[12:10] <doko> seb128, Laney, didrocks: http://people.canonical.com/~ubuntu-archive/component-mismatches-proposed.svg fonts-smc was split. Please could you review the licenses and subscribe desktop-bugs to the split packages?
[13:28] <andreas> sil2100: hi, the trusty version of ubuntu-advantage-tools failed to build: https://bugs.launchpad.net/ubuntu/+source/ubuntu-advantage-tools/+bug/1719671/comments/56
[13:28] <andreas> is it because of universe?
[13:31] <sil2100> andreas: hey, yeah, for a main package an universe package won't really be visible
[13:31] <sil2100> I mean, well
[13:37] <andreas> all ppa builds I did before didn't show this problem
[13:37] <andreas> even our daily build ppa
[13:37] <andreas> and how did the other packages build? The ua-tools ones that are in proposed for x, z and a?
[13:40] <sil2100> andreas: I guess I need to see first what's happening before I start talking
[13:40] <sil2100> eh
[13:40] <andreas> :)
[13:41] <sil2100> Anyway, I'll take a look at this in some moments
[13:42] <andreas> thanks
[13:49] <slashd> sil2100, andreas seems like universe hasn't been enable in trusty but xenial yes --> http://pastebin.ubuntu.com/25910954/
[13:51] <sil2100> Anyway, clearly I made a mistake and didn't take notice that u-a-t is actually a main package
[13:51] <cjwatson> that changed in xenial, but trusty uses the old model
[13:52] <cjwatson> right
[13:52] <cjwatson> (sorry, I was a little further back in scrollback without noticing)
[13:52] <andreas> these build deps are only used for tests at buildtime, not at runtime
[13:52] <andreas> does that help?
[13:52] <cjwatson> irrelevant
[13:52] <cjwatson> >>> lp.load('/ubuntu/trusty').strict_supported_component_dependencies
[13:52] <cjwatson> True
[13:52] <cjwatson> >>> lp.load('/ubuntu/xenial').strict_supported_component_dependencies
[13:52] <cjwatson> False
[13:53] <andreas> I mean, in terms of policy: a main package having build-deps from universe
[13:53] <cjwatson> we made the policy more liberal in xenial, but for trusty it does not help
[13:54] <andreas> then let's reject that trusty sru
[13:54] <cjwatson> you could probably just disable those tests for trusty
[13:55] <andreas> yeah, would that be acceptable from the sru point of view?
[13:55] <andreas> we can show them in the daily build ppa
[13:55] <sil2100> andreas: I told you last time it was - if we can't run the tests on a given platform then I'm generally good to skip
[13:55] <sil2100> It's just that if a series can run the tests then they shouldn't be disabled
[13:56] <sil2100> slashd: could you re-upload u-a-t to trusty with the tests disabled and test deps removed?
[13:56] <slashd> sil2100, sure can take care of it
[14:00] <sil2100> slashd: thanks
[14:00] <slashd> sil2100, thanks to you
[15:39] <LargePrime> does anyone know if https://launchpad.net/~network-manager has a #irc
[15:58] <nacc> !alis | LargePrime
[16:05] <cyphermox> LargePrime: #nm
[16:34] <LargePrime> thanks nacc cyphermox
[16:43] <nacc> LargePrime: yw
[19:46] <slangasek> stgraber, infinity, kees, mdeslaur: TB 15 minute warning
[19:47] <mdeslaur> ack
[20:31] <bdmurray> slangasek: release upgrade failure due to having apt and apt-transport-https:i386 installed. That seems crazy right?
[20:31] <slangasek> haha
[20:32] <slangasek> bdmurray: yes, that's a crazy state.  maybe it's our bug that the system got in that state to begin with, but the failure to upgrade from it is not a bug
[20:41] <NewGnuGuy> What is the process for moving a package from multiverse to universe if the latest version is fully freely licensed? Asking specifically about the redeclipse package which is licensed under a combination of zlib and CC-BY-SA and which is in the main repository in Debian.
[20:41] <jbicha> NewGnuGuy: file a bug and subscribe the ubuntu-archive team
[20:42] <NewGnuGuy> Which bug tracker should I file under?
[20:44] <jbicha> you can run   ubuntu-bug redeclipse
[20:44] <jbicha> or https://launchpad.net/ubuntu/+source/redeclipse/+filebug
[20:49] <ekristen> I'm trying to compile a custom version of python for ubuntu, and I've basically used the .dsc to get all the patches etc, and then dropped in the customizations I need to make, when I compile though the binary behaves differently, the stock python interpretter searches for shared objects with suffixing everything with x86_64-linux-gnu
[20:50] <ekristen> while my custom binary does not, and I am unable to figure out how to make my binary search for shared objects the same way
[20:51] <mwhudson> are the autopkgtest queues actually going down at all?
[20:52] <xnox> mwhudson, yes as fast as fed normalising QE balance sheet.
[20:53] <xnox> mwhudson, it was 14k now it's like 13.9k and things are moving, it's just new things keep being added.
[20:53] <xnox> too.
[20:54] <nacc> ekristen: how are you compilinng?
[20:55] <ekristen> nacc: I was using dget -u to pull down everything, then I modified the files necessary, then ran dpkg-buildpackage, then tested the resulting binary
[20:56] <ekristen> nacc: it compiles with what I need, it just doesn't search shared objects teh same way. I tried also to compile directly from source from python too, with the same behavior
[20:57] <ekristen> I'm sure it's something simple, a small patch or configure option that tells python to look for shared objects in a few different ways, but I cannot seem to figure out where that is setup.
[20:57] <nacc> ekristen: the binary or the .deb?
[20:59] <ekristen> nacc: ultimately I'm trying to compile the python interpretter with some custom changes, and install it on ubuntu, ideally I wanted to be able to create a .deb package that contains the binary as well. For my changes to work I've passed the disable-shared, and added my library references to LDFLAGS and CFLAGS, I've tried compiling the binary with and without dpkg-buildpackage.
[20:59] <ekristen> It makes the .deb file and the python interpreter with teh changes I need, however when I go to import a module like `gi` for example
[21:00] <ekristen> my custom interpreter looks for _gi.so and that's it
[21:00] <nacc> ekristen: i'm asking if you tested the binary (e.g. ./...python) or the binanry package (the .deb)
[21:00] <ekristen> however ubuntu's 2.7 python interpetter looks for _gi.so and _gi.x86_64-linux-gnu.so
[21:00] <ekristen> nacc: both
[21:00] <ekristen> I've tested both
[21:02] <nacc> ekristen: i'm curious what changes you are doing?
[21:08] <mwhudson> xnox: yeah i know things are being processed, it's just the rate of that vs the rate of things being added that i wasn't sure of
[21:09] <xnox> mwhudson, we are one cloud down.
[21:09] <mwhudson> still?
[21:09] <infinity> No.
[21:09] <xnox> infinity, it keeps deing taking out the lcy builders for 6 hounts.
[21:09] <xnox> infinity, so after 28 jobs, we are one cloud down for 5 hours.
[21:09] <infinity> xnox: They're being reset more often than that.
[21:09] <xnox> then they come back.
[21:09] <ekristen> nacc: hard to explain, some legacy stuff inside my company for a python gtk app we have
[21:09] <infinity> xnox: You're operating on old info.
[21:10] <nacc> ekristen: ok, i'm looking at hte source myself to see
[21:10] <infinity> (Yes, lcy isn't in perfect state, but it's not as dire as that)
[21:10] <xnox> infinity, i'm going by the info, from someone with autopkgtest data, from about two hours ago.
[21:10] <xnox> infinity, there is a problem with lcy when booing bionic guests.
[21:10] <xnox> (all good with xenial guests)
[21:10] <infinity> 11:00 < Laney> nah, I'll make the reset job run hourly so we limp along a bit
[21:11] <infinity> xnox: Trust me, I'm aware of all of this.
[21:11] <xnox> infinity, ok.
[21:11] <infinity> xnox: They're resetting more often than every 6h, as I said.
[21:11] <xnox> slangasek, ^^^
[21:11] <xnox> infinity, i've been told fake news again then!
[21:11] <infinity> xnox: Not fake, just old.
[21:12] <infinity> xnox: Just irksome when I tell you that it's old news, you keep arguing. :P
[21:12] <ekristen> nacc: thanks, any help would be greatly appreciated
[21:14] <nacc> ekristen: i guess my first attempt would be to use a PPA or a good build environment (e.g., sbuild, clean LXD) and see if you can rebuild the existing srcpkg with the same beahvior?
[21:14] <slangasek> xnox: it was not fake news when I told you
[23:41] <blahdeblah_> cpaelzer: When you're around, would you have a few minutes to talk about the solutions you investigated when fixing https://bugs.launchpad.net/ubuntu/+source/libvirt/+bug/1620407 ?