Time |
Nick |
Message |
07:29 |
|
graced joined #evergreen |
07:39 |
|
rjackson_isl joined #evergreen |
07:40 |
|
dcook__ joined #evergreen |
07:58 |
|
krvmga joined #evergreen |
07:58 |
krvmga |
are the macros that we can use for receipt templates also good for things in acquisitions? |
08:01 |
|
jboyer-isl joined #evergreen |
08:06 |
|
ckolasinski joined #evergreen |
08:14 |
|
collum joined #evergreen |
08:18 |
csharp |
krvmga: afaik, no - there is JavaScript business logic in the receipt template code that knows about the macros - it's not in acq |
08:19 |
krvmga |
csharp: thanks. one of my co-workers asked me. |
08:20 |
|
akilsdonk joined #evergreen |
08:27 |
|
mmorgan joined #evergreen |
08:28 |
|
mrpeters joined #evergreen |
08:40 |
jboyer-isl |
Action Trigger Question Time! |
08:42 |
jboyer-isl |
So, by default a_t_r_pl only runs the checkout.due hook because it’s defined as the default in the script. There are a lot of passive hooks though, some of which seem to run without having to be called specifically (the selfcheck.whatever hooks, usually). Do any local hooks have to be added to /openils/conf/action_trigger_filters.json or called out on the a_t_r.pl command line? |
08:43 |
jboyer-isl |
any local == all local... |
08:43 |
jboyer-isl |
I would have assumed that not specifying any hook would mean to run them all, but I am mistaken. |
08:49 |
|
Shae joined #evergreen |
08:52 |
jboyer-isl |
For the logs: From what I have seen it does appear that local hooks need to be added to action_trigger_filters.json. |
08:53 |
dbwells |
Our experience matches that conclusion. I haven't seen any passive hooks run other than those we added to action_trigger_filters.json. |
08:54 |
* mmorgan |
has found that to be true as well. |
08:57 |
dbwells |
We don't run and selfcheck, so I can't comment on whether that code does something unique with event generation. |
09:02 |
mmorgan |
We are running some selfcheck stations that use the a_t selfcheck receipts. Not sure I understand why those events are "passive", but they work just fine. |
09:08 |
pinesol_green |
[evergreen|Remington Steed] Docs: Fix AsciiDoc processing errors - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=63b5982> |
09:09 |
|
dkyle joined #evergreen |
09:09 |
|
_bott_ joined #evergreen |
09:10 |
|
Dyrcona joined #evergreen |
09:30 |
Dyrcona |
Do I have to use namespace prefixes when using xpath in a database query on bre.marc? |
09:31 |
Dyrcona |
I ask, 'cause this is giving me nothing: /record/field[@tag="245"]/subfield[@code="a"]/text() |
09:32 |
Dyrcona |
Doh! |
09:32 |
Dyrcona |
datafield, not field. |
09:33 |
Dyrcona |
And, I still get nothing! |
09:33 |
Dyrcona |
It's gonna be another one of those weeks, I see. |
09:33 |
dbwells |
Dyrcona: We usually tiptoe around any possible namespace issues and do something like: oils_xpath_string('//*[@tag="245"]/*[@code="a"]', bre.marc) |
09:33 |
Dyrcona |
Ok, I'll us oils_xpath_string, then. |
09:33 |
Dyrcona |
I don't like using //* |
09:34 |
Dyrcona |
Just sayin'. |
09:34 |
dbwells |
Well, I think the regular xpath stuff works too with the wildcards. |
09:34 |
Dyrcona |
It does. I just prefer the precision of specifying exactly what I want. |
09:35 |
dbwells |
Yes, that was in response to your first statement, not the stuff about not liking the wildcards. At some point I just gave in, since @tag is already pretty specific in a marc record. |
09:36 |
Dyrcona |
Still getting nothing, and the record has a 245$a. |
09:36 |
|
yboston joined #evergreen |
09:41 |
csharp |
Dyrcona: I've had a similar lack of success using xpath too |
09:41 |
Dyrcona |
Well, to hell wit that, then. I'll just pull the title from some place else. So what if it is in all lower case. |
09:42 |
csharp |
I don't know enough about it to even really troubleshoot |
09:42 |
Dyrcona |
csharp: I normally have no trouble with xpath in Perl, C, or whatever. |
09:42 |
csharp |
I'll clarify: xpath in Evergreen/postgresql |
09:42 |
Dyrcona |
That same statement works with libxml perl. |
09:42 |
Dyrcona |
Heh. |
09:42 |
Dyrcona |
I already feel exhausted, sorry. |
09:43 |
* Dyrcona |
should've taken a sick day, but then there'd be no tech staff in the office and everyone else would shit their pants if something happened. |
09:55 |
gmcharlt |
verbose, but effective: '/*[local-name()="record"]/*[local-name()="datafield" and @tag = "245"]/*[local-name()="subfield" and @code="a"]/text()' |
09:56 |
gmcharlt |
sadly, Pg's handling of XML namespaces has been... variable |
09:56 |
gmcharlt |
e.g., http://www.postgresql.org/message-id/54E5C0B1.6040001@joh.to |
09:58 |
dbwells |
We're still on 9.1.14, so that might be a factor in why the code I posted has always worked for me. |
10:00 |
|
Newziky joined #evergreen |
10:00 |
gmcharlt |
dbwells: indeed |
10:00 |
dbwells |
I've also had luck with something like the following (where the "namespace" argument structure can actually be any namespace you want): |
10:00 |
dbwells |
SELECT xpath('/marc:record/marc:datafield[@tag="245"]/marc:subfield[@code="a"]', marc::XML, ARRAY[ARRAY['marc', 'http://www.loc.gov/MARC21/slim']]) from biblio.record_entry where id = 12345; |
10:00 |
gmcharlt |
dbwells: likewise |
10:08 |
Dyrcona |
Yeah. I just gave up and used mrfr. I don't want to spend all morning on it. |
10:19 |
Dyrcona |
On my opensrf.settings issue: I have almost ruled out the hold targeter and a/t runner, but not exactly. |
10:20 |
Dyrcona |
I notice that storage uses SettingsClient quite liberally, so I'm going log every time it is used in storage and fire off a/t runner and the hold targeter and then see what happens. |
10:24 |
Dyrcona |
dbwells: Our Pg server is 9.1, but I was using a 9.3 client, not that that has much to do with anything. :) |
10:25 |
berick |
fyi if there are more than a handful of connections from storage to settings (maybe even just one), I'd be surprsied. drones should be reading from the local cached version of the config. |
10:25 |
berick |
if you do find a lot, that's news |
10:25 |
dbwells |
Dyrcona: I'm just curious, are you on 9.1.14 or 9.1.15? Apparently (based on the thread gmcharlt posted), xpath behavior had a significant change at that minor version. |
10:26 |
* dbwells |
wants to know if all his reports are going to break when 9.1.15 hits production. |
10:27 |
Dyrcona |
Not even 9.1.14. |
10:27 |
Dyrcona |
Earlier than that. |
10:27 |
dbwells |
ok, guess we'll wait and see :) |
10:27 |
Dyrcona |
XML namespaces can be tricky. |
10:27 |
* Dyrcona |
thinks they were an OK idea that was poorly implemented. |
10:32 |
Dyrcona |
Whee! Gotta love this one: pg_restore: [archiver (db)] COPY failed for table "z3950_index_field_map": ERROR: new row for relation "z3950_index_field_map" violates check constraint "valid_z3950_attr_type" |
10:32 |
Dyrcona |
Added something to my restore script to shove the table data in after the fact if the table ends up empty. |
10:32 |
bshum |
I'm still not sure why that randomly happens but then doesn't. |
10:32 |
Dyrcona |
I'm not either. |
10:33 |
Dyrcona |
It will happen, and then it won't. |
10:33 |
Dyrcona |
Sometimes happens several restores in a row, some times doesn't. Sometimes seems to alternate. |
10:33 |
jboyer-isl |
bshum: because it is random. If the 2 tables are restored in this order, everything is fine. If it’s the other order, your data is sad. |
10:34 |
bshum |
Sad data makes me feel sad now. |
10:34 |
jboyer-isl |
pg_restore isn’t smart enough to figure out that the check constraint implies ordering |
10:34 |
Dyrcona |
So, if I don't do parallel restore it won't happen. |
10:34 |
Dyrcona |
But, I'm lazy and don't want to wait all day. |
10:34 |
jboyer-isl |
Dyrcona: true, but like you say, it’s super slow. |
10:35 |
Dyrcona |
What's curious, is why just those two tables? Other tables must have similar relations. |
10:35 |
jboyer-isl |
I know there’s a —disable-triggers (or something similar) If there’s a pg_restore option to ignore all constraints until the data is in that might help. |
10:36 |
jboyer-isl |
Dyrcona: I think it’s specified as a check constraint rather than a foreign key, but I haven’t looked in a while. |
10:36 |
Dyrcona |
jboyer-isl: That could be it. |
10:38 |
jboyer-isl |
I don’t think there are lot of check constraints that depend on other tables. (The only ones I can remember have their list of acceptable values right in the check) |
10:53 |
dbwells |
Dyrcona: bshum: jboyer-isl: Regarding the above issue, this looks interesting: http://dba.stackexchange.com/questions/75613/disable-all-constraints-and-table-checks-while-restoring-a-dump/75635#75635 From what that says, a non-immutable check constraint is a no-no, so we should either move it to a trigger or perhaps add a 'NOT VALID' modifier to it (9.2+) |
10:55 |
bshum |
Interesting. |
10:55 |
jboyer-isl |
dbwells: A trigger certainly sounds good. (may still require disabling on restore, but that’s easy enough to do) |
10:57 |
Dyrcona |
Would a simple FK do? |
10:58 |
dbwells |
I think the issue is that the 'name' is not unique in the config table. |
10:58 |
|
jwoodard joined #evergreen |
11:15 |
|
BigRig joined #evergreen |
11:45 |
Bmagic |
Is my IRC client stale? Can anyone read this? |
11:45 |
jboyer-isl |
Bmagic: It is quiet, too quiet. |
11:45 |
jboyer-isl |
(Yes) |
11:46 |
Bmagic |
jboyer-isl: ah! good! |
11:47 |
bshum |
Calm before the storm |
11:48 |
jboyer-isl |
How do I install Evergreen on Windows with MySQL? |
11:49 |
|
bmills joined #evergreen |
11:50 |
Dyrcona |
heh |
11:50 |
Dyrcona |
You don't. |
11:50 |
Dyrcona |
Same answer for how do I install Evergreen on OpenBSD. |
11:51 |
* Dyrcona |
wouldn't 'cause OpenBSD is too slow, and I don't mean that disparagingly, it is slow by design. |
11:52 |
Dyrcona |
And, I've used OpenBSD for various purposes since at least version 2.7 back in '99 or thereabouts. |
11:53 |
Dyrcona |
But, to Francis, I say, "Have it, Hoss." |
11:54 |
* Dyrcona |
sighs. |
12:05 |
* Dyrcona |
shouldna got out of bed this morning. |
12:06 |
|
buzzy joined #evergreen |
12:07 |
mmorgan |
Always a risky thing to do ;-) |
12:09 |
|
jihpringle joined #evergreen |
12:15 |
Dyrcona |
:) |
12:31 |
|
bmills joined #evergreen |
12:32 |
|
sandbergja joined #evergreen |
12:48 |
bshum |
Hmm, have you guys been removing RC4 from the cipher suite for SSL config for apache? I'm thinking about it again today while perusing things. |
12:54 |
|
krvmga joined #evergreen |
12:55 |
|
ckolasinski left #evergreen |
12:57 |
berick |
bshum: we have |
12:58 |
dbs |
bshum: I use https://wiki.mozilla.org/Security/Server_Side_TLS |
12:58 |
dbs |
SSLCipherSuite ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-DSS-AES128-GCM-SHA25 6:kEDH+AESGCM:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:EC DHE-ECDSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-DSS-AES128- |
12:58 |
bshum |
Yowza |
12:58 |
* bshum |
might just try that |
12:59 |
dbs |
mozilla updates their recommended config quite regularly |
12:59 |
bshum |
dbs++ # thanks for sharing :D |
13:00 |
dbs |
We should perhaps link that from the docs somewhere. Once upon a time the evergreen book was going to have a "Hardening your Evergreen install" chapter |
13:01 |
bshum |
Indeed. |
13:20 |
|
jwoodard joined #evergreen |
13:25 |
mmorgan |
Quick question about selfcheck, is there a way to have it automatically login with staff credentials? |
13:26 |
mmorgan |
Most of our stations are touch screens with no keyboard. |
13:29 |
eeevil |
mmorgan: you can make those staff logins last ... a really long time (excepting memcached restarts), but not auto-login |
13:30 |
eeevil |
mmorgan: you know, actually, if you use the auth proxy from 2.6 and before (still in there) and you don't show the URL bar, you could use basic-auth params in the URL |
13:31 |
eeevil |
and that would be auto-login |
13:31 |
eeevil |
but, you'd be putting the staff user and pw into the url, so you want to be /really/ sure patrons can't ever see that |
13:32 |
jeff |
relying on "don't show the url bar" for the security of a staff password might be more risk than you're willing to accept. |
13:32 |
eeevil |
jeff: right :) |
13:32 |
* bshum |
sees your risk and bets 20 more. |
13:32 |
eeevil |
but, hey, mmorgan asked for "how" not "should we" ;) |
13:33 |
mmorgan |
ok, thanks for the input. Yeah. Just because one CAN doesn't mean one SHOULD ;-) |
13:34 |
jeff |
ELIMINATE patron password problems with this ONE WEIRD DATABASE TRIGGER -- DBAs HATE HIM! |
13:34 |
* mmorgan |
must run to lunch, but will ponder upon return |
13:34 |
csharp |
@coin |
13:34 |
pinesol_green |
csharp: heads |
13:40 |
Dyrcona |
@coin |
13:40 |
pinesol_green |
Dyrcona: tails |
13:40 |
bshum |
@coin |
13:40 |
pinesol_green |
bshum: tails |
13:41 |
* Dyrcona |
looks around for Rosencrantz and Guildenstern. |
13:42 |
jonadab |
We have a (non-ILS) thing here that actually authenticates staff by IP address. |
13:43 |
jonadab |
Of course, to have one of the IP addresses that will get you authenticated, you have to be physically connected to the staff portion of the network; otherwise you'd be on the wrong side of a firewall. |
13:43 |
jeff |
GREETINGS PROFESSOR ROSENCRANTZ |
13:43 |
jeff |
WOULD YOU LIKE TO PLAY AT QUESTIONS? |
13:43 |
Dyrcona |
Oh sure, lots of database vendors do that. |
13:43 |
Dyrcona |
jeff: Y'know they're dead the whole time, right? ;) |
13:43 |
jeff |
Why would you think I didn't know that? |
13:43 |
Dyrcona |
;) |
13:44 |
* Dyrcona |
looks around for Tom Stoppard. |
13:44 |
* jeff |
imagines a new script -- "Emoticon! One - Love!" |
13:44 |
Dyrcona |
I think I need a new script writer for my life. The current has too dark of a sense of humor. :) |
13:44 |
jeff |
Can emoticons be questions? Can emoji be questions? |
13:45 |
Dyrcona |
That is the question! |
13:45 |
jonadab |
The emoji that cannot be questions are not the true emoji. |
13:45 |
Dyrcona |
These aren't the emoji we're looking for. :) |
13:46 |
jonadab |
Ah, sooo. |
13:46 |
Dyrcona |
On an Evergreen note, this is what I like to see before testing something: -rw-rw-r-- 1 opensrf opensrf 0 Mar 10 13:36 osrfsys.log |
13:47 |
* Dyrcona |
hugs truncate -s0 |
13:53 |
Dyrcona |
@coin |
13:53 |
pinesol_green |
Dyrcona: tails |
14:06 |
bshum |
dbs: Did you guys choose the "intermediate compatibility" list? |
14:07 |
bshum |
I'm tempted to go for broke and take Modern Compatibility, but I keep getting nervous twitches with IE |
14:07 |
bshum |
IE-- |
14:07 |
Dyrcona |
IE6 on XP and Java 6 are not compatible even with the intermediate list. |
14:08 |
Dyrcona |
At least, according to SSLLabs |
14:08 |
bshum |
Right. |
14:08 |
bshum |
But I want that dead for sure :) |
14:08 |
dbs |
Intermediate, yes. |
14:08 |
bshum |
I just feel like maybe giving people IE7 might be good. |
14:09 |
bshum |
Stupid Vista users |
14:10 |
dbs |
Yeah, I can't justify breaking IE < 11 |
14:10 |
Dyrcona |
I can't imagine how giving anyone IE7 could be good. |
14:10 |
dbs |
So just intermediate. |
14:10 |
Dyrcona |
;) |
14:10 |
Dyrcona |
I'd go with intermediate. |
14:10 |
Dyrcona |
Or, rather, I did. |
14:10 |
dbs |
And we use HTTPS-only, so Modern would very much break IE < 11. |
14:11 |
bshum |
True that. |
14:11 |
* bshum |
steps back from the cliff a bit then |
14:27 |
jonadab |
Requiring IE users to upgrade to at least IE8 seems reasonable. |
14:27 |
jonadab |
I think IE8 will install on everything back through XP. |
14:28 |
Dyrcona |
Requiring IE users to switch to Firefox or Chromium sounds reasonable. :) |
14:28 |
jonadab |
Heh. |
14:28 |
jonadab |
Good luck with that. |
14:28 |
jonadab |
Although, a lot of progress has been made. Die-hard IE-only users are well down into minority country these days, so that's progress. |
14:29 |
Dyrcona |
Just for fun I wrote something that would tell IE users that they couldn't use a site and provided links to download a different browser. |
14:29 |
jonadab |
Oh, I remember when half the sites on the web did that. |
14:29 |
Dyrcona |
I know of some users who don't trust software that didn't come with the computer. |
14:29 |
jonadab |
Back when IE was new and none of the websites had started to support it yet. |
14:30 |
jonadab |
Anything other than Netscape got the "install our favorite browser" button. |
14:30 |
Dyrcona |
Of course, you can't trust the crap that the vendor loaded in the first place.... *Cough* Lenovo *Cough* |
14:30 |
jonadab |
Lenovo is not unique in that regard. |
14:30 |
Dyrcona |
Not by a long shot. |
14:30 |
jonadab |
My normal practice is to not trust software unless I get it from the people who wrote it. |
14:30 |
Dyrcona |
Dell used to put a lot of crap on "home" PCs. |
14:31 |
Dyrcona |
My normal practice is buy with no O/S installed, just the hardware, please. |
14:31 |
bshum |
Remember google chrome frame plugin? Ah, JSPAC... I do NOT miss you. |
14:31 |
Dyrcona |
bshum: Actually, I don't remember that, but I have a very selective memory. :) |
14:31 |
jonadab |
Hah. |
14:32 |
bshum |
:P |
15:02 |
dbs |
bshum: ugh, yes, I remember that |
15:03 |
dbs |
JSPAC was almost self-aware |
15:36 |
JSPAC |
dbs: YES, I WAS |
15:38 |
kmlussier |
csharp++ |
15:40 |
|
akilsdonk joined #evergreen |
15:41 |
gmcharlt |
Clearly, the really problem with library free software projects is how they keep spawning off AIs by accident! ;) |
15:42 |
eeevil |
HAVEN'T ANY OF YOU READ NECROMANCER?!?! |
15:42 |
gmcharlt |
@quote add <dbs> JSPAC was almost self-aware ... <JSPAC> dbs: YES, I WAS |
15:42 |
pinesol_green |
gmcharlt: The operation succeeded. Quote #107 added. |
15:43 |
eeevil |
er... neuromancer |
15:43 |
eeevil |
NTS: joke works better when you do it right |
15:44 |
dbs |
csharp++ |
15:44 |
* dbs |
actually did read at least one book in the Necromancer series |
16:24 |
Dyrcona |
Does $self->method_lookup($method)->run(args) actually make a request or it does it just run the method directly? |
16:27 |
Dyrcona |
Never mind, I found the answer in OpenSRF::Application, I think. |
16:29 |
Dyrcona |
BTW, OpenSRF perl code appears to be indented with tabs. Just throwing that out there. |
16:30 |
Dyrcona |
The answer to my question appears to be "It depends." |
16:30 |
Dyrcona |
Looks like it usually will make an OpenSRF call, but under certain circumstances (i.e. when $self->{remote} is undefined) it will just execute the code. |
16:31 |
jeff |
hah. service bulletin that might explain some of the random lockups we've had on this unit: 12V supply incorrectly wired to 5V input on one of the internal components. :-) |
16:31 |
Dyrcona |
Well, that'll do it. |
16:35 |
jeff |
@eightball will the fix be worse than the freeze? |
16:35 |
pinesol_green |
jeff: The outlook is hazy, please ask again later. |
16:35 |
jeff |
@eightball is it later yet? |
16:35 |
pinesol_green |
jeff: The outlook is poor. |
16:40 |
kmlussier |
@eightball is the outlook clearer yet? |
16:40 |
pinesol_green |
kmlussier: Yes! |
16:42 |
Dyrcona |
@eightball Does it blend? |
16:42 |
pinesol_green |
Dyrcona: The answer is def-- oooh! shiny thing! |
16:44 |
Dyrcona |
@eghtball Is the outlook cloudy? |
16:44 |
pinesol_green |
Dyrcona: MARC still isn't dead yet, alas |
16:44 |
Dyrcona |
Oops. |
16:44 |
* Dyrcona |
calls it a day. |
16:45 |
jonadab |
Haha. I still remember my horror the first time I ever saw a MARC record. |
16:46 |
Dyrcona |
That horror comes back every time you look at one. |
16:47 |
Dyrcona |
Ever look at a raw binary MARC record? |
16:47 |
|
vlewis joined #evergreen |
17:02 |
|
mmorgan left #evergreen |
17:05 |
eeevil |
@later tell Dyrcona re method_lookup(), if it can't resolve the method name locally, it will go to the router, get a list of services, go to each and gather their methods, then try to resolve the method by name again. it supports simple service discovery: "I don't care who implements this method, just do what I want" ... that functionality is not used inside evergreen (we only resolve local methods via method_lookup) |
17:05 |
pinesol_green |
eeevil: The operation succeeded. |
17:12 |
pinesol_green |
Incoming from qatests: Test Success - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
17:36 |
csharp |
@dunno add The horror... The horror... |
17:36 |
pinesol_green |
csharp: The operation succeeded. Dunno #36 added. |
17:56 |
|
Newziky left #evergreen |
18:06 |
|
eady joined #evergreen |
18:59 |
|
jonadab joined #evergreen |
19:19 |
|
bmills joined #evergreen |
21:15 |
|
akilsdonk joined #evergreen |
23:16 |
|
akilsdonk joined #evergreen |