| 03:25 |
|
Lunchb0x joined #evergreen |
| 07:18 |
|
mrpeters joined #evergreen |
| 07:41 |
|
jboyer-isl joined #evergreen |
| 08:03 |
csharp_ |
so during the vandelay upload step, to which location is the file uploaded? I am expecting it to be in the location specified in <open-ils.vandelay><importer> in opensrf.xml, but I don't see it there |
| 08:04 |
csharp_ |
also not in /tmp on either of the brick heads on my test server |
| 08:28 |
|
kbeswick joined #evergreen |
| 08:36 |
berick |
csharp_: the file is deleted after all the records are queued |
| 08:37 |
|
Dyrcona joined #evergreen |
| 08:42 |
|
Shae joined #evergreen |
| 08:45 |
|
ericar joined #evergreen |
| 08:48 |
|
csharp joined #evergreen |
| 08:50 |
csharp |
berick: I guess I'm trying to see where in the process things are. I'm testing whether the ~250MB file I'm uploading is actually moving since I'm just seeing "Uploading..." on the interface. Just looking for a way to monitor progress |
| 08:51 |
berick |
ah, gotcha |
| 08:52 |
berick |
in that case, yes, you should see a file slowing growing in size in the directory configured under <importer> |
| 08:52 |
berick |
s/slowing/slowly/ |
| 15:01 |
kmlussier |
csharp: My understanding is that our consortia limit the size of their uploads, but I can't remember what limit they used. |
| 15:01 |
csharp |
it's possible that my staff client auth session timed out while it was running too |
| 15:01 |
csharp |
ah - makes sense |
| 15:02 |
kmlussier |
I don't think anyone did a test to see how large the files could get. But I can check. |
| 15:02 |
csharp |
thanks |
| 15:02 |
|
tmccanna left #evergreen |
| 15:05 |
|
tmccanna joined #evergreen |
| 16:10 |
Dyrcona |
MARC::CharSet just loves them to death! |
| 16:13 |
Dyrcona |
gmcharlt: I'll be emailing you some examples a bit later, possibly tomorrow. |
| 16:13 |
gmcharlt |
Dyrcona++ |
| 16:13 |
rfrasur |
Hah! Have been wanting to test some Korean records. How many characters are in the vietnamese charset? |
| 16:14 |
Dyrcona |
Phép lạ của sự tỉnh thức. |
| 16:15 |
Dyrcona |
That's what seems to be causing the problem. |
| 16:15 |
rfrasur |
oh...that's not what I was expecting. |
| 07:47 |
dbs |
paxed: a major part of the value of review & sign-off is reproducing the before / after behaviour in a separate environment, as well as ensuring nothing else breaks unexpectedly as a result. so, not really :/ |
| 07:48 |
* dbs |
is enjoying Canada Day, apparently |
| 07:51 |
paxed |
dbs: disheartening. |
| 07:53 |
dbs |
paxed: it's a time vs. quality thing. We keep on seeing what happens when we push commits that "look good" without actually testing them. |
| 07:53 |
dbs |
Or testing them in a very limited way. And testing in production, really, really sucks for the community. |
| 07:54 |
csharp |
bshum: thanks! |
| 07:57 |
csharp |
dbs: happy Canada Day! |
| 07:58 |
csharp |
not a holiday I take it? ;-) |
| 08:01 |
csharp |
dbs: ah - I see ;-) |
| 08:03 |
|
jasonb-iph joined #evergreen |
| 08:03 |
jcamins |
dbs: have you looked at things like gerritt? |
| 08:06 |
dbs |
jcamins: it's more about testing & reproducing UI behaviour (selenium etc) than code review tools |
| 08:07 |
|
Dyrcona joined #evergreen |
| 08:08 |
jcamins |
dbs: ah. We have both problems with Koha. |
| 08:10 |
dbs |
for example, paxed has a patch that affects 8 or so different dialogues in the staff client. testing that means setting up a clean testing environment, reproducing the problem conditions (possibily requiring setup of special data to provoke the problem), setting up the test env + patch, reproducing the corrected scenarios... and all of that gives us no guarantee that other scenarios haven't been negatively affected by the patch |
| 08:10 |
dbs |
jcamins: I'm not saying gerritt or the like wouldn't be helpful, just a different problem :) |
| 08:21 |
|
finnx joined #evergreen |
| 08:25 |
|
rjackson-isl joined #evergreen |
| 08:34 |
|
laque joined #evergreen |
| 18:12 |
|
konr_revmob joined #evergreen |
| 18:12 |
|
finn1 joined #evergreen |
| 18:13 |
|
finnx1 joined #evergreen |
| 18:14 |
konr_revmob |
Can I test whether, say, the infinite scroll functionality works in my website using evergreen, or its not the appropriate tool? |
| 18:15 |
|
finnx1 left #evergreen |
| 18:18 |
|
finnx1 joined #evergreen |
| 18:19 |
|
finnx1 left #evergreen |
| 07:21 |
|
Dyrcona joined #evergreen |
| 07:32 |
|
jboyer-isl joined #evergreen |
| 07:34 |
|
bkuhn joined #evergreen |
| 08:25 |
csharp |
okay - I'm back to troubleshooting my circ rule issue - the problem is that we have a rule based on a circ modifier called 'dvd' assigned to dvd items. When I use the find_circ_matrix_matchpoint test on an item, patron, and location on our production server, the correct rule matches. When I do the same test on our test server, it picks a different rule. |
| 08:25 |
csharp |
The only thing I've changed is linking a circulation limit set |
| 08:26 |
csharp |
the rule it selects on our test server is based on the item's marc type |
| 08:27 |
pastebot |
"csharp" at 204.193.129.146 pasted "circ policy matching descrepancy" (16 lines) at http://paste.evergreen-ils.org/34 |
| 08:27 |
csharp |
as you'll see in the paste, rule 159 no longer matches |
| 08:27 |
|
timf joined #evergreen |
| 08:30 |
Dyrcona |
@quote random |
| 08:30 |
pinesol_green |
Dyrcona: Quote #21: "< Dyrcona> Writing software is more fun than working." (added by csharp at 09:29 AM, November 29, 2011) |
| 08:36 |
|
kbeswick joined #evergreen |
| 08:37 |
csharp |
created CSVs of a dump of circulation policies on test and production and diffed them - no difference |
| 08:39 |
csharp |
btw - test image is from 6/26, so no substantial differences between the datasets |
| 08:40 |
|
finnx joined #evergreen |
| 08:43 |
|
mmorgan joined #evergreen |
| 08:47 |
Dyrcona |
csharp: I've not ever seen the behavior you described in my environment. If I check something out in production and in development, I get the same matchpoint. |
| 09:26 |
csharp |
I'm using the Default weightset, which has worked fine for us until now |
| 09:28 |
* bshum |
checks to see what that is :) |
| 09:33 |
pastebot |
"csharp" at 204.193.129.146 pasted "default weightset" (7 lines) at http://paste.evergreen-ils.org/35 |
| 09:36 |
bshum |
csharp: Can you paste the rules 139 and 159 from your test server? |
| 09:36 |
bshum |
Curious to see what the rows look like. |
| 09:37 |
pastebot |
"csharp" at 204.193.129.146 pasted "more details on circ limit set setup" (43 lines) at http://paste.evergreen-ils.org/36 |
| 09:37 |
|
rfrasur joined #evergreen |
| 09:38 |
csharp |
I'll paste 139 too |
| 09:38 |
pastebot |
"csharp" at 204.193.129.146 pasted "circ matrix matchpoint 139" (4 lines) at http://paste.evergreen-ils.org/37 |
| 09:39 |
bshum |
What's the copy location of the item you're testing? |
| 09:39 |
bshum |
Just the first thing that jumped out to me looking at rule 159 |
| 09:39 |
|
remingtron joined #evergreen |
| 09:39 |
bshum |
Hopefully 7404 |
| 09:39 |
csharp |
we don't use copy locations in our rules since copy locations are managed at the library level |
| 09:40 |
csharp |
that would multiply our number of rules exponentially |
| 09:40 |
bshum |
But 7404 is in the column for "copy_location" in the paste. |
| 10:03 |
bshum |
Just thinking aloud, but it seems bad to allow copy location to be set for a specific library if they're also creating consortium level rules (or rules in general that affect greater than just them). |
| 10:03 |
csharp |
Indiana's still using script-based circ too, I think |
| 10:04 |
* csharp |
agrees |
| 10:04 |
bshum |
Since we don't let end users create policy, I don't think we've ever tested restricting the level of rules they can create. |
| 10:04 |
rfrasur |
csharp: yes...I think we are (because it breaks from time to time) |
| 10:04 |
bshum |
Or if that's possibly restricted by permission. |
| 10:12 |
rfrasur |
So, explain to me while I'm editing a million call #s - why not to use the "circ as type" attribute? |
| 10:17 |
rfrasur |
hmm, our circ policies are based on circ modifiers |
| 10:17 |
rfrasur |
meh |
| 10:17 |
jeff_ |
But those incorrect bibs should still be fixed -- because the copy-level override for circulate as type will do nothing to fix the other issues caused by the incorrect MARC data -- mostly with searching and display in the catalog. |
| 10:17 |
dbs |
paxed's fixes in bug 1195334 looks like it's probably golden, but because we lack any sort of UI test automation to reproduce the problems before the patch and show that it's fixed after the patch, I'm reluctant to wade into applying & testing it myself |
| 10:17 |
pinesol_green |
Launchpad bug 1195334 in Evergreen "Some data URIs don't define character set" (affected: 1, heat: 6) [Undecided,New] https://launchpad.net/bugs/1195334 |
| 10:18 |
dbs |
and without testing, I'm not going to commit anything. Which is a major part of our QA problem in a nutshell, methinks. (surprise, broken record, whatever) |
| 10:22 |
mrpeters |
is there any way to test a LONG (14 day) grace period without checking out an item and waiting 2 weeks? --- using in-db circ |
| 10:24 |
mrpeters |
i suppose i could check out an item for 1 day and see if it accrues fines over the weekend... |
| 10:26 |
bshum |
mrpeters: I haven't tried it recently, but I think you could edit the circulation entry to be in the past, like 10 days past due or whatnot. |
| 10:26 |
Dyrcona |
mrpeters: Check it out and change the due date to the past? |
| 10:26 |
bshum |
mrpeters: Through the DB |
| 11:25 |
jeff_ |
k. |
| 11:25 |
jeff_ |
i forget that reports have debug output now. :-) |
| 11:25 |
mrpeters |
ya itsnice |
| 11:26 |
* rfrasur |
is running a test report (obviously not the same one...but similar) |
| 11:26 |
rfrasur |
so...in a couple hours.... |
| 11:28 |
mrpeters |
http://pastie.org/private/af01zwkuj3hikoucyobttg |
| 11:30 |
rfrasur |
(is it just me or are Indiana reports taking longer and longer and longer to generate?) |
| 11:33 |
mrpeters |
big database.... |
| 11:38 |
mrpeters |
they all look like normal circs.....except the "migrated" ones have no due date |
| 11:39 |
mrpeters |
http://imageshack.us/a/img838/5477/auvn.png |
| 11:39 |
|
collum joined #evergreen |
| 11:39 |
jeff_ |
mrpeters: er, that contains patron data. |
| 11:39 |
jeff_ |
unless those are test users. |
| 11:40 |
mrpeters |
yeah, guess i better obscure that |
| 11:40 |
mrpeters |
image deleted |
| 11:41 |
mrpeters |
http://imageshack.us/a/img834/102/hj51.png |
| 13:57 |
* rfrasur |
is def not THAT cool |
| 13:58 |
bshum |
jeff_: I have multiple accounts to LP but only get notifications to one as well. I don't think it sends to more than one. |
| 13:58 |
bshum |
Since you're cool and have gapps though, you could probably setup a filter to find LP emails and forward them on and only those. |
| 14:05 |
hopkinsju |
jeffdavis: I added CASCADE to the upgrade script and it completed successfully. It took quite a while but I'm finally done upgrading this test DB to 2.4. OPAC searching is being weird though... |
| 14:05 |
hopkinsju |
Searching takes forever and so far I'm seeing queries that should return results not returning any results on the first try, but oddly returning them on the second attempt. |
| 14:05 |
rfrasur |
Hah! One of those two staff members is already GOING to GenCon (no money from lib needed) |
| 14:06 |
hopkinsju |
I need to have a better way to test that the db upgrades *really* worked well. |
| 14:07 |
bshum |
hopkinsju: Returning on the second attempt sounds like the query ran long and didn't finish till later. And it being cached. |
| 14:07 |
hopkinsju |
bshum: Makes sense |
| 14:07 |
Dyrcona |
hopkinsju: You probably have to reingest. |
| 14:27 |
dbs |
GIN takes more space, more time to build, but is faster |
| 14:27 |
bshum |
faster++ |
| 14:27 |
* csharp |
peruses http://www.postgresql.org/docs/9.1/static/textsearch-indexes.html |
| 14:27 |
jeffdavis |
metabib_title_field_entry_index_vector_idx is a GIN index on our upgraded 2.4 test db |
| 14:27 |
dbs |
and will be required if oleg / alex gets their super-fast text search patches in |
| 14:27 |
rfrasur |
faster++ |
| 14:27 |
* Dyrcona |
has had some recent experience with faster in a different context. |
| 16:09 |
* bshum |
ponders how safe it is to make a copy of m_* migration schemas and then drop them from production DBs. |
| 16:09 |
rfrasur |
you live dangerously, remember? |
| 16:10 |
* rfrasur |
does payroll and prepares to be entertained by bshum living dangerously. |
| 16:10 |
bshum |
rfrasur: You've got a point. And hey that's what test databases are for right? :D |
| 16:11 |
rfrasur |
bshum: that's exactly right. |
| 16:11 |
* rfrasur |
cues music https://www.youtube.com/watch?v=7nqcL0mjMjw |
| 16:13 |
|
stevenyvr2 joined #evergreen |
| 09:02 |
rfrasur |
okay, I got it going. thank you |
| 09:03 |
rfrasur |
okay, thanks sir. see ya later. |
| 09:22 |
|
ericar joined #evergreen |
| 09:27 |
* dbs |
noticed, while testing the upgrade path for the catapostrophe fix from 2.3 - 2.4, that the 2.3-2.4.0 upgrade script will bomb out for anyone who recently installed 2.3 due to having already applied upgrade 0788. I suppose we should move that into its own transaction in the upgrade script. |
| 09:29 |
dbs |
huh, or is that because I installed from rel_2_3 and not a packaged version which might get a different value in 002.schema.config.sql? |
| 09:29 |
* dbs |
looks |
| 09:31 |
dbs |
Nope, that's in the packaged 2.3.8 tarball |
| 09:31 |
|
afonit joined #evergreen |
| 09:32 |
dbs |
and 2.3.7 |
| 09:34 |
|
DPearl joined #evergreen |
| 09:36 |
eeevil |
yeah ... I'll pull 788 into its own chunk. soon |
| 09:36 |
paxed |
bah. character encoding problems in javascript. |
| 13:17 |
hopkinsju |
dbs: gotta run an errand, but will do! |
| 13:25 |
|
ericar joined #evergreen |
| 13:38 |
|
mcooper joined #evergreen |
| 13:52 |
csharp |
circ policy changes (in-db) are immediate, right? no need for autogen/opensrf restart? |
| 13:52 |
* csharp |
has apparently borked circ on his test server |
| 13:53 |
csharp |
same dataset, same ruleset on prod/test, same item, same patron, same, location, different rules are chosen |
| 13:54 |
csharp |
test is picking the default rule, prod selects the correct rule |
| 13:54 |
csharp |
"default rule" = id 1 |
| 13:54 |
csharp |
@monologue |
| 13:54 |
pinesol_green |
csharp: Your current monologue is at least 6 lines long. |
| 13:56 |
mcooper |
csharp: believe they are immediate … delete all rules and circs can't happen, w/o having to restart anything (if I recall correctly) ... |
| 13:56 |
csharp |
ok |
| 18:41 |
jeffdavis |
backups++ |
| 18:41 |
jeffdavis |
@karma backups |
| 18:41 |
pinesol_green |
jeffdavis: Karma for "backups" has been increased 3 times and decreased 0 times for a total karma of 3. |
| 18:41 |
Dyrcona |
Anyway, now I have a chance to test a C version of xpath. |
| 18:42 |
rfrasur |
backups needs more karma |
| 18:42 |
Dyrcona |
backups++ |
| 18:42 |
Dyrcona |
backups times elebenty! |
| 11:34 |
eeevil |
dbs: any thoughts on the end of bug 1187433? |
| 11:34 |
pinesol_green |
Launchpad bug 1187433 in Evergreen "apostrophe search issues in 2.4" (affected: 3, heat: 20) [High,Confirmed] https://launchpad.net/bugs/1187433 |
| 11:34 |
rfrasur |
paxed++ |
| 11:40 |
dbs |
eeevil: Still need to test it, just to be sure |
| 11:40 |
dbs |
but looks good |
| 11:41 |
dbs |
in the mean time, if any QP-knowledgeable folks would care to figure out why a search for "big : bad : groovy" results in 6 "text-search ':*' contains no lexemes" errors, that would be teh awesome :) |
| 11:41 |
rfrasur |
I just have to say, y'all are the sanest, least anger/anxiety/frustration-producing group of people that I deal with (excepting my family). It may be a very low bar, but thanks anyways. |
| 11:42 |
eeevil |
dbs: that's a fair trade ... I'll look |
| 11:45 |
dbs |
eeevil: I spent some time trying to protect empty queries from reaching QP in Search/Biblio.pm, but realized that testing with srfsh with queries like "" or ":*" weren't representative of what actually gets passed in from TPAC (" pref_ou(103)" and the like appended to the end) |
| 11:45 |
dbs |
So I think ultimately QP is the answer :/ |
| 11:46 |
|
jdouma joined #evergreen |
| 11:47 |
eeevil |
yeah ... I think I see where it's coming from. I'm trying to think of a reason why we would want to allow a bare ":" as an atom |
| 11:47 |
kmlussier |
Heads up. The web team meeting will be starting here in 13 minutes. |
| 11:48 |
dbs |
eeevil: in phrase-searches too? |
| 11:49 |
dbs |
(in the real world, most of the bare " : " come from copying/pasting a title into a search box) |
| 11:49 |
eeevil |
dbs: are the :s in "value" for you? (I'm sure you have this documented on a bug ... /me goes to look) |
| 11:50 |
dbs |
eeevil: no, there's no bug, I was researching / bashing my head yesterday |
| 11:51 |
dbs |
eeevil: and yes, the :s are in "value" |
| 11:53 |
* dbs |
recreates a local concerto test database - see "Critical entertainments : music old and new" as an example |
| 11:54 |
dbs |
"La canzone italiana del Novecento" includes 2 " : " segments in its title |
| 11:59 |
|
mcooper joined #evergreen |
| 12:01 |
bshum |
kmlussier: Hmm, time? :) |
| 12:01 |
* bshum |
doesn't know who else is even here... |
| 12:19 |
Rogan_ |
sounds good |
| 12:19 |
bshum |
+1 |
| 12:19 |
moodaepo |
kmlussier: I was thinking the same. +1 |
| 12:20 |
kmlussier |
#info moodaepo to continue working on test site |
| 12:20 |
kmlussier |
Though I think bshum has been working on this one too. |
| 12:20 |
kmlussier |
Who wants to give an update? |
| 12:20 |
bshum |
I'm multi-tasking :) |
| 12:20 |
moodaepo |
bshum has taken on doing a test site [ http://evergreener.net/ ] ..I've just been providing him with support right now. We did discuss plans on moving forward and will be emailing it to the list soon for feedback. |
| 12:20 |
moodaepo |
bshum++ |
| 12:21 |
kmlussier |
It's pretty! |
| 12:21 |
bshum |
The fun thing we learned while working on the wordpress site prototype is dealing with non-javascript-enabled browsers. |
| 12:21 |
bshum |
There are lots of pretty themes, but not all of them function well without javascript-enabled. |
| 12:23 |
moodaepo |
or even one hand :) |
| 12:23 |
kmlussier |
moodaepo++ |
| 12:23 |
bshum |
I'd volunteer, but my email isn't trustworthy right now. |
| 12:24 |
kmlussier |
#action moodaepo to e-mail link to test site to the list for feedback. |
| 12:24 |
kmlussier |
moodaepo: That's the general list, right? |
| 12:24 |
Rogan_ |
I would say yes. |
| 12:24 |
moodaepo |
kmlussier: Yup |
| 12:25 |
kmlussier |
Anything else before we move on to the next action item? |
| 13:28 |
rfrasur |
rock on |
| 13:36 |
|
kbeswick joined #evergreen |
| 13:37 |
|
b_sage joined #evergreen |
| 13:39 |
DPearl |
Event/trigger question. I have created a clone of the hold available email event (consortium-level) for a library that wants to include a special message in the email. When testing, the first try got the library's handler; the second try got the consortium handler. I can see why this might have happened, but it seems to me to be incorrect behavior (going up a level). Or is this desirable? |
| 13:42 |
bshum |
DPearl: So, in practice, you cannot have both a consortium level hold available and also a library specific one. |
| 13:42 |
bshum |
Because the event will fire off both. |
| 13:42 |
bshum |
or at least, that's been my experience. |
| 16:58 |
hopkinsju |
bshum: Did that answer your questoin? Looks like it's in the evergreen schema. |
| 16:58 |
bshum |
hopkinsju: Yes, that helps. Thanks. |
| 17:05 |
pastebot |
"hopkinsju" at 204.193.129.146 pasted "Ok, now this is weird..." (58 lines) at http://paste.evergreen-ils.org/31 |
| 17:07 |
gmcharlt |
Dyrcona: did you happen to make the binary MARC record available? I'm lhappy to add test cases for MARC::Charset |
| 17:08 |
Dyrcona |
gmcharlt: I didn't because I was able to get mostly what I needed from yaz-marcdump, plus I've been having fun with other things today. |
| 17:08 |
Dyrcona |
gmcharlt: I think this file is a mix of records in latin 1 and marc 8. |
| 17:08 |
gmcharlt |
I'd appreciate having it if you get a spare moment |
| 17:20 |
|
mllewellyn1 left #evergreen |
| 17:20 |
bshum |
dbs: Seems to me that tsvector_concat is something we can safely drop away if it's no longer in the code base. Like so many other functions that get stuck lying around. |
| 17:21 |
hopkinsju |
gmcharlt: *dum dum duuuuum* "$user",public |
| 17:21 |
gmcharlt |
hopkinsju: k, thought so -- when your test DB finishes resyncing, I suggest running the following before trying the (unmodified) upgrade script: |
| 17:21 |
gmcharlt |
ALTER DATABASE evergreen SET search_path TO evergreen, public, pg_catalog; |
| 17:22 |
bshum |
gmcharlt++ |
| 17:22 |
hopkinsju |
gmcharlt: Thank you, I will try that. |
| 17:22 |
hopkinsju |
Gonna have to let this go and check back later though. Gotta get my daughter to karate. |
| 20:26 |
rfrasur |
so they (whoever they are) may not understand what all that means, but can get a broad idea and have a little higher comfort level in talking w/ people re: more technical stuff. |
| 20:26 |
* rfrasur |
saw that with the feed as well. |
| 20:26 |
rfrasur |
I was all excited that 2015 was going to be in Grand Rapids...until it was 2009 or 10 |
| 20:26 |
bshum |
Heh |
| 20:28 |
bshum |
rfrasur, I'm going to be modifying the wordpress prototype for a moment. Want to test out something with a different theme. |
| 20:28 |
rfrasur |
I am legitimately excited about the direction the website is going, btw. I think it'll be much more accessible. |
| 20:28 |
rfrasur |
(and not in an ADA sort of way, but maybe that, too) |
| 20:28 |
rfrasur |
okie |
| 08:54 |
csharp |
circ_policies-- |
| 08:59 |
Dyrcona |
csharp: We think we're successfully limiting with limit sets. |
| 08:59 |
|
ericar joined #evergreen |
| 09:02 |
csharp |
Dyrcona: thanks - looks like my first problem is that the circ policy I'm expecting to be chosen isn't being chose |
| 09:02 |
csharp |
n |
| 09:03 |
csharp |
so now I'm playing with weights, which is pretty complex |
| 09:04 |
* csharp |
is *so* glad we have find_circ_matrix_matchpoint() to test with |
| 09:04 |
tsbere |
csharp: Between poking at our mail server I can probably answer questions about some of that for ya |
| 09:05 |
tsbere |
csharp: For note, easy way to limit by circ mod: Create a circ matrix line that matches the circ modifier and as little else as possible with no circulate flag or rules. Attach limits to *that* rule with fallthrough flag checked. |
| 09:08 |
csharp |
tsbere: thanks for that tip |
| 09:41 |
tsbere |
Then I would assume I was wrong. ;) |
| 09:41 |
csharp |
heh |
| 09:44 |
pinesol_green |
[evergreen|Mike Rylander] Only attempt to map copies once per hold - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=fceea3d> |
| 09:44 |
paxed |
haha. testing some improvements for bug 1156545 - i guess a bill for $1234567.80 is a bit too much: ERROR: numeric field overflow |
| 09:44 |
pinesol_green |
Launchpad bug 1156545 in Evergreen "Currency symbol and format should not be in po-file translatable texts" (affected: 1, heat: 6) [Medium,Triaged] https://launchpad.net/bugs/1156545 |
| 09:46 |
senator |
we have lots of fields defined as numeric(6,2), although depending on the currency that could be too limiting i suppose |
| 09:46 |
paxed |
it's unlikely the patron bill would hit that much. |
| 14:12 |
|
kmlussier joined #evergreen |
| 14:16 |
jeffdavis |
so, regarding bug 1187433 ... |
| 14:16 |
pinesol_green |
Launchpad bug 1187433 in Evergreen "apostrophe search issues in 2.4" (affected: 3, heat: 20) [High,Confirmed] https://launchpad.net/bugs/1187433 |
| 14:16 |
jeffdavis |
We're doing a 2.2->2.4 upgrade, so my understanding is I just need to integrate this commit into our db upgrade stuff: http://git.evergreen-ils.org/?p=working/Evergreen.git;a=commitdiff;h=1b64d6e |
| 14:17 |
jeffdavis |
Assuming that's correct, I can try it out in a test environment tomorrow. |
| 14:21 |
|
kmlussier1 joined #evergreen |
| 14:24 |
|
jrshaw joined #evergreen |
| 14:26 |
|
kbeswick joined #evergreen |
| 15:06 |
jeffdavis |
It looked to me like the necessary changes from the other commits are in the upgrade script, but it's a long ticket and I get a little paranoid before major version upgrades. ;) |
| 15:08 |
jeffdavis |
s/ticket/bug/ |
| 15:09 |
bshum |
It's healthy to be mindful of potential pitfalls. |
| 15:24 |
jrshaw |
Oh the fun. Back to the 2.4 client Install... Went to lunch. The system hibernated. Powered up. corrupted system image. discarded the hiber-image and did a clean reboot. Full functionality has been restored. I can repeatedly start the Client and it works. Now to find a working 2.4 test server that works... |
| 15:25 |
jrshaw |
demo.ils.edoceo.com produces a "There was an error testing the hostname." error |
| 15:26 |
csharp |
jrshaw: so are your complaints purely about getting the client up and running, or are you installing a server too? |
| 15:28 |
jrshaw |
I'm taking this one step at a time. I've decided to work on Clint configuration since that would be a simpler and shorter process. just need to know how to interface the client to the test server. |
| 15:28 |
kmlussier |
jrshaw: demo.ils.edoceo.com is working for me. You may need to add a SSL Exception for the server. |
| 15:29 |
kmlussier |
Or, I should say, it would work if I had the right staff client version. |
| 15:30 |
jrshaw |
So you bumped into that problem (wrong client version) too... |
| 10:33 |
mmorgan1 |
seems like it's possible for a barcode scanner to feed in digits faster than they can register in evergreen |
| 10:34 |
rfrasur |
hmm, I haven't seen that but I'm not with the scanners much anymore either. |
| 10:36 |
mmorgan1 |
rfrasur: btw, regarding the upc, you may be able to program your barcode scanners not to recognize these, as long as your book barcodes aren't the same kind |
| 10:37 |
csharp |
mmorgan1: a simple test might be to scan the same barcodes into a text editor and see if the errors persist |
| 10:38 |
csharp |
in our experience, those kinds of mis-scans are the fault of the scanner itself FWIW |
| 10:38 |
csharp |
(or *ahem*, staff) |
| 10:38 |
rfrasur |
mmorgan1: you're right, we probably could. but, I'm the IT department (it's sorely lacking) and the everything else, and decided it was easier to move the barcodes away from the UPC (they're never on the back anymore) and explicitly teach the full staff re: barcodes in general. The obnoxious of the tutorial and the prospect of getting it again was a deterrent. |
| 10:40 |
csharp |
and "strict barcode" doesn't stop the creation of invalid barcodes - it just checks for them when scanning |
| 10:40 |
|
dboyle joined #evergreen |
| 12:49 |
|
zerick joined #evergreen |
| 13:00 |
|
mtcarlson joined #evergreen |
| 13:00 |
mcooper |
I've been trying to convince people that new is exciting and full of potential for the better part of a year =) |
| 13:05 |
b_bonner |
Hi all. Our staff is starting to test the OCLC number scheme change that is starting next month, and noticed something quite odd. If an 001 OCLC number is the new style with "on" followed by 10 digits (on3987654321), it is NOT searchable in the opac (keyword or identifier). However, it IS searchable if it is |
| 13:05 |
b_bonner |
on" followed by 11 or 12 digits (on39876543211). Can someone help reproduce this and see if it's not just us? |
| 13:05 |
b_bonner |
I've been able to change the oclc number on the same record back and forth between and can confirm this scenario on our system |
| 13:07 |
b_bonner |
TCNs 1283817 (10 digit) and 1283816 (11 digit) on catalog.kcls.org if you want our examples |
| 13:15 |
dbs |
b_bonner: looks like it should be indexed and retrievable via identifier|scn ... |
| 13:18 |
dbs |
b_bonner: but right now catalog.kcls.org only seems to be returning 500 server errors :/ |
| 13:19 |
dbs |
in theory, if it was running, http://catalog.kcls.org/eg/opac/results?query=identifier|scn:3987654321 would give you what you're looking for |
| 13:29 |
|
kmlussier joined #evergreen |
| 13:30 |
b_bonner |
it is strange that identifier search on 001 works on other length entries, just not on+10 |
| 13:30 |
dbs |
b_bonner: it seems likely that you have something set up locally to do special things that don't match the Evergreen out-of-the-box experience. Hard to help with that :/ |
| 13:32 |
b_bonner |
dbs: hmm, thanks. will keep digging. Can you do me a favor and try changing an 001 on your test system to "on54987654321" and see if it can find it via keyword or identifier search? |
| 13:35 |
b_bonner |
dbs: and if not, does 11 digit? (on39876543211) |
| 13:40 |
csharp |
b_bonner: you might also poke around in the metabib tables to see if entries for each of those records are present |
| 13:40 |
dbs |
http://laurentian-test.concat.ca/eg/opac/results?query=identifier|scn:on54987654321 works |
| 13:41 |
dbs |
... but it's not getting (OCoLC)54987654321 as a 035$a like I would have expected. |
| 13:41 |
dbs |
possibly because we have an institutional ID set? hrm. |
| 13:42 |
b_bonner |
csharp: first thing I did. every thing looks identical between them in metabib.identifier_field_entry between them when 10 or 11 digits, just search failing on 10 |
| 13:42 |
csharp |
hmm |
| 13:44 |
b_bonner |
dbs csharp: query captured: http://pastebin.com/VpAteZRd |
| 13:44 |
dbs |
http://laurentian-test.concat.ca/eg/opac/results?query=identifier|scn:on39876543211 also works |
| 13:45 |
dbs |
but really, the "on" should be stripped off |
| 13:45 |
b_bonner |
dbs: any results without the scn? |
| 13:45 |
dbs |
http://laurentian-test.concat.ca/eg/opac/results?query=identifier:on39876543211 works fine too |
| 13:45 |
b_bonner |
we have an identifer set up (accession) on the 001 tag |
| 13:46 |
dbs |
Yeah, that's an out of the box thing |
| 13:46 |
b_bonner |
and without scn on the 10 digit? |
| 13:46 |
dbs |
http://laurentian-test.concat.ca/eg/opac/results?query=identifier:on54987654321 works too |
| 13:47 |
dbs |
Note that our system is set up to replace the 001 with the bib ID each time, so the results will show 001 739015 |
| 13:47 |
dbs |
But you can see the 035 $a that were added. |
| 13:48 |
b_bonner |
dbs: yeah, that changes the scenario quite a bit |
| 13:48 |
* dbs |
tries an ocn prefix, that works too. |
| 13:48 |
dbs |
b_bonner: why? |
| 14:31 |
jeffdavis |
dbs: we don't have the 8 latest commits in rel_2_4 yet |
| 14:32 |
jeffdavis |
i'll try to integrate them after hours today |
| 14:32 |
dbs |
lemme tell you, it's nice to be down to 4,000 WARN messages today |
| 14:36 |
jeffdavis |
yeah, i'd like that fix - our test server osrfsys.log has 60K WARN messages from the past 36 hours |
| 14:36 |
jeffdavis |
or I guess those multiple fixes |
| 14:37 |
* jeffdavis |
adds rebase to todo list, says goodbye to any remaining time off this weekend ;) |
| 14:37 |
dbs |
https://bugs.launchpad.net/evergreen/+bug/1192710 was a pretty good one too |
| 14:37 |
pinesol_green |
Launchpad bug 1192710 in Evergreen "QP uses numeric cmp operator for comparing strings, fills logs with warnings" (affected: 1, heat: 6) [Medium,New] |
| 14:37 |
dbs |
not yet signed off or committed |
| 15:19 |
csharp |
dbs: holy moly |
| 15:19 |
bshum |
Maybe there's something wonky there that's taking too long to process out. |
| 15:19 |
dbs |
kmlussier: it would be fun to be able to poke at your system to see the SQL that's getting generated and to enable the timelog for that part slowness |
| 15:19 |
bshum |
Blah |
| 15:20 |
bshum |
But of course, my only test server is running the custom new code for patron UI. |
| 15:20 |
bshum |
So that throws a kink in my testing :( |
| 15:20 |
csharp |
hrmm - I just got the message too |
| 15:20 |
bshum |
timelog++ |
| 15:20 |
csharp |
lemme try the original title reported as an example |
| 15:20 |
kmlussier1 |
csharp, bshum: I get the confirmation message on 2.3 |
| 15:20 |
bshum |
So then it's just csharp :( |
| 15:21 |
bshum |
Maybe it's some weird local customization run amok? |
| 15:22 |
bshum |
kmlussier1: You tested it via the staff client right? On behalf of a patron? I think that's where we're looking. |
| 15:22 |
csharp |
hmm - the original example (with 250+ copies attached) *doesn't* show the message |
| 15:22 |
kmlussier1 |
Yes, I followed the steps in the bug report. |
| 15:23 |
csharp |
so maybe the holdings are a factor? |
| 15:27 |
pinesol_green |
Dyrcona: It's all parts's fault! |
| 15:28 |
|
dboyle joined #evergreen |
| 15:28 |
Dyrcona |
csharp: There is no such thing as a normal library. |
| 15:28 |
bshum |
Nice, I apparently crashed my test server trying to place a hold via the new patron UI. |
| 15:28 |
* bshum |
adds that to the long list of things to work out :( |
| 15:29 |
|
kmlussier1 joined #evergreen |
| 15:29 |
|
jboyer-isl joined #evergreen |
| 15:32 |
|
kmlussier joined #evergreen |
| 15:34 |
* Dyrcona |
imagines a dynamic battle for survival between kmlussier and her evil clone, kmlussier1. |
| 15:34 |
bshum |
Doesn't seem to be a parts problem either. Though I haven't found bibs with lots of holdings to try further yet. |
| 15:34 |
bshum |
Dyrcona++ # I would watch that movie. |
| 15:35 |
bshum |
... uptime 10 minutes for the test server. Well that's... interesting. |
| 15:35 |
Dyrcona |
You caused it to reboot itself? |
| 15:36 |
Dyrcona |
I'd check the logs very carefully. It likely has nothing to do with what you were doing in Evergreen. |
| 15:36 |
bshum |
Yeah |
| 15:59 |
|
edoceo joined #evergreen |
| 16:01 |
bshum |
Hmm, it does seem noticeably slower though when I do try it against bibs with large number of holdings. |
| 16:02 |
bshum |
And the time it took to go from Submit to successfully placed took longer I mean. |
| 16:02 |
kmlussier |
bshum: Yes, it was much slower for me too. My first test on the record with just a few copies went through very quickly. |
| 16:04 |
kmlussier |
bshum: Did you say you had the alternate patron editor on the client where you were testing this? |
| 16:04 |
bshum |
kmlussier: I am using that, yeah. |
| 16:05 |
bshum |
kmlussier: But it's not very different. The issue I encountered previously was because the server suffered some mysterious reboot :( |
| 16:05 |
kmlussier |
I was just noticing that the catalog search/place holds screen loads in a different tab instead of being embedded in that patron frame. I wasn't sure if that would make a difference. |
| 10:22 |
|
BigRig joined #evergreen |
| 10:23 |
|
BigRig_ joined #evergreen |
| 10:28 |
krvmga |
dbs: i'm not sure that the text in the record thought holds water. the first and the fourth returns have less text that the sixth return. |
| 10:28 |
csharp |
btw, if there is a "intro to evergreen hacking" in the works, I'd love to be a test dummy for that project ;-) |
| 10:29 |
krvmga |
csharp: is there such a thing? because i'd be all 'me, too' on that. |
| 10:30 |
csharp |
krvmga: someone ( Dyrcona? ) mentioned it as an "it would be nice if..." type thing |
| 10:31 |
Dyrcona |
Yeah, that was me. I think kivilahtio's work on debugging could be cleaned up into a nice chapter. |
| 13:27 |
tsbere |
That largely falls into login type defs, though |
| 13:27 |
bshum |
Heh |
| 13:27 |
bshum |
Gotcha. |
| 13:27 |
jihpringle |
i think part of the problem was in earlier versions of our testing server I wasn't getting the red bar for staff but I do now |
| 13:28 |
jihpringle |
thanks all |
| 13:36 |
* rfrasur |
has conquered the state system and reported and needs chocolate. |
| 13:37 |
rfrasur |
@love chocolate |
| 13:37 |
pinesol_green |
rfrasur: The operation succeeded. rfrasur loves chocolate. |
| 14:33 |
kmlussier |
Sure. It probably won't happen until after ALA and my subsequent vacation. |
| 14:33 |
gmcharlt |
kmlussier: would you prefer to report back during the August meeting, then? |
| 14:34 |
kmlussier |
No, that gives a couple of weeks for discussion. I should have something to report. |
| 14:34 |
gmcharlt |
OK |
| 14:34 |
gmcharlt |
moving on |
| 14:34 |
gmcharlt |
#topic Announcement: Conference call for discussing organizing testing efforts |
| 14:35 |
gmcharlt |
sborger: you have the floor |
| 14:35 |
sborger |
Rogan, Andrea and I are planning a conference call on July 2 to further discuss organizing test efforts. |
| 14:35 |
sborger |
I figured that I had some very basic questions about where to get started and how to get my local staff involved so others probably do as well. |
| 14:35 |
sborger |
We will come up with a plan and share it at the next board meeting. |
| 14:36 |
gmcharlt |
#info Shauna, Rogan, and Andrea are planning a conference call on July 2 to further discuss organizing test efforts. |
| 14:36 |
gmcharlt |
any questions for sborger? |
| 14:36 |
sborger |
Let me know if you are interested in joining the conference call right away and keep in mind that we will most likely look for volunteers in the future as well. |
| 14:37 |
Rogan |
And the goal is to expand involvement so some of it may seem simple but anything that furthers the community through engagement and the work is worthy I think. |
| 14:38 |
montgoc1 |
What time on July 2? |
| 14:42 |
kmlussier |
Just a general comment. I've been very pleased with teh amount of communication with this release. Thanks Dan! |
| 14:42 |
kmlussier |
dbwells++ |
| 14:42 |
yboston |
I just wanted to say thanks for trying out a new approach, not that the older approaches were bad |
| 14:43 |
dbwells |
Thanks, all. So far so good, but the only real test will be the actual release :) |
| 14:43 |
gmcharlt |
thanks, again |
| 14:43 |
gmcharlt |
moving on |
| 14:43 |
gmcharlt |
#topic Grants and fundraising |
| 08:39 |
|
kbeswick joined #evergreen |
| 08:46 |
kivilahtio |
everybody: berick: eeevil: I managed to get the debugger working. It was more simpler than I thought. I wrote a small tutorial about debugging and I would appreciate some feedback before I publish it under dokuwiki->"Project OpenSRF, the framework underlying Evergreen". https://docs.google.com/document/d/1CGMPWG2Pb5_mhnnEzXywfkQTnp8OeCdMivjd9Pap_ow/edit?usp=sharing |
| 08:47 |
Dyrcona |
kivilahtio++ #whether this works or not. |
| 08:47 |
kivilahtio |
It works for me |
| 08:48 |
kivilahtio |
but might not work for all services, tested with open-ils.serial |
| 08:49 |
Dyrcona |
kivilahtio: I'll gladly test it with other services today. If this works or only needs slight modifications to work everywhere, then it is a god-send. |
| 08:49 |
|
finnx joined #evergreen |
| 08:50 |
|
Rogan_ joined #evergreen |
| 08:50 |
kivilahtio |
Dyrcona: Happy to hear that. |
| 09:18 |
Dyrcona |
kivilahtio: Yes, found it. |
| 09:18 |
kivilahtio |
but to sum it up we are talking about normalizing capitalized author names |
| 09:20 |
Dyrcona |
kivilahtio: You specify running as the opensrf user, but I've already installed OpenSRF and Evergreen on my workstation as my own user account, so that should be the same as running as opensrf user, right? (Just making sure.) |
| 09:20 |
kivilahtio |
Dyrcona, right |
| 09:20 |
kivilahtio |
that is the "advanced" part |
| 09:20 |
kivilahtio |
well I havent tested it but that is what I would have done had I known this |
| 09:29 |
pinesol_green |
[evergreen|Bill Erickson] LP 1177388 'Add to Po' Honors default copy count - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=aae36ea> |
| 09:30 |
berick |
@quote add <Bender> An infinite loop? I don't have time for that! |
| 09:30 |
pinesol_green |
berick: The operation succeeded. Quote #59 added. |
| 12:32 |
rfrasur |
dbs: yeah |
| 12:32 |
Dyrcona |
dbs: In 2.3.7, I think it has to be passed in as 1 otherwise it is zero..... |
| 12:32 |
|
acoomes joined #evergreen |
| 12:33 |
frank |
Dyrcona: I changed the default value from 1 to 0 and I tested it, I looks well, The system generated the bill |
| 12:33 |
Dyrcona |
I would have to checkout a 2.3 branch, but master ignores the grace period. |
| 12:34 |
Dyrcona |
frank: Grace period can also be set from config.circ_matrix_matchpoint and config.rule_recurring_fine. |
| 12:35 |
Dyrcona |
These would affect fine generation at checkin if using in-db circ rules. |
| 15:04 |
eeevil |
it looks like simply delaying the execution of Open-ILS/src/sql/Pg/version-upgrade/2.3-2.4-supplemental.sh until after you run 2.4.0-2.4.1-upgrade-db.sql should be enough |
| 15:07 |
dbs |
eeevil: agreed, but probably worthwhile munging the 2.3-2.4 upgrade to include the good metabib function bodies, just in case |
| 15:08 |
eeevil |
dbs: well, the 2.3-2.4 is 2.4.0 specific, so you'd run the 2.4.0-2.4.1 script anyway, right? |
| 15:09 |
jeffdavis |
I had been planning to go live on 2.4.0 since we don't have time to test 2.4.1, but I dunno how much of a consideration that sort of situation should be here |
| 15:10 |
dbs |
eeevil: you might, if the 2.3-2.4 script didn't say "Now run supplemental.sh" right at the end of it? |
| 15:10 |
eeevil |
jeffdavis: there are significant bug fixes that will exist in 2.4.0, fwiw. the apostrophe stuff is just one of them |
| 15:10 |
* dbs |
was about to recommend to jeffdavis to skip 2.4.0 :) |
| 10:54 |
|
fparks_ joined #evergreen |
| 10:54 |
|
fparks_ joined #evergreen |
| 11:00 |
|
dboyle joined #evergreen |
| 11:02 |
jeffdavis |
The clipboard thing came up in our 2.4 testing, and the response has been "Ok, let's update the documentation and notify libraries that it's changed." |
| 11:03 |
dbs |
jeffdavis++ # I'm with you and phasefx as far as "all other software works this way" |
| 11:03 |
csharp |
bshum++ # suggesting using the linux client |
| 11:03 |
csharp |
I was able to resolve one of the "stuck" accounts |
| 11:21 |
jcamins |
kmlussier: yes please! |
| 11:21 |
jcamins |
New libraries are more fun, so I really ought to know these things. |
| 11:21 |
jcamins |
Ruth: any idea who assigns in Indiana? |
| 11:22 |
kmlussier |
dbs: Sure, what we really need is usability testing and experts in UI design. But I'm preaching to the choir. :) |
| 11:22 |
Ruth |
hmm, I think you'd need to talk with jboyers-isl or Shauna or our new EG coordinator...Anna...I'll look up contact info and pm you |
| 11:22 |
jcamins |
Thanks! |
| 11:22 |
Ruth |
hmm, or not...it's public information. Hold on. |
| 12:46 |
rfrasur |
okay. |
| 12:46 |
phasefx |
rfrasur: if code were legos, OpenSRF would be some larger blocks made up of the legos, and Evergreen would be legos springing off of the OpenSRF blocks :D |
| 12:46 |
phasefx |
we need a car analogy too |
| 12:47 |
bshum |
dbs: looks good to me. Tested and I'm not seeing any noise for that one anymore. |
| 12:47 |
phasefx |
OpenSRF is chassis |
| 12:47 |
bshum |
dbs: I'll get it pushed in a moment. |
| 12:47 |
rfrasur |
phasefx: That sounds like a mess of legos |
| 13:28 |
kmlussier |
Dyrcona: Probably not. |
| 13:29 |
Dyrcona |
kmlussier: OK. As you may already know we're changing our network provider this weekend and will have different IP addresses on Monday. |
| 13:29 |
Dyrcona |
I figured that I'd just build a new VM rather than reconfigure the one that I'm currently running. |
| 13:29 |
kmlussier |
ok. I'm hoping to test all of those branches over the next couple of days. |
| 13:43 |
|
ktomita_ joined #evergreen |
| 13:48 |
|
dboyle_ joined #evergreen |
| 13:49 |
|
dexap joined #evergreen |
| 15:26 |
Dyrcona |
Or, wait... Is your database connection configured correctly? |
| 15:32 |
Dyrcona |
Polo: Did you do eg_db_config.pl? |
| 15:32 |
Polo |
Sorry I had stepped away |
| 15:33 |
Polo |
Everything was working correctly yesterday and then we had someone truncate the usr table. which isn't that big of an issue as we are still in a test env |
| 15:33 |
Polo |
so I was trying to add the user back. I don't think anything changed with the database connection |
| 15:33 |
Polo |
is there a way I can test it correctly? |
| 15:36 |
Dyrcona |
You'll want to look in opensrf.xml and make sure that the database credentials are correct for the storage service. That is the one that seems to be failing in your paste. |
| 15:38 |
Polo |
Ok thanks for the point to the right spot :D |
| 15:45 |
|
Pibbits joined #evergreen |
| 12:08 |
DPearl |
csharp: Haven't checked settings-tester.pl |
| 12:08 |
csharp |
oh wait - that's EG |
| 12:08 |
bshum |
Right. |
| 12:08 |
csharp |
hmm - it'd be nice to have for the opensrf testing step, though, huh? |
| 12:09 |
* bshum |
still dislikes how opensrf is a separately installed thing. When will we just bundle it all together already :D |
| 12:09 |
|
acoomes joined #evergreen |
| 12:10 |
pastebot |
"DPearl" at 204.193.129.146 pasted "ejabberd.cfg" (644 lines) at http://paste.evergreen-ils.org/28 |
| 14:28 |
phasefx |
the diff -b thing gmcharlt pointed out was reassuring |
| 14:29 |
bshum |
kayals: Bear with us for a moment, there's a developer meeting happening for the next little while. We'll be done soonish. |
| 14:29 |
kayals |
sure. |
| 14:29 |
gmcharlt |
dbwells: one thing I didn't specifically test was that code using heredocs remained unbroken |
| 14:29 |
gmcharlt |
(or at least in its current state of brokeness or not ;) |
| 14:30 |
eeevil |
gmcharlt: that's where my fear lies, but dbwells' logic seems sound in first analysis |
| 14:30 |
gmcharlt |
agreed, the logic seems sound |
| 14:30 |
dbwells |
At a few stages I ran a recursive 'perl -c' over the whole set, and at this point the output from those is identical. |
| 14:36 |
eeevil |
certainly ... thanks! |
| 14:38 |
dbwells |
so... who wants to sign off? |
| 14:39 |
bshum |
On the small steps first? +1 to small steps |
| 14:39 |
gmcharlt |
my view -- I'm comfortable with pushing the whitespace change provided somebody explicitly tests the heredocs; alas, I doubt I have any tuits for that this week |
| 14:39 |
gmcharlt |
and in any event, I'd rather that it be done, if done at all, sooner rather than later |
| 14:41 |
eeevil |
dbwells: is it only perl modules (*.pm), or all perl-type files? |
| 14:41 |
dbwells |
Well, let's not hold up the meeting. I'll run a few more tests, make sure the branch is up-to-date, then see if I can round up a volunteer to jump with me. |
| 14:41 |
|
kayals joined #evergreen |
| 14:42 |
bshum |
Adding some dates to the notes |
| 14:42 |
bshum |
Does anyone have anything about Dan's suggested dates for the next round of commit action? |
| 14:42 |
berick |
heh, dbwells and louise, flying over the cliff |
| 14:42 |
bshum |
They seemed reasonable to me. |
| 14:43 |
bshum |
#info 7/1 - suggested last day for targetting bugs/features at 2.5-m2 |
| 14:43 |
bshum |
#info 7/2-7/12 - Suggested period to focus energy on reviewing/committing m2 |
| 14:43 |
bshum |
bugs/features |
| 14:44 |
bshum |
#info dbwells working on whitespace cleanup; will do more tests and find others |
| 14:44 |
|
bkuhn joined #evergreen |
| 14:44 |
dbwells |
eeevil: The command as written is limited to the *.pm. I looked briefly for other common file patterns, and came up empty. I also grepped for tabs in the whole perlmods dir after running the commands, and found just one in a test file, so I figured that was close enough. |
| 14:44 |
bshum |
Anything else about 2.5 before we move on? I'd like to have a short word on the next maintenance releases. |
| 14:44 |
eeevil |
(one last thing re whitespace ... it's really just HEREDOCs with space in front. for those that want to test, it looks like circ, actor, cat, search and resolver-resolver services, and added content, exporter, tpac and supercat web stuff could all break .... if they're not broken, things are looking good) |
| 14:45 |
eeevil |
I found that using `ack '<<"' --type=perl|grep \.pm|cut -f1 -d:|sort -u` |
| 14:46 |
dbwells |
eeevil: Thanks for the list. In my testing, I believe every service at least started, but it never hurts to triple-check. |
| 14:46 |
eeevil |
and `ack "<<'" --type=perl|grep \.pm|cut -f1 -d:|sort -u` adds booking and bib batch update to the list to test |
| 14:47 |
dbwells |
bshum: nothing from me |
| 14:47 |
bshum |
Cool, eeevil++ showing us the things to check :D |
| 14:47 |
bshum |
So next |
| 14:48 |
bshum |
Otherwise, I left other bugs untargeted for now. |
| 14:48 |
bshum |
#link Link to 2.3.8 targeted bugs: https://launchpad.net/evergreen/+milestone/2.3.8 |
| 14:49 |
bshum |
#link Link to 2.2.10 targeted bugs: https://launchpad.net/evergreen/+milestone/2.2.10 |
| 14:49 |
eeevil |
for those following along with bug 1187433, there are now 2 branches on that, both for testing, both to repair 2.4-era regressions. one's been tested and one is new as of this morning. That's the most important outstanding 2.4/master bug I would like to appeal for eyes on for the june 2.4 release |
| 14:49 |
bshum |
I assigned them to the maintainers, but that's something we can help out with. |
| 14:49 |
pinesol_green |
Launchpad bug 1187433 in Evergreen "apostrophe search issues in 2.4" (affected: 1, heat: 6) [Medium,Confirmed] https://launchpad.net/bugs/1187433 |
| 14:49 |
eeevil |
(since were talkin' maint releases) |
| 14:57 |
phasefx |
someone can always volunteer to maintain an otherwise defunct branch |
| 14:57 |
rfrasur |
yup |
| 14:58 |
bshum |
kmlussier: So to try being on track... the suggestion is that outside of 2.5 merging, maintenance releases, we try setting aside a specific time/day to work on miscellaneous bugs that have not had much love yet? |
| 14:58 |
rfrasur |
I'll just make it more of a priority to get in on some testing |
| 14:58 |
|
ktomita joined #evergreen |
| 14:59 |
kmlussier |
bshum: Yes, that's what I'm suggesting. If others think it's a good idea. |
| 14:59 |
mrpeters |
i like that idea |
| 14:59 |
|
jdouma joined #evergreen |
| 15:00 |
kmlussier |
When we used to have those pullrequest meetings, I loved seeing all the unloved patches finally getting merged in. |
| 15:00 |
kmlussier |
Of course, I wasn't do much testing then, but would be able to help out now. :) |
| 15:03 |
bshum |
For myself, I feel that bug squashing tends to happen best in conjunction with the maintenance releases. |
| 15:03 |
bshum |
Maybe we should designate a particular day prior to the cutting date where we try to focus a bit more on it? |
| 15:04 |
bshum |
Since bug squashing and getting fixes in would lead ultimately to being part of a maintenance release anyways for others to take. |
| 15:56 |
kayals |
one database server with multiple databases for each library |
| 15:56 |
jeffdavis |
But you wanted to have a single reports server for all of them? |
| 15:56 |
kayals |
yes |
| 15:57 |
jeffdavis |
as bshum says, interesting... :) |
| 15:58 |
jeffdavis |
We've got a setup like that for our test environment but not with shared services like reports |
| 15:58 |
bshum |
Yeah our test database server has multiple databases for various distinct Evergreen test systems too. |
| 15:58 |
bshum |
But we don't run reports together. |
| 15:58 |
kayals |
how can we configure reports for each library then |
| 15:58 |
bshum |
Is there a reason the libraries need to be split up like that into disparate databases? |
| 15:59 |
bshum |
Well, you could run clark-kent reporter on each Evergreen VM. As long as the opensrf.xml was pointed to the right DB, I imagine that'd be fine. |
| 15:25 |
jeff_ |
isl-JBoyer++ welcome! |
| 15:26 |
dbs |
eeevil: actually, note that all of my tests have been against the 'title' field |
| 15:27 |
eeevil |
dbs: consider it noted |
| 15:27 |
dbs |
hmm, and config.metabib_field_ts_map is devoid of rows on our test database |
| 15:27 |
eeevil |
using_the_same_words_for_testing++ |
| 15:27 |
eeevil |
well... that's something |
| 15:28 |
eeevil |
if, with those, it still fails ... it be code problems. |
| 15:28 |
eeevil |
well, no |
| 15:28 |
eeevil |
that's only used for fielded searches. title|proper: foo |
| 15:28 |
tsbere |
dbs: You want config.metabib_class_ts_map, I think... |
| 15:29 |
dbs |
tsbere: yeah, that's populated |
| 15:29 |
dbs |
per 14:59 < dbs> I have simple -> A, english_nostop -> C in my test config.metabib_class_ts_map table. Doesn't seem to be resulting in any english_nostop in the actual queries |
| 15:29 |
dbs |
and 15:02 < dbs> Only Publisher/metabib.pm attempts to set config_metabib_class_ts_map it seems. |
| 15:31 |
|
ldwhalen joined #evergreen |
| 15:39 |
eeevil |
found it... |
| 15:39 |
dbs |
yay |
| 15:39 |
eeevil |
we're not loading the class->ts mapping |
| 15:39 |
eeevil |
the calling code in open-ils.search calls the fts wrapper |
| 15:40 |
eeevil |
the wrapper has an initialize block instead of using _initialize($parser) |
| 15:40 |
eeevil |
once /any/ initialization has occurred, we never reinitialize the parser singleton (well, effective singleton) |
| 15:41 |
eeevil |
and the wrapper's block does not do the class and field to ts config mapping |
| 15:42 |
eeevil |
dbs: I'll toss a patch on the bug for you to test, if you want |
| 15:44 |
* bshum |
has been watching quietly and can help test too. |
| 15:44 |
bshum |
If I don't get carried away by flood waters that is. |
| 15:44 |
bshum |
Crazy rain. |
| 15:46 |
eeevil |
bshum: it's attached now |
| 15:52 |
* tsbere |
is not surprised he missed that when figuring out the parser initializations |
| 15:56 |
dbs |
eeevil++ |
| 15:59 |
bshum |
eeevil++ |
| 16:08 |
dbs |
Looks like it works in my limited tests |
| 16:10 |
bshum |
Likewise |
| 16:11 |
bshum |
Or at least, we get results where we didn't before. |
| 16:14 |
* dbs |
added more details to the bug |
