| Time |
Nick |
Message |
| 06:40 |
|
rlefaive joined #evergreen |
| 07:07 |
|
agoben joined #evergreen |
| 07:27 |
|
rjackson_isl joined #evergreen |
| 07:36 |
|
JBoyer joined #evergreen |
| 07:56 |
|
ericar joined #evergreen |
| 08:29 |
|
gsams_ joined #evergreen |
| 08:41 |
|
mmorgan joined #evergreen |
| 08:54 |
|
maryj joined #evergreen |
| 09:03 |
|
bos20k joined #evergreen |
| 09:14 |
|
Dyrcona joined #evergreen |
| 09:30 |
|
bos20k joined #evergreen |
| 09:38 |
jeff |
good morning, #evergreen |
| 09:38 |
|
jvwoolf joined #evergreen |
| 09:39 |
mmorgan |
Good morning! |
| 09:42 |
|
yboston joined #evergreen |
| 09:56 |
Dyrcona |
Since we postponed the beta release by a week, I'm inclined to postpone the release of 2.9.7 to the same date. |
| 09:57 |
Dyrcona |
This gives us the chance of having the same bug fixes as the beta. |
| 09:57 |
Dyrcona |
Do I hear any objections? |
| 09:59 |
jeff |
sounds reasonable. i don't have a sense for how much others may plan their maintenance around point releases. |
| 10:00 |
* berick |
nods in agreement |
| 10:01 |
|
mmorgan1 joined #evergreen |
| 10:02 |
|
rlefaive_ joined #evergreen |
| 10:16 |
|
kmlussier joined #evergreen |
| 10:23 |
dbs |
\win 2 |
| 10:23 |
dbs |
meh |
| 10:27 |
* Dyrcona |
wonders if 2.9.7 will be the last? Maybe a 2.9.8 will make it out? |
| 10:29 |
berick |
@marc 035 |
| 10:29 |
pinesol_green |
berick: A control number of a system other than the one whose control number is contained in field 001 (Control Number), field 010 (Library of Congress Control Number) or field 016 (National Bibliographic Agency Control Number). (Repeatable) [a,z,6,8] |
| 10:32 |
Dyrcona |
I assume it is not a big deal to restart rsyslog on a brick head or drone in the middle of the day. Is that assumption correct? |
| 10:34 |
bshum |
"I can neither confirm nor deny details of any operation without the Secretary's approval." |
| 10:34 |
|
rlefaive joined #evergreen |
| 10:34 |
Dyrcona |
Heh. |
| 10:34 |
Bmagic |
Dyrcona: after removing those UNIVERSAL lines, I get complaints in the logs about OpenILS::SIP not being loaded. It's loaded from the config file, then on line 885 in MsgType.pm it loads it with $module->use; |
| 10:34 |
bshum |
But that shouldn't blow up anything to restart syslog stuff |
| 10:35 |
Bmagic |
Dyrcona: I can add use OpenILS::SIP at the top of SIPServer.pm and solve the issue |
| 10:35 |
Dyrcona |
Bmagic: Don't do that. You'll break "compatibility with Koha," which doesn't really exist. |
| 10:36 |
Bmagic |
what's the right solution? |
| 10:36 |
Dyrcona |
Try Module::Load. |
| 10:38 |
Dyrcona |
Something like use Module:Load; |
| 10:38 |
Dyrcona |
Then load $module; instead of $module->use; |
| 10:39 |
Bmagic |
ah, let me see |
| 10:39 |
Dyrcona |
I'm not sure that's the best solution, but it should work. |
| 10:39 |
Dyrcona |
Perhaps, I was mistaken that with the deprecation of UNIVERSAL::import that this stuff was going to "just work" in the future. |
| 10:40 |
Bmagic |
Can't locate object method "load" via package "OpenILS::SIP" |
| 10:41 |
Dyrcona |
Hang on. I typed that from "memory." |
| 10:41 |
Bmagic |
how about an eval statement? |
| 10:41 |
JBoyer |
Bmagic, may need to be something like this: use Module::Load qw('load'); |
| 10:41 |
Dyrcona |
I have a module where I used Module::Load. |
| 10:41 |
JBoyer |
Its' also possible that load isn't the right function name, I don't know anything about it, :) |
| 10:41 |
Dyrcona |
And if the eval statement fails? How do you recover? |
| 10:45 |
Dyrcona |
Nope. Looks like use Module::Load; |
| 10:45 |
Dyrcona |
then load $module; should work. |
| 10:46 |
Bmagic |
it works as long as I put use Module::Load; in MsgType.pm and not SIPServer.pm |
| 10:47 |
Dyrcona |
Right, you want it in the module where you're going to use it. |
| 10:47 |
Bmagic |
I figured the execution path started with SIPServer.pm |
| 10:47 |
Bmagic |
threads I guess |
| 10:48 |
Dyrcona |
Not threads. |
| 10:48 |
Dyrcona |
Processes. |
| 10:48 |
Bmagic |
gotcha |
| 10:48 |
Dyrcona |
It could also just be an issue of translation units and visibility in the code. |
| 10:49 |
|
ericar joined #evergreen |
| 10:50 |
Bmagic |
It sounds like these changes need to be on git |
| 10:50 |
Bmagic |
for xenial and beyond? |
| 10:50 |
Dyrcona |
Yes. I'm still mildly surprised that $module->use; doesn't work. |
| 10:51 |
Bmagic |
it might work now that Module::Load is there, let me check |
| 10:51 |
Dyrcona |
Really, the distro doesn't matter. UNIVERSAL::import has been deprecated for quite a while. |
| 10:51 |
Dyrcona |
IIRC, Module::Load is installed with Perl. |
| 10:52 |
Bmagic |
no, ->use syntax doesnt work |
| 10:53 |
Dyrcona |
Right, and I'm surprised, because it is pretty much the same thing as use $module; |
| 10:53 |
Dyrcona |
You could try "use $module;" instead of using Module::Load. |
| 10:54 |
Dyrcona |
Given what you've said, I'd be surprised if that worked, though. |
| 10:56 |
Dyrcona |
A module in OpenSRF uses Module::Load already as does NCIPServer, so there's precedent. :) |
| 10:56 |
|
csharp-gpls joined #evergreen |
| 10:57 |
miker |
Dyrcona: ->use comes from UNIVERSAL::require |
| 10:57 |
miker |
fwiw |
| 10:57 |
Dyrcona |
OK. |
| 10:58 |
Dyrcona |
UNIVERSAL::require is a separate module, so that should still work, then. |
| 10:58 |
Bmagic |
When we setup SIPServer, we have to use a different branch other than master due to some sort of memory leak bug maybe |
| 10:58 |
Dyrcona |
Bmagic: If that's the case, that branch should be merged into master. :) |
| 10:59 |
Bmagic |
that is where I was going |
| 10:59 |
Bmagic |
git checkout 9b3ca581d92298904652f52b512dc2eb1b153977 |
| 10:59 |
Bmagic |
we just use it by default now and I cant remember why |
| 11:00 |
Bmagic |
I was going to put together a branch for these changes but I just remember that we dont use master |
| 11:00 |
Dyrcona |
Bmagic: I think that is in master already. |
| 11:00 |
Bmagic |
oh? |
| 11:00 |
Bmagic |
LP#1339190 |
| 11:01 |
Dyrcona |
Yeah: git show 7e4fbac12f6018b4d5a36d7a4360789ced929aa0 |
| 11:01 |
pinesol_green |
Dyrcona: [sipserver|Mike Rylander] LP#1339190 Add support for the "Multiplex" personality - <http://git.evergreen-ils.org/?p=SIPServer.git;a=commit;h=7e4fbac> |
| 11:01 |
Bmagic |
ah! so we dont need to check that branch out anymore |
| 11:02 |
Dyrcona |
Right. |
| 11:03 |
Bmagic |
ok moving on, there is another line in SIPServer.pm referencing UNIVERSAL. $self->{state} = $self->{ils}->state() if (UNIVERSAL::can($self->{ils},'state')); |
| 11:03 |
Dyrcona |
Bmagic: That should be fine. |
| 11:03 |
|
mmorgan joined #evergreen |
| 11:04 |
|
Christineb joined #evergreen |
| 11:04 |
Bmagic |
on my test machine, that line is present and I could launch the sip server and login to it, but I didnt test anything else |
| 11:24 |
jeff |
Bmagic: can you sum up what you're trying to do/fix? |
| 11:24 |
Bmagic |
it started with me installing SIPServer on xenial |
| 11:24 |
Bmagic |
turns out UNIVERSAL module is depricated in perl 5.22 and beyond |
| 11:26 |
Dyrcona |
No. It's deprecated in 5.1[04] to 5.20. It's removed in 5.22+ |
| 11:31 |
JBoyer |
A new policy approaches! Humans: But, we don't want to do that. Computers: You got it! GUESS WHICH ONE I PREFER. |
| 11:31 |
Bmagic |
Right, removed |
| 11:38 |
Bmagic |
LP 1613326 look ok? |
| 11:38 |
pinesol_green |
Launchpad bug 1613326 in Evergreen "SIPServer UNIVERSAL removed" [Undecided,New] https://launchpad.net/bugs/1613326 |
| 11:39 |
jeff |
what's the motivation behind the move from UNIVERSAL::require to Module::Load? |
| 11:39 |
Bmagic |
it's what works |
| 11:40 |
tsbere |
jeff: UNIVERSAL::require ceasing to be an option due to perl changes? |
| 11:40 |
|
maryj joined #evergreen |
| 11:40 |
Dyrcona |
I suggested removing it when it would load on my laptop, but turns out it is fine to keep it. I would still recommend Module::Load over UNIVERSAL::require. |
| 11:41 |
Dyrcona |
"would not load on my laptop" |
| 11:42 |
Dyrcona |
Anyway, that's what happens when rushing to check things. :) |
| 11:42 |
Dyrcona |
I mentioned earlier that it would be fine to leave UNIVERSAL::require after miker pointed out that is where the $module->use comes from. |
| 11:43 |
Dyrcona |
Both are Module::Load and UNIVERSAL::require are already used by OpenSRF and Evergreen. |
| 11:43 |
* Dyrcona |
should stop typing so fast. |
| 11:45 |
Bmagic |
I had trouble getting SIP started. It complained about UNIVERSAL |
| 11:46 |
jeff |
because this line in Sip/MsgType.pm is now a fatal error: use UNIVERSAL qw(can); |
| 11:46 |
Dyrcona |
Bmagic: You could probably revise to just remove the use UNIVERSAL qw(can); |
| 11:47 |
jeff |
I'll throw up a working branch and comment on the bug. |
| 11:47 |
* Dyrcona |
can't multitask. |
| 11:49 |
|
brahmina joined #evergreen |
| 11:54 |
Bmagic |
I got my branch updated |
| 12:29 |
pinesol_green |
[opensrf|Ben Shum] LP#1585041: Move debian_sys_config target for Debian distributions - <http://git.evergreen-ils.org/?p=OpenSRF.git;a=commit;h=1c8a7dc> |
| 12:35 |
Dyrcona |
To be precise: the UNIVERSAL module is not deprecated or removed. UNIVERSAL::import is deprecated and removed. |
| 12:36 |
Dyrcona |
Thus, statements like "use UNIVERSAL qw(can);" produce warnings on Perl < 5.22 and fatal errors on Perl >= 5.22. |
| 12:37 |
jeff |
right. |
| 12:38 |
miker |
Dyrcona: heh ... indeed ... see my comment on the bug :) |
| 12:38 |
jeff |
ref http://perldoc.perl.org/perl5120delta.html and http://perldoc.perl.org/perl5220delta.html#use-UNIVERSAL-'...'-is-now-a-fatal-error |
| 12:39 |
miker |
jeff: aye |
| 12:39 |
Dyrcona |
Yeah. |
| 12:39 |
Dyrcona |
Ah, 5.12 is where the deprecation happened. I should keep up more. :) |
| 12:40 |
Dyrcona |
IANM, $self->{ils}->can('state'); should also work. |
| 12:41 |
jeff |
yes. |
| 12:41 |
Dyrcona |
Or maybe not if the module isn't loaded, yet. |
| 12:41 |
miker |
unless it's undefined ... |
| 12:41 |
jeff |
and wrapping it in an eval is safer. |
| 12:41 |
jeff |
and oft-recommended. |
| 12:41 |
miker |
well, |
| 12:42 |
jeff |
but of course if you can be reasonably certain of what you're calling it on... |
| 12:42 |
Dyrcona |
I think that line should be left alone for now. ;) |
| 12:43 |
|
ericar joined #evergreen |
| 13:14 |
|
maryj joined #evergreen |
| 13:51 |
|
collum joined #evergreen |
| 14:48 |
* kmlussier |
grumbles about LP timeout errors. |
| 14:48 |
csharp |
kmlussier: same here! |
| 14:49 |
csharp |
was just about to mark my bug report as a duplicate of bug 1613374 |
| 14:49 |
pinesol_green |
Launchpad bug 1613374 in Evergreen "Feature Request: "Canceled Transit" Item Status" [Wishlist,New] https://launchpad.net/bugs/1613374 - Assigned to Chris Sharp (chrissharp123) |
| 14:49 |
csharp |
oh - I mean 1306666 |
| 14:49 |
csharp |
bug 1306666 |
| 14:49 |
pinesol_green |
Launchpad bug 1306666 in Evergreen 2.9 "When Aborting a Transit, items should not automatically get Reshelving status." [Low,Confirmed] https://launchpad.net/bugs/1306666 |
| 14:49 |
kmlussier |
csharp: Apparently LP disagrees with us that it's a duplicate. |
| 14:50 |
csharp |
I'm still digesting Dyrcona's approach to the issue - I think I like the new status approach better since it doesn't care about what the circumstances are when the transit is canceled/aborted |
| 14:50 |
csharp |
but I'm open to being convinced otherwise ;-) |
| 14:51 |
csharp |
kmlussier: ok - marked duplicate |
| 14:52 |
jeff |
hah. found one remaining annual workflow that relies on clark kent. fixing! |
| 14:52 |
kmlussier |
csharp: I think Dyrcona's first branch should also be considered if we go with the new status. In that branch, he was addressing items that were checked out but had a hanging transit. We still want to keep those as checked out. |
| 14:52 |
kmlussier |
And LP is back in business for me too. Finally get to add my comment to bug 1613341. |
| 14:52 |
pinesol_green |
Launchpad bug 1613341 in Evergreen "Patron name search - apostrophes" [Wishlist,Confirmed] https://launchpad.net/bugs/1613341 |
| 14:52 |
csharp |
oh - I'll take a look at that |
| 14:52 |
csharp |
I was just looking at the last git branch |
| 14:53 |
Dyrcona |
Well, I don't know that the two bugs are trying to solve the same problems, but they certainly appear to be fraternal twins if not identical. :) |
| 14:53 |
csharp |
heh |
| 14:54 |
csharp |
our bug resulted from similar circumstances as mmorgan originally reported - confusion because aborting transits created situations that don't match the actual status of the transited item |
| 14:55 |
* mmorgan |
didn't consider those two were duplicates at first glance. Will need to look again. |
| 14:55 |
Dyrcona |
I think I would trust the copy status over the existence of a transit. |
| 14:55 |
Dyrcona |
Which is where I was coming from, only change the copy status if the copy status is in transit. |
| 14:56 |
Dyrcona |
A new status for canceled transit is fine with me. |
| 14:59 |
* csharp |
runs off to test his branch before referring to it in the original bug thread |
| 15:00 |
* mmorgan |
saw bug 1612754 and overlooked the one about the status |
| 15:00 |
pinesol_green |
Launchpad bug 1612754 in dpkg (Ubuntu) "package openssh-client 1:7.2p2-4ubuntu1 failed to install/upgrade: package openssh-client is already installed and configured" [Undecided,New] https://launchpad.net/bugs/1612754 |
| 15:00 |
csharp |
jeff: OPERATION KRYPTONITE? |
| 15:00 |
|
rlefaive joined #evergreen |
| 15:01 |
* mmorgan |
can't type, bug 1612752 |
| 15:01 |
pinesol_green |
Launchpad bug 1612752 in Evergreen "Feature Request: Cancel Transits, Don't Delete Them" [Wishlist,Confirmed] https://launchpad.net/bugs/1612752 - Assigned to Chris Sharp (chrissharp123) |
| 15:01 |
csharp |
mmorgan: yeah, working a lot on transits today ;-) |
| 15:02 |
kmlussier |
csharp: It's a very worthy place to be focusing your attentions. :) |
| 15:03 |
csharp |
heh - last week we had like 3 tickets in a row about it |
| 15:03 |
csharp |
it takes lots of sys admin time in the DB and logs recreating what happened |
| 15:04 |
Dyrcona |
It does. |
| 15:04 |
csharp |
so, really, the main motivation here is the desire to be lazier ;-) |
| 15:04 |
tsbere |
I haven't had too many to dig into lately, but they do get annoying. |
| 15:04 |
mmorgan |
csharp++ |
| 15:07 |
mmorgan |
I'm warming up to the idea of a new status for cancelled transits |
| 15:09 |
Dyrcona |
It complicates things a bit. It will need to be added to relevant lists of what different statuses to look for in certain situations and so on. |
| 15:10 |
Dyrcona |
Some parts of the code only look for copies with certain statuses, and those places will need to be examined to determine if they should look at this new status as well. |
| 15:10 |
csharp |
Dyrcona: right - I was wondering about that |
| 15:10 |
csharp |
so my branch is not complete since I haven't considered that yet |
| 15:12 |
csharp |
also, I will definitely need guidance on writing perl tests for my changes, but not today |
| 15:13 |
mmorgan |
I would think it could avoid a lot of confusion for the end user, though. |
| 15:13 |
csharp |
well, the reason I went that direction (completely unaware of the discussion on the older bug) was that it's a clear signal to staff what happened to their item |
| 15:14 |
csharp |
it feels kind of unsubtle, but it may be a good solution |
| 15:15 |
mmorgan |
There's nothing subtle about the other Evergreen statuses ;-) |
| 15:15 |
csharp |
heh - true |
| 15:17 |
mmorgan |
I like the idea of status being one-stop-shopping, a clear indication of the very last thing that happened to the item. |
| 15:18 |
csharp |
that's what I was thinking |
| 15:24 |
csharp |
okay - my branch is basically working - I'll look into the special statuses stuff tomorrow and add it to the bug |
| 15:26 |
Dyrcona |
Hmm. I just commented on the bug and realized that a new status may prevent a backport because of translations. |
| 15:32 |
kmlussier |
My recollection was that translations weren't a showstopper for backports; they just warranted more caution. In this case, though, it does feel a little new featurish to me. |
| 15:42 |
bshum |
I know you guys are talking about transit status stuff, but it occurs to me that berick (and others) were working on some custom status handling for circ, etc. in https://bugs.launchpad.net/evergreen/+bug/1464709 ; might be good to plan around each other's work |
| 15:42 |
pinesol_green |
Launchpad bug 1464709 in Evergreen "Seamless checkout of non-standard copy status AKA single-use copy statuses" [Wishlist,New] - Assigned to Bill Erickson (berick) |
| 15:56 |
|
mrpeters joined #evergreen |
| 15:59 |
* berick |
removes his name from said bug since he's not actively working on it at the moment |
| 16:00 |
|
maryj_ joined #evergreen |
| 16:33 |
kmlussier |
I have noticed lately that checkins on webby are either extremely slow (like minutes) or don't complete at all. The barcode number displays but none of the other grid fields populate on the checkin screen. |
| 16:33 |
kmlussier |
Has anyone else seen this on a machine with the latest branches loaded? I'm just wondering if it's a code issue or 'something else.' |
| 17:04 |
|
mmorgan left #evergreen |
| 18:35 |
|
JBoyer_alt joined #evergreen |
| 18:37 |
|
JBoyer_alt_bin joined #evergreen |
| 19:17 |
|
dcook joined #evergreen |
| 23:48 |
|
gsams_ joined #evergreen |
