00:54 |
|
abowling joined #evergreen |
03:55 |
|
bshum joined #evergreen |
04:15 |
|
bshum joined #evergreen |
05:02 |
pinesol_green |
News from qatests: Test Success <http://testing.evergreen-ils.org/~live> |
06:12 |
|
bshum joined #evergreen |
06:12 |
|
troy__ joined #evergreen |
06:13 |
|
csharp joined #evergreen |
09:39 |
* gmcharlt |
wonders if they come in bottles |
09:41 |
Dyrcona |
#monero often has random spammers posting links. |
09:43 |
Dyrcona |
duh.... |
09:43 |
Dyrcona |
I started my SIP2 test again after reloading the database. I forgot that I need to change the read only sip group's permissions. |
09:44 |
Dyrcona |
maybe I should add that to my upgrade script? |
09:48 |
* Dyrcona |
sees what he considers a bug in the SIP2 groups setup here, but one person's bug is another's feature. |
09:54 |
|
Christineb joined #evergreen |
11:25 |
gmcharlt |
e.g., making the 3.0 XUL client use HTTPS to access offline.pl is totally doable |
11:26 |
* bshum |
points at https://bugs.launchpad.net/evergreen/+bug/1547668 and wonders if this still applies |
11:26 |
pinesol_green |
Launchpad bug 1547668 in Evergreen "XUL staff client does not support TLS above 1.0" [Undecided,New] |
11:26 |
Dyrcona |
Hmm... You know. I didn't test the staff client with TLS1.2.... |
11:26 |
Dyrcona |
I don't think it can do it, can it? |
11:26 |
dbs |
I should update that bug to indicate that yaz is happily connecting to HTTPS on Ubuntu 16.04, it was another victim of a particular yaz version / OS version issue |
11:26 |
Dyrcona |
bshum++ # For reading my mind. |
11:28 |
berick |
do the secure:false setting in the staff client have no effect? in constants.js. |
11:28 |
berick |
or do are they happy to be redirected? |
11:28 |
* Dyrcona |
goes to check the dates again on the PCI ultimatum..... |
11:29 |
berick |
i tested a few things here redirecting 80->443 and xul seems happy, but haven't confirmed it's hitting any of the secure:false API's |
11:30 |
dbs |
well we're using the indexdata yaz packages so that might be part of it |
11:32 |
berick |
eh, the secure:false stuff didn't come up in 1507013, so it's probably not an issue. |
11:43 |
Dyrcona |
Y'know what really bugs me about the SSL-everywhere movement? Practically no one encrypts their email, and email should be the first that gets encrypted. Not some random website with pictures of cats. |
01:19 |
|
remingtron joined #evergreen |
05:01 |
pinesol_green |
News from qatests: Test Success <http://testing.evergreen-ils.org/~live> |
07:18 |
|
rjackson_isl joined #evergreen |
08:21 |
|
_adb joined #evergreen |
08:35 |
csharp |
working with test_json_query this morning... how to I make it not freak out when there are spaces in a key (ex. "not in")? |
08:39 |
|
Dyrcona joined #evergreen |
08:40 |
|
mmorgan joined #evergreen |
08:41 |
tsbere |
csharp: Not sure, but I didn't think "not in" was in the list of 2+ word operators allowed |
08:49 |
csharp |
tsbere: working from https://wiki.evergreen-ils.org/doku.php?id=documentation:tutorials:json_query - also the query is in active use in 2.12+: http://git.evergreen-ils.org/?p=Evergreen.git;a=blob;f=Open-ILS/src/perlmods/lib/OpenILS/Application/Acq/Order.pm;h=3eae8602e31730305f346472d0dbf63e5ebbb456;hb=refs/heads/rel_2_12#l1194 |
08:50 |
|
bos20k joined #evergreen |
08:50 |
csharp |
when I remove the space or replace it with _ just to get it working, the resulting SQL is wrong (not just because "notin/not_in" is invalid SQL) |
08:52 |
csharp |
relevant: bug 1257915 - which I tested and signed off on on a stock master server, but it's not working on our test server |
08:52 |
pinesol_green |
Launchpad bug 1257915 in Evergreen 2.11 "Acq: purchase orders stay "on-order" with some lineitems received and the rest canceled" [Medium,Fix released] https://launchpad.net/bugs/1257915 |
08:53 |
csharp |
test server has real PINES data |
08:53 |
tsbere |
csharp: Huh. Ok, maybe my memory is lacking. Or I missed some other change that went through. |
08:53 |
csharp |
s'ok |
08:54 |
Dyrcona |
csharp: Have you converted it to Perl and tried it that way? |
08:57 |
* tsbere |
ran a quick test on his (not updated recently) dev machine and it worked fine if he single-quoted the entire json query when passing it to test_json_query |
08:58 |
tsbere |
csharp: Is your passing being split into multiple arguments on the space? |
08:59 |
csharp |
Dyrcona: the query is converted from perl - I don't know how one tests it from perl :-/ |
08:59 |
csharp |
tsbere: yeah, it appears to be that |
09:00 |
|
collum joined #evergreen |
09:00 |
Dyrcona |
csharp: CStore has methods to run JSON queries. I suspect what you're using converts the JSON to Perl and passes it to one of those. |
09:00 |
csharp |
tsbere: when I add single quotes around the whole query, I get "Unexpected character" |
09:02 |
csharp |
test_json_query -v `cat blah.json | sed ':a;N;$!ba;s/\n/ /g'` |
09:02 |
csharp |
oh actually I did it without the sed |
09:03 |
csharp |
test_json_query -v `cat blah.json` |
09:03 |
Dyrcona |
csharp: here's another tool you can use to test it: https://github.com/Dyrcona/evergreen_utilities/blob/master/perl/json_query.pl |
09:03 |
Dyrcona |
Put your json in a file and run it with that. See what happens. :) |
09:04 |
tsbere |
csharp: This should fix it for you: test_json_query -v "`cat blah.json`" |
09:05 |
csharp |
tsbere: that did it - thanks! |
09:09 |
Dyrcona |
it just works with my script, but feel free to ignore me. :) |
09:10 |
Dyrcona |
And my script serves a slightly different purpose. |
09:10 |
csharp |
Dyrcona: thanks - nice to know that there are alternatives ;-) |
09:11 |
Dyrcona |
It's not meant to test json queries, but to run them and produce CSV output. |
09:12 |
Dyrcona |
I don't use it much, but there it is. |
09:12 |
csharp |
Dyrcona: I just ran it - as expected in this case, it returned no results |
09:12 |
Dyrcona |
Yeap, and no errors. If there was an error in the json, it would have been reported. |
09:13 |
Dyrcona |
I ran it on a test database. |
09:14 |
Dyrcona |
I think I originally wrote that to debug some json queries that weren't giving the results I expected, but that was 5 years ago, so... |
09:15 |
|
terran joined #evergreen |
09:15 |
Dyrcona |
Or more. I think I put 2012 on there when I put it in a public repo. |
13:57 |
Bmagic |
I would like to see the xul staff client "home" screen instantly after hitting enter on my login box |
13:57 |
Dyrcona |
If you're paying per CPU, then reduce the number of CPUs. |
13:57 |
Dyrcona |
That will never happen because network. |
13:59 |
Bmagic |
network, of course, but shouldn't these bricks be pushing everything they have to offer? I guess the true test would be to remove half of the bricks and see if the CPU load doubles on the other half |
14:00 |
Dyrcona |
The idea isn't to max out the utilization of the hardware. The idea is to offer your customers a reasonable level of performance at a reasonable price. |
14:00 |
Dyrcona |
You may have more bricks than you need. |
14:00 |
Dyrcona |
But honestly, when even one of our bricks is maxed out, we get phone calls, and not pleasant ones, either. |
14:13 |
csharp |
gotta start putting these awesome @band names to good use |
14:21 |
berick |
csharp: bug 1711194 |
14:21 |
pinesol_green |
Launchpad bug 1711194 in OpenSRF "osrf_control --diagnostic should report max-children values" [Wishlist,New] https://launchpad.net/bugs/1711194 |
14:26 |
csharp |
berick: oh - awesome! will test directly |
14:27 |
berick |
fyi requires a re-configure |
14:27 |
csharp |
berick: will do |
14:30 |
|
lasse_ joined #evergreen |
14:36 |
csharp |
lasse_: yeah... no windows server at this point |
14:36 |
csharp |
but the client software is multi-platform and we're transitioning to browser based with the next release |
14:37 |
lasse_ |
ah if it's just a matter of running the server on linux it's no problem - I am sys admin and could just set up a linux server |
14:37 |
csharp |
lasse_: yep, most of our clients are running on windows boxes |
14:38 |
csharp |
lasse_: if you decide to install a test box, please ask here for help - we're mostly on the east coast of the USA and available 8 a.m. to mostly 6 or 7 p.m. Eastern Time |
14:38 |
lasse_ |
I'm thinking of using it for check in and out of our library (currently students just go in and pick books of the shelf - no control what soever) - same goes for study books - only the teacher is responsible for knowing who has which book |
14:38 |
csharp |
some of us are night owls and early risers though :-) |
14:39 |
csharp |
lasse_: koha would be another open source option too, in case you're not aware |
15:22 |
bshum |
Yep, that's the one |
15:22 |
Dyrcona |
yeah. |
15:23 |
Dyrcona |
I haven't seen it, but I've not used 2.5 in production, yet. |
15:23 |
Dyrcona |
Just in testing/training. |
15:23 |
|
remingtron joined #evergreen |
15:23 |
Dyrcona |
You are using it with EG 2.12, right? |
15:24 |
dbs |
yep |
15:49 |
Dyrcona |
dbs: that "stanza is too big" appears in OpenSRF/OpenILS logs, right? I'm going to check training and one of my dev vms. |
15:51 |
dbs |
Dyrcona: yeah we have ours going to syslog, so on a systemd system 'journalctl -n 100000 | grep "XML stanza"' works |
15:52 |
dbs |
Doesn't show up often, only once in our last 100000 lines of logs |
15:52 |
Dyrcona |
All right. I'm using /openils/var/log on the training and test vms. |
15:52 |
Dyrcona |
I have several gigs of logs going back a couple of weeks. |
15:52 |
Dyrcona |
I hammered SIP2 recently on the test vm, that might turn something up. |
15:54 |
Dyrcona |
Nope. Not finding anything, but my requests may not be that big. |
15:57 |
dbs |
"Bront©± family." eh? hmm |
15:58 |
* Dyrcona |
guesses double encoding or similar. |
15:59 |
dbs |
yeah, this was an originally MARC8-encoded record |
15:59 |
dbs |
yaz-client shows it just fine so we're messing something up |
15:59 |
dbs |
back on stanza too big, the one case I have seems to be related to incoming SRU queries |
16:01 |
Dyrcona |
Well, I can try some of those. I'm sure we've not looked at that on training or my test vm. |
16:01 |
Dyrcona |
Maybe tomorrow. |
16:04 |
|
collum_ joined #evergreen |
16:18 |
berick |
@band add CHACHA20 |
16:18 |
pinesol_green |
berick: Band 'CHACHA20' added to list |
16:18 |
berick |
from a list of ssl ciphers |
17:01 |
pinesol_green |
News from qatests: Test Success <http://testing.evergreen-ils.org/~live> |
17:02 |
|
mmorgan left #evergreen |
17:18 |
|
jvwoolf left #evergreen |
18:33 |
csharp |
dbs: we have reports of unicode not working on our z39.50-imported records - 2.12.2-ish/OpenSRF 2.5.0 - haven't dug yet but symptoms sound similar |
18:34 |
csharp |
on Ubuntu 16.04 |
18:38 |
csharp |
also got reports of search/other things not working on our test server a couple of weeks ago - found that OpenSRF was offline - I'll look into the logs to see what was going on - I suspect the same issue as bug 1709710 |
18:38 |
pinesol_green |
Launchpad bug 1709710 in Evergreen "OpenSRF Installation Instructions for ejabberd" [Undecided,Incomplete] https://launchpad.net/bugs/1709710 - Assigned to Adam Bowling (abowling) |
18:40 |
csharp |
lots of "4 In-flight request(s) took longer than 600 seconds to complete. Treating requ |
18:40 |
csharp |
est as dead and moving on." |
05:00 |
pinesol_green |
News from qatests: Test Success <http://testing.evergreen-ils.org/~live> |
07:03 |
|
jvwoolf joined #evergreen |
07:14 |
|
JBoyer joined #evergreen |
07:19 |
|
book` joined #evergreen |
12:17 |
csharp |
dbs: I've not heard of it... to be clear, this is in the client when entering the z39.50 UI and they've saved credentials to outside servers? |
12:18 |
dbs |
That's what it seems to be, yeah |
12:19 |
* dbs |
needs to dig further |
12:24 |
csharp |
dbs: I just added credentials on my 2.12 test server, then exited and re-opened the z39 UI and it worked as expected - I'll check with our catalogers who have been testing too |
12:24 |
Dyrcona |
Bmagic: Maybe my attribution to the IRS is another case of GIGO: http://www.atlasobscura.com/articles/is-this-the-first-time-anyone-printed-garbage-in-garbage-out |
12:26 |
Dyrcona |
And I love that Charles Babbage quote. I have read it before. |
12:27 |
csharp |
dbs: in our case it may not be a good test since most are creating new XUL client profiles as they log into our test server |
12:27 |
csharp |
so not exactly an "upgrade" |
12:29 |
Bmagic |
Dyrcona: nice article! |
12:33 |
dbs |
csharp: thanks! |
12:34 |
csharp |
dbs: confirmed from our lead cataloger that no one has reported similar problems while testing 2.12 |
12:34 |
csharp |
happy to help! |
12:34 |
dbs |
We only have one entry in config.z3950_source_credentials and it's mine, so it really looks like a XUL thing. I'll dig deeper. |
12:39 |
|
mmorgan joined #evergreen |
13:12 |
Dyrcona |
hm... too bad there are no good guidelines for random page cost. I'm tempted to set it to 1.0 on my new server. |
13:21 |
Dyrcona |
Well, drop it to 2.0. "Leave it at 2.0" is a comparison to the current production db, just to be perfectly clear. |
13:25 |
berick |
Dyrcona: FYI. i'll open a bug soon. http://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/berick/open-auth-login |
13:26 |
Dyrcona |
berick: Cool! |
13:26 |
Dyrcona |
That should be easy to test. |
13:27 |
Dyrcona |
We can start by altering the authenticate method of Cronscript and friends. |
13:29 |
berick |
yeah, and my initial tests look good. confirmed block count handling still works as expected. no mem leaks. |
13:31 |
Dyrcona |
Yeah, I was just looking at all of the "free me" comments. :) |
13:31 |
Dyrcona |
That's a good idea... |
13:35 |
|
jwoodard joined #evergreen |
16:55 |
bshum |
I'll read through more of it later, later tonight |
16:55 |
gmcharlt |
looking at the original string, the divs were there |
16:58 |
gmcharlt |
yeah, for that one it appears to be correclty parsing the [% |l(args) %]string[% END %] form |
17:01 |
pinesol_green |
News from qatests: Test Success <http://testing.evergreen-ils.org/~live> |
17:06 |
|
mmorgan left #evergreen |
17:07 |
|
jboyer-isl joined #evergreen |
17:16 |
bshum |
gmcharlt: Gotcha, then I won't worry about that too much |
05:01 |
pinesol_green |
News from qatests: Test Success <http://testing.evergreen-ils.org/~live> |
05:52 |
|
rlefaive joined #evergreen |
07:22 |
|
Dyrcona joined #evergreen |
08:48 |
bshum |
That commit notes about PG versions makes me wonder if we ought to have a discussion about using the newer PG versions with Evergreen. While saying min 9.4 is necessary, maybe we should make 9.6 the default for the installers if we plan to make it a better tested target? |
08:49 |
bshum |
Stretch comes with 9.6 anyways, and 18.04 next year, I suspect will ship with something newer too |
08:49 |
bshum |
Though I also have been thinking we could switch to using the PostgreSQL apt repos like we do now for Wheezy/Trusty and come up with a more consistent version across distro installers |
08:50 |
Dyrcona |
Well, I'd like to see 9.6 tested more before we make it the recommended version. |
08:50 |
bshum |
For sure, for variations of "tested more" too :) |
08:50 |
Dyrcona |
I'm using the PostgreSQL apt repositories for production. |
08:51 |
Dyrcona |
I don't think there will be any issues with 9.6. |
08:51 |
bshum |
Yeah I used PG apt repos too |
09:34 |
|
HTTP_____GK1wmSU joined #evergreen |
09:36 |
|
HTTP_____GK1wmSU left #evergreen |
14:10 |
Dyrcona |
Whee! Fun with pgtap and typoed usernames and wrong databases and..... |
14:10 |
Dyrcona |
Anyway, you'll be happy to know that all pgtap tests succeed when I get it right, including the new test that I added. |
14:22 |
Dyrcona |
Hmm... I think the code to make sure that the hold notification info is filled in messes with thing, at least on Firefox. |
14:23 |
Dyrcona |
yep, and some of the behavior looks familiar.... :) |
14:24 |
Dyrcona |
Guess I'll make a bug on Lp. |
14:54 |
Dyrcona |
So, I think I discovered Lp 1710404. |
14:54 |
pinesol_green |
Launchpad bug 1710404 in Evergreen "Code to require OPAC hold notification data causes minor breakage" [Undecided,New] https://launchpad.net/bugs/1710404 |
14:55 |
Dyrcona |
On the plus side, the code I'm working on appears to work. |
14:55 |
Dyrcona |
I'll see if I can write some Perl test code later. |
15:07 |
Dyrcona |
Weird. I don't get the header on the opac. |
15:07 |
Dyrcona |
No login link.... I didn't touch the OPAC code, yet. |
15:08 |
Dyrcona |
I'll check for errors. |
15:11 |
Dyrcona |
Nifty! The missing stuff is only missing in Firefox 54. It appears in Chromium. |
15:12 |
Dyrcona |
Ah, wait a minute... This has to do with having run the staff client first, doesn't it. |
15:13 |
Dyrcona |
Yep! If I quit Firefox and start it up again, all is well... |
15:14 |
Dyrcona |
Since I have them both browsers open I'll long in as both of my test subjects at once. |
15:43 |
|
D33P-B00K joined #evergreen |
15:45 |
|
D33P-B00K left #evergreen |
16:21 |
|
Dyrcona joined #evergreen |
16:52 |
Dyrcona |
Oy! Writing tests takes longer than writing the code that you're testing. At least in this case it does. |
17:01 |
pinesol_green |
News from qatests: Test Success <http://testing.evergreen-ils.org/~live> |
04:31 |
pinesol_green |
News from qatests: Test Success <http://testing.evergreen-ils.org/~live> |
04:34 |
|
abowling1 joined #evergreen |
05:31 |
|
jeff___ joined #evergreen |
05:31 |
|
dbs joined #evergreen |
09:21 |
bos20k |
Debian has a nice text interface that lets you change it when you do 'dpkg-reconfigure locales'. The same command in Ubuntu seems to just regenerate locale files. |
09:22 |
Dyrcona |
Yeap. You can also set it per user, which is what I typically do. |
09:23 |
* Dyrcona |
waits for gitlab-ce to update. |
09:23 |
bos20k |
Yeah, if you're testing something you might want to try setting environment variables. The locale files for the particular locale would need to exist on the system I would think though. |
09:24 |
Dyrcona |
yeah, that goes without saying. |
09:24 |
* Dyrcona |
considers setting his environment to Esperanto when going through customs. :) |
09:33 |
|
jvwoolf joined #evergreen |
09:36 |
* pinesol_green |
You don't want to get mixed up with someone like kmlussier. kmlussier is a loner, Dottie. A rebel. for her LP skills |
09:36 |
kmlussier |
:) |
09:37 |
mmorgan |
kmlussier++ |
09:37 |
csharp |
kmlussier: heh - your solution was going to be my next step to test |
09:37 |
mmorgan |
pinesol_green is in a bad mood this morning. |
09:37 |
pinesol_green |
mmorgan: Leave me alone, I'm busy right now. |
09:37 |
mmorgan |
see? |
09:56 |
pinesol_green |
Dyrcona: Have you confirmed your ISBN SPIDs with your service provider? |
10:12 |
terran |
Bmagic++ for work on bug 1655158 - our staff have wanted this for years! |
10:12 |
pinesol_green |
Launchpad bug 1655158 in Evergreen "Patron Search by date of birth" [Wishlist,Confirmed] https://launchpad.net/bugs/1655158 |
10:13 |
remingtron |
Dyrcona: a SIP testing tool tells me my server "actively refused" the connection. I think I have opened port 6001 already. Advice? |
10:15 |
Dyrcona |
remingtron: Can you connect from the localhost? I'd try with both the name and 127.0.0.1 as well as ::1 if IP6 is configured. |
10:15 |
remingtron |
thanks, I'll give that a try |
10:15 |
Bmagic |
terran++ for checking it out |
11:19 |
terran |
Or bug 1708485 even |
11:19 |
pinesol_green |
Launchpad bug 1708485 in Evergreen "Web Staff Client: Missing courier code on transit slip print templates" [Undecided,New] https://launchpad.net/bugs/1708485 |
11:34 |
|
DPearl joined #evergreen |
11:38 |
JBoyer |
terran, I'm assuming courier_code is a field on actor.org_unit, but is in defined in the IDL where you're testing? It also looks to me like it will have to be accessed as 'dest_location.courier_code' or similar. (I haven't looked at web client printing that much yet, but I think should work) |
11:38 |
csharp |
shortname is the same thing |
11:38 |
csharp |
wait - no it's not |
11:38 |
csharp |
@blame csharp |
14:34 |
berick |
Dyrcona: +1 to context-sensitive error messages. i thought you were suggesting something else. |
14:34 |
csharp |
berick++ |
14:39 |
kmlussier |
berick++ |
14:40 |
berick |
csharp++ # it's fun making code you don't have to test :) |
14:53 |
|
Jillianne joined #evergreen |
15:07 |
|
Dyrcona joined #evergreen |
15:28 |
* Dyrcona |
decides to look at something for feedback fest.... |
15:33 |
gmcharlt |
Dyrcona++ |
15:34 |
Dyrcona |
Lp 1411422 since it bit us today. :) |
15:34 |
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 |
15:34 |
Dyrcona |
Looks like it mainly needs a test and maybe a little additional code. |
15:36 |
miker |
grabbing 1051 for great justice |
15:38 |
pinesol_green |
[evergreen|Bill Erickson] LP#1695007 All-circulations slim DB VIEW - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=4a24441> |
15:38 |
pinesol_green |
[evergreen|Bill Erickson] LP#1695007 Webstafff circ group summary display fix - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=4105f8d> |
16:03 |
JBoyer |
Further infos and links on the site: https://wiki.evergreen-ils.org/doku.php?id=hack-a-way-2017 |
16:03 |
berick |
JBoyer++ |
16:06 |
Dyrcona |
JBoyer++ agoben++ |
16:32 |
pinesol_green |
News from qatests: Test Success <http://testing.evergreen-ils.org/~live> |
17:04 |
|
mmorgan left #evergreen |
17:08 |
kmlussier |
berick++ bug 1709476 |
17:08 |
pinesol_green |
Launchpad bug 1709476 in Evergreen "web client: item status recent circ history tab does not correctly display aged circulations" [Medium,Confirmed] https://launchpad.net/bugs/1709476 |
03:52 |
|
Jillianne joined #evergreen |
04:31 |
pinesol_green |
News from qatests: Test Success <http://testing.evergreen-ils.org/~live> |
06:20 |
|
tsadok joined #evergreen |
06:40 |
|
rlefaive joined #evergreen |
07:12 |
|
agoben joined #evergreen |
09:25 |
|
Dyrcona joined #evergreen |
09:25 |
|
jvwoolf1 joined #evergreen |
09:33 |
|
yboston joined #evergreen |
09:46 |
pinesol_green |
[evergreen|Cesar Velez] LP#1669534 - OPAC hold request should not default to first SMS carrier - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=f7deb92> |
10:11 |
|
bos20k joined #evergreen |
10:33 |
gmcharlt |
csharp: I've made an updated branch for bug 1098685 if you'd care to test again |
10:33 |
pinesol_green |
Launchpad bug 1098685 in Evergreen "User can select SMS notify without providing a valid address" [Medium,Confirmed] https://launchpad.net/bugs/1098685 |
10:47 |
|
gsams joined #evergreen |
10:51 |
csharp |
gmcharlt: trying to test - I think I'm fighting cache but it's still not working for me |
10:52 |
csharp |
I copied the files from your last commit into place and started testing - if there's something else I need, let me know |
10:52 |
gmcharlt |
csharp: does view source show holds-validation.js being linked? |
10:53 |
csharp |
hmm - no |
10:53 |
csharp |
lemme verify that the files are actually there |
11:50 |
|
khuckins joined #evergreen |
12:27 |
miker |
berick: are you handy? |
12:27 |
berick |
miker: i am |
12:27 |
miker |
and have time to maybe look at why some karma tests hate me? |
12:27 |
miker |
:) |
12:29 |
kmlussier |
Gee, I wonder what prompted that question. :) |
12:29 |
berick |
heh |
12:29 |
berick |
miker: point me at it |
12:33 |
miker |
ok, np |
12:37 |
|
jihpringle joined #evergreen |
12:57 |
pastebot |
"berick" at 64.57.241.14 pasted "for miker -- karma config update for lovefield" (12 lines) at http://paste.evergreen-ils.org/596 |
12:57 |
berick |
that fixes the tests for me |
12:58 |
berick |
fyi, the services have to be loaded in a certain order, that's why it's not a simple services/*.js import |
13:09 |
miker |
berick: bah ... thanks... I fixed a different test problem a week or so ago with that same thing. I should'a known |
13:13 |
miker |
kmlussier: so, berick's fix is pushed to the offline branch |
13:13 |
kmlussier |
miker: OK, I'll take a look when I have a moment. |
13:19 |
kmlussier |
It would be nice if there were a way to identify words that should never be stemmed. Like 'kissinger.' |
13:26 |
|
rlefaive joined #evergreen |
14:59 |
Dyrcona |
sure |
14:59 |
remingtron |
what value should I put in the "institution" variable? |
14:59 |
Dyrcona |
Whatever you want. It isn't really used, IIRC. |
15:00 |
remingtron |
I have two successful tests from 00sc_status.t, but test 3 fails with "Unable to connect to ILS..." |
15:00 |
Dyrcona |
I never run those tests... |
15:00 |
remingtron |
ha |
15:00 |
Dyrcona |
And, I'm not sure that they work with a real ILS, just the dummy one that comes with SIPServer. |
15:01 |
Dyrcona |
These are the SIPServer tests, right? |
15:01 |
remingtron |
yes |
15:01 |
remingtron |
so basically, a failure of those tests shouldn't concern me? |
15:02 |
|
mmorgan1 joined #evergreen |
15:03 |
Dyrcona |
Not in the least if you're talking to a real ILS. |
15:03 |
Dyrcona |
The test that's failing uses a username of sip_01. |
15:04 |
remingtron |
cool, thanks for calming my fears. |
15:06 |
Dyrcona |
heh. it might even fail with the ILS.pm supposed to be used for testing. |
15:09 |
Dyrcona |
Yeah, looks like it will just plain fail. |
15:12 |
JBoyer |
remingtron, While you can use just about anything for an institution, it is (can be?) used to select different options for some SIPServer backend options in oils_sip.conf. We have one institution that needs that msg_64_barcode_something_something turned off and another where it's turned on. |
15:13 |
Dyrcona |
Yeah. It will match up in the configs. I guess I sort of assumed..... |
15:19 |
Dyrcona |
The SIPServer will attempt to correct the client, but most clients ignore the server. :) |
15:20 |
remingtron |
good to know |
15:22 |
|
ohiojoe joined #evergreen |
15:28 |
berick |
remingtron: if you're planning to create more tests, this may be of value https://github.com/berick/pysip2 |
15:29 |
remingtron |
berick: thanks for sharing. I'm just scratching the surface at the moment, but I'll keep that in mind. |
15:30 |
rhamby |
berick++ : I've used pysip2 before and it's handy |
15:33 |
* Dyrcona |
usually uses phpsip2 but has used pysip2 |
15:41 |
|
abowling joined #evergreen |
15:50 |
|
kmlussier joined #evergreen |
16:14 |
|
mmorgan joined #evergreen |
16:31 |
pinesol_green |
News from qatests: Test Success <http://testing.evergreen-ils.org/~live> |
16:49 |
|
ningalls joined #evergreen |
17:05 |
|
mmorgan left #evergreen |
17:11 |
gsams |
Anyone have advice for completely overhauling permission groups? |
17:12 |
* gmcharlt |
claims 1050 in the name of miners everywhere! |
17:16 |
pinesol_green |
[evergreen|Cesar Velez] LP#1480432 - Added tests for permission.usr_perms() change - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=1f02799> |
17:16 |
pinesol_green |
[evergreen|Michele Morgan] LP#1480432: choose broadest depth if staff has same perm multiple times - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=2790b6e> |
17:16 |
pinesol_green |
[evergreen|Galen Charlton] LP#1480432: stamp DB update - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=db7b67a> |
17:16 |
kmlussier |
Yay! mmorgan++ cesardv++ gmcharlt++ |
18:13 |
csharp |
gsams: been planning something like that in PINES for some time, but it hasn't risen to the top - I would do it on a test server and work incrementally |
18:15 |
gsams |
csharp: Seems wise for sure. We've not really adjusted well over the years and I think sooner would be better than later for this process. |
18:17 |
jihpringle |
gsams: we overhauled one of our permission group sets a while ago (we have different groups for different library types) |
18:17 |
jihpringle |
we set up the new permission groups on a test server and then copied them over to our production server when we were ready |
18:18 |
jihpringle |
and then updated the users to use the new groups |
18:18 |
jihpringle |
we didn't remove the old groups until we have confirmation that everything was working as expected |
18:19 |
jihpringle |
it worked well for us, but it was just our K-12 perms we overhauled so only 15 or 16 libraries affected |
18:21 |
gsams |
jihpringle: awesome, thanks for sharing. We are only 14 public libraries, so I think we could make that work really well. |
18:22 |
jihpringle |
gsams: you' |
18:22 |
jihpringle |
you're welcome :) |
00:16 |
|
Jillianne joined #evergreen |
04:31 |
pinesol_green |
News from qatests: Test Success <http://testing.evergreen-ils.org/~live> |
06:40 |
|
rlefaive joined #evergreen |
07:06 |
|
JBoyer joined #evergreen |
07:19 |
|
rjackson_isl joined #evergreen |
09:25 |
|
jvwoolf left #evergreen |
09:28 |
|
jvwoolf joined #evergreen |
10:02 |
|
mmorgan1 joined #evergreen |
10:04 |
pinesol_green |
[opensrf|Graham Billiau] LP#1704090: ensure make install respects DESTDIR - <http://git.evergreen-ils.org/?p=OpenSRF.git;a=commit;h=e88891b> |
10:51 |
pastebot |
"gmcharlt" at 64.57.241.14 pasted "for feedback - is this in fact easier to understand?" (12 lines) at http://paste.evergreen-ils.org/579 |
10:51 |
bshum |
gmcharlt: were not or may not? |
10:51 |
gmcharlt |
bshum: in this context, definitely were not |
15:32 |
* JBoyer |
feels a dufus because he forgot to disable transparent_hugepages on the db, explaining all manner of "random" slowdowns in otherwise simple Qs. |
15:32 |
JBoyer |
Looked at an email csharp sent to the lists ages ago and was reminded. |
16:09 |
csharp |
JBoyer: glad it was helpful :-) |
16:24 |
Dyrcona |
jeff: Thought you might like to know that after I installed my branches for Lp 1542495 and Lp 1463943 my phpsip2 test script runs great. It was apparently a UTF-8 character causing it to crash. |
16:24 |
pinesol_green |
Launchpad bug 1542495 in SIPServer "OpenILS::SIP::clean_text() can crash" [Undecided,Confirmed] https://launchpad.net/bugs/1542495 |
16:24 |
pinesol_green |
Launchpad bug 1463943 in SIPServer "Non-ascii Unicode characters in messages cause SIP client problems" [Undecided,Confirmed] https://launchpad.net/bugs/1463943 |
16:25 |
gmcharlt |
Dyrcona: coordinates of that test script? |
16:26 |
Dyrcona |
gmcharlt: It's not a test script that one could integrate into Evergreen, but I put it on pastebin. Let me check my logs. |
16:26 |
gmcharlt |
Dyrcona: thanks! |
16:27 |
Dyrcona |
gmcharlt: https://pastebin.com/5jm9m2h3 |
16:28 |
* gmcharlt |
claims 1049 in the name of the too few journal publishers who never, ever, ever change their titles everywhere! |
16:29 |
Dyrcona |
It was written to test some SIP2 fine item details changes, but incidentally tests those branches as well. :) |
16:31 |
pinesol_green |
News from qatests: Test Failure <http://testing.evergreen-ils.org/~live> |
16:32 |
gmcharlt |
*cough* |
16:32 |
gmcharlt |
I'll deal with that test failure |
16:33 |
Dyrcona |
:) |
16:33 |
Dyrcona |
It doesn't look too bad. |
16:33 |
gmcharlt |
yeah, easy-peasy |
01:12 |
|
ericar joined #evergreen |
03:41 |
|
StomproJ joined #evergreen |
04:31 |
pinesol_green |
News from qatests: Test Success <http://testing.evergreen-ils.org/~live> |
06:40 |
|
rlefaive joined #evergreen |
07:18 |
|
rjackson_isl joined #evergreen |
07:32 |
|
agoben joined #evergreen |
14:35 |
ohiojoe |
and it looks like Jane and I will follow on the in-progress then? |
14:37 |
ohiojoe |
#action sandbergja and ohiojoe will follow-up with assigned "in-progress" users to try to preserve any progress made but not submitted |
14:38 |
ohiojoe |
#topic Progress on Docs Reorganization project |
14:38 |
sandbergja |
I would love some guidance here! |
14:39 |
sandbergja |
I'd like to gather some feedback on the reorganized manuals on the test server |
14:39 |
sandbergja |
What's the best way of going about the feedback gathering, do you think? |
14:42 |
kmlussier |
sandbergja: Have you sent out anything to one of the lists (docs or general) showing the changes you've made? |
14:42 |
kmlussier |
I feel like you have, but I'm not finding it. |
14:43 |
sandbergja |
kmlussier: I thought so too, but it looks like I haven't |
14:43 |
sandbergja |
ohiojoe: could you put that down as an action item for me, please? |
14:44 |
ohiojoe |
#action sandbergja will email one or more lists seeking feedback on reorganized manuals on the test server |
14:44 |
kmlussier |
sandbergja: If you don't get much feedback via the list, it might be worth scheduling another meeting focused on the reorg project. |
14:44 |
kmlussier |
But it would be good to see if you can get good discussion on the list first. |
14:45 |
sandbergja |
sounds like a plan |
14:45 |
kmlussier |
For reference: |
14:45 |
kmlussier |
#link http://docs-testing.evergreen-ils.org/ |
14:45 |
ohiojoe |
any other thoughts here before we move on? |
14:46 |
ohiojoe |
#topic Progress on documentation launchpad bugs |
14:48 |
kmlussier |
#link https://bugs.launchpad.net/evergreen/+bugs?field.tag=documentation |
16:06 |
jeffdavis |
Dyrcona: do you mean having generic (rather than Sitka specific) access to that environment for EG devs? |
16:06 |
jeffdavis |
Or just in general? |
16:13 |
Dyrcona |
I'm not sure. I requested Patron Authentication API and they responded about using their integration envoronment. |
16:14 |
Dyrcona |
They said, "We are currently speaking with an Evergreen contributor and have not been able to set up a test environment." |
16:14 |
Dyrcona |
Among other things. |
16:30 |
jeffdavis |
They must mean me. I requested access to their integration environment for Sitka (not for the broader EG community) - looks like they didn't receive part of my request and followed up while I was on vacation. |
16:31 |
pinesol_green |
News from qatests: Test Success <http://testing.evergreen-ils.org/~live> |
16:40 |
|
jvwoolf joined #evergreen |
16:47 |
jeffdavis |
Dyrcona: I sent them a follow up attempting to explain that my access to their API doesn't preclude others'. |
16:55 |
Dyrcona |
jeffdavis: OK. I'm going to discuss it with others here to see where our priorities are. I don't think i really have time for it right now. |
16:16 |
berick |
i'll add a note to the bug about revisiting |
16:16 |
gmcharlt |
ok |
16:16 |
gmcharlt |
so then, finally, back to miker about offline |
16:17 |
miker |
Really, I just want to get input on the serviceworker setup in use, and ask for testing |
16:17 |
csharp |
@band add The Version Treadmill Bullet |
16:17 |
pinesol_green |
csharp: Band 'The Version Treadmill Bullet' added to list |
16:17 |
miker |
we're using UpUp currently |
16:19 |
miker |
the branch is at http://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/miker/lp-1706107-offline-mode |
16:19 |
miker |
LP at https://bugs.launchpad.net/evergreen/+bug/1706107 |
16:19 |
pinesol_green |
Launchpad bug 1706107 in Evergreen "Offline mode for the Web Client" [Undecided,New] |
16:20 |
kmlussier |
I've already done a fair amount of testing and could probably add a signoff sometime soon. I probably would want to load it on a local test server just to make sure it still works as I remember. |
16:20 |
JBoyer |
I'm +1 to using the simplest thing that will work, though I've not been able to test that branch yet. |
16:20 |
kmlussier |
miker: Are we losing anything by not using the whole serviceworker framework? |
16:20 |
miker |
kmlussier: complication? ;) |
16:21 |
miker |
seriously, not that I can see |
16:21 |
miker |
that is /all/ upup tries to do |
16:21 |
miker |
and, now that it's all set up, it seems to do well |
16:22 |
berick |
ditto JBoyer |
16:22 |
miker |
kmlussier: when testing the new separate branch (was embedded in serials before) we'll need to watch for new 404s during offline mode |
16:23 |
miker |
one key thing is that upup has to know about (and cache) every single resource that the offline interface references, either directly or indirectily, via css include or xhr also |
16:24 |
miker |
for instance, I had to install the woff2 version of the bootstrap font because, even though we don't use it, it's requested by the css |
16:24 |
miker |
and causes a load failure in the offline UI if it can't be cached by the service worker |
16:26 |
miker |
to sum up: this is a call for testing, and secondarily, a call for critique of the implementation |
16:26 |
kmlussier |
ok, I'll try to carve time out for testing it. I think I know what to look for and how to break it if there are issues. :) |
16:26 |
gmcharlt |
ok, and with that, we've reached the end |
16:26 |
miker |
kmlussier: if anyone does ... ;) |
16:26 |
miker |
thanks all |
16:30 |
|
DPearl left #evergreen |
16:32 |
berick |
miker: k, yeah, that's another one that would benefit from a quick merge once it's updated. |
17:00 |
|
https_GK1wmSU joined #evergreen |
17:00 |
pinesol_green |
News from qatests: Test Success <http://testing.evergreen-ils.org/~live> |
17:01 |
|
https_GK1wmSU left #evergreen |
17:05 |
|
mmorgan1 left #evergreen |
17:37 |
Bmagic |
gmcharlt++ |