| Time |
Nick |
Message |
| 03:58 |
|
NawJo joined #evergreen |
| 04:20 |
|
NawJo joined #evergreen |
| 05:01 |
pinesol_green |
News from qatests: Test Success <http://testing.evergreen-ils.org/~live> |
| 05:52 |
|
genpaku joined #evergreen |
| 06:20 |
|
genpaku joined #evergreen |
| 07:14 |
|
kmlussier joined #evergreen |
| 07:16 |
|
rjackson_isl joined #evergreen |
| 07:22 |
|
agoben joined #evergreen |
| 07:46 |
pinesol_green |
[evergreen|Galen Charlton] LP#1517596: add missing template file for webstaff patron merge - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=512dd0c> |
| 08:41 |
|
abowling1 joined #evergreen |
| 08:45 |
|
mmorgan joined #evergreen |
| 08:54 |
|
genpaku joined #evergreen |
| 09:02 |
|
genpaku joined #evergreen |
| 09:04 |
graced |
good morning #evergreen |
| 09:04 |
graced |
@coffee |
| 09:04 |
* pinesol_green |
brews and pours a cup of Ethiopia Harrar, and sends it sliding down the bar to graced |
| 09:13 |
|
yboston joined #evergreen |
| 09:13 |
JBoyer |
Good morning graced |
| 09:13 |
graced |
good morning, JBoyer |
| 09:14 |
tsbere |
Woohoo, I made it to work. My 15 minute drive only took just over an hour this morning. <_< |
| 09:15 |
JBoyer |
tsbere, That's pretty awful, weather or just traffic? |
| 09:16 |
tsbere |
JBoyer: Multi-alarm fire between me and the office that started last night, causing them to shut down the only major road between my house and the office and screwing up traffic because most people didn't know before they hit the "you can't go this way" signs/police cars. |
| 09:16 |
JBoyer |
That does sound like a major pain, for all involved. |
| 09:16 |
tsbere |
For added fun, my primary "bypass most traffic issues" alternate route dumps back onto said major road *at the location of said fire* and was unusable. |
| 09:17 |
tsbere |
And the "go a bit further and dump back out onto the major road much further down" route had an accident backing things up for miles too |
| 09:18 |
JBoyer |
(very) occasionally it can be nice to take the scenic route. Sounds like that's enough scenery for a couple years, heh. |
| 09:19 |
JBoyer |
graced, I don't suppose you know anything about the room block that isn't on the list do you? (like availability Friday) Still haven't gotten my travel auth and was just curious. :/ |
| 09:19 |
tsbere |
I ended up having to go the (still slow/backed up) "go the wrong way to pick up the highway" route. Which, by the time I got there, had an accident just after the ramp. |
| 09:20 |
graced |
jboyer: we have some availability left for Friday - we just increased our room block |
| 09:20 |
graced |
But we may still run out soon |
| 09:21 |
JBoyer |
I thought we'd have run out already since the last time I heard about it. That's good. Hopefully they'll get a move on... |
| 09:21 |
graced |
We're working with the hotel to increase the rooms available on Friday, not sure if we'll be successful |
| 09:22 |
JBoyer |
graced++ |
| 09:23 |
graced |
thanks for asking a question I could answer :) |
| 09:24 |
|
terran joined #evergreen |
| 09:34 |
|
maryj joined #evergreen |
| 09:35 |
|
mmorgan1 joined #evergreen |
| 09:36 |
csharp |
has anyone worked up any report templates/other solutions for Edelweiss Analytics? |
| 09:38 |
rjackson_isl |
tsbere souds like an "exciting" commute :( Indiana had 60-80 mph winds overnight with a few uncomfirmed twisters. Only a couple non-functioning lights for me to deal with |
| 09:39 |
tsbere |
rjackson_isl: The commute itself was boring as most of it my car decided to not even keep the engine running. <_< |
| 09:39 |
rjackson_isl |
so a quite ride except for maybe a few blaring horns? |
| 09:39 |
JBoyer |
csharp, My answer is obviously no, but I'm curious what that is. A collection development service like CollectionHQ, or something else? |
| 09:40 |
tsbere |
rjackson_isl: Didn't even get horns blaring. |
| 09:41 |
csharp |
JBoyer: yeah, it's like CollectionHQ |
| 09:41 |
csharp |
I'm planning to work up reports views to add to the IDL and let the library handle the rest |
| 09:42 |
csharp |
I just wondered if anyone had already done something like that :-) |
| 09:43 |
JBoyer |
Depending on how *much* like CHQ it may not be that easy. :/ There are reasons that extract is server side only currently. :/ |
| 09:44 |
csharp |
JBoyer: it's pretty much a customized item list, bib list, and hold list in CSV format |
| 09:45 |
* dbs |
had a nice one-hour walk in driving snow this morning, first with the kids because buses were cancelled, then to work. I feel alive and happy :) |
| 09:46 |
JBoyer |
As is CHQ, but I didn't think through what you said entirely; if you make a customized reporting view you may be able to address any issues so I'm not trying to be a big downer on that front. No good way to get it without a custom view OR server side pulls. |
| 09:48 |
kmlussier |
dbs: They canceled the buses but not the schools? |
| 09:48 |
* kmlussier |
had a nice, leisurely walk down her stairs to get to work this morning. |
| 09:50 |
csharp |
dbs++ |
| 09:51 |
csharp |
JBoyer: yeah, my attempts to hack existing reports sources are failing badly |
| 09:52 |
JBoyer |
Depending on how similar they are you could look at the CHQ extract stuff, if all you have to do is rearrange the output fields that's quick work. :) |
| 09:54 |
csharp |
JBoyer++ # I'll have a look |
| 09:54 |
jeff |
assuming that this is something that you want to automate, i would strongly suggest avoiding trying to use the reporter. |
| 09:55 |
dbs |
kmlussier: yeah, they have only ever cancelled school once here |
| 09:55 |
csharp |
jeff: it's actually something I want the libraries to handle completely if I can swing it |
| 09:55 |
jeff |
csharp: it's all manual on the transmission to Edelweiss? |
| 09:56 |
jeff |
csharp: i.e., you have to log in to a web site and upload a file that way, to the point that to automate it would require web scraping? |
| 09:56 |
csharp |
jeff: it can be automated server-side, but we reeeally don't like doing that - it creates potential for a lot of fragile out-of-band stuff |
| 09:56 |
csharp |
like, say, CollectionHQ used to be |
| 09:57 |
csharp |
we only had one library using it and they finally dumped it |
| 09:59 |
* csharp |
looks forward to the fm_IDL.d/ approach to fieldmapper stuff |
| 09:59 |
JBoyer |
conf.d++ |
| 10:00 |
|
_bott_ joined #evergreen |
| 10:01 |
rjackson_isl |
dbs: I think perhaps our snow is finished here except for flurries - early spring here we come! |
| 10:01 |
|
maryj_ joined #evergreen |
| 10:02 |
csharp |
our snowday this year was just a whole bunch of cold rain |
| 10:02 |
csharp |
climate_change-- |
| 10:02 |
csharp |
trees and bushes are fully in bloom and it's March 1 |
| 10:03 |
berick |
csharp: i have to mow the lawn this weekend :( |
| 10:03 |
csharp |
me too! |
| 10:03 |
rjackson_isl |
we aren't quite that far along but there are some flowers out and the willows have leaves sprouting |
| 10:04 |
csharp |
nice bike-riding weather though :-) |
| 10:06 |
rjackson_isl |
it was good for visiting the local eagle's nest Sunday AM with the frozen temps (mud was also frozen for the hike) |
| 10:09 |
pinesol_green |
[evergreen|Jeff Davis] LP#1668816: Prevent Internal Server Error in OPAC when logged-in user has no card - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=d2ff144> |
| 10:12 |
|
abowling joined #evergreen |
| 10:46 |
terran |
FYI, bug squashing is going great this week: https://docs.google.com/spreadsheets/d/1RPR5gIL02EiIvsg5vDKLs40rgw0Daqy4_TRWPlqU0WY/edit?usp=sharing |
| 10:46 |
terran |
bugtesters++ |
| 10:47 |
terran |
The bottom-right list on that spreadsheet has new or updated patches that are ready to test |
| 10:49 |
kmlussier |
I would like to load remingtron's new patch on mlnc3, but I don't know when I'll get to it. |
| 10:51 |
pinesol_green |
[opensrf|Bill Erickson] LP#1667091 Remove non-SSL websockets sample configs - <http://git.evergreen-ils.org/?p=OpenSRF.git;a=commit;h=2fc52cf> |
| 10:52 |
gmcharlt |
now cutting the OpenSRF 2.5 RC |
| 10:53 |
* csharp |
wishes he had the bandwidth this week to participate in bug squash week :-/ |
| 10:56 |
kmlussier |
gmcharlt++ |
| 10:58 |
* dbs |
is with csharp |
| 11:02 |
|
rlefaive joined #evergreen |
| 11:17 |
gmcharlt |
OK, OpenSRF 2.5.0-rc is now available |
| 11:18 |
gmcharlt |
I expect not to merge any substantive changes between now and general release on 3/14, barring any fixes of showstopper bugs or fixes for installation issues |
| 11:18 |
|
khuckins joined #evergreen |
| 11:22 |
|
Dyrcona joined #evergreen |
| 11:23 |
csharp |
gmcharlt++ |
| 11:23 |
JBoyer |
gmcharlt++ |
| 11:25 |
Dyrcona |
gmcharlt++ # /me jumps on the bandwagon without knowing why, exactly. ;) |
| 11:26 |
csharp |
Dyrcona: 11:17 < gmcharlt> OK, OpenSRF 2.5.0-rc is now available |
| 11:26 |
Dyrcona |
I thought so. Got the email. |
| 11:26 |
csharp |
:-) |
| 11:26 |
Dyrcona |
I'll have to give a whirl. |
| 11:26 |
Dyrcona |
it.. |
| 11:27 |
csharp |
I WILL GIVE A WHIRL TO IT |
| 11:28 |
JBoyer |
csharp++ |
| 11:31 |
Dyrcona |
:) |
| 11:31 |
Dyrcona |
So, this is interesting: git push origin +master:master |
| 11:32 |
Dyrcona |
remote: error: denying non-fast-forward refs/heads/master |
| 11:32 |
Dyrcona |
Not related to Evergreen, but to git. |
| 11:33 |
Dyrcona |
All I did was amend the top commit message. |
| 11:33 |
Dyrcona |
git insists that I pull first. |
| 11:33 |
JBoyer |
Not having looked it up, is there something about the + in +master that is special, or is this just a different branch name? |
| 11:34 |
Dyrcona |
It does a force push. |
| 11:34 |
Dyrcona |
git push --force origin master gives the same message. |
| 11:34 |
Dyrcona |
Maybe this is new in git 2.11? |
| 11:35 |
Dyrcona |
The remote is running 2.11. |
| 11:35 |
* Dyrcona |
tries Google. |
| 11:35 |
gmcharlt |
there's a long-standing Git setting that can deny non-FFs |
| 11:35 |
gmcharlt |
so maybe a config issue with the remote? |
| 11:35 |
|
mllewellyn joined #evergreen |
| 11:35 |
|
mllewellyn left #evergreen |
| 11:35 |
gmcharlt |
e.g., repos controlled by gitolite can be easily configured that way |
| 11:37 |
Dyrcona |
Not new. Just denyNonFastForwards, probably. Maybe it defaults to true, now? |
| 11:38 |
Dyrcona |
gmcharlt++ |
| 11:38 |
Dyrcona |
Huh. It's explicitly on in this repo. |
| 11:38 |
Dyrcona |
Maybe that's always been the default.... |
| 11:39 |
Bmagic |
has anyone got he xul staff client in another language? |
| 11:39 |
Bmagic |
/he/the |
| 11:40 |
Dyrcona |
Bmagic: I have seen it in Armenian. It's pretty. |
| 11:40 |
Bmagic |
how did you get that to compile? |
| 11:40 |
Dyrcona |
Just installed i18n and changed the language. |
| 11:40 |
Dyrcona |
You should have i18n from a regular tarball. |
| 11:40 |
Bmagic |
hmmmmm, oh, I need to use git |
| 11:41 |
Dyrcona |
If you're building from git, you need to do a little extra dance. |
| 11:41 |
Bmagic |
so, I have done some of the prep work from https://wiki.evergreen-ils.org/doku.php?id=dev:release_process:evergreen:2.8 |
| 11:42 |
Bmagic |
but maybe I need to do the whole thing, and create the tarball... then extract that and compile the staff client from there? |
| 11:42 |
|
mmorgan joined #evergreen |
| 11:42 |
Bmagic |
or perhaps, all I am missing are the files from translation-export... need to be copied into the Evergreen git tree somewhere? |
| 11:43 |
Dyrcona |
Bmagic: cd build/i18n ; make install_all_locales |
| 11:43 |
Bmagic |
I didn't do that |
| 11:44 |
Dyrcona |
You can do the translation-export if you want to update the translations. |
| 11:45 |
Dyrcona |
You do that before the big make install, IIRC. |
| 11:45 |
Bmagic |
ok, this might be what I was missing... trying it now |
| 11:47 |
Bmagic |
lots of warnings about missing strings |
| 11:47 |
Dyrcona |
Yeah, that's normal. |
| 11:47 |
Dyrcona |
Unfortunately. |
| 11:47 |
Dyrcona |
It still works. |
| 11:47 |
Bmagic |
figured |
| 11:48 |
Bmagic |
that command needs to be mentioned here probably https://wiki.evergreen-ils.org/doku.php?id=backend-devel:i18n |
| 11:49 |
Dyrcona |
So, 5 of my repos have denyNonFastforwards set in config, and the others don't. |
| 11:50 |
Dyrcona |
Must have been defaults in the version of git when I made the repos. These are not managed by gitolite. |
| 11:51 |
Dyrcona |
Bmagic: Yeah, maybe. |
| 11:51 |
Dyrcona |
You don't need to do it if installing from a tarball because make-release will do it for you unless you use the option to skip it. |
| 11:51 |
Dyrcona |
make-release ought to be documented somewhere, too. |
| 11:52 |
* Dyrcona |
considered doing a presentation on make-release at the conference. |
| 11:53 |
Bmagic |
when I compile the xul client - I change to Open-ILS/xul/staff_client |
| 11:53 |
Bmagic |
and run an additional make install command with AUTOUPDATE_HOST STAFF_CLIENT_STAMP_ID STAFF_CLIENT_BUILD_ID rigrelease LOCALE |
| 11:54 |
Dyrcona |
I don't think you have to recompile the staff client, just do the sudo make install STAFF_CLIENT_[whatever]=somethingelse : |
| 11:55 |
Dyrcona |
I usually use STAFF_CLIENT_VERSION others use STAFF_CLIENT_STAMP_ID |
| 11:57 |
Bmagic |
Dyrcona++ |
| 11:57 |
Bmagic |
Dyrcona++ # cd build/i18n ; make install_all_locales fixed my problem! |
| 11:58 |
Dyrcona |
I used to do it on my vms. |
| 12:07 |
Bmagic |
well, thank you again, I beat my head on that for hours yesterday |
| 12:09 |
* dbs |
apologizes for all of the i18n weirdness |
| 12:09 |
|
sandbergja joined #evergreen |
| 12:10 |
jeff |
dbs++ i18n with quirks > no i18n :-) |
| 12:11 |
Bmagic |
it's great to see the other language on the familiar staff client. Pretty cool |
| 12:11 |
Bmagic |
dbs++ |
| 12:12 |
bshum |
@quote search armenian |
| 12:12 |
pinesol_green |
bshum: 2 found: #20: "<bshum> The staff client looks pretty in Armenian" and #5: "<senator> the armenian regression sounds like a..." |
| 12:12 |
bshum |
@quote get 20 |
| 12:12 |
pinesol_green |
bshum: Quote #20: "<bshum> The staff client looks pretty in Armenian" (added by Dyrcona at 09:50 PM, November 16, 2011) |
| 12:12 |
bshum |
:D |
| 12:13 |
Dyrcona |
@quote get 5 |
| 12:13 |
pinesol_green |
Dyrcona: Quote #5: "<senator> the armenian regression sounds like a spy novel" (added by bshum at 03:44 PM, February 22, 2011) |
| 12:13 |
Dyrcona |
heh. that was a real bug. |
| 12:13 |
dbs |
Bmagic: iirc some of the inputs might not work as expected for things like money or date/time values -- you'll want to test those |
| 12:14 |
Bmagic |
good to know |
| 12:14 |
Bmagic |
good thing this experiment was for bug squashing week :) |
| 12:20 |
|
jihpringle joined #evergreen |
| 12:23 |
|
brahmina joined #evergreen |
| 12:27 |
miker |
berick: soooooo.... on a scale from 1 to 10, what's the likelyhood that we'll be able to get hatch running on chromebooks? ;) |
| 12:29 |
dbs |
heh, or tablets or phones :) |
| 12:29 |
berick |
miker: don't know. can they run java? |
| 12:29 |
dbs |
no |
| 12:33 |
miker |
haven't tried it, but: https://forum.xda-developers.com/hardware-hacking/chromebooks/how-to-install-java-8-chrome-os-crouton-t3110778 |
| 12:35 |
miker |
which is basically "no" ... |
| 12:36 |
berick |
what can chromebooks do natively? |
| 12:38 |
* berick |
has a feeling hatch is going to evolve a lot over the next year |
| 12:38 |
dbs |
berick: there's a NativeClient that you can build extensions around (C/C++) |
| 12:39 |
dbs |
Hatch is for a) printing and b) some persistence IIRC? |
| 12:39 |
berick |
moving file I/O into the extension, altnernate print implementations, cloud print shim |
| 12:39 |
berick |
dbs: yeah |
| 12:39 |
dbs |
basic extensions are html/css/javascript with little UI: https://developer.chrome.com/extensions |
| 12:39 |
dbs |
NaCl is more powerful - https://developer.chrome.com/native-client |
| 12:41 |
dbs |
we might want to put our heads together on what service workers can do these days, for persistence purposes at least |
| 12:42 |
kmlussier |
Also offline circ, right? |
| 12:42 |
berick |
kmlussier: that's (for me) included in 'persistence' |
| 12:43 |
berick |
a place to put stuff |
| 12:43 |
kmlussier |
As we look at ways that hatch might evolve over the next year, could we also consider what would need to be done to get it working with Firefox? |
| 12:44 |
berick |
+1 to that |
| 12:46 |
dbs |
service worker + indexeddb would handle most of the needs for Chrome + Firefox support today, the only nasty bit is that from time to time the browser might "clean that up" for you |
| 12:47 |
dbs |
but https://developer.mozilla.org/en-US/docs/Web/API/IndexedDB_API/Browser_storage_limits_and_eviction_criteria looks pretty promising on the "persistent" storage side. |
| 12:59 |
|
Jillianne joined #evergreen |
| 13:05 |
|
terran joined #evergreen |
| 13:05 |
kmlussier |
@coin |
| 13:05 |
pinesol_green |
kmlussier: tails |
| 13:10 |
|
rlefaive joined #evergreen |
| 13:20 |
berick |
dbs: we're using NativeMessaging today, which lets us bypass all browser restrictions, and in theory works in FF too. the main limitation of course being that the native code has to run on the machine. |
| 13:21 |
berick |
we could write alternate natvie code (python, perl, go, whatever) to match the host |
| 13:21 |
berick |
.. c++, c# (/me names all the langs) |
| 13:24 |
|
khuckins_ joined #evergreen |
| 13:26 |
|
rlefaive joined #evergreen |
| 13:28 |
jeff |
apparently despite their interface's calendar coloring the days as "available", Friday is not actually available at the conference hotel. |
| 13:52 |
|
maryj joined #evergreen |
| 14:09 |
* dbs |
offers up bug 1584891 as low-hanging i18n-friendly fruit for testing |
| 14:09 |
pinesol_green |
Launchpad bug 1584891 in Evergreen "marc_export -i gives incorrect record length in the leader when call numbers include UTF8 characters" [Undecided,Confirmed] https://launchpad.net/bugs/1584891 |
| 14:13 |
Dyrcona |
UTF-8 in call numbers... I've seen it. All I can say is, "Yuck." |
| 14:14 |
terran |
jeff: apparently we hit the contract numbers for the Friday room block, but we are trying to get more - you might want to contact joe gtownlibrary.net for followup |
| 14:15 |
jeff |
terran: thanks! I started by e-mailing the named contact for the hotel on the reservation confirmation. |
| 14:15 |
terran |
good news is, that means we're getting good registration numbers :) |
| 14:15 |
jeff |
indeed! |
| 14:16 |
terran |
Joe Knueven at Georgetown is the local conference committee chair who is working with the hotel |
| 14:16 |
dbs |
Dyrcona: it's more the Copy Locations than anything else, but nice to have our bases covered |
| 14:18 |
Dyrcona |
dbs: It causes problem for SIP2, too. I shared branches. |
| 14:37 |
Bmagic |
Has anyone integrated "Pay Anywhere" services into Evergreen? Or played with it? |
| 14:42 |
terran |
Bmagic: not us, but we'd be interested to know if someone else does. We're still trying to convince all of our libraries to take the online payments through the OPAC. |
| 14:45 |
|
krvmga joined #evergreen |
| 14:46 |
krvmga |
what does it mean when i try to cherry pick and get the message "fatal: bad revision" |
| 14:50 |
berick |
krvmga: maybe do a 'git fetch' or 'git fetch --all' |
| 14:57 |
kmlussier |
Dev meeting in three minutes! |
| 14:59 |
bshum |
wheezy-- # making my life more annoying by the minute |
| 15:02 |
kmlussier |
Does anyone want to volunteer to run the meeting? |
| 15:04 |
graced |
*crickets* |
| 15:05 |
* kmlussier |
can do it, but is still recovering from the outreach meeting |
| 15:06 |
kmlussier |
#startmeeting 2017-03-01 Developer meeting |
| 15:06 |
pinesol_green |
Meeting started Wed Mar 1 15:06:03 2017 US/Eastern. The chair is kmlussier. Information about MeetBot at http://wiki.debian.org/MeetBot. |
| 15:06 |
pinesol_green |
Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. |
| 15:06 |
pinesol_green |
The meeting name has been set to '2017_03_01_developer_meeting' |
| 15:06 |
kmlussier |
#topic Introductions |
| 15:06 |
kmlussier |
#info kmlussier is Kathy Lussier, MassLNC |
| 15:06 |
abowling |
#info abowling is Adam Bowling at Emerald Data Networks |
| 15:06 |
terran |
#info terran is Terran McCanna, Georgia PINES |
| 15:07 |
remingtron |
#info remingtron is Remington Steed, Hekman Library (Calvin College) |
| 15:08 |
remingtron |
looks like it's just us Padawans today |
| 15:08 |
kmlussier |
Yeah, I'm wondering if this is one of those meetings where it might be better to postpone. |
| 15:08 |
gmcharlt |
#info gmcharlt Galen Charlton, EOLI |
| 15:08 |
* kmlussier |
reads EOLI, but sees Aioli |
| 15:09 |
* gmcharlt |
commissions a recipe ;) |
| 15:10 |
gmcharlt |
if we want to go with a compressed agenda, I have a suggestion |
| 15:10 |
berick |
#info berick Bill Erickson |
| 15:10 |
gmcharlt |
namely, what are the top priorities for testing for the upcoming releases? |
| 15:12 |
kmlussier |
OK, well the agenda is fairly short as it is, so let's note that the one action item is deferred and move on to updates where we can talk about testing for 2.12. |
| 15:12 |
gmcharlt |
#link https://wiki.evergreen-ils.org/doku.php?id=dev:meetings:2017-03-01#new_business |
| 15:12 |
kmlussier |
Thanks, I was just about to do that! It's been a while since I took the meeting controls. |
| 15:12 |
kmlussier |
#topic Action items from last meeting |
| 15:13 |
kmlussier |
#info kmlussier has not yet solicited feedback on release process documentation. |
| 15:13 |
kmlussier |
#action kmlussier will post to open-ils-dev soliciting feedback on the release process documentation |
| 15:13 |
kmlussier |
I should have a little more time on my hands in a couple of weeks. |
| 15:13 |
kmlussier |
#topic OpenSRF 2.5 updates |
| 15:14 |
kmlussier |
gmcharlt? |
| 15:14 |
gmcharlt |
#info OpenSRF 2.5.0-rc released today |
| 15:14 |
gmcharlt |
#info OpenSRF 2.5.0 will be released on 14 March |
| 15:14 |
gmcharlt |
#info Testing requested, in particular for installation issues on supported platforms |
| 15:14 |
gmcharlt |
and that's it, unless there are questions. |
| 15:16 |
kmlussier |
Any questions for gmcharlt? |
| 15:16 |
* gmcharlt |
answers in advance: 42 |
| 15:16 |
kmlussier |
:) |
| 15:17 |
kmlussier |
#topic Evergreen 2.12 updates |
| 15:17 |
kmlussier |
#info 2.12 beta was released last week |
| 15:18 |
kmlussier |
Thanks to everyone who helped get the release out and to those who helped with the issues with the automated tests. |
| 15:18 |
kmlussier |
We're getting a lot of bug fixing activity done this week with Bug Squashing Week. |
| 15:18 |
kmlussier |
terran++ |
| 15:20 |
kmlussier |
One thing I would like to do for the end of bug squashing week is to see if there are any volunteers in the community who might want to go through some of the use cases we have on the wiki just to make sure the release is in good shape. |
| 15:20 |
kmlussier |
I think I tried something similar for the 2.10 release without much luck, but maybe we'll get some takers. |
| 15:21 |
kmlussier |
I do have a question regarding translations. Eva had contacted me a while ago to see if we might be able to do the translation dance again at the .1 release to give translators more time to get their translations in. |
| 15:21 |
kmlussier |
Is that something that would be doable? |
| 15:22 |
bshum |
kmlussier: As long as we don't merge any new string changes or run any POT updates for the templates, then the PO files won't drift any further than what's in Launchpad |
| 15:22 |
bshum |
So that is doable, until we start merging new features or syncing the templates again |
| 15:23 |
bshum |
Or like how gmcharlt and others fixed some typos in the git branch and touched the change in all the templates too |
| 15:23 |
kmlussier |
bshum: Oh, so if start merging things for the 3.0 release before the .1 release, it could be a problem? |
| 15:23 |
bshum |
kmlussier: It'll only be an issue if we run the template sync job. If we skip that only do the PO sync, then I think it'll be fine to merge new stuff too |
| 15:23 |
gmcharlt |
bshum: would it be worth trying to set up per-series translations in LP? |
| 15:23 |
terran |
I know Eva is looking at the Czech translation in 2.12 this week |
| 15:24 |
bshum |
gmcharlt: It's probably possible, but I didn't look too much into it given our overall weak support for translations historically, and just not having enough eyes on the subject |
| 15:24 |
bshum |
And I think we'd need to engage dbs into that discussioin |
| 15:24 |
bshum |
Since we're using his bzr branches to do the PO sync updates |
| 15:24 |
gmcharlt |
yeah... but I'm inclined to push a bit to see if we can make it happen |
| 15:25 |
bshum |
It's been hard enough keeping master up to date, than to worry about specific past releases :) |
| 15:25 |
bshum |
But the new round of translators have been especially dedicated :) |
| 15:25 |
kmlussier |
Can we do an action item, then, to investigate the feasibility of doing per-series translations? |
| 15:25 |
gmcharlt |
indeed |
| 15:25 |
terran |
translators++ |
| 15:25 |
gmcharlt |
yeah, I'll take an action item |
| 15:26 |
kmlussier |
#action gmcharlt to investigate the feasibility of doing per-series translations |
| 15:26 |
gmcharlt |
just to set some expectations, unless it turns out to be really easy, I'm not contemplating going any earlier than 2.12 |
| 15:26 |
kmlussier |
Understood |
| 15:26 |
kmlussier |
Does anyone have any questions or things they want to add about the 2.12 release? |
| 15:27 |
* kmlussier |
pushes the cat off the keyboard. |
| 15:27 |
gmcharlt |
:) |
| 15:28 |
kmlussier |
#topic Search development and minimum Postgres requirements |
| 15:28 |
kmlussier |
miker wasn't able to make the meeting today to provide more detail on this than I can give. |
| 15:29 |
kmlussier |
MassLNC has contracted with Equinox to do the development to eliminate two-stage work in Evergreen. |
| 15:29 |
gmcharlt |
one implication: we should consider deprecating Pg < 9.4 with the 2.12 release |
| 15:29 |
kmlussier |
The work will need to use functions that are only available in Postgres 9.4 or above. |
| 15:30 |
bshum |
Oh. Good to know... |
| 15:30 |
bshum |
Cause I was just engaging Dyrcona in my schemes to update Wheezy to use PG 9.3 from the PG community repo. maybe we should set that to PG 9.4? :D |
| 15:31 |
bshum |
And make similar adjustments for Ubuntu Trusty |
| 15:31 |
kmlussier |
gmcharlt: Deprecate 9.4 now? Does that give the community enough time. |
| 15:31 |
gmcharlt |
no, deprecate 9.3 now |
| 15:31 |
gmcharlt |
e.g., with 2.12, say: |
| 15:31 |
kmlussier |
heh |
| 15:31 |
gmcharlt |
- minimum required version is 9.3 |
| 15:31 |
gmcharlt |
- recommended minimum version is 9.4 |
| 15:31 |
kmlussier |
Sorry, that's what my head said. My fingers were thinking differently. |
| 15:31 |
bshum |
Fun times. |
| 15:31 |
gmcharlt |
- 9.3 will be deprecated |
| 15:32 |
gmcharlt |
er, _is_ deprecated |
| 15:32 |
* bshum |
will always be +1 to moving forward with PG versions |
| 15:32 |
|
Bmagic joined #evergreen |
| 15:32 |
gmcharlt |
and I think there's enough time |
| 15:33 |
gmcharlt |
reasoning: if somebody is planning to upgrade Pg anyway to install 2.12, there's no reason they can't go straight to 9.4 |
| 15:33 |
kmlussier |
OK, so right now, we are saying in the docs that 9.3 is minimum. But we should probably be saying the 9.3 is deprecated and 9.4 is recommended, correct? |
| 15:33 |
gmcharlt |
yeah |
| 15:33 |
bshum |
This new search development is intended for 2.next or 3.0, right? |
| 15:33 |
kmlussier |
I'm obviously +1, because I think this development is important for search. |
| 15:33 |
kmlussier |
Yes |
| 15:34 |
kmlussier |
Does anyone have concerns with this plan? |
| 15:34 |
kmlussier |
Or, since we have just a few people here today, should we send something to the dev list ahead of time to get more feedback? |
| 15:34 |
remingtron |
dev list is a good idea |
| 15:34 |
gmcharlt |
worth writing to dev reqardless |
| 15:34 |
terran |
I can't imagine PINES would have a problem with it |
| 15:35 |
kmlussier |
OK, I can take an action item to write something to the dev list then. |
| 15:35 |
* gmcharlt |
files wishlist bug: authority-record-controlled spellchecking applied to #evergreen |
| 15:36 |
kmlussier |
#action to send message to dev list regarding plan to deprecate Postgres 9.3 and recommend 9.4 for the 2.12 release with plans to remove support for 9.3 in 2.next. |
| 15:36 |
kmlussier |
Sigh...let me try that again. |
| 15:36 |
terran |
(terran just finds out we're already on 9.4) |
| 15:37 |
kmlussier |
#action kmlussier to send message to dev list regarding plan to deprecate Postgres 9.3 and recommend 9.4 for the 2.12 release with plans to remove support for 9.3 in 2.next. |
| 15:37 |
kmlussier |
Any other questions or thoughts on 9.3/9.4 support in Evergreen? |
| 15:38 |
jeff |
I would recommend looking at postgresql EOL dates vs expected Evergreen EOL dates as you consider "minimum" vs "recommended", etc. |
| 15:38 |
bshum |
PG 9.4 ends in December 2019 -- https://www.postgresql.org/support/versioning/ |
| 15:39 |
bshum |
So that should be fine for Evergreen.next purposes. But should look further out I guess as time moves on |
| 15:39 |
bshum |
PG 9.3 for Sept 2018, also fine I think |
| 15:39 |
kmlussier |
9.3 is end of life in September 2018. |
| 15:39 |
bshum |
For 2.12 |
| 15:40 |
kmlussier |
So 2.12 EOL is March 2018 |
| 15:40 |
kmlussier |
With security updates going through to September 2018 |
| 15:40 |
bshum |
June? 3 months, or is it really six? |
| 15:41 |
jeff |
in the past, we had at least a few Evergreen releases whose "minimum" postgresql version reached EOL before the Evergreen release reached EOL. We know those things ahead of time, usually -- so that might be one of the facts that we could state in the README where we recommend postgresql versions, so that the person making a selection at that time has the "pg x.y is deprecated as of this release and will actually reach EOL before this release of Evergreen |
| 15:41 |
bshum |
Either way, plenty of coverage |
| 15:41 |
kmlussier |
bshum: You're right. It's 3 months. https://wiki.evergreen-ils.org/doku.php?id=dev:release_process:schedule |
| 15:41 |
gmcharlt |
sounds like an excellent conversation to continue on open-ils-dev |
| 15:42 |
jeff |
gmcharlt++ indeed :-) |
| 15:42 |
kmlussier |
OK, moving on then. |
| 15:42 |
kmlussier |
#topic Starting RM selection for next release |
| 15:42 |
gmcharlt |
so, I have a couple thoughts here |
| 15:42 |
gmcharlt |
namely, that getting started sooner rather than later would be good |
| 15:42 |
kmlussier |
+1 |
| 15:43 |
gmcharlt |
so, here's my proposal: I can send out the traditional call for nominations tomorrow |
| 15:43 |
gmcharlt |
with deadline of 3/31 |
| 15:43 |
gmcharlt |
and voting to occur in-person and online during the afternoon dev hackfest on 4/6 |
| 15:43 |
gmcharlt |
another option would be to compress that timeline a bit |
| 15:44 |
gmcharlt |
with the idea that the next RM would be elected during the week of the 27th |
| 15:44 |
gmcharlt |
i.e., after 2.12.0 |
| 15:44 |
gmcharlt |
thoughts on either option (or any other)? |
| 15:45 |
kmlussier |
I know we've traditionally voted at the conference, but I prefer an earlier timeline to give the RM as much time as possible to prepare for the release. |
| 15:46 |
bshum |
Is the plan to make this next one 2.13 or 3.0? Because I think extra lead time sounds good either way :) |
| 15:47 |
kmlussier |
3.0 is what we were planning. |
| 15:47 |
berick |
i'm also in favor of extra lead time. wouuld be cool if the RM was decided before the conf. |
| 15:47 |
kmlussier |
I don't think anything has changed significantly with the web client to make us consider holding off on the big release. |
| 15:47 |
gmcharlt |
agreed |
| 15:47 |
jeff |
I think either timeline sounds reasonable. Practically, the RM may not have THAT much more lead time depending on their travel plans and such, but every bit helps, right? :-) |
| 15:47 |
gmcharlt |
well, the next RM will be literally chained to their desk, so... |
| 15:48 |
gmcharlt |
wait, did I say that part out loud? |
| 15:48 |
kmlussier |
gmcharlt: Wait, I wasn't supposed to be chained to my desk for the last one? |
| 15:48 |
kmlussier |
Now you tell me. |
| 15:48 |
gmcharlt |
:) |
| 15:49 |
gmcharlt |
more seriously, I think there's a small but real factor that the lag period between prev-RM and next-RM discourages merges to master during that period |
| 15:49 |
gmcharlt |
so I'm also in favor of a shorter tiemframe |
| 15:49 |
kmlussier |
gmcharlt: Shall I give you an action item for the kicking off the process under the shorter timeframe? |
| 15:49 |
gmcharlt |
kmlussier: sure! |
| 15:49 |
berick |
gmcharlt: i have the same concerns re: lag |
| 15:51 |
kmlussier |
#action gmcharlt to send out a call for RM nominations tomorrow, with an election planned for the week of March 27 |
| 15:51 |
kmlussier |
Anything else on the RM nomination process? |
| 15:52 |
kmlussier |
Does anyone need any feedback on new features under development or have anything else they want to discuss? |
| 15:52 |
kmlussier |
Going once, going twice... |
| 15:53 |
kmlussier |
#endmeeting |
| 15:53 |
pinesol_green |
Meeting ended Wed Mar 1 15:53:08 2017 US/Eastern. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) |
| 15:53 |
pinesol_green |
Minutes: http://evergreen-ils.org/meetings/evergreen/2017/evergreen.2017-03-01-15.06.html |
| 15:53 |
pinesol_green |
Minutes (text): http://evergreen-ils.org/meetings/evergreen/2017/evergreen.2017-03-01-15.06.txt |
| 15:53 |
pinesol_green |
Log: http://evergreen-ils.org/meetings/evergreen/2017/evergreen.2017-03-01-15.06.log.html |
| 15:53 |
jeff |
kmlussier++ |
| 15:53 |
bshum |
kmlussier++ # wrangling |
| 15:53 |
gmcharlt |
kmlussier++ |
| 15:53 |
terran |
kmlussier++ |
| 15:54 |
remingtron |
kmlussier++ |
| 15:54 |
kmlussier |
While we were in the meeting, I saw Eva's update to bug 1629078. |
| 15:54 |
pinesol_green |
Launchpad bug 1629078 in Evergreen "Untranslated parts of web staff client" [Undecided,Triaged] https://launchpad.net/bugs/1629078 |
| 15:54 |
kmlussier |
I was wondering if anyone had any insight on what the problem is there. |
| 15:55 |
bshum |
Well... |
| 15:56 |
kmlussier |
hmmm...it's not clear to me if they tried the patch berick provided. |
| 15:57 |
bshum |
I don't know about that part. But the three bugs they also linked to have issues of their own |
| 15:57 |
bshum |
It's messy |
| 15:58 |
bshum |
I think I tried berick's patch briefly but do not recall the exact results. I can try it again later when I have more time to refocus, kmlussier |
| 15:59 |
bshum |
Trying out webstaff translation was weird to me personally due to complications from https://bugs.launchpad.net/evergreen/+bug/1560805 |
| 15:59 |
pinesol_green |
Launchpad bug 1560805 in Evergreen "webclient: locale picker does not work well" [Undecided,New] |
| 15:59 |
bshum |
So just changing the locale doesn't always work unless you know how to set the cookie better. |
| 15:59 |
* bshum |
runs along for now, will think more on it again |
| 16:06 |
Dyrcona |
Sorry I missed the meeting. I had to repair the roof. |
| 16:07 |
kmlussier |
Dyrcona: You're on vacation. You shouldn't be attending dev meetings anyway! |
| 16:07 |
kmlussier |
Though, attending a dev meeting is probably preferable to repairing a roof. |
| 16:08 |
mmorgan |
Repairing a roof is also not a traditional way of spending vacation. |
| 16:08 |
* csharp |
awakes from helpdesk-induced stupor |
| 16:08 |
mmorgan |
Though I've certainly spent similar vacations. |
| 16:08 |
csharp |
so, there was a dev meeting... sorry :-/ |
| 16:08 |
Dyrcona |
Well, the family comes in and says there are shingles in the yard.... |
| 16:09 |
csharp |
oh boy |
| 16:10 |
Dyrcona |
And, there are high winds today and rain expected tonight. |
| 16:11 |
Dyrcona |
On the Pg 9.3 front on wheezy, we get the apt.postgresql.org repo to add easily, but libdbi won't build with libpq-dev from the community repo. |
| 16:11 |
Dyrcona |
That's as far as I got before climbing up the ladder. |
| 16:12 |
Dyrcona |
I have not had this problem on the production vms I've made with wheezy, but then, I've stuck with the 9.1 client from Debian. |
| 16:14 |
Dyrcona |
I *think* bshum and I are both using working/collab/dyrcona/wheezy-pg93-testing which is based on working/user/bshum/wheezy-pg93-testing which he said has stuff he lifted from csharp. :) |
| 16:16 |
Dyrcona |
The error, for anyone still paying attention, is configure: error: Invalid PostgreSQL directory - libraries not found. |
| 16:17 |
csharp |
hmm |
| 16:19 |
csharp |
so why still on wheezy? (not judging, just askin' ;-) ) |
| 16:21 |
Dyrcona |
wheezy is still supported, and C/W MARS is using it, but not for too much longer. |
| 16:21 |
Dyrcona |
wheezy has LTS until May 2018, and the next one, stretch? isn't out yet. |
| 16:21 |
csharp |
ah - gotcha |
| 16:22 |
Dyrcona |
It's the drivers that blow up. |
| 16:28 |
Dyrcona |
Hmm.. I ended up with libpq-dev from 9.6 and postgresql-client-9.1 installed. |
| 16:30 |
jeff |
there is a release between wheezy and stretch... :-) |
| 16:31 |
* berick |
gets wheezy when he stretches |
| 16:31 |
JBoyer |
berick++ |
| 16:32 |
Dyrcona |
Hm.. I installed prereqs with the wrong branch somehow. |
| 16:33 |
Dyrcona |
So, things were confused, I guess between the community libpq-dev and Debian postgresql-client.... |
| 16:34 |
Dyrcona |
Ah, community packages put libs in versioned directories. |
| 16:35 |
Dyrcona |
libdbi-drivers has a configure option for that, I believe. |
| 16:39 |
Dyrcona |
Nope. Didn't help, and libpq is under /usr/lib/x86_64-linux-gnu/ |
| 16:40 |
Dyrcona |
Ah, specifying --with-pgsql-incdir=/usr/includ/postgresql seems to fix it. |
| 16:40 |
Dyrcona |
Well, barring typos. :) |
| 16:42 |
Dyrcona |
Then make all in libdbi-drives runs into this: ../../libtool: line 1801: cd: no: No such file or directory |
| 16:44 |
Dyrcona |
And, they include an antiquated version of libtool, of course... |
| 16:44 |
csharp |
berick: we're getting reports of an issue with hold targeting where it's targeting copies outside the pickup library when there are eligible copies *in* the pickup library |
| 16:44 |
csharp |
I don't really have a good grasp of how it worked in the old targeter to know where to look |
| 16:45 |
csharp |
but I was just looking at the circ.holds.org_unit_target_weight setting type, which we haven't set before and wondering if it needs to be set |
| 16:45 |
Dyrcona |
Specifying both --with-pgsql-incdir --with-pgsql-libdir seems to work. |
| 16:46 |
csharp |
I'm going to keep looking in the code, but thought I'd let you know about it too |
| 16:46 |
berick |
csharp: the circ.holds.org_unit_target_weight setting is applied nowhere, correct? |
| 16:46 |
csharp |
correct |
| 16:47 |
berick |
then it should behave just as before.. |
| 16:47 |
berick |
you don't need to set that setting to solve this problem, is what I'm saying |
| 16:47 |
csharp |
ok - I'll keep looking for examples and let you know if I find anything interesting |
| 16:47 |
csharp |
berick: 10-4 |
| 16:47 |
berick |
k, i'll take a look too and see if anything jumps out at me |
| 16:49 |
berick |
csharp: are you using circ.holds.max_org_unit_target_loops ? |
| 16:49 |
csharp |
the complaint is 1) staff see an item available at library A and place a hold, expecting that copy to get targeted since it's at the pickup lib 2) hold targeter picks another copy at library B and 3) library B staff pull and ship the hold to library A |
| 16:50 |
csharp |
I'll have to look |
| 16:50 |
csharp |
nope, we're not using that setting anywhere |
| 16:51 |
berick |
k |
| 16:52 |
csharp |
I'm actually not convinced yet that it hasn't always worked this way, but it's notable that two separate libraries have complained |
| 16:52 |
csharp |
so I'm starting with the assumption that something has changed |
| 16:53 |
berick |
with those settings not in play, it should based solely on the calculated copy proximity |
| 16:54 |
berick |
csharp: in those cases, is there more than one copy at the pick up lib? related, does the copy at the pickup lib get targeted, not pick up, then something else gets targeted? |
| 16:54 |
mmorgan |
Hmm. Launchpad timeout error. It must be exhausted from all the bug squashing. |
| 16:55 |
csharp |
berick: I'll have to dig for both of those answers - there are several examples, but I'll need to track what happened in the logs |
| 16:56 |
berick |
csharp: ok, the only time it should target somewhere else when there is a copy at the pickup library, is if there is only 1 copy at the pickup library and that copy is currently targeted, so a new copy is selected (from the next "closest" location) |
| 16:57 |
berick |
csharp: anyway, yeah, keep me posted |
| 17:00 |
csharp |
berick: thanks for the pointers! |
| 17:02 |
pinesol_green |
News from qatests: Test Success <http://testing.evergreen-ils.org/~live> |
| 17:02 |
kmlussier |
csharp / berick: Is it a case where the opportunistic capture happens before the person in library A has a chance to pull it off the shelf? Do you have holds stalling in place? |
| 17:03 |
kmlussier |
Oh, I think berick was already suggesting that above. :) |
| 17:03 |
csharp |
kmlussier: we have 5 days of stalling in place, but I'm sure it's not that - our staff is pretty savvy about that feature |
| 17:04 |
csharp |
at least I can say that about the 2 staff that independently reported the issue :-) |
| 17:04 |
kmlussier |
OK, then, so it shouldn't be an opportunistic capture. |
| 17:04 |
* kmlussier |
tried out a bunch of different use cases with the new holds targeter, but did not test out holds stalling. |
| 17:06 |
csharp |
I figured we were good after a month and a half, but you can trust PINES libraries to find every single corner case :-) |
| 17:07 |
|
mmorgan left #evergreen |
| 17:09 |
* kmlussier |
never knows what status to give a bug that was addressed through one of the big web client merges. |
| 17:09 |
kmlussier |
Because there isn't some other bug to point to as a duplicate. Invalid? |
| 17:12 |
Dyrcona |
Fix committed. :) |
| 17:12 |
Dyrcona |
Comment with a link to the branch on git.evergreen-ils.org. |
| 17:14 |
Dyrcona |
How do I let bshum rope into these things? :P |
| 17:18 |
Dyrcona |
Oh! On the holds stalling issue discussed above, folks at C/W MARS think it is broken since 2.8 or so. |
| 17:18 |
Dyrcona |
It's on the list of things for me to look at. |
| 17:18 |
Dyrcona |
They swear it used to work on a system/branch level and now it doesn't. |
| 17:19 |
kmlussier |
Do they really think it's broken? I thought they wanted it to work differently. |
| 17:22 |
* kmlussier |
applies another fixedinwebby tag to an LP bug and looks forward to the day when we can set those xul-era bugs to "Won't Fix." |
| 17:27 |
Dyrcona |
I was told that [someone] thinks it used to work they way that they want, and it broke around 2.8. |
| 17:27 |
Dyrcona |
I don't think it ever worked that way, but I've never used it. |
| 17:35 |
Dyrcona |
So, should we switch the wheezy branch to install Pg 9.4 instead of 9.3? |
| 17:36 |
Dyrcona |
And, if we do that, we should probably do something similar for trusty, but they both should disappear next Spring, so maybe not worth it, either way. |
| 17:37 |
Dyrcona |
Well, we probably won't drop trusty until 18.04 is working. |
| 17:39 |
Dyrcona |
Yeah, we should probably go with the recommend version in both cases. |
| 17:39 |
Dyrcona |
Gah! |
| 17:40 |
Dyrcona |
Ok. I'll blame the typos on the sore arms from the hammering while holding up roofing shingles, and the short strokes required, and the gloves catching on the edge of the shingles.... |
| 17:42 |
Dyrcona |
And CPAN decided that the closest mirror for this installation is yzu.edu.tw! |
| 17:42 |
Dyrcona |
Taiwan...OK. |
| 17:45 |
Dyrcona |
If we're still supporting trusty and wheezy for 3.0, then I think this exercise will be worth it. :) |
| 17:49 |
Dyrcona |
Well, barring a typo that I'm about to fix the 9.3 prereq installation works on wheezy. |
| 17:50 |
Dyrcona |
I'll fix the typo, update to install 9.4 and push a new collab branch for anyone interested. |
| 17:51 |
Dyrcona |
Ugh..... |
| 17:52 |
Dyrcona |
My working directory is somehow messed up. |
| 17:53 |
Dyrcona |
Ah, no. Maybe I'm running low on RAM. |
| 18:04 |
Dyrcona |
Oh, well. What else would I be doing right now, my taxes? |
| 18:09 |
* Dyrcona |
works on irs-mode for doing his taxes in GNU Emacs. :) |
| 18:11 |
|
dbwells joined #evergreen |
| 18:12 |
|
gsams joined #evergreen |
| 18:13 |
Dyrcona |
From Sloganizer.net: «Dyrcona verleiht Flügel.» |
| 18:13 |
Dyrcona |
It's more fun in German. :) |
| 18:37 |
Dyrcona |
I think libtemplate-perl being under TRANSLATOR_DEBS is a mistake. |
| 18:37 |
Dyrcona |
Anyway, I'm out of here when I verify that my changes for Pg 9.4 on wheezy work. |
| 18:38 |
Dyrcona |
Well, verify that the prereqs install. |
| 18:40 |
Dyrcona |
It only works that way because... |
| 18:41 |
Dyrcona |
Actually, I don't see how this works on wheezy to be honest. |
| 18:41 |
Dyrcona |
It works on Jessie because libtemplate-plugin-posix-perl naturally install libtemplate-perl as a prerequisite. |
| 18:42 |
Dyrcona |
It works on wheezy, but I'm not sure why. |
| 18:46 |
Dyrcona |
Ah, it's installed via CPAN. |
| 18:47 |
Dyrcona |
We could just remove libtemplate-perl from the Makefiles and rely on the plugin installing it. |
| 18:49 |
Dyrcona |
I feel like I've had this monologue before.... |
| 18:49 |
Dyrcona |
Yay! Pre-requisite installation succeeded. |
| 18:51 |
Dyrcona |
And, Pg 9.4 server installs nicely. So, I'm signing out. |
| 19:28 |
jeff |
Dyrcona++ |
| 19:47 |
|
Jillianne joined #evergreen |
| 21:23 |
bshum |
@later tell Dyrcona Saw the branch work for PG 9.4, looks great. I'll test the latest on fresh Wheezy and also apply changes for Trusty too. See: https://bugs.launchpad.net/evergreen/+bug/1493824 |
| 21:23 |
pinesol_green |
bshum: The operation succeeded. |
| 21:23 |
pinesol_green |
Launchpad bug 1493824 in Evergreen "Evergreen/PostgreSQL 9.4 support" [Wishlist,Triaged] |
| 21:26 |
bshum |
Dyrcona++ |
| 22:36 |
bshum |
Cool, Wheezy installs great with PG 9.4 with the collab branch, and works with the built web client, etc. |
| 22:37 |
bshum |
Now to try the same thing on Trusty and build a new VM for that. |
| 22:39 |
bshum |
Well after I get the latest 14.04.5 ISO I guess. |
| 23:20 |
bshum |
Hmm, confirmed that Step 9.10 to "chown opensrf /var/lock/apache2" was needed for my Debian Wheezy prior to successfully restarting apache. Guess we should make that a standard step for all Debian-based distros now. |
| 23:20 |
bshum |
and not just for Ubuntu |
| 23:26 |
* bshum |
will leave some variant of the Fedora language around, but probably should work on getting newer Fedora vetted with Evergreen so that the README can be more accurate someday |
