Evergreen ILS Website

IRC log for #evergreen, 2017-04-11

| 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
05:01 pinesol_green News from qatests: Test Success <http://testing.evergreen-ils.org/~live>
06:40 rlefaive joined #evergreen
07:13 rjackson_isl joined #evergreen
07:22 agoben joined #evergreen
07:51 rlefaive joined #evergreen
07:59 rlefaive_ joined #evergreen
08:10 Brad_ joined #evergreen
08:10 Brad_ I was wondering if anyone out there had a VMWare image that was already made we can use.
08:11 csharp Brad_: at one point a couple of community members were supporting virtualbox images, but its been several years
08:12 csharp Brad_: many people in the channel have installation scripts that make install simpler than just following the instructions is, but they still require some knowledge about what's what in Evergreen and Linux
08:13 Brad_ Is there anyway to get a copy of one of these Scripts, I have knowledge of linux but was having trouble with some of the commands
08:15 csharp Brad_: looks like a couple of people maintain scripts here: http://git.evergreen-ils.org/?​p=working/random.git;a=summary
08:15 csharp Brad_: also, if you want to ask questions about what might be going wrong for you, ask here (and allow time for people to answer) and we can help
08:30 collum joined #evergreen
08:43 mmorgan joined #evergreen
08:58 rlefaive joined #evergreen
09:05 jvwoolf joined #evergreen
09:13 kmlussier joined #evergreen
09:14 dbs On the feedback email, I just pointed someone (Brad I imagine) at the Docker image that Bmagic posted
09:16 kmlussier We also have build scripts at https://wiki.evergreen-ils.org/doku.php​?id=server_installation:semi_automated
09:16 jwoodard joined #evergreen
09:16 yboston joined #evergreen
09:17 dbs yboston: you were missed at the conference!
09:17 * yboston waves
09:20 remingtron_ joined #evergreen
09:20 * kmlussier thinks it might be a good time to start deleting wiki pages like this one - https://wiki.evergreen-ils.o​rg/doku.php?id=vmware:debian
09:21 * dbs has long been an advocate of wiki deletion
09:22 dbs "Last modified: 2009/11/13 15:13 by dbs"
09:23 dbs and now "Deleting outdated content klussier (76.23.161.40) -5.5 KB"
09:23 dbs beat me to it kmlussier++
09:23 kmlussier :)
09:24 * dbs just deleted the 2007 vmware:gentoo page
09:24 kmlussier dbs++
09:26 * csharp is cool with wiki deletions as long as old revisions are visible (which they are)
09:26 kmlussier Heh. I like this one. dbs tried deleting it once in 2010, but it was resurrected a month later - https://wiki.evergreen-ils.org/doku.php?id=inst​alling_prerequisites_on_gentoo&amp;do=revisions
09:27 yboston dbs: hope it went well. It made me sad not to be able to go. This year instead I was aked to go to the Islandora conference in Ontario
09:27 terran_ joined #evergreen
09:28 csharp yboston: we especially missed your IRC overview during lightning talks :-)
09:28 jvwoolf1 joined #evergreen
09:29 yboston I shoudl have done it remotely
09:29 terran_ Yamil! We missed you!
09:29 kmlussier yboston: I missed you during the DIG meeting. I don't think I made documentation sound as exciting as you do.
09:29 Dyrcona joined #evergreen
09:30 yboston kmlussier: next tiem talk lauder, faster, and use your hands
09:30 kmlussier Well, I really missed yboston during the *whole* conference.
09:30 yboston *louder
09:30 kmlussier Yes, I tried the talk loud and fast thing, but it only lasted for about a minute. And then the Internet went down.
09:31 yboston sorry to hear that, no one expects our EG conf badnwidth needs inquisition
09:33 dteston joined #evergreen
09:34 collum_ joined #evergreen
09:48 csharp 813ac365b
09:48 pinesol_green csharp: [evergreen|Mike Rylander] We don't have a matched_attr column anymore, because we're using the fancy expression tree, so test for 901c match directly - <http://git.evergreen-ils.org/?p=​Evergreen.git;a=commit;h=813ac36>
09:53 mmorgan1 joined #evergreen
09:55 jeff ah yes, a 2011 vintage commit. code that survives mostly unchanged to this day. excellent selection, sir!
09:58 csharp jeff++
09:59 csharp jeff: the funny thing is, I have hit this bug before: https://bugs.launchpad.net/eve​rgreen/+bug/1170514/comments/5, but I didn't update our production server, just the test server using acq
09:59 pinesol_green Launchpad bug 1170514 in Evergreen "vandelay.auto_overlay_bib_record discrepancy" [Undecided,Confirmed]
09:59 csharp life is just endless circles
10:09 jeff is vandelay.auto_overlay_bib_record the only affected function?
10:09 csharp jeff: that I know of
10:10 jeff i was looking at that function yesterday as part of my investigations into how we'd make best use of the marc stream importer.
10:10 jeff small world!
10:10 jeff but yes, i can also confirm that we have the outdated function
10:11 jeff i have replaced some other vandelay functions before, but without checking notes i don't know which functions, or the underlying reason for needing to replace them.
10:11 jeff but apparently not this function.
10:11 dbs so what's the situation with merging to master / rel_2_12 now? any special processes beyond the usual double sign-off + test(s)?
10:13 jeff dbs: with the added explicit statement that rel_2_12 would be bugfixes and not new features, I think you've got it correct.
10:14 dbs okay, thanks for the verification :)
10:20 * kmlussier catches up to where we left off with the web team two years ago.
10:24 remingtron__ joined #evergreen
10:28 kmlussier It's never too late to work on two-year-old action items.
10:29 pinesol_green [evergreen|Dan Scott] LP#1680312 Ensure oils_i18n_gettext keys are unique - <http://git.evergreen-ils.org/?p=​Evergreen.git;a=commit;h=9a596f9>
10:29 pinesol_green [evergreen|Ben Shum] LP#1680312: Fix IDs for 950.data.seed-values.sql for i18n - <http://git.evergreen-ils.org/?p=​Evergreen.git;a=commit;h=4ccf38b>
10:31 csharp jeff: I added a branch, FYI: https://bugs.launchpad.net/eve​rgreen/+bug/1170514/comments/7
10:31 pinesol_green Launchpad bug 1170514 in Evergreen "vandelay.auto_overlay_bib_record discrepancy" [Undecided,Confirmed]
10:34 * Dyrcona wonders if make release can make a db upgrade script without making a tarball?
10:43 * jeff looks askance at this email regarding the non-optional disclosure of certain information to conference exhibitors and sponsors
10:44 bshum dbs++ # new test
10:45 jeff is that sharing/disclosure something that attendees agree to when registering on eventbrite? i was not responsible for my registration / signup this year, so i can't pull from my own experience.
10:46 jeff I know it's pretty typical for many conferences (I still get spam and junk mail over a decade later). I just didn't know that this conference was one of those.
10:46 kmlussier jeff: In the past, there was a checkbox on the registration form.
10:47 kmlussier jeff: I don't know about this year, though. Since I was exhibiting, I go through a different registration process.
10:47 bshum dbs / gmcharlt : I haven't finished writing up the steps for setting up POT sync / PO sync, but basically I think we just write in some slight variation on the sources for the branch based on the new bzr target -- lp:~bshum/evergreen/translation-export-2.12
10:47 bshum Though the timing is such that it only does the sync on a daily basis right now I think
10:47 kmlussier We also used to have language as to how that info could be used.
10:48 gsams joined #evergreen
10:50 maryj joined #evergreen
10:50 kmlussier I don't think I saw an attendee list this year, so I don't now if the traditional language was included.
10:51 jeff kmlussier: looks like 2015 was the last year that the Eventbrite registration included that option.
10:51 jeff "We will produce an attendee list for the conference. This list is not to be published on the web or to be used for unsolicited commercial, marketing, or bulk email purposes. If you do not wish to be part of this list, check the box below to opt out."
10:51 jeff and the checkbox was labeled "Please exclude my name, e-mail address, and Twitter/IRC handle from the conference attendee list."
10:51 jeff (i left it unchecked)
10:52 jeff but 2016 and 2017 do not appear to have such an option. just the code of conduct and photography policy.
10:52 kmlussier Yes, if that option/language has been changed, I would like to see it reinstated.
10:53 JBoyer If memory serves, that option likely referred to a printed list in the program or distributed to other attendees. I don't remember if vendors ever came into it. (it
10:53 JBoyer s entirely possible, of course.)
10:54 kmlussier JBoyer: If the vendors are at the conference, though, they would be able to get the list. But was there a list this year? I didn't see one.
10:54 jeff last year the list was sent to attendees as an expiring dropbox link to an xlsx document.
10:54 kmlussier My recollection is that the "This list is not to be published..." language was in the footer of every page of the attendee list. Just to make it clear.
10:55 bshum dbs: I remember encountering https://bugs.launchpad.net/evergreen/+bug/1681864 when I tested the fixes for i18n in db.seed too.  But I found that if I were to remove the resulting PO files (git clean or whatnot since we don't track them) and then rebuild, it would align the expected IDs.  Presumably when doing make_release for new tarballs from git, this would approach would work similarly as long as we worked on clean repositories, but if any leftover files
10:55 bshum were in the way, then yeah... duplicates
10:55 pinesol_green Launchpad bug 1681864 in Evergreen "db-seed.po files need cleanup to remove duplicate IDs from generated localized seed data" [Undecided,Triaged]
10:55 jeff this year i've not seen a list or mention of a list, other than the one that is apparently being given to sponsors/exhibitors which you can only partially opt out of.
10:55 jeff it's just a little unusual, either a departure from past practices, or more transparency about what was always done in the past and we just didn't know about it. dunno!
10:56 jeff I found it unusual enough to mention, but I should stop worrying about it now.
10:58 dbs bshum: yeah if you remove the PO files, you will generate nice clean PO files, but they won't contain any translations?
11:00 bshum dbs: I thought I saw translations...
11:00 bshum I think in git, it tracks the translation, etc. but doesn't assign the IDs to the file
11:00 bshum Till you do the install
11:01 bshum So just msgid and msgstr I thought
11:01 bshum Without ID comments
11:01 remingtron_ joined #evergreen
11:06 dbs bshum: for db-seed, if it doesn't have ID comments, then it can't generate output
11:06 * bshum thinks about that
11:06 dbs po/db.seed/cs-CZ.po has a mix of entries, some with ID comments, some without
11:06 dbs (in git)
11:06 bshum Fun, okay.
11:07 bshum So, huh, I wonder how I managed to fix things.... mysterious.
11:07 bshum Oh well, valid bug then I guess
11:07 bshum :)
11:08 dbs It's probably just that nobody paid attention before. heh.
11:08 dbs bshum++
11:11 bshum Oh, wait, I'm thinking of the output
11:11 bshum the 950.seed-data-values-xx-YY.sql files
11:11 bshum I had to clear those away and rebuild to get better files
11:11 bshum That's where my confusion came from
11:17 Dyrcona hmm... OpenSRF rel_2_5 branch or osrf_rel_2_5_0-rc?
11:18 bshum Guess gmcharlt hasn't pushed the tag for 2.5.0?
11:20 gmcharlt oop
11:20 gmcharlt I've rectified that
11:20 bshum gmcharlt++
11:22 Christineb joined #evergreen
11:23 Dyrcona gmcharlt++
11:26 Bmagic so on an action trigger reacting to the actor.usr table, I want the message_usr_path to be "id" right?
11:26 kmlussier dbs++ bshum++ gmcharlt++
11:28 kmlussier @karma
11:28 pinesol_green kmlussier: Highest karma: "gmcharlt" (8), "berick" (4), "bshum" (3), "Bmagic" (3), and "dbs" (3).  Lowest karma: "oracle" (-6), "ie" (-5), "bzr" (-1), "taggers" (1), and "csharp" (1).  You (kmlussier) are ranked 8 out of 14.
11:30 * csharp suffers from low karma
11:30 csharp comcast--
11:30 csharp comcast--
11:30 csharp comcast--
11:30 csharp @karma
11:30 pinesol_green csharp: Highest karma: "gmcharlt" (8), "berick" (4), "bshum" (3), "Bmagic" (3), and "dbs" (3).  Lowest karma: "oracle" (-6), "ie" (-5), "comcast" (-3), "bzr" (-1), and "taggers" (1).  You (csharp) are ranked 8 out of 15.
11:30 csharp ah.. better
11:31 Bmagic haha
11:31 kmlussier csharp++
11:36 kmlussier parts++
11:36 berick @execute_karma_seed_script
11:36 pinesol_green berick: Have you confirmed your ISBN SPIDs with your service provider?
11:36 Bmagic Anyone have thoughts on that action trigger question?
11:37 Bmagic I get this error: System ERROR: id is not a field on Fieldmapper::actor::user  Please repair the environment.
11:39 bshum Bmagic: Sounds like you don't have the appropriate environment values linked to your A/T event definition
11:39 bshum That's what the error is saying anyways
11:39 Bmagic the message_usr_path is set to "id"
11:40 bshum So I would compare what's in action_trigger.environment for one A/T event_def and check the other
11:40 Bmagic This trigger is reacting to au.expired
11:40 bshum And maybe it was a bad clone
11:40 bshum That's happened to us before with the A/T dojo interface, where we clone an existing A/T definition, make some changes, but the clone didn't carry over the environment
11:40 csharp @who is a bad clone?
11:40 pinesol_green book`_ is a bad clone.
11:41 Bmagic I checked all that. I have the environment
11:41 Bmagic In this case, it's complaining about the column "id" which is clearly apart of actor.usr
11:42 Bmagic I am attempting to implement the message center component. I would like to place a copy of the emailed message in the patron's message center. Do I need to even define the message_usr_path?
11:43 Dyrcona actor.usr is in the environment?
11:44 terran_ Bmagic: I'm not sure what it looks like on the database side, but in the client interface for an action trigger, Message User Path is only needed for Patron Message Center messages (as far as I can tell) and it would be set to usr
11:45 Bmagic terran_: You are using a patron account expiration notice with message center? And you are using "usr" for that field?
11:45 terran_ Yes
11:45 terran_ We're doing one for new account welcome messages too, and have usr in that field
11:46 berick that's.. unexpected
11:46 terran_ heh
11:46 berick au doesn't have a column called "usr"
11:47 jeff my @usr_path = split(/\./, $self->event->event_def->message_usr_path);
11:47 jeff $self->_object_by_path( $self->target, undef, [qw/usr_message usr/], \@usr_path );
11:49 sandbergja joined #evergreen
11:50 terran_ Ugh, never mind, forget what I said.
11:51 terran_ Need more coffee.
11:52 kmlussier left #evergreen
11:52 Bmagic jeff: right - so, when reacting to actor.usr, the message_usr_path should be "id" right?
11:53 terran_ Bmagic: did you try leaving it blank?
11:53 Bmagic I am trying blank now
11:53 maryj_ joined #evergreen
11:54 kmlussier joined #evergreen
11:54 Bmagic ok, so, blank works, but it doesn't put anything in the message center
11:55 kmlussier @coffee terran_
11:55 * pinesol_green brews and pours a cup of Panama La Esmeralda Especial Mario San Jose, and sends it sliding down the bar to terran_
11:55 terran_ Thanks, kmlussier, and keep it coming
11:55 berick it's possible the code just can't use the root object as the message user. as in, it's a bug.  i don't see any examples of that on the seed data.
11:55 Bmagic yeah, that's sort of where my head is going
11:56 berick Bmagic: here's a trick, set the message usr field to billing_address.usr and add the billing_address to the environment
11:56 Bmagic I wonder if you can do something like card.usr
11:57 berick yeah, same idea
11:57 Bmagic I'll give it a whirl
11:57 berick and i suppose card.usr is more likely to have a value
11:58 dbwells So, we need an IDL link path to the user, but we are starting at the user, so there is no obvious path back to itself.  This is probably a design oversight?
11:58 berick dbwells: that's my un-investigated assumption
11:58 Bmagic yay! We have success - card.usr worked!
11:58 berick yay
11:58 terran_ Good to know!
11:58 Bmagic update the docs
11:59 Bmagic lol
12:02 maryj joined #evergreen
12:06 miker we could make "." a special path that means "the event target" for any object_by_path call. that should be a simple code change/addition
12:08 Bmagic miker: sounds doable
12:11 pastebot "miker" at 64.57.241.14 pasted "Bmagic: aye, very" (13 lines) at http://paste.evergreen-ils.org/79
12:11 miker hrm... maybe not, though
12:12 Bmagic lol
12:13 miker yeah, that won't work. but any other special character will ... like, - or @ or ^
12:13 Bmagic miker: it is a corner case I suppose. It seems that these paths need to lead to an actor.usr. Which is only being reacted to in the case of au.expired (and a non-merged feature patron_has_bills)
12:14 JBoyer miker, is the path used as a regex somewhere else?
12:14 gmcharlt a suggestion: …
12:14 gmcharlt ;)
12:15 gmcharlt JBoyer: dots indicate path components in this context
12:15 miker heh... splits on "." though. as in: split(/\./,$path)
12:15 JBoyer Ah, yes, I see.
12:16 miker @ kinda looks like a bull's eye, for target... ?
12:16 pinesol_green miker: Have you confirmed your ISBN SPIDs with your service provider?
12:16 miker pinesol_green: no. no I have not
12:16 pinesol_green miker: Yeah, well, you know, that's just, like, your opinion, man.
12:16 pinesol_green miker: I am only a bot, please don't think I'm intelligent :)
12:16 JBoyer Given how young all of this is, what if we just required a full path to the id? Then you'd use usr.id where there's usr now, and just id in Bmagic's case.
12:17 JBoyer Failing that, I *guess* @ has some precedent in DNS usage at least.
12:17 Bmagic card.usr works yall
12:17 jeff hah. i misread gmcharlt's suggestion as _
12:19 miker yeah, let's just document the message_usr_path requirement if your target is a user object ... it's cached anyway
12:20 miker Bmagic++
12:20 Bmagic JBoyer: "usr" is only there because the database table that is being reacted to, happens to have a column named "usr" in all of the examples. It's possible it will need to be "owner" in the future. Or whatever actor.usr foreign key name people come up with
12:23 JBoyer Bmagic, I know, most (all?) of the examples are from ahr. But requiring an FK relationship isn't ideal because they're not guaranteed. I remember various bugs in the past caused by users not having any cards, and while this wouldn't be that big a deal,  1 user loses their message(s), it's one more thing dependent on an optional relationship.
12:24 Bmagic JBoyer: true dat
12:25 Bmagic That is a good argument
12:25 Bmagic I vote @
12:27 Bmagic rediscovering this https://www.youtube.com/watch?v=KoVO_PFWxqI
12:27 JBoyer (to clarify what I mean by FK's not being guaranteed, I mean *incoming* relationships, like depending on there being a card or aua that points to *you*. I'm not suggesting we use a database where relations are simply suggestions ;) )
12:30 Bmagic "Who put the cat in the cat house?"
12:31 berick JBoyer: that, plus this trick requires fetching the same user account twice from the DB.
12:31 JBoyer although, a quick Q for gmcharlt or miker, I see that there's a ProcessMessage reactor defined but doesn't appear to have been defined (my seed data ahr Message events have NOOP_True for a reactor) is that an oversight or a change in direction?
12:33 gmcharlt JBoyer: ProcessMessage is invoked directly during event and event group processing
12:33 mmorgan joined #evergreen
12:33 gmcharlt e.g., see around line 204 of Trigger/Event.pm
12:34 gmcharlt if chained reactors were a thing, we might have done it slightly differently
12:37 jihpringle joined #evergreen
12:38 * miker dreams of chained modules
12:42 JBoyer gmcharlt, makes sense. Just hoping nothing went sideways in an upgrade.
12:46 mmorgan Bmagic: http://irc.evergreen-ils.org/​evergreen/2015-12-10#i_219081
12:46 * mmorgan walked down the same path!
12:56 Bmagic mmorgan: Ha! That's awesome
13:34 rlefaive joined #evergreen
13:48 kmlussier heh. Thunderbird spellcheck wants to replace ils with eels.
13:49 berick do not want open eels
13:50 berick i'm OK with electric-ils though
13:51 * gmcharlt in fact insists on electricity for ils
13:55 * berick adds to Makefile.install
13:55 * kmlussier now has Electric Avenue stuck in her head for some reason.
14:10 Dyrcona :)
14:18 dbs kmlussier++ # CC-BY-SA licenseing - hope you don't get that joke from too many other people
14:19 kmlussier dbs: Nope! It's just you so far. :)
15:23 maryj joined #evergreen
15:36 rlefaive joined #evergreen
15:43 Jillianne joined #evergreen
15:48 khuckins joined #evergreen
15:53 kmlussier joined #evergreen
16:00 khuckins_ joined #evergreen
16:25 bshum berick: Thinking about what you said about a fresh install for https://bugs.launchpad.net/evergreen/+bug/1680624 got me thinking we didn't rip out bower install from the Makefiles for Ubuntu Trusty, Ubuntu Xenial, and Debian Jessie
16:25 pinesol_green Launchpad bug 1680624 in Evergreen "Consolidate JS dependency install with npm" [Undecided,Confirmed]
16:25 bshum I'll ponder that when I get a fresh VM built again
16:26 bshum (with more disk space this time... *big sigh*)
16:27 berick bshum: oh yeah, i forgot about that
16:28 bshum And apparently Debian.common has something there for wheezy too
16:28 bshum Minor details
16:28 * berick adds a comment to the bug
16:44 jeff oh, hah.
16:44 jeff [comment redacted]
16:59 mmorgan left #evergreen
17:01 pinesol_green News from qatests: Test Success <http://testing.evergreen-ils.org/~live>
17:02 bshum dbs++ # new test is successful!  so says the test run above :)
17:08 kmlussier Yay!
17:08 kmlussier dbs++
19:54 genpaku joined #evergreen
20:04 dbs whee
21:23 dteston joined #evergreen
21:29 bshum Ubuntu xenial clean install went nicely with the bower npm changes.
21:35 pinesol_green [evergreen|Dan Scott] LP#1680624 Consolidate package dependencies into package.json - <http://git.evergreen-ils.org/?p=​Evergreen.git;a=commit;h=8c7000a>
21:35 pinesol_green [evergreen|Dan Scott] LP#1680624 angular-ui-bootstrap stopped shipping minified files - <http://git.evergreen-ils.org/?p=​Evergreen.git;a=commit;h=4a068d0>
21:35 pinesol_green [evergreen|Dan Scott] LP#1680624 Remove bower packaging bits - <http://git.evergreen-ils.org/?p=​Evergreen.git;a=commit;h=c66d632>
21:43 dbs bshum++ # thanks!
21:49 bshum Of course, right after I do that
21:49 bshum I think about the automated builder
21:49 bshum http://git.evergreen-ils.org/?p=work​ing/random.git;a=shortlog;h=refs/hea​ds/collab/phasefx/wheezy_installer
21:50 bshum And the fact that the test run tomorrow needs updating
21:50 dbs well that's the random.git one, yeah, I can poke that
21:50 dbs really the automated builder should just use the make targets that y'all painstakingly added rather than its own workarounds
21:50 bshum +1, for sure
21:57 dbs okay, ripped the basic bits out
21:57 dbs http://git.evergreen-ils.org/?p=wo​rking/random.git;a=commit;h=9d7d2a​fbfe08580a056a68fc1b1d91b56294cd3b
21:57 bshum dbs++
21:59 * dbs notes with amusement that the browser staff client section also has a hard-coded nodejs install in the installer scripts
22:00 kmlussier joined #evergreen
22:06 khuckins_ joined #evergreen
23:11 dbs also updated the planet evergreen theme to be a little less ugly; now the big EG logo just links back to https://evergreen-ils.org
23:47 dbs (kudos to bshum for the suggestion)

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