Evergreen ILS Website

IRC log for #evergreen, 2016-08-15

| Channels | #evergreen index | Today | | Search | Google Search | Plain-Text | summary | Join Webchat

All times shown according to the server's local time.

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/perl5​220delta.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

| Channels | #evergreen index | Today | | Search | Google Search | Plain-Text | summary | Join Webchat