| Time |
Nick |
Message |
| 05:00 |
|
RAIDoperator joined #evergreen |
| 05:02 |
pinesol_green |
Incoming from qatests: Test Success - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 06:44 |
|
Callender joined #evergreen |
| 07:52 |
|
geoffsams joined #evergreen |
| 07:56 |
|
jboyer-home joined #evergreen |
| 08:09 |
|
akilsdonk joined #evergreen |
| 08:11 |
|
ericar joined #evergreen |
| 08:19 |
jboyer-home |
berick++ # for bug 1329503. |
| 08:19 |
pinesol_green |
Launchpad bug 1329503 in Evergreen "View / Edit Existing Reports" (affected: 4, heat: 24) [Undecided,New] https://launchpad.net/bugs/1329503 - Assigned to Bill Erickson (erickson-esilibrary) |
| 08:20 |
jboyer-home |
I sort of looked into it a long time ago and fled. |
| 08:31 |
|
mrpeters joined #evergreen |
| 08:43 |
|
mmorgan1 left #evergreen |
| 08:47 |
|
mmorgan1 joined #evergreen |
| 08:47 |
|
mmorgan1 left #evergreen |
| 08:48 |
|
mmorgan joined #evergreen |
| 08:49 |
|
kbeswick joined #evergreen |
| 09:18 |
|
yboston joined #evergreen |
| 09:22 |
|
shadowspar joined #evergreen |
| 09:54 |
|
Dyrcona joined #evergreen |
| 10:53 |
|
rsoulliere joined #evergreen |
| 10:56 |
yboston |
@marc 740 |
| 10:56 |
pinesol_green |
yboston: Contains related or analytical titles that are not controlled through an authority file or list. (If related or analytical titles are controlled by an authority file, use field 730 (Added entry - uniform title)). (Repeatable) [a,h,n,p,5,6,8] |
| 11:02 |
bshum |
Hmm, evergreeen site was down, we restarted apache just now. |
| 11:14 |
jboyer-home |
bshum, Dyrcona: Re: our occasional discussion about pg_restore and config.z3950_index_field_map; Something I hadn’t considered was to do a schema only restore and then a data only with triggers disabled. As long as the data is consistent on pg_dump this should result in a good restore (and faster, too!) Does that sound good to everyone, or am I missing some subtlty? |
| 11:15 |
Dyrcona |
jboyer-home: I didn't have that problem during my latest restore this week. |
| 11:15 |
jboyer-home |
Dyrcona: It |
| 11:16 |
jboyer-home |
it’s not consistent. I worry that it’s related to using a -j greater than 1. (since that check references another table) |
| 11:16 |
Dyrcona |
Could be. |
| 11:16 |
jboyer-home |
I’ve done “single-threaded” restores and they never have that problem, if I do a -j 16 or -j 24 they’re more common. |
| 11:17 |
jeff |
bshum: drat. been a while since there was an issue. |
| 11:18 |
Dyrcona |
I usually do -j 4 |
| 11:19 |
dbs |
win 12 |
| 11:20 |
jboyer-home |
I don’t know if pg_restore tries to do any dependency checking beyond inheirited tables. -j 4 may be low enough that it doesn’t happen often. |
| 11:20 |
jeff |
bshum: it would be good to get a snapshot of localhost/server-status next time, if there is a next time. |
| 11:20 |
bshum |
jeff: I'll remember that. |
| 11:21 |
jeff |
bshum: hrm. looks like it's disabled, actually (even from localhost) |
| 11:21 |
jeff |
so that wouldn't have helped this time. :-) |
| 11:21 |
jeff |
and now that i think of it, if all the apache processes are busy, i don't know that that will even return data. |
| 12:18 |
|
ericar joined #evergreen |
| 12:19 |
rsoulliere |
Hi, I have a question about marc_export.sh. |
| 12:22 |
rsoulliere |
In older versions of EG I could export records based on a text list of ids with this structure: "cat list_of_ids.txt | /openils/bin/marc_export ..." |
| 12:22 |
rsoulliere |
Should that still work? |
| 12:22 |
dbs |
rsoulliere: might depend on the version |
| 12:23 |
rsoulliere |
version of EG? How about 2.6.0? |
| 12:25 |
dbs |
Looks like it should still work |
| 12:26 |
dbs |
what's happening? |
| 12:28 |
rsoulliere |
dbs: It looks like it is ignoring the text file and generating a marc file of all records. Running on 2.4 system before upgrade it worked as expected... After upgrade to 2.6 it did not. |
| 12:29 |
rsoulliere |
The marc_export command looks something like this: "/openils/bin/marc_export -c /openils/conf/opensrf_core.xml -f USMARC -e UTF-8 > file.marc |
| 12:32 |
dbs |
Weird. $all_records is supposed to be undef |
| 12:32 |
dbs |
maybe try "if (defined $all_records)" instead of "if ($all_records)" around line 199? |
| 12:35 |
jeff |
marc_export has been completely re-written in 2.6 |
| 12:37 |
rsoulliere |
jeff: There seemed to be more options to reduce the need for the id list, but piping the id text list should still work? |
| 12:38 |
jeff |
I think that's correct. |
| 12:39 |
jeff |
if you run your marc_export command without piping any IDs to it, does it echo "Waiting for input" to stderr? |
| 12:39 |
dbs |
jeff: ah right, I was looking at marc_export as produced by a previous version, instead of marc_export.in |
| 12:41 |
rsoulliere |
I did see the error "Waiting for input?" Format issues with my text file? Does 2.6 handle the file differently now? |
| 12:42 |
|
RoganH joined #evergreen |
| 12:42 |
jeff |
rsoulliere: "waiting for input" is normal to see when not running with something like --all, --since, or --library |
| 12:43 |
jeff |
rsoulliere: it will always print that first, even if you're feeding it IDs as input |
| 12:43 |
jeff |
rsoulliere: have you tried with a small batch of records as input? |
| 12:44 |
Dyrcona |
yeah, I had tried to make that go away when it comes from standard input but it didn't work out. |
| 12:44 |
Dyrcona |
That message should have probably just been removed. |
| 12:46 |
rsoulliere |
Jeff: let me try a few tests on my end and I will report back. |
| 12:48 |
jeff |
fwiw, i don't think it will cause any issue, but i don't think marc_export requires that you pass your opensrf config file location if it's in the default location, and I don't think it knows about or respects a -c argument, just --config |
| 12:48 |
jeff |
i also don't think the previous version paid attention to a -c either, but i could be wrong there. |
| 12:48 |
jeff |
it's likely not causing any issues, just isn't doing anything. |
| 12:50 |
|
hbrennan joined #evergreen |
| 12:53 |
rsoulliere |
ls |
| 12:53 |
rsoulliere |
ignore my last comment: wrong window when I typed :-) |
| 12:54 |
RoganH |
rsoulliere: At least you didn't accidentally type a password in the wrong window as I once did. :) |
| 12:55 |
hbrennan |
hehe |
| 12:55 |
hbrennan |
About once a week I scan a barcode in here :) |
| 12:55 |
* dbs |
did that a few weeks back with a 14-char randomized password - sigh. |
| 12:55 |
dbs |
memorizing the new 16-char randomized password was murder. |
| 12:57 |
jeff |
it took me many many years to stop remembering my old michnet dialup account's fixed, random password. |
| 12:57 |
jeff |
fwiw, i believe it *could* be changed, but changing it may have involved a fax machine. |
| 12:57 |
RoganH |
dbs: at least it was just a password for a desktop windows vm |
| 12:58 |
RoganH |
hbrennan: I've done that at least once too |
| 13:02 |
jcamins |
dbs: you can't change the password to something secure on desktop Windows VMs? |
| 13:03 |
RoganH |
jcamins: I was saying when I posted a password in IRC it was just a desktop VM, so it wasn't a big deal to me that I posted it |
| 13:03 |
jcamins |
RoganH: ohhh, got it. |
| 13:04 |
RoganH |
jcamins: I just felt very, very stupid for not paying attention to my active window |
| 13:04 |
* dbs |
did it when the monitor was off, assuming that screenlock had kicked in. Nope. |
| 13:04 |
jcamins |
RoganH: yeah, I've done that. Not with passwords, because I never hit enter after typing in a password. |
| 13:05 |
RoganH |
I want one of those eye trackers that change your active window based on where you're looking. Tragically my library probably won't consider laziness an adequate disability to justify the accommodation. |
| 13:05 |
jcamins |
At least, I try not to. |
| 13:05 |
rsoulliere |
marc export testing update: I ran the marc_export script on a small list of ids and it worked as expected. Looking over the logs... one correlation is that if my text file had no records, the script imported all records. |
| 13:05 |
jcamins |
dbs: that's exactly why I don't hit enter after entering a password. |
| 13:06 |
dbs |
jcamins: thanks |
| 13:07 |
jcamins |
dbs: no judgement intended. |
| 13:07 |
|
mrpeters left #evergreen |
| 13:07 |
* dbs |
reminds self to 1) not hit enter after entering a password and 2) not confess to embarassing actions in IRC |
| 13:07 |
jcamins |
lol |
| 13:07 |
dbs |
MUST... MAINTAIN... IMAGE... OF PERFECTION |
| 13:07 |
rsoulliere |
More background info. The text file is autogenerated from an sql script. Perhaps, I need to add a check in my script to not run marc_export if the text file is empty? |
| 13:08 |
* RoganH |
always admits to embarrassing actions, it's the closest thing he gets to humility. |
| 13:08 |
jcamins |
RoganH: yeah, the other day I accidentally shared the password for ${MY_COUNTRY}'s ICBM fleet? |
| 13:08 |
dbs |
rsoulliere: I would consider "--all as default" a bug, as the cost to the system is potentially higher |
| 13:09 |
dbs |
0000 |
| 13:09 |
rsoulliere |
dbs: agreed, should I file a bug report in launchpad? |
| 13:10 |
dbs |
oh, 00000000 -- http://www.damninteresting.com/ive-got-the-same-combination-on-my-luggage/ |
| 13:10 |
RoganH |
Dear NSA, I don't like jcamins. I always thought he was a dirty commie. |
| 13:10 |
RoganH |
dbs: I read that a while back. Bloody terrifying. |
| 13:11 |
RoganH |
I would say that the NSA has better things to do than monitor this IRC but they funded staff members to play WoW guilds to catch terrorists in Warcraft, so you never know. |
| 13:13 |
|
ldw joined #evergreen |
| 13:15 |
dbs |
uh oh, looks like the NSA got RoganH |
| 13:17 |
jcamins |
dbs: he must've been flagged last time he played WoW. Though I'm a little bit confused about how you can identify a terrorist in a game devoted to going around brutally killing everyone. |
| 13:17 |
hbrennan |
ahh |
| 13:26 |
Dyrcona |
--all isn't a default. |
| 13:26 |
Dyrcona |
If you give it no arguments or standard input, it sits there doing nothing. |
| 13:27 |
Dyrcona |
That's why it prints "waiting for input." |
| 13:27 |
dbs |
13:11 < rsoulliere> marc export testing update: I ran the marc_export script on a small list of ids and it worked as expected. Looking over the logs... one correlation is that if my text file had no records, the script imported all records. |
| 13:32 |
Dyrcona |
---all still isn't a default. It's because standard input was empty. |
| 13:32 |
Dyrcona |
Different bug. |
| 13:33 |
jeff |
i'm not sure that empty stdin would still export all -- but that's based on a quick read of the code earlier, so i'll defer to rsoulliere's empirical test results :-) |
| 13:33 |
Dyrcona |
The export code doesn't check Config::need_ids, so if the idlist is empty it looks like it will export everything. |
| 13:34 |
jeff |
aha |
| 13:35 |
hbrennan |
What does the Global checkbox mean/do in Circulation Limit Sets? |
| 13:35 |
jeff |
Dyrcona: ah, yup. there it is. |
| 13:36 |
Dyrcona |
Actually, this gives me an ID to make it work better with standard input. |
| 13:36 |
|
bmills joined #evergreen |
| 13:36 |
Dyrcona |
rsoulliere: Could you file a launchpad bug, please? I'll have a look in 3 weeks when I back from vacation. |
| 13:37 |
Dyrcona |
Missing a verb there, but anyway. :) |
| 13:37 |
Dyrcona |
So much for the image of perfection. :) |
| 13:37 |
rsoulliere |
Dyrcona: will do. Thanks for the help everyone! :-) |
| 13:43 |
dbs |
fwiw, "--all as default" was my lazy shorthand for the behaviour, not a diagnosis of the bug |
| 13:43 |
dbs |
but I should have been explicit about that |
| 13:45 |
|
RoganH joined #evergreen |
| 13:54 |
|
RoganH joined #evergreen |
| 14:03 |
Dyrcona |
Well, it never got tested with an empty file or pipe, so same difference. |
| 14:49 |
|
sseng_ joined #evergreen |
| 14:49 |
|
ktomita joined #evergreen |
| 15:49 |
|
jeff joined #evergreen |
| 15:49 |
|
jeff joined #evergreen |
| 15:49 |
jeff |
hrm. |
| 16:07 |
|
ericar_ joined #evergreen |
| 17:03 |
|
mmorgan left #evergreen |
| 17:03 |
hbrennan |
Trying to change a permission from Branch to Consortium, and after hitting Save (and seeing the successful message) it reverts back to Branch after a few seconds.... |
| 17:04 |
Dyrcona |
hbrennan: It shouldn't. |
| 17:05 |
Dyrcona |
hbrennan: Do you know how to clear the cache in the staff client? |
| 17:06 |
Dyrcona |
I'd try that. |
| 17:07 |
Dyrcona |
Also, not sure what that interface will do if your account doesn't have permission to change the permission. |
| 17:07 |
Dyrcona |
I usually mess with permissions in the database. |
| 17:15 |
hbrennan |
Dyrcona: Sorry, got pulled away |
| 17:15 |
hbrennan |
I didn't think that was supposed to happen |
| 17:15 |
hbrennan |
Yes, I know how to clear the cache |
| 17:15 |
hbrennan |
I wasn't the one giving the permission, so I'll track down my boss soon and have her try again after doing that on her staff client |
| 17:16 |
hbrennan |
She should have permission to do everything |
| 17:16 |
hbrennan |
Funny thing is, she gave me the permission Admin_Group_Penalty_Threshold no problem |
| 17:17 |
hbrennan |
but she's just trying to change the View_Group_Penalty from branch to consortium now |
| 17:17 |
hbrennan |
but I suppose that "lower level" permission isn't talking to thetoher |
| 17:27 |
hbrennan |
bmills++ |
| 20:04 |
hbrennan |
@later tell bmills About that permission-granting issue... Had super user/admin log in, couldn't grant the change from Branch to Consortium. Had him add the permission to my user group, still couldn't change it. So, still a mystery but we've rules out any permission issues. Weird! |
| 20:04 |
pinesol_green |
hbrennan: The operation succeeded. |
| 20:04 |
hbrennan |
hehe. My first later |
| 23:09 |
|
artunit joined #evergreen |
