| Time |
Nick |
Message |
| 02:55 |
|
Jillianne joined #evergreen |
| 04:31 |
pinesol_green |
News from qatests: Test Failure <http://testing.evergreen-ils.org/~live> |
| 04:52 |
|
gsams_ joined #evergreen |
| 04:54 |
|
BigRig joined #evergreen |
| 07:12 |
|
agoben joined #evergreen |
| 07:13 |
|
rjackson_isl joined #evergreen |
| 07:14 |
|
Callender joined #evergreen |
| 07:48 |
|
kmlussier joined #evergreen |
| 07:53 |
csharp |
so... I discovered that one problem we had with our A/T meltdown over the weekend was about 9K patrons had an sms_carrier of "", which caused the reactor to error, and immediately after, the cstore drone died and all was lost |
| 07:54 |
csharp |
found with select count(*) from actor.usr where id in (select usr from actor.usr_setting where name = 'opac.default_sms_carrier' and value ='""'); |
| 07:55 |
csharp |
we don't understand how those would have happened, though, because those are selected with a dropdown menu |
| 07:56 |
csharp |
oh - oops - it's one of those dojo dropdown/typeahead menu |
| 07:56 |
csharp |
s |
| 07:57 |
JBoyer |
csharp, yeah, and there's no way currently to completely remove user settings or stat cats. Once one is set it's always something, even if it's just "" |
| 07:58 |
csharp |
well, I'm planning to alter the get_sms_gateway_email sub to make it care about that |
| 07:58 |
csharp |
currently it checks that the sms_notify field is defined/non-blank, but it charges ahead and uses the sms_carrier value |
| 08:02 |
|
Dyrcona joined #evergreen |
| 08:10 |
Dyrcona |
Great. My 2.10.7 to 2.12.2 upgrade script blows up on last Wednesday's dump. |
| 08:10 |
Dyrcona |
It blows up early in 0983. I think because we have multiple holds with th same target, but I'm looking. |
| 08:12 |
Dyrcona |
psql:2.10.7-2.12.1-upgrade-db.sql:109: ERROR: more than one row returned by a subquery used as an expression |
| 08:13 |
Dyrcona |
That's from the create table reporter.hold_request_record statement. |
| 08:13 |
Dyrcona |
I think I need to add distinct on one or more of the subqueries. |
| 08:13 |
|
jvwoolf joined #evergreen |
| 08:21 |
csharp |
okay - perl question... in this line: if (! defined $sms_notify || $sms_notify eq '' || ! defined $sms_carrier || $sms_carrier eq ''), will those checks be true for values that are literally in the database as ""? |
| 08:21 |
Dyrcona |
Hm.. The subquery in the case for volume holds is returning two rows in this database. |
| 08:21 |
csharp |
that is, postgres sees them as '""' |
| 08:22 |
Dyrcona |
csharp: They'll be true if they are an empty string in Perl. |
| 08:22 |
csharp |
ok - cool |
| 08:22 |
csharp |
Dyrcona: thanks |
| 08:22 |
Dyrcona |
Since they're stored as JSON, the answer is probably yes. |
| 08:22 |
Dyrcona |
Most likely yes. |
| 08:23 |
Dyrcona |
I'm going to that query in a database with data of a similar age that was not restored with 63 ignored errors. Maybe it's just a bad restore. |
| 08:28 |
* csharp |
directs the logs to bug 1694696 |
| 08:28 |
pinesol_green |
Launchpad bug 1694696 in Evergreen master "SMS Action/Triggers fail on "blank" sms_carrier" [High,New] https://launchpad.net/bugs/1694696 |
| 08:28 |
csharp |
also Bmagic ^^ |
| 08:28 |
csharp |
Bmagic: that could explain your crazy cstore issue |
| 08:29 |
|
jvwoolf1 joined #evergreen |
| 08:31 |
Dyrcona |
csharp: Looks good to me. I'll let Bmagic test it, since he's run into it. |
| 08:31 |
Dyrcona |
Anyway, I think my upgrade script issue is gonna set my testing back a day. I'll have to do a new restore, and that takes about 6 hours on this server. |
| 08:32 |
Dyrcona |
Yeah. The query returns only 1 row on a non-botched database. |
| 08:38 |
|
mmorgan joined #evergreen |
| 08:38 |
Dyrcona |
bleh. |
| 08:39 |
Dyrcona |
Why does a restore NOT work unless I use the options to drop and recreate everything? |
| 08:39 |
jeff |
"not work"? |
| 08:39 |
jeff |
or, to quote you more accurately, "NOT work"? |
| 08:39 |
Dyrcona |
Even restoring into an empty database, I get errors: pg_restore: [archiver (db)] could not execute query: ERROR: function metabib.compile_composite_attr(integer) does not exist |
| 08:40 |
Dyrcona |
Command was: ALTER FUNCTION metabib.compile_composite_attr(cattr_id integer) OWNER TO evergreen; |
| 08:40 |
Dyrcona |
Ah stupid path issues. |
| 08:40 |
jeff |
is that your earliest error? |
| 08:40 |
Dyrcona |
No. |
| 08:41 |
jeff |
or was there an error creating the.. yeah, thought that might be the case. |
| 08:41 |
Dyrcona |
It couldn't create the function because it couldn't find a type in the evergreen schema..... |
| 08:41 |
Dyrcona |
I'll start over. |
| 08:41 |
jeff |
because the function def used an unqualified reference? |
| 08:42 |
jeff |
best option there is to fully qualify the references (in this case, to the type) |
| 08:42 |
jeff |
metabib.compile_composite_attr doesn't ring a bell as being one that's tripped us up before. |
| 08:42 |
Dyrcona |
yeah, well I'm restoring an archived dump. |
| 08:42 |
jeff |
but wait, it doesn't fail when you're using pg_restore to create the db instead of creating it first? |
| 08:43 |
Dyrcona |
jeff: When I restore -c -C -d postgres so that the db is restored with the name evergreen, it works. |
| 08:43 |
Dyrcona |
When I create an empty database and restore with just -d dbname it fails. |
| 08:43 |
jeff |
okay. what version of evergreen is the database at restore time? |
| 08:44 |
jeff |
i'm curious to do some more testing myself later. |
| 08:44 |
Dyrcona |
Pg 9.2 restored to a Pg 9.5 db server. |
| 08:44 |
Dyrcona |
Oh sorry, Evergreen: 2.10.7 |
| 08:44 |
jeff |
using pg_dump 9.2 and pg_restore 9.5? |
| 08:44 |
Dyrcona |
Yes. |
| 08:45 |
jeff |
thanks! |
| 08:45 |
Dyrcona |
I'm going to try manually setting the path in the new database. |
| 08:46 |
Dyrcona |
I'm using create_database_extensions.sql from 2.10 to create the database, fwiw. |
| 08:46 |
jeff |
in my experience, because pg_restore explicitly sets the search path during the restore, it doesn't much matter what you set it to at a user setting or db setting level, or even if you injected it into the session. |
| 08:47 |
jeff |
re-creating the failed objects/functions post-restore is sometimes simple enough, but long term the best option for me has been to fix the (broken, IMO) references. |
| 08:47 |
jeff |
i think i did open at least one lp bug on the most recent one we hit. |
| 08:47 |
jeff |
and started looking for others. |
| 08:48 |
* jeff |
looks for the lp bug in question |
| 08:48 |
Dyrcona |
My user name is evergreen also. |
| 08:48 |
jeff |
what is the database name in the dump that you are restoring? |
| 08:48 |
Dyrcona |
So, I'll just restore to my evergreen database and then recreate the other database from evergreen. |
| 08:48 |
Dyrcona |
The database name is evergreen. |
| 08:48 |
jeff |
(relevant when using -c -C) |
| 08:49 |
Dyrcona |
And, I'm set back a day..... |
| 08:50 |
Dyrcona |
I also specifically want my data from last week for testing purposes. I'm going to test URI deletes with the branch on Lp 1482757, but that's not particularly relevant. :) |
| 08:50 |
pinesol_green |
Launchpad bug 1482757 in Evergreen "Loading records with located URIs should not delete and recreate call_numbers" [Undecided,Confirmed] https://launchpad.net/bugs/1482757 |
| 08:50 |
jeff |
bug 1671150 -- looks like i need to make a working branch. |
| 08:50 |
pinesol_green |
Launchpad bug 1671150 in Evergreen "Unqualified references in evergreen.unaccent_and_squash lead to index creation failures with pg_restore" [Undecided,In progress] https://launchpad.net/bugs/1671150 - Assigned to Jeff Godin (jgodin) |
| 08:51 |
Dyrcona |
I'm not getting errors from unaccent_and_squash, though. |
| 08:52 |
jeff |
Dyrcona: do you know which type failed on the creation of metabib.compile_composite_attr? |
| 08:52 |
Dyrcona |
CREATE FUNCTION compile_composite_attr(cattr_def text) RETURNS evergreen.query_int blows up because it can't find the type evergreen.query_int |
| 08:52 |
jeff |
Dyrcona: your database is Evergreen 2.10.7, and the unaccent indexes in that bug were not introduced until 2.11 |
| 08:53 |
Dyrcona |
I know. :) |
| 08:53 |
Dyrcona |
ERROR: type "evergreen.query_int" does not exist |
| 08:54 |
Dyrcona |
Almost the same options, but restoring to a db name evergreen works. |
| 08:54 |
jeff |
in a 2.10 db i have public.query_int but no evergreen.query_int |
| 08:55 |
Dyrcona |
pg_restore -U evergreen -h localhost -C -c -d postgres -j 8 eg-backup.Wednesday-20170524.dmp |
| 08:55 |
Dyrcona |
That works. |
| 08:56 |
jeff |
does the source database where this dump was created have public.query_int, evergreen.query_int, or both? |
| 08:58 |
Dyrcona |
PgAdmin 3 apparently doesn't list types. I'll have to check with psql. |
| 08:59 |
jeff |
\dT is your friend |
| 09:00 |
Dyrcona |
Yeah, I know. |
| 09:00 |
Dyrcona |
It has evergreen.query_int and not public.query_int |
| 09:02 |
|
bos20k joined #evergreen |
| 09:04 |
jeff |
i would guess then that \dx shows the queryint extension as being present in the evergreen schema and not the public schema |
| 09:05 |
|
maryj joined #evergreen |
| 09:07 |
Dyrcona |
No queryint extension, but intarray is in the evergreen schema. |
| 09:07 |
jeff |
er, yeah -- i misspoke. |
| 09:07 |
Dyrcona |
Ah, I bet that's it. |
| 09:08 |
jeff |
yeah. that seems to be unusual. i have production 2.10 and 2.11 databases that both have the intarray extension in the public schema. |
| 09:08 |
jeff |
though i note now that the 2.10 db has pgcrypto in the evergreen schema, likely due to search path settings + the upgrade script not specifying an explicit schema. |
| 09:09 |
Dyrcona |
pgcrypto is also in the evergreen schema, others in public or pgcatalog. |
| 09:10 |
Dyrcona |
So, I'll wager that create_database_extensions.sql that I'm using creates intarray in the public schema. |
| 09:11 |
Dyrcona |
I wonder if the restore would work if I don't create the extensions? |
| 09:12 |
Dyrcona |
Oh, well. I'll try some other time. I've got the other restore started. I might as well wait. |
| 09:22 |
jeff |
i'm curious how you ended up with intarray in the evergreen schema. |
| 09:23 |
jeff |
possibly because 2.5.3-2.6.0-upgrade-db.sql creates it with an explicit schema of public, but 0864.MVF_CRA-upgrade.sql does not specify a schema. |
| 09:35 |
Dyrcona |
jeff: I wasn't here at that time. I inherited this database. |
| 09:35 |
Dyrcona |
I would think that is the most likely culprit. |
| 09:41 |
|
kmlussier joined #evergreen |
| 09:47 |
Dyrcona |
Should deleted records have asset.uri entries? |
| 09:48 |
Dyrcona |
It appears that they do, but I'm asking if people think that they should. |
| 09:50 |
jeff |
okay, and in my case with pgcrypto being in the evergreen schema, that's fine unless i lose my database-level search_path setting. then Things Break. |
| 09:50 |
JBoyer |
Unless we make un-deletion more involved (a full reingest, possibly more) or make it impossible without poking around in the database manually they should probably stick around. |
| 09:50 |
mmorgan |
Dyrcona: In my experience, once added, asset.uri entries don't go away. Part of lp 1482757 is meant to address that bit. |
| 09:50 |
pinesol_green |
Launchpad bug 1482757 in Evergreen "Loading records with located URIs should not delete and recreate call_numbers" [Undecided,Confirmed] https://launchpad.net/bugs/1482757 |
| 09:50 |
Dyrcona |
Right. I was going to test some of that, but I have a delay because of pg_restore issues. |
| 09:51 |
Dyrcona |
I'm just trying to do some cleanup in production. |
| 09:52 |
jeff |
in terms of pgcrypto, it looks like we use crypt() in actor.set_passwd / actor.verify_passwd and gen_salt() in actor.create_salt |
| 09:53 |
mmorgan |
Oh, I get it. So the deleted records still have the 856, imo, the asset.uri should probably remain. |
| 09:56 |
Dyrcona |
mmorgan: OK. I can see that point of view, and it makes me wonder if I should modify my script to include deleted records when removing 856s. |
| 09:58 |
mmorgan |
I'm just thinking of the possibility that the record gets undeleted at some point. Maybe not an issue. |
| 09:59 |
|
yboston joined #evergreen |
| 09:59 |
Dyrcona |
Well, yeah, and if we were asked to remove all URLs for a certain vendor for a certain library, they'll show up again if the record is undeleted. |
| 10:00 |
Dyrcona |
So, I should probably do deleted records, too. |
| 10:02 |
Dyrcona |
Not likely that these records would be undeleted, though. |
| 10:04 |
mmorgan |
Yeah, probably not likely. |
| 10:14 |
Dyrcona |
I'm going through the list anyway in case some are not deleted. |
| 10:14 |
Dyrcona |
Mostly romance novels from Freading. |
| 10:16 |
Dyrcona |
and mysteries. |
| 10:20 |
Bmagic |
csharp: I'll test it and get back to you. I'm not positive that we had that exact problem. |
| 10:32 |
|
kmlussier joined #evergreen |
| 10:37 |
csharp |
Bmagic: I'm not sure it's our *only* problem :-/ |
| 10:38 |
csharp |
but it happened last night and I could very easily track the cause in the logs |
| 10:47 |
|
rlefaive joined #evergreen |
| 11:11 |
|
sandbergja joined #evergreen |
| 11:11 |
|
collum joined #evergreen |
| 11:31 |
|
Christineb joined #evergreen |
| 11:33 |
|
ohiojoe joined #evergreen |
| 11:40 |
|
_adb joined #evergreen |
| 11:54 |
|
tspindler joined #evergreen |
| 11:57 |
Dyrcona |
Is it normal to have 48 identical browse queries, all with a state of active in the server, going at once? |
| 11:57 |
tspindler |
not that i'm aware of |
| 11:57 |
tspindler |
is this a cat on the keyboard type of thing? |
| 11:58 |
tspindler |
we have seen that before |
| 11:58 |
JBoyer |
Dyrcona, depends on if you think user's clicking the same link over and over again is normal. (i.e. what tspindler said.) |
| 11:58 |
Dyrcona |
JBoyer: Do you think it would be "safe" to pg_cancel_backend on them? |
| 11:58 |
Dyrcona |
Will I run into problems with cstore? |
| 11:59 |
JBoyer |
I've never had issues knocking out simple search queries, no. |
| 11:59 |
JBoyer |
(it's no worse than what will happen when they start to time out) |
| 12:02 |
Dyrcona |
That's better. Now, all my queries started in the last minute. |
| 12:02 |
Dyrcona |
JBoyer++ # For confirming what I thought. |
| 12:03 |
Dyrcona |
And, hey, the load on my db server just dropped by 25 or so. |
| 12:03 |
JBoyer |
Ouch. Those were certainly poky. |
| 12:03 |
Dyrcona |
One had been running for about 25 minutes. |
| 12:03 |
dbs |
browsing on 'the' or somethign like that? |
| 12:04 |
Dyrcona |
'SELECT * FROM metabib.browse( 'series', 'amea badelea', '150', NULL, 'f', NULL, '25' ) AS "metabib.browse" ;' |
| 12:04 |
dbs |
huh |
| 12:04 |
Dyrcona |
Forty-eight of those going at once. |
| 12:04 |
JBoyer |
I've got a script called current_queries that just pipes this Q through psql that I'll check out now and then: SELECT now()-query_start AS "Duration", client_addr AS "Client", REGEXP_REPLACE(REPLACE(SUBSTRING(TRIM(LEADING ' ' FROM query) FOR 140), E'\\n', ' '), E'[\\\\s\\\\t ]+', ' ', 'ig') AS "Query" FROM pg_stat_activity WHERE state NOT LIKE 'idle%' AND query NOT LIKE '%now()-query_start%' ORDER BY query_start DESC; |
| 12:04 |
kmlussier |
I wouldn't expect a browse for 'the' to have the same effect as a keyword search for 'the.' |
| 12:05 |
JBoyer |
And yeah, anytime I see a ton of repeat searches it tends to be kids stuff :/ |
| 12:06 |
* csharp |
had a multiple-identical-queries-per-second issue that turned out to be a book laying on the F5 key |
| 12:07 |
Dyrcona |
Yeah, books on Enter keys are also a problem. |
| 12:08 |
Dyrcona |
JBoyer: If I run that query in pgadmin, it mangles the query, but I imagine the number of backslashes is tuned for passing through the shell and then into psql. |
| 12:09 |
JBoyer |
It is, I meant to mention that. |
| 12:09 |
Dyrcona |
It looks handy. I'll keep it around. |
| 12:09 |
Dyrcona |
Yeah, I'll adjust it to run via psql -f sql_file |
| 12:09 |
|
collum joined #evergreen |
| 12:10 |
csharp |
Dyrcona: we also have a bib search killer that gmcharlt set up for us years ago: select pg_cancel_backend(pid) from pg_stat_activity where query <> '<IDLE>' and now() - query_start > '20 seconds' and query ~ 'bib search' order by 1 desc; |
| 12:10 |
csharp |
that runs via cron once per minute |
| 12:10 |
Dyrcona |
Yeah, I've seen that before. MVLC might have also run that or something like it. |
| 12:10 |
JBoyer |
Whoa, are you still running that as-is csharp? |
| 12:11 |
csharp |
JBoyer: yeah |
| 12:12 |
JBoyer |
My surprise was a little unnecessary, the "query ~ bib search" took care of what I was initially worried about. |
| 12:12 |
JBoyer |
I initially thought it would kill anything that ran over 20 seconds. |
| 12:12 |
csharp |
heh |
| 12:13 |
csharp |
I think the query <> '<IDLE>' is probably out-of-date as of the version of PG we're on though |
| 12:13 |
csharp |
(9.4) |
| 12:13 |
JBoyer |
As it is though, if a canceled search backend isn't recycled within 1 min it will get canceled again. More recent versions of postgres stopped using the query column for state, and now you can replace that "query <> '<IDLE>'" with "state not like 'idle%'" |
| 12:14 |
Dyrcona |
Yes. |
| 12:14 |
csharp |
yeah, I was just looking at that |
| 12:14 |
JBoyer |
You figured it out as I was taking too long to type all of that out, heh. |
| 12:15 |
Dyrcona |
Well, I know about the state column, yeah. |
| 12:16 |
* csharp |
takes JBoyer's advice and updates the query |
| 12:16 |
Dyrcona |
heh. I can kind of see why you limited it to just the first 140 characters. :) |
| 12:17 |
JBoyer |
Yeah, and it was a lot worse before I went to the trouble of taking out the newlines, heh. Lots of queries built with heredocs and so on. ;) |
| 12:18 |
Dyrcona |
Yeah. |
| 12:20 |
|
khuckins joined #evergreen |
| 12:24 |
csharp |
one thing I've noticed a couple of times watching the logs over the past few days is this cropping up: Gateway received error: open-ils.pcrud: permacrud received a bad auth token: |
| 12:25 |
csharp |
I'm assuming "bad" == "expired", because I can see the token used earlier in the logs |
| 12:32 |
jeff |
expired or deleted or evicted from memcache are all likely, especially if you saw them used with success before. |
| 12:41 |
|
jihpringle joined #evergreen |
| 12:45 |
|
jihpringle_ joined #evergreen |
| 12:50 |
csharp |
jeff: thanks for confirming my assumptions :-) |
| 13:07 |
csharp |
hmm - I have a report of this popping up at a library on an older Win7 station: This page uses an unsupported technology that is no longer available by default. |
| 13:07 |
csharp |
my first thought based on DuckDuckGo results is "Firefox Addons", but I wondered if someone else here Just Knows™ |
| 13:13 |
jeff |
a similar bug fixed around Evergreen 2.3: bug 1038147 |
| 13:13 |
pinesol_green |
Launchpad bug 1038147 in Evergreen "Unable to view report output in staff client" [Undecided,Fix released] https://launchpad.net/bugs/1038147 - Assigned to Bill Erickson (berick) |
| 13:15 |
jeff |
csharp: do you know where in the staff client (if indeed in the staff client) that the user encountered the message? |
| 13:23 |
csharp |
Description from staff: "As far as I can tell it seems to happen when we open new tabs, or try to refresh a tab. Not every time though, and it doesn't seem to be after a certain number of clicks either. I have seen it happen from check in, out, hold, and trying to refresh the pull list as well." |
| 13:23 |
csharp |
so kind of anything |
| 13:23 |
csharp |
I'm also trying to nail down whether this is a single station or all on a LAN |
| 13:23 |
csharp |
it's only affecting one location as far as the ticket says |
| 13:24 |
* csharp |
finds bug 1038147 |
| 13:24 |
pinesol_green |
Launchpad bug 1038147 in Evergreen "Unable to view report output in staff client" [Undecided,Fix released] https://launchpad.net/bugs/1038147 - Assigned to Bill Erickson (berick) |
| 13:25 |
jeff |
my goodness! where have i seen that before?! |
| 13:25 |
* jeff |
grins and ducks |
| 13:26 |
|
terran_ joined #evergreen |
| 13:28 |
|
khuckins_ joined #evergreen |
| 13:29 |
|
khuckins__ joined #evergreen |
| 13:34 |
|
tspindler left #evergreen |
| 13:41 |
csharp |
only one workstation at the affected library :-/ |
| 13:41 |
* csharp |
is still surprised after 9 years of working with PINES when he hears about such libraries... |
| 13:50 |
|
kmlussier joined #evergreen |
| 13:52 |
csharp |
actually, looks like I misread - it's just the one station *affected* (whew) |
| 13:54 |
dbs |
csharp: still pointing at a xul_2_2 directory or something? |
| 13:54 |
dbs |
ancient staff client? |
| 13:58 |
csharp |
ooh - it could be |
| 13:58 |
csharp |
at least upgraded in place since forever |
| 14:04 |
|
khuckins_ joined #evergreen |
| 14:09 |
jeffdavis |
jeff: you mentioned in the past that you have a PatronAPI shim - is that something you'd be willing to share? |
| 14:11 |
|
jihpringle_ joined #evergreen |
| 14:14 |
jeff |
yes. |
| 14:15 |
jeff |
many of the local patron tests for eligibility are expressed in perl code, but i expect that i can make them commented examples and throw it up on github. |
| 14:17 |
jeff |
we use it as a true/false test -- we are not returning patron data such as name or expiration date or birth date, or even money owed. |
| 14:18 |
jeff |
this doesn't mean that it can't do those things, just that we intentionally didn't. |
| 14:18 |
jeffdavis |
I'm hoping to get some time this summer to make that an option with EG's SIP server too. |
| 14:19 |
jeff |
i'm looking now to see if we're testing password or just using the library card. |
| 14:24 |
jeff |
not checking password (because we did not want patrons to enter their library password into a vendor app / site) |
| 14:25 |
jeff |
it could be added, but i'm okay with it not being there. :-) |
| 14:34 |
jeffdavis |
That would likely be good for Sitka's immediate use case (we've had a patron auth request from another vendor and I'm trying to steer away from SIP for that). |
| 14:38 |
gsams |
https://www.humblebundle.com/books/linux-book-bundle |
| 15:10 |
pinesol_green |
[evergreen|Galen Charlton] LP#1694497: fix record links on 2nd+ page of grouped results - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=fc9b7ea> |
| 15:38 |
|
remingtron joined #evergreen |
| 15:38 |
|
dbwells joined #evergreen |
| 16:20 |
|
Jillianne joined #evergreen |
| 16:31 |
pinesol_green |
News from qatests: Test Failure <http://testing.evergreen-ils.org/~live> |
| 16:33 |
kmlussier |
Do we know what needs to be done to fix the tests? |
| 16:36 |
jeff |
did they start breaking on the 28th? |
| 16:36 |
* jeff |
looks |
| 16:36 |
jeff |
29th |
| 16:36 |
Dyrcona |
Looks like apt-get update/upgrade needs to be run or someone broke packages on the Debian side. |
| 16:40 |
jeff |
on May 28, the libdbd-pg-perl package in the postgresql PGDG apt repository was updated: https://www.postgresql.org/message-id/E1dEuUN-0000Q0-Gy%40atalia.postgresql.org |
| 16:41 |
jeff |
for Wheezy, it requires the latest perl package, which is not present on the test system. |
| 16:41 |
jeff |
so yeah, either someone needs to manually apt-get update && apt-get dist-upgrade, or fix whatever automated process is expected to do that which isn't. :-) |
| 16:42 |
Dyrcona |
I don't think I have access. If I do, I never used it. |
| 16:42 |
jeff |
i may. checking. |
| 16:49 |
jeff |
checked. |
| 16:50 |
jeff |
pinged phasefx but he's rather idle, possibly enjoying time away. :-) |
| 16:53 |
jeff |
thus, pestering gmcharlt :-) |
| 17:02 |
jeff |
...who is On It. |
| 17:02 |
jeff |
gmcharlt++ |
| 17:04 |
phasefx |
:D |
| 17:04 |
phasefx |
I thought the script did apt-get update/upgrade/dist-upgrade |
| 17:04 |
jeff |
oh wow, and we woke phasefx from a 6+day slumber, to boot. |
| 17:06 |
|
mmorgan left #evergreen |
| 17:06 |
phasefx |
it doesn't |
| 17:10 |
jeff |
current output of http://testing.evergreen-ils.org/~live/test.4.html shows it does... |
| 17:10 |
jeff |
but that the version of perl it installed is still one revision down. |
| 17:10 |
jeff |
hrm. |
| 17:11 |
phasefx |
in build_essentials it's doing apt-get update && apt-get -yq dist-upgrade ... skips the upgrade; would that make a difference? |
| 17:12 |
jeff |
i'm missing the "skips the upgrade" part of your statement. |
| 17:12 |
Dyrcona |
dist-upgrade does an upgrade. |
| 17:13 |
Dyrcona |
At least, it is supposed to. |
| 17:13 |
phasefx |
I'm not really a sysadmin, but on my own systems I'm in the habit of doing apt-get update && apt-get upgrade && apt-get dist-upgrade; eg_wheezy_installer.sh essentially does the first and last. Dyrcona: cool, then I'm not sure why the right perl isn't getting installed |
| 17:16 |
Bmagic |
Before I click submit on this bug report, can I confirm that it's still a bug in 2.12? - Electronic records can be chosen as the "master" record for a meta group. |
| 17:16 |
jeff |
phasefx: there may be corner cases, but per docs and experience, dist-upgrade does everything that upgrade does and then some. upgrade tries to be exceptionally conservative. |
| 17:16 |
* phasefx |
nods |
| 17:17 |
|
jihpringle_ joined #evergreen |
| 17:18 |
kmlussier |
Bmagic: Yes, I'm pretty sure it's still an issue. |
| 17:19 |
Bmagic |
Thanks kmlussier, submitted |
| 17:19 |
kmlussier |
It has to do with the record quality, but I forget how record quality is calculated. |
| 17:19 |
kmlussier |
Or maybe I never knew. |
| 17:19 |
Dyrcona |
phasefx: Is the apt line being run with sudo? If so, maybe only the update is and the && part isn't. |
| 17:20 |
phasefx |
Dyrcona: the whole script is being sudo'ed |
| 17:21 |
jeff |
phasefx_: in this case, it may simply be a case of the VM not having the security repo enabled as an apt source. |
| 17:21 |
Dyrcona |
ok |
| 17:21 |
jeff |
phasefx_: i don't see security.debian.org in the output of apt-get update |
| 17:21 |
phasefx |
yeah, it simply has: http://testing.evergreen-ils.org/~live/test.4.html |
| 17:21 |
phasefx |
cut/paste across desktops, bleh :) |
| 17:22 |
phasefx |
wheezy main contrib |
| 17:22 |
jeff |
yeah. that's the issue. |
| 17:22 |
phasefx |
jeff++ |
| 17:23 |
jeff |
it broke after the new PGDG package update started requiring the latest perl package for wheezy, which is only available from security.debian.org |
| 17:23 |
jeff |
(currently only available from) |
| 17:23 |
jeff |
phasefx++ gmcharlt++ because you'll likely be doing the boring work of fixing it. :-) |
| 17:23 |
phasefx |
so should I add both deb http://ftp.de.debian.org/debian wheezy-updates main contrib and deb http://ftp.de.debian.org/debian-security wheezy/updates main contrib ? |
| 17:25 |
jeff |
wheezy/updates, i think |
| 17:25 |
jeff |
deb http://security.debian.org/ wheezy/updates main contrib |
| 17:25 |
gmcharlt |
no, security is needed aswell |
| 17:25 |
gmcharlt |
*snap* |
| 17:25 |
gmcharlt |
phasefx: what jeff said |
| 17:26 |
phasefx |
rock |
| 17:34 |
Bmagic |
We have a question about "auto" renewing patron cards that "are in good standing" - Anyone had this question before? |
| 17:55 |
kmlussier |
For the purposes of the logs, the answer to my earlier question about how record quality is calculated is the biblio.extract_quality function. |
| 18:01 |
Dyrcona |
Bmagic: No, but you could probably do it with an action trigger, just to add to your a/t runner woes. :) |
| 18:18 |
|
jvwoolf joined #evergreen |
| 19:26 |
|
Freddy_Enrique joined #evergreen |
| 19:26 |
Freddy_Enrique |
Good evening everyone |
| 19:26 |
Freddy_Enrique |
Hope you are okay |
| 19:27 |
csharp |
Freddy_Enrique: right back atcha |
| 19:27 |
Freddy_Enrique |
I meant to ask something about the concerto |
| 19:28 |
Freddy_Enrique |
Don't really mean to annoy with this question, it may be ridiculously easy for you |
| 19:28 |
csharp |
Freddy_Enrique: feel free to just ask :-) |
| 19:28 |
Freddy_Enrique |
but how do I Lad the sample data? |
| 19:29 |
Freddy_Enrique |
Load* |
| 19:29 |
Freddy_Enrique |
Its in the instructions, but I wasn't able to figure it out |
| 19:30 |
csharp |
Freddy_Enrique: two ways: 1) add --load-all-sample during the eg_db_config.pl step 2) run psql on Open-ILS/tests/datasets/sql/load_all.sql |
| 19:34 |
Freddy_Enrique |
Let see.... there were 4 step in the eg_db_config. this could be a 5 step. Should it look like this? |
| 19:34 |
Freddy_Enrique |
https://snag.gy/dqlPTv.jpg |
| 19:35 |
csharp |
Freddy_Enrique: that works, yeah |
| 19:35 |
Freddy_Enrique |
and then..... |
| 19:43 |
Freddy_Enrique |
like this? https://snag.gy/Qu9Kd0.jpg |
| 20:00 |
Freddy_Enrique |
IT WORKED!!! |
| 20:00 |
Freddy_Enrique |
Thanks a lot Sharp :) |
| 20:07 |
csharp |
Freddy_Enrique: happy to help! |
| 22:20 |
|
genpaku joined #evergreen |
