[05:17] <pitti> @all: Today's TB meeting needs to start earlier, at 1700 UTC
[05:18] <jbailey> Err, that's awfully short notice for a change, isn't it?
[05:19] <jbailey> Oh good, agenda doesn't concern me really anyway.
[06:55] <seb128> hey dholbach :)
[06:55] <dholbach> hey :)
[06:56] <\sh> huhu daniel :)
[06:56] <ogra> hoho dholbach 
[06:56] <ivoks> howdy
[06:57] <ogra> dholbach, i added a mention of revu to the expanding universe goal, but didnt change the status
[06:58] <mdz> 2 minutes
[06:58] <ogra> dholbach, to make th eprogress visible
[06:59] <dholbach> ogra: excellent
[07:00] <mdz> good morning, everyone
[07:00] <mdz> waiting for sabdfl and Keybuk
[07:01] <ogra> :)
[07:01] <\sh> ogra: u made it? ,-)
[07:02] <Keybuk> (I'm almost entirely not present, but will respond if my name goes blue ;p)
[07:02] <ogra> \sh, with a lot of help from mvo (you should call him the AssemblerKing now)
[07:02] <\sh> ogra: good to know *eg*
[07:03] <mdz> ok, that's quorum at least :-)
[07:03] <dholbach> ogra: mvo rocks
[07:03] <ogra> yeh
[07:03] <mdz> we seem to have one MaintainerCandidate to process
[07:03] <ogra> +a
[07:03] <mdz> Ankur Kotwal?
[07:03] <ogra> DanielN ?
[07:03] <\sh> Unfrgiven: 
[07:03] <ogra> huh ? 
[07:03] <ogra> a
[07:03] <ogra> ah
[07:03] <\sh> Ankur is Unfrgiven
[07:04] <mdz> he's applying for MOTU
[07:04] <\sh> and DanielN_atw is not online
[07:04] <ogra> yep... i always muddle Ankur and Ante :)
[07:04] <sabdfl> hi all
[07:04] <ivoks> i'm Ante :)
[07:04] <ogra> hey sabdfl 
[07:04] <dholbach> hi mark
[07:04] <\sh> for Unfrgiven I can give a ++ for MOTU...he did a lot for cxx and stuff 
[07:04] <ogra> ivoks, i know.... but ivoks is more familiar ;)
[07:04] <ogra> absolutely
[07:05] <ogra> \sh++
[07:05] <sabdfl> mdz: you under way?
[07:05] <mdz> sabdfl: yes
[07:05] <mdz> sabdfl: currently Unfrgiven (https://wiki.ubuntu.com/AnkurKotwal) is being considered for MOTU maintainership
[07:05] <\sh> and for DanielN_atw , he made some progress in those 2 weeks after the last meeting and I think he would be a good candidate. Ogra, what do u think?
[07:05] <mdz> ogra and \sh both support his admission
[07:06] <dholbach> i worked with him on a package, but that's some weeks ago, he did it well
[07:06] <ivoks> ++ by me too 
[07:06] <dholbach> i read his name a cuople of times on the c++ library list
[07:06] <ogra> sabdfl, we also met hi at udu, he made good progress with packaging since then
[07:07] <ogra> him even
[07:07] <dholbach> that's true, ogra
[07:08] <sabdfl> ok, fine by me if ogra and \sh have worked with him and think he's up to it
[07:08] <ogra> absolutely :)
[07:08] <mdz> likewise
[07:08] <Keybuk> same for me
[07:08] <dholbach> excellent :)
[07:08] <ogra> yay :)
[07:08] <ivoks> great
[07:08] <\sh> heissa :)
[07:08] <dholbach> watch the MOTU team grow :)
[07:09] <sabdfl> welcome aboard Unfrgiven!
[07:09] <mdz> Unfrgiven: congratulations and welcome
[07:09] <\sh> he's going mad when he's hearing that :)
[07:09] <ogra> so welcome Unfrgiven (in sleeping absence )
[07:09] <mdz> next up, Riddell on choosing an office suite for Kubuntu
[07:09] <sabdfl> Riddell: is there a wiki page that outlines the options and arguments?
[07:09] <Riddell> sabdfl: no there isn't
[07:09] <sabdfl> this sort of thing is best done in spec format, as a proposal
[07:10] <Riddell> trouble is I don't yet have an answer to propose :)
[07:10] <Riddell> koffice is faster and smaller and integrated
[07:10] <sabdfl> because whichever way it goes, in future people will want to know what was factored into the decision
[07:10] <mdz> the guiding principle should be to do whatever the KDE community will love
[07:10] <pitti> Riddell: what about stability?
[07:10] <sabdfl> mdz: agreed
[07:10] <\sh> Riddell: what about the compatiblity to ms office?
[07:10] <ogra> mdz, whyt about MS compatibility ?
[07:10] <Riddell> openoffice is probably less buggy and more compatible with MS Officce
[07:10] <pitti> Riddell: OO.o is a pain both stability- and performance-wise, is KOffice any better?
[07:10] <\sh> ogra: *g*
[07:10] <ogra> heh
[07:10] <sabdfl> in addition, since openoffice is in main, we should also make sure that k-oo.o love is around and available, even if it isn't the default
[07:11] <Riddell> pitti: it's a lot better performance wise, not so stability wise
[07:11] <mdz> ogra: see above; if MS compatibility is of great importance to the KDE community, they will factor that into their opinions
[07:11] <Mithrandir> sabdfl: k-oo.o love is utterly painful for amd64.
[07:11] <sabdfl> Riddell: we had a similar debate around abiword + gnumeric vs oo.o
[07:11] <\sh> mdz: i don't think it has to do with KDE alone...it's a matter of integration of * Linux into the office structure of companies
[07:11] <sabdfl> Mithrandir: is that true for the goo.o too.o?
[07:11] <Riddell> sabdfl: where can I find out about the discussions of that?
[07:11] <Mithrandir> sabdfl: less so, but yes.
[07:12] <Mithrandir> sabdfl: that is, more packages => more pain.
[07:12] <mdz> \sh: to a certain extent, such companies will make their own decisions about which software to use
[07:12] <ogra> mdz, true.... but still non KDE people will switch too :)
[07:12] <sabdfl> Riddell: poorly documented i'm afraid, we mostly had it on irc in the SSDS days
[07:12] <mdz> the default should be the "right thing" for a KDE-oriented distribution
[07:12] <\sh> mdz: and most of the companies using OOo as a choice 
[07:12] <mdz> what do other KDE distributions do?
[07:12] <Mithrandir> sabdfl: I'm throwing in a data point, I'm not trying to veto (which I wouldn't be able to) k-oo.o.
[07:12] <\sh> they put both
[07:12] <Riddell> mdz: the only distribution to ship with koffice is mepislight
[07:12] <ivoks> oo.o seems more mature atm, but koffice is doing great improvment, imho
[07:12] <Riddell> ship as default that is
[07:13] <sabdfl> Mithrandir: your say counts for a lot around here, so don't be shy
[07:13] <Riddell> one agrument is that if nobody uses koffice then it will never improve
[07:13] <Mithrandir> sabdfl: the pain will be significantly less with ooo2 once we get it usable in a 64 bit form.
[07:13] <sabdfl> Riddell: similarly for Gnome office and KOffice, though
[07:13] <mdz> the 32-bit stuff for oo.o2-kde will be painful, yes,, but we'll need to do it regardless of which office suite is default in kubuntu
[07:13] <\sh> Riddell: what about shipping with koffice and OO?
[07:13] <Riddell> \sh: no space for that
[07:14] <sabdfl> and with java and sun, there's a feeling that it would be good to have strong ground-up-free office suits
[07:14] <mdz> how big is koffice?
[07:14] <ogra> \sh, no redundancys !
[07:14] <Riddell> although we will probably ship with kexi (database) and krita (drawing)
[07:14] <Mithrandir> mdz: but we won't have to package half of kde in ia32-libs-kde if we don't use ooo for kubuntu.
[07:14] <sabdfl> mdz: is oo.o2 64-bit K difficult because of the C++ nature of K?
[07:14] <Riddell> mdz: source is 20MB
[07:15] <mdz> sabdfl: it's difficult because KDE has a huge dependency chain which would need to be repackaged a la ia32-libs
[07:15] <ivoks> 20?
[07:15] <mdz> Mithrandir: even if kubuntu uses koffice by default, we should have oo.o2-kde available on all supported architectures
[07:15] <Mithrandir> sabdfl: ooo2 64 bit is difficult because the programmers writing staroffice thought that having assembly in a office suite made sense.
[07:15] <Mithrandir> mdz: do I get an extra bottle of whisky a month to endure the pain? ;-)
[07:15] <\sh> Mithrandir: no whisky while you're working ;-)
[07:16] <Riddell> koffice .debs are 21MB
[07:16] <Mithrandir> \sh: you haven't done ia32-libs, I see. :-)
[07:16] <uniq> the (few) comments on koffice vs. oo.o on kubuntu-users@list are all more or less pro oo.o.
[07:16] <pitti> \sh: you need the alcohol to double the 32 bit
[07:16] <\sh> Mithrandir: nope...but other nasty stuff;)
[07:16] <mdz> Riddell: what is your gut feeling?
[07:16] <\sh> pitti: yeah...this I know perfectly ;)
[07:16] <Mithrandir> anyhow, ooo is k-able on amd64 just fine, it's just painful.
[07:17] <dholbach> stabitily and exchangebility maybe should be the keypoint, imho - since people judge a distribution by what they use and what (and probably what not) works for them  --- i say that without being a fan of oo.o and its not-integrated-ness, and i agree with riddell on getting users for improving, new products
[07:17] <Riddell> mdz: I've been trying to use koffice as much as possible this last week since 1.4 release.  for lugradio live kpresenter couldn't open it's own slides and I had to re-do my whole talk.  that put me towards keeping openoffice
[07:17] <pitti> Riddell: is "not so stable" == "it crashes every half an hour"? or is it better?
[07:17] <\sh> Riddell: do u think the userbase will increase for koffice, if kubuntu is shipping it as default?
[07:17] <pitti> Riddell: I'd judge stability over performance
[07:18] <Riddell> pitti: "it crashes every half an hour" isn't too far off I suspect
[07:18] <pitti> Riddell: then you will rather scare away people with it, I'm afraid
[07:19] <Riddell> \sh: yes I do
[07:20] <\sh> Riddell: so, ship it...we have OO in anyway available
[07:20] <mdz> Riddell: so if you're leaning toward openoffice, and kubuntu-users seems to be leaning the same way, is there someone who can speak for koffice?
[07:20] <pitti> Riddell: ... not that OO.o wouldn't be scary on any but the latest and greatest number crunching hardware
[07:20] <Riddell> \sh seems to speak for koffice 
[07:20] <Riddell> amu is a big koffice fan
[07:20] <ogra> \sh, whats the use of an ofiice suit that crashes every 1/2h, have fun with the bugreports you cant solve in a stable distro ?
[07:21] <Mithrandir> I was a fan of koffice five years ago, but it sounds like it might not have moved too much since then?
[07:21] <\sh> ogra: well, thinking of ms word which is crashing for me every single time I try to open a big document I don't have anything against a crashing presenter
[07:22] <dholbach> it's the same for gnome: abiword and gnumeric, but without a presenting software, you can't hand gnome-office to the average user yet, that's disappointing, but that seems to be life atm :-/
[07:22] <ivoks> we can't ship crashing app.
[07:22] <pitti> \sh: that isn't the thing we should compare software to
[07:22] <\sh> lets say it like this: if kubuntu is shipping as default with koffice, we can also try to stablelize it
[07:22] <sabdfl> Mithrandir: if we were to put a google-size bounty on proper oo.o2 64-bit support, is there anyone you can think of in the upstream crowd who could take it on?
[07:22] <ogra> \sh, we'll talk about it after you lost your first ubuntu slides 1/2h before the telk ;)
[07:22] <sabdfl> upstream being oo.o community
[07:22] <ogra> talk
[07:22] <pitti> dholbach: gnumeric is a great piece of software, it jsut works and is fast (as opposed to OO.o spread, which is buggy and slow as hell)
[07:22] <Mithrandir> sabdfl: I don't know upstream, so no, but I could look around.
[07:22] <\sh> pitti: we have OO in the repos...so the user is able to install OO  in an way
[07:22] <pitti> dholbach: it's abiword that sucks, though
[07:23] <dholbach> pitti: anyway, gnome-office just isnt ready yet :-/
[07:23] <pitti> \sh: right, but only one will be shipped on the CD
[07:23] <pitti> dholbach: agreed
[07:23] <ogra> pitti, its the missing presentation program that sucks imho
[07:23] <pitti> \sh: the point is, many users can't download big debs, they depend on a CD
[07:23] <uniq> \sh: koffice is smaller to download.
[07:24] <ivoks> then with koffice, you could put more apps on CD?
[07:24] <ivoks> that would be + for koffice
[07:24] <seb128> pitti: what's wrong about abiword?
[07:24] <mdz> Riddell: I think the best thing to do is to collect points in favor of each suite and document them on a wiki page
[07:24] <mdz> Riddell: once that's done, the answer could well be obvious
[07:24] <\sh> well, from my point of view, I would like to see KDE applications on a kde distro and vice versa.
[07:24] <Mithrandir> sabdfl: Pavel Janik is doing some work on it already. pavel@janik.cz
[07:24] <pitti> seb128: it lacks too much important features, and the MS compatibility is much worse than OO.O's
[07:25] <Riddell> mdz: sounds like a plan
[07:25] <seb128> pitti: bah, not the place to argue about that :)
[07:25] <sabdfl> Mithrandir: is he upstream? distro? good credentials?
[07:25] <pitti> seb128: however, I only use gnumeric, and I never ever use a WYSIWYG word processor, so don't count on my opinion about abiword too much
[07:25] <seb128> pitti: happy about gnumeric? :)
[07:25] <pitti> seb128: gnumeric rocks
[07:25] <seb128> yeah ;)
[07:25] <sabdfl> ok, i think this needs to be specced
[07:25] <sabdfl> Riddell: could you put a spec together?
[07:26] <sabdfl> Oo.O2 vs KOffice - the default in Kubuntu
[07:26] <Riddell> sabdfl: I'm not sure what that would be.  isn't a spec more "we will do this" rather than "which should we do"?
[07:26] <mdz> right, the comparison chart we discussed would form the meat of a spec
[07:26] <sabdfl> Riddell: it starts with "these are the options"
[07:26] <mdz> just add some background to it
[07:26] <pitti> Riddell: after that discussion, do you think KOffice is still an option to consider?
[07:26] <sabdfl> then when there's a decision, you put that at the top
[07:26] <sabdfl> so afterwards it reads:
[07:27] <sabdfl>  "this spec documents our decision to run with OO.o2 for Kubuntu Breezy"
[07:27] <sabdfl>  "rationale"
[07:27] <sabdfl>  blah blah blah
[07:27] <pitti> Riddell: (I don't want to imply a "no" in any way)
[07:27] <sabdfl> </subliminal advertising>
[07:27] <mdz> Riddell: invite the kubuntu community to add their own thoughts to the list, within guidelines (keep it objective)
[07:27] <sabdfl> yes, the doc is open so people with an interest in either course of action can add pro's and con's
[07:28] <Keybuk> (
[07:28] <mdz> if it's still unclear at that point, we'll discuss it again with this additional context
[07:28] <Keybuk> sorry, desktop crapped out and decided that it didn't want to be on there
[07:28] <sabdfl> then it's easier to bring it to the TB and take an up or down vote amongst the kubuntu leaders and tb
[07:28] <Mithrandir> sabdfl: I think he's upstream, yes.  His blog has 271 entries on ooo and he's been doing amd64 porting for a bit of fair time.  I don't know him personally so I can't comment on his saneness, but it seems to be ok.
[07:28] <sabdfl> cool
[07:28] <Riddell> pitti: I think it's an option, see jdub's speach on how gnome office can overtake openoffice.  same for koffice
[07:28] <sabdfl> Riddell: there are definitely arguments in favour of lightweight native tools
[07:28] <pitti> Riddell: ok, great. well, spec and argument collection sounds really sane then IMHO?
[07:29] <sabdfl> but we do have to make a decision on the default
[07:29] <sabdfl> even if both end up in main, as we did with gnome office
[07:29] <sabdfl> anything more on Kubuntu Office?
[07:30] <Riddell> I'll write the spec then
[07:30] <Mithrandir> sabdfl: he's a Novell employee, fwiw.
[07:31] <sabdfl> Mithrandir: could be interesting :-)
[07:31] <mdz> ok, next up, pitti on language packs
[07:31] <Mithrandir> sabdfl: well, I guess they're interested in a 64 bit OOo this year too..
[07:31] <sabdfl> Riddell: you don't have to write it any further than needed to justify your own viewpoint, get someone else to argue the other side :-)
[07:31] <pitti> I wrote about the problem yesterday
[07:32] <pitti> so far I still think that the solution proposed in the udu spec (split up packs into -main/-gnome/-kde) is the way to go
[07:32] <pitti> however, I'd like to collect more opinions about that
[07:32] <pitti> the actual source of problem is that Kubuntu is not a proper derivative
[07:32] <seb128> 3) from the mail seems to be best option imho
[07:32] <pitti> with its own archive and so on
[07:33] <sabdfl> "    Besides language-support-lang, Kubuntu additionally installs kde-i18n-lang.  "
[07:33] <sabdfl> pitti: how do you propose to do that?
[07:33] <pitti> sabdfl: that is to avoid splitting the -support packages, too
[07:33] <pitti> sabdfl: it's already done
[07:33] <sabdfl> if someone wants to add a new language to the system, how does the system know to install the -kde or the -gnome pack?
[07:33] <pitti> sabdfl: the Kubuntu installer just does it and our language selector application can do it, too
[07:34] <sabdfl> pitti: how does it know if the user has, for example, installed Kubuntu and added abiword?
[07:34] <ivoks> khm...
[07:34] <pitti> sabdfl: the crude solution would be that langpack-o-matic just checks whether gnome and/or kde is installed
[07:34] <sabdfl> pitti: see above - "gnome" and "kde" become fuzzy concepts over time
[07:34] <sabdfl> it's easy at install time
[07:34] <sabdfl> hard once the sysadmin starts adding and removing packages
[07:34] <pitti> sabdfl: the fine-grained one is to check which packages are installed, so that the relevant pack could be installed if needed
[07:35] <pitti> sabdfl: so if language selector sees "ah, abiword is installed", it would pull in the gnome one
[07:35] <pitti> sabdfl: it's not an optimal solution, I'M aware of that
[07:35] <pitti> sabdfl: it also makes elmo cry because it will add 400 packages
[07:35] <pitti> sabdfl: but I don't know a better solution
[07:35] <Mithrandir> this sounds like a good use case for Enhances: support, btw.
[07:36] <pitti> if anybody does have a better solution, speak up :-)
[07:36] <Mithrandir> pitti: implement support for Enhances in dpkg and apt. :-)
[07:36] <pitti> Mithrandir: how does that help to not split langpacks?
[07:36] <mdz> pitti: the root problem is what?  a combined language pack is too large?
[07:37] <pitti> mdz: yes, we can't fit them all onto the CDs
[07:37] <mdz> we already can't fit them all onto the CD
[07:37] <mdz> how many would we lose?
[07:37] <pitti> mdz: KDE translations alone are bigger than main+gnome right now
[07:37] <mdz> so we would lose more than half?
[07:37] <Mithrandir> pitti: it helps the packaging system note that "oh, you have this installed, then you probably want this too".
[07:37] <pitti> mdz: we ship all on most CDs
[07:37] <pitti> Mithrandir: ugh, that would be pretty intrusive; I think mvo and I had a better solution for the langpack selector at least
[07:38] <mdz> pitti: we ship all on 2 out of 6 CDs ;-)
[07:38] <pitti> oh?
[07:38] <pitti> hm
[07:38] <pitti> yes, we would loose more than half of the translations
[07:38] <dholbach> "order your ubuntu cd-case today."
[07:38] <mdz> but one of those two is the i386 install CD, which accounts for a disproportionate number of uses
[07:38] <\sh> is a dvd not cheaper then?
[07:38] <Mithrandir> dholbach: s/case/backpack/. :-)
[07:38] <pitti> well, DVDs would solve the problem at instant :-)
[07:38] <mdz> \sh: DVDs are more expensive than CDs
[07:39] <mdz> and less portable
[07:39] <ivoks> is it possible to do CDs by area? east europe, midle east, etc?
[07:39] <sabdfl> \sh: we still have to focus on 650MB CD's, unfortunately
[07:39] <pitti> or make Kubuntu a proper derivative with its own archive
[07:39] <ogra> \sh, not everybody has a DVD reader
[07:39] <mdz> ivoks: it is possible to create them, but it is impractical to test them
[07:39] <mdz> ivoks: we already must test 8 images for each release candidate
[07:39] <pitti> mdz: if langpack-o-matic could create different langpacks for Kubuntu than for Ubuntu, that would rock, but with the current structure it can't
[07:39] <\sh> ogra: yes :) i forgot the *grmpf* ;)
[07:39] <mdz> er, 9
[07:39] <ivoks> oh, then this would be too much
[07:40] <ivoks> didn't think of that :)
[07:40] <mdz> pitti: what's the least intrusive way to split the langpacks?
[07:40] <pitti> one alternative would be to split it to l-p-ubuntu and l-p-kubuntu
[07:40] <pitti> and copy the common stuff into both
[07:40] <pitti> but that's ugly IMHO
[07:40] <sabdfl> pitti: i'm happy with your first proposal
[07:40] <mdz> unified language packs, while inefficient in terms of space, are awfully attractive due to their simplicity
[07:41] <sabdfl> it just means the language selector needs to be smart
[07:41] <pitti> mdz: right
[07:41] <pitti> sabdfl: so we don't support KDE translations in Rosetta?
[07:41] <sabdfl> mdz: you mean install all the gnome translations on a fresh kubuntu box?
[07:41] <mdz> sabdfl: I mean the approach we're already using
[07:41] <pitti> sabdfl: would be the easiest solution, but redundant and non-symmetrical
[07:42] <sabdfl> pitti: what's non-symmetrical about -base, -gnome and -kde?
[07:42] <pitti> mdz: what do you mean by "way to split"?
[07:42] <pitti> sabdfl: oh, I thought you meant (1) in my mail
[07:42] <mdz> pitti: I can't find your email; what was the subject?
[07:42] <pitti> sabdfl: (1) in mail was the status quo
[07:42] <mdz> ah, found it
[07:42] <sabdfl> no, LanguagePackRoadmap
[07:42] <pitti> "27.06.05 18:43 Martin Pitt       Preparing tomorrow's language pack TB topic"
[07:42] <pitti> sabdfl: ah, ok, so that would be the split
[07:43] <sabdfl> it has its warts, but i can't see a better one
[07:43] <mdz> pitti: is there any significant advantage of (3) over (1) for breezy?
[07:43] <Riddell> mdz: it means kubuntu has translations on CD
[07:43] <mdz> Riddell: gnome translations, you mean?
[07:43] <pitti> mdz: Rosetta support mainly
[07:44] <pitti> mdz: and Kubuntu does not need to ship gnome translations and instead has room for kde ones
[07:44] <Riddell> mdz: 3 means we have translations, 1 means we don't have KDE translations
[07:44] <pitti> well, there is no golden solution anyway, we just have to choose the pain
[07:44] <mdz> pitti: why does (1) make rosetta support impossible?
[07:45] <Riddell> mdz: nowhere for rosetta to output to
[07:45] <pitti> mdz: not impossible, but we had to regenerate kde-i18n-foo, which consists of more than translations
[07:45] <mdz> oh, I see, it uses kde-i18n-foo rather than language-pack-kde
[07:45] <pitti> mdz: it would be possible, I guess, with some hacking
[07:45] <mdz> (3) seems the clear winner, to me
[07:46] <pitti> would it be possible to give Kubuntu it's own archive?
[07:46] <mdz> not for breezy
[07:46] <pitti> or would that make sense?
[07:46] <pitti> no, not for breezy, but in the long run
[07:46] <pitti> I think we could live with option (1) for breezy
[07:46] <pitti> if we have a solution in sight for breezy+n
[07:47] <mdz> we should take advantage of rosetta for kubuntu
[07:47] <pitti> understandable
[07:48] <pitti> mdz: I think the biggest con of (3) is the hoary->breezy upgrade
[07:48] <mdz> I don't see that as a major issue
[07:49] <mdz> when the language pack is upgraded, we'll drop an update-notifier hook to prompt the user to reconfirm their language settings
[07:49] <pitti> well, upgrade notes, just as for Hoary (when users lost all their translations as well)
[07:49] <pitti> that sounds good
[07:49] <mdz> any further unresolved issues regarding language packs?
[07:50] <pitti> Ineed to convince elmo to accept 400 new packages :-)
[07:50] <pitti> anybody has serious issues with (3)?
[07:50] <mdz> elmo: would you like to weigh in on this?
[07:50] <ogra> pitti, give them to doko, then elmo wont even recognize ;)
[07:51] <pitti> ok, thanks guys for your input
[07:51] <mdz> ok, you can follow up with elmo later if he takes issue with it
[07:51] <pitti> ok, I'll do
[07:51] <mdz> next up, REVU with no person associated with it
[07:52] <mdz> ogra?
[07:52] <sabdfl> hmm... sec
[07:52] <pitti> it's always better to hear more than just the own opinion when trashing he archive :-)
[07:52] <\sh> and ogra :) and dholbach
[07:52] <sabdfl> linspire just did their German edition release
[07:52] <ogra> mdz, you could put MOTU aside :)
[07:52] <sabdfl> they wait till they have a certain coverage of translations, then release a dedicated iso
[07:52] <sabdfl> has the advantage that the installer can skip the language question
[07:52] <sabdfl> and just install the language it is dedicated to
[07:52] <mdz> ogra: /me points to the "INCLUDE YOUR NAME" comment in the wiki
[07:53] <sabdfl> i wondered if there is any interest in us making similar releases?
[07:53] <mdz> sabdfl: we've discussed it; the primary issue is testing
[07:53] <ogra> mdz, i didnt put it there ... \sh !
[07:53] <ogra> :)
[07:53] <Mithrandir> sabdfl: but then, you get to keep half a gazillion ISOs on cdimage.
[07:53] <mdz> we need to at least sanity check every ISO release
[07:53] <sabdfl> mdz: i don't know how this would fit into the broader picture, i would not want to amp up the number of iso's on the main release
[07:53] <\sh> mdz: put the blame on me pls :) i need to put it asap on the agenda :)
[07:53] <mdz> if we do 10 localized ISOs, we need to test them all
[07:53] <sabdfl> i suspect these would best be distributed from the loco websites
[07:53] <mdz> 10 locales x 3 architectures = 30 more test cases
[07:53] <sabdfl> we would only do releases that the loco teams want, they test, when they're happy, we push the button
[07:54] <Mithrandir> mdz: have we considered doing some sort of automated testing similar to the lab joeyh has set up?
[07:54] <pitti> right now we still have the ability to ship 10 translations on a CD, which make them somewhat more universal
[07:54] <mdz> Mithrandir: where "considered" -> "gee, that would be nice"
[07:54] <ogra> sabdfl, you mean additional localized ones ? or our default release ?
[07:54] <ivoks> sabdfl: maybe is possible to have more locos in same image, this way more loco teams would work on testing
[07:54] <pitti> sabdfl: that would make much sense with translations we don't put on CDs though, even if the images are sort of unofficial
[07:54] <sabdfl> ivoks: that's a cool idea
[07:55] <Mithrandir> mdz: not "gee, that would be nice, let us commit some resources to it"?
[07:55] <sabdfl> if we could automate the process of generating the install iso, we could make this work
[07:55] <mdz> sabdfl: I expect we would need the launchpad infrastructure in order to manage production of localized ISOs
[07:55] <sabdfl> mdz: absolutely
[07:55] <mdz> maintaining that many sets of seeds is impractical in our current setup
[07:55] <sabdfl> i'll bounce the idea off kinnison in brazil
[07:56] <mdz> ok, can we close the language pack discussion?
[07:56] <sabdfl> ok
[07:56] <sabdfl> thanks
[07:56] <pitti> from my side yes
[07:56] <pitti> thanks 
[07:57] <ogra> revu !
[07:57] <mdz> right, next is \sh on REVU
[07:57] <ivoks> :>
[07:57] <\sh> yes
[07:57] <\sh> I don't know if anybody is informed about our new toy :) 
[07:57] <ogra> \sh, give us an introduction :)
[07:57] <mdz> \sh: perhaps a one-line explanation of what REVU does, for the benefit of those listening at home :-)
[07:57] <sabdfl> url again?
[07:57] <ogra> http://siretart.tauware.de/revu/
[07:57] <ivoks> http://siretart.tauware.de/revu/
[07:57] <\sh> https://wiki.ubuntu.com/REVU?highlight=%28REVU%29
[07:58] <\sh> to have a view inside, please refere to http://revu.ubuntu.linux-server.org/
[07:58] <\sh> I created an account for you all, that u can have a look inside 
[07:58] <\sh> username: sh@linux-server.org and pw: sabdfl  ;)
[07:58] <ogra> sabdfl, its a tool for test autobuilding packages, collecting comments and seeing all data about a package that should get reviewed
[07:58] <\sh> (will be deleted in anyway after this meeting :))
[07:59] <\sh> some adds to ogra: 
[07:59] <dholbach> and collecting advocates (3 for MOTU NEW packages)
[07:59] <ogra> yeah
[07:59] <\sh> right now we're reviewing newpackages for MOTU via wiki..which is not bad, but it's sometimes confusing
[07:59] <ogra> so it perfectly mirrors our review process
[07:59] <ogra> and its written in python :)
[08:00] <\sh> so siretart had an idea of doing it via a webinterface, with database and build automation
[08:00] <\sh> siretart and a friend of him wrote this nice little peace of software, and now we're trying to establish it to the motu world :)
[08:01] <sabdfl> ROCKS!
[08:01] <\sh> right now, uploading packages (debuild -S -sa) and putting comments etc. is working. the test build is included the next days
[08:01] <dholbach> automatic linda and lintian are additional features
[08:01] <ogra> but we feel it would belong into the DC, but we need a sbuild capable environment, so a vserver might not work
[08:01] <\sh> we have only limited resources on our servers, siretart has only a vserver without the possibility to create a sbuild env. and I have only my server with more then one service running on it
[08:01] <ogra> (strike one but :) )
[08:02] <\sh> dholbach: it's included already ;)
[08:02] <\sh> we can inject all automatic tests we need through hooks
[08:02] <dholbach> \sh: i didn't say they were missing :)
[08:03] <\sh> ok, now we're looking for a permanent home :)
[08:03] <mdz> \sh: are you interested in working on AutomatedTesting as well? ;-)
[08:03] <mdz> right, the matter at hand
[08:03] <sabdfl> are the linode servers not capable of sbuild?
[08:03] <\sh> mdz: let me do my other todos first :) 
[08:04] <Kamion> surely you can chroot from a vserver ...
[08:04] <mdz> assuming you get root in the vserver
[08:04] <ogra> mdz, \sh  first needs to write a KDE version of gnome-power )
[08:04] <\sh> Kamion: sbuild also? would u provide us with a solution? what we found out, that we need admin capabilities
[08:05] <\sh> and then update-manager and SER and my normal work, and then life 
[08:05] <sabdfl> mdz: i think linode gives you root
[08:05] <sabdfl> it's either Xen or UML based
[08:05] <ogra> \sh, forget about your normal work, who nees TV anyway :)
[08:05] <Kamion> \sh: if you don't have root, then indeed that would be a problem; if you do, then it's relatively straightforward assuming sufficient disk space
[08:05] <mdz> sbuild just requires root
[08:06] <\sh> ogra: u pay my rent? ,-)
[08:06] <ogra> heh, depends *g*
[08:06] <\sh> and my wife ;-) 
[08:06] <\sh> ex at least ;)
[08:06] <ogra> NO !
[08:06] <\sh> more expensive ;)
[08:06] <ogra> yep
[08:06] <dholbach> guys... :)
[08:06] <ogra> ok, offtopic here
[08:07] <mdz> \sh: so is the root issue that you need help setting up sbuild?
[08:07] <ogra> mdz, nope, we'd like a machine in the DC
[08:07] <sabdfl> ogra: why?
[08:07] <\sh> mdz: it's that and resources...I can handle only a bit more...but then my server will break 
[08:08] <ogra> sbuild in the test env is already running
[08:08] <sabdfl> how about a linode?
[08:08] <ogra> sabdfl, can we ge sbuild running there ?
[08:08] <ogra> get even
[08:08] <sabdfl> ogra: yes, i believe so, it's a root environment
[08:08] <sabdfl> UML i think
[08:08] <ogra> ah, great, then this would suffice
[08:09] <elmo> uh
[08:09] <ogra> elmo, objections ?
[08:10] <sabdfl> elmo: we need to get a purchase order for a bunch of linode's in
[08:10] <elmo> this is a buildd that only accepts uploads signed by universe maintainers right?
[08:10] <ogra> elmo, yes
[08:10] <sabdfl> then we need a very lightweight process to get those fired up
[08:10] <\sh> elmo: yes
[08:10] <dholbach> elmo: and MOTU hopefuls
[08:10] <ogra> elmo, with additional acess control before
[08:10] <elmo> if so - I'm 95% completed work on something that makes it a moot point
[08:10] <elmo> oh, ok, not for MOTU hopefuls
[08:10] <mdz> this is essentially entirely untrusted stuff
[08:11] <mdz> it's probably not even signed at the moment
[08:11] <elmo> ok, nm then
[08:11] <sabdfl> elmo: we will need the "build a package for anybody" stuff in due course, but i think linode is the answer for this one
[08:11] <mdz> and certainly not by a key we can authenticate
[08:11] <\sh> there is no package coming from this system
[08:11] <elmo> sabdfl: want me to sort that out?
[08:11] <sabdfl> elmo: yes please
[08:11] <\sh> all packages are reviewed only and uploaded by MOTUs with upload right to universe
[08:12] <mdz> sabdfl: as long as it doesn't steal cycles from backports ;-)
[08:12] <dholbach> \sh: NO, they are uploaded by MOTU hopefuls as well
[08:12] <ogra> dholbach, he means in the end
[08:12] <dholbach> ogra: well uploads to the archive were already handled before :)
[08:13] <ogra> dholbach, yeps
[08:13] <ogra> :)
[08:14] <mdz> ok, so the resolution is to set up a linode system to run these builds
[08:14] <mdz> any further unresolved issues?
[08:14] <sabdfl> \sh: we will pay for the linode system, she's yours to play with
[08:14] <mdz> \sh: will this meet your needs?
[08:14] <\sh> sabdfl: we are honoured :) and I have to say thx for siretart in absence as well :)
[08:15] <sabdfl> elmo: let's talk about a streamlined linode-for-community deal tomorrow?
[08:15] <\sh> mdz: of course
[08:15] <elmo> sabdfl: sure
[08:15] <sabdfl> elmo: are you in london tomorrow?
[08:15] <elmo> sabdfl: all week
[08:15] <sabdfl> cool
[08:15] <mdz> I am in london in ~48 hours
[08:15] <sabdfl> next up?
[08:15] <sabdfl> mdz: rock :-)
[08:15] <ogra> sabdfl, done :)
[08:15] <mdz> that's the end of the agenda
[08:15] <mdz> any other business?
[08:16] <sabdfl> \sh: REVU looks very cool, well done
[08:16] <\sh> sabdfl: I will report it to siretart, I think he will be very proud to hear that :) 
[08:16] <ogra> sabdfl, its siretarts baby, \sh has set up the backend
[08:17] <mdz> ok, looks like it's safe to adjourn
[08:17] <mdz> thanks, everyone
[08:17] <\sh> thx mdz
[08:17] <ogra> thanks mdz 
[08:17] <pitti> thanks folks
[08:18] <dholbach> thanks mdz