| 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-luo-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.... |
