Evergreen ILS Website

IRC log for #evergreen, 2014-11-29

| Channels | #evergreen index | Today | | Search | Google Search | Plain-Text | summary | Join Webchat

All times shown according to the server's local time.

Time Nick Message
01:28 phasefx__ joined #evergreen
01:28 Callender_ joined #evergreen
01:40 dkyle joined #evergreen
05:10 pinesol_green Incoming from qatests: Test Success - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html>
05:15 wsmoak joined #evergreen
05:54 wsmoak joined #evergreen
06:28 phasefx joined #evergreen
06:29 mceraso joined #evergreen
06:30 Callender joined #evergreen
06:53 nhilton joined #evergreen
09:31 Dyrcona joined #evergreen
09:54 bshum Dyrcona: I think bug 1350345 supercedes the newly reported bug 1397532
09:54 pinesol_green Launchpad bug 1350345 in Evergreen 2.6 "marc export can blow up with bad records" (affected: 1, heat: 6) [Undecided,Fix released] https://launchpad.net/bugs/1350345
09:54 pinesol_green Launchpad bug 1397532 in Evergreen "marc_export utility allows the creation of invalid (too large) MARC records" (affected: 1, heat: 6) [Undecided,Triaged] https://launchpad.net/bugs/1397532
09:54 bshum Since it's applied to 2.6+ and the new bug is for 2.5 (a security fixes only release), maybe we can mark it off as duplicate and remove it.
09:55 bshum I believe at the time, I only backported it to 2.6 because that's when the new version of marc_export went in.  And 2.5 is the older one.
09:57 Dyrcona bshum: I'll look, but I think it is a different issue.
09:57 bshum Dyrcona: Ah, yes, it does look to be a little different now that I'm reading the code bits.
09:58 Dyrcona @later tell dbs Yes, we have a tendency to crash when crawled.
09:58 pinesol_green Dyrcona: The operation succeeded.
09:58 bshum Well, maybe
09:58 Dyrcona bshum: Records with "invalid" sizes don't cause marc_export to crash.
09:59 bshum True.
09:59 Dyrcona And the fix for the older bug in no way affects record sizes, so it is definitely different.
10:00 bshum But wouldn't it have passed the warning off with the bib ID?
10:00 bshum And then proceeded to make a sucky export
10:00 Dyrcona He's getting the warning from MARC::Lint.
10:03 Dyrcona He's also probably "backported" the new marc_export, 'cause there is no reason that it wouldn't work with 2.5, as far as I know.
10:03 bshum Sure, if you grabbed the whole thing from a newer release I guess.
10:04 Dyrcona Just cherry-pick the commit(s) or copy the complete file and alter your Makefiles.
10:05 Dyrcona @blame MARC
10:05 pinesol_green Dyrcona: MARC forgot to give the gerbils their chocolate-frosted sugar bombs
10:06 bshum Huh
10:06 bshum Speaking of dependencies
10:07 * bshum wonders why he gets "Can't locate Date/Manip/Date.pm in @INC"
10:07 * bshum checks his utility server...
10:08 * Dyrcona sometimes forgets new dependencies when upgrading.
10:08 bshum These are fresh installed servers, they should have everything, but maybe I've missed something...
10:10 Dyrcona Maybe its missing from Makefile.install for your distro?
10:11 Dyrcona Is this precise or trusty?
10:11 bshum It's a precise server, but I'm checking the Makefile.install for both Ubuntu in master to see if I'm missing something
10:11 bshum I didn't see it in Evergreen, checking OpenSRF now
10:12 Dyrcona Is that used by marc_export? I forget...
10:12 bshum Line 24 of marc_export
10:13 bshum So it seems I should look for a package like libdate-manip-perl
10:14 Dyrcona Yep.
10:14 bshum I think it's missing.
10:17 Dyrcona Looks like it is missing, but I seem to recall something else possibly depending on it.
10:18 Dyrcona I could be mistaken, but even if I'm not, it won't hurt to make sure it is installed.
10:19 bshum You're probably right, I don't know how else I could have tested or used the new marc_export previously otherwise
10:19 bshum Maybe something changed when we moved to the modularized makefiles per distro
10:19 Dyrcona I wonder if it was in there and got axed by a jumbled/out of sync commit?
10:20 bshum Hmm, maybe.
10:20 Dyrcona Well, I recall something else being missed when that happened.
10:20 bshum Yeah
10:20 Dyrcona Stripe was missed for Ubuntu.
10:20 bshum Sigh, guess we should file that bug and fix too :)
10:20 Dyrcona Yep.
10:20 Dyrcona Or, it wasn't moved to the force section, something like that for stripe.
10:21 Dyrcona You file a bug, I'll do a branch real quick.
10:23 Dyrcona Seems to be missing on Debian, too.
10:28 Dyrcona I'll add it for Debian, since it is the same package name there.
10:30 Dyrcona Looks like the Fedora package is perl-Date-Manip.
10:30 Dyrcona bshum: Think I should add it as a dependency for Fedora, too?
10:38 jeff "something else adding it" can sometimes be the difference between using apt or aptitude, or having your "recommends == important" settings set non-default
10:40 Dyrcona bshum: * [new branch]      missing_dep_date-manip -> user/dyrcona/missing_dep_date-manip
10:41 Dyrcona jeff: Could be. This work was done just about the time of the move to the split up Makefiles, so it could have been missed in the shuffle, too.
10:41 jeff *nod*
10:47 Dyrcona Looks like the dependency was just plain missed.
10:48 Dyrcona I don't see it in my working branch.
10:51 bshum Maybe it got lost when we changed working branches from Marque.pm
10:51 bshum Oh well.
10:52 bshum Dyrcona++ # I'll test it later this weekend
14:41 dbs Dyrcona: dang. sounds like something we should fix; a web app that can't handle requests for web pages isn't very useful :/
14:41 * dbs wonders if it's the same "extremely broad searches cause a cascading database denial of service" issue that we faced a while back
14:52 Dyrcona Dunno. We recently changed some O/S settings after a crash.
14:52 Dyrcona We get lots of NOT CONNECTED TO THE NETWORK messages every day.
14:53 Dyrcona Might be related, might not be.
15:18 sandbergja joined #evergreen
16:37 StephenGWills joined #evergreen
16:52 pinesol_green Incoming from qatests: Test Success - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html>
17:09 jeff dbs: what are your thoughts on search engine indexing of searches in general (say, from external links to search results) and things like subject/facet/related searches?
17:11 jeff dbs: with sitemaps being a path toward indexing of the records without searches, is it useful/important to index the search result pages themselves?
18:53 StephenGWills left #evergreen

| Channels | #evergreen index | Today | | Search | Google Search | Plain-Text | summary | Join Webchat