[02:49] <robert_ancell> mbiebl_, You seem to be the last to touch realmd - can you apply so we can keep in sync? http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=800928
[04:36] <pitti> roaksoax: yes, don't use trusty's autopkgtest -- use wily's package, the deb can be installed on anything >= precise
[04:36] <pitti> roaksoax: in production I just run it straight out of git
[04:38] <pitti> smoser: I was on the snappy sprint last week, there's now a huge backlog to look into (which includes this bug)
[04:42] <FourDollars> Ubuntu doesn't have the mmc udeb like https://packages.debian.org/unstable/mmc-modules-4.2.0-1-amd64-di in Debian so it causes problems when we use debian-installer on some platforms with eMMC storage only. :-(
[04:43] <pitti> sarnold: restarting; the machine has an incredible load right now, it apparently crashed on some timeout
[04:54] <roaksoax> pitti: ok, cool, thanks!
[06:49] <dholbach> good morning
[06:49] <dholbach> @pilot in
[07:15]  * smb notes the trusty-proposed repo seems to miss a signed grub2 upload 
[08:31] <flexiondotorg> dholbach, Thanks for the sponsoring!
[08:50] <doko> pitti, did you override the libxml-libxml-perl autopkg test failure? and the xslt one?
[08:52] <dholbach> flexiondotorg, no worries
[08:53] <pitti> doko: no, I fixed the reason why they fail
[08:53] <pitti> doko: and re-ran them
[08:53] <doko> ohh, nice
[08:53] <pitti> doko: same for some of the ruby failures (the ones which only failed on i386 and amd64)
[08:54] <pitti> doko: we had "git" installed on the VM testbeds, which enabled the additional "check gem deps" test; these aren't run in LXC (armhf/ppc64el) and Debian as there "git" isn't installed
[08:54] <pitti> and it's not a test dep
[08:54] <doko> pitti, setup of the test env?
[08:54] <pitti> doko: so IMHO we should ignore those for now, as we don't have anyone in Ubuntu actively working on these tests
[08:54] <doko> argh
[08:54] <pitti> doko: yep -- the cloud images contain more and more stuff, so my "purge" list becomes longer over time :)
[08:55] <doko> pitti, so there is no minimal cloud-image?
[08:55] <pitti> doko: nodejs is a block-proposed, infinity wanted to do some additional manual testing
[08:55] <pitti> doko: ruby is a mess, the other excuses look fairly reasonable now
[08:55] <pitti> doko: no, I use the standard cloud images and minimize the stuff which we don't need
[09:14] <doko> mvo, would it be ok to merge apt again? or else I have downgrade the b-d in libept
[09:16] <mvo> doko: I think thats ok, I can do that later today
[09:16] <doko> ta
[09:19] <hrw> hi
[09:19] <hrw> will 15.10 have support for 32bit uefi in x86-64 install iso?
[09:23] <davmor2> hrw: not sure I follow that. UEFI as far as I am aware is not bit dependant, so amd64 is the only one that supports UEFI and secureboot
[09:23] <FourDollars> https://bugs.launchpad.net/ubuntu/+source/debian-installer/+bug/1341944
[09:23] <hrw> davmor2: http://i.imgur.com/fRdyE2A.jpg
[09:24] <FourDollars> hrw: Check https://bugs.launchpad.net/ubuntu/+source/debian-installer/+bug/1341944
[09:24] <hrw> FourDollars: reading. thanks
[09:25] <FourDollars> hrw: YW
[09:30] <hrw> FourDollars: full of "me too" without any "we work on it"
[09:30] <FourDollars> hrw: You are right.
[09:33] <dholbach> chrisccoulson, Laney, seb128, Mirv: you all commented on https://bugs.launchpad.net/ubuntu/+source/ninja-build/+bug/1473680 - do you have any objections to a newer version of ninja-build going in?
[09:33] <seb128> dholbach, none from me
[09:35] <hrw> FourDollars: not suprised I am
[09:35] <FourDollars> hrw: Me neither.
[09:43] <Mirv> dholbach: no objections
[09:45] <hrw> bye
[09:52] <Laney> dholbach: do it if you are happy
[09:53] <chrisccoulson> dholbach, none from me
[10:25] <bzoltan_> cjwatson: how do you like the changes in my MR? https://code.launchpad.net/~bzoltan/click/add_overlay_ppa/+merge/272428
[10:27] <bzoltan_> zbenjamin: happy-happy-joy-joy -> https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/stable-phone-overlay/+sourcepub/5477761/+listing-archive-extra
[10:28] <bzoltan_> zbenjamin:  now the standalone qmake extras package is available from the overlay ppa, so once the new click ^^ is out we can push the  single packaged IDE out.
[10:31] <zbenjamin> bzoltan_: and did you fix the src package of qtcreator-plugin-ubuntu?
[10:32] <bzoltan_> zbenjamin: not yet... that will come after click
[10:47] <cjwatson> bzoltan_: surely you don't need to duplicate the whole script!
[10:48] <cjwatson> bzoltan_: there's plenty of commonality, you only need the if for the bit in the middle.  good programming practice involves not duplicating things like this
[10:49] <cjwatson> bzoltan_: I mentioned this in my previous review, when I said that you could split into multiple finish.write calls
[10:52] <bzoltan_> cjwatson: imo it is not that big deal...but I do as you wish
[10:52] <cjwatson> bzoltan_: it is a big deal
[10:53] <cjwatson> bzoltan_: otherwise a year from now it'll be "why were fixes applied in one branch but not the other?"
[10:53] <dholbach> @pilot out
[10:53] <bzoltan_> cjwatson: I am not challengig you :)
[10:55] <cjwatson> mvo: ^- fwiw, I'm going to need somebody who isn't me to land this new click version once bzoltan_ has it fixed up ...
[11:08]  * pitti hugs dholbach
[11:20] <bzoltan_> cjwatson: done... took some time to test it, but i hope now it is what you though of
[11:21] <mvo> cjwatson: sure, I can land it
[11:23]  * dholbach hugs pitti back :)
[11:23] <mvo> bzoltan_: just ping me when this is ready
[11:23] <bzoltan_> mvo:  it is ready from my side ... it is up to cjwatson to approve it :)
[11:25] <mvo> bzoltan_: I thought I read that there is some duplication that needs cleanup first? but maybe I misread?
[11:26] <bzoltan_> mvo:  my middle name is "Lightning" :) for a reason
[11:28] <mvo> lol
[11:32] <cjwatson> Let's see.
[11:35] <bzoltan_> cjwatson: thank you
[11:35] <cjwatson> Thanks for persevering; merged.
[11:36] <cjwatson> (into lp:click/devel)
[11:55] <caribou> pitti: have time to sponsor my upload for Bug #1470399 ?
[12:19] <doko> cyphermox, cjwatson: grub is dep-wait on automake1.9 (removed).  I assume just backporting 0.97-68 would be the correct solution?
[12:20] <doko> or would it need more build fixes?
[12:24] <infinity> Oh wow, grub is in desperate need of a merge.
[12:26] <pitti> caribou: will do
[12:26] <caribou> pitti: thanks!
[12:27] <cjwatson> infinity: Historically painful because it included the auto-upgrade saga
[12:28] <cjwatson> doko: Let me see if I can cherry-pick a few things.
[12:28] <infinity> cjwatson: Yeah, I've not looked at why it's so far behind, just saw that it was, plus has 66 ubuntu revisions.   That's a contender for the d-i oops award.
[12:41] <caribou> infinity: you had some concerns over Bug: #1432871
[12:42] <infinity> caribou: Just concerns about it being sanely fixed in an upstreamable way.  The theory is that the current proposed patch is from upstream?  I haven't looked yet.
[12:43] <caribou> infinity: yes, AFAIK, chiluk got the patches accepted upstream
[12:43] <caribou> infinity: there's a new debdiff in the ubg
[12:43] <caribou> s/ugb/bug/
[12:47] <smoser> pitti, sorry that i sounded like a nag. thanks for getting back to me.
[12:48] <pitti> smoser: no worries, nagging is fine; just saying that it still takes a bit
[12:49] <pitti> smoser: is the network up in teh cases where /run/resolvconf/resolv.conf doesn't have the nameserver?
[12:49] <smoser> yeah, network is up, as otherwise there'd be no root filesystem (iscsi)
[12:49] <pitti> smoser: collecting/attaching the journal from a "good" vs. "bad" case is also a good first step (I assume you already have the iscsi setup)
[12:50] <smoser> well, the linked bug has example on how to run it from scratch on a new install .
[12:50] <smoser> ie, easy enough to recreate.
[12:50] <smoser> i actually haven't ever *caught* it working
[12:51] <pitti> smoser: ah, so I suppose open-iscsi's startup scripts need to call resolvconf then, as nothing else is calling it then?
[12:51] <smoser> well, i've had evidence of it workign hough. which i admit is weird.
[12:51] <pitti> smoser: i. e. they trick ifupdown to think that it already brought up ethN, so /etc/network/if-up.d/000resolvconf would never run
[12:52] <pitti> (unless you have other interfaces)
[12:52] <smoser> ie, once a 'wget http://dns.entry/' didn't work, and i went in to see why. and other time it did.
[12:53] <smoser> i'll poke a bit at it.
[12:57] <cjwatson> doko: uploaded grub 0.97-29ubuntu67, should be happier
[13:06] <smoser> pitti, how do i collect what you want ?
[13:07] <smoser> collecting/attaching "the journal"
[13:08] <pitti> smoser: just "sudo journalctl > /tmp/journal.txt", or mostly equivalently, attach /var/log/syslog
[13:08] <pitti> (this has previous boots in it etc., but simple enough)
[13:08] <smoser> i'll attach to bug
[13:08] <smoser>  http://paste.ubuntu.com/12689381/
[13:09] <pitti> smoser: but resolvconf doesn't actually print anything when it runs; so debugging with making it print something would indeed be more useful
[13:09] <smoser> that is pass (/etc/resolv.conf populated)
[13:09] <smoser> k
[13:11] <pitti> smoser: i. e. add as set -x to /sbin/resolvconf to see what it's doing and when it runs during boot?
[13:12] <smoser> ok.
[13:12] <seb128> doko, can you retry the telepathy-gabble builds on the test builds? should be fixed with the libnice update
[13:49] <seb128> doko, can you retry the url-dispatcher build on armd64 as well?
[14:02] <smoser> pitti, ok. attached journalctl of pass and fail
[14:06] <doko> seb128, done
[14:06] <seb128> doko, thanks
[14:34] <smoser> pitti, i think i've diagnosed problem. i'm not sure how you want to solve it.
[14:34] <smoser> see comment in bug
[14:35] <smoser> is there a way to get output of udev-event fired commands ?
[14:35] <smoser> ie, resolvconf there did write 'report_error' to its stderr, but that  never made it to journalctl
[14:49] <cjwatson> Odd_Bloke: do you know if anyone has got anywhere with https://rt.admin.canonical.com/Ticket/Display.html?id=84711 ?
[14:51] <Odd_Bloke> cjwatson: I don't think we've got anywhere with it; let me take some time to look at what they're actually asking for.
[14:51] <cjwatson> basically a manifest-upgrade mojo spec
[14:52] <cjwatson> in whatever runs those environments
[15:05] <kruger> hi, someone can help me to rebuild a uefi cdrom? i've got an error which say: "(initramfs) Unable to find a medium containing a live file system" Any hints?
[19:47] <bdmurray> How can I sort out / look into the Launchpad automatic translations being out of date for ubuntu-release-upgrader?
[20:21] <bdmurray> cyphermox, slangasek: How can I sort out / look into the Launchpad automatic translations being out of date for ubuntu-release-upgrader?
[20:31] <slangasek> bdmurray: no clue, I'm afraid
[20:31] <slangasek> possibly a pitti question
[20:44] <kruger> hi, someone can help me to rebuild a uefi cdrom? i've got an error which say: "(initramfs) Unable to find a medium containing a live file system" Any hints?
[20:44] <cyphermox> kruger: that has nothing to do with uefi, fortunately :)
[20:44] <cyphermox> kruger: did you indeed get a grub menu rather than a graphical splash when booting your CD?
[20:46] <cyphermox> bdmurray: I don't know either, last upload was my first time ever touching ubuntu-release-upgrader :)
[20:46] <kruger> cyphermox, no i've got a splash image because i've themed grub2
[20:48] <cyphermox> kruger: fair enough, just making sure you don't expect it's booting uefi when it's not -- as long as it's indeed grub2, then you are in UEFI
[20:49] <cyphermox> as for the live filesystem, that's a matter of the squashfs file that is typically in casper/
[20:50] <cyphermox> if it's not the same filename, or not present, you'd need to pass an extra parameter in your preseed file, or on the command-line when starting the kernel
[20:50] <bdmurray> cyphermox: Its about "Launchpad automatic translations update" not really being up to date so isn't ubuntu-release-upgrader specific.
[20:51] <kruger> cyphermox: when i boot in standard bios mode all boot fine, but not when i choose uefi boot
[20:51] <cyphermox> kruger: I suppose it's the command-line for grub then
[20:54] <cyphermox> kruger: try passing 'live-media-path=' with the path to where your squashfs file is, on the kernel command-line
[20:55] <kruger> cyphermox: in grub.cfg i've got this: http://pastebin.com/xk1G6rXx
[20:56] <kruger> cyphermox: ok i try
[21:14] <kruger> cyphermox: nothing to do
[21:15] <tjaalton> hallyn: why is libvirt-bin stopped on package upgrade? seems to kill all running instances too
[21:20] <tjaalton> either that or bug 1342083
[21:22] <infinity> tjaalton: Why/how is your /dev/pts mounted incorrectly?
[21:22] <hallyn> tjaalton: stopping libvirt-bin should absolutely not stop your instances
[21:22] <infinity> tjaalton: (pt_chown is only called by glibc when creating ptys if /dev/pts isn't mounted with correct permissions)
[21:23] <tjaalton> devpts on /dev/pts type devpts (rw,nosuid,noexec,relatime,mode=600,ptmxmode=000)
[21:24] <infinity> devpts on /dev/pts type devpts (rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000)
[21:24] <infinity> Note the gid and mode.
[21:24] <tjaalton> where does it come from?
[21:24] <infinity> tjaalton: That points at you likely having mounted a /dev/pts in a chroot by hand at some point, or a script having done so incorrectly.
[21:24] <infinity> (Sadly, /dev/pts is, by default, a shared instance mount, so mounting a fresh one with incorrect options breaks your root mount too)
[21:24] <tjaalton> hum, sbuild
[21:25] <cyphermox> kruger: it would go better if you could print me a list of the contents of your image, but essentially that's the idea; you set live-media= or live-media-path=, depending on how it's set up. you may want to look at the source for the casper package.
[21:25] <infinity> sbuild does it right.
[21:25] <tjaalton> I don't do other that schroot/sbuild
[21:25] <infinity> Well, I sbuild/schroot all day, and don't have any issues, unless your schroot has a local fstab modification.
[21:26] <infinity> (by default, it's a bindmount, and thus DTRT)
[21:26] <tjaalton> /etc/schroot/default/fstab:/dev/pts        /dev/pts        none    rw,bind         0       0
[21:27] <infinity> Right, that works fine and wouldn't alter your boot-time mount options.
[21:27] <infinity> But if you're positive that you didn't ever manually mount a /dev/pts (maybe a quick by-hand abuse of an unpacked chroot tarball or something?), we really should hunt down what broke it.
[21:28] <tjaalton> uptime is only a month, running wily
[21:28] <infinity> Cause I intend to drop pt_chown from glibc soon (it's a glaring security hole waiting to be exploited), and if people are breaking /dev/pts still, they get no more ptys after I do that.
[21:28] <tjaalton> since.. a month or so
[21:28] <tjaalton> hallyn: ok so you're off the hook then, I guess :)
[21:29] <infinity> Well, he's not off the hook, really.
[21:29] <infinity> Cause his apparmor profile should have allowed you to run pt_chown, and it didn't.
[21:29] <infinity> So, a bit of WTF there too.
[21:29] <tjaalton> well ok
[21:29] <tjaalton> still, I'll reboot and see what I have
[21:29] <infinity> Still, you wouldn't see the bug if your /dev/pts was sane.
[21:29]  * infinity nods.
[21:29] <tjaalton> yeah
[21:30] <infinity> Do you use virt-install?
[21:30] <infinity> I wonder if it does something dumb.
[21:30] <tjaalton> sometimes
[21:30] <infinity> Cause it basically debootstraps in a chroot, then converts it to a qemu image, right?
[21:30] <infinity> Or something along those lines?
[21:31] <infinity> So, it might be mounting /dev/pts in the chroot with incorrect options.
[21:31] <tjaalton> what about piuparts?
[21:34] <infinity> Also possible.
[21:34] <infinity> I had planned to hack util-linux to force sane default mount options for devpts filesystems if none were specified, not sure how that dropped off my TODO. :/
[21:35] <tjaalton> I'll check after a reboot
[21:40] <tjaalton> sane pts, kvm instances start fine
[21:40] <tjaalton> now piuparts..
[21:42] <tjaalton> boom
[21:45] <infinity> Laney: Hey, desktop guy.  What broke my desktop today? (fonts are wrong, and LIM aren't LI)
[21:46] <tjaalton> hm, where did firefox & libreoffice launchers go from my left panel
[21:46] <infinity> tjaalton: Yeah, confirmed the bug in the piuparts source.  Whee.
[21:47] <tjaalton> cool
[21:47] <sarnold> pitti: thanks for tracking down the recalcitrant retracers; 1502431 is now several days withuot tracing
[21:48] <tjaalton> infinity: no way to fix the mount without rebooting?
[21:49] <infinity> Laney: And firefox is unthemed...
[21:49] <infinity> tjaalton: You can remount it with the correct options.  Or use piuparts after I feed you a patch. ;)
[21:49] <tjaalton> heh, ok
[21:54] <infinity> tjaalton: http://paste.ubuntu.com/12692496/
[21:54] <infinity> tjaalton: Can you apply that 1-liner to /usr/sbin/piuparts and show me "mount | grep devpts" after a run?
[21:54] <tjaalton> ok
[21:58] <tjaalton> infinity: devpts on /dev/pts type devpts (rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000)
[21:58] <tjaalton> all good
[21:58] <infinity> tjaalton: Ta.
[21:58] <tjaalton> should it not bind-mount it instead?
[21:59] <infinity> tjaalton: It probably should bind-mount most of its mounts, but I was going for minimally-invasive, not knowing the code or what it does.
[21:59] <tjaalton> right, ok
[22:13] <infinity> tjaalton: piuparts uploaded.  Thanks for the public whine and debugging. ;)
[22:14] <infinity> tjaalton: I don't suppose you have any insight as to why my GTK theme's gone sideways after an upgrade/reboot?