[00:34] <infinity> soren: Don't worry about rebasing that qemu-kvm SRU, I just did it for you.
[01:33] <TheMuso> ?C
[03:31] <herton> @pilot out
[04:31] <ScottK> doko__: kmediafactory in the rebuild could be retried.  I think it'd work.
[05:51] <pitti> Good morning
[08:16] <cjwatson> ScottK,doko__: retried kmediafactory
[08:22] <pitti> cjwatson: hm, do you see what's wrong with this command?
[08:22] <pitti> copy-package -b -s oneiric --ppa-name ppa -p ubuntu-langpack --to-suite=oneiric-proposed language-pack-{,gnome-,kde-}se{,-base}
[08:22] <pitti> cjwatson: it always fails with "400 Bad Request: name: Required input is missing"
[08:23] <pitti> same with just one package name
[08:23] <cjwatson> PPAs don't have -proposed; are you trying to copy to the primary archive?
[08:23] <pitti> no, from langpack PPA to the real oneiric-proposed
[08:23] <cjwatson> So "yes" then
[08:24] <cjwatson> Try --to-primary
[08:24] <pitti> but I didn't specify --to-ppa*
[08:24] <cjwatson> It defaults to the source archive
[08:24] <pitti> ah
[08:24] <cjwatson> Note, this is different from the old copy-package.py
[08:25] <pitti> thanks
[08:27] <gsedej_work> hi! Is it ok to report bug "missing logout option" in 12.10 live?
[08:29] <darkxst> gsedej_work, that will be fixed in the next images (if you are talking about ubuntu gnome remix)
[08:34] <gsedej_work> darkxst, I don't see "logout" in ubuntu unity
[08:34] <gsedej_work> live
[08:34] <gsedej_work> I have big problems for testing KDE in 12.10
[08:35] <gsedej_work> Or is it just me not seeing option "logout" in top right corner (LiveCD/USB)
[08:35] <darkxst> unity disables logout on livecd
[08:36] <darkxst> (well indicator-session does)
[08:39] <darkxst> but it should return it you add another user (or rename the ubuntu user)
[09:10] <gsedej_work> darkxst, thanks for explanation, but this still complicates very much the way to test other DE
[09:10] <gsedej_work> I had to install kdm and use it
[09:10] <gsedej_work> lightdm config was not permanent, it was always rewritten
[11:41] <cjwatson> wookey: gdbm from your aarch64 config.guess/sub patch stack seems to be unnecessary; debian/rules copies in current versions from /usr/share/misc/ on every build
[11:48] <wookey> cjwatson: OK, sorry missed that
[11:48] <wookey> good for it :-)
[11:48] <wookey> if only everything did that...
[11:53] <cjwatson> wookey: I'm getting there with this set; just dropbear, expat, libgpg-error, libx11, libxml2, libxslt, make-dfsg, pcre3, and slang2 to do
[11:53] <cjwatson> keeping track by way of visited link colours :)
[12:28] <wookey> cjwatson: I've got some aarch64 fixes for linux-3.5.0 so that it makes a source package suitable for cross-toolchain building
[12:28] <wookey> I'm assuming that's not the sort of change you'll want to be putting in at this stage
[12:30] <cjwatson> wookey: nooooooooooo
[12:30] <cjwatson> wookey: but in any case, send them to the kernel team
[12:30] <cjwatson> I'm definitely not going to be uploading linux independently :)
[12:31] <wookey> yeah, I'll file a bug with the patch soonish (still hacking eglibc to work)
[13:07]  * cjwatson looks deeply confused at libgpg-error
[13:07] <cjwatson> $ cat debian/source/format
[13:07] <cjwatson> 3.0 (quilt)
[13:07] <cjwatson> $ ls debian/patches/
[13:07] <cjwatson> 00list                 06_Makefile.in.dpatch   m4_macros.dpatch
[13:07] <cjwatson> 05_Makefile.am.dpatch  10_relibtoolize.dpatch
[13:08] <cjwatson> Just when you think you've seen all the weird ways people construct packages
[13:08] <ogra_> well, it has error in the name ...
[13:12] <mlankhorst> m is a number right? :P
[13:13] <ion> m4 is a perfectly cromulent base-64 number.
[13:13] <ion> err, base-36
[13:16] <ogra_> @pilot in
[13:16] <cjwatson> mlankhorst: that's the least of the problems ...
[13:16] <mlankhorst> or maybe I'm selectively blocking horrors so I don't have to worry about it
[13:24] <tjaalton> dpatch with 3.0 (quilt), lovely
[13:25] <mlankhorst> not listening! :o
[13:26] <xnox> cjwatson: I had sponsoree package without source/format specified (that is 1.0) with bzr-bd branch with quilt patches applied. Seeing .pc dir in diff.gz was natural to me.... until it was not bzr log of a udd branch =)
[13:29] <cjwatson> jamespage: I've noticed several Java packages failing to build because of missing javax.http.servlet.  The fix seems to be to build-depend on libservlet3.0-java, but I wanted to check (a) that this was correct (since there are several libservlet*-java) and (b) why this failure seems to be associated with the OpenJDK 7 change
[13:30] <diwic_> packages who do anything with multiarch should upload to quantal-proposed instead of quantal, right? To ensure safe upgrades for people having both amd64 and i386 versions of the package installed.
[13:30] <jamespage> cjwatson, odd - can you point me at an example please
[13:30] <cjwatson> jamespage: openid4java
[13:31] <cjwatson> diwic_: Theoretically yes; although realistically multiarch is going to be rocky during development releases until such time as we're directing everything to -proposed and handling it automatically
[13:31] <cjwatson> But it's OK to do so
[13:31] <diwic_> cjwatson, what's the recommendation?
[13:32] <cjwatson> Me having noticed this before recommending this morning that jodh use quantal not quantal-proposed for libnih ;-)
[13:32] <cjwatson> diwic_: -proposed is the conscientious option
[13:32] <tjaalton> could an archive admin remove libmusicbrainz from quantal, there's lmb-5 that replaced it. would fix bug 1036511
[13:33]  * diwic_ uploads to quantal-proposed for an extra gold star in the booklet.
[13:33] <diwic_> thanks
[13:33] <cjwatson> tjaalton: it's in my queue
[13:33] <tjaalton> cjwatson: oh cool
[13:36] <jamespage> cjwatson, I think it may have something todo with the switch of tomcat6/7 in main this cycle
[13:37]  * jamespage refreshes his memory
[13:38] <cjwatson> tjaalton: done
[13:39] <tjaalton> cjwatson: thanks
[13:40] <jamespage> cjwatson, oddness in libcommons-logging-java is the root cause
[13:41] <jamespage> and the fact that I only transitioned r-b-d's in main to depend on tomcat7
[13:42] <cjwatson> Ah
[13:42] <cjwatson> So I should just s/servlet2\.5/servlet3.0/ and move on?
[13:43] <cjwatson> hm, wait, it doesn't b-d on libservlet3.0-java directly
[13:45] <cjwatson> libehcache-java Depends: libservlet2.5-java
[13:47] <jamespage> cjwatson, TBH its a fluke it works
[13:47] <jamespage> libcommons-logging-java sets a classpath manifest which openjdk which read
[13:48] <jamespage> which includes servlet3.0.jar
[13:48] <jamespage> but the package only Suggest's it
[13:48] <cjwatson>   * Move libservlet2.3-java from Depends to Suggests (Closes: #526043)
[13:49] <Sweetshark> doko: I assume the vigra stuff is solved now? I would have time to look at it now, but I guess I can dump that now as you already tested it?
[13:49] <cjwatson> "It is pretty unexpected to have a dep related to servlets on a logging application" says the bug reporter
[13:49] <jamespage> cjwatson, which is kinda of right
[13:49] <jamespage> commons-logging is design to work in servlet containers
[13:50] <jamespage> where the servlet api is 'provided' by the container
[13:50] <jamespage> so its a build-time only dependency
[13:50] <cjwatson> I wonder how things like https://launchpadlibrarian.net/117244429/buildlog_ubuntu-quantal-i386.acegi-security_1.0.7-3_BUILDING.txt.gz work
[13:50] <doko> Sweetshark, lo builds with the new one, as commented in the issue
[13:51] <jamespage> cjwatson, the correct fix IMHO is to BD in openid4java on libservlet3.0-java (its backwards compat with 2.5)
[13:52] <Sweetshark> doko: yeah, I also did a ppa build against it in the meantime.
[13:52] <cjwatson> hrw: I'm confused by your rules changes in gcc-defaults-armel-cross (and presumably armhf but I haven't looked at that yet)
[13:52] <jamespage> and fix its build process to sort out its own classpath rather than depend on the only partially implemented Class-Path manifest method
[13:52] <cjwatson> hrw: you have build-arch depending on build-stamp, which now depends on install, which runs dh_testroot
[13:52] <mterry> @pilot in
[13:52] <cjwatson> hrw: build-arch is not allowed to require (fake)root, so this looks wrong
[13:53] <cjwatson> hrw: can you explain the problem you were trying to solve?
[13:53] <cjwatson> jamespage: OK, that would have been my first instinct, so that's good, thanks
[13:53] <cjwatson> jamespage: I'll take care of it
[13:53] <jamespage> cjwatson, ta
[13:54] <doko> cjwatson, hrw: the previous build failure was caused by calling a binary target in a build target
[13:54] <doko> (in the test rebuild)
[13:55] <cjwatson> well, it's not the target names that matter here, it's the use of dh_testroot
[13:55] <cjwatson> I don't see how this upload will fix that failure
[13:55] <cjwatson> in general build{,-arch,-indep} should not depend on install-type rules
[13:57] <hallyn> cjwatson: hi, do you have any objections to the proposed fix for bug 1060404 ?  without some solution, ubuntu-cloud containers can't be updated... (not sure if juju is going to default to ubuntu-cloud conainers during q or not)
[13:57] <hrw> reject it - will rewrite that rules
[13:57] <cjwatson> hrw: OK, done, thanks
[13:58] <cjwatson> hallyn: Hmm.  Does /boot/grub/grub.cfg exist when the container is first built?
[13:58] <hrw> cjwatson: when it comes to cross packages then both armel and armhf have same packaging cause I generate them
[13:58] <cjwatson> hallyn: I assume not, since you need update-grub to build that
[14:00] <hallyn> cjwatson: not sure, but i think so, because these are the same cloud images you can use in kvm
[14:01] <hallyn> cjwatson: yeah, it is there
[14:01] <cjwatson> Then that means that if you update the image in a container you can't later boot it in kvm
[14:02] <hallyn> i think we're ok with that.  simply being unable to cleanly update is a bigger problem
[14:03] <cjwatson> Well, I'm willing to apply that for 12.10, but I don't consider it the right fix.  I'd like to leave a comment that it's temporary, and I'd like to have a bug with the details of what goes wrong when you run update-grub in a containere
[14:03] <cjwatson> *container
[14:03] <cjwatson> Because the intent is absolutely that you should be able to run update-grub no matter what
[14:04] <cjwatson> hallyn: In fact, something along the lines of debian/patches/mkconfig_skip_dmcrypt.patch might be a cleaner approach
[14:04] <hallyn> that would be nice.  but i dont' think there is a general way grub can know what the root dev should be.
[14:04] <hallyn> checking
[14:05] <cjwatson> (That patch may actually be obsolete now with LUKS support, but that aside ...)
[14:05] <hallyn> yes, something like that.  there will be more than one case to consider...
[14:05] <cjwatson> Well, it could call running-in-container, even
[14:06] <hallyn> as long as we're updating grub itself it's worth trying to do better;
[14:06] <hallyn> it *is* possible to be in a container that is backed by a real rootdev which you're allowed to open;
[14:06] <cjwatson> It'd be no worse there than in the update-grub wrapper, and I think it might be neater
[14:06] <hallyn> agreed, but i'm saying for a longer term (13.04) solution ...
[14:06] <cjwatson> Do you have a log somewhere of the update-grub failure?
[14:06] <cjwatson> I'd like to see what it's doing
[14:07] <cjwatson> In particular, which grub-probe command is failing
[14:07] <hallyn> no, but it's trivial to reproduce.  am on mobile net, need a few mins to spin up an instance
[14:08] <cjwatson> At this stage, GRUB is only trying to work out the root device in order to work out which modules to include (LVM, RAID, the filesystem, etc.) and to add probing hints to speed things up at runtime
[14:08] <cjwatson> Even if it can't open the root device, in principle it ought to be possible to set GRUB_MODULES to augment the autodetection, and still have update-grub work
[14:11] <cjwatson> hallyn: Oh, BTW, I think your patch as written is a no-op due to the unnecessary ``
[14:12] <cjwatson> Actually maybe not a no-op.  But hard to parse.
[14:12] <hallyn> oops, yeah that shouldn't be there
[14:12] <cjwatson> 'type' returns a perfectly good exit code, so you don't need to wrap it in command substitution
[14:13] <hallyn> hm, pretty quick:
[14:13] <hallyn> ubuntu@q1:~$ sudo update-grub
[14:13] <hallyn> /usr/sbin/grub-probe: error: failed to get canonical path of /dev/disk/by-label/cloudimg-rootfs.
[14:14] <hallyn> (/dev/disk isn't in the container, of course)
[14:14] <cjwatson> hallyn: Could you put 'set -x' at the top of /usr/share/grub/grub-mkconfig_lib ?  I'd like to see a trace
[14:17] <hallyn> cjwatson: http://paste.ubuntu.com/1260027/
[14:18] <cjwatson> hm, right, *very* early
[14:19] <cjwatson> hallyn: OK, so I would like a separate bug with that trace, but I'll apply a tweaked version of your patch for now then
[14:19] <hallyn> cjwatson: yeah, but again i guess it just sees '/dev/disk/by-label/cloudimg-rootfs on / type ext4 (rw)' in mount output
[14:19] <hallyn> cjwatson: so while i would bristle at this, it coudl be lcaimed that th eproblem is the container doesn't have /dev/disk/by-label set up
[14:19]  * hallyn tries to fake that one
[14:19] <pitti> doko: not all python crashes are pyobject crashes ... :)
[14:20] <doko> pitti, no, some are dbus-python too ;-P
[14:20] <cjwatson> Well, it uses mountinfo, but yes
[14:20] <cjwatson> But it'd need a fairly complete /dev for it to actually work
[14:20] <pitti> doko: (j/k; following up with requests for reproducers)
[14:21] <hallyn> cjwatson: yes, when i mknod /dev/vda1 and thenln that to /dev/disk/by-label/cloudimg-rootfs, update-grub succeeds
[14:21] <doko> pitti: still wondering why these end up assign to python2.7, because the script name is available ...
[14:21] <pitti> doko: looking at bug 1036438
[14:21] <pitti> doko: that seems to be a local script (not packaged)
[14:21] <l3on> Hi guys.. what does the packages you think this bug can be related (see the red rectangle) http://people.ubuntu.com/~l3on/tmp/underscore_replace-bug.gif ?
[14:22] <pitti> doko: and no useful stuff in the stack trace at all; I'll just ask for a reproducer
[14:23] <cjwatson> hallyn: hm, so is that doable by default?
[14:23] <cjwatson> I'd obviously rather not change common code if it's avoidable
[14:24] <hallyn> well it'll be common code one way or the other.  what we'd do (i think) is have an upstart job (shipped with upstart) which runs if in a container and set up the dev/disk stuff for the rootfs at startup
[14:24] <hallyn> stgraber: ^
[14:25] <cjwatson> OK.  Well, personally I prefer that option, but perhaps that's because it doesn't involve changing my package ... can I let you and stgraber hash it out and let me know what you decide? ;-)
[14:26] <hallyn> cjwatson: absolutely.  thanks, ttyl
[14:26] <cjwatson> I have your patch ready to commit if that's what you opt for
[14:26] <hallyn> thanks (i think the attached version stupidly left out the 'LP:' tag fwiw)
[14:27] <mterry> cjwatson, I'm seeing an SRU bug in the sponsor queue that you uploaded to quantal and have assigned to you for precise.  (bug 978654)  Did you upload already?  Else, I'd be happy to upload
[14:27] <cjwatson> Yeah, I have that locally
[14:28] <cjwatson> mterry: I didn't upload, and the assignment was mostly a reminder to get back to it after 12.10 (I don't plan to do much SRU work before then).  Feel free to take it
[14:28] <mterry> cjwatson, k
[14:29] <cjwatson> mterry: (But please use the patch I uploaded rather than the previous incorrect ones in the bug)
[14:29] <mterry> cjwatson, yes
[14:37] <ogra_> hmm, no alkisg
[14:39] <ogra_> cjwatson, i dont realy understand the bug status for bug 978654 ... your barnch has been merged into precise-poposed the top-level task is fix released but there is still a precise task in triaged state ?
[14:39] <ogra_> *branch
[14:39] <ogra_> should that be closed or should tehere be a quantal task  ?
[14:41]  * hallyn wonders whether grub_find_root_devices_from_mountinfo should be provided by a tiny general library
[14:41] <ogra_> oh, the upload actually wnet to quantal, its just the branch naming thats confusing
[14:42] <cjwatson> ogra_,mterry: ... oh, maybe I did upload that
[14:42] <cjwatson> mterry: Sorry, yeah, that's actually waiting for approval in precise-proposed
[14:42] <cjwatson> There's something of a backlog
[14:43] <mterry> cjwatson, ah ok.  I'll mark as in progress then I guess
[14:43] <cjwatson> Yeah, please
[14:43] <ogra_> mterry, oh, we clashed
[14:43] <cjwatson> Sorry for the confusion
[14:43]  * ogra_ didnt read backlog :)
[14:43] <mterry> ogra_, ah yes, both on sponsor duty.  Shall I go from the bottom?
[14:44]  * ogra_ decides to rather work from the bottom of the list upwards then :=)
[14:44] <mterry> heh
[14:44] <ogra_> first !
[14:44]  * mterry works from the top
[14:48] <cjwatson> doko: So, you were asking why these amd64 build-arch failures weren't showing up in Debian; well, I just ran across one that does: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=666307
[14:48] <cjwatson> The package is orphaned so I think I'll fix that in a QA upload
[14:49] <doko> cjwatson, hmm, but that's not related to dpkg-dev?
[14:49] <ogra_> wookey, your patch to bug 1056975 is for precise only but there is no precise SRU task ... i'll upload it into quantal (with the series adjusted) could you take care of the paperwork to also have it in precise ?
[14:49] <cjwatson> doko: Sure it is, it's dpkg-dev now choosing to use build-arch
[14:50] <cjwatson> And the package having 'build: patch' in debian/rules, but a % target which means that build-arch doesn't apply patchces
[14:50] <cjwatson> *patches
[14:50] <cjwatson> Sane fix in this day and age is to convert to 3.0 (quilt), which I'll do
[14:50] <doko> ahh, ok
[14:51] <doko> yes, did the 3.0 conversion for another package too
[14:51] <Laney> not sure the release team will like that, if you plan on asking for an unblock
[14:51] <cjwatson> Laney: *shrug* it's simpler than any other fix, and the package already uses quilt
[14:51] <cjwatson> I'm happy to argue that with them directly
[14:52] <cjwatson> Laney: But as it happens the package in question has already been removed from testing, so I don't see a need to have that debate
[14:52] <Laney> Good. I didn't check
[14:54] <mlankhorst> cjwatson: does initramfs-tools have a git repository for ubuntu?
[14:54] <cjwatson> mlankhorst: No
[14:55] <cjwatson> mlankhorst: bzr - lp:ubuntu/initramfs-tools
[14:55] <mlankhorst> ah k
[14:55] <cjwatson> It's in a weird state at the moment due to a cherry-pick with an odd version number
[14:56] <cjwatson> But should be usable
[14:56] <xnox> mlankhorst: if in daubt, ask infinity =) he should know.
[14:56] <cjwatson> So should I :-P
[14:56]  * cjwatson <- last uploader
[14:56] <xnox> cjwatson: well you generally don't cause confusion with cherry-picks
[14:56]  * xnox can still blame infinity =)
[14:56] <cjwatson> No, but I understand the reason for this one
[14:57] <xnox> ah, ok.
[14:58] <mlankhorst> cjwatson: what about sru's for precise, are they tracked in a separate bzr branch?
[14:58] <cjwatson> mlankhorst: I'd assume the usual naming scheme but don't especially care about bzr branches for SRUs :-)
[14:59] <cjwatson> Don't worry about it - the importer will take care of it
[15:00] <mlankhorst> I wanted to sru the fix for #1017991, and add any other drivers that are similarly missing, I need hid-logitech-dj for my keyboard
[15:00] <mlankhorst> bug #1017991
[15:00] <cjwatson> just prepare a source package or whatever
[15:01] <mlankhorst> yeah k
[15:03] <mlankhorst> off for a bit, will do it tomorrow :)
[15:09] <jamespage> barry, thanks for fixing that FTBFS in genshi
[15:10] <ogra_> mfisch, lookin at your merge at bug 1054353, seems you missed to use -v  4ubuntu1 when generating the patch for xfonts-mathml-6 ... could you fix that ? then i'll upload
[15:10] <barry> jamespage: np.  not sure the way i did it is what upstream will eventually adopt, since i'm not sure what the intent is for those previously failing examples.  but hey, at least it gets built now :)
[15:10] <mfisch> ogra_: let me look
[15:11] <ogra_> the second patch looks ok
[15:11] <mfisch> ogra_: -v when running debdiff?
[15:11] <cjwatson> err, yeah, -v is something the sponsor does when building the source package
[15:11] <ogra_> no, when generating the source package
[15:12] <cjwatson> you should be building it yourself
[15:12] <ogra_> cjwatson, oh, i always ask for that in the debdiff too
[15:12] <cjwatson> based on the submitter's patch
[15:12] <cjwatson> why?
[15:12] <cjwatson> there's no need for a patch submitter to worry about this
[15:12] <ogra_> for completeness and to train good habits :)
[15:12] <ogra_> ok
[15:12] <ogra_> i'll move on with it as is then
[15:14] <mfisch> I'll try to do that next time if it's helpful in the process
[15:14] <ogra_> mfisch, well, its only helpful to have it in your finger-memory once you upload the merges yourself
[15:14] <mfisch> ogra_: understood
[15:35]  * ogra_ glares at all these misc depends merge requests  
[15:35] <ogra_> do we really want to add that in ubuntu ? it should go to debian, no ?
[15:38] <micahg> ogra_: they should be for Ubuntu only packages, but probably shouldn't be a priority at this point in the release unless they're actually adding something to the package
[15:39] <Laney> ogra_: you can just merge them to the packaging branch and leave it unreleased
[15:39] <Laney> in theory that gets it included next time ... ahem.
[15:40] <ogra_> if MoM is clever :)
[15:40] <stokachu> ogra_, mterry : could either of you sponsor https://launchpad.net/bugs/1036834?
[15:40] <micahg> which since these are most likely neglected packages as well, will result in yet another merge proposal
[15:40] <stokachu> it is a pretty easy one
[15:40] <ogra_> stokachu, yeah, just looked into it and then fell over when i downloaded the source package :P
[15:40] <stokachu> lol
[15:40] <ogra_> i'll get to it
[15:41] <stokachu> ok cool, thanks a bunch
[15:53] <pitti> ev: just looked at your recent apport commit; is df.data.tgz() actually going to work for bz2 and xz compressed .debs as well?
[15:54] <ogra_> argh
[16:03] <ev> pitti: seems to
[16:03] <ev> I think it's just a poorly named function
[16:04] <cjwatson> mterry: ah, hooray for your aptitude merge
[16:04] <mterry> :)
[16:04]  * cjwatson scratches an item off his to-do list
[16:10] <barry> doko: i think the b-d conflict that was causing claws-mail-extra-plugins to ftbfs in your test rebuild has been resolved with a new upload of libgdata.  i can't do a retry, not sure if you can, or if its worth it
[16:11] <doko> barry, given back
[16:11] <barry> doko: thanks.  i'll keep an eye on it, but i think bug 1060489 is resolved
[16:20] <ogra_> stokachu, :/ ... the build-deps are totally messed up in the gdb patch
[16:21] <ogra_> ...  mig [], cdbs (>= 0.4.17), libkvm-dev [], ....
[16:22] <ogra_> something seems to have wiped all traces of hurd
[16:22] <ogra_> butu left the packages and brackets in place
[16:22] <stokachu> wow, how did that happen
[16:23] <ogra_> stokachu, i assume you didnt mean to touch them, right ?
[16:23] <stokachu> yea i just changed one line in the control file
[16:24] <stokachu> ogra_: thats so odd, the debdiff's show a changelog entry and a one line change
[16:25] <stokachu> oh wtf
[16:25] <stokachu> the precise shows the build-depends
[16:25] <stokachu> ogra_: honestly i have no idea how that happened
[16:25] <stokachu> the build-depends shouldnt have been touched, want me to generate a new debdiff?
[16:25] <ogra_> well, there seems to be some control.in processing
[16:26] <stokachu> quantal looks fine, however
[16:27] <stokachu> lemme regenerate the precise debdiff
[16:34] <stokachu> ogra_: so odd, i change the control.in file and when i generate the source it alters the build-depends
[16:34] <hallyn> ok what am i doing that's silly?
[16:34] <hallyn> MAKEDEV -n vda1
[16:34] <hallyn> /sbin/MAKEDEV: don't know how to make device "vda1"
[16:35] <sarnold> my precise MAKEDEV doesn't know vda either
[16:35] <hallyn> drat
[16:36] <hrw> doko: checking 4.5/cross - maybe will update it instead of removing
[16:36] <hallyn> course vda1 would be wrong anyway :)  'sd' works, 'sda1' does not
[16:37] <stokachu> is altering control.in deprecated now?
[16:37] <hallyn> well if makedev needs a patch to know about vda, then i'm afraid that brings me over the 'wait for 13.04' threshold
[16:37] <ogra_> stokachu, i guess that needs some hint from doko or hrw
[16:38] <mitya57> barry: how do you feel about uploading py3-defaults snapshot (something like 3.2.3-5+bzr171) into quantal?
[16:38] <mitya57> (or do you think we can SRU that / ignore those bugs?)
[16:38] <hrw> hallyn: devtmpfs.mount=1 and ignore any makedev
[16:40] <stokachu> doko,hrw: should i be altering control.in for gdb?
[16:40] <hrw> stokachu: yes, cause debian/control at one day will be regenerated
[16:41] <stokachu> hrw: when altering control.in in precise and regenerating the debdiff https://launchpadlibrarian.net/116712597/gdb_7.4-2012.04-0ubuntu2.1.precise.debdiff
[16:41] <stokachu> that is the result where it alters the build-depends
[16:42] <hrw> ugly indeed
[16:42] <wookey> cjwatson: libxslt and libxml2 also use dh --with autoreconf, so my bugregreps are null. And libx11 autoreconfs every time too.
[16:43] <wookey> The others seems to remain valid.
[16:43] <cjwatson> Ah, good.  Yes, I've been checking for autoreconf
[16:43] <hrw> stokachu: leave original b-d than
[16:44] <stokachu> hrw: should i copy the original b-d over to the control.in and build patch for that as well
[16:45] <hrw> stokachu: in control.in you only added m-a line. add it by hand to control
[16:45] <hallyn> hrw: may or may not be an option.
[16:45] <hrw> stokachu: I would have to check packaging but not today
[16:45] <stokachu> hrw: ok
[16:46] <stokachu> hrw: would you like me to create a bug on it?
[16:46]  * micahg would think that you'd add it to control.in and regenerate control
[16:47] <stokachu> yea adding it to control just gets overwritten during source packaging
[16:49] <hallyn> hm, but yeah, just putting devtmpfs in the container fstab (so it gets mounted before apparmor restrictions) may be working
[16:49] <stokachu> http://paste.ubuntu.com/1260320/ - this is what is generated now when updating control.in
[16:49] <stokachu> properly alters control to just change the multi-arch and updates the b-d in control.in
[16:50] <stokachu> question is do you want this separated out or have the control.in modifications included
[16:50] <stokachu> i can certainly create a new bug with the control.in patch
[16:51] <tjaalton> slangasek: ping re bug 804109
[16:53] <micahg> stokachu: well, if an empty variable is bad there, just fix debian/rules to make the substitution work properly in Ubuntu as well (or put some sane value there)
[16:53] <doko> slangasek, stokachu: libgnome MA upload was rejected by stgraber, missing a FFe. is the FFe now done?
[16:53] <micahg> stokachu: I mean empty brackets
[16:55] <hrw> stokachu: I logged into precise, fetched gdb/precise, changed debian/control.in to add m-a line. then 'debian/rules debian/control -B' and debian/control had only m-a added, rest was same
[16:55] <stokachu> hrw: ok i was running a bzr ci; bzr bd -- -S -us -uc
[16:55] <stokachu> doko: one sec
[16:56] <stokachu> doko: FFe for precise?
[16:56] <stokachu> doko: it says libgnome is fix released in quantal
[16:56] <hrw> stokachu: I do not use bzr for such things
[16:57] <hallyn> cjwatson: ok, so if the ubuntu templates cause devtmpfs to be mounted before the container init starts, update-grub succeeds.  However then you're annoyingly prompted whether you want to install grub in /dev/vda1 (as it hasn't been installed yet)
[16:57] <hrw> stokachu: basically I do not use bzr at all nowadays
[16:57] <hallyn> if you say yes, it fails.  if you say no, it happily continues
[16:57] <stokachu> hrw: ok so you are saying this is not a bug then?
[16:57] <hallyn> i guess we can be happy with that for q, but for r it woudl be nice if grub woudl say "oh, but i can't write to /dev/vda1" (cgroup prevents it) and then shut up
[16:58] <doko> stokachu, hmm, which lib was the other one?
[16:58] <stokachu> doko: https://bugs.launchpad.net/ubuntu/+source/libgnomecanvas/+bug/1013211
[16:58] <stokachu> that has the ffe
[16:58] <stokachu> which *i think* is done
[16:59] <cjwatson> hallyn: Well, that relates to grub-install rather than update-grub; I expect that's fixable ...
[16:59] <cjwatson> I'm not totally sure writability is the right test; tricky to establish in advance of asking the question
[17:00] <hallyn> cjwatson: agreed, i'm also not sure :)  but offhand it feels right;  if i'm not allowed to write to it, no sense trying to install grub to it.  we can discuss that at uds or around that time?
[17:00] <cjwatson> I don't see a need to wait :)
[17:01] <cjwatson> So GRUB hasn't been installed *anywhere* yet?
[17:01] <hallyn> nope
[17:01] <doko> stgraber, stokachu: hmm, then why was it rejected? don't see a comment from the release team either
[17:01] <hallyn> it's a container running in a chroot
[17:01] <hallyn> i mean yes, it has been installed on /dev/vda (for the amazon instance itself), but not on /dev/vda1 (which has '/' for the container)
[17:02] <cjwatson> Right, as far as the postinst is concerned that means it's been installed somewhere
[17:02] <stokachu> doko: no idea :)
[17:02] <cjwatson> Because /boot/grub/{,*/}core.img will exist
[17:03] <cjwatson> I suppose we could just skip the whole grub-install path in a container
[17:03] <cjwatson> Bit nasty but maybe tolerable
[17:03] <cjwatson> And no worse than skipping update-grub in a container, possibly better
[17:03] <hallyn> hold on, i'mnot convinced core.img exists in the container, checking
[17:04] <stokachu> hrw: no idea then i ran your command and it still alters the build-depends on debian/control
[17:04] <cjwatson> Well, from the code, either it exists, or grub-pc is being installed from scratch
[17:04] <hallyn> cjwatson: nope, doesn't exist
[17:04] <cjwatson> Huh
[17:04] <cjwatson> That's truly bizarre
[17:04] <hallyn> why?
[17:04] <cjwatson> Because in that case you shouldn't be asked that question
[17:05] <hallyn> it could exist if utlemming left it int he cloud tarballs,
[17:05] <cjwatson> It's only asked if:
[17:05] <hallyn> huh
[17:05] <cjwatson>  1) grub-pc is being installed from scratch
[17:05] <stokachu> ogra_: if i attach the debdiff http://paste.ubuntu.com/1260320/ do you want that in two separate patches and a bug for the control.in or will you accept both changes
[17:05] <cjwatson>  2) There's already a core.img
[17:05] <cjwatson>  3) We're upgrading from GRUB Legacy
[17:05] <cjwatson>  4) The postinst thinks it's running inside Wubi
[17:06] <cjwatson> None of which AIUI should hold here
[17:06] <cjwatson> (There are other conditions as well, but that's the disjunction at the top)
[17:06] <cjwatson> Any way to get set -x output from grub-pc.postinst?
[17:07] <ogra_> hrw, if you say fetched above, how did you fetch ? apt-get source (as i do here) ?
[17:09] <hallyn> cjwatson: perhaps grub-pc isn't installed yet  (checking)
[17:09] <cjwatson> hallyn: That would raise the question of why something thinks it's a good idea to install it, then :-)
[17:09] <hallyn> hm, no, it is installed
[17:09] <ogra_> stokachu, fine as is i think
[17:09] <stokachu> ogra_: ok i attached an updated debdiff
[17:09] <hallyn> oh, there it is.  /boot/grub/i386-pc/core.img.
[17:10] <hallyn> oh i get it - apt-get update had deleted that perhaps.  it's there ina  newly created container
[17:10] <ogra_> stokachu, yep, looking at it already
[17:10] <stokachu> this allows me to run bzr bd -- -S -us -uc a
[17:10] <stokachu> this was the way i was told to do it so if there is another way im all ears
[17:11] <hallyn> cjwatson: so i've lost your train of thought :)  if core.img does exist, you think our best option is what at that point?  not run grub-install?
[17:12] <cjwatson> hallyn: My suggestion was that we do something similar here to what you were proposing for update-grub; that is, bypass the entire code path that deals with figuring out where to install GRUB and then running grub-install in the event that we're running in a container
[17:13] <cjwatson> (But I have to go for dinner nowish)
[17:13] <hallyn> cjwatson: ok, would you prefer to chat later, or to have me push an attempt to my grub branch?
[17:15] <cjwatson> hallyn: I was going to suggest something like http://paste.ubuntu.com/1260370/
[17:15] <cjwatson> Maybe try that out by local editing or something to see if I'm vaguely close :)
[17:15] <cjwatson> But will need to talk later anyway
[17:16] <hallyn> cjwatson: ok thx, ttyl
[17:18] <hrw> ogra_: apt-get source gdb
[17:19] <stokachu> you know what would be awsome, if there were quake sounds embedded into the LP comments if a package was accepted or rejected
[17:19] <ogra_> hrw, good then
[17:19] <hrw> ogra_: you use other way?
[17:20] <ogra_> hrw, nope, same
[17:23] <ogra_> EEK
[17:23]  * ogra_ better re-rolls the gdb fix without -sa attached to dpkg-buildpackage 
[17:23] <ogra_> :P
[17:39] <barry> doko: looks like the retry worked.  thanks
[17:47] <zyga> pitti: hi
[17:47] <zyga> pitti: quick question, python3-pyudev, can we ship it on the cd?
[17:47] <zyga> pitti: it's whooping 30KB in size
[17:49] <sarnold> zyga: I believe he went to bed an hour ago..
[17:49] <zyga> sarnold: never hurts to ask :), I'll grab him tomorrow
[17:49] <sarnold> zyga: indeed :)
[17:49] <zyga> which timezone is he in BTW? I thought he was in Europe
[17:50] <sarnold> I've assumed Germany's TZ, +1 ...
[17:53] <roaksoax> cjwatson: howdy!! in debian/maintscript -> is the version listed there, such as "rm_conffile /etc/init/maas-celery.upstart 0.1+bzr1170+dfsg-0ubuntu1" is the last version of the package that contained that file
[17:53] <ogra_> @pilot out
[17:54] <ogra_> (oops, had totally forgotten)
[18:11] <hallyn> cjwatson: http://paste.ubuntu.com/1260370/ seems to be working (if i'm testing this right)
[18:11] <hallyn> ttyl
[18:29] <cjwatson> roaksoax: 'man dpkg-maintscript-helper' has an exact specification
[18:30] <roaksoax> cjwatson: got it alreayd, thanks though :)
[18:31] <cjwatson> hallyn: OK - if I don't hear further from you I'll upload that tomorrow morning, then
[18:39] <hallyn> cjwatson: thanks!  I'll upload the new lxc to do the devtmpfs mount in the meantime
[18:40] <hallyn> stgraber: are you around?
[18:58] <infinity> kirkland: *nudge*
[18:58] <infinity> kirkland: That sks upload to precise-proposed was an oops, I assume?
[18:59] <infinity> kirkland: Since what you were fixing was something in precise-backports, which could just be done with a new backport.
[19:03] <radix> jml: so, the conditional in undistract-me's profile.d script seems to be causing it to exit for me
[19:23] <kirkland> infinity: hmm, well, I do want to fix this in precise-proposed;  looks like I grabbed the wrong base package to work from (from backports, rather than from updates)
[19:23] <infinity> kirkland: Okay, if it needs fixing in updates as well, please do, but with the right base. ;)
[19:24] <kirkland> infinity: yep, good catch
[19:24] <kirkland> infinity: okay, just re-uploaded with the right base
[19:47] <bryceh> kirkland, heya
[19:55] <infinity> kirkland: Thanks, accepted.
[21:25] <darkxst> how can I enable debug logging for indicator session?
[21:26] <mterry> @pilot out
[22:06] <trism> darkxst: indicator-applet in a gnome-panel session logs the indicator debug messages to ~/.cache/indicator-applet-complete.log (don't know how to get that output in unity, though if anyone does I'd be interested)
[22:14] <darkxst> trism, thanks