[05:45] <pitti> Good morning
[05:48] <Unit193> Howdy.
[07:29] <dholbach> good morning
[07:59] <seb128> hey dholbach
[07:59] <dholbach> hi seb128
[08:47] <dholbach> @pilot in
[08:51] <seb128> dholbach, ;-)
[08:58] <highvoltage> n/win 21
[09:04] <pitti> apw, infinity, Laney: hah! queue lengths: http://autopkgtest.ubuntu.com/running.shtml
[09:09] <Laney> pitti: nice!
[09:10] <Laney> and shtml> nice too (was away on Friday when you announced it)
[09:10] <Laney> we'll make a web designer of you yet
[09:12] <pitti> Laney: I just added <html style="layout: nice"> ☺
[09:12] <Laney> hah
[09:14] <pitti> Laney: as for reading the queue contents: the administrator UI also just reads and requeues all requests, which garbles their order :(
[09:16] <LocutusOfBorg1> good morning folks
[09:17] <pitti> Laney: I reviewed your britney MP yesterday, looks good now! thanks for that
[09:17] <Laney> \o/
[09:17] <pitti> Laney: please push
[09:17] <Laney> just grinding through email, will look soon
[09:17] <pitti> ack
[09:30] <LocutusOfBorg1> can anybody please retry arrayfire for xenial on amd64 and i386?
[09:30] <LocutusOfBorg1> it should build now
[09:30] <LocutusOfBorg1> and remove powerpc build, it doesn't build anymore in Debian too
[09:30] <pitti> LocutusOfBorg1: done
[09:30] <LocutusOfBorg1> thanks
[09:30] <pitti> well, the retries
[09:31] <LocutusOfBorg1> well, I uploaded a new version on Debian a few seconds ago
[09:31] <LocutusOfBorg1> we will see how the build goes
[09:31] <LocutusOfBorg1> but I need to know if the current version was failing because of underlying toolchain failures
[09:31] <LocutusOfBorg1> so thanks
[09:45] <apw> pitti, nice
[09:46] <Laney> pitti: manual merge proposal request: https://git.launchpad.net/~laney/+git/autopkgtest-cloud/commit/?id=6f74b2a4a718012fa645ca4f78a4557c4f26ad18
[09:46] <Laney> (LP doesn't support MPs for these personal git branches)
[09:47]  * Laney cowboyed it already to check it works
[09:48] <LocutusOfBorg1> interesting, the build failed
[09:48] <LocutusOfBorg1> so I'll wait for the debian dinstall and ubuntu sync
[09:49] <pitti> Laney: ok, let's keep that for a while; pushed with a "debci-web-swift charm:" log prefix
[09:49] <Laney> thanks!
[09:50] <Laney> I think this makes browsers re-learn their URL bar entries at least
[10:09] <morphis> seb128, cyphermox, pitti: time to look at https://requests.ci-train.ubuntu.com/#/ticket/522 and publish if ok for you?
[10:09] <pitti> morphis: I'm afraid I have zero knowledge about libhybris and whether to update it
[10:10] <seb128> morphis, I don't think you need a coredev for that, #ubuntu-ci-eng trainguards should be enough
[10:10] <morphis> seb128: robru just told me I need one :)
[10:10] <robru> seb128: nope it's a main package, needs core dev
[10:10] <robru> seb128: trainguards have no publishing power any longer
[10:11] <seb128> oh, I didn't know libhybris was in main
[10:11] <morphis> pitti, seb128: so who can do the publishing job then?
[10:11] <morphis> was rsalveti who did that directly before
[10:11] <Mirv> morphis: for example p + s
[10:12] <sil2100> seb128: yeah, it is, I already tried publishing this silo and failed ;)
[10:12] <Mirv> morphis: sil_2100 possibly soon and I'll probably apply within a few months as well
[10:12] <seb128> Mirv, morphis, I just did it
[10:12] <morphis> seb128: thanks!
[10:12] <sil2100> seb128: thanks!
[10:12] <seb128> trusting you guys that the update is good
[10:12] <seb128> yw
[10:13] <morphis> Mirv: sounds good
[10:25] <pitti> dholbach: btw, I'm handling bug 1510824
[10:25] <pitti> dholbach: (to avoid stepping on our toes for sponsoring)
[10:25] <dholbach> oops
[10:26] <dholbach> pitti, I uploaded it earlier - was that wrong? :-/
[10:26] <pitti> dholbach: ah, didn't see that in the bug
[10:26] <pitti> dholbach: no, it's ok, but I'm committing to Debian and would like to keep them in sync
[10:26] <pitti> but I can still sync after that
[10:26] <dholbach> thanks!
[10:27] <pitti> dholbach: the stable SRUs are fine; thanks for sponsoring!
[10:27]  * pitti updates the bug status
[10:27] <dholbach> thanks pitti!
[10:28] <pitti> dholbach: I unsub'ed sponsors to clean up the list (the SRU will keep the tasks open for a while)
[10:28] <dholbach> great
[10:32] <Laney> bdmurray: glib2.0/wily> I rebuilt the source pkg and uploaded it again, thanks for noticing
[11:28] <cjwatson> infinity: Reminder about xenial chroot refreshing
[11:29] <cjwatson> Unit193: Nothing special beyond the reposurgeon docs.  Once you're using reposurgeon rather than just fast-export/import, you're going to need to read its docs anyway :-)
[12:37] <morphis> cyphermox: ping
[12:41] <cyphermox> good morning!
[12:41] <cyphermox> morphis: hey
[12:42] <morphis> cyphermox: good morning!
[12:43] <morphis> cyphermox: regarding our discussion on friday
[12:43] <morphis> have a look at https://code.launchpad.net/~morphis/bluez/vivid-5.36-upgrade/+merge/278302
[12:43] <morphis> and the result on https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/landing-054/+packages
[12:43] <morphis> which produces now sane version numbers
[12:43] <morphis> from a MP
[12:44] <cyphermox> k
[12:45] <morphis> cyphermox: it currently only adds one extra changelog item "No-change rebuild."
[13:09] <pitti> Laney: aah! "never passed" stuff on http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#systemd :)
[13:11] <Laney> pitti: yay!
[13:12] <Laney> and sad that we have this for unity8
[13:12] <didrocks> what is the difference with "always failed"?
[13:12] <Laney> doesn't wait for the test to finish
[13:13] <didrocks> shouldn't it be "Test in progress (always failed)" rather then ?
[13:13] <didrocks> not important, but it seems, this just introduce a difference where there should be none?
[13:13] <tkamppeter> sladen, hi
[13:13] <pitti> didrocks: yeah, that's a point
[13:14] <Laney> maybe
[13:14]  * didrocks happy to propose a patch (just need to find the branch :p)
[13:14] <pitti> didrocks: https://code.launchpad.net/~ubuntu-release/britney/britney2-ubuntu
[13:14] <didrocks> pitti: thanks!
[13:14]  * pitti hugs our new britney maintainer
[13:15] <dholbach> @pilot out
[13:15] <didrocks> pitti: you should have told that after I did a MP :p
[13:15] <didrocks> strategic mistake here ;)
[13:15] <pitti> dang!
[13:16] <didrocks> heh
[13:17] <didrocks> (but trailing coma at the end of the dict in the code, /me hugs $whoever)
[13:20]  * didrocks looks for how to run tests
[13:21] <Laney> tests/test_autopkgtest.py
[13:22] <didrocks> yeah, I was just missing kombu
[13:22] <didrocks> and modified tests pass
[13:22] <pitti> that reminds me, we should probably change that to use python3-amqplib; as that's available in trusty, python3-kombu isn't
[13:22] <pitti> robru: ^ right?
[13:23] <didrocks> (same for python3-mock, it's part of unittest now)
[13:24] <pitti> didrocks: oh? if you feel like it, please feel free to convert that too, that'd be appreciated
[13:25] <pitti> didrocks: ah, that's just in ./tests/test_boottest.py, right?
[13:25] <didrocks> pitti: https://code.launchpad.net/~didrocks/britney/more_coherent_message/+merge/278312 first
[13:25] <didrocks> and yeah
[13:25] <didrocks> I can change it
[13:25] <pitti> didrocks: wrong merge target :/
[13:26] <didrocks> argh, I used bzr lp-propose
[13:26] <didrocks> so that set upstream branch isn't the right one
[13:26] <didrocks> the*
[13:26] <pitti> didrocks: but nevermind, I can merge it like that
[13:26] <didrocks> pitti: ok, thanks :)
[13:26] <didrocks> pitti: feel free to change to unittest maybe meanwhile? I have the test_boottest failing here, even with trunk)
[13:26] <pitti> didrocks: oh? works here
[13:26] <pitti> what's failing?
[13:27] <didrocks> TypeError: do_test() missing 2 required positional arguments: 'unstable_add' and 'expect_status'
[13:27] <didrocks> I'm on wily though
[13:27] <didrocks> with 3.4
[13:27] <didrocks> (and running using nose)
[13:27] <pitti> wily/3.4 should be fine
[13:27] <pitti> didrocks: I just call tests/test_autopkgtest.py and tests/test_boottest.py
[13:27] <pitti> how do you run using nose?
[13:28] <didrocks> yeah, calling works
[13:28] <didrocks> nosetests3 tests/*
[13:28] <pitti> merged, thanks!
[13:28] <diwic> maybe having a runny nose helps
[13:28]  * diwic sees puns everywhere, hard to hold back
[13:28] <didrocks> diwic: ask Laney! :-)
[13:28] <Laney> ah, the bikeshed looks nicer now!
[13:29] <Laney> :P
[13:29] <didrocks> pitti: sweet! ;)
[13:29] <didrocks> pitti: want me to push the unittest thingy?
[13:29] <caribou> Any reason why dh_input high would not prompt for a question during a normal apt-get install of a new package (never installed)
[13:29] <caribou> ?
[13:29] <pitti> didrocks: so, no idea aobut those; if you care, feel free to look into the nose thingy
[13:29] <diwic> "look into the nose thingy"?!
[13:29] <caribou> If I follow-up with dpkg-reconfigure it does ask the question
[13:29] <pitti> didrocks: but converting the external mock into whatever the internal replacement is sounds great (I figure it's trivial)
[13:30] <pitti> diwic: yes, so that it's running again :)
[13:30]  * diwic goes gossiping about Britney's nose running and earns some extra $$$
[13:31] <pitti> didrocks: apparently it's mis-interpreting the do_test() helper function as a test ?
[13:31] <didrocks> pitti: sounds like so, let's not bother about the nose one, I'm looking at mock internal, one sec
[13:32] <didrocks> yep, quite easy :)
[13:33] <didrocks> pitti: just last commit of lp:~didrocks/britney/unittest-mock
[13:34] <pitti> didrocks: oh, that was really easy :)
[13:35] <pitti> didrocks: merged, merci !
[13:35] <didrocks> pitti: isn't it? There has been some small interface changes that I needed in my projects, but britney tests don't use any of them
[13:35] <didrocks> pitti: avec plasir :)
[13:49]  * mdeslaur hugs mardy for fixing unity-scope-gdrive
[13:51] <seb128> mardy, thanks for that!
[13:51] <mardy> mdeslaur, seb128: yw! :-)
[13:53] <mardy> the funny thing is that I don't use it much, and I wasn't even aware that it was broken :-)
[13:55] <cyphermox> @pilot in
[14:04] <sil2100> cyphermox, kenvandine: hey guys! I have a core-dev-related packaging question
[14:05] <mterry> kenvandine, good morning!  Over the weekend, I tried building deja-dup trunk in a PPA, and it built fine, including tests: https://launchpadlibrarian.net/227251469/buildlog_ubuntu-xenial-amd64.deja-dup_34.1bzr1556~ubuntu16.04.1_BUILDING.txt.gz
[14:05] <mterry> kenvandine, so I'm claiming you've got something weird going on.  Although I don't know how it could affect your second laptop/new user
[14:05] <sil2100> cyphermox, kenvandine: first, the situation: as you know, since gcc5 some of our CI Train project stopped being able to dual land due to ABI changes (symbols etc.)
[14:06] <sil2100> cyphermox, kenvandine: so some of those projects decided on providing a debian/rules rule that auto-generates the control file and picks the right symbols file for the selected distro, changing the sonames etc. if needed
[14:06] <cyphermox> eep
[14:07] <sil2100> cyphermox, kenvandine: anyway, those are in the archive... but now we have a new project that wants to start doing the same, but
[14:07] <sil2100> I found an issue with it, and just want to know if you guys find this bad as much as I do
[14:08] <cyphermox> sounds bad to me already
[14:08] <sil2100> cyphermox, kenvandine: the new project that wants to do that basically also does the same magic as the others, but besides changing the symbols and control file, it also changes the content's library version (4.3.0 for vivid, 5.0.0 for xenial+) - the problem is, that due to how we do dual landings, both vivid and xenial *packages* would have one version number: 5.0.0
[14:09] <sil2100> Meaning, the package for vivid versioned 5.0.0 would provide the 4.3.0 library in it
[14:09] <sil2100> While the same version (just with the CI Train version part changed to 16.04 as for all dual-landings) would have 5.0.0 in it
[14:10] <sil2100> For xenial
[14:10] <cyphermox> why say it's 4.3 if it's not?
[14:10] <sil2100> cyphermox: well, yeah, it's evil, I didn't like the idea but Steve and some other people agreed on that hack to allow dual-landing for people
[14:10] <kenvandine> evil
[14:11] <sil2100> cyphermox: I guess the reason is, since there's ABI breakage between releases, the upstream doesn't want the sonames to be the same for both
[14:12] <sil2100> So they originally bumped the wily/xenial version to 5.0.0
[14:12] <cyphermox> sil2100: if they break ABI, the so version should change
[14:12] <cyphermox> that applies to vivid too
[14:12] <kenvandine> yeah, i'm not sure i understand how it helps anything
[14:12] <cyphermox> could they not just SRU things ?
[14:13] <sil2100> cyphermox: the ABI breakage is from the toolchain side
[14:13] <sil2100> So it's not something they caused
[14:13] <cyphermox> how so?
[14:13] <sil2100> They still build from one source tree
[14:13] <cyphermox> I think it would be best to see the code
[14:13] <sil2100> It's C++11, due to gcc5 the symbol files changed between vivid and wily/xenial
[14:14] <cyphermox> that doesn't make it a different so version though, if it's just that the symbols are named differently
[14:15] <cyphermox> ie. you still might have new API in the library, it's just that the symbols file will look one way for vivid because gcc < 5, and another way for wily/xenial because gcc >= 5
[14:15] <sil2100> cyphermox: yes, they're named differently, so there's no compatibility between libraries then, right? Since a lib build against one will expect different symbols coming from the library
[14:16] <cyphermox> I mean, there won't be a difference between the symbol names as they are in vivid right now and the new version of that package.
[14:16] <cyphermox> (or what they might have been if the package existed already and what it will now be)
[14:18] <sil2100> You mean, no difference in symbols between compiling against gcc4.9 and gcc5?
[14:28] <jamespage> how big is the filesystem that supports PPA based builds?  I'm hitting what I think is a freespace issue in this PPA - https://launchpad.net/~openstack-ubuntu-testing/+archive/ubuntu/ceph-sru/+packages
[14:28] <jamespage> but can't tell for sure...
[14:29] <cjwatson> jamespage: 60GiB
[14:29] <cyphermox> sil2100: what I mean is there is obviously a difference between compiling with 4.9 and 5, but vivid should always compile with 4.9, so you shouldn't have to jump through hoops messing with soname or sover, things should just "work"
[14:30] <cyphermox> or did I get the gcc version used in vivid wrong? ;)
[14:30] <cjwatson> jamespage: it's the same for PPAs and Ubuntu builds
[14:30] <jamespage> cjwatson, okay
[14:30]  * jamespage scratches his head
[14:30] <cjwatson> jamespage: doesn't look like a disk issue to me
[14:31] <cjwatson> jamespage: cc1 is being SIGKILLed, which implies OOM
[14:31] <cjwatson> (more or less)
[14:31] <cjwatson> jamespage: is this an extremely large translation unit?
[14:32] <dobey> mwhudson: you around?
[14:33] <sil2100> cyphermox: well, things don't really work, as the fact is: you have different symbols exported in one distro and different in the other, which means that the soname should be bumped
[14:33] <sil2100> (bumped = changed)
[14:34] <sil2100> cyphermox: at least that's what I have always been taught
[14:34] <sil2100> cyphermox: so now, building the same package on two different distros, with the package providing a symbols file - people now look for a way to build those two at once from one source tree
[14:35] <sil2100> cyphermox: since you at least need to provide 2 different symbols files for vivid and wily/xenial+
[14:35] <sil2100> Although everyone doing this anyway changes the soname as they're no longer binary compatible
[14:35] <sil2100> I mean, ABI-compatible
[14:37] <cyphermox> sil2100: it's only relevant if the code in the library changes. if what you're seeing is one distro giving out symbols named in a particular way (mangled some way), and another distro mangled a different way, you still have the same API/ABI, it's just toolchain specifics?
[14:37] <zzarr> hello! how do I avoid this message when building an application for generic Ubuntu ARM? error: Unknown module(s) in QT: bluetooth
[14:38] <cyphermox> in other words, building on vivid or on xenial should work without any changes as long as they're not using magic that is only available in gcc5, provided they just use the default compiler for the release
[14:38] <cyphermox> what you'll hit after that is just how dh will parse and compare the symbols generated
[14:39] <zzarr> cyphermox, did you respond to my question?
[14:39] <sil2100> cyphermox: yes, and that was the main point of doing the hack with debian/rules, but they also change the soname as this was recommended by someone from the ubuntu-archive team
[14:39] <dobey> doko: you around?
[14:39] <sil2100> But that's irrelevant to the original question ;)
[14:39] <cyphermox> zzarr: no, that was for sil2100
[14:40] <zzarr> okey, I was confused ;)
[14:40] <dobey> zzarr: install the bluetooth qt module?
[14:40] <zzarr> yes, but how do I do that?
[14:40] <cyphermox> sil2100: I don't have the context for the soname change, I guess, unless it's to support upgrades correct, in which case what is meant is the name of the library.
[14:41] <dobey> libqt5bluetooth5 - Qt Connectivity Bluetooth module
[14:41] <killall> Hello, i need some help, i have 2 usb devices purchased in diferent times and one works and the other does not work. Booth work in windows.   SONiX USB Device in lsusb detects as   0c45:8419 Microdia
[14:41] <zzarr> dobey, I know, but where do I install it?
[14:42] <killall> this is making me crazy i dont know if i have to mod the driver or not
[14:42] <zzarr> in the emulator?
[14:42] <dobey> killall: #ubuntu is the support channel
[14:42] <dobey> zzarr: i don't know how you are building things, but yes, wherever you are getting that error is obviously where it needs to be installed
[14:44] <zzarr> I get the error here (compiler output) The process "/home/zzarr/.config/QtProject/qtcreator/ubuntu-sdk/ubuntu-sdk-15.04-armhf/qt5-qmake-arm-linux-gnueabihf" exited with code 3.
[14:46] <zzarr> dobey, I installed the package, but it did not help
[14:47] <sil2100> cyphermox: well, I guess it had to be done that way in wily, since let's say you have a library foo with an soversion of 2 in wily compiled against gcc4.9, then gcc5 got uploaded and foo had to be rebuilt - without the soversion changing, apps linked against soversion 2 would stop working
[14:51] <dobey> zzarr: you are trying to write an app that uses that module, for the phone?
[14:52] <sil2100> cyphermox: since it all happened in one series
[14:53] <dobey> zzarr: you can't, you'll have to ship the library in your own package, and even when doing so i don't think you'll be able to use it anyway
[14:53] <zzarr> dobey, no it's for a generic device with a bluetooth dongle
[14:53] <dobey> zzarr: but you're building it using the phone sdk
[14:54] <zzarr> how do I do that (it might just work)
[14:54] <zzarr> okey
[14:54] <dobey> are you trying to build a .deb package?
[14:54] <zzarr> simply downloading the code and building it, thanks
[14:54] <zzarr> no, it's installed in opt
[14:55] <zzarr> thanks for the heads up dobey :D
[14:55] <dobey> deb packages can install in opt. cf the "for purchase" apps in software-center
[14:56] <zzarr> true, but so far I've just installed the project in opt directly from the SDK
[14:57] <kenvandine> mterry, no idea what's going on... it fails consistently for me in sbuild :/
[14:57] <dobey> ubuntu-sdk isn't building in an emulator, it's cross-compiling; and the ubuntu-sdk chroots have further restraints since they're for the phone
[14:57] <kenvandine> mterry, i can't look at it today though, sorry
[14:58] <mterry> kenvandine, ok.  Maybe I can bug another desktop person and that would be a good 3rd (4th if we could LP) opinion
[14:58] <kenvandine> mterry, yeah... sorry :)
[14:58] <zzarr> dobey, okey, so that's why it's not working for me
[14:58] <mterry> seb128, know anyone that wants to review a deja-dup branch (to drop python2 from image)?
[14:59] <dobey> zzarr: i'd suggest just making your own chroot for cross-compiling it in, or building on armhf hardware directly
[14:59] <mterry> kenvandine, no worries  :)  sorry it was such a hassle
[14:59] <seb128> mterry, python ... maybe try didrocks?
[14:59] <mterry> didrocks, hello  :)
[14:59]  * didrocks whistles
[15:00] <didrocks> mterry: ok ok, I'm using deja-dup (and still swearing against bad volumediff sometimes) :p but I thing I owne you that ;)
[15:00] <mterry> didrocks, heh
[15:01] <mterry> didrocks, https://code.launchpad.net/~mterry/deja-dup/no-python2/+merge/276875
[15:01] <didrocks> mterry: for tomorrow is fine?
[15:01] <mterry> didrocks, kenvandine looked at it, but saw some weird test failures that I and LP couldn't reproduce.  So I'm hoping for another sanity check.  Yeah, tomorrow is fine
[15:02] <didrocks> ah, interesting, yeah, will do
[15:02] <didrocks> seb128: there is some vala in this python, want to remind me some Unity0 time? :)
[15:03] <mterry> didrocks, this is vala changes to allow us to drop a python2 package from the image
[15:03] <mterry> didrocks, seb128 tricked you
[15:03] <mterry> not intentionally  :)
[15:03] <seb128> didrocks, yeah, like in good old times!
[15:04] <didrocks> I don't see any clutter dependency though, not fully good old times! :)
[15:04] <didrocks> mterry: yeah, seems so :p
[15:04] <zzarr> okey, I'll make my own chroot in that case :)
[15:05] <zzarr> thanks dobey, I have to go
[15:12] <pitti> Laney: ah, did you restart the dbus tests?
[15:12] <pitti> Laney: I think I overzealously killed a batch before, I thought they were still hanging; thanks for fixing those!
[15:13] <pitti> (if you didn't restart them, I will)
[15:13] <pitti> but I need to sort out the "apt-get source needs to download the -release version" issue
[15:14] <cpaelzer> pitti, hi I'm working with autopkgtest for the first time and wonder if there is a way to let adt-run invoke the adt-virt-qemu with -smp >1?. Google neither made me happy about "why not" nor "how to"
[15:14] <cpaelzer> pitti, test can't run in schroot which would be the more obvious solution :-/
[15:14] <pitti> cpaelzer: see man adt-virt-qemu
[15:14] <pitti> cpaelzer: -c N
[15:14] <cpaelzer> pitti, to bad I search for smp in the doc - thanks!
[15:15] <cpaelzer> google needs to learn what I need and not what I ask - so do manpages (or read them from beginning to end)
[15:15] <pitti> heh
[15:16] <didrocks> ximion: hey, not sure if you saw my new PR so that we can ensure a more consistent experience for people deploying appstream: https://github.com/ximion/appstream-dep11/pull/2. Hope that helps!
[15:16] <pitti> cpaelzer: you can also pass through arbitrary qemu options (--qemu-options) for the stuff that isn't exposed directly
[15:16] <ximion> didrocks: saw it, will apply it soon :-) Looks pretty good :)
[15:17]  * ximion will work on getting rid of X-Source-Checksum in DEP-11 files soon
[15:17] <didrocks> good :)
[15:17] <cpaelzer> pitti, yeah just saw it as I started to fully digest man adt-virt-qemu - thanks
[15:19] <jamespage> cjwatson, quite possibly (re is this an extremely large translation unit?)
[15:20] <jamespage> cjwatson, how much memory do we give builders these days?
[15:23] <cjwatson> jamespage: 4GiB
[15:24] <cjwatson> jamespage: can you split the translation unit?
[15:24] <jamespage> cjwatson, erm feeling stupid - how would I go about doing that?
[15:24] <cjwatson> jamespage: we've talked about bumping to 8GiB, but it will take a while, and it still makes sense to look for approaches to make the build less unreasonable
[15:25] <cjwatson> jamespage: erm, depends?  look at the .c file in question, see if there's some way to split it up if it's enormous
[15:26] <cjwatson> jamespage: may be lots of complex macro expansion or something
[15:26] <jamespage> cjwatson, 11k lines
[15:26] <cjwatson> that's pretty big
[15:26] <cjwatson> jamespage: another approach you can try is to use less parallelisation in your build
[15:27] <jamespage> cjwatson, yeah I was thinking that
[15:27] <jamespage> gonna take a loooonnggg time to build now...
[15:27] <cjwatson> jamespage: well, you could try initially just dropping it to 2
[16:16] <mapreri> can somebody explain me why this is not building?  the b-d it's complaining about looks available to me.. https://launchpad.net/ubuntu/+source/squashfs-tools/1:4.3-3
[16:20] <pitti> Section: universe/libdevel
[16:20] <seb128> mapreri, that package is in main
[16:20] <seb128> it can't use a build-depends in universe
[16:20] <pitti> mapreri: liblz4-dev is in universe
[16:21] <mapreri> ok, i got fooled by the "main" label on https://launchpad.net/ubuntu/+source/lz4/0.0~r131-1 ..
[16:21] <pitti> can't this use lzma?
[16:22] <mapreri> no idea, i've no releshionship with it other than being involved on a reverse of a reverse of a reverse dep :)
[16:23] <mapreri> but the why there is a "component: main" in https://launchpad.net/ubuntu/+source/lz4/0.0~r131-1 ... :S
[16:26] <infinity> mapreri: LP display misfeature.  It came from main in Debian.  If you look at the publishing info on the right, is says universe.
[16:26] <infinity> s/is says/it says/
[16:28] <mapreri> yeah, i figured.. that's confusing, but anyway..  yes guess squashfs-tools can be built without lz4, removing support for it; it got added some releases ago, but it's an optional flag in d/rules
[16:30] <cjwatson> misfeature> oh, I missed a bit when I tried to remove that from the UI.
[16:39] <pitti> cjwatson: hm, https://launchpad.net/ubuntu/xenial/+queue?queue_state=0 lost its components/section displays
[16:39] <pitti> worth a bug report, or known already?
[16:40] <cjwatson> pitti: expand the items
[16:40] <pitti> cjwatson: oh, silly me -- thanks
[16:41] <cjwatson> pitti: you'll see the component/section directly on source uploads, but for binary uploads they're per-binary
[16:41] <pitti> cjwatson: yeah, of course -- I was just confused for a sec
[18:12] <robru> pitti: correct that python3-kombu is not in trusty
[20:02] <sladen> tkamppeter: yo
[20:21] <mwhudson> dobey: hi
[20:26] <dobey> mwhudson: hey. i was wondering if you had any idea what was going on in this build failure on ppc64el? https://launchpadlibrarian.net/227153468/buildlog_ubuntu-xenial-ppc64el.pay-service_15.10%2B16.04.20151120.2-0ubuntu1_BUILDING.txt.gz
[20:26] <dobey> mwhudson: it's happening only on ppc64el on xenial; everything else built fine
[20:27] <dobey> (and exact same code built fine on vivid)
[20:27] <dobey> hoping it's something we can fix easily/quickly, but my gccgo skills are limited, especially regarding hardware i don't have any direct access to
[20:58] <mwhudson> dobey: oh hm
[20:59] <mwhudson> dobey: looks like https://github.com/golang/go/issues/13375
[21:01] <mwhudson> yeah very much like that
[21:03] <mwhudson> dobey: what's the actual care level on this? :-)
[21:03] <mwhudson> we'll be uploading go 1.5.2 within a week or two and i'll try to make sure this is fixed there
[21:04] <mwhudson> dobey: don't you have access to the ppc64el porter box?
[21:04] <mwhudson> oh heh no xenial chroot anyway
[21:07] <dobey> i don't
[21:07] <dobey> well, if i do, i don't know anything about porter boxes :)
[21:10] <dobey> mwhudson: it's not super urgent, but would like a fix asap. any idea on when exactly that fix would land?
[21:10] <tkamppeter> sladen, you are working with fonts?
[21:11] <sladen> tkamppeter: some times
[21:11] <sladen> tkamppeter: when the mood takes me
[21:12] <tkamppeter> sladen, there seems to be used some fonts with unclear copyright in Linux, see https://bugzilla.redhat.com/show_bug.cgi?id=1284215.
[21:14] <tkamppeter> So Hin-Tak Leung, the reporter of this bug asked me to forward this to the font maintainers of Ubuntu/Canonical to check whether Ubuntu contains any fonts with the same copyright problem.
[21:14] <tkamppeter> sladen, so I want to ask you to check this.
[21:18]  * sladen looking ... tkamppeter 
[21:21] <sladen> tkamppeter: thank you for the heads up
[21:37] <mwhudson> dobey: week or two?
[21:37] <mwhudson> oh i see "exactly"
[21:37] <mwhudson> no
[21:37] <mwhudson> :-)
[21:37] <dobey> mwhudson: any idea if it would be trivial to throw the patch in the existing package and do a quick upload?
[21:38] <mwhudson> dobey: probably
[21:38] <dobey> mwhudson: can i bribe you to do that? :)
[21:38] <mwhudson> depends on how quickly ~ubuntu-sponsors react
[21:38] <mwhudson> dobey: i'm still waiting for my last "quick fix" to get sponsored...
[21:38] <dobey> oh, you don't have upload privs?
[21:39] <mwhudson> no
[21:39] <dobey> what source package is that in?
[21:39] <mwhudson> it would also be good to test that the fix actually helps, which means some fooling around with ppas i guess
[21:40] <mwhudson> dobey: https://bugs.launchpad.net/ubuntu/+source/golang/+bug/1501651
[21:41] <dobey> mwhudson: oh, that upload faild to build on amd64 and i386
[21:41] <dobey> https://launchpadlibrarian.net/226248080/buildlog_ubuntu-xenial-amd64.golang_2%3A1.5.1-0ubuntu3_BUILDING.txt.gz
[21:42] <dobey> mwhudson: with the unexpected relocation error! :)
[21:42] <mwhudson> no, that was the previous one
[21:42] <mwhudson> i'm fairly sure
[21:42] <mwhudson> and yes, can we get the binutils people to stop changing things please
[21:42] <dobey> ikr
[21:43] <mwhudson> yes, that's ubuntu3, i'm waiting for someone to upload ubuntu4
[21:43] <dobey> oh ok
[21:44] <dobey> infinity, slangasek: ^^ can one of you sponsor the latest patch on bug #1501651 please?
[22:35] <slangasek> dobey, mwhudson, infinity: done
[22:35] <mwhudson> slangasek: thanks!
[22:35] <Unit193> slangasek: Is it the weekend yet? :)
[22:36] <dobey> thanks!
[22:37] <sarnold> Unit193: .. it's like you can read minds :)
[22:37] <Unit193> sarnold: I can't even read my own mind...
[22:37] <sarnold> hehe
[22:44] <mwhudson> slangasek: whaat https://launchpadlibrarian.net/227405312/buildlog_ubuntu-xenial-amd64.golang_2%3A1.5.1-0ubuntu4_BUILDING.txt.gz
[22:45] <mwhudson> specifically "E: Failed to fetch http://ftpmaster.internal/ubuntu/pool/main/g/gettext/libasprintf0v5_0.19.4-1ubuntu3_amd64.deb  Temporary failure resolving 'ftpmaster.internal'
[22:45] <mwhudson> "
[22:45] <mwhudson> i guess that means retry?
[22:45] <MrBIOS> lols
[22:46] <cjwatson> mwhudson: yes, must have been temporary network trouble particularly given that subsequent fetches succeeded
[22:46] <mwhudson> can someone hit retry on https://launchpad.net/ubuntu/+source/golang/2:1.5.1-0ubuntu4/+build/8335506 ?
[22:46] <cjwatson> mwhudson: retried
[22:46] <mwhudson> thanks
[22:46] <cjwatson> was already going there :)
[22:46] <mwhudson> heh
[22:46] <slangasek> not the first such resolution failure I've seen in the past week, hmm
[22:47] <mwhudson> cjwatson: service!