Evergreen ILS Website

Search in #evergreen

Channels | #evergreen index




Results

Result pages: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139

Results for 2014-02-25

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/Everg​reen.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

Results for 2014-02-24

12:09 b_bonner joined #evergreen
12:11 Dyrcona dbwells: Thank you. That works for me.
12:11 jeff heh. lost any response in the netsplit.
12:14 dbwells For jeff and the logs (if I was on the "wrong" side): "Based on where we are at, I am looking at 3/12 for the RC cutting, and final TBD based on RC testing/reception."
12:29 fparks joined #evergreen
12:31 jeff dbwells++ thanks :-)
12:36 jihpringle joined #evergreen

Results for 2014-02-21

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-i​ls.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

Results for 2014-02-20

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/builde​rs/evergreen-master-ubuntu-12.04-x86/builds/538  blamelist: Jason Boyer <JBoyer1@library.in.gov>, Lebbeous Fogle-Weekley <lebbeous@esilibrary.com>, Dan Wells <dbw2@calvin.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/builder​s/evergreen-master-debian-6.00-x86_64/builds/532  blamelist: Jason Boyer <JBoyer1@library.in.gov>, Lebbeous Fogle-Weekley <lebbeous@esilibrary.com>, Dan Wells <dbw2@calvin.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/bu​ilders/evergreen-master-fedora-18/builds/506  blamelist: Jason Boyer <JBoyer1@library.in.gov>, Lebbeous Fogle-Weekley <lebbeous@esilibrary.com>, Dan Wells <dbw2@calvin.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

Results for 2014-02-19

10:06 Dyrcona jl-: The code is in Open-IlS/src/perlmod/lib/O​penILS/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/_mig​rating_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-i​ls.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

Results for 2014-02-18

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/co​llab/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

Results for 2014-02-14

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- root@evergreendev:/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- :)

Results for 2014-02-13

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-i​ls.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-equi​nox/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.

Results for 2014-02-12

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.cale​ndar.google.com&amp;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

Results for 2014-02-11

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...

Results for 2014-02-10

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

Results for 2014-02-09

10:36 finnx joined #evergreen
11:07 Dyrcona jl-: Probably, but I don't have time to go into it. Check the release notes directory. I think that was new in 2.5.
11:10 jl- Dyrcona gotcha, np
12:58 eeevil bshum: thanks for testing and pushing :)
13:01 jl- is there a google grp I can post my question tp?
13:07 paxed no, but there are mailing lists. http://evergreen-ils.org/c​ommunicate/mailing-lists/
13:07 paxed although if the devs here cannot answer, it's unlikely the people in the MLs would know either.

Results for 2014-02-08

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/extr​as/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=work​ing/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

Results for 2014-02-07

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/_s​etting_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

Results for 2014-02-06

15:12 Dyrcona jl-: No, it explains the missing </collection>.
15:12 jl- right
15:12 Dyrcona jl-: It looks like your records are missing the namepace declaration, and we don't normally use the xsi schema stuff, but it should be ignored.
15:13 jl- I figgured testing with 1 record will be easier
15:13 jl- than with over a million
15:13 Dyrcona If that is exactly what you are using, either remove the <collection> at the top or add </collection> at the bottom.
15:14 Dyrcona What errors are you getting?
15:15 jl- Dyrcona: well do I need to do any encoding before importing?

Results for 2014-02-05

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. :)

Results for 2014-02-04

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

Result pages: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139