Time |
Nick |
Message |
03:03 |
|
tfaile_ joined #evergreen |
03:06 |
|
senator_ joined #evergreen |
04:01 |
|
ktomita joined #evergreen |
04:01 |
|
zxiiro joined #evergreen |
04:01 |
|
Callender_ joined #evergreen |
04:01 |
|
bradl joined #evergreen |
04:01 |
|
jboyer_isl joined #evergreen |
06:55 |
|
rjackson_isl joined #evergreen |
06:55 |
|
mceraso_ joined #evergreen |
06:55 |
|
wjr_ joined #evergreen |
06:57 |
|
bshum joined #evergreen |
06:59 |
|
pmurray_away joined #evergreen |
07:11 |
|
timf joined #evergreen |
07:25 |
csharp |
@later tell bshum I'll take a look at the classic_current_circ view issue |
07:25 |
pinesol_green |
csharp: The operation succeeded. |
07:34 |
csharp |
@later tell bshum yeah I think dropping the view with a NOTICE from the script that it was dropped and needs to be recreated (if it was there) is the best approach for now |
07:34 |
pinesol_green |
csharp: The operation succeeded. |
07:35 |
csharp |
that happened with one of the other custom reporter views in 2.3-2.4 iirc |
07:45 |
|
tsbere joined #evergreen |
07:49 |
bshum |
Sigh. Reingests always take too long :( |
08:05 |
|
akilsdonk joined #evergreen |
08:05 |
csharp |
yep - for us that means minimum 3 - 4 days of downtime for upgrades |
08:17 |
bshum |
I don't think I've ever done an upgrade downtime window longer than 24 hours. |
08:19 |
|
kmlussier joined #evergreen |
08:23 |
|
Shae joined #evergreen |
08:28 |
csharp |
bshum: some of why we need longer upgrade windows is because we tend to only upgrade every 9-12 months, which means we're often jumping up at least 2 releases |
08:28 |
bshum |
csharp: Yeah, I know. Just teasing you, sorry ;) |
08:28 |
csharp |
nah - I didn't take it the wrong way |
08:30 |
csharp |
upgrade scripts themselves are usually done within 24 hours, but if something unexpected occurs (like, oh, discovering that the pg_xlog partition is full as you're doing a pg_restore at 3:00 a.m.), it could put you back a half day ;-) |
08:45 |
|
RoganH joined #evergreen |
08:45 |
|
ericar joined #evergreen |
08:52 |
|
Dyrcona joined #evergreen |
09:00 |
kmlussier |
csharp: In your e-mail, are you talking about the initial proposal for a development project? If so, it was done on list too - http://markmail.org/message/rbz6atf7j2zhe2k3 |
09:06 |
Dyrcona |
In ten years of working in a "consortium" and longer working with Free Software projects, I can tell you that communication is always the hardest part. |
09:06 |
Dyrcona |
You can send all the emails, make the bug entries, chat in IRC, etc., but there is no way to make people pay attention. |
09:07 |
RoganH |
Dyrcona: Let me fix that for you. "In a lifetime of working with humans, I can tell you that communication is always the hardest part." |
09:07 |
Dyrcona |
heh. |
09:07 |
Dyrcona |
True dat. |
09:07 |
Dyrcona |
RoganH++ |
09:08 |
csharp |
kmlussier: no, I'm not referring to the initial development (which I think was done properly) |
09:08 |
csharp |
I just wonder if wide-ranging discussions about development direction should be handled outside of bug comments |
09:08 |
csharp |
(obviously, I think they should ;-) ) |
09:09 |
kmlussier |
csharp: OK, thanks! I'll be replying to your e-mail. Fair warning, it might be rather lengthy as I've been mulling over this issue for about a week now. |
09:09 |
csharp |
kmlussier++ |
09:09 |
kmlussier |
mulling/stewing - take your pick of words. ;) |
09:10 |
Dyrcona |
mulling is stewing, just for wine. :) |
09:10 |
csharp |
Dyrcona++ |
09:10 |
kmlussier |
heh |
09:11 |
jeff |
mulling on the issue of in-bugtracker vs on-list communication, or mulling on this specific bug? |
09:12 |
kmlussier |
jeff: I would say mulling ways to improve the entire process of proposing development projects and getting feedback early on. |
09:13 |
jeff |
mmm... milled cider. |
09:16 |
|
mmorgan joined #evergreen |
09:20 |
jeff |
er, mulled. :P |
09:22 |
csharp |
kmlussier: oh, and my intention isn't to call anyone out about anything in that bug - I just would like to see that type of discussion take place on the list - just to be clear |
09:23 |
kmlussier |
csharp: Understood |
09:23 |
csharp |
:-D |
09:30 |
|
mrpeters joined #evergreen |
09:37 |
Dyrcona |
@later tell gmcharlt rhcl would appreciate it if you could kickstart huginn for #koha. :) |
09:37 |
pinesol_green |
Dyrcona: The operation succeeded. |
09:38 |
csharp |
@later tell huginn please tell #koha we said "hello" |
09:38 |
pinesol_green |
csharp: The operation succeeded. |
09:40 |
phasefx |
any objections to subscribing pinesol to http://testing.evergreen-ils.org/~live/ in this channel? It's been doing it in #openils-evergreen for a while now as an experiment |
09:40 |
csharp |
phasefx: no objections here |
09:41 |
Dyrcona |
My question would be: How spammy is that? |
09:41 |
phasefx |
one message a day |
09:41 |
bshum |
Fix the live test failure and I'll say yes. |
09:41 |
bshum |
:D |
09:42 |
bshum |
Cause otherwise it'll just make me sad to see that message. |
09:42 |
Dyrcona |
I don't think one message a day would be a problem. |
09:42 |
* phasefx |
was kind of hoping folks seeing the failure message would cause some impetus to getting it fixed :) |
09:42 |
|
yboston joined #evergreen |
09:42 |
phasefx |
there's a bug report for it <looks> |
09:43 |
csharp |
looks like a missing perl lib? |
09:43 |
jeff |
I started looking at Test::Output last night. I'm interested in getting it fixed. I don't like the idea of us getting used to live tests failing. :-) |
09:43 |
jeff |
and yes, bug 1279420 |
09:43 |
phasefx |
bug 1279420 |
09:43 |
pinesol_green |
Launchpad bug 1279420 in Evergreen "need Test::Output prerequisite" (affected: 1, heat: 6) [Medium,Triaged] https://launchpad.net/bugs/1279420 |
09:43 |
phasefx |
jeff++ |
09:46 |
csharp |
I can test the ubuntu targets |
09:46 |
phasefx |
csharp++ |
09:52 |
dbs |
phasefx: can you add a <meta charset="utf-8"> tag to the head of the testing output? |
09:53 |
dbs |
jeff++ |
09:54 |
phasefx |
dbs: can do, and it's all in a public git branch |
09:56 |
phasefx |
(that it refreshes and pulls from every night before running) |
09:57 |
phasefx |
dbs: so just a <meta charset="utf-8"> between <head> and </head> somewhere? no need to close with a </meta> ? |
09:59 |
dbs |
phasefx: correct. viva HTML5! |
09:59 |
phasefx |
dbs: done, thanks man |
10:00 |
jeff |
oh hell. phasefx already had a working branch. |
10:00 |
jeff |
:P |
10:03 |
jeff |
I'm too used to looking for working branches in comments. |
10:04 |
phasefx |
convergent evolution |
10:19 |
jeff |
dbs: is evergreen expected to work on fedora 19, 20, other? |
10:19 |
csharp |
jeff: the fedora buildslave is 19 FYI |
10:19 |
jeff |
thanks. |
10:19 |
* csharp |
should update that to 20 |
10:22 |
dbs |
jeff: I target fedora-current-stable |
10:23 |
dbs |
short support lifespans. |
10:31 |
|
pmurray joined #evergreen |
10:32 |
|
dluch joined #evergreen |
10:38 |
|
Wyuli joined #evergreen |
10:59 |
jeff |
the official fedora 19 AMI does not survive a yum upgrade + reboot. Oh well. |
11:02 |
dbs |
AMI? u crazy |
11:05 |
jeff |
what, is Fedora allergic to EC2? |
11:07 |
* csharp |
sneezes |
11:08 |
dbs |
I honestly know nothing about EC2 + Fedora, never tried |
11:11 |
|
Wyuli joined #evergreen |
11:11 |
jeff |
dbs: got it. from the "crazy" comment, I wondered if I was doing something that was expected to fail. :-) |
11:12 |
* dbs |
does everything with kvm these days |
11:12 |
csharp |
kvm++ |
11:12 |
bshum |
@love kvm |
11:12 |
pinesol_green |
bshum: The operation succeeded. bshum loves kvm. |
11:12 |
csharp |
@love kvm |
11:12 |
pinesol_green |
csharp: The operation succeeded. csharp loves kvm. |
11:16 |
* Dyrcona |
uses kvm + qemu. |
11:17 |
csharp |
I'm still kind of stuck on virtualbox for local desktop stuff (running windows VMs) because of not-so-awesome network bridging in NetworkManager |
11:17 |
csharp |
as soon as that's better, I'll switch completely |
11:19 |
csharp |
(last time I tested that was on F19 last summer - now on Ubuntu 13.10) |
11:20 |
dbs |
windows vms are the one thing I havent' been able to get working in kvm. but I don't want to taint my system with virtualbox kernel modules... so no windows vms for me. |
11:20 |
csharp |
dbs: understood |
11:20 |
csharp |
with the Linux staff client, I boot mine less and less frequently |
11:21 |
csharp |
I could probably lose them completely if I tried hard enough ;-) |
11:21 |
dbs |
(mostly from a "hate it when a kernel bug report gets created but not submitted because the tainted module") |
11:22 |
|
collum joined #evergreen |
11:25 |
|
dreuther joined #evergreen |
11:34 |
pinesol_green |
[evergreen|Jason Etheridge] LP#1279420 Add Test::Output prerequisite - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=0cbadcc> |
11:35 |
phasefx |
jeff++ |
11:58 |
csharp |
jeff++ phasefx++ |
11:58 |
csharp |
I didn't finish getting my dev servers built - is there still a need for me to test? |
12:04 |
|
ericar joined #evergreen |
12:08 |
|
snowcatt joined #evergreen |
12:08 |
|
frank__ joined #evergreen |
12:10 |
frank__ |
hi all, could someone help me please, I am triying to upgrade my db from 2.5.0 to 2.5.3, I executed the fists two scripts without any problem, but when I execute the 2.5.2-2.5.3-upgrade-db.sql script I get ERROR: column "behind_desk" does not exist LINE 90: behind_desk |
12:11 |
jeff |
frank__: you have encountered bug 1287510 |
12:11 |
pinesol_green |
Launchpad bug 1287510 in Evergreen "2.5.2-2.5.3-upgrade-db.sql and ERROR: column "behind_desk" does not exist" (affected: 1, heat: 6) [High,Confirmed] https://launchpad.net/bugs/1287510 |
12:13 |
frank__ |
so just running ALTER TABLE action.aged_hold_request ADD COLUMN behind_desk BOOLEAN NOT NULL DEFAULT FALSE; solves the problem? |
12:13 |
csharp |
frank__: well, eeevil recommended not setting the DEFAULT FALSE part (if I'm reading correctly) |
12:14 |
dbwells |
right, to both of you |
12:14 |
eeevil |
correct, re DEFAULT FALSE. I recommend against that |
12:15 |
eeevil |
specifically, I recommend against any default for both audit and "history" (statistical obfuscation) tables |
12:15 |
eeevil |
in the case of new features, in any case |
12:15 |
csharp |
that makes sense to me. "preserve whatever's entered in the parent table" |
12:15 |
gmcharlt |
er, for a not null column, you have to pick a default |
12:16 |
dbwells |
I think the suggestion is to drop that part, too. |
12:16 |
csharp |
frank__: so drop the NOT NULL DEFAULT FALSE part |
12:17 |
frank__ |
ok csharp |
12:17 |
eeevil |
gmcharlt: well, if the parent says not null, the future entries won't be null ... I should have been less precise ;) |
12:17 |
frank__ |
thanks all |
12:17 |
csharp |
s/drop/omit/ # should be more careful in metaphor choices when talking about DBs ;-) |
12:17 |
gmcharlt |
heh, indeed |
12:17 |
eeevil |
(I addressed only the default here (and probably in the bug) but as gmcharlt points out, I'm in favor of killing the NOT NULL as well) |
12:19 |
gmcharlt |
eeevil: I've updated the bug |
12:19 |
eeevil |
gmcharlt: you are a gentleman and a scholar, sir |
12:19 |
* gmcharlt |
is also pendantic at times ;) |
12:22 |
eeevil |
pedantically speaking, many scholars are... |
12:25 |
|
kayals joined #evergreen |
12:40 |
|
DPearl joined #evergreen |
12:41 |
|
yboston joined #evergreen |
12:42 |
|
dluch joined #evergreen |
12:43 |
|
jwoodard joined #evergreen |
13:00 |
|
mixo joined #evergreen |
13:13 |
mixo |
Hi. I want from one evergreen installation create more than one apache virtualhosts. I've copied "/openils/var/template" and "/openils/var/web/opac" folders. Now I am going to copy eg_vhost.conf and eg.conf files, but in eg.conf file is configuration lines out of virtualhost tags and I've desided copy them into virtualhosts, because I must not duplicate some of tham. I want to know, may be you can offer better solution for this pro |
13:22 |
|
artunit_ joined #evergreen |
13:23 |
tsbere |
mixo: What is your goal with the virtual hosts? |
13:26 |
tsbere |
mixo: I will point out, MVLC has two sets of virtualhost blocks, the only difference is the hostname/alias set and the SSL certificates attached. They then include the eg_vhost.conf file. We then use rewritemaps to deal with the rest of the differences (default search library, env vars for library names and urls, etc) |
13:26 |
mixo |
I want them for different libraries and they want different domain and design for their libraries |
13:26 |
mixo |
but they want one database |
13:28 |
tsbere |
mixo: If you merely want to deal with differing template folders then I would skip duplicating eg_vhost.conf entirely. Just add to eg.conf, and after the eg_vhost.conf inclusion put "PerlAddVar OILSWebTemplatePath ..." lines for the other libraries. |
13:29 |
tsbere |
mixo: Note that you will need SSL certs for each library domain if you want to go that route. If you are doing subdomains (mvlc uses library.mvlc.org, changing library out for each library) you can go with a single wildcard certificate |
13:31 |
mixo |
thank you very much for advise |
13:36 |
|
mllewellyn joined #evergreen |
13:36 |
mixo |
but what I can do with /openils/var/web/opac folder duplication. There is some images like main_logo.png and may'be some design files |
13:37 |
tsbere |
mixo: The way the PerlAddVar works, *after* the eg_vhost.conf inclusion, means that the original templates folder will be used as a fallback. |
13:37 |
tsbere |
so you only put the files you are actually changing in the new folder(s) |
13:38 |
tsbere |
So if you use PerlAddVar OILSWebTemplatePath "/openils/var/templates_library1" it will look at /openils/var/templates_library1/whatever and if not found will go back to /openils/var/templates/whatever, only giving up when it runs out of paths. |
13:40 |
mixo |
thanks again |
13:56 |
|
pmpoid joined #evergreen |
13:58 |
|
bshum joined #evergreen |
14:12 |
|
mcooper joined #evergreen |
14:23 |
|
eby joined #evergreen |
14:33 |
|
jihpringle joined #evergreen |
14:36 |
jeff |
so, Business::Stripe fails tests under perl 5.18 |
14:38 |
jeff |
there's a pull request to fix it, but it seems to have gone unnoticed. i'm going to try to get an alternative fix accepted, but if it isn't accepted and a new release added to CPAN, we might need to force the install for at least fedora. |
15:04 |
gmcharlt |
jeff: does it appaer that the maintainer is responsive at all? |
15:10 |
|
ericar joined #evergreen |
15:12 |
jeff |
Unclear. The repo for the distribution hasn't been updated in ~2y. The pull request is old, but it's also a bit messy. I'll know on the "responsive" or not in a few days. :-) |
15:14 |
jeff |
but it doesn't have the appearance of some projects, where there are a dozen forks that have left the original in the dust 40 or so new features ago. |
15:24 |
gmcharlt |
jeff: tcohen successively took over maint of a Perl dep used by Koha recently |
15:24 |
gmcharlt |
and I think it would be a good thing for us to do, as needed |
15:26 |
csharp |
'twould be nice to also do deb (or rpm) packaging of known working versions of CPAN deps too ;-) |
15:26 |
* csharp |
looks around for interns, finds none |
15:26 |
jeff |
one thing at a time. :-) |
15:33 |
|
yboston joined #evergreen |
15:47 |
|
ericar joined #evergreen |
15:59 |
jboyer-isl |
Re: the Stripe module, there were only 2 real options I could find when we were working on that code, the other one had an enormous pile of dependencies that we absolutely don't need. :/ An alternative is an Evergreen specific Stripe module, it would only take 5-6 LWP calls to accomplish all we need with their API. |
15:59 |
jboyer-isl |
It's very simple and straightforward if you only want to bill a token. |
16:06 |
gmcharlt |
jboyer-isl: let me guess |
16:06 |
gmcharlt |
Net::Stripe <-- Moose <-- half of CPAN? |
16:07 |
rangi |
blargh |
16:07 |
rangi |
(so automatic Moose mention reflex) |
16:16 |
jboyer-isl |
gmcharlt: That's the one! When the list of dependencies scrolled of the top of the screen I decided anything else was better. |
16:21 |
Dyrcona |
eeevil++ |
16:25 |
eeevil |
Dyrcona: does that inc mean "while you remain incorrect, I appreciate that you took the time to lay out your case with examples" ? ;) |
16:25 |
gmcharlt |
heh |
16:26 |
Dyrcona |
eeevil: No, it means just the second part. |
16:26 |
|
kbutler joined #evergreen |
16:27 |
eeevil |
Dyrcona++ |
16:31 |
|
Bmagic joined #evergreen |
17:13 |
|
mmorgan left #evergreen |
17:31 |
|
dcook joined #evergreen |
17:49 |
|
Bmagic|2 joined #evergreen |
18:45 |
|
kmlussier joined #evergreen |
19:06 |
|
mrpeters left #evergreen |
21:29 |
|
kmlussier joined #evergreen |