[12:13] <JaneW> ok time for bed
[12:13] <JaneW> night all <- this time it is ME saying good night
[12:14] <ogra> night JaneW 
[01:06] <terrex> when the meeting will start?
[01:07] <Mithrandir> there's a kernel meeting at 1600UTC and a backports meeting at 1930UTC today.
[01:08] <terrex> thx
[05:52] <Nafallo> thanx fabbione 
[05:52] <fabbione> http://lists.ubuntu.com/archives/kernel-team/2005-May/000527.html
[05:52] <fabbione> this is the agenda for today :)
[05:53] <Kamion> I'll be around sort of if you need me for installer stuff, but you'll need to get my attention by saying my nick
[05:55] <fabbione> Kamion: ok thanks :)
[05:55] <zul> blah
[05:55] <toresbe> that's not me, btw :P
[05:55] <tore_> toresbe: =] 
[05:57] <zul> i just won a poker tournament yeah!
[05:57] <zul> anyways
[05:57] <fabbione> just to refresh your mind:
[05:57] <fabbione> http://lists.ubuntu.com/archives/kernel-team/2005-May/000527.html
[05:57] <fabbione> ^^agenda
[05:57] <fabbione> http://udu.wiki.ubuntu.com/LinuxKernelRoadmap
[05:57] <fabbione> and roadmap
[05:58] <zul> less than a hour? that is goign to be a record
[05:58] <fabbione> well i hope it can be less than one hour :)
[05:58] <zul> it will
[05:59] <ogra> guys, we need this room at 19:00 UTC again for backporting things.... so speed up ;)
[06:00] <fabbione> ogra: i read it was at 19:30 but ok :)
[06:00] <fabbione> ok it's 16:00 UTC now
[06:00] <Lathiat> what time is it now?
[06:00] <fabbione> let's start
[06:00] <Nafallo> ogra: thanx. I just wondered when it was ;-)
[06:00] <fabbione> welcome everybody
[06:00] <ogra> err, yes... but we need to clean up your mess before ;)
[06:00] <fabbione> today we will review the status of the spec implementation
[06:00] <zul> shhhush 
[06:00] <fabbione> and we will assign the last few remaining tasks to people
[06:01] <fabbione> most of the stuff has been happily done
[06:01] <fabbione> as a side note, the release for 2.6.12 final seems to be delayed upstream
[06:01] <infinity> Not delayed long enough to be an issue, though.
[06:01] <zul> surprise surprise
[06:01] <fabbione> so the first 4 points might slow down a bit
[06:01] <jbailey> What's the spec clalled so we all have the same one up?
[06:01] <fabbione> http://udu.wiki.ubuntu.com/LinuxKernelRoadmap
[06:02] <jbailey> tx
[06:02] <fabbione> so let's go point by point
[06:02] <fabbione> infinity: right
[06:02] <fabbione> we are already building 2.6.12rcX with gcc-3.4 and so far we have received no complains about regressions
[06:02] <fabbione> and that's good
[06:02] <fabbione> gcc-4.0 is still known to miscompile the kernel
[06:03] <fabbione> point 2 is dependent on upstream
[06:03] <fabbione> same goes for 3 and 4
[06:03] <fabbione> work that can be done in parallel:
[06:03] <infinity> Do e have any idea where gcc-4.0 is miscompiling the kernel?
[06:03] <Lathiat> Is it likely to get that fixed before shipping ?
[06:03] <fabbione> infinity: afaik there are bugs open upstream with specific details
[06:03] <fabbione> Lathiat: we don't know
[06:04] <Lathiat> Because that raises issues compiling out of tree drivers, etc
[06:04] <fabbione> that depends a lot
[06:04] <fabbione> Lathiat: external drivers will have to be compiled with the proper gcc. if they use the kbuild system they will be fine
[06:04] <infinity> Lathiat : Out of tree modules should be able to set kgcc to something sane.
[06:04] <fabbione> otherwise they are on their own
[06:04] <fabbione> the problems with gcc-4.0 are:
[06:04] <zul> Lathiat: most of the external drivers that we use have been switched to kbuild
[06:04] <fabbione> 1) gcc-4.0 doesn't compile the kernel
[06:05] <Lathiat> hrm vmware musnt use kbuild ?
[06:05] <fabbione> 2) some kernel code is not gcc-4.0 compliant
[06:05] <zul> we dont use vmware :)
[06:05] <Lathiat> anyway
[06:05] <fabbione> anyway
[06:05] <fabbione> chmj: can you plese give us a status update on thirdy part drivers tracking tool?
[06:05] <chmj> its finished 
[06:05] <fabbione> chmj: ok.. we need to get the code :)
[06:06] <chmj> just need to document it and then you can test it 
[06:06] <fabbione> chmj: ok
[06:06] <fabbione> great
[06:06] <fabbione> HIGHMEM on 386 has been enabled, but i gues we will see the first reports only after we will make 2.6.12 the default
[06:06] <fabbione> did anybody in here tested it?
[06:06] <chmj> what can we do about the gcc-4.0 kernel problem though ?
[06:06] <infinity> I've used it on my own machines without issues, but I haven't tested your current images.
[06:07] <fabbione> chmj: not much right now
[06:07] <dilinger> chmj: test it and submit fixes upstream?
[06:07] <fabbione> infinity: ok
[06:07] <fabbione> the next 3 points are benchmarking related
[06:07] <fabbione> and we didn't start on them yet
[06:08] <fabbione> i don't have enough resources to even start it
[06:08] <infinity> Does anyone have any sane benchmark suites?
[06:08] <fabbione> who would like to take the tasks?
[06:08] <zul> bonnie++ is one
[06:08] <infinity> I will happily test SMP vs UP vs optimised vs generic on my amd64 til the cows come home, if I have some benchmarks to run.
[06:08] <zul> i dont have the gear for smp
[06:08] <chmj> I don't have the resources 
[06:08] <dilinger> whoever does take on the task should make the process public, so other people can reproduce the benchmark results
[06:09] <fabbione> who could test ppc?
[06:09] <fabbione> infinity: i assume you can test i386 on amd64
[06:09] <infinity> More importantly, though, what do we consider an acceptable performance loss to switch to generic-SMP on all installations?
[06:09] <jbailey> chmj: PRobably at a minimum, find the bugs in gcc's bugzilla and list them on the page.  Then they can be tracked.
[06:09] <infinity> 5%? 10%?
[06:09] <jbailey> fabbione: I can test ppc g4/g5.
[06:09] <toresbe> I can test m68k! oh wait... :P
[06:09] <fabbione> infinity: between 5 and 10% is ok with me
[06:09] <infinity> fabbione : I can test an i386 and amd64 root, but obviously the kernel will always be amd64.
[06:09] <chmj> jbailey: ok 
[06:10] <fabbione> note that Herbert Xu reported that the worst bottle neck is networking related
[06:10] <fabbione> using SMP kernels on UP machines
[06:10] <infinity> In what sense?... When the network is saturated?
[06:10] <fabbione> with very high load on the cpu and very high load on the network card (~1Gb)
[06:10] <infinity> I could see locking issues coming into play only when you're saturating I/O.
[06:10] <dilinger> probably related to softirq locking, would be my guess
[06:10] <infinity> Yeah.  Do we even care about such a use case?
[06:10] <fabbione> infinity: that's what he was talking about
[06:11] <fabbione> infinity: for server, we do
[06:11] <infinity> People who need to push that kind of bandwidth will almost never use default kernels.
[06:11] <fabbione> infinity: unfortunatly we cannot assume
[06:11] <infinity> (And people who push that kind of bandwidth also often have SMP machines, so the point becomes moots)
[06:11] <infinity> s/moots/moot/
[06:11] <fabbione> but i agree
[06:12] <fabbione> so does everybody agree in a possible loss of perf between 5 and 10%?
[06:12] <fabbione> or should we put it down?
[06:12] <fabbione> between 3 and 7?
[06:12] <toresbe> that's quite a lot, isn't it?
[06:12] <infinity> I could go as high at 10, but I'd be happier with 5.
[06:12] <dilinger> %5 is fine
[06:12] <zul> well if its too high then users are going to complain
[06:12] <infinity> I think we should shoot for 5 as a baseline.
[06:12] <chmj> 5% is fine 
[06:12] <toresbe> I mean, if people are using SMP machines, which atm is quite rare...
[06:12] <fabbione> ok let's average...
[06:12] <infinity> And see how bad our results are. :)
[06:12] <fabbione> no more than 6% :)
[06:13] <fabbione> clearly the lower the better :)
[06:13] <fabbione> so we have jbailey on ppc and infinity for i386/amd64.
[06:13] <chmj> no more than 6 is acceptable
[06:13] <infinity> Someone needs to be tasked with coming up with some comprehensive benchmarks.
[06:13] <fabbione> infinity, jbailey: i would like you 2 to update the wiki with an ETA for test results
[06:13] <jbailey> fabbione: ppc newworld g4/g5 only, though.  If you want oldworld support or g3 support, I don't have the equipment.
[06:14] <toresbe> what sort of thing should one test?
[06:14] <fabbione> jbailey: one ppc serie is acceptable
[06:14] <jbailey> fabbione: Standard linux test suite is fine?
[06:14] <toresbe> forks? malloc? memcpy...?
[06:14] <infinity> If it's going to involve network I/O and CPU, something like ab running against boa might work, over a crossover GigE.
[06:14] <fabbione> toresbe: the more the best
[06:14] <fabbione> toresbe: do you want to take care to find a benchmarking tool?
[06:15] <fabbione> zul: ?
[06:15] <jbailey> infinity: Something we should put together for FormalTestPlans?
[06:15] <fabbione> that needs to be done by yesterday
[06:15] <zul> fabbione: i would suggest bonnie or ltp
[06:15] <infinity> jbailey : FormalTestPlans seems to be all-encompassing, doesn't it?
[06:15] <toresbe> fabbione: I, uhm, I could try...
[06:15] <jbailey> infinity: I did mention that.
[06:15] <zul> http://ltp.sourceforge.net/
[06:15] <fabbione> toresbe: you don't need to write it.. just find one out there
[06:15] <toresbe> yeah
[06:15] <jbailey> I wonder how much elmo would hurt us if the kernel build fired up Xen and started an ltp pass?
[06:15] <fabbione> anyway.. add what you find at the end of the wiki
[06:16] <infinity> jbailey : I would hurt you.
[06:16] <toresbe> fabbione: me?
[06:16] <fabbione> toresbe: you and zul
[06:16] <fabbione> ok next item
[06:16] <toresbe> okies
[06:16] <zul> okies then
[06:16] <toresbe> ltp seems fairly spot-on, though
[06:16] <fabbione> are we aware of any way to detect SMP machines booting a UP kernel?
[06:17] <jbailey> fabbione: Depends on the arch, iirc.
[06:17] <fabbione> this is needed if enabling SMP kernels on UP machines is too expensive
[06:17] <infinity> Not reliably, IIRC.
[06:17] <infinity> Why is it needed?
[06:17] <infinity> Can the installer not run an SMP kernel unconditionally, and drop to installing a UP kernel if the system is UP.
[06:17] <zul> so we dont have a zillion configs for builidng the kernel
[06:17] <infinity> (much easier to detect UP from SMP than the other way around)
[06:18] <fabbione> infinity: because if installing a SMP kernel on UP machine is too expensive performance wise, we can ask d-i to install the proper kernel
[06:18] <infinity> fabbione : Yes, but d-i can run an SMP kernel.
[06:18] <fabbione> infinity: while i agree, it is somehow known that SMP kernels don't always boot UP hardware
[06:18] <toresbe> yeah, I've noticed that.
[06:18] <infinity> fabbione : It's much easier to detect a single CPU on an SMP kernel than the other way around.
[06:19] <toresbe> but it's quite rare.
[06:19] <infinity> fabbione : Is this still a concern, or are we operating on 5 year old assumptions?
[06:19] <fabbione> infinity: we can't risk breezy not even being installable because of an SMP kernel on the wrong UP hardware
[06:19] <fabbione> infinity: it's true on sparc at least... and that's now
[06:19] <infinity> Right, but Sparc isn't a release arch. ;)
[06:20] <jbailey> Nor is hppa (the other arch I know of that can reliably detect offline CPUs)
[06:20] <fabbione> infinity: yes but it's the same code that runs on other arches.. you know
[06:20] <infinity> fabbione : Not really, no.
[06:20] <fabbione> damn you got me :)
[06:20] <infinity> fabbione : The bits that just plain won't boot are drastically different between arches.
[06:20] <fabbione> i was trying to be vague ;)
[06:20] <infinity> CPU setup is very arch-dependent, obviously.
[06:21] <infinity> And I'd be very surprised if the SMP-on-UP problem still exists on our 3 release arches.
[06:21] <fabbione> infinity: there are other problems too
[06:21] <fabbione> not all drivers are compiled for SMP kernels, because they are not SMP friendly
[06:21] <infinity> Well, fair enough.  We can examing the CPU detection thing and see where it takes us.
[06:22] <fabbione> or they compile and don't work
[06:22] <fabbione> so we might kill the installation just a bit further
[06:22] <infinity> But if we're looking at SMP default kernels anyway (assuming the performance hit isn't teh suck), we need to tackle any other problems SMP may bring us, like crap drivers.
[06:22] <infinity> Otherwise, it's a pipe dream, and we can scrap the benchmarking.
[06:22] <fabbione> infinity: yes, but this doesn't assume we need to kill d-i for it :)
[06:23] <fabbione> at least not in the beginning
[06:23] <fabbione> but yes...
[06:23] <toresbe> ok
[06:23] <toresbe> how about in the installer, it asks if you want to use more than one processor?
[06:23] <fabbione> next point
[06:23] <fabbione> toresbe: and what would that solve?
[06:23] <infinity> toresbe : Questions in d-i will get Kamion and mdz smacking you.
[06:23] <infinity> Certainly not ones like that.
[06:24] <fabbione> even a boot option is not an option :)
[06:24] <fabbione> given that the code is still compiled in the kernel
[06:24] <toresbe> the installer could use a UP kernel, and could also very reliably detect it ;)
[06:24] <infinity> Anyhow, put me down for CPU number detection on amd64 and i386.  Can't do PPC until my Mac flies in here in a month.
[06:24] <fabbione> infinity: ok. i am not writing down who is going to do what ...
[06:24] <fabbione> i expect you guys to remember :)
[06:24] <infinity> fabbione : You're the lead, you should. :)
[06:25] <fabbione> infinity: i can remember without writing :)
[06:25] <fabbione> so you are still doomed ;)
[06:25] <infinity> jbailey : Unless you want to play secretary.
[06:25] <fabbione> next 2 steps are pretty related to each other
[06:25] <infinity> Yeah, but I suck at reembering things.  It's nice to go back to the spec and remember who to bug about what (or what I said I'd do and didn't)
[06:25] <fabbione> we should have done this a long long time ago
[06:26] <fabbione> infinity: you can just add yourself to it ;)
[06:26] <fabbione> anyway
[06:26] <fabbione> let's keep going
[06:26] <infinity> Carry on.
[06:26] <fabbione>  generate non-supported-linux-kernel-modules.
[06:26] <jbailey> infinity: For this meeting?  I guess I could, but since it's already written in text form, I'd rather not.
[06:26] <fabbione> now we have a problem
[06:26] <infinity> jbailey : Alright, I'll grab the log later. :)
[06:26] <fabbione> we include a lot of external drivers that are just a pile of junk code
[06:27] <fabbione> but users want it
[06:27] <fabbione> and we all know the drill
[06:27] <fabbione> so the idea was to create the above package
[06:27] <fabbione> that will contain all the modules that:
[06:27] <fabbione> 1) are not part of upstream kernel
[06:27] <fabbione> 2) we don't support directly
[06:27] <fabbione> 3) they are not required for installation (like webcam drivers)
[06:27] <infinity> 3) can compile cleanly out-of-tree?
[06:28] <fabbione> 4) as infinity 3)
[06:28] <fabbione> 5) we will drop as soon as they stop compiling
[06:28] <fabbione> for whatever reason
[06:28] <zul> or no longer supported upstream
[06:28] <fabbione> zul: right
[06:28] <infinity> Is this actually a long list?
[06:29] <fabbione> now.. we still want this package coming from the main kernel
[06:29] <chmj> I'm also wonderign how long it is 
[06:29] <fabbione> infinity: quite
[06:29] <fabbione> and we still want it shipped with the CD
[06:29] <zul> infinity: read the external-drivers file in the debian dir
[06:29] <fabbione> but clearly we don't want to support it
[06:29] <fabbione> hence the fancy name
[06:30] <fabbione> who would like to take this task?
[06:30] <fabbione> the task is to prepare a list of such drivers
[06:30] <fabbione> for all the arches
[06:30] <fabbione> by flavour
[06:30] <zul> i guess i can i have the experience with the drivers
[06:30] <fabbione> it needs to be detailed
[06:30] <fabbione> zul: ok.. it's your
[06:30] <zul> or maybe a couple of people can help
[06:30] <chmj> zul: I can help 
[06:30] <fabbione> zul: we will work on it together
[06:30] <zul> ok good
[06:31] <fabbione> since we need some changes to the build system too
[06:31] <fabbione> chmj: welcome to help :)
[06:31] <fabbione> chmj: would you like to help zul with the list and start to strech your wings on the build system?
[06:31] <chmj> yes 
[06:31] <fabbione> perfect
[06:31] <fabbione> next point
[06:31] <fabbione>  create policy for 3rd party driver inclusion policy.
[06:31] <chmj> maybe we can also enhance the watch program 
[06:32] <fabbione> this is mainly documentation/wiki stuff
[06:32] <fabbione> to reflect what are the criteria of 3rd party drivers
[06:32] <jbailey> chmj: I'd like to work with you a bit on build system stuff to see if cdbs2 can be bent to do what you want simply.
[06:32] <fabbione> mainly is what we wrote above already
[06:33] <chmj> jbailey: ok 
[06:33] <fabbione> and 3rd party patches must not touch any kernel core functionality or feature
[06:33] <fabbione> who would like to spend a few minutes doing it?
[06:33] <zul> fabbione: uh so like kdb?
[06:34] <fabbione> zul: debugging is a bit different and we can apply patches per flavour
[06:34] <zul> ah ok
[06:34] <zul> just had me worried for a minute
[06:34] <fabbione> i don't consider that a 3rd party drivers that to gain 1 ms in 8000 hours processing will patch 9000 lines of code
[06:35] <fabbione> so anybody wants to write this stuff down?
[06:35] <fabbione> it's just copy/paste from this discussion basically ;)
[06:35] <fabbione> i will offer a beer at the next conf? ;)
[06:35] <infinity> I'm grabbing the log anyway, so I'll do it.
[06:36] <jbailey> 12:26 <infinity> jbailey : Alright, I'll grab the log later. :)
[06:36] <fabbione> infinity: you win a beer :)
[06:36] <fabbione> ehhe
[06:36] <infinity> Yay, beer!
[06:36] <fabbione> next point
[06:36] <fabbione>  3rd party drivers will be maintained as patches.
[06:36] <fabbione> this was just a decision
[06:36] <fabbione> nothing fancy
[06:36] <fabbione> it has always been there
[06:36] <fabbione> next one:
[06:36] <fabbione>  Provide a psuedo/virtual package named 'linux' that depends on a generic
[06:37] <fabbione> this has been done where possible
[06:37] <fabbione> that means i386/amd64/ia64
[06:37] <fabbione> and sparc
[06:37] <fabbione> ppc and hppa have too many specific needs
[06:37] <fabbione> next one
[06:37] <fabbione>  Include ABINAME in kernel version string, to remove ambiguities from bug reports.
[06:37] <zul> is anyone besides fabbione actually looking at ppc?
[06:38] <zul> just had to ask
[06:38] <fabbione> zul: i guess nobody...
[06:38] <zul> ok then
[06:38] <fabbione> and the funny thing is that i don't even have one to test on
[06:38] <chmj> lack of hardware
[06:38] <zul> i could care less about ppc imho
[06:38] <infinity> PPC and I will spend some quality time when my Mac comes home to me.
[06:38] <infinity> Which is at the end of June.
[06:39] <fabbione> infinity: ok :)
[06:39] <jbailey> zul: What's needed?  I don't have a lot of time, but my main two boxes are PPC.
[06:39] <chmj> fabbione: you don't? 
[06:39] <fabbione> jbailey: it needs porting love :)
[06:39] <fabbione> chmj: no
[06:39] <fabbione> since it breaks every time
[06:39] <jbailey> The boxes I have are probably not the ones that need alot of love.
[06:39] <zul> jbailey: im not exactly sure it just needs someone to hold it and pet it and love and call him george
[06:39] <fabbione> anyway ppc is fluxating a lot now
[06:39] <fabbione> let's keep going guys....
[06:40] <fabbione> we will talk about ppc later
[06:40] <fabbione>  Include ABINAME in kernel version string, to remove ambiguities from bug reports.
[06:40] <fabbione> this has been done
[06:40] <fabbione> with the extra huglification of the version
[06:40] <fabbione>  Defer enhancing ABI check for now; improvements to this can come over
[06:40] <fabbione> as it says.. we have deffered it..
[06:41] <fabbione> the original system invented by mdz and improved by dilinger and lamont seems to meet our needs fine for now
[06:41] <fabbione>  Add a -dbg kernel image for all architectures that have a generic kernel
[06:41] <fabbione> zul: ^^
[06:41] <fabbione> status update?
[06:41] <zul> 686-dbg 386-dbg done...i have to enable kdb in the kernel rest will be working once 1.3 is branced
[06:42] <zul> and the ramdisk_size issue 
[06:42] <fabbione> rocking.. infinity, jbailey i will need you to test the -dbg packages on amd64/ppc
[06:42] <fabbione> but that's in about a couple of kernel releases
[06:42] <jbailey> fabbione: Will we get reminders at the time? =)
[06:42] <fabbione> zul: we might want to get that one fixed before
[06:43] <zul> fabbione: if i knew how to fix it i would
[06:43] <fabbione> jbailey: do i ever forget who are my bitches^W^Wyou? ;)
[06:43] <jbailey> fabbione: Not so far, dear. =)
[06:43] <fabbione> zul: ok we will work on it together than
[06:43] <fabbione> let's skip Debian/Ubuntu pkg unification for now
[06:44] <fabbione> we will take it later
[06:44] <fabbione>  Add infrastructure to autobuild git/bk snapshots from upstream.
[06:44] <infinity> But dilinger showed up just for that, I suspect. :)
[06:44] <fabbione> deferred for now....
[06:44] <fabbione> infinity: right in 10 minutes :)
[06:44] <fabbione> just that we finish the other simple points in the specs
[06:45] <fabbione> if somebody is interested in creating git/cogito autobuild snapshot can speak now.. or we will recruit for breezy+1
[06:45] <zul> oh that would be fun..not that im volunteering
[06:45] <infinity> I would, but my plate's too full this cycle, I suspect.
[06:45] <infinity> It's something I cal look at when bored, though.
[06:45] <infinity> s/cal/can/
[06:45] <chmj> I still need to spead my wing on the build system 
[06:46] <fabbione> chmj, infinity: it's not a high priority thing
[06:46] <jbailey> fabbione: Is that something best left to the GrumpyGroundhog timeframe?
[06:46] <fabbione> so if you feel bored or waiting for firefox to compile...
[06:46] <infinity> jbailey : GrumpyGroundhog will pretty much buy us this for free, but we're not sure when Grumpy will happen.
[06:46] <fabbione> jbailey: the motivations behind kernel crack of the day are several
[06:46] <jbailey> Right.  But do we want to encourage folks to try for CrackOfTheDay before that?  It seems better to not pretend that we might even support such a notion.
[06:46] <fabbione> like testing upstream fixes
[06:47] <infinity> fabbione : I'd leave it deferred for now anyway.  I don't have time for it right now, and I doubt anyone else wants to look at it.
[06:47] <fabbione> infinity: i am not promoting it :)
[06:47] <zul> jbailey: suse/novell has a kotd 
[06:47] <fabbione> but if somebody volunteers....
[06:47] <fabbione> jbailey: COTD won't be in the archive.. only somewhere available
[06:47] <chmj> fabbione, can still be touched on spare time, I guess 
[06:47] <dilinger> i could do some git stuff
[06:48] <fabbione> chmj: sure.. that works for me
[06:48] <chmj> sweet 
[06:48] <dilinger> but people at work are making me deal w/ a failed drive right now
[06:48] <fabbione> dilinger: wait .. i would really love you to do something else ;)
[06:48] <fabbione>  Add a hook to kernel image's postinst to call out to module-assistant.'
[06:48] <fabbione> i think we should defer this one to breezy+1
[06:49] <chmj> why ?
[06:49] <jbailey> IS that where my mkinitramfs hook goes? =)
[06:49] <infinity> Is the end goal there to never have to provide any binary packages matching module-source packages?
[06:49] <fabbione> chmj: because we can't ship it in the default install CD
[06:49] <infinity> If so, I'm all for it.  Keeping those in sync is stupidly painful.
[06:50] <fabbione> infinity: the goal was to have a common framework, where the user stick his external module source
[06:50] <fabbione> that get rebuilded automatically at postinst if there is an ABI change
[06:51] <fabbione> but that's quite complicated 
[06:51] <infinity> Ahh, so not for sources we ship?
[06:51] <fabbione> and there are several points of failre
[06:51] <infinity> Just for random downloaded crap.
[06:51] <fabbione> infinity: whatever that is source 
[06:51] <infinity> That sounds harder than it initially did.
[06:51] <chmj> heh, yes 
[06:51] <fabbione> we still have the issue that even if it is source that we ship, it might build on the kernel you are going to install
[06:52] <fabbione> + you need the framework to depends on gcc-*
[06:52] <fabbione> + you don't know if the crap that it's in there needs to be built with a specific order
[06:52] <fabbione> so i think we should rediscuss it a bit
[06:52] <infinity> Fair enough.  It sounds cracktastic.
[06:53] <fabbione> well it is....
[06:53] <fabbione> i think dilinger and I were discussing it at 5am :)
[06:53] <fabbione> or something like that
[06:53] <fabbione> any other comment on this?
[06:53] <fabbione> 3
[06:53] <fabbione> 2
[06:53] <fabbione> 1
[06:53] <fabbione> ok
[06:53] <fabbione>  Notification applet.
[06:53] <fabbione> that's done
[06:53] <infinity> \o/
[06:53] <fabbione> basically if you have event notifier installed
[06:54] <fabbione> every time you upgrade your kernel you get told to reboot..
[06:54] <fabbione> F4nCy
[06:54] <chmj> sweet 
[06:54] <fabbione> so let's go back to the Debian/Ubuntu thing
[06:54] <fabbione> #
[06:54] <fabbione> Unify Debian and Ubuntu kernel packaging. Drop dpatch, and add centralized
[06:54] <fabbione>     *
[06:54] <fabbione>       config file generation/management. (possibly use cdbs2) (low priority: decision beeds to be taken within 2 months)
[06:54] <infinity> dilinger : You can stop working on hard drives now.
[06:55] <fabbione> dilinger: what is the situation and feelings in debian about this merge?
[06:55] <fabbione> i know that quite a bunch of guys would be happy about it
[06:55] <infinity> It can't be timed more appropriately, given Sarge's impending release and Etch opening up within a week.
[06:55] <fabbione> and i remember we agreed on you and horms to prepare somekind of draft...
[06:55] <infinity> So, now is the ideal time to shove unification down everyone's throats.
[06:56] <fabbione> infinity: let me tell you a secret.. i knew when sarge was going to be released :)
[06:56] <fabbione> dilinger: ??
[06:56] <infinity> I think dilinger got stuck dealing with that failed drive at work. :/
[06:56] <fabbione> ok
[06:56] <infinity> (See, you shouldn't have left this point til last)
[06:56] <fabbione> let's suspend it for a while
[06:57] <fabbione> and hope he can come back
[06:57] <fabbione> we forgot 2 important things from the specs
[06:57] <fabbione> PPC64 and CONFIG_ handling (the latter also part of the debian integration)
[06:57] <fabbione> Kamion: i think it would be nice if you can stay here with us a few minutes?
[06:57] <Kamion> sure
[06:58] <fabbione> PPC64 :)
[06:58] <fabbione> finally we have a working toolchain
[06:58] <Amaranth> how come the backports meeting isn't in the topic?
[06:58] <fabbione> that can build the kernel (or we believe so)
[06:58] <fabbione> Amaranth: we are in another meeting. kthxbye
[06:58] <dilinger> back
[06:58] <Lathiat> fabbione: 'kthxbai'
[06:58] <Amaranth> yeah, get it right :)
[06:58] <jbailey> meow
[06:58] <Amaranth> i'll watch this one
[06:59] <fabbione> we agreed after some discussion for the naming of the new ppc64 flavours :)
[06:59] <dilinger> fabbione: i don't think anyone has problems w/ a merge
[06:59] <fabbione> powerpc, powerpc-smp -> 32Bit
[06:59] <dilinger> fabbione: trave11er's reworking the debian packaging to build from a single source
[06:59] <fabbione> dilinger: ok.. we will take it up in a few minutes if that's ok
[06:59] <dilinger> apparently he wasn't aware of ubuntu's work to do that
[06:59] <dilinger> ok
[07:00] <fabbione> pseries-smp, iseries-smp -> ppc64
[07:00] <fabbione> the power3 and power4 flavours will die
[07:00] <fabbione> replaced by pseries and iseries
[07:00] <fabbione> given that we don't have any experience i would suggest a few releases transition plan
[07:00] <fabbione> that will mean overbloating ppc images with what we have now
[07:01] <Kamion> I still really hate the pseries name for that
[07:01] <fabbione> + the ppc64
[07:01] <infinity> fabbione : And what does one install on their G5?  (Yes, I know it's the pseries one, but no one else will know that)
[07:01] <Kamion> infinity: my feeling exactly
[07:01] <fabbione> ok...
[07:01] <fabbione> any better suggestions are welcome until they retain the -smp at the end
[07:01] <fabbione> since there will be no UP for them
[07:02] <infinity> powerpc64-smp, iseries-smp
[07:02] <fabbione> (according to benh it's perfectly safe)
[07:02] <infinity> Since iseries is the odd man out.
[07:02] <fabbione> Kamion: are you happy with that?
[07:02] <Kamion> yeah, iseries is unusual powerpc64, in the same way as powerpc isn't everything that's "PowerPC" but it's the most generic kind
[07:02] <Kamion> well, most common
[07:02] <Kamion> fabbione: yes
[07:03] <fabbione> Kamion: ok.
[07:03] <Kamion> not bothered about whether -smp is there or not
[07:03] <infinity> And so much for that bikeshed.
[07:03] <fabbione> now the point is to get people to test these kernels and d-i before we kill the old flavours
[07:03] <fabbione> Kamion: i am a bit fuzzy in having it for the sake of consistency with the other arches
[07:03] <jbailey> What testing is needed?  powerpc should just work on all the 32 bit ones, no?  And the 64 bit ones are new.
[07:04] <fabbione> jbailey: that's why we need a ppc person in the team ;)
[07:04] <fabbione> jbailey: we need somebody to see if the kernel actually works before we force it to the users
[07:05] <infinity> fabbione : My Mac will be handy here, as it's an OldWorld, and thus far more likely to not work right. :)
[07:05] <infinity> fabbione : Again, that's "end of month" timeframe.
[07:05] <fabbione> perfect
[07:05] <fabbione> Kamion: what do you want me to do in terms of udebs?
[07:05] <fabbione> Kamion: should i give you udebs for 64bits or should we wait?
[07:06] <Kamion> fabbione: yes please, same udebs as are currently there for power3/power4
[07:06] <Kamion> fabbione: so just let it use modules/powerpc/ and it should be fine
[07:06] <fabbione> Kamion: ok.. i will generate udebs for you
[07:06] <fabbione> and you will decide what you want to include in d-i for testing
[07:07] <fabbione> i have no problems with that :)
[07:07] <fabbione> Kamion: thanks
[07:07] <Kamion> ok, no problem
[07:07] <fabbione> any other comment on PPc64?
[07:07] <Kamion> I imagine I'll just s/power4/powerpc64/g
[07:07] <infinity> Yes, send me one.
[07:07] <fabbione> (btw i will take this tasks since i think i am one of the few with access to the porting box)
[07:08] <fabbione> infinity: if i had one....
[07:08] <jbailey> Migration path for people with current kernels?
[07:08] <infinity> which box is that?
[07:08] <fabbione> jbailey: we will use linux-meta for that
[07:08] <fabbione> infinity: davis
[07:08] <infinity> fabbione : I have access.
[07:09] <fabbione> infinity: want to take the tasks?
[07:09] <infinity> Not really. :)
[07:09] <fabbione> infinity: so shut up next time :P

[07:09] <fabbione> heeh
[07:09] <zul> send me one and ill do it ;)
[07:09] <titus`> hi
[07:09] <fabbione> jbailey: i think it will be safe at a certain point for the 64bit kernels to provide the old 32 power3/4
[07:10] <fabbione> but we will see when we will have the images in place....
[07:10] <fabbione> does it sound reasonable to everybody?
[07:10] <fabbione> ok
[07:10] <fabbione> let's go back to Debian
[07:10] <fabbione> dilinger: are you still around?
[07:11] <chmj> dilinger, ? 
[07:11] <zul> diiiiiiiiilinnnnnnnnnnger
[07:11] <zul> sorry
[07:12] <fabbione> ok i guess dilinger is floating around a bit
[07:12] <infinity> Looks like his job kidnapped him.
[07:12] <fabbione> i think other than the Debian merge we have done with the specs...
[07:12] <infinity> Anything else on your agenda?
[07:12] <fabbione> infinity: yes
[07:12] <fabbione> just one second..
[07:13] <fabbione> ah sorry.. i had a cramp on my right hand
[07:13] <fabbione> the last item in agenda is 2.6.12 in main
[07:13] <fabbione> how do you guys feel with the current images?
[07:13] <fabbione> right now we are not respecting ABI changes
[07:14] <fabbione> to keep the package "simpler"
[07:14] <zul> except with some random crashing im fine with it
[07:14] <jbailey> stable for me on i386 and ppc so far.
[07:14] <Mithrandir> fabbione: they blow up on my AMD64 due to acx
[07:14] <fabbione> i am fine here too...
[07:14] <fabbione> Mithrandir: did the old version work?
[07:14] <Amaranth> fine here in i386
[07:14] <Amaranth> on
[07:14] <fabbione> Mithrandir: if so can you try to do some debugging?
[07:14] <zul> Mithrandir: im getting random crashes as well with ati
[07:14] <chmj> i386 work for me 
[07:15] <fabbione> anyway acx is an external driver and Mithrandir is supposed to be the amd64 porter :)
[07:15] <Mithrandir> fabbione: 2.6.10-5-amd64-k8 works fine, 2.6.12 blows up.
[07:15] <fabbione> Mithrandir: you lose :)
[07:15] <Mithrandir> fabbione: I can do some debugging if you give me kernels I can debug usefully. :-P
[07:15] <fabbione> ok.. i guess i will than upload 1.2 with the -dbg merges from zul
[07:16] <zul> there isnt one for amd64 yet
[07:16] <fabbione> Mithrandir: acx is easy to debug.. i will tell you tomorrow how
[07:16] <fabbione> and we will ask to move the kernel in main
[07:16] <Mithrandir> fabbione: if you say so.
[07:16] <fabbione> that means start supporting it
[07:16] <fabbione> including ABI changes
[07:16] <zul> heh we werent? :)
[07:16] <fabbione> zul: nope.. :)
[07:17] <fabbione> we cheated
[07:17] <zul> oh...
[07:17] <fabbione> oh i shouldn't have said that
[07:17] <fabbione> :P
[07:17] <fabbione> ok
[07:17] <infinity> Too late.
[07:17] <fabbione> so general consensum is to have it in main
[07:17] <infinity> Better now than never, really.
[07:18] <infinity> The bugs will get worked out faster if more people install them and complain.
[07:18] <fabbione> infinity: i tend to agree if some arches like ppc didn't tend to selfdestruct each minor upstream release
[07:18] <zul> yah...fun fun
[07:18] <fabbione> but yeah
[07:18] <fabbione> it's time to move it to main
[07:18] <fabbione> it will be a bit more painful in the beginning but ok
[07:18] <chmj> zul: heh 
[07:19] <infinity> Pain is character-building.
[07:19] <chmj> fabbione: painfull is putting it mildly
[07:19] <fabbione> when do we want to switch 2.6.12 as default kernel?
[07:19] <zul> tomorrow hah!...edit that out as well :)
[07:19] <fabbione> 2 weeks after it will hit main?
[07:20] <infinity> Depends on how many bug reports we get. :)
[07:20] <zul> uh...wait..linux-restricted-modules
[07:20] <fabbione> zul: easy dude... it's an rc release
[07:20] <infinity> If it seems reasonably stable 2 weeks after it goes in, promote it.
[07:20] <fabbione> it might eat your machine and you still don't know
[07:20] <fabbione> infinity: agreed
[07:20] <chmj> fabbione: depends on the bugs Ithink 
[07:20] <fabbione> zul: daniels is already working on them
[07:20] <fabbione> chmj: bugs or non bugs we need a deadline
[07:20] <fabbione> there will be always bugs
[07:20] <zul> fabbione: ok 
[07:21] <zul> yeah it is the kernel
[07:21] <fabbione> there is no way to get a 0 bugs kernel
[07:21] <fabbione> people can make bugs out of hello.c
[07:21] <fabbione> so..
[07:21] <fabbione> dilinger: are you back?
[07:21] <chmj> like infinity, has to be reseanably stable
[07:22] <chmj> +said 
[07:22] <jbailey> *g*
[07:22] <fabbione> ok
[07:22] <fabbione> last item in the agenda
[07:22] <fabbione> that was for dilinger
[07:22] <fabbione> we need to do some CONFIG_ rework
[07:22] <fabbione> i know dilinger and zul started on it already
[07:22] <dilinger> yea
[07:22] <dilinger> i'm here
[07:23] <dilinger> this is a horrible time for a meeting, btw :)
[07:23] <fabbione> it's goal is to try to get CONFIG_ options across arches/flavours are coherent as possible
[07:23] <infinity> Dude, it's 3:23am where I am, don't complain.
[07:23] <dilinger> the CONFIG stuff ties in w/ the package unification stuff we're doing w/ debian
[07:24] <fabbione> dilinger: ok.. so if you don't mind to give us a short status update again
[07:24] <dilinger> i hadn't bothered to finish it due to the fact that i couldn't use it
[07:24] <fabbione> dilinger: why not?
[07:24] <dilinger> because there is no common package yet
[07:24] <dilinger> so getting back to what i was saying
[07:24] <dilinger> trave11er's started working on a single source package
[07:24] <dilinger> he wasn't aware ubuntu already did it
[07:25] <dilinger> he also wasn't aware that we wanted to use cdbs2
[07:25] <fabbione> ehehhe
[07:25] <dilinger> we made him aware, and he started pulling in changes; but he hasn't started using cdbs2
[07:25] <dilinger> i haven't looked at his stuff yet (been busy moving), but i plan to within the next week or two
[07:25] <fabbione> i did look at his tree and it seems interesting
[07:25] <dilinger> ubuntu and debian requirements should be about the same
[07:26] <fabbione> dilinger: other than the udebs yes
[07:26] <dilinger> debian has some additional requirements; i don't believe there's anything that ubuntu needs that debian doesn't, other than udebs
[07:26] <fabbione> we have the same pkging requirements atm
[07:26] <dilinger> so, merging just makes sense
[07:26] <fabbione> dilinger: the only problem is to move debian away from svn
[07:26] <dilinger> i'll look at trave11er's stuff, convert to cdbs2 if it lends itself well to it, and made it so that it works for both debian and ubuntu
[07:26] <fabbione> to a more sane SCM to handle branches
[07:27] <dilinger> fabbione: i'm hesitant to do such a thing until lifeless fixes baz bugs that are keeping me from actually getting stuff done
[07:27] <fabbione> dilinger: point taken
[07:27] <infinity> SVN works fine.  Leave the poor thing alone.
[07:27] <dilinger> it's looking like we might just skip right to bzr or git in a few months
[07:27] <dilinger> whichever actually matures
[07:28] <fabbione> bzr sounds fine to me :)
[07:28] <fabbione> what do we want to do in the meanwhile?
[07:28] <dilinger> part of making the single source packaging work for both ubuntu and debian includes adding CONFIG_ handling
[07:28] <Amaranth> is bzr the python git that actually does more?
[07:29] <dilinger> Amaranth: bzr is the python SCM; git is the "tree management" something-or-other that other SCMs (cogito, monotone or darcs, i forget which) are attempting to base themselves off of
[07:29] <fabbione> dilinger: ok.. sounds good, perhaps we want to start experimenting the CONFIG_ stuff in ubuntu while traveller plays with the packaging?
[07:30] <dilinger> fabbione: to be honest, i'd rather get the packaging out of the way first.  the architectures headache causes me much more stress than config file handling
[07:30] <dilinger> once we have a single source package, CONFIG handling suddenly becomes *my* problem when i do a new kernel-source upload and am required to update configs for 20 different files instead of just 5
[07:31] <dilinger> so i'll be quick to take care of that ;)
[07:31] <fabbione> dilinger: ok :)
[07:31] <dilinger> did i miss anything?
[07:31] <fabbione> dilinger: we need to set a timeframe for this work
[07:32] <dilinger> ok
[07:32] <fabbione> because definetely we can't wait forever
[07:32] <fabbione> so i suggest we merge the packaging asap
[07:32] <dilinger> i'm considering this week to be a waste; i've still got a bunch of things i need to take care of related to my new apt
[07:32] <fabbione> and later the source trees
[07:32] <dilinger> this weekend/next week, i intend to work on the packaging
[07:32] <dilinger> i don't know how far along trave11er is yet
[07:32] <fabbione> dilinger: sounds fine for me
[07:33] <fabbione> it will give me time to do a few userland things
[07:33] <fabbione> so i suggest:
[07:33] <fabbione> - we merge the packaging
[07:34] <fabbione> basically debian/* !debian/patches
[07:34] <fabbione> and at a later stage when Debian will start to work on .12 we will merge the code too
[07:34] <zul> so would this mean would we have to keep track of bugs and bugzilla?
[07:34] <fabbione> at least the common part of debian/patches/*
[07:34] <fabbione> zul: no
[07:35] <fabbione> zul: we will only take care of our bugs
[07:35] <zul> ok
[07:35] <fabbione> and debian will do it in it's bugtracking
[07:35] <dilinger> fabbione: i still do intend to get -as kicked off again after .12 (i'll need to write scripts to interface git instead of bk, though.  which is where the git autobuild stuff might tie in..)
[07:35] <fabbione> we will have different patchsets at the end
[07:35] <dilinger> so having debian and ubuntu share patches, and call it -as, might work
[07:35] <fabbione> dilinger: yes.. works for me
[07:36] <fabbione> and on top everybody adds whatever they want
[07:36] <fabbione> so that it get's more tasty ;)
[07:36] <fabbione> ok
[07:36] <fabbione> i think that's it
[07:36] <fabbione> is there Any Other Businees?
[07:37] <fabbione> 3
[07:37] <fabbione> 2
[07:37] <fabbione> 1
[07:37] <fabbione> ok
[07:37] <fabbione> thanks everybody
[07:37] <chmj> :) 
[07:37] <fabbione> it was nice to see you all
[07:37] <dilinger> heh
[07:37] <fabbione> and see you again in 2 hours for the backporting meering
[07:37] <zul> that will keep ogra happy
[07:38] <chmj> man, I'm gonna miss that 
[07:38] <fabbione> bye and have a nice evening if you will not show up later
[07:38] <ogra> heh
[07:38] <fabbione> dilinger: if it's ok with you we will review possible deadline of the merging later or tomorrow...
[07:39] <chmj> cheers all !
[07:39] <Nafallo> thanx all :-)
[08:52] <mako> greetings everyone
[08:53] <dilinger> hello
[08:53] <zul> hey mako 
[08:53] <mako> there's not a bonus meeting in here now, is there?
[08:53] <Nafallo> hi mako 
[08:53] <Amaranth> 30 minutes?
[08:53] <siretart> hi folks
[08:53] <mako> yeah, 35 or so
[08:53] <mako> i'm going to start working on the agenda.. 
[08:53] <siretart> mako: there was, I think
[08:54] <Amaranth> lets start now, decide to not allow backports, and be done before the backports guys get here :D
[08:54] <siretart> lol
[08:54] <tseng|work> too late for that, he's here
[08:54] <tseng|work> but i second the motion
[08:54] <tseng|work> *G*
[08:54] <tseng|work> brb
[08:54] <Amaranth> jdahl? what's his irc nick?
[08:55] <Amaranth> err, jdong
[08:55] <mako> Amaranth: alas, we're going to be constructive instead :-P
[08:58] <tseng|work> hello ubunteros
[08:58] <siretart> hi tseng|work 
[08:58] <Nafallo> hi tseng|work 
[09:00] <kassetra> mako: do you want our suggestions on the agenda page as well?
[09:01] <ogra> sure
[09:01] <ogra> its a wiki, its for all of us ;)
[09:01] <\sh> evening people
[09:02] <ogra> \sh, you stopped packaging ?
[09:02] <tseng|work> kassetra: i thought I asked you to do that a week ago :(
[09:02] <tseng|work> the page was empty until a few hours ago
[09:02] <mako> kassetra: umm.. i'm editing it now
[09:02] <Amaranth> no backports for packages in main? kinda harsh
[09:03] <\sh> ogra: yeah....fixed one bug, the next is waiting :( c++ crap
[09:03] <Amaranth> oh, the meeting hasn't started yet ;)
[09:03] <kassetra> I have the suggestions, but I wasn't sure you wanted them on the agenda.
[09:03] <\sh> ogra: and finally it's your thing, gnome ;)
[09:03] <ogra> \sh, lazy guy, GO PACKAGING, there is still 1/2h left ;)
[09:03] <tseng|work> Amaranth: uh, not really.
[09:03] <tseng|work> backports-for-main screws support
[09:03] <ogra> Amaranth, 30mins
[09:04] <tseng|work> because people dont readily advertise that they have backported stuff on their system
[09:04] <siretart> kassetra: I'd suggest to create a new wiki page then
[09:04] <\sh> ogra: gnome-chemistry-utils
[09:04] <tseng|work> see the support nightmare for gentoo gnome team with breakmygentoo if you need proof
[09:04] <Amaranth> good point
[09:04] <ogra> hmm, \sh *very* important indeed ;)
[09:05] <mako> give me like 5 minutes more to do this
[09:05] <\sh> ogra: and taking over ivoks work ;)
[09:05] <tseng|work> basically people dont understand that third party bugs dont go to bugzilla
[09:05] <JohnDong> I've tried to get people to understand that...
[09:05] <ogra> \sh, i saw it, awesome :) i love our team
[09:05] <tseng|work> JohnDong: its not your fault, they just cant fathom it
[09:06] <JohnDong> thanks, tseng... I've put disclaimers everywhere on the Backports site... but some people just don't read :)
[09:06] <tseng|work> a segment of people attracted to crack-of-the-day are not really well aclimated to how OSS works
[09:06] <kassetra> We're working on ways to really broadcast that idea to people...
[09:06] <\-> hey JohnDong, thanks for the backports. wanted to say that for a long time.
[09:06] <JohnDong> thanks :)
[09:06] <tseng|work> seemingly a large segment
[09:06] <ogra> yep
[09:06] <Amaranth> JohnDong: my only problem with the backports is that you've put my stuff in hoary universe instead of hoary-extras ;)
[09:07] <JohnDong> Amaranth: what package, specifically
[09:07] <JohnDong> I've taken smeg out due to gnome deps
[09:08] <Amaranth> JohnDong: oh, then just pymusique and related packages
[09:08] <Amaranth> JohnDong: I guess gnome-menus from the 2.10 cvs branch was too much crack, eh?
[09:08] <Amaranth> I need to go back and redo that package...
[09:08] <JohnDong> gnome-devel broke with those packages
[09:08] <JohnDong> I can't accept that
[09:09] <mako> YES THAT BOURNE
[09:09] <mako> i hope you all feel important
[09:09] <\sh> whoever it is?
[09:09] <JohnDong> lol
[09:09] <infinity> Pfft.  He was calling from my bedroom, dude.
[09:09] <Amaranth> yeah, every hoary user using my stuff is getting a backport (*gasp*) of gnome-menus that breaks gnome-devel
[09:09] <\sh> just a VIP ;)
[09:09] <siretart> has the meeting already begun?
[09:09] <JohnDong> sort of, I guess
[09:09] <\sh> no 20mins left
[09:10] <kassetra> Amaranth - you're going to kill me telling me that.
[09:10] <\sh> eta:20
[09:10] <ogra> siretart, in 20
[09:10] <mako> i'm still finishing the agenda
[09:10] <\sh> but we're heating up i guess ;)
[09:10] <JohnDong> mako: thanks for all the time you're putting into this
[09:10] <JohnDong> we've needed this for a while now
[09:10] <siretart> heavy discussion already here. promises to be a heatful meeting :)
[09:10] <Amaranth> this is kind of odd for me
[09:11] <Amaranth> i've made backports, some of my stuff is in backports, and i'm trying to be a MOTU so i kinda don't like backports...
[09:11] <kassetra> well, MOTU and backports shouldn't be mutually exclusive.
[09:11] <JohnDong> I certainly don't try to make anybody use backports...
[09:12] <JohnDong> and I certainly am not trying to make Backports conflict with Ubuntu efforts
[09:12] <Amaranth> personally i think universe shouldn't freeze
[09:12] <Amaranth> hey Ryantroy 
[09:12] <\sh> Amaranth: i don't think that backports and motu are byting each other..but the problem is, we need a policy for backports...
[09:12] <kassetra> which is why we're all here.
[09:12] <\-> why a policy for backports?
[09:12] <\sh> Amaranth: see gentoo...even gentoo.de has it's own backports repos
[09:12] <JohnDong> \sh: what do you mean, biting?
[09:13] <Amaranth> why would gentoo need backports?
[09:13] <JohnDong> what kinds of conflicts am I not informed?
[09:13] <JohnDong> amaranth: experimental ebuilds
[09:13] <Amaranth> ah, breakmygentoo
[09:13] <JohnDong> amaranth: Version bumps, like what I do, are done with the mv command ;)
[09:13] <tseng|work> er, gentoo cant have backports
[09:13] <tseng|work> that doesnt make sense.
[09:13] <ogra> \-, https://www.ubuntulinux.org/wiki/UbuntuBackports
[09:13] <JohnDong> tseng:3rd party repo, not really backports
[09:13] <tseng|work> yes
[09:14] <tseng|work> thats totally different, more common with apt-get.org
[09:14] <tseng|work> lets ignore it.
[09:14] <Ryantroy> Amaranth: hello
[09:14] <JohnDong> ok
[09:14] <JohnDong> Perhaps a more relevant example is Fedora...
[09:14] <Amaranth> Ryantroy: Still waiting on moderator access to my subforum. ;)
[09:14] <JohnDong> Core 3 shipped with Firefox .10 and since then, they've updated it to 1.0.4
[09:14] <mako> alright
[09:14] <mako> i put up a new agenda
[09:14] <Ryantroy> Amaranth: Yes :) I know... working on that solution atm.. Sorry its taking so long.
[09:14] <bob2> isn't Core 4 out, or nearly so?
[09:15] <mako> EVERY GO EDIT IT AT ONCE
[09:15] <JohnDong> bob2: almost
[09:15] <mako> EVERYONE GO EDIT IT AT ONCE
[09:15] <bob2> mako: ONE
[09:15] <JohnDong> mako: lol
[09:15] <Amaranth> yes, let's break it
[09:15] <bob2> BREAKMYWIKI, it'll be awesome
[09:15] <mako> it's obvious
[09:15] <Amaranth> doesn't rosetta handle people editing things at the same time?
[09:15] <bob2> moin at -O9!
[09:15] <mako> screw moin
[09:15] <siretart> hey dholbach :)
[09:15] <dholbach> hey
[09:15] <bob2> Amaranth: rosetta != wiki
[09:15] <tseng|work> bob2: -j007
[09:15] <ogra> hi dholbach 
[09:15] <JohnDong> *resisting urge to CTRL-A*
[09:15] <JohnDong> j/k
[09:15] <Amaranth> bob2: It could be. :)
[09:15] <JohnDong> ;)
[09:15] <mako> screw moin, lets replace zwiki with BAZ
[09:15] <bob2> hahaha
[09:15] <kassetra> LOL
[09:16] <mako> SUCH A GOOD IDEA
[09:16] <dholbach> :)
[09:16] <bob2> mako: harsh!
[09:16] <mako> that will make mdz happy
[09:16] <tseng|work> hah
[09:16] <tseng|work> plaintext in version control
[09:16] <tseng|work> im down for that
[09:16] <bob2> mako: only Subversion can deliver the enterprise synergy and XML compatbility needed in todays heady internet marketplace.
[09:16] <ogra> hey jbailey :)
[09:17] <JohnDong> bob2: I've had a LOT of trouble with subversion
[09:17] <Amaranth> bob2: Congrats, you've blown the top off the bullshit-o-meter. :)
[09:17] <JohnDong> Ryan can testify to svnadmin recover
[09:17] <JohnDong> lol
[09:17] <Amaranth> JohnDong: Use the fsfs backend.
[09:17] <bob2> Amaranth: I'd like to thank Jeebus, and the forums and Scientology.
[09:17] <JohnDong> Amaranth: I could change systems now that my lazy cycle is done
[09:18] <JohnDong> Amaranth: before I served directly from mod-dav-svn
[09:18] <drmaravo> hola holita flanders terrex
[09:18] <Amaranth> JohnDong: scary
[09:18] <JohnDong> Amaranth: tell me about it
[09:18] <terrex> drmaravo: X-D
[09:19] <Amaranth> perfect timing, as always
[09:19] <mdz> mako: do we have an agenda for the backports discussion?
[09:19] <JohnDong> mdz:http://www.ubuntulinux.org/wiki/UbuntuBackports
[09:19] <JohnDong> I'm quite happy with this agenda
[09:19] <ogra> https://www.ubuntulinux.org/wiki/UbuntuBackports
[09:19] <Burgundavia> always good before a meeting, a netsplit
[09:21] <ogra> haha
[09:21] <ogra> dilinger incognito
[09:21] <\sh> ah there ;)
[09:21] <dilinger> uhm?
[09:21] <\sh> freenode hub ddos ;)
[09:22] <ogra> dilinger, havent seen you yet with this name :)
[09:23] <dilinger> ouh yeah
[09:23] <Amaranth> hide!
[09:23] <\sh> hahaa....now i know why i had so much traffic on my line
[09:23] <dilinger> gentoo rulez!
[09:23] <\sh> samba greets me
[09:23] <ogra> GOOD MORNING JDUB !
[09:23] <tseng|work> "How can the backports team guarantee that system works after using their packages, are backports rather using cdbs or debhelper?"
[09:23] <tseng|work> what does this mean
[09:23] <JohnDong> I was looking at that, too
[09:23] <Amaranth> KDE 10x10!
[09:24] <ogra> Amaranth, lol
[09:24] <JohnDong> tseng: I think it's a question on the method we use to build packages?
[09:24] <\sh> and all those windows noobs tried to inject me with this stupid viruses
[09:24] <tseng|work> well i imagine you dont touch rules
[09:24] <Amaranth> i'm running gnome-panel, kicker, and xfce4-panel, which do i choose? :)
[09:24] <\sh> KDE 90x10 it says ;) because gnome only 10x10 ;)
[09:24] <bob2> JohnDong: that can't be it
[09:24] <bob2> JohnDong: you can't be touching debian/rules when backporting things
[09:24] <tseng|work> if you did i'd be beating you alot harder :P
[09:24] <tseng|work> so the question seems odd
[09:24] <JohnDong> tseng: no, I don't touch rules, lol
[09:25] <infinity> bob2 : Says you.  I've done some pretty intrusive backporting.
[09:25] <Amaranth> ouch
[09:25] <Amaranth> netsplit bites back
[09:25] <tseng|work> well actually you should have for mono
[09:25] <ogra> Amaranth, you still have left one edge
[09:25] <bob2> infinity: you don't count!
[09:25] <tseng|work> but thats another story
[09:25] <JohnDong> tseng: yeah... Mono is really a mistake....
[09:25] <ogra> Amaranth, for an xtra panel ;)
[09:25] <bob2> infinity: it was the hat doing the editing, afaict
[09:25] <Amaranth> ogra: i should be running it all on e17?
[09:25] <zul> ahem...kernel...
[09:25] <ogra> hehe
[09:25] <JohnDong> tseng: BTW, the Beagle Wiki uses Backports as its primary Ubuntu installation method, though ;)
[09:25] <tseng|work> zul: dude help me backport glibc
[09:25] <JohnDong> LOL
[09:26] <infinity> bob2 : Altogether possible.  The hat always has had a thing for makefiles.
[09:26] <tseng|work> JohnDong: uh
[09:26] <zul> tseng|work: no i want to live to a ripe old age
[09:26] <tseng|work> i tried to explain to seb (who did that) why thats crack
[09:26] <JohnDong> tseng: not trying to give you high blood pressure
[09:26] <tseng|work> he cant understand
[09:26] <tseng|work> i beat on him for 2 hours or so
[09:26] <JohnDong> Oh, he wrote that wiki article?
[09:26] <tseng|work> he just cant fathom why something that appears to work to him can be wrong
[09:26] <ajmitch> hi
[09:26] <ogra> hey ajmitch 
[09:26] <\sh> ETA 3
[09:26] <Amaranth> beagle wiki's install method broke my system when i upgraded to breezy :/
[09:26] <tseng|work> hi andrew
[09:27] <JohnDong> Amaranth: that shouldn't be possible
[09:27] <bob2> ajmitch: hah, up early
[09:27] <JohnDong> Amaranth: Backports doesn't survive if you put in Breezy
[09:27] <tseng|work> i actually told him to leave it as it was, rather than promote breezy
[09:27] <JohnDong> yeah, you told me that, too ;)
[09:27] <tseng|work> i dont want those users using breezy anymore than I do backports
[09:27] <Amaranth> JohnDong: It was an old mono backport
[09:27] <siretart> 3minutes to go :)
[09:27] <tseng|work> at this stage
[09:27] <Amaranth> actually i think it came from manno.name
[09:28] <tseng|work> ...
[09:28] <JohnDong> tseng: Yeah, Backports mono is a mess, I'll agree :(
[09:28] <tseng|work> those are the WORST
[09:28] <tseng|work> its all native packages
[09:28] <bob2> haha
[09:28] <Amaranth> hey, i just followed the beagle wiki :P
[09:28] <tseng|work> and he didnt merge mcs and mono sources
[09:28] <ogra> argh native packages
[09:28] <tseng|work> no idea where he got an mcs orig
[09:28] <kassetra> Ok, mono was not our brightest moment in the backports world.
[09:29] <bob2> "deb http://manno.name/debian/ breezy cvs", debian, breezy, cvs.  WHAT COULD POSSIBLY GO WRONG?
[09:29] <ogra> err
[09:29] <tseng|work> kassetra, that wasnt backports
[09:29] <tseng|work> that was some guy making his own package
[09:29] <Amaranth> haha
[09:29] <zul> bob2: besides a fatal beating
[09:29] <JohnDong> Can we please stop mentioning non-backports 3rd party repos?
[09:29] <tseng|work> yes.
[09:29] <JohnDong> :)
[09:30] <\sh> ok ETA 1 packaging a cigarette ;)
[09:30] <Amaranth> they kinda all get lumped together when users have extra repos in their sources.list and ask for help on #ubuntu
[09:30] <bob2> zul: hey, I'm not the manno.name person
[09:30] <Amaranth> is that macewan?
[09:30] <JohnDong> Amaranth: Yeah, and I often get blamed for that too
[09:30] <JohnDong> Amaranth: I've got a guy bitching at me because his Sid sources no longer work...
[09:30] <JohnDong> and it was aparantly my fault...
[09:30] <JohnDong> lol
[09:31] <bob2> Amaranth: someone needs to talk to the ubuntuguide person about the "Recommended" sources.list crap
[09:31] <ogra> yeah
[09:31] <tseng|work> someone is already woking on ubuntuguide
[09:31] <JohnDong> bob2: Would you rather have him recommending Marillat?
[09:31] <Amaranth> bob2: jiyou?
[09:31] <ogra> ouch
[09:31] <Amaranth> he was, for awhile
[09:31] <ogra> JohnDong, what for either ?
[09:31] <\sh> transcode :(
[09:31] <JohnDong> transcode, acroread 7
[09:31] <bob2> JohnDong: I don't know.
[09:31] <Amaranth> half the people with broken systems in #ubuntu have sid marillat enabled
[09:32] <JohnDong> You guys gotta admit, Backports is safer than Marillat
[09:32] <Amaranth> ok, time for the meeting to start
[09:32] <mdz> mako: are we ready?
[09:32] <bob2> JohnDong: presumably you guys don't have crap like w32codecs in there, tho
[09:32] <siretart> Amaranth: ++
[09:32] <JohnDong> and Backports is safer than forcing Sid packages to install
[09:32] <tseng|work> maybe we should just backport marillat
[09:32] <mako> alright
[09:32] <tseng|work> that would be awesomes.
[09:32] <JohnDong> I was working on that
[09:32] <mako> alright.. i don't have ops here
[09:32] <JohnDong> a lot of Marillat is in Backports
[09:32] <JohnDong> but let's move on :)
[09:32] <mako> so i can't forcefully SILENCE PEOPLE :)
[09:32] <JohnDong> **Ready to start
[09:32] <mako> (yet)
[09:32] <ogra> JohnDong, its also in multiverse
[09:32] <tseng|work> MAKO HAS THE STAGE
[09:32] <Amaranth> jdub: ping?
[09:33] <jdub> Amaranth: pong
[09:33] <mako> so we need to all show restraint here
[09:33] <Amaranth> jdub: op mako :)
[09:33] <mako> so anyway
[09:33] <ogra> Amaranth, we're all grown up...
[09:33] <mako> https://www.ubuntulinux.org/wiki/UbuntuBackports
[09:33] <mdz> before we dive in, we should elect someone to take notes
[09:33] <mdz> and summarize the discussion, preferably in the form of a draft spec
[09:34] <mako> everytime we need quiet, mdz will ask that question
[09:34] <mdz> any volunteers?
[09:34] <mdz> mako: good idea
[09:34] <kassetra> well, I'll volunteer, but I'll need to know some specifics.
[09:34] <mako> kassetra: sure
[09:34] <mako> kassetra:  i can go over the form with you.. take notes often means just go through the log later
[09:34] <ogra> kassetra, see the specs on udu.wiki.ubuntu.com
[09:34] <kassetra> k.
[09:35] <mako> kassetra: thanks :)
[09:35] <mako> kassetra: but yeah.. if you need summary or overview, stop us at anytime
[09:35] <kassetra> ok.
[09:35] <kassetra> will do.
[09:35] <ogra> kassetra, there are alos logs of the meetings to review if you need
[09:35] <ogra> also even
[09:35] <kassetra> (ok.  :)
[09:36] <mako> ok.. so the agenda is not set in stone
[09:36] <mako> but we should try to stick to it generally
[09:36] <JohnDong> Ok
[09:36] <mako> we'll call for any othe comments on particular issues in the subsections
[09:36] <ogra> for anyone: people.ubuntu.com/~fabbione/irclogs/
[09:36] <mako> and we should be ready to put issues to rest or to put them off for a later meeting if we're going down a rathole
[09:36] <JohnDong> ok
[09:36] <fabbione> please somebody else should also record the irc logs
[09:36] <mdz> I'm logging
[09:36] <kassetra> I have them being recorded as well.
[09:37] <fabbione> since freenode is not exactly stable today
[09:37] <mako> i'm logging too
[09:37] <Amaranth> i'm logging
[09:37] <Burgundavia> I am logging
[09:37] <JohnDong> we get the point
[09:37] <Amaranth> hehe
[09:37] <mako> JohnDong: alright dude :)
[09:37] <JohnDong> lol
[09:37] <mako> JohnDong: why don't you give us a brief background on the backports project
[09:37] <JohnDong> sure
[09:37] <mako> emphasize what we probably don't know
[09:37] <Amaranth> in case of netsplit, stop discussion
[09:38] <JohnDong> The Backports project started halfway through Warty's release, when Firefox 1.0 came out
[09:38] <JohnDong> Primarily, I intended to address apps like GAIM And Firefox getting dated through the 6-month release cycle
[09:38] <JohnDong> From there, I registered a SF project and started offering two or three debs
[09:39] <JohnDong> Ryan also made arrangements with me for a Ubuntu Backports section @ the forums
[09:39] <JohnDong> since then, requests have been exponentially growing, and soon SF booted me off :)
[09:39] <mako> why?
[09:39] <JohnDong> too much bandwidth
[09:39] <Amaranth> too much bandwidth
[09:40] <JohnDong> to do APT repositories, I had to use Public Web Services
[09:40] <mako> how much bandwidth were you using?
[09:40] <JohnDong> 20GB or so daily
[09:40] <JohnDong> They've been "setting up a sandbox" for me, since last October :)
[09:40] <\-> this should tell how much people like the backports :)
[09:41] <JohnDong> Anyway, we moved to a Ubuntu Forums server and continued happily
[09:41] <JohnDong> Today, the repository houses 400 packages weighing in at 14GB, with about 40GB daily transfer and 24,000+ unique IP's logged in a 7-day period
[09:41] <Amaranth> damn
[09:41] <Lathiat> wow
[09:41] <mez>  That's not including Mirrors
[09:41] <mako> how many people are contributing backports
[09:41] <\sh> 1.2TB per month
[09:41] <mdz> JohnDong: which 400 packages?
[09:42] <JohnDong> primarily desktop programs from Universe
[09:42] <mako> can we get a list?
[09:42] <mdz> JohnDong: and how do you decide which packages?
[09:42] <JohnDong> users request them, I make sure they're not too big, then I package them
[09:42] <mako> JohnDong: are you the only person doing packages?
[09:42] <JohnDong> mako: it's available via rsync
[09:42] <fabbione> JohnDong: do you repackage them, or you use the ones from a newer ubuntu suite?
[09:42] <JohnDong> mako: no, there are 2 new developers, fairly recently added
[09:43] <mako> JohnDong: it might be nice to take a look at that list right now
[09:43] <mdz> JohnDong: do you support any non-i386 architectures?
[09:43] <JohnDong> before Hoary, I was the only one
[09:43] <mako> JohnDong: ok
[09:43] <JohnDong> we're starting to support powerpc
[09:43] <JohnDong> http://ubuntu-backports.mirrormax.net/
[09:43] <JohnDong> you can get a rough idea of what I backport by looking into the repository
[09:43] <Amaranth> you packaged 400 packages by yourself?
[09:43] <JohnDong> yeah
[09:43] <dholbach> 400 packages take up 14gb?
[09:43] <JohnDong> with history :)
[09:43] <ogra> how that ?
[09:43] <fabbione> JohnDong: can you answer my question please?
[09:44] <fabbione> JohnDong: do you repackage them, or you use the ones from a newer ubuntu suite?
[09:44] <mako> dholbach: many versions
[09:44] <JohnDong> sorry
[09:44] <JohnDong> fabbione: I recompile Breezy packages
[09:44] <pitti> JohnDong: you take unstable Ubuntu's packages and build them for hoary/warty? Or do you really repackage them? (Why?)
[09:44] <JohnDong> I try not to modify them
[09:44] <ogra> ouch
[09:44] <JohnDong> I take Ubuntu devel packages and rebuild them for Haory
[09:44] <pitti> ah, ok
[09:44] <mdz> so in what way is the result different, from a usability standpoint, from Breezy itself?
[09:45] <JohnDong> stability.
[09:45] <fabbione> JohnDong: what criteria do you use to select build-dependencies?
[09:45] <JohnDong> aah, one at a time
[09:45] <Amaranth> no g++ tranistion, no x transition
[09:45] <mdz> JohnDong: do you only update the packages when you decide that they are stable?
[09:45] <JohnDong> correct
[09:45] <mdz> Amaranth: but we didn't do those things during Hoary, and still there were backports
[09:45] <JohnDong> only when the community tests to deem it stable
[09:45] <Amaranth> mdz: agreed, it didn't make as much sense then
[09:46] <mdz> but it happened, so clearly there was some need
[09:46] <JohnDong> fabbione: I try only to select packages that are satisfied by Hoary dev packages
[09:46] <mako> JohnDong: do you rebuild against a system with backports or against a pure hoary system in each case?
[09:46] <mdz> I'm trying to establish what the use cases are which are not met, or not seen as met, by our existing offering
[09:46] <\sh> mdz: update policy of ubuntu ... but later
[09:46] <JohnDong> I rebuild against a Backports chroot
[09:46] <ogra> JohnDong, who reviews you packaging changes if they happen ?
[09:46] <mdz> what is it that users are looking for which leads them to backports, and not to any of our existing trees?
[09:46] <Amaranth> guys, one at a time please
[09:46] <NetGeek> sorry I'm late
[09:47] <dholbach> could all the backport developers in here raise their hand?
[09:47] <mako> NetGeek: we're all asking JohnDong questions at once
[09:47] <JohnDong> mdz, about the demand for Backports:
[09:47] <Mez> mdz, people coming to use backports are basically looking for the most up to date version of general desktop apps
[09:47] <JohnDong> some packages become useless very quickly
[09:47] <kassetra> mdz: typically a user request a backport because they want a new feature / bug fix, etc.
[09:47] <NetGeek> btw: I'm Mike a Backport Developer
[09:47] <mako> JohnDong: useless is pretty subjective
[09:47] <Amaranth> Mez: Are you the other one?
[09:47] <mdz> mako: extremely so
[09:47] <Mez> no - I'm a backports user ;)
[09:47] <fabbione> JohnDong, NetGeek: so.. how come there was a new version of glibc available from backports?
[09:47] <JohnDong> sorry for the bad wording
[09:47] <kassetra> mdz: if they're requesting an application be backported without a meaningful reason, we won't backport it.
[09:48] <JohnDong> aaahhhhhh
[09:48] <Amaranth> mako: If the user considers it useless, it's useless.
[09:48] <mdz> Amaranth: but different users have vastly different criteria
[09:48] <mako> kassetra: really?
[09:48] <JohnDong> fabbione: Firefox 1.0.4 Breezy is compiled with GCC4, so I decided to do the same
[09:48] <kassetra> mako: really.
[09:48] <jdub> mdz: interesting use case -> regularly putting new versions of cool (reviewed?) apps on a magazine coverdisk
[09:48] <mdz> I know a lot of people who are happy with the web browser, IM client, etc. in hoary, and even Warty
[09:48] <mako> kassetra: how many requests are rejected?
[09:48] <JohnDong> right now, it's a 50-50
[09:48] <mdz> jdub: I don't think that's what backports is being used for today, though
[09:48] <fabbione> JohnDong: did any of you evaluated the impact of a new glibc?
[09:49] <jbailey> fabbione: Did it appear and then go away?  I didn't see it in the backports tree when I was trying to hunt it down.
[09:49] <fabbione> and if so.. how
[09:49] <mdz> JohnDong: wait, so you're using g++-4.0 in backports now?
[09:49] <ogra> ouch
[09:49] <jdub> mdz: people see version number increases and begin to salivate, regardless of wheter or not it makes sense to upgrade
[09:49] <JohnDong> mdz: only with packages in breezy that explicitly call gcc-4.0
[09:49] <Burgundavia> jbailey, I did some hunting as well, and I couldn't find it on the usual suspects (backports, marilliat)
[09:49] <JohnDong> currently, that's ONLY FIREFOX
[09:49] <\sh> uhhhh
[09:49] <JohnDong> it DOES NOT COMPILE with 3.3
[09:49] <mako> lets try to stay away from the specifics right now
[09:49] <JohnDong> fabbione: what new glibc?
[09:49] <infinity> JohnDong : Would make more sense to edit firefox's debian/rules to not explicitly call the new compiler, then.
[09:50] <mdz> JohnDong: you can't build firefox with g++-4.0 unless you also build all its dependencies with g++-4.0
[09:50] <mdz> mako: this is valuable, for me at least
[09:50] <JohnDong> infinity: it still doesn't compile
[09:50] <mako> mdz: alright
[09:50] <infinity> JohnDong : what mdz said.  You're asking for a world of C++ ABI trouble.
[09:50] <JohnDong> the code has changed since
[09:50] <fabbione> JohnDong: somehow a bunch of users using backports did have a newer version of glibx
[09:50] <fabbione> glibc evenb
[09:50] <Amaranth> they had a crack repo enabled then
[09:50] <sabdfl> hi all
[09:50] <Amaranth> hey sabdfl 
[09:50] <mdz> it sounds like you're running into the ABI transition issue anyway
[09:50] <\sh> evening sabdfl 
[09:50] <Mez> fabbione, it's only in the staging area at the moment if I remember correctly
[09:50] <ogra> which caused a LOT of trouble and dragged a lot of manpower
[09:51] <Amaranth> JohnDong: You should explain staging maybe?
[09:51] <JohnDong> are we getting into specifics already???
[09:51] <kassetra> wait.
[09:51] <ogra> hey sabdfl 
[09:51] <mdz> sabdfl: JohnDong is helping to educate us about what backports are today
[09:51] <mako> ogra: hold off
[09:51] <fabbione> Mez: well the point is that it's breaking hoary-security updates (including the kernel)
[09:51] <ajmitch> hello sabdfl 
[09:51] <mvo> hey sabdfl 
[09:51] <kassetra> John: why don't you explain what mdz asked about first.
[09:51] <ogra> mako, sure
[09:51] <fabbione> Mez: but we can talk about tech details later
[09:51] <fabbione> hi sabdfl 
[09:51] <mako> fabbione: yes
[09:51] <doko> JohnDong, you should use a compiler from breezy, namely g++-3.4 -fabi-version=1. upgrading system libraries shouldn't be done in backports
[09:51] <JohnDong> thanks for that info
[09:51] <\sh> JohnDong: why didn't u try to talk to the devs for reviewing the policy of updating ubuntu?
[09:51] <Amaranth> I thought 3.4 was ABI incompatible with 3.3
[09:51] <mdz> doko: let's discuss for now what is happening, and later decide what should happen :-)
[09:51] <doko> s/breezy/hoary/ of coursse
[09:52] <mako> i think we should probably try to establish something like this a little bit later as a good policy to move forward with
[09:52] <mako> what mdz said
[09:52] <mako> JohnDong: why don't explain staging
[09:52] <mdz> \sh: it has come up many times already; we will not abandon the idea of a stable release
[09:52] <Amaranth> ok, let's try to get back on track
[09:52] <\sh> mdz: i know :)
[09:52] <JohnDong> staging: When a backport gets packaged it goes into beta-testing under the -staging section of the repository
[09:52] <JohnDong> that way, we can see how the package behaves in a live APT repo
[09:53] <Mez> mako: it says this about staging "But, BIG FAT WARNING: The staging area should be treated like Debian experimental -- it's NOT tested, NOT guaranteed in any way, shape or form to be stable!"
[09:53] <mako> how many people use it?
[09:53] <siretart> JohnDong: what criteria do you have for moving it to the regular backport archive?
[09:53] <mako> how long do things stay in staging?
[09:53] <Amaranth> 7 days, iirc
[09:53] <JohnDong> stuff stays in staging for at least a week, sometimes a month or more
[09:53] <NetGeek> mako, one week usually
[09:53] <sabdfl> is -staging like -security or -updates?
[09:54] <JohnDong> no
[09:54] <sabdfl> it's a separate little repo?
[09:54] <JohnDong> it's like a -experimental
[09:54] <JohnDong> yep
[09:54] <sabdfl> ok
[09:54] <mako> sabdfl: no, it's just testing for the main backports archive
[09:54] <JohnDong> to separate the testing from the stable
[09:54] <kassetra> mako: we try not to let go of items in staging if there are still errors.
[09:54] <JohnDong> siretart: no bug reports in staging
[09:54] <sabdfl> ok. so folks who want latest crack go there, others get it from  the primary backport repo
[09:54] <mako> how are bugs reported?
[09:54] <mdz> JohnDong: yes, it is like -security or -updates in the sense that sabdfl meant
[09:54] <JohnDong> NONE... it's a beta testing area
[09:55] <kassetra> sabdfl: well, those are the ones we mark "for testing purposes only!"
[09:55] <JohnDong> it's more like a testing area for -updates
[09:55] <suifur> mako: we receive them via our forum at http://ubuntuforums.org
[09:55] <JohnDong> the entire Backports repo is like hoary-updates
[09:55] <siretart> JohnDong: do you have a bug tracking system or goes bugreporting exclusivly through webforums?
[09:55] <mdz> yes, but the point of testing is to get feedback :-)  where does the feedback go?
[09:55] <kassetra> mdz: the forums
[09:55] <mdz> there must be some means to report problems, or you wouldn't know whether they work or not
[09:55] <JohnDong> in the Ubuntu Backports section of Ubuntuforums
[09:55] <mdz> ok, so bug reports go to the forums
[09:55] <mako> mdz: it all goes to the forums
[09:55] <JohnDong> correct
[09:56] <mako> alright.. 
[09:56] <sabdfl> JohnDong: would it be useful to have a more structured bug management system for the staging area? or do you actively want that stuff on a forum/mailing list?
[09:56] <JohnDong> sabdfl: not really, do you really want users to register for another account??
[09:56] <JohnDong> they'd be much less willing to file a bug report
[09:56] <sabdfl> Kinnison is writing the infrastructure which will manage archives etc for breezy+1, so i thought to invite him along
[09:56] <\sh> JohnDong: when those people reporting to official bugzilla or malone...it doesn't matter ;)
[09:57] <suifur> sabdfl: the forum has been effective and we've seen no reason to change the bug-reporting system
[09:57] <mako> JohnDong: well, it would be the same login for the website, wiki, launchpad, etc
[09:57] <sabdfl> JohnDong: we only do one account around here :-)
[09:57] <siretart> JohnDong: take a look at the debian bts. you can file bugs without accounts there
[09:57] <Amaranth> heh, with smeg they don't even seem to be willing to make a new thread for bugs, asking them to make a new account somewhere would kill any hope for bug reports
[09:57] <JohnDong> mako: If it can be integrated with Ubuntu's bugzilla, that'd be awesome
[09:57] <sabdfl> JohnDong: it would be
[09:57] <mako> JohnDong: exactly
[09:57] <JohnDong> I'm all for it :)
[09:57] <mdz> JohnDong: there is already a single login for the website/wiki, malone, rosetta, etc.
[09:57] <mako> ok, that's a possibility
[09:57] <sabdfl> we already have the infrastructure to support this
[09:57] <\sh> can we wait with integrating something in something?
[09:58] <JohnDong> thanks for letting me know
[09:58] <Amaranth> ok, back on track
[09:58] <mdz> it would be nice if we could share credentials with the forums
[09:58] <JohnDong> yeah
[09:58] <mako> before we move on though, can we back to questions about backports is and what it is doing?
[09:58] <Amaranth> mdz: talk to Ryantroy 
[09:58] <JohnDong> ONE AT A TIME :) :)
[09:58] <Ryantroy> Hello
[09:59] <\sh> JohnDong: so r u only backporting apps or also essential libs (libs in main and/or universe?)
[09:59] <JohnDong> no libs
[09:59] <JohnDong> just apps
[09:59] <JohnDong> mostly in universe
[09:59] <JohnDong> but a hand-picked FEW in main
[09:59] <JohnDong> like Firefox, Gaim, xchat
[09:59] <JohnDong> I've never went deeper than that :)
[09:59] <mako> any other questions about what backports are.. how they are done, etc?
[09:59] <ogra> JohnDong, but hwo do you handle C++ then ?
[09:59] <mdz> JohnDong: what do you do if the current version of the app in Breezy doesn't work with the libs/infrastructure currently in backports?
[09:59] <JohnDong> mdz: with the second FF 1.0.4 backport, I've tried to introduce GCC4
[10:00] <ogra> in hoary ?
[10:00] <JohnDong> I though since GCC4's alpha was already in Universe, introducing the real thing wouldn't hurt
[10:00] <JohnDong> yeah
[10:00] <JohnDong> After a month of testing, nobody's said anything's wrong
[10:00] <JohnDong> and I use ubuntu for at least 8 hours daily
[10:00] <\sh> JohnDong: did u have any concerns breaking binary compatiblity in hoary?
[10:00] <JohnDong> I did, and that's why it stayed in -staging for a month
[10:00] <sabdfl> JohnDong: is FF C++?
[10:01] <JohnDong> yes
[10:01] <mdz> sabdfl: very much so
[10:01] <Amaranth> *shudder*
[10:01] <mdz> JohnDong: so what did you do about the ABI transition?
[10:01] <Amaranth> so wouldn't that break everything in hoary that uses firefox?
[10:01] <JohnDong> I haven't seen any problems yet
[10:01] <sabdfl> is the breakage then confined to any FF libraries that other apps might use?
[10:01] <JohnDong> All that build on mozilla-firefox-dev work fine
[10:02] <mdz> JohnDong: after a rebuild, you mean
[10:02] <JohnDong> no, no rebuild
[10:02] <JohnDong> Epiphany worked fine
[10:02] <ogra> JohnDong, o still use mozilla-ff, not ff ?
[10:02] <Amaranth> that's impossible
[10:02] <\sh> Amaranth: not at all...if u r using ff as an app it won't break anything...if you need some things from some ff libs u r lost
[10:02] <mdz> oh, firefox-dev exports a C interface, not a C++ one
[10:02] <JohnDong> ogra: I have both names as aliases for each other, to aid in transition
[10:02] <ogra> OUCH
[10:02] <doko> firefox doesn't have any external C++ build deps, so if you don't build firefox-dev, then the C++ ABI version doesn't matter
[10:02] <\sh> mdz: no c++ stuff in those libs?
[10:02] <JohnDong> I tested Firefox dependents a lot
[10:02] <mdz> \sh: inside, yes, but not exporting an interface
[10:03] <ogra> did you check how it breaks upgradeability ?
[10:03] <\sh> mdz: ok 
[10:03] <JohnDong> I play with chroots and bringing them to 
[10:03] <JohnDong> Breezy
[10:03] <JohnDong> Also, I use the "~" version tag in Backports
[10:03] <JohnDong> so everything's "older" than Breezy
[10:03] <Amaranth> i've never quite understood how that worked
[10:03] <JohnDong> All backports get removed when someone apt-get upgrades to Breezy
[10:03] <JohnDong> Amaranth: foo 1.0.0~ubp is older than foo 1.0.0
[10:04] <JohnDong> the "~" tag is special
[10:04] <mdz> JohnDong: how can you be sure of that (all backports get removed)?
[10:04] <mako> well, that's one part of upgradability
[10:04] <JohnDong> mdz: because I know all Backports packages are older than Breezy's
[10:04] <sabdfl> the version ordering is well documented and implemented
[10:04] <Amaranth> so you have to bump the version number to match the one in breezy?
[10:04] <mdz> JohnDong: what if the package is removed in breezy?
[10:04] <sabdfl> if there's a ~ in there it's older
[10:04] <JohnDong> how often does Firefox get removed from Breezy ? ;)
[10:04] <mdz> JohnDong: we're going to do it shortly
[10:05] <mdz> mozilla-firefox has been renamed to firefox
[10:05] <sabdfl> mdz: we don't in any event guarantee that a hoary -> breezy upgrade == breezy install
[10:05] <JohnDong> To answer your question: I make an override package in Breezy backports
[10:05] <JohnDong> mdz: what do you do without backports if Firefox is removed?
[10:05] <mdz> sabdfl: no, but we know where everything came from
[10:05] <mdz> JohnDong: we'll rely on the metapackages for the transition
[10:05] <sabdfl> mdz: we won't in the real world with 3rd party ISV's, so we shouldn't be too paranoid
[10:05] <mdz> sabdfl: that's different, backports contain infrastructure components, ISV's don't
[10:06] <JohnDong> mdz: If it doesn't get automatically overridden in extreme cases, I'll do it via a fake Breezy backport
[10:06] <JohnDong> I've yet to see this happen though...
[10:06] <mdz> it depends entirely on which packages you decide to backport
[10:06] <mdz> which is one of the reasons I'm interested in that list
[10:07] <JohnDong> any good place for me to post it?
[10:07] <sabdfl> the wiki
[10:07] <ogra> JohnDong, ubuntu-devel mailinglist
[10:07] <fabbione> or both
[10:07] <ogra> yep
[10:07] <fabbione> ;)
[10:07] <siretart> :)
[10:07] <Amaranth> you want to dump a list of 400 packages in the wiki?
[10:07] <\sh> summary: there is a extra repos  with ca. 400 packages making 1.2TB per month downloads 
[10:07] <\sh> JohnDong: why didn't u apply for a motu job? ,-)
[10:07] <mako> Amaranth: yes.. 
[10:07] <ogra> Amaranth, sure we work with it regulary on such a base with MOTU
[10:08] <mako> Amaranth: 400 is not so long a list
[10:08] <Amaranth> ogra: I seem to remember firefox locking up and crashing on those MOTU pages. :)
[10:08] <\sh> Amaranth: the c++ transistion list is on the wiki...and it works ;) 
[10:08] <ogra> Amaranth, thats a ff bug ;)
[10:08] <kassetra> I'll add the package list to the wiki.
[10:08] <mako> kassetra: great, thanks
[10:08] <mako> alright.. 
[10:09] <mako> are there more specific questions for JohnDong or others about what backports do or how they do it?
[10:09] <mako> if not, we can move on...
[10:09] <\sh> mako: the how is explained on their webpage
[10:09] <JohnDong> sent to the list
[10:09] <mako> JohnDong: thanks
[10:09] <mdz> I count 184 packages in hoary-backports
[10:09] <JohnDong> yeah
[10:09] <JohnDong> Warty has quite a few, too
[10:09] <mdz> main+restricted+universe+multiverse
[10:09] <mdz> oh, so that's 400 .debs
[10:09] <Amaranth> mdz: don't forget extras
[10:09] <JohnDong> yeah
[10:10] <JohnDong> extras, too
[10:10] <mdz> how many actual source packages, do you know?
[10:10] <JohnDong> I don't have that number
[10:10] <mdz> there are no sources on the backports mirror
[10:10] <JohnDong> they're all Breezy sources
[10:10] <pitti> JohnDong: to what percentage you can used breezy source packages unmodified?
[10:10] <JohnDong> I thought wasting space on that would be pointless
[10:10] <sabdfl> need to have sources :-)
[10:10] <mako> JohnDong: you should probably fix that, from a gpl compliance issue
[10:10] <JohnDong> pitti: 100%
[10:10] <pitti> JohnDong: uh, that's surprising :-)
[10:11] <JohnDong> mako: can I just point to Ubuntu sources?
[10:11] <fabbione> that's impossible
[10:11] <ogra> yep
[10:11] <JohnDong> why do you say so?
[10:11] <ogra> JohnDong, not if you modified them
[10:11] <Amaranth> we've seem how many things have changed in breezy
[10:11] <ogra> JohnDong, (pomit to ubunu that is)
[10:11] <ogra> pint even
[10:11] <Amaranth> for instance, any C++ backport would be changed
[10:11] <fabbione> because there are at least a few dependencies or build-dependencies that you need to modify
[10:11] <mako> JohnDong: you need to be responsible to provide them to people
[10:12] <ajmitch> and also because you need to at least change the version number to rebuild each one
[10:12] <mdz> 54 source packages
[10:12] <bob2> if nothing else, you've changed the version
[10:12] <mdz> so we are talking about a MUCH smaller amount of code than I thought
[10:12] <mako> alright.. in most cases, the changes are very minor
[10:12] <JohnDong> yeah;
[10:12] <ogra> JohnDong, GPL forces _your_ to provide your changes as source...
[10:12] <mako> mdz: that's good news
[10:12] <Amaranth> 54 slightly changed source packages
[10:12] <JohnDong> changes are limited to a few extra chars on changelogs
[10:12] <JohnDong> ogra: how about "~5.04ubp1"????
[10:12] <mdz> http://people.ubuntu.com/~mdz/temp/backports-sources.txt
[10:12] <mako> JohnDong: still need to provide source but that's not a conversation we need to have
[10:13] <Amaranth> this is starting to not sound so bad
[10:13] <mdz> 5 versions of gcc!
[10:13] <ogra> JohnDong, that doesnt give ppl the changes in the source
[10:13] <JohnDong> mdz: huh?
[10:13] <tseng|work> JohnDOng: you cant post a binary w/o source if its a different binary than in breezy
[10:13] <mdz> oh, that's probably an error in my source mapping logic
[10:13] <JohnDong> the binaries ARE NOT DIFFERENCE
[10:13] <JohnDong> DIFFERENT
[10:13] <ogra> JohnDong, sure
[10:13] <Amaranth> can't you provide sources as a patch against the breezy source?
[10:13] <zul> mdz: i noticed linux-image-2.6.10-19 was there as well
[10:13] <JohnDong> sure
[10:13] <ogra> Amaranth, yes
[10:14] <mako> alright lets try to reign this in a bit.. the source distribution issue and gpl stuff is not super relevant
[10:14] <mako> at least not to this discussion
[10:14] <doko> JohnDong, why do you need all these GCC versions?
[10:14] <\sh> at least, we know now, that backports is not only updating, it's even upgrading in some areas (like ff)
[10:14] <infinity> doko : I think that was an error in mdz's script. :)
[10:15] <mdz> yes, I've fixed it up by hand
[10:15] <JohnDong> doko: what GCC version???
[10:15] <mdz> the fastest way to do it was to map the packages based on breezy
[10:15] <fabbione> mdz: kernel is still missing :)
[10:15] <JohnDong> zul: that was for Warty
[10:15] <mako> JohnDong: it was a script error :)
[10:15] <ogra> gcc-4.0_4.0.0-7ubuntu6~5.04ubp1_i386.deb
[10:15] <JohnDong> lol
[10:15] <JohnDong> ok
[10:15] <mdz> fabbione: feel free to do it yourself
[10:15] <ogra> gcc-4.0-doc_4.0.0-7ubuntu6~5.04ubp1_all.deb
[10:15] <Amaranth> aside from mono this list doesn't look bad at all
[10:15] <mdz> I just wanted an idea of what was there
[10:15] <JohnDong> guys, a family issue has popped up
[10:15] <JohnDong> I'll need to leave for about 15-20 minutes
[10:15] <fabbione> mdz: hence the ":)"
[10:16] <zul> JohnDong: that was still way behind
[10:16] <mako> JohnDong: alright.. 
[10:16] <mako> are there other bp people around?
[10:16] <JohnDong> zul: that never made it to stable
[10:16] <JohnDong> yeah
[10:16] <kassetra> yes.
[10:16] <Amaranth> NetGeek
[10:16] <mako> JohnDong: hurry back
[10:16] <JohnDong> and Kass can help you out
[10:16] <Ryantroy> hello
[10:16] <Amaranth> oh, and kassetra 
[10:16] <JohnDong> I'll keep logging
[10:16] <kassetra> :)
[10:16] <ogra> there is a ton of libs in that list
[10:16] <mdz> fabbione: I see no linux-* anywhere in the hoary-backports Packages.gz
[10:16] <mdz> Ryantroy: hi
[10:16] <Amaranth> and Ryantroy has something to do with all of this, as ubuntuforums admin
[10:16] <Amaranth> i guess
[10:16] <pitti> uh, tla, but no bazaar :-/
[10:17] <fabbione> mdz: as JohnDong said, it's in warty from hoary
[10:17] <mdz> fabbione: did I miss something?
[10:17] <Amaranth> who would request tla? :P
[10:17] <mdz> fabbione: I only looked at hoary backports
[10:17] <fabbione> well there are backports to warty too.. zul?
[10:17] <Amaranth> btw, nothing from main is a bit extreme
[10:17] <mako> i have one more question
[10:18] <zul> fabbione: i believe so
[10:18] <siretart> are the backports for warty updated with sources from breezy?
[10:18] <mako> are people actively backporting stuff to warty still?
[10:18] <ajmitch> Amaranth: supportability issues for canonical..
[10:18] <zul> mdz: i saw it in the forums...ill dig it up again
[10:18] <\sh> at least no libstdc++6 ;)
[10:18] <\sh> in warty
[10:18] <tseng|work> i was told that backports to dists were removed when the dist+1 became rasonably stable
[10:18] <Mez> mako - according to the developers group - this stoopped a while back
[10:18] <ogra> Amaranth, but that breaks stuff, heavily
[10:18] <mako> Mez: ok.. good to know
[10:18] <Amaranth> for example, gnome-menus in hoary has a bug that makes menu editing impossible, the patch is about 60 lines
[10:18] <zul> mdz: http://www.ubuntuforums.org/showthread.php?t=15913
[10:18] <tseng|work> or just stopped new backports I guess
[10:19] <doko> \sh, libstdc++6 is in warty
[10:19] <mdz> zul: ok, that's warty
[10:19] <doko> maybe universe
[10:19] <kassetra> tseng: correct.
[10:19] <mako> alright.. we need to move on
[10:19] <Amaranth> they don't have the bandwidth to support backports for more than one distro
[10:19] <Amaranth> err, more than one distro release
[10:19] <mdz> I would like to raise the question of security support
[10:20] <mako> can we establish if there are any more remaining questions here about what backports are?
[10:20] <mdz> once a package has been backported, how are security  updates handled?
[10:20] <ogra> mako, the list is enough
[10:20] <mdz> (if they are)
[10:20] <mkde> i am interested in "why" the backports are
[10:20] <mako> kassetra, Mez: ?
[10:20] <Amaranth> mako: i think we're good there
[10:20] <Ryantroy> Amar: we got 4 mirrors now and the main BP server has plenty of bandwidth
[10:20] <mkde> maybe that is OT tho
[10:20] <ogra> mako, and JohnDong's explanations
[10:20] <Amaranth> mkde: was explained at the beginning
[10:20] <kassetra> mdz: let me grab that explanation for you.
[10:20] <mako> kassetra: great
[10:20] <mkde> Amaranth, ok i missed it
[10:20] <Amaranth> mkde: check fabbione's logs
[10:20] <mkde> Amaranth, they are not quite current i don't think
[10:21] <mkde> but i will later
[10:21] <sabdfl> mdz: if backports are generally the next version's sources, they would inherit our security work
[10:21] <Amaranth> mkde: want me to paste in a PM for you?
[10:21] <\sh> the bandwidth is nothing...when I think about the wide user range
[10:21] <mkde> Amaranth, that would be lovely thanks
[10:21] <Amaranth> sabdfl: only if the backport is updated
[10:21] <mako> sabdfl: right, but not on our timescale
[10:21] <kassetra> sabdfl: correct, and yes, we do update backports.
[10:21] <fabbione> sabdfl: only if they are regularly maintained
[10:21] <ogra> sabdfl, only if upgradeability is guaranteed
[10:21] <fabbione> well as the above
[10:21] <kassetra> mako: John stays on top of security fixes for any package he backports.
[10:22] <mdz> sabdfl: we don't do security work in the development branch until after upstreamversionfreeze, at the earliest
[10:22] <ogra> kassetra, for all 400 ?
[10:22] <infinity> sabdfl : Only if they continue to upgrade their backports.  People will often backport a version, then not update it for a month.
[10:22] <mako> and since there are only ~50 source packages, that's relatively straight forward
[10:22] <mdz> it would be a waste of effort
[10:22] <pitti> JohnDong: are you aware that currently I do not actively do security updates for Breezy? mostly we get them through Debian
[10:22] <kassetra> ogra: yes.
[10:22] <Amaranth> we are now down to one bp developer here
[10:23] <mako> Amaranth: JohnDong will reappear in a few minutes
[10:23] <ogra> kassetra, so he is subscribed to the secret mailing lists handling vulnerabilitys ?
[10:23] <kassetra> mako: exactly, we aren't backporting large amount of code, so security fixes are relatively minor.
[10:23] <kassetra> ogra: yes.
[10:23] <ogra> ok
[10:23] <pitti> most issues are fixed, but there are certainly one or two unfixed vulnerabilities in Breezy
[10:23] <mdz> pitti: he's away for a bit
[10:23] <mako> kassetra: right, but pitti is saying that *we're* not even providing real security support for the breezy packages
[10:23] <pitti> yeah, I just noticed
[10:24] <mako> can i get one last call for open questions about backports?
[10:24] <kassetra> mako: right, he checks securityfocus as well.
[10:24] <Mez> mako, so doesnt htta mean tahtyou're making the people helping out by bugtesting breezy vulnerable to security issues?
[10:24] <pitti> Mez: really bad issues are fixed
[10:24] <mako> we're making them vulnerable to a wide range of issues.. welcome to development releases
[10:25] <Amaranth> Mez: it's a development version, they really shouldn't expect it to be bug and exploit free
[10:25] <sabdfl> infinity: what if we did it automatically?
[10:25] <pitti> Mez: but if it is convenient, I just mail a patch to Debian and wait until they fixed it, which might last a week in some cases
[10:25] <mako> alright.. 
[10:25] <mako> lets move on
[10:26] <infinity> sabdfl : Then you lose the promised stability of a backport repo.  When I used to backport stuff, I would pay attention to the debian changelogs (okay, I cheated, i wrote the debian changelogs), and I'd only backport and publish known-good versions.
[10:26] <Mez> piti, then if you're deeming certain things to be not "important" enough to be fxe din your dev version, does it make a difference if they're in the backport?
[10:26] <infinity> sabdfl : You can't really automate that sort of "I think this version's good and stable enough to release it to users" very well.
[10:26] <mkde> Mez, yeah because the backport gets used with peoples' hoary
[10:27] <ogra> Mez, its a _development_ version.... we only care about the most critical things
[10:27] <mkde> which should be secure/stable
[10:27] <pitti> Mez: yes, I think so, since stable versions should not have any open issues
[10:27] <sabdfl> infinity: good point
[10:27] <pitti> Mez: well, it depends what the bp audience is; for desktops, it's probably alright, but for servers you can get screwed
[10:27] <sabdfl> maybe we could have an auto-built repo, and a migrated-from-autobuilt-by-hand-cos-it's-solid repo
[10:27] <mako> pitti: it's mostly desktop applications
[10:27] <mako> in any case
[10:28] <Mez> pitti: near enough everything that is backported are desktop apps
[10:28] <Amaranth> desktop apps and utilities, it looks like
[10:28] <ogra> sabdfl, grumpy auto security ?
[10:28] <mako> i'd like to sort of help kassetra with the notes by putting together a list of concerns and limitations of backports now
[10:28] <pitti> .... apart from samba, yes
[10:28] <mako> if you'll let me steer conversation in that way
[10:28] <mako> we've done a bit of that already
[10:28] <\sh> pitti: if we were talking about servers they won't have 1.2TB per month bandwisth on one server ;)
[10:28] <mako> but i think it will be helpful to sort of establish the problems briefly before we establish thes olutions
[10:28] <Amaranth> mako: good idea
[10:28] <mako> there are a number of classes of issues out there
[10:29] <Amaranth> perhaps we should debunk the myths about backports at the same time?
[10:29] <mako> i've roughly divied it into integration with the largest project issues, qa issues, communication issues and others
[10:29] <sabdfl> if this can fit into our existing plans (which we can stretch a little to accommodate the backports team) then we can provide servers and bandwidth
[10:29] <mako> Amaranth: i'm not entireliy sure what that is
[10:29] <ogra> Amaranth, myths ?
[10:29] <sabdfl> JohnDong: where are you based?
[10:29] <mdz> sabdfl: we'd want to semi-automate it, I think
[10:29] <kassetra> sabdfl: he's in Michigan, US.
[10:29] <mako> Amaranth: if you want to do that, and you think it's the correct time to do it, why don't you go ahead and do that
[10:29] <tseng|work> what if we had a list to be "auto" built
[10:30] <tseng|work> from stuff JohnDong verified by hand
[10:30] <Amaranth> well, most of them are cleared up now, but for example before this meeting everyone thought using backports would completely break upgrades
[10:30] <tseng|work> a whitelist.
[10:30] <Amaranth> but perhaps that goes along with the concerns
[10:30] <mako> we can please hold off on the solutions until we've given folks a chance to identify the problems
[10:30] <ogra> Amaranth, it did for the warty -> hoary part, for a lot of people
[10:30] <sabdfl> sorry mako :-)
[10:30] <mdz> sabdfl: have a human decide when something should be backported, and the system handles the rest
[10:30] <mako> not everybody shares the same concerns here.. or even knows what other people's concerns are :)
[10:31] <mako> we all know what our own concerns are :)
[10:31] <Amaranth> yeah, let's go through concerns for now
[10:31] <Mez> ogra, yes it did, which is when John put in the work to make sure that didnt happen in for futre upgrades
[10:31] <mako> Amaranth: go ahead, dispell some myths
[10:31] <Amaranth> mako: I'm not a bp dev, the main one I know of is the upgrading. It was true before, doesn't seem to be now. Anyway, I think it goes along with the concerns.
[10:31] <ogra> Mez, how can he make it sure now, breezy doesnt even exist as it will when the upgrade will happen
[10:32] <Amaranth> mako: If a concern isn't warranted, the bp devs can say so and explain why.
[10:32] <\sh> mako: I'm thinking only about the users not the devs...what impact will it has, when backports are not there, and the users get p*ssed off why they don't get a ff 8.0 at the same day as it is released
[10:32] <ogra> Mez, we transition half of the world currently
[10:32] <Mez> ogra: John explained it earlier
[10:32] <mako> \sh: i think we've already established taht backports are desired by many people
[10:32] <mako> people want a stable system with a brand new FF or something
[10:32] <mako> lots of people
[10:33] <Ryantroy> tons of people
[10:33] <tseng|work> mako: most of my concernts are out of line with everyone elses and we came to a conclusion out-of-band
[10:33] <Amaranth> every regular user, it seems :)
[10:33] <Mez> the ~ operator makes for example package-1.0.0~ubp1 older than package-1.0.0, so it will upgrade properly
[10:33] <ogra> Mez, i saw it, i'm not confident since all library names for c++ stuff changes still for example
[10:33] <mako> tseng|work: shouldn't keep you from saying it
[10:33] <herve> how did you measure the "tons of people"?
[10:33] <mako> herve: 24k/week
[10:33] <ogra> Mez, the ~ doesnt apply if a name changed
[10:33] <\sh> mako: yeah, but because of this, i'm thinking about this issue...for main, i'm quite concerned, for universe i would say: ok, one new version compiled against the libs of ubuntu hoary/breezy/breezy+1 could be ok
[10:33] <Amaranth> herve: using 1.2TB/month should be a useful measure
[10:34] <Mez> ogra, which is where John tracks things like this and makes meta-packages to aid the transition
[10:34] <kassetra> mako: I myself requested a backport for an application that had a massive spec change.
[10:34] <ogra> Mez, since its a totally different binary package then
[10:34] <Ryantroy> herve: before we had mirrors the main server was pushing a solid 10mbit pipe daily 24x7
[10:34] <tseng|work> makoL just basically mono is too large/complex to be backported by someone who hasnt worked with the packages for quite some time. its a large "stack" with interdependencies and such.
[10:34] <ogra> Mez, so he's aware of the c2 names ?
[10:34] <mako> tseng|work: right, i think that's a reasonable thing to bring up
[10:34] <mako> tseng|work: so, your concern is in porting things like interpretors
[10:35] <tseng|work> we already agreed on why he shouldnt port something this large/complex
[10:35] <ogra> Mez, ... and the source changes that have to be made to a package to match them
[10:35] <kassetra> tseng: yes, and we aplogize for mono.
[10:35] <tseng|work> he ported the interpreter and no tthe bindings and appliactions
[10:35] <\sh> i would like to see a system like kubuntus (riddell ping) update system...(as seen with 3.4.1)
[10:35] <tseng|work> several things wont work, the rest works by sheer luck
[10:35] <mako> i think the integration into the major project concerns were already raised in the forms of figuring out what the backpots project is
[10:35] <mako> so..
[10:35] <tseng|work> but its a non issue since we agreed already, I think.
[10:36] <\sh> so..concentrating only on the main desktop things like kde/gnome/xfce != main
[10:36] <mako> in terms of concerns, i've got some things on the wiki
[10:36] <kassetra> \sh: we're more similar to fedora's "rolling backports"
[10:36] <Riddell> the kubuntu system is popular (pretty well expected) but not perfect
[10:36] <Mez> ogra: you have to rememebr mnost of these are desktop apps, and will rarely change package name :D if they do, it's are, and a meta-package can be made
[10:36] <kassetra> Also, I have added the backport package list to the wiki.
[10:36] <\sh> kassetra: lets talk about something else then fedora...
[10:36] <mako> basically, there's a percieved difficulty in providing QA for these packages
[10:36] <ogra> Mez, i'm not upset or something, but we (MOTU) and your group should vlerly work closer together to make sure that works
[10:36] <Mez> ogra, I'm not part of any group ;) just a bp supporter
[10:37] <ogra> Mez, the libs _below_ the desktop packages changed their names....
[10:37] <Mez> and isnt that the aim of this meeting
[10:37] <Amaranth> ogra: when the desktop package upgrades to breeze i don't see how that would be a problem
[10:37] <Amaranth> err, breezy
[10:37] <mako> alright
[10:37] <Mez> as amaranth says, when it upgrades to breezy, it will use the dependency list of the new package witht eh new names
[10:38] <ogra> Amaranth, the dependencys dont match
[10:38] <kassetra> mako: I think that the QA questions stem from users talking with developers instead of John about the backports, correct?
[10:38] <Mez> It's  for breezy devs to make sure that works ;)
[10:38] <mako> right
[10:38] <philipacamaniac> \sh: what do you like specifically about the kubuntu update system?
[10:38] <siretart> Amaranth: right now, uploads for C++ application are restricted. as soon as this restriction is removed, backporting them will get more challenging.
[10:38] <mdz> kassetra: yes, it's very awkward to have so much parallel infrastructure for QA
[10:38] <Amaranth> ogra: the breezy package will get used over the backports one, so the dependencies will be updated
[10:38] <ogra> Amaranth, all backports might break once in a while while we transition ther architecture below
[10:38] <\sh> philipacamaniac: they're conform with the system...no breakage of the system 
[10:38] <mdz> kassetra: it's frustrating for developers to receive bug reports from backports users
[10:38] <mako> kassetra: well, there is this issue that people want to be able to install a single package and still get support from the ubuntu community
[10:39] <mako> but they now have a system that is not pure ubuntu
[10:39] <mako> and not even *known* ubuntu
[10:39] <Amaranth> siretart: that is true
[10:39] <philipacamaniac> \sh: That's because Riddell made them... If MOTU was in charge of backports, then...
[10:39] <Amaranth> mako: that's the same problem with ubuntuguide telling people to use marillat
[10:39] <kassetra> mdz: we're working on ways of making sure users know that backports are only supported by the backports team.
[10:39] <\sh> philipacamaniac: it doesn't have to do with motu
[10:39] <mako> Amaranth: that is a problem, and it's been raised with the author
[10:39] <\sh> or riddell
[10:39] <Burgundavia> Amaranth, mako the docteam is working with the author on that
[10:39] <\sh> (that was luck ;))
[10:40] <ogra> kassetra, a package where the changes are not reviewed by at least 3 other devs cant even enter universe currently, i'd like to see such a QA in the backpors too....
[10:40] <mako> do people have any other comments or additions to the list of limiations that we had collected before
[10:40] <kassetra> ogra: typically john doesn't make a change to anything except the version number.
[10:40] <mako> kassetra: there *is* less overview and qa for backports than there is for universe now
[10:41] <mako> kassetra: introducign large amounts of new code into a system is a major change
[10:41] <ogra> kassetra, how do i know, i cant see the source
[10:41] <mako> ogra: that's another issue
[10:41] <ogra> mako, yes
[10:41] <mako> ogra: JohnDong has said these are almost always clean rebuilds from breezy and there's no reason to doubt that
[10:41] <kassetra> ok, mako: we use breezy sources - so whatever qa and overview breezy sources use, we benefit from that as well.
[10:42] <mdz> kassetra: what about the atypical cases?  at least firefox falls into that category
[10:42] <mako> kassetra: but that is the point that mabye you don't realize.. that code is *development* code
[10:42] <mdz> building with a different toolchain is a major divergence
[10:42] <kassetra> mako: no, I do understand, exactly.
[10:42] <Mez> ogra: assuming that ubuntu started mirroring backports etc etc, then John owuld be able to upload the sources aswell...
[10:42] <ogra> mako, sorry but he also said he didnt backport libs... 
[10:42] <ogra> Mez, ok :)
[10:42] <kassetra> ogra: exactly.
[10:42] <Mez> but, at the moment, he does have the bandwidth to handle it :D
[10:43] <ogra> mako, and his package list is full of libs
[10:43] <mako> kassetra: introducing a huge ball of development code into a stable system is a major change and makes the entire system less reliable and more difficult to support
[10:43] <mdz> ogra: there are pretty few libraries in hoary-backports
[10:43] <ogra> mdz, i only look at the list he mailed
[10:43] <kassetra> mako: ok, we're not talking backporting libraries or any multi-level applications.
[10:43] <Amaranth> if you say no backports for things in main then the main reason for having the backports is gone (firefox and gaim)
[10:43] <mdz> perhaps there are more in warty-backports; I didn't look at his list
[10:44] <mako> Amaranth: dude, don't jump to the end of the agenda
[10:44] <Amaranth> mako: sorry
[10:44] <Amaranth> mako: the agenda seems to have fallen apart...
[10:44] <mako> Amaranth: well, don't make it worse
[10:44] <Mez> where in the agenda are we?
[10:44] <Mez> ish
[10:45] <mako> we're in the problems issues
[10:45] <ogra> mdz, 68 libs according to: grep ^lib |wc -l
[10:45] <\sh> Amaranth: i was my statement, just because, as I understand, "main" is actively supported
[10:45] <mako> right above proposals
[10:45] <Amaranth> ok
[10:45] <Amaranth> the only concerns i have are that more and more things are going to have to be changed to make breezy things run on hoary after the transition finishes
[10:45] <kassetra> mako: typically we don't introduce items that aren't already compatible with the OS and system-relevant libraries.
[10:46] <JohnDong> ok, I'm back guys.....
[10:46] <kassetra> ogra: please take a look at those "libraries" first.
[10:46] <mako> kassetra: nobody is accusing anybody of introducing maintainability problems intentionally
[10:46] <mako> JohnDong: great :)
[10:46] <Amaranth> good, now we can get back on track :)
[10:46] <JohnDong> so I read a bit about "libraries"?
[10:47] <kassetra> John - in the list of items you have backported.
[10:47] <kassetra> We're actually talking about qa.
[10:47] <mako> Mez: we're talking about issues and concerns that people have with backports
[10:47] <mdz> ogra: 10 of those are from wine
[10:47] <Amaranth> Mez: Probably another hour.
[10:47] <mako> Mez: right, and qa in particularly
[10:47] <mako> Amaranth: i think so
[10:47] <ogra> kassetra, libpam-smbpass, libstdc++6, libsmbclient, libmyth etc
[10:47] <Mez> ok
[10:47] <mdz> ogra: that also counts runtime and devel as 2
[10:47] <Mez> well I'm going to have to go ;) sorry
[10:47] <JohnDong> most of them are from wine or gcc4 or mythtv
[10:47] <mako> Mez: alright
[10:48] <Mez> and if someone can send me alog to mezzle@gmail.com it'd be appreciated
[10:48] <mako> Mez: it will be published online
[10:48] <Mez> ah, kk
[10:48] <Mez> thx
[10:48] <linuxboy> where?
[10:48] <Amaranth> JohnDong: I'm still not sure why gcc4 was backported.
[10:48] <mdz> JohnDong: what do you do about packages which depend on the libraries for which you are providing updated versions?
[10:48] <kassetra> ogra: we're not talking about libgtk2 or so.
[10:48] <mdz> JohnDong: do you rebuild them, or do people simply use the versions in hoary?
[10:48] <ogra> kassetra, nope...
[10:49] <JohnDong> mdz: there is usually no ABI change
[10:49] <JohnDong> like Samba...
[10:49] <JohnDong> Fedora bumps up samba like crazy
[10:49] <JohnDong> they started with 3.0.0 and made it up to at least 3.0.12
[10:49] <mdz> JohnDong: well, there certainly is with mythtv, eg
[10:49] <JohnDong> and they don't "rebuild"
[10:49] <mdz> with every release
[10:49] <JohnDong> mythtv in Hoary is pretty broken up
[10:49] <\sh> JohnDong: fedora is something else...do u know how redhat is working in the moment?
[10:49] <JohnDong> \sh: It doesn't matter; their update model works
[10:49] <\sh> JohnDong: yes, for them
[10:49] <mdz> JohnDong: what is their model?
[10:50] <titus`> linuxboy, http://people.ubuntu.com/~fabbione/irclogs/
[10:50] <JohnDong> mdz: provide rolling updates for some packages and stable version backports for others
[10:50] <JohnDong> mdz: i.e. rolling Firefox, fixed Apache
[10:50] <mdz> JohnDong: rolling updates meaning what?
[10:50] <\sh> JohnDong: but u won't see HP taking fedora as laptop distri...they would use RedHat enterprise or advanced...so redhat is picking the diamonds out of fedora
[10:50] <Amaranth> basically what the backports do
[10:50] <JohnDong> Gentoo-style introduce new versions
[10:50] <\sh> and not the pees
[10:50] <JohnDong> \sh: Am I asking for HP to include Backports?
[10:51] <JohnDong> that's not the point
[10:51] <mdz> JohnDong: meaning they track the same versions which are in their development tree?
[10:51] <JohnDong> all I'm saying is that backports works
[10:51] <mdz> JohnDong: or something else?
[10:51] <JohnDong> mdz: yes
[10:51] <mako> \sh: we've established that there is demand and that it's filling a need
[10:51] <JohnDong> they take rawhide builds and rebuild them for stable
[10:51] <mdz> JohnDong: so if firefox breaks in rawhide, it's broken for backports users too?
[10:51] <\sh> JohnDong: it is the point..this distribution is actively support not only by the community...and fedora is only supported by the community..redhat wont give u any chance to ask for fedora support
[10:51] <JohnDong> mdz: not really....
[10:51] <mdz> JohnDong: I assume the backports are opt-in, then?
[10:52] <JohnDong> \sh: correct
[10:52] <JohnDong> err
[10:52] <JohnDong> mdz: correct
[10:52] <JohnDong> sh: I'm not asking for Canonical to support backports
[10:52] <JohnDong> mdz: Backports is perfectly optional. I don't force anyone to use it :)
[10:52] <Amaranth> JohnDong: Your users are though.
[10:52] <mako> JohnDong: you don't have to.. we've already established that it happens
[10:52] <JohnDong> Amaranth, what can I do about that?
[10:52] <Amaranth> JohnDong: I think he meant fedora's backports.
[10:52] <kassetra> Amaranth: only when they don't listen to us first.
[10:52] <\sh> JohnDong: but the users are asking not the backports support channels..they want to have also support on the official lists or channels 
[10:52] <mako> JohnDong: that's why we're talking about it now
[10:53] <mdz> look, we're not here to criticize backports.  I don't think that JohnDong is doing anything wrong, on the contrary, backports clearly provide a valuable service to the community
[10:53] <JohnDong> thanks.
[10:53] <mdz> and we're here to discuss how we can work more closely, not whether it's a good idea
[10:53] <Amaranth> yes, please don't look at it that way
[10:53] <mako> mdz: Yes
[10:53] <JohnDong> I agree that this support ordeal needs to be resolved
[10:53] <ogra> JohnDong, but we (MOTU) would appreciate to know whats going on in your universe and even would like to help out, you must admit that the communication was not as good as it could have been in the past
[10:53] <mako> alright
[10:53] <mako> maybe it's time to move forward
[10:53] <mako> can folks look at teh agenda and say if there are any other problems
[10:53] <JohnDong> ogra: I appreciate that :)
[10:54] <mako> with backports, that should be brought up here now?
[10:54] <kassetra> ogra: we've been developing technologies in the forums to help out with the communication aspects between the developers and the backports.
[10:54] <mako> things any solution or set of solutions should take in consideration
[10:54] <mako> that (a) is not on that list or (b) has not been brought up today?
[10:54] <\sh> hmmm
[10:54] <JohnDong> ok, developer<->backports communications
[10:54] <kassetra> mako: did you want to discuss communications?
[10:54] <JohnDong> should I use the mailing list for that?
[10:54] <\sh> backports as subpart of MOTU?
[10:54] <mako> if we've covered this ground and everyone is confident that we know the problem, we can start plowing into solutions
[10:55] <mako> \sh: that's a solution :)
[10:55] <JohnDong> I've learned saying the B-word isn't a good idea on ubuntu-devel
[10:55] <mdz> \sh: patience, we'll talk about solutions next ;-)
[10:55] <JohnDong> \sh: I don't want backports to really be a part of MOTU....
[10:55] <mako> JohnDong: in what sense?
[10:55] <JohnDong> MOTU is forced upon Ubuntu users
[10:55] <JohnDong> I don't want backports to be that way
[10:55] <mdz> JohnDong: there's a certain amount of resentment which has built up as a result of a lack of communications
[10:55] <mdz> backports is something which has grown up outside Ubuntu, and many developers (including me, until today) didn't know enough about it
[10:55] <mako> JohnDong: lets stick to remaining issues/problems before we evaluate taht and other solutions
[10:55] <JohnDong> mdz: I understand that. But communications isn't grouping Backports with MOTU...
[10:56] <kassetra> mdz: we've opened a special forum area where devs can talk with us directly to stop the communications mishaps.
[10:56] <mdz> JohnDong: I was responding to your "B-word on ubuntu-devel" statement
[10:56] <kassetra> mdz: also, we're looking into tying the channels in irc into the forums as well.
[10:56] <JohnDong> mdz: yeah, I've seen some of the misconceptions
[10:56] <Amaranth> you have irc channels?
[10:56] <\sh> JohnDong: u r not forced by your users? in a special way?
[10:56] <ogra> JohnDong, i must iadmit, i'm one of the people pushing that attitude, but i'm willing to change that if i see QA, upgradeability etc as MOTU has
[10:56] <mako> \sh: hold off
[10:56] <JohnDong> \sh: huh?
[10:56] <mako> JohnDong: you too 
[10:57] <mako> we'll get to that
[10:57] <mdz> JohnDong: well, consider that the first contact most of us have with backports is that we receive a bug report for a problem we can't reproduce, spend some time diagnosing, and discover that the user isn't using our packages at all
[10:57] <JohnDong> mdz: yeah :)
[10:57] <mdz> JohnDong: at which point everyone loses, since we don't know where to send them for support, nor how the backports community works
[10:57] <mdz> and they get a RESOLVED/INVALID
[10:57] <JohnDong> ok, I understand that
[10:58] <mdz> I think we've made good progress in the right direction at this meeting
[10:58] <JohnDong> I agree
[10:58] <ogra> yep
[10:58] <mdz> but of course only a subset of the developer community is represented here
[10:58] <dholbach> JohnDong: MOTUs and Backport guys are both working voluntarily and both should need to meet some review criteria before uploading stuff anywhere, maybe that's why they both were mentioned in one breath. maybe we can think of processes how to make people more confident in what happens?
[10:58] <mako> now that we know each other and how our communities, work, we've probably gone some of the way to making that situation slightly better
[10:58] <Amaranth> is there anything backports can modify that can be used to easily tell if a user is using them? firefox UA perhaps?
[10:58] <Amaranth> shit, that's a solution, never mind
[10:58] <mako> mdz: we'll MAKE the others read the summary :)
[10:58] <mdz> mako: well, we'll discuss what to do about it in the bit about solutions ;-)
[10:58] <mdz> mako: BUSTED
[10:58] <JohnDong> Amaranth: You can't mistake a backport for a regular package
[10:59] <JohnDong> Amaranth: They all contain ~*ubp*
[10:59] <Burgundavia> JohnDong, but the user doesn't see that when they run the icon on the desktop
[10:59] <JohnDong> Burgundavia: You want me to rebrand every package? lol
[10:59] <ogra> JohnDong, the user who apt-getted doesnt know that, the bugreport goes to malone anyway
[10:59] <mdz> speaking of which, are we ready to move on?
[10:59] <JohnDong> let's move on
[10:59] <mako> ogra: bugs going to the wrong places!@
[10:59] <kassetra> Burgundavia - no but there is the possibility of adding a backports icon to specific packages, in say, synaptic.
[10:59] <mako> kassetra: that's a new problem
[11:00] <mdz> kassetra: we had discussed it earlier already
[11:00] <Burgundavia> kassetra, that would need expanded synaptic
[11:00] <mdz> er
[11:00] <mdz> s/kassetra/mko/
[11:00] <mdz> s/mko/mako/
[11:00] <JohnDong> kass: it doesn't have a Ubuntu logo beside it....
[11:00] <mako> alright.. 
[11:00] <kassetra> John: no, I know.
[11:00] <mako> kassetra: did you want to say something else about communication problems?
[11:00] <Amaranth> Burgundavia: Doable for breezy, not a solution for hoary though.
[11:00] <ogra> JohnDong, all universe packages have no ubuntu logo
[11:00] <mako> did someone else?
[11:00] <ogra> JohnDong, you talk about 16000
[11:00] <JohnDong> ogra: well, maybe that should change
[11:00] <kassetra> mako: well, we've been working on ways of solving those issues, actually.
[11:00] <doko> mako: require a version field to be filled and in case o a backports version, redirect the bug report
[11:01] <mdz> mako: I do, but it's all solution-oriented ;-)
[11:01] <mako> alright
[11:01] <mako> FINE SOLUTION TIME
[11:01] <JohnDong> lol
[11:01] <kassetra> LOL
[11:01] <JohnDong> :)
[11:01] <mako> ok
[11:01] <mdz> what shall we solve first?
[11:01] <JohnDong> bugzilla
[11:01] <mako> lets look at the proposals on the wik
[11:01] <JohnDong> since everyone's in my face about that right now :)
[11:01] <ogra> oh, one thing i'm very concerned about
[11:01] <mako> want to talk about bugs, sure.. why not
[11:01] <mako> ogra: quickly, quickly
[11:02] <pitti> imho it shouldn't really be bz, maybe malone? it already supports different releaese
[11:02] <pitti> releases, even
[11:02] <Amaranth> yeah, malone
[11:02] <JohnDong> pitti: same difference...
[11:02] <mdz> pitti: yes, malone should be the target
[11:02] <JohnDong> lol :D
[11:02] <ogra> MOTU would love to see the manpower thats loszt in backports, there is no chance to convince you guys to become MOTUs ? JohnDong ?
[11:02] <mako> JohnDong: so sabdfl has already suggested throwing you guys to malone
[11:02] <JohnDong> mako: eventually, there's gonna be other 3rd party confusion in the bugs database
[11:02] <pitti> JohnDong: which differences?
[11:02] <mako> JohnDong: malone is ALL ABOUT third party confusion
[11:02] <JohnDong> pitti:nvm :)
[11:03] <kassetra> ogra: manpower isn't lost to backports, ok?  That's what people want.
[11:03] <Amaranth> easy now
[11:03] <ogra> kassetra, for me as MOTU it is
[11:03] <JohnDong> ogra: I don't like the term "lost"... MOTU isn't backports
[11:03] <philipacamaniac> malone seems to have bugs of its own that need to be ironed out
[11:03] <ogra> kassetra, we are 20 ppl caring for 16000 packages ;)
[11:03] <kassetra> ogra: if the goal is to provide users with packages, no, it's not.
[11:03] <Amaranth> We all serve a role is making Ubuntu better for the user here.
[11:03] <JohnDong> ogra: the goals are different enough that it'd cause more conflict
[11:03] <dholbach> philipacamaniac: they will be, this is not part of this meeting :)
[11:03] <Amaranth> How we do it isn't as important as doing it.
[11:03] <ogra> JohnDong, its lost for the MOTU ;)
[11:03] <ajmitch> MOTUs want all the recruits we can get :)
[11:04] <ogra> yeah
[11:04] <JohnDong> ogra: nothing personal... nothing against MOTU... but I don't think we share similar goals :)
[11:04] <mdz> MOTU and backports are orthogonal
[11:04] <kassetra> ogra, ajmitch: then you're going about it the wrong way.
[11:04] <ogra> JohnDong, it was a lame try to recruit you ;)
[11:04] <ajmitch> since the more MOTUs there are, the better the breezy packages will be for you to backport :)
[11:04] <mako> i think it's clear that both are different solutions filling different needs
[11:04] <kassetra> mako: exactly.
[11:04] <mdz> but they should both be closely coordinated with core development
[11:04] <mako> yes
[11:04] <dholbach> yes
[11:04] <mdz> MOTU is a better example than backports right now of how it should work
[11:04] <kassetra> mdz: we see nothing wrong with that.  :)
[11:04] <mako> they are similar in that they both work on universe packages a lot
[11:04] <mako> mdz: yes
[11:04] <\sh> well I would be glad to see, backport devs efford under MOTUs guidance, QA and reviewing practice...so we can improve Ubuntu 
[11:04] <mako> ok.. so
[11:04] <mdz> mako: hoary-backports looks like a pretty even split between main and universe
[11:04] <dholbach> i think we should have *yet another* mailing list with the debdiffs sent to it, so the packages would catch more eyes
[11:05] <mdz> if not biased toward main
[11:05] <mako> mdz: hmm
[11:05] <JohnDong> mdz: more people use stuff in main
[11:05] <Amaranth> If we could get backports more integrated it could take a load of the bp devs that they could possible spend working on MOTU things? :)
[11:05] <JohnDong> there's stuff in universe that I've never heard of...
[11:05] <mako> JohnDong: are you comfortable moving ahead with some sort of plan for switching bug tracking to malone?
[11:05] <JohnDong> mako: sure
[11:05] <ogra> JohnDong, exciting, isnt it ;)
[11:05] <JohnDong> mako: but I want forums integration, too :)
[11:05] <JohnDong> s/want/would like
[11:06] <Amaranth> using malone really only works if we have single sign-on with the forums
[11:06] <JohnDong> Amaranth: Exactly.
[11:06] <mako> JohnDong: well, you may end up using both seperately or with some integration.. we'll see
[11:06] <JohnDong> mako: that's fine. As long as if it's separate, the Ubuntu Backports forum survives :)
[11:06] <mako> sabdfl, mdz: who should he talk to be working with to identify needs and such and to move forward with malone?
[11:06] <mako> JohnDong: absolutely
[11:06] <JohnDong> :)
[11:06] <Amaranth> ideally only malone would be needed
[11:07] <mdz> mako: I think we should set up a meeting between JohnDong, Ryantroy and someone on the launchpad squad
[11:07] <Amaranth> file a wishlist bug for new backports, file bugs for broken backports
[11:07] <Ryantroy> mdz: sounds good
[11:07] <mako> mdz: yes
[11:07] <JohnDong> Amaranth: yeah; but forums currently attract a bigger crowd
[11:07] <mdz> to discuss the forums and launchpad
[11:07] <mdz> common authentication, and perhaps some way to tie in malone
[11:07] <mako> mdz, JohnDong: also, we should talk about how you work your backport packages to make sure the bugs go the right place
[11:07] <Amaranth> btw, the 'launchpad' name just made sense to me for the first time :D
[11:07] <mdz> sabdfl: who would be a good person on the launchpad side to participate in that?
[11:07] <mako> that doesn't need to happen right now
[11:08] <mako> cool.. one solution down :)
[11:08] <JohnDong> mako: yeah
[11:08] <mako> how about:
[11:08] <mako> * Don't do backports for an unreleased version.
[11:08] <mako> is that useful? possible?
[11:09] <JohnDong> mako: "unreleased"... definition?
[11:09] <mdz> JohnDong, ryantroy: could you guys send mail to me (mdz@ubuntu.com) so that I have your contact information?  I'll forward it on
[11:09] <mako> sticking to breezy sources?
[11:09] <Amaranth> I know .desktop packages have info about where bugs go and what help to use for debian things.
[11:09] <Amaranth> Or at least I think they do.
[11:09] <JohnDong> mdz: done
[11:09] <mdz> mako: meaning that backports should be strictly from Ubuntu development releases -> Ubuntu stable releases, right?
[11:09] <dholbach> Amaranth: that's for bug-buddy afaik
[11:09] <JohnDong> mdz: I'm fine with that
[11:09] <kassetra> JohnDong: unreleased = the version that's not released yet, like Breezy right now.
[11:09] <Amaranth> yeah, for bug-buddy
[11:09] <mdz> if so, that seems reasonable to me
[11:09] <mdz> backports are not the right place to introduce new stuff from upstream
[11:10] <mdz> it should go into our development release first
[11:10] <JohnDong> ok, so reworded: only backport stuff from Breezy
[11:10] <mako> JohnDong: right
[11:10] <JohnDong> I know, stuff will get restricted very soon :)
[11:10] <kassetra> except, Breezy won't be breezy next time.
[11:10] <JohnDong> kass, we get it.
[11:10] <JohnDong> :)
[11:10] <kassetra> :)
[11:10] <mako> also, not introducing new libraries sounds likew it could be huge
[11:10] <Ryantroy> mdz: done
[11:10] <mako> which is something you are trying to do already
[11:10] <JohnDong> mako: yeah, we've stopped doing that altogether
[11:10] <mako> but there are situations when you do introduce new libraries because of deps that could be worked around
[11:10] <JohnDong> mako: it was done a bit back in Warty, but I've learned
[11:11] <JohnDong> mako: If deps aren't too nasty (like new firefox libs) that's fine
[11:11] <JohnDong> mako: just no gtk backports :)
[11:11] <JohnDong> lol
[11:11] <mako> JohnDong: in the future, it may be nicer if you work with the rest of the team in #ubuntu-devel and we can figure out to do it the Right Way
[11:11] <mako> JohnDong: doko knows a few things about gcc, for example
[11:11] <mdz> mako: along those lines, I'd like to step back a bit and propose a high-level solution idea
[11:11] <JohnDong> mako: sure... it's just that #ubuntu-* hasn't been too welcoming in the past. I'll try again :)
[11:11] <mdz> I would like for backports to become an official Ubuntu project
[11:11] <ogra> mako, a fwe, lol
[11:11] <ogra> few
[11:12] <mako> mdz: !!!!
[11:12] <JohnDong> mdz: interesting... I'd still like it to be "optional"... maybe a "recognized" project?
[11:12] <ogra> JohnDong, try in -motu
[11:12] <mako> JohnDong: what do you say?
[11:12] <Amaranth> mdz: having ubuntu host it would resolve a few issues all at once
[11:12] <mako> JohnDong: oh yes.. optional yes
[11:12] <JohnDong> that'd be nice
[11:12] <JohnDong> we need to work out details on that, though
[11:12] <mako> JohnDong: official doesn't mean required
[11:12] <mako> JohnDong: i don't use kubuntu
[11:12] <mdz> JohnDong: what this would mean would be sharing our infrastructure and working closely with the development team
[11:12] <mako> JohnDong: hell, i don't even have gnome installed :)
[11:12] <JohnDong> mako: yeah, but kubuntu repository changes get propagated to everyone
[11:12] <mdz> right, this wouldn't imply any requirement on the part of the users
[11:13] <\sh> mdz: official optional ubuntu project == u can do this and that, but bound to ubuntu community rules?
[11:13] <kassetra> mdz: would users still get to request items to be backported?
[11:13] <mdz> kassetra: of course
[11:13] <mako> kassetra: sure
[11:13] <JohnDong> :)
[11:13] <Amaranth> and we could work to get you guys into MOTU :)
[11:13] <mdz> if the current approach is working well, then the right idea would be to try to maintain that workflow
[11:13] <Mez> I just popped back and saw this
[11:13] <Mez> all i can say is wewt
[11:13] <mdz> but do it on top of Ubuntu proper, rather than working in a separate sandbox
[11:13] <JohnDong> so does that mean I can get access to some build machines?
[11:13] <JohnDong> primarily amd64
[11:13] <mdz> JohnDong: it means that we would provide automatic build services
[11:13] <mako> JohnDong: so..
[11:14] <ogra> JohnDong, yes
[11:14] <mdz> the same way that breezy works
[11:14] <Mithrandir> JohnDong: if you have a key signed by a DD or a MOTU then I can provide access for you.
[11:14] <JohnDong> mdz, mako: I'll need some documentation about Ubuntu's build system
[11:14] <mako> from an organizational perspective, it will means that you guys become the ubuntu backports team
[11:14] <ogra> JohnDong, on the buildds
[11:14] <mako> and keep working on your own
[11:14] <\sh> mdz: but this means, that u allow updates different from secfixes ;)
[11:14] <ogra> JohnDong, join the MOTU ;)
[11:14] <JohnDong> ogra: stop :)
[11:14] <mdz> \sh: this is orthogonal to hoary-updates and hoary-security
[11:14] <Seveas> JohnDong is MOTB, not MOTU :)
[11:14] <ogra> JohnDong, we can tell you everything about the build system
[11:15] <mako> if there are problems or issues within your team or between your team and others, it will ultimately be up to the tech board and the community council to sort it out
[11:15] <\sh> mdz: this is what i meant in the beginning :)
[11:15] <JohnDong> ogra: thanks
[11:15] <JohnDong> mako: sounds great!!
[11:15] <mdz> JohnDong: we can go into the implementation later, but the general idea is that we want to provide support for what you are doing, and provide for closer collaboration with the development team
[11:15] <kassetra> mdz: yes, we really like the idea.  :)
[11:15] <mako> JohnDong: so you'll be giving up a little bit of control, potentially, in that sense
[11:15] <JohnDong> mako: I'm fine with compromising
[11:15] <ogra> JohnDong, wecould have a MOTUBackports team
[11:15] <mako> JohnDong: but you should be working the way you did almost all of the time
[11:15] <Amaranth> that would bring us back to 'no backports form main' then
[11:15] <JohnDong> ogra just doesn't give up :)
[11:15] <mako> ogra: sssh :)
[11:16] <Nafallo> hoary,hoary-updates,hoary-security,hoary-backports ;-)
[11:16] <JohnDong> Amaranth: I was just about to bring that up
[11:16] <JohnDong> lol
[11:16] <ogra> JohnDong, never ;)
[11:16] <mdz> Nafallo: right, that's the sort of idea we mean
[11:16] <ogra> JohnDong, i'm known for agressive recruiting ;)
[11:16] <mako> Nafallo: yes
[11:16] <JohnDong> mdz, mako: would "restricted" ever get as far as a ban on backporting stuff in main?
[11:16] <ajmitch> ogra: very aggressive :)
[11:16] <ogra> hehe
[11:16] <JohnDong> primarily, xchat, firefox, gaim....
[11:16] <mako> JohnDong: i don't think so
[11:16] <JohnDong> mako: excellent :)
[11:16] <mdz> JohnDong: I don't see any reason to have restrictions by section
[11:17] <mdz> JohnDong: but I think we should formalize what you are already doing
[11:17] <JohnDong> I'm all for working with devs
[11:17] <kassetra> mako, mdz: that sounds like a winning plan then.  :)
[11:17] <JohnDong> this sounds great :)
[11:17] <mako> well that's great
[11:17] <mdz> JohnDong: you and the community have sorted out which packages it makes sense to backport
[11:17] <mako> there are a few other things to maybe try to sort first
[11:17] <mako> i know we've been here a long time
[11:17] <Amaranth> JohnDong: that reminds me, if i redo my gnome-menus backport, would it have a chance of being accepted? :)
[11:17] <mako> siretart: go ahead
[11:17] <siretart> I like backports the way http://backports.org provide
[11:17] <JohnDong> Amaranth: I think the tech board needs to be involved in this one
[11:18] <siretart> is this aproach possible for ubuntu backports, too?
[11:18] <Nafallo> mdz, mako: and does that share the mirrornetwork as well?
[11:18] <mdz> Nafallo: the mirrors are volunteers, it would be their decision
[11:18] <JohnDong> siretart: if I figure out how pools work
[11:18] <mdz> Nafallo: but I hope so, yes
[11:18] <Nafallo> mdz: k
[11:18] <JohnDong> siretart: I'm sure you guys know :)
[11:18] <JohnDong> lol
[11:18] <siretart> the advatage for users: they can decide with the apt line, which backported packages they want
[11:18] <mdz> siretart: yes, this is something I wanted to discuss as well
[11:19] <mdz> the granularity of backports
[11:19] <JohnDong> siretart: as long as there's an "all backports" option, too.
[11:19] <mdz> users generally either use the backports repository, or they don't, right?
[11:19] <mdz> or do users pick and choose packages they want to upgrade?
[11:19] <kassetra> mdz: pick & choose.
[11:19] <JohnDong> mdz: they either use or don't use.
[11:19] <JohnDong> mdz: apt-pinning is popular
[11:19] <Amaranth> heh, two different answers
[11:19] <JohnDong> I see more of all-or-nothing
[11:19] <Mez> probably two differnt interpretations of thwe question
[11:19] <JohnDong> some people do hand-pick backports
[11:20] <kassetra> Yeah, I do.
[11:20] <mdz> does apt-pinning work well in your environment?
[11:20] <JohnDong> mdz: I've gotten excellent reports about it
[11:20] <mdz> it tends to fall apart between major Debian releases, e.g.
[11:20] <kassetra> mdz: yes.  :)
[11:20] <mdz> where there are many complex dependency changes
[11:20] <JohnDong> mdz: but I don't like the system. it's more of a workaround
[11:20] <mdz> but with backports, it seems like it could work
[11:20] <JohnDong> mdz: I like the Backports.org method
[11:20] <mdz> what do they do?  one section per source package?
[11:20] <JohnDong> mdz: are you familiar with the backports.org structure?
[11:20] <mako> mdz: couldn't we just generate a load of Packages files?
[11:21] <mdz> mako: in the future, perhaps, but not initially
[11:21] <siretart> from what I read, nobse also plans an upload queue for DD's for backports.org. that would be awesome for us too :)
[11:21] <JohnDong> mdz: virtual "sections" with single packages, plus the whole "backports " section
[11:21] <JohnDong> mdz: just a bit of scripting magic
[11:21] <mdz> JohnDong: as above, I think that's something we should look into down the road, but shouldn't be part of our initial roadmap for getting backports integrated with our infrastructure
[11:21] <siretart> nobse == maintainer of backports.org (for those who did not know)
[11:21] <mdz> it's much more complex to administer
[11:22] <JohnDong> mdz: I agree. I see it for the future
[11:22] <mako> excellent
[11:22] <mdz> given the limitations that we've agreed on, I think this should be pretty simple
[11:22] <Mez> It doesnt look that hard to do
[11:22] <mdz> if I can sketch a few implementation details for a moment, to make sure we're all on the same page
[11:22] <Mez> as John said - it's a bit of scripting magic
[11:22] <mdz> we would create a backports repository, directly adjacent to hoary (e.g., hoary-backports)
[11:22] <mako> mdz: go ahead
[11:23] <ogra> which is already there)
[11:23] <mdz> the backports team would decide when to backport a particular version, and would request it from the archive administrators
[11:23] <mdz> this would cause the source package to be copied over, and rebuilt against hoary
[11:23] <mdz> then the binaries would be published in hoary-backports
[11:23] <Amaranth> so backport+patch would be totally out?
[11:23] <siretart> this sounds reasonable
[11:23] <mako> Amaranth: i'm sure he's going there
[11:23] <Mez> mdz: wouldnt that mean barely any work exeptdeciding what to backport for the backport developers?
[11:24] <mdz> Mez: it would mean that the backports team could get out of the business of building packages and maintaining an archive (which is really not much fun anyway)
[11:24] <\sh> Mez:  this is a pro point of a working infrastructure and team
[11:24] <JohnDong> Mez: I have autobuild scripts; the more work on quality, the better
[11:24] <mdz> and concentrate on providing the best quality service
[11:24] <JohnDong> mdz: absolutely
[11:24] <mako> mdz: and in situations that that build fails, what is the process?
[11:24] <mdz> which I think is a win both for the users and the backports team
[11:24] <mdz> mako: then it should be fixed in breezy
[11:24] <Mez> I wasnt questioning it... I was more, that makes life easier for them :D
[11:24] <\sh> mako: as i understand they could use our infrastructure
[11:25] <mdz> I think wherever possible, we should provide for backports by making breezy packages continue to build on hoary
[11:25] <JohnDong> mdz: we'll need to go into the failure part again
[11:25] <mdz> usually this is not difficult to do
[11:25] <Amaranth> mdz: some dependencies need to be changed
[11:25] <ogra> JohnDong, are your packages signed btw ?
[11:25] <Amaranth> mdz: and what about backport+patch?
[11:25] <JohnDong> ogra: no :(
[11:25] <mdz> usually or-ed dependencies can be used
[11:25] <mako> mdz: even if the fix doesn't affect the packages ability to be built against breezy?
[11:25] <mdz> Amaranth: can you provide an example?
[11:25] <JohnDong> ogra: I was just workin on that yesterday
[11:25] <mdz> what's a situation where you need to patch?
[11:25] <mako> mdz: right
[11:25] <Mez> ogra - no - but they will be
[11:25] <ogra> JohnDong, great :)
[11:25] <JohnDong> mako: package renames
[11:25] <ogra> Mez, ^^
[11:25] <Amaranth> mdz: to make gnome-menus work with smeg i need to apply a small patch (~60 lines, i think) to it
[11:25] <Mez> I'm too slow ogra ;)
[11:25] <mdz> if the patch is necessary in order to build on hoary, it should be patched into breezy in a generic way wherever possible
[11:25] <ogra> heh
[11:26] <mdz> Amaranth: is that patch unsuitable for breezy for some reason?
[11:26] <Amaranth> mdz: gnome-menus 2.11 is fixed
[11:26] <JohnDong> mdz: it requires a gnome-menu backport :)
[11:26] <JohnDong> mdz: I'm sure the tech board won't like that
[11:26] <mdz> then where's the problem?
[11:26] <Amaranth> mdz: not wanting to backport GNOME just for smeg?
[11:27] <JohnDong> mdz: backporting a core component of GNOME probably won't be accepted warmly by you guys
[11:27] <mdz> well, our archive infrastructure certainly allows for a new version to be uploaded to backports directly
[11:27] <mdz> I think we would want to establish some pretty clear criteria for when we should do that, and when not
[11:27] <JohnDong> mdz: back to the transition, what becomes of -staging? A testing area is still necessary
[11:27] <JohnDong> mdz: would -staging go into my people.ubuntu.com repo?
[11:28] <mdz> JohnDong: we could do it that way, but it probably makes more sense to have it exist within the archive infrastructure also
[11:28] <mdz> I assume that you test in staging, and then move exactly the same binaries over when you're satisfied?
[11:28] <mdz> this is a facility that we would like to have anyway, in order to test security updates before rolling them out
[11:28] <JohnDong> mdz: ok, awesome
[11:28] <Nafallo> mdz++
[11:28] <siretart> .oO( setting up britney from dak for backports? ohoh... )
[11:28] <mdz> but let me say, that we don't have it yet :-)
[11:28] <ogra> mdz, wouldnt be necessary the MOTU way, but i'll shut up about MOTU now
[11:28] <JohnDong> mdz: I just move binaries, too :)
[11:28] <Amaranth> doesn't elmo need to approve some of this stuff?
[11:28] <mdz> ogra: how do you mean?
[11:29] <ogra> mdz, three reviews
[11:29] <Kamion> ogra: reviews aren't perfect
[11:29] <mdz> Amaranth: elmo has been consulted
[11:29] <JohnDong> **puts ogra on a list with Gentoo mods....
[11:29] <mako> mdz: what's the timeline for that functionality?
[11:29] <ogra> Kamion, but better then nothing
[11:29] <Kamion> ogra: I've reviewed a lot of stuff, and I know I miss stuff too often even so. Testing is better than reviews.
[11:29] <Amaranth> ogra: but not better than -staging
[11:29] <ogra> JohnDong, dont do that ;)
[11:29] <mdz> mako: the outline that I've described, getting hoary-backports set up, should be less than a week's work
[11:29] <mdz> staging is a bigger project that I haven't really thought enough about yet
[11:30] <mako> mdz: including building the functionality to do the staging area?
[11:30] <mako> JohnDong: are you happy doing a hack for the staging stuff in the meantime?
[11:30] <mdz> mako: that requires some consultation with people who are not here
[11:30] <JohnDong> mako: sure :)
[11:30] <JohnDong> Does this mean Breezy will ship with hoary-backports lines commented out, just like how universe is shipped?
[11:30] <mako> alright.. seems reasonable
[11:30] <mdz> but I think it is the right idea for us to integrate the staging functionality as well, because it is useful beyond just backports
[11:30] <\sh> johndong: staging implies only install issues with the packages or also functionality issues of the backported software?
[11:30] <JohnDong> That way, Synaptic will have a checkbox
[11:31] <mdz> JohnDong: that sounds reasonable
[11:31] <JohnDong> sh: it can be either
[11:31] <mako> JohnDong: sure, seems possible
[11:31] <JohnDong> YAY
[11:31] <Amaranth> \sh: functionality
[11:31] <LarstiQ> does hoary-backports make sense for breezy?
[11:31] <JohnDong> it can be either... sometimes renames cause packaging issues
[11:31] <mdz> in fact we might decide that hoary-updates should be identical to backports, though that's less clear
[11:31] <Amaranth> LarstiQ: obviously it'd be breezy
[11:31] <mako> LarstiQ: no
[11:31] <mdz> it would certainly need to change from opt-out to opt-in
[11:31] <LarstiQ> right, just checking
[11:32] <mako> LarstiQ: i mean, we're talking about packages that are already in breezy :)
[11:32] <mdz> but I don't think we need quite all of -security, -updates, -backports and -backports-staging
[11:32] <JohnDong> mdz: awesome :)
[11:32] <mdz> there is a lot of overlap there
[11:32] <LarstiQ> mako: I could see a use, but yes :)
[11:32] <mdz> and it would be a lot to maintain
[11:32] <JohnDong> mdz: correct. -updates is barely used at all...
[11:32] <JohnDong> mdz: maybe like the Fedora and Extras model?
[11:32] <Kamion> does seem kind of overkill for a default install
[11:32] <mdz> JohnDong: I'm not very familiar with that
[11:32] <Kamion> JohnDong: when -updates is needed, it's needed, though
[11:32] <mdz> Kamion: especially given that timeout bug ;-)
[11:32] <JohnDong> mdz: Fedora maintains a core updates repo, and Extras is like a Backports
[11:32] <Kamion> mdz: yeah ...
[11:33] <JohnDong> so it's like having all 4 repos there.... :(
[11:33] <mdz> Kamion: could you file that in bugzilla for mvo if you haven't already?
[11:33] <JohnDong> mdz: I don't think there's "overlap", but just bad naming
[11:33] <mdz> JohnDong: well, I think we should do some thinking about how many different use cases there really are
[11:33] <JohnDong> mdz: 'hoary-updates' can be renamed to mean more of major bugfixes
[11:33] <Kamion> mdz: he's cced on the relevant bug, and I've included an explanation
[11:33] <mdz> how many people really want security but NOT critical bugfixes, for example
[11:33] <Kamion> mdz: (I'm going to work around it, so it's still assigned to me)
[11:33] <mdz> Kamion: ok, my bugzilla-fu is way behind these days
[11:33] <elmo> mdz: me :P
[11:34] <JohnDong> mdz: I don't know, lol :). hoary-updates isn't even that well publicized
[11:34] <Kamion> I think people want to be able to distinguish between security and critical bugfixes, rather than having them all jammed together
[11:34] <mako> alright.. lets move on :)
[11:34] <mdz> elmo: oh, hello ;-)
[11:34] <Kamion> because the criteria for the latter is a lot less well-defined
[11:34] <ogra> mdz, so how do we sort the missing gpg key issues, the backports guys need a valid gpg key or not ?
[11:34] <mdz> elmo: how do you feel about having 5 suites for each release, though?
[11:34] <JohnDong> mdz: won't Ubuntu provide a signing key? like how hoary-* is handled
[11:34] <ogra> JohnDong, you need to sign the source
[11:35] <mako> JohnDong: you will need a key to upload
[11:35] <JohnDong> ogra: aha, I see
[11:35] <mdz> elmo: do you have any initial ideas about the best way to implement some sort of staging facility?
[11:35] <ogra> JohnDong, with your own key
[11:35] <elmo> mdz: it's kind of unfortunate in that, per-suite mirroring is annoying (i.e. can't be done with just rsync)
[11:35] <mdz> JohnDong: yes
[11:35] <JohnDong> mako: I'll work on trying to keep a gpg key :)
[11:35] <elmo> would it be 14Gb for us too?  if so, that's not an insubstantial hit
[11:35] <ogra> Amaranth, thats why i brought it up
[11:35] <mdz> elmo: we're expecting these suites to be quite small
[11:35] <mako> JohnDong: create one, sign with someone in the strongly connected set, it should be no problem
[11:35] <JohnDong> elmo: no!
[11:35] <mdz> hoary-backports/i386 is ~250M currently
[11:35] <JohnDong> elmo: the actual binaries are small
[11:35] <elmo> (where did the 14Gb figure come from?)
[11:35] <mdz> elmo: of course, we'd need to copy the source as well
[11:36] <Amaranth> JohnDong: where do you live?
[11:36] <JohnDong> elmo: Subversion metadata
[11:36] <JohnDong> Amaranth: Michigan
[11:36] <Amaranth> city?
[11:36] <mako> subversion!
[11:36] <mdz> elmo: and also that figure includes warty backports
[11:36] <elmo> JohnDong: bong
[11:36] <Kamion> Amaranth: even an unsigned key is better than no key at all, although it's still not good
[11:36] <JohnDong> mako: we're currently using subversion
[11:36] <mako> JohnDong: ok
[11:36] <Amaranth> if an unsigned key works for the backports i can work on them :D
[11:36] <Kamion> Amaranth: at least you can tell that this set of uploads are all by the same person
[11:36] <elmo> mdz: if it's small, then I don't have any real/valid objections
[11:36] <elmo> from an archive/mirror POV
[11:36] <mako> if you don't have a signed key, talk to me about getting it signed
[11:37] <elmo> mako: will-sign-keys-for-food?
[11:37] <Kamion> I'm not sure if we'll be accepting unsigned keys, though; TBH I hope not, I want signed-key verification of anything an unsigned key does ...
[11:37] <mako> after the meeting
[11:37] <mako> i don't think we will either
[11:37] <mdz> getting your key signed is not that hard
[11:37] <mako> which is why you should talk to me abou getting it signed
[11:37] <JohnDong> mako: talk about keys via e-mail?
[11:37] <mdz> and it's a good excuse to meet people
[11:37] <Amaranth> mdz: sure it is
[11:37] <mako> JohnDong: yes
[11:37] <ogra> hehe
[11:37] <mako> so..
[11:37] <mdz> Amaranth: we already have a facility in place for people who can't arrange a face-to-face meeting
[11:37] <JohnDong> mdz: I'm a junior in high school... not too much travel goes by me :)
[11:37] <mako> since we've passed teh two hour mark
[11:38] <mako> lets try to wrap this up
[11:38] <mako> mdz: do you have more impelementation details you want to go over?
[11:38] <Amaranth> mdz: i have no one who can sign me within 100 miles and i have no transportation
[11:38] <mako> Amaranth: then talk to me after the meeting
[11:38] <Amaranth> mako: ok
[11:38] <mako> please, lets no talk about keys right now
[11:38] <JohnDong> lol
[11:38] <ogra> mako travels for keys ;)
[11:38] <JohnDong> who's gonna update the wiki page with our progress?
[11:38] <mdz> mako: no, I think that's too much already
[11:38] <mako> JohnDong: kassetra 
[11:39] <mako> ok then
[11:39] <JohnDong> ok
[11:39] <mako> ANY OTHER SUGGESTIONS
[11:39] <JohnDong> key signing?
[11:39] <mako> proposals, things of that sort
[11:39] <JohnDong> j/k :)
[11:39] <ogra> heh
[11:39] <JohnDong> lol
[11:39] <\sh> ok...we will make backports official
[11:39] <Ryantroy> All I have to leave..  this meeting looks to be going well.. thanks all..
[11:39] <mako> Ryantroy: cool thanks for showing up
[11:39] <mako> JohnDong: you know what is going to be problematic
[11:39] <mako> JohnDong: in terms of libs, etc
[11:39] <ogra> Ryantroy, all of them go well ;)
[11:39] <Ryantroy> mako: always! I wish i had more time in the day :) 
[11:39] <ogra> Ryantroy, at least in ubuntu ;)
[11:40] <mako> JohnDong: i think if you run those things by people in #u-devel to ask for advice, etc
[11:40] <mako> JohnDong: it might be good
[11:40] <mako> JohnDong: i apologize that it's not been ultra welcoming in the past but you know moe people now
[11:40] <mako> JohnDong: and i suspect it will be better
[11:40] <siretart> will hoary-backports become a new upload target? Who will be allowed to upload there?
[11:40] <JohnDong> mako: thanks. I'll consult you guys much more than before :)
[11:40] <\sh> philipacamaniac: as I understand it, it applies to all packages in ubuntu warty/hoary/etc.
[11:41] <mako> man, that mdz guy was annoying
[11:41] <mdz> JohnDong: it will get a lot easier to work with the deveolper community when this stuff is official, I expect
[11:41] <mako> oh wait.. he's back
[11:41] <mdz> visibility helps a lot
[11:41] <JohnDong> mdz: thanks :)
[11:41] <mdz> taonheutnsao xchat and its keyboard shortcuts
[11:41] <JohnDong> lol
[11:41] <kassetra> *snicker*
[11:41] <philipacamaniac> \sh: but KDE is such a big metapackage - it couldn't possibly be "officially" backported, could it?
[11:41] <ogra> mdz, get rid of dvorak ;)
[11:41] <mdz> ogra: that's unrelated :-P
[11:41] <JohnDong> umm, I don't plan to backport KDE...
[11:41] <\sh> philipacamaniac: riddell took the same sources as in breezy 
[11:42] <mako> ok
[11:42] <JohnDong> that's just as unholy as doing so with GNOME 
[11:42] <JohnDong> lol
[11:42] <ogra> JohnDong, to late
[11:42] <JohnDong> :)
[11:42] <mako> before we end
[11:42] <\sh> JohnDong: no..this is what the people want
[11:42] <ogra> JohnDong, now aou have _all_ backports
[11:42] <mako> JohnDong: want to take a look at the "When to backport, when not to" list 
[11:42] <mako> and short of "don't do backports to main" do you have any other objectsions?
[11:42] <mako> or does that list looks like a good set of rules to on
[11:42] <JohnDong> *looking*
[11:43] <mako> in situations where you think you might be crossing one of those lines or need to, talking to the rest of the team will be helpful
[11:43] <JohnDong> where is this list?
[11:43] <mako> Amaranth: we've established that this was not realistic
[11:43] <JohnDong> am I being blind here?
[11:43] <mako> JohnDong: on the agenda
[11:43] <\sh> mako: talking about "main"...so, there r no official backports for main, or only != libs*
[11:43] <Amaranth> mako: ok, just making sure
[11:43] <\-> but what about pakages that are not in breezy and that the comunity would like to have packaged? wil those eventually be added to breezy first and then be backported?
[11:43] <JohnDong> I see it
[11:43] <\sh> \-: to universe first.
[11:43] <mako> \-: yes
[11:43] <\sh> \-: for those packages we have policies
[11:43] <JohnDong> ok, I'm fine with it
[11:43] <JohnDong> minus the part about main, of course!
[11:43] <ogra> \-, please leave them to MOTU
[11:43] <JohnDong> lol
[11:43] <mako> \-: no reason we can't do that.. if it's not in breezy, it can't be backported
[11:44] <mdz> \-: yes, absolutely
[11:44] <kassetra> other than the main/backport moratorium.
[11:44] <mako> and if shouldn't even be in multiverse, you shouldn't install it :)
[11:44] <ogra> \-, but no objections on backporting them later ;)
[11:44] <mako> ogra: yes
[11:44] <mdz> if people working on backports are interested in adding new stuff as well, they should absolutely join MOTU
[11:44] <JohnDong> yeah
[11:44] <mako> JohnDong: excllent
[11:44] <JohnDong> backports will definitely pull on MOTU work :)
[11:44] <mdz> I'm sure ogra won't argue with that ;-)
[11:44] <JohnDong> lol
[11:44] <mako> ANY OTHER BUSINESS?
[11:44] <ogra> yep :)
[11:44] <JohnDong> we gotta make ogra happy
[11:44] <JohnDong> lol
[11:44] <mako> ....
[11:44] <ogra> yay
[11:44] <dholbach> :)
[11:44] <\-> ogra, i would be all for it, if only universe would not be freezed
[11:45] <mako> have we sufficiently killed this issue?
[11:45] <siretart> sorry if I got something wrong, but will hoary-backports become a new upload target? Who will be allowed to upload there?
[11:45] <Nafallo> dholbach, ogra: congrats ;-)
[11:45] <kassetra> mako: killed, and then grilled it.
[11:45] <ogra> \-, why  you can backport ;)
[11:45] <dholbach> universe freezed?
[11:45] <mako> KILLED GRILLED... GOING ONCE
[11:45] <mdz> siretart: we will have that capability, but we should discuss how and when it should be used
[11:45] <JohnDong> keys....
[11:45] <mako> GOING TWICE
[11:45] <mako> JohnDong: FU
[11:45] <JohnDong> keys....
[11:45] <JohnDong> lol
[11:45] <JohnDong> LOL
[11:45] <Mez> lol
[11:45] <kassetra> LMFAO
[11:45] <mako> this meeting is declared over half an hour ago
[11:45] <mako> :)
[11:45] <mdz> mako: one more thing
[11:45] <ogra> kassetra, F ?
[11:45] <mako> damnit
[11:45] <mako> mdz: 
[11:45] <JohnDong> lol
[11:45] <mdz> seriously
[11:45] <mako> mdz: ok go
[11:46] <mdz> Ubuntu membership
[11:46] <siretart> mdz: in this or an later meeting?
[11:46] <mako> right
[11:46] <mdz> did we already talk about that?
[11:46] <mako> mdz: we solved half of this problem already
[11:46] <kassetra> ogra: my F'ing tushie off.
[11:46] <\sh> no
[11:46] <mako> JohnDong and kassetra are already members so is ryan
[11:46] <ogra> kassetra, *g*
[11:46] <mdz> mako: oh, I didn't realize
[11:46] <JohnDong> :)
[11:46] <Amaranth> they are?
[11:46] <mdz> excellent :-)
[11:46] <mako> last meeting
[11:46] <JohnDong> BTW, that member list on the wiki needs a bit of updating :)
[11:46] <mako> i didn't send the minutes yet :)
[11:46] <mako> so that's partially my fault
[11:46] <kassetra> heh.
[11:46] <Amaranth> that just leaves me then, sitting as potential backporter/motuer for 6 months now
[11:46] <mdz> anyone who is working on backports should obviously become an Ubuntu member
[11:47] <mako> yes, absolutely
[11:47] <mako> and they need to get their keys signed
[11:47] <mdz> that's about all I wanted to say
[11:47] <dholbach> are they on UbuntuMembers yet?
[11:47] <sabdfl> wow
[11:47] <mako> OVER
[11:47] <JohnDong> amd64 arch
[11:47] <JohnDong> oh well, we'll talk later
[11:47] <mako> alright.. thanks for showing up everybody
[11:47] <mdke> hows the meeting going?
[11:47] <kassetra> mako: mine *is* signed!  :)
[11:47] <mdke> omg finished surely not
[11:47] <mdz> mdke: over :-)
[11:47] <mako> i think this went longer and more successfully than i suspected
[11:47] <dholbach> thanks mako
[11:47] <JohnDong> yeah
[11:47] <mdke> cool
[11:47] <dholbach> absolutely
[11:47] <mdz> thanks to everyone who participated
[11:47] <mako> kassetra: thank you SO MUCH for helping write this up
[11:47] <JohnDong> great job conducting the meeting, mako
[11:47] <ogra> JohnDong, you can do amd64 on the buildds ;)
[11:47] <mako> kassetra:  i can help go over this
[11:47] <Kinnison> Will there be a summary posted somewhere?
[11:47] <JohnDong> ogra: yeah, I remembered that :)
[11:48] <mdz> Kinnison: yes
[11:48] <mako> Kinnison: yes.. kassetra will send it -news :)
[11:48] <Nafallo> JohnDong: you should let ogra brief you on the buildingsystem ;-)
[11:48] <Kinnison> I guess I should sub to -news
[11:48] <mako> thanks everybody
[11:48] <Kinnison> or could someone fwd it to me when it happens
[11:48] <ogra> Nafallo, but not tonight anymore ;)
[11:48] <mako> Kinnison: subscribe
[11:48] <mako> :)
[11:48] <mako> ok.. i'm going to the park
[11:48] <Amaranth> hey!
[11:48] <Nafallo> ogra: baah, don't act so lazy ;-)
[11:48] <JohnDong> awesome
[11:48] <mako> but i will talk about keys AFTER the park
[11:48] <Amaranth> mako: what about the key thing?
[11:48] <ajmitch> bye mako :)
[11:48] <JohnDong> we'lll all be in contact :)
[11:48] <Amaranth> ok
[11:48] <Amaranth> ping me
[11:48] <Amaranth> i need to go clean house a bit anyway
[11:48] <ogra> Nafallo, its 23:47 here ....
[11:49] <mako> Amaranth: will do
[11:49] <Nafallo> mako: what keys? ;-)
[11:49] <Nafallo> ogra: we're in the same timezone ;-)
[11:49] <mdke> mako, yeah ping me too on the keys when you are back
[11:49] <JohnDong> is he gone yet?
[11:49] <JohnDong> hmm
[11:49] <ogra> JohnDong, you find me in #ubuntu-devel and #ubuntu-motu, nearly every day
[11:49] <JohnDong> now to talk behind his back...
[11:49] <JohnDong> lol
[11:49] <mdke> JohnDong, ogra is on irc 24 hours a day
[11:49] <JohnDong> ogra: sure; we'll be in contact
[11:49] <mdke> JohnDong, sometimes more
[11:50] <Nafallo> JohnDong: and night ;-) (finding ogra)
[11:50] <ogra> yep, great :)
[11:50] <kassetra> ok, I will be summarizing later tonight, after my regular work day is over.
[11:50] <JohnDong> k
[11:50] <ajmitch> he's always recruiting, so if you ever reconsider MOTU... :)
[11:50] <JohnDong> LOL
[11:50] <ogra> JohnDong, and ogra@ubuntu.com :)
[11:51] <JohnDong> alright, I gotta leave too
[11:51] <JohnDong> great seeing everyone
[11:51] <ogra> yep :=
[11:51] <ogra> :)
[11:55] <kassetra> man.  I have a bunch of work to do now.
[11:55] <mdke> kassetra, maybe you can delegate a bit?
[11:55] <kassetra> LOL no, I meant to summarize this meeting.  :)
[11:56] <mdke> me too
[11:56] <kassetra> LOL well, if you have any suggestions, I'm all ears.
[11:56] <mdke> hmm
[11:56] <mdke> well if you can't find anyone to help, then just take as much time as you need
[11:57] <kassetra> k.  :)
[11:57] <mdke> it doesn't have to be done for tomorrow
[11:57] <kassetra> oh... that's a relief.
[11:57] <kassetra> I will get it soon, but I have my regular job meetings for today too.
[11:57] <mdke> kassetra, LOL people can't force you to do stuff you haven't got time to do
[11:57] <kassetra> LMFAO
[11:57] <kassetra> I know.  I just wanted to be a good reporter.  :)
[11:58] <\-> thanks kassetra for summarizing all this stuff.
[11:58] <mdke> you'll find that people will appreciate whatever you do
[11:58] <mdke> or they should anyhow
[11:59] <kassetra> LOL well, it's my first time doing this for this meeting, but I shouldn't be too terribly bad at it.
[12:02] <{Seb}> hi all
[12:02] <{Seb}> what happeneded in the backports meeting?
[12:02] <dholbach> there will be a wrapup on ubuntu-news <at> lists.ubuntu.org
[12:02] <{Seb}> can you basically tell me what happened?
[12:03] <kassetra> backports is going to be officially folded into the development community.  :)
[12:03] <{Seb}> good good
[12:03] <{Seb}> and?
[12:03] <mdke> {Seb}, you can find the log at people.ubuntu.com/~fabbione/irclogs
[12:03] <{Seb}> ok