[01:43] <soultekkie> http://brainstorm.ubuntu.com/idea/28233/ << vote if you like the idea
[02:00] <Chipzz> soultekkie: have you thought this through?
[02:00] <Chipzz> soultekkie: ubiquity simply copies the content of the livecd
[02:01] <Chipzz> which would mean you would need to have both unity and gnome3 on the livecd
[02:01] <RAOF> Well, that's a simple matter of programming.  More to the point, offering options like that in the installer is not philosophically aligned with what we want to do.
[02:01] <Chipzz> which I doubt is an option, given that the available space is constantly an issue
[02:02] <Chipzz> RAOF: it's not. not for ubiquity
[02:02] <Chipzz> RAOF: it is an option for the alternate install cd, ok
[02:03] <RAOF> Chipzz: If we *wanted* to do it we could without too much trouble.  We already (optionally) install packages from the internet during install.  I just don't think we want to do it.
[02:04] <TheMuso> And given that classic GNOME 3 is rather different to GNOME 2...
[02:04] <Chipzz> RAOF: that sounds more like a gross hack to ubiquity than "a simple matter of programming" though ;)
[02:06] <lifeless> given ubiquities deep roots in d-i, not really.
[02:06] <Chipzz> it would probably still qualify as "gross" though (IMO) ;)
[02:07] <RAOF> As I say, we *already* do it.  It would presumably be simple to extend.
[02:07] <Chipzz> I can see where it makes sense for things like nvidia drivers etc
[02:07] <Chipzz> or certain network drivers
[02:07] <Chipzz> because you need those to have a proper functioning system
[02:09] <lifeless> network is one of the least sensible :)
[02:09] <Chipzz> heh. right :)
[02:09] <Chipzz> that just dawned upon me
[02:10] <Chipzz> unless you have both wired and wireless and it's the wireless network driver you need
[02:10] <Chipzz> or vice versa
[02:10] <StevenK> "Let's connect to the Internet so we can download a driver, so you can connect to the Internet." Oh.
[02:11] <Chipzz> StevenK: "04:10 < Chipzz> unless you have both wired and wireless..."
[02:11] <StevenK> Don't assume the wired works either :-)
[02:23] <RAOF> Could an archive admin please reject pyabiword from natty-proposed?
[02:24] <TheMuso> The classic phrase comes to mind... "I would if I could, but I can't."
[02:24] <RAOF> There's a StevenK here, right? :)
[02:24] <TheMuso> Oh right.
[02:26] <StevenK> RAOF: pyabiword/0.8.0-6build2 Component: universe Section: python ?
[02:27] <RAOF> StevenK: Yes please.
[02:27] <StevenK> RAOF: Rejected.
[02:28] <RAOF> Ta muchly.
[02:35] <soultekkie> I think ubuntu will lose many users by going "unity" only.and btw Gnome# is so great it can be used as is or with the classic look&feel
[02:35] <soultekkie> *gnome3
[02:52] <scialex> soultekki, im not so sure. its a WIP but its got potential
[02:56] <TheMuso> @pilot out
[02:59]  * micahg sees there's not much left in the sponsoring queue, will try to drive it down further in a little bit
[04:15] <pitti> Good morning
[04:30] <pitti> micahg: seems scarneiro now fixed all the opendrim packages, these seem easy
[04:54] <micahg> pitti: they're all ready to go in?
[04:54] <pitti> micahg: it's the same FTBFS fix for all of them, and it was fixed properly now
[04:55] <pitti> just pointing out if you want to do some 10 queue items with relatively little effort
[04:55] <micahg> pitti: sure, was about to go hunting for patches :)
[04:57] <micahg> @pilot in
[04:57] <micahg> pitti: do they have to go in any order?
[04:57] <pitti> micahg: I don't know these packages at all; but I suppose not
[05:01] <micahg> pitti: oh, ok, no worries, I'll figure it out
[05:20] <broder> micahg: i...don't ever think i've seen documentation telling me to update timestamps
[05:21] <broder> launchpad will still keep its own timestamps, right? so this is purely a changelog optimization?
[05:25] <micahg> broder: I did say try, not must :), but point taken, it does seem like changelog optimization to some extent, but the changelog is what ends up on the end-user's system, not the LP timestamp
[05:26] <micahg> when I started using bzr, I was trained to update timestamps, but maybe that was just for the release commit...
[05:26] <broder> i think i have a vague understanding of what you're trying to do, but whenever i've looked at timestamps in changelogs, i've only cared about them on the scale of months, so it seems weird to me to add this extra step i have to remember
[05:26] <micahg> maybe someone will make debcommit do it for you :)
[05:28] <micahg> broder: feel free to reply and say how pointless it is :), I don't mind being wrong
[05:33] <micahg> broder: Actually, I should've been more specific I was referring to when the day was off, not just the hour or minnute
[05:57] <pitti> (might as well lift the freeze now, a2 images aren't going to get any better)
[06:02] <poolie> broder, which timestamps would you be updating? in debian/changelog?
[06:02] <micahg> poolie: see my mail to ubuntu-devel
[06:19] <poolie> i see
[06:22] <didrocks> good morning
[07:06] <brendand> anyone know if the default for 'When the power button is pressed' was changed to 'Suspend' deliberately in Oneiric?
[07:07] <pitti> it's supposed to bring up a dialog with the shutdown/reboot/suspend/etc. options (works here)
[07:07] <micahg> @pilot out
[07:25] <dholbach> good morning
[07:26] <ronin___> good morning
[07:28] <dholbach> hey ronin___
[07:29] <ronin___> hi dholbach
[07:29] <ronin___> dholbech: Thank you for your reply
[07:30] <ronin___> dholbech: I sand another mail to you
[07:30] <dholbach> ronin___, great, I'll have a look in a bit
[07:30] <ronin___> dholbech: thank you
[07:42] <brendand> pitti - sure you haven't changed it manually? on all the default install i do it suspends
[07:42] <pitti> brendand: I have upgraded since natty, could very well be due to that
[07:43] <brendand> pitti - but the default should still be 'ask'? i'll file a bug if so
[07:43] <pitti> I think so; suspending doesn't make much sense, that's what the lid is for
[07:43] <pitti> if anything, it should default to powering off and asking
[07:43] <pitti> (for confirmation)
[07:44] <pitti> but the "power off/reboot/suspend" dialog makes sense IMHO
[07:51] <brendand> as far as i can tell gnome-power-manager is setting the default so i'll raise a bug there
[07:53] <pitti> brendand: should be gnome-settings-daemon
[07:54] <brendand> pitti - true that
[07:54] <brendand> pitti - thanks
[07:57] <brendand> pitti - bet it got borked by the gconf -> gsettings move
[08:05] <brendand> pitti - bug reported 806855. thanks
[08:06] <pitti> thanks
[08:28] <Quintasan> Good morning.
[08:36] <wzssyqa> how to rebuild it : https://launchpad.net/ubuntu/+source/ns3
[08:42] <didrocks> ScottK: hey, small question, is there any reason (other not nothing for now depends on it), that libboost-system1.46.1 and libboost-filesystem1.46.1 are in universe?
[08:53] <evfool> hi all, quick question: is it worth fixing software-center bugs now, as the interface seems like its being reimplemented with gtk3 and also been redesigned by mpt and other designers
[08:55] <mwhudson> is this a reasonable place to talk about dh_python2?
[08:56] <brendand> got somebody with a touchpad broken by update in natty, anyone know how to find last weeks version of xorg-xserver?
[08:57] <mvo> evfool: depeds on the bug, if its a small one its still worth fixing as we can backport it to 4.0. the gtk3 port is work in progress still, much is still missing s its good to have the gtk2 in good shape
[08:58] <evfool> thanks mvo
[09:00] <mvo> evfool: what bug do you have in mind?
[09:01] <evfool> small ui/usability fixes, like bug 802918, bug 802919 and bug 802920
[09:01] <evfool> mvo^
[09:02] <mvo> evfool: I think that is still fine, you can even do it in the 4.0 branch and I will merge it from there into trunk
[09:12] <mvo> brendand: hello! you update-manager bbattery_msg_part_hidden branch is ready for merging, right?
[09:12] <brendand> mvo - no, i have a problem where it hangs when any of the labels are hidden that i want to resize
[09:13] <brendand> mvo - hope i don't offend anyone here but gtk is pretty stupid at handling text wrapping
[09:13] <brendand> mvo - someone gave me an idea of how to finish it but not got time yet to check it out again
[09:14] <brendand> mvo - do you have a deadline?
[09:14] <mvo> brendand: iirc this got better with gtk3
[09:14] <mvo> brendand: no, deadline, no
[09:14] <brendand> mvo - that's cool, so the change might be even easier
[09:14] <brendand> mvo - it might be good if i wait until the gtk3 changes are done
[09:14] <mvo> yeah, exactly
[09:16] <brendand> mvo - is there a tracking bug for that in update-manager?
[09:16] <mvo> for gtk3?
[09:16] <mvo> there is a branch by evfool that I check out now :)
[09:17] <brendand> mvo - oh cool
[09:18] <evfool> mvo - my branch? for update-manager? don't expect anything from that, just ran the pygi converter, and got stuck, but pitti asked me to push it somewhere and when he'll have time he'll look at it ... but he's extremely busy
[09:20] <evfool> mvo: just wanted to experiment with porting from pygtk to pygi, but I was not able to handle it, so I though I'd leave it to more experienced people or wait until I gain some more experience
[09:20] <evfool> *were
[09:21] <mvo> evfool: aha, thanks anyway for the update, I have a look at it
[09:36] <benonsoftware> Hi all
[10:01] <mikey_> kees, RAOF or bryce: Hi, I got advised to direct a question I have to you last time I was on this channel. Basically I've been involved with writing a couple of very basic scripts / apps that use X to create a second X session on which to play games, as a workaround for Compiz and game clashes. As a strategy it works well but I'm finding it increasingly difficult to make work within the Ubuntu X session management f
[10:01] <mikey_> ramework. I was hoping I could talk to you to come up with some definite solution.
[10:06] <tjaalton> cjwatson: hey, I need a grub gfxpayload quirk in natty for lenovo L420, but I'm not sure where to get the information for the quirk line. any pointers?
[10:11] <slomo> doko: are you aware that the two binutils versions in sid from this month are not working well with valgrind? dlopen of a .so that was linked with new binutils (no matter if gold or normal ld) crashes valgrind: http://pastebin.com/qBrsiiTC
[10:12] <doko> slomo: lool pointed out an upstream fix
[10:12] <slomo> doko: want me to try the fix?
[10:13] <doko> slomo: sure
[10:13] <slomo> doko: where is it? :)
[10:13] <seb128> slomo, doko: the fix is in oneiric and verified to work
[10:14] <seb128> slomo, https://launchpadlibrarian.net/74573993/valgrind_1%3A3.6.1-0ubuntu1_1%3A3.6.1-0ubuntu2.diff.gz
[10:15] <slomo> seb128: thanks
[10:15] <seb128> slomo, yw
[10:21] <tjaalton> cjwatson: think I got it
[10:22] <RAOF> mikey_: #ubuntu-x would be the place to talk about that.
[10:22] <mikey_> RAOF: oh, ok
[11:14] <Amoz> dholbach, you still need someone to freshen up the packaging guide?
[11:14] <dholbach> Amoz, yes
[11:14] <dholbach> Amoz, somebody started work on bringing it more in line with the general design of the ubuntu pages but ran out of time
[11:14] <dholbach> Amoz, let me dig up the link again
[11:15] <Amoz> dholbach, I already have it
[11:15] <dholbach> oh, great :)
[11:15] <Amoz> I was trying some different approaches, but all of them seems unclean
[11:16] <Amoz> dholbach, and "ubuntu pages" refers to something like the wiki?
[11:16] <dholbach> let me see if Ronnie and daker are in awake in #ubuntu-locoteams - they did quite a bit of web ui stuff for loco.ubuntu.com
[11:16] <dholbach> Amoz, yes
[11:17] <dholbach> there's already a branch with all the css, we just need to find a good way to map the css classes(is that what it's called? :-)) I think
[11:18] <daker> hi
[11:18] <dholbach> daker, Amoz and I were talking about http://daniel.holba.ch/blog/?p=1026
[11:18] <Amoz> dholbach, I think the best way would be to redesign the html templates and let the django-light-theme (or what the name is) be untouched
[11:19] <Amoz> if that's possible
[11:19] <dholbach> Amoz, yes, and reuse those bits where possible
[11:19] <Amoz> yeah otherwise we have to do a lot of css restyling I think
[11:19]  * dholbach nods
[11:19] <dholbach> even if we do it gradually, like do big changes first and then fix small bits as we go would be sweet
[11:20] <dholbach> daker, does the approach generally sound sane?
[11:20] <daker> ok, is there any work being done on that?
[11:21] <dholbach> https://code.launchpad.net/~raoul-snyman/ubuntu-packaging-guide/new-colours/+merge/56010 was the first try (without using the ubuntu-website bits)
[11:21] <dholbach> apart from that there's no work in progress AFAIK
[11:21] <didrocks> @pilot in
[11:21]  * dholbach hugs didrocks
[11:22]  * didrocks hugs dholbach back (I won't be there next week for my patch pilot time, so swapping with today as nobody is there :))
[11:22] <dholbach> didrocks, nice :)
[11:22]  * daker checking the code
[11:23] <dholbach> Amoz, daker: should we maybe move to #ubuntu-website? (and whoever else is interested in retheming the packaging guide)
[11:23] <daker> yep
[11:31] <didrocks> dholbach: stupid question, but how can I reject https://code.launchpad.net/~ubuntu-branches/ubuntu/oneiric/gnome-desktop3/oneiric-201107061510/+merge/67055 ? I can only set it as merged/WIP
[11:32] <dholbach> didrocks, james_w can do it
[11:32] <dholbach> I think there's a bug open for changing that in the LP UI
[11:33] <didrocks> dholbach: ok, so apart from faking "merged", I can't make it disappear from the sponsoring list?
[11:33] <dholbach> WIP will make it go away from the list
[11:34] <tumbleweed> didrocks: you could delete the merge proposal too
[11:35] <didrocks> tumbleweed: not sure if james_w doesn't want to clean afterwards the new branches
[11:35] <didrocks> so yeah, WIP + comment then
[11:36] <tumbleweed> didrocks: aah, I've deleted some recently
[12:24] <cjwatson> tjaalton: you should be able to extract it from lspci and massage it into the format described in /usr/share/grub-gfxpayload-lists/blacklist/00_header
[12:24] <pitti> james_w: who can I poke to get lp:ubuntu/gvfs updated?
[12:26] <tjaalton> cjwatson: yeah, it should be fine now, just needs some testing
[12:26] <james_w> pitti, should be up to date in a few minutes
[12:26] <pitti> james_w: cheers!
[12:27] <pitti> is that something we can avoid happening somehow?
[12:27] <pitti> in oneiric we synced from Debian
[12:27] <pitti> but now we'll need to modify it again
[12:28] <james_w> pitti, in general you can ask in #bzr
[12:29] <james_w> but that problem shouldn't happen
[12:29] <evfool> mvo I have made some fixes for the 4.0 branch, and requested a merge to the 4.0 branch, I hope that's ok, and you can merge it in the trunk, if the fix's ok
[12:29] <james_w> it happens if you push --overwrite the branch
[12:29] <pitti> james_w: is that what syncing did?
[12:30] <james_w> pitti, nope
[12:30] <james_w> syncing should be fine
[12:32] <mvo> evfool: \o/ awsome! thanks!
[12:35] <barry> cjwatson: can you do the sync request in bug 806103 today?
[12:36] <pitti> I can sync it
[12:36] <barry> pitti: awesome, thanks
[12:37] <barry> pitti: that'll close out python-central on the cds!
[12:37] <pitti> yay
[12:45] <cjwatson> barry: that's what I get for intermittently checking IRC
[12:53] <ScottK> didrocks:  libboost-system1.46.1 and libboost-filesystem1.46.1 are only in Universe because nothing in Main needs them.
[12:55] <didrocks> ScottK: thanks for the answer :) I know at least it's not a blocker then
[13:19] <james_w> pitti, unfortunately it hit another (known) bug and so it won't be up to date
[13:36]  * psurbhi booted successfully from the first event-based initramfs on my laptop :) - just uploaded a ppa 
[13:37] <stgraber> yeah!
[13:37] <psurbhi> https://launchpad.net/~csurbhi/+archive/natty-initramfs
[13:37] <psurbhi> will not work for initrds that change the root device
[13:37] <psurbhi> that might need some modification
[13:38] <psurbhi> however should work otherwise
[13:38] <psurbhi> if not, i will definitely wait for bugs
[13:38] <psurbhi> :)
[13:38] <psurbhi> is there a way of filing for bugs for a ppa?
[13:38] <nigelb> Not yet
[13:38] <nigelb> just make a project if you want
[13:38] <psurbhi> ok
[13:38] <psurbhi> nigelb, thanks :)
[13:38] <nigelb> np :)
[13:41] <psurbhi> editing the description of how to try the ppa
[13:48] <psurbhi> any volunteers:
[13:48] <psurbhi> https://launchpad.net/~csurbhi/+archive/natty-initramfs
[13:49] <psurbhi> please follow the description at this ppa
[13:49] <psurbhi> i will wait for updates
[13:50] <stgraber> psurbhi: you may want to e-mail ubuntu-devel@lists.ubuntu.com to get more testers
[13:52] <nigelb> Also, blogging on the kernel blog might me a good idea
[13:52] <psurbhi> ok
[13:52] <psurbhi> stgraber, nigelb, thanks!
[13:53] <psurbhi> plan to make foundations team mates scape goats before i start attacking the ubuntu devel
[13:53] <psurbhi> :D
[13:53] <psurbhi> stgraber, which means i will wait for your input
[13:53] <psurbhi> :P
[13:54] <nigelb> heh
[13:54] <nigelb> then you'll have "psurbhi made my laptop to stop working!"
[13:54] <psurbhi> nigelb, hehee! if you follow the instructions, you are pretty much risk free
[13:55] <psurbhi> if not, you definitely are at a big risk
[13:55] <psurbhi> :D
[13:55] <psurbhi> whatever gurantees, never delete your initramfs that works
[13:55] <psurbhi> :)
[13:55] <psurbhi> use a temporary one and edit your grub command line
[13:55] <psurbhi> :)
[13:55] <psurbhi> do that and you will sail safely
[13:55] <nigelb> If were running Natty, I'd definitely give it a shot, but alas my machines run Lucid and Maverick
[13:55] <nigelb> need to upgrade the Maverick machines this weekend
[13:56] <psurbhi> nigelb, you could try it for maverick too really
[13:56] <psurbhi> i have tested it on maverick and natty
[13:56] <nigelb> In which case, trying on maverick now.
[13:56] <psurbhi> nigelb, thanks a lot!!!!
[13:56] <psurbhi> please remember not to install the ppa- but install the SOURCE
[13:56] <Laney> why didn't you just upload the source if it's that bad?
[13:57] <stgraber> psurbhi: hmm, I'll have to download and install a Natty VM then :) I only have Oneiric systems around.
[13:57] <psurbhi> stgraber ok!
[13:58] <psurbhi> Laney, I have uploaded the source
[13:58] <Laney> i mean somewhere other than a ppa
[13:58] <psurbhi> Laney, I haven't yet worked on the install scripts
[13:58] <psurbhi> yet
[13:58] <psurbhi> its not that bad yet!
[13:58] <psurbhi> ;)
[13:59] <psurbhi> Laney, let me upload the source somewhere too :)
[14:00] <Laney> psurbhi: I meant that if you don't want people to install it then you might as well /just/ upload the source to your webspace
[14:01] <Laney> PPAs are for distributing debs really
[14:01] <Laney> but YMMV :-)
[14:01] <psurbhi> Laney, yeah i agree with you
[14:02] <nigelb> Actually, in that case, just push it into a bzr repo
[14:03] <psurbhi> ok
[14:03]  * Laney shrugs
[14:04] <psurbhi> also kept the source as tar.gz here:
[14:04] <psurbhi> http://people.canonical.com/~surbhi/event-based-initramfs/
[14:04] <Laney> I was just trying to save users from accidently installing .deb :P
[14:04] <psurbhi> Laney, ack!
[14:04] <Laney> cheers psurbhi!
[14:14] <mvo> barry: silly question, but can you recomment a good python indent tool? I have a piece of old python code of mine that is really a broken tab/2,4 indent piece that I want to fix once and for all
[14:17] <mvo> barry: nevermind, I found reindent.py
[14:17] <ion> I use vim to fix broken indentation.
[14:17] <barry> mvo: yeah, i use emacs :)
[14:18] <ion> :set et sw=4 sts=4, :%retab
[14:18] <mvo> barry: emacs is too clever, it notces the 2 space indent in a class wanted to keep it
[14:18] <mvo> thanks ion
[14:18] <ion> (if i interpreted your message correctly)
[14:19] <mvo> ion: yeah, that is what I want, a global reindent of the whole file with 4 spaces
[14:35] <serge_> pitti: hi, regarding the ill-fated bug 790145, would you mind kicking the current qemu-kvm packages from lucid-proposed and maverick-proposed (they've been superseded) and accepting my new ones which sit atop the new -security versions?
[15:01] <bdmurray> mvo: I am looking at bug 803277 and an error message in the dpkgterminallog.txt regarding update-alternatives
[15:01] <bdmurray> mvo: update-alternatives: error: /var/lib/dpkg/alternatives/cli corrupt: invalid status
[15:02] <mvo> bdmurray: I think we need to ask for addding this file to the bugreport
[15:02] <mvo> bdmurray: I asked in the bugreport now
[15:02] <bdmurray> mvo: okay, looking around there are quite a few 'update-alternatives.*invalid status' bug reports
[15:05] <bdmurray> mvo: should those be treated the same way or should dmesg be examined for memory / hardware issues?
[15:10] <Sweetshark> where does the change that our ld is using --as-needed by default coming from? ubuntu? or debian?
[15:10] <mvo> bdmurray: I don't now :/ I am not sure if that is the result of a programming error or fs corruption
[15:11] <janimo> Sweetshark, I think it is an ubuntu change, at least that was the case in natty
[15:12] <didrocks> @pilot out
[15:13] <Sweetshark> janimo: k, thx. good to know since it break the build here.
[15:13] <bdmurray> mvo: okay, I'll look into some manually and see what I find
[15:13] <mvo> bdmurray: thanks! keep me updated please
[15:14] <janimo> Sweetshark, AIUI it is enabled so we fix packages preemptively, as this becomes default behaviour when a switch to the gold linker happens
[15:15] <janimo> although I may be confusing it with the --add-needed option (which got renamed to avoid such confusions)
[15:16]  * Sweetshark is scared of the thought to link LibreOffice with gold.
[15:38] <janimo> siretart, is there a particular schedule for uploading libav? There's a crasher fixed upstream which I found useful but it may not be necessarily urgent for Ubuntu (lightspark crashes with it)
[15:39] <janimo> siretart, I built a package locally to confirm it is the right fix http://comments.gmane.org/gmane.comp.video.ffmpeg.devel/133360
[15:40] <bdmurray> slangasek: cjwatson commented on bug 500175 regarding passthrough and debconf
[15:41] <cjwatson> it's not clear to me that the tzdata case is the same
[15:41] <cjwatson> I'm having a go at reproducing that now
[15:42] <bdmurray> I've also seen 'user did not accept license' in the msttcorefonts ones regarding passthrough.pm
[15:43] <cjwatson> that sounds like a symptom of cancellation
[15:43] <cjwatson> I think at least some of these are going to end up being package installation failures that should be suppressed from crash reporting
[15:43] <cjwatson> I don't see any other way round some of them
[15:52] <siretart> janimo: well, I'd prefer to have it fixed in libav upstream first, and then I'm happy to upload it to debian/ubuntu, but otherwise, I don't have a 'particular schedule' for uploads
[15:53] <cjwatson> bdmurray: can't reproduce by just updating tzdata on top of 10.04 :-/
[15:53] <cjwatson> (well, a 10.04 image from July 2010 sometime)
[15:54] <cjwatson> I guess I can try 11.04 since there are reports from that ...
[16:04] <cjwatson> bdmurray: what would be a good way to stop reports of this kind of thing when it's just that the user hit cancel?  dump a known piece of text into the terminal log or something?
[16:07] <bdmurray> cjwatson: I think so but perhaps mvo would have a different idea
[16:08] <mvo> sounds good to me
[16:15] <cjwatson> if I could reproduce the damn thing it would really help, though.
[16:15] <bdmurray> mvo: and then we'd put that text in apt or apport?
[16:15] <cjwatson> it would have to be a message emitted by the debconf passthrough frontend
[16:15] <cjwatson> so you'd just have something pattern-matching on error messages, which is ugh but anyway
[16:16] <bdmurray> cjwatson: right and then added to apt or apport to not generate a crash
[16:18] <mvo> I would prefer apport (but need to rush to dinner now)
[16:52] <bdmurray> slangasek: i was rebooting and during the shutdown process noticed that 'Checking for running unattended-upgrades' appeared on the same line as something else.  Does that mean /etc/init.d/unattended-upgrades is missing a newline? and is there some log file I check for shutdown messages?
[17:03] <barry> @pilot in
[17:12]  * cjwatson wonders why a bug's reporter is called .owner in the LP API
[17:17] <infinity> cjwatson: Because all LP objects have owners?
[17:17] <cjwatson> I guess.  It just seems an odd way to put it
[17:17] <infinity> Thankfully, that's the only odd thing in the entirety of Launchpad.
[17:18] <Pici> 4hah
[17:21] <cjwatson> miaow
[17:24] <highvoltage> you're not supposed to say that out loud are you? :)
[17:25] <infinity> What?  That was my "completely sincere" voice.
[17:25] <bdmurray> barry: could pilot https://code.launchpad.net/~brian-murray/update-manager/apport-gconf/+merge/67228 ?
[17:25] <bdmurray> er could you
[17:25] <cjwatson> bdmurray: gah, even fairly brutal methods are failing to reproduce the tzdata case
[17:25] <cjwatson> escalating to a bigger chainsaw
[17:26] <barry> bdmurray: yep, i'm looking at this one right now and will look at yours afterward: http://tinyurl.com/622frtw
[17:28] <bdmurray> barry: thanks the debdiff in bug 797894 goes hand in hand with that merge proposal too
[17:29] <barry> bdmurray: cool
[17:32] <cjwatson> bdmurray: aha!  I can reproduce it if I upgrade both libpam0g and tzdata in update-manager
[17:32] <maco> any of you seen this odd behaviour on natty:  logging in only works at a DM, not at a TTY?
[17:33] <bdmurray> cjwatson: great!
[17:33] <maco> huh. well that just got more interesting. bugs are weird. works on TTY3, fails every time on TTY2
[17:34] <infinity> maco: Maybe tty2 thinks you have a key stuck or something?  (reset tty2, or switch to tty2 and randomly hammer modifier keys a bit before trying to log in?)
[18:05] <maco> ooh and rww spotted someone in #ubuntu having *all* TTY logins fail
[18:44] <ahasenack> hi, quick package versioning question. I have a package in oneiric I want to build on lucid: python-psutil 0.2.1-1
[18:44] <ahasenack> what should the version/release look like in lucid?
[18:45] <ahasenack> not only build, but backport and maintain in a ppa of mine
[18:45] <barry> bdmurray: is the patch in https://bugs.launchpad.net/ubuntu/+source/update-manager/+bug/797894 already uploaded to natty-proposed?
[18:46] <bdmurray> barry: no, it needs uploading
[18:46] <barry> bdmurray: k, looking at that now
[18:47] <bdmurray> barry: thanks!
[18:48] <serge_> all right so if a debian package version jumped to 0.7.4.2-0.3 (used to be 0.7.3-1 format), do we make it 0.7.4.2-0.3-0ubuntu1?
[18:50] <cjwatson> serge_: no, 0.7.4.2-0.3ubuntu1
[18:50] <cjwatson> serge_: 'dch -i' on an Ubuntu system should generally do the right thing to add a suitably incremented entry to the top of the changelog
[18:53] <barry> bdmurray: fwiw, the debdiff in #3 does not apply cleanly to the natty branch.  in fact: patch: **** malformed patch at line 36: diff -Nru update-manager-0.150.2/debian/update-manager-core.install update-manager-0.150.3/debian/update-manager-core.install
[18:53] <barry>  
[18:53] <serge_> cjwatson: thanks
[18:53] <barry> bdmurray: any chance you can regenerate the patch?  otherwise i'll manually apply it
[18:56] <bdmurray> barry: sure
[18:58] <slangasek> bdmurray, cjwatson: 500175> so does cancel not get passed through the passthrough?
[18:58] <slangasek> or else, why is the log so messy when someone presses cancel?
[18:58] <slangasek> bdmurray: I don't think we have a shutdown log, no; but upstart jobs can run in parallel to init scripts even on shutdown, maybe that's what's happening here?
[19:01] <pitti> james_w: ok, thanks; I'll update it the oldfashioned way then :)
[19:01] <pitti> serge_: no need to explicitly kick them; we'll just review them
[19:02] <bdmurray> barry: okay new one added
[19:03] <barry> bdmurray: thanks, that applies cleanly
[19:04] <barry> well, except for the changelog, but i'll fix that
[19:05] <bdmurray> what is wrong with the changelog?
[19:07] <barry> bdmurray: the debian/changelog hunk FAILED
[19:07] <barry> bdmurray: hmm, i grabbed `bzr ubuntu:natty/update-manager`.  maybe i should have grabbed something else though
[19:08] <bdmurray> barry: maybe natty-updates?
[19:08] <barry> bdmurray: let's try that!
[19:09] <barry> bdmurray: yep, much better
[19:19] <cjwatson> slangasek: passthrough is a bit slow to notice cancel, and witters a bit about undef values until it eventually gets killed by SIGPIPE.  Fixing that would be a good thing.  However, the ultimate effect would be the same - the user's cancelled, it needs to exit non-zereo
[19:19] <cjwatson> *non-zero
[19:19] <cjwatson> so the nonsense spewed on stderr is just noise rather than substance IMO
[19:20] <cjwatson> bug 442941 is much more interesting
[19:21] <cjwatson> and I fear that the proximate cause is actually an installer bug
[19:21] <cjwatson> after a fresh installation, /var/cache/debconf/config.dat is mode 0600
[19:21] <cjwatson> this means that the UI side of aptdaemon's debconf proxy can't start
[19:22] <cjwatson> I don't know if that's the whole problem
[19:32] <ahasenack> hi guys, quick packaging question. I want to build https://launchpad.net/ubuntu/+source/python-psutil/0.2.1-1 in a lucid ppa, what should its version become? 0.2.1-1ubuntu0.10.04?
[19:33] <micahg> ahasenack: try backportpackage from ubuntu-dev-tools
[19:33] <broder> micahg: beat me to it :)
[19:34] <micahg> :)
[19:34] <ahasenack> micahg: thanks, I will
[19:35] <ahasenack> micahg: hmm, I don't see it in that package
[19:35] <ahasenack> micahg: mine is ubuntu-dev-tools                   0.99
[19:35] <ahasenack> I have lucid-backports
[19:36] <broder> ahasenack: yeah, that's likely too old...let me see if the daily PPA has lucid builds...
[19:36] <broder> looks like it doesn't
[19:37] <micahg> ahasenack: yeah, so basically VERSION~RELEASE~ppa1 is what the script uses
[19:37] <broder> tumbleweed, bdrung_: ^
[19:37] <ahasenack> it also has other problems, it fails to import lazr.uri
[19:37] <ahasenack>     from lazr.uri import URI
[19:37] <ahasenack> ImportError: No module named uri
[19:37] <ahasenack> but I have it
[19:37] <ahasenack> ii  python-lazr.uri                    1.0.2-1
[19:37] <ahasenack> or I think I do :)
[19:37] <ahasenack> that was ubuntu-build, btw
[19:37] <broder> micahg: it's {VERSION}~{RELEASE}1~ppa1
[19:37] <broder> because VERSION~RELEASE1 is what we use for automated backports
[19:38] <micahg> broder: oh, hmm, right, was confusing with what I did before
[19:38] <ahasenack> so, python-psutil-0.2.1-1 becomes python-psutil-0.2.1-1~10.04.1~ppa1?
[19:38] <broder> ahasenack: no, we would do 0.2.1-1~lucid1~ppa1
[19:38] <ahasenack> ok, s/10.04/lucid/
[19:39] <ahasenack> and a dot
[19:39] <ahasenack> broder: and if I do local changes, I bump to ppa2 and so on?
[19:40] <broder> ahasenack: you only need to bump the number each time you upload to the PPA
[19:40] <ahasenack> broder: ok, but it's that last number, right? After the "ppa" suffix
[19:40] <broder> yeah
[19:40] <ahasenack> broder: cool, thanks a lot
[19:41] <broder> the idea is that you're doing a "prerelease" version of a real backport, so you always want your version number to be smaller than one the eventual real backports' version number would be
[19:42] <ahasenack> broder: the real backport would be 0.2.1-1~lucid1?
[19:42] <broder> right
[19:42] <ahasenack> ok, I might have a shot to get a hang of this someday :)
[19:42] <ahasenack> thanks again
[19:45] <slangasek> cjwatson: ah, heh; well, great to see that we actually have a foothold on these bugs now :)
[19:48] <ahasenack> broder: I'm getting this error, I suppose this is a good case to actually use the suggested -b?
[19:48] <ahasenack> New version specified (0.2.1-1~lucid1~ppa1) is less than
[19:48] <ahasenack> the current version number (0.2.1-1)!  Use -b to force
[19:49] <ahasenack> this with dch -v 0.2.1-1~lucid1~ppa1 "Backported to lucid."
[19:49] <broder> yeah, -b is fine
[19:49] <ahasenack> ok
[19:50] <broder> making the version number smaller is what we're going for, because it means that when you upgrade, the original will have a "higher" version than the backport, so you'll be upgraded back to the original
[19:50] <ahasenack> right
[19:50] <cjwatson> slangasek: I have no idea how to fix this post-release though
[19:50] <slangasek> a chmod from a maintainer script won't do the job?
[19:50] <cjwatson> it might be worth cramming into 10.04.3 as a late change to try to stem the flow of bugs there; but applying any upgrade to fix this might very well be hit by the same bug
[19:51] <cjwatson> I don't see how to reliably fix it before users encounter it
[19:51] <slangasek> right
[19:51] <cjwatson> and it only affects the first upgrade that uses debconf, AFAICS
[19:51] <cjwatson> once debconf rewrites the database, it sets the correct mode
[19:51] <slangasek> ah
[19:52] <cjwatson> which is why most of us never noticed
[19:52] <slangasek> if we suppressed the apport reports, would the *users* notice?  Beyond having to rerun the upgrade?
[19:52] <slangasek> well, I guess they'd still get the prompt about a crash, and told afterwards that they don't need to report the bug
[19:53] <cjwatson> right, it would be an improvement but not perfect
[19:54] <cjwatson> hard to make the bug pattern very specific, too
[19:54]  * slangasek nods
[19:54] <cjwatson> we'd have to ignore anything with this debconf warning pattern in it, and I can't claim confidence that this is the cause of all of them
[19:54] <cjwatson> in fact I'm fairly sure it's not
[19:54] <bdrung_> broder: if you get u-d-t building on lucid, let me know what dependencies needs to be updated
[19:55] <cjwatson> perhaps it's a price worth paying, I'm not sure
[19:56] <broder> bdrung_: oh, it doesn't build? that's too bad
[19:57] <bdrung_> broder: probably (i didn't test it)
[19:57] <bdrung_> broder: we probably need to backport a big bunch of packages
[19:58] <cjwatson> slangasek,bdmurray: we could bugpattern it just in the tzdata case, I suppose, and maybe libpam*; the packages that this is most likely to be reported against will be high-priority packages that use debconf and that have been updated since release
[19:59]  * cjwatson does a quick scour of "Binary package hint:" lines
[19:59] <cjwatson> or "Package:" I guess
[20:00] <slangasek> AIUI the 'Binary package hint' is considered deprecated and rarely accurate, so probably Package: yeah
[20:01] <cjwatson> the accuracy bit isn't a problem here, but yeah
[20:03] <slangasek> right, but I think the idea is to make that field go away entirely :)
[20:04] <cjwatson> indeed
[20:05] <cjwatson> http://paste.ubuntu.com/639704/ packages against which dups of 442941 have been reported
[20:06] <cjwatson> so tzdata accounts for 66%
[20:07]  * slangasek nods
[20:07] <serge_> jbernard: hey
[20:07] <cjwatson> I guess I'll have to check the others to make sure that they really are the same thing
[20:07] <cjwatson> should be recognisable by the terminal log being fairly short
[20:07] <serge_> jbernard: do you have any objection to my debdiff for bug 807199 ?
[20:08] <slangasek> I can speak for samba (samba, smbclient, samba-common, winbind) and libmyodbc to say that their debconf usage hasn't changed in a long time, so any failures there are unlikely to be caused by debconf misuse on the package side; dunno if that means it's the same bug on the debconf side though
[20:09]  * cjwatson causes lp-shell to eat his firefox so he can find out
[20:12] <cjwatson>  2794 cjwatson  20   0 2088m 1.6g  18m R  101 52.8  49:46.01 firefox-bin
[20:13] <cjwatson> I suspect that the other common factor (other than high-priority packages) is stuff-users-install-straight-away
[20:13] <cjwatson> and IIRC there's some bit of desktop furniture that offers to install some bit of samba for you, presumably using aptdaemon
[20:13] <cjwatson> similarly for gstreamer0.10-fluendo-plugins-mp3-partner
[20:14] <micahg> cjwatson: upstream's (Mozilla) working on that memory usage, I think by 8 you should see a significant improvement
[20:14] <cjwatson> micahg: while it's certainly not fun, I just opened 100 tabs all at once from a script, so I suspect it's allowed to be a bit upset
[20:14] <infinity> micahg: But it's already quarter past 9!
[20:15] <micahg> heh
[20:15] <micahg>  2789 micah     20   0 4440m 2.9g  22m S    6 36.6 465:05.60 firefox-bin, I run like this all the time :-/
[20:16] <bdmurray> cjwatson: could we bugpattern a specific version of the package such that only lucid/maverick/natty were blocked?
[20:22] <cjwatson> bdmurray: given that this is the first upgrade after installation, it would be simpler to bugpattern InstallationMedia or some such
[20:23] <cjwatson> I mean, include that in the pattern
[20:23] <cjwatson> the installer bug goes way back, I think it's very likely always been there
[20:23] <cjwatson> since ubiquity started in dapper anyway
[20:24] <cjwatson> we just never noticed it before package management frontends started using aptdaemon and having a user/root split
[20:25] <Daviey> Any of the DMB around?
[20:26] <stgraber> Daviey: what's up?
[20:26] <Daviey> stgraber: can ~ubuntu-server-dev be added to ~ubuntu-dev please?
[20:27] <Daviey> stgraber: *-server-dev is the package set team, and it's blocking the indirect ~ubuntu-dev and therefore ~ubuntumember foo.
[20:27] <stgraber> Daviey: done
[20:28] <Daviey> stgraber: rocking, thanks
[20:28] <cjwatson> also voting rights
[20:29] <stgraber> I also added edubuntu-dev as both kubuntu-dev and mythbuntu-dev were in it
[20:32] <Daviey> stgraber: rocking.
[20:36] <Laney> yeah, think you got everything
[20:37] <Laney> what happened to the bzr package set we approved?
[20:38] <stgraber> I think it needs implementation by TB, though I'm not sure if someone sent them an e-mail yet
[20:39] <Laney> :S
[20:43] <tumbleweed> broder: you wanting a u-d-t backport to lucid? the prerequise (for a no change backport) would be the dh_python2 backport
[20:43] <broder> ah, ok
[20:44] <Laney> stgraber: er, i can't actually find where we heard it. any clue?
[20:45] <Laney> stgraber: ah nm, found it
[20:46] <Laney> i wish we were better at minutes
[20:47] <stgraber> Laney: I guess we should create the team, make it a member of ubuntu-dev, then poke the TB to get the ACLs updated
[20:47] <Laney> right, doing that
[20:47] <Laney> it was your adding of teams that made me remember (when I was thinking if we'd missed any)
[20:48] <stgraber> then we'll be able to move the current PPU people we have for bzr to that team and maybe (not really needed) poke the TB again to drop the PPU upload rights (as they'll have them coming from the team)
[20:49] <Laney> I'll just ask the TB to do all of that
[20:52] <bdmurray> barry: still piloting? ;-)
[20:53] <barry> bdmurray: yep.  need another one?
[20:53] <bdmurray> https://code.launchpad.net/~brian-murray/apport/ubiquity-hook/+merge/67254
[20:54] <bdmurray> I've tested it an awful lot
[20:54] <bdmurray> probably too much
[20:54] <barry> :)
[20:57] <bryceh> slangasek, hi, we have xdiagnose as a Recommends of x11-common, however Sarvatt found it didn't get pulled in and installed in a fresh alpha2 install.  Any ideas where we went wrong?
[20:58] <barry> bdmurray: i have a couple of comments that would clean the code up a bit.  do you want them here or in the mp?
[20:58] <bryceh> slangasek, ubuntu-desktop depends on xserver-xorg, should xdiagnose be a recommends of that instead?  or should it be a Depends rather than Recommends?
[20:58] <RainCT> pedro_: Hey. You'll probably see some more of those bug reports. Zeitgeist 0.8.1-1ubuntu1 is badly broken
[20:58] <bdmurray> barry: here is fine
[20:59] <pedro_> RainCT, yup already have one assigned to didrocks
[20:59] <pedro_> he's doing the packaging there
[20:59] <barry> bdmurray: line 28.  it's always preferred to compare against None with identity instead of equality, so use "if response is None" instead
[20:59] <Sarvatt> bryceh: actually it depends on xorg not xserver-xorg, sorry
[20:59] <bdmurray> barry: right that was dumb
[21:00] <barry> bdmurray: line 30. it's generally not pythonic to test for equality against True, so just use "if response:" instead
[21:00] <bryceh> Sarvatt, ah right
[21:00] <pedro_> RainCT, bug 807203 , in case you want to subscribe
[21:01] <barry> bdmurray: the only other comment is about the start of the message on line 22.  i find the first sentence a little hard to follow.  can you rephrase/simplify that first sentence?
[21:01] <RainCT> pedro_: Yup, got the bug mail (and also sent didrocks a mail some hours ago). Just letting you know :)
[21:02] <pedro_> ;-)
[21:02] <bdmurray> barry: okay
[21:02] <barry> bdmurray: push an update and ping me and i'll be happy to upload it
[21:04] <bdmurray> barry: "The system log from your installation contains an error.  The specific error commonly occurs when there is an issue with the media from which you were installing."
[21:04] <bdmurray> does that sound better?
[21:04] <barry> bdmurray: beautiful :)
[21:05] <cjwatson> slangasek,bdmurray: I think what I'm inclined to do here is to have a bugpattern that's as accurate as I can make it, but have it redirect to a wiki page that (a) explains the debconf database permissions problem and a workaround (b) explains the issue with cancellation (c) suggests e-mailing me if they have some different problem not covered
[21:05] <cjwatson> does that seem reasonable?
[21:07] <cjwatson> because I'm not even sure I can separate (a) and (b) in terminal logs manually, let alone automatically
[21:09] <Daviey> bdmurray: Where is the bugpattern work being documented?
[21:09] <cjwatson> bdmurray: do you think you've already caught all the duplicates with grab-attachments or whatever?
[21:09] <bdmurray> cjwatson: yes that sounds reasonable to me, however there may be some complications implementing it.
[21:10] <bdmurray> cjwatson: no, I stopped looking until we had the issue sorted more
[21:10] <Daviey> bdmurray: I assume Ursinha is following this closely?
[21:10] <cjwatson> bdmurray: what would the implementation problems be?
[21:10] <Ursinha> me
[21:10] <bdmurray> Daviey: Ursinha and I have talked about bug patterns
[21:10] <bryceh> cjwatson, heya, we have a MIR approved for xdiagnose, and have a Recommends on it from x11-common, but it appears to still be in universe; do you happen to know if there is something more we need to do to get it in?
[21:10] <Daviey> Ursinha: Guten Tag, i thought you might be /away by now.
[21:11] <Ursinha> Daviey: not yet :)
[21:11] <cjwatson> bryceh: I can do it now given an approved MIR
[21:11] <bdmurray> cjwatson: well if you want the pattern to work on releases before natty there are some issues but I can sort that out.
[21:11] <cjwatson> haven't gone through that queue for a bit
[21:11]  * Ursinha reads backlog
[21:11] <cjwatson> bryceh: where's the MIR?
[21:11] <bryceh> cjwatson, that would be great, thanks - https://bugs.launchpad.net/ubuntu/+source/xdiagnose/+bug/784885
[21:11] <bdmurray> barry: the merge proposal has been updated
[21:12] <cjwatson> I don't see it on https://bugs.launchpad.net/~ubuntu-mir/+subscribedbugs
[21:12] <barry> bdmurray: looks great, i'll sponsor it
[21:12] <cjwatson> bryceh: oh, you marked it Fix Released, that removed it from our queue
[21:13] <cjwatson> the workflow is that MIR bugs go to Fix Committed once they're approved
[21:13] <bryceh> cjwatson, guess I assumed since pitti uploaded some changes to it that he'd done the main promotion :-/
[21:13] <bdmurray> cjwatson: so once a wiki page was made I'd go looking for more duplicates and include the wiki page in the coment.
[21:13] <cjwatson> bryceh: different hats there
[21:13] <bryceh> *sigh*
[21:14] <bryceh> cjwatson, ok thanks for clarifying
[21:14] <cjwatson> promoted now, anyway
[21:17] <bryceh> Sarvatt, ok should be fixed now.  Once again a case of me being stupid, sorry.
[21:24] <barry> bdmurray: how many branches of apport are there?!  lp:apport, ubuntu:apport lp:~ubuntu-core-dev/ubuntu/oneiric/apport/ubuntu
[21:25] <micahg> that's actually a normal number of branches :)
[21:25] <barry> ah, well clearly the last two are not in sync, given bug 494481
[21:26] <barry> micahg: but it hurts ;)
[21:27] <micahg> barry: well, in this case your minimum is 2 since upstream is hosted in LP :)
[21:27] <bdmurray> barry: well I know lp:apport is the upstream one and that doesn't contain the package hooks as those are ubuntu specific
[21:27] <barry> i could handle two :)
[21:28] <barry> no worries though, i'm just complainin' ;)
[21:28] <ScottK> micahg: Get off barry's lawn.
[21:28] <barry> ScottK: exactly :-D
[21:29]  * micahg goes to find another lawn...
[21:31] <barry> and with that...
[21:31] <barry> @pilot out
[21:32]  * Laney applauds barry
[21:33] <Laney> jono: can you CC the DMB in on your recent tech-board discussion?
[21:33]  * barry bows and collides with the keyboard
[21:37] <jono> Laney, I want to get the TB's perspective first before moving forward to see if my suggestions even fly
[21:38] <jono> as this is a technical policy decision
[21:38] <jono> and then I will move it forward to the DMB
[21:38] <ScottK> What's the topic?
[21:38] <Laney> I'd have thought you wanted DMB input as you are proposing some quite serious changes to the way we work.
[21:38] <Daviey> ScottK: https://lists.ubuntu.com/archives/technical-board/2011-July/000957.html
[21:38] <jono> Laney, I am totally interested in input
[21:38] <ScottK> Daviey: Thanks.
[21:38] <jono> I just wanted to get the TB input first
[21:39] <Laney> The effect that will have is that the path is rather firmly aligned when the discussion comes down to us
[21:40] <ScottK> That is a bit of a change.
[21:40] <jono> I am certainly keen that the DMB offers plenty of input on this
[21:41] <ScottK> jono: I'm interested in specific examples (in private if you prefer) of people not getting through the current process as they should have.  My view has been that if anything the process is too biased towards acceptance.
[21:41] <jono> ScottK, interesting
[21:42] <jono> ScottK, would be happy to hop on a call
[21:42] <jono> maybe tomorrow if you are around?
[21:42] <ScottK> jono: Tomorrow is better for me.  I'm about EOD here.
[21:42] <Laney> I thought that too.
[21:42] <jono> thanks ScottK
[21:42] <Laney> I wonder why people don't come to the DMB with their concerns
[21:42] <jono> Laney,  thought it was too accepting?
[21:42] <ScottK> jono: Give me a ping when you're awake and moving tomorrow (assuming you're in your home TZ).
[21:43] <jono> ScottK, will do, thanks, pal
[21:43] <Laney> jono: yes, or at least that we treat deferrals much more seriously
[21:43] <jono> right
[21:43] <jono> I think there are just some areas in which we can ease the process
[21:44] <jono> as I outline in my mail
[21:44] <jono> I believe it should be more about reputation than anything, and we should bring more value into the testimonials
[21:44] <ScottK> Laney: I haven't said anything since I think that between the TB delegation and the election by ubuntu-dev the DMB has a lot of legitimacy to figure out how to handle approving members.  I'd have to find it seriously broken before I complained.  I don't think it is (seriously broken).
[21:45] <ScottK> jono: It's been my experience that people I give solid testimonials to get in easily and the one time I gave a "Dear God, please no" testimonial they didn't.
[21:45] <Laney> ScottK: I wasn't referring to your concerns, but these people who think that 'the process is too difficult to get through'
[21:46] <ScottK> So I think they get a lot of weight already, but we can discuss tomorrow.
[21:46] <jono> ScottK, great, and that is what I am keen to empower and set expectations firmly about - the value of a +1/-1 from a core dev
[21:47]  * ajmitch wouldn't necessarily say that all core devs are the same
[21:47] <ScottK> Some are definitely more equal than others.
[21:47] <ScottK> See you all later.
[21:48] <ajmitch> I trust my opinion on +1/-1 far less than I'd trust others
[21:50]  * cjwatson had an extensive argument on this subject on the DMB list just before retiring.  My sense that I wasn't getting anywhere was part of why I retired.
[21:50] <cjwatson> (though far from all; I just didn't have the time)
[21:51] <cjwatson> of course that was a while back now.
[21:55] <jml> barry: ping
[21:55] <Laney> besides one which is currently unresolved, I'm not sure I can remember us voting down any applications since I joined anyway
[21:55] <Daviey> it's a shame the list isn't open.
[21:55] <Laney> however I'm not at all sure that the DMB commands the legitimacy that it should
[21:56] <Daviey> Laney: I suspect that are quite a few people that are not applying through fear/embarrasement of applying for upload privs TBH.
[21:56] <maco> Laney: "serious changes to the way we work" is an understatement, IMO. "making the DMB redundant" is a better description
[21:56] <Daviey> fear of NACK, that is.
[21:56] <Laney> maco: We get to press the 'Add member' button :-)
[21:57] <Laney> Daviey: Right, applications are self selecting.
[21:57] <nigelb> Laney: :)
[21:57] <maco> Laney: but if all it takes is "well 2 people think its a good idea" then hey, just make there be a "make dev" button on everybody's LP page and once two core devs have +1'd by pressing it, there ya go automagic
[21:57] <Daviey> Laney: surivial of the most confident :)
[21:57] <nigelb> maybe it should be +2 with no objections to make it more fair
[21:57] <ajmitch> Daviey: it should work like that, to some degree
[21:57] <Laney> I didn't apply for MOTU until james_w told me to for the 15th time
[21:57] <jono> maco, my suggestions do not make the DMB redundant
[21:58] <jono> they just optimize the process around reputation
[21:58] <maco> Laney: it is no longer unresolved, i believe. you and persia both said +0. based on what persia says is historical practice, the application is "not yet"'d
[21:58] <jono> we still need a board to assess applications
[21:58] <Laney> It assumes we undervalue testimonials, which I do not believe to be the case
[21:58] <maco> Laney++
[21:59] <maco> we just don't take testimonials as the end-all be-all
[21:59] <cjwatson> jono: I think it may be worth assessing your past experiences in light of the facts around the current iteration of the DMB
[21:59] <maco> i probably couldve gotten some nice testimonials from a couple of people 6mo before i applied for motu, but i wouldve only had 5 uploads
[21:59] <cjwatson> that probably goes for me too
[21:59] <cjwatson> jono: let's make sure it's actually a significant problem right now before changing anything
[22:00] <Laney> upload count> I don't really consider that per se
[22:00] <Laney> all activity goes into the mix
[22:00] <nigelb> cjwatson: What was the conclusion of the discussion on the DMB list (if it is possible to be made public that is)?
[22:00] <cjwatson> nigelb: inconclusive
[22:00] <nigelb> ah
[22:00] <cjwatson> but, as I say, that was the last board
[22:00] <jono> cjwatson, totally agreed
[22:01] <maco> actually, whatd be REALLY handy is if LP could tell us all uploads on which their name was *anywhere* in the changelog, since often with UDD and all, you get  [name]  stuff [name] stuff [name] stuff       name <email> $timestamp
[22:01] <Laney> debian has 'ddportfolio'
[22:01] <cjwatson> basically my thesis was that the DMB has two functions, gatekeeper (keep out the bad eggs) and nurturer (encourage new developers), and that at the point I retired we had swayed too far towards the former
[22:01] <jono> Laney, and my suggestions may well be redundant
[22:01] <cjwatson> I'm entirely prepared to believe that that's changed since then
[22:01] <Laney> jono: we can't really judge without specific examples
[22:02] <cjwatson> though I think the dual function is always worth keeping in mind
[22:02] <nigelb> maco: Isn't that the responsibility of the candidate to say, "Hey, I've worked on foo, bar, and baz"
[22:02] <cjwatson> nigelb: it'd be less tedious for everyone if we could just look up a full list
[22:02] <jono> sorry, I have to head to a meeting, maybe this could be a good point of discussion at the next TB meeting? invite the DMB along to participate too?
[22:02] <Daviey> maco: Funny you say that, i have a mbox parsing script for searching for names anywhere in the changelog.  Only takes 1.5 hours to run :)
[22:02] <cjwatson> er, "we" being a board I'm not on, but YSWIM
[22:02] <maco> nigelb: the template asks for a couple you're proud of. having a full list would by handy though
[22:03] <maco> Daviey: i suspect LP's db is faster than text parsing....
[22:03] <nigelb> cjwatson: ah, that makes sense
[22:03] <cjwatson> jono: the proposal is to change DMB behaviour; I think it should be discussed primarily in the DMB, with the TB as guests
[22:03] <nigelb> Daviey: well, if you could run it everyday....
[22:03] <cjwatson> jono: but I agree, we definitely need concrete current examples
[22:03] <jono> cjwatson, I suggested the TB as I see this as a wider policy that the DMB implements
[22:03] <jono> but happy either way
[22:03] <cjwatson> jono: that's a bit artificial though
[22:03] <jono> DMB may well make better sense
[22:04] <Laney> the TB has delegated deveoper membership to the DMB
[22:04] <Daviey> maco: I would hope so!  I had hoped that Laney's UDD work would deprecate it.
[22:04] <maco> LP shows who the uploader and sponsor were. if it showed "other contributors to the upload" and then had your /+relatedsoftware hook into that....yay
[22:04] <Laney> Daviey: it doesn't include changelogs
[22:04] <cjwatson> in practice I've not heard of any debate about any other team doing developer approvals (kubuntu council or whatever)
[22:04] <Laney> but it does mean that I have a large cache of changes mboxes
[22:04] <Daviey> Laney: arse.
[22:04] <Laney> infact, the sysadmins kindly made them rsyncable for me
[22:04] <Laney> lists.ubuntu.com::changes-mboxes
[22:05] <Laney> so it's easy for anyone to get :-)
[22:05] <micahg> maco: re person in changelog> I actually discussed something like that with barry about 5 months ago as part of UDD
[22:05] <jono> tbh, I don't mind where the meeting is, so long as the DMB and TB both have input
[22:06] <nigelb> lol
[22:06] <nigelb> technically, we could parse the changes mbox, but that's going to be time consuming.
[22:06] <nigelb> unless its a diff, hm. that should be interesting
[22:06] <nigelb> Daviey: Could I have your mbox parsing script?
[22:06] <Daviey> nigelb: no.
[22:07] <Daviey> nigelb: it's an embarrasement.
[22:07] <Laney> it's not that time consuming
[22:07] <nigelb> Daviey: Don't worry, I won't show it to anyone. I don't want to start from scratch
[22:07] <micahg> maco: one of the problems with parsing the changelog is without an e-mail address it's indeterminate as to whom the person is
[22:07] <maco> micahg: thats true
[22:07] <Daviey> nigelb: -> PM.
[22:08] <Daviey> micahg: it's a reasonable indicator.
[22:08] <Laney> with applicants, I suspect that a good time to apply is when existing developers get bored of sponsoring your changes and make you do it
[22:08] <micahg> Daviey: it can't be automated is my point
[22:08] <Laney> that's probably the way it works for a lot of people
[22:08] <Daviey> micahg: agreed
[22:09] <nigelb> Sure but a list of [Name] type entries is nice to have. Its posible to ask candidates, do you do that change?
[22:12] <maco> Laney: a month before my motu app, ogra was going "what? you need a sponsor? but thats a universe package!"
[22:12] <Laney> hah
[22:14] <ajmitch> maco: that can happen a bit
[22:14] <Daviey> is revu dead these days?
[22:15] <Laney> mostly
[22:15] <maco> pretty much
[22:15] <ajmitch> it's just resting
[22:16] <Laney> ajmitch locked it in the cellar
[22:16] <cjwatson> it's pining for the fjords
[22:16] <maco> i changed the wiki page to point out that the WNPP route is better because it benefits more users and involves a designated maintainer instead of just piling on to motu-work
[22:16] <Laney> yay
[22:16] <Laney> did you also link to wiki.d.o/Teams? :-)
[22:17] <maco> i linked to the WNPP process stuff for sure. not sure on particulars though...was a while ago
[22:17] <maco> i remember saying to persia that i couldnt apply for motu since i hadnt packaged enough from scratch, and he was like "that's fine! motu doesn't really need more work!"
[22:18] <maco> oh hm. i should do whatever htat next step is in my DM application...
[22:18] <Laney> if it's not leaking too much, the gist of cjwatson's email is that we shouldn't focus on debian/changelog too much but consider the whole
[22:18] <Laney> is that a fair summary?
[22:19] <cjwatson> pretty much yeah, plus my comments above on the two functions of the DMB
[22:19] <Laney> so to refer to the conversation of a few minutes ago, we shouldn't worry too much about mining archives of upload history
[22:20] <micahg> heh, I'm still working on my first package from scratch (through Debian) and even that I "borrowed" a couple files from the UBuntu package
[22:20] <Laney> I just uploaded a NEW package to debian that started life in a PPA :-)
[22:20] <Laney> http://packages.debian.org/changelogs/pool/main/s/sparkleshare/current/changelog
[22:21] <maco> Laney: in most cases i dont think we need the extra upload history, but for example a recent person had only 1 visible upload on their +relatedsoftware page at the time of application, so in that case being able to see what they worked-on-but-didnt-officially-upload wouldve been handy to sway things toward a more positive space
[22:21] <ajmitch> oh it'd uploaded now?
[22:21] <cjwatson> for a lot of people upload history will be pretty significant, I just think y'all probably oughtn't be closed-minded about it
[22:21] <Laney> ajmitch: yeah, for ages!
[22:21] <ajmitch> Laney: well, uploaded & through NEW
[22:21]  * ajmitch should try it out
[22:21] <Laney> got NEWed rapidly, as happens in Debian these days
[22:21] <Laney> initial setup is rough
[22:22] <maco> cjwatson: given i had like...a dozen...uploads when i joined motu, i dont really think i can be *too* anal about # of uploads, but ...plural is nice
[22:22] <cjwatson> and there ought to be some sponsored uploads; I think what I was trying to push back on was that people ought to have dozens and dozens of sponsored uploads over a seriously extended period
[22:22] <ajmitch> Laney: synced to oneiric yet?
[22:22] <cjwatson> *was the idea that
[22:22] <Laney> maco: oh yeah, that's why applicants are encouraged to point us to more information that can help review
[22:22] <Laney> ajmitch: in NEW
[22:22] <cjwatson> at some level it was really just a difference of opinion about degree
[22:22] <Laney> (was a merge to add appindicator stuff)
[22:23] <maco> (im still a bit surprised yall approved me with a dozen uploads though)
[22:23] <ajmitch> maco: I'm sure some of us got in with less
[22:24] <maco> cjwatson: i do recall the "dozens and dozens" type talk before i applied.  sounded like some people wanted 50-ish uploads before you even think about applying, which...
[22:24] <ajmitch> that seems excessive
[22:24] <maco> to establish "i'm not stupid and will ask for help when i reach my boundaries" doesn't take NEARLY that many
[22:24]  * micahg was told 30 once upon a time
[22:25] <ajmitch> I'm sure that the DMB would take into account what sort of uploads they were
[22:25] <maco> if you're doing merges and ftbfs and actually getting them right pretty plz take upload rights :P
[22:25] <ajmitch> 30 syncs is quite different than 30 uploads of a complex set of packages
[22:25] <Laney> don't forget the testimonials that started this discussion off
[22:26] <ajmitch> right
[22:27] <maco> balance
[22:27] <serge_> jbernard: o/
[22:28] <ajmitch> maco: and common sense
[22:28] <lifeless> as a data point, I'm nervous about applying for core-dev
[22:28] <maco> lifeless: you're not one?
[22:28] <lifeless> nope
[22:28] <ajmitch> heh
[22:29] <nigelb> O_O
[22:29] <lifeless> I have stuff in main I can upload to via Debian :)
[22:29] <maco> huh.
[22:29] <ajmitch> why are you nervous about it?
[22:29] <infinity> lifeless: We're all nervous about you in core-dev.
[22:29] <lifeless> ajmitch: I don't *routinely* change stuff that is in main
[22:29] <lifeless> infinity: thanks :P
[22:29] <infinity> lifeless: But, more seriously, people who are cautious about responsibility are the people who should be applying. :P
[22:29] <lifeless> ajmitch: and I have the impression there is a high assessment bar around core-dev
[22:30] <infinity> lifeless: Cause you won't break something you don't understand.
[22:30] <maco> infinity++
[22:30]  * ajmitch goes off to upload glibc for fun...
[22:30] <infinity> ajmitch: *glare*
[22:30] <Laney> lifeless: can we swap you for ajmitch please?
[22:30] <infinity> ajmitch: You shouldn't have given me warning, I can head that off. :P
[22:30] <ajmitch> infinity: yeah I'm not that stupid :P
[22:30] <lifeless> Laney: hahaha :)
[22:31] <lifeless> Laney: sure, its only ~600km drive
[22:31] <ajmitch> Laney: <3 to you too
[22:31] <nigelb> haha
[22:31]  * Laney snuggles ajmitch really
[22:31] <infinity> ...
[22:31] <infinity> Should we be seeing this?
[22:31] <Laney> :$
[22:31] <Laney> lifeless: but really, if you can get a couple of testimonials then I see no problem
[22:32] <Laney> I usually ask about working with Debian, but if you're a DD already …
[22:32] <infinity> I suspect he just doesn't want to apply because then Daniel will rope him into patch piloting.
[22:32] <Daviey> lifeless: Feel free to help out with the squid issues, then you'll get +100 testimonal from the server team :)
[22:32] <micahg> infinity: he's already MOTU
[22:32] <lifeless> I should do more piloting
[22:33] <lifeless> I was doing revu a lot at one point, but dropped the ball and didn't get back onto it
[22:33] <lifeless> Daviey: ask SpamapS .... I already do :P
[22:33] <infinity> micahg: Oh, when I do my PP rotations, I can ignore people with patches to main?  Snazzy. ;)
[22:34] <infinity> Daviey: I'm sure he helps with squid a lot, you just don't realise it because he refers to it as "quiche".
[22:34] <Daviey> real developers don't eat quiche.
[22:34] <lifeless> bah, fish schticks to you al
[22:34] <micahg> infinity: you're a core-dev already, his way out is he's with Launchpad :)
[22:34] <lifeless> l
[22:35] <maco> Daviey: zuchinni quiche is delicoius
[22:35] <maco> *delicious
[22:35] <micahg> infinity: actually, upload rights isn't a requirement for piloting
[22:35] <Daviey> pah.
[22:35] <lifeless> maco: I think you just broke my tastebuds
[22:35] <Laney> Canonical DDs should be forced to troll in -devel to bring Debian down from the inside
[22:35] <Laney> debian-devle that is :-)
[22:35] <micahg> or maybe it was only minimal upload rights...(PPU for one package at least)
[22:36] <nigelb> like the opposite of patch piloting?
[22:36] <lifeless> patch creation?
[22:36] <infinity> micahg: Ahh, well.  I've not really been initiated into the whole process yet, I just have an event on my calendar, and a Holbach threatening me with doom if I attempt to back out. ;)
[22:36] <Laney> cloak 'n dagger
[22:37] <nigelb> infinity: On a positive note, its Daniel and not Jono :P
[22:37] <micahg> heh, which day is that, I have to make sure to flood the queue with stuff to sponsor for main :P
[22:37] <Daviey> micahg: yeah, Canonical engineering team who are in ~ubuntu-dev, are expected to do 4 hours per month.
[22:37] <micahg> Daviey: yep, so the second one :)
[22:38] <maco> nigelb: because daniel's version of doom involves stuffed teddy bears and jono's involves listening to Severed Fifth?
[22:38] <nigelb> Exactly!
[22:38]  * infinity snickers.
[22:39] <lifeless> hmm, does gwibber have g+ integration in oneiric?
[22:39] <infinity> lifeless: Impatient much?
[22:39] <nigelb> hold on, g+ hasn't exposed api yet
[22:39] <lifeless> infinity: curious is all
[22:39] <lifeless> nigelb: its massive client side js, that pretty mnuch defines it having an API :)
[22:40] <Daviey> nigelb: python-mechanize was invented for this reason! :)
[22:40] <nigelb> lifeless: I'll rephase. API docs!
[22:40] <nigelb> *rephrase
[22:41] <Daviey> ah, JS.
[22:41] <nigelb> ok, bed. 4 am is late enough.
[22:41] <maco> yeah, hometime
[22:42] <lifeless> hah, at least https://services.google.com/fb/forms/plusdevelopers/ is refreshingly honest
[22:42] <lifeless> 'In addition, we'd love to gather more information about you.'
[22:42] <nigelb> I need to tell my brain which timezone my body is in.
[22:42] <nigelb> heh
[23:24] <apachelogger> kees, mterry: bug 601662 requires attention, it is blocking movement on KDE 4.7 builds
[23:25] <micahg> apachelogger: kees is on vacation until next week
[23:27] <TheMuso> c
[23:28] <apachelogger> micahg: oh, ok
[23:28] <apachelogger> actually I could also live with a pre-promotion ;)
[23:59]  * micahg hugs cjwatson