| 06:31 |
pinesol_green |
News from qatests: Test Success <http://testing.evergreen-ils.org/~live> |
| 07:15 |
|
rjackson_isl joined #evergreen |
| 07:34 |
|
agoben joined #evergreen |
| 08:02 |
|
_adb joined #evergreen |
| 11:15 |
jeff |
the precondition doesn't apply here, but I do believe there have been cases of that in the past. I don't recall any other details without digging. |
| 11:15 |
|
littlet joined #evergreen |
| 11:16 |
Dyrcona |
jeff: Only time I've seen it happen before is when placing multiple holds at once. This is with a single hold and appears to be "new behavior." |
| 11:17 |
Dyrcona |
I've not seen it in the OPAC on 3.02, and I'm waiting on a db copy to test on a vm similar to our production system. |
| 11:18 |
Dyrcona |
I'm looking at Lp 1671635 as the possible culprit, but want to make sure it's not just our customization to place_hold.tt2. |
| 11:18 |
pinesol_green |
Launchpad bug 1671635 in Evergreen 2.12 "Place hold success page changes search scope" [Medium,Fix released] https://launchpad.net/bugs/1671635 |
| 11:23 |
jeff |
Hrm. I'm used to left-side casting on a WHERE clause giving undesirable performance without an additional index (think xact_start::DATE BETWEEN '2017-12-01'::DATE AND '2017-12-31'::DATE vs xact_start >= '2017-12-01'::DATE AND < '2018-01-01'::DATE). Now, it's possible that the performance isn't as much of a problem as it was in the past. |
| 11:29 |
pinesol_green |
berick: Band 'Semi-PseudoCode' added to list |
| 11:34 |
dbs |
Hrm, I'm guessing there's no easy way to add a part name to myopac/circs.tt2; if a user has both parts signed out for a given item, there's no way they can easily tell which is which (barcode, yes, but that's not "easy"--heh) |
| 11:39 |
Dyrcona |
So, my problem mentioned above does not happen in the OPAC nor the web staff client on our production 2.12.8 system (with customization), nor does it happen in the OPAC or web staff client in 3.0.2 (without customization). |
| 11:40 |
Dyrcona |
Next step build a 3.0.2 xul client to test and build a stock 2.12.8 vm to test a stock XUL client there. |
| 11:43 |
Dyrcona |
Aw. crap. That server that I messed with the networking yesterday.... I can't ssh to the non-routeable IP address and it's not listening on the other one... |
| 11:43 |
jeff |
vm console time? |
| 11:49 |
Dyrcona |
This is a physical server in another building a few miles away. |
| 16:53 |
* jeff |
re-discovers the difference between Retarget Local Holds vs Retarget Local Holds + Retarget All Statuses |
| 16:53 |
jeff |
(with just Retarget Local Holds set, only items in In Process status are retargeted) |
| 17:39 |
|
jvwoolf left #evergreen |
| 18:31 |
pinesol_green |
News from qatests: Test Success <http://testing.evergreen-ils.org/~live> |
| 05:48 |
|
StomproJ joined #evergreen |
| 05:55 |
|
remingtron joined #evergreen |
| 05:55 |
|
StomproJ joined #evergreen |
| 06:30 |
pinesol_green |
News from qatests: Test Success <http://testing.evergreen-ils.org/~live> |
| 07:13 |
|
rjackson_isl joined #evergreen |
| 07:34 |
|
agoben joined #evergreen |
| 07:36 |
|
dwgreen joined #evergreen |
| 11:25 |
dbs |
hah, ERROR: date/time field value out of range: "0000-12-29T23:59:00-04:00" |
| 11:30 |
dbs |
or is it crap like "open-ils.search[11996]: [ERR :11996:Z3950.pm:494:1513698318917678] z3950: bad XML : Tag "7||" is not a valid tag. at /usr/share/perl5/MARC/File/USMARC.pm line 223" |
| 11:31 |
|
Christineb joined #evergreen |
| 11:31 |
Dyrcona |
So, updated a test system to the latest ubuntu 16.04 4.4.0 kernel and other packages. Apache2 just times out. |
| 11:32 |
Dyrcona |
Don't seem to have this problem on a different machine. |
| 11:34 |
Dyrcona |
Ah, wait a minute.... |
| 11:36 |
dbs |
got it, hours of operation were set to 00:00:00 to 00:00:00 across the board |
| 11:43 |
Dyrcona |
Of course, the interface is UP RUNNING.... |
| 11:45 |
|
jihpringle joined #evergreen |
| 11:46 |
|
_adb joined #evergreen |
| 11:46 |
* Dyrcona |
thinks maybe kernel -104 has issues....But! my test VM doesn't do this. |
| 11:50 |
|
jvwoolf joined #evergreen |
| 11:52 |
jeff |
the "RTNETLINK answers: File exists" often indicates that state between your networking scripts and the live system has gotten out of sync. Sometimes it's your config trying to add a route that you've already added by hand, etc. Other times, a symptom of having two interfaces that both declare an identical route. |
| 11:53 |
jeff |
check your config for duplicate routes (including default routes / gateway entries), and then consider a full stop/start of networking or even a reboot. |
| 14:34 |
JBoyer |
dbs, I would hope that the only places that are closed 7 days a week have no copies, but just in case 7 places are about to be open for an hour a week... |
| 14:34 |
JBoyer |
dbs++ |
| 14:35 |
Bmagic |
berick++ |
| 14:35 |
Bmagic |
berick: I am going to test it! |
| 14:48 |
Dyrcona |
Bmagic++ #testing in production |
| 14:48 |
Bmagic |
yep! Exactly |
| 14:49 |
Bmagic |
hmmm... can I delete the acq.edi_message row? and the new order pusher will create it again? |
| 14:52 |
berick |
Bmagic: yes. you should also be able to set the status on the edi_message to 'retry' |
| 18:10 |
berick |
+1 to release |
| 18:18 |
dbwells |
Just noticed yesterday was our eight year Evergreen anniversary. Cheers to all, and here's to another eight :) |
| 18:19 |
berick |
dbwells: huzzah! |
| 18:32 |
pinesol_green |
News from qatests: Test Success <http://testing.evergreen-ils.org/~live> |
| 20:42 |
|
StomproJ joined #evergreen |
| 20:56 |
|
jvwoolf joined #evergreen |
| 00:19 |
pinesol_green |
[evergreen|Bill Erickson] LP#1735807 Webstaff holdings owning lib shortname - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=fe30a5e> |
| 06:31 |
pinesol_green |
News from qatests: Test Success <http://testing.evergreen-ils.org/~live> |
| 07:15 |
|
rjackson_isl joined #evergreen |
| 07:28 |
|
JBoyer joined #evergreen |
| 08:48 |
|
Dyrcona joined #evergreen |
| 11:26 |
Dyrcona |
syntax error at /usr/local/share/perl/5.22.1/OpenILS/WWW/EGCatLoader/Record.pm line 317, near "else" |
| 11:27 |
Dyrcona |
Record.pm looks like your culprit. |
| 11:27 |
* Dyrcona |
ran into something similar last week. |
| 11:27 |
Dyrcona |
I busted something in circulation on a test server. |
| 11:28 |
JBoyer |
EGCatLoader is almost never the problem when EGCatLoader is where the error is logged. |
| 11:28 |
csharp |
I have no memory of customizing that file |
| 11:28 |
Dyrcona |
Right. It's usually one of the modules used by EGCatLoader. |
| 13:15 |
_adb |
you may be amused by lolcat (it's in ubuntu repos.) it's a replacement for the 'cat' command. |
| 13:23 |
csharp |
_adb++ # lolcat |
| 13:34 |
|
khuckins__ joined #evergreen |
| 13:50 |
dbs |
Dyrcona: ran your marc_export --uris today, seemed to do the job nicely! Considering signing it off but also considering how to write an automated test for it... |
| 13:50 |
Dyrcona |
dbs: Yeah, tests are missing for most of the support scripts. |
| 13:52 |
csharp |
maybe we need to have virtual hacking days for stuff like test writing |
| 13:52 |
csharp |
ala DIG hackfests |
| 13:58 |
Dyrcona |
Not a bad idea, though I'm not sure how you'd test some of the scripts. |
| 15:04 |
|
jvwoolf joined #evergreen |
| 15:10 |
Dyrcona |
FYI for anyone who cares, I just merged the evergreen-3.0-compatibility branch into evergreen_utilities master. |
| 15:10 |
jeff |
ah. |
| 15:13 |
Dyrcona |
Guess I still can. Should I sign it with my GPG key that expires in 2 days? :) |
| 15:16 |
Dyrcona |
There we go. I pushed a tag: eg-2.12-compat |
| 16:17 |
|
Christineb joined #evergreen |
| 16:19 |
Bmagic |
I'm getting an error when importing a test authority record. Complaining about a column that doesn't exist. |
| 16:20 |
Bmagic |
Error retrieving vandelay::authority_match with query [SELECT "vam".id, "vam".queued_record, "vam".eg_record, "vam".quality,............... ERROR: column vam.quality does not exist |
| 16:20 |
Bmagic |
should vam have a quality column? |
| 16:21 |
Bmagic |
the code tells me yes |
| 16:21 |
|
khuckins joined #evergreen |
| 16:21 |
Bmagic |
012.schema.vandelay.sql |
| 16:21 |
Dyrcona |
My 3.0.2 test database tells me yes. |
| 16:21 |
Dyrcona |
quality | integer | not null default 0 |
| 16:23 |
Bmagic |
weird. I wonder why we dont have that column |
| 16:23 |
Dyrcona |
Failed db upgrade? |
| 16:57 |
gmcharlt |
Bmagic: send me an email |
| 16:57 |
Bmagic |
will do |
| 17:30 |
|
jvwoolf left #evergreen |
| 18:30 |
pinesol_green |
News from qatests: Test Success <http://testing.evergreen-ils.org/~live> |
| 06:31 |
pinesol_green |
News from qatests: Test Success <http://testing.evergreen-ils.org/~live> |
| 07:15 |
|
rjackson_isl joined #evergreen |
| 07:15 |
|
rjackson_isl_ joined #evergreen |
| 07:27 |
|
jvwoolf joined #evergreen |
| 09:14 |
csharp |
kmlussier: thanks! |
| 09:15 |
csharp |
I want to reproduce it - if it's because I connected to multiple EG servers in a single browser (seems to be so, since the failure is related to actor.survey), it may not need to be considered a bug, per se |
| 09:15 |
csharp |
i.e., the answer might just be "don't do that" |
| 09:20 |
kmlussier |
csharp: I have connections open to multiple Evergreen servers in the same browsers all the time. I'm constantly doing side-by-side testing on two different servers. I don't think that should cause the problem. |
| 09:21 |
kmlussier |
csharp: When it previously happened to me, it was more likely to happen after I rebuilt my VM. |
| 09:26 |
|
yboston joined #evergreen |
| 09:26 |
|
rfrasur joined #evergreen |
| 09:32 |
|
mllewellyn joined #evergreen |
| 09:56 |
kmlussier |
pinesol_green: Thank you for not giving me decaf. |
| 09:56 |
pinesol_green |
kmlussier: Have you confirmed your ISBN SPIDs with your service provider? |
| 09:56 |
rfrasur |
kmlussier: anything that helps suss the thing out. |
| 09:57 |
berick |
rfrasur: the print test interface includes an image. does that one work? |
| 09:57 |
rfrasur |
let's see. |
| 09:58 |
rfrasur |
berick: that's on the way. |
| 09:59 |
berick |
rfrasur: next question, are you testing on a machine w/ a valid SSL certificate? |
| 09:59 |
rfrasur |
The image does work. (I'm the go between here, sorry) |
| 09:59 |
berick |
oh, good |
| 09:59 |
rfrasur |
lol, uh huh |
| 10:01 |
rfrasur |
@coffee berick |
| 10:01 |
* pinesol_green |
brews and pours a cup of Hacienda La Esmeralda, and sends it sliding down the bar to berick |
| 10:01 |
rfrasur |
You're a good person. |
| 10:02 |
berick |
heh, ok, backing up.. so the test image works? |
| 10:03 |
rfrasur |
it does, and throwing a new image in there works, but it doesn't seem to work in the actual receipts. |
| 10:04 |
berick |
ah, ok |
| 10:04 |
berick |
which receipt are you testing? |
| 10:04 |
rfrasur |
holds shelf |
| 10:05 |
csharp |
kmlussier: ah - that makes sense - I have rebuilt my test VMs DB recently |
| 10:09 |
berick |
rfrasur: i'm setting up a test to see if I can make it work.. |
| 10:11 |
rfrasur |
Excellent |
| 10:11 |
kmlussier |
@praise berick |
| 10:11 |
* pinesol_green |
berick is kind and patient to newbies |
| 10:28 |
|
mllewellyn1 joined #evergreen |
| 10:29 |
jeff |
rfrasur: if the library web site lacks a valid certificate, then the image might need to be served from the Evergreen server, where a valid certificate is presumably in place. |
| 10:29 |
kmlussier |
berick: Yes, the Evergreen server would have the valid ssl certificate. But I think some libraries might use images off their own web sites, where they may not have people logging in. |
| 10:32 |
rfrasur |
jeff: it did present from the library web site to the test receipt though. |
| 10:33 |
berick |
turns out it may not be a problem. i just printed an http:// image without issue |
| 10:33 |
berick |
i think i confused myself.. |
| 10:34 |
* rfrasur |
laughs |
| 10:40 |
berick |
Bmagic++ # good tip |
| 10:40 |
rfrasur |
bmagic: I'll send that along and see how it goes for it. |
| 10:41 |
Bmagic |
pretty sweet thing |
| 10:41 |
jeff |
a technique that i think works in the xul client and could be tested in hatch is to use.. nevermind, interrupted and Bmagic beat me to it. :-) |
| 10:41 |
jeff |
(data: urls -- i can make no claims or assurances as to the site Bmagic mentioned) |
| 10:42 |
Bmagic |
that website will convert the image into a huge long string of text that should* work (at least it has worked for me when I needed something like that) |
| 10:42 |
kmlussier |
berick: Is the image something that should work with or without hatch? I'm testing without hatch, and, even when I see the image the preview, I don't see it in the actual slip. |
| 10:42 |
kmlussier |
I didn't try Bmagic's method yet. |
| 10:42 |
Bmagic |
I wonder if we can embed that sort of thing for the patron profile picture in the database? |
| 10:42 |
rfrasur |
No worries. Gonna give it a try...eventually. |
| 10:42 |
berick |
kmlussier: yes, it should work with or without hatch |
| 10:42 |
rfrasur |
(that's very cool, btw) |
| 10:46 |
berick |
kmlussier: in the browser, I do have to use HTTPS |
| 10:46 |
berick |
since the page is https |
| 10:46 |
csharp |
hmm - seeing an error when applying an annotated payment: https://pastebin.com/jbD3r0sQ |
| 10:47 |
csharp |
basically, error quoting string - apparently "null" is the string it's mad about |
| 10:48 |
csharp |
this is on our 3.0.1 testing server - not seeing it in 2.12.4 or on my stock master server |
| 10:48 |
Bmagic |
can I quote you csharp? |
| 10:48 |
Bmagic |
"csharp" |
| 10:48 |
Dyrcona |
Ah, null.... I was gonna say maybe you have a ' in your string. |
| 10:55 |
csharp |
Dyrcona: I'll have to check |
| 10:55 |
Dyrcona |
yeah. Best to make sure before looking for other causes. :) |
| 10:56 |
csharp |
nope - I think we were just assuming I'd have 3.0.2 installed by now :-/ |
| 10:56 |
Dyrcona |
I've missed important commits in production updates, and I know it can happen in testing. :) |
| 10:56 |
csharp |
this week totally got away from me |
| 10:56 |
Dyrcona |
:) |
| 10:57 |
Dyrcona |
Weeks'll do that. |
| 10:57 |
Bmagic |
weeks++ |
| 10:58 |
Bmagic |
weeks 1, days nill |
| 10:59 |
csharp |
our test server has been patched so much I'm not sure whether all of them are there |
| 10:59 |
csharp |
time to just rebuild the app servers and try again from there |
| 11:02 |
Dyrcona |
Yeap. That's why I like VMs. Just delete and build a fresh one every so often. |
| 11:10 |
csharp |
yeah, I verified that the fix was *not* applied for some reason - done now |
| 11:10 |
csharp |
and working as expected |
| 14:54 |
Dyrcona |
I really don't know, unfortunately. |
| 14:54 |
rjackson_isl |
yeah - and not sure I want to experiment live! |
| 14:55 |
Dyrcona |
We solved our problem by deleting one of the duplicate part maps or whatever. |
| 14:55 |
Dyrcona |
Well, if you have a test system where you can experiment, then no real harm done. |
| 14:55 |
rjackson_isl |
problem is I am not up to speed on how they use the cataloging interface enough to pull off the test :( |
| 14:57 |
mmorgan |
rjackson_isl: I would say undeleting the monograph part and adding back the missing asset.copy_part_map should fix the immediate problem. |
| 14:57 |
rjackson_isl |
++mmorgan thanks for the input was hoping that makes sense! |
| 14:58 |
* mmorgan |
has performed minor surgery on copy_part_maps in the past. |
| 15:33 |
Dyrcona |
It's not that unusual to have to modify upgrade scripts. I almost always have to. |
| 15:35 |
berick |
Bmagic: tried a few at random and they're pretty snappy. i wonder how many rows are returned for your user ID 425135 |
| 15:35 |
Bmagic |
berick: I can confirm! Browsing to that link generates that query and the query gets stuck on postgres server |
| 15:35 |
berick |
none of my tests retunred more than a few rows |
| 15:36 |
Bmagic |
berick: well, I don't get the answer using that exact query. Which table should I look at? money.payment ? |
| 15:37 |
mdriscoll |
Dyrcona: yes, that's the other missing functions. I can add them of course and then run 3.0.1-3.0.2. |
| 15:37 |
berick |
Bmagic: meaning, it never completes? |
| 15:42 |
Bmagic |
still running - I don't think that made a difference |
| 15:42 |
berick |
something in that nest of joins needs help |
| 15:42 |
Bmagic |
agreed |
| 15:43 |
berick |
to be fair, i'm testing on 2.10 db |
| 15:43 |
Bmagic |
that is a lot of joins |
| 15:43 |
Bmagic |
17 left joins |
| 15:43 |
Bmagic |
and the columns selected are only from one table, lol |
| 16:48 |
csharp |
mdriscoll: check that you have run 2.12.6-3.0.0-upgrade-db.sql |
| 16:48 |
csharp |
maybe something in that failed |
| 16:49 |
csharp |
mdriscoll: if config.upgrade_log lacks 1063, then something went wrong and probably means you're missing more than just that |
| 16:50 |
mdriscoll |
csharp: I had a few errors with 2.12.6-3.0.0 but they were from my own stupid mistakes. I think I'll try to find another test system to run through the 2.12.4-3.0.2 scripts. |
| 16:50 |
csharp |
mdriscoll: 10-4 |
| 16:51 |
csharp |
mdriscoll: you might grep deps_block 2.12.6-3.0.0-upgrade-db.sql and make sure you aren't missing others in the list of numbered scripts - it's an all-or-nothing script though, so I would expect you're missing all of them |
| 16:51 |
csharp |
(unless you tweaked the script) |
| 18:01 |
Bmagic |
Any thoughts on having an example birth date format next to the date of birth box on the patron registration form in Webby? |
| 18:02 |
Bmagic |
I suppose it would have to take into account what format the branch has in the settings? |
| 18:07 |
* csharp |
thinks we should have an example show |
| 18:31 |
pinesol_green |
News from qatests: Test Success <http://testing.evergreen-ils.org/~live> |
| 06:08 |
|
phasefx joined #evergreen |
| 06:09 |
|
berick joined #evergreen |
| 06:10 |
|
maryj joined #evergreen |
| 06:31 |
pinesol_green |
News from qatests: Test Success <http://testing.evergreen-ils.org/~live> |
| 07:09 |
|
rjackson_isl joined #evergreen |
| 07:34 |
|
agoben joined #evergreen |
| 07:55 |
|
Dyrcona joined #evergreen |
| 08:38 |
|
mmorgan joined #evergreen |
| 08:40 |
|
jvwoolf joined #evergreen |
| 08:49 |
|
jvwoolf1 joined #evergreen |
| 09:23 |
csharp |
cool - Fedora (as of 27) has javafx in the repos which means I can theoretically use Hatch on my main OS |
| 09:23 |
csharp |
of course, I've not had great luck with networked printers on Fedora over the last couple of releases :-/ |
| 09:26 |
csharp |
./hatch.sh compile and ./hatch.sh test appear to work fine |
| 09:27 |
Dyrcona |
I build Hatch on Ubuntu 16.04, but have not used it on Linux. |
| 09:27 |
Dyrcona |
s/build/built/ |
| 09:33 |
csharp |
berick: referring back to our exchange last week (http://irc.evergreen-ils.org/evergreen/2017-12-06#i_336931), I'm not seeing org.evergreen_ils.hatch.json in ~/.config/google-chrome/NativeMessagingHosts/ - I do see it in the Hatch git repo thouhg |
| 14:26 |
|
mmorgan left #evergreen |
| 14:33 |
|
rlefaive joined #evergreen |
| 14:36 |
Dyrcona |
fcc-- |
| 14:44 |
csharp |
fcc-- |
| 14:44 |
csharp |
pai-- |
| 14:46 |
csharp |
berick: ok, I've tested the lp1733692-nsis-best-practices-signoff hatch branch on Windows and Linux and all is working - I'm a little confused about what needs signing off for all to be official... |
| 14:47 |
csharp |
bug 1733692 and bug 1708757 |
| 14:47 |
pinesol_green |
Launchpad bug 1733692 in Evergreen "Hatch Windows installer doesn't follow best practices" [High,New] https://launchpad.net/bugs/1733692 |
| 14:47 |
pinesol_green |
Launchpad bug 1708757 in Evergreen "Publish Hatch to Chrome web store" [Wishlist,New] https://launchpad.net/bugs/1708757 - Assigned to Galen Charlton (gmc) |
| 14:49 |
csharp |
I see - looks like we're just waiting on signoffs of bug 1708757 |
| 16:04 |
jeff |
alas, this is neither bash nor vim. |
| 16:11 |
|
rlefaive joined #evergreen |
| 16:42 |
csharp |
jeff++ |
| 18:31 |
pinesol_green |
News from qatests: Test Success <http://testing.evergreen-ils.org/~live> |
| 18:54 |
|
jvwoolf joined #evergreen |
| 19:09 |
|
jvwoolf joined #evergreen |
| 06:31 |
pinesol_green |
News from qatests: Test Success <http://testing.evergreen-ils.org/~live> |
| 07:08 |
|
rjackson_isl joined #evergreen |
| 07:09 |
|
agoben joined #evergreen |
| 07:37 |
|
dwgreen joined #evergreen |
| 13:25 |
pinesol_green |
Launchpad bug 1730752 in Evergreen "Webstaff option to show/hide multiple grid columns" [Undecided,New] https://launchpad.net/bugs/1730752 |
| 13:42 |
Dyrcona |
Is there a way to get the title of a bib record out of the database in title case without doing oils_xslt_process and oils_xpath_string? |
| 13:42 |
Dyrcona |
If I join with reporter.materialized_simple_record the title is normalized to lower case. |
| 13:43 |
Dyrcona |
And, if I try the oils_xslt_process and oils_xpatch_string method on all of the records in one query, I crash my test db server. :) |
| 13:45 |
csharp |
Dyrcona: depending on the need, you can also use initcap() which will capitalize the first letter in every word (not perfect and not preserving the original case, but maybe better?) |
| 13:45 |
Dyrcona |
Well, it's a dump for Novelist On-the-Shelf. |
| 13:46 |
csharp |
ah' |
| 16:58 |
mmorgan |
So seems like something is different with a new build vs upgrade? |
| 16:58 |
kmlussier |
I think I linked to the log in that bug. |
| 16:59 |
mmorgan |
Indeed you did! |
| 17:00 |
* kmlussier |
hasn't tested miker's patch for that issue yet. |
| 17:01 |
kmlussier |
mmorgan: But the upgrade vs. new build difference makes sense to me. It would explain why you didn't originally see the problem on the upgraded system until you added a new record with a Located URI, while I saw the problem with all the records on my newly-built system. |
| 17:04 |
* mmorgan |
is heading home, but is sure to have dreams about this bug :-( |
| 17:05 |
|
mmorgan left #evergreen |
| 17:22 |
|
kmlussier joined #evergreen |
| 17:28 |
|
kmlussier joined #evergreen |
| 17:41 |
|
mllewellyn left #evergreen |
| 18:32 |
pinesol_green |
News from qatests: Test Success <http://testing.evergreen-ils.org/~live> |
| 21:36 |
|
mnsri joined #evergreen |
| 21:36 |
|
rashma joined #evergreen |
| 22:55 |
|
Christineb joined #evergreen |
| 03:44 |
|
sard joined #evergreen |
| 06:32 |
pinesol_green |
News from qatests: Test Success <http://testing.evergreen-ils.org/~live> |
| 07:14 |
|
rjackson_isl joined #evergreen |
| 07:45 |
|
dwgreen joined #evergreen |
| 08:35 |
|
mmorgan joined #evergreen |
| 15:37 |
|
bshum joined #evergreen |
| 15:40 |
|
phasefx joined #evergreen |
| 15:45 |
|
RBecker joined #evergreen |
| 15:55 |
jeffdavis |
I'm puzzled that the fix for bug 1736419/1730758 is working for others but not on my test system |
| 15:55 |
pinesol_green |
Launchpad bug 1736419 in Evergreen "Search Showing Bibs with no Holdings" [High,Confirmed] https://launchpad.net/bugs/1736419 |
| 15:56 |
* mmorgan |
is puzzled about that, too. |
| 15:59 |
jeffdavis |
https://upstream.catalogue.libraries.coop/eg/opac/record/249 is a record with a located URI at BR1, but the record doesn't show up in a catalog search on that server. |
| 16:04 |
jeffdavis |
mmorgan: hmm, for records with located URIs and no holdings I only have very small values in vis_attr_vector - e.g. the record above has {4} in there which is the actor.org_unit.id of the located URI location |
| 16:06 |
mmorgan |
jeffdavis: Yes, I see similar for most records with located uris and no holdings, but some also show, for example: {268435571,74} |
| 16:07 |
kmlussier |
jeffdavis / mmorgan: Before the fix was even added, I was puzzled that people saw different behavior in the original bug report. |
| 16:08 |
mmorgan |
jeffdavis: is your test system a fresh install of 3.0? |
| 16:08 |
mmorgan |
Ours is an upgrade. |
| 16:10 |
jeffdavis |
Ours a fresh 3.0.2 install with concerto data. |
| 16:12 |
jeffdavis |
kmlussier: yeah, good point |
| 16:17 |
kmlussier |
mmorgan: And you don't see a difference between new Located URI records and ones that were there before the upgrade? |
| 16:36 |
Dyrcona |
No, you're talking about cat.maintain_control_numbers, me thinks. |
| 16:36 |
mmorgan |
kmlussier, jeffdavis: I can retrieve my newly created record in the opac. The link is not showing at the cons level, but the record is retrieved in a search. |
| 16:36 |
Dyrcona |
Or, rather, I think the flag you mentioned affects the behavior of both. |
| 16:38 |
kmlussier |
mmorgan: The link isn't displaying at the cons level? That's strange. In the previous testing, the problem only seemed to affect what was retrieved in searches, not the link display. |
| 16:39 |
mmorgan |
Yes, I hadn't noticed that before. |
| 16:40 |
* csharp |
confirms that OCLC libraries set cat.bib.use_id_for_tcn = false |
| 16:40 |
Dyrcona |
I think you've confirmed that an OCLC library/consortium sets it to false. |
| 17:15 |
miker |
jeffdavis: -^ |
| 17:35 |
jeffdavis |
Ah, ok. Bib source is null for all records on a default install apparently. (Adding a source added a large-number entry to vis_attr_vector, but records with luris still don't show in public search results for me, fwiw.) |
| 17:58 |
|
jvwoolf1 left #evergreen |
| 18:32 |
pinesol_green |
News from qatests: Test Success <http://testing.evergreen-ils.org/~live> |
| 21:05 |
|
Jillianne joined #evergreen |
| 00:34 |
|
beanjammin joined #evergreen |
| 06:30 |
pinesol_green |
News from qatests: Test Success <http://testing.evergreen-ils.org/~live> |
| 07:01 |
|
JBoyer joined #evergreen |
| 07:17 |
|
rjackson_isl joined #evergreen |
| 07:21 |
|
agoben joined #evergreen |
| 13:28 |
JBoyer |
Nothing useful in the browser console? (there certainly isn't in Firefox when I'm trying to see what's what there. :/ ) |
| 13:28 |
Dyrcona |
By that I mean, if you specify 3 directories, it looks in the last, then the middle, then the first, right? |
| 13:28 |
JBoyer |
Dyrcona, My understanding is that you're right though I haven't tried it. |
| 13:29 |
Dyrcona |
JBoyer: That's what I think, and I'm about to test it, maybe. :) |
| 13:29 |
JBoyer |
Dyrcona++ |
| 13:31 |
Dyrcona |
I can test it in training.. |
| 13:44 |
Dyrcona |
Bleh. Training is behind, or at least we've made many changes to our customizations since I last updated training. I have 13 files with conflicts. |
| 13:55 |
|
khuckins_ joined #evergreen |
| 14:01 |
Dyrcona |
JBoyer: I'm not having any luck, but it looks like my training configuration is kind of messed up. |
| 15:21 |
csharp |
JBoyer: it's pretty great |
| 15:22 |
Dyrcona |
@dunno |
| 15:22 |
pinesol_green |
Dyrcona: Fire BAD! Reading GOOD! |
| 15:22 |
csharp |
@blame add $who tests their code on the LIVE SERVERS, then blames the user. SAD! |
| 15:22 |
pinesol_green |
csharp: The operation succeeded. Blame #29 added. |
| 15:24 |
Dyrcona |
@who loves [band] |
| 15:24 |
pinesol_green |
bwicksall loves C-Sharp and The Servers. |
| 17:37 |
berick |
Bmagic: familar with process of opening the extension console? similarly, ~/.evergreen/hatch.log* may have something useful. |
| 17:37 |
|
gsams joined #evergreen |
| 17:38 |
Bmagic |
berick: yeah, I think I will have to setup a screen sharing session with him and get some of those details. Glad to hear that folks have it working. Lets me know that it should* work |
| 17:39 |
berick |
Bmagic: to be clear, it sounds your user has clocked more time than I did using Hatch on OSX. I just did basic function tests. |
| 17:40 |
Bmagic |
berick: thanks! |
| 17:40 |
berick |
they may be in rarefied air |
| 18:30 |
pinesol_green |
News from qatests: Test Success <http://testing.evergreen-ils.org/~live> |
| 18:57 |
|
ejk joined #evergreen |
| 19:00 |
|
bshum joined #evergreen |
| 19:01 |
|
eby joined #evergreen |
| 01:23 |
|
abowling joined #evergreen |
| 01:29 |
|
beanjammin joined #evergreen |
| 04:12 |
|
yar joined #evergreen |
| 06:31 |
pinesol_green |
News from qatests: Test Success <http://testing.evergreen-ils.org/~live> |
| 07:10 |
|
rjackson_isl joined #evergreen |
| 08:45 |
|
mmorgan joined #evergreen |
| 08:48 |
|
littlet joined #evergreen |
| 08:58 |
|
bos20k joined #evergreen |
| 09:01 |
|
kmlussier joined #evergreen |
| 09:04 |
|
yboston joined #evergreen |
| 09:16 |
csharp |
so my takeaway from the hatch discussion from yesterday is we need to merge in JBoyer's and berick's branches to Hatch master - is that right? |
| 09:16 |
* csharp |
is happy to test and signoff wherever would help |
| 09:16 |
csharp |
our testers are hitting the WSOD issue a lot now |
| 09:16 |
* csharp |
saw it himself last week |
| 09:19 |
kmlussier |
csharp: When does it come up? |
| 09:20 |
csharp |
for me it was after installing hatch after running the web client without hatch |
| 09:21 |
miker |
csharp: did you tell it to use hatch for storage? I believe the word is, now, "don't do that, only printing" |
| 10:07 |
berick |
does clearing the cache, etc. wipe out the indexdb too? |
| 10:09 |
csharp |
kmlussier: I think the storage options should be at the very least greyed out if they're going to break things |
| 10:10 |
Dyrcona |
Clear browsing data on Chromium gives a list of things to clear with check boxes. |
| 10:11 |
kmlussier |
We tested this at the hack-a-way, I think. IIRC, clearing the cookies would also clear local storage. I'm not sure about indexdb. |
| 10:11 |
csharp |
also, it's almost certainly my own fault for tuning out, but I was in the dark about Hatch not being used for storage - I thought that was the point (or *a* point) of it |
| 10:11 |
kmlussier |
My preference would be to fix the hatch storage issue. |
| 10:11 |
csharp |
I think Terran did see that it at least unlinked the DB from the instance so even if it doesn't blow away data it's no longer functional |
| 10:30 |
csharp |
I see - then let me work with that one then report back |
| 10:30 |
berick |
csharp++ |
| 10:31 |
csharp |
also, need to find a windows (v)box somewhere |
| 10:31 |
berick |
what have you been testing on? |
| 10:31 |
csharp |
this was Ubuntu 17.10 |
| 10:31 |
berick |
ohhh |
| 10:31 |
berick |
didn't realize |
| 12:11 |
Dyrcona |
But, when I had just OpenSRF installed opensrf.math worked just fine. |
| 12:15 |
Dyrcona |
Umm... I thought master installed the libraries correctly as lib.... Apparently that didn't happen for me. |
| 12:16 |
Dyrcona |
Ok. Never mind, my checkout was behind current master by quite a bit. :) |
| 12:52 |
jeffdavis |
I'm seeing a weird thing on a test server where OPAC iframes within the web client fail to load with a "too many redirects" error - but only in Chrome. If I open dev tools and check "Disable cache" it works fine. |
| 12:54 |
jeffdavis |
The iframes also work fine if I use a subdomain to connect (foo.example.com) but the main domain (example.com) always fails. |
| 12:55 |
jeffdavis |
It seems like I'm getting a redirect loop somehow, so going to Catalog > Search the Catalog does 'GET /eg/opac/advanced' but the server responds with a redirect to /eg/opac/advanced, ad infinitum. |
| 12:57 |
jeffdavis |
I can load /eg/opac/advanced just fine outside the web client. |
| 13:03 |
berick |
jeffdavis: using nginx? |
| 13:03 |
jeffdavis |
yeah |
| 13:04 |
jeffdavis |
I'm going to try without the proxy and see if it makes a difference |
| 17:05 |
miker |
I was thinking of https://bugs.launchpad.net/evergreen/+bug/1723977 |
| 17:05 |
pinesol_green` |
Launchpad bug 1723977 in Evergreen "Searching specific location in Advanced Search not limiting correctly in 3.0" [Medium,Fix released] |
| 17:06 |
|
mmorgan left #evergreen |
| 17:06 |
kmlussier |
miker: OK. The testing I did for bug 1736419 was on a recent master system that should already have that fix on it. |
| 17:07 |
pinesol_green` |
Launchpad bug 1736419 in Evergreen "Search Showing Bibs with no Holdings" [High,Confirmed] https://launchpad.net/bugs/1736419 |
| 17:07 |
jeffdavis |
likewise, I'm still seeing the luri issue on a 3.0.2 server |
| 17:07 |
miker |
kk, so it's something else |
| 17:13 |
miker |
kmlussier: that suggests you have a NULL bre.v_a_v, as that's how staff search would look at that situation |
| 17:13 |
miker |
good news is, the upgrade script to correct the data should be very targetted and not too painful in terms of run time |
| 17:14 |
kmlussier |
miker: Well, whatever day it gets fixed will be tomorrow on whatever day precedes it. :) |
| 17:16 |
jeffdavis |
I have a test server where a record with located URIs and non-null vis_attr_vector doesn't show in OPAC search. |
| 17:16 |
jeffdavis |
That server has some customizations though, I'll see if I can confirm on a server running vanilla EG. |
| 17:17 |
miker |
jeffdavis: thanks |
| 17:17 |
kmlussier |
miker: I'm seeing null in that field for my two test records. |
| 17:17 |
miker |
kmlussier: good, that's helpful. thanks |
| 17:19 |
kmlussier |
I'll make a comment on bug 173641. I don't think I'll mark it as a duplicate yet since the behavior rjackson described for public catalog searches is a little different. |
| 17:19 |
kmlussier |
Wrong bug number. You all know what I meant. |
| 17:19 |
miker |
kk, thanks |
| 17:25 |
miker |
ah... I think I see it. it'll be at least tomorrow for a fix, though |
| 18:31 |
pinesol_green |
News from qatests: Test Success <http://testing.evergreen-ils.org/~live> |
| 20:10 |
|
beanjammin joined #evergreen |
| 20:11 |
|
Dyrcona joined #evergreen |
| 20:11 |
Dyrcona |
I know no one is likely to be around, but here goes. |
| 01:39 |
|
RBecker joined #evergreen |
| 02:18 |
|
beanjammin joined #evergreen |
| 03:04 |
|
JBoyer_alt_bin joined #evergreen |
| 06:30 |
pinesol_green |
News from qatests: Test Success <http://testing.evergreen-ils.org/~live> |
| 07:03 |
|
rjackson_isl joined #evergreen |
| 07:04 |
|
JBoyer joined #evergreen |
| 07:29 |
|
agoben joined #evergreen |
| 09:33 |
jeff |
Bmagic: yep, that's expected with that command. what were you trying to do? |
| 09:54 |
stephengwills |
is there a common patron records problem one can look for when really_delete_user fails with a 500 error? |
| 09:56 |
Dyrcona |
Not that I'm aware of. The Apache error log is often useful in the event of a 500 error. |
| 09:57 |
Dyrcona |
I got one on a test server this morning that included enough of the Perl error for me to track it down, for example. |
| 09:58 |
stephengwills |
ok thanks. will dig deeper. |
| 09:58 |
Dyrcona |
Sometimes, that information isn't there, unfortunately. |
| 10:01 |
mmorgan |
Our OverDrive login activity type is working! We've recorded almost 30 logins in the first hour. |
| 12:08 |
Dyrcona |
It's a lot faster than pg_restore. |
| 12:09 |
Dyrcona |
But, if you're renaming the db, and you don't have the db already on the server, you have to create an empty db to restore into. |
| 12:11 |
* jeff |
nods |
| 12:12 |
bshum |
Bmagic: re: web client, I recently tested the 2.12.8 tarball and that seemed fine to log in without any errors, same for recent master for me |
| 12:12 |
bshum |
Which version are we talking about on your end of things? |
| 12:13 |
Bmagic |
bshum: it's weird - doesn't happen right away. Seems like its some FF stale cookies or something. Happens on Chrome too. Incognito window "fixes" it sometimes, but still weird |
| 12:13 |
bshum |
Version of EG and Linux distro too |
| 12:13 |
Dyrcona |
Adding on to my last statement, I usually just do a create database statement from psql and don't bother with the create db script these days. |
| 12:58 |
bshum |
sandbergja: I think kmlussier pointed that out to me and asked awhile back |
| 12:58 |
bshum |
Fixing the typo in the .pot and .po files is not a bad thing |
| 12:59 |
Dyrcona |
sandbergja: You generally don't need to fix the .pot and .po files though. They are generated are release time. |
| 12:59 |
bshum |
What'll happen is that the next import from git to LP will update the relevant template strings out there |
| 13:00 |
bshum |
At release time, if the string is already changed in git, it'll just get skipped over by the i18n sync process |
| 13:00 |
bshum |
I'm in favor of git changes like this so that it's easier for folk to install / test with |
| 13:00 |
bshum |
Rather than waiting or learning the i18n dance |
| 13:00 |
bshum |
But I'm okay with it either way |
| 13:00 |
Dyrcona |
I'll defer to bshum on that point, then. :) |
| 13:01 |
sandbergja |
That's helpful -- thanks. |
| 13:01 |
bshum |
For typos, I think it's fine |
| 17:09 |
berick |
change the path to suit |
| 17:11 |
berick |
find ~/ -name org.evergreen_ils.hatch.json |
| 17:12 |
Bmagic |
thanks! |
| 18:31 |
pinesol_green |
News from qatests: Test Success <http://testing.evergreen-ils.org/~live> |
| 22:02 |
|
jvwoolf joined #evergreen |
| 22:25 |
|
jvwoolf left #evergreen |
| 23:00 |
|
Stompro joined #evergreen |
| 00:29 |
|
dbwells_ joined #evergreen |
| 06:32 |
pinesol_green |
News from qatests: Test Success <http://testing.evergreen-ils.org/~live> |
| 06:57 |
|
JBoyer joined #evergreen |
| 07:18 |
|
rjackson_isl joined #evergreen |
| 07:30 |
|
agoben joined #evergreen |
| 16:11 |
bshum |
kmlussier: Possibly. |
| 16:11 |
bshum |
Not sure if that's the real problem or not based on your errors you saw |
| 16:11 |
* kmlussier |
can try it locally to see if it fixes her issue. |
| 16:13 |
bshum |
And I'm not 100% sure what'll happen if you have both nodejs legacy and then install the nodejs binary |
| 16:13 |
bshum |
If it'll just figure out to use the newer one, or if it'll be unhappy till you remove nodejs legacy |
| 16:13 |
bshum |
I vaguely recall testing that out |
| 16:13 |
bshum |
but it's been awhile.. |
| 16:14 |
jeff |
Bmagic: can you please name the functions in question? |
| 16:14 |
jeff |
Bmagic: my first thought is that you may be running into bug 1671150 |
| 16:14 |
pinesol_green |
Launchpad bug 1671150 in Evergreen "Unqualified references in evergreen.unaccent_and_squash lead to index creation failures with pg_restore" [Medium,Fix committed] https://launchpad.net/bugs/1671150 |
| 16:28 |
jeff |
or attempting to. |
| 16:29 |
Bmagic |
it is the same db name |
| 16:29 |
Bmagic |
the very tippy top error is complaining about the db already existing, but that is OK because I think I created it just fine |
| 16:30 |
jeff |
the behavior in that case is not defined in the manpage. (-C without --clean where the database name in the dump file already exists in the cluster). I haven't tested to see what the actual behavior is. Were you able to share the \dL and \dx output of the database you're attempting to restore into? |
| 16:30 |
Bmagic |
that went away when I removed -C |
| 16:30 |
jeff |
okay. i still recommend getting out of the habit of using -C, but it sounds like it was not the cause of your issue. |
| 16:31 |
pastebot |
"Bmagic" at 64.57.241.14 pasted "\dL \dx" (22 lines) at http://paste.evergreen-ils.org/948 |
| 16:45 |
Bmagic |
I thought of search path too |
| 16:46 |
jeff |
changing your CREATE EXTENSION for intarray to this might be needed in this case: CREATE EXTENSION intarray WITH SCHEMA evergreen; |
| 16:46 |
jeff |
is the source database available for you to query? |
| 16:48 |
Bmagic |
weird. I can't find the example of query_int in any of my other test machines |
| 16:48 |
Bmagic |
only query_int_wrapper |
| 16:48 |
jeff |
it would be a type, not a function. |
| 16:48 |
jeff |
\dT |
| 17:32 |
Bmagic |
sorry khuckins__ - I have not |
| 18:10 |
|
jvwoolf joined #evergreen |
| 18:11 |
|
JBoyer_alt joined #evergreen |
| 18:30 |
pinesol_green |
News from qatests: Test Success <http://testing.evergreen-ils.org/~live> |
| 19:02 |
|
beanjammin joined #evergreen |
| 19:04 |
beanjammin |
khuckins: You were asking about conditionally adding classes to grid fields? I just finished doing a little bit of that. |
| 19:06 |
khuckins |
beanjammin: Yeah, I've been wracking my brain a bit, specifically trying to make a few glyphicons show up in a field depending on certain values in the item |
| 06:31 |
pinesol_green |
News from qatests: Test Success <http://testing.evergreen-ils.org/~live> |
| 07:08 |
|
rjackson_isl joined #evergreen |
| 07:48 |
|
kmlussier joined #evergreen |
| 07:48 |
|
rlefaive joined #evergreen |
| 10:31 |
ejk |
I guess I'll have to make one OpenSRF call after all. =) |
| 10:33 |
ejk |
Thanks again. How did it get to be December already? ... |
| 10:33 |
ejk |
miker++ jeff++ |
| 10:36 |
Dyrcona |
Bmagic: I just tested an upgrade from 2.12.6 to 2.12.8 using your working tag branch for rel_2_12_8 and it works fine. Should we push that to the main repo? |
| 10:37 |
Bmagic |
Dyrcona: I think that's fine, I was just in the middle of testing the tarball myself |
| 10:37 |
Dyrcona |
OK. It can wait a bit longer while you test. |
| 10:37 |
Bmagic |
gmcharlt might be in bed as a "sick pumpkin" - otherwise, he usually does that |
| 10:37 |
Dyrcona |
I'll be doing this upgrade for real next Wednesday. |
| 10:38 |
Dyrcona |
:) |
| 10:38 |
Dyrcona |
Well, :( rather |
| 10:53 |
Bmagic |
Dyrcona: tarball successful. OPAC running, staff client logged in, with concerto. Did not test DB upgrade though |
| 10:54 |
Dyrcona |
Bmagic: Cool! I tested the db upgrades for 2.12.6 to 2.12.7 and 2.12.7 to 2.12.8, and they work for me. |
| 10:54 |
Bmagic |
I think we might be gold |
| 10:54 |
Dyrcona |
I've been kicking the tires and taking it around the block. |
| 10:55 |
Dyrcona |
Yeah. I'll push the branch to the main repository. |
| 12:01 |
|
khuckins joined #evergreen |
| 12:05 |
berick |
csharp: can you clarify, the problem is the Owning Library column does not have enough space? |
| 12:05 |
csharp |
berick: right |
| 12:05 |
berick |
and if you hide other columns (to test) it does eventually show the full names? |
| 12:05 |
csharp |
let me see |
| 12:05 |
berick |
and/or resize the columns via the configurator |
| 12:07 |
csharp |
berick: the full names are visible if there's room, yes - looking at resizing now |
| 12:10 |
berick |
don't forget to "Save Columns" once you have it where you want. |
| 12:12 |
berick |
csharp: if you want to further improve the grid mgmt experience: bug #1730752 :) |
| 12:12 |
pinesol_green |
Launchpad bug 1730752 in Evergreen "Webstaff option to show/hide multiple grid columns" [Undecided,New] https://launchpad.net/bugs/1730752 |
| 12:16 |
csharp |
berick++ # will test |
| 12:17 |
csharp |
apparently our catalogers are unyielding about needing enough columns that the display isn't wide enough :-/ |
| 12:17 |
* csharp |
seethes a little |
| 12:23 |
kmlussier |
Bmagic / Dyrcona: I saw you all talking about the release earlier, but has the tarball uploaded to the server yet? If so, I can put on gmcharlt's hat for the day and upload the downloads page, do announcements, etc. |
| 12:24 |
pastebot |
"berick" at 64.57.241.14 pasted "for csharp if needed -- use shortname" (12 lines) at http://paste.evergreen-ils.org/946 |
| 12:24 |
kmlussier |
No, it doesn't look like the tarball is available or, if it is, I'm not using the correct URL. |
| 15:34 |
csharp |
kmlussier: according to Elaine here, she could delete bucket items but not copy notes |
| 15:34 |
csharp |
after applying the DB scripts |
| 15:34 |
csharp |
I haven't looked into yet, though |
| 15:34 |
kmlussier |
csharp: Yeah, I just tested it. I see it too. Adding a comment to the bug. |
| 15:35 |
csharp |
@blame too many frickin' issues |
| 15:35 |
pinesol_green |
csharp: I know it was you, too many frickin' issues. You broke csharp's heart. You broke csharp's heart. |
| 15:56 |
Bmagic |
Dyrcona kmlussier - it looks like the git repo does not have tags/rel_3_0_2 ? |
| 17:23 |
kmlussier |
Bmagic: Of course, it's easy enough to remove from the slip locally, but I'm always in favor of setting a good example. |
| 17:23 |
Bmagic |
do you know if there is a bug already out there along those lines? |
| 17:34 |
Bmagic |
bug 1735847 |
| 17:34 |
pinesol_green |
Launchpad bug 1735847 in Evergreen "Default hold transit slip should not include patron information" [Undecided,New] https://launchpad.net/bugs/1735847 |
| 18:32 |
pinesol_green |
News from qatests: Test Success <http://testing.evergreen-ils.org/~live> |
