| 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/evergreen/+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/documentation/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=a506947198f1b219482bc82bc96d72e461c4a95f;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/evergreen-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/downloads/previews/?C=M;O=D |
| 22:54 |
* dbwells |
goes offline for the night |
| 22:56 |
|
jeff joined #evergreen |
| 22:57 |
|
_adb joined #evergreen |
