Evergreen ILS Website

IRC log for #evergreen, 2014-03-05

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

All times shown according to the server's local time.

Time Nick Message
03: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

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