00:06 |
pinesol_green |
[evergreen|Kathy Lussier] Docs: 2.11.9 release notes - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=203dd19> |
00:06 |
pinesol_green |
[evergreen|Kathy Lussier] Docs: 2.12.6 Release Notes - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=b38b3e5> |
00:24 |
|
acautley joined #evergreen |
01:46 |
|
acautley joined #evergreen |
02:55 |
|
acautley joined #evergreen |
03:49 |
|
acautley joined #evergreen |
04:37 |
|
Jillianne joined #evergreen |
04:58 |
|
acautley joined #evergreen |
05:01 |
pinesol_green |
News from qatests: Test Success <http://testing.evergreen-ils.org/~live> |
05:55 |
|
acautley joined #evergreen |
06:59 |
|
acautley joined #evergreen |
07:13 |
|
rjackson_isl joined #evergreen |
08:55 |
|
acautley joined #evergreen |
08:59 |
|
bos20k joined #evergreen |
09:10 |
|
kmlussier joined #evergreen |
09:12 |
bshum |
gmcharlt (and others): FYI, I'll angle to do another i18n POT and PO sync later tonight after today's work is done prior to 3.0-beta2 cutting (tomorrow?) |
09:14 |
|
Dyrcona joined #evergreen |
09:14 |
bshum |
Looking at LP translations, looks like Eva's finished translating for Czech all the latest strings we added for 3.0-beta1 for webstaff/db.seed so there's plenty to test and check out |
09:28 |
|
yboston joined #evergreen |
09:59 |
|
acautley joined #evergreen |
10:08 |
|
rlefaive_ joined #evergreen |
10:09 |
gmcharlt |
bshum: noted, and thanks |
10:09 |
kmlussier |
Oops. The 2nd time this week I forgot to vote. |
10:18 |
csharp |
miker: pretty sure at this point that RAM was part of (if not the cause of) the problem - thanks for the pointer! |
10:18 |
Stompro |
Beta2 tomorrow... I'm just finishing with a test database upgrade of beta1... sigh. |
10:18 |
csharp |
Stompro: right there with ya |
10:19 |
csharp |
JBoyer's disable ALL THE TRIGGERS! solution made mine pretty painless though after sifting out PINES database particularities |
10:20 |
Stompro |
No problems with a 2.10.6 -> 3.0.Beta1 database upgrade so far though, so that is good. Some parts take a long time on my non ssd test vm though. |
10:21 |
Stompro |
csharp, could you point me to more info on that? |
10:26 |
csharp |
Stompro: here's what I did http://git.evergreen-ils.org/?p=evergreen/pines.git;a=blobdiff;f=Open-ILS/src/sql/Pg/version-upgrade/2.12.5-3.0-beta1-upgrade-db.sql;h=3a4f54fecc0b4c37b627da2963fe1e50e259aa02;hp=0da18594c992f7050b0ea907600e318af117d6da;hb=99d5c1164f7180117760d48245db54a5a7bc0296;hpb=dfc8e3892d76af32162e1069c2c620139449ce2f |
10:28 |
Stompro |
csharp++ thanks |
10:36 |
kmlussier |
Recalculating fingerprints? |
10:38 |
Dyrcona |
Yeap. |
10:39 |
Dyrcona |
csharp++ # For the links.. |
10:40 |
Dyrcona |
I'm supposed to set up a 3.0 testing server, too, but I'm focusing on the upgrade, first. :) |
10:40 |
Dyrcona |
miker: Do you have any code for that set replication suggestion from last week? I might give that a go, though I said it made me uneasy. |
10:41 |
Dyrcona |
If not, I suppose I could figure it out. |
10:43 |
miker |
Dyrcona: it's basically just, "set session_replication_role to 'replica';" before the big update, and then "set session_replication_role to 'origin';" after |
10:44 |
Dyrcona |
miker: Thanks! I'll give that a whirl when do it the 3.0 upgrade on the testing server. |
10:44 |
pinesol_green |
[opensrf|Ben Shum] LP#1708048: Add support for Debian 9 Stretch - <http://git.evergreen-ils.org/?p=OpenSRF.git;a=commit;h=a85132e> |
10:44 |
miker |
awesome |
10:44 |
pinesol_green |
[opensrf|Jason Stephenson] LP#1708048: Fix ld problems by renaming libraries. - <http://git.evergreen-ils.org/?p=OpenSRF.git;a=commit;h=cace46d> |
11:35 |
gmcharlt |
tossing in bug 1715503 as ready for review and merging today |
11:35 |
pinesol_green |
Launchpad bug 1715503 in Evergreen "Complain if minimum Pg version for 3.0 is not met" [Medium,New] https://launchpad.net/bugs/1715503 |
11:40 |
|
rlefaive joined #evergreen |
12:46 |
bshum |
miker++ # I'll test your branch for bug 1717777 later tonight |
12:46 |
pinesol_green |
Launchpad bug 1717777 in Evergreen "Need to load all the PO files for a locale" [Undecided,Confirmed] https://launchpad.net/bugs/1717777 |
12:47 |
miker |
bshum++ # thanks |
12:47 |
bshum |
Fwiw, I also noticed that there could be differences in the various PO files too |
13:45 |
Dyrcona |
Wheezy is old and...wheezy...it should be replaced by Jessie. :) |
14:10 |
Dyrcona |
FYI: Master Evergreen seems to be broken on Debian 8 Jessie. |
14:11 |
Dyrcona |
karma:unit starts out with this warning: WARN [watcher]: Pattern "/home/opensrf/Evergreen/Open-ILS/web/js/ui/default/staff/node_modules/angular-sanitize/angular-sanitize.min.js" does not match any file. |
14:12 |
Dyrcona |
Then all following tests blow up with with various long messages. |
14:13 |
Dyrcona |
I'm testing a branch that has this commit as head: bed0acd1b197af590da729b6e1c29839580d1c5b |
14:13 |
Dyrcona |
Oh, right. It doesn't look at the working repository. |
14:14 |
Dyrcona |
I may have botched a prereq in the makefile, but I don't think so. |
00:33 |
|
roycroft joined #evergreen |
04:08 |
|
Jillianne joined #evergreen |
05:00 |
pinesol_green |
News from qatests: Test Success <http://testing.evergreen-ils.org/~live> |
05:35 |
|
rlefaive joined #evergreen |
07:14 |
|
rjackson_isl joined #evergreen |
07:15 |
|
rlefaive joined #evergreen |
15:58 |
berick |
hm, browser client console showing lovefield error. error url takes me to.. |
15:58 |
berick |
Constraint error: (201) Duplicate keys are not allowed, index: Setting.pkSetting, key: "ui.staff.max_recent_patrons" |
15:59 |
berick |
anyone else getting this? |
15:59 |
Dyrcona |
So, I tested Lp 1708048 on trusty. make check succeeds for OpenSRF and Evergreen. All Evergreen live tests pass. |
15:59 |
pinesol_green |
Launchpad bug 1708048 in OpenSRF "Add support for Debian 9 Stretch" [Wishlist,Confirmed] https://launchpad.net/bugs/1708048 - Assigned to Galen Charlton (gmc) |
15:59 |
* berick |
will just try clearing localStorage |
15:59 |
Dyrcona |
I also commented on the bug, but thought this might be quicker to reach the intended audience. |
16:47 |
bshum |
Yeah I didn't notice till I re-traced the steps more carefully too |
16:48 |
bshum |
More reasons that 3.0 will be the bestest Evergreen release soon enough |
16:49 |
Dyrcona |
Yeah, it's still needed on 2.12.... |
17:01 |
pinesol_green |
News from qatests: Test Success <http://testing.evergreen-ils.org/~live> |
17:04 |
csharp |
dammit! A/T is totally broken |
17:05 |
csharp |
I don't have a good bead on what's happening yet, but something breaks and it's a wall of "No children available" |
17:09 |
|
mmorgan left #evergreen |
00:23 |
pinesol_green |
[evergreen|Jane Sandberg] Docs: TPAC bib_source variable - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=9d163e4> |
05:00 |
pinesol_green |
News from qatests: Test Success <http://testing.evergreen-ils.org/~live> |
06:13 |
|
rkw joined #evergreen |
07:14 |
|
rjackson_isl joined #evergreen |
08:39 |
|
mmorgan joined #evergreen |
10:25 |
pinesol_green |
Launchpad bug 1712637 in Evergreen "Web Client: Default Hold Pickup Location Errors" [High,Confirmed] https://launchpad.net/bugs/1712637 |
10:29 |
kmlussier |
berick: In the hold pickup location selector? No. |
10:29 |
kmlussier |
I was about to build a new VM this morning and was going to include that branch. I can check again just to be sure. |
10:30 |
berick |
kmlussier: that would be appreciated. I'm not seeing what you are seeing. |
10:30 |
berick |
they are greyed out and un-select-able for me |
10:32 |
berick |
i just rebased to master and re-tested |
10:37 |
dbs |
berick: in terms of clearing cached proxy entries for given URIs, I started using the proxy_cache_bypass directive recently |
10:37 |
pinesol_green |
[evergreen|Jane Sandberg] Docs: adding the MARC Templates documentation back - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=899b6a5> |
10:37 |
pinesol_green |
[evergreen|Jane Sandberg] Docs reorg: splitting action/triggers into command-line and staff-client manuals - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=10c578a> |
10:43 |
dbs |
thank you https://serverfault.com/questions/493411/how-to-delete-single-nginx-cache-file for showing me the way :) |
10:45 |
|
mmorgan joined #evergreen |
10:51 |
berick |
i also had to find an example... docs are spare on that one. |
11:00 |
kmlussier |
berick: I don't know why it didn't work in my earlier test, but it's working for me now. I'll sign off and push it now. |
11:01 |
berick |
kmlussier++ |
11:21 |
|
ningalls joined #evergreen |
11:25 |
gmcharlt |
survey on what version number to use for the next major OpenSRF release https://gmcharlt.limequery.org/523355 |
13:42 |
csharp |
examples here (for the logs): http://gapines.org/eg/kpac/category?trail=30 |
13:43 |
* mmorgan |
remembers making buckets OPAC-able by doing what csharp said, changing btype AND public. But since both changes are required, the 'publicly visible' checkbox in the web client won't do the whole job. |
13:45 |
berick |
doesn't the pub checkbox in the web client determine if staff A can view a (staff) bucket created by staff B? or is that just permission-based? |
13:47 |
csharp |
for webstaff installation, is there anything wrong with having test/data/idl2js.pl use the installed versions of fm_IDL.xml and fm_IDL2js.xsl? since we install from debs, we're trying to work around needing the source tree installed |
13:47 |
csharp |
btw, what I'm suggesting *works*, I'm just wondering if there's a good reason not to do so by default or just instead |
13:52 |
berick |
csharp: it uses the source version so it's possible to build EG without installing it. |
13:53 |
kmlussier |
berick: Yeah, that's what I'm testing now. But I keep messing up my tests. |
13:56 |
csharp |
berick: ah |
13:59 |
kmlussier |
Yeah, I can retrieve somebody else's bucket by id whether it's publicly visible or not. |
14:01 |
kmlussier |
That's a copy bucket. I haven't tried it with a record bucket yet. |
14:37 |
kmlussier |
csharp: Too late! I've already tweeted about it. |
14:50 |
csharp |
crap |
14:51 |
csharp |
:-D |
15:18 |
pinesol_green |
[evergreen|Bill Erickson] LP#1537233 Copy bucket handles mis-scans, improve focus - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=40d8ce3> |
15:24 |
|
tlittle joined #evergreen |
15:50 |
|
jvwoolf left #evergreen |
16:39 |
|
jihpringle_ joined #evergreen |
17:00 |
pinesol_green |
News from qatests: Test Success <http://testing.evergreen-ils.org/~live> |
17:03 |
|
mmorgan left #evergreen |
17:07 |
|
acautley joined #evergreen |
17:09 |
|
khuckins joined #evergreen |
17:20 |
pinesol_green |
[evergreen|Ben Shum] LP#1717715: Fix typo in webstaff serials - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=a7a98ff> |
17:26 |
|
Jillianne joined #evergreen |
18:01 |
|
tlittle left #evergreen |
18:27 |
|
acautley joined #evergreen |
05:01 |
pinesol_green |
News from qatests: Test Success <http://testing.evergreen-ils.org/~live> |
07:06 |
|
rjackson_isl joined #evergreen |
07:19 |
pinesol_green |
[evergreen|Galen Charlton] LP#1716486: fix hotkeys - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=bb85fcd> |
07:32 |
csharp |
@quote add * miker shakes fist at the heavens, "U T F EEEEEEIIIIIGGGGGHHHHTTTTT!" |
07:32 |
pinesol_green |
csharp: The operation succeeded. Quote #175 added. |
07:46 |
csharp |
@later tell RyanM see https://bugs.launchpad.net/evergreen/+bug/1541801 - should be fixed in the web client for 2.12 and newer (but not the XUL staff client) |
08:54 |
|
_adb joined #evergreen |
08:54 |
* csharp |
needs the fix, just wants to be sure we're on sure footing before experimenting too much |
08:57 |
Dyrcona |
csharp: I'm confident that gmcharlt's patch that I pushed last night fixes the problem. |
08:57 |
Dyrcona |
I'm going to build a new vm today to do some more testing. |
08:58 |
Dyrcona |
This is mainly 2.10.7 -> 2.12.5 upgrade testing, but this code will get another workout. |
08:59 |
Dyrcona |
I've got another machine that I'm supposed to install 3.0-beta onto, but I may just go with master. |
08:59 |
Dyrcona |
Until rel_3_0 is branched, that is. |
09:01 |
Dyrcona |
heh. It helps not to typo the db user name, huh? :) |
09:03 |
csharp |
Dyrcona: thanks ;-) |
09:04 |
Dyrcona |
Anyway, I think it is safe to apply the patch from last nigh if you've already installed OpenSRF 2.5.1. |
09:05 |
Dyrcona |
Oh, I can see it's going to be one of those typo kind of days. |
09:05 |
Dyrcona |
This is where testing with production data comes in handy. |
09:08 |
gmcharlt |
I am inclined to cut 2.5.2 now; the other changes can wait |
09:08 |
gmcharlt |
thoughts? |
09:09 |
|
bos20k joined #evergreen |
11:36 |
Bmagic |
Dyrcona++ |
11:36 |
Dyrcona |
I don't see anywhere that a SAN i put into an outgoing message. |
11:37 |
Dyrcona |
And yeah, right after that it looks up the address by SAN. ;) |
11:39 |
Dyrcona |
csharp: I haven't test a/t on 2.12. I probably should after making sure email goes nowhere. |
11:54 |
|
jvwoolf1 joined #evergreen |
11:57 |
|
sandbergja joined #evergreen |
11:58 |
csharp |
Dyrcona: A/T generally works - email notices are working fine - just the PO JEDI event with the undef variables that I'm trying to suss out |
13:24 |
Dyrcona |
Whee! tail -f /openils/var/log/osrfsys.log goes by too fast to follow. |
13:25 |
csharp |
berick: will do |
13:25 |
* berick |
always has to read "Fix for Web Client Copy Editor Fix" twice |
13:25 |
csharp |
I did verify that the template/environment/params have not changed between versions |
13:26 |
csharp |
but I haven't tested against stock yet |
13:26 |
Dyrcona |
csharp: You added lines to log the context, yeah? |
13:26 |
csharp |
yes |
13:27 |
kmlussier |
miker: mmorgan and I already verified the search slowness is still a problem on 2.5.1. Do you think 2.5.2 will make a difference? |
13:27 |
Dyrcona |
my events all went to invalid, but it could be because they are so old. |
13:28 |
miker |
kmlussier: that's what I want to test, yes. 2.5.1 has a bad bug, so an upgrade to the brand new 2.5.2 is indicated in any case |
13:28 |
Dyrcona |
I don't know enough about acq to setup an invoice to have a fresh one. |
13:28 |
csharp |
invalid probably means they aren't EDI vendors |
13:28 |
mmorgan |
miker: kmlussier: We slipped in the 2.5.2 fix this morning on our training server and still saw the issue. |
13:29 |
* csharp |
makes a sad face at mmorgan's last :-( |
13:29 |
csharp |
we're getting slow/timeout on searching too |
13:29 |
kmlussier |
Sure, I'll also update the OpenSRF on the test system I've been using just to be sure. |
13:29 |
* mmorgan |
forgot to supply same :-( |
13:30 |
* csharp |
was hoping the latest fixes would Just Work™ |
13:31 |
miker |
mmorgan: thanks, that's the confirmation I wanted. I just wanted to take something off the table to look at |
13:33 |
berick |
Dyrcona: to test the ACQ A/T stuff, i think all you need to do is activate a PO whose provider has an edi_default value |
13:33 |
berick |
the edi_account itself can be all dummy data |
13:33 |
csharp |
yeah |
13:34 |
Dyrcona |
berick: 1) I have no idea how to actually use acq. 2) I have 3-month old data that I can test with at the moment. |
13:34 |
Dyrcona |
I just make the dog food. I don't eat it. :) |
13:34 |
berick |
heh |
13:34 |
berick |
but it's delicious! |
13:35 |
berick |
TFW you remember you don't have to launch the XUL client |
13:35 |
csharp |
berick: did that earlier |
13:35 |
csharp |
"wait, why did I bother opening this?" |
13:36 |
berick |
:) gonna take some getting used to |
13:41 |
berick |
csharp: tested on master/master w/ stock data. had no problem generating JEDI. |
13:41 |
berick |
order had 1 LI and 25 copies, so not huge |
13:43 |
* berick |
is also using the large max_stanza_size, in case it's relevant |
13:49 |
csharp |
yeah our max_stanza_size is at 2000000 |
13:53 |
Dyrcona |
mine is the default 65536 |
13:53 |
Dyrcona |
Of course, my events failed to validate, so that's no helpful at this point. |
13:58 |
berick |
reminder to set an edi_default value on the provider after creating the edi_account. |
13:58 |
* berick |
got stuck on that |
14:03 |
* csharp |
just busted his test server by inserting the stock PO JEDI template into ALL THE EVENT DEFS |
14:04 |
csharp |
I was about to blow it away to start testing 3.0 anyway |
14:04 |
csharp |
and I did preserve the old defs, but I don't want to worry about spending the required time fixing it |
14:04 |
berick |
YOU GET EDI, AND YOU GET EDI |
14:04 |
berick |
noooooo |
14:05 |
csharp |
@oprah EDI |
16:48 |
Dyrcona |
Do it right, now, or pay for it later. |
16:48 |
Dyrcona |
Again, just a suggestion... :) |
17:00 |
miker |
parseFloat+printf (yes, we have a printf implementation stashed away somewhere in the code base) |
17:01 |
pinesol_green |
News from qatests: Test Success <http://testing.evergreen-ils.org/~live> |
17:02 |
|
mmorgan left #evergreen |
17:22 |
|
acautley joined #evergreen |
17:36 |
|
tlittle joined #evergreen |
17:42 |
pinesol_green |
[evergreen|Galen Charlton] LP#1708951: fix tabbing in webstaff catalog app for Firefox - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=c43bc5b> |
18:00 |
|
kmlussier joined #evergreen |
19:17 |
|
Jillianne joined #evergreen |
20:29 |
|
tsbere joined #evergreen |
01:04 |
|
dbwells_ joined #evergreen |
01:05 |
|
remingtron_ joined #evergreen |
01:14 |
|
dbwells__ joined #evergreen |
05:00 |
pinesol_green |
News from qatests: Test Success <http://testing.evergreen-ils.org/~live> |
07:02 |
|
agoben joined #evergreen |
07:02 |
|
JBoyer joined #evergreen |
07:13 |
|
rjackson_isl joined #evergreen |
09:01 |
|
_adb joined #evergreen |
09:07 |
|
rlefaive_ joined #evergreen |
09:09 |
JBoyer |
mdriscoll, kmlussier, csharp: I noticed the talk about upgrade script 1057 in the logs, the real issue is the trigger that maintains the 901c subfield. It's causing every record in your entire db, deleted or not, to be parsed by the MARC::XML perl module and the 901 rebuilt. |
09:10 |
JBoyer |
If that winds up changing the marc field it will be reingested, but otherwise it's still just overly slow for no reason. For that script on my testing server I disabled all of the triggers and ignored the deleted records to get it down to somewhere between 30 and 90 mins. |
09:10 |
csharp |
JBoyer: oh - awesome |
09:11 |
mdriscoll |
JBoyer: I'll try that, thanks! |
09:12 |
kmlussier |
JBoyer++ |
10:59 |
* gmcharlt |
goes *poof* for a brief meeting |
11:00 |
bshum |
OpenSRF 3.0 sounds fun. +1 |
11:01 |
JBoyer |
and mdriscoll: if you left the maintain_control_numbers trigger enabled, it's doing essentially the same thing as maintain_901, meaning it will only take half as long as letting both run, but it will be a lot faster if you disable all of the triggers for the duration of that script. |
11:01 |
miker |
meh, WORKSFORME is psql test on 9.4. the complaints seem to be about pgadmin. but the script is editable, so... to each site, their own |
11:02 |
Dyrcona |
mdriscoll: You're using Pg 9.4, right? |
11:02 |
mdriscoll |
JBoyer: ok will do. I was trying to disable as little as possible to see how long it would take. |
11:03 |
mdriscoll |
Dyrcona: yes Pg 9.4. |
13:19 |
gmcharlt |
the bit of JavaScript mentioned on the Koha wiki page can be plopped into webstaff's base_js.tt2 and just work |
13:20 |
jeffdavis |
thx Dyrcona |
13:20 |
Dyrcona |
gmcharlt: That "feature" apparently hasn't made it into Firefox 55 on Linux, or it is not on by default. |
13:21 |
gmcharlt |
Dyrcona: yeah, they seem to be doing A/B testing during the release, so I think it is on for some |
13:23 |
kmlussier |
gmcharlt++ |
13:23 |
gmcharlt |
and for those institutions that manage their deployments of Firefox to library staff, there's this - https://support.mozilla.org/en-US/questions/1168009 |
13:48 |
* csharp |
switches gears back to other acq issue where A/T is crapping out on undefined values |
14:34 |
pinesol_green |
jeffdavis: [opensrf|Bill Erickson] LP#1697029 Log and exit on write to dead child - <http://git.evergreen-ils.org/?p=OpenSRF.git;a=commit;h=a9cd124> |
14:34 |
jeffdavis |
That reset gets rid of the fixes for bug 1709710 (plus a few other things). |
14:34 |
pinesol_green |
Launchpad bug 1709710 in Evergreen "Default ejabberd max_stanza_size can be exceeded when chunking (MARC)XML-heavy responses" [Undecided,Confirmed] https://launchpad.net/bugs/1709710 |
14:35 |
jeffdavis |
I'll test more when things are calmer here. |
14:38 |
Dyrcona |
jeffdavis: I may be able to set up a test of OpenSRF rel_2_5 and Evergreen 2.12. (I assume you have the issue with 2.12.) |
14:38 |
Dyrcona |
I only tested the changes with master OpenSRF and master Evergreen. |
14:38 |
jeffdavis |
yeah, we're on 2.12.1 with some backports |
14:39 |
Dyrcona |
Well, I'd recommend going all the way to 2.12.5, but I know that can be difficult (not technically, but politically). |
14:40 |
Dyrcona |
Since I was just working on documentation to prepare for our upgrade next month, maybe I should put that aside and build the test vm now..... |
14:40 |
Dyrcona |
jeffdavis: You say had trouble with workstation registration. Anything else that I could try to reproduce? |
14:41 |
jihpringle |
Drycona: stat cats for one of our sites disappeared in the copy editor as well |
14:42 |
Dyrcona |
jihpringle: Thanks. |
15:02 |
jeffdavis |
I can email you the scripts I used it you like |
15:02 |
jeffdavis |
*if |
15:02 |
Dyrcona |
That's OK. I think I know what I need to do. |
15:03 |
Dyrcona |
I'm going to test upgrading OpenSRF but leaving Evergreen untouched, first. |
15:05 |
abneiman |
anyone else getting timeout errors from docs.evergreenils.org? the main page loads but links into the docs themselves are timing out for me. |
15:05 |
|
mmorgan1 joined #evergreen |
15:08 |
berick |
abneiman: site doesn't load at all for me |
15:43 |
Dyrcona |
So, after that I get a different error message. I'll save those logs, too. |
15:52 |
Dyrcona |
Register workstation seems to work in the web staff client, btw. |
15:54 |
jihpringle |
Drycona: we could register workstations in the web client too |
15:55 |
Dyrcona |
I'll open a bug for now. I want to test with a clean installation tomorrow. |
16:02 |
* bshum |
grumbles as he makes himself a new Mac client |
16:10 |
Dyrcona |
jeffdavis jihpringle: bug 1717350 |
16:10 |
pinesol_green |
Launchpad bug 1717350 in Evergreen "Upgrading to OpenSRF 2.5.1 appears to break XUL 2.12.5" [Undecided,New] https://launchpad.net/bugs/1717350 |
16:20 |
jeffdavis |
followed by the usua "Request Completed Successfully" + request time |
16:20 |
jeffdavis |
*usual |
16:20 |
jeffdavis |
I need to step away for a bit, happy to try more stuff later on |
16:20 |
berick |
huh |
16:20 |
berick |
thanks |
16:21 |
berick |
just trying to boil it down to the simplest possible test case |
16:23 |
Dyrcona |
berick: FWIW the first request above gives the same message in the lp bug. |
16:25 |
Dyrcona |
And I get the osrfResultPartialComplete exception for the second, so same as jeffdavis, more or less. |
16:26 |
* Dyrcona |
calls it a day. |
16:48 |
gmcharlt |
berick: yeah, I was just about to reproduce it by expanding aou |
16:49 |
bshum |
New staff client, hmm... |
16:49 |
berick |
i tried installing rel_2_12 on top of osrf master and cannot reproduce, fwiw |
17:01 |
pinesol_green |
News from qatests: Test Success <http://testing.evergreen-ils.org/~live> |
17:04 |
|
khuckins__ joined #evergreen |
17:05 |
miker |
berick: can't reproduce in srfsh, you mean? |
17:06 |
berick |
miker: i couldn't reproduce locally in srfsh or xul |
17:39 |
dbwells |
gmcharlt's bug is the killer, but FWIW, I think we also have another issue with that loop. We're looping until num_bytes, but still chunking on chars. Since bytes >= chars, the effect will be possible empty responses at the end of the loop (rather than missing data, and depending on chunk boundary), so not the end of the world. If anyone agrees with this diagnosis, I can open a bug about it for a future fix. |
17:39 |
gmcharlt |
dbwells: I think it's worth exploring |
17:40 |
miker |
yeah, breaking when the substr is empty seems sane |
17:43 |
dbwells |
Okay, I will try to concoct a test case and go from there. I'm not very familiar with this layer, so should be interesting at least :) |
17:45 |
miker |
hrm... I wonder if the C version is at risk of spliting 2+ byte utf8 chars ... I suspect so. I'll make a note to look at that first thing tomorrow. |
17:46 |
* miker |
shakes fist at the heavens, "U T F EEEEEEIIIIIGGGGGHHHHTTTTT!" |
17:53 |
miker |
actually, nevermind. we \u-encode 2+ byte chars |
02:47 |
|
Jillianne joined #evergreen |
04:03 |
|
gsams joined #evergreen |
05:02 |
pinesol_green |
News from qatests: Test Success <http://testing.evergreen-ils.org/~live> |
07:11 |
|
rjackson_isl joined #evergreen |
08:40 |
|
mmorgan joined #evergreen |
08:53 |
|
bos20k joined #evergreen |
09:03 |
|
mdriscoll joined #evergreen |
09:05 |
* csharp |
is about to test backporting non-Ruby EDI (bug 1373690) |
09:05 |
pinesol_green |
Launchpad bug 1373690 in Evergreen "Direct EDI generation for ACQ orders -- AKA kill ruby webrick" [Wishlist,Fix released] https://launchpad.net/bugs/1373690 |
09:06 |
csharp |
in part because, for whatever reason, A/T is breaking on creating JEDI |
09:07 |
|
_adb joined #evergreen |
09:36 |
|
jvwoolf joined #evergreen |
09:43 |
|
jvwoolf joined #evergreen |
09:48 |
|
kmlussier joined #evergreen |
09:55 |
berick |
csharp: i'm all ears! BTW, you probably saw this, but you have to enable direct generation for each edi_account now. |
09:56 |
berick |
so you can test by applying attrs while continuing traditional edi delivery |
09:59 |
csharp |
berick: good to know |
10:15 |
pinesol_green |
[evergreen|Galen Charlton] LP#1713160: fix crash viewing circ history in public catalog - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=461072d> |
10:21 |
|
mmorgan joined #evergreen |
13:04 |
csharp |
heh |
13:07 |
|
rlefaive joined #evergreen |
13:09 |
|
collum joined #evergreen |
13:12 |
roycroft |
hello, folks |
13:13 |
roycroft |
i'm curious - has there been any discussion of creating a virtual machine image of an evergreen platform for folks to use for testing/evaluation? |
13:13 |
roycroft |
i'm not complaining, but i've spent 3 hours doing an install so far, and i'm still working on the opensrf installation |
13:13 |
|
jihpringle_ joined #evergreen |
13:14 |
csharp |
roycroft: we used to have a couple out there, but not in years |
13:14 |
rhamby_ |
roycroft: there are a variety of ways to doing quick and dirty builds that are good for test systems but I wouldn't recommend them for production, I use an ansible script usually |
13:14 |
csharp |
it's a moving target and time-consuming to maintain :-/ |
13:14 |
roycroft |
i know that this is a vertical market app, and perhaps it's not evaluated as commonly as things like a cms |
13:14 |
roycroft |
so a vm image might not be as useful |
13:17 |
roycroft |
but if it's a slam dunk on jessie, perhaps i should go back and start over |
13:17 |
csharp |
oh - well, I would go with jessie or one of the Ubuntu LTS's |
13:17 |
roycroft |
i'm up to installing apache2-websockets |
13:18 |
berick |
roycroft: may be of interest: https://wiki.evergreen-ils.org/doku.php?id=server_installation:semi_automated |
13:18 |
berick |
i use the ansible installer (2nd from bottom) |
13:18 |
berick |
docker container is great for test machines too |
13:18 |
csharp |
roycroft: since it sounds like you're basically installing for evaluations, keep it simple and go with long-supported releases (jessie & Ubuntu 14.04) |
13:18 |
berick |
(when the build you want exists) |
13:23 |
roycroft |
yes, i'm beginning to think that would be a good idea |
15:07 |
berick |
so now you just have to keep trying over and over all day :) |
15:07 |
csharp |
ha! |
15:07 |
csharp |
yep |
15:23 |
mdriscoll |
I'm upgrading a test system to 3.0-beta1. The database has 2m bibs and 3m copies. The 2.12.5-3.0 upgrade script is taking a really long time (>24 hrs). |
15:23 |
mdriscoll |
The problem is with script 1057.schema.copy_vis_attr_cache.sql. I believe it is causing a reingest of every bib record. I'm wondering if there is a way around this. |
15:25 |
csharp |
d9fa69de |
15:25 |
pinesol_green |
csharp: [evergreen|Mike Rylander] LP#1698206: Eliminate Staged Search - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=d9fa69d> |
15:25 |
kmlussier |
mdriscoll: I don't think it's reingesting bib records, but I can confirm it takes a very long time based on an upgrade on a much smaller database that I did yesterday. |
15:34 |
berick |
kmlussier: yeah that's what i'm thinking, after we get a usable set of seed data |
15:34 |
mdriscoll |
csharp: thanks! |
15:37 |
|
mmorgan1 joined #evergreen |
15:49 |
Dyrcona |
I will test that upgrade fairly soon on a relatively well-tuned server. |
15:57 |
csharp |
same here |
15:58 |
csharp |
PINES libs are super excited about the web client and we're starting trainings week after next |
16:00 |
berick |
we've started some high level review sessions here |
16:47 |
csharp |
ate a lot of those during my recent vegetarian period |
16:47 |
berick |
hah |
16:48 |
berick |
lot of dark adjectives |
17:00 |
pinesol_green |
News from qatests: Test Success <http://testing.evergreen-ils.org/~live> |
17:07 |
|
jvwoolf left #evergreen |
17:11 |
|
mmorgan left #evergreen |
19:53 |
|
khuckins joined #evergreen |
03:50 |
|
HTTP_____GK1wmSU joined #evergreen |
03:53 |
|
HTTP_____GK1wmSU left #evergreen |
05:01 |
pinesol_green |
News from qatests: Test Success <http://testing.evergreen-ils.org/~live> |
06:02 |
|
kmlussier joined #evergreen |
07:17 |
|
rjackson_isl joined #evergreen |
07:43 |
|
Dyrcona joined #evergreen |
15:01 |
|
Jillianne joined #evergreen |
15:03 |
|
mmorgan1 joined #evergreen |
15:17 |
* berick |
has also had the missing cursor issue |
15:25 |
Dyrcona |
One of the negative balance live tests fails for me on Concerto. It's test 90. |
15:26 |
Dyrcona |
Also, I think we have two live tests with the same number again. |
15:26 |
Dyrcona |
Yeah, two 24s. |
15:30 |
bshum |
And two 20s |
15:31 |
Dyrcona |
you're right. I missed the 2 20s. |
15:32 |
Dyrcona |
It's not a big deal, but what's the point of numbering them. |
15:32 |
bshum |
Isn't that some tests have to run sequentially? |
15:33 |
Dyrcona |
Could be that. |
15:33 |
Dyrcona |
I'm just saying if we duplicate numbers, then why number them? ;) |
15:34 |
Dyrcona |
Anyway, I did login and do a search prior to running prove, so I've reloaded a fresh db and will try again. |
15:34 |
Dyrcona |
I also ran make check, but that doesn't do the live tests. |
15:34 |
bshum |
That's probably a good idea. I think login could goof something up like if you register a workstation ahead of whatever they add during the test |
15:36 |
Dyrcona |
It passed this time. |
15:36 |
berick |
the live tests have chaotic consequences. until we have a system that does a full data rollback (a la pgtap) with each test we have to guarantee an order. |
15:37 |
Dyrcona |
I know that. I'm being rhetorical, sort of... :) |
15:37 |
bshum |
So... branch needed to rename the tests in a proper order? :D |
15:37 |
Dyrcona |
Guess someone (me) should open a LP bug to renumber them. |
15:38 |
berick |
Dyrcona: ah, i'm being too literal |
15:38 |
Dyrcona |
Or, bshum can open it. That works for me. :) |
15:41 |
Dyrcona |
Anyway, Evergreen now runs on Debian 9. bshum++ |
15:41 |
berick |
woot |
15:42 |
Dyrcona |
I should make sure the lib naming changes don't break anywhere else, but it shouldn't. |
15:42 |
bshum |
Yeah I'll test the new commit too for Debian 9 but also apply it on my next Ubuntu 16 test build just in case |
15:42 |
bshum |
Dyrcona++ |
15:43 |
bshum |
Maybe those changes will help get it working for Fedora again, hehe :) |
15:43 |
Dyrcona |
Shouldn't hurt. |
15:43 |
Dyrcona |
It's always better not to fight the tools. |
15:43 |
roycroft |
hello, folks |
16:06 |
Dyrcona |
roycroft: You'll need to convert the CSV to MARC. |
16:06 |
roycroft |
there's a library system that covers most of eastern oregon (i'm in western oregon) who use evergreen, and folks seem to think it's a really nice package, which is what got me looking at it in the first place |
16:06 |
roycroft |
so csv to incomplete marc, and then evergreen can get the full marc records? |
16:06 |
Dyrcona |
Also, if you want to test on stretch use the branches on the bug I referenced earlier. |
16:07 |
roycroft |
ok, i'll do that |
16:07 |
gmcharlt |
yeah, Evergreen doesn't have a direct script to batch-import records from a Z39.50 source, but here's another tool that can do it: http://marcedit.reeset.net/batch-marc-record-retrieval-using-z39-50 |
16:07 |
Dyrcona |
They're basically the beta for 3.0. |
16:32 |
Dyrcona |
Mr. Kent seems much happier, now. |
16:36 |
miker |
Dyrcona: confirmed, yes it's fine |
16:37 |
Dyrcona |
miker: Thanks. That's what I thought and what it looks like from here. ;) |
16:38 |
* Dyrcona |
actually makes a note to that when updating the data for the training and testing servers.....Typing it in will help me remember. |
16:39 |
* Dyrcona |
imagines 62 zombie Supermen running around Gotham or whatever city Superman supposedly lives in. |
16:41 |
gmcharlt |
clark-kent.pl ought to change its process name to 'Bizarro' just before terminating |
16:55 |
Dyrcona |
I noticed that Clark still doesn't daemonize properly. It writes messages to the console, still. |
16:56 |
* Dyrcona |
search for a LP bug on that. |
17:02 |
pinesol_green |
News from qatests: Test Success <http://testing.evergreen-ils.org/~live> |
17:03 |
kmlussier |
abneiman: The silent failure bug you just filed, is that the import marc permission or the create or update marc permission? |
17:04 |
* kmlussier |
is wondering if it's the same as bug 1693580 or something different. |
17:04 |
pinesol_green |
Launchpad bug 1693580 in Evergreen "web client: attempting to update a MARC record without required permissions fails without feedback to the user" [Undecided,New] https://launchpad.net/bugs/1693580 |
19:48 |
|
_adb1 joined #evergreen |
19:48 |
|
pastebot0 joined #evergreen |
19:54 |
|
berick joined #evergreen |
20:37 |
bshum |
berick: I added a couple tweaks for the ansible installer here: http://git.evergreen-ils.org/?p=working/random.git;a=shortlog;h=refs/heads/collab/bshum/ansible-installer-ubuntu-16.04 |
20:37 |
bshum |
berick: It changes the ejabberd config back to default max_stanza_size and adds the rpaf apache module install for nginx |
20:38 |
bshum |
I used it to test a clean installation using the Debian9 changes from Dyrcona for libaries. Looks like everything works with the changes. |
21:12 |
|
jvwoolf joined #evergreen |
21:22 |
|
jvwoolf joined #evergreen |
21:31 |
|
jvwoolf left #evergreen |
05:00 |
pinesol_green |
News from qatests: Test Success <http://testing.evergreen-ils.org/~live> |
06:26 |
|
barbara joined #evergreen |
06:33 |
|
barbara_ joined #evergreen |
13:31 |
|
Dyrcona joined #evergreen |
13:53 |
Dyrcona |
@monologue |
13:53 |
pinesol_green |
Dyrcona: Your current monologue is at least 21 lines long. |
14:05 |
Dyrcona |
Well, my search for keyword mozart is still broken. |
14:15 |
Dyrcona |
So, a 2 core vm with 4GB of RAM is no longer enough to test Evergreen....Just my opinion based on today's frustrations. |
14:19 |
bshum |
Hmmm, crazy |
14:21 |
Dyrcona |
I keyword search for mozart and get a cstore time out in the logs. |
14:21 |
Dyrcona |
harry potter on the other hand comes back almost instantly with the 1 record. |
14:26 |
Dyrcona |
I'm working on code to place multiple holds for a single title. |
14:26 |
Dyrcona |
Everything works so far except for actually placing the multiple holds. It's still only placing 1. |
14:27 |
Dyrcona |
oops. last two lines are in the wrong tab, but it's no secret what I'm working on. :) |
14:32 |
Dyrcona |
The tests work, so the backend changes are "correct." I'm stuck on getting the places hold logic in EGCatloader to pass the message correctly. |
16:05 |
Dyrcona |
Well, search is still messed up on my vm, even after a fresh db reload and the git clean -xfd and a rebuild. |
16:06 |
Dyrcona |
I've tried mozart and brahms and they don't return anything with an occasional Internal server error from a cstore timeout. |
16:06 |
Dyrcona |
harry potter with just 1 record comes right back, though. |
16:06 |
Dyrcona |
Guess I'll blow this vm out, too. :( |
16:07 |
Dyrcona |
I did figure out my issue with placing multiple holds. I've got more work to do, and I may possibly rearrange the code that I've written. |
17:01 |
pinesol_green |
News from qatests: Test Success <http://testing.evergreen-ils.org/~live> |
19:45 |
pinesol_green |
[evergreen|Jillianne Presley] Docs reorg: adding acquisitions manual - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=a1c75a7> |
20:32 |
|
Jillianne joined #evergreen |
21:37 |
|
Badman240 joined #evergreen |
21:38 |
Badman240 |
Hey guys, I'm really new to ILS software and was planning to use it for a library of about ~1000 books for my sunday school |
00:18 |
|
remingtron_ joined #evergreen |
04:32 |
pinesol_green |
News from qatests: Test Success <http://testing.evergreen-ils.org/~live> |
05:10 |
|
rlefaive joined #evergreen |
06:01 |
|
rlefaive joined #evergreen |
06:24 |
|
rlefaive joined #evergreen |
09:52 |
Dyrcona |
Been a long time since I tried 32-bit and that was just to see if it would install. |
09:53 |
rkw |
Dyrcona: I'm new enough that the install experience will help, so like you, I just want to see if I can do 32-bit while the 64-bit downloads |
09:55 |
Dyrcona |
Last time I had a library issue, I just munged the makefiles. |
09:55 |
dbwells |
In my case, I fired up an older server a few months ago in laziness to do a test install, had no recollection it was 32-bit, then was majorly confused for longer than I care to admit :) |
09:57 |
Dyrcona |
I haven't installed on 14.04 for a while, either, for that matter. I'm mostly using Ubuntu 16.04 and Debian 8. |
09:58 |
pinesol_green |
[evergreen|Galen Charlton] start work on 3.0 release notes - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=2da1e4f> |
09:58 |
pinesol_green |
[evergreen|Galen Charlton] add organizations who sponsored develpoment written by Equinox - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=fa4fe4f> |
14:27 |
sandbergja |
2) Updating the script on the production docs server to generate the new, reorganized manuals based on the root_*.adoc files |
14:27 |
sandbergja |
3) Lots and lots of cleanup :-) |
14:28 |
kmlussier |
sandbergja: I assume Robert hast to take care of #2? |
14:29 |
sandbergja |
kmlussier: I think so. There's a reorganized-documentation-generator script on the docs testing server that would just need a few modifications. |
14:31 |
kmlussier |
OK, so I guess we need to coordinate a bit to make sure he can update the script right after the new root file is added. |
14:32 |
sandbergja |
I believe that the current script would just ignore the new files, so it wouldn't be terrible if there were a lag between 1 and 2. |
14:32 |
sandbergja |
But doing 2 before 1 would cause problems. :-) |
16:14 |
jeffdavis |
kmlussier: did MassLNC ever get anywhere with new feature dev on allowing other patrons to pick up a patron's holds? |
16:15 |
kmlussier |
jeffdavis: bug 1661688 |
16:15 |
pinesol_green |
Launchpad bug 1661688 in Evergreen "Want easy way to clear a hold when picked up by other patron" [Wishlist,New] https://launchpad.net/bugs/1661688 - Assigned to Dan Pearl (dpearl) |
16:15 |
kmlussier |
C/W MARS is working on it, but there was an issue when I tested it. |
16:46 |
|
Jillianne joined #evergreen |
17:02 |
pinesol_green |
News from qatests: Test Success <http://testing.evergreen-ils.org/~live> |
17:05 |
|
mmorgan left #evergreen |
17:10 |
|
jvwoolf left #evergreen |
17:30 |
|
dbwells joined #evergreen |
01:52 |
|
abowling joined #evergreen |
02:01 |
|
jonadab joined #evergreen |
02:46 |
|
tsbere joined #evergreen |
05:00 |
pinesol_green |
News from qatests: Test Success <http://testing.evergreen-ils.org/~live> |
06:05 |
|
ohiojoe joined #evergreen |
06:38 |
|
rlefaive joined #evergreen |
07:05 |
|
JBoyer joined #evergreen |
07:14 |
|
rjackson_isl joined #evergreen |
07:39 |
|
agoben joined #evergreen |
08:28 |
csharp |
berick: your latest suggestion is working for me on a test server, but not on production - gonna look into why - thanks |
08:35 |
csharp |
and, looks like browser cache was the problem - working now |
08:35 |
csharp |
berick++ |
08:41 |
|
mmorgan joined #evergreen |
08:45 |
|
mmorgan left #evergreen |
08:49 |
|
mmorgan joined #evergreen |
09:57 |
berick |
$apache->log->info('forwarded for: ' . $apache->headers_in->{'HTTP_X_FORWARDED_FOR'}); |
09:58 |
berick |
the forwarded for header would be better to use ultimately since it works with intermediate proxies |
09:59 |
berick |
(no rush, i know you just upgraded) |
10:04 |
csharp |
berick: on my test server, looks like it's null |
10:04 |
csharp |
2017-09-06 10:03:59 next-brick01-head gateway: [perl:info] [pid 22961] [client 127.0.0.1:40254] forwarded for: |
10:06 |
berick |
csharp: huh. you have this in your nginx config? |
10:06 |
berick |
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; |
10:07 |
berick |
under the various 'location' sections |
13:07 |
JBoyer |
\me despairs at the above scrollback. |
13:07 |
* JBoyer |
tires of me |
13:08 |
* Dyrcona |
wonders how the proxy works with load balancers. I suppose the proxy is done on each brick head? |
13:08 |
JBoyer |
csharp, to simplify things, if your test system for the Acq issue is using NFS is it possible to turn that off to see if things work or the message changes? |
13:19 |
csharp |
JBoyer: strangely, I'm not able to duplicate it at the moment, so I'm going to have to wait until my coworker returns from an errand :-/ |
13:19 |
csharp |
but that's a good idea to just remove NFS to see whether that's the issue |
13:20 |
csharp |
I actually might need to rule out perms as the cause |
15:08 |
gmcharlt |
Dyrcona: any updates on investigating GitLab? |
15:08 |
Dyrcona |
No. I've not really had the time. |
15:08 |
gmcharlt |
fair enough |
15:08 |
Dyrcona |
I still have a gitlab test vm running, though |
15:08 |
Bmagic |
#info Bmagic = Blake GH, MOBIUS |
15:09 |
* gmcharlt |
is thinking that I might help out with that process after release of 3.0.0 |
15:09 |
gmcharlt |
#info gmcharlt sent out proposed XUL bugfix merge policy for 3.0 - thread here: http://libmail.georgialibraries.org/pipermail/open-ils-dev/2017-August/010400.html |
15:20 |
JBoyer |
miker, gmcharlt, would it be unreasonable to strive for a "./configure;make;make install" style installation for 2.6 while we're making big changes anyway? I know that was mentioned in the Gentoo thread and it immediately caught my attention. |
15:20 |
|
stephengwills joined #evergreen |
15:20 |
gmcharlt |
at least as far as the C libraries are concerned, it should be pretty clearly something that either works or doesnt work |
15:21 |
miker |
JBoyer: if we can have a beta 2 with stretch support, for a solid-ish test period, would you be OK with that? (also, we can always pull back with a simple enough change if release day is looming and we're still seeing problems) |
15:22 |
berick |
in general terms, having to rebuild osrf to install eg 3.0 does not seem crazy to me. |
15:22 |
miker |
Dyrcona: right ... we're going out of our way to have .so's named just so, and ldconfig hates us for that |
15:23 |
miker |
libtool writes symbols /inside/ the file, too, though. we need to not override that, not just the filesystem name |
15:23 |
JBoyer |
miker, it's ok with me; I don't run Debian. ;) I just want to make sure there's plenty of time for testing and it does *feel* like early days, admittedly for the previous reason. |
15:24 |
Dyrcona |
If stretch support can wait until after the beta, I'll make it a point to look at those bugs next week. |
15:25 |
miker |
JBoyer: re './configure;make;make install', how do you mean? I feel like it's pretty much that already, no? |
15:25 |
gmcharlt |
Dyrcona: yeah, it can certain wait until after today's beta |
15:50 |
Bmagic |
At the last hack-a-way, there was talk of getting folks up to speed on contributing to the project. Thoughts of adding another day to the hack-a-way of "class". I have been working on some videos with that in mind |
15:51 |
Bmagic |
Maybe some videos would help get folks started, not a replacement of "class" but something. I just thought I would bring it up here for thoughts. |
15:53 |
berick |
i haven't watched the videos yet, but I love the idea |
15:53 |
Bmagic |
One of the big hurdles, is installing the Evergreen server. My direction here is to skip that part and show how to get a test server running with almost no effort |
15:54 |
Bmagic |
Then show how to edit the code on the running server and affect change, using easy-to-install tools for windows |
15:54 |
Dyrcona |
I have seen the videos, and other than the Windows part, I like 'em. ;) |
15:55 |
kmlussier |
Bmagic++ |
16:59 |
Dyrcona |
That's the description. |
17:00 |
mmorgan |
Oh, that won't help, then. :-( |
17:00 |
Dyrcona |
It never seems to be exactly what the members want. |
17:00 |
pinesol_green |
News from qatests: Test Success <http://testing.evergreen-ils.org/~live> |
17:00 |
Dyrcona |
Well, I'm taking off. Catch everyone tomorrow. |
17:01 |
mmorgan |
Well, if holds don't capture exacly chronologically, if they're placed close together, it hasn't been a big deal, but this example seemed a little less than fair. |
17:02 |
* mmorgan |
needs to revisit with a fresh eye tomorrow. |
05:01 |
pinesol_green |
News from qatests: Test Success <http://testing.evergreen-ils.org/~live> |
05:51 |
|
jonadab joined #evergreen |
07:11 |
|
rjackson_isl joined #evergreen |
08:29 |
|
collum joined #evergreen |
14:13 |
csharp |
I would hate to spoil it with my tinkering :-) |
14:13 |
csharp |
berick: yeah |
14:13 |
berick |
awesome |
14:13 |
csharp |
2.12.4 |
14:14 |
csharp |
would've gone with .5, but we didn't have time to fully test it |
14:14 |
csharp |
will probably backport some of those patches |
14:14 |
berick |
csharp++ # expanding the nginx testing |
14:14 |
berick |
s/testing/using and fixing/ |
14:15 |
csharp |
berick++ Dyrcona++ jeffdavis++ # sharing expertise ;-) |
14:24 |
terran |
For everybody who got to go to Hood River for the Evergreen Conference: http://www.wweek.com/news/2017/09/05/multnomah-falls-engulfed-in-flames-as-out-of-control-wildfire-races-west-through-gorge/ |
14:26 |
Bmagic |
omg |
14:38 |
csharp |
uncommenting RPAFheader X-Real-IP has not fixed it |
14:38 |
berick |
csharp: rpaf's not updating REMOTE_ADDR |
14:38 |
berick |
heh, i tried that too |
14:38 |
csharp |
I'll have to transfer everything to a test server and enable debug logs to do much more |
14:38 |
berick |
my $user_ip = $ENV{'HTTP_X_FORWARDED_FOR'} || $ENV{REMOTE_ADDR}; |
14:39 |
berick |
that just worked on my test server |
14:39 |
csharp |
berick: where did you add that? |
14:40 |
csharp |
oh - I see |
14:40 |
csharp |
Redirect.pm |
14:40 |
|
terran joined #evergreen |
14:41 |
csharp |
berick: any changes to rpaf.conf? or should it Just Work™ |
14:41 |
berick |
no rpaf changes. that's basically bypassing rpaf |
14:41 |
csharp |
ok good |
15:01 |
csharp |
still not working for me, but I'm going to have to put it aside for now |
15:01 |
csharp |
berick++ |
15:01 |
csharp |
I'll set up a test server to experiment with |
15:34 |
|
sandbergja joined #evergreen |
15:54 |
gmcharlt |
reminder - the next deveopment meeting is tomorrow at 15:00 EDT / 12:00 PDT |
15:54 |
gmcharlt |
agenda here: working/user/cesardv/lp1145213-bib_merge_func_merge_record_assets-signoff |
15:54 |
pinesol_green |
[evergreen|Jason Boyer] LP1714589: Use Explicit Definition for aacs - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=fbda8c2> |
15:54 |
berick |
csharp: that assumes nginx is passing the X-Real-IP header (which it does in the sample osrf config) |
16:18 |
|
sandbergja joined #evergreen |
17:00 |
pinesol_green |
News from qatests: Test Success <http://testing.evergreen-ils.org/~live> |
17:05 |
|
mmorgan left #evergreen |
17:49 |
|
kmlussier joined #evergreen |
18:05 |
|
Jillianne joined #evergreen |