[05:06] <didrocks> good morning
[05:47] <pitti> Good morning
[05:53] <sladen> morgen pitti
[05:55] <pitti> hey sladen, how are you?
[06:25] <sladen> pitti: admiring the weather (dull), and my todo list (similar ;-)
[06:35] <buxy> pitti: any way to get the apport retracer to do its work for https://bugs.launchpad.net/ubuntu/+source/dpkg/+bug/807845 ?
[06:35] <pitti> buxy: that's on my list today; the retracers crashed due to a fakechroot problem again
[06:35] <buxy> ok, thanks
[07:02] <dupondje> pitti: thanks for cups apparmor fix :D
[07:06] <geser> good morning
[07:20] <dholbach> good morning
[07:26] <pitti> hey dholbach, guten Morgen
[07:27] <pitti> dholbach: UDW all cut and dried now? *hug*
[07:29] <dholbach> pitti, yep - I'll start writing the summary now, so you can see what other than your session happened :)
[07:29]  * dholbach hugs pitti back
[08:30] <pitti> cjwatson: if you dd a current iso to an USB stick, the device/partition headers look strange; blkid thinks that both sdb1 and sb are a mountable iso9660 file system
[08:30] <pitti> cjwatson: and indeed that's right, as you can mount either of them
[08:30] <pitti> cjwatson: but which one is the "right" one to automount if you plug it into a running ubuntu system?
[08:31] <pitti> or doesn't it matter really?
[08:31] <pitti> didrocks: ^ FYI
[08:39] <jhunt_> pitti: Morning! FYI, my upstart fix for /run is failing in the test phase. Looks like a change in dbus behaviour in oneiric.
[08:42] <pitti> hey jhunt_
[08:44]  * jml waves
[08:45] <RAOF> slangasek: Is there any chance that debhelper compat 9 could make substituting DEB_HOST_MULTIARCH less of a pain in *.install,*.{pre,post}{inst,rm},*.links, etc?
[08:45] <pitti> jhunt_: you mean it doesn't actually pick up the things in /run/initramfs/ ?
[08:46] <RAOF> jml: Hello!
[08:46] <pitti> jhunt_: I tested it with the symlink and bootchart, and it seemed to work
[08:46] <jml> RAOF: hi
[08:46] <jhunt_> pitti: no, sorry. it just means that the "build" fails for upstart in the test phase. I believe -- as you say -- that the code change itself should work fine.
[08:48] <jhunt_> pitti: we now get this error from dbus in a chroot: "Unable to autolaunch a dbus-daemon without a $DISPLAY for X11'"
[08:49] <jhunt_> pitti: problem relates to starting an app using a session bus I believe. But this is different behaviour to natty.
[08:49] <pitti> jhunt_: strange that this is related to the "check /run" change; or isn't it?
[08:50] <jhunt_> pitti: it's not related to that change, but I can only presume the archive builds do not occur in a chroot env otherwise we wouldn't have a build of upstart for oneiric.
[08:51] <pitti> we do have build chroots, but perhaps they are tweaked enough
[08:52] <jhunt_> pitti: ok. I'd really like to understand what is being tweaked. Who would be the best person to talk to about that?
[08:53] <pitti> jhunt_: probably lamont or infinity
[08:53] <jhunt_> pitti: ah yes, thanks!
[09:17] <cjwatson> pitti: IIRC the partition table is set up such that it doesn't matter
[09:19] <cjwatson> RAOF: beware, controversy.  http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=614731
[09:23] <RAOF> …and it just peters out.
[09:29] <cjwatson> RAOF: but in a way that promises doom if we try to change it Ubuntu-specifically
[09:29] <doko> did make the mistake to update the desktop to oneirc this weekend :-(
[09:30] <doko> - context menu in firefox is broken, pop's up and I can't select anything
[09:30] <doko> chrisccoulson: ^^^
[09:30] <doko> - how do I change my workspace from 2x2 to 4x1?
[09:30] <chrisccoulson> doko - known compiz bug
[09:31] <doko> - how do I change the monospace font settings?
[09:31] <chrisccoulson> doko - it will work again if you focus another window and change it back again
[09:31] <chrisccoulson> (it's also broken in natty though)
[09:32] <doko> didn't had to use it in natty ;p
[09:32] <doko> seb128: ^^^
[09:33] <seb128> doko, dunno about the compiz bug, you can change the workspace layout in ccsm
[09:34] <pitti> doko: gnome-tweak-tool has the font settings now
[09:34] <seb128> the font in dconf-editor
[09:34] <seb128> gnome-tweak-tool depends on gnome-shell though, which is a bit over what you want to install to tweak a setting
[09:35] <doko> seb128: ccsm?
[09:35] <seb128> doko, it's a command
[09:36] <seb128> it's from compizconfig-settings-manager if you don't have it installed
[09:44] <doko> seb128: hmm, still can't find it in ccsm
[09:46] <seb128> doko, click on the tools icon "option..." in the first category
[09:46] <seb128> doko, it's the tab 5 in this dialog (need to scroll tabs to reach it)
[09:48] <pitti> cjwatson, didrocks: ah, I found out why dd'ed isos don't show up in GNOME: they have partition type 0x17, which is "Hidden IFS (e.g., HPFS)"
[09:48] <pitti> these are ignored
[09:49] <didrocks> pitti: oh, so the behavior is expected, it's at least a start :-)
[09:49] <pitti> well, FSVO "expected"
[09:50] <didrocks> right
[09:50] <pitti> didrocks: the raw device is ignored because there is a partition, to work around that common breakage with unclean first sectors
[09:50] <doko> seb128: ok, found it, but changing this doesn't have any effect
[09:50] <pitti> and the partition is hidden by udev rules to avoid showing recovery partitions
[09:50] <doko> or do I need to restart compiz?
[09:50] <pitti> tricky
[09:50] <seb128> doko, are you sure you are running unity-3d?
[09:50] <seb128> doko, ps ax | grep compiz?
[09:50] <didrocks> pitti: urgh, indeed
[09:51] <doko> seb128: apparently, I don't
[09:51] <seb128> doko, ok, that probably explain why it doesn't work
[09:52] <doko> seb128: so how to change that in unity-2d?
[09:52] <seb128> try running compiz --replace or unity and see what if it complains and about what
[09:52] <seb128> doko, what videocard and driver do you use?
[09:52] <seb128> 3d should work if it worked in natty...
[09:56] <doko> seb128: Intel GM965/GL960
[09:56] <seb128> doko, does running "unity" works?
[10:00] <brendand> anyone know why i might be getting 'unable to load addon translations' when doing debuild in Oneiric?
[10:00] <brendand> what am i missing?
[10:10] <doko> seb128: it did log me out, after reboot, the 4x1 setting works
[10:10] <doko> but it's horrible to get there
[10:11] <seb128> doko, right, ccsm is not a nice ui
[10:12] <seb128> it might be worth trying ubuntu-tweaks
[10:12] <seb128> http://ubuntu-tweak.com/
[10:24] <doko> chrisccoulson, seb128: not sure, if that's known too ... typing less in a terminal, quitting with q, doesn't show you the scrollbar anymore :-/
[10:49] <jjardon> Hi, Is there any chance to package glade 3.8 for oneiric?
[10:49] <jjardon> Currecty the only available version is 3.10, but this version doesnt have libglade support
[10:50] <jjardon> (3.8 and 3.10 are parallel instalables)
[10:50] <seb128> jjardon, isn't libglade deprecated for years?
[10:51] <jjardon> seb128: yes, but we need it to port applications that still using libglade
[10:52] <seb128> jjardon, well I guess the old glade could be packaged if somebody has enough interest to work on that, it's not a priority though
[11:15] <dupondje> StevenK: https://launchpad.net/ubuntu/+source/guile-gnome-platform/+changelog => Any idea why you added the ubuntu delta? Its long time ago, but you never know :p
[11:27] <tkamppeter> hi, thunderbird stopped working completely for me, I get
[11:27] <tkamppeter> GLib-GIO-ERROR **: Settings schema 'apps.gecko-mediaplayer.preferences' is not installed
[11:28] <tkamppeter> Trace/breakpoint trap   (core dumped) thunderbird
[11:28] <tkamppeter> Is this known?
[11:41] <tkamppeter> chrisccoulson, hi
[11:41] <chrisccoulson> hi tkamppeter
[11:42] <tkamppeter> chrisccoulson, it seems that thunderbird is generally not working any more. I get
[11:42] <tkamppeter> GLib-GIO-ERROR **: Settings schema 'apps.gecko-mediaplayer.preferences' is not installed
[11:42] <tkamppeter> Trace/breakpoint trap   (core dumped) thunderbird
[11:43] <chrisccoulson> that's not a thunderbird bug
[11:43] <tkamppeter> chrisccoulson, is this known?
[11:43] <chrisccoulson> nope
[11:43] <chrisccoulson> that's caused by a plugin you've got installed (gecko-mediaplayer)
[11:43] <chrisccoulson> (just a guess, going on the schema name)
[11:44] <tkamppeter> chrisccoulson, so seems to be best to uninstall that plugin?
[11:44] <chrisccoulson> tkamppeter, yeah
[11:46] <tkamppeter> chrisccoulson, that's it, thunderbird is working again. Thank you.
[11:50] <chrisccoulson> tkamppeter, no problem. i'll get that fixed, as i guess it also stops firefox from starting too
[11:53] <tkamppeter> chrisccoulson, OK, is this bug 812053?
[11:53] <chrisccoulson> tkamppeter, yeah
[11:54] <chrisccoulson> how on earth there was ever an upstream release of this is beyond me, there's no schema file anywhere in the upstream source
[11:54] <chrisccoulson> so it could never have worked for anybody
[11:55] <tkamppeter> chrisccoulson, thanks. I have added a comment and a "me too" to that bug.
[11:56] <chrisccoulson> tkamppeter, oh, i think we commented at the same time ;)
[12:18] <Daviey> stgraber / Laney: people with PPU should be in ~ubuntu-dev, right?
[12:22] <Laney> Daviey: yeah
[12:23] <Daviey> Laney: ~serge-hallyn has PPU but not in ~ubuntu-dev
[12:23] <Laney> alrighty
[12:26] <Laney> done, thanks
[12:26] <Daviey> rocking, thanks Laney
[12:26] <Laney> "This is the team of developers who work on Ubuntu. They are called the "Masters of the Universe" because historically they were responsible for the long tail of packages outside the core of the OS."
[12:26] <Laney> err, think not
[12:27] <Daviey> Laney: I've never understood the logo either :)
[12:50] <StevenK> dupondje: I can't recall, sorry. Intrepid was a *long* time ago.
[12:50] <StevenK> dupondje: I suspect it was a FTBFS fix. If it builds without it, drop it.
[13:40] <jdstrand> pitti: hey, I saw the changes to the cups profile for bug #812035. I'm not sure what is put in /run/samba by samba itself, but it seems like giving cups rw access to all of /run/samba/** might be too lenient
[13:41] <jdstrand> pitti: what is cups trying to do with it and what does samba put in there?
[13:41] <pitti> jdstrand: you think it might be enough to give it write permissions for /run/, to create the dir?
[13:41] <pitti> the bug report had a denied privilege of 'c', which is undocumented
[13:41] <pitti> seems to map to an mkdir call
[13:41] <pitti> jdstrand: but apparently cups is trying to mkdir /run/samba/
[13:42] <jdstrand> pitti: well, that is just it-- I don't know what cups is trying to do. '/run/samba/ rw,' would solve the immediate error, but I don't know if more would then come out after
[13:43] <jelmer> it seems wrong for cups to look at /run/samba in either case, as the location of that directory can be changed in the samba configuration
[13:46] <jdstrand> if it operates correctly without it, then maybe use 'deny /run/samba/ w,'
[13:46] <jdstrand> that would silence the error
[13:46] <jdstrand> (but make it harder to diagnose if the access was actually needed)
[13:47] <pitti> jdstrand: thanks; I'll ask in the bug
[13:47] <jdstrand> pitti: cool, thanks
[13:48] <pitti> dupondje: ^
[13:48] <pitti> asked in bug 812035
[13:51] <cjwatson> oh, bah, designing an interface that requires a function to be called when one fd is ready for reading *and simultaneously* another fd is ready for writing is probably not very select-friendly, is it
[13:52] <dupondje> pitti: jdstrand: I added a remote printer on a SMB share
[13:52] <dupondje> that caused to pop the error in dmesg
[13:52] <dupondje> But printing worked!
[13:53] <pitti> dupondje: ah, thanks
[13:53] <pitti>   deny /{,var/}run/samba/ rw,
[13:53] <pitti> jdstrand: ^ so that should do it?
[13:53] <dupondje> I also searched the network
[13:53] <dupondje> for printers
[13:54] <dupondje> not on my computer at home atm
[13:54] <dupondje> so can't test what action it was exactly :)
[13:55] <dupondje> But 'search network printer' failed I think
[13:55] <dupondje> 'Find Windows printer on SMB share' worked
[13:55] <dupondje>  can test that again if you want
[13:56] <ion> I take it dmz-cursor-theme wasn’t dropped from ubuntu-desktop intentionally?
[13:56] <jdstrand> pitti: it sounds like a reasonable start
[13:57] <jdstrand> dupondje: please file a bug if printing to that printer gets weird if we update the profile to explicitly deny
[13:58] <dupondje> i'll do :)
[14:36] <RoAkSoAx> kees: howdy! I was wondering if you have an ETA on when will bug #800403 be reviewed?
[14:57] <Laney> kirkland: are you aware that divitup's ssl certificate has expired?
[14:57] <kirkland> Laney: i am, will get that fixed ;-)  I'm moving it to godaddy
[14:57] <Laney> :-)
[14:58] <kirkland> Laney: thanks for the reminder!  will get that ssl cert on order today
[14:58] <Laney> np
[15:11] <cr3> soren: thanks for copy-ppa-pkg.py in your ubuntu-archive-tools branch, came in very handy today
[15:24] <bjf> @pilot in
[15:35] <tkamppeter> mpt, hi
[15:39] <worstadmin> So the guy says to me "Are you *suuure* that you aren't an actor" ohaha that's right Mr. Giraffe get all the marmalade.
[15:42] <roadmr> hi folks, I have a source tree and when I debuild -S, the .tar.gz is huge because it's including .bzr, how should I invoke debuild so .bzr gets ignored/excluded?
[15:43] <micahg> roadmr: use bzr-builddeb
[15:43] <jamespage> lamont: ping re aspectj manual bootstrap build
[15:45] <micahg> I have lm-sensors which is replacing lm-sensors-3, should I -v to the last lm-sensors upload or the last lm-sensors-3 upload?
[15:46] <roadmr> micahg: excellent, a simple answer for a newbie question :) works like a charm, thanks!
[16:10] <jono> didrocks, was it you who I spoke to at the Rally about the Qt Creator Design bug being fixed?
[16:11] <didrocks> jono: I think we didn't speak about it together, but I clearly tried to figure out why there was this bug and know it will be fixed for Oneiric :)
[16:12] <didrocks> jono: basically, step 1 is there, still need a new qt creator sync from debian + a small patch (but need new qtwebkit first)
[16:12] <jono> didrocks, oh, cool, someone told me there was a fix and it was going in the week after the Rally
[16:12] <jono> was just curious :-)
[16:12] <didrocks> jono: right, but new qtwebkit came into the dance between :-)
[16:13] <jono> didrocks, aha!
[16:13] <jono> good times
[16:13] <jono> lol
[16:13] <didrocks> of course :-)
[16:13] <didrocks> jono: I'll ping you once it's done (I have it working locally fyi)
[16:14] <jono> thanks so much didrocks, you rock, as usual :-)
[16:14] <didrocks> thanks :-)
[16:25] <pdtpatrick> There are no plans in the making to be able to suppress the unity dock to the left are there?
[16:36] <lamont> jamespage: see the portal
[16:36] <lamont> I saw it's waiting for me, slim chance today, better chances tomorrow
[16:36] <jamespage> lamont: great - thanks
[16:39] <slangasek> RAOF: debhelper multiarch substitutions: there was a bug report requesting such a facility for debhelper (at least for .install, .links files, not for maintainer scripts), but there is unlikely to be progress soon on getting this merged
[16:55] <jdstrand> dholbach: hi! fyi, I have created a wiki page for the security team's packages of the week: https://wiki.ubuntu.com/SecurityTeam/HighlightedPackages. Currently this is being importated into our GettingInvolved page (https://wiki.ubuntu.com/SecurityTeam/GettingInvolved#Fix_security_bugs)
[16:57] <dholbach> jdstrand, awesome! I'll write about it tomorrow
[16:58] <jdstrand> dholbach: it is also something that will be mentioned in our weekly irc meetings
[16:58] <dholbach> that's awesome
[16:58] <jdstrand> dholbach: thanks for your ideas/help with all of this :)
[16:58]  * dholbach hugs jdstrand
[16:59]  * jdstrand hugs dholbach back :)
[16:59] <dholbach> :-D
[17:48] <bdmurray> cjwatson: I was thinking about making an apport package hook for memtest that'd direct some bugs to grub2 since a lot of failures occur with the syntax of grub files
[18:38] <Phr3d13> i know this isn't support, but can someone help me with my problem? trying to get a via vt6410 pci raid/ide card to see the drives attached to it, running ubuntu 11.04
[19:03] <stgraber> geser: ping?
[19:09] <ikonia> Phr3d13: if you know it's support why are you asking
[19:10] <ikonia> Phr3d13: you've had the issue explained to you in #ubuntu before you got banned, so please don't bring support here
[19:13] <Pici> 14:38:34 <Phr3d13>
[19:13] <Pici> oops
[19:16] <Phr3d13> my bad, just trying to get a better answer than ask via and "it isn't supported", sorry
[19:17] <serue_> i didn't know there was 'submittodebian!'
[19:17] <serue_> neat
[19:21] <bdmurray> slangasek: do you know what 'Bus error' means in bug 790869?
[19:22] <slangasek> bdmurray: I do, but how it happens there is a mystery :)
[19:23] <slangasek> bdmurray: "bus error" is the signal when something tries to do unaligned memory access and the CPU rejects it; this doesn't happen on x86
[19:23] <infinity> Yeah, I was just scratching my head at that.
[19:23] <slangasek> (because the CPU never rejects it)
[19:23] <slangasek> bdmurray: so we would need to reproduce this and catch a backtrace of the failing process to actually diagnose
[19:23] <infinity> Maybe someone helpfully added alignment traps to the i386 kernel and it throws sigbus? :P
[19:24] <slangasek> that would be excellent :)
[19:25]  * micahg tries to ask his question again
[19:25] <micahg> I have lm-sensors which is replacing lm-sensors-3, should I -v to the last lm-sensors upload or the last lm-sensors-3 upload?
[19:25] <slangasek> micahg: what do you mean by "-v"?
[19:26] <micahg> slangasek: debuild -v, to get the changelog entries in sources.changes
[19:26] <slangasek> oh
[19:26] <broder> other than bookkeeping, what's actually affected by that? LP closer detection?
[19:26] <infinity> slangasek: Apparently, SSE* instructions can SIGBUS.
[19:26] <slangasek> infinity: oh, woot!
[19:27] <slangasek> micahg: I would use the last lm-sensors version
[19:27] <micahg> broder: probably nothing, just wondering if people have any opinions
[19:27] <slangasek> because there's a separate lm-sensors-3 package in the archive with a separate changelog
[19:27] <micahg> slangasek: right, so lm-sensors-3 is being dropped from Debian with lm-sensors taking over again
[19:27] <infinity> slangasek: Still pretty unhelpful to know without a backtrace, mind you.
[19:28] <micahg> slangasek: it's essentially a source rename to a previously used source
[19:29] <infinity> bdmurray: I have a sneaking suspicion that with the bug being 2 months old, you won't be able to ask the reporter if his system is still hosed and get him to backtrace ldconfig in gdb, but that would be nice. :P
[19:29] <slangasek> micahg: yeah, I understand... I guess my answer might depend on what the changelog for this package actually looks like :)
[19:29] <micahg> slangasek: I can pastebin the two options :)
[19:29] <infinity> bdmurray: It's equally likely that it was a transient toolchain issue that's since been resolved and rebuilt, mind you.
[19:29] <slangasek> micahg: so I think I actually don't care enough to load the links if you do ;)
[19:31] <micahg> slangasek: k, it's only ~200 lines against the last lm-sensors upload, so not so bad, thanks
[19:36] <awkisopen> How the heck are you guys gonna fix 54 bugs before the 29th
[19:38] <roadmr> ... by averaging 4.909 a day :)
[19:39] <awkisopen> .909? I guess the other .091 is committing
[19:39] <micahg> awkisopen: patches welcome :)
[19:40] <awkisopen> someday I'll figure out a way to give back to Ubuntu, I swear
[19:47] <infinity> awkisopen: Cookies.
[19:49] <slangasek> not that I think 54 bugs between now and the 29th is unrealistic, but I don't know what 54 bugs you're talking about or why the 29th is a deadline :)
[19:49] <slangasek> so what's special about the 29th?
[19:50]  * charlie-tca was wondering that too
[19:51] <infinity> slangasek: You weren't planninh on having a "6 days before Alpha-3" party?
[19:51] <infinity> slangasek: Cause I already bought balloons and sparklers.
[19:51] <stgraber> ;)
[19:52] <slangasek> infinity: actually that was the day I was going to prove upstart is better than systemd, didn't realize there was a party that day - perhaps I'll have to juggle my schedule
[19:53] <awkisopen> Isn't the 29th when 10.04.3 comes otu?
[19:53] <awkisopen> *out, even
[19:53] <awkisopen> That's what I was referring to, anyway
[19:53] <infinity> That's the 21st, in theory.
[19:54] <awkisopen> https://launchpad.net/ubuntu/+milestone/ubuntu-10.04.3 says "expected: 2011-07-29"
[19:54] <infinity> Oh, fair enough.  Perhaps someone juggled it.
[19:54] <stgraber> awkisopen: https://wiki.ubuntu.com/LucidReleaseSchedule says 21st
[19:54] <awkisopen> oh no now I'm confused :(
[19:54] <awkisopen> I had my calendar marked for the 29th for months
[19:55] <awkisopen> I'd be thrilled if it were indeed only 3 days from now
[19:57] <sconklin> slangasek: any thoughts on what might be behind this? https://bugs.launchpad.net/ubuntu/+source/linux/+bug/811999
[19:58] <sconklin> there are more than just that one, possibly all duplicates
[19:59] <bdmurray> sconklin: I've been cleaning those up
[19:59] <bdmurray> sconklin: its something wrong with the .deb on the user's system
[19:59] <infinity> dpkg-deb (subprocess): data: internal bzip2 read error: 'DATA_ERROR'
[19:59] <infinity> Definitely corruption or a short file, but...
[19:59] <infinity> Ew.
[20:00] <sconklin> ok. Well, here's a list to start with - sorry there are two of each one. Scripting bug.
[20:00] <sconklin> http://people.canonical.com/~sconklin/reports/regressions.html
[20:00] <sconklin> almost all the Natty ones appear to be this problem
[20:00] <bdmurray> sconklin: okay, i'll take care of them
[20:00] <infinity> We could do a better job of verifying files before apt calls dpkg, surely?
[20:01] <slangasek> awkisopen: ah yes, I suspect the milestone in launchpad didn't get updated when the schedule changed; it's unfortunately not somethign that tends to be at the forefront of people's minds.  As for 54 bugs, most of the bugs linked from the milestone are already fixed or "fix committed" (meaning the SRU is pending final publication), and a number of the others will likely not make the deadline.
[20:02] <slangasek> infinity: maybe we do now, and didn't then?
[20:02] <awkisopen> slangasek: Cool. I was wondering how it all worked. So you're saying it's likely that 10.04.3 is coming out on the 21st?
[20:03] <infinity> slangasek: Yeah, things are probably much improved since yesterday when the bug was filed. ;)
[20:03] <slangasek> infinity: it was filed against natty :P
[20:03] <infinity> (I know)
[20:03] <slangasek> actually, I guess that means it's unlikely to have been fixed since, doesn't it
[20:04] <slangasek> it is strange to have an uptick in such reports in natty
[20:05] <infinity> Well, it could be symptomatic of something else going pear-shaped (filesystem drivers, network issues, or heck, maybe some massive ISP just started doing broken transparent proxying six months ago)
[20:05] <infinity> But none of that changes that we should probably be doing at least trivial checks on downloaded debs before passing them off to dpkg.
[20:11] <doko> bdmurray: bug #812507, people start to translate the -fsys-tarfile :-(
[20:12] <bdmurray> doko: hrm
[20:22] <geser> persia, maco: a status mail how far we are with ArchReorg would be helpful, I don't know either what the next step would be
[20:22] <maco> agreed
[20:23] <maco> we have package sets!  ....the end
[20:23] <maco> all i got
[20:25]  * persia wants to wait until after the DMB meeting is over, and there has been a chance to renew hydration, and then will blather for a bit (but I'm unprepared, so I may not be able to give entirely authoritative answers)
[20:26] <slangasek> doko: doh.  Can you file a bug on the translation for that?  Since obviously commandline arguments shouldn't be translated
[20:26] <geser> persia: no problem (and no hurry), I would be happy to even get some unauthorative answers
[20:36] <doko> slangasek: hmm, which package
[20:36] <dupondje> What happends with the idea to have a 'testing' repo in Ubuntu ?
[20:41] <persia> dupondje: Someone raises it every couple years, and then it never happens.
[20:41] <slangasek> doko: I don't know, I figured you're in a better position to work that out than I am since you might actually have german language packs installed :-)
[20:41] <persia> The original setup has some philosophical basis that I've forgotten, but nobody has yet put up a strong enough arguments to overcome inertia (if that can be done)
[20:42] <infinity> doko: looks like dpkg.mo to me.
[20:42] <doko> slangasek: well, maybe ... the language packs itself don't help much
[20:43] <persia> maco, geser: So, ArchiveReorganisation has two aspects: Permissions and Components.
[20:43] <persia> Permissions: https://wiki.ubuntu.com/ArchiveReorganisation/Permissions
[20:43] <infinity> (or so says "grep -r fsys-tarfile /use/share/locale")
[20:44] <persia> This is largely done, except that is a need for Soyuz to grow a default packageset, and to stop using components as part of Ubuntu permissions.
[20:44] <infinity> slangasek: And "I have no langpacks" isn't much of an excuse, dpkg is fully translated without. :P
[20:44] <persia> There was a UDS spec about it, and jml wrote up some notes, and someone needs to review the notes, file some bugs, file an LEP, and set aside some time to help implement it.
[20:44] <geser> persia: do we have enough packagesets or need some more need to be created to cover what we currently have?
[20:45] <persia> geser: More packagesets are useful if there are developers for them.
[20:45] <slangasek> infinity: that message isn't in the de/dpkg.mo
[20:45] <slangasek> infinity: at least not in oneiric
[20:45] <persia> And some packagesets need cleanup work (the server set is particularly in need of gardening)
[20:45] <infinity> adconrad@cthulhu:/usr/share/locale$ grep -r Tar-Dateisystem /usr/share/locale && dpkg -S /usr/share/locale/de/LC_MESSAGES/dpkg.mo
[20:45] <infinity> Binary file /usr/share/locale/de/LC_MESSAGES/dpkg.mo matches
[20:45] <infinity> dpkg: /usr/share/locale/de/LC_MESSAGES/dpkg.mo
[20:45] <infinity> slangasek: Probably fixed already, then.  It's there in natty.
[20:46] <persia> Components: https://wiki.ubuntu.com/ArchiveReorganisation/Components
[20:46] <slangasek> infinity: false positive, do it properly with msgunfmt :)
[20:46] <geser> persia: should we continue to "push" people into package sets upload right where applicable?
[20:46] <persia> THis is much less well along.  It needs identification of all the various uses of "main", and assurance that we have a solution that doesn't rely on "main" to move forward.
[20:47] <persia> geser: Where applicable, yes.  Any specialist develolper team should probably have a packageset.
[20:47] <maco> persia: do we need an "old-universe" package set so that the-people-formerly-known-as-motu can be grandfathered into their packages instead of losing them when they get added to xubuntu-desktop or whatever else?
[20:47] <persia> I don't think we care if large chunks of the archive are outside packagesets, if some team to care for them doesn't organically appear.
[20:47] <slangasek> infinity: the hits only translate the usage message for --fsys-tarfile, not the option itself (including in natty)
[20:47] <persia> maco: At the UDS session, bigjools wanted that to be called "default"
[20:48] <maco> i thought at UDS Dallas "motu take care of teh long tail  of not-in-a-packageset packages" was what was said
[20:48] <maco> gosh was that dallas or barcelona? ....meh
[20:48] <geser> persia: belong package sets to "Permissions" or "Components" or both?
[20:48] <persia> maco: And MOTU are intended to lose access when things move into packagesets: if they want to keep working on those packages, they should join the relevant teams.
[20:48] <infinity> slangasek: Oh, indeed.  That's a message about a corrupted archive.
[20:48] <persia> Membership in many development teams should be an indicator that someone ought be core-dev.
[20:48] <infinity> slangasek: The other one might be apt, come to think of it.
[20:49] <cjwatson> bdmurray: sure ...
[20:49] <persia> geser: Mostly permissions, although permissions was the largest of the meanings of "main" towards Components.
[20:49] <persia> maco: Dallas
[20:49] <micahg> cjwatson: got a minute?
[20:49] <slangasek> infinity, doko: actually, the "subprocess dpkg --fsys-tarfile" message should *always* be untranslated, because it's the name+args of the process so dpkg never passes it to gettext for translation... so no bug here, I think
[20:50] <slangasek> infinity, doko: the text message explaining what went wrong will be translated, but that's correct
[20:50] <slangasek> msgid "corrupted filesystem tarfile - corrupted package archive"
[20:50] <slangasek> msgstr "defektes Tar-Dateisystem - Paketarchiv ist defekt"
[20:51] <persia> So, for components, I've done some of the research, and found "supported", "translated by rosetta", "receives priority attention by the security team", "undergoes security review", "undergoes code review", "undergoes maintainabilty review"
[20:51] <geser> persia: the "Permissions" part moved forward with increased use of package sets, did the "Components" part moved forward too in the last months?
[20:51] <bdmurray> so bug 797968 is the highest numbered bug I've found with "Bus error"
[20:51] <cjwatson> dupondje: I'm pretty sure it will never happen.  I suggested it before Ubuntu was even created. :-)
[20:51] <cjwatson> micahg: only if you warn me what it's about
[20:51] <persia> I've also found a number of others which were nascent, and could be converted to packagesets before they got too far (like freeze definitions).
[20:52] <persia> geser: I don't know of any work done in ArchiveReorganisation since March, which was me interviewing lots of stakeholders about "support".
[20:52] <infinity> slangasek: Hrm.  So, we're just seeing a different return on that bug report?
[20:52] <micahg> cjwatson: I uploaded lm-sensors, I thought it would be stuck in Binary NEW since it's a different source providing binaries, but it doesn't seem to be the case
[20:52] <slangasek> infinity: maybe
[20:52] <persia> I was unable to find an acceptable consensus, and am not personally working on AR for a while because that was frustrating.
[20:52] <infinity> slangasek: (ie: not the "subprocess dpkg had a sad" return)
[20:52] <micahg> cjwatson: I just don't want to break the world with a component mismatch
[20:52] <cjwatson> micahg: https://launchpad.net/ubuntu/+source/lm-sensors/1:3.3.0-4ubuntu1 says it's accepted
[20:53] <cjwatson> micahg: the only thing that goes through NEW is when the source/binary package name in question doesn't have an override
[20:53] <cjwatson> LP doesn't care (much, and not at this level) if one source takes over another source's binaries
[20:53] <persia> Oh, for Components, "mirroring" is another important thing to be sorted.
[20:54] <geser> persia: so AR will stay in the current state until the pressure rises again to move it forward?
[20:54] <micahg> cjwatson: ok, can you switch lm-sensors for lm-sensors-3 in core and promote to main?
[20:54] <cjwatson> micahg: sure, tomorrow
[20:54] <cjwatson> it won't break things tonight AFAIK
[20:54] <persia> geser: As with everything in Ubuntu, if nobody works on it, nothing happens.
[20:54] <micahg> cjwatson: ok, thanks, as long as it doesn't break stuff, I don't care much when it happens, thanks :)
[20:55] <persia> I don't think it's fair for me to make a blanket statement about the progress of AR.
[20:55] <maco> persia: by mirroring, do you mean the /pool/main/blahblahblah paths?
[20:56] <geser> maco: more likely $country.archive.ubuntu.com
[20:56] <persia> maco: Rather, that some mirrors have limited disk space and/or bandwidth.  We would need a way for mirrors to mirror packages based on packagesets or flavours, rahter than main/universe.
[20:56] <maco> ah ok
[20:56] <persia> geser: $CC.archive.ubuntu.com is always a full mirror, so those aren't as affected.  It's the smaller mirrors, private mirrors, etc.
[20:57] <micahg> cjwatson: do I need to file any paperwork for this since it's just a source rename?
[20:57] <cjwatson> no
[20:59] <dupondje> Nobody happen to have a Intel Centrino Advanced-N 6230 ?
[20:59] <micahg> dupondje: you might want to try askubuntu.com
[21:00] <persia> geser: maco: Other questions, or do you feel you understand the current status to the degree you wish?
[21:00] <geser> persia: thanks for the description of the current AR state, it really helped me to understand where we currently are with AR
[21:01] <persia> geser: Please, feel free to ask my anytime.  I try to keep track of AR, and help new processes be AR-compatible, and really hope me taking a break doesn't mean we make no progress for a while.
[21:01] <maco> persia: well, you said "help would be welcome"
[21:01] <maco> persia: how do random non-canonifolk help?
[21:02] <maco> i assume some stuff just plain requires IS involvement, for example
[21:02] <maco> (which reminds me: omg the other day IS responded to an RT ticket the SAME DAY)
[21:02] <persia> maco: You could pick up the Soyuz stuff where I left off (I'll dig up the detail status for you if you like).  You could interview folk for "support", but from my experience, I believe that needs Canonical folk.
[21:02] <persia> (as I'd hate to share my frustration)
[21:03] <maco> yeah uh....launchpad's code scares me
[21:03] <nigelb> heh
[21:03] <persia> Someone needs to tackle translations: understand the infrastructure, envision how it might work without "universe", write up an LEP and a blueprint for UDS.
[21:03] <nigelb> it scares everyone who's touched it too.
[21:03] <geser> I also get the impression that for a community member it's hard to help with AR in the current state as it needs planing through complete Ubuntu and also LP
[21:03] <persia> Replacing MIRs is probably blocked by "supported".
[21:04] <micahg> persia: there was a recent fix to allow translations for non-main packages in laucnhapd
[21:04] <maco> persia: creating a "supported" package set just means poking cjwatson, though, doesn't it?
[21:04] <maco> he seems to be keeper of the keys of packagesets
[21:04] <sgnb> can someone here rebuild obrowser and ocaml-sqlexpr (with no changes, recompile with lwt 2.3.0-3)?
[21:04]  * maco was surprised to learn the DMB cannot use edit-acl.py to add devs to packagesets after voting on them
[21:05] <sgnb> bdrung: ^^^
[21:05] <persia> geser: I've never found anything blocked because I'm not Canonical, although there are enough different Canonical stakeholders for "supported" that I'll admit I gave up.
[21:05] <sgnb> (it should allow compilation of ocsigen)
[21:05] <geser> maco: s/cjwatson/TB/ as any TB member can create package sets (if there is a consensus for the creation)
[21:06] <cjwatson> there is a bit of packagesets that's currently SPOF me
[21:06] <maco> SPOF?
[21:06] <cjwatson> single point of failure
[21:06] <persia> maco: It's more than packageset.  Currently "supported" is defined by a header in the Packages files, but doesn't actually represent a commitment by anyone (other than prioritisation by the Ubuntu Security Team) to actually provide any sort of "support".
[21:06] <cjwatson> supported would be pretty hard to maintain as a single giant packageset
[21:06] <maco> oh, so nothing to do even with canonical support contracts?
[21:07] <cjwatson> but yes, the problem is a definitional one anyway
[21:07] <persia> maco: There are notes on what is needed, and the code isn't much (add debtags support to Muon/Software Centre, define support in debtags, publish), but it first requires there existing lists of packages that are considered "suppoorted" by organisations, Canonical being the largest sponsor of Ubutnu Developers obviously is a priority stakeholder here.
[21:07] <persia> maco: Support contracts by various entities (not just Canonical) is part of it, but it's complicated.
[21:08] <geser> maco: you mean add PPU with edit-acl.py or add packages to an existing package set or add dev to the upload team of a package set?
[21:08] <maco> geser: i think it was add PPU for a packageset to a dev
[21:08] <maco> im not sure if that's the first or the third thing you said :P
[21:09] <cjwatson> geser: any of the package sets that are automatically generated by seeds can only be extended (as in packages added to it) by me right now; fixing this is some kind of priority, along with everything else ...
[21:09] <persia> I think this is a murky undefined corner of AR/Permissions.  My understanding is that the DMB is supposed to declare packagesets into existence, and that the Archive Admins are supposed to control which packages are in which packagesets.
[21:09] <geser> don't we usually add a team which can upload the packages from that package set and the DMB can administer that team?
[21:09] <persia> Oh, the DMB is also supposed to decide who has upload to which packagesets.
[21:09] <cjwatson> granting a developer upload access to a package set should be doable by the DMB.  if you can give me a concrete example then I can investigate why
[21:09] <cjwatson> geser: we haven't always bothered for small cases
[21:10] <maco> cjwatson: its possible i was doing it wrong but let me try to find who it was
[21:10] <persia> But this is inherited from N discussions in a changing landscape over the years (DMB didn'T exist when we agreed AA would chose which packages go where), and probably needs a dedicated new discussion to come to consensus.
[21:10] <cjwatson> it is possible that "doable by the DMB" only works for the team-upload case
[21:10] <maco> s/possible/likely/ :P
[21:10] <cjwatson> but anyway the fundamental problem is that the DMB does not have any special status in LP, unlike techboard
[21:11] <geser> persia: isn't package set creation TB land which was sort of delegated to DMB?
[21:11] <dtchen> sgnb: done
[21:11]  * geser checks the wiki
[21:11] <micahg> well, IIRC, the DMB owns two packagesets which it should be able to make modifications to if I understand correctly
[21:11] <cjwatson> and we sort of hacked around that by just saying "OK, the TB will do the mechanics for you on request"
[21:11] <persia> geser: Yes, but nobody ever said anything about authority over the packageset contents.
[21:11] <sgnb> dtchen: thanks!
[21:11] <maco> cjwatson: it was John Rigby's application for the linux-linaro-* packages that i was trying to follow up on
[21:11] <cjwatson> maco: if you can't do it, just mail it to the TB
[21:11] <cjwatson> sorting it out any other way will be a long road :-/
[21:12] <persia> Needs doing, but not anything we should block upon.
[21:12] <maco> cjwatson: its been fixed now. was about a month ago. but i dont know whether i used edit-acl.py wrong or if its just not doable by dmb
[21:12] <geser> maco: all we (the DMB) can do is add members to DMB-administered teams and add packages to DMB-owned package sets, the remaining task need to go to the TB
[21:12] <maco> and i'm *pretty* sure my bash.history isnt that long
[21:13] <maco> geser: ok
[21:13] <maco> so should we make it a habit of making teams to match when we make new packagesets?
[21:13] <persia> Considering that AA always took care of components, we probably ought adjust packageset change permissions to be union of DMB and AA or similar.
[21:13] <cjwatson> yes.  but that is Hard.
[21:14] <cjwatson> (AIUI.)
[21:14] <persia> Unless we expect the DMB to take over regular migration of stuff for transitions, etc.
[21:14] <cjwatson> maco: it's probably the most practical approach
[21:14] <persia> cjwatson: It's hard to have a union of teams.  It's not hard to have a team with membership limited to AA+DMB that owns the packageset.  That said, it needs discussion and consensus before being done.
[21:15] <maco> cjwatson: so then we just ask the TB "can you make packageset $name with packages x,y,z and permissions to $team" and then never have to bug you about that packageset again (for the most part...until it needs a new package)
[21:15] <persia> When we approve a PPU, does this necessitate the creation of a packageset?
[21:15] <maco> persia: we often vote to create a packageset if the set being requested seems reusable or is copied off someone else and is therefore obviously being reused
[21:17] <persia> maco: Right, when there is a team.  My concern is that we grant packageset teams exclusive authority over packages unique to their packagesets (which is why packageset teams are required to have core-dev as a member).
[21:17] <maco> persia: i did not know of this requirement
[21:17] <micahg> persia: in terms of Archive Reorg, I don't think PPU should have a packageset
[21:17] <persia> This is incompatible with our statement that we *do not* grant exclusive authority over packages for PPUs, once MOTU is implemented as the inverse of all packagesets.
[21:18] <geser> maco: if the package set is DMB-owned (some are like mozilla, zope and some others) the DMB can add and remove packages from it once the TB created the package set
[21:18] <persia> maco: Failure to abide by the requirement today has a low penalty, as Soyuz still supports component-based permissions.
[21:18] <maco> so we're seeing graceful degradation
[21:18] <persia> Although for *flavour* packageset teams, it has been strictly enforced, because it affects seed branches.
[21:19] <maco> geser: i'm actually concerned with adding *devs* to it, not so much packages
[21:19] <maco> i think adding devs is a hopefully-more-frequent occurance
[21:19] <persia> maco: For PPUs, yes.  On the other hand, we're not actually granting most packageset teams what we promise we've granted them.
[21:20] <maco> persia: packagesets arent supposed to be *totally* exclusive though right? because generalist is still supposesd to have access, except to restricted packagesets which would then only be core devs
[21:20] <maco> is the restricted/unrestricted bit not implemented yet?
[21:20] <persia> maco: No.
[21:20] <maco> (or rather, only core devs + team members)
[21:20] <geser> maco: package sets can overlap (and do it)
[21:20] <persia> Restricted packagesets are supposed to be totally exclusive.  We should celebrate that our community is cooperative enough to not need any today.
[21:21] <infinity> Wait, wait, wait.
[21:21] <maco> kernel isn't restricted?
[21:21] <infinity> Someone actually specced exclusive package sets?
[21:21] <persia> Unrestricted packagesets are supposed to be exclusive to the packageset team (although packagesets can overlap, so specific packages may not be exclusive), which is why the teams are supposed to have core-dev as a member.
[21:21] <infinity> Should I point out that this was the one huge problem I had with Maemo? :P
[21:21] <persia> infinity: Yes.
[21:22] <geser> maco, persia: wasn't the plan to "merge" core-dev and motu to generalist which have access to all package sets (except a few one like the kernel where even core-dev isn't enough)?
[21:22] <persia> infinity: So, we don't have any today.  They are in reserve because some folk felt that we might have a social problem with some of the initial theories about implemenation of Archive Reorganisation.
[21:22] <maco> https://wiki.ubuntu.com/ArchiveReorganisation/Permissions  <-i'm re-reading this
[21:23] <persia> geser: Yes, there was a plan to make every MOTU core-dev.  Nobody executed the plan (athough cjwatson and dholbach did interview just about everyone towards implementing it).
[21:23] <geser> persia: right, I remember that interview, was the result of it ever published?
[21:23] <persia> geser: When the TB approved keeping MOTU as folk who specifically didn't have upload access to anything in any packageset, as a place for folk interested in general QA to play, that changed.
[21:24] <maco> ok so reading that, generalist replaces core dev?
[21:24] <persia> Masters of the Unseeded has considerably less upload authority than Masters of the Universe, but enough folk (including me) wanted it that we have it approved.
[21:24] <micahg> It makes sense as there will still be a ton of packages that no one will explicitly care about
[21:24] <persia> maco: I don't believe anyone currently still wants to rename "Ubuntu Core Developers" to "Ubuntu Generalist Developers", although that was once planned.
[21:25] <persia> micahg: The alternate assertion is that everyone should be core-dev if they want to be a generalist.  I'm not convinced this makes it easy for new generalists to build reputation, but I'm not sure this opinion is consensus.
[21:26] <micahg> persia: I think that raises the bar on who can be a generalist then which would hurt the part of the archive no one explicitly cares about
[21:26] <persia> And just to be clear: I don't know of any "secret" discussions about AR that have happened since ~2008 (when there were some invite-only phone calls between the MC and TB).
[21:27] <maco> micahg: i think the "no one explicitly cares" part is the Masters of the Unseeded, not the generalist
[21:28] <persia> micahg: Then you share my opinion.  The counter argument is that we should be seeking to attract developers in areas where we have a demonstrated passion, and that once their skills are honed, it is safe to give them access to packages fewer people are watching.
[21:28] <geser> isn't MOTU sort-of generalist too (currently)?
[21:28] <micahg> maco: that's what I was commenting on, the necessity of that
[21:28] <persia> geser: Yes.
[21:28] <maco> geser: yup
[21:28] <maco> geser: oh oh maybe its Novice Generalist and then core dev is Advanced Generalist? :P
[21:29] <persia> In the original formulation of Archive Reorganisation, MOTU was to be abolished, and all current MOTU were to be strongly encouraged to become core-dev.  The new MOTU is entirely different than the old MOTU, except that it shares the name, and all historical members of MOTU were grandfathered as members initially (I thought I sent a long mail about this, entitled "Future of MOTU" back when the TB approved this)
[21:29] <persia> maco: Err, no.  We don't want any semantics that imply that one category of developer is more "Novice" or "Advanced" than another.
[21:30] <infinity> I honestly think trying to split those two roles is overengineering for a problem we don't actually have.
[21:30] <persia> We're all "Ubuntu Developers", and anything else is just a reflection of our interests.
[21:30] <persia> infinity: Which two roles?
[21:31] <infinity> Debian's done fine for years with 1000 people who are essentially "core-dev", and they don't randomly upload GCC for the hell of it, though they CAN.
[21:31] <cody-somerville> infinity, Its also much harder to become a DD.
[21:31] <infinity> persia: Trying to have "people who care about lots of packages, but not core" and "people who care about core, but not lots of other packages", as if A or B will mess with each other somehow.
[21:32] <infinity> cody-somerville: *shrug*... It's also simple to revoke privileges to someone who screws up a development release via touching things they don't understand.  And no one can screw up a stable release without it passing by several checks.
[21:33]  * cody-somerville coughs.
[21:33] <micahg> infinity: I think it's more about people that have demonstrated care for the archive, but not yet demonstrated ability with core packages
[21:33] <persia> infinity: All true, and likely the basis for the argument that all generalists should be core-dev.
[21:33] <infinity> micahg: People who care deeply about the archive will know if they shouldn't be touching glibc.
[21:33] <cody-somerville> they might not know how to version an SRU though
[21:34] <infinity> cody-somerville: And I know how to reject packages.  So?
[21:34] <persia> infinity: As one of the folk involved in the ressurection of MOTU, our motivation was that there were lots of people who didn't feel they *should* be core-dev who were contributing useful random fixes to arbitrary packages.
[21:34] <cody-somerville> infinity, the problem is when the archive admin doesn't know how to either and accepts it :P
[21:34] <infinity> persia: Sure, I suppose there are people who don't want the "pressure" (?) of being allowed access to "scary stuff", but is it so hard for them to just refuse to upload those packages? :)
[21:35] <infinity> persia: I don't upload toolchain bits on a whim, but I'm glad that I can when there's an emergency that requires it.
[21:35] <infinity> cody-somerville: Not a team/permissions problem then, but an AA problem.
[21:35] <infinity> cody-somerville: (And when that happens, please bring it up, so we can hunt down the offending AA and make sure we're all on the same page)
[21:36] <sladen> I think peer-pressure mainly deals with the occasions when you do an upload and screw up.  The permissions are somewhat of a technical solution to a social problem
[21:36] <persia> sladen: Yes, indeed. *but* given the history of Ubuntu, there was also a fair amount of social identity wrapped around "MOTU", which then members were unhappy about having removed when it was announced that MOTU would be no more.
[21:37] <infinity> sladen: Jinx.  I just used "technical solution to a social problem" in a /msg to persia. ;)
[21:37] <persia> infinity: Yeah, well.  I'm not sure we don't do well to cater to the inconfident.
[21:38] <slangasek> I am going to burn that phrase in effigy
[21:38] <slangasek> there are lots of social problems that should be solved with technical solutions
[21:39] <slangasek> (I have not read the scrollback so I have no idea whether it's appropriate here, but grrr that makes me mad :)
[21:39] <infinity> slangasek: Heh.
[21:40] <infinity> slangasek: I agree that there are plenty of social problems that are readily solved by technical means.  Just not sure the current discussion is about one of them. ;)
[21:40] <persia> slangasek: As with every use, it is both appropriate and not.
[21:41] <infinity> Well, the current meta-discussion, wherein some things are definitely things that can be addresses technicaly, and some are not.
[21:41] <slangasek> democracy: a technical solution to a social problem
[21:41] <slangasek> debit card PINs: a technical solution to a social problem
[21:41] <slangasek> ;)
[21:41] <infinity> (Making it progressively harder and harder for people to upload packages because you're afraid that one clueless developer will upload glibc is a losing battle)
[21:42] <bjf> @pilot out
[21:42] <bjf> @pilot out
[21:42] <slangasek> infinity: true
[21:42] <persia> Hrm?  I argued for the creation of the new MOTU.  I never intended that to be something that would make it harder to get access to other stuff.
[21:43] <persia> We've historically been stingy about access to stuff that appears in images, and I don't think our standards for that have changed much.
[21:43] <persia> The idea is to make it *easier* to get access to other stuff, if one is so inclined (but anyone who applies for MOTU who doesn't have a QA bent is probably applying for the wrong thing).
[21:45] <persia> (in fact, the creation of the DMB probably makes it *easier* to be core-dev, as one no longer needs to undergo two interviews with two separate bodies, as one did from 2007-2009)
[21:46] <persia> (with several promising candidates being approved at the first and denied at the second, or denied at the first, blocking the ability to apply at the second)
[21:46] <slangasek> is that reflected in the numbers regarding time in queue for core-dev?
[21:47] <geser> queue time for core-dev?
[21:47] <slangasek> from application to approval
[21:47] <persia> I'm not sure I understand "time in queue for core-dev".
[21:47] <persia> Oh, certainly.
[21:47] <persia> Used to be a 4-6 week process at the fastest.
[21:48] <slangasek> really?  no one I've talked to lately has found the current DMB process anywhere near that fast :)
[21:48] <persia> DMB has had some issues with meetings, but tends to be able to approve folk within a month the majority of the time.
[21:48] <persia> slangasek: How do they measure?  From announcing their application to review, or some some other boundary?
[21:48] <maco> i think we've only missed one meeting since march or so, and that was the Fourth of July
[21:49] <geser> slangasek: we have recently problems to get quorum at the "early" meeting but that applies to all applications and not only core-dev
[21:49] <slangasek> persia: that's what I'm going by, yes
[21:49] <slangasek> geser: right
[21:49] <maco> ugh yes and now the early meeting clashes with my commute (boss says now i must be here at 10, not 11, so now i have to leave home about 15 minutes after meeting starts... so i guess those mondays i get to go to work an hour early...)
[21:50] <slangasek> it's possible my info is already dated; I was going by comments from March-ish
[21:50] <maco> ah yeah in feb/march we had issues then moved the early meeting time by an hour
[21:51] <stgraber> yeah, the early timeslot is always the issue, even since the change, the only meeting without quorum was an early one. Though the new time is definitely an improvement for me (as in, I can attend it now)
[21:52] <geser> maco: mail the DMB and check with the other if we could move it again if it helps to reach quorum
[22:55] <Laney> Compared to NM, DMB applications are a breeze :-)
[22:55] <Laney> also I asked in a postscript to my bzr packageset mail whether we should be asking LP to give the DMB packageset administration rights