=== utlemming_away is now known as utlemming
=== tmpRAOF is now known as RAOF
=== _salem is now known as salem_
=== salem_ is now known as _salem
=== Ionic is now known as Guest90842
=== Malsasa is now known as Guest91062
=== Malsasa_ is now known as Malsasa
[05:56] <pitti> Good morning
[05:56] <Unit193> Heya.
=== Malsasa_ is now known as Malsasa
=== ara is now known as Guest36049
[07:03] <pitti> tyhicks, kirkland: *sigh*, more trouble with ecryptfs swap: bug 1453738
[07:03] <ubottu> bug 1453738 in ecryptfs-utils (Ubuntu) "installer in LVM mode sets up broken encrypted swap, using duplicate unencrypted swap" [High,Triaged] https://launchpad.net/bugs/1453738
[07:03] <pitti> it seems for the past several years we have set up unencrypted or broken swap and nobody noticed :/
[07:06] <pitti> except that this bug is worse, as we unintentionally use unencrypted swap
[07:19] <Mirv> something has just killed i386 building? https://launchpadlibrarian.net/208901928/buildlog_ubuntu-wily-i386.webbrowser-app_0.23%2B15.10.20150610-0ubuntu2_BUILDING.txt.gz happens on multiple sources
[07:19] <Mirv> "dh_auto_configure: cmake .. -DCMAKE_INSTALL_PREFIX=/usr -DCMAKE_VERBOSE_MAKEFILE=ON -DCMAKE_BUILD_TYPE=None died with signal 11"
[07:19] <Mirv> and i386 only
[07:20] <Mirv> all cmake though
[07:21] <Mirv> all I know is that they built on Wednesday at least
[07:25] <Mirv> it seems cmake specific, but I don't see anything recent related to that uploaded
[07:44] <Frantique> hello all
[07:45] <Frantique> guys, why it is so slow to give a review to the updated packages on developer.ubuntu.com?
[07:47] <zzzdeb> hello, is there any way i can create a deb package that makes a delay at install?
[07:48] <Frantique> zzzdeb: perhaps a sleep in preinstall script?
[07:49] <Frantique> or in postinstall, depending on the needs, ofcourse
[07:53] <Mirv> actually, I had a successful build 13h ago, and now those cmake i386 failures
[07:54] <caribou> I need some help with a merge :
[07:54] <caribou> I have fixed all conflicts from grab-merge and trying to build the source pkg
[07:55] <caribou> turns out that apparently one of the source in the tarball has been modified by grab-merge
[07:55] <caribou> is it to be expected ?
[07:55] <caribou> i.e. one patch from the previous version is applied in the merged output
[08:02] <Mirv> caribou: I'm not sure if I understand the context, but you might want to change the source version number (if the source is not actually same anymore), or unapply the patch if it has been accidentally applied and should actually be in debian/patches and only applied at build time
[08:03] <Mirv> Frantique: you could try asking on #ubuntu-app-devel regarding the review
[08:03] <caribou> Mirv: that's what I'm doing atm. I got the pristine source from the tarball & crafting a quilt patch to keep the modification applied
[08:03] <caribou> Mirv: I am just surprized that MoM didn't flag that as a conflict
[08:05] <Frantique> Mirv: thanks
[08:11] <zyga> cjwatson: hey, do you know who I can ping to get tarmac reviews?
[08:11] <zyga> cjwatson: I sent out an introductionary merge request a few days ago but without any response
[08:11] <zyga> cjwatson: I'm working on more changes locally to actually do stuff but I'm worried with the lack of response so far
[08:35] <LocutusOfBorg1> Hi ubuntu sponsors, your opinion on bug 1297849 ?
[08:35] <ubottu> bug 1297849 in network-manager-vpnc (Ubuntu) "[SRU] Virtual private network connection fails after distribution upgrade due to outdated Network Manager configuration files" [High,Triaged] https://launchpad.net/bugs/1297849
[08:35] <LocutusOfBorg1> seems that syncing network-manager* stuff from debian might be the easiest solution, at least for wily
[08:46] <Mirv> infinity: we believe the gnutls broke all i386 cmake builds https://launchpadlibrarian.net/208901967/buildlog_ubuntu-wily-i386.unity8_8.02%2B15.10.20150603.1-0ubuntu2_BUILDING.txt.gz
[08:46] <Mirv> sil2100: ^
[08:46] <Mirv> that's the only thing that matches the timing, and it seems gnutls is somehow used by cmake at least
[09:01] <Mirv> sil2100: infinity1: confirming i386 building without an issue without -proposed, so I filed bug #1464569
[09:01] <ubottu> bug 1464569 in gnutls28 (Ubuntu) "3.3.15-5ubuntu1 breaks CMake on i386" [Undecided,New] https://launchpad.net/bugs/1464569
=== tvoss is now known as tvoss|test
=== tvoss|test is now known as tvoss
[09:15] <cjwatson> zyga: if it were me I would try the last three or four people from the intersection of (has committed to trunk, is in the team that can do so)
[09:16] <zyga> cjwatson: thanks
[09:16] <sil2100> Mirv: thanks!
[09:16] <sil2100> infinity1: we'll have to do something with the new gnutls28 as it's really breaking stuff
[09:17] <cjwatson> Does a straight cmake rebuild fix things?  (Would be quick to try locally, I expect)
[09:18] <cjwatson> Or possibly a curl rebuild
[09:51] <LocutusOfBorg1> cjwatson, sil2100 Mirv
[09:51] <LocutusOfBorg1> https://bugs.launchpad.net/ubuntu/+source/gnutls28/+bug/1462934
[09:51] <ubottu> Ubuntu bug 1462934 in gnutls28 (Ubuntu) "please merge gnutls28 from Debian" [Undecided,Fix released]
[09:52] <LocutusOfBorg1> https://bugs.launchpad.net/ubuntu/+source/curl/+bug/1459685/comments/9
[09:52] <ubottu> Ubuntu bug 1459685 in curl (Ubuntu) "please merge curl from debian" [Undecided,Confirmed]
[09:52] <LocutusOfBorg1> ^^^^
[09:52] <LocutusOfBorg1> unfortunately it has been uploaded before gnutls, not after :)
[09:53] <LocutusOfBorg1> You might look at https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=784009 too
[09:53] <ubottu> Debian bug 784009 in libgnutls-deb0-28 "Lack of versioned symbols in nettle causes segfault" [Serious,Fixed]
[10:01] <sil2100> Oh :)
[10:01] <sil2100> LocutusOfBorg1: thanks!
[10:01] <LocutusOfBorg1> I mentioned in the merge request, but not enough loudly ;)
[10:01] <LocutusOfBorg1> sorry for the confusion
[10:02] <LocutusOfBorg1> thanks to you!
=== Guest90842 is now known as Ionic
=== MacSlow is now known as MacSlow|lunch
[12:20] <zyga> cjwatson: hey, did you see my question about ppa and code exporter earlier
[12:21] <zyga> cjwatson: I'm curious if the restriction not to export bzr branches from launchpad-based git branches
[12:21] <cjwatson> zyga: I think you were offline when I tried to reply
[12:21] <cjwatson> zyga: Where do PPAs come into it?
[12:22] <zyga> cjwatson: is intentional or a tech limitation
[12:22] <zyga> cjwatson: and what is the recommended way to get ppa packages built from git repos
[12:22] <zyga> cjwatson: perhaps, I had some issues with my machines latelty
[12:22] <zyga> cjwatson: they are built from recipes
[12:22] <zyga> cjwatson: from bzr branches
[12:23] <cjwatson> zyga: And indeed, there is such a restriction on code imports at the moment (historically, it was to prevent circular imports from other bzr branches on LP), which we'll lift soon
[12:23] <cjwatson> zyga: Recipes are on the to-do list, which I'm pretty sure I've told you before, we don't have a "recommended way" yet
[12:24] <zyga> cjwatson: that makes sense, so the recommended way will be to use bzr exportrs for recipes?
[12:25] <cjwatson> There will probably be a transitional period when LP-git-to-LP-bzr imports work but recipes don't yet
[12:25] <cjwatson> But we do intend to make recipes work for git too
[12:26] <zyga> cjwatson: oh, I must have missed that, thank you
[12:27] <cjwatson> The import limitation dates from bug 820069
[12:27] <ubottu> bug 820069 in Launchpad itself "BadUrlLaunchpad raised mirroring a branch" [Critical,Fix released] https://launchpad.net/bugs/820069
[12:28] <cjwatson> Well, and a similar thing in the codeimport worker
[12:29] <cjwatson> Which is rather older, 2007-era
=== joet is now known as josepht
=== _salem is now known as salem_
=== mwenning is now known as mwenning-wfh
=== anthonyf is now known as Guest45939
[13:38] <rbasak> shaderslayer: test docker.io backport packages at https://launchpad.net/~docker-maint/+archive/ubuntu/staging. I will review and upload for SRUs soon.
=== MacSlow|lunch is now known as MacSlow
[15:00] <shaderslayer> rbasak: thanks!
[15:00] <rbasak> shaderslayer: please let us know how you get on
[15:01] <shaderslayer> will do :)
[15:02] <shaderslayer> rbasak: oh, would have been nice to have armhf packages too
[15:02] <rbasak> shaderslayer: can you rebuild locally OK? The PPA just isn't enabled for armhf that's all.
[15:03] <rbasak> shaderslayer: when we upload to Ubuntu you'll get armhf
[15:03] <shaderslayer> rbasak: yeah, I reckon we'll do that
=== infinity1 is now known as infinity
[15:28] <infinity> sil2100: Ugh.  Who turned off proposed in that silo to make the package build?  That's not helpful.
[15:33] <arges> hallyn: does lxc by default set any cgroup.cpu.* settings?
[15:33] <arges> hallyn: n/m i can just lxc-info it
=== shaderslayer is now known as shadeslayer
[15:47] <hallyn> arges: nope
[15:48] <arges> hallyn: thanks, yea see it now
[15:51] <barry> pitti: are you still around?  q re: adt-run
=== pgraner is now known as pgraner-afk
[16:27] <sil2100> infinity: we did that, the unity8 was required for a landing
[16:27] <infinity> sil2100: ...
[16:27] <sil2100> infinity: it's eaisly reproducible in anything ;p!
[16:28] <sil2100> Mirv reproduced it with some strange package in his PPA
[16:28] <infinity> sil2100: That's not the point.  Those PPAs have proposed enabled for a reason.
[16:28] <infinity> sil2100: Skipping past transitions in proposed means the transitions never finish (and can even regress).
[16:28] <infinity> sil2100: Was unity8 in *wily* that important that it couldn't wait for a proper fix?
[16:29] <sil2100> infinity: ok, sorry about that then, we didn't know it depended actually on anything that was in transition, it was a dual landing so it required landing to both places, wily first even
[16:30] <sil2100> Since we thought that the problem was in a dependency of a dependency
[16:30] <infinity> sil2100: Might be a process failure if "dual landing" implies "hack around breakage in the devel series".
[16:30] <infinity> sil2100: It may well have not caused an issue, I haven't checked, but generally, turning off proposed is a Bad Thing.
[16:31] <infinity> sil2100: And I keep running into silo PPAs where it's been turned off and never back on, which is also irksome.
[16:31] <sil2100> infinity: noted, well, having proposed enabled also includes additional risks, especially when you land to the overlay without proposed-migration, since you could basically build against a broken library that would be dropped
[16:31] <sil2100> So it's a double-edged sword anyway
[16:32] <sil2100> infinity: I have re-enabling the PPA to use -proposed in my daily-doings, so this one wouldn't be forgotten
[16:33] <infinity> sil2100: Anyhow, I'd argue the process needs revision to match the SRU process.  SRUs require "fix in devel", but that really just means "uploaded, so we don't lose the code change", not "uploaded, built, and migrated" or anything.
[16:33] <infinity> sil2100: dual landing should likely be similar.  The goal is to not lose the change, not to force people to hack around temporary problems just to get B landed before A.
[16:43] <sil2100> infinity: right... sadly right now the dual landing required landing both at once
[16:44] <sil2100> We *could* release just one, but only after removing binaries of the other from the PPA
[16:44] <sil2100> Which sucks a bit
[16:44] <sil2100> But yeah, dual-landings is a quick helper thing
=== tvoss is now known as tvoss|test
=== tvoss|test is now known as tvoss
[18:00] <smoser> infinity, i suspect you know if anyone... is there a way that i can disable initramfs update that would happen as a result of 'apt-get install' operation ?
[18:01] <smoser> strikov and i are wanting to avoid that as we know we're going to haev to update ourselves. and just want to save some time.
[18:02] <cjwatson> The standard way we use in various places is to divert it aside temporarily and replace with a trivial wrapper.  See livecd-rootfs for example.
[18:02] <ogra_> mv  /usr/sbin/update-initramfs /usr/sbin/update-initramfs.real && ln -s /bin/true /usr/sbin/update-initramfs
[18:02] <ogra_> (and revers it after update)
[18:03] <cjwatson> Please use dpkg-divert instead.
[18:03] <cjwatson> I gave a pointer already which is better.
[18:03] <ogra_> yeah, sorry, i was typing :)
[18:03] <cjwatson> You don't want your work to be undone if an initramfs-tools upgrade happens to arrive.
[18:04] <ogra_> indeed, thats just a quick hack ... diverting is the proper way
=== Trevinho is now known as Trevinho|Holiday
[19:15] <DreadPirateBob> Getting a failure on launchpad in my PPA. bzr bd -- -k <parentkeyid> is signing with <subkeyid>. dput succeeds, but the build fails because it doesn't recognize the key.
[19:15] <DreadPirateBob> Anyone know how to get this working?
[19:15] <DreadPirateBob> barry maybe? (Hi Barry)
[19:22] <DreadPirateBob> Nevermind. Confusing output, but not an error.
[19:23] <barry> DreadPirateBob: ok... and hi!
[19:25] <DreadPirateBob> backportpackage showed the right thing, so I was confused
[19:53] <cjwatson> DreadPirateBob: You mean the complaint about being unable to check the signature on the .dsc?
[19:56] <cjwatson> Or possibly the one about the public key for the archive on ppa.launchpad.net being unavailable.  Either way, we should suppress both of those when we get round to it, but at least it's only cosmetic.
[20:04] <DreadPirateBob> This was two fold: when I ran bzr bd -S -- -k<myparentkey>, when it got to the signing part, it prompted me for the subkey. Then dput verified using the subkey, and then showed a warning in the build log that the key could not be verified.
[20:05] <DreadPirateBob> but the subkey is not shown in the launchpad ui
=== ming is now known as Guest91806
[20:10] <DreadPirateBob> probably just a display setting.
[20:37] <meles> I'm havin a problem when trying to get my ambient light sensor working. I would need the value of /sys/class/backlight/acpi_video0/max_brightness which is not found. Instead I have /sys/class/backlight/intel_backlight/max_brightness. Is there any way to link it?
[20:41] <shadeslayer> does anyone know how to switch to the gold linker for a package?
[21:07] <shadeslayer> -fuse-ld=gold for now I guess :3
[21:33] <cjwatson> DreadPirateBob: Right, anything you see in the build log about key verification is cosmetic and should be silenced; Launchpad does all the verification well before it gets to the point of building the source package, and doesn't need to do it again there, but we haven't made all the warnings shut up :-)
=== salem_ is now known as _salem