| Time |
Nick |
Message |
| 01:20 |
bshum |
Hmmmm |
| 01:25 |
bshum |
Interestingly, 0890 and 0891 are not present in the 2.6-2.7.0 upgrade script either. |
| 01:26 |
bshum |
Looks like the creation only went off 2.6.3-2.7.0 (aka, it didn't include the stuff in the 2.6.2-2.6.3) |
| 01:28 |
* bshum |
is not sure why it decided to skip those |
| 01:30 |
bshum |
Aha |
| 01:31 |
bshum |
Maybe when I rolled the 2.7.0, I told it to look at the rel_2_6 series branch, and it included the 2.6.2-2.6.3 script already. So it assumed it should have been there and skipped all the contents of it. |
| 01:32 |
bshum |
Or hmm |
| 01:32 |
bshum |
Maybe I just used the wrong tagged version 2.6.3 instead of 2.6.2 when I cut it |
| 01:32 |
* bshum |
sighs |
| 01:44 |
bshum |
@later tell dbs I put some thoughts on the bug in reply, but I think we should forward port 2.6.2-2.6.3 to rel_2_7. Master already has it, so the question is changing the assumption that you can upgrade at any point along the 2.6 to 2.7.0, but actually it needs to be 2.6.3-2.7.0 (exactly) |
| 01:44 |
pinesol_green |
bshum: The operation succeeded. |
| 01:45 |
bshum |
Not sure if that's better or worse actually.... version upgrades are such a mess. I'm sorry that I couldn't test it more thoroughly myself. Not being on any particular version is a downside to my own personal testing efforts of these scripts :( |
| 01:46 |
bshum |
dbs++ # actually getting 2.7 tested :) |
| 01:54 |
bshum |
I also updated bug status on bug 800478 (that's 0890) and bug 1189556 (that's 0891) |
| 01:54 |
pinesol_green |
Launchpad bug 800478 in Evergreen "Acquisitions - Funds transfer always transfers entire fund, not specified amount" (affected: 5, heat: 34) [Medium,Confirmed] https://launchpad.net/bugs/800478 |
| 01:54 |
pinesol_green |
Launchpad bug 1189556 in Evergreen "Typo: 'Allows a user to process and verify ULSs'" (affected: 1, heat: 6) [Low,Confirmed] https://launchpad.net/bugs/1189556 |
| 01:54 |
bshum |
We'll have to fix those as well to figure out how to incorporate those upgrade script fixes in the 2.7 series. |
| 01:55 |
bshum |
dbs++ # seriously bummed that 2.7.0's upgrade script is wonky :( |
| 01:55 |
bshum |
bshum-- |
| 01:55 |
bshum |
Oh well. Something to ponder more today while avoiding the snow... |
| 05:15 |
pinesol_green |
Incoming from qatests: Test Success - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 05:31 |
paxed |
dbs: i'm going to steal some parts of your intro-to-git - i got tasked to teach git at work ... |
| 05:47 |
|
wsmoak joined #evergreen |
| 06:28 |
|
eeevil joined #evergreen |
| 06:28 |
|
mtate joined #evergreen |
| 07:08 |
|
maryj joined #evergreen |
| 07:08 |
|
Callender joined #evergreen |
| 07:08 |
|
TaraC joined #evergreen |
| 07:09 |
|
phasefx joined #evergreen |
| 07:28 |
|
wsmoak_ joined #evergreen |
| 07:47 |
|
collum joined #evergreen |
| 08:19 |
eeevil |
bshum: I bet I know what happened re 2.7.0 upgrade script ... I think the tagged branches for the latest 2.5 and 2.6 hadn't been pushed yet (happened a while after releases were cut, IIRC) so you probably used rel_2_6_2 since it was the newest at the time |
| 08:31 |
|
mmorgan joined #evergreen |
| 08:31 |
|
mmorgan left #evergreen |
| 08:45 |
|
mmorgan joined #evergreen |
| 09:00 |
|
Dyrcona joined #evergreen |
| 09:04 |
|
mrpeters joined #evergreen |
| 09:11 |
|
yboston joined #evergreen |
| 09:29 |
Dyrcona |
I am trying to find the open-ils.circ.checkin call in the osrfsys.log so I can see what modifiers were set, but I'm not finding it. |
| 09:30 |
Dyrcona |
I've tried grepping with the copy barcode and copy id but no luck. |
| 09:30 |
|
mrpeters left #evergreen |
| 09:30 |
Dyrcona |
I can find the calls that it make, like copy and circ updates. |
| 09:31 |
Dyrcona |
I image that the params are going into the log as ARRAY[blah], so that's why it doesn't turn up. |
| 09:32 |
Dyrcona |
Well, close: open-ils.circ open-ils.circ.renew da62e601dca807bf3a34c6b9b93b8108, HASH(0x4b96030) |
| 09:32 |
Dyrcona |
That's not helpful. |
| 09:32 |
Dyrcona |
I thought we could see the modifiers in the logs at one point. |
| 09:33 |
dbwells |
Dyrcona: Might you also find what you need in the gateway log? |
| 09:33 |
Dyrcona |
Ah, dbwells, that is probably it. |
| 09:33 |
Dyrcona |
I'll give the gateway.log a shot. |
| 09:34 |
Dyrcona |
Anyway, I'm not sure modifiers apply to a renew, but I've got 19 circs a library asked about not charging fines this morning, and the first just happens to be a renew. |
| 09:35 |
mmorgan |
Dyrcona: I remember seeing modifiers in logs, maybe activity.log? |
| 09:35 |
Dyrcona |
dbwells++ |
| 09:35 |
Dyrcona |
mmorgan: Thanks for the suggestion but I've found them in gateway.log. |
| 09:35 |
Dyrcona |
I want to make sure that they were not in amnesty mode and didn't know it. |
| 09:36 |
Dyrcona |
Or something like that.... |
| 09:41 |
Dyrcona |
So, library calls to ask why 18 or so items that were due yesterday and checked in this morning did not charge fines. |
| 09:41 |
Dyrcona |
The grace period is 0. |
| 09:41 |
Dyrcona |
The library was not closed yesterday or today. |
| 09:41 |
Dyrcona |
No checking modifiers. |
| 09:42 |
Dyrcona |
I would expect the fine generator to not calculate fines, but shouldn't the checkin calculate fines? |
| 09:43 |
Dyrcona |
fine_rate and all that good stuff are filled in on the circs, too. |
| 09:45 |
mmorgan |
Backdated checkin? |
| 09:46 |
Dyrcona |
mmorgan: Nope. |
| 09:46 |
Dyrcona |
I vaguely recall there being something like an automatic 1 day of grace because of how the code works, but I could be mistaken. |
| 09:47 |
Dyrcona |
That is, if you return the day after something is due, you don't get charged a fine. |
| 09:47 |
Dyrcona |
However, if you return on the second day, you get charged for two days. |
| 09:48 |
Dyrcona |
Of course, the librarian claims it works all the time, just not with this patron and one other. |
| 09:49 |
Dyrcona |
Or, just not this morning and yesterday morning. |
| 09:49 |
Dyrcona |
No closed dates... |
| 09:50 |
mmorgan |
Hours of operation? |
| 09:52 |
Dyrcona |
Nope. The open at 8:30 and the circs happened after. First was a renewal at 8:38. |
| 09:53 |
Dyrcona |
The time on the server is used, unless it is a backdated checkin. |
| 09:55 |
Dyrcona |
Another thing bugs me... She called at 8:54 and most of these checkins happened at 8:58. |
| 09:55 |
csharp |
"I just wanted to let you know about this future Evergreen problem" |
| 09:55 |
Dyrcona |
I wonder if she didn't check them out again and then check them in? But no, I see no checkouts when I grep the barcodes. |
| 09:55 |
berick |
library minority report |
| 09:56 |
Dyrcona |
Originally she called at 8:42, and I was not in the office, yet. |
| 09:56 |
csharp |
Dyrcona: if staff are inside the patron account, they don't have to enter barcodes to manipulate circs |
| 09:56 |
csharp |
(in case that helps) |
| 09:57 |
Dyrcona |
csharp: True. But the circs don't look manipulated. |
| 09:57 |
Dyrcona |
At least the 3 or 4 that I've looked at in detail. |
| 09:57 |
Dyrcona |
No bills, no voids, no amnesty mode. |
| 09:58 |
csharp |
hmm |
| 09:58 |
dbs |
paxed++ # it's meant for sharing, that's great! I plan to revamp it in January for an improved session at the uni |
| 09:59 |
paxed |
dbs: the added complexity: both windows and linux users. |
| 09:59 |
dbs |
paxed: augh, yes |
| 10:02 |
dbs |
bshum: yeah, I'm wrong about the 2.6-2.7.0 reverting the version of the functions. but i don't think the 2.6.2-2.6.3 upgrade will actually work either because there will be two versions of the vandelay.marc21_extract_fixed_field_list(text, text) function |
| 10:02 |
dbs |
we don't delete the non-BOOLEAN DEFAULT version until after we try "CREATE OR REPLACE FUNCTION biblio.marc21_extract_fixed_field_list" |
| 10:03 |
dbs |
which contains a call to vandelay.marc21_extract_fixed_field_list(text, text) and postgresql 9.1, at least, treats (TEXT, TEXT, BOOLEAN DEFAULT) the same as (TEXT, TEXT) and errors out due to the ambiguity |
| 10:04 |
dbs |
so the fix there is to bump the DELETE FUNCTION IF EXISTS statements to just before each CREATE OR REPLACE FUNCTION statement, rather than having them at the end |
| 10:04 |
* dbs |
is braindumping into IRC rather than actually fixing the bug because of ye olde "I didn't have time to write you a short letter so I wrote you a long one" reasons |
| 10:06 |
Dyrcona |
Heh. |
| 10:10 |
bshum |
dbs: aha, interesting. |
| 10:11 |
* bshum |
has only been using PG 9.3 |
| 10:12 |
* jeff |
finds himself wanting "when was the last revision of this file that contained this string?" in git |
| 10:12 |
* jeff |
goes to search |
| 10:12 |
bshum |
@hate snow |
| 10:12 |
pinesol_green |
bshum: The operation succeeded. bshum hates snow. |
| 10:22 |
csharp |
@love snow |
| 10:22 |
pinesol_green |
csharp: The operation succeeded. csharp loves snow. |
| 10:22 |
csharp |
I'm sure I'd feel differently if I were trying to get to/from/around in New England right now though :-/ |
| 10:25 |
* csharp |
has fond memories of a Thanksgiving in Connecticut when it snowed several years ago |
| 10:30 |
Dyrcona |
@meh snow |
| 10:30 |
pinesol_green |
Dyrcona: Mr. Spock: Something fascinating just happened. |
| 10:30 |
Dyrcona |
That seems to happen a lot.... |
| 10:31 |
bshum |
I'm surprised it took me this long to log my hate of snow |
| 10:32 |
Dyrcona |
I like snow when I don't have to leave the house and can watch it through the window next to a warm fire. |
| 10:36 |
|
RoganH joined #evergreen |
| 10:42 |
* mmorgan |
likes Dyrcona's kind of snow. |
| 10:43 |
Dyrcona |
On my circulation conundrum, I did miss the obvious. Library is set to closed today because they didn't want things to be due. |
| 10:50 |
csharp |
aha |
| 10:55 |
Dyrcona |
As an experiment, I set the close to start at 4:30 pm and it still doesn't charge fines. I just wondered what would happen. |
| 10:56 |
Dyrcona |
bsum: Has the snow started where you are? |
| 10:56 |
Dyrcona |
oops. |
| 10:57 |
Dyrcona |
bshum: Has the snow started where you are? |
| 10:57 |
bshum |
Dyrcona: Well, there's snow at home, so I didn't leave. |
| 10:57 |
bshum |
I think it's wet rain / snow mixture |
| 10:57 |
Dyrcona |
I thought of working from home today. |
| 10:57 |
Dyrcona |
Nothing has started here, yet. |
| 10:58 |
csharp |
@weather 30033 |
| 10:58 |
pinesol_green |
csharp: The current temperature in Leafmore, Decatur, Georgia is 49.5°F (10:58 AM EST on November 26, 2014). Conditions: Clear. Humidity: 51%. Dew Point: 32.0°F. Windchill: 50.0°F. Pressure: 30.11 in 1020 hPa (Rising). |
| 11:02 |
maryj |
bshum: At least your city doesn't start shutting down with a half inch of snow. |
| 11:03 |
bshum |
Heh, I suppose that's true. |
| 11:15 |
|
vlewis joined #evergreen |
| 11:26 |
* collum |
was snow deprived as a child and really loves it now. |
| 11:26 |
jeff |
things i've been musing on again: a method to express various barcode transformations / validations in config (as opposed to code), and a means for patrons to have virtual library cards for online services (either one for all, or one for each, etc) |
| 11:27 |
jeff |
also, "library newsletter" integration other than just "pass email address to API upon new user registration" |
| 11:29 |
csharp |
okay, I'm trying to script OCLC bibs + holdings exports and I need to count the number of MARC records in an exported USMARC file - does anyone have a handy unix-tools or perl-based way to do that |
| 11:29 |
csharp |
? |
| 11:30 |
Dyrcona |
csharp: A binary file? |
| 11:31 |
csharp |
Dyrcona: yep |
| 11:31 |
csharp |
here's my attempt: http://paste.ubuntu.com/9252064/ |
| 11:31 |
* dbs |
usually uses yaz-marcdump for that sort of thing |
| 11:31 |
csharp |
it chokes on a bad leader |
| 11:31 |
csharp |
dbs: ah - yeah - that would work too |
| 11:32 |
csharp |
I'm trying to stick to tools that can be assumed to be installed on a typical Evergreen box |
| 11:32 |
csharp |
for portability's sake |
| 11:33 |
csharp |
hmm - I thought yaz-marcdump had a --count (or similar) parameter |
| 11:33 |
Dyrcona |
csharp: Your script should work. |
| 11:34 |
eeevil |
some light reading for your (US) holiday weekend: http://goo.gl/AOKWxo |
| 11:34 |
csharp |
eeevil: ooooh - nice |
| 11:35 |
eeevil |
tl;dr: it's 5am, time to upgrade the kernel |
| 11:36 |
csharp |
haha |
| 11:36 |
csharp |
eeevil: oh btw, congratulations ;-) |
| 11:36 |
|
sandbergja joined #evergreen |
| 11:36 |
eeevil |
csharp: thanks :) |
| 11:38 |
jboyer-isl |
eeevil++ |
| 11:39 |
csharp |
Dyrcona: this is the error I'm getting: http://pastie.org/9745086 - I guess I should point out that I don't care as much about the quality of specific records (while that's an overall concern) at this point. I just want to be able to put in an accurate count of records for OCLC's LABEL files |
| 11:39 |
csharp |
oclc-- |
| 11:40 |
csharp |
I hate how much trouble doing these exports/uploads is compared to... well, everyone else on earth |
| 11:40 |
Dyrcona |
csharp: You got that file from OCLC, or you exported it from Evergreen? |
| 11:41 |
csharp |
exported from Evergreen |
| 11:41 |
Dyrcona |
Never seen those particular errors from an Evergreen export before. |
| 11:41 |
csharp |
and that particular file has already been processed - I was using it as a test case for my perl script |
| 11:41 |
* csharp |
tries another |
| 11:42 |
Dyrcona |
I often have charset conversion errors when they want MARC8 and records with empty fields because of it. |
| 11:42 |
Dyrcona |
I'd ask OCLC if they'd accept MARC21XML. :) |
| 11:43 |
csharp |
maybe I can try MARC::Charset->ignore_errors() |
| 11:43 |
csharp |
Dyrcona: they don't - they're very rigid |
| 11:43 |
csharp |
I think it's because they're using tools from the late 90s or somesuch |
| 11:43 |
Dyrcona |
Not sure, those look like problems with the exported records, not with charsets. |
| 11:43 |
csharp |
ok |
| 11:44 |
Dyrcona |
csharp: All the vendors do. Our tools work. Why should we change them? |
| 11:44 |
bshum |
eeevil++ # fun reading indeed :) |
| 11:44 |
csharp |
well, since my script is theoretically sound, and the files I'm testing with have known issues, I'll try a new export and test on it. |
| 11:44 |
csharp |
Dyrcona: thanks for being a sounding board |
| 11:45 |
csharp |
bshum: after the holiday, I'd love to compare notes with you on the Dell DBs |
| 11:45 |
Dyrcona |
csharp: You might have low ascii in some of your fields. |
| 11:45 |
bshum |
csharp: For sure! I think things have gone much better since we reformatted them (again) and made all the changes to the configs. |
| 11:46 |
Dyrcona |
It's not supposed to be there, but old data could have it. |
| 11:46 |
eeevil |
csharp: s/90s/70s/ :) |
| 11:46 |
Dyrcona |
eeevil++ |
| 11:46 |
csharp |
Dyrcona: PINES is a bad data nightmare (or playground, depending on your perspective) ;-) |
| 11:47 |
csharp |
eeevil++ |
| 11:47 |
Dyrcona |
csharp: Every live system is. :) |
| 11:48 |
eeevil |
csharp: maybe pines would have more sway the lil' ol' me in getting oclc to deliver the holdings update web service they promised RSN in, oh, 2005 when I first asked about it :) |
| 11:48 |
csharp |
we have a particularly interesting mix of good, valid MARC, bad cataloging, and many records from legacy (and in some cases homegrown, non-MARC compliant) systems that were brought in many a year ago |
| 11:48 |
Dyrcona |
You could try using OpenILS::Utils::Normalize::clean_marc on the records before writing to your output file. |
| 11:49 |
csharp |
Dyrcona: is that employed by marc_export at all? |
| 11:49 |
csharp |
eeevil: interesting - I know there's a history there that I've heard in bits and pieces over the years |
| 11:50 |
Dyrcona |
charp: Apparently not. It is normally done when MARC is added to the database these days, but you may have older data or data added via SQL that bypasses that. |
| 11:50 |
eeevil |
csharp: royt and Thom Hickey were my prime targets, if you want a starting point, IIRC |
| 11:51 |
* Dyrcona |
wonders what is wrong with his fingers this morning. |
| 11:51 |
Dyrcona |
csharp: see above |
| 11:51 |
csharp |
Dyrcona: I'll look into it |
| 11:53 |
Dyrcona |
I made a library that includes versions of clean_marc and entityize that don't rely on Evergreen being installed. |
| 12:00 |
csharp |
Dyrcona: is that in your MVLC repo? |
| 12:03 |
Dyrcona |
No. It's on my laptop. :) |
| 12:03 |
csharp |
no prob - I'm on a box that has that anyway |
| 12:03 |
Dyrcona |
I was going to maybe add some more things to it. |
| 12:03 |
Dyrcona |
I use when I want to mess with MARC on my laptop using DBI. |
| 12:03 |
csharp |
I wonder if that would be worth running on our full bib set at some point |
| 12:04 |
Dyrcona |
Might not be a bad idea. |
| 12:05 |
Dyrcona |
Something in Perl to pull the marc of each record, clean it, and update it. |
| 12:08 |
jeff |
it would be nice if OCLC didn't charge an arm and a leg to update your holdings with them. the only recent holdings we have are where we've gotten the MARC from them via CatExpress |
| 12:12 |
Dyrcona |
If you ever pull MARCXML from the database and it comes straight out with more than 1 line, then you should at least run clean_marc on those records. |
| 12:12 |
Dyrcona |
Multiple lines is a sure sign that the MARC was not "fixed" for Evergreen. |
| 12:13 |
csharp |
@fix ALL THE MARC |
| 12:13 |
pinesol_green |
csharp: Zoia knows how to make fusilli. |
| 12:14 |
Dyrcona |
What do you know, pinesol_green ? |
| 12:14 |
Dyrcona |
Heh. It apparently knows enough to ignore me. ;) |
| 12:15 |
Dyrcona |
Yes, I realize I entered that incorrectly. |
| 12:25 |
|
artunit joined #evergreen |
| 12:33 |
|
nhilton joined #evergreen |
| 12:34 |
|
jihpringle joined #evergreen |
| 12:38 |
Bmagic |
jeff++ #helping with jcarousel |
| 12:40 |
jeff |
Bmagic++ glad to hear you made progress! |
| 12:40 |
jeff |
now I can share http://shouldiuseacarousel.com/ with you |
| 12:40 |
bshum |
Heh |
| 12:46 |
Dyrcona |
jeff++ # hah. |
| 12:47 |
jeff |
(technically a different KIND of carousel...) |
| 12:49 |
dbs |
If the carousel has ponies, then I'm down with it. |
| 12:51 |
Dyrcona |
dbs: Like this: https://www.youtube.com/watch?v=uoFn-PXO1OI |
| 13:22 |
|
jwoodard joined #evergreen |
| 13:38 |
Bmagic |
jeff: LOL! We had that discussion last week! |
| 13:48 |
dbs |
Dyrcona: yeah, I wasn't thinking that at all, but those kids are pretty impressive |
| 13:49 |
dbs |
It was thoughtful of you to include a Shania Twain cover in there for my Canuck heritage |
| 13:51 |
Dyrcona |
I didn't know they covered Shania Twain. ;) |
| 13:52 |
Dyrcona |
dbs: I honestly hadn't heard them before today. I always wanted to name a band Carousel Ponies and figured someone must have already done it. |
| 13:53 |
dbs |
Nice :) |
| 14:06 |
jeff |
patron self reg does good and bad things for data quality. |
| 14:10 |
csharp |
jeff: it's gotten mixed reviews from our libraries |
| 14:11 |
csharp |
the main complaint at the moment is the printability of the patron registration form itself, which our libraries would like to print, have the patron sign, and keep a copy of for some length of time |
| 14:11 |
* csharp |
hasn't looked into the issue at all so far though |
| 14:12 |
jeff |
i had an app for that. |
| 14:13 |
jeff |
we opted to ditch the paper instead. |
| 14:33 |
Dyrcona |
PKI signatures. |
| 14:45 |
jeff |
``The term “electronic signature” means an electronic sound, symbol, or process, attached to or logically associated with a contract or other record and executed or adopted by a person with the intent to sign the record.'' |
| 14:56 |
eeevil |
berick: trying to figure out how one might make egUser usable inside egHolds (as defined by the factory in circ/services/holds.js ... pointers? |
| 14:57 |
* berick |
looks |
| 14:59 |
berick |
eeevil: since egUser is defined inside its own module, whatever app that's running in the current page has to import egUserMod (see checkin/app.js) |
| 15:00 |
berick |
and checkin/index.tt2 loads services/user.js |
| 15:00 |
berick |
then the service in question has to import 'egUser', similar to how it imports egCore |
| 15:00 |
berick |
or... |
| 15:01 |
berick |
if it seems reasonable to load the module on many/most pages, we could insert it into egCore so it's always loaded |
| 15:01 |
eeevil |
ok, so just adding a <script> for user.js is the key, and then listing it along side egAlertDialog |
| 15:01 |
eeevil |
it's pretty important :) |
| 15:01 |
eeevil |
so, yes. where would that go? |
| 15:02 |
eeevil |
coresvc.js, I guess? |
| 15:02 |
berick |
yeah, it would be added there and it would need to get loaded in base_js.tt2 |
| 15:05 |
eeevil |
trying that |
| 15:05 |
berick |
note that user.js just has some fleshed user fetching stuff. unless you need the open-ils.actor.user.fleshed.retrieve magic, it's practically just as easy (and faster) to use egCore.pcrud.retrieve('au',1) |
| 15:06 |
berick |
but i could def. see the mod expanding over time |
| 15:06 |
berick |
in which case, +1 to including it in core |
| 15:09 |
eeevil |
yeah, it's not liking being loaded in the same way as the others in core: https://docs.angularjs.org/error/$injector/unpr?p0=egUserProvider%20%3C-%20egUser%20%3C-%20egCore |
| 15:09 |
eeevil |
so, I'll just do that. was trying to be more angular, but alas |
| 15:11 |
berick |
hm, right, user.js would need to live in the egCoreMod in that case (instead of egUserMod) |
| 15:27 |
|
artunit_ joined #evergreen |
| 15:51 |
|
Dyrcona joined #evergreen |
| 16:38 |
pinesol_green |
[evergreen|Lynn Floyd] Docs: Update to template receipt docs - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=3c40129> |
| 16:58 |
pinesol_green |
Incoming from qatests: Test Success - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 17:01 |
|
mmorgan left #evergreen |
| 17:39 |
|
artunit joined #evergreen |
| 18:52 |
|
dcook joined #evergreen |
| 23:08 |
|
dcook joined #evergreen |
