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 |
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 |
05:01 |
pinesol_green |
News from qatests: Test Failure <http://testing.evergreen-ils.org/~live> |
09:42 |
bshum |
gmcharlt: I added POT updates to working branch user/bshum/20170902-i18n-pot-sync |
09:43 |
bshum |
There's a few areas I'm still reviewing, the one that I question most is this in one in Open-ILS/src/templates/staff/base_js.tt2 |
09:43 |
bshum |
msgid "{{location_name}} ({{owning_lib_shortname}})" |
09:44 |
bshum |
Just another case where we only seem to be sending the variable names for translation. And the PO not likely to ever contain the actual values for those variables, so eh... |
10:14 |
* bshum |
reads up on PO filter and various tests we could try to use to validate our PO files to prevent i18n mishaps... http://docs.translatehouse.org/projects/translate-toolkit/en/latest/guides/using_pofilter.html |
11:00 |
|
Dyrcona joined #evergreen |
11:01 |
Dyrcona |
So, I upgraded one of my development branches with latest master this morning. |
11:01 |
Dyrcona |
I did a fresh load of concerto, and I'm getting no search joy. |
11:24 |
Dyrcona |
Ran the mozart search again... |
11:24 |
bshum |
gmcharlt: I suppose so, or we just need to make a note for new i18n practice to ignore anything in {{variable}} and that should be good too |
11:25 |
gmcharlt |
yeah |
11:25 |
bshum |
I just finished building a new test server based on the branch with the POT changes and it seems to be perfectly fine to me |
11:25 |
bshum |
I think we can safely push it in for now and figure out next steps |
11:25 |
gmcharlt |
and arguably, {{username}} gives a translator more of a fighting chance to figure context than a bare [_1] |
11:25 |
bshum |
Yeah I get the argument, but I also don't think it's realistic that any actual values would ever end up in the PO file that way |
11:26 |
pinesol_green |
[evergreen|Galen Charlton] LP#1251394: fix typo in seed data caugh by t/24-sql-gettext-unique.t - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=d5fe1cc> |
14:14 |
Dyrcona |
I wonder if that person asking on the ejabberd forum ever got help? They mention OpenSRF in their post. |
14:15 |
Dyrcona |
yay! OpenSRF works. :) |
14:15 |
Dyrcona |
And company just arrived, so got to go, again. |
17:01 |
pinesol_green |
News from qatests: Test Success <http://testing.evergreen-ils.org/~live> |
18:33 |
|
cucumberjoe joined #evergreen |
05:00 |
pinesol_green |
News from qatests: Test Failure <http://testing.evergreen-ils.org/~live> |
06:57 |
|
kmlussier joined #evergreen |
07:14 |
|
rjackson_isl joined #evergreen |
08:24 |
* kmlussier |
just tried cherry picking a patron barcode number. |
11:37 |
|
jvwoolf1 joined #evergreen |
12:16 |
|
jihpringle joined #evergreen |
12:17 |
|
yboston joined #evergreen |
12:21 |
gmcharlt |
I'd like to request one more pair of eyes on bug 1710949, which I've tested and signed off on |
12:21 |
pinesol_green |
Launchpad bug 1710949 in Evergreen "A one-call login API would be swell" [Wishlist,New] https://launchpad.net/bugs/1710949 |
12:39 |
berick |
gmcharlt++ |
12:50 |
pinesol_green |
Showing latest 5 of 17 commits to Evergreen... |
13:02 |
miker |
gmcharlt: I'll take the login api |
13:02 |
gmcharlt |
miker++ |
13:02 |
gmcharlt |
dbwells++ |
13:08 |
pinesol_green |
[evergreen|Bill Erickson] LP#1710949 open-ils.auth.login API - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=18b313d> |
13:08 |
pinesol_green |
[evergreen|Bill Erickson] LP#1710949 auth.login Perl live test script - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=3bc96cf> |
13:08 |
pinesol_green |
[evergreen|Bill Erickson] LP#1710949 Redact open-ils.auth.login params - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=d067a00> |
13:08 |
pinesol_green |
[evergreen|Bill Erickson] LP#1710949 Release notes for auth.login - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=f1f6489> |
13:08 |
pinesol_green |
[evergreen|Galen Charlton] LP#1710949: add tests for blocking after failed attempts - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=cd22fa0> |
13:14 |
miker |
grabbing 1062-1067 |
13:18 |
miker |
I'm going to stamp a couple forgotten upgrade scripts |
13:24 |
dbwells |
miker: ack, darn, that would be me. Thanks. |
15:11 |
pinesol_green |
[evergreen|Galen Charlton] LP#1688398: some tidying - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=0efd7b6> |
15:11 |
pinesol_green |
[evergreen|Galen Charlton] LP#1688398: add release notes - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=9ede1f1> |
15:11 |
pinesol_green |
[evergreen|Galen Charlton] LP#1582354: put release notes entry in proper directory and fix typo - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=6e64e97> |
15:13 |
berick |
jeffdavis: gmcharlt: i have ebook_api service running (tests pass) and ebook settings enabled in config.tt2 (including test mode). i do see the ebook counts in my account. what else should I be seeing? possible to perform actions in test mode? |
15:21 |
berick |
ah, cool, i'm getting some useful error logs. |
15:21 |
gmcharlt |
not sure about what test mode permits (I'd borrowed test OverDrive credentials) |
15:21 |
berick |
gmcharlt: *nod* thanks |
15:23 |
jeffdavis |
catalog search for Tolkien, you should see some sample records with URIs like http://example.com/ebookapi/t/001 ; those records should display ebook holdings info and a "Check Out E-Item" or "Place Hold on E-Item" link; clicking on those should (after OPAC login) take you to a page with a button for checking out or placing a hold |
15:23 |
|
abowling joined #evergreen |
15:25 |
berick |
jeffdavis: Tolkien returns zero results. they were added to the concerto data set? |
15:25 |
kmlussier |
gmcharlt: OK, then, is it possible that anything in the database bits of the authority branch that could affect being able to log into the web client? It worked fine this morning when I was testing on an ugpraded database. |
15:25 |
kmlussier |
It's the only branch I have on that VM outside of current master. Everything else looks great. |
15:26 |
jeffdavis |
berick: They're there for me. I'm currently not seeing any titles with located URIs but no physical holdings. |
15:26 |
kmlussier |
https://mlnc4.noblenet.org/eg/staff/ is the page. It doesn't fully load in Chrome. In Firefox, it loads, but I can't log in. |
15:26 |
jeffdavis |
er, non-web-client searches return 0 results for me if all the results only have located URIs but no physical copies |
15:28 |
kmlussier |
berick: They're located URIs, so you have to scope your search in the public catalog. |
15:28 |
kmlussier |
Oh, sorry, jeffdavis already mentioned the Located URIs. |
15:29 |
berick |
kmlussier: ah, ok. i didn't put all the pieces together |
15:31 |
jeffdavis |
In the Tolkien records the URI is scoped to CONS but they don't show up in a CONS-scoped OPAC search. Ditto for manually created records with CONS-scoped URIs. |
15:32 |
jeffdavis |
I don't think that's an issue with the ebook code (which doesn't touch search results until the page has been rendered) but I haven't had a chance to test more yet. |
15:32 |
abneiman |
kmlussier: FWIW I can get mlnc4 to load in Chrome, but I get nothing when I try to log in. |
15:34 |
kmlussier |
I can now too, but I'm guessing that's because gmcharlt is performing some kind of magic spell. |
15:34 |
berick |
jeffdavis: thanks. i have enough here to get a sense of things. |
15:35 |
gmcharlt |
kmlussier: try again now; apache2-websockets needed to be bounced |
15:36 |
kmlussier |
gmcharlt: Sigh. Ok, I checked to make sure they were running, but did nothing else. Sorry about that. |
15:39 |
jeffdavis |
berick: and getting back to the original question, in theory clicking the Checkout button should result in a message like "Item has been checked out" and your checkout count being incremented temporarily. The EbookAPI::Test handler has hardcoded responses so it will only authenticate for patron 99999359616, checkout will always and only succeed with item 003, etc |
15:39 |
jeffdavis |
item 003 = title with URI http://example.com/ebookapi/t/003 |
15:40 |
jeffdavis |
I should of course document this more thoroughly somewhere. |
15:41 |
pinesol_green |
[evergreen|Ben Shum] LP#1710991: Do not translate username and workstation in webclient navbar - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=df79b43> |
15:48 |
berick |
jeffdavis: nice! i have actions |
15:50 |
* kmlussier |
clears her throat |
16:16 |
berick |
kmlussier: your commits are in there, just buried.. happened at essentially the same time |
16:16 |
berick |
"latest 5 of 39" .. i think i merged about 20 |
16:17 |
kmlussier |
Ah, well. They're both good causes. |
16:32 |
pinesol_green |
News from qatests: Test Failure <http://testing.evergreen-ils.org/~live> |
16:40 |
* gmcharlt |
takes a look at those |
17:03 |
miker |
great news everyone! display fields rebases over master-with-authority without any conflicts! |
17:03 |
kmlussier |
miker++ |
17:03 |
kmlussier |
Of course, that means you could have looked at it hours ago miker. |
17:03 |
gmcharlt |
currently doesn't account for possiblity that imported_as can be null |
17:04 |
miker |
gmcharlt: point me at a commit, I shall pick it |
17:04 |
Bmagic |
just created the much-wanted regression test on bug 1411422 |
17:04 |
pinesol_green |
Launchpad bug 1411422 in Evergreen 2.12 "Copy details repeated in search results when item/volume moved with parts attached" [Medium,Confirmed] https://launchpad.net/bugs/1411422 |
17:04 |
kmlussier |
Oooh! |
17:06 |
Bmagic |
funny, creating that test actually uncovered a potential bug. LOL, I guess that's what those tests are for, huh? |
17:07 |
pinesol_green |
[evergreen|Cesar Velez] LP#1599894 - OPAC disable Add to MyList when doing metabib search - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=3a14a50> |
17:07 |
gmcharlt |
miker: user/gmcharlt/fix_vii_inh_fkey |
17:07 |
miker |
gmcharlt: thanks, looking |
17:11 |
gmcharlt |
miker: :) I've updated the branch |
17:11 |
miker |
it is known |
17:11 |
* miker |
also grabs 1075 |
17:12 |
gmcharlt |
Bmagic: Open-ILS/src/sql/Pg/t/regress/lp1629108_metarecord_constituent_result_reroute.pg |
17:12 |
gmcharlt |
am I understanding correctly that the partiuclar value of source_list doesn't actually matter for hte purpose of the test? |
17:12 |
Bmagic |
gmcharlt: I was looking at that as well |
17:13 |
Bmagic |
yes, those ID numbers were* the constituent records on concerto once upon a time |
17:13 |
gmcharlt |
they're still showing up -- but the order of the ids in source_list appears to be varying |
17:13 |
Bmagic |
that would break the test for sure |
17:14 |
Bmagic |
STRING_AGG(x.id::TEXT, ',') AS source_list doesn't enforce an order.... so I suppose the test shouldn't expect it to be in order |
17:14 |
gmcharlt |
yeah |
17:14 |
gmcharlt |
OK, I'll work up a patch right quick |
17:14 |
Bmagic |
ty |
17:19 |
pinesol_green |
[evergreen|Galen Charlton] LP#1152753: upgrade script - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=0161aef> |
17:19 |
pinesol_green |
[evergreen|Mike Rylander] Stamping upgrade scripts for Display Fields and Vandelay regression - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=b930174> |
17:20 |
gmcharlt |
Bmagic: bug 1714594 |
17:20 |
pinesol_green |
Launchpad bug 1714594 in Evergreen "lp1629108_metarecord_constituent_result_reroute.pg test failure" [Medium,New] https://launchpad.net/bugs/1714594 |
17:21 |
* Bmagic |
looks |
17:22 |
Bmagic |
gmcharlt: looks like a great solution |
17:22 |
gmcharlt |
are you in a position to test it right now? |
17:22 |
Bmagic |
You could ditch the "sfaf" off the tail of the success message while you are at it |
17:22 |
Bmagic |
yes, I can teset |
17:22 |
Bmagic |
/teset/test |
17:22 |
gmcharlt |
thanks! (and feel free to get rid of the sfaf in your signoff patch) |
17:23 |
Bmagic |
it will be a few minutes, I gotta get the pgtap stuff installed |
17:24 |
gmcharlt |
kk |
17:43 |
kmlussier |
gmcharlt++ #For all the 3.0 things! |
17:43 |
kmlussier |
Have a nice weekend everyone! |
17:43 |
pinesol_green |
[evergreen|Jason Boyer] LP1714512: Patron Edit Barcode Validation - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=f70f6f6> |
17:45 |
gmcharlt |
Bmagic: the second test, specifically? |
17:46 |
Bmagic |
yes, I commented it out, and I have success. So at least I know that my pgtap stuff is doing it's thing |
17:46 |
Bmagic |
doing some manual checking |
17:47 |
Bmagic |
wait a minute, I thought we addressed this already |
17:51 |
Bmagic |
select metarecord,count(*) from metabib.metarecord_source_map group by 1 having count(*) > 1; |
17:55 |
gmcharlt |
select metarecord,array_agg(source) from metabib.metarecord_source_map group by 1 having count(*) > 1; |
17:56 |
gmcharlt |
that gives me {242,243,244} for 240 in a stock DB |
18:00 |
Bmagic |
yep, I have that in my data, my problem is the function on my test db |
18:01 |
Bmagic |
Sorry, I'm not much help. Does the test work for you? |
18:04 |
gmcharlt |
it does - I'll think I'll just go ahead and push it for a clean testbed |
18:06 |
gmcharlt |
and with that, I'm out for now. have a good weekend, all! |
18:07 |
pinesol_green |
[evergreen|Galen Charlton] LP#1714594: fix lp1629108_metarecord_constituent_result_reroute.pg - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=0bef0c2> |
00:31 |
pinesol_green |
[evergreen|Cesar Velez] LP#1695029-Webstaff Fix Patron Registration page never loading - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=688e8e1> |
00:31 |
pinesol_green |
[evergreen|Bill Erickson] LP#1695029 Patron reg. supports bool opt-in defaults - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=edc503b> |
05:00 |
pinesol_green |
News from qatests: Test Failure <http://testing.evergreen-ils.org/~live> |
06:57 |
|
agoben joined #evergreen |
07:15 |
|
rjackson_isl joined #evergreen |
07:55 |
|
kmlussier joined #evergreen |
12:05 |
|
jihpringle joined #evergreen |
12:10 |
kmlussier |
miker / gmcharlt: Would either of you have tuits to rebase bug 1676608 against current master? |
12:10 |
pinesol_green |
Launchpad bug 1676608 in Evergreen "Copy Alert Persistence and Suppression Matrix" [Wishlist,New] https://launchpad.net/bugs/1676608 |
12:10 |
kmlussier |
I should have time to test it this afternoon. There were conflicts in a lot of files, which made me nervous about resolving them myself. |
12:11 |
Dyrcona |
msh: You can't really get it from the staff client. You can really only see the last two or so who have checked out an item. |
12:11 |
miker |
kmlussier: I can take a look, yes |
12:11 |
kmlussier |
miker++ |
13:07 |
berick |
but still, 30 mins is not OK |
13:07 |
Dyrcona |
Well, and nothing else going on, yeah. :) |
13:07 |
berick |
that too |
13:07 |
csharp |
nothing much going on on my test server at 6 a.m. either ;-) |
13:08 |
Dyrcona |
Test servers are just slow.... Witness my circulation aging attempts. :) |
13:08 |
Dyrcona |
Some kind of unwritten law of computer science. :) |
13:08 |
csharp |
well, I haven't looked lately, but I know we have complaints about slow loading in acq vandelay in general |
13:08 |
csharp |
but I agree that 30 mins is kinda crazy |
13:22 |
berick |
yeah, creating those queued bib recs is slow |
13:23 |
Dyrcona |
TBH, I eschew Vandelay. I've always considered it to be too slow. |
13:23 |
* csharp |
would love to not bother with it but our acq libs need it |
13:24 |
berick |
csharp: maybe time to explain/analyze one of the those queued_bib_record INSERTs |
13:25 |
berick |
updates taking as long too. that might be easier to test. |
13:27 |
Dyrcona |
Yeah.... |
13:29 |
Dyrcona |
Probably some trigger is taking way too long. |
13:30 |
berick |
look for the trigger that calls pg_sleep(16) |
13:39 |
berick |
wonder how many rows are inserted into vandelay.bib_match for each of these records. |
13:40 |
Dyrcona |
Also, how long does vandelay.measure_record_quality take? Looks like it could be run twice. |
13:41 |
Dyrcona |
Ah. I see why it's called twice. Different records. |
13:44 |
miker |
kmlussier: ok, I have a rebased branch that I think is fully resolved. However, if testing goes well, I think a good bit of squashing is in order. pushing the branch now.... |
13:46 |
miker |
kmlussier: http://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/collab/miker/lp1676608_copy_alerts-rebased-again-20170831 |
13:50 |
csharp |
FOR test_result IN SELECT * FROM |
13:50 |
csharp |
vandelay.match_set_test_marcxml(match_set, NEW.marc, match_bucket) LOOP |
13:50 |
csharp |
^^ appears to be the bottleneck |
14:12 |
bshum |
What day is today? |
14:14 |
Dyrcona |
heh |
14:15 |
* bshum |
is ready for his weekend |
14:20 |
* csharp |
is upgrading PINES this weekend, so no weekend |
14:20 |
csharp |
though hoping to move holiday to next Friday, $DEITY willing |
14:22 |
csharp |
resulting query: https://pastebin.com/XwZSSSkn |
14:23 |
csharp |
and that's like basically impossible to test :-/ |
14:23 |
kmlussier |
Ice cream should never be blamed for anything. It is only a force for good. |
14:23 |
kmlussier |
@praise ice cream |
14:23 |
* pinesol_green |
I come to praise ice cream, not to bury them. |
16:30 |
berick |
oh, i don't remember that part |
16:32 |
|
sandbergja joined #evergreen |
16:49 |
|
Christineb joined #evergreen |
17:00 |
pinesol_green |
News from qatests: Test Failure <http://testing.evergreen-ils.org/~live> |
17:22 |
pinesol_green |
[evergreen|blake] LP1655158 Patron Search by Date of Birth - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=baf337b> |
17:42 |
|
jvwoolf left #evergreen |
20:22 |
|
Jillianne joined #evergreen |
23:03 |
gmcharlt |
hmm, I think that test failure is basically a problem with the test itself |
23:05 |
gmcharlt |
besides dropping that static redefinition of unapi.mmr_mra, there isn't a reliable ordering imposed on source_list, nor does it seems that the specific order matters |