| Time |
Nick |
Message |
| 00:05 |
pinesol |
[evergreen|Jane Sandberg] Docs: documenting new 3.2 features based on release notes - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=bb466cd> |
| 06:30 |
pinesol |
News from qatests: Failed Running perl live tests <http://testing.evergreen-ils.org/~live> |
| 07:05 |
|
rlefaive joined #evergreen |
| 07:24 |
|
kmlussier joined #evergreen |
| 07:29 |
|
bdljohn joined #evergreen |
| 07:36 |
|
Dyrcona joined #evergreen |
| 08:41 |
|
aabbee joined #evergreen |
| 08:49 |
|
collum joined #evergreen |
| 08:57 |
|
lsach joined #evergreen |
| 09:02 |
Dyrcona |
@later tell JBoyer I'd like to discuss your multiple scans/transits that you mentioned on 7/20: http://irc.evergreen-ils.org/evergreen/2018-07-20 . We have seen a real uptick in these since switching to the web client, and I wonder if you have come up with any workable solutions or Lp bugs. |
| 09:02 |
pinesol |
Dyrcona: The operation succeeded. |
| 09:26 |
|
aabbee left #evergreen |
| 09:30 |
|
aabbee joined #evergreen |
| 09:44 |
Dyrcona |
It looks like something other than double scans can produce multiple transit entries. When I expand to hour and to day granularity in the query, I get even more duplicate transits. |
| 09:52 |
Dyrcona |
Adding prev_hop makes no difference in the numbers; adding prev_dest shaves off a couple, and adding copy_status (with prev_dest) shaves off a few more. |
| 09:54 |
Dyrcona |
But, I still have 2,107 with that last combination. It comes down from 2,177 without prev_dest and copy_status on the 1 day granularity. |
| 10:05 |
berick |
Dyrcona: if you have a copy w/ multiple open transits, back-tracking to the API calls that created them would be very helpful. |
| 10:06 |
Dyrcona |
berick: I'm not sure how much I can trust our logs. We're using UDP with rsyslog and it drops messages. |
| 10:07 |
Dyrcona |
https://pastebin.com/AqZeeeh2 |
| 10:07 |
Dyrcona |
Those are the queries I've been using. |
| 10:14 |
Dyrcona |
bshum++ # For the release channel. |
| 10:30 |
|
kmlussier joined #evergreen |
| 10:35 |
pinesol |
[evergreen|Andrea Buntz Neiman] Docs: Adding Equinox Open Library Initiative's acknowledgments - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=296b814> |
| 10:35 |
pinesol |
[evergreen|Jane Sandberg] Docs: finalizing acknowledgments section for 3.2 release notes - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=40995f7> |
| 10:42 |
|
khuckins joined #evergreen |
| 11:07 |
|
sandbergja joined #evergreen |
| 11:23 |
pinesol |
[evergreen|Dan Wells] Translation updates - po files - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=8bedbe0> |
| 11:26 |
|
rlefaive joined #evergreen |
| 11:43 |
|
Christineb joined #evergreen |
| 12:08 |
|
beanjammin joined #evergreen |
| 12:18 |
kmlussier |
@coin |
| 12:18 |
pinesol |
kmlussier: tails |
| 12:25 |
|
yboston joined #evergreen |
| 12:28 |
rhamby_ |
kmlussier: karaoke decisions? |
| 12:29 |
kmlussier |
rhamby_: Heh. No, not quite. Decisions that probably shouldn't be made with the flip of a coin. :) |
| 12:30 |
kmlussier |
Like how much of the work should be dumped on rhamby_ for the next Annual Report. |
| 12:30 |
rhamby_ |
kmlussier: it's oddly good I don't a part in that decision, I have a bad habit of using phrases like "I'll take care of that" |
| 12:31 |
|
jihpringle joined #evergreen |
| 12:31 |
csharp |
new cataloging blocker: https://bugs.launchpad.net/evergreen/+bug/1791335 |
| 12:31 |
pinesol |
Launchpad bug 1791335 in Evergreen "Transferring items and vol/items does not maintain stat cats" [Undecided,New] |
| 12:31 |
rhamby_ |
kmlussier: actually I do have on my todo list to do some preliminary work in looking at a new layout app this month |
| 12:31 |
kmlussier |
What I coincidence! I have a bad habit of using phrases like "rhamby_ can take care of that" |
| 12:32 |
kmlussier |
csharp: Yikes! |
| 12:32 |
rhamby_ |
csharp: kmlussier will take care of that one |
| 12:32 |
* rhamby_ |
exits stage left |
| 12:43 |
khuckins |
pursued by a (li)bear(ian)? |
| 12:47 |
Dyrcona |
csharp here's another one, though the bug itself is not exactly new: https://bugs.launchpad.net/evergreen/+bug/1787274 |
| 12:47 |
pinesol |
Launchpad bug 1787274 in Evergreen "Web Client: Transits Don't Always Clear" [Critical,Confirmed] |
| 12:56 |
gsams |
Dyrcona: I ran your queries on my system, at the 'day' level and found 15 total prior to 3.0 and 93 since the upgrade. |
| 12:56 |
gsams |
if I can do anything to help trace the issue I'd be happy to try, I may just need some walking through it. |
| 12:58 |
Dyrcona |
gsams: I'm not sure, yet, what else to look for. Checking for duplicate checkins, etc., in the logs might be a good place to start, but I can't rely on our log server too much because it drops a lot of messages. |
| 12:58 |
gsams |
We've had a lot of odd issues with multiple checkins within extremely tight timing over the summer |
| 12:59 |
gsams |
I'm just not sure what is causing it to happen really |
| 13:04 |
Dyrcona |
I have been told in internal emails that some libraries report scanning things twice because checkin is slow. |
| 13:05 |
Dyrcona |
I have seen 1 copy that has 3 transits and 3 auditor log entries all created within .0028 seconds from first to last, so that is way too fast to be multiple checkin scans. |
| 13:06 |
gsams |
I would definitely describe checkin as slow here, but most of what I am seeing in our consortium is within thousandths of a second. |
| 13:06 |
Dyrcona |
Yeahp. :) |
| 13:06 |
gsams |
Well, at least I know it isn't just us! |
| 13:07 |
Dyrcona |
I think JBoyer was reporting this behavior back in July in IRC before we noticed it at CW MARS. |
| 13:07 |
kmlussier |
I think there is a bug on the slow checkins, right? |
| 13:08 |
Dyrcona |
Probably, but I think the only way to speed it up is to lose some "features." |
| 13:08 |
kmlussier |
bug 1777207 |
| 13:08 |
pinesol |
Launchpad bug 1777207 in Evergreen "Web Client - Check In List Refreshes After Every Scan and Gets Progressively Slower" [Medium,Confirmed] https://launchpad.net/bugs/1777207 |
| 13:08 |
Dyrcona |
Well, checkin has always been slow, even in XUL. |
| 13:20 |
jihpringle |
the reports we've had is that it's check in is currently significantly slower than it was in xul |
| 13:24 |
Dyrcona |
Yeah, same here, but I've always personally thought it was too slow. :) |
| 13:25 |
|
khuckins joined #evergreen |
| 13:26 |
jihpringle |
we're also seeing transits not clearing and holds that are ending up with Error(-1) - the holds are captured and they're set to reshelving at the same time |
| 13:27 |
jihpringle |
our suspicion is that those issues are related to the check in slowness but we don't have any proof |
| 13:34 |
Dyrcona |
jihpringle: If it looks like Lp 1787274 could you click at least indicate that the bug affects you, please? |
| 13:34 |
pinesol |
Launchpad bug 1787274 in Evergreen "Web Client: Transits Don't Always Clear" [Critical,Confirmed] https://launchpad.net/bugs/1787274 |
| 13:34 |
Dyrcona |
We've had at least 1 ticket this week about holds going to the invalid status, -1. |
| 13:35 |
jihpringle |
Drycona done |
| 13:37 |
jihpringle |
there's an old bug from 2015 about the invalid hold status that was recently commented on in August https://bugs.launchpad.net/evergreen/+bug/1526605 |
| 13:37 |
pinesol |
Launchpad bug 1526605 in Evergreen "Stuck holds can with hold status -1" [Undecided,Incomplete] |
| 13:40 |
Dyrcona |
yeahp. I think something new is going with the web staff client to make that happen more frequently. |
| 13:41 |
jihpringle |
I thought there was a more recent bug report for it but I can't find one so I must've be thinking of the tickets we've been seeing |
| 13:54 |
berick |
Dyrcona: you're dupe transits, are finding cases where dest_recv_time is null on multiple transits on the same copy? |
| 13:58 |
Dyrcona |
berick: Yes. I added another copy of the same csv with dest_recv_time added. https://bugs.launchpad.net/evergreen/+bug/1787274/comments/4 |
| 13:58 |
pinesol |
Launchpad bug 1787274 in Evergreen "Web Client: Transits Don't Always Clear" [Critical,Confirmed] |
| 13:58 |
Dyrcona |
BTW, I'm having a little problem with the tarball installation. I mentioned it in the release channel. |
| 14:03 |
Dyrcona |
berick: cancel_time is also null. |
| 14:06 |
berick |
Dyrcona: thanks for the csv... those appear to be created within a single checkin call. any logs you have for that API call would be super helpful |
| 14:07 |
Dyrcona |
berick: They should still be on whatever brick processed that request for a few days. They'll be more intact from the brick than from our syslogger. I'll see if I can find them and add them to the bug. |
| 14:09 |
berick |
Dyrcona++ |
| 14:12 |
|
yboston joined #evergreen |
| 14:16 |
abneiman |
Question for the room |
| 14:16 |
abneiman |
I'm testing sort persistence in web client grids -- so far in 3.1.5, not a single Cat or Circ grid will save a user-set sort priority. Once you leave the interface and come back, it's back to default sort. Spot checks in 3.0.9 show the same. |
| 14:17 |
abneiman |
Has anyone else come across this? I know a couple bugs have been filed for specific grids (bug 1758381 and bug 1790169) but I'm curious id anyone's looked into it more broadly |
| 14:17 |
pinesol |
Launchpad bug 1758381 in Evergreen "Web Client: Copy Buckets Default Sort Seems to be Random" [Undecided,Confirmed] https://launchpad.net/bugs/1758381 |
| 14:17 |
pinesol |
Launchpad bug 1790169 in Evergreen "Web Client: Sort Priority not honored in Check In and Capture Hold screens" [Undecided,New] https://launchpad.net/bugs/1790169 |
| 14:25 |
kmlussier |
abneiman: Sort persistence is one thing I haven't looked closely at yet. |
| 14:26 |
abneiman |
kmlussier: yeah, I'm looking into it because a customer is having issues, but I'd never looked closely before either |
| 14:32 |
kmlussier |
I just remembered bug 1766262. Is that something we want to make part of xul removal? Can it be considered a bug fix for post-beta? |
| 14:32 |
pinesol |
Launchpad bug 1766262 in Evergreen "Remove org unit settings that are no longer valid in web client" [Wishlist,Confirmed] https://launchpad.net/bugs/1766262 |
| 14:53 |
Dyrcona |
kmlussier: XUL is not removed, yet, just not installed by default, so we probably want to wait for actual XUL removal, first. |
| 14:53 |
kmlussier |
Dyrcona: OK, thanks! |
| 14:54 |
kmlussier |
It probably wouldn't hurt to have a branch posted, just so it's ready to go when the time comes. If I have tuits. |
| 14:58 |
jeffdavis |
We need a sponsor with deep pockets to set up a tuit dispenser at the next hackaway. |
| 15:02 |
kmlussier |
jeffdavis++ |
| 15:08 |
kmlussier |
Actually, the pockets don't need to be too deep - https://amzn.to/2CwYhii |
| 15:09 |
gmcharlt |
but if we need a million of them... :) |
| 15:09 |
kmlussier |
gmcharlt: I assume there's some kind of per-tuit discount when bought in bulk. |
| 15:10 |
* jeff |
nods |
| 15:10 |
jeff |
i have priced them on more than one occasion from multiple vendors, with and without customization. :-) |
| 15:13 |
gmcharlt |
heh |
| 15:14 |
|
jvwoolf joined #evergreen |
| 15:15 |
|
rlefaive joined #evergreen |
| 16:01 |
|
khuckins joined #evergreen |
| 17:27 |
|
aabbee left #evergreen |
| 18:31 |
pinesol |
News from qatests: Failed Running Evergreen browser client build/test - Expected 6 errors but encountered 3. <http://testing.evergreen-ils.org/~live> |
| 18:31 |
pinesol |
News from qatests: Failed Running perl live tests <http://testing.evergreen-ils.org/~live> |
