| Time |
Nick |
Message |
| 00:52 |
jeff |
~ |
| 00:52 |
jeff |
hrm. |
| 01:16 |
|
Bmagic|2 joined #evergreen |
| 02:40 |
|
rsinger joined #evergreen |
| 03:20 |
|
afterl joined #evergreen |
| 05:55 |
|
rsinger joined #evergreen |
| 06:00 |
|
mrpeters joined #evergreen |
| 06:33 |
|
mtj_ joined #evergreen |
| 07:52 |
csharp |
@weather 30345 |
| 07:52 |
pinesol_green |
csharp: The current temperature in Lakeside, Atlanta, Georgia is 24.4°F (7:45 AM EST on January 23, 2014). Conditions: Clear. Humidity: 51%. Dew Point: 8.6°F. Windchill: 24.8°F. Pressure: 30.32 in 1027 hPa (Rising). Wind Chill Advisory in effect from 9 PM this evening to 10 am EST Friday... |
| 07:57 |
|
afterl1 joined #evergreen |
| 08:00 |
|
afterl1 left #evergreen |
| 08:02 |
|
ericar joined #evergreen |
| 08:09 |
|
jtaylorats joined #evergreen |
| 08:11 |
|
collum joined #evergreen |
| 08:23 |
|
ericar joined #evergreen |
| 08:30 |
|
Shae joined #evergreen |
| 08:37 |
|
ericar joined #evergreen |
| 08:38 |
|
ericar_ joined #evergreen |
| 08:41 |
|
akilsdonk joined #evergreen |
| 08:46 |
|
kbeswick joined #evergreen |
| 08:47 |
|
jwoodard joined #evergreen |
| 08:48 |
dbs |
Oh right. Of course there's yet another copy table... this time for KPAC |
| 08:48 |
* dbs |
goes back to the branch trenches |
| 08:48 |
dbs |
@wunder sudbury, ontario |
| 08:48 |
pinesol_green |
dbs: The current temperature in Sudbury, Ontario is -14.8°F (8:00 AM EST on January 23, 2014). Conditions: Light Snow. Humidity: 77%. Dew Point: -20.2°F. Windchill: -38.2°F. Pressure: 30.31 in 1026 hPa (Rising). |
| 08:49 |
mrpeters |
@wunder 46060 |
| 08:49 |
pinesol_green |
mrpeters: The current temperature in Downtown Noblesville, Noblesville, Indiana is -0.2°F (8:43 AM EST on January 23, 2014). Conditions: Clear. Humidity: 55%. Dew Point: -13.0°F. Windchill: -9.4°F. Pressure: 30.38 in 1029 hPa (Steady). Wind Chill Advisory in effect until noon EST Friday... |
| 08:49 |
mrpeters |
poor dbs :( |
| 08:49 |
mrpeters |
thats brutal....we were in the -20's for wind chill earlier this morning before sun came up |
| 08:49 |
* dbs |
hopes to get another ski outing in this morning |
| 08:50 |
mrpeters |
this winter has been epic (in a bad way) |
| 08:50 |
mrpeters |
at least for Indiana |
| 08:50 |
mrpeters |
we're already 10 inches over our average annual snowfall |
| 08:51 |
mrpeters |
another blizzard due to hit saturday |
| 08:51 |
|
mmorgan joined #evergreen |
| 08:54 |
mtate |
@wunder 30096 |
| 08:54 |
pinesol_green |
mtate: The current temperature in City of Berkeley Lake, Berkeley Lake, Georgia is 25.0°F (8:50 AM EST on January 23, 2014). Conditions: Clear. Humidity: 52%. Dew Point: 10.4°F. Windchill: 24.8°F. Pressure: 30.35 in 1028 hPa (Rising). Wind Chill Advisory in effect from 9 PM this evening to 10 am EST Friday... |
| 08:56 |
mtate |
not as cold, but coolder than normal here too |
| 08:57 |
|
Dyrcona joined #evergreen |
| 08:57 |
mtate |
I feel for the folks headed to Philly for ALA-MW, they'll be getting their money's worh out of that "W" |
| 09:05 |
|
finnx joined #evergreen |
| 09:13 |
csharp |
the snowfall in Georgia is holding steady at 0 inches ;-) |
| 09:13 |
mrpeters |
mtate: ouch, thats rough. it was gorgeous down there when i came for our holiday party a couple weekends ago |
| 09:13 |
mrpeters |
60's, sunny....everyone else seemed cold but we were driving around with windows down haha |
| 09:13 |
csharp |
yeah, we've been going from frigid to beautiful and back over the last few weeks |
| 09:19 |
dbs |
And then of course KPAC library info link in the copy table leads to a TPAC library page, busting one out of the KPAC context |
| 09:20 |
dbs |
@hate supporting multiple catalogues |
| 09:20 |
pinesol_green |
dbs: The operation succeeded. dbs hates supporting multiple catalogues. |
| 09:21 |
|
mllewellyn joined #evergreen |
| 09:22 |
pastebot |
"jboyer-isl" at 64.57.241.14 pasted "coded value map errors" (2 lines) at http://paste.evergreen-ils.org/57 |
| 09:24 |
jboyer-isl |
Our 2.5 system has these ccvm select errors all over the logs (an int field is being used in a where like so: where id='') |
| 09:24 |
jboyer-isl |
Does anyone have an idea where to look to track that one down? |
| 09:34 |
|
timf joined #evergreen |
| 09:35 |
Dyrcona |
jboyer-isl: It would help if you can find corresponding entries in osrfsys.log. |
| 09:36 |
Dyrcona |
IANM: There should be corresponding query failures in there and some backend messages. That should get you closer to the code in Evergreen that is making the bad database call. |
| 09:36 |
jboyer-isl |
And now that I've done that it makes slightly more sense: "editor[0|0] request error open-ils.cstore.direct.config.coded_value_map.search.atomic : {"id":""} : Exception: OpenSRF::DomainObject::oilsMethodException" |
| 09:37 |
jboyer-isl |
With more behind, obviously. |
| 09:38 |
jboyer-isl |
Always working backward is debugging... :/ |
| 09:39 |
Dyrcona |
heh. |
| 09:40 |
Dyrcona |
I have found several variations on that call in my osrfsys.log on my development VM, but none where it the argument is {"id":""}. |
| 09:41 |
csharp |
dbs++ # "KPAC: Won't somebody think of the children's record details?" |
| 09:41 |
jeff |
jboyer-isl: is there a thread trace id on the most recent editor error you pasted? i'd grep for that to see if you can get any earlier entries. |
| 09:41 |
csharp |
colorful_commit_messages++ |
| 09:43 |
jboyer-isl |
jeff: yes (you're referring to a number like so: 1390132209139741485 ?) and there are many references to "see error log for more details" but the details are coming up pretty short. I can tell it's calling that method incorrectly, but I can't see why or where. |
| 09:43 |
csharp |
maybe up the loglevel? |
| 09:43 |
jboyer-isl |
I suppose that' |
| 09:44 |
jboyer-isl |
s the only option at the moment. At least it's very lightly used currently. |
| 09:44 |
jeff |
i only see two calls to search_config_coded_value_map in the Evergreen perl libs in master. That makes me wonder if it's something like pcrud -- but that's a bit of a stab. |
| 09:45 |
jeff |
jboyer-isl: Can you share (after any redaction) the log entries that have that thread id? 1390132209139741485? |
| 09:45 |
dbwells |
jboyer-isl: My money is on something going wrong with commit f337381d for you. |
| 09:45 |
pinesol_green |
[evergreen|Thomas Berezansky] Translate the icon labels in TPAC - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=f337381> |
| 09:45 |
jeff |
dbwells++ |
| 09:45 |
jeff |
"the queries are coming from INSIDE the database!" |
| 09:45 |
jboyer-isl |
jeff: shortly. |
| 09:45 |
csharp |
jeff++ |
| 09:46 |
dbwells |
Maybe for some reason your unapi.mra function didn't get replaced, and isn't sending back the id? |
| 09:46 |
|
rjackson-isl joined #evergreen |
| 09:46 |
|
BigRig joined #evergreen |
| 09:48 |
pastebot |
"jboyer-isl" at 64.57.241.14 pasted "a bunch of bummers" (35 lines) at http://paste.evergreen-ils.org/58 |
| 09:48 |
jeff |
jboyer-isl: yeah, follow dbwells' suggestion. |
| 09:49 |
jboyer-isl |
How does one check that? I'm not familiar with it. |
| 09:50 |
jboyer-isl |
Oh, hey, I could follow the link pinesol put in here. I missed that message dbwells. I'm looking now. |
| 09:51 |
|
yboston joined #evergreen |
| 09:52 |
jboyer-isl |
Well, hello there missing line. That is missing. I'll see if there's anything else missing from that commit. |
| 09:52 |
jeff |
jboyer-isl: i was going to suggest looking at the output of \df+ unapi.mra -- see if this is present: cvm.id AS "cvmid" |
| 09:52 |
jboyer-isl |
Dyrcona++ jeff++ dbwells++ |
| 09:53 |
jboyer-isl |
jeff: and indeed, it is not. |
| 09:53 |
jeff |
and in checking, i see it missing in our 2.5.1 system. interesting. |
| 09:53 |
* jeff |
checks that function in rel_2_5 |
| 09:54 |
dbwells |
jboyer-isl: Was this a clean install of 2.5.2, or an upgrade from an earlier 2.5? |
| 09:55 |
jeff |
I don't see 0850 present in any file in Open-ILS/src/sql/Pg/version-upgrade/ on rel_2_5 |
| 09:55 |
jeff |
ack -l cvmid Open-ILS/src/sql/ |
| 09:55 |
jeff |
Open-ILS/src/sql/Pg/990.schema.unapi.sql |
| 09:55 |
jeff |
Open-ILS/src/sql/Pg/upgrade/0850.cvm_translated.sql |
| 09:55 |
jboyer-isl |
dbwells: "upgrade," so to speak |
| 09:56 |
jeff |
so maybe that's the issue. |
| 09:56 |
jeff |
since i have a similarly different function, i'll check logs. |
| 09:56 |
dbwells |
jeff: yes, about to "forward port" that. It is only in rel_2_5_2 at the moment |
| 09:57 |
dbwells |
That is, 2.5.1-2.5.2-upgrade-db.sql in the tag and the release tarball. |
| 09:57 |
jboyer-isl |
I see. We've tracking rel_2_5, so I must have caught it between the commit and the upgrade script. |
| 09:57 |
jeff |
dbwells: ah. do you think it would cause the log error jboyer-isl is experiencing in a 2.5.1 system, or is that commit not in 2.5.1? i guess i should look at that first. |
| 09:58 |
dbwells |
jboyer-isl: That is likely the issue. The only real safe way to install from a rel_x_x branch is to use the numbered upgrade scripts as they happen. |
| 09:58 |
jeff |
okay, it's not in 2.5.1, that's why I don't see it. :-) |
| 09:58 |
jeff |
(i.e., not a problem for us, not expected to be there, 2.5.2 isn't cut yet so it would not be expected to be in a version-upgrade script.) |
| 09:58 |
jeff |
and now I'm just re-stating what dbwells is saying. oops. :-) |
| 09:59 |
jeff |
jboyer-isl: so if you run Open-ILS/src/sql/Pg/upgrade/0850.cvm_translated.sql i would expect the symptoms to go away. |
| 09:59 |
dbwells |
2.5.2 is cut, and this commit is in the version upgrade script there. I need to get that into rel_2_5 and master, but that isn't really meant for this case. |
| 10:00 |
jeff |
dbwells: oops. right you are. thanks for the correction. :-) |
| 10:00 |
jboyer-isl |
This is also an artifact of our build, I believe the db was only upgraded through 2.5.0 or thereabouts, and the running code is closer to 2.5.2. |
| 10:01 |
jboyer-isl |
i.e. it's not 100% ideal at the moment. |
| 10:01 |
jeff |
jboyer-isl: perhaps to state the obvious, that's not really recommended. ;-) |
| 10:01 |
Dyrcona |
I think I misunderstood, because it is in master AFAICT. |
| 10:01 |
dbwells |
jboyer-isl: In a minute or so I will have the 2.5.2 script forward ported into rel_2_5, or you can use the numbered scripts higher than your last one in the DB upgrade log. |
| 10:01 |
jboyer-isl |
AFK, called to duty! |
| 10:02 |
jeff |
Dyrcona: 0850 is in the baseline and in a numbered upgrade script and in a version upgrade script in tags/rel_2_5_2 -- and about to be in rel_2_5. does that clear up any misunderstanding? |
| 10:03 |
jeff |
jboyer-isl: i'd be interested to hear if running that upgrade script (to update unapi.mra) eliminates the log symptoms for you -- seems likely that it will. |
| 10:09 |
pinesol_green |
[evergreen|Dan Wells] Forward port 2.5.2 upgrade script - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=6cebf87> |
| 10:24 |
|
jbfink joined #evergreen |
| 10:32 |
|
rfrasur joined #evergreen |
| 10:43 |
|
j_scott joined #evergreen |
| 10:49 |
jboyer-isl |
I do hate unloading -2 degree glass. |
| 10:50 |
rfrasur |
Um, yeah. |
| 10:50 |
jboyer-isl |
dbwells: I'll be looking forward to that script hitting rel_2_5 and will let everyone know how it goes. I expect it to be corrected also. |
| 10:50 |
rfrasur |
WHY are you unloading glass? |
| 10:51 |
jboyer-isl |
Many hands make cold work, or something like that. |
| 10:51 |
rfrasur |
rephrased. What's the glass for? |
| 10:53 |
jboyer-isl |
Oh, right. I guess I answered "Why are YOU unloading glass?" Shelves for some new display cases. |
| 10:53 |
rfrasur |
Oh, cool. Or....cold. |
| 10:54 |
dbs |
Unloading Google Glass would be cooler. |
| 10:55 |
dbwells |
jboyer-isl: The script is there. Still, if you are going to be running from rel_x_x on a regular basis, you should probably get used to the idea of running the "numbered" scripts (e.g. 0850.cvm_translated.sql) as they happen. The DB in a rel_x_x branch can change any time, but the combined upgrade scripts only materialize when a release is cut. |
| 10:56 |
jboyer-isl |
dbwells: Understood. A lot is learned in your first upgrade! |
| 10:56 |
jboyer-isl |
dbs: And so much lighter! |
| 10:57 |
* tsbere |
digs into SIPServer and evergreen's related code to see if he can reduce the time patron information responses seem to want to take |
| 10:57 |
rfrasur |
Are they redecorating the "exhibit hall" when you come in on the north side? (that far corner is depressingly bare) |
| 10:58 |
dbwells |
jboyer-isl: :) There is also a little helper script which can apply the numbered upgrade scripts, but I don't use it often enough to recall exactly what it is called. Someone else might chime in on that. |
| 10:58 |
|
phasefx joined #evergreen |
| 10:58 |
jboyer-isl |
rfrasur: yes. I only briefly looked around but I think there will be close to 10 displays down there. |
| 10:58 |
rfrasur |
Excellent! |
| 11:00 |
|
BigRig_ joined #evergreen |
| 11:00 |
|
akilsdonk_ joined #evergreen |
| 11:02 |
|
mtate joined #evergreen |
| 11:10 |
jeff |
tsbere: This interests me. What has brought SIP patron retrieval performance to your attention? |
| 11:11 |
jeff |
One thing that slows things down is if the SIP client is also requesting things like holds details -- XSLT operations for each bib probably contribute to much of the time spent. |
| 11:12 |
jeff |
I had some notes about this, but it's possible they're just in my head. :P |
| 11:12 |
tsbere |
jeff: You have no idea. and my first thought on fixing it doesn't work. :( |
| 11:12 |
|
jbfink joined #evergreen |
| 11:12 |
jeff |
tsbere: sorry, I have no idea about what? |
| 11:13 |
tsbere |
jeff: Know those XSLT operations you just mentioned? Every patron info response likely does them. Even *without* details being requested. |
| 11:14 |
jeff |
got it. that rings a bell. :-) |
| 11:14 |
jeff |
Anyway, is this just a "staff say patron retrieval is slow", or something else driving it? |
| 11:15 |
tsbere |
This is a "vendors are timing out because the lookup takes too long for patrons with insane hold queues" thing. >_> |
| 11:15 |
jeff |
It isn't like I don't also have other things to work on, I just have a strong interest in this. Sorry to pester with questions. :-) |
| 11:15 |
jeff |
Ah. What's your upper limit for outstanding hold requests? |
| 11:15 |
tsbere |
If we have one configured, probably 1000. I don't think we have one configured. |
| 11:16 |
jeff |
Yeah, ours is 40. The delay is noticeable, but not resulting in timeouts. |
| 11:17 |
tsbere |
The current "problem patron" exceeds 100 right now. <_< |
| 11:17 |
jeff |
And since I maintain about 38 holds (mostly suspended at the moment), I think about it every time I check out materials. :-) |
| 11:17 |
Dyrcona |
We don't have a holds limit. One thousand is our checkout limit. |
| 11:18 |
jeff |
Interesting. |
| 11:18 |
jeff |
we cap both at 40 max. |
| 11:18 |
csharp |
PINES caps both at 50 |
| 11:18 |
Dyrcona |
Our members believe in "serving the patron!" Whatever that means. :) |
| 11:19 |
jeff |
though with melcat it gets slightly more complex -- patrons can have up to 50 melcat "transactions" open, which are open from time of request to time item checks in back at its lending library. |
| 11:19 |
csharp |
our motto is the same with the addendum of "(as long as they don't want more than 50 items/holds)" |
| 11:20 |
tsbere |
Looks like to make this less of an issue I need to modify both evergreen and sipserver. BAH. |
| 11:20 |
Dyrcona |
csharp: It usually amounts to "serving this patron right here in front of me right now to the detriment of some other patron who might show up later." |
| 11:20 |
Dyrcona |
tsbere: Sounds about right. |
| 11:21 |
csharp |
Dyrcona: true |
| 11:21 |
jeff |
tsbere: work worth doing. i'll keep my eyes open for what you come up with. :-) |
| 11:22 |
* csharp |
worked as a reference librarian in the northern suburbs for a while, where every patron took for granted that they were the exception to the rules |
| 11:22 |
csharp |
northern *Metro Atlanta* suburbs, I should add |
| 11:23 |
csharp |
cause y'all live other places and stuff |
| 11:25 |
Dyrcona |
I've often wondered why have rules if staff can make exceptions for anyone? |
| 11:25 |
Dyrcona |
Anyway, I've got some copy locations to change.... |
| 11:26 |
* dbs |
starting to feel stupid as a basic attempt to hook up library pages with a KPAC look through EGKPacLoader is failing miserably :/ |
| 11:26 |
rfrasur |
"can" and "do" are diff. |
| 11:27 |
dbs |
Oh, there we go. Had to copy the opac library template over to the kpac directory. Still need the kpac branding though |
| 11:34 |
jeff |
we're going to do in-building laptop circ with evergreen, and while i can configure a circ modifier for "this can circ to this computer-use-only user" while leaving the "computer-use-only can't check anything else out" rules in place, there is no circ modifier based method of saying "yep, bypass max fines and max items out" |
| 11:35 |
jeff |
so we're going to have staff in the habit of overriding more things to check out the laptops. |
| 11:35 |
jeff |
i'm tempted to do a web based checkout for staff to use that auto-overrides those things and only those things. :-) |
| 11:35 |
jeff |
or, in those circumstances and only those, etc. |
| 11:35 |
jeff |
likely not to start, though. |
| 11:35 |
Dyrcona |
Why not make that an opportunity to get the patron to pay their fines? |
| 11:36 |
jeff |
we don't require fine payment to use the existing public computers, and that will carry over to the laptops. i would hope that we'll raise the issue, however gently. |
| 11:37 |
jeff |
in other news, the laptops will be chromebooks, so that will be fun. :-) |
| 11:37 |
Dyrcona |
Chromebooks seem to be made for this type of thing. |
| 11:37 |
* rfrasur |
listens with interest. |
| 11:38 |
jeff |
we'll be using the chrome management console to enable support for things like public sessions, etc. |
| 11:38 |
rfrasur |
Jeff have you looked at your wireless usage compared to PAC usage? |
| 11:38 |
jeff |
toyed with the idea of requiring patrons to sign into the wireless after checking out the chromebook, but opted to go with "no time limits" and skip that. |
| 11:39 |
jeff |
rfrasur: i have, and so can you! http://www.tadl.org/stats/ |
| 11:39 |
rfrasur |
hah! I forgot about your awesome dashboard. |
| 11:40 |
jeff |
the idea with the chromebooks is to meet that "just need the internet, thanks!" need, and free up some space in our main computing lab, and reduce the number of computers in there, but up the quality. |
| 11:40 |
jeff |
so we might put more neat software on them, or add a nice large format scanner or a high volume document scanner, etc. |
| 11:40 |
rfrasur |
user_driven_technology_plans++ |
| 11:40 |
jeff |
and now we're way off-topic for #evergreen, sorry. :-) |
| 11:41 |
tsbere |
bah, I just found code doing something like what I am, but I have no clue why. Or where it is used. |
| 11:41 |
jboyer-isl |
I wish they were available when JCPL bought their laptops. Even my CR-48 was WAY better than the crappy little Toshibas they ended up with. :( |
| 11:41 |
jeff |
"we can buy six windows laptops or 30 chromebooks" |
| 11:42 |
rfrasur |
So, this is an #evergreen question that I've probably already asked. If (when) we have a web-based client does that also mean that it'll be OS agnostic? |
| 11:42 |
rfrasur |
(related to Chromebooks/ChromeOS/Android) |
| 11:42 |
Dyrcona |
It is theoretically OS agnostic now, the OS just has to support Firefox/Xulrunner. |
| 11:43 |
rfrasur |
Hmm, has anyone experimented with Chrome OS? |
| 11:43 |
Dyrcona |
In theory, yes, but it'll have all the usual browser compatibility issues. |
| 11:43 |
jeff |
rfrasur: the current web prototype should run fine on a chromebook. i haven't tested it yet. your issues come down to printing support and rfid support (if applicable) |
| 11:43 |
* rfrasur |
files this |
| 11:43 |
Dyrcona |
@hate printing |
| 11:43 |
pinesol_green |
Dyrcona: The operation succeeded. Dyrcona hates printing. |
| 11:43 |
jboyer-isl |
dbwells, jeff: Re: earlier today. Success! ccvm errors have been banished from our testing system. |
| 11:44 |
Dyrcona |
jboyer-isl++ |
| 11:44 |
rfrasur |
I'd like to go exclusively to email receipts that that's not likely to happen in the near future...not here at least. |
| 11:44 |
jeff |
i have put thought into printing from a web browser to a receipt printer on windows/linux/macos, but not yet put as much thought into printing to a receipt printer from a chromebook. |
| 11:44 |
dbwells |
jboyer-isl: good to hear, thanks for reporting back |
| 11:45 |
jboyer-isl |
jeff: Set up G Cloud Print through Chrome on a "real" desktop behind the circ desk? |
| 11:46 |
jeff |
jboyer-isl: most printing from a chromebook involves google cloud print, yes. |
| 11:46 |
jboyer-isl |
The only caveat is that the same G account has to be signed in to the chromebooks. |
| 11:46 |
jeff |
jboyer-isl: you can share, at least in a domain environment. |
| 11:46 |
rfrasur |
So, something else I've been thinking about - how...when there is a web client...using a tablet/handheld/whatever to input a barcode to EG using the camera |
| 11:46 |
jeff |
(google apps domain) |
| 11:46 |
jboyer-isl |
Ah, I never set up any chromebooks in JCPLS |
| 11:46 |
jeff |
rfrasur: i don't recommend it for high volume scanning. for occasional use, maybe. |
| 11:46 |
jboyer-isl |
bah. 's GApps domain. |
| 11:46 |
|
mcooper joined #evergreen |
| 11:47 |
jeff |
rfrasur: bluetooth barcode scanner is a better option for higher volume. |
| 11:47 |
rfrasur |
I was thinking POS in the stacks. Roving circulation. |
| 11:47 |
jeff |
rfrasur: but the camera can still be useful for things like registering someone for a library card by scanning the back of their drivers license. |
| 11:47 |
rfrasur |
Have thought about that as well (and looked at them). |
| 11:47 |
rfrasur |
jeff: right |
| 11:47 |
jboyer-isl |
rfrasur: Dropping proper coin will net you a device running iOS/Android with a built-in scanner. |
| 11:47 |
jeff |
jboyer-isl: another option is network receipt printers. |
| 11:48 |
jeff |
i really want to supplement the patron self-registration kiosk in our library with a barcode scanner. |
| 11:49 |
* rfrasur |
hasn't enough coin to drop properly. Not here. Though the MVF project was a good start for EG-IN |
| 11:49 |
jboyer-isl |
For self-reg? So for drivers licenses, or ? |
| 11:50 |
jboyer-isl |
I suppose depending on how much info MI puts in a DL barcode, you could bring pre-reg time down to near-nil. That would be neat. |
| 11:59 |
dbs |
ctx.opac_root Y U NO B "kpac"?!?!?! |
| 12:01 |
dbs |
guess I can do ctx.kpac_root ? ctx.kpac_root : ctx.opac_root. |
| 12:01 |
dbs |
BORING |
| 12:03 |
senator |
heh |
| 12:06 |
jeff |
jboyer-isl: yeah, it would be down to "give us your email address" |
| 12:06 |
jeff |
jboyer-isl: most states have the new drivers license PDF-417 barcode on the back. That includes darn near everything. |
| 12:06 |
|
jbfink joined #evergreen |
| 12:07 |
jeff |
jboyer-isl: and since we enable drivers license to be used as your library card number, that would be set also. |
| 12:07 |
jeff |
jboyer-isl: i'd like to make some of our outreach / sign up for a library card things done with just scanning the license, and the end result being "great, you're all set, we'll let you know when that book is in, your license now works as your library card" |
| 12:08 |
jboyer-isl |
I didn't know you did that. Seems like a good way to actually keep patrons from sharing their cards (and then complaining "I didn't check that out! I'm not paying that!") |
| 12:08 |
rfrasur |
jeff++ |
| 12:08 |
jeff |
or "great, we found you in our system, your address is all up to date now, come see us soon!" |
| 12:08 |
rfrasur |
(librarianship without ducttape) |
| 12:08 |
jeff |
the standard new barcode on the back of the license lacks email and phone number, but that's about it. |
| 12:09 |
jboyer-isl |
Slick. |
| 12:09 |
jeff |
and it's a versioned, common format across all states. |
| 12:09 |
jeff |
(participating states, which might be all) |
| 12:09 |
rfrasur |
it's the same for state IDs, I'm assuming? |
| 12:10 |
jeff |
suspect so. their original barcodes are the same, though the number of digits used to be slightly different (they have since standardized) |
| 12:11 |
rfrasur |
could be quite awesome. |
| 12:12 |
jeff |
doesn't work for everyone. |
| 12:12 |
rfrasur |
No, but it could work for enough people. Of course, we deal with people often who haven't changed their license for this or that reason yet. |
| 12:16 |
* dbs |
ponders checking REFERER for populating breadcrumb trail as an alternative to relying solely on GET params |
| 12:17 |
dbs |
Yes, some privacy plugins would block it, but sure would make for prettier URLs. |
| 12:19 |
* tsbere |
hates that header |
| 12:22 |
dbs |
come on, tsbere, how do you really feel? Don't be so shy! |
| 12:23 |
tsbere |
dbs: I hate that header. I have my reasons. Your pondered use does not actually factor into the hate, but the hate is still there. |
| 12:25 |
csharp |
ldwhalen++ berick++ |
| 12:25 |
* csharp |
loves reading well-reasoned arguments |
| 12:25 |
dbs |
tsbere: I hate it too, say when it's used for authentication purposes. Terrible |
| 12:28 |
csharp |
https://www.youtube.com/watch?v=zLjhLaD9Zjw |
| 12:29 |
tsbere |
dbs: I have run into websites where if you don't pass the referer header anywhere other than the homepage then they force-redirect you to the homepage. Which not only screws up shortcuts but also makes them impossible to use when the header is disabled. :( |
| 12:42 |
|
tsbere joined #evergreen |
| 12:44 |
|
j_scott joined #evergreen |
| 12:47 |
Dyrcona |
Only way that I've used REFERER is to attempt to provide a modicum of security on an email CGI program and to prevent "theft" of images. However, both attempts proved to be laughable. |
| 12:48 |
|
jbfink joined #evergreen |
| 12:53 |
paxed |
about the only use i can see for it is to generate a "go back" link... |
| 12:54 |
Dyrcona |
paxed: I log it. It can be interesting to see how some users got to your site. |
| 12:55 |
Dyrcona |
Of course, I check my apache logs almost never. |
| 12:55 |
bshum |
dbs++ #wrestling with KPAC |
| 13:01 |
dbs |
paxed: yep, that's what I was thinking of using it for |
| 13:13 |
|
RoganH joined #evergreen |
| 13:14 |
|
jbfink joined #evergreen |
| 13:21 |
dbs |
bshum: will you forgive me if I walk away from KPAC CSS? |
| 13:21 |
bshum |
dbs: Yes I would forgive you. |
| 13:22 |
dbs |
Soooooooo much CSS |
| 13:22 |
dbs |
Soooooooo much fixed-widthedness |
| 13:22 |
bshum |
KPAC is special. |
| 13:22 |
|
jwoodard joined #evergreen |
| 13:23 |
jeff |
KPACtsman |
| 13:26 |
* jeff |
brushes the dust off of bug 608308 |
| 13:26 |
pinesol_green |
Launchpad bug 608308 in Evergreen "receipt template macros should have access to address, phone numbers" (affected: 4, heat: 20) [Wishlist,In progress] https://launchpad.net/bugs/608308 - Assigned to Jeff Godin (jgodin) |
| 13:26 |
* dbs |
wonders which one of the many possible addresses jeff will provide access to :) |
| 13:27 |
dbs |
physical? mailing? billing? other randomly labelled entries? |
| 13:27 |
jeff |
i liked galen's suggested direction of "* library address (for each type, possibly with a set of convenience macros to default to the library mailing address if that's the only type set up)" |
| 13:29 |
dbs |
Of course nothing forces there to even be a mailing address; could be labelled "Postal" :/ |
| 13:29 |
jeff |
and forget the unbounded ones, i suppose. |
| 13:29 |
jeff |
well, aou defines ill_address, holds_address, mailing_address, and billing_address |
| 13:30 |
jeff |
and have i mentioned that mailing_address and billing_address make no sense to me? :P |
| 13:30 |
jeff |
to me, mailing == billing and physical is distinct. |
| 13:30 |
dbs |
Oh right, forgot about the constraints at actor.org_unit |
| 13:30 |
dbs |
I guess billing could go to a parent OU |
| 13:30 |
gmcharlt |
jeff: money to the central branch, complaints to the locals ;) |
| 13:30 |
jeff |
but i guess billing = physical in evergreen, unless you've adopted another convention. |
| 13:31 |
* dbs |
had to deal with some of this for the library info page, might make sense for me to revisit it once jeff sorts out best practices :) |
| 13:31 |
jeff |
hah |
| 13:31 |
|
sseng joined #evergreen |
| 13:32 |
dbs |
IIRC I went with mailing==physical because that seemed most likely of interest to patrons (who would either want to get there, or contact them) |
| 13:33 |
rfrasur |
billing isn't the same as physical...at least not here. We have people that have a physical address but pick up their mail at the post office. |
| 13:34 |
* jeff |
nods |
| 13:34 |
rfrasur |
billing = mailing |
| 13:34 |
rfrasur |
(heck, they might even have a mailbox at their house and STILL use a PO box) |
| 13:34 |
jeff |
rfrasur: so given options for "Mailing" and "Billing" in the user editor, which do you pick for the "physical address, but we do not receive mail at this address" address? |
| 13:34 |
dbs |
rfrasur: right; might be different given that we're talking about library addresses though |
| 13:35 |
rfrasur |
dbs, not necessarily. We have libs that function similarly. lil tiny ones. |
| 13:35 |
rfrasur |
jeff: neither of those would apply. |
| 13:35 |
jeff |
and yes, i think the default connotations are slightly different for actor.org_address vs actor.usr_address, though they suffer from similar confusion. |
| 13:36 |
dbs |
rfrasur: ah, we need extreme_outlier_address then :) |
| 13:36 |
rfrasur |
dbs: or not_quite_in_the_twenty_first_century_address |
| 13:37 |
rfrasur |
or are_you_serious_address |
| 13:37 |
dbs |
we_would_really_prefer_you_use_email_address |
| 13:37 |
jeff |
rfrasur: if a patron visits your library today and signs up for an account, and they live at 123 Rural Ln but can only receive mail at PO Box 123, do you enter both addresses in Evergreen, and which address gets set as "Billing" and which as "Mailing"? |
| 13:37 |
rfrasur |
dbs++ |
| 13:37 |
gmcharlt |
this_is_where_the_collection_agency_will_show_up_if_you_are_too_slow_to_return_books_address |
| 13:37 |
rfrasur |
Jeff, no. We enter the PO box in both places and just use the physical address to check their residency. |
| 13:37 |
jeff |
(and I realize that the PO Box might get set to both Billing AND Mailing, and the 123 Rural Ln address left as an address but with neither radio box selected. |
| 13:38 |
gmcharlt |
(forutnately for us, Pg won't let us use a column name that's so long) |
| 13:38 |
jeff |
rfrasur: so there's no note of the physical residence on their account anywhere? |
| 13:39 |
jeff |
this just brings to mind UPDATE actor.usr SET email = null WHERE email = 'second number is sister's mom'; |
| 13:39 |
rfrasur |
well, I should clarify. That's what I would do. But I rarely do patron registrations anymore (probably for the reason that I can't stand that ambiguity). We also still have paper records. |
| 13:39 |
dbs |
sister''s mom |
| 13:39 |
jeff |
dbs: thanks :-) |
| 13:39 |
rfrasur |
AND our lib doesn't use collections. |
| 13:39 |
jeff |
still very pleased that we have a patron email regex in place, and that staff are both happy and thankful for it. |
| 13:40 |
jeff |
Dyrcona, tsbere: with your 1000 item limit, what are normal daily fines and what is the per-circ max fine? |
| 13:41 |
Dyrcona |
jeff: It varies. Depending on how you count "charging fines" roughly half of our members do not charge overdue fines. |
| 13:41 |
rfrasur |
jeff: actually...here's what we do if that's the case. We add a new address and deselect both radio buttons and type in PHYSICAL |
| 13:41 |
rfrasur |
(I can't only imagine the joy that behavior bring the DB) |
| 13:41 |
rfrasur |
s/can't/can |
| 13:42 |
dbs |
jeff: much better than sister-mom |
| 13:43 |
Dyrcona |
jeff: We do have a PATRON_EXCEEDS_FINES of $10.00 before a patron is cut off with PATRON_EXCEEDS_OVERDUE_COUNT of 15. |
| 13:43 |
Dyrcona |
We can actually get the members to agree on some things. |
| 13:44 |
rfrasur |
Dyrcona: just two things though, right? |
| 13:44 |
jeff |
if we had a 1000 item limit, it would still take between ten and 45 days to reach max fines on all items, but that grand total of $6,750 to $10,000 in overdue fines would be impressive. |
| 13:47 |
Dyrcona |
rfrasur: If you include the 1,000 checkout limit, that's three things. |
| 13:47 |
Dyrcona |
:) |
| 13:48 |
jeff |
rfrasur: that sounds completely sane. the PO Box is there with both Mailing and Billing selected, and the physical address is there with neither Mailing or Billing selected, and has a human-readable "physical" in the Type field. :-) |
| 13:48 |
rfrasur |
oh yeah! such a sense of community. Makes my consortial heart warm. |
| 13:48 |
rfrasur |
jeff: yes |
| 13:48 |
jeff |
the fun part is when you do it one way and another library in your system does it another way, like saying "mailing is the po box and billing is the physical" |
| 13:49 |
jeff |
which is what really makes future disambiguation efforts tricky. |
| 13:49 |
Dyrcona |
We have some members who are interested in seasonal addresses. |
| 13:49 |
rfrasur |
yes, I was just thinking what a mess that could become...is. Thinking about our DB w/ 104 libraries in it? It IS a mess. |
| 13:50 |
Dyrcona |
Many of our swankier communities have a number of snow birds who have a place up here and a place in Florida. |
| 13:50 |
rfrasur |
Dyrcona: I could see that. We have vacationers in some of our districts who are parttime residents |
| 13:50 |
jeff |
bugs like bug 1068646, where one person sees "In the attached patch all the instances of "Physical" are replaced with "Billing" in address type labels." and says "hooray", while another says "what? no! that's WRONG!" |
| 13:50 |
pinesol_green |
Launchpad bug 1068646 in Evergreen "Improve Consistency of terms in registration and information sheet" (affected: 4, heat: 24) [Wishlist,Triaged] https://launchpad.net/bugs/1068646 |
| 13:51 |
Dyrcona |
jeff: People (librarians in particular) get hung up on language and the meanings of words. |
| 13:51 |
rfrasur |
we DO. |
| 13:51 |
Dyrcona |
It's just a label. |
| 13:51 |
* rfrasur |
LOVES words. |
| 13:52 |
|
timf joined #evergreen |
| 13:52 |
jeff |
"Patron had an invalid email address: lives at t.c. address from june thru aug" |
| 13:52 |
jeff |
so much bad data. baby steps toward less bad data. |
| 13:52 |
jeff |
(and more less-bad data) |
| 13:55 |
Dyrcona |
In my experience, all data is bad until proven otherwise, and that is a very high burden of proof. |
| 13:55 |
jeff |
"Patron had an invalid email address: po box XXXX ann arbor mi YYYYY 1/2 yr" |
| 13:56 |
rfrasur |
It's fairly amazing that we're able to do the things we do with the data we have. |
| 13:56 |
rfrasur |
shortcuts and placeholders |
| 13:57 |
dbs |
bshum: well, I dove into kpac css anyway. just enough to make the library info page not look terrible. |
| 13:59 |
jeff |
three patrons had item barcodes for email addresses. :-) |
| 13:59 |
Dyrcona |
Oh, you should have seen the "shortcuts and placeholders" that came up during our migration. |
| 13:59 |
rfrasur |
Hah! Only three? How about UPC codes for item barcodes? |
| 14:00 |
Dyrcona |
Phone numbers that read something like "the number in the field above is the drivers license" or similar. |
| 14:01 |
Dyrcona |
That's the beauty of a system that stores phone numbers in a free text field and does no validation on the input. |
| 14:02 |
rfrasur |
And do any of your libraries do self-registration for patrons? |
| 14:02 |
jeff |
we do. |
| 14:03 |
rfrasur |
jeff: are there validation thingies for each of the fields to make sure they're actually correct format at least? |
| 14:03 |
rfrasur |
(pardon, I know you guys were talking about that all earlier) |
| 14:05 |
jeff |
rfrasur: some, but not all fields. some that are not validated at the self-reg side are validated when staff go to turn the pending patron into a real patron: https://tadl.org/selfreg |
| 14:05 |
jeff |
er. |
| 14:05 |
jeff |
https://tadl.org/newuser |
| 14:05 |
jeff |
that first one would be a 404, because my brain made it up just now. :P |
| 14:06 |
rfrasur |
I gotcha. Nice spontaneous, fake URL creation also. |
| 14:06 |
RoganH |
rfrasur: upc codes for barcodes? ummm... wtf? |
| 14:06 |
rfrasur |
And I want to steal ALL of TADL's stuff and appropriate it for my library....staff included. |
| 14:07 |
rfrasur |
RoganH: yes. Item barcodes. |
| 14:07 |
rfrasur |
one reason that I now swear using the f-word on a regular basis. |
| 14:08 |
* rfrasur |
didn't say such things in the past. |
| 14:08 |
RoganH |
Back when SCLENDS was more active in doing migrations when I had a bad day and felt we'd had a big problem I could always count on horror stories in IRC to make me say "wow, it's not that bad." |
| 14:08 |
jeff |
it was common for us in days when we used offline mode frequently to have staff attempt to check patrons out to other patrons. :-) |
| 14:09 |
rfrasur |
jeff: yes, that has also happened although not recently. |
| 14:09 |
rfrasur |
RoganH: well, that's not even a migration issue. That was a cataloger not paying attention. |
| 14:10 |
rfrasur |
"oh look...it has a lot of little vertical lines. I'll just scan that." |
| 14:11 |
RoganH |
rfrasur: There is a cure for that. The high voltage ones aren't legal in SC but they might be in your state. |
| 14:11 |
jeff |
rfrasur: feel free to try and submit a new user -- it won't hurt anything. |
| 14:11 |
jeff |
https://www.tadl.org/tadleg/newuser/thankyou/ is the result page after success |
| 14:11 |
rfrasur |
jeff: yes! I didn't want to touch it if it was going to tick someone off. |
| 14:11 |
jeff |
mostly that form is filled out by people in-building. we've eliminated the paper forms. |
| 14:12 |
RoganH |
jeff: eliminate paper? Wow, what a radical concept. Seriously though, I'm jealous. I've been trying to convince others of that for years. |
| 14:12 |
rfrasur |
RoganH: The cure I've used has been somewhat less effective than electricity but involved conversations that inspired fear and mentioned firing. |
| 14:13 |
RoganH |
rfrasur: yeah, but the twitching brightens up my day. And when they start to relax you can hit the button again. |
| 14:13 |
rfrasur |
If ze cataloger cannot catalog, why for shouldst we keep ze cataloger. |
| 14:13 |
jeff |
i've noticed that we have far more patrons with all-lowercase names now, but far fewer instances of "invalid email address that LOOKS like someone either mis-heard or mis-read from paper" |
| 14:13 |
jeff |
(purely anecdotal, that.) |
| 14:13 |
rfrasur |
RoganH++ |
| 14:13 |
rfrasur |
jeff: Are they registering on tablets? |
| 14:14 |
jeff |
no, we just have a kiosk (same hardware as our catalog terminals, just a different idle/screensaver message) near the welcome desk, or they do it from any catalog terminal in the building, or from home, etc, etc |
| 14:15 |
jeff |
i mean, they could use their tablet, but we don't supply tablets for registration. |
| 14:15 |
rfrasur |
I was thinking that maybe they were registering at home and then coming in to complete the process. The kiosk is a little more realistic for most people. |
| 14:18 |
jeff |
some register from home, most via kiosk. either way, the next step is to talk to a staff member at the welcome desk, where they retrieve the pending patron in the evergreen staff client, scan a library card barcode, fill in some additional bits like statistical categories, and *poof*, you're a real patron! |
| 14:18 |
rfrasur |
I like it. |
| 14:18 |
* rfrasur |
would love to be paperless. |
| 14:18 |
jeff |
we'd still like to get back to the concept of patrons being "real" in the system before they come in, and being able to place holds and such so that the first time they visit is when we tell them we have that thing they wanted... |
| 14:18 |
rfrasur |
Have I mentioned that we still have a typewriter that one employee actually uses? |
| 14:19 |
rfrasur |
Yeah, there'd need to be a pretty mature residency verifier though for that. |
| 14:20 |
jeff |
we'd require the usual proof before they check items out |
| 14:20 |
jeff |
but not before placing holds |
| 14:20 |
rfrasur |
OR a true state-wide library system. |
| 14:21 |
rfrasur |
That makes sense. And then have a time limit for them to "convert" their account or have holds removed? |
| 14:21 |
jeff |
more likely we'd let the holds fill, but would cut off electronic resource access after a certain time if they don't come in to bless their account. |
| 14:23 |
rfrasur |
I think there'd still need to be a time limit for the holds otherwise it'd mess with other people wanting to hold some items. Unless I'm not understanding something (completely possible). |
| 14:24 |
jeff |
well, once the holds became available they'd only wait on the shelf so long before the holds were cancelled and the items went to the next patron who had a hold, etc. |
| 14:24 |
rfrasur |
I'd love for our patrons to be able to sign up remotely and have access to digital collections. My fear is, however, that the people we'd want to have access that way because of being housebound for whatever reason are also the people who have lower access to technology (for a variety of reasons). |
| 14:34 |
Dyrcona |
Does it matter if I run pg_prove from somewhere other than database server? |
| 14:34 |
Dyrcona |
Also, should my version of pg_prove be the same as pgtap on the server? |
| 14:35 |
* dbs |
has only run pg_prove on an all-in-one server install |
| 14:36 |
jeff |
pg_prove seems capable of running from another host. it uses psql to connect. |
| 14:36 |
Dyrcona |
All the tests are failing, and I don't think they should. |
| 14:37 |
Dyrcona |
I'll play with the options a bit. |
| 14:37 |
Dyrcona |
Parse errors: No plan found in TAP output |
| 14:37 |
Dyrcona |
Leads to believe I should get a more recent pgtap? |
| 14:38 |
dbs |
Which tests? What command are you running? |
| 14:39 |
Dyrcona |
pg_prove t # from Evergreen/Open-ILS/src/sql/Pg |
| 14:40 |
Dyrcona |
Ah, wait. Maybe pgtap is not actually loaded in the database I'm testing against. |
| 14:42 |
|
stevenyvr joined #evergreen |
| 14:42 |
Dyrcona |
I'll have to bug tsbere when he gets back to his desk. |
| 14:44 |
jeff |
Dyrcona: first error in the output is usually more helpful than the errors in the Test Summary Report |
| 14:44 |
|
bibliophylum joined #evergreen |
| 14:45 |
Dyrcona |
jeff: Yeah. select plan(2) says plan() doesn't exist. I'm trying to figure out the parameters that I need to use psql on the server itself to load pgtap in my database. |
| 14:45 |
jeff |
"Parse errors: No plan found in TAP output" can show for "i can't connect to postgresql", "there wasn't a database with that name", lack of plan() function, etc. |
| 14:45 |
csharp |
okay - here's an interesting bug... if a 2.3 copy/item cataloging template had "Floating = False" applied, it creates an exception in 2.5.1 because that field is now an integer, not a boolean |
| 14:45 |
jeff |
yup. lack of plan() says "no pgtap installed in target db" to me. :-) |
| 14:46 |
csharp |
"Floating = False" equates to "0" which is not a valid ID for a floating group |
| 14:46 |
jeff |
csharp: reminds me of when circ modifiers changed case. |
| 14:46 |
csharp |
jeff: me too actually |
| 14:47 |
bshum |
csharp: Yep, that sort of randomness happened to us too, when the new floating group development came into being. |
| 14:47 |
bshum |
Parsing the copy template JSONs made me grumpy. |
| 14:47 |
jeff |
csharp: delete and re-create templates, export, delete, edit, re-load templates, or get creative with SQL and json functions... not sure if there are other more useful options. |
| 14:47 |
csharp |
this is not nearly as devastating to our catalogers though, since we haven't implemented floating and most catalogers leave it unset |
| 14:47 |
jeff |
actually, you could PROBABLY be okay with regexp_replace |
| 14:47 |
|
finnx joined #evergreen |
| 14:48 |
csharp |
jeff: interesting - you're right - I'll look into a batch change via SQL |
| 14:48 |
jeff |
using regexp_replace to update the templates in actor.usr_setting probably wouldn't be too painful. |
| 14:49 |
Dyrcona |
tsbere++ |
| 14:49 |
jeff |
you could even check your work (slightly) with is_json() before committing the changes. :-) |
| 14:51 |
Dyrcona |
So, turns out psql on the database server is not allowed to talk to the database server. |
| 14:51 |
gmcharlt |
super_security++ |
| 14:52 |
jeff |
wait, that resulted in no error when connecting to the db, but only an error when it came time to make use of plan()? |
| 14:52 |
eeevil |
"but what if someone gains access to a shell on the system?" oh .. wait... |
| 14:52 |
tsbere |
Dyrcona: No, it is allowed. If you talk TCPIP. You were talking socket. :P |
| 14:52 |
Dyrcona |
jeff: No, I was running pgtap from another machine remotely, but tried to install pgtap from the database server. |
| 14:52 |
jeff |
oh. got it. |
| 14:53 |
jeff |
"You can't test in here! This is the database server!" |
| 14:53 |
Dyrcona |
Ah, well. It's fixed with 'create extension pgtap schema public;' from the remote machine. |
| 14:53 |
Dyrcona |
:) |
| 14:53 |
Dyrcona |
Strangelove++ |
| 14:53 |
Dyrcona |
jeff++ |
| 14:53 |
|
ibogachenko joined #evergreen |
| 14:54 |
Dyrcona |
Oh, and now that pgtap is installed in the target database, all of the tests pass. |
| 14:55 |
jeff |
tests++ |
| 14:56 |
* Dyrcona |
finally gets around to writing pgtap tests. |
| 14:56 |
tsbere |
and due to adding a similar statement to our copy of the database create script used for restoring backups for various purposes we don't have to worry about that in the future :D |
| 15:00 |
Dyrcona |
Should I be concerned if the unbreak new encode test fails if I don't have the new version of Encode.pm? |
| 15:02 |
|
jbfink joined #evergreen |
| 15:06 |
dbs |
Dyrcona: maybe |
| 15:07 |
csharp |
I see that libmarc-xml-perl-1.0.2 has made it to Ubuntu, but the deb is for the upcoming trusty release |
| 15:07 |
csharp |
but looks like the deb will probably work on earlier versions |
| 15:08 |
csharp |
http://packages.ubuntu.com/trusty/libmarc-xml-perl for those following along at home |
| 15:09 |
pastebot |
"Dyrcona" at 64.57.241.14 pasted "pg_prove t/regress output" (18 lines) at http://paste.evergreen-ils.org/59 |
| 15:10 |
* Dyrcona |
checks our CPAN mirror. |
| 15:11 |
Dyrcona |
And our CPAN mirror has 1.0.2! |
| 15:11 |
gmcharlt |
if you don't mind mixing-and-matching package repositories, but are running Debian and would prefer a package over CPAN, 1.0.2 is available at http://debian.koha-community.org/ |
| 15:11 |
gmcharlt |
or you can grab it from sid |
| 15:12 |
* Dyrcona |
wishes he had more time to figure out packaging to make his own PPA or whatever for Ubuntu, or join MOTU even. |
| 15:24 |
dbs |
Dyrcona: hmm. well, I confirmed that the test still passes on new Encode, but sure is not good that it fails on old Encode.pm |
| 15:27 |
* dbs |
wondered for a moment if MARC::Charset might be involved but I have 1.35 here |
| 15:28 |
Dyrcona |
Ditto. |
| 15:31 |
Dyrcona |
I can't upgrade Encode.pm on this server because it might cause our training database problems. |
| 15:31 |
Dyrcona |
Our training Evergreen doesn't have the commit with the fix. |
| 15:33 |
dbwells |
Dyrcona: Is this a totally fresh DB? Anything which might cause a change to the MARC via triggers, such as varying config.internal_flag settings, or different org unit codes, could potentially cause this test to fail, as it requires the record be exactly as expected. |
| 15:34 |
Dyrcona |
dbwells: It has a copy of our production data in it, so that must be it. We're using id for tcn. |
| 15:42 |
|
rfrasur joined #evergreen |
| 15:45 |
dbwells |
I could be wrong, but I think that is the default. I wonder if just changing your top OU code to 'CONS' would let the test pass, since that gets inserted by maintaing_control_numbers? |
| 15:46 |
Dyrcona |
Heh. That's Ok. I'll just accept that the test fails on my setup. :) |
| 15:46 |
dbwells |
But you've got us all worried! ;) |
| 15:47 |
* dbs |
was going to ask if it was a stock db as well |
| 15:47 |
dbs |
dbwells++ |
| 15:48 |
Dyrcona |
Suppose I could alter the test before running it to do the update... |
| 15:48 |
|
jtaylorats joined #evergreen |
| 15:57 |
dbs |
I suppose we could make the test more resilient by regex_replace'ing the 003/035/901 fields out before running the md5sum |
| 15:57 |
dbs |
001 too I guess |
| 15:58 |
Dyrcona |
If it works on a brand new database, then I don't suppose it should change. |
| 15:59 |
Dyrcona |
Maybe some notes to the effect that it will fail in a database that already has been configured. |
| 16:13 |
|
jtaylorats joined #evergreen |
| 16:16 |
|
jwoodard joined #evergreen |
| 16:29 |
jeff |
hrm. incoming request that makes me think about merging reports and searching. |
| 16:31 |
Dyrcona |
On pgtap tests: I guess those that go with upgrade scripts should have XXXX. in the name where the version would go, looking at the examples in Open-ILS/src/sql/Pg/t. |
| 16:33 |
dbs |
Eh. My kneejerk reaction is that I don't think they should be tied to schema upgrades; just name what they're testing |
| 16:35 |
eeevil |
dbs: I though there was some logic that used the numbers? maybe not. If not, I'd say tests generated by a schema change /could/ (but needn't necessarily) carry the same number, and tests that just get added shouldn't have a number at all |
| 16:36 |
gmcharlt |
if we include any numbers at all in the filename, LP numbers would be the most useful in the long run |
| 16:36 |
gmcharlt |
at leat for regression test |
| 16:36 |
gmcharlt |
s |
| 16:37 |
dbs |
eeevil: no logic that I'm aware of |
| 16:37 |
dbs |
gmcharlt: yeah, lp numbers make sense for regress/ IMO |
| 16:37 |
phasefx |
I did one test for an upgrade script as an example/experiment, but I'm not sure I'd like to continue that practice |
| 16:37 |
Dyrcona |
Ok, sounds good to me. |
| 16:37 |
dbs |
"that I'm aware of" is a great big qualification :) |
| 16:37 |
Dyrcona |
After looking again, there is only that has an upgrade version number in the name. |
| 16:38 |
Dyrcona |
I suppose we don't want tests to check that a particular version exists in config.upgrade_log? |
| 16:38 |
phasefx |
part of me would like to see us use the make-pgtap script to encode the entire schema, and then start keeping that up-to-date |
| 16:39 |
|
jbfink joined #evergreen |
| 16:40 |
eeevil |
gmcharlt / dbs: that's fair. LP would be good, I agree |
| 16:40 |
eeevil |
Dyrcona: I was actually imagining that /that/ might be (partially) there, thus the numbering that senator did for his test on my recent change (sorry for the git churn on that, btw, all) |
| 16:40 |
gmcharlt |
eeevil: to be clear, I don't care much *how* the LP gets cited, but think that it should |
| 16:41 |
gmcharlt |
test names would be another way to do it, e.g. |
| 16:43 |
phasefx |
re: make-pgtap, the thought is that if you create an upgrade script that changes the schema, you'd also change a base set of tests that tracks the schema. How useful that would be for everyone, I'm not sure. Someone doing an upgrade could run the tests afterward to make sure it went well. For developers, eventually we might have automation that compares the results of upgrade scripts to |
| 16:43 |
phasefx |
pristine database installs (via those tests) |
| 16:43 |
|
akilsdonk joined #evergreen |
| 16:47 |
eeevil |
phasefx: not if I have /my/ way ;) |
| 16:48 |
eeevil |
(no more moving-baseline) |
| 16:48 |
eeevil |
which I've STILL not emailed about. I'm buying tuits if anyone is selling |
| 16:49 |
* phasefx |
welcomes our new non-duplicated-upgrade-script-overlords |
| 16:50 |
gmcharlt |
eeevil: if you find a source of tuits.... |
| 16:51 |
eeevil |
gmcharlt: I'll add you to the list, sir |
| 16:52 |
gmcharlt |
eeevil++ |
| 16:53 |
* senator |
buys futures in tuit mines |
| 17:07 |
|
keynote2k joined #evergreen |
| 17:08 |
|
jbfink joined #evergreen |
| 17:19 |
|
mmorgan left #evergreen |
| 17:39 |
|
stevenyvr joined #evergreen |
| 17:43 |
|
dcook joined #evergreen |
| 18:49 |
|
sseng joined #evergreen |
| 20:01 |
|
snowball joined #evergreen |
| 20:03 |
|
rjackson_isl joined #evergreen |
| 20:04 |
|
artunit joined #evergreen |
| 20:28 |
|
dac joined #evergreen |
| 20:32 |
|
artunit_ joined #evergreen |
| 20:38 |
|
rsinger joined #evergreen |
| 22:21 |
|
zerick joined #evergreen |
| 22:31 |
* jeff |
plays with address alerts |
| 22:48 |
|
mrpeters joined #evergreen |
