Time |
Nick |
Message |
06:02 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
06:54 |
|
agoben joined #evergreen |
07:07 |
|
rjackson_isl joined #evergreen |
07:31 |
|
rfrasur joined #evergreen |
08:21 |
eby |
dbs: jeff as another data point we just went from 3.0.2 -> 3.3.5 . i caught the change and backporting the default to when the field was created changed the database upgrades from hour+ to 15 minutes. our action.circulation is 12,583,648 |
08:24 |
|
Dyrcona joined #evergreen |
08:24 |
eby |
(we haven't aged anything yet) |
08:26 |
eby |
so backporting that default to the upgrade script would probably help others |
08:28 |
|
collum joined #evergreen |
08:42 |
|
mantis1 joined #evergreen |
08:45 |
|
mmorgan joined #evergreen |
08:48 |
|
remingtron joined #evergreen |
08:50 |
Dyrcona |
Go to Lp to open a new bug and discover that you already opened the bug two years ago: https://bugs.launchpad.net/ncipserver/+bug/1679292 |
08:50 |
pinesol |
Launchpad bug 1679292 in NCIPServer "NCIPServer should provide decent logging" [Wishlist,New] |
08:53 |
mmorgan |
Dyrcona: Been there, done that! |
09:04 |
|
tlittle joined #evergreen |
09:10 |
Dyrcona |
Are we still patching 3.2, officially? |
09:15 |
dbs |
https://evergreen-ils.org/egdownloads/ says security only, but if we can avoid major pain for those who aren't on 3.2 yet, it might be worth making an exception |
09:16 |
Dyrcona |
dbs: Thanks. I should have looked there, first. That answers my question. I just wanted to know for targeting a bug. |
09:16 |
dbs |
(although I suppose another way you could do it is just patching the 3.1.5-3.2.0 upgrade script in master, 3.4, and 3.3 |
09:17 |
dbs |
Dyrcona: ah i hear ya :) |
09:17 |
Dyrcona |
Ah, I was asking for a different reason, but yeah.... |
09:23 |
csharp |
@decide shelf-checks or self-checks |
09:23 |
pinesol |
csharp: go with shelf-checks |
09:23 |
csharp |
@blame library terminology |
09:23 |
pinesol |
csharp: library terminology HAXORED csharp's SERVERZ!!!! |
09:24 |
dbs |
I pushed a rough patch to user/dbs/avoid_hours_of_asset.circulation_updates |
09:30 |
csharp |
dbs++ |
09:30 |
|
yboston joined #evergreen |
09:30 |
Dyrcona |
It should be bugged on Lp. |
09:30 |
dbs |
Dyrcona: that was going to be my next step |
09:30 |
Dyrcona |
:) |
09:31 |
* csharp |
adds _or_if_you_run_pines_literally_days_of_updates to dbs's branch name |
09:33 |
Dyrcona |
Mine wasn't so bad. It actually finished a lot sooner than I thought it would, but it broke my replication server. :/ |
09:33 |
dbs |
ouch |
09:33 |
csharp |
I had some system badness too |
09:34 |
csharp |
it generated gigs and gigs of xlog that I had to deal with |
09:34 |
Dyrcona |
Yeahp. That's why my replication server had problems. |
09:35 |
Dyrcona |
Testing on non-replicated servers went just fine, but took a looooonnngggg time. |
09:49 |
dbs |
bugged with 1856047 and tweaked the branch commit log and name accordingly |
09:57 |
mmorgan |
dbs++ |
10:05 |
|
sandbergja joined #evergreen |
10:10 |
Dyrcona |
dbs: You want me to add the pullrequest tag to bug 1856047 while I'm confirming and targeting it? |
10:10 |
pinesol |
Launchpad bug 1856047 in Evergreen 3.4 "Updating auto_renewal column added in 3.2.0 can take hours or days on large systems" [Low,Confirmed] https://launchpad.net/bugs/1856047 |
10:11 |
Dyrcona |
I think someone else will have to test it as I don't have any pre-3.2 database dumps available. |
10:30 |
dbs |
Dyrcona: sure sounds good! |
10:30 |
Dyrcona |
OK. Done! |
10:32 |
Dyrcona |
If anyone disagrees with the Importance I assigned to the bug, feel free to change it. |
10:52 |
eby |
are most using the default max stanza size for ejabberd or does it usually require a bump? |
10:59 |
berick |
eby: i'm still bumping. there are edge cases |
11:01 |
eby |
thanks berick . run into it with some action trigger event creation and wondered if was worth digging into or just happens |
11:03 |
Dyrcona |
eby: We bump in production, but I usually leave it alone on test VMs. |
11:21 |
|
Christineb joined #evergreen |
11:55 |
|
jihpringle joined #evergreen |
12:31 |
|
khuckins joined #evergreen |
12:51 |
|
collum joined #evergreen |
13:23 |
|
JimPossible joined #evergreen |
13:23 |
JimPossible |
Hi all, where can I learn more about nullability in the reporting module? |
13:26 |
jonadab |
Hmm, I think I have a PDF of some slides from a presentation about nullability. |
13:26 |
jonadab |
That someone gave me at some point. |
13:26 |
jonadab |
"Nullability and Statistical Categories reporting" |
13:27 |
jonadab |
It's succinct. |
13:28 |
jonadab |
There's a table on the second page (of 3) that lists Child as meaning RIGHT JOIN, Parent as LEFT JOIN, Default as "RIGHT OR LEFT JOIN" (probably means FULL JOIN). |
13:41 |
* dbs |
trying to remember - did the default get reversed in the webby reporter interface, so that it's actually an INNER JOIN ? |
13:43 |
JBoyer |
dbs, there was a point where all joins became inner. Those dark days (should) have passed us by, however. |
13:47 |
eby |
@decide inner or outer |
13:47 |
pinesol |
eby: go with outer |
13:57 |
|
sandbergja joined #evergreen |
14:16 |
csharp |
JimPossible: basically "child nullable" forces a left join, meaning that you bring back rows from the table on the "left" side of the join (the "parent") - "parent nullable" is a right join where you bring back rows on the "right" side of the join even if there's nothing on the left and "Default" means "do whatever you would have done if I hadn't clicked on "Nullability"", which may be inner, left, or |
14:17 |
csharp |
right, depending on how the sources are defined in the fieldmapper file |
14:17 |
* csharp |
wheezes after typing that out |
14:19 |
csharp |
awwww |
14:19 |
* csharp |
probably would've left after hearing that too |
14:25 |
rfrasur |
Does anyone have an extra copy of the 2018 Evergreen Community Annual Report I could swap for...some random thing on my desk or goodwill? |
14:32 |
dbs |
rfrasur: what will you give me for https://evergreen-ils.org/about-us/annual-reports/ ? :) |
14:33 |
* csharp |
watches dbs figure out how to monetize publicly available websites :-) |
14:34 |
rfrasur |
I mean...I have an empty cheese container and a cut paper snowflake that only has one tear and vaguely represents the evergreen indiana logo. I also have some unsharpened ticonderoga #2 yellow pencils... |
14:34 |
* rfrasur |
is looking for one of the nice glossy hard copies. |
14:34 |
csharp |
ooh Ticonderoga... |
14:34 |
rfrasur |
csharp++ # cuz you know what's up. |
14:35 |
csharp |
you can only find those on the EG documentation black market nowadays |
14:35 |
dbs |
csharp: dude I can't, there's no license on the report |
14:35 |
rfrasur |
I also have Pilot G-2 .05 pens...but I'm saving those. |
14:35 |
rfrasur |
I'd give up ONE of those pens for an annual report. |
14:35 |
csharp |
dbs++ |
14:36 |
rfrasur |
Oh, I do have a bookmark made out of some bit of circuit board. It's a terrible bookmark (too thick) but cool looking. |
14:36 |
collum |
I may one day conclude that my 15 year old unsharpened pencils in my pencil holder are not going to be used. |
14:37 |
rfrasur |
lol, collum!!! wth? Are they the nasty round "branded" kind? |
14:37 |
alynn26 |
all pencils must be sharpened. |
14:38 |
collum |
It looks like most of them are swag from different conferences. |
14:38 |
rfrasur |
only if one has been provided with a pencil sharpener. I have not and don't wanna go to another office. But...have one in my amazon list. |
14:38 |
alynn26 |
there is one in my office |
14:38 |
rfrasur |
collum, swag pencils. Hit or miss. Ticonderoga all the way. |
14:39 |
alynn26 |
ticonderoga++ |
14:39 |
rfrasur |
alynn26, I know, lol. |
14:41 |
dbs |
examine sharpener |
14:42 |
* dbs |
suddenly felt like he was in an Infocom text adventure for some reason |
14:42 |
rfrasur |
I'm lookin' at an x-acto quiet motor one. |
14:42 |
rfrasur |
dbs++ |
14:42 |
dbs |
poke sharpener |
14:44 |
JBoyer |
dbs++ |
14:44 |
* alynn26 |
hears a grinding noice |
15:01 |
eby |
has anyone done tweaks to HoldNotify.pm similar to the SendEmail bug 1801163 ? noticing on perl 5.26 that some unicode characters throw a wide character error on email sending in HoldNotify but not A/T. Seeing more encoding of text in A/T |
15:01 |
pinesol |
Launchpad bug 1801163 in Evergreen "SendEmail A/T reactor broken for recent version of Encode::MIME::Header" [High,Confirmed] https://launchpad.net/bugs/1801163 - Assigned to Jeff Godin (jgodin) |
15:03 |
Dyrcona |
eby: I'm not sure that the wide characters warnings are related. With the referenced bug, email just plain isn't sent. |
15:05 |
eby |
yeah i noticed a comment about using the mime elsewhere since it was going to be a dependency and wondered if that might help with the encoding |
15:05 |
JBoyer |
I was under the impression that things that throw that wide character error are mis-encoded (i.e. invalid UTF-8 chars, etc.) but things still seem to work when it pops up. |
15:06 |
Dyrcona |
I don't know if it will help. |
15:06 |
jonadab |
The wide character error can happen if data comes from a UTF-8 source that Perl assumes isn't a UTF-8 source for whatever reason. |
15:06 |
Dyrcona |
Unicode in Perl is awful, and hardly anyone uses Encode properly because, despite being a "simple" interface, it's actually hard to use properly. |
15:07 |
jonadab |
e.g., if Perl thinks the data are Latin-1, and they're actually UTF-8, you get that error. |
15:07 |
Dyrcona |
Well, that and other things..... |
15:07 |
Dyrcona |
Generally, it's crap data. |
15:08 |
Dyrcona |
Character set X claiming to be/masquerading as Y. |
15:14 |
eby |
thanks. i'll see what i can find. definitely bombs holdnotify out |
15:17 |
Dyrcona |
It could be a bug somewhere, such as a double encode happening. We fixed a number of those a while back, but might have missed them. It could be a character in a different character set that got into your data, like in a title. |
15:19 |
Dyrcona |
@who stole the decoder ring |
15:19 |
pinesol |
genpaku stole the decoder ring. |
15:20 |
eby |
it's definitely the title of the item in the send |
15:21 |
eby |
was just curious since I noticed SendEmail has encode_utf8 of the text and uses Mime and handles the same title fine |
15:23 |
mmorgan |
miker: It continues. I hadn't intended a virtual index mapping for the title class on my 3.2.9 test system. I removed that and restarted services. That changed the query for my "symphony" title search, but the query results are exactly the same, so that virtual keyword addition was having no effect. Swapping out the english_nostop for simple made a very slight difference in the rel score for two of the records, but not e |
15:27 |
JBoyer |
fyi mmorgan, for me that stopped at "two of the records, but not en" in case you wrote much more. |
15:27 |
dbs |
oh fun, I guess I forgot that "My List" / "View basket" can't display books that only have a located URI, no physical holdings |
15:27 |
mmorgan |
Ok, thanks, here's the rest: |
15:28 |
mmorgan |
but not enough to change the order of hits. The popular record still sorts 4th out of 5 in the poprel search. |
15:29 |
dbs |
hmm, can't find a bug for it. Guess I'll open one. |
15:35 |
dbs |
Wait. Working on the demo server. Hrm |
15:50 |
|
mantis1 left #evergreen |
15:55 |
jeff |
dbs: I think there was a bug on that. Looking. |
15:59 |
jeff |
...there's proving a negative, and then there's launchpad search. |
16:00 |
Dyrcona |
:) |
16:02 |
jeff |
dbs: can't find the bug I was thinking of. |
16:05 |
Dyrcona |
Try reporting a new one. That sometimes works to find a duplicate. |
16:09 |
jeff |
I've used that trick in the past. :-) |
16:09 |
* dbs |
started reporting the bug, and his title didn't turn up the old one |
16:10 |
dbs |
I was working through the Concerto sample on the demo server but there it shows the books with no physical copies |
16:11 |
dbs |
Really strange because all of our Perl code is in sync with upstream/rel_3_4 as is the mylist.tt2 / anon_list.tt2 templates |
16:14 |
collum |
bug 1802518 |
16:14 |
pinesol |
Launchpad bug 1802518 in Evergreen "Basket view does not include bib records with no holdings" [Undecided,Confirmed] https://launchpad.net/bugs/1802518 |
16:14 |
collum |
Maybe? |
16:14 |
jeff |
my memory of the issue is that an 856-only record cannot be added to a list, or perhaps if added to a list will not appear when viewing the list. |
16:15 |
dbs |
That's exactly the right bug |
16:16 |
dbs |
but yet it seems to work on demo.evergreencatalog.com |
16:16 |
jeff |
dbs: also, the issue you're looking into might be sensitive to global flags like the "located uris behave like copies" flag. I don't know if your local server and the demo server have the same settings there. |
16:17 |
dbs |
I checked the global flag on the demo server and it's FALSE, like our server |
16:18 |
dbs |
Makes me feel better that it's not just us! I can go back into digging into the anon_list.tt2 template and Container.pm code |
16:19 |
dbs |
(all the record ids are listed in the XHR response to /eg/opac/api/mylist/retrieve - {"mylist":[739015,2916495]} even though only one record is displayed) |
16:22 |
dbs |
Trying to remember if we generate the ebook records in Concerto by creating and then deleting physical holdings, maybe? |
16:22 |
* dbs |
looks |
16:25 |
dbs |
doesn't look like it; ebooks are loaded in their own file with just located URIs |
16:28 |
dbs |
They're all at CONS; I'll try moving some down to SYS1 and BR1 |
16:29 |
dbs |
BOOM |
16:31 |
jeff |
cute. |
16:31 |
jeff |
yeah, maybe not a very good test data set for located uris to have them all at top of tree. :-) |
16:40 |
dbs |
Updated the bug accordingly. Identifying that pattern is 90% of fixing the bug, feels good! |
16:42 |
|
rfrasur joined #evergreen |
16:42 |
|
jvwoolf1 left #evergreen |
16:44 |
|
khuckins joined #evergreen |
17:02 |
|
mmorgan left #evergreen |
17:24 |
|
sandbergja_ joined #evergreen |
18:02 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
18:08 |
|
jihpringle joined #evergreen |
18:19 |
jeffdavis |
There is a Perl live test (20-lp1541559-ebook-api.t) which assumes those ebooks have located URIs at CONS, something to watch for if the concerto data is changed |
19:09 |
|
cmalm joined #evergreen |
19:20 |
dbs |
thanks for the heads-up jeffdavis! |
19:38 |
|
sandbergja joined #evergreen |
20:59 |
|
rfrasur joined #evergreen |