[06:49] <FourDollars> It seems no patch pilot now. Is anyone willing to review and sponsor my patch on https://bugs.launchpad.net/ubuntu/+source/clutter-gtk/+bug/1401376?
[07:57] <smb> hallyn, mdeslaur, Stomped by security... the sad story of my life... :-P
[08:02] <dholbach> good morning
[09:48] <cjwatson> Laney: Did you notice that your libsoup2.4 sync FTBFS on powerpc and ppc64el?
[09:48] <Laney> cjwatson: Yes - I fixed the immediate failure and then reported an upstream bug about a hanging testcase
[09:48] <Laney> Waiting to hear back now
[09:49] <cjwatson> Laney: ok, thanks
[09:50] <Laney> I'll skip the test or something by the end of the day
[11:20] <xnox> stgraber: mvo: it looks cool, well done! =)
[12:24] <mdeslaur> smb: sorry about that, I'll probably release the updates today :P
[12:24] <smb> mdeslaur, Heh yeah. Thats a hope :)
[12:42] <cjwatson> Noskcaj: I think if you wanted to merge dhelp that it would actually manage to migrate to vivid now; I fixed up ruby-bdb
[12:42] <cjwatson> (by way of a sync and some NBS removals)
[13:01] <Riddell> pitti: this seems to be a problem with the jenkins server not with the package? https://jenkins.qa.ubuntu.com/job/vivid-adt-kate/lastBuild/console
[13:02] <cjwatson> Riddell: there's already a retry in the queue
[13:02] <Riddell> groovy
[13:02] <cjwatson> running, in fact
[13:03] <cjwatson> queue's a bit long because there were some infrastructure problems over the last couple of days so lots of retries last night / this morning
[13:04] <Riddell> I'll be patient :)
[13:12] <mdeslaur> pitti, kees, infinity, stgraber, slangasek: next tech board meeting is scheduled for dec 23rd, shall we skip it and have it jan 6th instead?
[13:24] <pitti> mdeslaur: sounds good to me; I'm still on vac on jan 6, but I'll make it
[13:32] <pitti> Riddell: yeah, I'm afraid the whole CI infrastructure got broken due to the data center move; things should move back into place soon
[14:51] <peacememories> heya, any ubuntu-core people here?
[15:13] <bdmurray> tseliot: can you have a look at bug 1401390?
[15:27] <tseliot> bdmurray: looking
[15:33] <tseliot> bdmurray: nvidia provides libopencl and apparently that is being picked up before ocl-icd-libopencl1 (alphabetical order seems to be the criterion)
[15:37] <tseliot> bdmurray: ok, I know what happened. nvidia-libopencl1-331 now depends on nvidia-331-uvm, which, in turn, depends on nvidia-331. The dependency is correct but nvidia-libopencl1-331 shouldn't have been installed in the first place (since it only works with nvidia)
[15:49] <slangasek> mdeslaur: sounds good to me
[15:50] <bdmurray> mvo: Could you have a look at bug 1399455?
[15:58] <bdmurray> pitti: did you see my ping about the py3cairo debugy packages missing?
[16:13] <tseliot> doko: ping
[16:14] <doko> tsdgeos, ?
[16:14] <tsdgeos> me what?
[16:14] <tsdgeos> ah, wrong autocomplete
[16:22] <tseliot> doko: libhwloc-plugins seems to pull in the libopencl1 virtual package, which, in turn, pulls in nvidia-libopencl1-331 instead of ocl-icd-libopencl1, and results in LP: #1401390
[16:30] <sil2100> mitya57: oh! I see your PlatformSystemTrayIcon branch for appmenu-qt5!
[16:47] <rbasak> pitti: some help with apport please? In mysql, we currently intentionally fail an attempted downgrade from eg. 5.6 to 5.5 in the preinst, causing the maintainer script to exit non-zero with a message.
[16:47] <rbasak> pitti: this triggers apport. But in this case it isn't a bug, so is there some way to tell apport it's OK?
[16:48] <rbasak> An alternative we're considering is to succeed but then let mysql be broken for manual fixing.
[16:50] <rbasak> We've decided to let the maintainer script succeed but disable daemon startup.
[16:50] <rbasak> (with a debconf note explaining)
[16:50] <rbasak> That's maybe better. So never mind.
[16:55] <roadmr> hello folks! Is there a way to update lxc cache (/var/cache/lxc/$RELEASE)? The apt data is out of date so I always have to do apt-get update in every lxc container I create :/
[16:55] <roadmr> (I could clearly just delete the cache so lxc-create rebuilds it from newest sources, but that'd be quite slow)
[17:05] <tseliot> bdmurray, doko: apparently, we only need to rebuild hwloc so as to get the correct dependencies: Depends: libc6 (>= 2.4), libltdl7 (>= 2.4.2), libopencl-1.1-1, libpciaccess0, libxml2 (>= 2.7.4), ocl-icd-libopencl1 (>= 1.0) | libopencl1, libhwloc5
[17:07] <bdmurray> rbasak: for future reference not really to prevent the crash notification from appearing, but to stop it from being submitted you could write a bug pattern.
[17:12] <tseliot> bdmurray: do I still need an SRU for a simple rebuild?
[17:13] <tseliot> (a no-change rebuild
[17:13] <tseliot> )
[17:13] <bdmurray> tseliot: I think so. slangasek?
[17:17] <slangasek> tseliot, bdmurray: yes; if you're rebuilding from source, there's plenty of room for something else to go wrong
[17:17] <tseliot> slangasek, bdmurray: ok, it makes sense. Speaking of which, I have just uploaded the change for hwloc
[17:18] <bdmurray> slangasek: we'd want a bug for tracking that too then right?
[17:19] <slangasek> yes
[17:26] <tseliot> bdmurray, slangasek: I reassigned the bug to hwloc, requested an SRU and uploaded the sources. It should all be ready
[17:29] <bdmurray> tseliot: okay, I'll review it today
[17:29] <tseliot> bdmurray: thanks
[17:30] <rbasak> bdmurray: thanks. I did suggest that but we thought it was bad for the user to get the crash notification too.
[17:31] <bdmurray> tseliot: what about utopic?
[17:36] <tseliot> bdmurray: same problem :/ let me fix that one too
[17:36] <bdmurray> tseliot: thanks!
[17:37] <tseliot> bdmurray: what version shall I use?
[17:37] <bdmurray> tseliot: 14.04.1 and 14.10.1 would have been ideal
[17:38] <tseliot> bdmurray: I uploaded 1.8-1ubuntu1.1 in trusty-proposed but the one in utopic is still at 1.8-1ubuntu1
[17:38] <tseliot> bdmurray: if you want to reject the one in trusty-proposed, I'll reupload
[17:38] <bdmurray> tseliot: right so instead 1.8-1ubuntu1.14.04.1 would be better
[17:39] <tseliot> bdmurray: ok, please reject the one in the queue then
[17:39] <bdmurray> tseliot: done
[17:39] <tseliot> thanks
[17:46] <cjwatson> mvo: I just noticed that https://launchpad.net/ubuntu/+source/apt/1.0.1ubuntu2.2 was shadowed by a security update and so never released to trusty-updates.  Is it easy for you to rebase that on top of the current trusty-updates (maybe in git), or should I just go ahead and do it?
[17:49] <tseliot> bdmurray: ok, uploaded
[17:51] <bdmurray> arges: to be clear bug 1368815 is v-done for utopic?
[17:52] <arges> bdmurray: yes, sorry to confuse the bug comments; I was also trying to hunt another qcow2 corruption bug, but it is a separate issue
[17:53] <bdmurray> arges: no problem, just wanted to err on the side of caution
[17:57] <kkirsche> Hey guys, I've been looking around but I haven't been able to identify this, what package is used to create the graphical installer used by ubuntu or where can I find the source code for the graphic installer?
[17:57] <bdmurray> kkirsche: ubiquity
[17:58] <kkirsche> thank you bdmurray I'll look at that. Thank you
[18:26] <bdmurray> smb: do you want this new dahdi-linux accepted before the other upload is verified?
[18:27] <smb> bdmurray, Yeah, it actually fixes the first at least in Precise
[18:28] <smb> changes contains both so verification of both should be carrying on
[18:29] <bdmurray> smb: got it, thanks
[18:30] <bdmurray> Riddell: it looks like there is a typo in your lixext upload. https://launchpadlibrarian.net/192182678/libxext_2%3A1.3.2-1_2%3A1.3.2-1ubuntu0.1.diff.gz
[19:02] <_Groo_> hi/2 all
[19:50] <mdeslaur> smb: ok, qemu updates for stable releases done.
[19:53] <MasterPiece> Hello all :)
[19:53] <MasterPiece> https://bugs.launchpad.net/ubuntu/+source/gsettings-desktop-schemas/+bug/1401646
[20:37] <timrc> kirkland, So none of the snappy commands to update the system and install packages requires sudo... at least on that KVM image you linked too in your blog
[20:37] <timrc> s/too/to/ (still have 33 years I cannot get that one right :))
[21:19] <smoser> infinity, is there some official thing / test that needs to happen to make the utopic-* things (hwe updates) in http://archive.ubuntu.com/ubuntu/dists/trusty-proposed/main/installer-amd64/current/images/ able to move to -updates ?
[21:19] <smoser> i can do a quick sniff of them.
[21:28] <timrc> kirkland, Ah I took a look at the code... calling sudo from inside snappy
[21:33] <mwhudson> is there a cross toolchain targetting ppc64le in the archive?
[21:34] <mwhudson> ah, yes
[21:40] <smoser> timrc, you're not the first person  to notice that. :)
[21:40] <smoser> it will change to your expectation
[21:41] <timrc> smoser, Nice.  Yeah... it seems a little... un-ubuntu-y
[21:46] <infinity> smoser: If you can test i386 generic and utopic-generic for me and make sure they both boot and install the expected kernel, that would be great.
[21:46] <infinity> smoser: I've tested amd64, ppc64el, and powerpc64, and I've had arm64 tested.  That just leaves armhf.
[21:50] <smoser> infinity, someone going to do that ? thats not one i can easily test.
[21:52] <infinity> smoser: My house in a bit of a pre-move mess, so finding bits to test with has been challenging, but if I can't put together what I need, I'll get someone else to test.
[21:53] <infinity> Actually, I could probably test it in qemu, if we build the right DTB for vexpress...
[21:53]  * infinity checks.
[21:54] <infinity> Yeah, I can probably fudge something together to test armhf on my laptop.
[21:57] <smoser> infinity, i'd be interested in knowing how  you do that .
[21:57] <smoser> if you dont mind writing it donw
[21:58] <infinity> Well, the only annoying bit is going to be extracting (or building) the right DTBs, since I don't ship them with d-i, apparently.
[21:59] <infinity> I should fix that.
[22:23] <infinity> smoser: This seems to be doing the trick:
[22:23] <infinity> qemu-system-arm -M vexpress-a9 -m 1G -kernel vmlinuz -initrd initrd.gz -dtb vexpress-v2p-ca9.dtb -serial stdio -nographic -no-reboot -append "console=ttyAMA0" -sd armhf.img
[22:23] <infinity> smoser: Will know more once I've installed.
[22:24] <infinity> smoser: Oh, ditch the -nographic, qemu's I/O multiplexer seems to go insane without the graphics console being up.
[22:42] <infinity> smoser: Yeah, nevermind.  That all ended very poorly.  I'm going to hunt down an SD card and my Panda.
[22:42] <infinity> ... and fix d-i on qemu another day.