| 09:07 |
berick |
this ticket wins the "first time make livcheck found a bug" award (for me) |
| 09:08 |
berick |
ironically, the code in question will almost certainly be replaced by direct pcrud calls in the future (if it hasn't already). |
| 09:09 |
dbs |
"make liver-check" might be useful during the conference |
| 09:10 |
jeff |
berick++ |
| 09:10 |
jeff |
tests++ |
| 09:10 |
dbs |
Do we have a documented set of tests / make targets to run for development & signoff? |
| 09:10 |
dbs |
make check && make livecheck? |
| 09:10 |
berick |
dbs: why look for something you don't want to find? |
| 09:11 |
* dbs |
can add that to http://wiki.evergreen-ils.org/doku.php?id=dev:signoff_review_checklist |
| 09:11 |
berick |
that was in response to liver-check, not signoff tests |
| 09:11 |
berick |
dbs++ |
| 09:11 |
berick |
jeff++ |
| 09:13 |
dbs |
added. not sure if anyone is actually looking at the review signoff list but occasionally people find the wiki :) |
| 09:14 |
jeff |
speaking of make check, does everyone else get a handful of warnings in metabib.pm? I dug just enough to see that the fix is probably simple and probably-simple (two different warnings, but one repeated several times), and confirmed that they weren't introduced by anything i was signing off on, but did not open a bug. |
| 09:15 |
berick |
jeff: yes, i get the warnings. |
| 09:15 |
* berick |
will gladly sign off if a fix is pushed |
| 09:15 |
jeff |
that checklist would have helped the other day when i forgot to bump the upgrade id in 002.schema.config.sql |
| 09:23 |
|
mrpeters joined #evergreen |
| 09:37 |
|
RoganH joined #evergreen |
| 09:42 |
|
yboston joined #evergreen |
| 09:49 |
jeff |
oh, i should start services before running make livecheck :P |
| 09:51 |
jeff |
and have the expected admin password... |
| 09:51 |
jeff |
i believe i've only run these from the uberscript |
| 10:04 |
jeff |
berick++ tests clean, pushed to master! |
| 10:05 |
pinesol_green |
[evergreen|Jeff Godin] LP#1187035 Remove OpenILS::Utils::Editor - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=0199ecd> |
| 10:05 |
pinesol_green |
[evergreen|Bill Erickson] LP#1187035 Remove OpenILS::Utils::Editor part 2. - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=bb222e7> |
| 10:05 |
pinesol_green |
[evergreen|Jeff Godin] LP#1187035 Remove OpenILS::Utils::Editor part 3. - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=8eda1c2> |
| 10:16 |
krvmga |
i am not able to duplicate the problem with ietester |
| 10:18 |
berick |
wonder if it's the same as bug 1002971 |
| 10:18 |
pinesol_green |
Launchpad bug 1002971 in Evergreen "tpac: library names are cut off in library selector when using IE" (affected: 2, heat: 10) [Medium,Confirmed] https://launchpad.net/bugs/1002971 |
| 10:19 |
bshum |
berick: Well that bug notes that it doesn't affect IE9 in my testing. |
| 10:20 |
berick |
ah |
| 10:20 |
bshum |
My first kneejerk reaction for krvmga is to check that one of your bricks isn't malfunctioning with a bad dropdown. |
| 10:22 |
bshum |
krvmga: Also, for those of us who don't follow religiously, it helps to know what version of Evergreen you're on :) |
| 12:55 |
fparks_ |
eeevil: I do see the fr-CA locale poping up in other parts of the log |
| 12:56 |
* eeevil |
grabs 0860 |
| 12:56 |
paxed |
fun for the whole consortium! |
| 13:02 |
pinesol_green |
[evergreen|Bill Erickson] DB patch supersede/deprecate logic repairs; unit tests - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=b7f0b1d> |
| 13:02 |
pinesol_green |
[evergreen|Mike Rylander] Stamping upgrade script for supsersede/deprecate logic fixes - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=4be7952> |
| 13:04 |
jeff |
29 fix committed |
| 13:05 |
eeevil |
fparks_: without seeing the code that's failing, I couldn't say why it's not picking up the in-use locale while other parts of the system seem to be, based on what you say about the logs |
| 13:10 |
eeevil |
I'd like to get more eyes on this chunk of plpgsql, because either I'm misunderstanding it, or it's doint the wrong thing: |
| 15:01 |
eeevil |
+1 # march is still a ways of! ;) |
| 15:10 |
jeff |
+1 to extension |
| 15:21 |
berick |
crazy. just hit 60 degrees and there's still a large patch of (thin) snow outside the window. |
| 15:23 |
jeff |
i think i just confused the conditional negative balance branch by violating its assumptions. |
| 15:24 |
jeff |
checked something out, set its due date back a ways, ran fine generator, made some payments, did a backdated checkin. |
| 15:24 |
jeff |
i suppose that's an unfair test, and i think our local branches have suffered similar fates before. |
| 15:25 |
jeff |
but this brings up a good question: what is a recommended method of testing overdues -- manually create the checkout many days ago? |
| 15:25 |
* jeff |
goes to see what make livecheck does |
| 15:25 |
berick |
jeff: the seed data has some overdues in it |
| 15:25 |
jeff |
my usual trick is the above, check out and then set a due date in the past (which means it becomes due before checkout), then run fine generator. it works for many things until it doesn't. :-) |
| 15:27 |
jeff |
okay, livecheck rewrites history with open-ils.cstore.direct.action.circulation.update |
| 15:27 |
jeff |
still "cheating" (what tests aren't?) but results are cleaner. |
| 15:46 |
|
stevenyvr joined #evergreen |
| 15:59 |
|
Dyrcona joined #evergreen |
| 16:11 |
|
dMiller_ joined #evergreen |
| 16:59 |
Dyrcona |
Yeah, you could say that the ILS market is actually a functioning, competitive market. |
| 17:00 |
eeevil |
dbwells / berick: please see the top of http://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/collab/miker/lp1053397-tpac-metarecords-r5 |
| 17:01 |
* berick |
takes a look |
| 17:02 |
eeevil |
berick: to see it in action, your test server has it in place already |
| 17:02 |
jcamins |
Dyrcona: let's not go overboard. Have you seen some of the ILSes out there? :P |
| 17:02 |
eeevil |
evergreen=# select metabib.reingest_record_attributes(id,'{icon_format}'::TEXT[],marc,false) from biblio.record_entry where id > 0 and not deleted; |
| 17:02 |
eeevil |
Time: 477.551 ms |
| 17:03 |
berick |
eeevil: thanks. i'll install on a new DB though, to test the baseline as well |
| 17:03 |
eeevil |
berick: fair :) |
| 17:03 |
Dyrcona |
jcamins: Yes, they all suck, some just suck less. :) |
| 17:04 |
pastebot |
"berick" at 64.57.241.14 pasted "for eeevil :)" (17 lines) at http://paste.evergreen-ils.org/22 |
| 17:05 |
eeevil |
well that's fun |
| 17:05 |
eeevil |
I wonder why it works on the test db... |
| 17:09 |
eeevil |
berick: pushing the fix... just RETURN NULL; |
| 17:09 |
berick |
ah |
| 17:09 |
eeevil |
pushed |
| 17:10 |
eeevil |
well |
| 17:10 |
eeevil |
ing |
| 17:10 |
eeevil |
pushd |
| 17:10 |
berick |
thanks, running again |
| 17:11 |
|
mmorgan left #evergreen |
| 17:18 |
berick |
works well. memory looks good. full re-ingest still takes longer (but i'd be shocked if it didn't). |
| 17:18 |
berick |
though speed is considerably improved |
| 17:19 |
berick |
master = 17 seconds; old MR branch = 50 seconds; new MR branch = 30 seconds. |
| 17:19 |
berick |
on my test vm |
| 17:19 |
eeevil |
ah, I should have said that full attr reingest (all we need for the upgrade to this) only takes 10s |
| 17:19 |
eeevil |
not full marc dance |
| 17:20 |
berick |
that's what I thought you meant |
| 11:14 |
phasefx |
tsbere: do you have some easily shareable comparisons of output? |
| 11:14 |
tsbere |
phasefx: Gimme a min |
| 11:16 |
phasefx |
I don't have a good handle on how dewey and generic differ at the moment |
| 11:19 |
tsbere |
Hmmm |
| 11:20 |
* tsbere |
notes an issue with the true/false bit, he tested with 1/0 in a pl file but forgot the DB doesn't do that with boolean values |
| 11:22 |
tsbere |
easily fixed. <_< |
| 11:26 |
tsbere |
phasefx: I added example callnumbers to the end of the paste and what the original and "new" variants spit out for them |
| 11:26 |
phasefx |
cool deal |
| 11:44 |
|
mrpeters joined #evergreen |
| 11:45 |
|
mrpeters left #evergreen |
| 14:37 |
jcamins |
Well... unless I collapse each record into a single line. |
| 14:37 |
Dyrcona |
jcamins: sed works just fine over multiple lines. |
| 14:38 |
Dyrcona |
jl-: Can you program in Perl? |
| 14:38 |
jcamins |
Dyrcona: that would be an example of something about sed which I did not know. I may have to find a use to test this. |
| 14:38 |
jcamins |
*reason |
| 14:39 |
jl- |
grep -c '\="012"' ship_all.xml |
| 14:39 |
jl- |
3111 |
| 14:40 |
Dyrcona |
@marc 012 |
| 16:04 |
jl- |
jcamins or jeff |
| 16:05 |
Dyrcona |
jl-: If you have tags like sou in your file, they aren't valid, either. |
| 16:05 |
Dyrcona |
jl-: What ILS did these records come from? |
| 16:05 |
jl- |
root evergreendev:/openils/Evergreen-ILS-2.5.1/Open-ILS/tests/datasets/sql# grep -c 'tag="sou"' bibs_concerto.sql |
| 16:05 |
jl- |
1 |
| 16:06 |
jl- |
Dyrcona: to be honest, the more I am working on them the more I think these records are shit.. they are from voyager but it also depends on the librarians how clean |
| 16:06 |
jl- |
they handle their records |
| 16:06 |
Dyrcona |
jl-: All MARC records are shit. |
| 16:06 |
jl- |
I was able to import the first 50000 |
| 16:06 |
jl- |
:) |
| 00:15 |
pinesol_green |
[evergreen|Pasi Kallinen] Fix some javascript errors, trying to access nonexistent widgets - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=fbb73c7> |
| 00:20 |
|
remingtron__ joined #evergreen |
| 00:24 |
|
fparks joined #evergreen |
| 00:47 |
bshum |
@later tell eeevil I was perusing new working branches and saw what you put in earlier today (user/miker/avoid-dupe-hold-on-list). Potential solution for old bug https://bugs.launchpad.net/evergreen/+bug/1046026 ? Tested and it does look... better! Exciting! :D |
| 00:47 |
pinesol_green |
bshum: The operation succeeded. |
| 00:47 |
pinesol_green |
Launchpad bug 1046026 in Evergreen 2.4 "Pull list shows multiple rows for same hold/copy" (affected: 5, heat: 26) [Medium,Confirmed] |
| 02:04 |
|
stevenyvr joined #evergreen |
| 13:49 |
eeevil |
jeff: did you get a chance to look at bug 1271630 yesterday? |
| 13:49 |
pinesol_green |
Launchpad bug 1271630 in Evergreen "Allow Located URIs to supply copy-like visibility to bibs" (affected: 1, heat: 6) [Wishlist,In progress] https://launchpad.net/bugs/1271630 - Assigned to Jeff Godin (jgodin) |
| 13:50 |
|
jihpringle joined #evergreen |
| 13:52 |
jeff |
eeevil: yes and no. rolling it into some testing i'm starting right now. |
| 13:56 |
yboston |
heads up the DIG monthly meeting will start at 2 PM EST |
| 14:00 |
yboston |
#startmeeting 2014-02-13 - DIG Monthly Meeting Evergreen Documentation Interest Group (DIG) Monthly Meeting. |
| 14:00 |
pinesol_green |
Meeting started Thu Feb 13 14:00:50 2014 US/Eastern. The chair is yboston. Information about MeetBot at http://wiki.debian.org/MeetBot. |
| 14:46 |
dbs |
jeff: you apt-get update && apt-get dist-upgrade'd first? |
| 14:49 |
jeff |
yep. |
| 14:50 |
* gmcharlt |
adds a step to release-cutting today |
| 14:50 |
phasefx |
jeff: there's one unitialized value in http://testing.evergreen-ils.org/~live/test.11.html Doesn't look fatal; that's a wheezy system |
| 14:51 |
jeff |
got it. so likely unrelated to that debian bug, and it's the later syntax error that i should dig at next |
| 14:55 |
dbs |
you have "check" installed? |
| 14:55 |
berick |
dbwells: fyi, the tpac / metarecords templates might need some conflict resolution for master after the wcag merge. going to look at that soon |
| 15:23 |
* dbs |
only gets an extend_reporter.sql error if he tries creating the schema without dropping the database first |
| 15:23 |
* dbs |
is not seeing any error output from seed data |
| 15:24 |
jeff |
jboyer-isl: and to answer your original question, dunno about bug reporting. i've usually stuffed a branch on github and pointed gmcharlt at it. |
| 15:24 |
dbwells |
dbs: are you testing in collab/berick/lp1053397-tpac-metarecords-r4, or master? |
| 15:25 |
gmcharlt |
jboyer-isl: jeff: and that will work for now |
| 15:25 |
jboyer-isl |
jeff: thanks. I'll probably do something similar. (or email a patch, it's maybe 30 chars...) |
| 15:25 |
dbs |
hah, master! |
| 15:30 |
berick |
dbwells: sorry about that. fix pushed to collab/berick/lp1053397-tpac-metarecords-r4 |
| 15:30 |
jeff |
jboyer-isl: this is how i addressed te floating issue: https://github.com/tadl/evergreen-contrib-equinox/compare/fix_floating_bool_now_int?expand=1 |
| 15:30 |
* berick |
checks the templates |
| 15:30 |
jeff |
gmcharlt: irc pullrequesting that commit. :-) |
| 15:31 |
jeff |
gmcharlt: fwiw, i have not tested that change on pre-2.5, but it fixed our extracts on 2.5. |
| 15:31 |
jboyer-isl |
jeff: thanks, I'll grab that for our next run. |
| 15:32 |
jeff |
bah. two typos in commit message. :P |
| 15:32 |
jeff |
(at least) :P |
| 18:43 |
bshum |
berick: Question for you |
| 18:44 |
bshum |
I'm looking at 161815ed and trying to figure out why the clear:both is commented out for .adv_filter_block |
| 18:44 |
pinesol_green |
[evergreen|Bill Erickson] LP#1268636 advanced search repairs - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=161815e> |
| 18:44 |
bshum |
Without that, the advanced search filters don't break up into separate rows like it used to. |
| 18:45 |
bshum |
Maybe just something tiny that snuck in accidentally |
| 18:46 |
bshum |
Mainly only a quirk on specific resolutions and groups of filters. |
| 18:47 |
bshum |
Like our first row of filters only has three in it, and then four in the next group of filters. So it should have split into two separate rows. |
| 18:47 |
bshum |
But on my test server, it all ended up on a single line |
| 18:47 |
* bshum |
does some more testing |
| 19:02 |
|
senator joined #evergreen |
| 19:08 |
|
senator joined #evergreen |
| 19:44 |
dbs |
bshum: I didn't see that behaviour with stock config--with the exception of the final row + sort options |
| 19:51 |
bshum |
dbs: I'm guessing it has something to do with the more filters you have per row. |
| 19:51 |
bshum |
That said |
| 19:51 |
bshum |
Now I'm not sure |
| 19:52 |
bshum |
Cause I don't see that in stock either... |
| 19:52 |
* bshum |
goes poking at his test server... WHY YOU NO WORK?! |
| 19:52 |
* dbs |
chuckles |
| 19:53 |
* dbs |
waits for koha clone to finish cloning |
| 19:56 |
bshum |
Oh, my master server isn't quite up to speed.... it's still a few days older than all the other changes. |
| 09:09 |
jl- |
ohai |
| 09:15 |
phasefx |
yo gozaimasu |
| 09:17 |
|
mmorgan joined #evergreen |
| 09:21 |
bshum |
@later tell talexander I was just reading the admin archive of recent messages and wonder what server specs your test machine has. My kneejerk reaction is that maybe you're under 2 GB of memory and the system is killing you as you try logging into Evergreen. |
| 09:21 |
pinesol_green |
bshum: The operation succeeded. |
| 09:21 |
* bshum |
still hates the evergreen-admin list |
| 09:22 |
|
dluch joined #evergreen |
| 12:20 |
jl- |
I used the concerto loader |
| 12:24 |
jl- |
dbs dbwells |
| 12:27 |
|
jihpringle joined #evergreen |
| 12:37 |
sseng |
hello. rebuilt master this morning and getting this error when doing a browse search : "An error occurred browsing records. Please try again in a moment or report the issue to library staff." |
| 12:37 |
sseng |
anyone getting this error? just wanted to make sure it not my test environment (tried rebuilding several times and getting similar errors) |
| 12:51 |
|
Wyuli joined #evergreen |
| 13:00 |
bshum |
sseng: I got that error on one of my master servers too. Might be string_agg changes dbs? |
| 13:00 |
bshum |
Also, airport signal sucks. |
| 14:19 |
jeff |
dbwells: would you like an action item for adding RM dates to the dev calendar? |
| 14:19 |
jeff |
#link http://www.google.com/calendar/embed?src=tfm2bbqnt7q890jidnqe3u29j4%40group.calendar.google.com&ctz=America/New_York |
| 14:19 |
dbwells |
eeevil: I can do the backport when I do rel_2_5, as long is you are fine with it going in. |
| 14:19 |
eeevil |
dbwells: with all the tests I'm fairly comfortable, fwiw |
| 14:19 |
eeevil |
dbwells: if you're offering, sure thing! :) |
| 14:19 |
eeevil |
(comfortable with a backport generally) |
| 14:19 |
dbwells |
eeevil: yes, no problem |
| 14:19 |
dbwells |
jeff: Why not |
| 14:19 |
jeff |
#action dbwells to add RM dates to dev calendar |
| 14:44 |
* dbs |
is working on the known STRING_AGG() text-casting at least |
| 14:44 |
gmcharlt |
it would be a pain, but this is one area where I think I trust ourselves more than I trust the Pg devs |
| 14:44 |
|
gsams joined #evergreen |
| 14:45 |
dbs |
gmcharlt: that doesn't sound too crazy to me. either way, with some pgTAP tests to ensure that the results are consistent across versions |
| 14:45 |
|
ericar_ joined #evergreen |
| 14:45 |
jeff |
gmcharlt: do you expect performance pain in addition to transition pain, or does this fall under the umbrella of "if we're xpath'ing too much, we're already doing something wrong"? |
| 14:45 |
gmcharlt |
tradeoffs might include performance and/or the time of maintaining our own extensions if we decide to write C instead of Perl to wrap around libxml2/libxslt |
| 08:54 |
|
jwoodard joined #evergreen |
| 08:54 |
csharp |
jboyer-isl: 37 is what I get on PINES prod (2.5.1) |
| 08:56 |
csharp |
I guess I don't know what I'm looking at here, though :-/ |
| 08:56 |
dbs |
berick: yeah, I was testing with a user that had fines. And they didn't show up properly (there were a couple of little squares floating below the actual fines box) |
| 08:56 |
jboyer-isl |
That table maps indexed fields to normalizing functions. So it says to run a date normalizer against the date type fields, etc. |
| 08:57 |
dbs |
berick: so arguably my commit to remove those divs is very much a bug fix :) |
| 08:57 |
csharp |
jboyer-isl: ah - I see |
| 09:01 |
csharp |
I know we have some custom metabib fields |
| 09:01 |
jboyer-isl |
csharp: I think it's from around the 2.0-ish area. Even if it were audited we'd both be in the dark by now. |
| 09:01 |
csharp |
yeah |
| 09:03 |
* dbs |
needs to build some pgTAP tests for further STRING_AGG() / 9.3 type strictness tweaks |
| 09:03 |
jboyer-isl |
csharp: Now I'm even more curious what this looks like at PINES: select id,field_class,name,xpath from config.metabib_field where id < 1000 order by id; |
| 09:04 |
jboyer-isl |
If you've got time, of course. |
| 09:05 |
pastebot |
"csharp" at 64.57.241.14 pasted "select id,field_class,name,xpath from config.metabib_field where id < 1000 order by id;" (36 lines) at http://paste.evergreen-ils.org/19 |
| 11:50 |
gmcharlt |
bshum++ |
| 11:55 |
|
mrpeters joined #evergreen |
| 12:09 |
|
jtaylorats joined #evergreen |
| 12:10 |
yboston |
jeff: thanks for the tip, still looking at it. Though I want to pull in a specific custom GooGle map. Not sure if I can do that yet. Need to write a test HTML page |
| 12:10 |
yboston |
dbs: thanks for the tip. I will look at this too |
| 12:10 |
jtaylorats |
Greetings....another, hopefully, quick question....The instructions on this page, at the bottom, says running the indicated script will provide a "pristine" database. |
| 12:10 |
dbs |
yboston: I can help if desired |
| 12:10 |
jtaylorats |
http://wiki.evergreen-ils.org/doku.php?id=evergreen-admin:importing:bibrecords |
| 14:35 |
|
stevenyvr joined #evergreen |
| 14:37 |
|
roses joined #evergreen |
| 14:39 |
|
ericar joined #evergreen |
| 14:39 |
roses |
I have a test demo server that I just installed 2.5.2 on (couldn't get it to upgrade from 2.3.7 cleanly) - it work working - could get to my staff client etc until yesterday when I installed pgAdmin III and to make that work I had to mess around with two files - /etc/postgresql..../postgresql.conf and pg_hba.conf - anyway I was able to get into pgadmin but now am not able to get into staff client? |
| 14:40 |
bshum |
roses: Err, if you were messing with those two files, I assume you had to restart/reload postgresql to apply changes. |
| 14:40 |
bshum |
roses: Did you restart osrf services after you did that? |
| 14:40 |
bshum |
And apache if you're restarting osrf services... |
| 09:24 |
AaronZ-PLS |
We have a library who managed to scan a barcode into Staff client/Patron details/Bills/Receipt Options/Number of Copies. |
| 09:24 |
AaronZ-PLS |
Where does EG store that setting in 2.2.1? |
| 09:24 |
AaronZ-PLS |
Theoretically, they could change it by hitting the down button (you cant type into the field), but hitting the down button more than 52000000000000 times seems somewhat over the top. |
| 09:24 |
AaronZ-PLS |
I tested it myself and I cant type in that box, but I can scan in some barcodes, ie:"US060TF7535903BCABD9" (PN from a Dell DVD) works, but "A00" (revision # from the same DVD) doesnt. |
| 09:25 |
phasefx |
AaronZ-PLS: try pulling up Admin -> For Developers -> about:config, filter on persist, and scroll through the results |
| 09:27 |
phasefx |
filtering on receipt_upon_payment should get you closer |
| 09:27 |
AaronZ-PLS |
phasefx: Thanks. Looks like its oils_persist_evergreen.owwl.org_bill2.xul_num_of_receipts_value |
| 13:45 |
|
Rish joined #evergreen |
| 13:46 |
|
Rish joined #evergreen |
| 13:47 |
|
Recky joined #evergreen |
| 13:47 |
jboyer-isl |
Good to hear. I'm going to try it against our test database and see how hard the cleanup will be. |
| 13:48 |
jboyer-isl |
Edited to correct our situation, obviously. |
| 13:50 |
jeff |
monitoring and logs... can you ever have enough? |
| 13:50 |
jeff |
good panel discussion. |
| 13:52 |
jeff |
everybody introduces themselves, everybody agrees you can never have enough logs, monitoring, automation, or testing (or automated testing, or automated monitoring (because really, should there be any other kind?)), panel discussion over. |
| 13:52 |
dbs |
Entire panel automatically monitored and logged by the NSA |
| 13:53 |
jboyer-isl |
jeff: I think you're forgetting the part where everyone argues that 75% of what the other panelists are doing misses critical issues. |
| 13:53 |
jeff |
jboyer-isl: that's the post-panel discussion, over everyone's choice of drink. |
| 13:54 |
jeff |
jboyer-isl: besides -- what is the answer to monitoring/testing/logging/automating the wrong thing? the answer is monitoring/testing/logging/automating MORE THINGS! |
| 13:54 |
dbs |
And then everyone goes off to build a new integrated automatic log monitoring system (IALMS) |
| 13:57 |
jboyer-isl |
Ugh. Not a fan of log monitoring. I'd rather poke at live state. (I say this having just developed a local feature that necessitates log monitoring...) |
| 13:57 |
jeff |
what local feature? |
| 14:00 |
jboyer-isl |
Using a payment processor I like so little I'm not submitting the code to core. There's a chance that if an authtoken is lost in memcache that the payment can still proceed but we don't know where to apply it. So something has to scan our osrfsys logs for SIREN.GIF and start sending urgent emails if that happens. |
| 14:00 |
jboyer-isl |
The moral of the story is test and use Stripe. :) |
| 14:01 |
jboyer-isl |
Just noticed I left out a "that" in that explanation. Suffice it to say that due to circumstances beyond my control, using a different provider is out. |
| 14:01 |
tsbere |
That sounds possibly problematic. What if the gif isn't requested due to other things (like someone turning off images)? |
| 14:01 |
jboyer-isl |
but that's no reason anyone else should use it. |
| 14:01 |
jeff |
oof. |
| 14:05 |
csharp |
ok - that's how I thought it worked. |
| 14:05 |
csharp |
thankks |
| 14:05 |
csharp |
tsbere++ |
| 14:06 |
tsbere |
csharp: Note I haven't *tested* any of this, this is based on my knowledge of the fine generator and some assumptions. ;) |
| 14:14 |
jl- |
I'm trying to bulk import in /test/datasets/sql with a 700mb file (17 million lines) but I get |
| 14:14 |
jl- |
psql:bibs_concerto.sql:17580472: ERROR: out of memory |
| 14:14 |
jl- |
DETAIL: Failed on request of size 268435456. |
| 14:15 |
jl- |
any suggestions? I'm gonna give the VM more memory but it already has 4 GB |
| 14:16 |
Dyrcona |
4GB is nothing these days. |
| 14:16 |
Dyrcona |
Evergreen is barely usable with no data in about 2GB. |
| 14:17 |
jl- |
I'm hoping that this means my import file has been sanitized correctly |
| 15:44 |
Bmagic|2 |
phasefx: I see, I appreciate it! |
| 15:46 |
phasefx |
jl-: you could use the perl module MARC::Record to read in the file and spit it out chunked. Would give you a heads-up on problematic MARC in the process |
| 15:51 |
jeff |
or yaz-marcdump as dbs recommended earlier. |
| 15:52 |
jl- |
phasefx as far as I can tell I already sanitized it to be sucked into the bibs_ machine in /tests/datasets/sql |
| 15:52 |
jl- |
I just get a connection lost at the end |
| 15:52 |
jl- |
atmittidly it's 17 million lines of records |
| 15:52 |
jl- |
about 200 000 records |
| 15:54 |
phasefx |
the Equinox migration_tools repository has a perl script called marc_cleanup (or something similar); it'll spit out one xml record per line; you could then use the split command on it |
| 15:55 |
jl- |
can I specifiy how many records per file? |
| 15:55 |
jl- |
or will I end up with 200 000 files |
| 22:05 |
|
jeff joined #evergreen |
| 22:07 |
|
ldwhalen joined #evergreen |
| 22:12 |
|
ldwhalen joined #evergreen |
| 22:25 |
dbs |
berick: I'm firing up a testing vm for the wcag commits. I bet you felt dirty letting that 4-image border for the fine box go through :) |
| 22:47 |
dbs |
Hmm. On Chrome I just deleted the offending divs and it didn't change the look one bit |
| 22:47 |
* dbs |
tests further |
| 10:13 |
dbs |
hmm. seeing the same problem as bhsum reported on ubuntu |
| 10:14 |
* dbs |
rattles the git tree to see what he can shake out of the branches |
| 10:30 |
bshum |
dbs: I think it has something to do with the scripts being referenced twice in the Makefile, but I'm not 100% sure yet. |
| 10:31 |
dbs |
eeevil: you see the "metabib.author_field_entry is getting 'name, name creator' additional entries" bug yet? |
| 10:31 |
dbs |
bshum: yep, I just pushed a fix |
| 10:31 |
dbs |
but testing it out on ubuntu and fedora with and without --prefix to be sure |
| 10:32 |
bshum |
dbs++ |
| 10:33 |
bshum |
I'll take a poke at it again later this evening. Gotta jet off for a bit. |
| 10:34 |
dbs |
and works, yay |
| 10:35 |
eeevil |
dbs: i doubt it. it's certainly a simple index def adjustment. is it causing problems for you, or just an annoyance? (afk for a while) |
| 10:35 |
dbs |
bshum++ # good jetting |
| 10:35 |
eeevil |
s/i doubt it/i have not/ |
| 10:36 |
dbs |
eeevil: it's an index bloat / inaccurate search thing - affects both 9.1 and 9.3, so yeah, index def adjustment |
| 10:36 |
dbs |
index bloat because you get approximately twice as many rows, inaccuracy because "creat*" |
| 10:42 |
dbs |
looks like we want to grab /name/namePart but not /name/role... fun fun |
| 10:43 |
dbs |
per http://laurentian-test.concat.ca/opac/extras/supercat/retrieve/mods32/record/1198543 and //mods32:mods/mods32:name[@type='personal' and mods32:role/mods32:roleTerm[text()='creator']] |
| 10:48 |
pastebot |
"bshum" at 64.57.241.14 pasted "show more details log error" (5 lines) at http://paste.evergreen-ils.org/15 |
| 10:48 |
* bshum |
fails at jetting |
| 10:48 |
dbs |
ah, sonofa |
| 11:10 |
bshum |
I see now |
| 11:10 |
bshum |
cd056eba75038c6a1fabd2a83ba97d81a444bc75 |
| 11:10 |
pinesol_green |
[evergreen|Ben Shum] Fix copy_info variables for result and record view - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=cd056eb> |
| 11:11 |
bshum |
When I wrote that, what was really wrong was that record/copy_table.tt2 should never needed anything for the variables |
| 11:11 |
bshum |
We could nix it from there cause the copy_info is already set there. So my change did nothing to it. |
| 11:11 |
bshum |
Since copy isn't referenced |
| 11:11 |
bshum |
I think? |
| 11:12 |
bshum |
But when we flipped around the variable in results, it broke the display :\ |
| 11:12 |
* bshum |
fiddles around |
| 11:16 |
bshum |
dbs: Commit here seems to fix it on my test system: http://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/bshum/fix-copy-info-again |
| 11:16 |
bshum |
I think I've got it sorted out this time :( |
| 11:39 |
pinesol_green |
[evergreen|Dan Scott] Address some remaining hardcoded install prefixes - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=aa8ea3c> |
| 11:40 |
eeevil |
dbs: re creator, I think we'll want a search_xpath to do the same thing as facet_xpath and browse_xpath ... i've no time today, though. i'll toss it on my community day pile |
| 13:07 |
jl- |
good afternoon |
| 13:25 |
jl- |
just installed a fresh copy of evergreen on a VM |
| 13:25 |
jl- |
newest opensrf and eg |
| 13:33 |
jl- |
could someone help me import this record, possibly testing it with me http://paste.debian.net/80892/ I'm not sure if it needs to be cleansed of anything and what tools to use (I was advised not to use pg_loader before) |
| 13:53 |
dbs |
bshum: well that's hilarious! will look at it later |
| 13:55 |
dbs |
jl-: insert the <record>...</record> bit (strip off the <?xml ...><collection> bits) and you should be good to go |
| 13:56 |
dbs |
jl-: you can look at Open-ILS/tests/datasets/sql/bibs_concerto.sql for an example -- almost the only gotcha is to escape single quotes that might exist in the record |
| 13:57 |
* dbs |
out |
| 14:06 |
jl- |
dbs: I see the bibs_concerto, looks like my format -- insert, how? |
| 14:38 |
jl- |
evergreen=# \i /home/x/Desktop/test.sql |
| 14:38 |
jl- |
psql:/home/x/Desktop/test.sql:70: ERROR: relation "marcxml_import" does not exist |
| 14:38 |
jl- |
LINE 1: INSERT INTO marcxml_import (tag, marc) VALUES |
| 15:13 |
jl- |
do I need to create a table marcxml_import ? |
| 15:52 |
dbs |
jl-: Open-ILS/tests/datasets/sql/load_concerto.sql gives you all the steps for concerto stuff, but that includes authorities, call numbers, and copies |
| 15:52 |
dbs |
you could change the marcxml_import line to "INSERT INTO biblio.record_entry (marc, last_xact_id) |
| 15:52 |
dbs |
and things should work |
| 16:13 |
dbs |
bshum++ |
| 16:14 |
pinesol_green |
[evergreen|Ben Shum] Fix copy_info variables one last time for library_name_link purposes - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=462a352> |
| 16:21 |
jl- |
brb |
| 16:25 |
jl- |
dbs: here's my test.sql http://paste.debian.net/80916/ |
| 16:26 |
jl- |
getting this error: evergreen=# \i /home/x/Desktop/test.sql |
| 16:26 |
jl- |
psql:/home/x/Desktop/test.sql:69: ERROR: |
| 16:26 |
jl- |
syntax error at line 1, column 0, byte 0 at /usr/lib/perl5/XML/Parser.pm line 187 |
| 16:26 |
jl- |
CONTEXT: PL/Perl function "maintain_901" |
| 16:39 |
jl- |
dbs: not sure if you typed anything since my last perl parse error |
| 16:40 |
jl- |
one question tho, in the concerto, there are no next line (like <br> in html) spaces |
| 16:40 |
jl- |
do I need to remove those from my record in the bibs_concerto.sql file? |
| 16:40 |
jl- |
the samples are all one single line |
| 16:40 |
jl- |
like a CSV |
| 16:50 |
|
zerick joined #evergreen |
| 16:55 |
jl- |
psql:assets_concerto.sql:99: ERROR: insert or update on table "monograph_part" violates foreign key constraint "monograph_part_record_fkey" |
| 16:55 |
jl- |
ETAIL: Key (record)=(84) is not present in table "record_entry". |
| 16:56 |
jl- |
:< |
| 17:14 |
jl- |
I did psql evergreen -f load_all.sql and it said it imported |
| 17:14 |
jl- |
how can I see it in the catalog? |
| 17:26 |
jl- |
ermahgerd |
| 17:26 |
jl- |
I'm seeing it |
| 17:26 |
jl- |
er mah gerd |
| 20:04 |
jl- |
I was able to import records with the load_all.sql initiating bib_concerta.sql, I can now search for certain authors and find them and their records |
| 20:04 |
jl- |
however, they don't show up under 'browse ALL' (next) |
| 20:05 |
jl- |
do I need to add certain meta data or do anything do build this index? |
| 20:21 |
|
sseng joined #evergreen |
| 20:21 |
|
ktomita joined #evergreen |
| 06:40 |
pinesol_green |
bshum: The operation succeeded. |
| 06:41 |
dbs |
bshum++ |
| 06:42 |
bshum |
I organized the upgrade SQL with little comments to myself like -- from 030.schema.metabib.sql |
| 06:42 |
dbs |
I will endeavour to test those out. Groggy. |
| 06:42 |
bshum |
So that I knew where I was looking for changes |
| 06:42 |
bshum |
I think I caught all of them, but there were lots. |
| 06:43 |
bshum |
dbs++ cool, cool |
| 11:15 |
* kmlussier |
tries to remember how you do that. |
| 11:15 |
dbwells |
Yes, same as above but with ?physical_loc=999 |
| 11:15 |
dbwells |
That should set a cookie. |
| 11:16 |
* krvmga |
is testing it now. |
| 11:16 |
kmlussier |
krvmga: Also see http://docs.evergreen-ils.org/2.3/_setting_the_default_physical_location_for_your_library_environment.html |
| 11:16 |
bshum |
krvmga: Maybe it's your kiosk software. I know some of those don't like remembering history/cookies |
| 11:16 |
kmlussier |
I had forgotten that you could set the cookie just by using the parameter in the URL. |
| 11:24 |
* krvmga |
hates getting intermittent and seemingly inexplicable 500 errors |
| 11:27 |
|
collum joined #evergreen |
| 11:38 |
csharp |
krvmga: do you have access to the server logs? |
| 11:38 |
bshum |
Or just test each brick individually |
| 11:39 |
csharp |
yeah - intermittent usually means a misconfigured brick |
| 12:02 |
bshum |
RIP Marque :) |
| 12:06 |
|
rfrasur joined #evergreen |
| 14:52 |
pastebot |
"csharp" at 64.57.241.14 pasted "marclint results for jboyer-isl's record" (11 lines) at http://paste.evergreen-ils.org/14 |
| 14:52 |
csharp |
so a couple of (apparently) invalid subfields? |
| 14:53 |
Dyrcona |
jeffdavis: No output from integrity-checker means everything checked is up to date, yeah? |
| 14:54 |
jboyer-isl |
There's a possibility. I just ran it through an xml validator (which can only do so much). I'll try just tearing those out on a test system and seeing if it saves correctly. If not, eeevil, I'll pull those tables if they're small enough and paste them separately. |
| 14:55 |
eeevil |
csharp: the 856$9 is ours, obv (located uris). the 500$0 looks odd |
| 14:56 |
eeevil |
jboyer-isl: config.xml_transform is not small :) |
| 14:56 |
jboyer-isl |
Shoot. I hadn't looked at it yet. :) |
| 17:19 |
bshum |
I think we're on PG 9.1 still |
| 17:23 |
|
Bmagic joined #evergreen |
| 17:23 |
Bmagic |
Hey everyone, got a billing question. We have noticed that money.billing and money.payments have rows that point to xact id's that dont exist in money.billable_xact |
| 17:25 |
dbs |
opened bug 1277731 - plowing ahead with array_agg testing |
| 17:25 |
pinesol_green |
Launchpad bug 1277731 in Evergreen "Hold tests failure" (affected: 1, heat: 6) [Critical,New] https://launchpad.net/bugs/1277731 |
| 17:26 |
dbs |
Bmagic: maybe in one of the Child tables: action.circulation, booking.reservation, money.grocery |
| 17:26 |
Bmagic |
dbs: thanks, i'll check |
| 17:26 |
dbs |
oh wait, I may be drunk |
| 10:26 |
* Dyrcona |
wishes library vendors actually had a clue. |
| 10:26 |
jeff |
I get worked up about this when evaluating new services. Sometimes the interest fades, sometimes not. |
| 10:27 |
jeff |
But part of the idea too is that it would give me some perspective on Evergreen/Koha/etc from a "content provider" point of view also. |
| 10:28 |
dbs |
jeff: this would let us test improved core security too, like replacing unsalted MD5-hashed passwords |
| 10:29 |
jeff |
"here's an idea, let's not use a self checkout protocol with access to holds/circ/bills/more just to verify that you are a patron, and let's not require your library card number (which one?) and library password be entered on the vendor site, and let's not have the vendor store your library password in cleartext in their systems!" |
| 10:29 |
jeff |
dbs: yes, though i see that as a parallel, higher priority goal. :-) |
| 10:29 |
dbs |
jeff: so teaching Evergreen to be an OAuth2 provider? |
| 11:35 |
bshum |
And yay, Marque.pm whee! |
| 11:35 |
Dyrcona |
I'm target it for the beta now. I'll see if I can't finish it by the end of the week. |
| 11:36 |
Dyrcona |
Everything is going into working/dyrcona/lp1223903-MARC-export-Mk.2 from now on. |
| 11:37 |
jboyer-laptaupe |
bshum: Re: commit db7b99e8ccba2ebf81a345157de5a90ba5387626, is there anything else that may need changing for rel_2_5? We have a test system built from rel_2_5 pulled just after that commit went in, but auto-print still doesn't seem to stick on the checkout page with a fresh staff client. |
| 11:37 |
pinesol_green |
[evergreen|Ben Shum] Revert "Eliminate an annoying and useless warning in the JavaScript Console." - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=db7b99e> |
| 11:38 |
bshum |
jboyer-laptaupe: It's a server side change. |
| 11:38 |
bshum |
Not just a client one |
| 11:40 |
bshum |
The one that gets me is the chrome directory stuff I think |
| 11:44 |
Dyrcona |
Yeah, just changing the file on the server fixed it for me. |
| 11:45 |
Dyrcona |
bshum: We've got six inches of snow at my house and its still coming down. |
| 11:45 |
jboyer-laptaupe |
Well never mind that. Our test system isn't running the version of evergreen we wanted to test. :( |
| 11:45 |
jeff |
jboyer-laptaupe: oops. |
| 11:47 |
jboyer-laptaupe |
jeff: I'd actually feel better about it if it were my fault. :/ |
| 11:49 |
|
akilsdonk joined #evergreen |
| 15:12 |
|
stevenyvr joined #evergreen |
| 15:13 |
dbwells |
roses: depending on when 2.4 was released, there might not be a direct route from 2.3.7 to 2.4.0, so you may need to massage the early upgrade scripts until you are back on track. |
| 15:14 |
roses |
dbwells: I'm running the first script (.sql) and I'm having trouble with the password for evergreen - shouldn't it be evergreen because of #10 in the instructions? perl Open-ILS/src/support-scripts/eg_db_config --update-config --service all \ --create-offline --database evergreen --host localhost --user evergreen --password evergreen |
| 15:15 |
dbwells |
roses: There is also at least one supplemental script for 2.4, so make sure you run that too, or at least understand what it does (sometimes scripts do something which gets done again later anyway, especially reingesting records). |
| 15:15 |
dbwells |
roses: Is this a test server? |
| 15:15 |
roses |
dbwells: Yes - a test server |
| 15:15 |
roses |
dbwells: Which I might just wipe and start with a fresh installation of 2.5 |
| 15:16 |
dbwells |
The password will be whatever you set it to when you set it up, your evergreen DB password. |
| 15:17 |
dbwells |
That is, if you ever login to the evergreen DB using 'psql', it will be the same username/password you use for that. |
| 15:19 |
dbwells |
It's might be nice to run through the upgrade scripts for general practice, understanding, and to test the scripts themselves, but unless you have a lot of data in your test server, installing fresh is probably easier. |
| 15:20 |
roses |
dbwells: Thanks. I found my password and now am going to run through the scripts. I might be back later. |
| 15:24 |
fparks |
I am working on a new rendition of Boolean Search https://bugs.launchpad.net/evergreen/+bug/1152863 |
| 15:24 |
pinesol_green |
Launchpad bug 1152863 in Evergreen "Support for traditional Boolean operators" (affected: 3, heat: 18) [Wishlist,Triaged] |
| 15:44 |
Dyrcona |
'course we only 56 SREs in our database, so more eyes might be good on that part. :) |
| 15:44 |
Dyrcona |
...only [have] 56.... |
| 15:47 |
|
roses joined #evergreen |
| 16:10 |
phasefx |
bshum: I tried looking at the commit log for that line re: non-cat in-house, and I think it was indeed oversight + intermediate testing |
| 16:12 |
phasefx |
for those curious (and I only just now learned how to do this), I did git blame in_house_use.js, got a useless commit message for some whitespace cleanup, but then did this to get the commit prior to that: git blame in_house_use.js b228af4f~1 |
| 16:12 |
pinesol_green |
[evergreen|phasefx] Change each tab to 4 spaces in the staff client javascript files. - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=b228af4> |
| 16:35 |
Dyrcona |
learning++ |
| 16:35 |
Dyrcona |
I learned a new git trick today. |
| 18:19 |
pinesol_green |
Launchpad bug 1155769 in Evergreen "Items repeated in tpac display, others not visible" (affected: 3, heat: 16) [Undecided,Confirmed] |
| 18:19 |
bshum |
Do you know how that bug is replicated? I've never been able to consistently get broken displays as described. |
| 18:19 |
Dyrcona |
dbs: git rebase -i / then edit the commit, reset HEAD^, add some files, commit, add the remaining files, commit, rebase --continue |
| 18:20 |
kmlussier |
I've seen it happen. You've got to find the right record to make it happen. |
| 18:20 |
kmlussier |
I was just about to test it and was first looking for a record. |
| 18:20 |
bshum |
And I'm not sure the change ktomita makes there to order by barcode instead of copy number would necessarily be good. Just for the folks who do use copy number in their cataloging. |
| 18:20 |
bshum |
Not us, for sure, but someone might? |
| 18:21 |
kmlussier |
Sounds like a good comment to make on the bug report. :) |
| 05:43 |
|
mtj_ joined #evergreen |
| 07:06 |
|
b_bonner joined #evergreen |
| 07:07 |
|
tfaile joined #evergreen |
| 07:11 |
csharp |
@later tell hbrennan you should ask your IT dept for a testing server that you can play with too |
| 07:11 |
pinesol_green |
csharp: The operation succeeded. |
| 07:25 |
|
timlaptop joined #evergreen |
| 07:40 |
|
kbeswick joined #evergreen |
| 09:09 |
jeff |
create three dirs /openils/var/web/opac/extras/ac/jacket/{small|medium|large}/r |
| 09:09 |
csharp |
StephenGWills: the lines beginning with \qecho will let you know what you need |
| 09:10 |
StephenGWills |
kk looking |
| 09:10 |
jeff |
place an .htaccess file in each dir (you might be able to do this at a common ancestor directory -- i've not tried) containing: "ForceType image/jpeg" |
| 09:11 |
jeff |
place a jpeg file named "12345" in the large/r/ medium/r/ and small/r/ directories |
| 09:11 |
jeff |
if you have multiple app servers without /openils/var/web/opac/extras/ac/jacket being shared storage between them all, you'll need to copy the images to each app server. |
| 09:11 |
jeff |
then, test. |
| 09:12 |
csharp |
so the ../r directory contains any custom jpegs that are named by the bib id number, correct? |
| 09:12 |
jeff |
right |
| 09:12 |
StephenGWills |
the bib in question does not have a 901$c, I'm feeling hopeful :) thanks Chris |
| 09:18 |
csharp |
wow |
| 09:18 |
csharp |
well, we're discussing sustainability at this point - we're pretty sure we can't handle an influx of local image requests at this point |
| 09:18 |
bshum |
jeff: I was thinking about custom images the other day as I looked at some random 856 lines. |
| 09:18 |
csharp |
but I still want to test it (and possibly script it) |
| 09:19 |
jeff |
yeah, we have an interface that staff use to upload jacket images. |
| 09:19 |
* csharp |
imagines a staff upload interface that would act like an "incoming" directory |
| 09:19 |
csharp |
heh |
| 12:51 |
jeff |
but the "can i do this with a function returning SETOF in this circumstance" seemed useful to determine an answer to, for future. |
| 12:52 |
tsbere |
jeff: Well, I can give you "the first alert in the list" easily. "All alerts in the list" is harder. |
| 12:52 |
jeff |
i'll take that for starters. |
| 12:53 |
* tsbere |
could be wrong on the "all" front now that he ran a test |
| 12:54 |
tsbere |
jeff: Add this to the end of your SELECT DISTINCT line: , (actor.address_alert_matches(au.home_ou, aaua.street1, aaua.street2, aaua.city, aaua.county, aaua.state, aaua.country, aaua.post_code, aaua.mailing, aaua.billing))).alert_message |
| 12:54 |
jeff |
ah, see i was trying to think of how to do it with a subselect -- suddenly, easier! |
| 12:56 |
tsbere |
I might have an extra ) in there |
| 12:56 |
tsbere |
<_< |
| 12:56 |
jeff |
you did, i'm pretty sure. |
| 12:56 |
* tsbere |
can't actually test this due to MVLC not *having* any such alerts defined right now |
| 12:57 |
jeff |
we recently started using them, and i'm trying to make them do double duty for reporting as well as the alerts in the user editor. |
| 12:58 |
jeff |
currently takes over a minute to run, but that's reasonable for this report. |
| 13:01 |
|
jeffdavis joined #evergreen |
| 13:18 |
csharp |
looks like closed dates are acting more like grace periods with the current behavior |
| 13:19 |
Dyrcona |
next breaks from the loop at that point and starts again at the top with the next iteration. |
| 13:21 |
dbwells |
csharp: I am pretty sure the code is meant to do what you want it to do. If I understand your situation correctly, for some reason, actor::org_unit::closed_date->search_where() isn't finding your closed dates. |
| 13:22 |
csharp |
dbwells: I can dig for this, but can you see a simple-ish way to test that hypothesis? |
| 13:22 |
Dyrcona |
I was about to say something along the lines of what dbwells just said. |
| 13:22 |
Dyrcona |
I needed more context. :) |
| 13:23 |
dbwells |
csharp: That function basically is a straight DB lookup (I think), so I'd start by looking in the DB and see if everything is in line there. |
| 16:41 |
eeevil |
Dyrcona: for your next trick, convince B&T a library might want to use all 35 bytes available to name itself in EIDFACT, not just 5. ;) |
| 16:42 |
eeevil |
see also: item identifiers |
| 16:45 |
|
roses joined #evergreen |
| 16:46 |
roses |
Several months ago (almost a year) I was working on setting up a test Evergreen server and someone here told me about where to find some fake/test records to import into my catalog? Where can I find something like that? |
| 16:50 |
bshum |
roses: If you're just setting up some sort of demo system, you can always use the stock concerto dataset that comes with Evergreen 2.4+ |
| 16:50 |
roses |
bshum: I installed 2.3.7 |
| 16:51 |
bshum |
That step gets described a bit in step 9.1 of the 2.5 README |
| 13:01 |
Dyrcona |
I tried using substream => 1 to no avail. |
| 13:02 |
Dyrcona |
Well, I still got no results, but maybe then the login didn't fail... |
| 13:02 |
dbs |
Bmagic: maybe also see if it's getting gzipped or anything: curl -I http://hostname/updates/update.rdf (doesn't seem to be on ours) |
| 13:02 |
csharp |
okay - testing something with our bots |
| 13:02 |
bshum |
Bmagic: I'd be curious what you did to create the updates on the new server. Did you copy the archives from the old server to the new one and then make updates-client there? |
| 13:03 |
|
serflog joined #evergreen |
| 13:03 |
|
Topic for #evergreen is now Welcome to the #evergreen library system channel! | We are publicly logged. | Large pastes at http://paste.evergreen-ils.org |
| 18:54 |
bshum |
Well, we are using OpenSRF master. |
| 18:54 |
dbwells |
I am assuming you have had parallel on for a while. |
| 18:55 |
bshum |
Yeah it's untouched and comes that way out of the box for opensrf.xml |
| 18:56 |
dbwells |
Hmm, I see those lines commented on my test box, but I may not have updated opensrf.xml in a while. |
| 18:57 |
dbwells |
In any case, I am glad you found a possible workaround for now. |
| 18:59 |
bshum |
dbwells: Yep I'll check the systems tomorrow and see if there's a backlog again of broken collected state A/T events. |
| 18:59 |
bshum |
Thanks for the advice! dbwells++ |
| 19:41 |
hbrennan |
If anyone's still here, I'm having a "moment" and can't find where to change the text on the OPAC login screen that says "If this is your first time logging in, please enter the last 4 digits of your phone number. Example: 0926" |
| 16:48 |
Dyrcona |
bshum: When you try to renew a lost item, after applying the above patch, you are supposed to get a dialog asking if you want to force action. |
| 16:48 |
Dyrcona |
Instead, I'm getting a FIX ME followed by another FIX ME. |
| 16:51 |
Dyrcona |
I was going to say that kmlussier and I both saw the force action dialog before, but I'm less certain of that, now. |
| 16:51 |
Dyrcona |
After looking through my email, I see she mentions getting it on a different test. |
| 16:52 |
Dyrcona |
I don't see her mentioning on testing renewal of a lost item, but I thought I had seen it. |
| 16:52 |
Dyrcona |
I now believe I was mistaken. |
| 16:52 |
bshum |
Renewing a lost item should generate some sort of stupid error I thought. |
| 16:52 |
Dyrcona |
The patch I pasted above gets rid of it. |
| 16:53 |
bshum |
or trying to |
| 16:53 |
|
zerick joined #evergreen |
| 16:53 |
Dyrcona |
Now, you get a different stupid error, but is should be a force action, instead. |
| 16:53 |
kmlussier |
I'm almost certain I saw it. I suppose it's possible I confused it with the other test, but I really thought I saw it. |
| 16:53 |
Dyrcona |
s/is/it/ |
| 16:53 |
Dyrcona |
kmlussier: I'm not saying we didn't see it. I'm just not certain at this point. |
| 16:54 |
kmlussier |
However, it is unusual for me not to mention seeing the override when I reported the bug. |
| 16:57 |
Dyrcona |
Well, it should mention three events: COPY_NOT_AVAILABLE, COPY_STATUS_LOST, PATRON_EXCEEDS_MAX_FINES. |
| 16:57 |
kmlussier |
Which is why I was so certain I saw it. Because I remember seeing it and thinking that I should pay the lost bill ahead of time to see if it changed the behavior. |
| 16:58 |
Dyrcona |
Those three should be overridable if the user has the .override permission. |
| 16:58 |
* kmlussier |
used to be more diligent about capturing screenshots during testing. :( |
| 16:58 |
Dyrcona |
I think I am just going to have to tinker with the renewal code until it works. |
| 16:59 |
bshum |
Well, at least back in 2011 when I had the original ticket in our helpdesk, they only mention the ACTION_CIRCULATION_NOT_FOUND error |
| 16:59 |
bshum |
Nothing about overrides |
| 16:59 |
kmlussier |
bshum: Yes, that's right. The overrides came with the code I'm testing. |
| 16:59 |
bshum |
Oh |
| 16:59 |
bshum |
Well then! |
| 16:59 |
bshum |
:) |
| 17:00 |
* bshum |
should just be quiet and let you guys do your thing |
| 17:01 |
Dyrcona |
bshum: You realize I've made a change to get past the ACTION_CIRCULATION_NOT_FOUND, right? |
| 17:01 |
* Dyrcona |
points at paste 10 above. |
| 17:02 |
bshum |
Dyrcona: I hadn't gotten to the paste yet. I was trying to figure out what the "broken" behavior was before I applied a proposed fix to learn what else it breaks. |
| 17:02 |
bshum |
I was just going to try adding it to our master test server next. |
| 17:03 |
bshum |
Just refamiliarizing myself with what's going on. 2011/2012 seems like forever ago. |
| 17:03 |
Dyrcona |
ok |
| 17:10 |
bshum |
Well I got a network error as it tried to find the billing to deal with voiding the lost. But then yeah I got the two FIXMEs back to back after that. |
| 17:10 |
Dyrcona |
Thanks. |
| 15:39 |
Dyrcona |
Or, maybe that isn't right.... I think I'll add some code to log the contents of $self->{events} to make sure. It is hard to tell from the logs as they are. |
| 15:39 |
Dyrcona |
It looks like the events disappear after checkin pushes SUCCESS. |
| 15:56 |
Dyrcona |
Heh... |
| 15:57 |
Dyrcona |
@later tell kmlussier I just noticed the name of the test user you created in my development database. |
| 15:57 |
pinesol_green |
Dyrcona: The operation succeeded. |
| 16:00 |
Dyrcona |
The events stick around as do the checkin event, including the negative event added, but handled by checkin... |
| 16:02 |
Dyrcona |
The events are reset just before we get to do_checkin, which makes it seem that the events gathered in run_renew_permit are done for no purpose. |
| 16:13 |
Dyrcona |
Interestingly, without run_renew_permit, I still get two of the three events that were causing the renewal failure. |
| 16:14 |
Dyrcona |
I think I know where to add my new checks for permissions to allow lost items to be renewed. |
| 16:14 |
Dyrcona |
I had them in the wrong place before. |
| 16:47 |
* kmlussier |
tries to remember the name of the test user she used. |
| 17:48 |
|
zerick joined #evergreen |
| 17:51 |
Dyrcona |
kmlussier: When you tested the renewal on lost and claims returned was the staff client asking to override the events? |
| 18:00 |
Dyrcona |
My staff client right now throws up a FIX ME error, the payload looks like three overrideable events. |
| 18:19 |
|
zerick joined #evergreen |
| 18:34 |
* Dyrcona |
is done monologuing for one day. |
| 13:29 |
tsbere |
jeff: Yea. Though ensuring you don't hit max too soon might be an issue. |
| 13:30 |
tsbere |
not to mention overnight issues <_< |
| 13:31 |
Dyrcona |
jeff: Sound overly complicated. Are the exclusions based on some rarely changing property of the user, or is it arbitrary for each report? |
| 13:32 |
jeff |
Dyrcona: the idea is "don't count circs by test or otherwise not-real patrons". usually this is just done with an infrequently (never!) changing patron profile on the "patron" account. |
| 13:32 |
jeff |
but right now i'd like (for training and/or for testing-for-real) to have some patrons who are in other groups also be excluded, without excluding that entire group. |
| 13:33 |
jeff |
i don't want to edit every report to "also exclude these patrons" or "also exclude patrons with this attribute", hence the idea that "at this point, if i decide to do this, i want a view to help me" :-) |
| 13:34 |
jeff |
(a reporting view for sql reports, not necessarily a full-on view in the IDL and such. |
| 13:34 |
jeff |
) |
| 13:35 |
jeff |
but another option is to change a test user in the excluded group to a non-excluded group to test "can this user really check out only one chromebook and no other items at all", then return the user to the excluded group -- but that involves: |
| 13:35 |
jeff |
1) hope nobody runs a report that would be affected |
| 13:35 |
jeff |
2) don't forget to change the group back |
| 13:35 |
jeff |
sometimes i think i just worry too much about reporting on "not real" things. |
| 13:36 |
jeff |
other times i think "more test servers!" |
| 13:36 |
* jeff |
shrugs |
| 13:36 |
jeff |
i'm just babbling now |
| 13:37 |
tsbere |
jeff: Make a table of "don't report on these user ids", fill it however you want (perhaps with a DB function), then ensure that reports say "and the user id is not in that table" either directly or via a view? |
| 13:37 |
|
rfrasur joined #evergreen |
| 13:37 |
tsbere |
Would likely be faster than looking up stat cat or user pref entries, though you could do that to populate the table |
| 15:57 |
dbwells |
jtaylorats: Yes. At that point they will display in the OPAC and be editable in the client. If the records contain any kind of individual copy/volume level data, there is no code which will do anything special with that type of data. |
| 15:57 |
* Dyrcona |
decides to program in BrainFuck from now on. |
| 15:58 |
kmlussier |
Dyrcona++ bshum++ # Doing your part to contribute to Evergreen even if you are human and sometimes make mistakes. |
| 15:58 |
jtaylorats |
Thanks. That is the last piece. I've gotten the test migration done for the entire database. |
| 15:58 |
jboyer-isl |
Dyrcona, have you seen Whitespace? http://compsoc.dur.ac.uk/whitespace/ |
| 15:59 |
jtaylorats |
Now to wipe it out and put all the pieces together and do it again :-) |
| 15:59 |
jtaylorats |
Appreciate all the help. |
| 16:04 |
bshum |
jboyer-isl: Heh, well it's fixed for rel_2_5 now too. |
| 16:05 |
bshum |
Every time I think about being a "hero" I think of the movie Sky High. Where there's heros and sidekicks. |
| 16:05 |
bshum |
I always thought I was more of a sidekick. |
| 16:05 |
jboyer-isl |
Huzzah! Thanks. We were just about to cut off changes to a new test environment 10 mins ago :) |
| 16:05 |
jboyer-isl |
I haven't seen that one, but I vaguely remember when it came out. |
| 16:28 |
pinesol_green |
[opensrf|Bill Erickson] osrf_control router-de/re-register and reload commands - <http://git.evergreen-ils.org/?p=OpenSRF.git;a=commit;h=5b3f804> |
| 16:28 |
pinesol_green |
[opensrf|Galen Charlton] typo fix - <http://git.evergreen-ils.org/?p=OpenSRF.git;a=commit;h=0c0b02e> |
| 16:28 |
pinesol_green |
[opensrf|Galen Charlton] x - <http://git.evergreen-ils.org/?p=OpenSRF.git;a=commit;h=d90a415> |
| 16:56 |
* bshum |
watches it explode now |
| 16:57 |
pinesol_green |
[opensrf|Bill Erickson] LP#1066131: srfsh.py should not require opensrf.settings - <http://git.evergreen-ils.org/?p=OpenSRF.git;a=commit;h=2fae356> |
| 16:59 |
gmcharlt |
bshum: while you're in the area, a look at 1155446 would be nice |
| 17:00 |
* bshum |
doesn't really want to test on Lucid |
| 17:00 |
bshum |
But I'll look at the rest of it. |
| 17:00 |
gmcharlt |
well, lucid is less relevant now than it was in March of last year |
| 17:01 |
gmcharlt |
I'll see how wheezy likes it |
| 17:01 |
bshum |
I'm checking precise right now. |
| 17:20 |
bshum |
gmcharlt: Looks okay to me on precise. |
| 17:20 |
bshum |
I'll sign off and push it |
| 17:20 |
gmcharlt |
thanks |
| 17:22 |
pinesol_green |
[opensrf|Galen Charlton] LP#1155446: add Debian/Ubuntu deps required for Python tests to pass - <http://git.evergreen-ils.org/?p=OpenSRF.git;a=commit;h=02a93da> |
| 17:25 |
* jeff |
waits patiently to see if collectionHQ extract will complete |
| 17:26 |
bshum |
egbuilder: status |
| 17:26 |
egbuilder |
evergreen-master-debian-6.00-x86_64: idle, last build 1h30m42s ago: build successful |
| 10:13 |
|
tsbere joined #evergreen |
| 10:14 |
eeevil |
there is that path, yes ;) |
| 10:31 |
|
mcooper joined #evergreen |
| 10:55 |
mceraso |
gmcharlt: I tested the candidate tarball for OpenSRF 2.2.2 using Ubuntu 12.04 LTS and it works well |
| 10:56 |
gmcharlt |
mceraso++ # thanks for testing! |
| 10:56 |
|
mrpeters joined #evergreen |
| 10:56 |
mceraso |
Anytime :) |
| 10:57 |
|
mcooper joined #evergreen |
| 13:39 |
|
schatz joined #evergreen |
| 13:39 |
mrpeters |
we're going to be building out a new installation with 900TB of SSD for their DB's. Should be fun to see how it screams. |
| 13:39 |
mrpeters |
I know PINES has talked about going SSD as well. |
| 13:40 |
bshum |
900TB? Whoa? |
| 13:40 |
bshum |
:) |
| 13:41 |
bshum |
So far, I'm noticing significant gains in search response and hold placement via the catalog on my test server with SSD. |
| 13:41 |
bshum |
Like an example bib where hold placement took 24 seconds in production system took 6 seconds in that test laptop. |
| 13:43 |
* bshum |
should switch out to GIN indexes and see what happens.... |
| 13:44 |
eeevil |
oh, that reminds me. 9.4 looks like it's going to greatly improve GIN speed |
| 13:44 |
bshum |
Yay! :) |
| 13:44 |
* bshum |
loves postgres |
| 14:09 |
|
hbrennan joined #evergreen |
| 14:13 |
|
snowball joined #evergreen |
| 14:26 |
|
akilsdonk joined #evergreen |
| 14:33 |
bshum |
berick: I just setup the prototype code on one of our test servers, we're going to play around. Just curious about one thing though: |
| 14:33 |
bshum |
What might cause this to happen where it seems to get stuck a bit on the patron search and I can't seem to retrieve new result sets. |
| 14:34 |
bshum |
Logging out I could get back to it again and things seemed fine, but on my first go, it found a patron, then I opened their record, then couldn't search for anybody new. |
| 14:34 |
* bshum |
keeps playing around |
| 14:34 |
berick |
bshum: haven't seen that. i'd suggest checking the JS console for errors |
| 14:34 |
berick |
bshum++ # testing |
| 14:34 |
bshum |
berick: Yeah I thought of that after I'd left the client |
| 14:34 |
bshum |
I'll try to replicate it and check the console next time. |
| 14:35 |
bshum |
It's quite fun so far. |
| 15:40 |
sseng |
jeff: gmcharlt: alright, thanks! |
| 15:46 |
Dyrcona |
rfrasur: Turns out, one of our members is also doing a seed lending program. |
| 15:47 |
Dyrcona |
rfrasur: Groton Public Library (gpl.org), and they are reusing the card catalog shelves. :) |
| 16:06 |
sseng |
gmcharlt: can I confirm that from the memory leak test report, I perform the test in the same tab right? that is to say, I press F1, enter the patron barcode, checkout a book, and click "Done", and this represent one iteration? |
| 16:06 |
jeff |
Right now, if you have a standing penalty such as PATRON_EXCEEDS_FINES, you can configure what things that penalty blocks (CIRC, or CIRC|RENEW, etc), but you can't have that penalty block certain things for different groups of patrons. Does anyone else have interest in such functionality? |
| 16:07 |
gmcharlt |
sseng: yes |
| 16:07 |
jeff |
I'm trying to decide between a hack and a wishlist bug. :-) |
| 16:56 |
bshum |
Bah, and now it works again. Might just be some weird browser effect... |
| 16:56 |
bshum |
I'll play more tomorrow. |
| 16:57 |
berick |
bshum: holler when you do. Now that it's browser-based, I can poke too! (if you give me a login :) |
| 16:58 |
bshum |
berick: Unfortunately I rolled it in with my local SSD test server. Which is hidden behind too many layers to unveil. |
| 16:58 |
bshum |
But I'm going to work on installing it to our public demo system soon. |
| 17:00 |
berick |
ah |
| 17:02 |
bshum |
Just have to remind myself how to log into everything... too many passwords. |
| 17:02 |
berick |
feel free to type them in here if you need a backup |
| 17:03 |
bshum |
:) |
| 17:22 |
|
kimo_sabe joined #evergreen |
| 17:31 |
kimo_sabe |
I'm having an odd issue trying to do some testing on 2.5.2 but when I try and clone my production database over to dev to try the upgrade stuff goes missing. Anyone seen that before? I'm at a loss |
| 17:39 |
|
mmorgan left #evergreen |
| 18:10 |
dbwells |
kimo_sabe: There have been a few recent conversations about needing to set the search_path before using pg_restore. |
| 18:11 |
dbwells |
e.g. here: http://evergreen-ils.org/irc_logs/evergreen/2014-01/%23evergreen.22-Wed-2014.log at 12:54:55 |
| 17:41 |
|
dcook joined #evergreen |
| 18:44 |
|
Dyrcona joined #evergreen |
| 18:45 |
Dyrcona |
If renewal is mostly just a checkin and then checkout, why have all these extra checks just for renewing? |
| 18:46 |
Dyrcona |
We end up running those, then the checkin tests, and then essentially the same checks for the checkout. |
| 18:46 |
dcook |
I'm not an Evergreen person, but I imagine there are extra rules for renewing? |
| 18:47 |
dcook |
Like only being able to renew certain types of items, only renewing if there are no other holds, etc. |
| 18:48 |
Dyrcona |
dcook: I'm going through the circ code, and I am an "Evergreen person." |
| 18:48 |
Dyrcona |
There are slightly different checks for renewals, but virtually all of the tests get run again. |
| 18:49 |
dcook |
In that case, no idea, but sounds like a valid question :) |
| 18:49 |
Dyrcona |
I'm tempted to remove the database check for the status not being equal to 1 on a renewal. |
| 18:54 |
Dyrcona |
I also don't like how the same events come up three times in my log before we actually hit a bail statement. |
| 18:58 |
Dyrcona |
If I wish to introduce a permission-based check to override this, I have to add the checks for the permissions in all of the multiple places the checks occur. |
| 18:59 |
Dyrcona |
I also rather naively based the permissions on the stop fines values from action.circulation, so I'm now I'm slightly stumped at the approach to take with the status of the copy. |
| 19:00 |
Dyrcona |
Pardon me. This is mostly thinking "out loud" at this point. |
| 19:01 |
Dyrcona |
The other problem, is the renew (and checkout tests) return COPY_NOT_AVAILABLE regardless of the copy's status. |
| 19:01 |
hbrennan |
I'm "listening" to ya, Dyrcona. :) |
| 19:02 |
Dyrcona |
heh. |
| 19:02 |
Dyrcona |
That means I have to check the copy's status yet again rather than relying on the return code from the database check. |
| 19:22 |
Dyrcona |
In checkin, we push a COPY_STATUS_LOST, check bail_out (which hasn't been set), and then keep right on going. |
| 19:24 |
Dyrcona |
neato: We call checkin_handle_lost_or_lo_now_found twice in a row. I have to find out why. |
| 19:25 |
Dyrcona |
We get through checkin and push a SUCCESS event! So, we have 3 failures (this patron also owes too many fines, but I was ignoring that) and 1 success. |
| 19:26 |
Dyrcona |
Then, we do the indb circ tests again, but I don't think we've made it to checkout, yet. |
| 19:37 |
Dyrcona |
So, I should probably add a new function to be called from do_permit that checks for my particular conditions and permissions. |
| 19:39 |
Dyrcona |
Since this isn't a case of override permissions.... Err, wait.... |
| 19:40 |
* Dyrcona |
mulls the impact of override permissions. |
| 15:47 |
eeevil |
ldwhalen: or just check that it's not there already with a CTE, or blindly insert outside any explicit transaction |
| 15:49 |
ldwhalen |
eeevil: Is it worth while adding the param_count from pg_proc? |
| 15:50 |
eeevil |
you need the param_count when it's not 0. I'd suggest just setting it to what it should be. I wouldn't involve pg_proc at all. IMO, just look at the definition of the proc, count the params requested, and subtract 1 |
| 15:53 |
jboyer-isl |
jeff: route_subdomains was commented out on both test bricks, but setting it to s2s doesn't seem to have been the whole fix. I could/should check the other service machines, but these bricks should be talking straight to the db without too much bouncing around. |
| 15:58 |
eeevil |
jboyer-isl: can the other domains find each other via dns or /etc/hosts? (IOW, is ejabberd listening on all IPs, and are the foreign IPs named something they would recognized) |
| 16:01 |
tsbere |
jboyer-isl: I would also check for local firewalling - If the server(s) aren't allowing incoming traffic on the S2S port the rest of the proper config won't help....and are your different bricks using different ejabberd domains for that matter? |
| 16:03 |
jboyer-isl |
the machines appear to be able to find each other by name, I don't believe there's a firewall running (they're off on a private 10. network) and they are all using individual private.name.evergreen.lib.in.us and public.evergreen...., and localhost domains. |
| 16:14 |
eeevil |
berick: agreed ... I was really just thinking of xdr JS clients, though I don't know if that's strictly possible right now, and since only older MOZ supports multipart/mixed-replace, it's probably never going to be worth worrying about |
| 16:15 |
* dbs |
does a bit of a double-take at "Bill Erickson moved some example seed data out of the base install and into a sample data set." |
| 16:16 |
* eeevil |
goes to look more closely and make sure he didn't lie... |
| 16:17 |
dbs |
berick does _tons_ of stuff that deserves credit, and I certainly appreciate his testing & signing off |
| 16:17 |
eeevil |
I did lie. dbs, my apologies |
| 16:17 |
* eeevil |
updates |
| 16:21 |
dbs |
thanks eeevil |
