| Time |
Nick |
Message |
| 00:05 |
|
tfaile joined #evergreen |
| 00:10 |
|
b_bonner joined #evergreen |
| 07:26 |
|
dbwells_ joined #evergreen |
| 07:38 |
|
rjackson-isl joined #evergreen |
| 07:46 |
|
artunit_ joined #evergreen |
| 07:51 |
|
artunit_ joined #evergreen |
| 07:57 |
|
mdriscoll1 joined #evergreen |
| 08:08 |
|
mrpeters joined #evergreen |
| 08:35 |
|
akilsdonk joined #evergreen |
| 08:39 |
|
kbeswick joined #evergreen |
| 08:42 |
|
Shae joined #evergreen |
| 09:02 |
|
timlaptop joined #evergreen |
| 09:06 |
pinesol_green |
[evergreen|Srey Seng] LP#1266937: Fix missing/incorrect regex for authority in Vandelay.pm - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=0947992> |
| 09:24 |
pinesol_green |
[evergreen|Dan Scott] Repair the live_t regression tests - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=812a726> |
| 09:29 |
|
Dyrcona joined #evergreen |
| 09:34 |
pinesol_green |
[evergreen|Kyle Tomita] LP1038240 - Patron editor field documentation does not display text - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=df6a6b9> |
| 09:36 |
|
mmorgan joined #evergreen |
| 09:50 |
pinesol_green |
[evergreen|Dan Scott] Tests: Ensure TT2 templates parse cleanly - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=5bf117c> |
| 09:54 |
egbuilder |
build #466 of evergreen-master-debian-6.00-x86_64 is complete: Failure [failed test] Build details are at http://testing.evergreen-ils.org/buildbot/builders/evergreen-master-debian-6.00-x86_64/builds/466 blamelist: Dan Scott <dscott laurentian.ca> |
| 09:54 |
egbuilder |
build #472 of evergreen-master-ubuntu-12.04-x86 is complete: Failure [failed test] Build details are at http://testing.evergreen-ils.org/buildbot/builders/evergreen-master-ubuntu-12.04-x86/builds/472 blamelist: Dan Scott <dscottlaurentian.ca> |
| 09:56 |
|
gsams joined #evergreen |
| 09:57 |
jeff |
Test::Output needed as new pre-req on build slaves, it appears. |
| 09:58 |
* dbs |
should be able to arrange for that on a few of those slaves |
| 09:58 |
dbs |
@blame Dan Scott |
| 09:58 |
pinesol_green |
dbs: Dan Scott musta been an Apple employee. |
| 09:58 |
dbs |
OUCH |
| 10:00 |
berick |
bah, i forgot about the build slaves |
| 10:02 |
|
collum joined #evergreen |
| 10:05 |
bshum |
ktomita++ # field doc repairs, yay!!!! |
| 10:24 |
|
yboston joined #evergreen |
| 10:27 |
csharp |
okay Test::Output installed on Fedora and Ubuntu buildslaves |
| 10:28 |
bshum |
csharp++ |
| 10:31 |
|
hopkinsju joined #evergreen |
| 10:38 |
dbs |
Test::Output installed on testing.evergreen-ils.org as well |
| 10:41 |
csharp |
dbs++ |
| 10:41 |
egbuilder |
build #473 of evergreen-master-ubuntu-12.04-x86 is complete: Success [build successful] Build details are at http://testing.evergreen-ils.org/buildbot/builders/evergreen-master-ubuntu-12.04-x86/builds/473 |
| 10:41 |
csharp |
yay! |
| 10:42 |
* dbs |
needs to bring over a vpnc conf for upei's build slave still... |
| 10:42 |
csharp |
all is well in the world, so I'll just sit back and ... oh crap! I have an upgrade next week! |
| 10:43 |
bshum |
Hmm |
| 10:43 |
dbs |
ah, http://testing.evergreen-ils.org/buildbot/builders/evergreen-master-fedora-18/builds/440/steps/test/logs/stdio is still failing because of Encode.pm I imagine |
| 10:43 |
bshum |
Contemplating https://bugs.launchpad.net/evergreen/+bug/1208875 |
| 10:43 |
pinesol_green |
Launchpad bug 1208875 in Evergreen "OPAC: My Account: Download Checkout History CSV breaks when there are a large number of items in the history" (affected: 2, heat: 10) [Undecided,New] |
| 10:44 |
dbs |
fedora also failing on "Can't locate Locale/Maketext/Extract.pm" |
| 10:44 |
bshum |
Looking at how circ history CSV is done, I'm not sure if this is just a factor of the A/T being slow to pass off the data off? |
| 10:44 |
csharp |
dbs: will look |
| 10:47 |
csharp |
perl-Encode-2.54-1.fc19.x86_64 |
| 10:47 |
csharp |
so that's the higher version that breaks stuff? |
| 10:48 |
bshum |
bug 1242999 says, yes. |
| 10:48 |
pinesol_green |
Launchpad bug 1242999 in Evergreen "Encode.pm 2.54 breaks database functions (naco_normalize, maintain_control_numbers, others)" (affected: 1, heat: 10) [High,Confirmed] https://launchpad.net/bugs/1242999 |
| 10:49 |
csharp |
bshum: thanks |
| 10:49 |
dbs |
csharp: yes, although it's probably best that Fedora continue to fail until we fix the real problem |
| 10:50 |
|
roses joined #evergreen |
| 10:51 |
csharp |
hmm - Locale::Maketext::Extract is not in the F19 repo |
| 10:51 |
roses |
I'm still working on authority records and have been able to add an authority record and it's in the list (right mouse click) but it stil doesn't want to validate. |
| 10:51 |
roses |
csharp: I have Sara on speaker phone :-) So she will be helping me describe the problem. |
| 10:52 |
csharp |
dbs: should Locale::Maketext::Extract be included in the Makefile? |
| 10:53 |
csharp |
roses: sorry - my attention is very divided at the moment, but if you ask, I'm sure someone will be able to assist |
| 10:53 |
dbs |
csharp: prolly, lemme look |
| 10:53 |
Dyrcona |
bshum: Wouldn't be surprised if it is timing out on an atomic call to retrieve circ history. |
| 10:54 |
roses |
csharp: thanks. should I just come back - ya'll look like you're "atomic calling" something |
| 10:54 |
bshum |
Dyrcona: That's the other thing I was wondering |
| 10:54 |
csharp |
roses: if you're willing to ask and wait (or ask on the email lists) that works |
| 10:54 |
bshum |
I'm looking for a sample problem patron to see if I can get some log data to see if I can pinpoint where it's breaking. |
| 10:56 |
dbs |
oh, hey, roses - http://www.loc.gov/marc/bibliographic/bd651.html says $a is not a repeatable subfield |
| 10:56 |
dbs |
So authority validator isn't going to validate an invalid field... |
| 10:57 |
roses |
dbs: That was my mistake on the screenshots - we are adding subfield v Fiction |
| 10:57 |
dbs |
TBH we might be just getting lucky there, that might not be intentional |
| 10:58 |
dbs |
Oh, hmm. |
| 10:58 |
Dyrcona |
Wow! |
| 10:58 |
* Dyrcona |
just found a "patron" with 15,775 check outs. |
| 10:58 |
csharp |
holy moly |
| 10:59 |
Dyrcona |
I think it is actually a special account for lost things or something. I'll check. |
| 10:59 |
* csharp |
guesses that it's a fake "weeding" or "damaged" staff card used to avoid using statuses |
| 10:59 |
csharp |
yeah, that |
| 11:00 |
Dyrcona |
Yep. It's "name" is Reference Dept. Discard. |
| 11:00 |
roses |
dbs: It seems like we have "permission" to add to the list (we see the authority record we added in the list) it just doesn't listen to it. |
| 11:02 |
roses |
dbs: Also that file would be local wouldn't it? Should we be looking at permissions on that file? Or if that file needs to be "reupdated" or something like that? |
| 11:02 |
gmcharlt |
Dyrcona: that, or it's a bird! it's a plane! it's SUPERPATRON! |
| 11:03 |
* dbs |
wonders if the validation result was cached |
| 11:03 |
dbs |
roses: it would be in the database in authority.record_entry as one of the most recently added entries |
| 11:03 |
Dyrcona |
gmcharlt++ |
| 11:06 |
roses |
dbs: We think we have tested possibly the caching issue. ie put it in a couple of weeks ago and it still doesn't work. Are there settings for keeping cache (how long etc) |
| 11:08 |
dbs |
roses: the cache settings are all hard coded; a few weeks ago would certainly be cleared by now |
| 11:09 |
roses |
dbs: we are stumped. Sara (the person who has the issue) has emailed super catalogers but they all seemed not to be using it at this level. |
| 11:10 |
roses |
dbs: Sara said that the people she talked to were just using LOC as is and not adding their own records. |
| 11:18 |
dbs |
roses: huh. We have some libraries that use it to add local auth records on our 2.4 system and it seems to work :/ |
| 11:19 |
roses |
dbs: Can we have their name or contact info? |
| 11:19 |
roses |
dbs: Or you can just send it to me in an email? |
| 11:21 |
dbs |
You're probably better off posting your question to open-ils-general or the cataloguing list, that way everyone benefits (and can figure out if it works on 2.4 and not 2.5 or something like that) |
| 11:23 |
roses |
dbs: We've done that and maybe your people didn't see it. Sara has also called several other Evergreen catalogers. |
| 11:23 |
Dyrcona |
dbs: An email appears to have been sent to the catalogers list on December 6. |
| 11:24 |
Dyrcona |
Oops. That a different topic. |
| 11:24 |
* Dyrcona |
fades into the background again. |
| 11:24 |
|
RoganH joined #evergreen |
| 11:24 |
roses |
dbs: We will try again to both the general and the cataloguing. |
| 11:27 |
|
afterl joined #evergreen |
| 11:28 |
roses |
RoganH: Are we still on for Rock Hill in February? |
| 11:29 |
RoganH |
roses: No, unfortunately not. The state libraries involved chose to not pursue it. Since they had been discussing sponsoring it and had put together the surveys I asked them if they'd like to inform potential attendees and they never replied. |
| 11:29 |
RoganH |
roses: at this point SCLENDS is considering putting it on later in the year without the nc / sc state libraries |
| 11:29 |
roses |
RoganH: Crud - I was looking forward to it and so were some of my libraries since it's local. |
| 11:32 |
dbs |
roses: yes, our people won't see it; sadly there are few people outside of myself, rri, and artunit really participating in the broader Evergreen community |
| 11:33 |
roses |
dbs: Okay, we are going to send it out today - could you please forward to your people - possibly? Thanks in advance. |
| 11:35 |
dbs |
roses: sure. Please include all of the extra info (steps we've gone through since) |
| 11:35 |
dbs |
and point at an example bib record in your catalogue if you can, and the authority record that you created and expect it to validate against |
| 11:40 |
|
Dyrcona joined #evergreen |
| 11:41 |
RoganH |
roses: I don't know if you got the private messages but basically some strange events transpired with the original promoters of the event. I was working with them but not putting it on myself. |
| 11:41 |
RoganH |
roses: I've now been asked if I would organize and put it on but I have to work with the SCLENDS board on that decision so I think we'll have that decision made by next Friday. |
| 11:42 |
RoganH |
roses: If we go ahead with the S/E conference we are probably looking at a September or October time frame. |
| 11:47 |
roses |
RoganH: I didn't know that you weren't putting it on - I'm looking forward to the possible fall one. |
| 11:50 |
RoganH |
roses: Well, I was kind of adjunct to it. I was involved but I wanted it to be an opportunity for the state libraries to contribute to the community and get some good karma. |
| 11:51 |
roses |
dbs: Just got this message back from Mike at Equinox: Based on looking at your catalog* you're on version 2.3.7. I believe there are bugs specifically with the Validate function that were not fixed until after the EOL of 2.3, so it's likely that upgrading to the newest 2.4 or 2.5 will be your best hope of repair for that functionality. |
| 11:55 |
|
Dyrcona joined #evergreen |
| 12:10 |
pinesol_green |
[evergreen|Bill Erickson] LP#1267224: Repair IDL typo for vandelay authority match / rec link - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=4c5f792> |
| 12:10 |
pinesol_green |
[evergreen|Galen Charlton] LP#1267224: repair another fm_IDL.xml typo - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=0eb7e69> |
| 12:21 |
dbs |
csharp: working/user/dbs/fedora_maketext for master / 2.5, I guess I should backport it for 2.4 too |
| 12:23 |
jeff |
pg_restore++ for having a --no-tablespaces option |
| 12:23 |
csharp |
dbs++ # thanks |
| 12:24 |
jeff |
also, for -l/-L -- i have often found the technique of creating a toc and editing the file to determine what to restore to be Quite Handy |
| 12:24 |
dbs |
and user/dbs/fedora_maketext_2_4 as well |
| 12:32 |
|
rfrasur joined #evergreen |
| 12:36 |
|
jihpringle_ joined #evergreen |
| 12:40 |
csharp |
dbs: signoff branch (for master/2.5) is at user/csharp/fedora_maketext_signoff |
| 12:40 |
csharp |
I tested it on the buildslave - no issue |
| 12:41 |
dbs |
yay! |
| 12:41 |
dbs |
csharp++ |
| 13:02 |
|
kbutler joined #evergreen |
| 13:04 |
sseng |
Just wanted to ask if there's any documentation and/or guide on how to use th Acquisitions->Patron Requests and how that ties to selection lists, vice versa, thanks! Been doin g quite a bit of searching online but can't seem to find |
| 13:06 |
bshum |
sseng: I'll be honest, I'm not sure what exists on that either. To me, I never thought the acq /patron requests stuff was quite finished. |
| 13:06 |
bshum |
Or at least I couldn't find where it got revealed to end users anywhere meaningful. |
| 13:09 |
sseng |
bshum: ah ok. was looking around that area, and not quite sure when I encounter certain behavior whether it was due to a bug or my workflow. thanks again! |
| 13:11 |
jeff |
dear launchpad search: die. |
| 13:11 |
jeff |
two non-matching results shown for a search on get_combined_holdings |
| 13:12 |
csharp |
@blame launchpad search |
| 13:12 |
pinesol_green |
csharp: launchpad search stole bradl's tux doll! |
| 13:22 |
Dyrcona |
@whocares Launchpad Search |
| 13:22 |
pinesol_green |
kmlussier and Dyrcona hate Launchpad Search |
| 13:25 |
jeff |
staff receiving this in serials batch receive in 2.5.2 ("intermittently", though I haven't confirmed that yet) get_combined_holdings(): Can't call method "increment" on an undefined value at [...]/OpenILS/Utils/MFHD.pm line 576. |
| 13:26 |
* bshum |
boggled for a moment at 2.5.2 |
| 13:27 |
senator |
jeff: kind of a catch all error for holdings data that confuses serials holdings summarization, which is re-run at each receive time |
| 13:28 |
senator |
look for issuances all related to the same subscription and caption_and_pattern with holding_codes that don't all have the same number of elements (or holding_codes with empty subfields, out of sequence values, or other oddness) |
| 13:28 |
jeff |
and yes, s/2.5.2/2.5.1/ :-) |
| 13:29 |
bshum |
Speaking of which |
| 13:29 |
jeff |
supposedly staff switched to a different computer and were able to receive. that seems... unusual. |
| 13:29 |
jeff |
but unconfirmed. |
| 13:30 |
bshum |
eeevil: I was finally going back through old emails from the holidays and saw your packaging up 2.4.5 RC. I didn't notice that and there's been some shuffling of bugs and backports into rel_2_4 since that happened. |
| 13:31 |
bshum |
Since the other maintenance builds were postponed, I'm wondering if we can quietly let that RC go and then build a new one for 2.4.5 with all the latest stuff. |
| 13:31 |
bshum |
Otherwise, I can go back and sift through LP and move things around. |
| 13:33 |
jeff |
psql++ for \x auto |
| 13:33 |
jeff |
(new in 9.2, iirc) |
| 13:37 |
jeff |
senator: thanks for the pointer! my serials-fu is quite weak. |
| 13:38 |
jeff |
senator: looking at all of the issuances with that subscription and caption_and_pattern shows that all have at least one empty entry in their holding_code value -- not sure if that's fatal. |
| 13:38 |
jeff |
example: ["4","1","8","1.29","a","","b",159,"i","2013","j","10","x","AUTOGEN"] |
| 13:39 |
remingtron |
yboston: there's a DIG meeting at 2pm, correct? |
| 13:39 |
yboston |
yes |
| 13:39 |
jeff |
full error references "using sdist ID #572 and 18 issuances, of which one has ID #52493" |
| 13:40 |
jeff |
so i looked at issuance 52493 and found its subscription and caption_and_pattern, then queried using select id, holding_code from serial.issuance where subscription = 548 and caption_and_pattern = 737 order by id; |
| 13:41 |
jeff |
which returns 69 issuances, presumably either because the "and 18 issuances" excluded future issuances, or... not sure what other likely cause there. |
| 13:41 |
remingtron |
yboston: I was looking at the agenda, and it seems to have some out of date items |
| 13:42 |
remingtron |
also, I added a few small things |
| 13:42 |
yboston |
remingtron: no problem |
| 13:42 |
yboston |
thanks |
| 13:42 |
senator |
jeff: right, very likely the 18 issuances are the ones received to-date (including the one it was trying to receive) |
| 13:43 |
jeff |
logical. |
| 13:43 |
senator |
jeff: atm i couldn't narrow it down to a specific commit, but the holdings summarization did indeed get stricter recently about things like that empty $a |
| 13:43 |
senator |
very likely finding a value to put there (and fixing any similar cases) will make that item receivable again |
| 13:44 |
jeff |
i'll attempt to determine if the "intermittent" means "works for some serials but not others", and compare one where it's working. |
| 13:44 |
senator |
jeff++ |
| 13:46 |
dbwells_ |
jeff: for the issuance data you posted, what is the scap pattern_code? |
| 13:47 |
jeff |
select pattern_code from serial.caption_and_pattern where id = 737; |
| 13:47 |
jeff |
["2","0","8","1","a","","b","issue","u","125","v","c","i","(year)","j","(month)","w","m","y","cm01/02","y","pm03","y","pm04","y","pm05","y","cm06/07","y","cm08/09","y","pm10","y","pm11","y","pm12"] |
| 13:47 |
jeff |
i think that's what you were asking, but let me know if i'm off. |
| 13:49 |
dbwells |
jeff: yes, that's it. It is definitely interesting/unusual. Not sure if the empty "a" is a mistake, or if they genuinely wanted a volumed digit to appear with no caption at all. |
| 13:50 |
jeff |
looks like we have nine rows in serial.caption_and_pattern where pattern_code ~ '""' |
| 13:50 |
jeff |
i'll see if those are the ones with issues. |
| 13:50 |
jeff |
(no pun intended) :P |
| 13:50 |
dbwells |
In any case, the issuance would need a value in the "a", as senator suggests, even if it is unlabled by a caption. |
| 13:52 |
jeff |
from the staff client, where is the best place to correct the blank value for "a"? |
| 13:52 |
jeff |
(staff may know this already) |
| 13:52 |
dbwells |
The fact that this pattern says you get 125 "issues" per "[unlabeled unit]" only makes things even more odd. |
| 13:55 |
dbwells |
jeff: because this pattern has a lot of custom data (combo issues, in particular), it is probably easiest to edit the holding code directly (it is a JSON string). Sorry, not the most user-friendly thing. |
| 13:59 |
yboston |
heads up the DIG monthly meeting is starting at 2 PM EST |
| 13:59 |
rfrasur |
yboston++ |
| 14:00 |
yboston |
#startmeeting 2014-01-09 - DIG Monthly Meeting Evergreen Documentation Interest Group (DIG) Monthly Meeting. |
| 14:00 |
pinesol_green |
Meeting started Thu Jan 9 14:00:39 2014 US/Eastern. The chair is yboston. Information about MeetBot at http://wiki.debian.org/MeetBot. |
| 14:00 |
pinesol_green |
Useful Commands: #action #agreed #help #info #idea #link #topic. |
| 14:00 |
pinesol_green |
The meeting name has been set to '2014_01_09___dig_monthly_meeting_evergreen_documentation_interest_group__dig__monthly_meeting_' |
| 14:01 |
yboston |
The agenda can be found here http://evergreen-ils.org/dokuwiki/doku.php?id=evergreen-docs:dig_meeting_20140109-agenda |
| 14:01 |
yboston |
#topic Introductions |
| 14:01 |
yboston |
Please feel free to start introducing yourselves... |
| 14:01 |
* remingtron |
is Remington Steed, Hekman Library, Calvin College |
| 14:01 |
* yboston |
is Yamil Suarez @ Berklee college of Music - DIG meeting facilitator |
| 14:02 |
* rfrasur |
is Ruth Frasur, Hagerstown Library, Evergreen Indiana |
| 14:02 |
yboston |
kmlussier warned that she will not be ble to make it today |
| 14:02 |
yboston |
(Happy new year to everyone) |
| 14:02 |
remingtron |
looks like a small meeting |
| 14:02 |
eeevil |
bshum: oh, the 2.4.5 RC is gold, just needs to be moved into place. never got a "tested, works" from anyone, which is why I didn't just push it out |
| 14:03 |
rfrasur |
(happy new year as well) |
| 14:03 |
* eeevil |
hushes for the dig meeting. sorry |
| 14:03 |
yboston |
I will wait one more minute before starting our (small) meeting |
| 14:04 |
remingtron |
do we have enough members to make any decisions? or should we postpone? |
| 14:04 |
remingtron |
or is it just not that formal? |
| 14:04 |
rfrasur |
remingtron, it's not that formal, but it is a very small group. |
| 14:04 |
yboston |
I guess we are too few to make any major decisions, though there are no written rules |
| 14:05 |
* kmlussier |
is Kathy Lussier, MassLNC, but probably be only able to lurk today. :( |
| 14:05 |
rfrasur |
IMO, there's some pretty important stuff on the agenda. |
| 14:05 |
yboston |
We can decide as a (small) group how to proceed. |
| 14:06 |
remingtron |
let's see how far we get |
| 14:06 |
rfrasur |
+1 |
| 14:06 |
yboston |
I am fine with just brainstorming for a bit or just asking each other questions for a bit. or we can try to reschedule |
| 14:06 |
yboston |
on the thought of rescheduling, we can ask on the list if we should try a different time/day to meet going forward in case it helps others to participate |
| 14:07 |
yboston |
though perhaps changing the date/time might not make much of a difference. |
| 14:07 |
remingtron |
do you think we should try the doodle scheduling approach that the devs use? |
| 14:07 |
remingtron |
at least once to see if people respond |
| 14:07 |
rfrasur |
I'm not sure that's the issue at this point, yboston |
| 14:08 |
rfrasur |
remingtron, I think that's actually been done in the past. I'm not against it. |
| 14:08 |
yboston |
remingtron: I don;t mind a poll, even if we end up with the same time |
| 14:08 |
yboston |
rfrasur: what do you mean? |
| 14:08 |
rfrasur |
Maybe we used a doodle poll for something other than the DIG meeting. |
| 14:09 |
rfrasur |
I was thinking it was used for something related to DIG though. Oh, it might have been the hackaway. Pardon, I'm a little foggy today. |
| 14:09 |
remingtron |
no worries. for today, looks like we don't have any content coordinators around, right? |
| 14:09 |
yboston |
looks like we don't |
| 14:10 |
remingtron |
should we brainstorm our way through the agenda items then? |
| 14:10 |
rfrasur |
yep |
| 14:11 |
yboston |
I am OK with that, specially to start fleshing stuff out for the next meeting |
| 14:11 |
yboston |
we can also throw in another agenda item to explore increasing meeting participation |
| 14:11 |
yboston |
like a doodle poll (etc) to see what time works for most folks |
| 14:11 |
remingtron |
sounds good |
| 14:12 |
rfrasur |
Should that be an action item then? creating a doodle poll (why did they have to name it doodle? seriously). |
| 14:13 |
yboston |
yes, we can try a doodle poll for next months meeting, just to see if it increase participation, and we could also ask for general feedback on the meting time going forward |
| 14:13 |
remingtron |
sounds like a good action item to me |
| 14:14 |
yboston |
would either of you like to set up the poll and send out the email? |
| 14:14 |
* rfrasur |
chuckles at the silence. |
| 14:15 |
rfrasur |
Yeah, I'll do it. |
| 14:15 |
remingtron |
rfrasur++ |
| 14:15 |
rfrasur |
Should we have another near the end of this month? |
| 14:16 |
yboston |
you can bounce ideas off of me before sending it out, if that helps |
| 14:16 |
remingtron |
rfrasur: another....meeting? |
| 14:16 |
yboston |
another poll or meeting? |
| 14:16 |
rfrasur |
yes...another meeting. Since this one is sparcely attended but there are some fairly important things on the agenda. |
| 14:17 |
remingtron |
ah, right. sure, +1 to that idea |
| 14:17 |
rfrasur |
It'd stink to have to wait until next month. |
| 14:17 |
yboston |
I am fine with another meeting this months, but |
| 14:17 |
yboston |
should we have a poll for just the next meeting, and /or a poll to find another time to meet monthly besides the first Thursday of the month? |
| 14:18 |
rfrasur |
(I wonder how many people are going to ALA MW) |
| 14:18 |
rfrasur |
Well, how about we just do one at a time. We can talk about it more at the next meeting which will hopefully add some new/more voices to the discussion. |
| 14:18 |
remingtron |
I agree |
| 14:19 |
yboston |
works for me |
| 14:19 |
rfrasur |
Okay, I'll put that together this today or tomorrow at the latest. |
| 14:19 |
yboston |
thanks! |
| 14:19 |
rfrasur |
mp |
| 14:20 |
yboston |
#action rfrasur will create a doodle poll for finding alternate January meeting time |
| 14:20 |
yboston |
rfrasur++ |
| 14:21 |
yboston |
do we want to switch to talking about new or old business? or something else? |
| 14:21 |
rfrasur |
I'm reading through the agenda and there's a lot that really requires more input from people who aren't here. |
| 14:22 |
yboston |
that makes sense |
| 14:22 |
remingtron |
yboston: want to update us on your intern's converstion stuff? |
| 14:22 |
rfrasur |
I guess I have have a question and comment about the hackaway. well, two. Remingtron asked one of them though :) |
| 14:22 |
remingtron |
any progress from people who started proofreading |
| 14:23 |
yboston |
there might be some confusion on that old agenda time regarding the intern. I do now have a new intern, that agenda item refers to the older interns work that you guys have looks at altready |
| 14:24 |
yboston |
and I have not been able to do anything with that work since the hack-a-way. been to busy with EG conference work |
| 14:24 |
remingtron |
okay. I added the link to : http://evergreen-ils.org/dokuwiki/doku.php?id=evergreen-docs:2.5_needs |
| 14:24 |
yboston |
I would like to say, I want to start doing something with what we started in the last hack-a-way next week |
| 14:25 |
remingtron |
yboston: I added some things to the "Old/Missing Sections" section on that wiki page |
| 14:25 |
rfrasur |
Yeah, I feel like I've been stalled with because of non-Evergreen stuff. |
| 14:25 |
rfrasur |
remingtron++ |
| 14:25 |
yboston |
thanks |
| 14:25 |
remingtron |
feel free to add status messages to those items |
| 14:26 |
rfrasur |
(oh good grief) stalled with hackaway progress on documentation |
| 14:26 |
remingtron |
rfrasur: thanks for finishing your thought! I was mighty confused. |
| 14:27 |
rfrasur |
oy vey. and it still barely made sense. |
| 14:27 |
* rfrasur |
points and grunts |
| 14:27 |
* remingtron |
is fluent in grunt |
| 14:27 |
yboston |
ha |
| 14:27 |
rfrasur |
excellent |
| 14:28 |
remingtron |
yboston: will your new intern be doing anything with Evergreen docs? |
| 14:28 |
yboston |
sadly, I just found out I am NOT getting an intern |
| 14:28 |
remingtron |
oh...sorry to bring that up..... |
| 14:28 |
yboston |
no problem |
| 14:29 |
rfrasur |
well, that stinks |
| 14:29 |
yboston |
I will try to find the time so I can contribute more to the docs |
| 14:29 |
yboston |
I will start with what we were working on at the hack-a-way |
| 14:29 |
remingtron |
sounds like we have a few sections that are mostly ready to add to master, right? |
| 14:30 |
yboston |
from the hack-a-way, yes |
| 14:30 |
yboston |
remingtron: we can set up a time to review what can be put in |
| 14:30 |
yboston |
to master |
| 14:31 |
yboston |
from the hack-a-way |
| 14:31 |
yboston |
and what still needs work |
| 14:31 |
remingtron |
sounds good, I like keeping track of progress on those things |
| 14:31 |
yboston |
thanks |
| 14:31 |
remingtron |
helps us know where to focus our efforts |
| 14:33 |
yboston |
I guess off the top off my head, my new year's goals for DIG would be to finish off the hack-a-way work, then focus on increasing DIG participation, and trying to get as much work done during the conference |
| 14:33 |
yboston |
ith some training or "open house" thrown somewhere in between |
| 14:34 |
rfrasur |
I like the idea of an open house during the conference. |
| 14:34 |
remingtron |
I won't be able to attend the conference, but I'll do my best to be virtually connected |
| 14:34 |
rfrasur |
I'm also interested to see if there's a DIG component to the regional conference that Rogan's doing. |
| 14:34 |
yboston |
actually, I was thinking right before the conference, just to get people pre-trained, but during is perfectly fine |
| 14:34 |
rfrasur |
yboston: that too. |
| 14:35 |
remingtron |
I'd vote for one or two training things before the conference, to give people a chance to prepare for lots-of-work-during-conference |
| 14:36 |
remingtron |
also, I've been collecting bitesize docs bugs, so I'll try to post those to LP soon |
| 14:36 |
yboston |
rfrasur: I gotta remember to ask Rogan, but then again, who from DIG is going? |
| 14:36 |
rfrasur |
or instead...whichever. Something that's easy for people to learn about the documentation and how to participate. |
| 14:36 |
yboston |
I am writing this stuff down |
| 14:36 |
rfrasur |
I dunno that anyone from DIG is going. There should be though. It's an important part of EG |
| 14:37 |
yboston |
#idea offer pre-conference DIG training or even during the conference |
| 14:37 |
rfrasur |
It's a major part for the end user (good grief - preaching to the choir) |
| 14:38 |
|
terran_ joined #evergreen |
| 14:38 |
* kbutler |
gets back from helping with ereader questions and reads back. |
| 14:38 |
rfrasur |
kbutler++ |
| 14:39 |
yboston |
are either of you going to Rogan's conference? |
| 14:39 |
yboston |
#idea find out if any DIG members are attending the Rogan organized regional conference, to help spread DIG |
| 14:40 |
remingtron |
I'm not planning on it |
| 14:40 |
kbutler |
I am not. It's not in my neck of the woods. |
| 14:40 |
yboston |
Neither was I because of my budget, but maybe in the future |
| 14:40 |
rfrasur |
I haven't seen recent information about it. In my case, probably not this year. I wouldn't be a good rep anyway since I don't have much more than basic info/knowledge with documentation. |
| 14:40 |
yboston |
MAybe I can speak about DIG remotely? |
| 14:41 |
rfrasur |
I'm not sure. Maybe RoganH can give some guidance or feedback at a later time. |
| 14:42 |
yboston |
i'll check in with him later |
| 14:42 |
kbutler |
One stumbling block I keep running into when I find a doc need is that... I don't know how to use it. That's why I was looking for documentation. But I'd like to /help/ make the documentation. Is there a way to identify people who might help with questions about specific modules? |
| 14:42 |
yboston |
#action yboston will ask Rogan about some type of DIG participation in the regional conference, however small |
| 14:42 |
|
hopkinsju joined #evergreen |
| 14:43 |
rfrasur |
kbutler: I think that's pretty common. |
| 14:43 |
rfrasur |
It's one thing to write the stuff, but then what? who? when? |
| 14:43 |
yboston |
We can try teaming up, and focusing in one section |
| 14:44 |
rfrasur |
kbutler, are you going to the conference? |
| 14:44 |
kbutler |
I am, yeah. |
| 14:44 |
yboston |
this two person or more team, specially a new DIG member and a veteran member can work together |
| 14:44 |
rfrasur |
okay, good |
| 14:44 |
rfrasur |
yboston, that's a good idea |
| 14:44 |
kbutler |
yboston: That's a good idea. |
| 14:44 |
rfrasur |
jinx |
| 14:45 |
remingtron |
kbutler: you mean, who should you talk to if you find a problem in the Serials module and don't know what it should be? or do you mean don't know the technology side of fixing it? |
| 14:45 |
kbutler |
yboston: It would be nice if we could also manage to get a developer in there for consultation |
| 14:45 |
yboston |
that is one fun thing that we did at the hack-a-way |
| 14:46 |
yboston |
what I have down in the past, I do some research , pull the most important questions together and email the developers. |
| 14:46 |
rfrasur |
Yes, especially on some of the more obscure things. I know that bshum has functioned in both capacities - developer and DIG |
| 14:46 |
kbutler |
remingtron: More along the lines of 'I'm looking for how to customize these receipts and the documentation is missing/old/incomplete' |
| 14:46 |
rfrasur |
and kmlussier and several others actually |
| 14:47 |
kbutler |
So then I think 'I could fix these docs' but I can't really because I don't know the correct info. |
| 14:47 |
remingtron |
ah, I see. |
| 14:48 |
* kmlussier |
isn't a developer |
| 14:48 |
yboston |
compare to us yes :) |
| 14:48 |
rfrasur |
no, but you know some stuff |
| 14:48 |
remingtron |
seems like you could just ask for a developer's help on IRC, right? |
| 14:48 |
rfrasur |
remingtron: good point |
| 14:48 |
kmlussier |
But I have found that if you tell developers that you are asking the questions so that you can create documentation, they are more than happy to answer your questions. |
| 14:48 |
remingtron |
that's probably the fastest way to get a knowledgeable answer |
| 14:50 |
yboston |
I can also understand that IRC can be intimidating, and then asking developers can be intimidating to |
| 14:50 |
yboston |
too |
| 14:51 |
remingtron |
that's true, though kbutler has already proven fearless |
| 14:51 |
yboston |
I can offer my help to help craft questions for developers, I kinda speak their language (though not very fluent in Perl yet) |
| 14:51 |
kbutler |
ha! Hardly so. :) |
| 14:52 |
rfrasur |
It's probably more intimidating for the people who aren't here right now ;) |
| 14:52 |
yboston |
rfrasur: probably |
| 14:52 |
yboston |
BTW< we are at the 52 minute mark |
| 14:53 |
kmlussier |
Depending on the area you are documenting, questions posted to the general list might help too. There are a lot of non-developers who might know how things work, but who haven't had a chance to contribute to the docs. |
| 14:53 |
yboston |
kmlussier: absolutely true |
| 14:54 |
yboston |
one observation I had from the hack-aw-ay was that I have a lot of personal workflows for working on documentation, that are ironically not documented anywhere |
| 14:54 |
remingtron |
sounds like that's a pretty good recommendation then: ask on the general list and/or IRC, and state that you are asking in order to improve the docs |
| 14:54 |
yboston |
I got a chance to explain some of these wok flows to the hack-a-way participants, but we did not document them, they are so far just oral traditions |
| 14:55 |
kbutler |
Yeah. It's just a matter of formulating the questions. |
| 14:55 |
yboston |
remingtron: I also feels that is helps if you offer a draft of how you would write the docs with some blanks, so that when a developr/knowlegeable user responds they have something to just edit to get you a reply |
| 14:55 |
rfrasur |
I think it'd be worth documenting your workflows. It'll provide ease of entry for others. |
| 14:56 |
remingtron |
yboston: I agree, we should document your workflows |
| 14:56 |
remingtron |
how about on the wiki? |
| 14:56 |
yboston |
the wiki would be the perfect place |
| 14:57 |
yboston |
#idea document workflow for creating/editing DIG documentation on wiki |
| 14:58 |
yboston |
I do mention one or two of these informal workflows in my training resonation, but I should put them somewhere on the wiki. I believe remingtron update some already |
| 14:58 |
remingtron |
yboston: you might want to edit or borrow from : http://evergreen-ils.org/dokuwiki/doku.php?id=evergreen-docs:how-to-contribute-documentation |
| 14:59 |
remingtron |
one last question, then I have to leave |
| 15:00 |
yboston |
remingtron: yes, that is the stuff you updated recently |
| 15:00 |
remingtron |
does anyone have feedback or ideas for the DIG style guide (draft)? |
| 15:00 |
remingtron |
http://evergreen-ils.org/dokuwiki/doku.php?id=evergreen-docs:dig_style_guide |
| 15:01 |
rfrasur |
not at this point |
| 15:01 |
yboston |
I might have some feedback on how to format "code / bash" commands, but I need to do some research first |
| 15:01 |
yboston |
I need look into how many formatting styles are currently used all over the docs for bash or other code, don't think we have been consistent this whole time |
| 15:02 |
yboston |
or maybe we have? |
| 15:02 |
kbutler |
not right now. I haven't done enough to come up with any. |
| 15:02 |
yboston |
BTW, we are slightly past the 1 hour mark |
| 15:03 |
remingtron |
okay, if any of you use the style guide and find something confusing or have other suggestions, you can edit the page or email the DIG list |
| 15:03 |
yboston |
remingtron: thanks again for putting that together |
| 15:03 |
remingtron |
you're welcome |
| 15:03 |
kbutler |
remingtron++ |
| 15:03 |
yboston |
should we wrap up? |
| 15:04 |
remingtron |
sounds good to me |
| 15:05 |
yboston |
any fins thoughts? |
| 15:05 |
yboston |
any final thoughts? |
| 15:06 |
* rfrasur |
waves |
| 15:06 |
rfrasur |
yboston++ |
| 15:06 |
yboston |
OK folks, see you at the alternate January meeting or next month |
| 15:06 |
yboston |
#endmeeting |
| 15:06 |
pinesol_green |
Meeting ended Thu Jan 9 15:06:49 2014 US/Eastern. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) |
| 15:06 |
pinesol_green |
Minutes: http://evergreen-ils.org/meetings/evergreen/2014/evergreen.2014-01-09-14.00.html |
| 15:06 |
pinesol_green |
Minutes (text): http://evergreen-ils.org/meetings/evergreen/2014/evergreen.2014-01-09-14.00.txt |
| 15:06 |
pinesol_green |
Log: http://evergreen-ils.org/meetings/evergreen/2014/evergreen.2014-01-09-14.00.log.html |
| 15:09 |
remingtron |
yboston++ |
| 15:09 |
kbutler |
yboston++ |
| 15:10 |
|
stevenyvr2 joined #evergreen |
| 15:33 |
|
finnx joined #evergreen |
| 15:35 |
|
finnx joined #evergreen |
| 15:36 |
|
finnx joined #evergreen |
| 15:36 |
jeff |
dbwells, senator: so the issue i was encountering was due to a blank subfield a in the holdings_code for the serial issuances. |
| 15:37 |
|
finnx joined #evergreen |
| 15:39 |
|
finnx joined #evergreen |
| 15:39 |
senator |
jeff: glad you were able to fix it. i think we see that as bad data. one could make a bug report to the effect that evergreen should be more tolerant somehow (it used to be, but not intentionally i think, and i don't know in what way such holding_code's corrupted generated summaries) but i'm not sure what the system really ought to do. maybe instead of more tolerance it just needs some kind of |
| 15:39 |
senator |
more specific check that can point out the problem to the user [spitballing] |
| 15:41 |
dbwells |
jeff: that's expected, but the real question for me is whether that bad data was predicted (i.e. maybe the blank "a" in the pattern (odd, but at least conceivably meaningful) somehow goofed up the holdings) |
| 15:41 |
dbwells |
caused the predictions to fail |
| 15:42 |
dbwells |
Where fail = generate predictions with empty "a" subfields. |
| 15:43 |
dbwells |
jeff: the fact that the holdings_code you posted has "AUTOGEN" in the notes field concerns me, since that means it was generated at one time, but maybe somebody mangled it along the way. |
| 15:48 |
jeff |
does AUTOGEN signify that the wizard was used to create the pattern_code? |
| 15:49 |
jeff |
or does that signify something else? |
| 15:49 |
dbwells |
AUTOGEN appears in holding_code, not pattern_code |
| 15:49 |
dbwells |
maybe what you meant |
| 15:50 |
dbwells |
Yes, it is a simple marker which generally signifies that the holding was generated through predictions. |
| 15:50 |
dbwells |
Of course there is nothing to stop someone from adding it to any holding manually. |
| 15:51 |
dbwells |
I can see this most likely happening through copy/paste holding creation. |
| 15:51 |
jeff |
got it. |
| 15:52 |
dbwells |
It is technically just a "nonpublic note" in the holding field data. |
| 15:59 |
jeff |
what data factors into the predictions used to generate the holding_code values? i had one set of issuances with "a","1" (every one was "1"), and then the other with "a","" |
| 15:59 |
jeff |
(and feel free to just tell me to go look at the code if that's best here) |
| 16:01 |
dbs |
csharp: hmm. working/user/csharp/fedora_maketext_signoff seems to be missing a (the!) commit? |
| 16:05 |
dbwells |
jeff: It's quite a complex system, so I am not sure how to answer your question, other than to say "lots of factors" :) |
| 16:06 |
dbwells |
jeff: It isn't abnormal to have "a" stay as "1" for a while, it just means the top level of enumeration hasn't incremented yet. |
| 16:06 |
|
mrpeters left #evergreen |
| 16:06 |
dbwells |
That said, most journals you would be receiving are likely well past "volume" 1. |
| 16:07 |
dbwells |
The most common case by far is that "a" will increment on a yearly basis. |
| 16:08 |
dbwells |
This can be defined as a certain number of issues, or as a calendar triggered change. |
| 16:12 |
dbwells |
jeff: p.s. I am not sure if you *really* want to poke around in the predictions code. You can never un-see what you will see in there... |
| 16:13 |
* jeff |
laughs |
| 16:13 |
jeff |
are predictions based on serial.caption_and_pattern.pattern_code plus some other bits of info? |
| 16:15 |
csharp |
dbs: bleh - I'll re-do it - sorry |
| 16:15 |
csharp |
juggling too much today, obviously ;-) |
| 16:16 |
jeff |
hrm. found what i think is another example of "tpac loses auth token in staff client, failures are subtle" |
| 16:16 |
csharp |
jeff++ # fighting the good fight |
| 16:16 |
dbwells |
existing holding_code + pattern_code + sometimes issuance date info (if holding_code is incomplete) = future holding_code values for predictions. |
| 16:16 |
dbs |
csharp++ # right there with you |
| 16:17 |
Dyrcona |
I'm trying to figure out if 780$t is included in existing title indexes via MODS, and if not, then how best to add it. |
| 16:17 |
dbwells |
jeff: I don't think it's conceptually a complicated system, but the devil (as usual) is in the details. |
| 16:18 |
Dyrcona |
My main stumbling block is trying to parse XSL in my head and figure out what it would be called in the MODS output. |
| 16:19 |
csharp |
dbs: okay - pushed the commit :-/ |
| 16:19 |
csharp |
thanks! |
| 16:19 |
dbwells |
Dyrcona: If you haven't already, I'd pull up the MODS record via supercat and see if the text you are looking for is in there. |
| 16:20 |
dbwells |
e.g. http://ulysses.calvin.edu/opac/extras/supercat/retrieve/mods32/record/109729 |
| 16:23 |
Dyrcona |
dbwells: I knew the answer was going to be a variation on "run a record through XSLT." ;) |
| 16:24 |
dbs |
csharp++ # sweet |
| 16:24 |
dbs |
Dyrcona: alternate approach is to grep the mods xsl for 780 and read from there :) |
| 16:24 |
|
finnx joined #evergreen |
| 16:24 |
dbwells |
Dyrcona: Yeah, I have a lot of those URLs in my browser autocomplete because it is the laziest way I have found. |
| 16:24 |
Dyrcona |
dbs: I've been doing the latter and my XSL Fu is weak. |
| 16:25 |
* dbs |
notes that if 780$t isn't there, and you add it, then you will undoubtedly get patrons asking why a search for "Some title" returned "Entirely different title" |
| 16:25 |
dbs |
Dyrcona: that's why dbwells' approach is bestest! |
| 16:26 |
pinesol_green |
[evergreen|Dan Scott] Fedora needs Locale::Maketext::Lexicon too - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=38fcad9> |
| 16:26 |
Dyrcona |
Right. I'll find a record with the 780 $t and 0 0 for indicators, then request it via feed. |
| 16:26 |
Dyrcona |
Thanks, guys. |
| 16:27 |
Dyrcona |
That is easier than what I was thinking of doing, which was find a record, copy its marc, and run that through xslt on the command line. |
| 16:27 |
dbs |
looking at MARC21MODS33 xsl suggests that it will be creating titleInfo/title elements for 780$t |
| 16:28 |
dbwells |
Dyrcona: my quick research suggests the MODS field is "<relatedItem type="preceding">" with child tags of <titleInfo><title>. |
| 16:28 |
Dyrcona |
dbwells++ |
| 16:29 |
Dyrcona |
My XSL perusal was heading that way, but I was confusing myself as to the order of the XML tags on output. |
| 16:29 |
dbs |
but only within the relatedItem... what dbwells said |
| 16:31 |
Dyrcona |
That does not appear to be part of any of the existing title indexes. |
| 16:32 |
Dyrcona |
The question is: Would it be better to use the MODS or a XPATH query on the MARC if I want to make a metabib_field for this? |
| 16:43 |
dbwells |
Dyrcona: IMHO, if we are talking about straight extraction of a single subfield, it probably doesn't matter too much either way. The MODS XPATH would probably be a little more readable to anyone who sees your config, unless they happen to know what 780|t is. |
| 16:44 |
|
ktomita joined #evergreen |
| 16:44 |
|
fparks joined #evergreen |
| 16:44 |
|
sseng joined #evergreen |
| 16:45 |
Dyrcona |
dbwells: Thank you for your opinion. I think I'll go with MARC, since the MODS extract doesn't appear to take indicators into account. |
| 16:50 |
|
smyers_ joined #evergreen |
| 16:51 |
|
jwoodard joined #evergreen |
| 17:05 |
|
mdriscoll1 left #evergreen |
| 17:13 |
|
mmorgan left #evergreen |
| 17:19 |
|
dcook joined #evergreen |
| 17:19 |
Bmagic |
I am having a heck of a time getting marc records into a perl program and then written back to disk without losing special characters |
| 17:20 |
Dyrcona |
Bmagic: What is the source of the MARC records and what encoding are they in: UTF8 or MARC8? |
| 17:21 |
Bmagic |
Dyrcona: I would love to know how to tell but I think they are utf8 |
| 17:22 |
Dyrcona |
Bmagic: You look at the leader of one of the records, if position 09 is the letter 'a', then that record is UTF8. |
| 17:22 |
Bmagic |
they are blank |
| 17:22 |
Dyrcona |
If it is blank, it is supposed to be MARC-8. |
| 17:22 |
Bmagic |
wait, they are utf8 |
| 17:22 |
dbs |
That is a common problem with MARC records :/ |
| 17:23 |
Bmagic |
LDR 00751nam 22002057 4500 |
| 17:23 |
Bmagic |
The "a" in "nam" is what you mean? |
| 17:23 |
Dyrcona |
Well, that says it is MARC-8. |
| 17:23 |
Dyrcona |
No, that is the MARC type. |
| 17:24 |
Bmagic |
ok then, they are marc8, I use this code |
| 17:24 |
Dyrcona |
The a would be after the m and before the 2. |
| 17:24 |
Bmagic |
my $file = MARC::File::USMARC->in( $inputFile ); |
| 17:24 |
Bmagic |
while ( my $marc = $file->next() ) |
| 17:24 |
Dyrcona |
09 means count to the 9th positioning counting the first as 0. |
| 17:24 |
Bmagic |
$output.=$marc->as_usmarc(); |
| 17:25 |
Bmagic |
open(OUTPUT, '>> '.$file) or die $!; binmode(OUTPUT, ":utf8"); print OUTPUT "$line\n"; |
| 17:25 |
Dyrcona |
Well, that should just copy the input to the output without any conversions. |
| 17:25 |
Bmagic |
the output $file is in another scope so it is not the same file as the first one |
| 17:26 |
Bmagic |
going through that process, I lose characters |
| 17:26 |
|
fparks joined #evergreen |
| 17:26 |
Bmagic |
Diol{acute}e becomes Diolâe |
| 17:26 |
|
dconnor joined #evergreen |
| 17:27 |
Bmagic |
Francisco V{esc}b4{esc}sasquez becomes Francisco Vb4sasquez |
| 17:27 |
Dyrcona |
That might be the binmode, or your records are not really MARC-8. |
| 17:27 |
Dyrcona |
As dbs said: "A common problem with MARC records." |
| 17:27 |
Bmagic |
so, what other options can I expierement with on the binmode output? |
| 17:28 |
Dyrcona |
Bmagic: I suggest reading this: http://search.cpan.org/~gmcharlt/MARC-Charset-1.35/lib/MARC/Charset.pm |
| 17:28 |
Dyrcona |
Try the examples in that to convert to UTF-8. |
| 17:28 |
Bmagic |
Dyrcona: oh yeah, that |
| 17:28 |
Dyrcona |
I'd also output to MARCXML so the output is human readable, just to check that the output makes sense. |
| 17:29 |
Bmagic |
when I go to XML I get more errors |
| 17:29 |
Bmagic |
"no mapping found for [0xCC] at position 0 " |
| 17:29 |
Dyrcona |
You'll need to convert to UTF-8 and scrub the file. |
| 17:29 |
Dyrcona |
What version of Evergreen are you on? |
| 17:29 |
Bmagic |
marcedit has no problems with the file |
| 17:30 |
Bmagic |
2.4.1 |
| 17:30 |
|
ktomita joined #evergreen |
| 17:30 |
|
sseng joined #evergreen |
| 17:30 |
Dyrcona |
You're not using MARCEdit here. |
| 17:30 |
|
smyers_ joined #evergreen |
| 17:30 |
|
dconnor joined #evergreen |
| 17:30 |
dbs |
Bmagic: you should probably share a record or two |
| 17:30 |
dbs |
MARCEdit might do things like look for UTF8 sequences and ignore LDR09 |
| 17:31 |
Bmagic |
no I am not using marcedit, Im trying to use perl. I was just illistrating that the file is sound as far as marcedit is concerned |
| 17:31 |
dbs |
Who knows. MARCEdit isn't open source :/ |
| 17:31 |
Bmagic |
lol |
| 17:31 |
|
fparks joined #evergreen |
| 17:31 |
Dyrcona |
Have a look at OpenILS::Utils::Normalize. I think 2.4.1 will have the clean_marc function. |
| 17:32 |
Dyrcona |
MARCEdit may be more tolerant of garbage. |
| 17:32 |
Dyrcona |
Time for me to go. I'll be back later. |
| 17:39 |
dbwells |
Bmagic: despite kinda sorta being text, MARC-8 records should written out as binary, since no OS on earth (that I know of) understands MARC-8 as a text encoding. |
| 17:40 |
Bmagic |
dbwells: binmode(OUTPUT, ":utf8"); is the right thing? |
| 17:41 |
dbs |
I would not use the ":utf8" flag |
| 17:41 |
dbs |
Bmagic: look at Open-ILS/src/support-scripts/marc_export.in |
| 17:41 |
dbwells |
No, that says you will be outputting utf8. If you truly just want to round-trip MARC-8 data, you probably want just binmode(OUTPUT); (or no binmode() call at all? not sure about default behavior). |
| 17:42 |
dbs |
binmode(STDOUT, ':raw') if ($encoding ne 'UTF-8'); # That's for MARC8 records |
| 17:43 |
* dbs |
feels like he's poling blindly at Bmagic's problems |
| 17:43 |
dbs |
s/poling/poking/ |
| 17:45 |
dbwells |
Bmagic: to reiterate what dbs suggested, you would get better advice if we could see some records. Otherwise, you can try binmode(OUTPUT, ':raw'); (I think ':raw' is the default, but it never hurts to be explicit, and maybe even understand what is going on :) |
| 17:45 |
Bmagic |
dbwells: that helps, I am trying it now |
| 17:47 |
Bmagic |
raw! |
| 17:47 |
Bmagic |
that did it |
| 17:48 |
dcook |
\o/ |
| 17:48 |
dcook |
Treating marc8 records like utf8 records never goes well |
| 17:48 |
Bmagic |
dcook: apparently |
| 17:48 |
dcook |
I'm not familiar with evergreen's z3950 capabilities, but that's worth keeping in mind there too |
| 17:49 |
dcook |
Although not all databases advertise whether their records are utf8 or marc8 |
| 17:50 |
dbs |
Evergreen is pretty good about setting LDR09 to 'a' for all of the records it ingests. Because we're UTF8 only in the database. |
| 17:50 |
dbs |
As for bad z39.50 sources that you might import records from, well, there's only so much we can do |
| 17:51 |
dcook |
Oh, I just meant whether you can specify the encoding when you execute your query |
| 17:51 |
* dbwells |
heads home |
| 17:51 |
Bmagic |
laters |
| 17:52 |
* dcook |
wishes that he knew all the encoding magicks |
| 17:52 |
dcook |
Of course, then you can have marcxml records that have a mixture of utf8, windows 1252, etc... |
| 17:52 |
dbs |
dcook: not really sure what you mean, to be honest |
| 17:53 |
dcook |
dbs: Makes sense, hehe |
| 17:53 |
dcook |
In Koha, you can specify whether a z3950 target is using marc8 or utf8 |
| 17:53 |
dcook |
Probably so that it can then convert it to utf8 when it comes in |
| 17:53 |
dcook |
Admittedly, I haven't looked too far into it. |
| 17:53 |
dbs |
dcook: oh. and that overrides what the MARC records themselves say? |
| 17:54 |
dbs |
we just trust the MARC records |
| 17:54 |
dcook |
I suspect so. I'd have to poke around and see. |
| 17:54 |
dbs |
if you have a bad source with untrustworthy MARC records, then it's probably a bad idea to import anything from it |
| 17:54 |
dcook |
Interesting. Hmm, maybe I'll have to keep that in mind next time I look. |
| 17:54 |
dbs |
I think I see what you mean now |
| 17:54 |
dcook |
True true |
| 17:55 |
dcook |
Hmm, when I look at Koha, it looks like there are other encoding options.. |
| 17:55 |
dcook |
Probably for UNIMARC |
| 17:57 |
dcook |
EUC-KR |
| 17:57 |
dcook |
Ahh, Asian languages |
| 17:58 |
dcook |
Apparently it's more popular than utf8 in Korea |
| 17:58 |
dcook |
In case anyone was wondering :p |
| 17:58 |
* dcook |
wanders off again |
| 18:00 |
dbs |
dcook++ |
| 18:01 |
dcook |
Hmm? |
| 18:04 |
pinesol_green |
[evergreen|Jeff Godin] Treat empty username as invalid in user editor - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=48c1b5b> |
| 18:22 |
|
Dyrcona joined #evergreen |
| 20:05 |
|
stevenyvr2 left #evergreen |
| 20:33 |
|
hopkinsju joined #evergreen |
| 23:19 |
|
stevenyvr2 joined #evergreen |
| 23:19 |
|
stevenyvr2 left #evergreen |
| 23:32 |
|
stevenyvr2 joined #evergreen |
| 23:33 |
|
stevenyvr2 left #evergreen |
| 23:53 |
|
zerick joined #evergreen |
