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

Results for 2014-01-24

10:36 csharp senator: yeah - that's what I'm trying to do now - thanks for the suggestion
10:37 senator if you can get a log trace of a single hold placement (which as you know invokes the targeter for that specific hold) that's granular enough to show us more precisely where the slow part is
10:37 senator yeah
10:38 csharp I've got one with DEBUG enabled on our test server
10:38 csharp I'm trolling through it
10:45 RoganH I change windows and all I see is chsarp saying something about trolling.  It's going to be that kind of day, eh?
10:54 * csharp IS IN UR IRC CHANNEL TROLLIN U LOL LOL LOL
10:54 jeff @decide Totally Awesome District Library or Trolling All Day Long
11:41 senator csharp: if possible (and i'm sure you'll want to do some redacting of authtokens, barcodes, and IPs) a pastebin of the log would be awesome
11:42 csharp senator: yeah - I'm trying to make sure I don't paste anything private - looking for authtokens, passwd hashes, etc.
11:45 berick csharp: you can look for 32-character words (md5 authtokens and password hashes) w/ something like:  grep -w '\w\{32\}' filename
11:46 csharp berick: excellent - thanks
11:47 csharp http://pastebin.com/6LCW2Luf
11:48 csharp this is at loglevel 3 on our live server, btw
11:48 csharp I can do one with DEBUG enabled on our test server if that helps
11:50 berick wonder what's happening between 11:01:04 and 11:01:13
11:51 sylvar joined #evergreen
11:52 berick that is a lot of OUS calls.  just switching to the cstore / stored-proc variant would help a lot
11:54 csharp I can see how this wouldn't have manifested itself in an instance with fewer Ous
11:54 berick yeah
11:57 csharp that gap looks like this on the test server (different hold): http://pastebin.com/YmC7pUNq
11:58 csharp (between Processing hold blah... and when it starts checking OU settings
11:58 csharp )
12:00 berick huh, wonder which of those is taking so long on your prod servers.  I take it the prod hold is on a popular record with lots of copies?
12:04 csharp lemme look
12:06 csharp 227 total copies - 4 current holds
12:07 csharp http://gapines.org/eg/opac/record/5606034 - "Calculated in Death" - apropos title ;-)
12:07 berick heh
12:08 csharp I'll place a hold on it in our test server and see what the log output is there
12:10 tsbere I wonder if we have similar problems when records have a couple hundred copies. We appear to have less than 300 total records with >100 copies, actually...
12:13 csharp whoa 22968 lines for that threadtrace
12:13 csharp but it took  73 seconds to process
12:13 tsbere Hmmm. 48% of our records have ONE copy. >_>
12:34 senator csharp: if you're feeling saucy, on your test system,
12:34 senator you might try working/collab/senator/slow-targ​eter-try-faster-settings-lookup
12:34 * csharp is feeling saucy and SASSY
12:34 senator that has two commits
12:34 rsinger joined #evergreen
12:51 sseng dbs: that's sounds like it, now curious to see where in eg code the barcode gets written to that subfield.
12:52 sseng dbs: thanks a bunch for your help!
12:52 smyers_ joined #evergreen
12:54 csharp senator: I saw that speed up from 73 to 61 seconds on the test server after applying the patches and restarting opensrf
12:54 csharp Method duration for [open-ils.storage.action.ho​ld_request.copy_targeter]:  59.706
12:55 csharp Method duration for [open-ils.circ.holds.test_and_create.batch]:  61.294
12:55 csharp ^^after
12:55 csharp vv before
12:55 csharp Method duration for [open-ils.circ.holds.test_and_create.batch]:  71.550
12:56 csharp Method duration for [open-ils.storage.action.ho​ld_request.copy_targeter]:  73.370
12:56 csharp the frontend still times out, but it's better on the server side
12:58 * dbs wonders about caching the COUST rather than fetching it fresh every time
12:59 eeevil sseng: re barcode in 905u, evergreen doesnt write that, it reads it from external tools
13:00 * eeevil disappears as quickly as he appeared
13:00 sseng eeevil: ooh i see. so, might not be a good idea to comment that check out, thanks!
13:01 Dyrcona joined #evergreen
13:02 Dyrcona More pgtap questions.
13:02 Dyrcona Should a test file related to a database upgrade script go in t or t/regress? I assume t, but thought I would ask.
13:15 rsinger joined #evergreen
13:20 rfrasur joined #evergreen
13:25 RoganH joined #evergreen
13:27 Dyrcona Hmm. Also, what about a branch with two upgrade scripts? So far I'm putting the tests in a single .pg file.
13:28 Dyrcona The scripts could be merged into one upgrade script, I guess.
13:31 ericar joined #evergreen
13:54 tsbere senator / csharp: Thinking about holds and the stuff being done, wouldn't most of the lookups in the targeter not affect placement at all? respond_complete happens *before* the hold creation process fires off a blind request to the copy targeter after all...
13:58 * csharp has no idea...
13:59 * senator thinks and looks
13:59 senator csharp: also, cool, thanks for testing that, at least it's a small win. more to do i see...
13:59 csharp senator: happy to help!
14:02 ktomita_ joined #evergreen
14:05 senator tsbere: so you mean the respond_complete near the end of sub create_hold aka open-ils.circ.holds.create.override ?
14:07 senator i see tpac code calling open-ils.circ.holds.test_and_create.batch instead
14:09 * Dyrcona sings: "Let's do the 'rebase' again...."
14:11 Dyrcona senator: Note tsbere is talking about the targeter and not tpac.
14:12 tsbere senator: test and create batch ends up calling open-ils.circ.holds.create (or the .override variant) if the "test" succeeds
14:12 senator right, well i thought we're talking about whether the targeter must be waited on at hold placement time
14:12 Dyrcona Also, pgtap is easy. :)
14:13 senator ah there it is, i see
14:13 tsbere senator: And that leads us into create_hold, which is where the targeter comes into play. I think the problem with hold *placement* is the "test" phase of that, the call to open-ils.circ.title_hold.is_possible call
14:13 Dyrcona senator: OK. I know we have some internal tickets, related to checkin, that we like to blame on holds code being slow but we've not figured out what exactly is the problem.
14:14 * graced thinks eeevil would be helpful about now...
14:14 * Dyrcona shuts up, so as not to confuse things.
14:36 rfrasur jeff++
14:38 Dyrcona So, another pgtap question.
14:39 Dyrcona What should I do with views that were altered by the upgrade script?
14:40 jeff as in, how should you test them?
14:41 jeff sorry, in the context of pg_tap, i suppose that was a silly question on my part.
14:42 * dbs doesn't understand the question
14:42 tsbere Dyrcona: I think you can do tests as though you would for a table (columns and types for the columns) - Beyond that you may want to look at ensuring test data is there and pulling from the view to ensure you got the correct info, maybe?
14:44 Dyrcona dbs: I'm working on tests for an upgrade script that alters existing view definitions. I'm also discovering that there is no easy way to check if a view definition (i.e. its underlying query) is correct.
14:44 Dyrcona jeff: Basically, yes.
14:44 Dyrcona Testing for the existence of the views is easy.
14:45 Dyrcona Testing it the view has or hasn't certain columns is also easy.
14:45 Dyrcona s/it/if/
14:45 csharp senator: https://bugs.launchpad.net/eve​rgreen/+bug/1272316/comments/4
14:45 pinesol_green Launchpad bug 1272316 in Evergreen "much slower holds processing in 2.4+" (affected: 2, heat: 10) [Undecided,New]
14:45 phasefx Dyrcona: test the views behavior with test data?
14:45 senator csharp++ kmlussier++
14:46 dbs Dyrcona: given that the view probably surfaced incorrect data before, and that's why it has been upgraded, wouldn't you just insert data into the underlying tables that you know would trigger the bad "before" case and test that the view now shows "good" data?
14:46 dbs what phasefx said, only more verbose :)
14:46 Dyrcona dbs: The views are being changed not because they were incorrect before, but because columns are disappearing from a base table.
14:47 tsbere Dyrcona: In that case I would mainly focus on "the view does not have the column that went away"
14:47 phasefx Dyrcona: I would still pick some data that exercised the boundaries of whatever query powered the view.. find data that should fall in and outside of the view
14:47 phasefx if it is indeed the query you're concerned with
14:50 jeff beyond testing a view for columns being present / not-present and testing data types of those columns, i think you have to use data to test the underlying query of a view.
14:50 Dyrcona phasefx: I'll give that some thought. Since we're talking about billing and 8 views (3 or which are only modified if they exist), that could be a lot of test data.
14:51 jeff i'm not sure that "view's definition is [SQL HERE]" is a good test.
14:51 Dyrcona jeff: I'm not sure "view's definition is ...." is easily done.
14:52 jeff i don't see a way, short of extending. i'm just saying "maybe there isn't an easy way because it's not a great test" :-)
14:52 phasefx when it comes to testing structure (which I think is not being advocated here), I think we could do that better / more centrally for everything
14:52 stevenyvr joined #evergreen
14:52 Dyrcona tsbere: Also, I don't recall at this point if the view columns changed. It may only be from statements in many cases.
14:53 Dyrcona jeff: I agree.
14:53 dbs SELECT definition FROM pg_catalog.pg_views WHERE schemaname = blah, viewname = blah; # but I agree with data view
14:53 Dyrcona Are there transactions in the concerto data, and are bills included?
14:54 Dyrcona If yes && yes, I may just test the views in live_t?
14:54 dbs Dyrcona: Yes, but you would need to run the fine generator to actually generate bills
14:54 dbs So no
14:54 jeff i am interested in having or creating sample bills and payments, fwiw.
14:55 phasefx care would have to be taken if we use the fine generator for test data, because of the day's date changing
14:55 jeff i have some pretty fun test cases from our live data. ;-)
14:56 Dyrcona dbs: (I am not knocking automated tests.) I think that speaks to my arguments about the complexity of testing things in a system as complicated and why automated tests will never catch everything.
14:56 jeff i think we could have bills and payments in the sample data without need for using the fine generator to create the bills.
14:56 Dyrcona jeff++
14:56 phasefx could and should

Results for 2014-01-23

11:42 Dyrcona It is theoretically OS agnostic now, the OS just has to support Firefox/Xulrunner.
11:43 rfrasur Hmm, has anyone experimented with Chrome OS?
11:43 Dyrcona In theory, yes, but it'll have all the usual browser compatibility issues.
11:43 jeff rfrasur: the current web prototype should run fine on a chromebook. i haven't tested it yet. your issues come down to printing support and rfid support (if applicable)
11:43 * rfrasur files this
11:43 Dyrcona @hate printing
11:43 pinesol_green Dyrcona: The operation succeeded.  Dyrcona hates printing.
11:43 jboyer-isl dbwells, jeff: Re: earlier today. Success! ccvm errors have been banished from our testing system.
11:44 Dyrcona jboyer-isl++
11:44 rfrasur I'd like to go exclusively to email receipts that that's not likely to happen in the near future...not here at least.
11:44 jeff i have put thought into printing from a web browser to a receipt printer on windows/linux/macos, but not yet put as much thought into printing to a receipt printer from a chromebook.
14:34 Dyrcona Also, should my version of pg_prove be the same as pgtap on the server?
14:35 * dbs has only run pg_prove on an all-in-one server install
14:36 jeff pg_prove seems capable of running from another host. it uses psql to connect.
14:36 Dyrcona All the tests are failing, and I don't think they should.
14:37 Dyrcona I'll play with the options a bit.
14:37 Dyrcona Parse errors: No plan found in TAP output
14:37 Dyrcona Leads to believe I should get a more recent pgtap?
14:38 dbs Which tests? What command are you running?
14:39 Dyrcona pg_prove t # from Evergreen/Open-ILS/src/sql/Pg
14:40 Dyrcona Ah, wait. Maybe pgtap is not actually loaded in the database I'm testing against.
14:42 stevenyvr joined #evergreen
14:42 Dyrcona I'll have to bug tsbere when he gets back to his desk.
14:44 jeff Dyrcona: first error in the output is usually more helpful than the errors in the Test Summary Report
14:44 bibliophylum joined #evergreen
14:45 Dyrcona jeff: Yeah. select plan(2) says plan() doesn't exist. I'm trying to figure out the parameters that I need to use psql on the server itself to load pgtap in my database.
14:45 jeff "Parse errors: No plan found in TAP output" can show for "i can't connect to postgresql", "there wasn't a database with that name", lack of plan() function, etc.
14:52 eeevil "but what if someone gains access to a shell on the system?" oh .. wait...
14:52 tsbere Dyrcona: No, it is allowed. If you talk TCPIP. You were talking socket. :P
14:52 Dyrcona jeff: No, I was running pgtap from another machine remotely, but tried to install pgtap from the database server.
14:52 jeff oh. got it.
14:53 jeff "You can't test in here! This is the database server!"
14:53 Dyrcona Ah, well. It's fixed with 'create extension pgtap schema public;' from the remote machine.
14:53 Dyrcona :)
14:53 Dyrcona Strangelove++
14:53 Dyrcona jeff++
14:53 ibogachenko joined #evergreen
14:54 Dyrcona Oh, and now that pgtap is installed in the target database, all of the tests pass.
14:55 jeff tests++
14:56 * Dyrcona finally gets around to writing pgtap tests.
14:56 tsbere and due to adding a similar statement to our copy of the database create script used for restoring backups for various purposes we don't have to worry about that in the future :D
15:00 Dyrcona Should I be concerned if the unbreak new encode test fails if I don't have the new version of Encode.pm?
15:02 jbfink joined #evergreen
15:06 dbs Dyrcona: maybe
15:07 csharp I see that libmarc-xml-perl-1.0.2 has made it to Ubuntu, but the deb is for the upcoming trusty release
15:11 gmcharlt if you don't mind mixing-and-matching package repositories, but are running Debian and would prefer a package over CPAN, 1.0.2 is available at http://debian.koha-community.org/
15:11 gmcharlt or you can grab it from sid
15:12 * Dyrcona wishes he had more time to figure out packaging to make his own PPA or whatever for Ubuntu, or join MOTU even.
15:24 dbs Dyrcona: hmm. well, I confirmed that the test still passes on new Encode, but sure is not good that it fails on old Encode.pm
15:27 * dbs wondered for a moment if MARC::Charset might be involved but I have 1.35 here
15:28 Dyrcona Ditto.
15:31 Dyrcona I can't upgrade Encode.pm on this server because it might cause our training database problems.
15:31 Dyrcona Our training Evergreen doesn't have the commit with the fix.
15:33 dbwells Dyrcona: Is this a totally fresh DB?  Anything which might cause a change to the MARC via triggers, such as varying config.internal_flag settings, or different org unit codes, could potentially cause this test to fail, as it requires the record be exactly as expected.
15:34 Dyrcona dbwells: It has a copy of our production data in it, so that must be it. We're using id for tcn.
15:42 rfrasur joined #evergreen
15:45 dbwells I could be wrong, but I think that is the default.  I wonder if just changing your top OU code to 'CONS' would let the test pass, since that gets inserted by maintaing_control_numbers?
15:46 Dyrcona Heh. That's Ok. I'll just accept that the test fails on my setup. :)
15:46 dbwells But you've got us all worried!  ;)
15:47 * dbs was going to ask if it was a stock db as well
15:47 dbs dbwells++
15:48 Dyrcona Suppose I could alter the test before running it to do the update...
15:48 jtaylorats joined #evergreen
15:57 dbs I suppose we could make the test more resilient by regex_replace'ing the 003/035/901 fields out before running the md5sum
15:57 dbs 001 too I guess
15:58 Dyrcona If it works on a brand new database, then I don't suppose it should change.
15:59 Dyrcona Maybe some notes to the effect that it will fail in a database that already has been configured.
16:13 jtaylorats joined #evergreen
16:16 jwoodard joined #evergreen
16:29 jeff hrm. incoming request that makes me think about merging reports and searching.
16:31 Dyrcona On pgtap tests: I guess those that go with upgrade scripts should have XXXX. in the name where the version would go, looking at the examples in Open-ILS/src/sql/Pg/t.
16:33 dbs Eh. My kneejerk reaction is that I don't think they should be tied to schema upgrades; just name what they're testing
16:35 eeevil dbs: I though there was some logic that used the numbers?  maybe not.  If not, I'd say tests generated by a schema change /could/ (but needn't necessarily) carry the same number, and tests that just get added shouldn't have a number at all
16:36 gmcharlt if we include any numbers at all in the filename, LP numbers would be the most useful in the long run
16:36 gmcharlt at leat for regression test
16:36 gmcharlt s
16:37 dbs eeevil: no logic that I'm aware of
16:37 dbs gmcharlt: yeah, lp numbers make sense for regress/ IMO
16:37 phasefx I did one test for an upgrade script as an example/experiment, but I'm not sure I'd like to continue that practice
16:37 Dyrcona Ok, sounds good to me.
16:37 dbs "that I'm aware of" is a great big qualification :)
16:37 Dyrcona After looking again, there is only that has an upgrade version number in the name.
16:38 Dyrcona I suppose we don't want tests to check that a particular version exists in config.upgrade_log?
16:38 phasefx part of me would like to see us use the make-pgtap script to encode the entire schema, and then start keeping that up-to-date
16:39 jbfink joined #evergreen
16:40 eeevil gmcharlt / dbs: that's fair. LP would be good, I agree
16:40 eeevil Dyrcona: I was actually imagining that /that/ might be (partially) there, thus the numbering that senator did for his test on my recent change (sorry for the git churn on that, btw, all)
16:40 gmcharlt eeevil: to be clear, I don't care much *how* the LP gets cited, but think that it should
16:41 gmcharlt test names would be another way to do it, e.g.
16:43 phasefx re: make-pgtap, the thought is that if you create an upgrade script that changes the schema, you'd also change a base set of tests that tracks the schema.  How useful that would be for everyone, I'm not sure.  Someone doing an upgrade could run the tests afterward to make sure it went well.  For developers, eventually we might have automation that compares the results of upgrade scripts to
16:43 phasefx pristine database installs (via those tests)
16:43 akilsdonk joined #evergreen
16:47 eeevil phasefx: not if I have /my/ way ;)
16:48 eeevil (no more moving-baseline)

Results for 2014-01-22

09:31 jcamins Dyrcona: "The Do-it-yourself library management game for the entire family"?
09:31 Dyrcona :)
09:31 Dyrcona jcamins++
09:31 graced My new favorite fast game is We Didn't Play Test This At All.
09:32 jcamins graced: lol
09:32 graced I think one of our rounds was over in 10 seconds.
09:32 dbs Monopoly: that's when you check out all of the latest Stephen King / George R.R. Martin copies to yourself
09:34 phasefx Cards Against Humanity is probably my favorite party game :D
09:34 graced And the phone app  Cards Against Manatees
09:34 paxed assuming "party game" means "needs to be played while intoxicated", then yes.
09:35 phasefx We Didn't Play Test This, would be my 2nd.  "Ah.. Zombies"
09:35 graced Ah Zombies gets me every time for some reason
09:36 phasefx graced++  I had forgotten the name of that game; I'm glad you mentioned it
09:36 graced phasefx: we should play it at lunch on this Friday
11:48 jtaylorats ""$user",public"
11:48 rfrasur Ben's cool.  Reading his "what I think he meant was" version.
11:50 rfrasur Hah!  Love the last line "Long-range plans are a big deal for Open Source..."
11:50 jtaylorats I've done a direct SQL insert as a test before I use the Copy option.
11:51 jtaylorats Insert worked fine.   It is when it goes to move it to the biblio.record_entry table that it triggers the failing functions.
11:52 dbs huh, the actual notifications doc url is at http://en.flossmanuals.net/evergreen-in-act​ion/sending-gentle-reminders-to-your-users/
11:53 jtaylorats Don't fix it...I may never find it again ;-)
11:53 dbs jtaylorats: "\df oils_xpath" doesn't show anything?
12:10 smyers_ joined #evergreen
12:11 jtaylorats Set that from the evergreen-dev schema?
12:11 jeff jboyer-isl: but that said, if the errors you've seen are those indexes failing to build (which can then be built after the pg_restore completes), it's likely unrelated to the issue jtaylorats has (though jtaylorats' issue might also be search path related :-)
12:11 jboyer-isl jeff: That would explain why our upgrade testing db is not performing as fast as expected.
12:11 csharp jtaylorats: (scrolling up) so "evergreen-dev" is a copy of your production database?
12:12 jtaylorats Yes.
12:12 csharp jtaylorats: then yes, try that
12:14 jtaylorats PL/pgSQL function "fingerprint_trigger" line 10 at assignment
12:14 jtaylorats SQL statement "INSERT INTO biblio.record_entry (marc, last_xact_id) VALUES (stage.marc, 'IMPORT')"
12:14 jtaylorats PL/pgSQL function "staging_importer" line 5 at SQL statement
12:14 jeff jboyer-isl: does your test db have an authority.by_heading index?
12:14 jtaylorats The error has changed a bit.
12:14 jtaylorats It showed more detail before.
12:15 jeff jboyer-isl: the indexes authority.by_heading and authority.unique_by_heading_and_thesaurus are the common ones to fail at pg_restore time due to search_path issues.
12:39 jtaylorats Well, sounds like I need to have them create a copy using a different method, assuming they did a dump/restore?
12:39 jtaylorats That sound right?
12:40 Dyrcona Oh. I was gonna say that we run a little script after pg_restore that fixes your problem.
12:40 jtaylorats then check to see if that function exists in the test database?
12:40 jtaylorats Works for me.
12:40 jtaylorats What script?
12:41 jtaylorats Will it insure that all the functions exist?   I assume this problem could exist on many fronts???
12:41 dbs Dyrcona: we could add that script to http://en.flossmanuals.net/evergreen-in​-action/care-and-feeding-of-evergreen/ for the logical backup section!
12:42 pastebot "Dyrcona" at 64.57.241.14 pasted "fix_database.sql" (6 lines) at http://paste.evergreen-ils.org/56
12:43 jtaylorats Is this related to my problem or jeff's?
15:06 jeff tsbere: which is why i'm using the exim logs -- they contain the email that we used. :-)
15:07 jeff tsbere: but if we went with VERP and handled delayed bounces, etc, I'd probably encode the email address we have in the envelope.
15:07 tsbere jeff: And how hard is it to say "fetch email from this patron by id, then pass it into said API, perhaps with the inclusion of the final bounce" ;) (also, the bounces I am concerned about are also the backscatter potential ones that are delevered from elsewhere)
15:08 dbs jeff: yes, ours too (now that our uni is cutting over to google apps). went so far as to send myself a test message to play with it. But OTOH I'm still morally opposed to HTML email :)
15:10 * tsbere also hates services that will strip anything that looks like one of their emails from the message, removes most of the headers from the message, and then wonder why you can't do anything to stop them from showing up again later, especially when multiple people got it and only one wants it to stop
15:12 jeff yup. email.
15:13 jeff dbs: and, contrats on groupwise -> google apps :-)

Results for 2014-01-21

11:38 bshum eeevil: see csharp's question --^
11:38 csharp our two staff tickets on the issue say "place hold button doesn't do anything"
11:39 eeevil csharp: you have staff creating adjustments, I take it
11:39 csharp eeevil: nope - we haven't tested the feature yet
11:40 csharp it was on our post-upgrade to-do
11:40 bshum Right, even out of the box, it's been kind of a nightmare.
11:40 eeevil it requires a permission: ADMIN_PROXIMITY_ADJUSTMENT
11:40 eeevil out of the box, it's empty
11:56 csharp ah
11:57 * csharp hasn't looked closely at the code to see what's what
12:02 Dyrcona It is on my ever-growing list of things to look at.
12:03 bshum csharp: I'm going to try asking my people for some specific example bibs that they've had trouble with and then run it through some tests on another server to see if I can get a longer output of what's going on in the behind the scenes.
12:03 bshum If you see anything interesting, I'd like to compare notes.
12:03 csharp yeah - that's what I'm doing now too - I'm not even sure of the opensrf call at this point though :-/
12:04 csharp in the logs, that is
12:13 jwoodard joined #evergreen
12:32 bshum dbwells: I just saw the notification about bug 1261939.  Fwiw, the branch worked when I was poking with it.
12:32 pinesol_green Launchpad bug 1261939 in Evergreen "Add per-library TPAC pages with schema.org structured data support" (affected: 1, heat: 6) [Wishlist,New] https://launchpad.net/bugs/1261939 - Assigned to Dan Wells (dbw2)
12:33 dbwells bshum: thanks for the report.  Looks good so far for me, hope to have it in today for the alpha cut tomorrow.
12:37 bshum dbwells: Cool deal, I was going to do one more test before I merged, but since you're on the case, I'll feel better knowing there were more eyes on it.
12:51 rjackson-isl joined #evergreen
12:57 mcooper joined #evergreen
13:04 Dyrcona jeff: "When you ride a lone, you ride with RDA!"
14:01 gmcharlt (that is, if you're currently running 0.93)
14:01 bshum csharp: I updated the bug with a comment and link to some working code switching -- https://bugs.launchpad.net/eve​rgreen/+bug/1271218/comments/3
14:01 pinesol_green Launchpad bug 1271218 in Evergreen "OPAC gives 'No Notification Preferences Are Configured' even when they are" (affected: 1, heat: 6) [Low,Confirmed]
14:02 bshum I have to test and see what happens if you do have opt-in settings configured.  But it should work, I think.
14:10 kmlussier csharp: Were you on 2.4 before your upgrade this weekend?
14:11 bshum I think they were on 2.3.
14:13 Dyrcona csharp: Is there an official maintainer for the library-related Perl packages on Ubuntu?

Results for 2014-01-19

09:40 jcamins You're welcome. I should probably do the same for the Koha repo on Github.
09:41 bshum csharp: Well, jt definitely bothered everyone who noticed the change back when for us that we'll be highly unlikely to stop reverting itbin our system.
09:41 jcamins Oh, looks like someone disabled the issue tracker in Github for Koha. Cool.
09:41 csharp yeah - the GPLS/PINES staff are internally testing 2.5 this morning and we're discussing it
09:41 bshum (bleh, typos.... too early on a Sunday)
09:41 csharp I think we'll probably do the same
09:42 * csharp doesn't care one way or the other, but in general changes to long-standing functionality mean lots more work for us
09:51 csharp other changes like this have been far more involved to fix
10:15 bshum @later tell dcook Quotes from the other night were from the movie Sneakers:  http://www.youtube.com/watch?v=3VlyZIywY9c  (around 1:23 in)
10:15 pinesol_green bshum: The operation succeeded.
11:00 * dbs spinning up a new Fedora 20 VM for commit testing & signoff
11:04 dbs somewhat amused that, starting with a minimal install that doesn't even have ifconfig installed, the opensrf makefile.install somehow pulls in vim and X
11:04 * dbs randomly blames ejabberd because, let's not kid ourselves, it is that source of most problems :)
11:05 dbs SDL. SDL!!!
11:11 dbs I was right about ejabberd, btw
11:11 dbs *sigh*
11:11 paxed *shudder*
11:22 jeff this is on fedora, right?
11:23 dbs yep
13:56 pinesol_green [evergreen|Dan Scott] More explicit database configuration instructions - <http://git.evergreen-ils.org/?p=​Evergreen.git;a=commit;h=965ebdc>
14:06 dbs oh goody, looks like "firewall-cmd --add-service=http; firewall-cmd --add-service=https" might be necessary for a minimal install of Fedora too
14:06 dbs *very* secure by default
14:18 pinesol_green [evergreen|Elliot Voris] LP104785: Selfcheck needs to be run with HTTPS - <http://git.evergreen-ils.org/?p=​Evergreen.git;a=commit;h=e382b99>
14:26 pinesol_green [evergreen|Pasi Kallinen] Move hard-coded style out of the copy status layout. - <http://git.evergreen-ils.org/?p=​Evergreen.git;a=commit;h=5c565f6>
14:42 pinesol_green [evergreen|Bill Erickson] New live test for fetching and update bre/MARC data - <http://git.evergreen-ils.org/?p=​Evergreen.git;a=commit;h=dc6e1e8>
17:29 dcook joined #evergreen
21:28 pinesol_green [evergreen|Galen Charlton] LP#1235474: fix failure of authority browse context menu to render - <http://git.evergreen-ils.org/?p=​Evergreen.git;a=commit;h=bb5a180>
22:28 pinesol_green [evergreen|Pasi Kallinen] Allow generating fixed data in control field 008 quickly - <http://git.evergreen-ils.org/?p=​Evergreen.git;a=commit;h=9286424>
22:28 pinesol_green [evergreen|Dan Scott] Create 008 - take only the first field/subfield combo - <http://git.evergreen-ils.org/?p=​Evergreen.git;a=commit;h=06ce842>
23:10 confidor joined #evergreen

Results for 2014-01-17

09:26 jtaylorats Some reading had indicated that it was also possible via Vandelay but maybe I misunderstood.
09:27 dbs jtaylorats: You can use vandelay to import the serial *bib* records, but I don't think it supports the associated mfhd records
09:28 dbwells Correct, there is no support for importing MFHD records in Vandelay.
09:28 * dbs hasn't really touched marc2sre.pl or the test data or the associated test data README since he put that stuff together for his own migration in 2009
09:29 jtaylorats Okay.   Appreciate the info.
09:30 jtaylorats Do you happen to know off the top of your head what table the info resides in?   I'm sure I can find it but am lazy enough to ask :-)
09:30 dbwells jtaylorats: the MFHD records are in serial.record_entry
14:36 jeff because what do you do with the rest of a payment when you're trying to attribute payments to billings? :-)
14:36 jeff (answer-for-now is likely to be "attribute with billing -1 and show a billing_type of OVERPAY)
14:37 jeff er, associate with or attribute to, likely not "attribute with"
14:48 jboyer-isl Has anyone seen a "_print_tree" error when accepting offline transactions? We're testing a 2.5 client and that's not a comforting thing to encounter.
14:49 jboyer-isl Fun fact: commenting out the try's and catch's in chrome/content/util/print.js allows it to work with no indication of an unhandled exception. :/
14:49 jboyer-isl (in the _print_tree function, that is)
14:50 bshum jboyer-isl: When you say "accepting offline transactions" what do you mean?
14:50 bshum Saving them in offline?  Uploading them?  Processing them?
14:51 jboyer-isl Sorry, that wasn't very specific. Clicking Save these transations with the Auto Print box checked.
14:59 jboyer-isl OH.
14:59 jboyer-isl But I set the offline_checkout template to force the receipt context, not offline.
14:59 jboyer-isl Oops.
15:02 mceraso dbwells: I just finished testing the release candidate for 2.5.2 using Ubuntu 12.04 LTS and everything works just fine
15:03 csharp mceraso++
15:05 dbwells mceraso++ # thanks!
15:06 mceraso Not a problem at all :) Always happy to help!
15:10 mmorgan jboyer-isl: csharp: Coming in late on this but we had exactly this issue when down for our 2.4 upgrade
15:10 mmorgan Setting the offline printer, totally exiting the client, then launching again worked - for most
15:11 mmorgan Some users reported they had to redo their printer settings, though, because they didn't seem to stick the first time
15:29 jboyer-isl Thanks mmorgan, we'll tell people they can test things ahead of time and hopefully it won't turn out to be a huge issue.
15:30 jboyer-isl (Though we all know better. <_< >_>)
16:11 BigRig_ joined #evergreen
16:14 BigRig__ joined #evergreen
16:16 BigRig joined #evergreen

Results for 2014-01-16

15:22 yboston gmcharlt++
15:22 StephenGWills gmcharlt++
15:22 montgoc1 gmcharlt++
15:25 pinesol_green [evergreen|Mike Rylander] Fix proximity adjustment calculator - <http://git.evergreen-ils.org/?p=​Evergreen.git;a=commit;h=a78bd1b>
15:25 pinesol_green [evergreen|Mike Rylander] Upgrade script - <http://git.evergreen-ils.org/?p=​Evergreen.git;a=commit;h=657e7f3>
15:25 pinesol_green [evergreen|Lebbeous Fogle-Weekley] Test for Mike's proximity adjustment fix two commits back - <http://git.evergreen-ils.org/?p=​Evergreen.git;a=commit;h=9a010a1>
15:43 eeevil calling 0852, because I'm dumb
15:47 pinesol_green [evergreen|Mike Rylander] Renumbering the upgrade script - <http://git.evergreen-ils.org/?p=​Evergreen.git;a=commit;h=9c7b271>
15:47 pinesol_green [evergreen|Mike Rylander] Renumbering the test - <http://git.evergreen-ils.org/?p=​Evergreen.git;a=commit;h=aec65bd>
15:49 pinesol_green [evergreen|Mike Rylander] And renaming the test - <http://git.evergreen-ils.org/?p=​Evergreen.git;a=commit;h=8c7731f>
15:56 akilsdonk joined #evergreen
15:57 mrpeters joined #evergreen
16:15 sseng joined #evergreen

Results for 2014-01-15

09:44 dbs I'm still shocked the browser people haven't come up with an <input type='autosuggest' src='json_feed'> standard widget
09:44 berick and rest assured when they do, IE won't support it for 8 years :(
09:53 * dbs was tempted to mess more with the OpenSearch functionality last night, e.g. to use the full name of the library rather than the shortname for the search engine widget, but realized that a) many libraries would have crazy long names and b) probably .05% people would actually use it anyway
09:55 bshum dbs: I haven't tested the latest branch, but remember fiddling with it back in the day. I think the only part that made me wary was how scoping could be applied if possible.
09:56 bshum I'll try it again when I get a moment to breathe.
10:02 kbeswick_ joined #evergreen
10:04 keynote2k joined #evergreen
10:04 dbs bshum: there are no real options for scoping; the code takes whatever your current search library is and uses that for the widget scope
10:05 bshum dbs: That might be why it wasnt entirely happy with me then. Our system is only making use of the pref_lib and doesn't set scope unless someone manually chooses something.
10:05 jwoodard joined #evergreen
10:06 dbs bshum: I'm not sure you tried this branch ever, as I'm sure it didn't exist until around midnight last night
10:06 bshum Well... Right. Fine, I'll just have to go test it now then. :)
10:06 dbs :)
10:07 * bshum should rename our top level someday from CONS...
10:14 bshum dbs: Ahh, I see.  The hostname stuff?

Results for 2014-01-14

11:22 hopkinsju It had an odd effect when viewing permissions in the staff client. Looking at the user permission editor the values in there seemed to all change their depth.
11:23 csharp yowza
11:24 jeff did you end up reverting those changes?
11:24 hopkinsju The documentation on adding new types wasn't super helpful so we were doing some trailblazing. Our initial testing looked ok, but we missed the inability to save users.
11:25 csharp hopkinsju: do the existing org unit types have 'can_have_vols' and 'can_have_users' set to true appropriately?
11:25 jeff because if it's possible to end up with a org type setup of ONE -> TWO -> THREE but have a first-level child of the root be of type THREE, I'll bet that breaks things.
11:25 hopkinsju jeff: We reverted them, but not in the technical sense. We removed the new types and changed the parent OU for the sub-branches.
14:48 stevenyvr joined #evergreen
14:54 dbwells grabbing 0851
14:54 hopkinsju joined #evergreen
15:08 pinesol_green [evergreen|Dan Scott] Encode.pm change to the UTF8 flag - <http://git.evergreen-ils.org/?p=​Evergreen.git;a=commit;h=796cf6b>
15:08 pinesol_green [evergreen|Dan Scott] Test Perl Unicode normalization process - <http://git.evergreen-ils.org/?p=​Evergreen.git;a=commit;h=d475ebc>
15:08 pinesol_green [evergreen|Dan Scott] Add pgTAP test for normalized MARC records - <http://git.evergreen-ils.org/?p=​Evergreen.git;a=commit;h=1da9b00>
15:08 pinesol_green [evergreen|Dan Wells] Upgrade file for Encode.pm 2.54+ changes - <http://git.evergreen-ils.org/?p=​Evergreen.git;a=commit;h=644f244>
15:08 pinesol_green [evergreen|Dan Wells] Stamping 0851 - changes for Encode.pm 2.54+ - <http://git.evergreen-ils.org/?p=​Evergreen.git;a=commit;h=ecbe401>
15:08 dbs dbwells++
15:09 rfrasur dbwells++
15:14 egbuilder build #446 of evergreen-master-fedora-18 is complete: Success [build successful]  Build details are at http://testing.evergreen-ils.org/buildbot/bu​ilders/evergreen-master-fedora-18/builds/446
15:15 RoganH dbwells++
15:20 dbs buildbot++
15:20 sandbergja joined #evergreen

Results for 2014-01-13

09:05 jboyer-isl Sigh. Has anyone seen this on a 2.5 release:  open-ils.storage.action.ho​ld_request.copy_targeter: Use of uninitialized value $min_prox in anonymous hash ({}) at /usr/local/share/perl/5.14.2/OpenILS/A​pplication/Storage/Publisher/action.pm line 1641.
09:05 bshum Yes, ignore it.
09:06 jboyer-isl That line is deep into the new_hold_targter
09:06 csharp jboyer-isl: yes - I've seen that on our 2.5.1 test server
09:06 jboyer-isl sub
09:06 jboyer-isl For every single hold processed?
09:06 csharp bshum: is there a bug on it?
14:49 Bmagic joined #evergreen
14:49 csharp well the system is completely down as far as our libraries are concerned
14:50 Bmagic Where does the staff client get the dropdown list of "depth" in the user permissions UI?
14:50 csharp I'm just trying to figure out when we should start plugging things back in and doing full out testing
14:50 bshum My understanding is that while reingests happen, you can search or whatever, but your results will vary significantly depending on which bibs have or haven't been ingested yet.
14:51 csharp Bmagic: config.org_unit_type? (not looking - that's from memory)
14:51 csharp org_type, maybe
14:52 csharp yeah - I'll be doing that too
14:53 bshum Since there's churn in the metabib tables and I like to keep things tidy.  The vacuum lock does kill things, depending on the type of vacuum you pick.
14:53 bshum So for that reason I tend not to turn on Evergreen till after I finish all my tasks.
14:53 csharp yeah, I'm moving to GIN indexes for the metabib tables too, so it sounds like vacuum becomes way more important with those
14:54 csharp that makes sense, I'm just trying to figure out if we can keep moving or if we just need to sit around for the 20+ hours our reingest will take
14:55 csharp + VACUUM ANALYZE
14:55 csharp well, it may be a shorter time - the hardware I'm testing on is about 1/4 the power of our production hardware
14:57 rfrasur (the sign that you've become a real manager/administrator is when you can tell an employee that you have no desire to fire them though they might technically deserve it, tell them that you've been grooming them for a full-time position, make them cry and NOT cry yourself)
15:22 jeff SIP2 is not a suitable means for vendors to validate patrons. :P
15:22 jeff (despite this, many vendors like to use it)

Results for 2014-01-11

10:20 sylvar And I'm still spellchecking, when I have time for it. Almost done. Of course, I started 3 months ago, so we'll see how much of it is still applicable.
10:41 csharp sylvar++
10:43 dbs sylvar++
11:05 csharp whoa - I just added a gin index for metabib.keyword_field_entry on one of our test servers and keyword searches are flying!
11:06 csharp it only took 16m to create the index - I was expecting longer
11:06 csharp totally gonna work that into the PINES upgrade next weekend
11:24 dbs GIN++ # what version of postgresql?
11:33 csharp this is 9.1
11:49 dbs Nice

Results for 2014-01-10

13:15 dbs eeevil: Oh, that README is bound up in a branch with the Encode.pm fixes
13:15 eeevil dbs: ah, well, that's a one-liner for me ...
13:15 eeevil ah!
13:15 dbs (Because I added more tests for the Encode stuff)
13:15 eeevil dbs++
13:15 bshum Ah, dbs++
13:15 dbs If we could merge that, we'd fix Fedora and get docs too.. *ahem* :)
13:15 bshum Can I mark an action item for someone (maybe eeevil to check that in?)
13:16 bshum #action eeevil to publish detailed plan about freezing baseline schemas between EG releases and using deprecates/supersedes in database upgrade scripts. This will go on the mailing list and the thread should structure further discussion of pros and cons of eeevil's plan.
13:16 dbs #info branch with pgTAP tests and Encode fixes is in https://bugs.launchpad.net/evergreen/+bug/1242999
13:16 pinesol_green Launchpad bug 1242999 in Evergreen "Encode.pm 2.54 breaks database functions (naco_normalize, maintain_control_numbers, others)" (affected: 1, heat: 10) [High,Confirmed]
13:16 dbwells I intend to re-review and push the Encode.pm stuff later today, or Monday at the latest.
13:16 dbs dbwells++
13:38 dbwells I changed the 2.next tag to 2.6.0-alpha earlier today.
13:38 bshum I'll take an action item to help do that.  Or give dbwells access to the google calendar to set it himself.
13:38 bshum (probably both actually)
13:38 egbuilder build #470 of evergreen-master-debian-6.00-x86_64 is complete: Success [build successful]  Build details are at http://testing.evergreen-ils.org/buildbot/builder​s/evergreen-master-debian-6.00-x86_64/builds/470
13:38 dbwells bshum++
13:40 bshum #action bshum to set new calendar entries for 2.6 milestone events and give access to dbwells to dev calendar.
13:40 bshum Okay, anything else before we move on?
13:42 bshum berick: floor is yours
13:42 bshum (to give to others)
13:42 berick yep, I'm wondering if there are any comments on the techincal bits, since feedback has been sparse so far.
13:43 ldwhalen I am concerned about the speed of Angularjs on older machines.  I am not sure if this is a valid concern because I have not done any testing.
13:43 akilsdonk joined #evergreen
13:44 berick ldwhalen: where does the concern come from?
13:44 bshum #link Prototype wrap-up report: http://yeti.esilibrary.com/d​ev/pub/web-staff-report.html
13:44 ldwhalen Angularjs is obviously doing a lot of work manipulating the DOM and passing information back and forth via the $scope object
13:45 RoganH I have done very limited testing.  I've done demos to get feedback from front line staff on our "spare" machine the front desk.
13:45 RoganH It's about a five year old low end intel with 2 gigs of RAM.  The demo at least ran very well on it.
13:45 berick so, my usual spiel on angular is that if we weren't using it, we would be doing all the same stuff manually w/ our own code (assuming a dhtml ui).
13:46 ldwhalen my concern is with a bad model and view implementation it might be slow.  I am not concerned with the current prototype.
13:46 gmcharlt anything can be too slow if coded badly
13:46 ldwhalen I want to idenitfy if there is a limit to chainging models and views in one screen and how we might avoid
13:46 dbs ldwhalen: Angular is extremely lean, as far as JavaScript frameworks go
13:47 ldwhalen alright.  I will go and test and come back if I have any concerns.
13:48 dbs berick: is bootstrap 2 or 3 in use? (Yes, I have not dived into the prototype code yet)
13:48 jeff ldwhalen++
13:48 berick ldwhalen: cool, testing very much appreicated
13:48 jeff dbs: it appears to be 3.0.1
13:49 * dbs looked and confirmed that too
13:49 Dyrcona My only question is: Are AngularJS and Bootstrap the final word on the staff client?
13:54 dbs berick: your report made no mention of printing support; any thoughts on that?
13:54 jboyer-isl (The non-IE support, that is_
13:54 dbwells berick: I think last I checked, you were using a third party integration of Angular and Bootstrap.  Is that still true?
13:54 ldwhalen I hope to rid myself of that concern with the testing
13:54 jeff I understand that bootstrap 3.x is not backward compatible with bootstrap 2.x, and that the effort involved in porting from 2.x to 3.x can vary by site/app, but can be significant. Does bootstrap 3.x have a stated/expected lifespan / support lifecycle?
13:55 berick dbs: it's covered more fully in the specs and original proposal:  printing and offline storage will be a separate project
13:55 berick dbwells: 3rd-party hosted, yes, that will have to change eventually, but it's easier for testing
13:56 berick jeff: good question.
13:56 dbwells berick: no, I mean the AngularUI stuff.  I think that is a third party, right?
13:56 berick dbwells: oh, yes, that is.
13:56 rfrasur Is this a meeting or general discussion?
14:10 gmcharlt keeping in mind that oldstable general is expected to go away a year after the release of the current stable
14:10 jeff +1 stable and oldstable
14:11 dbs +1 stable and oldstable
14:11 Dyrcona But, I think the question at hand is how do you support new stable on day one if you haven't started working with testing?
14:11 berick fwiw, i had wheezy patches on LP 6 months before it was released
14:11 berick give or take, i don't remember ;)
14:11 * csharp appears
14:12 gmcharlt Dyrcona: fair question; but yes, supporting stable does imply that folks exercise OpenSRF and Evergreen in testing beforehand
14:12 jeff it's probably time to start testing with testing/jessie. i'm happy to help.
14:12 csharp I think it would be reasonable to take a similar approach to ubuntu LTS and treat the old LTS like Debian oldstable and support it for a year after a new LTS release
14:12 gmcharlt jeff: just avoid running sudo apt-get install kaboom
14:12 * Dyrcona always installs kaboom.... It's so much fun. :)
14:13 jeff the idea being that we don't support testing until it's stable, but that devs have started incorporating support for testing into opensrf and evergreen before said debian release is released.
14:13 jeff i.e., we don't recommend running your evergreen system on a not-yet-released version of debian.
14:13 gmcharlt jeff: exactly
14:14 berick if the trend follows, we still have well over a year before jessie is out
14:14 dbs And we're not expected to shoehorn new-stable support into an old OpenSRF or Evergreen release, right?
14:19 csharp +1
14:19 bshum Okay.
14:19 Dyrcona When 12.04 came out, I tried to have it ready for the upcoming release in April.
14:19 gmcharlt bshum: I assume Ubuntu has some mechansim for providing the equivalent of a testing socket for an upcoming LTS?
14:20 Dyrcona That makes no sense.
14:20 Dyrcona What I said, not what gmcharlt said. :0
14:20 gmcharlt :)
14:20 bshum gmcharlt: I'm not sure, but I can try to find out.  Last time I just helped Dyrcona with testing things out over time.
14:21 csharp gmcharlt: yeah, you can usually be more or less stable on an LTS beta
14:21 csharp similar (much shorter) testing period than Debian testing
14:21 gmcharlt csharp: that sounds good enough
14:21 Dyrcona I started testing Evergreen with 12.04 right after the first alpha of 12.04.
14:21 csharp s/than/to/
14:22 Dyrcona I haven't started on 14.04, yet, and I agree with csharp that waiting for the beta may be reasonable.
14:22 * Dyrcona checks the release schedule.

Results for 2014-01-09

14:02 yboston kmlussier warned that she will not be ble to make it today
14:02 yboston (Happy new year to everyone)
14:02 remingtron looks like a small meeting
14:02 eeevil bshum: oh, the 2.4.5 RC is gold, just needs to be moved into place. never got a "tested, works" from anyone, which is why I didn't just push it out
14:03 rfrasur (happy new year as well)
14:03 * eeevil hushes for the dig meeting. sorry
14:03 yboston I will wait one more minute before starting our (small) meeting

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