Evergreen ILS Website

IRC log for #evergreen, 2014-07-10

| 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
00:00 gsams joined #evergreen
00:47 board joined #evergreen
02:30 b_bonner joined #evergreen
02:31 mnsri joined #evergreen
02:31 mtcarlson_away joined #evergreen
05:01 dbwells_ joined #evergreen
05:02 jboyer-isl joined #evergreen
05:02 adbowling-isl joined #evergreen
05:21 _bott_ joined #evergreen
06:03 b_bonner_ joined #evergreen
06:04 tsbere_ joined #evergreen
06:04 mtcarlsoz joined #evergreen
06:40 b_bonner joined #evergreen
06:41 mnsri joined #evergreen
06:42 mtcarlson_away joined #evergreen
07:12 artunit joined #evergreen
08:28 Dyrcona joined #evergreen
08:29 collum joined #evergreen
08:32 akilsdonk joined #evergreen
08:40 mmorgan joined #evergreen
08:56 jwoodard joined #evergreen
09:18 rjackson-isl joined #evergreen
09:20 kbeswick joined #evergreen
09:31 _bott_ joined #evergreen
10:30 * bshum taps his fingers waiting for a new 14.04 VM to finish installing
10:34 jeff i may have exhausted all of my luck with barcode scanners. usually they're pretty tame, not very annoying devices.
10:34 jeff dealing with two that seem to have factory defaulted after installing windows updates.
10:34 jeff trying to reproduce.
10:35 jeff so far, we can't reproduce the issue.
10:40 tsbere jeff: Some barcode scanners have reset codes that can be sent to them from the PC side, though I haven't heard of any getting reset in that manner without special software. I *have* heard that some fancy media keyboard drivers, however, will try and talk to a barcode scanner instead of their intended keyboard...
10:41 jeff good to know.
10:42 jeff detatching and re-attaching the scanner did not seem to trigger the issue, and restarting the computer did not appear to trigger the issue, but this single computer has experienced this issue with two different barcode scanners, both times apparently after installing windows updates and rebooting.
10:42 jeff rather odd.
10:44 tsbere jeff: I know that at least one media keyboard with fancy programming capabilities I had "reset and re-configured" after the driver updated, without prompting me. Which was a pain when I was using it on two different machines (desktop and laptop) and the config had been loaded by the *other* computer...
10:45 * tsbere assumes it was less work for the manufacturer to have the keyboard send different signals on the standard keyboard driver than to have a custom driver that changed the signals mid-stream, especially as then the keyboard still worked in the bios and such
10:47 mmorgan jeff: what make and model barcode scanner?
10:53 jeff mmorgan: This is a Motorola (nee Symbol) LI2208 attached via USB to a Windows 7 computer
10:54 jeff I'm unable to locally reproduce the issue. I'm going to get the remote site back online by scanning a few key programming barcodes, then see if it happens again.
10:54 tsbere jeff: Oooooooh......I have never had good luck with them remembering settings. Though half the ones I had access to also didn't have *drivers* available...
10:55 jeff If it does happen again, I'm going to dig into things like other software/drivers present.
10:55 jeff tsbere: you've had troubles getting this specific model to remember settings?
10:55 jeff we don't install (or usually need to install) drivers for these.
10:55 tsbere jeff: No. I have had troubles getting the entire brand to remember settings.
10:55 jeff ugh. :P
10:56 tsbere jeff: And when I say "didn't have drivers" I mean "they refused to emulate a keyboard and had funky serial interfaces" ;)
10:56 jeff oh. yeah, that is not the case here. :-)
10:56 tsbere jeff: I suggest figuring out the barcodes needed to program it, make a sheet with the barcodes in order, and then stick it under the keyboard. Start with "reset to defaults". When it goes wonky they can just flip the keyboard over, scan the barcodes, and get back to work. ;)
10:58 bmills joined #evergreen
11:03 mmorgan jeff: could the workstation have a utility installed that can reset the scanner? looks like there is such a thing for those: http://www.motorolasolutions.com/SMS
11:07 asimon joined #evergreen
11:13 asimon *: I'm planning to delete a large number of deleted bib records with no corresponding asset.call_number entries.  The only instructions I can find are very old.  After I drop the protect_bib_rec_delete rule, I think I need to change the bibliographic.record_entry.id constraint as follows:
11:13 asimon *: ALTER TABLE biblio.record_entry DROP CONSTRAINT record_entry_pkey ADD CONSTRAINT record_entry_pkey PRIMARY KEY(id) ON DELETE CASCADE;
11:13 asimon *: Is that correct?
11:15 bshum Uh
11:15 tsbere asimon: I would just disable (not drop) the protect_bib_rec_delete, and I can't think of any situation where a primary key needs an on delete cascade flag. Foreign keys, yes, but not primary.
11:15 tsbere asimon: As such, only things *referring* to biblio.record_entry would need altering to do a cascade delete, which is easier said than done.
11:19 asimon tsbere: The old instructions said to issue the following command:  DELETE FROM biblio.record_entry CASCADE WHERE ID = blah;, which is not a valid command.  Would dropping or disabling the rule allow me to delete the bibs that do not have corresponding acn entries?
11:20 bshum asimon: What "instructions" do you refer to?  Out of morbid curiosity
11:21 Dyrcona asimon: Actually deleting "empty" bib records is a lot of work.
11:21 asimon bshum: http://libmail.georgialibraries.org/pipermai​l/open-ils-general/2009-February/001191.html
11:22 bshum asimon: I'd be concerned too that bibs were used in other ways beyond just not having call numbers attached to them.  Like what if they were used in buckets, or acquisitions, etc.
11:23 bshum Yes, what Dyrcona says :)
11:23 mmorgan ditto!
11:24 Dyrcona You have to disable at least 6 rules and triggers.
11:24 RoganH joined #evergreen
11:25 asimon bshum: Definitely not used in acquisitions, and likely not in buckets, as these are electronic records.
11:25 Dyrcona And then delete from about 20 tables.
11:25 bshum If they're electronic records, then I'm even more concerned about how interconnected they might be.
11:25 bshum Depending on what kind
11:27 Dyrcona Then, you'll want to vaccuum full analyze the tables and put the rules and triggers back in place.
11:28 bshum Well, in any case, just be careful how you identify which bibs to delete.  And do it all on a test server a couple of times first.  People have been known in the past to have removed their protections and then deleted the wrong bibs to dangerous consequences...
11:28 Dyrcona Yep, that, too.
11:29 bshum There's a decent number of instances in our IRC logs for those unhappy stories.
11:31 Dyrcona IOW, unless you're going to get a major benefit from it, such as cutting your database by a significant %, I wouldn't bother.
11:34 mmorgan problem is, the empty bibs show in staff searches, which is hugely annoying.
11:34 asimon Dyrcona  OK, even through this would drop the database from almost 400,000 records down to about 35,000 records, I'll deal with this another way.  Has anyone modified marc_export to output only deleted records?  I attempted to modify it but my Perl skills are limited.
11:35 Dyrcona asimon: The new marc_export in 2.6 and later does export deleted records when you use the --since option, IIRC.
11:35 Dyrcona It doesn't have a feature to export only deleted records, though.
11:36 Dyrcona Deleted records also have the record status field set to 'd' if not already.
11:36 Dyrcona However, if you're eliminating that many records. It might be worth it to try. It just won't be easy.
11:37 asimon Dyrcona:  TY
11:39 Dyrcona asimon: Do you have a test/training database you can test it on?
11:39 asimon Dyrcona:  I'll use COPY (SELECT marc FROM biblio.record_entry WHERE deleted = 't') to a file and then convert the XML to MARC with yaz-marcdump.
11:40 Dyrcona asimon: That sounds like it should work, thought it should already be xml.
11:41 asimon Dyrcona:  Yes, but I want MARC, not XMLMARC.
11:41 yboston joined #evergreen
11:41 asimon Dyrcona: Sorry.  MARCXML.
11:41 Dyrcona Oh, right, sorry. my brain inverted the words.
11:41 tspindler joined #evergreen
11:42 Dyrcona You might need to add the collection or whatever it is around the xml content in the file first. Not sure.
11:43 Dyrcona collection tag that is.
11:44 Dyrcona Well, the schema says its optional, so guess not.
11:47 bshum mmorgan: Empty bibs sure, but not "deleted" bibs.
11:47 bshum And as far as empties go, that's just a necessary evil of cataloging new items as far as I'm concerned :)
11:47 bshum But I know there's been a fair amount of discussion about how that ought to work in the future.
11:51 mmorgan bshum: gotcha
11:51 bshum Deleted bibs shouldn't show up in regular searching either in staff client or otherwise, unless you are indexing them and using the deleted flag for searching.
11:51 bshum Which I don't do or have experience with, but remember reading in some release notes somewhere that it was possible....
11:52 Dyrcona Deleted bibs can show up on our system, because we index them.
12:01 jboyer-isl This is irritating. I've got a server where http searches seem to work fine, but https searches take so long that they time out. (Always time out in the client, usually time out in browsers)
12:01 jboyer-isl Sounds like an Apache issue, but I can't see anything that points at an issue.
12:02 pinesol_green [evergreen|Robert Soulliere] Documentation: Update upgrade instruction for 2.6.1 - <http://git.evergreen-ils.org/?p=​Evergreen.git;a=commit;h=e6af464>
12:02 pinesol_green [evergreen|Remington Steed] Documentation: Upgrade instructions examples - <http://git.evergreen-ils.org/?p=​Evergreen.git;a=commit;h=28a5085>
12:03 Dyrcona jboyer-isl: Encryption using too much CPU?
12:03 jboyer-isl Almost none.
12:04 jboyer-isl I spoke too soon about the logs though, Plenty of this: "The timeout specified has expired: SSL input filter read failed."
12:04 jboyer-isl Though no idea what to do about it. :/
12:04 jeff is it only searches?
12:04 Dyrcona jboyer-isl: We see that all the time. I don't think it is relevant to slow searches.
12:04 jboyer-isl Drycona: I had top running while doing some searches, top itself was usually at the top of hte list.
12:05 jeff "Encryption using too much CPU" is likely not the issue (not sure if that was a joke). https://istlsfastyet.com/ :-)
12:05 jboyer-isl jeff: That we've noticed. It's just a demo server so nothing is normally done on it. I'll try some circs and see what happens
12:05 jeff is there a proxy/load balancer in the mix?
12:05 jboyer-isl Nope, direct connection.
12:05 jeff (that might be sending your searches to a host other than the one you think)
12:06 jboyer-isl Single server aside from the Db.
12:06 Dyrcona jeff: Half serious. I could see a corrupted OpenSSL install causing an issue.
12:06 jeff is it using a real or a self-signed cert? are your clients firewalled off from the internet at large, and therefore might not be able to perform OCSP lookups/etc?
12:07 jboyer-isl Self-signed, and I'm tunneling directly into the same LAN with an otherwise completely open machine.
12:07 jeff tunneling how? you mentioned "direct connection" earlier.
12:08 jboyer-isl Direct connection just means no load balancer, poor choice of words. The IP the name resolves to is the one running Apache and OpenSRF.
12:10 mceraso dbwells: Just finished testing the maintanence release for 2.6.2 using Ubuntu LTS 12.04. It works well :)
12:10 jboyer-isl Tunneled over SSH, though I'm testing a "normal" connection now also.
12:11 jboyer-isl (It has a public IP)
12:11 Dyrcona Added content? Could that be using https and the vendor doesn't support it?
12:13 jboyer-isl I guess it's possible, I'll check.
12:14 Dyrcona I've never seen searches be slow just over https, so I'm grasping.
12:14 Dyrcona jeff has made some good suggestions, too.
12:21 jboyer-isl Disabled added content to no effect, now we try the ages-old method of restart it and see.
12:28 dbs jboyer-isl: tunneled over ssh with compression of the ssh tunnel enabled?
12:28 dbs compression + encryption still shouldn't be that slow though.
12:29 jboyer-isl dbs: Not that I'm aware of. I'm testing over a regular connection now just to avoid the possibility that it's tunnel related.
12:29 jeff At the risk of sounding like SAPS, this could be an MTU issue.
12:30 jeff It would be interesting to see if an HTTPS request for a small file (such as robots.txt) and an HTTPS request for a larger (ten meg or so) are any different from each other, and are any different from the searches.
12:32 jboyer-isl Oh. It appears to be at least partially related to the hour+ long bib searches that were hung up on 4 of the postgres backends that serve that installation. I cleared that out and now it's returning results in the staff client again.
12:33 jeff So the difference between http and https was just happenstance?
12:33 ericar joined #evergreen
12:33 jboyer-isl Looks that way. Nothing else I've tried has made any difference.
12:34 jboyer-isl This thing is never fast, really, but I didn't think it was on the brink or anything.
12:34 dbs DoS_searches--
12:34 dbs "a", "the", "it", bah.
12:36 jboyer-isl Bah. I may have spoken too soon, not everything is working 100%.
12:36 jeff heh
12:37 jboyer-isl It'll have to wait until after lunch, as my appetite for dealing with it has been exceeded by my appetite for food.
12:37 jeff oh hey. it's that time, isn't it.
12:38 dbs Lunch. Mmm. Good idea.
12:38 Dyrcona Just finished lunch.
12:40 Dyrcona I usually only find hanging searches when I try to reload my dev system's database.
12:40 Dyrcona However, I haven't seen any in months.
12:41 Bmagic Has anyone else seen pickup notice emails go out with blank title and author?
12:43 Dyrcona Bmagic: Long, long ago, IIRC.
12:44 Dyrcona tsbere might remember better what the cause was, since I think he fixed it for us.
12:44 Dyrcona He's not at his desk at the moment.
12:44 Bmagic The only thing that I see here is that the title has a diacritic. The pickup notices are usually fine. Sometimes, we see the title and author blank. In this case, it's only the title that has a diacritic, the author does not have one.
12:45 Dyrcona I'm not sure it was diacritics in our case.
12:45 Dyrcona I think we solved it by pulling title and author in a different way.
12:45 Bmagic Right on. I will ask tsbere
12:46 Dyrcona He'll probably see this when he catches up back at his desk. He'll notice he's been mentioned.
12:46 Bmagic @later tell tsbere Do you remember dealing with pickup notices containing blank titles and or author names?
12:46 pinesol_green Bmagic: The operation succeeded.
12:46 Dyrcona This was over two years ago, though.
12:47 Bmagic No problem, it would be interesting to find the answer
12:53 tsbere Bmagic: I don't need @laters during the day. My client blinks at me when someone mentions me ;)
12:53 Bmagic tsbere: right on
12:54 tsbere Bmagic: And I don't recall what the issue(s) were on that. I seem to recall some being a reporter template for the hold requests to bib mapping not including all hold types, but I don't recall if that affected hold notices or not.
12:55 tsbere Bmagic: If you know what kinds of holds have issues, for example, that may be a good starting point. "Only part holds" indicates one possible issue, very different from "random holds of all types"
12:56 Bmagic tsbere: I will have to take a look and see what type of hold it was. You found that the hold type uses different code to create the pickup notice?
12:57 Bmagic tsbere: It was a title level hold "T"
12:59 Bmagic tsbere: http://missourievergreen.o​rg/eg/opac/record/1311697
13:01 mrpeters joined #evergreen
13:04 Dyrcona Bmagic: I'd look at the A/T template for hold notifications and work backwards to see what field is being used for the title and author.
13:04 Dyrcona Bmagic: Then try some of the lookups on that record.
13:05 Dyrcona I seem to recall our issue being that some records weren't getting the right information because of the way titles and authors were being looked, but I'm not 100% on that.
13:05 hbrennan joined #evergreen
13:05 ldw joined #evergreen
13:05 ldwhalen joined #evergreen
13:06 Dyrcona And, our template has been modified some since then, so my looking at ours won't be so helpful.
13:13 Dyrcona bshum: I added a comment with a linked branch on lp 1302207 for ya.
13:13 pinesol_green Launchpad bug 1302207 in Evergreen "Syndetics broken cover image retrieval" (affected: 2, heat: 14) [Medium,Confirmed] https://launchpad.net/bugs/1302207 - Assigned to Jeff Godin (jgodin)
13:13 bshum Dyrcona++ # thanks, I'll try that soon-ish
13:13 Dyrcona And for jeff, too, I guess. :)
13:17 Dyrcona I guess it doesn't really fix the problem of a number before the ISBN, but I've never actually seen that in a real MARC record, only after.
13:18 Dyrcona never mind. I'll stop dwelling on it. :)
13:23 jeff I think we spent enough time yesterday dwelling on it. :-)
13:24 Dyrcona Hehe. We did.
13:24 vlewis joined #evergreen
13:25 Dyrcona I've loaded that on my dev machine and I still get the same images as before clearing the cache, so I'm confident it doesn't break anything. :)
13:26 bshum Wow, the readme looks so much deeper than I remember.
13:27 bshum Clearly I need to read it more thoroughly in the future :)
13:29 ericar joined #evergreen
13:33 bshum csharp: Do you have a 14.04 system running presently?
13:34 bshum I'm getting some nasty 404 error -- <404>  Method [open-ils.circ.copy_note.retrieve.all] not found for OpenILS::Application::Circ
13:34 bshum And internal server error on the record details
13:34 ericar_ joined #evergreen
13:36 bshum Not sure where that goofed, but it looks like a nasty problem
13:38 bshum Not sure if this is a perl 5.18 issue or maybe something else
13:41 bshum That all said, the makefile changes look fine to me.  Seems reasonable to start by adding those to master and then troubleshooting other issues.
13:41 bshum I just want to tinker with the README a bit, there's some syntax issues in there are asciidoc complained about.
13:43 pastebot "bshum" at 64.57.241.14 pasted "or maybe it's opensrf that's the problem?" (7 lines) at http://paste.evergreen-ils.org/70
13:45 * bshum should have tried not OpenSRF master
13:46 bshum But eh, fun times troubleshooting :)
13:55 krvmga joined #evergreen
13:57 krvmga in eg 2.5 > in the opac > on the browse the catalog page, i'd like to change the order of the qtypes displayed in the "Browse for" dropdown so that Subjects is first. can this be done? if so, where do i have to do it?
13:58 krvmga i looked in qtype_selector.tt2 but it didn't seem obvious to me from there.
14:00 bshum krvmga: Uh, are you talking about the Browse search?
14:00 bshum qtype_selector seems to be for the basic search
14:00 krvmga bshum: yes
14:00 bshum To me
14:00 krvmga bshum: the second part of qtype_selector.tt2 looked like it might bear on browse.
14:01 krvmga browse.tt2 includes qtype_selector.tt2
14:01 bshum krvmga: So
14:02 bshum If you just move around the order of qtypes in that file
14:02 krvmga [% control_qtype = INCLUDE "opac/parts/qtype_selector.tt2"
14:02 krvmga id="browse-search-class" browse_only=1 plural=1 %]
14:02 bshum Where the query_types are defined
14:02 bshum The order to which those are listed seems to follow
14:02 bshum But I would imagine that putting Subject ahead of title, etc. would do the same in the qtype selector in other places too
14:02 bshum Yeah
14:02 bshum If I put keyword, then subjects
14:02 bshum It puts subjects as default browse
14:03 bshum But also puts it ahead of title in the selector for the basic search
14:03 krvmga bshum: yeah, i noticed
14:03 krvmga that's why i was wondering if it was possible at all.
14:03 krvmga without messing up the dropdowns in other places
14:04 bshum Sounds like a new feature to me if you wanted it to have separately defined options :)
14:04 bshum But I haven't played with the code long enough yet
14:07 bshum Like the sort of thing that'd be a nice addition to the config file options someday.
14:08 eeevil or, better, just add that info to config.search_class and load it dynamically (and cache it, of course)
14:08 eeevil config_file--
14:09 bshum Well, sure. ;)
14:09 eeevil (hint: we're already loading and caching search class info, an aliases, and other stuff)
14:10 krvmga *sigh*
14:12 bshum krvmga: In the short-term, who cares what the dropdown order is?  Just change it and let it ride!  :D
14:12 bshum Or you know, start asking for some dev quotes.  Or get your programmers to start tinkering ;)
14:12 bshum 2.7 isn't feature frozen yet.
14:12 bshum *cough, cough*
14:12 krvmga i would like to start tinkering. this sounds like a small thing that might not be out of my reach.
14:14 eeevil krvmga: it's a small-ish thing that touches all the layers (db, idl, caching, egweb, templates), so it might be good as a learning exercise if you're unfamiliar with how some of that fits together
14:14 krvmga kewl
14:14 bshum Dyrcona: tsbere: Since your group and I are the two master nuts here, do you have any objection if I pull in the 14.04 makefile changes to master and we can hammer out the remaining quirks as we go?
14:15 bshum Or should I just keep it in the topic branch for now
14:15 Dyrcona I don't have a problem with it going into master if you're confident we can iron out the problems by the 2.7 release.
14:15 eeevil bshum++ # motivation-to-fix-stuff
14:16 Dyrcona We won't be upgrading production to 14.04 until EDI issues are straightened out.
14:16 bshum Ah right, the EDI issues :(
14:16 Dyrcona I'm upgrading my dev vm to 14.04 via do-release-upgrade right now, in fact.
14:16 bshum Well, generally speaking, my goal is to get 2.7 final working with 14.04.
14:16 bshum But yeah I hear you
14:17 Dyrcona Yeah, I think 2.7 should work on 14.04 also.
14:17 Dyrcona We just started using acq this month. Be a shame to have to take it away.
14:18 bshum Indeed.
14:18 Dyrcona Anyway, I say go for it.
14:18 bshum A real shame. :)
14:18 Dyrcona I should be building 14.04 vms in a week or so.
14:19 bshum I found one more README tweak I want to make (have to yank out any remaining references to Lucid since that's getting dropped)
14:28 krvmga eeevil: ok, tspindler gave me the go-ahead to tinker with it. we'll see what happens.
14:28 krvmga i'm sure i'll learn a lot.
14:31 bshum csharp++ # forging the path ahead
14:32 jboyer-isl I return confused. Whatever is up with searching is db related. I'm searching the opac in a browser, https to minimize variation. I load top on the db server and let it sit. browser search: 1 postgres task to 100%, then 10 at 100%, then none. (The whole exchange is a little slow, but it does work.)
14:33 pinesol_green Showing latest 5 of 11 commits to Evergreen...
14:33 pinesol_green [evergreen|Chris Sharp] LP#1315531 Adding further changes to the server install docs for Ubuntu 14.04: - <http://git.evergreen-ils.org/?p=​Evergreen.git;a=commit;h=3db76b0>
14:33 pinesol_green [evergreen|Chris Sharp] LP#1315531 Correcting typo: "eg_host.conf" -> "eg_vhost.conf". - <http://git.evergreen-ils.org/?p=​Evergreen.git;a=commit;h=2f07808>
14:33 pinesol_green [evergreen|Chris Sharp] LP#1315531 Quick clarification about which Ubuntu we mean. - <http://git.evergreen-ils.org/?p=​Evergreen.git;a=commit;h=c49517c>
14:33 pinesol_green [evergreen|Ben Shum] LP#1315531 Fix README asciidoc syntax - <http://git.evergreen-ils.org/?p=​Evergreen.git;a=commit;h=609d9e1>
14:33 pinesol_green [evergreen|Ben Shum] LP#1315531 Remove remaining references to Lucid from README and Makefile - <http://git.evergreen-ils.org/?p=​Evergreen.git;a=commit;h=fcfff08>
14:33 jboyer-isl Staff Client search: click Search, watch 1 postgres process sit at 100% until I get tired of it.
14:33 jboyer-isl :/
14:33 dbs jboyer-isl: any recent upgrades?
14:34 dbs jboyer-isl: does the 100% only happen with specific searches, or any search?
14:35 dbs Did anyone drop or recreate indexes recently?
14:35 dbs All sorts of potential problems.
14:35 Dyrcona csharp++ bshum++
14:36 jboyer-isl The data is identical to production, we did a dump/restore, and ran a test migration. It's every search.
14:37 jboyer-isl Osrf/Eg versions are also the same.
14:38 Dyrcona Any problems with the restore?
14:42 jboyer-isl The usual (rebuild those 2 authority indexes and the auditor schema since I didn't dump it)
14:44 bshum remingtron++ # taking a look at bug 1210161 and it looks good.  Testing the upgrade script and then I'll probably push that on in.
14:44 pinesol_green Launchpad bug 1210161 in Evergreen "TPAC "my list" still referred to as "bookbag" in some places" (affected: 3, heat: 16) [Medium,Confirmed] https://launchpad.net/bugs/1210161
14:46 dbs jboyer-isl: oh, test migration == upgrade to newer version?
14:46 jboyer-isl Dyrcona: Ah, and apparently all of config.z3950_index_field_map is missing. Is that table more important than it's z3950 prefix would suggest?
14:47 jboyer-isl dbs: Nope, just adding a new lib. I've got another server for upgrade testing, it went great so far as I can tell though I don't have a client built for it yet.
14:47 Dyrcona No, it isn't but I've had that happen seemingly randomly before.
14:48 dbs ANALYZE run after the restore?
14:48 bshum Calling 0884
14:50 jboyer-isl dbs: Only on metabib.metarecord and metarecord_source_map. I'll give that a shot and see if it helps. (Hasn't been necessary in the past that I can recall, but maybe we've crossed a threshold in size?)
14:51 edoceo joined #evergreen
14:55 pinesol_green [evergreen|Remington Steed] LP#1210161: Finish renaming bookbag to list - <http://git.evergreen-ils.org/?p=​Evergreen.git;a=commit;h=3f2be6c>
14:55 pinesol_green [evergreen|Remington Steed] LP#1210161: Upgrade script to rename bookbag to list - <http://git.evergreen-ils.org/?p=​Evergreen.git;a=commit;h=7c0562b>
14:55 pinesol_green [evergreen|Ben Shum] LP#1210161: Stamping upgrade script to rename bookbag to list - <http://git.evergreen-ils.org/?p=​Evergreen.git;a=commit;h=4836d0b>
14:59 pinesol_green [evergreen|Bill Erickson] LP#1327284 Display Imported As column in vandelay queue - <http://git.evergreen-ils.org/?p=​Evergreen.git;a=commit;h=aa5671b>
14:59 pinesol_green [evergreen|Yamil Suarez] Documentation: added release notes for LP#1327284 Display "Imported As" column - <http://git.evergreen-ils.org/?p=​Evergreen.git;a=commit;h=ba629d5>
15:05 pinesol_green [evergreen|Victoria Lewis] LP#1316814: Change potentially incorrect information display in hold_status.tt2 - <http://git.evergreen-ils.org/?p=​Evergreen.git;a=commit;h=686764a>
15:11 pinesol_green [evergreen|Mike Rylander] LP#1306753: Only look at holds that expire before 'today' - <http://git.evergreen-ils.org/?p=​Evergreen.git;a=commit;h=b1e53c1>
15:11 pinesol_green [evergreen|Kathy Lussier] Release notes entry for holds shelf expire change - <http://git.evergreen-ils.org/?p=​Evergreen.git;a=commit;h=30912a6>
15:11 bshum berick: Was just perusing bug 1308239 and thinking, with pre-cats all pointed at -1, there'd never be any title holds or whatnot that go loose and target a precat mistakenly.  So really it'd almost always be copy specific only that would trap on pre-cats.  In theory.
15:11 pinesol_green Launchpad bug 1308239 in Evergreen "Support targeting and fulfillment of precat copy holds (for ILL)" (affected: 2, heat: 10) [Wishlist,New] https://launchpad.net/bugs/1308239
15:12 bshum Just confirming that thinking, but pushing it in anyways :)
15:15 pinesol_green [evergreen|Bill Erickson] LP#1308239 Support pre-cat copy hold targeting - <http://git.evergreen-ils.org/?p=​Evergreen.git;a=commit;h=a1c8c3a>
15:15 pinesol_green [evergreen|Bill Erickson] LP#1308239 support holds fulfillment on precat copies - <http://git.evergreen-ils.org/?p=​Evergreen.git;a=commit;h=fb0366d>
15:15 berick bshum: exactly. it's not something that would happen on accident
15:15 berick bshum++
15:15 bshum berick++
15:15 Dyrcona bshum: I was gonna look at that one sooner or later. ;)
15:16 Dyrcona Right now, I'm trying to reinstall stuff that was simply removed by the upgrade to 14.04.
15:17 Dyrcona I have not yet had a good experience with the 14.04 Ubuntu upgrade. My recommendation is wipe out your machine and install fresh.
15:29 AaronZ-PLS joined #evergreen
15:31 pinesol_green [evergreen|Dan Scott] LP#1330784 Add a sitemap generator for Evergreen - <http://git.evergreen-ils.org/?p=​Evergreen.git;a=commit;h=8af7e42>
15:31 pinesol_green [evergreen|Dan Scott] LP# 1330784: Release notes for sitemap builder - <http://git.evergreen-ils.org/?p=​Evergreen.git;a=commit;h=f956df5>
15:32 dbs \o/
15:33 bshum dbs: Works so far, I just got it setup to cron and will watch it for any strangeness
15:33 bshum But pushed it in for good times
15:33 bshum dbs++
15:35 bshum dbs: So to verify something based on my read of the notes
15:35 bshum If I specify a run like sitemap_generator --prefix HEBRON --lib-shortname HEBRON that would make sitemaps for just that particular library right?
15:35 bshum And that might be more important for something like if we have lots of virtualhosts
15:36 bshum And getting each library mapped out individually?
15:36 dbs bshum: correctamundo -- because that's our situation
15:37 * dbs was thinking it would make sense to have --prefix value default to whatever --lib-shortname was, if a value was supplied, in the shower this morning
15:37 bshum dbs: That's kind of what I was just wondering too
15:37 bshum dbs: Whether it would make any sense to align prefix with other values
15:37 dbs or <--lib-shortname> + '_' at least ;)
15:37 bshum dbs: And all of those still live in the same web root though?
15:37 dbs yep
15:38 bshum Intriguing.
15:39 dbs you could get fancier and generate subdirectories if you really wanted "sitemapindex.xml" with no prefix. or even fancier with vhosts serving up different versions of the same file
15:39 dbs but why? :)
15:39 * bshum will ponder this futher and setup his crons better
15:39 bshum I did think about whether it'd reduce clutter to have all the sitemaps inside of a folder or something
15:39 bshum When you start having lots, I could see it getting quite busy
15:40 jeff until you hit a few tens of thousands, ext[2-4] isn't going to get too unhappy. ;-)
15:40 dbs yeah, i guess in which case you do the equivalent of "cd /openils/var/web ; mkdir sitemaps; cd sitemaps; sitemap_generator ..." in your cron
15:40 jeff now, hashed local jacket image override directories... that might start to make sense in some systems... ;-)
15:41 dbs bshum: you must be a librarian, worrying about those darned messy folders
15:43 mtate joined #evergreen
15:43 * bshum just really hates seeing long returns from "ls -alh" in places on his servers
15:43 bshum :D
15:43 * bshum scrolls up, up and up some more
15:47 pinesol_green [evergreen|Dan Scott] LP# 1337550 Remove AggregateOffer schema.org instance - <http://git.evergreen-ils.org/?p=​Evergreen.git;a=commit;h=3acadb6>
15:47 pinesol_green [evergreen|Dan Scott] LP# 1337550 remove schema.org itemOffered, add price property - <http://git.evergreen-ils.org/?p=​Evergreen.git;a=commit;h=e4ff6af>
15:49 eeevil bshum: no chance for https://bugs.launchpad.net/evergreen/+bug/1254918 right now, eh? (is there a sitka dev in the house that would like to officially sign off? jpringle says it's the bee's knees)
15:49 pinesol_green Launchpad bug 1254918 in Evergreen "rendering the fund drop-down in the line batch update controls can be slow" (affected: 6, heat: 30) [Medium,Confirmed]
15:50 bshum eeevil: I was literally just looking at that two minutes ago and wondering if I wanted to ask for their official signoff.
15:50 bshum eeevil: I wanted to try it on our systems too, but got irked by the c changes :D
15:50 eeevil "c is for speed. and also cookie"
15:51 bshum Damnit, and now I want cookies :D
15:52 bshum But yeah, the speed does sound very sweet indeed.
15:53 mtate joined #evergreen
15:53 pinesol_green [evergreen|Bill Erickson] LP#1334693 ./configure avoid osrf_config without core - <http://git.evergreen-ils.org/?p=​Evergreen.git;a=commit;h=879b94c>
15:54 eeevil oh, yay! I hate 1334693, too!
15:54 eeevil bshum++
15:59 ldw eeevil: I will signoff, I was talking with jpringle yesterday about that.  She is very impressed.
15:59 bshum Oops, just pushed it through ldw
16:00 ldw bshum: no worries, I can get back to other tickets :).
16:00 bshum But ldw++ and jpringle++ anyways, always good to hear good results from others
16:01 pinesol_green [evergreen|Mike Rylander] LP#1254918: Allow skiping of user-object perms - <http://git.evergreen-ils.org/?p=​Evergreen.git;a=commit;h=f9f4d18>
16:01 pinesol_green [evergreen|Bill Erickson] LP#1254918 limit ACQ batch update fund retrieval by perms - <http://git.evergreen-ils.org/?p=​Evergreen.git;a=commit;h=2986646>
16:07 RoganH joined #evergreen
16:07 bshum Bleh, to Business::Stripe
16:08 bshum Dyrcona++ # that is our perl problem on Ubuntu 14.04
16:08 Dyrcona I bet the force is missing in the trusty makefile or stripe is missing entirely. I'll have a peak.
16:08 bshum Stripe is there, but it's probably not forced
16:08 bshum I remember a bug for that in Jessie
16:08 bshum Probably use a similar solution for Trusty
16:09 Dyrcona Yep. Not under modules_force.
16:09 Dyrcona Anyone mind if I just push the fix?
16:10 bshum Dyrcona: Go for it
16:10 eeevil ldw: that's great to hear, thanks!
16:13 pinesol_green [evergreen|Jason Stephenson] Force the installation of Business::Stripe on Ubuntu Trusty. - <http://git.evergreen-ils.org/?p=​Evergreen.git;a=commit;h=f2bcfbf>
16:21 Dyrcona Well, it is working for me after a 14.04 upgrade, but it was not fun getting there.
16:34 bshum Calling 0885
16:36 tspindler left #evergreen
16:39 chatley joined #evergreen
16:39 pinesol_green [evergreen|hubert depesz lubaczewski] LP#1234845: Performance improvement to evergreen.ranked_volumes() database function. - <http://git.evergreen-ils.org/?p=​Evergreen.git;a=commit;h=6f32e8f>
16:39 pinesol_green [evergreen|Ben Shum] LP#1234845: Stamping upgrade script for improved evergreen.ranked_volumes() - <http://git.evergreen-ils.org/?p=​Evergreen.git;a=commit;h=76686de>
16:45 * dbs muses: we never added any sort of "Hey, your patron expiry date occurs before the normal due date for this item: alert or auto-truncate due date?" circ logic did we?
16:45 eeevil dbs: I don't think so ... IIRC, that was possible with the circ scripts, though!
16:45 * eeevil ducks
16:45 dbs we have the 'circ.patron_expires_soon_warning' OUS but that's not very useful when you have some classes of users who get 4-month loans
16:45 bshum dbs: That sounds weirdly familiar but maybe only in a "we talked about that once" sort of way.
16:46 dbs eeevil: hey, no worries, we're still using circ scripts
16:46 dbs YOU'LL PRY THEM FROM OUR COLD, DEAD  ***ACK***
16:46 eeevil srsly?
16:46 dbs Sadly, seriously.
16:47 eeevil other than what you just mentioned, are there features you need?
16:47 dbs Hell we're still running 2.4.something. Cobbler's children and all that.
16:47 dbs Nope.
16:47 eeevil ah, well, gotcha
16:47 bshum Don't worry dbs, you only have till someone actually writes the commits to remove them as per https://bugs.launchpad.net/evergreen/+bug/1312308
16:47 pinesol_green Launchpad bug 1312308 in Evergreen "time to remove script-based circ policies" (affected: 1, heat: 6) [Wishlist,Confirmed]
16:47 dbs bshum++
16:47 bshum Oh for fun
16:47 bshum https://bugs.launchpad.net/evergreen/+bug/1046420
16:47 pinesol_green Launchpad bug 1046420 in Evergreen "Wishlist: Cut off due dates so they don't extend past card expiration date" (affected: 3, heat: 24) [Wishlist,Triaged]
16:47 bshum Also came up in my search dbs!
16:47 bshum And there's code there
16:48 bshum jeffdavis++  # we shall rescue this code from the dark hells of LP
16:48 dbs YESSSSS!
16:49 * dbs targets it
16:49 bshum dbs++ # get yourself over to in-db!  :D
16:57 jeffdavis it's aliiiiiiiive
16:57 jeffdavis Someday I should get around to making that list of all the things I need to get around to doing.
16:57 jeffdavis Finishing old half-finished bugfixes and new features, for example.
17:01 bshum Hehe
17:01 bshum eeevil++ # debian defender ;)
17:01 bshum That's a fair clarification, I didn't quite word my part of that correctly.
17:01 bshum I should have said we only officially test Ubuntu with that particular version.
17:01 bshum But others are done as well.
17:03 eeevil bshum: :)
17:08 * dbs wades in with a hearty encouragement to use Fedora
17:08 eeevil hrm... we need to get a debian 7 buildbot host going, and upgrade the live tester ...
17:08 dbs (not)
17:09 bshum Haha
17:09 eeevil dbs: at least that still has a buildbot slave :(
17:09 bshum dbs++
17:13 mmorgan left #evergreen
17:20 pinesol_green Incoming from qatests: Test Success - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html>
17:29 bshum dbs: Ooh, just found http://stuff.coffeecode.net/2014/ll​d_preconference/search_engine_cse/ ... I will play through this one :)
17:33 akilsdonk_ joined #evergreen
17:40 sseng Question: anyone encountered this error when running osrf_control -l --stop-all? error is: Can't kill a non-numeric process ID at /openils/bin/osrf_control line 149.
17:47 jeffdavis sseng: I have not seen that before, but I am curious what's in /openils/var/run/opensrf/*.pid ?
17:48 jeffdavis i.e. does one or more of those files contain an error msg or something, rather than a process id?
17:49 Bmagic sseng: I have seen that error but it doesn't seem to matter for us
17:50 sseng jeffdavis: Bmagic : unfortunately i ran the osrf_control with the --kill-with-fire option.... so no longer have access to those .pids with the errors....the good news running the usual --stop_all no longer produce that error!
17:56 jeffdavis Seems likely that file perms/ownership were wrong on a pid file or the directory. osrf_control just does @pids = `cat $pid_file`; if cat gives an error like "permission denied" then @pids will contain the test of the error message.
17:56 jeffdavis Anyway, glad it's working now.
17:56 jeffdavis s/test/text/
17:57 sseng jeffdavis: yep, thanks a bunch, will look out for those in future!
18:36 sseng joined #evergreen
18:36 ktomita joined #evergreen
18:36 akilsdonk_ joined #evergreen
18:36 chatley joined #evergreen
18:36 tater joined #evergreen
18:36 AaronZ-PLS joined #evergreen
18:36 edoceo joined #evergreen
18:36 ldw joined #evergreen
18:36 hbrennan joined #evergreen
18:36 _bott_ joined #evergreen
18:36 jwoodard joined #evergreen
18:36 mtcarlson joined #evergreen
18:36 mnsri joined #evergreen
18:36 b_bonner joined #evergreen
18:36 tsbere joined #evergreen
18:36 adbowling-isl joined #evergreen
18:36 dbwells joined #evergreen
18:36 gsams joined #evergreen
18:36 pastebot joined #evergreen
18:36 eeevil joined #evergreen
18:36 ningalls joined #evergreen
18:36 RBecker joined #evergreen
18:36 paxed joined #evergreen
18:36 rangi joined #evergreen
18:36 pmurray_away joined #evergreen
18:36 jeffdavis joined #evergreen
18:36 berickm joined #evergreen
18:36 Silva joined #evergreen
18:36 riot joined #evergreen
18:36 mtj_ joined #evergreen
18:36 Bmagic joined #evergreen
18:36 dkyle joined #evergreen
18:36 Sato joined #evergreen
18:36 eby__ joined #evergreen
18:36 remingtron_ joined #evergreen
18:36 jventuro joined #evergreen
18:36 gmcharlt joined #evergreen
18:36 dbs joined #evergreen
18:36 jeff joined #evergreen
18:36 pinesol_green joined #evergreen
18:36 phasefx_ joined #evergreen
18:36 jcamins joined #evergreen
18:36 csharp joined #evergreen
18:36 Callender joined #evergreen
18:36 wjr_ joined #evergreen
18:36 shadowspar joined #evergreen
18:36 dreuther joined #evergreen
18:36 jeff_ joined #evergreen
18:36 phasefx joined #evergreen
18:36 graced joined #evergreen
18:36 bradl joined #evergreen
18:38 artunit joined #evergreen
18:41 dbs bshum: it's short but sweet
19:19 bshum dbs: for some reason Google seems to think our robots.txt is still a deny all, but we definitely changed that months ago
19:37 akilsdonk joined #evergreen
19:42 akilsdonk joined #evergreen
20:19 akilsdonk joined #evergreen
20:34 ldw joined #evergreen
21:06 dbs bshum: weird. http://acorn.biblio.org/robots.txt looks okay to me. Hmm.
21:06 dbs very similar to http://zed.concat.ca/robots.txt :)
21:30 artunit joined #evergreen
21:30 mnsri joined #evergreen
21:30 tsbere joined #evergreen
21:30 dbwells joined #evergreen
21:30 eeevil joined #evergreen
21:30 pmurray_away joined #evergreen
21:30 jeffdavis joined #evergreen
21:30 berickm joined #evergreen
21:30 csharp joined #evergreen
21:30 jcamins joined #evergreen
21:30 phasefx_ joined #evergreen
21:30 pinesol_green joined #evergreen
21:30 jeff joined #evergreen
21:58 rangi joined #evergreen
21:58 b_bonner joined #evergreen
21:58 Callender joined #evergreen
21:58 dbs joined #evergreen
21:58 eby__ joined #evergreen
21:58 adbowling-isl joined #evergreen
21:58 _bott_ joined #evergreen
21:58 edoceo joined #evergreen
21:58 AaronZ-PLS joined #evergreen
21:58 dreuther joined #evergreen
21:58 shadowspar joined #evergreen
21:58 wjr_ joined #evergreen
21:58 jventuro joined #evergreen
21:58 remingtron_ joined #evergreen
21:58 dkyle joined #evergreen
21:58 Bmagic joined #evergreen
21:58 riot joined #evergreen
21:58 RBecker joined #evergreen
21:58 ktomita joined #evergreen
21:58 sseng joined #evergreen
21:58 chatley joined #evergreen
21:58 ningalls joined #evergreen
22:03 bradl joined #evergreen
22:06 tater joined #evergreen
22:06 mtcarlson joined #evergreen
22:06 pastebot joined #evergreen
22:06 Sato joined #evergreen
22:06 gmcharlt joined #evergreen
22:06 jeff_ joined #evergreen
22:06 phasefx joined #evergreen
22:06 graced joined #evergreen
22:08 gsams joined #evergreen
22:08 ldw joined #evergreen
22:08 paxed joined #evergreen
22:08 mtj_ joined #evergreen
22:10 Silva joined #evergreen

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