| 06:01 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 07:04 |
|
rjackson_isl joined #evergreen |
| 08:39 |
|
mmorgan joined #evergreen |
| 09:01 |
|
mantis1 joined #evergreen |
| 10:31 |
berick |
might be worth teaching them to wait for the response from their open-ils.trigger.event.autocreate calls |
| 10:34 |
pastebot |
"berick" at 168.25.130.30 pasted "AutoRenew.pm waits for event creation" (23 lines) at http://paste.evergreen-ils.org/10117 |
| 10:34 |
berick |
something like that ^- |
| 10:35 |
Dyrcona |
I can try that, but I've almost never had this happen on a test environment. |
| 10:37 |
mmorgan |
fwiw, I'm not seeing the same issues as Dyrcona, but the highest number of autorenewal events we've had in a day is just under 7000 |
| 10:38 |
Dyrcona |
mmorgan: Get that many on a slow day. :) |
| 10:42 |
Dyrcona |
Meh.... lineendings-- |
| 10:45 |
Dyrcona |
I have a script to fix PO JEDI issues. |
| 10:46 |
Dyrcona |
I think A/T is the wrong mechanism for some of these things. If it is something that should be generated regularly a plain old cron job should do it. |
| 10:47 |
Dyrcona |
I can see A/T for things triggered by user actions, like PO JEDI, for instance. |
| 10:48 |
Dyrcona |
I'm going to run a daily action trigger runner on a test vm with --verbose and --debug-stdout |
| 10:50 |
berick |
A/T jedi's been replaced, of course. /me still needs to make that migration |
| 10:50 |
Dyrcona |
Um, yeah, I guess it has. :) |
| 10:50 |
Dyrcona |
We were testing the replacement, but lost the configuration when I refreshed the training database. |
| 10:56 |
Dyrcona |
I imagine that this will take a few hours. |
| 10:56 |
Dyrcona |
I should test it again on Thursday. |
| 10:59 |
Dyrcona |
I'm running it with berick's patch, I suppose I should run it without and then with.... |
| 11:00 |
Dyrcona |
So far, though, nothing has blown up. :) |
| 11:01 |
Dyrcona |
Or, maybe it has. syslog hasn't changed in about 6 minutes. |
| 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. |
| 06:01 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 07:07 |
|
rjackson_isl joined #evergreen |
| 08:07 |
|
stephengwills joined #evergreen |
| 08:22 |
|
stephengwills joined #evergreen |
| 14:45 |
dbs |
Well, I just installed the 8 different add-ons I use in Firefox into a clean FF profile and can't trigger the error |
| 14:46 |
dbs |
(Bitwarden, Cookie Autodelete, EZProxy Redirect Foxified, Firefox Multi-Account Containers, GNOME Shell integration, Grammalecte[fr], uBlock Origin, and Zotero Connector) |
| 14:48 |
Dyrcona |
Of those, I use GNOME Shell Integration and uBlock Origin. |
| 14:50 |
dbs |
was inspecting the stored user preferences under Administration -> Workstation but I don't really see how that would make a difference |
| 14:51 |
dbs |
ah well, hopefully it's just something weird & truly unique with this workstation |
| 14:53 |
|
khuckins joined #evergreen |
| 15:18 |
dbs |
oh man. so I'm using Container Tabs in Firefox, and had been testing in a Work container tab |
| 15:18 |
dbs |
for "fun", I created a new container tab called "Testing" and used that to register a new workstation and test MARC Batch Edit |
| 15:19 |
dbs |
and of course it shows all of my record buckets (also called containers, just to confuse things further with overlapping terminology) |
| 15:21 |
dbs |
so... somehow the workstation inside one particular category of container tabs gets that XHR response wrong unless I use network tools to disable caching |
| 15:21 |
dbs |
and I can't reproduce it even within the same browser (as Firefox containers separate cookies & localstorage, etc, from other containers) |
| 15:22 |
Dyrcona |
So, don't do that? |
| 15:24 |
jeff |
i remain intrigued. it sounds like there isn't a reliable way to reproduce the issue? |
| 15:25 |
jeff |
but the nature of the oddness is... puzzling. |
| 15:38 |
Dyrcona |
OK. Fair enough. I was thinking maybe don't use the container tabs. |
| 15:38 |
dbs |
jeff: yeah, I've tried matching up as many configuration bits as I can and can't reproduce it outside of this one container |
| 16:21 |
|
sandbergja joined #evergreen |
| 16:47 |
pinesol |
News from qatests: Failed Installing OpenSRF pre-requisites <http://testing.evergreen-ils.org/~live//archive/2019-12/2019-12-30_16:00:03/test.7.html> |
| 17:06 |
|
mmorgan left #evergreen |
| 17:15 |
pinesol |
[evergreen|Mike Risher] lp1855931 wrap text for wide Angular eg-grid column headers - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=fe8a465> |
| 17:15 |
pinesol |
[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> |
| 17:17 |
|
berick joined #evergreen |
| 17:48 |
Bmagic |
for small Evergreen patches that introduce a new row into a table, is a pgtap test required? To test that the row exists? |
| 17:49 |
Bmagic |
(Example: AutoRenew patch did not have a pgTAP to test AT hook row) |
| 17:51 |
pinesol |
[evergreen|lfloyd] DOCS: LP 1767378 Work Log documentation - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=8296e8c> |
| 17:51 |
pinesol |
[evergreen|lfloyd] Docs: fixed a spacing issue - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=593a93a> |
| 17:51 |
pinesol |
[evergreen|Jane Sandberg] Docs: LP1767378 follow up: adding manual anchor - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=7ac78d5> |
| 17:51 |
pinesol |
[evergreen|Jane Sandberg] Docs: Fixing asciidoc syntax so fop doesn't complain about staff client admin manual - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=2cd4053> |
| 18:07 |
Dyrcona |
Bmagic: Well, obviously, we don't require a test for that, but adding a test would be highly encouraged, at least by me. |
| 18:08 |
Dyrcona |
Retroactively adding tests for the auto-renew feature would make a decent, bite sized bug. Perhaps I'll open one tomorrow. |
| 18:16 |
Dyrcona |
Anyway, I should have signed out a while ago. Catch you all again, tomorrow! |
| 18:41 |
|
abowling1 joined #evergreen |
| 18:59 |
|
abowling joined #evergreen |
| 02:26 |
|
cmalm joined #evergreen |
| 02:51 |
|
cmalm joined #evergreen |
| 02:59 |
|
cmalm joined #evergreen |
| 06:01 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 07:20 |
|
abowling1 joined #evergreen |
| 07:28 |
|
sandbergja joined #evergreen |
| 07:51 |
|
sandbergja joined #evergreen |
| 14:25 |
|
sandbergja joined #evergreen |
| 15:02 |
|
sandbergja joined #evergreen |
| 15:09 |
|
cmalm joined #evergreen |
| 18:01 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 22:16 |
dbs |
Getting a weird thing on rel_3_4 in MARC Batch Edit where the containers aren't being fetched for the requested user because the open-ils.actor.container.retrieve_by_class.authoritative returns ACTOR_USER_NOT_FOUND |
| 22:19 |
dbs |
But if I disable cache and reload the page, the request succeeds. Weird thing is the requests are almost identical, except for the user ID |
| 22:20 |
dbs |
in the cache-enabled mode, the user ID is actually the aou ID for the workstation (or possibly the home OU of the user), whereas in the cache-disabled mode it's the expected user's ID |
| 00:29 |
|
sandbergja_ joined #evergreen |
| 02:48 |
|
sandbergja_ joined #evergreen |
| 03:15 |
|
sandbergja_ joined #evergreen |
| 06:00 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 06:39 |
|
agoben joined #evergreen |
| 08:33 |
|
Dyrcona joined #evergreen |
| 08:42 |
|
mantis1 joined #evergreen |
| 09:40 |
rfrasur |
dbs: congratulations!! |
| 11:13 |
jeffdavis |
This article claims to have an improved algorithm for sorting LC call numbers: https://ejournals.bc.edu/index.php/ital/article/view/11585 |
| 11:14 |
jeffdavis |
It specifically mentions shortcomings of library-callnumber-lc, which appears to be what EG uses |
| 11:19 |
dbs |
Although it lists the Perl version in the table, the text only mentions the Python version. So... unsure. |
| 11:20 |
|
drigney joined #evergreen |
| 11:20 |
|
miker joined #evergreen |
| 11:21 |
|
alynn26 joined #evergreen |
| 11:23 |
dbs |
Would have been nice if they had contributed some failing tests to library-callnumber-lc so it could be fixed! |
| 11:23 |
* dbs |
also notes that https://github.com/scodepress/shelfreader/tree/master/tests doesn't have any real tests |
| 11:27 |
dbs |
they also could have credited Dan Wells and Bill Dueber instead of "Library Hackers" given the copyright statement in https://github.com/libraryhackers/library-callnumber-lc/tree/master/perl/Library-CallNumber-LC/README |
| 12:17 |
|
Christineb joined #evergreen |
| 12:27 |
|
sandbergja_ joined #evergreen |
| 12:29 |
|
miker joined #evergreen |
| 13:14 |
|
jweston joined #evergreen |
| 13:21 |
|
agoben joined #evergreen |
| 13:49 |
|
sandbergja_ joined #evergreen |
| 14:34 |
dbs |
Hmm. Except now to figure out why trying to save an edited record turns up a "Failed to save record: {{error}}" message |
| 14:43 |
|
remingtron_ joined #evergreen |
| 14:43 |
dbs |
Found an issue with the database schema by checking the logs. |
| 15:48 |
|
mantis1 left #evergreen |
| 15:53 |
dbs |
Next challenge: figuring out why I only see the leader of a record when I try "Edit and import" in the Z39.50 import screen, but I can click Import and then go to the record to edit the full thing |
| 15:54 |
dbs |
(and I do have bug # 1830923 in my branch, which is tracking current rel_3_4) |
| 15:54 |
Dyrcona |
bug 1830923 |
| 15:54 |
pinesol |
Launchpad bug 1830923 in Evergreen 3.3 "MARC import lacks ability to view and edit incoming MARC record" [High,Fix committed] https://launchpad.net/bugs/1830923 |
| 15:55 |
Dyrcona |
We have 3.4.1 on a training system, but I don't know if anyone has attempted any cataloging yet. |
| 15:59 |
Dyrcona |
dbs: You're running Pg 9.6 on the database server? |
| 15:59 |
dbs |
Dyrcona: yep |
| 16:00 |
dbs |
Strange thing is, on our testing system which only has commits up to end of November (thus missing the commits that were supposed to resolve # 1830923)... Edit then Import works |
| 16:07 |
Dyrcona |
OK. We're on 3.4.1, so only up to the end of October. |
| 16:08 |
* Dyrcona |
prepares to head out for the day. |
| 16:09 |
dbs |
Have a good one! |
| 16:09 |
Dyrcona |
You, too. Hope you figure this out. |
| 16:32 |
|
jvwoolf left #evergreen |
| 17:05 |
|
sandbergja_ joined #evergreen |
| 18:00 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 18:17 |
|
abowling1 joined #evergreen |
| 18:33 |
|
abowling joined #evergreen |
| 20:17 |
|
phasefx_ joined #evergreen |
| 06:00 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 06:53 |
|
remingtron_ joined #evergreen |
| 06:58 |
|
agoben joined #evergreen |
| 07:02 |
|
rfrasur joined #evergreen |
| 10:20 |
nfBurton |
Just click on the top nav bar before hitting the hotkey. We are just finishing RFID enabling our library with PV Supa products |
| 10:20 |
jeff |
yes, galen had a candidate fix for that which I was looking at the other day, as part of bug 1437106 |
| 10:20 |
pinesol |
Launchpad bug 1437106 in Evergreen "keyboard shortcuts in the web staff client" [Undecided,Confirmed] https://launchpad.net/bugs/1437106 |
| 10:21 |
jeff |
and yes, there is the "just click a menu / navbar area before pressing the hotkey" workaround, but I would like to work to make that no longer necessary. |
| 10:22 |
jeff |
mostly because it fails my absurdity test. i feel absurd telling someone about the required workaround. :-) |
| 10:22 |
Dyrcona |
If you want "hot keys" for everything, you don't want a browser-based application, just repeatin' myself, I know..... |
| 10:22 |
dbs |
nfBurton: right, the issue here is that the Bibliotheca software wants F1 / F2 for its own use, but the web staff client is trapping them first |
| 10:23 |
Dyrcona |
Actually, you probably want a GNU Emacs mode. :) |
| 17:18 |
Dyrcona |
:) |
| 17:37 |
|
sandbergja_ joined #evergreen |
| 17:38 |
|
abowling left #evergreen |
| 18:00 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 20:06 |
|
Dyrcona joined #evergreen |
| 21:33 |
* dbs |
is so happy to see people talking about password resets |
| 21:34 |
dbs |
Oh, for the logs, i was able to resolve the Bibliotheca SmartStation "how do we get the barcodes into the web staff client?" issue |
| 00:44 |
|
sandbergja_ joined #evergreen |
| 04:19 |
|
serflog joined #evergreen |
| 04:19 |
|
Topic for #evergreen is now Welcome to the #evergreen library system channel! | We are publicly logged: http://irc.evergreen-ils.org/evergreen | Large pastes at http://paste.evergreen-ils.org | Can't speak? Make sure your nickname is registered and that you are identified to freenode services: https://freenode.net/kb/answer/registration |
| 06:00 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 06:56 |
|
agoben joined #evergreen |
| 07:11 |
|
Dyrcona joined #evergreen |
| 08:02 |
|
rfrasur joined #evergreen |
| 08:13 |
rhamby |
every day qa tests succeed a non-denominational spirit entity gets it's wings |
| 08:13 |
alynn26 |
lol |
| 08:15 |
|
rjackson-isl-hom joined #evergreen |
| 08:17 |
|
mantis1 joined #evergreen |
| 14:16 |
jeff |
blongwel: were the items checked in with the checkin modifier to retarget local holds? were the transits to another library, or to the checkin library (a la "capture local holds as transits")? |
| 14:16 |
jeff |
blongwel: and, what version of Evergreen? |
| 14:25 |
Dyrcona |
I'm pretty sure there's a Lp bug for this already, but damned if I can find it: I just encountered a situation where paying off bills on 8 circulations set xact_finish on all but 1 of the transactions, and they were all renewed just before paying the bills. |
| 14:28 |
Dyrcona |
Renewal actually generated the bills, since I haven't run the fine generator on this test system. |
| 14:33 |
jeff |
doesn't ring a bell. anything (else) unusual about the one transaction? |
| 14:34 |
jeff |
renewal operation completed before the bills were paid? |
| 14:34 |
jeff |
fine generation on checkin (renewal) doesn't kick off anything async in the background, does it? |
| 14:58 |
Dyrcona |
blongwel: I don't think the hold_targeter is at issue, though it might be. We run ours every 15 minutes. |
| 14:58 |
Dyrcona |
mmorgan++ I knew there had to be a bug, but Lp search is terrible. |
| 14:58 |
mmorgan |
I run across that occasionally, too, usually comes to light when staff try and delete a patron record. |
| 15:02 |
Dyrcona |
Well, I found it while looking into a previous patron's circulation being aged for an item after it was renewed to the current patron. I had data from before and was seeing what happened on my test system, so thought I'd "pay" the bills, too. |
| 15:02 |
Dyrcona |
And, I think what I was looking into could be considered a bug, depending on your perspective. |
| 15:02 |
|
mmorgan1 joined #evergreen |
| 15:04 |
Dyrcona |
It's bugs all the way down. :) |
| 16:39 |
|
khuckins joined #evergreen |
| 16:52 |
|
sandbergja_ joined #evergreen |
| 17:00 |
|
mmorgan left #evergreen |
| 18:00 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 18:06 |
|
Dyrcona joined #evergreen |
| 19:09 |
|
cmalm joined #evergreen |
| 19:39 |
|
csharp_ joined #evergreen |
| 05:10 |
|
dbs joined #evergreen |
| 05:10 |
|
berick joined #evergreen |
| 05:55 |
|
remingtron_ joined #evergreen |
| 06:00 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 07:12 |
|
rjackson_isl joined #evergreen |
| 07:19 |
|
rfrasur joined #evergreen |
| 08:41 |
|
mmorgan joined #evergreen |
| 14:17 |
|
khuckins joined #evergreen |
| 14:26 |
jeffdavis |
As much as I dislike npm, I don't know if it's substantially worse on security etc than any other tools/libraries that we use. |
| 14:27 |
Dyrcona |
I think it is worse than apt, but I have little proof. There's a real problem of trust, and I trust npm much less than I do apt. |
| 14:28 |
Dyrcona |
Also, I think I understand why chromium and firefox were added to the distro *-developer Makefile.install targets, but I'm not so sure I like that, either. If I'm installing via git in production, which I do, and I'm not gonna run tests, those packages are dead weight. |
| 14:29 |
Dyrcona |
Not to mention all of the dependencies on those packages. |
| 14:30 |
Dyrcona |
I guess that's yet-another-local-patch-branch to maintain..... |
| 14:37 |
Dyrcona |
I thought we jumped to Node v12 lately? Is that just in master? |
| 14:37 |
berick |
for ang8 |
| 14:37 |
Dyrcona |
berick++ # I was just about to compare 3.4.1 and master. |
| 14:41 |
Dyrcona |
Am I right that upgrading npm breaks the Evergreen install process? |
| 14:41 |
jeffdavis |
The browsers were added because they were the best alternative for running tests. There was some discussion about separating out a -tester target but you want devs to run tests; maybe there should be a -developer-minimal target or something instead to allow installing from git without the test stuff. |
| 14:43 |
Dyrcona |
jeffdavis: Yes, that's my understanding, and I didn't say much during the discussion. I'm not sure that I want a new dependency target, so I'll live with it for now. |
| 14:44 |
Dyrcona |
Hmm... could be a *-git target that is made a requirement of the *-developer targets..... |
| 15:39 |
|
gerlevi joined #evergreen |
| 15:58 |
|
jvwoolf joined #evergreen |
| 16:22 |
|
sandbergja_ joined #evergreen |
| 17:03 |
|
mmorgan left #evergreen |
| 18:00 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 22:13 |
|
cmalm joined #evergreen |
| 22:14 |
|
sandbergja_ joined #evergreen |
| 22:34 |
|
cmalm joined #evergreen |
| 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 |
| 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 |
| 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: |
| 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 |
| 00:33 |
|
sandbergja joined #evergreen |
| 00:45 |
|
sandbergja joined #evergreen |
| 02:14 |
|
sandbergja joined #evergreen |
| 06:01 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 06:54 |
|
agoben joined #evergreen |
| 07:07 |
|
rjackson_isl joined #evergreen |
| 07:22 |
|
rfrasur joined #evergreen |
| 11:15 |
miker |
mmorgan: and, finally, the reason for the change is that there was no real functional difference between sort on pop vs poprel because of the (lack of) scaling before application of the popularity addition. it was all popularity all the time for both, effectively |
| 11:15 |
mmorgan |
miker: Any processing needed after changing the global flag? |
| 11:21 |
* csharp |
confirms that installing from https://koji.fedoraproject.org/koji/buildinfo?buildID=1420745 solves the EG and extensions issues |
| 11:25 |
mmorgan |
I'm not seeing the effect of popularity I would expect. |
| 11:25 |
mmorgan |
I have a 3.2.9 Concerto system. My test search is a title search on symphony, result set is 5 hits. |
| 11:26 |
mmorgan |
I give the least relevant hit a popularity score of 5, (added directly in the db to rating.record_badge_score). Global flag search.max_popularity_importance_multiplier is set to the max at 2.0. |
| 11:27 |
miker |
mmorgan: you might need to restart services (storage in particular) |
| 11:27 |
mmorgan |
My record with the badge is #4 in the poprel sort. |
| 11:27 |
* mmorgan |
will restart. |
| 11:42 |
mmorgan |
jeff: The popularity score is the highest it can be. If it can't ever push that record higher, than 4 out of 5, then the popularity badge will always be ineffective. We noticed a significantly decreased effect of our popularity badges after upgrading to 3.1 |
| 11:42 |
Dyrcona |
Part of the troulbe that I had with systemd during out last update was the query to update action.aged_circulations filled up the log space on the replication db server. |
| 11:43 |
Bmagic |
That's the code I've created to do the job (sql file and bash sh file) |
| 11:43 |
Dyrcona |
Yeah, I'm not sure it needs to be so complicated. Have you tested it on a test db server? |
| 11:44 |
Bmagic |
It seems to be working, one of the bugs I found came when updating action.circulation rows with target_copy IDs that don't exist in asset.copy. Stemming from trigger fake_fkey_tgr() |
| 11:44 |
Bmagic |
Dyrcona: yep, it's purring like a kitten |
| 11:44 |
Bmagic |
and the server is functional wihle it's running. I can renew/circ/etc with no perceived slowness |
| 16:45 |
|
mmorgan joined #evergreen |
| 17:05 |
|
mmorgan left #evergreen |
| 17:36 |
|
rfrasur joined #evergreen |
| 18:02 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 18:25 |
|
Christineb joined #evergreen |
| 19:07 |
|
cmalm_ joined #evergreen |
| 19:33 |
|
rfrasur joined #evergreen |
| 01:14 |
|
sandbergja joined #evergreen |
| 01:58 |
|
sandbergja joined #evergreen |
| 06:01 |
pinesol |
News from qatests: Failed Installing Evergreen pre-requisites - Expected 1 errors but encountered 3. <http://testing.evergreen-ils.org/~live/test.26.html#2019-12-09T06:00:09,402632214-0500 -0> |
| 07:03 |
|
agoben joined #evergreen |
| 07:50 |
|
collum joined #evergreen |
| 07:59 |
|
mantis1 joined #evergreen |
| 09:05 |
Dyrcona |
Well, Chromium also works. :) |
| 09:05 |
csharp |
yeah :-) |
| 09:06 |
|
rfrasur joined #evergreen |
| 09:29 |
dbs |
csharp: I am indeed on F31 |
| 09:29 |
dbs |
Now trying to remember if I ran into this while I was testing on Windows, however... |
| 09:30 |
* dbs |
curses dbs_windows for not having reported back on that |
| 09:39 |
csharp |
heh |
| 09:39 |
JBoyer |
Quick data point: I tried FF 71 on macOS and did not run into the issue. |
| 09:39 |
csharp |
JBoyer: thanks for that confirmation |
| 09:40 |
* csharp |
went to start his Windows 10 VM only to realize the station he's on doesn't have one installed yet :-/ |
| 09:40 |
JBoyer |
So it looks Linux specific at the moment, which, while not great, really is the ideal situation if there *has* to be a problem. |
| 09:40 |
csharp |
JBoyer: agreed |
| 09:41 |
* JBoyer |
remembers he's standing right next to a Windows laptop, will test right now. |
| 09:42 |
csharp |
and Google Music Desktop Player also stopped working on Linux for me, so all the software is breaking |
| 09:42 |
csharp |
@who broke the softwares |
| 09:42 |
pinesol |
felicia broke the softwares. |
| 09:42 |
* mmorgan |
is having flashbacks to those mac dude vs. pc guy commercials |
| 09:45 |
JBoyer |
UGH. That old smushbox keyboard is like typing on bugs. |
| 09:46 |
JBoyer |
Anyway, FF 71 on Windows was fine. |
| 09:46 |
JBoyer |
I was testing on master, to double check, what server versions have you seen issues on? |
| 09:46 |
remingtron |
FF 71 on Windows also works fine for me (EG 3.3.1) |
| 09:51 |
csharp |
JBoyer++ remingtron++ # thanks for confirming |
| 10:00 |
|
mmorgan1 joined #evergreen |
| 12:58 |
csharp |
nothing in the audit.log with "deni" (case insensitive) |
| 12:58 |
* csharp |
remembers that dbs's alternate nick is denials :-) |
| 12:59 |
Dyrcona |
:) |
| 12:59 |
dbs |
mmm... https://fedoraproject.org/wiki/How_to_debug_Firefox_problems?rd=Bug_info_Firefox#Testing_Mozilla_binaries |
| 13:00 |
dbs |
could rule out packaging hijinks that way |
| 13:00 |
dbs |
FWIW I also saw no difference with SELinux disabled |
| 13:00 |
* dbs |
will commence downloading |
| 13:05 |
dbs |
hmm. initial testing suggests that the vanilla mozilla version of Firefox 71.0 is not affected |
| 13:06 |
dbs |
csharp++ # avoiding log alerts for me - so kind |
| 13:06 |
csharp |
dbs: ha! |
| 13:07 |
csharp |
dbs: very interesting - so this really must be a Fedora thing |
| 13:07 |
csharp |
@who lives in a Fedora bubble? |
| 13:07 |
pinesol |
rashma lives in a Fedora bubble. |
| 13:11 |
dbs |
however I also created a brand new firefox profile for this, so... |
| 13:13 |
dbs |
Hah! And using the same new profile as was created in vanilla FF 71.0 in Fedora's version of FF 71.0 triggers the bug |
| 13:13 |
dbs |
I think that's as smoking gun as we can get |
| 13:14 |
dbs |
Then the question is: how the heck do we build a minimal reproducible test case for the Fedorans? |
| 13:14 |
csharp |
hmmm |
| 13:14 |
csharp |
dbs++ # detective work |
| 13:20 |
JBoyer |
dbs++ |
| 15:46 |
Dyrcona |
:) |
| 16:39 |
|
yboston joined #evergreen |
| 17:07 |
|
mmorgan left #evergreen |
| 18:01 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 18:22 |
|
dbwells joined #evergreen |
| 18:51 |
|
rfrasur joined #evergreen |
| 21:14 |
|
sandbergja joined #evergreen |
| 09:53 |
Dyrcona |
Bmagic: We are. |
| 09:57 |
Dyrcona |
Bmagic: I'm not entirely sure if bug 1801163 applies. |
| 09:57 |
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) |
| 09:58 |
Dyrcona |
I'll check since I was about to update a test vm that's on 18.04 anyway. |
| 09:58 |
Bmagic |
at this point, 18.04 is still not "fully" functional an issue with Evergreen? |
| 09:59 |
Dyrcona |
Well, can we say we support a distro if Evergreen is not fully functional? |
| 09:59 |
Bmagic |
It's debatable I'm sure |
| 10:01 |
pinesol |
Launchpad bug 1855199 in Evergreen "Vandelay record queuing can fail if spool directory is /tmp" [Medium,Confirmed] https://launchpad.net/bugs/1855199 |
| 10:01 |
Bmagic |
If they did say that, I probably wouldn't have posed the question here |
| 10:02 |
berick |
that's the only 18.04 issue i've encountered on dev machines. of course, I'm not sending email |
| 10:02 |
pinesol |
News from qatests: Failed Building the AsciiDoc output formats <http://testing.evergreen-ils.org/~live/test.81.html#2019-12-06T09:38:30,140377482-0500 -0> |
| 10:02 |
Dyrcona |
Bmagic: I would say that Ubuntu 18.04 is affected by 1801163 give that Encode is version 2.88 and Encode::MIME::Header is 2.24. |
| 10:03 |
Dyrcona |
It also probably affects Debian Stretch and Buster. |
| 10:03 |
Bmagic |
what a bummer |
| 10:13 |
jeff |
I'll take a fresh look. |
| 10:13 |
Dyrcona |
Yeahp. I think you're right. |
| 10:13 |
Dyrcona |
About changing the templates. |
| 10:14 |
* dbs |
found that using the Cookie Autodelete extension in Firefox to greylist the test server hostname and then hitting the trash icon for the hostname (keeping localstorage and cookies) fixed the "Possibly unhandled rejection: {"isTrusted":true}" webby white screen problem |
| 10:14 |
Dyrcona |
There are a number of related wish list items on Launchpad that would require similarly radical changes. |
| 10:15 |
Dyrcona |
dbs: Good to know. I haven't encountered that issue switching from production to test/training servers. |
| 10:18 |
csharp |
we're happy to reconfigure our (many) templates if it keeps us from chasing our tail in the future (fwiw) |
| 10:19 |
* jeff |
nods |
| 10:21 |
Dyrcona |
csharp | jeff: same here. |
| 12:16 |
|
gsams joined #evergreen |
| 12:44 |
|
dbwells joined #evergreen |
| 13:14 |
berick |
tried to recreate the DataCloneError in FF 70 on master, no dice. pleased to see FF shows shared worker logs along with the main page logs. |
| 13:15 |
Dyrcona |
berick: I was just getting ready to test it. |
| 13:16 |
Dyrcona |
Except I got an Internal Server Error, so I probably have something broken on my vm. |
| 13:18 |
Dyrcona |
I think my problem is ejabberd. |
| 13:20 |
Dyrcona |
Cannot connect to server public.localhost: Connection refused |
| 16:13 |
mmorgan |
Anyone know why that factor of 1000 was introduced? |
| 16:16 |
rhamby |
I have a flippant desire to say because 999 just didn't feel like quite enough but that might because it's Friday afternoon. :) |
| 16:16 |
|
stephengwills left #evergreen |
| 16:17 |
* mmorgan |
realizes that Friday afternoon might not be the best time for such a question :) |
| 16:18 |
mmorgan |
On a test system, I removed the factor of 1000, and our popular items zoomed right back up to the top of the poprel search. |
| 16:23 |
mmorgan |
Anyone else have issues with poprel, or is it just us? |
| 16:27 |
* mmorgan |
will open an lp bug, but wanted to look for insight here first. |
| 17:06 |
|
mmorgan left #evergreen |
| 18:02 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 18:03 |
|
sandbergja_ joined #evergreen |
| 18:33 |
|
dbwells_ joined #evergreen |
| 19:34 |
|
remingtron_ joined #evergreen |
| 08:51 |
|
mantis1 joined #evergreen |
| 09:14 |
remingtron |
Bmagic: I pushed to your Antora collab branch. In particular, I converted the headings to one-line prefix/suffix style, to help with nav work that requires changing heading levels. |
| 09:15 |
remingtron |
@later tell sandbergja I pushed to Bmagic's Antora collab branch. In particular, I converted the headings to one-line prefix/suffix style, to help with nav work that requires changing heading levels. |
| 09:15 |
pinesol |
remingtron: The operation succeeded. |
| 09:15 |
|
mllewellyn joined #evergreen |
| 09:15 |
|
mllewellyn left #evergreen |
| 09:16 |
|
mllewellyn1 joined #evergreen |
| 09:35 |
|
rfrasur joined #evergreen |
| 09:53 |
|
sandbergja joined #evergreen |
| 10:33 |
|
sandbergja joined #evergreen |
| 11:02 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 11:44 |
|
Christineb joined #evergreen |
| 12:05 |
|
khuckins joined #evergreen |
| 12:17 |
|
nfBurton joined #evergreen |
| 14:21 |
dluch |
dbs++ |
| 14:21 |
dluch |
Okay, we'll catch up more on the server move next meeting |
| 14:22 |
dluch |
#info Quick update on Antora progress |
| 14:22 |
sandbergja |
if anybody needs HTML versions, I can hop onto docs-testing.evergreen-ils.org and generate them there |
| 14:22 |
sandbergja |
actually... I should just do that |
| 14:22 |
dluch |
sandbergja++ |
| 14:22 |
|
Cody joined #evergreen |
| 14:22 |
tkatie217 |
sandbergja++ please :) |
| 14:26 |
dluch |
(I think bmagic is packing up from the offsite meeting we just had.) |
| 14:26 |
remingtron |
#link http://antora.mobiusconsortium.org/prod |
| 14:26 |
Cody |
Hey all, I'm trying to build a custom catalog search for my local library and struggling with the documentation. http://docs.evergreen-ils.org/reorg/3.0/integrations/index.html seems to be the correct page to start. Is there any way to get JSON or is it only XML? |
| 14:27 |
remingtron |
Anyone can help by testing that server and emailing the DIG list (or posting on IRC) any problems they find. There are some obvious ones, and probably many small ones. |
| 14:28 |
remingtron |
Cody: Hi! We're holding a Documentation Interest Group meeting here right now, should end shortly, then someone can hopefully answer your question. |
| 14:29 |
dbs |
Cody: we're in the middle of a meeting atm but right now there's only XML |
| 14:29 |
dluch |
Cody: we're using the IRC channel for the DIG meeting right now, but I'm sure someone can help after! |
| 14:29 |
dluch |
lol. Jinx, remingtron |
| 14:29 |
sandbergja |
Cody: no worries! |
| 14:29 |
dluch |
Okay, so I'm going to set an action item for all of us on this one |
| 14:30 |
remingtron |
dluch: great |
| 14:30 |
dluch |
#action Everyone will test the new Antora server and email the DIG list (or IRC) with problems (or suggestions) |
| 14:30 |
dluch |
#info We will catch up on other action items and business at the January meeting |
| 14:31 |
dluch |
#info January meeting date |
| 14:31 |
dluch |
The first Thursday in January is the 1st. I am definitely not going to be at work that day and assume most of you won't, either. So, is the following Thursday, January 9, okay with everyone? |
| 14:32 |
abneiman |
9th is fine with me |
| 14:32 |
jweston |
dluch the first Thursday is Jan 2nd but moving it to the 9th sounds fine to me |
| 14:33 |
remingtron |
sounds good |
| 15:22 |
|
jvwoolf joined #evergreen |
| 15:24 |
|
rfrasur joined #evergreen |
| 15:27 |
Dyrcona |
miker: OK, I see why, and I suspect that would have been it before reading bug 1855329. |
| 15:27 |
dbs |
Fun. Switching from our test web staff client back to production, and getting a white screen with "Possibly unhandled rejection: {"isTrusted":true}" in the console when I log in |
| 15:27 |
pinesol |
Launchpad bug 1855329 in Evergreen "Followup to bug 1827250, hold shelf issues" [High,New] https://launchpad.net/bugs/1855329 |
| 15:28 |
miker |
Dyrcona: yeah... too much freedom for the planner. some datasets are super happy with NULLS LAST, but at least 1 not-uncommonly-shaped dataset is super NOT happy |
| 15:31 |
Dyrcona |
miker: I'll have a look tomorrow. I have a couple of 9.6 and higher pg databases hanging around. Our production db is still 9.5. |
| 21:33 |
|
sandbergja joined #evergreen |
| 21:46 |
|
sandbergja joined #evergreen |
| 22:47 |
|
sandbergja joined #evergreen |
| 23:02 |
pinesol |
News from qatests: Failed Building the AsciiDoc output formats <http://testing.evergreen-ils.org/~live/test.81.html#2019-12-05T23:01:09,498026739-0500 -0> |
| 23:45 |
|
sandbergja joined #evergreen |
| 03:24 |
|
jweston joined #evergreen |
| 06:50 |
|
agoben joined #evergreen |
| 07:24 |
|
rfrasur joined #evergreen |
| 07:31 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 08:02 |
|
_bott_ joined #evergreen |
| 08:08 |
|
collum joined #evergreen |
| 08:37 |
|
Dyrcona joined #evergreen |
| 11:22 |
berick |
Bmagic: searching the full value works in stock EG / concerto. e.g. identifier:(Sirsi) 01-0112101 |
| 11:23 |
berick |
or for more precision identifier|scn:(Sirsi) 01-0112101 |
| 11:23 |
berick |
but just searching the numbers should also work |
| 11:46 |
dbs |
Hmm, fun times with the 3.4 staff client - we're seeing labels and the language selector switching seemingly randomly between French and English |
| 11:47 |
dbs |
We're testing out an upgrade from 3.1, where people barely used webby, to 3.4.1 where I hope to pull the plug on XUL |
| 11:50 |
Bmagic |
Dyrcona++ |
| 11:50 |
Bmagic |
berick++ |
| 12:00 |
dbs |
Looks like the service worker might be serving up the cached version, disregarding the eg_locale cookie? |
| 17:53 |
pinesol |
Launchpad bug 1830923 in Evergreen 3.3 "MARC import lacks ability to view and edit incoming MARC record" [High,Confirmed] https://launchpad.net/bugs/1830923 |
| 17:57 |
berick |
gmcharlt: noted, will take a look |
| 18:08 |
gmcharlt |
setting the Vandelay spool directory to /tmp considered harmful... bug 1855199 |
| 18:08 |
pinesol |
Launchpad bug 1855199 in Evergreen "Vandelay record queuing can fail if spool directory is /tmp" [Medium,New] https://launchpad.net/bugs/1855199 |
| 18:28 |
|
sandbergja_ joined #evergreen |
| 18:30 |
|
sandbergja_ joined #evergreen |
| 19:22 |
|
mllewellyn joined #evergreen |
| 21:43 |
|
sandbergja joined #evergreen |
| 21:53 |
|
sandbergja_ joined #evergreen |
| 22:30 |
|
sandbergja joined #evergreen |
| 23:02 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 23:56 |
|
sandbergja joined #evergreen |
| 23:58 |
|
sandbergja_ joined #evergreen |
| 10:11 |
berick |
"today in PINES training we learn IRC" |
| 10:12 |
csharp |
"ok, y'all just hang tight for about 45 mins..." |
| 10:20 |
|
sandbergja joined #evergreen |
| 11:01 |
pinesol |
News from qatests: Failed Building Evergreen <http://testing.evergreen-ils.org/~live/test.30.html#2019-12-03T11:00:45,642733428-0500 -0> |
| 11:01 |
pinesol |
News from qatests: Failed Running Evergreen tests <http://testing.evergreen-ils.org/~live/test.31.html#2019-12-03T11:00:45,670095784-0500 -2> |
| 11:01 |
pinesol |
News from qatests: Failed Installing Evergreen <http://testing.evergreen-ils.org/~live/test.32.html#2019-12-03T11:00:45,697174167-0500 -4> |
| 11:01 |
pinesol |
News from qatests: Failed Installing Dojo <http://testing.evergreen-ils.org/~live/test.35.html#2019-12-03T11:00:45,724417964-0500 -6> |
| 11:02 |
pinesol |
News from qatests: Failed configure apache <http://testing.evergreen-ils.org/~live/test.36.html#2019-12-03T11:00:45,751807836-0500 -8> |
| 11:02 |
pinesol |
News from qatests: Failed configure EG Action/Trigger <http://testing.evergreen-ils.org/~live/test.38.html#2019-12-03T11:00:45,779140022-0500 -10> |
| 11:02 |
pinesol |
News from qatests: Failed Create Evergreen Database <http://testing.evergreen-ils.org/~live/test.41.html#2019-12-03T11:00:45,806399243-0500 -12> |
| 11:02 |
pinesol |
News from qatests: Failed Running pgTAP tests <http://testing.evergreen-ils.org/~live/test.42.html#2019-12-03T11:00:45,833616012-0500 -14> |
| 11:02 |
pinesol |
News from qatests: Failed Running autogen.sh <http://testing.evergreen-ils.org/~live/test.44.html#2019-12-03T11:00:45,861887222-0500 -16> |
| 11:02 |
pinesol |
News from qatests: Failed Running pgTAP live tests <http://testing.evergreen-ils.org/~live/test.47.html#2019-12-03T11:00:45,889208650-0500 -18> |
| 11:02 |
pinesol |
News from qatests: Failed Running settings-tester.pl <http://testing.evergreen-ils.org/~live/test.48.html#2019-12-03T11:00:45,916017334-0500 -20> |
| 11:02 |
pinesol |
News from qatests: Failed Running perl live tests <http://testing.evergreen-ils.org/~live/test.49.html#2019-12-03T11:00:45,942780711-0500 -22> |
| 11:02 |
pinesol |
News from qatests: Failed Log Output: srfsh.log <http://testing.evergreen-ils.org/~live/test.58.html#2019-12-03T11:00:45,969839648-0500 -24> |
| 11:02 |
phasefx |
I'm going to change that to report just the first error :) |
| 11:04 |
phasefx |
though in this case, the webifier is not catching the true first error, which is Err:106 http://ftp.us.debian.org/debian stretch/main amd64 libgd-graph-perl all 1.48-2 |
| 11:04 |
phasefx |
Hash Sum mismatch |
| 15:24 |
dbwells |
Yes. Actually, I see there is a security bug as well. |
| 15:25 |
gmcharlt |
yeah |
| 15:25 |
dbwells |
It seems like both are close, so just highlighting in hopes that someone can push them over the finish line. |
| 15:26 |
gmcharlt |
both bugs have progress, indeed |
| 15:27 |
gmcharlt |
I can provide forward progress for the security bug |
| 15:28 |
gmcharlt |
and we can nudge csharp to see if he's progressed any further with testing for 1773191 |
| 15:28 |
gmcharlt |
#action gmcharlt will apply various code changes and nudges regarding the remaining webstaffblocker bugs |
| 15:29 |
dbwells |
gmcharlt++ |
| 15:29 |
remingtron |
gmcharlt++ |
| 15:30 |
Dyrcona |
gmcharlt++ |
| 15:33 |
berick |
along w/ the hatch 0.3.2 build |
| 15:33 |
berick |
i know there's some other interested parties in moving that bug forward |
| 15:33 |
gmcharlt |
commit ade63709f4b51b jumps out at me |
| 15:33 |
berick |
hoping we can help root out any final issues and encourage some confidence in the bug overall |
| 15:33 |
berick |
done a fair amount of use and testing so far |
| 15:34 |
gmcharlt |
was there anything adding dupes? and if so, should there be code checking that the new constraint is not violated? |
| 15:34 |
gmcharlt |
or is that patch just belt-and-suspenders? |
| 15:34 |
berick |
belt-and-suspenders ... i had a dupe on a dev VM but I was fairly confident it was not from natural causes |
| 15:50 |
|
Topic for #evergreen is now QA-related bugs (Meeting topic: Evergreen Develpment Meeting 2019-12-03) |
| 15:50 |
gmcharlt |
this is a carry-over from an earlier version of the agenda, but the LP link for "qaproject"-tagged bugs turns up nothing |
| 15:50 |
gmcharlt |
does anybody recall what this is? |
| 15:50 |
phasefx |
no bugs there at the moment; I added that to the stock agenda way back when tests failed and no one had the itch to address it |
| 15:51 |
gmcharlt |
ah, OK |
| 15:51 |
phasefx |
for regressions |
| 15:51 |
gmcharlt |
#info The "qaproject" LP tag is meant for bugs stemming from automated test failures that aren't immediately addressed |
| 15:52 |
gmcharlt |
ok |
| 15:52 |
gmcharlt |
so at the moment, we're golden! |
| 15:53 |
gmcharlt |
any other topics that folks would like to raise for the last 8 minutes? |
| 15:53 |
Dyrcona |
Except that tests failed earlier today. |
| 15:53 |
gmcharlt |
we're not golden! :( |
| 15:53 |
phasefx |
I think that may be from debian updates to the repo not being atomic, but I'm not sure |
| 15:53 |
JBoyer |
Dyrcona, that was some kind of upstream thing. (Not even npm!) |
| 20:42 |
|
sandbergja joined #evergreen |
| 21:22 |
|
rfrasur joined #evergreen |
| 22:09 |
|
sandbergja joined #evergreen |
| 23:12 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
