[01:49] <darkxst> Sarvatt, I fixed ppa-purge to work on multi-arch, and it works perfectly with apt-get, but when I tested with aptitude not only did it remove the ppa, but it also downgraded everything from quantal-updates
[01:49] <darkxst> I think this might be a different bug, but wondering if you have ever seen that before
[07:42] <dholbach> good morning
[09:43] <infinity> doko_: I note that binutils-gold is falling out of main in component-mismatches.  I assume that just means nothing build-deps on it currently.  Do we want to seed it explicitly, or are you happy with it dropping to universe?
[09:43] <infinity> doko_: platform/supported-development-common seems like a sane place for it, if we want to keep it in main.
[10:12] <hrw> wookey, doko: good news - armhf cross compiler has most of issues solved
[10:55] <diwic> If I have a package that's "Multi-arch: foreign", e g pulseaudio-utils (which only contains executables and no .so files, so I think that makes sense), how do I specify that for pulseaudio-utils-dbg only makes sense together with the same arch of pulseaudio-utils ?
[13:23] <cjwatson> @pilot in
[14:22] <bdrung> ScottK: okay
[14:33] <ogra_> would grep "^\([0-9a-z]\)\{8\}-\([0-9a-z]\)\{4\}-\([0-9a-z]\)\{4\}-\([0-9a-z]\)\{4\}-\([0-9a-z]\)\{12\}$" be a proper way to safely match a UUID ?
[14:34] <ogra_> or is there any way the format of a UUID could be different than 8-4-4-4-12 on ext2/3/4 ?
[14:50] <xnox> ogra_: that should be fine for ext2/3/4
[14:51] <ogra_> great, i found a better fix than this insanity though :)
[14:51] <ogra_> but its good to keep for the next time i need something like that :)
[14:52] <xnox> ogra_: note that other filesystems generate (pseudo) uuid-like identifiers that are shorter.
[14:53] <ogra_> yep, i know, at least for vfat i do
[14:53] <ogra_> though luckily our installer wont allow you to install to vfat
[14:54] <ogra_> (i hope at least, else the install would fail later anyway)
[15:25] <rickspencer3> msf sforshee hey, would it still be helpful if I installed the mainline kernel?
[15:25] <rickspencer3> oops
[15:25] <rickspencer3> nice pm
[15:26] <sforshee> rickspencer3, heh
[15:26] <sforshee> rickspencer3, it's always good to know whether the bug still exists upstream. I suspect you'll find that it does, since this device seems to have been broken for a long time now.
[15:28] <sforshee> rickspencer3, I'll probably also build a kernel for you with extra debug enabled. I could make it a raring kernel so you could also do the upstream testing at the same time.
[15:28] <rickspencer3> sforshee, perfect
[15:48] <gnutun> hey all; it appears there's a packaging bug introduced in quantal, where libavutil-dev depends strictly on libavutil51, instead of libavutil51 | libavutil-extra-51; this prevents both the extra libav libs and dev files from being installed simultaneously
[15:54] <gnutun> yup, looks like the bug was already reported, nm
[15:54] <jtaylor> siretart: ^
[15:54] <xnox> gnutun: bug number?
[15:54] <jtaylor> its a known issue
[15:54] <jtaylor> unfortunatly I think the solution is delayed to 13.04
[15:54] <jtaylor> or later
[15:57] <gnutun> jtaylor, oh wow
[15:57] <gnutun> bug 1038781
[15:57] <gnutun> https://bugs.launchpad.net/ubuntu/+source/libav/+bug/1038781
[15:58] <xnox> gnutun: fix in raring first, then SRU into quantal.
[16:00] <gnutun> ok, i think i'll throw a fixed package in my ppa for now
[16:00] <gnutun> i had to write a script on my system to uninstall/reinstall these packages several times a day depending on what im doing
[16:00] <gnutun> thx for the info
[16:38] <roaksoax> jdstrand: howdy! So for the MAAS SRU to precise and in order to address the bugs you filed back then and get rid of cobbler, we need to SRU new packages that are not in precise. How do you feel about that (from the security team stand point)
[16:38] <bdrung> ScottK: uploaded
[16:44] <jdstrand> roaksoax: that is fine. I discussed this with flacoste some time ago
[16:44] <jdstrand> it is unusual, but in this case, ok
[16:48] <roaksoax> jdstrand: awesome then!
[16:48] <roaksoax> thanks
[17:07] <janimo> cjwatson, what fraction the effort for a full wubi port to nexus7 would be making a bootimg/initramfs that boots off a loopmounted file in the android data partition?
[17:08] <janimo> and that boot img put in recovery so both can be selected from the bootloader
[17:08] <cjwatson> the initramfs part is basically just adding lupin-casper
[17:08] <cjwatson> but I think to do it sanely we need to get the grub port in first
[17:09] <cjwatson> otherwise we end up in copy-out-the-kernel hell and it's all a mess
[17:09] <cjwatson> and we'd want a boot menu anyway
[17:09] <cjwatson> I wasn't suggesting it as a "hey, we can do this right now" thing :-)
[17:09] <cjwatson> but it seems like something rather handy that might be worth a look
[17:10] <janimo> cjwatson, I know, I just thought about this before, without knowing what the technical blockers are
[17:10] <ogra-cb> me would be a technical blocker for raring at least :)
[17:10] <ogra-cb> i think we should do it, but not this cycle
[17:10] <janimo> I was just hoping there was an easy way to tell the kernel that root is not a device but a file on a filesystem and be done :)
[17:11] <cjwatson> that's basically what lupin-casper arranges for
[17:11] <ogra-cb> (enough other stuff to do and it needs more research and testing etc)
[17:11] <cjwatson> the initramfs side is by this point fairly easy
[17:11] <cjwatson> but you need the boot loader to be able to get at the kernel/initrd too
[17:12] <cjwatson> which either means (a) copy it out to the containing fs (we tried this before, it more or less worked for a few cycles but was really a big bag of no fun at all) or (b) grub2 which is smart enough to unpick things
[17:12] <janimo> cjwatson, but the boot images are zImage+initrd does that not mean they are already seen by the bootloader?
[17:13] <ogra-cb> you can surely make it just work with abootimg somehow
[17:13] <cjwatson> I guess you're already flashing them which amounts to copying them out, yeah
[17:13] <ogra-cb> but if we can have a proper way typo chainload grub and adapt that across alll bootloaders some day, thats definitely better
[17:14] <cjwatson> in the sense of flash-kernel
[17:14] <ogra-cb> s/typo/to/
[17:14] <ogra-cb> funny typo, tsk
[17:14] <janimo> ogra-cb, having grub and consistency is great, I am just wondering if grub is a requirement at all. I may actually need to read lupin-casper before just assuming things though :)
[17:14] <ogra-cb> so imho we should inspect the opportunity this cycle and lay the foundations for next release
[17:14] <cjwatson> well, in that case it's a matter of adding lupin-casper and figuring out how to make the installer create a big file rather than a new filesystem
[17:15] <cjwatson> but you still need something to offer a boot menu
[17:15] <cjwatson> otherwise not a lot of point in dual-booting
[17:15] <ogra-cb> right
[17:15] <janimo> cjwatson, I was thinking of a less friendly way of using the device
[17:15] <janimo> device's boot menu
[17:15] <ogra-cb> which means hw related hacks depending on what keys your device has
[17:15] <janimo> and have android and ubuntu use linux and sos partitions
[17:16] <janimo> so leave android boot as it
[17:16] <cjwatson> I gathered that using the recovery partition was possible; it just struck me that it'd be nicely non-invasive not to have to use that
[17:16] <janimo> and put an ubuntu loader that looks for a loopmounted file in UDA to recoveyr
[17:16] <cjwatson> since it kind of seems like a misuse of the recovery partition?
[17:16] <janimo> cjwatson, at the moment recovery is unused 'officialy' so would be ok
[17:16] <janimo> and also easy to reflash anytim
[17:17] <janimo> ogra-cb, I am only thinking of the nexus7 now, not long-term dual boot which indeed should be better thought out and nicer
[17:17] <janimo> just so we get many more testers who are otherwise unwilling to buy a lovely device just to have a not-yet-working ubuntu on it
[17:17] <janimo> and for hw/kernel debugging having an android to compare behaviour against is a win as well
[17:17] <ogra-cb> well, i wont change the image design right now
[17:18] <cjwatson> janimo: right, those were very much my motivations in thinking about this
[17:18] <janimo> cjwatson, right it is a misusre of recovery, but since we assume unlocked devices, we have fastboot to do recovery and random flashing
[17:19] <ogra-cb> there are to many bits that rely on it (usb-creator etc) but i agree that we should have a plan ... bonus points if we can do it with the current design or something close to it
[17:20] <cjwatson> @pilot out
[17:21] <ogra-cb> the prob i see with the lupin approackh is that you have to somehow teach the android side to work with it as well
[17:21] <cjwatson> Do you?
[17:21] <ogra-cb> and android kind of relies on the same hardcoded crap flash-kernel assumes today
[17:22] <ogra-cb> so a kernel update would be written to mmcblk0p2
[17:22] <ogra-cb> overwriting your menu/initrd
[17:24] <ogra-cb> iirc it looks at labels instead of device names so one could probably swap recovery and boot labeling or so
[17:25] <ogra-cb> but given that the partition table is usually kind of hardcoded as GPT inside the bootloader that wont be easy either
[17:26] <infinity> ogra: By the way.  You haven't filed an MIR for anrdoid-whosit-whatever, and livecd-rootfs is uninstallable.
[17:26] <ogra-cb> oops, will do now
[17:27] <infinity> ogra-cb: You might want to do some of the MIR legwork too, not just file it, if you have any hope of seeing it promoted this year. :P
[17:27] <ogra-cb> well, i'm not in the MIR team
[17:27] <ogra-cb> i'll do what i can though
[17:42] <infinity> ogra-cb: Anyone can do the research and post the results, it's only the MIR team that can do the final approval, that's all.
[17:47] <bryceh_> is there a way to install sru packages that are in the Unapproved queue?  (I.e. so I can test the package while it's waiting)
[17:47] <mlankhorst> pbuilder-dist ?
[17:47] <xnox> bryceh_: it's source only, so you can download them of launchpad, then build then install.
[17:48] <patr|ck> hello, when i try to report a problem regarding the i965 "sandy bridge" graphics chip where the packages kernel, mesa, libdrm, libva-intel and xf86-video-intel are affected i want to ask, which one do i choose for the bug report?
[17:48] <ogra_> infinity, bug 1079796
[17:48] <xnox> bryceh_: https://launchpad.net/ubuntu/raring/+queue pick correct queue & package, download the .dsc
[17:48] <ogra_> infinity, anything else i could add or do to speed it up ?
[17:49] <bryceh_> patr|ck, just file against 'xorg'.  we'll figure it out.
[17:49] <patr|ck> okay, thanks
[17:49] <bryceh_> patr|ck, it's generally impossible to know ahead of time which package is the faulty one
[17:50] <bryceh_> xnox, hmm, right was hoping for more magick there ;-)
[17:50] <infinity> ogra_: That should do for now.
[17:50] <ogra_> great
[17:50] <cjwatson> bryceh_: the 'queue' tool in lp:ubuntu-archive-tools can fetch them
[17:51] <xnox> cjwatson: \0/ this changes my world
[17:52] <bryceh_> cjwatson, thanks
[18:00] <patr|ck> i must say, the way ubuntu-bug and launchpad.net work is plain awesome. big achievement :-)
[18:01] <doko> Sweetshark, the boost packages are now built for quantal. please validate these
[18:09] <Sweetshark> doko: willdo
[18:12] <siretart> jtaylor: yes, I'll work on that in my next upload to quantal. I'm currently busy with https://launchpad.net/~motumedia/+archive/libav9-raring/ though, help more than welcome, btw. however, since progress on that transition is rather slow, I guess I'll upload 0.8.4 to raring nevertheless soon
[18:24] <doko> ogra-cb, does android-tools need seeding?
[18:24] <cjwatson> livecd-rootfs already depends on it on armhf, so I shouldn't think so
[18:36] <ogra-cb> doko, what cjwatson said
[19:25] <bryceh_> @pilot in
[19:26] <infinity> bryceh_: If you change your nick to one without an underscore, can I no longer bug you to pilot?
[19:27] <bryceh_> you always welcome to bug me to pilot infinity
[19:27] <bryceh_> @pilot out
[20:55] <morphias> guys i am having trouble building an application package. http://paste.ubuntu.com/1363476/ is the output from building it and i dont know what to do exactly to get the deb built...
[20:58] <sarnold> morphias: I'd try again in a directory that does not contain a space in the directory name.
[20:58] <morphias> kk ill try that
[21:05] <morphias> sarnold, yey... now it says "secret key not available"
[21:05] <morphias> but it produced the deb
[21:05] <sarnold> morphias: woot. :D
[21:07] <morphias> now i went through the effort of creating a gpg key last night... how do i get it built to sign it or is that not needed (something tells me its needed)
[21:14] <morphias> sarnold, should i post the output of what occured?
[21:17] <infinity> No need to sign local package builds.  That said, "-uc -us" should have skipped the signing bits.
[21:19] <morphias> infinity, oh... but if a package gets distrubuted, should it be signed? (btw, I just figured it out, I had to add my nickname into the changelog)
[21:20] <infinity> morphias: Generally, if you're distributing, you either sign your archive, or if you're uploading just the source/binaries somewhere, you sign the .changes and the .dsc.
[21:20] <infinity> morphias: -uc makes dpkg-buildpackage not sign changes, -us makes it not sign the .dsc
[21:20] <morphias> yeah that is what the debuild did for me
[21:21] <infinity> After an unsigned build, "debsign *changes" will sign it, if you want it to be so.
[21:27] <morphias> well now i got to hunt down yet another bug. hehe... this is my first time doing this
[21:28] <morphias> i got a "terminate called without an active exception" error thrown
[21:31] <barry> sbuild is making my cry today.  i'm trying to build a package in a sid chroot (where python2.6 is supported).  python-argparse is a b-d and i can see it getting past the "Merge Build-Depends" stage, but then apt in the chroot simply doesn't install it. :(
[21:34] <barry> and yes, jumping into the chroot and `apt-get install python-argparse` works :/
[21:48] <infinity> ogra-cb: Your latest livecd-rootfs upload isn't committed/tagged in bzr.
[21:49] <infinity> ogra-cb: pls to fiz before I go staging something else. :)
[21:49] <infinity> s/fiz/fix/
[22:01] <ScottK> bdrung: Thanks.
[22:04] <ScottK> bdrung: Accepted.
[22:05] <infinity> barry: Are you sure it's not provided by something else that's installed?
[22:05] <infinity> barry: Like, I dunno, python2.7?
[22:07] <infinity> barry: A versioned build-dep would be more correct there (since it's entirely valid for both sbuild and apt to say that your unversioned build-dep is satisfied by python2.7)
[22:07] <infinity> barry: Not sure if a versioned build-dep will fix it, but if not, THAT's a bug. :P
[22:08] <barry> infinity: yeah, i thought about that.  but unless i'm missing it, 2.7 under sid doesn't claim to provide it:
[22:09] <barry> grep argparse sid/debian/control
[22:09] <barry> (returns nothing)
[22:09] <infinity> barry: Oh, I wasn't looking in sid.
[22:09] <infinity> Err, yes it does.
[22:09] <barry> yeah.  raring is all like happy happy joy joy
[22:09] <infinity> Provides: python-argparse, python2.7-argparse ...
[22:09] <infinity> In my sid chroot.
[22:10] <barry> oh craptasm.  i grabbed the wrong branch
[22:10] <infinity> Methinks you want apt-cache show, not an incomplete control file in the source.
[22:11] <barry> no, it's in there
[22:11] <infinity> Oh, or just read the right source, sure. :)
[22:12] <barry> yeah, so now it makes sense ;)
[22:25] <bryce> are there any SRU admins here today?  There is a jockey SRU for precise stuck in Unapproved.  I think RAOF meant to approve that along with fglrx-experimental-9 but overlooked it.  The jockey change allows the driver to actually be installed.  Could someone approve it?
[22:52] <RAOF> bryce: Done. Sorry, I thought we had all the jockey changes already.
[23:34] <bryce> RAOF, awesome, thanks.
[23:47] <bryce> RAOF, yeah we need to get more organized with these driver updates.  it's too easy for bits to get skipped
[23:47] <LyzardKing> what is kubuntu's status, being passed over to bluesystems?