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-targeter-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.hold_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.hold_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/evergreen/+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 |
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) |
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-action/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 :-) |
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/evergreen/+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? |
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 |
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 |
09:05 |
jboyer-isl |
Sigh. Has anyone seen this on a 2.5 release: open-ils.storage.action.hold_request.copy_targeter: Use of uninitialized value $min_prox in anonymous hash ({}) at /usr/local/share/perl/5.14.2/OpenILS/Application/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) |
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/builders/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/dev/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. |