=== freeflying_away is now known as freeflying
=== jono is now known as Guest35005
=== bryceh is now known as bryce
[05:49] <pitti> Good morning
=== timrc is now known as timrc-afk
[07:22] <pitti> stgraber: still awake by any chance?
[07:38] <dholbach> good morning
=== freeflying is now known as freeflying_away
[09:11] <mlankhorst> xnox: that unity upgrade bug is weird.. what happens when you apt-get install libxi6?
[09:21] <xnox> mlankhorst: it's all fine actually. and upgrade / install ubuntu-desktop works in a precise chroot.
[09:22] <xnox> mlankhorst: the user however, doesn't have default priorities - apt-cache policy shows -security pocket at 990, and -updates pocket at 900. By default all should be 900. Thus libxi from "-security" pocket is enforced, breaking the upgrade.
[09:22] <xnox> mlankhorst: none of the other packages have things in -security for that upgrade =/
[09:23] <xnox> mlankhorst: i did panic a bit with bug statuses, but now it's all set to incomplete/invalid states.
[09:44] <mlankhorst> ah
[09:44] <mlankhorst> xnox: yeah I did test the default case, had a feeling it was something like that ;-)
[09:46] <xnox> mlankhorst: yeah, it did look suspicious that the bug reporter, knew, and included, apt-cache policy. And it did turn out to look fishy =)
=== doko_ is now known as doko
=== tkamppeter_ is now known as tkamppeter
[10:33] <Laney> directhex: what issue is that?
[10:33] <Laney> oh
[10:33] <Laney> I misunderstood the use of 'main' ;-)
[10:38] <Laney> Can we have gtk-sharp3 promoted please? It's the gtk3 version of gtk-sharp2 which is already in main so I hope we can avoid the MIR.
[10:38] <Laney> per http://people.canonical.com/~ubuntu-archive/component-mismatches-proposed.txt
[10:45] <seb128> Laney, let me have a look
[10:47] <seb128> why is gnome-panel&co wanting to go to main?
[10:48] <seb128> oh, indicator-datetime recommends indicator-applet
[10:50] <seb128> hum, what about lightdm recommending lightdm-gtk-greeter?
[10:50] <seb128> Recommends: xserver-xorg, unity-greeter | lightdm-greeter | lightdm-kde-greeter
[10:50]  * seb128 wonders what's happening there
[10:56] <Laney> seems to be expanding the provides strangely
=== _salem is now known as salem_
[11:40] <doko> mlankhorst, about 1266492, did you see this in a specific package?
[11:40] <mlankhorst> bug 1266492
[11:40] <ubottu> bug 1266492 in binutils (Ubuntu) "ld:i386 crashes with -static -fPIE -pie" [High,Confirmed] https://launchpad.net/bugs/1266492
[11:41] <mlankhorst> doko: xorg-server
[11:41] <mlankhorst> and the duplicate was a ftbfs for another bug
[11:41] <doko> mlankhorst, why doesn't these b-d on hardening-wrapper?
[12:03] <doko> mlankhorst, ^^^
[12:06] <doko> mlankhorst, looks like xorg-server has some hardening settings, but these are useless because of the missing b-d
[12:16] <mlankhorst> no idea, it's same as debian
[12:59] <Laney> directhex: looks like it got promoted
[12:59] <Laney> thanks seb128 (assuming it was you)
[12:59] <seb128> Laney, it was, yw
[13:00] <directhex> so banshee should build, and we can work on the rest of that little tangle
[13:01] <directhex> Finished 3 minutes ago (took 5 minutes, 32.4 seconds)
[13:09] <mdeslaur> @pilot in
=== udevbot changed the topic of #ubuntu-devel to: Trusty Tahr Alpha 1 released! | Archive: open | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of lucid -> saucy | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: mdeslaur
=== Sweetsha1k is now known as Sweetshark
[13:23] <xnox> seb128: is that's all because of ppc64el/arm64 build-scew. As in on amd64, gnome-palen doesn't want to go in =)
[13:23] <xnox> s/gnome-palen/gnome-panel/
[13:24] <seb128> xnox, oh, ok, I didn't even think that could be arch specific ... thanks ;-)
[13:24] <xnox> seb128: yeah, components-mismatches doesn't tell you that. E.g. I think if unity-greeter would build on ppc64el, it would be all fine.
[13:25] <seb128> xnox, I see, makes sense now that you say it ;-)
[13:25] <xnox> seb128: https://bugs.launchpad.net/ubuntu/+source/unity-greeter/+bug/1263436
[13:25] <ubottu> Ubuntu bug 1263436 in unity-greeter (Ubuntu) "unity-greeter fails to build from source on all arches" [High,New]
=== timrc-afk is now known as timrc
=== freeflying_away is now known as freeflying
=== jamesh__ is now known as jamesh
[14:30] <stgraber> pitti: nope, but I am now
[14:30] <pitti> stgraber: bonjour
[14:31] <pitti> stgraber: apport with your container changes is in; I also fixed the init.d/upstart script for containers, but I'd appreciate a review of the changes from you
[14:31] <pitti> stgraber: I left some questions/comments in the MP, and filed bug 1267728 for SRUing
[14:31] <ubottu> bug 1267728 in apport (Ubuntu Precise) "starts/stops in containers" [Medium,In progress] https://launchpad.net/bugs/1267728
[14:33] <stgraber> pitti: I believe that bug is invalid
[14:33] <stgraber> pitti: I noticed that behaviour when testing but it's only happening because our current 3.13 kernel is buggy
[14:34] <pitti> stgraber: oh, you mean containers aren't supposed to be able to change core_pattern?
[14:34] <stgraber> pitti: once the kernel team fixes our 3.13 kernel to actually apply the apparmor profile as it should, the container won't be able to write core_pattern anymore
[14:34] <pitti> stgraber: ah, that would do it as well
[14:34] <pitti> stgraber: oh, it's only apparmor which prevents that, not the kernel itself?
[14:35] <pitti> stgraber: then I believe the upstream init.d check should stay
[14:35] <pitti> and we might just revert it from our upstart job
[14:35] <pitti> but if we don't need to SRU this, so much the better
[14:36] <pitti> jamespage: ah, openvswitch autopkgtest failure is because our version doesn't support kernel 3.13
[14:36] <stgraber> pitti: I guess it probably doesn't hurt having the check in the upstart job anyway (in case someone runs their container with lxc.aa_profile = unconfined)
[14:36] <stgraber> pitti: though on Ubuntu, you really want to use running-in-container rather than a direct check of pid 1's environment
[14:36] <pitti> stgraber: ah, ok
[14:36] <pitti> stgraber: right, I thought of that after I hit dput..
[14:37]  * pitti commits that change to avoid forgetting it
[14:37] <jamespage> pitti, indeed
[14:38] <jamespage> apw and I already discussed - I've reported that upstream; I've got inflight patches being reviewed upstream for 3.12; once those have landed, can look at 3.13 :-)
[14:38] <jamespage> for now we can drop the dkms package; they don't add much with 3.13
[14:38] <pitti> stgraber: (done)
[14:39] <apw> stgraber, a new 3.13.0-2 is building in the CKT ppa which should have the reguiste AA bits
[14:39] <pitti> jamespage: ah, we ship the driver in our kernel now?
[14:39] <jamespage> pitti, feature parity between the in-tree ovs module and the dkms module is almost 100% now
[14:39] <jamespage> the in-tree lack LISP tunnelling support (but that's pretty experimental)
[14:40] <stgraber> apw: cool, thanks!
[14:40] <apw> stgraber, if you are able to test all the better
[14:40] <stgraber> pitti: thanks for reviewing/merging that change, it took around a year longer than I anticipated to land this but it's great to finally have it :) (my kernel patch took quite a while to get merged upstream...)
[14:41] <stgraber> apw: sure, I'll grab it from the PPA and do a quick test here
[14:41] <apw> the signed bits are still pending publication
[14:41] <apw> oh notg that they are any use :)  being signed with the wrong key
[14:42] <stgraber> right, if they were signed they wouldn't boot here, thankfully our grub is still happy to boot unsigned kernels
[14:42] <pitti> oh, is it?
[14:42] <pitti> that means, if I alter the kernel image and grub would refuse it, the only thing I'd need to do is to remove the .signature file?
[14:43] <pitti> err, .signed
[14:43] <stgraber> yeah, grub will let you boot unsigned kernels on EFI but in that case will call ExitBootServices() before entering the kernel
[14:43] <stgraber> however if a kernel is signed with an invalid key, it won't boot
[14:43] <pitti> ah, I was hoping that once I turn that on, no unsigned/wrongly signed kernel would ever boot any more
[14:44] <cjwatson> I'll probably stop allowing unsigned kernels once all the MOK stuff is properly integrated
[14:44] <stgraber> it's not a standalone signature file, it's inline, but yes, you can use sbattach to remove the signature
[14:44] <cjwatson> so that it's easy for users to authorise their own kernels
[14:44] <pitti> it's inline? what is /boot/vmlinuz-3.13.0-1-generic.efi.signed then, just an informational copy?
[14:44] <cjwatson> pitti: the unsigned kernel won't be allowed *to execute code in boot-services context* - important distinction
[14:44] <pitti> oh, I see, it's big enough to *be* a kernel
[14:45] <pitti> I thought it was just a tiny file a few months ago, apparently I mislooked
[14:45] <pitti> thanks for the heads-up
[14:45] <stgraber> and yeah, MOK + disallowing unsigned binaries is the right way forward, once we have all the tools needed to easily generate a new signing key and having it added in the nvram variable
[14:49] <apw> pitti, the signature is carried as a tiny file in the binary package and added to a copy of the kernel on installatin
[14:49] <stgraber> apw: based on my 30s test, your new kernel looks good
[14:49] <stgraber> apw: boots fine, apparmor reload no longer complains and I can't trivially destroy my host from a container
[14:49] <pitti> apw: ah, thanks; so back then I was probalby looking at /usr/lib/linux/vmlinuz-3.13.0-1-generic.efi.signature
[14:49] <apw> stgraber, great, i'll get the security tests run on it,then let it out
[14:50] <pitti> stgraber, apw: cheers, closing the precise task in bug 1267728 then
[14:50] <ubottu> bug 1267728 in apport (Ubuntu Precise) "starts/stops in containers" [Medium,In progress] https://launchpad.net/bugs/1267728
[14:50] <pitti> and I made such a nice SRU test case/info..
[14:50] <pitti> but it's pretty much the same test case for verifying that kernel :)
[14:51] <stgraber> pitti: ah yeah, I also checked core_pattern
[14:51] <stgraber> root@p1:~# echo 1 > /proc/sys/kernel/core_pattern
[14:51] <stgraber> -bash: /proc/sys/kernel/core_pattern: Permission denied
[14:51] <pitti> nice
[14:51] <stgraber> (my original test was writing to the uevent handler which if not blocked lets you run code as root on the host)
[14:52] <pitti> stgraber: I didn't think of that at first, that gave me a big "WTF??" this mornign when testing your branch :)
[14:52] <pitti> (because apport didn't behave as I expected it to, as the container startup ate the new %P)
[14:53] <stgraber> haha, yeah, I had the same happen to me a couple of times when working on the branch :) I guess I should have mentioned it in the MP
[15:01] <directhex> can the ubuntu archive manglers delete a package from trusty to help a transition, whilst keeping the source package in place, such that the source package can be fixed at a later date? like deletion from testing in debian?
[15:03] <kentb> how long does it normally take for a package to move out of the Trusty upload queue?  Namely, I'm waiting for sblim-sfc-common.
[15:04] <cjwatson> directhex: there are a few different tactics for that.  the nearest analogue is demoting it to trusty-proposed
[15:04] <cjwatson> kentb: new packages need manual review, expected time would be days
[15:04] <cjwatson> (I can't promise to look today, sorry)
[15:04] <kentb> cjwatson: ok. np.
[15:05] <directhex> cjwatson, basically i don't expect to fix monodevelop-monogame for a month or two (due to upstream release schedule), and it's apparently a blocker on mono transition
[15:10] <cjwatson> directhex: I can only do this at a source package level.  Can you confirm that it's OK to demote all of monogame?  If so could you give me a brief log message I can use for the demotion?
[15:10] <cjwatson> directhex: also, if you could please file a bug against monogame in Ubuntu with the "block-proposed" tag, that'll stop it immediately going back in after I demote it
[15:16] <directhex> cjwatson, demoting the whole source package is fine. can i file a bug against cjohnston for overloading my cj<tab> irc usage?
[15:16] <cjohnston> 1, 2, 3<tab>
[15:16] <Laney> YEAH
[15:18] <directhex> ok, bug 1267892 filed
[15:18] <ubottu> bug 1267892 in monogame (Ubuntu) "Does not build against MonoDevelop 4" [Undecided,New] https://launchpad.net/bugs/1267892
[15:18] <cjwatson> directhex: if I could, I would
[15:19] <cjwatson> directhex: ok, demoted
[15:19] <cjwatson> (https://launchpad.net/ubuntu/+source/monogame/+publishinghistory)
=== oSoMoN_ is now known as oSoMoN
[16:08] <mdeslaur> @pilot out
=== udevbot changed the topic of #ubuntu-devel to: Trusty Tahr Alpha 1 released! | Archive: open | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of lucid -> saucy | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots:
=== Ursinha is now known as Ursinha-afk
=== Ursinha-afk is now known as Ursinha
=== thegodfather is now known as fabbione
[17:53] <mdeslaur> mpt: think we could reconsider not having a close button in the window title on this dialog: http://i.imgur.com/qlScVX7.png
[17:53] <mdeslaur> mpt: seems to be a common complaint from users
[17:55] <mpt> mdeslaur, that would be temporary, because Mir+Unity8 will never have close buttons on dialogs. However, that particular dialog is missing a “Restart Later” button (bug 1033226).
[17:55] <ubottu> bug 1033226 in update-manager (Ubuntu) "No close option, only restart" [Medium,Triaged] https://launchpad.net/bugs/1033226
[17:58] <mdeslaur> mpt: ah! cool...I'll read through that and will poke at this this weekend. Thanks!
[19:09] <jdrab> mdeslaur: btw you can close that "restart to finnish" window from software updater
[19:09] <mdeslaur> from software updater6
[19:09] <mdeslaur> ?
[19:10] <jdrab> yes
[19:10] <jdrab> :D
[19:10] <jdrab> i don't know how it's called that compis effect but if you "display all windows"
[19:10] <jdrab> there is that little ugly close button there
[19:10] <jdrab> on that window
[19:10] <mdeslaur> well, you can also simply right click the launcher too
[19:11] <jdrab> 2 clicks. vs one :P
[19:14] <mdeslaur> ok, unassigning myself, too much work to implement
[20:02] <wadechandler> Has anyone here ever done any dev work with unity (assuming at some point certainly that answer is yes)? i.e. ever took your reg dev box, built it, replace your running version with the one you are deving, then reverted back when done? I just want to provide a patch which I think should be fairly simple to sort out on multiple displays, but have yet to work on it nor much anything else in Ubuntu land. I'm wondering if th
[20:02] <sarnold> wadechandler: you were cut off at "wondering if th"
[20:04] <dobey> wadechandler: btw, #ubuntu-unity is a channel specific to unity development
[20:05] <wadechandler> I'm wondering if there are any tutorials on the topic: 1) I can get the source (easy enough) 2) how to take a built set of outputs and install them, and then 3) how to revert all that back. I know I can use a VM and do that, but seems like over kill for a few things; yes I know I can kill my current OS by being an idiot :-)
[20:05] <wadechandler> silly client didn't chop it for me...must need a new client other than pidgin
[20:05] <wadechandler> thanks dobey
[20:06] <sarnold> wadechandler: there's nothing that gaurantees package downgrades will work; in my experience they usually do work, but some things are just easier done in a VM first :)
[20:08] <wadechandler> thanks sarnold; for some things I would totally think that, but in the case of multi monitors it can be tricky because of vid cards etc, but I should give it a shot that way anyways :-( I'm just lazy :-P
[20:08] <wadechandler> thanks
[20:09] <sarnold> wadechandler: cool :) have fun
[21:41] <brainwash> doko: hey, so the new bash upstream version is now available in debian experimental (4.3~rc1-1). would it be possible to setup a PPA for ubuntu to provide this new version? I assume that some changes are needed to make it work properly in ubuntu, right? if no, I could try the debian package
[21:43] <dobey> did the required patch level (-p option to patch) change for quilt packages in dpkg in trusty?
[21:44] <slangasek> quilt patches are always -p1 by default unless otherwise specified in the series
[21:45] <dobey> that's what i thought, but the patch i just created, won't apply, :-/
[21:46] <dobey> http://pastebin.ubuntu.com/6729042/ is what i'm getting
[21:46] <slangasek> is ubuntuone/devtools/testcases/tests/test_squid_testcase.py present in the upstream source?
[21:47] <slangasek> dpkg doesn't appear to be objecting to the patch, the patch simply doesn't apply
[21:47] <dobey> hrmm, it seems to not be in the bzr tree for some reason
[21:48] <dobey> and indeed is not in the tarball
[21:48] <dobey> wtf
[22:10] <infinity> dobey: bzr add? :P
[22:11] <dobey> infinity: no. none of the tests are in the tarball it seems. not sure why or when they stopped getting picked up by python during sdist. will have to figure it out later :-/
=== salem_ is now known as _salem