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 |
07:57 |
|
Dyrcona joined #evergreen |
08:00 |
|
collum joined #evergreen |
08:28 |
|
mrpeters joined #evergreen |
08:35 |
Dyrcona |
Here we go: Testing a void_all_bills fix in the billing branch. |
08:38 |
|
Shae joined #evergreen |
08:39 |
mrpeters |
morning all -- trying to load some bib record SQL generated by paralell_pg_loader.pl and getting this error -- http://pastie.org/8755529 -- not sure which file's "line 31" it's balking at... |
08:45 |
|
mmorgan1 joined #evergreen |
09:35 |
|
jwoodard joined #evergreen |
09:38 |
Dyrcona |
dbwells and to anyone who cares: I've resolved the void_all_bills issue AFAICT, I've pushed some fixes to the collab branch. |
09:38 |
Dyrcona |
Be warned that I rebased it last night to resolve a conflict with master when a collections function was removed. |
09:39 |
phasefx |
qa tests were angrier this morning than usual: http://testing.evergreen-ils.org/~live/test.html Need to add a hueristic for the db init section: http://testing.evergreen-ils.org/~live/test.17.html syntax error |
09:39 |
phasefx |
this is with the stripe code |
09:42 |
|
adbowling-isl joined #evergreen |
09:44 |
remingtron |
phasefx: I'll push a fixed version to my signoff branch |
09:44 |
dbs |
hmm. shouldn't that be caught if you run "eg_db_config.pl --create-schema --create-database" (with an optional "| grep ERROR") before committing? |
09:45 |
remingtron |
dbs: yes, but I sadly neglected the fresh db install from the branch, only did the upgrade script on a master db |
09:45 |
* remingtron |
is learning his lesson |
09:45 |
dbs |
remingtron: we all have much to learn, don't worry! |
09:46 |
phasefx |
learning++ tests++ |
10:00 |
pinesol_green |
[evergreen|Remington Steed] Fix syntax error in seed data - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=0bb4915> |
10:08 |
|
dluch joined #evergreen |
10:10 |
* mrpeters |
attempts loading the records in 10k chunks (split FTW) to see if i can narrow it down any |
16:21 |
eeevil |
dbwells: however, even discounting the left join itself, I don't think we should include ts_map entries when the mravl.id is null ... |
16:29 |
eeevil |
netsplit... again |
16:31 |
|
Callender joined #evergreen |
16:44 |
egbuilder |
build #538 of evergreen-master-ubuntu-12.04-x86 is complete: Failure [failed test] Build details are at http://testing.evergreen-ils.org/buildbot/builders/evergreen-master-ubuntu-12.04-x86/builds/538 blamelist: Jason Boyer <JBoyer1library.in.gov>, Lebbeous Fogle-Weekley <lebbeousesilibrary.com>, Dan Wells <dbw2calvin.edu> |
16:44 |
egbuilder |
build #532 of evergreen-master-debian-6.00-x86_64 is complete: Failure [failed test] Build details are at http://testing.evergreen-ils.org/buildbot/builders/evergreen-master-debian-6.00-x86_64/builds/532 blamelist: Jason Boyer <JBoyer1library.in.gov>, Lebbeous Fogle-Weekley <lebbeousesilibrary.com>, Dan Wells <dbw2calvin.edu> |
16:45 |
egbuilder |
build #506 of evergreen-master-fedora-18 is complete: Failure [failed test] Build details are at http://testing.evergreen-ils.org/buildbot/builders/evergreen-master-fedora-18/builds/506 blamelist: Jason Boyer <JBoyer1library.in.gov>, Lebbeous Fogle-Weekley <lebbeousesilibrary.com>, Dan Wells <dbw2calvin.edu> |
16:47 |
|
jeffdavis left #evergreen |
17:06 |
|
theofilos__ joined #evergreen |
17:06 |
|
jeffdavis joined #evergreen |
19:16 |
Dyrcona |
I should say, add them back as virtual fields.... |
19:19 |
sseng |
Actually, could the hold count be off? For example, since it is by copy id, and the hold count only cares about fulfillment_time and cancel_time being null, and if a copy's status change to deleted, the hold count would still consider the hold on the copy as active and count it? |
19:21 |
Dyrcona |
sseng: It might. I'd have to look at the code for that. I haven't spent a lot of time working with holds. |
19:22 |
sseng |
Dyrcona: ok, going to test out this situation. thanks! |
19:23 |
Dyrcona |
np |
19:24 |
Dyrcona |
Hmm... Now, I wonder if I can add all those fields as virtual fields. |
19:44 |
|
fparks joined #evergreen |
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 |
09:07 |
berick |
this ticket wins the "first time make livcheck found a bug" award (for me) |
09:08 |
berick |
ironically, the code in question will almost certainly be replaced by direct pcrud calls in the future (if it hasn't already). |
09:09 |
dbs |
"make liver-check" might be useful during the conference |
09:10 |
jeff |
berick++ |
09:10 |
jeff |
tests++ |
09:10 |
dbs |
Do we have a documented set of tests / make targets to run for development & signoff? |
09:10 |
dbs |
make check && make livecheck? |
09:10 |
berick |
dbs: why look for something you don't want to find? |
09:11 |
* dbs |
can add that to http://wiki.evergreen-ils.org/doku.php?id=dev:signoff_review_checklist |
09:11 |
berick |
that was in response to liver-check, not signoff tests |
09:11 |
berick |
dbs++ |
09:11 |
berick |
jeff++ |
09:13 |
dbs |
added. not sure if anyone is actually looking at the review signoff list but occasionally people find the wiki :) |
09:14 |
jeff |
speaking of make check, does everyone else get a handful of warnings in metabib.pm? I dug just enough to see that the fix is probably simple and probably-simple (two different warnings, but one repeated several times), and confirmed that they weren't introduced by anything i was signing off on, but did not open a bug. |
09:15 |
berick |
jeff: yes, i get the warnings. |
09:15 |
* berick |
will gladly sign off if a fix is pushed |
09:15 |
jeff |
that checklist would have helped the other day when i forgot to bump the upgrade id in 002.schema.config.sql |
09:23 |
|
mrpeters joined #evergreen |
09:37 |
|
RoganH joined #evergreen |
09:42 |
|
yboston joined #evergreen |
09:49 |
jeff |
oh, i should start services before running make livecheck :P |
09:51 |
jeff |
and have the expected admin password... |
09:51 |
jeff |
i believe i've only run these from the uberscript |
10:04 |
jeff |
berick++ tests clean, pushed to master! |
10:05 |
pinesol_green |
[evergreen|Jeff Godin] LP#1187035 Remove OpenILS::Utils::Editor - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=0199ecd> |
10:05 |
pinesol_green |
[evergreen|Bill Erickson] LP#1187035 Remove OpenILS::Utils::Editor part 2. - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=bb222e7> |
10:05 |
pinesol_green |
[evergreen|Jeff Godin] LP#1187035 Remove OpenILS::Utils::Editor part 3. - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=8eda1c2> |
10:16 |
krvmga |
i am not able to duplicate the problem with ietester |
10:18 |
berick |
wonder if it's the same as bug 1002971 |
10:18 |
pinesol_green |
Launchpad bug 1002971 in Evergreen "tpac: library names are cut off in library selector when using IE" (affected: 2, heat: 10) [Medium,Confirmed] https://launchpad.net/bugs/1002971 |
10:19 |
bshum |
berick: Well that bug notes that it doesn't affect IE9 in my testing. |
10:20 |
berick |
ah |
10:20 |
bshum |
My first kneejerk reaction for krvmga is to check that one of your bricks isn't malfunctioning with a bad dropdown. |
10:22 |
bshum |
krvmga: Also, for those of us who don't follow religiously, it helps to know what version of Evergreen you're on :) |
12:55 |
fparks_ |
eeevil: I do see the fr-CA locale poping up in other parts of the log |
12:56 |
* eeevil |
grabs 0860 |
12:56 |
paxed |
fun for the whole consortium! |
13:02 |
pinesol_green |
[evergreen|Bill Erickson] DB patch supersede/deprecate logic repairs; unit tests - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=b7f0b1d> |
13:02 |
pinesol_green |
[evergreen|Mike Rylander] Stamping upgrade script for supsersede/deprecate logic fixes - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=4be7952> |
13:04 |
jeff |
29 fix committed |
13:05 |
eeevil |
fparks_: without seeing the code that's failing, I couldn't say why it's not picking up the in-use locale while other parts of the system seem to be, based on what you say about the logs |
13:10 |
eeevil |
I'd like to get more eyes on this chunk of plpgsql, because either I'm misunderstanding it, or it's doint the wrong thing: |
15:01 |
eeevil |
+1 # march is still a ways of! ;) |
15:10 |
jeff |
+1 to extension |
15:21 |
berick |
crazy. just hit 60 degrees and there's still a large patch of (thin) snow outside the window. |
15:23 |
jeff |
i think i just confused the conditional negative balance branch by violating its assumptions. |
15:24 |
jeff |
checked something out, set its due date back a ways, ran fine generator, made some payments, did a backdated checkin. |
15:24 |
jeff |
i suppose that's an unfair test, and i think our local branches have suffered similar fates before. |
15:25 |
jeff |
but this brings up a good question: what is a recommended method of testing overdues -- manually create the checkout many days ago? |
15:25 |
* jeff |
goes to see what make livecheck does |
15:25 |
berick |
jeff: the seed data has some overdues in it |
15:25 |
jeff |
my usual trick is the above, check out and then set a due date in the past (which means it becomes due before checkout), then run fine generator. it works for many things until it doesn't. :-) |
15:27 |
jeff |
okay, livecheck rewrites history with open-ils.cstore.direct.action.circulation.update |
15:27 |
jeff |
still "cheating" (what tests aren't?) but results are cleaner. |
15:46 |
|
stevenyvr joined #evergreen |
15:59 |
|
Dyrcona joined #evergreen |
16:11 |
|
dMiller_ joined #evergreen |
16:59 |
Dyrcona |
Yeah, you could say that the ILS market is actually a functioning, competitive market. |
17:00 |
eeevil |
dbwells / berick: please see the top of http://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/collab/miker/lp1053397-tpac-metarecords-r5 |
17:01 |
* berick |
takes a look |
17:02 |
eeevil |
berick: to see it in action, your test server has it in place already |
17:02 |
jcamins |
Dyrcona: let's not go overboard. Have you seen some of the ILSes out there? :P |
17:02 |
eeevil |
evergreen=# select metabib.reingest_record_attributes(id,'{icon_format}'::TEXT[],marc,false) from biblio.record_entry where id > 0 and not deleted; |
17:02 |
eeevil |
Time: 477.551 ms |
17:03 |
berick |
eeevil: thanks. i'll install on a new DB though, to test the baseline as well |
17:03 |
eeevil |
berick: fair :) |
17:03 |
Dyrcona |
jcamins: Yes, they all suck, some just suck less. :) |
17:04 |
pastebot |
"berick" at 64.57.241.14 pasted "for eeevil :)" (17 lines) at http://paste.evergreen-ils.org/22 |
17:05 |
eeevil |
well that's fun |
17:05 |
eeevil |
I wonder why it works on the test db... |
17:09 |
eeevil |
berick: pushing the fix... just RETURN NULL; |
17:09 |
berick |
ah |
17:09 |
eeevil |
pushed |
17:10 |
eeevil |
well |
17:10 |
eeevil |
ing |
17:10 |
eeevil |
pushd |
17:10 |
berick |
thanks, running again |
17:11 |
|
mmorgan left #evergreen |
17:18 |
berick |
works well. memory looks good. full re-ingest still takes longer (but i'd be shocked if it didn't). |
17:18 |
berick |
though speed is considerably improved |
17:19 |
berick |
master = 17 seconds; old MR branch = 50 seconds; new MR branch = 30 seconds. |
17:19 |
berick |
on my test vm |
17:19 |
eeevil |
ah, I should have said that full attr reingest (all we need for the upgrade to this) only takes 10s |
17:19 |
eeevil |
not full marc dance |
17:20 |
berick |
that's what I thought you meant |
19:14 |
bshum |
That all said... there is work underway to make things faster overall. |
19:14 |
bshum |
One of the branches I've assigned to myself and plan to push shortly for 2.6 beta is https://bugs.launchpad.net/evergreen/+bug/1223903 |
19:14 |
pinesol_green |
Launchpad bug 1223903 in Evergreen "marc_export with --items is too damned slow and other things" (affected: 2, heat: 10) [Wishlist,Confirmed] - Assigned to Ben Shum (bshum) |
19:15 |
bshum |
From my testing so far, the new marc_export that Dyrcona creates in his working branch is MUCH faster at its job. |
19:15 |
bshum |
And you can still run it in parallel groups. |
19:16 |
bshum |
I think a run of 100k records from our system normally takes about 1-2 hours and with his new script, we did the same batch less than half an hour. |
19:21 |
|
RBecker joined #evergreen |
19:21 |
|
artunit joined #evergreen |
19:36 |
|
Dyrcona joined #evergreen |
11:14 |
phasefx |
tsbere: do you have some easily shareable comparisons of output? |
11:14 |
tsbere |
phasefx: Gimme a min |
11:16 |
phasefx |
I don't have a good handle on how dewey and generic differ at the moment |
11:19 |
tsbere |
Hmmm |
11:20 |
* tsbere |
notes an issue with the true/false bit, he tested with 1/0 in a pl file but forgot the DB doesn't do that with boolean values |
11:22 |
tsbere |
easily fixed. <_< |
11:26 |
tsbere |
phasefx: I added example callnumbers to the end of the paste and what the original and "new" variants spit out for them |
11:26 |
phasefx |
cool deal |
11:44 |
|
mrpeters joined #evergreen |
11:45 |
|
mrpeters left #evergreen |
14:37 |
jcamins |
Well... unless I collapse each record into a single line. |
14:37 |
Dyrcona |
jcamins: sed works just fine over multiple lines. |
14:38 |
Dyrcona |
jl-: Can you program in Perl? |
14:38 |
jcamins |
Dyrcona: that would be an example of something about sed which I did not know. I may have to find a use to test this. |
14:38 |
jcamins |
*reason |
14:39 |
jl- |
grep -c '\="012"' ship_all.xml |
14:39 |
jl- |
3111 |
14:40 |
Dyrcona |
@marc 012 |
16:04 |
jl- |
jcamins or jeff |
16:05 |
Dyrcona |
jl-: If you have tags like sou in your file, they aren't valid, either. |
16:05 |
Dyrcona |
jl-: What ILS did these records come from? |
16:05 |
jl- |
rootevergreendev:/openils/Evergreen-ILS-2.5.1/Open-ILS/tests/datasets/sql# grep -c 'tag="sou"' bibs_concerto.sql |
16:05 |
jl- |
1 |
16:06 |
jl- |
Dyrcona: to be honest, the more I am working on them the more I think these records are shit.. they are from voyager but it also depends on the librarians how clean |
16:06 |
jl- |
they handle their records |
16:06 |
Dyrcona |
jl-: All MARC records are shit. |
16:06 |
jl- |
I was able to import the first 50000 |
16:06 |
jl- |
:) |
00:15 |
pinesol_green |
[evergreen|Pasi Kallinen] Fix some javascript errors, trying to access nonexistent widgets - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=fbb73c7> |
00:20 |
|
remingtron__ joined #evergreen |
00:24 |
|
fparks joined #evergreen |
00:47 |
bshum |
@later tell eeevil I was perusing new working branches and saw what you put in earlier today (user/miker/avoid-dupe-hold-on-list). Potential solution for old bug https://bugs.launchpad.net/evergreen/+bug/1046026 ? Tested and it does look... better! Exciting! :D |
00:47 |
pinesol_green |
bshum: The operation succeeded. |
00:47 |
pinesol_green |
Launchpad bug 1046026 in Evergreen 2.4 "Pull list shows multiple rows for same hold/copy" (affected: 5, heat: 26) [Medium,Confirmed] |
02:04 |
|
stevenyvr joined #evergreen |
13:49 |
eeevil |
jeff: did you get a chance to look at bug 1271630 yesterday? |
13:49 |
pinesol_green |
Launchpad bug 1271630 in Evergreen "Allow Located URIs to supply copy-like visibility to bibs" (affected: 1, heat: 6) [Wishlist,In progress] https://launchpad.net/bugs/1271630 - Assigned to Jeff Godin (jgodin) |
13:50 |
|
jihpringle joined #evergreen |
13:52 |
jeff |
eeevil: yes and no. rolling it into some testing i'm starting right now. |
13:56 |
yboston |
heads up the DIG monthly meeting will start at 2 PM EST |
14:00 |
yboston |
#startmeeting 2014-02-13 - DIG Monthly Meeting Evergreen Documentation Interest Group (DIG) Monthly Meeting. |
14:00 |
pinesol_green |
Meeting started Thu Feb 13 14:00:50 2014 US/Eastern. The chair is yboston. Information about MeetBot at http://wiki.debian.org/MeetBot. |
14:46 |
dbs |
jeff: you apt-get update && apt-get dist-upgrade'd first? |
14:49 |
jeff |
yep. |
14:50 |
* gmcharlt |
adds a step to release-cutting today |
14:50 |
phasefx |
jeff: there's one unitialized value in http://testing.evergreen-ils.org/~live/test.11.html Doesn't look fatal; that's a wheezy system |
14:51 |
jeff |
got it. so likely unrelated to that debian bug, and it's the later syntax error that i should dig at next |
14:55 |
dbs |
you have "check" installed? |
14:55 |
berick |
dbwells: fyi, the tpac / metarecords templates might need some conflict resolution for master after the wcag merge. going to look at that soon |
15:23 |
* dbs |
only gets an extend_reporter.sql error if he tries creating the schema without dropping the database first |
15:23 |
* dbs |
is not seeing any error output from seed data |
15:24 |
jeff |
jboyer-isl: and to answer your original question, dunno about bug reporting. i've usually stuffed a branch on github and pointed gmcharlt at it. |
15:24 |
dbwells |
dbs: are you testing in collab/berick/lp1053397-tpac-metarecords-r4, or master? |
15:25 |
gmcharlt |
jboyer-isl: jeff: and that will work for now |
15:25 |
jboyer-isl |
jeff: thanks. I'll probably do something similar. (or email a patch, it's maybe 30 chars...) |
15:25 |
dbs |
hah, master! |
15:30 |
berick |
dbwells: sorry about that. fix pushed to collab/berick/lp1053397-tpac-metarecords-r4 |
15:30 |
jeff |
jboyer-isl: this is how i addressed te floating issue: https://github.com/tadl/evergreen-contrib-equinox/compare/fix_floating_bool_now_int?expand=1 |
15:30 |
* berick |
checks the templates |
15:30 |
jeff |
gmcharlt: irc pullrequesting that commit. :-) |
15:31 |
jeff |
gmcharlt: fwiw, i have not tested that change on pre-2.5, but it fixed our extracts on 2.5. |
15:31 |
jboyer-isl |
jeff: thanks, I'll grab that for our next run. |
15:32 |
jeff |
bah. two typos in commit message. :P |
15:32 |
jeff |
(at least) :P |
18:43 |
bshum |
berick: Question for you |
18:44 |
bshum |
I'm looking at 161815ed and trying to figure out why the clear:both is commented out for .adv_filter_block |
18:44 |
pinesol_green |
[evergreen|Bill Erickson] LP#1268636 advanced search repairs - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=161815e> |
18:44 |
bshum |
Without that, the advanced search filters don't break up into separate rows like it used to. |
18:45 |
bshum |
Maybe just something tiny that snuck in accidentally |
18:46 |
bshum |
Mainly only a quirk on specific resolutions and groups of filters. |
18:47 |
bshum |
Like our first row of filters only has three in it, and then four in the next group of filters. So it should have split into two separate rows. |
18:47 |
bshum |
But on my test server, it all ended up on a single line |
18:47 |
* bshum |
does some more testing |
19:02 |
|
senator joined #evergreen |
19:08 |
|
senator joined #evergreen |
19:44 |
dbs |
bshum: I didn't see that behaviour with stock config--with the exception of the final row + sort options |
19:51 |
bshum |
dbs: I'm guessing it has something to do with the more filters you have per row. |
19:51 |
bshum |
That said |
19:51 |
bshum |
Now I'm not sure |
19:52 |
bshum |
Cause I don't see that in stock either... |
19:52 |
* bshum |
goes poking at his test server... WHY YOU NO WORK?! |
19:52 |
* dbs |
chuckles |
19:53 |
* dbs |
waits for koha clone to finish cloning |
19:56 |
bshum |
Oh, my master server isn't quite up to speed.... it's still a few days older than all the other changes. |
09:09 |
jl- |
ohai |
09:15 |
phasefx |
yo gozaimasu |
09:17 |
|
mmorgan joined #evergreen |
09:21 |
bshum |
@later tell talexander I was just reading the admin archive of recent messages and wonder what server specs your test machine has. My kneejerk reaction is that maybe you're under 2 GB of memory and the system is killing you as you try logging into Evergreen. |
09:21 |
pinesol_green |
bshum: The operation succeeded. |
09:21 |
* bshum |
still hates the evergreen-admin list |
09:22 |
|
dluch joined #evergreen |
12:20 |
jl- |
I used the concerto loader |
12:24 |
jl- |
dbs dbwells |
12:27 |
|
jihpringle joined #evergreen |
12:37 |
sseng |
hello. rebuilt master this morning and getting this error when doing a browse search : "An error occurred browsing records. Please try again in a moment or report the issue to library staff." |
12:37 |
sseng |
anyone getting this error? just wanted to make sure it not my test environment (tried rebuilding several times and getting similar errors) |
12:51 |
|
Wyuli joined #evergreen |
13:00 |
bshum |
sseng: I got that error on one of my master servers too. Might be string_agg changes dbs? |
13:00 |
bshum |
Also, airport signal sucks. |
14:19 |
jeff |
dbwells: would you like an action item for adding RM dates to the dev calendar? |
14:19 |
jeff |
#link http://www.google.com/calendar/embed?src=tfm2bbqnt7q890jidnqe3u29j4%40group.calendar.google.com&ctz=America/New_York |
14:19 |
dbwells |
eeevil: I can do the backport when I do rel_2_5, as long is you are fine with it going in. |
14:19 |
eeevil |
dbwells: with all the tests I'm fairly comfortable, fwiw |
14:19 |
eeevil |
dbwells: if you're offering, sure thing! :) |
14:19 |
eeevil |
(comfortable with a backport generally) |
14:19 |
dbwells |
eeevil: yes, no problem |
14:19 |
dbwells |
jeff: Why not |
14:19 |
jeff |
#action dbwells to add RM dates to dev calendar |
14:44 |
* dbs |
is working on the known STRING_AGG() text-casting at least |
14:44 |
gmcharlt |
it would be a pain, but this is one area where I think I trust ourselves more than I trust the Pg devs |
14:44 |
|
gsams joined #evergreen |
14:45 |
dbs |
gmcharlt: that doesn't sound too crazy to me. either way, with some pgTAP tests to ensure that the results are consistent across versions |
14:45 |
|
ericar_ joined #evergreen |
14:45 |
jeff |
gmcharlt: do you expect performance pain in addition to transition pain, or does this fall under the umbrella of "if we're xpath'ing too much, we're already doing something wrong"? |
14:45 |
gmcharlt |
tradeoffs might include performance and/or the time of maintaining our own extensions if we decide to write C instead of Perl to wrap around libxml2/libxslt |
08:54 |
|
jwoodard joined #evergreen |
08:54 |
csharp |
jboyer-isl: 37 is what I get on PINES prod (2.5.1) |
08:56 |
csharp |
I guess I don't know what I'm looking at here, though :-/ |
08:56 |
dbs |
berick: yeah, I was testing with a user that had fines. And they didn't show up properly (there were a couple of little squares floating below the actual fines box) |
08:56 |
jboyer-isl |
That table maps indexed fields to normalizing functions. So it says to run a date normalizer against the date type fields, etc. |
08:57 |
dbs |
berick: so arguably my commit to remove those divs is very much a bug fix :) |
08:57 |
csharp |
jboyer-isl: ah - I see |
09:01 |
csharp |
I know we have some custom metabib fields |
09:01 |
jboyer-isl |
csharp: I think it's from around the 2.0-ish area. Even if it were audited we'd both be in the dark by now. |
09:01 |
csharp |
yeah |
09:03 |
* dbs |
needs to build some pgTAP tests for further STRING_AGG() / 9.3 type strictness tweaks |
09:03 |
jboyer-isl |
csharp: Now I'm even more curious what this looks like at PINES: select id,field_class,name,xpath from config.metabib_field where id < 1000 order by id; |
09:04 |
jboyer-isl |
If you've got time, of course. |
09:05 |
pastebot |
"csharp" at 64.57.241.14 pasted "select id,field_class,name,xpath from config.metabib_field where id < 1000 order by id;" (36 lines) at http://paste.evergreen-ils.org/19 |
11:50 |
gmcharlt |
bshum++ |
11:55 |
|
mrpeters joined #evergreen |
12:09 |
|
jtaylorats joined #evergreen |
12:10 |
yboston |
jeff: thanks for the tip, still looking at it. Though I want to pull in a specific custom GooGle map. Not sure if I can do that yet. Need to write a test HTML page |
12:10 |
yboston |
dbs: thanks for the tip. I will look at this too |
12:10 |
jtaylorats |
Greetings....another, hopefully, quick question....The instructions on this page, at the bottom, says running the indicated script will provide a "pristine" database. |
12:10 |
dbs |
yboston: I can help if desired |
12:10 |
jtaylorats |
http://wiki.evergreen-ils.org/doku.php?id=evergreen-admin:importing:bibrecords |
14:35 |
|
stevenyvr joined #evergreen |
14:37 |
|
roses joined #evergreen |
14:39 |
|
ericar joined #evergreen |
14:39 |
roses |
I have a test demo server that I just installed 2.5.2 on (couldn't get it to upgrade from 2.3.7 cleanly) - it work working - could get to my staff client etc until yesterday when I installed pgAdmin III and to make that work I had to mess around with two files - /etc/postgresql..../postgresql.conf and pg_hba.conf - anyway I was able to get into pgadmin but now am not able to get into staff client? |
14:40 |
bshum |
roses: Err, if you were messing with those two files, I assume you had to restart/reload postgresql to apply changes. |
14:40 |
bshum |
roses: Did you restart osrf services after you did that? |
14:40 |
bshum |
And apache if you're restarting osrf services... |
09:24 |
AaronZ-PLS |
We have a library who managed to scan a barcode into Staff client/Patron details/Bills/Receipt Options/Number of Copies. |
09:24 |
AaronZ-PLS |
Where does EG store that setting in 2.2.1? |
09:24 |
AaronZ-PLS |
Theoretically, they could change it by hitting the down button (you cant type into the field), but hitting the down button more than 52000000000000 times seems somewhat over the top. |
09:24 |
AaronZ-PLS |
I tested it myself and I cant type in that box, but I can scan in some barcodes, ie:"US060TF7535903BCABD9" (PN from a Dell DVD) works, but "A00" (revision # from the same DVD) doesnt. |
09:25 |
phasefx |
AaronZ-PLS: try pulling up Admin -> For Developers -> about:config, filter on persist, and scroll through the results |
09:27 |
phasefx |
filtering on receipt_upon_payment should get you closer |
09:27 |
AaronZ-PLS |
phasefx: Thanks. Looks like its oils_persist_evergreen.owwl.org_bill2.xul_num_of_receipts_value |
13:45 |
|
Rish joined #evergreen |
13:46 |
|
Rish joined #evergreen |
13:47 |
|
Recky joined #evergreen |
13:47 |
jboyer-isl |
Good to hear. I'm going to try it against our test database and see how hard the cleanup will be. |
13:48 |
jboyer-isl |
Edited to correct our situation, obviously. |
13:50 |
jeff |
monitoring and logs... can you ever have enough? |
13:50 |
jeff |
good panel discussion. |
13:52 |
jeff |
everybody introduces themselves, everybody agrees you can never have enough logs, monitoring, automation, or testing (or automated testing, or automated monitoring (because really, should there be any other kind?)), panel discussion over. |
13:52 |
dbs |
Entire panel automatically monitored and logged by the NSA |
13:53 |
jboyer-isl |
jeff: I think you're forgetting the part where everyone argues that 75% of what the other panelists are doing misses critical issues. |
13:53 |
jeff |
jboyer-isl: that's the post-panel discussion, over everyone's choice of drink. |
13:54 |
jeff |
jboyer-isl: besides -- what is the answer to monitoring/testing/logging/automating the wrong thing? the answer is monitoring/testing/logging/automating MORE THINGS! |
13:54 |
dbs |
And then everyone goes off to build a new integrated automatic log monitoring system (IALMS) |
13:57 |
jboyer-isl |
Ugh. Not a fan of log monitoring. I'd rather poke at live state. (I say this having just developed a local feature that necessitates log monitoring...) |
13:57 |
jeff |
what local feature? |
14:00 |
jboyer-isl |
Using a payment processor I like so little I'm not submitting the code to core. There's a chance that if an authtoken is lost in memcache that the payment can still proceed but we don't know where to apply it. So something has to scan our osrfsys logs for SIREN.GIF and start sending urgent emails if that happens. |
14:00 |
jboyer-isl |
The moral of the story is test and use Stripe. :) |
14:01 |
jboyer-isl |
Just noticed I left out a "that" in that explanation. Suffice it to say that due to circumstances beyond my control, using a different provider is out. |
14:01 |
tsbere |
That sounds possibly problematic. What if the gif isn't requested due to other things (like someone turning off images)? |
14:01 |
jboyer-isl |
but that's no reason anyone else should use it. |
14:01 |
jeff |
oof. |
14:05 |
csharp |
ok - that's how I thought it worked. |
14:05 |
csharp |
thankks |
14:05 |
csharp |
tsbere++ |
14:06 |
tsbere |
csharp: Note I haven't *tested* any of this, this is based on my knowledge of the fine generator and some assumptions. ;) |
14:14 |
jl- |
I'm trying to bulk import in /test/datasets/sql with a 700mb file (17 million lines) but I get |
14:14 |
jl- |
psql:bibs_concerto.sql:17580472: ERROR: out of memory |
14:14 |
jl- |
DETAIL: Failed on request of size 268435456. |
14:15 |
jl- |
any suggestions? I'm gonna give the VM more memory but it already has 4 GB |
14:16 |
Dyrcona |
4GB is nothing these days. |
14:16 |
Dyrcona |
Evergreen is barely usable with no data in about 2GB. |
14:17 |
jl- |
I'm hoping that this means my import file has been sanitized correctly |
15:44 |
Bmagic|2 |
phasefx: I see, I appreciate it! |
15:46 |
phasefx |
jl-: you could use the perl module MARC::Record to read in the file and spit it out chunked. Would give you a heads-up on problematic MARC in the process |
15:51 |
jeff |
or yaz-marcdump as dbs recommended earlier. |
15:52 |
jl- |
phasefx as far as I can tell I already sanitized it to be sucked into the bibs_ machine in /tests/datasets/sql |
15:52 |
jl- |
I just get a connection lost at the end |
15:52 |
jl- |
atmittidly it's 17 million lines of records |
15:52 |
jl- |
about 200 000 records |
15:54 |
phasefx |
the Equinox migration_tools repository has a perl script called marc_cleanup (or something similar); it'll spit out one xml record per line; you could then use the split command on it |
15:55 |
jl- |
can I specifiy how many records per file? |
15:55 |
jl- |
or will I end up with 200 000 files |
22:05 |
|
jeff joined #evergreen |
22:07 |
|
ldwhalen joined #evergreen |
22:12 |
|
ldwhalen joined #evergreen |
22:25 |
dbs |
berick: I'm firing up a testing vm for the wcag commits. I bet you felt dirty letting that 4-image border for the fine box go through :) |
22:47 |
dbs |
Hmm. On Chrome I just deleted the offending divs and it didn't change the look one bit |
22:47 |
* dbs |
tests further |
10:13 |
dbs |
hmm. seeing the same problem as bhsum reported on ubuntu |
10:14 |
* dbs |
rattles the git tree to see what he can shake out of the branches |
10:30 |
bshum |
dbs: I think it has something to do with the scripts being referenced twice in the Makefile, but I'm not 100% sure yet. |
10:31 |
dbs |
eeevil: you see the "metabib.author_field_entry is getting 'name, name creator' additional entries" bug yet? |
10:31 |
dbs |
bshum: yep, I just pushed a fix |
10:31 |
dbs |
but testing it out on ubuntu and fedora with and without --prefix to be sure |
10:32 |
bshum |
dbs++ |
10:33 |
bshum |
I'll take a poke at it again later this evening. Gotta jet off for a bit. |
10:34 |
dbs |
and works, yay |
10:35 |
eeevil |
dbs: i doubt it. it's certainly a simple index def adjustment. is it causing problems for you, or just an annoyance? (afk for a while) |
10:35 |
dbs |
bshum++ # good jetting |
10:35 |
eeevil |
s/i doubt it/i have not/ |
10:36 |
dbs |
eeevil: it's an index bloat / inaccurate search thing - affects both 9.1 and 9.3, so yeah, index def adjustment |
10:36 |
dbs |
index bloat because you get approximately twice as many rows, inaccuracy because "creat*" |
10:42 |
dbs |
looks like we want to grab /name/namePart but not /name/role... fun fun |
10:43 |
dbs |
per http://laurentian-test.concat.ca/opac/extras/supercat/retrieve/mods32/record/1198543 and //mods32:mods/mods32:name[@type='personal' and mods32:role/mods32:roleTerm[text()='creator']] |
10:48 |
pastebot |
"bshum" at 64.57.241.14 pasted "show more details log error" (5 lines) at http://paste.evergreen-ils.org/15 |
10:48 |
* bshum |
fails at jetting |
10:48 |
dbs |
ah, sonofa |
11:10 |
bshum |
I see now |
11:10 |
bshum |
cd056eba75038c6a1fabd2a83ba97d81a444bc75 |
11:10 |
pinesol_green |
[evergreen|Ben Shum] Fix copy_info variables for result and record view - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=cd056eb> |
11:11 |
bshum |
When I wrote that, what was really wrong was that record/copy_table.tt2 should never needed anything for the variables |
11:11 |
bshum |
We could nix it from there cause the copy_info is already set there. So my change did nothing to it. |
11:11 |
bshum |
Since copy isn't referenced |
11:11 |
bshum |
I think? |
11:12 |
bshum |
But when we flipped around the variable in results, it broke the display :\ |
11:12 |
* bshum |
fiddles around |
11:16 |
bshum |
dbs: Commit here seems to fix it on my test system: http://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/bshum/fix-copy-info-again |
11:16 |
bshum |
I think I've got it sorted out this time :( |
11:39 |
pinesol_green |
[evergreen|Dan Scott] Address some remaining hardcoded install prefixes - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=aa8ea3c> |
11:40 |
eeevil |
dbs: re creator, I think we'll want a search_xpath to do the same thing as facet_xpath and browse_xpath ... i've no time today, though. i'll toss it on my community day pile |
13:07 |
jl- |
good afternoon |
13:25 |
jl- |
just installed a fresh copy of evergreen on a VM |
13:25 |
jl- |
newest opensrf and eg |
13:33 |
jl- |
could someone help me import this record, possibly testing it with me http://paste.debian.net/80892/ I'm not sure if it needs to be cleansed of anything and what tools to use (I was advised not to use pg_loader before) |
13:53 |
dbs |
bshum: well that's hilarious! will look at it later |
13:55 |
dbs |
jl-: insert the <record>...</record> bit (strip off the <?xml ...><collection> bits) and you should be good to go |
13:56 |
dbs |
jl-: you can look at Open-ILS/tests/datasets/sql/bibs_concerto.sql for an example -- almost the only gotcha is to escape single quotes that might exist in the record |
13:57 |
* dbs |
out |
14:06 |
jl- |
dbs: I see the bibs_concerto, looks like my format -- insert, how? |
14:38 |
jl- |
evergreen=# \i /home/x/Desktop/test.sql |
14:38 |
jl- |
psql:/home/x/Desktop/test.sql:70: ERROR: relation "marcxml_import" does not exist |
14:38 |
jl- |
LINE 1: INSERT INTO marcxml_import (tag, marc) VALUES |
15:13 |
jl- |
do I need to create a table marcxml_import ? |
15:52 |
dbs |
jl-: Open-ILS/tests/datasets/sql/load_concerto.sql gives you all the steps for concerto stuff, but that includes authorities, call numbers, and copies |
15:52 |
dbs |
you could change the marcxml_import line to "INSERT INTO biblio.record_entry (marc, last_xact_id) |
15:52 |
dbs |
and things should work |
16:13 |
dbs |
bshum++ |
16:14 |
pinesol_green |
[evergreen|Ben Shum] Fix copy_info variables one last time for library_name_link purposes - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=462a352> |
16:21 |
jl- |
brb |
16:25 |
jl- |
dbs: here's my test.sql http://paste.debian.net/80916/ |
16:26 |
jl- |
getting this error: evergreen=# \i /home/x/Desktop/test.sql |
16:26 |
jl- |
psql:/home/x/Desktop/test.sql:69: ERROR: |
16:26 |
jl- |
syntax error at line 1, column 0, byte 0 at /usr/lib/perl5/XML/Parser.pm line 187 |
16:26 |
jl- |
CONTEXT: PL/Perl function "maintain_901" |
16:39 |
jl- |
dbs: not sure if you typed anything since my last perl parse error |
16:40 |
jl- |
one question tho, in the concerto, there are no next line (like <br> in html) spaces |
16:40 |
jl- |
do I need to remove those from my record in the bibs_concerto.sql file? |
16:40 |
jl- |
the samples are all one single line |
16:40 |
jl- |
like a CSV |
16:50 |
|
zerick joined #evergreen |
16:55 |
jl- |
psql:assets_concerto.sql:99: ERROR: insert or update on table "monograph_part" violates foreign key constraint "monograph_part_record_fkey" |
16:55 |
jl- |
ETAIL: Key (record)=(84) is not present in table "record_entry". |
16:56 |
jl- |
:< |
17:14 |
jl- |
I did psql evergreen -f load_all.sql and it said it imported |
17:14 |
jl- |
how can I see it in the catalog? |
17:26 |
jl- |
ermahgerd |
17:26 |
jl- |
I'm seeing it |
17:26 |
jl- |
er mah gerd |
20:04 |
jl- |
I was able to import records with the load_all.sql initiating bib_concerta.sql, I can now search for certain authors and find them and their records |
20:04 |
jl- |
however, they don't show up under 'browse ALL' (next) |
20:05 |
jl- |
do I need to add certain meta data or do anything do build this index? |
20:21 |
|
sseng joined #evergreen |
20:21 |
|
ktomita joined #evergreen |
06:40 |
pinesol_green |
bshum: The operation succeeded. |
06:41 |
dbs |
bshum++ |
06:42 |
bshum |
I organized the upgrade SQL with little comments to myself like -- from 030.schema.metabib.sql |
06:42 |
dbs |
I will endeavour to test those out. Groggy. |
06:42 |
bshum |
So that I knew where I was looking for changes |
06:42 |
bshum |
I think I caught all of them, but there were lots. |
06:43 |
bshum |
dbs++ cool, cool |
11:15 |
* kmlussier |
tries to remember how you do that. |
11:15 |
dbwells |
Yes, same as above but with ?physical_loc=999 |
11:15 |
dbwells |
That should set a cookie. |
11:16 |
* krvmga |
is testing it now. |
11:16 |
kmlussier |
krvmga: Also see http://docs.evergreen-ils.org/2.3/_setting_the_default_physical_location_for_your_library_environment.html |
11:16 |
bshum |
krvmga: Maybe it's your kiosk software. I know some of those don't like remembering history/cookies |
11:16 |
kmlussier |
I had forgotten that you could set the cookie just by using the parameter in the URL. |
11:24 |
* krvmga |
hates getting intermittent and seemingly inexplicable 500 errors |
11:27 |
|
collum joined #evergreen |
11:38 |
csharp |
krvmga: do you have access to the server logs? |
11:38 |
bshum |
Or just test each brick individually |
11:39 |
csharp |
yeah - intermittent usually means a misconfigured brick |
12:02 |
bshum |
RIP Marque :) |
12:06 |
|
rfrasur joined #evergreen |
14:52 |
pastebot |
"csharp" at 64.57.241.14 pasted "marclint results for jboyer-isl's record" (11 lines) at http://paste.evergreen-ils.org/14 |
14:52 |
csharp |
so a couple of (apparently) invalid subfields? |
14:53 |
Dyrcona |
jeffdavis: No output from integrity-checker means everything checked is up to date, yeah? |
14:54 |
jboyer-isl |
There's a possibility. I just ran it through an xml validator (which can only do so much). I'll try just tearing those out on a test system and seeing if it saves correctly. If not, eeevil, I'll pull those tables if they're small enough and paste them separately. |
14:55 |
eeevil |
csharp: the 856$9 is ours, obv (located uris). the 500$0 looks odd |
14:56 |
eeevil |
jboyer-isl: config.xml_transform is not small :) |
14:56 |
jboyer-isl |
Shoot. I hadn't looked at it yet. :) |
17:19 |
bshum |
I think we're on PG 9.1 still |
17:23 |
|
Bmagic joined #evergreen |
17:23 |
Bmagic |
Hey everyone, got a billing question. We have noticed that money.billing and money.payments have rows that point to xact id's that dont exist in money.billable_xact |
17:25 |
dbs |
opened bug 1277731 - plowing ahead with array_agg testing |
17:25 |
pinesol_green |
Launchpad bug 1277731 in Evergreen "Hold tests failure" (affected: 1, heat: 6) [Critical,New] https://launchpad.net/bugs/1277731 |
17:26 |
dbs |
Bmagic: maybe in one of the Child tables: action.circulation, booking.reservation, money.grocery |
17:26 |
Bmagic |
dbs: thanks, i'll check |
17:26 |
dbs |
oh wait, I may be drunk |
10:26 |
* Dyrcona |
wishes library vendors actually had a clue. |
10:26 |
jeff |
I get worked up about this when evaluating new services. Sometimes the interest fades, sometimes not. |
10:27 |
jeff |
But part of the idea too is that it would give me some perspective on Evergreen/Koha/etc from a "content provider" point of view also. |
10:28 |
dbs |
jeff: this would let us test improved core security too, like replacing unsalted MD5-hashed passwords |
10:29 |
jeff |
"here's an idea, let's not use a self checkout protocol with access to holds/circ/bills/more just to verify that you are a patron, and let's not require your library card number (which one?) and library password be entered on the vendor site, and let's not have the vendor store your library password in cleartext in their systems!" |
10:29 |
jeff |
dbs: yes, though i see that as a parallel, higher priority goal. :-) |
10:29 |
dbs |
jeff: so teaching Evergreen to be an OAuth2 provider? |
11:35 |
bshum |
And yay, Marque.pm whee! |
11:35 |
Dyrcona |
I'm target it for the beta now. I'll see if I can't finish it by the end of the week. |
11:36 |
Dyrcona |
Everything is going into working/dyrcona/lp1223903-MARC-export-Mk.2 from now on. |
11:37 |
jboyer-laptaupe |
bshum: Re: commit db7b99e8ccba2ebf81a345157de5a90ba5387626, is there anything else that may need changing for rel_2_5? We have a test system built from rel_2_5 pulled just after that commit went in, but auto-print still doesn't seem to stick on the checkout page with a fresh staff client. |
11:37 |
pinesol_green |
[evergreen|Ben Shum] Revert "Eliminate an annoying and useless warning in the JavaScript Console." - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=db7b99e> |
11:38 |
bshum |
jboyer-laptaupe: It's a server side change. |
11:38 |
bshum |
Not just a client one |
11:40 |
bshum |
The one that gets me is the chrome directory stuff I think |
11:44 |
Dyrcona |
Yeah, just changing the file on the server fixed it for me. |
11:45 |
Dyrcona |
bshum: We've got six inches of snow at my house and its still coming down. |
11:45 |
jboyer-laptaupe |
Well never mind that. Our test system isn't running the version of evergreen we wanted to test. :( |
11:45 |
jeff |
jboyer-laptaupe: oops. |
11:47 |
jboyer-laptaupe |
jeff: I'd actually feel better about it if it were my fault. :/ |
11:49 |
|
akilsdonk joined #evergreen |
15:12 |
|
stevenyvr joined #evergreen |
15:13 |
dbwells |
roses: depending on when 2.4 was released, there might not be a direct route from 2.3.7 to 2.4.0, so you may need to massage the early upgrade scripts until you are back on track. |
15:14 |
roses |
dbwells: I'm running the first script (.sql) and I'm having trouble with the password for evergreen - shouldn't it be evergreen because of #10 in the instructions? perl Open-ILS/src/support-scripts/eg_db_config --update-config --service all \ --create-offline --database evergreen --host localhost --user evergreen --password evergreen |
15:15 |
dbwells |
roses: There is also at least one supplemental script for 2.4, so make sure you run that too, or at least understand what it does (sometimes scripts do something which gets done again later anyway, especially reingesting records). |
15:15 |
dbwells |
roses: Is this a test server? |
15:15 |
roses |
dbwells: Yes - a test server |
15:15 |
roses |
dbwells: Which I might just wipe and start with a fresh installation of 2.5 |
15:16 |
dbwells |
The password will be whatever you set it to when you set it up, your evergreen DB password. |
15:17 |
dbwells |
That is, if you ever login to the evergreen DB using 'psql', it will be the same username/password you use for that. |
15:19 |
dbwells |
It's might be nice to run through the upgrade scripts for general practice, understanding, and to test the scripts themselves, but unless you have a lot of data in your test server, installing fresh is probably easier. |
15:20 |
roses |
dbwells: Thanks. I found my password and now am going to run through the scripts. I might be back later. |
15:24 |
fparks |
I am working on a new rendition of Boolean Search https://bugs.launchpad.net/evergreen/+bug/1152863 |
15:24 |
pinesol_green |
Launchpad bug 1152863 in Evergreen "Support for traditional Boolean operators" (affected: 3, heat: 18) [Wishlist,Triaged] |
15:44 |
Dyrcona |
'course we only 56 SREs in our database, so more eyes might be good on that part. :) |
15:44 |
Dyrcona |
...only [have] 56.... |
15:47 |
|
roses joined #evergreen |
16:10 |
phasefx |
bshum: I tried looking at the commit log for that line re: non-cat in-house, and I think it was indeed oversight + intermediate testing |
16:12 |
phasefx |
for those curious (and I only just now learned how to do this), I did git blame in_house_use.js, got a useless commit message for some whitespace cleanup, but then did this to get the commit prior to that: git blame in_house_use.js b228af4f~1 |
16:12 |
pinesol_green |
[evergreen|phasefx] Change each tab to 4 spaces in the staff client javascript files. - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=b228af4> |
16:35 |
Dyrcona |
learning++ |
16:35 |
Dyrcona |
I learned a new git trick today. |
18:19 |
pinesol_green |
Launchpad bug 1155769 in Evergreen "Items repeated in tpac display, others not visible" (affected: 3, heat: 16) [Undecided,Confirmed] |
18:19 |
bshum |
Do you know how that bug is replicated? I've never been able to consistently get broken displays as described. |
18:19 |
Dyrcona |
dbs: git rebase -i / then edit the commit, reset HEAD^, add some files, commit, add the remaining files, commit, rebase --continue |
18:20 |
kmlussier |
I've seen it happen. You've got to find the right record to make it happen. |
18:20 |
kmlussier |
I was just about to test it and was first looking for a record. |
18:20 |
bshum |
And I'm not sure the change ktomita makes there to order by barcode instead of copy number would necessarily be good. Just for the folks who do use copy number in their cataloging. |
18:20 |
bshum |
Not us, for sure, but someone might? |
18:21 |
kmlussier |
Sounds like a good comment to make on the bug report. :) |
13:18 |
csharp |
looks like closed dates are acting more like grace periods with the current behavior |
13:19 |
Dyrcona |
next breaks from the loop at that point and starts again at the top with the next iteration. |
13:21 |
dbwells |
csharp: I am pretty sure the code is meant to do what you want it to do. If I understand your situation correctly, for some reason, actor::org_unit::closed_date->search_where() isn't finding your closed dates. |
13:22 |
csharp |
dbwells: I can dig for this, but can you see a simple-ish way to test that hypothesis? |
13:22 |
Dyrcona |
I was about to say something along the lines of what dbwells just said. |
13:22 |
Dyrcona |
I needed more context. :) |
13:23 |
dbwells |
csharp: That function basically is a straight DB lookup (I think), so I'd start by looking in the DB and see if everything is in line there. |
16:41 |
eeevil |
Dyrcona: for your next trick, convince B&T a library might want to use all 35 bytes available to name itself in EIDFACT, not just 5. ;) |
16:42 |
eeevil |
see also: item identifiers |
16:45 |
|
roses joined #evergreen |
16:46 |
roses |
Several months ago (almost a year) I was working on setting up a test Evergreen server and someone here told me about where to find some fake/test records to import into my catalog? Where can I find something like that? |
16:50 |
bshum |
roses: If you're just setting up some sort of demo system, you can always use the stock concerto dataset that comes with Evergreen 2.4+ |
16:50 |
roses |
bshum: I installed 2.3.7 |
16:51 |
bshum |
That step gets described a bit in step 9.1 of the 2.5 README |