| Time |
Nick |
Message |
| 00:00 |
jeff_ |
i see where pre-cat copies in scripts will end up with a fleshed obj for circ_lib, but you're not dealing with pre-cat copies, right? |
| 00:01 |
dbs |
Nope |
| 00:03 |
jeff_ |
ah, there it is. |
| 00:03 |
jeff_ |
fetch_bib_data in ScriptBuilder.pm fleshes circ_lib on the acp |
| 00:13 |
dbs |
I guess I could defensively unflesh it before its used later |
| 00:14 |
dbs |
something like "if ref $cp->circ_lib { $cp->circ_lib = $cp->circ_lib->id; }" |
| 00:23 |
dbs |
"Can't modify non-lvalue subroutine call" of course, Perl protects me |
| 00:25 |
paxed |
morning |
| 00:42 |
dbs |
We have a fix. Yay. |
| 00:50 |
dbs |
http://git.evergreen-ils.org/?p=contrib/Conifer.git;a=commit;h=b3905c80d9bbfd13c2b5316ee34980b301e1c3f8 for the interested |
| 00:51 |
dbs |
(with a bonus "don't fire off 3 warnings about var comparisons to undefined in isTrue()" few fixes) |
| 00:52 |
paxed |
just out of curiosity, how long did it take to find and fix that? |
| 00:53 |
dbs |
Ran into the problem this morning. We had three major problems this morning; now we have none (that we know about). |
| 00:54 |
dbs |
This one sucked the most. Probably 5 or 6 hours. |
| 00:58 |
dbs |
jeff++ # helped cut through a lot of the pain |
| 01:06 |
|
Mark__T joined #evergreen |
| 07:08 |
|
DPearl joined #evergreen |
| 07:19 |
|
timf joined #evergreen |
| 07:33 |
|
collum joined #evergreen |
| 08:08 |
|
collum joined #evergreen |
| 08:21 |
|
tfaile_ joined #evergreen |
| 08:28 |
|
rjackson-isl joined #evergreen |
| 08:28 |
|
akilsdonk_ joined #evergreen |
| 08:35 |
|
kbeswick joined #evergreen |
| 08:45 |
|
Dyrcona joined #evergreen |
| 08:45 |
|
mmorgan joined #evergreen |
| 08:48 |
|
jboyer-isl joined #evergreen |
| 08:50 |
|
ericar joined #evergreen |
| 08:55 |
|
kmlussier joined #evergreen |
| 09:04 |
|
mrpeters joined #evergreen |
| 09:15 |
|
bkuhn joined #evergreen |
| 09:23 |
|
remingtron joined #evergreen |
| 09:43 |
|
BigRig joined #evergreen |
| 09:55 |
csharp |
hmm - have a strange title retrieval issue in 2.3.6... if you search for 'La ciencia del agua para escuelas' this record should be in the results: https://gapines.org/eg/opac/record/5083466 but it is not |
| 09:55 |
csharp |
we have attempted reingest to no avail |
| 09:58 |
jeff_ |
csharp: does this query return a number greater than zero? SELECT COUNT(*) FROM asset.opac_visible_copies WHERE record = 5083466; |
| 09:58 |
bshum |
Hmm |
| 09:58 |
bshum |
I wonder if maybe it's bug 1091885 |
| 09:58 |
pinesol_green |
Launchpad bug 1091885 in Evergreen "Reingest bib needs to deal with missing metabib.record_attr entries" (affected: 1, heat: 6) [Medium,Confirmed] https://launchpad.net/bugs/1091885 |
| 09:59 |
csharp |
jeff_: no - it's zero |
| 09:59 |
jeff_ |
bshum++ i'd forgotten about that one. |
| 09:59 |
bshum |
You could check to make sure that the bib record is in the metabib.record_attr table |
| 09:59 |
jeff_ |
csharp: okay, you ran into a similar thing that i ran into investigating two "does not show in public catalog" reports Friday. |
| 09:59 |
bshum |
If it isn't, you have to manually add a line with junk in it, and then reingest. |
| 10:00 |
csharp |
bshum: how does that table "work"? |
| 10:00 |
csharp |
metabib.record_attr, that is |
| 10:01 |
bshum |
The bug details are hazy for me. I'm re-reading what happened that day I reported it. |
| 10:01 |
bshum |
:D |
| 10:02 |
csharp |
does metbib.record_attr.id = biblio.record_entry.id? |
| 10:02 |
bshum |
csharp: That's what it looks like, yes. |
| 10:02 |
csharp |
oh ok |
| 10:02 |
bshum |
And then attrs stores all the attributes |
| 10:02 |
bshum |
If there isn't a row there, it doesn't update. |
| 10:02 |
bshum |
And then the bib doesn't show up in searches or something. |
| 10:03 |
csharp |
aha - 0 rows for that id |
| 10:03 |
bshum |
And bingo |
| 10:03 |
bshum |
So just insert a row for that ID |
| 10:03 |
bshum |
And then go ahead and reingest the bib again, to repopulate the attrs |
| 10:03 |
csharp |
does it matter what's in attr? |
| 10:03 |
bshum |
It does not. |
| 10:03 |
csharp |
ok |
| 10:03 |
jeff_ |
hrm. both the opac visibility cache and the metabib record_attr issue? what are the odds? i wonder if the mra is causing issues with the visibility cache. |
| 10:04 |
jeff_ |
i didn't find out why the copies in question on my end weren't in the visibility cache -- it seemed that they should have been, and they were all old with little activity... |
| 10:05 |
csharp |
BAM - it comes up now |
| 10:05 |
csharp |
bshum: thanks! |
| 10:05 |
bshum |
Huzzah :) |
| 10:05 |
csharp |
ok - I'll check to see how many records are affected |
| 10:05 |
bshum |
The SQL in the bug report takes awhile to run but highlights any other bibs that are similarly dead. |
| 10:05 |
csharp |
great |
| 10:06 |
bshum |
I don't think we ever got to the bottom of what caused it to occur. |
| 10:06 |
jeff_ |
csharp: unless you have a non-zero result for the visibility query earlier, it likely still will not appear in the public catalog. should it, in the case of this bib? does it have visible copies? |
| 10:06 |
bshum |
I'm re-reading the chat log and it looks like it might have something to do with marking a bib deleted and then unmarking it from being not deleted. |
| 10:07 |
bshum |
We don't do that often, but our workflows are not like others. |
| 10:09 |
csharp |
jeff_: hmm - it shows in the catalog despite the zero result |
| 10:09 |
jeff_ |
huh. |
| 10:09 |
bshum |
Isn't it an electronic record? |
| 10:09 |
csharp |
oh - it's because it's an electronic resource |
| 10:09 |
bshum |
And therefore no copies |
| 10:09 |
csharp |
yeah |
| 10:09 |
jeff_ |
ah. serves me right for not viewing the record. |
| 10:09 |
csharp |
:-D |
| 10:10 |
|
yboston joined #evergreen |
| 10:15 |
bshum |
Yay, only one affected and broken bib in our system since I reported that bug. That makes me happy :) |
| 10:15 |
bshum |
Well, less stressed. |
| 10:25 |
|
kivilahtio joined #evergreen |
| 10:26 |
kivilahtio |
Ok, I am having some steep difficulties in getting the debugger to debug OpenSrf services |
| 10:26 |
kivilahtio |
nobody has any idea about debugging OpenSRF services with the Perl DebuggeR? |
| 10:31 |
* bshum |
is one of these nobody folk. |
| 10:32 |
|
shopkins joined #evergreen |
| 10:49 |
berick |
kivilahtio: using the debugger across multiple perl processes is.. complicated. you'll probably have better luck adding log lines to the code instead. it's not elegant, but it will get you there (eventually) |
| 10:50 |
* paxed |
thinks that's about what he said to kivilahtio last week ... |
| 10:50 |
kivilahtio |
berick: logging sucks pretty badly when I encountered 60+ lines of business code |
| 10:50 |
kivilahtio |
berick: kinda missing the debugger. And I feel like it might be worth the effort to get it working, compared to the clarity it would give about internal workings of OpenSRF |
| 10:52 |
kivilahtio |
berick: I got the debugger to start new debugging sessions in xterm windows when perl processes fork, but they strangely crash. I think I have the possible solution by using PERLDB_OPT variables noTTY and TTY=/dev/tty<available_tty> |
| 10:52 |
kivilahtio |
berick: so I could sneak a debugger sessions inside and then trigger it using $DB::single=1 breakpoints |
| 10:53 |
berick |
kivilahtio: cool. i would also suggest dropping all of your max-children settings down to 1 (instead of the default 15 or so) so that you are only tracking 2 processes per service instead of ~16 |
| 10:53 |
kivilahtio |
berick: but perl doesn't recognize my TTY path :( |
| 10:54 |
berick |
max and min settings, both, that is |
| 10:54 |
kivilahtio |
berick: yeah, I'll try that, but I am facing some weird crashes in OpenSRF, in AppSession.pm server_build() |
| 10:54 |
kivilahtio |
it excpects Drones to have a process id from forking, which shouldn't happen |
| 10:55 |
bshum |
dbs: Hmm, I'm interested in what you did to quiet the warnings about undefined var comparisons in action.pm. That sounds like it would quiet down all the warning we've been tracking in our logs :( |
| 10:56 |
* bshum |
takes a look at the Conifer branch link |
| 10:56 |
berick |
another trick that might be helpful is using opensrf-perl.pl directly to stop/start a service. it has a --no-daemon mode which would leave the listener process running in the current tty and result in one fewer fork() |
| 10:56 |
kivilahtio |
berick: so far clueless as to why PERLDB_OPTS TTY=doesn't recognize my TTY path |
| 10:56 |
berick |
kivilahtio: ^- |
| 10:56 |
* berick |
doesn't know |
| 10:56 |
kivilahtio |
berick: hmm, that is a good idea, I have been starting/Stopping a singel service, but no-daemon might be easier |
| 10:57 |
shopkins |
Hi, does anyone know if evergreen's sip supports holds (15/16 messages) ? I am trying to get a holds expired date. |
| 10:57 |
kivilahtio |
berick: can you tell me which class actually processes the Service function? |
| 10:57 |
bshum |
shopkins: I'll refer to https://bugs.launchpad.net/evergreen/+bug/1083334 |
| 10:57 |
kivilahtio |
berick: I traced it down to Drone, but then I realized the Drone actually makes a eJabberd-call |
| 10:57 |
pinesol_green |
Launchpad bug 1083334 in Evergreen "Support SIP Hold Cancellation" (affected: 1, heat: 6) [Wishlist,Triaged] |
| 10:57 |
bshum |
Which seems to indicate some work towards support of holds 15/16 messages |
| 10:58 |
bshum |
(but it's not in any version yet) |
| 10:58 |
bshum |
though I should find out more in general about what those messages mean |
| 10:58 |
berick |
kivilahtio: i'm not sure what you mean by "Service function" |
| 10:59 |
kivilahtio |
berick: request open-ils.serial open-ils.serial.<function_call> "param1" "param2" |
| 10:59 |
kivilahtio |
berick: I guess the correct term is Evergreen service function? |
| 10:59 |
|
zerick joined #evergreen |
| 11:02 |
berick |
kivilahtio: you want to know where the code is that implements that API call or you want to know where in OpenSRF the call is dispatched to the code that implements the API call? |
| 11:02 |
kivilahtio |
berick: So when I make that request open-ils.serial.regenerate_summaries "cfca48acdbc0df94e6ec838bc9fcd988" [1], the code in Serial.pm->regenerate_summaries() gets executed. |
| 11:02 |
kivilahtio |
Which class is responsible for running that code |
| 11:02 |
berick |
the first could of course be the code in Serials.pm (in your example) |
| 11:02 |
shopkins |
bshum: Thanks! |
| 11:02 |
berick |
oohhh |
| 11:03 |
|
dboyle joined #evergreen |
| 11:04 |
kivilahtio |
berick: I think this one :: where in OpenSRF the call is dispatched to the code that implements the API call :: And can I attach a debugger there? I presume it gets executed from the C parts of OpenSRF? |
| 11:04 |
berick |
kivilahtio: the code is run from within Application.pm (for perl) |
| 11:04 |
kivilahtio |
berick: Does the OpenSRF Drone run the Application.pm? |
| 11:04 |
berick |
Application.pm => handler() |
| 11:05 |
berick |
yes |
| 11:05 |
bshum |
shopkins: Sure thing. Looks like it's targeted to 2.5-m2 so maybe it'll be there in time for 2.5's release later this Fall :D |
| 11:06 |
berick |
kivilahtio: the drone receives the request over the network and it bubbles up through Transport.pm -> oilsMessage.pm -> Application.pm |
| 11:06 |
berick |
there the params are passed into the Perl sub linked to the API call |
| 11:07 |
berick |
$resp = $coderef->run( $appreq, @args); |
| 11:07 |
berick |
that's where the magic happens ^- |
| 11:07 |
berick |
application.pm:223 |
| 11:07 |
kivilahtio |
berick: ok, I think I should have figured that out. I kinda got desperate when I saw the program flow going through the Transport.pm :) |
| 11:08 |
berick |
kivilahtio: an oldie, but a goodie : http://evergreen-ils.org/documentation/OpenILS_Structural_Overview.png |
| 11:12 |
eeevil |
kivilahtio: the upshot of that graphic is that if you're having a problem with a specific opensrf method, you can safely focus your efforts on the code inside (and called by) the sub named in that method's register_method() invocation. problems below that level would be experienced by other (probably all) opensrf methods. (one caveat to that is for opensrf apps that provide their own register_method() logic, but Serial.pm does not) |
| 11:12 |
kivilahtio |
berick: I have some strange behavior in AppSession.pm->server_build(). The child process accessing it without a process id. Is this something which should happen and the errors get hidden in /dev/null ? Generally starting perl services in debugger seems to fail |
| 11:13 |
kivilahtio |
I'll try to dg up some logs |
| 11:17 |
|
mcooper_ joined #evergreen |
| 11:18 |
eeevil |
kivilahtio: perhaps the debugger replaces fork() or setsid or related with a wrapper that is too clever by half for opensrf's purposes ... a debugger is not, by definition, the same environment as a pure interpreter. I echo berick's suggestion for logging. Note, too, that if you simply warn() from within the sub in question, you should get log lines in open-ils.serial_stderr.log (though I have a vague feeling that might be less true on newer |
| 11:18 |
eeevil |
opensrfs ...) |
| 11:18 |
kivilahtio |
eeevil: warn not working here |
| 11:19 |
kivilahtio |
eeevil: possibly because in opensrf-perl.pl->do_daemon() STDERR & friends get directed to /dev/null |
| 11:19 |
berick |
warns now go to the configured log file |
| 11:19 |
berick |
in newest opensrf |
| 11:20 |
kivilahtio |
eeevil: or maybe I am having a older version in my dev environment |
| 11:20 |
eeevil |
kivilahtio: that's post-fork ... just the FDs for the outer-most controlling process |
| 11:21 |
kivilahtio |
eeevil: ah true |
| 11:26 |
dbs |
bshum: that var warning silencing thing was pretty quick and dirty; calling "isTrue $fifo" where $fifo is undefined looked pretty sketchy given that isTrue always expected a value. other option would be to return 0 immediately if $var was undefined |
| 11:31 |
Dyrcona |
FYI: It is standard practice in UNIX daemons to close any open file descriptors inherited from the parent process, include stdin, stdout, and stderr. |
| 11:42 |
dbs |
Hmm. flay_marc stored procedure reporting unhappiness with new MARC::File::XML (just a warning, things still ingest, but WARNING: Use of uninitialized value $self in pattern match (m//) at /usr/local/share/perl/5.10.1/MARC/File/XML.pm line 437.) |
| 11:43 |
dbs |
or maybe the don't reingest. double-hmm |
| 11:44 |
jcamins |
dbs: Evergreen flays MARC records? That seems... quite appropriate, actually. |
| 11:44 |
eeevil |
I was particularly proud of that stored proc name :) |
| 11:44 |
dbs |
could be caused by calling metabib.reingest_metabib_full_rec() instead of updating biblio.record_entry() value = value actually. |
| 11:45 |
* dbs |
would have been happy with the XML-relational convention of shred_marc too :) |
| 11:46 |
eeevil |
feed_marc_through_wood_chipper was my first choice, but increased the likelihood of typos |
| 12:11 |
|
ldwhalen joined #evergreen |
| 12:16 |
|
jihpringle joined #evergreen |
| 12:21 |
jeffdavis |
is there an easy way to mimic a bib search on the srfsh command line? |
| 12:21 |
jeffdavis |
mimic an opac search, that is |
| 12:27 |
senator |
jeffdavis: request open-ils.search open-ils.search.biblio.multiclass.query {} "piano limit(10) offset(10)" |
| 12:28 |
jeffdavis |
thanks! |
| 12:39 |
|
Ruth joined #evergreen |
| 12:45 |
rfrasur |
Yay! GSoC announcement. That sounds like a pretty cool project. |
| 12:46 |
dbs |
bshum++ # getting the announce out there! |
| 12:47 |
|
stevenyvr2 joined #evergreen |
| 12:47 |
rfrasur |
bshum++ |
| 12:47 |
rfrasur |
bshum++ # for joining the Mazda family |
| 12:47 |
kmlussier |
bshum: Do you have your car yet? |
| 12:48 |
bshum |
kmlussier: Not yet, Wednesday probably. |
| 12:48 |
bshum |
rfrasur: :) |
| 12:49 |
* bshum |
is admittedly somewhat distracted with new car glee. |
| 12:49 |
rfrasur |
:D |
| 12:49 |
rfrasur |
as well you should be. |
| 12:51 |
rfrasur |
Does it have the BOSE sound system? |
| 12:51 |
rfrasur |
(forget the fuel economy and safety rating) |
| 12:51 |
dbs |
mazda++ # although our 3 is getting pretty rusted out, the cx-5 is intriguing |
| 12:52 |
bshum |
rfrasur: Ha! Indeed it does. 11 speakers I think. |
| 12:53 |
rfrasur |
dbs: we downsized from a CX-7 because of my commute. The CX-5 looked like a shoe to me in the beginning, but it's growing on me as time passes. We went w/ the 3 w/ SkyActiv engine....it gets 36.2 mpg (real fuel economy) even w/ a teenager driving it periodically. |
| 12:53 |
rfrasur |
bshum: you'll never regret a good stereo system. |
| 12:53 |
* rfrasur |
missed the CX-7 like a lost limb |
| 12:54 |
* rfrasur |
sniffs |
| 12:54 |
|
jdouma joined #evergreen |
| 12:54 |
jeff |
hrm. /c |
| 12:54 |
jeff |
er. |
| 12:54 |
jeff |
hello. |
| 12:54 |
dbs |
hello, jeff with no tail |
| 12:54 |
rfrasur |
jeff: hello :D |
| 12:56 |
jeff |
dbs: yeah, i need to un-clone myself one of these days. |
| 12:57 |
dbs |
no no, we need more jeff |
| 12:58 |
eeevil |
dbs: are you currently using what's embodied in working/user/dbs/another_metabib_ingest_fix ? |
| 12:59 |
dbs |
eeevil: yes |
| 12:59 |
dbs |
now that I fixed the SQL typo |
| 12:59 |
dbs |
(not sure if you saw the force-push this AM) |
| 12:59 |
eeevil |
I saw the mention of that on the bug, which prompted me to ask :) |
| 13:02 |
dbs |
also running the reingest as you suggested, minus the pg_sleep(); the ingest runs at 100 records / minute without sleep, which works out to 13 days for our 2M+ records |
| 13:15 |
|
akilsdonk_ joined #evergreen |
| 13:16 |
rfrasur |
The realization that any semblance of true professionalism is simply unattainable after using the phrase "burns my biscuits" in an email to staff. |
| 13:21 |
pastebot |
"dbs" at 204.193.129.146 pasted "URL_Verify - getting an empty owning lib value, which is interesting..." (2 lines) at http://paste.evergreen-ils.org/12 |
| 13:38 |
rfrasur |
have any of you ever messed w/ openbiblio? |
| 13:40 |
jcamins |
rfrasur: a former intern used it for his library in rural Guatemala. |
| 13:41 |
dbs |
what in the... http://planet.evergreen-ils.org/ says the newest post from the Equinox feed is from November, 2013 |
| 13:41 |
jcamins |
He found Koha a little too much to handle. |
| 13:41 |
* rfrasur |
nods. |
| 13:41 |
rfrasur |
dbs: that's very....forward thinking |
| 13:42 |
rfrasur |
jcamins: Reading through the known issues, it seems like it'd be okay to use for only the most basic implementation. |
| 13:43 |
csharp |
@eightball does ESI have the gift of prophecy? |
| 13:43 |
pinesol_green |
csharp: The answer is def-- oooh! shiny thing! |
| 13:43 |
bshum |
dbs: My favorite was the recent feed post that said we were having the next Evergreen conference in Grand Rapids. From 2009 :) |
| 13:43 |
bshum |
I just assumed they were having quirks with their blog again :( |
| 13:44 |
jcamins |
rfrasur: that's my impression of it as well. |
| 13:44 |
csharp |
well the blog post is Nov '13 and the press release date is Nov '12 |
| 13:45 |
dbs |
Could be the planet aggregator, the feed looks okay |
| 13:45 |
dbs |
http://esilibrary.com/esi/news.rss is the feed |
| 13:46 |
jcamins |
rfrasur: are you thinking of switching? I think your staff might miss some of the functionality in EG. |
| 13:46 |
rfrasur |
lol, heck no. I'll live and die w/ an EG implementation of some sort. |
| 13:46 |
rfrasur |
it was just suggested by someone else to someone else and I wasn't sure if it was actually a good suggestion. |
| 13:48 |
dbs |
oh, heh, 21 occurrences of "<pubDate> 12:00:00 GMT</pubDate>" |
| 13:48 |
dbs |
http://feedvalidator.org/check.cgi?url=http%3A%2F%2Fesilibrary.com%2Fesi%2Fnews.rss also says "implausible date" for the Nov 2013 one :) |
| 13:50 |
rfrasur |
on another note, it'd be really nice to be able to export to .csv from the items out and lost items windows in the staff client. |
| 13:55 |
csharp |
I'm seeking documentation for "Behind Desk" hold pickup... I've enabled the setting, checked in a hold item and nothing looks different on the holds slip |
| 13:55 |
csharp |
anyone have experience with that feature? |
| 13:55 |
rfrasur |
sorry csharp. Not here. |
| 13:56 |
b_bonner |
csharp: the "route to: " message should change between private and public hold shelf if set |
| 13:57 |
csharp |
b_bonner: ah - thanks - I'll play with that |
| 13:57 |
hopkinsju |
tsbere: Any updates on the issue you and denials were working on here? http://evergreen-ils.org/irc_logs/evergreen/2012-11/%23evergreen.18-Sun-2012.log |
| 13:57 |
hopkinsju |
around the 18:16:14 mark |
| 13:58 |
|
acoomes joined #evergreen |
| 13:58 |
b_bonner |
csharp: the %route_to% macro, to be more specific. |
| 13:59 |
csharp |
b_bonner: cool - I'm putting that on our holds slip now |
| 14:00 |
csharp |
excellent - I see it working now |
| 14:01 |
tsbere |
hopkinsju: I don't think so. The solution is available, but a PITA to implement. ;) |
| 14:02 |
hopkinsju |
tsbere: Do you think I can avoid it by restoring the entire cluster rather than a single DB? |
| 14:02 |
dbs |
hopkinsju: IIRC, one approach was to create the evergreen user first but I'm kind of focused on post-2.4 upgrade issues atm |
| 14:03 |
b_bonner |
csharp: one thing we haven't fixed about the behind desk holds, it doesn't show up on the printable expired holds list |
| 14:03 |
hopkinsju |
dbs: I'm just trying to restore my migration servers database. I'm running a pg_dump of my hot spare from my migration server, then piping it to psql locally. |
| 14:04 |
tsbere |
hopkinsju: I think we came down to "MVLC sees the issue because we don't have an Evergreen DB user, and that user doesn't own our functions/tables/etc, so the default search path used by restore doesn't work when re-creating some indexes" - The solution is schema-qualify everything used by those indexes. |
| 14:04 |
hopkinsju |
dbs: So the evergreen user is already there. |
| 14:05 |
b_bonner |
csharp: I mean, the hold shows up but no indicator if behind desk or not |
| 14:06 |
ldwhalen |
Should I be able to open the Staff Client javascript console on Linux with xulrunner application.ini -console? It is not working for me right now. |
| 14:11 |
senator |
ldwhalen: -jsconsole |
| 14:13 |
ldwhalen |
senator: thank you! |
| 14:14 |
senator |
no prob |
| 14:15 |
csharp |
b_bonner: ah - good to know |
| 14:21 |
|
fparks joined #evergreen |
| 14:31 |
dbs |
ldwhalen: also only for older versions of xulrunner, newer versions aren't compatible in many areas |
| 14:32 |
ldwhalen |
dbs: I lucked out then when I rebuilt xulrunner 1.9 for 12.04. Thanks for letting me know, as I am about to try connection with a client using 14. |
| 14:37 |
|
Ruth joined #evergreen |
| 14:39 |
dbs |
14 should be fine |
| 14:40 |
jeffdavis |
is there a release date target for 2.4.1? (launchpad says may 30.) |
| 14:41 |
kmlussier |
jeffdavis: I think we're supposed to have monthly maintenance releases on the 3rd Wednesday of the month. |
| 14:42 |
hopkinsju |
tsbere: 1) stop postgres on the hot swap 2) rsync |
| 14:43 |
hopkinsju |
tsbere: Do you have documentation on the fix - and is it permanent? TBH I wasn't really following what you're saying about schema-qualify everything. I get it, but not the 'how to' part. |
| 14:46 |
tsbere |
hopkinsju: We restore multiple times to the same server for different purposes, so can't just rsync things over. As for the changes: Find places with raw function names like "oils_xpath_string" and add the schema to the front of them, changing them to "evergreen.oils_xpath_string". In general, not just for that one function... |
| 14:55 |
eeevil |
jeffdavis: this Weds |
| 14:55 |
eeevil |
with the 2.3 and 2.2 releases |
| 14:57 |
|
mrpeters joined #evergreen |
| 15:02 |
hopkinsju |
tsbere++ |
| 15:02 |
|
mrpeters left #evergreen |
| 15:06 |
|
Viper joined #evergreen |
| 15:07 |
Guest90545 |
Anyone have an idea of how to re-create the admin account to get into the staff client |
| 15:09 |
|
moodaepo_nb joined #evergreen |
| 15:09 |
ldwhalen |
Did you delete it or forget the password? |
| 15:10 |
Guest90545 |
It was deleted.. employee deleted the evergreen.usr schema |
| 15:12 |
jeff |
restoring from a backup (or doing a point in time recovery) of your database is going to be best. |
| 15:13 |
jeff |
was this a production system, or something you were testing / evaluating? |
| 15:14 |
Guest90545 |
Well he never setup the backup, this is how we figured it out (he is gone now).. and I'm not sure how far back it happened, we think about a week... and yes this has bibs, author, circ policy, etc all in the system |
| 15:14 |
Guest90545 |
Yes it is a production server |
| 15:15 |
dbs |
Well, you could copy the actor.usr schema definition from Open-ILS/src/sql/Pg/005.schema.actors.sql and then populate that, but... there are all kinds of tables that depend on it. |
| 15:16 |
Guest90545 |
That is just my concern.. to do a reinstall will kill everything we have in the db right now |
| 15:16 |
dbs |
Open-ILS/src/sql/Pg/950.data.seed-values.sql has some lines around line 2425 for creating the admin user |
| 15:17 |
Guest90545 |
I will try your idea and just have to re-populate the usrs.. much easier than the alternative |
| 15:17 |
dbs |
Guest90545: no, I'm saying you could just take the individual "CREATE TABLE actor.usr..." stmt from that file and use that, if actor.usr really doesn't exist |
| 15:17 |
Guest90545 |
That is correct |
| 15:17 |
Guest90545 |
It does NOT exist |
| 15:18 |
dbs |
Guest90545: I would also take a pg_dump right now so that you can at least recover to this point again, if anything else goes wrong |
| 15:18 |
rfrasur |
I hope this is the same DB vandalism we heard about last week and not another instance of it . |
| 15:18 |
Guest90545 |
I've done that... but I'm going to take another one once everyone gets off the system this evening |
| 15:18 |
bshum |
Wouldn't the missing actor.usr break all sorts of dependencies elsewhere. For circs, etc. |
| 15:19 |
Guest90545 |
Well right now they are using the offline so we won't know until we come back up and recover from this |
| 15:19 |
bshum |
I'm just thinking of the poor data elsewhere in the DB :( |
| 15:20 |
Guest90545 |
by theroy everthing should be in a miss because of the tie between the tables |
| 15:20 |
paxed |
i bet that employee didn't get references from you ... |
| 15:20 |
rfrasur |
paxed++ |
| 15:21 |
Guest90545 |
Well take a wild guess... and I have PTSD as well.... good thing I didn't go to jail |
| 15:21 |
rfrasur |
I'm pretty sure Dante described special places for people who destroy or corrupt data |
| 15:21 |
Dyrcona |
rfrasur: Then anyone who has ever touched a database as a user, programmer, or admin belongs there. :) |
| 15:21 |
Guest90545 |
Yes but it's his word against mine and I'm going to pick my battles and not give my paycheck to some money hog |
| 15:22 |
rfrasur |
Dyrcona: Hmm, sounds like the foundation of a good evangelical sermon |
| 15:23 |
rfrasur |
For all have corrupted data and fall short of the glory of perfect data preservation. |
| 15:23 |
Dyrcona |
Amen! |
| 15:23 |
bshum |
Hmm, interesting, most of the usr connections in other tables (circ, holds, copy) don't do much on delete. They just set to null or do nothing. |
| 15:24 |
Guest90545 |
LOL |
| 15:24 |
bshum |
Or at least that's what the constraint says. |
| 15:24 |
bshum |
Still sounds messy though :( |
| 15:28 |
jeffdavis |
Guest90545: Assuming this is the same issue as last week, I thought the whole db had been dropped. But it sounds like just actor.usr is missing? Do you have data in the auditor schema? |
| 15:28 |
rfrasur |
Remember, back in the day when we never used our real names in email addresses unless they were work-related and didn't anywhere else online either? |
| 15:28 |
jeffdavis |
(It should be actor.usr, not evergreen.usr) |
| 15:29 |
Guest90545 |
Yes jeff that's what I meant.. I guess I'm still a bit fired up... I was thinking about the database name |
| 15:30 |
Dyrcona |
rfrasur: Yes..... ;) |
| 15:30 |
jeffdavis |
Specifically, if only actor.usr is missing and you have data in auditor.actor_usr_history, you can probably reconstruct actor.usr from that auditor table (and supplement it with actor.card etc if there are a few records that were never updated after being created). |
| 15:30 |
* rfrasur |
misses those days. |
| 15:30 |
jeff |
jeffdavis++ for thinking of the auditor schema as a possible last-chance recovery (of SOME data) option |
| 15:30 |
|
jihpringle joined #evergreen |
| 15:31 |
jeffdavis |
The data would be out of date but better than nothing. |
| 15:31 |
rfrasur |
jeffdavis++ |
| 15:32 |
Guest90545 |
As long as I can figure out a starting point.. I think I can work around the code |
| 15:33 |
dbs |
jeffdavis++ |
| 15:37 |
gmcharlt |
a thought -- looking at the FK constraints after doing "\d actor.card" in psql might indicate if the actor.usr table was actually renamed, not dropped |
| 15:42 |
rfrasur |
(this ridiculous computer is just about to be replaced) |
| 15:42 |
Guest90545 |
Jeff the actor.card is gone as well |
| 15:45 |
tsbere |
A cascade drop might have gotten anything with a fk to actor.usr, and anything with a fk to those, etc....so action.circulation (for example) may also be gone... |
| 15:46 |
Guest90545 |
No it is there |
| 15:47 |
pastebot |
"dbs" at 204.193.129.146 pasted "Regenerating actor.usr from auditor.actor_usr_history - rough approach" (11 lines) at http://paste.evergreen-ils.org/13 |
| 15:47 |
|
Guest90545 joined #evergreen |
| 15:48 |
dbs |
probably lots of improvements that could be made to that, and obviously you need all the other fields, but that's the idea jeffdavis was suggesting. |
| 15:48 |
|
Guest90545 joined #evergreen |
| 15:50 |
|
TonyS joined #evergreen |
| 15:53 |
jeffdavis |
dbs++ |
| 15:56 |
|
toast_ joined #evergreen |
| 15:57 |
|
dboyle joined #evergreen |
| 15:57 |
|
toast_ left #evergreen |
| 15:59 |
|
TonyS joined #evergreen |
| 16:05 |
dbs |
Day 1 of running rel_2_4 current + Conifer tweaks: https://groups.google.com/d/msg/conifer-discuss/9TiULj4RpDo/2cw4BugdJJEJ |
| 16:09 |
bshum |
dbs++ |
| 16:13 |
rfrasur |
Alright friends, I need to go see a park about a shelter. Y'all be safe and happy and w/ full tummies and the like. |
| 16:17 |
jeff |
dbs++ |
| 16:17 |
jeff |
dbs: i noticed an issue that wasn't on the list. :-) |
| 16:18 |
jeff |
dbs: (the renewals bit from last night -- which may not have qualified for that list) |
| 16:24 |
jeffdavis |
thanks for sharing that, dbs |
| 16:31 |
jeffdavis |
interesting to hear about that client auto-update error, I was seeing the same error while testing updates on our test server too |
| 16:50 |
|
dboyle joined #evergreen |
| 17:05 |
|
mmorgan left #evergreen |
| 17:36 |
|
acoomes_ joined #evergreen |
| 17:55 |
|
jdouma_ joined #evergreen |
| 17:58 |
|
akilsdonk_ joined #evergreen |
| 18:23 |
|
ktomita_ joined #evergreen |
| 18:51 |
|
dMiller_ joined #evergreen |
| 18:59 |
|
stevenyvr2 left #evergreen |
| 21:46 |
dbs |
jeff: heh, right - that list was "Here are things you said you experienced today, and here's where they're at now" -- the "script-based circ = renewal failure" problem was wrapped up before today, thus, not on the list |
| 21:46 |
dbs |
but jeff++ # for assistance with that |
| 21:46 |
dbs |
jeffdavis: glad to know we're not totally crazy when it comes to auto-update weirdness |
| 21:50 |
dbs |
jeez, is paste.evergreen-ils.org down again? |
| 21:58 |
dbs |
speaking of which, finally opened bug 1192019 |
| 21:58 |
pinesol_green |
Launchpad bug 1192019 in Evergreen "Renewals fail with script-based circulation" (affected: 1, heat: 6) [High,New] https://launchpad.net/bugs/1192019 |
| 22:22 |
|
ktomita joined #evergreen |
| 22:22 |
|
sseng joined #evergreen |
