| Time |
Nick |
Message |
| 00:02 |
|
ldwhalen_ joined #evergreen |
| 00:08 |
|
remingtron_ joined #evergreen |
| 00:08 |
|
dbwells_ joined #evergreen |
| 00:10 |
|
rangi joined #evergreen |
| 00:10 |
|
rangi joined #evergreen |
| 00:10 |
|
dbwells__ joined #evergreen |
| 00:12 |
|
remingtron__ joined #evergreen |
| 00:22 |
|
dbwells_ joined #evergreen |
| 00:24 |
|
dac joined #evergreen |
| 00:29 |
|
rangi joined #evergreen |
| 00:29 |
|
rangi joined #evergreen |
| 00:29 |
|
_bott_ joined #evergreen |
| 00:36 |
|
_bott_1 joined #evergreen |
| 01:05 |
|
_bott_ joined #evergreen |
| 01:10 |
|
rangi` joined #evergreen |
| 01:48 |
|
BigRig_ joined #evergreen |
| 02:00 |
|
tsbere_ joined #evergreen |
| 04:42 |
|
geoffsams joined #evergreen |
| 07:09 |
|
kmlussier joined #evergreen |
| 07:37 |
|
rjackson-isl joined #evergreen |
| 08:10 |
|
akilsdonk joined #evergreen |
| 08:19 |
|
kbeswick joined #evergreen |
| 08:26 |
|
Shae joined #evergreen |
| 08:29 |
|
jeff_ joined #evergreen |
| 08:30 |
|
Guest24636 joined #evergreen |
| 08:41 |
|
finnx joined #evergreen |
| 09:01 |
|
ericar joined #evergreen |
| 09:16 |
|
Dyrcona joined #evergreen |
| 09:22 |
|
akilsdonk_ joined #evergreen |
| 09:27 |
|
dluch joined #evergreen |
| 09:35 |
|
RoganH joined #evergreen |
| 09:37 |
|
mllewellyn joined #evergreen |
| 09:51 |
|
akilsdonk joined #evergreen |
| 09:55 |
|
yboston joined #evergreen |
| 10:15 |
|
akilsdonk_ joined #evergreen |
| 10:15 |
|
mtcarlsoz joined #evergreen |
| 10:33 |
|
gmcharlt joined #evergreen |
| 10:36 |
jeff |
csharp: am i remembering correctly that you had a favorite tool for use on test/dev systems with regard to accepting all mail, but not relaying it on to its actual intended destination? |
| 10:36 |
jeff |
it might have been a specific configuration of sendmail/exim/postfix, or it might have been a special-purpose MTA. ring any bells? |
| 10:43 |
|
mrpeters joined #evergreen |
| 10:45 |
Dyrcona |
jeff: You could always setup an inetd entry on port 25 and redirect it to /dev/null. ;) |
| 10:46 |
Dyrcona |
That will "accept" all incoming mail and not send it on. |
| 10:46 |
jeff |
someone suggested nc -l > /dev/null :-) |
| 10:46 |
Dyrcona |
Yeah. |
| 10:46 |
Dyrcona |
It won't do SMTP, though, so the other end might get confused. |
| 10:46 |
tsbere_ |
jeff: I had, at one point, configured our mail server to accept all mail from our test systems but drop it into a local mailbox instead of the real destination(s) |
| 10:46 |
jeff |
i don't think that either option would -- right, exactly. |
| 10:47 |
jeff |
i might get some spam from old spambots, but not much else. :-) |
| 10:47 |
csharp |
jeff: one of our admins had set up postfix to send to a directory (not /dev/null :-), but a similar idea), and it was set up so we could connect an email client to it to see what was sent |
| 10:47 |
csharp |
I was actually just looking for that config |
| 10:47 |
csharp |
if I find it, I'll share |
| 10:47 |
tsbere |
We used an access table in postfix |
| 10:48 |
tsbere |
ip REDIRECT whatever local.ext |
| 10:48 |
tsbere |
I think that was "check_client_access hash:/path/to/file" in postfix. |
| 10:53 |
|
mrpeters left #evergreen |
| 10:55 |
|
kmlussier joined #evergreen |
| 11:13 |
kmlussier |
eeevil: The fix for https://bugs.launchpad.net/evergreen/+bug/1272316. You had mentioned getting it into 2.5 and 2.6. Any chance it can be backported to 2.4 at the same time? |
| 11:13 |
pinesol_green |
Launchpad bug 1272316 in Evergreen "much slower holds processing in 2.4+" (affected: 10, heat: 46) [High,Confirmed] |
| 11:14 |
eeevil |
kmlussier: absolutely |
| 11:14 |
kmlussier |
Great - thanks! |
| 11:14 |
eeevil |
I'm actually holding off cutting 2.4.next to give a couple folks a chance to test |
| 11:14 |
eeevil |
however, I'll probably not wait much longer, since csharp has confirmed its efficacy and was the OP on the bug |
| 11:15 |
eeevil |
IIRC |
| 11:15 |
eeevil |
yeah, he was |
| 11:15 |
kmlussier |
OK, good to know. I think we have a couple of people who are anxious to see it in production. |
| 11:18 |
eeevil |
kmlussier: IIRC, Dyrcona applied my SQL-ified, rebased version of depesz's ranked volumes patch (https://bugs.launchpad.net/evergreen/+bug/1234845) ... if you can confirm it's good for you, we could get that in soon, too. though that will probably not be 2.4 material (I'll have to look more closely) |
| 11:18 |
pinesol_green |
Launchpad bug 1234845 in Evergreen "possible optimization for evergreen.ranked_volumes database function" (affected: 2, heat: 12) [Medium,Triaged] |
| 11:18 |
eeevil |
kmlussier: applied to his test system, I mean |
| 11:19 |
Dyrcona |
Yep. |
| 11:19 |
kmlussier |
eeevil: I should have time to look at it today. |
| 11:19 |
* gmcharlt |
tosses OpenSRF bug https://bugs.launchpad.net/opensrf/+bug/1286198 out for consideration |
| 11:20 |
pinesol_green |
Launchpad bug 1286198 in OpenSRF "Improve process control at startup" (affected: 1, heat: 6) [Wishlist,New] |
| 11:20 |
gmcharlt |
it would be a 2.3.1 candidate, but I'm hoping that it might be reviewed as a candidate for 2.3.0 |
| 11:21 |
kmlussier |
The other depesz improvement I'm really interested in is https://bugs.launchpad.net/evergreen/+bug/1236979, but I'm not sure if the issues I found were anomalies or real issues |
| 11:21 |
pinesol_green |
Launchpad bug 1236979 in Evergreen "Speed up bibs-by-item-age" (affected: 1, heat: 10) [Medium,Confirmed] |
| 11:22 |
gmcharlt |
bshum: there's no direct way to mark bugs as fix-committed when you cut a release in LP, is there? |
| 11:22 |
gmcharlt |
er, fix-released that is |
| 11:22 |
eeevil |
kmlussier: thanks |
| 11:23 |
eeevil |
kmlussier: re the other one ... the issues you found confuse me, and I haven't looked back at it in a couple weeks |
| 11:23 |
* eeevil |
tosses it on the pile |
| 11:25 |
kmlussier |
eeevil: When you have time to look at it, let me know. The examples I used are outdated because new items have been added to the database since I first reported it. I'm happy to redo my testing at a time when eyes are on it. |
| 11:25 |
eeevil |
thanks! |
| 11:25 |
eeevil |
I will ping you before I start |
| 11:29 |
Dyrcona |
gmcharlt: You have to change each bug independently of the others, unless you write a script. |
| 11:29 |
gmcharlt |
Dyrcona: each time I hope the answer changes ;) |
| 11:30 |
Dyrcona |
gmcharlt: Launchpad API changes frequently and is poorly documented. My scripts stopped working two years ago and I never bothered to fix them. |
| 11:31 |
Dyrcona |
Anyone else in here use Syndetics for cover art? |
| 11:31 |
Dyrcona |
I'm trying to figure out if I should open a bug or if it is just something particular to us. |
| 11:32 |
jeff |
we do. |
| 11:32 |
jeff |
are you running into "dirty isbns aren't cleaned enough"? |
| 11:33 |
jeff |
i'm poking at that later today, i expect. |
| 11:33 |
jeff |
bshum and i had discussed it earlier, and he just reminded me about it this morning. |
| 11:36 |
Dyrcona |
dunno if that's the problem or not, I'll share a link with you in private. |
| 11:36 |
jeff |
but go on... what are you seeing? |
| 11:36 |
jeff |
ah. sounds good. |
| 11:39 |
bshum |
eeevil: I was going to help merge/ backport the holds stuff after I had a few days (which I have now), but also I was waiting for an answer on what your plans were for 2.4.x. Happy that you're on it though. |
| 11:39 |
bshum |
gmcharlt: And yeah, I end up just manually setting statuses all the time. Give me a chance to read them one last time and go "thank god that's mostly over with" :) |
| 11:40 |
jeff |
Dyrcona: yup. looks like the same issue. |
| 11:41 |
gmcharlt |
heads up to those who run on OpenSRF master - I will be pushing lp1179660 at some point soonish |
| 11:41 |
gmcharlt |
bug 1179660 |
| 11:41 |
pinesol_green |
Launchpad bug 1179660 in OpenSRF "OpenSRF.pm AUTOLOAD complicates testing / serves little purpose" (affected: 1, heat: 6) [Medium,Triaged] https://launchpad.net/bugs/1179660 |
| 11:42 |
gmcharlt |
there is a decent chance that it will expose further AUTOLOAD dependers in the Evergreen codebase |
| 11:42 |
gmcharlt |
in fact, that's exactly why I want to push it |
| 11:43 |
Dyrcona |
gmcharlt: Good to know. I won't update my development environment for a few days, but when I do, I'll update OpenSRF, too. |
| 11:44 |
pinesol_green |
[evergreen|Bill Erickson] LP#1179660: remove call to undefined initialize func - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=1e3a50f> |
| 11:44 |
jeff |
ah, i was just looking to see if that had made it in yet. :-) |
| 11:44 |
jeff |
gmcharlt++ berick++ |
| 12:19 |
|
jihpringle joined #evergreen |
| 12:33 |
eeevil |
bshum: if you want to sign off, I'll wait before merging. If you want to just merge, please feel free! |
| 12:33 |
|
Shae_ joined #evergreen |
| 12:33 |
bshum |
eeevil: Oh I have it queued up in my master branch, but hadn't looked at the backports quite yet. |
| 12:34 |
eeevil |
bshum: if you sign off on the master/2.6 version, I'll do the heavy lifting for backport. FWIW, we've pushed it into a 2.4 instance already |
| 12:35 |
bshum |
eeevil: Yeah I wasn't too worried about the backport testing since I knew folks were on the case. |
| 12:35 |
bshum |
Give me two seconds |
| 12:36 |
eeevil |
bshum: I'll give you FOUR |
| 12:36 |
bshum |
Heh |
| 12:36 |
bshum |
I have to double check which upgrade number we're on |
| 12:36 |
eeevil |
cuz I'm generous like that |
| 12:37 |
eeevil |
;) |
| 12:37 |
bshum |
I called it back the other day, but maybe we've moved some more? |
| 12:37 |
bshum |
Nope, still 0869 |
| 12:40 |
bshum |
Okay, it's in now. |
| 12:41 |
bshum |
Backporting |
| 12:42 |
bshum |
Oh I see |
| 12:42 |
bshum |
Well, it's in rel_2_5 |
| 12:42 |
pinesol_green |
[evergreen|Lebbeous Fogle-Weekley] LP1272316 - Speed up these settings lookups in the hold targeter that get repeated a ... - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=181c784> |
| 12:42 |
pinesol_green |
[evergreen|Lebbeous Fogle-Weekley] LP1272316 - Followup to make ou_ancestor_setting() even faster - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=4cb16a9> |
| 12:42 |
pinesol_green |
[evergreen|Mike Rylander] LP1272316 - Calculate proximity in the DB for speed - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=af966c3> |
| 12:42 |
pinesol_green |
[evergreen|Ben Shum] LP1272316 - Stamping upgrade script for pre-calculate-prox-adjustment - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=c1e03c0> |
| 12:43 |
bshum |
eeevil: I see what you mean with rel_2_4. Stupid whitespace. |
| 12:43 |
eeevil |
bshum: yeah, not too bad. not "heavy lifting" per se |
| 12:46 |
bshum |
eeevil: Yeah I can poke at it too, but if you've already got it, then maybe I'll let you ;) |
| 12:49 |
|
gsams joined #evergreen |
| 12:49 |
|
finnx joined #evergreen |
| 12:50 |
|
rangi joined #evergreen |
| 12:50 |
|
mllewellyn joined #evergreen |
| 12:50 |
|
Dyrcona joined #evergreen |
| 12:51 |
|
_bott_ joined #evergreen |
| 12:52 |
|
akilsdonk joined #evergreen |
| 12:55 |
eeevil |
bshum: I don't have it handy, but I will backport it if you prefer ... just tell me which you prefer ;) |
| 12:55 |
|
ktomita joined #evergreen |
| 12:56 |
|
dluch joined #evergreen |
| 12:59 |
|
Dyrcona1 joined #evergreen |
| 12:59 |
yboston |
what is the URL syntax I would use to grab MARXML for a particular bib record from TPAC (EG 2.5.1)? Thanks in advance |
| 13:04 |
jeffdavis |
yboston: /opac/extras/supercat/retrieve/marcxml/record/123 gives you the MARCXML for bib record with ID 123 |
| 13:04 |
|
jeff_ joined #evergreen |
| 13:06 |
yboston |
jeffdavis: thanks |
| 13:07 |
|
_bott_ joined #evergreen |
| 13:08 |
|
RoganH joined #evergreen |
| 13:12 |
|
rangi joined #evergreen |
| 13:12 |
|
rangi joined #evergreen |
| 13:16 |
|
mllewellyn joined #evergreen |
| 13:19 |
gmcharlt |
dbwells: I want to call your attention to bug 1286248, particularly the Evergreen side of it |
| 13:19 |
pinesol_green |
Launchpad bug 1286248 in OpenSRF "remove deprecated script osrf_ctl.sh" (affected: 1, heat: 6) [Wishlist,New] https://launchpad.net/bugs/1286248 |
| 13:19 |
bshum |
One thing I haven't filed yet on that is that brick_ctl.sh needs to be updated |
| 13:19 |
|
dluch joined #evergreen |
| 13:20 |
gmcharlt |
bshum: then you'll want to look at that bug as well |
| 13:20 |
bshum |
gmcharlt++ # will do |
| 13:20 |
bshum |
And eeevil, I'll tackle the backport right after I finish eating some of my lunch. |
| 13:20 |
eeevil |
bshum++ |
| 13:25 |
|
rjackson-isl joined #evergreen |
| 13:26 |
dbwells |
gmcharlt: thanks |
| 13:27 |
bshum |
eeevil: Gah, actually it sounds like I'm going to get pulled into something. If this is holding up you cutting the next 2.4, please feel free to proceed as you need. |
| 13:28 |
|
ericar joined #evergreen |
| 13:29 |
bshum |
Sorry. |
| 13:36 |
eeevil |
bshum: no worries |
| 13:46 |
|
Guest99466 joined #evergreen |
| 13:56 |
|
DPearl joined #evergreen |
| 14:59 |
jeff |
i/c |
| 15:00 |
jeff |
bah |
| 15:00 |
|
DPearl joined #evergreen |
| 15:23 |
jboyer-isl |
Is there some trick I'm missing with respect to rsyslog and eg-stats-collector? I followed the instructions here: http://git.evergreen-ils.org/?p=contrib/equinox.git;a=blob;f=monitoring/eg-stats/README and my logging machine is just dumping all kinds of stuff in the egstats file. |
| 15:29 |
kmlussier |
I'm looking at the new ranked volumes function on Dyrcona's server. It looks good, but then I got distracted by the shiny new "Group Formats and Editions" checkbox. |
| 15:30 |
kmlussier |
But I can't get it to work correctly on any search I try. When I click on a title to see the grouped records, I always get 0 results. |
| 15:30 |
kmlussier |
Is it possible the ranked volumes branch I'm testing affects it? I don't see any other dev branches on Jason's server that should affect the search results page. |
| 15:33 |
berick |
kmlussier: can't say for sure, but i would recommend merging https://bugs.launchpad.net/evergreen/+bug/1284864 before testing MR stuff. lots of fixes in there. |
| 15:33 |
pinesol_green |
Launchpad bug 1284864 in Evergreen "TPAC metarecord / formats repairs and usability additions" (affected: 1, heat: 6) [Undecided,New] - Assigned to Bill Erickson (erickson-esilibrary) |
| 15:37 |
|
dreuther joined #evergreen |
| 15:37 |
kmlussier |
I was just looking at those, but didn't see this particular problem being noted. |
| 15:37 |
kmlussier |
But I guess I won't worry about it for now. |
| 15:37 |
berick |
yeah, i'd be surprised if that branch solved your problem |
| 15:38 |
berick |
mostly just didn't want you to get stuck on other, unfixed stuff |
| 15:49 |
|
ktomita_ joined #evergreen |
| 16:06 |
|
RoganH joined #evergreen |
| 16:28 |
|
berickm joined #evergreen |
| 16:28 |
|
remingtron_ joined #evergreen |
| 16:38 |
|
Bmagic joined #evergreen |
| 16:39 |
Bmagic |
When reading marc from biblio.record_entry.marc with perl, do I need to encode/decode it? EG: decode_utf8($_) ? |
| 16:40 |
Dyrcona |
Not usually. |
| 16:40 |
Dyrcona |
Are you getting messages about wide characters? |
| 16:40 |
Bmagic |
yes! |
| 16:41 |
Dyrcona |
I usually open the output stream as UTF8 and make sure my environment is UTF8. |
| 16:41 |
gmcharlt |
using DBD::Pg? |
| 16:41 |
Bmagic |
DBD::Pg - yes |
| 16:42 |
Bmagic |
my $query = $conn->prepare($querystring); |
| 16:42 |
Bmagic |
$query->execute(); |
| 16:42 |
Bmagic |
while (my $row = $query->fetchrow_arrayref()) |
| 16:42 |
Bmagic |
something wrong with that? |
| 16:43 |
jeff |
is that the code throwing the error, or is the error being thrown when you try to do something else with the data? |
| 16:43 |
Dyrcona |
No. I don't ever get messages from DBD::Pg. |
| 16:43 |
Bmagic |
the code is later |
| 16:43 |
Bmagic |
but that is how I'm going through the results, is there a better way? |
| 16:44 |
Bmagic |
where $conn = DBI->connect("DBI:Pg:dbname=$dbname;host=$host;port=$port", $login, $pass, {pg_utf8_strings => 1,AutoCommit => 1}); |
| 16:44 |
Dyrcona |
Bmagic: man Encode or google "perl wide character in output" |
| 16:49 |
|
ktomita joined #evergreen |
| 16:50 |
|
remingtron__ joined #evergreen |
| 16:53 |
|
jeff_ joined #evergreen |
| 16:53 |
|
jeff_ joined #evergreen |
| 16:58 |
|
ericar_ joined #evergreen |
| 17:04 |
|
DPearl1 joined #evergreen |
| 17:05 |
Bmagic |
Honestly, I am totally confused about Encode.pm |
| 17:05 |
Bmagic |
I think that I have struggled with this for years now |
| 17:08 |
Bmagic |
I have written code to test the string for utf8 and wide characters ahead of time and then encode/decode depending. I have liftedcode from EG and sometimes messing with some other modules. It's all inconsistant and I have given up trying to figure this out but it keeps coming back and biting me |
| 17:11 |
|
23LAAEWVZ joined #evergreen |
| 17:11 |
Bmagic |
I would love a second set of eyes on this http://pastebin.com/e7D1s6Ys |
| 17:12 |
Bmagic |
specifially sub query{} |
| 17:15 |
|
rangi joined #evergreen |
| 17:15 |
|
rangi joined #evergreen |
| 17:21 |
Bmagic |
Acording to this: http://en.wikibooks.org/wiki/Perl_Programming/Unicode_UTF-8#1._Decoding_Text_Input I am supposed to use utf8::decode() when bringing strings in from the DB. " If any of these might contain UTF-8 encoded data/text, you must decode it." |
| 17:27 |
jeffdavis |
perl + unicode = headaches, in my experience |
| 17:31 |
Bmagic |
jeffdavis: exactly! |
| 17:32 |
Bmagic |
here is an example of the character that is messing it up: fianč (fiance) |
| 17:33 |
Bmagic |
that is pgadmin's representation of it |
| 17:36 |
|
rangi` joined #evergreen |
| 17:38 |
|
jeff__ joined #evergreen |
| 17:41 |
jeffdavis |
Bmagic: client encoding is set to UTF8 in your postgres database, right? |
| 17:41 |
jeffdavis |
(I know your code also explicitly tries to specify it via post_connect_sql) |
| 17:42 |
dbwells |
Bmagic: The example you gave is an HTML entity, which is not something that the Encode module deals with. Is that something pgadmin is inventing (for some strange reason), or is that the actual text in your data? |
| 17:42 |
Bmagic |
right, I noticed that, pg_utf8_strings => 1 - With that, in theory, I should not need the decode statement however, I have tried it with and without it and every combo with decode and I am still getting program exits |
| 17:43 |
Bmagic |
no, that was a copy and paste from pgadmin |
| 17:43 |
Bmagic |
it's probably represented differently in the DB |
| 17:44 |
Bmagic |
if you look at it on the OPAC, it looks strange: http://mig.missourievergreen.org/eg/opac/record/87124?expand=marchtml#marchtml |
| 17:44 |
jeffdavis |
I don't see pg_utf8_strings documented on the CPAN page for DBD::Pg |
| 17:45 |
dbwells |
I just don't know why pgadmin would entity-ize the data for display. If this is data from biblio.record_entry, it is entity-ized. |
| 17:46 |
dbwells |
That link looks ok to me, it is displaying the right character based on the code you gave. |
| 17:47 |
Bmagic |
dbwells: well, that's good, how do I keep perl from crashing on line 215 of Encode.pm ? |
| 17:48 |
* dbwells |
reads the scrollback, and gets less confused |
| 17:51 |
dbwells |
Bmagic: I need to run soon, but it may help me or others to know, what exactly are you trying to accomplish? |
| 17:51 |
Bmagic |
dbwells: I am trying to read the marc column from biblio.record entry - that's pretty muchit |
| 17:52 |
Bmagic |
dbwells: after I read the column, I run this code MARC::Record->new_from_xml(); |
| 17:54 |
jeffdavis |
Bmagic: do you have the script that contains MARC::Record->new_from_xml() ? can you pastebin it? |
| 17:56 |
Bmagic |
jeffdavis: sure, It's on our github repo https://github.com/mcoia/mobius_evergreen/tree/master/overdrive and the specific script is overdrive_import.pl |
| 17:58 |
Bmagic |
This is the important subroutine: importMARCintoEvergreen |
| 18:04 |
Bmagic |
thanks everyone for your help, have a good weekend, I will have to pick this up Monday! Sorry to start something that I can't finish |
| 18:05 |
Bmagic |
I will stay logged in to IRC but I have noticed that this computer will get kicked out over the course of time |
| 18:06 |
dbwells |
Bmagic: If you are still there, what exact error are you getting, and at what line? |
| 18:06 |
Bmagic |
dbwells: Cannot decode string with wide characters at /usr/local/lib/perl/5.10.1/Encode.pm line 215. |
| 18:07 |
Bmagic |
I'm fairly certian it's happening inside of DBhandler.pm (my code) on line 124ish |
| 18:09 |
dbwells |
Well, we'll need to eventually trace that error to see what line in *your* code is failing. We'll get to the bottom of it on Monday :) |
| 18:23 |
|
kmlussier joined #evergreen |
| 19:27 |
|
mllewellyn joined #evergreen |
| 21:21 |
|
zerick joined #evergreen |
