| Time |
Nick |
Message |
| 00:36 |
|
mtcarlson_away joined #evergreen |
| 00:37 |
|
chatley joined #evergreen |
| 00:39 |
|
b_bonner_ joined #evergreen |
| 01:03 |
|
StomproJ joined #evergreen |
| 05:18 |
pinesol_green |
Incoming from qatests: Test Success - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 07:57 |
|
rjackson-isl joined #evergreen |
| 07:57 |
|
Dyrcona joined #evergreen |
| 07:59 |
|
mrpeters joined #evergreen |
| 08:04 |
|
Dyrcona joined #evergreen |
| 08:05 |
|
collum joined #evergreen |
| 08:05 |
|
jeff_ joined #evergreen |
| 08:05 |
|
pmurray joined #evergreen |
| 08:13 |
Dyrcona |
bshum: When you have a chance, I think we should discuss lp 134227 and lp 1366964 as they relate to the 2.7 release. |
| 08:13 |
pinesol_green |
Launchpad bug 134227 in casper (Ubuntu) "restricted-manager still has autostart file" (affected: 0, heat: 2) [Undecided,Fix released] https://launchpad.net/bugs/134227 |
| 08:13 |
pinesol_green |
Launchpad bug 1366964 in Evergreen "Transaction Issues with libdbi 0.9.0" (affected: 1, heat: 6) [Undecided,New] https://launchpad.net/bugs/1366964 |
| 08:13 |
Dyrcona |
oops. |
| 08:13 |
Dyrcona |
lp 1342227 |
| 08:13 |
pinesol_green |
Launchpad bug 1342227 in Evergreen "Setting up EDI Fails with Ruby version > 1.8" (affected: 1, heat: 6) [Undecided,New] https://launchpad.net/bugs/1342227 |
| 08:15 |
Dyrcona |
After getting a later, I realize I said nothing in channel yesterday. |
| 08:17 |
Dyrcona |
eeevil: You might want to have a look at lp 1359762. I added logs and other details about what happens on our server when we get gobs of Internal Server Errors. |
| 08:17 |
pinesol_green |
Launchpad bug 1359762 in Evergreen "Internal Server Error Doing Keyword Basic Search for ISBN" (affected: 1, heat: 6) [Undecided,New] https://launchpad.net/bugs/1359762 |
| 08:21 |
|
krvmga joined #evergreen |
| 08:21 |
|
akilsdonk joined #evergreen |
| 08:22 |
|
akilsdonk joined #evergreen |
| 08:25 |
eeevil |
Dyrcona: I was actually looking at lp 1366964 ... the workaround is simple enough -- use 0.8.3 -- and the fix (if you're right about the new transaction handling, and I suspect you are) is libdbi-version dependent. there's a chance we might have to require the new version, if it's not a bug of ours but a true behavioral change. I haven't checked what jessie delivers yet, but (IMO) that would be important to consider |
| 08:25 |
pinesol_green |
Launchpad bug 1366964 in Evergreen "Transaction Issues with libdbi 0.9.0" (affected: 1, heat: 6) [Undecided,New] https://launchpad.net/bugs/1366964 |
| 08:27 |
|
dreuther_ joined #evergreen |
| 08:27 |
eeevil |
Dyrcona: do you feel like doing some spelunking? |
| 08:27 |
eeevil |
re 1359762 I mean |
| 08:28 |
|
ktomita joined #evergreen |
| 08:29 |
krvmga |
if i do an search in the cwmars catalog for author: robin williams DVD Blu-Ray All C/W MARS limit to available, i get that 3 of 18 copies are available. |
| 08:29 |
krvmga |
this is, i think, good. |
| 08:29 |
krvmga |
if i do the same search but limit the search to Amherst Jones library, i still get the 3 of 18 copies available but it also shows that there are 0 of 1 copy available at Amherst. |
| 08:30 |
krvmga |
is this the correct behavior if i have "limit to available" checked? |
| 08:30 |
krvmga |
is this just informational? in other words, your library does own a copy. |
| 08:30 |
csharp |
eeevil: if you have a second, would you be willing to eyeball this explain analyze output?: http://paste.evergreen-ils.org/23 - it's doing a seq scan rather than using the by_heading index and I was wondering how I need to configure things so the index is used |
| 08:31 |
krvmga |
or should that 0 of 1 copy not be showing up at all? |
| 08:32 |
eeevil |
csharp: looking |
| 08:32 |
csharp |
krvmga: this is ringing a bell for me, but I don't remember how PINES handle(d|s) that |
| 08:32 |
csharp |
eeevil: much appreciated |
| 08:33 |
krvmga |
csharp: this was reported to me as a bug but i thought it might not be. |
| 08:33 |
Dyrcona |
eeevil: I actually don't think using 0.8.3 is a very useful solution. Seems more of a cop out, really. |
| 08:34 |
csharp |
krvmga: yeah - it was throwing our staff when we first moved to TPAC, but it hasn't come up lately and I don't remember what the explanation was. When a couple of my colleagues get in, I'll ask them if you want |
| 08:34 |
Dyrcona |
eeevil: I would do some spelunking, but probably won't have the time unless I can impress upon the power that be here how important this is. |
| 08:35 |
krvmga |
csharp: thanks much :) |
| 08:35 |
eeevil |
Dyrcona: if the api changed (in a behavioral way) then I wouldn't call it a cop out. if we're using it wrong, I would agree with you. |
| 08:36 |
Dyrcona |
eeevil: I think we should adjust to the new API, because more distros are going to package the newer version in the near future. |
| 08:36 |
eeevil |
and, re spelunking, it might require jacking up the logging level to see what the last thing that happens is before a cstore backend disappears |
| 08:36 |
Dyrcona |
This will, I am certain, also affect Debian Jessie. |
| 08:36 |
StomproJ |
dbs: thanks for the tip on using "git log --follow" to find the history of moved files. |
| 08:36 |
Dyrcona |
eeevil: Ok, but in production, where this happens, we'll run out of disk space in a hurry. |
| 08:37 |
Dyrcona |
eeevil: I can't seem to duplicate it on a dev environment even if I try. |
| 08:37 |
Dyrcona |
Right now, it looks like the drone is exiting normally, i.e. I have no evidence of it crashing. |
| 08:38 |
eeevil |
Dyrcona: boo. well, short of that, is there anything in the osrf_sys log right before ejabberd notices the disconnection? in your first example, around 01:16? I'm curious if there's /any/ sign (even "normal" stuff) of the backend doing work |
| 08:39 |
Dyrcona |
Yeah: at 01:16:04 it processed a message. At 01:16:23 it disconnected from ejabberd. At 01:53 the not connected to network starts. |
| 08:39 |
Dyrcona |
No sign of the drone between 01:16:04 and 01:16:23 in the logs AFAICT. |
| 08:40 |
|
mmorgan joined #evergreen |
| 08:42 |
eeevil |
Dyrcona: could you get the full history of thread trace 140980411420299132 from all the logs? activity.log, osrf_*.log ... maybe we can see what the last call was at or around 01:16:04 |
| 08:56 |
|
jwoodard joined #evergreen |
| 08:59 |
|
jboyer_isl joined #evergreen |
| 09:09 |
eeevil |
csharp: hrm... I wonder if it's ye olde text_patter_ops? what's 1) your database's local and 2) the definition of the index according to \d authority.record_entry |
| 09:12 |
Dyrcona |
eeevil: I'll have to see if I can get that information later. |
| 09:18 |
csharp |
eeevil: 'show lc_collate' = 'C' - I'll pastebin the index definition in a second |
| 09:19 |
pastebot |
"csharp" at 64.57.241.14 pasted "\d authority.record_entry" (50 lines) at http://paste.evergreen-ils.org/24 |
| 09:19 |
csharp |
eeevil: ^^ |
| 09:26 |
|
Shae joined #evergreen |
| 09:26 |
eeevil |
csharp: as a quick test, you could try EXPLAINing the query after replacing "like" with ">=" |
| 09:27 |
csharp |
sure thing - just a sec |
| 09:28 |
csharp |
ERROR: argument of AND must be type boolean, not type tex |
| 09:29 |
pastebot |
"csharp" at 64.57.241.14 pasted "full explain output for eeevil" (3 lines) at http://paste.evergreen-ils.org/25 |
| 09:41 |
eeevil |
csharp: boo... well, I'd suggest adding a second text_pattern_ops index (create concurrently) to test |
| 09:41 |
eeevil |
and now I must run away |
| 09:41 |
csharp |
eeevil: thanks! |
| 09:54 |
|
yboston joined #evergreen |
| 10:00 |
dbwells |
csharp: I think what you are seeing is a side effect of the secondary changes on bug #1253163. |
| 10:00 |
pinesol_green |
Launchpad bug 1253163 in Evergreen "authority indexes can fail on Postgres 9.3.0" (affected: 3, heat: 20) [Critical,Fix released] https://launchpad.net/bugs/1253163 |
| 10:00 |
|
kmlussier joined #evergreen |
| 10:00 |
dbwells |
Namely, changing those functions from IMMUTABLE to STRICT is making the planner too darn cautious. |
| 10:01 |
dbwells |
We made the change because the functions read config information, and are not therefore not /truly/ immutable. |
| 10:02 |
dbwells |
That said, changing them back to IMMUTABLE should be quite safe as a temporary fix. |
| 10:04 |
dbwells |
I am going to write the postgres list and see if they have any pointers. STABLE seems to never do what I think it should anymore. |
| 10:04 |
csharp |
dbwells: thanks, I was actually wondering about that |
| 10:05 |
csharp |
whether the IMMUTABLE/STRICT change had an impact - I recall a similar issue sometime back regarding patron lookups by email(?) |
| 10:05 |
dbwells |
I have found other people complaning, but the answer is always that STABLE means the planner can choose to run it only once, but it might also choose to run it for every row. In my recent experience, it chooses the second way too often. |
| 10:06 |
dbwells |
Maybe PG needs a new STABLER option which means "run this once per query, don't ask questions, I promise that will be fine" |
| 10:10 |
csharp |
:-) |
| 10:17 |
dbwells |
csharp: If you look at the upgrade script in commit e26298ac24efd59, you can see the ALTER FUNCTION calls. Just change the end of each to IMMUTABLE to change them back. |
| 10:17 |
csharp |
cool - I'll try that |
| 10:17 |
dbwells |
csharp: I'd probably start with just ALTER FUNCTION authority.simple_normalize_heading(TEXT) IMMUTABLE; and see where that gets you. |
| 10:18 |
csharp |
dbwells++ # that did it |
| 10:18 |
csharp |
instant validation results |
| 10:19 |
csharp |
okay, now to muster up the courage to move around the C binaries on our prod servers ;-) |
| 10:19 |
dbwells |
It makes me both happy and sad to hear that :) |
| 10:19 |
dbwells |
That it worked, that is. |
| 10:22 |
tsbere |
Given that "IMMUTABLE" = "I don't need the DB and just pay attention to my arguments" while "STABLE" = "I don't *change* the DB, but may read it", any statement that is changing the DB (or involves volatile functions that could change the DB) would likely result in a "keep re-running the function in case the things it is (possibly) reading change" in the planner |
| 10:22 |
dbwells |
The other sometimes suggested workaround is to wrap the offending function in a subselect, but that isn't friendly to our JSON grammar queries :( |
| 10:25 |
tsbere |
Oh, hey, and now I see a contradiction to the "stable re-runs in case the data changed" theory I first found. The official docs say only volatile functions see anything that changed, stable (and immutable) only see a snapshot. |
| 10:25 |
* tsbere |
gives up trying to figure it out for now |
| 10:43 |
eeevil |
dbwells: if you've been seeing it choose run-once or run-every-time in different situations, we could try upping the cost of the function a lot to suggest it ought only run the function once |
| 10:43 |
eeevil |
immutable is actually dangerous in some situations, when you do read the db, and we should really try to avoid lying to PG if we can avoid it |
| 10:44 |
dbwells |
eeevil: Right. That whole bug seemed to be caused by the lie, which is why we tacked on that change in the first place :) |
| 10:45 |
dbwells |
eeevil: I did briefly try upping the cost, but didn't see any difference. I think I stopped at 100000. I don't have enough experience to know if that is "high", but it was at least higher than the default of (I think) 100. |
| 10:47 |
eeevil |
dbwells: yeah, I don't know if that's enough or not ... /me looks at the explain again |
| 10:47 |
jboyer_isl |
dwells, weevil: I’m just plain guessing, but is it possible that a vacuum analyze on the config tables may help the Qplanner realize they don’t change often? |
| 10:47 |
dbwells |
I've never posted to the PG lists, but I have a test case worked up which I think isolates the issue. We can see what they say over there. |
| 10:48 |
dbs |
dbwells: RhodiumToad is right over in #postgresql |
| 10:49 |
dbs |
RhodiumToad is like the collective wisdom of all PostgreSQL hackers combined |
| 10:49 |
eeevil |
dbwells: in csharp's example, it seems like it should be high enough... total cost is ~630000 |
| 10:49 |
dbs |
but a post to the mailing list carries more weight vs. the immediacy of IRC, and test cases are golden |
| 10:51 |
dbwells |
dbs: Thanks for the tip! I'll probably still start with the list if only due to general timidity. I still find it hard enough to speak up in #evergreen. :) |
| 10:53 |
* dbwells |
needs to re-steel himself daily |
| 10:53 |
dbs |
dbwells++ |
| 10:54 |
|
ericar joined #evergreen |
| 11:26 |
dbwells |
Thread is away: http://www.postgresql.org/message-id/ed527d86dc3c4e7aa35e29159afaf00e@CO2PR06MB588.namprd06.prod.outlook.com |
| 11:34 |
berick |
dbwells++ |
| 11:35 |
* berick |
actually understood all of that sans context |
| 11:47 |
jboyer_isl |
kmlussier: I’m looking into the release notes thing, would this be better put in _2_7 or _NEXT ? |
| 11:48 |
kmlussier |
jboyer-isl: In next. I was thinking it looked like a new feature, so it probably wouldn't make 2.7. But I guess bshum could make the final call on that. |
| 11:48 |
jboyer_isl |
Sounds good to me. |
| 11:52 |
gmcharlt |
heads-up - there is going to be downtime for git.evergreen-ils.org at about 6 p.m. tonight for a VM move |
| 11:54 |
csharp |
tom_lane++ |
| 12:00 |
dbs |
good old CTE optimization fences |
| 12:15 |
dbwells |
Funny thing is, in the real code we are trying to use the function call for an index scan, and it *still* doesn't fall on the side of the fence we want. So, who wants to write the SUPERSTABLE patch for PG? ;) |
| 12:15 |
|
nhilton joined #evergreen |
| 12:25 |
|
jihpringle joined #evergreen |
| 12:57 |
|
buzzy joined #evergreen |
| 13:20 |
kmlussier |
launchpad-- |
| 13:20 |
* kmlussier |
really wishes she could edit her own comments. |
| 13:29 |
dbs |
kmlussier: we could move to G+ as a bug tracking platform |
| 13:30 |
kmlussier |
dbs: That could be...interesting? |
| 13:33 |
berick |
google_remote_desktop++ |
| 13:33 |
berick |
speaking of the Goog.. |
| 13:34 |
berick |
closing the gap on remote desktop support for Linux |
| 13:36 |
Dyrcona |
ssh and X forwarding doesn't work for you? ;) |
| 13:37 |
jcamins |
Dyrcona: berick uses Wayland. Unfortunately for him, no one else does. |
| 13:37 |
Dyrcona |
:) |
| 13:37 |
* phasefx |
uses screen :) |
| 13:38 |
Dyrcona |
I've been meaning to try Wayland. |
| 13:38 |
* jcamins |
switched to tmux. |
| 13:38 |
* Dyrcona |
uses tmux. |
| 13:38 |
phasefx |
is it much better? |
| 13:38 |
jcamins |
I got fed up with UTF-8 randomly breaking under screen. |
| 13:38 |
jcamins |
Speaking of which, this is a new server. Did I configure UTF-8 for irssi? |
| 13:39 |
phasefx |
what I'd be interested in is xmonad key bindings and behavior for something like screen/tmux |
| 13:39 |
jcamins |
phasefx: you could do that, I think. |
| 13:41 |
berick |
arg, not desktop support..thiking more about a replacement for join.me and other linux-unfriendly webinar-y stuff. |
| 13:44 |
Dyrcona |
I wouldn't say tmux is better, but it has some features I like, such as the green status bar at the bottom. It makes it easier to track which "window" you're in and how many you have open. |
| 13:46 |
* Dyrcona |
wonders what happened to his one o'clock conference call. |
| 13:47 |
* dbs |
wonders what happened to the lunch he planned to have |
| 13:47 |
Dyrcona |
Anyway.... |
| 13:47 |
Dyrcona |
dbs: I ate it. |
| 13:48 |
Dyrcona |
It was good, too. Do you like souvlaki? |
| 13:48 |
* dbs |
shakes fist at the betrayal, after having shared Mother Mother with you too |
| 13:48 |
gmcharlt |
dbwells: any reason not to promote the 2.6.3 and 2.5.7 releases from preview to production? |
| 13:48 |
* berick |
likes the album Souvlaki |
| 13:49 |
gmcharlt |
at the moment, I either have a fix pushed that could go into those releases, or it's time to make the LP milestones for the next releases in the 2.5 and 2.6 series |
| 13:49 |
Dyrcona |
dbs++ For sharing Mother Mother. I spent the rest of that evening watching most of their videos on Youtube. |
| 13:50 |
jcamins |
Dyrcona: the person you have your call with forgot the timezone difference? |
| 13:50 |
|
dreuther joined #evergreen |
| 13:50 |
dbwells |
gmcharlt: Is the fix something which can reasonably wait? |
| 13:50 |
gmcharlt |
dbwells: yes |
| 13:50 |
Dyrcona |
jcamins: It could be. One of them is in California, but it was the person on the East Coast who told me one o'clock. |
| 13:52 |
dbs |
Ah that marvelous feeling when you discover that your action_trigger_runner wasn't running due to an old lockfile. For a month. |
| 13:53 |
Dyrcona |
Ouch! A whole month. |
| 13:53 |
|
nhilton_ joined #evergreen |
| 13:53 |
dbs |
Yeah, isn't that grand. |
| 13:54 |
dbs |
We have nice auto-cleanup-on-restart processes in place now, but didn't then. Obviously. |
| 13:55 |
dbwells |
gmcharlt: Okay, I'll go ahead and shuffle the milestones in a bit. |
| 13:55 |
gmcharlt |
dbwells: if you want, I can close out the milestones for you |
| 13:57 |
dbwells |
gmcharlt: please, feel free. Thanks! |
| 14:02 |
|
nhilton joined #evergreen |
| 14:04 |
|
dreuther_ joined #evergreen |
| 14:06 |
|
dreuther_ joined #evergreen |
| 14:14 |
|
dreuther joined #evergreen |
| 14:17 |
|
dreuther_ joined #evergreen |
| 14:18 |
gmcharlt |
dbwells: I've finished dealing with the milestones |
| 14:23 |
|
dreuther joined #evergreen |
| 14:23 |
jboyer_isl |
kmlussier: git hates me, so I’ve managed to finally get a relnotes file up at collab/jboyer/lp1366026_relnote |
| 14:25 |
kmlussier |
jboyer-isl: git hates me too. I empathize. |
| 14:26 |
kmlussier |
It's the time of the month when I normally schedule a dev meeting. Actually, it's a week late. Should I try to schedule something for next week? Or should we skip it since the hack-a-way is coming up. |
| 14:27 |
kmlussier |
Of course, it might be an opportunity to plan for the hack-a-way. |
| 14:28 |
kmlussier |
Can somebody remind me what the dates are for the hack-a-way so that I can add it to the calendar? |
| 14:28 |
berick |
kmlussier: sept. 24-26 |
| 14:29 |
kmlussier |
berick: Thanks! |
| 14:32 |
krvmga |
csharp: i don't mean to be a pest but did you have a chance to talk to any colleagues about the "limit to available"? |
| 14:37 |
kmlussier |
krvmga: I'm having trouble replicating what you found earlier. If I do a "limit to available" search scoped to Jones library, I'm only retrieving results that are available in Amherst. What am I missing? |
| 14:38 |
krvmga |
kmlussier: when i do the search, it shows 0 of 1 copies available at Amherst and 0 of 1 copies available at Amherst Jones. |
| 14:38 |
kmlussier |
krvmga: Link? |
| 14:40 |
kmlussier |
krvmga: Oh, wait. I see now. On my first try, I was limiting from the search results screen. |
| 14:42 |
kmlussier |
krvmga: It only seems to happen when you select multiple formats? Is that what you're finding? |
| 14:43 |
krvmga |
kmlussier: that seems to be the case. |
| 14:43 |
* kmlussier |
checks something else |
| 14:47 |
kmlussier |
krvmga: It only seems to happen with multiple search filter groups. |
| 14:47 |
kmlussier |
If I search MVLC's catalog and use multiple item types, I don't see the problem. |
| 14:48 |
krvmga |
kmlussier: you think it's tied to our customization somehow? |
| 14:48 |
kmlussier |
So I would say it is indeed a bug, since the behavior is different when you select multiple search filter groups. On the other hand, when you upgrade to 2.6, you might want to use the MVF-based formats on your advanced search page. |
| 14:49 |
kmlussier |
krvmga: It's tied to the fact that you use search filter groups for your format filters, yes. |
| 14:53 |
eeevil |
that sounds like it could be the query construction order issue from long ago if it's always with a modifier (like #available). if so, arguably a bug in QP, but possibly addressable in the tpac. IMO, teaching the tpac to use the floating subquery syntax would be a step in the right direction. there is a basic description here in the first comment: https://bugs.launchpad.net/evergreen/+bug/1310751 |
| 14:53 |
pinesol_green |
Launchpad bug 1310751 in Evergreen "certain queries can break Group by Formats and Editions feature" (affected: 4, heat: 18) [Undecided,Confirmed] |
| 14:55 |
eeevil |
krvmga: essentially, you can get it to ignore #available, is that right? |
| 14:58 |
krvmga |
eeevil: yes, that seems to be right. |
| 14:58 |
|
nhilton_ joined #evergreen |
| 14:59 |
csharp |
krvmga: sounds like you're on the right track - a basic search with "limit to available" checked *does* hide the "0 of 1" listings, but we aren't using search groups |
| 15:09 |
csharp |
looking at bug 1297967 and wondering what the best approach is to scripting/otherwise cleaning up installation of the ruby bits |
| 15:09 |
pinesol_green |
Launchpad bug 1297967 in Evergreen "document openils-mapper code for enriched EDI" (affected: 1, heat: 6) [Undecided,New] https://launchpad.net/bugs/1297967 |
| 15:09 |
tsbere |
csharp: Perhaps the best approach is to re-write them in something other than ruby? ;) |
| 15:10 |
csharp |
the "install.sh" file that runs through the ruby deps then ruby gems installation pulls in openils-mapper, then we need to copy over files from berick's forked repo |
| 15:10 |
csharp |
tsbere: no objections here, but this is a bit beyond my chops ;-) |
| 15:10 |
* csharp |
wonders what would be required to have berick's work accepted upstream |
| 15:11 |
csharp |
this appears to be an EG-specific gem |
| 15:12 |
csharp |
huh - and berick's work is 2+ years old |
| 15:13 |
csharp |
ruby-- |
| 15:14 |
csharp |
bshum: are you using berick's fork in production? |
| 15:15 |
csharp |
@monologue |
| 15:15 |
pinesol_green |
csharp: Your current monologue is at least 8 lines long. |
| 15:15 |
kmlussier |
csharp: I think Dyrcona is. |
| 15:16 |
csharp |
I don't mind contacting mbklein about accepting the code, but I have nothing to do with it ;-) |
| 15:20 |
pinesol_green |
[evergreen|Josh Stompro] Docs: update to 'Address Alerts' feature content - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=d86f470> |
| 15:22 |
bshum |
csharp: Yes, we are |
| 15:22 |
bshum |
And yes, I talked to mbklein |
| 15:23 |
bshum |
And he told me the code is basically abandoned at this point |
| 15:23 |
bshum |
He didn't remember working on it much actually. |
| 15:23 |
csharp |
ah - gotcha |
| 15:24 |
bshum |
I was wondering about changing the script to just install from berick's source |
| 15:24 |
bshum |
Or we host his and call that the new master :) |
| 15:25 |
bshum |
At this point I don't know if anyone else is even using it |
| 15:26 |
csharp |
mbklein says he's willing to hand ownership to someone over on our end |
| 15:26 |
|
berick joined #evergreen |
| 15:26 |
csharp |
so, anyone want to be the maintainer for openils-mapper? :-D |
| 15:27 |
csharp |
berick: we were just discussing your openils-mapper bits to enable enriched EDI and I'm interested in what it would take to get your changes upstream |
| 15:28 |
csharp |
mbklein is saying he doesn't have anything invested in it any more and is willing to hand it over to anyone who wants ownership ;-) |
| 15:28 |
berick |
for starters, I could push enriched stuff into my master branch |
| 15:28 |
berick |
and we could just use my master branch in the install docs |
| 15:28 |
csharp |
yeah, that works |
| 15:28 |
berick |
oh, wait, arg |
| 15:29 |
berick |
didn't do that before because I don't know how to do the ruby distribution stuff |
| 15:29 |
csharp |
ah - I figured there was a piece like that involved |
| 15:29 |
berick |
so we need to figure out what mbklien did to get his stuff distributed |
| 15:30 |
* csharp |
peruses http://guides.rubygems.org/publishing/ |
| 15:31 |
csharp |
actually, that looks pretty simple |
| 15:32 |
csharp |
http://guides.rubygems.org/command-reference/#gem-owner |
| 15:33 |
csharp |
berick: so maybe mbklein could make you an owner of the gem? (not trying to add to your to-do, just thinking of simple ways to git er done ;-)) |
| 15:34 |
berick |
csharp: sounds like a good start |
| 15:34 |
csharp |
berick++ |
| 15:36 |
berick |
that does look easy |
| 15:36 |
Dyrcona |
Yeah, I am using berick's code in production. |
| 15:36 |
Dyrcona |
I'd much rather see the ruby go away. |
| 15:36 |
berick |
once it's shared and I get a few mins, i'll gem-ify it |
| 15:36 |
berick |
Dyrcona: +1 to that |
| 15:37 |
Dyrcona |
Yesterday and today have been kind of crazy for me. Hopping from thing to thing. |
| 15:37 |
Dyrcona |
I wanted to discuss some bugs with bshum and their relation to 2.7 today. |
| 15:39 |
pinesol_green |
[evergreen|Josh Stompro] Docs: Updated usage of autogen.sh to not use param 'u' - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=bfc7eed> |
| 15:39 |
pinesol_green |
[evergreen|Josh Stompro] Docs: Fixed small typo in docs/reports/reporter_daemon.txt - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=7c1aea0> |
| 15:39 |
Dyrcona |
Reading the scrollback, It would be nice if we could get everything in the ruby to not require 1.8, at least. |
| 15:39 |
bshum |
Dyrcona: What's up? |
| 15:39 |
Dyrcona |
I don't know if that would be easier than just replacing it with Perl. |
| 15:39 |
bshum |
Sorry, juggling a few things. Coming back from vacation, sigh. I miss being on vacation already. :) |
| 15:40 |
Dyrcona |
Vacation? What is that? :) |
| 15:40 |
Dyrcona |
As for what's up, I wanted to talk about the ruby issues on 14.04 and if that should be a stopper on 2.7 being released. |
| 15:41 |
Dyrcona |
Among a couple of other bugs. |
| 15:41 |
bshum |
Hmm |
| 15:42 |
Dyrcona |
Mainly, I'm concerned that I've found a few issues with Evergreen on Ubuntu 14.04, which may not be specific to just 14.04, and I'm concerned that we release 2.7 with 14.04 as a a target and then things don't work. |
| 15:46 |
Dyrcona |
On a more positive note, I'd also like to get your opinion on lp 1261791. I think it should be considered a bug and added to 2.7 if not also backported to 2.6. |
| 15:46 |
pinesol_green |
Launchpad bug 1261791 in Evergreen "no search box on catalog's account pages when viewed on screens smaller than 600px wide" (affected: 1, heat: 8) [Undecided,Triaged] https://launchpad.net/bugs/1261791 |
| 15:49 |
|
BigRig joined #evergreen |
| 15:55 |
|
_bott_ joined #evergreen |
| 16:03 |
|
cherri joined #evergreen |
| 16:07 |
|
_bott_ joined #evergreen |
| 16:12 |
|
berick joined #evergreen |
| 16:23 |
|
berick_ joined #evergreen |
| 16:25 |
|
_bott_ joined #evergreen |
| 16:42 |
Dyrcona |
Fun. Fun. Fun. |
| 16:47 |
|
cherri joined #evergreen |
| 16:52 |
|
_bott_ joined #evergreen |
| 16:56 |
|
hbrennan joined #evergreen |
| 17:00 |
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 |
hbrennan |
Patrons with max fines are being skipped in the holds queue. I'm looking in Standing Penalties and believe I just need to remove some items from the block_list.... |
| 17:01 |
hbrennan |
I would like patrons to be notified their hold is available (I'm guessing this is CAPTURE) and renew items they already have (RENEW) |
| 17:01 |
hbrennan |
But what is FULFILL? |
| 17:02 |
mmorgan |
hbrennan: You are corrrect that CAPTURE is the one to remove if you want the holds to be captured. |
| 17:02 |
phasefx |
hbrennan: if that's in a block list, it keeps the hold item from being checked out to the user |
| 17:03 |
phasefx |
FULFILL, that is |
| 17:03 |
hbrennan |
We definitely want to lure in patrons, so I'll remove CAPTURE. And we're nice so we'll let people place holds (HOLD) and renew items they already have our (RENEW) |
| 17:03 |
hbrennan |
phasefx: so Fulfill is specific to the holds? |
| 17:03 |
hbrennan |
phasefx: And CIRC wouldn't let them check out OTHER things? |
| 17:04 |
phasefx |
s/OTHER/ANY/ |
| 17:04 |
phasefx |
so yeah, CIRC stops all circulation |
| 17:04 |
hbrennan |
And FULFILL just stops the circulation of the captured hold |
| 17:05 |
phasefx |
oh no, I'm wrong.. if the circulation is for a hold, it looks like CIRC is ignored.. so it is OTHER things |
| 17:05 |
phasefx |
if I'm reading the code correctly |
| 17:06 |
hbrennan |
That is super fancy |
| 17:06 |
bshum |
@later tell Dyrcona Sigh, I didn't get to reply before you left, but I'll ponder things further. I'm generally fine with releasing 2.7.0 and adding a note about issues with Ubuntu 14.04, etc. as some sort of advisory while we work on fixing it. |
| 17:06 |
pinesol_green |
bshum: The operation succeeded. |
| 17:06 |
bshum |
That said, if people feel like that should be a blocker, I can always wait longer before I move things about. |
| 17:07 |
bshum |
I have to finish getting my head around the i18n dance first, so that gives us a bit more time to poke. |
| 17:12 |
|
mmorgan left #evergreen |
| 17:12 |
bshum |
As for bug 1261791, my opinion is to treat it as a bug that we should definitely merge in time for 2.7 (small feature with the new variable, but I'm willing to add it). As far as backporting to 2.6, I'll leave that to dbwells to help decide. |
| 17:12 |
pinesol_green |
Launchpad bug 1261791 in Evergreen "no search box on catalog's account pages when viewed on screens smaller than 600px wide" (affected: 1, heat: 8) [Undecided,Triaged] https://launchpad.net/bugs/1261791 |
| 17:13 |
hbrennan |
mmorgan++ phasefx++ Thanks for the help |
| 17:19 |
|
snigdha26 joined #evergreen |
| 17:20 |
kmlussier |
bshum: So that release notes entry about the color variable should really be added to the 2.7 release notes, right? |
| 17:20 |
bshum |
kmlussier: When we push it, yes. |
| 17:21 |
* kmlussier |
isn't sure how we communicate that kind of information for a point release if it is backported further. |
| 17:22 |
bshum |
kmlussier: I know that senator used to generate release notes for point releases too, but I don't think that's been consistent practice. |
| 17:22 |
kmlussier |
Maybe it's something we can talk about during a dev meeting at some point. I'm willing to help out on that front if I can. |
| 17:23 |
bshum |
Personally I'm content with just making sure we fix it for 2.7 since it's available right now and it's not too late to slip it in. But I worry about one release series at a time right now :) |
| 17:26 |
bshum |
I think senator hand linked release notes for point releases to also point back at earlier versions of the notes. |
| 17:26 |
bshum |
It looked complicated and consuming. |
| 17:27 |
kmlussier |
Sure. There have been a few people who have told me it would be useful to know which bugs were fixed in a given point release, so I think if there were a way to do it that's not complicated and consuming, it would be useful. |
| 17:29 |
bshum |
kmlussier: Well I always just read the changelogs, but I imagine people prefer slightly more friendly reading terms :) |
| 17:29 |
kmlussier |
The change log that's posted on the downloads page: does it just include changes since the last point release or does it show all changes since the .0 release? |
| 17:29 |
bshum |
The changelog file says what it contains |
| 17:29 |
bshum |
The name of it I mean |
| 17:29 |
kmlussier |
Ah! I wasn't looking there. |
| 17:30 |
bshum |
So, "ChangeLog-2.5.5-2.5.6" means all changes between 2.5.5 and 2.5.6 |
| 17:30 |
kmlussier |
Yeah, I figured it out once you pointed me in the right direction. :) |
| 17:30 |
bshum |
I used to read them more religiously when I was on release series |
| 17:31 |
|
berick joined #evergreen |
| 17:46 |
* bshum |
wanders home for now. |
| 18:33 |
|
kmlussier joined #evergreen |
| 18:48 |
hbrennan |
Losing my mind today.. Can someone verify that Evergreen PINs are just alphanumeric? No symbols allowed? |
| 18:48 |
hbrennan |
By Evergreen PINs I mean patron account PINs |
| 18:55 |
csharp |
hbrennan: you can control which characters are used with a regular expression in Admin -> Local Admin -> Library Settings Editor |
| 18:57 |
csharp |
the setting is named "Password format" - if there's nothing entered there, the passwords can be any character, any length (as far as I know) |
| 18:57 |
hbrennan |
Ahh, that's where it is |
| 18:57 |
hbrennan |
Thanks, csharp++ |
| 18:57 |
hbrennan |
I KNEW where it was, but I didn't |
| 18:58 |
hbrennan |
Our setting says ^.{4,} |
| 18:59 |
hbrennan |
So I'm assuming that means anything 4 or more characters, no limit, no restrictions |
| 18:59 |
csharp |
I think that's right |
| 19:00 |
hbrennan |
Good to know. First time setting up a third party authentication since moving to Evergreen so my brain is mushy in this area |
| 19:00 |
hbrennan |
Thanks! |
| 19:03 |
csharp |
happy to help! |
| 19:12 |
|
dcook joined #evergreen |
| 20:44 |
|
StomproJ joined #evergreen |
| 21:02 |
|
berick joined #evergreen |
| 22:09 |
|
mrpeters joined #evergreen |
| 22:09 |
|
mrpeters left #evergreen |
