| 10:32 |
Dyrcona |
I have (event_def, state), but not with update_time. |
| 10:43 |
|
khuckins_ joined #evergreen |
| 10:53 |
|
stephengwills joined #evergreen |
| 11:02 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 11:15 |
|
jvwoolf joined #evergreen |
| 11:22 |
rjackson_isl |
just discovered that Cricket (phone plan) service provider changed their sms address of preference. Will changes to config.sms_carrier be "seen" without any type of autogen or restarting of services? |
| 11:34 |
Dyrcona |
I think so. I don't recall anywhere that gets cached by autogen.sh. |
| 11:35 |
Dyrcona |
Alos, adding those a/t event output indexes made my PO JEDI reset script noticeably faster on my test VM. |
| 11:35 |
csharp |
cricket-- |
| 11:36 |
Dyrcona |
Well, cheap wireless in general..... |
| 11:36 |
csharp |
they've done that several times over the last few years - at one point we just removed them from the public listing |
| 15:03 |
Bmagic |
"not supported" by Evergreen? |
| 15:05 |
jeff |
SIPServer doesn't populate that field. |
| 15:05 |
jeff |
How does bibliotheca plan to use it? |
| 15:05 |
nfBurton |
Also, this tool is amazing for testing SIP if you don't have it https://clcohio.org/sip-testing-tool/ |
| 15:05 |
Bmagic |
cool, (I sorta knew that because they are complaining about it) |
| 15:06 |
Bmagic |
awesome tool! I will get that for sure |
| 15:07 |
Bmagic |
I think they would use this information to artificially block patrons at their limit |
| 15:15 |
jeff |
Bmagic: are you talking about holds or circs? |
| 15:15 |
Dyrcona |
That's fine, except we don't know what that limit is because it varies. |
| 15:15 |
Bmagic |
circs (I know the vendor is asking about the BZ field which is confusing things I htink) |
| 15:16 |
* jeff |
goes to test something |
| 15:17 |
Dyrcona |
Send them -1 and see what their software does. :) |
| 15:19 |
Bmagic |
Dyrcona++ |
| 15:23 |
jeff |
My testing doesn't reproduce the issue. |
| 15:25 |
jeff |
I had an account with an item checked out. I changed the account to a profile which is limited to a very small number of items (3). I then checked out another item, bringing it to two. In a new session, I then tried to check out two more items, and I was blocked from checking out the fourth item. |
| 15:27 |
Bmagic |
hmmm |
| 15:27 |
Bmagic |
jeff++ |
| 15:28 |
Bmagic |
maybe we are fixing an issue that isn't there (anymore) |
| 15:35 |
|
sandbergja joined #evergreen |
| 16:08 |
|
jvwoolf left #evergreen |
| 16:37 |
|
khuckins joined #evergreen |
| 23:02 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 01:18 |
|
remingtron_ joined #evergreen |
| 04:30 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 06:49 |
|
Dyrcona joined #evergreen |
| 08:41 |
|
mmorgan joined #evergreen |
| 08:52 |
|
yboston joined #evergreen |
| 08:59 |
|
rjackson_isl joined #evergreen |
| 09:10 |
|
collum joined #evergreen |
| 09:12 |
bshum |
Oops, guess that parenthesis made the tests all unhappy in a different way. |
| 09:13 |
* bshum |
waits for the next time it runs again, before being happier about it |
| 09:23 |
|
yboston joined #evergreen |
| 09:35 |
|
jvwoolf joined #evergreen |
| 09:40 |
|
sandbergja joined #evergreen |
| 13:44 |
Bmagic |
I'm thinking it's coming in at the data level instead of at the presentation |
| 13:46 |
|
yboston joined #evergreen |
| 14:01 |
Bmagic |
berick: paper size dropdown menu in the printer driver interface contains a list of label options that Evergreen does not receive in it's options |
| 14:02 |
Bmagic |
however, when running hatch test, the JSON string contains the "correct" list of paper types for the Dymo as presented in the Windows driver preferences interface |
| 14:02 |
Bmagic |
The paper size, of course, needs to be exact such that the print job isn't asking the printer to print onto a canvas larger than the paper |
| 14:08 |
Bmagic |
weird, needed to set the printer as default. Relaunch chrome. and now we have the correct paper type list... hmmmmm |
| 14:40 |
berick |
hm, indeed |
| 16:10 |
|
mmorgan joined #evergreen |
| 16:20 |
abneiman |
berick++ # actual LOL |
| 16:20 |
abneiman |
we should've included that in our conference presentation |
| 16:30 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 16:33 |
|
jvwoolf left #evergreen |
| 17:05 |
|
mmorgan left #evergreen |
| 17:10 |
bshum |
Oh come on |
| 00:54 |
|
sandbergja joined #evergreen |
| 03:23 |
|
jamesrf joined #evergreen |
| 03:27 |
|
yar joined #evergreen |
| 05:02 |
pinesol |
News from qatests: Failed configuring websockets <http://testing.evergreen-ils.org/~live/test.22.html#2019-07-23T04:57:34,222253532-0400 -0> |
| 07:00 |
|
Dyrcona joined #evergreen |
| 07:01 |
Dyrcona |
Well, I just installed the configuration in production to proxy websocket connections through Apache with mod_proxy_wstunnel. Guess I'll know in a few hours how well that works. |
| 07:02 |
Dyrcona |
If this works well for us after a few days/weeks, I'm going to make a branch to remove the other proxy configurations and recommend this one in OpenSRF. |
| 07:20 |
csharp |
right |
| 07:20 |
Dyrcona |
I'm proxying websockets from 7682 to 7680, but the simpler configuration is from 443 to 7682. |
| 07:21 |
* csharp |
looks forward to seeing your branch |
| 07:21 |
Dyrcona |
I've tested this on training and on all of my virtual machines, so I know it works. |
| 07:21 |
Dyrcona |
The question is, what happens under load? |
| 07:21 |
csharp |
yeah |
| 07:22 |
Dyrcona |
Since we get the most complaints about white screens on Tuesday afternoons, I figure I'll find out pretty quickly if it's a problem or not. |
| 10:15 |
Dyrcona |
curr_connections 708 |
| 10:17 |
|
jvwoolf joined #evergreen |
| 10:21 |
Dyrcona |
What's also interesting is now that I've undone the proxy setup, load is higher on the brick heads, but we're running our normal, 60 or so apache process per brick head. |
| 10:22 |
Dyrcona |
I think we need to replace ldirectord with haproxy, but I suppose I'll look at using haproxy or just nginx for proxying websocktes only. I've set that up on a test server, but dunno how it works under load. |
| 10:25 |
Dyrcona |
I assume that everyone is using nginx as a proxy per the README instructions? |
| 10:26 |
Dyrcona |
And, you're doing it on each brick head? |
| 10:28 |
Dyrcona |
Oh, nice.... /tmp/action-trigger-LOCK exists for a process that isn't running and that didn't stop our --run-pending a/t runner from starting up. I assumed it was the one that used that particular lock file because no granularity. |
| 11:25 |
jeff |
are you sure the lockfile isn't just being removed quickly? have you confirmed with inotify or strace or something that the lockfile isn't being created at all? |
| 11:26 |
jeff |
hrm. |
| 11:29 |
Dyrcona |
No, I haven't confirmed that, but the processes were both still running when it was gone. |
| 11:31 |
jeff |
That's expected if they had gotten to the point where open-ils.trigger.event.run_all_pending had returned a response (and it returns an early "found" response after collecting and before reacting). |
| 11:32 |
jeff |
This has relevance to something I'm currently working on, so I'm trying an empirical test or two here to compare results. |
| 11:34 |
Dyrcona |
So, why would I have no granularity a/t runners going with a lock file for for a defunct process in it? |
| 11:34 |
Dyrcona |
It seems to be working with a --granularity-only process. |
| 11:35 |
Dyrcona |
There are two places in there where the lock file can be unlinked. That's bad. |
| 17:05 |
|
mmorgan joined #evergreen |
| 17:06 |
|
jvwoolf left #evergreen |
| 17:07 |
|
mmorgan left #evergreen |
| 17:32 |
pinesol |
News from qatests: Failed configuring websockets <http://testing.evergreen-ils.org/~live/test.22.html#2019-07-23T17:03:45,457223219-0400 -0> |
| 17:41 |
|
sandbergja joined #evergreen |
| 18:09 |
jeffdavis |
So, it looks like the master branch in working/Evergreen.git hasn't received updates in a couple of months. |
| 18:10 |
jeffdavis |
It used to auto-update from the main Evergreen repo, I believe. |
| 01:49 |
|
serflog joined #evergreen |
| 01:49 |
|
Topic for #evergreen is now Welcome to the #evergreen library system channel! | We are publicly logged: http://irc.evergreen-ils.org/evergreen | Large pastes at http://paste.evergreen-ils.org | Can't speak? Make sure your nickname is registered and that you are identified to freenode services: https://freenode.net/kb/answer/registration |
| 02:43 |
|
remingtron_ joined #evergreen |
| 05:01 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 05:19 |
|
stephengwills joined #evergreen |
| 06:52 |
|
Dyrcona joined #evergreen |
| 06:56 |
|
agoben joined #evergreen |
| 08:17 |
Dyrcona |
Hah! Even easier. |
| 08:18 |
JBoyer |
I did not realize that Apache had that module, it sounds much simpler. |
| 08:19 |
JBoyer |
But I'm guessing we're not using it for the same reason that we started using apache2-websockets? Something about having to have a heavy opac-laden process for every connection or something similar. |
| 08:20 |
JBoyer |
But if your tests look good and it's not too much of a ram pig maybe that should be reconsidered. |
| 08:21 |
Dyrcona |
Well, if you stick with port 7682 and don't include eg_vhosts.conf, I don't the process would be that laden. |
| 08:21 |
Dyrcona |
Possibly not even with 443 since it's only the one location, but I'll see. |
| 08:22 |
JBoyer |
Dyrcona++ |
| 08:25 |
Dyrcona |
I don't think it will be a big hit to performance or memory. |
| 08:26 |
Dyrcona |
The reason: This is configured as a location, so these Apache processes will be used for non-websockets requests, too. |
| 08:31 |
Dyrcona |
It does seem to be recycling them pretty quickly |
| 08:32 |
Dyrcona |
Without the proxy, I have osrf-websocket-stdio processes running for hours, even on a lightly used test server. |
| 08:34 |
Dyrcona |
They don't seem to be sticking around for more than 10 minutes or so. |
| 09:02 |
|
yboston joined #evergreen |
| 09:10 |
|
stephengwills joined #evergreen |
| 14:08 |
|
khuckins joined #evergreen |
| 14:41 |
|
bos20k joined #evergreen |
| 16:37 |
|
jvwoolf left #evergreen |
| 17:01 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 18:36 |
|
sandbergja joined #evergreen |
| 19:08 |
|
stephengwills joined #evergreen |
| 19:18 |
|
stephengwills joined #evergreen |
| 04:28 |
|
book` joined #evergreen |
| 05:08 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 07:13 |
|
agoben joined #evergreen |
| 07:33 |
|
bos20k joined #evergreen |
| 07:56 |
|
Dyrcona joined #evergreen |
| 12:02 |
|
cowens joined #evergreen |
| 12:05 |
Dyrcona |
hmm.... I should be able to proxy port 7632 to websockets on a different locally, so that it is totally transparent to our current users. |
| 12:05 |
Dyrcona |
should be "...on a different port locally..." |
| 12:06 |
Dyrcona |
I'll test that this afternoon before I send an email. If that works, it could save us some headache. |
| 12:17 |
|
collum joined #evergreen |
| 12:41 |
pinesol |
[evergreen|Galen Charlton] LP#1777207: have eg-grid generate DOM nodes only for visible columns - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=a84b6ae> |
| 12:41 |
pinesol |
[evergreen|Galen Charlton] LP#1777207: teach egGrid how to prepend rows more efficiently - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=1da6a8e> |
| 12:54 |
Dyrcona |
After thinking about it, I've decided not to even bother. I'll change the port when we start using a proxy. It's better for the long run. |
| 12:56 |
Dyrcona |
All right, I'm going to test it out of curiosity. |
| 12:59 |
pinesol |
[evergreen|Dan Wells] LP#1823367 Tone down org unit row coloring - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=0ef978c> |
| 12:59 |
pinesol |
[evergreen|Dan Wells] LP#1823367 De-encapsulate holdings grid styles to fix row highlighting - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=a60fcd0> |
| 12:59 |
pinesol |
[evergreen|Dan Wells] LP#1823367 Add place to collect style guidelines - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=d424f00> |
| 13:36 |
|
yboston joined #evergreen |
| 13:40 |
|
tlittle joined #evergreen |
| 13:48 |
|
kip joined #evergreen |
| 13:53 |
Dyrcona |
And, maybe, my test vm is hosed for some other reason. :( |
| 13:53 |
Dyrcona |
'Cause it doesn't work after reverting the changes. |
| 13:54 |
agoben |
The Evergreen Project Board/EOB meeting should be starting in about 5 minutes. |
| 14:00 |
agoben |
#startmeeting EOB meeting for 2019-07-18, agenda:https://wiki.evergreen-ils.org/doku.php?id=governance:minutes:2019-07-18 |
| 14:32 |
gmcharlt |
it's arising from a staff member at the Niagara Falls Public Library |
| 14:32 |
gmcharlt |
but would inherently become multi-entity when it becomes ready for review |
| 14:32 |
agoben |
Sure, just wasn't sure where to start if we wanted to pass it along. |
| 14:32 |
gmcharlt |
I note that the accessbility report reflects testing of the web staff client |
| 14:33 |
tlittle |
I asked the auditors if it was okay to widely share the results, and they said yes. So maybe it would be beneficial to release to the dev mailing list, as guidelines for future dev work that accounts for accessibility needs? |
| 14:33 |
gmcharlt |
and of course the Angular work may effectdetails |
| 14:33 |
agoben |
tlittle++ |
| 14:33 |
gmcharlt |
I think it is worthwhile to share it with the dev mailing list, and also put it somewhere on the wiki or website if GPLS is amenable to that |
| 14:34 |
tlittle |
I'm fine with that |
| 14:35 |
agoben |
tlittle, since PINES solicited the study, would you be willing to take lead on getting that document shared? |
| 14:35 |
gmcharlt |
I'm not seeing OPAC on the list of URLs tested, FWIW |
| 14:35 |
tlittle |
Sure, I can do that |
| 14:35 |
|
cowens joined #evergreen |
| 14:35 |
tlittle |
I'm pretty sure it was purely for the client, IIRC |
| 15:06 |
dbwells |
dbs: If that was on my radar, it must have fallen off. Sorry for that. We use the built in auth for staff accounts, so it hasn't been an issue for us. |
| 15:08 |
dbs |
dbwells: it was probably something that only came up in IRC, no worries |
| 15:11 |
|
sandbergja joined #evergreen |
| 15:13 |
sandbergja |
dbs: re checking accessibility before merging PRs, I've also been wondering if we can add some automated accessibility tests to our test suite |
| 15:14 |
sandbergja |
I've been meaning to experiment with this: https://github.com/angular/protractor-accessibility-plugin |
| 15:15 |
sandbergja |
(not that automated tools can catch all a11y errors, but they can help so much with things like unlabeled inputs) |
| 15:16 |
Dyrcona |
While that was broken, xmllint says it can't parse /openils/var/web/reports/fm_IDL.xml, but /openils/conf/fm_IDL.xml is fine. |
| 15:16 |
Dyrcona |
autogen.sh doesn't help. |
| 15:17 |
Dyrcona |
Replacing one with the other resolves it. |
| 15:53 |
Dyrcona |
dbs: Well, I found that replacing the translated IDL with the non-translated one fixed my issue. |
| 15:54 |
Dyrcona |
Something else may have been wrong with it. |
| 15:54 |
dbs |
the XMLENT apache module resolves those at run time, but you'll only have a complete set of XML entity definitions if you do the make install step after prepping the desired localizations, iirc |
| 15:54 |
Dyrcona |
I'm doing a fresh build after git clean -xfd to test. |
| 15:55 |
Dyrcona |
dbs: Yeah, I followed the correct steps once, when verifying the bug, but I had forgotten about having done it. |
| 15:55 |
dbs |
yeah, all the unilingual sites just do that (cp /openils/conf/fm_IDL.xml /openils/var/web/reports/fm_IDL.xml) :/ |
| 15:55 |
dbs |
but it works! which is always a good thing |
| 16:42 |
gsams |
jeff: 3.2.3 and it does appear to be working properly now after some browser clearing. |
| 16:51 |
|
yboston joined #evergreen |
| 16:57 |
|
sandbergja joined #evergreen |
| 17:02 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 17:04 |
gsams |
jeff++ |
| 17:48 |
|
stephengwills left #evergreen |
| 21:16 |
|
stephengwills joined #evergreen |
| 05:00 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 07:06 |
|
rjackson_isl joined #evergreen |
| 07:26 |
|
collum joined #evergreen |
| 08:17 |
|
bos20k joined #evergreen |
| 12:03 |
|
jihpringle joined #evergreen |
| 12:10 |
jihpringle |
gmcharlt: for the second of the new patches on LP 1777207 is the "previous sort order" in bullet 3 the original check in order or the order after the patron sorted? |
| 12:10 |
pinesol |
Launchpad bug 1777207 in Evergreen "Web Client - Check In List Refreshes After Every Scan and Gets Progressively Slower" [Medium,Confirmed] https://launchpad.net/bugs/1777207 - Assigned to Galen Charlton (gmc) |
| 12:11 |
jihpringle |
just want to make sure I know what I should be seeing when I test |
| 12:15 |
|
Christineb joined #evergreen |
| 12:22 |
miker |
jihpringle: donning gmcharlt mask, the user-applied sort |
| 12:23 |
miker |
IIUC |
| 14:07 |
jeffdavis |
csharp: I guess I need to start attending the conferences. |
| 14:07 |
csharp |
jeffdavis: or the hackaway! |
| 14:08 |
csharp |
fwiw, I've never made a report with that source |
| 14:08 |
jihpringle |
thanks gmcharlt |
| 14:09 |
jihpringle |
I've tested both new patches on our test server and so far it looks good |
| 14:11 |
gmcharlt |
cool |
| 14:17 |
dbs |
gmcharlt: those would be some weird reports indeed! |
| 14:18 |
gmcharlt |
dbs: "but whatever is wrong with me using Evergreen as my platform for hosting an IRSpy clone?" ;) |
| 15:06 |
Dyrcona |
So, I have found two so far that don't seem to correspond to open-ils.auth.session.delete calls, but 1 has two session retrieves right before it: 1 with an authtoken and 1 with null for the authtoken. |
| 15:07 |
Dyrcona |
Two segfaults, that is. |
| 15:07 |
dbs |
csharp: okay, that matches what we're doing. thanks though! |
| 15:07 |
Dyrcona |
dbs | csharp: I'm using the same on my test systems with nginx. I will likely use haproxy in production to replace ldirectord, IF I ever get the time. |
| 15:08 |
dbs |
Some of the Dojo UIs were replaced with Angular UIs in the last couple of releases, or am I dreaming? |
| 15:09 |
berick |
dbs: they were |
| 15:09 |
Dyrcona |
They have to be enabled, though, don't they? |
| 16:51 |
* Dyrcona |
hopes he never runs into Grace Slick. |
| 16:52 |
Dyrcona |
Although, that would be cool... |
| 17:00 |
|
finnx joined #evergreen |
| 17:00 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 17:02 |
|
finnx left #evergreen |
| 17:08 |
|
mmorgan left #evergreen |
| 17:12 |
Dyrcona |
So, I'm partly wrong and partly right about where the segfault occurs, and the partly wrong could make a better fix easier.... |
| 04:21 |
|
pinesol joined #evergreen |
| 04:30 |
|
pinesol` joined #evergreen |
| 04:31 |
|
csharp_ joined #evergreen |
| 04:31 |
pinesol |
News from qatests: Failed cloning Evergreen git repository <http://testing.evergreen-ils.org/~live/test.24.html#2019-07-11T04:28:32,372035808-0400 -0> |
| 04:31 |
pinesol |
News from qatests: Failed Evergreen developer steps <http://testing.evergreen-ils.org/~live/test.25.html#2019-07-11T04:28:32,398579854-0400 -2> |
| 04:31 |
pinesol |
News from qatests: Failed Installing Evergreen pre-requisites <http://testing.evergreen-ils.org/~live/test.26.html#2019-07-11T04:28:32,424469023-0400 -4> |
| 04:31 |
pinesol |
News from qatests: Failed Installing Evergreen pre-requisites <http://testing.evergreen-ils.org/~live/test.27.html#2019-07-11T04:28:32,450430528-0400 -6> |
| 04:31 |
pinesol |
News from qatests: Failed Installing AngularJS web client <http://testing.evergreen-ils.org/~live/test.28.html#2019-07-11T04:28:32,476370743-0400 -8> |
| 04:31 |
pinesol |
News from qatests: Failed Installing Angular web client <http://testing.evergreen-ils.org/~live/test.29.html#2019-07-11T04:28:32,502300896-0400 -10> |
| 04:31 |
pinesol |
News from qatests: Failed Building Evergreen <http://testing.evergreen-ils.org/~live/test.30.html#2019-07-11T04:28:32,528244132-0400 -12> |
| 04:31 |
pinesol |
News from qatests: Failed Running Evergreen tests <http://testing.evergreen-ils.org/~live/test.31.html#2019-07-11T04:28:32,554250981-0400 -14> |
| 04:31 |
pinesol |
News from qatests: Failed Installing Evergreen <http://testing.evergreen-ils.org/~live/test.32.html#2019-07-11T04:28:32,581608579-0400 -16> |
| 04:31 |
pinesol |
News from qatests: Failed Installing Dojo <http://testing.evergreen-ils.org/~live/test.35.html#2019-07-11T04:28:32,608470485-0400 -18> |
| 04:31 |
pinesol |
News from qatests: Failed configure apache <http://testing.evergreen-ils.org/~live/test.36.html#2019-07-11T04:28:32,634442673-0400 -20> |
| 04:31 |
pinesol |
News from qatests: Failed configure EG Action/Trigger <http://testing.evergreen-ils.org/~live/test.38.html#2019-07-11T04:28:32,661434258-0400 -22> |
| 04:31 |
pinesol |
News from qatests: Failed Installing Evergreen database pre-requisites <http://testing.evergreen-ils.org/~live/test.39.html#2019-07-11T04:28:32,687372908-0400 -24> |
| 04:31 |
pinesol |
News from qatests: Failed Create PostgreSQL superuser <http://testing.evergreen-ils.org/~live/test.40.html#2019-07-11T04:28:32,713406894-0400 -26> |
| 04:31 |
pinesol |
News from qatests: Failed Create Evergreen Database <http://testing.evergreen-ils.org/~live/test.41.html#2019-07-11T04:28:32,740334785-0400 -28> |
| 04:31 |
pinesol |
News from qatests: Failed Running autogen.sh <http://testing.evergreen-ils.org/~live/test.44.html#2019-07-11T04:28:32,767387782-0400 -30> |
| 04:31 |
pinesol |
News from qatests: Failed Running pgTAP live tests <http://testing.evergreen-ils.org/~live/test.47.html#2019-07-11T04:28:32,793340892-0400 -32> |
| 04:31 |
pinesol |
News from qatests: Failed Running settings-tester.pl <http://testing.evergreen-ils.org/~live/test.48.html#2019-07-11T04:28:32,821412178-0400 -34> |
| 04:31 |
pinesol |
News from qatests: Failed Running perl live tests <http://testing.evergreen-ils.org/~live/test.49.html#2019-07-11T04:28:32,847372095-0400 -36> |
| 04:31 |
pinesol |
News from qatests: Failed Log Output: srfsh.log <http://testing.evergreen-ils.org/~live/test.58.html#2019-07-11T04:28:32,873266185-0400 -38> |
| 04:31 |
pinesol |
News from qatests: Failed Building the AsciiDoc output formats <http://testing.evergreen-ils.org/~live/test.61.html#2019-07-11T04:28:32,900231157-0400 -40> |
| 05:55 |
|
dbwells_ joined #evergreen |
| 06:02 |
|
dbwells joined #evergreen |
| 06:57 |
|
csharp joined #evergreen |
| 10:23 |
Dyrcona |
CALL: open-ils.pcrud open-ils.pcrud.search.pgt null,{"parent":null},{"flesh":-1,"flesh_fields":{"pgt":["children"]}} is followed by a segfault in liboils_pcrud.so.2.0 on one of my brick drones' logs. That -1 looks quite wrong to me. |
| 10:28 |
mmorgan |
Dyrcona: The null after search.pgt looks wrong to me |
| 10:30 |
Dyrcona |
Yeah, that, too. :) |
| 10:31 |
Dyrcona |
I'm going to try exactly that call on a test vm. See if it leads to a crash. |
| 10:31 |
berick |
the -1 is OK |
| 10:33 |
mmorgan |
In the web client, when you choose Print Full Grid from the Actions menu, can you control which printer is used? |
| 10:34 |
Dyrcona |
berick: OK, but I won't just take your word for it. I'll look at the code, too, because I want to see why it is OK and how it works. I always thought flesh depth, etc., had to be > 1 and correspond to the actual depth of the fleshing.... |
| 16:19 |
|
khuckins joined #evergreen |
| 16:52 |
|
mmorgan joined #evergreen |
| 16:55 |
|
mmorgan2 joined #evergreen |
| 17:01 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 17:03 |
|
mmorgan left #evergreen |
| 22:35 |
|
sandbergja joined #evergreen |
| 22:47 |
|
sandbergja joined #evergreen |
| 05:00 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 09:49 |
|
Dyrcona joined #evergreen |
| 09:59 |
Dyrcona |
So, looking into Buster support a bit more, I see something that also likely needs to be fixed on Bionic: Compilation failed in require at /usr/share/perl/5.28/base.pm line 135. |
| 10:00 |
Dyrcona |
The Bionic error happens on line 136, but I believe it is the same issue. |
| 16:24 |
|
sandbergja joined #evergreen |
| 16:48 |
|
sandbergja joined #evergreen |
| 16:56 |
|
Dyrcona joined #evergreen |
| 16:57 |
Dyrcona |
Messing around with the bug again. My patch fixes some disabled tests in 09-OpenILS-Application-Storage-Driver.t. |
| 16:58 |
Dyrcona |
Also hacked utils.h in libopensrf so I could actually introspect open-ils.storage. The storage drone seg faults if you don't increase BUFFER_MAX_SIZE. The default is 10MB. |
| 16:59 |
Dyrcona |
Looks like the output is 47MB. |
| 17:01 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 17:19 |
|
sandbergja joined #evergreen |
| 17:37 |
Dyrcona |
Just running some requests through srfsh and storage still seems to be working. |
| 17:53 |
|
sandbergja joined #evergreen |
| 01:11 |
|
sandbergja joined #evergreen |
| 05:01 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 07:21 |
|
Dyrcona joined #evergreen |
| 07:25 |
Dyrcona |
@later tell bshum I think we need to ditch phantomjs. It has other issues, IIRC. |
| 07:25 |
pinesol |
Dyrcona: The operation succeeded. |
| 10:53 |
dbs |
TFW you discover that the */20 minute cron job that synced LDAP users to Evergreen was cancelled Sept 2018 |
| 10:54 |
bshum |
dbs: Well, that wasn't *that* long ago... :P |
| 10:54 |
dbs |
It's like I've been gone for a year or something! |
| 10:54 |
Dyrcona |
When I make a test vm, I add the first and only user as opensrf. The installer now will not let me do that. I have to add a different user, then create the opensrf via command line. It adds 3 or 4 steps because I also have to add that user to a couple of groups: adm, sudo, etc. |
| 10:55 |
jeff |
ah. interesting! not applicable here, so i've not run into the issue. |
| 10:56 |
Dyrcona |
I do the same thing with production vms, but I use Ubuntu in production, so it's not an issue there. |
| 10:59 |
|
Christineb joined #evergreen |
| 16:44 |
Dyrcona |
bshum: Did you want to make a change to the README? I thought you mentioned earlier about wanting to add some more detail about adding mod_legacy_auth to the ejabberd.yml |
| 16:47 |
Dyrcona |
Ah well. We can take that up next week. |
| 16:48 |
* Dyrcona |
signs out and switches back to WiFi. |
| 17:00 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 17:06 |
|
mmorgan left #evergreen |
| 17:12 |
|
jvwoolf1 left #evergreen |
| 17:47 |
|
sandbergja joined #evergreen |
| 00:25 |
jeff |
kenstir++ Where the Wild Things Are ref |
| 05:00 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 09:56 |
|
Christineb joined #evergreen |
| 12:09 |
|
jihpringle joined #evergreen |
| 14:02 |
|
jamesrf joined #evergreen |
| 14:52 |
bshum |
And then adopting part of the Ubuntu-Xenial ejabberd config steps (though of course the ejabberd.yml is missing the mod_legacy_auth: {} line entirely now, so it has to be added in) |
| 14:52 |
bshum |
But yay, working opensrf.math :) |
| 14:59 |
dbs |
bshum++ |
| 15:01 |
bshum |
Working through the EG prereqs now, everything seems fine except that we need to standardize all the distros to use the PG community apt repo and then choose PG 9.6 baseline |
| 15:02 |
bshum |
dbs: Heh, this is me on a quiet holiday I guess ;) |
| 15:03 |
* bshum |
hasn't done a by-the-book install manually in forever |
| 15:06 |
bshum |
Hmm |
| 15:06 |
bshum |
So libssl 1.1.1 that comes with Debian 10 is busted for phantomjs, it errors very unhappily during web client building |
| 15:08 |
bshum |
Doing "export OPENSSL_CONF=/etc/ssl/" first, before doing the npm run test seems to have allowed phantomjs to work |
| 15:08 |
bshum |
with the newer libssl |
| 15:21 |
* bshum |
whistles to himself waiting for concerto to load to PG |
| 15:26 |
bshum |
And both opac search and web client login works, whee! |
| 15:26 |
bshum |
Okay, guess it's time to make LP bugs and branches now :) |
| 15:59 |
bshum |
Huzzah |
| 16:00 |
* bshum |
is going to take a break and will try installing libgcrypt20-dev as a pre-req for older distros later |
| 16:00 |
bshum |
I put all my findings about Debian 10 (and some initial branches) at https://bugs.launchpad.net/evergreen/+bug/1835458 |
| 16:00 |
bshum |
Will revisit later :) |
| 16:01 |
pinesol |
Launchpad bug 1835458 in OpenSRF "Add Evergreen support for Debian 10 Buster" [Undecided,New] |
| 17:01 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 18:14 |
|
sandbergja joined #evergreen |
| 20:23 |
|
jihpringle68 joined #evergreen |
| 22:10 |
|
sandbergja joined #evergreen |
| 05:02 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 06:54 |
|
agoben joined #evergreen |
| 07:15 |
|
rjackson_isl joined #evergreen |
| 07:28 |
|
Dyrcona joined #evergreen |
| 11:01 |
bos20k |
Can't call method "opac_visible" on an undefined value at /usr/local/share/perl/5.22.1/OpenILS/Application/Storage/Driver/Pg/QueryParser.pm line 1191. |
| 11:08 |
JBoyer |
bos20k, a problem with the org tree can do that. If you specify an invalid org in a query param it will usually dump an ISE on you, but I think some changes without a catch-up autogen.sh can cause this |
| 11:09 |
JBoyer |
(or potentially an out of date org tree in memcache) |
| 11:10 |
bos20k |
JBoyer: Thanks. I was thinking it was probably something like that. I didn't see any issues but I'll go over it again. |
| 11:22 |
bos20k |
Looks like it was memcached on the test database server. Thanks again! |
| 11:22 |
bos20k |
JBoyer++ |
| 11:23 |
JBoyer |
yay! |
| 11:27 |
bos20k |
I think I need to add it to our documentation to restart memcached on the test database server after refreshing one of the databases from production. I think that is probably what set it off. |
| 11:30 |
JBoyer |
After a full db refresh that might be the way to go, yeah. If you just want to wipe out the org cache real quick you can just use memcrm to clear the orgtree. , orgtree.en-US , and orgtree.en-us keys and you should be in business. |
| 11:32 |
bos20k |
I'm wondering if this would work instead of a restart: echo 'flush_all' | nc localhost 11211 |
| 11:32 |
jeff |
it could have similar effects, assuming memcached is bound to that interface. |
| 12:12 |
JBoyer |
mmorgan, so I had not noticed this, but you're right. it should be auto only. |
| 12:13 |
mmorgan |
Ok, thanks, I'll open a bug. |
| 13:04 |
|
jvwoolf joined #evergreen |
| 13:26 |
JBoyer |
mmorgan, good news, I think I'm already on the trail of that one and should have a branch to test very soon. |
| 13:26 |
mmorgan |
JBoyer++ |
| 13:31 |
Dyrcona |
JBoyer++ |
| 13:32 |
|
stephengwills joined #evergreen |
| 15:16 |
Dyrcona |
No, but that's the likely culprit. I'll have to look into it later, since it's time for me to end my day. |
| 15:19 |
|
jvwoolf joined #evergreen |
| 15:41 |
|
stephengwills joined #evergreen |
| 17:01 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 17:12 |
|
mmorgan left #evergreen |
| 17:23 |
|
jvwoolf left #evergreen |
| 17:40 |
|
kenstir joined #evergreen |
| 16:20 |
|
jihpringle joined #evergreen |
| 16:31 |
Dyrcona |
jeffdavis++ # It's Friday. |
| 16:35 |
Dyrcona |
jeffdavis: Can explain what you mean by "installed locale?" Does it have to be installed from O/S packages or do you mean one of the languages with Evergreen translations? |
| 16:36 |
jeffdavis |
The latter. In our case we build locale stuff from source; for installing from a tarball I think you could use any of the translations that come with EG (but I haven't tested that). |
| 16:37 |
jeffdavis |
"installed translations" would maybe be a clearer way for me to put it |
| 16:37 |
Dyrcona |
jeffdavis: Thanks. That is what I thought you meant, but yeah... |
| 16:38 |
* Dyrcona |
looks into how to install locale stuff from source.... |
| 16:40 |
jeffdavis |
cd build/i18n && make LOCALE=fr-CA install |
| 16:58 |
mmorgan |
Dyrcona++ |
| 16:59 |
Dyrcona |
I've used that on pending and collected events. |
| 16:59 |
Dyrcona |
I think it works regardless of the event state. |
| 17:01 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 17:03 |
|
jvwoolf1 left #evergreen |
| 17:06 |
mmorgan |
Dyrcona: Interesting, each time it's fired it bumps to the next state. Works for my purpose though! Thanks again. |
| 17:06 |
Dyrcona |
It should only need to be fired once. Something must be wrong with the data. |
