| Time |
Nick |
Message |
| 00:04 |
|
kmlussier joined #evergreen |
| 01:11 |
pinesol_green |
Incoming from qatests: Test Success - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 02:21 |
|
berick joined #evergreen |
| 02:53 |
|
gsams joined #evergreen |
| 02:53 |
|
mtj_ joined #evergreen |
| 02:53 |
|
jboyer-isl joined #evergreen |
| 02:53 |
|
Guest12083 joined #evergreen |
| 02:53 |
|
mtcarlsoz joined #evergreen |
| 02:53 |
|
timhome joined #evergreen |
| 02:53 |
|
fparks_ joined #evergreen |
| 02:53 |
|
Callender joined #evergreen |
| 02:53 |
|
rri joined #evergreen |
| 02:53 |
|
ningalls joined #evergreen |
| 02:53 |
|
gmcharlt joined #evergreen |
| 02:53 |
|
sseng joined #evergreen |
| 02:53 |
|
Bmagic|2 joined #evergreen |
| 02:53 |
|
_bott_ joined #evergreen |
| 02:53 |
|
kayals joined #evergreen |
| 02:53 |
|
artunit joined #evergreen |
| 02:53 |
|
dreuther joined #evergreen |
| 02:53 |
|
wjr joined #evergreen |
| 02:53 |
|
tfaile_ joined #evergreen |
| 02:53 |
|
shadowspar joined #evergreen |
| 02:53 |
|
phasefx joined #evergreen |
| 02:53 |
|
BigRig joined #evergreen |
| 02:53 |
|
mtate joined #evergreen |
| 02:53 |
|
RBecker joined #evergreen |
| 02:53 |
|
rangi joined #evergreen |
| 02:53 |
|
remingtron__ joined #evergreen |
| 02:53 |
|
berickm joined #evergreen |
| 02:53 |
|
b_bonner joined #evergreen |
| 02:53 |
|
graced joined #evergreen |
| 02:53 |
|
dconnor_ joined #evergreen |
| 02:53 |
|
eby joined #evergreen |
| 02:53 |
|
eeevil joined #evergreen |
| 02:53 |
|
phasefx2_ joined #evergreen |
| 02:53 |
|
book` joined #evergreen |
| 02:53 |
|
pastebot joined #evergreen |
| 02:53 |
|
csharp joined #evergreen |
| 02:53 |
|
egbuilder joined #evergreen |
| 02:53 |
|
paxed joined #evergreen |
| 02:53 |
|
jcamins joined #evergreen |
| 02:53 |
|
pmurray joined #evergreen |
| 02:57 |
|
old_people joined #evergreen |
| 03:51 |
|
DPearl joined #evergreen |
| 03:57 |
|
berick joined #evergreen |
| 03:58 |
|
DPearl1 joined #evergreen |
| 04:12 |
|
DPearl joined #evergreen |
| 04:31 |
|
gsams joined #evergreen |
| 07:07 |
|
kmlussier joined #evergreen |
| 07:46 |
|
collum joined #evergreen |
| 07:54 |
bshum |
dbwells: Fwiw, 0864 completed on our production hardware in 29m57.139s |
| 07:54 |
bshum |
So I guess things will probably be okay. |
| 07:55 |
|
akilsdonk joined #evergreen |
| 08:06 |
|
Shae joined #evergreen |
| 08:38 |
|
eby joined #evergreen |
| 08:40 |
|
mmorgan joined #evergreen |
| 08:45 |
bshum |
Doh |
| 08:46 |
bshum |
eeevil: Putting one more tiny adjustment for 0870 from yesterday to fix the located URIs |
| 08:50 |
|
ericar joined #evergreen |
| 08:51 |
bshum |
Okay, we're good now. |
| 08:52 |
pinesol_green |
[evergreen|Ben Shum] LP1288938 - final adjustments for 0870 upgrade script - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=19f4385> |
| 08:54 |
|
mrpeters joined #evergreen |
| 09:09 |
|
jl- joined #evergreen |
| 09:10 |
jl- |
any idea where I could download a ton of marc records? I got 1.4 million from the boston college library but I need moar |
| 09:12 |
Guest30779 |
jl-: possibly https://archive.org/details/ol_data |
| 09:13 |
Guest30779 |
er. |
| 09:13 |
|
Guest30779 joined #evergreen |
| 09:15 |
dbwells |
jl-: How about this? http://openmetadata.lib.harvard.edu/bibdata |
| 09:15 |
jeff |
jl-: in addition to the data set at archive.org for openlibrary, there's a batch (or two!) of gutenberg records here: http://www.gutenberg.org/wiki/Gutenberg:Offline_Catalogs |
| 09:15 |
jeff |
dbwells++ |
| 09:17 |
|
dluch joined #evergreen |
| 09:20 |
* dbwells |
creates a '--load-sample-harvard' option, watches his test machine go up in smoke |
| 09:21 |
jeff |
--generate-random-bibs |
| 09:21 |
jeff |
--count 100M |
| 09:31 |
|
yboston joined #evergreen |
| 09:37 |
jl- |
thx |
| 09:44 |
|
RoganH joined #evergreen |
| 09:48 |
dbs |
jl-: archive.org has a bunch of sets of MARC records, like https://archive.org/details/marc_records_scriblio_net |
| 09:49 |
dbs |
https://archive.org/search.php?query=%28marc%29%20AND%20collection%3A%28ol_data%29 is a good search |
| 09:50 |
|
wlayton joined #evergreen |
| 09:51 |
jl- |
12 million from harvard should be good |
| 09:51 |
* dbs |
sees he's basically repeated jeff |
| 09:51 |
* dbs |
waves at wlayton |
| 09:52 |
wlayton |
hey everyone |
| 09:52 |
bshum |
Hey wlayton! |
| 09:52 |
wlayton |
for the 1st time in a while, I have some time to devote to EG |
| 09:53 |
wlayton |
is there anything that I can help with today? |
| 09:53 |
|
Dyrcona joined #evergreen |
| 09:55 |
dbs |
wlayton: we're aiming for a 2.6 release real soon now, so there's always the basic "Follow the install instructions and see if you can break anything", as well as trying out and signing off on the fixes for the 2.6 blocker bugs |
| 09:55 |
dbs |
https://bugs.launchpad.net/evergreen/+bugs?field.tag=2.6-rc-blocker |
| 09:55 |
wlayton |
sounds good. I'll give that a whirl |
| 09:56 |
dbs |
wlayton++ |
| 10:24 |
|
kayals joined #evergreen |
| 10:30 |
wlayton |
Just checking: we're still on Dojo 1.3.3? |
| 10:30 |
wlayton |
(for evergreen 2.6) |
| 10:31 |
dbs |
wlayton: believe it or not, yep |
| 10:31 |
dbs |
@ana technical deficit |
| 10:31 |
pinesol_green |
dbs: Beyond here be dragons. |
| 10:32 |
dbs |
INDEED |
| 10:33 |
wlayton |
I still have a Git branch kicking around from when I started trying to move things up to v1.6. I'll see if I can resurrect that. |
| 10:34 |
wlayton |
(I think I had passed my patches on the Joe Lewis, too, when he started working on that.) |
| 10:36 |
dbs |
In the OPAC, we're down to just one major use of Dojo (for the autosuggest widget), and I think everyone would like to see that simplified. So a TPAC-uses-Dojo-current / staff-client-uses-Dojo-ancient split could be a possibility. |
| 10:36 |
dbs |
That said, the web-based staff client project seems likely to ditch Dojo entirely. |
| 10:37 |
dbs |
@praise AngularJS |
| 10:37 |
wlayton |
AngularJS, right? |
| 10:37 |
* pinesol_green |
AngularJS is the very model of a modern major hacker |
| 10:38 |
|
mllewellyn joined #evergreen |
| 10:40 |
kmlussier |
dbs: Is it possible to do that (splitting the versions of Dojo between OPAC and staff client)? That question had come to my mind a while back when thinking about the autosuggest accessibility problems. |
| 10:42 |
dbs |
kmlussier: sure, anything's possible :) We would have to be careful to avoid conflicts using the catalogue in staff client mode (don't want to introduce mysterious memory leaks for example) but it could be done. |
| 10:48 |
eeevil |
dbs: well, ditch dojox at least ... with angular-dojo we could avoid throwing away lots of useful encapsulation |
| 10:55 |
|
ldwhalen_ joined #evergreen |
| 11:02 |
gmcharlt |
on account of bug 1286198, I'm going to do a RC for OpenSRF 2.3.0 |
| 11:06 |
|
geoffsams joined #evergreen |
| 11:06 |
wlayton |
One comment for EG 2.6 install instructions: It says to install most recent version of OpenSRF "(2.2.1 or later)". Should this say "(2.3.0 or later)" or will 2.2.1 work with 2.6? |
| 11:06 |
wlayton |
The downloads page on the website makes it look like 2.3.0 is required. |
| 11:06 |
gmcharlt |
2.3.0 is required |
| 11:07 |
pinesol_green |
Launchpad bug 1286198 in OpenSRF "Improve process control at startup" (affected: 1, heat: 6) [Wishlist,New] https://launchpad.net/bugs/1286198 |
| 11:07 |
|
mrpeters joined #evergreen |
| 11:09 |
eeevil |
gmcharlt: for inclusion in 2.3.0, you mean? cool! |
| 11:09 |
|
dbwells_ joined #evergreen |
| 11:09 |
gmcharlt |
eeevil: yep |
| 11:09 |
gmcharlt |
eeevil: also, I'm inclined to be boring |
| 11:09 |
|
mllewellyn joined #evergreen |
| 11:09 |
gmcharlt |
namely, s/--are-there-no-prisons/--ignore-orphans/ |
| 11:09 |
eeevil |
ha |
| 11:09 |
gmcharlt |
are you terribly attached to that? |
| 11:09 |
eeevil |
sure |
| 11:09 |
eeevil |
no, not attached |
| 11:10 |
gmcharlt |
OK :) |
| 11:10 |
eeevil |
I think that was senator's answer to berick's "--kill-with-fire" for shutdown with SIGKILL |
| 11:10 |
gmcharlt |
heh, good point |
| 11:13 |
|
kbutler joined #evergreen |
| 11:14 |
gmcharlt |
dbwells: is it OK to use the RC-blocker tag to mark adminstrivia bugs that are nonetheless prereqs for release of 2.6? |
| 11:14 |
dbwells |
gmcharlt: yes |
| 11:17 |
|
Callender_ joined #evergreen |
| 11:19 |
gmcharlt |
wlayton: https://bugs.launchpad.net/evergreen/+bug/1289450 |
| 11:19 |
pinesol_green |
Launchpad bug 1289450 in Evergreen "mark OpenSRF 2.3.0 as minimum required version" (affected: 1, heat: 6) [Low,New] |
| 11:19 |
|
Callender__ joined #evergreen |
| 11:22 |
wlayton |
gmcharlt: thanks! |
| 11:23 |
remingtron |
berickm: testing your branch on bug 1281750 raised an unrelated bug, I think. Can you (or others) confirm? |
| 11:23 |
pinesol_green |
Launchpad bug 1281750 in Evergreen 2.5 "Fetching user group info on deleted users creates unnecessary load" (affected: 2, heat: 10) [High,Confirmed] https://launchpad.net/bugs/1281750 |
| 11:23 |
remingtron |
open-ils.actor.usergroup.leaders.retrieve always returns all users in group, but master_account='f' for all but one |
| 11:23 |
remingtron |
my guess is 'if $u->master_account' evals the string 'f' as true? |
| 11:24 |
kmlussier |
Hey y'all. I noticed last night that a surprising number of IRC folks hadn't added their IRC handles when registering for the conference. I suspect in most cases, it was because a central person in an org handled registrations, but there may have been cases where somebody had a reason for excluding this information. |
| 11:25 |
kmlussier |
If it's okay to put your IRC handle on your badge and on the attendee list, could you let me know? |
| 11:25 |
gmcharlt |
kmlussier: fine for me |
| 11:25 |
dbs |
Fine with me |
| 11:27 |
jeff |
i hide behind my opaque irc nickname. |
| 11:27 |
kmlussier |
gmcharlt: And I assume you're okay with publishing your Twitter name? |
| 11:28 |
jeff |
kmlussier: i believe i listed the requested information on the registration for both irc and twitter. :-) |
| 11:28 |
gmcharlt |
kmlussier: yep |
| 11:28 |
kmlussier |
jeff: Yes, you did. :) |
| 11:28 |
jeff |
perlbrew users: this is handy: ``perlbrew list-modules | perlbrew exec --with perl-5.18.2 cpanm'' ref: http://perlbrew.pl/Reinstall-All-Modules-On-New-Perl.html |
| 11:29 |
dbwells |
eeevil: I was poking at bshum's funny record grouping problem a bit. I didn't get too far is solving it, but here is what I think we may at least have a few broken assumptions in this case. |
| 11:29 |
dbwells |
If anyone else wants to check it out, you can see the behavior here: http://spork1.biblio.org/eg/opac/results?bool=and;bool=and;bool=and;qtype=title;qtype=title;qtype=author;contains=exact;contains=contains;contains=contains;query=CONNECTICUT;query=;query=;_adv=1;locg=1;pubdate=is;modifier=metabib;page=5 |
| 11:30 |
dbwells |
eeevil: 1) We assume that records with a common metarecord will at least share a title, or a title and an author. In this case, we have an author == title situation (the author record has no title whatsoever). This is certainly rare, and shouldn't happen except with questionable data. |
| 11:30 |
dbwells |
2) Our metarecord grabbing in get_records_and_facets() doesn't seem to be doing any deleted checks (should it?). But when we go to count the records, we *do* check for deleted. We then wrongly assume this metarecord has just one bib, but we've fetched two (I think). |
| 11:31 |
|
Wyuli joined #evergreen |
| 11:31 |
dbwells |
3) Since we *think* we have one bib, we link directly to it, but we end up linking directly to the deleted bib we fetched. (related questions: Should deleted bibs even have a metarecord mapping? Is there protection against deleted bibs ending up as the 'master' record?) |
| 11:32 |
dbwells |
It seems like we perhaps need a deleted filter at the mmr unapi level or within get_records_and_facets(). I am not sure which is better or more possible at this point, or if we need to look at yet a different layer in the stack. |
| 11:33 |
dbwells |
eeevil: Anyway, that's just my brain dump on the matter. It isn't code I am terribly familiar with, so take it or leave it :) |
| 11:42 |
|
wlayton joined #evergreen |
| 11:42 |
|
Callender joined #evergreen |
| 11:56 |
kmlussier |
@eightball Will we get a March warm-up in 2 weeks? |
| 11:56 |
pinesol_green |
kmlussier: Naturally. |
| 11:56 |
kmlussier |
Hooray! |
| 11:56 |
kmlussier |
@love magic eightball |
| 11:56 |
pinesol_green |
kmlussier: The operation succeeded. kmlussier loves magic eightball. |
| 11:58 |
gmcharlt |
and thus the magic eightball gets to live another day! |
| 12:01 |
eeevil |
dbwells: I'll look at that this afternoon, thanks for brain-dumping! unfortunately, berick has been attacked by ice, and his power is out, and we'll want him to jump into this too, I think |
| 12:03 |
eeevil |
dbwells: the fingerprinting issue is a deficiency of the algo, and predates any of this code, of course. that would have happened in jspac. fwiw, anyway |
| 12:03 |
eeevil |
the deleted checks, I'll definitely look into. and thanks again |
| 12:03 |
* eeevil |
runs to lunch |
| 12:13 |
pinesol_green |
[opensrf|Lebbeous Fogle-Weekley] LP#1286198: When doing router-specific things, we don't need as much configuration loaded - <http://git.evergreen-ils.org/?p=OpenSRF.git;a=commit;h=82f19d8> |
| 12:13 |
pinesol_green |
[opensrf|Lebbeous Fogle-Weekley] LP#1286198: Offer ability to ignore what seem like orphan processes when starting things - <http://git.evergreen-ils.org/?p=OpenSRF.git;a=commit;h=81cdb6f> |
| 12:13 |
pinesol_green |
[opensrf|Lebbeous Fogle-Weekley] LP#1286198: Teach osrf_router to (optionally) write its own PID files - <http://git.evergreen-ils.org/?p=OpenSRF.git;a=commit;h=ff43e38> |
| 12:13 |
pinesol_green |
[opensrf|Galen Charlton] LP#1286198: use --ignore-orphans rather than --are-there-no-prisons - <http://git.evergreen-ils.org/?p=OpenSRF.git;a=commit;h=d3499f2> |
| 12:27 |
jeff |
=008 FIXEDLENGTHDATAELEMENT\\\\\\\\\\\\\\\\\\ |
| 12:27 |
jeff |
"where did YOU come from?" |
| 12:29 |
jcamins |
jeff: copy-and-pasted from RLIN? |
| 12:32 |
jeff |
neat. we have a bib whose biblio.record_entry.tcn_source is a marc record. |
| 12:32 |
bshum |
o.O |
| 12:32 |
bshum |
jeff: I fear your records |
| 12:33 |
|
jihpringle joined #evergreen |
| 12:35 |
gmcharlt |
jeff: please tell me it's a properly constructed name authority record for OCLC |
| 12:36 |
jeff |
it also has an interesting 024: =024 70$2Legacy Title Number$a9773 |
| 12:48 |
jeff |
and now i know where these records came from. :-) |
| 12:48 |
jeff |
email++ |
| 12:48 |
jeff |
(correlation between create_date of this batch and an old 2011 email of a pair of libraries going live) :-) |
| 12:51 |
bshum |
dbwells: Testing the negative balance branch on the test system. So far, found a lost bill, paid it off to zero, then checked in the item to go and delete it. So far no negative bills appear and no errors. Good first sign for me. |
| 12:51 |
bshum |
We'll keep testing here next week to look at some of the other scenarios. |
| 12:53 |
kmlussier |
dbwells: Dyrcona has loaded the branch on his test server too. But I probably won't get a chance to look at it until after the conference. |
| 13:00 |
dbwells |
bshum++ kmlussier++ |
| 13:02 |
jeff |
"Computer-generated, six-character numeric string that indicates the date the MARC record was created. Recorded in the pattern yymmdd." |
| 13:03 |
jeff |
which will become more useless first, 008/00-05 or MARC itself? :P |
| 13:04 |
eeevil |
bshum: I'll have a perl-only patch for you to try out re your deleted record issue. the fingerprinting thing is old, different and bigger, but there might be a short-term solution to help with that, too |
| 13:04 |
bshum |
eeevil: I'm mostly worried about the deleted bibs. The other thing is just junky bibs ruining our lives :) |
| 13:04 |
bshum |
eeevil: So happy to try whatever you point me at. |
| 13:04 |
eeevil |
cool |
| 13:05 |
bshum |
Our test system is working with berick's lightly squashed branch too. So hopefully I can check out some of the other things that have been fixed and get that signed off and in |
| 13:05 |
gmcharlt |
bshum: OpenSRF master now eschews AUTOLAOD |
| 13:05 |
jeff |
i mocked the two digit year-ness of 008/00-05, but in doing so realized what i was seeing. |
| 13:05 |
gmcharlt |
it also dislieks AUTOLOAD |
| 13:05 |
jeff |
1061120n |
| 13:05 |
gmcharlt |
and I can't type today |
| 13:05 |
pinesol_green |
[opensrf|Bill Erickson] LP#1179660: remove OpenSRF.pm AUTOLOAD - <http://git.evergreen-ils.org/?p=OpenSRF.git;a=commit;h=951d97a> |
| 13:05 |
jeff |
2006-11-20 |
| 13:05 |
bshum |
gmcharlt: Good to know, thanks. Lucky for me I grabbed what I needed earlier. |
| 13:06 |
jeff |
it's the year 20106! |
| 13:06 |
jeff |
19106 perhaps |
| 13:10 |
jeff |
anyway, there's 2474 mangled 008 fields that can be fixed. |
| 13:12 |
Dyrcona |
Heh.... |
| 13:12 |
jeff |
i would feel better if they were not all devoid of any other useful data. |
| 13:12 |
jeff |
1000303n xx 0 eng |
| 13:13 |
Dyrcona |
Just delete the 008s. They aren't required are they? |
| 13:15 |
jeff |
i suppose these also have a language and a literary form. |
| 13:15 |
jeff |
Dyrcona: "required" in what sense? :-) |
| 13:19 |
Dyrcona |
meh. It's MARC, it's gonna be junk. |
| 13:27 |
pastebot |
"eeevil" at 64.57.241.14 pasted "for bshu. should avoid deleted metarecord constituents" (34 lines) at http://paste.evergreen-ils.org/28 |
| 13:31 |
* bshum |
tests |
| 13:33 |
bshum |
eeevil: It doesn't like that |
| 13:33 |
bshum |
egweb: Context Loader error: Can't call method "content" on an undefined value at /usr/local/share/perl/5.14.2/OpenILS/WWW/EGCatLoader/Util.pm line 301. |
| 13:34 |
eeevil |
hrm. interesting (and odd). well, I'll look futher |
| 13:34 |
bshum |
Oh wait, maybe just a bad refresh, hang on. |
| 13:34 |
bshum |
Nope |
| 13:34 |
bshum |
It's broken |
| 13:34 |
eeevil |
and missing the deleted check |
| 13:34 |
eeevil |
yeah, it needs more |
| 13:34 |
eeevil |
but if you have a futher error, that'd be good |
| 13:36 |
bshum |
Well it just shows as an internal server error in the catalog |
| 13:36 |
bshum |
And that's all I really get in the log end |
| 13:37 |
eeevil |
huh ... nothing in the pg log? |
| 13:37 |
bshum |
Oh that I can check. That's on the other server |
| 13:37 |
bshum |
*whistles innocently* |
| 13:38 |
bshum |
Nope, nothing interesting in the postgres logs |
| 13:39 |
pastebot |
"eeevil" at 64.57.241.14 pasted "another for bshum. note the new first hunk, and the new part of the where clause" (46 lines) at http://paste.evergreen-ils.org/29 |
| 13:39 |
eeevil |
that'll avoid the error you got, at least |
| 13:39 |
bshum |
Okay |
| 13:42 |
bshum |
Well, it's a different error now. |
| 13:42 |
eeevil |
WHEEE |
| 13:42 |
bshum |
Or rather, nothing works at all now |
| 13:42 |
bshum |
I'm checking my copy/paste |
| 13:42 |
bshum |
egweb: Context Loader error: Can't locate object method "new" via package "OpenILS::WWW::EGCatLoader" at /usr/local/share/perl/5.14.2/OpenILS/WWW/EGWeb.pm line 111.\n |
| 13:43 |
bshum |
Is the error though |
| 13:43 |
eeevil |
we may want to wait for berick ... I'm not seeing where he's gathering the constituent record ids, and that's where we need to filter out deleted records |
| 13:44 |
* bshum |
puts things back for now to test other stuff |
| 14:05 |
wlayton |
stupid git question: how do I pull in berickm 's prototype code at http://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/collab/berick/web-staff-proto |
| 14:05 |
wlayton |
ideally, I'd like to pull that into a separate branch |
| 14:06 |
bshum |
You can always checkout that branch with something like git checkout -b localbranch remote/remotebranch |
| 14:06 |
bshum |
Or what I tend to do is merge git branches of targets I want |
| 14:07 |
bshum |
And then either rebase to move things back up or just go with it messy |
| 14:08 |
bshum |
So err, something like git checkout -b localname working/collab/berick/web-staff-proto I guess. To just checkout that branch as done. |
| 14:08 |
bshum |
*where you replace "localname" there with whatever you want to call it locally. |
| 14:15 |
dbwells |
eeevil: bshum: I think at that point, if we've come through the "grouped" code, we have a collection of mmr IDs, not bre IDs. Of course that doesn't help us, since mmrs have no 'deleted' property. |
| 14:16 |
dbwells |
eeevil: I think perhaps we should put a 'deleted' check right in the bre select in unapi.mmr itself. What do you think? |
| 14:16 |
wlayton |
bshum: sorry to bug you again, but `git checkout -b websc working/collab/berick/web-staff-proto` fails for me. |
| 14:17 |
wlayton |
From what I tell, I need to do a git-fetch beforehand...but to where? |
| 14:17 |
bshum |
wlayton: Did you add a git remote for the working repos? |
| 14:17 |
wlayton |
nope |
| 14:17 |
bshum |
http://wiki.evergreen-ils.org/doku.php?id=dev:git |
| 14:17 |
bshum |
I'll point you here then |
| 14:17 |
wlayton |
thanks -- I'll RTFM |
| 14:17 |
bshum |
in the "Quick start for Evergreen contributors" section |
| 14:17 |
bshum |
It describes how to add the working remote |
| 14:18 |
bshum |
No sorry, I'm a poor explainer sometimes. |
| 14:18 |
dbwells |
eeevil: maybe both the 'leadrec' and 'subrec' selects? |
| 14:18 |
eeevil |
dbwells: I think yes ... you mean inside unapi.mmr ... ah, that's what you said. yes, sorry. |
| 14:19 |
bshum |
wlayton: A helpful trick I've seen from our git servers is that they list the URL for where to go on the main summary page for the repo |
| 14:19 |
bshum |
http://git.evergreen-ils.org/?p=working/Evergreen.git;a=summary (look for the URL part) |
| 14:19 |
wlayton |
bshum: no, not at all. I was just being too lazy. |
| 14:19 |
bshum |
And that's handy for knowing where to set the path for the git remote |
| 14:20 |
|
berick joined #evergreen |
| 14:20 |
bshum |
Not all gitweb are setup that way, but that was a nice touch our git-admins did for us |
| 14:20 |
eeevil |
dbwells: yes, I think we just need to add AND NOT bre.deleted to the subrec select |
| 14:21 |
dbwells |
eeevil: Yeah, I guess we can't do it on the leadrec, since that is predetermined by master_record. |
| 14:22 |
eeevil |
dbwells: I'm going to doublecheck now, but IIRC, deleting a lead bib will cause the MR to choose a new lead |
| 14:22 |
dbwells |
eeevil: That leads again to one of my questions from earlier, though. Do we have code to make sure that master_record records aren't deleted? |
| 14:22 |
dbwells |
eeevil: ok :) |
| 14:22 |
eeevil |
I know we did, once upon a time ;) |
| 14:23 |
wlayton |
bshum: I'm in business now. Thank you very much! |
| 14:23 |
|
RoganH joined #evergreen |
| 14:23 |
bshum |
wlayton++ |
| 14:23 |
bshum |
yay! |
| 14:24 |
eeevil |
dbwells: we don't now, but we're about to! :) |
| 14:24 |
wlayton |
wlayton-- #Sucks at git |
| 14:25 |
csharp |
@karma git |
| 14:25 |
pinesol_green |
csharp: Karma for "git" has been increased 21 times and decreased 0 times for a total karma of 21. |
| 14:25 |
csharp |
@loves git |
| 14:25 |
pinesol_green |
csharp: git doesn't seem to love anything. |
| 14:25 |
csharp |
heh |
| 14:25 |
bshum |
Heh |
| 14:26 |
bshum |
I know I already love git |
| 14:26 |
csharp |
@quote add < pinesol_green> git doesn't seem to love anything. |
| 14:26 |
pinesol_green |
csharp: The operation succeeded. Quote #81 added. |
| 14:27 |
bshum |
Haha |
| 14:31 |
jeff |
@whocares git |
| 14:31 |
pinesol_green |
Dyrcona, tsbere, bshum and csharp love git |
| 14:31 |
pinesol_green |
kmlussier hates git |
| 14:31 |
dbwells |
eeevil: Yeah, sorry, got your comment after I posted my question. Did a quick test by deleting record 15 from the DB (it was master of a group of three), but it looks like the master_record is still set to 15. |
| 14:31 |
bshum |
Maybe git should hate kmlussier :) |
| 14:31 |
kmlussier |
git does hate kmlussier. That's the problem. |
| 14:31 |
|
_bott_ joined #evergreen |
| 14:32 |
dbwells |
eeevil: I think bshum managed to dig up some old demons with this one ;) |
| 14:32 |
eeevil |
yeah ... someone (maybe me) moved some code into metabib.remap_metarecord_for_bib that is causing problems |
| 14:32 |
jeff |
iirc, it is quite possible to delete a master record -- i don't know if there is/was protection against a deleted record being selected as master in the first place. |
| 14:32 |
eeevil |
there was back in the open-ils.ingest days... not now though |
| 14:34 |
dbwells |
thanks to jeff, there's no going back on that :) |
| 14:34 |
jeff |
hey, the history's there. :-) |
| 14:35 |
bshum |
Hehe |
| 14:35 |
jeff |
it's just no longer an active, running service (if you followed the recommendations when upgrading). ;-) |
| 14:36 |
bshum |
I'll admit, I found out that I initially installed an older git branch because I was using the ingest change to mark times since the last time I upgraded our test server and was surprised to still see it in my opensrf.xml.example |
| 14:36 |
|
hbrennan joined #evergreen |
| 14:37 |
bshum |
So jeff, your change spared me from looking really stupid for claiming we'd "upgraded" our test systems. |
| 14:38 |
bshum |
As for old demons though, I didn't mean it, really I didn't! |
| 14:39 |
dbwells |
That's what they all say |
| 14:40 |
pinesol_green |
[evergreen|Elliot V] LP#1077811 Inconsistent INSTALL Instructions - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=f102496> |
| 14:52 |
bshum |
yboston++ # and now I get what MX / LATAM is all about. |
| 14:53 |
yboston |
bshum: :) it took me a while to understand what does meant. I thought at first the email was spam |
| 14:54 |
yboston |
bshum: I almost mentioned that we are actually using a hybrid american / canadian English docs |
| 14:54 |
yboston |
s/does/those/ |
| 14:55 |
bshum |
yboston: As far as status goes, I've been meaning to dust off the TPAC translation file for Spanish at some point. Once upon a time, one of our libs helped to contrib the spanish translation for JSPAC, but we haven't had time to revisit and update it. |
| 14:55 |
bshum |
For the client, that was ultimately a much harder process, so we didn't get to it. |
| 14:55 |
yboston |
bshum: let me know if I can help |
| 14:58 |
bshum |
My middle school Spanish doesn't lend itself well to verifying that things work out. But I know some of the technical side of how things happen in LP at least. Maybe we can put our heads together sometime at the conference. |
| 14:58 |
bshum |
Where's the i18n interest group, eh? :D |
| 14:58 |
bshum |
(kidding, kidding) |
| 14:59 |
gmcharlt |
bshum: I think you've found it! |
| 15:00 |
bshum |
At GSOC mentor summit, I sat in and took notes for the i18n session. It was quite interesting to see the pain points for other projects. And other tools they employ. |
| 15:00 |
bshum |
I'm still curious to see if we could do some sort of tool like Transifex to directly edit strings from the web vs. git. |
| 15:00 |
bshum |
To make it a little easier to sync things |
| 15:02 |
RoganH |
hopefully simple TPAC question (I'm fairly TPAC ignorant): If you wanted to set ctx_org to something static in the register.tt2 could you just give it org unit IDs? |
| 15:04 |
berick |
RoganH: for the home library selector? |
| 15:04 |
RoganH |
berick: yes |
| 15:05 |
berick |
you want a default value or a value that cannot be changed? |
| 15:05 |
RoganH |
berick: a value that can't be changed |
| 15:05 |
RoganH |
berick: essentially we have different libraries that want custom pages that will look like parts of their sites, not the opac |
| 15:06 |
RoganH |
berick: and many won't use it at all |
| 15:06 |
berick |
the best way to set the value is via url param (or cookie) using physical_loc or locg. that way the back-end uses the same org as the UI |
| 15:07 |
berick |
you need that for the OU settings, etc. to match up |
| 15:07 |
berick |
to prevent changing the value, set disabled='disabled' on the org unit <select> |
| 15:07 |
RoganH |
berick: I gotcha |
| 15:07 |
berick |
there may be a way to pass that in.. |
| 15:07 |
berick |
since you don't want to change org_selector.tt2 itself |
| 15:07 |
RoganH |
berick: not particularly but I think I can make this work |
| 15:09 |
berick |
aha, in register.tt2, where it says valid_org_list=ctx.register.valid_orgs , you could change it to valid_org_list=[one_org_id] |
| 15:09 |
berick |
then you don't have to disable it, because it will only have 1 value |
| 15:09 |
RoganH |
berick: perfect, that's what I was looking to do |
| 15:12 |
RoganH |
berick: thanks, that worked perfectly |
| 15:12 |
berick |
cool, welcome |
| 15:17 |
hbrennan |
bshum: Congratulations on being my 10th Twitter follower! |
| 15:17 |
bshum |
hbrennan: Heh, I'm honored ;) |
| 15:17 |
hbrennan |
I still don't know how to use it. But I did resurrect my acct at the conference last year so I wouldn't miss out on eating/drinking opportunities. |
| 15:20 |
bshum |
I tweet more often at conferences. |
| 15:22 |
|
Dyrcona joined #evergreen |
| 15:37 |
|
dluch joined #evergreen |
| 15:40 |
jeff |
AHA |
| 15:40 |
bshum |
!! |
| 15:40 |
jeff |
just bit myself with Can't locate object method "initialize" via package "OpenILS::Application::Search::Z3950" at /usr/local/share/perl/5.14.2/OpenILS/Application/Search.pm line 31. |
| 15:40 |
jeff |
(opensrf autoload removal) |
| 15:41 |
jeff |
easy to debug with "osrf_control --localhost --no-daemon --start --service open-ils.search" combined with "oh hey, this line needs to be removed!" |
| 15:44 |
berick |
jeff: it's fixed in currrent master, btw |
| 15:44 |
jeff |
yep! :-) |
| 15:45 |
berick |
that's the first (and only, so far) instance of that I've hit |
| 15:55 |
bshum |
eeevil: I can confirm that the reason I've had icon / format search issues is due to lacking reingests. I'll schedule some time over the weekend to populate our test DB. |
| 15:55 |
eeevil |
bshum: I'm both glad to hear it's reingest-related and sad to hear you'll have to reingest ;) |
| 15:56 |
bshum |
Fwiw, the icons look really cool for the two or three bibs I manually reingested to test that out. |
| 15:57 |
bshum |
Or rather, I can see potential there. |
| 15:58 |
bshum |
For configuring these things, I'm thinking it's the coded value maps? |
| 15:58 |
dbwells |
bshum: Are you saying a full reingest is needed, or just the new attribute-only reingest? |
| 15:58 |
bshum |
dbwells: Let me try attribute-only if I can find the instructions for that. I just did a full reingest to get it over with to make it known to myself that it wasn't just broken. |
| 16:01 |
dbwells |
bshum: You could reingest all the attributes, or even try just the icon_format with a spell eeevil gave on the bug: select count(metabib.reingest_record_attributes(id,'{icon_format}'::TEXT[],marc,false)) from biblio.record_entry where id > 0 and not deleted; |
| 16:01 |
eeevil |
indeed. that'll be much quicker |
| 16:02 |
bshum |
dbwells: Yeah I was just trying to find something like that from the bug. Let's say that's not spelled out for end users :) |
| 16:02 |
dbwells |
just list the attributes in that text array, or I think a null for the second parameter will do them all. |
| 16:04 |
bshum |
You guys are talking about https://bugs.launchpad.net/evergreen/+bug/1053397 right? (doesn't know the background of this stuff entirely) |
| 16:04 |
pinesol_green |
Launchpad bug 1053397 in Evergreen "TPAC - Missing Meta-record Level Hold" (affected: 8, heat: 42) [Wishlist,Fix committed] |
| 16:04 |
dbwells |
bshum: whatever you do, please time it for me :) I am always interested in early performance reports. |
| 16:05 |
dbwells |
bshum: yes, comment 25 is where I pulled that from |
| 16:06 |
bshum |
dbwells: Gotcha, I see. |
| 16:06 |
bshum |
So... this is an "undocumented" step then for the upgrade process. That might be good to add before we release. |
| 16:07 |
bshum |
I'll let you know what the timing is. |
| 16:07 |
dbwells |
bshum: Yes, I am definitely tracking with you on that thought. |
| 16:08 |
dbwells |
It might end up a 'spit out instructions at the end' type thing depending on how long it takes. |
| 16:08 |
bshum |
That makes sense. I was also thinking about what it says in the comments about running these in parallel? |
| 16:10 |
bshum |
To confirm, running just a single bib ID in the example noted in comment 25 works to bring up the format icons. |
| 16:11 |
jboyer-isl |
I'm not sure there's a better way to spend a Friday afternoon than coming up with a list of 20+ indexes missing from a production database. |
| 16:11 |
jboyer-isl |
Good times. |
| 16:11 |
bshum |
jboyer-isl: Dude, ouch. |
| 16:12 |
jboyer-isl |
4-5 of them are essentially useless (we don't use edi or authority) but the 9 metabib ones will probably make a difference! |
| 16:12 |
eeevil |
berick: whoo hoo! websockets! I have a (probably silly) question ... could OpenSRF.ClientSession.prototype.request() notice that someone wants to use sync-mode and 1) grab the current transport 2) temporarily set the transport to XHR 3) then set it back? |
| 16:12 |
jboyer-isl |
bshum: But it is a good thing to check now and then, upgrade path vs. stock, to make sure that everything is in order. |
| 16:13 |
berick |
eeevil: yes, in theory, i don't see why not |
| 16:13 |
|
RoganH joined #evergreen |
| 16:14 |
eeevil |
jboyer-isl: look at it this way ... after you run 9 "CREATE INDEX CONCURRENTLY" statement your DB will be blazing fast |
| 16:14 |
bshum |
Or on fire. |
| 16:14 |
jboyer-isl |
eeevil: that is how I have chosen to interpret my situation. :D |
| 16:15 |
eeevil |
berick: cool... I may pitch in on that, then |
| 16:15 |
dbwells |
bshum: I would consider also including sr_format and mr_hold_format when you run the reingest command, since those are the other completely new defs (I think that is all). |
| 16:16 |
bshum |
Hmm.... |
| 16:16 |
berick |
eeevil: i'm curious, what benefit do you see in using sync requests? |
| 16:17 |
dbwells |
bshum: But any that are now 'multi' could potentially improve by being reingested, I think. |
| 16:17 |
bshum |
Maybe I should just do a full reingest over the weekend anyways then. I'm sure I can ask someone to come up with more reasons :) |
| 16:18 |
* dbwells |
thinks this is going to need some more testing and consideration |
| 16:18 |
eeevil |
berick: the chance to reuse some existing code in the SC rewrite, primarily |
| 16:18 |
eeevil |
(and flexibility) |
| 16:18 |
eeevil |
dbwells: most are now multi, in fact |
| 16:19 |
jboyer-isl |
berick: It's not really the same with JS, but if you can do some of the network stuff in a background thread, waiting on it to return data directly is simpler than dealing with callbacks |
| 16:19 |
dbwells |
bshum: I just *really* don't want a full reingest to be part of the 2.6 upgrade process, if it can be avoided. I am pretty sure the worst case (for this feature group, at least) would be the full attribute reingest (i.e. reingest_record_attributes() with a null second param). |
| 16:20 |
berick |
eeevil: aha to #1. for #2, i would argue taht kind of flexibilty is a big negative |
| 16:20 |
berick |
sync is never (prove me wrong) a good thing |
| 16:20 |
bshum |
dbwells: I'm happy to try whatever you'd like me to attempt with our DB. I just have to work out the timing with the folks who want to poke at the feature :) |
| 16:21 |
berick |
jboyer-isl: i totally agree, which is why if we make it standard / available, people will use it, which we don't want |
| 16:21 |
berick |
it's easier to code, but it's bad practice |
| 16:21 |
berick |
unless you're goal is frozen browsers and serialized network communication |
| 16:22 |
eeevil |
berick: well, with streaming responses (which, obv, we can't /actually/ do with sync) it is easier to code for, IMHO |
| 16:22 |
berick |
right, sync is 110% easier to code |
| 16:22 |
berick |
and humans, being lazy, will do sync in a hurry |
| 16:22 |
eeevil |
and there are times that you want strictly serialized requests that you can't plan completely in advance |
| 16:23 |
eeevil |
see: pcrud.apply() |
| 16:23 |
berick |
you can serialize wt/ asycn |
| 16:23 |
eeevil |
sure |
| 16:23 |
berick |
the new pcrud service in the angular code is all async |
| 16:23 |
* eeevil |
needs to go look at that |
| 16:24 |
berick |
fwiw, using promises makes things a lot easier for async |
| 16:24 |
berick |
well, considerably easier.. it's not a silver bullet |
| 16:24 |
bshum |
dbwells: That said, don't kill yourself coming up with new solutions. If we have to full reingest, it wouldn't be the first time we did that between major version upgrades (in fact I'm almost sure that's been the case for at least the last three or so) |
| 16:25 |
bshum |
It's just especially unfun doing full reingests between upgrade scripts during ongoing development :\ |
| 16:26 |
eeevil |
so, the openils dojo module's pcrud.apply() takes an array of objects (various types) with their isnew, isupdated, isdeleted flags set (mixed is fine) and does the right thing inside a transaction ... IIRC, it can do either sync or async ... the former being good for a logicially-single update, the latter for pile of logicially separate updates |
| 16:26 |
dbwells |
bshum: I think the upgrade might say 'do X now, do Y when convenient', where x is: |
| 16:26 |
dbwells |
bshum: select count(metabib.reingest_record_attributes(id,'{icon_format,sr_format,mr_hold_format}'::TEXT[],marc,false)) from biblio.record_entry where id > 0 and not deleted; |
| 16:27 |
eeevil |
now, we don't use pcrud.apply a ton, except in batch admin interfaces |
| 16:27 |
eeevil |
so it's a stick man, if not a straw man ... ;) |
| 16:27 |
eeevil |
but, it's the example that comes to mind |
| 16:27 |
dbwells |
bshum: So I guess I'd like you to try that version and see what you get for time. |
| 16:27 |
dbwells |
bshum: How big is your DB? |
| 16:28 |
dbwells |
in bib records |
| 16:28 |
berick |
eeevil: pcrud transactions don't require sync calls.. i'm confused what sync buys you there |
| 16:28 |
eeevil |
but, if I have to give up sync-ish code for callbacks and promises to get fast and small and non-brittle code, it's a small price ;) |
| 16:29 |
bshum |
dbwells: We have....1163490 bibs (not deleted) |
| 16:29 |
bshum |
In this test system |
| 16:30 |
dbwells |
bshum: My *very* rough estimate is that that last command I gave would take about an hour for a DB that size, give or take. |
| 16:30 |
bshum |
dbwells: Worth a shot then. Full reingest would certainly take longer. |
| 16:31 |
eeevil |
berick: it's the conceptual (not code-ish) difference between "rewrite the permission list for a user" (conceptually atomic) and "update these 500 copies, and tell me along the way how we're doing" (conceptually streaming) |
| 16:31 |
eeevil |
you absolutely don't /need/ sync for the first one |
| 16:32 |
bshum |
dbwells: I'm running it now, I'll check it later this evening to see if your estimate was on target. |
| 16:32 |
bshum |
But either way I'll get the final time |
| 16:32 |
berick |
eeevil: unfortunately, i'm about to lose my scrollback. hold that thought! |
| 16:33 |
dbwells |
bshum: Thanks! I'll be happy if it's somewhere between half and double my estimate :) |
| 16:33 |
eeevil |
berick: but, like I said, I think my only real argument in favor of thunking to sync is to reuse some existing code in the SC rewrite |
| 16:33 |
berick |
eeevil: gotcha. i def. can see the value of that. |
| 16:34 |
eeevil |
bshum: did you have a bug for the MR display issues? with berick's help, I think I've killed it (and fixed some other general MR problems) |
| 16:34 |
bshum |
eeevil: I haven't had a chance to file it yet now that you mention it. |
| 16:35 |
eeevil |
I can, if you like |
| 16:35 |
bshum |
That'd be great, and I'm happy to test those fixes too |
| 16:35 |
eeevil |
bshum: actually, you know, I'll just tack it onto berick's ... bug 1284864 |
| 16:35 |
pinesol_green |
Launchpad bug 1284864 in Evergreen "TPAC metarecord / formats repairs and usability additions" (affected: 1, heat: 6) [Undecided,Confirmed] https://launchpad.net/bugs/1284864 |
| 16:35 |
bshum |
eeevil: That sounds good to me. |
| 16:37 |
bshum |
The hit count stuff in that branch was very nice btw. |
| 16:37 |
bshum |
Made it much easier to figure out which were multiple bibs and all |
| 16:37 |
eeevil |
berick++ |
| 16:37 |
bshum |
Definitely, berick++ |
| 16:37 |
kmlussier |
@marc 505 |
| 16:37 |
pinesol_green |
kmlussier: The titles of separate works or parts of an item or the table of contents. The field may also contain statements of responsibility and volume numbers or other sequential designations. (Repeatable) [a,g,r,t,u,6,8] |
| 16:38 |
bshum |
I haven't been able to try metarecord holds yet since without the formats, it seemed unhappy with them |
| 16:38 |
bshum |
I'm hopeful that post reingest that'll be good to test |
| 16:43 |
eeevil |
bshum: http://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/collab/miker/metarecord-deleted-constituents |
| 16:46 |
dbwells |
eeevil: so it looks like we were on the right track earlier? |
| 16:48 |
dbwells |
glad to see it wasn't a waste of time then :) |
| 16:58 |
eeevil |
dbwells: you were all over it, as usual :) |
| 17:00 |
dbwells |
eeevil: thanks, as my daughter likes to say, I just do "my personal best" :) |
| 17:00 |
eeevil |
:) |
| 17:13 |
|
16WAA1GK3 joined #evergreen |
| 17:17 |
|
mmorgan left #evergreen |
| 17:21 |
|
timf joined #evergreen |
| 17:46 |
kmlussier |
dbwells++ |
| 17:47 |
kmlussier |
And apologies if I caused any sleepless nights. :( |
| 17:55 |
dbwells |
kmlussier: thanks, and no worries. I should never blame others for my own compulsions :) |
| 18:18 |
bshum |
dbwells: Fwiw, 67m33.520s for that script you had me run |
| 18:18 |
bshum |
So pretty right on the money |
| 18:19 |
dbwells |
bshum: sweet, thanks! Did it get the icons to show up as expected? |
| 18:20 |
bshum |
I'm about to apply the fix for deleted bib leakage first |
| 18:20 |
bshum |
Then fire up the test server |
| 18:20 |
bshum |
Two shakes and I should know |
| 18:20 |
dbwells |
ok, I'm heading out right now, so I'll see how it went later. Have a good weekend. |
| 18:21 |
bshum |
Have a good one! |
| 18:21 |
bshum |
dbwells++ |
| 18:21 |
bshum |
Icons whee! |
| 18:21 |
bshum |
Err, mostly. |
| 18:22 |
* bshum |
wonders what's wrong with this bib record now... |
| 18:22 |
bshum |
Maybe I'll find out after dinner |
| 18:27 |
|
mrpeters joined #evergreen |
| 20:33 |
|
Dyrcona joined #evergreen |
| 20:47 |
|
zxiiro joined #evergreen |
| 21:15 |
bshum |
eeevil: Applied the changes in the upgrade script for the metarecord deleted bibs issue. Doing that alone doesn't solve the problems though. Looks like we need to tell the system to use those new functions to find non-deleted bibs where all the bibs are deleted in the metabib.metarecord.master_record |
| 21:16 |
bshum |
Reingesting the deleted bib forced that Connecticut record out of the way at least, so that much is working right with the corrected functions. |
| 21:23 |
bshum |
eeevil: http://pastie.org/8897557 is what I ran to find deleted bibs and correct them (the query found 121k rows that way) |
| 21:24 |
bshum |
I guess we have lots of deleted bibs with similar fingerprints. |
| 21:29 |
bshum |
Which actually makes sense given how many dupe bibs we've deleted over the years |
| 21:41 |
* jeff |
works on additional "bibs with these issues are worth knowing about" criteria |
| 22:14 |
|
zxiiro joined #evergreen |
| 22:27 |
eeevil |
bsum: right. I fixed an old bug there. We probably need a cleanup script. |
| 23:45 |
|
jboyer-isl joined #evergreen |
