Evergreen ILS Website

IRC log for #evergreen, 2017-06-28

| 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
04:31 pinesol_green News from qatests: Test Failure <http://testing.evergreen-ils.org/~live>
06:40 rlefaive joined #evergreen
07:15 agoben joined #evergreen
07:15 rjackson_isl joined #evergreen
07:53 rlefaive joined #evergreen
08:23 kmlussier joined #evergreen
08:29 rlefaive_ joined #evergreen
08:31 _adb joined #evergreen
08:32 RBecker joined #evergreen
08:41 mmorgan joined #evergreen
08:51 bos20k joined #evergreen
09:10 Dyrcona joined #evergreen
09:13 tsbere_ joined #evergreen
09:40 yboston joined #evergreen
09:43 maryj joined #evergreen
10:45 kmlussier @coffee [someone]
10:46 * pinesol_green brews and pours a cup of Kenya Kiandu, and sends it sliding down the bar to gmcharlt
10:46 kmlussier @tea [someone]
10:46 * pinesol_green brews and pours a pot of Bi Luo Chun Green Tea (Pi Lo Chun), and sends it sliding down the bar to eby (http://ratetea.com/tea/teavivre/bi-l​uo-chun-green-tea-pi-lo-chun/6490/)
10:46 gmcharlt kmlussier++
11:09 kmlussier joined #evergreen
11:10 kmlussier Have we ever talked about changing defaults so that metabib indexes are created using GIN instead of GIST?
11:17 miker we have, and we should
11:20 miker or even RUM indexes (yes, that's a thing. also VODKA indexes for hierarchical data like JSON. apparently DB developers are lushes...)
11:23 kmlussier Yes, we do need more rum and vodka in our ILS.
11:24 kmlussier Maybe we should change it the next time we have a feature that requires a reingest.
11:25 * kmlussier can open a LP bug.
11:25 dbs frank___: yay!
11:32 Christineb joined #evergreen
11:39 * csharp creates EVERCLEAR indexes alongside COINTREAU ones
11:42 Dyrcona Are RUM indexes better than GIN?
11:46 csharp Dyrcona: if you're using COLA, yes, but GIN works better with SPRITE or TONIC
11:47 Dyrcona csharp++
11:47 csharp or even VERMOUTH
11:47 Dyrcona :)
12:11 jihpringle joined #evergreen
12:15 abowling joined #evergreen
12:26 abowling1 joined #evergreen
13:18 rjackson_isl Need of HELP!!! One site is seeing much of their holds not captured with Check in Scan (log shows HOLD_CAPTURE_DELAYED) and the only thing I see strange is the "Change Reshelving Status Interval" of 3 hours - will that cause this issue?
13:19 Dyrcona I don't think it is meant to affect this, no.
13:20 rjackson_isl Dyrcona: any things to recommend to check that might cause the delay msg?
13:20 Dyrcona Is the option to skip holds on during checkin?
13:20 Dyrcona skip holds & transits I think it is called. You can probably see this in the logs.
13:21 rjackson_isl Will ask - the ticket indicated 80-90% getting this messgae and some making it thru but who knows?!
13:23 jeff HOLD_CAPTURE_DELAYED is not "suppress holds and transits", that event is raised when a copy is in a shelving location where asset.copy_location.hold_verify is TRUE.
13:23 Dyrcona rjackson_isl: Copy location has hold_verify enabled.
13:23 Dyrcona jeff: Curses! Beaten again.
13:23 Dyrcona Or something...
13:23 Dyrcona :)
13:23 rjackson_isl jeff++ Dyrcona++ t
13:24 jeff in the XUL client, that results in a staff dialog for "This item could fulfill a hold request but capture has been delayed by policy."
13:24 jeff unless you're suppressing pop-ups, i think.
13:25 jeff the dialog then has options for capture or don't capture.
13:25 jeff it was originally intended to prevent opportunistic hold capture on items where they must be examined / cleaned / etc before going on the holdshelf.
13:26 jeff it allows you to check an item in, but not capture it, then the item goes through whatever (potentially time-consuming, potentially in-another-department) process and you check it in again and this time you say "yes, capture it."
13:26 jeff it's a shelving location specific "are you sure you want to capture this hold?" prompt.
13:28 rjackson_isl Yup - just checked their locations and most (not all) have that flag on. Guessing a mis-understanding and a recent update by local admin.
13:28 Dyrcona jeff++
13:28 rjackson_isl what Dyrcona said!
13:52 mmorgan joined #evergreen
14:14 kmlussier Wow! Copy location group searches are seeing a big boost in performance with bug 1698206.  Nice!
14:14 pinesol_green Launchpad bug 1698206 in Evergreen "Eliminate staged search" [Wishlist,New] https://launchpad.net/bugs/1698206
14:15 bos20k Hello. Question regarding the XUL staff client.  Is the AUTOUPDATE_HOST compiled in to the client?
14:16 bos20k So it will always look there for updates?
14:16 bshum It will for the client it's set for
14:17 bshum I think if you don't pass that argument for the next client you build, you could end an update line
14:17 bshum Or I have done that by accident before..
14:17 * bshum whistles innocently
14:18 bos20k So, if you are running a client that is pointing at production.domain.com, it will only ever look there.  Even if you try to log in to testing.domain.com it will not see the updates sitting on testing.domain.com?
14:18 Dyrcona It's set at configure time. --with-autoupdates-host=
14:18 bshum Right, you would need to build a different client to point at auto-updates elsewhere I would think.
14:18 Dyrcona Yes, that is my understanding.
14:19 bos20k Ok, just want to make sure that was correct.
14:19 jeffdavis The autoupdate hostname is saved in the defaults/preferences/autoupdate.js file in your copy of the client, so you can edit that for testing purposes too.
14:19 bos20k Otherwise I'm doing something wrong on my testing setup since the production client doesn't want to update from the testing server.
14:19 bshum Yeah, but... the files on the server side have to be able to upgrade from X to Y version.  So that sounds messy to me jeffdavis
14:20 bshum I mean you could copy production XUL and let the test server build on top of it
14:20 bshum But yuck
14:20 Dyrcona I always build custom clients for testing, often with a different app name to store preferences in a different place.
14:20 jeffdavis That's what we do during pre-upgrade testing.
14:20 Dyrcona just use the web staff client? :)
14:20 bos20k :) Soon enough...
14:21 bos20k Thanks everyone
14:21 Dyrcona bos20k: you know about the manualupdates.html page, right?
14:22 bos20k Dyrcona: yes, I was just trying to test the auto update stuff.  Will do it a different way that should work.
14:22 Dyrcona OK.
14:22 Dyrcona In my experience auto updates work on Windows, but not Linux.
14:22 jeffdavis ^ To be clear, "that's what we do" = copy existing updates from production to our upgrade testing server, build the client on the test server with autoupdate_host set to our production URL, manually edit the autoupdate.js file to point at the test server for testing purposes, and copy the new updates from the test server back to production during the upgrade proper.
14:23 jeffdavis Cumbersome, but works for us. (And yeah, web client will be nice!)
14:23 bshum jeffdavis: That makes more sense to me.  I didn't think diverging prod / test without copying something would work cleanly
14:23 bshum jeffdavis++ # satisfying my curiousity :D
14:24 Dyrcona I'd set the autoupdate host on the testing server at configure time and save a step or two.
14:24 jeffdavis Dyrcona: well, we want to test the actual client that we make available to our libraries, and we want that client to have the production autoupdate_host built-in.
14:25 Dyrcona But, I also would build everything fresh again on production proper. :)
14:25 jeffdavis We have libraries that want the new client available to install several weeks in advance of the upgrade.
14:26 jeffdavis Building on prod would be preferable for me, but not possible in that case, alas. :)
14:26 Dyrcona See, I'd just tell them No, but I can be a jerk like that. :)
14:27 Dyrcona j/k
14:27 bshum I think ever since like 2.7, I stopped paying attention to XUL stuff, since it's basically been frozen
14:27 bshum All that extra testing sounds boring when nothing is supposed to be different :)
14:28 bshum But yay, testing
15:13 bos20k I changed the hostname in autoupdate.js but it still says there is no update...
15:14 jeffdavis Does your test server have a valid SSL certificate?
15:14 rjackson_isl_ joined #evergreen
15:15 bos20k jeffdavis: yes, it does
15:15 bos20k I also tried changing https:// to http:// in autoupdate.js but that didn't make a difference either.
15:15 maryj_ joined #evergreen
15:16 Dyrcona bos20k: Did you copy the production files over before making the updates client?
15:16 Dyrcona It won't make updates if there is nothing to update against.
15:17 bos20k Dyrcona: I cloned a production VM for this so I believe it all is there.
15:17 bos20k There are .patchline files going back to 2.3.0
15:17 bos20k It looks to me like they are there for this update as well.
15:19 bos20k I tried accessing the URLs manually in firefox.  They come up fine from what I can see.  I also tried to access the .mar file URLs and firefox offers to download them.
15:21 bos20k I did give this new staff client a custom stamp of biblio_2_12  I don't see why that would be a problem though.  Old client has a custom stamp of 2.9_0
15:24 bshum bos20k: So you changed all the hostnames in that autoupdate.js file (I saw like three or so)
15:24 bos20k bshum: yes
15:26 bshum And you've got old .mar for 2.9_0 in /openils/var/updates/archives I guess
15:26 bshum From your copy
15:27 bos20k yes
15:28 Dyrcona bos20k: You can always do make updates-client again to be sure.
15:28 bshum I wonder if it does matter what you name the thing
15:29 bos20k Dyrcona: That has been done many times.
15:29 bshum https://developer.mozilla.org/en​-US/docs/Toolkit_version_format gets linked to from old https://wiki.evergreen-ils.org/doku.php?id​=mozilla-devel:deploying_automatic_updates
15:30 bshum and that talks about version numbering
15:30 bshum Maybe it doesn't think biblio_2_12 is newer ?
15:30 * bshum hasn't really tested
15:31 bshum I mean I haven't tested words ahead of the numbers
15:31 bshum The doc seems to say numbers, then letters
15:31 bshum 2.2.0mvlc.0 from the wiki
15:31 bshum I'm really just spitballing and guessing; I don't know
15:32 bos20k Hmmm, well, the default name is rel_2_12_3  I will try that next.  If that doesn't work I will try just 2_12_3
15:33 bos20k Or maybe even 2.12_3...
15:34 Dyrcona bos20k: The stamp id is not the version number. I skip stamp id and specify STAFF_CLIENT_VERSION when building.
15:34 Dyrcona Something like STAFF_CLIENT_VERSION=2.12cwtrain003
15:35 Dyrcona I use different versions for training and production.
15:35 bos20k Dyrcona: I had both ID and VERSION set to biblio_2_12  I bet that is the problem...
15:35 Dyrcona I'd have to check again how the version is determined from the STAMP_ID.
15:36 Dyrcona bos20k: Probably.
15:36 Dyrcona I believe the version needs to begin with digits or it gets confused, and use dots, not underscores for best results.
15:39 bos20k Yup, don't mess with STAFF_CLIENT_STAMP_ID...  It offers to update now.  Now to clean up my mess and test the procedure again.
15:40 bos20k Thanks again!
16:31 pinesol_green News from qatests: Test Failure <http://testing.evergreen-ils.org/~live>
16:38 maryj joined #evergreen
17:07 mmorgan left #evergreen
17:29 cesardv random fact: apparently mongoDB built a CI server called Evergreen https://jira.mongodb.org/browse/EVG
17:34 berick couldn't they have at least spelled it Evrgrn
17:34 gmcharlt Here's a plan
17:35 gmcharlt 1. Teach Evergreen-the-CI about authority records
17:35 gmcharlt 2. ???
17:35 gmcharlt 3. PROFIT!
17:35 cesardv looks pretty cool actually https://evergreen.mongodb.com/
17:36 cesardv they even have a similar "pine"-type logo
17:37 cesardv sharpen your lawyers... I think it's time to sue ;)
17:37 berick huh, this is the first time i've made the connection of "ever green" to "always good/OK/GO" -- i'm guessing that was the motivation for the name.
17:38 berick here I was just thinking about trees
17:39 cesardv berick: they do have a green basil type of "leaf" as their logo
17:40 berick cesardv: indeed, matching the color of the 'success' blocks on their test coverage grids
17:40 berick (presumably, looks close)
17:40 cesardv berick: yep definitely could be
17:42 rhamby cesardv: our trademark requires they enter enter the realm of library services for infringment ... once they do though ... POW ZOOM TO THE MOON!
17:43 phasefx unless we were Apple or somebody huge, then they'd sue or at least send nasty letters no matter what the domain :)
17:44 cesardv rhamby: you leave that to the lawyers to spin around ;)
17:44 * phasefx makes a line of paper airplanes called iPods.. "oh, hello.  What's with the baseball bats and fierce demeanors?"
17:45 cesardv phasefx: the baseball bats'll teach you to "think different"
17:46 phasefx they're solid white baseball bats
17:46 rhamby phasefx: unless you're willing to pay extra for the rose gold
17:46 cesardv phasefx: airplane grade aluminum, you mean
17:47 phasefx added feature, they leave an apple mark on your forehead
17:47 rhamby there should be a "you're holding it wrong" joke in there somewhere ....
17:48 cesardv phasefx: then they stick you with an un-athorized use of their logo...
17:48 * phasefx sighs
17:49 * phasefx has to apply the baseball bat three different times to get it right
17:56 cesardv phasefx: learns the hard way...
17:57 cesardv anyhow, have a good one guys, later!
19:42 Jillianne joined #evergreen
19:53 Freddy_Enrique joined #evergreen
21:32 Freddy_Enrique So quiet....

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