Time |
Nick |
Message |
03:28 |
|
jeff_ joined #evergreen |
04:22 |
|
eby joined #evergreen |
04:48 |
|
sseng joined #evergreen |
06:48 |
|
kmlussier joined #evergreen |
07:43 |
|
rjackson-isl joined #evergreen |
08:04 |
|
collum joined #evergreen |
08:29 |
|
Shae joined #evergreen |
08:35 |
|
akilsdonk joined #evergreen |
08:45 |
|
kbeswick joined #evergreen |
08:46 |
|
mmorgan1 joined #evergreen |
08:46 |
|
mmorgan1 left #evergreen |
08:46 |
|
mmorgan joined #evergreen |
09:04 |
|
Dyrcona joined #evergreen |
09:08 |
|
Callender joined #evergreen |
09:17 |
|
DPearl joined #evergreen |
09:28 |
|
mrpeters joined #evergreen |
09:41 |
remingtron |
I'm getting an error when trying to clone an Action Trigger. Anyone else seeing this? Server and client are 2.5.0. |
09:41 |
pastebot |
"remingtron" at 64.57.241.14 pasted "Error cloning a Notification / Action Trigger" (1 line) at http://paste.evergreen-ils.org/37 |
09:42 |
remingtron |
happens when I click the "Save" button, in case that isn't clear. |
09:43 |
phasefx |
I'm going to edit some of these old wiki pages for installing EG to point to the Downloads page |
09:45 |
jeff |
remingtron: anything additional in the server logs? do you know if by any chance do you have two ejabberd instances talking to each other? are other pcrud-based interfaces like circ policy / circ matrix editor behaving as you would expect? |
09:46 |
|
yboston joined #evergreen |
09:48 |
remingtron |
jeff: I will investigate |
09:51 |
remingtron |
jeff: open-ils.pcrud ERROR inserting action_trigger::event_definition object |
09:52 |
|
RoganH joined #evergreen |
09:52 |
remingtron |
ERROR: duplicate key value violates unique constraint |
09:52 |
remingtron |
there's our winner |
09:52 |
jeff |
ah, there you go. database level error. |
09:58 |
* dbs |
continues to advocate simply deleting wiki pages that are obsolete |
10:00 |
* dbs |
has donated to archive.org so that things like http://web.archive.org/web/20120629024803/http://evergreen-ils.org/dokuwiki/doku.php?id=server:2.0:install can exist, for those who want to preserve our history |
10:01 |
kmlussier |
dbs: I know erica was going to start a process for deleting wiki pages that started with sending an e-mail to the list to make sure she didn't delete anything that we still need. |
10:02 |
* kmlussier |
just came across one yesterday that looked like a good candidate for deleting. |
10:04 |
* phasefx |
won't cry if folks go deleting wiki pages |
10:06 |
phasefx |
may even want to go as far as requiring that every page has a maintainer/champion to exist |
10:06 |
jeff |
"hey, why is the wiki empty?" |
10:06 |
phasefx |
;) |
10:07 |
kmlussier |
This is the page I thought could go. Seemed a little outdated. http://wiki.evergreen-ils.org/doku.php?id=scratchpad:staff_client_wishlist |
10:10 |
|
mllewellyn joined #evergreen |
10:12 |
remingtron |
Last modified: 2006/11/01 |
10:13 |
phasefx |
and previous history gone |
10:13 |
remingtron |
seven years of dust, probably obsolete |
10:13 |
phasefx |
kill it with fire :) |
10:14 |
csharp |
but what about that feature thingamabob we talked about back then, phasefx? WHAT ABOUT THAT? |
10:15 |
csharp |
fortunately the "we asked for that feature 6 years ago" type talk is mostly nonexistent in PINES nowadays ;-) |
10:16 |
kmlussier |
Dumb question. How DO you delete a page in dokuwiki? |
10:17 |
bshum |
Erase all the contents and save the page. |
10:17 |
* csharp |
is of the opinion that we *shouldn't* |
10:17 |
csharp |
as long as we mark outdated docs as such, I think we should keep everything |
10:17 |
bshum |
The page will be deleted but if someone goes to the url and clicks the history, they can still view what used to be there. |
10:17 |
csharp |
that works |
10:18 |
csharp |
as long as it's somehow preserved |
10:18 |
eeevil |
csharp: you're as big a pack-rat as me! ;) |
10:18 |
csharp |
heh |
10:18 |
remingtron |
Is there a good way to find newly broken links once you delete a wiki page? |
10:19 |
* kmlussier |
will add it to http://wiki.evergreen-ils.org/doku.php?id=scratchpad:pages_that_need_updating_or_revising and let the wiki wrangler sort it out. |
10:19 |
csharp |
as the former curator of old PINES documentation, I know the value of not throwing anything away |
10:20 |
csharp |
plus, I'm not totally convinced one of us won't need all that historical info when we write a book about Evergreen |
10:20 |
phasefx |
and as a former user of deja news... |
10:21 |
yboston |
my two cents is that if we decide to keep old wiki pages, we need to put a large and very obvious note that the page is deprecated. Also with a link to any page that now supersedes it if applicable. For example, I took what phasefx did to that install page and made the text arguer and red http://evergreen-ils.org/dokuwiki/doku.php?id=server:2.0:install (note: the underlying HTML of the warning is kinda ugly) |
10:22 |
yboston |
s/arguer/larger/ |
10:25 |
jeff |
i figured you were going for "angrier" |
10:25 |
dbs |
Maybe a floating modal dialogue that blocks you from reading any of the text and automatically redirects you to the downloads page in 0.001 seconds |
10:27 |
kmlussier |
yboston: The note you now see at the top of http://wiki.evergreen-ils.org/doku.php?id=scratchpad:staff_client_wishlist is what Erica has been using. |
10:29 |
jeff |
dbs: 3 Outdated Wiki Pages Remaining - Subscribe Now for Full Access! |
10:29 |
csharp |
jeff: ha! |
10:29 |
kmlussier |
And this is the agreement we reached at the Oct web team meeting - http://irc.evergreen-ils.org/evergreen/2013-10-17#i_40650 |
10:29 |
csharp |
Evergreen Premium Access™ for only $9.99/month |
10:30 |
csharp |
you can make money AND enemies at the same time! |
10:32 |
csharp |
@dunno add Sorry, that command is only available to Evergreen Premium™ Subscribers. Please upgrade your subscription ASAP! |
10:32 |
pinesol_green |
csharp: The operation succeeded. Dunno #24 added. |
10:33 |
kmlussier |
csharp++ |
10:38 |
RoganH |
csharp: So PTFS is taking over Evergreen too? |
10:39 |
kmlussier |
RoganH: Just the next-generation wiki |
10:39 |
csharp |
kmlussier: beat me to it! |
10:39 |
kmlussier |
:D |
10:39 |
csharp |
kmlussier++ |
10:42 |
|
ericar joined #evergreen |
10:42 |
RoganH |
kmlussier++ |
10:43 |
|
smyers_ joined #evergreen |
10:55 |
jeff |
another day, another NCIP bug to fix. :-) |
10:56 |
|
RoganH joined #evergreen |
10:57 |
|
RoganH joined #evergreen |
11:27 |
|
dMiller__ joined #evergreen |
11:44 |
Dyrcona |
I wish people would stop using the word "deprecated" incorrectly. |
11:44 |
jeff |
Hrm. 2.3 added CAPTURE and FULFILL standing penalty block types. FULFILL prevents checking out a held item. I think a CIRC block would be more common, but I see the difference -- FULFILL block allows other circ, just not circ of a item on the holdshelf for you. |
11:45 |
Dyrcona |
"Deprecated" means still availble, not recommended for use, not being updated, not supported. |
11:45 |
Dyrcona |
It applies to features of programs generally, not to whole releases. |
11:46 |
jeff |
Does anyone here have a specific use case for a FULFILL block? Mostly I'm curious. |
11:46 |
Dyrcona |
Such as php_mysql is deprecated switch to php_mysqli or pdo_mysql. |
11:46 |
Dyrcona |
Not, version 2.0.12 is deprecated, use 2.4. |
11:46 |
Dyrcona |
2.0.x is just dead. |
11:47 |
Dyrcona |
We don't disapprove of 2.0. We disavow all knowledge that it even existed. |
11:47 |
tsbere |
jeff: To ensure someone can't check something on the hold shelf out from a self-check? Though I dunno why you would want to block that but not "grabbed off the shelf"... |
11:47 |
* Dyrcona |
falls off his high horse. |
11:49 |
jeff |
tsbere: no idea. that's why i asked. :-) |
11:51 |
phasefx |
Dyrcona: I'll deprecate my use of deprecate |
11:52 |
Dyrcona |
heh |
11:53 |
* phasefx |
likes keeping things around for historical reasons, and is saddened that, for example, all incarnations of World of Warcraft won't be available to future retro communities. But I can see how these old wiki pages create a support burden for us |
11:54 |
dbs |
Dyrcona: It's like the value of deprecation is depreciating |
11:54 |
Dyrcona |
At least, I avoided the obvious Inigo Montoya reference. |
11:55 |
Dyrcona |
You usually only see it used in terms of code libraries, functions, and interfaces. |
11:55 |
Dyrcona |
Not whole sale versions of things. |
11:56 |
* dbs |
nods |
11:57 |
* Dyrcona |
had caffeine for the first time in over two weeks this morning. Maybe that has something to do with it? |
12:00 |
jcamins |
Dyrcona: maybe people mean that everyone insults 2.0.x? |
12:00 |
jcamins |
@insult 2.0.x |
12:00 |
pinesol_green |
2.0.x: You are nothing but a gleeking tongueful of tottering urine. |
12:00 |
jcamins |
^^ 2.0.x has been deprecated |
12:01 |
Dyrcona |
2.0.x needs to be buried, not insulted. ;) |
12:02 |
jeff |
@decide real data or made up test cases |
12:02 |
pinesol_green |
jeff: Beyond here be dragons. |
12:03 |
jeff |
bah. |
12:05 |
Dyrcona |
@eightball real data or made up test cases? |
12:05 |
pinesol_green |
Dyrcona: _I_ don't know. |
12:06 |
berick |
@eightball does @eightball ever give an answer? |
12:06 |
pinesol_green |
berick: The outlook is good. |
12:07 |
berick |
still feel unsatisfied |
12:08 |
Dyrcona |
Lunch today is homemade tandoori chicken with vegetable korma. |
12:08 |
* Dyrcona |
is very satisfied. |
12:09 |
|
mcooper joined #evergreen |
12:10 |
mrpeters |
mmmm i am so driving for indian food now Dyrcona |
12:11 |
* csharp |
wants chicken tikka masala stat! |
12:24 |
mrpeters |
^^^^ and chicken chili and lemon rice |
12:24 |
mrpeters |
too bad its a long drive in the snow.....im making it anyways! |
12:25 |
berick |
gah, can't even imagine snow... 70's down here |
12:25 |
csharp |
Dyrcona: running the authority batcher - it's excellent |
12:25 |
csharp |
sharing++ |
12:26 |
csharp |
berick: same here - it's sticky and gross |
12:26 |
berick |
csharp: i'm in your neck of the woods this week ;) |
12:26 |
csharp |
turned on the A/C last night for the first time in a couple of months |
12:26 |
mrpeters |
we got alert at 3PM yesterday that 7 inches was coming....was supposed to be an inch of rain but cold front shifted north |
12:26 |
csharp |
ah cool |
12:27 |
mrpeters |
we had almost no warning...it was already sleeting when they put out the winter storm warning |
12:27 |
mrpeters |
and there's more coming until midnight |
12:27 |
csharp |
@weather 30033 |
12:27 |
pinesol_green |
csharp: The current temperature in Glenwood Estates, Decatur, Georgia is 73.4°F (12:27 PM EST on December 06, 2013). Conditions: Overcast. Humidity: 82%. Dew Point: 68.0°F. Pressure: 30.02 in 1016 hPa (Falling). |
12:27 |
csharp |
ick, I say |
12:27 |
mrpeters |
@weather 46060 |
12:27 |
Dyrcona |
csharp: thanks. I'm glad you found it useful, too. |
12:27 |
pinesol_green |
mrpeters: The current temperature in Downtown Noblesville, Noblesville, Indiana is 29.8°F (12:14 PM EST on December 06, 2013). Conditions: Overcast. Humidity: 66%. Dew Point: 19.4°F. Windchill: 30.2°F. Pressure: 30.28 in 1025 hPa (Rising). Winter Storm Warning in effect until midnight EST tonight... |
12:27 |
Dyrcona |
@weather 01845 |
12:27 |
pinesol_green |
Dyrcona: The current temperature in North Andover, Massachusetts is 48.4°F (12:22 PM EST on December 06, 2013). Conditions: Overcast. Humidity: 90%. Dew Point: 46.4°F. Windchill: 48.2°F. Pressure: 29.98 in 1015 hPa (Rising). |
12:27 |
jeff |
@weather ktvc |
12:27 |
pinesol_green |
jeff: The current temperature in Traverse City, Michigan is 19.4°F (11:53 AM EST on December 06, 2013). Conditions: Light Snow. Humidity: 62%. Dew Point: 8.6°F. Windchill: 6.8°F. Pressure: 30.32 in 1026 hPa (Rising). |
12:27 |
mrpeters |
for perspective....hit 67 here this week |
12:28 |
csharp |
whoa - jeff wins! |
12:28 |
jeff |
"wins" |
12:29 |
csharp |
heh |
12:30 |
csharp |
jeff: one of my colleagues with friends in Traverse City was saying it would be a great EG conference destination ;-) |
12:30 |
jeff |
all conferences and hack-a-ways should be held here. |
12:48 |
|
smyers_ joined #evergreen |
12:51 |
bshum |
jeff: Could always submit a proposal for the next site selection committee :) |
13:14 |
bshum |
Dyrcona++ # for Marque.pm |
13:14 |
Dyrcona |
Shh! It isn't ready for prime time, yet. |
13:14 |
* csharp |
was about to ask |
13:15 |
csharp |
Dyrcona: I may have said before, but I'll be happy to test that when you're ready |
13:40 |
|
kmlussier joined #evergreen |
13:48 |
|
akilsdonk joined #evergreen |
13:53 |
kmlussier |
I briefly looked at bug 1234845 on Dyrcona's server a while back, but now I'm giving it closer scrutiny on another server. Could somebody give me some information on where the ranked_volumes function comes into play? Is it related to the way copies are retrieved on the search results page? |
13:53 |
pinesol_green |
Launchpad bug 1234845 in Evergreen "possible optimization for evergreen.ranked_volumes database function" (affected: 2, heat: 12) [Medium,Triaged] https://launchpad.net/bugs/1234845 |
13:57 |
|
stevenyvr2 joined #evergreen |
14:00 |
eeevil |
kmlussier: it is, IIRC |
14:01 |
Dyrcona |
kmlussier: Regarding my server, I am loading all of the dev branches today, so it should be ready for you to look at again this weekend. |
14:01 |
kmlussier |
Dyrcona: Thanks! |
14:03 |
|
dMiller__ joined #evergreen |
14:08 |
jeff |
pickaxe++ |
14:15 |
kmlussier |
eeevil: And based on what you said in e-mail on the list, I want to look at a page like http://training.cwmars.org/opac/extras/browse/rss2-full/item-age/WORP-MAIN to see the effect of bug 1236979? |
14:15 |
pinesol_green |
Launchpad bug 1236979 in Evergreen "Speed up bibs-by-item-age" (affected: 1, heat: 10) [Medium,Confirmed] https://launchpad.net/bugs/1236979 |
14:15 |
Dyrcona |
jeff: *Which* pickaxe? |
14:16 |
jeff |
Dyrcona: -S |
14:16 |
* kmlussier |
assumes so since the difference in performance between the production and test server is very noticeable indeed. |
14:16 |
Dyrcona |
The BitCoin miner, the MMORPG.... |
14:17 |
eeevil |
kmlussier: yes (that's the item-age freshmeat feed). the ranked_volumes change is only part of the fix, of course, the other is an entirely new stored proc that replaces a big query |
14:17 |
jeff |
this pickaxe: git log -SCHECKIN_BYPASS_HOLD_FULFILL --pretty=oneline --abbrev-commit |
14:17 |
jeff |
only one "arg" commit in that history! |
14:18 |
Dyrcona |
;) |
14:18 |
jeff |
commit 90d3fe9 is... odd. i don't know how odd. |
14:18 |
pinesol_green |
[evergreen|evergreen] according to git i've made changes to 950.data.seed-values.sql - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=90d3fe9> |
14:19 |
jeff |
if you request the file at revision 90d3fe9 you get lots of nulls |
14:19 |
pinesol_green |
[evergreen|evergreen] according to git i've made changes to 950.data.seed-values.sql - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=90d3fe9> |
14:19 |
eeevil |
that's scary |
14:19 |
jeff |
i don't know if it's scary if if i'm mis-using git |
14:20 |
jeff |
and that commit hash doesn't show in the history shown with git log Open-ILS/src/sql/Pg/950.data.seed-values.sql |
14:21 |
eeevil |
jeff: hrm... maybe make a fresh clone and see if it's there? |
14:21 |
jeff |
gitweb seems same: http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=90d3fe9 |
14:21 |
pinesol_green |
[evergreen|evergreen] according to git i've made changes to 950.data.seed-values.sql - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=90d3fe9> |
14:21 |
eeevil |
jeff: hrm... I see it in my git log |
14:23 |
eeevil |
committer is weird, too ... |
14:23 |
dbs |
"Binary files a/Open-ILS/src/sql/Pg/950.data.seed-values.sql and b/Open-ILS/src/sql/Pg/950.data.seed-values.sql differ" |
14:23 |
dbs |
Binary? |
14:23 |
eeevil |
maybe just an attribute change? |
14:23 |
eeevil |
yeah |
14:23 |
jeff |
binary, because one of the two revisions of the file is all-null. |
14:23 |
dbs |
Looks like a commit made from a virtual machine |
14:24 |
Dyrcona |
Looks like an oops. |
14:24 |
eeevil |
jeff: Bin 616724 -> 616724 bytes suggests no change |
14:24 |
Dyrcona |
so does the previous commit. |
14:24 |
jeff |
because it's 616724 null bytes. :-) |
14:25 |
eeevil |
Dyrcona: the merge? |
14:25 |
jeff |
the size is the same but the hash is different |
14:25 |
* csharp |
sees "contains zero-padded file modes" for a few trees using git fsck |
14:25 |
csharp |
doubting that's related |
14:25 |
Dyrcona |
Yeah, looks like it was done on the same vm and then pushed, maybe later. |
14:26 |
jeff |
yeah. we have some permanent (unless we want to break every commit hash) warnings in the Evergreen repo due to some old git bugs, or old got win32 client bugs. |
14:28 |
jeff |
eeevil: you said that commit shows in your git log -- does it show in git log --pretty=oneline --abbrev-commit -- Open-ILS/src/sql/Pg/950.data.seed-values.sql |
14:28 |
pastebot |
"eeevil" at 64.57.241.14 pasted "commits by this user" (6 lines) at http://paste.evergreen-ils.org/38 |
14:29 |
eeevil |
jeff: not when I point at the file directly, nope |
14:29 |
jeff |
according to research done at some point: Robin Isard <robin.isardalgomau.ca> <evergreensqueeze.debian> |
14:29 |
jeff |
that seems potentially incorrect, just based on the equinox branch that was merged. |
14:30 |
eeevil |
doesn't seem be causing a problem, per se. I guess we could rebase it out of the universe |
14:30 |
gmcharlt |
csharp: the zero-padded file modes thing is a legacy of doc commits once living in GitHub and being edited directly there; or to be more precise, the bug in GitHub's implementation of Git that was exercised |
14:30 |
jeff |
i don't think we could without impacting every commit hash since. it probably isn't a problem, i just found it odd and didn't leave it go. sorry. :-) |
14:31 |
jeff |
gmcharlt++ i remember looking into that and it being some third-party implementation, forgot it was github |
14:32 |
mmorgan |
I feel I should know this. asset.copy.price vs. asset.copy.cost? |
14:32 |
jeff |
mmorgan: price is list price used when billing a patron for a lost item, etc. |
14:33 |
gmcharlt |
it's an annoyance at present; in principle we could recrate the repo and clean it up, but it's not presently worth the pain that would cause to every last clone of the repo |
14:33 |
jeff |
mmorgan: cost may only be filled in if you're using acq, and represents the cost the library paid. |
14:33 |
jeff |
mmorgan: internally we have need/desire to backfill asset.copy.cost, and i've thought about making a way for that value to be editable. not sure if that will be found acceptable to others. |
14:35 |
|
dMiller___ joined #evergreen |
14:35 |
mmorgan |
jeff: OK, thanks. I thought "price" was the one that was pertinent to circ billing. Does "price" get filled in automatically as part of acq? |
14:38 |
phasefx |
I didn't know the OpenLibrary API offered author photos. neat |
14:39 |
* bshum |
just realized we've had some new releases... |
14:39 |
bshum |
I'm going to make new milestones and do some bug wrangling |
14:39 |
kmlussier |
mmorgan: No, it doesn't. |
14:40 |
mmorgan |
kmlussier: Thanks, so price has to be entered by the staff member processing the item. |
14:41 |
kmlussier |
mmorgan: That's my recollection. |
14:44 |
mmorgan |
Thanks for confirming! |
14:47 |
jeff |
mmorgan: for circ-related billings, there's also a default price that can be specified per library. |
14:48 |
jeff |
mmorgan: i don't believe that results in the price field being populated, but instead is used when there is no price listed. |
14:50 |
mmorgan |
jeff: Thanks, we have a library that charges $50 for anything lost, but I find many of their items have the price field filled in. So some bills are coming through with the price instead of $50. |
14:50 |
mmorgan |
So I think we need to blank out the prices in the items and instruct them to not enter the price when they add the item. |
14:52 |
csharp |
mmorgan: yes, the price is entered at the time of cataloging |
14:53 |
jeff |
seems a shame to delete that data. |
14:54 |
jeff |
it's useful for other things, like "you checked out $123.45 worth of material today" |
14:55 |
jeff |
but given current code, there's not a great way to force bill a set price for items. |
14:55 |
csharp |
sounds like a feature request: charge a standard replacement cost rather than entered price |
14:55 |
jeff |
you can set a lost material processing fee of $50 and void the item price charge. |
14:56 |
jeff |
or "minimum lost item fee" |
14:56 |
csharp |
could probably use the same underpinnings as "charge lost on zero" |
14:57 |
jeff |
mmorgan: flesh out the idea a bit more and open a wishlist bug describing things -- it may very well make a useful feature in the next version of Evergreen. :-) |
14:58 |
mmorgan |
jeff: will do! In our previous system we had to blank out prices, too, but it would be useful not to have to do that. |
14:58 |
jeff |
also, any idea why the library charges a $50 fixed fee for every lost item? |
15:02 |
* dbs |
dreads losing a Mr. Men book. |
15:02 |
mmorgan |
Not sure of all the full reasoning behind it. It's an academic library, and it may have something to do with the bursar, but I can't say for sure. |
15:02 |
jeff |
i was going to ask if they were academic. :-) |
15:03 |
jeff |
the last academic i ILLd a book from billed $100/book before they were even due. :-) |
15:03 |
jeff |
(which was partially due to delays between them shipping it and it actually being checked out to me) |
15:03 |
gmcharlt |
jeff: ILL, IRS, guess not much difference ;) |
15:04 |
|
Guest41307 joined #evergreen |
15:04 |
jeff |
gmcharlt: *grin* |
15:04 |
* gmcharlt |
can imagine the article: "ILL departments as profits centers" |
15:05 |
bshum |
Alright, I'm done spamming everybody today with bug shifting |
15:06 |
bshum |
I didn't create another milestone for 2.3 |
15:06 |
dbwells |
mmorgan: Perhaps this is what you want: https://bugs.launchpad.net/evergreen/+bug/1207903 |
15:06 |
pinesol_green |
Launchpad bug 1207903 in Evergreen "Lost billing amounts should be more configurable" (affected: 1, heat: 6) [Wishlist,Triaged] |
15:06 |
bshum |
Unless we do encounter security bugs to release for, I figure we can end it there |
15:06 |
dbwells |
We are also a "crazy academic" who charges a flat $50 lost book fee. |
15:06 |
csharp |
bshum++ |
15:07 |
dbwells |
The reasoning for us is binding costs. It makes replacement costs not as simple as the cost of the item itself, so we attempt to just average it all out. |
15:07 |
jcamins |
gmcharlt: I saw that article, except it was in a bookseller's rag, and entitled "ILL as a marketing tool." |
15:07 |
csharp |
dbwells: makes sense |
15:08 |
gmcharlt |
jcamins: oh dear |
15:08 |
csharp |
from a public library perspective, I was just imagining having conversations across the circ desk about $50 per item |
15:08 |
* csharp |
cringes |
15:08 |
gmcharlt |
csharp: before or after the bulletproof glass is installed? |
15:08 |
csharp |
gmcharlt: exactly! |
15:08 |
mmorgan |
dbwells: That sounds like it would do the trick! |
15:09 |
dbwells |
We wrote the feature in bug 1207903 as a "min/max" dual setting to potentially cover more cases, but we just set them both the same to achieve the fixed cost. |
15:09 |
pinesol_green |
Launchpad bug 1207903 in Evergreen "Lost billing amounts should be more configurable" (affected: 1, heat: 6) [Wishlist,Triaged] https://launchpad.net/bugs/1207903 |
15:14 |
mmorgan |
dbwells++ |
15:15 |
mmorgan |
Back to the "cost" field for a moment. Is that not visible anywhere in the client? Just for reporting? |
15:19 |
jeff |
it is not visible in the client when viewing a copy. it may be visible somewhere in Acq. it can be reported on. |
15:19 |
jeff |
at our library, we intend to move item cost from a copy note to asset.copy.cost and use it for reporting collection value / depreciation |
15:31 |
jeff |
dbwells++ remingtron++ for bug 1207903. Looks good at a quick glance. Any reason I shouldn't give it a test and commit to master sometime this weekend? |
15:31 |
pinesol_green |
Launchpad bug 1207903 in Evergreen "Lost billing amounts should be more configurable" (affected: 2, heat: 10) [Wishlist,Triaged] https://launchpad.net/bugs/1207903 |
16:18 |
|
dMiller__ joined #evergreen |
16:44 |
smyers_ |
I have a z39.50 problem and was wondering if someone would be willing to help find the issue |
16:47 |
Dyrcona |
smyers_: Just ask. If anyone can help, they most likely will. |
16:47 |
smyers_ |
ok so I can use yaz-client and set sru GET 1.1 and find things when pointed to http://catalog.kcls.org/opac/extras/sru |
16:48 |
smyers_ |
but when I point to http://evgtest.kcls.org/opac/extras/sru |
16:48 |
smyers_ |
it just returns |
16:48 |
smyers_ |
like it crashed |
16:49 |
Dyrcona |
You mean the client just returns as if the server connection dropped? |
16:49 |
smyers_ |
yes |
16:50 |
smyers_ |
Z> open http://evgtest.kcls.org/opac/extras/sru |
16:50 |
smyers_ |
Connecting...OK. |
16:50 |
smyers_ |
Z> sru GET 1.1 |
16:50 |
smyers_ |
Z> find hemingway |
16:50 |
smyers_ |
Z> |
16:51 |
Dyrcona |
What happens if you do a SRU request via parameters in a browser to evgtest? |
16:51 |
Dyrcona |
Just hitting the URL retuns something. |
16:51 |
smyers_ |
works great |
16:51 |
smyers_ |
yep |
16:51 |
smyers_ |
http://evgtest.kcls.org/opac/extras/sru?version=1.1&operation=searchRetrieve&query=hemingway&maximumRecords=0 |
16:52 |
smyers_ |
open http://catalog.kcls.org/opac/extras/sru |
16:52 |
smyers_ |
Connecting...OK. |
16:52 |
smyers_ |
Z> sru GET 1.1 |
16:52 |
smyers_ |
Z> find hemingway |
16:52 |
smyers_ |
Received SRW SearchRetrieve Response |
16:52 |
smyers_ |
Number of hits: 733 |
16:52 |
smyers_ |
pos=1 schema=info:srw/schema/1/marcxml-v1.1 |
16:52 |
smyers_ |
and that is from the same box just changing the source |
16:53 |
Dyrcona |
Yep. Returns records for me, and I notice the first contains a lot of our beloved Vietnamese. |
16:53 |
|
b_bonner_ joined #evergreen |
16:53 |
jeff |
whee... marking syntactically-improbable email addresses as invalid! |
16:53 |
Dyrcona |
Sorry the second record. |
16:54 |
smyers_ |
so maybe an encode problem? |
16:56 |
Dyrcona |
Maybe. |
16:56 |
Dyrcona |
I think you can tell yaz-client to expect and request utf-8 can't you? |
16:57 |
Dyrcona |
If the problem were the server, I'd expect hitting the URL with a browser to fail, unless it is failing to convert the record to another charset. |
16:57 |
Dyrcona |
ie. if yaz-client is asking for marc 8 or is8859 for instance, but the browser says, I'll take utf-8. |
16:58 |
smyers_ |
setting the charset to utf-8 didn't change the results |
16:59 |
smyers_ |
and I get the same restuls as in nothing when trying to find fkajshfkuwehlfawuhf which sould have 0 results |
16:59 |
Dyrcona |
I thought that was German for a second. :) |
16:59 |
smyers_ |
lol |
17:00 |
Dyrcona |
Have you checked the logs on evgtest for anything related to SRU? |
17:00 |
smyers_ |
the odd thing is as soon as I point this at the production environment I get results |
17:00 |
Dyrcona |
Well, something is different. You also get different results from the two environments in the browser. |
17:01 |
smyers_ |
that would be expected to some degree as the databases are different |
17:01 |
Dyrcona |
Is the test environment a copy of production? If not, you should go over what makes it different. |
17:01 |
smyers_ |
the underlying data is older but that should be it |
17:02 |
|
mrpeters left #evergreen |
17:02 |
Dyrcona |
I've had lots of fun migrating Vietnamese records this year and pestered gmcharlt with sample files, that every time I see Vietnamese like that, I tend to blame charset issues. |
17:03 |
smyers_ |
lets eleminate charset and use something that gets the same results then |
17:03 |
Dyrcona |
I think first you should see if you have the same versions of the relevant Perl modules installed. |
17:03 |
smyers_ |
this query gets the same via the opac |
17:03 |
smyers_ |
?version=1.1&operation=searchRetrieve&query=asdf&maximumRecords=0 |
17:04 |
Dyrcona |
Yeah, it returns the empty result set. |
17:05 |
smyers_ |
open http://evgtest.kcls.org/opac/extras/sru |
17:05 |
smyers_ |
Connecting...OK. |
17:05 |
smyers_ |
Z> sru GET 1.1 |
17:05 |
smyers_ |
Z> find asdf |
17:05 |
smyers_ |
Z> open http://catalog.kcls.org/opac/extras/sru |
17:05 |
smyers_ |
Connecting...OK. |
17:05 |
smyers_ |
Z> find asdf |
17:05 |
smyers_ |
Received SRW SearchRetrieve Response |
17:05 |
smyers_ |
Number of hits: 0 |
17:05 |
smyers_ |
Elapsed: 0.036037 |
17:05 |
smyers_ |
any ideas what could cause that |
17:06 |
smyers_ |
and nothing in osrfsys.log |
17:07 |
Dyrcona |
Not off the top of my head. Perhaps something is missing on evgtest? |
17:09 |
smyers_ |
that's the fun part trying to figure out what |
17:09 |
Dyrcona |
I suspect your yaz-client. |
17:09 |
Dyrcona |
I'll paste what I got. |
17:10 |
smyers_ |
k |
17:11 |
pastebot |
"Dyrcona" at 64.57.241.14 pasted "my yaz-client results" (9 lines) at http://paste.evergreen-ils.org/39 |
17:11 |
Dyrcona |
So, it works for me. Let me check the client version. |
17:12 |
jeff |
also appears to work for me: YAZ version: 5.0.2 9555e682b2e9e018092fb92a4abd43e11d4fedb7 |
17:12 |
Dyrcona |
YAZ version: 5.0.4 5b048b45e49be6a0af7cb17dee0c49da9074f013 |
17:12 |
smyers_ |
yeah I have a yaz-client 4.2.18 that can work with both |
17:12 |
jeff |
5.0.4 appears to be current |
17:13 |
Dyrcona |
Well, I updated yesterday, so... |
17:14 |
jeff |
smyers_: which version fails for you? |
17:14 |
smyers_ |
3.0.47 |
17:15 |
smyers_ |
and 3.0.34 |
17:15 |
jeff |
yeah, those are from 2008 and 2009. there's probably little benefit in trying to make them work, if more recent versions do work. |
17:16 |
jeff |
but your environment and advantages may vary |
17:16 |
Dyrcona |
We had lots of issues with yaz package on Ubuntu 12.04. We switched to using the packages from indexdata's PPA. |
17:16 |
jeff |
http://www.indexdata.com/yaz/doc/NEWS is the changelog which might have clues as to the exact change that makes newer versions work. |
17:16 |
smyers_ |
Dyrcona: do those work with simple2zoom out of the box? |
17:17 |
Dyrcona |
smyers_: Our simple2zoom didn't work until we switched, so I'd say yes. |
17:17 |
smyers_ |
the reason for trying to get this to work is that when I start my simple2zoom server I get error 100 on stage and results on prod |
17:17 |
|
mmorgan left #evergreen |
17:17 |
smyers_ |
and the only change I am making is the zurl |
17:18 |
Dyrcona |
what's the difference between the two servers? Sounds like they don't have the same package versions at least. |
17:19 |
Dyrcona |
smyers_: If you get the daily system emails from your evgtest server you might want to look for reports of segfaults or similar for simple2zoom or related. (I forget the exact error and software.) |
17:20 |
Dyrcona |
You will likely also see them in /var/log/syslog or dmesg (possibly). |
17:21 |
Dyrcona |
One of our symptoms was simple2zoom would return the first screen full of results, then crash when the client requested the next X records. |
17:21 |
dbwells |
jeff: Sorry for the late response re:bug 1207903, but if you like it, commit away. |
17:21 |
pinesol_green |
Launchpad bug 1207903 in Evergreen "Lost billing amounts should be more configurable" (affected: 2, heat: 10) [Wishlist,Triaged] https://launchpad.net/bugs/1207903 |
17:21 |
Dyrcona |
Of course, that is the z39.50 server and not exactly your issue with SRU. |
17:21 |
* dbwells |
goes home |
17:21 |
jeff |
dbwells: thanks! nite! |
17:23 |
* Dyrcona |
should probably get more active in the Ubuntu community and possibly take over packaging some of these things. |
17:24 |
kmlussier |
Dyrcona: In your spare time? :) |
17:24 |
Dyrcona |
kmlussier: What is this "spare time?" I would like to subscribe to your newsletter. |
17:28 |
Dyrcona |
Well, it is time for me to go, also. |
17:29 |
Dyrcona |
Good luck, smyers_! |
17:29 |
smyers_ |
Dyrcona: thanks you have been a great help |
18:02 |
|
kbeswick joined #evergreen |
18:57 |
|
msteinholz joined #evergreen |
19:16 |
|
stevenyvr2 left #evergreen |
19:24 |
* jeff |
goes looking to see how cpanr recommends including data files |
19:42 |
jeff |
cpan, even |
19:59 |
|
smyers_ joined #evergreen |
21:22 |
|
kbeswick joined #evergreen |
21:44 |
|
stevenyvr2 joined #evergreen |
21:45 |
|
stevenyvr2 left #evergreen |