| Time |
Nick |
Message |
| 06:56 |
|
TARA joined #evergreen |
| 07:08 |
|
agoben joined #evergreen |
| 07:20 |
|
rjackson_isl joined #evergreen |
| 07:23 |
|
JBoyer joined #evergreen |
| 07:32 |
graced |
good morning #evergreen |
| 07:38 |
csharp |
d4f6bf89 |
| 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] |
| 08:18 |
* pinesol_green |
brews and pours a cup of Sumatra Golden Mandheling, and sends it sliding down the bar to book` |
| 08:18 |
kmlussier |
@tea [someone] |
| 08:18 |
* pinesol_green |
brews and pours a pot of Masala Chai, and sends it sliding down the bar to wsmoak (http://ratetea.com/tea/rishi/masala-chai/4495/) |
| 08:37 |
csharp |
would anyone be willing to share an EDI order response message (ORDRSP) from Baker & Taylor with me? |
| 08:38 |
|
mmorgan joined #evergreen |
| 08:52 |
kmlussier |
csharp: http://pastebin.com/iegHb7Q4 |
| 08:58 |
|
TARA joined #evergreen |
| 09:01 |
csharp |
kmlussier++ # thanks |
| 09:03 |
* csharp |
starts to appreciate the problem of developing out EDI parsing stuff for vendors who do everything differently and/or don't follow standards |
| 09:05 |
|
Dyrcona joined #evergreen |
| 09:13 |
|
yboston joined #evergreen |
| 10:02 |
berick |
csharp: you've earned your EDI Club jacket! beware, the sleeves are different lengths and the zippers only go in one direction. |
| 10:03 |
csharp |
berick++ |
| 10:04 |
mmorgan |
:) |
| 10:05 |
jeff |
you'll note that the jacket is reversible, though. if you turn it inside out, it's the NCIP Club jacket. |
| 10:05 |
berick |
:) |
| 10:05 |
jeff |
remove the XML outer layer and you have a SIP Club jacket, etc. :-) |
| 10:06 |
mmorgan |
And watch out for the pockets, they're portable holes! |
| 10:06 |
jeff |
though you do have to refer to it as a Club Jacket SIP, because some of the more extreme club members need everything to be in alphabetical order. |
| 10:07 |
jeff |
did I mention we recently evaluated a product that used very simple regular expressions to "parse" SIP messages? super robust. not fragile or problematic at all. |
| 10:08 |
Dyrcona |
jeff: I seem to recall a mention of that.... |
| 10:08 |
Dyrcona |
"Now, you've got two problems." ;) |
| 10:08 |
jeff |
pretty sure you'd never be able to deactivate a patron with the string "BLY" anywhere in their last name. |
| 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:13 |
|
jihpringle joined #evergreen |
| 12:31 |
|
rjackson_isl joined #evergreen |
| 12:34 |
|
brahmina joined #evergreen |
| 12:38 |
|
Christineb joined #evergreen |
| 12:41 |
Dyrcona |
Is the scclient account setup in the concerto data? |
| 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 |
| 12:56 |
Dyrcona |
Authors and call numbers are known (to me) to cause problems. |
| 12:56 |
Dyrcona |
With item info lookup. |
| 12:56 |
|
JBoyer joined #evergreen |
| 12:57 |
csharp |
@dunno add http://xkcd.com/1739/ |
| 12:57 |
pinesol_green |
csharp: The operation succeeded. Dunno #49 added. |
| 12:57 |
Dyrcona |
heh |
| 12:58 |
Dyrcona |
For now, I think I'll set this up how we did it at MVLC with a separate SIP permission group with its own permissions. |
| 13:01 |
kmlussier |
csharp++ |
| 13:08 |
Dyrcona |
And the mouseover is perfect... :) |
| 13:09 |
kmlussier |
Ha ha. I missed that. |
| 13:15 |
|
collum joined #evergreen |
| 13:16 |
Dyrcona |
That sounds so much like me. ;) |
| 13:17 |
Dyrcona |
Yay for DO...DECLARE...BEGIN...END in pgsql. |
| 13:17 |
Dyrcona |
Not related. :) |
| 13:20 |
Dyrcona |
Boo for typos. :) |
| 13:23 |
Dyrcona |
dbs: Maybe I'll add René Descartes as a patron.... |
| 13:23 |
jeff |
< Dyrcona> dbs: Maybe I'll add Ren? Descartes as a patron.... |
| 13:23 |
jeff |
amusing. |
| 13:23 |
Dyrcona |
It looks good on my screen. :) |
| 13:24 |
Dyrcona |
That's how SIP should see the name. :) |
| 13:34 |
Dyrcona |
UNIVERSAL does not export anything at Sip/MsgType.pm line 30. |
| 13:34 |
Dyrcona |
BEGIN failed--compilation aborted at Sip/MsgType.pm line 30. |
| 13:34 |
Dyrcona |
I think we knew that was coming... :) |
| 13:46 |
Dyrcona |
So, with stock master, logins are failing. I'm not even getting to the osrf layer. |
| 13:46 |
Dyrcona |
OIC! |
| 13:47 |
Dyrcona |
The password isn't what I thought it was in oils_sip.xml. |
| 13:48 |
Dyrcona |
OK. It works. |
| 13:48 |
Dyrcona |
berick++ pysip2++ |
| 13:49 |
berick |
Dyrcona: yay, glad it's useful. lemme know if it's missing anything critical. pullreqs accepted too, of course. |
| 13:49 |
Dyrcona |
:) |
| 13:54 |
Dyrcona |
dbs: There are some concerto titles with accented characters (CONC4000036) being the barcode for one. |
| 13:54 |
Dyrcona |
It's Italian. The current code handles titles OK. |
| 13:57 |
jeff |
hrm. why did i think that behind_desk was not a per-hold attribute? |
| 13:57 |
berick |
jeff: it is |
| 13:57 |
berick |
oh |
| 13:57 |
jeff |
(there is indeed an action.hold_request.behind_desk boolean not null default false) |
| 13:57 |
berick |
it wasn't previously |
| 13:57 |
berick |
it was just a per-user setting |
| 13:57 |
berick |
now it's both |
| 13:58 |
jeff |
yeah, guess i missed that event. happy to see it there now. :-) |
| 13:59 |
jeff |
all false in our system. |
| 13:59 |
jeff |
(which is what i expected) |
| 13:59 |
berick |
iirc, there's an org setting to enable the feature |
| 14:00 |
berick |
bools abound |
| 14:00 |
jeff |
i'm interested in using it for ILLs and MeLCat holds placed via NCIP. |
| 14:01 |
jeff |
so that we can be careful to call out the fact that you'll need to ask staff to get those holds, alert on self checkout terminals, etc. |
| 14:02 |
|
bmills joined #evergreen |
| 14:02 |
jeff |
because it's a little silly to tell you that you have holds ready for pickup if you already grabbed those items off the public hold shelf and are trying to check them out at that self checkout terminal, but it's useful to say "after you're done here, you should ask at the desk because you have some other holds behind the desk" |
| 14:14 |
|
brahmina joined #evergreen |
| 14:15 |
|
DPearl joined #evergreen |
| 14:18 |
DPearl |
Is there any instance where more than one asset.copy_part_map rows point to the same asset.copy? We have a small (but disquieting) number of these rows in our db. |
| 14:19 |
* jeffdavis |
goes to add a "myopac_page" var to templates, discovers that it already exists, is pleased |
| 14:21 |
kmlussier |
DPearl: That sounds special. |
| 14:22 |
* kmlussier |
looks |
| 14:24 |
DPearl |
kmlussier: "special" gives me the shakes. |
| 14:24 |
Dyrcona |
heh |
| 14:24 |
kmlussier |
DPearl: Well, I said that before looking at it more closely. So you can delay your shakes for a bit. |
| 14:27 |
bmills |
DPearl: looks like we have 3 duplicates in ours… |
| 14:28 |
DPearl |
Beats me how to create one if I wanted to. |
| 14:30 |
Dyrcona |
So on the item lookup with SIP2, looks like the call number has to have the accented character to cause issues. |
| 14:31 |
kmlussier |
DPearl: Yeah, I haven't found a way to make it happen yet. I wonder if it's related to transferring parted copies from one record to another. |
| 14:32 |
kmlussier |
However it's done, though, I would guess it's not expected behavior. |
| 14:32 |
DPearl |
kmlussier: It has to be something there that went off the track. The schema should be updated to prohibit this, I think, to maintain the db consistency. |
| 14:33 |
DPearl |
kmlussier: We have 128 instances to sort out! |
| 14:36 |
kmlussier |
Yikes! |
| 14:36 |
kmlussier |
Transferring copies doesn't replicate the problem, either. |
| 14:40 |
JBoyer |
kmlussier, DPearl, do you mean the same part is mapped to the same copy multiple times, or a single copy has multiple parts? I can't tell from your discussion exactly what you're seeing. |
| 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:39 |
StomproJosh |
How do you all handle negative notice preferences? How can another action trigger know to include someone because they opted-out of a different notice. Like if they say no to automated phone calls for overdue's, include them in the USPS postcard notice. |
| 15:41 |
Dyrcona |
Oh, maybe this is my problem: Use of uninitialized value in subroutine entry at /usr/lib/x86_64-linux-gnu/perl/5.22/Encode.pm line 229, <STDIN> chunk 2. |
| 15:41 |
jeff |
StomproJosh: we handle that externally (and infrequently), but a validator may be the answer? of course, this reminds me that i think we've had discussion about stacking validators... |
| 15:42 |
Bmagic_ |
kmlussier: yes |
| 15:42 |
jeff |
Dyrcona: that looks usual. ;-) |
| 15:42 |
Dyrcona |
Yeap. |
| 15:42 |
Dyrcona |
These records have diacritics..... |
| 15:42 |
Dyrcona |
Though other records with diacritics worked. |
| 15:43 |
dbs |
@who is doing important SIP unicode work? |
| 15:43 |
pinesol_green |
Bmagic_ is doing important SIP unicode work. |
| 15:43 |
Bmagic_ |
awww shucks |
| 15:43 |
Bmagic_ |
I really need to get rid of my nick's tail |
| 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 |
| 15:49 |
jeff |
unless you're talking about something else. |
| 15:52 |
DPearl |
jboyer: Two copy_part_map entries both point to the same target_copy id, but with different monograph_part id's. It's like one copy has two parts at the same time. |
| 15:54 |
Dyrcona |
jeff: Yeah, that's what I mean, basically. |
| 15:55 |
Dyrcona |
In my fiddling around yesterday, I discovered that the decode doesn't blow up if you wrap it with an encode, first. |
| 15:55 |
kmlussier |
Bmagic++ #Getting Sandboxes ready for tomorrow. :) |
| 15:55 |
* Dyrcona |
gets started on the branch to excise clean_text. |
| 15:56 |
Dyrcona |
Bmagic++ |
| 15:56 |
Bmagic |
:) |
| 15:59 |
dbs |
Encode 2.49 on our Ubuntu 14.04. Dunno what's on Jessie. |
| 16:01 |
dbs |
looks like 2.60 |
| 16:01 |
Dyrcona |
Hmm.. Supercat might suffer this problem with Encode, too. |
| 16:01 |
* dbs |
wonders how much pain we've suffered due to Encode.pm changes over the years |
| 16:01 |
Dyrcona |
I'll check that tomorrow. |
| 16:02 |
JBoyer |
DPearl, that does sound familiar, but I don't believe I had the time to track down possibilities. :/ I was thinking record merging might be involved (as opposed to vol/copy transfers) but it's been a while... |
| 16:02 |
dbs |
Dyrcona: possibly why Eva et al are encountering issues with added content |
| 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. |
| 16:05 |
Dyrcona |
gmcharlt's sample on Lp 1542495 for instance. |
| 16:06 |
pinesol_green |
Launchpad bug 1542495 in Evergreen "OpenILS::SIP::clean_text() can crash" [Undecided,Confirmed] https://launchpad.net/bugs/1542495 |
| 16:06 |
jeff |
dbs: the added content bits had a different issue altogether, which i think miker fixed already. |
| 16:06 |
dbs |
oh good. |
| 16:07 |
Dyrcona |
But I guess the string constant is auto-decoded, so an encode(decode) sequence works. |
| 16:08 |
dbs |
So the mnemonic had been "decode() on input, encode() on output) |
| 16:10 |
Dyrcona |
I think it still is. You are quite likely right about it not being sage to double decode. |
| 16:11 |
Dyrcona |
sage or safe.... :) |
| 16:11 |
Dyrcona |
That's what I get out of the github discussion. |
| 16:11 |
Dyrcona |
The biggest complaint is the change was not mention in perl520delta. |
| 16:13 |
|
mmorgan1 joined #evergreen |
| 16:19 |
|
DPearl left #evergreen |
| 16:19 |
|
dpearl_ joined #evergreen |
| 16:26 |
Dyrcona |
Oh. I noticed a comment in the clean_text code that maybe I should do in the SIPServer branch.... |
| 16:27 |
Dyrcona |
Apparently, stripping combining characters before encoding produces better output. |
| 16:27 |
Dyrcona |
I'll give that a whirl tomorrow, too. |
| 16:35 |
Dyrcona |
Not a big deal: 3 files changed, 21 insertions(+), 65 deletions(-) |
| 16:36 |
Dyrcona |
This is going to need a release note, for sure, because you are going to need to upgrade SIPServer at the same time. |
| 16:36 |
* Dyrcona |
starts to think maybe csharp was right about SIPServer releases. :) |
| 16:36 |
jeff |
sipserver needs versioning, yes. |
| 16:38 |
Dyrcona |
I disagreed on Lp, but I've since changed my mind. |
| 16:38 |
* StomproJosh |
will have to upgrade sipserver sometime... I think Galen installed it the first time... I hope there are install instructions. |
| 16:39 |
Dyrcona |
StomproJosh: Install it from git and an update is just a git pull away. ;) |
| 16:39 |
StomproJosh |
Dyrcona, that is good to know, it is installed from git... 6 commits behind. |
| 16:40 |
dbs |
wait... stripping combining characters? Is this for pure ASCII output or what? |
| 16:41 |
Dyrcona |
Yes, it is for ascii. Look at OpenILS::SIP::clean_text(), there's if (encoding == 'ascii') block with more comment than code explaining it. |
| 16:42 |
dbs |
ah, okay. I thought this was for the UTF-8 encoding output path! |
| 16:42 |
Dyrcona |
Nope, but I might add that trick for ascii on the SIPServer side. |
| 16:42 |
jeff |
sub mangle_utf8() { |
| 16:42 |
jeff |
... |
| 16:42 |
Dyrcona |
And, I'm starting to think this may not be the best approach... |
| 16:43 |
Dyrcona |
But, we'll see. Something is better than breaking either the clients or the server. :) |
| 16:44 |
Dyrcona |
And, rather than do a full make, I'll just copy the changed SIP files into place. |
| 16:45 |
dbs |
So I'm still wondering if the real problem is that we're missing a final encode() on the Supercat / unapi output / wherever we're pulling the incoming text from, rather than any problem on the SIP input side |
| 16:45 |
dbs |
our "something" was to just return the text for the item title directly, rather than call clean_text, so that we got nice clean UTF-8 :) |
| 16:45 |
dbs |
hack vs hack for different hacky purposes |
| 16:47 |
Dyrcona |
Yeah, your comments earlier about Eva's issues with added content and jeff's comments about miker fixing it got me down that path. |
| 16:47 |
Dyrcona |
That's why I said I'm starting to think this might not be the right fix. |
| 16:50 |
dbs |
ahh - 3ad39d5e661cf8 ? |
| 16:50 |
pinesol_green |
dbs: [evergreen|Mike Rylander] MARC21 feed support - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=3ad39d5> |
| 16:51 |
dbs |
where we now call utf8::encode instead of entityize? Hmm |
| 16:51 |
Dyrcona |
I'm not sure. |
| 16:52 |
Dyrcona |
Seems we have kind of a hodge podge when it comes to handling encoding. |
| 16:53 |
Dyrcona |
So, I'm still hanging with these records, but I haven't installed my SIPServer changes, just the Evergreen side. |
| 16:56 |
dbs |
yeah, my head hurts and I have to prep an info lit class for tonight |
| 16:57 |
Dyrcona |
All right. I'm heading home. |
| 17:02 |
dbs |
perldoc utf8 says about utf8::encode "Note that this function does not handle arbitrary encodings; therefore Encode is recommended for the general purposes." (exact wording has changed over time) |
| 17:02 |
dbs |
oh perl unicode. |
| 17:06 |
|
mmorgan1 left #evergreen |
| 17:07 |
|
bmills joined #evergreen |
| 17:18 |
StomproJosh |
Has anyone experienced slower check-in after a 2.8 ish to 2.9 or 2.10 migration? Staff are reporting just slightly slower check-in response which is throwing off their flow after our 2.8 to 2.10 migration. |
| 17:20 |
StomproJosh |
Is there a good way to benchmark check-in speed? Look at the log timestamps? |
| 17:21 |
dbs |
StomproJosh: ours has been timing out occasionally after going from 2.7 to 2.10. so yeah. |
| 17:21 |
jeff |
meanwhile, no reported issues here from going 2.7 to 2.10 |
| 17:22 |
jeff |
(specifically, no reported slower checkin issues) |
| 17:22 |
berick |
StomproJosh: log timestamps are a good start. |
| 17:24 |
StomproJosh |
Thanks for the feedback. I'll try and compare the logs for a few check-ins before and after the migration. |
