05:01 |
pinesol_green |
News from qatests: Test Failure <http://testing.evergreen-ils.org/~live> |
09:42 |
bshum |
gmcharlt: I added POT updates to working branch user/bshum/20170902-i18n-pot-sync |
09:43 |
bshum |
There's a few areas I'm still reviewing, the one that I question most is this in one in Open-ILS/src/templates/staff/base_js.tt2 |
09:43 |
bshum |
msgid "{{location_name}} ({{owning_lib_shortname}})" |
09:44 |
bshum |
Just another case where we only seem to be sending the variable names for translation. And the PO not likely to ever contain the actual values for those variables, so eh... |
10:14 |
* bshum |
reads up on PO filter and various tests we could try to use to validate our PO files to prevent i18n mishaps... http://docs.translatehouse.org/projects/translate-toolkit/en/latest/guides/using_pofilter.html |
11:00 |
|
Dyrcona joined #evergreen |
11:01 |
Dyrcona |
So, I upgraded one of my development branches with latest master this morning. |
11:01 |
Dyrcona |
I did a fresh load of concerto, and I'm getting no search joy. |
11:24 |
Dyrcona |
Ran the mozart search again... |
11:24 |
bshum |
gmcharlt: I suppose so, or we just need to make a note for new i18n practice to ignore anything in {{variable}} and that should be good too |
11:25 |
gmcharlt |
yeah |
11:25 |
bshum |
I just finished building a new test server based on the branch with the POT changes and it seems to be perfectly fine to me |
11:25 |
bshum |
I think we can safely push it in for now and figure out next steps |
11:25 |
gmcharlt |
and arguably, {{username}} gives a translator more of a fighting chance to figure context than a bare [_1] |
11:25 |
bshum |
Yeah I get the argument, but I also don't think it's realistic that any actual values would ever end up in the PO file that way |
11:26 |
pinesol_green |
[evergreen|Galen Charlton] LP#1251394: fix typo in seed data caugh by t/24-sql-gettext-unique.t - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=d5fe1cc> |
14:14 |
Dyrcona |
I wonder if that person asking on the ejabberd forum ever got help? They mention OpenSRF in their post. |
14:15 |
Dyrcona |
yay! OpenSRF works. :) |
14:15 |
Dyrcona |
And company just arrived, so got to go, again. |
17:01 |
pinesol_green |
News from qatests: Test Success <http://testing.evergreen-ils.org/~live> |
18:33 |
|
cucumberjoe joined #evergreen |
05:00 |
pinesol_green |
News from qatests: Test Failure <http://testing.evergreen-ils.org/~live> |
06:57 |
|
kmlussier joined #evergreen |
07:14 |
|
rjackson_isl joined #evergreen |
08:24 |
* kmlussier |
just tried cherry picking a patron barcode number. |
11:37 |
|
jvwoolf1 joined #evergreen |
12:16 |
|
jihpringle joined #evergreen |
12:17 |
|
yboston joined #evergreen |
12:21 |
gmcharlt |
I'd like to request one more pair of eyes on bug 1710949, which I've tested and signed off on |
12:21 |
pinesol_green |
Launchpad bug 1710949 in Evergreen "A one-call login API would be swell" [Wishlist,New] https://launchpad.net/bugs/1710949 |
12:39 |
berick |
gmcharlt++ |
12:50 |
pinesol_green |
Showing latest 5 of 17 commits to Evergreen... |
13:02 |
miker |
gmcharlt: I'll take the login api |
13:02 |
gmcharlt |
miker++ |
13:02 |
gmcharlt |
dbwells++ |
13:08 |
pinesol_green |
[evergreen|Bill Erickson] LP#1710949 open-ils.auth.login API - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=18b313d> |
13:08 |
pinesol_green |
[evergreen|Bill Erickson] LP#1710949 auth.login Perl live test script - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=3bc96cf> |
13:08 |
pinesol_green |
[evergreen|Bill Erickson] LP#1710949 Redact open-ils.auth.login params - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=d067a00> |
13:08 |
pinesol_green |
[evergreen|Bill Erickson] LP#1710949 Release notes for auth.login - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=f1f6489> |
13:08 |
pinesol_green |
[evergreen|Galen Charlton] LP#1710949: add tests for blocking after failed attempts - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=cd22fa0> |
13:14 |
miker |
grabbing 1062-1067 |
13:18 |
miker |
I'm going to stamp a couple forgotten upgrade scripts |
13:24 |
dbwells |
miker: ack, darn, that would be me. Thanks. |
15:11 |
pinesol_green |
[evergreen|Galen Charlton] LP#1688398: some tidying - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=0efd7b6> |
15:11 |
pinesol_green |
[evergreen|Galen Charlton] LP#1688398: add release notes - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=9ede1f1> |
15:11 |
pinesol_green |
[evergreen|Galen Charlton] LP#1582354: put release notes entry in proper directory and fix typo - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=6e64e97> |
15:13 |
berick |
jeffdavis: gmcharlt: i have ebook_api service running (tests pass) and ebook settings enabled in config.tt2 (including test mode). i do see the ebook counts in my account. what else should I be seeing? possible to perform actions in test mode? |
15:21 |
berick |
ah, cool, i'm getting some useful error logs. |
15:21 |
gmcharlt |
not sure about what test mode permits (I'd borrowed test OverDrive credentials) |
15:21 |
berick |
gmcharlt: *nod* thanks |
15:23 |
jeffdavis |
catalog search for Tolkien, you should see some sample records with URIs like http://example.com/ebookapi/t/001 ; those records should display ebook holdings info and a "Check Out E-Item" or "Place Hold on E-Item" link; clicking on those should (after OPAC login) take you to a page with a button for checking out or placing a hold |
15:23 |
|
abowling joined #evergreen |
15:25 |
berick |
jeffdavis: Tolkien returns zero results. they were added to the concerto data set? |
15:25 |
kmlussier |
gmcharlt: OK, then, is it possible that anything in the database bits of the authority branch that could affect being able to log into the web client? It worked fine this morning when I was testing on an ugpraded database. |
15:25 |
kmlussier |
It's the only branch I have on that VM outside of current master. Everything else looks great. |
15:26 |
jeffdavis |
berick: They're there for me. I'm currently not seeing any titles with located URIs but no physical holdings. |
15:26 |
kmlussier |
https://mlnc4.noblenet.org/eg/staff/ is the page. It doesn't fully load in Chrome. In Firefox, it loads, but I can't log in. |
15:26 |
jeffdavis |
er, non-web-client searches return 0 results for me if all the results only have located URIs but no physical copies |
15:28 |
kmlussier |
berick: They're located URIs, so you have to scope your search in the public catalog. |
15:28 |
kmlussier |
Oh, sorry, jeffdavis already mentioned the Located URIs. |
15:29 |
berick |
kmlussier: ah, ok. i didn't put all the pieces together |
15:31 |
jeffdavis |
In the Tolkien records the URI is scoped to CONS but they don't show up in a CONS-scoped OPAC search. Ditto for manually created records with CONS-scoped URIs. |
15:32 |
jeffdavis |
I don't think that's an issue with the ebook code (which doesn't touch search results until the page has been rendered) but I haven't had a chance to test more yet. |
15:32 |
abneiman |
kmlussier: FWIW I can get mlnc4 to load in Chrome, but I get nothing when I try to log in. |
15:34 |
kmlussier |
I can now too, but I'm guessing that's because gmcharlt is performing some kind of magic spell. |
15:34 |
berick |
jeffdavis: thanks. i have enough here to get a sense of things. |
15:35 |
gmcharlt |
kmlussier: try again now; apache2-websockets needed to be bounced |
15:36 |
kmlussier |
gmcharlt: Sigh. Ok, I checked to make sure they were running, but did nothing else. Sorry about that. |
15:39 |
jeffdavis |
berick: and getting back to the original question, in theory clicking the Checkout button should result in a message like "Item has been checked out" and your checkout count being incremented temporarily. The EbookAPI::Test handler has hardcoded responses so it will only authenticate for patron 99999359616, checkout will always and only succeed with item 003, etc |
15:39 |
jeffdavis |
item 003 = title with URI http://example.com/ebookapi/t/003 |
15:40 |
jeffdavis |
I should of course document this more thoroughly somewhere. |
15:41 |
pinesol_green |
[evergreen|Ben Shum] LP#1710991: Do not translate username and workstation in webclient navbar - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=df79b43> |
15:48 |
berick |
jeffdavis: nice! i have actions |
15:50 |
* kmlussier |
clears her throat |
16:16 |
berick |
kmlussier: your commits are in there, just buried.. happened at essentially the same time |
16:16 |
berick |
"latest 5 of 39" .. i think i merged about 20 |
16:17 |
kmlussier |
Ah, well. They're both good causes. |
16:32 |
pinesol_green |
News from qatests: Test Failure <http://testing.evergreen-ils.org/~live> |
16:40 |
* gmcharlt |
takes a look at those |
17:03 |
miker |
great news everyone! display fields rebases over master-with-authority without any conflicts! |
17:03 |
kmlussier |
miker++ |
17:03 |
kmlussier |
Of course, that means you could have looked at it hours ago miker. |
17:03 |
gmcharlt |
currently doesn't account for possiblity that imported_as can be null |
17:04 |
miker |
gmcharlt: point me at a commit, I shall pick it |
17:04 |
Bmagic |
just created the much-wanted regression test on bug 1411422 |
17:04 |
pinesol_green |
Launchpad bug 1411422 in Evergreen 2.12 "Copy details repeated in search results when item/volume moved with parts attached" [Medium,Confirmed] https://launchpad.net/bugs/1411422 |
17:04 |
kmlussier |
Oooh! |
17:06 |
Bmagic |
funny, creating that test actually uncovered a potential bug. LOL, I guess that's what those tests are for, huh? |
17:07 |
pinesol_green |
[evergreen|Cesar Velez] LP#1599894 - OPAC disable Add to MyList when doing metabib search - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=3a14a50> |
17:07 |
gmcharlt |
miker: user/gmcharlt/fix_vii_inh_fkey |
17:07 |
miker |
gmcharlt: thanks, looking |
17:11 |
gmcharlt |
miker: :) I've updated the branch |
17:11 |
miker |
it is known |
17:11 |
* miker |
also grabs 1075 |
17:12 |
gmcharlt |
Bmagic: Open-ILS/src/sql/Pg/t/regress/lp1629108_metarecord_constituent_result_reroute.pg |
17:12 |
gmcharlt |
am I understanding correctly that the partiuclar value of source_list doesn't actually matter for hte purpose of the test? |
17:12 |
Bmagic |
gmcharlt: I was looking at that as well |
17:13 |
Bmagic |
yes, those ID numbers were* the constituent records on concerto once upon a time |
17:13 |
gmcharlt |
they're still showing up -- but the order of the ids in source_list appears to be varying |
17:13 |
Bmagic |
that would break the test for sure |
17:14 |
Bmagic |
STRING_AGG(x.id::TEXT, ',') AS source_list doesn't enforce an order.... so I suppose the test shouldn't expect it to be in order |
17:14 |
gmcharlt |
yeah |
17:14 |
gmcharlt |
OK, I'll work up a patch right quick |
17:14 |
Bmagic |
ty |
17:19 |
pinesol_green |
[evergreen|Galen Charlton] LP#1152753: upgrade script - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=0161aef> |
17:19 |
pinesol_green |
[evergreen|Mike Rylander] Stamping upgrade scripts for Display Fields and Vandelay regression - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=b930174> |
17:20 |
gmcharlt |
Bmagic: bug 1714594 |
17:20 |
pinesol_green |
Launchpad bug 1714594 in Evergreen "lp1629108_metarecord_constituent_result_reroute.pg test failure" [Medium,New] https://launchpad.net/bugs/1714594 |
17:21 |
* Bmagic |
looks |
17:22 |
Bmagic |
gmcharlt: looks like a great solution |
17:22 |
gmcharlt |
are you in a position to test it right now? |
17:22 |
Bmagic |
You could ditch the "sfaf" off the tail of the success message while you are at it |
17:22 |
Bmagic |
yes, I can teset |
17:22 |
Bmagic |
/teset/test |
17:22 |
gmcharlt |
thanks! (and feel free to get rid of the sfaf in your signoff patch) |
17:23 |
Bmagic |
it will be a few minutes, I gotta get the pgtap stuff installed |
17:24 |
gmcharlt |
kk |
17:43 |
kmlussier |
gmcharlt++ #For all the 3.0 things! |
17:43 |
kmlussier |
Have a nice weekend everyone! |
17:43 |
pinesol_green |
[evergreen|Jason Boyer] LP1714512: Patron Edit Barcode Validation - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=f70f6f6> |
17:45 |
gmcharlt |
Bmagic: the second test, specifically? |
17:46 |
Bmagic |
yes, I commented it out, and I have success. So at least I know that my pgtap stuff is doing it's thing |
17:46 |
Bmagic |
doing some manual checking |
17:47 |
Bmagic |
wait a minute, I thought we addressed this already |
17:51 |
Bmagic |
select metarecord,count(*) from metabib.metarecord_source_map group by 1 having count(*) > 1; |
17:55 |
gmcharlt |
select metarecord,array_agg(source) from metabib.metarecord_source_map group by 1 having count(*) > 1; |
17:56 |
gmcharlt |
that gives me {242,243,244} for 240 in a stock DB |
18:00 |
Bmagic |
yep, I have that in my data, my problem is the function on my test db |
18:01 |
Bmagic |
Sorry, I'm not much help. Does the test work for you? |
18:04 |
gmcharlt |
it does - I'll think I'll just go ahead and push it for a clean testbed |
18:06 |
gmcharlt |
and with that, I'm out for now. have a good weekend, all! |
18:07 |
pinesol_green |
[evergreen|Galen Charlton] LP#1714594: fix lp1629108_metarecord_constituent_result_reroute.pg - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=0bef0c2> |
00:31 |
pinesol_green |
[evergreen|Cesar Velez] LP#1695029-Webstaff Fix Patron Registration page never loading - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=688e8e1> |
00:31 |
pinesol_green |
[evergreen|Bill Erickson] LP#1695029 Patron reg. supports bool opt-in defaults - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=edc503b> |
05:00 |
pinesol_green |
News from qatests: Test Failure <http://testing.evergreen-ils.org/~live> |
06:57 |
|
agoben joined #evergreen |
07:15 |
|
rjackson_isl joined #evergreen |
07:55 |
|
kmlussier joined #evergreen |
12:05 |
|
jihpringle joined #evergreen |
12:10 |
kmlussier |
miker / gmcharlt: Would either of you have tuits to rebase bug 1676608 against current master? |
12:10 |
pinesol_green |
Launchpad bug 1676608 in Evergreen "Copy Alert Persistence and Suppression Matrix" [Wishlist,New] https://launchpad.net/bugs/1676608 |
12:10 |
kmlussier |
I should have time to test it this afternoon. There were conflicts in a lot of files, which made me nervous about resolving them myself. |
12:11 |
Dyrcona |
msh: You can't really get it from the staff client. You can really only see the last two or so who have checked out an item. |
12:11 |
miker |
kmlussier: I can take a look, yes |
12:11 |
kmlussier |
miker++ |
13:07 |
berick |
but still, 30 mins is not OK |
13:07 |
Dyrcona |
Well, and nothing else going on, yeah. :) |
13:07 |
berick |
that too |
13:07 |
csharp |
nothing much going on on my test server at 6 a.m. either ;-) |
13:08 |
Dyrcona |
Test servers are just slow.... Witness my circulation aging attempts. :) |
13:08 |
Dyrcona |
Some kind of unwritten law of computer science. :) |
13:08 |
csharp |
well, I haven't looked lately, but I know we have complaints about slow loading in acq vandelay in general |
13:08 |
csharp |
but I agree that 30 mins is kinda crazy |
13:22 |
berick |
yeah, creating those queued bib recs is slow |
13:23 |
Dyrcona |
TBH, I eschew Vandelay. I've always considered it to be too slow. |
13:23 |
* csharp |
would love to not bother with it but our acq libs need it |
13:24 |
berick |
csharp: maybe time to explain/analyze one of the those queued_bib_record INSERTs |
13:25 |
berick |
updates taking as long too. that might be easier to test. |
13:27 |
Dyrcona |
Yeah.... |
13:29 |
Dyrcona |
Probably some trigger is taking way too long. |
13:30 |
berick |
look for the trigger that calls pg_sleep(16) |
13:39 |
berick |
wonder how many rows are inserted into vandelay.bib_match for each of these records. |
13:40 |
Dyrcona |
Also, how long does vandelay.measure_record_quality take? Looks like it could be run twice. |
13:41 |
Dyrcona |
Ah. I see why it's called twice. Different records. |
13:44 |
miker |
kmlussier: ok, I have a rebased branch that I think is fully resolved. However, if testing goes well, I think a good bit of squashing is in order. pushing the branch now.... |
13:46 |
miker |
kmlussier: http://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/collab/miker/lp1676608_copy_alerts-rebased-again-20170831 |
13:50 |
csharp |
FOR test_result IN SELECT * FROM |
13:50 |
csharp |
vandelay.match_set_test_marcxml(match_set, NEW.marc, match_bucket) LOOP |
13:50 |
csharp |
^^ appears to be the bottleneck |
14:12 |
bshum |
What day is today? |
14:14 |
Dyrcona |
heh |
14:15 |
* bshum |
is ready for his weekend |
14:20 |
* csharp |
is upgrading PINES this weekend, so no weekend |
14:20 |
csharp |
though hoping to move holiday to next Friday, $DEITY willing |
14:22 |
csharp |
resulting query: https://pastebin.com/XwZSSSkn |
14:23 |
csharp |
and that's like basically impossible to test :-/ |
14:23 |
kmlussier |
Ice cream should never be blamed for anything. It is only a force for good. |
14:23 |
kmlussier |
@praise ice cream |
14:23 |
* pinesol_green |
I come to praise ice cream, not to bury them. |
16:30 |
berick |
oh, i don't remember that part |
16:32 |
|
sandbergja joined #evergreen |
16:49 |
|
Christineb joined #evergreen |
17:00 |
pinesol_green |
News from qatests: Test Failure <http://testing.evergreen-ils.org/~live> |
17:22 |
pinesol_green |
[evergreen|blake] LP1655158 Patron Search by Date of Birth - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=baf337b> |
17:42 |
|
jvwoolf left #evergreen |
20:22 |
|
Jillianne joined #evergreen |
23:03 |
gmcharlt |
hmm, I think that test failure is basically a problem with the test itself |
23:05 |
gmcharlt |
besides dropping that static redefinition of unapi.mmr_mra, there isn't a reliable ordering imposed on source_list, nor does it seems that the specific order matters |
01:54 |
|
abowling1 joined #evergreen |
04:31 |
pinesol_green |
News from qatests: Test Failure <http://testing.evergreen-ils.org/~live> |
07:01 |
|
JBoyer joined #evergreen |
07:07 |
|
agoben joined #evergreen |
07:13 |
|
rjackson_isl joined #evergreen |
08:22 |
|
gsams_ joined #evergreen |
08:22 |
|
rhamby_ joined #evergreen |
08:22 |
|
Shae_ joined #evergreen |
08:27 |
csharp |
hmm - my 2.12 test server's marc import from z39.50 is not respecting unicode |
08:28 |
csharp |
it displays fine in z39 view and in MARC edit, then after import the unicode is replaced by non-unicode symbols |
08:28 |
csharp |
not sure where to look |
08:30 |
csharp |
search for what the "Import" button does leads me to OpenILS/xul/staff_client/server/cat/z3950.js, but I lose the thread there |
08:32 |
csharp |
okay - I found the perl |
08:35 |
|
kmlussier joined #evergreen |
08:36 |
* csharp |
wonders if running through XML::LibXML is causing it |
08:45 |
* csharp |
runs off to see if it's happening on master too |
08:54 |
csharp |
okay - it's working fine on my master test server, but broken on 2.12 test server |
08:59 |
|
_adb joined #evergreen |
08:59 |
|
Dyrcona joined #evergreen |
09:04 |
csharp |
ok - definitely not a problem with 2.12 - something local |
09:07 |
|
kmlussier joined #evergreen |
09:16 |
|
yboston joined #evergreen |
09:26 |
|
Dyrcona joined #evergreen |
09:41 |
dbs |
csharp: if the code is identical, maybe a difference in either the locale of the server, or the locale of the database? |
09:42 |
dbs |
Alternately, difference in where yaz packages are getting pulled from? |
09:43 |
dbs |
Or more commonly, actually, duplicated database functions (public.maintain_control_numbers vs. evergreen.maintain_control_numbers) where the old one came from a db restore and the new one was created during upgrade, but isn't first in the search path |
09:52 |
pinesol_green |
Showing latest 5 of 13 commits to Evergreen... |
09:52 |
pinesol_green |
[evergreen|Mike Rylander] Add moment.js to the offline asset list - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=40079db> |
09:52 |
pinesol_green |
[evergreen|Mike Rylander] Remove confusing "session" tab from the offline menu entry -- the code will figure out the correct default tab - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=b77f4cb> |
09:52 |
pinesol_green |
[evergreen|Mike Rylander] Reorder the tabs and adjust the default based on logged-in-ness - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=346cba8> |
09:52 |
pinesol_green |
[evergreen|Mike Rylander] Fix the "404 asset" test - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=23886b4> |
09:53 |
pinesol_green |
[evergreen|Mike Rylander] The ngToast maintainers decided to trick us with a new directory name. Thanks. - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=f1e2631> |
09:57 |
kmlussier |
And...I just remembered that I was planning to write a release notes entry for that one before merging. I'll put that on my to-do list. |
10:00 |
csharp |
dbs: ooh - I'll check those possibilities out thanks! |
10:14 |
|
jvwoolf joined #evergreen |
10:52 |
Dyrcona |
I was going to look at it, or I tried, but ran out of time. |
10:52 |
Bmagic |
ok, that was cryptic |
10:53 |
Dyrcona |
Yeah, trouble is, I've forgotten which bug. :( |
10:54 |
Dyrcona |
I recall kmlussier commenting about adding a regression test, and that's what I was going to try and do. |
10:54 |
kmlussier |
Oh, it's the one for transferring volumes to another record. |
10:55 |
kmlussier |
bug 1411422 |
10:55 |
pinesol_green |
Launchpad bug 1411422 in Evergreen 2.12 "Copy details repeated in search results when item/volume moved with parts attached" [Medium,Confirmed] https://launchpad.net/bugs/1411422 |
10:56 |
Dyrcona |
Yeah, that's it. |
10:58 |
Bmagic |
oh yeah, an oldie but a goodie |
10:59 |
Bmagic |
that code merges onto 2.11.0 but I can't vouch for anything newer |
11:00 |
kmlussier |
Bmagic: The issue with that code is that is has passed user testing, but it needs a regression test. |
11:01 |
Bmagic |
right, sounds like today will be EG developing day! |
11:01 |
Bmagic |
(for me) |
11:01 |
Dyrcona |
I:) |
11:02 |
Dyrcona |
:) |
11:04 |
* kmlussier |
quickly finds something else to merge that will affect Bmagic's search by date of birth branch. |
11:04 |
Bmagic |
ahhhhhhhhhhhhhhhh |
11:12 |
Dyrcona |
Whee! I'm also getting a conflict merging something into master for testing. |
11:14 |
Dyrcona |
Ah, fun. My own coded causing the conflict. :) |
11:14 |
Dyrcona |
At least I know how to resolve it. :) |
11:33 |
|
rjackson_isl joined #evergreen |
12:39 |
|
Christineb joined #evergreen |
13:13 |
kmlussier |
Yay! More merge conflicts! |
13:15 |
Dyrcona |
It seems to be the day for it. |
13:16 |
kmlussier |
Every branch I've tried to test today has one. I think I can resolve this one on my own. |
13:16 |
kmlussier |
Of course, that's what I said a couple of weeks ago before breaking 2.12 |
13:18 |
kmlussier |
That is, one week ago. Time is moving very slowly. |
13:20 |
Dyrcona |
Yeah. We could be approaching an event horizon. |
13:21 |
* Dyrcona |
greps the code for examples of xlst_process used int he database, specifically for mods transformation. |
13:24 |
Dyrcona |
Easy enough... :) |
14:35 |
dbs |
Oh hey, turns out our reports problem only occurs when we request Excel format output. |
14:35 |
berick |
csharp: vandelay <importer> directory looks right in opensrf.xml? |
14:36 |
berick |
... and all NFS mounts are confirmed to be mounted? |
14:36 |
csharp |
berick: yes and yes |
14:36 |
csharp |
I just tested creating files as opensrf from each location |
14:37 |
berick |
i don't think creation is the problem |
14:37 |
JBoyer |
dbs, oh. That sounds vaguely familiar. Do you have all of the various Excel::Whatevs perl mods that Clark needs for that? I thought there was a period that a couple had to be added by hand and if they were missing I'd get that error instead of the expected exploding perl. |
14:37 |
berick |
csharp: problem is acq trying to read the files post-creation |
16:38 |
berick |
thanks |
16:39 |
|
finnx left #evergreen |
16:43 |
miker |
berick: looking at the jquery branch, what do you think about having /common/build/ in the .gitignore, rather than plain /common/? |
16:46 |
berick |
miker: that makes sense, but can't remember if git is smart enough to ignore the parent for an ignored child directory |
16:46 |
berick |
if the only sub-dir is ignored, i mean, which is the case here |
16:47 |
berick |
easy enough to test |
16:47 |
miker |
ah... you mean getting warnings about an "empty" common to git-add? |
16:47 |
miker |
yeah, I'll test that |
16:47 |
berick |
yeah, exactly |
16:48 |
miker |
if it doesn't seem to care, I'll add build. otherwise, I'll leave it as you have it |
16:48 |
miker |
maybe adjust the comment |
16:49 |
berick |
miker: just tested, looks like it's good. |
16:49 |
miker |
rock |
16:49 |
berick |
no warnings when the sub-dir is ignored |
16:49 |
miker |
I'll adjust, remove the comment, and squash into your commit |
16:58 |
pinesol_green |
[evergreen|Bill Erickson] LP#1642086 TPAC Jquery path repair, .gitignore, karma - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=5120189> |
16:58 |
pinesol_green |
[evergreen|Mike Rylander] LP#1642086: Adjust offline resources for jquery support - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=74e1fba> |
16:59 |
miker |
I think I should add an upgrade note about ctx.want_jquery... |
17:01 |
pinesol_green |
News from qatests: Test Failure <http://testing.evergreen-ils.org/~live> |
17:04 |
pinesol_green |
[evergreen|Mike Rylander] LP#1642086: Relase note for jQuery support - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=18d1064> |
17:16 |
|
kakious joined #evergreen |
17:16 |
kakious |
Anyone free to help or not right now? |
17:18 |
kmlussier |
kakious: Some people may have gone home for the day, but some folks may still be around. |
01:07 |
bshum |
kakious: Possibly, what's going on? |
01:08 |
bshum |
Certainly you'll get more folks around later today I suspect |
01:09 |
kakious |
Woo! I can not delete any Organizational Units, even if I run the command on the documentation to update the database and restart apache. |
01:10 |
bshum |
There could be a lot of reasons you're not able to remove an organizational unit from your (test?) system |
01:10 |
kakious |
It is a test system. Any Ideas to pinpoint the cause of it? |
01:11 |
bshum |
If you're trying to remove an org unit via the staff client, I'm not 100% sure that would work out so well. |
01:11 |
bshum |
There might be something in the logs that would explain what it's unhappy about |
01:12 |
bshum |
Did you load the test system with the sample records? Or just a clean test system? |
01:12 |
kakious |
Sample Records |
01:13 |
bshum |
So, you used that --load-all-sample option when creating the database? |
01:13 |
kakious |
Yes, I did |
01:14 |
bshum |
If you use that option it'll populate sample bibs and assign sample copies and users too |
01:14 |
bshum |
And these all belong to the org units you're probably trying to remove |
01:14 |
kakious |
Ahh, so How would I wipe the database and rebuild it? |
01:14 |
bshum |
So there's dependency stuff in place to prevent deltion of org units that have stuff attached to them |
01:14 |
bshum |
The best thing might be to stop your test system |
01:15 |
bshum |
And then re-run the command that builds the database |
01:15 |
bshum |
But this time without that option for --load-all-sample |
01:15 |
bshum |
That will create a database without any sample items or users in it |
01:15 |
bshum |
And that should be easier to manipulate the org unit structure with |
01:16 |
kakious |
Okay |
01:16 |
bshum |
Running that eg_db_config script again will generally drop the pre-existing Evergreen DB and start over fresh |
01:21 |
bshum |
You'll find this channel tends to be most active during weekdays between 9-5 eastern timezone. So there'll be more folks later in the day you can ask for further help too. |
01:27 |
bshum |
Or weird stuff could go wrong with building the database again |
01:47 |
* bshum |
signs off to get some sleep, new week here we go... whee... |
01:56 |
kakious |
Thank you! That fixed it |
05:00 |
pinesol_green |
News from qatests: Test Success <http://testing.evergreen-ils.org/~live> |
08:15 |
|
collum joined #evergreen |
08:41 |
|
jvwoolf joined #evergreen |
08:55 |
|
kmlussier joined #evergreen |
09:21 |
|
collum_ joined #evergreen |
09:22 |
|
jvwoolf2 joined #evergreen |
09:36 |
|
dbs joined #evergreen |
10:16 |
csharp |
I'm seeing an issue when adding a survey that results in this message in the error log: Session cache for thread 0.34420842786521711503929736231 does not match request |
10:17 |
csharp |
I had seen those messages a lot in the logs while testing 2.12/OpenSRF 2.5, but wasn't connecting them with a specific problem |
10:17 |
csharp |
but now I'm nervous |
10:18 |
csharp |
steps: enter Admin -> Local Admin -> Surveys in the XUL client and create a new survey. Clicking save does not save the survey and the "Session cache..." message appears in the logs. |
10:21 |
csharp |
actually, same behavior in web client' |
10:23 |
csharp |
huh - works in the web client on my master server |
10:24 |
csharp |
I get a different error in the logs (Global $r object is not available.) but it allows me to create the survey |
10:27 |
csharp |
fwiw I can edit *existing* surveys, just not create new ones |
10:27 |
csharp |
and existing surveys are working during patron registration, etc. |
10:27 |
bshum |
csharp: https://bugs.launchpad.net/opensrf/+bug/1684970 |
10:27 |
pinesol_green |
Launchpad bug 1684970 in OpenSRF "Proxy setup masks client IP needed by osrf-http-translator" [Medium,Confirmed] |
10:27 |
bshum |
That error you see is similar to what I encountered in another bug that pointed back to that one for OpenSRF 2.5.0 and using nginx proxy |
10:28 |
berick |
csharp: no config required, just install and restart apache |
10:28 |
csharp |
oh - nice |
10:28 |
csharp |
we'll add that to our deb dependencies |
10:28 |
bshum |
So maybe you've got that on your master system, but not your 2.12 test one |
10:29 |
bshum |
Or you're not using nginx proxy |
10:29 |
csharp |
no proxy on the master server, right |
10:31 |
|
kmlussier joined #evergreen |
10:33 |
csharp |
bshum++ berick++ # works! |
13:35 |
miker |
kmlussier: sorry, meeting. /me looks |
13:41 |
miker |
kmlussier: I see a conflict in the first commit, but I suspect that's not your issue, eh? |
13:44 |
miker |
kmlussier: so I ran into 2 confilicts when picking the 8 commits. The solution to both is to keep /both/ change sets, AFAICT |
13:44 |
kmlussier |
miker: There was a conflict in two files when I merged the branch. I resolved them myself, but testing hasn't been going well. I wanted to make sure it wasn't because I did something wrong, though the conflicts seemed rather simple to resolve. |
13:45 |
* kmlussier |
always assumes she's in error before blaming the code. |
13:49 |
Dyrcona |
Speaking of merge conflicts. I am declaring it the end of the line for the alt_patron_summary branch for master. |
13:49 |
Dyrcona |
CONFLICT (modify/delete): Open-ILS/xul/staff_client/server/patron/display.js deleted in Patron Display/Summary Revamp and modified in HEAD. Version HEAD of Open-ILS/xul/staff_client/server/patron/display.js left in tree. |
13:50 |
Dyrcona |
Since we're the only site that uses it, I suppose it doesn't matter much. :) |
14:54 |
Dyrcona |
charter-- |
15:07 |
|
bwicksall joined #evergreen |
16:53 |
|
Christineb joined #evergreen |
17:00 |
pinesol_green |
News from qatests: Test Failure <http://testing.evergreen-ils.org/~live> |
17:05 |
miker |
hrm. inquiring minds want to know... why does that failing pgtap test replace the unapi.mmr_mra function with a static, local copy and then call it instead of testing the version in the database? |
17:18 |
kmlussier |
Huh. When I tested pg tap tests earlier, I must have skipped the ones in the regress directory. |
17:21 |
dbs |
I assume the test was written before the new version was part of the core schema. Removing the CREATE OR REPLACE statement from the test should make it more correct now though, right? |
18:19 |
|
jvwoolf joined #evergreen |
20:00 |
|
Jillianne joined #evergreen |
05:00 |
pinesol_green |
News from qatests: Test Success <http://testing.evergreen-ils.org/~live> |
07:09 |
|
rlefaive joined #evergreen |
07:12 |
|
rjackson_isl joined #evergreen |
07:32 |
|
agoben joined #evergreen |
11:42 |
JBoyer |
gmcharlt++ |
11:43 |
JBoyer |
I didn't realize why we were seeing failures on inserting copies using deleted locations; we had 2 with identical names, one system and one branch that was deleted. |
11:45 |
|
jeffdavis joined #evergreen |
11:45 |
Dyrcona |
Anyway, if anyone comes up with a fix that works, ping me. I'm kinda stuck at the moment.--I was going to test something. |
11:46 |
Dyrcona |
Well, specifically, Lp 1710512 |
11:46 |
pinesol_green |
Launchpad bug 1710512 in Evergreen "Alert message in Open-ILS/web/js/ui/default/opac/holds-validation.js is not translatable" [Medium,Confirmed] https://launchpad.net/bugs/1710512 |
11:46 |
Bmagic |
Has anyone had the xul runner staff client preset an alert box randomly that says "This page uses an unsupported technology that is no longer available by default" ????? |
13:15 |
|
collum_ joined #evergreen |
13:26 |
pinesol_green |
[evergreen|Jeff Davis] LP#1684988: add opt-in check to patron service - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=42528f5> |
13:46 |
jeffdavis |
kmlussier: working branch user/jeffdavis/lp1699566-barcode-completion-fix attempts to clean up that backport - the fix gives a console error when scanning a barcode in item status, but seems to work regardless |
13:47 |
kmlussier |
Dyrcona: Are you still up for testing a fix for 2.12? |
13:47 |
Dyrcona |
I'm just copying the branch name to paste into a terminal. |
13:50 |
Dyrcona |
jeffdavis++ It passes grunt all. I'll have to finish the installation and check item status. |
13:50 |
Dyrcona |
Then, I'll check what I was originally going to check. |
14:15 |
* kmlussier |
takes a look |
14:23 |
Dyrcona |
It's working for me. I'll sign off on jeffdavis' branch. I'll let kmlussier test it and push it if she wants. |
14:24 |
kmlussier |
Dyrcona: If it works for you, go ahead and push it. I didn't know if you were testing the whole thing or just the build. |
14:25 |
Dyrcona |
Well, I just copied and pasted some barcodes into item status. |
14:25 |
Dyrcona |
I'm not sure I have the necessary set up at my working ou to test barcode copletion. |
14:25 |
Dyrcona |
completion. |
14:27 |
kmlussier |
OK, I'll take a look then. |
14:29 |
csharp |
I have seen that before - it's referring to remote XUL I think |
15:59 |
gmcharlt |
fair enough |
16:19 |
|
Jillianne joined #evergreen |
16:25 |
|
mmorgan joined #evergreen |
16:30 |
pinesol_green |
News from qatests: Test Success <http://testing.evergreen-ils.org/~live> |
17:00 |
|
jvwoolf1 left #evergreen |
17:00 |
|
mmorgan left #evergreen |
17:39 |
phasefx |
grabbing 1055 |
04:31 |
pinesol_green |
News from qatests: Test Success <http://testing.evergreen-ils.org/~live> |
07:07 |
|
agoben joined #evergreen |
07:12 |
|
rjackson_isl joined #evergreen |
08:01 |
|
collum joined #evergreen |
11:45 |
JBoyer |
berick++ # that would have taken me a bit to figure out. |
11:46 |
berick |
JBoyer: does that mean it worked? :) |
11:47 |
JBoyer |
Not yet, just getting to where it needs to be. |
11:49 |
berick |
webstaff++ # performing admirably through a 2800-mile long VPN to a modest test server |
11:50 |
berick |
minus the embedded dojo UI's, unfortunately. those take a while to load |
11:51 |
* berick |
looks forward to adding some nginx caching |
11:53 |
kmlussier |
berick: Funny you should say that. I just came across my first case of 'Wow! That loaded slowly' in the web client today. |
11:53 |
* kmlussier |
was retrieving the record holds screen for a very popular title. |
11:55 |
kmlussier |
And then I asked for sorting, which probably wouldn't help matters. |
11:59 |
berick |
kmlussier: view holds, under record details page? |
12:01 |
kmlussier |
berick: Yes, it was a title with 158 holds. It could be the hardware since it was a test server, but I hadn't seen it in other parts of the web client. |
12:01 |
berick |
kmlussier: hm, i can't sort on that page.. is sorting new? |
12:02 |
* berick |
updates |
12:02 |
kmlussier |
berick: No, this wasn't when I was sorting it. It was retrieving holds for a pickup location. Sorry, I just mentioned sorting in relation to a bug I just filed requesting that it be made available. |
14:33 |
berick |
admin -> local admin -> field documetnation |
14:33 |
berick |
lemme see if it works in the browser. (i think it does) |
14:35 |
berick |
so field docs work, but they add a question mark on the field, which has to be clicked to see the docs. so, you're describing the other thing.. |
14:35 |
kmlussier |
berick: It worked when I tested the patron editor way back when. |
14:35 |
* csharp |
has always wondered what "field documentation" means :-) |
14:36 |
berick |
terran: i think you want the org unit setting example text |
14:36 |
kmlussier |
csharp / berick: I just posted a link to the documentation on the general list about 15 minutes ago. |
14:46 |
|
jihpringle joined #evergreen |
15:18 |
|
mmorgan1 joined #evergreen |
15:29 |
|
terran joined #evergreen |
15:32 |
terran |
of course irc freezes on me right when I need it |
15:33 |
terran |
hrrm... for some reason I'm not able to save field documentation on our 2.12.4 test server - I can on our 2.11 server, but it doesn't show up in our form. |
15:35 |
berick |
terran: did you see my comment about org settings for example text? |
15:35 |
berick |
if you want the help info to be permanently visible you'll want to go the OUS route |
15:36 |
terran |
Yes, that sounds like where I need to go |
16:16 |
|
mmorgan joined #evergreen |
16:18 |
terran |
berick++ that's exactly what I was trying to find in the first place, completely overlooked that file - thank you! |
16:26 |
|
khuckins_ joined #evergreen |
16:31 |
pinesol_green |
News from qatests: Test Success <http://testing.evergreen-ils.org/~live> |
16:32 |
|
Jillianne joined #evergreen |
17:02 |
|
khuckins__ joined #evergreen |
17:04 |
|
mmorgan left #evergreen |
17:27 |
|
jvwoolf1 left #evergreen |
17:58 |
pinesol_green |
[evergreen|Dan Wells] Forward-port 2.11.8 upgrade script - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=546428a> |
18:16 |
pinesol_green |
[evergreen|Galen Charlton] forward-port 2.12.4-2.12.5 DB update - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=c77c669> |
20:43 |
gmcharlt |
https://evergreen-ils.org/evergreen-2-11-8-and-2-12-5-released/ |