=== wgrant__ is now known as wgrant
[04:35] <slangasek> doko: how does new cairocffi not require an FFe?
[04:37] <tsimonq2> slangasek: On the safe side before sponsoring something... new translations don't need an FFe right?
[04:38] <slangasek> tsimonq2: they do not
[04:38] <tsimonq2> Ok, thanks slangasek
[10:23] <doko> LocutusOfBorg: Binary only movements to main
[10:23] <doko>  -----------------------------
[10:23] <doko>  o libturbojpeg libturbojpeg0-dev                              {libjpeg-turbo}
[10:23] <doko>    [Reverse-Depends: Rescued from libjpeg-turbo, libturbojpeg0-dev]
[10:23] <doko> having this legacy API in main is something I want to really avoid :-/
[10:31] <LocutusOfBorg> doko, I don't get it, if it is the new binary I introduced, I think it can live in universe...
[10:32] <doko> Package: libturbojpeg0-dev
[10:32] <doko> Conflicts: libjpeg-turbo8-dev
[10:32] <doko> why?
[10:35] <LocutusOfBorg> because I would like to make openjpeg syncable after 18.04, so I'm preparing the conflicts fields
[10:35] <LocutusOfBorg> turbojpeg, whatever is called :)
[10:35] <doko> LocutusOfBorg: no, you can't sync it in any case
[10:36] <doko> I explained it to you before.
[10:36] <doko> Ubuntu has the jpeg8 compat bits turned on, Debian has jpeg6
[10:36] <LocutusOfBorg> I mean, sync the package names, with the jpeg compatibility layer added
[10:36] <LocutusOfBorg> yep, sure
[10:36] <LocutusOfBorg> but at least we can have the "progs" and other sub-binaries in sync
[10:37] <doko> but it doesn't mean that we should support this api everywhere
[10:37] <LocutusOfBorg> I don't parse this sentence
[10:38] <LocutusOfBorg> maybe we can ask debian to switch to jpeg8 too
[10:38] <doko> this is a legacy API, please read the docs
[10:38] <doko> so I'll remove the conflicts now
[10:40] <LocutusOfBorg> sorry I'm lost in the ldc merge, I don't follow exactly
[10:40] <LocutusOfBorg> I'm happy to read them if you provide a link, and feel free to remove the conflict if you find it useless
[10:53] <doko> it's called README, found in the sources
[10:55] <LocutusOfBorg> will look while fixing ldc (I hope)
[12:39] <LocutusOfBorg> doko, the change in turbojpeg broke dcm2niix /build/dcm2niix-1.0.20170818/console/nii_dicom.cpp:44:13: fatal error: turbojpeg.h: No such file or directory
[12:41] <xnox> LocutusOfBorg, are you aware of Ubuntu feature freeze policy at all? just like in debian one should not be introducing new packages, merging new upstream releases, doing package reorgs, transitions, etc.
[12:41] <doko> LocutusOfBorg: does this package build with the standard jpeg?
[12:41] <xnox> LocutusOfBorg, one should only focus on bug-fixes.
[12:41] <xnox> LocutusOfBorg, can you not wait until after 17.10 ships?
[12:42] <LocutusOfBorg> xnox, I don't think I reorganized stuff, and I think I didn't break Ffe...
[12:42] <LocutusOfBorg> sure, a lot of stuff is waiting for 17.10, right now I'm syncing gcc-7 build fixes
[12:42] <LocutusOfBorg> doko, no
[12:42] <LocutusOfBorg> it is using headers only provided by turbojpeg.h
[12:45] <LocutusOfBorg> it can build without turbojpeg support
[12:50] <LocutusOfBorg> doko, it uses something like "tjDecompress2"
[12:56] <doko> can, or cannot?
[12:57] <LocutusOfBorg> it can build without that support, it cannot use jpegturbo without that header
[12:57] <LocutusOfBorg> so, if you want to remove that feature, go ahead, I don't know how much of features it will loose
[13:37] <doko> I'm still trying to find out why the new packages are pulled into main, even with out the Conflicts
[14:01] <xnox> slangasek, shouldn't libgles1-mesa | 17.0.7-0ubuntu0.16.04.2 | xenial-proposed  | all be published into xenial such that it is installable with libglapi-mesa that is at 17.* version in xenial-updates?
[14:23] <sdeziel> hello *, I'd like to know if there is something to do to move tor from xenial-proposed to -updates? https://people.canonical.com/~ubuntu-archive/proposed-migration/xenial/update_excuses.html#tor
[14:24] <sdeziel> it currently says it's blocked due to a freeze
[14:27] <LocutusOfBorg> sdeziel, xenial might take some days more, because $LTS
[14:27] <LocutusOfBorg> I think next time a RT member is around, he will release it
[14:28] <sdeziel> LocutusOfBorg: OK, I didn't know the baking period was longer on LTS
[14:28] <LocutusOfBorg> it is at least one week, with no upper bound I would say
[14:28] <LocutusOfBorg> probably it isn't longer, maybe no RT folk has got time to look and release it
[14:28] <LocutusOfBorg> but it wouldn't surprise me to see a time higher for LTS releases
[14:29] <apw> sdeziel, everything in stables is "blocked for freeze"
[14:29] <LocutusOfBorg> *an higher time
[14:29] <apw> sdeziel, that is not the report we use to work out what to release
[14:29] <LocutusOfBorg> because the archive is closed
[14:30] <sdeziel> I'm not sure I know what stables refers to in that context
[14:30] <apw> sdeziel, stables == "not the development release"
[14:30] <LocutusOfBorg> something that has been released
[14:30] <sdeziel> ah
[14:31] <sdeziel> this specific package comes with security fixes which is why I'd rather have it land in -updates sooner than later
[14:31] <apw> sdeziel, if it has security fixes it likely should have been built in the security PPA and released to -security, but
[14:31] <LocutusOfBorg> maybe pinging the person who accepted it is the best chance you have
[14:31] <apw> sdeziel, it looks to be ready to release to my eye
[14:31] <sdeziel> apw: it's in universe so I'm not sure that applies then
[14:31] <sdeziel> ?
[14:32] <LocutusOfBorg> sdeziel, universe has community providing security fixes
[14:32] <LocutusOfBorg> and people looking at them
[14:32] <LocutusOfBorg> same as main, just changes *who* provides support
[14:33] <LocutusOfBorg> and security updates have higher priority, automatic installation, so for CVE fixes better use them
[14:33] <sdeziel> LocutusOfBorg: OK, I thought that the security PPA was only for packages in main, my bad
[14:33] <LocutusOfBorg> maybe you can ask on #ubuntu-hardened
[14:33] <apw> that may well be true, sanyhow i can release that
[14:33] <LocutusOfBorg> but for CVEs always better ask to security team before trying a microSRU
[14:33] <sdeziel> apw: that would be nice indeed
[14:34] <sdeziel> LocutusOfBorg: duly note
[14:34] <sdeziel> there will be more of those now that the package is using the upstream LTS version so thanks for providing input on the process
[14:34] <apw> sdeziel, on its way
[14:34] <sdeziel> apw: thanks!
[14:52] <stgraber> apw, Laney, slangasek: can one of you please review https://bugs.launchpad.net/ubuntu/+source/lxc/+bug/1715278?
[14:52] <ubot5> Ubuntu bug 1715278 in lxc (Ubuntu) "[FFe] LXC 2.1" [Undecided,New]
[14:52] <stgraber> it's been waiting for two weeks now :(
[14:59] <apw> stgraber, if it is all backwardscompatible as claimed it seems ok to my eye
[15:00] <jbicha> sdeziel: there are -security updates for universe packages, I've done a few
[15:00] <stgraber> apw: yeah, lib is fully backward compatible and CLI is too. Config is where we made changes but it accepts the old config and issues warnings for things that will go away in 3.0
[15:01] <jbicha> they don't publish USNs for universe -security updates but except for that, I believe it's the same
[15:01] <sdeziel> jbicha: yeah, that's probably what got me confused
[15:03] <beisner> hi bdmurray - i think this one is verif done for xenial-proposed.  can you do the honors into xenial-updates?  https://bugs.launchpad.net/neutron/+bug/1668410
[15:03] <ubot5> Ubuntu bug 1668410 in neutron "[SRU] Infinite loop trying to delete deleted HA router" [Medium,In progress]
[15:05] -queuebot:#ubuntu-release- New binary: libxbean-java [amd64] (artful-proposed/universe) [4.5-6] (no packageset)
[15:06] <apw> stgraber, will we have 3.0 in BB, and how will xenial upgrades be handled
[15:07] <stgraber> apw: we will indeed have 3.0 in the next LTS. Upstream ships a lxc-update-config tool which will convert the configs. I expect we'll update the tool a bit to allow for a "-a" flag and then show a debconf warning telling users to run that post-upgrade.
[15:07] <stgraber> apw: we could auto-run it, but the problem is that we don't necessarily know where their containers are :)
[15:08] <apw> it sounds like you need 2.1 in xenial ... too
[15:09] <apw> stgraber, ^
[15:14] <stgraber> apw: it will be in -backports for those interested but I don't believe we want to push a non-LTS LXC release down to xenial. Xenial users should stick to 2.0.x and when doing the LTS to LTS upgrade, we'll have them run lxc-update-config to upgrade to the new format.
[15:15] <stgraber> it's also going to be limited to actual LXC users. Anyone who uses LXD won't have to deal with that as LXD will auto-generate the right format based on liblxc versions.
[15:15] <apw> stgraber, ack thanks
[15:16] <apw> stgraber, approved (details in bug)
[15:16] <stgraber> apw: thanks
[15:18] <bdmurray> apw: slangasek gives me the impression you and infinity are working on fixing secureboot kernels shipping two vmlinuz files is that correct?
[15:18] -queuebot:#ubuntu-release- New: accepted libxbean-java [amd64] (artful-proposed) [4.5-6]
[15:21] <smoser> infinity, you are sru team member...
[15:21] <smoser> for today
[15:21] <smoser> cloud-init has xenial and zesty uploads in queue that are in need of processing
[15:22] <sil2100> smoser: I can look at this in a moment
[15:27] -queuebot:#ubuntu-release- Unapproved: accepted python3.5 [source] (zesty-proposed) [3.5.3-1ubuntu0~17.04.1]
[15:28] -queuebot:#ubuntu-release- Unapproved: accepted python3.5 [source] (xenial-proposed) [3.5.2-2ubuntu0~16.04.3]
[15:29] <smoser> sil2100, thanks!
[15:33] <sil2100> smoser: I think for clarity, once this is released to -updates, we'll have to revert the 'Fix Released' fields of all the series in bug LP: #1691489
[15:34] <ubot5> Launchpad bug 1691489 in cloud-init "fstab entries written by cloud-config may not be mounted" [Medium,Confirmed] https://launchpad.net/bugs/1691489
[15:37] -queuebot:#ubuntu-release- Unapproved: accepted cloud-init [source] (zesty-proposed) [0.7.9-233-ge586fe35-0ubuntu1~17.04.2]
[15:39] <sil2100> smoser: btw. when preparing uploads, you don't have to target them to xenial-proposed, xenial is fine
[15:39] <sil2100> It looks better in the changelogs then
[15:39] <sil2100> (for the future)
[15:40] -queuebot:#ubuntu-release- Unapproved: accepted cloud-init [source] (xenial-proposed) [0.7.9-233-ge586fe35-0ubuntu1~16.04.2]
[15:47] <smoser> sil2100, i always felt like xenial-proposed "looked better"
[15:47] <smoser> (personal preference)
[15:48] <sil2100> To each his own, I guess! ;)
[16:36] <doko> is sysvinit-utils still supposed to be essential in artful?
[17:27] <xnox> doko, no... is it?
[17:27] <xnox> doko, well, some init scripts source it, so maybe it still is essential.
[18:16] <slangasek> xnox: mesa/xenial, appears to be waiting for verification on LP: #1709823?
[18:16] <ubot5> Launchpad bug 1709823 in mesa (Ubuntu Xenial) "Installation of libgles1-mesa (12.0.6-0ubuntu0.16.04.1) failed" [Undecided,Confirmed] https://launchpad.net/bugs/1709823
[18:18] <slangasek> xnox: sounds like it's a pretty easy thing for you to verify :)
[18:19] <infinity> doko: I see no reason why it wouldn't be essential.
[18:19] <infinity> doko: At the very least, the binaries would need to move to another essential package, if someone objected to it being essential just based on the package name.
[18:20] <infinity> (Or it would need to demote in both Debian and Ubuntu with a full archive sweep for references to said binaries)
[18:20] <doko> infinity: I just saw it pulled into build-essential, and Debian didn't do it
[18:21] <infinity> doko: It's Essential in Debian too...
[18:21] <infinity> Of course, build-essential shouldn't include Essential packages, since that would be redundant.
[18:23] <doko> well, look at http://launchpadlibrarian.net/337444978/build-essential_12.1ubuntu2_12.4ubuntu1.diff.gz
[18:24] <infinity> doko: Oh, well, that is literally a list of essential packages.  I'm just curious why it was wrong before.
[18:24] <infinity> Oh, hrm.
[18:24] <infinity> No, it wasn't essential before.
[18:24] <infinity> But it *is* in sid too.
[18:27] <infinity> Ahh.
[18:27] <infinity> It was transitively Essential before.
[18:27] <infinity> Someone just tagged it correctly.
[18:27] <infinity> doko: ^
[18:28] <infinity> doko: So, "yes, it's supposed to be Essential".
[18:28] <infinity> Or, "it always way, but implicitly, and now it's explicit".
[18:37] -queuebot:#ubuntu-release- New source: tomcat8.0 (artful-proposed/primary) [8.0.46-0ubuntu1]
[18:38] -queuebot:#ubuntu-release- New: accepted tomcat8.0 [source] (artful-proposed) [8.0.46-0ubuntu1]
[18:41] <xnox> slangasek, verified
[18:45] <slangasek> xnox: ok - despite the previous comment suggesting verification didn't work?
[18:46] <doko> infinity, slangasek: what's the todo list for glibc at this point? autopkg test failures are still twisted, why3, click
[18:47] <xnox> slangasek, i just did it freshly.
[18:47] <infinity> doko: Processing click removals right now.  twisted, I'll ignore when everything else is green (not ignoring the new twisted to let it in, just ignoring the failure to let glibc in), so that leaves why3.
[18:47] <xnox> slangasek, at the moment i do not care about installability of third-party software; what i do care about is that on uptodate xenial-updates we have a package which is not installable due to conflicts.
[18:47] <xnox> slangasek, with proposed enabled it is installable.
[18:48] <xnox> slangasek, regressing installable count is very bad, britney should have caught this for xenial, no?
[18:52] <doko> xnox: did you look at wh3/s390x?
[19:00] <slangasek> xnox: we don't use britney for promotion
[19:13] <xnox> doko, no.
[19:32] <slangasek> xnox: are you going to?  that's one of the last remaining blockers for glibc, we need to know what the path forward is
[19:35] <doko> slangasek: has no rdepends. remove?
[19:35] <xnox> slangasek, it passes with 4 out of 5 backends.
[19:35] -queuebot:#ubuntu-release- New binary: tomcat8.0 [amd64] (artful-proposed/universe) [8.0.46-0ubuntu1] (no packageset)
[19:36] <xnox> slangasek, so even if has regressed with z3 backend, one can use the other 4 backends.....
[19:36] <xnox> slangasek, most likely a bug in z3 rather than why3
[19:36] <slangasek> xnox: so you're arguing for a badtest?
[19:36] <slangasek> or an upload to disable/xfail the test?
[19:36] <xnox> slangasek, could do that.
[19:36] -queuebot:#ubuntu-release- New: accepted tomcat8.0 [amd64] (artful-proposed) [8.0.46-0ubuntu1]
[19:36] <xnox> slangasek, i'll try rebuilding z3 and check if that helps at all.
[19:38] <slangasek> xnox: ok.  then I conclude that the current version should be badtested for right now
[19:38] <slangasek> and if that badtest hint can be dropped due to the next version, hurray
[19:38] <slangasek> doko, infinity: what's the current situation with libhybris?
[19:38] <slangasek> did anyone talk to morphis?
[19:39] <xnox> slangasek, there is still click which needs removing.... https://bugs.launchpad.net/ubuntu/+bugs?field.tag=u8rm and gcc-4.7
[19:39] <doko> no, you said you wanted to do that? at least that was my impression when I asked last ...
[19:39] <infinity> slangasek: Last week, xnox claimed the plan was to drop it (obviously, with code changes required to do so).
[19:39] <infinity> xnox: I'm removing things right now.
[19:39] <slangasek> xnox: infinity says he was following through on click
[19:39] <xnox> infinity, and somebody did upload pulseaudio to drop things
[19:40] <xnox> or not
[19:40] <xnox> i am confused
[19:41] <infinity> xnox: gcc-4.7 can't be removed yet.  But I actioned the rest of that bug.  On to the click stuff now.
[19:41] <slangasek> doko: I try to be explicit if I am committing to follow up on something ;) all I said was that morphis might be interested in helping with libhybris
[19:42] <xnox> infinity, why can gcc-4.7 not be removed yet? note the brain deadness of reverse-depends, and doko shipping the same binary package out of three source packages, with only latest being actually installable
[19:42] <slangasek> infinity: what still blocks gcc-4.7?
[19:42] <xnox> infinity, all of gcc-4.7 and gcc-4.7-arm* crosses can be removed.
[19:42] <infinity> xnox: Because things still build-depend on it.
[19:43] <infinity> xnox: Unless you're asserting (incorrectly) that newer gcc provides gcc-4.7/g++-4.7 :P
[19:43] <xnox> infinity, all of these packages are to be removed, as per RM bugs.
[19:43] <xnox> gcc-4.7-armel-cross <- has phatom reverse-depends
[19:43] <slangasek> but you have not listed what those packages are, in the gcc-4.7 removal request
[19:43] <xnox> slangasek, hm.
[19:44] <slangasek> u-boot-linaro?
[19:44] <infinity> xnox: Dude.  Don't make incorrect assertions.  There are not removal bugs for all the r-build-deps.
[19:44] <xnox> https://bugs.launchpad.net/ubuntu/+source/u-boot-linaro/+bug/1717232
[19:44] <ubot5> Ubuntu bug 1717232 in u-boot-linaro (Ubuntu) "RM: duplicate package" [High,Triaged]
[19:44] <infinity> cloog-ppl-gcc4, gmp-gcc4, ppl-gcc4
[19:44] <xnox> let me tag things
[19:44] <slangasek> ok, so the bug exists; but cross-linking the reports helps us do this faster
[19:44] <infinity> Now, I imagine those should all be removed.  But there aren't bugs.
[19:44] <slangasek> and ensures we're looking at the same things
[19:45] <doko> adding
[19:45] <infinity> doko: Add tasks to LP: #1717229 for those, if they should go.
[19:45] <ubot5> Launchpad bug 1717229 in gmp-gcc4 (Ubuntu) "RM: obsolete product" [Undecided,New] https://launchpad.net/bugs/1717229
[19:45] <infinity> Hah, proof task was added, thanks bot. ;)
[19:46] <xnox> infinity, yeah all of those are "this is gcc4.7 toolchain pieces, chicken, egg"
[19:46] <xnox> you see, all bugs were totally filed ;-)
[19:46] <infinity> xnox: Except, there's no obvious indicator of that without someone saying it.
[19:46] <xnox> ps no need to look at bug history
[19:47]  * infinity keeps removing.
[19:47] <doko> $ reverse-depends src:libhybris
[19:47] <doko> Reverse-Depends
[19:47] <doko> ===============
[19:47] <doko> * libmedia-hub-client5          (for libmedia1)
[19:47] <doko> * liboxideqtcore0               (for libhybris)
[19:47] <doko> * liboxideqtcore0               (for libandroid-properties1)
[19:47] <doko> * media-hub                     (for libmedia1)
[19:47] <doko> * telepathy-ofono-ril-mc-plugin  (for libhybris-utils)
[19:47] <doko> * unity-system-compositor       (for libandroid-properties1)
[19:47] <doko> * urfkill [amd64 armhf i386]    (for libandroid-properties1)
[19:47] <doko> * urfkill [amd64 armhf i386]    (for libhybris)
[19:47] <doko> that looks like more ...
[19:47] <infinity> Different stack.
[19:47] <infinity> But yes, those need addressing, or hybris needs fixing.
[19:48] <doko> do we agree that we can remove libhybris?
[19:48] <infinity> Not yet, no.
[19:48] <infinity> We very much don't agree.
[19:48] <infinity> I think most of us agree that we *should* remove it.  Once the rdeps are fixed.
[19:49] <slangasek> how about giving the active libhybris upstream a heads up and finding out if they want to do the work to keep it, before us doing the work to remove it?
[19:49] <doko> did upstream ever care about the arm soft-float/hard-float bits?
[19:50] <infinity> slangasek: Because "upstream might support it" isn't a good enough reason to have the shim existing, if our stacks no longer actually need it?
[19:51] <infinity> It's not like this is something that will regress functionality for a user if we remove it.
[19:51] <xnox> look, all of the libhybris reverse depends have RM bugs filed (just now) https://bugs.launchpad.net/ubuntu/+bugs?field.tag=u8rm
[19:51] <infinity> xnox: Erm.
[19:51] <xnox> and building pulseaudio to drop a (forgotten) build-dep
[19:51] <slangasek> urfkill should not be dropped because of libhybris.
[19:52] <infinity> xnox: And are those bugs signed off on by the people who should do so?
[19:52] <xnox> slangasek, why is it not seeded then?
[19:52] <xnox> slangasek, please seed it appropriately.
[19:52] <slangasek> xnox: no
[19:52] <slangasek> urfkill should not be dropped /because of libhybris/
[19:52] <xnox> slangasek, is urfkill generic, or the thing we wrote from scratch.
[19:52] <slangasek> using "we want to nuke libhybris" as a rationale for removing urfkill is wrong
[19:52] <slangasek> it's generic and we didn't write it
[19:53] <xnox> slangasek, i'm pretty sure we did rewrite it from scratch and abuse the name =/
[19:53] <xnox> unless i am very confused.
[19:53] <slangasek> not to my knowledge
[19:53] <xnox> why not force ync with debian then?
[19:53] <slangasek> because we're ahead of Debian in versions
[19:54] <doko> https://www.freedesktop.org/wiki/Software/urfkill/ -> Development happens in git. and this link pointing to cvs ...
[19:55] <doko> there is no 0.6 release, so this is basically a fork
[19:55] <slangasek> xnox: anyway, my core point is the same as infinity's here - just filing bugs requesting removal because we're in a hurry to get rid of libhybris isn't sufficient wrt procedure
[19:56] <xnox> slangasek, without touch, there is little sense to build VCS snapshot of urfkill with hybris enabled.
[19:56] <slangasek> so disable hybris support in urfkill!
[19:56] <doko> sure, we can wait with promoting glibc to -release until the last day before the release as well
[19:56] <slangasek> but don't just file blanket removal requests for revdeps without analysis
[19:56] <doko> if people didn't care until now, when will they?
[19:57] <infinity> We are the people currently caring.
[19:57] <slangasek> doko: what have you done to inform people that there is an issue they need to care about?
[19:57] <infinity> Disabling hybris in urfkill can't be that hard.
[19:57]  * xnox test builds
[19:58] <infinity> Bye-bye, gcc-4.7.
[19:59] <slangasek> doko: libhybris only just broke with glibc 2.26.  it's not reasonable to expect that someone knows there's a build failure in a package they care about /without us telling them/.
[19:59]  * xnox fixes urfkill FTBFS on something from his half of the decade
[19:59] <infinity> slangasek: OTOH, it only "just broke" because I didn't update gcc last cycle.  Its design is to break every 6 months.
[20:00] <infinity> slangasek: So I can see some argument here that the hybris-using crowd should have probably had a plan to stop using hybris well before now (or keep on top of maintenance in the distro).
[20:00] <doko> slangasek: I think it is reasonable to drop these packages if we decided to drop the product. sure, urfkill might have some value to keep. but are there any other packages which need keeping without touch?
[20:00] <infinity> Failing the latter, forcing the former is the only sane option.
[20:00] <xnox> infinity, slangasek - i thought even we built hybris in the device tarball and did not use ubuntu archive one.....
[20:00] <infinity> s/gcc/glibc/
[20:01] <xnox> doko, pulseaudio, which is now uploaded.
[20:01] <infinity> xnox: I mean, we clearly use the archive one for something, even if it's just to link against at build-time.
[20:01] <xnox> (bogus build-dep that was not removed)
[20:01] <xnox> infinity, true.
[20:02] <infinity> Grr, why were the click removals three bugs? :P
[20:02] <infinity> ... and none of them are for click.
[20:02] <xnox> infinity, because one should remove leaf things first.
[20:02] <cyphermox> I wrote that urfkill libhybris crap IIRC, I'm happy to get rid of it
[20:02] <slangasek> I'm filing a bug against libhybris about the FTBFS
[20:03] <infinity> xnox: You filed all the gcc-4.7 stuff in one bug, despite there being interdeps. ;)
[20:03] <xnox> uploaded urfkill to not have libhybris stuff.
[20:03] <cyphermox> oh ok then
[20:04] <xnox> infinity, well cause click ones were filed with automated scripts; and gcc stuff was by hand due to circular build-deps on itself.
[20:04] <infinity> xnox: Fair enough.  Well, leafy things going away as we speak.  Gimme a bug for the tree.
[20:04] <xnox> infinity, and click is hard to check, because of the bogus python3-click
[20:04] <infinity> It is indeed.
[20:04] <xnox> also i see unity-scopes-api sutff
[20:05] <infinity> libusermetrics is still there.
[20:05] <xnox> and we are back to url-dispatcher stuff =/
[20:05] <infinity> Woo.
[20:05] <xnox> via unity-scopes-api -> url-dispatcher -> indicator-*
[20:06] <infinity> All roads lead to indicators.
[20:06] <infinity> Thanks, Ted.
[20:06] <slangasek> https://bugs.launchpad.net/ubuntu/+source/libhybris/+bug/1718030
[20:06] <ubot5> Ubuntu bug 1718030 in libhybris (Ubuntu) "libhybris fails to build with glibc 2.26" [Undecided,New]
[20:08] <infinity> xnox: libusermetrics has no rdeps, unless it's on someone's protected list, it might be a candidate for thwacking.
[20:09] <infinity> unity-scopes-api is definitely ickier.
[20:09] <infinity> And probably just needs the click bits excised.
[20:09] <infinity> Rather than the package dropped.
[20:09] <xnox> infinity, i think unity-scopes-api was a unity8 thing, not unity7 thing thus can be removed.... once indicators are fixed.
[20:09] <xnox> or that.
[20:10] <xnox> https://bugs.launchpad.net/ubuntu/+source/libusermetrics/+bug/1718027
[20:10] <ubot5> Ubuntu bug 1718027 in libusermetrics (Ubuntu) "RM: obsolete product" [Undecided,Triaged]
[20:10] <infinity> xnox: Sure, it may be that its ultimate fate is deletion, but I suspect the faster path today is to see about disabling the click bits.
[20:10] <xnox> 3/4 indicators to go....
[20:11] <xnox> infinity, cause we do have mandate to ship indicators
[20:13] <doko> xnox: upload why3. test was already ignored on ppc64el
[20:14] <slangasek> I've badtested why3/s390x now, it won't block now
[20:16] <infinity> Kay, so let's finish unwinding click.  Grabbing the unity-scopes-api source to see if there's an obvious solution.
[20:16] <infinity> How does that have 18MB of source?  Sheesh.
[20:17] <xnox> infinity, does it include an embedded copy of systemd? if not, it's not that bad....
[20:17] <doko> slangasek: you may want to skip the autopkg tests for build-essential and python-defaults (and python3-defaults) if capacity is needed. all of these are dependency packages anyway
[20:18] <doko> not 20mb testsuite
[20:18] <infinity> Hrm, click stuff is ALL over in this.
[20:23] <xnox> infinity, yeah, i would have expected as much
[20:24] <xnox> infinity, maybe we can make url-dispatcher not depend on libunity-scopes1.0 and then nuke unity-scopes-api with click?
[20:24] <infinity> xnox: That's where I was heading.
[20:26] <infinity> That looks to require some hefty surgery too.
[20:28] <slangasek> this all seems like useful surgery over the long term, but all of this is just for a single test failure of click on ppc64el, correct?
[20:28] <slangasek> which we could badtest and not treat as a blocker for glibc here and now
[20:28] <infinity> Well, yes.  We could badtest that test for now.
[20:28] <infinity> And then skiptest glibc to get over the twisted hump.
[20:28] <slangasek> and file a bug and make it some other team's problem to eliminate their own obsolete deps
[20:29] <infinity> Does that team exist?
[20:30] <infinity> Anyhow, if we address those two test issues, we're just back to hybris.
[20:31] <slangasek> infinity: it's either the mir team or the desktop team
[20:31] <slangasek> not sure which
[20:31] <slangasek> but yes, if tracing the revdeps leads us to something seeded / not removable, then there is a team that should be on the hook for it
[20:34] <infinity> slangasek: Well, url-dispatcher is "seeded", but only indirectly.
[20:34] <infinity> Not removable, it certainly is currently.
=== klebers_ is now known as klebers
[20:34] <infinity> Anyhow, fine with badtesting click on an arch where no one would ever had used it.
[20:34] <infinity> So, it's a regression, but not one that anyone will see.
[20:36]  * infinity does that now.
[20:38] <infinity> Done.
[20:38] <xnox> slangasek, infinity - what is the story with ofono? it is a generic thing right?
[20:39] <infinity> Which leaves just twisted, which I would badtest if it was the old version, but someone re-ran against the new version, whose test failure is legit.
[20:42] <xnox> hm ofono in debian is on 1.18 and we are on 1.17
[20:49] -queuebot:#ubuntu-release- Unapproved: unattended-upgrades (xenial-proposed/main) [0.90ubuntu0.7 => 0.90ubuntu0.8] (desktop-core, ubuntu-server)
[20:50] <infinity> doko: http://paste.ubuntu.com/25567940/ <-- Wat.
[20:51] <infinity> Oh, hrm.  Is my mirror out of date?
[20:51] <xnox> infinity, i did same paste to doko in msg too =)
[20:51]  * xnox calls it a day
[20:51] <infinity> Oh no, it's not.
[20:53] <infinity> Ahh, I see the bug.
[20:53] <infinity> I think.
[20:54] <nacc> infinity: yeah a double definition?
[20:54] <nacc> infinity: rather than a remove/add
[20:54] <infinity> nacc: Or, the inverse.
[20:54] <infinity> Anyhow, removing that one, since it build-deps on itself.
[20:54] <nacc> infinity: err, right (i see a add in the debdiff, rather than a remove/add)
[20:58] <infinity> nacc: http://paste.ubuntu.com/25567979/ <-- That match your read on what's broken?
[20:58]  * infinity test.
[20:58] <infinity> s
[21:00] <infinity> Yep, that fixes it.
[21:02] <nacc> infinity: yeah
[21:29] <doko> ahh, thanks for fixing :-/
[21:30] <infinity> doko: Thankfully, nothing build-depends on python, so no harm done.
[21:30] <infinity> Oh, wait. ;)
[21:30] <infinity> Now just waiting for the publisher to get around to deleting the old version.
[21:43] <doko> indeed, only python3 ;)
=== Guest41832 is now known as RAOF