Time |
Nick |
Message |
05:00 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
06:57 |
|
agoben joined #evergreen |
07:12 |
|
rjackson_isl joined #evergreen |
07:19 |
|
JBoyer joined #evergreen |
07:37 |
|
bdljohn joined #evergreen |
08:15 |
|
bos20k joined #evergreen |
08:35 |
|
Dyrcona joined #evergreen |
08:44 |
|
mmorgan joined #evergreen |
09:27 |
|
stephengwills joined #evergreen |
09:32 |
|
yboston joined #evergreen |
09:32 |
|
finnx joined #evergreen |
09:33 |
|
finnx left #evergreen |
09:48 |
|
sandbergja joined #evergreen |
10:17 |
|
Christineb joined #evergreen |
10:25 |
Bmagic |
berick: I tested the installer. It installs. It gracefully removes the previous version. It enables the browser extension. I set my printer to Dymo. And I printed a spine label without a margin error! (I don't have the printer anymore because it was on loan but I printed to the printer through Windows's driver) |
10:26 |
Bmagic |
At the very least: this version of Hatch can't be worse. |
10:27 |
Bmagic |
(Other than it's 214MB) |
10:27 |
berick |
:) |
10:27 |
berick |
Bmagic++ |
10:27 |
berick |
next hurdle seems to be massaging the spine label printing code to be happy with the Dymo's |
10:28 |
berick |
I should be diving back into that soon |
10:28 |
Bmagic |
I can lean on some of our members who have the printer, and I can remote their machine and install this version and hammer out something. If that would be helpful? |
10:28 |
berick |
yes, definitely |
10:28 |
Bmagic |
I'll see if I can't do that soon |
10:29 |
berick |
Bmagic: do you have sites working OK now w/ your patches? |
10:29 |
Bmagic |
I have held off pushing mine |
10:29 |
berick |
gotcha |
10:29 |
Bmagic |
knowing that this was coming, didn't want to make everyone go through so many trials |
10:29 |
berick |
ok, so we're not necissarily losing anything here |
10:30 |
berick |
gotcha |
10:37 |
csharp |
postgresql++ |
10:37 |
csharp |
postgresql++ |
10:37 |
csharp |
postgresql++ |
10:37 |
berick |
preach it |
10:38 |
csharp |
had a streaming replica we're relying on for our PINES migration stop receiving logs (master dropped a needed log before the replica got it) - moving xlogs into place and restarting it automatically fixed it within literally under a minute |
10:39 |
csharp |
(and we now have a replication slot for the replica so that doesn't happen again) |
10:56 |
|
scott_ joined #evergreen |
10:56 |
|
yboston joined #evergreen |
11:18 |
|
Dyrcona joined #evergreen |
11:19 |
Bmagic |
csharp++ # a potiential spy y'all. Watch out on game night |
11:25 |
* csharp |
really wanted to be a CIA agent when he was a kid |
11:26 |
csharp |
my spy name was Brett Kramer |
11:26 |
berick |
sounds like something an acting CIA agent would say to throw us off the trail |
11:26 |
* csharp |
whistles innocently |
11:28 |
* csharp |
while screwing silencer onto a gun |
11:32 |
berick |
heh |
11:43 |
|
khuckins joined #evergreen |
12:03 |
|
sandbergja joined #evergreen |
12:13 |
|
jihpringle joined #evergreen |
12:40 |
|
khuckins joined #evergreen |
12:48 |
|
yboston joined #evergreen |
12:53 |
Dyrcona |
So, I'm searching Lp for a bug that I swear exists. I even tried filing what I think is a duplicate bug and no luck. |
12:54 |
Dyrcona |
Has anyone seen a web staff client bug (on Lp or in person) where copy templates come up empty? It seems to happen after adding a new template at some point, though I don't know the magic trigger, yet. |
12:56 |
mmorgan |
Dyrcona: I have not seen a bug, but have seen that behavior. |
12:57 |
* mmorgan |
had not gotten to the point of searching for an existing lp bug |
12:57 |
jihpringle |
Drycona: could you be thinking of https://bugs.launchpad.net/evergreen/+bug/1772062 ? |
12:57 |
pinesol |
Launchpad bug 1772062 in Evergreen 3.1 "Copy Template Missing Values When Applied" [High,Confirmed] |
12:58 |
Dyrcona |
jihpringle: Yeah, I found that one in my email, thanks. |
12:58 |
Dyrcona |
That might be it. I have to reread it. |
12:59 |
jihpringle |
that's the only one I remember that deals with missing values |
13:00 |
* mmorgan |
has seen the entire list of templates for a user disappear. That sounded like what Dyrcona was describing. |
13:01 |
Dyrcona |
Well, I find it iffy to rely on user-supplied descriptions of problems. |
13:04 |
Dyrcona |
mmorgan: https://bugs.launchpad.net/evergreen/+bug/1772062/comments/18 |
13:04 |
pinesol |
Launchpad bug 1772062 in Evergreen 3.1 "Copy Template Missing Values When Applied" [High,Confirmed] |
13:07 |
* mmorgan |
reads |
13:10 |
mmorgan |
Comment #5 describes what I've seen, but have not been able to reproduce reliably, haven't looked for the NOT CONNECTED errors: https://bugs.launchpad.net/evergreen/+bug/1772062/comments/5 |
13:10 |
pinesol |
Launchpad bug 1772062 in Evergreen 3.1 "Copy Template Missing Values When Applied" [High,Confirmed] |
13:11 |
mmorgan |
Sounds like two different issues being described in that bug |
13:12 |
Dyrcona |
We've had multiple reports of problems with copy templates. |
13:14 |
mmorgan |
Ditto. |
13:29 |
csharp |
same here, btw, though from what I'm aware of, things have calmed |
13:30 |
csharp |
i.e., fewer complaints are coming to us |
13:37 |
jeffdavis |
Is there a way to distinguish auth attempts that fail because the user is barred from other auth failures? It looks to me like the response is the same whether the user is barred, the password is incorrect, etc. |
13:41 |
Dyrcona |
jeffdavis: That's partly by design to thwart password guessing attempts. |
13:47 |
jeffdavis |
We do return a different event if auth fails because the account is inactive. |
13:50 |
Dyrcona |
Well, that might be a security bug. :) |
13:50 |
Dyrcona |
Or a feature, depending on your point of view. |
14:01 |
berick |
iirc, inactive events only return after successfully authenticating |
14:07 |
jeffdavis |
Looks like it. |
14:39 |
Dyrcona |
Bleh. Gitlab eventually overwrote my configuration to warn on zero padded file modes instead of erroring out. |
14:39 |
Dyrcona |
On the plus side, I've got a configuration that should survive upgrades, now. |
14:46 |
jeff |
I haven't had that issue. What did you end up having to do differently? |
14:51 |
Dyrcona |
jeff: You've never encountered https://gitlab.com/gitlab-org/omnibus-gitlab/issues/1602 or you've never encountered gitlab overwriting /var/opt/gitlab/.gitconfig, or you put the 'receive "fsck"' setting elsewhere? |
14:52 |
Dyrcona |
I tried https://gitlab.com/gitlab-org/omnibus-gitlab/issues/1602#note_82524498 but it didn't work as written. I had to play with it until I came up with 'receive "fsck"' => ["zeroPaddedFilemode = warn"], |
14:53 |
Dyrcona |
ruby-- |
14:54 |
* Dyrcona |
blames ruby for the configuration syntax. |
14:54 |
csharp |
@blame ruby for Dyrcona's issues |
14:54 |
pinesol |
csharp: ruby is probably integrated with systemd for Dyrcona's issues |
14:54 |
Dyrcona |
Oh, that would take the cake....integrating ruby with systemd.... ;) |
14:56 |
Dyrcona |
And, drupal-- |
14:56 |
Dyrcona |
I was messing with Drupal issues this morning, but gave up since a) it's not my job, and b) I don't really know drupal, just PHP and MySQL. |
14:57 |
* stephengwills |
smells the word Drupal and peeks in excitedly …. ;-P |
15:12 |
* csharp |
|
15:12 |
* csharp |
looks forward to being able to focus on EG bugs again someday |
15:13 |
csharp |
we have the PINES/GPLS IT migration, an office move, and my travel schedule has me booked until mid-May |
15:22 |
Dyrcona |
I just have to say this to get it out of my system: "I TOLD YOU SO!' |
15:22 |
* Dyrcona |
is just interested in surviving the night.... |
16:11 |
|
sandbergja_ joined #evergreen |
16:19 |
* mmorgan |
has been experimenting with Best-Hold selection sort order. |
16:19 |
mmorgan |
Can it be configured such that the item gets sent home after circulating away from home for a certain period of time, even if there is no hold at home? |
16:20 |
mmorgan |
That is, can the "best hold" ever be "no hold"? |
16:22 |
mmorgan |
I've tried setting up a sort order with shtime - "Copy Has Been Home At All Lately", but it didn't send the item home. |
16:29 |
miker |
mmorgan: I don't believe there's a "skip all holds and send home even if there's no current home-hold" option. that logic is just about sorting extant holds that are eyeballing a copy, not transiting generally |
16:32 |
mmorgan |
miker: :-( Thanks. There was also a suggestion that setting a soft stalling interval might serve to get the item home rather than filling the next hold, but I tested that too, and the item wasn't sent home. |
16:33 |
mmorgan |
Is there any combination of settings in Evergreen that can accomplish getting the item back home short of placing a hold for pickup there? |
16:33 |
miker |
mmorgan: yeah, that's really just about stopping opportunistic capture. at-pickup-lib and currently-targetted holds will still capture |
16:34 |
mmorgan |
We are using holds always go home |
16:35 |
miker |
mmorgan: not that I can think of OTTOMH. I think it would be new logic that would check /before/ sorting holds to see if a copy hasn't been home "recently" (probably based on a setting, maybe the same as shtime uses now) and skips hold capture altogether (which would cause a transit home, or sticking "here" if float allows) |
16:38 |
miker |
(incidentally, I've recently implemented some code for FulfILLment that does a variation of this (binary "op capture" vs "go home without any capture attempt"), but it's almost certainly not directly portable to EG because the code in question has diverged a /lot/) ... but it should be possible to do something similar for EG given time and tuits. |
16:39 |
mmorgan |
Ah. No quick fix, then. I will open a wishlist bug and look for a workaround in the meantime. |
16:41 |
jeff |
Dyrcona: I was wrong. I had set the setting in a way that an upgrade overwrote it, but I just hadn't noticed yet. I came to the same conclusion as you: setting in /etc/gitlab/gitlab.rb is the way to go. |
16:42 |
jeff |
Dyrcona: and the syntax is awkward mostly because of the format of the git config file... ;-) |
16:53 |
|
yboston joined #evergreen |
17:00 |
pinesol |
News from qatests: Failed Running pgTAP tests <http://testing.evergreen-ils.org/~live/test.42.html#2019-04-09T16:57:41,930899029-0400 -0> |
17:05 |
Bmagic |
Weird problem I've not ran into before. Setting up a new machine from scratch. 16.04. This file doesn't exist: "/usr/share/doc/apache2/examples/setup-instance" for the websockets step |
17:06 |
Bmagic |
I've apt-get remove --purge apache2* and reinstalled with "make -f src/extras/Makefile.install ubuntu-xenial" from the OpenSRF repo. Still doesn't create that file |
17:06 |
|
mmorgan left #evergreen |
17:11 |
Dyrcona |
jeff: Yes, but still awkward partly because of ruby. :) |
17:13 |
Dyrcona |
Bmagic: It exists on my 16.04 VMs. |
17:13 |
Bmagic |
mine too :) |
17:14 |
Dyrcona |
I encountered a weird problem where not all of the apache packages installed correctly, I find to install apache2-bin manually. |
17:14 |
Dyrcona |
This was yesterday actually, but someone else had tried to install Apache 2.2 on Ubuntu 18.04 or something like that. |
17:15 |
Dyrcona |
This is related to my Drupal complaint from earlier today. :) |
17:16 |
Dyrcona |
Bmagic: See what this outputs and compare it on the one where setup-instance is missing: apt list --installed apache2* |
17:16 |
Dyrcona |
Maybe something is missing. |
17:17 |
Bmagic |
apache2-bin |
17:17 |
Bmagic |
is listed |
17:17 |
Bmagic |
but, thanks! I will dive deeper. that gives me some ideas |
17:17 |
Dyrcona |
setup-instance is probably in apache2-utils |
17:17 |
Dyrcona |
There's a way to find out, but I'd have to look up the exact command options. |
17:18 |
Dyrcona |
My issue with missing apache2-bin was apache wouldn't start because /usr/sbin/apache2 was missing. |
17:20 |
Dyrcona |
Bmagic: Why are you installing apache2-websocket? websocketd is better. |
17:20 |
Bmagic |
Just following the instructions |
17:21 |
Bmagic |
3.0.2 and EG 3.1.10 |
17:21 |
Dyrcona |
I have a branch that backports the necessary files to 3.0 from 3.1 for websocketd, let me see if I've pushed it to the working repository. |
17:23 |
Dyrcona |
No, I haven't pushed it and don't have it locally. |
17:29 |
Dyrcona |
grrr.... I didn't add the remote with a valid push url. I have to fix that. |
17:31 |
Dyrcona |
Hmm... git says it pushed OK, but I don't see it gitweb. |
17:32 |
Dyrcona |
Oh! It sorts by the dates on the commits, not the date it was pushed. |
17:32 |
Dyrcona |
Bmagic: https://git.evergreen-ils.org/?p=working/OpenSRF.git;a=shortlog;h=refs/heads/user/dyrcona/rel_3_0-websocketd |
17:35 |
|
eady joined #evergreen |
17:38 |
* Dyrcona |
wreaks havoc with his RAM and CPU by starting and stopping all of his vms in sequence to install updates. |
17:42 |
Bmagic |
TY! |
17:48 |
Dyrcona |
That branch might need a merge or rebase to get up to the latest rel_3_0. |
17:50 |
Bmagic |
I guess I could use OpenSRF 3.1 with EG 3.1.10 |
17:50 |
Bmagic |
right? |
17:56 |
Dyrcona |
Yeah, I think you can even use 3.1 with Evergreen 3.0. |
17:57 |
Dyrcona |
The only thing you can't do is use OpenSRF 3.0+ with Evergreen 2.12 or lower. |
17:58 |
Dyrcona |
I've run relatively recent OpenSRF master with Evergreen 3.0 on a test virtual machine, and I didn't notice any problems. |
18:13 |
Dyrcona |
Bmagic: I rebased and force-pushed that rel_3_0-websocketd branch. |
18:13 |
Dyrcona |
There was a conflict in the README, but I think I resolved it so that things make sense. |
20:22 |
|
stephengwills joined #evergreen |