2010-07-13T01:31:24 *** mck9 has left #evergreen 2010-07-13T01:35:56 *** dbs has joined #evergreen 2010-07-13T03:00:57 *** dbs has quit IRC 2010-07-13T03:10:52 *** StephenGWills has quit IRC 2010-07-13T03:33:15 *** dbs has joined #evergreen 2010-07-13T05:50:09 *** shadowspar has quit IRC 2010-07-13T07:02:50 *** shadowspar has joined #evergreen 2010-07-13T07:39:17 *** sfortin has joined #evergreen 2010-07-13T08:12:29 *** greg_g has joined #evergreen 2010-07-13T08:14:58 *** greg_g has quit IRC 2010-07-13T08:22:34 *** mck9 has joined #evergreen 2010-07-13T08:23:05 *** gdunbar has joined #evergreen 2010-07-13T08:36:43 Dibs on # 0334 for a database upgrade 2010-07-13T08:39:13 *** Granitize has joined #evergreen 2010-07-13T08:43:21 *** Dyrcona has joined #evergreen 2010-07-13T08:51:32 *** mrpeters-isl has quit IRC 2010-07-13T09:04:27 *** Meliss has joined #evergreen 2010-07-13T09:05:20 *** StephenGWills has joined #evergreen 2010-07-13T09:14:11 *** StephenGWills_ has joined #evergreen 2010-07-13T09:15:05 *** leed has joined #evergreen 2010-07-13T09:17:17 *** StephenGWills has quit IRC 2010-07-13T09:17:18 *** StephenGWills_ is now known as StephenGWills 2010-07-13T09:17:34 *** jenny has joined #evergreen 2010-07-13T09:21:23 *** Meliss has quit IRC 2010-07-13T09:26:03 *** yboston has joined #evergreen 2010-07-13T09:27:24 *** mrpeters-isl has joined #evergreen 2010-07-13T09:38:23 *** Meliss has joined #evergreen 2010-07-13T09:55:27 *** Granitize has quit IRC 2010-07-13T09:56:22 *** Granitize has joined #evergreen 2010-07-13T10:06:43 *** youdonotexist has joined #evergreen 2010-07-13T10:29:10 *** Granitize has quit IRC 2010-07-13T10:45:14 *** kmlussier has joined #evergreen 2010-07-13T10:46:16 *** sfortin has quit IRC 2010-07-13T10:55:44 *** sfortin has joined #evergreen 2010-07-13T11:28:48 we can haz a script that applies authority control to an uncontrolled set of bib records... still taking shape, but it VERKS 2010-07-13T11:29:07 dbs++ # mwahahaha... it VERKS! IT VERKS! 2010-07-13T11:31:03 *** granitize has joined #evergreen 2010-07-13T11:34:10 authorities in Evergreen 2.0 are going to blow people's minds 2010-07-13T11:34:17 *** Granitize1 has joined #evergreen 2010-07-13T11:36:01 hey granitize / Granitize1 2010-07-13T11:37:02 dbs: script or stored proc? 2010-07-13T11:37:53 miker_: script. I wanted to take advantage of the existing OpenSRF methods that were available (validate.tag) and didn't think calling out to OpenSRF from within a stored proc would make sense 2010-07-13T11:38:14 indeed ... nice 2010-07-13T11:38:16 dbs++ 2010-07-13T11:38:38 I imagine it's ... non-super-fast :) 2010-07-13T11:39:00 Could always reimplement it to become a function one could call but implementation speed was the first priority 2010-07-13T11:39:15 (as in, how fast can I get something working; not how fast will something work - heh) 2010-07-13T11:39:26 for retrospective linking, I don't think speed is #1 (IMO) 2010-07-13T11:39:41 yeah. for maintenance purposes, that would be a different story 2010-07-13T11:40:03 well, that's what the triggers are for! ;) 2010-07-13T11:41:56 miker_++ # so much of what we've been doing is low-hanging fruit because you were way up on the branches, jumping up and down 2010-07-13T11:42:44 *** jeffgreenca has joined #evergreen 2010-07-13T11:48:33 I'll check in what I've got going for now; will spend more time on it tomorrow (as will become evident once you look at it). damned bib field::auth field maps. 2010-07-13T11:49:10 speaking of speed and the lack thereof, we'll probably add a second loop through the bibs just for the floating subdivisions. heh. 2010-07-13T11:50:04 heh 2010-07-13T11:53:49 *** shadowspar has quit IRC 2010-07-13T11:54:07 *** jenny has quit IRC 2010-07-13T11:56:53 all right, r16918 for the morbidly curious. remember, still early days 2010-07-13T11:58:37 ah - and I need to check to see if the given auth record already has a $0 entry in a given bib field. 2010-07-13T11:58:52 dbs: sounds great! 2010-07-13T11:59:14 miker_: do you happen to have a fix hanging around in your bzr branch for multiple 901 propagation? I'm seeing lots of 901's build up as I edit records :) 2010-07-13T11:59:20 * dbs has to scoot - back on later 2010-07-13T11:59:24 *** dbs has quit IRC 2010-07-13T11:59:46 @later tell dbs I'll look at the 901 issue 2010-07-13T11:59:46 miker_: The operation succeeded. 2010-07-13T12:00:06 Anyone doing printed notices? I need to pick someone's brain about this (it'd be brief)... 2010-07-13T12:00:30 I'm in a 1.6.0.6 environment (in case that makes a difference). 2010-07-13T12:01:43 moodaepo: Did you ever get your printed notices working (again)? 2010-07-13T12:02:56 we use UMS for printed notices. we send them an XML file, done. i'm a fan of the approach. :-) 2010-07-13T12:03:56 How much does it cost, jeff? 2010-07-13T12:04:17 How do you generate your XML file? 2010-07-13T12:04:59 @later tell dbs I wonder if it's because of the retained formatting in the xml? newlines throwing off the regexp used to remove the existing 901 tags 2010-07-13T12:04:59 miker_: The operation succeeded. 2010-07-13T12:06:49 xml file is mostly as generated by the generate_circ_notices.pl --generate-global-templates output. price is worth it to us. worked out to be cheaper than what we were paying for supplies and labor. we use them for overdues and (soon) billing/lost/damaged/etc. 2010-07-13T12:07:29 the script is slightly modified on the server side, delivered to us, we mangle it a little more to remove things like patrons with e-mail addresses (they don't receive postal overdues), and send it on to UMS 2010-07-13T12:08:02 you'd need to contact them for pricing. tell 'em jeff at TADL sent you. ;-) 2010-07-13T12:08:37 Interesting thought for the long-term. Right now, I gotta get something out today (and they have no labor charges as the librarians stuff the envelopes). 2010-07-13T12:09:19 the two other approaches that i'm aware of are the XSLT transform on that same XML data, which can be used to print 8.5"x11" sheets which can be mailed, or something Indiana had for generating PDFs -- I don't know if it made it back to trunk or if it was local-only. I thought that ESI authored it. 2010-07-13T12:09:53 for the XSLT approach, see Overdue Notice Generation here: http://mcls.org/wiki/index.php/How-To's 2010-07-13T12:12:36 Yeah, I've read that. What I was hoping to do was talk/chat with someone who was actually doing it... 2010-07-13T12:14:42 That How-To, just for the record, is great if someone's given you the XML and already has the process in place to handle the XSLT automatically (and invisibly); it's not much help. I'll try posting to one of the lists... 2010-07-13T12:15:06 john at branch authored the XSLT and the write-up, I believe. he would be a good one to talk/chat with regarding it. 2010-07-13T12:15:14 convert the xml to csv (using perl, java, etc.) and use some Microsoft Office product? 2010-07-13T12:17:10 phasefx: no comment. :P 2010-07-13T12:17:17 * phasefx grins 2010-07-13T12:17:46 phasefx: Yeah; here's the problem: the questions about the process (overall) are not important: I have the general solution. I want to talk to someone about the nuts and bolts: what have they found effective as far as a command line tool to do the XLS transform step? How do they deliver the finished (in my case, the target is HTML) to the user who's actually going to print the notices? (That... 2010-07-13T12:17:47 ...sort of thing....) 2010-07-13T12:19:07 agJohn: xsltproc (command and apt package) for xslt processing 2010-07-13T12:19:38 miker_: Thanks; most helpful. 2010-07-13T12:20:30 Another specific question: Is there a reasonable way to have the Evergreen server deliver the HTML to a browser (if someone knows the proper URL); or is that just a bad idea? 2010-07-13T12:20:55 (My thought was it'd be a URL that you could not, of course, navigate to.) 2010-07-13T12:21:23 (You'd have to just put in the whole path to get to the finished HTML so it could be printed from the browser.) 2010-07-13T12:23:22 a URL for staff? you can pick a directory and protect it with OILSProxy so that you need EG credentials 2010-07-13T12:23:40 using the generate_circ_notices.pl and xsltproc you could easily do that, but i would recommend you use evergreen credentials to require login to the url. 2010-07-13T12:24:16 see how is protected in the example eg_vhost.conf 2010-07-13T12:24:31 *** Granitize1 has left #evergreen 2010-07-13T12:31:25 phasefx: Yes, a URL for staff; and yes, I could protect it.... Sorry to bug everyone; obviously not the right forum for the questions I need answers to... 2010-07-13T12:42:08 cataloging question: how can one know, from bib-only data, that a work is a multi-volume set like an encyclopedia or a tv series, where the attached callnumber object (in EG) are not necessarily equivelant? 2010-07-13T12:42:24 objects 2010-07-13T12:42:46 (fixed field information would be preferable) 2010-07-13T12:44:55 good question, and while i do not have an answer, i am interested in both the answer and the line of thought that led to the question. :) 2010-07-13T12:45:19 jeff: I'm sure you can guess :) 2010-07-13T12:46:36 (and assuming good cataloging...) 2010-07-13T12:46:40 yes 2010-07-13T12:48:45 miker_: did you see my question from yesterday, on if there are any in-the-works changes to holds that i could/should know about before trying to develop a more complete understanding of the current implementation? 2010-07-13T12:54:59 @later tell dbs well, embedded newlines does not seem to be a problem for the 901-removing regexp 2010-07-13T12:54:59 miker_: The operation succeeded. 2010-07-13T12:55:55 jeff: hrm... we're looking at adding acp.status to the hold matrix for in-db, but I don't think there's anything earth-changing coming 2010-07-13T12:56:03 nothing like script-to-in-db 2010-07-13T12:58:04 miker_: one thing i've been thinking of trying to tweak is ensuring that some copies with currently "untargetable" status (on order, in process) are added to ahcm. I suspect that they are excluded from targeting only so that they don't show on a pull list (because that would be silly). 2010-07-13T12:58:39 they're excluded because their status makes them untargettable 2010-07-13T12:58:47 and uncapturable 2010-07-13T12:58:50 the idea being, if they are added to ahcm, they will be captured at first checkin, rather than requiring that we 1) wait for retargeting or 2) manually retarget some/all holds. 2010-07-13T12:59:03 op-capture would try to grab them if they were on the ahcm 2010-07-13T12:59:43 oh, you want that 2010-07-13T12:59:43 our workflow is okay with op-capture trying to capture them when we check them in -- are there workflows that aren't okay with that? 2010-07-13T12:59:51 well, just make on-order holdable 2010-07-13T12:59:58 they won't show up on a pull list 2010-07-13T13:00:05 only available/reshelving does 2010-07-13T13:00:23 i believe that on-order is holdable and opac visible -- if the only copies in the system are on-order, you can place a hold. 2010-07-13T13:00:51 op-capture should grab them 2010-07-13T13:01:38 *** dbs has joined #evergreen 2010-07-13T13:02:41 dbs: a bunch of @later coming your way :) (well, not a bunch... some) 2010-07-13T13:03:02 hit me, pinesol 2010-07-13T13:03:18 heh, oh the rollercoaster! 2010-07-13T13:03:41 miker_: I don't mind banging on it, I just didn't want to invest a couple of hours if you happened to have the fix already :) 2010-07-13T13:04:11 dbs: right now, WORKSFORME :( 2010-07-13T13:04:59 miker_: multi-part volumes such as encyclopedia are easily distinguished by LDR/06 = v (y for serials) in the MFHD record, of course! 2010-07-13T13:05:06 http://www.loc.gov/marc/holdings/hd853878.html 2010-07-13T13:05:25 miker_: OHREALLY? 2010-07-13T13:06:49 * dbs will bang on the 901 2010-07-13T13:07:06 dbs++ 2010-07-13T13:07:26 dbs: but no bib-only data for multi-volume OTTOYH 2010-07-13T13:08:53 looking at some "here's how we catalog here at $SCHOOL" docs, it seems to veer quickly into "put our holdings information in the MARC in this fashion" 2010-07-13T13:09:07 Integrating resource, maybe? 2010-07-13T13:09:08 A stretch would be LDR/24=e for BibLvl = s (http://www.loc.gov/marc/bibliographic/bd008s.html ) 2010-07-13T13:09:27 dbs: yeah, that's what I was looking at 2010-07-13T13:10:20 s/LDR/008/ 2010-07-13T13:10:32 @curse MARC 2010-07-13T13:10:32 dbs: Error: "curse" is not a valid command. 2010-07-13T13:10:56 all I want is "this thing has parts" ... bah 2010-07-13T13:11:22 miker_: could always try AUTOCAT 2010-07-13T13:11:32 dem's the masters 2010-07-13T13:11:45 *** phasefx_ has quit IRC 2010-07-13T13:13:54 *** phasefx_ has joined #evergreen 2010-07-13T13:15:24 miker_: one other question - were you intending to make are's automatically be ingested at the database level like bibs? 2010-07-13T13:16:49 dbs: ideally, yes. but I don't have plans to work on it now. if your group is feeling suacy ... :) 2010-07-13T13:17:08 heh, we'll see how far we get :) 2010-07-13T13:17:12 hrm. i wonder if our "on order" copies are in a null or non-holdable shelving location. 2010-07-13T13:19:39 AHHH 2010-07-13T13:20:12 doesn't match ' stinking namespaces 2010-07-13T13:21:29 is it "we hates them?", or "we hateses them?" 2010-07-13T13:21:55 E']*?\s*tag="901".+?' works and appears to be safe 2010-07-13T13:22:17 we hatesess them 2010-07-13T13:24:51 we hat[es]* them 2010-07-13T13:25:41 * dbs goes out for a mind-cleansing walk 2010-07-13T13:27:42 noooooooo 2010-07-13T13:29:15 agJohn: Just got back from meetings if you need help with the XML/XSLT let me know I used (heavily edited) the CSS/XSLT from > http://www.branchdistrictlibrary.org/professional/mieg_overdues.php and the stock generate_circ_notices.pl to do print overdues, I can send over the files. Some what 'secured' the files using htaccess. The John Rucker and Bill Ott helped me out : ) 2010-07-13T13:29:21 * moodaepo goes to get lunch 2010-07-13T13:36:35 *** jeffgreenca_ has joined #evergreen 2010-07-13T13:37:47 *** jeffgreenca has quit IRC 2010-07-13T13:38:01 *** jeffgreenca_ is now known as jeffgreenca 2010-07-13T13:41:08 *** jenny has joined #evergreen 2010-07-13T13:53:12 *** phase_bb has quit IRC 2010-07-13T14:22:49 moodaepo: When you get back, ping me if you would. 2010-07-13T14:24:03 agJohn: Will be off to a meeting soon... 2010-07-13T14:28:19 just confirmed that our production database has records with the moodaepo: Watch for an email from me... 2010-07-13T14:28:58 grabbing 0335 2010-07-13T14:28:59 agJohn: Will do! 2010-07-13T14:29:42 dbs: I did not think you could get those through the marc2bre/direct_ingest/pg_loader sequence... We always make people fix those (or ignore them) when extracting data. 2010-07-13T14:30:30 agJohn: there are plenty of ways to get those. 2010-07-13T14:31:06 No doubt. . . We just never happened to find any that "worked" when doing migrations.... 2010-07-13T14:31:27 try them in vandelay, for example 2010-07-13T14:31:50 will fail, but Ah, well, we haven't tried to load migrating data through there.... 2010-07-13T14:32:10 that's not migrating, that's just plain old day-by-day data 2010-07-13T14:32:21 Yeah, I'm with ya... 2010-07-13T14:35:11 dbs: E'<(?:marc:)?datafield\s*[^<>]*?\s*tag="901".+?' ? 2010-07-13T14:37:11 miker_: I'll be shocked if namespaced stuff ever makes its way in, as MARC::File::XML seems too dumb to handle it :) 2010-07-13T14:37:36 (that might be unfair, I think it chokes on marc:record in particular) 2010-07-13T14:37:44 indeed 2010-07-13T14:38:11 miker_: if'n you want me to cover that possibility, though, I'll incorporate it 2010-07-13T14:38:56 nah 2010-07-13T14:39:22 dbs: actually, there's a very good chance that MARC::File::XML will be getting smarter about namespaces, because of the turbomarc serialization 2010-07-13T14:39:25 alternately... E'<(/)?marc:', E'<\\1', 'g' 2010-07-13T14:39:52 gmcharlt: awww, I like its sweet and dumb nature (and I have no knowledge of turbomarc) 2010-07-13T14:40:31 *** r123 has quit IRC 2010-07-13T14:40:48 dbs: worry, not, there will always be a MARC::File::XML::SweetAndDumbApiJustForDbs compatiblity layer ;) 2010-07-13T14:41:14 && E' xmlns:marc="http://www.loc.gov/MARC21/slim"', '', 'g' -- nobody would put that inside an actual subfield value, would they? :) 2010-07-13T14:43:41 gmcharlt: is there public news of this turbomarc development somewhere 2010-07-13T14:43:51 dbs = nosey dbs 2010-07-13T14:44:09 dbs: http://www.indexdata.com/blog/2010/05/turbomarc-faster-xml-marc-records 2010-07-13T14:44:23 from pov of M::F::XML, which be just an alternative serialization 2010-07-13T14:45:33 * dbs vomits a little bit 2010-07-13T14:50:53 *** jenny has quit IRC 2010-07-13T14:51:20 *** collum has joined #evergreen 2010-07-13T14:53:42 dbs: oh? 2010-07-13T14:58:53 gmcharlt: why even use XML at that point? 2010-07-13T15:00:35 so that ID can continue to use XSLT in process search results in pazpar2, presumably 2010-07-13T15:03:09 *** jeffgreenca_ has joined #evergreen 2010-07-13T15:03:46 *** jeffgreenca has quit IRC 2010-07-13T15:03:51 *** jeffgreenca_ is now known as jeffgreenca 2010-07-13T15:18:10 agJohn: btw, it's traditional in Unix-land to be able to assume that your program can fire off an email and the server will relay it for you; you can configure sendmail / postfix / ssmtp or whatever MTA you're running to transfer mail to a different SMTP server, if needed 2010-07-13T15:18:27 ergo: not Evergreen's problem :) 2010-07-13T15:22:05 dbs: Understood. I was guessing that running sendmail was assumed--I just was hoping to talk to someone who'd actually set it up. General info is easy to come by: "Here's how we actually did it:"--much less common. And then being able to ask questions so you can deal with the differences between your setup and another's, still less common. While it's perfectly reasonable to say "Not EV's... 2010-07-13T15:22:07 ...problem." I trust you recognize that's not a solution--although in this case it does answer the question of what entries to put in opensrf.xml 2010-07-13T15:23:37 Those of us who aren't dyed-in-the-wool Unix-landers need more info than you folks who are natives ;-) 2010-07-13T15:24:09 No, I think drawing the boundaries of our responsibilities in this project is highly necessary. It's a solution to the problem of too much to do and not enough people doing. 2010-07-13T15:24:15 * phasefx is a DOS refugee 2010-07-13T15:25:11 As I said, it's perfectly reasonable to draw boundaries. But, for someone who's trying to get everything set up and working, the most obvious place to ask is those who've done it. N'est-ce pas? 2010-07-13T15:25:33 (Even if the question is outside the boundaries of the project itself.) 2010-07-13T15:25:59 And didn't I give you an answer? 2010-07-13T15:26:34 As noted, yes. But a general one--helpful, but I'd be pleased to talk to someone in more depth. 2010-07-13T15:28:31 *** shadowspar has joined #evergreen 2010-07-13T15:28:33 agJohn, Debian system? 2010-07-13T15:28:44 Ubuntu, actually. 2010-07-13T15:28:50 8.04 2010-07-13T15:29:09 close enough. dpkg-reconfigure exim4-config on a default system should do the trick for you 2010-07-13T15:29:48 Thanks, I'll check it out. 2010-07-13T15:30:22 after that, apt-get mailx (if you don't have it already) and fire off a test message from the command line. 2010-07-13T15:30:49 Wouldn't sendmail do the same? 2010-07-13T15:31:27 What "trick" exactly does dpkg-reconfigure exim4-config do? 2010-07-13T15:31:36 see also http://packages.ubuntu.com/search?keywords=ssmtp 2010-07-13T15:31:36 you probably don't have sendmail installed, I believe Ubuntu is exim by default 2010-07-13T15:32:05 the sendmail binary will be a symbolic link to exim 2010-07-13T15:33:08 heh, I had no idea http://www.evergreen-ils.org/dokuwiki/doku.php?id=community_servers#community_demo_servers existed 2010-07-13T15:33:14 the "trick" is to configure your MTA to your likings and environment. You can configure it a number of different ways 2010-07-13T15:33:27 OK. I'll give the config a shot. Thanks. 2010-07-13T15:33:32 agJohn: the dpkg-reconfigure command atheos gave you uses the debian config tools to walk you through reconfiguring the "exim4-config" package, which is a package that handles the configuration of the exim4 MTA on your system. 2010-07-13T15:33:52 see also docs in /usr/share/doc/exim4-config/ 2010-07-13T15:34:10 Many thanks for the good info, folks! 2010-07-13T15:35:48 * dbs sets NOEMS in CONFIG.SYS 2010-07-13T15:39:22 dbs pasted "phasefx or other ESI person: JS error when logging into demo.evergreencatalog.com" at http://paste.lisp.org/display/112440 2010-07-13T15:42:52 dbs: gracias 2010-07-13T15:43:18 phasefx: thanks in advance for our -feedback person :) 2010-07-13T15:43:50 * phasefx can't wait to hand that off to some Evergreen foundation, though :) 2010-07-13T15:44:44 i feel like i just drove through a phantom traffic jam. 2010-07-13T15:55:16 *** granitize has quit IRC 2010-07-13T16:00:38 *** Meliss has quit IRC 2010-07-13T16:01:37 Dibs on #0336 for an upgrade script 2010-07-13T16:03:25 * dbs wonders if we'll hit 1000 by September 2010-07-13T16:06:09 i've no idea why we were seeing symptoms in 1.2 and 1.4 days that led us to believe that on order copies were not listed in ahcm and that we needed to re-target holds in order for those copies to be op-captured. 2010-07-13T16:06:28 reading the targeting code in 1.2 and 1.6, i don't see it. in live 1.6, on-order copies are in ahcm. 2010-07-13T16:06:48 moving on to test at op-capture to make sure it isn't a problem with some other portion of the code. 2010-07-13T16:07:20 or config 2010-07-13T16:08:15 jeff: maybe thinking about new items being added in between targeting? 2010-07-13T16:09:55 that's one possibility that i had thought of. 2010-07-13T16:20:03 *** jenny has joined #evergreen 2010-07-13T16:23:32 *** sfortin has quit IRC 2010-07-13T16:27:15 *** natschil has joined #evergreen 2010-07-13T16:31:00 okay, i think the "processing staff change status from on order to something else" was due to the "bad status" error on checkin of an On Order item. 2010-07-13T16:36:32 *** natschil has quit IRC 2010-07-13T16:44:29 Hrm. Vandelay (MARC::File::XML / MARC::Charset in particular inside as_xml_record()) seem to be choking on NFD XML records, but happily accepting NFC XML records. 2010-07-13T16:55:47 *** kmlussier has quit IRC 2010-07-13T17:15:05 Hmm. as_formatted() doesn't trigger the problem, but as_xml_record() does. 2010-07-13T17:20:11 because as_xml_record() is deciding to transcode the record, apparently. 2010-07-13T17:22:18 ha ha ha 2010-07-13T17:23:09 my $original_encoding = substr($ldr,9,1); # really shouldn't return '2' 2010-07-13T17:23:38 *** Dyrcona has quit IRC 2010-07-13T17:23:41 ' ' and 'a' as values for Leader/09 is just too constrictive 2010-07-13T17:23:47 gotta allow more leeway ;) 2010-07-13T17:26:01 leader was defective, obviously 2010-07-13T17:26:44 that was a fine number of hours spent debugging that issue; I keep forgetting that M:F:X tries to be helpful and do the encoding conversion for you 2010-07-13T17:27:05 but ... it probably shouldn't do anything if it gets a value that's neither ' ' or 'a', eh? 2010-07-13T17:27:24 indeed not 2010-07-13T17:28:08 in fact, I'd be tempted to push a change to have it *never* transcode without an explicit request to do so 2010-07-13T17:28:12 ah, and now it makes sense why these errors only showed up with NFD chars 2010-07-13T17:28:16 but that would probably break way too much downstream 2010-07-13T17:28:55 yeah. for the time it was written, when UTF8 records were few and far between, it was a reasonable decision 2010-07-13T17:31:20 maybe flip the "if ($original_encoding ne 'a' ... " test to "if ($original_encoding eq ' ' ... " ? 2010-07-13T17:32:09 yeah 2010-07-13T17:32:37 That, and/or refuse to do anything if the leader is invalid (but there goes half the MARC records in existence). 2010-07-13T17:32:57 and also tack on a blank_does_not_mean_marc8_in_korea_or_well_most_of_rest_of_world, switch 2010-07-13T17:33:10 heh 2010-07-13T17:33:55 *** collum has left #evergreen 2010-07-13T17:34:06 actually, there's quite of a bit of character handling code in Koha that I really ought to fold into MARC::Charset RSN 2010-07-13T17:35:09 *** jenny has left #evergreen 2010-07-13T17:38:03 perl -i -pe 's/(\d{5}.. )/$1 /' *.xml # fixed that batch of records 2010-07-13T17:51:32 *** natschil has joined #evergreen 2010-07-13T18:04:58 I'll put a preemptive fix + warning into Vandelay for now 2010-07-13T18:12:59 *** dbs has quit IRC 2010-07-13T18:13:14 *** natschil has quit IRC 2010-07-13T18:18:29 *** youdonotexist has quit IRC 2010-07-13T18:39:15 *** yboston has quit IRC 2010-07-13T19:01:06 *** jeffgreenca has quit IRC 2010-07-13T19:43:20 mmmm... perl pie 2010-07-13T20:30:56 pie? 2010-07-13T20:31:53 miker_: thanks for the comments earlier on on order and ahcm. apparently no longer (or never was) an issue for us. 2010-07-13T20:43:26 just have to undo some cargo culting and cross my fingers. 2010-07-13T21:12:08 *** jeffgreenca has joined #evergreen 2010-07-13T21:37:02 *** alxp has quit IRC 2010-07-13T22:44:52 *** jeffgreenca has quit IRC 2010-07-13T23:49:41 *** StephenGWills has quit IRC