| Time |
Nick |
Message |
| 00:06 |
|
BigRig joined #evergreen |
| 02:27 |
|
tfaile joined #evergreen |
| 02:27 |
|
Callender joined #evergreen |
| 02:27 |
|
BigRig joined #evergreen |
| 02:28 |
|
phasefx joined #evergreen |
| 02:28 |
|
RBecker joined #evergreen |
| 02:30 |
|
mtate joined #evergreen |
| 03:28 |
|
tfaile_ joined #evergreen |
| 03:31 |
|
tater joined #evergreen |
| 05:00 |
|
b_bonner joined #evergreen |
| 05:00 |
|
mtcarlson_away joined #evergreen |
| 05:20 |
pinesol_green |
Incoming from qatests: Test Success - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 05:24 |
|
TSU-evergreen joined #evergreen |
| 05:25 |
TSU-evergreen |
hii all |
| 05:28 |
TSU-evergreen |
can somebody help me ЫЫ |
| 05:28 |
TSU-evergreen |
?? |
| 05:54 |
|
b_bonner_ joined #evergreen |
| 05:54 |
|
mtcarlson_away joined #evergreen |
| 06:42 |
|
ktomita joined #evergreen |
| 06:44 |
|
timlaptop joined #evergreen |
| 06:47 |
TSU-evergreen |
can somebody help meЫ |
| 06:48 |
TSU-evergreen |
? |
| 07:47 |
|
kmlussier joined #evergreen |
| 07:50 |
kmlussier |
TSU-evergreen: The channel is most active from 9 a.m. to 5 p.m. EDT, and you're not likely to get much response in the early morning hours. I suggest just asking your question. When somebody arrives who can answer it, they'll send a response. |
| 07:50 |
kmlussier |
You can also try sending the question to one of the mailing lists. |
| 07:55 |
|
rjackson-isl joined #evergreen |
| 07:58 |
kmlussier |
@coffee |
| 07:58 |
* pinesol_green |
brews and pours a cup of El Salvador La Montana Pacamara, and sends it sliding down the bar to kmlussier |
| 08:04 |
|
akilsdonk joined #evergreen |
| 08:21 |
|
collum joined #evergreen |
| 08:31 |
|
Shae joined #evergreen |
| 08:35 |
|
jboyer-isl joined #evergreen |
| 08:37 |
|
Dyrcona joined #evergreen |
| 08:43 |
|
mrpeters joined #evergreen |
| 08:45 |
dbs |
maybe we can borrow the @welcome plugin from zoia as well (it recognizes new visitors to the channel and sends them a quick summary message like kmlussier did) |
| 08:50 |
|
mmorgan joined #evergreen |
| 08:59 |
kmlussier |
dbs: This one?: https://github.com/code4lib/supybot-plugins/tree/master/plugins/Greeter |
| 08:59 |
DPearl |
Question: I'm looking at a change in /usr/local/share/perl/5.10.1/OpenILS/Application/Circ/Circulate.pm. What do I need to restart in order to test the changes in that file? |
| 09:00 |
jeff |
at a minimum, the open-ils.circ service. |
| 09:01 |
jeff |
that might be it. |
| 09:01 |
dbs |
kmlussier: that's it! |
| 09:01 |
DPearl |
jeff: Thanks! |
| 09:02 |
jeff |
in most cases when testing even small changes, i do the work in a local git branch, push that branch to a development server, stop apache and opensrf, then make, make install, start opensrf, start apache. sometimes i also restart memcached or perform a selective removal of keys from memcached. |
| 09:04 |
jeff |
thinking on that a bit, my only real reason for not doing a full memcached restart is usually just that i want to preserve my session -- i should probably either get used to just logging in again, or manually insert my session after a full restart. |
| 09:04 |
jeff |
(of memcached) |
| 09:04 |
jeff |
(or flush) |
| 09:05 |
jeff |
mostly because a partial deletion of keys and their values requires either that i know the exact key, or that i use memcdump and grep, and memcdump is not guaranteed to give you every key in every situation. |
| 09:05 |
tsbere |
jeff: I have aliases that do the entire install/reinstall process for me on my dev machine, and I use the automatic login options on the staff client. The only place I normally log into my dev machine is in the catalog, or if I want a different user than one of the normal three I use in the staff client. :D |
| 09:06 |
Dyrcona |
What tsbere said, plus I only do the makes and restarts when necessary. |
| 09:06 |
* tsbere |
even lets the browser remember the passwords for three "patron" accounts, though, so even the catalog isn't a big deal for logging in |
| 09:06 |
Dyrcona |
If I'm messing with tt2 fles or server side client files, I just copy them in place and clear the cache in the staff client or browser. |
| 09:07 |
* jeff |
nods |
| 09:07 |
jeff |
templates i often test without restarting, just cache-clearing |
| 09:07 |
Dyrcona |
DPearl: You'll want to restart open-ils.circ. Depends on your version of OpenSRF how you do that. |
| 09:07 |
jeff |
i wanted to get away from editing a perllib file in place on the dev system. |
| 09:08 |
Dyrcona |
I use git for this stuff definitely. |
| 09:09 |
Dyrcona |
I even have bare repos on my dev server that I push to from my laptop. |
| 09:09 |
Dyrcona |
I then clone those to build from. |
| 09:10 |
jeff |
right, that's what i was trying to describe above. |
| 09:10 |
Dyrcona |
git makes managing customizations, etc. dead simple. |
| 09:10 |
Dyrcona |
jeff++ #yep. I just wanted to say, "Me, too!" |
| 09:10 |
jeff |
i edit code on my laptop, commit to a git branch, push that to a bare repo on the dev instance which is configured as a remote on itself |
| 09:11 |
Dyrcona |
Fun thing: On my laptop I have my bare repos set up to pull from an empty.git repo on the laptop and push to the remotes on the dev machine. |
| 09:11 |
Dyrcona |
This avoids errors when doing a git fetch --all and the remotes on the dev machine are not around. |
| 09:12 |
jeff |
mostly the changes i'll be testing do not involve large schema changes, so i don't have much in place for the database other than "create volume from snapshot, mount, configure postgres to use that path" -- where the snapshot in question is a block-level snapshot of a device with a filesystem containing a restore of our production db from sometime in the last month or so. |
| 09:13 |
Dyrcona |
I usually run upgrade scripts by hand, or for large changes I use a perl script that I wrote. |
| 09:13 |
jeff |
Dyrcona: nice. the local repo i'm usually doing this from isn't somewhere where i typically fetch --all, but that's handy. |
| 09:15 |
Dyrcona |
And this reminds me that I noticed memcached running on a machine where it doesn't have to and I want to disable it. |
| 09:15 |
jeff |
git fetch --some |
| 09:15 |
jeff |
:-) |
| 09:21 |
Dyrcona |
Does anyone have a server running 2.6 besides me at the moment? |
| 09:21 |
_bott_ |
Unique is telling me that their collections calls are erroring out with "does not contain valid XML". I'm wondering if I mistakenly updated a Perl mod. Does anyone know if Precise has a version issue with any XML modules? |
| 09:21 |
Dyrcona |
I ask because I suspect something is wrong with SuperCat feeds in general, but I haven't looked hard enough, yet. |
| 09:21 |
_bott_ |
Dyrcona: test server, running, yes. I haven't touched it in a few weeks though. |
| 09:22 |
Dyrcona |
_bott_: Not that I am aware of, but could be. |
| 09:22 |
_bott_ |
I can't seem to locate my handy xml-rpc test scripts. Gotta go recreate them to test. |
| 09:23 |
Dyrcona |
_bott_: Oh. In that case, yeah, I had trouble with xml-rpc and precise all along, but never really narrowed it down. |
| 09:23 |
jeff |
_bott_: there was a change to XMLRPC calls which made our method names no longer valid. there's a new way of spelling those method names, and Unique knows how to do it, but they might not have enabled it for your system -- I don't think it was as simple as "use these names, they work everywhere" -- I think it was more of a "flag day per system" thing. |
| 09:24 |
Dyrcona |
Plus, what jeff just said. :) |
| 09:24 |
_bott_ |
hrm... their issue seems to be encoding with foreign characters, not method names |
| 09:25 |
Dyrcona |
There were issues with the packaged versions of some xml-rpc perl libs with precise, also, iirc. |
| 09:25 |
jeff |
_bott_: perhaps you have some bibs that were at some point in time double encoded and there isn't enough defense against that in the XMLRPC bits of evergreen |
| 09:25 |
Dyrcona |
_bott_: That's not one I've seen. The problems I remember was it not working at all because of missing or deprecated functions, and things had to be installed from CPAN. |
| 09:26 |
jeff |
_bott_: congrats on your new and interesting failure mode! :-) |
| 09:27 |
_bott_ |
The examples I have are from some old bibs, and way old bills. I hate to waste too much time on it, but off I go... |
| 09:28 |
Dyrcona |
jeff++ |
| 09:32 |
|
yboston joined #evergreen |
| 09:39 |
|
RoganH joined #evergreen |
| 09:48 |
mmorgan |
Puzzling over this. If I make a change in about:config, where does that get stored on the workstation? |
| 09:48 |
|
rjackson_isl joined #evergreen |
| 09:48 |
|
jboyer_isl joined #evergreen |
| 09:52 |
|
kmlussier joined #evergreen |
| 09:58 |
jboyer-isl |
mmorgan: in the prefs.js file for xulrunner. If you're on Windows you can find it by opening Explorer, typing %APPDATA% into the address bar and press enter, then follow OpenILS\open_ils_staff_client\Profiles\(random characters).default\ |
| 09:59 |
jboyer-isl |
Other systems put it in other places, and you may have to open the Roaming folder before seeing OpenILS, depending on your setup. |
| 10:01 |
|
kmlussier joined #evergreen |
| 10:01 |
jeff |
it's stored in a file called prefs.js in the top level of your evergreen client's profile directory. that profile directory can vary based on client OS and evergreen config. by default on a Windows machine, it's going to be in %APPDATA%\OpenILS\open_ils_staff_client\Profiles\[random characters].default\ |
| 10:02 |
jeff |
if you're storing the profile in the app directory, it'll be in a subdir of the application folder, etc. |
| 10:02 |
jeff |
oh, and jboyer-isl answered in the time i was confirming. oops! |
| 10:03 |
jboyer-isl |
\me spends a lot of time there when printers get fussy. |
| 10:03 |
* jeff |
nods |
| 10:03 |
* jboyer-isl |
fails at IRC. |
| 10:03 |
jeff |
jboyer-isl: blame the Windows style path separators. ;-) |
| 10:04 |
jboyer-isl |
And shell escapes! :D |
| 10:07 |
|
montgoc1 joined #evergreen |
| 10:08 |
jeff |
i spent too many seconds trying to figure out why the following wasn't doing what i intended: |
| 10:08 |
jeff |
# Strip any whitespace |
| 10:08 |
jeff |
card_value.gsub!(/s+/, '') |
| 10:10 |
jeff__ |
i spent too many seconds trying to figure out why the following wasn't doing what i intended: |
| 10:10 |
jeff |
er. |
| 10:10 |
jeff__ |
heh. |
| 10:15 |
jboyer-isl |
I'm assuming + -> * fixed your issue, but what language is that? I've never seen function_!_() that I know of. (I guess ! isn't a special character?) |
| 10:20 |
csharp |
_bott_: we're running precise and have UMS querying our servers OK |
| 10:21 |
jeff |
jboyer-isl: nope, i was using /s+/ when i needed /\s+/ :-) |
| 10:21 |
jboyer-isl |
Oh, hey, that does make a difference! Oops. |
| 10:22 |
jeff |
jboyer-isl: and, ruby. gsub is a method call on a string object, and the bang makes it operate in-place. as far as my novice ruby knowledge goes, string.gsub!(/\s+/,'') is just another way of spelling string = string.gsub(/\s+/,'') |
| 10:23 |
jboyer-isl |
I see. Not a bad use of !, letting you know that you're potentially wrecking the variable you're working with. |
| 10:23 |
jboyer-isl |
And saving a fair bit of typging. |
| 10:24 |
jeff |
can't say i prefer it, more of a "using the conventions of the surrounding code" thing. |
| 10:45 |
phasefx |
we don't have any metarecord examples in the test data do we? I grouped by master_record on metabib.metarecord to test |
| 10:47 |
jboyer-isl |
Sigh. on restore (of a 2.5.2-ish db) is anyone seeing this error: COPY failed for table "z3950_index_field_map": ERROR: new row for relation "z3950_index_field_map" violates check constraint "valid_z3950_attr_type" |
| 10:47 |
jboyer-isl |
It's a little disconcerting, as we have plenty of people that do z39.50 searches and there's obviously an entry in the production db being dumped each night. |
| 10:50 |
bshum |
You know, I did have that happen at least once during one of my restores... |
| 10:51 |
bshum |
I wasn't sure the cause though and it didn't happen the next time. |
| 10:51 |
bshum |
Assumed it was some weird fluke with the snapshot from the day I was restoring. |
| 11:04 |
|
bmills joined #evergreen |
| 11:04 |
|
vlewis joined #evergreen |
| 11:10 |
pastebot |
"mrpeters" at 64.57.241.14 pasted "how the heck?" (13 lines) at http://paste.evergreen-ils.org/38 |
| 11:11 |
mrpeters |
this makes me lol -- how in the world can a user have 2 of the same actor.usr_setting with identical id's, usr, and name/value settings!?! |
| 11:17 |
tsbere |
mrpeters: That wouldn't make me lol if it were in a DB I had to deal with. That may mean something is busted in postgres. :( |
| 11:17 |
eeevil |
mrpeters: hrm... that doesn't make me lol ... it makes me fear you have some corruption. certainly, the pkey index is broken |
| 11:17 |
jboyer-isl |
bshum: ick, I was looking at the constraints on that table, I wonder if it depends on the restore order. The constraint depends on the config.z3950_attr table and I'm running with -j 16. I may try a single-job restore to see if it helps, but that takes SO LONG on this older machine. :/ |
| 11:17 |
mrpeters |
yeah, it may not be fun...but it is what it is |
| 11:17 |
* eeevil |
suspects native replication |
| 11:17 |
mrpeters |
http://pastie.org/9192964 fwiw |
| 11:18 |
mrpeters |
sorry, rather http://pastie.org/9192964 |
| 11:18 |
bshum |
jboyer-isl: Yeesh, yeah I get what you're saying. Hmm |
| 11:18 |
mrpeters |
argh, copy/paste fail :( |
| 11:18 |
mrpeters |
http://pastie.org/9192970 -- lets try that one |
| 11:19 |
jboyer-isl |
bshum: though it's consistently title only. Maybe more subtle than that. |
| 11:19 |
tsbere |
mrpeters: Wait, there is a child table? |
| 11:20 |
tsbere |
mrpeters: Run your original queries with "FROM ONLY" instead of just "FROM" - See if you get different results. |
| 11:20 |
eeevil |
tsbere: good eye |
| 11:22 |
mrpeters |
the child table is a staging table |
| 11:22 |
mrpeters |
but yes, you are right, only 1 entry with that only |
| 11:22 |
mrpeters |
wonder if the staging table is breaking things though |
| 11:23 |
tsbere |
mrpeters: I would recommend removing the staging table and keep those as not being children in the future. |
| 11:23 |
mrpeters |
yep, i think you're right |
| 11:27 |
mrpeters |
damn...still having the error i had hoped getting rid of those dupes would fix |
| 11:27 |
mrpeters |
[Tue May 20 09:05:29 2014] [error] [client 98.220.133.90] egweb: Context Loader error: malformed JSON string, neither array, object, number, string or atom, at character offset 0 (before "email") at /usr/local/share/perl/5.14.2/OpenSRF/Utils/JSON.pm line 108.\n, referer: https://foo.bar.com/eg/opac/myopac/main |
| 11:28 |
jboyer-isl |
mrpeters: what's the error you're looking into? |
| 11:28 |
jboyer-isl |
Oops. |
| 11:28 |
mrpeters |
seeing that duplicate "email" value in a.us made me think that was the same "email" the JSON was chokin on, but i guess not |
| 11:28 |
tsbere |
mrpeters: email needs to be json quoted. Set the value to '"email"'? |
| 11:28 |
mrpeters |
issue is, when authenticated to the opac with a patron from this particular org unit, if you perform a search you get an internal server error while still logged in |
| 11:29 |
mrpeters |
aha |
| 11:29 |
tsbere |
mrpeters: Note that you want the double quotes in the value, the single quotes are just what sql will expect you to wrap it in. ;) |
| 11:29 |
mrpeters |
i bet thats exactly it |
| 11:29 |
mrpeters |
sure enough |
| 11:30 |
mrpeters |
darn it...knew it was something so simple |
| 11:35 |
|
akilsdonk_ joined #evergreen |
| 11:35 |
|
tfaile joined #evergreen |
| 11:35 |
|
mrpeters1 joined #evergreen |
| 11:41 |
|
dreuther joined #evergreen |
| 11:53 |
bshum |
fwiw, gmcharlt, we applied https://bugs.launchpad.net/bugs/1296937 to our production to help speedup lookups and it hasn't been a problem as far as I know. |
| 11:53 |
pinesol_green |
Launchpad bug 1296937 in Evergreen 2.5 "SIP2 Patron Information times out on too many checkouts/holds" (affected: 4, heat: 20) [Medium,Confirmed] - Assigned to Galen Charlton (gmc) |
| 11:54 |
gmcharlt |
bshum: yep, I'm nearly done testing it |
| 11:54 |
bshum |
gmcharlt++ |
| 11:54 |
tsbere |
heh, I just poked him to say the same thing. We had people with a couple hundred holds complaining about overdrive not letting them log in. <_< |
| 11:55 |
bshum |
Yeah, that's the same thing we saw :( |
| 12:01 |
* tsbere |
recalls his testing: Insert a row into action.hold_request for every bib, then when that wasn't enough of a stress test adding one for every copy, for the test patron |
| 12:02 |
pinesol_green |
[evergreen|Thomas Berezansky] LP#1296937: (SIP2) Add ids_only parameter to _items functions - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=9ce8743> |
| 12:02 |
pinesol_green |
[evergreen|Galen Charlton] LP#1296937: (follow-up) make $ids_only be the last parameter for ->charged_items() - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=2f27b78> |
| 12:02 |
* tsbere |
wonders what Galen was doing with that follow up commit |
| 12:03 |
Dyrcona |
We've got that branch in production since the 11th. |
| 12:04 |
gmcharlt |
tsbere: bshum: Dyrcona: committed; note the follow-up |
| 12:04 |
tsbere |
gmcharlt: What did that follow-up commit get us beyond confusing things inside of SIPServer? |
| 12:04 |
gmcharlt |
tsbere: read the commit message on the Evergreen follow-up |
| 12:05 |
tsbere |
gmcharlt: I did. I still don't get why it was needed. The code that used that parameter existed only in the Evergreen side of things, and if SIPServer triggered the "force barcode" code it actually *improved* the patron information response from not doing so in my own testing. |
| 12:06 |
tsbere |
gmcharlt: Thus, as I said a moment ago: What does that get us beyond confusing things inside of SIPServer with different numbers of params needed for each summary call? |
| 12:09 |
eeevil |
tsbere: I'm having a hard time understanding when it's ever a good idea to reorder positional parameters as opposed to always adding to the end |
| 12:09 |
gmcharlt |
tsbere: prior to the follow-up, if one upgraded Evergreen but not SIPServer, it was unclear that the renew-all message would get the correct information to actually renew the items |
| 12:10 |
tsbere |
gmcharlt: Ummm.....the renew-all code in question is part of Evergreen, not SIPServer. Which is my point. If you upgraded Evergreen you got the new version of the renew all code too. |
| 12:10 |
gmcharlt |
and yes, I also have a hard time seeing that it's a good thing to add new positional parameters any place other than at the end |
| 12:11 |
gmcharlt |
tsbere: which absolutely depended on remembering to upgrade SIPServer |
| 12:11 |
gmcharlt |
which yes, admins should be doing, but I'd rather not punish them for that slip-up unnecessarily |
| 12:12 |
tsbere |
gmcharlt: The only conflict point I could find was if you updated *SIPServer* and not evergreen, at which point SIPServer would be counting a list of barcodes instead of titles until Evergreen was updated for one call, which was an improvement. |
| 12:14 |
tsbere |
eeevil/gmcharlt: I felt keeping the calls SIPServer was making consistent was more important than keeping the function call identical, given the only usage was internal to Evergreen, so that in the future we don't have oddities if we un-fork Evergreen vs Koha SIPServer |
| 12:14 |
* tsbere |
vanishes for a couple min to fetch his lunch |
| 12:15 |
|
jwoodard joined #evergreen |
| 12:19 |
DPearl |
I'm looking at the suppress-transit code. Our situation is where main desk receives transits for kid's department (a sub-branch); we'd LIKE it to put it on the holdshelf (in the kid's room), but current behavior changes pickup_lib to the main desk. I can see arguments for both behaviors. Has anyone thought about this? |
| 12:20 |
|
jihpringle joined #evergreen |
| 12:22 |
kmlussier |
DPearl: I think dbwells suppresses transits between a branch and departments. He might have some insight. |
| 12:23 |
DPearl |
kmlussier: Thanks |
| 12:24 |
kmlussier |
DPearl: You might also want to take a look at bug 850461 where that feature was added. tsbere talked through a lot of use cases there. |
| 12:24 |
pinesol_green |
Launchpad bug 850461 in Evergreen "Ability to suppress transits between certain org units" (affected: 1, heat: 8) [Wishlist,Fix released] https://launchpad.net/bugs/850461 |
| 12:25 |
* mmorgan |
is back from a meeting, catching up on scrollback |
| 12:25 |
phasefx |
DPearl: I think dbwells maybe does it via the Suppress Hold Transits Group and Suppress Non-Hold Transits Group settings; I haven't played with those myself |
| 12:26 |
tsbere |
gmcharlt: I have returned and STILL challenge your follow-up commits. And challenge you having committed them without sign-offs from someone else, for that matter. <_< |
| 12:26 |
mmorgan |
jboyer-ils++ jeff++ |
| 12:26 |
phasefx |
DPearl: I guess that was the code you were looking at :D |
| 12:27 |
mmorgan |
Thanks for the info on prefs.js |
| 12:28 |
mmorgan |
Oops, that's jboyer-isl++ |
| 12:29 |
DPearl |
kmlussier: Yes, The code was added, but stopped working. |
| 12:31 |
gmcharlt |
tsbere: well, I was not expecting a follow-up that invoked standard practice of adding new position parameters to the end of a routine to be controversial, but I also specifically pointed it out for discussion |
| 12:31 |
gmcharlt |
I'm not sneaking anything by anyone |
| 12:31 |
tsbere |
gmcharlt: Believe it or not, though I haven't dug out the logs, the ordering of the params was discussed previously. I think eeevil may have even prompted some of the discussion. |
| 12:34 |
gmcharlt |
tsbere: if so, it was a dicussion that is not reflected in the bug discussion, nor in any commit message, nor in any comment in the code |
| 12:34 |
tsbere |
gmcharlt: At this point I could argue that leaving things in for any length of time with the follow-up is more of an issue. If those of us running without the follow up in SIPServer update Evergreen and get the follow up we will likely see a decrease in the patron information response speed as it gives out barcodes instead of IDs. |
| 12:36 |
tsbere |
gmcharlt: Conversely to your comment, your decision that a follow-up commit was needed was also not reflected in the bug discussion and, as a single sign off, was not discussed before being committed to master and release branches, regardless of any comments or commit messages you may have added in it. |
| 12:37 |
tsbere |
In fact, the first time I knew you were planning a follow up commit to change that was *after* it was committed |
| 12:40 |
|
b_bonner_ joined #evergreen |
| 12:51 |
mmorgan |
I have another about:config question. |
| 12:51 |
mmorgan |
I turn on the Amnesty Mode checkin modifier, which is sticky from login to login. |
| 12:51 |
mmorgan |
I can see this in about:config: |
| 12:51 |
mmorgan |
oils_persist_egtraining.noblenet.org_checkin.xul_checkin_auto_retarget_checked;true |
| 12:51 |
mmorgan |
but I don't see any change in prefs.js for the profile I'm using. |
| 12:52 |
mmorgan |
Is this stored in a different place? |
| 12:52 |
jeff |
I participated in the discussion that tsbere is referencing, and I'm interested in both the performance benefits of the fix as well as keeping SIPServer friendly to future-un-forking (and thirdly, keeping the unexpected from happening when SIPServer and Evergreen are upgraded independently from each other). I will attempt to make time between now and tomorrow evening to refresh my memory of the issues and comment on the bug and/or propose a working branch |
| 12:53 |
jeff |
and/or propose a working branch if applicable. |
| 12:53 |
jeff |
(benefit of having multiple active clients -- i can see when my own messages truncate!) |
| 12:53 |
tsbere |
jeff: My single active client knows when my message will truncate and splits it. <_< |
| 12:53 |
jeff |
anyway, I have nothing other to contribute to that subject at this time. here's hoping i can make some time. :-) |
| 12:56 |
jeff |
yeah, i keep meaning to take time to adjust that here. it would probably be beneficial, as i tend to be... verbose. |
| 12:58 |
jeff |
I feel like I should have made some effort at the time of the original conversation to comment in the bug, even if I had not come to any conclusions yet -- having some note in the commit message or the bug itself with regard to choice of parameter position and the expected/anticipated impacts in scenario x, y, and z would probably have helped. |
| 13:01 |
jeff |
I don't think that it's reasonable to expect any one of us to have read the entirety of IRC conversations before attempting to review or sign off on fixes. For my part, I'll try to do a better job of cross-linking from bug comments to IRC conversations, or (perhaps better) summarize. |
| 13:01 |
|
SeramaFly joined #evergreen |
| 13:03 |
jeff |
perhaps wandering too far down the path of trying to mediate where it's not desired, putting myself in two sets of shoes I can empathize with "you changed my code -- i did it that way on purpose!" as well as "it would have been helpful if the reason for breaking from convention was pointed out". :-) |
| 13:09 |
jeff |
and of course there are other issues lurking in the depths. i'll stop my monologue/exposition now. :-) |
| 13:11 |
csharp |
jeff++ |
| 13:18 |
|
Dyrcona joined #evergreen |
| 13:21 |
jeff |
csharp: pfft. i haven't DONE anything yet. tsbere++ for filing the bug and proposing a fix, and gmcharlt++ for trying to get some movement on said bug :-) |
| 13:26 |
gmcharlt |
offerred in the spirit of compromise - https://bugs.launchpad.net/evergreen/+bug/1296937/comments/3 |
| 13:26 |
pinesol_green |
Launchpad bug 1296937 in Evergreen 2.5 "SIP2 Patron Information times out on too many checkouts/holds" (affected: 4, heat: 20) [Medium,Confirmed] - Assigned to Galen Charlton (gmc) |
| 13:29 |
|
kmlussier joined #evergreen |
| 13:40 |
|
bmills joined #evergreen |
| 13:47 |
* gmcharlt |
is looking at a patch that would cause minor breakage to JSPac |
| 13:48 |
tsbere |
gmcharlt: Wait, we care about breakage to JSPac? Since when? |
| 13:48 |
gmcharlt |
this is probably a really obvious Q and A, but I think it wouldn't hurt to be explicit: are we all agreed that we don't care about anything that would break JSPac? |
| 13:49 |
gmcharlt |
and no, I rather suspect we don't, but for as long as it lives in the code base, we should probably be crystal clear about expectations |
| 13:50 |
jeff |
Not having tested jspac on 2.6 in... ever, I'm not sure why I'm asking, but: are you planning to backport the change that breaks jspac to rel_2_6 or is it just master-and-forward? |
| 13:51 |
* kmlussier |
thinks we should break JSPac as much as we can to convince anyone who may be using it to get off of it. |
| 13:52 |
kmlussier |
We officially stopped supporting it in 2.4, right? |
| 13:52 |
gmcharlt |
something like that |
| 13:54 |
gmcharlt |
jeff: the patch in question (bug 1321017) is something that would be a candidate for porting back to 2.6, but might be useful to port to 2.5 if anybody was somehow managing to create metarecord holds then |
| 13:54 |
pinesol_green |
Launchpad bug 1321017 in Evergreen "doing SIP2 lookup of a patron who has a metarecord hold can fail" (affected: 2, heat: 12) [High,New] https://launchpad.net/bugs/1321017 |
| 13:55 |
gmcharlt |
kmlussier: FYI, bug 1312309, which I believe we would like to see handled in 2.7 |
| 13:55 |
pinesol_green |
Launchpad bug 1312309 in Evergreen "to remove last remnants of JSPAC" (affected: 2, heat: 10) [Wishlist,Confirmed] https://launchpad.net/bugs/1312309 |
| 13:56 |
jeff |
that reminds me... |
| 13:58 |
* jeff |
assigns and comments |
| 13:59 |
gmcharlt |
jeff++ |
| 13:59 |
jeff |
gmcharlt: Lacking hard data on if anyone is using jspac with 2.6 or 2.5, I've no strong opinion on breaking metarecord holds in jspac. I'd be more interested in if you think that changing the method calls would hinder any future work on metarecords/metarecord holds in tpac. |
| 14:00 |
jeff |
It seems like the underlying query was in need of some attention anyway, so perhaps there's nothing to "preserve" for supporting future enhancements. |
| 14:02 |
jeff |
There's also the remote possibility that someone was using the API call externally. Might be worth a quick ack-grep of Syrup. Either way, noting the change in the release notes would probably be polite. |
| 14:03 |
jeff |
no matches for "metarecord" in Syrup. :-) |
| 14:03 |
gmcharlt |
jeff: I think that's essentially the case (regarding adding filtering in the future) |
| 14:07 |
jeff |
and eeevil has replied in-bug possibly making the question moot. |
| 14:09 |
eeevil |
well, the only thing in JSPAC that would break would be the ability to filter to a subset of MR constituents |
| 14:10 |
eeevil |
that is, if you do a JSPAC MR search, and click on an MR that has more than on record, what gets displayed will no longer filter on type/form/blvl |
| 14:11 |
kmlussier |
Nope. I've never seen anything in Syrup related to metarecords. |
| 14:11 |
eeevil |
and the order of the constituents could be different (but likely won't be, because type/form/blvl are encoded, to a degree, in the record quality) |
| 14:39 |
|
dkyle joined #evergreen |
| 14:40 |
|
bradl joined #evergreen |
| 14:57 |
bshum |
It's been awhile, but has anyone looked closely at the required package list for a standalone PG database server? |
| 14:57 |
bshum |
Specifically this part of the README for "Installing additional Perl modules on a standalone PostgreSQL 9 Server" http://evergreen-ils.org/documentation/install/README_2_6.html#_setting_up_the_postgresql_server |
| 14:57 |
bshum |
I'm wondering if that list is still current and/or we need to add anything else to it. |
| 14:57 |
gmcharlt |
bshum: not specifically, but FWIW, I don't recall any recent cases where that list of Perl modules was nicomplete |
| 14:58 |
jeff |
bshum: do you have a specific reason for asking? |
| 14:58 |
bshum |
jeff: Mostly just cause I'm setting up a brand new clean database server :) |
| 14:58 |
gmcharlt |
now one thing that could be improved is that many of then are packaged for Debian and thus don't need to be isntalle from CPAN |
| 14:58 |
bshum |
gmcharlt: Yeah that's what I've found. With 14.04, all of them are now packages that we can just apt-get install |
| 14:59 |
bshum |
I'm not sure about Wheezy, but I imagine it's close |
| 15:00 |
bshum |
Would it be worth updating that portion of the README if that's the case? To use package names instead of the perl module names? |
| 15:00 |
bshum |
Or maybe splitting it I guess... into more specific Debian/Ubuntu versions as required |
| 15:01 |
gmcharlt |
I think so, though even better would either be adding a new set of make targets |
| 15:01 |
gmcharlt |
and maybe better yet... just fold them into the postgres-server-* targets |
| 15:01 |
bshum |
Aha, interesting. |
| 15:02 |
jeff |
oh, and back to an earlier tangent... we have 9 outstanding metarecord holds currently. :P |
| 15:02 |
gmcharlt |
bshum: and maybe best of all, do both -- add new targets, and fold them into the exist ones |
| 15:03 |
gmcharlt |
that accommodates the experienced Pg admins who prefer to handle the Pg installation entirely on their own |
| 15:03 |
|
ldwhalen joined #evergreen |
| 15:04 |
bshum |
gmcharlt: I'll consider those points and see what I can wrangle together. |
| 15:04 |
bshum |
I'm still learning how the makefiles operate :) |
| 15:04 |
bshum |
At the very least, it seems like I'll have to create myself a new one anyways for trusty to handle PG 9.3 |
| 15:08 |
|
ldwhalen_mobile joined #evergreen |
| 15:09 |
|
hbrennan joined #evergreen |
| 15:15 |
hbrennan |
I have been working with our book cover supplier because we're having many images not show up in the catalog. They said that EG is "hard coded to only look at the last isbn in the listing" and ", "it (EG) won't move on to another isbn in the list even when a cover image is attached" |
| 15:15 |
|
bmills joined #evergreen |
| 15:15 |
hbrennan |
Is this true? Why isn't EG looking at the FIRST ISBN? |
| 15:16 |
bshum |
hbrennan: It depends... |
| 15:16 |
dbs |
hbrennan: it might depend on the book cover supplier. we have different implementations for each supplier |
| 15:17 |
hbrennan |
Syndetics |
| 15:17 |
bshum |
Which version are you running again? |
| 15:17 |
bshum |
(it used to be first ISBN, but nowadays, I think it's a bit more erratic) |
| 15:17 |
hbrennan |
2.5.2 |
| 15:17 |
hbrennan |
It seemed we had more images on 2.3.4 |
| 15:17 |
* bshum |
thinks jeff would know |
| 15:17 |
jeff |
nowadays it's more erratic but there was a recent fix or proposed fix to restore order :-) |
| 15:18 |
hbrennan |
Is it just me or does picking the last ISBN not really make sense? |
| 15:18 |
jeff |
hbrennan: i'd be interested in links to records that you think you should have covers for, or think you used to have covers for |
| 15:19 |
Dyrcona |
hbrennan: Well, if every record had a single ISBN, i.e. if the ISBN really were a unique identifier.... |
| 15:19 |
hbrennan |
I'd be happy to send you the reply from Syndetics... sounds like they manually fixed the two records I asked about, but I can find more |
| 15:19 |
jeff |
hbrennan: technically now it's picking an indeterminate, unpredictable isbn. that violates my principe of absurdity, so i support fixing it. :-) |
| 15:19 |
hbrennan |
Me too |
| 15:19 |
hbrennan |
Sometimes I haven't been able to figure out why none of 4 ISBNs will display an image |
| 15:19 |
Dyrcona |
jeff: You cannot escape the Holy Chao. |
| 15:21 |
Dyrcona |
hbrennan: Is there "junk" after the ISBNs in the 220 $a? |
| 15:21 |
bshum |
jeff: Aha, found what you were talking about, comment on https://bugs.launchpad.net/evergreen/+bug/1302207/comments/2 ? |
| 15:21 |
pinesol_green |
Launchpad bug 1302207 in Evergreen "Syndetics broken cover image retrieval" (affected: 1, heat: 8) [Medium,Confirmed] |
| 15:21 |
jeff |
bshum: yes, thanks |
| 15:21 |
hbrennan |
Nada |
| 15:22 |
hbrennan |
020. ‡a1400069629 (acid-free paper) 020. ‡a9781400069620 (acid-free paper) 020. ‡z9780679604617 (eBook) 020. ‡a9780812997033 (signed edition) 020. ‡a0812997034 (signed edition) |
| 15:22 |
hbrennan |
Unless you mean the notes, then yes |
| 15:22 |
jeff |
hbrennan: when you say "they", do you mean local catalog staff or syndetics? |
| 15:22 |
Dyrcona |
Yes, the notes are what I mean. |
| 15:22 |
hbrennan |
Syndetics |
| 15:22 |
jeff |
hbrennan: i think you might be being affected by another bug which I need to give more attention to |
| 15:22 |
Dyrcona |
Sorry for the typo of 220 for 020. |
| 15:23 |
hbrennan |
I know enough MARC to figure that one out :) |
| 15:23 |
* Dyrcona |
knows more MARC than is healthy. |
| 15:23 |
hbrennan |
I have another un-tampered record that is showing the wrong cover |
| 15:24 |
Dyrcona |
@marc 020 |
| 15:24 |
pinesol_green |
Dyrcona: The ISBN assigned to a monographic publication by designated agencies in each country participating in the program. The field may include terms of availability and canceled or invalid ISBNs. It may be repeated for multiple numbers associated with the item (e.g., ISBNs for the hard bound and paperback manifestations; ISBNs for a set as a whole and for the individual parts in the set). (1 more message) |
| 15:24 |
hbrennan |
bleeeeeehhhh |
| 15:24 |
bshum |
Bad cover matches are just annoying. Mostly because Evergreen will keep the cached bad cover even if Syndetics does finally get their act together and fix errors on their end. |
| 15:24 |
hbrennan |
This is why I chose IT when given the choice between that and more cataloging |
| 15:24 |
Dyrcona |
We get reports of wrong covers all the time. |
| 15:24 |
Dyrcona |
We use Syndetics. |
| 15:25 |
hbrennan |
And in a simplier sense, I'm going to go to the stacks looking for a white cover when it's really red! |
| 15:25 |
bshum |
jeff: Do you think it's the bad parse problem that was in the bug I linked to? Where it's that ISBN followed by stuff in parenthesis? |
| 15:25 |
hbrennan |
That plain english is really useful, so I'd hate to get rid of it |
| 15:26 |
jeff |
Business::ISBN is far less tolerant than I thought it was of extra data. |
| 15:27 |
jeff |
hbrennan: no need to get rid of any of it. |
| 15:27 |
hbrennan |
jeff: Good |
| 15:27 |
gmcharlt |
jeff: re Business::ISBN, http://git.koha-community.org/gitweb/?p=koha.git;a=commitdiff;h=ed4b60fa1dca40d0d0bcf4880fd5f2892a15f90f is (at one remove) on point |
| 15:27 |
jeff |
If you ever see me advocate mangling your metadata to work around limitations in your ILS (ESPECIALLY if your ILS is open source), hit me with something. |
| 15:28 |
jeff |
We're STILL fixing bad data from that kind of thing in our previous ILS. |
| 15:28 |
jeff |
I have a report for 245 tags where ind2 is 4 and the first characters of the $a are not "The " :P |
| 15:30 |
|
ldwhalen_mobile joined #evergreen |
| 15:31 |
hbrennan |
I'm going to flip flop the first and last of (6!) ISBNs for a title which is showing the wrong cover image... |
| 15:32 |
jeff |
hbrennan: keep in mind that that may do nothing. in the code you're running, there is no predictable way to ensure that a certain ISBN is used for a Syndetics lookup. |
| 15:33 |
jeff |
gmcharlt: does that code and that test pass for you? which version of Business::ISBN? It's been too many weeks since I was looking at Business::ISBN, but memory says it won't do what is expected there. |
| 15:34 |
dbs |
we put some extensive ISBN pre-cleanup code into database logic to work with Business::ISBN, should be able to reuse that |
| 15:34 |
gmcharlt |
jeff: that patch needed a couple follow-ups (also in the source tree) to deal with invalid ISBNs, but overall, it does appear to correctly normalize ISBNs, and produce variations of an ISBN |
| 15:35 |
* jeff |
looks to see if his memory is wrong, but also sees that there's a new-this-year version of Business::ISBN |
| 15:35 |
jeff |
dbs: yes, my thought was either or both of that or old jspac routines :-) |
| 15:35 |
hbrennan |
We flip flopped them and it did not update with the correct one |
| 15:35 |
dbs |
oh hey, I mentioned that code in comment #1 |
| 15:35 |
|
Dyrcona joined #evergreen |
| 15:36 |
hbrennan |
Granted this record has 6 ISBNs... |
| 15:36 |
bshum |
dbs++ :) |
| 15:36 |
dbs |
and it's really frustrating for things to work in one part of the system and not in another part :) |
| 15:37 |
* jeff |
nods |
| 15:37 |
|
ldw joined #evergreen |
| 15:38 |
jeff |
assigned bug 1302207 to myself |
| 15:38 |
pinesol_green |
Launchpad bug 1302207 in Evergreen "Syndetics broken cover image retrieval" (affected: 1, heat: 8) [Medium,Confirmed] https://launchpad.net/bugs/1302207 - Assigned to Jeff Godin (jgodin) |
| 15:38 |
hbrennan |
Sweet. I can add examples of records |
| 15:38 |
jeff |
(which is of course the only pre-requisite to making time to fix it, right?) |
| 15:39 |
bshum |
:) |
| 15:40 |
jeff |
on the subject of "don't mangle metadata to work around limitations in X", does the idea of re-ordering 020 tags to get better added content results sit well (or "well enough for now") with everyone? |
| 15:40 |
hbrennan |
As long as the order is predictable :) |
| 15:40 |
hbrennan |
Or add a "randomize" button |
| 15:40 |
jeff |
It doesn't impact most methods of record matching / etc that I can think of, and there aren't many places I can think of where a record needs to be "identical" for any other reasons... |
| 15:42 |
tsbere |
jeff: I have no problems with it, and the code I threw out would also apply to the other two fields potentially used too, I believe. "Most important one first, others after that" doesn't seem like a bad thing to begin with... |
| 15:43 |
hbrennan |
Syndetics also told me that EG only looks at ONE ISBN and it won't move on to other ISBNs even when a cover isn't attached |
| 15:45 |
tsbere |
hbrennan: One ISBN, one UPC, and one ISSN, regardless of whether or not later ones would return results. In part because we don't want to make multiple requests out to Syndetics for the later ones. If Syndetics let us throw lists at them we probably would, though. |
| 15:46 |
|
akilsdonk joined #evergreen |
| 15:50 |
dbs |
jeff: deterministic makes sense over randomness to me, at least for debugging problems, so +1 to tsbere's patch |
| 15:50 |
hbrennan |
tsbere: That makes sense |
| 15:50 |
dbs |
(I can't imagine it killing performance but let's keep an eye on it anyway - heh) |
| 15:50 |
jeff |
hbrennan: i have some thoughts on "be more aggressive about finding results from syndetics" also. |
| 15:51 |
dbs |
It might be worthwhile to find out from syndetics how other ILSes use more than one ISBN with their service |
| 15:51 |
jeff |
dbs: yeah. it's an id, so there's an implicit index in terms of sorting, right? :-) |
| 15:51 |
bshum |
Yuck, Callender++ eeevil++ for work on https://bugs.launchpad.net/evergreen/+bug/1321429 |
| 15:51 |
pinesol_green |
Launchpad bug 1321429 in Evergreen "Hold shelf expire time check uses UTC time," (affected: 1, heat: 6) [Undecided,New] |
| 15:51 |
jeff |
hbrennan: did Syndetic Solutions / Bowker / Proquest support imply that this was unusual in terms of trying the first isbn/etc? |
| 15:52 |
jeff |
dbs: the logic exposed in their "Syndetics Plus" offering only uses the first ISBN, last I looked. |
| 15:52 |
hbrennan |
They said if EG were coded to look at the top ISBN they think our catalog would look better |
| 15:53 |
hbrennan |
and it "should have" moved on to the next ISBN when a cover wasn't found |
| 15:53 |
hbrennan |
Previoulsy we had Sirsi and images worked quite well |
| 15:53 |
hbrennan |
and they worked better in 2.3.4 than 2.5.2 |
| 15:54 |
hbrennan |
With the examples I gave Syndetics, they said if those adjustments were made then the covers would have displayed (first ISBN, and moving on if not) |
| 15:54 |
dbs |
So probably some combination of the sanitization of the ISBN that we did in the JSPAC + grabbing the first ISBN from the record (because we pulled from the MARCXML directly using bibtemplate) |
| 15:54 |
hbrennan |
"In the very least - if Evergreen were hard code to look at the top isbn I think that your catalog would have better cover image coverage. " |
| 15:54 |
hbrennan |
and it would be "helpful" if it moved on to others |
| 15:54 |
dbs |
Moving on... I can't imagine any other system actually does that. |
| 15:55 |
jeff |
agreed on first ISBN in the record, and agreed that there's a bug needing attention (which I just assigned to myself) to reduce the number of "not found" images when there's certain extra data in the 020$a |
| 15:55 |
hbrennan |
It's relatively easy for staff to move the ISBNs around to fix it, so I'd say that's the most important thing here |
| 15:55 |
* jeff |
nods |
| 15:55 |
dbs |
I wonder how Syndetics would feel about us running nightly batches of ISBNs against their service to determine what they have :) |
| 15:55 |
hbrennan |
All the reports of these missing/wrong images are coming to me.. and staff definitely know which one it SHOULD be |
| 15:56 |
jeff |
I think those two issues can be dealt with in the same bug. |
| 15:56 |
dbs |
jeff++ |
| 15:56 |
hbrennan |
jeff++ |
| 15:56 |
jeff |
dbs: or feeding us a list of what they have, isbn/issn/upc-wise :-) |
| 15:56 |
dbs |
agreement, not even violent :) |
| 15:56 |
jeff |
tsbere++ for a very elegant proposed fix to key ordering |
| 15:57 |
hbrennan |
I have to say, Syndetics did not use blame language towards EG |
| 15:57 |
hbrennan |
it would be easy for them to do, but they didn't |
| 15:57 |
jeff |
certainly. they've been very helpful when i have worked with them in the past. |
| 15:57 |
jeff |
including providing us with a client code for development/testing, etc. |
| 15:57 |
hbrennan |
They called it a "small technical issue" on EG's part |
| 15:58 |
hbrennan |
And they did add the missing ISBNs in their database so our images would show.. at least for the two we were missing in the case |
| 15:59 |
|
ericar joined #evergreen |
| 15:59 |
dbs |
heh, I would think any valid ISBNs that they don't have in their database should trigger an automatic xISBN call against OCLC to try and fill in that gap in their database |
| 15:59 |
|
wjr_ joined #evergreen |
| 16:00 |
hbrennan |
dbs: Exactly. That's where we're getting them from! |
| 16:02 |
jeff |
dbs: right :-) |
| 16:03 |
hbrennan |
If I had more time in my life I'd be sending them everything missing i can find, but I think that would be a whole other job |
| 16:03 |
jeff |
dbs: of course, in "aggressive AC mode", Evergreen would simply try every ISBN in the record, then consult the oISBN service of other Evergreen libraries, try all of THOSE ISBNs, etc! |
| 16:04 |
jeff |
of course, then we'd get into XKCD 416 territory: http://xkcd.com/416/ |
| 16:04 |
dbs |
hbrennan: you shouldn't have to... we're sending them the requests via the API, so they know every ISBN that comes in that doesn't return a match |
| 16:04 |
jeff |
"Zealous Autoconfig" |
| 16:05 |
jeff |
Incidentally, that's how we handle missing cover images. We seek images based on the most commonly displayed records without cover images. |
| 16:06 |
jeff |
(There's a javascript handler in our catalog which reports cover-not-found) |
| 16:06 |
hbrennan |
That is super nifty |
| 16:06 |
bshum |
Haha, I like the alt text on that one, jeff. |
| 16:07 |
hbrennan |
I can't wait until more than 25% of my job is dedicated to EG.. then I can learn about this stuff! |
| 16:08 |
hbrennan |
(I say, as I try to juggle circ desk duties while having this conversation) |
| 16:11 |
dbs |
hbrennan++ |
| 16:12 |
jeff |
some of the best ideas come when working on desk. |
| 16:12 |
jeff |
(they work best when implemented when NOT on desk, though) |
| 16:14 |
jeff |
that reminds me, I still need to share https://twitter.com/skrrrl/status/447361459865931776 with the folk here who asked for Update Expire Date |
| 16:15 |
* Dyrcona |
feels like replying to a openils-dev thread with, "And that is why we run the master branch!" |
| 16:18 |
jeff |
Dyrcona: yeah. |
| 16:25 |
jeff |
dbs: and also, Syndetics could arguably accept a list of isbns, and/or trim extra data -- be liberal in what you accept, and all that... |
| 16:26 |
jeff |
I did at one time go looking at the API that Syndetic Solutions Classic and Plus are using for their data... |
| 16:26 |
jeff |
pricing unclear. |
| 16:34 |
gsams |
Our new library needs to export bib records for boopsie, Something like 150,000 records. I don't feel like recommending the marc exporter through the staff client for that. Is there a more efficient, hopefully automated method anyone else might use? |
| 16:35 |
bshum |
gsams: So what you'll likely want to do is to use the marc_export command line tool. |
| 16:35 |
gsams |
bshum: I've not done that before, sounds like a learning experience |
| 16:36 |
jcamins |
Doesn't boopsie integrate with EG via OpenSRF or an API or something? I thought I was told that Boopsie integration with EG was better than with Koha. |
| 16:36 |
bshum |
jcamins: Eh, I don't think so. but maybe there's some secret sauce that I don't know about. |
| 16:36 |
bshum |
What I know is that we're also supposed to be doing regular marc exports of all our bibs (plus holdinngs) |
| 16:36 |
bshum |
But we don't |
| 16:36 |
bshum |
Due to the amount of time it takes. |
| 16:37 |
bshum |
Part of the reason why I'm still soooooooo happy that Dyrcona wrote improvements to marc_export for 2.6 |
| 16:38 |
bshum |
gsams: As the opensrf user in the command line, you can probably do something like "marc_export --help" |
| 16:38 |
bshum |
And read about the ways of using the marc_export utility |
| 16:38 |
gsams |
bshum: thanks, I'll see what I can do with that! |
| 16:39 |
bshum |
That said, I strongly recommend upgrading to 2.6 (hehe, see how I keep saying that) and using the new marc_export tool cause it'll be faster than the older ones. |
| 16:39 |
bshum |
:D |
| 16:39 |
Dyrcona |
gsams: Or, you could just have a look at this: http://git.mvlcstaff.org/?p=jason/boopsie.git;a=summary |
| 16:39 |
* Dyrcona |
recommends upgrading to master, but I'm crazy like that. |
| 16:40 |
gsams |
Dyrcona: if only we could afford to do that, I would honestly be all for it. |
| 16:40 |
bshum |
Dyrcona: My crazy level has cooled down a bit. I blame it on being on vacation for too long. |
| 16:41 |
bshum |
Don't worry I'll be back to full swing soon enough ;) |
| 16:41 |
Dyrcona |
"Afford?" What does it cost? |
| 16:42 |
tsbere |
Dyrcona: Insane amounts of frustration when you can no longer give librarians a fixed "we are on version X" response? Massive time and effort explaining what going to master means to get it approved? |
| 16:42 |
gsams |
either support, or properly trained staff. We are a small consortium, I am the only staff member that has any training on the inner workings of Evergreen, and that really isn't saying much. |
| 16:42 |
jeff |
jcamins: last I knew, Boopsie had transitioned from making API calls to screen scraping the Evergreen catalog |
| 16:42 |
Dyrcona |
bah. people care too much about nonsense. |
| 16:44 |
jcamins |
jeff: I was told that a while ago, and I don't know if it was true then. |
| 16:44 |
jeff |
jcamins: sorry, what is "that"? |
| 16:47 |
jcamins |
jeff: that EG had better API integration with boopsie than Koha. |
| 16:47 |
jeff |
ah. |
| 16:47 |
Dyrcona |
Anyway, when it comes to versions, I just tell people we're on whatever was the closest latest version when we updated. |
| 16:47 |
Dyrcona |
So, now, we're 2.6.0, with a couple of 2.6.1 patches. |
| 16:49 |
* Dyrcona |
saw a document from two(?) years ago: "Boopsie uses these Evergreen calls" |
| 16:49 |
jeff |
"but probably not anymore" :-) |
| 16:50 |
jeff |
i think their SOP was scraping, and they couldn't easily scrape JSPAC, so they were making API calls and hardcoding the array positions on their end, and that would break for some upgrades, and when TPAC became widespread, they transitioned to scraping. |
| 16:51 |
gsams |
The good news is that we only need to do the process monthly, so I could probably relegate it to Sundays or something like that. I don't know how long it would take one way or the other until I give it a go though... |
| 16:51 |
jeff |
some of this is based on conversations with them when we were a customer, some is based on observation, etc, etc. |
| 16:51 |
jeff |
when we were doing boopsie exports, we did it via sql against our reporting db, and it was usually pretty quick for 300k or so bibs |
| 16:52 |
jeff |
i don't think we were exporting holding data. |
| 16:52 |
jeff |
since they poll holding data live at time of viewing the record (possibly with a small cache) |
| 16:54 |
jeff |
gsams, bshum: are they asking for holdings data? |
| 16:55 |
bshum |
jeff: In our case, because we were attempting to make use of some special service for our consortium, they required holdings data from us. |
| 16:55 |
bshum |
I don't think it was something employed by everyone who used it |
| 16:55 |
jeff |
do you know what that special service was? |
| 16:55 |
gsams |
jeff: This library just migrated in from Millenium, and that was what they were doing with that system. If it is possible to do this differently, as in not have to do much of anything at all, I'm all for that, and I imagine they are all for that. |
| 16:56 |
jeff |
oh, right -- you might have been dealing with "one extract to be used by multiple boopsie client libraries with their own apps"? |
| 16:56 |
bshum |
I think it was to limit searchable material to the folks who actually subscribed to Boopsie. Since not 100% of our members use it. |
| 16:56 |
jeff |
bshum: got it |
| 16:56 |
bshum |
fwiw, I don't think it ever worked right, and we've negotiated back to doing MARC exports without holdings in the future. |
| 16:56 |
bshum |
Once we sort out our next upgrade and get better marc_export tools ;) |
| 16:56 |
gsams |
bshu, jeff: I imagine it would be that way for us as well since they are the only library that uses it. |
| 16:58 |
gsams |
well, this will be fun. |
| 16:59 |
jeff |
when we were a customer, we were one library system within a larger evergreen installation participating on our own with boopsie. we had a script that exported just those bibs that were relevant. |
| 16:59 |
gsams |
jeff: yeah that is basically what I will be trying to setup. |
| 17:00 |
|
dreuther joined #evergreen |
| 17:01 |
gsams |
just a bit smaller scale, as in one library in a 13 library system. |
| 17:03 |
pinesol_green |
Incoming from qatests: Test Success - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 17:07 |
|
dreuther joined #evergreen |
| 17:09 |
|
mmorgan left #evergreen |
| 17:09 |
dbwells |
Browser prompt: "You are about to close 793 tabs. Are you sure you want to continue?" |
| 17:10 |
dbwells |
I need help. |
| 17:10 |
jcamins |
dbwells: does it actually say 793? |
| 17:10 |
kmlussier |
ha ha |
| 17:10 |
dbwells |
yessir |
| 17:10 |
bshum |
I don't think I've ever had more than 20 or 25 tabs open before in a browser. |
| 17:10 |
bshum |
But that does sound like an impressive amount ;) |
| 17:10 |
kmlussier |
I'm sure there's a support group out there for people who open too many tabs. |
| 17:12 |
gmcharlt |
dbwells: I thought I was bad about never closing tabs |
| 17:12 |
* gmcharlt |
was seriously mistaken |
| 17:13 |
hbrennan |
dbwells: I will join the support group |
| 17:13 |
dbwells |
I think my previous high was in the 300-400 range. But now I have a "system" where I really only use the ends, and eventually tabs just fade away into the middle-regions. |
| 17:13 |
hbrennan |
I sometimes want to cry when my computer auto-updates and can't restore my tabs |
| 17:13 |
kmlussier |
I was thinking I would join the support group too, but then seeing 793 made me feel better about my own tab behavior. |
| 17:14 |
hbrennan |
kmlussier: That's what support groups are for, right? Outing people with worse problems? |
| 17:14 |
gmcharlt |
heh |
| 17:14 |
jcamins |
dbwells: what browser do you use? I found both FF and Chrome to get sluggish when confronted with large numbers of tabs. |
| 17:15 |
hbrennan |
Speaking of problems, there's a 7,000 acre out of control forest fire an hour north of me |
| 17:15 |
hbrennan |
Just thought I'd share that, since my vision is fading as our library and world fills with smoke |
| 17:16 |
kmlussier |
hbrennan: Is it close enough that you should consider leaving the building? |
| 17:17 |
hbrennan |
Not yet, but I want to |
| 17:17 |
hbrennan |
:) |
| 17:17 |
hbrennan |
I don't really know what they would do about evacuations, since the fire is north and the ocean is south |
| 17:17 |
hbrennan |
and one road, of course, since this is Alaska |
| 17:18 |
dbwells |
jcamins: It's Firefox. I've tried Chrome a few times, but once you get high enough, your tabs are just worthless little triangles. Maybe there's a way around it; never looked too hard. |
| 17:18 |
hbrennan |
dbwells: Maybe just use more windows? (<----enabler) |
| 17:19 |
dbwells |
hbrennan: :) |
| 17:27 |
jeff |
i've no idea why this message from git made me laugh, but it did: "Unable to fetch spot" |
| 17:27 |
bshum |
Hehe |
| 18:16 |
|
zerick2 joined #evergreen |
| 18:37 |
|
kmlussier joined #evergreen |
| 19:53 |
* gmcharlt |
grabs 0880 |
| 20:01 |
pinesol_green |
[evergreen|Mike Rylander] LP#1312945: auth-auth linking: cache less agressively and look for all links - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=89f8e98> |
| 20:01 |
pinesol_green |
[evergreen|Srey Seng] LP#1312945: authority.calculate_authority_linking and multiple linked tags - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=663715d> |
| 20:01 |
pinesol_green |
[evergreen|Mike Rylander] LP#1312945: baseline schema update - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=e7e9731> |
| 20:01 |
pinesol_green |
[evergreen|Galen Charlton] LP#1312945: add regression test - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=73aff25> |
| 20:01 |
pinesol_green |
[evergreen|Galen Charlton] LP#1312945: pin schema update - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=4df12a9> |
| 20:13 |
pinesol_green |
[evergreen|Dan Wells] LP#1314902: Restore header bar styles on results pages - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=e174630> |
| 21:21 |
|
kmlussier joined #evergreen |
| 22:04 |
|
kmlussier joined #evergreen |
| 22:09 |
|
Jimmy__ joined #evergreen |
| 22:10 |
|
b_bonner_ joined #evergreen |
| 22:10 |
|
mtcarlsoz joined #evergreen |
| 22:10 |
|
PSM joined #evergreen |
| 22:13 |
PSM |
Hi, I installed eg 2.6 on ubunutu 12.04, but when I try to start apache 2 I receive the error 'apache2: could not reliably determine the server's fully qualified domain name, using 127.0.1.1 for ServerName'. Could you help me please solve this issue? |
| 22:14 |
bshum |
PSM: That warning is actually "normal" for a system where you have not yet identified it with a fully qualified domain name |
| 22:15 |
bshum |
It's just letting you know that this hasn't been done and it's just using the localhost address 127.0.1.1 as the servername for the apache service. |
| 22:23 |
|
b_bonner joined #evergreen |
| 22:23 |
|
mtcarlson_away joined #evergreen |
| 22:23 |
PSM |
<bshum> Ok, I see. I guess should leave it this way then. My main concern is my staff client 2.6 on win xp machine is connecting fine to the server, but when I try Acquisitions, new brief record then to save the record I get the following error 'Event: 2002: DATABASE_QUERY_FAILED-> The attempt to query to the DB failed' on the server side it seems that it's running fine and I can do the srfsh test with no problems |
| 22:25 |
bshum |
PSM: I'm afraid that I can't speak to how acquisitions operates in that area, so I'm unsure how to instruct you on proceeding further, but yeah, that apache warning you noted is just a warning, not an actual error per say. |
| 22:26 |
PSM |
<bshum> I see, thanks for your help with Apache anyway. |
| 22:27 |
PSM |
<bshum> I wonder where would you recommend me to go for more help about this? |
| 22:28 |
bshum |
PSM: Well, this is normally a good place to ask those sorts of questions, but it's usually busier here during working hours for the US east coast time (lots more folks active then) |
| 22:28 |
bshum |
PSM: Alternatively, it's probably worth sending a message on the general mailing list with inquiry |
| 22:29 |
PSM |
<bshum> That's a great advice, thanks a lot. and I wish you a good night! |
| 22:32 |
bshum |
gmcharlt: Just an FYI for you (and others) that I temporarily broke something just now as I tried updating the dokuwiki |
| 22:32 |
bshum |
And I'm fixing it as quickly as I can |
| 22:34 |
kmlussier |
@blame bshum |
| 22:34 |
pinesol_green |
kmlussier: bshum is why we can never have nice things! |
| 22:34 |
bshum |
That's almost never true ; |
| 22:34 |
Guest40525 |
Ah, that's the line! |
| 22:34 |
kmlussier |
bshum: That's why you're not supposed to try working while you're sick. |
| 22:34 |
* dcook |
was trying to remember a good line to tease bshum ;) |
| 22:36 |
bshum |
kmlussier: Yeah you're probably right. |
| 22:37 |
bshum |
Mostly it's the templates that are borked |
| 22:38 |
bshum |
Looks like the upgrade took us a few past the last ones we were on last |
| 22:38 |
bshum |
So it's time for a slightly new look I guess. |
| 22:40 |
hbrennan |
Plus it's late. Why are you here?! |
| 22:41 |
kmlussier |
hbrennan: bshum is alway here this late |
| 22:42 |
bshum |
I'm not *always* here late... |
| 22:42 |
kmlussier |
Quite often? |
| 22:43 |
* bshum |
stops digging his own grave |
| 22:43 |
rangi |
bshum just likes to pretend he lives in nz |
| 22:43 |
rangi |
its only 2.43pm here |
| 22:44 |
bshum |
That's just called living in the future ;) |
| 22:44 |
bshum |
I like that idea |
| 22:45 |
hbrennan |
:) |
| 22:45 |
hbrennan |
There's a NZer here? Yay! |
| 22:45 |
hbrennan |
Someone earlier than me |
| 22:46 |
dcook |
Only 12:46pm here :p |
| 22:46 |
* dcook |
also pretends that bshum is around NZ and OZ |
| 22:47 |
bshum |
dcook: Hey, now that I've knocked England off my list of countries to visit, Australia is next ;) |
| 22:50 |
dcook |
Sweet as! It would be great to have you visit! |
| 22:50 |
hbrennan |
This is like the UN Hour |
| 22:50 |
* dcook |
just realized that "sweet as" might look like a typo for "sweet ass" |
| 22:51 |
dcook |
I never realized that before... |
| 22:51 |
hbrennan |
I've never heard someone say "sweet as" |
| 22:51 |
hbrennan |
unless it's sweet as _____ |
| 22:51 |
dcook |
hbrennan: I'm originally from Canada so it is quite like UN hour.. |
| 22:51 |
dcook |
hbrennan: I think it's a NZ/OZ thing to leave off the ____ at the end |
| 22:52 |
hbrennan |
I will ask my local NZer |
| 22:52 |
hbrennan |
:) |
| 22:52 |
dcook |
I think this was my original intro: http://www.urbandictionary.com/define.php?term=Beached%20As |
| 22:52 |
rangi |
yeah you never put things on the end |
| 22:52 |
rangi |
its just something as |
| 22:53 |
dcook |
I'm trying to think of other examples... |
| 22:53 |
hbrennan |
I learned something new tonight |
| 22:54 |
* jeff |
yawns |
| 22:54 |
jeff |
morning! |
| 22:54 |
jeff |
er, not-morning! |
| 22:55 |
dcook |
hbrennan: happy to be of service |
| 22:55 |
dcook |
It's been afternoon for about 55 minutes, jeff :D |
| 22:56 |
hbrennan |
But what day is it? Tues right? |
| 22:56 |
dcook |
Wednesday |
| 22:56 |
* jeff |
chuckles |
| 22:56 |
dcook |
Living in the future O_O |
| 22:56 |
bshum |
Like I said :) |
| 22:56 |
hbrennan |
jeff: Hey, I can't keep everything straight! |
| 22:56 |
bshum |
Show offs |
| 22:56 |
kmlussier |
Wednesday is just an hour away. Not that far in the future. |
| 22:56 |
hbrennan |
Not for me! |
| 22:56 |
hbrennan |
:) |
| 22:57 |
jeff |
@sing Tomorrow |
| 22:57 |
dcook |
I was in Canada at the end of Decemember 2012, but I was on the phone with my wife in Oz, so I was pretty sure the world hadn't ended ;) |
| 22:57 |
pinesol_green |
jeff: Leave me alone, I'm busy right now. |
| 22:57 |
jeff |
alas, pinesol_green isn't nearly as well-versed in song lyrics as zoia |
| 22:57 |
jeff |
(this is probably a GOOD thing) |
| 22:57 |
kmlussier |
jeff: But pinesol_green has desserts. |
| 22:57 |
hbrennan |
@dessert |
| 22:57 |
* pinesol_green |
grabs some Red Velvet Cake for hbrennan |
| 22:58 |
hbrennan |
I don't like red velvet - It's not a real flavor! |
| 22:58 |
hbrennan |
It's red! |
| 22:58 |
hbrennan |
redvelvet-- |
| 22:59 |
dcook |
lol |
| 23:00 |
kmlussier |
@dessert hbrennan |
| 23:00 |
* pinesol_green |
grabs some Krispy Kreme Donuts for hbrennan |
| 23:00 |
hbrennan |
That'll do. Thanks, kmlussier. |
| 23:00 |
hbrennan |
Still haven't seen my pie given out |
| 23:00 |
kmlussier |
Which pie was that? |
| 23:01 |
hbrennan |
wild Alaskan rhubarb of course |
| 23:01 |
hbrennan |
:) |
| 23:01 |
kmlussier |
Oh, that's right! I've already forgotten. |
| 23:01 |
bshum |
@dessert search alaskan |
| 23:01 |
pinesol_green |
bshum: 1 found: #13: "wild Alaskan rhubarb pie" |
| 23:01 |
bshum |
Lucky 13. |
| 23:01 |
hbrennan |
It only took me 8 times to get it added |
| 23:03 |
jeff |
hrm. red velvet krispy kreme. |
| 23:04 |
hbrennan |
Does Krispy Kreme make different kinds? We don't have them here.... |
| 23:04 |
jeff |
i suspect that would be the kind of thing that nobody would be ambivalent about. |
| 23:04 |
jeff |
hbrennan: i don't think so. |
| 23:04 |
hbrennan |
"Krispy Kreme" is their flavor |
| 23:04 |
hbrennan |
haha |
