Time |
Nick |
Message |
03:48 |
|
jonadab joined #evergreen |
05:00 |
pinesol_green |
News from qatests: Test Success <http://testing.evergreen-ils.org/~live> |
07:10 |
|
rjackson_isl joined #evergreen |
07:17 |
|
agoben joined #evergreen |
08:06 |
|
rlefaive joined #evergreen |
08:36 |
|
Dyrcona joined #evergreen |
08:39 |
|
remingtron joined #evergreen |
08:42 |
|
mmorgan joined #evergreen |
08:42 |
|
kmlussier joined #evergreen |
08:50 |
Dyrcona |
"Sorry. We don't like your new password. Guess again." ;) |
08:51 |
* tsbere |
had what he thought was that kind of issue recently, only to discover that the issue was "the password reset interface doesn't work in the browser we embedded in our app" |
08:52 |
jeff |
ouch. |
08:57 |
* Dyrcona |
deletes his comment on the lp bug before hitting post. |
08:58 |
Dyrcona |
I've run into a couple of sites that accepted my password with funk characters when I made the account, but the login screen has some kind of limit or bug where it rejects the very same password. |
08:58 |
|
rlefaive joined #evergreen |
08:58 |
Dyrcona |
It's either too long or doesn't htmlize the input properly. |
09:01 |
Dyrcona |
But, I kind of agree that just validating against a regex is lame, but then, I kind of think trying to force users to use "secure" passwords is going about it all wrong. :) |
09:34 |
|
yboston joined #evergreen |
10:13 |
|
jvwoolf joined #evergreen |
10:17 |
|
maryj joined #evergreen |
10:42 |
|
remingtron joined #evergreen |
10:49 |
Dyrcona |
Another interesting PgAdmin observation: Using ssh tunnels created on the command line gives a seemingly faster connection than using PgAdmin's built-in SSH tunnel capability. |
10:50 |
tsbere |
I never use the built-in capability. I find it does not work well. |
10:56 |
Dyrcona |
Me, neither, but I guess I forgot and I tried it earlier this week. |
10:57 |
Dyrcona |
I still have my tunnels configured for MVLC. :) I'll probably delete them before too long. |
10:58 |
kmlussier |
There is a permission called CREATE_DUPLICATE_HOLDS in the schema that doesn't appear to be used anywhere. Does anyone know what the intended purpose for that permission was? |
10:58 |
kmlussier |
I'm wondering if it was mean to serve a different purpose than the HOLD_EXISTS.override permission. |
11:08 |
kmlussier |
s/mean/meant |
11:08 |
kmlussier |
I didn't intend to accuse the software of being mean. |
11:10 |
jeffdavis |
Yeah, it's usually stubborn rather than actively malevolent. |
11:10 |
jeffdavis |
:P |
11:12 |
mmorgan |
Or maybe it's just being mischeivous, like when it plays the "Find the save column option" game ;-) |
11:12 |
berick |
kmlussier: i'm fairly certain the intention was the same. |
11:13 |
|
bmills joined #evergreen |
11:15 |
kmlussier |
berick: Thanks! |
11:19 |
Stompro |
berick++ Thanks for the info on the au.create hook, that is a much better option for the welcome email. |
11:21 |
|
jvwoolf left #evergreen |
11:22 |
berick |
Stompro: cool. we started talking about it here (because of the mail list chatter) and it jarred my memory of old, unused code. |
11:24 |
phasefx |
graced: kmlussier: rhamby: maybe an outreach committee thing, but a sales person from Capterra was emailing docsevergreen-ils.org trying to find someone to maintain their "free" listing for Evergreen. I tried to educate them on the nature of EG and pointed them to the companies page (yes, you all can thank me later). She was then curious about who ran the "campaign" for Evergreen and talked of |
11:24 |
phasefx |
adwords. I expressed ignorance and pointed her to the outreach committee wiki page. Again, feel free to thank me :) |
11:24 |
graced |
uh... thanks? |
11:24 |
|
rlefaive joined #evergreen |
11:24 |
graced |
;) |
11:24 |
phasefx |
:D |
11:25 |
phasefx |
also suggested that they weren't likely to find a volunteer to maintain a list that was already maintained elsewhere |
11:25 |
berick |
*graced puts a box of kittens in the mail as thanks to phasefx* |
11:26 |
rhamby |
berick++ |
11:26 |
kmlussier |
#thanksphasefx |
11:26 |
phasefx |
free kittens are the best |
11:27 |
graced |
berick++ thanks for the idea |
11:27 |
phasefx |
so yes, this was just a horrible confession and I'm sorry :) |
11:29 |
kmlussier |
Oh, look, we already have a profile there. |
11:29 |
kmlussier |
http://www.capterra.com/library-automation-software/spotlight/82991/Evergreen%20ILS/Evergreen |
11:31 |
rhamby |
Apparently we need someone to run a campaign. Who wants to do that? Bueller? Bueller? |
11:31 |
|
khuckins joined #evergreen |
11:34 |
kmlussier |
Deployment: Installed - Windows |
11:34 |
JBoyer |
"Deployment: Installed - Windows" - It feels so good when someone really "gets" you, doesn't it? |
11:34 |
JBoyer |
Bah! Too slow. :p |
11:34 |
kmlussier |
JBoyer++ |
11:36 |
kmlussier |
I almost prefer to have no profile there than an incomplete/inaccurate profile. |
11:37 |
JBoyer |
Yeah. Training - Yup, Support - nope. What? |
11:38 |
berick |
kill it with fire |
12:00 |
|
brahmina joined #evergreen |
12:01 |
|
khuckins joined #evergreen |
12:01 |
|
tsbere_ joined #evergreen |
12:02 |
|
abowling joined #evergreen |
12:05 |
|
rlefaive_ joined #evergreen |
12:54 |
|
jihpringle joined #evergreen |
13:02 |
|
remingtron joined #evergreen |
13:59 |
dbs |
Microsoft had (might still have) that issue with their passwords; you could sign up for an MSN Passport account with a 20-char password, but when you tried to log in it with a 3rd party service you would find out it had been truncated at 16 chars |
13:59 |
dbs |
https://developer.pidgin.im/ticket/1233 |
13:59 |
dbs |
so who wants to add 2FA to evergreen? *ducks* |
14:01 |
|
rlefaive_ joined #evergreen |
14:03 |
gmcharlt |
dbs: well, I have an ubikey... just need to find some tuits ;) |
14:05 |
Dyrcona |
heh |
14:07 |
csharp |
okay, I'm having an issue with A/T where the trigger drone dies just after this message: 2017-01-26 14:03:11 utility01 open-ils.trigger: [WARN:24489:Client.pm:122:] Sending large message of 52809654 bytes to routerprivate.utility01.gapines.org/open-ils.trigger |
14:07 |
csharp |
so is that too large for ejabberd? |
14:08 |
csharp |
no log errors from ejabberd that look relevant |
14:09 |
csharp |
this is the message that follows the one I just posted: 2017-01-26 14:03:22 utility01 open-ils.trigger: [ERR :24489:EX.pm:66:] Exception: OpenSRF::EX::JabberDisconnected 2017-01-26T14:03:22 OpenSRF::Transport::SlimJabber::Client /usr/local/share/perl/5.18.2/OpenSRF/Transport/SlimJabber/Client.pm:199 JabberDisconnected Exception: This JabberClient instance is no longer connected to the server |
14:10 |
csharp |
so 11 seconds later |
14:10 |
csharp |
so could it be a keepalive problem? |
14:11 |
|
bmills joined #evergreen |
14:17 |
JBoyer |
csharp, there's a max message size set in your ejabberd config file too. The docs say to increase it fairly high, but 50000000+ sounds well past it. |
14:18 |
JBoyer |
(And I don't know how loudly ej complains if you try to top it) |
14:19 |
berick |
csharp: opensrf has a msg_size_warn setting that defaults to 1800000 bytes |
14:20 |
jeff |
for a long time the recommendation has been max_stanza_size of 2000000. That recommendation is removed from the README in the rel_2_5 branch of OpenSRF. |
14:20 |
berick |
intended to help diagnose cases where a message may have been dropped by ejabberd |
14:22 |
miker |
csharp: well, that's 52MB, so... |
14:22 |
berick |
csharp: 52809654 likely exceeds your ejabberd max_stanza_size |
14:22 |
JBoyer |
csharp, Also suddenly very interesting to me: Are you seeing this when trying to use action_trigger_aggregator.pl? Because I was considering moving our notices to that (upon receipt of suffient tuits.) |
14:23 |
berick |
JBoyer: the aggregator was built specifically to avoid this problem, so hopefully not |
14:23 |
miker |
csharp: it's probably getting hit by the traffic shaper |
14:23 |
JBoyer |
berick, ah, good. I haven't looked at it much yet. |
14:25 |
miker |
jeff: it's removed because we added automatic partial messages (chunking) :) |
14:25 |
miker |
in 2.5, that is |
14:25 |
csharp |
JBoyer: not aggregator - just trying to catch up on a bunch of notices |
14:25 |
csharp |
I'll try to chop it into smaller chunks |
14:25 |
jeff |
miker: yes, i know. :-) |
14:26 |
jeff |
(but forgot to state that, so thanks!) |
14:26 |
csharp |
we're trying to diagnose a template issue on top of this, so it's an unwelcome red herring |
14:26 |
miker |
which will get csharp around the extant problem, but replace it with 1000 messages :) |
14:26 |
csharp |
thanks to all of you for the info |
14:27 |
miker |
csharp: well, it's an actual issue ... something generated a 52MB pile of output |
14:27 |
miker |
unless that's reasonable in your situation |
14:27 |
csharp |
not sure, actually - we're troubleshooting SMS holds-are-ready-for-pickup notices that are dying off |
14:28 |
JBoyer |
OH. This is starting to sound familiar. csharp, did I understand that you're trying to aggregate all of your notices for a single run into a single ateo? |
14:28 |
Dyrcona |
Must be XML... :) |
14:28 |
miker |
if they're granularity bound, then I'd say that's not a reasonable output size ;) |
14:28 |
csharp |
it dies just after they get to "collected" state |
14:28 |
csharp |
yes, they are granulated :-) |
14:29 |
miker |
Diamond(tm) brand notifications :) |
14:29 |
csharp |
JBoyer: no, this is a separate issue - that's for UMS xml file processing |
14:32 |
JBoyer |
Unless I'm still misunderstanding something you're going to want to not do that either for similar reasons. We group by user for notices but still don't group the entire output's run until they're pulled out of the db. |
14:32 |
JBoyer |
But as that's a separate issue, that can wait. |
14:44 |
csharp |
I can't imagine what's generating 52MB - these are just a few thousand SMS messages |
14:45 |
csharp |
I'm trying to make the perl less opaque with debugging log messages, but it's still pretty black-box-y to me |
14:45 |
JBoyer |
Can you post the ated entry? |
14:46 |
miker |
and environment, and params? |
14:46 |
berick |
lot of people out there using PG 9.5? |
14:48 |
Dyrcona |
berick: Considering upgrading to 9.5 from 9.2 next month. |
14:49 |
berick |
Dyrcona: good to know. trying to figure out where to upgrade to.. also on 9.2 here. |
14:49 |
csharp |
berick: I'm planning to start testing in PINES for 2.12/Labor Day upgrade |
14:49 |
berick |
csharp: *nod* |
14:49 |
Dyrcona |
berick: I believe NOBLE just upgraded to 9.4. |
14:49 |
csharp |
I'm using 9.5 on a standalone EG server for the governor's mansion and I haven't seen problems, but it's a tiny dataset |
14:49 |
csharp |
and no transaction load |
14:50 |
csharp |
9.4 rox |
14:50 |
berick |
i have it on my test vm's. been fine, but yeah, no load |
14:51 |
Bmagic |
berick: we are on 9.5 atop 16.04 |
14:52 |
berick |
Bmagic: cool, no issues? |
14:52 |
csharp |
just pay attention to the posix/THP issue that I hit last year: http://libmail.georgialibraries.org/pipermail/open-ils-general/2016-February/012736.html (plus miker's caveats in that thread) |
14:52 |
Bmagic |
berick: nope, it just works |
14:52 |
berick |
csharp: I have that bookmarked! |
14:52 |
csharp |
heh |
14:53 |
Bmagic |
transparent huge pages are turned off for us as well |
14:54 |
Bmagic |
otherwise, we haven't done any of the other things mentioned on that thread from csharp |
14:54 |
miker |
basic testing of 9.6 shows it should work fine, too, fwiw. parallel seq scans! tsearch phrases! faster on big boxen! |
14:55 |
Bmagic |
parallel seq scans sounds nice! |
14:58 |
csharp |
JBoyer: miker: http://pastebin.com/qfL43KAS |
14:58 |
* csharp |
transits himself from office to home - will check back from there |
14:59 |
kmlussier |
miker or others: Is bug 1485374 something that can be merged rather soonish? It has a signoff from Dyrcona, but when I asked about it at the hack-a-way, my recollection was that it wasn't ready to go in yet. |
14:59 |
pinesol_green |
Launchpad bug 1485374 in Evergreen "Use client TZ in the database when supplied to the server" [Wishlist,Confirmed] https://launchpad.net/bugs/1485374 |
15:05 |
|
mmorgan1 joined #evergreen |
15:06 |
miker |
kmlussier: it looks good to me, and will cause testing :) |
15:07 |
miker |
merging will cause testing, I mean |
15:07 |
JBoyer |
This isn't necessarily a discussion I'm eager to have now, but has there ever been any discussion of only ever storing UTC in the db and only applying a TZ on the client? |
15:14 |
|
maryj joined #evergreen |
15:22 |
* csharp |
returns |
15:26 |
JBoyer |
csharp, nothing looks odd to me, we don't have usr.home_ou in our env but I can't imagine that would have this effect. We also don't send item information so that would make them a bit bigger, but it sounds like they're not even getting reacted. |
15:26 |
csharp |
yeah, this is a rollback to what was running pre-upgrade - I haven't dug deep enough yet to see if the issue was happening before |
15:27 |
csharp |
post-upgrade version uses usr.home_ou |
15:29 |
csharp |
nope - definitely not happening pre-upgrade |
15:30 |
csharp |
all of our other A/Ts are fine, btw - it's just this one |
15:40 |
Dyrcona |
@wunder |
15:40 |
pinesol_green |
Dyrcona: BIG LETTERS MEAN BIG IDEAS, AM I RIGHT THOUGHT LEADERS? |
15:40 |
Dyrcona |
@weather |
15:40 |
pinesol_green |
Dyrcona: Methuen, MA :: Partly Cloudy :: 52F/11C | Thursday: Partly cloudy. A shower of rain or wet snow possible. High 52F. Winds W at 10 to 20 mph. Thursday Night: Mainly clear. Low 34F. Winds WSW at 10 to 20 mph. |
15:40 |
JBoyer |
Ahaha, I always forget about that one. |
15:40 |
Dyrcona |
Yeah, that's why it's so hot in here. |
15:41 |
Dyrcona |
Or maybe I still have a fever? |
15:41 |
Dyrcona |
Well, looks like we don't have wunder any more. |
16:18 |
|
JBoyer joined #evergreen |
16:55 |
|
mmorgan joined #evergreen |
17:00 |
pinesol_green |
News from qatests: Test Success <http://testing.evergreen-ils.org/~live> |
17:08 |
|
mmorgan left #evergreen |
21:11 |
pinesol_green |
[evergreen|Jane Sandberg] Docs: authority_control_field script --days-back feature - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=3b36b46> |
23:56 |
|
abowling1 joined #evergreen |