[00:34] <ScottK> janimo: It's the first time the dbus/dbus.cpp code's been built on arm* in a python3 environment.  Might be something with that or barry's patch then.  Thaks.
[00:34] <slangasek> cjwatson: any chance you could push your debhelper merge to the bzr branch?  importer doesn't seem to be grabbing it
[00:38] <cjwatson> slangasek: hm, I didn't do it in bzr as it happens; is a local import-dsc likely to fare any better than the importer?
[00:38] <slangasek> not sure :/
[00:38] <slangasek> cjwatson: actually, import-dsc fails for native packages
[00:38] <slangasek> so no
[00:39] <slangasek> (also, not sure if it does sane things with branches for merges)
[00:40] <cjwatson> I guess I can try to reconstruct something
[00:41] <cjwatson> actually, I think it would be bad to try - lp:debian/sid/debhelper is out of date so if I tried it would result in a lack of merge metadata
[00:41] <slangasek> right
[00:42] <slangasek> so maybe we should just get the importer kicked
[00:42] <cjwatson> I think so
[00:56] <psusi> cjwatson, is it time to poke you about my parted/dmraid/multipath-tools merges yet? ;)
[01:11] <Jatinder> Good Morning Everyone !!!
[01:12] <Jatinder> How to remove complete GUI of Ubuntu 11.10?
[01:12] <Jatinder> I tried this : sudo apt-get remove ubuntu-desktop
[01:13] <Jatinder> but system replied that it will remove only 16kb of the data
[01:13] <slangasek> Jatinder: this is not a support channel; please see #ubuntu
[01:14] <Jatinder> Sir I am trying to work on derived ubuntu so thought its developers' talk
[01:14] <Jatinder> so got into here
[01:14] <slangasek> well, that's not a development question :)
[01:15] <Jatinder> okay. i'll  leave then
[01:48] <smoser> slangasek, ping
[01:48] <slangasek> smoser: hey there
[01:48] <smoser> https://cloud-images.ubuntu.com/server/precise/current/
[01:48] <smoser> we sign SHA1SUMS and MD5SUMS with some key on nectarine
[01:48]  * slangasek nods
[01:48] <smoser> but that public key (as far as I know) is not distributed anywhere.
[01:49] <slangasek> really? hmm
[01:49] <smoser> $ gpg --keyring /usr/share/keyrings/ubuntu-archive-keyring.gpg --verify SHA256SUMS.gpg SHA256SUMS
[01:49] <smoser> gpg: Signature made Tue 24 Jan 2012 09:36:24 PM EST using RSA key ID 7DB87C81
[01:49] <smoser> gpg: Can't check signature: public key not found
[01:49] <smoser> the same command works for me with Release and Release.gpg (from archive.ubuntu.com)
[01:50] <slangasek> smoser: no, it is distributed via the public keyrings
[01:50] <smoser> so what am i doing wrong?
[01:50] <slangasek> smoser: e.g., gpg --keyserver pgp.mit.edu --recv-keys 7DB87C81
[01:51] <slangasek> it could probably do with some more public signatures beside my own, btw :)
[01:51] <slangasek> (from other people who have access to nectarine and can verify the authenticity of the key)
[01:52] <smoser> hm.. yes, i suppose it could
[01:53] <smoser> this obviosly exposes my grave gpg ignorance
[01:53] <smoser> but how would someone come up with that key ?
[01:54] <slangasek> smoser: your gpg output shows the key ID and reports that you don't have it locally; the next step if you want it is the gpg --recv-keys command to fetch it from the public keyservers
[01:55] <smoser> ah. duh.
[01:56] <slangasek> if you are intending to sign the pgp key yourself, please make sure to verify that the full pgp fingerprint of the key you download locally matches the fingerprint of the public key on nectarine :)
[04:52] <dhana013>  Hi guys. I want make custom distro. It's based on ubuntu derivative. but not depends on ubuntu,  How to compile source code from scratch , make deb packages, please guide me.
[04:56] <RAOF> dhana013: This seems unlikely to be on-topic for #ubuntu-devel.  dpkg-buildpackage is the standard way to go from source-package→binary package, though.
[05:01] <dhana013> RAOF: Any guide how to proceed, with my creating custom destro.
[05:17] <RAOF> dhana013: Um, don't?  I don't think there's a particularly good reason to.
[05:18] <dhana013> RAOF: New distro creation in am my project
[07:39] <dholbach> good morning
[08:09] <pitti> slangasek, cjwatson: has there been any discussion about kmod by any chance? i. e. "we want this for precise" or "we want to keep it out of precise"?
[08:09] <pitti> apw: ^
[08:09] <pitti> newer udev versions now need it, they use libkmod instead of calling modprobe a thousand times
[08:09] <pitti> which might also give a nice speedup
[08:10] <pitti> but of course it's still fairly new; Fedora and Arch linux use it, but I haven't tested it yet (it's in Debian experimental)
[08:10] <pitti> is that something I should have a look at, or do we want to stay at udev 175 and just backport some fixes?
[08:12] <pitti> we could at least sync it into universe, so that it's easier to test and play with
[08:20] <broder> i'm +1 for having it somewhere in the archive - i have some applications i'd like to use it for
[08:21] <pitti> ah, we can't sync it directly, it builds a transitional module-init-tools
[08:22] <pitti> I figure we do not want to do this right away, unless we decide to actually do replace m-i-t
[08:22] <pitti> and that requires some merging of ubuntu changes
[08:22] <pitti> so we could do a ~ubuntu1 upload without the transitional package into universe
[08:23] <pitti> (~ so that we retain the option to sync)
[08:59] <apw> pitti, yeah not heard anything but if thats the way upstream is rattling we should have it somewhere to play with
[09:00] <pitti> apw: apparently it's the m-i-t successor
[09:05] <apw> pitti, folling the libudev model i assume "do it yourself" functionality
[09:06] <pitti> apw: I don't understand, I'm afraid
[09:06] <apw> library to be directly involved in module loading, find out what is and isn't and load them so you don't need to fork all the time
[09:07] <pitti> apw: yes, udev went into that direction
[09:07] <pitti> instead of calling blkid, modprobe, and whatnot, it now uses their libraries
[09:08] <pitti> I'd like to at least get the libbklid change, but I could cherry-pick that even without kmod
[09:08] <pitti> if I look at http://people.canonical.com/~pitti/bootcharts/daniel-oneiric-20111027.png, the blkid and modprobe calls take no small percentage of the boot
[09:09] <pitti> path_id, iput_id, usb_id are now also builtin
[09:11] <apw> pitti, it would be nice to have this thing for testing and no mistake
[09:12] <pitti> apw: the debian package does some transitional changes: http://packages.qa.debian.org/k/kmod/news/20120110T221730Z.html
[09:13] <pitti> apw: so I think we need to apply some work to be able to install it for testing and then revert back to m-i-t
[09:14] <apw> pitti, yeah, why could this not have happened a month ago ...
[09:15] <pitti> apw: well, kmod existed back then, but it was still pretty young
[09:15] <pitti> apw: anyway, I don't think it's particularly urgent
[09:15] <apw> heh "cannot login to my machine as any user since kmod replaced module-init-tools" ... suspect there will be some fun :)
[09:15] <pitti> we can probably get away with reverting the kmod bits and update to 179, or cherry-pick other changes
[09:16] <pitti> I mainly wondered if there was any dicussion about that already which I wasn't aware of
[09:16] <pitti> if not, I think we should stay at m-i-t for precise
[09:16] <apw> pitti, no seems we missed out on the whole thing by missing plumbers
[09:28] <apw> pitti, do if this dicussion is correct kmod will have a kmod binary which is the  official interface which can also be symlinked to modprobe etc.  so it should be testable at least
[09:28] <pitti> yes, that's what I understood
[09:39] <apw> pitti, what is daniel, 16 blkids seem like a lot
[09:39] <pitti> apw: daniel is my Dell Mini 10v
[09:40] <pitti> i. e. my boot speed test machine
[09:40] <pitti> this was a pristine oneiric install in default partitioning mode
[09:40] <apw> pitti, and how many partitions does it have
[09:40] <pitti> apw: it's running over all ram/loop/whatnot devices, too
[09:40] <apw> oh gawd
[09:40] <pitti> apw: I think two: system and swap
[09:40] <pitti> apw: you just don't see those on faster boxes as they are quicker than bootchart's measuring interval
[09:40] <apw> no wonder you want to use it
[09:40] <pitti> which is what makes this Abacus so nice for boot speed testing :)
[09:41] <apw> yeah i wish my abacus hadn't broken, i must source another
[09:43] <pitti> it's not that easy to revert, but I'll see what I can do
[11:29] <Daviey> lynxman: around/
[11:29] <Daviey> ?
[13:45] <lynxman> Daviey: kinda, but not much, will be around in full force tomorrow
[13:46] <Daviey> lynxman: k
[13:52] <james_w> cjwatson, hi, were you planning a wadllib upload with your py3 changes?
[13:58] <cjwatson> james_w: I was waiting for somebody with permissions to do so (i.e. not me) to do an upstream release
[13:58] <cjwatson> james_w: barry has a work item to shepherd that all into the archive
[13:58] <cjwatson> maybe poke the lp people if they haven't already been poked?
[13:59] <james_w> cjwatson, ok, thanks
[14:05] <quadrispro> ScottK, waiting for a signal from you and I'll push audiofile to precise
[14:07]  * quadrispro reminds: "At my signal, unleash hell"
[14:25] <slangasek> pitti: I don't know that there's been discussion of kmod; I've assumed our answer is we don't want it due to the newness
[14:27] <pitti> slangasek: ok, thanks; that's all I wanted to know; so I'll check if the kmod bits can be reverted in udev and we upgrade to 179, or I'll try to cherrypick the interesting bits
[14:27] <pitti> the latter won't be any easier, so I'll try the former first
[14:28] <slangasek> are there good reasons to upgrade to 179, even?
[14:29] <pitti> slangasek: the biggest change is replacing the external blkid, path_id, input_id etc. calls (and also modprobe, with libkmod) with internal libraries
[14:29] <pitti> slangasek: if you look at a bootchart like http://people.canonical.com/~pitti/bootcharts/daniel-oneiric-20111027.png (mini 10), that'll should speed it up quite nicely
[14:29] <pitti> slangasek: and then the usual set of keymap quirks, but these are easily backported
[14:30] <pitti> there's also some bug fixes, but nothing major AFAIK
[14:39] <slangasek> pitti: aren't we doing ok right now with boot speed target?  not sure it makes sense to me to change udev just for this... also, has anyone run tests to show the speed improvement is actually significant?
[14:39] <pitti> slangasek: no, as we don't yet have an udev version with this
[14:39] <pitti> we can't build > 175 right now
[14:40] <pitti> slangasek: well, I wouldn't call it 'ok', but the speed regressions in natty/oneiric are certainly not udev's fault
[14:40] <pitti> (in the sense that it didn't get worse)
[14:40] <pitti> it's relatively low-hanging fruit
[14:42] <stokachu_> pitti, ping
[14:42] <pitti> stokachu_: hello
[14:42] <stokachu_> pitti, hey there :) was curious about LP#860765, was there any particular reason it was set to wont fix for natty?
[14:44] <pitti> stokachu_: it's not a high-priority bug, and natty has been out long enough for it to not matter any more
[14:44] <pitti> if someone wants to prepare an SRU, it'd be alright, but there is little to be gained
[14:55] <TREllis> slangasek: thanks for the cpp:any tip - works. Lintian doesn't like it, guess that's lintian bug tho
[14:58] <apw> pitti, would you be able to tickle the linux-ti-omap4 through for me
[14:58] <cjwatson> mvo: so I'm trying auto-upgrade-tester again, this time with apt-cacher-ng set up so that it doesn't spend eons re-downloading stuff
[14:59] <pitti> apw: ah, sure; already looked this morning, but the armel builds were still missing for both that and linux
[14:59] <cjwatson> mvo: however it fails on the apt-clone file from bug 917173 because apt-clone wasn't in lucid
[14:59] <cjwatson> mvo: do you know any way around this?
[14:59] <apw> pitti, thanks, i think linux is still lacking powerpc
[14:59] <pitti> apw: yep; omap4 done
[15:02] <apw> pitti, thanks a lot
[15:05] <mvo> cjwatson: jibel put it into a PPA afaik, jibel - if so, could you please tell colin what ppa that is?
[15:06] <slangasek> pitti: so the reason I'm pushing back a bit on udev 179 is that I don't think it's a slam dunk to take a new upstream version of udev; we spent about half a cycle chasing regressions in oneiric due to udev behavior changes, and still have one we haven't closed the gap on.  So I'm really not sure that fruit feels "low-hanging" to me
[15:06] <ScottK> Riddell: re python-qt4: That's the first time it's been built against Qt 4.8 on arm*, but it built before that with 4.7.4.  The function with the error isn't a new one, so I'm inclined to blame Qt 4.8.  sip: QPainterPathStroker::setDashPattern() unsupported function argument type - provide %MethodCode and a valid C++ signature - Thoughts?
[15:06] <cjwatson> mvo: how do I force auto-upgrade-tester to use that?
[15:07] <ScottK> Oops.  Wrong channel.
[15:07] <jibel> mvo, I didn't, sorry.
[15:09] <barry> ScottK: python-qt4 on arm is giving us headaches
[15:10] <ScottK> barry: Yeah.  Riddell and I are discussing on #kubuntu-devel.  Feel free to join.
[15:10] <mvo> jibel: oh, sorry then, I misremembered
[15:11] <mvo> cjwatson: so if there is a apt-clone in a PPA then you can do:
[15:11] <mvo> +AddRepo=local_testing.list
[15:11] <mvo> +AddRepoUpgradeImmediately=true
[15:11] <mvo> to [NonInteractive] (to e.g. profile/server-amd64/DistUpgrade.cfg)
[15:12] <mvo> and the file "local_testing.list" would contain something like deb http://ppa.launchpad.net/mvo/apt-precise/ubuntu oneiric main
[15:13] <mvo> cjwatson: there is even a branch for the backport https://code.launchpad.net/~mvo/apt-clone/lucid-backport but apparently I did not upload it into a ppa :/
[15:13] <cjwatson> do you think you could, if you already have that?
[15:14] <mvo> cjwatson: sure
[15:15] <cjwatson> mvo: do I need to do anything special if I'm testing e.g. DistUpgrade.cfg changes?
[15:17] <mvo> cjwatson: anything special when using a apt-clone file? I'm not sure, its pretty new (the integration) and jibel did those bits, IIRC its just a matter of pointing to the right apt-clone file and I guess a bit of hackery to ensure that the ppa with the apt-clone is actually in the sources.list
[15:18] <cjwatson> well, I mean inserting a different DistUpgrade.cfg file and seeing what would have happened to the upgrade if it had been done with that ...
[15:18] <cjwatson> (DistUpgrade.cfg doesn't seem to be in the apt-clone file anyway)
[15:22] <mvo> cjwatson: if you simply modify the one in the profile directory that should have the desired effect, e.g. if you want to test with a additional "KeepInstalledPkgs=" line you can just add it and it will "win" over the default value from the upgrader
[15:22] <mvo> https://launchpad.net/~mvo/+archive/apt-clone-lucid - but it neeeds to build first
[15:24] <cjwatson> oh, the profile directory, right
[15:26] <cjwatson> mvo: does it inherit from DistUpgrade.cfg.lucid on the fly or something?
[15:26] <cjwatson> sorry for asking so many questions, just finding it really hard to get going on this
[15:27] <mvo> cjwatson: it should inherit, yes (unless there is a bug somewhere)
[15:27] <mvo> cjwatson: no worries about the questions, I know its a tricky piece :/
[15:27] <cjwatson> OK
[15:28] <cjwatson> the last time I played with this I couldn't make it pick up code changes to DistUpgrade (not .cfg), and found that rather baffling
[15:28] <cjwatson> I expect I'll give that another go ...
[15:28] <mvo> cjwatson: ohhh
[15:28] <mvo> cjwatson: please set "UseUpgraderFromBzr=false" to "true" in [NonInteractive]
[15:29] <mvo> cjwatson: in AutoUpgradeTester/profile/defaults.cfg.d/defaults.cfg
[15:29] <mvo> cjwatson: or in your individual profile
[15:29] <cjwatson> ah!
[15:29] <mvo> cjwatson: otherwise it uses the version of the upgrader code from the archive
[15:29] <cjwatson> marvellous, thank you
[15:30] <mvo> yw
[15:58] <pitti> barry: dbus-python (1.0.0-1) UNRELEASED; urgency=low
[15:58] <pitti> o_O
[15:58] <barry> pitti: it's basically what we had in 0.84.0-2ubuntu3 anyway ;)
[15:59] <pitti> barry: I mean, was this uploaded prematurely?
[15:59] <barry> pitti: sync'd from experimental, but i think it's safe
[15:59] <pitti> oh, http://packages.qa.debian.org/d/dbus-python/news/20120124T214728Z.html has the same problem
[15:59] <pitti> barry: I mean "UNRELEASED" as target; it shoudl certainly be "experimental" or "unstable"
[16:00] <pitti> anyway, just looked odd
[16:01] <barry> pitti: yeah, it does, and probably should.  i'll drop a message to simon about it, but i debdiff'd the .debs and tested in a chroot.  all seemed okay, modulo http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=657488
[16:01] <pitti> barry: ok, thanks
[16:01] <barry> pitti: thanks
[16:20] <ericbee> can anyone point me to some documentation about creating applets for the systray?
[16:29] <cjwatson> The following packages have unmet dependencies.
[16:29] <cjwatson>   apt-clone: Depends: python-argparse but it is not installable
[16:29] <cjwatson>              Recommends: dpkg-repack but it is not installable
[16:29] <cjwatson> mvo: ^-
[16:29] <cjwatson> (from your PPA)
[16:30] <SpamapS> Could someone offer some guidance on how this needs to be fixed:
[16:30] <SpamapS> https://launchpadlibrarian.net/90939944/buildlog_ubuntu-precise-amd64.gearmand_0.27-1_FAILEDTOBUILD.txt.gz
[16:30] <SpamapS> Looks like an ABI bump is needed upstream..
[16:31] <cjwatson> SpamapS: using the syntax for filtered C++ symbols files rather than raw ones would be a good start
[16:31] <cjwatson> SpamapS: but C++ symbols are difficult; there's a thread on debian-devel about them at the moment ...
[16:31] <cjwatson> you might just find those symbols are inlined on some architectures or something
[16:31] <mvo> cjwatson: meh, this sounds like universe is not enabled (which is the default). you will have to tweak it and add "Components=main,restricted,universe" to the AutoupgradeTester/profile/defaults.cfg.d/defaults.cfg or the individual profile
[16:32] <mvo> cjwatson: the easier option is to start the image manually (its in /var/cache/auto-upgrade-tester/test-image.$name.lucid and add it manually there
[16:32] <mvo> cjwatson: probably a quicker solution
[16:36] <cjwatson> mvo: oh right
[16:39]  * mvo is away for a bit
[16:40] <mpt> mvo, hi, what do I need to know before doing this? "[mpt] Invite people to port release-upgrader to aptdaemon"
[16:40] <mpt> d'oh
[16:52] <manish> where is federico?
[16:52] <manish> sorry, wrong channel :)
[17:15] <kenvandine> anyone around that can re-score a ppa build?  indicator-appmenu in the unity-team/hud ppa has a pretty critical fix and it is estimating 20 hours
[17:15] <kenvandine> infinity or stgraber ^^
[17:16] <stgraber> kenvandine: url?
[17:17] <infinity> kenvandine: Done
[17:18] <kenvandine> thanks!
[17:42] <bryceh> @pilot in
[18:15] <slangasek> jibel: hi, should I see the effects of your job rearranging on https://jenkins.qa.ubuntu.com/view/Precise%20Upgrade%20Testing%20Dashboard/ ?  I still see all red at the top level
[18:17] <smoser> can i get someone to approve dbus-python's new 'python-dbus-dev' at https://launchpad.net/ubuntu/precise/+queue?queue_state=0&queue_text=
[18:17] <slangasek> jibel: oh n/m, you said "published to the public instance on the next run" :)
[18:17] <jibel> slangasek, the jobs are still running/queued
[18:17] <slangasek> jibel: ack - sorry for reading with my manager glasses on
[18:17] <smoser> it is depends of python-dbus with is depended on by a lot of things and is currently not installable
[18:17] <jibel> slangasek, np
[18:18] <slangasek> smoser: looking
[18:18] <slangasek> smoser: python-dbus depends on python-dbus-dev, though?  That's surely broken
[18:18] <smoser> changelog says
[18:19] <smoser> make python-dbus depend on python-dbus-dev for now, to preserve istorical functionality (but packages which use it, like PyQt, should  switch to depending on it explicitly)
[18:19] <smoser> so it was by design
[18:19] <slangasek> ah, so it's a package splitting
[18:19] <slangasek> ok
[18:21] <slangasek> jibel: oh, also - did you catch my note that the prompting for service restart on glibc upgrade on server installs is by design and shouldn't be counted as a test failure?
[18:21] <slangasek> smoser: accepted
[18:22] <smoser> gracias
[18:22] <jibel> slangasek, yes, I'll add the prompt to the whitelist.
[18:29] <smoser> slangasek, how fast does that take affect? every 1/2 hour?
[18:32] <cjwatson> smoser: should start publishing in one minute and finish in about half an hour from now
[18:32] <smoser> thank you cjwatson
[18:39] <bryceh> @pilot in
[19:16] <arges> bryce, hello patch pilot. have a patch that needs reviewing. this is my first one so i probably have it all wrong
[19:17] <arges> bryce, tried to follow the directions in the wiki. its a patch to fix https://bugs.launchpad.net/ubuntu/+source/rhythmbox/+bug/885502.
[19:21] <slangasek> smoser: every half hour, yes
[19:22] <smoser> its in now
[19:22] <slangasek> jibel: oh, is that whitelist somewhere I could see it?  (Mostly out of curiosity)
[19:22] <smoser> my build is going
[19:22] <slangasek> smoser: yay
[19:32] <stgraber> slangasek: trying to refresh ubuntu-meta, I'm getting "Skipping package resolvconf (package not in debootstrap)". Do you know what needs to happen for germinate to be happy and add it to -minimal?
[19:36] <stgraber> slangasek: <cjwatson> It probably means that the package isn't Priority: required/important yet.  An archive admin who isn't in the pub can fix that based on priority-mismatches output.
[19:36] <stgraber> slangasek: priority-mismatches says it should be moved from optional to important
[20:54] <hallyn> jdstrand: this is getting ridiculous.  I ran 'make check' in netcf in a precise chroot on hardy.  Pass.
[21:06] <Daviey> doko: Hey, had a chance to look at bug 914160 ?
[21:07] <infinity> hallyn: So, it's not the kernel version either? :/
[21:07] <hallyn> infinity: (GAH!) so it seems...
[21:07] <infinity> hallyn: Did you try it in that configuration, but with sbuild?
[21:08] <hallyn> infinity: so i'm at a loss
[21:08] <infinity> Not that I'd expect sbuild's FD buggery to behave differently on a hardy kernel, but...
[21:08] <hallyn> no, i don't know how to do that
[21:08] <hallyn> debootstrap wouldn't do precise.  that's hwy i scp'd over a precise chroot
[21:08] <infinity> debootstrap is an arch:all package with no deps, you can install the precise version on hardy.
[21:09] <hallyn> install precise version of debootstrap?  just 'dpkg -i' it?
[21:09] <infinity> https://launchpad.net/ubuntu/+source/debootstrap/1.0.38/+build/2945367/+files/debootstrap_1.0.38_all.deb
[21:09] <infinity> Yeah.
[21:09] <hallyn> all right lemme try, thanks
[21:21] <hallyn> lack of aufs and ext4 is really annoying
[21:28] <hallyn> infinity: build... successful
[21:29] <hallyn> and with that, i'm pulling 'make check' from the build
[21:35] <infinity> hallyn: Wasn't it only one test that was failing?  Surely you can disable that one.
[21:35] <infinity> hallyn: test-debian, or whatever it was.
[21:35] <hallyn> infinity: all the other tests are just gnulib tests.  and one of those (test-float) actually fails on powerpc
[21:35] <hallyn> that is, there is only one test supplied by netcf itself
[21:35] <infinity> Oh.
[21:35] <infinity> Special.
[21:40] <hallyn> infinity: is there any way to get a shell in an *exact* replica of buildd env?
[21:40] <htorque> hi all! on ask ubuntu someone asked when btrfs-tools will see an update. is there anything else than bug 894456 i can tell that user?
[21:42] <micahg> htorque: needs a merge from Debian
[21:43] <infinity> hallyn: Well, you can download the buildd chroots from launchpad.
[21:43] <hallyn> oh?
[21:44] <htorque> micahg: is that planned for precise (or is it a case of "someone needs to do it")?
[21:44] <infinity> hallyn: https://api.launchpad.net/1.0/ubuntu/precise/armhf/ for example.
[21:44] <infinity> hallyn: (replace armhf with the arch you want)
[21:44] <hallyn> infinity: thanks.
[21:44] <infinity> hallyn: That said, I tried reproducing it in a buildd chroot, and got nowhere.
[21:45] <micahg> htorque: someone needs to do it, cjwatson touched it last, I don't know if he's interested in doing it though
[21:45] <htorque> micahg: ok, thanks for the info! :-)
[21:58] <slangasek> jcastro: who has access to delete pages from help.ubuntu.com?
[22:03] <stgraber> slangasek: can you override the priority of resolvconf to important? that needs to happen before I can upload a new ubuntu-meta
[22:11] <jibel> slangasek, that will be quick, the list empty.
[22:11] <jibel> the code of the debconf test is there http://bazaar.launchpad.net/~ubuntu-core-dev/update-manager/main/view/head:/AutoUpgradeTester/post_upgrade_tests/debconf_test.py
[22:16] <hallyn> infinity: you say the netcf 'make check' passed when you ran it in the buildd chroot right?
[22:16] <slangasek> jibel: heh, ok :)
[22:17] <slangasek> stgraber: yes, looking
[22:18] <slangasek> stgraber: done
[22:18] <stgraber> slangasek: thanks
[22:20] <micahg> I'm guessing pitti isn't around anymore at this hour
[23:23] <micahg> stgraber: I think you forgot to set DEBEMAIL :)
[23:26] <stgraber> micahg: yeah, I just noticed in -changes ;)
[23:27] <stgraber> micahg: should have checked the output of that script a bit more carefully
[23:29] <stgraber> micahg: will make a note to fix the changelog entry next time I upload it... (and fixed that chroot to have a decent environment)
[23:35] <Laney> ah I heard about this 'root' fellow somewhere
[23:37] <ajmitch> pretty dangerous person, I heard
[23:37] <stgraber> ;)
[23:45] <pp7> root is a badass!