| 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 |
| 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. |
| 11:22 |
tsbere |
My hate is more general ;) |
| 11:23 |
bshum |
tsbere++ |
| 11:36 |
|
DPearl joined #evergreen |
| 11:45 |
DPearl |
Help! I'm installing opensrf on a new machine and it is not starting up. The srfsh test failed with "unable to bootstrap client". It looks like the router is failing. |
| 11:46 |
DPearl |
I have checked and rechecked the ejabber users, and they look fine. |
| 11:47 |
DPearl |
The .srfsh.xml is fine. |
| 11:47 |
phasefx |
if you grep your osrfsys.log for ERR, what's the first hit there? |
| 14:09 |
bshum |
dbs: +1 |
| 14:10 |
bshum |
paxed: I'm not fully up to speed with the details, but I think the screen reader just works alongside the browser, so there's no clear indication whether they're using one or not vs. just using a browser. |
| 14:10 |
paxed |
bshum: ah... right. |
| 14:10 |
kmlussier |
Yup. I was using standard browsers in my own testing. |
| 14:12 |
senator |
if dijit removes the aria-label attribute, can the problem be solved by adding it back to some <span> element surrounding the input widget? or is there more to it than that? |
| 14:13 |
* dbs |
looks at Driver/Pg/QueryParser.pm and wonders if line 311/312 is where the pain in apostrophe searching arrives |
| 14:13 |
* bshum |
peruses |
| 14:13 |
dbs |
this code could use some comments, and maybe some more expressive var names. $c looks pretty important, just have to figure out what it is |
| 14:14 |
dbs |
a boolean for "is combined" I guess |
| 14:15 |
akilsdonk_ |
kmlussier: it looks like all the new documentation has been processed into 2.4 now. |
| 14:17 |
kmlussier |
senator: I don't know much about the code, but I wouldn't be surprised if the problem goes beyond the arial-label attribute. 2.2 catalogs didn't use the arial-label attribute, and, if autosuggest wasn't enabled, you could still identify the correct form elements by tabbing or using the JAWS commands. But that was just my uneducated gut feeling when I was testing. |
| 14:18 |
kmlussier |
akilsdonk_++ Thanks! Of course, now that it's displaying, I now see I neglected to make some changes to the root file. |
| 14:20 |
akilsdonk_ |
kmlussier: Yeah, I had to make a few changes too. :) Thank you! |
| 14:20 |
akilsdonk_ |
kmlussier++ dbs++ rsoulliere++ We have docs! |
| 14:20 |
kmlussier |
http://www.nomensa.com/blog/2011/how-do-you-detect-a-screen-reader/ tells us we can't detect screen readers. |
| 14:55 |
eeevil |
hrm... maybe not |
| 14:55 |
* eeevil |
thinks more |
| 14:55 |
dbs |
Check line 583 of Driver/Pg/QueryParser.pm |
| 14:55 |
tsbere |
dbs: Isn't that the *test* setup, where we don't have a DB to pull things from? |
| 14:56 |
dbs |
tsbere: I dunno, I'm just trying to unravel this! |
| 14:58 |
dbs |
so "config_metabib_class_ts_map" should bring us DB-based config? |
| 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. |
| 14:59 |
tsbere |
we *do* assume "just simple" if we don't have any info, so if something is broken on the "fetch from DB" side of things that would be the only thing we got... |
| 15:00 |
dbs |
Sounds like something might be broken (quite consistently) then. |
| 15:00 |
dbs |
As this has been confirmed on all sites running 2.4 |
| 15:24 |
eeevil |
;) |
| 15:24 |
eeevil |
thinking_of_the_future++ |
| 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 |
| 11:35 |
bshum |
It's listed as March 19-22 on my calendar anyways. |
| 11:36 |
berick |
huh, must have gotten pushed back |
| 11:40 |
|
ThePoster60 joined #evergreen |
| 11:42 |
bshum |
berick: I'm going to try out your new wrong shelf hold branch. I remember trying it during the 2.4 cycle and having some weird network error crash. |
| 11:43 |
bshum |
But that might have been something wonky with our test server. |
| 11:43 |
bshum |
Good to get fresh eyes on it again. |
| 11:43 |
* phasefx |
is testing it too |
| 11:45 |
bshum |
Ah okay. I probably wasn't going to get to all of it before today's cutoff, I just meant in general. |
| 11:45 |
bshum |
phasefx++ |
| 11:46 |
phasefx |
this close > < I think |
| 12:07 |
|
jihpringle joined #evergreen |
| 12:12 |
|
krvmga joined #evergreen |
| 12:13 |
krvmga |
i was looking at the sql generate for reports and found a big section on relation under rel_cache. anyone know what/where rel_cache is? |
| 12:22 |
jeff_ |
Dyrcona: you have build scripts for test instances somewhere -- or am i imagining things? |
| 12:23 |
jeff_ |
Dyrcona: rephrased, do you have build scripts for building test evergreen systems available somewhere? |
| 12:24 |
Dyrcona |
jeff_: I currently have this https://docs.google.com/document/d/1s8C1ZLSgHwvDZOpinuHoku0ABbOjoHrs-iHBZPbCch0/edit#heading=h.b44ysgz2myvl |
| 12:26 |
Dyrcona |
Whos is "Anonymous Chupacabra?" ;) |
| 12:26 |
Dyrcona |
I should have used that as my /. handle. |
| 21:05 |
pinesol_green |
rfrasur: NO! |
| 21:05 |
rfrasur |
good to know |
| 21:05 |
jcamins |
rfrasur: having fun with the bot? |
| 21:05 |
rfrasur |
yep |
| 21:06 |
rfrasur |
I tested some of them in a pm, but some don't work that way |
| 21:10 |
rfrasur |
if people want to do something productive, just tell me to knock it off. |
| 21:10 |
* rfrasur |
won't be offended. |
| 21:11 |
jcamins |
@librarian |
| 21:11 |
pinesol_green |
jcamins: Management:15, Cataloging:12, Acquisitions:14, Reference:12, Circulation:12, Systems:12, Research:10, Custodial:14 |
| 21:11 |
jcamins |
^^ my favorite |
| 09:32 |
pinesol_green |
Launchpad bug 1187035 in Evergreen "Remove obsolete OpenILS::Utils::Editor" (affected: 1, heat: 6) [Wishlist,New] https://launchpad.net/bugs/1187035 - Assigned to Jeff Godin (jgodin) |
| 09:42 |
jeff_ |
berick: zero toes were harmed! |
| 09:42 |
berick |
excellent |
| 09:42 |
jeff_ |
all i had in mind was to clean up my commit message and test / get exactly the kind of eyes you put on it -- thanks for catching the $e->request bits |
| 09:42 |
kivilahtio |
Hi all! Is there a guide on how to get logging statements to show in the open-ils.serials_stderr.log or opensrf logs? |
| 09:42 |
kivilahtio |
I have read Dan Scott's articles about easing gently into OpenSRF and I get syntax errors! Also went through the opensrf.xml & opensrf_core.xml and found references to the unix_log files named <unix_log>open-ils.serial_unix.log</unix_log> |
| 09:42 |
kivilahtio |
This should export the $logger-object to the package? use OpenSRF::Utils::Logger qw/:logger/; |
| 09:59 |
kivilahtio |
jeff_: yeah I kinda figured that out after the OpenSRF tutorial, but it didnät work before that either. I'll try |
| 10:00 |
kivilahtio |
jeff_: do you have any idea about the open-ils.serials_stderr.log ? |
| 10:00 |
kivilahtio |
can one push statements there? |
| 10:00 |
jeff_ |
kivilahtio: i would expect this line to work, assuming that $obj exists and has an as_string method. have you tried logging just a basic scalar, or a fixed value, as a test? $logger->error("HELP I AM STUCK IN A SERIAL FACTORY"); or the like? |
| 10:00 |
kivilahtio |
jeff_: yes :) |
| 10:01 |
jeff_ |
hrm. strange. perhaps the Serial.pm file which you are editing is not the Serial.pm file which is being loaded by the system? (going back to basics) |
| 10:01 |
jeff_ |
(rather -- trying the simple things) |
| 10:02 |
kivilahtio |
jeff_: yeah. but it should work and I'll try to work from there, thanks |
| 10:02 |
phasefx |
we should expose a private API call for testing logging, if one doesn't already exist |
| 10:03 |
jeff_ |
kivilahtio: good luck -- sorry, I'm out of ideas for the moment. also, I'm not certain on the stderr logs, though I would have expected warn() to hit them -- which is why I was wondering if the file you were editing was not the file being used by the system when starting services. |
| 10:03 |
phasefx |
registered OpenSRF method, that is |
| 10:04 |
kivilahtio |
phasefx: what do you mean? add it to the opensrf.xml ? |
| 10:04 |
kivilahtio |
phasefx: or the opensrf_core.xml? I couldn't find any serials related entries there |
| 10:04 |
phasefx |
kivilahtio: I mean, it would be neat to be able to use srfsh and just say something like request open-ils.actor opensrf.log.error "testing 123" |
| 10:04 |
kivilahtio |
phasefx: ah |
| 10:05 |
phasefx |
not that such a thing would have necessarily been of help here |
| 10:08 |
kivilahtio |
phasefx: I think i solved the osrfsh.log issue, still getting nothing in the serials_stderr.log |
| 10:33 |
gmcharlt |
dbs++ |
| 10:33 |
jeff |
kivilahtio: when a service is started, it should try to open the stderr log file. if it fails, it will log at the error level, "server: unable to open STDERR log file: [...] " if it succeeds, it will log at the internal level (which you probably are not logging), "server: redirecting STDERR to [...]" |
| 10:34 |
jeff |
kivilahtio: you might want to restart the service(s) and look for errors in the opensrf log mentioning STDERR -- also, verify that file ownership and permissions on the stderr files permit your user (likely opensrf) to write to them. |
| 10:34 |
dbs |
paxed: I'm working on testing a commit for bug 1020625 atm |
| 10:34 |
pinesol_green |
Launchpad bug 1020625 in Evergreen "TPAC unable to link to specific organization by shortname" (affected: 1, heat: 6) [Wishlist,Confirmed] https://launchpad.net/bugs/1020625 |
| 10:37 |
kivilahtio |
jeff: no errors with keywords serial and redir |
| 10:37 |
kivilahtio |
write persmission for oser opensrf |
| 11:55 |
rfrasur |
eeevil:I knew it could be done...but didn't know how. Thanks :-). Now I have some of the right words to say (in the future...when there's someone to say them to) |
| 11:59 |
phasefx |
heh, I can't edit bug status in launchpad with my version of chromium |
| 12:02 |
|
mllewellyn joined #evergreen |
| 12:08 |
dbs |
paxed: testing 1187316 right now |
| 12:09 |
|
Ruth joined #evergreen |
| 12:10 |
|
dboyle joined #evergreen |
| 12:10 |
paxed |
how do you handle the ssl cert for the staff client in automatic client installs? |
| 12:19 |
pinesol_green |
Launchpad bug 1158218 in Evergreen "Improve db-seed-i18n.py to actually grab all strings for translation" (affected: 1, heat: 6) [Undecided,Triaged] https://launchpad.net/bugs/1158218 |
| 12:20 |
|
jihpringle joined #evergreen |
| 12:20 |
paxed |
dbs: "so they be built" ??! :D |
| 12:20 |
dbs |
that be right |
| 12:24 |
dbs |
paxed: that one requires more testing, and I don't really have time. putting the whole thing on one line is known to work, and there are tests for it in tests/testSQL.py ; I'm loathe to add support for multiline parsing without corresponding tests |
| 12:25 |
paxed |
ok, i guess i should write tests for it then too. |
| 12:27 |
dbs |
added a comment correspondingly; in this case, it's just extending existing test data & expected output so it should be pretty easy to do |
| 12:45 |
sseng_ |
How does a person add a predefine message in the drop down list for the "Apply Standing Penalty/Message" in the "Messages" tab of the staff client? Been trying to search around but not coming up with much. |
| 12:45 |
|
stevenyvr2 joined #evergreen |
| 12:47 |
|
ericar joined #evergreen |
| 13:07 |
|
ldwhalen joined #evergreen |
| 13:07 |
|
jdouma joined #evergreen |
| 13:09 |
* dbs |
shakes head slowly at mutt and google's ssl certificates |
| 13:11 |
paxed |
dbs: i'm adding some contrived test cases, not just examples lifted out of 950.*.sql |
| 13:11 |
dbs |
paxed: cool, exercise it thoroughly :) |
| 13:13 |
|
kyleonalaptop joined #evergreen |
| 13:16 |
|
mjingle joined #evergreen |
| 13:35 |
* kmlussier |
fears that August will come sooner than expected. :( |
| 13:35 |
kmlussier |
rfrasur: I'll take whatever thoughts you want to send my way. :) |
| 13:36 |
rfrasur |
kmlussier: Also, if there's something that doesn't require a vast amt of tech know-how, I'd be willing to TRY and help. |
| 13:36 |
paxed |
dbs: the branch now has test cases too. dunno if it was ok to delete the remote branch and recreate it from my local one ... |
| 13:37 |
rfrasur |
hmm, I suppose in this "room," I should say...barely any tech know-how |
| 13:38 |
paxed |
(what's the best way to handle a case where your local repo doesn't have the same branch? i just created a branch, cherry-picked the changes from the remote one, hacked, amended commit, deleted the remote branch and pushed my local out as the same name branch...) |
| 13:39 |
dbs |
paxed: okay with me |
| 14:03 |
* rfrasur |
is Ruth Frasur, Evergreen Indiana |
| 14:03 |
* rsoulliere |
is Robert Soulliere, Mohawk College |
| 14:03 |
pinesol_green |
[evergreen|Dan Scott] Fix Latin-1 encoding that broke doc output - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=96c877e> |
| 14:05 |
yboston |
we might be a small crowd today, but any meeting that Robert and Kathy attends is a success to me |
| 14:05 |
yboston |
#topic Updates from Content Coordinators |
| 14:05 |
yboston |
We will continue having the content corrdinators try out the "#topic" AND "#info" Meetbot commands for their reports |
| 14:05 |
yboston |
So content coordinators, please use "#topic" for the first post/line of your report |
| 14:05 |
yboston |
then use "#info" for every other chat post/line of your report. |
| 14:05 |
yboston |
for example... |
| 14:06 |
yboston |
#topic this is a test report first post/line |
| 14:06 |
yboston |
#topic this is a test report first post/line |
| 14:06 |
yboston |
#topic this is a test report first post/line |
| 14:06 |
yboston |
#info this is a test report second post/line |
| 14:06 |
yboston |
(sorry having pasting issues) |
| 14:06 |
yboston |
who would like to go first.. |
| 14:07 |
kmlussier |
#topic DIG Release Coordinator Report |
| 14:07 |
kmlussier |
#info Nothing to report in terms of release coordination. |
| 14:08 |
kmlussier |
#info I did get some udpated 2.4 acq docs done, but have a few more to work on. |
| 16:08 |
bshum |
Maybe its just me, but it looks like phasefx is committing from the future. By just a few minutes but it's wigging me out man! |
| 16:08 |
gmcharlt |
:) |
| 16:09 |
* phasefx |
wiggles his chaos fingers |
| 16:09 |
Dyrcona |
jeff_: Looks like we might be putting your RESTful API to the test, too. |
| 16:10 |
gmcharlt |
bshum: there's a reason we never let phasefx drive at exactly 88 mph |
| 16:10 |
jeff_ |
cool. in any context of NCIP, or unrelated? |
| 16:10 |
Dyrcona |
jeff_: In context of NCIP. |
| 17:19 |
gmcharlt |
Dyrcona: yeah, I think that's bug-worthy |
| 17:22 |
phasefx |
berick: I'm going to push a branch with the Current Shelf Library column |
| 17:23 |
phasefx |
well, first I'm going to make sure I didn't break master :) |
| 17:24 |
rs233 |
Dyrcona: I think I found where A problem is where I added a line to the xml that was not exactly correct.. I believe the Server is runnin now will try some testing |
| 17:25 |
Dyrcona |
rs233: Good luck! |
| 17:25 |
berick |
phasefx++ |
| 17:25 |
rs233 |
I might be back tomorrow lol |
