| 08:44 |
|
mmorgan joined #evergreen |
| 09:13 |
JBoyer |
Dyrcona, If you have a couple minutes for Overdrive API questions I have a couple. (Mostly what needed to be requested for CW/MARS' setup, not low level stuff) |
| 09:14 |
Dyrcona |
JBoyer: Go ahead. |
| 09:15 |
JBoyer |
I was looking at the APIs we have access to (LIB, META, AVAIL, and SRCH) and I have an updated and hand-tested api secret, but no part of the Ebook API displays anything in the logs. Did you request additional APIs or have to do anything special to get things working there? |
| 09:16 |
JBoyer |
(hand-tested as in I can throw the secret at curl and get an oauth bearer token back, I haven't done much else) |
| 09:17 |
Dyrcona |
Yes. Let me check. |
| 09:20 |
Dyrcona |
You need to have Client and Patron authenticaton API access. |
| 09:21 |
Dyrcona |
BTW, where do you see the list of APIs that you have access to? I'm not seeing that in the member center on the developers' site. |
| 12:47 |
Bmagic |
Since it's not officially recognized in LOC, it's the wild west, and you/catalogers can decide how to catalog playaways. Our catalogers decided it needed to have two 007's and some other stuff. Then you define that in the Evergreen ILS, call it playaway. Then create an icon for it with the same name |
| 12:48 |
Bmagic |
the icon/picture file needs to be located in the same folder as the rest of the picture files. The naming convention needs to match the name of the format (but all lowercase) as defined in the ILS |
| 12:49 |
Bmagic |
and finally.. reingest |
| 12:49 |
Bmagic |
you need only reingest a test record for troubleshooting before you go and reingest the whole database |
| 12:53 |
nfburton |
Would I be able to see your tree for the Format Icon? |
| 12:54 |
Bmagic |
yeah, let me see if I can get a screenshot |
| 12:54 |
nfburton |
Thanks |
| 13:12 |
nfburton |
Sounds good thanks |
| 13:18 |
|
yboston joined #evergreen |
| 14:31 |
|
jvwoolf joined #evergreen |
| 14:36 |
csharp |
khuckins_: we were just testing your fix for bug 1777677 and hit a snag - if I'm a non- |
| 14:36 |
pinesol |
Launchpad bug 1777677 in Evergreen "Test notification method" [Wishlist,New] https://launchpad.net/bugs/1777677 |
| 14:37 |
csharp |
"admin" user, I am prompted with a perm override box for OPAC_LOGIN even though my user has that perm at the proper level |
| 14:37 |
csharp |
gonna see if I can get that working, but wanted you to know (I also update the bug report) |
| 14:38 |
csharp |
s/update/updated/ |
| 14:50 |
Bmagic |
nfburton: it looks like the SMD stuff is stock in config.marc21_physical_characteristic_type_map |
| 15:02 |
jeff |
csharp: was the user you were testing as a user with super_user = true set? |
| 15:02 |
csharp |
I think I may have a handle on the problem. It's possible that the "home_ou" attribute is not being dereferenced "enough" (obviously not conversant in Perl to this level) |
| 15:02 |
jeff |
csharp: can you see what arguments were being passed to open-ils.actor.event.test_notification? |
| 15:02 |
csharp |
jeff: the original testers were superusers and that works perfectly |
| 15:03 |
jeff |
and once that's fixed, there's some other permissions-related flaws which would need to be addressed before that's tested and merged. |
| 15:03 |
csharp |
but a non-superuser with OPAC_LOGIN set still doesn't see it |
| 15:03 |
csharp |
http://git.evergreen-ils.org/?p=working/Evergreen.git;a=blob;f=Open-ILS/src/perlmods/lib/OpenILS/Application/Actor.pm;h=f8aa7491bf1ff8d097229c484a26201b1a84c1b4;hb=refs/heads/user/khuckins/lp1777677-test-notification-method#l4231 |
| 15:04 |
csharp |
that's the sub it's using and I think $$args{home_ou}) on line 4241 is the problem |
| 15:04 |
jeff |
it's because a user with super_user = true (which should probably be deprecated) gets TRUE returned for permission checks on non-existent org unit contexts. |
| 15:04 |
csharp |
I'm not great at using Data::Dumper, but it comes back as Fieldmapper::actor::org_unit=ARRAY(0x5b40070) |
| 15:05 |
csharp |
ah - makes sense |
| 15:05 |
csharp |
er... |
| 15:05 |
jeff |
oh. |
| 15:06 |
csharp |
not showing the args in the console, no |
| 15:06 |
jeff |
is this in place on a test system i can log into, or would i need to install the branch to get that? |
| 15:06 |
JBoyer |
I would wonder how well it works if that line is just thrown away. I barely remember when a perms check came up for that and the question was basically "What's something that everybody has?" which to me sounds a lot like |
| 15:07 |
JBoyer |
"Maybe we don't need to gate this one" |
| 15:07 |
csharp |
jeff: let me fix the SSL cert on it and I'll let you it (it's a concerto server) |
| 15:13 |
khuckins |
home_ou is passed in for the sake of checking the permission, so if we drop the OPAC_LOGIN check, that should probably be dropped as well |
| 15:14 |
khuckins |
csharp++ jeff++ Drycona++ JBoyer++ |
| 15:14 |
Dyrcona |
khuckins: Any reason for checking for OPAC_LOGIN? |
| 15:15 |
jeff |
Just to be clear, the status of this is that it is not currently included in any released or reployed Evergreen install, other than perhaps a test install with either no live data or no ability for non-trusted individuals to log in? :-) |
| 15:16 |
* Dyrcona |
thinks its on our training server where we may have looked at it, but yeah. :) |
| 15:16 |
khuckins |
Early on on the lp ticket it was suggested to have a permissions check to avoid potential abuse, initially using the UPDATE_USER permission, then brought down to OPAC_LOGIN when realizing users should be using this as well as staff |
| 15:16 |
khuckins |
But in retrospect any user who's going to be able to access that API call would be logged in |
| 15:21 |
jeff |
Dyrcona: originally it was UPDATE_USER |
| 15:21 |
|
aabbee left #evergreen |
| 15:21 |
|
aabbee joined #evergreen |
| 15:22 |
Dyrcona |
Well, that makes sense if the test is done in conjunction with changing the notification method's value. |
| 15:22 |
Dyrcona |
jeff++ |
| 15:23 |
jeff |
Also, it allows a wider than intended array of events to be fired. |
| 15:24 |
jeff |
by passing arbitrary values as event_def_type -- though it looks like it will only pass an (arbitrary!) user object to $U->fire_object_event |
| 00:11 |
|
Christineb joined #evergreen |
| 01:03 |
|
beanjammin joined #evergreen |
| 04:30 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 06:04 |
|
dkyle2 joined #evergreen |
| 06:34 |
|
jamesrf joined #evergreen |
| 07:06 |
|
rjackson_isl joined #evergreen |
| 10:38 |
|
jamesrf joined #evergreen |
| 10:40 |
Bmagic |
stephengwills: Chrome/Firefox both seem to work and work well. When it comes to the Hatch software, Chrome was* the only browser that had the Hatch extension, but now thanks to csharp and others, FF has it available in the add-on's store |
| 10:42 |
|
khuckins_ joined #evergreen |
| 10:42 |
stephengwills |
thanks…my tests seem to be working as well. I just wanted to double check. |
| 10:44 |
berick |
we officially support chrome and ff |
| 10:44 |
berick |
hatch still needs a little bit of love for FF, though - some pending LP's |
| 10:48 |
stephengwills |
i was just on a conf call where one of my LibDirs told the group not to ue firefox because it was unsupported. I didn’t want to jump in without this checkin. thanks all, as usual. ++ |
| 10:52 |
berick |
ideally, the other browsers will catch up, but yeah for now Chrome is the path of least resistence, but we also support FF |
| 10:57 |
* stephengwills |
puts up his thumb and pokes himself in the eye. |
| 11:03 |
Dyrcona |
Speaking of Google.... Do we have a community calendar with the EOL dates for the releases on it? |
| 11:26 |
Dyrcona |
berick++ for Lp 1810802. I swear I tested that, but guess I didn't. |
| 11:26 |
pinesol |
Launchpad bug 1810802 in Evergreen "Database org_top() function upgrade script errors" [High,New] https://launchpad.net/bugs/1810802 - Assigned to Jason Stephenson (jstephenson) |
| 11:31 |
pinesol |
[evergreen|Bill Erickson] LP1810802 org_top() SQL upgrade repairs - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=eaca9cd> |
| 11:37 |
berick |
Dyrcona++ |
| 12:05 |
|
mmorgan joined #evergreen |
| 12:05 |
|
sandbergja joined #evergreen |
| 12:22 |
Dyrcona |
Speaking of db upgrades... It would be great if Lp 1806709 could go in before next week's update releases. |
| 12:22 |
pinesol |
Launchpad bug 1806709 in Evergreen 3.2 "Add Billing History grid persist-key to server-side db settings" [High,Confirmed] https://launchpad.net/bugs/1806709 |
| 12:37 |
|
khuckins_ joined #evergreen |
| 12:40 |
|
beanjammin joined #evergreen |
| 12:47 |
|
beanjammin joined #evergreen |
| 13:41 |
|
khuckins_ joined #evergreen |
| 15:13 |
|
khuckins joined #evergreen |
| 15:56 |
|
jvwoolf joined #evergreen |
| 16:30 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 17:11 |
|
mmorgan left #evergreen |
| 17:31 |
|
jvwoolf joined #evergreen |
| 22:36 |
|
beanjammin joined #evergreen |
| 15:10 |
phasefx |
welcome |
| 15:13 |
phasefx |
hrmm, so some instances of stretch seem to require use of /etc/init.d/ in places instead of systemctl :-/ |
| 15:14 |
berick |
phasefx: apache2ctl-websockets should work universally |
| 15:15 |
phasefx |
berick++ in this most recent case, it was ejabberd surprising me |
| 15:15 |
phasefx |
what do you guys think of this look/layout for the live tester? http://testing.evergreen-ils.org/~live/ |
| 15:16 |
bshum |
phasefx++ # neat :) |
| 15:16 |
phasefx |
will put a shortuct at the top to indicate/jump to the first failure |
| 15:17 |
bshum |
berick: phasefx: that step's in the OpenSRF readme right? It probably hasn't been touched since we introduced apache2-websocket |
| 15:18 |
phasefx |
will probably hyperlink to sections in the install instructions as well |
| 15:20 |
bshum |
Makes sense to update the instruction to be distro specific, if necessary. Or just use the one berick suggests. |
| 15:20 |
bshum |
That's assuming we keep it as option #1 over the new websocketd :D |
| 15:25 |
pinesol |
News from qatests: Failed configuring ejabberd <http://testing.evergreen-ils.org/~live/test.15.html#2019-01-03T15:08:51,961120528-0500 -0> |
| 15:25 |
pinesol |
News from qatests: Failed creating jabber users <http://testing.evergreen-ils.org/~live/test.16.html#2019-01-03T15:08:51,970774027-0500 -2> |
| 15:25 |
pinesol |
News from qatests: Failed start opensrf <http://testing.evergreen-ils.org/~live/test.18.html#2019-01-03T15:08:51,980501558-0500 -4> |
| 15:25 |
pinesol |
News from qatests: Failed start opensrf <http://testing.evergreen-ils.org/~live/test.20.html#2019-01-03T15:08:51,990116639-0500 -6> |
| 15:25 |
pinesol |
News from qatests: Failed test opensrf <http://testing.evergreen-ils.org/~live/test.21.html#2019-01-03T15:08:51,999747537-0500 -8> |
| 15:25 |
pinesol |
News from qatests: Failed configuring websockets <http://testing.evergreen-ils.org/~live/test.22.html#2019-01-03T15:08:52,009366939-0500 -10> |
| 15:38 |
blongwel |
In 3.1.7 with duplicate tcn (from 035) on import we are seeing long tcns generated with all isbns in the record. Is this expected behavior or a bug? |
| 15:55 |
pinesol |
News from qatests: Failed configuring websockets <http://testing.evergreen-ils.org/~live/test.22.html#2019-01-03T15:48:20,626585144-0500 -0> |
| 16:04 |
|
gsams_ joined #evergreen |
| 16:06 |
|
gsams_ joined #evergreen |
| 16:25 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 16:45 |
mmorgan |
Anybody getting reports from patrons using Comcast as an email provider that they are not getting their Evergreen notifications? |
| 16:45 |
csharp |
not here that I've heard |
| 16:46 |
mmorgan |
We're getting lots of reports, but see no problems in our email logs, and we've successfully seen messages delivered to staff members who have Comcast email. |
| 16:50 |
csharp |
email providers are getting stricter about enforcing that - but I would expect problems with Gmail and Yahoo too |
| 16:51 |
mmorgan |
We send through gmail and those logs indicate those messages are all being delivered to Comcast servers. We're only seeing the usual occasional bounce when a user doesn't exist. |
| 16:52 |
csharp |
yeah - the logs on your end will look fine - the receiving server accepts the mail in most cases, then trashes it on their end |
| 16:54 |
mmorgan |
Tests we've done work fine. Hold notifications, etc. appear in the Comcast inboxes of the patrons, who just happen to be staff members who tested with their Comcast email addresses. |
| 16:54 |
csharp |
oh - hmm |
| 16:55 |
mmorgan |
But we've had a large number of reports from patrons that they're not getting messages in the past two weeks. |
| 16:55 |
csharp |
we have a standard line of "all looks correct on our end - please contact your email provider" (sometimes including the log message on our end showing successful receipt |
| 05:01 |
pinesol |
News from qatests: Failed Running perl live tests <http://testing.evergreen-ils.org/~live/test.24.html#2018-12-19T04:52:32,076196669-0500 -0> |
| 07:05 |
|
agoben joined #evergreen |
| 07:08 |
|
rjackson_isl joined #evergreen |
| 07:29 |
|
bdljohn joined #evergreen |
| 09:51 |
|
yboston joined #evergreen |
| 09:54 |
RMiller |
Hi, quick Evergreen install question. In step 11 of the Evergreen install, it tells me to copy the opensrf_core.xml file again, then modify it the same way I did in OpenSRF setup |
| 09:55 |
RMiller |
Since I only installed OpenSRF for the purposes of using Evergreen, do I need to do this step? |
| 09:56 |
JBoyer |
RMiller, yeah, the one included in OpenSRF only has a couple testing services defined, the example included with Evergreen defines the other services required by Evergreen and a couple testing services. |
| 09:56 |
RMiller |
So the Evergreen setup replaced that example file with something more thorough? |
| 09:57 |
RMiller |
It's the same location and filename, so that just seemed weird |
| 09:58 |
|
bwicksall joined #evergreen |
| 14:15 |
jeff |
if your backend systems are not sharing a memcached instance, then the session token from one would not be considered valid on another. |
| 14:16 |
jeff |
so unless you have taken some extraordinary steps to ensure that requests by a given client are only ever serviced by a specific backend host, you're going to run into issues where it appears that you are not logged in. you may never be able to successfully log in and could loop, like you're seeing. |
| 14:16 |
stephengwills |
ok. makes sense. |
| 14:17 |
jeff |
if haproxy was connecting over http and you weren't taking other steps to inform the backend systems of the client <-> haproxy protocol being https, then you'd run into similar redirect issues because the backend systems would think the client connection was over http and try to redirect to https, looping. |
| 14:19 |
jeff |
if you rule out those two issues and are still having problems with a "fresh" client, you might consider configuring haproxy to only use a single backend system as a next troubleshooting step. |
| 14:20 |
jeff |
and by a "fresh" client, I mean you might want to clear cache and restart the web browser, or try a new incognito/private browing session to test, to rule out the possibility that the client had cached a problematic redirect, etc. often not necessary, but good to rule out... |
| 14:21 |
stephengwills |
fair. thanks will do |
| 14:21 |
jeff |
good luck! |
| 14:26 |
jeff |
another issue that we might still be susceptible to is if you've created a directory in your DocumentRoot titled "eg", or if your hostname contains (or perhaps just starts with) "staff". I should find or create bugs for those two. They're less common, but if either rings a bell for you, could be that. :-) |
| 15:29 |
|
bdljohn1 joined #evergreen |
| 16:51 |
stephengwills |
one of the hosts I am retiring was named staff but that is no longer an issue. I fixed the eg_vhost to rewrite all traffic to https and now haproxy delivers a user to one of the hosts and that user should stay put for the druation of thier session, anyway. not fool proof but it got me past that issue. I’ll look into shared memcache after dinner. thanks for the suggestions. |
| 16:57 |
|
stephengwills left #evergreen |
| 17:01 |
pinesol |
News from qatests: Failed Running perl live tests <http://testing.evergreen-ils.org/~live/test.24.html#2018-12-19T16:53:56,389847953-0500 -0> |
| 17:33 |
|
stephengwills joined #evergreen |
| 18:17 |
|
nfBurton joined #evergreen |
| 20:27 |
|
sandbergja joined #evergreen |
| 05:01 |
pinesol |
News from qatests: Failed Running perl live tests <http://testing.evergreen-ils.org/~live/test.24.html#2018-12-18T04:52:13,436767412-0500 -0> |
| 07:02 |
|
agoben joined #evergreen |
| 07:08 |
|
rjackson_isl joined #evergreen |
| 07:42 |
|
bdljohn joined #evergreen |
| 09:24 |
RMiller |
The passwords are in there correctly, as far as I can tell; two are inside <password> tags and two are inside <passwd> tags. Is that right? |
| 09:27 |
aabbee |
yes. the <password> tags are for router users, <passwd> tags for opensrf users. note that these do not appear in the opensrf_core.xml file in the same order that the users were created in step 11. |
| 09:28 |
RMiller |
I gave them all the same password, so the order shouldn't matter... :) |
| 09:29 |
Dyrcona |
RMiller: For testing purposes, I use "password" so I don't have to change the configuration file. |
| 09:30 |
Dyrcona |
Did you restart ejabberd after making the changes to ejabberd.yml? |
| 09:31 |
Dyrcona |
You probably could not have registered the users unless you did, though. |
| 09:32 |
RMiller |
I'm sure I did (this has been a month-long on-and-off process, long story) but I just did again, and no change. |
| 10:32 |
RMiller |
4! Hooray! |
| 10:33 |
Dyrcona |
I'm concerned about the amount of RAM. I never go with less than 4GB. You may find yourself running out once you get PostgreSQL and everything else running. |
| 10:36 |
RMiller |
Ok. It's virtualized, so I'd have to ask the IT guy for that one. Are we talking increasing swap space or just actually adding another stick of RAM or what? |
| 10:37 |
pastebot |
"Dyrcona" at 64.57.241.14 pasted "Free on Ubuntu 18.04 test VM" (4 lines) at http://paste.evergreen-ils.org/14378 |
| 10:38 |
Dyrcona |
That's after having done very little, just looking up a book and editing it's information. |
| 10:38 |
Dyrcona |
Is this going to be for production use or just for testing? |
| 10:39 |
RMiller |
Production on a small scale- we're one K-12 school library. |
| 10:40 |
Dyrcona |
You'll probably want 8GB in the end. If it's virtualized, they should be able to increase the RAM rather easily, just a config change and VM restart. |
| 10:41 |
RMiller |
Ok. Thank you again for all your help! I really appreciate it |
| 16:58 |
bshum |
It's kind of like you'd have to though. In order to preserve the original displayed content vs. the new variable you'd rather be searching on |
| 16:59 |
|
khuckins joined #evergreen |
| 17:01 |
nfBurton |
I thought one would exist already. Thanks for the sanity check. |
| 17:01 |
pinesol |
News from qatests: Failed Running perl live tests <http://testing.evergreen-ils.org/~live/test.24.html#2018-12-18T16:54:23,308313503-0500 -0> |
| 17:02 |
bshum |
It wouldn't be the first time we broke up an existing field definition into more granular pieces to achieve certain goals |
| 17:04 |
|
mmorgan left #evergreen |
| 17:54 |
|
aabbee left #evergreen |
| 08:54 |
mmorgan |
@coffee |
| 08:54 |
* pinesol |
brews and pours a cup of Kenya Mamuto Kirinyaga, and sends it sliding down the bar to mmorgan |
| 08:55 |
mmorgan |
@coffee [someone] |
| 08:55 |
* pinesol |
brews and pours a cup of Costa Rica Finca Cerro Palado, and sends it sliding down the bar to dbwells |
| 09:11 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 09:33 |
phasefx |
not really a success, but getting there |
| 09:35 |
mmorgan |
Less of a failure is a success |
| 09:45 |
rhamby |
mmorgan: unless the less of a failure is a failure to correctly diagnose the scale of failure (I'm clearly in an optimistic mood today) |
| 10:01 |
Dyrcona |
Unfortunately, the ejabberd log only shows it closing the connection, not why. |
| 10:02 |
|
yboston joined #evergreen |
| 10:06 |
Dyrcona |
OK. Looks like we need some chunking/bundling work there, possibly. |
| 10:22 |
Dyrcona |
So, I got it to work on a "test" server by setting max_stanza_size to 2,000,000 and firing the event by itself. |
| 10:23 |
Dyrcona |
The server that normally runs the events already has max_stanza_size set to 2,000,000, so it can't be just that. |
| 10:26 |
* Dyrcona |
wishes the perl debugger was actually useful. |
| 10:33 |
Dyrcona |
So, I may just go back to using 1 collector and 1 reactor. It seems we've had the --run-pending a/t runner get hung up about 1/week since changing the configuration. That's far more often than before. |
| 10:33 |
Dyrcona |
csharp: Have you encountered any similar issues? |
| 10:41 |
|
khuckins joined #evergreen |
| 10:41 |
pinesol |
News from qatests: Failed Running OpenSRF build tests <http://testing.evergreen-ils.org/~live> |
| 10:41 |
pinesol |
News from qatests: Failed Running Evergreen build tests <http://testing.evergreen-ils.org/~live> |
| 10:41 |
pinesol |
News from qatests: Failed configure apache <http://testing.evergreen-ils.org/~live> |
| 10:41 |
pinesol |
News from qatests: Failed Running pgTAP tests <http://testing.evergreen-ils.org/~live> |
| 10:41 |
pinesol |
News from qatests: Failed <http://testing.evergreen-ils.org/~live> |
| 10:50 |
Dyrcona |
I lowered our collect and react settings to 2, just to see if that helps. |
| 10:50 |
* Dyrcona |
doubts it. |
| 11:10 |
|
terran joined #evergreen |
| 11:11 |
pinesol |
News from qatests: Failed configure apache <http://testing.evergreen-ils.org/~live> |
| 11:11 |
pinesol |
News from qatests: Failed Running pgTAP tests <http://testing.evergreen-ils.org/~live> |
| 11:11 |
pinesol |
News from qatests: Failed <http://testing.evergreen-ils.org/~live> |
| 11:12 |
phasefx |
getting there |
| 11:13 |
phasefx |
the pgTAP failure is legit |
| 11:15 |
Dyrcona |
phasefx: I've discussed that failure with someone (gmcharlt?) at the hack-away. I noticed when going to Pg 10. |
| 11:17 |
phasefx |
Dyrcona++ |
| 11:18 |
berick |
and phasefx++ |
| 11:18 |
Dyrcona |
phasefx: What version of Pg is installed? |
| 11:18 |
berick |
building test server on ub 18? |
| 11:18 |
phasefx |
Dyrcona: PostgreSQL 9.6.10 on x86_64-pc-linux-gnu, compiled by gcc (Debian 6.3.0-18+deb9u1) 6.3.0 20170516, 64-bit |
| 11:19 |
Dyrcona |
OK. I don't recall if I've ever run the tests on Pg 9.6. |
| 11:19 |
phasefx |
berick: debian stretch, but we have or are close to having multi-server support |
| 11:20 |
phasefx |
http://git.evergreen-ils.org/?p=working/random.git;a=blob;f=qa/test_runner.xml;h=6e3952d0b1f47e2a1898d3048ebe6153ce4da547;hb=refs/heads/collab/phasefx/eg_live_tests |
| 11:20 |
berick |
nice! |
| 11:21 |
Dyrcona |
Looks like we'll have to modify the test to accommodate 9.6 also.... |
| 11:31 |
phasefx |
right now testing.evergreen-ils.org is still running test.sh (http://git.evergreen-ils.org/?p=working/random.git;a=blob;f=qa/test.sh;h=11d96d5b42eb05d513e6bea63d75a29983175246;hb=refs/heads/collab/phasefx/eg_live_tests), but we can eventually switch it over to and smoke test test_runner.pl http://git.evergreen-ils.org/?p=working/random.git;a=blob;f=qa/test_runner.pl;h=4fc672529021ec2b74bcf83d69dc22bf74ff3c73;hb=refs/heads/collab/phasefx/eg_live_test |
| 11:32 |
phasefx |
then folks with commit access to the branch can just add their servers (there's an ssh pubkey for testin.evergreen-ils.org in the branch) |
| 11:33 |
Dyrcona |
phasefx: Sound interesting/useful. I'll take a look some day. |
| 11:38 |
jeff |
what keeps us using the random repository for all manner of things? would gitlab and/or something else help us get away from that practice, because it would potentially reduce the burden of creating a repo? |
| 11:38 |
jeff |
(tangent, i know) |
| 12:25 |
|
bdljohn1 joined #evergreen |
| 12:36 |
|
beanjammin joined #evergreen |
| 12:39 |
Dyrcona |
jeff: Gitlab will let you create your own repositories just by pushing to them be default. It can be done with gitolite using a wildcard repo configuration. |
| 12:42 |
pinesol |
News from qatests: Failed Running pgTAP tests <http://testing.evergreen-ils.org/~live#2018-12-12T12:12:09,428726255-0500 -0> |
| 12:42 |
pinesol |
News from qatests: Failed Running perl live tests <http://testing.evergreen-ils.org/~live#2018-12-12T12:12:09,450827934-0500 -2> |
| 12:42 |
pinesol |
News from qatests: Failed <http://testing.evergreen-ils.org/~live#2018-12-12T12:12:09,472980231-0500 -4> |
| 12:47 |
dickreckard |
uhm, is there a way to list the last records added to the catalog in the staff client? |
| 13:01 |
miker |
dickreckard: in the staff client directly? hrm, probably not. but in another tab: http://sandbox-32.evergreencatalog.com/opac/extras/feed/freshmeat/opac/biblio/import/10/ |
| 13:05 |
* jeff |
notes the Apache "Found" 3xx body appended to the end of that document |
| 13:12 |
jeff |
also, if you're not logged in to the staff client in that browser when you fetch that url, if the most recent 10 bibs aren't otherwise visible in searches, you may get zero results, or more likely less than the number requested. |
| 13:14 |
jeff |
but if there are zero results you'll get an error that references record IDs, which you can then individually retrieve. |
| 13:16 |
Dyrcona |
dickreckard: What problem are you trying to solve? Do you want to see X of the most recent records you've added or just the previous one? This sounds like a potentially useful feature request. |
| 13:16 |
dickreckard |
no it's for the staff indeed |
| 13:17 |
dickreckard |
just wanted to check how the staff is doing in the test installation, and export the records that were added |
| 13:17 |
dickreckard |
so maybe make a csv with the IDs and use the batch export |
| 13:18 |
dickreckard |
cos I will need to merge the old database with the recods that were added in the test installation, into a new installation |
| 13:20 |
dickreckard |
I think a record query " * sort(create_date) #descending " solve my needs.. but indeed the last x records instead of just the 'retriev last bib record' button could be nice |
| 13:26 |
dickreckard |
also I finally solved the problem I had with vandelay batch imports.. I found the issue was that systemd creates a private /tmp folder nested inside an apache2 private folder, so it couldn't find the uploaded temporary .mrc file as it was inside the private tmp instead of /tmp. I wanted to somehow add that note somewhere, cos it would be useful to add in the documentation as from debian stretch it's the |
| 13:26 |
dickreckard |
default behavior. |
| 13:27 |
dickreckard |
I looked on launchpad and couldn't find mentions about it. so let me know if I can add notify this somewhere. |
| 13:29 |
jeff |
It might be reasonable to review changing the default value of <importer>/tmp</importer> in openils.xml.example |
| 13:31 |
Dyrcona |
dickreckard: You should be able to get marc records out of the URL that miker shared earlier. |
| 13:31 |
|
sandbergja joined #evergreen |
| 15:07 |
JBoyer |
++ |
| 15:08 |
* berick |
wonders if csharp is in the house |
| 15:08 |
berick |
in any event, I'll note that in the LP |
| 15:08 |
* Dyrcona |
was thinking we could assign testing with Firefox to csharp. :) |
| 15:08 |
JBoyer |
The thing that's primarily being tested is the Windows installer. The extension can function without changes so long as the windows bits are updated. |
| 15:08 |
gmcharlt |
ok |
| 15:08 |
gmcharlt |
so I'll take this as |
| 15:09 |
gmcharlt |
#info Next Hatch release is close |
| 15:09 |
JBoyer |
+1 |
| 15:09 |
gmcharlt |
#action berick, JBoyer, csharp, et. al. will collaborate on final testing |
| 15:09 |
gmcharlt |
Bmagic: we can discuss the Dymo stuff later in the agenda |
| 15:09 |
Bmagic |
sure |
| 15:10 |
gmcharlt |
but I note that since there's a direct Evergreen dependency with the "compatiblity mode", we may not want to couple that issue with the other stuff that's being worked on for the Hatch release |
| 15:10 |
|
khuckins__ joined #evergreen |
| 15:11 |
gmcharlt |
^ that one looks straightforward; I'll run it through its paces and will merge today |
| 15:12 |
gmcharlt |
the other is bug 1729610 |
| 15:12 |
pinesol |
Launchpad bug 1729610 in OpenSRF "allow requests to be queued if max_children limit is hit" [Wishlist,New] https://launchpad.net/bugs/1729610 |
| 15:12 |
gmcharlt |
which I know miker will test, but it would be nice to have additional eyes on it |
| 15:12 |
gmcharlt |
I'll write up draft release notes as well |
| 15:12 |
gmcharlt |
request chunking will /not/ make it into 3.1-beta for lack of code |
| 15:12 |
gmcharlt |
any questions? |
| 15:12 |
* miker |
hangs head in shame |
| 15:13 |
JBoyer |
Looks good, since I'm hoping to use websocketd in production soon I'll try to test those two branches too. |
| 15:14 |
|
bdljohn1 joined #evergreen |
| 15:14 |
* Dyrcona |
is using websocketd in production and it is very reliable. |
| 15:14 |
berick |
just noticed I need a better commit message on the websocketd patch... |
| 15:25 |
gmcharlt |
ok, moving on |
| 15:25 |
gmcharlt |
#topic Hatch |
| 15:25 |
|
Topic for #evergreen is now Hatch (Meeting topic: Evergreen Development Meeting, 2018-12-12) |
| 15:26 |
berick |
I am planning to help w/ the Dymo LP, at minimum code reivew and non-Dymo testing. |
| 15:26 |
gmcharlt |
berick++ |
| 15:26 |
berick |
I don't have a Dymoe printer, alas |
| 15:27 |
berick |
so kind of like the other Hatch issue, more help testing would be appreciated |
| 15:27 |
gmcharlt |
I have one comment so far ... I dislike calling it "compatibility mode" as a printing setting |
| 15:27 |
dbwells |
We've got a million Dymos and can help with testing. |
| 15:27 |
Bmagic |
I solicited my libraries and was able to borrow one more long term. |
| 15:28 |
gmcharlt |
as ultimately that's meaningless to the user |
| 15:28 |
Bmagic |
I'm not married to the term either. |
| 15:47 |
berick |
and when it's enabled it will be clearly /other/ |
| 15:47 |
berick |
and not a replacement |
| 15:47 |
gmcharlt |
but I'm wondering if we can go so far as to also deprecate the old embedded OPAC at the same time, with a stated goal of removing it in 3.4 |
| 15:47 |
JBoyer |
+1 to having the code in core, possibly just have 2 entries in the cat menu "Search Catalog" and "Testing Catalog" or similar. |
| 15:47 |
Dyrcona |
I'd be inclined to leave it out. |
| 15:47 |
berick |
Dyrcona: well, it's already in there |
| 15:47 |
berick |
or do you mean the menu entry? |
| 15:48 |
berick |
Dyrcona: gotcha |
| 15:48 |
miker |
is it Decided(tm) that the embedded catalog must die? (sorry if that's been made clear or is obvious) |
| 15:48 |
JBoyer |
Does seem a little early to deprecate embedded tpac in 3.3, though |
| 15:48 |
berick |
it could still be easily tested even if it weren't listed in the menu, of course |
| 15:49 |
berick |
miker: that is certainly my hope, but no decisions on that have really been made. also why I wanted to raise the topic |
| 15:49 |
JBoyer |
miker, if it went up to a vote among circ staff they wouldn't think twice, as the iframe eats the shortcut keys. |
| 15:49 |
gmcharlt |
miker: in the long run, I don't think it does us much good to support two different staff OPACs (although obviously there will need to be a way to quickly open a bib in the OPAC) |
| 15:49 |
berick |
make sure I'm tilting at the correctly shaped windmills |
| 16:05 |
berick |
that's my take as well. |
| 16:05 |
miker |
gmcharlt: that's totally fair |
| 16:05 |
jeffdavis |
I think deprecating in 3.3 is too aggressive, but a soft goal of defaulting to angular OPAC in 3.4 (+ deprecating TPAC in client) is ok with me. |
| 16:06 |
gmcharlt |
I also think that it should be a bit easier than editing navbar.tt2 (or the equivalent) to make it avaialble in 3.3 for testing purposes |
| 16:06 |
gmcharlt |
YAOUS, perhaps? |
| 16:07 |
JBoyer |
A reasonable compromise; that way Library A can get their staff started early even if Library B isn't sure how this whole "online" thing is going to shake out. |
| 16:07 |
miker |
I'm mainly curious as to whether we can, or should, write an Ang egFrame component so we can make use of what's there, or will the whole catalog in the client continue to be AngJS until we switch? |
| 16:08 |
berick |
miker: as it stands, I'm making the Ang catalog jump to AngJS for anything it's not prepared to deal with |
| 16:08 |
berick |
to ease integration / testing |
| 16:09 |
berick |
e.g. it jumps to AngJS for holdings maintenance, holds lists, and a few others |
| 16:09 |
berick |
but AngJS stays within its own sphere for now |
| 16:09 |
berick |
it never jumps back to Ang (unless you use the back button) |
| 16:10 |
berick |
which as it stands would be confusing for most staff, but certainly usable / testable |
| 16:10 |
miker |
sure, that makes sense |
| 16:11 |
berick |
but to answer your questoin, I think yes, there has to be a single catalog that's the main one |
| 16:11 |
berick |
which will be angjs until it's not |
| 16:15 |
* JBoyer |
can't wait for the hip-hop remix of the discussion. |
| 16:15 |
berick |
i think that's it so far |
| 16:15 |
berick |
miker: :) |
| 16:16 |
gmcharlt |
ok, so I think to sum up, it sounds like we have |
| 16:16 |
gmcharlt |
(a) general willingness that the Ang staff OPAC be made available in 3.3 in some fashion for testing |
| 16:17 |
gmcharlt |
(b) a new shared sense of what the issues will be around when (or if) to make a full transiition to it at some point |
| 16:17 |
gmcharlt |
accurate? |
| 16:17 |
miker |
+1 |
| 16:17 |
JBoyer |
+1 |
| 16:17 |
berick |
+1 |
| 14:49 |
jeff |
similarly, History (bib_source(1)) does not restrict to bib source 1 |
| 14:51 |
miker |
jeff: that's both interesting and annoying... I'll see if there's something obvious |
| 14:52 |
jeff |
thanks. in the meantime, i'm learning new things. :-) |
| 14:52 |
miker |
jeff: the one common thing there is that locations and bib source are part of the new int_array-based attribute vector visibility tests, and audience is not -- it's a standard coded value map thing |
| 14:53 |
jeff |
problem came to light because we have some search filter groups that use locations() |
| 14:55 |
jeff |
and locations(123) and bib_source(1) seem to do the expected thing with regard to the SQL using search.calculate_visibility_attribute_test |
| 14:56 |
jeff |
but (locations(123)) and (bib_source(1)) eventually lose the filter before it gets to the sql. |
| 15:01 |
|
bdljohn joined #evergreen |
| 15:02 |
|
yboston joined #evergreen |
| 15:05 |
Dyrcona |
So, if someone has a bad url on a provider and activates a PO and pushing the edi fails, does fixing the url automagically fix it all, or do I need to update some other fields? |
| 15:14 |
pinesol |
News from qatests: Failed cloning git repositories <http://testing.evergreen-ils.org/~live> |
| 15:14 |
pinesol |
News from qatests: Failed Installing OpenSRF pre-requisites <http://testing.evergreen-ils.org/~live> |
| 15:14 |
pinesol |
News from qatests: Failed Installing Evergreen pre-requisites <http://testing.evergreen-ils.org/~live> |
| 15:14 |
pinesol |
News from qatests: Failed Installing Evergreen database pre-requisites <http://testing.evergreen-ils.org/~live> |
| 15:14 |
pinesol |
News from qatests: Failed setting ld.so.conf and rsyslog and /etc/hosts and ejabberd <http://testing.evergreen-ils.org/~live> |
| 15:14 |
pinesol |
News from qatests: Failed Building OpenSRF <http://testing.evergreen-ils.org/~live> |
| 15:14 |
pinesol |
News from qatests: Failed Running OpenSRF build tests <http://testing.evergreen-ils.org/~live> |
| 15:14 |
pinesol |
News from qatests: Failed Installing OpenSRF <http://testing.evergreen-ils.org/~live> |
| 15:14 |
pinesol |
News from qatests: Failed Building Evergreen <http://testing.evergreen-ils.org/~live> |
| 15:14 |
pinesol |
News from qatests: Failed Running Evergreen build tests <http://testing.evergreen-ils.org/~live> |
| 15:14 |
pinesol |
News from qatests: Failed Running Evergreen browser client build/test - Expected 6 errors but encountered 5. <http://testing.evergreen-ils.org/~live> |
| 15:14 |
pinesol |
News from qatests: Failed Installing Evergreen <http://testing.evergreen-ils.org/~live> |
| 15:14 |
pinesol |
News from qatests: Failed configure database <http://testing.evergreen-ils.org/~live> |
| 15:14 |
pinesol |
News from qatests: Failed configure apache <http://testing.evergreen-ils.org/~live> |
| 15:14 |
pinesol |
News from qatests: Failed Starting Evergreen <http://testing.evergreen-ils.org/~live> |
| 15:14 |
pinesol |
News from qatests: Failed Running settings-tester.pl <http://testing.evergreen-ils.org/~live> |
| 15:14 |
pinesol |
News from qatests: Failed Running perl live tests <http://testing.evergreen-ils.org/~live> |
| 15:14 |
pinesol |
News from qatests: Failed <http://testing.evergreen-ils.org/~live> |
| 15:14 |
* berick |
chuckles |
| 15:15 |
berick |
as if millions of QA tests suddenly cried out in terror |
| 15:16 |
Dyrcona |
:) |
| 15:16 |
Dyrcona |
Well, if you can't clone the repo.... |
| 15:19 |
|
jvwoolf1 joined #evergreen |
| 16:42 |
|
dkyle2 left #evergreen |
| 16:42 |
Dyrcona |
Yeah, that PO definitely causes some kind of problem. |
| 16:42 |
* Dyrcona |
will look into it more tomorrow. |
| 17:06 |
jeff |
miker: the patch supplied above doesn't seem to improve the issue. testing with opac and with Open-ILS/src/support-scripts/test-scripts/query_parser.pl |
| 17:13 |
|
mmorgan left #evergreen |
| 17:17 |
|
jvwoolf1 left #evergreen |
| 17:18 |
pinesol |
News from qatests: Failed cloning git repositories <http://testing.evergreen-ils.org/~live> |
| 17:18 |
pinesol |
News from qatests: Failed Installing OpenSRF pre-requisites <http://testing.evergreen-ils.org/~live> |
| 17:18 |
pinesol |
News from qatests: Failed Installing Evergreen pre-requisites <http://testing.evergreen-ils.org/~live> |
| 17:18 |
pinesol |
News from qatests: Failed Installing Evergreen database pre-requisites <http://testing.evergreen-ils.org/~live> |
| 17:18 |
pinesol |
News from qatests: Failed setting ld.so.conf and rsyslog and /etc/hosts and ejabberd <http://testing.evergreen-ils.org/~live> |
| 17:18 |
pinesol |
News from qatests: Failed Building OpenSRF <http://testing.evergreen-ils.org/~live> |
| 17:18 |
pinesol |
News from qatests: Failed Running OpenSRF build tests <http://testing.evergreen-ils.org/~live> |
| 17:18 |
pinesol |
News from qatests: Failed Installing OpenSRF <http://testing.evergreen-ils.org/~live> |
| 17:18 |
pinesol |
News from qatests: Failed Building Evergreen <http://testing.evergreen-ils.org/~live> |
| 17:18 |
pinesol |
News from qatests: Failed Running Evergreen build tests <http://testing.evergreen-ils.org/~live> |
| 17:18 |
pinesol |
News from qatests: Failed Running Evergreen browser client build/test - Expected 6 errors but encountered 5. <http://testing.evergreen-ils.org/~live> |
| 17:18 |
pinesol |
News from qatests: Failed Installing Evergreen <http://testing.evergreen-ils.org/~live> |
| 17:18 |
pinesol |
News from qatests: Failed configure database <http://testing.evergreen-ils.org/~live> |
| 17:19 |
pinesol |
News from qatests: Failed configure apache <http://testing.evergreen-ils.org/~live> |
| 17:19 |
pinesol |
News from qatests: Failed Starting Evergreen <http://testing.evergreen-ils.org/~live> |
| 17:19 |
pinesol |
News from qatests: Failed Running settings-tester.pl <http://testing.evergreen-ils.org/~live> |
| 17:19 |
pinesol |
News from qatests: Failed Running perl live tests <http://testing.evergreen-ils.org/~live> |
| 17:19 |
pinesol |
News from qatests: Failed <http://testing.evergreen-ils.org/~live> |
| 17:24 |
dbwells |
:( |
| 17:36 |
|
khuckins joined #evergreen |
| 17:54 |
Bmagic |
Grrrr, xpath yall |
| 17:54 |
Bmagic |
oils_xpath('//datafield[@tag="856"]/subfield[@code="u"]/text()',marc) doesn't seem to work |
| 17:57 |
Bmagic |
ha! //*[@tag="856"]/*[@code="u"] worked |
| 18:30 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 19:31 |
pinesol |
News from qatests: Failed setting ld.so.conf and rsyslog and /etc/hosts and ejabberd <http://testing.evergreen-ils.org/~live> |
| 19:31 |
pinesol |
News from qatests: Failed Running OpenSRF build tests <http://testing.evergreen-ils.org/~live> |
| 19:31 |
pinesol |
News from qatests: Failed Running Evergreen build tests <http://testing.evergreen-ils.org/~live> |
| 19:31 |
pinesol |
News from qatests: Failed configure apache <http://testing.evergreen-ils.org/~live> |
| 19:31 |
pinesol |
News from qatests: Failed Starting Evergreen <http://testing.evergreen-ils.org/~live> |
| 19:31 |
pinesol |
News from qatests: Failed Running pgTAP tests <http://testing.evergreen-ils.org/~live> |
| 19:31 |
pinesol |
News from qatests: Failed Running perl live tests <http://testing.evergreen-ils.org/~live> |
| 19:31 |
pinesol |
News from qatests: Failed Log Output: osrfsys.log - Expected 3 errors but encountered 171. <http://testing.evergreen-ils.org/~live> |
| 19:31 |
pinesol |
News from qatests: Failed <http://testing.evergreen-ils.org/~live> |
| 10:08 |
|
jvwoolf joined #evergreen |
| 10:10 |
|
yboston joined #evergreen |
| 10:39 |
|
khuckins joined #evergreen |
| 10:40 |
Dyrcona |
remingtron | mmorgan: I've made the branches and pushed them to the working repo. I'm going to test them on MassLNC VMs before updating the bug and adding the pullrequest tag. |
| 10:44 |
remingtron |
Dyrcona++ |
| 10:45 |
|
abneiman joined #evergreen |
| 10:46 |
Dyrcona |
@blame [band] |
| 10:46 |
* Dyrcona |
waits on the installation script.... |
| 10:51 |
Dyrcona |
It takes about 20 to 25 minutes from start to finish, if anyone cares. :) |
| 11:40 |
Dyrcona |
After some fun with clearing the cache and cookies, the 3.1 branch works for me. |
| 11:41 |
Dyrcona |
bshum suggested using incognito mode windows for testing, which I think is a good idea. I'll try that next time. |
| 11:42 |
mmorgan |
Dyrcona: I would second the use of incognito mode |
| 11:43 |
Dyrcona |
And, hey! There's a developers' meeting scheduled for this afternoon. |
| 11:44 |
Dyrcona |
mmorgan: You would be interested to know that I have updated the build scripts for the MassLNC VMs and fixed most of the issues. I will send an email to the interested parties later. This branch testing also constitutes testing of the scripts. |
| 11:45 |
mmorgan |
Dyrcona++ |
| 11:49 |
|
sandbergja joined #evergreen |
| 12:12 |
|
jihpringle joined #evergreen |
| 13:12 |
|
beanjammin joined #evergreen |
| 13:17 |
|
stlink joined #evergreen |
| 13:21 |
stlink |
Problem solved: they had blocked cookies from being accepted from the PINES server. |
| 13:28 |
remingtron |
Seems like the qatests haven't run in a while |
| 13:28 |
remingtron |
According to IRC logs, looks like this is the last day it ran (or logged to IRC anyway): http://irc.evergreen-ils.org/openils-evergreen/2018-08-27 |
| 13:29 |
remingtron |
er, I guess the test output says Sept 10, but that's still a while ago |
| 13:30 |
remingtron |
phasefx: what's the state of the test server? |
| 13:45 |
remingtron |
sandbergja: Seems like we need to remove old docs files, like "circulating_items.adoc |
| 13:45 |
remingtron |
", which has been replaced by "circulating_items_web_client.adoc". Keeps causing confusion. |
| 13:46 |
remingtron |
sandbergja: if you have any thoughts on how to approach that process, I'd love to hear them! |
| 13:47 |
* miker |
will not be able to make it to the dev meeting today :( |
| 13:57 |
phasefx |
remingtron: re: test server, on my plate for next Tuesday |
| 13:57 |
remingtron |
phasefx: awesome |
| 13:57 |
* dbwells |
will also miss the dev meeting today |
| 14:02 |
berick |
in light of the above, and given there's no agenda or email reminder, perhaps we should push the dev meeting back a week. |
