<13.03.2012 20:01> <@Betelgeuse> helo <13.03.2012 20:01> <@grobian> yo <13.03.2012 20:01> <+dberkholz> hi <13.03.2012 20:01> <@Chainsaw> 250 chainsaw.gentoo.org ready <13.03.2012 20:02> <@grobian> MAIL FROM: <13.03.2012 20:02> <@Betelgeuse> agenda: http://archives.gentoo.org/gentoo-dev-announce/msg_6531c9554a3050e94eac3388bc38f4b8.xml <13.03.2012 20:02> < willikins> grobian, you have notes! [20:42] it seems that the portage and x11 overlay versions of libSM have diverged. if you make changes to those ebuilds it is important to notify x11 team because we use the x11 overlay packages for bumping <13.03.2012 20:02> <@grobian> Betelgeuse: do we skip the EAPI5 thing or not? <13.03.2012 20:02> <@Betelgeuse> As a sub bullet for 2) I think we want to touch on Tommy[D]'s request <13.03.2012 20:03> <@Betelgeuse> My initial idea was to first open the process in general <13.03.2012 20:03> <+dberkholz> the person who submitted it withdrew the proposal and wanted to write up cross-compile stuff for the next council <13.03.2012 20:03> <@grobian> jmbsvicetto: ulm ping <13.03.2012 20:04> <@Betelgeuse> hwoarang: ping <13.03.2012 20:04> * hwoarang here <13.03.2012 20:04> <@ulm> here <13.03.2012 20:05> <@Chainsaw> Present. <13.03.2012 20:05> <@Betelgeuse> I will call Jorge <13.03.2012 20:05> <@grobian> |I was texting <13.03.2012 20:07> <@Betelgeuse> didn't connect <13.03.2012 20:07> <@Betelgeuse> so let's start <13.03.2012 20:07> <@Betelgeuse> 2. EAPI 5 <13.03.2012 20:07> <@Betelgeuse> Tommy[D] wanted us to vote on the inclusion of a feature. <13.03.2012 20:07> <@grobian> specs first <13.03.2012 20:07> <@Betelgeuse> Usually we have voted only on ready specs. <13.03.2012 20:08> <@Chainsaw> Anything to vote on? No? Move on. <13.03.2012 20:08> <@ulm> someone should go through the open EAPI bugs and collect the features that are candidates for EAPI 5 <13.03.2012 20:09> <@Betelgeuse> ulm: http://video.fosdem.org/2012/crossdistro/Gentoo_EAPI_5.webm <13.03.2012 20:09> <@ulm> Betelgeuse: do you have a summary in textual form? ;) <13.03.2012 20:10> < Tommy[D]> Betelgeuse: as i wrote in response to your announcement, i will ask for the next council session with a provided spec, so just drop it for now :) <13.03.2012 20:10> <@grobian> I'd suggest to actually flesh that out first on the mls <13.03.2012 20:10> <@grobian> ^^^ betelgeuse <13.03.2012 20:10> <@Betelgeuse> ulm: I can upload the slides (they have bug ids) <13.03.2012 20:10> <+dberkholz> maybe we should just make a tracker bug instead <13.03.2012 20:10> <@ulm> Betelgeuse: yes, slides would be fine <13.03.2012 20:11> <@jmbsvicetto> pong <13.03.2012 20:11> <@jmbsvicetto> sorry guys, I forgot the meeting :-\ <13.03.2012 20:11> <+dberkholz> jmbsvicetto: good, now i'm not the only one =) <13.03.2012 20:11> <@Betelgeuse> Ok so to conclude: the council encourages starting to submit EAPI 5 items for specification with implementations to Portage. All agree? <13.03.2012 20:11> <+dberkholz> sure <13.03.2012 20:11> <@ulm> +1 <13.03.2012 20:11> <@grobian> sure <13.03.2012 20:12> <@hwoarang> ok <13.03.2012 20:12> <@Betelgeuse> Tommy[D]: thanks <13.03.2012 20:12> <@Betelgeuse> Tommy[D]: Sorry about undercommunication on the agenda. <13.03.2012 20:12> <@jmbsvicetto> +1 <13.03.2012 20:12> <@Chainsaw> Yes. Agreed. <13.03.2012 20:12> <@Betelgeuse> ok point 2 <13.03.2012 20:12> <@Betelgeuse> default locale <13.03.2012 20:12> <@Chainsaw> UTF8 is a good thing to have, but... <13.03.2012 20:13> <@Betelgeuse> actually 3a <13.03.2012 20:13> <@Chainsaw> It seems to lock you into a country. <13.03.2012 20:13> <@Chainsaw> Did you say Debian had implemented a pretend-country for this purpose? <13.03.2012 20:13> <@jmbsvicetto> Chainsaw: I've seen the proposal to use C.UTF-8 a few times when this discussion is raised <13.03.2012 20:13> <@grobian> can someone remind me why documenting this in the install doc isn't sufficient? <13.03.2012 20:13> <@jmbsvicetto> I recall reading about it on the dev ml at least 2 times in the last 6 months. <13.03.2012 20:14> <@grobian> jmbsvicetto: yeah, but it doesn't exist <13.03.2012 20:14> <@Chainsaw> grobian: Something to be said for that, all of my kit is en_GB.UTF-8. <13.03.2012 20:14> <@jmbsvicetto> grobian: I thought debian had created it <13.03.2012 20:14> <@grobian> Chainsaw: same here <13.03.2012 20:14> <@Chainsaw> grobian: Especially now that eselect handles the env.d aspects... <13.03.2012 20:14> <@grobian> jmbsvicetto: exactly <13.03.2012 20:14> <@Chainsaw> grobian: It is no longer such a hardship. <13.03.2012 20:15> <@grobian> multibyte stuff is expensive <13.03.2012 20:15> <@Chainsaw> grobian: So, counter-proposal is to better document the existing tools? <13.03.2012 20:15> <@grobian> whether you want to have support for it available, is another thing <13.03.2012 20:15> <@grobian> Chainsaw: I believe it already is documented like this, isn't it? <13.03.2012 20:15> <@Chainsaw> I want UTF-8, and think developers should have it. You can't write Flameeyes correctly, for example. Petten o-with-funky-stripe etc. <13.03.2012 20:16> <@jmbsvicetto> Chainsaw: iirc, one of the proposals for releng to use it was related to some packages failing to build with the C locale <13.03.2012 20:16> <@Chainsaw> jmbsvicetto: Test suites tend to implode, yes. <13.03.2012 20:16> <+dberkholz> btw, here's the debian bug about introducing C.UTF-8: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=522776 <13.03.2012 20:16> <@Chainsaw> jmbsvicetto: If you turn those off it is generally okay. <13.03.2012 20:17> <@grobian> I've no problems making en_US.UTF-8 the default, but it's the same as portage's --quiet-build in some sense <13.03.2012 20:17> <@Chainsaw> grobian: I would be against defaulting to a specific country. <13.03.2012 20:17> < cam___> all packages build fine with utf8 enabled? <13.03.2012 20:17> <@Chainsaw> grobian: C.UTF-8 looks more sensible, but is extra work. <13.03.2012 20:18> <+dberkholz> gentoo already defaults to en_US <13.03.2012 20:18> <+dberkholz> read the docs <13.03.2012 20:18> <+dberkholz> i mean, everything on our site uses american english <13.03.2012 20:18> <@ulm> we should leave LANG at C or POSIX <13.03.2012 20:18> <@Betelgeuse> Portage could default to C when building even if C.UTF-8 is otherwise the default. <13.03.2012 20:18> <@ulm> and only set LC_CTYPE which is less intrusive <13.03.2012 20:18> <@Betelgeuse> So stuff building is not really an issue. <13.03.2012 20:19> <@ulm> otherwise, there may be undesired side effects <13.03.2012 20:19> <+dberkholz> ulm: that is precisely what C.UTF-8 does <13.03.2012 20:19> <@grobian> Why is adding a strong suggestion to set UTF-8 locale in http://www.gentoo.org/doc/en/handbook/handbook-amd64.xml?part=1&chap=8 not enough? <13.03.2012 20:19> <@grobian> the default must be C/POSIX, IMO <13.03.2012 20:20> <@grobian> though you should be free to override, and actually be encouraged to do so <13.03.2012 20:20> <@grobian> apart from that the system should be capable of doing UTF-8 and so on <13.03.2012 20:20> <@ulm> grobian: you certainly have a point, locale is one of the things that every user should configure for his system <13.03.2012 20:20> < cam___> are there some other distros utf8 by default? <13.03.2012 20:21> <@Betelgeuse> cam___: Installers probably set it. <13.03.2012 20:21> <@hwoarang> i tend to agree that a strong suggestion in the guide is enough <13.03.2012 20:21> <@grobian> ulm: and even individual users can configure it <13.03.2012 20:21> <@Betelgeuse> I think Ubuntu went years ago but don't remember specifics. <13.03.2012 20:21> <@ulm> grobian: right <13.03.2012 20:21> <@Chainsaw> grobian: I support your idea. <13.03.2012 20:21> <@Betelgeuse> So let's start with this: Should the handbook have a section for the user to choose a locale? <13.03.2012 20:22> <@ulm> yes <13.03.2012 20:22> <@grobian> Betelgeuse: yes <13.03.2012 20:22> <@Chainsaw> Betelgeuse: Yes. It should. <13.03.2012 20:22> <+dberkholz> so you're saying we should incorporate the existing localization guide content directly into the handbook? <13.03.2012 20:22> <@grobian> Ubuntu indeed seems to be en_US.UTF-8 by default <13.03.2012 20:22> <@grobian> (just checked) <13.03.2012 20:23> <+dberkholz> we already talk a little about locales in the handbook, see http://www.gentoo.org/doc/en/handbook/handbook-x86.xml?part=1&chap=6 <13.03.2012 20:23> <@Chainsaw> grobian: I find that Ubuntu has made so much bad calls lately, that I would discourage using them as a guide. <13.03.2012 20:23> <@grobian> Chainsaw: just as info, I don't agree with their choice, although I understand from their perspective and vision on their users <13.03.2012 20:23> <@Betelgeuse> http://www.gentoo.org/doc/en/handbook/handbook-amd64.xml?part=1&chap=12 <13.03.2012 20:24> <@Betelgeuse> dberkholz: it is linked to from there <13.03.2012 20:24> <@Betelgeuse> dberkholz: I think we want to put a little more emphasis <13.03.2012 20:24> <@Chainsaw> Betelgeuse: Yes, it seems too optional this way. <13.03.2012 20:24> <@grobian> I think dberkholz's link is actually the place where you want to suggest actually enabling something by default <13.03.2012 20:24> <@grobian> iso just making it available <13.03.2012 20:25> <@Betelgeuse> jmbsvicetto, hwoarang, dberkholz: input please <13.03.2012 20:25> <@Chainsaw> grobian: Better place there, yes. But the current examples are a bit sparse. <13.03.2012 20:25> <@grobian> Chainsaw: agreed <13.03.2012 20:26> <@Chainsaw> Evening Zac. <13.03.2012 20:26> <+dberkholz> sure, i'd be fine with adding extra emphasis on enabling a utf-8 locale in that section i pointed to <13.03.2012 20:26> <+dberkholz> seems very reasonable <13.03.2012 20:26> <@jmbsvicetto> Betelgeuse: I like the idea of improving the docs <13.03.2012 20:26> <@Chainsaw> dberkholz: Okay, let's do that. Update the documentation, but make no actual system changes. <13.03.2012 20:27> <@Betelgeuse> Second question: Do we want to mandate a new default at this point? <13.03.2012 20:27> < cam___> why not in http://www.gentoo.org/doc/en/handbook/handbook-amd64.xml?part=1&chap=8#doc_chap3 along with keymap and clock? <13.03.2012 20:27> <@jmbsvicetto> I think we should also "encourage" anyone interested in looking at the C.UTF-8 locale <13.03.2012 20:27> <@grobian> Betelgeuse: I guess no, since it's the user to chose there <13.03.2012 20:27> <@Chainsaw> jmbsvicetto: Do we have one though? <13.03.2012 20:28> <@grobian> jmbsvicetto: it's there on Debian <13.03.2012 20:28> <@Chainsaw> jmbsvicetto: Is that not a Debian-specific patch that we do not carry? <13.03.2012 20:28> <@grobian> jmbsvicetto: not with us <13.03.2012 20:28> <@grobian> We should just explain a bit better where ti find our own land/language code <13.03.2012 20:28> <@jmbsvicetto> something we should talk with vapier about? <13.03.2012 20:28> <@ulm> Chainsaw: yes, it's debian specific <13.03.2012 20:29> <@grobian> jmbsvicetto: no, don't need it, and upstream apparently don't want it <13.03.2012 20:29> <@Chainsaw> jmbsvicetto: If the documentation is better, it shouldn't be required. <13.03.2012 20:29> <@Chainsaw> jmbsvicetto: Besides, fighting upstream is labour-intensive. <13.03.2012 20:29> <+dberkholz> we don't ship that locale <13.03.2012 20:29> <+dberkholz> that's the problem <13.03.2012 20:29> <@grobian> how can C be UTF-8 anyway <13.03.2012 20:29> <@Betelgeuse> https://bugs.gentoo.org/show_bug.cgi?id=408073 <13.03.2012 20:29> <+dberkholz> and i'm not terribly interested in adding customizations at that level <13.03.2012 20:29> <@jmbsvicetto> grobian / Chainsaw: If we could pick C.UTF-8, I'd prefer us making that the default <13.03.2012 20:29> <@grobian> it's POSIX, so ASCII <13.03.2012 20:29> <@Chainsaw> jmbsvicetto: But we can't. <13.03.2012 20:29> <@grobian> jmbsvicetto: we can't and it's nonsense <13.03.2012 20:30> < ssuominen> I would ship 02locale by default set to en_US.UTF-8 and update the locale documentation for that <13.03.2012 20:30> < ssuominen> shipped in bl-2 <13.03.2012 20:31> <@ulm> ssuominen: LANG or LC_CTYPE? <13.03.2012 20:31> < ssuominen> LANG <13.03.2012 20:31> <@grobian> what's the benefit of that? <13.03.2012 20:31> <@ulm> ssuominen: then I would be against it <13.03.2012 20:31> < ssuominen> leave LC_CTYPE below that commented out <13.03.2012 20:31> < ssuominen> as an example <13.03.2012 20:32> <@grobian> Betelgeuse: can we get back on track, please? <13.03.2012 20:32> <@Betelgeuse> grobian: yes <13.03.2012 20:32> <@Betelgeuse> Can I have a clear yes /no on the second question <13.03.2012 20:33> <@grobian> Betelgeuse: no, since we won't force another default <13.03.2012 20:33> <@Betelgeuse> (if the answer is no we can clearly move on as no changes need to be discussed) <13.03.2012 20:34> <+dberkholz> i would be ok with it, if it were shipped upstream, but not if we have add it ourselves <13.03.2012 20:34> <@hwoarang> i dont see the point for a default locale in installation images. So "no" for me <13.03.2012 20:34> <@ulm> Betelgeuse: no if it would mean changing LANG <13.03.2012 20:35> <@Betelgeuse> ulm: so you would like changing some LC_*? <13.03.2012 20:35> <@ulm> Betelgeuse: I wouldn't oppose it <13.03.2012 20:36> <@ulm> count it as abstain <13.03.2012 20:36> <@Betelgeuse> jmbsvicetto, Chainsaw <13.03.2012 20:37> <@Chainsaw> Betelgeuse: No. Do not make system changes, stick with a documentation change and call it a day. <13.03.2012 20:39> <@jmbsvicetto> Betelgeuse: if we can't use C.UTF-8 to try to fix the building issues with the C locale and document how to set a locale, I think we shouldn't set a new default <13.03.2012 20:39> <@grobian> jmbsvicetto: fix building issues by forcing en_US.UTF-8 locale in build-env? <13.03.2012 20:39> <@Betelgeuse> What we build with is a different item I think. <13.03.2012 20:39> <@Betelgeuse> what grobian said <13.03.2012 20:39> <@Chainsaw> jmbsvicetto: C.UTF-8 is a Debian-specific thing that we do not have. <13.03.2012 20:39> <@hwoarang> that's a diffenent issue <13.03.2012 20:40> <@Chainsaw> And please, can we move on. This is a yes or no question. <13.03.2012 20:40> <@jmbsvicetto> grobian: I guess we could do that - if the user doesn't have a UTF-8 locale <13.03.2012 20:40> <@jmbsvicetto> Chainsaw: I know, but I think it might / could be an option <13.03.2012 20:40> <@Betelgeuse> We have enough no's to call it a decision. <13.03.2012 20:40> <@jmbsvicetto> Chainsaw: count mine as a no <13.03.2012 20:40> <@Chainsaw> That's unanimous. Move on please. <13.03.2012 20:41> <@Betelgeuse> Ok that concludes the official agenda items. <13.03.2012 20:41> <@grobian> jmbsvicetto: let's delay discussion for a bit <13.03.2012 20:41> <@Betelgeuse> Anything for the open floor? <13.03.2012 20:41> <@jmbsvicetto> grobian: sure <13.03.2012 20:42> <@grobian> Betelgeuse: maybe a little q for the other council members how they see re-evaluating glep-55 <13.03.2012 20:42> <@Betelgeuse> grobian: sure <13.03.2012 20:42> <@jmbsvicetto> grobian: My reasons to dislike it are still valid (imho) <13.03.2012 20:42> <@grobian> possible, useful, whether it will change anything, etc. <13.03.2012 20:42> <@Betelgeuse> I voted for it the last time. <13.03.2012 20:42> <@Chainsaw> grobian: I thought it was a bad idea then, and it still is a bad idea now. <13.03.2012 20:43> <@grobian> I'm not a big fan of changing the ebuild extension myself <13.03.2012 20:43> <+dberkholz> i prefer the header solution <13.03.2012 20:43> <@jmbsvicetto> grobian: I don't think a file format that changes its "extension" on every update is "sane" and I still think the EAPI version should not be part of the file name <13.03.2012 20:44> <@hwoarang> i haven't read the entire thread but I don't want to change the extension <13.03.2012 20:44> <@ulm> I think my opinion on the matter is clear ;) <13.03.2012 20:44> <@grobian> yeah it is <13.03.2012 20:44> <@grobian> ok, so my conclusion is that this council won't change the state of glep-55 <13.03.2012 20:44> <@Chainsaw> grobian: I agree with that summary. <13.03.2012 20:44> <@jmbsvicetto> as ebuild is a text format, I think EAPI should be defined on the header or top of the file <13.03.2012 20:44> <@grobian> so it's useless to bring it up again, if people ask for that <13.03.2012 20:45> <@Chainsaw> grobian: Indeed. <13.03.2012 20:45> <@ulm> BTW, ferringb and myself have started a wiki page to collect what has been proposed so far: http://wiki.gentoo.org/wiki/Alternate_EAPI_mechanisms <13.03.2012 20:45> <@jmbsvicetto> so it seems <13.03.2012 20:45> <@grobian> jmbsvicetto: the only real problem I see, and that is what Glep-55 solves, is what an older PM would do with a newer ebuild it doesn't grok <13.03.2012 20:46> <@ulm> grobian: see the wiki page :) <13.03.2012 20:46> <@grobian> however, I tend to believe that the possible scope of problems there in reality is fairly limited <13.03.2012 20:46> <@grobian> (I strongly dislike XML or Python ebuilds) <13.03.2012 20:46> <@jmbsvicetto> grobian: That's why I'd be open for a one-time extension change so that we could introduce some fault-tolerance / future-proof features in the PMs <13.03.2012 20:46> <@grobian> (if they ever come around, an extension change IS a good idea) <13.03.2012 20:46> <@grobian> jmbsvicetto: that's not the point of glep-55 <13.03.2012 20:47> <@grobian> jmbsvicetto: in that case, you can stick as well with .ebuild <13.03.2012 20:47> <@jmbsvicetto> yes, but to me that's what we should be looking into ;) <13.03.2012 20:47> <@grobian> ulm: excellent comparison/study material <13.03.2012 20:47> <@jmbsvicetto> grobian: sure, but if we really need to change the name to take advantage of that "mis-feature" of old PMs, I'd be ok with it <13.03.2012 20:48> <@jmbsvicetto> grobian: I just think we should try to pack as much sensible features as possible when we do that - so we don't have to do it again N months after <13.03.2012 20:48> <@grobian> jmbsvicetto: I don't see the point, Zac/ulm already gave ways to work around it <13.03.2012 20:48> <+dberkholz> i'd rather do it again N months after <13.03.2012 20:48> <@grobian> anyhow, this is just chat to me <13.03.2012 20:49> <+dberkholz> otherwise we spend forever trying to get a perfect solution that does it all <13.03.2012 20:49> <@grobian> not really something for the meeting per se <13.03.2012 20:49> <+dberkholz> when in reality, iteration works a lot better <13.03.2012 20:49> <@grobian> dberkholz: got some point in there <13.03.2012 20:49> <@jmbsvicetto> grobian: one thing that I think we should try to pack in this change is the discussion about the PM cache format <13.03.2012 20:50> <@grobian> isn't that something totally different? <13.03.2012 20:50> <@grobian> a portage internal? <13.03.2012 20:50> <@ulm> jmbsvicetto: I'd rather keep such discussions separate <13.03.2012 20:51> <+dberkholz> grobian: made that mistake enough times to see it coming these days =) <13.03.2012 20:52> <@jmbsvicetto> grobian: then there's also the idea of having a file under the top of a repo (inside metadata?) and the idea of reworking profiles <13.03.2012 20:52> <@jmbsvicetto> grobian: unless we can define a new cache format that could be used by all PMs <13.03.2012 20:52> <@grobian> aren't we now packing up the x-mas tree with everything we can, like we do for gx86 git migration? <13.03.2012 20:53> <@grobian> guarantee to get nowhere anywhere near soon <13.03.2012 20:53> <@grobian> see dberkholz <13.03.2012 20:54> <@jmbsvicetto> yes, I understand dberkholz's point <13.03.2012 20:55> <@jmbsvicetto> but I think we may need to rethink the tree / repo / cache structure and try to come up with a way that allows us to implement changes without requiring adding one-time files to repos or replacing ebuild extensions <13.03.2012 20:55> <@Betelgeuse> grobian: so you got the answer I guess, so anything else? <13.03.2012 20:56> <@jmbsvicetto> Betelgeuse: anyway, I'll stop now <13.03.2012 20:56> <@grobian> Betelgeuse: yeah, long ago, see my "summary" <13.03.2012 20:56> <@Betelgeuse> so next meeting <13.03.2012 20:56> <@grobian> that's after easter? <13.03.2012 20:57> <@Betelgeuse> 10th April yeah <13.03.2012 20:57> <@grobian> anyone else going on holiday for easter? <13.03.2012 20:57> <@hwoarang> 10th may be a bit odd <13.03.2012 20:57> <@grobian> if not, no point in trying to persuade to move the date <13.03.2012 20:57> <@hwoarang> as it is after easter and I will be on vacations :/ <13.03.2012 20:58> <@grobian> ah, number 2 <13.03.2012 20:58> <@hwoarang> grobian: i wont be here so I will be interested in changing the date <13.03.2012 20:58> <@jmbsvicetto> grobian: hopefully, the hospital move should be done around that date <13.03.2012 20:58> <@grobian> both 3 and 17 are fine for me <13.03.2012 20:58> <+dberkholz> i'll probably be traveling the afternoon of the 10th, not sure exactly when i'm leaving though <13.03.2012 20:58> <@Betelgeuse> so move to 17th? <13.03.2012 20:58> <+dberkholz> same goes for the 17th for me, actually =D <13.03.2012 20:58> <@grobian> I'd like that very much <13.03.2012 20:58> <@grobian> ah <13.03.2012 20:58> <+dberkholz> how about the 3rd? <13.03.2012 20:58> <@hwoarang> id prefer 3rd <13.03.2012 20:59> <@grobian> fine with me <13.03.2012 20:59> <@Betelgeuse> I can be in Pacific time but probably still works <13.03.2012 20:59> <@Betelgeuse> It should be ok time there too <13.03.2012 20:59> <@ulm> both 3 and 17 are o.k. for me <13.03.2012 20:59> <+dberkholz> that'll be 1pm pacific, it's fine generally speaking <13.03.2012 20:59> <@jmbsvicetto> I might be busy with the Hospital, but for the next month or so I won't know right until the meeting time <13.03.2012 21:00> <@Betelgeuse> jmbsvicetto: so no difference been 3rd and 10th? <13.03.2012 21:00> <@jmbsvicetto> no <13.03.2012 21:00> <+dberkholz> jmbsvicetto: gonna have a proxy on standby, then? <13.03.2012 21:00> <@jmbsvicetto> nor 17th likely <13.03.2012 21:00> <@jmbsvicetto> dberkholz: yeah, I'll try to get someone for next meeting <13.03.2012 21:00> <@Chainsaw> First Tuesday of the month is normally a linux user group meeting for me, but if that date works best I'll move it. <13.03.2012 21:01> <@grobian> ok, so 3rd it will be? <13.03.2012 21:01> <@ulm> seems so <13.03.2012 21:01> <@hwoarang> ok <13.03.2012 21:01> <@Betelgeuse> ok <13.03.2012 21:02> <@jmbsvicetto> Betelgeuse: btw, thanks for calling me. We have terrible coverage at the hospital, for now. That's why you didn't caught me <13.03.2012 21:02> <@ulm> start at 19:00 UTC because of DST? <13.03.2012 21:02> <@grobian> ulm: ok <13.03.2012 21:02> <+dberkholz> i just moved it to the 3rd in the google calendar <13.03.2012 21:02> <@Betelgeuse> ulm: ok <13.03.2012 21:02> <@hwoarang> ok <13.03.2012 21:02> <+dberkholz> sure, 1900 is fine <13.03.2012 21:02> <@jmbsvicetto> sure <13.03.2012 21:02> -!- ulm changed the topic of #gentoo-council to: Next meeting: April 3rd, 19:00 UTC | Meeting chairs: http://www.gentoo.org/proj/en/council/#doc_chap5 | http://www.gentoo.org/proj/en/council/utctolocal.html?time=1900 | http://www.gentoo.org/proj/en/council/ <13.03.2012 21:03> <@Betelgeuse> Did we have a practise on writing summaries. Presumably I'll post one? <13.03.2012 21:03> <@grobian> I'll send call for items next week then <13.03.2012 21:03> <@grobian> hmmm, if I have wireless reception then... <13.03.2012 21:03> <@Betelgeuse> Thanks everyone and see you next time. <13.03.2012 21:03> <@grobian> ulm: mind sending the call yourself, next tuesday? I'll be in the middle of knowhere <13.03.2012 21:04> <@Betelgeuse> grobian: atd? <13.03.2012 21:04> <@grobian> heh <13.03.2012 21:04> <@ulm> grobian: yes, I can do <13.03.2012 21:04> <@grobian> I'm not that advanced here <13.03.2012 21:04> <@grobian> I edit the emails each time <13.03.2012 21:04> <@grobian> ulm: ok, thanks <13.03.2012 21:04> <@Betelgeuse> grobian: that's why I said atd instead of crond :) <13.03.2012 21:05> <@grobian> too lazy to lookup how mutt is scripted <13.03.2012 21:05> <@grobian> ok, thanks for chairing Betelgeuse <13.03.2012 21:05> <@jmbsvicetto> Betelgeuse: thanks for chairing the meeting <13.03.2012 21:07> <@grobian> jmbsvicetto: I thought you referred to the release building process with the locale thing <13.03.2012 21:07> <@Chainsaw> Betelgeuse: Thanking you. <13.03.2012 21:07> <@Betelgeuse> no problem