| 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/Evergreen-README.html#_optional_extra_steps_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 |
