Evergreen ILS Website

IRC log for #evergreen, 2014-10-07

| 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
03:11 jventuro joined #evergreen
05:17 pinesol_green Incoming from qatests: Test Success - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html>
05:41 sseng_ joined #evergreen
07:06 Sato joined #evergreen
07:32 rjackson-isl joined #evergreen
07:48 kmlussier joined #evergreen
08:01 mtate joined #evergreen
08:01 eeevil joined #evergreen
08:02 phasefx joined #evergreen
08:02 Callender joined #evergreen
08:03 graced joined #evergreen
08:09 _bott_ joined #evergreen
08:09 _bott_ left #evergreen
08:09 _bott_ joined #evergreen
08:27 mrpeters joined #evergreen
08:28 tspindler joined #evergreen
08:33 kmlussier Good morning!
08:35 tspindler @coffee kmlussier
08:35 * pinesol_green brews and pours a cup of Ethiopia Yirgacheffe Koke, and sends it sliding down the bar to kmlussier
08:35 kmlussier tspindler: Thanks! I needed that. We're out of coffee this morning.
08:36 tspindler kmlussier: prices are going up apparently, drought in brazil
08:37 * kmlussier is trying to make do with tea.
08:41 kmlussier @love new edit links in the catalog
08:41 pinesol_green kmlussier: The operation succeeded.  kmlussier loves new edit links in the catalog.
08:42 mmorgan joined #evergreen
08:50 ericar joined #evergreen
08:50 jwoodard joined #evergreen
08:52 DPearl left #evergreen
09:06 Dyrcona joined #evergreen
09:08 collum joined #evergreen
09:12 Sato joined #evergreen
09:18 kmlussier eeevil: The working branch with all column picker options that you mentioned in your e-mail last week: do you know if that's loaded on webby right now?
09:18 mrpeters kmlussier: what can you edit with those links?  i haven't been following that
09:19 mrpeters are they just for staff, or for patrons as well to make corrections/contributions?
09:19 kmlussier mrpeters: In 2.7, when you're logged into the staff client, you'll get edit links for items you have permission to edit.
09:19 kmlussier So you can skip the step of going to holdings maintenance to edit item information.
09:19 mrpeters oh very cool
09:19 mrpeters i like it
09:19 mrpeters top
09:19 mrpeters oops
09:20 kmlussier cwmars++ #Funding development that saves time for staff. :)
09:20 Shae joined #evergreen
09:25 * dbs ran into https://rt.cpan.org/Public​/Bug/Display.html?id=84841 (simplezoom seg faulting on Ubuntu 12.04), apparently SITKA addressed this by using yaz's deb packages instead. will report back.
09:32 csharp so that would appear if you're allowing z39.50 access to your catalog?
09:33 jeff @coffee [coffee]
09:33 * pinesol_green brews and pours a cup of Kenya Karogoto, and sends it sliding down the bar to brews and pours a cup of Burundi Kinyovu, and sends it sliding down the bar to jeff
09:34 jeff my coffee needs a coffee this morning.
09:34 kmlussier heh
09:34 csharp @coffee [someone]
09:34 * pinesol_green brews and pours a cup of Ethiopia Sidamo Special Prep, and sends it sliding down the bar to mtate
09:34 csharp @quote random
09:34 pinesol_green csharp: Quote #14: "<Dyrcona> Alas, poor Craftsman. I knew him well, Horatio." (added by bshum at 04:18 PM, August 02, 2011)
09:34 mtate mmmm    ... thank you!
09:35 csharp mtate: my pleasure ;-)
09:35 csharp @praise [someone]
09:35 * pinesol_green mrpeters is the very model of a modern major hacker
09:35 mtate @love coffee
09:35 pinesol_green mtate: The operation succeeded.  mtate loves coffee.
09:35 mrpeters haha
09:35 kmlussier @whocares coffee
09:35 pinesol_green kmlussier, csharp and mtate love coffee
09:36 mtate he is script kiddie, hex coder, and little bit of safe-cracker...
09:39 yboston joined #evergreen
09:39 dbs csharp: yes indeed. We're big fans of open z39.50 access here (in fact, required as part of our participation in a national ILL service)
09:39 jeff he exploits [redacted] [redacted] [redacted]
09:40 dbs fwiw, we never had a problem with the distro packages when we were on debian. ubuntu--
09:41 Dyrcona dbs: Debian is more conservative. Ubuntu pulls from snapshots from Sid every 6 months.
09:42 Dyrcona And Sid is named Sid because....
09:43 mtate ...he's unstable
09:43 mtate . o O (...maybe even malicious...)
09:44 Dyrcona mtate: Specifically because he's the kid next door who breaks his toys.
09:44 mtate lol
09:48 sarabee joined #evergreen
09:48 dbs Oh, I know Sid.
09:49 dbs I'm still decrementing ubuntu because this problem has existed for a couple of years.
09:51 csharp well, to be pedantic, the LTS releases sync with debian testing, so this is likely a problem that would exist in jessie too
09:52 csharp unless it doesn't pass muster with Debian testers, that is
10:01 RoganH joined #evergreen
10:15 kmlussier Web client testing is also a good way to remember old bugs that I forgot to file in LP.
10:42 ningalls joined #evergreen
10:48 kmlussier I'm looking at the self-check docs at http://docs.evergreen-ils.org/2.7/_self_che​ckout.html#_configuring_self_check_behavior. For "Patron Login Timeout," it says not currently supported. Is that still true?
10:48 bshum kmlussier: Right
10:49 kmlussier Oh, wait. I see the bug report.
10:49 bshum kmlussier: So there's a bug ticket for that and I wrote new code during the hackaway
10:49 bshum I have to polish it up a bit
10:49 mmorgan bshum++
10:49 kmlussier OK. Then I withdraw my next comment since code it sounds like code is forthcoming. :)
10:49 kmlussier bshum++
10:51 bshum I haven't decided if it's a "new feature" or a "bug fix" though.
10:53 kmlussier I would think bug fix since there is an existing setting that doesn't work.
10:53 * mmorgan agrees that it's a bug fix
10:53 bshum Oh fun then.
10:54 bshum Well if anyone feels brave to try :)
10:54 bshum http://git.evergreen-ils.org/?p=working​/Evergreen.git;a=shortlog;h=refs/heads/​user/bshum/lp1306814-selfcheck-timeout
10:54 bshum That's where I put the initial code I was poking at
10:54 bshum I have to test it with an actual library setting configured.
10:57 bshum I updated the bug report with a link to the code
10:57 bshum And assigned targets as a bug fix.
10:57 csharp heh - so it multiplies the patron timeout value by 1000?
10:57 bshum Right, cause I think the setting is assigned as seconds
10:57 bshum But the value is like milliseconds
11:00 bshum The thing I'm not sure yet is whether I applied the timeout reset to enough places
11:00 kmlussier We've been discussing this question locally, so I'll pose the question here. Has anyone noticed slower catalog searches since upgrading to 2.6?
11:00 * bshum doesn't want to answer that question
11:00 * csharp chuckles at the exorbitant values PINES libraries have been putting in to avoid any sort of timeout
11:00 * RoganH thinks that bshum sees no evil, hears no evil, speaks no evil.
11:00 kmlussier Well, given that response, I think I know what the answer is.
11:01 kmlussier bshum: But some of that was based on your custom 001 record attribute, right?
11:01 bshum kmlussier: Correct, for us, abnormally large entries in our uncontrolled values table was causing slowdown, among other things.
11:01 * kmlussier is looking at search performance on a system that doesn't have custom record attributes.
11:01 bshum I'm finishing testing eeevil's fixes for that.
11:02 bshum Define "slow"
11:02 bshum Like have you guys turned on the debug timing and grabbed numbers on how things are?
11:03 kmlussier This is a system where they timed searches on 2.5 and then timed then again after uprading the same system to 2.6. We're seeing numbers where the search took 3 seconds on 2.5 and is now taking 12-14 seconds. A big difference.
11:03 kmlussier bshum: No, we haven't.
11:04 DPearl joined #evergreen
11:04 bshum kmlussier: Well, what we did in our system was to start looking at the database logs and trying to track down which query calls were taking a long time.
11:05 bshum eeevil suggested me to start watching for queries that were taking longer than like... 1 second. And that's what led me to scrutinize unapi.bre
11:05 bshum And the stuff inside it
11:05 bshum But yeah, I don't have anything specific to contribute to say, "yeah, it's super slow"
11:05 vlewis joined #evergreen
11:05 bshum In fact, our speed has definitely improved since we made the adjustment to production.
11:05 bshum It's still slower than I'd prefer, but it's better.
11:06 kmlussier https://drive.google.com/file/d/0B74gDM​UDwDXqRHlHN1Y3SFdiTlE/view?usp=sharing
11:06 bshum Could also be tuning related.
11:06 bshum Do you know what postgresql version is being used behind the scenes?
11:07 kmlussier Possibly. I was just curious to hear if others have seen it or if it's just us.
11:07 tspindler bshum: i'm not sure is thre an easy way to check version
11:07 bshum tspindler: Not remotely anyways, it's just a matter of asking whoever is running the show I would think :)
11:07 tspindler bshum: it is our server so i have command line access
11:08 bshum kmlussier: I'm not sure I'd say it's slow for everyone.  MVLC has stayed pretty fast to me :)
11:08 bshum We only got slow when we started reingesting and our uncontrolled got huge
11:08 bshum Prior to that people definitely felt Evergreen was fast.  Though we are using our new DB servers too.
11:09 bshum Too much change at once.
11:09 tspindler bshum: version is tspindler@training:~$ psql --version psql (PostgreSQL) 9.1.13
11:27 kmlussier Reporting back for the sake of the logs. Looks like we also have a very large metabib.uncontrolled_record_attr_value table.
11:28 csharp kmlussier: you might try vacuuming that table too - might edge up the speed
11:29 csharp 'vacuum analyze verbose metabib.uncontrolled_record_attr_value' that is
11:29 kmlussier I think they're going to try the code at bug 1374091
11:29 pinesol_green Launchpad bug 1374091 in Evergreen 2.7 "unapi.bre and slow views" (affected: 1, heat: 6) [Undecided,New] https://launchpad.net/bugs/1374091
11:29 csharp verbose is optional, of course, but I like to see the messages
11:33 sandbergja joined #evergreen
11:38 dbwells kmlussier: We didn't experience anything like the slowdowns shown in your chart. (great chart btw!)  We also have a "normal" uncontrolled_record_attr_value table size (2551 rows).
11:39 kmlussier dbwells: The credit for the great chart goes to tspindler. :)
11:47 bshum csharp: Vacuuming the table didn't do anything for us, the new code helped :)
11:50 Bmagic Im testing 2.7, right off the bat I don't see the secondary permission group UI in the staff client. Was there something I forgot to setup?
11:51 kmlussier Bmagic: It should just display in the patron editor. And you need permission to see it.
11:52 Bmagic kmlussier: huh, no magic trick? I am using an account with global everything
11:54 bshum Hmm, it's working for me
11:54 bshum There's a button for "Secondary Groups" that appears next to the profiles
11:54 Bmagic bshum: kmlussier: I will take another look
11:55 bkuhn joined #evergreen
11:55 Bmagic I preformed an upgrade on an existing directory full of 2.6.1 code
11:56 Bmagic aka /openils
11:56 bshum Bmagic: That I don't know, all I know is that a clean install test server I was looking at seems fine.
11:59 nhilton joined #evergreen
11:59 ningalls joined #evergreen
12:05 jihpringle joined #evergreen
12:09 berick gmcharlt: were you able to make any headway w/ your nginx for websockets test?
12:10 berick one of the OPW candidates cannot access webby... wondering if it's a port issue
12:10 Bmagic bshum: I got it figured out, yay!
12:10 gmcharlt berick: wouldn't surprise if it were; I expect to have tuits for that tomorrow
12:10 kmlussier berick: We had a similar issue with another OPW candidate. We narrowed it down to the ports issue.
12:10 berick gmcharlt: i have zero nginx experience (so far), but if I can be of assistance, let me know.
12:11 berick kmlussier: good to know
12:11 berick gmcharlt++
12:12 gmcharlt and, to share in the general "fun": http://the-digital-reader.com/2014/10/06/adobe​-spying-users-collecting-data-ebook-libraries/
12:12 kmlussier I almost forgot. Snigdha said she was still waiting on a response for her SSH key submission. gmcharlt / dbs / tsbere: did any of you see it come through?
12:12 gmcharlt kmlussier: yep, and was responded to, IIRC - perhaps it fell into a spam folder?
12:13 kmlussier gmcharlt: Thanks. I'll let her know.
12:17 mrpeters1 joined #evergreen
12:18 bshum Bmagic++ # cool :)
12:25 dreuther_ joined #evergreen
12:36 dreuther joined #evergreen
12:50 dreuther_ joined #evergreen
12:52 eby_ joined #evergreen
13:00 Bmagic Has anyone setup the web based staff client from the 2.7 branch? I was able to install grunt and bower and node but I'm sort of at a loss as to where the jumping point is for a URL to see the resulting pages
13:04 dreuther joined #evergreen
13:05 buzzy joined #evergreen
13:06 gmcharlt Bmagic: https://yourhost/eg/staff/home
13:09 Bmagic gmcharlt: I must need to start a service? (internal server error)
13:11 Bmagic gmcharlt: nevermind, that's not the error, it's just a blank page
13:15 Bmagic from the apache logs: File does not exist: /openils/var/web/js/ui/default/staff/build
13:16 gmcharlt Bmagic: ah - running the grunt/npm steps IN /openils/var/web/js/ui/default/staff is necessary - or if you ran them in your Evergreen unpacked tarball or Git checkout, just copy the directoriwes over
13:17 gmcharlt note that I may be getting paths a bit wrong - I'm currently waiting to start a webinar
13:17 Bmagic oh I see, I ran them from the Evergreen source
13:17 Bmagic not the /openils dir
13:17 Bmagic thanks
14:16 ldwhalen joined #evergreen
14:59 julialima joined #evergreen
15:08 mrpeters joined #evergreen
15:12 mrpeters in A/T event hell!  I have one particular event (the stock "Hold is ready for pickup") that just simply will not come out of the 'pending' state.  All other events with the same granularity settings (Hourly) are working fine.  The event is active, and new events are added to action_trigger.event regularly, they just never change state.  Any ideas what I might be overlooking?
15:13 bshum mrpeters: Are you using any granularity?
15:13 mrpeters yeah, Hourly
15:13 mrpeters /openils/bin/action_trigger_runner.pl --process-hooks --granularity hourly
15:14 bshum What about --run-pending?
15:14 mrpeters yeah, that runs every 30 -- /openils/bin/action_trigger_runner.pl --osrf-config=/openils/conf/opensrf_core.xml --run-pending
15:14 bshum Do you have one setup for that granularity too
15:14 bshum ?
15:14 bshum By itself, that may not catch the particular granularity.
15:14 bshum It'll run everything else.
15:15 bshum Or at least, that's been my experience so far, with adding other types of custom granularity.
15:15 pastebot "mrpeters" at 64.57.241.14 pasted "AT cron example" (26 lines) at http://paste.evergreen-ils.org/16
15:15 bshum I have to define one cron for --process-hooks and later another for --run-pending
15:16 mrpeters have a look at that....i think this was baselined from the example that comes with the tarballs, but i didn't do the initial setup so I can't be 100% for certain.  Really strange.  They worked prior to upgrade to 2.6.2, but just now finding out about it (2 months later---eesh)
15:17 bshum Well I have no idea exactly
15:17 bshum I just know that I have to have a --run-pending --granularity X cron job
15:17 bshum That if I don't specify separately, it doesn't run those granularity
15:17 mrpeters thats interesting
15:17 mrpeters i'll give it a shot
15:18 bshum I would add an entry for the hourly hook and see what happens.
15:18 bshum Maybe this is some weird regression bug in 2.6
15:18 bshum I don't know if A/T changed
15:19 mrpeters yeah, i am going to try that, its super strange...only that one hourly granularity
15:20 mrpeters so you are thinking one like this:   . ~/.bashrc && /openils/bin/action_trigger_runner.pl --osrf-config=/openils/conf/opensrf_core.xml --run-pending --granularity hourly
15:20 * bshum checks his own crons, but yeah
15:21 mrpeters ok, going to give it a shot
15:23 * bshum doesn't seem to have hold pickup on granularity
15:23 mrpeters yeah i was almost wondreing if it needed to be
15:23 bshum Guess that came after our 1.6-era A/T setup
15:23 mrpeters you probably want those to go out frequently
15:23 bshum Pretty much as soon as they're ready to ship and once the delay is done
15:24 Bmagic we run action_trigger_runner.pl --osrf-config /openils/conf/opensrf_core.xml --process-hooks --run-pending every day at 4am
15:26 mrpeters i think this granularity addition is working....it's actually doing something now
15:26 bshum Whee :)
15:26 bshum So
15:26 bshum Two choices
15:26 bshum Run it separately like that
15:26 bshum Or just remove the granularity
15:26 bshum And let it ride :)
15:26 mrpeters yeah, you know, i do wonder if this is a weird 2.6 thing
15:26 dreuther_ joined #evergreen
15:35 dreuther joined #evergreen
15:38 csharp @who [quote random]?
15:38 pinesol_green Bmagic Quote #68: "<senator> what a nice smile, dojo. why thank me, angularjs, and that's a nice outfit me're wearing." (added by gmcharlt at 10:52 AM, September 27, 2013.
16:09 Bmagic Web staff client - Once I have node, grunt, bower installed, I presume I need to start the node server? My web browser is complaining about not getting a connection on port 7682
16:10 bshum Bmagic: So, assuming you have OpenSRF 2.4 installed?
16:10 bshum Bmagic: And you have an apache2-websockets thingy around?
16:10 Bmagic bshum, yes 2.4 alpha
16:10 Bmagic not sure about apache2-websockets
16:11 Bmagic did I miss that in the docs?
16:11 bshum Bmagic: So one of the things that's in the README.websockets file that ships with alpha are steps to setup websockets.
16:11 Bmagic ah!
16:11 bshum I've been trying to integrate them with the core OpenSRF README file itself
16:11 bshum See, this bug....
16:11 bshum https://bugs.launchpad.net/opensrf/+bug/1369169
16:11 pinesol_green Launchpad bug 1369169 in OpenSRF "Add install instructions for websockets to README (and other cleanup)" (affected: 1, heat: 6) [Undecided,New]
16:11 berick Bmagic: node, bower, etc. are only used for dependency retrieval and unit tests.  it's not needed for running the browser client.
16:12 bshum Bmagic: http://evergreen-ils.org/~bshum/OpenSRF-README.ht​ml#_optional_websockets_installation_instructions
16:12 bshum That's a generated copy of the integrated steps
16:12 Bmagic !!
16:12 Bmagic I new I was missing something
16:12 bshum I still need to revise them a bit, to remove some of the hardcoded assumptions
16:12 bshum Like where's the OpenSRF files to be found
16:12 bshum Not always /home/opensrf/..
16:12 bshum But for the most part, those steps ought to work
16:13 bshum That should spin up the websockets portion of OpenSRF 2.4
16:13 Bmagic ok, cool, I will walk through these instructions and provide feedback then
16:13 bshum And then you should work out from there.
16:13 bshum In theory
16:16 buzzy joined #evergreen
16:18 tspindler left #evergreen
16:21 Bmagic bshum  #it's working  http://www.youtube.com/watch?v=AXwGVXD7qEQ
16:21 Bmagic bshum++
16:22 bshum Bmagic: HAHA!
16:22 bshum Amusingly enough, I was just about to go setup a new VM called "Anakin"  :D
16:22 Bmagic lol
16:22 Dyrcona Bmagic++
16:26 bshum Bmagic++
16:26 Bmagic !!
16:38 buzzy joined #evergreen
17:15 mmorgan left #evergreen
17:24 buzzy joined #evergreen
17:49 pinesol_green Incoming from qatests: Test Success - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html>
17:51 bshum But gmcharlt, the quest_for_knowledge is over!
17:51 bshum http://git.evergreen-ils.org/?p=Evergreen.git;a=c​ommit;h=988605ececad7850f2a7276b64a697b6b5c9ae31
17:51 pinesol_green [evergreen|Dan Wells] LP#1290496: The quest for knowledge is over - <http://git.evergreen-ils.org/?p=​Evergreen.git;a=commit;h=988605e>
17:51 * bshum just read twitter and it uplifted my day. :D
17:51 gmcharlt bshum: it's just been redirected ;)
17:51 bshum gmcharlt++
17:52 gmcharlt bshum: also, I feel like I'm forgetting one of the code names
17:53 bshum Heh
17:56 dbwells maybe Vandelay?
17:57 dbwells nevermind, that's what started it :)
17:58 bshum Heh
18:01 dbs conify?
18:01 * dbs hasn't seen the tweet in question
18:01 gmcharlt aha!
18:02 gmcharlt dbs: https://twitter.com/mjgiarl​o/status/519591580437458948
18:02 dbwells joined #evergreen
18:02 remingtron_ joined #evergreen
18:21 jeff cute.
18:22 jeff open-ils.storage.actor.user.crazy_search amused me when i ran into it years ago, but i'm not sure it's a good example.
18:41 tsbere joined #evergreen
19:41 artunit joined #evergreen
20:33 remingtron_ joined #evergreen
20:33 dbwells_ joined #evergreen
20:35 dbwells__ joined #evergreen

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