Evergreen ILS Website

IRC log for #evergreen, 2015-05-04

| 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:08 sarabee joined #evergreen
05:09 pinesol_green Incoming from qatests: Test Success - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html>
07:42 ericar joined #evergreen
07:51 graced joined #evergreen
07:55 jboyer-isl joined #evergreen
07:56 rjackson_isl joined #evergreen
08:09 Newziky joined #evergreen
08:11 collum joined #evergreen
08:30 akilsdonk joined #evergreen
08:32 mrpeters joined #evergreen
08:38 mmorgan joined #evergreen
08:40 Shae joined #evergreen
08:45 Dyrcona joined #evergreen
08:56 Dyrcona And, today we build a new development VM and attempt to install the browser-based staff client.
08:56 dkyle1 `history
08:58 mrpeters morning guys -- i've talked to a few of you about being able to obtain information about the staff member that created a record and many have asked "why?" -- I got an answer, and I think it's a pretty fair one.
09:01 Dyrcona AFAIK, that information is only kept for bibliographic records.
09:02 mrpeters A library is finding that about 5% of their new patron records are being entered incorrectly (errors in permissions, typos, etc.) and they are trying to identify whether or not this is isolated to 1 or 2 staff members, or spread amongst all staff.  We have creator/editor information for bibs, I think for similar reasons, so I'm going to file a wishlist bug to modify the actor.usr schema to include this information.
09:02 mrpeters I should clarify -- i know that is not the ONLY reason that info is kept for bibs, but I'm sure it is one of them
09:04 mrpeters as for how to deal with upgrades, i would propose setting the global superuser (au.id=1) as the creator for all records when the upgrade is applied, and then going forward, record the actor.usr.id of the creating staff user
09:04 Dyrcona Yeah, put it in the bug. Doubt it would go in soon, though.
09:05 Newziky joined #evergreen
09:05 mrpeters yeah, probably not, and they are ok with that -- they realize it was just probably one of those things nobody ever brought up, but as things have evolved, it's become something that would be handy in the future
09:13 bshum Drycona: When you say I'm missing a sudo, what are you working from?
09:19 maryj joined #evergreen
09:20 Dyrcona http://evergreen-ils.org/~bshum/Ever​green-README.html#_optional_extra_st​eps_for_browser_based_staff_client
09:20 Dyrcona bshum: I was gonna ask you if there is a git branch for that.
09:21 bshum Ah, that thing. Okay, I think that there might be some lingering issue on that step.
09:21 Dyrcona Are those the best instructions available?
09:21 bshum There used to be a git branch somewhere for that, though I'm not 100% where right now.
09:22 bshum More or less, I based them on the README file in the webclient directory.
09:22 bshum I'll dig up the branch for you in a bit.
09:22 yboston joined #evergreen
09:24 bshum Hmm, I thought I made one but now I can't seem to locate it. I'll make a new branch for you.
09:26 Dyrcona One thing that isn't answered by any of the docs is do you do this before installing the rest of Evergreen, or can it be done after?
09:27 bshum It's supposed to be before you compile
09:27 bshum Otherwise the web client pages aren't in place before you do the configure/make steps
09:28 bshum And it doesn't automatically get moved into the installed places during make install
09:28 Dyrcona OK. That might explain my problems yesterday.
09:28 Dyrcona I'll give it another shot.
09:29 bshum Yeah, the position of the instruction in my doc is intentionally if not explicitly defined.
09:29 Dyrcona My VM is almost done being created.
09:29 Dyrcona Oh. It finished 6 minutes ago. Another window was covering the prompt in the terminal. ;)
09:30 bshum You might be right about that npm install needing a sudo on it. I vaguely recall doing something similar at one point.
09:30 bshum Though I'm unsure if maybe there were weird permission issue or something.
09:31 Dyrcona Well, I got several errors about stuff not being installed/not able to be opened without the sudo.
09:31 Dyrcona With sudo, it just worked.
09:31 bshum You testing with Ubuntu 12.04 or 14.04?
09:37 bshum Alright, so I can't find the branch anywhere, so I must have just been modifying a local copy Evergreen-README on lupin directly. We can diff those changes against master and get a branch started though.
09:42 RoganH joined #evergreen
09:54 Dyrcona 14.04
09:55 bshum Dyrcona: I pushed a collab branch with the changes I started to http://git.evergreen-ils.org/?p=work​ing/Evergreen.git;a=shortlog;h=refs/​heads/collab/bshum/README-webclient
10:00 mllewellyn joined #evergreen
10:01 tsbere_ joined #evergreen
10:05 Dyrcona If I'm using OpenSRF from master is there anything that I need to do for the browser-based staff client in OpenSRF?
10:06 bshum Dyrcona: I believe the websocket steps were incorporated into the README for OpenSRF master/2.4 series
10:06 bshum So you should be fine there as long as that's all setup.
10:07 Dyrcona Do you need websockets if I'm not using hatch? I assume yes.
10:07 bshum gmcharlt was going to add some samples later on for proxy to get it to run websockets off more traditional ports, or something.
10:07 bshum Yes, you need websockets configured or else you won't even be able to log into it.
10:07 Dyrcona OK. Thanks.
10:31 Stompro joined #evergreen
10:59 Stompro joined #evergreen
11:10 Shirleyh joined #evergreen
11:18 Shirleyh_ joined #evergreen
11:30 jjk joined #evergreen
11:32 Shirleyh joined #evergreen
11:42 jjk Good morning
11:42 jeff jjk: good morning!
11:43 jjk I'm attempting to upgrade an older 2.3 install to the current version but have run into issues with the database schema updates.  I'm hoping some folks here can point me in the right direction.
11:45 jjk I have a test database that started at 2.3.5 and I've successfully run the schema updates all the way up to 2.3.12.
11:47 jjk When trying to upgrade the schema using 2.3-2.4.0-upgrade-db.sql I quickly receive the following errors:
11:47 jjk psql:version-upgrade/2.3-2.4.0-upgrade-db.sql:96: NOTICE:  extension "tsearch2" already exists, skipping
11:47 jjk psql:version-upgrade/2.3-2.4.0-upgrade-db.sql:98: ERROR:  cannot drop extension tsearch2 because other objects depend on it
11:48 jjk I've not found much in the way of similar issues.
11:53 bshum jjk: So that sounds like you have something custom in your database that relies on tsearch2 extension
11:54 bshum I found something like that when we upgraded as well, some locally created views for reporting had used that extension and needed to be rewritten
11:55 * bshum upgraded forever ago and doesn't remember how he ultimately identified all the things that used that extension.
11:57 jjk bshum: Thanks.  I'll look at the reports.
11:58 TaraC joined #evergreen
12:01 bshum jjk: Out of curiosity, what version of PostgreSQL are you using for your tests?
12:01 bshum (i.e. did you also test upgrading your postgresql installation to newer versions 9.1+)
12:02 bshum And you might find it interesting
12:02 bshum To try the drop extension directly
12:02 bshum And see if it spits back what is still depending on it
12:03 bshum Hmm
12:03 bshum csharp: Did we archive the old evergreen-admin mailing list?
12:04 bshum csharp: Nevermind, found what I was looking for
12:04 bshum jjk: You might see some value in discussion from this mailing list entry: http://list.evergreen-ils.org/pipermai​l/evergreen-admin/2014-May/000086.html
12:05 jjk bshum: I'm running 9.1 on Debian, specifically 9.1.14-0+deb7u1
12:05 bshum jjk: Based on what they say there, I would check to make sure the search_path is set right, and then see if there's any "DETAIL" that comes up after the "ERROR" part when you try to drop the extension.
12:05 bshum ~search_path
12:05 pinesol_green After restoring a database, make sure to reset the search_path accordingly with something like: alter database unpredicable_haxxors_go_away set search_path = evergreen, public, pg_catalog;
12:08 jjk Thanks, I'll look these.
12:08 bshum jjk: As you work upwards in versions, I want to point you towards http://docs.evergreen-ils.org/2.7/_upgr​ade_the_evergreen_database_schema.html
12:08 bshum Which describes the path you'll want from 2.5+
12:09 bshum Specifically, you might want to skip over certain numbered scripts to avoid conflicts in the upgrade scripts.
12:09 bshum Due to x.y.z releases coming out at different times.
12:10 bshum i.e. skip 2.5.3-2.5.4 (if you're going to go past 2.5 towards 2.6), etc.
12:10 bshum You're not there yet.  But you'll get there, sometime.  And that can be a weird little stumbler.
12:10 jjk Does this apply for just 2.5 or 2.6 and 2.7 branches too?
12:10 * jeff somewhat idly wonders if he should expect to be able to make it from gate to shuttle in time to make the noon departure, or if he should plan on the 2:30
12:11 bshum jjk: It applies to everything.  I'm not sure how far along 2.3 went after 2.4 came along, etc.
12:11 bshum So you might find stuff in later version upgrade scripts that have already happened previously and might not successfully apply or whatnots.
12:12 bshum So you'll want to follow the path as best as you can if you want to cut down on the amount of manual intervention you'll need.
12:12 jeff hah! wondered why there were two calendar entries for my flights. one i created by hand, the other google created automatically.
12:12 bshum I'm unsure how comfortable you are with SQL stuffs.
12:12 bshum But if you love SQL, you'll enjoy it.  Or learn to enjoy it?  :\
12:13 csharp jeff: you might ask Buzzy or Brent about it - I'm in a similar spot with the 5:00 (final) shuttle
12:13 csharp they made it sound like they'd be able to hold it for me
12:13 jeff csharp: youch -- 9 minutes
12:13 csharp (arriving at 4:51 pm)
12:13 csharp yeah
12:14 * csharp doesn't have a very good backup plan :-/
12:14 Dyrcona csharp: Tuesday? You hang around until midnight when bshum and I get there.
12:14 csharp ha!
12:15 csharp if you see me asleep on a couch, please wake me up and drag me along ;-)
12:15 bshum Heh
12:16 jjk bshum: clear as mud!  It's not clear to me what is meant by 'run all incremental scripts' if for example 2.4.0-2.4.1 is not an incremental script.
12:17 bshum jjk: I think that's exactly what it means.  (And that the doc writer got lazy and meant to say, run 2.4.0-2.4.1, 2.4.1-2.4.2, 2.4.2-2.4.3
12:17 bshum Which is three incremental scripts
12:17 bshum *three separate
12:18 kmlussier csharp: I'm arriving at 5:15, just after the last shuttle. I've hitched a ride with gmcharlt later in the night. I don't know if he has more spots, but you might want to check.
12:18 jjk bshum: That's what I thought.  What is meant by 'additional scripts'?
12:18 Dyrcona Speaking of upgrade scripts, I have plans to make db_upgrade.pl smarter.
12:18 jeff The interesting one will be the return for me -- looks like I'll have 5 hours or so to burn.
12:18 * kmlussier has noticed that csharp and I have very similar flight times next week.
12:19 wjr joined #evergreen
12:19 Dyrcona db_upgrade.pl is available here if you're scratching your head: http://git.mvlcstaff.org/?p=jason/evergre​en_utilities.git;a=tree;f=scripts;h=05bdd​b674e4d91760392fc31333ef1104a055648;hb=5e​c82e38e8465bafc56fdb19961b1b78c49f5075
12:20 bshum jjk: "additional scripts?"
12:20 bshum I'm not sure I know what you mean by that.
12:20 jjk Dyrcona: Is that directed at me?  I looked at db_upgrade.pl breifly but didn't see any mention in the docs and so chickened out.
12:21 jjk bshum: The docs read: 'Note that you do not want to run additional 2.5 scripts to upgrade to the newest version of 2.5'
12:21 bshum jjk: Right... so...
12:21 Dyrcona jjk: No, it's directed in general. db_upgrade.pl won't help you right now, but the changes I have in mind might help you in the future.
12:21 jjk got it.
12:21 bshum jjk: Gotcha now.  So, let's say there were other scripts like, 2.5.3-2.5.4, 2.5.4-2.5.5
12:22 bshum If you ran those, then the script for 2.5.3-2.6.0 (major upgrade) may not (read, *will not*) function seamlessly.
12:22 bshum Cause your database would be at the wrong state
12:22 bshum And you would end up having to edit the major upgrade script to remove stuff that might have already been applied during one of the other incremental scripts.
12:23 bshum Things of that nature.
12:25 jjk I think I understand.  Once I get over the 2.3-2.4 hurdle I'll compose a list of sql scripts that I believe should be run.  Can I post the URL to that file here and get a sanity check?
12:26 csharp kmlussier: thanks - I'll check
12:26 bshum jjk: You can always ask, but I don't promise I'll personally answer if I'm not around later.  (though I'm sure others might chime in, if you're patient)
12:26 bshum :)
12:27 bshum Upgrading from older versions can be interesting.  And that's where you discover all the quirks.
12:27 bshum jjk: Out of curiousity, who are you upgrading?
12:28 csharp kmlussier: looks like gmcharlt's car is full - I'll try to get some assurance that the 5:00 shuttle doesn't leave without me ;-)
12:29 kmlussier joined #evergreen
12:29 mceraso joined #evergreen
12:29 bshum joined #evergreen
12:29 bshum kmlussier: Sorry about that, I think my linode's quasslcore just updated...
12:29 bshum And bumped us all around a bit
12:30 Dyrcona Looks like it.
12:30 kmlussier bshum: Oh, that was you? I thought our wireless went out.
12:30 bshum Yeah I was doing an update and didn't notice it said "quassalcore" amongst the packages being updated.
12:30 bshum Sorry for the interruption there.
12:30 csharp @blame updates
12:30 pinesol_green csharp: updates caused the white screen of death!
12:30 bshum Carry on
12:30 jihpringle joined #evergreen
12:31 jboyer-isl bshum: That's almost as fun as doing a remote Windows Update and noticing the network drivers are in there. It was a very tense couple of minutes before the remote desktop was available again. :D
12:32 bshum jboyer-isl: I've been there before... scary stuff.
12:32 bshum I feel that way every time I have to change the IP address for a system.
12:32 bshum Where are you and why aren't you online yet?
12:33 csharp jboyer-isl: whenever I hear the words "remote Windows Update", I'm reminded of this: http://thenextweb.com/shareables/2014/05/1​6/emory-university-server-accidentally-sen​ds-reformat-request-windows-pcs-including/
12:34 jeff we live in a weird world.
12:34 jeff i just searched google for "quassel sasl"
12:35 * csharp watches his Helpdesk ticket queue grow as he tries to catch up on paperwork neglected during last week's PINES meetings
12:44 bshum berick: I'm going through master's server_upgrade doc and getting it updated to reflect path up towards 2.8.1
12:44 kmlussier OK, the group working on Evergreen outreach met today and talked about adding a contact email to the handouts we'll be distributing at conferences. I know we already have a feedback@evergreen-ils.org address, but we were thinking info@evergreen-ils.org might make more sense for the people we would be reaching at conferences.
12:44 kmlussier Is that something we could have set up?
12:44 bshum I'll push that out in a bit and we can get the docs server rebuilt overnight to put up a proper link for 2.8 upgrade path later tomorrow.
12:45 * kmlussier isn't sure if that's a csharp request or a gmcharlt request.
12:48 gmcharlt kmlussier: looking
12:49 jeff_ joined #evergreen
12:50 * jeff_ waves
12:50 gmcharlt kmlussier: there's no info@ reflector, but I can easily create it given a set of email addresses
12:51 gmcharlt or it could be mapped to the set underlying list as feedback@
12:52 kmlussier Awesome! I think I like the idea of mapping it with the feedback address because it seems like they serve similar purposes. It really is just a matter of semantics.
12:52 kmlussier Who is on the feedback address?
12:52 * kmlussier waves to jeff_
12:53 csharp kmlussier: me, dbs and phasefx
12:53 csharp it's unfortunately 99.4% spam
12:53 csharp which reminds me
12:53 kmlussier ugh
12:53 kmlussier @hate spam
12:53 pinesol_green kmlussier: The operation succeeded.  kmlussier hates spam.
12:53 csharp note to self: set up spam filtering somewhere
12:54 gmcharlt csharp: kmlussier: also eeevil
12:54 csharp oh? good
12:55 csharp kmlussier: the other 0.6% are questions that would be better asked on Open-ILS-General (or even of specific sites' Helpdesks)
12:55 gmcharlt coins, sides, two
12:56 gmcharlt kmlussier: in fact, there'd be an argument to be made that info@ should be publicized *only* on printed materials
12:56 kmlussier csharp: Yeah, I think I heard that was the case. But if we were distributing the address in handouts at conference, it might get more use.
12:56 kmlussier gmcharlt: So that we could have an informational address that doesn't receive so much spam?
12:56 gmcharlt kmlussier: right
12:57 kmlussier gmcharlt: In that case, it might be better to separate it out from the feedback address, right?
12:57 csharp I think filtering is the only reasonable approach to the spam issue
12:57 csharp any address that is public anywhere is subject to that
12:57 gmcharlt and conveniently, open-ils-general already has filtering :)
12:57 csharp if'n y'all want, I can get awitter on the case ;-)
12:58 csharp he's a seasoned veteran of such things
12:58 Dyrcona Even ones that aren't public, you should see all of the unknown address bounces in my logs. :)
12:58 jeff info@ is going to get spam even if it's only on printed materials.
12:58 kmlussier Good point
12:58 csharp I'm pretty sure list.evergreen-ils.org has filtering on it too
13:01 pinesol_green [evergreen|Ben Shum] Docs: Change references to release 2.8.1 for server upgrade - <http://git.evergreen-ils.org/?p=​Evergreen.git;a=commit;h=dedc2dc>
13:05 kmlussier csharp: Sure, why not? Even without the info question, it sounds like it would benefit the people on feedback. :)
13:10 berick bshum++ # i've never actually looked at that doc
13:10 bshum berick: I started watching it after Stompro gave us all these patches for it.  And now I just try to keep it going.
13:11 bshum I'm editing up the various pages on the wordpress site too, to move things onto the "more staff clients" downloads page, and get rid of all the 2.5 stuff and put it onto the code museum page.
13:11 bshum Lots of editing.
13:14 bshum I suppose I should copy all the 2.6 stuff to the museum too in preparation for that going away.
13:14 bshum Since I'm editing anyways
13:30 bshum I'm kicking OpenSRF 2.2 off the screen from http://evergreen-ils.org/opensrf-downloads/  No currently supported Evergreen target it, so we can safely remove it.
13:41 Stompro bshum++, I was just thinking of working on the upgrade docs for 2.8, thanks.
13:42 bshum I'm spinning up a Jessie image to take a look over all the stuff you said was broken
13:45 Stompro Thanks, let me know if you see any issues with the patches that you would like me to look at.
13:46 bshum Stompro++ # I'm sure they'll help
13:56 buzzy joined #evergreen
14:08 gmcharlt kmlussier: ok, info@ now exists, is directed towards feedback@, and has better filtering
14:08 gmcharlt also, you're now subscribed to it
14:08 kmlussier Wow! That was fast. Thanks gmcharlt!
14:08 kmlussier gmcharlt++
14:19 jeffdavis What's the status of NCIPServer?
14:22 kmlussier jeffdavis: We have it in testing now to use with AutoGraphics.
14:22 jeffdavis kmlussier: that's excellent, thank you
14:24 Dyrcona jeffdavis: You can't use the master branch with Evergreen at the moment.
14:24 Dyrcona rangi or someone (me?) has to do some integration. I changed the interfaces a good bit.
14:25 kmlussier Dyrcona: I was just looking for that. Is the Evergreen side of it available somewhere else?
14:25 Dyrcona It's in the better_abstraction working branch.
14:26 Dyrcona http://git.evergreen-ils.org/?p=worki​ng/NCIPServer.git;a=shortlog;h=refs/h​eads/user/dyrcona/better_abstraction
14:27 Dyrcona magnus over in #koha on oftc.net has apparently made his own branch for more internationalization or something to do with how NCIP is being used in Norway.
14:27 Dyrcona his nick is magnuse
14:27 jeffdavis FWIW we're not planning to use it at the moment, I'm just anticipating some questions about third-party integration with EG.
14:27 bshum Oy, the new ejabberd.yml config file layout is freaking me out.
14:28 Dyrcona jeffdavis: Lovely thing about NCIP, you need a new implementation for just about every vendor.
14:28 bshum Screwing with muscle memory for my OpenSRF installs.
14:29 Dyrcona And sometimes different products from the same vendor.
14:31 kitteh_ joined #evergreen
14:31 jeffdavis Dyrcona: ah yes, "standards" that are actually their own special case of https://xkcd.com/927/ -- good times!
14:31 bshum Haha, the hover is funny
14:32 bshum Stompro++ # tested the change for OpenSRF instructions for Ejabberd for Debian Jessie and they look good.  I'll sign and push that on for a future OpenSRF 2.4.1 release.
14:33 Dyrcona Well, I don't even really consider NCIP to be a standard myself. It's list of features that you can implement.
14:34 Dyrcona And every vendor seems to pick their own way to do things, and too many messages are similar, but different.
14:34 Dyrcona So, yeah, we need an actual standard.
14:35 Dyrcona Where there's one way to do a given task.
14:35 bshum Stompro: Well, after I fix up some asciidoc weirdness in the formatting.
14:35 Dyrcona If TCP/IP were standardized like most library standards, we'd all be using AOL/CompuServe.
14:38 jeffdavis heh
14:38 jeffdavis Someone should add that to pinesol_green's quote repository.
14:43 berick @quote add "<Dyrcona> If TCP/IP were standardized like most library standards, we'd all be using AOL/CompuServe."
14:43 pinesol_green berick: The operation succeeded.  Quote #114 added.
14:43 berick @quote get 114
14:43 pinesol_green berick: Quote #114: "<Dyrcona> If TCP/IP were standardized like most library standards, we'd all be using AOL/CompuServe." (added by berick at 02:43 PM, May 04, 2015)
14:43 berick can't believe that worked the first time
14:46 jeffdavis berick++
14:46 bshum Bleh, asciidoc syntax can be annoying when you don't use it regularly :(
14:47 Dyrcona heh to berick and to bshum. :)
14:47 * Dyrcona wonders if asciidoc really has syntax. :)
15:21 dkyle1 left #evergreen
15:22 * bshum has wrestled with asciidoc and is losing :(
15:24 Bmagic if I wanted to manually change a password in the database, I need to sha1? md5?  update actor.usr set passwd=digest('password', 'sha1') where id=926  ??
15:24 tsbere Bmagic: None of the above?
15:24 bshum Bmagic: Nah, there's a DB function that'll do that for you
15:24 tsbere Bmagic: set passwd = 'new password' ;)
15:24 Bmagic oh, lol
15:24 bshum Bmagic: You can just do UPDATE actor.usr SET passwd = 'something' WHERE id = sillyuser;
15:24 Stompro bshum, it took me a while to add the second example to the docs also... I thought I compiled it and tested how it looked, did you not like how it looked or did it break when you tried it.
15:24 bshum and the function will hash it out for you
15:25 Bmagic great! that worked
15:25 bshum Stompro: I was just trying to see if I could make it more consistent looking with the rest of the styling.
15:25 bshum Stompro: Your approach isn't wrong, just different.
15:25 bshum For myself, I might put the OS ahead of the Ejabberd version in the subheadings
15:26 bshum So like "(Debian Jessie) Ejabberd 13.x and 14.x" instead of "Ejabberd 13.x and 14.x, Debian Jessie"
15:26 bshum That seems to be how everything else is done.
15:26 bshum Then when I tried to make it the bold blue text with the .inlead, then I got weird generation errors with the bullets under each section.
15:27 bshum Still playing with it more
15:29 Stompro I wasn't quite sure with all the numbered steps how to best add in the different options, while continuing the numbering after those steps.  I think I remember that trying to use ".section" headings broke all the numbering afterwards.
15:29 bshum Yep, that's what I'm seeing too.
15:29 bshum I'm wondering next if we have to number it at all, and maybe we can get away with bullets instead.
15:33 Stompro I don't have a strong opinion on it, but don't the docs generally use numbed steps for most things.
15:34 Dyrcona Can you get "a" and "b" on the numbers? like 4.1a 4.1b
15:34 Dyrcona Or maybe something like X.Y option A X.Y option B
15:35 Dyrcona But, seriously if there are options, don't go past C, 'cause people just get confused at that point.
15:44 mmorgan I'm puzzling over some strange catalog searches in our logs. Wonder if anyone has seen searches similar to the following ...
15:44 pastebot "mmorgan" at 64.57.241.14 pasted "Curious catalog search" (217 lines) at http://paste.evergreen-ils.org/50
15:45 mmorgan The searches have a random string of characters for author, title, etc, and have multiple languages and filter groups selected.
15:46 bshum Sounds like a very entertaining advanced search.
15:46 mmorgan I see a fair number of similar searches in the logs.
15:46 * bshum doesn't know anything, is just musing
15:46 mmorgan Heh. "Entertaining" for sure ;-)
15:47 mmorgan Had to kill about ten of these today.
15:47 bmills joined #evergreen
15:49 bshum That join against a facet looks interesting.
15:49 mmorgan They all seem to limit to "before(1012)"
15:54 kmlussier mmorgan: Before 1012, eh?
15:55 mmorgan Yeah. Don't *think* we have anything that old. ;-)
15:56 kmlussier mmorgan: Given that it's before the Pilgrims landed, I would think not. :)
15:56 bshum Well it is a geographic search for "asia" so, I dunno.....
15:56 bshum subject|geographic[Asia]
15:56 bshum Whee
15:58 mmorgan And some of them don't seem to have any 'real' search terms in them at all. Just the random characters and the limiters.
15:58 bshum Yeah, (-"OQcYe" && title:-"2scg4") && author:-"V3oH2") doesn't seem quite... real looking at all.
15:59 kmlussier They look like passwords
15:59 tsbere Or some of the random negations someone might use to do a "not cached' search
16:00 bshum mmorgan: Have you tried tracing back into apache what leads to these queries?
16:00 kmlussier Ah, that's true. I do thsoe sometimes. But usually you have a real keyword with those negations.
16:01 bshum kmlussier: Well, keyword: subject|geographic[Asia] seems real to me.
16:01 bshum If a bit broad.
16:02 * kmlussier isn't looking at the queries closely enough.
16:04 mmorgan bshum: How would I go about that?
16:04 bshum Well I would have gone with time.
16:05 bshum Like, before the timestamp of the DB query, what happens in apache, osrfsys, etc.
16:05 bshum And slowly try recontructing the actual thing that made that weird query
16:06 mmorgan Ok, I have done some poking around, but haven't been able to pin anything down.
16:06 mmorgan Our logs are very busy :)
16:08 mmorgan And I'm not sure of all the ways to follow the threads of what's going on. :-(
16:11 kmlussier Isn't there a conference presentation next week on reading Evergreen logs?
16:12 Newziky left #evergreen
16:12 bshum kmlussier: Yeah, csharp is giving one.
16:12 kmlussier mmorgan:  I'll try sitting in on that one so that I can bring back lots of knowledge for you. :)
16:12 kmlussier I hope it isn't up against one of my programs.
16:13 mmorgan kmlussier: Thanks!
16:15 mmorgan I'm sure the presentation will be posted, too, afterward for posterity :)
16:25 mrpeters is an  INSERT INTO config.metabib_field, followed by a reingest of those records, still the fastest way to add a particular marc tag to a keyword search?
16:43 * mrpeters takes note that "label" is also a new required field so that magic spell is a little dated
16:44 mmorgan mrpeters: Not an expert, but I don't know of any other way to do that.
16:44 Dyrcona I was going to say that I think it is the only way to do it, but got sidetracked.
16:45 mrpeters mmorgan: i didnt think so either, but so much awesome stuff has been done with the in-staff client configuration menus that i wasnt sure
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:16 pinesol_green [opensrf|Ben Shum] Docs: Keep all source syntax consistent in README - <http://git.evergreen-ils.org/?p​=OpenSRF.git;a=commit;h=ef80e4c>
17:16 pinesol_green [opensrf|Ben Shum] Docs: Add [source, bash] to code blocks that were not defined in README - <http://git.evergreen-ils.org/?p​=OpenSRF.git;a=commit;h=52b6eca>
17:16 pinesol_green [opensrf|Ben Shum] Docs: Emphasize variables and paths consistently in README - <http://git.evergreen-ils.org/?p​=OpenSRF.git;a=commit;h=86e6d84>
17:16 pinesol_green [opensrf|Josh Stompro] LP#1445503 - Updated Ejabberd setup steps for Ejabberd 14.x for Debian Jessie - <http://git.evergreen-ils.org/?p​=OpenSRF.git;a=commit;h=e421bb3>
17:18 pinesol_green [opensrf|Ben Shum] Docs: Fix mailing list link for help in README - <http://git.evergreen-ils.org/?p​=OpenSRF.git;a=commit;h=966fb05>
17:18 bshum I give up on the asciidoc syntax for now.  I will slay that eventually though.
17:18 mmorgan left #evergreen
17:21 bshum So, for the Evergreen bugs targeting issues with Debian Jessie
17:21 bshum I'm thinking to backport those to rel_2_8 and rel_2_7
17:22 bshum Since both of those versions contained support for Jessie as a target.
17:22 bshum And likely require those fixes to work successfully.
17:23 Stompro That makes sense to me.
17:27 * bshum is going to create new milestones
17:28 pinesol_green [evergreen|Josh Stompro] LP#1445150 Update Debian Jessie depend make to PG9.4 - <http://git.evergreen-ils.org/?p=​Evergreen.git;a=commit;h=7cc3ee6>
17:29 bshum dbwells: I'm not going to add a 2.6 milestone unless we determine more work is to be done for that series.
17:29 dbwells bshum: sounds good
17:33 * bshum shakes fist at Launchpad for timing out
17:34 jeff @blame launchpad
17:34 pinesol_green jeff: launchpad wants the TRUTH?! launchpad CAN'T HANDLE THE TRUTH!!
17:37 jeff_ No results for search _TRUTH_
17:38 pinesol_green [evergreen|Josh Stompro] LP#1447195 Updates for Debian Jessie in README - <http://git.evergreen-ils.org/?p=​Evergreen.git;a=commit;h=3200c8d>
17:44 pinesol_green [evergreen|Josh Stompro] LP#1445187 - Force disable of deflate - <http://git.evergreen-ils.org/?p=​Evergreen.git;a=commit;h=b949202>
17:44 pinesol_green [evergreen|Josh Stompro] LP#1362260 - Email::Sender/libemail-send-perl change in Jessie - <http://git.evergreen-ils.org/?p=​Evergreen.git;a=commit;h=ad879d4>
17:50 pinesol_green [evergreen|Josh Stompro] LP#1445182 Changed Debian Jessie dependency install to use packages for dbi dbd-pgsql. - <http://git.evergreen-ils.org/?p=​Evergreen.git;a=commit;h=d5089b7>
17:54 bshum Stompro++ # I pushed ahead everything and I seem to be well on my way towards a happy Jessie test server.
18:08 bshum Hmm
18:10 bshum Looks like we'll need to create a file for 000.english.pg94.fts-config.sql
18:10 bshum In order for PG 9.4 to be used when creating the database
18:11 bshum To test, I've just copied the 93 one to be named 94 and seeing how that goes.
18:25 bshum I appended my findings to the bug
18:30 bshum Stompro: I set https://bugs.launchpad.net/evergreen/+bug/1445150 back to Triaged while we test the last little bit I think we need to create a working database on PG 9.4 using the scripts.
18:30 pinesol_green Launchpad bug 1445150 in Evergreen 2.7 "Debian Jessie includes Postgresql 9.4 - update software dependency makefile" (affected: 1, heat: 6) [Medium,Triaged]
18:31 bshum When we get time, someone else should check that initial working branch, and then make any special adjustments.
18:31 bshum Otherwise, as far as I can see, I have a functional Evergreen install on Debian 8.0 Jessie
18:32 * bshum shuts down his VMs and goes to find a quiet (and cooler) room to space out in
19:03 * kmlussier wonders how jcamins packs cookies when he goes to conferences.
19:05 dcook kmlussier: The last cookies I had from jcamins at a conference were a bit squished... but yummy!
19:06 dcook Oh man... I forgot that it's spring/summer in North America...
19:27 kmlussier dcook: The calendar says it's spring, but I don't think the weather has been paying attention to the calendar.
19:27 kmlussier Although the last few days have been quite nice.
19:28 dcook Yeah, it's supposed to be autumn/winter here, but I think it's supposed to be something like 26 today
19:28 dcook This has to be one of the weirder years I've been in Oz...
19:42 jonadab Where I come from, 26 is a nice brisk fall day.  (Granted, that's 26 F.)
19:42 dcook I was waiting for that ;)
19:44 kmlussier Heh
19:45 jonadab Happy to oblige.
19:51 sarabee joined #evergreen
20:03 jcamins kmlussier: how far is the conference?
20:03 kmlussier jcamins: All the way across the country. Hood River, Oregon
20:03 jcamins And how many cookies?
20:03 jcamins Hm.
20:04 kmlussier I don't know how many yet. I'm thinking I may make bshum and his crew get theirs at another time. Since they aren't that far away from me.
20:04 kmlussier I offered to make them for Evergreen sites that partnered with us on development projects.
20:05 kmlussier The conference seemed so far away back then.
20:05 bshum kmlussier: So in other words I'll probably never get cookies
20:05 jcamins Are you checking any luggage?
20:05 kmlussier bshum: Of course you'll get them!
20:05 kmlussier Yes, I was planning to pack it in the checked luggage
20:05 kmlussier I didn't know if I could get them through security.
20:05 kmlussier How many do you usually travel with?
20:06 kmlussier bshum: When you get yours, they probably won't be squished.
20:06 jcamins I'd probably bring 4-5 takeout containers with cookies, then.
20:06 kmlussier What kind of takeout containers do you use?
20:06 jcamins The cookies dcook had were squished because I wasn't checking a suitcase, so I put them in ziploc bags, the better to fit them in my single carry-on.
20:06 kmlussier Ah.
20:06 jcamins My favorite are the rectangular Chinese ones.
20:07 bshum I had those cookies, didn't I?
20:07 jcamins *The cookies dcook and bshum had...
20:08 jcamins Of course, if you really need to bring a *ton* your best bet is fudge.
20:08 jcamins Though you'll spend hours wrapping it.
20:09 kmlussier Fudge is yummy.
20:09 kmlussier But I haven't made it in years.
20:10 jcamins I make cheating fudge.
20:11 kmlussier I don't really need to bring that many. There's PINES, COOL, and rfrasur's library. Since I've already decided that Bibliomation can wait.
20:11 jcamins Yeah, true. PINES is really small.
20:11 * dcook is getting hungry now but it's only 10:11am...
20:11 kmlussier Yeah, that's what people always say when they talk about PINES. It's so small!
20:11 * dcook needs to figure out when Aussies take tea...
20:12 jcamins dcook: 10, 11...
20:12 jcamins Oh, hey, it's 10 11, time for tea!
20:12 dcook hehe
20:13 dcook I could actually really go for some hummus about now...
20:15 jcamins I should eat some dinner...
20:15 jcamins kmlussier: isn't it a bit late for you?
20:15 kmlussier Yeah, I'm suffering the consequences of my procrastination.
20:16 kmlussier I have a presentation to deliver at 8:30 a.m. tomorrow.
20:16 bshum Can you fit chocolate in your presentation
20:16 bshum ?
20:16 bshum I think that always makes things better.
20:17 kmlussier Chocolate at 8:30 a.m.?
20:17 bshum True, might be too early for most.
20:19 * bshum might just be thinking about chocolate cause he wants some right now.
20:21 jcamins kmlussier: sounds good to me!
20:22 jonadab Is there ever a wrong time of day for chocolate?
20:22 jonadab 8:30am is a good time of day for hot chocolate.
20:23 jcamins jonadab: any kind of chocolate, really.
20:29 jeff_ Hrm. I don't think quasseldroid is what I'm looking for.
20:38 jeff theae aren't the droids you're looking for?
21:55 bmills joined #evergreen
22:21 sarabee joined #evergreen
23:01 book` joined #evergreen
23:22 sarabee joined #evergreen
23:23 book` joined #evergreen
23:49 sarabee joined #evergreen

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