| 05:00 |
pinesol |
News from qatests: Failed Installing OpenSRF pre-requisites <http://testing.evergreen-ils.org/~live/test.7.html#2019-09-08T04:45:37,588967130-0400 -0> |
| 05:00 |
pinesol |
News from qatests: Failed Building OpenSRF <http://testing.evergreen-ils.org/~live/test.9.html#2019-09-08T04:45:37,616133766-0400 -2> |
| 05:01 |
pinesol |
News from qatests: Failed Running OpenSRF build tests <http://testing.evergreen-ils.org/~live/test.10.html#2019-09-08T04:45:37,643261966-0400 -4> |
| 05:01 |
pinesol |
News from qatests: Failed creating opensrf user and environment <http://testing.evergreen-ils.org/~live/test.12.html#2019-09-08T04:45:37,670052378-0400 -6> |
| 05:01 |
pinesol |
News from qatests: Failed configuring ejabberd <http://testing.evergreen-ils.org/~live/test.15.html#2019-09-08T04:45:37,697153810-0400 -8> |
| 05:01 |
pinesol |
News from qatests: Failed creating jabber users <http://testing.evergreen-ils.org/~live/test.16.html#2019-09-08T04:45:37,724083776-0400 -10> |
| 05:01 |
pinesol |
News from qatests: Failed configuring OpenSRF <http://testing.evergreen-ils.org/~live/test.17.html#2019-09-08T04:45:37,751685289-0400 -12> |
| 05:01 |
pinesol |
News from qatests: Failed start opensrf <http://testing.evergreen-ils.org/~live/test.18.html#2019-09-08T04:45:37,778719304-0400 -14> |
| 05:01 |
pinesol |
News from qatests: Failed stop opensrf <http://testing.evergreen-ils.org/~live/test.19.html#2019-09-08T04:45:37,805681747-0400 -16> |
| 05:01 |
pinesol |
News from qatests: Failed start opensrf <http://testing.evergreen-ils.org/~live/test.20.html#2019-09-08T04:45:37,832641068-0400 -18> |
| 05:01 |
pinesol |
News from qatests: Failed test opensrf <http://testing.evergreen-ils.org/~live/test.21.html#2019-09-08T04:45:37,859382142-0400 -20> |
| 05:01 |
pinesol |
News from qatests: Failed configuring websockets <http://testing.evergreen-ils.org/~live/test.22.html#2019-09-08T04:45:37,886279588-0400 -22> |
| 05:01 |
pinesol |
News from qatests: Failed stop opensrf <http://testing.evergreen-ils.org/~live/test.23.html#2019-09-08T04:45:37,913149142-0400 -24> |
| 05:01 |
pinesol |
News from qatests: Failed Installing Evergreen pre-requisites <http://testing.evergreen-ils.org/~live/test.26.html#2019-09-08T04:45:37,940167346-0400 -26> |
| 05:01 |
pinesol |
News from qatests: Failed Installing Angular web client <http://testing.evergreen-ils.org/~live/test.29.html#2019-09-08T04:45:37,966866093-0400 -28> |
| 05:01 |
pinesol |
News from qatests: Failed Building Evergreen <http://testing.evergreen-ils.org/~live/test.30.html#2019-09-08T04:45:37,993893592-0400 -30> |
| 05:01 |
pinesol |
News from qatests: Failed Running Evergreen tests <http://testing.evergreen-ils.org/~live/test.31.html#2019-09-08T04:45:38,021016559-0400 -32> |
| 05:01 |
pinesol |
News from qatests: Failed Installing Evergreen <http://testing.evergreen-ils.org/~live/test.32.html#2019-09-08T04:45:38,048219354-0400 -34> |
| 05:01 |
pinesol |
News from qatests: Failed Change File Ownership <http://testing.evergreen-ils.org/~live/test.33.html#2019-09-08T04:45:38,075283659-0400 -36> |
| 05:01 |
pinesol |
News from qatests: Failed Installing Dojo <http://testing.evergreen-ils.org/~live/test.35.html#2019-09-08T04:45:38,103904901-0400 -38> |
| 05:01 |
pinesol |
News from qatests: Failed configure apache <http://testing.evergreen-ils.org/~live/test.36.html#2019-09-08T04:45:38,130485884-0400 -40> |
| 05:01 |
pinesol |
News from qatests: Failed configure EG OpenSRF <http://testing.evergreen-ils.org/~live/test.37.html#2019-09-08T04:45:38,157130237-0400 -42> |
| 05:01 |
pinesol |
News from qatests: Failed configure EG Action/Trigger <http://testing.evergreen-ils.org/~live/test.38.html#2019-09-08T04:45:38,183979995-0400 -44> |
| 05:01 |
pinesol |
News from qatests: Failed Create Evergreen Database <http://testing.evergreen-ils.org/~live/test.41.html#2019-09-08T04:45:38,210903690-0400 -46> |
| 05:01 |
pinesol |
News from qatests: Failed Running pgTAP tests <http://testing.evergreen-ils.org/~live/test.42.html#2019-09-08T04:45:38,239757579-0400 -48> |
| 05:01 |
pinesol |
News from qatests: Failed start opensrf <http://testing.evergreen-ils.org/~live/test.43.html#2019-09-08T04:45:38,266705784-0400 -50> |
| 05:01 |
pinesol |
News from qatests: Failed Running autogen.sh <http://testing.evergreen-ils.org/~live/test.44.html#2019-09-08T04:45:38,293294847-0400 -52> |
| 05:01 |
pinesol |
News from qatests: Failed Restarting Apache - Expected 1 errors but encountered 2. <http://testing.evergreen-ils.org/~live/test.45.html#2019-09-08T04:45:38,319808447-0400 -54> |
| 05:01 |
pinesol |
News from qatests: Failed test EG opensrf <http://testing.evergreen-ils.org/~live/test.46.html#2019-09-08T04:45:38,346509683-0400 -56> |
| 05:01 |
pinesol |
News from qatests: Failed Running pgTAP live tests <http://testing.evergreen-ils.org/~live/test.47.html#2019-09-08T04:45:38,373125960-0400 -58> |
| 05:01 |
pinesol |
News from qatests: Failed Running settings-tester.pl <http://testing.evergreen-ils.org/~live/test.48.html#2019-09-08T04:45:38,399692248-0400 -60> |
| 05:01 |
pinesol |
News from qatests: Failed Running perl live tests <http://testing.evergreen-ils.org/~live/test.49.html#2019-09-08T04:45:38,426314366-0400 -62> |
| 05:01 |
pinesol |
News from qatests: Failed Gathering log summary <http://testing.evergreen-ils.org/~live/test.50.html#2019-09-08T04:45:38,453108549-0400 -64> |
| 05:01 |
pinesol |
News from qatests: Failed Log Output: config.log <http://testing.evergreen-ils.org/~live/test.51.html#2019-09-08T04:45:38,479855669-0400 -66> |
| 10:44 |
bshum |
Well that seems like a Debian problem to me :) |
| 11:38 |
|
sandbergja joined #evergreen |
| 12:03 |
pinesol |
[evergreen|Jane Sandberg] Docs: cleaning up headings in 3.4 release notes - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=3f4a956> |
| 12:04 |
sandbergja |
bshum++ #catching db errors over the weekend |
| 15:52 |
bshum |
Hmm, so installing LWP::Protocol::https from CPAN for Ubuntu 16.04 works fine, but on 18.04 it doesn't change anything and the test still fails :( |
| 16:01 |
|
GreyAzazel joined #evergreen |
| 16:02 |
|
GreyAzazel left #evergreen |
| 16:05 |
|
r_mcauliffe joined #evergreen |
| 16:25 |
bshum |
The distro installed version from 18.04 is 6.07 also |
| 16:25 |
bshum |
Same as the one from CPAN |
| 16:25 |
csharp |
oh |
| 16:25 |
bshum |
I checked the actual code bits too, and they're the same |
| 16:26 |
bshum |
So I think it's a problem with the IO::Socket::SSL |
| 16:26 |
bshum |
Or one of the other related perl bits |
| 16:27 |
bshum |
And something newer in 18.04 is reacting to the bad code in a different way than on 16.04 |
| 16:29 |
bshum |
Maybe this is the right approach: https://stackoverflow.com/questions/47662461/how-to-accept-self-signed-certificates-with-lwpuseragent |
| 16:30 |
bshum |
Having LWP::UserAgent accept the default generated SSL cert |
| 16:30 |
bshum |
Though, I guess the SSL cert hostname might vary from test system to system... so that could be weird. |
| 16:30 |
bshum |
And also "localhost" wouldn't match the SSL cert |
| 16:30 |
bshum |
Seems problematic |
| 16:32 |
bshum |
So yeah, I'm back to my suggestion to not do the test against https since it doesn't work consistently across all the testbeds |
| 16:32 |
bshum |
And also the more I look at the eg_vhost.conf addition where we're putting a staff login to lookup user data with and having the credentials just sitting out there, that's questionable to me too |
| 16:32 |
bshum |
For an out of the box install that is |
| 16:40 |
bshum |
Oh I see, the docs are in TechRef, no release notes :\ |
| 16:42 |
|
kirchmeierl joined #evergreen |
| 16:46 |
|
kirchmeierl joined #evergreen |
| 17:18 |
bshum |
Hmm |
| 17:23 |
bshum |
https://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/bshum/lp1817645-perl-test-fixes |
| 17:23 |
bshum |
Those two commits worked for me on Ubuntu 18.04 |
| 17:23 |
bshum |
Retesting the whole branch on fresh Ubuntu 16.04 next |
| 17:29 |
r_mcauliffe |
Hey Guys, I'm trying to install opensrf on debian-buster. Got the install working correctly, the make file needed to adjust the libgcrypt package for buster (Happy to upload my makefile changes to git soon). Everything installed correctly, and was following the install guide on the web and came across this problem while trying to start it: |
| 17:30 |
r_mcauliffe |
Subroutine section_pkg redefined at (eval 921) line 4 (#1) |
| 17:30 |
r_mcauliffe |
(W redefine) You redefined a subroutine. To suppress this warning, say |
| 17:41 |
bshum |
Or sending an email to the general or dev mailing lists :) |
| 17:42 |
bshum |
I'm just a casual volunteer who's poking at things in my offtime |
| 17:42 |
r_mcauliffe |
will do, thank you bshum ! |
| 17:44 |
bshum |
Sure thing |
| 17:44 |
bshum |
I haven't seen rabbitmq before, but I do know that OpenSRF is pretty specialized into how it is using (or abusing) ejabberd for messaging between the various bits |
| 18:04 |
bshum |
jeffdavis: gmcharlt: So my branch works for solving the perl livetest for basic auth api on Ubuntu 16.04 and 18.04. I have to test wider with Debian, but I don't have my cool Ansible setup for Debian finished yet to make the install simple and breezy |
| 18:05 |
bshum |
I still have my doubts about using https for the test against localhost and ignoring the cert anyways, plus also now dumping additional pre-req stuff onto the installs that I'm not sure we will use everywhere |
| 18:05 |
bshum |
But eh, working code wins? :D |
| 18:53 |
r_mcauliffe |
well rabbitmq would use erlang rather than ejabberd, but a very cut down version of it. I was just thinking if there is a product that could be usable that would suit evergreens purpose than something y'all have to maintain, might be worth looking into. But like I said VERY new to this, so my opinion counts for diddly squat lol |
| 19:09 |
|
r_mcauliffe left #evergreen |
| 19:40 |
|
sandbergja joined #evergreen |
| 20:05 |
|
sandbergja joined #evergreen |
| 20:13 |
|
sandbergja joined #evergreen |
| 20:48 |
|
sandbergja joined #evergreen |
| 23:01 |
pinesol |
News from qatests: Failed Running pgTAP live tests <http://testing.evergreen-ils.org/~live/test.47.html#2019-09-08T23:00:57,525131392-0400 -0> |
| 23:01 |
pinesol |
News from qatests: Failed Running perl live tests <http://testing.evergreen-ils.org/~live/test.49.html#2019-09-08T23:00:57,553207498-0400 -2> |
| 09:08 |
|
aabbee joined #evergreen |
| 09:28 |
csharp |
bshum++ |
| 11:02 |
pinesol |
News from qatests: Failed Running pgTAP live tests <http://testing.evergreen-ils.org/~live/test.47.html#2019-09-07T11:00:49,903620999-0400 -0> |
| 11:02 |
pinesol |
News from qatests: Failed Running perl live tests <http://testing.evergreen-ils.org/~live/test.49.html#2019-09-07T11:00:49,931658935-0400 -2> |
| 12:05 |
bshum |
Hmm |
| 12:06 |
bshum |
So that PGTap test isn't so bad to fix. We're missing some closing parenthesis in the tests |
| 12:06 |
bshum |
And one of the test parameters returned a different result than the actual thing being matched |
| 12:06 |
bshum |
I guess an Inactive patron returns "not_found" rather than "blocked" |
| 12:07 |
* bshum |
makes a patch to toss on followup |
| 12:07 |
bshum |
And then I'll see what this perl live test is balking at next :) |
| 12:22 |
bshum |
Hmm |
| 12:23 |
bshum |
That live perl test failure seems more complicated |
| 12:23 |
bshum |
https://bugs.launchpad.net/evergreen/+bug/1817645/comments/1 |
| 12:23 |
pinesol |
Launchpad bug 1817645 in Evergreen "Configurable patron auth and retrieval" [Wishlist,Fix committed] |
| 12:24 |
bshum |
In jeffdavis comments on the feature, they described a bug with LWP::Protocol::https that required a newer version from CPAN to resolve, 6.07 and greater |
| 12:24 |
bshum |
Couple issues... that dependency isn't in the core Makefile.install for the various distros |
| 12:25 |
bshum |
But also, on Ubuntu 18.04, I have the latest version of that package, and I'm still unable to get successful test results from the API test |
| 12:25 |
* bshum |
pushes the pgtap fix patch first, and then goes to contemplate lunch |
| 12:29 |
pinesol |
[evergreen|Ben Shum] LP#1817645: Fix pgtap tests - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=1421240> |
| 12:41 |
bshum |
So it's definitely the certificate error affecting the running of the test |
| 12:41 |
bshum |
Changing the endpoint to http://localhost (without the https) allowed it to succeed |
| 12:43 |
bshum |
I'd be tempted to let that be the permanent change for the purposes of the test, since the access is restricted to localhost only anyways |
| 12:43 |
bshum |
and in a real productive environment, someone should be changing it to have a real SSL cert, have real auth user to look up data (rather than the default admin account), etc. |
| 12:43 |
bshum |
So........... hmm, I'll ponder that |
| 12:43 |
bshum |
While I eat my sandwich :D |
| 13:38 |
jeffdavis |
I think the Ubuntu package for LWP::Protocol::https is installed as a dependency when you install libwww-perl, so should be available on any system running OpenSRF. It would make sense for Makefile.install to the later non-buggy version from CPAN though. |
| 13:54 |
jeffdavis |
Switching to http doesn't feel great but it does still confirm whether the API endpoint is returning correct responses, which is the purpose of the test. |
| 15:54 |
|
sandbergja joined #evergreen |
| 18:27 |
bshum |
jeffdavis: I haven't read enough and finished spinning older distro VMs, but if the bug is only from those SSL checks, then switching to http for the test would resolve for everybody's tests |
| 18:28 |
bshum |
Without needing to upgrade that package |
| 18:28 |
bshum |
And if I've already got the latest package on 18.04 and it's still broken, that seems like there's something deeper problematic with it than just the version |
| 18:34 |
bshum |
also systemd-- # apt.systemd.daily install is super annoying |
| 18:39 |
* bshum |
finishes setting up fresh Ubuntu 16.04 to retest |
| 19:41 |
bshum |
So much faster to clone virtualbox VMs once they've been compacted down in size, whee! |
| 20:07 |
bshum |
Very interesting |
| 20:07 |
bshum |
So, on Ubuntu 16.04, changing it to http for the test, definitely makes it work. So that's consistent |
| 20:08 |
bshum |
But also installing LWP::Protocol::https via CPAN and restarting apache, also lets the test proceed happily too |
| 20:08 |
bshum |
I wonder why that's different on Ubuntu 18.04 now, hmm |
| 21:43 |
bshum |
Reading https://github.com/libwww-perl/LWP-Protocol-https/issues/47 and based on the source for LWP::Protocol::https, I think it's still broken |
| 21:52 |
bshum |
Seems to me that if we're passing the value to ignore SSL cert anyways, we're already not paying attention to the security as part of the test |
| 21:52 |
bshum |
So having it go to http instead of https seems moot |
| 22:27 |
|
sandbergja joined #evergreen |
| 23:02 |
pinesol |
News from qatests: Failed Running pgTAP live tests <http://testing.evergreen-ils.org/~live/test.47.html#2019-09-07T23:00:56,032084177-0400 -0> |
| 23:02 |
pinesol |
News from qatests: Failed Running perl live tests <http://testing.evergreen-ils.org/~live/test.49.html#2019-09-07T23:00:56,061217285-0400 -2> |
| 11:01 |
berick |
Dyrcona: you have to raise the upload size.. |
| 11:02 |
berick |
e.g. client_max_body_size 25m; |
| 11:02 |
Dyrcona |
nginx, I presume. |
| 11:02 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 11:02 |
Dyrcona |
berick: How's Dorian treating you? My family's in the thick of it in Wilmington. |
| 11:02 |
berick |
well, what I posted was for uploading files for import |
| 11:02 |
berick |
not sure if that's what you meant |
| 15:02 |
pinesol |
[evergreen|Galen Charlton] LP#1840327: add release notes - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=b577e78> |
| 15:02 |
Dyrcona |
Ah... That will do it. |
| 15:20 |
|
zbanks joined #evergreen |
| 15:27 |
csharp |
Dyrcona: https://drive.google.com/file/d/1GBwpFLxPZ79sBsP0zcXSdX-_eGm4OWnl/view?usp=sharing - the second indicator column is misaligned |
| 15:28 |
csharp |
if I remove some of the long text in one of the fields (or reduce the zoom enough) it corrects |
| 15:29 |
csharp |
I also played with the CSS padding in dev tools and corrected it that way too |
| 15:30 |
csharp |
the problem didn't exist in the new ng staff catalog when I tested that on one of the "problem" records |
| 15:30 |
csharp |
but does in the AngJS version on current-ish master |
| 15:33 |
Dyrcona |
csharp: Maybe that's what they were trying to explain to me yesterday. I was told it happens with tags that have a second indicator. |
| 15:34 |
Dyrcona |
I looked at the MARC edit view and not that one, let me look at the bibs they sent me again. |
| 15:34 |
Dyrcona |
I also was not sent screen shots. |
| 16:09 |
jeff |
Dyrcona, csharp: does this happen in the opac, or only in the web staff client? |
| 16:09 |
Dyrcona |
Haven't checked the OPAC. |
| 16:10 |
jeffdavis |
gmcharlt: bug 1662297 is a bugfix rather than a feature request, but the pullrequest would involve changes to the install process so may be worth a look for the 3.4 beta (you know, in all that spare time you have right now) |
| 16:10 |
pinesol |
Launchpad bug 1662297 in Evergreen "Install directory hardcoded in web client build and tests" [Low,Confirmed] https://launchpad.net/bugs/1662297 |
| 16:12 |
Dyrcona |
Well, my OPAC isn't returning results for tcn searches and I did not make a note of the titles, plus I'm off the clock, so not putting much more effort into it. :) |
| 16:22 |
|
bwicksall joined #evergreen |
| 16:30 |
Dyrcona |
And, I just got a Firefox update to install. If I remember, I'll look at that again on Monday. |
| 17:20 |
pinesol |
[evergreen|Galen Charlton] LP#1817645: (follow-up) sync schema update script - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=56bab3e> |
| 17:20 |
pinesol |
[evergreen|Galen Charlton] LP#1817645: stamp schema update - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=e850739> |
| 17:20 |
pinesol |
[evergreen|Galen Charlton] LP#1817645: add release notes - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=46c8e3a> |
| 17:22 |
gmcharlt |
jeffdavis: re 1662297, I'm willing to consider it for the 3.4-rc, but won't make it into the beta given the time I would need to test it properly |
| 17:22 |
jeffdavis |
ok |
| 17:37 |
* gmcharlt |
claims 1181 |
| 17:42 |
pinesol |
Showing latest 5 of 8 commits to Evergreen... |
| 18:15 |
jeffdavis |
gmcharlt++ |
| 21:09 |
|
tlittle joined #evergreen |
| 22:36 |
|
sandbergja joined #evergreen |
| 23:02 |
pinesol |
News from qatests: Failed Create Evergreen Database <http://testing.evergreen-ils.org/~live/test.41.html#2019-09-06T23:00:54,913184280-0400 -0> |
| 23:16 |
bshum |
Oops, well that's fun. Duplicate key constraint in the seed data |
| 23:28 |
bshum |
Looks like some stuff snuck back in after the cleanup done in eee5c5948ca |
| 23:29 |
pinesol |
bshum: [evergreen|Dan Wells] LP#1759343 Clean up data seed values - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=eee5c59> |
| 23:31 |
bshum |
That led to the duplicate settings error |
| 23:31 |
bshum |
Removing them again should fix things up |
| 23:39 |
pinesol |
[evergreen|Ben Shum] LP#1816475: Cleanup 950.data.seed-values.sql - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=5d9bc66> |
| 23:59 |
bshum |
And much better on my test server :) |
| 23:59 |
* bshum |
sleeps more happily now |
| 10:59 |
jeff |
...or a logins table, and avoid updating actor.workstation on each and every login. |
| 10:59 |
jeff |
but useful any way you spell it. |
| 11:00 |
mmorgan |
At the very least a create date would be useful. |
| 11:02 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 11:02 |
jeff |
all the metadata. |
| 11:02 |
jeff |
create date, creating user, etc. :-) |
| 11:04 |
|
zbanks joined #evergreen |
| 13:12 |
|
rsoulliere joined #evergreen |
| 13:12 |
Dyrcona |
berick: PhantomJS is dead, i.e. archived, and the person who was going to take it over and modernize it, gave up. |
| 13:13 |
* Dyrcona |
considered doing so, since it uses Qt Webkit, but no time.... |
| 13:13 |
Dyrcona |
We should find an alternative for testing JS, like headless Chromium if that really is an option. |
| 13:13 |
berick |
Dyrcona: i agree |
| 13:14 |
Dyrcona |
Again, I'm short on time, so.... It's easy for me to say these things. :) |
| 13:19 |
|
khuckins joined #evergreen |
| 14:17 |
dluch |
dbs++ |
| 14:17 |
rsoulliere |
I will have more info about the server situation. |
| 14:17 |
remingtron |
dbs++ |
| 14:17 |
dluch |
Then sandberja made a copy of the docs on a test page, http://docs-testing.evergreen-ils.org/. Thanks, sandberja! |
| 14:17 |
dluch |
sandbergja++ |
| 14:17 |
jweston |
dbs++ |
| 14:17 |
dluch |
Thanks, rsoulliere |
| 14:17 |
remingtron |
sandbergja++ |
| 14:33 |
dluch |
gmcharlt++ |
| 14:33 |
dluch |
#info Documentation server needs |
| 14:34 |
dluch |
I wasn't sure who added this one, but rsoulliere, it was you, I assume |
| 14:34 |
rsoulliere |
At Mohawk, library access to servers required to maintain the docs is being questioned by IT. We are still negotiating with our IT overlords to regain access. Could http://docs-testing.evergreen-ils.org be made the live docs server since it is working? In fact, we should probably have multiple servers at a few institutions in a mirror set up for mo |
| 14:34 |
rsoulliere |
re reliability/redundancy going forward. |
| 14:34 |
dluch |
Take it away! |
| 14:37 |
dluch |
redundancy does sound like a good idea |
| 14:37 |
gmcharlt |
rsoulliere: from the perspective of a member of the infrastructure team... we would be happy to accommodate |
| 14:37 |
gmcharlt |
specificaly, working out a plan to put on a new docs VM on the hosting platform that GPLS and BOR are kindly continuing to donate to the project |
| 14:37 |
dluch |
gmcharlt: I was just in the middle of typing a question about that. Good, thanks! |
| 14:38 |
gmcharlt |
if docs-testing becomes the new one, we'll need to plan on moving it to the new GPLS hosting anyway, but we can readily sort out such details |
| 14:39 |
rsoulliere |
Was there any assistance you needed from me by working on the server or developing a git repo with the tools/instructions for setting up? Or was that covered? |
| 14:39 |
dluch |
so, is that something the infrastructure team can take on to tackle? |
| 14:40 |
gmcharlt |
yeah, in conjunction with rsoulliere (and yeah, I think we would want help and/or infodumps to make sure that the setup is suitable for the docs needs) |
| 19:27 |
|
stephengwills joined #evergreen |
| 20:56 |
|
HomerPublic joined #evergreen |
| 21:40 |
dbs |
gmcharlt: https://bugs.launchpad.net/evergreen/+bug/1517298 has a working patch for Matomo, although ideally it would use OU settings instead of config.tt2 |
| 21:40 |
pinesol |
Launchpad bug 1517298 in Evergreen "Catalogue should support Matomo, a privacy-sensitive alternative to Google Analytics" [Wishlist,New] |
| 23:02 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 23:59 |
|
jeff joined #evergreen |
| 09:29 |
pinesol |
Launchpad bug 1840669 in Evergreen 3.3 "Aging Circulations Removes Auto-Renewal Information" [High,Confirmed] https://launchpad.net/bugs/1840669 |
| 09:30 |
Dyrcona |
Also, if you feel like bumping the importance of Lp 1835577 that would be fine with me. I'm not sure how important it is, since I don't do reports, myself. |
| 09:30 |
pinesol |
Launchpad bug 1835577 in Evergreen 3.3 "Combined Aged and Active Circulations Report Source not Exposed to Auto-Renewal Fields" [Undecided,Confirmed] https://launchpad.net/bugs/1835577 |
| 09:33 |
Dyrcona |
I also have a branch for Lp 1839002 but haven't added it to the bug, yet, because we haven't tested it. I plan to install it on training at the end of the day today. |
| 09:33 |
pinesol |
Launchpad bug 1839002 in Evergreen "auto_renewal field stored as NULL/TRUE. Should be FALSE/TRUE" [High,In progress] https://launchpad.net/bugs/1839002 - Assigned to Jason Stephenson (jstephenson) |
| 09:33 |
Dyrcona |
It takes a while to update the existing fields. |
| 09:34 |
Dyrcona |
I will likely have something for Lp 1835085 by lunch time. |
| 10:54 |
Dyrcona |
What does everything about removing an api in a bug fix. I think this api (open-ils.circ.renew.auto) was added as a result of misunderstanding. The feature could easily have been implemented with an auto_renewal flag, the same way that sip_renewal and opac_renewal work. |
| 11:02 |
* Dyrcona |
"deprecates" it.... |
| 11:02 |
|
bos20k joined #evergreen |
| 11:03 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 11:22 |
|
bos20k joined #evergreen |
| 11:43 |
|
yboston joined #evergreen |
| 11:49 |
|
jihpringle joined #evergreen |
| 13:12 |
|
yboston joined #evergreen |
| 13:16 |
Dyrcona |
gsams: To be clear, auto renewal and OPAC renewal are doing the same thing, so changing the setting for the OPAC renewals affects auto renewals. I was mildly surprised when I saw that in the code this morning, but none of my patches change that behavior. |
| 13:22 |
* mmorgan |
realizes she misspoke earlier regarding "all renewals". Should have read *opac* renewals |
| 13:25 |
* Dyrcona |
has a branch for that ready, too, but will wait to push it until after we've tested it. May be typos, etc. |
| 13:26 |
Dyrcona |
By "push it" I mean to the working repo. |
| 13:30 |
|
khuckins joined #evergreen |
| 13:34 |
|
yboston joined #evergreen |
| 20:13 |
|
sandbergja joined #evergreen |
| 20:23 |
|
sandbergja joined #evergreen |
| 22:19 |
|
sandbergja joined #evergreen |
| 23:01 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 10:54 |
|
yboston joined #evergreen |
| 10:54 |
miker |
mmorgan: they were flushed (all but local storage, for the ws values) |
| 10:55 |
miker |
bah, same result in firefox |
| 10:55 |
Bmagic |
Everyone knows the real test results come from IE |
| 10:56 |
miker |
IE 5, to be exact |
| 10:56 |
Bmagic |
"It ain't broke if it works in Internet Explorer" |
| 10:59 |
Bmagic |
I installed Windows 95 on a VM recently. Hilarious. IE 1.0 |
| 10:59 |
Dyrcona |
Pfft... It's just plain broken. |
| 11:00 |
Bmagic |
The days when you had to "install" TCP/IP |
| 11:03 |
pinesol |
News from qatests: Failed Create Evergreen Database <http://testing.evergreen-ils.org/~live/test.41.html#2019-08-29T11:00:49,587271975-0400 -0> |
| 11:04 |
Dyrcona |
Eh, well, the Internet was "new..." |
| 11:04 |
gmcharlt |
^ bah, humbug |
| 11:04 |
gmcharlt |
er, ^^^ |
| 11:27 |
|
mmorgan1 joined #evergreen |
| 11:27 |
|
khuckins joined #evergreen |
| 11:53 |
Bmagic |
well, action.hold_request_permit_test still results in a failure "config.rule_age_hold_protect.prox" - It doesn't seem that this code consults the proximity adjustment table |
| 11:54 |
Bmagic |
The hold rule that it choses is perfect. It's the one I created to specifically allow the two systems to lend to eachother. And it's an Allow rule. Even though it's an allow rule, the rest of the permit test code "IF hold_transit_prox > age_protect_object.prox THEN" |
| 11:56 |
Dyrcona |
hold_transit_prox should be calculated using proximity adjustments. If not, that's a bug. |
| 11:56 |
Dyrcona |
Could be your adjustment is incorrect. |
| 11:57 |
Bmagic |
I'm using the system to adjust to the other system. Maybe I need to install adjustment rows for each combo of branches? |
| 12:14 |
Dyrcona |
Maybe. I'd have to look at the script again. |
| 12:15 |
Bmagic |
yeah, -u |
| 12:15 |
Bmagic |
Refreshing proximity of org units;Successfully updated the organization proximity |
| 12:18 |
Bmagic |
yeah, as I suspected, didn't change the outcome of the permit test |
| 12:18 |
Dyrcona |
All right, my bad for giving you the wrong option... |
| 12:19 |
Bmagic |
at this point, I'm 99% sure that it doesn't take into account the adjustments |
| 12:19 |
Dyrcona |
Well, you could open a bug or you can tell the libraries that they can't share age protected items with each other. |
| 17:03 |
|
sandbergja joined #evergreen |
| 17:05 |
|
mmorgan left #evergreen |
| 20:39 |
|
sandbergja joined #evergreen |
| 23:03 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 23:43 |
|
sandbergja joined #evergreen |
| 10:58 |
jeff |
but yes, I don't think anywhere in this conversation we've been suggesting making the PIN take the place of a password when logging into Evergreen as a patron. |
| 11:00 |
jeff |
another challenge is "library PIN or password" as a label on some vendor sites. |
| 11:00 |
JBoyer |
jeff, absolutely. But there is some value in making sure it's clear in the logs that no one discussing it would ever want it to work that way. I would imagine the first naive attempt to implement it would. "AND (pwd = ... OR pin =... )" |
| 11:01 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 11:01 |
Dyrcona |
I also imagine there will be some confusion among staff and patrons when such a feature is rolled out. |
| 11:04 |
Dyrcona |
I imagine we should call it "Remote Access PIN" or something like that. I don't know what would make the most sense to the most people. Maybe "Third Party PIN"? |
| 11:04 |
Dyrcona |
Now, we just have to code it up and write release notes! :P |
| 13:14 |
pinesol |
Launchpad bug 1779467 in Evergreen "Enhance Mark Item Discard/Weed Functionality" [Wishlist,Fix committed] https://launchpad.net/bugs/1779467 |
| 13:15 |
Dyrcona |
:) |
| 13:15 |
jeff |
mmorgan++ thanks |
| 13:15 |
Dyrcona |
jeff: I don't think it changes anything significant in the backend code. I reorganized it a little, but the functionality is the same. I deliberately tested it to make sure. |
| 13:16 |
Dyrcona |
I don't recall if I tested with a damaged fee, though it did charge the price of the item when the settings were correct. |
| 13:17 |
Dyrcona |
Others can answer for their testing of it. :) |
| 13:18 |
jeff |
I wasn't too concerned with regression, just didn't realize that that bug had evolved beyond its title (though it was my first guess when you mentioned "recently made some changes to the mark items functionality"), and I'm curious to see if it interacts with some changes we've been using for Missing Pieces. |
| 13:18 |
Dyrcona |
Ah, cool. |
| 13:18 |
jeff |
There are things in Missing Pieces that I'd like to rip out, but I suspect would need to be placed behind an OU setting or flag. |
| 13:39 |
jeff |
i don't remember without looking at docs what we did for "we're only going to charge them for a missing disc replacement fee, not the full price" -- i think it was "do that before the system bills full price". pretty sure we didn't suggest that the item price be adjusted down to the partial amount. that would have been silly of us. |
| 13:48 |
|
jonadab joined #evergreen |
| 13:59 |
|
sandbergja_ joined #evergreen |
| 14:24 |
pinesol |
[evergreen|Dan Wells] LP#1796945 Reporter cloning and creation fixes - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=6cdbb3d> |
| 14:24 |
pinesol |
[evergreen|Dan Wells] LP#1796945 Match new path_label/alias standard - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=53e4550> |
| 15:02 |
|
mmorgan1 joined #evergreen |
| 15:18 |
|
khuckins joined #evergreen |
| 15:57 |
|
jvwoolf left #evergreen |
| 16:31 |
|
mdriscoll left #evergreen |
| 16:49 |
|
sandbergja_ joined #evergreen |
| 16:58 |
|
nfBurton joined #evergreen |
| 16:58 |
pinesol |
[evergreen|Andrea Buntz Neiman] docs: error correction to 3.1.14 release notes - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=43413aa> |
| 17:13 |
|
mmorgan left #evergreen |
| 17:16 |
pinesol |
[evergreen|April Durrence] Docs: add info about merge tracking - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=f4ac25f> |
| 17:26 |
pinesol |
[evergreen|dluchenbill] Docs: add checkin trigger holds and cancel transit - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=9bf8d67> |
| 17:28 |
pinesol |
[evergreen|Dan Wells] Forward-port 3.1.14 upgrade script - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=3d5b1d0> |
| 17:28 |
pinesol |
[evergreen|Dan Wells] Forward-port 3.2.8 upgrade script - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=fabf404> |
| 17:28 |
pinesol |
[evergreen|Dan Wells] Forward-port 3.3.3 upgrade script - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=1eaf0e3> |
| 17:38 |
|
khuckins joined #evergreen |
| 17:46 |
pinesol |
[evergreen|Derek C. Zoladz] Docs: LP #1803415: Location of MARC Editor 'Delete' Button - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=7223710> |
| 17:46 |
pinesol |
[evergreen|Jane Sandberg] Docs: adding alt text to MARC Editor chapter images - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=5489249> |
| 20:18 |
|
Dyrcona joined #evergreen |
| 22:59 |
|
sandbergja joined #evergreen |
| 23:01 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 07:08 |
|
rjackson_isl joined #evergreen |
| 08:30 |
|
bos20k joined #evergreen |
| 08:44 |
|
mmorgan joined #evergreen |
| 09:05 |
pinesol |
[evergreen|Remington Steed] LP#1785061: Split filter value on comma for "in list" and the like - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=758cdcf> |
| 09:05 |
pinesol |
[evergreen|Galen Charlton] LP#1785061: move the filter value munging to the template service - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=9e939ca> |
| 09:13 |
|
yboston joined #evergreen |
| 09:17 |
pinesol |
[evergreen|James Fournie] LP1751800 - fix fields fields reversing - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=d97b45c> |
| 09:23 |
|
aabbee joined #evergreen |
| 09:27 |
|
jvwoolf joined #evergreen |
| 10:04 |
|
alynn26_away joined #evergreen |
| 10:13 |
pinesol |
[evergreen|Bill Erickson] LP1839548 Angular catalog holds patron barcode link - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=3433d29> |
| 10:14 |
|
sandbergja joined #evergreen |
| 10:24 |
|
bos20k_ joined #evergreen |
| 10:35 |
|
cmalm joined #evergreen |
| 10:37 |
|
cmalm96 joined #evergreen |
| 11:01 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 12:09 |
csharp |
about to jump into a meeting, but I've been looking at bug 1796945 and am interested in discussing it so dbwells 's work can make it into 3.4 (if that's what we decide) |
| 12:09 |
|
khuckins joined #evergreen |
| 12:09 |
pinesol |
Launchpad bug 1796945 in Evergreen 3.3 "Report templates cloned from those created on XUL client causing error or producing different results" [High,Confirmed] https://launchpad.net/bugs/1796945 |
| 12:10 |
|
jihpringle joined #evergreen |
| 12:10 |
csharp |
I'm wondering if dbwells 's branch can be signed off on so we get its improvements and the issues that JBoyer and Tina found can be split off into a separate bug to be addressed later? |
| 12:10 |
csharp |
(note that I've done zero testing so far - just trying to figure out a sensible approach) |
| 12:11 |
csharp |
this also assumes that Tina's and JBoyer 's issues are not *caused* by dbwells 's branch (which is not obvious to me one way or the other at this point) |
| 12:12 |
|
yboston joined #evergreen |
| 12:12 |
csharp |
@eightball is this when I finally make the time and effort investment to learn the reporter's backend? |
| 12:12 |
pinesol |
csharp: I doubt it very much. |
| 12:13 |
JBoyer |
csharp, dbwells's branch helps re-align the generated SQL for xul and web reports, but the issues that pop up are there already, just hidden because you can't reliably translate reports without that branch. |
| 12:14 |
csharp |
oh, I see - so that would be an argument in favor of spinning the newly-found issues into their own bug |
| 12:14 |
JBoyer |
So his branch is a very important step along the way, but it doesn't really help much without fixing the underlying issue because while you can in fact clone reports now, you still can't actually edit them without things breaking. |
| 12:15 |
csharp |
oh ok - again, I haven't tested the branch at all yet |
| 12:15 |
* dbwells |
tries to catch up on that bug |
| 12:15 |
JBoyer |
I've looked >< this much into how that could potentially be mitigated, but it's going to be a lot of uphill work. |
| 12:15 |
csharp |
yeah |
| 21:58 |
|
sandbergja joined #evergreen |
| 22:09 |
|
sandbergja joined #evergreen |
| 22:47 |
|
sandbergja joined #evergreen |
| 23:01 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 23:53 |
|
sandbergja joined #evergreen |
| 10:26 |
|
sandbergja joined #evergreen |
| 10:47 |
|
jvwoolf joined #evergreen |
| 10:52 |
|
Christineb joined #evergreen |
| 11:02 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 11:04 |
|
tlittle joined #evergreen |
| 11:12 |
|
mmorgan joined #evergreen |
| 11:18 |
Bmagic |
Isn't there still and oustanding issue with Evergreen running on 18.04? |
| 11:53 |
bshum |
Yeah, right now the bionic makefile uses the PG community apt source and then grabs PG 9.6 for install |
| 11:53 |
bshum |
Bionic does have PG 10 out of the box |
| 11:53 |
Bmagic |
Anyone here running 18.04 on the database server in production? |
| 11:55 |
bshum |
There was some bug with PG10 for awhile, but we fixed those functions during the last conference I think. Though we still need to test other functions out |
| 11:58 |
bshum |
Yeah I was thinking of https://bugs.launchpad.net/evergreen/+bug/1820339 which was fix released, so that's fine |
| 11:58 |
pinesol |
Launchpad bug 1820339 in Evergreen "Postgres 10 support: Vandelay Edition" [Medium,Fix released] |
| 12:07 |
|
jihpringle joined #evergreen |
| 12:27 |
jeff |
Dusting off plans for supporting "pick up other people's holds" via SIP2. |
| 13:54 |
|
khuckins joined #evergreen |
| 14:03 |
csharp |
sandbergja: around? |
| 14:04 |
sandbergja |
csharp: yup! I'm here |
| 14:05 |
csharp |
I'm testing your fix to bug 1816475 and when doing the "ng build --prod" step, I see this: https://pastebin.com/ph7dbp0a - seems like we need to add moment-timezone to package.json somewhere? |
| 14:05 |
pinesol |
Launchpad bug 1816475 in Evergreen "Booking module refresh" [Undecided,Confirmed] https://launchpad.net/bugs/1816475 |
| 14:06 |
csharp |
one our libraries is very interested in booking, so we're enthusiastic about getting into 3.4 (or as close as we can get) |
| 14:06 |
csharp |
s/getting into/getting your fix into/ |
| 14:06 |
sandbergja |
ooh, let me take a look. I might have missed a commit in that branch. |
| 14:07 |
csharp |
no prob - I figured you probably already have it correct locally :-) |
| 14:07 |
sandbergja |
thanks for testing, btw! |
| 14:08 |
bshum |
dbs: "the keyboard? how quaint..." |
| 14:10 |
sandbergja |
csharp: I just took a look -- do you have the commits with messages starting "LP1834662" as well as "LP1816475"? |
| 14:11 |
csharp |
sandbergja: oh - no I don't - that's certainly the problem |
| 14:11 |
csharp |
I'll start over :-) |
| 14:11 |
csharp |
more soon |
| 14:11 |
csharp |
for some reason, I assumed the other bug's commits were already committed to master |
| 14:12 |
sandbergja |
keep me posted! Hope you like it -- let me know if you have other questions as you test! |
| 14:12 |
csharp |
thanks! |
| 14:13 |
sandbergja |
out of curiosity: what does that one library want to use the booking module for? I'm always interested to hear use cases for it. |
| 14:14 |
sandbergja |
as in what resources do they want to use it for? |
| 14:19 |
csharp |
I think it's for meeting room-type resources |
| 14:19 |
sandbergja |
that makes sense! Thanks! |
| 14:20 |
mmorgan |
sandbergja: We had a library that was using booking for book club kits - tote bags with all different formats of a certain title. |
| 14:22 |
sandbergja |
mmorgan: cool! do you think they might be interested in testing out the Angular booking interface too? |
| 14:23 |
sandbergja |
I'm also happy to just make screenshots or a video of the new interface so they can give their feedback without the overhead of loading the branch, etc. |
| 14:26 |
mmorgan |
We've certainly been keeping an eye on the progress of the development. I think screenshots or a video would be great! Not just for libraries that have been using the old version, but also to show others what it looks like, which might give them ideas about what it might be useful for. |
| 14:28 |
sandbergja |
I will do that! |
| 14:33 |
|
jvwoolf joined #evergreen |
| 15:33 |
|
khuckins joined #evergreen |
| 15:47 |
|
mmorgan joined #evergreen |
| 15:48 |
|
abowling joined #evergreen |
| 15:50 |
abowling |
running into the server not supporting the staff client error, even though they're on the same minor release version. anyone fill me in on a piece of magic i might be missing? |
| 15:50 |
abowling |
^one is a production server; the clone is a test server |
| 15:52 |
|
jihpringle joined #evergreen |
| 15:54 |
jeff |
abowling: for the XUL client, support is determined by looking for an entry in /xul/ on the server. |
| 15:55 |
jeff |
so, https://demo.example.org/xul/ |
| 21:21 |
|
sandbergja joined #evergreen |
| 21:42 |
|
sandbergja joined #evergreen |
| 22:19 |
|
sandbergja joined #evergreen |
| 23:02 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 11:58 |
berick |
csharp: "verified in production" would be useful, I think, but not a de facto sign off |
| 11:59 |
berick |
it's like a half sign off |
| 12:03 |
|
jihpringle joined #evergreen |
| 12:03 |
* mmorgan |
feels like if a system is running a fix in production, that should be at least as good as testing that fix in a Concerto test system. |
| 12:05 |
|
sandbergja joined #evergreen |
| 12:05 |
berick |
mmorgan: i don't disagree, but presumably whoever adds the 'verified in production' tag would also be adding a sign-off |
| 12:05 |
berick |
my point is the combo is not the same as 2 sign-off's |
| 12:06 |
berick |
it's 1 really good sign-off |
| 12:07 |
JBoyer |
The other could be as simple as "I looked this over and didn't find any rotten code smell," if it's difficult to test directly. Just making sure that a fix to a weird problem doesn't accidentally introduce some local assumptions / policy is still valuable, even if you didn't encouter the original issue. |
| 12:07 |
dbs |
It doesn't necessarily cover review for accessibility or other parts of the sign-off checklist that we're supposed to go through |
| 12:08 |
dbs |
translation, etc |
| 12:20 |
mmorgan |
berick: yes, a really good sign-off. So maybe a 'verified in production' tag could put a fix in a state where a core committer could do the final review like JBoyer suggests? |
| 12:36 |
* dbs |
is unsure if there is anything that has superceded that checklist |
| 12:40 |
|
collum joined #evergreen |
| 12:42 |
JBoyer |
If so it should probably be updated, but some of the additions seem relatively modern. |
| 12:42 |
JBoyer |
Should probably be some mention of the npm test steps in the web client(s) though. |
| 12:49 |
|
Lenin joined #evergreen |
| 12:55 |
|
collum_ joined #evergreen |
| 12:56 |
|
collum__ joined #evergreen |
| 13:19 |
csharp |
berick: makes sense to me that "verified in production" would be considered strong evidence in favor of a signoff and not an actual signoff |
| 13:19 |
csharp |
(in other words, we agree :-) ) |
| 13:19 |
|
khuckins joined #evergreen |
| 13:20 |
|
jvwoolf joined #evergreen |
| 13:22 |
csharp |
my goal in thinking about that was addressing those fixes that linger because of difficulty in testing (jeffdavis has/has had a number of these over the years) |
| 14:04 |
berick |
agoben: these dates are locked in, yeah? https://wiki.evergreen-ils.org/doku.php?id=hack-a-way:hack-a-way-2019 |
| 14:11 |
rhamby |
berick: they are |
| 14:12 |
berick |
thanks rhamby |
