Time |
Nick |
Message |
01:07 |
|
_adb joined #evergreen |
01:07 |
|
dkyle joined #evergreen |
01:08 |
|
_bott_ joined #evergreen |
01:59 |
|
_adb joined #evergreen |
02:03 |
|
_bott_ joined #evergreen |
02:03 |
|
dkyle joined #evergreen |
03:08 |
|
dkyle joined #evergreen |
05:42 |
|
genpaku joined #evergreen |
07:13 |
|
rjackson_isl joined #evergreen |
07:29 |
|
agoben joined #evergreen |
07:46 |
|
mrpeters joined #evergreen |
07:54 |
|
ericar joined #evergreen |
08:33 |
miker |
I've rebased the web client sprint 3 branch at http://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/miker/sprint3-rebase-final ... I plan to merge that today, but wanted to give interested folks in here a chance to peek at it first |
08:39 |
|
mmorgan joined #evergreen |
08:53 |
|
jwoodard joined #evergreen |
08:58 |
|
rlefaive joined #evergreen |
09:01 |
|
bos20k joined #evergreen |
09:08 |
|
kmlussier joined #evergreen |
09:08 |
|
maryj joined #evergreen |
09:14 |
|
afterl joined #evergreen |
09:18 |
csharp |
bug-wrangling question - who decides how to target bugs to a series or specific milestone? is that for anyone? or is it assumed to be reserved for RMs and the like? |
09:19 |
csharp |
I ask in part because I'd love to see bug 1612752 considered for 2.11, but I don't want to assume that I can just do that without someone else caring about it :-) |
09:19 |
pinesol_green |
Launchpad bug 1612752 in Evergreen "Feature Request: Cancel Transits, Don't Delete Them" [Wishlist,Confirmed] https://launchpad.net/bugs/1612752 - Assigned to Chris Sharp (chrissharp123) |
09:20 |
kmlussier |
csharp: Anyone who has the power to target can target, particularly in the case where it is Wishlist, and you want to get the attention of the 2.11 RM. |
09:20 |
kmlussier |
csharp: If it doesn't make it into 2.11, it then gets moved up to 2.next |
09:21 |
csharp |
ok cool - well, I'll target it for 2.11-beta for now and let the RM (miker iirc) decide if that's not right |
09:21 |
kmlussier |
csharp: If you also add targets to backport, somebody may disagree. It ultimately is up to the release maintainer to decide whether the target sticks or not. |
09:21 |
csharp |
nah, I don't think it's appropriate for backporting |
09:21 |
csharp |
it's a new feature |
09:22 |
kmlussier |
csharp: Yup. I was just adding it as clarification on who can do what. |
09:22 |
csharp |
oh ok ;-) |
09:23 |
kmlussier |
From what I've seen, I think a lot of RM's use targets as a way to see which code needs to be reviewed. |
09:23 |
csharp |
good to know |
09:24 |
bshum |
Agreed, I usually didn't assign a series target unless there's actual code to be reviewed for backport. Otherwise, most of the time I ended up shuffling the bug from series to series without any other change and that got tedious. |
09:24 |
|
Dyrcona joined #evergreen |
09:24 |
csharp |
I can see that |
09:24 |
bshum |
Or if it was a "High" priority bug that broke data. And I wanted to force someone to pay attention. |
09:25 |
kmlussier |
I sometimes add a target when there is no code, but only when I know I will be submitting the code before feature freeze. |
09:25 |
bshum |
But that usually also came with a bug fix within the day of the bug moving.. so |
09:26 |
csharp |
well, my other issue, bug 1613374 appears to now depend on the outcome of bug 1306666 |
09:26 |
pinesol_green |
Launchpad bug 1613374 in Evergreen "Feature Request: "Canceled Transit" Item Status" [Wishlist,New] https://launchpad.net/bugs/1613374 - Assigned to Chris Sharp (chrissharp123) |
09:26 |
pinesol_green |
Launchpad bug 1306666 in Evergreen 2.9 "When Aborting a Transit, items should not automatically get Reshelving status." [Low,Confirmed] https://launchpad.net/bugs/1306666 |
09:27 |
* Dyrcona |
checks logs. |
09:28 |
* kmlussier |
can probably take a look at bug 1306666 tomorrow if somebody else doesn't get to it first. |
09:28 |
pinesol_green |
Launchpad bug 1306666 in Evergreen 2.9 "When Aborting a Transit, items should not automatically get Reshelving status." [Low,Confirmed] https://launchpad.net/bugs/1306666 |
09:29 |
csharp |
I'm still wrapping my mind around what the solution does |
09:29 |
Dyrcona |
I should really look at 130666, but I'll need to ask someone if he minds that I borrow their server.... ;) |
09:29 |
Dyrcona |
It basically does what my code did, but does a little extra. |
09:29 |
* mmorgan |
was planning to have a look at those two bugs today. |
09:30 |
Dyrcona |
csharp: Bugs do sometimes end up depending on each other. |
09:30 |
Dyrcona |
I've done a little write up where I've found 5 bugs that all sort of depend on each other, or at least the latter 3 depend on the first two. |
09:31 |
csharp |
yeah - it's fine, I just want to understand how to implement my new status on top of the new transit logic |
09:31 |
Dyrcona |
In fact, I promised someone that I would ping gmcharlt and miker about the first two. |
09:31 |
* csharp |
is looking now |
09:32 |
csharp |
I would bet the dependencies go deep if we look hard enough - an isolated bug report might be the tip of an iceberg |
09:32 |
Dyrcona |
Yeah, they sometimes are. |
09:35 |
Dyrcona |
I'll load 130666 on a personal vm and see if the perl tests I wrote still work. They may need to be changed or we may want to add one or two given miker's changes to the code. |
09:36 |
Dyrcona |
If I'm not satisfied with that, then I might check if it's OK to use my old vm at MVLC with real life data. |
09:42 |
Dyrcona |
csharp++ # It's fun trying to hit a moving target. |
09:42 |
csharp |
heh |
09:43 |
tsbere |
I am having fun with trying to standardize user addresses. |
09:43 |
miker |
Dyrcona: I suspect they won't pass now, since I don't do the same thing with non-hold transits |
09:43 |
tsbere |
I am amazed that we only have 3 or 4 email addresses in street fields. <_< |
09:44 |
Dyrcona |
miker: That was my suspicion also. I'll update them if necessary. |
09:44 |
|
yboston joined #evergreen |
09:44 |
* Dyrcona |
does apt-get update on his vm. |
09:46 |
miker |
Dyrcona++ |
09:48 |
Dyrcona |
miker: While you're around, I wanted to ping you and gmcharlt about the following two bugs. |
09:48 |
* miker |
runs away |
09:48 |
Dyrcona |
bug 1485371 |
09:48 |
miker |
;) |
09:48 |
pinesol_green |
Launchpad bug 1485371 in OpenSRF "Use client TZ when supplied to the server" [Wishlist,Fix committed] https://launchpad.net/bugs/1485371 |
09:48 |
Dyrcona |
:) |
09:48 |
Dyrcona |
bug 1485374 |
09:48 |
pinesol_green |
Launchpad bug 1485374 in Evergreen "Use client TZ in the database when supplied to the server" [Wishlist,New] https://launchpad.net/bugs/1485374 |
09:49 |
miker |
sure. you have questions? |
09:49 |
Dyrcona |
I installed the branches back in June and found that the latter had changes in code that appeared to be moved. |
09:49 |
Dyrcona |
I commented on the bugs, IIRC. |
09:49 |
Dyrcona |
I also wonder if there are plans to get those in for 2.11. |
09:50 |
Dyrcona |
I think a number due datetime related bugs could benefit from those branches. |
09:50 |
miker |
ah, because of the auth stuff, yes? |
09:50 |
Dyrcona |
Ah, I see the OpenSRF code went in... |
09:50 |
jeff |
yeah, opensrf code went into master this week for inclusion in 2.5 |
09:51 |
Dyrcona |
Yeah, the auth stuff affects the latter and I wasn't sure if the branches needed changes, and if so, what changes. |
09:51 |
* miker |
looks |
09:53 |
jeff |
when i see "this branch needs a rebase" i hear it in a jack nicholson voice, every time. |
09:53 |
Dyrcona |
jeff: Thanks for that little earworm. :) |
10:00 |
pastebot |
"Dyrcona" at 64.57.241.14 pasted "What now, npm?" (5 lines) at http://paste.evergreen-ils.org/20 |
10:01 |
Dyrcona |
The rest is working, so far. |
10:01 |
bshum |
o.O |
10:02 |
Dyrcona |
Says it's an optional package anyway. |
10:02 |
bshum |
Granted, just WARN, not ERROR at least? |
10:02 |
Dyrcona |
I never noticed that one before, but it must have happened and I just ignored it. |
10:02 |
Dyrcona |
This isn't the first time I've installed the web client on this VM. |
10:06 |
jeff |
fsevents is only an OS X thing. |
10:07 |
jeff |
i believe you can safely ignore that. |
10:07 |
Dyrcona |
OK. |
10:07 |
jeff |
something in the dependency chain is listing it as a nice-to-have. |
10:08 |
Dyrcona |
miker: Looks like my xenial vm would be perferct for testing timezone stuff. It insists on being set to UTC and my laptop is presently EDT. :) |
10:12 |
csharp |
@quote add < jeff> when i see "this branch needs a rebase" i hear it in a jack nicholson voice, every time. |
10:12 |
pinesol_green |
csharp: The operation succeeded. Quote #157 added. |
10:19 |
berick |
well now we all do |
10:20 |
Dyrcona |
:) |
10:20 |
* csharp |
thinks it works pretty well in a Homer Simpson voice too |
10:21 |
* Dyrcona |
just realized that he's running a server on a virtual machine on his laptop. In light of the fact that his first computer was a Commodore Vic-20, he thinks that what he's doing right now is rather amazing. |
10:21 |
csharp |
Dyrcona++ |
10:21 |
* Dyrcona |
has a hard time hearing it in a Homer Simpson voice, but Sean Connery.... |
10:22 |
Dyrcona |
And, eg_db_config --load-all-sample is done. |
10:26 |
Dyrcona |
Well, the tests did fail, but not exactly how I expected them to fail. |
10:27 |
Dyrcona |
Failed test ''Got hold transit copy' isa 'Fieldmapper::action::hold_transit_copy'' |
10:27 |
Dyrcona |
Oh, wait. Failures started before that test. ;) |
10:29 |
Dyrcona |
OK. Failures start at subtests of test 13, which is more or less where I might expect it. |
10:29 |
* Dyrcona |
makes a collab branch based on miker's changes. |
10:30 |
Dyrcona |
Test 14, rather. |
10:30 |
* Dyrcona |
can't read today, apparently. |
10:47 |
|
Christineb joined #evergreen |
10:52 |
* miker |
tests new tz branch... |
10:59 |
* Dyrcona |
"numbers" the tests in the test script. |
11:05 |
|
rlefaive_ joined #evergreen |
11:06 |
Dyrcona |
I think I'm going to remove the lp number from the test file, because csharp will need to alter the tests for the new copy status branch. |
11:07 |
Dyrcona |
Eh, maybe I'll leave it for now and we can sort it out later. |
11:07 |
JBoyer |
"rm it all and let the fs sort it out." |
11:10 |
miker |
Dyrcona: updated TZ branch for evergreen located at http://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/collab/miker/lp1485374-always-use-client-tz-rebase |
11:10 |
Dyrcona |
miker++ # I'll take a look after working on these tests. |
11:25 |
csharp |
@quote add < JBoyer> "rm it all and let the fs sort it out." |
11:25 |
pinesol_green |
csharp: The operation succeeded. Quote #158 added. |
11:35 |
|
bmills joined #evergreen |
11:35 |
|
bmills joined #evergreen |
11:46 |
Dyrcona |
Hmm. Something seems to have changed in checkin. |
11:46 |
Dyrcona |
When I abort the hold transit from the hold library and check the copy in, I get a SUCCESS event instead of ROUTE_ITEM. |
11:47 |
Dyrcona |
OK. I check it in again, and I get NO_CHANGE. |
11:47 |
Dyrcona |
The hold is still there, still with this copy as current_copy. |
11:47 |
* Dyrcona |
digs through git log. |
11:48 |
Dyrcona |
Action that should have been "abort the hold transit from the home library" and not hold library. I goofed when I edited to add hold before transit. |
11:48 |
Dyrcona |
s/Action/Actually/ |
11:48 |
* Dyrcona |
rolls his eyes at himself. |
11:49 |
Dyrcona |
never mind. It can't be a change 'cause I didn't rebase this branch, yet. |
11:49 |
Dyrcona |
I don't think I did... |
11:50 |
* Dyrcona |
looks a bit harder at miker's changes. |
11:54 |
Dyrcona |
Ok. the transit was aborted at the destination library and then checked in at the acp.circ_lib, and now it won't fill the hold, again. |
11:55 |
* Dyrcona |
changes the status to Available manually. |
11:56 |
mmorgan |
Dyrcona: What was the status after the transit was aborted? |
11:58 |
Dyrcona |
In Transit |
11:58 |
Dyrcona |
It has been checked in twice at the home library and doesn't fill the hold again after either one. |
11:59 |
berick |
should name the canceled transit copy status "stranded" or "stuck at O'Hare" |
11:59 |
mmorgan |
Even after you changed it to available? |
11:59 |
Dyrcona |
I haven't tried that yet. I have to reload concerto after each failed test run. |
12:00 |
Dyrcona |
I'm first going to verify the copy status in the tests after each step. |
12:03 |
|
kmlussier joined #evergreen |
12:04 |
|
brahmina joined #evergreen |
12:12 |
|
bmills joined #evergreen |
12:13 |
|
miker joined #evergreen |
12:13 |
|
Shae joined #evergreen |
12:13 |
|
graced joined #evergreen |
12:14 |
|
sarabee joined #evergreen |
12:15 |
|
jyorio joined #evergreen |
12:16 |
JBoyer |
Did miker kick the cable out of the wall again? |
12:16 |
|
rhamby joined #evergreen |
12:16 |
phasefx |
the application does live on a server called commidore64 |
12:17 |
phasefx |
just buggy :-/ |
12:17 |
JBoyer |
:D I like the way things are done down there. |
12:17 |
JBoyer |
(the Commodore part, not so much the buggy part.) |
12:17 |
miker |
huh... I didn't even notice the disconnect. last I saw was: <Dyrcona> I don't think I did... |
12:17 |
miker |
in case anyone was talking in my direction |
12:18 |
miker |
yeah, quassel core is acting up a lot recently... |
12:23 |
bshum |
Poor quasselcore :( |
12:23 |
Dyrcona |
I was just speaking in general how holds appear to be trapping differently for me in concerto today and it's more or less the same branch when the tests all passed before. |
12:23 |
Dyrcona |
I'm trying tricks to see what I need to do. |
12:24 |
Dyrcona |
A script to stop services, reload concerto into the db, and start services again has come in real handy. |
12:25 |
tsbere |
Dyrcona: Heh, I have a bash alias to do that for me on my dev machine. :D |
12:26 |
* dbs |
wonders if Dyrcona is finding out why our holds aren't getting trapped at checkin -- this is the TZ testing? |
12:28 |
Dyrcona |
dbs: It could be, but I'm doing it all on the server where everything is UTC. |
12:29 |
Dyrcona |
Maybe it was EDT last time.... I believe I did make a new VM since then. |
12:29 |
Dyrcona |
It traps the first time, but after aborting the transit and checking the copy in again, it's not trapping. |
12:29 |
Dyrcona |
I recall that used to work. |
12:31 |
Dyrcona |
oh, right. I always forget... pcrud needs a transaction to do an update. |
12:32 |
Dyrcona |
Oh, yeah, and it has to be connected.... |
12:33 |
Dyrcona |
:) |
12:34 |
JBoyer |
Who is going to clean up all of these bits that are just scattered all over the floor? |
12:37 |
bshum |
@who is going to clean up all of these bits that are just scattered all over the floor |
12:37 |
pinesol_green |
jwoodard is going to clean up all of these bits that are just scattered all over the floor. |
12:45 |
* Dyrcona |
gives up for now. |
12:45 |
|
akilsdonk joined #evergreen |
12:54 |
Dyrcona |
Hmm... Looks like I rebased on master on Jun 24. |
12:54 |
Dyrcona |
Maybe something changed around then, and I didn't notice? |
12:54 |
Dyrcona |
Guess I didn't give up... ;) |
12:57 |
Dyrcona |
Nope. Circulate.pm had not changed since February, so I should have had those changes already. |
12:57 |
* Dyrcona |
takes a real break this time. |
13:06 |
phasefx |
live tester was broken again and I didn't realize it. Clean run shows just one issue from settings-tester.pl: Please install Excel::Writer::XLSX |
13:13 |
Dyrcona |
heh. I read that as "liver tester" at first. ;) |
13:13 |
Dyrcona |
It's one of *those* days, I think. |
13:16 |
bshum |
That dependency's been around for awhile, hmmm |
13:18 |
|
phasefx_ joined #evergreen |
13:27 |
|
gsams_ joined #evergreen |
13:36 |
|
collum joined #evergreen |
13:38 |
|
terran joined #evergreen |
13:44 |
|
tspindler joined #evergreen |
13:48 |
|
rgagnon joined #evergreen |
13:49 |
* kmlussier |
will try to squeeze a question in before the EOB meeting begins. |
13:50 |
kmlussier |
One thing I would love to see merged in time for 2.11 is bug 1553287 |
13:50 |
pinesol_green |
Launchpad bug 1553287 in Evergreen "Incorporating part information into biblio fingerprint" [Medium,New] https://launchpad.net/bugs/1553287 |
13:51 |
kmlussier |
I made the necessary database updates in my working branch, but the one thing I'm stuck on is the guidance I should give in the release notes as to how to get existing records remapped. |
13:51 |
kmlussier |
I had tried a couple of things when I first worked on the code, but I must have been trying the wrong things. |
13:54 |
|
rfrasur joined #evergreen |
13:54 |
rfrasur |
afterl, I just sent an email. sorry it's so late. |
13:54 |
|
hbrennan joined #evergreen |
13:57 |
csharp |
kmlussier: there's a trigger on any insert or update on biblio.record_entry, so it *should* just happen :-/ |
13:57 |
csharp |
(for fingerprint) |
13:57 |
kmlussier |
Updating a record wasn't remapping things properly for me. |
13:57 |
berick |
if the MARC differs or the force-on-same-marc setting is applied |
13:58 |
kmlussier |
I also tried a reingest, which didn't remap things as I would expect. |
13:58 |
csharp |
kmlussier: yeah - did you see that global_flag (or internal_flag, I forget which) |
13:59 |
kmlussier |
csharp / berick: I'll take a look at that, but I thought I made changes to the bib record before updating. But it was so long ago, I could be wrong. |
13:59 |
rfrasur |
Hey all, the EOB meeting is going to perhaps be starting. I don't know how to run the meeting bot and am here but sick (it's not catching) |
13:59 |
kmlussier |
http://wiki.evergreen-ils.org/doku.php?id=community:using-meetbot |
14:00 |
afterl |
So EOB members, FYI, Grace is sick. She's asked me to either cancel or run the meeting. |
14:00 |
rfrasur |
I think that afterl is going to running it. |
14:00 |
terran |
Do we have an agenda? |
14:00 |
afterl |
I am happy to run it |
14:00 |
afterl |
Good question |
14:00 |
afterl |
Here's what I have (to help you decide) |
14:01 |
rfrasur |
lemme check if it's been updated on the website while you're putting it in here. |
14:01 |
afterl |
Financial Report (Galen?)Conference Committee ReportRelease Manager ReportRules of Governance Committee Report |
14:01 |
afterl |
If I can get feedback from the respective parties on all of these topics, then I'm willing to give this a go |
14:02 |
|
mmorgan1 joined #evergreen |
14:02 |
terran |
We can certainly present the work we've done on the Rules of Governance document so far |
14:02 |
afterl |
That's good |
14:03 |
afterl |
Who else is here? |
14:03 |
rgagnon |
rgagnon is here for the EOB. |
14:03 |
afterl |
Hi Ron |
14:04 |
rfrasur |
Sharon will not be here. |
14:04 |
* rfrasur |
got an email. |
14:04 |
tspindler |
tspindler is here |
14:04 |
tspindler |
feels like a tautology |
14:04 |
afterl |
Anyone from the conference committee? |
14:05 |
rfrasur |
That would be Grace. |
14:05 |
afterl |
Hmmm..... |
14:05 |
rfrasur |
Is it possible for us to postpone rather than cancel. |
14:05 |
rfrasur |
? |
14:05 |
afterl |
I like that idea |
14:05 |
afterl |
so we don't miss an entire month |
14:05 |
rfrasur |
I'd hate to go an entire month without updates. |
14:05 |
rfrasur |
afterl++ |
14:06 |
rgagnon |
OK with me. |
14:06 |
afterl |
How about this - I can check with gdunbar on some dates in the near future |
14:06 |
tspindler |
sounds good |
14:06 |
rfrasur |
Can we do that that through email, check with gdunbar and do a poll for potential dates? |
14:06 |
afterl |
Not up for holding a meeting with limited participation |
14:06 |
collum |
Ok with me too |
14:06 |
rfrasur |
Say in the next two weeks? |
14:06 |
afterl |
rfrasur: yes |
14:06 |
rfrasur |
Rock on. Thank you. |
14:06 |
afterl |
so thanks to you all |
14:06 |
afterl |
Have a good rest of your day .... |
14:07 |
terran |
Next week is good for me except for Wednesday |
14:20 |
|
tspindler left #evergreen |
14:20 |
|
JBoyer joined #evergreen |
14:33 |
* tsbere |
glares at a query he keeps running on static data but still gets different results each time |
14:33 |
jeff |
bad ram. ;-) |
14:34 |
tsbere |
May be that I am using poorly written third party code. Which means I may need to change to *different* third party code because I don't want to implement this mess myself. >_> |
14:34 |
jeff |
(running an md5sum repeatedly on the same unchanging file and getting different results == you should have bought ECC ram) |
14:37 |
tsbere |
jeff: That depends. Does your md5sum include the file's access time? I actually had someone write one that did. Worked fine for them in a noatime system... |
14:38 |
jeff |
was his name Heisenberg? |
14:41 |
* tsbere |
is suspecting that the code he is using isn't initializing memory properly between calls :( |
14:42 |
jeff |
ouch. |
14:42 |
tsbere |
When the same query on static data in a system only I am logged into returns a seemingly random number of rows between 10,117 and 23,772.... |
14:43 |
tsbere |
And earlier the *same calls* with the *same data set* were only returning at *most* 3,200 rows.... |
14:54 |
jeff |
hrm. interesting mix of application names in syslog on added content log entries. |
14:54 |
jeff |
(probably not limited to that, probably nothing new or exciting) |
14:55 |
jeff |
but i see a mix of osrf_json_gw, /usr/sbin/apache2, and osrf_http_translator as the application name in syslog when looking at lines matching AddedContent.pm, with no apparent logic as to which lines get which application name. |
14:55 |
jeff |
mostly osrf_json_gw |
14:57 |
jeff |
probably just a matter of "what did the apache child do before it handled this request" |
14:57 |
jeff |
which would determine what the most recent call to osrfLogSetAppname did |
14:57 |
berick |
yeah, i think that's it |
14:58 |
berick |
and the Perl code probably does that dance only during child_init |
14:58 |
jeff |
and in the case of /usr/sbin/apache2, it's an apache child that hasn't serviced an opensrf gateway/translator call yet |
15:13 |
|
afterl left #evergreen |
15:31 |
miker |
time to make the donuts^W^W^Wmerge the web staff branch |
15:34 |
jeff |
miker++ |
15:35 |
berick |
what, no donuts? |
15:37 |
* miker |
makes munchkins, pushes branch to repo |
15:38 |
pinesol_green |
Showing latest 5 of 41 commits to Evergreen... |
15:38 |
pinesol_green |
[evergreen|Bill Erickson] LP#1522635 Webstaff lost (etc.) checkout completes - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=f6eeb16> |
15:38 |
pinesol_green |
[evergreen|Bill Erickson] LP#1527694 Webstaff clear last patron - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=350500a> |
15:38 |
pinesol_green |
[evergreen|Bill Erickson] LP#1527694 Webstaff egHatch supports 'LoginSession' storage - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=059411b> |
15:38 |
pinesol_green |
[evergreen|Michele Morgan] LP#1583729 Item status screen column options do not include age protection - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=3d78e82> |
15:38 |
pinesol_green |
[evergreen|Galen Charlton] LP#1476049: disable serve-cgi-bin Apache config on Jessie and Xenial - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=4e4525c> |
15:39 |
berick |
miker++ |
15:48 |
|
gsams joined #evergreen |
15:52 |
jeff |
berick: in the case of perl applications, OpenSRF::Server calls $logger->set_service($self->{service}), so there's no fallback to $0 |
15:56 |
berick |
jeff: Utils/Logger.pm will fall back to $0, though, if set_service() is never called from outside. |
16:01 |
berick |
ah, but it only does it once |
16:02 |
berick |
probably the mod_perl apps need to run $logger->set_service first thing in their handler() subs (like the C apps). |
16:03 |
jeff |
yeah, so set_service gets called, sets the perl var $service, which means that set_service doesn't get called again. meanwhile, the apache child services a gateway/translator request which does a closelog/openlog, and... |
16:07 |
berick |
yeah |
16:08 |
pinesol_green |
[evergreen|Galen Charlton] LP#1613381: combine two tables in patron notification preferences - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=079d0ed> |
16:41 |
jeff |
if you're using syslog for ErrorLog in apache, those entries also end up with the osrf_json_gw/osrf_http_translator ident |
16:44 |
jeff |
(doesn't apply if you're using piped logging to something like logger) |
16:44 |
|
mmorgan joined #evergreen |
16:45 |
kmlussier |
@dessert |
16:45 |
* pinesol_green |
grabs some of mllewellyn's Cupcakes for kmlussier |
17:10 |
|
mmorgan left #evergreen |
17:35 |
|
eby_ joined #evergreen |
17:37 |
|
bmills joined #evergreen |
22:51 |
|
gsams_ joined #evergreen |
23:03 |
|
dcook joined #evergreen |