Evergreen ILS Website

IRC log for #evergreen, 2019-02-08

| 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
03:42 jeff joined #evergreen
03:44 yar joined #evergreen
05:01 pinesol News from qatests: Testing Success <http://testing.evergreen-ils.org/~live>
07:03 agoben joined #evergreen
07:07 rjackson_isl joined #evergreen
07:44 tlittle joined #evergreen
07:57 JBoyer csharp, since your update to 3.2 has anyone noticed that when opening records from search results the 245c isn't displayed, but if you load a record directly (or reload a search result record) it finally appears?
07:58 JBoyer I ask because that is what's happening, so I wondered if you've heard. :)
07:59 JBoyer We're having the same issue, and I've noticed that CW/MARS does not have that problem (because they're on < 3.2?)
08:15 tlittle JBoyer Is that happening in both MARC View and MARC Edit? I just tried, and the 245c loads in both for me
08:15 JBoyer Record detail display, the marc view/edit tabs are fine.
08:16 tlittle Ah, okay. Let me try that one
08:17 tlittle Nope, it's loading for me
08:20 JBoyer That's annoying. I searched for adventure time islands and clicked record 5861077 in your catalog, in my browser I see the 245 a and p, but the c doesn't appear until I remove the query string from the url and load it again.
08:20 bos20k joined #evergreen
08:22 csharp sounds like a job for Elaine!
08:24 JBoyer I don't think it has anything to do with cataloging if that's what you mean.
08:25 csharp no - she's the best at ferreting out these sorts of OPAC searching issues/bugs
08:25 csharp and she'll stay on it until it's fixed :-)
08:25 JBoyer Ah. Yes, in that case I think she'll have fun with this one.
08:32 tlittle Yep, Elaine found it! I read your question incorrectly. Sorry about that
08:35 csharp yeah
08:35 JBoyer tlittle++ # thanks for looking though!
08:36 csharp <LAW AND ORDER THUM THUM> *CONFIRMED*
08:36 JBoyer csharp++
08:36 tlittle Hah :D
08:42 mmorgan joined #evergreen
08:46 Dyrcona joined #evergreen
09:01 jonadab joined #evergreen
09:01 Dyrcona joined #evergreen
09:09 csharp soo... how important is the content of Open-ILS/src/eg2/package-lock.json?  I'm trying to apply a commit where there are too many conflicts in that file to resaonbly address and it's like 12K lines long :-/
09:10 csharp conflicts are mostly package version differences and maybe some re-ordering of lines?
09:12 JBoyer I'm not certain we're using it to its fullest effect; it shouldn't hurt anything to just use the version from the newer branch.
09:12 csharp JBoyer: that's what I was hoping someone would say :-)
09:13 JBoyer (I specifically prefer newer because of things like the rxjs fix berick helped me with recently)
09:14 aabbee joined #evergreen
09:14 csharp @band add Ticky Box
09:14 pinesol csharp: Band 'Ticky Box' added to list
09:15 tlittle csharp++
09:15 csharp @praise [band]
09:15 * pinesol The Carrollton Contingency is kind and patient to newbies
09:15 csharp @blame [band]
09:15 pinesol csharp: Carrollton High School Trojan Marching Band stole bshum's tux doll!
09:15 csharp pinesol: enough with the Carrollton stuff, huh?
09:15 pinesol csharp: What we have here is a failure to communicate.
09:16 csharp pinesol: obvs
09:16 pinesol csharp: http://xkcd.com/1739/
09:17 csharp ooh - git checkout --theirs
09:17 * csharp didn't know about that
09:18 miker JBoyer: difference between (configurable) display fields and (hard coded) xpath-in-templates record display methods. removing the query disables highlighting, which disables use of display fields for display. I have a goal to move all the way to display fields, regardless of highlighting
09:18 csharp thank you stack exchange! https://stackoverflow.com/a/22544803/1692794
09:18 csharp er.. overflow, I mean
09:19 JBoyer miker, thanks, I should have wondered about that since I noticed PINES has highlighting enabled, but it didn't initially occur to me since we have hl disabled in config.tt2.
09:19 miker csharp: if you're working with my branch for email/print, you could just drop the changes to the json files (both). if you don't, and if I can find some time early next week, I'll push something to remove the changes to those files
09:20 miker (I've learned since that branch went up that we should basically avoid touching those files, even though npm really likes to whack them around, apparently)
09:20 csharp miker: yep - that's the one - I'll just use my newfound git skillz to address it for now
09:20 Dyrcona csharp: You can also specify -s theirs when merging for a similar effect.
09:20 csharp Dyrcona: nice
09:21 JBoyer git checkout --theirs, git commit --mine, git blame --everyone-else, git rm :/*
09:21 Dyrcona :)
09:21 Dyrcona JBoyer++
09:21 csharp @quote add <JBoyer> git checkout --theirs, git commit --mine, git blame --everyone-else, git rm :/*
09:21 pinesol csharp: The operation succeeded.  Quote #192 added.
09:21 miker JBoyer: to clarify, disabling highlighting doesn't disable display field use, just disables whether we use the highlighted version of display field data
09:22 JBoyer Ah, got it.
09:22 miker Dyrcona: that would pick the wrong direction for other conflict resolution, if there is any, right?
09:23 miker (not that there are any here, necessarily, but in the general case...)
09:23 Dyrcona miker: It resolves merge conflicts favoring what comes from the remote branch, IIRC.
09:24 Dyrcona I never use it, but it's there.
09:25 miker oh, well, we don't actually want that in this case
09:26 miker csharp would want -s ours, I think, because he /doesn't/ want my changes to the angular json files (IIUC)
09:27 Dyrcona Well, -s theirs does what is in that stackoverflow comment from the beginning and without more context, I assumed that's what csharp wants. :)
09:28 csharp oh - right - I do want "ours"
09:28 mmorgan JBoyer: we noticed the missing 245c, too, on 3.1. We added a row to config.metabib_field to make it both a search and display field.
09:29 csharp @praise ours
09:29 * pinesol And ours raised the report up on high, saying O Lord, bless this thy circ report, that with it thou mayst blow thine enemies to tiny bits, in thy mercy.
09:29 Dyrcona And, unrelated: I think Email::Stuffer is going to make the tricks in Lp 1532236 more difficult.
09:29 pinesol Launchpad bug 1532236 in Evergreen "Evergreen should allow for HTML formatted action trigger emails" [Wishlist,Confirmed] https://launchpad.net/bugs/1532236
09:30 JBoyer mmorgan, ooh, could you send me any more detail on that? Things don't look odd anywhere else?
09:32 * miker hereby registers his eteranal -1 vote for html email support
09:32 Dyrcona :)
09:33 Dyrcona I don't mind it if it is done correctly, with a HTML part and plain text part.
09:33 * csharp has mixed feelings too
09:33 * JBoyer would like the ability to design attrative html mails, but only if there's a usable plaintext alt-part for the plaintexters.
09:33 csharp +1
09:35 * Dyrcona is going to try websocketd 0.3.1 on his test vm.
09:35 JBoyer my understanding is that it's perfectly possible even now, but you've got to insert the multipart delimiter yourself and write both segments manually, yes? I'm not expecting our SendEmail reactor to pull out the plaintext as part of the process.
09:35 mmorgan JBoyer: Yes, I can get you more detail. There were issues with the punctuation around those fields, too, which we (not me personally ;-)) addressed in tt2 files.
09:35 JBoyer mmorgan++
09:36 Dyrcona JBoyer: That is correct and that's basically what is done in the above Lp branch. It only adds `unless(....)` on the ends of some header mangling lines.
09:37 JBoyer ++
09:38 Dyrcona I'm not sure what approach to take at the moment. I'll have to do some experimentation. I'd like to leave the possibility for multi-part emails to work like that.
09:38 Dyrcona Maybe I should just merge that bug fix with my branch and "fix" 3 bugs in one branch? :)
09:39 JBoyer HTMAILOMNIBRANCH
09:39 Dyrcona :)
09:41 Dyrcona The problem that I'm mainly working on is a/t can't send email when versions of Encode.pm >= 2.83 are installed.
09:46 jamesrf joined #evergreen
09:48 pastebot "mmorgan" at 64.57.241.14 pasted "metabib_field entry for 245|c" (4 lines) at http://paste.evergreen-ils.org/10003
09:48 mmorgan JBoyer: ^^
09:48 mmorgan Also see bug 1806724
09:48 pinesol Launchpad bug 1806724 in Evergreen "Display field strangeness on some 3.1+ systems" [Medium,Confirmed] https://launchpad.net/bugs/1806724
09:50 mmorgan The changes mdriscoll posted in comment #6 fixed the highlighting problems we had because we don't use stemming.
09:50 JBoyer mmorgan++
09:50 mmorgan mdriscoll++
09:50 JBoyer We fixed the highlighting issues we were seeing by turning it off. It hasn't yet been missed. :)
09:51 mmorgan :)
09:51 mmorgan Highlighting is definitely nice to have when it works predictably!
09:51 JBoyer mdriscoll++ # finding fixes for local issues
09:53 mmorgan That fix would likely apply to any system that has turned off stemming.
10:00 jvwoolf joined #evergreen
10:30 berick joined #evergreen
10:34 collum joined #evergreen
11:18 miker ugh... anyone else get checksum failures during npm install fom time to time?
11:20 Dyrcona Don't recall checksum errors, thought I have had other kinds of "fun" from time to time.
11:20 Dyrcona npm--
11:31 Christineb joined #evergreen
11:33 Stompro @weather 56560
11:33 pinesol Stompro: Moorhead, MN :: Clear :: -20F/-29C | Wind Chill: -40F/-40C | Friday: Abundant sunshine. High -8F. Winds WNW at 5 to 10 mph. Friday Night: Partly cloudy this evening, then becoming cloudy after midnight. Low -22F. Winds NE at 5 to 10 mph. | Updated: 40m ago
11:39 mmorgan Brrr. At least the sun is shining!
11:50 berick didn't know numbers went that low
11:53 jeff "abundant sunshine"
11:54 sandbergja joined #evergreen
11:54 Dyrcona @weather
11:54 pinesol Dyrcona: Methuen, MA :: Overcast :: 44F/7C | Wind Chill: 37F/3C | Friday: Showers this morning with clearing during the afternoon hours as drier air moves in on gusty breezes. High 46F. Winds W at 20 to 30 mph. Chance of rain 60%. Higher wind gusts possible. Friday Night: Windy with a few clouds. Colder. Low 21F. Winds W at 20 to 30 mph.
11:54 Dyrcona Crazy....
11:56 Dyrcona So far email experiments are not working out. We can't MIME Encode the headers with Encode and have the email work, not with Email::Send nor with Email::Sender, at least not without a lot of extra code.
11:56 Dyrcona And Email::Stuffer isn't gonna work for us.
11:58 jeff I'm willing to give it some extra code. Hardest part will likely be handling existing templates.
11:59 jeff I'm pretty sure we are averse to breaking things and also averse to "you must examine all of your templates or things will break", but maybe I'm wrong.
12:01 Dyrcona Yeah. Well, the hard part may be parsing the header fields.
12:01 Dyrcona Looks like we're going to need to parse out recipient email addresses while MIME encoding the headers.
12:03 jeff I'm.... not interested in doing that. I'd prefer to use a library that handles that part for us. It might change how we pass the email addresses to the reactor, though.
12:04 montgoc1 joined #evergreen
12:04 nfBurton joined #evergreen
12:06 jihpringle joined #evergreen
12:07 nfBurton Is there a script in Evergreen to start|stop|restart the server as a whole? I noticed our Evergreen doesn't start up after a reboot on the server and am looking to automate it. But the one on the docs I found is for 2.1 and osrf_ctl is depreciated
12:07 nfBurton Or if someone has a script they want to share :)
12:08 nfBurton Sorry, to restart osrf service and apache. Not the server
12:11 Dyrcona nfburton: You know how to start services with osrf_control? Modify the old script to use the new command syntax.
12:12 nfBurton Yeah. Trying to create a shell script for server boot but the osrf_control only being usable by opensrf is tripping me up
12:12 nfBurton cause then apache needs to start as a different user too
12:12 Dyrcona jeff: tbh, I'm not interested in any of this. It's 2019. Email should be a solved problem.
12:13 Dyrcona nfBurton: Apache will start as root, then switch to opensrf. You want it to start after opensrf services.
12:14 Dyrcona As of osrf_control, with proper environment it should start as any user, however you may need to switch to opensrf for it to function properly. That said, I have never attempted to write a system startup script for OpenSRF. I've always just done it manually because I know what a hassle it can turn into. :)
12:15 Dyrcona There are many examples in Evergreen where we're doing it wrong. This is one of them.
12:26 Stompro I need to look into setting up Evergreen startups using systemd sometime.  It seems like it will handle all the dependancys for startup order pretty easily.  I'm using a sysv init script now that works reasonably well, I don't remember who I stole it from though.
12:27 nfBurton Yeah. I just set the openils/bin prefix to my user account so I could do everything from there
12:27 Dyrcona I was thinking that systemd *should* make this easier, despite my antipathy toward its overall design.
12:28 Dyrcona I do everything as the opensrf user. I make that user during o/s installation, except on Debian Stretch where someone requested it as a reserved user name.
12:35 Stompro nfBurton, here it the sysv init script we use on our utility server.  I think I still start the EDI translator manually https://gist.github.com/stompro/​d0a12c26e8cecd1c287f100dadfa591f
12:38 Stompro I really want to add checks that delay until remote services are up and running, like the database server, but haven't gotten around to it.
12:42 nfBurton That looks far more modern than the wiki has. Thanks!
13:02 Stompro nfBurton, your welcome.
13:03 nfBurton Stompro++
13:03 nfBurton Although it has the depreciated osrf_ctl in it as well...
13:03 nfBurton :(
13:06 * Dyrcona might have an email solution.
13:13 mmorgan jeffdavis++ csharp++ # privacy waiver
13:24 Dyrcona Gotta love how the Encode module maintainers "fix" bugs that lead to breakage. Twice, at least, we've been bitten by such changes.
13:52 Dyrcona jeff: Mail::Address works for the address headers, so we don't have to parse much of anything.
13:53 Dyrcona Email::Address seems to work, too, both using Email::MIME instead of Email::Simple, so we don't reinvent any wheels.
14:07 jeffdavis Hm, adding tags to a bug isn't working for me in LP.
14:17 bshum jeffdavis: That's happened to me sometimes when my LP session was timed out and it wasn't telling me right.  Signing out of LP and signing back in might help
14:17 bshum (aka, restart it!  :D)
14:19 jeffdavis Thanks for the suggestion. No luck, though. *shrugs*
14:19 bshum Maybe LP is just having an off day then
14:20 * bshum blames it on the other guy
14:20 Dyrcona @blame The Other Guy
14:20 pinesol Dyrcona: The Other Guy crafted the perfect SHA-1 collision, breaking Git
14:40 mmorgan jeffdavis: I often forget to hit the checkmark when tagging bugs, which makes them not stick.
14:41 jeffdavis ah, I think it just doesn't like underscores in tags - I was trying to use "auth_proxy"
14:53 Dyrcona You also have to be in a special group to make new tags, but I think jeffdavis is in that group already.
14:54 Dyrcona I seem to recall Lp not liking certain characters in tags.
15:09 Dyrcona And, Email::MIME and friends allow you to make nonconforming email messages, according to RFC 2822.
15:14 Dyrcona If you pass a list to $email->header_set and family, you get multiple header entries.
15:15 Dyrcona The address headers are only allowed to appear once per message, though my limited testing indicates multiple To: fields "works" even though the message is strictly illegal.....
15:15 Dyrcona It's never as simple as you think. :)
15:16 Dyrcona It's email. How complicated could it be? :)
15:16 * jeff laughs
15:17 jeff ...mirthlessly
15:20 Dyrcona Ok. So I can encode the fields just fine, but the UTF-8 is not interpreted as such on the other end.
15:21 Dyrcona Both Thundird and Gmail are not liking my E accent aigue...
15:21 Dyrcona É
15:21 Dyrcona Gmail shows that. And, I have no idea what you're seeing. :)
15:23 Dyrcona maybe that's i may fault...
15:23 Bmagic nfBurton: ansible for restarting services post boot: https://github.com/mcoia/eg-docker/blob/master/doc​ker_builds/generic-dockerhub/restart_post_boot.yml
15:24 Dyrcona So, it was...
15:24 Dyrcona My test script wasn't decoding the message, first. SendEmail.pm is already doing that, so that's why it worked in one place but not the other.
15:26 Dyrcona So, looks like I have a fix for bug 1801163.
15:26 pinesol Launchpad bug 1801163 in Evergreen "SendEmail A/T reactor broken for recent version of Encode::MIME::Header" [High,In progress] https://launchpad.net/bugs/1801163 - Assigned to Jason Stephenson (jstephenson)
15:31 Dyrcona And, I *think* I see a different bug....
16:07 * Dyrcona prepares for a flood of email. :)
16:08 Dyrcona "Its aliiive!!!"
16:10 Dyrcona Two-hundred thirty-eight emails. I guess that works.
16:11 mmorgan Dyrcona++
16:23 Bmagic does this still apply in Evergreen > 2.12 ? http://docs.evergreen-ils.org/2​.1/html/relevancyrankings.html
16:40 miker Bmagic: yes, in 2.12. it starts getting complicated in 3.0+ (progressively so with each version)
16:41 Bmagic Thought so! Im looking into making the 245a in a title search more weighty
16:45 Bmagic this is starting to make sense http://docs.evergreen-ils.org/3.1/​_virtual_index_definitions_2.html
16:48 Bmagic I also see a "fix me" at the top of https://wiki.evergreen-ils.org/do​ku.php?id=documentation:indexing
16:58 bdljohn joined #evergreen
17:02 pinesol News from qatests: Testing Success <http://testing.evergreen-ils.org/~live>
17:02 bdljohn left #evergreen
17:04 mmorgan left #evergreen
17:16 jvwoolf left #evergreen
18:33 sandbergja joined #evergreen

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