[01:21] <ogra> @schedule
[01:21] <Ubugtu> Schedule for Etc/UTC: 08 Feb 16:00: Ubuntu Development Team | 10 Feb 21:00: Ubuntu Canada | 11 Feb 22:00: LoCo Teams | 12 Feb 20:00: Screencast Team | 13 Feb 16:00: Forum Council | 13 Feb 20:00: Technical Board
[04:33] <mdz> morning
[04:36] <fabbione> hey mdz
[04:36] <dholbach> heya mdz
[04:57] <mdz> cjwatson,doko,sfllaw,pkl,tkamppeter,asac,mvo,Riddell,iwj,kwwii,ogra: ping
[04:57] <cjwatson> yo
[04:57] <ogra> pong
[04:57] <asac> here
[04:57] <doko> here
[04:57] <mvo> hello
[04:58] <fabbione> mdz: sfllaw is on his way
[04:59] <Riddell> good afternoon
[04:59] <mdz> cjwatson: heard from till?
[04:59] <mdz> Keybuk: ian and ken?
[04:59] <sfllaw> Pong.
[05:00] <ogra> till was around in -devel earlier
[05:00] <cjwatson> (cjwatson) Henrik: "sudo AT-SPI looks like it's finally happening, but needs a fix in /root/.orbitrc"; can we do that some other way to avoid having to change dotfiles in /root?
[05:00] <Keybuk> they're both here
[05:00] <cjwatson> I'm dropping that off the agenda because I noticed it was discussed by e-mail already
[05:00] <Keybuk> where here =~ seen them online this afternoon
[05:00] <mdz> cjwatson: see -devel
[05:00] <mdz> ah
[05:00] <heno> cjwatson: yes, he discussion is in full flow upstream again
[05:00] <iwj> Hi everyone.
[05:01] <mdz> ok, let's get started
[05:01] <heno> we should go with a user work around and wait for it to get fixed properly (of course it still affects ubiquity badly)
[05:01] <mdz> cjwatson: Tim isn't here today, right?
[05:02] <cjwatson> no, holiday; that's noted on the agenda
[05:02] <mdz> agenda is at https://wiki.ubuntu.com/DevelTeamMeeting20070208:
[05:02] <mdz> cjwatson: let's put that at the top in the future
[05:02] <mdz> and I'm here :-)
[05:02] <cjwatson> mdz: sure, I'll edit the template
[05:02] <mdz> er, https://wiki.ubuntu.com/DevelTeamMeeting20070208 (no trailing punctuation)
[05:03] <mdz> are there any additions or deletions to/from the agenda?
[05:03] <Keybuk> gnargh!
[05:03] <Keybuk> COLIN, PLEASE OBEY WIKI LOCKS
[05:04] <cjwatson> huh? I see no lock errors
[05:04] <cjwatson> perhaps I missed it, if so sorry
[05:05] <Keybuk> np; you just did it twice in a row to me :p
[05:05] <BenC> FYI, ogra is listed twice on wiki, once with "NO REPORT..." and once with a report
[05:05] <fabbione> BenC: once for each of ogra's personalities
[05:05] <Keybuk> I suspect ogra added it himself
[05:06] <mdz> ok, taking the agenda as-is
[05:06] <Keybuk> ogra: you're most welcome to participate in the meeting, but please do get your report in by the end of Wednesday -- we pre-edit the agenda and send it out; if you add it yourself, people may not see it
[05:06] <ogra> yeah i did
[05:06] <mdz> "New Archive Team" has no name attached to it
[05:06] <ogra> Keybuk, yes. i'll be on time next week, really sorry for that
[05:06] <mdz> er, wrong agenda
[05:06] <Keybuk> mdz: errrr
[05:06] <mdz> asac: your agenda item?
[05:06] <mdz> (asac) Alexander wants to go over his firefox packaging changes with Ian.
[05:07] <cjwatson> that was one I added on asac's behalf to ensure that that got done soon
[05:07] <iwj> asac: Sure, how about right after this meeting ?
[05:07] <mdz> sounds like something the two of you could take care of out of band, rather than in this meeting
[05:07] <cjwatson> (since it was in his report)
[05:07] <cjwatson> it certainly doesn't need to happen in the meeting
[05:07] <mdz> ok
[05:07] <Keybuk> ACTION iwj and asac to talk about firefox packaging changes
[05:07] <asac> iwj: actually I am not here today :) ... I will upload it and we can go through it tomorrow?
[05:07] <iwj> asac: OK.
[05:07] <mdz> sounds good
[05:07] <mdz> the sooner the better
[05:07] <asac> fine ... actually I am quite optimistic that we get patches sorted out
[05:08] <iwj> asac: Sure but I'm away tomorrow ...
[05:08] <asac> there is only one major patch we might really get trouble getting upstream approval for
[05:08] <asac> the thai patch
[05:08] <iwj> Let's take these details offline.
[05:08] <asac> iwj: weekend?
[05:08] <mdz> asac: yes, that's come up with upstream already.  need to connect the person who wrote it with upstream to get it into shape
[05:09] <mdz> next agenda item: Will the following specs make release? (Scott James Remnant, Colin Watson)
[05:09] <asac> mdz: fine. Can you CC me, so I know the author?
[05:09] <mvo> asac: thep wrote it, hes around quite often in irc
[05:09] <Keybuk> right
[05:09] <Keybuk> iwj: your spec update didn't include any estimate of whether winmodem-support or automated-testing-deployment might make the release?
[05:09] <Keybuk> what's the status of those two specs?
[05:09] <iwj> automated-testing-deployment> Is largely decoupled from the release cycle.  So since it wasn't urgent for feature freeze it got put on hold at Keybuk's request.
[05:09] <mdz> asac: mvo should have his contact info; I don't have it to hand
[05:10] <asac> mdz: ok ... noted ... will ping mvo
[05:10] <Keybuk> *nods* the udev-* stuff was higher priority -- but if you started on that now, would you complete it before the release?
[05:10] <iwj> winmodem-support> It is now evident that it won't make the release.  I've been chasing after udev breakage the last day or two when I had hoped to be fixing up and promoting sl-modem-daemon.
[05:10] <mdz> iwj: even so, there's little potential to benefit from it for the release unless it's deployed soon
[05:10] <iwj> mdz: Indeed.
[05:10] <iwj> Although one benefit will be for security testing.
[05:11] <cjwatson> How long would winmodem-support take, out of curiosity?
[05:11] <tfheen> and we'll be gearing up, not down as we get closer to the release.
[05:11] <iwj> cjwatson: I spoke to mjg59 and I got the impression it was just a matter of putting together existing stuff in a slightly sane way.
[05:11] <iwj> I can get automated-testing running here out of cron with a week's work or so if I don't do anything much else that week.
[05:11] <mdz> I said the same thing about it in November.
[05:12] <iwj> mdz: Right, but I have the hardware now (since last week).
[05:13] <Keybuk> ok, otherwise your specs are now in good order; thanks especially for taking on some of the work from me
[05:13] <iwj> NP
[05:13] <Keybuk> udev-mdadm didn't take you as long as you feared?
[05:13] <Keybuk> (or is the spec status in LP wrong?)
[05:14] <mdz> if that's true, we will get more value out of automated testing than winmodem-support, since it should benefit a larger proportion of users
[05:14] <iwj> udev-mdadm was more straightforward than I feared but less easy than the spec said :-).
[05:14] <mdz> but winmodem-support is worth pushing in late if it's not too intrusive for users who don't have the hardware
[05:14] <iwj> Keybuk: LP> Oh, I probably forgot to update the status.
[05:14] <Keybuk> good.  the testing spec is the most important one to get done next, as that will be useful in the shortest time scale
[05:14] <fabbione> iwj: next week i am going to stress test the udev-* on the systems i have home that suck at bringing up disks at a normal speed
[05:15] <Keybuk> and as mdz just said, we should also get winmodem-support in, even past FF
[05:15] <tfheen> mdz: I would want it properly regression-tested so we don't end up loading modules which destabilise the system, since loads and loads of laptops have winmodem hardware.
[05:15] <iwj> mdz, Keybuk: Can I get you two to agree on priorities so know what I want to be working on ? :-)
[05:15] <mdz> tfheen: afaik, they're already loading the appropriate modules
[05:15] <Keybuk> iwj: I think we just did agree on priorities :p
[05:15] <iwj> fabbione: Right.  I think you'll find it's fine.
[05:15] <mdz> iwj: it sounds like we do
[05:15] <fabbione> iwj: i am sure it will be fine... i like to be the devil advocate ;)
[05:15] <tfheen> mdz: not my laptop at least.
[05:15] <iwj> OK, I'll do the winmodem support first since it's probably smaller.
[05:16] <Keybuk> *blink*
[05:16] <mdz> iwj: talk it over with Keybuk out of band
[05:16] <iwj> mdz: OK
[05:16] <mdz> moving on to mvo
[05:16] <Keybuk> mvo: dist-upgrader-fixes
[05:16] <mvo> dist-upgrader-fixes> -> Half is done, a backport of apt fixes is requested (DPkg::StopOnErrors patch, no changes to existing codepathes). Biggestet MISSING thing is runing the frontend and the backend in two different processes. this is prototyped, but python lacks a mechanism to pass file descriptors over sockets between processes. this is added in update-manager (fdsend module) now, so we can use this for the next release (then we will ha
[05:16] <mvo> ve https://blueprints.launchpad.net/ubuntu/+spec/dist-upgrader-arch-any too)
[05:17] <Keybuk> there wasn't anything in your report saying whether it'd miss FF but be ready for the Release, be ready for FF, or miss the Release
[05:17] <mvo> some bits are ready now
[05:17] <Keybuk> will the missing bits be ready before the release?  (ideally soon)?
[05:17] <mvo> the process seperation will miss release unless we backport the fdsend module to edgy
[05:17] <mdz> I don't think we should make major structural changes to the upgrader at this point
[05:18] <mvo> and for the better error handling I would like to add a patch to edgy apt
[05:18] <mvo> agreed
[05:18] <cjwatson> SRU stuff is later on the agenda
[05:18] <mdz> mvo: what's the potential benefit of the StopOnErrors backport?
[05:18] <mvo> mdz: apt will not stop if a dpkg --unpack/configure run fails
[05:19] <mvo> but keep going as long as possible
[05:19] <mvo> and report the broken packages
[05:19] <mvo> it won't change the behaviour by default
[05:19] <mvo> just when run under the upgrader
[05:20] <mdz> doesn't sound like a straightforward one to evaluate
[05:20] <mdz> let's discuss via email with the SRU team
[05:20] <mvo> fine with me
[05:20] <mdz> ACTION: mvo to discuss StopOnErrors backport with SRU team
[05:20] <pitti> still, if things break with the upgrader, that would be bad
[05:20] <mdz> tkamppeter: printerdriverautodownload?
[05:20] <cjwatson> that has made significant process since we last talked, according to Till's update
[05:21] <cjwatson> so I would like to know roughly how much longer it's expected to take, to see if it's worth an FF exception now
[05:21] <tkamppeter> I have made the first driver packages and put them up on OpenPrinting
[05:22] <tkamppeter> And I have updated the sites CGI scripts so that the packages are shown, added install instruction, and announced the new service.
[05:23] <tkamppeter> For making a source .deb which auto-downloads all available packages when building. I have some questions:
[05:23] <mdz> the spec calls for changes to PrinterDrake, which isn't shipping in this release
[05:23] <tkamppeter> Is it possible to convert a source RPM into a .deb source (.orig.gz, .diff.gz, dsc)?
[05:24] <pitti> mdz: these parts aren't crucial at all AFAICS, just nice to have (better integration)
[05:24] <tfheen> tkamppeter: you can't download anything off the net when you build a package.
[05:24] <pitti> tkamppeter: not universally; what do you need that for?
[05:24] <pitti> tfheen: the idea is something like 'debian/rules upstream-update'
[05:25] <cjwatson> tkamppeter: this should be a proper source package, not one converted from another format, IMO
[05:25] <mdz> this implementation sounds less and less like the summary of the spec
[05:25] <tkamppeter> The idea which was brought in for Ubuntu was making Ubuntu .deb packages from the available distribution-independent driver packages in an automated way.
[05:25] <pitti> tfheen: i. e. at some point you fetch the stuff from openprinting, then update the source package, and run the tests, etc.
[05:25] <tfheen> pitti: well, that's fine of course.
[05:25] <mdz> cjwatson,pitti,tkamppeter: how about the three of you review this out of band and come to a decision?
[05:25] <cjwatson> mdz: it's what's in the wiki page, though, more or less
[05:25] <pitti> mdz: fine for me
[05:25] <mdz> ok
[05:25] <cjwatson> the discussion evolved a fair bit since the LP spec summary was written
[05:26] <mdz> ACTION: cjwatson/pitti/tkamppeter to review printerdriverautodownload and come to a decision regarding its fate for feisty
[05:26] <cjwatson> ACTION: cjwatson, pitti, tkamppeter to review printerdriverautodownload
[05:26] <cjwatson> dup!
[05:26] <Keybuk> caught it :p
[05:26] <mdz> Kubuntu Upgrader needs patches backported to kdelibs, kdebase and adept but also the feisty version of python-kde3 backported, which means backporting also python-qt3 and sip4-qt3, is that OK to go into edgy-updates after the usual SRU process? (Jonathan Riddell)
[05:26] <mdz> ouch
[05:26] <Riddell> mostly just a warning
[05:27] <Riddell> we need the fesity python-kde3 for the new embedded konsole
[05:27] <mdz> my gut feeling just based on the scope of the changes is that we should release this with feisty and not backport it to edgy
[05:27] <Riddell> and that needs the feisty versions of python-qt3 and sip
[05:27] <Riddell> mdz: that defeats the point of a dist-upgrader, which is very badly needed
[05:28] <mdz> Riddell: it doesn't; it just makes it one release later
[05:28] <Riddell> there's only limited packages that use python-kde3 and -qt, it's possible to test them all for breakage
[05:28] <mdz> it doesn't meet the criteria for an SRU
[05:29] <mdz> well, not obviously anyway
[05:30] <mdz> it depends on just how poorly the upgrade experience is now, I suppose
[05:30] <mdz> but it's a very large change to weigh against the benefits
[05:30] <Riddell> judging by dapper->edgy very poor
[05:30] <sfllaw> Is there some way to statically compile for just that app?
[05:30] <tfheen> we need to solve this problem for dapper->next LTS too, at some point.
[05:30] <sfllaw> Then we could limit the breakage.
[05:30] <pitti> sfllaw: urgh @ security updates then
[05:31] <tfheen> sfllaw: that would mean shipping a statically compiled python, I think?
[05:31] <cjwatson> statically compile> include copies of the relevant modules with the upgrader?
[05:31] <cjwatson> UGLY, but ...
[05:31] <mdz> Riddell: have you talked with mvo about it?
[05:31] <mvo> statically compile> we would need autobuilder support for that
[05:31] <mvo> well, not really, but it would be really good to have that
[05:31] <cjwatson> I'm still convinced that you already have it
[05:32] <mvo> we may have arch-any upload support, but I'm pretty sure we do not have auto-builder support
[05:32] <cjwatson> well, might need a bit of a source package restructuring, but I think the archive-side support is all thre
[05:32] <cjwatson> there
[05:32] <Riddell> mdz: yes
[05:32] <mvo> its not a .dsc file afterall, just a tarball
[05:32] <cjwatson> a source package can spit out anything as long as it goes in a .changes file :)
[05:32] <cjwatson> right, the source package would need to be fixeed
[05:32] <cjwatson> fixed
[05:33] <mvo> cjwatson: that would be a interessting option, can we talk offline about this?
[05:33] <cjwatson> sure
[05:33] <cjwatson> ACTION: cjwatson and mvo to discuss dist-upgrader autobuilding
[05:33] <mdz> sounds like another conversation for the SRU team
[05:33] <mdz> (the Kubuntu upgrader situation, that is)
[05:34] <Riddell> == cjwatson and pitti?
[05:34] <mdz> ACTION: cjwatson/pitti/Riddell/mvo to discuss Kubuntu upgrade options for edgy->feisty
[05:34] <pitti> ack
[05:34] <mdz> A friend of mine just phoned me, he created a Qt GUI implementation for apport; do we want that in Feisty? It'd require us to copy over the apport bits of update-notifier to adept-notifier (shouldn't be hard, there's nothing GTK specific in it) (Martin Pitt)
[05:34] <pitti> I tested the current bzr head version (under Gnome, though)
[05:34] <pitti> it principally works
[05:34] <Riddell> what are the apport bits of update-notifier?
[05:34] <cjwatson> I would love to make ubiquity more consistent between GNOME and KDE as regards crash reporting
[05:35] <mdz> I see no reason why we wouldn't want it
[05:35] <pitti> modulo some bugs in the Qt/Gnome frontend and qt itself
[05:35] <pitti> but it's mostly cosmetics
[05:35] <mdz> pitti: is it something you can hand off to Riddell for most of the integration work?
[05:35] <pitti> Riddell: calling apport-checkreports and displaying a tray icon or calling apport
[05:35] <pitti> mdz: I'm happy to work with him to get it going
[05:35] <pitti> the u-n bits for apport are entirely GTK-independent
[05:35] <pitti> well, almost, the tray icon needs different treatment, I guess
[05:36] <pitti> but the branch just arrived today, so it's quite on the edge of FF
[05:36] <pitti> how'bout me uploading apport-qt to the archive today for more widespread testing?
[05:36] <pitti> (universe for now)
[05:36] <mdz> it's worth having, but only if it doesn't require much wore work for you
[05:37] <pitti> Riddell: my principal question is to you, whether you actually want it
[05:37] <mdz> does it make the difference between having apport in Kubuntu or not?
[05:37] <Riddell> pitti: sounds fun, my main worry remains how it interacts with the normal KDE crash handler and how annoyed upstream would get if we replaced it
[05:37] <pitti> mdz: Michael agreed to help with bug fixing in the qt port itself, so it's just the adept-notifier bits
[05:37] <pitti> Riddell: if kcrash intercepts sigsegvs, apport won't kick in
[05:38] <Riddell> ok, that's an easy way around
[05:38] <pitti> Riddell: so it'd only be used for non-KDE programs, as long as you keep krash enabled
[05:38] <Riddell> mdz: it would yes
[05:38] <pitti> and that depends on how happy upstream is with the krash reports they get
[05:38] <Riddell> pitti: there's a couple people who have been doing adept patches during feisty as well as myself so there's people to help with thfat
[05:39] <mdz> I can't imagine why
[05:39] <dholbach> hehe :)
[05:39] <mdz> ...
[05:39] <kwwii> while we are on the subject, the apport icons (from the last meeting), a first version is ready and the final icons should be done soon
[05:39] <fabbione> ROFL
[05:39] <pitti> kwwii: Troy sent me some, they look really nice!
[05:39] <Keybuk> Riddell: you realise that it now has to be
[05:40] <mdz> pitti: ok, are you finished with your agenda item?
[05:40] <kwwii> pitti: exactly, I am going to touch them up a bit, but they will be done soon
[05:40] <pitti> mdz: so, the decision seems to be 'yes, we want it'?
[05:40] <Keybuk> yes please
[05:40] <pitti> mdz: ok, then I'll put it into the archive today and discuss integration with Riddell
[05:40] <mdz> pitti: of course we do; it's a question of whether we can get it finished soon enough
[05:40] <Riddell> action: pitti to upload and riddell to evaluate that it doesn't break with current KDE stuff and find someone to do adept-updater work
[05:40] <pitti> ACTION: discuss adept-notifier integration of apport (pitti/Riddell)
[05:41] <pitti> heh, snap again
[05:41] <mdz> we already covered StopOnError earlier
[05:41] <mdz> (dholbach) [WWW]  https://lists.ubuntu.com/archives/ubuntu-devel/2007-February/023233.html
[05:41] <dholbach> I think we all agree, that it would have been nice to get this in earlier, I still wonder if it wouldn't make sense to get xorg 7.2 in still (in terms of maintainability and fixes we'd get from upstream and support for newer devices, etc.)
[05:41] <mdz> agenda items which consist solely of URLs are deprecated
[05:41] <pitti> does anyone know whether tepsipakki has the sk1llz for that?
[05:41] <dholbach> What does the Release team think?
[05:42] <mdz> dholbach: basically the same answer as for apport-qt
[05:42] <mdz> we certainly do want it, but we have finite resources and are occupied with other things at the moment
[05:42] <dholbach> mdz: I don't think we can have xorg7.2 in universe :)
[05:42] <cjwatson> on the one hand, I'd like to get the driver fixes, but on the other I'm concerned about having nobody dedicated to new bugs coming in
[05:42] <mdz> is anyone available to review his packages and upload them?
[05:42] <dholbach> cjwatson: we don't have anybody dedicated to old bugs atm too :-/
[05:42] <mdz> and who would be responsible for bug reports?
[05:43] <mdz> I assume this stuff isn't in Debian yet
[05:43] <cjwatson> we ought to be able to sync a number of the libraries from Debian experimental
[05:43] <mvo> I guess we could do this as a team effort (review+upload)
[05:43] <cjwatson> mdz: I think some of this is merges from experimental
[05:43] <tfheen> I'm not happy with it unless we have a bunch of interested people who works on it, actively.
[05:43] <cjwatson> but I haven't verified
[05:43] <seb128> I can review some uploads, I've enough bugs on my list without xorg though
[05:44] <tfheen> we have a bunch of people who can chip in a bit, but that's not really enough.
[05:44] <dholbach> cjwatson: he merged a bunch of packages with experimental already
[05:44] <tfheen> seb128: and you're already stretching more than last cycle now that you're doing ubuntu-archive stuff.
[05:44] <mdz> if we can get a plausible community effort behind it, we can do it
[05:44] <mdz> but someone in core-dev needs to be the point person for it
[05:44] <tfheen> mdz: that'd need to happen fairly quickly though.  If we have a team of interested people and merged packages in a week, it can happen.
[05:44] <seb128> tfheen: right, I clearly don't intend to spend much efforts on xorg
[05:45] <mdz> what's needed is to explain the requirements for making this happen for feisty, to the people working on it
[05:45] <cjwatson> somebody should post to -devel with such an explanation and calling for core-dev assistance
[05:45] <kylem> mdz, i'm willing to take point if i need to.
[05:46] <seb128> the question is if we think the 7.2 upload would bring bugs_fixed >  new_bugs_brough
[05:46] <cjwatson> if that came from one of the core team it would have more impact
[05:46] <tfheen> mdz: I can do that from a RM POV.
[05:46] <mdz> get a handle on the scope, estimate a reasonable deadline for completion, form a team which can plausibly respond to bug reports, etc.
[05:46] <kylem> i'm sure mjg59 will chip in too, he wants to see some of this stuff in feisty.
[05:46] <Keybuk> 7.2 doesn't include either input-hotplug or monitor-hotplug/randr 1.2; right?
[05:46] <kylem> Keybuk, correct, that's 7.2.1 ;-)
[05:46] <tfheen> Keybuk: input-hotplug is easily mergable, but monitor-hotplug is 7.3, AIUI.
[05:46] <mdz> it surely brings heaps of hardware-related improvements though
[05:46] <kylem> still doable for feisty thoughh...
[05:47] <cjwatson> kylem: I don't want you doing much of the actual work, but I'd be happy if you're willing to coordinate
[05:47] <mvo> I would like to support the effort too
[05:47] <kylem> randr 1.2 needs xserver 1.2.1 which keithp has said he can have release ready for us...
[05:47] <cjwatson> some of the work will match up with your kernel bits of course
[05:47] <dholbach> I'll try to help with forming a team and talk to tepsipakki - should the team present their efforts at the next TB meeting or something?
[05:47] <kylem> cjwatson, right, i don't want to do the actual work either. ;-P
[05:47] <mdz> cjwatson: would you write up the requirements for ubuntu-devel?  formulate it so that someone needs to put their name in each of the necessary slots in order for it to be approved
[05:47] <fabbione> dholbach: there is an X team already
[05:47] <fabbione> dholbach: let's use that one
[05:47] <dholbach> fabbione: where?
[05:47] <cjwatson> it's modular. the team should get whatever the hell they can into the archive in incremental stages that won't break the world
[05:47] <mdz> ubuntu-x-swat
[05:48] <fabbione> dholbach: ubuntu-x-swat..
[05:48] <dholbach> yeah, but who's on that team?
[05:48] <cjwatson> not wait for a meeting :)
[05:48] <cjwatson> mdz: yes
[05:48] <kylem> cjwatson, i'm mostly just concerned about -intel for obvious reasons.
[05:48] <dholbach> I didn't to intend to invent a new name
[05:48] <cjwatson> right
[05:48] <mdz> ACTION: cjwatson to post requirements for X.org 7.2 in feisty to -devel
[05:48] <fabbione> dholbach: me... and a few others... people don't join it for fun
[05:48] <mdz> at a minimum, this should require that the packagers and a couple of other folks step up to join the X team and follow up
[05:48] <ogra> how do we mae sure we dont need to roll back everything if they loose interest half way ?
[05:48] <ogra> *make
[05:48] <mdz> and someone on -core-dev to sponsor them
[05:49] <cjwatson> ogra: 16:47 < cjwatson> it's modular. the team should get whatever the hell they can into the archive in incremental stages that won't break the world
[05:49] <mdz> and we get a commitment from them
[05:49] <ogra> cjwatson, but if it does ?
[05:49] <cjwatson> this should be perfectly doable; our client-side and server-side stuff is already out of sync
[05:49] <cjwatson> ogra: we only need to roll back a package or two
[05:49] <ogra> mdz, exactly, thats what i mean
[05:49] <dholbach> fabbione: we all agreed that we don't have somebody who looks after bugs at the moment... that's why I asked 'where' - I wrote the wiki pages for ubuntu-x-swat so I should know :)
[05:49] <cjwatson> I have many concerns, but they don't include needing to roll back everything
[05:50] <fabbione> dholbach: right, i thought you wanted to create another LP team
[05:50] <ogra> cjwatson, mine neither, but being left with a half done update ...
[05:50] <mdz> ok, sounds like consensus to me
[05:50] <dholbach> fabbione: no, not really
[05:50] <mdz> moving on
[05:50] <mdz> Keybuk: udev debugging?
[05:50] <Keybuk> still have to write that
[05:50] <cjwatson> ogra: half-done isn't actually all that bad in this case. Anyway, #ubuntu-devel
[05:51] <Keybuk> I'll try and get to it next week for the bug fixing push
[05:51] <iwj> udev debugging> shoot the author ?
[05:51] <iwj> Excuse me, I'm just a bit annoyed with it recently :-).
[05:51] <cjwatson> legal udev debugging
[05:52] <Keybuk> iwj: could you write up the problems you had with it
[05:52] <mdz> s/legal/helpful/
[05:52] <Keybuk> it could be a useful thing for upstream
[05:52] <seb128> mdz: is that ok if I go now? I've guitar class in a few min
[05:52] <Keybuk> kay's a nice guy, he accepts helpful (and/or witty) criticism
[05:52] <mdz> if done with a constructive tone
[05:52] <iwj> Keybuk: Hmm.  I'll write up a rant and then we can tone it down into something useful.
[05:52] <Keybuk> send it to me first; since I already have a working relationship with him
[05:52] <Keybuk> ok
[05:52] <Keybuk> ACTION iwj to write up summary of experiences debugging udev
[05:52] <iwj> While we're on udev, is anyone here affected by bug 83878 ?
[05:52] <Ubugtu> Malone bug 83878 in udev "wrong permissions for /dev/null" [High,Confirmed]  https://launchpad.net/bugs/83878
[05:53] <mdz> seb128: OK, but this meeting is scheduled for 1 hour, you should plan on being able to stay until the end
[05:53] <iwj> If so talk to me afterwards.
[05:53] <Keybuk> iwj: everyone is on and off; it tends to show up once in a while with a whole bunch of different causes
[05:53] <seb128> mdz: ok, will do for next time, thanks
[05:53] <mdz> sfllaw will e-mail distro-team@ about commercial package support
[05:53] <Keybuk> it's the most common symptom of "udevtrigger didn't get run"
[05:53] <iwj> Keybuk: Joy.
[05:53] <Keybuk> mdz: he's done that
[05:53] <mdz> this seems to have happened _during_ the meeting
[05:53] <cjwatson> hah
[05:53] <sfllaw> Yes.
[05:53] <cjwatson> Brinkmanship. :-)
[05:53] <sfllaw> I only noticed after reading the agenda.
[05:54] <Keybuk> iwj: sometimes caused by the udev init script being run multiple times
[05:54] <mdz> deliverables were mailed to distro-team after last week's meeting
[05:54] <cjwatson> doko to mail ubuntu-devel about which Python modules should be in main
[05:54] <cjwatson> judging from the odd /msg, doko has been investigating this today?
[05:54] <doko> cjwatson: that was done *before* the meeting
[05:55] <cjwatson> aha, I didn't notice; I'm behind on -devel
[05:55] <Keybuk> doko: reference?
[05:55] <Keybuk> doko: you didn't follow-up to distro-team to say the action was done
[05:55] <Keybuk> (which is useful if your line manager hasn't caught up on other mailing lists :p)
[05:55] <doko> Keybuk: hmm, ok
[05:55] <mdz> cjwatson to chase up the set of core-devs who can help moderate ubuntu-devel and arrange for clear documentation
[05:56] <cjwatson> FYI, I've edited Simon's late update into the agenda
[05:56] <doko> Keybuk: https://lists.ubuntu.com/archives/ubuntu-devel/2007-February/023235.html
[05:56] <mdz> I posted bullet points which should be sufficient for documentation
[05:56] <cjwatson> moderation> this is still not done, I'm afraid; I gave feature-freeze requirements precedence
[05:56] <Keybuk> heh, 20 seconds before the meeting doesn't count <g>
[05:56] <cjwatson> please leave it on my action list for this week
[05:56] <mdz> ok
[05:56] <mdz> tfheen: release readiness?
[05:56] <heno> I've done some moderation and have filed some RT about whitelisting and spam
[05:57] <tkamppeter> iwj, the /dev/null problem keeps HPLIP's hpssd from starting, bug 83924
[05:57] <Ubugtu> Malone bug 83924 in hplip "[apport] [feisty]  hpssd crashed with IOError in daemonize()" [Medium,Unconfirmed]  https://launchpad.net/bugs/83924
[05:57] <pitti> tkamppeter: -> #ubuntu-devel, please
[05:57] <tfheen> mdz: I'm a bit behind on looking at the spec status, but when I looked at it on Monday, it looked like about half the specs were good progress or better.
[05:58] <mdz> tfheen: blocker bugs?
[05:58] <Keybuk> I should probably have sent tollef the list of specs mdz and I wrote last week
[05:59] <tfheen> Keybuk: yes, please.
[05:59] <Keybuk> that has whether they're likely to meet FF, slip but make the release, or miss
[05:59] <tfheen> mdz: I'm behind on those as well, but I don't have any big problems on my radar.
[05:59] <mdz> I'm more interested in bugs, honestly
[05:59] <mdz> we can more easily release without a feature than with a major bug
[06:00] <tfheen> there's a fair amount of polishing to be done such as NetworkManager needing a bit of love to handle suspend/resume reliably.
[06:00] <mdz> tfheen: have you received any high-profile issues from sfllaw, bdmurray or others in the past week?
[06:00] <Keybuk> we should target bugs at the feisty release?  or at a milestone?
[06:00] <mdz> right, is there a process in place to flag bugs which you should be tracking?
[06:00] <tfheen> Keybuk: if they're feasible for a milestone, milestone.
[06:00] <Keybuk> https://bugs.launchpad.net/ubuntu/feisty/+bugs
[06:01] <Keybuk> (has three 3 bugs)
[06:01] <Keybuk> https://launchpad.net/ubuntu/+milestone/ubuntu-7.04
[06:01] <tfheen> mdz: not a formal one, no.  I'll get in touch with QA about it.
[06:01] <Keybuk> (has a whole bunch of bugs)
[06:01] <mdz> ACTION: tfheen to document bug escalation to release management
[06:01] <tfheen> so far it has been "target stuff to a release/milestone"
[06:02] <mdz> tfheen: plenty of room for confusion there, especially since we have milestones intended to work around the former lack of release targeting
[06:02] <mdz> ok, that's the end of the agenda
[06:02] <mdz> any other business?
[06:02] <tfheen> I'd just like to remind everybody that herd-4 is due next week
[06:03] <tfheen> and that we're now in FF+UVF, so please get in touch if you have new upstream versions you want in.
[06:03] <pitti> oh, already? *urgh*
[06:03] <tfheen> pitti: traditionally, it's been the start of the distro meeting, you've I've let it slip by a whole hour! :-)
[06:03] <cjwatson> I have migration-assistant still to land
[06:03] <BenC> what if I have a totally new package?
[06:03] <Keybuk> I still have both my specs to land
[06:03] <cjwatson> it's in main, but the ubiquity merge needs to be done
[06:03] <pitti> tfheen: I meant herd-4, not UVF
[06:04] <cjwatson> in the middle of that :)
[06:04] <tfheen> pitti: oh, ok.
[06:04] <BenC> new kernel needs dtc (device-tree compiler) for ppc
[06:04] <tfheen> I'm fine with people sneaking stuff in under the wire for today.
[06:04] <tfheen> BenC: ugh.  Get it packaged ASAP.
[06:04] <sfllaw> tfheen: I have a version of ttf-dejavu that I'm looking at building.
[06:04] <tfheen> BenC: and get the MIR done ASAP.
[06:04] <sfllaw> To solve internationalization issues.
[06:04] <BenC> tfheen: will do
[06:04] <BenC> I might just sneak it into the kernel build, since that's the only place that needs it
[06:05] <tfheen> BenC: please don't, I'd rather have to NEW it.
[06:05] <BenC> then it'd only take up src space
[06:05] <BenC> tfheen: let's talk in -devel
[06:05] <mdz> ok, anything else, please follow up by mail/IRC
[06:05] <mdz> adjourned, thanks all
[06:05] <fabbione> thanks guys
[06:05] <fabbione> cya monday
[06:06] <amendt> Great Meeting!
[06:06] <Keybuk> tfheen: ok, spec list sent to you
[06:06] <dholbach> thanks
[06:06] <kwwii> bye all, thanks
[06:06] <pitti> thanks everyone
[06:06] <tfheen> Keybuk: cheers.
[06:06] <iwj> Thanks everyone.  This one was tough.  Let's see if we can make the next one shorter :-).
[06:08] <pkl_> bye
[06:08] <ogra> wow, nice and fast
[06:10] <mvo> thanks
[10:36] <Commander-Crowe> @time los_angeles
[10:36] <Ubugtu> Current time in America/Los_Angeles: February 08 2007, 13:36:17 - Next meeting: Ubuntu Canada in 1 day