| Time |
Nick |
Message |
| 01:37 |
|
Mark__T joined #evergreen |
| 05:17 |
pinesol_green |
Incoming from qatests: Test Success - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 07:56 |
|
jboyer-isl joined #evergreen |
| 07:56 |
|
rjackson_isl joined #evergreen |
| 08:00 |
|
collum joined #evergreen |
| 08:11 |
|
ericar joined #evergreen |
| 08:12 |
|
mrpeters joined #evergreen |
| 08:32 |
|
mmorgan joined #evergreen |
| 08:53 |
kmlussier |
TGIF #evergreen! |
| 08:54 |
|
Dyrcona joined #evergreen |
| 09:08 |
|
Mark__T joined #evergreen |
| 09:08 |
mmorgan |
TGIF Indeed! |
| 09:12 |
remingtron |
kmlussier: any idea if the 2.9 docs acknowledgements page has been updated? |
| 09:12 |
remingtron |
http://docs.evergreen-ils.org/2.9/_acknowledgments.html |
| 09:13 |
kmlussier |
remingtron: That's the most recent version of it. Did I miss somebody? |
| 09:13 |
remingtron |
kmlussier: not that I know of. I just hadn't thought about it at all, wanted to make sure someone did! |
| 09:13 |
remingtron |
kmlussier++ |
| 09:14 |
* kmlussier |
makes a note to revert the RELEASE_NOTES_NEXT acknowledgements file back to **To Do** |
| 09:14 |
kmlussier |
remingtron: OK, I see why you're asking. Yeah, you would have noticed if it was updated. The file usually just says To Do until it's updated. |
| 09:14 |
kmlussier |
s/was/wasn't |
| 09:15 |
remingtron |
kmlussier: that's good planning! |
| 09:15 |
kmlussier |
Yes! Good planning that somebody else thought up. :) |
| 09:16 |
remingtron |
kmlussier: We should add Mohawk College to the list somewhere, for hosting the docs server |
| 09:16 |
kmlussier |
We usually don't get to the acknowledgements until after the release notes file is generated. This is the first time we did it early enough to warrant cleaning up the template. |
| 09:16 |
remingtron |
it was just brought to my attention, so I can do it unless you'd like to |
| 09:17 |
|
maryj joined #evergreen |
| 09:19 |
kmlussier |
remingtron: hmmmm...I'm just thinking. It's a different type of acknowledgements, which means, if we include it, we might want to consider similar contributions in the community and acknowledge them equally. |
| 09:19 |
remingtron |
kmlussier: good point |
| 09:20 |
kmlussier |
If we're acknowledging the organization that hosts the docs server, do we also want to acknowledge the organization that hosts the server where our code lives? I'm assuming that's GPLS. |
| 09:21 |
remingtron |
yeah, there's a wiki page or two that list who hosts servers, listservs, etc. |
| 09:21 |
remingtron |
can't find it just now |
| 09:22 |
kmlussier |
I know the page you're talking about. It is indeed very difficult to find. |
| 09:23 |
kmlussier |
http://wiki.evergreen-ils.org/doku.php?id=website_administration |
| 09:23 |
remingtron |
yeah, I just searched for Chris Sharp and found that page too |
| 09:25 |
kmlussier |
I guess I see the release notes acknowledgements as a way to thank the people/organizations responsible for contributing the code, docs, tests that made a release happen. We could expand upon it, but there may be better places where we can acknowledge other contributions to the community. |
| 09:26 |
remingtron |
kmlussier: on the main website? |
| 09:26 |
kmlussier |
Yes, that seems appropriate. Because they are ongoing contributions. |
| 09:26 |
remingtron |
I agree, ongoing contributions are different than version contributions |
| 09:29 |
remingtron |
kmlussier: can you take this action to the web team? (you're on the web team, right?) |
| 09:30 |
kmlussier |
remingtron: I'm on the web team, but I don't think we have any meetings lined up on the calendar. |
| 09:31 |
kmlussier |
It's something I could add to our shared to-do list |
| 09:32 |
remingtron |
kmlussier: good enough for now, thanks |
| 09:32 |
kmlussier |
In the meantime, if it's something that somebody wanted to create on the WordPress site, I don't think it needs to be a member of the web team. There just might need to be a little communication ahead of time about the best place to put it. |
| 09:40 |
|
yboston joined #evergreen |
| 09:45 |
|
rangi joined #evergreen |
| 09:45 |
|
rangi joined #evergreen |
| 10:11 |
pinesol_green |
[evergreen|Kathy Lussier] Docs: Restoring the acknowledgements template - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=67f721b> |
| 10:13 |
csharp |
unfortunately, 2.8.4-2.9.0-upgrade-db.sql is still borked - more data vs. schema change conflicts :-/ |
| 10:13 |
Dyrcona |
csharp: LP bug? |
| 10:14 |
csharp |
Dyrcona: will do |
| 10:14 |
Bmagic |
@coffee |
| 10:14 |
* pinesol_green |
brews and pours a cup of Panama Geisha Aroma Roast, and sends it sliding down the bar to Bmagic |
| 10:15 |
kmlussier |
@coffee [someone] |
| 10:15 |
* pinesol_green |
brews and pours a cup of Sumatra Lake Tawar, and sends it sliding down the bar to jboyer-isl |
| 10:16 |
jboyer-isl |
Yay! Though I am utterly without coffee in this house. D: |
| 10:17 |
kmlussier |
jboyer-isl: Sorry! Can't help you there. |
| 10:18 |
jboyer-isl |
I will press on. |
| 10:19 |
csharp |
Dyrcona: https://bugs.launchpad.net/evergreen/+bug/1497307 |
| 10:19 |
pinesol_green |
Launchpad bug 1497307 in Evergreen "2.8.4-2.9.0 DB upgrade script fails due to data vs. schema changes" (affected: 1, heat: 6) [Undecided,New] |
| 10:38 |
Dyrcona |
Gonna unplug for a bit. I may drop off depending on how freenode responds to my chang in IP address. |
| 10:50 |
|
Dyrcona joined #evergreen |
| 11:03 |
|
Christineb joined #evergreen |
| 11:16 |
|
RoganH joined #evergreen |
| 11:22 |
|
rlefaive joined #evergreen |
| 11:31 |
Bmagic |
anyone have a quick trick to split shared addresses in the patron table (for everyone) ? |
| 11:32 |
bshum |
Bmagic: (for everyone) meaning.. no more shared addresses, period? |
| 11:32 |
Bmagic |
yep |
| 11:33 |
bshum |
Then, no, we've done that :( |
| 11:33 |
bshum |
I was just asking for clarity |
| 11:33 |
Bmagic |
I didnt want to reinvent the wheel. I was about to script it. |
| 11:34 |
jeff |
jboyer-isl may have done work in that area. |
| 11:34 |
jeff |
i don't recall. |
| 11:34 |
jboyer-isl |
Bmagic: I posted a script somewhere and referenced it in a bug on launchpad, but I don’t think I kept it handy since we ran if after turning the “cloned accounts get their own addresses” setting. |
| 11:35 |
berick |
anyone opposed to me adding "privacy" as an official tag in LP? |
| 11:35 |
jboyer-isl |
I believe the bug is still open, because the actual concerns were never addressed since that setting was enough of a “fix” for most people. |
| 11:35 |
jeff |
berick: do it. |
| 11:35 |
berick |
jeff: done |
| 11:35 |
mmorgan |
berick++ |
| 11:37 |
bshum |
berick: I also made it an actual official tag so that it'll add it as an auto-suggested value in LP |
| 11:38 |
Bmagic |
jboyer-isl: thanks |
| 11:38 |
berick |
bshum: oh, i thought that's what I was doing |
| 11:39 |
jboyer-isl |
Bmagic: Ah, here it is: lp 885270 |
| 11:39 |
pinesol_green |
Launchpad bug 885270 in Evergreen "Delete User Aborts on Shared Address" (affected: 6, heat: 30) [Medium,Confirmed] https://launchpad.net/bugs/885270 |
| 11:40 |
bshum |
berick: Yeah I'm not too sure who all has control of the "manage official tags" section of the bug tracker |
| 11:40 |
bshum |
I know I can |
| 11:40 |
bshum |
berick: https://bugs.launchpad.net/evergreen/+manage-official-tags (let's see if you can!) |
| 11:40 |
Bmagic |
jboyer-isl: oh thanks! |
| 11:40 |
berick |
bshum: i admit, i tried it several times and i didn't work. it sure let me think i was doign it. when it did finally work, it might have been you doing it :) |
| 11:40 |
berick |
so, thanks :) |
| 11:41 |
bshum |
Heh, okay |
| 11:43 |
bshum |
I'm going to move one of these to the "offical list" too. |
| 11:43 |
bshum |
Which is right? "needstest" or "needstests" :) |
| 11:43 |
bshum |
Probably the first one |
| 11:43 |
|
bmills joined #evergreen |
| 11:45 |
* bshum |
went with the first one |
| 11:46 |
jeff |
needsfoodbadly |
| 11:46 |
mmorgan |
needscoffee |
| 11:52 |
* mmorgan |
wanted to bounce something permission-y off whatever ears might be around. |
| 11:53 |
mmorgan |
The permission SET_CIRC_CLAIMS_RETURNED looks at the checkout library. So if my staff user permission is set at the branch or system level, I can't mark one of my own items claimed returned if it was checked out at another library. |
| 11:53 |
mmorgan |
But the other library can. |
| 11:53 |
mmorgan |
We'd like our libraries to have permission to make only their own items claimed returned. Is this an issue for other consortia? |
| 11:53 |
jeff |
this is not a unique situation/question. |
| 11:53 |
kmlussier |
berick: I love the LP bug you just submitted. While you're poking around there anyway, how difficult would it also be to take care of bug 1378383? |
| 11:53 |
pinesol_green |
Launchpad bug 1378383 in Evergreen "Previous circ history should always honor Maximum previous checkouts OU setting" (affected: 1, heat: 6) [Medium,New] https://launchpad.net/bugs/1378383 |
| 11:54 |
mmorgan |
jeff: no, not unique, but a specific example. |
| 11:54 |
jeff |
mmorgan: yep, i responded before you were done. :-) |
| 11:55 |
mmorgan |
Ah. ok :) |
| 11:57 |
mmorgan |
Just wondering if having some permissions look at checkout library rather than copy owning library is an issue for others. |
| 11:58 |
bshum |
mmorgan: "rather than" might be a problem, maybe in addition to |
| 11:58 |
bshum |
mmorgan: I'd have to check our system, but I suspect that own library would definitely want the powers , but so would the library that actually checked out the material for the user |
| 11:58 |
bshum |
Since they might be the ones who interact with them. |
| 11:59 |
berick |
kmlussier: huh, yeah, we should take care of that |
| 11:59 |
* bshum |
bets our permission is more globally assigned |
| 11:59 |
berick |
kmlussier: and thanks for the feedback |
| 11:59 |
kmlussier |
berick++ |
| 11:59 |
berick |
will wait until others chime in before I roll up my sleeves on that one |
| 12:00 |
kmlussier |
berick: We recently had some discussions here about aging of circs, so the timing worked out well. :) |
| 12:01 |
Stompro |
Allo Allo, is there a way to set a default preferred location for a non authed web catalog session? The physical_loc seems to set the search scope. If I want the search scope to always be at the Consortiume level, but have a Preferred Loc set is there any hope? |
| 12:01 |
mmorgan |
kmlussier: berick: Yes, indeed! |
| 12:03 |
|
jihpringle joined #evergreen |
| 12:03 |
jboyer-isl |
mmorgan: it appears we have granted that permission to all staff at the consortial level, so that’s one option. |
| 12:05 |
bshum |
Yep, ours is set consortium too |
| 12:05 |
bshum |
Probably why nobody's complained about it |
| 12:07 |
bshum |
Stompro: So, for clarity |
| 12:07 |
mmorgan |
jboyer-isl: bshum: Currently we have lower level circ staff able to do it at the system level, but higher level staff at the consortium level. |
| 12:07 |
bshum |
Stompro: You mean you want to search the consortium level, everything, but still have a preferred location set? |
| 12:08 |
bshum |
Stompro: I think preferred library is physical_loc usually |
| 12:08 |
bshum |
And actual searching location is the locg |
| 12:09 |
bshum |
Stompro: So for example, we use physical_loc behind the scenes linked to our various hostnames |
| 12:09 |
bshum |
Stompro: http://newmilford.biblio.org/eg/opac/home?locg=1 (if we append ?locg=1 or whatever, we can force the search scope) |
| 12:09 |
Bmagic |
jboyer-isl++ #detangle addresses |
| 12:11 |
Stompro |
bshum, thanks, so if I have my locg set to 1 and my physical_loc set to whatever the local org unit is, then that should do it. Can I set locg as an apache directive like physical_loc? |
| 12:14 |
bshum |
Stompro: I think most of our libs who want consortial search end up adding the variable to their library websites' links. So we haven't really tried to set it via apache directives as such |
| 12:14 |
bshum |
Stompro: But I think it should be possible. |
| 12:14 |
Stompro |
bshum, I'll try it out and see how it goes. |
| 12:15 |
bshum |
Actually yes, a long time ago, before TPAC, we used to use just loc variables to control search scopes and append it appropriately |
| 12:15 |
bshum |
So it should be possible to write something like that in. |
| 12:16 |
|
bmills joined #evergreen |
| 12:17 |
kmlussier |
Stompro: If you go to to http://evergreen.noblenet.org/ , you'll see that they automatically append locg=1 |
| 12:17 |
kmlussier |
They did it through apache, but it was so long ago, I don't recall the details. |
| 12:17 |
* kmlussier |
is not being particularly helpful at the moment. |
| 12:27 |
Stompro |
bshum, I don't see $ENV{locg} anywhere so setting an apache env variable won't work, without that check being added. But maybe a rewrite rule is the better way to go... I think I remember that being discussed on IRC, I just didn't know what they were talking about at the time. |
| 12:30 |
Stompro |
kmlussier, thanks, I'll try to find out how to make that work, that sounds like the answer. |
| 12:31 |
bshum |
Stompro: I think that sounds right, rewrite rules anyways |
| 12:36 |
Bmagic |
Does anyone disagree that fm_IDL.xml metabib::record_attr_flat is missing a field for "source" ? |
| 12:39 |
bshum |
Disagree? |
| 12:39 |
Bmagic |
or agree |
| 12:41 |
Bmagic |
I think that the issue is the link actually. It should reference "id" instead of "source" |
| 12:50 |
Dyrcona |
csharp: I am installing 2.8.4 so I can test the upgrade script for 2.8.4 to 2.9.0. |
| 12:55 |
mmorgan |
Bmagic: Disclaimer, I don't pretend to have a deep understanding of the idl, but the id field has datatype "id", not "link" so it's not referring to that link field. |
| 12:56 |
Bmagic |
mmorgan: compare to metabib::record_attr |
| 12:56 |
Dyrcona |
Well, it should most likely be a link to bre.id. Does that appear in the list of links? |
| 12:56 |
* Dyrcona |
admittedly has not checked that statement or question. |
| 12:57 |
Bmagic |
it does but the link mentions "source" and there is not a field definition for "source" - I think it intends "id" |
| 13:03 |
Dyrcona |
Bmagic: One way to check is to make a controller call, either cstore or pcrud, to retrieve a mra object and flesh the source. |
| 13:03 |
Dyrcona |
If that doesn't work, then the link needs to be fixed. |
| 13:03 |
Bmagic |
I discovered it when creating a report |
| 13:03 |
Dyrcona |
Well, then, it is probably broken. |
| 13:03 |
Bmagic |
I submitted it on LP |
| 13:06 |
* Dyrcona |
should be paying more attention to the upgrade script issue. |
| 13:40 |
* jeff |
mostly-idly wonders how difficult it would be to make the apache/mod_perl bits of Evergreen tolerant of starting "early" |
| 13:43 |
csharp |
Dyrcona: thanks |
| 13:44 |
Dyrcona |
csharp: I'm installing 2.9.0 now. |
| 13:44 |
Dyrcona |
I'll know if the changes I made to the upgrade script will work in a couple of minutes. |
| 13:45 |
Dyrcona |
It works for me. I'm going to post a branch based on rel_2_9. |
| 13:46 |
Dyrcona |
You check it out and just try the 2.8.4 to 2.9.0 upgrade script, or you can go through the whole install process from git if you like. |
| 13:52 |
Dyrcona |
csharp: http://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/dyrcona/lp1497307_fix_upgrade_script |
| 14:27 |
csharp |
Dyrcona: excellent! I'll test |
| 14:27 |
Dyrcona |
csharp++ |
| 14:33 |
csharp |
so far so good - I'm at the authority update, which will take a while |
| 14:33 |
csharp |
I'll update the bug with a signoff unless I hit anything |
| 14:57 |
Dyrcona |
Well, it's not surprising that there were some issues. |
| 14:58 |
Dyrcona |
2.8.4-2.9.0-upgrade-db.sql is the largest version upgrade script, yet. |
| 15:13 |
csharp |
signed off - works for me! |
| 15:13 |
csharp |
Dyrcona++ |
| 15:15 |
|
jlitrell joined #evergreen |
| 15:19 |
Dyrcona |
csharp++ |
| 15:20 |
pinesol_green |
[evergreen|Jason Stephenson] LP 1497307: Fix 2.8.4 to 2.9.0 upgrade script. - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=fd32a6e> |
| 15:20 |
Stompro |
bshum, kmlussier, editing the default / redirect to add the ?locg=1 seems like the simplest fix for my earlier question. Had to learn about firefox caching 301 redirects, was puzzled for a while. Thanks again. |
| 15:37 |
Dyrcona |
For those following along at home, I replaced the 2.9.0 tarball and md5 with one that contains the fixed upgrade script. |
| 15:38 |
Dyrcona |
I'll send an email to the general list to let anyone know who has already downloaded it that they should download it again. |
| 15:38 |
csharp |
excellent |
| 15:44 |
kmlussier |
Stompro: Glad you got it to work the way you wanted! |
| 15:52 |
* csharp |
experiments with parallel pg_dump |
| 15:53 |
csharp |
on a test server with SSDs and 64 processor cores (using 48) - this should speed up a couple of upgrade steps ;-) |
| 15:56 |
* jlitrell |
sighs wistfully |
| 16:03 |
Bmagic |
I might have found a bug, would someone confirm. Using the staff client, replacing a barcode using this method: Edit Menu -> Replace barcode. It's resulting in a new item instead of replacing the barcode of the old item. Seems to be new in 2.8+ |
| 16:05 |
* jeffdavis |
submits a feature request entitled "Require all SQL generated by the reporter to be reviewed and approved by a knowledgeable human before being run" |
| 16:07 |
jboyer-isl |
Quick sanity check! BRE has (always since I’ve known Evergreen) an owner field, but it’s never set. I do see the occasional reference to it in OpenILS::Cat, but there’s no way to make use of it, correct? |
| 16:07 |
jboyer-isl |
I can’t see any way, but if I’m gaslighting myself it’s time to stop. |
| 16:09 |
Dyrcona |
jboyer-isl: I believe you are correct. You can set it if you create bres via script. |
| 16:09 |
mmorgan |
Bmagic: I can't confirm that on 2.8.2. Edit Menu -> Replace barcode worked, did not create a new item. Got the uncataloged item noise, but I'm not sure if it's always done that. |
| 16:09 |
Dyrcona |
FWIW, none of our bres have owner set to anything but null. |
| 16:10 |
jboyer-isl |
Dyrcona: Good. I’ve poked around the menus looking for a global flag or something that I may have missed, I just wanted to make sure I’m giving people accurate answers. |
| 16:10 |
Dyrcona |
jboyer-isl: You probably don't want to set it anyway. |
| 16:10 |
jboyer-isl |
Yeah, we have nothing but nothing in our DB also, but seeing it referenced in a few functions got me wondering. |
| 16:11 |
Dyrcona |
jboyer-isl: Consider it junk DNA. :) |
| 16:11 |
Dyrcona |
Which often turns out not to be junk.... :) |
| 16:11 |
jboyer-isl |
Dyrcona: Oh, no. We don’t want to mess with it, but other groups are asking if things are possible. |
| 16:12 |
jboyer-isl |
Dyrcona: BRE->owner is the mitochondria of the Evergreen organism? ;) |
| 16:12 |
Dyrcona |
jboyer-isl: Unexpected things might happen. |
| 16:12 |
Dyrcona |
aua->replaces also. |
| 16:13 |
Dyrcona |
Though the latter might not be in the IDL. |
| 16:13 |
jboyer-isl |
That’s the first I’ve heard of it. Almost like an in-line version of the audit tables (but I assume with a different feature set in mind, long, long ago) |
| 16:14 |
Dyrcona |
Probably. |
| 16:14 |
berick |
apt metaphor. a MARC record eats its owner, its owner goes on to provide power for the MARC record, which would have otherwise died out. |
| 16:14 |
kmlussier |
Bmagic: I tested it on master too and had the same results as mmorgan. |
| 16:14 |
jboyer-isl |
berick++ |
| 16:14 |
Bmagic |
weird |
| 16:15 |
kmlussier |
mmorgan: The sound was a little unexpected, wasn't it? |
| 16:15 |
Bmagic |
There must be anther variable |
| 16:15 |
mmorgan |
kmlussier: yes :) |
| 16:16 |
kmlussier |
mmorgan: I suspect you all have replaced the Star Trek sound with something that's a little less jarring. |
| 16:16 |
mmorgan |
Maybe it's the old barcode saying: Noooooo! as it goes poof. |
| 16:16 |
mmorgan |
Actually, we have not replaced it. |
| 16:17 |
mmorgan |
I wonder if our users would miss it if we replaced it now. I think we still have folks that pine for the turtle. |
| 16:59 |
pinesol_green |
Incoming from qatests: Test Success - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 17:06 |
|
mmorgan left #evergreen |
| 17:17 |
|
bmills1 joined #evergreen |
| 19:44 |
|
jihpringle joined #evergreen |
| 20:31 |
gmcharlt |
doing maintenance on evergreen-ils.org |
| 23:40 |
|
serflog joined #evergreen |
| 23:40 |
|
Topic for #evergreen is now Welcome to the #evergreen library system channel! | We are publicly logged: http://irc.evergreen-ils.org/evergreen | Large pastes at http://paste.evergreen-ils.org |
| 23:44 |
gmcharlt |
testing |
| 23:48 |
gmcharlt |
ok, all done - everything should be up and running again (with the exception of piwik tracking, which I've mostly disabled) and running Wheezy |
| 23:49 |
csharp |
gmcharlt++ |
| 23:49 |
gmcharlt |
another O/S upgrade is in store some time next week |
