| 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 |
| 08:57 |
|
Callender joined #evergreen |
| 08:59 |
|
tfaile joined #evergreen |
| 09:01 |
|
mmorgan1 joined #evergreen |
| 09:02 |
dbs |
bshum: don't sigh about acquisitions testing, please... we're going to try seriously adopting acq after we upgrade to 2.4, and I'm sure all the basic stuff works flawlessly. _flawlessly_. |
| 09:02 |
* dbs |
still needs to test that basic stuff, is crossing fingers. |
| 09:15 |
kmlussier |
dbs: acq has come a long way in the past year. I hope your testing goes well! |
| 09:24 |
|
jeff___ joined #evergreen |
| 09:25 |
|
Simon21 joined #evergreen |
| 09:25 |
|
pmurray_away joined #evergreen |
| 09:41 |
Dyrcona |
The 404 is likely 'cause I missed something that needs to be configured. |
| 09:42 |
rjackson-isl |
we have a book mobile in offline mode due to poor connectivity and wondered if this would help... |
| 09:42 |
jeff_ |
the offline patron list downloads a list of barred/lost/expired/penalized patron barcodes, and it depends on offline-blocked-list.pl being run (usually via cron) to generate the list. |
| 09:43 |
rjackson-isl |
ok - I will see if I can get that going in test jeff_ ++ |
| 09:43 |
bshum |
Yeah, for some reason Indiana's list.txt is empty. |
| 09:43 |
|
shadowsp1r joined #evergreen |
| 09:45 |
Dyrcona |
jeff_++ # I should have known that. |
| 09:47 |
dbs |
kmlussier: thanks for the reassurance :) |
| 09:48 |
kmlussier |
dbs: What tools did you use when testing accessibility in tpac? |
| 09:49 |
|
tater joined #evergreen |
| 09:54 |
kmlussier |
dbs: nm, I found it. |
| 09:54 |
bshum |
dbs: I only sigh about testing new acq "features". It's hard to test expected behavior sometimes :( |
| 09:54 |
bshum |
But I agree with kmlussier that acq has come a very long way from when we first started using them back in 2.0 days. |
| 09:54 |
|
mllewellyn joined #evergreen |
| 10:15 |
kmlussier |
Should https://bugs.launchpad.net/evergreen/+bug/1155278 be backported since it is an accessibility issue? Looks like it was only committed to 2.4. |
| 10:15 |
pinesol_green` |
Launchpad bug 1155278 in Evergreen "TPAC: Accessibility audit compliance" (affected: 3, heat: 14) [Undecided,Fix released] |
| 12:20 |
|
kyleonalaptop joined #evergreen |
| 12:21 |
|
mllewellyn joined #evergreen |
| 12:23 |
|
ldwhalen joined #evergreen |
| 12:25 |
eeevil |
paxed: it looks ok to me, but I haven't tested it |
| 12:25 |
paxed |
the material() sees only the full 007 field, not the one character from pos 1 |
| 12:30 |
eeevil |
this won't address that, but start_pos is 0-based |
| 12:30 |
paxed |
yes, and i'm looking for the 2nd character. |
| 12:50 |
eeevil |
what does the following return for you? SELECT biblio.marc21_extract_fixed_field( $bibid, 'material'); -- replace $bibid with an appropriate bib id |
| 12:51 |
eeevil |
to purge material, UPDATE metabib.record_attr SET attrs = attrs - 'material'; |
| 12:51 |
paxed |
that returns just one char, correctly |
| 12:52 |
eeevil |
cool. so, I guess, purge and then reingest a couple records. then search for "material(x)" (no quotes, replace "x") to test |
| 12:52 |
paxed |
# UPDATE metabib.record_attr SET attrs = attrs - 'material'; |
| 12:52 |
paxed |
ERROR: Unexpected end of string |
| 12:53 |
eeevil |
maybe got smartquotes from cut/paste? |
| 15:07 |
* rfrasur |
prefers analog legos |
| 15:08 |
eeevil |
paxed: so, there's already a sophisticated 007 parser. what, in particular, are you trying to accomplish? SMD filtering, I believe? |
| 15:09 |
paxed |
eeevil: it started as a learning experience, now i'm just trying to get this working. SMD? what 007 parser? |
| 15:10 |
kmlussier |
dbs: Have you loaded the fixes from https://bugs.launchpad.net/evergreen/+bug/1155278 to your production server? I was using your catalog for comparison when testing a problem here, but then remembered you're not on 2.4 yet. |
| 15:10 |
pinesol_green` |
Launchpad bug 1155278 in Evergreen "TPAC: Accessibility audit compliance" (affected: 3, heat: 14) [Undecided,Fix released] |
| 15:11 |
* kmlussier |
wonders if there are any production systems using both 2.4 and auto suggest. |
| 15:11 |
eeevil |
007/01 (second character in 007) is described as the SMD field for ... well ... it looks like all record types. http://www.oclc.org/bibformats/en/0xx/field007table.html (easier to read, IMO, than the LOC version) |
| 15:11 |
kmlussier |
Ooh! Looks like SC LENDS is. |
| 15:12 |
paxed |
eeevil: well, i usually read the marc21 format in finnish, so i wouldn't know/remember what "SMD" stands for. |
| 15:12 |
dbs |
kmlussier: our test server ( http://laurentian-test.concat.ca ) has that loaded - and I think I did apply it to our production server, but can't recall for sure |
| 15:13 |
kmlussier |
dbs: Ok, I'll look there too. Thanks! |
| 15:13 |
eeevil |
paxed: gotcha, fair enough. so, you were looking for the 007/01 on a particular record type originally, what was that type? |
| 15:14 |
dbs |
kmlussier: IIRC, autosuggest is a massive pain for accessibility; at least in our implementation, where Dojo dijits don't even make ARIA a viable option |
| 15:14 |
|
fparks joined #evergreen |
| 15:15 |
eeevil |
paxed: ok, so, where 007/00 = c, correct? |
| 15:15 |
paxed |
eeevil: so what filter gets the 007/01? yes |
| 15:16 |
dbs |
kmlussier: http://www-test.concat.ca/ is closer to stock than our LU skin |
| 15:16 |
kmlussier |
Yes, that's what I'm finding. C/W MARS modified their searchbar.tt2 based on your changes, but it still seems to be problematic in IE and Chrome. I'm not sure if was the problem with the way we patched it or if further work is needed. |
| 15:17 |
* kmlussier |
hasn't even looked at advanced search yet. :P |
| 15:17 |
dbs |
kmlussier: I couldn't easily fix the problem that autosuggest introduces, so I didn't |
| 15:21 |
kmlussier |
dbs: This morning, I used Chrome's accessibility add-on and had no trouble. It may just be a JAWS issue, but, then again, JAWS has a big share of the market. |
| 15:21 |
dbs |
kmlussier: yeah, understood. I can't recall if I checked the recent Dojo version to see if that issue had been addressed |
| 15:23 |
paxed |
eeevil: ok, now how do i do a filter for any type of record, or do i have to make a different filter name for each type of record? |
| 15:23 |
kmlussier |
dbs: Thanks for the info. So it sounds like disabling java or using Firefox are some workarounds for the time being. I'll test try some tests with java disabled. |
| 15:23 |
eeevil |
dbs: I believe ARIA is surfaced much better in modern dojo's |
| 15:25 |
eeevil |
paxed: the values in 007/01 overlap across record types ("a" means different things based on 007/00), so the short answer is "yes, a filter per type". that being said, what you've been trying to do /should/ work, so figuring out why it's not would be good, because then you could do it with a single filter on 007/00 with a length of 2 |
| 15:26 |
paxed |
eeevil: com_smd should show in metabib.record_attr attrs, right? |
| 10:59 |
|
_zerick_ joined #evergreen |
| 11:00 |
|
tspindler joined #evergreen |
| 11:04 |
Dyrcona |
dbs: mens health doesn't match men's health on my catalog, either. |
| 11:04 |
bshum |
Well, I just tested that search on MVLC and SCLEND's catalogs and neither returned expected results |
| 11:05 |
bshum |
Oh, heh |
| 11:05 |
dbs |
Looks like your thinking that new QP might be playing a role might be a reasonable theory. I'm seeing the same difference on our 2.4 test server vs our 2.3 production server |
| 11:06 |
dbs |
Is SCLENDs on 2.4? |
| 11:06 |
dbs |
I assume MVLC is. |
| 11:06 |
gmcharlt |
dbs: yes |
| 11:08 |
* bshum |
goes off to file a bug |
| 11:08 |
paxed |
is it enough to insert into config.record_attr_definition and reingest, or do i have to do something else to get a new filter working? |
| 11:33 |
paxed |
huh. okay, that works. it just didn't work like i expected it to. |
| 11:34 |
paxed |
adding that filter, it seems to consider the whole 007 field, not the 007/1 |
| 11:46 |
|
Ruth joined #evergreen |
| 11:57 |
jeff_ |
drat. the perils of comparing json as strings? |
| 11:57 |
jeff_ |
# Failed test at t/09-Utils-JSON.t line 105. |
| 11:57 |
jeff_ |
# got: '{"__p":{"foo":"bar"},"__c":"osrfException"}' |
| 11:57 |
jeff_ |
# expected: '{"__c":"osrfException","__p":{"foo":"bar"}}' |
| 11:57 |
jeff_ |
(of course, run the test again and all's well) |
| 11:59 |
Ruth |
I had the same problem with roofing nails this morning. |
| 12:02 |
|
mcooper joined #evergreen |
| 12:05 |
pinesol_green |
[evergreen|Simon Hieu Mai] LP#1053074: Editimg MARC Fixed Fields jumps cursor to marc record - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=717a126> |
| 12:25 |
|
ldwhalen joined #evergreen |
| 12:35 |
paxed |
yeah, figured |
| 12:39 |
|
mjingle joined #evergreen |
| 12:55 |
jeff_ |
tests+- |
| 13:09 |
|
mcarlson joined #evergreen |
| 13:11 |
|
mtcarlson joined #evergreen |
| 13:13 |
dbs |
jeff_: maybe set $json->canonical(true) to ensure the keys are ordered |
| 13:14 |
dbs |
assuming that json::xs is in play |
| 13:15 |
* dbs |
hasn't been able to get that test to fail |
| 13:15 |
jeff_ |
yeah. it might be a perl 5.18 thing. i'm seeing similar with some XML tests for RPC::XML |
| 13:16 |
jeff_ |
or, might be that i've fallen back to the pure perl json backend. i should check. |
| 13:16 |
dbs |
mmm, yeah, perl 5.16 here |
| 13:16 |
jeff_ |
and dbs++ for $json->canonical(true) -- i thought there was an option for that but had not gone looking. |
| 13:17 |
|
StephenGWills joined #evergreen |
| 17:05 |
|
mjingle joined #evergreen |
| 20:20 |
|
serflog joined #evergreen |
| 20:20 |
|
Topic for #evergreen is now Welcome to the #evergreen library system channel! | We are publicly logged. | Large pastes at http://paste.evergreen-ils.org |
| 20:21 |
bshum |
awitter++ mrpeters++ |
| 20:36 |
|
b_bonner joined #evergreen |
| 20:43 |
|
mtcarlson joined #evergreen |
| 20:46 |
|
mcarlson joined #evergreen |
| 22:03 |
|
ktomita-mac joined #evergreen |
| 22:16 |
|
ldwhalen joined #evergreen |
| 22:17 |
|
kmlussier joined #evergreen |
| 22:20 |
* bshum |
sighs loudly at acquisitions and EDI testing :( |
| 23:00 |
pinesol_green |
[evergreen|Pranjal Prabhash] Standalone Mode Staff Client Shortcuts - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=b55da92> |
| 23:00 |
pinesol_green |
[evergreen|Ben Shum] Added release note for standalone mode shortcuts - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=2060027> |
| 23:04 |
bshum |
Calling 0794 |
