Evergreen ILS Website

IRC log for #evergreen, 2016-08-25

| 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
02:32 StomproJ joined #evergreen
06:40 rlefaive joined #evergreen
07:07 agoben joined #evergreen
07:16 rjackson_isl joined #evergreen
07:19 csharp miker: release notes added to the top of my working branch
07:35 kmlussier joined #evergreen
07:36 kmlussier csharp: Are you around to answer a quick question about your release notes?
07:43 csharp kmlussier: yep, what's up?
07:43 * csharp has never done release notes before, so is open to corrections/critiques
07:44 kmlussier csharp: I stopped following the conversation about a week ago. Is the item given the 'canceled transit' status even when it is aborted at home? I know there was discussion about it, but I don't know what the resolution was.
07:45 kmlussier csharp: They look great! But if it only happens with canceling transits remotely, I think it deserves a mention.
07:45 * kmlussier needs to get out of the habit of saying 'abort' now, I guess.
07:46 csharp kmlussier: yes, it doesn't know/care if it's at home - parts of the fix to bug 1316666 were picked in, but not that part afaik
07:46 pinesol_green Launchpad bug 1316666 in OpenStack Dashboard (Horizon) "wrap_list is not honored for not-editable cells" [Low,Fix released] https://launchpad.net/bugs/1316666 - Assigned to Davide Guerri (davide-guerri)
07:46 csharp ugh - wrong bug
07:46 kmlussier csharp: OK, then, they look good. I'll merge those right night before I disappear for a few days.
07:46 csharp bug 1306666
07:46 pinesol_green Launchpad bug 1306666 in Evergreen 2.9 "When Aborting a Transit, items should not automatically get a status change." [Low,Fix committed] https://launchpad.net/bugs/1306666
07:47 csharp https://bugs.launchpad.net/ever​green/+bug/1306666/comments/26 explains what miker did
07:49 ericar joined #evergreen
07:49 kmlussier csharp: Thanks!
07:50 pinesol_green [evergreen|Chris Sharp] LP#1613374 - Canceled Transit status Release Notes - <http://git.evergreen-ils.org/?p=​Evergreen.git;a=commit;h=18c769a>
07:50 csharp kmlussier: thank you!
07:50 kmlussier csharp++
07:50 kmlussier We're looking forward to this new feature. :)
07:50 csharp good
07:51 csharp I was hoping that the fix for bug 1612752 would be accepted as well, but I have some additional ideas about it
07:51 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)
07:52 csharp e.g., how to display them to staff, maybe also add a "canceled_by" field that records the canceling staff ID
07:52 csharp our libraries *love* knowing who did things
07:52 kmlussier Yes, I think the canceling staff id could be useful.
07:52 csharp @blame staff who do things
07:52 pinesol_green csharp: staff who do things 's bugfix broke csharp's feature!
08:18 mrpeters joined #evergreen
08:20 sarabee joined #evergreen
08:28 mrpeters joined #evergreen
08:38 rlefaive joined #evergreen
08:39 ericar_ joined #evergreen
08:44 mmorgan joined #evergreen
08:47 bos20k joined #evergreen
08:58 StomproJ Is there any way for staff to easily know if a customer uses the my account feature of the catalog?  Looks like the last activity hover info shows the last authentication, which can sometimes show that, as long as that was the last thing?
09:02 tsbere StomproJ: If you mean "personally use" I would say "no" as some won't actually be using it, but have instead signed into screen-scraper services that use it for them
09:03 Dyrcona joined #evergreen
09:08 bos20k joined #evergreen
09:15 gsams_ joined #evergreen
09:17 mmorgan StomproJ: I believe that "Last Activity" in the patron record summary is the only place in the client (short of reporting) where you can get to data in the usr activity table. And it's just the most recent activity.
09:18 dbwells joined #evergreen
09:22 maryj joined #evergreen
09:32 StomproJ tsbere, Good point there.
09:35 StomproJ mmorgan, thanks, we are just getting around to looking at using the message center, but we are not sure how to determin if someone uses the catalog and would ever view such messages.
09:35 jeff StomproJ: are trying to encourage online account usage for renewals and holds and such, and just want front line staff to know if a patron already does all that so you can skip the promo talk?
09:35 jeff StomproJ: ah, i see.
09:36 jeff does message center have a concept of displayed/not-displayed-yet? i haven't looked closely.
09:37 StomproJ jeff, There is a read date that is set when a message is opened.
09:38 graced https://esilibrary.com/documentatio​n/2-8-patron-message-center/#sthash.jv7hhwXd.dpbs
09:39 graced Not sure if those have gotten into the official docs yet... ^^
09:40 StomproJ I wonder if anyone else would find an enhancement to the patron record that just shows the last opac login date... or based on any other activity type you want.
09:41 mmorgan StomproJ: another clue would be, if the patron has holds, the "Staff Hold" field in the column picker. If that's False, then the patron placed it in the catalog.
09:42 * mmorgan thinks such an enhancement could be useful.
09:42 rhamby You could run a report based on rewewals and insert something into the patron alert that says if they've renewed in the OPAC or not.  It's a big of a kludge and only partial but it's info.
09:43 mmorgan Related question: Does anyone see it as a problem that the Last Activity does not include circ activity?
09:44 StomproJ rhamby, thanks, that could also work.  Why would you base it on renewals vs the user actvity data?  To weed out the screen scrapers that tsbere mentioned?
09:44 tsbere StomproJ: Half the screen scrapers I know of offer "renew for me". A couple will place holds for you....
09:44 csharp mmorgan: I do, actually - it's very confusing if circ/hold activity is not included in that displayed date (at least with that particular label describing it)
09:45 csharp mmorgan: changing the label to something more specific would probably solve the issue
09:46 jeff rhamby: if you're running a report, you already have access to the ewho for tpac login. no need to kluge it to "did an opac renewal". :-)
09:46 tsbere mmorgan / csharp: I only see the constant "why not!?!?!" as a problem. The answer, BTW: If configured incorrectly you can no longer usefully anon circs.
09:46 rhamby StomproJ: simplicity really
09:46 jeff i can see benefit in being able to add activity type dates to the display, or to be able to expand the display to show all activity types.
09:47 StomproJ tsbere, are there currently any API's that would provide access to the functions that the screen scrapers need?  If there was and easier method for them to do what they need, maybe their access could be classified differently.
09:47 jeff similar to how you can add arbitrary patron stat cats to the summary, etc.
09:47 rhamby jeff: it depends if you want to look at opac login versus using it for renewals.  I've seen lots of patrons that would log in to search and see what they have out but still call in to do renewals.
09:48 tsbere StomproJ: There are APIs. At least two screen-scrapers I know of *used to use the APIs* but decided that screen scraping was easier.
09:48 csharp might be more useful if there was a last_activity_time column on the actor.usr row that gets updated anytime they do anything
09:48 jeff StomproJ: in my experience, at least some vendors don't care about APIs since they have to screen scrape everybody else -- they don't want to do something "special" just for Evergreen. :-)
09:48 rhamby Humans are strange creatures.  Library using humans no less so, just more worth working with some of the others.
09:48 jeff the landscape will change again in the future. :-)
09:48 StomproJ jeff, we should make it attractive by randomly changing the html then.
09:49 jeff but if you're interested in detecting screen scraping services vs patron logins... that can be done via a few methods, like useragent and source IP. it'll vary by vendor, etc.
09:50 jeff StomproJ: yeah, I've zero interest in a screen scraping arms race. I don't see any benefit to the library or to patrons.
09:50 StomproJ jeff, i wasn't serious.
09:51 jeff StomproJ: sometimes it's hard to tell on irc. :-)
09:51 ericar joined #evergreen
09:51 StomproJ i'll use joke tags in the future.
09:52 mrpeters joined #evergreen
09:52 csharp actually I'm liking the last_activity_time idea - it would alleviate the need for sql scripts like this one to set user inactive: http://git.evergreen-ils.org/?p=contrib/pines.​git;a=blob;f=sql/set_patrons_inactive.sql;h=a5​06947198f1b219482bc82bc96d72e461c4a95f;hb=HEAD
09:52 * tsbere has, on a personal site, actually changed things seemingly randomly every 24 hours to annoy a screen scraper.
09:53 jeff csharp: which last_activity_time idea?
09:53 csharp jeff: 09:48 < csharp> might be more useful if there was a last_activity_time column on the actor.usr row that gets updated anytime they do anything
09:53 StomproJ Maybe the screen scrapers will start supporting the message center, as long as the customer is getting the message.
09:53 jeff csharp: oh. i think i see it above.
09:53 * jeff nods
09:54 StomproJ My auditor table is going to love that, so many new versions!
09:54 tsbere csharp: I can see it making *some* of that not needed. You still want to check things like "do they have open circs?" and "are they in the right profile group?"
09:54 jeff csharp: i see lots and lots of audit table bloat, and a few privacy issues.
09:54 miker StomproJ: exactly
09:54 jeff csharp: there's a reason why actor.usr_activity is its own relation.
09:55 jeff csharp: several, probably. that's just one of them. :-)
09:55 csharp jeff: yeah, table bloat occurred to me too
09:55 * tsbere has set up triggers to update a "last circ month" extend reporter table for MVLC
09:55 csharp tsbere: right
09:56 jeff adding more writes to circ ops in general is something we might want to try and avoid without good reasons, but a day-granular activity type for circulations could be implemented.
09:57 jeff this is something where a check for "already has one recorded for today?" could be polled (read, no write!) and stored in memcache, so you'd only poll the db once in a theoretical "patron checks out several items at the desk" scenario.
09:57 miker jeff: well, that can be an out-of-band thing. after respond_complete
09:57 jeff miker: good point.
09:57 miker "that" being "record circ activity"
09:58 jeff miker: could also be a nightly job, but that would leave a hard-to-explain window of time where the data was stale.
09:58 berick miker++ # merge master mike
09:58 csharp haha
09:59 miker of course, a view (or reporter source) over actor.usr_activity and action.{stuff} might be just as simple
09:59 csharp miker: yes!
10:00 jeff miker: would a view like that result in an empty value for "last circ date" given a patron whose circs have all been aged?
10:01 miker jeff: that's a problem, thus actor.usr_activity ;)
10:01 jeff exactly! :-)
10:01 miker that was always meant to expand in scope. just like A/T ... just infrastructure, plug stuff into it
10:01 tsbere miker: I think the entire headache here is a combination of "usr_activity doesn't track circs" and "if it does track circs badly you may as well not anon circs at all"
10:02 * csharp was envisioning a view that basically coaslesces things until the most recent date emerges and we just use that
10:02 miker tsbere: why would it track circs badly?
10:03 csharp "last date/time somebody did X" can be gathered from many other sources/methods, so I was thinking of just like a single date
10:03 tsbere miker: If you don't keep just the last circ you probably have enough information from the user record and timestamp to de-anon all their circs for one
10:03 miker csharp: that's the (eventual) point of aua. MAX(event_time)
10:03 jeff tsbere: knowing the date a patron last circulated an item does reduce the search space for "who could have possible been responsible for this aged circ", but i can also see configurable granularity for the activity date stamp. day by default, month or year could also be useful and might address some of the concerns you have... or I'm wrong, and you have different concerns.
10:04 tsbere jeff: My solution has been, as I mentioned earlier, a "last circ month" extend_reporter table and a trigger on action.circulation to populate it. Not that I need the info that frequently.
10:04 miker tsbere: we can ... what jeff said. no reason we can't use something other than now() when inserting into aua
10:04 jeff tsbere: great! glad that's working for you! :-)
10:04 jeff tsbere: do you still have concerns with what we've been spitballing here, other than "I already have a working solution here"?
10:04 * miker thanks PG for the 'today' timestamp literal :)
10:05 tsbere jeff: I have no problem with adding something like my last circ month to the usr_activity table instead. In fact, I have no problems with providing my trigger to re-purpose it for such a purpose if desired.
10:06 tsbere jeff: I just don't want someone to go and add to one feature in the system (usr_activity tracking) and make that compromise another (anoned circs)
10:06 * jeff teaches OpenILS::SIP that patrons can have more than one library card number
10:07 * tsbere thought that OpenILS::SIP already knew that
10:07 jeff renewal logic for checkout does not know that.
10:08 jeff "Oh honey, he's teasing you. Nobody has two library card numbers."
10:08 miker tsbere: a trigger would link them, though. tcid/xmin/xmax would link them temporally, even if the user data is granularized. if we're going to be paranoid, let's go all the way ;)
10:08 csharp jeff: ha!
10:09 csharp @quote add < jeff> "Oh honey, he's teasing you. Nobody has two library card numbers."
10:09 pinesol_green csharp: The operation succeeded.  Quote #159 added.
10:12 Dyrcona jeff++
10:12 Dyrcona heh
10:39 berick before I go code diving.. authority record 008 positions 14/15 -- use as main/added entry and/or subject entry.  does EG support treating a single authority record as both a main entry and a subject entry record?
10:39 berick or in other words, can a bib 1XX and 6XX both link to the same authority record?
10:40 berick assuming the auth record has 008 #14=a and 008 #15=a
10:41 miker berick: it's ignorant of 008-14/15, so yes by default
10:44 berick miker: thanks
10:48 Dyrcona Is anyone planning any last minute bug pushes today?
10:49 Dyrcona And, am I right that dbwells is going to build the 2.11-beta tarball today?
10:54 jeff one of my favorite things about Multiplex SIPServer? the potential for code changes without client disconnects.
11:03 berick miker: futher exploration confirms your 008 14/15 assessment.  thanks for pointing me in the right direction.
11:04 gmcharlt miker: any objection if I just push a follow-up to 1612274 that tags a string for translation/
11:04 gmcharlt ?
11:04 miker gmcharlt: seems like a bug fix to me :)
11:04 miker dbwells: you haven't done the translation dance, have you?
11:07 * gmcharlt also notes bug 1616882
11:07 pinesol_green Launchpad bug 1616882 in Evergreen 2.9 "string missing in translation file" [Low,Confirmed] https://launchpad.net/bugs/1616882
11:09 Dyrcona I saw that one last night. I'll defer to others if it should be pushed today.
11:10 Dyrcona I have not yet started on builing and testing a tarball. I'll need to update the release notes, etc.
11:11 Dyrcona Right now, I'm preparing a vm to do the testing.
11:12 gmcharlt I'll be doing my release-cutting in mid-afternoon
11:15 Dyrcona I'll wait until then, too.
11:16 Dyrcona Might as well get the translation fix in, even if it won't make a difference to 2.9...
11:16 Dyrcona I have to configure all the prerequisites on the vm, so might as well do that and then have lunch. :)
11:19 * Dyrcona installs OpenSRF 2.4.1.
11:19 StomproJ Hello, I'm trying to figure out how to disable the use of the reshelving status?  Is that possible?
11:20 Dyrcona Before I do that I'll have a look at that string fix. If it looks good I'll push so it's there for the i18n step for the beta.
11:20 Dyrcona StomproJ: No, it isn't possible.
11:21 Dyrcona Not without code changes.
11:22 mmorgan StomproJ: You can control how long items remain in Reshelving status, though.
11:25 mmorgan StomproJ: What are your issues with the Reshelving status?
11:26 StomproJ mmorgan, not in my experience, I was instructed by our implementation team to only run the reshelving_complete script during closed hours, because otherwise there is a chance that a checkout happening at the same time would conflict with the process.  Or something along those lines.
11:26 miker jeff: my favorite thing is not wasting 100MB per quiescent session :)
11:26 StomproJ mmorgan, so even though we want just a 2 hour reshelfing status, it is all day.
11:27 mmorgan StomproJ: Actually, that rings a bell.
11:28 miker https://bugs.launchpad.net/evergreen/+bug/1018011
11:28 pinesol_green Launchpad bug 1018011 in Evergreen "Incorrect copy status caused by reshelving process colliding with item checkout" [Medium,Confirmed]
11:28 mmorgan miker++
11:28 * mmorgan was a second too slow :)
11:29 miker the branch on that bug, though, can hold up circs that collide (two writers on the same copy)
11:29 Dyrcona StomproJ: A worth wishlist entry might be something along the lines of assigning a copy status to use at checkin.
11:29 StomproJ Thanks miker++
11:31 StomproJ Although, maybe this isnt' a big problem for us since we have a small system with a powerfull db server.  If the reshelving complete only takes a few seconds to run, maybe we can risk it.
11:32 jeff miker: well, that too!
11:32 pinesol_green [evergreen|Galen Charlton] LP#1616882: mark string as translateable - <http://git.evergreen-ils.org/?p=​Evergreen.git;a=commit;h=cb297cf>
11:32 pinesol_green [evergreen|Galen Charlton] LP#1616882: mark another string as translateable - <http://git.evergreen-ils.org/?p=​Evergreen.git;a=commit;h=8d94c3a>
11:33 StomproJ Looks like it takes 12 seconds for it to run once a night for 4000 updates, but only 0.41 second with 62 items.
11:33 csharp seems like it would be pretty simple to make 'Reshelving' the default status for checked in items but to add YAOUS to allow people to override it with a chosen status
11:34 jeff miker: this warning in Net::Server::Multiplex docs caught my eye yesterday: "should only be used with protocols that are guaranteed to be able to respond quickly on a packet by packet basis. If determining a response could take a while or an unknown period of time, all other connections established will block until the response completes."
11:34 * csharp dons hazmat suit to dive into acq code
11:35 jeff miker: in how SIPServer is using Multiplex, does this mean that a SIP message taking several seconds to process for client A will hang processing of requests for client B?
11:41 Dyrcona So, I'm looking at bug 1613709, and I wonder if want that fixed before i18n is done?
11:41 pinesol_green Launchpad bug 1613709 in Evergreen "Library card request - untranslated error message" [Medium,Confirmed] https://launchpad.net/bugs/1613709
11:47 bmills joined #evergreen
11:48 bmills joined #evergreen
11:59 jihpringle joined #evergreen
12:06 jihpringle joined #evergreen
12:13 miker jeff: sorry, lunch.  nope, not at all.  highest cost action before moving on to the next message is a fork, and then only for new or quiescent sessions. other than that, it's just a couple hash lookups in the main process, and a write to a pipe
12:14 miker jeff: the naive user of multiplex does everything in one process. we just do connection brokering in the main process, and everything heavy in forked workers. benefit is that quiescent sessions don't waist resources (and most sessions are quiescent, even for folks with sorters and such)
12:18 miker Dyrcona (and everyone else looking at i18n stuff, thanks!): i18n commits get a pass from me, esp. in early beta -- IMO it's more important for us (with relatively low translation rates) to make new strings available for translation by GA than to have a perfectly locked translation target as of beta cut-off. I'm open to opinions, though, if folks think that will cause more harm than possible good
12:20 bshum +1 to that approach, we only do template syncs during the period between beta and release, so any fixes for strings is better now than six months or more from now.
12:23 jeff miker: aha! thanks for the explanation. i was pretty sure based on gut/experience that the warning didn't apply in this case, but I was having a hard time explaining it to myself. :-)
12:25 jeff also, i'm pretty sure that the new workstation support breaks when the auth session expires, and that we can probably stuff the workstation in the ils state hash to preserve it in those cases.
12:26 jeff ("breaks" as in "silently logs back in without a workstation")
12:27 jeff i'll test / branch
12:31 JBoyer jeff, do we not just require the client to log in again on an auth timeout?
12:34 jeff JBoyer: not a sip client, at least not in the case of Multiplex
12:35 JBoyer Well then I suppose that case was overlooked. :/
12:35 JBoyer Curses!
12:35 jeff JBoyer: SIPServer creates a new worker child and re-uses the auth token. if the auth token does not correspond with a valid session at the time of the child being created, a new login is performed. at that time the workstation would be lost.
12:36 miker jeff: ah, yes, indeed. your fix is what's needed
12:36 jeff JBoyer: there's a different scenario (again, just talking about Multiplex personality right now) where a worker will crash when it tries to use an invalid auth token, and in that case the sip client usually times out or hangs.
12:37 miker jeff: haven't seen that. do you know where it's failing? (line of code, or method)
12:37 jeff that's generally not encountered unless someone's trying to break things, unless you do something silly like set worker timeout to be something greater than your auth session timeout.
12:38 dbwells Dyrcona, miker, et. al: Yes, I'll be starting the build for 2.11-beta around 2:00pm today.  Anything up to that point will get in.
12:38 jeff (and have a sip connection that's idle long enough for the session to expire from memcached but still have an active worker child)
12:40 miker jeff: ah! ok, that makes sense. I think the default worker timeout is 30 or 60 seconds ... there's some use in raising it to, say, 90 (some products "ping" once a minute) but not really any use in going higher than that
12:40 miker dbwells: thanks!
12:40 jeff miker: i think the fix for the (rare) condition is to teach more of the Evergreen SIP driver to retry on auth failures, or possibly introduce a more general concept of "try again" from a worker.
12:41 jeff default worker idle timeout is 5 seconds
12:41 miker maybe ... I'd be fine with a documentation-based fix
12:42 jeff there was another related issue in that a crashed client looks to the parent the same as a idle timed out child. the parent should probably terminate the connection with the client when a worker crashes.
12:42 * jeff looks at notes from yesterday evening
12:44 jeff Ah. I think my only idea thus far for that one was "we got a SIGCHLD from a child far too soon for it to have idled out, it must have crashed"
12:44 jeff which is... imperfect.
12:45 jeff short of passing success to the parent somehow, or setting a "if you are reading this then i have failed in my mission" marker in memcached that the parent checks for when mourning a child...
12:46 jeff There's probably another approach. As it stands, the client receives no response and either times out or hangs.
12:56 JBoyer jeff, did I understand correctly that you're working on that fix? I found where it belongs but I'll let it go if you're in process.
12:56 Christineb joined #evergreen
12:58 jeff yeah, i'm in there. what do you think -- re-open and comment on original bug for the feature, or new bug?
12:58 JBoyer As for storing the location in state, I believe it's already in $self->{login}, it's just that verify_session doesn't use it.
12:58 jeff JBoyer: also, i was testing behavior when a location code doesn't correspond with a workstation.
12:58 jeff JBoyer: did you already test or have thoughts on that?
13:00 collum joined #evergreen
13:01 JBoyer I know it fails in a similar fashion to other issues, such as an expired / missing Eg account, etc. I wasn't too worried about it at the time, but I don't see a problem with retrying sans workstation. The alternative is you just insert whatever workstations you need into your db if your clients force you to use a hard coded location. (seems unlikely)
13:03 Dyrcona Hmm.. I just did a fresh install of osrf_rel_2_4_1 from git on my Ubuntu 14.04 vm and osrf_control --start-all appears to hang.
13:05 Dyrcona Hmm. Must have messed up the jabberd config.
13:09 JBoyer jeff, forgot to mention, I guess since the bug hasn't been set to fix committed I'd say add a comment and ping miker when it's ready.
13:09 JBoyer Thanks a lot for the catch, too.
13:10 JBoyer jeff++
13:10 miker WORKSFORME
13:12 jeff hrm. i may have been imagining it, but did COPY_NEEDED_FOR_HOLD ever throw on checkout, or just renewal?
13:13 JBoyer jeff, I thought there was a setting that could do that. I'm not sure because if it does exist it's user hostile enough I'd never let it be used.
13:17 JBoyer never mind, I appear to have made up that bad idea from whole cloth, or it was something someone asked about in the JS circ days.
13:20 maryj joined #evergreen
13:20 Dyrcona So, I'm getting a timeout trying to connect to ejabberd, and everything looks OK.
13:28 pgardella joined #evergreen
13:28 jeff JBoyer: yeah, anything's possible in circ script days, but from what I can see neither stock nor our old MIEG circ scripts ever threw (that particular event) on checkout, just renew.
13:29 csharp berick: howdy - do you have a favorite Linux-installable or web-based EDI reader?
13:29 jeff JBoyer: the ability to use an org unit setting to block/permit renewal when "needed for a hold" was new in 2010.
13:29 berick csharp: I use Open-ILS/src/support-scripts​/test-scripts/edi_reader.pl
13:30 jeff it gets a little murky, but COPY_NEEDED_FOR_HOLD may have even been thrown at one point instead of "copy is on holds shelf". :-)
13:30 csharp berick: heh - I didn't know about that - thanks
13:30 berick csharp: spits out JSON that's fairly human-readable
13:30 csharp works for me
13:32 Dyrcona Well, that wasn't helpful...
13:34 pgardella Afternoon all! We're having some problems with the osrf_router.  It is crashing about every 10-15 minutes today.  The last message in the logs is "Removing router class '*' because of a bad top-level file descriptor" where the * is many different things.  It's been crashing about every 3-5 days recently, but today, it's every 10 minutes.  Anyone have a suggestion on what might be going wrong? It looks like the problem is with the socket to
13:35 csharp pgardella: your message got truncated at "is with the socket to c"
13:35 pgardella onnect to ejabberd, but I don't know where to go from there.
13:36 pgardella looks like apparmor is deniying access to ejabberdctl
13:36 csharp ewww - I haven't seen that
13:36 csharp (we're on Ubuntu 14.04, if that helps)
13:37 csharp pgardella: have you changed anything, configuration-wise?
13:38 pgardella csharp: We added some marc templates today, that's it.
13:39 pgardella The apparmor message is: [882032.001065] audit: type=1400 audit(1472145235.632:87): apparmor="DENIED" operation="connect" profile="/usr/sbin/ejabberdctl//su" name="/run/dbus/system_bus_socket" pid=6556 comm="su" requested_mask="wr" denied_mask="wr" fsuid=0 ouid=0
13:39 pgardella now, we could obviously disable apparmor for ejabberdctl, but that's not getting to the underlying cause
13:42 csharp pgardella: do you see a profile for ejabberd in the output of "aa-status"?
13:42 pgardella yes, under enforce for both profiel and processes
13:44 csharp looking at 2 of our app servers, ejabberd is *not* in the output of aa-status
13:45 csharp (we don't enable apparmor beyond the default)
13:45 pgardella I doubt we did either.  But we're on 16.04, so it may have automatically added it on install
13:46 csharp pgardella:
13:46 csharp sorry http://askubuntu.com/a/541841
13:46 pgardella csharp: Yep. Was just looking at that :)
13:46 csharp hehe
13:47 csharp I would just disable the profile since it sounds like you weren't meaning to use it in the first place
13:47 * csharp braces for slapdowns from security gurus
13:48 csharp there are similar issues with selinux on Fedora/CentOS and most devotees hate the "just disable it" solution
13:49 pgardella Yes, I'm sure they do
13:49 pgardella OK, disabled.  We'll see what happens from here.
13:49 csharp pgardella: fingers crossed!
13:49 Dyrcona I don't recall every doing anything with apparmor and ejabberd on any release of Ubuntu.
13:53 pgardella dyrcona: do you have it enabled though?
13:53 Dyrcona Likely not.
13:55 Dyrcona Typos.....
13:55 Dyrcona That's my problem with ejabberd. I typoed the hostname in /etc/hosts
13:56 * Dyrcona starts over.
14:01 pinesol_green [evergreen|Jason Stephenson] LP#1613709: Make DOB validation alert failure translatable. - <http://git.evergreen-ils.org/?p=​Evergreen.git;a=commit;h=83a9520>
14:02 csharp yeah, I've learned if you change the hostname on the server after ejabberd is installed, it's lotsa work to fix
14:03 Dyrcona csharp: Well, that wasn't the issue. The hostname hadn't changed. I just typoed it in one place, but not seeing that, I messed with a lot of other configuration and made the situation worse.
14:03 csharp ah
14:04 Dyrcona So, rather than clean all that up, I'll just start over.
14:04 Dyrcona It's easy to build a new vm.
14:04 csharp definitely
14:05 * csharp uses virsh snapshot-create a lot
14:05 gmcharlt bug 1617017 == easy i18n pull request
14:05 pinesol_green Launchpad bug 1617017 in Evergreen 2.9 "untranslatable "Export List" string in TPAC" [Low,Confirmed] https://launchpad.net/bugs/1617017
14:05 Dyrcona Yeah, I probably should have made a snapshot before starting.
14:07 Dyrcona This time, I'll copy and paste instead of type in the hostname. :)
14:08 gmcharlt Dyrcona: I've reviewed 1496556 and intend to backport it to rel_2_10 as part of today's release; are you in a position to also including that in the 2.9 release?
14:09 gmcharlt if so, I'll push it to both rel_2_10 and rel_2_9
14:09 Dyrcona Sure! Thanks!
14:10 * Dyrcona is still working on getting a working vm to test the tarball.
14:10 * Dyrcona hasn't made a tarbal, yet.
14:11 gmcharlt OK
14:13 pgardella left #evergreen
14:14 remingtron joined #evergreen
14:29 Dyrcona And, OpenSRF works....
14:31 collum_ joined #evergreen
14:41 pinesol_green [evergreen|Galen Charlton] LP#1617017: make another TPAC string translatable - <http://git.evergreen-ils.org/?p=​Evergreen.git;a=commit;h=3fb5406>
14:43 Dyrcona All right I think that's the last one for today. :)
14:46 gmcharlt ditto - I'm not pushing anything else into rel_2_10 today beyond the normal stuff related to the release
14:47 gmcharlt well, I lie, I believe there might be a strings update from dbwells and/or bshum
14:57 dbwells gmcharlt: working on the requested release notes for that now
15:01 gmcharlt dbwells++
15:03 pgardella joined #evergreen
15:12 jihpringle joined #evergreen
15:35 montgoc1 joined #evergreen
15:39 jeffdavis This is puzzling. I'm trying to send a POST request to osrf-http-translator from JS and getting a 404, but using CURL to send a POST request directly works just fine.
15:39 pinesol_green [evergreen|Dan Wells] Translation updates - po files - <http://git.evergreen-ils.org/?p=​Evergreen.git;a=commit;h=568cea9>
15:48 Dyrcona So, should I do translation updates for rel_2_9 also?
15:48 Dyrcona Ah, never mind, a little birdie tells me that I can't.
15:49 dbwells :)
15:49 Dyrcona Strings have likely drifted too much.
15:50 dbwells Yeah, this is one last hurrah for 2.10.  After we commit the newpot changes, all bets are off.
15:53 jeff two different code paths for SIP renewals... two different sets of client UI strings... lovely!
15:54 jeff jeffdavis: first thought, use chrome dev console to examine the request that is 404ing, even comparing "copy as curl" and comparing / re-running the request until you find clues?
15:57 Dyrcona Our release notes coordinator is not around or resigned. How are we coordinating release notes?
16:00 jihpringle joined #evergreen
16:15 jeffdavis jeff: ah, I didn't know about Copy as cURL, that's handy
16:18 jeff it is exceptionally verbose, but sometimes that's handy -- remove the useragent, try again, remove cookies, try again, remove blah... etc.
16:19 gmcharlt Dyrcona: I'll write the release notes for 2.10; should be pushed by 5ish
16:19 gmcharlt feel free to crib
16:19 Dyrcona All right. I've already started working on notes for 2.9.7, but I think it would be good to have the same wording for the same bugs.
16:19 Dyrcona I'll wait and crib yours. ;)
16:20 jeff i feel as if this sip client is messing with me -- fair, since i've been messing with it. :P
16:25 jeff now i'm certain of it.
16:27 jvwoolf joined #evergreen
16:27 pinesol_green [evergreen|Ben Shum] LP#1095280: i18n - Move existing templates closer together in Makefile - <http://git.evergreen-ils.org/?p=​Evergreen.git;a=commit;h=a66ccca>
16:27 pinesol_green [evergreen|Ben Shum] LP#1095280: i18n - Add new templates for translation to Makefile - <http://git.evergreen-ils.org/?p=​Evergreen.git;a=commit;h=df174c2>
16:28 pinesol_green [evergreen|Ben Shum] LP#1095280: i18n - Add templates to update_pofiles - <http://git.evergreen-ils.org/?p=​Evergreen.git;a=commit;h=b54e576>
17:05 gmcharlt Dyrcona: I've pushed my first pass at release notes to rel_2_10
17:05 gmcharlt I'll be offline for a bit, but will cut 2.10.6 later this evening
17:05 Dyrcona gmcharlt: Thanks, I'll have a look in a minute.
17:09 jvwoolf left #evergreen
17:10 jeff excellent. i have now stumped first line support at the sip client vendor! \o/
17:11 mmorgan left #evergreen
17:11 berick achievement unlocked!
17:17 Dyrcona heh
17:18 Dyrcona Reading these release notes, I wonder if one or two of these should have been targeted at 2.9.7 but weren't. Specifically the one about marc file extensions.
17:18 * Dyrcona goes searching for the bug.
17:19 Dyrcona Ok looks like that was 2.10 only.
17:19 Dyrcona I should have remembered Janet saying that it didn't happen in production. :)
17:21 jeff okay, i think i now know why this client sometimes sends renew[29] for item-not-present renewals and other times sends checkout[11] for those same item-not-present renewals.
17:21 jeff and the answer seems to be "depends on the value of acs renewal policy in the acs status[98] message"
17:22 jeff which is something i had noticed and checked but didn't seem to have any correlation.
17:22 jeff this has raised two other issues which do not require me to stump the client vendor:
17:23 jeff 1) why is my SIPServer instance sometimes dropping its syslog ident, and 2) why is this SIP server returning N for acs renewal policy when it seems to be set to yet, and doesn't seem to have changed.
17:23 Dyrcona gmcharlt++
17:28 jeff oh wow. it's...
17:30 * jeff tests
17:34 jeff yup. my SIP server flips from a Y to an N for the acs renewal policy after the initial worker is reaped.
17:35 jeff and once that flips from Y to N, the on-screen renewal interface on this client changes from sending renew[29] to sending checkout[11]
17:39 Dyrcona jeff: The first part sounds like a bug. The second part sounds normal for an approximately reasonable definition of "normal."
17:40 * Dyrcona is about to find out if he installed everything on his laptop needed to make a tarball.
17:40 miker jeff: being no SIP2 expert, I would expect EG to treat a checkout to the same patron as a renew automatically in SIP context (via some API flag or name). but it sounds like my expectation is false...
17:43 * Dyrcona would not be surprised either way. :)
17:44 Dyrcona And apparently, yes, I did install the packager prereqs already.
17:44 jeff miker: a SIP2 checkout[11] message sent to evergreen will renew the item, as long as various conditions are met.
17:47 Callender_ joined #evergreen
17:47 jeff the SC needs to have sent renew_ok = Y, the Evergreen SIP implementation needs to think that the patron who has an open circ on the item is the same as the patron in the SIP checkout request, the institution config needs to have renewals set to true, etc.
17:48 jeff i don't much care if the sip client uses renew or checkout to do a renewal, it was just that in testing some fixes to the same-patron detection and "needed for hold" messages i was hitting one code path and other times not.
17:49 jeff thus, the shovel and large pile of dirt.
17:50 miker :)
17:50 miker but, a bug is found. so that's something.
17:50 jeff yes!
17:51 * miker disappears
17:55 jeff also lost are timeout period and retries allowed.
17:56 jeff all defined in acsconfig/institutions/institution/policy
18:00 pinesol_green [evergreen|Dan Wells] Translation updates - po files, part 2 - <http://git.evergreen-ils.org/?p=​Evergreen.git;a=commit;h=ebd804d>
18:00 pinesol_green [evergreen|Dan Wells] Translation updates - newpot - <http://git.evergreen-ils.org/?p=​Evergreen.git;a=commit;h=ec802af>
18:07 _adb left #evergreen
18:39 Dyrcona Well, 2.9.7 works.
18:43 * Dyrcona copies the files to the server.
18:46 bmills joined #evergreen
18:53 Dyrcona Are we going to coordinate the editing of the downloads page or should I just go ahead and change the 2.9.6 entries to 2.9.7?
19:47 * gmcharlt is back
19:48 gmcharlt Dyrcona: once I finish cutting 2.10.6, I can take care of updating the downloads page and the release announcements
19:49 Dyrcona OK. I've got the release files in my directory on the server but haven't put them in place, yet.
19:50 gmcharlt Dyrcona: OK. Send me exact coordinates and I'll drop it in place when I move files about
19:51 Dyrcona They're in ~dyrcona on lupin. All in the home directory.
19:51 Dyrcona You should be able to move them with sudo.
19:51 gmcharlt gotcha
20:37 bmills joined #evergreen
20:52 pinesol_green Showing latest 5 of 7 commits to Evergreen...
20:52 pinesol_green [evergreen|Kathy Lussier] Docs: Adding 2.9.6 Release Notes - <http://git.evergreen-ils.org/?p=​Evergreen.git;a=commit;h=7f609d0>
20:52 pinesol_green [evergreen|Jason Stephenson] Docs: Adding 2.9.7 Release Notes - <http://git.evergreen-ils.org/?p=​Evergreen.git;a=commit;h=0f717f5>
20:52 pinesol_green [evergreen|Jason Stephenson] Docs: Add Additional 2.9.7 Acknowledgments for Testing/Signoff - <http://git.evergreen-ils.org/?p=​Evergreen.git;a=commit;h=66dfd05>
20:52 pinesol_green [evergreen|Galen Charlton] forward-port 2.9.6-2.9.7 schema upgrade script - <http://git.evergreen-ils.org/?p=​Evergreen.git;a=commit;h=dc0d286>
20:52 pinesol_green [evergreen|Galen Charlton] forward-port 2.10.5-2.10.6 schema update script - <http://git.evergreen-ils.org/?p=​Evergreen.git;a=commit;h=936fbc2>
20:57 Dyrcona gmcharlt++
20:59 gmcharlt https://evergreen-ils.org/everg​reen-2-9-7-and-2-10-6-released/
21:14 bmills joined #evergreen
21:28 * Dyrcona signs off for the night.
21:43 jihpringle joined #evergreen
21:54 dbwells joined #evergreen
22:31 remingtron joined #evergreen
22:34 remingtron joined #evergreen
22:53 dbwells 2.11.beta is available for *preview*, but the upgrade script isn't quite ready for prime time yet.   Fresh install and small-data-set early testers welcome :)  http://evergreen-ils.org/d​ownloads/previews/?C=M;O=D
22:54 * dbwells goes offline for the night
22:56 jeff joined #evergreen
22:57 _adb joined #evergreen

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