| 05:37 |
|
JBoyer joined #evergreen |
| 06:00 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 07:41 |
|
collum joined #evergreen |
| 07:50 |
|
mantis joined #evergreen |
| 08:33 |
|
mmorgan joined #evergreen |
| 10:34 |
* Dyrcona |
ponders fixing the 856 by moving subfield 3 in front of the others instead of being at the end. |
| 11:16 |
mantis |
Weird thing. I noticed when using Angular, I get a weird rollover effect when trying to place an Item Hold that prevents me from clicking the option in Chrome. But in Firefox it's fine. Has anyone else noticed this? |
| 11:26 |
Dyrcona |
Hrm.. "Not an array reference..." |
| 11:37 |
Dyrcona |
mantis: I haven't seen that, but I hardly ever use the staff client, only when testing something specific. |
| 11:48 |
mmorgan1 |
mantis: I'm not seeing the same thing. Are you looking at the full record in the staff catalog? |
| 11:53 |
jeff |
mantis: I'm pretty sure it's a Chrome bug. We just had a report of exactly that today. |
| 11:54 |
jeff |
Chrome 99 on Windows exhibits the problem. Chrome 98 on macOS does not. |
| 11:54 |
jeff |
I haven't found a Chrome bug/issue for it yet. |
| 11:55 |
jeff |
one quick workaround for placing an item/copy level hold from that point is to select the "view" option to bring the copy up in Item Status, and then use the "Request" feature to place the copy hold. |
| 11:56 |
jeff |
(not a suitable workaround in all scenarios, but useful in many) |
| 12:03 |
jeff |
none of the current Chrome release channels on macOS include Chrome 99.x. I suspect it's currently on a phased release as the main channel. |
| 12:04 |
jeff |
I'm going to test more on Windows, to see if it's OS specific or just Chrome 99. |
| 12:14 |
|
jihpringle joined #evergreen |
| 12:17 |
jeff |
hah! vendor stated that they had a document that went into detail about how their product uses SIP2. We asked for a copy, they sent us the 2006 3M SIP 2.0 protocol specification document. |
| 12:19 |
mantis |
jeff++ |
| 12:19 |
JBoyer |
jeff, hah, reminds me of those self-certifying sip implementations. "What parts of the standard do you support?" "Oh, all of them. (As far as you or we know.)" |
| 12:29 |
jeff |
When talking (or joking) about idiosyncrasies of the SIP2 protocol, I can never decide if I want to go the Emo Philips route or the Monty Python route. |
| 15:06 |
pinesol |
Launchpad bug 1910452 in Evergreen 3.6 "Angular Catalog: Search links and Added Content" [Undecided,Fix released] https://launchpad.net/bugs/1910452 |
| 15:07 |
jihpringle |
mmorgan: we're on 3.7.0 so the links in Patron View don't work for us and placing holds via the traditional catalogue always uses the staff account contact details |
| 15:09 |
jihpringle |
I'm really looking forward to our next upgrade when we get all the awesome catalogue fixes that came in 3.7.2 |
| 15:13 |
mmorgan |
jihpringle: Oh right! We've also applied bug 1939426, which grabs the user prefs. Haven't tested it rigorously enough to sign off yet, though. |
| 15:13 |
pinesol |
Launchpad bug 1939426 in Evergreen "Placing holds as staff in traditional catalog in 3.7 doesn't always load user settings" [Undecided,Confirmed] https://launchpad.net/bugs/1939426 |
| 15:15 |
Dyrcona |
mmorgan: Are you using it in production? |
| 15:17 |
Dyrcona |
If you've been using a patch in production for a while and no one has complained, that's pretty thorough testing. :) |
| 15:17 |
mmorgan |
Dyrcona: We are, but we are still having some issues with the screen. |
| 15:18 |
mmorgan |
Agreed, putting in production = thorough testing :) |
| 15:21 |
* mmorgan |
will take another look and try and add a signoff this afternoon. |
| 16:13 |
jeff |
in Chrome 99, offsetWidth and offsetHeight on the eg-grid-body-cell element returns 0. |
| 16:13 |
jeff |
(but only in that one column -- "Holdable?") |
| 16:46 |
jeff |
looks like placing <div>hello<//div> in an <ev-grid-body-cell> causes the eg-grid-body-cell to have offsetHeight 0 |
| 17:17 |
jeff |
confirmed Version 99.0.4844.51 (Official Build) (arm64) |
| 17:17 |
jeff |
(as affected) |
| 17:18 |
jeff |
on macOS |
| 18:00 |
pinesol |
News from qatests: Failed Installing Angular web client <http://testing.evergreen-ils.org/~live//archive/2022-03/2022-03-04_16:00:02/test.29.html> |
| 22:22 |
|
JBoyer joined #evergreen |
| 02:24 |
|
JBoyer joined #evergreen |
| 06:00 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 07:13 |
|
rjackson_isl_hom joined #evergreen |
| 07:49 |
|
collum joined #evergreen |
| 08:01 |
|
rjackson_isl_hom joined #evergreen |
| 12:58 |
Dyrcona |
Also, I had to rm <other file>.orig 'cause I forgot to say no backups to patch. |
| 12:59 |
Dyrcona |
Admittedly, it's of limited utility, but I have a use case where file b started as a copy of file a. I made an edit to file b that I wanted to put in file a, and I was feeling lazy and figured that git diff trick would work, so I tried it. |
| 13:01 |
* jeff |
nods |
| 13:02 |
Dyrcona |
Also, I'm tempted to put in another patch that I tested. I hesitate because it accesses a Perl object's internals, and it could break in a future release of the Perl package, though I doubt it. |
| 13:06 |
Dyrcona |
@praise Encapsulation |
| 13:06 |
* pinesol |
Encapsulation LOVES the RESISTANCE! |
| 13:31 |
dluch |
Reminder: DIG Meeting starts in 30 minutes! |
| 14:37 |
abneiman |
the process I followed is from Jane & I think it's documented though |
| 14:37 |
mantis |
should we reply to announcement emails with branches ready to go prior to the meeting? |
| 14:37 |
dluch |
csharp, thanks! |
| 14:38 |
abneiman |
well, I thought we were going to try to pivot to github commits (I do git command line right now) so we can take advantage of the new build-testing plugin |
| 14:38 |
abneiman |
that's what I'm supposed to teach myself this month before I talk to y'all about it in April :) |
| 14:38 |
dluch |
Correct (I think) |
| 14:38 |
dluch |
:-) |
| 14:39 |
mantis |
I see |
| 15:58 |
Dyrcona |
Anyone know off the top their head what happens if you check in a claims returned item? |
| 16:11 |
jihpringle |
I think it depends on your library settings |
| 16:12 |
Dyrcona |
<John_Cleese>Naturellement.</John_Cleese> |
| 16:12 |
* Dyrcona |
thinks he'll just try it on a test database next week and see what happens. :) |
| 16:13 |
Dyrcona |
jihpringle++ |
| 16:15 |
Dyrcona |
I'm likely to be asked to checkin and delete a bunch of old clams returned items. |
| 16:15 |
jihpringle |
Dyrcona: the item gets checked in (with an item alert to tell you it was claimed returned) and goes to reshelving and then bills may be voided depending on your library settings (at least that's what happens on our test server) |
| 16:15 |
Dyrcona |
Maybe I should share this program. I have one that will checkin and delete copies from a spreadsheet. |
| 16:16 |
Dyrcona |
jihpringle: Thanks for looking. |
| 16:16 |
Dyrcona |
I suspect it might do the same here. |
| 16:19 |
Dyrcona |
My suspicion is it will work on claims returned just as well as it works on lost, long overdue, and missing. |
| 16:24 |
Dyrcona |
Well, it's about that time. I'll catch everyone again tomorrow! |
| 17:05 |
|
mmorgan left #evergreen |
| 18:00 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 19:47 |
|
jvwoolf joined #evergreen |
| 20:01 |
|
jvwoolf left #evergreen |
| 20:28 |
|
Guest30 joined #evergreen |
| 06:00 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 06:15 |
|
JBoyer joined #evergreen |
| 07:14 |
|
rjackson_isl_hom joined #evergreen |
| 07:40 |
|
collum joined #evergreen |
| 11:08 |
miker |
hrm... that's strange ... could the records be claiming MARC8? IIRC we do look at the leader, but I think there's a way to force the issue |
| 11:09 |
Dyrcona |
Ah, wait a minute. The records don't seem to say that they're UTF-8.... |
| 11:09 |
Dyrcona |
vendor-records-- |
| 11:10 |
Dyrcona |
I'll have to test this... again.... I have a prep script that can set the encoding, I saw 'a' in the leader and thought I didn't have to, but after counting, that 'a' isn't the 'a' that I want. :) |
| 11:14 |
Dyrcona |
I'm going to see what these problem records look like in the database before I do anything else. |
| 11:16 |
Dyrcona |
One of them has different characters for the first letter of the author's last name in different fields. It's \xC3\x85 in one field and \xC3\x81 in another.... |
| 11:18 |
Dyrcona |
245$c on that record is empty in the database, but has the author's name in the input. It's the one with \xC3\x85. |
| 11:35 |
Dyrcona |
I've found all kinds of crap in MARC from 3rd parties. |
| 11:36 |
miker |
right on. fwiw, many of our scripts and db functions use both assume_unicode(1) and ignore_errors(1). see the top part of Open-ILS/src/extras/import/marc_add_ids for instance |
| 11:38 |
Dyrcona |
Well, I've set the 09 in the leader to 'a' for this batch. When I open the file in Emacs it looks like UTF-8. |
| 11:39 |
Dyrcona |
I'm running it again in another db with a fresh copy of production. I reloaded them after yesterday's tests. |
| 11:40 |
jeff |
the last time I looked at pymarc was years ago, and I thought that there were a few broken things about it, especially with regard to encoding. |
| 11:40 |
Dyrcona |
jeff: I don't recall if I actually used it. I may just perused the repo or something like that. |
| 11:41 |
jeff |
It may have gotten better since then, or I may have been mistaken. I only remember that I had issues with a large set of changes that had recently gone into it, but don't recall more than that offhand. |
| 11:59 |
Dyrcona |
Yeah, it has passed the author with the different characters for the first letter of the last name with no warnings or errors. |
| 12:03 |
|
jihpringle joined #evergreen |
| 12:12 |
Dyrcona |
Well, there's "stuff" in the author's name in the database. I'm not sure it's correct. |
| 12:28 |
Dyrcona |
Looks good in my test catalog, so... I guess I'll load these into production. |
| 12:29 |
Dyrcona |
multiple-test-environments++ |
| 13:07 |
mantis |
Does anyone have suggestions for software that locks browsers into a kiosk mode for OPAC use? We used OpenKiosk for a while but it's causing a lot of white screening and timeouts on Linux OS. |
| 13:28 |
berick |
mantis: have you tried the kiosk mode options baked into most browsers? |
| 13:31 |
jeff |
I've heard good things about webconverger in the past, but it seems that they haven't updated in a while. We used to use OpenKiosk, but now I think we use Chrome/Chromium with a browser plugin called from a pruned-down xinitrc or the equivalent on some little linux boxes. |
| 13:32 |
jeff |
Biggest issue (other than it being somewhat cobbled together) is that the image doesn't do much to avoid writes, so the microSD cards tend to wear out often. |
| 13:33 |
jeff |
I don't think Chrome, Edge, or Firefox have stock "kiosk" mode options that would be suitable for an OPAC. Chrome OS does have a kiosk mode that you might look into, though. |
| 13:33 |
jeff |
It will likely require a management license for the Chrome OS device. |
| 13:45 |
mantis |
berick++ |
| 13:45 |
mantis |
jeff++ |
| 13:45 |
mantis |
thanks for the suggestions; I'm mostly speaking on behalf of our network services |
| 13:45 |
mantis |
I think they did try at one point using the Kiosk setting in Firefox but they liked OpenKiosk because it really locks the browser down |
| 13:46 |
mantis |
unrelated but where in the Boopac is the search courses module? This is my first time testing it |
| 13:49 |
Dyrcona |
So, why does "identical" css produce different results on different servers in the same browser? I seem to have a discrepancy between my devleopment VM and my training server, and git tells me the relevant files are the same.... |
| 13:51 |
|
JBoyer joined #evergreen |
| 13:53 |
Dyrcona |
I even emptied cache and hard reloaded..... |
| 16:47 |
Dyrcona |
JBoyer++ |
| 16:47 |
Dyrcona |
Yeah, that's what a narrows is. |
| 16:47 |
Dyrcona |
narrows are? is? I'm not gonna bother looking it up. |
| 16:58 |
pinesol |
News from commits: LP#1955931 Staff catalog show more details - add due date <https://git.evergreen-ils.org/?p=Evergreen.git;a=commitdiff;h=4e6fe743271992347686a113c390b208c162942b> |
| 17:07 |
|
mmorgan left #evergreen |
| 18:00 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 18:19 |
|
Christineb joined #evergreen |
| 18:39 |
|
jihpringle joined #evergreen |
| 06:00 |
pinesol |
News from qatests: Failed Running pgTAP tests <http://testing.evergreen-ils.org/~live//archive/2022-03/2022-03-01_04:00:02/test.42.html> |
| 07:13 |
|
rjackson_isl_hom joined #evergreen |
| 07:16 |
|
collum joined #evergreen |
| 08:00 |
|
mantis joined #evergreen |
| 08:01 |
JBoyer |
^ A test about spaces around values was *also* testing whether or not URIs were deleted when records are changed. We don't do that anymore, and now the test is updated. |
| 08:23 |
pinesol |
News from commits: Update Test for LP1722827 After LP1482757 <https://git.evergreen-ils.org/?p=Evergreen.git;a=commitdiff;h=e9c6750312c9c1ba001119e918ac84f4bcd017a6> |
| 08:33 |
|
mmorgan joined #evergreen |
| 08:40 |
csharp_ |
JBoyer++ |
| 08:40 |
|
jvwoolf joined #evergreen |
| 11:33 |
pinesol |
Dyrcona: Your current monologue is at least 45 lines long. |
| 11:34 |
Dyrcona |
Thanks, ducky! |
| 11:34 |
Dyrcona |
I should check the load script. Not sure it does anyone encoding. |
| 11:38 |
Dyrcona |
Also, TRAMP++ EMACS++ # I edited the file on the remote test server, committed it to the repo on that test server, then pushed it to the main repo, all using Emacs running on my laptop.... BTW, I know you can do that in vim, but most vim users don't know that. :) |
| 11:41 |
Dyrcona |
It would be nice if there was an easy way in git to apply a commit to a different, almost identical file. There probably is, and I just don't have the magic sauce. |
| 11:41 |
Dyrcona |
@monologue |
| 11:41 |
pinesol |
Dyrcona: Your current monologue is at least 50 lines long. |
| 17:04 |
|
mmorgan1 left #evergreen |
| 17:18 |
|
jvwoolf left #evergreen |
| 17:48 |
|
Keith_isl joined #evergreen |
| 18:00 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 18:25 |
|
jihpringle joined #evergreen |
| 20:25 |
|
JBoyer joined #evergreen |
| 21:11 |
|
Keith-isl joined #evergreen |
| 06:02 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 06:52 |
|
rjackson_isl_hom joined #evergreen |
| 08:30 |
|
Dyrcona joined #evergreen |
| 08:32 |
|
mmorgan joined #evergreen |
| 09:37 |
Dyrcona |
JBoyer: I think we do, so I'll check that. Thanks for the suggestion. |
| 09:47 |
jeff |
chopPunctuation, chopPunctuation, chopPunctuation... heh. |
| 09:49 |
Dyrcona |
Yeah, I haven't looked but I suspect a busted field in the MARC. Maybe i should dump it now before someone changes it. |
| 09:54 |
jvwoolf |
Dyrcona: Before I forget again, I wanted to say that we tested the patch in 1482757 and it worked fine. We've got it running in production now. |
| 09:54 |
jvwoolf |
Let's see if I can get that to link correctly - lp1482757 |
| 09:54 |
Dyrcona |
Lp 1482757 |
| 09:54 |
pinesol |
Launchpad bug 1482757 in Evergreen "Loading records with located URIs should not delete and recreate call_numbers" [Low,Confirmed] https://launchpad.net/bugs/1482757 |
| 09:54 |
jvwoolf |
Dyrcona++ |
| 16:17 |
Dyrcona |
"Paprika! That will fix it." |
| 16:18 |
Dyrcona |
I just have to figure out why the proper logo isn't showing up, and why it still looks like it is in the navbar. I think that latter is a style issu. |
| 16:22 |
Dyrcona |
Guess I'll squash these little fixes out later... |
| 16:27 |
Dyrcona |
OK. I think I need to update the Apache configuration on my test vm to handle our library URLs correctly. |
| 16:27 |
Dyrcona |
But, that will have to wait for Monday. |
| 16:35 |
Dyrcona |
Have a good weekend, everyone! |
| 17:09 |
|
jihpringle joined #evergreen |
| 17:12 |
|
JBoyer joined #evergreen |
| 17:12 |
|
mmorgan left #evergreen |
| 17:49 |
|
jvwoolf left #evergreen |
| 18:02 |
pinesol |
News from qatests: Failed Running pgTAP tests <http://testing.evergreen-ils.org/~live//archive/2022-02/2022-02-25_16:00:02/test.42.html> |
| 01:22 |
|
Bmagic joined #evergreen |
| 01:38 |
|
Bmagic joined #evergreen |
| 01:38 |
|
dluch joined #evergreen |
| 06:00 |
pinesol |
News from qatests: Failed Installing Evergreen database pre-requisites <http://testing.evergreen-ils.org/~live//archive/2022-02/2022-02-22_04:00:02/test.39.html> |
| 07:16 |
|
rjackson_isl_hom joined #evergreen |
| 07:32 |
|
collum joined #evergreen |
| 08:26 |
|
rfrasur joined #evergreen |
| 08:34 |
|
jvwoolf joined #evergreen |
| 09:05 |
|
Dyrcona joined #evergreen |
| 09:07 |
|
Keith__isl joined #evergreen |
| 10:04 |
csharp_ |
somebody commit something to master so I can see whether the @rss version of commit announcement suffices for our purposes :-) |
| 10:06 |
csharp_ |
Dyrcona: I missed that you had included removing PG 9.6 on your branch - makes sense, but I wasn't seeing it before :-/ |
| 10:11 |
csharp_ |
Dyrcona: I'm interested in seeing that branch go in... to fully test it, would I want to run all the PGtap tests on PG 10-14? or is there another way? |
| 10:13 |
csharp_ |
(this is why I prefer more granular bugs/fixes, btw - not trying to be critical since you've done so much work though :-) ) |
| 10:28 |
Dyrcona |
csharp_: Commit the branch that updates the PostgreSQL prerequisite targets. That should test the rss feeds. :) |
| 10:29 |
Dyrcona |
My branch changes the default client to Pg 14, IIRC. I'm using it on almost all of my VMs with Pg 10 databases with no issues. |
| 10:30 |
Dyrcona |
As for more granular bug fixes, I mostly agree. I don't like the giant omnibus branches that sometimes appear. I also prefer more, smaller commits over larger commits that touch more lines/files. |
| 10:30 |
Dyrcona |
In the case of my branch, I think it's scope is fine. I don't see why removing Pg 9.6 and adding support for newer Pg version should be separate. |
| 10:32 |
csharp_ |
Dyrcona: makes sense - I wasn' |
| 10:32 |
csharp_ |
t speaking specifically about removal of 9.6 - it just looks like a whole lot to test at once :-) |
| 10:33 |
csharp_ |
but, I'm going for it, so we'll see :-) |
| 10:33 |
Dyrcona |
Nah, not so much. Just inst all Pg 10, if the tests pass, that's all you've really got to worry about. I say int he README that the other versions are not fully tested and may have performance issues. |
| 10:34 |
* Dyrcona |
wishes his fingers would cooperate. |
| 10:34 |
Dyrcona |
csharp_++ |
| 10:34 |
csharp_ |
ok, that's where I was starting anyway |
| 10:35 |
Dyrcona |
If you want to test a different Pg version, I'd recommend Pg 14. |
| 10:35 |
Dyrcona |
It has the most changes from Pg 9.6/10, and it is the latest. |
| 10:37 |
csharp_ |
will do |
| 10:40 |
Dyrcona |
I should use the other installations on my development db server more. I've mostly just been using Pg 10 lately. |
| 10:41 |
csharp_ |
Dyrcona: do you have the alternate versions running together on different ports? |
| 10:42 |
Dyrcona |
csharp_: Yes. When I want to test one version in particular, I'll swap out a configuration file with optimized parameters and reboot. |
| 10:42 |
Dyrcona |
If I'm not too fussed for performance, I'll just change the ports in my client config. |
| 12:00 |
|
jihpringle joined #evergreen |
| 12:04 |
csharp_ |
Dyrcona: I see this when running pg_prove on PG 10/master + your branch: https://pastebin.com/cYA4qzDW |
| 13:00 |
csharp_ |
Dyrcona: now I'm getting https://pastebin.com/LjE1DtxJ (I cherry-picked your latest commit on top and rebuild the DB) |
| 13:02 |
csharp_ |
s/rebuild/rebuilt/ |
| 13:02 |
csharp_ |
gonna step away for a few |
| 13:09 |
Dyrcona |
Another typo. I thought I tested these after making the changes.... |
| 13:10 |
Dyrcona |
Again, the db upgrade script is correct. Maybe I only ran the tests after running the db upgrade with the switch from namespace to local-name()? |
| 13:14 |
Dyrcona |
OK. This one looks like the last issue. I've poured over the diffs and don't see any other changed XPath that looks bad. |
| 13:16 |
Dyrcona |
Fortunately I put the XPath canges all in one commit. |
| 13:16 |
Dyrcona |
s/canges/changes/ |
| 13:16 |
Dyrcona |
typos-- |
| 13:19 |
Dyrcona |
csharp_: Same deal I pushed a new commit. |
| 13:22 |
* Dyrcona |
sighs. Some days are more typo-prone than others. |
| 14:41 |
csharp_ |
yay!: |
| 14:41 |
csharp_ |
Result: PASS |
| 14:41 |
csharp_ |
ok, now onto PG 14 |
| 15:01 |
csharp_ |
Dyrcona: ok, PG 14 pgtap tests pass too - is there anything else I should test? |
| 15:07 |
Dyrcona |
You could try the Perl tests. Do anything you'd normally do, like circulation or whatever. |
| 15:08 |
csharp_ |
10-4 |
| 16:07 |
Dyrcona |
So, I'm trying to figure out how the bootstrap OPAC knows to load main_logo.png. So far it just seems to be magic. My motivation is, I want to replace it with CWMARS' Logo, name home-logo.png. I'd rather not just replace main_logo.png, but I will if I have to. |
| 16:08 |
* csharp_ |
looks around for terranm but doesn't see her |
| 16:08 |
csharp_ |
she's our resident boostrap OPAC person :-) |
| 16:08 |
csharp_ |
@seen terranm |
| 16:08 |
pinesol |
csharp_: terranm was last seen in #evergreen 2 years, 23 weeks, 6 days, 4 hours, 39 minutes, and 31 seconds ago: <terranm> Bmagic++ for setting up bug squashing test server! https://docs.google.com/spreadsheets/d/1qYNGrJBt42_ArQzbwlcnKxS3TobDnmquSXZzopOkZh4/edit#gid=0 |
| 16:08 |
csharp_ |
huh I guess she's using a different nick lately :-/ |
| 16:10 |
Dyrcona |
My suspicion is it has something to do with glide.js, but my suspicions are frequently incorrect. |
| 16:11 |
csharp_ |
https://gapines.org/opac/images/main_logo.png - she must have figured out how to change it |
| 16:52 |
|
jvwoolf left #evergreen |
| 17:02 |
|
jihpringle joined #evergreen |
| 17:09 |
|
mmorgan left #evergreen |
| 18:00 |
pinesol |
News from qatests: Failed Installing Evergreen database pre-requisites <http://testing.evergreen-ils.org/~live//archive/2022-02/2022-02-22_16:00:02/test.39.html> |
| 06:00 |
pinesol |
News from qatests: Failed Installing Evergreen database pre-requisites <http://testing.evergreen-ils.org/~live//archive/2022-02/2022-02-15_04:00:02/test.39.html> |
| 08:00 |
|
collum joined #evergreen |
| 08:36 |
|
mantis1 joined #evergreen |
| 08:38 |
|
mmorgan joined #evergreen |
| 11:19 |
berick |
heh |
| 11:25 |
mmorgan |
csharp_++ |
| 11:26 |
mmorgan |
though my head is now spinning a bit :) |
| 11:37 |
Dyrcona |
csharp_: Part of the point of what I'm testing is to avoid cataloging staff from using MarcEdit to edit the 856s....They say it's the most time consuming step. |
| 11:37 |
Dyrcona |
Since I've got a Perl program to do that part, I may just add code to clean up certain junk characters. |
| 11:38 |
csharp_ |
good plan |
| 11:39 |
Dyrcona |
Yes, I've assigned myself to look at Bmagic's record loader, but don't think I'll use it for this process, just yet: Bug1947898 |
| 11:39 |
Bmagic |
Dyrcona++ |
| 11:39 |
Dyrcona |
Missed a space: Lp 1947898 |
| 11:39 |
pinesol |
Launchpad bug 1947898 in Evergreen "Enhanced MARC importer script electronic_marc_import.pl" [Wishlist,Confirmed] https://launchpad.net/bugs/1947898 - Assigned to Jason Stephenson (jstephenson) |
| 11:54 |
Dyrcona |
The reload finished in time for me to start another test run before lunch, so here goes. |
| 11:55 |
|
jihpringle joined #evergreen |
| 12:33 |
Dyrcona |
Yeah, after looking up the Windows-1252 character set, I'm pretty sure that what I'm seeing are the Euro symbol (0x80), double dagger (0x87), and right single quotation mark (0x92). |
| 12:34 |
Dyrcona |
There may be others, but I remember those three codes from the output. |
| 12:51 |
Dyrcona |
We're using Pg 10. Haven't noticed any real performance differences with Pg 9.6. |
| 12:51 |
Dyrcona |
At Pg 11, most things start getting faster, but others seem to get hit. |
| 12:52 |
Dyrcona |
We do a dump and restore at least whenever we get new hardware. |
| 12:52 |
Dyrcona |
I do them weekly to keep some test databases up to date. Anyway, getting off topic. |
| 12:54 |
Dyrcona |
Going back to my record load/character issues, the message isn't coming from MARC::Record, either. I've got a program to dump the 856s that uses the same code to read the records and it doesn't peep. |
| 12:56 |
Dyrcona |
I wonder if I can just convert the raw MARC data or if I need to do it field by field.... |
| 13:04 |
Dyrcona |
Now, it's just looking like some garbage and not necessarily Windows 1252... Probably a mix.... :( |
| 16:27 |
abowling |
Dyrcona++ |
| 16:28 |
Dyrcona |
I'm not sure if Elaine's comment regards the patch (it sounds like it), or if she's saying that she doesn't see the bug. |
| 16:29 |
Dyrcona |
I guess since I |
| 16:29 |
Dyrcona |
I'm having fun loading resources in a test database, I could check that one out, too... |
| 16:38 |
Dyrcona |
Alright, so, some of the records were not set to UTF-8 in the LDR, and I suspect that at least one of them was giving me this warning/error. |
| 16:39 |
abowling |
Dyrcona: thanks again! that fixed it. |
| 16:40 |
Dyrcona |
abowling: Cool. If you could update the Lp bug, that would be great. |
| 16:47 |
|
jvwoolf left #evergreen |
| 16:47 |
abowling |
Dyrcona: will do |
| 17:04 |
|
mmorgan left #evergreen |
| 18:00 |
pinesol |
News from qatests: Failed Installing Angular web client <http://testing.evergreen-ils.org/~live//archive/2022-02/2022-02-15_16:00:02/test.29.html> |
| 18:23 |
|
jeff joined #evergreen |
| 18:59 |
|
jonadab joined #evergreen |
| 00:52 |
|
troy joined #evergreen |
| 06:01 |
pinesol |
News from qatests: Failed Installing Evergreen database pre-requisites <http://testing.evergreen-ils.org/~live//archive/2022-02/2022-02-14_04:00:02/test.39.html> |
| 07:44 |
|
collum joined #evergreen |
| 08:17 |
|
Dyrcona joined #evergreen |
| 08:37 |
Dyrcona |
Another stuck search query running for 18 hours, well, two, but they look like the same search in the database. I guess the patron/staff tried it again when it didn't return any results. |
| 11:13 |
Dyrcona |
We had some libraries leave a few years ago. While looking into adding records for an e-resource vendor, I stumbled across asset.uri entries from this vendor for one of the libraries that left. |
| 11:15 |
Dyrcona |
I though we must have some 856s still in the database, but no. There are no links to asset.uri_call_number_map for these asset.uri entries, no asset.call_number entries, and I didn't find any metabib.real_full_rec entries when I did a tsquery on index_vector. |
| 11:15 |
Dyrcona |
Anyone else seen orphaned asset.uri entries before? |
| 11:16 |
Dyrcona |
I was able to just delete them from a test database. |
| 11:16 |
mmorgan |
bug 1482757 rears its ugly head :) |
| 11:16 |
pinesol |
Launchpad bug 1482757 in Evergreen "Loading records with located URIs should not delete and recreate call_numbers" [Low,Confirmed] https://launchpad.net/bugs/1482757 |
| 11:18 |
Dyrcona |
Yeah, maybe, but this feels like a different bug. I'll have to reread that one to see if orphaned entries are mentioned. |
| 11:22 |
pinesol |
Launchpad bug 1482757 in Evergreen "Loading records with located URIs should not delete and recreate call_numbers" [Low,Confirmed] |
| 11:22 |
Dyrcona |
Intereestingly, I found 20,000+ entries in metabib.real_full_rec that reference this particular libary in the 856, but no subfield u, just 9, y and z. |
| 11:22 |
Dyrcona |
GIGO. |
| 11:23 |
Dyrcona |
mmorgan: Cool, I'll read the bug description again. IIRC, I already signed off on the branch, no? I don't think it made much difference in performance when I tested it. |
| 11:24 |
* mmorgan |
needs to refresh memory on that, too. We are running some version of that patch in production. |
| 11:25 |
mmorgan |
Not sure it makes much difference in performance, but does eliminate call number churn. |
| 11:34 |
Dyrcona |
Right. I think I'm just going to do a blanket search for orphaned asset.uri entries and delete them. |
| 12:35 |
Dyrcona |
Over 2/3 of our asset.call_number table is deleted = 't' rows. I didn't bother to count those with the ##URI## label. |
| 12:38 |
|
jihpringle joined #evergreen |
| 12:44 |
|
jihpringle68 joined #evergreen |
| 12:52 |
Dyrcona |
Maybe it's high time that patch went in. I signed off over a year ago, but that probably means it needs a rebase and to be tested again. |
| 12:58 |
jvwoolf |
Dyrcona: If you rebase it, I can test it on a 9.6 DB with production data |
| 12:58 |
jvwoolf |
We're only running Evergreen 3.6 though |
| 12:59 |
jvwoolf |
Also, I see that there's an upgrade query in here to get rid of the orphaned entries in asset.uri_call_number_map but nothing to get rid of the call numbers |
| 13:00 |
jvwoolf |
I think that probably needs to be addressed in the release notes at the very least. It's probably better handled outside the upgrade scripts since it would be deleting the majority of the asset.call_number table in our case. |
| 13:03 |
Dyrcona |
jvwoolf: You can't really get rid of the call number. They just get tagged deleted. Or, do you mean, that there should be something to set call numbers deleted, too? |
| 13:04 |
jvwoolf |
Dyrcona: I think for us, we're going to need to get rid of the call number or our reports for filtering on call number are going to stay broken |
| 13:04 |
jvwoolf |
So maybe we're a special case |
| 16:30 |
|
Keith-isl joined #evergreen |
| 16:51 |
|
jvwoolf left #evergreen |
| 17:10 |
|
mmorgan left #evergreen |
| 18:01 |
pinesol |
News from qatests: Failed Installing Evergreen database pre-requisites <http://testing.evergreen-ils.org/~live//archive/2022-02/2022-02-14_16:00:02/test.39.html> |
| 09:09 |
|
jvwoolf joined #evergreen |
| 09:10 |
csharp_ |
yes, lesson is never upgrade anything ever for any reason whatsoever |
| 09:11 |
alynn26 |
csharp_++ |
| 09:11 |
Dyrcona |
Pretty much. At least not without testing it on more or less the same hardware, first. |
| 09:11 |
Dyrcona |
csharp_++ |
| 09:14 |
|
jvwoolf1 joined #evergreen |
| 09:16 |
csharp_ |
now fighting with fastcgi (I think) |
| 09:36 |
jeff |
I'm not even certain open-ils.auth is to blame, or the only service affected. It's just the first thing that a staff login page hits. :-) |
| 09:44 |
jeff |
oh, cute. yep, it was auth. found more clues in router syslog messages, found a misbehaving client. |
| 09:44 |
jeff |
still, the misbehavior could be symptom-not-cause, but worth pulling on this thread next. |
| 09:51 |
Dyrcona |
jeff: I'm taking bug 1959904 from you. I'm testing a potential fix today. |
| 09:51 |
pinesol |
Launchpad bug 1959904 in Evergreen "Angular Patron Search Can Freeze the Browser" [Undecided,Confirmed] https://launchpad.net/bugs/1959904 - Assigned to Jeff Godin (jgodin) |
| 09:52 |
jeff |
cool, i was working on that this morning but I'll stop. |
| 09:53 |
Dyrcona |
Well, I don't want to intrude, but we really want this fixed. :) |
| 16:07 |
|
pinesol joined #evergreen |
| 16:31 |
|
jihpringle joined #evergreen |
| 17:05 |
|
mmorgan left #evergreen |
| 18:01 |
pinesol |
News from qatests: Failed Installing Evergreen database pre-requisites <http://testing.evergreen-ils.org/~live//archive/2022-02/2022-02-11_16:00:02/test.39.html> |
| 06:01 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 08:28 |
|
mantis1 joined #evergreen |
| 08:31 |
|
rfrasur joined #evergreen |
| 08:40 |
|
mmorgan joined #evergreen |
| 13:03 |
Dyrcona |
miker: I haven't tried that search. |
| 13:03 |
miker |
looks like we should push the exact match construct down into the initial search structures. I wonder if my "make joins CTEs" patch helps here. I'll dig that up. |
| 13:08 |
Dyrcona |
Did they actually type "winter AND sports" in the search box? Do I understand that corectly? I did a keyword from advanced search with winter in one and sports in the other and it came back rather quickly. |
| 13:09 |
jeff |
I haven't specifically tested the "make joins CTEs" patch against postgresql < 12 and >= 12, but the change in CTE optimization fence behavior suggests that it might be a good idea (to test/compare). :-) |
| 13:09 |
Dyrcona |
Looks like they typed "winter" AND "sports" |
| 13:10 |
Dyrcona |
I hate when they try to outsmart the query engine. They usually do with bad consequences. :) |
| 13:11 |
Dyrcona |
Yeahp. The variation with the quotes takes longer/hangs. Hasn't been long enough to tell, but the quotes definitely take longer. |
| 16:02 |
|
jihpringle joined #evergreen |
| 17:03 |
|
jvwoolf left #evergreen |
| 17:10 |
|
mmorgan left #evergreen |
| 18:01 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 06:01 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 07:19 |
|
rjackson_isl_hom joined #evergreen |
| 08:24 |
|
collum joined #evergreen |
| 08:27 |
|
rjackson_isl_hom joined #evergreen |
| 15:12 |
phasefx |
miker++ |
| 15:12 |
shulabear |
What are the duties of the release team? |
| 15:12 |
terranm |
miker++ |
| 15:13 |
miker |
shulabear: coordinating, prodding folks to test/signoff/commit, release building |
| 15:13 |
gmcharlt |
miker++ |
| 15:13 |
terranm |
I'm happy to be bug squash/feedback fest wrangler again |
| 15:13 |
phasefx |
I didn't help a lick with the last team I was on; I'm willing to, but may need some help/direction |
| 15:27 |
Dyrcona |
gmcharlt: Does it still use Dojo? |
| 15:27 |
gmcharlt |
Dyrcona: correct, that hasn't changed |
| 15:28 |
Dyrcona |
Do we have plans to replace it with something that doesn't use Dojo? |
| 15:29 |
JBoyer |
I assume the choicest signoffs will involve using an Overdrive testing account, which I ... have gotten in the past but no longer remember the level of hassle one is required to endure. Have you and jeffdavis verified the actual downloading bits so that "Doesn't break my system and looks sane" type signoffs are sufficient? |
| 15:29 |
gmcharlt |
JBoyer: yes, we've verified it w.r.t. to real OverDrive credentials |
| 15:29 |
JBoyer |
gmcharlt++ |
| 15:29 |
JBoyer |
jeffdavis++ |
| 15:29 |
Dyrcona |
JBoyer: Even if you have credentials the Overdrive test environment is a pain to use. |
| 15:30 |
|
jvwoolf1 joined #evergreen |
| 15:31 |
JBoyer |
Though to guess at the answer to your Q Dyrcona, I haven't seen specific mention of a major update to the feature that I can recall. Depending on what Dojo is doing it could be a major undertaking. |
| 15:31 |
JBoyer |
And I can't say I'm surprised that it's a hassle to work with their backend. I'm still salty about the time they took away ftp access to new records. |
| 15:39 |
terranm |
JBoyer++ |
| 17:06 |
|
mmorgan left #evergreen |
| 17:34 |
|
jvwoolf1 left #evergreen |
| 18:01 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 18:12 |
|
jihpringle joined #evergreen |
| 21:52 |
pinesol |
[evergreen|gmontimantis] Docs: Updating Opac Lists doc - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=ad42342> |
| 22:45 |
pinesol |
[evergreen|Lynn Floyd] Adding videos from Conferences - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=bb054da> |
| 00:08 |
|
Kolvir joined #evergreen |
| 00:09 |
Kolvir |
Can I run the evergreen server and the client interface on a single system? |
| 00:22 |
jeff |
It can be done, especially for testing or development, but I wouldn't recommend it for "real" production use. |
| 00:26 |
Kolvir |
I'm going to be in charge of computerizing a small church library, completely paper based now, and am looking for a software package |
| 00:31 |
Kolvir |
There will only be one computer for patron use, and really doesn't need to be a separate one for admin, unless evergreen would require it. |
| 06:01 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 07:16 |
|
rjackson_isl_hom joined #evergreen |
| 07:55 |
|
alynn26 joined #evergreen |
| 08:34 |
|
mantis1 joined #evergreen |
| 14:42 |
|
Christineb joined #evergreen |
| 16:44 |
|
jvwoolf left #evergreen |
| 17:10 |
|
mmorgan left #evergreen |
| 18:01 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 18:40 |
|
jihpringle joined #evergreen |
