[00:13] <SpamapS> @pilot out
[00:52] <ari-tczew> doko: is python-django on your todo ftbfs fix?
[01:20] <jfer> Hi. I am having trouble using bzr to get involved in unity
[01:20] <jfer> can someone please give me a hand?
[01:29] <achiang> jfer: what is your question?
[03:41] <kees> james_w: say, why is this 6 months behind? https://code.launchpad.net/~ubuntu-branches/ubuntu/natty/kde4libs/natty
[03:43] <kees> Riddell: do you know anyone from upstream KDE that will commit my patch in https://bugs.kde.org/show_bug.cgi?id=245529 ?
[04:32] <james_w> kees, bug 653301
[04:32] <james_w> which could actually progress now
[04:32]  * james_w leaves that for tomorrow
[05:46] <mark_> test
[05:46] <kees> james_w: ah-ha, thanks
[05:47] <mark_> any progress on the memory leaking nm-applet?
[07:11] <mark_> any progress on the memory leaking nm-applet?
[07:41] <pitti> Good morning
[07:54] <dholbach> good morning
[07:54] <akshatj> good morning dholbach
[07:54] <dholbach> hi akshatj
[08:08]  * ebroder wants Upstart managing his user session instead gnome-session
[08:58] <seb128> hey
[08:59] <seb128> @pilot in
[09:00]  * dholbach hugs seb128
[09:00]  * seb128 hugs dholbach
[09:03] <mvo> seb128: happy flying
[09:04] <seb128> mvo, thanks ;-)
[10:49] <mok0> mvo, I see you fixed the python-minimal problem, THANKS!
[10:51] <pitti> mvo: oh, did you?
[10:51] <mvo> not really :/
[10:51] <mvo> doko just added workaround for now
[10:51]  * mvo is off for lunch
[10:51] <mok0> pitti: there was an upgrade of python2.6-minimal, after which I could install python-minimal
[10:52] <pitti> mok0: in natty? no, that was python2.7-minimal dropping the Breaks:
[10:52] <doko> it would be a workaround if the fixed python-defaults arrives in -updates
[10:52] <mok0> pitti: That's what it seemed like when apt-get did its thing
[10:52] <mok0> yes in natty
[10:53] <mok0> anyway my natty sbuilder is now happily compiling again :-)
[12:02] <ScottK> kees: Riddell, apachelogger, and JontheEchidna all have commit rights in KDE svn, so one of them.
[12:02] <ScottK> Oh, or agateau if you can catch him.
[12:09] <pitti> seb128: can you please reupload bug     688781
[12:09] <pitti> seb128: with a fixed LP# ref in the changelog?
[12:15] <seb128> pitti, urg, yeah sorry about that
[12:18] <seb128> pitti, done
[12:18] <pitti> seb128: merci
[12:18] <seb128> de rien, sorry for not being careful
[12:19] <seb128> the bug number was listed twice but not with the right format ;-)
[13:05] <ScottK> NCommander: When you have a moment, I'd like to talk to you about sip4-qt3 (looking for help understanding it, not asking you to do work).
[13:29] <doko> seb128: who best to ask about vala? bug #618809
[13:32] <seb128> doko, do they fail to build or...?
[13:33] <doko> seb128: yes, b-d on libvala-dev, now we seem to target vala 0.12
[13:34] <seb128> doko, did they fail to build if you rename the build-depends?
[13:37] <doko> seb128: yes
[13:38] <seb128> kenvandine, ^ do you have time to try to see what's wrong with gtask?
[13:39] <doko> cyphermox and slomo are not online. will subscribe them
[13:40] <seb128> doko, or wait for kenvandine to reply
[13:40] <doko> ok
[13:41] <ari-tczew> Więcej osób chce Cię poznać na Badoo!
[13:41] <ari-tczew> ups, not this copy
[13:41] <ari-tczew> doko: is python-django on your todo ftbfs fix?
[13:41] <doko> ari-tczew: no. what is wrong with it?
[13:42] <ari-tczew> doko: no longer build with python. it's to sync, but it can be synced because it's ftbfs on natty chroot.
[13:43] <doko> ari-tczew: bug number?
[13:43] <ari-tczew> doko: not reported, report it?
[13:43] <doko> ari-tczew: ftbfs is not that much info ...
[13:43] <ari-tczew> doko: as sync request or rather ftbfs?
[13:54] <doko> ari-tczew: is it safe ti sync, do packages b-d on it, build? you have more information than me. please make it available. bug report seems to be fine
[13:56] <kenvandine> seb128, i can look at gtask
[13:57] <ari-tczew> doko: hmmm, I can't attack buildlog ATM, so I'm sending pastebin: http://paste.ubuntu.com/544044/
[13:57] <ari-tczew> bug 690646
[13:57] <Daviey> doko: Have you been seeing, http://pb.daviey.com/cRcx/raw/ ?
[13:58] <doko> ari-tczew: does the package b-d on python-all*?
[13:58] <doko> Daviey: dpkg -l python python-minimal ?
[13:59] <ari-tczew> doko: nope
[13:59] <Daviey> doko: version 2.6.6-2ubuntu1, want a full paste?
[14:00] <doko> ari-tczew: but it tries to build for it.
[14:00] <Daviey> doko:  http://pb.daviey.com/ZJew/raw/
[14:00] <doko> Daviey: see my last comment in https://bugs.edge.launchpad.net/ubuntu/+source/python2.7/+bug/689306
[14:00] <ari-tczew> doko: Build-Depends: debhelper (>= 7.0.50), python-support, python (>= 2.5) | python-sqlite, language-pack-en-base Build-Depends-Indep: python-sphinx, libjs-jquery
[14:01]  * Daviey reads
[14:04] <apw> jhunt, hey, you had a bug for initramfs-tools for the fixes for the new linhib0001 stuff, can you point me at it
[14:05] <jhunt> apw: https://bugs.launchpad.net/ubuntu/+source/util-linux/+bug/683605
[14:05] <apw> jhunt, how is that one going, i am starting to see duplicates of it
[14:05] <Daviey> doko: thanks!
[14:06] <apw> jhunt, oh yeah it was waiting for something to invalidate a pending linhib0001 image in swap when it was first installed ... else bad poop (tm) could occur
[14:13] <NCommander> ScottK: I'm here
[14:13] <ScottK> NCommander: Hello.
[14:13] <NCommander> ScottK: how are you doing this morning?
[14:13] <ScottK> NCommander: I looked at dh_sip and it seems simple enough.  The one big question I have is where does the API version come from?
[14:13] <ScottK> NCommander: Pretty good.  Pleanty to do.
[14:14] <NCommander> ScottK: ah, that's a new feature added by the co-maintainer. I would have to look
[14:14] <ScottK> NCommander: OK.  I thought you had been involved in it.
[14:14] <NCommander> give me a sec, I'll grab the source
[14:14] <ScottK> Thanks.
[14:14] <jhunt> apw: sorry, been busy on upstart. So the scenario is that if a user boots a kernel older than 2.6.37 (having hibernated in the 2.6.37 kernel), we need to invalidate the swap signature right?
[14:14] <NCommander> ScottK: I did some design discussions, but then I went to China and it got implemented without me
[14:14] <ScottK> I see.
[14:15] <NCommander> ScottK: looks like we're quizing dpkg for the python-sip version
[14:15] <apw> jhunt, no actually the issue is if we have natty and hibernate, reboot, hibernate is not detected and swap is lost.  we then fix the tools and reboot and it finds and resume from the image and the filesystem no longer matches the memory image and BLAMMO bad corruption of /
[14:15] <NCommander> ScottK: which is sane because we don't know if the sip ABI has changed (there's no promise by upstream that it will remain stable)
[14:15] <apw> jhunt, so if you install your fixes to the tools, we need to invalidate the swap marker as the contents are definatly BAD to use
[14:16] <apw> cjwatson, ^^
[14:16] <NCommander> cjwatson: did you get around to putting archdetect in userspace BTW? (per UDS)
[14:16] <ScottK> NCommander: Right, but dh_sip uses whatever API version the package provides.
[14:17] <ScottK> I'm trying to figure out where that comes from (see the provides in debian/control)
[14:18] <NCommander> ScottK: it would be the version of the source package then
[14:18]  * NCommander looks a little more indepth
[14:19] <cjwatson> NCommander: see recent debian-boot@
[14:19] <ScottK> That doesn't match what's there currently.
[14:19] <NCommander> cjwatson: checking
[14:20] <NCommander> ScottK: what's there currently?
[14:20] <ScottK> NCommander: Provides: ${python:Provides}, sip-api-7.0, sip-api-7.1
[14:21] <NCommander> cjwatson: thread title?
[14:22]  * NCommander is not seeing it in the archive list
[14:22] <cjwatson> NCommander: http://lists.debian.org/debian-boot/2010/12/msg00481.html
[14:23] <NCommander> cjwatson: interesting. I'll be watching what develops in this thread (dpkg-subarchitecture or extending dpkg-architecture is an interesting idea TBH)
[14:30] <cjwatson> NCommander: I can't say I approve myself - stuff that isn't maintained by the dpkg team shouldn't be in the dpkg-* namespace
[14:30] <cjwatson> (dpkg-reconfigure is a historical mistake that shouldn't be repeated)
[14:30] <cjwatson> I followed up to the thread to say that
[14:39] <ari-tczew> doko: so, are B-D fine or not?
[14:40] <doko> ari-tczew: is the package meant for all supported python versions, or just for the current one?
[14:41] <ari-tczew> doko: dunno, really
[14:45] <doko> ari-tczew: where is the merged package?
[14:45] <ari-tczew> doko: merged?
[14:46] <doko> ari-tczew: I thought you wanted to merge from unstable?
[14:46] <ari-tczew> doko: it's ready to sync
[14:46] <NCommander> cjwatson: thanks for being on top of this
[14:47] <ari-tczew> doko: but it's ftbfs - the same with current package and from unstable, so I'm getting in touch with you
[14:50] <doko> ari-tczew: $ cat debian/pyversions
[14:50] <doko> 2.3-
[14:51] <cjwatson> dholbach: does http://merges.ubuntu.com/main.json (and restricted, universe, multiverse, and main-manual etc.) fit the form you need for harvest?
[14:51] <ari-tczew> doko: I see. what does it mean for me?
[14:53] <dholbach> cjwatson, that should be fine - I might write a script that goes and merges them (as Harvest does packagesets/etc. on its own) - let me quickly try it out
[14:53] <doko> so it wants to build for all python versions. uninstall python26-minimal and try again
[14:53] <cjwatson> dholbach: right, it's just easiest to spit them out that way
[14:53] <dholbach> cjwatson, don't worry - that's totally fine - should be easy to do :)
[14:53] <cjwatson> dholbach: I also just committed a grep-merges tool to ubuntu-dev-tools that uses that output
[14:54] <dholbach> awesome
[14:54] <dholbach> I'll report back in a few
[14:54] <dholbach> thanks in any case
[14:54] <cjwatson> so should at least be valid json ;-)
[14:54] <doko> ari-tczew: and it will fail later ...
[14:56] <ari-tczew> doko: could you fix it?
[14:56] <ari-tczew> (I can't)
[15:11] <dholbach> cjwatson, looking good :)
[15:11] <dholbach> (locally)
[15:12] <cjwatson> excellent
[15:29] <apw> cjwatson, where do the unity peeps hang out ?
[15:30] <dholbach> #ayatana probably
[15:32] <cjwatson> yeah
[15:37] <NCommander> ScottK: are you still interested in updating your +1 on my core dev app
[15:37] <ScottK> NCommander: I don't think we've worked on anything together recently?
[15:38] <hallyn_> hm, debootstrapping a lucid image on natty is giving me troubles
[15:39] <NCommander> ScottK: I poked you on that earlier lsat month, and I thought you wanted to revise what you said; are   you still confortable +1ing me?
[15:39] <ScottK> You did?
[15:40]  * ScottK lost those brain cells apparently.
[15:40] <ScottK> NCommander: Give me a link and I'll look.
[15:40] <NCommander> ScottK: I thought I did, or at elast said something at UDS. Granted, its been a long month
[15:41] <NCommander> ScottK: https://wiki.ubuntu.com/MichaelCasadevall/CoreDevApplication
[15:41] <ari-tczew> doko: I prefer to not uninstall python2.6-minimal - it will remove 50% of important packages.
[15:41] <ari-tczew> doko: I guess that you're talking about remove python2.6-minimal from B-D?
[15:42] <doko> ari-tczew: you should do development in a chroot where you can do stuff like this
[15:42] <ScottK> NCommander: I think it's still correct.
[15:42] <ari-tczew> doko: I use pbuilder. python2.6-minimal doesn't exist in debian/control
[15:49] <mok0> How to deal with a package distributed by svn only, and where upstream does not provide a .tar.gz file?
[15:49] <azeem> mok0: do they tag releases?
[15:49] <mok0> azeem: nope
[15:50] <pitti> mok0: do they have version numbers at all?
[15:50] <mok0> pitti: yes, svn revision numbers
[15:50] <pitti> I  mean "eleases"
[15:50] <azeem> then I'd just use 0.0.0~r<svn-revision> as version number
[15:50] <mok0> azeem: oh, they do have a version number yes
[15:50] <pitti> mok0: right, use 0.r1234 as fake version numbers and use make dist
[15:51] <mok0> pitti: ok... just seems going a detour, when everything is in LP
[15:51] <mok0> :-)
[15:52] <ion> Perhaps 0~r1234. That should accommodate any kind of future version number. :-)
[15:52] <pitti> mok0: well, you could use bzr-svn to import upstream's trunk, and create a branch with the packaging in it
[15:52] <pitti> ion: mathematically that's a really fun number
[15:52] <mok0> pitti: right, but I still need a tar.gz file for the source package
[15:53] <pitti> a non-negative number smaller than 0
[15:53] <ion> hehe
[15:53] <pitti> mok0: why?
[15:53] <pitti> mok0: you can call autoreconf in debian/rules, if you are worried about that
[15:53] <mok0> pitti, errh that was what I thought you said: "make dist"
[15:53] <pitti> mok0: right, you'd use that _if_ you want to create an orig.tar.gz
[15:54] <pitti> if you want to branch off trunk for a packaging branch, you don't have to
[15:54] <pitti> but your choice really
[15:55] <mok0> pitti: I see. I've never done packaging directly from a bzr before, so it's new territory for me.
[15:55] <pitti> it's not that different; you just need to ensure that you build the autoconfiscation
[15:55] <pitti> (if they use autotools)
[15:56] <mok0> pitti: they do
[15:58] <mok0> pitti, do you have a reference for a package I could study, that does not use an orig.tar.gz file?
[15:59] <pitti> hm, not off-hand
[16:01] <Keybuk> jdstrand: when somebody files four separate SEGV reports in the space of a minute, I'm afraid I begin to suspect something else wrong
[16:01] <Keybuk> jdstrand: so could you run memcheck86 on your machine please
[16:01] <jdstrand> Keybuk: they aren't mine
[16:01] <jdstrand> Keybuk: they are old and private. I just noticed them since I had access
[16:01] <Keybuk> are they not?  LP's make them sound like they are
[16:02] <Keybuk> ahh
[16:02] <Keybuk> LP fail then
[16:02] <jdstrand> Keybuk: so I subscribed you and james since I thought someone might be interested in seeing them :)
[16:02] <Keybuk> thanks
[16:02] <Keybuk> jdstrand: in general, subscribe james from now on
[16:02] <jdstrand> sure
[16:02] <Keybuk> he's the ubuntu maintainer now
[16:03] <jdstrand> Keybuk: ok, I did both of you this time, but noted
[16:03] <Keybuk> but I never mind being subscribed
[16:03] <Keybuk> I just mean avoid only subscribing me by accident, since I won't be here :p
[16:03]  * jdstrand nods
[16:04] <Keybuk> thanks :p
[16:04] <Keybuk> will take a quick look at these now
[16:04] <jdstrand> cool, thanks
[16:14] <doko> kenvandine: gtask, thanks for the upload, but better re-upload as ubuntu1 instead of buildN
[16:18] <kenvandine> doko, will do
[16:20] <kenvandine> doko, done
[16:22] <dholbach> cjwatson, it's on there! http://harvest.ubuntu.com/opportunities/ :)
[16:23] <cjwatson> neat!
[16:24]  * dholbach hugs cjwatson
[16:24] <dholbach> good work!
[16:30] <lamont> I wish that my system wouldn't randomly decide that a window should have the cursor grabbed when the window believes that it does not...  clearing that makes for some fun exploritory poking
[16:39] <seb128> cjwatson, could you review or merge https://code.launchpad.net/~smoser/ubuntu/natty/openssh/lp688574/+merge/43366 when you have some time?
[16:47] <cjwatson> I really wish that ssh-import-id weren't in openssh.  it's such a bad idea for it to be integrated there
[16:47] <cjwatson> it belongs in a separate package
[16:48] <cjwatson> seb128: Dustin's assigned it to himself, he can do it
[16:48] <cjwatson> (the bug)
[16:49] <kirkland> cjwatson: ?
[16:49] <cjwatson> kirkland: 16:39 <seb128> cjwatson, could you review or merge https://code.launchpad.net/~smoser/ubuntu/natty/openssh/lp688574/+merge/43366 when you have some time?
[16:49] <cjwatson> you assigned the bug to you so as far as I'm concerned you're taking care of that
[16:49] <kirkland> cjwatson: it was a separate package, we reviewed it in belgium, and i got the go ahead from you to drop it in openssh-server
[16:49] <cjwatson> over my protests
[16:49] <seb128> ups sorry, I was reviewing from the queue and just read the merge request, not the bug
[16:49] <cjwatson> I thought it was wrong but you wouldn't let up :(
[16:50] <cjwatson> bug 690436 is a great demonstration of why it should be separate
[16:50] <kirkland> cjwatson: ?  i'm sorry, i didn't under you protested it
[16:51] <cjwatson> it's bizarre that we have this thing that upstream doesn't care about, that's maintained totally separately from openssh to all intents and purposes, and yet it's in the openssh-server package
[16:51] <cjwatson> it's basically an Ubuntu server add-on
[16:53] <kirkland> cjwatson: are you asking for this in a separate source package, or a separate binary package under openssh ?
[16:53] <cjwatson> normally, source packages are divided along maintenance lines
[16:54] <cjwatson> I really don't know what I'm asking for any more, though, I just want not to have to worry about ssh-import-id TBH
[16:54] <kirkland> cjwatson: okay; i'm in the process of getting it upstream
[16:54] <cjwatson> you seriously think upstream will take it?
[16:55] <cjwatson> I am extremely doubtful
[16:55] <kirkland> cjwatson: to do that, smoser wanted to re-write it in the way that that merge request does
[16:55] <kirkland> cjwatson: i honestly have no idea;  i have never dealt with that upstream
[16:55] <kirkland> cjwatson: is ssh-copy-id upstream?
[16:55] <cjwatson> I think you're onto a loser
[16:55] <cjwatson> ssh-copy-id is, yes
[16:55] <cjwatson> but from ages and ages back
[16:56] <cjwatson> openssh upstream are extremely conservative, and rarely include anything significant that they didn't write themselves
[16:56] <cjwatson> maybe I'm wrong, but it would astonish me if they took ssh-import-id
[16:57] <kirkland> cjwatson: i see it in a contrib/
[16:57] <kirkland> cjwatson: i see this as ssh-copy-id, from the other direction
[16:57] <kirkland> cjwatson: ssh-copy-id securely pushes a public key;  ssh-import-id securely pulls a public key
[16:57] <kirkland> cjwatson: i mean, i can make a new source/binary package;  but it's one shell script and one manpage
[16:57] <cjwatson> you may see it that way, but I think it's unlikely that upstream will
[16:57] <cjwatson> pulling keys has much more interesting cryptographic properties
[16:58] <kirkland> cjwatson: right;  i don't know that upstream well enough to have any idea what they would say
[16:58] <cjwatson> pulling keys over SSL even more sos
[16:58] <cjwatson> *so
[16:58] <cjwatson> because that means SSL is now within their security boundary
[16:59] <cjwatson> not to mention the hardcoding of LP, etc.
[16:59] <cjwatson> (sure, that's fixable, although the hardcoding is a desirable part of the UI from Ubuntu server's point of view)
[17:00] <kirkland> cjwatson: it's configurable now
[17:00] <kirkland> cjwatson: the URL;  defaults to LP
[17:00] <cjwatson> bear in mind that even of patches I think are a good idea, or even blindingly obvious, I only have a 50% success rate or so at getting them upstream
[17:00] <cjwatson> when they do take them, they often rewrite them
[17:00] <kirkland> cjwatson: okay, well, i plan on dropping the script on that list out of courtesy
[17:01] <kirkland> cjwatson: if they have constructive criticism that I can address, I will
[17:01] <cjwatson> I'm pretty confident we're stuck with it forever
[17:01] <kirkland> cjwatson: if they tell me to go f myself, fine;  i've done my duty
[17:01] <cjwatson> but that's an ongoing maintenance problem
[17:01] <kirkland> cjwatson: now, what I really want to know is how you want this script to be packaged in Ubuntu, in the mean time
[17:02] <cjwatson> IMO the dependency issues are a good reason why at the very least it needs to be a separate binary package again
[17:02] <kirkland> cjwatson: it shouldn't be a maintenance problem;  it should just work; shouldn't need a lot of attention; it should do one thing and do it well
[17:02] <smoser> its very little on going maintenance, and a fairly high amount of "man that was easy"
[17:02] <cjwatson> there's a bunch of mail I have to ignore
[17:02] <cjwatson> any bunch of mail I have to ignore is a problem :)
[17:03] <cjwatson> look, I can procmail out anything with ssh-import-id in the subject if you really want, but I'm not sure that's constructive.  What I want is for it not to show up as part of openssh maintenance, because really, it's being maintained separately
[17:03] <kirkland> cjwatson: i'm subscribed to all bugs in openssh
[17:04] <cjwatson> I know, but so am I
[17:04] <cjwatson> things like this happen, where the patch pilot asks me about something and I honestly don't have a clue
[17:05] <kirkland> cjwatson: "don't have a clue" -- dude, you probably the smartest person I know ;-)
[17:05] <kirkland> cjwatson: but I understand, I don't want this to be your problem
[17:05] <cjwatson> I don't have a clue about the correctness or otherwise of this merge request
[17:05] <cjwatson> I view that as a problem, given that I maintain the package
[17:05] <cjwatson> whether it's my problem ... I'm not sure
[17:06] <kirkland> cjwatson: well, for the record, I would be happy for you to pass any and all ssh-import-id issues to me, and I'll deal with them at a high degree of urgency
[17:06] <cjwatson> but it seems to me that having these two disparately-maintained things in the same source tree is just creating extra work
[17:06] <kirkland> cjwatson: that said, i'll split this out to a separate package
[17:06] <Riddell> kees: I committed that patch to KDE thanks
[17:07] <kirkland> cjwatson: fine, i'll split it out;  can openssh-server recommend this package?
[17:07] <cjwatson> sure
[17:07]  * kirkland gets to work
[17:07] <cjwatson> thank you, my mailbox will appreciate it
[17:09] <jhunt> cjwatson: I've tweaked busybox for bug 683605, but am getting quilt errors on the 'dpkg-buildpackage -S'
[17:10] <cjwatson> jhunt: what's the text of the error?
[17:10] <jhunt> cjwatson: error is, "dpkg-source: error: can't build with source format '3.0 (quilt)': no orig.tar file found"
[17:10] <cjwatson> ah, ok, that's easy - cd to the parent directory, 'apt-get -d source busybox'
[17:10] <cjwatson> just so it has the upstream source available
[17:11] <cjwatson> I take it you generated a quilt patch for your change?
[17:11] <jhunt> ok - the parent dir does have the bzr upstream src, but clearly that ain't good enough :-)
[17:11] <jhunt> cjwatson: no - never used quilt.
[17:11] <cjwatson> aha, well you need to :)
[17:12] <cjwatson> back out your changes to start with
[17:12] <cjwatson> quilt new name-of-your-change.patch # look in debian/patches/ for examples
[17:12] <cjwatson> quilt edit util-linux/volume_id/linux_swap.c # or whatever
[17:12] <cjwatson> make your changes
[17:12] <cjwatson> quilt refresh
[17:13] <cjwatson> then edit debian/patches/name-of-your-change.patch according to http://dep.debian.net/deps/dep3/ so that we know why it's there in future
[17:13] <cjwatson> then you can build
[17:13] <cjwatson> the main thing to watch out for is just that quilt needs to know about any file you change before you edit it, so that it has a pristine copy - 'quilt edit' is basically 'quilt add; $EDITOR'
[17:14] <cjwatson> you can use the 'what-patch' tool in ubuntu-dev-tools to find out whether a package uses a patch system before you start editing it
[17:15] <kees> Riddell: great! thanks. :)
[17:15] <jhunt> cjwatson: thx! Re the apt-get src, I'm running maverick, but this bug is in natty, so a wget or similar instead presumably?
[17:15] <cjwatson> oh, yeah
[17:16] <cjwatson> dget http://archive.ubuntu.com/ubuntu/pool/main/b/busybox/busybox_1.17.1-7ubuntu4.dsc
[17:16] <cjwatson> sorry, dget -d
[17:17] <cjwatson> or I have http://paste.ubuntu.com/544096/ lying around in ~/bin/get-lp-package - 'get-lp-package ubuntu busybox 1:1.17.1-7ubuntu4'
[17:25] <ev> jhunt: or just put the natty deb-src in your sources.list
[17:26] <jhunt> ev: thx
[17:46] <seb128> kirkland, did you guys agree to use a new source? should the sponsors be unsubscribed from this bug for now then?
[17:46] <seb128> kirkland, the openssh one
[17:47] <kirkland> seb128: sure, just assign the bug to me
[17:47] <seb128> ok thanks
[17:49] <kirkland> cjwatson: presumably you're subscribed to  openssh-unix-dev@mindrot.org?
[17:49] <kirkland> cjwatson: and presumably you won't want me to explicitly CC you on my note to them?
[17:55] <cjwatson> kirkland: right
[17:55] <cjwatson> (well, I read it via a news gateway)0
[18:04] <jhunt> cjwatson: I'm confused by the Forwarded quilt field. I'm fixing this bug in lp:ubuntu/busybox, so to generate the upstream git patch, do I use the bzr-git to patch "lp:busybox" and export a git patch, mail to the busyboxy mailing list and then ref. *that* patch in my lp:ubuntu/busybox quilt patch?
[18:04] <cjwatson> jhunt: upstream will probably respond best if you just generate a patch using git format-patch for them
[18:05] <cjwatson> based on whatever their current tip of development is
[18:05] <cjwatson> jhunt: so normally, TBH, I just copy the patch around between two trees :)
[18:05] <juliank> Who does not love git format-patch?
[18:06] <cjwatson> though I mean a patch is a patch is a patch, so if you generate it with bzr-git I shouldn't imagine it would go too badly wrong
[18:06] <cjwatson> anyway, Forwarded just wants a URL so that you can show you've sent the patch somewhere
[18:07] <juliank> cjwatson: git patches can be applied directly and have a commit message; so it's a bit easier (just git am 0001-my-patch.patch)
[18:07] <jelmer> cjwatson, jhunt: "bzr send --format=git" generates git-format-patch-like patch files
[18:08] <juliank> jelmer: Cool
[18:09] <jhunt> cjwatson: thx, so I *think* I fix the bug in lp:busybox, bzr send it upstream, then pull that into lp:ubuntu/busybox as a quilt patch, build it, upload to ppa and request sponsorship. This bug is turning into a four-act epic... :)
[18:09] <jelmer> There's also "bzr diff --format=git". I'm not sure if anybody other than myself is using either at the moment though.
[18:11] <cjwatson> jhunt: it gets quicker as you build up habits
[18:12] <juliank> jelmer: I get bzr: ERROR: Bad value "git" for option "format". - am I missing something?
[18:12] <jhunt> cjwatson: whoever said this isn't easy? :)
[18:12]  * jhunt goes for a strong drink and a lie down...
[18:12] <jelmer> juliank: do you have bzr-git installed?
[18:12] <cjwatson> jhunt: I don't really think about it any more
[18:13] <juliank> jelmer: I thought I had it installed, but I didn't.
[18:13] <cjwatson> you get used to lobbing patches around into the right places
[18:18] <bdrung> ebroder: around?
[18:31] <smoser> pedro_, hggdh has implicated you. suggesting that you may have been running some lp:qa-regression-testing on lucid-proposed kernel (2.6.32-311.23)
[18:32]  * hggdh hides, fast
[18:33] <pedro_> smoser, yes, for this kernel cycle i've running test-kernel.py and test-kernel-root-ops.py
[18:34] <smoser> so do you have results ? i'm completely unaware of how long that takes or what it entails
[18:34] <pedro_> i do, one sec
[18:35] <pedro_> smoser, http://people.canonical.com/~pedro/kernel/
[18:35] <pedro_> smoser, in there you can find the results and as well from autotest and ltp for maverick, lucid and karmic proposed kernels
[18:36] <smoser> pedro_, so, that represents "PASS" ?
[18:36] <pedro_> yes
[18:39] <smoser> pedro_, so, based on that, i'm going to mark changelog mentioned bugs as "verification-done"
[18:39] <ebroder> bdrung: Here now; will be caught up on backlog momentarily
[18:39] <smoser> and i'll point at your results. do you have any issue with that?
[18:39] <pedro_> smoser, ok nice, i'm commenting on the tracking bugs right now
[18:39] <smoser> oh.
[18:40] <smoser> well, then you can do the 'verification-done' also
[18:40] <smoser> or maybe just let that up to an SRU person, but in the past pitti told me that i could change the tag if i'd done it.
[18:41] <pedro_> smoser, the tests were done by Monday but we were waiting for HW cert team to provide their results first, just following the https://wiki.ubuntu.com/Kernel/StableReleaseCadence#Tracking%20Bug%20Procedure
[18:41] <pedro_> smoser, but just a few minutes ago marjo said it's ok to comment on it and that the procedure is going to be fixed
[18:45] <marjo> pedro, smoser: according to sconklin, qa team can post results, but we shouldn't be changing any tags until both hw cert & qa team are done
[18:45] <pedro_> marjo, smoser ok our part is done (qa team) now we have to wait for hw cert
[18:45] <pedro_> for maverick, lucid and karmic kernels
[18:45] <marjo> pedro: ack
[18:46] <marjo> pedro: nice job!
[18:46] <pedro_> hggdh, ^ that goes for you too ;-)
[18:46] <pedro_> thanks a lot marjo
[18:46] <hggdh> pedro_: this is relative to kernel updates, right?
[18:47] <pedro_> hggdh, yes Señor
[18:48] <hggdh> pedro_: muchas gracias
[18:50] <bdrung> ebroder: i reviewed your backportpackage branch and i have some requests
[18:50] <smoser> ok, so someone from QA is going to mark the relavant bugs as "verification-done" ?
[18:50] <doko> I didn't like cmake that much in the past, but looking at the alternatives like handcrafted build systems and cmake, ... I do like it better
[18:50] <smoser> and we're waiting on some hw cert tests, is that right ?
[18:51] <pedro_> smoser, yes
[18:51] <smoser> any idea on how long that is going to be ?
[18:51] <smoser> (not nagging, asking)
[18:51] <pedro_> cr3, ^ ?
[18:52] <bdrung> ebroder: you probably have to unquote the dsc url from launchpad (to convert "%2b" -> "+")
[18:53] <bdrung> ebroder: you should evaluate if the package build process failed
[18:53] <ebroder> Keybuk, jhunt: I forget - why did you guys decide to do /etc/init/foo.override instead of a separate directory? Separate directories seems to me like it would enable more things easily down the road (e.g. using /etc/init.user + ~/.init for user sessions)
[18:54] <ebroder> bdrung: What do you mean by evaluate if the build failed? Right now it throws an error, doesn't it?
[18:55] <bdrung> ebroder: biulder.build(...) returns the return code of the build command (should be 0 on success)
[18:55] <bdrung> ebroder: example package for unquoting: qemu-kvm and abraca
[18:57] <ebroder> bdrung: Sure, the unquoting is easy. What do you think it should do if the build fails?
[18:58] <bdrung> ebroder: print an error and abort (if you don't like that, then change the default for the upload question to no)
[18:59] <ebroder> bdrung: Nope, I like bailing. It's nice and simple
[19:00] <bdrung> ebroder: i don't like global variables. you could pass lp to the function that require it.
[19:00] <ebroder> bdrung: :(, but ok
[19:01] <bdrung> ebroder: 4) instead of passing opts to the subfunction you could pass the needed opts.foo instead
[19:02] <bdrung> ebroder: optional 1) allow specifying the workdir (and then don't purge it)
[19:02] <bdrung> ebroder: optional 2) allow a dsc as input
[19:03] <bdrung> ebroder: optional 3) i want the workdir in /tmp for sponsor-patch too
[19:03] <bdrung> ebroder: 5) give examples in the man page of backportpackage
[19:04] <bdrung> cjwatson: should grep-merges be installed? then you have to add it to setup.py. and please add some examples to the man page of grep-merges
[19:05] <ebroder> bdrung: Ok, I can do all of those. Can I do the same thing - default to mkdtemp() and clean it up afterwards, unless you specify a working dir?
[19:05] <bdrung> ebroder: yes
[19:05] <ebroder> bdrung: Great
[19:05] <bdrung> ebroder: you can do the optional things in separate branches
[19:06] <bdrung> - i want to get your backportpackage branch merged
[19:07] <ebroder> bdrung: The optional things are generally easier than the non-optional ones, so I'll probably do them all at once :-P
[19:11] <ScottK> ebroder: I finally took a look at your merge request.  I have a couple of comments.
[19:12] <ScottK> 1.  -f tends to be kind of hard wired in people's brains as "force" (at least mine anyway).  Can we use something else?
[19:12] <ScottK> Maybe -s/--source -d/--destination?
[19:13] <ScottK> 2. Could to/destination default to whatever release the target system is running.  I suspect that will be by far the common case.
[19:13] <ebroder> Yeah, I described them like that at first, but I was worried that people would conflate --source and the source package name
[19:13] <ebroder> Yes, that's a reasonable default. I'll put that on my TODO
[19:13] <bdrung> ebroder: i like the -s/--source -d/--destination idea
[19:14] <ebroder> Ok. I have no objections to --source/--destination
[19:14] <ScottK> ebroder: Also it'd be nice if there were a way to specify a standard destination in a config file so you didn't have to specify it each time.
[19:15] <bdrung> i suggest to have a environment variable for that
[19:15] <bdrung> same for upload destination
[19:15] <ScottK> config file or environment variable are fine, but I think that might be a bit magical for non-experienced users.
[19:16] <ScottK> (where that == environment variable)
[19:16] <ebroder> ScottK: We already use environment variables in things like sponsor-patch, so this would be consistent. Also in backportpackage for things like UBUNTUTOOLS_BUILDER
[19:16] <ScottK> ebroder: Yes, but sponsor patch is aimed at a developer user and this targets a broader audience.
[19:17] <ScottK> Whichever you prefer though, I'm OK with it.
[19:17] <bdrung> ScottK: we could use the devscripts config file for setting the environment variables
[19:17] <bdrung> then we have both
[19:18] <ScottK> Sounds reasonable as long as it's documented.
[19:18] <ebroder> Whatever I do will end up in the manpage
[19:19] <bdrung> ScottK: bug #681693
[19:19] <ScottK> OK.
[19:24] <ebroder> bdrung: I'm thinking of supporting both an UBUNTUTOOLS_UPLOAD and BACKPORTPACKAGE_UPLOAD, and would probably also add a SPONSOR_PATCH_UPLOAD. Personally, I have separate PPAs for backports vs. non-backport tests, since the archive dependencies are different, so I want to be able to set that default separately. Seem reasonable?
[19:24] <bdrung> ebroder: yes
[19:25] <bdrung> ebroder: go ahead :)
[19:25] <ebroder> bdrung: Awesome. I'll try to get an update to my branch ready for you in the next day or two
[19:26] <bdrung> ebroder: ok
[19:31] <bdrung> ebroder: i would like to get a current version of backportpackage merged and then merge improvement (like upload env variables, workdir chnange, ...) merged separately (= easier to review)
[19:32] <bdrung> s/merged//
[19:37] <bdrung> ebroder: do you have the time to do the "required" task now and the optional ones later?
[19:40] <cr3> pedro_: which bug do you speak of, with smoser?
[19:40] <smoser> the current -proposed kernel update
[19:41] <cr3> smoser: I believe brendan updated the lucid one with something like in progress and it will be extended approprietaly when done, I believe
[19:45] <smoser> cr3, so, i'm just wondering what the time frame is
[19:45] <smoser> bugs referenced are bug 613381, bug 628776, bug 643891, bug 668380, bug 681132, bug 683257
[19:46] <cr3> smoser: my understanding is that certification only tests that systems can still install and boot the new kernel, whereas qa tests for specific regressions
[19:47] <smoser> well, yes. and they've run that test suite, so i'm just wondering when you would expect that the certification tests would be done
[19:47] <cr3> smoser: Friday
[19:48] <cr3> smoser: please be patient with us, we're training new folks so that we can reduce the timeframe over time
[19:49] <smoser> cr3, i promise, i'm just asking
[19:50] <cr3> smoser: cool, just thought I'd take this opportunity to reassure you we'll be getting awesomer :)
[19:51] <seb128> @pilot out
[19:53] <bdrung> great work seb128 - we are down to 32 task waiting for sponsoring
[19:53] <seb128> bdrung, thanks
[19:54] <bdrung> seb128: now i can see the whole sponsoring table without scrolling :)
[19:54] <seb128> ;-)
[20:00] <ebroder> bdrung: Probably not until this evening - I should probably at least pretend to do work while I'm at work :)
[20:01] <bdrung> ebroder: you are doing work - work for ubuntu :P
[20:01] <bdrung> ebroder: in which time zone do you live?
[20:03] <ari-tczew> bdrung: which resolution do you use?
[20:04] <bdrung> ari-tczew: fullhd - 1920x1080
[20:04] <bdrung> ups - 1920x1200
[20:04] <ari-tczew> bdrung: aaa, then you can use look on SQ without scrolling :P
[20:04] <ari-tczew> bdrung: btw. could you sponsor BlackZ's merges for main? some of them are lying so long
[20:05] <bdrung> ari-tczew: which one?
[20:05] <ari-tczew> bdrung: bug 685860 and bug 681418
[20:08] <ebroder> bdrung: US/Pacific
[20:10] <bdrung> ebroder: that explains a lot
[20:36] <aantn> beuno: are you martin albisetti?
[20:36] <beuno> aantn, yes I am
[20:48] <cjwatson> bdrung: I *did* add it to setup.py, didn't I?
[20:49] <cjwatson> oh, blast, forgot to commit that bit
[20:49] <cjwatson> bdrung: do you think it needs examples?  it's really simple :)
[20:49] <bdrung> cjwatson: no, you didn't. :P
[20:50] <bdrung> cjwatson: yes, what kind of regexp are commonly used?
[20:50] <cjwatson> I had the diff locally, honest
[20:50] <cjwatson> it's just a substring match
[20:50] <cjwatson> anyway, have to go for dinner, I'll do that part later
[20:57] <apw> cjwatson, it feels like linux-headers package installs are taking a long time on natty again ... has something changed ?
[21:42] <hallyn_> hm.  'bzr: ERROR: Merge upstream in merge mode is not yet supported.
[21:43] <hallyn_> kirkland: ^  that's what i get when i do 'bzr merge-upstream' from the vmbuilder-packaging tree
[21:53] <cjwatson> apw: dunno, but things are *going* to change again in dpkg so not worth debugging right now
[21:53] <cjwatson> apw: you can put force-unsafe-io in /etc/dpkg/dpkg.cfg now to turn off fsyncs across the board (at your own risk)
[21:54] <apw> cjwatson, ok thanks, i'll just leave it be, and keep an eye on it
[21:54] <cjwatson> we did go back to fsync(2) because sync(2) caused other problems - but there's a dpkg 1.15.8.7 on its way soon
[21:54] <cjwatson> which uses sync_file_range(2) at tytso's suggestion
[21:55] <apw> cjwatson, sounds interesting
[21:56] <apw> cjwatson, we ended up needing to do a quick upload for something else so that vt numbering change is in with it ... should be built by the morning
[21:57] <cjwatson> cool, thanks
[21:57] <cjwatson> bdrung: example added no
[21:57] <cjwatson> now
[22:31] <barry> can someone with perms please retry this build: https://launchpad.net/ubuntu/+source/pymvpa/0.4.5~dev23-2build1/+build/2076605
[22:32] <barry> i think the underlying bug that caused this has been fixed (iow, it wfm locally)
[22:33] <ebroder> barry: Sure, just a sec
[22:33] <barry> ebroder: thanks
[22:33] <ebroder> Done
[22:35]  * barry watches and crosses his fingers
[22:47] <kirkland> any idea why right clicking is not working in Natty?
[22:49] <crimsun> lool: while cleaning BTS, I noticed #460197. Are you experiencing this in Ubuntu as well?
[22:49] <geser> I hope we don't optimize for mice with one button :)
[22:53] <kirkland> https://bugs.launchpad.net/ubuntu/+source/sudo/+bug/690873
[22:54] <kirkland> be very careful if you upgrade sudo right now in natty ....
[22:58] <kirkland> kees: https://bugs.launchpad.net/ubuntu/+source/sudo/+bug/690873
[22:58] <kirkland> kees: looks like blackz did the merge earlier today
[22:59] <micahg> bdrung: ^^
[22:59] <kirkland> kees: debian has changed /etc/sudoers to be a conffile, and wants to use a /etc/sudoers.d dir
[22:59] <kees> yeah, looks like sudo made /etc/sudoers a conffile when it wasn't one before.
[22:59] <kees> I can't find what added %admin originally...
[22:59] <StevenK> d-i?
[22:59] <kees> StevenK: not sure, but we need to fix sudo quickly and hard!
[23:00] <kirkland> kees: possibly installer magic?
[23:00] <StevenK> Do we want to block the sudo update on the mirror?
[23:00] <kees> I don't see it in any maintainer scripts I have installed, so yeah, must be installer.
[23:01] <wgrant> Has someone told ubuntustatus on identi.ca and twitter?
[23:01] <kees> slangasek: do you know this area at all?
[23:01] <ebroder> kees: Any chance it's user-setup or something like that?
[23:01] <Laney> can you still block updates after they have been mirrored?
[23:01] <wgrant> Laney: Sort of.
[23:01] <kees> kirkland: can you pastebin the resulting sudoers file from sudo?
[23:01] <wgrant> Laney: We can chmod -r
[23:01] <kirkland> kees: sure
[23:01] <wgrant> And then force a mirror push.
[23:02] <Laney> yeah, like that
[23:02] <kirkland> kees: before or after?
[23:02] <kees> elmo: awake?
[23:02] <kees> kirkland: after
[23:02] <kirkland> kees: http://pastebin.com/g1ghJNaX
[23:02] <kirkland> kees: that's straight out of debian/sudoers in the current sudo source
[23:02] <kees> Ugh. Yeah, it even removes the ticket defaults.
[23:03] <kirkland> StevenK: I think it would be a good idea
[23:04] <wgrant> Who has access to identi.ca/ubuntustatus?
[23:04] <kirkland> StevenK: the conffile conflict defaults to "N" (keep my local copy), which is "something";  but I still breezed over the diff without noticing the -%admin the first time
[23:04] <wgrant> It is for precisely this purpose.
[23:04] <kirkland> wgrant: not sure ... rickspencer3 ?
[23:04] <kirkland> robbiew: ?
[23:05] <JackyAlcine> Evening, guys.
[23:06] <kirkland> kees: http://pastebin.com/Sze9Yk3H
[23:06] <kirkland> kees: that's the unbroken one
[23:06] <kirkland> kees: as a quickie, we could put the contents of that into the sudo package's debian/sudoers file
[23:06] <ebroder> kees: Ticket defaults? I don't remember there ever being ticket defaults...
[23:06] <kirkland> kees: so at least there's no diff when upgrading
[23:07] <ebroder> kirkland: We probably shouldn't if we were adding it as part of the installer before. That'd be a change in behavior for...people who do screwy things not involving the installer
[23:07] <kirkland> kees: for those who haven't modified their /etc/sudoers
[23:07] <ebroder> kees, kirkland: The snippet is added by user-setup-apply in user-setup
[23:08] <kees> ebroder: ah, good find.
[23:08] <ebroder> Don't know if there's separate code somewhere in ubiquity
[23:08] <ebroder> cjwatson or ev would have a better idea
[23:08] <kees> kirkland: everyone has modified their /etc/sudoers because it's going from non-conffile to conffile, iiuc.
[23:08] <kirkland> kees: yes, but the delta could be zero
[23:09] <ebroder> kees: Yeah, looks like there's a copy of the user-setup source package in d-i/source/user-setup in ubiquity
[23:09] <kirkland> kees: anyway, that would just be quick and dirty to keep this from breaking in the near term
[23:09] <ebroder> So you'd need to be sure to update that as well
[23:09] <StevenK> ebroder: There's a script in ubiquity that will sync new code from d-i into it
[23:09] <kees> so, it looks like this will only break people if they say "Y" to the prompt
[23:09] <kirkland> kees: correct
[23:10] <ebroder> How hard would it be for sudo's postinst to take everything in /etc/sudoers that didn't ship there and throw it in /etc/sudoers.d/50-custom? (Conditionalized on dpkg --compare-versions "$2" -lt "whatever", or whatever)
[23:10] <StevenK> kirkland, kees: If DEBIAN_FRONTEND is noninteractive, the default is N, right?
[23:10] <kirkland> StevenK: yes
[23:11] <kees> StevenK: right
[23:11] <kees> so, I thought the defaults were Defaults!lecture,tty_tickets,!fqdn for sudoers?
[23:11] <kees> did that go away?
[23:11] <ebroder> kees: I don't remember ever seeing that in any of my sudoers files
[23:11] <kirkland> kees: from where I was sitting, though, I knew that I hadn't modified my own local /etc/sudoers, so I figured, meh, whatever Ubuntu recommends is good 'nough for me
[23:11] <kees> hunh
[23:12] <ebroder> kees: Looks like we compile those defaults in
[23:12] <ebroder>   * Merge from debian unstable.  Remaining changes:
[23:12] <ebroder>    - debian/rules:
[23:12] <kees> ebroder: yup, this is an oooold sudoers file :)
[23:12] <ebroder>      - compile with --without-lecture --with-tty-tickets (Ubuntu specific)
[23:19] <kirkland> kees: hmm, so what do you think we should do with this?
[23:20] <StevenK> kirkland: Do you think we should block the update and upload a revert?
[23:20] <kees> kirkland: get the foundations folks to look at it. it'll only get people into trouble if they answer "Y", so I don't think this exactly qualifies for an archive block.
[23:21] <wgrant> kees: I would Y, since I know I haven't modified it myself.
[23:21] <kees> wgrant: it'll _always_ prompt, though, since it wasn't a conffile before. it'll prompt _everyone_.
[23:21] <StevenK> So perhaps an ubuntustatus and u-d-a mail warning?
[23:21] <kirkland> wgrant: right, that's more or less what I did
[23:22] <kees> wgrant: ah, I see what you mean now
[23:22] <wgrant> (I personally wouldn't, but I know lots of people who would)
[23:22] <ebroder> We should definitely change user-setup to use sudoers.d. That seems like it should be uncontroversial and will at least unbreak new installs
[23:22] <kees> StevenK: what about an upload that doesn't ship the sudoers file for now?
[23:23] <kees> I really don't know the best way to approach this.
[23:23] <kirkland> kees: yeah, i basically have that here now
[23:23] <StevenK> I'm not sure either
[23:23] <kirkland> kees: it's just a couple of lines to comment out of debian/rules
[23:23] <ebroder> The upgrade path is annoying because the change was made by a package that doesn't get installed on the real system
[23:24] <micahg> BTW, conffile change is debian 605130 FWIW
[23:24] <StevenK> lamont: If you're around, ^
[23:25]  * kees ponders a preinst that detects %admin and writes a file into /etc/sudoers.d for it.
[23:25] <kees> gah, what a mess.
[23:25] <wgrant> Block and revert the update for now, I think.
[23:26] <StevenK> Going from no conffile to conffile is always going to suck. Rocks.
[23:26] <wgrant> Then a proper fix can be devised at our leisure.
[23:26] <kees> wgrant: yeah, probably true.
[23:26] <kirkland> kees: actually, the easiest solution would be to just put the necessary %admin bit in the new /etc/sudoers.d
[23:26] <ebroder> kees: What about detecting if sha1sum /etc/sudoers == "some known value" (or alternatively in [list, of, known, values]), and if it does (is), writes the %admin line to /etc/sudoers.d and resets /etc/sudoers?
[23:27] <ebroder> kirkland: I don't think the sudo package should unconditionally put the %admin line in. That's not what it's done previously
[23:27] <kirkland> kees: people who answer "N" will continue working as normal
[23:27] <micahg> ebroder: that won't help if people add select sudo rights
[23:27] <kees> ebroder: right, I think that'll likely be the solution, but gathering that list of known values, or the stuff around it is what'll take time to test right
[23:27] <ebroder> micahg: Yes, but if they know they've modified the conffile, they'll look more closely
[23:27] <kirkland> kees: ah, i just saw your ponderance
[23:27] <kirkland> kees: yeah, that's fine
[23:30] <slangasek> kees: ugh; not deeply familiar, no
[23:31] <kees> slangasek: okay, no worries.
[23:32] <ebroder> kees: I don't know about older releases, but Maverick's sudo.postinst doesn't change /etc/sudoers on upgrades. If that's true going back, then there shouldn't be many cases to test for
[23:33] <kees> ebroder: right, it should be finite, but I don't want to gather that list in a rush.
[23:33] <ebroder> kees: Yeah, that's reasonable
[23:34] <Laney> everyone is going to get a conffile prompt regardless, right?
[23:34] <slangasek> shouldn't, if it's fixed right
[23:34] <ebroder> Laney: Not if we reset /etc/sudoers to match the conffile in a preinst :)
[23:34] <Laney> what conffile? it wasn't one before
[23:34] <ebroder> Oh, hmm. Maybe you just remove the old file?
[23:35] <slangasek> why wouldn't we just add the %admin line into the conffile as shipped?
[23:35] <kees> Laney: right, a well-written preinst will handle the existing /etc/sudoers and potentially remove it completely
[23:35] <Laney> right
[23:35] <slangasek> instead of trying to match what Debian is doing here
[23:35] <kees> slangasek: hunh, yeah, I guess that would be reasonable as a crisis-workaround.
[23:36] <kirkland> kees: they have a %sudo line in theres
[23:36] <kees> slangasek: the prompt needs to be fixed regardless, but that would stop people from having unsudoable systems
[23:36] <Laney> that's a reasonable immediate fix
[23:36] <slangasek> kees: fwiw I think it might even be the correct long-term solution
[23:36] <ebroder> slangasek: I kind of figured someone made a deliberate choice to put the %admin line in user-setup instead of in sudo
[23:36] <kees> ebroder: yeah, that was my thinking too
[23:36] <slangasek> kees: if it's done correctly to where the conffile now matches the default generated file, then the conffile prompt goes out anyway
[23:37] <Laney> even if this is becoming a conffile for the first time?
[23:37] <Laney> if so, then +1
[23:37] <slangasek> yes
[23:37] <kees> slangasek: it's different at least due to the change of uncommenting the "include" directive
[23:37] <slangasek> ah
[23:37] <slangasek> in that case you'd have to do the preinst md5sum && rm trick
[23:38] <Laney> seems like something that would be reasonable for dpkg-maintscript-helper
[23:38] <kees> yeah, there's a non-trivial number of possible contents for the default /etc/sudoers, depending on which release you first installed. :(
[23:38] <slangasek> but still, I think it's simpler for the conffile to include everything we expect to be there on upgrade
[23:38] <hallyn_> all rightg whoever just uploaded sudo with cldeaned ut conffile is on mhy naughty list :)
[23:38] <kirkland> hallyn_: yup
[23:38] <ebroder> hallyn_: Read the scrollback. It never had the %admin line, so this is a non-obvious multi-package interaction
[23:38] <kirkland> hallyn_: https://bugs.launchpad.net/ubuntu/+source/sudo/+bug/690873
[23:40] <kirkland> hallyn_: that's quite possibly the worst typo'd sentence I've ever seen from you :-)
[23:40] <Laney> drunk with no-more-sudo rage
[23:40] <kees> haha
[23:40] <hallyn_> :)
[23:41] <hallyn_> on n900
[23:41] <kirkland> :-)
[23:41] <kirkland> hallyn_: sudo locked you out of your system then?
[23:41] <hallyn_> yeah, but i was walking ojut the door
[23:41] <kirkland> hallyn_: boot a live cd, mount your root disk and:
[23:42] <kirkland> echo "%admin ALL=(ALL) ALL" >> /etc/sudoers
[23:42] <kirkland> well, to /etc/sudoers on your root disk, of course
[23:42] <hallyn_> kirkland: no worries i have reswcue mode
[23:42] <ebroder> kirkland, hallyn_: If you put it in /etc/sudoers.d/admin instead, you won't run into this problem in the future
[23:46] <ebroder> So it looks like user-setup has been adding the %admin line since more or less time immemorial. r1 of user-setup in UDD :)