| Time |
Nick |
Message |
| 02:58 |
* dbs |
going a bit nuts trying to use Acq; funds show up in Batch Update fund picker scoped to our OU, but won't show up in the line item details fund picker when I try to add a copy. |
| 03:00 |
dbs |
http://i.imgur.com/tqfTD4Q.png?1 |
| 03:01 |
* dbs |
wonders if maybe everyone using acquisitions is using funds at the Consortium level |
| 03:11 |
dbs |
If I create a purchase order from the selection list, however, then I can select the Fund at the individual copy level |
| 03:11 |
dbs |
which makes me think that the selector isn't expected to actually select the fund. hmm. |
| 03:15 |
dbs |
Interesting. So in our workflow, the selectors generally say what they want to order, and what fund to apply that order to, but the acq people figure out the provider (Amazon, B&T, whatever) |
| 03:17 |
dbs |
Looks like you have to choose the provider when you create the PO, then you can choose the fund, but that's the opposite of our workflow. |
| 03:17 |
dbs |
And looks like there's no way to change the provider after the PO is created but before it is activated. |
| 03:19 |
dbs |
I guesss for Coutts at least we can try to make Load MARC Order Records work; then focus on the one-offs for the non-Coutts orders |
| 03:19 |
dbs |
Should be a fun session with our acq people tomorrow |
| 07:17 |
csharp |
dbs: yeah - the OU scoping for different acq things is confusing to our libraries too |
| 07:18 |
csharp |
the funds are owned by individual branches, but the orders are all placed at the system level (iirc) and that creates confusion for everyone (including vendors) |
| 07:25 |
|
graced joined #evergreen |
| 07:36 |
|
jboyer-isl joined #evergreen |
| 07:56 |
|
collum joined #evergreen |
| 08:11 |
|
akilsdonk joined #evergreen |
| 08:15 |
|
ericar joined #evergreen |
| 08:19 |
|
mrpeters joined #evergreen |
| 08:33 |
|
Shae joined #evergreen |
| 08:33 |
dbs |
sitka++ # http://docs.sitka.bclibraries.ca/Acq/current/pdf/Sitka_Acquisitions_Manual.pdf - some pretty thorough docs there |
| 08:35 |
dbs |
One of the main things that was really confusing me was the presence of the Fund field on the Selection List - copies line, even though you can't do anything with it. |
| 08:37 |
csharp |
dbs: we have a part-time person here who has been diving deep into acq... if you're interested in connecting with her, please let me know |
| 08:38 |
|
mmorgan1 joined #evergreen |
| 08:39 |
dbs |
thanks csharp! |
| 08:39 |
|
mmorgan1 left #evergreen |
| 08:40 |
dbs |
I went over acq admin with our admin people last week, am introducing ordering to our technicians this morning |
| 08:40 |
csharp |
cool |
| 08:40 |
csharp |
I'll be interested in how it all goes |
| 08:40 |
dbs |
Bar should be low: make ordering less painful than updating a big old spreadsheet + local fields in each MARC record along with the actual provider site |
| 08:40 |
dbs |
we'll see. |
| 08:40 |
csharp |
we're piloting one (maybe two) libraries for acquisitions in the coming months |
| 08:42 |
csharp |
the biggest headache I've had to deal with is EDI setup (and specifically FTP) because when it fails there's not a straightforward way to re-do things |
| 08:42 |
csharp |
and of course, the Ruby bits |
| 08:45 |
dbs |
no plans for EDI here in the near future. Loading MARC Order Records is likely though. |
| 08:45 |
csharp |
that has been an adventure for us too, having little practical vandelay experience |
| 08:46 |
bshum |
Better than it used to be anyways ;) |
| 08:47 |
bshum |
Unrelated, I didn't get to cutting a new maintenance release of 2.7 yesterday by the calendar. The day ended up a bit more exciting in other areas. |
| 08:48 |
bshum |
Hoping to take a look at pulling a few fixes in before the next cut. |
| 08:49 |
bshum |
I'll likely aim to put together a 2.7.3 this evening. |
| 08:49 |
bshum |
So fix, fix away |
| 08:51 |
dbs |
highly critical fixes like <table> <table> ? :) |
| 08:52 |
bshum |
dbs: super important! :D |
| 08:54 |
|
jwoodard joined #evergreen |
| 08:55 |
* csharp |
only sees 4 new commits in rel_2_7, one of which he's already applied to 2.7.2 |
| 08:56 |
|
julialima_ joined #evergreen |
| 08:56 |
bshum |
csharp: Like I said, need to merge more stuff. |
| 08:56 |
csharp |
ah, gotcha |
| 08:57 |
bshum |
If you look at the actual milestone, there's a lot of targeted bugs. I need to go through them all and decide if they continue to remain targeted, push fixes, or leave for next milestone. |
| 08:58 |
bshum |
https://launchpad.net/evergreen/+milestone/2.7.3 |
| 08:58 |
bshum |
And that's not including any wildcards that have yet to be targeted for backports |
| 08:59 |
|
mmorgan joined #evergreen |
| 09:00 |
* csharp |
agrees with berick: https://bugs.launchpad.net/evergreen/+bug/1386347/comments/13 |
| 09:00 |
pinesol_green |
Launchpad bug 1386347 in Evergreen 2.6 "Speed up hold copy map deletion for clear shelf process, etc." (affected: 1, heat: 6) [Undecided,New] |
| 09:05 |
csharp |
dbs: or eeevil: for bug 1206936, does the suggested change in comment #7 supercede my "use window functions" branch and solve the original problem? |
| 09:05 |
pinesol_green |
Launchpad bug 1206936 in Evergreen "money.transaction_billing_summary view displays incorrect billing_type and billing_note for the actual last transaction" (affected: 1, heat: 6) [High,Triaged] https://launchpad.net/bugs/1206936 |
| 09:05 |
* csharp |
hasn't tested, jsyk |
| 09:07 |
tsbere |
jeff: Regarding differences in default notification formats: TPac (pipe, prefers email, then phone, then sms) vs old JSPac entries (dunno) vs Patron Editor (colon, prefers phone, then email, then sms) |
| 09:10 |
jeff |
tsbere: thanks. i had suspected as such, and started to compare new/old patron editors vs tpac -- thought i saw in tpac that it was colon-delimited, just with a different order. guess i'll have to re-look. |
| 09:14 |
bshum |
csharp: On bug 1386347, I was leaning towards removing the milestone from that, since nobody seems to be championing it for backport presently. |
| 09:14 |
pinesol_green |
Launchpad bug 1386347 in Evergreen 2.6 "Speed up hold copy map deletion for clear shelf process, etc." (affected: 1, heat: 6) [Undecided,New] https://launchpad.net/bugs/1386347 |
| 09:14 |
csharp |
bshum: +1 |
| 09:21 |
|
Dyrcona joined #evergreen |
| 09:23 |
Dyrcona |
Well the first commit on the collab branch has been running in production since about 8:00 pm last night. |
| 09:24 |
Dyrcona |
If anyone else wants to jump in, just say what service you're looking at. |
| 09:28 |
jboyer-isl |
I had a question about the various services. Is the intention for there to always be pcrud and cstore (and qstore? I don't know what uses that off hand) or is this the middle of a transition where pcrud is old and broken and cstore is the new hotness? |
| 09:30 |
tsbere |
jboyer-isl: As I understand it, cstore is "backend, no auth needed" and pcrud is "frontend, auth needed". rstore is a reporting(?) version of cstore. qstore is unrelated. |
| 09:31 |
jboyer-isl |
ok, so likely they're all going to be around long-term. Thanks tsbere. |
| 09:32 |
|
maryj joined #evergreen |
| 09:41 |
|
yboston joined #evergreen |
| 09:45 |
dbs |
csharp: we're using the #7 recommendation in production here |
| 09:46 |
csharp |
dbs: excellent - thanks |
| 09:49 |
dbs |
I guess we should really go ahead and create a whole new set of views that way |
| 09:50 |
dbs |
jboyer-isl: on qstore: https://bugs.launchpad.net/evergreen/+bug/1077212 |
| 09:50 |
pinesol_green |
Launchpad bug 1077212 in Evergreen "add qstore to eg_db_config.pl --update-config list" (affected: 1, heat: 6) [Undecided,Incomplete] |
| 09:51 |
dbs |
(the discussion goes decidedly in a different direction from the bug title) |
| 09:51 |
bshum |
I thought qstore was dead? |
| 09:51 |
bshum |
I guess I already thought we started ripping it out. But I guess maybe I was wrong on that. |
| 09:52 |
tsbere |
Wait, was it ever in use to begin with? |
| 09:52 |
dbs |
was never in use in Evergreen |
| 09:53 |
dbs |
It's just an extra attack vector / resource consumer if turned on. Kind of like an appendix. |
| 09:54 |
bshum |
Right, it's not an activeapp anymore right? |
| 09:54 |
bshum |
Or ever |
| 09:54 |
bshum |
I guess |
| 09:55 |
bshum |
Oh, I see, I'm mixing it up with the ingest thing that we also yanked out. Nevermind, my confusion has ended. :( |
| 09:55 |
|
BigRig joined #evergreen |
| 09:56 |
jeff |
heh |
| 09:59 |
jboyer-isl |
It appears my confusion on the qstore front is because it's still in opensrf.xml, but it's not in any of the service lists in opensrf_core.xml. So it's not on, but it's not really gone, either. |
| 10:01 |
Dyrcona |
jboyer-isl: AFAIK, nothing at all uses qstore. |
| 10:02 |
Dyrcona |
The code code be removed, but no one has bothered. |
| 10:02 |
Dyrcona |
If you have it still configured to start, you should turn it off. |
| 10:03 |
Dyrcona |
And I should have read what everyone else said before replying. |
| 10:04 |
Dyrcona |
Too bad we can't set a bug's status to deprecated.... I'd be inclined to set that bug to invalid and create a new one to rip qstore out. |
| 10:05 |
bshum |
"won't fix" |
| 10:05 |
bshum |
i.e. not in project plans |
| 10:05 |
jboyer-isl |
Invalid + new bug sounds like a fine plan to me. Maybe a comment could be dropped in the bug before it's closed for software archaeologists. |
| 10:06 |
jboyer-isl |
O, what bshum said. :) |
| 10:08 |
Dyrcona |
Yeah, +1 to won't fix. |
| 10:09 |
Dyrcona |
I'll do it later and file a bug for ripping out qstore, but I've got some other things I should do, first. |
| 10:19 |
* eeevil |
would hate to see qstore go away ... it's meant to support batch operations. but if it gets ripped out, it should be done in one fell swoop (please), so the commit can be reverted if it's needed later |
| 10:22 |
Dyrcona |
Hmm. Then maybe we should make use of qstore for batch operations instead of what we do now? |
| 10:22 |
|
rjackson-isl joined #evergreen |
| 10:22 |
Dyrcona |
Would it be efficient enough to stop timeouts when doing things from large copy and bib buckets? |
| 10:35 |
Dyrcona |
Grr. GoogleDrive/Docs/whatever-they-call-it-this-month is interfering the behavior of select and middle click in X. |
| 10:36 |
Dyrcona |
I select something in the document, and middle click in another document and it does not paste what I selected. |
| 10:39 |
|
mllewellyn joined #evergreen |
| 10:41 |
eeevil |
Dyrcona: I noticed the selection change in gdocs too... I had to start ctl-c'ing , which is dumb |
| 10:42 |
Dyrcona |
Yep. |
| 10:43 |
eeevil |
and, re qstore, it's just part of the puzzle, but yes. the idea was to let it manage batch change setup and supply completion state information for a polling UI to refresh regularly. it also has a "remember old state" feature, IIRC, so you can say "hey, that named changeset that I ran a month ago to move copies to another branch? yeah, undo that now." |
| 10:46 |
* eeevil |
looks under the couch cushions for tuits |
| 10:47 |
Dyrcona |
eeevil: That sounds pretty cool. We already set a table up to store temporary copy changes, like moving stuff to/from Summer Reading copy locs and so on. |
| 11:03 |
csharp |
since upgrading, we are no longer able to place "unfillable holds" - it gets to the screen where it says " You have permission to override some of the failed holds. Click Submit to override and place your hold on the selected items.", but clicking submit returns us to the bib record page with no further information |
| 11:03 |
csharp |
we can't seem to track what that "submit" button is supposed to be doing |
| 11:03 |
csharp |
we're on 2.7.2 |
| 11:05 |
mmorgan |
Hmm. Haven't heard that from our libraries - and I think we would have if it were a problem here. |
| 11:06 |
csharp |
nevermind - it was a local commit that was keeping it from working |
| 11:16 |
eeevil |
csharp: was it something others might run into? |
| 11:44 |
kmlussier |
It's odd. I've never come across the problem where some users can't log into webby using Firefox, but I still hear reports of it from our users. |
| 11:45 |
kmlussier |
I thought I might run into it when I switched to a new laptop. |
| 11:49 |
|
nhilton joined #evergreen |
| 11:52 |
eeevil |
kmlussier: could it be noscript or the like, or an old version? |
| 11:53 |
kmlussier |
The person who reported it said she was using Firefox 35. She enters the login information, but it just sits there. |
| 11:53 |
kmlussier |
I know it was a known problem at one point. |
| 11:54 |
bshum |
kmlussier: Is it a websocket problem maybe |
| 11:54 |
bshum |
Like the ports aren't open on their end |
| 11:54 |
* bshum |
is not sure how far gmcharlt has gotten with websocket configuration on webby or elsewhere |
| 11:56 |
bshum |
kmlussier: If they open their web console |
| 11:56 |
bshum |
They can check for errors |
| 11:57 |
bshum |
Ignoring of course the check for 8443/hatch |
| 11:57 |
bshum |
But if they were getting blocked on the websocket port, it might show up there as an unresponsive, or failure to connect |
| 11:59 |
tsbere |
eeevil++ # Pointing out space delimination in the WWW::Proxy modules and causing me to notice I had missed a bug in the version of my code I had pushed to working |
| 11:59 |
eeevil |
tsbere++ # fixin' stuffs |
| 11:59 |
eeevil |
and that auth module looks good |
| 12:00 |
kmlussier |
bshum: If it were an issue where the port is blocked, wouldn't they have come across it in Chrome too? |
| 12:01 |
tsbere |
eeevil: Tis a combination of "basic auth that only accepts usernames is bad for patron access" and "WWW::Proxy::Authen may be broken in newer versions of Apache due to them changing the API a bit, so I needed to figure out how to do things differently" |
| 12:02 |
|
graced joined #evergreen |
| 12:04 |
bshum |
kmlussier: Probably right. |
| 12:04 |
bshum |
Maybe their firefox is configured differently. |
| 12:05 |
tsbere |
uneducated user of adblock or noscript? |
| 12:07 |
kmlussier |
berick: I was talking to some folks at NOBLE yesterday, and they have some minor catalog customizations we were thinking would be nice additions to the core code |
| 12:08 |
kmlussier |
berick: I know we're passed the milestone targeting deadline, but if they created the LP bugs now, would they still have a chance of making it into 2.8? |
| 12:08 |
kmlussier |
I was planning to work with them next week to get the code into a git branch. |
| 12:08 |
berick |
kmlussier: yes, that's fine. |
| 12:09 |
kmlussier |
berick: Thanks! I'll let them know. |
| 12:21 |
|
nhilton_ joined #evergreen |
| 12:25 |
|
sandbergja joined #evergreen |
| 12:29 |
|
jihpringle joined #evergreen |
| 12:37 |
|
buzzy joined #evergreen |
| 12:54 |
csharp |
eeevil: nope - it happened because we commented out the code for the checkbox in place_hold_result.tt2 |
| 12:54 |
csharp |
@who would be fool enough to do that? |
| 12:54 |
pinesol_green |
dbwells would be fool enough to do that. |
| 12:55 |
dbwells |
sounds about right |
| 12:55 |
csharp |
heh |
| 12:58 |
|
nhilton__ joined #evergreen |
| 13:18 |
phasefx_ |
hrmm, just noticed the live tester has been broken since the 12th.. skeletal output |
| 13:22 |
Dyrcona |
Just thought I'd follow up on yesterday's conversation about CStoreEditor. |
| 13:22 |
Dyrcona |
I loaded a branch on my development vm that has the CStoreEditor DESTROY method issue a warning. |
| 13:23 |
Dyrcona |
I then did some stuff, like run action_trigger_runner. |
| 13:25 |
Dyrcona |
The destructor is getting called. |
| 13:25 |
Dyrcona |
So, theoretically, CStoreEditor should not really be causing issues. |
| 13:29 |
|
nhilton joined #evergreen |
| 13:43 |
|
b_bonner joined #evergreen |
| 13:44 |
|
mnsri_away joined #evergreen |
| 13:44 |
|
rashma joined #evergreen |
| 13:51 |
dbs |
so much for removing timeout=60 from the SIP config. now the self-check randomly hangs while accessing patron records |
| 13:51 |
* dbs |
is going to roll back to a 2009-era version of SIPServer |
| 13:51 |
bshum |
:( |
| 13:53 |
csharp |
dbs: that's what we did pre-emptively after hearing about some of your trouble |
| 13:54 |
* csharp |
*cough* we need SIPServer versioned releases *cough* *cough* |
| 13:59 |
bshum |
@gitrehash |
| 13:59 |
pinesol_green |
bshum: The operation succeeded. |
| 14:00 |
bshum |
@git repolist |
| 14:00 |
pinesol_green |
bshum: evergreen (Evergreen, branch: master) |
| 14:00 |
pinesol_green |
bshum: opensrf (OpenSRF, branch: master) |
| 14:00 |
pinesol_green |
bshum: evergreen_website (Evergreen Website, branch: master) |
| 14:00 |
pinesol_green |
bshum: sipserver (SIPServer, branch: master) |
| 14:00 |
bshum |
And now we have SIPServer :) |
| 14:00 |
bshum |
So that I can do something like cd4551366fba4c30ad434b0c58432f2d6ff081cc |
| 14:00 |
pinesol_green |
[sipserver|Thomas Berezansky] LP#1227273: Clear account info at start and end of connection - <http://git.evergreen-ils.org/?p=SIPServer.git;a=commit;h=cd45513> |
| 14:01 |
bshum |
That's the last commit our SIPServer is up to running apparently. |
| 14:01 |
bshum |
It was before the timeout stuff and the multiplex stuff |
| 14:25 |
pinesol_green |
Incoming from qatests: Test Success - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 14:46 |
Stompro |
Is creating read only postgres access really as difficult as it seems to be? Needing to run a command for every schema individually? |
| 14:50 |
bshum |
Stompro: I believe that's how we had to do it in the past. |
| 14:50 |
bshum |
And actually I think we even went further and specified it table by table in some cases. |
| 14:51 |
bshum |
So we had to grant usage for the schemas |
| 14:51 |
bshum |
And then grant select on each table |
| 14:51 |
|
krvmga joined #evergreen |
| 14:52 |
bshum |
But it's been awhile since we toyed with that whole thing. Awhile, meaning, that's the way we rolled back in PG 8.3 days |
| 14:53 |
|
nhilton_ joined #evergreen |
| 14:53 |
jeffdavis |
Stompro: http://pastebin.com/aGqNKUYU <- you can "automate" the grant usage/grant select commands |
| 14:54 |
bshum |
jeffdavis++ |
| 14:54 |
Stompro |
Thanks Jeff, jeffdavis++ |
| 14:55 |
jeffdavis |
You may wish to adjust the WHERE clauses if there are other tables you don't want your read-only user to have access to, of course. |
| 14:58 |
kmlussier |
dbwells: We loaded collab/dbwells/1198465_cstore_fines_gen in our dev environment (we being Dyrcona). However, we're getting the following when starting up the client: Method [open-ils.circ.circ_modifier.retrieve.all] not found for OpenILS::Application::Circ |
| 14:58 |
jeffdavis |
Oh, and to be clear that just outputs the commands that you need to run, it doesn't actually run them. You can put the output in a script and run that. |
| 15:04 |
collum |
Stompro: here's a quick way to find out what schema.tables a user has the 'select' privilege on. http://pastebin.com/PmSKmM7k Just change 'username' in the script to the user. |
| 15:05 |
jeff |
kmlussier: first thing I check in that scenario is for syntax errors in OpenILS/Application/Circ.pm |
| 15:07 |
Dyrcona |
jeff: We did that, and if there were syntax errors that bublle up to Circ.pm, circ would not start. |
| 15:07 |
Dyrcona |
open-ils.circ started. |
| 15:07 |
jeff |
got it. |
| 15:16 |
Stompro |
collum++ thanks for code. |
| 15:24 |
kmlussier |
bshum: For bug 1078593, I actually have been meaning to take a look at that again and probably sign off on it. |
| 15:24 |
pinesol_green |
Launchpad bug 1078593 in Evergreen "serials: deleting an issuance does not update the basic summary statement" (affected: 4, heat: 22) [Medium,In progress] https://launchpad.net/bugs/1078593 - Assigned to Dan Wells (dbw2) |
| 15:25 |
bshum |
kmlussier: Sure, whatever you guys decide :) I was just moving it out of my way on 2.7.3 work |
| 15:25 |
kmlussier |
So I could make a comment on the bug saying just that and assign it to myself. :) |
| 15:25 |
bshum |
If it is actually ready, we can always add it in there before I cut. |
| 15:25 |
kmlussier |
You're cutting today? |
| 15:26 |
bshum |
I was hoping to cut this evening, but can wait a bit if needed. |
| 15:26 |
bshum |
We're already a day behind the scheduled date, but that hasn't stopped us before :\ |
| 15:28 |
kmlussier |
bshum: It shouldn't take me long to look at it again. The problem is all of the other stuff I have on my plate today. |
| 15:30 |
kmlussier |
But if you wait until tomorrow, I can also look at that Lost and Paid bug too. |
| 15:31 |
Dyrcona |
kmlussier: I've loaded the branch on my dev system already, so feel free to toggle settings on there if you want. |
| 15:31 |
dbwells |
kmlussier: rats, sorry. Probably a merge error I made of some kind when getting it into the branch. I loaded the branch earlier on my test box, but haven't gotten back to it yet. I'll get it fixed. |
| 15:31 |
Dyrcona |
The lost and paid fix branch, that is. |
| 15:31 |
kmlussier |
dbwells++ Great, thanks! |
| 15:32 |
bshum |
kmlussier: That's fine, I can wait to cut tomorrow. |
| 15:32 |
pinesol_green |
[evergreen|Chris Sharp] LP#1310619: Add links in reporter.classic_item_list to legacy_cat1 and legacy_cat2 views. - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=9b2ec17> |
| 15:32 |
pinesol_green |
[evergreen|Chris Sharp] LP#1310619: Changing relationship between rcil and legacy stat cats to "might_have". - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=4ffe7d6> |
| 15:32 |
bshum |
That'll give me more time to slack off, err...... I mean review and commit more fixes. |
| 15:32 |
bshum |
:D |
| 15:33 |
Dyrcona |
heh |
| 15:34 |
kmlussier |
For some reason, the words "slack off" don't come to mind when I think of bshum. |
| 15:34 |
|
akilsdonk joined #evergreen |
| 15:34 |
Dyrcona |
bshum: Do you want me to back port lp 1398926 to 2.7 when I push it? |
| 15:34 |
pinesol_green |
Launchpad bug 1398926 in Evergreen "Symbol Overlay only works on pre-existing entry fields" (affected: 1, heat: 6) [Medium,Confirmed] https://launchpad.net/bugs/1398926 |
| 15:35 |
bshum |
Dyrcona: Sure, I don't see why not. |
| 15:35 |
Dyrcona |
It could probably go to 2.6 also. |
| 15:35 |
bshum |
Do me a favor though and edit the commit message to include the LP# |
| 15:35 |
Dyrcona |
OK. I'll do that. |
| 15:35 |
bshum |
Thanks :) |
| 15:35 |
Dyrcona |
I think he made the branch before the LP bug. |
| 15:36 |
pinesol_green |
[evergreen|Josh Stompro] LP 1373197: fixed default "Get Help With Evergreen" link. - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=05f86c8> |
| 15:36 |
pinesol_green |
[evergreen|Josh Stompro] LP 1372197: Fixed another link to evergreen-ils.org that changed. - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=3a5aa33> |
| 15:37 |
bshum |
Dyrcona: Yeah that's no problem. I just like to try including the LP# in the commit for tracking purposes now. |
| 15:38 |
bshum |
It has been surprisingly useful when learning more about a given changeset. |
| 15:38 |
Dyrcona |
Any particular format? |
| 15:38 |
jeff |
heh |
| 15:39 |
* jeff |
is partial to "LP#number Commit short msg here" |
| 15:40 |
Dyrcona |
Yep, that's what I did, since most commits follow that pattern. |
| 15:40 |
jeff |
but that might just be because most of my terminals select the digits and not the LP# when i double-click the digits. |
| 15:40 |
bshum |
What jeff said works. Sometimes people do LP#number: (with a colon at the end) |
| 15:40 |
pinesol_green |
[evergreen|Thomas Berezansky] LP#1398926: Allow symbol popup to trigger on new marc fields - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=8196546> |
| 15:40 |
Dyrcona |
I added the colon. |
| 15:40 |
jeff |
and a trailing colon wastes a precious character :-) |
| 15:40 |
Dyrcona |
Well, there, you can see. |
| 15:40 |
jeff |
heh |
| 15:40 |
Dyrcona |
A trailing colon sounds painful. |
| 15:41 |
bshum |
Damn, missed the # in the previous commits |
| 15:41 |
jeff |
but not as many wasted characters as LP#number - Commit description here |
| 15:41 |
bshum |
I need to finish poking at the ilbot config |
| 15:43 |
Dyrcona |
I need to test phasefx_'s marc_export changes. Probably won't get to it today. |
| 15:44 |
Dyrcona |
They won't go into 2.7 anyway. |
| 15:48 |
pinesol_green |
[evergreen|Bill Erickson] LP#1407171 Avoid DEFLATEing fm_IDL.xml - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=112b270> |
| 15:50 |
pinesol_green |
[evergreen|Ben Shum] LP#1373594: Also ignore subfield 7 in get_graphics_880s - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=67999a6> |
| 15:52 |
pinesol_green |
[evergreen|Dan Scott] LP#1413490 Fix <table><table> markup - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=9436b7c> |
| 15:57 |
bshum |
remingtron: I was looking at your final changes in https://bugs.launchpad.net/evergreen/+bug/1396161 and just checking on the thinking for removal of osrf-config from the example entries |
| 15:57 |
pinesol_green |
Launchpad bug 1396161 in Evergreen "action_trigger_runner.pl documentation update" (affected: 1, heat: 8) [Undecided,Confirmed] |
| 15:57 |
bshum |
It's cause that's already the default, but should we keep that in the help info for people who might have it live elsewhere for some reason? |
| 16:12 |
|
mrpeters left #evergreen |
| 16:12 |
|
mrpeters joined #evergreen |
| 16:14 |
dbwells |
kmlussier: Dyrcona: I missed one added and two deleted lines in my merging (or unmerging, as the case may be). It seems happier now at my end, so I force pushed over the same branch (collab/dbwells/1198465_cstore_fines_gen). Thanks for the early testing! |
| 16:14 |
kmlussier |
dbwells++ |
| 16:18 |
Dyrcona |
kmlussier: I can load the revised branch if you want to look at it tomorrow. |
| 16:18 |
remingtron |
bshum: I think the help info should be enough as is, since the config setting is the first option listed. But I don't have strong feelings either way. |
| 16:18 |
Dyrcona |
I'm off tomorrow, so otherwise it would have to wait until Saturday. |
| 16:18 |
kmlussier |
Dyrcona: Yes, I think I'll have time to look at it after my meeting tomorrow, so that will be great if you could load it now. |
| 16:18 |
Dyrcona |
Will do. |
| 16:19 |
bshum |
remingtron: Works for me, I'll go ahead and push all that on through momentarily then :) |
| 16:20 |
tsbere |
berick: I am told that I should check with you about including https://bugs.launchpad.net/evergreen/+bug/1413624 in 2.8 before I mark it as 2.next instead. Any thoughts one way or the other? |
| 16:20 |
pinesol_green |
Launchpad bug 1413624 in Evergreen "New AccessHandler Module" (affected: 1, heat: 8) [Undecided,New] |
| 16:20 |
bshum |
remingtron++ |
| 16:20 |
remingtron |
bshum++ #thanks for keeping things moving! |
| 16:23 |
kmlussier |
Does anyone recall off the top of their heads when the WCAG work was incorporated in Evergreen? |
| 16:24 |
pinesol_green |
[evergreen|Josh Stompro] LP#1396161: action_trigger_runner.pl documentation update - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=82bb117> |
| 16:24 |
pinesol_green |
[evergreen|Remington Steed] LP#1396161: Improve public docs and change osrf-config default from script help - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=d445150> |
| 16:24 |
bshum |
kmlussier: I want to say 2.6 |
| 16:24 |
jeff |
kmlussier: commit 598267d contains the release notes -- i think it was 2.6 |
| 16:24 |
pinesol_green |
[evergreen|Dan Scott] Release notes for WCAG compliance for the TPAC - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=598267d> |
| 16:25 |
bshum |
And http://evergreen-ils.org/documentation/release/RELEASE_NOTES_2_6.html agrees with me |
| 16:25 |
kmlussier |
bshum++ jeff++ Thanks! |
| 16:26 |
Dyrcona |
kmlussier: The branch has been installed and services restarted. |
| 16:26 |
jeff |
are the -developer and -packager makefile targets intended to never be both installed? |
| 16:28 |
bshum |
jeff: I thought developer was a subunit of packager. Meaning if you ask for packager, it'll also call the stuff in developer. |
| 16:28 |
bshum |
Something weird going on? |
| 16:28 |
jeff |
i suppose that would have been the obvious thing for me to check. |
| 16:29 |
Dyrcona |
bshum: I notice you're pushing a lot of stuff to 2.6 also. Should I push the symbols popup fix branch to 2.6? I guess it is also a question for dbwells. |
| 16:29 |
bshum |
So I wouldn't expect a problem to call either or |
| 16:30 |
jeff |
bshum: install_packager calls install_developer, you are correct. |
| 16:30 |
bshum |
Dyrcona: Most of the things I end up pushing to 2.7 tend to be either tiny or broken things. I usually save dbwells the trouble of pushing it to rel_2_6 on his behalf, but I could change that if he'd prefer to push it himself :) |
| 16:31 |
kmlussier |
Dyrcona++ Thank you! |
| 16:31 |
jeff |
bshum: so trying to install debian-wheezy-packager target after installing debian-wheezy-developer results in an error because it tries to clone the node git repo a second time. |
| 16:31 |
bshum |
If it was me, I wouldn't hold off on backporting if it's indeed a bug fix. |
| 16:32 |
bshum |
jeff: Ahh..... I primarily tested the Ubuntu side of things, and those are all packages. |
| 16:32 |
bshum |
So it doesn't usually clobber itself, it'll just add whatever packages it's still missing. |
| 16:32 |
* jeff |
nods |
| 16:32 |
bshum |
jeff++ # may want to file that a new bug then for 2.8 series. |
| 16:33 |
bshum |
Darn Wheezy |
| 16:33 |
bshum |
:) |
| 16:33 |
jeff |
might be as simple as clarifying the README (assuming it isn't already clear and I misread) to point out that it's either-or, not both. |
| 16:35 |
bshum |
jeff: Ideally I think it ought to handle both. |
| 16:35 |
bshum |
Meaning if I start off with the developer package, but want to grow up to be a packager on behalf of the project, it shouldn't blow up on me. |
| 16:35 |
* jeff |
nods |
| 16:43 |
bshum |
jeff: I wonder if we added some sort of check to see if the node directory was already cloned |
| 16:43 |
bshum |
Or existing I mean |
| 16:43 |
bshum |
And if so, move on |
| 16:43 |
dbwells |
Dyrcona: If a fix for 2.7 also applies to 2.6, please feel free to push it in. Does that answer your question, or did I misunderstand? |
| 16:44 |
Dyrcona |
dbwells; That answers the question. I didn't want to step on RM toes. |
| 16:44 |
bshum |
jeff: Course then the next step after that to checkout the branch would fail too, cause the branch would already be checked out... |
| 16:44 |
bshum |
Hmm |
| 16:45 |
bshum |
Maybe like the install_libdbi thing before install_nodejs_from_source |
| 16:45 |
bshum |
Where we look for the folder, if not present, get it, etc. |
| 16:45 |
dbwells |
I think whoever does the testing should go ahead and push to all applicable branches. The fact that bshum is an RM and also tests a bunch of things just confuses the situation ;) |
| 16:46 |
* bshum |
either has lots of hats or lots of heads. |
| 16:46 |
bshum |
Possibly both. |
| 16:47 |
bshum |
jeff: That's of course all from Makefile.common I'm curiously looking at. |
| 16:49 |
Dyrcona |
dbwells kmlussier: I'm still getting the error with the branch installed. I even made sure to git fetch before making a new branch. |
| 16:49 |
Dyrcona |
I don't have time to mess with it much today. |
| 16:50 |
pinesol_green |
[evergreen|Dan Scott] LP#1409844: Towards more meaningful catalogue <title> elements - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=eda58b7> |
| 16:53 |
dbwells |
Dyrcona: I'm sorry it's probably still some problem on my end. Or maybe you just did a 'git fetch' and not 'git fetch working'? Again, the problem is probably my fault, so just a suggestion. |
| 16:53 |
Dyrcona |
No, it's me. I fucked my git branches. |
| 16:54 |
bshum |
"Closing time, James." |
| 16:54 |
Dyrcona |
Yep, it's too late in the day to fix this now. |
| 16:55 |
Dyrcona |
I'll just build a new vm on Saturday or Monday. |
| 16:55 |
kmlussier |
Dyrcona: Thanks for trying! |
| 16:55 |
* kmlussier |
calls it a day |
| 16:56 |
pinesol_green |
Incoming from qatests: Test Success - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 17:01 |
berick |
tsbere: re: bug 1413624, if you hope to get it merged into 2.8, go ahead and target 2.8-beta |
| 17:01 |
pinesol_green |
Launchpad bug 1413624 in Evergreen "New AccessHandler Module" (affected: 1, heat: 8) [Undecided,New] https://launchpad.net/bugs/1413624 |
| 17:02 |
eeevil |
dbwells: I've been terribly remiss in not looking at your cstore-fine-gen code ... I'm wondering what the reason for that is? (the use of cstore instead of dbi in the storage app, in particular) ... but, I think I've found a problem in any case. it looks like penalty calculation is being called before the cstore->commit is called |
| 17:03 |
eeevil |
so, fine-oriented penalties won't have fresh data... |
| 17:06 |
eeevil |
dbwells: well, you can ignore the first part, really |
| 17:10 |
|
mrpeters left #evergreen |
| 17:10 |
dbwells |
eeevil: Thanks for looking at it. I'll check out what your saying about the penalty calc, and thank goodness I don't have to relive how I arrived at this path. |
| 17:10 |
|
mmorgan left #evergreen |
| 17:12 |
berick |
dbwells: in a nutshell, "make it possible to run the whole circ shebang, including fine generation, in a single transaction" ? |
| 17:15 |
dbwells |
berick: yep, that's the gist. Just don't ask me why, at least not this late in the day :) |
| 17:16 |
dbwells |
although, it's starting to come back to me |
| 17:16 |
berick |
i have a pretty good idea why, at least in part.. I won't ask you to re-live it :) |
| 17:23 |
dbwells |
eeevil: yep, I see what you mean. I think it'll be easy enough to fix for the backwards compat calls, but penalty generation will have to become responsibility of any code passing in their own transaction. |
| 17:26 |
dbwells |
eeevil++ |
| 22:51 |
|
abowling joined #evergreen |
| 23:47 |
|
goood joined #evergreen |
