| 08:01 |
|
collum joined #evergreen |
| 08:07 |
|
tspindler joined #evergreen |
| 08:30 |
|
remingtron joined #evergreen |
| 08:31 |
csharp |
hmm, I'm trying to generate the log warnings for bug 1624491, but I'm not able to and I'm not seeing the prox_cache uninitialization warnings on PINES production or test servers :-/ |
| 08:32 |
pinesol_green |
csharp: Error: Could not gather data from Launchpad for bug #1624491 (https://launchpad.net/bugs/1624491). The error has been logged |
| 08:32 |
csharp |
pinesol_green: why not? |
| 08:32 |
pinesol_green |
Factoid 'why not?' not found |
| 09:57 |
jeff |
we're running with... 0? that's surprising to me. |
| 09:58 |
dbs |
The only two modules that I can think of that we run that most sites probably don't run are open-ils.resolver and open-ils.auth_proxy |
| 10:00 |
dbs |
Not sure if there's an easy way to figure out where a memory leak is occurring in apache with a bunch of c and perl mods |
| 10:00 |
jeff |
in test systems earlier this year, i could trigger high memory utilization in apache children. setting MaxConnectionsPerChild seemed to be a solid workaround, and i did have to set it pretty low. |
| 10:01 |
dbs |
jeff: interesting - but you don't need that workaround any more? |
| 10:01 |
jeff |
i'd have to look at notes, but first thing i'd try would be comparing things handled by EGCatLoader with something like static files. |
| 10:02 |
|
jlundgren joined #evergreen |
| 10:36 |
jeff |
if nothing else, in the interest of improving logging / error handling / avoiding this myself. ;-) |
| 10:36 |
Dyrcona |
If I use a barcode from a copy other than the ones I added, I get a response in less than 1 second. I think I'm missing something in the database. |
| 10:37 |
jeff |
yeah. |
| 10:37 |
Dyrcona |
jeff: I can paste it. I was thinking of adding these to concerto for testing purposes in the future. |
| 10:37 |
Dyrcona |
I'll bet there is some setting not switched on in concerto that I'm used to having on and that's my issue. |
| 10:38 |
dbs |
Dyrcona: any chance the bib / volume / copy ingest triggers are failing or aren't running? |
| 10:38 |
jeff |
ideally data that postgres allows you to insert wouldn't cause SIP to fail like that, but maybe the marcxml or something is to blame. |
| 10:42 |
Dyrcona |
Yes. |
| 10:42 |
Dyrcona |
Since I discovered that SIPServer won't start on Ubuntu 16.04, I'm going to move on to a branch for that and then come back to this after that. |
| 10:42 |
jeff |
isn't this expected to fail on recent Encode.pm? |
| 10:43 |
Dyrcona |
jeff: Yes. That was what I was testing, but this is not a recent Encode AFAIK. |
| 10:43 |
jeff |
ah. |
| 10:43 |
Dyrcona |
It failed on 16.04, and I'm testing 14.04 for duplication, etc. |
| 10:44 |
jeff |
my guess right now is that you're running into the bug where sipserver doesn't properly flush the buffer on the socket. |
| 07:38 |
pinesol_green |
csharp: [evergreen|Dan Scott] Support Apache 2.4 configuration directives - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=d4f6bf8> |
| 07:39 |
csharp |
375054cf |
| 07:39 |
pinesol_green |
csharp: [evergreen|Bill Erickson] Collections user balance API / batch file output - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=375054c> |
| 08:05 |
csharp |
okay, so I just now learned about the collections batch file feature that's been around for years, and I'm looking to enable it. If I browse to /collections/, I'm prompted to log in and I get a 404, but if I create a test file and browse to it it works. Is that the expected behavior, that the file works but the directory doesn't? |
| 08:15 |
|
kmlussier joined #evergreen |
| 08:18 |
* kmlussier |
yawns |
| 08:18 |
kmlussier |
@coffee [someone] |
| 10:09 |
Dyrcona |
rhamby is safe, then. :) |
| 10:09 |
* Dyrcona |
is readying his xenial VM for bug squashing day tomorrow. |
| 10:10 |
rhamby |
:) |
| 10:10 |
* Dyrcona |
believe he will test his new and improved SIP branch. |
| 10:11 |
Dyrcona |
jeff: Do you mind if I start working on a branch to remove clean_text from the Evergreen sip code? |
| 10:12 |
jeff |
if you have lots of free time go for it. i'll take it off my list for today. |
| 10:12 |
jeff |
and i'll be happy to test. |
| 10:13 |
jeff |
or counter, if i'm feeling particularly opinionated. |
| 10:13 |
Dyrcona |
I'll see if I can get to it today.. :) |
| 10:14 |
Dyrcona |
First, I want to make sure that the SIPServer changes don't hose a more-or-less stock master installation. |
| 10:14 |
Dyrcona |
But, so I can test removing clean_text, I'll at least start a branch today. |
| 10:23 |
|
TARA joined #evergreen |
| 11:52 |
|
bmills joined #evergreen |
| 12:11 |
|
bos20k joined #evergreen |
| 12:41 |
* Dyrcona |
checks |
| 12:43 |
Dyrcona |
Nope. |
| 12:44 |
Dyrcona |
Once I set that up, maybe I'll make a Lp bug to have it added to the seed data for concerto. |
| 12:46 |
dbs |
Dyrcona: it doesn't look like there are any users with non-ASCII characters in their names or other data, either. |
| 12:46 |
dbs |
which would be really helpful for testing |
| 12:47 |
Dyrcona |
dbs: Yeah, I was going to look into that, too. I can get some records to load if need be. |
| 12:47 |
Dyrcona |
I think I still have a small file of vietnamese records hanging around somewhere. |
| 12:48 |
dbs |
yep, /[^\d0-\d127] says no match |
| 14:41 |
* JBoyer |
is also distracted by other projects, so isn't really checking the EI db.. |
| 15:03 |
mmorgan |
DPearl: kmlussier: Looks like this can happen when transferring volumes as described in lp 1411422 |
| 15:03 |
pinesol_green |
Launchpad bug 1411422 in Evergreen 2.10 "Copy details repeated in search results when item/volume moved with parts attached" [Medium,Confirmed] https://launchpad.net/bugs/1411422 |
| 15:04 |
kmlussier |
mmorgan: I tried transferring volumes on a test system, but I didn't see the problem occur. |
| 15:05 |
* mmorgan |
didn't try and reproduce, but remembered it being a problem in the past. |
| 15:12 |
kmlussier |
Speaking of that bug, Bmagic_ did you see my comments on bug 1411422 regarding old parts being left behind and the possibility of a regression test? |
| 15:12 |
pinesol_green |
Launchpad bug 1411422 in Evergreen 2.10 "Copy details repeated in search results when item/volume moved with parts attached" [Medium,Confirmed] https://launchpad.net/bugs/1411422 |
| 15:12 |
* kmlussier |
would love to see that bug fix merged. |
| 15:38 |
Dyrcona |
So, I just inserted some copies with SQL and a SIP2 request for item info times out. |
| 15:44 |
|
Bmagic joined #evergreen |
| 15:44 |
Dyrcona |
So, if we had upgraded to Jessie, instead of crashing the vendor's software, these records would crash ours. :( |
| 15:45 |
dbs |
We're on Ubuntu 14.04, fwiw |
| 15:46 |
Dyrcona |
We're on Squeeze in production and I'm testing on Ubuntu 16.04. |
| 15:46 |
Dyrcona |
Ubuntu 14.04 does not exhibit this problem. |
| 15:47 |
Dyrcona |
Well, Perl < 5.20 doesn't exhibit this problem. |
| 15:49 |
jeff |
by nature of including the affected version of Encode.pm |
| 16:02 |
StomproJosh |
jeff, I'm going to start a bug on stacking/multiple AT validators. I've wondered a few times about not being able to have several validators. It would be nice to always include a UsrHasEmail validator for an email notice, along with any others. |
| 16:02 |
dbs |
my hypothesis for the reason that i needed to remove clean_text() for item info was that supercat started encoding the incoming data properly |
| 16:03 |
Dyrcona |
dbs: Could be. Looks like Supercat and SIP are the only modules that call decode_utf8 |
| 16:04 |
Dyrcona |
Wel, I'll remove clean_text() (should be easy) test SIP, and then see what happens with Supercat look ups of these two records I have that break SIP. |
| 16:04 |
dbs |
so if you try to decode it twice now, boom, whereas before decode_utf8() was safe to call multiple times on the same data |
| 16:05 |
jeff |
supercat and/or unapi exhibit other non-crashy encoding issues. |
| 16:05 |
Dyrcona |
Well, I find it breaks on utf-8 data, period. |
| 12:22 |
* kmlussier |
will also recheck the page one last time to make sure I didn't miss any other glaring errors. |
| 12:23 |
csharp |
berick: cstore does see the call |
| 12:23 |
csharp |
which is 405466 bytes |
| 12:23 |
berick |
csharp: ok.. so maybe tsbere is on to something. it's easy to test that one.. sec |
| 12:23 |
csharp |
ok |
| 12:25 |
berick |
csharp: mind seeing what happens if you add this line (and restart trigger) -- maybe on a dev server if possible |
| 12:25 |
berick |
https://gist.github.com/berick/f4e1ac051ac8860faaf72816d867b460 |
| 12:27 |
berick |
yeah, exactly |
| 12:29 |
|
mmorgan1 joined #evergreen |
| 12:36 |
* berick |
steps away for a bit |
| 13:02 |
csharp |
ugh - now I'm in a rabbit hole of trying to get logging working properly on my acq testing server :-/ |
| 13:11 |
|
sandbergja joined #evergreen |
| 13:17 |
* tsbere |
dislikes finding 42 bib records with a bad type character |
| 13:18 |
tsbere |
If anyone wants the query I used to *find* said bib records I am willing to share |
| 13:20 |
|
rlefaive joined #evergreen |
| 13:29 |
dbwells |
kmlussier: Took me a second, but I see the heading you are talking about now. Sure, I can regenerate/repost them when ready. |
| 13:31 |
kmlussier |
dbwells: Thanks! I've also caught a few typos that I missed on previous proofreading. Making the changes now. |
| 13:36 |
csharp |
berick: same behavior after that change |
| 13:38 |
csharp |
I was hopeful when a PO on our test server with 212 items printed, but the 313-long one that triggered the helpdesk ticket is still timing out |
| 13:39 |
berick |
csharp: ok, mind trying one more thing? |
| 13:39 |
csharp |
sure |
| 13:39 |
kmlussier |
Do we have a 2.11 release branch yet? |
| 15:15 |
dbs |
csharp berick: thank you for doing this work, it seems very very similar to what we're seeing (albeit more with checkins than triggers) |
| 15:16 |
dbs |
because it seems superweird for a simple checkin to time out in the database |
| 15:17 |
* dbs |
was wondering if networking issues (like ipv6 routing madness from years past?) might also be playing a role |
| 15:17 |
kmlussier |
Bmagic: I'm unable to test the web client to see if I can replicate it, but there was a recent small fix to the patron search form that might be a starting point for your investigation. |
| 15:17 |
kmlussier |
ee711968 |
| 15:17 |
pinesol_green |
kmlussier: [evergreen|Galen Charlton] LP#1436987: webstaff - fix patron search form - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=ee71196> |
| 15:17 |
Bmagic |
thanks! |
| 15:21 |
Dyrcona |
csharp: That would indicate that the call to create the trigger in the database failed. |
| 15:21 |
Dyrcona |
Or timed out along the way, which you already know. :( |
| 15:22 |
Dyrcona |
Well, the event output, rather. |
| 15:22 |
berick |
dbs: well, this one is a problem with the size of the data, a blob of text way larger than any normal processing (unless you're bib records are .3 Megabytes in size) |
| 15:22 |
pinesol_green |
[evergreen|Dan Scott] Add a simple Item Information test for SIP server - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=9dd9dca> |
| 15:29 |
csharp |
Dyrcona: stock as of 2.9.2 |
| 15:29 |
berick |
csharp: still on ubuntu 14.04? |
| 15:29 |
csharp |
berick: yep |
| 15:35 |
* Dyrcona |
hands out BLOBs. |
| 15:36 |
Bmagic |
kmlussier: phew - it turned out to be some sort of browser caching issue - opened incognito and violla |
| 15:36 |
kmlussier |
Bmagic: Glad to hear it! |
| 15:38 |
csharp |
I'm going to have to stop working on this until I get my test server updated - I'm monkeying around too much on the prod servers :-/ |
| 15:40 |
Dyrcona |
@bartender |
| 15:40 |
* pinesol_green |
fills a pint glass with Cantillon Saint Lamvinus, and sends it sliding down the bar to Dyrcona (http://beeradvocate.com/beer/profile/388/8954) |
| 15:43 |
|
maryj joined #evergreen |
| 10:46 |
dbs |
current status: what the hell happened to take our nice "running with 5GB of free RAM for a full day" into an OOM situation just a few hours later in the middle of the night |
| 10:53 |
Dyrcona |
A bot? A book on an enter key? A ridiculous search query? |
| 11:04 |
Dyrcona |
JBoyer: This looks like the list of services required for SIP on a 2.9 installation: http://pastebin.com/MmVxGC9j |
| 11:04 |
Dyrcona |
NOTE: I have not tested that on a VM or anything, so something might be missing. |
| 11:05 |
Dyrcona |
That just looks like the things that could actually get used by the calls that the SIP driver makes. |
| 11:06 |
JBoyer |
Dyrcona, I'm running on tuit fumes currently, but I've got a couple places I could test that out eventually. I'll admit trigger is a surprise, but I realize there are the occasional interdependencies that aren't always clear. |
| 11:07 |
Dyrcona |
JBoyer: Well, circ could end up making a call to trigger. It probably won't but it wasn't totally clear. |
| 11:08 |
JBoyer |
Ah, that makes sense for some of the active events. |
| 11:09 |
Dyrcona |
I also could have spent more time on it. :) |
| 11:51 |
dbs |
the Apache drones and their 150M of memory per process :/ |
| 11:52 |
Dyrcona |
miker: I can always take a look when I get the chance, which has not been very often lately. |
| 11:53 |
* dbs |
was tempted to start working with nginx or a similar caching proxy again to try and offload some of that weight, but also doesn't want to add another layer of complexity |
| 11:53 |
Dyrcona |
I've also had a hard time reproducing this myself on a test environment. |
| 11:53 |
dbs |
miker: ah that's what I was thinking of, didn't realize it hadn't been merged yet |
| 11:54 |
miker |
in particular, a pile-up occurs when we get a spew of requests that take a long time to process. the apache backends wait for the opensrf request to finish, even if the client side has gone away. the branch attempts avoid that wait, by checking at 1s intervals for client connectedness when it's inside modperl |
| 11:54 |
miker |
dbs: well, we have had same-search guards for a long time ... 2.5, maybe? ... but that only saves the middle layer and the db |
| 16:58 |
Dyrcona |
A new feature might be to add a command in the staff client to recalculate penalties. |
| 16:58 |
phasefx |
the Refresh button triggers the api call for refreshing penalties |
| 16:59 |
phasefx |
checking something in or out should also do it |
| 17:01 |
mmorgan |
Hmm. On production system, 2.9, penalties are recalculating when I refresh. |
| 17:01 |
mmorgan |
On 2.10.5 test system, penalties don't recalculate when I refresh. |
| 17:01 |
phasefx |
mmorgan: are the org depths the same on the penalty definitions? |
| 17:02 |
phasefx |
between systems |
| 17:02 |
Dyrcona |
And all this time I thought that Refresh only retrieved the patron information again. |
| 17:02 |
phasefx |
wasn't really joking when I suggested org units :) |
| 17:04 |
mmorgan |
So on production system, PATRON_EXCEEDS_FINES has null org_depth |
| 17:04 |
mmorgan |
test system has 0 |
| 17:04 |
phasefx |
what I don't have a good handle on is the behavior with org depths, I just remember they can cause problems |
| 17:04 |
mmorgan |
but it's a consortium wide penalty |
| 17:05 |
* mmorgan |
guesses this won't get solved today will revisit on Monday;-) |
| 17:05 |
phasefx |
mmorgan: I bet if you make it null on the test system it'll work |
| 17:05 |
mmorgan |
Will try that next, but have to run. Have a good weekend, all! |
| 17:05 |
|
mmorgan left #evergreen |
| 17:20 |
|
Stompro joined #evergreen |
| 11:22 |
|
maryj joined #evergreen |
| 11:26 |
Stompro |
Thanks all for the damaged item nfo. Now that I think about it more it is probably a bad idea to combine them, they are two seperate situations that get treated differently in our state law. If we notify about damaged items we will send a seperate notice. |
| 11:35 |
* Dyrcona |
wonders at the usefulness of an interface to undelete patrons. I guess it would only work here because the client doesn't do the obliteration dance on delete for ... reasons. |
| 11:42 |
* kmlussier |
updates the MassLNC community demo server to 2.10.6 early because she had to test something on 2.10 anyway. |
| 11:42 |
kmlussier |
For now, then, we're going to have 2 community demo servers on the same major release. |
| 11:46 |
|
bmills joined #evergreen |
| 12:00 |
Dyrcona |
"hello, headache, my old friend...I feel you've come to me again." |
| 12:00 |
Dyrcona |
"it's just the pain of sinus..." |
| 14:10 |
pinesol_green |
csharp: [evergreen|Bill Erickson] LP#1464709 Rename checkout_ok to is_available - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=2c40b84> |
| 14:15 |
Bmagic |
miker: sorry for the delay - The SIP server is working as expected on 2.11rc |
| 14:16 |
Bmagic |
my copy of production database was 2.9.1 and that did not work |
| 14:16 |
miker |
Bmagic: sweet, thanks for testing! |
| 14:16 |
miker |
oh? how did it break? |
| 14:16 |
Bmagic |
I had to raise the db to 2.11rc (to match the Evergreen code) - auth errors otherwise - db functions missing |
| 14:17 |
Bmagic |
I didn't try the SIPServer against 2.9.1 evergreen |
| 14:17 |
miker |
oh, the db was 2.9.1 but the evergreen code was 2.11 |
| 14:17 |
Bmagic |
right |
| 14:17 |
Bmagic |
I suppose the SIPServer will work against older Evergreen installs? |
| 14:18 |
miker |
it should |
| 14:18 |
Bmagic |
I think I can test that as well if needs be |
| 14:18 |
miker |
old drivers should ignore the new parameter |
| 14:18 |
miker |
JBoyer: did you test the new sip stuff (passing a workstation) against old evergreen that doesn't expect to receive that? |
| 14:21 |
rjackson_isl |
miker: the boss is off to one of his many meetings currently so he will get back to you! |
| 14:21 |
miker |
rjackson_isl: heh, thanks :) |
| 14:27 |
|
yboston_ joined #evergreen |
| 14:28 |
miker |
right, that's my reading too |
| 14:29 |
* tsbere |
glares at the glare on his screen as well as the ineffective blinds that are full of intentional holes |
| 14:29 |
|
maryj joined #evergreen |
| 14:31 |
csharp |
kmlussier: I just pushed a probable fix to bug 1624025 to http://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/csharp/lp1624025_copy_status_missing_field - are you able to easily test it? I'm not in a place at the moment where I can test it on my own server |
| 14:31 |
pinesol_green |
Launchpad bug 1624025 in Evergreen "Hold targeting weirdness in 2.11" [High,New] https://launchpad.net/bugs/1624025 |
| 14:33 |
kmlussier |
csharp: Yes, berick shared the same fix earlier (up above around the time I was complaining about comcast). It does indeed work. |
| 14:33 |
csharp |
oh great :-) |
| 10:10 |
dbs |
JBoyer: We've run for 7 years on a single app server, the simplicity has been nice |
| 10:11 |
* Dyrcona |
has fun with Internets. Could drop again without notice. |
| 10:14 |
JBoyer |
dbs, there is something to be said for simplicity. |
| 10:16 |
kmlussier |
I keep coming across bug 1013786 whenever I'm getting ready for Bug Squashing Day. I think we need to decide whether we want to push the code that's there, which already has two signoffs, or if we want to wait until the password strength test is moved to a self-contained routine, in which case we should remove the pullrequest tag. |
| 10:17 |
pinesol_green |
Launchpad bug 1013786 in Evergreen "tpac: Check for password strength at login" [Medium,Confirmed] https://launchpad.net/bugs/1013786 |
| 10:17 |
kmlussier |
Any thoughts? |
| 10:17 |
* kmlussier |
guesses that nobody is actively working on it at the moment. |
| 15:28 |
Dyrcona |
Hmm... It isn't always quick to branchify configs that are generated from .in files if you're not starting from git but from the modified output of the .in files. |
| 15:34 |
|
mmorgan1 joined #evergreen |
| 15:37 |
Dyrcona |
Because of things like this: 3 out of 10 hunks FAILED -- saving rejects to file eg_vhost.conf.in.rej |
| 15:45 |
Bmagic |
miker: I am still testing this branch ( just resuming now ) |
| 16:04 |
Dyrcona |
One thing I've discovered in this process is that it helps to check out the rel_* branch for the release that your production server is on and do the comparisons/updates in that branch. |
| 16:06 |
Dyrcona |
Then cherry-pick the resulting commits to a copy of master and/or any later rel_* branches. |
| 16:10 |
|
berick_ joined #evergreen |
| 16:41 |
miker |
the difference that my second commit makes is that it allows you to say "ignore the client's CP field, use this value from the config file" |
| 16:42 |
miker |
well, it will if you do /not/ set client_location_code="true" for your institution(s) |
| 16:42 |
miker |
which gives you the ability to migrate clients over time |
| 16:43 |
Bmagic |
that should work, I will have to setup a test |
| 16:43 |
miker |
by moving their account entries from one institution to another, with differing settings |
| 16:44 |
miker |
please do! I'd like this to get into sipserver before 2.11 goes GA if possible, so sipserver master can be configured (at least) to not break any existing releases |
| 16:45 |
jeff |
i may propose an alternate branch if i can get my thoughts together. |
| 17:03 |
Dyrcona |
Yes. I would tend to agree with server wins. |
| 17:04 |
miker |
anyway, I pushed one more commit that changes the institution policy setting "client_location_code" so that, unless that is set to "true", you get the old behavior (plus the ability to set the value in the config file) |
| 17:04 |
Bmagic |
if a username/password is presented on the xml and from the client, who wins? |
| 17:04 |
miker |
Bmagic: so, if you feel like testing, please try the tip of http://git.evergreen-ils.org/?p=working/SIPServer.git;a=shortlog;h=refs/heads/user/miker/lp1579144_login_location |
| 17:07 |
miker |
Bmagic: for an <account> you mean? the xml is considered authoritative. if they don't match (or the login fails at the ILS) then login fails... so, I guess the ILS is most authoritative, but between XML and client, XML wins. is that what you mean? |
| 17:07 |
Bmagic |
yeah, another joke |
| 17:07 |
Bmagic |
the xml has the username/password/workstation supplied and the sip client has the same. who wins on each one..... |
| 17:09 |
* Dyrcona |
calls it a day. |
| 17:28 |
miker |
git blame --annui ?? |
| 17:29 |
* miker |
really runs away |
| 17:30 |
Bmagic |
lol |
| 17:53 |
Bmagic |
miker: I just tested the SIP server code - something is amiss (probably me) |
| 17:53 |
Bmagic |
LOGIN ERROR: 'Undefined subroutine &Sip::MsgType::to_bool called at Sip/MsgType.pm line 859. |
| 18:37 |
|
_adb left #evergreen |
| 19:17 |
miker |
Bmagic: no, it's me. I'll look at that as soon as I can and let you know. probably in the morning |
| 09:20 |
jeff |
can your apache hosts connect to memcached successfully? |
| 09:20 |
dbs |
jeff: yeah, I realize that -- so many moving parts to tweak |
| 09:21 |
jeff |
any cache-related errors in the logs? |
| 09:21 |
dbs |
tested the apache memcache translator setting of 127.0.0.1:11211 via telnet and that works, no errors reported in the logs |
| 09:21 |
jeff |
there are things that are fetched from config, from the db, and from memcached... also the template toolkit cache... |
| 09:21 |
dbs |
yep |
| 09:22 |
* dbs |
will get back onto debug_timing, whoever thought of adding that was a GENIUS |
| 09:39 |
dbs |
It seems that the apache processes need to be initialized, subsequent requests don't show those kinds of slowdowns (157ms and 83.5ms for initial connection & ssl), so that's an outlier |
| 09:40 |
Dyrcona |
dbs: yes, I've seen that Apache is really slow just after start up. Load also tends to stay high for a couple of minutes, then settles down. |
| 09:40 |
dbs |
hah, there aren't many events in the stock /eg/opac/advanced page it seems, just New page and initial load (At 0.1836: Initial load) |
| 09:40 |
csharp |
same here - just saw that on my test box |
| 09:40 |
dbs |
btw, Dyrcona, thank you for http://blog.mvlcstaff.org/2013/05/what-has-been-going-on.html |
| 09:43 |
jeff |
worst case i can get is 2.30s Load time (per chrome devtools) on a fresh apache start, even with cstore intentionally hobbled to 1 worker. |
| 09:43 |
jeff |
on a fresh apache start. |
| 10:22 |
dbs |
we do have about 20 virtualhosts configured for both 443 and 80, so undoubtedly lots of parsing overhead |
| 10:23 |
JBoyer |
Could be, this machine hosts nothing else and it's generally hit by outside users. |
| 10:24 |
JBoyer |
NOT generally hit by users, that is. |
| 10:24 |
Dyrcona |
So, you're testing against one of 20 virtual hosts on the same hardware? Could be the hardware is slightly overtaxed. |
| 10:26 |
dbs |
Dyrcona: yep |
| 10:26 |
dbs |
although load seems fine |
| 10:26 |
dbs |
at 0.75 for the last fifteen minutes, on an "8 core" VM |
| 10:30 |
JBoyer |
dbs, referring to your speed comment above, I'm seeing ~200Kb/s for our homepage on the same gigabit network. TCP startup speeds I'm guessing? With pages that "small" the speed may never be able to top out. ( I also see 2000Kb/s when testing localhost on it's public IP) |
| 10:30 |
dbs |
total of 14 cstore timeout errors reported over the past 24 hours (determined by grep "perl:error" /var/log/syslog | grep cstore) |
| 10:33 |
jeff |
also laptop-on-wifi here. local system gets me 111.196 ms mean over 100 requests (11.120 seconds total); webby gets 740.887 ms mean over 100 requests (74.089 seconds total) |
| 10:34 |
jeff |
that seems to be more than just rtt hurting me there. second guess is ssl tuning, but in both cases ab selected TLSv1.2,ECDHE-RSA-AES256-SHA384,2048,256 |
| 16:16 |
Dyrcona |
I want to start clark kent on the training server and it has a copy of production. |
| 16:17 |
Dyrcona |
I set recur to false on all of the reports. |
| 16:17 |
Dyrcona |
Is that all I need to do to prevent any surprise reports firing off? |
| 16:17 |
Dyrcona |
We want to test some reports manually. |
| 16:19 |
jeff |
also check for any reports scheduled to run which have not run. |
| 16:19 |
* jeff |
refreshes memory on what columns he means |
| 16:20 |
Dyrcona |
jeff: I was just going to aks. |
| 10:36 |
jeff |
i'm not quite sure how i managed to get this many for a single file without noticing. |
| 10:37 |
Dyrcona |
My laptop doesn't crash much, but it's like playing Russian roulette after resume from suspend/sleep if it is going to act normal or exhibit one of two or three bugs. |
| 10:38 |
* Dyrcona |
goes back to figuring out why some students didn't load yesterday... |
| 10:40 |
Stompro |
Dyrcona, I just got done purging based on our migration date, lots of test load data, and batch global edits in there. |
| 10:41 |
berick |
Stompro: we break our auditor data into 3 time categories and keep at most a certain number of entries from each grouping. (We're only cleaning the copy auditor right now, more to follow). the code i'm about to deploy: http://git.evergreen-ils.org/?p=working/Evergreen.git;a=commitdiff;h=f45857003181c8b0083c4d66e07d003d4478f29a |
| 10:41 |
Stompro |
berick++ , thank you. |
| 10:43 |
* berick |
notes some of the comments in there mention specific values for variables which are, in fact, variable |
| 15:44 |
Stompro |
But for things like the various receipts and reports, that shouldn't be a problem. |
| 15:45 |
* Dyrcona |
gets a lot of deprecations warnings on npm install. |
| 15:48 |
Dyrcona |
bshum berick: grunt all just worked. Did you two do anything to fix that issue or has npm fixed it? |
| 15:49 |
jeff |
are you talking about the test failure fixed in commit 6bc0bc2? |
| 15:49 |
pinesol_green |
jeff: [evergreen|Jeff Godin] LP#1618136 Fix webstaff IDL2js.js test failures - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=6bc0bc2> |
| 15:49 |
jeff |
(that was unrelated to npm, so i'm not sure if that's what you mean) |
| 15:50 |
Dyrcona |
jeff: I think that is it. My memory ain't what it used to be. |
| 15:50 |
Dyrcona |
jeff++ bshum++ dbwells++ |
| 16:08 |
* Dyrcona |
answers his own question: Yes. |
| 16:08 |
Bmagic |
wifi-- |
| 16:09 |
kmlussier |
Why is it not 5 p.m. yet? |
| 16:11 |
miker |
Dyrcona: the point testing of that branch is not to change the server tz -- that should be whatever it should be -- but to change the /client/ tz and confirm that times are 1) recorded in the client tz 2) show up in the client tz. that is, a client in central time should see times in central, even if they were written in eastern and the server is in eastern. and that those times should be the /real point in time/ not the same string. does that make |
| 16:11 |
miker |
sense? |
| 16:12 |
Dyrcona |
miker: Yes. I could just change my server to UTC and get a similar effect, no? |
| 16:12 |
miker |
eg, if someone checks out an item at 1pm EST, a client in CST will see the circ happened at noon CST |
| 16:12 |
miker |
um, no |
| 16:15 |
kmlussier |
berick: Brazil! Hopefully, they have no Schlitz there. |
| 16:15 |
miker |
perhpas |
| 16:15 |
Dyrcona |
Well, if I do some transactions in EDT and change my timezone to CST to view them later, that should work. |
| 16:16 |
miker |
I guess my point is, the real world test of the branch is about "do times displayed in the client and opac use the client TZ?" |
| 16:16 |
miker |
Dyrcona: right |
| 16:16 |
jeff |
miker: agreed! |
| 16:16 |
miker |
jeff: but, in the real world, one wouldn't be changing the server's system TZ |
| 16:17 |
jeff |
miker: it doesn't matter which one has changed, just that they are different. |
| 16:17 |
miker |
so, while that might aproximate the effect, I wouldn't trust it, necessarily. too many things (like database settings) could (in a real world setup) get in the way |
| 16:18 |
miker |
anyway, testing++ |
| 16:18 |
miker |
Dyrcona++ |
| 16:18 |
miker |
jeff++ |
| 16:18 |
* miker |
steps away from all keyboards for a bit |
| 16:32 |
Dyrcona |
Heh. Doesn't work if you start services before configuring the database in opensrf.xml.... |
| 16:43 |
Dyrcona |
Hmm.. /eg/staf/ leads to a login, but /eg/opach/home leads to an internal server error. |
| 16:43 |
* tsbere |
would expect both of those to be 404s, honestly ;) |
| 16:48 |
tsbere |
Dyrcona: I have gotten errors like that when the IDL didn't initialize properly. Did apache come up too soon or something? |
| 16:49 |
Dyrcona |
Yeah, my next thought after cstore not running was the idl. I ran autogen, and started apache. I'll restart apache and see if that helps. |
| 16:50 |
Dyrcona |
tsbere++ # A restart helped. |
| 16:50 |
Dyrcona |
Well, now that it seems to be working. I'll shut it down and do the testing tomorrow. |
| 16:54 |
Dyrcona |
Well, have a nice weekend, everybody! |
| 17:23 |
|
jvwoolf left #evergreen |
| 17:32 |
Bmagic |
I'm trying to login to my new test server via SIP. I am getting an error about workstation not found. Anybody have something off the top of their head before I dive in? |
| 17:34 |
berick |
Bmagic: it's ringing a bell w/ a recent bug... |
| 17:34 |
berick |
Bmagic: bug #1259196 |
| 17:34 |
pinesol_green |
Launchpad bug 1259196 in Evergreen "SIP support workstation option at login" [Wishlist,Fix committed] https://launchpad.net/bugs/1259196 |
| 17:35 |
Bmagic |
oh good! |
| 17:35 |
Bmagic |
berick++ |
| 17:36 |
Bmagic |
I am running master on this test machine though |
| 17:37 |
|
gmcharlt joined #evergreen |
| 17:38 |
Bmagic |
my login message contains the CP for the insitution, now it's workstation? |
| 17:40 |
Bmagic |
oh boy, this is going to break some stuff in the wild for sure |
| 10:18 |
jeff |
berick++ miker++ |
| 10:41 |
kmlussier |
StomproJ: I was reading your question from last week regarding Reshelving status. We have a site that did not have the option to run the Reshelving script more frequently than every 24 hours (too large). They ultimately went with a label change to "Recently Returned" that seemed to make people happy. |
| 11:03 |
|
Dyrcona1 joined #evergreen |
| 11:13 |
jeff |
hrm. need to spin up a pre-2.10 instance to test something. |
| 11:18 |
* csharp |
dreams up library-themed horror movie: THE UNRETURNED |
| 11:19 |
berick |
csharp++ |
| 11:20 |
dbwells |
csharp++ # I needed that laugh :) |
| 13:27 |
jeff |
it is inconsistent with the current xul client's checkin option from a patron's Items Out |
| 13:27 |
|
Griff`Ron joined #evergreen |
| 13:27 |
jeff |
but it really only matters when you're dealing with an unusual situation, like a patron with an open circulation on a deleted copy. |
| 13:28 |
tsbere |
Which is important |
| 13:28 |
tsbere |
But not a normal test case |
| 13:28 |
jeff |
checking in a deleted copy by barcode will either fail (because the barcode is not found), or will checkin the wrong copy (because another item with that same barcode has since been created). |
| 13:28 |
mmorgan |
jeff: right. We've had confusion about that in the past. |
| 13:28 |
jeff |
in my case, the latter happened. |
| 15:26 |
* berick |
hopes more than 4 people are coming to the hackaway |
| 15:26 |
Dyrcona |
csharp: Are you done working on Lp 1360347 |
| 15:26 |
pinesol_green |
Launchpad bug 1360347 in Evergreen "Wishlist - New LSE setting for Acquisitions" [Wishlist,In progress] https://launchpad.net/bugs/1360347 - Assigned to Chris Sharp (chrissharp123) |
| 15:26 |
Dyrcona |
The status is in progress, but the code changes look good to me and we'd like to test it. |
| 15:30 |
jeffdavis |
I've got a pcrud drone that's been running for over 40 minutes, chewing up a lot of CPU. Is there any way to find out what it's up to while it's running? I get the impression that the request (whatever it is) won't be logged until it's complete. |
| 15:31 |
* JBoyer |
hopes there are at least 18 others coming, or there'll be bills to pay. :/ |
| 15:31 |
jeff |
jeffdavis: have you tried attaching to it with something like "strace -p PID_HERE" to see if it's just spinning? |
| 16:10 |
jonadab |
"What's the worst that could happen?" "You mean besides starting a global thermonuclear war?" |
| 16:10 |
* dbs |
upgrades the upgrade plugin |
| 16:11 |
dbs |
I'll be good and wait until I can backup the wiki directory first before I upgrade the wiki. |
| 16:15 |
csharp |
Dyrcona: I'm done until I can actually test it, yes. Our Acq person is out for a while, so I'm waiting for her to return before experimenting |
| 16:15 |
csharp |
Dyrcona: please test if you have the means to do so |
| 16:16 |
csharp |
dbwells: I kept seeing "banjo" in there too :-P |
| 16:17 |
* csharp |
prolly won't bother bringing the ol' ukulele this round |
| 16:19 |
Dyrcona |
csharp: Thanks. I'll see if I can do anything to test it in the meantime, too. |
| 16:19 |
csharp |
Dyrcona++ |
| 16:19 |
* Dyrcona |
tosses another iron in the fire. ;) |
| 16:26 |
StomproJ |
Ooops, just merged all the Readers digest large print into reader digest... to the auditor tables. Where is the undo button in psql. |
| 16:37 |
|
gsams_ joined #evergreen |
| 16:39 |
|
gsams_ joined #evergreen |
| 16:42 |
StomproJ |
Hmm, it doesn't look like asset.merge_record_assets deletes empty volumes, which works out well for me, but I wonder if that is intended. |
| 16:43 |
csharp |
StomproJ: I'll test it, but it will take a long time to apply on our test system, so it won't be quick :-) |
| 16:43 |
StomproJ |
csharp++ thanks. |
| 16:43 |
csharp |
we have a buncha muncha cruncha bibs |
| 16:54 |
|
bmills joined #evergreen |
| 14:09 |
jeff |
The situation where I was experiencing it was within our mobile app, so I'm not sure (without digging) if it was in that abstraction layer or an issue within the tpac itself. |
| 14:11 |
tsbere |
jeff: Part of the headache there is you get a failure reason set for *every copy*. Which set of reasons do you pass to the end user? |
| 14:11 |
tsbere |
I made it so that if age protection was the *only* reason on *any* copy then that information would be passed back up. But anything else is likely to get lost. |
| 14:12 |
gvi |
I'm at the point of testing the staff client. I've entered so many user names in the last few hours I don't know which one to use. |
| 14:13 |
tsbere |
gvi: You probably specified the username/password at the eg_db_config step. |
| 14:13 |
gvi |
OK thanks. |
| 14:14 |
gvi |
That was it. |
| 17:06 |
Dyrcona |
I can probably come up with a SQL to fix the circulations in the mean time. |
| 17:07 |
Dyrcona |
I'll take a stab at a fix in the coming days. |
| 17:07 |
|
mmorgan left #evergreen |
| 17:20 |
phasefx |
incidentally, it looks like live_t/purge-user-activity.pg is failing now |
| 17:21 |
phasefx |
and on the perl side, live_t/18-lp1592891_sip_standing_penalties.t |
| 17:21 |
phasefx |
actually, wrong test on that last one |
| 17:21 |
phasefx |
live_t/19-lp1306666-abort-transit-copy-status.t |
| 17:40 |
Dyrcona |
phasefx: If that last one is failing, I'm not sure why. I'd have to play with it some more. |
| 17:42 |
* Dyrcona |
sees about building a xenial vm from an ISO. It has been failing with vmbuilder since sudo was updated yesterday. |
| 17:45 |
* Dyrcona |
give vmbuilder one last shot. |
| 17:48 |
phasefx |
for that abort test, it's expecting Reshelving, and getting Canceled Transit. I haven't looked more closely than that. Maybe the behavior is correct and the test needs updating |
| 17:50 |
Dyrcona |
Ah, OK. I hadn't noticed that csharp's branch had gone in. |
| 17:50 |
Dyrcona |
I thought the tests were to be rewritten before that happened. |
| 17:51 |
Dyrcona |
I'll see if I can get around to fixing the tests by this weekend, but I can't promise much. |
| 17:56 |
Dyrcona |
And, yeah, vmbuilder is still choking on sudo. |
| 18:13 |
Dyrcona |
virt-manager is being a pain. I wish I could remember the options that I used for virt-install that last time. |
| 18:20 |
|
gmcharlt joined #evergreen |
| 11:36 |
* Dyrcona |
should have remembered. |
| 11:38 |
jeff |
it appears to be the SQL strings. |
| 11:40 |
* Dyrcona |
didn't get that far. ;) |
| 11:52 |
jeff |
Open-ILS/web/js/ui/default/staff/test/data/idl2js.pl outputs an IDL2js.js for testing which is not valid javascript. |
| 11:52 |
jeff |
doesn't seem to be a problem for the OpenILS::WWW::IDL2js handler, though... thus, /IDL2js doesn't seem to break (or generate invalid output) |
| 12:01 |
jeff |
possibly because something in that chain already strips out newlines -- maybe the locale bits in the subrequest that /IDL2js uses |
| 12:04 |
|
jihpringle joined #evergreen |
| 12:17 |
eeevil |
jeff: yeah, I updated the handler to strip newlines (and sql comments, required by the newline stripping). I wasn't actually aware of the test script |
| 12:18 |
jeff |
just got to that part. |
| 12:20 |
jeff |
I believe those two things are the only current (stock) users of fm_IDL2js.xsl |
| 12:30 |
jeff |
bshum: did you open a bug yet? |
| 13:04 |
jeff |
my launchpad hasn't noticed yet. |
| 13:04 |
jeff |
there we go |
| 13:04 |
jeff |
bug 1618136 has my proposed fix |
| 13:04 |
pinesol_green |
Launchpad bug 1618136 in Evergreen "webstaff build/test failures related to IDL2js" [Undecided,In progress] https://launchpad.net/bugs/1618136 - Assigned to Jeff Godin (jgodin) |
| 13:05 |
* jeff |
unassigns self |
| 13:05 |
jeff |
i opted for "preprocess in the same way" as opposed to "try to do those transforms in XSL so that fm_IDL2js.xsl does what the filename claims" :-) |
| 13:06 |
bshum |
Haha |
| 13:31 |
jeff |
that sounds... annoyingly similar to your kernel update -> different ethernet driver -> different device name woes from earlier in scrollback. |
| 13:32 |
tsbere |
jeff: Doesn't it? Differences including that it isn't a server I normally maintain, I wasn't installing the updates, and the network was *configured*, it just decided to change firewall modes on it. |
| 13:33 |
tsbere |
jeff: Oh, and the person who was installing updates is supposed to be on vacation and emailed me to go deal with the problem. |
| 13:37 |
bshum |
Tested the patch jeff and it does let me get to the next steps and have a working web client |
| 13:46 |
eeevil |
jeff: I'd be 100% in favor of having the xslt do the processing -- I'm too tuit poor to dig back into xslt string mangling now, though. as evidenced by my "fix" for getting any IDL views to work at all ;) |
| 15:25 |
|
abowling left #evergreen |
| 15:38 |
Dyrcona |
jeff: Do you think the branch on bug 1618136 is ready to go? bshum tried it and I can try it and possibly push it to master tonight. |
| 15:38 |
pinesol_green |
Launchpad bug 1618136 in Evergreen "webstaff build/test failures related to IDL2js" [Undecided,In progress] https://launchpad.net/bugs/1618136 |
| 15:44 |
jeff |
Dyrcona: IMO it's ready to go, yes. at some future point we might return and enhance fm_IDL2js.xsl to no longer require pre-processing, but the branch as it stands fixes the test failure. |
| 15:44 |
Dyrcona |
OK. I can agree with that, but fixing it for now is good enough for now. :) |
| 15:45 |
Dyrcona |
I'll give it a whirl this afternoon/tonight unless someone else beats me to pushing it. |
| 15:46 |
Dyrcona |
I still need to really look at the timezone branch, too. Other things come up, y'know? :( |
| 15:46 |
jeff |
I think it follows with the original spirit of the idl2js.pl support script: transform the IDL to js in a way similar to how OpenILS::WWW::IDL2js does, but do it without requiring that we already have a running system. |
| 15:47 |
jeff |
My branch just updates idl2js.pl to keep up with some new things that OpenILS::WWW::IDL2js does. |
| 15:47 |
|
jvwoolf joined #evergreen |
| 15:48 |
Dyrcona |
Yeah. I eyeballed the diff already. It looks good. I asked bshum to sign off since he tested already. |
| 15:48 |
Dyrcona |
I don't think 3 signoffs would hurt. :) |
| 15:49 |
eeevil |
jeff++ |
| 15:50 |
eeevil |
Dyrcona++ |
| 16:59 |
|
TARA joined #evergreen |
| 17:13 |
|
mmorgan left #evergreen |
| 17:26 |
|
jihpringle joined #evergreen |
| 17:32 |
pinesol_green |
[evergreen|Jeff Godin] LP#1618136 Fix webstaff IDL2js.js test failures - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=6bc0bc2> |
| 17:36 |
|
jvwoolf left #evergreen |
| 17:37 |
dbwells |
grabbing 1000 |
| 17:42 |
pinesol_green |
[evergreen|Ben Shum] LP#1618183: Add Spanish to config.i18n_locale - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=dddb70d> |
| 18:18 |
Dyrcona |
Ah, man. My drive home takes too long. ;) |
| 18:18 |
Dyrcona |
dbwells++ |
| 18:20 |
Dyrcona |
Well, I don't think it was just using the wifi at work that prevented my ssh to the vms, 'cause it isn't working now, either. |
| 18:25 |
dbwells |
Dyrcona: If you want something to do, a hot, fresh tarball could use some testing: https://evergreen-ils.org/downloads/Evergreen-ILS-2.11.beta.tar.gz |
| 18:26 |
* dbwells |
heads home |
| 18:27 |
Dyrcona |
OK. I'm trying to figure out why my vm networking is broken. |
| 18:27 |
bshum |
dbwells: One potential reason not to backport the Spanish thing is cause it's an INSERT and if someone upgrades to 2.10.next with it, then try to upgrade to 2.11.0, they'll likely bomb their upgrade due to a rollback when it tries to INSERT the same entry a second time later on |
| 18:28 |
bshum |
Either that or we try to safely add it in a separate part of the 2.11 upgrade script |
| 18:31 |
bshum |
I'll defer to gmcharlt on backport opinions; I'm fine with just focusing on the future with 2.11 |
| 18:34 |
|
berick joined #evergreen |
| 18:34 |
Dyrcona |
So, apparently, I built the xenial vm but didn't fix the networking after. |
| 18:34 |
Dyrcona |
bshum: Did you test the new tarball on xenial? |
| 18:35 |
bshum |
Dyrcona: Not yet, I just got home too :) |
| 18:35 |
Dyrcona |
Well, I'll test trusty if you test xenial. ;) |
| 18:35 |
bshum |
Haha, deal :) |
| 18:35 |
bshum |
I'll spin up a new VM install in my virtualbox |
| 18:35 |
bshum |
I got 25 minutes till dinner anyways :D |
| 18:36 |
bshum |
I can grab the tarball and finish the rest of the Evergreen install setup |
| 18:37 |
bshum |
I stopped at prereq installing earlier |
| 18:37 |
bshum |
So, perfect. |
| 18:37 |
Dyrcona |
Yeah, I was going to install on trusty where I tested the 2.9.7 tarball, but s'pose I could build a fresh one. |
| 18:38 |
Dyrcona |
I should build a vm just with opensrf and save a snapshot. |
| 18:39 |
bshum |
Heh, perhaps |
| 18:39 |
bshum |
I was just thinking the same thing actually |
| 19:13 |
Dyrcona |
Well, it woks for me. I tried the OPAC and the browser staff client. |
| 19:14 |
bshum |
Dyrcona++ |
| 19:14 |
Dyrcona |
Aw, shucks...T'weren't nothin'.... ;) |
| 19:15 |
Dyrcona |
bshum++ # For finding the test issue. |
| 19:15 |
Dyrcona |
jgodin++ |
| 19:15 |
Dyrcona |
jeff++ |
| 19:15 |
bshum |
csharp++ # he got me looking for it in the first place |
| 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... |
| 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: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: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 |
| 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 |
| 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! |
| 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 |
| 14:53 |
Stompro |
sandbergja, You are welcome. Let me know if you have any problems with it. You need the asset.call_number.id and the new label name as arguments. |
| 14:55 |
csharp |
miker: ah... that's better |
| 14:55 |
miker |
grabbing 0995 |
| 14:56 |
csharp |
okay, I've pushed a commit on top of my fix for bug 1613374 and I want to test it with mmorgan's testing method before calling it done, but I'm letting others know in case they want to look/test after me |
| 14:56 |
pinesol_green |
Launchpad bug 1613374 in Evergreen "Feature Request: "Canceled Transit" Item Status" [Wishlist,Confirmed] https://launchpad.net/bugs/1613374 - Assigned to Chris Sharp (chrissharp123) |
| 14:57 |
pinesol_green |
[evergreen|Mike Rylander] Moving function creation to later in the schema def, where its deps exist. - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=9fc0603> |
| 14:57 |
pinesol_green |
[evergreen|Kathy Lussier] LP#1614290: Add badge_score_generator to example crontab - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=fd725a7> |
| 15:21 |
|
mmorgan1 joined #evergreen |
| 15:31 |
pinesol_green |
[evergreen|Ben Shum] LP#1603708: Remove support for Ubuntu 12.04 Precise - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=be0ed35> |
| 15:58 |
|
kmlussier joined #evergreen |
| 16:04 |
* kmlussier |
needs to leave and won't be able to test https://bugs.launchpad.net/evergreen/+bug/1497335/ again if berick is able to incorporate the changes he made in his last comment. If anyone else has tuits to look at it, feel free! |
| 16:04 |
pinesol_green |
Launchpad bug 1497335 in Evergreen "Display aged circulations for copies (was: "virtually aged circulations")" [Wishlist,New] |
| 16:06 |
csharp |
miker: bug 1613374 looks good to me after some poking |
| 16:06 |
pinesol_green |
Launchpad bug 1613374 in Evergreen "Feature Request: "Canceled Transit" Item Status" [Wishlist,Confirmed] https://launchpad.net/bugs/1613374 - Assigned to Chris Sharp (chrissharp123) |
| 18:35 |
pinesol_green |
[evergreen|Bill Erickson] LP#1497335 Aged circ display release notes - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=5769707> |
| 18:35 |
pinesol_green |
[evergreen|Bill Erickson] LP#1497335 Show Last Few Circs patron retrieve options - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=3f2d3a0> |
| 18:35 |
pinesol_green |
[evergreen|Mike Rylander] Stamping upgrade scripts for aged circs display branch - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=15ad6d4> |
| 18:42 |
miker |
and ... that's it, folks. I think I've merged anything that was ready to be merged and was a feature. the remainder are bug fixes, or are in some way not complete or well tested enough (given their relative invasiveness). Now, on to bug fix merging (not today)! |
| 18:42 |
* miker |
calls beta locked for features |
| 18:44 |
|
Dyrcona joined #evergreen |
| 19:05 |
|
gsams joined #evergreen |
| 19:06 |
Dyrcona |
miker: If you're still around, what do you think of bug 1583608? |
