08:46 |
senator |
kmlussier: ooh, i bet you're right |
08:46 |
graced |
kmlussier: smart thinking! |
08:47 |
kmlussier |
Well, we had a consortium that had both running at one point, so it was easy to make that connection. |
08:50 |
csharp |
Sara Paulk used to be in a PINES library (general interest observation) |
08:53 |
csharp |
more trivia... we also decided that we are probably related since there are many Paulks on my mom's south Georgia side from the same area as her family |
08:54 |
|
yboston joined #evergreen |
08:55 |
csharp |
okay - so our libraries have just discovered that dupe name/address checking is restricting its scope to the workstation OU (or its system) when it used to be doing a consortium-wide check (in the patron reg screen) |
08:56 |
csharp |
we don't use opt-in, so it's not that (set to "false" in opensrf.xml and no YAOUS settings in place) |
08:56 |
csharp |
I tested setting opt-in to true and setting the boundary and default to "0" (expecting that to be consortium) - no change |
08:57 |
kmlussier |
https://bugs.launchpad.net/evergreen/+bug/1185524 |
08:57 |
csharp |
the code in register.js appears to scope the search to "0" unless opt-in is in place, so I'm kind of at the end of knowing what to check next |
08:57 |
pinesol_green |
Launchpad bug 1185524 in Evergreen "duplicate patron checking in the user editor is limited to the workstation OU" (affected: 4, heat: 20) [Undecided,Incomplete] - Assigned to Kyle Tomita (tomitakyle) |
09:42 |
senator |
csharp: were you able to work something up on 1185524 yet? |
09:42 |
rfrasur |
Maybe I need to change my permission so that I acrue fines. |
09:42 |
csharp |
senator: I was just experimenting with hard-coding the search_ou, but not really |
09:43 |
senator |
i have a branch along the lines of eeevil's suggestions you could test |
09:43 |
csharp |
oh - excllent |
09:43 |
csharp |
excellent, that is |
09:43 |
csharp |
cool - hard-coding does work ;-) |
09:45 |
senator |
https://bugs.launchpad.net/evergreen/+bug/1185524/comments/6 |
09:45 |
pinesol_green |
Launchpad bug 1185524 in Evergreen "duplicate patron checking in the user editor is limited to the workstation OU" (affected: 4, heat: 22) [Undecided,Confirmed] - Assigned to Kyle Tomita (tomitakyle) |
09:45 |
csharp |
senator: awesome - I'll test |
09:47 |
|
moodaepo_nb joined #evergreen |
09:49 |
* rfrasur |
does the "we got a new board member and it's the one we requested" dance. |
09:52 |
senator |
kmlussier++ |
10:02 |
csharp |
s/interested/interesting/ |
10:04 |
csharp |
senator: works in 2.3.6 |
10:05 |
csharp |
senator++ |
10:08 |
senator |
thanks for brining it back up and testing! signoff appreciated |
10:08 |
kmlussier |
csharp: I wonder if they really want a separate search, though, or if they just miss some features and the fact that it was easier to get to some searches, like numeric and MARC expert, in jspac. Having heard the same complaints here. |
10:08 |
kmlussier |
I think tsbere's work that allows staff to set a default search tab in the staff client will help with some of that here. |
10:09 |
csharp |
kmlussier: I'm sure you're right |
23:27 |
mrpeters |
ill copy from example and start fresh |
23:27 |
mrpeters |
worth a shot |
23:27 |
dbs |
401 = HTTP 401 Unauthorized |
23:28 |
mrpeters |
apache not running a problem? |
23:28 |
mrpeters |
i didnt think it had to be for just doing the opensrf smoke test |
23:28 |
dbs |
no, just explaining where the "401" came from |
23:28 |
mrpeters |
right on, thanks. i didn't realize it was http related |
23:28 |
dbs |
it's not, really. just trying to use familiar error codes. |
13:03 |
rfrasur |
#info rfrasur is Ruth Frasur, Hagerstown Library/Evergreen Indiana |
13:03 |
kmlussier |
Ok, let's move on and people can keep introducing themselves as they arrive. |
13:04 |
afterl |
#info afterl is Amy Terlaga (guest) |
13:04 |
kmlussier |
#topic Action items from last meeting |
13:04 |
kmlussier |
#info action items were (a) moodaepo to e-mail link to test site to the list for feedback, (b) StephenGWills to work on member directory/map for web site. (c) hbrennan and kmlussier to work on layout/design issues for downloads page. (d) kmlussier will send out another Doodle to schedule a regular meeting time. |
13:05 |
kmlussier |
moodaepo: Your action item is up first. Anything to report? |
13:05 |
|
hbrennan joined #evergreen |
13:05 |
moodaepo |
kmlussier: bshum is the man with the test server plan. I haven't emailed it out yet but if he gives the go ahead I will do so today. |
13:05 |
kmlussier |
ok, bshum will be giving an update further down in the agenda. |
13:05 |
bshum |
kmlussier: It's an old agenda item, we're probably past test server at this point. |
13:06 |
moodaepo |
bshum++ |
13:06 |
kmlussier |
StephenGWills isn't here, so let's table his action item until we see him again. |
13:07 |
kmlussier |
For my action items, I made contact with hbrennan on downloads page, but my vacation got in the way. We'll touch base and report back to the web team list. |
13:22 |
bshum |
Though with Firefox 23 removing the option for no-JS and setting everybody back to using it, I have wondered about that limitation long-term. |
13:23 |
RoganH |
I personally don't see many users living without JS. |
13:23 |
RoganH |
Very, very few. |
13:23 |
bshum |
Maybe given the new timeline, if moodaepo gets around to sending out the link to the test site, we can solicit ideas for improving the existing theme or picking some new ones. |
13:23 |
bshum |
#link Link to current test site for notes: http://wp.evergreen-ils.org |
13:23 |
gmcharlt |
I was one of the ones who had a expressed a non-JS concern -- but the main issue was that (IIRC) one of the initial themes that was tested *completely* failed to work without JS |
13:24 |
moodaepo |
bshum: I can send out the link and maybe the couple of themes we've looked at also but require javascript for full functionality |
13:24 |
gmcharlt |
as no, no content was rendered |
13:24 |
bshum |
gmcharlt: Right, that was an unfortunate bad theme. |
09:27 |
|
mrpeters joined #evergreen |
09:28 |
csharp |
jcamins: not that I've seen - I'd be interested if so |
09:30 |
jcamins |
csharp: yeah, I was just noticing that 2s seems to be fairly normal for OPACs, which seems to me to be somewhat beyond the realm of "acceptable" in a website. |
09:31 |
csharp |
quick tests of PINES' opac on a good network connection using FF23's Tools -> Web Developer -> Network feature shows 2s on the low end and 7s on the high end of keyword searches |
09:31 |
csharp |
jcamins: agreed |
09:32 |
|
moodaepo_nb joined #evergreen |
09:44 |
|
mllewellyn joined #evergreen |
10:09 |
|
krvmga joined #evergreen |
11:20 |
jcamins |
rfrasur: that does say something about our culture, doesn't it? |
11:22 |
jboyer-isl |
Has anyone run into issues where the report interface will say it's using an inner join, but the generated sql uses left outer? |
11:22 |
rfrasur |
jcamins: To answer briefly something that is a HUGE discussion - Yes. Apparently, my three sons aren't welcome there. That is all. I shall take a walk and let it go. |
11:23 |
pinesol_green |
[evergreen|Dan Wells] Add new get_combined_holdings() method to MFHD.pm - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=83f8420> |
11:23 |
pinesol_green |
[evergreen|Dan Wells] Tie in new MFHD method to serials module/MFHD tests for compressing, combining - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=fbe9e5a> |
11:23 |
pinesol_green |
[evergreen|Dan Wells] Fix logic in get_compressed_holdings() - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=07b28a0> |
11:23 |
pinesol_green |
[evergreen|Dan Wells] Solidify caption/holding relationship, improve MFHD::Holding comparisons - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=a6f3e3b> |
11:24 |
csharp |
jboyer-isl: using nullability selection? |
11:24 |
eeevil |
jboyer-isl: are you sure it /says/ it's using an inner join, and not a "default" join? some default joins are, indeed, left joins |
11:26 |
jboyer-isl |
You bet. I'm working with stat cats, so I wanted to limit it to patrons who have a specific SC set, and to a specific value. There's an "(inner)" in the source specifier box in the lower right. I also noticed that it's including an IS NULL OR ... for those, and an actual inner join on our_unit id. |
09:51 |
pastebot |
"paxed" at 204.193.129.146 pasted "opensrf compile error" (10 lines) at http://paste.evergreen-ils.org/13 |
09:52 |
|
rfrasur joined #evergreen |
09:53 |
eby |
thanks Dyrcona , tsbere , collum |
09:53 |
paxed |
(this is on debian testing) |
09:57 |
paxed |
oh. sprintf without format string. |
09:57 |
* paxed |
goes to report a bug and fix it |
10:20 |
|
artunit joined #evergreen |
10:31 |
|
jdouma joined #evergreen |
10:33 |
paxed |
would it make sense reporting a bug because apache2ctl configtest complains ... but i'm running debian testing? |
10:55 |
tsbere |
paxed: complains about what? |
10:55 |
tsbere |
If it appears to be a valid problem (or potential problem later) a bug report isn't a bad thing |
10:55 |
paxed |
AH00671: The Alias directive in /etc/apache2/sites-enabled/eg.conf at line 56 will probably never match because it overlaps an earlier ScriptAlias. |
12:38 |
Dyrcona |
heh. It kinda helps to execute your queries after binding the parameters, huh? ;) |
12:43 |
paxed |
dbs: using the 2.4 configs doesn't help, i still get the same warnings from apache2ctl |
12:43 |
paxed |
i'll file a bug |
12:45 |
pinesol_green |
[evergreen|Pasi Kallinen] Prevent paste from empty clipboard throwing an error - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=f25cc39> |
12:49 |
pinesol_green |
[evergreen|Jason Etheridge] Fix org unit setting names for this example test - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=de357ea> |
12:49 |
rjackson-isl |
any administrators have advice on cleaning up the action_trigger (event and event_output) tables? Do you have a standing policy such as deleting any that are complete and over a year old? |
12:50 |
rjackson-isl |
Evergreen Indiana currently has space issues and 26+ million action_trigger.event rows |
12:50 |
rfrasur |
(holy heckama) |
13:07 |
Dyrcona |
As in "This parrot is no more!" |
13:08 |
rfrasur |
in that case, I'd say delete those A/T, rjackson-isl |
13:08 |
Dyrcona |
trouble is, the at runner might say, hey! i have to run these. |
13:08 |
mmorgan |
did a lot of testing on notice triggers lately, and had great success getting triggers to run again once the rows for the event_def were deleted from action_trigger.event |
13:09 |
mmorgan |
good for testing, but as bshum points out, if they are valid, they'll run again |
13:10 |
rjackson-isl |
is ther any easy way to determine which ones you can delete without making a mess with the notices then? |
13:11 |
Dyrcona |
rjackson-isl: I'd suggest you look at auditor tables if you're looking for some low hanging fruit to reduce database size. |
13:12 |
rjackson-isl |
Dyrcona we are purging off of the auditors already |
14:05 |
|
dMiller joined #evergreen |
14:07 |
|
acoomes joined #evergreen |
14:07 |
|
acoomes joined #evergreen |
14:07 |
Dyrcona |
And, for my final feat, I shall mess up my training database with a test load of 12,000 patrons! |
14:07 |
rfrasur |
I have some patrons that could REALLY mess it up. |
14:07 |
* rfrasur |
will donate. |
14:08 |
Dyrcona |
It is always fun when you're loading patrons, and they are already in the database. :) |
14:10 |
rfrasur |
hah, reminds of a new book about the 2012 election |
14:11 |
Dyrcona |
And, only 1 patron falls on the floor because of a duplicate usrname key. That is exactly what I expected! |
14:11 |
Dyrcona |
The test is successful! |
14:11 |
Dyrcona |
Now, back to your regularly-scheduled programming. |
14:14 |
|
jihpringle joined #evergreen |
14:18 |
pinesol_green |
[opensrf|Bill Erickson] LP#1188195: Default per-process client locale (Perl) - <http://git.evergreen-ils.org/?p=OpenSRF.git;a=commit;h=8524849> |
14:18 |
pinesol_green |
[opensrf|Galen Charlton] LP#1188195: add tests for setting default client locale - <http://git.evergreen-ils.org/?p=OpenSRF.git;a=commit;h=8a4ee2d> |
14:19 |
gmcharlt |
general heads up that I've created the LP milestone for OpenSRF 2.2.1 |
14:20 |
gmcharlt |
if there are any current pullrequests that you want targeted for consideration for a release next week, please target them now |
14:41 |
gsams |
Does anyone have an example library that uses syndetics with Evergreen? I'm looking to see how it integrates with the catalog so that I can show a prospective library that uses it currently |
09:16 |
Dyrcona |
Bingo! |
09:16 |
kmlussier |
Dyrcona++ |
09:16 |
rfrasur |
Dyrcona++ |
09:17 |
Dyrcona |
kmlussier++ #For testing billing development without realizing it. :) |
09:17 |
* Dyrcona |
makes a note to do something more permanent when he gets home this evening. |
09:17 |
rfrasur |
kmlussier++ #for good discussion/points on bug squashing |
09:17 |
kmlussier |
Dyrcona: Never hurts to get an early start on testing! ;) |
09:18 |
Dyrcona |
I'm going to check our training server just to be sure. |
09:19 |
Dyrcona |
It might be something that went in recently, but I doubt it is a problem without my void payment code also being in place. |
09:20 |
Dyrcona |
tsbere: I think I just realized why you still use 2.3.0 as the production version. :) |
09:38 |
Dyrcona |
Though I use Ubuntu, I'm really starting to dislike it in a serious way. |
09:38 |
asimon |
bshum: Yes, OpenSRF 2.2.0 supports Wheezy. |
09:38 |
csharp |
Dyrcona: what issues are you seeing? |
09:38 |
bshum |
csharp: That and testing for some of us :( |
09:38 |
|
krvmga joined #evergreen |
09:39 |
Dyrcona |
csharp: Frequently busted packages that stay busted, among other things. |
09:39 |
csharp |
hmm |
09:42 |
krvmga |
which tt2 file is displaying this data? |
09:43 |
bshum |
dbs: Oh in that case, it's the old dupe bug 1014724 |
09:43 |
pinesol_green |
Launchpad bug 1190279 in Evergreen "duplicate for #1014724 Modularize Makefile.install" (affected: 3, heat: 16) [Wishlist,In progress] https://launchpad.net/bugs/1190279 |
09:43 |
bshum |
Which blah |
09:43 |
bshum |
Points the wrong way |
09:43 |
bshum |
I tested berick's code for supporting wheezy now, but it used more CPAN than packages so I wanted to poke it further. |
09:43 |
* dbs |
kind of hates when new bugs live on, and the old bugs get closed as a duplicate. a bit. |
09:43 |
asimon |
Dyrcona: Yes, "libpq-dev is already the newest version." |
09:44 |
dbs |
kind of gives a false view of history. |
09:51 |
asimon |
csharp: Installing Evergreen before PostgreSQL 9.2 would solve this problem, no? |
09:51 |
* berick |
wonders where csharp got w/ his ubuntu experiment for bug #1190279 |
09:51 |
pinesol_green |
Launchpad bug 1190279 in Evergreen "Modularize Makefile.install" (affected: 3, heat: 16) [Wishlist,In progress] https://launchpad.net/bugs/1190279 |
09:51 |
csharp |
asimon: I think this is an APT level problem and that shouldn't matter (theoretically) |
09:52 |
|
yboston joined #evergreen |
09:53 |
csharp |
berick: my branch is here: http://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/csharp/ubuntu-per-distro-makefile - I got stalled out when CPAN was breaking on the 12.04 install |
09:53 |
csharp |
berick: I've been assuming the error is mine and when I spent a couple of hours trying to find it, I lost steam :-/ |
09:54 |
csharp |
10.04 installed okay in my test |
09:54 |
csharp |
my test only extended to seeing if the Makefile.install script finished without errors |
09:55 |
csharp |
asimon: interesting, I don't see a 9.2 branch here: http://apt.postgresql.org/pub/repos/apt/pool/ |
09:56 |
berick |
csharp: gotcha, thanks for the recap. i'll try to carve out a chunk of time soon to eyeball your branch |
09:56 |
berick |
would be nice to get these in |
09:56 |
csharp |
berick: thanks - I'll look again too |
10:00 |
dbs |
asimon: quite possibly. IIRC, there had been some question about PostgreSQL 9.2 support leading up to the 2.4 release, but AFAIK there's nothing preventing 9.2 from actually working |
10:00 |
Dyrcona |
dbs asimon: 9.2 works we've used it in our training and development servers. |
10:01 |
asimon |
dbs: Equinox Support has blessed PostgreSQL 9.2. |
10:01 |
* dbs |
seems to recall suggesting at some point that we make very clear statements about what distros / major dependencies are officially supported for particular releases as a standard process thing |
10:02 |
dbs |
Dyrcona: yeah, I've been using 9.2 on Fedora for a few months now too. but I don't hit all the pieces of Evergreen in my day-to-day testing |
10:06 |
csharp |
asimon: ah - I didn't look in /main |
10:07 |
asimon |
csharp: Note that Dyrcona has provided a different repo. |
10:08 |
csharp |
Dyrcona: asimon: thanks - getting my head turned around |
11:16 |
|
dboyle joined #evergreen |
11:19 |
mcooper |
berick++ too -- that looks great |
11:20 |
krvmga |
this is just a report back. in misc_util.tt2 adding the code -- or @code="h" -- to line 37 did not break anything and got me the GMD display in the title that i was looking for. |
11:21 |
pinesol_green |
[evergreen|Jason Etheridge] Eliminate a warning in Z3950.pm - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=e455913> |
11:21 |
pinesol_green |
[evergreen|Jason Etheridge] Test for an MFHD warning in 14-OpenILS-Utils.t - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=11f04ea> |
11:21 |
krvmga |
just for sanity, in my misc_util.tt2, i also changed line 36 'abmp' to 'abhmp' |
11:22 |
berick |
nc_cardinal++ # bug 1207396 |
11:22 |
pinesol_green |
Launchpad bug 1207396 in Evergreen "Patron self-registration form" (affected: 1, heat: 6) [Wishlist,In progress] https://launchpad.net/bugs/1207396 - Assigned to Bill Erickson (erickson-esilibrary) |
11:24 |
jeff_ |
uses the pending / staging user tables. |
11:24 |
rfrasur |
yes...and they hooked up a way to capture patron signatures (though I can't remember why right now...even though it was important) |
11:24 |
|
acoomes joined #evergreen |
11:25 |
pinesol_green |
[evergreen|Jason Etheridge] The check library for Debian and Fedora - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=ace3d99> |
11:25 |
pinesol_green |
[evergreen|Jason Etheridge] C unit test examples for Evergreen - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=33b6b48> |
11:25 |
egbuilder |
build #268 of evergreen-master-ubuntu-12.04-x86 is complete: Failure [failed test] Build details are at http://testing.evergreen-ils.org/buildbot/builders/evergreen-master-ubuntu-12.04-x86/builds/268 blamelist: Jason Etheridge <jasonesilibrary.com> |
11:25 |
egbuilder |
build #234 of evergreen-master-fedora-18 is complete: Failure [failed test] Build details are at http://testing.evergreen-ils.org/buildbot/builders/evergreen-master-fedora-18/builds/234 blamelist: Jason Etheridge <jasonesilibrary.com> |
11:26 |
egbuilder |
build #292 of evergreen-master-debian-6.00-x86_64 is complete: Failure [failed test] Build details are at http://testing.evergreen-ils.org/buildbot/builders/evergreen-master-debian-6.00-x86_64/builds/292 blamelist: Jason Etheridge <jasonesilibrary.com> |
11:26 |
phasefx |
ruh roh |
11:26 |
rfrasur |
jeff_: Do your libraries require picture ID? |
11:26 |
graced |
jeff_: neat! Where's the commit for that patron self-reg? |
11:27 |
rfrasur |
right...I was thinking that was bott |
11:27 |
* paxed |
is leery of leaving any kind of form that adds data to the database open without any kind of captcha. |
11:28 |
rfrasur |
paxed: it's not difficult to add that though, right? |
11:28 |
eeevil |
phasefx: no worries. buildslaves just need Test::Warn installed, it looks like |
11:28 |
csharp |
ubuntu and fedora slaves look ok |
11:29 |
bshum |
buildbot++ |
11:29 |
paxed |
rfrasur: nah. i've even rolled my own captchas for some small sites. |
11:34 |
bshum |
Dyrcona: It's a sign! |
11:35 |
Dyrcona |
Time to take up potato farming! |
11:35 |
|
jdouma joined #evergreen |
11:35 |
egbuilder |
build #293 of evergreen-master-debian-6.00-x86_64 is complete: Success [build successful] Build details are at http://testing.evergreen-ils.org/buildbot/builders/evergreen-master-debian-6.00-x86_64/builds/293 |
11:36 |
berick |
jeff_: if you have the time and feel like eyeballing my design doc for self-reg, i'd appreciate any input/suggestions you might have. real_world_experience++ |
11:37 |
pinesol_green |
[evergreen|Jason Etheridge] pgTAP examples - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=c36c86e> |
11:37 |
pinesol_green |
[evergreen|Galen Charlton] start adding pgTAP test cases - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=bb98f3f> |
11:37 |
pinesol_green |
[evergreen|Galen Charlton] use .pg extension for pgTAP test cases - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=97983b6> |
11:37 |
pinesol_green |
[evergreen|Galen Charlton] add regression test for LP#1155329 - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=bd4d765> |
11:37 |
pinesol_green |
[evergreen|Jason Etheridge] Use the .pg extension - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=7e8eec6> |
11:37 |
egbuilder |
build #270 of evergreen-master-ubuntu-12.04-x86 is complete: Success [build successful] Build details are at http://testing.evergreen-ils.org/buildbot/builders/evergreen-master-ubuntu-12.04-x86/builds/270 |
11:38 |
dbs |
phasefx et al: the test failures for buildbot are a good note to project-self that new prereqs should be called out in a specific section in release notes |
11:38 |
|
Rish joined #evergreen |
11:38 |
eeevil |
dbs: agreed |
11:38 |
phasefx |
dbs: sounds good |
11:40 |
Dyrcona |
OK. Works for me with either name. |
11:41 |
eeevil |
well, I should clarify that. I was thinking what I said /after/ Dyrcona mentioned a separate section... |
11:41 |
dbs |
"Upgrade notes" -> "New prerequisites" subsection, perhaps. |
11:41 |
csharp |
okay - I installed Test::Warn from respective distro repos and did general updates/reboots on fedora and ubuntu buildslaves |
11:42 |
dbs |
csharp: cool, resubmitted build |
11:43 |
egbuilder |
build #237 of evergreen-master-fedora-18 is complete: Success [build successful] Build details are at http://testing.evergreen-ils.org/buildbot/builders/evergreen-master-fedora-18/builds/237 |
11:43 |
dbs |
csharp++ |
11:44 |
csharp |
dbs: let me know if you'd like to either upgrade this one to F19 or build a separate F19 server |
11:45 |
pinesol_green |
[evergreen|Jason Etheridge] make-pgtap-tests.pl - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=d6ec452> |
11:45 |
dbs |
csharp: IMO, whenever you want to upgrade to F19. no rush :) |
11:45 |
csharp |
ok - understood |
11:46 |
bshum |
Dyrcona: tsbere: If either of you have time to poke again at bug 1204273, please do. Hoping to unbreak master in those areas. |
11:46 |
pinesol_green |
Launchpad bug 1204273 in Evergreen "bugs introduced with making state not required" (affected: 1, heat: 6) [High,Confirmed] https://launchpad.net/bugs/1204273 |
11:46 |
gmcharlt |
eeevil: you do realize that I now need to add a test case to catch instances of the misspelling "Moar"? ;) |
11:47 |
* csharp |
installs Test::Moar on the buildslaves too |
11:47 |
gmcharlt |
csharp++ |
11:47 |
csharp |
I CAN HAZ UNIT TESTZ? |
11:48 |
rfrasur |
csharp++ |
08:25 |
csharp |
heh |
08:25 |
bshum |
That's what led me to poke at it. |
08:26 |
bshum |
If I have a moment later this morning, I'll dust off my branch. |
08:27 |
csharp |
I believe 'LEFT JOIN actor.card circ_card ON circ_u.card = circ_card.id' will accomplish what I'm trying to fix |
08:27 |
csharp |
since users can have multiple active cards now too |
08:27 |
* csharp |
is testing the view query now |
08:28 |
csharp |
oh, and for the logs, we're discussing bug 1072892 |
08:28 |
pinesol_green |
Launchpad bug 1072892 in Evergreen "reporter.classic_item_list view creates repeated rows" (affected: 1, heat: 6) [Undecided,Incomplete] https://launchpad.net/bugs/1072892 |
08:28 |
bshum |
csharp++ |
08:29 |
|
kbeswick joined #evergreen |
10:11 |
csharp |
eeevil: thanks - I'll look into window functions |
10:12 |
|
CarrieC joined #evergreen |
10:17 |
pastebot |
"eeevil" at 204.193.129.146 pasted "possible replacement for csharp" (9 lines) at http://paste.evergreen-ils.org/14 |
10:17 |
csharp |
eeevil++ |
10:18 |
csharp |
I'll test it |
10:18 |
eeevil |
csharp: there are many more than that one to convert, of course. and I'm testing on an empty db, so the syntax works but we may need to add window range conditions |
10:18 |
csharp |
good to know |
10:25 |
|
mcooper joined #evergreen |
10:26 |
csharp |
eeevil: that returns a list of rows rather than a single row (though the last one has the correct total owed) |
13:15 |
|
kmlussier joined #evergreen |
13:19 |
csharp |
eeevil: I've been working on the other money views. The only ones I'm unsure how to approach conversion with are money.billable_xact_summary_new and money.billable_xact_with_void_summary since they are pretty complicated with subqueries |
13:20 |
|
dboyle joined #evergreen |
13:24 |
eeevil |
csharp: I don't have time to look currently, but I would say toss the ones you have up as a branch for testing and signoff and we can address the remainders later |
13:24 |
eeevil |
csharp++ |
13:25 |
csharp |
will do - thanks for your help! |
13:26 |
|
Dyrcona joined #evergreen |
13:35 |
|
timf joined #evergreen |
09:01 |
|
ericar joined #evergreen |
09:08 |
|
sborger joined #evergreen |
09:19 |
|
kmlussier1 joined #evergreen |
09:21 |
mmorgan |
jboyer-isl: your suggestion to delete rows from the action_trigger.event table worked, I was able to rerun my test trigger. Thanks! |
09:22 |
jboyer-isl |
Good to hear. maybe now I can clean up some of the failed events that are sitting around in ours. :D |
09:29 |
|
mcooper joined #evergreen |
09:33 |
bshum |
So I'm getting some javascript errors on large pull lists when using the "Clear Hold Shelf" option directly off the Circulation menu actions. |
14:13 |
dbwells |
jeff_: Let me know whenever you are done with your latest NCIP commits, and I will pull those into the jonscott repo right away. |
14:13 |
jeff_ |
dbwells: thanks! |
14:14 |
jeff_ |
dbwells: are you guys using the duplicate message detection? i've removed it in https://github.com/tadl/iNCIPit/commit/537b6a763ae6ec1a48d1bd9439daa177436f3bf1 |
14:15 |
dbwells |
jeff_: If your testing shows it should be removed, I have no issue with removing it. |
14:21 |
|
sseng joined #evergreen |
14:22 |
Dyrcona |
FWIW, I thought it should be removed the first time that I tried testing iNCIPit. |
14:24 |
jeff_ |
In testing, we rarely received duplicate messages (other than those that were legit retries after a failure to respond properly). The duplicate message detection was apparently due to an old issue that is no longer an issue, and it can cause problems such as failure to auth the same patron twice in a row. |
14:24 |
jeff_ |
Also, it would require shared storage or a modification to use memcache to work in multi-server environments, so I was pleased when told by MeLCat staff that it should no longer be needed. :-) |
14:26 |
|
bshum joined #evergreen |
14:28 |
|
rfrasur joined #evergreen |
14:29 |
bshum |
Am I back? Maybe... |
15:45 |
jventuro |
I was wondering the same thing about email requests. Should I have requesters respond to the list, or directly to me. |
15:45 |
|
AaronZ-PLS joined #evergreen |
15:46 |
jventuro |
I have no problem with doing that, chtrotter. I am the list admin :) |
15:46 |
AaronZ-PLS |
Looking for an action trigger hook to send a test email every day, is there one that would work? |
15:47 |
jventuro |
Hi AaronZ-PLS. We're having a meeting at the moment. Would you mind tabling your question for 15 minutes or so? |
15:48 |
AaronZ-PLS |
Willdo. |
15:49 |
jventuro |
Thanks! |
16:16 |
pinesol_green |
Minutes: http://evergreen-ils.org/meetings/evergreen/2013/evergreen.2013-07-30-15.00.html |
16:16 |
pinesol_green |
Minutes (text): http://evergreen-ils.org/meetings/evergreen/2013/evergreen.2013-07-30-15.00.txt |
16:16 |
pinesol_green |
Log: http://evergreen-ils.org/meetings/evergreen/2013/evergreen.2013-07-30-15.00.log.html |
16:17 |
AaronZ-PLS |
Looking for an action trigger hook to send a test email every day, is there one that would work? |
16:21 |
paxed |
AaronZ-PLS: if you just want to send a test email, you could just invoke mail directly from crontab ...? |
16:21 |
AaronZ-PLS |
paxed: Could do that, but looking to make action triggers arent hanging as well as making sure email is happy from end to end |
16:36 |
gsams |
AaronZ-PLS: I know it wouldn't be quite as informative, but the mail log should be a pretty good indication of whether action triggers are working or not. I can't say that I've tried looking into it in any other way myself. |
17:11 |
|
smyers_ joined #evergreen |
14:00 |
jeff |
email and IM are poor methods of revision control. |
14:01 |
Dyrcona |
Yes, they are. |
14:01 |
Dyrcona |
I use git as a sort of distribution mechanism, too. |
14:02 |
Dyrcona |
I edit the code on the laptop and then push to the server to test it. |
14:02 |
* jeff |
nods |
14:07 |
jeff |
fieldmapper alias typos are one of those "probably really difficult to fix" things. |
14:09 |
Dyrcona |
Could be.... |
14:56 |
yboston |
Dyrcona: Thanks. I guess setting active=false could be helpful if I change my mind so it is easy to reinstate? any other reasons off the top of your head? |
14:56 |
Dyrcona |
yboston: It's just what I typically do rather than delete. |
14:57 |
yboston |
Dyrcona: thanks for the info and sharing your preferred workflow |
14:57 |
kmlussier |
Dyrcona++ |
14:57 |
kmlussier |
I forgot include you in all the thanks I sent yesterday when signing off on the bib browse code, so I'm sending along karma now instead. |
14:58 |
kmlussier |
Dyrcona can not get enough good karma for all the assistance he gives me when I'm testing code. :) |
15:18 |
csharp |
@karma Dyrcona |
15:18 |
pinesol_green |
csharp: Karma for "Dyrcona" has been increased 382 times and decreased 3 times for a total karma of 379. |
15:31 |
|
mrpeters left #evergreen |
15:41 |
|
zerick joined #evergreen |
15:52 |
mmorgan |
I'm trying to test an action trigger. Is there a recommended way to remove rows from the database so I can tweak and retest? |
16:06 |
jboyer-isl |
mmorgan: A guess I'm thinking of testing soon: delete from action_trigger.event where event_def=(The event id you're testing). You could add additional clauses for add_time, state, etc. if needed. |
16:07 |
|
smyers_ joined #evergreen |
16:08 |
jboyer-isl |
but note that I've not tried it yet. |
16:10 |
mmorgan |
Thanks, anything I try will be on a test server :). Will deleting the row from action_trigger.event also remove rows from action_trigger.event_output? |
16:10 |
mmorgan |
or can those just stay there and not bother anybody? |
16:10 |
jboyer-isl |
Ah, I doubt it. |
16:10 |
|
rfrasur joined #evergreen |
16:10 |
jboyer-isl |
Cleaning them up might make testing easier, if that's where you're looking for success/failure. |
16:14 |
mmorgan |
Good point. I will give this a try on a test server, but maybe not til Monday. Thanks! |
16:16 |
bshum |
In the old days, we used to just put complete times on unfinished A/T events |
16:16 |
bshum |
And change the status |
16:17 |
bshum |
But deleting is also simple too. |
16:20 |
mmorgan |
I'm fine with updating rather than deleting. I'm testing notices and want to be able to run the same trigger again for the same user. |
16:23 |
mmorgan |
events for the event_def I'm working with have status complete but complete_ time of null. Can I update these fields to get it to run again after I make changes to the template? |
16:25 |
|
jdouma joined #evergreen |
16:25 |
|
kbeswick joined #evergreen |
16:30 |
|
jdouma joined #evergreen |
16:31 |
|
mcooper joined #evergreen |
16:36 |
|
smyers_ joined #evergreen |
16:46 |
|
shadowspar joined #evergreen |
16:49 |
bshum |
mmorgan: Hmm, I'd say, probably |
16:50 |
bshum |
I think we used to do that when we were testing acq EDI |
16:50 |
bshum |
And it would error out |
16:50 |
bshum |
So we'd tweak things, then null out the output and complete stuff and try again |
16:54 |
mmorgan |
Thanks! I'll look at that on Monday, too. Don't want to try anything new on a database on a Friday afternoon. |
16:55 |
kmlussier |
mmorgan: Go home and enjoy the beautiful weather! ;) |
16:55 |
mmorgan |
What beautiful weather?? Where?? It's quite gray out my window! |
11:08 |
|
akilsdonk_ joined #evergreen |
11:08 |
* rfrasur |
goes to delegate. |
11:11 |
RoganH |
If interest is high enough based on the doodle poll I might do two dates. |
11:16 |
csharp |
okay, so since open-ils.storage.asset.copy.circ_count pulls more than just a raw count from the circ table, I've fixed it (on my test machine) to use action.all_circulation... so now the issue is probably to recreate a new method for grabbing the circ count from extend_reporter.full_circ_count and use that in place of open-ils.storage.asset.copy.circ_count ;-) |
11:17 |
csharp |
s/recreate/create/ |
11:17 |
csharp |
I'll update the bug with what I've done and we can continue the discussion there |
11:21 |
bshum |
Huh, why would uploading offline transactions fail on "PERM_FAILURE" where almost all of them list out as needing "CIRC_PERMIT_OVERRIDE" |
11:21 |
rfrasur |
RoganH++ |
11:22 |
bshum |
I looked at the patron and items and they don't seem to require any override |
14:34 |
jeff_ |
these libraries use these vendors with {Evergreen|Koha} |
14:34 |
jeff_ |
etc |
14:35 |
csharp |
@hates |
14:35 |
pinesol_green |
csharp hates dojo_hold_policies_interface; SIP; when libraries purchase third party products without testing and blame Evergreen for it not working; reports; the fact that the Base Filters is unnecessarily greyed out when applying an Aggregate Filter and vice versa; evil; and reports more |
14:35 |
rfrasur |
ooooo....base filters! |
14:35 |
Dyrcona |
jeff_: EBSCO EDS. It appears to be aimed at academic libraries but one of our publics has signed up for it. |
14:37 |
csharp |
Dyrcona: I have that same project for PINES libs and GALILEO |
18:37 |
bshum |
Probably not |
18:37 |
bshum |
Still, perhaps you've stumbled into a quirky issue area. |
18:37 |
bshum |
:D |
18:37 |
gsams |
I suppose it would warrant some testing in some way, since this does appear to be a bug in our system at least |
18:38 |
gsams |
And I'm not sure if possible incoming libraries would be interested in using this feature |
18:38 |
gsams |
or current libraries for that matter |
18:38 |
gsams |
will enquire |
18:45 |
|
CarrieC left #evergreen |
18:48 |
bshum |
Well, the code looks like it ought to prompt the user with something. |
18:48 |
bshum |
I'm going to try testing it on one of our servers to see if it does |
18:50 |
bshum |
Well the popup worked |
18:50 |
bshum |
Generated an alert that asks me to verify the hold upon checkin |
18:51 |
bshum |
So I don't think there's a problem there. |
18:52 |
bshum |
gsams: Maybe there was something weird with the hold and doing that find another target helped move it on the right path again. |
18:52 |
bshum |
And that hold verify on the copy location wasn't involved. |
18:52 |
bshum |
Though good to check and make sure it's what the library wants. |
18:53 |
gsams |
I did all of those steps before turning it off and it didn't have that behavior then |
18:53 |
bshum |
Very weird. |
18:53 |
gsams |
indeed. I'll take a thorough look into it tonight if I get a chance |
10:26 |
rfrasur |
mmorgan: thanks. I noted that it did clear the field but didn't notice a message. That could be because I added my own though. |
10:27 |
|
mcooper joined #evergreen |
10:27 |
mmorgan |
I actually had to reload the patron (F8) to see the message. It didn't refresh until I did that. |
10:28 |
rfrasur |
okay, I'll go in and test it. I was wondering if it'd be a good idea to bar email addresses...but I can see that being a bad idea as well. |
10:30 |
jeff |
there's no current method to do so. |
10:30 |
jeff |
i've not had need to do so here. |
10:31 |
rfrasur |
well, honestly, the only need to do it here stems from repeated inaccuracies in input...and a lack of attention. |
10:59 |
jeff |
jbfink: you're welcome! glad it was somewhat simple to fix! |
10:59 |
jbfink |
got opensrf like 99% done. Got one problem with the srf shell that I will pick at today. |
11:00 |
jeff |
jbfink: i'm interested to hear what your thoughts on docker are, perhaps after you've used it more (if it's brand new to you) |
11:00 |
jbfink |
if this works though it will make deployment (in test instances at least) like about super super easy. |
11:00 |
jbfink |
I've done some work with it. |
11:00 |
jbfink |
I would not call myself an expert, but boy, is it something really intriguing. |
11:00 |
jbfink |
I did a Koha container for it. :) http://index.docker.io/u/jbfink/koha |
11:01 |
dbs |
jbfink++ |
11:01 |
|
CarrieC joined #evergreen |
11:10 |
rfrasur |
RoganH: Do you have a minute to talk about the inventory module project? |
17:00 |
rfrasur |
forEVER! |
17:01 |
rfrasur |
I wish we could actually get a real circ statistic on it...but will figure that out after it gets rolling and people care enough. |
17:02 |
gsams |
bshum: I didn't even think to check that at all, thanks again |
17:03 |
bshum |
gsams: No problem man. I couldn't remember how it was all setup either :) |
17:04 |
bshum |
Glad it's not a bug or other problem. |
17:06 |
bshum |
Dyrcona++ tsbere++ #for live testing the pain and suffering ahead of the rest of us |
17:06 |
bshum |
(and fixing it) |
17:07 |
Dyrcona |
Who said anything about fixing it? ;) |
17:08 |
Dyrcona |
Well, the first attempt caused a different error, but we'll have it by the end of the week, I'm sure. |
17:08 |
* tsbere |
made things worse, a nicer error for the user, but then a crashed circ backend |
10:16 |
moodaepo |
eeevil++ |
10:19 |
|
caveman273 left #evergreen |
10:24 |
|
ericar_ joined #evergreen |
10:25 |
dbs |
jboyer-isl: I suspect there would be a) bits of time for devs who are not familiar with a given area to get up to speed on certain areas (websockets, security, testing come to mind from last hack-a-way); communication and coordination on critical areas; and powering through things that especially benefit from collaboration |
10:26 |
dbs |
It's not a "how to develop Evergreen bootcamp" though |
10:26 |
jboyer-isl |
Thanks. |
10:27 |
* dbs |
notes that he's not the organizer and might be off-base |
10:27 |
jboyer-isl |
Well, it can't be too much of that, or nothing else would get done. |
12:07 |
bshum |
Total bill showing underneath the "bills" button in the patron interface. |
12:08 |
Dyrcona |
bshum: Red usually means a deficit. If it does show up in red maybe it means the library owes the patron. |
12:08 |
bshum |
Aha! |
12:08 |
Dyrcona |
You should test that to be sure, though. |
12:08 |
bshum |
Yeah I'm checking now |
12:09 |
bshum |
Nope, it's still black for them too. |
12:09 |
bshum |
$-8.00 in black text |
12:09 |
bshum |
I think the library is imagining the red. |
12:09 |
bshum |
Hmm |
12:10 |
Dyrcona |
I've never seen it in red personally, but I don't work with it that much. |
12:10 |
mmorgan |
fine threshold is set at $50, and my test patron owes $63.60, which appears in red under the Bills button. |
12:11 |
Dyrcona |
I bet that's it in bshum's case too, not those numbers exactly, but |
12:12 |
bshum |
mmorgan: Dyrcona: We'll check for that, thanks! |
12:15 |
RoganH |
A quick reminder - Hackaway 2013 Registration is open now and until 8/15 http://hackaway2013.eventbrite.com/ |
12:19 |
|
jihpringle joined #evergreen |
12:25 |
|
ElliotFriend joined #evergreen |
12:27 |
ElliotFriend |
Is there a way to display branch information (hours, address, etc.) in the OPAC? On an "About the library" page, for example? |
12:28 |
kmlussier |
ElliotFriend: It's not available yet, but I'm currently testing https://bugs.launchpad.net/evergreen/+bug/1201982, which will allow libraries to provide a link to this information. |
12:29 |
pinesol_green` |
Launchpad bug 1201982 in Evergreen "TPAC: In copy table, link library name to an external URL (if OU setting exists)" (affected: 1, heat: 6) [Wishlist,New] |
12:29 |
kmlussier |
I expect it will be available as of 2.5 |
12:29 |
dbs |
ElliotFriend: I'm also interested in automatically generating pages like that in the TPAC, with schema.org markup |
13:41 |
|
montgoc1 joined #evergreen |
13:44 |
* dbs |
takes a quick look for "template" in the official docs and notices that we are overloading the term "template" quite severely |
13:47 |
jeff_ |
tt2 templates, bib templates, copy templates, receipt templates... |
13:48 |
bshum |
jihpringle: Question for you when you have a moment about acq... |
13:48 |
bshum |
jihpringle: mllewellyn has been poking at receiving items in invoicing and seeing a quirk where clicking on it results in a loading bar animation that doesn't go away. |
13:49 |
bshum |
jihpringle: Curious if you've seen that anywhere in your 2.4 acq testing. |
13:49 |
bshum |
We're looking in our logs to see if we can trace it back now. |
13:50 |
jihpringle |
bshum: I don't recall seeing anything like that recently in acq and our libraries haven't reported it, but I have previously seen that in year end |
13:51 |
jihpringle |
I've also seen that in Circulation Policies especially when applying limits to existing policies |
13:51 |
|
abneiman joined #evergreen |
14:43 |
StephenGWills |
nod. kmlussier++ |
14:43 |
kmlussier |
RoganH: I was thinking a vote could wait until we have a real policy to vote on. |
14:44 |
StephenGWills |
it sounds if, if a motion is needed it would come next meeting? |
14:44 |
gmcharlt |
yes |
14:44 |
gmcharlt |
#action kmlussier will draw up an Evergreen version of Koha's support listing policy for consideration by the EOB by the August meeting |
14:45 |
* gmcharlt |
notes, BTW, that Koha's webmaster uses a particular WordPress plugin, Connections, for managing the directory; has worked well so far |
14:45 |
gmcharlt |
moving on |
14:45 |
gmcharlt |
#topic Follow-up on testing meeting |
14:45 |
* StephenGWills |
makes a note and runs to google |
14:45 |
gmcharlt |
sborger: you have the follow |
14:46 |
gmcharlt |
*floor |
14:46 |
sborger |
I have notes from our conference call which I would like to share but wasn't sure what would be appropriate. Also, I don't have access to Google docs at work. Would the board like to review the notes from the meeting? |
14:47 |
sborger |
Shall I email Galen or Kathy for them to quickly upload the minutes to Google docs so everyone can review? |
14:47 |
gmcharlt |
sborger: please |
14:48 |
sborger |
Since this was the first meeting, I spent much of the time asking questions to find out what has been done in the past and what is presently done in terms of testing Evergreen. |
14:48 |
gmcharlt |
#info Minutes of the 2013-07-02 testing conference call are at https://docs.google.com/file/d/1ImfRJH4V_5xUhTmv_8ni4ekt7_J-4gBU_EGz_lrOI9renZEO26QpHCwZ3JRL/edit?usp=sharing |
14:49 |
sborger |
We discussed collaboration with DIG since there certainly is an opportunity there and we don't want to recreate the wheel. |
14:50 |
gmcharlt |
any questions for sborger? |
14:50 |
sborger |
Moving forward, it was recommended that we plan another conference call and invite Yamil (DIG), a rep from Equinox (QA project) and a developer (Dan Scott). |
16:38 |
|
sseng joined #evergreen |
16:41 |
bshum |
senator: Hmm, changed that global flag and it still takes about 16-17 seconds |
16:42 |
* bshum |
now realizes he should have noted what the original value of that flag was. |
16:42 |
senator |
bshum: it was 100 |
16:42 |
senator |
thanks for the test! |
16:42 |
bshum |
Gotcha. |
16:43 |
bshum |
So no, unfortunately no effect it seems |
16:54 |
|
afterl left #evergreen |
11:12 |
dbs |
-1 to "in production" as good enough. "in production" means "with one very limited set of settings" |
11:13 |
eeevil |
dbs: what is good enough, then, for a bug fix? |
11:14 |
dbs |
and they may be in production, without the other fixes that are in production elsewhere, with not so good results |
11:14 |
eeevil |
dbs: code changes that aren't tested in production are tested on (normally) one non-author developer's test server |
11:15 |
gmcharlt |
dbs: I grant that that is a real concern, but do you have any alternative? a good many things simply do not get tested adequately before they hit master; at least bugfixes that are in actual production use have at least a bit more going for them, no? |
11:17 |
dbs |
The alternative that I proposed in the past was a commit checklist, which has had no adoption, but would probably be a good idea for sites to look through. |
11:18 |
eeevil |
to be clear, all, I'm talking about but fixes for common problems. IOW, things that have been seen (in this case, that I have seen) at multiple EG sites, for which a fix has been developed and shown to work |
11:18 |
dbwells |
I've sometimes wondered if we should adopt a more general bug-aging policy, i.e. and bugfix branch older than X is fair game for the author to commit. This would not apply to features, and I am not sure what "X" should be. |
11:21 |
eeevil |
dbs: you're not alone, as you well know (**points at self**), but that's also much more rare these days |
11:21 |
dbs |
I'm not sure we know what we _want_ to accomplish |
11:21 |
eeevil |
dbwells: for my part, yes, I'm trying to find a way to get real problems fixed without straying from convention where at all possible |
11:22 |
dbs |
What I would want to accomplish would be to have a reasonable amount of certainty that a commit doesn't introduce regressions for common but complex scenarios. |
11:23 |
dbs |
Sounds like phasefx is working towards that with the recreation of Ben's effort from a couple of summers back of an auto-installing VM that runs various test cases and reports on the results, which would be a good move. |
11:23 |
eeevil |
dbs: in an existential sense? ;) I know what I'm trying to accomplish: fixes are offered based on problems at live sites, but they are not of the type that many EG developers care about, or feel comfortable working on, or believe effects them or their site |
11:24 |
eeevil |
and I'm trying to find an equivalent to "wait for someone to care" |
11:25 |
dbs |
eeevil: no, I sometimes wonder whether one of the goals is "bug inbox zero" and whether that's actually a worthwhile goal (sez the guy with a mail inbox in the thousands) |
11:32 |
* berick |
reminds self to let things simmer in all cases |
11:33 |
gmcharlt |
it also points to another factor -- simmering time as compared to the complexity of the patch |
11:33 |
dbwells |
I am also -1 on this proposal, but that is mostly out of default, and not having enough time and information to properly consider the whole situation. |
11:33 |
eeevil |
since there is reasonable and thoughtful objection to "production testing is not enough", I'll be leaving 2 bug fixes unmerged for 2.4.1, unless someone wants to put their name on them next to mine. the two bugs, for reference, are: https://bugs.launchpad.net/evergreen/+bug/1200770 https://bugs.launchpad.net/evergreen/+bug/1200768 |
11:33 |
pinesol_green |
Launchpad bug 1200770 in Evergreen 2.4 "Search result rendering can crush the system" (affected: 1, heat: 6) [High,New] |
11:33 |
pinesol_green |
Launchpad bug 1200768 in Evergreen "2 remaining authority fixed fields out of whack" (affected: 1, heat: 6) [Medium,New] |
11:34 |
gmcharlt |
I can vouch for 1200700, having done quite a bit of back and forth with eeevil over it, FWIW |
11:36 |
dbs |
complexity, severity, local priorities, expertise - all compounding factors, and poor old i18n gets crushed in many cases :/ |
11:36 |
eeevil |
there's a third that I wanted to get in too, and if my stirring up this mess gets eyes on it that it's been worth it, but it's much newer than those two: https://bugs.launchpad.net/evergreen/+bug/1201962 |
11:36 |
pinesol_green |
Launchpad bug 1201962 in Evergreen 2.4 "hold count by record includes useless where clause" (affected: 1, heat: 6) [Medium,New] |
11:37 |
dbs |
eeevil: yeah, that one sounded good. |
11:38 |
dbs |
Many of these would be slam-dunks if we could drop them in, run a standard set of system tests, and note any differences in performance or output |
11:39 |
dbs |
Otherwise, we eyeball it and take our chances, or go through the laborious process of setting up a test environment, test data, profiling, etc to try and do what machines do better anyway |
11:39 |
eeevil |
dbs: right, and that is what phasefx is working towards, but until then my hope was (in the case of 1200770) that multiple production sites would be enough |
11:39 |
dbwells |
eeevil: thanks for posting the bugs, I think that clarifies what you are asking |
11:40 |
eeevil |
hrm, perhaps that's a factor to consider, actually. if /multiple/ production sites use the fix, does that make a difference in terms of "production = sign-off"? |
12:19 |
dbwells |
eeevil: re:1200770, it seems like we might be missing an 'next' where we push the $bid back on. Otherwise, it seems like we end up running the request again anyway, since it is in just a bare 'else'. |
12:21 |
* eeevil |
looks |
12:22 |
dbs |
QA note for phasefx: recording log file sizes and looking for size increases over time might be worthwhile |
12:23 |
phasefx |
dbs: good idea. Besides explicit tests with assertions, I'm also thinking of doing straight up diffs of various outputs between runs, and logs certainly qualify |
12:25 |
dbs |
phasefx: yeah, diffs of expected output is pretty common. logs are going to be fuzzier due to time stamps and what not :/ |
12:25 |
phasefx |
yeah |
12:27 |
eeevil |
dbwells: yes. I'm going to force-push a 'next' in there |
12:29 |
|
edoceo joined #evergreen |
12:29 |
|
jihpringle joined #evergreen |
12:30 |
eeevil |
dbwells: complete |
12:30 |
dbwells |
eeevil: thanks, will test |
12:33 |
|
smyers_ joined #evergreen |
12:36 |
eeevil |
dbwells: thank you, kind sir |
12:36 |
|
remingtron joined #evergreen |
12:41 |
gmcharlt |
dbwells++ |
12:41 |
gmcharlt |
eeevil: I'm going to do some torture testing of that now |
12:41 |
eeevil |
gmcharlt: cool, thanks |
12:46 |
gmcharlt |
eeevil: OK, looks good |
12:46 |
gmcharlt |
again |
15:55 |
eeevil |
re-entering i18n doldrums ... makensis :( |
16:06 |
|
brentm_sage joined #evergreen |
16:14 |
|
bshum joined #evergreen |
16:22 |
dbs |
Dyrcona: re bug 1201982 - can you verify that misc_util.tt2 matches the diff at http://git.evergreen-ils.org/?p=working/Evergreen.git;a=commitdiff;h=aeabe10c51b502a7d9256c2e760fca13e726fdf3 on your test server? |
16:22 |
pinesol_green |
Launchpad bug 1201982 in Evergreen "TPAC: In copy table, link library name to an external URL (if OU setting exists)" (affected: 1, heat: 6) [Wishlist,New] https://launchpad.net/bugs/1201982 |
16:27 |
Dyrcona |
No, it doesn't. |
16:27 |
Dyrcona |
I'll make a new branch for tomorrow. |
17:08 |
Dyrcona |
ALTER FUNCTION action.copy_related_hold_stats(bigint) |
17:08 |
Dyrcona |
OWNER TO evergreen; |
17:08 |
Dyrcona |
Looks like a "bug" in the 0811 upgrade script to me..... |
17:08 |
eeevil |
ok ... testers wanted! http://evergreen-ils.org/downloads/previews/ has a pile of 2.4.1 files for lookin'. tests appreciated. waiting for at least one set of eyes to avoid brown-bagging |
17:08 |
eeevil |
AND THERE'S THER FIRST! ;) |
17:09 |
eeevil |
Dyrcona: yeah... I'm gonna remove that with a big ol' chainsaw |
17:09 |
dbs |
Dyrcona++ |
17:11 |
Dyrcona |
bah. pushing to a checked out branch is not advisable.... |
17:16 |
pinesol_green |
[evergreen|Mike Rylander] Explicit function ownership is not the job of upgrade scripts - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=e66ddf9> |
12:00 |
berick |
kmlussier: go for it |
12:08 |
|
jihpringle joined #evergreen |
12:08 |
dbs |
paxed: chrome and firefox both worked for the self-check for me, using OpenSRF master (due to that opensrf_xhr.js issue berick mentioned) when I wrote up http://docs.evergreen-ils.org/2.4/_self_checkout.html a week or so ago |
12:09 |
paxed |
maybe it's just some settings i'm missing then. i tried it with the test data that comes with eg. |
12:09 |
paxed |
the concerto |
12:09 |
dbs |
paxed: there were some gotchas that I noted along the way, too - like needing to have hours of operation set - and I documented those |
12:10 |
paxed |
ah. well, that's it then. |
12:10 |
dbs |
paxed: no, that's all that I used. |
12:28 |
bshum |
paxed: dbs: There's a bug ticket for that too. |
12:28 |
bshum |
https://bugs.launchpad.net/evergreen/+bug/1047485 |
12:29 |
pinesol_green |
Launchpad bug 1047485 in Evergreen "Selfcheck needs to be run with https" (affected: 1, heat: 10) [Low,Confirmed] |
12:31 |
bshum |
I vaguely recall testing mrpeters' fix and there was something odd about it. But I guess I should look again... |
12:53 |
rfrasur |
dbwells++ |
12:53 |
bshum |
dbwells++ indeed |
12:56 |
bshum |
eeevil: I think our hold targeter is set to 3 right now. |
14:07 |
gmcharlt |
I think that item was from phasefx? |
14:08 |
phasefx |
yes |
14:08 |
gmcharlt |
phasefx: take it away, then :) |
14:08 |
phasefx |
I have some code I'm wanting feedback on, kudos, etc ;) And I'm hoping others may want to tie it into what we're doing now, etc. |
14:09 |
phasefx |
http://git.evergreen-ils.org/?p=working/random.git;a=shortlog;h=refs/heads/collab/phasefx/wheezy_installer |
14:09 |
|
BigRig_ joined #evergreen |
14:09 |
phasefx |
basically, given a pristine debian wheezy installation, this will install and run Evergreen without any prompting, and then fire off the pgTAP tests we have, and potentially whatever tests we come up with that require a live environment |
14:10 |
phasefx |
an area I'm really weak on is Buildbot, though it's not necessary for what I'm trying to do, it'd be nice to have some integration there |
14:11 |
|
tmccanna joined #evergreen |
14:11 |
phasefx |
so, any thoughts, interest, comments, etc? |
14:11 |
phasefx |
defer discussion to list? |
14:12 |
gmcharlt |
phasefx: it's a good idea, but sounds like discussion will in fact need to be deferred |
14:12 |
eeevil |
comment: +1 |
14:12 |
|
acoomes joined #evergreen |
14:13 |
berick |
phasefx: would you accept patches for teaching the script to update an existing install and firing the tests again? |
14:13 |
gmcharlt |
ok, moving on |
14:13 |
berick |
if it doesn't do that already, that is |
14:13 |
gmcharlt |
#topic OpenSRF release |
14:35 |
jsime |
it wasn't clear from that initial review if the use of ILIKE was more extensive, though, hence the flagging of it |
14:35 |
eeevil |
jsime: very fair. thanks! |
14:35 |
jsime |
np |
14:36 |
patnorton |
dbwells - once we get moving with a fully functional test environment, approximately 2 − 2.5 months |
14:36 |
patnorton |
environment should be available this week |
14:36 |
patnorton |
i beleive |
14:36 |
dbwells |
patnorton: sounds good, thank you |
14:36 |
kmlussier |
Yes, we're hoping for this week unless tsbere tells me something differently. |
14:38 |
gmcharlt |
anything else on this topic, or any last-minute topics? |