| Time |
Nick |
Message |
| 02:42 |
|
AnxiousGarlic joined #evergreen |
| 02:42 |
|
AnxiousGarlic left #evergreen |
| 04:59 |
pinesol_green |
Incoming from qatests: Test Success - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 07:11 |
|
graced joined #evergreen |
| 07:39 |
|
rjackson_isl joined #evergreen |
| 07:42 |
|
sarabee joined #evergreen |
| 07:49 |
csharp |
Happy Bug Squashing Day, everyone! |
| 08:00 |
|
jboyer-isl joined #evergreen |
| 08:14 |
|
collum joined #evergreen |
| 08:18 |
|
mrpeters joined #evergreen |
| 08:22 |
|
akilsdonk joined #evergreen |
| 08:26 |
|
ericar joined #evergreen |
| 08:30 |
|
Dyrcona joined #evergreen |
| 08:32 |
|
julialima_ joined #evergreen |
| 08:42 |
|
mmorgan joined #evergreen |
| 08:43 |
pinesol_green |
[evergreen|Josh Stompro] LP#1395842: fix labels for A/T environment and parameter ID fields - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=211acf9> |
| 08:51 |
|
Newziky joined #evergreen |
| 08:55 |
gmcharlt |
grabbing 0914 |
| 08:58 |
Dyrcona |
Maybe today is a bad day to build a new dev. branch. |
| 08:59 |
Dyrcona |
Looks like there will be a lot of churn. |
| 08:59 |
csharp |
we hope so! |
| 09:00 |
* csharp |
just accidently blew away half his /home directory with 'rm -rf *' |
| 09:00 |
csharp |
haven't made that mistake in years |
| 09:00 |
Dyrcona |
Oops. Hope you have backups. |
| 09:00 |
csharp |
yeah - recent enough :-/ |
| 09:01 |
Dyrcona |
I deleted the wrong files one day last week or the week before, but could recover them easily enough. |
| 09:01 |
* Dyrcona |
keeps almost daily backups. |
| 09:01 |
* csharp |
keeps weekly |
| 09:01 |
pinesol_green |
[evergreen|Dan Pearl] LP#1155313: Repair generation of label_sortkey for monograph_part entries - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=aa682ee> |
| 09:01 |
pinesol_green |
[evergreen|Dan Pearl] LP#1155313: upgrade script and pgTAP tests for monograph_part label normalization fix - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=b754ad6> |
| 09:01 |
pinesol_green |
[evergreen|Galen Charlton] LP#1155313: fix copy-and-paste-o in test case - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=4e15727> |
| 09:01 |
pinesol_green |
[evergreen|Galen Charlton] LP#1155313: pin upgrade script to 0914 - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=0c305b9> |
| 09:01 |
Dyrcona |
Well, daily on the server, manual on the laptop, but run it every work day. |
| 09:01 |
csharp |
but I don't really keep anything of high value on my PC |
| 09:02 |
csharp |
I do most of my dev work on a remote server |
| 09:02 |
Dyrcona |
I do most of my actual work on the laptop and push it to servers to run it. |
| 09:02 |
Dyrcona |
git also doubles as a distribution mechanis. |
| 09:02 |
Dyrcona |
mechanism |
| 09:03 |
Dyrcona |
Oh. Good. Kernel update. Gonna have to reboot. |
| 09:03 |
Dyrcona |
Haven't had this laptop on since Thursday. |
| 09:03 |
Dyrcona |
BBIAB |
| 09:05 |
|
Dyrcona joined #evergreen |
| 09:06 |
Dyrcona |
Heard you missed me! I'm back! :) |
| 09:07 |
Dyrcona |
So, for those who don't know: the beta and other upcoming releases are being held back until tomorrow for bug squashing day. |
| 09:15 |
pinesol_green |
[evergreen|Galen Charlton] LP#1155313: recalculate normalized labels during upgrade - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=c45c445> |
| 09:21 |
|
yboston joined #evergreen |
| 09:25 |
|
maryj joined #evergreen |
| 09:34 |
Dyrcona |
Whee! Garbage in the input. Who knew? :) |
| 09:44 |
|
kbutler joined #evergreen |
| 09:45 |
csharp |
been using Fedora across all my computers since October, still typing 'sudo apt-get install...' |
| 09:45 |
Dyrcona |
Heh. |
| 09:46 |
* Dyrcona |
is putting 21,859 copies into storage. |
| 09:46 |
Dyrcona |
Or, rather having the database do it for him. ;) |
| 09:47 |
dbwells |
gmcharlt: I was momentarily confused by that upgrade script name. It may need some adjustment ;) |
| 09:47 |
gmcharlt |
gah, sorry about that |
| 09:47 |
gmcharlt |
I'll fix that now |
| 09:48 |
Dyrcona |
And I wait while setting org_unit visibility does its thing with copy visibility. |
| 09:48 |
dbs |
csharp: and how are you liking it (other than muscle memory for apt-get)? |
| 09:48 |
Dyrcona |
And didn't have to wait too long. |
| 09:49 |
* dbs |
loves doing bulk updates via psql |
| 09:49 |
Dyrcona |
After doing autogen.sh should I restart opensrf-settings? |
| 09:50 |
Dyrcona |
dbs: That or via perl. :) |
| 09:50 |
bshum |
Dyrcona: Usually I only restart apache after an autogen |
| 09:50 |
gmcharlt |
what bshum said, although generally reloading Apache suffices for me |
| 09:50 |
gmcharlt |
dbwells: fixed |
| 09:50 |
gmcharlt |
dbwells++ |
| 09:51 |
Dyrcona |
Yeah, was gonna say I do the reload, but for some reason was thinking settings needed a kick, too. |
| 09:51 |
dbwells |
gmcharlt: thank you, sir |
| 09:53 |
pinesol_green |
[evergreen|Galen Charlton] LP#1155313: fix mangling of schema upgrade script name - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=6c52b6e> |
| 09:54 |
Dyrcona |
I don't autogen very often in production. |
| 09:57 |
Dyrcona |
Man, I like programming and getting things done. |
| 09:58 |
Dyrcona |
Incidentally, my daughter discovered a taste of that "power" this weekend when I showed her how to setup scripts in Nautilus to act on selected files. |
| 09:59 |
Dyrcona |
She often seems uninterested, but I'm still hoping she'll become a real computer user. |
| 10:04 |
Dyrcona |
Ah.. Just discovered overloaded abbrevs in some of my script names: lp for Launchpad and lp for Large Print. |
| 10:04 |
Dyrcona |
Brain nearly exploded. ;) |
| 10:08 |
|
Stompro joined #evergreen |
| 10:08 |
jonadab |
Just don't get operating systems confused with oversized books. |
| 10:08 |
csharp |
dbs: love it |
| 10:10 |
|
abowling joined #evergreen |
| 10:15 |
Dyrcona |
jonadab: heh. |
| 10:16 |
Dyrcona |
That would be a fun one: a report on oversized books. ;) |
| 10:16 |
jonadab |
Spoiler: if you have them shelved off by themselves, they don't circulate as well as you'd want them to. |
| 10:18 |
gmcharlt |
thinking aloud... do we need a LP tag for signifying that a pullrequest has been reviewed, may be mostly OK, but requires some more work on the part of the patch author (or a later passerby) to be ready for merging? |
| 10:19 |
* gmcharlt |
has seen "incomplete", which canonically is more of a bug status rather than a patch status used for that |
| 10:19 |
* gmcharlt |
has also seen (and done) removing the pullrequest tag |
| 10:20 |
gmcharlt |
but that's seems going a bit too far unless the original patch is completely unworkable |
| 10:20 |
gmcharlt |
reviewed-wip? |
| 10:21 |
bshum |
gmcharlt: Personally if a submitted patch requires further work, I would mark the bug as "incomplete" and notes in the comment and removing the "pullrequest" tag. |
| 10:22 |
bshum |
Just depends on whether you want to do the reworking, or if you're just telling the original author, hey fix X,Y,Z and we'll review and merge it. |
| 10:23 |
gmcharlt |
I think I prefer setting the bug status back to "confirmed" (unless it's also the case that the patch reviewer cannot reproduce the bug at all) |
| 10:24 |
gmcharlt |
given that LP's description of that status is "Cannot be verified, the reporter needs to give more info." |
| 10:24 |
gmcharlt |
and since there's nothing saying that the patch submitter is the same person as the reporter(s), or that they work for the same organization... |
| 10:25 |
bshum |
So in your definition is "submitter" meant to imply the person who wrote the code for the fix? |
| 10:26 |
gmcharlt |
yes |
| 10:26 |
bshum |
Vs. "reporter" the person who created the LP |
| 10:26 |
|
krvmga_ joined #evergreen |
| 10:26 |
gmcharlt |
right |
| 10:26 |
bshum |
Then I might say that http://wiki.evergreen-ils.org/doku.php?id=dev:bug_wrangler:faq defines "incomplete" as a reasonable status for that situation, even if LP's description sucks for it. |
| 10:27 |
bshum |
That said, I'm open to setting a bug's status back to "confirmed" or "triaged" in a situation like the one you describe. |
| 10:27 |
bshum |
For revised clarity. |
| 10:27 |
bshum |
And updating the bug status definitions appropriately. |
| 10:27 |
gmcharlt |
bshum: er, where in "The bug report is missing important information preventing it from being fixed. The submitter should be notified to provide additional information." does it say anyting about a patch? |
| 10:27 |
krvmga_ |
i tried re-installing EG 2.7.3 from scratch again. i ended up with the same fatal error for SpiderMonkey |
| 10:28 |
krvmga_ |
here's the paste: http://paste.evergreen-ils.org/39 |
| 10:28 |
bshum |
gmcharlt: For my read, I view any unfinished work as "incomplete" if both the bug being incomplete or the submitted work being incomplete. But that's just my opinion ;) |
| 10:28 |
bshum |
So missing information is missing. |
| 10:29 |
gmcharlt |
bshum: conflating bug status and patch status could lead to... interesting outcomes |
| 10:29 |
gmcharlt |
for example |
| 10:30 |
gmcharlt |
Person A reports a bug, and provides enough information for others to report it |
| 10:30 |
bshum |
gmcharlt: I'm not disagreeing with you. I'm just stating how we've previously worked through this. |
| 10:30 |
bshum |
You don't need to say more, I'm convinced :) |
| 10:30 |
gmcharlt |
Person B writes a patch, makes a pull request, but does a bad job of it... |
| 10:30 |
gmcharlt |
OK, I'll stop working out the example :) |
| 10:30 |
gmcharlt |
but I think you see where I'm going with it? |
| 10:32 |
gmcharlt |
so back to my original question, slightly modified |
| 10:33 |
gmcharlt |
do we want to do anything other than removing the pullrequest tag when a reviewer decides that more work is required, but also wants to make it clear that WIP has, in fact progressed? |
| 10:35 |
bshum |
Well, do you want to do something extra gmcharlt? :D |
| 10:36 |
dbs |
change the tag to pullrequest+- ? :) |
| 10:36 |
gmcharlt |
bshum: along the lines of adding a tag? sure; I wouldn't have started this discussion otherwise |
| 10:36 |
gmcharlt |
and perhaps something other than "failedqa" :) |
| 10:37 |
bshum |
I suppose in terms of precedence, it's not something we haven't done before with something like "needsreleasenote" (etc.) |
| 10:37 |
gmcharlt |
indeed |
| 10:37 |
bshum |
The thing I've often found more difficult than adding a tag is getting the original submitter to actually pay attention again and fix what they submitted :) |
| 10:39 |
bshum |
So whatever tag you use, sure. But we also need a way of informing contributors properly if they're not paying attention. Less we continue to risk code rot on bugs :( |
| 10:40 |
gmcharlt |
wrapping comments around rocks tossed through windows? |
| 10:40 |
gmcharlt |
:) |
| 10:41 |
gmcharlt |
though more seriously, particularly if a patch reviewer cares enough about an issue to actually write the follow-ups they've requested |
| 10:41 |
csharp |
yowza - 571 "dusty" bugs |
| 10:41 |
csharp |
anyone else looking at those? I want to go through them without duplicating effort if possible ;-) |
| 10:42 |
gmcharlt |
after a decent interval to allow the patch submitter to respond, the reviewer could do their own branch and put a fresh pullrequest on the bug |
| 10:42 |
gmcharlt |
either with their follow-ups or, if it came to it, their alternative implementation |
| 10:43 |
gmcharlt |
alas, I don't see a way in LP for patch submitters to readily hilight the correspondance on the bugs that they've submitted to |
| 10:44 |
* csharp |
stares at bug 1207533 |
| 10:44 |
pinesol_green |
Launchpad bug 1207533 in Evergreen 2.5 "Triggered event log times out for large-data sites" (affected: 14, heat: 74) [Medium,Confirmed] https://launchpad.net/bugs/1207533 |
| 10:44 |
gmcharlt |
so, to toss a specific idea out there |
| 10:44 |
gmcharlt |
*needspatchfollowup |
| 10:45 |
Dyrcona |
Too long. |
| 10:45 |
Dyrcona |
Tags should be short. |
| 10:45 |
csharp |
tagthatisdescriptivewithoutbeingtoolonganddoesntstraintheeyes |
| 10:46 |
bshum |
"needslove" |
| 10:46 |
bshum |
But more seriously |
| 10:46 |
csharp |
patchfollowup? |
| 10:46 |
gmcharlt |
needsrepatch? needsnewpatch? |
| 10:46 |
csharp |
needsrepatch makes sense |
| 10:47 |
goood |
FWIW, the postgres community uses "returned with feedback" in their "commitfest" app to signify "reviewed, needs love, but not rejected" |
| 10:47 |
Bmagic |
just "repatch" |
| 10:48 |
* gmcharlt |
points out that LP does have autocompletion for tags |
| 10:48 |
gmcharlt |
feedbacked? |
| 10:50 |
Dyrcona |
How bout dontwork |
| 10:50 |
phasefx |
back_to_gmcharlt, back_to_bshum? :) |
| 10:51 |
Dyrcona |
Only thing I can think of that's shorter is a four-letter synonym of excrement. |
| 10:51 |
gmcharlt |
http://www.easypolls.net/poll.html?p=54f486e6e4b0fec8f472c7c6 |
| 10:51 |
bshum |
phasefx: Well for that, I would use the "assigned to" field, but nobody ever seems to pay attention to those. |
| 10:51 |
bshum |
I'm partial to "repatch" for simplicity. |
| 10:52 |
* mmorgan |
likes "needsrepatch". Makes it clearer something is needed, like "needsreleasenote" |
| 10:54 |
bshum |
Might need to bring this to the dev list or something for broader inclusion? |
| 10:54 |
phasefx |
just an aside, folks should feel free to poke me "out of band" for a LP bug if need be |
| 10:55 |
bshum |
And write up the whole workflow |
| 10:55 |
kmlussier |
csharp: The "dusty" bugs link is just all of the bugs, with the oldest ones sorting to the top of the list. |
| 10:57 |
kmlussier |
+1 to needsrepatch |
| 10:57 |
Dyrcona |
Dude, that poll site does not look safe. |
| 10:58 |
Dyrcona |
It says you need a Java update and if you click no it takes to what appears to be a Flash player update. |
| 10:58 |
gmcharlt |
*sigh* |
| 10:58 |
gmcharlt |
didn't do that to me |
| 10:59 |
collum |
"needsrepatch" is understandable without seeing the above conversation, "repatch" not so much. |
| 10:59 |
csharp |
kmlussier: ah - thanks |
| 10:59 |
jboyer-isl |
Nor me. gmcharlt are you on a Mac at the moment? |
| 10:59 |
Dyrcona |
needsrepatch or needswork work for me. |
| 10:59 |
kmlussier |
Didn't do it for me either |
| 10:59 |
gmcharlt |
jboyer-isl: Dyrcona: looks like the difference for me is running adblockplus |
| 10:59 |
gmcharlt |
*grumble* *grumble* |
| 10:59 |
jboyer-isl |
Ah. |
| 11:00 |
Dyrcona |
I used to run adblock, but didn't bother after the reinstallation last fall. |
| 11:00 |
gmcharlt |
anyway, I won't promulgate the poll link further, but I'll wait a bit for additional results, then this afternoon write something up for the dev mailing list |
| 11:01 |
|
ericar_ joined #evergreen |
| 11:07 |
jboyer-isl |
Does anyone know if oils_sql.c’s “Empty IN list” error is supposed to be “survivable?” For example, if you call open-ils.collections.user_balance_summary.generate and one of the patrons in collections has paid off all transactions, the summary dies when it hits Collections.pm line 865 (retrieving the balance of no transactions). I’ve fixed that by testing for the existence of values in the array, but if there’s |
| 11:07 |
jboyer-isl |
deeper down that should be fixed I’d like to look into that. |
| 11:09 |
jboyer-isl |
Though I suppose if everything dies when that happens now and empty in lists are suddenly tolerated there could be repercussions all over. |
| 11:10 |
Dyrcona |
jboyer-isl: I didn't look, but are you certain the error comes from the C code and not the database itself? |
| 11:12 |
berick |
it comes from the C |
| 11:12 |
jboyer-isl |
Yes, the string returned is from oils_sql.c line 2737. It doesn’t look like the sql makes it to the db in that case. |
| 11:12 |
berick |
IIRC, it results in a NULL response, which the caller is meant to treat as an error |
| 11:14 |
jboyer-isl |
So it is meant to be a drop it like it’s hot, this whole request is busted type of error then. That makes it easy on me. :) I’ll write up my LP bug and put up a branch shortly. |
| 11:18 |
jboyer-isl |
The reason I wasn’t certain is that the call in Collections.pm is made regardless of the number of transactions and immediately after the return value is checked for defined-ed-ness, so I thought at one time it may have worked as-is. |
| 11:20 |
berick |
it's possible that it could be recovered from, but the usual approach is to be sure the list in question is non-empty before using it in a query. |
| 11:21 |
jboyer-isl |
I prefer that anyway, fewer extra error log lines. |
| 11:21 |
berick |
yeah |
| 11:21 |
jboyer-isl |
thanks for the clarification. |
| 11:28 |
|
abowling left #evergreen |
| 11:36 |
|
mrpeters joined #evergreen |
| 11:38 |
|
dreuther joined #evergreen |
| 11:38 |
|
dreuther_ joined #evergreen |
| 11:39 |
csharp |
mobius++ |
| 11:52 |
bshum |
gmcharlt: "Tag tables" per OU sounds... intriguing :) |
| 11:53 |
goood |
Here's why we don't paper over an empty IN list by just removing the clause: imagine the query is asking for a small set of objects from a large table; if we just skip that because user input was empty you'll get the /whole/ table. |
| 11:53 |
|
dreuther___ joined #evergreen |
| 11:53 |
|
dreuther__ joined #evergreen |
| 11:56 |
|
dreuther____ joined #evergreen |
| 11:56 |
|
dreuther_____ joined #evergreen |
| 12:00 |
|
jihpringle joined #evergreen |
| 12:00 |
|
chick joined #evergreen |
| 12:00 |
|
dreuther joined #evergreen |
| 12:00 |
|
dreuther_ joined #evergreen |
| 12:04 |
jboyer-isl |
goood: makes sense. |
| 12:10 |
|
Newziky joined #evergreen |
| 12:14 |
gmcharlt |
bshum: I've pushed to the working branch a commit that outlines part of the DB schema; hopefully will give you an idea of where I'm going with the per-OU bit |
| 12:25 |
|
kitteh_ joined #evergreen |
| 12:29 |
kmlussier |
I'll be tracking Bug Squashing Day activity here - http://bit.ly/1EGhB4Q |
| 12:38 |
* bshum |
finds re-reading old bugs both interesting and sad |
| 12:48 |
|
krvmga_ joined #evergreen |
| 12:49 |
krvmga_ |
again, working on EG 2.7.3 install, getting SpiderMonkey error; ran Build installdeps; got SpiderMonkey error; paste is here |
| 12:49 |
krvmga_ |
http://paste.evergreen-ils.org/40 |
| 12:50 |
krvmga_ |
debian-wheezy, opensrf 2.4 |
| 12:50 |
bshum |
Hmm, https://bugs.launchpad.net/evergreen/+bug/1117658 is an oldie. We might be able to close that bug now that work on the web client is a real thing, no longer an "experiment"? |
| 12:50 |
pinesol_green |
Launchpad bug 1117658 in Evergreen "Experiment with more browser-based staff interfaces" (affected: 2, heat: 16) [Wishlist,Triaged] |
| 12:52 |
berick |
krvmga_: using makefile.install? |
| 12:52 |
krvmga_ |
berick: using these instructions: PATH=/openils/bin:$PATH ./configure --prefix=/openils --sysconfdir=/openils/conf |
| 12:52 |
krvmga_ |
make |
| 12:53 |
krvmga_ |
berick: i watched the make fail on SpiderMonkey and looked at the output messages; that's where the instruction to run Build installdeps was |
| 12:54 |
berick |
krvmga_: but you previously ran "make -f Open-ILS/src/extras/Makefile.install debian-wheezy" ? |
| 12:54 |
berick |
http://evergreen-ils.org/documentation/install/README_2_7.html#_installing_prerequisites |
| 12:54 |
krvmga_ |
berick: yes, i've been following the instructions step by step |
| 12:55 |
krvmga_ |
and i did that step |
| 12:55 |
berick |
something must have failed before your error message, then, because in your error, CPAN is trying to install spidermonky |
| 12:55 |
berick |
but we install spidermonkey manually in makefile.install |
| 12:56 |
krvmga_ |
will it hurt if i just run that command for Makefile.install again? |
| 12:56 |
berick |
no, it's fine to re-run makefile.install |
| 12:57 |
krvmga_ |
berick: thx. i'm off to a meeting right now. i'll be back later to let everyone know what happened. |
| 12:57 |
berick |
good luck |
| 13:01 |
bshum |
berick: I'm pulling this one back out of the woods, looks like you have a partial fix for https://bugs.launchpad.net/evergreen/+bug/1269865 proposed (and there's some old feedback there) |
| 13:01 |
pinesol_green |
Launchpad bug 1269865 in Evergreen 2.5 "ACQ user request can result in double (or quadruple) holds placement" (affected: 3, heat: 14) [Undecided,New] |
| 13:03 |
bshum |
From i18n land, https://bugs.launchpad.net/evergreen/+bug/1095280 makes me queasy :( |
| 13:03 |
pinesol_green |
Launchpad bug 1095280 in Evergreen "Build process doesn't get all translatable strings from templates" (affected: 1, heat: 6) [Undecided,Triaged] |
| 13:03 |
bshum |
I think to fix that we need to have more thought into defining a new PO? |
| 13:03 |
bshum |
For other template toolkit files |
| 13:04 |
|
sandbergja joined #evergreen |
| 13:06 |
bshum |
jihpringle: Hmm, this bug has been assigned to you, but unsure if you've had time to look at / test it: https://bugs.launchpad.net/evergreen/+bug/1380709 |
| 13:06 |
pinesol_green |
Launchpad bug 1380709 in Evergreen 2.8 "invoice print amounts-per-fund uses wrong value when item price varies" (affected: 1, heat: 8) [Undecided,New] |
| 13:07 |
jihpringle |
bshum: on my list to test today |
| 13:07 |
bshum |
Oh, cool :) |
| 13:07 |
bshum |
Hope you see good things on it. Thanks! |
| 13:09 |
yboston |
Is there a pinsol_green command to show a commit? |
| 13:09 |
bshum |
yboston: Only if the commit is in one of the master branches being tracked by pinesol_green's git module. |
| 13:10 |
bshum |
@git repolist |
| 13:10 |
pinesol_green |
bshum: evergreen (Evergreen, branch: master) |
| 13:10 |
pinesol_green |
bshum: opensrf (OpenSRF, branch: master) |
| 13:10 |
pinesol_green |
bshum: evergreen_website (Evergreen Website, branch: master) |
| 13:10 |
pinesol_green |
bshum: sipserver (SIPServer, branch: master) |
| 13:10 |
bshum |
So if it's a commit in master, opensrf, or sipserver |
| 13:10 |
yboston |
bshum: In this case I wanted to show a working commit, but would like to know the syntax for ones in EG master |
| 13:10 |
bshum |
Err, master of Evergreen, etc. |
| 13:11 |
bshum |
So, basically, if you give it a short snippet or the whole hash, it'll make a nice link for it. But only the master branches of those repos. It won't track specific trees I think, or working. |
| 13:11 |
bshum |
So like |
| 13:11 |
bshum |
6c52b6e |
| 13:11 |
pinesol_green |
[evergreen|Galen Charlton] LP#1155313: fix mangling of schema upgrade script name - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=6c52b6e> |
| 13:12 |
bshum |
That's all it takes for the bot to pick up and match the commit |
| 13:12 |
bshum |
But like |
| 13:12 |
bshum |
e600f9f |
| 13:12 |
pinesol_green |
[evergreen|Galen Charlton] LP#1155313: recalculate normalized labels during upgrade - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=e600f9f> |
| 13:12 |
bshum |
Oh, I guess that works too |
| 13:12 |
bshum |
:D |
| 13:12 |
bshum |
Okay, so it does match the branches. |
| 13:13 |
berick |
bshum: yeah, my branch for bug 1269865 would be a good easy win |
| 13:13 |
pinesol_green |
Launchpad bug 1269865 in Evergreen "ACQ user request can result in double (or quadruple) holds placement" (affected: 3, heat: 14) [Medium,Confirmed] https://launchpad.net/bugs/1269865 |
| 13:13 |
* bshum |
wonders now if we added the working repo as a repolist... but somehow taught it not to announce in channel when new commits went to master. |
| 13:14 |
berick |
it's only a partial resolution, as noted |
| 13:15 |
yboston |
thanks for the info |
| 13:15 |
yboston |
so here is my question |
| 13:16 |
yboston |
Kathy took a commit from bug 1406350 and resolved a merge conflict on her working branch |
| 13:16 |
pinesol_green |
Launchpad bug 1406350 in Evergreen "Mobile device navigation issue in OPAC Shelf Browser" (affected: 1, heat: 8) [Medium,Confirmed] https://launchpad.net/bugs/1406350 |
| 13:16 |
yboston |
The original code fix does away with the use of "<thead>" tags. The code behaves great, but just wanted to make sure there was objections to it |
| 13:16 |
yboston |
0f53eb85e5ad98d19874c304d55034c8b524158f |
| 13:16 |
yboston |
http://git.evergreen-ils.org/?p=working/Evergreen.git;a=commitdiff;h=0f53eb85e5ad98d19874c304d55034c8b524158f |
| 13:16 |
|
ericar_ joined #evergreen |
| 13:19 |
|
buzzy joined #evergreen |
| 13:26 |
csharp |
Dyrcona: looking at bug 638509 - it looks like your approach was originally tied in with the overall billing overhaul you were working on, but it looks to me like the fix could stand on its own - do you agree? |
| 13:26 |
pinesol_green |
Launchpad bug 638509 in Evergreen 2.4 "renewing lost items fails unintuitively" (affected: 7, heat: 34) [Medium,Confirmed] https://launchpad.net/bugs/638509 |
| 13:26 |
bshum |
Hmm, how should we deal with DB version upgrade bugs where those versions are no longer supported? |
| 13:27 |
bshum |
For example like |
| 13:27 |
bshum |
https://bugs.launchpad.net/evergreen/+bug/1205061 |
| 13:27 |
pinesol_green |
Launchpad bug 1205061 in Evergreen 2.4 "Need more "IF EXISTS" clauses in 2.3-2.4.0-upgrade-db.sql" (affected: 1, heat: 8) [Medium,Triaged] |
| 13:27 |
bshum |
Or https://bugs.launchpad.net/evergreen/+bug/883036 |
| 13:27 |
pinesol_green |
Launchpad bug 883036 in Evergreen "2.0-2.1-upgrade.sql script: insert or update on table "org_unit_setting_type" violates foreign key constraint "org_unit_setting_type_grp_fkey"" (affected: 6, heat: 28) [Low,Confirmed] |
| 13:27 |
csharp |
bshum: it's possible that someone out there needs to upgrade from unsupported versions |
| 13:27 |
bshum |
True enough. |
| 13:28 |
csharp |
(though God help 'em if theyre still on 2.0 :-)) |
| 13:28 |
Dyrcona |
csharp: That was part of a bigger group of four changes. It was one of the two changes that could stand on its own. |
| 13:29 |
csharp |
Dyrcona: I'm going to test it and sign off. That's something that has needed to be fixed for a long time |
| 13:29 |
* Dyrcona |
is surprised kmlussier never signed off on it, but it fell by the wayside behind other things. |
| 13:29 |
Dyrcona |
csharp++ |
| 13:29 |
kmlussier |
Dyrcona: There was still a bug in that one. |
| 13:29 |
Dyrcona |
There was? |
| 13:29 |
kmlussier |
I'll add a comment to the bug, because I think the question was raised here before. |
| 13:30 |
Dyrcona |
Best to put things in writing. I have too much going on and even then, I don't keep up with written stuff, either. |
| 13:31 |
kmlussier |
Dyrcona: It was related to new overdue fines being added when a site was using the setting to add new overdue fines a lost checkin. It's possible it might be resolved now that the changes were made to the fine generator. |
| 13:31 |
kmlussier |
I'll have to dig up my notes on it. |
| 13:31 |
Dyrcona |
Right. I don't think it was ever determined if that issue was necessarily related to these changes. |
| 13:31 |
bshum |
berick: For that acq dupe holds bug, what I'm going to do is split issue #1 away from the rest of that bug so that we can merge #2 and close it out against a specific milestone. We can tackle the #1 part better in the next go of things. |
| 13:32 |
bshum |
By split, I mean open a new bug to track that issue separately. |
| 13:33 |
kmlussier |
Looking at my notes, it looks like there were two remaining issues. I'll post it to the bug. |
| 13:41 |
csharp |
hmm - renewing worked as expected from my point of view - it moved it from the bottom to the top window |
| 13:41 |
csharp |
well, actually, I didn't see the override popups, but I'm logged in as admin |
| 13:43 |
kmlussier |
csharp: https://bugs.launchpad.net/evergreen/+bug/638509/comments/12 |
| 13:43 |
pinesol_green |
Launchpad bug 638509 in Evergreen 2.4 "renewing lost items fails unintuitively" (affected: 7, heat: 34) [Medium,Confirmed] |
| 13:43 |
kmlussier |
Those were the two remaining issues I had found with that branch. |
| 13:46 |
csharp |
actually, what I'm seeing is: Mark Item Lost, reload patron account, Renew lost item and nothing happens - no popups or reload that shows the action succeeding, but when I manually reload, the previously lost item is back in the top window with a new due date |
| 13:46 |
csharp |
is that what's expected? |
| 13:49 |
kmlussier |
csharp: Yes, my recollection is that is how it worked. But it's been a few months since I looked at it. |
| 13:49 |
csharp |
ok |
| 13:49 |
kmlussier |
I do know you need a permission to do it. |
| 13:49 |
csharp |
I see, so I would be stopped if I were a circ staff without that perm |
| 13:50 |
Dyrcona |
Meh. Billing's a mess. Should be refactored. All we need really are a handful of functions in a single file instead of dozens scattered over several. |
| 13:51 |
Dyrcona |
Circulation, too, though instead of one giant hairball, it should be split up. |
| 13:51 |
* csharp |
likes the name "Michael Ramon Barber" |
| 13:51 |
csharp |
(one of the generated staff users in the sample dataset) |
| 13:52 |
csharp |
also "Mary Townsend, Jr." |
| 13:53 |
kmlussier |
csharp: I think you need the COPY_STATUS_LOST override permission to renew lost items and the COPY_CLAIMS_RETURNED override permission to do the same for claims returned items |
| 13:56 |
kmlussier |
Looks like Evergreen won't be participating in GSoC this year. But many thanks to bshum, dbs, and Dyrcona for setting up to volunteer as mentors! |
| 13:57 |
berick |
thanks bshum |
| 13:57 |
bshum |
kmlussier: I'm going to check #gsoc during the meeting later to find out what we need to do better with. |
| 13:57 |
kmlussier |
bshum: I'm guessing it would help if we had more projects. :) |
| 13:58 |
kmlussier |
bshum: But thanks for doing that! It would be helpful to hear what they say. |
| 13:58 |
bshum |
kmlussier: Yeah, probably, but I'll still find out what I can. |
| 14:04 |
dbs |
alas :/ |
| 14:25 |
|
mllewellyn joined #evergreen |
| 14:26 |
|
chick left #evergreen |
| 14:30 |
Dyrcona |
Speaking of bills. I can't make heads or tails out of the interface. |
| 14:30 |
Dyrcona |
I'm looking into an "in-house use" card that has 951 bills. |
| 14:30 |
Dyrcona |
They actually all load for me. |
| 14:31 |
bshum |
They load better in Linux than Windows. (go figure?) |
| 14:39 |
Stompro |
LP#754899 , can someone give me a pointer on how to set preview values for the receipt template macros? It's marked as bitesize so it must be reasonably easy.. right? |
| 14:40 |
Stompro |
bug 754899 |
| 14:40 |
pinesol_green |
Launchpad bug 754899 in Evergreen "receipt template editor preview busted for most templates" (affected: 3, heat: 16) [Low,Confirmed] https://launchpad.net/bugs/754899 |
| 14:44 |
jboyer-isl |
Stompro: The preview data dictionaries are in Open-ILS/xul/staff_client/server/circ/print_list_template_editor.js Then, print_list_template_editor.xul will need to reference the new/corrected data. |
| 14:44 |
Stompro |
jboyer-isl thank you very much. |
| 14:47 |
|
ericar_ joined #evergreen |
| 14:52 |
Dyrcona |
@hate billing even MOAR! |
| 14:52 |
pinesol_green |
Dyrcona: The operation succeeded. Dyrcona hates billing even MOAR!. |
| 14:57 |
kmlussier |
@whocares billing |
| 14:57 |
pinesol_green |
kmlussier: I can't find anyone who loves or hates billing. |
| 14:57 |
jboyer-isl |
So, talk of release notes for bug fixes (not tied to a new feature) came up some time ago, should we have a Fixes directory under docs/RELEASE_NOTES_NEXT ? |
| 14:58 |
jboyer-isl |
kmlussier, do you remember if there was ever any consensus on that? |
| 15:00 |
Dyrcona |
I recall the consensus being not now, maybe later, let's discuss it. |
| 15:00 |
Dyrcona |
Since I brought the question up.... |
| 15:00 |
kmlussier |
jboyer-isl: I don't think there was anyone against the idea. I don't know if it's a case where people need to create separate release notes entry as they do with new features or if it's something the release maintainers/DIG people can pull from change logs. |
| 15:02 |
jboyer-isl |
I wondered if most of them would be “X didn’t work/crashed before, now works as expected” which does make a most of them redundant. |
| 15:02 |
* Dyrcona |
wonders at the best way to clear bills from a patron for items that are no longer checked out to that patron, when said patron is not a real patron, but the children's room. |
| 15:02 |
Dyrcona |
@hate billing |
| 15:02 |
pinesol_green |
Dyrcona: The operation succeeded. Dyrcona hates billing. |
| 15:02 |
Dyrcona |
:) |
| 15:02 |
jboyer-isl |
Dyrcona: several scary DELETE FROM statements, I suspect. |
| 15:02 |
bshum |
Given that by the time a major series is cut, the RM would have likely reorganized content into an actual RELEASE_NOTES_2_x file, my recommendation is that we have DIG, etc. work off the main file instead of having more notes added in the block that need compiling each maintenance release. |
| 15:04 |
kmlussier |
Yes, I do agree with bshum that we it probably would be easiest to work on the existing RELEASE_NOTES_2_x file. Which means we would be working off the Change Log. |
| 15:04 |
jboyer-isl |
Sounds good to me. |
| 15:04 |
kmlussier |
I think the key is that the commit messages contain useful information. |
| 15:04 |
bshum |
With new features being merged all at different times, having the single file in flux is harder than the bug fixes that get added to the main file that's already compiled. |
| 15:04 |
Dyrcona |
jboyer-isl: combined with an update to set xact_finish. |
| 15:04 |
jboyer-isl |
Just wanted to make sure I had relnotes this time, if needed. |
| 15:04 |
Dyrcona |
Maybe something in Perl is called for..... |
| 15:05 |
jboyer-isl |
Dyrcona: yes, don’t want to forget that one. We’ve seen some instances where someone got ahead of themselves and we had 600+ transactions finished with no payments. That’s an interesting display in the client. |
| 15:06 |
Dyrcona |
Crazy thing is it looks like the patron is due for a $1,240 refund, with a current negative balance of $96.89. |
| 15:07 |
Dyrcona |
I don't know how to read that interface though. |
| 15:07 |
Dyrcona |
With this many bills it just looks all kinds of fubar. |
| 15:16 |
|
dreuther__ joined #evergreen |
| 15:16 |
|
dreuther___ joined #evergreen |
| 15:20 |
|
dreuther_ joined #evergreen |
| 15:20 |
|
dreuther joined #evergreen |
| 15:42 |
jboyer-isl |
Since it is bug cleanup day, someone with Teh Powerz might want to merge 990066 and 1394989. The eldest hasn’t been touched in some time, while the newer is nearly complete from the sound of the comments. |
| 15:43 |
|
ericar_ joined #evergreen |
| 16:10 |
|
julialima_ left #evergreen |
| 16:21 |
Dyrcona |
Does this ring a bell with anybody? |
| 16:21 |
Dyrcona |
Hold was not successfully placed Problem: The item's circulation library does not fulfill holds |
| 16:24 |
Dyrcona |
Ah. Think I found it, not sure though. |
| 16:33 |
pinesol_green |
[evergreen|Mike Rylander] LP#1287791: Restrict authority browse to controlled subfields - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=74ddf23> |
| 17:03 |
pinesol_green |
[evergreen|Bill Erickson] LP#1205072 A/T granularity UI sane default, honors case - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=54f7dba> |
| 17:03 |
pinesol_green |
[evergreen|Bill Erickson] LP#1205072 A/T granularity upgrade notes - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=2f1754a> |
| 17:03 |
pinesol_green |
[evergreen|Josh Stompro] LP#1205072 - Assorted fixes for action trigger granularity settings - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=e0d9c5c> |
| 17:03 |
pinesol_green |
[evergreen|Remington Steed] LP#1205072: Correct and clarify the upgrade notes - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=9ccc056> |
| 17:11 |
|
mmorgan left #evergreen |
| 17:17 |
|
dcook joined #evergreen |
| 18:28 |
|
wlayton joined #evergreen |
| 19:06 |
|
akilsdonk joined #evergreen |
| 20:29 |
|
akilsdonk joined #evergreen |
| 20:37 |
|
artunit joined #evergreen |
| 20:55 |
|
dcook joined #evergreen |
| 21:28 |
pinesol_green |
[evergreen|Adam Bowling] LP #1406350 Mobile Device Navigation Issue Fix for Shelf Browser - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=d364097> |
| 21:28 |
bshum |
Doing a clean sweep on things that were signed off. Thanks everyone. |
| 21:34 |
pinesol_green |
[evergreen|Bill Erickson] LP#1287370: allow AutoGrid to persist filter state and page offset - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=39fb207> |
| 21:34 |
pinesol_green |
[evergreen|Bill Erickson] LP#1287370: apply filter/offset persistence to the fund search page - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=05fd625> |
| 21:34 |
pinesol_green |
[evergreen|Galen Charlton] LP#1287370: minor textual cleanup - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=06ca57f> |
| 22:02 |
|
AnxiousGarlic joined #evergreen |
| 22:03 |
|
AnxiousGarlic left #evergreen |
| 22:23 |
|
bbqben joined #evergreen |
| 22:24 |
|
wlayton joined #evergreen |
| 23:05 |
|
mglass joined #evergreen |
| 23:05 |
|
chatley_ joined #evergreen |
| 23:08 |
|
dreuther joined #evergreen |
| 23:08 |
|
dreuther_ joined #evergreen |
| 23:15 |
|
chatley joined #evergreen |
| 23:15 |
|
dreuther joined #evergreen |
| 23:15 |
|
dreuther_ joined #evergreen |
| 23:15 |
|
mglass joined #evergreen |
