Evergreen ILS Website

IRC log for #evergreen, 2018-08-09

| 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
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.ph​p?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.or​g/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

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