| Time |
Nick |
Message |
| 00:32 |
|
fparks joined #evergreen |
| 01:19 |
|
mtcarlson_away joined #evergreen |
| 03:54 |
|
j_scott joined #evergreen |
| 06:57 |
csharp |
@later tell bshum re: bug 1255561, this is happening at the OPAC login screen |
| 06:57 |
pinesol_green |
csharp: The operation succeeded. |
| 07:00 |
|
timf joined #evergreen |
| 07:50 |
|
collum joined #evergreen |
| 08:08 |
jeff |
morning |
| 08:09 |
|
gmcharlt joined #evergreen |
| 08:20 |
csharp |
jeff: good morning |
| 08:22 |
|
mdriscoll joined #evergreen |
| 08:25 |
|
Dyrcona joined #evergreen |
| 08:34 |
|
mrpeters joined #evergreen |
| 08:43 |
|
mmorgan joined #evergreen |
| 08:49 |
|
Shae joined #evergreen |
| 08:50 |
|
akilsdonk joined #evergreen |
| 09:35 |
|
kbeswick joined #evergreen |
| 09:43 |
|
akilsdonk joined #evergreen |
| 09:43 |
|
collum joined #evergreen |
| 09:51 |
|
RoganH joined #evergreen |
| 09:51 |
* Dyrcona |
saves some questions for the developer meeting. |
| 09:52 |
Dyrcona |
berick++ |
| 09:54 |
berick |
Dyrcona++ # questions |
| 10:02 |
jeff |
did i miss something in the netsplit? |
| 10:02 |
berick |
jeff: no, just sent a dev email |
| 10:02 |
jeff |
ah. email. saw. |
| 10:02 |
berick |
a terse one, at that |
| 10:02 |
jeff |
looked there second. |
| 10:02 |
jeff |
berick++ |
| 10:07 |
jeff |
the fact that overdue fines get future-dated timestamps is annoying, but i suspect the work to correct it without causing headaches for existing sites would be great. |
| 10:10 |
Dyrcona |
jeff: Now, I missed something.... |
| 10:12 |
jeff |
This is mostly from memory, so might not be accurate: back around 1.2->1.4 or 1.4->1.6, daily overdue fines started being generated with a timestamp of 23:59. I believe this was due to changes with hourly fines, and might just have been a side effect of how circs get "pushed" to 23:59 when they have a day-granular circ duration. |
| 10:13 |
jeff |
I remember there were issues with fine generation for those circs that existed before the upgrade. I believe it resulted in one day extra fines. This may have been due to local quirks or missed upgrade recommendations -- I don't know. |
| 10:13 |
jeff |
Other than that, it doesn't usually cause much in the way of problems, but can be difficult to explain. |
| 10:13 |
Dyrcona |
I thought I was missing some IRC discussion about it since you mentioned work to fix it. |
| 10:14 |
jeff |
Nope. Sorry. :-) |
| 10:14 |
Dyrcona |
I don't see how you could do it any other way, particularly when the fine generator is playing catch up as mine is. |
| 10:15 |
Dyrcona |
Maybe just make it a date field with no timestamp, but that wouldn't work for hourly fines. |
| 10:15 |
jeff |
I was looking at a problem report involving a circ that was declared lost the same day it received its first overdue fine, and the payment forgiving the $0.25 fine is dated roughly 14 hours before the bill that it pays. |
| 10:15 |
Dyrcona |
Is there a problem with hourly fines? |
| 10:16 |
jeff |
I'm not sure that there's a way to expect money.materialized_payment_by_billing_type to be accurate in the face of bills with inaccurate (future) timestamps. |
| 10:16 |
Dyrcona |
Is it a "real" problem, i.e. the bill doesn't actually show as paid, or is it just an cosmetic problem because staff don't like the payment predating the bill? |
| 10:18 |
Dyrcona |
jeff: BTW, I pushed some updated billing branches last night and fixed its issues with the fine generator. So, I'm a bit sensitive about changes that would require me to make more changes to my code. :) |
| 10:19 |
Dyrcona |
Ah, I see how it could be a real problem if you're looking at it on that day.. billing_ts < now() might pose an issue, eh? |
| 10:21 |
phasefx |
incidentally, a qa test involving fines failed the past two nights. I'm poking |
| 10:24 |
|
yboston joined #evergreen |
| 10:25 |
jeff |
Dyrcona: it's an issue when i'm working on bug 1174498 / mmpbbt |
| 10:25 |
pinesol_green |
Launchpad bug 1174498 in Evergreen "Payment by billing type breakdown" (affected: 3, heat: 14) [Wishlist,In progress] https://launchpad.net/bugs/1174498 - Assigned to Jeff Godin (jgodin) |
| 10:26 |
jeff |
Dyrcona: if i have an overdue billing dated 11:59 today and a lost item billing dated 9:08 (because the item was manually marked lost -- the patron came in and wanted to pay for the item), assigning payments to billings is going to be inaccurate due to the inaccurate timestamp on the overdue billing |
| 10:27 |
|
AaronZ-PLS joined #evergreen |
| 10:27 |
jeff |
Also, I suspect that the future timestamp confused the system when it was trying to automatically forgive/void the overdues on lost, but that might not exist in stock -- we have the "forgive-not-void" code in production. |
| 10:28 |
Dyrcona |
jeff: Have a look at my Bill_01 branch, specifically bill_payment_map_for_xact in CircCommon.pm. After handling voids, it matches payments to bills by amount. |
| 10:28 |
* jeff |
looks |
| 10:33 |
berick |
:q |
| 10:33 |
berick |
bah |
| 10:33 |
Dyrcona |
wrong window? |
| 10:35 |
berick |
yeah |
| 10:36 |
RoganH |
I just sat down with three of our full time circ staff and had them play with Bill's web based staff client. They wanted to know how soon it could be finished and they could use it up front. |
| 10:39 |
jeff |
Dyrcona: got to the end of the comment on that function with a "these words sound vaguely familiar" feeling, then read the last statement on the comment, laughed |
| 10:41 |
berick |
RoganH++ # field testing |
| 10:41 |
berick |
very cool |
| 10:43 |
Dyrcona |
jeff: The comments in the function are meant to be helpful, too. :) |
| 10:43 |
Dyrcona |
But, yeah, your code was the inspiration even if it looks very different now. |
| 10:44 |
Dyrcona |
RoganH++ # Being braver than I. |
| 10:44 |
Dyrcona |
RoganH: That very question is why I've said nothing to member library staffs, yet. |
| 10:45 |
RoganH |
Dyrcona: my circ staff are good at rolling with change, they may not like something (and will say so) but they don't freak out. Branch managers are another issue ... |
| 10:45 |
jeff |
the approach in bill_payment_map_for_xact seems pragmatic, but it feels... wrong to be doing it that way. |
| 10:45 |
jeff |
i.e., ordering by payment size instead of date. |
| 10:46 |
jeff |
other than the future-dated overdue billings that we've just discussed, were there other things that you encountered that led you to go with that approach? |
| 10:46 |
jeff |
rather than sorting payments and billings by date and applying them in that order? |
| 10:51 |
jeff |
other than "experience shows that the things |
| 10:51 |
jeff |
other than "experience shows that the things that should never happen actually do happen with surprising regularity in a library setting." :-) |
| 10:53 |
tsbere |
jeff: Some days it seems like it is more "things that shouldn't happen do and things that should happen don't in library settings" - Things happening that should happen seem to be rarities. :P |
| 10:59 |
Dyrcona |
jeff: The reason for going by payment/bill amount was that it would likely match lost payments up with lost billings more accurately than a simple date-based approach. |
| 11:00 |
Dyrcona |
tsbere: That's probably true in any setting when humans are involved. :) |
| 11:13 |
|
rfrasur joined #evergreen |
| 11:35 |
bshum |
phasefx: Were those failed tests new to the testing suite? Or was it something that we've changed in master since the new year began? |
| 11:35 |
jeff |
one solution to future-billings and mmpbbt: treat overdue billings with 23:59 timestamp as -1 day :-) |
| 11:36 |
bshum |
phasefx: The only thing that's changed in master was altering the stock org unit data, so maybe that's something. Otherwise, the rest are catalog changes so far as I can tell. |
| 11:38 |
* Dyrcona |
wouldn't be surprised if something in the test environment changed. |
| 11:38 |
phasefx |
bshum: I'm suspecting environment (date, timezone, external package) and not recent code changes |
| 11:38 |
Dyrcona |
jinx! |
| 11:38 |
phasefx |
I've been pulled away from poking though |
| 11:38 |
Dyrcona |
test == more code == more bugs. :p |
| 11:42 |
bshum |
Heh |
| 11:43 |
eeevil |
jeff: re "one solution to future-billings and mmpbbt", how about just billing_ts::date::timestamptz if billing_ts::time = '23:59:59'; -- adjust spelling of time as required |
| 11:43 |
jeff |
eeevil: better, i think. |
| 11:44 |
jeff |
does anyone else see any value in making the future-billings no longer be future? |
| 11:44 |
eeevil |
jeff: even better would be "if it's a circ, and the fine interval == '1 day', do the casting dance" |
| 11:45 |
jeff |
yeah, i was thinking of limiting it to circ + od billing type, but that's better because it uses the same logic that creates them in the first place. |
| 11:47 |
eeevil |
jeff: if we had better mixed TZ support (cstore transactional params, and use thereof for "my client timezone"), I'd totally get rid of the offset |
| 11:48 |
eeevil |
FTR, the offset is really there to make sure that 1) double-billing on a day didn't happen in the olden days 2) make sure the date part doesn't magically shift due to DST or mixed client TZ |
| 11:49 |
jeff |
the "push to 23:59" trigger was part of work on hourly fines, i thought. |
| 11:49 |
jeff |
i'll dig a little, with at least the goal of having awareness of what potential fixes might look like, as i work with what we have. |
| 11:49 |
jeff |
Dyrcona++ eeevil++ thanks |
| 11:50 |
eeevil |
jeff: that's when it happened, yes. that's when the risk of double billing started |
| 11:50 |
eeevil |
before that, the nightly fine gen was the only time fines accrued, and they happened ahead of time |
| 11:51 |
eeevil |
anyway, I think we can work towards getting rid of it for good, but "if fine interval % '1 day' == 0, cast to date" seems a reasonable short term compromise |
| 11:52 |
jeff |
agreed. |
| 11:52 |
eeevil |
jeff: ahh... I said == 1 day up there ... I meant % 1 day == 0 ... (just to make sure that was clear) |
| 11:53 |
jeff |
istr there were quirks for circs that spanned the upgrade when that change was made -- resulting in one day extra billing. |
| 11:54 |
jeff |
eeevil: i got what you meant, but thanks for making sure. :-) |
| 11:56 |
eeevil |
jeff: probs, yes, re quirks |
| 11:57 |
* jeff |
looks at live_t/05-pay_bills.t |
| 12:01 |
phasefx |
jeff: those tests depend on preceding tests, so 03-overdue-circ is where I would look first; if you're looking because of the failure |
| 12:02 |
jeff |
phasefx: sorry, i was looking because i wanted to add some billing / overdue / checkin / backdate / etc related tests, and wanted to see what was already there |
| 12:02 |
phasefx |
gotcha |
| 12:03 |
jeff |
phasefx: thanks, though -- at least one comment or the commit message made that part clear also (that the tests relied on each other) |
| 12:04 |
jeff |
oh, the text of the test itself clued me in: Two billable xacts for admin user from previous tests |
| 12:33 |
|
snowball_ joined #evergreen |
| 12:33 |
|
snowball_ left #evergreen |
| 12:36 |
phasefx |
so 03-overdue-circ, I think the test assumptions are flawed. Fines didn't get created for the 28th and 29th of December.. those are on a weekend, and hours of operation with the stock test data have those days as closed for BR4. So no fines? |
| 12:37 |
phasefx |
I should use a different org that is always open |
| 12:41 |
tsbere |
phasefx: Should probably test both cases, really... |
| 12:41 |
phasefx |
tsbere: sounds good |
| 12:42 |
jeff |
perhaps. could also create a closing date and test that. not sure how best to test standard hoo closings, though |
| 12:42 |
phasefx |
04-overdue_with_closed_dates.t |
| 12:43 |
phasefx |
I think there is also a DST issue with the tests, but I didn't record it at the time |
| 12:52 |
jeff |
@decide UTC or Swatch Internet Time? |
| 12:52 |
pinesol_green |
jeff: Yeah, well, you know, that's just like uh, your opinion, man. |
| 13:02 |
csharp |
the_dude++ |
| 13:03 |
jeff |
ow. concurrency bug in jeff. |
| 13:04 |
|
gsams joined #evergreen |
| 13:04 |
jeff |
i just tried to type and tab-complete both phasefx and csharp at the same time. it did not work. |
| 13:04 |
jeff |
phasefx: is the random repo still the definitive place for eg_wheezy_installer.sh? |
| 13:06 |
|
stevenyvr2 joined #evergreen |
| 13:10 |
phasefx |
jeff: it is |
| 13:11 |
phasefx |
jeff: I have a link to gitweb from |
| 13:11 |
phasefx |
http://testing.evergreen-ils.org/~live/ |
| 13:13 |
jeff |
phasefx: thanks! |
| 13:16 |
dbs |
phasefx: aha, crap, so my addition of more more interesting HOO broke the live tests. sorry about that. |
| 13:17 |
phasefx |
dbs: s'okay, more interesting data, more interesting tests :) |
| 13:17 |
* dbs |
will attempt to fix |
| 13:19 |
dbs |
oh, right, crapola... these tests can't be run twice in a row :/ |
| 13:19 |
phasefx |
yeah, have to wipe the database at least |
| 13:19 |
phasefx |
we can strive to have tests that clean up after themselves, but I don't think we can/should require it |
| 13:20 |
phasefx |
that said, redoing those existing ones so they're not registering workstations could help |
| 13:20 |
phasefx |
add some stock registrations to concerto |
| 13:22 |
dbs |
Yeah, it's just a bit of a painful stop opensrf / recreate database / start opensrf debug cycle |
| 13:25 |
dbs |
Better than the alternative of entirely manual testing though |
| 13:29 |
dbs |
Mmm. Yeah. Hmm. What if the regression tests just created a brand new OU rather than messing with the sample data? |
| 13:31 |
dbs |
Working through the "Set closing start date 10 days ago and closing end date 9 days ago" logic and figuring out what that means if the OU comes in already having closed dates is hurting my brain atm |
| 13:31 |
jeff |
sounds good to me. either create the testing org unit(s) as part of an earlier test, or define an explicit "testing" set of data to be loaded, distinct from the "sample" data. |
| 13:31 |
dbs |
Or maybe we just start by setting the BR4 HOO to known values (the old defaults) from the start, rather than relying on the sample data |
| 13:31 |
phasefx |
yeah, I think that's a good strategy too, creating data as needed |
| 13:32 |
|
librarian joined #evergreen |
| 13:32 |
phasefx |
we do it with the closed date, since that has to be relative to the test run date |
| 13:44 |
|
hopkinsju joined #evergreen |
| 13:46 |
hopkinsju |
We've got a library that is interested in migrating their historical circs. I've told them that it's really not feasible. We don't have time to run 10 million circulations before we go live with them. Not to mention that many of the circs would fail due to deleted users, etc. I don't suppose there is a simple way of importing this information so that it could be combined with Evergreen circs and reported on? |
| 13:47 |
jeff |
hopkinsju: you could look into importing them as "aged" circulations. the foreign key constraints are then less of an issue. |
| 13:48 |
jeff |
hopkinsju: you would need to identify those circs that did not link to a currently existing item, though -- your only real option there would be to import them as non-cataloged circulations or as circulations of a dummy item, or to create (deleted) pre-cataloged items for those... |
| 13:48 |
jeff |
in retrospect, the last option there might be best. |
| 13:48 |
gmcharlt |
and even simpler, if they don't actually need a great deal of granularity, is to populate extend_reporter.legacy_circ_count |
| 13:48 |
jeff |
some of it depends on what their goal is. |
| 13:48 |
jeff |
gmcharlt++ |
| 13:49 |
hopkinsju |
Their goal is to generate a report for weeding. I had looked at action.aged_circulations and it seems like a reasonable solution (except that we'd be making up a good deal of information just to satisfy the not null constraints) |
| 13:50 |
hopkinsju |
Can you formulate a report that would show circs from both action.circulation and action.aged_circulation *and* provide information such as call number? |
| 13:50 |
jeff |
if they care only about circ counts and not about circ age or time of last circ, etc... then i'm guessing (and gmcharlt can probably confirm/deny) that gmcharlt's suggestion of extend_reporter.legacy_circ_count would work. |
| 13:51 |
jeff |
er, "circ age" there was a bad way to put it -- circ frequency, or distribution might be better. |
| 13:52 |
gmcharlt |
and in particular, there's nothing saying that legacy_circ_count couldn't be populated with just the number of circs in the past 6 months, or year, or whatever, if their actual reporting timeframe doesn't need to go further into the past |
| 13:54 |
Dyrcona |
hopkinsju: The action.all_circulation view combines action.circulation and action.aged_circulation. |
| 13:57 |
hopkinsju |
Ok all. I'm looking at these various tables and approaches. All seem like good ideas. I'm leaning towards extend_reporter.legacy_circ_count at this point but I'm going to need to get with the library and see what all they hope to use this for. |
| 13:58 |
jeff |
hopkinsju: whatever you select, be sure you determine how to report on it first, before committing. :-) |
| 13:58 |
hopkinsju |
jeff: I'm firing up the staff client as we speak to do exactly that. |
| 13:58 |
jeff |
hopkinsju: Dyrcona pointed out how to do it for aged circs. i don't know how best to do it for extend_reporter.legacy_circ_count |
| 13:59 |
|
akilsdonk joined #evergreen |
| 14:01 |
hopkinsju |
Is legacy circ count updated immediately when action.circulation is, or does it only include circs older than a certain age? |
| 14:02 |
Dyrcona |
legacy_circ_count has to be updated manually. |
| 14:02 |
Dyrcona |
It's sole purpose is to hold a total count of circulations for a copy from the legacy ILS. |
| 14:02 |
hopkinsju |
Dyrcona: It does? I wonder how the 76716 rows that are there got there. |
| 14:03 |
gmcharlt |
previous migrations |
| 14:06 |
hopkinsju |
gmcharlt: ahha. Looking through these I think they are from Poplar Bluff which you guys migrated. |
| 14:07 |
|
j_scott joined #evergreen |
| 14:11 |
Dyrcona |
hopkinsju: I don't think we used it when I helped you with migrations. |
| 14:38 |
bshum |
csharp: Quirk with the classic_item_list reporter view. It seems that pubdate with the fm_IDL.xml file is marked as an "int" field, when in fact it's actually a text field according to the view. |
| 14:38 |
bshum |
This breaks stuff like, when say selecting the average of a text field... |
| 14:41 |
bshum |
Also, it seems that pubdate in that reporter.classic_item_list view is only drawing from the 260c field. So it also suffers from RDA envy with the 264 tag change. |
| 14:41 |
* bshum |
hates reports |
| 14:44 |
dbs |
you should hate RDA too |
| 14:44 |
bshum |
Right, |
| 14:44 |
bshum |
I think I already do. |
| 14:45 |
bshum |
@hates |
| 14:45 |
pinesol_green |
bshum hates metarecord holds; acquisitions; questions about acquisitions; z39.50; acq; notices; action triggers; marc_export; hold pull lists; drupal; holds; RDA; edi; parts holds; kpac; SIP; parts; marc; RAID; Launchpad; edi troubleshooting; reports; serials; apostrophes in search; server power failures; zimbra; office printer; weird barcodes; PO JEDI; B&T; and using the phone |
| 14:45 |
bshum |
Yes, I do. |
| 14:45 |
kmlussier |
bshum: Looks like you hate almost every part of Evergreen. ;) |
| 14:46 |
bshum |
Hey, checkin and checkout work. |
| 14:46 |
bshum |
That's something. |
| 14:46 |
csharp |
damn |
| 14:46 |
csharp |
bshum++ # thanks |
| 14:48 |
Dyrcona |
We have an internal bug that only 264 field is showing up in the catalog. |
| 14:48 |
Dyrcona |
So, more RDA hate here. |
| 14:48 |
Dyrcona |
@hates |
| 14:48 |
pinesol_green |
Dyrcona hates parts; MARC; vacation; their/there; English orthography; Launchpad; and English_Orthography |
| 14:48 |
Dyrcona |
@loves |
| 14:48 |
pinesol_green |
Dyrcona loves git; Tina Dico; you anyway; scripted sign off; sed; Monique Ortiz; and OpenBSD |
| 14:49 |
Dyrcona |
Actually had a good vacation last time. |
| 14:49 |
Dyrcona |
@hate RDA |
| 14:49 |
bshum |
Dyrcona: "only" 264? That's not good.... |
| 14:49 |
pinesol_green |
Dyrcona: The operation succeeded. Dyrcona hates RDA. |
| 14:49 |
Dyrcona |
Oops. |
| 14:49 |
Dyrcona |
@hate typos |
| 14:49 |
csharp |
@karma rda |
| 14:49 |
pinesol_green |
Dyrcona: The operation succeeded. Dyrcona hates typos. |
| 14:49 |
pinesol_green |
csharp: Karma for "rda" has been increased 0 times and decreased 5 times for a total karma of -5. |
| 14:49 |
Dyrcona |
Only ONE 264 is showing up where there is more than one. |
| 14:50 |
bshum |
Odd. |
| 14:50 |
tsbere |
I will point out that while the bug does say that, the problem isn't that. :P |
| 14:50 |
Dyrcona |
I haven't looked really. |
| 14:50 |
bshum |
Oh okay, I would expect it to show one first, and the rest visible in the rest of the record details. |
| 14:50 |
tsbere |
The actual issue is that we aren't showing anything other than "Publication" information. Thus, the real issue is more of a "no Production, Distribution, Manufacture, or Copyright notice date information is displayed in the catalog" |
| 14:51 |
bshum |
Oh, that sounds like a custom catalog issue then |
| 14:51 |
bshum |
? |
| 14:51 |
tsbere |
Depends. Stock Evergreen shows none of that. |
| 14:51 |
bshum |
Hmm |
| 14:51 |
tsbere |
I am still waiting on someone else to tell me if it is actually important to show. |
| 14:53 |
Dyrcona |
That's the problem: A says yes, B says no. |
| 14:53 |
jeff |
berick++ phasefx++ eg_wheezy_install.sh |
| 14:53 |
jeff |
ran in 13:24 on a quick-and-dirty spot intsance |
| 14:53 |
jeff |
instance, even |
| 14:55 |
berick |
jeff: sweet |
| 14:55 |
* berick |
uses it often |
| 14:55 |
jeff |
Dyrcona: abuse au.profile or aus entries to make it so everyone sees it the way they think it should be. done! ;-) |
| 14:59 |
csharp |
bshum: in the most current version, pubdate is drawn from reporter.materialized_simple_record, so I think it *is* including 264s |
| 14:59 |
bshum |
csharp: Ooh, interesting... I guess I need to replace our view from the newer source then? |
| 14:59 |
bshum |
Or is that a local change in your DB? |
| 15:00 |
csharp |
no, it's in example.reporter_extension.sql in master |
| 15:00 |
|
librarian joined #evergreen |
| 15:00 |
|
j_scott1 joined #evergreen |
| 15:00 |
csharp |
if you're running the older version, it's flawed anyway - it overcounts circs because it was counting every patron card, active or not |
| 15:01 |
csharp |
there was another issue with it too that's not coming to mind ;-) |
| 15:01 |
csharp |
bitrot-- |
| 15:02 |
bshum |
Oh figures |
| 15:02 |
bshum |
I should know better; git blame says *I* signed off and merged those fixes |
| 15:02 |
bshum |
Thanks csharp |
| 15:02 |
bshum |
I'll reload ours |
| 15:04 |
csharp |
oh yeah - it wasn't counting aged circs |
| 15:04 |
csharp |
but that's fixed now too |
| 15:07 |
bshum |
Still though |
| 15:07 |
bshum |
rmsr.pubdate being a text field probably means we ought to change the fm_IDL.xml entry for pubdate |
| 15:07 |
bshum |
In that classic view |
| 15:11 |
csharp |
yeah - just created bug 1267229 and working branch |
| 15:11 |
pinesol_green |
Launchpad bug 1267229 in Evergreen "wrong datatype for pubdate in reporter.classic_item_list" (affected: 1, heat: 6) [Medium,In progress] https://launchpad.net/bugs/1267229 - Assigned to Chris Sharp (chrissharp123) |
| 15:12 |
bshum |
yboston: if/when you get a chance, I'd be curious to get some feedback from your catalogers on https://bugs.launchpad.net/evergreen/+bug/1267231 |
| 15:12 |
pinesol_green |
Launchpad bug 1267231 in Evergreen "TPAC - added author entries with titles, etc. display" (affected: 1, heat: 6) [Undecided,New] |
| 15:13 |
bshum |
Some of mine noticed issues with how the added authors displayed, but we're curious to get some music cataloger perspectives too. |
| 15:13 |
bshum |
Also, whether authorities make things messier |
| 15:14 |
yboston |
bshum: Happy new year, I will ask the catalogers |
| 15:15 |
yboston |
bshum: what version are you running? we moved to 2.5.1 yesterday |
| 15:16 |
jeff |
huh. seeing a failure with registering a workstation. wonder if i did something wrong. |
| 15:16 |
jeff |
(running tests from eg_wheezy_installer.sh) |
| 15:17 |
jeff |
ah, yep. |
| 15:17 |
jeff |
failed to pass -s, so the required sample data was not present. |
| 15:18 |
bshum |
yboston: We're using master, but basically 2.5.1ish |
| 15:18 |
bshum |
More like whatever 2.5.2 will be |
| 15:18 |
yboston |
bshum: (it was right there in the first one of your bug, my bad) |
| 15:20 |
jeff |
phasefx: is it expected to be able to re-run the full eg_wheezy_installer.sh script after failure? |
| 15:20 |
phasefx |
I don't think it would fail horribly if you tried it, but I wouldn't expect it to work flawlessly either |
| 15:21 |
yboston |
bshum: I sent an email to the catalogers, but I have not finished prating my custom TT files , so my OPAC is stiller inning some 2.4.x TT code until I finsih the update |
| 15:21 |
phasefx |
the webifier stuff for ~live would certainly mark-up a lot of the output |
| 15:22 |
jeff |
noted. best to nuke vm and start over, or closely approximate nuke by stopping services, dropping db, etc? |
| 15:22 |
yboston |
bshum: s/prating/updating/ |
| 15:22 |
bshum |
yboston: No problem, we appreciate your folks input on things. |
| 15:22 |
phasefx |
jeff: or maybe bludgeoning through the process a few times and change the code so that it does work well |
| 15:22 |
bshum |
yboston: Post-upgrade fun is always... well... fun. |
| 15:23 |
phasefx |
jeff: the way I use it now is a pristine wheezy image gets restored every night prior to run |
| 15:23 |
jeff |
phasefx: got it. thanks. :-) |
| 15:23 |
phasefx |
and for testing, I was using virtualbox a lot |
| 15:24 |
jeff |
huh. there's a sure fire way of finding a bunch of things to clean up: run the installer + tests with just stdout redirected to a file -- observe the output of stderr. |
| 15:24 |
jeff |
(made worse by my running this in an unsupported way, as previously established) |
| 15:28 |
|
kbeswick joined #evergreen |
| 15:31 |
|
roses joined #evergreen |
| 15:46 |
hopkinsju |
Dyrcona: I ran a query and it turns out that circ_lib is all over the place for these items. Something must have updated them, but I'm not inclined to figure it out at this point. I'm going to see about getting enough information into action.aged_circulation to make it useful. |
| 15:47 |
Dyrcona |
I am fairly certain that there are no database triggers to update that table. |
| 15:56 |
|
hbrennan joined #evergreen |
| 15:58 |
hbrennan |
Are bug tags searchable? I'm trying to add one, but I'm not getting confirmation that anything's happening after clicking the green checkmark. |
| 15:58 |
hbrennan |
So I'm not sure whether the bug tag is not searchable, or isn't getting saved in the first place |
| 16:04 |
Dyrcona |
hbrennan: What is the bug # and the tag? |
| 16:04 |
hbrennan |
https://bugs.launchpad.net/evergreen/+bug/1186391 |
| 16:04 |
pinesol_green |
Launchpad bug 1186391 in Evergreen "In house use count does not appear on item status summary " (affected: 6, heat: 36) [Wishlist,Triaged] |
| 16:05 |
hbrennan |
What the heck, pinesol.... spying on my interneting |
| 16:05 |
pastebot |
"roses" at 64.57.241.14 pasted "Authority validation question" (15 lines) at http://paste.evergreen-ils.org/52 |
| 16:05 |
hbrennan |
I wanted to add In-House Use as a tag |
| 16:05 |
hbrennan |
because I couldn't find it in a search because the hyphen isn't there |
| 16:05 |
Dyrcona |
I don't think tags are allowed to have hyphens. |
| 16:06 |
hbrennan |
oh... well that would do it |
| 16:06 |
Dyrcona |
Yeah, the search on Launchpad is pretty bad. |
| 16:06 |
roses |
I just posted an authority validation question that has been bugging me for some time. |
| 16:06 |
kmlussier |
@hate Launchpad search |
| 16:06 |
pinesol_green |
kmlussier: But kmlussier already hates Launchpad search! |
| 16:06 |
hbrennan |
ugh |
| 16:06 |
hbrennan |
Yeah, I felt bad since I really did try to find a bug on the subject |
| 16:06 |
Dyrcona |
hbrennan: One trick that tsbere does to search for bugs is open a new bug. |
| 16:06 |
hbrennan |
and mark it as a dup? |
| 16:07 |
Dyrcona |
The search for duplicates is apparently better than regular search. |
| 16:07 |
hbrennan |
That's how I found this one |
| 16:07 |
Dyrcona |
Launchpad will search for dups, so you might find a suitable bug that way. |
| 16:07 |
hbrennan |
I found the dup from 2011 first |
| 16:08 |
hbrennan |
I hate to make dups, but if that's a kosher way of making the search better I can |
| 16:08 |
Dyrcona |
Hmm. Looks like tags can have hyphens after all. |
| 16:08 |
hbrennan |
I just know that if the hyphen was included it would have more fire power |
| 16:08 |
csharp |
roses: I would recommend also sending that question to the General or Catalogers list |
| 16:08 |
Dyrcona |
Well, you don't have to file the bug. If Launchpad finds dups, it doesn't make the bug unless you explicit tell it to. |
| 16:09 |
hbrennan |
So there's something wrong with this page, or this bug, not letting me add a tag? |
| 16:09 |
Dyrcona |
You can also search by tags on the Advanced Search. I doubt that they are included in regular search. |
| 16:10 |
hbrennan |
Yeah, it will let me make a tag, but not with the hyphen |
| 16:10 |
Dyrcona |
hbrennan: I can't say. Launchpad is run by Canonical, the corporation behind Ubuntu GNU/Linux, so I don't know. |
| 16:10 |
roses |
csharp: Sara already has but with no results. Several people thought it was a permission problem, but I don't see that. |
| 16:10 |
hbrennan |
I thought the whole point of bug tags was to make searches easier |
| 16:11 |
Dyrcona |
Right. I've never looked at Launchpad's source code so I don't what it really does. |
| 16:11 |
hbrennan |
Weird... Well, it won't let me add the hyphen. But if the tag isn't searchable I guess there's no point |
| 16:12 |
hbrennan |
Hey, my email to the list doubled its flame-age though |
| 16:12 |
Dyrcona |
I added the tag with the hyphen. However, search does not turn up that bug for "in-house use." |
| 16:13 |
Dyrcona |
@sarcasticlove Launchpad Search |
| 16:13 |
pinesol_green |
Dyrcona: The operation succeeded. Dyrcona hates Launchpad Search. |
| 16:13 |
roses |
csharp: Do you know if there are "switches" (allow/disallow yes or no) that need to be turned off or on? |
| 16:13 |
hbrennan |
Very strange *I* couldn't do that |
| 16:13 |
Dyrcona |
*I* am a bug wrangler and may have special dispensation from the system. |
| 16:14 |
hbrennan |
Ah, so much power |
| 16:14 |
hbrennan |
You have the power of the hyphen |
| 16:14 |
Dyrcona |
Heh. |
| 16:14 |
csharp |
roses: as far as I know, validation just works or just doesn't |
| 16:15 |
* csharp |
isn't the best person to ask |
| 16:15 |
hbrennan |
Dyrcona, did you attend the conference in Vancouver? I can't remember if I met you |
| 16:15 |
hbrennan |
You are also a OPAC expert, yes? |
| 16:15 |
Dyrcona |
I was there. I don't remember meeting you, so we must not have rubbed elbows. |
| 16:15 |
roses |
csharp: Yep. and it works okay on other fields. Sara called the cataloger at Georgia and some other super catalogers but they didn't have an answer. Do you have a test server that you could test a 651 having more than one thing in it? |
| 16:15 |
Dyrcona |
Not an expert, but I can break things real good. |
| 16:16 |
hbrennan |
You helped me with some weird parts during our launch |
| 16:16 |
csharp |
roses: heh - the "cataloger at Georgia" is my colleague and I would consider her about as expert as you get |
| 16:16 |
hbrennan |
We had only been live with Evergreen for two weeks during the Vancouver conf |
| 16:16 |
hbrennan |
I can't wait to have a better handle on things in Boston |
| 16:16 |
roses |
csharp: Yeah I know! |
| 16:16 |
hbrennan |
Elaine? |
| 16:17 |
csharp |
hbrennan: yep ;-) |
| 16:17 |
hbrennan |
haha, that's how she was introduced to me |
| 16:17 |
dbs |
roses: so maybe there's an expectation that there would be only one $a for a given field? Not 100% sure, haven't dipped into the authority auth code for a long time |
| 16:18 |
roses |
dbs: That makes sense but who would know? |
| 16:18 |
dbs |
roses: you have an authority record that matches that? |
| 16:18 |
dbs |
e.g. 151 $a Lancaster County (Pa). $a fiction ? |
| 16:18 |
roses |
dbs: Yes - when I right mouse click I can go and select Lancaster, PA and VEL(some nunmbers) |
| 16:19 |
dbs |
roses: I guess I need a clearer description of what you mean by "won't validate" |
| 16:20 |
roses |
dbs: Turns back to red. I just went back and took out the "fiction" part and added what was in the list and it works. It doesn't like fiction in that field? |
| 16:21 |
roses |
dbs: So I don't have an authority record that matches 151 $Lancaster County (Pa). $a fiction - I have a screen shot of what I select in the paste bin (link to image bin) |
| 16:22 |
dbs |
roses: Then yes, it doesn't like fiction in that field because it's not finding a matching authority record |
| 16:23 |
dbs |
If you add an authority record that has 151 $a Lancaster County (Pa). $a fiction then it should validate. |
| 16:23 |
roses |
dbs: How/where do we add an authority record (the person asking me might know that answer) |
| 16:28 |
dbs |
roses: when you right click (as in http://imgbin.org/index.php?page=image&id=16251) there should be an "add authority record" option at the top |
| 16:31 |
roses |
dbs: thanks - I can't get in touch with the person who had the question so I will go back to her tomorrow and see if we can get this straightened out. Thanks again. |
| 16:41 |
|
stevenyvr2 joined #evergreen |
| 16:49 |
bshum |
hbrennan: Dyrcona: fwiw, I think people have just scrunched up words into a single word when describing things with LP bug tagging. For example "memoryleak" as a single word. |
| 16:49 |
bshum |
So I would go with "inhouse" if you wanted to tag it. |
| 16:52 |
hbrennan |
Thanks, bshum. |
| 16:52 |
hbrennan |
Drycona got the tag to stick with the hyphen, but it's only searchable in Advanced search |
| 16:57 |
|
GeoffSams joined #evergreen |
| 17:00 |
ldwhalen |
I am working on modifying phasefx parallel reingest script. |
| 17:01 |
ldwhalen |
The script calls metabib.reingest_metabib_field_entry |
| 17:01 |
ldwhalen |
with different paramters to allow browse entries to be ingested differently serially while others can be done in parallel |
| 17:01 |
phasefx |
do I have parallel reingest script? |
| 17:01 |
bshum |
jeffdavis++ # fix for bug 1267252 worked for me; never noticed it before. |
| 17:02 |
pinesol_green |
Launchpad bug 1267252 in Evergreen "SRU/Z39.50 results show deleted copies" (affected: 1, heat: 6) [Undecided,New] https://launchpad.net/bugs/1267252 |
| 17:02 |
ldwhalen |
phasefx: sorry I may have that wrong |
| 17:02 |
|
Bmagic joined #evergreen |
| 17:03 |
ldwhalen |
s/phasefx/drycona/ |
| 17:04 |
phasefx |
ah, Jasons abound |
| 17:04 |
ldwhalen |
I want to add teh functionality from indexing_ingest_or_delete |
| 17:05 |
ldwhalen |
I am thinking of addeing paramters to the trigger and manually setting NEW, OLD, and TG_OP |
| 17:05 |
ldwhalen |
depeding on the paramter |
| 17:05 |
ldwhalen |
That way I can call the trigger directly from the script, and the logic does not have to be maintained in two places |
| 17:06 |
ldwhalen |
This is still fragile if new trigger variables are used in the trigger without updating |
| 17:06 |
ldwhalen |
the case where the paramter is set |
| 17:06 |
ldwhalen |
I am wondering if this is a good idea? |
| 17:07 |
bshum |
Grr, backport to rel_2_4 fails due to whitespace vs. tab changes |
| 17:07 |
* bshum |
hand patches, bleh |
| 17:10 |
pinesol_green |
[evergreen|Jeff Davis] Fix bug that caused deleted holdings to be visible in SRU/Z39.50 results - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=71908f1> |
| 17:12 |
pinesol_green |
[evergreen|Chris Sharp] fix pub date data type in reporter.classic_item_list - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=cb7c6b5> |
| 17:14 |
senator |
bshum: `git cherry-pick -Xignore-space-change` is good for avoiding that in many cases, jfyi |
| 17:14 |
bshum |
senator: Oh, cool. I'll add that to my notes. Thanks! |
| 17:14 |
berick |
git cherry-pick -Xgah-just-do-it |
| 17:14 |
senator |
heh |
| 17:17 |
|
mdriscoll left #evergreen |
| 17:20 |
|
smyers_ joined #evergreen |
| 17:20 |
|
mmorgan left #evergreen |
| 17:29 |
|
mrpeters left #evergreen |
| 17:42 |
Bmagic |
anyone out there write perl to convert marc to xml and get errors like "no mapping found for [0x12]" ? Does that mean that I lost data moving from marc to xml? What happens to those characters in the destination? |
| 17:43 |
jeffdavis |
bshum: thanks! |
| 17:45 |
|
dcook joined #evergreen |
| 17:48 |
ldwhalen |
Bmagic: what encoding are you using in your perl file? |
| 17:49 |
Bmagic |
ldwhalen: use Data::Dumper; use DateTime; use utf8; use Encode; use encoding 'utf8', Filter => 1; use MARC::Record; use MARC::File::XML (BinaryEncoding => 'utf8'); |
| 17:49 |
ldwhalen |
Is your marc UTF8 or MARC8? |
| 17:49 |
Bmagic |
marc8 (i think) |
| 17:50 |
Bmagic |
my $file = MARC::File::USMARC->in( $inputFile ); |
| 17:51 |
Bmagic |
274k records, this error comes up about 100 times or less |
| 17:51 |
ldwhalen |
Can you check position 09 of the ldr for one of those records? |
| 17:52 |
Bmagic |
ldwhalen: any record? |
| 17:52 |
ldwhalen |
One of the records that fails |
| 17:52 |
Bmagic |
ldwhalen: I havent identified any of those specifically |
| 17:53 |
Bmagic |
I will answer your question in a minute, allow me to output some more info during runtime |
| 17:55 |
Bmagic |
ldwhalen: it's a space |
| 17:55 |
Bmagic |
LDR 00727nam 22002057 4500 |
| 17:56 |
ldwhalen |
Ok, assuming the leader is telling the truth, I am not sure. One thing I have encounterd, is UTF8 encoded records without the appropriate value set in the leader. |
| 17:56 |
ldwhalen |
There is a python library you can use which does a decent job of detecting encodings. |
| 17:56 |
Bmagic |
ldwhalen: let's say it's utf8 - is my code reading the file incorrectly? |
| 17:59 |
ldwhalen |
Bmagic: let me check, it has been a while since I have done this |
| 18:00 |
Bmagic |
ldwhalen: Thanks for your time - I will check back tomorrow - PM me - need to go AFK |
| 18:00 |
ldwhalen |
Bmagic: ok |
| 18:00 |
Bmagic |
ldwhalen: I will probably be back later today acctually |
| 20:24 |
|
stevenyvr2 left #evergreen |
| 21:15 |
|
serflog joined #evergreen |
| 21:15 |
|
Topic for #evergreen is now Welcome to the #evergreen library system channel! | We are publicly logged. | Large pastes at http://paste.evergreen-ils.org |
| 23:46 |
|
ktomita_ joined #evergreen |
| 23:48 |
|
dconnor_ joined #evergreen |
| 23:53 |
|
dbs joined #evergreen |
