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.org/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=installing_prerequisites_on_gentoo&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/evergreen/+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/evergreen/+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=working/random.git;a=shortlog;h=refs/heads/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=working/random.git;a=commit;h=9d7d2afbfe08580a056a68fc1b1d91b56294cd3b |
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) |