Evergreen ILS Website

IRC log for #evergreen, 2017-03-09

| 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
00:43 dcook joined #evergreen
01:28 Bmagic joined #evergreen
06:40 rlefaive joined #evergreen
06:57 agoben joined #evergreen
07:28 rjackson_isl joined #evergreen
07:28 graced Good morning, #evergreen
07:33 JBoyer joined #evergreen
08:00 jeff good morning!
08:03 Dyrcona joined #evergreen
08:43 mmorgan joined #evergreen
08:53 mmorgan1 joined #evergreen
09:07 Dyrcona Did a fresh install of OpenSRF master on an Ubuntu 16.04 Xenial Xerus VM just now, and osrf_control hangs.
09:08 Dyrcona Seems to take forever on opensrf.dbmath.
09:08 kmlussier joined #evergreen
09:09 Dyrcona If I get impatient and Ctrl-C out of it opensrf.dbmath is running, but opensrf.math is not.
09:10 Dyrcona ERR opensrf.settings has no running drones.
09:10 Dyrcona Hmm... I don't think I messed anything up.
09:11 Dyrcona I've checked the passwords 3 times, now.
09:12 collum joined #evergreen
09:14 Dyrcona [2017-03-09 09:04:54] opensrf.settings [ERR :24862:System.pm:122:] server: died with error Exception: OpenSRF::EX::Jabber 2017-03-09T09:04:54 OpenSRF::System /usr/local/share/perl/5.22.1/OpenSRF/System.pm:122 Jabber Exception: Disconnected from Jabber server
09:14 Dyrcona But no explanation why.
09:15 Dyrcona [2017-03-09 09:04:54] opensrf.settings [ERR :24862:EX.pm:66:] Exception: OpenSRF::EX::Jabber 2017-03-09T09:04:54 OpenSRF::Transport::SlimJabber::XMPPReader /usr/local/share/perl/5.22.1/OpenSRF/T​ransport/SlimJabber/XMPPReader.pm:263 Jabber Exception: Disconnected from Jabber server
09:15 Dyrcona I noticed a recent change to that file.
09:23 Dyrcona Well, reverting the latest commit to that file makes no difference.
09:24 Enjabain joined #evergreen
09:25 Dyrcona It seems somewhat random what services are running or not.
09:25 Dyrcona This time, opensrf.settings is fine but opensrf.validator isn't.
09:25 Dyrcona opensrf.math and opensrf.dbmath are also not running.
09:27 yboston joined #evergreen
09:28 kmlussier Since we have less than a week left until the RC, I wanted to highlight a couple of bugs that could use some attention if anyone has tuits. We have two bugs targeted for 2.12 with a high priority.
09:28 kmlussier One has a branch and pullrequest tag: bug 1442276
09:28 pinesol_green Launchpad bug 1442276 in Evergreen "Supercat encoding problems with MODS output (Zotero)" [High,Confirmed] https://launchpad.net/bugs/1442276
09:29 kmlussier The other does not have a branch: bug 1670250
09:29 pinesol_green Launchpad bug 1670250 in Evergreen "Web client: Circ staff users unable to view all checked-out items and other permission issues" [High,New] https://launchpad.net/bugs/1670250
09:29 kmlussier I identified the last one as a high priority because I'm concerned that people using the web client will be able to see the holds for patrons when they don't have view permissions for those patrons.
09:31 mmorgan joined #evergreen
09:32 rlefaive joined #evergreen
09:33 kmlussier There are also two web client bugs that I signed off on, but then added another commit that needs a signoff before it can be merged. bug 1522644 and bug 1621178
09:33 pinesol_green Launchpad bug 1522644 in Evergreen "webclient: Transfer title holds issues" [Medium,New] https://launchpad.net/bugs/1522644
09:33 pinesol_green Launchpad bug 1621178 in Evergreen "webclient: Copy status field missing from column pickers" [Medium,Confirmed] https://launchpad.net/bugs/1621178
09:36 kmlussier If there are any other bug fixes you think need to make it into the release, let me know. I probably won't get to them today, but will make some time to review branches before gmcharlt cuts the release next week.
09:47 mmorgan1 joined #evergreen
09:51 Dyrcona Well, I'm gonna try on another fresh vm elsewhere.
09:51 Dyrcona I should really test what I want to test with production data, anyway.
09:55 csharp Dyrcona: check journalctl for apport messages
09:56 Dyrcona csharp: Too late. I blew it all away.
09:56 Dyrcona Here's a middle finger for systemd-- :)
09:56 Dyrcona Turning Linux into Windows since 2012.
09:59 Dyrcona and binary_logs--
10:00 Dyrcona Now, I have to wait for an ISO to copy, 'cause I don't have the Ubuntu server ISO on the host where I want to make the new vm.
10:04 csharp we just build "stock-xenial" guests that we clone at need
10:04 csharp (ours is all on remote servers)
10:04 Dyrcona Uh-huh. I've cloned VMs before.
10:05 Dyrcona I've also made copies "by hand."
10:05 Dyrcona Doesn't help if you think your image is busted, which is my current suspicion, or you don't have clonable images handy at the moment.
10:06 Dyrcona It could be the new kernel. I notice some bustification with grub-update during apt dist-upgrade.
10:07 * Dyrcona grumbles and thinks he should get back to work on fixing our build so it will work on *BSD.
10:07 Dyrcona It's copying sparse image files around...rsync -S
10:08 Dyrcona Hmm. there's an adjective missing. I'll let the reader fill in the blank this time.
10:10 Dyrcona Imagine Evergreen on NetBSD, running on your toaster!
10:11 Dyrcona Imagine a Beowulf cluster of those.... ;)
10:14 * csharp still wants to install EG on a raspberry pi mounted on a drone and have a mobile ILS
10:14 Dyrcona Usually it's no big deal to make a new VM and I have limited space on my laptop. ;)
10:14 Dyrcona Heh!
10:15 Dyrcona Realistically, you'd need more RAM than a typical Raspberry Pi has.
10:15 Dyrcona But, fun idea.
10:15 Dyrcona Ditto the toaster.
10:16 * Dyrcona takes a look at /. for the first time in...months.
10:24 bshum Well, if you cluster the Pi's, you could make it work :)
10:24 bshum The hardest thing is having enough memory for your database I think
10:25 bshum So a flying army of drone pi's, obviously
10:32 * bshum plays "the ride of the valkyries"
10:37 Dyrcona :)
10:38 * Dyrcona plays The Blues Brothers: Briefcase Full of Blues.
10:42 * Dyrcona uses virt-manager to build the vm and lets it put it in the default location.
10:44 Dyrcona My laptop is acting "weird," too.
10:44 Dyrcona @blame Ubuntu
10:44 pinesol_green Dyrcona: Ubuntu is why we can never have nice things!
10:44 Dyrcona :)
10:45 Dyrcona Normally, I'd a get a generic icon for virt-manager run remotely for Alt-Tab switching.
10:46 Dyrcona But this time, task switcher has decided that virt-manager is another Thunderbird window.
10:46 Dyrcona If you're on Ubuntu 16.04, you might want to wait a few days before installing updates.
10:55 collum_ joined #evergreen
10:55 Enjabain joined #evergreen
11:08 Dyrcona joined #evergreen
11:13 brahmina joined #evergreen
11:21 berick i'm finally poking around the conditional negative balances stuff (prep for pending 2.9 update).  wondering if someone can explain why voiding is still used in some cases like before, but in the specific case of voiding overdues during mark-item-lost it forces the use of account adjustment payments.
11:21 berick from the release notes "The account adjustment payment type will also be used for all libraries, regardless of the state of negative balance settings, in cases where overdue fines are adjusted when an overdue item is marked lost."
11:22 berick what's special about marking items lost?
11:26 kmlussier berick: I think the reasonsing was in c) in this comment - https://bugs.launchpad.net/ever​green/+bug/1198465/comments/28
11:26 pinesol_green Launchpad bug 1198465 in Evergreen "Support for Conditional Negative Balances" [Wishlist,Fix released]
11:27 berick kmlussier++ thanks
11:43 tsbere joined #evergreen
11:45 Dyrcona OK. I think my other image was corrupt. OpenSRF is working on this one.
11:47 berick so if no neg. balance settings are applied, there will be 2 ways to undo a billing in practice, voiding (for most things), then account adjustment for undoing lost overdues.
11:47 Dyrcona With the latest updates.
11:47 berick wondering if this has caused any confusion in the field
11:47 berick the (apparent) inconsistency
11:49 * Dyrcona wouldn't be surprised.
11:51 berick it does appear that removing force_zero on lost overdue voiding would still work (untested, but in theory)
11:52 berick i wonder if that would be a useful feature request for lp
11:52 * berick knows he's late to the neg. balance ball game but whaddya gonna do
11:54 Enjabain joined #evergreen
11:54 berick this also begs the question, why not use 'account adjustment' payments everywhere by default instead of voiding, regardless of whether a site allows negative balances.
11:57 * Dyrcona originally developed it with a "void" payment type.
11:57 Dyrcona But others didn't like that.
11:57 berick interesting, ok
12:05 dbwells berick: Welcome to crazy land, I will be your host :)
12:05 khuckins joined #evergreen
12:06 berick dbwells++
12:06 berick dbwells: if any of my questions or comments are just wrong, please let me know :)
12:09 dbwells berick: obviously there was a lot of back and forth on that bug, but I think what's been said so far is true, and your questions are valid.  I know the existing solution is far from perfect.
12:10 berick dbwells: thanks!  that's quite helpful.
12:11 berick knowledge is more than half the battle in my book
12:11 Christineb joined #evergreen
12:12 berick well, "knowing"
12:12 dbwells Without re-living all 98 comments, I will try to recall the essence of what was done.
12:17 dbwells berick: I keep typing and deleting things, sorry.  Hard to simplify, I guess :)
12:19 kmlussier Once upon a time, there was a branch...
12:20 kmlussier and it promised to get rid of the big, bad negative balances that lurked in the Evergreen world.
12:21 mmorgan joined #evergreen
12:25 dbwells kmlussier++
12:26 dbwells berick: I guess I will just say the crux of the matter came down to disagreement over "partial voids".  If you believe, conceptually, that an event can be partially voided, then we did a lot of work for nothing.  Otherwise, where we ended up, while imperfect, makes some sense.  I am happy to try and answer specfic questions about the code as well, as best as I am able.
12:28 berick dbwells: well, i'm just scratching the surface, so take my questions w/ many salt grains.  in the short term, my concern is just a consistent user experience for those of us not using any of the neg. balance settings, which essentially means never using account adjuments (even though I'd like to).
12:29 berick i think that really just boils down to removing {..., force_zero => 1, ...} when calling void_or_zero_overdues during mark-item-lost
12:34 dbwells berick: The only thing I wonder off the top of my head is whether restoring overdues would work properly if you go that route.  If it doesn't, that is a bug in itself, but this route would give it a much wider path to surface.
12:35 berick thanks dbwells, I'll give it a shot
12:38 Dyrcona Has anyone successfully used marc_export on Debian 8 Jessie or Ubuntu 16.04?
12:39 Dyrcona I'm seeing an issue with looping over bre output and putting US MARC into a file on both of those distros.
12:39 Dyrcona It's just a loop of fretchrow_harshref, make a MARC::Record object, and write it to a file as US MARC.
12:40 Dyrcona The program eats all the RAM on the VM before any records are written.
12:42 Dyrcona fretchrow_harshref....Right, Raggie? Right on, Scoob!
12:42 berick dude, your harshref'ing my mellow
12:42 Dyrcona berick++
12:43 Dyrcona I'll finish setting up Evergreen on this VM and try a marc_export.
12:45 dbwells berick: FWIW, we've been running the setup you are trying to avoid for about a year and half, and I've only gotten one question about it (i.e. adjustments for lost overdues, voids for everything else).  Very different userbase, though (obviously).
12:49 berick dbwells: good to know.
12:56 berick dbwells: looks like the only difference how the overdues are reinstated.  previously, it would un-void, now it leaves the old ones voided, and creates a new, single combined overdue billing.
12:59 dbwells berick: thanks for letting me know.  I'd hoped we accounted for that path.
13:00 berick yeah, it's got a code block for "if this was voided the old-school way"
13:01 berick dbwells: got an example off the top of your head of the controversial "partial void"?
13:03 dbwells berick: In current code, or an earlier revision?
13:03 berick dbwells: either way, just trying to understand your comments up ^-- there
13:05 berick in my usual fashion, if i'm not actively participating, it's all white noise.  just catching up.
13:05 dbwells Okay sure.  One fundamental issue with avoiding negative balances is dealing with partially paid billings.
13:06 dbwells If you have a $50 lost fine, pay $25, then bring the item back, if the library has a "no refunds" policy, then we need to deal with the remaining $25.
13:07 * jeff raises hand
13:07 jeff yup. us.
13:07 jeff sorry.
13:07 dbwells An earlier version of the code applied a $25 "void" to the transaction.
13:09 dbwells Some, including me, felt that a void should be a black-and-white event, essentially saying "this never happened", usual implying it was a mistake.
13:10 dbwells The new code was kept, but the new payment was simply renamed to an "adjustment".
13:11 * miker raises had as one of the others that likes a hard definition for "void" :)
13:13 Dyrcona The void payment was an attempt to void part of a billing. Previously you could only void the whole thing.
13:14 dbwells It was also advantagous for sake of continuity (in interfaces, reports, etc.) to preserve the existing void structure rather than try to replace it.
13:15 dbwells berick: does that help?
13:19 berick dbwells: yes, absolutely.
13:19 dbwells To sum up, void, if kept conceptually simple (black-and-white), was adequate modeled by the existing flag structure, so we tried to keep it that way.  Adjustments are similar in the "balance-goes-down-without-real-payment" sense, but conceptually more flexible to cover more cases.
13:19 * berick got a bit distracted
13:23 kmlussier All of this negative balance talk reminds me of things missing from the web client.
13:23 * kmlussier files LP bugs before she forgets again.
13:25 dbwells berick: The case of switching voids to adjustments for lost item overdues was not functionally necessary.  It was an attempt to take advantage of a richer set of tools to hopefully, eventually, actually have *more* clarity.  A guy can dream, can't he?
13:28 berick dbwells: also good to know.  and I agree in principle.  it's better.
14:12 NawJo joined #evergreen
14:13 Dyrcona Bmagic: Have you encountered any issues with MARC on Ubuntu 16.04? Am I right you're running Ubuntu 16.04?
14:13 Dyrcona csharp: I guess the same question goes to you, too.
14:14 Dyrcona jeff and I are poking and it's looking like issues with Encode.pm at the moment.
14:15 Dyrcona jeff is looking at Debian 8, and sees similar things, but slightly less bad in some ways. :)
14:17 jeff what i'm seeing is that if i try to stick with the defaults of USMARC and MARC8 enoding, the output file seems to have internal length issues that are likely character/byte differences between MARC8 and UTF-8 characters.
14:18 jeff if i pass -e UTF-8 to marc_export, the problem appears to go away.
14:19 jeff ~255k records exported in 7m38.728s
14:19 pinesol_green jeff: I am only a bot, please don't think I'm intelligent :)
14:19 Dyrcona If I pass -e UTF-8, I still get issues that look like byte length problems.
14:19 Dyrcona Difference is I'm using Perl 5.22 and jeff is using Perl 5.20.
14:20 Dyrcona We get some similar messages from yaz-marcdump afterward, but I get some that he doesn't.
14:21 Dyrcona Directory offset 24: Data out of bounds 8532 >= 3239
14:21 Dyrcona That's one I see that jeff doesn't.
14:22 Dyrcona If I dump xml and then convert to usmarc with yaz-macdump, things are better.
14:22 Dyrcona Though some of the records fail to parse.
14:22 Dyrcona So, looking like length calculations and Encode.pm in MARC::Record, maybe...
14:25 kmlussier Is this related at all to bug 1584891 ?
14:25 pinesol_green Launchpad bug 1584891 in Evergreen 2.11 "marc_export -i gives incorrect record length in the leader when call numbers include UTF8 characters" [Undecided,Fix committed] https://launchpad.net/bugs/1584891
14:26 * kmlussier has nothing else to offer, but saw similar words in the bug report.
14:28 Dyrcona Well, it could be, but I've seen really nutty behavior in my Boopsie extract program.
14:28 Dyrcona It just uses MARC::Record on the out put of a database query.
14:30 Dyrcona Actually, no. It has to be something else.
14:31 Dyrcona I'm using master fetched as a couple of hours ago.
14:32 kmlussier OK, worth a shot. I'll go back to figuring out why I haven't received e-mail all day.
14:33 Dyrcona Yeah, that's probably more immediately important. :)
14:33 Dyrcona I'm gonna take a break for a bit, myself.
15:00 mmorgan joined #evergreen
15:01 mmorgan1 joined #evergreen
15:09 * csharp just hit the sms.cricket.com issue that Stompro mentioned a couple of weeks ago: http://irc.evergreen-ils.org/​evergreen/2017-02-24#i_291773
15:09 csharp from this source: https://mfitzp.io/list-of-email-to-sms-gateways/ it's reported not working as of 2015
15:10 csharp anyhoo, I'm thinking of opening a bug to remove it from the list of carriers
15:10 Stompro csharp, I just disabled the cricket provider and emailed all the users that were trying to use it, which was only a small number for us, like 10.
15:10 csharp cool
15:10 csharp it's more for us, but I'mma have a similar approach
15:11 Dyrcona It should be removed from the default list, IMO.
15:11 csharp yeah
15:23 jeff for those using email to sms gateways, how much volume do you see in a given day/week?
15:24 jeff and how much grouping of notifications do you do -- mostly one notification per hold, perhaps unless several hit within the interval where you run the notifications?
15:25 jeff (i.e., grouped by usr or sms number, but only if there are several that become available between A/T runs from cron)
15:27 jeff Dyrcona: zero errors or warnings emitted by yaz-marcdump on my marc_export of all records.
15:27 jeff marc_export -a -e UTF-8 > export-all.mrc
15:27 jeff followed by
15:28 jeff yaz-marcdump -n -p export-all.mrc  | grep -v '^<!-- Record .* -->$'
15:28 jeff which i could have probably simplified to:
15:28 jeff yaz-marcdump -n export-all.mrc
15:32 csharp jeff: I'll have to do some research to get volume - it's a good question to address and terran's and my session at the EG conf </shameless_plug>
15:33 Enjabain joined #evergreen
15:34 csharp jeff: we group by sms number for hold requests, running every half hour
15:34 csharp and by usr id for circ notices
15:35 Dyrcona jeff: OK.
15:35 csharp they run at 8am, 12pm, and 4pm each day
15:35 csharp (we don't want to be texting people in the middle of the night)
15:36 Dyrcona What I don't get is why something that worked fine on Trusty and Wheezy eats all the RAM on Jessie and Xenial and it's basically doing what marc_export does, only less...
15:36 NawJo_ joined #evergreen
15:36 csharp "Boopsie extract" sounds like 19th century snake oil for babies :-)
15:37 Dyrcona That was my main reason for testing marc_export, to see if it used all the RAM.
15:37 Dyrcona :)
15:37 Dyrcona Well, I think they named Boopsie after Betty Boop.
15:37 Dyrcona So, close....:)
15:38 csharp oh - interesting
15:38 Dyrcona But, marc_export of xml and converting with yaz-marcdump seems to be working for me.
15:38 berick csharp: haha
15:38 Dyrcona Well, better than either the Boopsie script or marc_export to usmarc.
15:39 bshum One of the CT librarians called it "oopsie" once.
15:39 berick getcha boopsie extract, guaranteed to cure festering humors
15:39 Dyrcona berick: I think it would be for more...um...intimate things. :)
15:40 Dyrcona Butanyway.
15:40 csharp "from 100% organic free-range Boopsie"
15:40 Dyrcona It's here if anyone wants to poke it, which I doubt: https://github.com/Dyrcona/boopsie
15:40 berick cure your woopsies with a dash of Boopsie
15:41 csharp berick++
15:41 Dyrcona I still suspect that there are issues with Encode and/or MARC::Record and Perl 5.22 on Ubuntu 16.04.
15:41 Dyrcona berick++ :)
15:41 berick it's fun not to work
15:42 Dyrcona I'll try it with concerto data later. We have some French and Italian records with accents.
15:42 csharp srsly
15:42 Dyrcona it's work not to fun?
15:42 berick Dyrcona: that checkouts out.  transitive property
15:43 Dyrcona :)
15:43 bshum Huh... is the live tests system unhappy?  Can't access the page, and no test success message from expected 5 am run this morning
15:43 Dyrcona heh heh...he said transitive....
15:49 rlefaive joined #evergreen
15:51 jeffdavis kmlussier: ebook API release notes pushed to working/user/jeffdavis/lp1541559​-ebook-api-phase1-release-notes
16:16 Enjabain joined #evergreen
16:23 kmlussier jeffdavis: Thanks!
16:23 kmlussier jeffdavis++
16:26 Jillianne joined #evergreen
16:32 mmorgan joined #evergreen
17:03 mmorgan left #evergreen
17:37 Enjabain joined #evergreen
17:59 khuckins_ joined #evergreen
18:24 kaffenkj joined #evergreen
18:25 khuckins__ joined #evergreen
18:27 Guest34221 joined #evergreen
23:46 kaffenkj joined #evergreen

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