Evergreen ILS Website

IRC log for #evergreen, 2014-08-11

| Channels | #evergreen index | Today | | Search | Google Search | Plain-Text | summary | Join Webchat

All times shown according to the server's local time.

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;q​type=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/res​ults?query=harry%20potter%20stone;qtype=t​itle;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++

| Channels | #evergreen index | Today | | Search | Google Search | Plain-Text | summary | Join Webchat