| Time |
Nick |
Message |
| 03:36 |
|
Bmagic joined #evergreen |
| 03:46 |
|
Jillianne joined #evergreen |
| 06:31 |
pinesol_green |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 07:34 |
|
agoben joined #evergreen |
| 07:40 |
|
rlefaive joined #evergreen |
| 07:41 |
|
rjackson_home joined #evergreen |
| 07:46 |
|
tlittle joined #evergreen |
| 07:49 |
|
rlefaive joined #evergreen |
| 08:00 |
|
collum joined #evergreen |
| 08:15 |
|
kmlussier joined #evergreen |
| 08:16 |
|
rlefaive joined #evergreen |
| 08:23 |
kmlussier |
Good morning #evergreen |
| 08:31 |
JBoyer |
@coffee kmlussier |
| 08:31 |
* pinesol_green |
brews and pours a cup of Ethiopia Washed Yirgacheffe, Koke Grade 1, and sends it sliding down the bar to kmlussier |
| 08:31 |
JBoyer |
@coffee |
| 08:31 |
* pinesol_green |
brews and pours a cup of Ethiopia Yirgacheffe Koke, and sends it sliding down the bar to JBoyer |
| 08:31 |
JBoyer |
Popular region this morning. |
| 08:31 |
kmlussier |
It's an Ethiopian coffee day! |
| 08:31 |
kmlussier |
JBoyer: Cheers! |
| 08:43 |
|
Dyrcona joined #evergreen |
| 08:53 |
|
mmorgan joined #evergreen |
| 09:01 |
* csharp |
has like 4 Ethiopian restaurants down the street from his office and has never tried them |
| 09:07 |
JBoyer |
You absolutely should, it's good stuff. |
| 09:12 |
|
terran joined #evergreen |
| 09:28 |
|
derekz joined #evergreen |
| 09:37 |
Dyrcona |
csharp: How much down time did you have during your 3.0 upgrade? |
| 09:38 |
csharp |
Dyrcona: approximately 6 hours |
| 09:38 |
Dyrcona |
Thanks! |
| 09:38 |
csharp |
we scheduled 2.5 days |
| 09:38 |
csharp |
but in reality, the upgrade took about 6 |
| 09:39 |
|
yboston joined #evergreen |
| 09:39 |
Dyrcona |
My trouble is timing the db upgrade script. |
| 09:39 |
csharp |
Dyrcona: going from 2.12? |
| 09:39 |
Dyrcona |
csharp, yes. |
| 09:40 |
csharp |
also I moved the auth/other reingests out of the script, so I'm not counting that in the upgrade |
| 09:40 |
csharp |
the auth reingest for us took ~30 hours |
| 09:40 |
Dyrcona |
I thought so. |
| 09:40 |
Dyrcona |
I've left 'em in at the end, but may move them to a separate script. |
| 09:50 |
kmlussier |
gmcharlt: Does bug 1741997 require an authority reingest or any new bib-to-auth or auth-to-auth linking if it's applied to a server that is already on 3.0? |
| 09:50 |
pinesol_green |
Launchpad bug 1741997 in Evergreen "additional browse improvements" [Medium,Confirmed] https://launchpad.net/bugs/1741997 |
| 09:50 |
gmcharlt |
kmlussier: it will require some browse reindexing but no bib-auth relinking |
| 09:51 |
gmcharlt |
I'll look into it today and provide details in the branch |
| 09:51 |
kmlussier |
gmcharlt: Thanks! |
| 09:51 |
Dyrcona |
gmcharlt++ |
| 10:01 |
berick |
csharp: do you recall what part of the sql took so long? |
| 10:03 |
csharp |
berick: lemme see if I recorded it |
| 10:05 |
yboston |
good morning everyone, I am extremely out of the loop , so pardon my simple question. If we upgrade to EG 3.x, are we forced to stop using the XUL client immediately or can both clients be used intially? thanks |
| 10:05 |
csharp |
berick: UPDATE authority.record_entry SET id = id WHERE NOT DELETED; <-- so the main process |
| 10:06 |
csharp |
yboston: both clients work for us |
| 10:06 |
csharp |
and as the saying goes "If it works in PINES..." |
| 10:06 |
yboston |
csharp: thanks :) |
| 10:06 |
csharp |
yboston: nice to see ya |
| 10:06 |
yboston |
csharp: same here |
| 10:06 |
|
rlefaive joined #evergreen |
| 10:07 |
kmlussier |
yboston: The XUL client won't go away until 3.2. But no more bug fixes will be added to it. |
| 10:07 |
berick |
csharp: ok, good, I can work with that... i'll probably move that to a batched post-upgrade update. |
| 10:07 |
csharp |
berick: yep |
| 10:08 |
csharp |
it wasn't quite that slow in testing - I would definitely batch it if I'd known it would take so long |
| 10:12 |
|
rjackson_isl joined #evergreen |
| 10:18 |
|
mmorgan1 joined #evergreen |
| 10:23 |
|
jvwoolf joined #evergreen |
| 10:28 |
terran |
Hi yboston! |
| 10:28 |
yboston |
terran: ¡Hola! |
| 10:29 |
yboston |
kmlussier: ¡thanks! |
| 10:29 |
yboston |
kmlussier: I still want to get you that flan |
| 10:30 |
kmlussier |
yboston: :) |
| 10:30 |
kmlussier |
yboston: Are you planning to go to the conference this year? |
| 10:30 |
yboston |
kmlussier: I raised about $6,200 for Puerto Rico with that flan raffle, Is is that good :) |
| 10:30 |
kmlussier |
yboston: That's awesome! I wish I could have gone. |
| 10:31 |
yboston |
kmlussier: sadly no, our travel budget is being spent differently than years before. I may not travel this year at all. if I do it would be for my new open source focus which is Islandora/Fedora |
| 10:35 |
kmlussier |
yboston: I'll just need to find an excuse to travel up to Boston someday so that I can visit. |
| 10:35 |
yboston |
kmlussier: absolutely, let me know |
| 10:36 |
yboston |
kmlussier: I will be flan ready |
| 10:37 |
csharp |
hmm - how would one use IP redirection (/openils/conf/lib_ips.txt) with an nginx proxy in place? |
| 10:37 |
csharp |
I guess I should ask, how *did* we in 2.12? hmmm |
| 11:05 |
berick |
csharp: mod_rpaf not cutting it? |
| 11:08 |
|
krvmga joined #evergreen |
| 11:09 |
Dyrcona |
@coin |
| 11:09 |
pinesol_green |
Dyrcona: tails |
| 11:11 |
krvmga |
i'm having difficulty displaying NoveList Select content in the staff client. It displays fine in the OPAC. I can't find anyplace where I'm blocking it by staff ctx. Is there anything else I can look for? |
| 11:11 |
krvmga |
@coin |
| 11:11 |
pinesol_green |
krvmga: heads |
| 11:12 |
Dyrcona |
krvmga: I was thinking also that Novelist might have recently changed the code to look for some JavaScript feature that the staff client doesn't support, but that's speculation on my part. |
| 11:14 |
Dyrcona |
"Staff client" being the XUL client in both cases. :) |
| 11:17 |
JBoyer |
It might be specifically hidden here just to avoid taking up all of that space. I don't know if it ever worked in the XUL client |
| 11:18 |
JBoyer |
(Well, it probably did at one point. but still.) |
| 11:18 |
Dyrcona |
JBoyer: I believe we've had it working in the XUL client. |
| 11:18 |
kmlussier |
Is anything showing up in the Javascript Console? |
| 11:24 |
terran |
krvmga: I had that on my list to look at today as well |
| 11:25 |
terran |
JBoyer: It was working in the web client before. We hid it locally for a while because there were issues where if it took too long to load it was slowing staff work down, but we un-did the hide code we had and it's still not working. We also seem to be having problems with Syndetics added content. |
| 11:26 |
terran |
I was thinking maybe it's because it contains mixed http and https content? |
| 11:26 |
JBoyer |
Huh. Since it looks like I specifically force it on for the public and don't disable it for the staff maybe I'll join in on the hunt. |
| 11:27 |
JBoyer |
That may do it. That causes http 856's to fail in the web client. |
| 11:29 |
JBoyer |
Huh. Works fine here on 3.0.3-ish. |
| 11:29 |
JBoyer |
in the web client |
| 11:32 |
JBoyer |
We do load the novelist js over https if that's of any help. |
| 11:33 |
terran |
JBoyer: Thanks, I'll check to see how we load ours... |
| 11:34 |
krvmga |
kmlussier: the one thing that shows up in the javascript console as an error is TypeError:Object.assign is not a function followed by https://imageserver.ebscohost.com/novelistselect/ns2init.js |
| 11:38 |
Dyrcona |
krvmga: Object.assign() is newer than XULRunner 14.0.1. |
| 11:38 |
Dyrcona |
Looks like it was added in Firefox 34. |
| 11:40 |
krvmga |
Dyrcona: it may be an incompatibility, then, as you thought. if this is true, i won't do anything about it because we'll move to 3.0 soon. |
| 11:40 |
krvmga |
and we won't have to worry about it in the web client |
| 11:41 |
Dyrcona |
Looks like it's new in Ecmascript 6. |
| 12:03 |
JBoyer |
That reminds me of a bug I thought I had entered about using brand-new JS features; apparently I started a draft and never finished it. :( |
| 12:11 |
|
Christineb joined #evergreen |
| 12:15 |
|
khuckins joined #evergreen |
| 12:21 |
csharp |
berick: ah - looks like it's installed but not enabled - thanks for the pointer! |
| 12:22 |
csharp |
wait - it is ... hmm |
| 12:25 |
berick |
it's possible rpaf is not up to the task. |
| 12:25 |
berick |
may have to tweak how the redirector extracts the client IP |
| 12:26 |
berick |
i'm having strong feeling of deja vu |
| 12:28 |
berick |
csharp: http://irc.evergreen-ils.org/evergreen/2017-09-05#i_322171 |
| 12:29 |
csharp |
berick: thanks - I knew we had discussed it but couldn't find the link |
| 12:30 |
berick |
some fixes posted if you read down |
| 12:30 |
berick |
various |
| 12:35 |
csharp |
berick++ |
| 12:35 |
csharp |
looks like I fixed it on the running server at the time but didn't add the change to our repo |
| 12:35 |
csharp |
not sure if that needs to be more generally applicable |
| 12:35 |
csharp |
my $user_ip = $apache->headers_in->{'X-Real-IP'}; does the trick |
| 12:36 |
csharp |
in Redirect.pm (for the logs - for future csharp next time you hit the problem ;-)) |
| 12:40 |
Dyrcona |
csharp: Have you read any books by Dan Ariely because he mentions how we consider our future self to be a different person? |
| 12:42 |
csharp |
Dyrcona: no I haven't, but I'll check it out |
| 12:43 |
Dyrcona |
You comment about "future csharp" made me think of it, of course. |
| 12:46 |
csharp |
@praise Future csharp |
| 12:46 |
* pinesol_green |
Shall I compare Future csharp to a summer's day? Future csharp is more lovely and more temperate. |
| 12:46 |
|
rlefaive joined #evergreen |
| 12:47 |
JBoyer |
With future comes perspective, I hear. |
| 12:47 |
Dyrcona |
Heh. |
| 12:47 |
JBoyer |
And with time comes future, and the hip bone is connected to the, uh, fell off the rails somewhere. |
| 12:50 |
|
sandbergja joined #evergreen |
| 12:52 |
|
jvwoolf joined #evergreen |
| 12:53 |
|
jihpringle joined #evergreen |
| 12:55 |
|
yar joined #evergreen |
| 13:10 |
|
mmorgan joined #evergreen |
| 13:38 |
JBoyer |
I'm trying to use Vandelay to import a record and create items at the same time and it absolutely will not create the item. I've got the branch set as a working location, logged in with a workstation at that location, selected an item import profile (just the stock Eg 852), the record looks good, but... |
| 13:39 |
JBoyer |
The record imports fine and follows the overlay option selected, just no items. the 852 is not in the trash fields either (anymore), |
| 13:39 |
JBoyer |
and I've tried full overlay, match only, nothing seems to matter. |
| 13:42 |
kmlussier |
JBoyer: Is there an error message showing in the queue? |
| 13:42 |
|
collum_ joined #evergreen |
| 13:43 |
JBoyer |
Nope, it's as if the field isn't there at all. |
| 13:43 |
JBoyer |
(as far as the interface is concerned) |
| 13:43 |
kmlussier |
JBoyer: In the queue, then, it's showing 0 item import failures? |
| 13:44 |
JBoyer |
Records in queue = 1, records imported = 1, everything else is 0. |
| 13:45 |
|
collum__ joined #evergreen |
| 13:47 |
kmlussier |
Huh. The times I haven't been able to import items, either it tells me there is an import failure, or it's a case where the record didn't successfully import (maybe because of insufficient quality). |
| 13:48 |
troy__ |
there a quick callnumber id -> name lookup function? |
| 13:50 |
JBoyer |
troy__, not really outside of psql (or your database interface of choice). If you've got the id do you have similarly quick access to the record field? There is an easy way to look up records by id, which can get you to the call numbers. |
| 13:50 |
troy__ |
have the copy id too yea |
| 13:51 |
JBoyer |
copy id isn't very helpful either, bib records are the only thing easy to look up by id number. |
| 13:51 |
JBoyer |
I'll keep poking at this kmlussier, thanks for the ideas. |
| 13:51 |
JBoyer |
kmlussier++ |
| 13:53 |
troy__ |
bib lookup won't be feasible for this scenario, but thanks |
| 13:53 |
troy__ |
direct to db it is |
| 13:53 |
Dyrcona |
troy__: What exactly are your trying to do? Is this a one-time thing or something that you'll want to automate? |
| 13:54 |
troy__ |
automate |
| 13:54 |
troy__ |
we do our interlibrary loans under one bib |
| 13:54 |
troy__ |
and i don't want to load all records under that to display one callnum |
| 13:54 |
Dyrcona |
I'd recommend becoming familiar with Cronscript.pm and open-ils.pcrud. |
| 13:56 |
Dyrcona |
Cronscript.pm can be used to help write Perl scripts that you can run on a brick or utility server that need to talk to Evergreen via OpenSRF. |
| 13:58 |
troy__ |
cool, thanks for the advice |
| 13:58 |
JBoyer |
kmlussier, so here's a cool thing: the record did look fine but that wasn't the record I was uploading. Good times. I suspect it will work fine if I import the record I'm looking at. |
| 13:58 |
troy__ |
JBoyer++ |
| 13:58 |
troy__ |
Dyrcona++ |
| 13:58 |
kmlussier |
JBoyer: LOL. Sounds like something I would do. |
| 13:58 |
Dyrcona |
JBoyer: :) |
| 13:59 |
JBoyer |
One of the hazards of having files with name like record.mrc and M20180124.mrc in the same directory... |
| 13:59 |
* Dyrcona |
just realized he needed to have services running on the vm where he's testing a backstage update. |
| 13:59 |
Dyrcona |
Lots of opensrf.settings IS NOT CONNECTED TO THE NETWORK!!! |
| 14:13 |
phasefx |
just noticed that our BuildBot isn't really doing anything anymore |
| 14:14 |
* phasefx |
nominates himself to be QA wrangler |
| 14:18 |
* Dyrcona |
seconds the nomination. :) |
| 14:23 |
miker |
troy__: actually, you might look into unapi. for example: http://demo.evergreencatalog.com/opac/extras/unapi?id=tag:open-ils.org:U2@acn/4848&format=xml |
| 14:24 |
kmlussier |
+1 for phasefx as QA wranger. |
| 14:26 |
miker |
troy__: the important part being the value of the id CGI param. you can replace that with any other tag URI (like, for the owning lib of the call number, tag:open-ils.org:U2 aou/4) and get back the relevant object |
| 14:28 |
|
khuckins_ joined #evergreen |
| 14:28 |
troy__ |
miker: thanks, i'll take a look at it |
| 14:28 |
troy__ |
miker++ |
| 14:28 |
* phasefx |
likes QA Ranger better |
| 14:29 |
JBoyer |
"Only YOU can prevent build failures" Also comes with a swell hat. |
| 14:29 |
phasefx |
JBoyer++ |
| 14:30 |
terran |
JBoyer: Are you using Syndetics added content as well? |
| 14:31 |
JBoyer |
Not anymore. We have a ContentCafe sub as part of our Novelist package. |
| 14:31 |
terran |
Ah, maybe that explains why your added content is working and mine isn't. |
| 14:32 |
JBoyer |
just your covers are broken or all AC? |
| 14:32 |
JBoyer |
Because I thought all cover art requests went through the local Eg server so they could be cached, regardless of source? |
| 14:34 |
|
gsams joined #evergreen |
| 14:34 |
terran |
The covers are loading, it's the stuff under the Added content tab. It loads the Reviews / TOC / Author Notes links, but when we click on them it does nothing |
| 14:35 |
JBoyer |
Oh! clicking on them. I did not actually test that this morning; I thought you meant it didn't load at all. Let me look again. |
| 14:36 |
kmlussier |
phasefx: IMO, if you volunteer for the role, you can name it whatever you want. |
| 14:36 |
kmlussier |
phasefx++ |
| 14:36 |
JBoyer |
I did throw a target="new" or whatever the syntax is on all 856 links for that same reason... |
| 14:38 |
kmlussier |
terran / JBoyer : That sounds very similar to the problem with http / https problem on the library info page. |
| 14:40 |
JBoyer |
Everything appears to work now that I've tried it all, clicking a search link even stays in the web client wrapper and the various tabs and whatnot act as expected. All of the links to EI searches have https in front of them |
| 14:42 |
terran |
We verified that we are using https in both the novelist and syndetics added content configs. Novelist loads fine in the opac but not the web client. Syndetics added content isn't loading either place. |
| 14:43 |
csharp |
I can see in the server logs that content is succesfully being retrieved, but that section in the OPAC just shows "No Content Available" |
| 14:44 |
JBoyer |
I thought Novelist builds the search links themselves, so there may be something on their end that needs to be updated. Not sure what's up with Syndetics. :/ |
| 14:46 |
terran |
The Novelist search links in the OPAC are working fine, and they're all built with https. They are including links to other related resources for us - I wonder if that's the problem. |
| 14:47 |
csharp |
we can see in the browser that the links include mixed content |
| 14:47 |
kmlussier |
terran: Does anything show up in the Console when you click on them? |
| 14:50 |
JBoyer |
I see. I don't think we had them add much of that initially because of the setup of an unrelated system. I do get complaints from links like the book lists and such, some http:// loaded image on ebsco's site. And yeah, if you've got links to databases or similar in yours those will be a no-go if they're not https. |
| 14:51 |
JBoyer |
https links are harder to find than I'd have hoped from a number of our vendors. |
| 14:58 |
csharp |
kmlussier: no console errors so far |
| 14:58 |
csharp |
possible that we can add debugging statements to see what's what |
| 14:58 |
terran |
It makes sense to me that it stops you from clicking on an http link, but shouldn't it be loading the link? In the other places we had http links, it loaded them and just wouldn't let you click |
| 14:58 |
terran |
(rather, would throw an error if you did click) |
| 15:04 |
terran |
I've put in a request to EBSCO to disable the additional e-resources section of our novelist content to see if that will allow it to load in our web client. |
| 15:06 |
kmlussier |
terran: Out of curiosity, when you've tested the behavior in the public catalog, are you logged in as a patron or are you using the catalog without a login? |
| 15:08 |
terran |
kmlussier: Both |
| 15:17 |
terran |
Spotting a syndetics error in the browser console that I didn't notice before: Uncaught TypeError: Cannot set property 'innerHTML' of null |
| 15:26 |
* berick |
grabs the LP-timeout spirit stick |
| 15:31 |
JBoyer |
LP timeouts exist in all of us, we only need want to avoid them enough. |
| 15:32 |
Dyrcona |
Quantum effects.... ;) |
| 15:33 |
Dyrcona |
...caused by my running make updates-clients. |
| 15:38 |
* mmorgan |
jumps on the missing Novelist Select content bandwagon. Seeing the problem in the xul client only, on both our 2.12 production and 3.0.3 test systems. |
| 15:40 |
kmlussier |
mmorgan: I think the xul client problem is different from what terran is seeing. krvmga and Dyrcona identified the source of that problem earlier this morning. |
| 15:41 |
kmlussier |
It sounded like it's not fixable in our current version of xul. |
| 15:43 |
* mmorgan |
scrolls back |
| 15:43 |
kmlussier |
mmorgan: Around 11:34 a.m. |
| 15:44 |
mmorgan |
Thanks! |
| 15:44 |
terran |
mmorgan: You're seeing novelist work in the web client though? Are you using Syndetics added content? |
| 15:45 |
mmorgan |
terran: No, like JBoyer, we have ContentCafe. |
| 15:45 |
terran |
Ah :( |
| 16:29 |
kmlussier |
mmorgan: On bug 1745233, are those located uri records also being retrieved when you limit by a copy location from the advanced search screen? |
| 16:29 |
pinesol_green |
Launchpad bug 1745233 in Evergreen "Records with located URIs are retrieved in Copy Location Group searches" [High,New] https://launchpad.net/bugs/1745233 |
| 16:32 |
* mmorgan |
looks |
| 16:45 |
* mmorgan |
needs the patch for bug 1744489 |
| 16:45 |
pinesol_green |
Launchpad bug 1744489 in Evergreen "Limit Search by Location Causes Syntax Error" [High,Fix committed] https://launchpad.net/bugs/1744489 |
| 17:03 |
|
derekz left #evergreen |
| 17:05 |
|
jvwoolf1 joined #evergreen |
| 17:11 |
|
mmorgan left #evergreen |
| 17:13 |
|
jvwoolf1 left #evergreen |
| 17:17 |
|
sandbergja joined #evergreen |
| 17:42 |
|
khuckins_ joined #evergreen |
| 18:31 |
pinesol_green |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 19:40 |
|
Jillianne joined #evergreen |
| 19:49 |
|
sandbergja joined #evergreen |
| 19:51 |
|
Christineb joined #evergreen |
| 20:49 |
|
Jillianne joined #evergreen |
