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 140 141 142 143 144 145 146 147 148

Results for 2014-03-05

09:37 pinesol_green Dyrcona: The operation succeeded.
09:38 csharp @later tell huginn please tell #koha we said "hello"
09:38 pinesol_green csharp: The operation succeeded.
09:40 phasefx any objections to subscribing pinesol to http://testing.evergreen-ils.org/~live/ in this channel?  It's been doing it in #openils-evergreen for a while now as an experiment
09:40 csharp phasefx: no objections here
09:41 Dyrcona My question would be: How spammy is that?
09:41 phasefx one message a day
09:41 bshum Fix the live test failure and I'll say yes.
09:41 bshum :D
09:42 bshum Cause otherwise it'll just make me sad to see that message.
09:42 Dyrcona I don't think one message a day would be a problem.
09:42 * phasefx was kind of hoping folks seeing the failure message would cause some impetus to getting it fixed :)
09:42 yboston joined #evergreen

Results for 2014-03-04

12:47 bshum http://openkiosk.mozdevgroup.com/
12:47 bshum (oh they changed their website...)
12:51 mmorgan Do slips print with either of those?
12:52 bshum mmorgan: I... think it can.  But I haven't tested it quite yet.
12:54 mmorgan We've had trouble getting the slips to print with different kiosks, but we'll take a look at these. Thanks!
12:57 krvmga joined #evergreen
12:58 krvmga i've got a situation where one of the holds that a patron has placed is causing errors. in the staff client, looking at the patron's holds, there is one that is always "retrieving" and i can't see what it is. how can i get at that hold?
13:18 bshum mmorgan: Oh you know... there was a bug for awhile in selfcheck
13:18 bshum Where the receipts didn't print at all due to a javascript error
13:19 bshum But I can't remember if that was ever resolved in more recent versions.  Or if it only affected certain parts of the receipts.  Like billings.
13:20 mmorgan Do bugs work as sacrificial offerings? :)
13:22 mmorgan I know a few kiosks have been tried and some printed but had other issues. We need to do some more testing, these suggestions will help.
13:23 mmorgan dbs++ bshum++ Wyuli++
13:25 jwoodard joined #evergreen
13:33 tsbere bshum: I think part of the problem with printing is "modern web browsers don't allow automatic printing, or interaction with printer settings in general, at all from web pages anymore"
13:36 Wyuli mmorgan, tsbere: The Evergreen self-check module and I are not on real good terms. :\  There's a pretty slick open source self checkout packge that runs on PHP and is pretty slick.
15:37 Wyuli jboyer-isl++ Thanks; I think that solves the mystery rather succinctly. :)
15:38 berick dbwells++ # 2.6 beta summary
15:48 senator joined #evergreen
15:54 eeevil I think we have code attached to all the RC blockers now ... https://bugs.launchpad.net/evergre​en/+bugs?field.tag=2.6-rc-blocker is looking for testers.  IMO, the sooner we can get those big ones out of the way the sooner we can start sweeping up the smaller bugs ... so, here's a call for testing, folks!
15:55 dbs eeevil++
15:56 dbwells eeevil++
16:01 gmcharlt eeevil++
16:52 kbeswick left #evergreen
17:20 mmorgan left #evergreen
17:25 dcook joined #evergreen
17:26 * bshum twiddles his thumbs waiting for 0864 to run on his test server.  (finish already!!)
17:31 bshum And it dies.
17:31 bshum Oy :(
17:31 dbwells :(
17:31 bshum Stupid reporter.classic_current_circ depends on rec_descriptor stuff
17:31 bshum Guess that's a killer.
17:52 bshum :)
17:52 pinesol_green Launchpad bug 1287510 in Evergreen "2.5.2-2.5.3-upgrade-db.sql and ERROR: column "behind_desk" does not exist" (affected: 1, heat: 6) [Undecided,New]
17:53 Callender_ joined #evergreen
17:54 bshum Oh you know dbwells
17:54 bshum This is a bad, bad test
17:54 bshum I keep forgetting I'm using my Thinkpad with the SSD
17:54 bshum So it's probably doing the job much faster than it does with our regular disk servers.
17:54 bshum I'll let you know when I run it on the other machines.
17:54 mrpeters left #evergreen
17:56 dbwells Oh, I was really just curious if we were talking minutes, 10s of minutes, or hours.  I am not too worried about it.
17:56 bshum Well, on the Thinkpad with SSD, it was no more than just minutes then.
18:07 bshum And that classic reporter issue
18:07 bshum We'll figure out what to do about it sometime before release I guess :\
18:07 dbwells bshum++ # thanks, man
18:08 bshum I'll finish whipping my test Evergreen frontend into shape and then see what things look like tomorrow.
18:31 bshum @later tell berick When you have a chance, curious to get your opinion on this new bug https://bugs.launchpad.net/evergreen/+bug/1287973
18:31 pinesol_green bshum: The operation succeeded.
18:31 pinesol_green Launchpad bug 1287973 in Evergreen "TPAC - CSS for advanced search filters" (affected: 1, heat: 6) [Undecided,New]
18:31 bshum It's a tiny thing, but it irks me enough that I'd like to get to the bottom of it before 2.6 is "done"
18:50 eeevil bshum: there definitely is. I plan to merge a squashed, rebased version of that branch tomorrow morning
18:50 bshum eeevil: Ah, cool.  I'll watch for it then.
18:51 bshum And make sure that nobody clicks on that option in advanced search during tomorrow's demos :)
18:51 eeevil :)
18:52 eeevil I'm not certain that what you're seeing is covered, but I am certain that there are bug fixes and that it works on fresh and upgraded test instances 'round here
18:52 eeevil (and that we don't see ... that)
18:52 ericar joined #evergreen
18:52 bshum I have to take a closer look at these icon_format things
18:52 eeevil bshum: I assume you reingested (or, at least the attrs, if not the full records)?
19:08 * bshum looks again
19:08 eeevil well, as far as duplication is concerned...
19:08 eeevil but I might have misunderstood you
19:09 bshum It's alright, I often have trouble with my words.  And this is the first time I've actually had time to try applying these things to a test system.
19:14 eeevil you know ... we might need to add  "AND all_orgs.flag" (and wrap the pair in parens) for the right hand side of the OR in those where clauses. (let me know if you're not following ... I'm not giving a ton of context, I know)
19:14 bshum Oh I'm surely lost.  But maybe that's a consequence of not going home to eat dinner.
19:15 eeevil heh ... poke me tomorrow re evergreen.located_uris() and all_orgs.flag, I'll know what you mean ;)

Results for 2014-02-28

10:15 akilsdonk_ joined #evergreen
10:15 mtcarlsoz joined #evergreen
10:33 gmcharlt joined #evergreen
10:36 jeff csharp: am i remembering correctly that you had a favorite tool for use on test/dev systems with regard to accepting all mail, but not relaying it on to its actual intended destination?
10:36 jeff it might have been a specific configuration of sendmail/exim/postfix, or it might have been a special-purpose MTA. ring any bells?
10:43 mrpeters joined #evergreen
10:45 Dyrcona jeff: You could always setup an inetd entry on port 25 and redirect it to /dev/null. ;)
10:46 Dyrcona That will "accept" all incoming mail and not send it on.
10:46 jeff someone suggested nc -l > /dev/null :-)
10:46 Dyrcona Yeah.
10:46 Dyrcona It won't do SMTP, though, so the other end might get confused.
10:46 tsbere_ jeff: I had, at one point, configured our mail server to accept all mail from our test systems but drop it into a local mailbox instead of the real destination(s)
10:46 jeff i don't think that either option would -- right, exactly.
10:47 jeff i might get some spam from old spambots, but not much else. :-)
10:47 csharp jeff: one of our admins had set up postfix to send to a directory (not /dev/null :-), but a similar idea), and it was set up so we could connect an email client to it to see what was sent
11:13 pinesol_green Launchpad bug 1272316 in Evergreen "much slower holds processing in 2.4+" (affected: 10, heat: 46) [High,Confirmed]
11:14 eeevil kmlussier: absolutely
11:14 kmlussier Great - thanks!
11:14 eeevil I'm actually holding off cutting 2.4.next to give a couple folks a chance to test
11:14 eeevil however, I'll probably not wait much longer, since csharp has confirmed its efficacy and was the OP on the bug
11:15 eeevil IIRC
11:15 eeevil yeah, he was
11:15 kmlussier OK, good to know. I think we have a couple of people who are anxious to see it in production.
11:18 eeevil kmlussier: IIRC, Dyrcona applied my SQL-ified, rebased version of depesz's ranked volumes patch (https://bugs.launchpad.net/evergreen/+bug/1234845) ... if you can confirm it's good for you, we could get that in soon, too. though that will probably not be 2.4 material (I'll have to look more closely)
11:18 pinesol_green Launchpad bug 1234845 in Evergreen "possible optimization for evergreen.ranked_volumes database function" (affected: 2, heat: 12) [Medium,Triaged]
11:18 eeevil kmlussier: applied to his test system, I mean
11:19 Dyrcona Yep.
11:19 kmlussier eeevil: I should have time to look at it today.
11:19 * gmcharlt tosses OpenSRF bug https://bugs.launchpad.net/opensrf/+bug/1286198 out for consideration
11:22 eeevil kmlussier: thanks
11:23 eeevil kmlussier: re the other one ... the issues you found confuse me, and I haven't looked back at it in a couple weeks
11:23 * eeevil tosses it on the pile
11:25 kmlussier eeevil: When you have time to look at it, let me know. The examples I used are outdated because new items have been added to the database since I first reported it. I'm happy to redo my testing at a time when eyes are on it.
11:25 eeevil thanks!
11:25 eeevil I will ping you before I start
11:29 Dyrcona gmcharlt: You have to change each bug independently of the others, unless you write a script.
11:40 jeff Dyrcona: yup. looks like the same issue.
11:41 gmcharlt heads up to those who run on OpenSRF master - I will be pushing lp1179660 at some point soonish
11:41 gmcharlt bug 1179660
11:41 pinesol_green Launchpad bug 1179660 in OpenSRF "OpenSRF.pm AUTOLOAD complicates testing / serves little purpose" (affected: 1, heat: 6) [Medium,Triaged] https://launchpad.net/bugs/1179660
11:42 gmcharlt there is a decent chance that it will expose further AUTOLOAD dependers in the Evergreen codebase
11:42 gmcharlt in fact, that's exactly why I want to push it
11:43 Dyrcona gmcharlt: Good to know. I won't update my development environment for a few days, but when I do, I'll update OpenSRF, too.
12:33 Shae_ joined #evergreen
12:33 bshum eeevil: Oh I have it queued up in my master branch, but hadn't looked at the backports quite yet.
12:34 eeevil bshum: if you sign off on the master/2.6 version, I'll do the heavy lifting for backport. FWIW, we've pushed it into a 2.4 instance already
12:35 bshum eeevil: Yeah I wasn't too worried about the backport testing since I knew folks were on the case.
12:35 bshum Give me two seconds
12:36 eeevil bshum: I'll give you FOUR
12:36 bshum Heh
12:36 bshum I have to double check which upgrade number we're on
15:00 jeff bah
15:00 DPearl joined #evergreen
15:23 jboyer-isl Is there some trick I'm missing with respect to rsyslog and eg-stats-collector? I followed the instructions here: http://git.evergreen-ils.org/?p=contrib/equi​nox.git;a=blob;f=monitoring/eg-stats/README and my logging machine is just dumping all kinds of stuff in the egstats file.
15:29 kmlussier I'm looking at the new ranked volumes function on Dyrcona's server. It looks good, but then I got distracted by the shiny new "Group Formats and Editions" checkbox.
15:30 kmlussier But I can't get it to work correctly on any search I try. When I click on a title to see the grouped records, I always get 0 results.
15:30 kmlussier Is it possible the ranked volumes branch I'm testing affects it? I don't see any other dev branches on Jason's server that should affect the search results page.
15:33 berick kmlussier: can't say for sure, but i would recommend merging https://bugs.launchpad.net/evergreen/+bug/1284864 before testing MR stuff.  lots of fixes in there.
15:33 pinesol_green Launchpad bug 1284864 in Evergreen "TPAC metarecord / formats repairs and usability additions" (affected: 1, heat: 6) [Undecided,New] - Assigned to Bill Erickson (erickson-esilibrary)
15:37 dreuther joined #evergreen
15:37 kmlussier I was just looking at those, but didn't see this particular problem being noted.
17:04 DPearl1 joined #evergreen
17:05 Bmagic Honestly, I am totally confused about Encode.pm
17:05 Bmagic I think that I have struggled with this for years now
17:08 Bmagic I have written code to test the string for utf8 and wide characters ahead of time and then encode/decode depending. I have liftedcode from EG and sometimes messing with some other modules.  It's all inconsistant and I have given up trying to figure this out but it keeps coming back and biting me
17:11 23LAAEWVZ joined #evergreen
17:11 Bmagic I would love a second set of eyes on this http://pastebin.com/e7D1s6Ys
17:12 Bmagic specifially sub query{}

Results for 2014-02-27

02:16 bshum Yeah, error is gone.  Nevermind, all is well after all.
02:50 gmcharlt joined #evergreen
07:35 rjackson-isl joined #evergreen
07:54 csharp bshum++ # testing through the night
08:07 remingtron joined #evergreen
08:08 akilsdonk joined #evergreen
08:13 kbeswick joined #evergreen
08:26 kmlussier joined #evergreen
08:28 kmlussier A question for csharp, bshum, and/or eeevil regarding the fix for https://bugs.launchpad.net/evergreen/+bug/1272316/
08:28 pinesol_green Launchpad bug 1272316 in Evergreen "much slower holds processing in 2.4+" (affected: 10, heat: 46) [High,Confirmed]
08:29 kmlussier It looks like most of the testing involved holds placement. Are you also seeing improvement for retargeting holds at checkin? Or is this fix specifically for the "place holds" issue?
08:29 Shae joined #evergreen
08:30 csharp kmlussier: we were not aware of a problem at checkin in PINES, so I haven't investigated that
08:33 csharp I'm investigating why our users are able to edit their own accounts in Evergreen 2.5.1 - I'm not sure that this wasn't going on before that... In any case, I'm looking closely at Open-ILS/xul/staff_client/​server/patron/user_edit.js for clues
08:34 csharp kmlussier: let me check that and get back to you
08:34 kmlussier csharp++ Thanks!
08:49 timlaptop joined #evergreen
09:07 csharp kmlussier: from my testing, I can see the hold targeter churning through far faster than before
09:07 csharp before the messages would hang, then move, then hang then move
09:08 csharp now they're moving pretty fast
09:08 tsbere_ joined #evergreen
09:10 csharp on a related note, has anyone implemented a "delete holds and notify the patron when all eligible copies are in a non-holdable status" feature?
09:10 csharp I'm assuming A/T could handle that
09:10 csharp s/eligible/previously eligible/
09:12 jeff We don't currently have anything like that, and I'd be a bit hesitant to introduce it without at least a timeout interval, during which reporting could give staff the opportunity to intervene.
09:13 jeff But it would also probably be important to have a means to selectively suspend the pending cancellation process, and I'm not sure what form that should take.
09:14 csharp jeff: good points
09:14 tsbere csharp/jeff: We have a "these holds can't be filled" report that staff poke through every so often (I hope)
09:14 csharp tsbere: yeah that may be a better approach
09:15 jeff similar here. they show up on our standard holds ratio report with a ratio of infinity. :-)
09:16 bshum kmlussier: Agreed with csharp that hold_targeter churn does seem faster than before.
09:16 bshum As far as checkin, that's trickiwr
09:16 bshum *trickier for me to test right now.
09:17 bshum But I'm sure it'll come up soon.
09:20 csharp bshum: are you running the patches in production?
09:21 bshum csharp: Maybe .... :)
09:24 csharp heh
16:07 jeff which isn't the longest value, but it is the largest value shared by more than one record.
16:10 Claudia_Love joined #evergreen
17:02 gsams joined #evergreen
17:03 bshum Oops
17:03 bshum Looks like Elliot is burned on osrf_control because he's not using the OpenSRF 2.3 beta
17:03 bshum In conjunction with testing for Evergreen 2.6 beta1
17:04 bshum gmcharlt: Was 2.3 cut after the last dev meeting?
17:04 bshum *OpenSRF 2.3
17:05 gmcharlt no, I'll get on that now
17:05 bshum I'll do some explanation for the discussion on the lists.
17:05 bshum Thanks gmcharlt
18:41 ktomita_ joined #evergreen
18:44 ningalls1 joined #evergreen
18:53 ktomita joined #evergreen
18:53 jeffdavis we've got a 2.6beta1 test server up and running, will start proper testing tomorrow
19:37 dac joined #evergreen
19:42 jeff joined #evergreen
19:42 b_bonner_ joined #evergreen

Results for 2014-02-26

08:48 akilsdonk joined #evergreen
08:50 finnx joined #evergreen
08:51 csharp @hates
08:51 pinesol_green` csharp hates dojo_hold_policies_interface; SIP; when libraries purchase third party products without testing and blame Evergreen for it not working; reports; the fact that the Base Filters is unnecessarily greyed out when applying an Aggregate Filter and vice versa; evil; reports more; reports even moar; details; reports even more; the fact that the Base Filters is unnecessarily greyed out (1 more message)
08:51 csharp @more
08:51 pinesol_green` csharp: when applying an Aggregate Filter and vice versa even more; and having to teach SIP2 client vendors about the SIP2 specification
08:52 * csharp notices hatred themes of SIP and reports ;-)

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
14:23 kbutler joined #evergreen
14:27 jboyer-dc joined #evergreen
14:32 mceraso dbwells: Tested 2.6 Beta Preview using Ubuntu 12.04 LTS. Works just fine!
14:33 dbwells mceraso++ # thanks again!
15:17 floadam joined #evergreen
15:42 bshum csharp: You didn't add it to the bug, but I assume your signoff branch is official?

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

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

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 140 141 142 143 144 145 146 147 148