| Time |
Nick |
Message |
| 01:29 |
|
dcook__ joined #evergreen |
| 07:04 |
|
Arlene joined #evergreen |
| 07:41 |
|
jboyer-isl joined #evergreen |
| 07:53 |
|
TaraC joined #evergreen |
| 07:56 |
|
rjackson_isl joined #evergreen |
| 08:03 |
|
graced joined #evergreen |
| 08:06 |
|
ericar joined #evergreen |
| 08:13 |
|
Arlene joined #evergreen |
| 08:20 |
|
jboyer-isl joined #evergreen |
| 08:25 |
|
collum joined #evergreen |
| 08:29 |
|
julialima_ joined #evergreen |
| 08:31 |
|
sarabee joined #evergreen |
| 08:32 |
|
Dyrcona joined #evergreen |
| 08:36 |
Dyrcona |
Oh lovely. Kernel updates. BBL. |
| 08:38 |
|
mmorgan joined #evergreen |
| 08:40 |
|
krvmga joined #evergreen |
| 08:44 |
krvmga |
i'm still trying to do a 2.7.3 install and am having problems. when i run settings-tester, it tells me to install Net::Z3950::Simple2ZOOM |
| 08:44 |
krvmga |
when i cpan Net::Z3950::Simple2ZOOM, it tells me it needs Net::Z3950::SimpleServer |
| 08:45 |
krvmga |
when i cpan Net::Z3950::SimpleServer, the install fails because |
| 08:45 |
krvmga |
You have YAZ version 4.2.32; you need 4.2.51 or better. |
| 08:45 |
krvmga |
what kind of rabbit hole have i fallen down here? |
| 08:46 |
|
Shae joined #evergreen |
| 08:46 |
krvmga |
i'm on debian-wheezy |
| 08:46 |
krvmga |
wheezy tells me i have the latest version of yaz |
| 08:46 |
krvmga |
and complains if i try to install a newer version |
| 08:48 |
krvmga |
quel frustrate! |
| 08:53 |
|
Dyrcona joined #evergreen |
| 08:58 |
|
Arlene joined #evergreen |
| 09:00 |
phasefx |
krvmga: the Makefile.install debian-wheezy step didn't pull those in? |
| 09:02 |
krvmga |
phasefx: it said "Make had some problems, won't install" |
| 09:03 |
krvmga |
it gave an error at Makefile.PL line 23 related to the yaz version |
| 09:03 |
krvmga |
and also said /usr/bin/perl Makefile.PL INSTALLDIRS=site -- NOT OK |
| 09:05 |
|
mrpeters joined #evergreen |
| 09:06 |
phasefx |
krvmga: here's output from a debian wheezy Makefile.install run from this morning for comparison: http://testing.evergreen-ils.org/~live/test.8.html |
| 09:07 |
|
Newziky joined #evergreen |
| 09:10 |
pastebot |
"krvmga" at 64.57.241.14 pasted "attempt to install Net::Z3950::Simple2ZOOM with required SimpleServer" (201 lines) at http://paste.evergreen-ils.org/37 |
| 09:10 |
krvmga |
phasefx: you can see what happened to me at the command line at that paste. |
| 09:10 |
|
sarabee joined #evergreen |
| 09:11 |
phasefx |
krvmga: try the debian package for those instead? |
| 09:12 |
krvmga |
it's worth a shot |
| 09:13 |
phasefx |
libnet-z3950-simpleserver-perl, libnet-z3950-zoom-perl, libnet-z3950-simple2zoom-perl, libyaz4, libyaz4-dev, yaz |
| 09:14 |
phasefx |
here's settings-tester output from the same instance: http://testing.evergreen-ils.org/~live/test.23.html |
| 09:15 |
phasefx |
ah, here's something that needs some red highlighting: Please install Business::CreditCard::Object |
| 09:16 |
phasefx |
unrelated to your troubles |
| 09:20 |
jonadab |
The first failure I see in that first pastebin is Business::Stripe, I think. |
| 09:21 |
jonadab |
Which, hmm... current version of that hasn't changed since 2012 October. |
| 09:22 |
Dyrcona |
krvmga: You did sudo when you ran the Makefile.install step, right? |
| 09:22 |
krvmga |
Dyrcona: yes |
| 09:22 |
krvmga |
i was already the superuser |
| 09:23 |
krvmga |
Business::CreditCard::Object installed without issue |
| 09:23 |
Dyrcona |
Ok. Just making sure. 'Cause not being root would cause issues. |
| 09:30 |
krvmga |
ok, here's what happened. |
| 09:31 |
krvmga |
i installed Net::Z3950::SimpleServer directly from source and not with span; success |
| 09:31 |
krvmga |
then cpan Net::Z3950::Simple2ZOOM installed; success |
| 09:32 |
krvmga |
side-stepped the whole yaz thing |
| 09:33 |
Dyrcona |
It won't work without yaz, y'know. |
| 09:34 |
csharp |
I'm trying to track down how hold status is determined in the "Holds" tab of the patron screen... |
| 09:35 |
jeff |
csharp: it's calculated in the api. what are you trying to track down? i'll point you to a line/sub in a sec. |
| 09:35 |
csharp |
I've traced it to Open-ILS/xul/staff_client/server/circ/util.js beginning at line 1933 (on 2.7.2) |
| 09:36 |
csharp |
jeff: specifically, I'm trying to track down what constitutes "Ready for pickup" and how it might differ from the way the summary counts determine that |
| 09:37 |
csharp |
summary says "where usr = <the actual user id> and fulfillment_time is null and cancel_time is null" |
| 09:37 |
csharp |
and also checks whether the current_shelf_lib matches the pickup_lib |
| 09:37 |
csharp |
we have a hold that is showing "Ready for pickup" but that is not reflected in the summary count |
| 09:37 |
jeff |
ah. |
| 09:38 |
csharp |
and in this hold's case, the current_shelf_lib is null, so no match, so it's not counted as "available" |
| 09:40 |
tsbere |
Wait, "Ready for pickup" without the current_shelf_lib set? |
| 09:41 |
csharp |
tsbere: correct |
| 09:42 |
* csharp |
usually suspects staff action as the cause of this kind of weirdness. |
| 09:42 |
csharp |
if I can determine a pattern, I'll develop a query to find others |
| 09:42 |
jeff |
yeah, looks like OpenILS::Application::Circ::Holds::_hold_status would return "4" (Ready for Pickup) in that case. |
| 09:43 |
|
yboston joined #evergreen |
| 09:43 |
tsbere |
So it would. It doesn't care about the current shelf lib at all, actually. |
| 09:44 |
tsbere |
That may be a bug. |
| 09:44 |
* csharp |
thinks it is |
| 09:44 |
jeff |
wait, but that's what the summary count seems to use, so that wouldn't explain what you're seeing. |
| 09:44 |
csharp |
hold is showing "Ready for pickup" in the list, but the summary count says 0 holds are ready |
| 09:45 |
krvmga |
Dyrcona: i think what got sidestepped was the need for the version difference in yaz. |
| 09:46 |
mmorgan |
csharp: is there a current_copy in the hold? |
| 09:46 |
csharp |
mmorgan: yes |
| 09:46 |
mmorgan |
What's its status? |
| 09:46 |
tsbere |
Does the summary count use the ID_LIST functions? If so, those check the current_shelf_lib... |
| 09:46 |
csharp |
mmorgan: "On holds shelf" |
| 09:46 |
tsbere |
(for "give me the list of available holds" lists) |
| 09:47 |
phasefx |
so patron summary uses open-ils.actor.user.hold_requests.count, and that doesn't use _hold_status, but a json query |
| 09:47 |
* csharp |
isn't familiar with ID_LIST functions :-/ |
| 09:47 |
mmorgan |
Hmm. Is it a title level hold, and does the record the copy is linked to match the target in the hold? |
| 09:48 |
phasefx |
and it's filtering out holds where pickup lib doesn't match current shelf lib |
| 09:48 |
|
kbutler joined #evergreen |
| 09:48 |
csharp |
mmorgan: yes and yes |
| 09:49 |
tsbere |
phasefx: Or current_shelf_lib isn't set |
| 09:49 |
phasefx |
right |
| 09:49 |
csharp |
phasefx: tsbere: yeah, current_shelf_lib is null |
| 09:49 |
tsbere |
Hmmm. For fun: If current_shelf_lib is 0 (shouldn't happen normally, but if someone manually messes with the org tree to add an id 0...) it would never show up as ready by that check. |
| 09:49 |
phasefx |
csharp: so that's happening in Actor.pm, sub hold_request_count |
| 09:50 |
csharp |
phasefx: right - I had tracked that piece - now looking at how the status is determined in the holds list |
| 09:51 |
phasefx |
csharp: sorry, mis-skimmed :) |
| 09:51 |
csharp |
no prob ;-) |
| 09:51 |
jeff |
looking at rel_2_7: line 85 of Open-ILS/xul/staff_client/server/patron/holds.js shows FM_AHR_BLOB_RETRIEVE being the API call (that's a constant, defined as open-ils.circ.hold.details.retrieve in constants.js). |
| 09:53 |
jeff |
that api call is defined in Open-ILS/src/perl/lib/OpenILS/Application/Circ/Holds.pm in the "uber_hold" sub. chasing subs to see where the status is deterined gets you uber_hold -> uber_hold_impl -> retrieve_hold_queue_status_impl -> _hold_status |
| 09:55 |
jeff |
that sub contains logic on status -- of course, the statuses are numeric. :-) |
| 09:55 |
|
eeevil joined #evergreen |
| 09:56 |
csharp |
jeff: thanks - I think this is getting me what I'm after |
| 09:57 |
phasefx |
server/locale/en-US/circ.properties has the strings for those statuses, staff.circ.utils.hold_status.1, .2, etc |
| 09:58 |
jeff |
there's a comment in the siangture for open-ils.circ.hold.status.retrieve that maps -1 and 1-8 to a description of status, but you'll note that "4 for 'arrived'" doesn't jump out at you as being "Ready for pickup" -- you'll want to look at the hold_status lines in Open-ILS/xul/staff_client/server/locale/en-US/circ.properties for the status messages you're used to seeing in the client. |
| 09:58 |
jeff |
"signature" |
| 09:59 |
jeff |
and you were already looking at xul/staff_client/server/circ/util.js where there's a switch statement to turn 1-8 into their textual status, and fall through anything else (which usually would just be the -1 / error status) |
| 10:00 |
jeff |
none of that directly answers your question, but you can probably catch a new kind of fish now. :-) |
| 10:02 |
Dyrcona |
dependencies-- |
| 10:05 |
kbutler |
If someone accidentally deleted a bunch of items from a bib record, is there an easy way to get those items back? |
| 10:06 |
|
ningalls joined #evergreen |
| 10:09 |
jeff |
kbutler: someone with database access can "undelete" the copies and (if needed) call numbers / volumes. it gets complicated if new volumes or copies that could conflict with the deleted ones have been created since the deletion. |
| 10:11 |
|
sarabee joined #evergreen |
| 10:12 |
Dyrcona |
See, staff complain that Evergreen doesn't really delete copies, then they're happy when we can resurrect them. |
| 10:12 |
csharp |
jeff++ # thanks! |
| 10:12 |
kbutler |
jeff: Thanks. It just happened this morning so we should be safe from conflicts. |
| 10:21 |
jonadab |
Dyrcona: the end user desire for deletion as a feature has not been rational since the price of disk space dropped out of the stratosphere in the late eighties. |
| 10:21 |
jonadab |
But some people just have an emotional need to "clean up" and "throw old stuff away". |
| 10:22 |
|
jwoodard joined #evergreen |
| 10:22 |
Dyrcona |
jonadab: A lot of end user desire is irrational, and in fact the root of the word desire comes from the opposite of irrational in Latin. |
| 10:22 |
bshum |
Deleting something in Evergreen takes up more storage than it does to just leave it be. Ironic, really. |
| 10:22 |
Dyrcona |
Oops. Opposite of rational. |
| 10:22 |
jonadab |
bshum: Makes sense, really. |
| 10:23 |
jonadab |
Because for obvious reasons if you let end users delete things you NEED a way to undelete them. |
| 10:28 |
Dyrcona |
With Postgres, you end up with "empty" rows in storage. They will eventually get filled in or cleaned if you vacuum the tables. |
| 10:28 |
Dyrcona |
Same thing happens with updates. |
| 10:28 |
jwoodard |
This is a stupid question but the what is the difference between "greater than but equal to", "greater than" and "between" filters when say running a monthly circ report? |
| 10:29 |
Dyrcona |
jwoodard: I believe greater than means "greater than but not equal to" |
| 10:29 |
Dyrcona |
Between means between value x and y including x and y. |
| 10:29 |
jwoodard |
I am getting conflicting numbers for my annual report and it has resulted in several cups of tea disappearing this morning. |
| 10:30 |
Dyrcona |
So, between 1 and 5, includes everything from 1 to 5. |
| 10:31 |
Dyrcona |
That "but" in "greater than but equal to" should probably be "and." |
| 10:31 |
Dyrcona |
Or, maybe an "or." |
| 10:32 |
Dyrcona |
jwoodard: Does that help? |
| 10:33 |
jwoodard |
Dyrcona: Thank you! I was having a moment of madness with reports and need clarification. |
| 10:34 |
|
sandbergja joined #evergreen |
| 10:36 |
jonadab |
Indeed, "greater than or equal to" makes more obvious sense. The other was reminding me of "0 but true". |
| 10:38 |
eeevil |
bah, 0E0 isn't a valid nick... |
| 10:57 |
|
phaverkamp joined #evergreen |
| 10:57 |
phaverkamp |
hello all, seems library of congress has chosen marcxml records |
| 10:57 |
phaverkamp |
anyway to import those records into evergreen? |
| 10:58 |
phaverkamp |
or a conversion tool out there? |
| 10:59 |
tsbere |
phaverkamp: I will point out that Evergreen uses that internally as well, as far as I know. |
| 11:00 |
phaverkamp |
what do you mean internally? |
| 11:01 |
tsbere |
Evergreen's DB-side storage of MARC is, I believe, marcxml |
| 11:02 |
phaverkamp |
i see |
| 11:03 |
|
vlewis joined #evergreen |
| 11:05 |
Dyrcona |
marcxml in UTF-8 goes in really well. |
| 11:05 |
Dyrcona |
No conversion needed. |
| 11:05 |
phaverkamp |
http://www.loc.gov/standards/marcxml/ |
| 11:05 |
|
Shae joined #evergreen |
| 11:05 |
phaverkamp |
AH nic |
| 11:06 |
Dyrcona |
Of course we flatten it, and have a preferred method of doing so, but the standard import tools will do that for you. |
| 11:07 |
phaverkamp |
i havent got a install going yet, but my goal to help the single librarian, is to find a place online that has marc records for the books she has that she can just grab |
| 11:07 |
phaverkamp |
and wam bam, import |
| 11:08 |
Dyrcona |
You can import records from Library of Congress via Z39.50 in the staff client. |
| 11:08 |
Dyrcona |
You can set up new Z39.50 targets. |
| 11:08 |
phaverkamp |
ok ill research that thanks! |
| 11:09 |
Dyrcona |
You can import from OCLC, if you have an account. |
| 11:09 |
phaverkamp |
i was looking at them also |
| 11:09 |
phaverkamp |
i suspect they are not cheap? |
| 11:22 |
Dyrcona |
I don't know. I don't pay the bills. |
| 11:22 |
phaverkamp |
hhah, fair enough |
| 11:23 |
phaverkamp |
thanks for you the input |
| 11:23 |
kmlussier |
phaverkamp: Library of Congress is a good source for books, but if the library you're working with has a lot of DVD's, you may need another source for those records. |
| 11:24 |
phaverkamp |
kmlussier, just books, 700-800 books, highschool library |
| 11:24 |
Dyrcona |
High school library, and you chose Evergreen because? |
| 11:24 |
phaverkamp |
well i havent fully decided yet |
| 11:25 |
Dyrcona |
Evergreen is a big system, not saying it won't work for you, there are smaller libraries using it. |
| 11:25 |
phaverkamp |
they school basically wants to spend $0, i figure a robust open system would be a place to start |
| 11:25 |
Dyrcona |
I always recommend people look around. |
| 11:25 |
Dyrcona |
I'd recommend looking at Koha, too. |
| 11:25 |
phaverkamp |
but the school is the one that brought it up |
| 11:25 |
phaverkamp |
evergreen that is |
| 11:27 |
Dyrcona |
Not that Koha isn't big, either, but it might be a better fit depending on their needs. |
| 11:27 |
phaverkamp |
ok yeah koha looks like a possibility too |
| 11:28 |
|
Shae joined #evergreen |
| 11:45 |
Bmagic |
kmlussier: do you have the bug assignments for us sandbox providers? |
| 11:49 |
|
bmills joined #evergreen |
| 11:49 |
kmlussier |
Bmagic: No |
| 11:49 |
kmlussier |
Bmagic: Because nobody knew to request them until yesterday. |
| 11:50 |
kmlussier |
I'm sending an email now. I had hoped to send something out first thing in the morning, but I had a meeting. |
| 11:50 |
* hopkinsju |
tunes in |
| 11:50 |
* kmlussier |
reads hopkinsju's email now. :) |
| 11:51 |
hopkinsju |
If we don't hear back, or don't get enough, we could just find launchpad bugs tagged pullrequest and a high "heat" or whatver |
| 11:51 |
kmlussier |
I'll ask people to submit their requests by the end of the day today. |
| 11:51 |
kmlussier |
Anything that comes later can be added to a MassLNC sanbox. |
| 11:52 |
kmlussier |
Sorry guys! I dropped the ball on planning this time around. |
| 11:57 |
jboyer-isl |
Can anyone answer a fines related question for me before I find the answer in fine-generator.pl? If a closed date is deleted will those old fines be recreated, (this is after the closing has already past and fines are already being generated) or would they have to be generated "manually," be that by staff client or databasery? |
| 12:01 |
jboyer-isl |
Bah, nevermind. These will likely have a stop_fines reason, so it doesn't matter. :-/ |
| 12:07 |
|
dMiller_ joined #evergreen |
| 12:07 |
eeevil |
jboyer-isl: they'll be created IFF there are no fines generated past the end of the now-deleted closing |
| 12:08 |
eeevil |
jboyer-isl: the fine generator looks at the last fine timestamp and works forward from there |
| 12:08 |
jboyer-isl |
That's what I thought. These will all have fines generated after the end of the closed period, so it's datamancy or bust. :/ |
| 12:12 |
jboyer-isl |
Pah, there's 8 effected circs. staff client it is. |
| 12:16 |
eeevil |
:) |
| 12:19 |
kmlussier |
mrpeters: Can I remove you from the Assigned To column for bug 1154656? |
| 12:19 |
pinesol_green |
Launchpad bug 1154656 in Evergreen 2.4 "MARC Expert Search "Add Rows" adds duplicate row" (affected: 5, heat: 24) [Medium,Confirmed] https://launchpad.net/bugs/1154656 |
| 12:20 |
mrpeters |
Absolutely |
| 12:20 |
mrpeters |
Adam picked up where i left off |
| 12:21 |
mrpeters |
i think you may want both his branch, and my branch |
| 12:21 |
mrpeters |
but he is currently relocating and unavailable |
| 12:22 |
|
jihpringle joined #evergreen |
| 12:27 |
kmlussier |
mrpeters: Bmagic is the one who will be loading that branch on a VM. Is there any way it could be combined in one branch? |
| 12:28 |
mrpeters |
its not something i could do today, unfortunately, but after looking at it I beleive you may only need Adam's patch |
| 12:28 |
mrpeters |
mine fixed the original bug, but there was still an issue on other search tabs with duplicate rows, i think he took care of all of them in one sweep |
| 12:42 |
|
dMiller_ joined #evergreen |
| 12:46 |
|
dMiller_ joined #evergreen |
| 13:04 |
|
chatley joined #evergreen |
| 13:34 |
kmlussier |
dbwells: I was going to test your patch on bug 1425191, but I'm having trouble replicating the original problem. Can you give me some guidance on how to make it break? |
| 13:34 |
pinesol_green |
Launchpad bug 1425191 in Evergreen 2.7 "Summarization fails for serial units" (affected: 1, heat: 6) [High,New] https://launchpad.net/bugs/1425191 |
| 13:36 |
dbwells |
kmlussier: Sure. It isn't particularly noticeable, since unit labels don't show up in many places in stock Evergreen. |
| 13:37 |
dbwells |
The easiest place to see it is receiving in serial control. |
| 13:38 |
kmlussier |
OK, I'm there |
| 13:38 |
dbwells |
The column "Unit ID / Contents" should show, for example, "[12345] v.1:no.1" in the bottom pane after receiving. |
| 13:39 |
dbwells |
In current master without the fix, you just get "[12345]" |
| 13:39 |
dbwells |
You could also peek in serial.unit in the DB and see that the label field is empty. |
| 13:40 |
dbwells |
sorry, not label, but "summary_contents" and "detailed_contents" |
| 13:40 |
kmlussier |
OK, that gives me some good leads. Thanks! :) |
| 13:42 |
dbwells |
kmlussier: Thank you for testing! Also, bshum mentioned he was going to poke at this bug as well. I am not sure where he is at on that. |
| 13:42 |
|
dMiller_ joined #evergreen |
| 13:44 |
bshum |
dbwells: Right, I haven't gotten that far in my testing either. Have to continually refamiliarize myself with serials workflows :( |
| 13:44 |
bshum |
kmlussier++ # testing |
| 13:46 |
|
dMiller_ joined #evergreen |
| 13:50 |
|
dMiller_ joined #evergreen |
| 14:12 |
|
kitteh_ joined #evergreen |
| 14:13 |
kmlussier |
Bmagic: I hadn't even noticed that you had a fix for bug 1331174. Awesome! |
| 14:13 |
pinesol_green |
Launchpad bug 1331174 in Evergreen "Long Overdue processing needs org unit settings separate from Lost Processing" (affected: 3, heat: 14) [Undecided,New] https://launchpad.net/bugs/1331174 |
| 14:14 |
* kmlussier |
knows somebody who might be interested in testing that, but will probably not be available on Bug Squashing Day. |
| 14:16 |
|
dreuther___ joined #evergreen |
| 14:16 |
|
dreuther__ joined #evergreen |
| 14:24 |
|
RoganH joined #evergreen |
| 14:31 |
mmorgan |
Indeed! Bmagic++ |
| 14:37 |
|
mglass joined #evergreen |
| 14:54 |
kmlussier |
dbwells: OK, I've replicated the bug and confirmed that the patch fixes it. Signoff is on its way. |
| 14:54 |
dbwells |
kmlussier++ |
| 15:08 |
|
jlundgren joined #evergreen |
| 15:30 |
|
RoganH joined #evergreen |
| 16:03 |
pinesol_green |
[evergreen|Dan Wells] LP#1425191 Restore summarization of serial units - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=0a3348f> |
| 16:03 |
berick |
csharp++ # thanks for the kick in the right direction. http://wiki.evergreen-ils.org/doku.php?id=conference:2015:proposals#oh_crud_my_api_has_a_flesh_wound |
| 16:10 |
kmlussier |
Is tomorrow the deadline? |
| 16:11 |
Dyrcona |
kmlussier: I believe it is. |
| 16:57 |
|
bmills joined #evergreen |
| 17:08 |
csharp |
berick++ #awesome! |
| 17:18 |
|
mmorgan left #evergreen |
| 17:20 |
* csharp |
updates fedora buildslave to 21 |
| 17:46 |
|
Newziky left #evergreen |
| 18:13 |
|
bmills joined #evergreen |
| 19:27 |
|
dcook__ joined #evergreen |
| 20:05 |
|
bmills1 joined #evergreen |
| 20:27 |
|
jeffdavis joined #evergreen |
| 20:28 |
|
jboyer_isl joined #evergreen |
| 21:47 |
|
substack joined #evergreen |
