Time |
Nick |
Message |
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 |
07:50 |
|
collum joined #evergreen |
08:07 |
|
Dyrcona joined #evergreen |
08:25 |
Dyrcona |
Bingo! Jan 3 08:18:35 jasontest open-ils.trigger: [WARN:8945:Client.pm:122:] Sending large message of 2561713 bytes to routerprivate.localhost/open-ils.trigger |
08:26 |
|
remingtron joined #evergreen |
08:33 |
Dyrcona |
Well, hmm. Not so much a bingo, I guess. I still don't see any errors about max_stanza_size, and the ejabberd log looks like the message was chunked since it shows multiple log entries for each part. |
08:36 |
|
mantis1 joined #evergreen |
08:37 |
|
mmorgan joined #evergreen |
08:46 |
Dyrcona |
Bumping max_stanza_size to 3,000,000 makes a difference, but don't know yet if it is a fix. |
08:48 |
Dyrcona |
Yeahp! It's a max_stanza_size issue. |
08:56 |
rfrasur |
Dyrcona++ |
08:57 |
mmorgan |
Dyrcona++ |
09:21 |
|
yboston joined #evergreen |
09:36 |
|
jvwoolf joined #evergreen |
09:42 |
|
cmalm joined #evergreen |
10:01 |
dbs |
Hmm, more fun today: our 168 hour circ durations (which we specified in hours rather than days to better support grace periods and fine intervals) is no longer working in 3.4 it seems: https://pastebin.com/3jDcJ9fc |
10:12 |
mmorgan |
dbs: bug 1857156 |
10:12 |
pinesol |
Launchpad bug 1857156 in Evergreen 3.3 "loans with HHH:MM:SS durations can fail" [Medium,New] https://launchpad.net/bugs/1857156 |
10:12 |
dbs |
mmorgan++ |
10:14 |
alynn26 |
mmorgan you need to do a session on searching launchpad at the next conference. |
10:14 |
berick |
:) |
10:14 |
dbs |
to be fair, I didn't try searching launchpad before posting here. bad me! |
10:15 |
mmorgan |
Heh. |
10:18 |
mmorgan |
Actually, we saw the issue when we upgraded to 3.2 so it rang a bell. |
10:23 |
|
mmorgan1 joined #evergreen |
10:31 |
dbs |
I very much appreciate the hive mind and supportive community |
10:47 |
|
sandbergja joined #evergreen |
11:00 |
|
Christineb joined #evergreen |
11:20 |
|
sandbergja joined #evergreen |
11:38 |
|
mmorgan joined #evergreen |
11:39 |
|
sandbergja joined #evergreen |
11:44 |
|
jihpringle joined #evergreen |
11:54 |
* dbs |
tries to remember whether we need a separate signoff before a third person pushes a fix to a release branch, or if the second person can just push it directly (re: bug 1867156) |
11:56 |
gmcharlt |
dbs: typo in the bug number? I see no 1867156 |
11:58 |
dbs |
gah. bug 1857156 |
11:58 |
pinesol |
Launchpad bug 1857156 in Evergreen 3.3 "loans with HHH:MM:SS durations can fail" [Medium,New] https://launchpad.net/bugs/1857156 |
11:58 |
gmcharlt |
gotcha |
11:58 |
dbs |
transposition, that's what I need some, transposition, gimme a lead some... TRANSPOSITION! |
11:58 |
dbs |
(well not quite transposition but I have a lot of songs going through my head these days) |
11:58 |
gmcharlt |
anyway, to answer your question, I think the third signoff is still desirable, but that's been increasingly observed in the breach nowadays |
12:00 |
gmcharlt |
in this particular case, I think it's low risk enough that pushing it through would be OK (but then, it is my patch) |
12:00 |
* dbs |
had a co-worker decades ago who used a different song lyric for every bug they opened. and they opened a lot of bugs. |
12:12 |
bshum |
https://bugs.launchpad.net/evergreen/+bug/922128 is still my favorite bug of all time :) |
12:12 |
pinesol |
Launchpad bug 922128 in Evergreen "Scrollbars non sunt multiplicanda praeter necessitatem" [Undecided,Won't fix] |
12:12 |
bshum |
Mostly because of the attached screenshot: https://launchpadlibrarian.net/91130446/yo-dawg-i-heard-you-like-scrolling.png |
12:13 |
rfrasur |
bshum++ |
12:13 |
rfrasur |
and hah!!! |
12:14 |
bshum |
Man 2012 was such a simpler time. Windows 7 + EVG XUL client. Those were the days :D |
12:14 |
bshum |
Or wait, maybe that's XP... |
12:14 |
bshum |
*gasp* |
12:15 |
rfrasur |
I wanna say "ikr?" but we don't wanna go back there. We can't. XUL abandoned us. |
12:15 |
rfrasur |
and no...never xp. never. |
12:15 |
dbs |
That is an awesome bug! |
12:16 |
* dbs |
now looking into an issue where a ridiculously long patron name (the full institutional ID for an ILL library) obscures the checkout input field |
12:19 |
dbs |
SELECT first_given_name, LENGTH(first_given_name) FROM actor.usr ORDER BY 2 DESC; -- shows that our longest first name is 175 characters(!) |
12:20 |
dbs |
adding first_given_name and family_name together gives me a max of 191 characters in our system. |
12:21 |
berick |
Library, first of his name, ruler of the seven kingdoms, kind of the andals and the first men, ... |
12:24 |
mmorgan |
berick++ |
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 |
12:45 |
Dyrcona |
Well, 168 hours == 7 days, so...... |
12:46 |
dbs |
mmorgan: yes, so a checkout time of 2020-01-03 09:11:30.964526-08 resulted in a due date of 2020-01-10 20:59:59-08 - that matches the behaviour that we had in 3.1, so we're happy |
12:46 |
mmorgan |
Dyrcona: 168 hours should give a due date/time of 168 hours after the checkout time. |
12:47 |
dbs |
theoretically the due date should be 2020-01-10 09:11:30.964526-08 but it has never acted that way for us |
12:47 |
mmorgan |
But our library that experienced the problem was happy with changing the duration to 7 days. |
12:48 |
Dyrcona |
Well.... at some point it's just an integer, and at that point they're the exact same value, so it wouldn't surprise me if the code can't tell the difference. |
12:48 |
dbs |
(IIRC, anything that results in an exact day boundary gets converted into days instead of hours anyway--but the reason we wanted to specify hours was more about wanting grace periods of hours instead of days) |
12:54 |
* mmorgan |
is prepared to add a sign off on 1857156, just want to check one more thing |
13:42 |
mmorgan |
added my signoff to bug 1857156 in case dbs or anyone wants to merge it. |
13:42 |
pinesol |
Launchpad bug 1857156 in Evergreen 3.3 "loans with HHH:MM:SS durations can fail" [Medium,New] https://launchpad.net/bugs/1857156 |
13:45 |
pinesol |
[evergreen|Bill Erickson] LP1858118 Hatch enabled check repairs - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=aa9b7c4> |
13:49 |
pinesol |
[evergreen|Galen Charlton] LP#1857156: handle HHH:MM:SS durations in loans - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=75c6b77> |
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. |
14:29 |
berick |
cool |
14:34 |
|
derekz joined #evergreen |
14:38 |
derekz |
Does anyone happen to know if vectorized versions of the default set of format icons exist? |
14:51 |
jeff |
derekz: depending on which icons you care about, the file Open-ILS/web/images/licenses.txt contains some information about the source of several. |
14:52 |
jeff |
derekz: some appear to have been derived from elsewhere, and it's unclear to me if the intermediate files are available. |
14:58 |
pinesol |
Showing latest 5 of 7 commits to Evergreen... |
14:58 |
pinesol |
[evergreen|Bill Erickson] LP1858138 Grid IDL field definition repairs and more - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=bb61f6a> |
14:58 |
derekz |
jeff: specifically, the icons in Open-ILS/web/images/format_icons/icon_format/*.png |
14:58 |
pinesol |
[evergreen|Bill Erickson] LP1858138 Link selector consolidation/repairs - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=f7d4422> |
14:58 |
pinesol |
[evergreen|Bill Erickson] LP1858138 Sandbox example of simple grid filtering - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=621b895> |
14:58 |
pinesol |
[evergreen|Galen Charlton] LP#1858138: remove remaining uses of showLinkSelector - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=d8d169f> |
14:58 |
pinesol |
[evergreen|Galen Charlton] LP#1858138: (follow-up) flesh creator and editor in sandbox's acp grid - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=5939012> |
14:59 |
jeff |
For the most part, the original vector art may not be available to us. Picking just a few icons, I found either the source website only provided png. In at least one case, the site no longer existed in its previous form and I was able to get a copy from the wayback machine, but again it was just rasterized formats. |
14:59 |
derekz |
jeff: I did review the license.txt files in several of the icon directories, but was unable to determine the proper source |
15:00 |
derekz |
jeff: Thanks. It may be easiest to create a fresh icon in this case. Appreciate it. |
15:02 |
jeff |
derekz: if you do, consider including the source file in any patch/branch/submission. :-) |
15:28 |
|
mantis1 left #evergreen |
16:02 |
|
jvwoolf joined #evergreen |
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 |
21:39 |
|
sandbergja joined #evergreen |
22:09 |
|
cmalm joined #evergreen |
22:30 |
|
cmalm joined #evergreen |
22:54 |
|
cmalm joined #evergreen |
23:16 |
|
cmalm joined #evergreen |
23:30 |
|
cmalm joined #evergreen |
23:59 |
|
cmalm joined #evergreen |