| Time |
Nick |
Message |
| 01:50 |
|
yaymuffins joined #evergreen |
| 02:10 |
|
salios joined #evergreen |
| 02:31 |
|
Notiche15 joined #evergreen |
| 02:48 |
|
CGML2 joined #evergreen |
| 03:15 |
|
majestic6 joined #evergreen |
| 05:48 |
|
infina4 joined #evergreen |
| 06:22 |
|
cncr04s20 joined #evergreen |
| 06:32 |
pinesol |
News from qatests: Failed Running Evergreen browser client build/test - Expected 6 errors but encountered 7. <http://testing.evergreen-ils.org/~live> |
| 06:45 |
|
Numline123 joined #evergreen |
| 06:58 |
|
lorimer15 joined #evergreen |
| 07:07 |
|
agoben joined #evergreen |
| 07:08 |
|
Quokka13 joined #evergreen |
| 07:17 |
|
Dyrcona joined #evergreen |
| 07:38 |
|
dwgreen joined #evergreen |
| 07:38 |
|
bdljohn joined #evergreen |
| 08:06 |
|
collum joined #evergreen |
| 08:16 |
pinesol |
[evergreen|a. bellenir] LP#1785305: Item Status 'Edited By' shows id instead of username. - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=aae6a29> |
| 08:36 |
|
dpearl joined #evergreen |
| 08:40 |
|
badpixel27 joined #evergreen |
| 08:41 |
|
mmorgan joined #evergreen |
| 08:55 |
|
idjit joined #evergreen |
| 09:06 |
|
TheoM joined #evergreen |
| 09:15 |
|
kmlussier joined #evergreen |
| 09:20 |
|
Monkeh10 joined #evergreen |
| 09:21 |
|
lsach joined #evergreen |
| 09:26 |
|
linuxmodder joined #evergreen |
| 09:32 |
|
qassim14 joined #evergreen |
| 09:36 |
|
yboston joined #evergreen |
| 09:38 |
kmlussier |
Are there any objections to backporting bug 1746566 as abneiman requested? I would be willing to merge it if there are no objections. |
| 09:38 |
pinesol |
Launchpad bug 1746566 in Evergreen "wishlist: increase row limits available in specific grids" [Wishlist,Fix committed] https://launchpad.net/bugs/1746566 |
| 09:38 |
abneiman |
kmlussier++ |
| 09:39 |
Dyrcona |
I don't object, but I'm not presently a maintainer. |
| 09:40 |
Dyrcona |
I could try it on 3.0 later. I was planning to look at something else next. |
| 09:40 |
kmlussier |
Also, I don't know who has the authority to do this, but can we upgrade abneiman's LP account to Driver so that she can directly target series/milestones rather than nominate bugs for a series? |
| 09:41 |
* Dyrcona |
will see if he has the power. |
| 09:41 |
bshum |
kmlussier: Done. |
| 09:41 |
Dyrcona |
Aww.... |
| 09:41 |
kmlussier |
bshum++ |
| 09:41 |
Dyrcona |
bshum++ |
| 09:41 |
abneiman |
bshum++ |
| 09:41 |
abneiman |
I promise I won't go mad with power |
| 09:42 |
|
PM joined #evergreen |
| 09:43 |
kmlussier |
I don't think the whole series nomination thing works well in our process. Maybe it makes more sense in other communities. |
| 09:43 |
Dyrcona |
IDK, I think it works OK for us. |
| 09:43 |
Dyrcona |
Not everything can or should be backported. |
| 09:44 |
abneiman |
yeah, this one even was edging a little towards featury, so I checked in-house before nominating it for backport |
| 09:44 |
kmlussier |
Dyrcona: I agree that everything shouldn't be backported. But when I was a lowly Bug Wrangler, I found it frustrating because people typically didn't notice that I had nominated a bug for a series, so it never went anywhere. |
| 09:45 |
kmlussier |
Often times, it was for my own code, where it's recommended that you target it so that it will get review. |
| 09:45 |
Dyrcona |
kmlussier: I find a lot of things go unnoticed. |
| 09:45 |
bshum |
kmlussier: That seems more like an advocate problem to me. To get the bug reviewers and core committers to pay attention. |
| 09:45 |
bshum |
*to ask |
| 09:46 |
kmlussier |
bshum: Well, I certainly don't have problems advocating. |
| 09:46 |
bshum |
Though I say this as a core committer who's often left backport requests to the maintainer's discretion and watched bugs languish till the release went EOL. |
| 09:46 |
bshum |
So.................. |
| 09:47 |
kmlussier |
But if we believe people are knowledgable about community practices to become Bug Wrangers, I figure they probably could be Drivers as well. As far as I can tell, that's the only difference. |
| 09:47 |
bshum |
Yes, in what comes after LP, let's say it'd be good to revisit how we designate bugs for backport |
| 09:47 |
Dyrcona |
Also, if you aren't the original dev, conflicts are not always obvious. |
| 09:47 |
* bshum |
doesn't want to waste more time on LP than necessary since we've been talking about moving off it since when, Vancouver? |
| 09:47 |
Dyrcona |
Yet, we're still on Lp with no real destination in sight. :) |
| 09:48 |
Dyrcona |
@blame lack of resources |
| 09:48 |
pinesol |
Dyrcona: lack of resources stole bshum's tux doll! |
| 09:48 |
bshum |
I remain hopeful :) |
| 09:48 |
kmlussier |
About a year ago, I was going to write up some more detailed guidelines for using LP, but I held off because we were about to move to something new. :) |
| 09:48 |
bshum |
That's actually true. They stopped making the special style of tux doll I like. |
| 09:48 |
bshum |
The new ones aren't as nice looking now :( |
| 09:50 |
Dyrcona |
But, I did push the backport of the cataloging omnibus branch this morning. :) |
| 09:50 |
kmlussier |
Dyrcona++ |
| 09:51 |
Dyrcona |
Drivers an do more than nominate to series. They can also create series, etc. |
| 09:51 |
kmlussier |
Dyrcona: Yes. Wranglers can nominate series. Drivers can create series and then target the bugs to milestones. That's what I was trying to say. |
| 09:52 |
Dyrcona |
Well, I mean in the Evergreen Lp page itself, not just in bugs. |
| 09:54 |
|
jvwoolf joined #evergreen |
| 09:54 |
Dyrcona |
helps to spell the bot's name correctly... :) |
| 09:54 |
|
jvwoolf left #evergreen |
| 09:55 |
Dyrcona |
Ha! |
| 09:55 |
bshum |
He |
| 09:55 |
bshum |
Funny :) |
| 09:55 |
|
jvwoolf joined #evergreen |
| 09:56 |
Dyrcona |
I'm not falling for it this time. |
| 09:56 |
Dyrcona |
:) |
| 09:56 |
kmlussier |
spammers-- :( |
| 09:56 |
Dyrcona |
jvwoolf++ # For making me laugh. |
| 09:57 |
kmlussier |
@karma |
| 09:57 |
pinesol |
kmlussier: Highest karma: "berick" (67), "miker" (65), "Dyrcona" (40), "kmlussier" (39), and "csharp" (35). Lowest karma: "comcast" (-22), "spammers" (-9), "windows" (-4), "oracle" (-4), and "action_triggers" (-3). You (kmlussier) are ranked 4 out of 99. |
| 09:57 |
kmlussier |
spammers still have a long way to go before beating out comcast. |
| 10:01 |
csharp |
comcast-- |
| 10:05 |
* Dyrcona |
just asked if bug 1702978 should be backported and targeted at earlier series. |
| 10:05 |
pinesol |
Launchpad bug 1702978 in OpenSRF "memcache keys containing % fail" [High,Confirmed] https://launchpad.net/bugs/1702978 - Assigned to Jason Stephenson (jstephenson) |
| 10:09 |
kmlussier |
kmlussier-- # Not noticing test failures when testing bug 1775719. |
| 10:09 |
pinesol |
Launchpad bug 1775719 in Evergreen 3.0 "Multiple IndexedDB connections (via tabs) can result in data inconsistency" [High,Confirmed] https://launchpad.net/bugs/1775719 - Assigned to Kathy Lussier (klussier) |
| 10:09 |
* berick |
was just verifying |
| 10:09 |
berick |
waiting for npm |
| 10:10 |
|
khuckins joined #evergreen |
| 10:12 |
berick |
confirmed on 3.0. |
| 10:12 |
* berick |
tries master |
| 10:13 |
Dyrcona |
Well, there's a conflict with 3.0 for bug 1746566, so in my book that is not a clean backport. |
| 10:13 |
pinesol |
Launchpad bug 1746566 in Evergreen 3.1 "wishlist: increase row limits available in specific grids" [Undecided,New] https://launchpad.net/bugs/1746566 |
| 10:14 |
kmlussier |
Dyrcona: Sounds reasonable. |
| 10:17 |
miker |
Dyrcona: re 1702978, the EG-only part can be backported, IIRC. I believe we're using that in production without the opensrf part |
| 10:18 |
Dyrcona |
Adding a % to my username would be a decent test, yes? |
| 10:18 |
berick |
kmlussier: fix en route |
| 10:18 |
berick |
bitten again by phantomjs lagging in support for features |
| 10:18 |
berick |
[].includes(..) in this case |
| 10:18 |
Dyrcona |
@blame phantom.js |
| 10:18 |
pinesol |
Dyrcona: It really IS phantom.js's fault! |
| 10:20 |
miker |
Dyrcona: yes |
| 10:21 |
Dyrcona |
miker: Thanks, that's what I thought. |
| 10:21 |
Dyrcona |
"Just makin' sure...." |
| 10:23 |
Dyrcona |
I'll test it with OpenSRF and Evergreen 3.0 first. |
| 10:24 |
|
yboston joined #evergreen |
| 10:40 |
|
yboston joined #evergreen |
| 10:41 |
jeff |
quick news: as of me setting +z on the channel the other day, unidentified users can now just send a @voice command to channel to have pinesol voice them. |
| 10:42 |
jeff |
(+z makes it so that channel operators like pinesol can see messages from users who wouldn't normally be able to send to channel (includig spammers). |
| 10:43 |
jeff |
this also conveniently works around the issue where such users can't message pinesol directly because of pinesol automatically getting the +R usermode |
| 10:43 |
berick |
can anyone else running rel_3_0 confirm 'grunt test' won't build? wondering if my node version (v8) is incompatible. |
| 10:44 |
berick |
s/won't build/exits immediately/ |
| 10:44 |
berick |
with: TypeError: Cannot read property 'prototype' of undefined |
| 10:44 |
Dyrcona |
with or without the fix for offline mode? |
| 10:44 |
bshum |
berick: From what I remember, node 8 didn't work for me when I was testing it awhile back, but I can try again later. |
| 10:45 |
berick |
Dyrcona: stock rel_3_0 |
| 10:45 |
Dyrcona |
I'm using node 6. |
| 10:46 |
Dyrcona |
Last time I tried node 8 nothing worked, but I got a botched Node upgrade because I didn't do it with the proper method of the week. |
| 10:47 |
Dyrcona |
FWIW, grunt test is working with Node 6.11.3. |
| 10:48 |
berick |
Dyrcona++ |
| 10:48 |
* berick |
continues his monologue on 1775719 |
| 10:51 |
Dyrcona |
yeah. |
| 10:51 |
Dyrcona |
bshum ^^ :) |
| 10:51 |
Dyrcona |
harmless wrong tab. :) |
| 10:52 |
Dyrcona |
And, since I just restarted apache on my test vm I have a question: |
| 10:53 |
Dyrcona |
Has anyone noticed that you have to restart/reload apache after restarting the opensrf.settings service lately? |
| 10:54 |
Dyrcona |
Since 3.0 or possibly the web client, if I restart opensrf.settings and open-ils.cat to pickup new MARC templates, for instance, neither the web client nor XUL will let me login until I restart apache2. |
| 10:54 |
Dyrcona |
That didn't used to happen, IIRC. |
| 10:57 |
kmlussier |
jeff++ # Continued efforts to make #evergreen usable while keeping the spammers out. |
| 11:08 |
|
Christineb joined #evergreen |
| 11:13 |
Dyrcona |
miker: Still around? |
| 11:15 |
|
bsanford joined #evergreen |
| 11:16 |
miker |
Dyrcona: will be back to a keyboard in an hour or so. feel free to ask in advance if useful |
| 11:17 |
Dyrcona |
miker: The current branches for bug 1702978 don't break ABI, correct? |
| 11:17 |
pinesol |
Launchpad bug 1702978 in OpenSRF "memcache keys containing % fail" [High,Confirmed] https://launchpad.net/bugs/1702978 - Assigned to Jason Stephenson (jstephenson) |
| 11:17 |
miker |
correct, iirc |
| 11:18 |
Dyrcona |
OK. I'll tag them for backport. Thanks! |
| 11:22 |
Dyrcona |
gmcharlt: There may be a reason for an OpenSRF 3.0.2 release after all. |
| 11:23 |
gmcharlt |
Dyrcona: i.e., non-ABI-breaking 1702978? |
| 11:23 |
Dyrcona |
yes. |
| 11:23 |
gmcharlt |
if so, I'm game |
| 11:23 |
Dyrcona |
Would it make sense to put an ABI-breaking version in OpenSRF 3.1? |
| 11:24 |
Dyrcona |
Guess that means Evergreen would need a different patch, too? |
| 11:24 |
gmcharlt |
yeah, 3.1 would be when the window opens for ABI-breaking patchs |
| 11:25 |
gmcharlt |
IIRC, Evergreen itself wouldn't need a different patch, but it would need a recompilation upon installing OpenSRF 3.1 |
| 11:25 |
Dyrcona |
OK, makes sense. |
| 11:26 |
jonadab |
Patch would be if you break API compat. |
| 11:26 |
Dyrcona |
I won't push anything until we've had that conversation with miker. |
| 11:26 |
Dyrcona |
I also can't seem to add milestones to the Evergreen part of the bug. |
| 11:28 |
mmorgan |
dbwells: Are you still looking at lp 1562061? |
| 11:28 |
pinesol |
Launchpad bug 1562061 in Evergreen "Marking a Long Overdue transaction Lost adds a second bill to the patron record" [Medium,Confirmed] https://launchpad.net/bugs/1562061 - Assigned to Dan Wells (dbw2) |
| 11:28 |
* mmorgan |
would love to see something happen with that. |
| 11:32 |
dbwells |
mmorgan: I cannot recall off hand where I left off on reviewing that, but I will try to finish reviewing it before the next maintenance releases. Sorry for the delay. |
| 11:33 |
mmorgan |
dbwells: Thanks for looking! |
| 11:35 |
berick |
dbwells: hey, billing question, in generate_fines(), is there a need to limit the search for existing fines on a circ to those created after the circ due date? Or is that simply an optimazation? |
| 11:35 |
berick |
looking at this part of the filter: billing_ts => { '>' => $c->$due_date_method } } |
| 11:35 |
* dbwells |
looks |
| 11:36 |
berick |
CircCommon around 530 |
| 11:40 |
|
gildarts25 joined #evergreen |
| 11:40 |
dbwells |
berick: can't think of a good reason for it. Seems odd of course for an overdue fine to come before the due date, but if that happens, don't see an obvious reason to treat it differently. |
| 11:40 |
berick |
dbwells: thanks. the source of the chaos is the "modify due date" action in the staff client |
| 11:40 |
mmorgan |
berick: dbwells: Could that have some bearing on deposits? |
| 11:41 |
berick |
mmorgan: so the fine generator is only looking at overdues |
| 11:41 |
berick |
not sure if that answers your question, though |
| 11:41 |
mmorgan |
Ah. ok. |
| 11:42 |
* berick |
attempts to recreate then opens a bug |
| 11:43 |
berick |
circs_with_2014_due_dates_in_concerto++ |
| 11:45 |
* dbwells |
does some code spelunking to find the original source of that line (for curiousity's sake) |
| 11:47 |
dbwells |
berick: interestingly enough, it was a deliberate change, "fixing weird edge case of pushing out the due date after fines start to acrue" |
| 11:48 |
dbwells |
commit 04bc4825f5e |
| 11:48 |
pinesol |
dbwells: [evergreen|miker] fixing weird edge case of pushing out the due date after fines start to acrue - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=04bc482> |
| 11:49 |
berick |
oh crazy |
| 11:49 |
berick |
that's an oldie |
| 11:51 |
dbwells |
Actually, I might see why that could be needed, or at least could have once been needed. |
| 11:51 |
miker |
ah! so, the idea was that if you push the due date then we should not start fining again until the due date is hit, again |
| 11:51 |
dbwells |
Without it, once the circ comes overdue the second time, it might fill in the other fines. |
| 11:52 |
miker |
I was thinking about removing/voiding existing fine when berick raised it last night |
| 11:52 |
|
mz`19 joined #evergreen |
| 11:53 |
dbwells |
Right, The "next fine" will probably build in after the previous ones, instead of after the due date. |
| 11:53 |
berick |
ah, ok |
| 11:53 |
berick |
so we need 2 checks, one for what is real total amount billed and one for where do we start billing now. |
| 11:54 |
miker |
hopefully the emergency closing handler will allow staff to avoid this in the future |
| 11:54 |
dbwells |
berick: I think you are right. |
| 11:55 |
berick |
ok, bug confirmed anyway in concerto. it's an edge case, to be sure |
| 11:56 |
berick |
you have to extend the due date before max-fines is set |
| 11:59 |
dbwells |
I feel like we should consider not allowing due date extention once the item is overdue, or only doing so in defined special cases to handle the consequences. There may be more. |
| 12:02 |
dbwells |
One possible way to think of this case is, if it is a pseudo-renew of an overdue item, then max_fines could justifiably be doubled, just as it would be for a real renew (the max fines can accrue on the original circ, then again on the renewed circ). Making this make sense to the user: impossible! :) |
| 12:03 |
|
rlefaive joined #evergreen |
| 12:03 |
berick |
dbwells: absolutely, at some level, what's happening now makes perfect sense. |
| 12:04 |
berick |
just unexpected. |
| 12:05 |
|
jihpringle joined #evergreen |
| 12:07 |
|
rlefaive joined #evergreen |
| 12:09 |
dbwells |
new catchphrase - Evergreen 3: Expect the Unexpected |
| 12:33 |
idjit |
what's the story with websocketd? will opensrf installation step 15 "websockets installation instructions" be transitioning from apache2-websockets to websocketd at some point? |
| 12:33 |
berick |
idjit: they are both in the docs in the LP code |
| 12:33 |
berick |
my hope is apache2-websockets will eventually be replaced, yes |
| 12:33 |
berick |
or replaced w/ 3.1 if enough people sign off on that |
| 12:35 |
Dyrcona |
I think apache2-websockets will have to be replaced unless someone wants to fix the problems with it. |
| 12:35 |
idjit |
cool. i've had good luck with websocketd on different projects. could you point me to the docs on LP? not sure where those live |
| 12:35 |
berick |
idjit: nice! |
| 12:35 |
berick |
they're in the INSTALL file in the root of the repo |
| 12:35 |
idjit |
oh, cool. thanks! |
| 12:35 |
idjit |
berick++ |
| 12:38 |
berick |
more info, including systemd setup in https://wiki.evergreen-ils.org/doku.php?id=dev:websockets:gateway:websocketd |
| 12:39 |
idjit |
thanks! i'll give it a shot |
| 12:51 |
|
James_T17 joined #evergreen |
| 12:51 |
|
Facilitating joined #evergreen |
| 13:01 |
csharp |
dbwells++ # catchphrase |
| 13:05 |
|
thunderrd25 joined #evergreen |
| 13:06 |
|
bdljohn joined #evergreen |
| 13:07 |
Dyrcona |
Too late for the Monty Python reference.... |
| 13:11 |
rhamby_ |
Dyrcona: it's never too late for a monty python reference |
| 13:15 |
csharp |
berick: replying late to your request to comment on bug 1775466 - I'm happy to, but I broke something when assigning a public IP to my test server and workstation registration stopped working - reinstalling the ang6 stuff in hopes that it Just Works™ |
| 13:15 |
pinesol |
Launchpad bug 1775466 in Evergreen "Angular6 Base Application" [Undecided,New] https://launchpad.net/bugs/1775466 - Assigned to Bill Erickson (berick) |
| 13:16 |
csharp |
so I'd like to see it working again before I comment :-) |
| 13:19 |
|
rlefaive joined #evergreen |
| 13:23 |
berick |
csharp++ |
| 13:57 |
csharp |
ugh - stuck on ERROR TypeError: "_co.workstations is null" (ang6) |
| 13:57 |
|
yboston joined #evergreen |
| 14:00 |
|
sscout26 joined #evergreen |
| 14:02 |
* berick |
fires up local ang6 branch |
| 14:03 |
berick |
csharp: on the login page? |
| 14:04 |
csharp |
it's on the ws registration page |
| 14:05 |
berick |
ok, so that's back in angjs land |
| 14:05 |
csharp |
https://paste.fedoraproject.org/paste/T0SqYucvvzFvlWIQ33x53A |
| 14:05 |
csharp |
the gory details |
| 14:06 |
berick |
and to be clear, angjs requires its own updates to work w/ ang6 |
| 14:06 |
berick |
so you have do that npm run build stuff too |
| 14:06 |
berick |
both have to be built and installed |
| 14:06 |
csharp |
yeah, I did both :-/ |
| 14:07 |
csharp |
I just walked back through the install doc for ang6 and updated npm and all the deps |
| 14:07 |
berick |
huh, ok |
| 14:09 |
csharp |
I cleared the browser cache too, but I'm suspicious that it's holding on to something |
| 14:10 |
berick |
hmm |
| 14:10 |
|
badpixel23 joined #evergreen |
| 14:10 |
berick |
csharp: what URL? |
| 14:11 |
csharp |
https://csharp-master.gapines.org/eg2/en-US/staff/admin/workstation/workstations/manage |
| 14:11 |
berick |
huh, that's the ang6 WS admin page |
| 14:11 |
csharp |
yeah |
| 14:12 |
berick |
how did you get there? |
| 14:12 |
csharp |
I logged in and was redirected |
| 14:12 |
berick |
ohhhh |
| 14:12 |
berick |
OK, I need to fix that. |
| 14:12 |
csharp |
ok, whew :-) |
| 14:12 |
berick |
it should send you to the angjs version |
| 14:12 |
csharp |
ok |
| 14:12 |
berick |
the ang6 version works (or it did), but had limited testing |
| 14:13 |
|
khuckins_ joined #evergreen |
| 14:13 |
csharp |
I saw it working yesterday |
| 14:13 |
berick |
csharp: i suggest goign to the angjs version to registring there |
| 14:13 |
csharp |
already there |
| 14:13 |
berick |
yeah, i haven't seen that error, but... yeah |
| 14:14 |
csharp |
ok - it's working again when I go to /eg2/en-US/staff/splash |
| 14:14 |
berick |
ok, great |
| 14:15 |
csharp |
hooray! |
| 14:19 |
berick |
csharp: oh, and I know why you got that error.. result of the server settings code changes |
| 14:19 |
* berick |
will fix that too |
| 14:21 |
csharp |
awesome - thanks! |
| 14:21 |
berick |
yeah, bug confirmed |
| 14:22 |
berick |
fix pushed |
| 14:25 |
berick |
oh boy, we also need to get a tool chain in place for translators for ang6... |
| 14:25 |
berick |
i can create .po files (in theory, still need to confirm). just need to figure out where they go |
| 14:26 |
* berick |
adds to list |
| 14:29 |
|
rlefaive joined #evergreen |
| 14:29 |
|
kmlussier joined #evergreen |
| 14:38 |
|
WSPR17 joined #evergreen |
| 14:41 |
|
rlefaive joined #evergreen |
| 14:43 |
csharp |
berick: to apply the change to the .ts file - does that require rebuilding, etc., or can I just copy it into place? |
| 14:45 |
Dyrcona |
When in doubt, rebuild. :) |
| 14:45 |
Dyrcona |
Shouldn't using --watch take care of that, though? |
| 14:46 |
csharp |
yeah, I'll do that next time |
| 14:47 |
* Dyrcona |
forgets about --watch, too. |
| 14:48 |
|
webpigeon13 joined #evergreen |
| 14:49 |
|
bdljohn joined #evergreen |
| 15:06 |
|
mmorgan joined #evergreen |
| 15:07 |
|
mmorgan joined #evergreen |
| 15:09 |
berick |
csharp: yes, any changes in the eg2 dir require rebuilding (or having --watch running) |
| 15:09 |
|
badseed joined #evergreen |
| 15:17 |
berick |
nice, xliff2po for building po files from ang6 translations is in translation-toolkit, which is already a translator dependency |
| 15:17 |
berick |
er, translate-toolkit |
| 15:18 |
berick |
the xliff files are lot more expressive, hopefully we can use them directly in the near future |
| 15:19 |
Dyrcona |
Well, po files were designed to work with compiled software in the last century, before XML was a thing. |
| 15:20 |
Dyrcona |
Kind of like using MARC for bibliographic record data.... |
| 15:20 |
berick |
*zing* |
| 15:22 |
|
nfburton joined #evergreen |
| 15:32 |
|
yboston joined #evergreen |
| 16:01 |
|
kmlussier joined #evergreen |
| 16:27 |
|
rkta joined #evergreen |
| 16:31 |
|
Dominian20 joined #evergreen |
| 16:36 |
|
annieslmaos joined #evergreen |
| 16:38 |
|
Connection joined #evergreen |
| 16:42 |
|
mmorgan1 joined #evergreen |
| 16:56 |
csharp |
ok - progress on Ubuntu 18.04/newer ejabberd - the problem revealed after enabling debug logging in ejabberd showed "<<"<stream:error><policy-violation xmlns='urn:ietf:params:xml:ns:xmpp-streams'/><text xml:lang='en' xmlns='urn:ietf:params:xml:ns:xmpp-streams'>Use of STARTTLS required</text></stream:error>">>" |
| 16:57 |
|
jvwoolf left #evergreen |
| 16:57 |
csharp |
so then as a test I set "starttls_required: false" in ejabberd.yml and it let opensrf start |
| 16:58 |
berick |
csharp: i assume you've seen bug # 1703411 |
| 16:58 |
berick |
er bug 1703411 |
| 16:58 |
pinesol |
Launchpad bug 1703411 in OpenSRF "OpenSRF: XMPP Non-SASL auth is being phased out" [Medium,Confirmed] https://launchpad.net/bugs/1703411 |
| 16:58 |
berick |
csharp: neat, that was easy :) |
| 16:58 |
csharp |
yeah, I started there, and I enabled legacy auth too |
| 17:00 |
csharp |
so 1) uncomment "mod_legacy_auth: {}" and 2) change "starttls_required" to "false" to get it working |
| 17:00 |
csharp |
but the real answer is to install certs and fix OpenSRF :-) |
| 17:03 |
berick |
yeah |
| 17:03 |
berick |
will take some coding to get the sasl stuff going |
| 17:04 |
berick |
the other Perl jabber libs have code we can steal |
| 17:04 |
berick |
i'm sure there's C stuff out there somewhere |
| 17:06 |
csharp |
I guess for a test server running on a laptop or just not exposed to the WWW it would probably be fine to disable starttls? |
| 17:07 |
csharp |
I don't want the install instructions to recommend anything foolhardy |
| 17:07 |
|
Guest95742 joined #evergreen |
| 17:08 |
berick |
csharp: well, it's the same as what we're doing now |
| 17:10 |
berick |
whether or not we want to do that is a question we have to decide, of course, but the 2 changes you made are identical to how ejabberd has always been used by EG. |
| 17:16 |
|
mmorgan1 left #evergreen |
| 17:27 |
|
nikow2 joined #evergreen |
| 17:40 |
bshum |
csharp: It let OpenSRF start with starttls_required: false ? Interesting... did you actually get math to start though? |
| 17:41 |
bshum |
I got as far as seeing most of OpenSRF start up, but math still failed to start |
| 17:41 |
bshum |
So I couldn't complete a proper test run |
| 17:41 |
bshum |
I'll retest it on my new 18.04 VM later |
| 17:42 |
|
DLange2 joined #evergreen |
| 17:44 |
|
abian0 joined #evergreen |
| 17:48 |
bshum |
Right, dbmath and math fail to start, even with the options set for me the way you describe. That matches my current experiences so far with 18.04 |
| 17:50 |
|
Tourist12 joined #evergreen |
| 17:52 |
berick |
bshum: what about perl services? |
| 17:53 |
bshum |
berick: Those seem to be alive. I haven't installed the rest of Evergreen cause there's some dependency issues I think |
| 17:54 |
berick |
kinda suggests a C / lib problem more than a jabber problem |
| 17:59 |
|
abowling1 joined #evergreen |
| 18:06 |
bshum |
Maybe |
| 18:06 |
bshum |
But the osrfsys.log does give me a bunch of ejabberd error noise |
| 18:06 |
bshum |
So I don't know if it's really respecting the options we asked it to use when switching to legacy auth |
| 18:10 |
pastebot |
"bshum" at 64.57.241.14 pasted "startup logs from 18.04 test server" (321 lines) at http://paste.evergreen-ils.org/13899 |
| 18:11 |
* bshum |
wanders off to dinner, will compare notes with csharp and folks later |
| 18:32 |
pinesol |
News from qatests: Failed Running Evergreen browser client build/test - Expected 6 errors but encountered 7. <http://testing.evergreen-ils.org/~live> |
| 18:56 |
|
lutoma11 joined #evergreen |
| 19:18 |
csharp |
bshum: yeah math and dbmath aren't running :-/ |
| 19:43 |
|
annieslmaos joined #evergreen |
| 20:12 |
|
precise9 joined #evergreen |
| 21:37 |
|
kiera3 joined #evergreen |
| 22:01 |
|
ablackack5 joined #evergreen |
