| Time |
Nick |
Message |
| 01:37 |
|
gsams joined #evergreen |
| 04:44 |
|
gsams_ joined #evergreen |
| 04:47 |
|
gsams_ joined #evergreen |
| 06:41 |
|
rlefaive joined #evergreen |
| 07:26 |
|
agoben joined #evergreen |
| 07:26 |
|
rjackson_isl joined #evergreen |
| 07:29 |
|
JBoyer joined #evergreen |
| 08:02 |
|
rlefaive joined #evergreen |
| 08:03 |
|
kmlussier joined #evergreen |
| 08:09 |
|
mrpeters joined #evergreen |
| 08:19 |
|
ericar joined #evergreen |
| 08:30 |
kmlussier |
Good morning #evergreen! |
| 08:30 |
kmlussier |
@coffee [someone] |
| 08:30 |
* pinesol_green |
brews and pours a cup of Mocha Java Espresso, and sends it sliding down the bar to bshum |
| 08:30 |
kmlussier |
@tea [someone] |
| 08:30 |
* pinesol_green |
brews and pours a pot of Bi Luo Chun Green Tea (Pi Lo Chun), and sends it sliding down the bar to pastebot (http://ratetea.com/tea/teavivre/bi-luo-chun-green-tea-pi-lo-chun/6490/) |
| 08:39 |
|
mmorgan joined #evergreen |
| 08:40 |
tsbere |
I am not sure how good it is, I have to attend meetings this afternoon and be prepped for them this morning. <_< |
| 08:59 |
|
krvmga joined #evergreen |
| 09:04 |
|
rlefaive joined #evergreen |
| 09:05 |
jeff |
morning! |
| 09:06 |
|
jwoodard joined #evergreen |
| 09:14 |
krvmga |
jeff: morning! |
| 09:21 |
|
maryj joined #evergreen |
| 09:35 |
|
Dyrcona joined #evergreen |
| 09:38 |
mmorgan |
Good morning, all! I'm working on lp 1583729 |
| 09:38 |
pinesol_green |
Launchpad bug 1583729 in Evergreen "Item status screen column options do not include age protection" [Wishlist,Confirmed] https://launchpad.net/bugs/1583729 - Assigned to Michele Morgan (mmorgan) |
| 09:38 |
mmorgan |
I have the xul pages covered, but I'm stuck on the Holdings view in webby. |
| 09:39 |
mmorgan |
Here are a couple of screenshots: https://docs.google.com/a/noblenet.org/document/d/1VEdLdI5wKiOIJ5-fx6pI88eGrwwRlUICLtGccBREe08/edit?usp=sharing |
| 09:40 |
kmlussier |
mmorgan: We need permission to see that. |
| 09:40 |
mmorgan |
Sorry! always forget to click "OK" :-( |
| 09:40 |
kmlussier |
:) |
| 09:42 |
mmorgan |
In t_holdings.tt2, I tried <eg-grid-field label="[% l('Age-based Hold Protection') %]" path="age_protect"></eg-grid-field> which resulted in the first screenshot |
| 09:42 |
mmorgan |
<eg-grid-field label="[% l('Age-based Hold Protection') %]" path="age_protect.name"></eg-grid-field> gave me the second. |
| 09:43 |
Dyrcona |
Dunno if I'm supposed to be able to see it, but I can't see the document. |
| 09:44 |
mmorgan |
In the second screenshot, the item with age protection displays correctly, but how can the field blanked for the other items? |
| 09:44 |
mmorgan |
kmlussier: Can you see the document now? |
| 09:45 |
kmlussier |
mmorgan: No. It's still telling me that I need permission. |
| 09:46 |
mmorgan |
Ah. OK. How about now? |
| 09:46 |
kmlussier |
Yes, works for me now. |
| 09:46 |
mmorgan |
:) |
| 09:46 |
Dyrcona |
mmorgan: What does circulation modifier do? |
| 09:47 |
* Dyrcona |
opens the template to look. |
| 09:47 |
mmorgan |
Circ modifier is <eg-grid-field label="[% l('Circulation Modifier') %]" path="circ_modifier"></eg-grid-field> |
| 09:50 |
|
yboston joined #evergreen |
| 09:51 |
jeff |
i've seen the bit in the second screen shot on webby before, but don't see it currently. perhaps it was a bug that has been fixed and you lack the fix locally? |
| 09:51 |
jeff |
(or just the similar symptom without a shared root cause) |
| 09:51 |
* jeff |
looks at changes |
| 09:52 |
kmlussier |
Yeah, I thought I had seen it before too, but I couldn't find the fixes when I tried looking for them. |
| 09:53 |
jeff |
i think it may be commit 89787b8 |
| 09:53 |
* mmorgan |
also remembers seeing something similar before, and also failed to find fixes. |
| 09:53 |
jeff |
in working: http://git.evergreen-ils.org/?p=working/Evergreen.git;a=commit;h=89787b83e7d1f74dca2bcd59fb1234633e4131f4 |
| 09:54 |
kmlussier |
jeff++ |
| 09:54 |
jeff |
miker++, not me. ;-) |
| 09:54 |
kmlussier |
The karma was for the finding. :) |
| 09:55 |
* mmorgan |
looks |
| 09:55 |
kmlussier |
I was looking much further back in history apparently. |
| 09:56 |
mmorgan |
jeff++ #finding |
| 09:56 |
mmorgan |
miker++ #fixing |
| 09:57 |
miker |
eh? wha? ... ah! yes, that was annoying me :) |
| 09:57 |
mmorgan |
That fix doesn't seem to be in my file. Should do the trick :) |
| 09:59 |
kmlussier |
miker++ #fixing mmorgan++ #hacking the web client |
| 10:00 |
mmorgan |
YAY!!! That did the trick :) |
| 10:00 |
mmorgan |
Should have a branch up soon. |
| 10:01 |
Dyrcona |
Yay! |
| 10:01 |
miker |
Dyrcona: question about 022ebd22895c987eb2227d8463b36e9a55d1d783 ... what happens to a copy who's transit.status is, say, damaged, and the copy is mistakenly checked in at the wrong location (or, a WS registered at the wrong location? |
| 10:01 |
miker |
AH! MEETING! biab |
| 10:03 |
Dyrcona |
miker: It does what the code says. If it's checked in at home and the copy status is transit, it changes to reshelving. The code cannot check for a mistaken checkin at the "wrong" location, 'cause the code just does what it's told. |
| 10:06 |
Dyrcona |
Rather, if the transit is aborted at home.... |
| 10:07 |
|
collum joined #evergreen |
| 10:44 |
miker |
Dyrcona: my point is that the code today will apply the transit.copy_status (which is not necessarily "reshelving") when the transit is aborted. with your code, it will abort the transit and /forget/ the transit.status, which, again, may not be reshelving, when the transit is aborted "remotely", even when the staff user has permission. so, you can lose a "damaged" status, or a "bindery" status, etc. |
| 10:47 |
kmlussier |
csharp++ #Bug wrangling |
| 10:48 |
* dbs |
considers fixing a 4-year-old bug he opened and identified a potential fix for |
| 10:49 |
csharp |
kmlussier: yeah, there are some Evergreen Classic™ bugs in there ;-) |
| 10:49 |
dbs |
csharp++ |
| 11:03 |
Dyrcona |
miker: "the code today will apply the transit.copy_status ... when the transit is aborted" does not jibe with my recollection of the experience. |
| 11:03 |
Dyrcona |
Nor does it jibe with the bug description. |
| 11:04 |
berick |
it forces the copy back into Reshelving if it's a hold transit. otherwise, it adopts the status carried in the transit. |
| 11:04 |
berick |
so it's a bit of both |
| 11:06 |
berick |
http://git.evergreen-ils.org/?p=Evergreen.git;a=blob;f=Open-ILS/src/perlmods/lib/OpenILS/Application/Circ/Transit.pm;h=22074384d33db7f3c235dd2a9ca0751bd913eb97;hb=HEAD#l242 |
| 11:06 |
Dyrcona |
berick: Right. I was looking at it again. |
| 11:06 |
Dyrcona |
We seem to get a lot of hold transits that never clear for one reason or another. |
| 11:07 |
Dyrcona |
The problem as I understand it is that the code today changes the copy status when it shouldn't, so I sought to reduce the times that the status changes. |
| 11:07 |
jeff |
staff select "don't print" and think that means "don't capture", and then they re-shelve the book instead of sending it to the correct library? |
| 11:08 |
Dyrcona |
If you read the comments, you can tease out how the code evolved. |
| 11:08 |
Dyrcona |
jeff: No idea what happens, really. I don't work in a library and by the time it gets to me, no one knows or remembers. |
| 11:08 |
Dyrcona |
Often times, the transit that was aborted was months old at the time. |
| 11:09 |
jeff |
lots of reasons for transits to not complete. we do a monthly report of "in transit too long" which is mailed to each library. then there's a followup report where anything that was on the first report and hasn't been cleared yet is aborted and the items marked missing. |
| 11:09 |
* Dyrcona |
resists the urge to use the "r" word. |
| 11:09 |
jeff |
(with some human intervention/analysis in some of those followup cases, i think -- which is why it isn't just automatically done.) |
| 11:10 |
Dyrcona |
jeff: Most of the cases that I hear about with abort transit, the librarian has the copy in hand and doesn't want it to fulfill the transit for some reason. |
| 11:10 |
jeff |
we also had a report for a while of things in transit to self too long -- some items were being captured for local holds at SIP checkin but were incorrectly being reshelved instead of placed on the shelf. a case of staff overriding the sorter. fixed, don't generally need that report anymore. |
| 11:11 |
jeff |
"instead of placed on the hold shelf" |
| 11:11 |
Dyrcona |
MVLC does an in transit too long report, mainly so they can harangue the delivery company. |
| 11:11 |
* jeff |
nods |
| 11:12 |
tsbere |
MVLC does a number of reports to harangue various people. <_< |
| 11:12 |
tsbere |
"Holds that are shelf-expired on someone *else's* shelf so we can call and yell at them to check them in already" |
| 11:12 |
tsbere |
<_< |
| 11:13 |
Dyrcona |
I think the code in abort transits is too trusting that everything has been done correctly. It blindly changes the copy status to whatever without checking the current status. |
| 11:14 |
Dyrcona |
I've seen checked out copies go to reshelving because of an aborted hold transit while the circulation is still open afterward. |
| 11:14 |
Dyrcona |
That is the situation I was trying to prevent. |
| 11:14 |
* mmorgan |
has also seen what Dyrcona describes. |
| 11:15 |
jeff |
because the item was checked out while still in transit, and the transit was not resolved at time of checkout? |
| 11:15 |
Dyrcona |
jeff: I don't know. I don't care. It doesn't matter. |
| 11:16 |
mmorgan |
jeff: I think these could be situations where the transit exists, but the item status isn't In Transit. |
| 11:16 |
Dyrcona |
How that transit got stuck is irrelevant to this discussion. Sure, you could fix that, but then you still don't know what other possible work flow could lead to this. |
| 11:17 |
Dyrcona |
I don't think abort transit should change a copy status unless the status is "In Transit," full stop. |
| 11:18 |
Dyrcona |
I added the check for it being at home because mmorgan and kmlussier asked me to do so. |
| 11:18 |
Dyrcona |
I disagree with that change, but I made it. |
| 11:18 |
|
Christineb joined #evergreen |
| 11:19 |
Dyrcona |
I think, if I were to redo it today, I'd remove that check and I'd remove the bit that checks for a hold transit and makes it reshelving. |
| 11:19 |
Dyrcona |
But then, I guess it could go on hold when it isn't. |
| 11:19 |
* miker |
reads up |
| 11:19 |
Dyrcona |
I like csharp's idea for a canceled transit copy status more and more. :) |
| 11:20 |
csharp |
well, I think my new status branch ignores the concern miker brings up too - if the item is transited in Damaged or Bindery, that gets clobbered |
| 11:20 |
kmlussier |
jeff: In answer to your question, I was able to replicate the checked out item with a hanging transit through a series of what I thought were implausible steps. It's a hard thing to make happen. |
| 11:20 |
|
rlefaive joined #evergreen |
| 11:21 |
miker |
Dyrcona: if the pain is all coming from hold transits that get aborted, then I think modifying that internal branch would be best, no? |
| 11:21 |
miker |
then return transits don't forget what they're supposed to do |
| 11:21 |
jeff |
kmlussier: thanks. we hadn't seen much of that there that i'm aware of, so i was curious (above). |
| 11:21 |
Dyrcona |
In my experience, "hard" or "implausible" happens all the time. |
| 11:21 |
kmlussier |
jeff: I put those steps on the LP bug if you're curious. |
| 11:22 |
jeff |
kmlussier: always. |
| 11:22 |
jeff |
kmlussier++ |
| 11:22 |
Dyrcona |
miker: I don't think abort transit should change the copy status unless the copy status is in transit. After that, the resit is negotiable. :) |
| 11:22 |
miker |
Dyrcona: and what about the information the code would flush down the drain? |
| 11:23 |
kmlussier |
And as a follow-up to that, I don't think a copy should get a reshelving status if whatever action changed the status happened outside its circulation library. |
| 11:23 |
Dyrcona |
miker: If combined with csharp's code to cancel a transit rather than delete, the information would still be there. |
| 11:23 |
Dyrcona |
In my experience though, that information is typically irrelevant by the time abort transit and copy status becomes an issue. |
| 11:25 |
miker |
or, we could just force aborted hold transit statuses to "in transit" instead of "reshelving" when not at the destination library ... which seems to be the point, is it not? |
| 11:25 |
Dyrcona |
But then, if the copy is actually checked out, you just hosed someone's circulation, which to mind is worse. |
| 11:25 |
miker |
I mean, the complaint AIUI is that there are copies in "reshelving" where they shouldn't be when someone aborts a hold transit. am I not getting the problem, though? |
| 11:26 |
Dyrcona |
I don't think you're getting the whole problem, no. |
| 11:26 |
Dyrcona |
The abort transit code assumes that the copy is still in transit, when it may not be for a variety of reasons. |
| 11:27 |
Dyrcona |
I have seen actual cases of a hold transit from 6 months ago being aborted when the copy was checked out to a patron. |
| 11:27 |
Dyrcona |
The copy went to reshelving when it should have stayed checked out. |
| 11:27 |
|
brahmina joined #evergreen |
| 11:27 |
Dyrcona |
The circulation itself was untouched. |
| 11:28 |
* mmorgan |
has seen one case where aborting a transit set TWO items to reshelving. |
| 11:28 |
miker |
then I think the description of the bug is lacking |
| 11:28 |
Dyrcona |
Well, yes, the description may be lacking. It was mmorgan's bug, and I glommed onto it in the comments. ;) |
| 11:29 |
Dyrcona |
I do think that the real problem is abort transit changing copy status when the copy status is not In Transit. |
| 11:29 |
miker |
and saying that how the "hanging" transits got that way doesn't matter is not how one generally fixes bugs, IMNSHO |
| 11:29 |
Dyrcona |
:) |
| 11:29 |
Dyrcona |
Well, you can find one way that happens and fix it, but without fixing abort transit, you could still end up with other ways that this happens. |
| 11:30 |
Dyrcona |
I'm talking about adding a safe guard to abort transit to protect the copy status from being changed unnecessarily. |
| 11:30 |
mmorgan |
The original description was intended to address the simple issue of not being able to track items when transits were aborted, and having them show up on a pull list when it's likely they aren't even in the library |
| 11:30 |
miker |
yes, bugs will exist. but the proposed change throws out the baby with the bathwater for return transits |
| 11:30 |
Dyrcona |
In a system as complicated as Evergreen, you can never really be sure how things got to a certain state. |
| 11:30 |
Dyrcona |
miker: I disagree. |
| 11:30 |
miker |
and return transits are not implicated in the bug (description or comments) at all |
| 11:31 |
Dyrcona |
Well, return transit will get the return status if aborted at home. |
| 11:31 |
miker |
Dyrcona: I disagree that you can't be sure. you can, it just may take more time than is reasonable to invest |
| 11:32 |
miker |
and they will THROW AWAY data otherwise |
| 11:32 |
Dyrcona |
Only hold transits are forced to reshelving and that is the current behavior, not mine. |
| 11:33 |
miker |
Dyrcona: a hold transit, but its nature, will not have a "special" status. it must be available-equivelant |
| 11:33 |
miker |
if you want to cause /those/ aborted transits, at non-home (and non-dest) locations to be marked specially, great. I support that |
| 11:33 |
Dyrcona |
Which part of the and do you object to? |
| 11:33 |
miker |
because I see exactly what you mean there |
| 11:34 |
miker |
but return transits can have /any/ status |
| 11:34 |
miker |
so don't throw that status information away |
| 11:34 |
miker |
I'll happily produce an alternative branch to illustrate, if you'd like |
| 11:34 |
berick |
Dyrcona: are you basically proposing: if (copy->status != <in-transit>) { /* OMG leave the copy alone */ } |
| 11:35 |
Dyrcona |
berick: Yes, pretty much. |
| 11:36 |
berick |
that seems like a reasonable safe guard to me. the copy /should/ be in-transit, so it's not affecting the correct case. |
| 11:36 |
csharp |
our experience is that the transit's target copy may be actually checked out or on the hold shelf or somewhere else, so I agree with letting the current copy status "win" |
| 11:38 |
Dyrcona |
miker: I am more than happy to look at any other proposals. Maybe I'm missing something. |
| 11:47 |
miker |
Dyrcona: so, here's my theory on how "hanging transits" occur: 1) staff fail to check in incoming hold transit items and just toss them on the hold shelf 2) staff force override of the checkout from a "bad" status, (if they are notified at all) 3) item is returned and the transit is unwrapped, breaking the circ |
| 11:55 |
Dyrcona |
Could be. |
| 11:55 |
* Dyrcona |
tries to read a diff backwards and decides to check the branch out instead. |
| 11:56 |
|
maryj joined #evergreen |
| 12:06 |
jeff |
I remember a while back some discussion about potential issues and/or improvements with proxying or load balancing websockets. It may have simply been "use a proxy to allow websockets and https to both take place on 443/tcp to avoid strict firewall issues." |
| 12:06 |
jeff |
Does anyone have a memory of what I'm trying to describe above? |
| 12:09 |
berick |
jeff: yes, IIRC, gmcharlt was looking at using nginx to do just that. |
| 12:09 |
berick |
sharing 443 |
| 12:12 |
jeff |
okay, good. thought i was remembering correctly, but i wasn't sure if there were some other issues lurking. |
| 12:12 |
jeff |
need for more/different persistence with LVS, etc. |
| 12:13 |
jeff |
hah |
| 12:14 |
jeff |
(misdirected hah -- dark laughter directed at an unrelated set of monitoring system alerts) |
| 12:20 |
* dbs |
finds unexpected need for decode_utf8() to be added to shelving location names (and probably other strings retrieved from the database) in marc_export :/ |
| 12:22 |
dbs |
the fun things you find when you have shelves named "Référence" and "Collection générale" :) |
| 12:24 |
miker |
Dyrcona: there's a commit at the top of http://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/miker/lp1306666-abort-transit-item-status that modifies your proposal |
| 12:52 |
|
bmills joined #evergreen |
| 13:01 |
|
rlefaive_ joined #evergreen |
| 13:04 |
|
mrpeters1 joined #evergreen |
| 13:17 |
|
bmills joined #evergreen |
| 13:18 |
|
bmills joined #evergreen |
| 13:20 |
Dyrcona |
miker++ |
| 13:23 |
|
rlefaive joined #evergreen |
| 13:36 |
|
rfrasur joined #evergreen |
| 14:32 |
* jeff |
pulls gently on the thread labeled "stop running apache as the opensrf user" |
| 14:34 |
Dyrcona |
jeff: Be careful you don't unravel the whole thing....That's a pretty delicate sweater. |
| 14:35 |
Dyrcona |
Should work, though, if you're meticulous. |
| 14:35 |
Dyrcona |
:) |
| 14:38 |
|
maryj_ joined #evergreen |
| 14:45 |
JBoyer |
jeff: fix your logging if it's not using syslog, and make a few things gid = www-data with g+r and you're all set. We haven't run apache as opensrf in years. |
| 14:46 |
JBoyer |
The project I'd like to spend some spare time on is PREFIX=/ and SYSCONFDIR=/etc/opensrf/ or similar. Did not work the last time I tried, but that may have been because I made some mistakes in that VM. |
| 14:46 |
Dyrcona |
JBoyer jeff: Is there any net benefit like for security or whatever? |
| 14:48 |
jeff |
JBoyer: amusing, as i was just sitting here wondering why your playbook set permissions on /var/run/apache2 and /var/log/apache2 in addition to the (currently recommended in docs) /var/lock/apache2 :-) |
| 14:48 |
JBoyer |
One less thing to change from the default, and you can use your apache install for other things if you like. (for smaller installs, anyway.) Also it may be slightly more secure since by default it can't write anywhere. |
| 14:48 |
JBoyer |
jeff, because they're old and that never caused any problems, so it was forgotten. :D |
| 14:50 |
Dyrcona |
JBoyer: Thanks. I guess you handle offline circ with permissions on the one directory. |
| 14:50 |
Dyrcona |
;) |
| 14:51 |
JBoyer |
And vandelay, yes. |
| 14:51 |
JBoyer |
(possibly others, memory is fuzzy.) |
| 14:52 |
Dyrcona |
Use fuzzy logic, then. :) |
| 14:52 |
JBoyer |
Yay! All of our problems are solved, for some definitions of "problems" and "solved!" |
| 14:53 |
jeff |
semi-related is the desire to not ignore some of the things which are lost when using syslog with apache. |
| 14:53 |
Dyrcona |
heh |
| 14:53 |
Dyrcona |
JBoyer: And some definitions of "all?" |
| 14:53 |
JBoyer |
Didn't want to be /entirely/ silly. |
| 14:54 |
Dyrcona |
:) |
| 14:54 |
Dyrcona |
jeff: Running as www-data helps with the log messages that don't make it to syslog, or was your comment in reference to something else? |
| 14:54 |
JBoyer |
jeff, remind me what you mean, things like log parsing utils and so on? |
| 14:56 |
jeff |
JBoyer: no, I mean log entries that are not logged by apache when using syslog, at least in the way that we are using syslog. |
| 14:56 |
jeff |
JBoyer: i'd have to go back and find specific examples. none offhand. |
| 14:57 |
|
rlefaive joined #evergreen |
| 14:57 |
jeff |
i think it was related to errors/warnings and you needing to give up some things with a syslog destination vs piped logging vs traditional file based logging. |
| 14:57 |
JBoyer |
I see. |
| 14:58 |
Dyrcona |
jeff: I recall something like that, but I thought I had found them in /var/log/apache on the server and not in syslog. |
| 14:58 |
Dyrcona |
It has also been a while since I last looked. |
| 15:00 |
Dyrcona |
Fuzzy logic for fuzzy sweaters.... Sorry..... |
| 15:00 |
berick |
my last recollection here was that piped logging to syslog from apache would allow all things to be captured, but using "ErrorLog syslog:local7" (or whatever) would drop stuff |
| 15:01 |
jeff |
looking at this again, it might simply be this -- but i think there may have been more to it: "When logging to a regular file, messages of the level notice cannot be suppressed and thus are always logged. However, this doesn't apply when logging is done using syslog." |
| 15:02 |
jeff |
berick: yes, i can't recall if the only downside i found to piping ErrorLog was "not the recommended default" or if there was another limitation. |
| 15:02 |
jeff |
another thread to pull at. |
| 15:02 |
jeff |
on this particular issue, i don't seem to have left myself anything in the way of useful (and searchable) notes. |
| 15:02 |
JBoyer |
This shirt is going to be Cthulu cosplay soon. |
| 15:02 |
Dyrcona |
heh. |
| 15:03 |
|
mmorgan1 joined #evergreen |
| 15:03 |
Dyrcona |
"Hey, there, Cthulhu. What's it like in Deep R'lyeh?" |
| 15:03 |
Dyrcona |
Yeah, what berick and jeff are saying rings a bell or two. |
| 15:04 |
Dyrcona |
IIRC, MVLC is piping to syslog from Apache because of that. |
| 15:05 |
Stompro |
Question about 2.10.5 placing holds on parts. The Parts dropdown now says "- All Parts -" by default. I had a staff member that was testing it out say "Awsome, I can request all parts at once, so I don't have to place multiple holds to get one of each part". But All Parts actually means Any Part, right? |
| 15:05 |
|
hbrennan joined #evergreen |
| 15:05 |
berick |
Stompro: right, any part |
| 15:05 |
berick |
it's still just 1 hold |
| 15:06 |
Stompro |
berick, Thanks for the confirmation. |
| 15:07 |
bshum |
parts-- |
| 15:07 |
bshum |
Just because |
| 15:08 |
bshum |
Boy that felt good :) |
| 15:15 |
kmlussier |
Stompro / berick: "All parts" means any copy that does not have a part assigned to it, which is a little different than any part. |
| 15:16 |
kmlussier |
Any part would mean the hold could target copy, no matter what part is assigned. |
| 15:17 |
kmlussier |
In our case, the "all parts" label makes sense because the copies that don't have an assigned part are ones that have not been broken up into parts. IOW, the entire set. But I understand people handle this differently in other places. |
| 15:22 |
|
collum_ joined #evergreen |
| 15:24 |
Stompro |
kmlussier, hmmm, thanks for the clarification. That might cause problems for us. I don't think we have records with some parts and some without parts, except for mistakes. |
| 15:25 |
kmlussier |
Stompro: If a record only has parted items, the 'all parts' option doesn't display. But, you're right, it could cause problems if you have some mistakes. |
| 15:25 |
berick |
kmlussier++ |
| 15:25 |
berick |
apologies for the misleading answer |
| 15:25 |
kmlussier |
It basically is a title-level hold when the All Parts option is selected. |
| 15:28 |
Stompro |
kmlussier++ thanks again... yep, there is one mistake witout a part on the record I was looking at. We look for those to fix them so this won't be a problem. |
| 15:35 |
miker |
JBoyer: non-default PREFIX and SYSCONFDIR work great for us, fwiw. what I'd really like is configure-time way to tell the perl install stuff to stick the modules in a location of my choosing |
| 15:36 |
jeff |
and for that i like local::lib, though i've not tried to use it for an entire evergreen install. |
| 15:37 |
JBoyer |
miker, Good to hear, I knew others had it working but I was only toying with it on a VM of likely questionable lineage. I also think being able to put the pm's where they "belong" is a good goal. |
| 15:40 |
Dyrcona |
For the things installed from source, keeping it all together under $PREFIX would be suitable for me. |
| 15:40 |
Dyrcona |
But others would have other ideas..... |
| 15:41 |
* Dyrcona |
doesn't think it should be too hard to do with configure. |
| 15:41 |
Dyrcona |
PERL5LIB would need to be set at runtime though. |
| 15:42 |
Dyrcona |
Unless you messed with the system default paths. |
| 16:24 |
|
rlefaive joined #evergreen |
| 16:39 |
|
mmorgan joined #evergreen |
| 16:50 |
Dyrcona |
csharp++ # Going through old bugs. |
| 16:50 |
* Dyrcona |
wonders how many of those are still valid. |
| 17:04 |
kmlussier |
Dyrcona: It looks like csharp checked a few of those to see if they were still valid. He even moved a few over to Incomplete. |
| 17:04 |
kmlussier |
progress |
| 17:06 |
csharp |
okay - I've cleared series-targeted bugs through 2.7 - gonna leave 2.8 and newer alone for now, FYI |
| 17:09 |
kmlussier |
csharp++ |
| 17:09 |
mmorgan |
csharp++ |
| 17:11 |
|
mmorgan left #evergreen |
| 17:17 |
Dyrcona |
Yeah. I didn't read all of the emails with the same scrutiny. |
| 17:19 |
jeff |
berick: okay, from what i can tell based on some experimentation and trying to refresh my memory: the specific thing that is lost with Apache ErrorLog going to syslog is stderr. Directing ErrorLog to a pipe fixes this but does introduce some other changes (which i can probably figure out). |
| 17:21 |
berick |
jeff: ok, that's about what I was expecting. couldn't remember whether it caused other changes or not, though. |
| 17:22 |
jeff |
with "LogLevel info", changing from ErrorLog syslog:local7 to ErrorLog "|/usr/bin/logger -p local7.info" results in a loss of at least one message -- [mpm_prefork:notice] [pid 2121] AH00169: caught SIGTERM, shutting down |
| 17:22 |
jeff |
and that might be explained by the syslog config. |
| 17:23 |
jeff |
(it also does expected things like change the process name from apache2 to logger, etc.) |
| 17:24 |
csharp |
kmlussier: on bug 1611815, looks like you changed the wrong "Activate" in holds.tt2 - you changed the option in the dropdown menu when I think you meant to change the column heading |
| 17:24 |
pinesol_green |
Launchpad bug 1611815 in Evergreen "use "Active On" rather than "Activate" as header in TPAC holds tables" [Low,Confirmed] https://launchpad.net/bugs/1611815 |
| 17:24 |
kmlussier |
Bah! |
| 17:25 |
kmlussier |
csharp: OK, I'll remove the pullrequest on that and fix it up once I'm done doing what I'm doing. |
| 17:25 |
csharp |
hold_history.tt2 looks correct though |
| 17:25 |
kmlussier |
Oh, I didn't have a pullrequest tag. |
| 17:25 |
kmlussier |
heh |
| 17:26 |
csharp |
I was just reviewing 2.10 bugs |
| 17:26 |
kmlussier |
csharp: Thanks for looking! |
| 17:28 |
* kmlussier |
also needs to finish up bug 1612274 |
| 17:28 |
pinesol_green |
Launchpad bug 1612274 in Evergreen "Improvements to My Account Holds Screens" [Wishlist,New] https://launchpad.net/bugs/1612274 - Assigned to Kathy Lussier (klussier) |
| 17:31 |
Dyrcona |
All right. Dinner is ready. I'm signing out. |
| 17:45 |
|
collum joined #evergreen |
| 18:19 |
jwoodard |
does anyone have mkSolutions self check machines? |
| 18:23 |
csharp |
jwoodard: I haven't heard of any of our libraries using those, fwiw |
| 18:28 |
|
tarac_ joined #evergreen |
| 18:29 |
jwoodard |
I am trying to find evergreen libraries that have them but no luck so far. |
| 18:29 |
jwoodard |
most people I talk to use either 3M or techlogic |
| 21:17 |
|
sandbergja joined #evergreen |
| 21:25 |
|
sandbergja joined #evergreen |
