| 00:47 |
pinesol_green |
Incoming from qatests: Test Failure - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 06:47 |
|
remingtron_ joined #evergreen |
| 06:47 |
|
jboyer_isl joined #evergreen |
| 06:47 |
|
sseng_ joined #evergreen |
| 06:48 |
|
fparks joined #evergreen |
| 06:48 |
|
BigRig_ joined #evergreen |
| 06:48 |
|
tfaile joined #evergreen |
| 06:58 |
phasefx |
that test failure came from live_t/03-overdue_circ.t, expected 13 bills, got 12. probably bad logic in the test surrounding certain dates and not in Evergreen. Will look later, unless someone gets the itch :) |
| 07:07 |
* phasefx |
had to double-take, but today's xkcd: http://xkcd.com/1340/ apropos dates |
| 07:31 |
csharp |
wow - so we'll really be kicking ourselves in 8000 years for not starting to use the five-digit year now, right? ;-) |
| 07:40 |
|
rjackson-isl joined #evergreen |
| 08:00 |
|
collum joined #evergreen |
| 09:48 |
jeff |
pg 9.2 vs 9.3? |
| 09:48 |
jeff |
dumb luck on my dataset? |
| 09:49 |
|
mrpeters joined #evergreen |
| 09:49 |
eeevil |
you could, conceivably, use it at the end, like: //*[local-name() == "leader"]/substring(.,7,1) ... but I haven't tested it. |
| 09:49 |
eeevil |
jeff: I'm surprised it works, TBH |
| 09:50 |
eeevil |
it's been a pain point for me since we first started thinking about in-db indexing |
| 09:50 |
Dyrcona |
jeff: If I add the name space for xpath-functions, I get the following: DETAIL: xmlXPathCompOpEval: function substring not found |
| 09:54 |
* jeff |
runs a "just how many marc values are invalid xml" query in the reporting db |
| 09:56 |
dbwells |
jeff: Which version of pg are you running? |
| 11:00 |
csharp |
@eightball is there a statute of limitations for cataloging errors? |
| 11:00 |
pinesol_green |
csharp: Maybe... |
| 11:04 |
|
dave_bn joined #evergreen |
| 11:05 |
dave_bn |
hi everyone! |
| 11:05 |
dave_bn |
I am looking for a quick way to test evergreen |
| 11:06 |
dave_bn |
so I need to install it on a test server. Is there an automated installation script that comes with a documentation? |
| 11:06 |
dave_bn |
or perhaps a virtual image I could deploy |
| 11:06 |
dave_bn |
or more or less easy installation instructions. |
| 11:07 |
dave_bn |
I have spent several hours with the official installation guides and also with sitka and paxed scripts, but have not been able to configure them properly due to lack of documentation. |
| 11:08 |
jeff |
what documentation did you find lacking? |
| 11:08 |
jeff |
i don't know that there is a current VM image for download, but I do know of at least one public "attempt to install everything automatically" script. let me see if i can find the url before someone else. |
| 11:09 |
dave_bn |
jeff: thank you for your help |
| 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 |
| 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 |
| 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? |
| 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 |
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: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: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: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: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. |
| 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: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: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: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 |
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 :) |
| 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++ |
| 09:53 |
Dyrcona |
@dnd |
| 09:53 |
pinesol_green |
Dyrcona: strength:16 dexterity:9 constitution:16 intelligence:9 wisdom:12 charisma:7 |
| 09:53 |
Dyrcona |
random_stats-- |
| 09:54 |
jeff |
hey, build tests pass! |
| 09:54 |
jeff |
i wish i knew more c. |
| 09:55 |
csharp |
C++ #ha! |
| 09:57 |
|
ericar_ joined #evergreen |
| 10:23 |
bshum |
Doh, time change this weekend? *big sigh* |
| 10:56 |
bshum |
dbs++ |
| 10:56 |
eeevil |
bshum: Imma look at the located URIs thing from the other day RSN |
| 10:57 |
phasefx |
bshum: just forward porting for those who still use it. Not pushing for integration into master |
| 10:57 |
bshum |
eeevil: Sounds good, I'm going to reingest a few more test records (not enough time to do the whole thing) |
| 10:57 |
bshum |
(yet) |
| 10:57 |
bshum |
phasefx: Cool, just thought I'd check. |
| 10:57 |
bshum |
Thanks |
| 10:58 |
pastebot |
"eeevil" at 64.57.241.14 pasted "for bshum ... please toss on your test server :)" (33 lines) at http://paste.evergreen-ils.org/26 |
| 11:00 |
bshum |
Well, there's a syntax error |
| 11:00 |
bshum |
Missing parenthesis / hanging ; maybe |
| 11:01 |
eeevil |
um ... doesn't look like it to me... |
| 11:01 |
* eeevil |
runs to a meeting, will look after |
| 11:02 |
tsbere |
bshum/eevil: Perhaps add a ")x" before the order by at the end? |
| 11:03 |
tsbere |
(sans quotes, but with the x) |
| 11:06 |
bshum |
tsbere: Indeed that lets it run. I'll test further once I get to the office in a bit. |
| 11:07 |
eeevil |
tsbere: ah, yep. the upgrade script was already broken in that way ... so, I'll fix that too in a patch. bshum: ... nm :) |
| 11:12 |
|
kmlussier joined #evergreen |
| 11:29 |
eeevil |
bshum: http://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/collab/miker/located-uris-leaking (with the subquery fixed. thanks, tsbere) |
| 13:45 |
bshum |
berick++ |
| 13:49 |
pinesol_green |
[evergreen|Bill Erickson] LP#1287973 recover row breaks in TPAC advanced search - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=51473ec> |
| 13:53 |
|
Bmagic joined #evergreen |
| 13:56 |
bshum |
eeevil: Tested that new function and at least I'm not seeing crazy URIs everywhere :) |
| 13:57 |
|
krvmga joined #evergreen |
| 13:58 |
krvmga |
if baker and taylor doesn't supply a jacket image, can be supply our own? |
| 13:58 |
bshum |
krvmga: For...... the catalog? |
| 14:00 |
eeevil |
dbwells: process question... are we saying, collectively, that one should be able to upgrade from, say, alpha to beta to RC to gold? |
| 14:01 |
eeevil |
dbwells: or is the only promise for 2.5.current to 2.6.0 to work? |
| 14:01 |
dbwells |
eeevil: my understanding has always been the second |
| 14:01 |
eeevil |
(I'd rather just fix the existing upgrade scripts, especially now that we're past beta, and say "testing should be on a fresh system, either upgraded or baseline, not upgraded from the previous beta") |
| 14:02 |
bshum |
I agree. People shouldn't necessarily expect that it'll go alpha --> beta --> rc, etc. |
| 14:02 |
eeevil |
good, ok ... then I can answer bshum! ;) |
| 14:02 |
bshum |
That said, |
| 17:53 |
bshum |
dcook: No it's probably just my generally addled brain trying to make weird phrases. I do that all the time. |
| 17:55 |
bshum |
Some weird place between whipping up something (conjuring) and tack, like sticking in a pin in something. A small trivial thing. |
| 17:55 |
dcook |
Fair enough :) |
| 17:57 |
bshum |
dbwells: I put a time on 0864 this time, so I'll get a sense of how long it'll take to complete on our duplicate production hardware with the test database. |
| 18:17 |
bshum |
Hmm, running for 20+ minutes now. Guess I'll check back at it tomorrow. |
| 18:17 |
bshum |
Or later tonight I mean |
| 18:20 |
pinesol_green |
[evergreen|Dan Wells] Forward-port 2.5.2-2.5.3 upgrade script - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=5d62e7d> |
| 18:30 |
pastebot |
"bshum" at 64.57.241.14 pasted "For hbrennan, top 50 karma entries in the pinesol_green database" (51 lines) at http://paste.evergreen-ils.org/27 |
| 18:30 |
* bshum |
amuses himself with the c|16 entry there at the end. c++ :P |
| 09:37 |
pinesol_green |
Dyrcona: The operation succeeded. |
| 09:38 |
csharp |
@later tell huginn please tell #koha we said "hello" |
| 09:38 |
pinesol_green |
csharp: The operation succeeded. |
| 09:40 |
phasefx |
any objections to subscribing pinesol to http://testing.evergreen-ils.org/~live/ in this channel? It's been doing it in #openils-evergreen for a while now as an experiment |
| 09:40 |
csharp |
phasefx: no objections here |
| 09:41 |
Dyrcona |
My question would be: How spammy is that? |
| 09:41 |
phasefx |
one message a day |
| 09:41 |
bshum |
Fix the live test failure and I'll say yes. |
| 09:41 |
bshum |
:D |
| 09:42 |
bshum |
Cause otherwise it'll just make me sad to see that message. |
| 09:42 |
Dyrcona |
I don't think one message a day would be a problem. |
| 09:42 |
* phasefx |
was kind of hoping folks seeing the failure message would cause some impetus to getting it fixed :) |
| 09:42 |
|
yboston joined #evergreen |
| 09:42 |
phasefx |
there's a bug report for it <looks> |
| 09:43 |
csharp |
looks like a missing perl lib? |
| 09:43 |
jeff |
I started looking at Test::Output last night. I'm interested in getting it fixed. I don't like the idea of us getting used to live tests failing. :-) |
| 09:43 |
jeff |
and yes, bug 1279420 |
| 09:43 |
phasefx |
bug 1279420 |
| 09:43 |
pinesol_green |
Launchpad bug 1279420 in Evergreen "need Test::Output prerequisite" (affected: 1, heat: 6) [Medium,Triaged] https://launchpad.net/bugs/1279420 |
| 09:43 |
phasefx |
jeff++ |
| 09:46 |
csharp |
I can test the ubuntu targets |
| 09:46 |
phasefx |
csharp++ |
| 09:52 |
dbs |
phasefx: can you add a <meta charset="utf-8"> tag to the head of the testing output? |
| 09:53 |
dbs |
jeff++ |
| 09:54 |
phasefx |
dbs: can do, and it's all in a public git branch |
| 09:56 |
phasefx |
(that it refreshes and pulls from every night before running) |
| 09:57 |
phasefx |
dbs: so just a <meta charset="utf-8"> between <head> and </head> somewhere? no need to close with a </meta> ? |
| 11:12 |
csharp |
@love kvm |
| 11:12 |
pinesol_green |
csharp: The operation succeeded. csharp loves kvm. |
| 11:16 |
* Dyrcona |
uses kvm + qemu. |
| 11:17 |
csharp |
I'm still kind of stuck on virtualbox for local desktop stuff (running windows VMs) because of not-so-awesome network bridging in NetworkManager |
| 11:17 |
csharp |
as soon as that's better, I'll switch completely |
| 11:19 |
csharp |
(last time I tested that was on F19 last summer - now on Ubuntu 13.10) |
| 11:20 |
dbs |
windows vms are the one thing I havent' been able to get working in kvm. but I don't want to taint my system with virtualbox kernel modules... so no windows vms for me. |
| 11:20 |
csharp |
dbs: understood |
| 11:20 |
csharp |
with the Linux staff client, I boot mine less and less frequently |
| 11:21 |
dbs |
(mostly from a "hate it when a kernel bug report gets created but not submitted because the tainted module") |
| 11:22 |
|
collum joined #evergreen |
| 11:25 |
|
dreuther joined #evergreen |
| 11:34 |
pinesol_green |
[evergreen|Jason Etheridge] LP#1279420 Add Test::Output prerequisite - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=0cbadcc> |
| 11:35 |
phasefx |
jeff++ |
| 11:58 |
csharp |
jeff++ phasefx++ |
| 11:58 |
csharp |
I didn't finish getting my dev servers built - is there still a need for me to test? |
| 12:04 |
|
ericar joined #evergreen |
| 12:08 |
|
snowcatt joined #evergreen |
| 12:08 |
|
frank__ joined #evergreen |
| 14:12 |
|
mcooper joined #evergreen |
| 14:23 |
|
eby joined #evergreen |
| 14:33 |
|
jihpringle joined #evergreen |
| 14:36 |
jeff |
so, Business::Stripe fails tests under perl 5.18 |
| 14:38 |
jeff |
there's a pull request to fix it, but it seems to have gone unnoticed. i'm going to try to get an alternative fix accepted, but if it isn't accepted and a new release added to CPAN, we might need to force the install for at least fedora. |
| 15:04 |
gmcharlt |
jeff: does it appaer that the maintainer is responsive at all? |
| 15:10 |
|
ericar joined #evergreen |
| 15:12 |
jeff |
Unclear. The repo for the distribution hasn't been updated in ~2y. The pull request is old, but it's also a bit messy. I'll know on the "responsive" or not in a few days. :-) |
| 12:47 |
bshum |
http://openkiosk.mozdevgroup.com/ |
| 12:47 |
bshum |
(oh they changed their website...) |
| 12:51 |
mmorgan |
Do slips print with either of those? |
| 12:52 |
bshum |
mmorgan: I... think it can. But I haven't tested it quite yet. |
| 12:54 |
mmorgan |
We've had trouble getting the slips to print with different kiosks, but we'll take a look at these. Thanks! |
| 12:57 |
|
krvmga joined #evergreen |
| 12:58 |
krvmga |
i've got a situation where one of the holds that a patron has placed is causing errors. in the staff client, looking at the patron's holds, there is one that is always "retrieving" and i can't see what it is. how can i get at that hold? |
| 13:18 |
bshum |
mmorgan: Oh you know... there was a bug for awhile in selfcheck |
| 13:18 |
bshum |
Where the receipts didn't print at all due to a javascript error |
| 13:19 |
bshum |
But I can't remember if that was ever resolved in more recent versions. Or if it only affected certain parts of the receipts. Like billings. |
| 13:20 |
mmorgan |
Do bugs work as sacrificial offerings? :) |
| 13:22 |
mmorgan |
I know a few kiosks have been tried and some printed but had other issues. We need to do some more testing, these suggestions will help. |
| 13:23 |
mmorgan |
dbs++ bshum++ Wyuli++ |
| 13:25 |
|
jwoodard joined #evergreen |
| 13:33 |
tsbere |
bshum: I think part of the problem with printing is "modern web browsers don't allow automatic printing, or interaction with printer settings in general, at all from web pages anymore" |
| 13:36 |
Wyuli |
mmorgan, tsbere: The Evergreen self-check module and I are not on real good terms. :\ There's a pretty slick open source self checkout packge that runs on PHP and is pretty slick. |
| 15:37 |
Wyuli |
jboyer-isl++ Thanks; I think that solves the mystery rather succinctly. :) |
| 15:38 |
berick |
dbwells++ # 2.6 beta summary |
| 15:48 |
|
senator joined #evergreen |
| 15:54 |
eeevil |
I think we have code attached to all the RC blockers now ... https://bugs.launchpad.net/evergreen/+bugs?field.tag=2.6-rc-blocker is looking for testers. IMO, the sooner we can get those big ones out of the way the sooner we can start sweeping up the smaller bugs ... so, here's a call for testing, folks! |
| 15:55 |
dbs |
eeevil++ |
| 15:56 |
dbwells |
eeevil++ |
| 16:01 |
gmcharlt |
eeevil++ |
| 16:52 |
|
kbeswick left #evergreen |
| 17:20 |
|
mmorgan left #evergreen |
| 17:25 |
|
dcook joined #evergreen |
| 17:26 |
* bshum |
twiddles his thumbs waiting for 0864 to run on his test server. (finish already!!) |
| 17:31 |
bshum |
And it dies. |
| 17:31 |
bshum |
Oy :( |
| 17:31 |
dbwells |
:( |
| 17:31 |
bshum |
Stupid reporter.classic_current_circ depends on rec_descriptor stuff |
| 17:31 |
bshum |
Guess that's a killer. |
| 17:52 |
bshum |
:) |
| 17:52 |
pinesol_green |
Launchpad bug 1287510 in Evergreen "2.5.2-2.5.3-upgrade-db.sql and ERROR: column "behind_desk" does not exist" (affected: 1, heat: 6) [Undecided,New] |
| 17:53 |
|
Callender_ joined #evergreen |
| 17:54 |
bshum |
Oh you know dbwells |
| 17:54 |
bshum |
This is a bad, bad test |
| 17:54 |
bshum |
I keep forgetting I'm using my Thinkpad with the SSD |
| 17:54 |
bshum |
So it's probably doing the job much faster than it does with our regular disk servers. |
| 17:54 |
bshum |
I'll let you know when I run it on the other machines. |
| 17:54 |
|
mrpeters left #evergreen |
| 17:56 |
dbwells |
Oh, I was really just curious if we were talking minutes, 10s of minutes, or hours. I am not too worried about it. |
| 17:56 |
bshum |
Well, on the Thinkpad with SSD, it was no more than just minutes then. |
| 18:07 |
bshum |
And that classic reporter issue |
| 18:07 |
bshum |
We'll figure out what to do about it sometime before release I guess :\ |
| 18:07 |
dbwells |
bshum++ # thanks, man |
| 18:08 |
bshum |
I'll finish whipping my test Evergreen frontend into shape and then see what things look like tomorrow. |
| 18:31 |
bshum |
@later tell berick When you have a chance, curious to get your opinion on this new bug https://bugs.launchpad.net/evergreen/+bug/1287973 |
| 18:31 |
pinesol_green |
bshum: The operation succeeded. |
| 18:31 |
pinesol_green |
Launchpad bug 1287973 in Evergreen "TPAC - CSS for advanced search filters" (affected: 1, heat: 6) [Undecided,New] |
| 18:31 |
bshum |
It's a tiny thing, but it irks me enough that I'd like to get to the bottom of it before 2.6 is "done" |
| 18:50 |
eeevil |
bshum: there definitely is. I plan to merge a squashed, rebased version of that branch tomorrow morning |
| 18:50 |
bshum |
eeevil: Ah, cool. I'll watch for it then. |
| 18:51 |
bshum |
And make sure that nobody clicks on that option in advanced search during tomorrow's demos :) |
| 18:51 |
eeevil |
:) |
| 18:52 |
eeevil |
I'm not certain that what you're seeing is covered, but I am certain that there are bug fixes and that it works on fresh and upgraded test instances 'round here |
| 18:52 |
eeevil |
(and that we don't see ... that) |
| 18:52 |
|
ericar joined #evergreen |
| 18:52 |
bshum |
I have to take a closer look at these icon_format things |
| 18:52 |
eeevil |
bshum: I assume you reingested (or, at least the attrs, if not the full records)? |
| 19:08 |
* bshum |
looks again |
| 19:08 |
eeevil |
well, as far as duplication is concerned... |
| 19:08 |
eeevil |
but I might have misunderstood you |
| 19:09 |
bshum |
It's alright, I often have trouble with my words. And this is the first time I've actually had time to try applying these things to a test system. |
| 19:14 |
eeevil |
you know ... we might need to add "AND all_orgs.flag" (and wrap the pair in parens) for the right hand side of the OR in those where clauses. (let me know if you're not following ... I'm not giving a ton of context, I know) |
| 19:14 |
bshum |
Oh I'm surely lost. But maybe that's a consequence of not going home to eat dinner. |
| 19:15 |
eeevil |
heh ... poke me tomorrow re evergreen.located_uris() and all_orgs.flag, I'll know what you mean ;) |
| 10:15 |
|
akilsdonk_ joined #evergreen |
| 10:15 |
|
mtcarlsoz joined #evergreen |
| 10:33 |
|
gmcharlt joined #evergreen |
| 10:36 |
jeff |
csharp: am i remembering correctly that you had a favorite tool for use on test/dev systems with regard to accepting all mail, but not relaying it on to its actual intended destination? |
| 10:36 |
jeff |
it might have been a specific configuration of sendmail/exim/postfix, or it might have been a special-purpose MTA. ring any bells? |
| 10:43 |
|
mrpeters joined #evergreen |
| 10:45 |
Dyrcona |
jeff: You could always setup an inetd entry on port 25 and redirect it to /dev/null. ;) |
| 10:46 |
Dyrcona |
That will "accept" all incoming mail and not send it on. |
| 10:46 |
jeff |
someone suggested nc -l > /dev/null :-) |
| 10:46 |
Dyrcona |
Yeah. |
| 10:46 |
Dyrcona |
It won't do SMTP, though, so the other end might get confused. |
| 10:46 |
tsbere_ |
jeff: I had, at one point, configured our mail server to accept all mail from our test systems but drop it into a local mailbox instead of the real destination(s) |
| 10:46 |
jeff |
i don't think that either option would -- right, exactly. |
| 10:47 |
jeff |
i might get some spam from old spambots, but not much else. :-) |
| 10:47 |
csharp |
jeff: one of our admins had set up postfix to send to a directory (not /dev/null :-), but a similar idea), and it was set up so we could connect an email client to it to see what was sent |
| 11:13 |
pinesol_green |
Launchpad bug 1272316 in Evergreen "much slower holds processing in 2.4+" (affected: 10, heat: 46) [High,Confirmed] |
| 11:14 |
eeevil |
kmlussier: absolutely |
| 11:14 |
kmlussier |
Great - thanks! |
| 11:14 |
eeevil |
I'm actually holding off cutting 2.4.next to give a couple folks a chance to test |
| 11:14 |
eeevil |
however, I'll probably not wait much longer, since csharp has confirmed its efficacy and was the OP on the bug |
| 11:15 |
eeevil |
IIRC |
| 11:15 |
eeevil |
yeah, he was |
| 11:15 |
kmlussier |
OK, good to know. I think we have a couple of people who are anxious to see it in production. |
| 11:18 |
eeevil |
kmlussier: IIRC, Dyrcona applied my SQL-ified, rebased version of depesz's ranked volumes patch (https://bugs.launchpad.net/evergreen/+bug/1234845) ... if you can confirm it's good for you, we could get that in soon, too. though that will probably not be 2.4 material (I'll have to look more closely) |
| 11:18 |
pinesol_green |
Launchpad bug 1234845 in Evergreen "possible optimization for evergreen.ranked_volumes database function" (affected: 2, heat: 12) [Medium,Triaged] |
| 11:18 |
eeevil |
kmlussier: applied to his test system, I mean |
| 11:19 |
Dyrcona |
Yep. |
| 11:19 |
kmlussier |
eeevil: I should have time to look at it today. |
| 11:19 |
* gmcharlt |
tosses OpenSRF bug https://bugs.launchpad.net/opensrf/+bug/1286198 out for consideration |
| 11:22 |
eeevil |
kmlussier: thanks |
| 11:23 |
eeevil |
kmlussier: re the other one ... the issues you found confuse me, and I haven't looked back at it in a couple weeks |
| 11:23 |
* eeevil |
tosses it on the pile |
| 11:25 |
kmlussier |
eeevil: When you have time to look at it, let me know. The examples I used are outdated because new items have been added to the database since I first reported it. I'm happy to redo my testing at a time when eyes are on it. |
| 11:25 |
eeevil |
thanks! |
| 11:25 |
eeevil |
I will ping you before I start |
| 11:29 |
Dyrcona |
gmcharlt: You have to change each bug independently of the others, unless you write a script. |
| 11:40 |
jeff |
Dyrcona: yup. looks like the same issue. |
| 11:41 |
gmcharlt |
heads up to those who run on OpenSRF master - I will be pushing lp1179660 at some point soonish |
| 11:41 |
gmcharlt |
bug 1179660 |
| 11:41 |
pinesol_green |
Launchpad bug 1179660 in OpenSRF "OpenSRF.pm AUTOLOAD complicates testing / serves little purpose" (affected: 1, heat: 6) [Medium,Triaged] https://launchpad.net/bugs/1179660 |
| 11:42 |
gmcharlt |
there is a decent chance that it will expose further AUTOLOAD dependers in the Evergreen codebase |
| 11:42 |
gmcharlt |
in fact, that's exactly why I want to push it |
| 11:43 |
Dyrcona |
gmcharlt: Good to know. I won't update my development environment for a few days, but when I do, I'll update OpenSRF, too. |
| 12:33 |
|
Shae_ joined #evergreen |
| 12:33 |
bshum |
eeevil: Oh I have it queued up in my master branch, but hadn't looked at the backports quite yet. |
| 12:34 |
eeevil |
bshum: if you sign off on the master/2.6 version, I'll do the heavy lifting for backport. FWIW, we've pushed it into a 2.4 instance already |
| 12:35 |
bshum |
eeevil: Yeah I wasn't too worried about the backport testing since I knew folks were on the case. |
| 12:35 |
bshum |
Give me two seconds |
| 12:36 |
eeevil |
bshum: I'll give you FOUR |
| 12:36 |
bshum |
Heh |
| 12:36 |
bshum |
I have to double check which upgrade number we're on |
| 15:00 |
jeff |
bah |
| 15:00 |
|
DPearl joined #evergreen |
| 15:23 |
jboyer-isl |
Is there some trick I'm missing with respect to rsyslog and eg-stats-collector? I followed the instructions here: http://git.evergreen-ils.org/?p=contrib/equinox.git;a=blob;f=monitoring/eg-stats/README and my logging machine is just dumping all kinds of stuff in the egstats file. |
| 15:29 |
kmlussier |
I'm looking at the new ranked volumes function on Dyrcona's server. It looks good, but then I got distracted by the shiny new "Group Formats and Editions" checkbox. |
| 15:30 |
kmlussier |
But I can't get it to work correctly on any search I try. When I click on a title to see the grouped records, I always get 0 results. |
| 15:30 |
kmlussier |
Is it possible the ranked volumes branch I'm testing affects it? I don't see any other dev branches on Jason's server that should affect the search results page. |
| 15:33 |
berick |
kmlussier: can't say for sure, but i would recommend merging https://bugs.launchpad.net/evergreen/+bug/1284864 before testing MR stuff. lots of fixes in there. |
| 15:33 |
pinesol_green |
Launchpad bug 1284864 in Evergreen "TPAC metarecord / formats repairs and usability additions" (affected: 1, heat: 6) [Undecided,New] - Assigned to Bill Erickson (erickson-esilibrary) |
| 15:37 |
|
dreuther joined #evergreen |
| 15:37 |
kmlussier |
I was just looking at those, but didn't see this particular problem being noted. |
| 17:04 |
|
DPearl1 joined #evergreen |
| 17:05 |
Bmagic |
Honestly, I am totally confused about Encode.pm |
| 17:05 |
Bmagic |
I think that I have struggled with this for years now |
| 17:08 |
Bmagic |
I have written code to test the string for utf8 and wide characters ahead of time and then encode/decode depending. I have liftedcode from EG and sometimes messing with some other modules. It's all inconsistant and I have given up trying to figure this out but it keeps coming back and biting me |
| 17:11 |
|
23LAAEWVZ joined #evergreen |
| 17:11 |
Bmagic |
I would love a second set of eyes on this http://pastebin.com/e7D1s6Ys |
| 17:12 |
Bmagic |
specifially sub query{} |
| 02:16 |
bshum |
Yeah, error is gone. Nevermind, all is well after all. |
| 02:50 |
|
gmcharlt joined #evergreen |
| 07:35 |
|
rjackson-isl joined #evergreen |
| 07:54 |
csharp |
bshum++ # testing through the night |
| 08:07 |
|
remingtron joined #evergreen |
| 08:08 |
|
akilsdonk joined #evergreen |
| 08:13 |
|
kbeswick joined #evergreen |
| 08:26 |
|
kmlussier joined #evergreen |
| 08:28 |
kmlussier |
A question for csharp, bshum, and/or eeevil regarding the fix for https://bugs.launchpad.net/evergreen/+bug/1272316/ |
| 08:28 |
pinesol_green |
Launchpad bug 1272316 in Evergreen "much slower holds processing in 2.4+" (affected: 10, heat: 46) [High,Confirmed] |
| 08:29 |
kmlussier |
It looks like most of the testing involved holds placement. Are you also seeing improvement for retargeting holds at checkin? Or is this fix specifically for the "place holds" issue? |
| 08:29 |
|
Shae joined #evergreen |
| 08:30 |
csharp |
kmlussier: we were not aware of a problem at checkin in PINES, so I haven't investigated that |
| 08:33 |
csharp |
I'm investigating why our users are able to edit their own accounts in Evergreen 2.5.1 - I'm not sure that this wasn't going on before that... In any case, I'm looking closely at Open-ILS/xul/staff_client/server/patron/user_edit.js for clues |
| 08:34 |
csharp |
kmlussier: let me check that and get back to you |
| 08:34 |
kmlussier |
csharp++ Thanks! |
| 08:49 |
|
timlaptop joined #evergreen |
| 09:07 |
csharp |
kmlussier: from my testing, I can see the hold targeter churning through far faster than before |
| 09:07 |
csharp |
before the messages would hang, then move, then hang then move |
| 09:08 |
csharp |
now they're moving pretty fast |
| 09:08 |
|
tsbere_ joined #evergreen |
| 09:10 |
csharp |
on a related note, has anyone implemented a "delete holds and notify the patron when all eligible copies are in a non-holdable status" feature? |
| 09:10 |
csharp |
I'm assuming A/T could handle that |
| 09:10 |
csharp |
s/eligible/previously eligible/ |
| 09:12 |
jeff |
We don't currently have anything like that, and I'd be a bit hesitant to introduce it without at least a timeout interval, during which reporting could give staff the opportunity to intervene. |
| 09:13 |
jeff |
But it would also probably be important to have a means to selectively suspend the pending cancellation process, and I'm not sure what form that should take. |
| 09:14 |
csharp |
jeff: good points |
| 09:14 |
tsbere |
csharp/jeff: We have a "these holds can't be filled" report that staff poke through every so often (I hope) |
| 09:14 |
csharp |
tsbere: yeah that may be a better approach |
| 09:15 |
jeff |
similar here. they show up on our standard holds ratio report with a ratio of infinity. :-) |
| 09:16 |
bshum |
kmlussier: Agreed with csharp that hold_targeter churn does seem faster than before. |
| 09:16 |
bshum |
As far as checkin, that's trickiwr |
| 09:16 |
bshum |
*trickier for me to test right now. |
| 09:17 |
bshum |
But I'm sure it'll come up soon. |
| 09:20 |
csharp |
bshum: are you running the patches in production? |
| 09:21 |
bshum |
csharp: Maybe .... :) |
| 09:24 |
csharp |
heh |
| 16:07 |
jeff |
which isn't the longest value, but it is the largest value shared by more than one record. |
| 16:10 |
|
Claudia_Love joined #evergreen |
| 17:02 |
|
gsams joined #evergreen |
| 17:03 |
bshum |
Oops |
| 17:03 |
bshum |
Looks like Elliot is burned on osrf_control because he's not using the OpenSRF 2.3 beta |
| 17:03 |
bshum |
In conjunction with testing for Evergreen 2.6 beta1 |
| 17:04 |
bshum |
gmcharlt: Was 2.3 cut after the last dev meeting? |
| 17:04 |
bshum |
*OpenSRF 2.3 |
| 17:05 |
gmcharlt |
no, I'll get on that now |
| 17:05 |
bshum |
I'll do some explanation for the discussion on the lists. |
| 17:05 |
bshum |
Thanks gmcharlt |
| 18:41 |
|
ktomita_ joined #evergreen |
| 18:44 |
|
ningalls1 joined #evergreen |
| 18:53 |
|
ktomita joined #evergreen |
| 18:53 |
jeffdavis |
we've got a 2.6beta1 test server up and running, will start proper testing tomorrow |
| 19:37 |
|
dac joined #evergreen |
| 19:42 |
|
jeff joined #evergreen |
| 19:42 |
|
b_bonner_ joined #evergreen |
| 08:48 |
bshum |
Oh no, I'm just trying to hang together some data for a library that's joining us and going live today. |
| 08:48 |
bshum |
First new lib in a couple years. Too rusty :) |
| 08:51 |
dbs |
Are they getting libinfo pages yet? :) |
| 08:52 |
bshum |
dbs: Heh, unfortunately not. I have to spend more time teasing out what else is new alongside all of that to make sure it doesn't break stuff for production. |
| 08:53 |
bshum |
That said, I did trial run libinfo on my test server. I think the only thing I want to tweak locally for us is how the mailing address gets displayed and maybe removing the parent links (most of it doesn't help the single branch systems) |
| 08:56 |
jeff |
in the case of the parent links, would you see benefit to removing the human-visible links but leave the microdata? |
| 08:56 |
dbs |
a) There's no microdata, it's RDFa </pedant> |
| 08:56 |
dbs |
b) Probably not, as the search engines get suspicious when they're fed info that humans don't see. |
| 11:43 |
csharp |
ah - I see |
| 11:46 |
|
jihpringle joined #evergreen |
| 11:47 |
Dyrcona |
I was just looking to see if I could find it at paste.evergreen-ils.org, but gave up. :) |
| 11:49 |
csharp |
well, I'm now running the CREATE INDEX commands on my test db to time them |
| 11:49 |
Dyrcona |
Cool. |
| 11:49 |
csharp |
I don't see much in the code though that actually references the normalize_heading functions |
| 11:49 |
csharp |
which must be why we haven't noticed ;-) |
| 12:26 |
csharp |
eeevil: I'll take a look at your hold proximity patches |
| 12:26 |
csharp |
(for bug 1272316, for context) |
| 12:26 |
pinesol_green |
Launchpad bug 1272316 in Evergreen "much slower holds processing in 2.4+" (affected: 9, heat: 38) [High,Confirmed] https://launchpad.net/bugs/1272316 |
| 12:27 |
eeevil |
csharp: great. I'm getting that in place in another large test system... MORE DATA POINTS! |
| 12:27 |
csharp |
excellent |
| 12:28 |
eeevil |
jeff: bah! (restore) ... I have a feeling things are getting worse, not better, with more modern pg_restore binaries |
| 12:30 |
jeff |
eeevil: all the more reason to move toward explicit qualification. of course, then there's potential for different search paths over time to have resulted in conflicting (or at least duplicate) functions in a live evergreen database, which might not be an issue until explicit schema qualification comes along... |
| 12:44 |
csharp |
a library had forgiven them before I went through and voided them (with the intention of catching ones they had missed) |
| 12:44 |
mmorgan |
csharp: I think that's true with all of us :) |
| 12:44 |
csharp |
they said "void" but meant "forgive" |
| 12:44 |
jeff |
mmorgan: in our most common workflows, no. we're running code that handles auto-forgive of overdues on Lost, re-billing of forgiven overdues on later checkin of a Lost item, etc. It's a working branch attached to a bug that was made (mostly, at least) superfluous by the conditional negative balances work. |
| 12:46 |
jeff |
My hope would be to test and ensure that the conditional negative balance work does indeed make our Forgive-not-Void work obsolete. |
| 12:48 |
mmorgan |
Ah, so you have been circumventing the built in Evergreen behavior for a while. |
| 12:49 |
jeff |
when it comes to lost item handling, yes. we'd like to bring things back into the fold, since other efforts with slightly differing requirements came along. I believe some of the code from our working branch became part of the conditional negative balances branch. |
| 12:50 |
|
Dyrcona1 joined #evergreen |
| 13:17 |
mrpeters |
no problem! |
| 13:17 |
mrpeters |
ls |
| 13:18 |
|
dbwells joined #evergreen |
| 13:19 |
mceraso |
dbwells: Just tested the 2.5.3 release candidate using Ubuntu 12.04 LTS with great success |
| 13:19 |
|
Sato`kun joined #evergreen |
| 13:20 |
jeff |
prediction didn't come true: echo -n '/me waits for the typographers to come along and point out his mis-use of "hyphen"' | md5sum |
| 13:20 |
dbwells |
mceraso++ # thanks! |
| 13:20 |
mceraso |
On to testing 2.6 beta now... |
| 13:20 |
bshum |
mceraso++ |
| 13:21 |
mrpeters |
i said "ls" dammit! |
| 13:21 |
mrpeters |
haha |
| 13:26 |
|
Bmagic joined #evergreen |
| 13:33 |
csharp |
eeevil: wow - that patch dropped processing time from 24 seconds to 6 seconds for a bib with 224 items attached |
| 13:34 |
bshum |
Fancy! |
| 13:34 |
csharp |
it was the test item I sent you the logs for |
| 13:34 |
csharp |
gonna test some more examples I've gotten |
| 13:34 |
eeevil |
csharp: great. can you confirm that the output is exactly as you expect? action.hold_copy_map contents, action.hold_request for that one, etc? |
| 13:35 |
kmlussier |
csharp: That's awesome! |
| 13:35 |
eeevil |
csharp: and that's on top of senator's previous patch, yes? |
| 13:35 |
csharp |
eeevil: correct |
| 13:35 |
eeevil |
csharp: related: how long did it take to run the proximity pre-calc update in the upgrade script? (aprox) |
| 13:36 |
eeevil |
(approximately, I mean) |
| 13:36 |
csharp |
well... wait - I may be mixing up my test environments |
| 13:36 |
eeevil |
heh |
| 13:36 |
csharp |
it ran for about 20-25 mins, I think |
| 13:36 |
eeevil |
ok. that's not too bad |
| 13:38 |
* csharp |
may release bradl's tux doll on the day we retire those good old DL580G5s |
| 13:41 |
|
snowkitteh__ joined #evergreen |
| 13:42 |
bshum |
FREEDOM! |
| 13:47 |
csharp |
eeevil: yes, I can confirm that senator's patches are included |
| 13:55 |
csharp |
yeah - definite improvements - a hold that took 65 seconds in production takes 14 seconds on my test server |
| 13:56 |
csharp |
still a long time, www-wise, but way better |
| 13:57 |
eeevil |
csharp: you don't happen to have pre-2.5 timings for an equiv hold, do you? |
| 13:58 |
csharp |
eeevil: unfortunately not |
| 13:59 |
eeevil |
I'd honestly be very surprised if a 600+ copy hold was ever faster than the post-patch version |
| 14:03 |
eeevil |
csharp: I HAVE NO IDEA WHAT YOU ARE TALKING ABOUT |
| 14:04 |
eeevil |
csharp / bshum: pushing a rebased version of that with senator's commits embedded below mine in a moment |
| 14:04 |
csharp |
eeevil++ |
| 14:04 |
bshum |
eeevil: Cool, I'm testing out the differences between our test system (with senator's stuff + yours now) vs. production |
| 14:06 |
bshum |
10 seconds in test, ~28 in production |
| 14:06 |
bshum |
For one of the sample bibs giving some grief |
| 14:07 |
eeevil |
http://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/collab/miker/prox-calc-speedup_plus_aouas-speedup_rebased FTR |
| 14:09 |
csharp |
bshum: nice |
| 14:13 |
|
stevenyvr joined #evergreen |
| 14:23 |
|
kbutler joined #evergreen |
| 14:27 |
|
jboyer-dc joined #evergreen |
| 14:32 |
mceraso |
dbwells: Tested 2.6 Beta Preview using Ubuntu 12.04 LTS. Works just fine! |
| 14:33 |
dbwells |
mceraso++ # thanks again! |
| 15:17 |
|
floadam joined #evergreen |
| 15:42 |
bshum |
csharp: You didn't add it to the bug, but I assume your signoff branch is official? |
| 10:06 |
Dyrcona |
jl-: The code is in Open-IlS/src/perlmod/lib/OpenILS/Utils/Normalize.pm if you want to look at it. |
| 10:07 |
dbs |
ergo easiest method might be to roll back to MARC binary via yaz-marcdump and just use that little bit of python |
| 10:07 |
jl- |
hmm |
| 10:07 |
jeff |
a well reasoned and tested "what to do if your data is already in marcxml format, but not one-record-per-line" (and that might be use yaz-marcdump to go marcxml to MARC) would probably be a useful addition to http://docs.evergreen-ils.org/dev/_migrating_your_bibliographic_records.html |
| 10:07 |
Dyrcona |
No. Write a little something with MARC::Batch. |
| 10:08 |
jl- |
dbs so roll back to .mrc |
| 10:08 |
yboston |
jeff++ |
| 10:19 |
jeff |
every phone call for a patron password reset that i handle is another reminder to get moving on bug 1264746 |
| 10:19 |
pinesol_green |
jeff: Error: Could not gather data from Launchpad for bug #1264746 (https://launchpad.net/bugs/1264746). The error has been logged |
| 10:20 |
jeff |
huh. well, that's ``Add "email password reset" button to user editor'' |
| 10:25 |
berick |
if anyone wants to help me quickly fix this : http://testing.evergreen-ils.org/~live/test.20.html |
| 10:25 |
berick |
see working/user/berick/pgtap-db-debs-check-sort-repair |
| 10:27 |
jeff |
but after that is "phone rings, web browser brings up list of matching patrons in web staff client, options for usual things including triggering a suggested username and triggering an e-mailed password reset" :-) |
| 10:27 |
* jeff |
looks at berick's url |
| 10:28 |
jl- |
ergreen=# SELECT staging_importer(); |
| 10:29 |
jl- |
yes that's what it said |
| 10:29 |
jl- |
sorry for the spam |
| 10:30 |
jeff |
berick: quick fix looks good (i have not run it through pgtap). any opinion on whether evergreen.upgrade_list_applied_deprecates should be updated to return sorted values itself? |
| 10:32 |
berick |
jeff: thought about that, but couldn't think of a case where it mattered outside of the test |
| 10:33 |
eeevil |
jeff / berick: and order may be important (but, of course, that's available from config.upgrade_log, I suppose) |
| 10:40 |
|
_bott_ joined #evergreen |
| 10:43 |
berick |
eeevil: as in, the order of entries in supersedes[] or deprecates[] may be important, so evergreen.upgrade_list_applied_deprecates (etc) should not apply asciibetical sorting of patches it returns? |
| 10:46 |
berick |
no, seemed like a waste of pixels |
| 10:46 |
berick |
original bug |
| 10:47 |
berick |
https://bugs.launchpad.net/evergreen/+bug/1262722 |
| 10:47 |
pinesol_green |
Launchpad bug 1262722 in Evergreen "DB patch supersede / deprecate func repairs; unit test" (affected: 1, heat: 6) [Undecided,Fix committed] |
| 10:47 |
* jeff |
waits for new two-factor token |
| 10:49 |
senator |
paxed: congratulations to your national hockey team (if you're into that sort of thing) |
| 10:49 |
paxed |
senator: i'm not really into hockey, but it's always nice to beat russia... :P |
| 11:05 |
eeevil |
mrpeters: I'd suggest looking at the schema, make sure all the indexes supporting autosuggest (which also support browse) are in place. you can configure autosuggest to not kick in until you have more than a certain number of characters from the user, IIRC |
| 11:05 |
mrpeters |
eeevil: thanks, great info. i hope autosuggest really is the culprit! |
| 11:05 |
paxed |
jl-: it just uses as much space as you've got available. |
| 11:07 |
eeevil |
mrpeters: and, short of disabling autosuggest, you can just disable visibility testing for autosuggest. I'd point you to the docs that, but the community docs sites seems broken at the moment... |
| 11:08 |
mrpeters |
no i know how, thanks mike |
| 11:10 |
mrpeters |
keyword searches are just bunk....title/author/etc. come back snappy....any particular index that might be corrupt/missing/etc. |
| 11:10 |
|
jboyer-laptaupe joined #evergreen |
| 11:19 |
mrpeters |
im wondering if the autosuggest stuff, and the process sniping deal WAS the tipping point |
| 11:24 |
|
mcooper joined #evergreen |
| 11:27 |
|
mmorgan left #evergreen |
| 11:28 |
jeff |
berick: tested your fix, pushed to master, commented in bug 1262722 |
| 11:28 |
pinesol_green |
Launchpad bug 1262722 in Evergreen "DB patch supersede / deprecate func repairs; unit test" (affected: 1, heat: 6) [Undecided,Fix committed] https://launchpad.net/bugs/1262722 |
| 11:28 |
jeff |
berick++ |
| 11:28 |
jeff |
tests++ |
| 11:29 |
berick |
jeff++ |
| 11:30 |
pinesol_green |
[evergreen|Bill Erickson] LP#1262722 Fix DB supersedes/deprecates pgtap test - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=6c16a44> |
| 11:44 |
phasefx |
if we can get this one too, then we'll have a clean QA test run: https://bugs.launchpad.net/evergreen/+bug/1279420 |
| 11:44 |
pinesol_green |
Launchpad bug 1279420 in Evergreen "need Test::Output prerequisite" (affected: 1, heat: 6) [Medium,Triaged] |
| 11:46 |
|
jwoodard joined #evergreen |
| 11:46 |
jeff |
heh. i was just testing the waters in preparation for arguing for that. :-) |
| 11:46 |
jeff |
phasefx: that system currently builds once nightly, around midnight? |
| 11:46 |
phasefx |
correct, though I can fire it off practically at will over here |
| 11:48 |
phasefx |
in #openils-evergreen, pinesol_green is following an RSS feed for it |
| 11:48 |
* dbs |
fears what adding a thin plperl wrapper around xml::libxslt is going to do to ingest times |
| 11:57 |
jl- |
mrpeters bibs |
| 12:02 |
mrpeters |
how many patrons do you plan to load? |
| 12:02 |
mrpeters |
is 80GB feasible for you? i'm thinking about circulation, auditor, etc. buildup over time as well |
| 12:02 |
jl- |
possibly |
| 12:03 |
jl- |
testing on a VM right now |
| 12:03 |
jl- |
gonna try 60 |
| 12:03 |
mrpeters |
ah, i see |
| 12:03 |
mrpeters |
just don't run your production DB in a VM, right eeevil ;) |
| 12:03 |
mrpeters |
i think we've all seen the pain that can cause |
| 14:39 |
pinesol_green |
[evergreen|Ben Shum] LP1223903 - Stamping upgrade script for new authority_record_entry indexes - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=c0a0fc6> |
| 14:41 |
pinesol_green |
[evergreen|Ben Shum] LP1223903 - Also bump the schema config - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=c0c1061> |
| 14:57 |
|
smyers_ joined #evergreen |
| 14:59 |
eeevil |
Dyrcona: since you've been testing http://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/dyrcona/lp1234845_ranked_volumes would you mind taking a look at the SQL version in http://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/collab/miker/lp1234845_ranked_volumes ? |
| 14:59 |
* eeevil |
updates the LP bug too |
| 14:59 |
Dyrcona |
No problem. I'll load it in a few. |
| 15:00 |
Dyrcona |
It has mostly been kmlussier looking at it and she's on vacation at the moment. |
| 15:00 |
eeevil |
Dyrcona: might need to re-drop the intermediate one by hand on your test server, just a head's up |
| 15:00 |
eeevil |
thanks! |
| 15:00 |
Dyrcona |
ok |
| 15:01 |
rangi |
Dyrcona: when you get a chance (non urgent) you might like to do a pull of the ncip stuff too |
| 15:01 |
Dyrcona |
rangi: Cool. |
| 16:20 |
jeffdavis |
jl-: how many MARC records are you importing? |
| 16:22 |
jl- |
jeff 230,000 |
| 16:23 |
jl- |
jeffdavis |
| 16:26 |
jeffdavis |
hm |
| 16:27 |
|
jboyer_laptaupe joined #evergreen |
| 16:27 |
jeffdavis |
I've got a test dataset with about 278,000 bib records, total size of the database after ingest is 10 GB |
| 16:27 |
|
smyers__ joined #evergreen |
| 16:27 |
jl- |
something's fishy then |
| 16:27 |
jl- |
well |
| 16:27 |
jl- |
after ingest |
| 16:27 |
jl- |
but during? |
| 16:28 |
jeffdavis |
not sure |
| 16:28 |
jl- |
btw these are not 'test datasets' |
| 16:28 |
jeffdavis |
I tried the staging_importer method that was discussed here recently and it didn't work for me, I ended up killing it after about 4 days and using a slightly different approach |
| 16:28 |
jl- |
this is real data |
| 16:28 |
jl- |
from a real university |
| 17:19 |
|
mmorgan left #evergreen |
| 17:36 |
|
dcook joined #evergreen |
| 17:37 |
|
smyers_ joined #evergreen |
| 17:43 |
jeff |
hrm. search errors in the logs on one of my test systems. will investigate further tonight. |
| 17:44 |
jeff |
pgtap being present shouldn't break searches, should it? |
| 17:44 |
jeff |
seems unlikely. |
| 17:47 |
jeff |
oh. i believe i have a disconnect between my database and my services. all is broken as expected. :-) |
| 19:13 |
|
nap joined #evergreen |
| 19:14 |
|
nap left #evergreen |
| 19:47 |
|
nap joined #evergreen |
library.in.gov>, Lebbeous Fogle-Weekley <lebbeous