| Time |
Nick |
Message |
| 05:02 |
pinesol_green |
Incoming from qatests: Test Success - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 05:07 |
|
kmlussier joined #evergreen |
| 05:10 |
|
kmlussier left #evergreen |
| 05:11 |
|
kmlussier joined #evergreen |
| 05:44 |
rangi |
stupid jetlag |
| 05:44 |
kmlussier |
rangi: I don't have jet lag as an excuse, but I was still up at 4 a.m. :P |
| 05:48 |
* kmlussier |
never sleeps well in hotels. |
| 05:51 |
|
tfaile joined #evergreen |
| 05:54 |
rangi |
kmlussier: hmm the programme says breakfast at 7, does that mean we get our own or breakfast will be there? |
| 05:55 |
kmlussier |
rangi: I was wondering the same thing, but I "think" it means breakfast will be there. |
| 05:56 |
rangi |
cool, i figure if its not, its a short walk back here to get some anyway :) |
| 05:59 |
kmlussier |
@weather 30308 |
| 05:59 |
pinesol_green |
kmlussier: The current temperature in Georgia Tech (Midtown), Atlanta, Georgia is 52.0°F (5:59 AM EDT on April 24, 2014). Conditions: Clear. Humidity: 65%. Dew Point: 41.0°F. Pressure: 29.99 in 1015 hPa (Rising). |
| 06:38 |
|
kmlussier left #evergreen |
| 07:46 |
|
rjackson-isl joined #evergreen |
| 08:04 |
|
collum joined #evergreen |
| 08:04 |
|
ericar joined #evergreen |
| 08:18 |
|
akilsdonk joined #evergreen |
| 08:22 |
|
kmlussier joined #evergreen |
| 08:31 |
|
tspindler joined #evergreen |
| 08:37 |
|
mmorgan joined #evergreen |
| 08:38 |
|
Dyrcona joined #evergreen |
| 08:45 |
|
mrpeters joined #evergreen |
| 08:54 |
|
kbeswick joined #evergreen |
| 08:57 |
|
montgoc1 joined #evergreen |
| 09:05 |
|
18VAALVS7 joined #evergreen |
| 09:15 |
|
timf joined #evergreen |
| 09:23 |
|
kmlussier1 joined #evergreen |
| 09:23 |
|
dluch joined #evergreen |
| 09:39 |
|
yboston joined #evergreen |
| 09:52 |
|
denishpatel joined #evergreen |
| 09:52 |
|
mllewellyn joined #evergreen |
| 09:57 |
|
ldwhalen joined #evergreen |
| 10:03 |
|
BigRig joined #evergreen |
| 10:21 |
|
dluch joined #evergreen |
| 10:25 |
|
mmorgan joined #evergreen |
| 10:35 |
|
denishpatel joined #evergreen |
| 10:38 |
|
erick316 joined #evergreen |
| 10:40 |
|
mdriscoll joined #evergreen |
| 10:48 |
jboyer-isl |
A quick autogen question. If you have a server that doesn't serve the opac or staff client (a utility or reporter server, say) is there any use/need to autogen them? I'm curious because we're out of sync and I'm not going to worry about it if they won't be affected. |
| 10:49 |
|
frank____ joined #evergreen |
| 10:50 |
tsbere |
jboyer-isl: Most of that is for external use and doesn't have an effect on server-side to begin with so you are probably good |
| 10:51 |
jboyer-isl |
That's what I figured. thanks, tsbere++ |
| 10:58 |
|
jwoodard joined #evergreen |
| 11:07 |
|
vlewis joined #evergreen |
| 11:18 |
|
ldwhalen joined #evergreen |
| 11:18 |
|
kmlussier1 joined #evergreen |
| 11:21 |
bshum |
dbwells: I was just taking a brief look at the end of the 2.6 upgrade SQL and the suggestion to do the full reingest but use the example as a starting point and look at parallel running of the reingest. |
| 11:22 |
bshum |
I was wondering if you or others has some work already on how to do the parallel running. |
| 11:22 |
tsbere |
I think we have something kicking around...maybe. Dyrcona wrote it if we do. |
| 11:23 |
Dyrcona |
Which ingest? |
| 11:23 |
Dyrcona |
I only do the standard ingests in parallel with pingest.pl. |
| 11:24 |
bshum |
Hmm I think it's the usual on same marc force reingest deal |
| 11:26 |
Dyrcona |
bshum: But, I also run a query reingest metabib.record_attributes, mainly for deleted records, but it does them all to be safe. |
| 11:28 |
Dyrcona |
bshum: Something like http://git.mvlcstaff.org/?p=jason/evergreen_utilities.git;a=blob;f=scripts/pingest.pl;h=2b43e9a45b20e10325217f86579002b5c0e14315;hb=cc9a96dc734997946c8027d41c9252a545dc05a8 ? |
| 11:28 |
Dyrcona |
I don't think you have to set the reingest on same marc if you use the above. |
| 11:37 |
bshum |
Dyrcona: Cool! I'll ponder that one and see what it does. Thanks for sharing. |
| 11:42 |
dbwells |
bshum: We've mostly kept it pretty simple and just generated batches of UPDATE commands (similar to the 2.6 example), then split them up and run them on multiple psql (or perl DBI) processes. |
| 11:43 |
dbwells |
bshum: In our experience, as long as you don't use tranactions or try to do UPDATEs on ranges of IDs, we don't have any locking problems. |
| 11:44 |
|
Christineb joined #evergreen |
| 11:53 |
gsams |
bshum: update on my call number search deal, we are currently planning on inserting the call numbers into their records so that bib call search should work. I think that will be a better solution for the time being. |
| 12:04 |
|
tonyb_ohionet joined #evergreen |
| 12:04 |
tonyb_ohionet |
Hi all! |
| 12:04 |
* bshum |
waves at tonyb_ohionet |
| 12:04 |
bshum |
gsams: That's certainly a way to move forward :) |
| 12:05 |
Bmagic |
when upgrading opensrf, has anyone ran into the "Failed legacy authentication for opensrf private.localhost/client_at_localhost_xxxxxx" ejabberd doesnt allow authentication when running |
| 12:05 |
Bmagic |
sorry for the <enter> button: osrf_control --localhost --start-all |
| 12:05 |
gsams |
bshum: it'll do the trick until we can decide otherwise at least! I still want that feature, so I'll try and convince our folks to look at it. |
| 12:06 |
tsbere |
Bmagic: Bad passwords in the config file can do that, otherwise I don't usually see that issue |
| 12:07 |
Bmagic |
tsbere: I will double check that, thanks! |
| 12:11 |
Bmagic |
tsbere: you were right, I re-registered the users and it worked |
| 12:13 |
Dyrcona |
@bartender |
| 12:13 |
* pinesol_green |
fills a pint glass with Magic Hat Blind Faith, and sends it sliding down the bar to Dyrcona (http://beeradvocate.com/beer/profile/96/298/) |
| 12:23 |
* Dyrcona |
is feeling lazy so I'll ask here. |
| 12:23 |
|
tonyb_ohionet joined #evergreen |
| 12:23 |
Dyrcona |
Is there a way to have MARC::Record accept a malformed record similar to MARC::Batch's strict_off option? |
| 12:24 |
Dyrcona |
I know I can use an eval block to catch the error, but I actually want to delete the offending tag. |
| 12:44 |
eeevil |
Dyrcona: I suspect it depends on the malformedness... do you know the issue? |
| 12:44 |
eeevil |
or is it just "record fails. goodbye" |
| 12:45 |
Dyrcona |
Yes, a field 520 has no subfields then execution halts. |
| 12:45 |
|
ldwhalen joined #evergreen |
| 12:45 |
eeevil |
ah ... I wonder if yaz can read it? (you've probably attempted that...) |
| 12:46 |
eeevil |
also, marcxml? |
| 12:46 |
Dyrcona |
I am pulling the marc right out of our database. |
| 12:47 |
Dyrcona |
Weird thing, with the eval block, $@ is not getting set. |
| 12:48 |
Dyrcona |
I am using Perl 5.18 if that matters. |
| 12:48 |
Dyrcona |
Yes, it is marcxml. |
| 12:50 |
eeevil |
I don't know if the version matters or not... it might be better to do that at the db level, though. regexp_replace(marc,'<datafield[^>]+/>','') or similar |
| 12:50 |
eeevil |
and call it bad data |
| 12:52 |
bshum |
gmcharlt: I added the new bug 1312297 to the 2.7 roadmap in the new area I desginated for deprecation/removal of old code |
| 12:52 |
pinesol_green |
Launchpad bug 1312297 in Evergreen "time to remove the old web-based selfcheck interface" (affected: 1, heat: 6) [Wishlist,New] https://launchpad.net/bugs/1312297 |
| 12:52 |
bshum |
gmcharlt: Fwiw, I'm in favor of full removal. |
| 12:54 |
Dyrcona |
eeevil: I'm not trying to fix that field specifically. I noticed it as a side effect of something else. |
| 12:54 |
Dyrcona |
I take back what I said about $@. It is being set. My sleep() inside that if block is not working, though. |
| 12:54 |
eeevil |
bshum: I'm about to run to lunch, but here's an deprecation idea for you: remove the 437 layers (only slight hyperbole) of indirection between the open-ils.search API and the backend that uses QueryParser to actually do the work. |
| 12:56 |
jeff |
With regard to the legacy web based selfcheck, I think it's been implicitly deprecated and should be excised. :-) |
| 12:56 |
bshum |
eeevil: Sounds intriguing, and helpful. I'll poke you more on that idea down the road :) |
| 12:58 |
gmcharlt |
bshum: as you can see, I've established a "deprecation" tag as well |
| 12:58 |
bshum |
gmcharlt++ |
| 12:59 |
jeff |
deprecation++ excision++ |
| 12:59 |
Dyrcona |
Interestingly, $MARC::Record::ERROR does not appear to get set as the documentation says it will: Use of uninitialized value $MARC::Record::ERROR in print at Src/egmisc/laserdisc_fix.pl line 39 |
| 13:00 |
jeff |
Dyrcona: i believe that's a difference between parsing with MARC::File::USMARC and MARC::File::XML |
| 13:01 |
eeevil |
Dyrcona: gotcha ... your problem sounds familiar, but I can't find its like on LP |
| 13:01 |
Dyrcona |
eeevil: It might be on CPAN's RT... |
| 13:01 |
eeevil |
bshum: please do |
| 13:02 |
Dyrcona |
Well, I'm just going to spit this record's id out with a message that it errored. It is only one out of 6,218. |
| 13:02 |
Dyrcona |
I'm also spitting out a list of records that I can't fix, so I'll put it in that list. |
| 13:03 |
jeff |
Dyrcona: there's a comment in MARC::File::SAX (used by MARC::File::XML) to the effect of being more consistent with MARC::File::USMARC's behavior with regard to parse errors. |
| 13:04 |
jeff |
That's my usual mode -- identify the malformed records and exclude, or fix by hand. |
| 13:05 |
jeff |
Ideally they wouldn't get into biblio.record_entry.marc if they're malformed. I don't know if that's just imported or older record data. I haven't tested to see if you can sneak bad data in in current Evergreen. |
| 13:10 |
|
hbrennan joined #evergreen |
| 13:16 |
Dyrcona |
bshum++ |
| 13:25 |
Dyrcona |
On my MARC::Record error: I can print $@ to get the error message. |
| 13:25 |
Dyrcona |
Just for those following along at home. :) |
| 13:28 |
Bmagic |
Dyrcona: This has been something that I have been dealing with as well, I would be interested in seeing what you come up with |
| 13:30 |
pastebot |
"Dyrcona" at 64.57.241.14 pasted "What I'm doing about my bad record(s) for now." (53 lines) at http://paste.evergreen-ils.org/10 |
| 13:30 |
Dyrcona |
Bmagic: Dunno if the above will help you, but that is what I am doing right now. |
| 13:31 |
* Bmagic |
reads code |
| 13:32 |
Dyrcona |
Of course, I misspelled substr! |
| 14:03 |
Bmagic |
I seem to remember reading some chat about the 2.5->2.6 sql upgrade script not being in the 2.6 git branch. I would just like to verify that in fact it is not |
| 14:03 |
Dyrcona |
I think this is odd, but maybe it isn't: I specified the UTF-8 encoding in my new_from_xml call and that error just went away. |
| 14:04 |
Bmagic |
Dyrcona: Nothing is more annoying that encode - I have gone round and round with it and get different results everytime |
| 14:04 |
|
kbeswick joined #evergreen |
| 14:05 |
Bmagic |
Dyrcona: I thought I had it all figured out until I realized that I didnt, lol |
| 14:10 |
Dyrcona |
Bmagic: I've seen some weird stuff with different encoding software. |
| 14:11 |
Dyrcona |
For instance, I've seen a record that when parsed by yaz, ends up with a combining character over the closing > of a MARCXML tag. That leads to a busted parser. |
| 14:11 |
|
jboyer_isl joined #evergreen |
| 14:22 |
|
remingtron joined #evergreen |
| 14:28 |
Bmagic |
Dyrcona: Yes, I have seen similar things, and it's crazy annoying |
| 14:28 |
Bmagic |
Dyrcona: Can we stop using marc already! |
| 14:28 |
|
remingtron joined #evergreen |
| 14:34 |
jeffdavis |
I had been thinking about making buttons that say "I support bshum for 2.7 release manager," but judging from the emails on open-ils-general they would be superfluous. :) |
| 14:37 |
hbrennan |
jeffdavis: But still fun. Everyone loves a button |
| 14:37 |
jeffdavis |
true |
| 14:38 |
|
jboyer-isl joined #evergreen |
| 14:42 |
bshum |
jeffdavis: Hehe, thanks for the support! :D |
| 14:42 |
kmlussier |
jeffdavis++ |
| 14:44 |
Dyrcona |
"Don't blame me. I voted for Kodos." |
| 14:45 |
|
kmlussier1 joined #evergreen |
| 14:45 |
|
lcathenry joined #evergreen |
| 14:49 |
|
ldwhalen joined #evergreen |
| 14:56 |
|
ericar joined #evergreen |
| 14:56 |
|
mtate joined #evergreen |
| 14:57 |
|
phasefx joined #evergreen |
| 14:58 |
|
tfaile joined #evergreen |
| 14:58 |
|
BigRig joined #evergreen |
| 14:58 |
|
Callender joined #evergreen |
| 14:58 |
|
BigRig_ joined #evergreen |
| 15:01 |
|
kmlussier1 joined #evergreen |
| 15:06 |
|
BigRig joined #evergreen |
| 15:11 |
jeff |
interesting. i don't think that it's currently possible to add electronic resource records as a patron. i think the issue is that the record_list() search used doesn't include enough information to satisfy the located uri search, and thus the results exclude those records. |
| 15:12 |
* Dyrcona |
does not know what "add electronic resource records as a patron" means. Add them to what? |
| 15:16 |
* Dyrcona |
assumes a list/book bag. |
| 15:17 |
|
kmlussier joined #evergreen |
| 15:20 |
|
ldwhalen joined #evergreen |
| 15:36 |
|
ldwhalen joined #evergreen |
| 15:48 |
jeff |
Dyrcona: sorry, yes. i missed the "to a list" part of my statement above. |
| 15:48 |
tsbere |
jeff: Sounds more like it is possible to add them, but once you do they don't show up even though they are there |
| 15:48 |
tsbere |
unless I missed something here |
| 15:49 |
tsbere |
(also, aren't lists usually handled by container searches, not record_list searches?) |
| 15:50 |
|
BigRig_ joined #evergreen |
| 15:52 |
|
tfaile_ joined #evergreen |
| 15:52 |
|
BigRig_ joined #evergreen |
| 15:52 |
|
Callender_ joined #evergreen |
| 15:52 |
jeff |
tsbere: adding it to the temp list fails in a fashion. if you request the anon cache key's value you see one electronic resource id, but you can never add it to a real (non-temp) list, and the next record you add to the list overwrites the electronic resource. |
| 15:52 |
tsbere |
huh, fun |
| 15:53 |
jeff |
overwrites is an oversimplification -- the contents of the anon cache are fetched, run through search, and then the new record is appended to the end of those results -- so the search step always eats the electronic resource. |
| 15:53 |
jeff |
unless your resource is an auri at the top of the org tree, i suspect (but haven't tested that) |
| 15:55 |
|
Callender__ joined #evergreen |
| 15:57 |
eeevil |
jeff: or within the current search scope? or acts-like-copies? |
| 16:09 |
jeff |
eeevil: "current search scope" is always "no org unit, defaults to top of tree" in this case, i think. |
| 16:10 |
jeff |
eeevil: but acts-like-copies would likely not suffer from this, yes. |
| 16:10 |
jeff |
eeevil: i'll do more work to repro on master and file a bug. |
| 16:11 |
eeevil |
jeff: ahh, this is all through non-type-y interfaces, right ... perhaps we should just respect the record_list() period, since (for patrons) it's only used to build a list of records they could, at one time, see... |
| 16:11 |
|
mtate joined #evergreen |
| 16:11 |
* jeff |
wonders if there's an option that could be paired with record_list() to say "and skip all checks other than 'does this record exist'" |
| 16:11 |
|
BigRig joined #evergreen |
| 16:12 |
jeff |
eeevil: yeah, pretty much. |
| 16:12 |
|
ericar joined #evergreen |
| 16:12 |
|
tfaile joined #evergreen |
| 16:12 |
|
Callender joined #evergreen |
| 16:12 |
|
phasefx joined #evergreen |
| 16:13 |
eeevil |
well, tossing the #staff modifier on the search should do that (today) ... I think just respecting the list is probably better |
| 16:18 |
|
ldwhalen joined #evergreen |
| 16:25 |
jeff |
ad for an offer of free business cards: "use them as networking cards, [...]" |
| 16:30 |
jeff |
eeevil: OpenILS::WWW::SuperCat::changes_feed seems to be the only other internal-to-evergreen thing that uses record_list() -- and that DOES pass a context org unit for the search, and probably shouldn't ignore things like visibility... |
| 16:31 |
jeff |
er, "probably shouldn't JUST respect the list" |
| 16:31 |
jeff |
though... |
| 16:31 |
* jeff |
looks |
| 16:33 |
|
BigRig_ joined #evergreen |
| 16:34 |
|
Callender_ joined #evergreen |
| 16:34 |
|
phasefx_ joined #evergreen |
| 16:34 |
|
tfaile_ joined #evergreen |
| 16:35 |
|
ericar_ joined #evergreen |
| 16:36 |
|
tater joined #evergreen |
| 16:47 |
|
tspindler left #evergreen |
| 16:56 |
|
kmlussier left #evergreen |
| 17:21 |
|
mmorgan left #evergreen |
| 18:25 |
|
akilsdonk joined #evergreen |
| 19:00 |
|
dbwells_ joined #evergreen |
| 19:03 |
|
mdriscoll1 joined #evergreen |
| 19:04 |
|
Bmagic joined #evergreen |
| 19:04 |
|
hopkinsju joined #evergreen |
| 19:22 |
|
bmills joined #evergreen |
| 19:33 |
|
Dyrcona joined #evergreen |
| 20:50 |
bshum |
@later tell dbwells I'm going to make a minor tweak to 0864 so that it's CREATE EXTENSION IF NOT EXISTS intarray; |
| 20:50 |
pinesol_green |
bshum: The operation succeeded. |
| 20:51 |
bshum |
The 2.5-2.6 script isn't added yet to master, but I'll assume we should make the same change there. |
| 20:54 |
bshum |
Ahh, I see now. |
| 20:54 |
bshum |
It installs that when I use the create_database_extensions.sql to create my DB initially before restores |
| 20:54 |
bshum |
That explains it now. |
| 20:55 |
hbrennan |
Talk it out, bshum |
| 20:56 |
bshum |
Hehe, hbrennan++ |
| 20:56 |
bshum |
:) |
| 21:02 |
pinesol_green |
[evergreen|Ben Shum] Only create extension intarray if it does not already exist - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=d960485> |
| 22:27 |
|
mceraso joined #evergreen |
