Evergreen ILS Website

IRC log for #evergreen, 2015-01-02

| 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
02:01 NikolaMachiavell joined #evergreen
06:44 pie_ joined #evergreen
06:44 pie_ joined #evergreen
07:33 collum joined #evergreen
07:33 rjackson-isl joined #evergreen
08:01 remingtron joined #evergreen
08:34 abowling joined #evergreen
08:34 mmorgan joined #evergreen
08:36 sarabee joined #evergreen
08:49 jboyer-isl joined #evergreen
09:02 Dyrcona joined #evergreen
09:02 Dyrcona jeff++
09:03 ericar joined #evergreen
09:03 ericar left #evergreen
09:04 Dyrcona jeff saved me a debugging session with Venkman.
09:19 BigRig joined #evergreen
09:21 pie_ joined #evergreen
09:37 RoganH joined #evergreen
10:20 Dyrcona When looking at running queries in an Evergreen database, ones that have hash values for table names are run by the reporter, correct?
10:21 jeff i can't remember without looking if QP uses that trick anywhere
10:22 jeff but i can confirm that the reporter does generate those kinds of table aliases -- that probably doesn't help you much :-)
10:22 Dyrcona OK. I've got one of the queries running for about 5 minutes now, and there are two clark kents going, one says reporting.
10:22 Dyrcona I'll assume this is the report.
10:27 Dyrcona Yep. The query finished and the reporting clark kent vanished.
10:33 Dyrcona jeff++ again
11:39 mllewellyn joined #evergreen
12:47 jeff you are too kind.
12:50 Dyrcona jeff: you have been too helpful. :)
12:50 jeff drat. so much for THAT new year's resolution.
12:54 buzzy joined #evergreen
12:55 nhilton joined #evergreen
12:59 mmorgan joined #evergreen
13:11 berick gmcharlt++ # Koha CATalog
13:15 jeff that's it. we're all switching to koha, right meow.
13:15 sandbergja joined #evergreen
13:16 * gmcharlt cannot resist
13:16 gmcharlt @quote add <jeff> that's it. we're all switching to koha, right meow.
13:16 pinesol_green gmcharlt: The operation succeeded.  Quote #104 added.
13:18 Dyrcona heh
13:20 remingtron berick: bshum: I'm looking to install the web client. Is the staff/README.install file in master the latest? I recall bshum trying to flesh it out, but don't see that in the history.
13:21 gmcharlt remingtron: it's the latest AFAIK; what bshum had been working on IIRC was the OpenSRF websockets README
13:21 gmcharlt in any event, the process described in staff/README.install works
13:21 remingtron gmcharlt: ah, thanks, that sounds right
13:22 bshum i did start a branch for the main README too
13:23 berick see also bug 1392759 for automating the prereq installs
13:23 pinesol_green Launchpad bug 1392759 in Evergreen "Developer/Packager Makefile.install targets" (affected: 1, heat: 6) [Wishlist,New] https://launchpad.net/bugs/1392759
13:24 berick though, it's probably easier just to use the README.install for now
13:25 bshum remingtron: Yeah looks like I didn't push a git branch yet, but I apparently did create a generated version at http://evergreen-ils.org/~bshum/Ever​green-README.html#_optional_extra_st​eps_for_browser_based_staff_client
13:25 bshum I'll look around on my laptops, one of them probably has the working branch
13:25 bshum I think I wanted to flesh out the position of the instructions better
13:25 bshum Since it only pertains to developers who use the git installs
13:25 bshum The tarballs already compile things.  Now, anyways.
13:28 remingtron bshum: thanks for the info!
13:32 remingtron bshum: did you you also push a branch for opensrf install instructions w/ websockets? or is that the missing branch you mentioned?
13:32 berick remingtron: it's in opensrf master
13:32 bshum remingtron: That was definitely already done, and is part of OpenSRF master
13:32 bshum It's only a matter of when gmcharlt cuts 2.4.0 official :)
13:32 remingtron berick++ bshum++
13:33 bshum I can't find my working branch for Evergreen... maybe it got lost in my VM shuffles :(
13:33 bshum So yeah, the staff/README.install is the main thing to follow for the moment.
13:33 remingtron thanks, that's what I'll do then
13:39 bshum remingtron: On a different note, I have it on my very long list of to-do to finish looking over the changes you and Stompro were poking at for 2.7 upgrade doc changes in https://bugs.launchpad.net/evergreen/+bug/1390138
13:39 pinesol_green Launchpad bug 1390138 in Evergreen "Documentation: 2.7 upgrade docs need to be updated" (affected: 1, heat: 6) [Medium,Confirmed] - Assigned to Josh Stompro (u-launchpad-stompro-org)
13:39 bshum Or wait, maybe I was thinking of another bug you were working on with Stompro :\
13:40 bshum Oy.
13:40 berick bshum: this is where I would add the '2.8' series?  https://launchpad.net/evergreen/+addseries
13:40 bshum I think so
13:40 bshum Looks right anyways
13:40 berick k
13:40 bshum Yes.
13:41 bshum berick++
13:41 berick bshum: do you have a tool for updating bugs from targeting 2.next to 2.8?
13:42 bshum berick: What I did during the last dev cycle was to only move bugs from 2.next to 2.8 as they were actually merged / worked on.
13:42 bshum That way, we didn't churn unnecessarily to move everything back from 2.8 to 2.next if we missed them
13:42 bshum So 2.next is a perpetual milestone.
13:43 bshum As far as moving things, no, I've always just manually changed things in LP.
13:43 berick gotha
13:45 Dyrcona I used to have a script, but it quit working after a LP udgrade a couple of years ago.
13:45 bshum Based on that interpretation, I might suggest changing some bugs to no longer target 2.next (since they were bug fixes that have been released in 2.7 series) and just mark them as fix released with no milestone shuffle to 2.8.x
13:46 bshum If it would help, I'd be happy to do some bug triage for you berick.
13:46 * berick wonders if we should just have a milestone called "pullrequest"
13:47 berick bshum: i would not say no to that :)
13:47 bshum Maybe "newfeature"
13:47 bshum :)
13:47 bshum pullrequest for bugs vs. newfeatures are different to me
13:47 berick oh, right, because 2.next would only be features
13:49 berick bshum: regarding the 2.7 vs 2.next bugs, if they were merged into 2.7, wouldn't they be marked as 'fix committed' for 2.next anyway?
13:49 bshum berick: Correct.
13:49 bshum But for LP purposes then, you'd have lingering bugs that never close cause 2.next will never release
13:49 bshum So we end up moving those bugs from 2.next to an actual release milestone 90% of the time anyways
13:50 berick i see.  just wondering what makes more sense.. marking 'released' on a virtual milestone (2.next) seems kind of odd, no?
13:50 bshum It's pretty pointless.
13:51 berick haha
13:51 bshum What I am doing right now is removing the milestone link for the main line
13:51 bshum And marking the bug as fix released
13:51 bshum Which will hide it from active listed bugs
13:51 berick ah, ok
13:51 bshum And not have it linked to the 2.next milestone anymore
13:51 bshum This is my general interpretation of a way to use LP.  We can discuss it further at the January dev meeting maybe.
13:51 berick another possibilty.. rename '2.next' to 'master'.  equally as pointless, but more flexible going forward
13:52 bshum And solidify our approaches
13:52 berick sure
13:52 berick and thanks, bshum
13:53 bshum berick: Once you have a 2.8.0-alpha milestone (or beta?) let me know
13:53 bshum I can shuffle along bugs that are fix committed in 2.next to the proper place for 2.8
13:53 berick k, doing so now
13:55 berick bshum: do you know what "date targeted" means in the milestone creation form?
13:55 berick release date, perhaps
13:55 bshum berick: That's sort of an estimated date for when you release, yes.
13:56 berick cook
13:56 berick er, cool
13:56 berick we're cookin!
13:56 bshum I tend to target those to the date I plan to cut, or maybe +1 day
13:56 bshum I think some people use +1 day (gmcharlt seems to have?) and it seems smart to do so since LP seems to live in a different timezone.
13:56 bshum Close enough though :)
13:56 gmcharlt bshum: uh... yeah... that's why I seized on that date... that's right...
13:57 gmcharlt :)
13:57 bshum gmcharlt++ # you're just that cool ;)
13:57 berick heh
13:57 berick ok, created 2.8-beta
13:58 bshum berick++ #cool, retargeting
13:58 berick bshum++
14:00 bshum Okay, all settled.
14:00 bshum For now.
14:00 bshum The real work begins though ;)
14:03 berick indeed
14:06 * berick wonders if 78 pullrequest bugs is high
14:07 bshum That sounds like a lot.
14:09 bshum But eh, no problemo :)
14:17 jboyer-isl joined #evergreen
14:40 RoganH joined #evergreen
15:44 pinesol_green [evergreen|Pasi Kallinen] Make Vandelay merge profile names translatable. - <http://git.evergreen-ils.org/?p=​Evergreen.git;a=commit;h=e66d78b>
17:01 pinesol_green Incoming from qatests: Test Success - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html>
17:04 mmorgan left #evergreen
17:07 berick ugh.  on more than one box (ubuntu 14.04), retrieving file /reports/fm_IDL.xml via browser craps out w/ an IDLCHUNK parse error.
17:07 berick it reads "\x1f\x8b\b" as the first few bytes..  (which is of course not in the IDL).
17:07 berick mod_idlchunk.c might need a once-over.
17:07 berick cofirmed same with mod_xmlent
17:08 berick wonder if anyone is having the same problem...
17:15 jeffdavis berick: we saw that error during our 2.4 and 2.6 upgrades, let me see if I can dig up details
17:16 berick jeffdavis++
17:16 berick good... hope i'm just missing something
17:20 dbs berick: usually that's a sign that the translation is not complete
17:20 berick dbs: the fm_IDL.xml file itself is fine.  xmllint linkes it OK
17:20 berick er, likes it
17:20 jeffdavis yeah, just confirmed that our issue was translation related so probably not the same problem
17:21 dbs berick: sure, but if there's a new type (like 'aou') that doesn't exist in the entity-ized version, then crap out
17:21 jeffdavis in our case we had added an entry to the IDL (to add a link from holds to hold_copy_map in the reporter) but hadn't done the proper localization stuff; our workaround was to overwrite reports/fm_IDL.xml with the version at /openils/conf/fm_IDL.xml which is hardcoded in English
17:21 berick more to the point.. on my system, /openils/var/web/reports/fm_IDL.xml was copied directly from /openils/conf/fm_IDL.xml
17:21 berick IOW, it has no entities
17:22 dbs berick: oh, that's certainly a different matter then.
17:22 berick dang
17:23 dbs proper localization stuff == 'cd build/i18n; make LOCALE=xx-YY newpot updatepo; make install' before doing the regular build and install
17:23 dbs otherwise, you have to copy the updated i18n files into place manually
17:25 berick dbs: thanks.  been meaning to figure out how to do that when installing from source.
17:25 * dbs would love to get rid of mod_xmlent and all of the .properties bits of i18n
17:26 dbs Interesting, https://laurentian.concat.ca/reports/fm_IDL.xml works fine but http://laurentian.concat.ca/reports/fm_IDL.xml gives a heinous error on our SSL-everywhere-ish instance
17:27 dbs "unable to include "/opac/locale/${locale}/fm_IDL.dtd" in parsed file /openils/var/web/reports/fm_IDL.xml" the error log says (ubuntu 12.04 here)
17:28 berick yeah, that's definitely different
17:29 jeffdavis berick: is your fm_IDL.xml being gzipped by apache?
17:29 jeffdavis apache deflate or whatever
17:29 berick jeffdavis: ooh.. i like that
17:29 berick lemme see
17:30 dbs jeffdavis++ # that rings a bell too
17:31 dbs We had disabled that combination way back when in the apache 2.2 config because of that problem, but I think the compression config might have been touched recently?
17:32 berick jeffdavis++
17:32 berick that's it
17:32 jeffdavis :)
17:34 jeff jeffdavis++
17:35 jeff (since i'm here anyway... ;-)
17:36 dbs Looks like the OOB compression config is still the same
17:37 berick had to change /etc/apache2/mods-enabled/deflate.conf to get it to work w/ deflate enabled
17:37 berick ->  AddOutputFilterByType DEFLATE application/xml
17:40 * berick will open LP
17:42 berick cool, 'SetEnv no-gzip' also fixes it
18:19 b_bonner joined #evergreen
18:20 mnsri_away joined #evergreen
18:20 rashma_away joined #evergreen
19:32 sarabee joined #evergreen
20:31 nhilton joined #evergreen
21:36 remingtron_ joined #evergreen

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