| 15:19 |
csharp |
ok cool |
| 15:20 |
terranm |
What Bill said |
| 15:20 |
* berick |
notes 2/17 may be a holiday for some |
| 15:20 |
terranm |
If we can get a bunch of those pullrequests on some sandboxes, the New Developers Group should be able to test a good chunk of them |
| 15:20 |
csharp |
# feedback fest scheduled for the week of 2/17 - 2/22 - code reviewers and committers are expected to participate |
| 15:20 |
csharp |
#info feedback fest scheduled for the week of 2/17 - 2/22 - code reviewers and committers are expected to participate |
| 15:20 |
* csharp |
will get the hang of it |
| 15:32 |
pinesol |
sandbergja: [evergreen|Galen Charlton] LP#1855931: (follow-up) make grid filter control cells wrap as well - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=9077cbc> |
| 15:32 |
jeffdavis |
berick: yes, I think so |
| 15:32 |
jeffdavis |
ah, I was trying to find that follow-up bug |
| 15:32 |
sandbergja |
(just musing, I have not tested a rebased version of gmcharlt's branch for 1846042) |
| 15:33 |
terranm |
PINES has this one in production and it seems to be working well: https://bugs.launchpad.net/evergreen/+bug/1570072 - I'm not sure if anyone else from ECDI has seen any issues with testing |
| 15:33 |
pinesol |
Launchpad bug 1570072 in Evergreen "Hold request update notification preferences on change" [Wishlist,Confirmed] |
| 15:34 |
jeffdavis |
terranm: do you want that targeted for 3.5? Currently it's 3.next |
| 15:49 |
sandbergja |
But don't clobber the server with simultaneous requests |
| 15:49 |
sandbergja |
jeffdavis mentioned that this should be an approach that we take not just in Item Status, but throughout the Web client |
| 15:50 |
berick |
sandbergja: your promise batching code looks sane. i have not kept up with the bug... does that solve the issue in your tests? |
| 15:50 |
sandbergja |
It does |
| 15:50 |
sandbergja |
But all my tests have been on a little VM on my laptop |
| 15:51 |
sandbergja |
So I'd really appreciate more help testing the specific case in bug 1821094 |
| 15:51 |
pinesol |
Launchpad bug 1821094 in Evergreen 3.3 "Item status refresh after editing can get confusingly slow" [Medium,Confirmed] https://launchpad.net/bugs/1821094 |
| 15:51 |
sandbergja |
And also some discussion about whether we want to batch the promise resolving in other places in the AngularJS client |
| 15:51 |
sandbergja |
Here's the specific commit: https://git.evergreen-ils.org/?p=working/Evergreen.git;a=commitdiff;h=75176bca0ce8051a6dd4ba56f5613bce75901f09 |
| 15:52 |
csharp |
sandbergja: we can test it on a PINES server with realistic data/specs |
| 15:52 |
sandbergja |
charp++ |
| 15:52 |
sandbergja |
That would be really helpful! |
| 15:52 |
csharp |
#action csharp will arrange testing for sandbergja's fix to https://launchpad.net/bugs/1821094 on a realistic test server |
| 16:44 |
bshum |
Just to be safe |
| 16:44 |
* bshum |
adds to his Hackfest ideas list |
| 16:44 |
Dyrcona |
Yeah, we need more pgtap tests. |
| 16:45 |
Dyrcona |
Not sure that we can really test all of the functions since they rely so heavily on side effects. |
| 16:45 |
bshum |
Right |
| 16:45 |
bshum |
But at least we can put some input and see what expected output ought to be |
| 16:46 |
Dyrcona |
I *think* we can do multistep tests, i.e. run the function and check table values after. |
| 16:46 |
bshum |
Right |
| 16:46 |
bshum |
I'm pretty sure we can |
| 16:47 |
mdriscoll |
bshum++ |
| 17:16 |
csharp |
berick++ # finishing the meeting |
| 17:16 |
csharp |
@band add Tab Crash |
| 17:16 |
pinesol |
csharp: Band 'Tab Crash' added to list |
| 17:17 |
Dyrcona |
Also for the logs, you can backport the Pg 10 fixes to earlier versions and things are OK. I've tested them on both 9.5 and 9.6. |
| 18:03 |
|
sandbergja_ joined #evergreen |
| 20:16 |
|
sandbergja joined #evergreen |
| 20:57 |
|
JBoyer joined #evergreen |
| 00:49 |
|
cmalm_ joined #evergreen |
| 00:51 |
|
sandbergja joined #evergreen |
| 02:30 |
|
sandbergja joined #evergreen |
| 06:01 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 06:58 |
|
rfrasur joined #evergreen |
| 07:06 |
|
agoben joined #evergreen |
| 07:10 |
|
rjackson_isl joined #evergreen |
| 09:51 |
Dyrcona |
Some vendors are still stuck in the '90s where PINs were used instead of passwords. |
| 09:52 |
rfrasur |
lol, yes, some of them are. Bless them. |
| 09:52 |
Dyrcona |
I do the opposite of bless them. :) |
| 09:53 |
Dyrcona |
But, anyway.... I guess it is still worth looking into the bugs with passwords, even if I can't use my account to test it. |
| 09:55 |
Dyrcona |
Really, I think it would be better if we had an OAuth provider and vendors connected to that to authorize our patrons. Looks like OverDrive's authentication is a form of OAuth provider. |
| 09:56 |
rfrasur |
(blessing and cursing can often bear striking similarities) |
| 09:57 |
Dyrcona |
:) |
| 17:06 |
|
mmorgan left #evergreen |
| 17:21 |
|
jihpringle joined #evergreen |
| 17:21 |
jeff |
is there anything attendees need to do to prevent our information from being shared with sched? |
| 18:01 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 20:01 |
|
sandbergja joined #evergreen |
| 21:13 |
|
jvwoolf joined #evergreen |
| 21:42 |
|
yboston joined #evergreen |
| 11:34 |
Dyrcona |
If you just install the plain old pgtap package on Ubuntu 16, it also tries to install Pg 9.6 if Pg 10 is already installed. |
| 11:48 |
Dyrcona |
And, then, you're back on a variation of the way you thought that things wouldn't work. |
| 11:49 |
|
jihpringle joined #evergreen |
| 11:50 |
Dyrcona |
Here's a question: Do we want translators to have to install the browsers for testing? I don't think so, but... |
| 11:51 |
Dyrcona |
Packagers, definitely. |
| 12:11 |
|
rjackson_isl_ joined #evergreen |
| 12:21 |
|
sandbergja joined #evergreen |
| 17:52 |
csharp |
ok, I just fixed the GPLS email lists issue (open-ils-general, -dev, -documentation, commits, etc.) - I deactivated some lists recently and removed a required configuration piece without noticing |
| 17:52 |
csharp |
systemd-- # for not telling me what's going on |
| 17:52 |
csharp |
so you may see an influx of messages |
| 18:01 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 18:05 |
Bmagic |
csharp++ |
| 18:26 |
|
jihpringle joined #evergreen |
| 18:28 |
jihpringle |
Bmagic: re: your acq questions when I've seen it it's because the activation timed out partway through (activating again usually fixes it) or it's run into an item it doesn't like, such as one attached to a deleted record |
| 00:33 |
|
sandbergja joined #evergreen |
| 01:03 |
|
cmalm joined #evergreen |
| 02:48 |
|
cmalm_ joined #evergreen |
| 06:00 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 06:43 |
|
agoben joined #evergreen |
| 07:08 |
|
rjackson_isl joined #evergreen |
| 08:15 |
|
tlittle joined #evergreen |
| 14:24 |
Dyrcona |
Hmm... 3.3. is missing from the targetable series list... |
| 14:25 |
gmcharlt |
Dyrcona: hit refresh on the bug; I think it's missing because I beat you to adding the target |
| 14:26 |
Dyrcona |
Oh! OK! |
| 14:26 |
Dyrcona |
JBoyer: If you're testing it, I'll leave it be. |
| 14:27 |
JBoyer |
I have only just started. If you're motivated and closer don't let me stop you. :) |
| 14:27 |
Dyrcona |
I have been struggling with getting the time set correctly on some "new" servers that spent two months sitting on a shelf, so I'm a bit out of it at the moment. |
| 14:28 |
Dyrcona |
JBoyer: You're probably farther along than I am. |
| 16:46 |
|
jihpringle joined #evergreen |
| 17:06 |
|
mmorgan left #evergreen |
| 17:31 |
|
jihpringle joined #evergreen |
| 18:00 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 18:06 |
|
sandbergja_ joined #evergreen |
| 18:26 |
|
sandbergja__ joined #evergreen |
| 18:35 |
sandbergja |
Stompro++ #so many of your great bugfixes are going into 3.4.2! |
| 02:29 |
|
cmalm joined #evergreen |
| 03:09 |
|
kip joined #evergreen |
| 05:54 |
|
dbwells_ joined #evergreen |
| 06:00 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 06:54 |
|
rfrasur joined #evergreen |
| 07:02 |
|
agoben joined #evergreen |
| 07:15 |
|
rjackson_isl joined #evergreen |
| 10:37 |
|
sandbergja__ joined #evergreen |
| 10:57 |
gmcharlt |
csharp: I've updated 1811710 |
| 11:04 |
csharp |
gmcharlt: responded |
| 11:05 |
gmcharlt |
csharp: thanks |
| 11:05 |
gmcharlt |
two more questions |
| 11:06 |
gmcharlt |
1. is the test DB in question still around? if so, I'd like to see the result of select * from pg_attribute where attname = 'hopeless_date'; |
| 11:06 |
gmcharlt |
2. is it possible that the test DB would have originated from a database that was created back in the pre-Pg-8.3 days? |
| 11:07 |
gmcharlt |
in particular, of a lineage that would have be upgraded via pg_upgrade, not pg_dump & restore? |
| 11:07 |
csharp |
1. the DB is around, but I dropped the hopeless columns to fully roll back the changes |
| 11:08 |
csharp |
2. I've used pg_upgrade to go from 9.3 -> 9.5, then 9.5 -> 9.6, but it was all pg_dump/pg_restore before that |
| 11:09 |
gmcharlt |
ok, in that DB, what attypid values do you get from select * from pg_attribute where attname = 'request_time';? |
| 15:54 |
Dyrcona |
And, with that, I'm signing out for the day. |
| 16:00 |
jeffdavis |
the fix for bug 1848550 will mitigate open-ils.actor drone exhaustion |
| 16:00 |
pinesol |
Launchpad bug 1848550 in Evergreen "Cache settings more aggressively in web client" [Undecided,Confirmed] https://launchpad.net/bugs/1848550 |
| 16:01 |
jeffdavis |
I still need to test the Angular parts on that one |
| 16:05 |
|
rfrasur joined #evergreen |
| 16:18 |
|
mmorgan joined #evergreen |
| 16:23 |
dbs |
jeffdavis++ |
| 17:03 |
|
mmorgan left #evergreen |
| 17:34 |
|
jihpringle joined #evergreen |
| 17:35 |
|
rfrasur joined #evergreen |
| 18:00 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 18:20 |
|
sandbergja_ joined #evergreen |
| 19:26 |
|
sandbergja_ joined #evergreen |
| 01:13 |
|
cmalm joined #evergreen |
| 01:27 |
|
cmalm joined #evergreen |
| 06:01 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 06:55 |
|
agoben joined #evergreen |
| 07:12 |
|
rjackson_isl joined #evergreen |
| 07:17 |
|
collum joined #evergreen |
| 14:25 |
|
Jeff_ARE joined #evergreen |
| 14:27 |
Jeff_ARE |
I'm struggling to import MARC records into a new (my first) Evergreen install. When I upload a file with a single record the Upload Progress quickly goes to 100%, but the Enqueue Progress never moves beyond 0%. The Inspect Queue tab shows show the import in the queue but it never finishes. Do I need to do anything to kickstart the processing of the |
| 14:27 |
Jeff_ARE |
queue? This is my first Evergreen experience so I may be missing something |
| 14:28 |
rfrasur |
Jeff_ARE, are you import using the batch importer with only one record because of testing? |
| 14:28 |
rfrasur |
s/import/importing |
| 14:29 |
Jeff_ARE |
Yes. I tried 5000 records and same result, then tried 100 records and same result. So for testing am just trying a single record |
| 14:29 |
berick |
Jeff_ARE: beware of https://bugs.launchpad.net/evergreen/+bug/1855199 |
| 14:29 |
rfrasur |
Gotcha. Hold on real quick. |
| 14:29 |
pinesol |
Launchpad bug 1855199 in Evergreen "Vandelay record queuing can fail if spool directory is /tmp" [Medium,Confirmed] |
| 17:29 |
|
_bott_ joined #evergreen |
| 17:37 |
|
_bott_ joined #evergreen |
| 17:52 |
|
_bott_ joined #evergreen |
| 18:01 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 18:03 |
|
_bott_ joined #evergreen |
| 18:48 |
|
_bott_ joined #evergreen |
| 19:08 |
|
_bott_ joined #evergreen |
| 02:18 |
|
cmalm joined #evergreen |
| 02:29 |
|
cmalm_ joined #evergreen |
| 02:43 |
|
cmalm joined #evergreen |
| 06:01 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 06:43 |
|
_bott_ joined #evergreen |
| 06:57 |
|
agoben joined #evergreen |
| 07:13 |
|
rjackson_isl joined #evergreen |
| 11:02 |
dbs |
We had two separate instances of clark-kent.pl running, each with --concurrency 2 |
| 11:30 |
|
sandbergja joined #evergreen |
| 11:49 |
|
_bott_ joined #evergreen |
| 11:59 |
gmcharlt |
csharp: re 1811710, do you happen to still have final fm_IDL.xml as installed on your test system? |
| 12:02 |
|
jihpringle joined #evergreen |
| 12:05 |
jeff |
Thinking about the physical logistics of distributing a large number of new patron cards (>5000): has anyone here ordered cards from somewhere where they're pre-stuck to a card / mailer, or something creative like that? |
| 12:05 |
jeff |
or used a removable sticker on the card? |
| 14:00 |
csharp |
gmcharlt: https://pastebin.com/a263dZ74 |
| 14:12 |
jeffdavis |
autogen? |
| 14:13 |
|
Christineb joined #evergreen |
| 14:14 |
csharp |
jeffdavis: I ran autogen - no dice |
| 14:15 |
csharp |
after we upgrade this weekend, we'll put it back on our test server so we can suss it out non-forensically |
| 14:48 |
|
_bott_1 joined #evergreen |
| 15:04 |
jihpringle |
sandbergja: is LP 1852782 the best bug to add the screenshot to? |
| 15:04 |
pinesol |
Launchpad bug 1852782 in Evergreen "Angular MARC Editor Part 2 -- Enriched Editor" [Wishlist,New] https://launchpad.net/bugs/1852782 |
| 16:28 |
|
sandbergja_ joined #evergreen |
| 17:12 |
|
mmorgan left #evergreen |
| 17:32 |
|
stephengwills left #evergreen |
| 18:01 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 20:47 |
|
stephengwills joined #evergreen |
| 20:48 |
|
stephengwills left #evergreen |
| 20:54 |
|
sandbergja joined #evergreen |
| 00:37 |
|
sandbergja joined #evergreen |
| 06:01 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 07:07 |
|
rfrasur joined #evergreen |
| 07:08 |
|
rjackson_isl joined #evergreen |
| 07:49 |
|
collum joined #evergreen |
| 14:21 |
|
_bott_ joined #evergreen |
| 14:35 |
|
_bott_ joined #evergreen |
| 14:40 |
|
_bott_ joined #evergreen |
| 14:48 |
csharp |
seeing some log errors on our test server that don't make sense to me: 2020-01-13 14:38:44 next-brick01-head open-ils.cstore: [ERR :20970:oils_sql.c:6993:1578914702188581199] open-ils.cstore ERROR No "datatype" attribute for field "hopeless_prone" |
| 14:48 |
csharp |
we've applied the hopeless holds branch and are planning to go live with it |
| 14:49 |
csharp |
fm_IDL.xml hwas this: <field name="hopeless_prone" reporter:datatype="bool"/> |
| 14:49 |
csharp |
so I don't know what the code is looking for if not that |
| 14:50 |
mmorgan |
csharp: I believe hopeless_prone would be an attribute of a copy status |
| 14:50 |
csharp |
right |
| 14:50 |
* Dyrcona |
sighs. |
| 17:23 |
|
_bott_ joined #evergreen |
| 17:38 |
|
khuckins joined #evergreen |
| 17:49 |
|
sandbergja_ joined #evergreen |
| 18:01 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 18:06 |
|
stephengwills left #evergreen |
| 18:15 |
|
sandbergja_ joined #evergreen |
| 19:25 |
|
sandbergja_ joined #evergreen |
| 01:23 |
|
cmalm joined #evergreen |
| 01:53 |
|
sandbergja joined #evergreen |
| 06:01 |
pinesol |
News from qatests: Failed Create Evergreen Database <http://testing.evergreen-ils.org/~live//archive/2020-01/2020-01-10_04:00:02/test.41.html> |
| 06:57 |
|
rfrasur joined #evergreen |
| 07:26 |
|
rjackson_isl joined #evergreen |
| 08:28 |
pastebot |
"phasefx" at 168.25.130.30 pasted "re: pgtap failure" (34 lines) at http://paste.evergreen-ils.org/10119 |
| 08:31 |
csharp |
investigating an issue where bib TCNs are getting changed to the record ID upon saving - I've ruled out BibCommon.pm as a possible cause - now looking at marcedit.js |
| 08:32 |
csharp |
apparently only happening when editing an existing record - imports from z39.50 are not affected as far as I understand |
| 08:32 |
csharp |
confirmed - only already existing records |
| 08:32 |
|
Dyrcona joined #evergreen |
| 08:33 |
csharp |
(on 3.4 testing server, btw) |
| 08:35 |
|
sandbergja joined #evergreen |
| 08:40 |
|
mantis1 joined #evergreen |
| 08:44 |
|
_bott_ left #evergreen |
| 10:54 |
gmcharlt |
upshot: open-ils.cat.biblio.record.xml.update appears to be what's needed |
| 10:55 |
gmcharlt |
also, this affects both the AngularJS and Angular sides |
| 10:57 |
* berick |
follows conversation |
| 10:58 |
csharp |
gmcharlt++ |
| 11:04 |
csharp |
gmcharlt: I can confirm that changing that call to xml.update works |
| 11:53 |
|
mmorgan joined #evergreen |
| 11:57 |
|
jihpringle joined #evergreen |
| 11:57 |
csharp |
gmcharlt: I added a branch to bug 1859191 for review - not sure about how to test Angular cataloging |
| 11:57 |
pinesol |
Launchpad bug 1859191 in Evergreen "Editing and saving MARC record changes the TCN value" [High,Confirmed] https://launchpad.net/bugs/1859191 |
| 12:10 |
|
rfrasur joined #evergreen |
| 12:12 |
|
yboston joined #evergreen |
| 12:19 |
|
aabbee left #evergreen |
| 16:34 |
|
dbwells joined #evergreen |
| 16:46 |
|
jvwoolf left #evergreen |
| 17:04 |
|
mmorgan left #evergreen |
| 18:01 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 18:14 |
|
dbwells_ joined #evergreen |
| 18:37 |
|
_bott_ joined #evergreen |
| 21:18 |
|
sandbergja joined #evergreen |
| 02:26 |
|
cmalm joined #evergreen |
| 02:50 |
|
cmalm joined #evergreen |
| 03:11 |
|
cmalm joined #evergreen |
| 06:00 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 07:06 |
|
agoben joined #evergreen |
| 07:15 |
|
rjackson_isl joined #evergreen |
| 08:16 |
|
alynn26 joined #evergreen |
| 14:09 |
abneiman |
probably so. +1 to collab alynn26 |
| 14:10 |
dluch |
That would be great. And maybe we could do some version as an online thing for folks who can't be at conference |
| 14:10 |
abneiman |
dluch: that's a good idea |
| 14:10 |
dluch |
abneiman++ alynn26++ |
| 14:11 |
dluch |
#3, abneiman: I know you have prodded gmcharlt about the test server. More on that shortly, unless you want to say anything now? |
| 14:11 |
abneiman |
nope nothing from me |
| 14:11 |
dluch |
abneiman++ |
| 14:11 |
dluch |
#4, sandbergja, gmcharlt, and/or Dyrcona: how's work on setting up a git repo for ui (and maybe layouts) coming? |
| 14:15 |
Bmagic |
tkatie217: Thank you :) |
| 14:15 |
dluch |
remingtron++ |
| 14:15 |
Bmagic |
remingtron++ |
| 14:16 |
dluch |
#6, Everyone will test the new Antora server and email the DIG list (or IRC) with problems (or suggestions). I don't think I've seen many (any?) emails with problems or suggestions. How is testing going? (Also, more on Antora shortly.) |
| 14:17 |
dluch |
crickets... |
| 14:17 |
alynn26 |
It looks great. |
| 14:17 |
Bmagic |
:) |
| 14:17 |
dluch |
I agree, it does look great |
| 14:17 |
remingtron |
there are still little bugs hiding everywhere, so please test! |
| 14:18 |
dluch |
I'll keep that on as an action item, then. :-) |
| 14:18 |
Bmagic |
yep - lots of hidden "gems" in there |
| 14:18 |
dluch |
#action Everyone will test the Antora server and email the DIG list (or IRC) with problems (or suggestions). |
| 14:18 |
alynn26 |
Home icon needs updating. If you click on it it goes to the "it's powered by Antora". |
| 14:19 |
remingtron |
alynn26++ #testing! |
| 14:19 |
Bmagic |
lol |
| 14:19 |
Bmagic |
I threw that page on there in the very very beginning |
| 14:19 |
dluch |
Good find, lol |
| 14:22 |
tkatie217 |
+remingtron that would make sense :) |
| 14:22 |
alynn26 |
I think it does, if you check out the Glossary it says Glossary. |
| 14:23 |
sandbergja |
alynn26: I think the glossary looks so cool in antora. :-) |
| 14:23 |
dluch |
navlabels++ :-D |
| 14:23 |
dluch |
Okay, everyone keep up the good testing! Let's move on |
| 14:23 |
tkatie217 |
+1 to glossary! gorgeous! |
| 14:24 |
dluch |
+1 The glossary really is awesome |
| 14:24 |
dluch |
#info Update on Documentation server move |
| 14:24 |
alynn26 |
I do have an update to the Glossary, With a few additional features. Here is my testing Gist: https://gist.github.com/alynn26/072bcda581fead021eab2f079dd49e82 |
| 14:24 |
dluch |
It doesn't look like rsoulliere is here right now...how's this going? |
| 14:25 |
dluch |
gmcharlt: how's this going? |
| 14:25 |
dluch |
alynn26++ |
| 17:07 |
|
mmorgan joined #evergreen |
| 17:09 |
|
jihpringle joined #evergreen |
| 17:12 |
|
mmorgan left #evergreen |
| 18:01 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 18:13 |
|
stephengwills left #evergreen |
| 18:24 |
|
khuckins joined #evergreen |
| 20:18 |
|
sandbergja joined #evergreen |
| 02:12 |
|
sandbergja joined #evergreen |
| 06:00 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 07:02 |
|
agoben joined #evergreen |
| 07:10 |
|
rjackson_isl joined #evergreen |
| 07:47 |
|
rfrasur joined #evergreen |
| 10:46 |
csharp |
so... I spent an additional 3 hours re-upgrading to 9.6 and we're now live on that with no issues |
| 10:47 |
csharp |
planning to gather details for a bug report ASAP, but no one should upgrade to PG 10 until there's a very close look at our SQL |
| 10:49 |
berick |
csharp++ pines++ # trailblazing |
| 10:51 |
csharp |
sooo glad I did the postgres upgrade outside of the EG upgrade window next weekend |
| 10:51 |
csharp |
that would have been hell to untangle |
| 10:56 |
csharp |
the most frustrating part of the ordeal is that we've been testing 3.4 on PG 10 for *months* and have not noticed the issue at all |
| 10:57 |
csharp |
I didn't explicitly run PG unit tests, so possible it would have emerged there |
| 10:57 |
dbs |
csharp++ # thank you for taking that bullet for the rest of us |
| 10:58 |
* csharp |
tips his hat |
| 11:10 |
|
sandbergja joined #evergreen |
| 12:36 |
Bmagic |
can "@code='a' or @code='t'" become "@code='a' AND @code='t'" |
| 12:51 |
|
Dyrcona joined #evergreen |
| 12:59 |
|
collum joined #evergreen |
| 13:11 |
Dyrcona |
csharp: That Pg 10 thing is a known issue, and we have fixed all of the functions that have turned up in testing. Doesn't mean we haven't missed some. Fixes may also not have been backported. |
| 13:19 |
Dyrcona |
Bmagic: Do you want only fields with both the subfield a and t to show up? |
| 13:20 |
Bmagic |
Dyrcona: sure, and I could make an additional definition for just one of them (at another time) |
| 13:20 |
* dbs |
was wondering if the PG10 thing was a difference between the experience of upgrading and a fresh install |
| 13:22 |
Dyrcona |
PG11 and PG12 also seem ok in my very limited tire kicking. |
| 13:22 |
dbs |
Right, I would expect a fresh install to work. But it's the upgrading of an existing system that might be tricky |
| 13:23 |
Dyrcona |
Yeahp. I'm not sure we've made it very clear what functions you have to replace, either. |
| 13:23 |
Bmagic |
Dyrcona: Simple enough. But will the entry be the two fields concatenated? A la metabib.browse_entry.value. - I was planning on setting this up on a test server and trying it out, so no worries |
| 13:23 |
Bmagic |
dbs: I agree, I think it's the upgrade |
| 13:24 |
Dyrcona |
I know it's the upgrade. :) |
| 13:24 |
Bmagic |
:) |
| 13:50 |
Dyrcona |
csharp: https://bugs.launchpad.net/evergreen/+bug/1820339 |
| 13:50 |
pinesol |
Launchpad bug 1820339 in Evergreen "Postgres 10 support: Vandelay Edition" [Medium,Fix released] |
| 13:51 |
Dyrcona |
But, yeah.... |
| 13:51 |
JBoyer |
Speaking of bug numbers, if anyone wanted to test bug 1858701 it's real simple and can lead to some really confusing error messages. |
| 13:51 |
pinesol |
Launchpad bug 1858701 in Evergreen "URL modification with regular expressions can lead to 403 Forbidden errors" [Undecided,New] https://launchpad.net/bugs/1858701 |
| 13:51 |
JBoyer |
well, unexpected, anyway. |
| 13:52 |
jeff |
Is anyone here aware of useful workflows for inspecting items on/after checkin, inspecting for missing pieces before capturing for a hold or re-shelving them? |
| 13:54 |
jeff |
(or use a dedicated workstation where it's "normally on", etc) |
| 13:55 |
jeff |
Other options include "suppress holds and transits" on the initial checkin. Similar issue there: need to turn it on/off, not simple to "oops, scratch that!" if you forget and capture something to available-for-pickup. |
| 13:56 |
jeff |
Persistent copy alerts with a next-status on checkin are... almost it? I don't think the workflow/features are quite there, but it's potentially promising. |
| 13:56 |
JBoyer |
csharp: yeah, that should be fine. The PG10 changes were tested to be compatible with at least 9.6 (no reason they shouldn't be fine farther back as well) |
| 13:57 |
JBoyer |
But farther back doesn't matter since you can't upgrade to that point without 9.6+ anyway, so it's good. ;) |
| 13:58 |
csharp |
right |
| 13:59 |
csharp |
I think I made the right 1:00 a.m. call :-) |
| 17:28 |
berick |
Bmagic: string-join((//marc:datafield[@tag='810']/marc:subfield[@code='a'], //marc:datafield[@tag='810']/marc:subfield[@code='t']), " ") |
| 17:29 |
Bmagic |
berick++ |
| 18:00 |
Bmagic |
I'm calling this a bust. But FYI, the string-join and concat functions (with parentheses in the right places) still throw an error during ingest "invalid XPath expression" function metabib.reingest_metabib_field_entries(bigint,boolean,boolean,boolean,boolean,integer[]) line 49 at FOR over SELECT rows |
| 18:00 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 18:04 |
|
sandbergja_ joined #evergreen |
| 19:12 |
|
cmalm joined #evergreen |
| 19:39 |
|
sandbergja_ joined #evergreen |
| 00:12 |
|
sandbergja joined #evergreen |
| 06:02 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 06:38 |
|
agoben joined #evergreen |
| 07:08 |
|
rjackson_isl joined #evergreen |
| 07:34 |
|
csharp joined #evergreen |
| 08:13 |
|
Dyrcona joined #evergreen |
| 08:27 |
csharp |
dbs: either Terran (out today) or I can help with carousel setup - that was early November, so I'm a bit rusty, but we definitely have it running the way we want on a test server |
| 08:28 |
csharp |
we have an office open house this morning and I'm kind of here and there all day, but I'll check in to see if you have a question/issue I might be able to help save time on |
| 08:48 |
|
mmorgan joined #evergreen |
| 08:50 |
|
mantis1 joined #evergreen |
| 08:50 |
Dyrcona |
Ah, well. I guess yesterday's test was a bust. The log settings filled the 30GB of space available in / on my test vm. |
| 08:52 |
Dyrcona |
Amazingly, it didn't crash. |
| 08:57 |
Dyrcona |
Same data as production, though, and from what I can tell, the same patron was causing a problem. |
| 08:58 |
JBoyer |
logs cranked up to debug I suppose? |
| 09:01 |
Dyrcona |
Well, actually, I truncated it to 0, rather than rm it. |
| 09:02 |
JBoyer |
I suppose if it's a single patron that causes the issue you could invalidate a bunch of the events and just reset the biggest groupings, maybe it will fail faster? (OR it won't fail at all because Heisenbugs) |
| 09:06 |
Dyrcona |
If I leave the problem patron's events in collected state and set the other collected events t pending, the others succeed. |
| 09:06 |
Dyrcona |
I was just trying to confirm on my test sever what I concluded in bug 1858471, though I started before I filed the bug. |
| 09:07 |
pinesol |
Launchpad bug 1858471 in Evergreen "Events with large amount of data can crash action_trigger_runner.pl" [Undecided,New] https://launchpad.net/bugs/1858471 |
| 09:09 |
Dyrcona |
Turns out that I didn't need the debug log level to see what the problem. |
| 09:09 |
JBoyer |
Ah, right. I see it in there now. (the 3037383 byte message line) |
| 10:32 |
|
mantis2 joined #evergreen |
| 11:16 |
mmorgan |
Could an upgrade from 3.2.8 to 3.3.5 disrupt printer settings in the web client? |
| 11:18 |
mmorgan |
We've had reports of lost margin settings for receipt printer and inability to print to same. |
| 11:26 |
csharp |
mmorgan: we're testing 3.4 and have an issue report concerning receipt printing not working correctly |
| 11:26 |
csharp |
"From ARL: Chrome; hold slip did not automatically print or give the option to print on some computers, even with Auto-Print modifier on check-in screen. For the ones that did, format did not reflect the 4 letters last name - 4 digits card format. ---> (Note that they probably didn't have their custom print templates installed on their testing workstations)" |
| 11:27 |
csharp |
the parenthetical part was probably from Terran explaining what she thinks caused part of the issue |
| 11:27 |
csharp |
two of our staff here confirmed the issue, but I haven't looked closely yet |
| 11:28 |
csharp |
she thinks bug 1858118 is possibly related, so we've applied that fix to the test server and haven't had a chance to test |
| 11:28 |
pinesol |
Launchpad bug 1858118 in Evergreen "AngJS Always Tries To Use Hatch For Printing" [Critical,Fix committed] https://launchpad.net/bugs/1858118 |
| 11:30 |
* dbs |
wonders if his is the first site on 3.4 in production |
| 11:31 |
dbs |
If printing via Hatch, berick's suggestion of applying printer settings to each kind of printer (not just Default and Label) resolved some problems for us |
| 17:41 |
Bmagic |
@later tell mmorgan: sure |
| 17:41 |
pinesol |
Bmagic: The operation succeeded. |
| 17:59 |
dbs |
Bmagic: Yes, I get it. If a library only copy catalogued from a single source ever, sure. Or maybe if every library used UUIDs for their 001 to (probably) avoid conflicts |
| 18:00 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 18:00 |
dbs |
That said, if someone wants to search for an OCLC number, identifier|oclcnum: works really well if the 001 and 003 identify that it comes from OCLC, and then gets moved predictably into 035 as (OCoLC)######### |
| 18:02 |
dbs |
But that would require searching the regular catalogue separately from Z39.50. (I don't think OCLC puts (OCoLC)######## into their own 035) |
| 18:28 |
dbs |
Also found out today that either the Norton Safe Web or IBM Trusteer Rapport extensions for Chrome subtly break the web staff client (symptom: trying to open the Reports interfac results in an ACTOR_USR_NOT_FOUND error dialogue, and console shows that an http translator call gets truncated) |
| 00:20 |
|
sandbergja joined #evergreen |
| 06:01 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 06:53 |
|
sandbergja joined #evergreen |
| 06:58 |
|
agoben joined #evergreen |
| 07:13 |
|
rjackson_isl joined #evergreen |
| 08:58 |
pinesol |
Launchpad bug 1781274 in Evergreen 3.4 "Web Client: Transactions Do Not Always Close When Bill Fully Paid" [Undecided,Confirmed] https://launchpad.net/bugs/1781274 |
| 09:23 |
|
yboston joined #evergreen |
| 09:32 |
|
jvwoolf joined #evergreen |
| 09:38 |
Dyrcona |
So, testing here at CW MARS indicates that the aged billing/payments feature breaks our reports. We're looking into possible resolutions on our end, including possibly deleting the code from our local branch. Expect a Lp bug for discussion to pop up soonish. |
| 09:39 |
Dyrcona |
I realize that it may be too late to modify the feature globally. |
| 09:42 |
JBoyer |
breaks how? And given the timing, I assume it's somehow causing end of year report problems? |
| 09:44 |
Dyrcona |
JBoyer: jamundson has the details, and I expect he'll summarize it on a Lp bug. We have some pretty sophisticated financial reports and we use a pretty aggressive timeline for aging circulations, 7 days, so I think it is more than end of year stuff. |
| 17:23 |
berick |
Bmagic: there's a Makefile.install target specifically for standalone DB servers |
| 17:24 |
Bmagic |
gotcha, I was reading it wrong I guess. |
| 17:24 |
berick |
postgres-server-ubuntu-xenial, postgres-server-ubuntu-xenial-10, etc. |
| 18:00 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 18:30 |
|
csharp joined #evergreen |
| 19:50 |
|
jvwoolf joined #evergreen |
| 20:21 |
dbs |
Trying to create a carousel for the first time. Gave myself the ADMIN_CAROUSEL and ADMIN_CAROUSEL_TYPE permissions, clicked New Carousel, filled out the fields for a Newly Cataloged carousel, and |
| 06:00 |
|
Bmagic joined #evergreen |
| 06:01 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 06:34 |
|
agoben joined #evergreen |
| 07:06 |
|
rjackson_isl joined #evergreen |
| 07:27 |
|
rfrasur joined #evergreen |
| 12:25 |
jeff |
SELECT first_given_name, ... seventh_given_name FROM actor.org_unit... |
| 12:26 |
berick |
alter table actor.usr rename column super_user to is_protector_of_the_realm; |
| 12:26 |
|
sandbergja joined #evergreen |
| 12:28 |
mmorgan |
dbs: Did your checkout with duration 168:00:00 give you the correct due date/time? |
| 12:29 |
* mmorgan |
is attempting to test and is getting a due date/time of 2020-01-10 23:59:59-05 |
| 12:29 |
jeff |
berick++ |
| 12:41 |
dbs |
mmorgan: let me double check |
| 12:41 |
dbs |
on the long-name issue, I opened bug # 1858225 (and included a screenshot, although not nearly as fun as bshum's yodawg) |
| 12:41 |
* mmorgan |
is testing on a 3.4.1 system |
| 12:42 |
dbs |
mmorgan: I had checked in the staff client and the checkout gave a due date of 2020-01-10 for our 168:00:00, I'll check in the database for the specific time |
| 12:43 |
|
mantis2 joined #evergreen |
| 12:45 |
|
mantis1 joined #evergreen |
| 14:03 |
Dyrcona |
Is the order of the id column in the actor.org_unit_custom_tree_node table important? We want to add 2 new org_units and we had trouble with the admin interface on training, so I thought that I'd do the update in the database. |
| 14:07 |
berick |
Dyrcona: I haven't confirmed, but given the sibling_order column, I would expect the ID to be generally ignored. |
| 14:08 |
|
collum joined #evergreen |
| 14:08 |
Dyrcona |
berick: That's my assumption, too. I'll test this on a vm before I do it in production. Thanks! |
| 14:10 |
Dyrcona |
I asked because it looks like the table is rebuilt more or less in order every time it is updated via the staff client. |
| 14:14 |
dbs |
mmorgan++ # thank you |
| 14:29 |
Dyrcona |
berick: Seems to work. |
| 17:01 |
|
mmorgan left #evergreen |
| 17:04 |
|
sandbergja joined #evergreen |
| 17:37 |
jeffdavis |
Are there any circumstances where it is correct for a circ to remain open (xact_finish is null) when the circ has a checkin time and there is no balance owed? |
| 18:01 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 18:12 |
|
dbwells_ joined #evergreen |
| 18:23 |
|
yar joined #evergreen |
| 19:07 |
|
cmalm joined #evergreen |
| 01:25 |
|
sandbergja joined #evergreen |
| 05:45 |
|
awitter joined #evergreen |
| 06:01 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 06:38 |
|
agoben joined #evergreen |
| 07:05 |
|
rjackson_isl joined #evergreen |
| 07:22 |
|
rfrasur joined #evergreen |
| 09:11 |
Dyrcona |
Well, I wasn't think of that specifically, but it would cause problems. I just thought maybe somebody changed something and autogen.sh wasn't run. |
| 09:13 |
Dyrcona |
Otherwise, I'm not sure why this would suddenly start happening, unless some service needs a restart/crashed. |
| 09:14 |
Dyrcona |
Maybe a corrupted fm_IDL somewhere? Disk issue? |
| 09:15 |
Dyrcona |
I should focus on the test that I'm setting up. I just made a mistake in the crontab that's part of the test. |
| 09:15 |
dbs |
Dyrcona: yes, focus on your stuff, I've got this working-ish for now |
| 09:19 |
Dyrcona |
Well, the mistake was no big deal, I just forgot to add some options and the &>> redirect on the run-pending runner. |
| 09:20 |
Dyrcona |
I'm trying to emulate production, though I think my main problem is just the number of events we're processing. |
| 10:30 |
Dyrcona |
berick: I'm seeing other events get stuck in collected state in production. I don't my problem necessarily has anything to do with chained events. I've got a coupe of 28 day mark lost events that are in collected state. I think I need to get down to the reason for the jabber client disconnections. |
| 10:31 |
berick |
Dyrcona: well mark lost is another chained A/T |
| 10:31 |
berick |
did you see any improvement in the autorenew after the patch? |
| 10:32 |
Dyrcona |
Well, maybe, they didn't blow up on a test server, but our 2-day courtesy notices did. |
| 10:32 |
Dyrcona |
I'm doing a more thorough test today with a bunch of things emulating production. |
| 10:32 |
Dyrcona |
I have the same, but more, data on a slower machine and slower db server. |
| 10:33 |
berick |
well, i can't comment on the predues, but if the patch fixes autorenew, then a similar patch might help mark-lost |
| 10:35 |
Dyrcona |
berick: OK, I'll take a look. I'm not running those on this test. |
| 10:36 |
Dyrcona |
Also, is anyone else having to fix dates in your manually entered db queries this morning? I'm still typing 2019. :) |
| 10:38 |
* mmorgan |
hasn't had occasion to type a date yet, but 2020 does look odd down in the corner of my computer screen :) |
| 10:45 |
Dyrcona |
:) |
| 13:41 |
Dyrcona |
I thought OpenSRF had an error message for that, but I'm not finding it. |
| 13:41 |
|
cmalm joined #evergreen |
| 13:43 |
|
jihpringle joined #evergreen |
| 13:53 |
dbs |
yay, over on our test server getting "egCore.hatch.getWorkstations is not a function" console error at the web staff client login prompt. and getWorkstations() is clearly defined in eg2/src/app/core/store.service.ts - sigh |
| 13:53 |
dbs |
at least it's our test server. |
| 13:54 |
berick |
dbs: one of those is eg2, one is eg. |
| 13:54 |
Dyrcona |
Aint' web development fun? |
| 13:55 |
Dyrcona |
Ain't software development fun? |
| 14:52 |
Dyrcona |
:) |
| 14:53 |
dbs |
Dyrcona: did not know about the "Empty Cache and Hard Reload" option! |
| 14:54 |
Dyrcona |
It's only there in Chrome with the dev tools enabled. |
| 14:54 |
Dyrcona |
I find it very handy when testing. |
| 15:02 |
|
mmorgan1 joined #evergreen |
| 15:07 |
dbs |
I guess we should document this expectation for now, and then work on fixing it so it's no longer necessary? |
| 15:09 |
|
jvwoolf joined #evergreen |
| 16:51 |
pinesol |
Launchpad bug 1858118 in Evergreen "AngJS Always Tries To Use Hatch For Printing" [Critical,New] |
| 16:52 |
mmorgan |
Okay, thanks! |
| 17:04 |
|
mmorgan left #evergreen |
| 18:01 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 18:02 |
|
sandbergja joined #evergreen |
| 18:19 |
|
abowling1 joined #evergreen |
| 18:21 |
|
sandbergja joined #evergreen |
| 13:12 |
* Dyrcona |
is a bit slow in the brainbox today. |
| 13:18 |
Dyrcona |
So, it looks like 26,445 courtesy notices got stuck in 'collected' this morning. |
| 13:18 |
Dyrcona |
I'll update them to pending in production and see what happens in about 10 minutes. |
| 13:21 |
Dyrcona |
Looks production has about half as many as my test system. I suppose the difference are the ones that were checked in between midnight Sunday and this morning. |
| 13:21 |
Dyrcona |
Well, midnight Saturday to Sunday. |
| 13:22 |
Dyrcona |
Looks like the 10,694 autorenewal and notice events processed OK. |
| 13:41 |
Dyrcona |
Hmm. The generic run pending did not pick them up. |
| 14:34 |
Dyrcona |
So, there's an interplay going on here. The daily a/t runner creates the autorenewal notice events but our twice hourly run-pending runner runs them. Could it be a timing issue? |
| 14:35 |
Dyrcona |
Seems like I've had parts of this monologue before... |
| 14:44 |
|
khuckins joined #evergreen |
| 14:46 |
Dyrcona |
So, test for Thursday morning: start Daily-PD-2, then start daily, then run a generic run-pending every half hour or so. |
| 14:46 |
Dyrcona |
With --verbose and --debug-stdout on all three. |
| 16:01 |
|
sandbergja joined #evergreen |
| 16:38 |
|
book` joined #evergreen |
