[00:45] <nemo> so https support is added to apt finally...
[00:46] <nemo> ... about a week after I manage to get an exception made in the stupid websense firewall at work for one ubuntu mirror
[00:46] <nemo> oh well. should simplify adding other apt lines.
[00:46] <nemo> (they ignored https since they could sniff it very effectively)
[00:47] <nemo> they *could* request same file and make a deny decision based on that, but they fortunately don't
[00:52] <maxb> nemo: er? apt has had https support for years
[00:55] <nemo> oh? huh. I guess none of the mirrors have support
[00:55] <nemo> I'd tried a bunch of 'em w/o success
[00:55] <nemo> was just reading through latest updates to apt on natty, and one was about adding https as a transport
[00:55] <nemo> supporting it in deb lines
[00:56] <nemo> oh well, I got 'em to open up mirror.anl.gov  (picked it because it was short and official sounding)
[00:56] <nemo> so hopefully no more stupidity with websense
[00:56] <nemo> I also complained to websense, but that went absolutely nowhere
[01:14] <echosystm> i need to package something up that uses a postgresql database and opens up a particular user to the world
[01:14] <echosystm> is there some kind of includes folder for the pg_hba.conf settings?
[01:16] <nibalizer> hi all, anybody had any luck making a puppet 2.7.1 package?
[02:28] <echosystm> can anyone point me towards some information about packaging applications that use postgres?
[02:28] <echosystm> or examples?
[02:33] <broder> echosystm: i might take a look at http://people.debian.org/~seanius/policy/dbconfig-common-using.html/ but i don't know how official that is
[02:36] <echosystm> thanks
[04:19] <pitti> Good morning
[04:20] <Gryllida> hi
[04:21] <pitti> apw: thanks! I'll send it to Gustavo and prepare a new release
[05:05] <RAOF> pitti: Re: bug #790145 - I'm pretty sure that the fixes for bug #786941 that were in the -proposed but not verified 0.12.3+noroms-0ubuntu9.7 package aren't in the new 0.12.3+noroms-0ubuntu9.10 that's now in proposed.
[05:05] <pitti> RAOF: right, I thought that was the idea?
[05:06] <RAOF> I thought the idea was that the 0.12.3+noroms-0ubuntu9.8 which had the fixes for both bugs had been superceded by the 9.9 from -security, so the proposed version needed to have the 9.9 changes folded in?
[05:06] <pitti> yay! there, working editmoin heading archivewards
[05:08] <RAOF> Oh, hai.  82% swap usage?  Maybe that's why things are stuttering every now and then :)
[05:09] <pitti> RAOF: in https://bugs.launchpad.net/ubuntu/+source/qemu-kvm/+bug/790145/comments/24 Serge said that they will only re-attempt that other SRU on request
[05:12] <RAOF> So, at minimum what should happen is the 786941 should lose the ‘fix committed’ status.  I would have thought that we didn't want fixes dropping out of the package like that, but I guess the unverified status makes things different.
[05:22] <pitti> RAOF: at least they shouldn't block other fixes to go in, yes
[05:25] <RAOF> Oh, arse.  Why did I think that would work?
[05:30] <RAOF> pitti: I think bug #804655 should be fixed for A2, and it's got a simple and cringeworthy fix.  It's not too late to upload mesa, right?
[05:31] <pitti> RAOF: we can re-roll CDs; I need to go through the tracker still, but right now I'm not aware of any other major breakage
[05:31] <pitti> RAOF: so please upload away
[05:31] <RAOF> Thanks.
[06:46] <didrocks> good morning
[06:58] <dholbach> good morning
[07:00] <pitti> RAOF: how big of an issue is 804655? does it cause the live CD to fail on these devices?
[07:01] <pitti> RAOF: once jibel is up, I'll ask whether we can do another round of testing, but I'd like to know more about how bad it is
[07:01] <RAOF> pitti: It causes unity to fail to work properly on the live CD.
[07:01] <pitti> shouldn't it fall back to unity-2d?
[07:01] <RAOF> It should, yes.
[07:02] <RAOF> It's not a horrific problem, and if you'd prefer it to miss A2 it certainly can.
[07:02] <pitti> it doesn't change the "should be uploaded now" part, of course
[07:02] <pitti> (then upgrades will get the fix, and if we need to respin for other reasons, we'll grab it)
[07:03] <RAOF> Aha!
[07:03] <pitti> RAOF: ok, thanks; so let's see what jibel says
[07:04] <RAOF> Waiting for the test build to finish to ensure I haven't made any other braindead mistakes :/
[07:14] <poolie> pitti, hi!
[07:15] <pitti> hey poolie, how are you?
[07:15] <poolie> good thanks, a little tired
[07:15] <poolie> about the bzr 2.3.3 natty sru
[07:15] <poolie> first, thanks for accepting it into proposed
[07:15] <poolie> there is a regression in it, bug 786980
[07:16] <poolie> so, we should cancel the SRU
[07:16] <poolie> it's not a catastrophic regression but still it shouldn't go in
[07:16] <poolie> i'm not quite sure where to formally say that - on one of the SRU bugs?
[07:17] <pitti> poolie: yes, on any of those would be good
[07:17] <poolie> and i guess mark it 'verification-failed'? not actually true but might have the right effect
[07:22] <pitti> poolie: right; I was going to do that, but feel free to do it yourself
[07:23] <poolie> done, thanks
[07:26] <broder> hmm...does the version of grub2 in maverick not support usb 3.0 boot?
[07:26] <broder> i would have sworn i had tried this when i was prepping bug #565047, but i can't seem to make it past grub now
[08:42] <cjwatson> dupondje: courier> no
[08:43] <cjwatson> dupondje: feel free
[08:54] <dupondje> cjwatson: prepared one (https://bugs.launchpad.net/ubuntu/+source/courier/+bug/803176)
[08:57] <ogra_> cjwatson, oh, back from holiday ? i thought you were out the whole week
[08:59] <cjwatson> broder: grub doesn't have EHCI yet, no.  somebody posted a patch for it to grub-devel a week or two ago
[08:59] <cjwatson> ogra_: no, just one day
[08:59] <ogra_> cjwatson, the code live-build uses for ext2/3/4 creation doesnt come from livecd-rootfs, right ? seems resizing got massively slow with the way these images are formatted
[08:59] <ogra_> a 4G SD card takes about 25min here (used to be 20-30sec with livecd-rootfs generated images)
[09:00] <cjwatson> ogra_: no, it's separate, the livecd-rootfs code had accreted various weirdnesses and I didn't see a particular reason to keep it
[09:00] <cjwatson> it's basically just mkfs.ext3 and copy stuff in
[09:00] <ogra_> well, i think we adjusted the inode count or some such to make resizing faster
[09:00] <cjwatson> I thought I mirrored that
[09:00] <cjwatson> but feel free to patch it
[09:00]  * ogra_ will have to check the code ...
[09:01] <cjwatson> I'm not going to look at it any further at this point
[09:01] <ogra_> k, will do
[09:18] <pitti> @pilot in
[09:20] <ogra_> grmbl ... live-build ...
[09:20]  * ogra_ curses
[09:20] <ogra_> so it seems i get a broken sources.list on ports ...
[09:27]  * ogra_ wonders why he sees irqbalance running all the time, i though that should only start once on boot and kill itself again
[09:29]  * dholbach hugs pitti
[09:29]  * pitti hugs back dholbach
[09:29] <pitti> quite sizable queue this morning :)
[09:30] <dholbach> yeah, there's quite a lot going on
[09:30] <seb128> thanks to a week of rally with no sponsoring
[09:30] <dholbach> I sponsored a few :)
[09:31] <dholbach> but not too many
[09:31] <seb128> I just cleaned a few as well
[09:31] <dholbach> nice
[09:31] <seb128> well, I tend to do desktop sponsoring often but those don't show up on the queue
[09:31] <seb128> just on our versions page
[09:31]  * dholbach nods
[09:50] <dupondje> Whats the default umask on launchpad builders ?
[09:51] <pitti> dupondje: hey
[09:51] <pitti> dupondje: I had expected 022 as well
[09:51] <pitti> infinity, lamont ^ do you know?
[09:52] <pitti> it's about https://launchpad.net/ubuntu/+source/courier/0.66.1-1ubuntu1/+build/2611450/+files/buildlog_ubuntu-oneiric-i386.courier_0.66.1-1ubuntu1_FAILEDTOBUILD.txt.gz which complains about the buildd umask
[09:52] <dupondje> Nothing changed in that part of the code neither, so before it was 022
[09:53] <soren> Well, the umask changed in Oneiric, didn't it?
[09:53] <soren> https://lists.ubuntu.com/archives/ubuntu-devel-announce/2011-June/000862.html
[09:54] <soren> Why would the buildd's be different?
[09:54] <pitti> soren: it only affects users with a private user group
[09:54] <infinity> pitti: Which the buildd user is.
[09:55] <infinity> pitti: buildd:buildd
[09:55] <pitti> if the buildd user falls into that case, then the umask would be 002
[09:55] <pitti> dupondje: ^
[09:55] <ogra_> infinity, you are talking in your sleep !
[09:55] <pitti> infinity: thanks
[09:55] <infinity> ogra_: Too hot here, keep waking up. :/
[09:56] <infinity> dupondje: To be fair, a test for an EXACT umask in a build system is daft.
[09:57] <soren> No.
[09:57] <infinity> soren: Yes? :)
[09:57] <soren> What is daft is to require a specific umask, but not just set it, but rather complain when it's wrong.
[09:57] <infinity> soren: well, yes, that too.
[09:57] <soren> Now *that* is daft.
[09:57] <infinity> soren: But you're still doing something wrong if you need to set a umask to build things, IMO.
[09:57] <pitti> dupondje: so I suppose debian/rules should call "umask 022" before calling build?
[09:58] <dupondje> yep
[09:58] <soren> infinity: Generally, yeah.
[09:58] <dupondje> fixing that now
[09:58] <infinity> You could just remove the test too.
[09:58] <infinity> Since whatever it wants the umask set for (make install, probably) will just get fixed later by dh_fixperms
[09:59] <infinity> debhelper: working around broken upstreams for over a decade.
[09:59] <dupondje> It has been introduces here:
[09:59] <dupondje>   * check umask in debian/rules because Courier requires umask 022 for
[09:59] <dupondje>     installation (Closes: #157149)
[09:59] <infinity> Err.
[10:00] <infinity> Wait, that was in debian/rules, not the upstream makefiles?
[10:00] <infinity> I didn't even look.
[10:00] <infinity> Now that's EXTRA broken.
[10:00] <infinity> This is the part where I back away slowly before I NMU the Debian package in a fit of rage.
[10:00]  * infinity goes to try to sleep some more.
[10:01] <geser> infinity: I hope you don't get any nightmares from this
[10:03] <soren> infinity: I'm trying to visualise you trying to fall asleep in a fit of rage.
[10:03] <soren> infinity: It doesn't look easy.
[10:11] <dupondje> pitti: I added new patch now
[10:16] <pitti> dupondje: uploaded, thanks! You might want to send that to Debian as well
[10:27]  * dupondje doesn't get it anymore now
[10:34] <Laney> hey, I just noticed that Debian asks derivatives to add a popcon url, rather than replacing theirs with ours. Why don't we do this? http://wiki.debian.org/Derivatives/Guidelines#Popularity_Contest
[10:35] <tumbleweed> Laney: isn't our popcon around 10* higher than debian?
[10:37] <tumbleweed> (I mean, debian wolud need a way to distinguish between the two)
[10:37] <Laney> they ask for it.
[10:38] <Laney> I think it's not supposed to be 'how many debian users use this package'
[10:38] <Laney> (see the page I linked)
[10:39] <tumbleweed> Laney: yeah, I know, but I still think Ubuntu is a little different from other derivatives here
[10:39] <Laney> I don't see why it's not relevant
[10:40] <pitti> dupondje: wah, failed again :/
[10:40] <Laney> as long as you use the data wisely, of course
[10:40] <pitti> https://launchpadlibrarian.net/74640246/buildlog_ubuntu-oneiric-i386.courier_0.66.1-1ubuntu2_FAILEDTOBUILD.txt.gz
[10:41] <pitti> dupondje: did you actually try to build this under a 002 umask? (so that it would fail before)
[10:41] <dupondje> I did a testbuild here. worked fine
[10:42] <tumbleweed> Laney: I'd want to know waht the popcon maintainers in debian think, and why we never submitted to them in the first place (was it just because we predated http submission?)
[10:42] <dupondje> Its strange, umask gets set without errors, but still its broken somehow
[10:43] <Laney> sure, that's why I asked
[10:47] <infinity> dupondje: Err.  You can't set the umask in a makefile like that.
[10:48] <infinity> dupondje: Every call in make is a forked shell, it will inherit the umask of the parent (make), not the previous shell call.
[10:48] <infinity> dupondje: Are you positive the package will actually FTBFS if you just remove the silly check?
[10:49]  * infinity notes that the check was added 9 years ago, a lot may have changed...
[10:52] <dupondje> The check is still in the Makefile
[10:52] <dupondje> to check if umask is 022
[10:52] <infinity> In which Makefile?
[10:52] <infinity> The upstream one?
[10:52] <tumbleweed> Laney: -> debian-derivatives?
[10:53] <dupondje> Makefile.in:	@test `umask | sed 's/^0*//'` = 22 && exit 0; \
[10:54] <pitti> dupondje: perhaps try something like
[10:54] <pitti> -                && $(MAKE) LIBTOOL=/usr/bin/libtool && touch stamp-build; \
[10:54] <pitti> +                 && umask 022 && $(MAKE) LIBTOOL=/usr/bin/libtool && touch stamp-build; \
[10:54] <pitti> and drop the umask check before?
[10:55] <infinity> It only checks on make install
[10:55] <infinity> Which makes some sense.
[10:55] <infinity> (Still broken for Debian, but makes sense for tarball dists)
[10:56] <pitti> dupondje: perhaps try something like
[10:56] <pitti> -                && $(MAKE) LIBTOOL=/usr/bin/libtool && touch stamp-build; \
[10:56] <pitti> +                 && umask 022 && $(MAKE) LIBTOOL=/usr/bin/libtool && touch stamp-build; \
[10:56] <pitti> and drop the umask check before?
[10:56] <dupondje> I'll test that :)
[10:56] <pitti> (sorry if that came through twice, DSL reconnect)
[10:56] <dupondje> :)
[10:56] <Laney> tumbleweed: already did
[10:56] <infinity> You can also export INSTALL_IGNORE_UMASK=1 to skip the check.
[10:57] <Laney> actually there was (as is often the way) a fizzled out thread there already
[10:57] <infinity> dupondje: pitti's patch won't do you any good.
[10:57] <pitti> infinity: why not? it's the same shell?
[10:58] <infinity> dupondje: Either export INSTALL_IGNORE_UMASK=1, or set the umask before each $(MAKE) call in the install target in debian/rules.
[10:58] <infinity> pitti: It's install that checks for umask, not the build.
[10:58] <infinity> pitti: (which makes sense, for tarballs distribution)
[10:58] <infinity> pitti: Makes less sense for Debian. :P
[11:00] <dupondje> first fixing pbuilder-dist now on my build system, so I can try different tests :D
[11:00] <dupondje> cause debootstrap seems broken somehow :s
[11:02] <tumbleweed> Laney: ah right, that's where I saw it. pere seemed to discourage it for distros who deviate from debian a bit
[11:04] <infinity> dupondje: http://paste.ubuntu.com/638828/
[11:04] <infinity> dupondje: That should do it.
[11:04] <dupondje> thanks, will try it out
[11:05] <infinity> (It will actually work if you only umask the first install call, but doing both is more in the spirit of what upstream wanted. :P)
[11:05] <infinity> Their install-perms target in Makefile.in should depend on install-check-umask, but doesn't.
[11:06] <dupondje> The package is not the cleanest one around indeed :(
[11:06] <infinity> Nope.
[11:24] <seb128> cjwatson, ev: could you drop the ubiquity libcheese-gtk-dev build-depends next time you upload it?
[11:24] <dupondje> infinity: https://launchpadlibrarian.net/74642842/umask_fix2.debdiff
[11:27] <ev> seb128: sure
[11:30] <seb128> ev: thanks
[11:30] <seb128> ev: I want to demote cheese since the current version doesn't build and we will need a bunch of mirs, if we need it in main we should handle it properly and not let it depwaiting as it's doing
[11:31] <seb128> it will need mir and gst components from the universe sets
[11:37] <dupondje> pitti: uploaded new fix. Should do the trick now
[11:43] <infinity> dupondje: Looks correct.
[11:45] <dupondje> build fine also :)
[12:04] <infinity> dupondje: Uploaded for you.
[12:05] <dupondje> thx
[12:39] <stgraber> pitti: did you see bug 800700? I noticed that yesterday on a lucid system. Apparently half the langpacks are still in -proposed...
[12:40] <pitti> stgraber: I didn't; thanks for pointing out! checking
[12:49] <pitti> stgraber: fixed
[12:49] <stgraber> pitti: thanks!
[12:49] <pitti> thanks muchly for pointing out
[13:18] <apw> pitti, do you know who promoted fsl-imx51, i am told it missed having its overrides applied
[13:18] <apw> (and thus ended up in universe)
[13:19] <pitti> I don't know, no
[13:19] <pitti> it's not even in oneiric?
[13:20] <ogra_> only lucid
[13:20] <pitti> oh, do you mean linux-fsl-imx51 in lucid?
[13:20] <apw> pitti, sorry yes, that
[13:20] <pitti> so that was me
[13:21] <pitti> the current kernel sru workflow doesn't really involve a step of setting overrides
[13:21] <apw> pitti, note this information is second hand, and it is being fixed by someone, just wondering if we're missing a step
[13:21] <pitti> apw: oh, it is? I'm currently changing it
[13:22] <pitti> apw: direct PPA->archive copying is circumventing the binary NEW procedure
[13:22] <pitti> so I guess we'll need to make "log into cocoplum and fix the componetn after copying" a part of the procedure :/
[13:23] <pitti> apw: moved tomain
[13:23] <pitti> to main
[13:23] <apw> pitti, ok cool.  thats unfortuante that its a manual step
[14:07] <pitti> @pilot out
[14:07] <pitti> zul: I think you might want to @pilot out, too :)
[14:07] <zul> @pilot out
[14:07] <zul> geez..
[14:11] <superm1> could someone look over why the mythbuntu livefs cron job decided to not even try yesterday? the others have logs, but nothing in http://people.canonical.com/~ubuntu-archive/livefs-build-logs/oneiric/mythbuntu/
[14:13] <seb128> pitti \o/
[14:13] <seb128> (sponsoring queue down to 61!)
[14:13] <pitti> just sent the report :)
[14:14] <pitti> superm1: cron jobs are off for alpha-2 RM
[14:14] <pitti> superm1: just poke me if you need another build
[14:14] <superm1> pitti, ah, yeah then could you do another build for me?
[14:14] <pitti> but they seem to have failed since July 2
[14:14] <pitti> superm1: yes, running
[14:15] <superm1> thanks
[14:15] <pitti> there were eglibc troubles over the weekend
[14:15] <pitti> superm1: so, let's see what this log will say
[14:15] <seb128> barry, hey
[14:29] <dupondje> https://launchpad.net/ubuntu/+source/vinagre/3.1.3-0ubuntu1/+build/2611478
[14:29] <dupondje> launchpad says build failed, but the logfile shows that build was successfull ...
[14:29] <tumbleweed> dupondje: look at the very end
[14:30] <seb128> dupondje, the amd64 builder breaks build when the log has implicit conversions
[14:30] <dupondje> ehh looked over that
[15:06] <pitti> superm1: http://cdimage.ubuntu.com/mythbuntu/daily-live/20110706/
[15:06] <pitti> superm1: added to tracker
[15:09] <superm1> pitti, thanks
[15:21] <shadowstalker> Hello all! :-)
[15:22] <seb128> ogra_, janimo: bigon fixed the json-glib build issue on debian so will be fixed in ubuntu once it's synced
[15:22] <seb128> will do that later when it's published in debian
[15:22] <seb128> bigon, thanks ;-)
[15:23] <bigon> np :)
[15:23] <seb128> barry: could you commit your dh_python2 changes to the vcs for the packages you upload?
[15:23] <seb128> barry, gnome-python-desktop gnome-applets gnome-menus gedit at least are outdated
[15:23] <janimo> seb128, nice, I could not figure out what it was when I looked
[15:23] <seb128> barry, which means either the next upload will get rejected or your change will be dropped
[15:24] <barry> seb128: will do
[15:24] <seb128> if people don't notice you uploaded without updating the vcs that's it
[15:24] <seb128> barry, thanks
[15:24] <shadowstalker> I'm quite a newbie but if someone has a minute to give me a little direction I would really appreciate it! (patching)
[15:24] <seb128> barry, you might want to check other things you uploaded, and debcheckout is your friends to checkout a source ;-)
[15:25] <barry> seb128: i wonder if the udd guidelines should be updated, or whether the tools themselves should be modified.  i'm not sure what the correct procedure should be though
[15:26] <seb128> barry, well "udd guidelines" are for udd use, reality is that we don't use udd in a consistant way
[15:26] <seb128> so ubuntu guideline != udd guideline
[15:27] <bigon> seb128: any new for cheese (and the required mir?)
[15:28] <barry> seb128: yeah, but i guess my question is this: if you grab a udd branch, how do you know you should ignore that and use the vcs branch?
[15:28] <seb128> bigon, no
[15:28] <seb128> bigon, i've asked ev to drop the ubiquity build-depends on libcheese so we can demote it
[15:28] <cjwatson> at the moment, you have to find that out before deciding to grab the udd branch, realistically
[15:28] <bigon> seb128: well cheese could become a hard dep for empathy
[15:29] <seb128> bigon, well, we will patch it out
[15:29] <barry> cjwatson: really?  what's the best way to do that?
[15:29] <seb128> bigon, it's a no way until the gstreamer parts it needs are in good or base
[15:29] <cjwatson> $ debcheckout -p gedit
[15:29] <cjwatson> bzr     https://code.launchpad.net/~ubuntu-desktop/gedit/ubuntu
[15:29] <cjwatson> seems reasonable enough to me ...
[15:29] <seb128> barry, cjwatson: we should teach debcheckout to get the udd vcs if it doesn't do yet
[15:29] <seb128> if there is no other vcs
[15:30] <cjwatson> (for an authenticated checkout, drop -p and add -a)
[15:30] <Laney> you should teach update-maintainer to drop the debian xs-vcs then
[15:30] <seb128> that as well
[15:30] <cjwatson> s/drop/move to XS-Debian-Vcs-/
[15:30] <Laney> yes
[15:31] <seb128> or teach debcheckout to favorite launchpad vcs-es on ubuntu when several are listed
[15:32] <seb128> which is a bit hackish but should do what we want most of the time
[15:32] <Laney> adding XS-Ubuntu-Vcs and preferring that is another solution
[15:32] <brendand> mvo - has update-manager been switched to pygi/gtk3 yet?
[15:32] <Laney> then it would also allow us to specify non-launchpad branches too ... (e.g. I have some git branches on alioth for Ubuntu packages that it'd be nice if people used)
[15:33]  * cjwatson would prefer not having massive churn in everything that already has Vcs-blah in Ubuntu
[15:33] <cjwatson> I don't see anything wrong with having an Ubuntu-specific Vcs-Git header
[15:33] <mvo> brendand: no, not yet
[15:34] <Laney> no there wouldn't be, if I could specify branches there
[15:34] <seb128> well first step would be to suggest in the documentation to use debcheckout or to check for non UDD vcs-es
[15:35] <seb128> seems some people read the UDD documentation and assume that UDD is the standard way to do things which is not the case...
[15:35] <barry> but i'm missing something.  what exactly would that "check for non UDD vcs-es" be?  a non-launchpad or non-bzr url?  or something else?  iow, how would i know whether it's safe to use the udd branch?
[15:36] <seb128> barry, apt-cache showsrc <source> and search for Vcs lines
[15:36] <seb128> $ apt-cache showsrc gedit | grep Vcs
[15:36] <seb128> Vcs-Bzr: https://code.launchpad.net/~ubuntu-desktop/gedit/ubuntu
[15:36] <seb128> or use debcheckout...
[15:36] <barry> seb128: so, you mean if there are any vcs lines at all, you cannot use the udd branch?
[15:37] <Laney> debcheckout can't tell if Vcs is for Debian or Ubuntu
[15:37] <tumbleweed> how common is using debcheckout for desktop packages, though? The majority of packages are not going to have launchpad Vcs lines, so I don't think I've ever used debcheckout on ubuntu
[15:38] <cjwatson> an explicit Vcs line indicates that the maintainer is doing something outside of UDD
[15:38] <Laney> so just unconditionally using that isn't enough
[15:38] <pitti> tumbleweed: pretty much all GNOME related packages have them
[15:38] <cjwatson> assuming it's for Ubuntu; Laney is right that there are wrinkles
[15:38] <cjwatson> most installer packages have Vcs-Bzr too
[15:39] <barry> cjwatson: right, but checking for Vcs-Bzr is a narrower test
[15:39] <cjwatson> one of these days I'll get round to pushing them to lp:ubuntu/... and moving everything over, but a million and one things to do etc.
[15:39] <cjwatson> barry: I have Debian packages with Vcs-Bzr; no reason to assume it's Ubuntu-specific
[15:39] <Laney> which is part of the reason for suggesting XS-$Vendor-Vcs; then you are indicating that this is the location to use for $Vendor
[15:39] <barry> cjwatson: no question, there will be false matches
[15:39] <Laney> if you just change it in the merge you aren't giving the tools enough information
[15:40] <pitti> well, as 95% heuristics it could always check for the word "ubuntu" in the branch
[15:40] <cjwatson> barry: designing something that minimised them would be kind of nice though :)
[15:40] <pitti> all desktop package branches are named "ubuntu", and most of them should be owned by ~ubuntu-{desktop,core-dev}
[15:40] <seb128> well we could say that ubuntu modified package that to keep only the ubuntu Vcs info
[15:40] <seb128> "have to keep"
[15:40] <barry> i'm just looking for some criteria other than saying "if there's a vcs-* line, don't use udd" because i'm afraid it will make udd basically unusable
[15:41] <cjwatson> the (not machine-readable) criteria should be "if there's a vcs-* line that looks like it's explicitly maintained by Ubuntu people, prefer that to UDD"
[15:41] <pitti> let's say "if there's a Vcs- line, check first"?
[15:41] <cjwatson> that's your criterion - now figure out how to make that machine-readable
[15:42] <barry> cjwatson: :)
[15:42] <cjwatson> pitti's heuristic certainly isn't a bad one
[15:42] <seb128> you can use "if the revision has an ubuntu number and the control a Vcs use that, otherwise use UDD"
[15:42] <barry> yes, but "check first" means?  ask someone, inspect the vcs branch, something else?
[15:42] <seb128> then we just need to make sure we clean debian vcs infos when we modify sources in ubuntu
[15:42] <broder> cjwatson: wait, does that mean that grub2 shouldn't currently work with usb 3.0 drives, or doesn't work with usb 3 drives in usb 2 ports? Because I definitely did the latter with natty last week, but can't seem to get it working with maverick
[15:43] <barry> seb128: that matches much closer to what i was thinking
[15:43] <pitti> barry: the naming/ownership of the branch sohuld generally make it clear whether it's the ubuntu one
[15:43] <cjwatson> broder: I expect I mean the controller rather than the drive
[15:43] <cjwatson> broder: maverick - no idea, too long ago :)
[15:43] <seb128> but what pitti said, checking for ubuntu in the vcs url should work for most cases
[15:43] <pitti> barry: like lp:~ubuntu-core-dev/pkgname/ubuntu obviously is
[15:43] <tumbleweed> seb128: and the ubuntu packages without ubuntu in the version?
[15:44] <seb128> tumbleweed, out of some special case of native ubuntu packages those are synced from debian
[15:44] <pitti> tumbleweed: even upstart has an ubuntuish version number now, and udev too
[15:44] <tumbleweed> yeah, I'm talking about the special cases :)
[15:44] <pitti> tumbleweed: do we still have these? frankly, we should fix those packages to have ubuntuish versions and stop trampling Debian's namespace
[15:44] <seb128> well, 95% if better than nothing
[15:44] <seb128> is
[15:45] <seb128> even if we have a few corner cases which has confusing
[15:45] <barry> the other thing to remember is the process is different too, iow, you'll have to create a branch and do a mp against the vcs branch
[15:45] <seb128> but usually things maintained in ubuntu are full source and packaging in bzr
[15:45] <tumbleweed> pitti: I agree with that, but I still see people using them because "the package is blacklisted" or "ubuntu-only, no such package in debian"
[15:45] <seb128> so they can easily be on lp:ubuntu namespace
[15:45] <pitti> tumbleweed: for those you can still check Vcs-Bzr:, just as you'd do (or not) right now..
[15:45] <cjwatson> barry: right, but for now, that's inevitable
[15:46] <barry> cjwatson: yep, agreed
[15:46] <cjwatson> pitti: honestly I can't see a reason to change e.g. ubiquity's version number
[15:46] <barry> okay, i think i have enough to at least start a discussion on the udd mlist.
[15:46] <tumbleweed> pitti: if the heuristic is "ubuntu" in version: use Vcs, else use UDD then those need to be special cased (but yes, there aren't many)
[15:47] <barry> tumbleweed: or maybe -0ubuntuX ?
[15:47] <pitti> tumbleweed: more specifically, use Vcs-Bzr
[15:47] <cjwatson> especially for a native package it's annoying and makes it look like it's a branch from Debian when it isn't
[15:48] <pitti> superm1: just saw your mythbuntu-default-settings upload; do you want that for a2?
[15:48] <tumbleweed> having an XS-$Vendor-Vcs-* certainly helps to override all the special cases, whatever heuristic is used
[15:49] <cjwatson> tumbleweed: yeah, I think I agree
[15:49] <cjwatson> mvo: I've been seeing a number of cases recently where changelogs.ubuntu.com isn't up to date; the most recent I noticed was isc-dhcp-client 4.1.1-P1-17ubuntu3.  Could there be a systemic problem here?
[15:49] <pitti> right, but any change to Vcs-Bzr: structure will take a cycle to implement
[15:51] <mvo> cjwatson: let me check
[15:51]  * barry -> lunch, but i'll open a thread on udd afterward
[15:53] <pitti> barry: thanks; the non-UDD branches are not going to go away anytime soon, so any improvement for the current situation is appreciated
[15:53] <pitti> unless we can retarget the lp:ubuntu/pkgname branches to the Vcs-Bzr: ones
[15:56] <micahg> umm, the lp:ubuntu/foo branches still serve a purpose even if the branch for making changes is elsewhere, I don't think they should not be available
[15:57] <micahg> in theory at least, it lets one look at upstream changes over time
[16:08] <mvo> cjwatson: thanks for the pointer, there is indeed something broken on changelogs, seems to be caused by the recent machine upgrade, I am on it
[16:09] <cjwatson> great, thanks
[16:15] <dupondje> cjwatson: dunno if you got time to look at https://bugs.launchpad.net/ubuntu/+source/debootstrap/+bug/805886 ?
[16:21] <chrisccoulson> kirkland`, you wanted the latest mongodb from debian didn't you?
[16:21] <tumbleweed> I did a hacky patch to pull-lp-source, to do vcs checkouts, using the "ubuntu" in Vcs-Bzr + X-Vcs-$Vendor-Bzr heuristics: lp:~stefanor/ubuntu-dev-tools/udd-checkout if that interests anyone
[16:22] <cjwatson> dupondje: not yet, no.  it certainly surprises me since that always used to be unmounted
[16:22] <cjwatson> dupondje: I was on holiday yesterday and am still catching up.
[16:25] <dupondje> cjwatson: hehe ok :) no stress :D
[16:39]  * ogra_ hugs bigon 
[16:39] <ogra_> thanks !
[16:42] <cr3> barry: did something change in python-imaging or related package(s) in oneiric? I'm getting this error when building a package on oneiric that works just fine all the way down to lucid: IOError: decoder zip not available
[16:45] <slangasek> bdmurray: where should I hook into apport to collect additional info if /var/cache/debconf/config.dat is mentioned in an upgrade log?
[16:48] <bdmurray> slangasek: probably data/general-hooks/generic.py
[16:49] <bdmurray> slangasek: in apport ...
[16:49] <slangasek> bdmurray: ack
[16:57] <barry> cr3: i think one of the launchpad guys got hit by this in dublin but i never found out what the issue was
[17:03] <cjwatson> dupondje: can't reproduce this with a bare debootstrap run
[17:04]  * cjwatson tries with the invocation from the Debian bug
[17:10] <bdmurray> doko: so bug 756028 ended up being tagged multiverse as the source is multiverse although the binary is in universe.  Does that seem reasonable?
[17:12] <superm1> pitti, we're skipping a2, lots of other issues right now
[17:12] <superm1> we'll start with a3
[17:43] <cjwatson> dupondje: can't reproduce this with the debootstrap line in the debugging output from the Debian bug either.  Can you please show me a way I can reproduce this with plain debootstrap?
[18:01] <cr3> barry: do you think the problem is likely to be ephemeral and will resolve itself somehow?
[18:02] <barry> cr3: unknown at this point, sadly.  i wonder if it could be a multiarch related problem.  does it happen only on oneiric?
[18:02] <barry> cr3: unfortunately too, PIL isn't being maintained upstream anymore afaik
[18:03] <cr3> barry: yep, only oneiric, the same package built fine on natty and below
[18:03] <barry> cr3: i suspect multiarch issues
[18:03] <cr3> barry: this might affect people developing on launchpad because of spriteutils, I think
[18:04] <cr3> barry: didn't multiarch kick in in natty though?
[18:04] <barry> cr3: that's where i saw it.  the lp build process fails because of this error
[18:05] <cr3> barry: exactly the same problem, and you encountered this on oneiric rather than natty though, right?
[18:05] <barry> cr3: i actually didn't encounter the problem, one of the lp devs did.  maybe ask around on #launchpad-dev?
[18:06] <cr3> barry: will do, thanks
[18:06] <barry> cr3: okay, sorry to be so unhelpful atm.  let me know how it goes
[18:07] <cr3> barry: for know, it's comforting enough to know I'm not alone :)
[18:07] <barry> ;)
[18:41] <micahg> @pilot in
[18:43] <directhex> when exactly do packages get removed from the archive which are meant to be removed from the archive?
[18:44] <micahg> depends on the immediacy I think, definitely before the end of the cycle
[18:48] <bdmurray> slangasek: so bug 756028 ended up being tagged multiverse as the source is  multiverse although the binary is in universe.  Does that seem  reasonable?
[18:48] <bdmurray> slangasek: so bug 756028 ended up being tagged multiverse as the source is multiverse although the binary is in universe.  Does that seem reasonable?
[18:49] <bdmurray> slangasek: this has to do with the ftbfs bugs
[18:51]  * micahg seems to be missing the point of tagging the component in the first place
[18:53] <bdmurray> micahg: to be able to search for ftbfs and component using a tag rather than using the component thing in advanced search
[18:53] <micahg> bdmurray: what's the point of searching by component though
[18:54] <bdmurray> micahg: ask skaet
[19:03] <slangasek> bdmurray: I think a 'multiverse' tag there is fine
[19:03] <bdmurray> slangasek: okay, that's what I'd thought too
[19:08] <seb128> barry, do you have upload rights?
[19:08] <barry> seb128: i do
[19:09] <cjwatson> directhex: if you care about anything in particular, file a bug - everything ubuntu-archive is subscribed to will get done
[19:09] <seb128> barry, so feel free to commit directly rather than open merge requests
[19:09] <barry> seb128: will do.  wasn't sure what the right etiquette was!
[19:10] <seb128> barry, well, if you uploaded you should at least keep the vcs updated with what is in the archive ;-)
[19:10] <seb128> barry, if you want review better to ask before uploading, it doesn't make sense to review the merge if you already uploaded
[19:10] <barry> seb128: good point :)
[19:10] <broder> i'm looking at the udd import failure for open-vm-tools. based on the comment in bug #494481, it sounds like the right thing to do is to uncommit and push --force - is that right?
[19:13] <broder> i guess i'd need to find someone else who could do that for natty since i don't think i can
[19:29] <bdrung_> tumbleweed: patches are welcome
[19:29] <tumbleweed> bdrung_: of course :)
[19:41] <pitti> superm1: understood
[19:45] <broder> where is the best place to ask udd infrastructure questions (specifically, trying to hunt down and fix an import failure)? here? #launchpad?
[19:56]  * micahg wonders if there's a UDD channel
[19:57] <broder> micahg: #ubuntu-udd and #udd are both empty, so i guess not
[19:57] <Laney> there's a mailing list though
[19:58] <mok0> Laney: liked your blog post
[19:59] <Laney> which one?
[19:59] <Laney> I liked that UDD one more :-)
[20:00] <mok0> Laney: the motuvation one
[20:00] <Laney> mok0: cheers, bit of a moan every now and again does good
[20:01] <mok0> Laney: ... but does it help? :-(
[20:01] <micahg> @pilot out
[20:02] <Laney> mok0: I posted it to -motu too some time back. You should reply — we can have an 'old washed up gits' support group :-)
[20:05] <broder> Laney: I think one thing we haven't done as good of a job of exploring is, in addition to getting more workers, trying to reduce the workload
[20:06] <broder> e.g. more strongly discouraging REVU and Ubuntu-specific packages
[20:06] <mok0> Laney: I missed it... stopped following u-m regularly since the there is rarely anything interesting and the team has basically stopped working (as you said)
[20:09] <mok0> Laney: But "old-washed-up-gits"... sounds good to me :-)
[20:11] <dupondje> cjwatson: commented the debootstrap bug
[20:13] <Laney> broder: well I do try to advocate working elsewhere as much as I can, but that can only help so far
[20:13] <Laney> and really the stuff that's left is the most tedious
[20:13] <cr3> barry: I reported but about python-imaging and subscribed you, it's a recent regression so I hope that'll be helpful
[20:14] <barry> cr3: okie dokie
[20:45] <dupondje> damn, newest upgrade broke vinagre :(
[20:55] <RedSingularity> Hey everyone.  This a good place to ask questions about packaging, or is there a more appropriate channel?
[20:57] <maxb> RedSingularity: for packaging for ubuntu itself, yes. for ppas, use #ubuntu-packaging
[20:57] <RedSingularity> maxb: thats what I am looking for.  Thanks much :)
[23:02] <bdmurray> cjwatson: it might be helpful to look at bug 500175 as it has testcase in the description
[23:09] <cjwatson> bdmurray: ok, tomorrow
[23:12] <cjwatson> thanks
[23:22] <TheMuso> @pilot in
[23:22] <TheMuso> Whoops should have done that 20 mins ago.