Time |
Nick |
Message |
00:22 |
|
phasefx_ joined #evergreen |
02:36 |
|
wsmoak joined #evergreen |
05:00 |
pinesol_green |
News from qatests: Test Success <http://testing.evergreen-ils.org/~live> |
07:12 |
|
rjackson_isl joined #evergreen |
07:51 |
rhamby |
morning |
08:06 |
jeff |
good morning! |
08:16 |
|
kmlussier joined #evergreen |
08:21 |
|
Dyrcona joined #evergreen |
08:27 |
_bott_ |
Friday the 13th and a full moon. Let the games begin! |
08:28 |
_bott_ |
...although I believe technically, it was full last evening |
08:31 |
Dyrcona |
Yeah. |
08:32 |
kmlussier |
Yeah, so almost full moon. |
08:32 |
Dyrcona |
Waning Gibbous. |
08:32 |
Dyrcona |
So, this isn't typical. |
08:32 |
Dyrcona |
When I have trouble with applications losing fonts/text after wake from suspend, it is usually GTK+ applications. |
08:33 |
Dyrcona |
This time Chromium has chosen to make the main content pane of its window completely devoid of content. |
08:34 |
Dyrcona |
I filed a Lp bug on the GTK+ apps, 'cause I'm kind of blaming Gnome/Mir for that one, 'cause killing the gnome-session fixes it. |
08:35 |
Dyrcona |
Looks like exiting Chromium and restarting fixes that, for now. |
08:36 |
Dyrcona |
So, yeah, I'm not triskaidekaphobic or anything, but.... |
08:37 |
Dyrcona |
Happens again, and I'll open another Lp bug.... IDK, maybe I just use my laptop wrong? ;) |
08:40 |
|
mmorgan joined #evergreen |
08:42 |
jeff |
@weather --astronomy ktvc |
08:42 |
pinesol_green |
jeff: Astronomy: :: Moon illum: 98% Moon age: 16d Sunrise: 8:17 Sunset: 17:25 Length of Day: 9h8m |
08:43 |
Dyrcona |
jeff: Cool didn't know the weather plugin had that feature. |
08:43 |
jeff |
(since y'all were talking about the moon) |
08:44 |
Dyrcona |
@weather --astronomy 01844 |
08:44 |
pinesol_green |
Dyrcona: Astronomy: :: Moon illum: 98% Moon age: 16d Sunrise: 7:13 Sunset: 16:34 Length of Day: 9h21m |
08:44 |
csharp |
@weather --astronomy 30033 |
08:44 |
pinesol_green |
csharp: Astronomy: :: Moon illum: 98% Moon age: 16d Sunrise: 7:42 Sunset: 17:49 Length of Day: 10h7m |
08:45 |
csharp |
shows our differences in longitude |
08:45 |
csharp |
and latitude with the length of the day |
08:52 |
Dyrcona |
jeff: Are you still in the eastern timezone? |
08:52 |
|
bos20k joined #evergreen |
08:52 |
Dyrcona |
I guess "still" was unnecessary... |
08:54 |
jeff |
Dyrcona: yes. most of Michigan is US/Eastern, currently -0500 offset. |
08:55 |
Dyrcona |
jeff: OK. Explains my my sunset is 50 minutes earlier than yours, even though I think you're at a higher or similar latitude. ;) |
08:55 |
Dyrcona |
grr..... typos? |
08:56 |
Dyrcona |
one of those mys should be a why. |
08:58 |
jeff |
There are four counties in the Upper Peninsula that observe US/Central time: Gogebic, Iron, Dickinson, and Menominee. |
09:08 |
|
collum joined #evergreen |
09:14 |
|
yboston joined #evergreen |
09:17 |
|
jvwoolf joined #evergreen |
09:32 |
|
krvmga joined #evergreen |
09:33 |
|
NawJo joined #evergreen |
09:40 |
|
maryj joined #evergreen |
10:00 |
|
_bott_ joined #evergreen |
10:07 |
* berick |
lights the official Fri. 13 IRC séance incense |
10:07 |
|
rlefaive joined #evergreen |
10:49 |
|
bmills joined #evergreen |
11:25 |
|
brahmina joined #evergreen |
11:35 |
tsbere |
Apparently berick and I had some similar thoughts on the "split the IDL" bit regarding "other places need to know too" |
11:39 |
berick |
tsbere++ |
11:40 |
tsbere |
berick++ |
11:40 |
tsbere |
Better to point these things out ahead of time than to run into them later ;) |
11:40 |
berick |
indeed |
11:40 |
berick |
gmcharlt++ |
11:43 |
gmcharlt |
berick: I've sometimes wondered if somebody has ever taken the fact that it currently resides in examples/ as a license to think, eh, it's just an example, I can delete fm_IDL.xml ;) |
11:44 |
berick |
gmcharlt: exactly. it sends an odd message :) |
11:58 |
|
rlefaive_ joined #evergreen |
12:05 |
Dyrcona |
Well, so do opensrf.xml and opensrf_core.xml. Maybe the IDL should have .example tacked onto the end of its name? |
12:16 |
|
jihpringle joined #evergreen |
12:30 |
miker |
I think it's home just predates the opensrf/eg schism, when all config files lived in examples/ and were (event the idl back then) expected to be instance-specialized (reporting and such) |
12:30 |
miker |
that never really happened for the idl |
12:30 |
miker |
not the way we originally imagined |
12:30 |
miker |
the others really are examples in opensrf, though ... and the location for those just stuck |
12:31 |
miker |
but the world moves on, and git properly tracks moves, so I certainly won't fight a move out of examples/ :) |
12:32 |
Dyrcona |
miker: Yes, but I know at least one place, possibly two, that does customize the IDL. |
12:32 |
miker |
oh, I know lots |
12:32 |
miker |
but not super heavily |
12:32 |
miker |
just "add this custom IDL view for reporting" type stuff |
12:32 |
* Dyrcona |
has a branch just for IDL customizations. |
12:32 |
miker |
not "let's make actor.usr have a different shape altogether" |
12:33 |
Dyrcona |
That's mostly what ours is, though, I think we backported a few missing fields from later patches and what not. |
12:36 |
miker |
Dyrcona: right .. and that use case (reporting additions) is simplied by shredding the IDL I think |
12:37 |
miker |
I guess my monologue may have lacked context ... I was just commenting on the location of the files and how they came to live there |
12:38 |
miker |
I'm +1M on shredding the idl. that would simplify a lot of lives, IMO |
12:49 |
miker |
simplied? simplified |
12:51 |
csharp |
gmcharlt++ |
12:53 |
Dyrcona |
I'm not fussed about the IDL either way. :) |
12:56 |
|
Christineb joined #evergreen |
13:06 |
Dyrcona |
Anyone else noticed Makfile, Makefile.am, and Makefile.in, in your /openils/var/web? |
13:07 |
csharp |
Dyrcona: I see it |
13:08 |
Dyrcona |
Those should probably not be installed. :) |
13:08 |
Dyrcona |
I'll Lp it later if I remember. |
13:08 |
csharp |
re: the IDL, I noticed that several non-PINES classes were added under the "comment this out if you don't want PINES stuff" line and rearranging the file was going to be painstaking and painful - glad to see the alternate approach |
13:09 |
csharp |
Dyrcona: they're in 2.9 too |
13:09 |
Dyrcona |
csharp: I might be responsible for one of those. I have this vague recollection of adding a class definition to the bottom of the IDL without thinking about it. |
13:10 |
Dyrcona |
csharp: Yeah, I'm seeing them in 2.10, fwiw. |
13:10 |
csharp |
it was inevitable that someone adding classes would miss that line |
13:11 |
Dyrcona |
Yeah, and my brain could be making that up. I don't trust my memory much any more. :) |
13:30 |
|
mmorgan joined #evergreen |
13:46 |
Dyrcona |
Whee! Nothing like working on a 64-bit image on a 32-bit O/S. Can't chroot, that's for sure. |
13:47 |
Dyrcona |
Makes things a tad more interesting. |
15:08 |
|
dteston joined #evergreen |
15:09 |
dteston |
building a Mac client for 2.11, but it's saying "This server does not support your version of the staff client." I get codes 200 and 404 |
15:15 |
dbwells |
dteston: You may need to add a link in /openils/var/web/xul/ to match your client build ID |
15:17 |
dbwells |
In the client, if you do Help->About this client, what do you see for "Target Server ID"? |
15:19 |
dteston |
dbwells: csharp is going to help me with the first part. Target Server ID is pines_rel_2_11_1 |
15:21 |
dbwells |
ok, that is normally the link name you would need in the directory I gave, but I am sure csharp can get it sorted. |
15:22 |
dteston |
dbwells: that did it. Thank you! |
15:23 |
dbwells |
you are welcome |
15:26 |
jeff |
Someone made reference to the old marc2bre.pl / quick_metarecord_map.pl import process from the 2.1 docs the other day, and it gave me an excuse to look at what the current docs say in terms of bib import / migration. |
15:28 |
jeff |
There are some potential issues with the process outlined in the current docs: http://docs.evergreen-ils.org/2.11/_migrating_your_bibliographic_records.html |
15:30 |
jeff |
Does anyone here use that process currently, or has it also grown stale? |
15:31 |
jeff |
looks like what's currently there came from Evergreen In Action |
15:33 |
kmlussier |
jeff: Yes, that's right. It is from Evergreen in Action. 2.3 days? |
15:34 |
Dyrcona |
Frankly, I never used those processes, but I'm quirky. |
15:37 |
dbs |
I think I wrote most of that process, but haven't done a big migration for years now |
15:39 |
dbs |
Still do minor variations on that for bulk loads of e-resource MARC records though |
15:39 |
* dbs |
was worried that marc2*re.pl was still in those docs |
15:39 |
jeff |
heh |
15:40 |
* phasefx |
still uses mar2bre.pl and parallel_pg_loader.pl, and GNU parallel |
15:40 |
phasefx |
marc2bre.pl, even |
15:41 |
dbs |
Only for the Evergreen 2.1 systems that you're hosting though, right? |
15:41 |
dbs |
:; |
15:41 |
phasefx |
no, I've done that recently on modern systems |
15:42 |
jeff |
there are potential gotchas with COPY and lines that happen to contain strings like "01\07 Foo", because \07 will be interpreted as octal 007 and now you have a bell in your MARC data. |
15:42 |
phasefx |
I tweak some ingest related internal flags and load stuff in chunks; it's not particularly fast |
15:43 |
jeff |
i thought that pymarc was silently dropping subfields when there was a problematic character in the data, but that turns out to be yaz-marcdump. |
15:44 |
jeff |
checking more recent versions of yaz-marcdump and changelog to see if that's a known/fixed issue, expected behavior, etc. |
15:44 |
Dyrcona |
COPY is too slow. You need to use JDBC, run about 12 threads, and do batch updates of 10,000 rows a piece. :P |
15:44 |
* phasefx |
uses yaz-marcdump to convert to UTF-8 and marc_cleanup from migration-tools; some records do get thrown out in that process. Not sure about the 0107 Foo example |
15:45 |
phasefx |
we should collect some problem records like that and build tests |
15:45 |
jeff |
but in the case of an 020 tag with one subfield that yaz-marcdump doesn't like, you end up with an empty 020 with zero subfields, which throws a fatal error in MARCC::File::XML when it comes time to maintain_901 :-) |
15:46 |
phasefx |
yeah, marc_cleanup throws out empty tags |
15:46 |
phasefx |
brb |
15:48 |
jeff |
phasefx: yaz-marcdump converting to utf8 was how i ended up with an empty 020, yeah. |
15:48 |
Dyrcona |
I usually write my own stuff in Perl and discard any records that MARC::File::XML doesn't like. |
15:48 |
jeff |
yaz-marcdump -v -f MARC-8 -t UTF-8 -o marc -l 9=97 input.mrc > output.utf8.mrc |
15:49 |
Dyrcona |
Oddly enough, it looks like I'll get through this again for real this summer. |
15:49 |
Dyrcona |
We'll have a new branch added with records from Voyager or something like that. |
15:50 |
Dyrcona |
I say oddly 'cause I only just found out about the time this conversation started. |
15:51 |
Dyrcona |
I notice that MARCEdit (is that the program?) can also tolerate some junk in the MARC that MARC::Record and friends don't like. |
15:52 |
jeff |
i am shocked -- SHOCKED -- to find that there is variance in what different MARC-using software tolerates and emits. |
15:52 |
phasefx |
jeff: fun. My chain looks like this: chardet, yaz-marcdump, marc_cleanup, marc2bre, parallel_pg_loader, split, wrap chunks in BEGIN; -- flag munging COMMIT; sql, parallel, quick_metarecord_map |
15:52 |
Dyrcona |
hah! |
15:52 |
phasefx |
:D |
15:52 |
Dyrcona |
It wasn't bad, though, just 3 records out of 140,000 or so. |
15:52 |
jeff |
chardet++ |
15:53 |
phasefx |
it doesn't know MARC8, but if you get anything other than UTF-8 back, you know something need be done |
15:53 |
Dyrcona |
And what does chardet do with records that have a mix of encodings in them? ;) |
15:53 |
phasefx |
maybe mislead you :) |
15:53 |
Dyrcona |
:) |
15:53 |
phasefx |
GIGO |
15:54 |
Dyrcona |
Exactly. |
15:55 |
Dyrcona |
I haven't done flag munging during loads much lately, but I've been dealing with small batches of 100,000 or so records. |
15:55 |
Dyrcona |
I let the insert/update do its thing. |
15:56 |
Dyrcona |
We've been loading into a live system with others cataloging, and this can run for hours on another machine and when it's done, it's done. |
15:56 |
phasefx |
either marc_cleanup is saving me, or I've lucked up on catastrophic-failure-causing records |
15:57 |
Dyrcona |
I deal with catastrophic records by using my own parser for binary records. |
15:57 |
Dyrcona |
Just IO::File with $/ = '\x1f\x1e'; |
15:58 |
Dyrcona |
Put an eval around the MARC::Record->new_from_usmarc() and put any that blow up into a reject file. |
15:58 |
* jeff |
nods |
15:58 |
Dyrcona |
I think I got that delimiter correct. That was from memory. :) |
15:59 |
phasefx |
I think that's what marc_cleanup does |
15:59 |
Dyrcona |
I was looking at the source of MARC4J again recently, for similar reasons. |
16:00 |
Dyrcona |
There's some neat stuff in there, too, that I didn't notice the last time I used it. |
16:03 |
* phasefx |
imagines a world where we were still using spidermonkey and trying to use it to parse marc with a javascript library |
16:05 |
phasefx |
I feel like we were.. maybe for record quality? |
16:05 |
jeff |
and/or biblio fingerprint? |
16:05 |
phasefx |
yeah |
16:07 |
phasefx |
may have to try installing EG 1.0 one day for kicks |
16:09 |
berick |
phasefx: bonus points for installing on Etch |
16:09 |
phasefx |
might have to |
16:09 |
berick |
true |
16:10 |
berick |
ok, bonus points for installing on 16.04 |
16:10 |
* phasefx |
shamefully deleted some old EG vm's recently :) |
16:10 |
* jeff |
tries to recall if a newline in a marc field is forbidden somewhere |
16:10 |
csharp |
phasefx: I tried installing 1.0 several years ago - it was not a success :-) |
16:10 |
phasefx |
:D |
16:20 |
|
dbwells joined #evergreen |
16:21 |
|
mllewellyn joined #evergreen |
16:23 |
|
mllewellyn joined #evergreen |
16:26 |
|
mllewellyn left #evergreen |
16:26 |
|
mllewellyn joined #evergreen |
17:01 |
pinesol_green |
News from qatests: Test Success <http://testing.evergreen-ils.org/~live> |
17:02 |
|
jvwoolf left #evergreen |
17:03 |
|
mmorgan left #evergreen |
17:22 |
|
dbwells joined #evergreen |
17:40 |
|
dbwells joined #evergreen |