| Time |
Nick |
Message |
| 07:48 |
|
jboyer-isl joined #evergreen |
| 08:09 |
|
mrpeters joined #evergreen |
| 08:11 |
|
mtate joined #evergreen |
| 08:11 |
|
akilsdonk joined #evergreen |
| 08:20 |
|
ericar joined #evergreen |
| 08:21 |
|
mrpeters joined #evergreen |
| 08:25 |
|
rjackson-isl joined #evergreen |
| 08:29 |
|
Dyrcona joined #evergreen |
| 08:35 |
|
Shae joined #evergreen |
| 08:45 |
|
mmorgan joined #evergreen |
| 09:01 |
|
kmlussier joined #evergreen |
| 09:20 |
|
ericar_ joined #evergreen |
| 09:40 |
|
mllewellyn joined #evergreen |
| 09:47 |
|
collum joined #evergreen |
| 09:49 |
|
yboston joined #evergreen |
| 09:51 |
|
mdriscoll joined #evergreen |
| 10:01 |
Dyrcona |
Nice way to start the work week: TypeError: branch is undefined |
| 10:01 |
Dyrcona |
autogen.sh doesn't fix it. |
| 10:02 |
Dyrcona |
kmlussier: You can't use my dev vm, and I'm killing the conditional negative balance branch. I blame it for breaking this. |
| 10:02 |
kmlussier |
ok |
| 10:08 |
|
mrpeters left #evergreen |
| 10:11 |
|
berick joined #evergreen |
| 10:15 |
|
remingtron joined #evergreen |
| 10:51 |
|
tspindler joined #evergreen |
| 11:39 |
remingtron |
bshum: I'm testing a fresh 2.7 beta db and getting "ERROR: function evergreen.rank_cp(bigint) does not exist" |
| 11:39 |
remingtron |
is rank_cp a normal Evergreen function, or is it likely to be something custom on my end? |
| 11:39 |
remingtron |
we have done some postgres hacking on this server |
| 11:43 |
tsbere |
I think rank_cp is normal, but apparently missing |
| 11:43 |
kmlussier |
I'm guessing it's something that might have been impacted by bug 1234845? |
| 11:43 |
pinesol_green |
Launchpad bug 1234845 in Evergreen "possible optimization for evergreen.ranked_volumes database function" (affected: 2, heat: 12) [Medium,Fix committed] https://launchpad.net/bugs/1234845 |
| 11:45 |
|
RoganH joined #evergreen |
| 11:45 |
Dyrcona |
I find evergreen.rank_cp_status in the code and not rank_cp. |
| 11:46 |
* Dyrcona |
checks a working database for a rank_cp function. |
| 11:47 |
Dyrcona |
I don't find a rank_cp function in our production server. |
| 11:47 |
remingtron |
I couldn't find any history of it in my first git investigations |
| 11:47 |
Dyrcona |
Sounds like something local or a busted code reference. |
| 11:48 |
Dyrcona |
I didn't find any SQL code in Evergreen trying to call it, either. |
| 11:56 |
remingtron |
Dyrcona: thanks for checking. I'll keep poking to find the culprit |
| 11:58 |
remingtron |
thanks kmlussier and tsbere for chiming in too |
| 12:05 |
|
akilsdonk joined #evergreen |
| 12:15 |
|
jihpringle joined #evergreen |
| 12:17 |
|
vlewis joined #evergreen |
| 12:32 |
|
mnsri joined #evergreen |
| 12:41 |
mmorgan |
We are looking at substituting the "active date" for the "create date" in the item display in the staff opac. |
| 12:42 |
mmorgan |
We added a column to pull "copy_info.active_date" in opac/parts/record/copy_table.tt2 but it doesn't work. Just get a "-" as if there is no value in active_date. |
| 12:42 |
mmorgan |
any advice? |
| 12:55 |
tsbere |
mmorgan: I think unapi.acp (and the .sunit variant, I guess?) would need to be edited |
| 12:56 |
tsbere |
mmorgan: Mainly because I believe that information is coming from those functions and you are not, as a result, dealing with actual copy objects |
| 13:03 |
mmorgan |
ok, i see that function. So all the data in the opac comes via those functions? |
| 13:03 |
* mmorgan |
is still trying to learn how the data gets from one place to the other ... |
| 13:05 |
|
RoganH joined #evergreen |
| 13:05 |
tsbere |
mmorgan: I believe a large percentage of the information in the opac comes from there. I haven't actually traced everything. Adding to the XMLATTRIBUTES list and the GROUP BY (at opposite ends of the functions) should hopefully let you add new fields like active_date. I would test in a dev system first though. |
| 13:07 |
mmorgan |
ok, thanks. We'll take a look at that. |
| 13:07 |
mmorgan |
tsbere++ |
| 13:08 |
berick |
beware the record details page is different. See Record::mk_copy_query, which calls AppUtils::basic_opac_copy_query |
| 13:08 |
berick |
which uses a json_query instead of unapi |
| 13:12 |
mmorgan |
berick: ok, thanks. We will proceed with caution - on our test server. |
| 13:15 |
|
hbrennan joined #evergreen |
| 13:17 |
|
mtate joined #evergreen |
| 13:35 |
dbs |
Some day maybe those two will be reconciled :/ |
| 13:37 |
* Dyrcona |
builds vm #2 for the day. |
| 13:38 |
Dyrcona |
kmlussier: I figured out what was wrong with the vm I built earlier. You should be able to use it later. |
| 13:40 |
Dyrcona |
bshum: lp1355319 : Beta installs won't work without it. |
| 13:41 |
Dyrcona |
pinesol_green: Are you awake? |
| 13:41 |
pinesol_green |
Dyrcona: Try restarting apache. |
| 13:42 |
eeevil |
bug 1355319 |
| 13:42 |
pinesol_green |
Launchpad bug 1355319 in Evergreen "Missing Dependency: Parse::RecDescent" (affected: 1, heat: 6) [Undecided,New] https://launchpad.net/bugs/1355319 |
| 13:43 |
Dyrcona |
I thought it worked with lp and the number. |
| 13:44 |
Dyrcona |
Anyway.... about to test the Makefile.install fix on Ubuntu Trusty. |
| 13:44 |
Dyrcona |
If someone could test Fedora, that would be great. |
| 13:49 |
dbs |
If only we had a live build tester for Fedora |
| 13:50 |
Dyrcona |
dbs: I can't tell if you're being sarcastic or not. ;) |
| 13:51 |
bshum |
Dyrcona: I think the lp didn't work for pinesol_green without the space between LP and # |
| 13:51 |
Dyrcona |
I thought there was a space. |
| 13:51 |
dbs |
Not sarcastic. The live build tester started failing a day or two ago because of the Parse::RecDescent missing problem |
| 13:52 |
Dyrcona |
Whatever....Machines don't like me, and I don't like them either. ;) |
| 13:52 |
dbs |
05:16 < pinesol_green> Incoming from qatests: Test Failure - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 13:52 |
dbs |
I noticed it over the weekend, and it does a very good job of highlighting the problem |
| 13:52 |
Dyrcona |
Yep. I noticed it Friday, and had forgotten about it when I built my latest VMs, until they didn't work of course. |
| 13:53 |
bshum |
I didn't get to build anything new yet, but that makes me feel a little better that I haven't actually rolled the beta1 tarball yet then. |
| 13:53 |
bshum |
Dyrcona++ for following up on that dependency issue |
| 13:56 |
Dyrcona |
Nope. Machines don't like me today. |
| 13:56 |
Dyrcona |
The NIC on the UPS says there is no UPS. |
| 14:01 |
jeff |
that's always fun -- rebooting the card without tickling the UPS to drop the load. ;-) |
| 14:07 |
|
Sato joined #evergreen |
| 14:09 |
|
Sato joined #evergreen |
| 14:15 |
Dyrcona |
bshum: You want me to target the bug at beta1? |
| 14:15 |
bshum |
Dyrcona: Yeah we should put it in |
| 14:15 |
Dyrcona |
I did originally and then waffled. |
| 14:21 |
Dyrcona |
I have tested it on Ubuntu Trusty, and I presume the Debian and Ubuntu Precise targets will work, since they all name the package the same way. |
| 14:22 |
Dyrcona |
I put in the name of the package as I found it for Fedora 20, so hope Fedora works. ;) |
| 14:48 |
|
csharp joined #evergreen |
| 14:57 |
bshum |
Dyrcona++ |
| 15:02 |
pinesol_green |
[evergreen|Jason Stephenson] LP1355319: Add missing Parse::RecDescent perl dependency. - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=f54db60> |
| 15:06 |
|
mnsri joined #evergreen |
| 15:22 |
|
kmlussier joined #evergreen |
| 15:26 |
kmlussier |
@dessert bshum |
| 15:26 |
* pinesol_green |
grabs some Carrot Cake for bshum |
| 15:29 |
|
RoganH joined #evergreen |
| 15:34 |
|
mtate joined #evergreen |
| 15:41 |
|
_bott_ joined #evergreen |
| 15:42 |
|
ericar_ joined #evergreen |
| 16:07 |
bshum |
eeevil: So I'm playing with create_release_notes.sh and I'm having difficulties where the different levels aren't cooperating when I try to go and generate the content. |
| 16:07 |
bshum |
Also I'm seeing stuff end up in two "Upgrade Notes" areas when one of those ought to be "New Features" |
| 16:08 |
bshum |
So I'm not sure if that means that I should edit the original RELEASE_NOTES_NEXT files to fix up the markup syntax |
| 16:08 |
bshum |
And set the levels correctly |
| 16:08 |
bshum |
Or if there's something wrong with the script |
| 16:08 |
* bshum |
continues poking |
| 16:09 |
bshum |
Also, when it asks for version, I can pass it -r 2.7 or -r 2_7 |
| 16:09 |
eeevil |
bshum: I haven't looked at that in ... ages. the levels were an issue at the beginning, but I think we said "that can be handled with command line switches" or the like |
| 16:09 |
bshum |
If I give it 2_7, then it formats the filename correctly as RELEASE_NOTES_2_7.txt |
| 16:09 |
bshum |
But then the name is wrong in the actual body |
| 16:10 |
bshum |
If I do 2.7, then it gets the filename wrong, but puts the right name in the body :) |
| 16:10 |
bshum |
I can manually adjust things of course. |
| 16:10 |
eeevil |
that's probably a simple fix. the simplest of which is `mv` ;) |
| 16:10 |
bshum |
Just trying to understand what I'm doing |
| 16:10 |
bshum |
:D |
| 16:10 |
bshum |
Since it's not documented |
| 16:10 |
eeevil |
sure thing. it was a starting point, not The End, by any means |
| 16:13 |
Bmagic |
When searching the OPAC and grouping by format, I have a question. I place a hold on a metabib that contains only books, I am still asked about formats that were not previously mentioned in the search results. Where does the system get these formats? It's not the leader/008 combination as far as I can tell |
| 16:21 |
Bmagic |
Bueller? |
| 16:22 |
eeevil |
Bmagic: from the list of records that share the fingerprint of the record you clicked on |
| 16:23 |
Bmagic |
eeevil: Those formats were generated during a digest? |
| 16:23 |
eeevil |
no |
| 16:24 |
eeevil |
the fingerprint of the record (basically, title+author, but more complicated than that) defines the metarecord to which the bib belongs |
| 16:25 |
Bmagic |
eeevil: I think I understand how those bibs are glued together, but the search results do not show that my metabib includes "Large Print" or "Cassette audiobook" however, I am presented with those options when placing a hold |
| 16:25 |
eeevil |
depending on the version of EG, the formats listed are either the type+form combinations from a hard-coded list of "known" formats, or a configurable set, as used by the full list of bibs in the metarecord |
| 16:25 |
Bmagic |
2.6.1 |
| 16:26 |
Bmagic |
eeevil: These formats are setup in a database table for these paticular bibs? I won't find the answer in the MARC? |
| 16:28 |
eeevil |
the answer always ends up coming from the marc, yes, but not directly. do you have a link to the record in question? (of course, I won't be able to see the hold screen, but I may be able to point you at other constituent records) |
| 16:28 |
Bmagic |
eeevil: Yes! Thanks for your help: https://missourievergreen.org/eg/opac/results?query=harry%20potter%20stone;qtype=title;locg=174;modifier=metabib |
| 16:29 |
Bmagic |
eeevil: That link gives you 4 results. I am interested in the 2nd result with the (3) |
| 16:30 |
eeevil |
https://missourievergreen.org/eg/opac/results?query=harry%20potter%20stone;qtype=title;modifier=metabib;metarecord=261505 |
| 16:31 |
Bmagic |
eeevil: As you can see, those bibs only mention "Book". Leader byte 6 is set to "a" for 1009993 and 1103662 but 1042161 is set to "i" |
| 16:31 |
eeevil |
MR holds format selection does not apply the locg filter when grabbing the list of potential formats. and that link I just pasted is the MR in question sans locg filtering |
| 16:32 |
Bmagic |
eeevil: ah! So the metabib accutally includes many more bibs, I get it |
| 16:32 |
eeevil |
yes |
| 16:33 |
Bmagic |
eeevil: It all makes sense now |
| 16:34 |
Bmagic |
So, when placing the hold, it isn't scoping to only those locg bibs? |
| 16:35 |
|
tspindler left #evergreen |
| 16:37 |
|
ericar joined #evergreen |
| 16:38 |
|
ericar left #evergreen |
| 16:50 |
eeevil |
right |
| 17:08 |
|
mmorgan left #evergreen |
| 17:09 |
|
mdriscoll left #evergreen |
| 17:11 |
pinesol_green |
Incoming from qatests: Test Success - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 17:23 |
phasefx |
Dyrcona++ bshum++ |
