| Time |
Nick |
Message |
| 00:09 |
bshum |
Well, playing with the Ubuntu 16.04 beta1 server build and OpenSRF is going to be interesting. |
| 00:10 |
jeff |
oh yes? |
| 00:10 |
bshum |
I can confirm what you saw csharp with the apache2-mpm-prefork no longer being around. I installed apache2 and apache2-dev and that seemed to take care of the needed bits. |
| 00:10 |
bshum |
The part that's bad seems to be ejabberd |
| 00:10 |
bshum |
The legacy authentication style we're using with the XML doesn't wor |
| 00:10 |
bshum |
*work |
| 00:10 |
jeff |
as i stated back then, and as mentioned in the ticket csharp created, apache2-mpm-prefork has been a dummy package for a while -- it's not "needed". |
| 00:11 |
bshum |
Looking up the stuff on XMPP, I think that they're obsoleted the approach we use now |
| 00:11 |
bshum |
jeff: Yep. |
| 00:11 |
bshum |
http://xmpp.org/extensions/xep-0078.html |
| 00:12 |
bshum |
If I read XMPPReader.pm and XMPPMessage.pm right, that's the style we're using now |
| 00:12 |
bshum |
And so I can see we're sending the auth with xmlns='jabber:iq:auth' and related params |
| 00:12 |
bshum |
But that doesn't get us anywhere |
| 00:12 |
bshum |
And ejabberd doesn't go any further, so of course opensrf doesn't start up |
| 00:13 |
bshum |
ejabberd 16.01 is the version that's bundled with Ubuntu 16.04. |
| 00:13 |
bshum |
ejabberd 14 is what went with Debian Jessie |
| 00:14 |
bshum |
16.01 is coming though in stretch, I guess. |
| 00:18 |
bshum |
Anywho, just playing with it all. Still early on. |
| 00:24 |
jeff |
i suspect that you can fix that by adjusting config. |
| 00:25 |
jeff |
but more testing required. :-) |
| 00:27 |
jeff |
there are a number of auth/password related config tweaks that the debian package incorporates. |
| 00:31 |
bshum |
jeff: Yep, you're right, I found it in the ejabberd.yml config options |
| 00:31 |
bshum |
If I set auth_password_format: plain |
| 00:31 |
bshum |
Instead of scram |
| 00:32 |
bshum |
And register my users with that |
| 00:32 |
bshum |
Then it allows me to use the plain text legacy authentication style |
| 00:32 |
bshum |
And then opensrf starts, and I can perform a simple test for math which works |
| 00:32 |
bshum |
So we could kick that ball down the road a little further I guess. |
| 00:56 |
bshum |
For Evergreen, add libpcre3-dev to the makefile prereq's |
| 01:01 |
jeff |
bshum++ |
| 01:02 |
bshum |
Yeah sorry, taking notes in channel while I force my way through an install attempt :) |
| 01:07 |
bshum |
Bah, concerto data doesn't load with PG 9.5 |
| 01:08 |
jeff |
no? |
| 01:08 |
jeff |
where does it appear to fail? |
| 01:08 |
bshum |
Well it bombs on something in the last part |
| 01:08 |
bshum |
psql:transactions.sql:139: ERROR: invalid return type |
| 01:08 |
bshum |
DETAIL: SQL key field type text does not match return key field type integer. |
| 01:08 |
bshum |
CONTEXT: SQL statement "SELECT 2 IN (SELECT id FROM permission.grp_ancestors(grp))" |
| 01:08 |
bshum |
PL/pgSQL function inline_code_block line 15 at IF |
| 01:08 |
bshum |
I'll try to track that down next |
| 01:08 |
bshum |
Seeing if autogen works and apache startup |
| 01:09 |
bshum |
And voila, catalog works |
| 01:09 |
bshum |
At least sign into my account |
| 01:09 |
bshum |
No items to speak of due to the error out |
| 01:10 |
bshum |
But that means that most of the Evergreen install will work for Ubuntu 16.04 once we make the Makefile for it. |
| 01:10 |
bshum |
Yay :) |
| 01:37 |
bshum |
Okay, filed https://bugs.launchpad.net/opensrf/+bug/1551090 for OpenSRF and https://bugs.launchpad.net/evergreen/+bug/1551084 for Evergreen |
| 01:37 |
pinesol_green |
Launchpad bug 1551090 in OpenSRF "Add OpenSRF support for Ubuntu 16.04 Xenial Xerus" [Wishlist,Triaged] |
| 01:37 |
pinesol_green |
Launchpad bug 1551084 in Evergreen "Add Evergreen support for Ubuntu 16.04 Xenial Xerus" [Wishlist,In progress] - Assigned to Ben Shum (bshum) |
| 01:38 |
* bshum |
heads off to sleep :P |
| 01:39 |
bshum |
jeff++ # sounding board feedback :) |
| 01:39 |
bshum |
csharp++ # starting the good fight for OpenSRF |
| 01:52 |
|
dbs joined #evergreen |
| 06:40 |
|
rlefaive joined #evergreen |
| 07:35 |
|
rjackson_isl joined #evergreen |
| 07:51 |
|
JBoyer joined #evergreen |
| 07:55 |
|
ericar joined #evergreen |
| 08:04 |
|
mrpeters joined #evergreen |
| 08:14 |
|
stompro__ joined #evergreen |
| 08:33 |
kmlussier |
Happy Leap Day #evergreen! |
| 08:49 |
|
Dyrcona joined #evergreen |
| 09:25 |
|
jvwoolf joined #evergreen |
| 09:40 |
|
yboston joined #evergreen |
| 09:49 |
csharp |
bshum++ # ubuntu xenial bugs |
| 09:59 |
|
mllewellyn joined #evergreen |
| 10:04 |
|
rlefaive joined #evergreen |
| 10:20 |
|
stevewills joined #evergreen |
| 10:21 |
stevewills |
oh! this is where those evergreen people STILL are :) |
| 10:23 |
csharp |
EVERYONE RUN! stevewills found us! |
| 10:25 |
stevewills |
I am migrating a small library use 2.8 docs. While trying to generate copies for holdings I find they use the same call number for several different items, which, seems to be creating cross reference barcode. i.e. each barcode points at every bib with that call number. Am I missing a step? |
| 10:25 |
stevewills |
hi Chris :) |
| 10:30 |
csharp |
:-D |
| 10:30 |
Dyrcona |
Hmm. Moving an Evergreen database to a new server is not as easy as it sounds. |
| 10:31 |
Dyrcona |
pg_restore: [archiver (db)] Error from TOC entry 9929; 0 6033349 TABLE DATA event superuser |
| 10:31 |
Dyrcona |
pg_restore: [archiver (db)] could not execute query: ERROR: relation "event" does not exist |
| 10:31 |
Dyrcona |
I must be missing something obvious. |
| 10:38 |
csharp |
Dyrcona: relevant? https://dba.stackexchange.com/questions/90258/pg-restore-archiver-db-could-not-execute-query-error-schema-public-alre |
| 10:38 |
jeff |
Dyrcona: no previous error? |
| 10:38 |
Dyrcona |
I think I figured it out. |
| 10:38 |
Dyrcona |
This server was running PostgreSQL already, but didn't have plperl installed. |
| 10:38 |
* csharp |
has apparently hit that error before because that link was shown as previously visited in his browser |
| 10:39 |
Dyrcona |
That's better. |
| 10:39 |
Dyrcona |
Now, I just get this: psql:/raid/scripts/create_database_9_1.sql:23: ERROR: could not open extension control file "/usr/share/postgresql/9.3/extension/pgtap.control": No such file or directory |
| 10:39 |
Dyrcona |
Which isn't fatal. |
| 10:40 |
Dyrcona |
csharp: Thanks for the link, but that was not it. |
| 10:46 |
Dyrcona |
new row for relation "z3950_index_field_map" violates check constraint "valid_z3950_attr_type" |
| 10:46 |
Dyrcona |
Heh. Thank you -j 4. :) |
| 10:46 |
Dyrcona |
But, I've got a script to fix that. |
| 10:53 |
JBoyer |
Dyrcona: you could also apply my fix that's coming in 2.10. Don't let the door hit you on the way out check constraint error! |
| 10:54 |
Dyrcona |
JBoyer: I just might do that. |
| 10:55 |
JBoyer |
I suppose it's possible the upgrade script will complain about a duplicate constraint, but I imagine you can keep tabs on that before it's an issue. |
| 10:56 |
Dyrcona |
Ok. |
| 11:00 |
stevewills |
for future googlers: adding: AND sm.bibkey = acn.record to the end of the SQL entitled "Generate the copies for your holdings" seems to be a reasonable workaround. Although I am still not happy with all the junk records hanging around in my call_number table. |
| 11:01 |
|
Christineb joined #evergreen |
| 11:11 |
|
rhamby joined #evergreen |
| 11:14 |
* Dyrcona |
wonders how long this restore will take. |
| 11:21 |
|
gsams joined #evergreen |
| 11:54 |
|
mmorgan joined #evergreen |
| 11:56 |
* mmorgan |
is trying to run an action trigger to mark items long overdue. I'm getting an error. |
| 11:56 |
mmorgan |
[ERR :20827:MarkItemLongOverdue.pm:35:] trigger: MarkItemLongOverdue require 'editor' param |
| 11:57 |
mmorgan |
anyone run into this? Maybe csharp? |
| 11:57 |
tsbere |
mmorgan: I know this one! |
| 11:57 |
|
jeffdavis joined #evergreen |
| 11:58 |
tsbere |
mmorgan: The "Event Parameters" tab from clicking on the "Name" link needs an editor defined. |
| 11:59 |
mmorgan |
tsbere: Oh! I think I remember that now! Checking… |
| 11:59 |
tsbere |
mmorgan: In this case I believe the editor should be the DB ID of the person the action should be attributed to |
| 12:00 |
Dyrcona |
@blame Ubuntu |
| 12:00 |
pinesol_green |
Dyrcona: Ubuntu stole bshum's tux doll! |
| 12:02 |
bshum |
Noooooooooooooo |
| 12:03 |
Dyrcona |
heh |
| 12:03 |
Dyrcona |
I think they busted the packaging of 9.3. |
| 12:03 |
csharp |
@blame Ubuntu |
| 12:03 |
pinesol_green |
csharp: Forget it, Jake. It's just Ubuntu. |
| 12:03 |
Dyrcona |
pg_config says I have 9.4 installed, but the packages are all 9.3. |
| 12:03 |
csharp |
Dyrcona: I never had issues with Ubuntu-packaged 9.3, if that helps troubleshoot |
| 12:03 |
Dyrcona |
The pgtap version they package, 0.90, only works with 9.3. |
| 12:03 |
bshum |
Did you use their apt source? |
| 12:04 |
Dyrcona |
I'm trying to install pgtap from source, but it can't find 9.4 installed on my machine. |
| 12:04 |
Dyrcona |
bshum: No, I did not. |
| 12:04 |
Dyrcona |
I was not planning to use the database much on this machine, at least not for Evergreen. |
| 12:05 |
Dyrcona |
I think I'll just blow this box out and install everything from source. |
| 12:05 |
Dyrcona |
That should only take a week or two. |
| 12:05 |
csharp |
LFS! |
| 12:05 |
mmorgan |
tsbere: Thanks, that was it! |
| 12:05 |
mmorgan |
tsbere++ |
| 12:06 |
* mmorgan |
fades away. |
| 12:06 |
|
mmorgan left #evergreen |
| 12:06 |
csharp |
Dyrcona: so you're running 9.4 on 14.04? |
| 12:09 |
Dyrcona |
csharp: No, I'm running 9.3 on 14.04 with Ubuntu's packages. They broke the packaging and including something from 9.4, apparently. |
| 12:10 |
csharp |
hmm - weird |
| 12:10 |
* Dyrcona |
thinks the Ubu in Ubuntu comes from Pere Ubu and wonder if Jarry is not somehow behind this absurdity. |
| 12:11 |
Dyrcona |
I really don't have time to deal with this right now, but I feel forced into it. |
| 12:13 |
csharp |
interesting, if I run 'pg_config' on my 14.04 box with 9.4 installed, it correctly shows 9.4, but if I run /usr/bin/pg_config.libpq-dev, it shows 9.5 |
| 12:14 |
Dyrcona |
mine says 9.4 for both, and I have 9.3 only installed and running. |
| 12:16 |
csharp |
If postgresql-server-dev-* is installed, call pg_config from the latest available one. Otherwise fall back to libpq-dev's version. (From the in-line comments at the top of /usr/bin/pg_config) |
| 12:18 |
Dyrcona |
So I should try installing postgresql-server-dev-9.3? |
| 12:19 |
Dyrcona |
csharp++ |
| 12:19 |
csharp |
did that do it? |
| 12:20 |
Dyrcona |
I wouldn't have incremented you if it hadn't. ;) |
| 12:20 |
csharp |
haha |
| 12:20 |
csharp |
ok cool ;-) |
| 12:23 |
|
jihpringle joined #evergreen |
| 12:25 |
Dyrcona |
And, I now have pgtap installed on my server, and the extension created in the database. |
| 12:25 |
Dyrcona |
So, I won't have to worry about that in the future. |
| 12:25 |
Dyrcona |
And the restore is still going. |
| 12:36 |
Dyrcona |
So, for the full lowdown, I did install pgtap from source. |
| 12:36 |
Dyrcona |
I also install the required Perl module via CPAN. |
| 12:37 |
Dyrcona |
I also can't type, apparently. |
| 12:38 |
|
sandbergja joined #evergreen |
| 12:38 |
|
rlefaive joined #evergreen |
| 13:42 |
dbs |
hmm. I wonder why our 2 hour loans are getting 1 day + 2 hours today. On leap day. Hmm. |
| 13:43 |
dbs |
SELECT NOW() + '2 hours'::interval; = '2016-02-29 15:43:15.250027-05' so it's not database-side :/ |
| 13:44 |
dbs |
(closed dates and aouhoo are all good too) |
| 13:50 |
tsbere |
dbs: I think that math happens perl-side, but I could be wrong |
| 13:54 |
tsbere |
dbs: On the other hand, I don't think there should be an issue from perl either...is the xact_start coming out wrong? |
| 13:58 |
* dbs |
is ensconced in a meeting and will poke at it later, but thanks for the thoughts tsbere! |
| 14:07 |
|
rlefaive joined #evergreen |
| 14:39 |
kmlussier |
csharp: bug 1531976 can get a signedoff tag, right? |
| 14:39 |
pinesol_green |
Launchpad bug 1531976 in Evergreen master "Triggered Events UI not loading after visiting Message Center UI and vice-versa" [High,Confirmed] https://launchpad.net/bugs/1531976 |
| 14:43 |
csharp |
kmlussier: done ;-) |
| 14:43 |
kmlussier |
csharp: Thanks! I think my first course of action on bug squashing day is to merge bugs that were signed off during the last bug squashing day. |
| 14:48 |
* tsbere |
remembers that fix |
| 15:02 |
|
jlitrell joined #evergreen |
| 15:17 |
dbs |
heh. due_date=2016-03-01T12:50:48-0800 duration=02:00:00 duration_rule=2_hours_0_renew ... xact_start=2016-02-29T10:50:48-0800 create_time=2016-02-29T10:50:48-0800 |
| 15:17 |
dbs |
¯\_(ツ)_/¯ |
| 15:22 |
|
collum joined #evergreen |
| 15:34 |
tsbere |
dbs: For the sake of argument, does 2_hours_0_renew have a "1 day 2 hours" interval in, say, "extended"? |
| 15:35 |
|
jeffdavis joined #evergreen |
| 15:47 |
mllewellyn |
Looking for some advice. |
| 15:47 |
mllewellyn |
We run a query for Wowbrary that is based in part on the pubdate column of the reporter.real_full_record |
| 15:48 |
mllewellyn |
Only problem is, when the date in 260 is in brackets, the value is not filled into the table, so the query doesn't see it. |
| 15:48 |
mllewellyn |
260 c |
| 15:49 |
mllewellyn |
I'd like to use the date from the fixed field instead, but I'm not sure how to get that into my query. |
| 15:49 |
mllewellyn |
We don't want to add pubdate is NULL to our query, because we end up with magazine issues on our list. |
| 15:50 |
mllewellyn |
Not what our libraries intend to advertise as new items on Wowbrary. |
| 15:50 |
miker |
mllewellyn: what EG version? |
| 15:50 |
tsbere |
mllewellyn: I suspect metabib.record_attr_vector_list combined with metabib.uncontrolled_record_attr_value for recent EG versions |
| 15:51 |
mllewellyn |
2.9.0 |
| 15:51 |
miker |
tsbere: aye, that's where I was heading :) |
| 15:52 |
miker |
mllewellyn: filtering, or just need to expose the data? |
| 15:52 |
mllewellyn |
filtering, I guess, so only new titles get put out on Wowbrary. |
| 15:52 |
mllewellyn |
We don't want all newly created items, just ones newly published. |
| 15:53 |
mllewellyn |
Our current query: SELECT DISTINCT ac.circ_lib AS "Library ID", acn.record AS "Record ID", |
| 15:53 |
mllewellyn |
rmsr.isbn AS "ISBN", rmsr.title AS "Title", rmsr.pubdate AS "Publication Year", |
| 15:53 |
mllewellyn |
date(ac.create_date) AS "Item Create Date" |
| 15:53 |
mllewellyn |
FROM asset.copy ac |
| 15:53 |
mllewellyn |
JOIN asset.call_number acn ON acn.id = ac.call_number |
| 15:54 |
|
mllewellyn joined #evergreen |
| 15:54 |
miker |
mllewellyn: you can join metabib.record_sorter on source = bib id where attr = pubdate |
| 15:54 |
miker |
that's pulled from date1 |
| 15:54 |
mllewellyn |
I'll give thta a try. |
| 15:55 |
mllewellyn |
miker ++ |
| 15:55 |
miker |
something like JOIN metabib.record_sorter rs ON (rs.source = acn.record AND rs.attr = 'pubdate') |
| 15:56 |
miker |
filter (or select) rs.value ... and cast to int for filtering, if you like. rs.value::INT > 2014 (or whatever) |
| 15:57 |
miker |
may need to protect that cast from empty (not NULL) values with a nullif() |
| 16:03 |
mllewellyn |
I will play with it, thanks again. |
| 16:16 |
dbs |
tsbere: good thought, but 02:00:00 across the board |
| 16:18 |
dbs |
oh geez |
| 16:19 |
dbs |
aouhoo has dow_0_open / close as 00:00:00 |
| 16:19 |
dbs |
meh |
| 16:27 |
jeff |
heh |
| 16:29 |
tsbere |
dbs: AKA, it is bumping it up a day due to that? ;) |
| 16:29 |
mllewellyn |
miker: it didn't like being cast as an integer because of a date entered as "19uu'. Got good results when I took out the INT part. |
| 16:33 |
dbs |
tsbere: yeah, and me having looked at dow_0 and thought "Sunday" |
| 16:34 |
dbs |
thus ignoring the closed hours. |
| 16:36 |
JBoyer |
dow_0 is Monday? |
| 16:37 |
JBoyer |
(well, I mean, apparently, given the way this has gone.) |
| 16:37 |
JBoyer |
That is sub-optimal. :( |
| 16:37 |
JBoyer |
An issue for another time. |
| 16:39 |
tsbere |
dbs: Then I will stop wondering if there is a timezone issue with leap year calcs |
| 16:41 |
dbs |
sorry for the foolishness folks |
| 16:42 |
dbs |
@later tell JBoyer yes, despite Perl and PostgreSQL both denoting day 0 as Sunday, it's one of those fun quirks to try and keep in the back of your mind :) |
| 16:42 |
pinesol_green |
dbs: The operation succeeded. |
| 16:45 |
* tsbere |
finds that one method for MySQL starts with Monday as 0, but that is one of the only references he has found so far to that |
| 16:45 |
tsbere |
So I dunno why that was done in EG |
| 16:46 |
miker |
DateTime has a function called day_of_week_0 |
| 16:47 |
miker |
because there's confusion among different systems as to what 1) the first day of the week is and 2) whether to start with 0 or 1, I went with the most explicitly named method |
| 16:47 |
miker |
seems, though, that DateTime stopped documenting dow0() at some point since 2004 |
| 16:48 |
miker |
for some back story... |
| 16:49 |
* miker |
disappears back into the shadows |
| 17:13 |
dbs |
miker++ |
| 17:18 |
|
bmills joined #evergreen |
| 19:56 |
|
bwicksall joined #evergreen |
