| Time |
Nick |
Message |
| 02:15 |
|
RBecker joined #evergreen |
| 03:39 |
|
mtcarlsoz joined #evergreen |
| 03:39 |
|
mnsri joined #evergreen |
| 03:48 |
|
mnsri_ joined #evergreen |
| 03:49 |
|
mnsri joined #evergreen |
| 06:01 |
|
mtcarlson_away joined #evergreen |
| 06:12 |
|
mnsri joined #evergreen |
| 07:05 |
|
kmlussier joined #evergreen |
| 07:39 |
|
rjackson-isl joined #evergreen |
| 07:48 |
|
jboyer-isl joined #evergreen |
| 08:00 |
|
yboston joined #evergreen |
| 08:02 |
|
tspindler joined #evergreen |
| 08:23 |
|
Dyrcona joined #evergreen |
| 08:43 |
|
mmorgan joined #evergreen |
| 08:43 |
kmlussier |
remingtron: Did your release notes definition ever make it to the wiki? |
| 08:45 |
remingtron |
kmlussier: good question. I'll investigate. |
| 08:46 |
kmlussier |
If not, I can add it. I did find this old page - http://wiki.evergreen-ils.org/doku.php?id=dev:release_notes_checklist |
| 08:47 |
kmlussier |
Ah, well, it's here: http://wiki.evergreen-ils.org/doku.php?id=dev:meetings:2014-05-19 |
| 09:00 |
remingtron |
yeah, that's all I found too. Not sure where it belongs |
| 09:01 |
remingtron |
maybe here, but it's old and probably not often used: |
| 09:01 |
remingtron |
http://evergreen-ils.org/dokuwiki/doku.php?id=dev:start |
| 09:02 |
remingtron |
Wherever the release notes info goes, it should get linked from the more authoritative dev pages, like here: |
| 09:02 |
remingtron |
http://wiki.evergreen-ils.org/doku.php?id=contributing |
| 09:03 |
kmlussier |
remingtron: Yup, that last one. That's what I was just looking at. |
| 09:03 |
remingtron |
cool, I'll leave it in your capable hands. thanks! |
| 09:04 |
kmlussier |
remingtron: Will do! I'll probably try to link to it from a DIG page too. |
| 09:04 |
remingtron |
sounds good |
| 09:31 |
berick |
kmlussier++ # LP review |
| 09:31 |
* berick |
has some release notes to write |
| 09:32 |
* kmlussier |
cracks the whip |
| 09:32 |
* berick |
gives the past a slip |
| 09:33 |
|
yboston joined #evergreen |
| 09:37 |
jeff |
welcome to August, everyone. |
| 09:37 |
kmlussier |
Good morning jeff. Happy Friday! |
| 09:47 |
jeff |
you too! |
| 09:55 |
berick |
hmm, if I have CREATE_PURCHASE_ORDER at the branch level, should I be able to spend from funds owned at the system level? |
| 09:55 |
berick |
my initial thought was yes, kind of like copy locations |
| 09:56 |
berick |
but i'm having second thoughts. curious how others see that |
| 09:56 |
jboyer-isl |
Is the alternative not allowing the expense, or requiring another user (supervisor, central ordering, etc.) to release it? |
| 09:57 |
berick |
well, after the work i'm doing now, the fund would simply not appear in the selector |
| 09:57 |
berick |
so, yeah, someone else would have to apply it |
| 10:00 |
jboyer-isl |
I probably misunderstood from the start then, I read that as they wouldn’t be able to even put the PO together. (Not using acq yet, should probably know more before thinking out loud about workflows… :) ) |
| 10:04 |
eeevil |
berick: I'd think that the depth of the perm would effect the list presented. if you have depth=system then you could see the system fund |
| 10:04 |
eeevil |
(I may be misunderstanding too) |
| 10:05 |
berick |
eeevil: depth w/ definitly affect it, just trying to determine how, exactly. |
| 10:05 |
berick |
as an alternate example, I have CRAETE_COPY at level 2, but I can use copy locations from level 0 |
| 10:05 |
berick |
if I have CREATE_PURCHASE_ORDER at level 2, can I use funds owned at level 0? |
| 10:06 |
eeevil |
oh... so, I would think fund visibility would be controlled separately from where you can create POs |
| 10:07 |
eeevil |
fund visibility would be "funds owned here, or at a parent up to depth X" |
| 10:08 |
eeevil |
but you wouldn't get peer-branch fund access, just ancestor-owned fund access |
| 10:08 |
berick |
what defines depth X? |
| 10:08 |
eeevil |
the depth of your (apparently hypothetical) VIEW_FUND perm |
| 10:08 |
eeevil |
and "here" is all your work orgs |
| 10:09 |
berick |
ok, I only want a list of funds I can spend from. Forget VIEW_FUND. |
| 10:09 |
kmlussier |
berick: We have acq staff that creates PO's at the branch level and use funds owned by the system. However, I think they have permission to create PO's at the system level, they just don't do it by practice. But I definitely could see a use case where a person who can only do POs at a branch would use the system-owned funds. |
| 10:10 |
eeevil |
is there a perm that says "you can see (and therefore use) these funds", or a "you can use these funds" perm? |
| 10:11 |
berick |
eeevil: hmm, actually, there is a MANAGE_FUND perm for that purpose.. i.e. which ones can I use. I fear no one really uses it, though |
| 10:11 |
berick |
or at least, not as intended |
| 10:11 |
berick |
maybe we need to brush that off |
| 10:11 |
berick |
kmlussier: thanks |
| 10:12 |
* berick |
notes the perm could have a better name |
| 10:13 |
berick |
that would solve the problem and simply some things |
| 10:13 |
berick |
eeevil++ # jarring my memory |
| 10:13 |
eeevil |
cool ... sorry if it's more work ;) |
| 10:13 |
jboyer-isl |
berick++ |
| 10:13 |
jboyer-isl |
eeevil++ |
| 10:13 |
jboyer-isl |
For worrying about details before they become problems. |
| 10:41 |
|
mllewellyn joined #evergreen |
| 10:51 |
kmlussier |
Would people consider https://bugs.launchpad.net/evergreen/+bug/1350827 a bug fix or new feature? I'm just wondering if I need to write a release notes entry for it. |
| 10:51 |
pinesol_green |
Launchpad bug 1350827 in Evergreen "Display problem in PAC when subfields $3 and $z are both present in the 856 tag " (affected: 1, heat: 6) [Low,Confirmed] |
| 11:00 |
|
collum joined #evergreen |
| 11:03 |
kmlussier |
And, since Doodle still will not let me fix the old poll, looks like I'll need to put out a new poll for Bug Squashing Day. http://doodle.com/2dx9h3cccwbp84v4 |
| 11:03 |
kmlussier |
Anyone who participated in the first poll will have to do a redo. Sorry! |
| 11:19 |
|
kmlussier joined #evergreen |
| 11:36 |
|
kmlussier left #evergreen |
| 11:36 |
|
kmlussier joined #evergreen |
| 12:47 |
|
mtate joined #evergreen |
| 13:03 |
csharp |
is there anyone using pgbouncer who would be willing to share their config.ini file with me? :-) |
| 13:05 |
dbs |
kmlussier: I'd say bug fix |
| 13:08 |
|
hbrennan joined #evergreen |
| 13:10 |
eeevil |
dbs: you were involved in the tpac version of that, and (I think) also the LURI version. do you agree with the general assessment that the LURI behavior seems more correct, and the tpac should align with that? |
| 13:21 |
dbs |
I was involved in the jspac version too :) |
| 13:22 |
eeevil |
dbs: indeed ... you are the master of the 856, it seems! |
| 13:23 |
dbs |
I suspect we should probably loop over all of the returned z/3/2/y subfields and display them all, rather than just the first one |
| 13:24 |
dbs |
z and y are repeatable (YAY MARC), and 3 / 2 are not, but they specify different things and probably should be separated out accordingly. at least according to marc21 docs |
| 13:24 |
|
RoganH joined #evergreen |
| 13:24 |
dbs |
$2 Access Method: "CLICK ON THE LINK IN YOUR BROWSER, DO YOU REALLY CARE IF IT IS GOPHER?" |
| 13:25 |
RoganH |
Hey, I liked gopher. I still want a gopher client. |
| 13:26 |
dbs |
I mean, $2 is supposed to be a code from http://www.loc.gov/standards/valuelist/electronaccess.html anyway |
| 13:27 |
csharp |
I WANT MY $2!! |
| 13:27 |
dbs |
We should probably just eradicate $2, seems like it's purely local practice that resulted in it wanting to be displayed |
| 13:28 |
dbs |
And if you have multiple $y or $z, they should all be displayed, not just the first one, because theoretically they were important. (Concatenating multiple $y together to form the link text? MARC21 U MAKE NO SENSE) |
| 13:30 |
dbs |
$3 should be broken out and displayed as an entirely separate field: "materials". But that's hard because we want one line. Which is probably why we went to the $3 = $z thing (that, and legacy usage of $3) |
| 13:30 |
dbs |
http://www.loc.gov/marc/bibliographic/bd856.html says the definitions haven't changed since 2000 though, so that's pretty dang legacy |
| 13:30 |
dbs |
@monologue |
| 13:30 |
pinesol_green |
dbs: Your current monologue is at least 5 lines long. |
| 13:31 |
dbs |
@curse RoganH and csharp for breaking up a perfectly good rant |
| 13:31 |
pinesol_green |
dbs: You probably want hard-boiled eggs. |
| 13:31 |
dbs |
Come to think of it, I do need lunch. |
| 13:31 |
Dyrcona |
The paper boy from Better Off Dead drove by while you were monologuing. |
| 13:31 |
RoganH |
I was just trolling you for the sake of preserving gopher's dignity. |
| 13:32 |
RoganH |
csharp: An egg sandwich sound good. |
| 13:32 |
Dyrcona |
RoganH: You might want a gopher server to go with that client. |
| 13:32 |
Dyrcona |
;) |
| 13:33 |
RoganH |
Drycona: We could jury rig some bizarre http translator. Really bizarre, but people don't actually need holds on what they asked for right? |
| 13:34 |
RoganH |
Technically I suppose that would be a gopher server anyway. /shrug |
| 13:35 |
Dyrcona |
A proxy maybe. |
| 13:35 |
kmlussier |
Everything dbs said makes sense to me. |
| 13:50 |
eeevil |
Dyrcona: I think I see my bug in the default FF value thing |
| 13:53 |
Dyrcona |
eeevil: Cool. I'll be happy to test what ever you come up with. |
| 13:54 |
* Dyrcona |
funks out with some '70s tunes. |
| 13:56 |
pastebot |
"eeevil" at 64.57.241.14 pasted "for Dyrcona ... fixed field defaults" (31 lines) at http://paste.evergreen-ils.org/14 |
| 13:57 |
eeevil |
if that helps, I'll update my branch. it's a 2 line change in 2 files.... |
| 13:57 |
Dyrcona |
Ok. I'll give it a whirl. |
| 13:58 |
eeevil |
I'll add IF EXISTS to the drops in the upgrade as well |
| 13:58 |
* dbwells |
hopes Dyrcona's '70s playlist includes THE greatest song of all time... CONVOY! |
| 13:59 |
eeevil |
Dyrcona: oh, heh... actually, that may be part of the problem. one of the drops was incorrect :) |
| 14:00 |
eeevil |
specifically: DROP FUNCTION IF EXISTS vandelay.marc21_extract_all_fixed_fields( text ); -- correct. only one param, upgrade had 2 |
| 14:01 |
Dyrcona |
dbwells: Nope, but it does have Kung Fu Figthing! |
| 14:01 |
dbwells |
eh, close enough |
| 14:02 |
Dyrcona |
eeevil: So, should I remove one of the drop function calls? |
| 14:02 |
eeevil |
no, just run the one I put ther -^ |
| 14:02 |
collum |
Thanks Dyrcona, I think that purged that previous song out of my head. |
| 14:02 |
eeevil |
shouldn't actually matter to reingest, but it was incorrect) |
| 14:03 |
Dyrcona |
ok. here goes.... |
| 14:05 |
Dyrcona |
It fixes my one sample record. |
| 14:05 |
Dyrcona |
Yay! |
| 14:06 |
Dyrcona |
I'll try it on my others. |
| 14:07 |
eeevil |
Dyrcona: rock. I'm going to force-push to my branch, with the other things fixed too |
| 14:08 |
Dyrcona |
eeevil: Cool. |
| 14:09 |
Dyrcona |
It fixes my other fiction records from my test batch, so I'll do an ingest on my dev server tonight. |
| 14:09 |
Dyrcona |
Or maybe, I'll reingest record attributes right now. |
| 14:09 |
eeevil |
and I'll rebase it to master... |
| 14:15 |
eeevil |
pushed |
| 14:46 |
Dyrcona |
eeevil: Was it the intent of these changes to not use defaults if no 006/008 exist in a record? |
| 15:10 |
eeevil |
Dyrcona: it was the effect ... was that not /your/ intent? a minor adjustment can make it supply the default when there is no value in the record. I can make it so, just say the word |
| 15:11 |
Dyrcona |
eeevil: It was not my intent, but I'm playing with it now to see what some of our records already have. |
| 15:11 |
Dyrcona |
eeevil: If you think it is better to not have a default, I could live with that, we don't even have only about 930 such records out of 900,000+. |
| 15:12 |
Dyrcona |
Something got messed up in the editing there, but anyway. |
| 15:13 |
eeevil |
a record without an 008 is basically a blank slate ... I'm not sure defaults for /indexing/ are a good thing ... I could go either way, though. I don't have a strong opinion |
| 15:14 |
eeevil |
IMO, it's better without than doubled, and we can certainly change it later |
| 15:18 |
Dyrcona |
Given that most of what I'm finding cataloged as "books" actually aren't books so far, I don't mind losing the defaults. |
| 15:19 |
Dyrcona |
Someone has an electric pencil engraver cataloged! I wonder if they even still have it. |
| 15:19 |
Dyrcona |
Actually 3 "copies" of this thing. |
| 15:26 |
Dyrcona |
Yeah, I think I'm cool with not having defaults. Why guess? |
| 15:33 |
|
RoganH joined #evergreen |
| 15:39 |
|
tspindler left #evergreen |
| 15:39 |
Dyrcona |
Ok. The funk just disappeared with Loggins & Messina. |
| 15:42 |
|
mnsri joined #evergreen |
| 15:42 |
* Dyrcona |
is saved by the Commodores... "She's a brick.....house!" |
| 15:47 |
RoganH |
Dyrcona++ |
| 15:47 |
kmlussier |
Have a nice weekend everyone! |
| 15:56 |
|
_bott_ joined #evergreen |
| 15:57 |
|
dkyle left #evergreen |
| 16:00 |
Dyrcona |
Now, we're Kung Fu Fighting! |
| 16:00 |
mmorgan |
Earworm! |
| 16:00 |
mmorgan |
thanks a lot. |
| 16:01 |
bshum |
*ninja kicks* |
| 16:16 |
mmorgan |
Anyone else had problems with runaway MARC Expert searches? |
| 16:16 |
mmorgan |
concurrent expert searches driving up the load average, essentially bringing the system down. |
| 16:19 |
Dyrcona |
mmorgan: Not sure if it is MARC expert searches or not, but we have found some search queries running in the database for days in the past. |
| 16:20 |
Dyrcona |
Haven't noticed that so much lately, though. |
| 16:20 |
jboyer-isl |
mmorgan: Not since our last upgrade (which included hardware modifications, so who knows) |
| 16:21 |
jboyer-isl |
Of course, before that it was so common that expert searches just plain never returned results that I suspect no one has tried one in ages. |
| 16:22 |
mmorgan |
It has happened a few times that the load average has skyrocketed. We could not always pinpoint a cause. |
| 16:22 |
mmorgan |
But the last two occasions we were able to capture the queries and they were expert searches. |
| 16:23 |
mmorgan |
seems like one takes a long time, but may eventually work. A number of them running concurrently is what caused the problem. |
| 16:23 |
mmorgan |
just wondering if it's unique to our system. |
| 16:25 |
jboyer-isl |
I don’t know enough about how they operate on the backend (trawling through metabib.real_full_rec I would hope) to offer much help. When we were having common issues with searches running “forever” we started killing them after 2-3 mins in a cron job. |
| 16:28 |
dbs |
mmorgan: yeah, we had concurrency problems with long-running searches back in the spring. A site uptime measurement tool searching for "a" and "the" (thanks IT Services) |
| 16:30 |
mmorgan |
we have hidden our expert search. Given the issues we didn't want it out there for anyone to try. |
| 16:32 |
mmorgan |
we don't want to leave it hidden, though. Maybe jboyer-isl's cron job is something to explore... |
| 16:32 |
|
alynn26 joined #evergreen |
| 16:36 |
pastebot |
"mmorgan" at 64.57.241.14 pasted "MARC Expert queries" (112 lines) at http://paste.evergreen-ils.org/15 |
| 16:36 |
mmorgan |
in case anyone is interested in what the queries looked like |
| 16:38 |
csharp |
mmorgan: we had similar issues before we added a separate RAID array on our master DB to contain our postgres data (previously all on one physical array) |
| 16:38 |
jeff |
high on the list of migration challenges is "terminology differences" |
| 16:38 |
csharp |
mmorgan: we, like jboyer-isl, also kill any search queries that run longer than 90 seconds |
| 16:39 |
mmorgan |
csharp: so it's specifically long running opac searches you kill, not just any query? |
| 16:39 |
Dyrcona |
jeff: true dat. |
| 16:40 |
csharp |
mmorgan: yes |
| 16:41 |
csharp |
mmorgan: select pg_cancel_backend(procpid) from pg_stat_activity where current_query <> '<IDLE>' and now() - query_start > '20 seconds' and current_query ~ 'bib search' order by 1 desc; |
| 16:41 |
csharp |
that runs once per minute on our server |
| 16:42 |
mmorgan |
ok, thanks. We'll definitely look into that. |
| 16:42 |
csharp |
so it's 20 to 80 seconds, my bad |
| 16:42 |
mmorgan |
csharp++ jboyer-isl++ |
| 16:45 |
Dyrcona |
csharp: Do you have statistics on how many queries get killed that way? |
| 16:45 |
dbs |
csharp: yikes, we found that killing postgresql backends had deleterious effects on other parts of the system |
| 16:45 |
dbs |
Something like open-ils.storage would freak out because the pg connection it had had just been killed |
| 16:46 |
dbs |
that said, all Evergreen 2.4 / older OpenSRF stuff so who knows if that was particular to our setup |
| 16:46 |
Dyrcona |
Well, I can imagine a drone might barf. |
| 16:50 |
csharp |
Dyrcona: after we fixed our hardware issues, we're probably killing 1 to 2 within every 20 mins |
| 16:50 |
csharp |
this was put in place by gmcharlt when we first moved to 2.1 |
| 16:51 |
gmcharlt |
pg_cancel_backend, not pg_terminate_backend, to be clear |
| 16:51 |
dbs |
ah, that's a good thing to make clear :) |
| 16:52 |
csharp |
mmorgan: our crontab entry for postgres looks like this: |
| 16:52 |
csharp |
*/1 * * * * psql -U evergreen < /var/lib/postgresql/scripts/calm.sql >> /var/lib/postgresql/scripts/calm.log |
| 16:53 |
csharp |
that way we have a log (though not timestamped or anything) |
| 16:53 |
gmcharlt |
dbs: it's how I've managed to hang on to my feet lo these many years -- avoiding foot-guns ;) |
| 16:53 |
csharp |
honestly, I forget it's there |
| 16:53 |
mmorgan |
So, what does a user searching the catalog see when their query is cancelled, should they patiently wait that long. Zero results? |
| 16:54 |
csharp |
mmorgan: I honestly don't know - I assume they'd just see the spinning wheel |
| 16:57 |
Dyrcona |
Well, I'm signing out. |
| 16:57 |
Dyrcona |
Have a pleasant weekend, everybody! |
| 17:10 |
pinesol_green |
Incoming from qatests: Test Success - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 17:25 |
|
mmorgan left #evergreen |
| 18:28 |
|
tsbere joined #evergreen |
| 18:36 |
|
yboston joined #evergreen |
