[00:29] <doko> LocutusOfBorg, slangasek: a sync is not possible, Ubuntu has jpeg8 compatibility, Debian has jpeg6 compatibility. and libturbojpeg-dev's so was not provided becauses it's a legacy API. At least it was when turbo entered Ubuntu
[00:38] -queuebot:#ubuntu-release- New binary: golang-github-go-macaron-captcha [amd64] (artful-proposed/universe) [0.0~git20170330.0.cbfb9d9-1] (no packageset)
[00:49] <doko> LocutusOfBorg: and not mentioning bug reports in this upload while you are aware of these and closing manually looks like you try to hide things. not amused
[00:55] <doko> LocutusOfBorg, slangasek: the the README.md in the sources, "Using libjpeg-turbo". I don't see the value providing this, and fear desaster coming when more packages start depending on turbo-dev
[00:55] <doko> but good night for now, 17.10 is not a LTS
[00:56] -queuebot:#ubuntu-release- New: accepted golang-github-go-macaron-captcha [amd64] (artful-proposed) [0.0~git20170330.0.cbfb9d9-1]
[06:13] -queuebot:#ubuntu-release- Unapproved: gnutls26 (trusty-proposed/main) [2.12.23-12ubuntu2.9 => 2.12.23-12ubuntu2.10] (core)
[06:21] <LocutusOfBorg> doko, I saw them because jbicha pinged me *after* not before of course
[06:22] <LocutusOfBorg> I woudl have closed bugs in changelog, of course! and it is not my fault that Debian started using it :( do you want to help me patching dcm2niix=
[06:22] <LocutusOfBorg> I would  like to at least sync the packages with a minimal delta, same package names, ok for the jpeg6/jpeg8, but the current status quo is a mess, a double mess
[06:23] <LocutusOfBorg> I put it in queue 12h before noticing the bugs
[06:24] <LocutusOfBorg> btw you can't avoid people doing bad symlinks on their systems to use it anyway, not providing a -dev package is not helping, but rather making people do nasty hacks :(
[06:29] <LocutusOfBorg> the package uses functions such as tjDecompressHeader2, provided only by that library
[06:29] <LocutusOfBorg> not really sure how can we avoid that
[07:13] -queuebot:#ubuntu-release- Unapproved: virt-manager (xenial-proposed/universe) [1:1.3.2-3ubuntu1.16.04.3 => 1:1.3.2-3ubuntu1.16.04.4] (no packageset)
[08:34] -queuebot:#ubuntu-release- Unapproved: virt-manager (zesty-proposed/universe) [1:1.3.2-3ubuntu4 => 1:1.3.2-3ubuntu6] (no packageset)
[08:40] <cpaelzer> could one please reject the shameful mistake of version number increase in zesty-unapproved being virt-manager 1:1.3.2-3ubuntu6?
[08:50] <apw> cpaelzer, looking
[08:51] -queuebot:#ubuntu-release- Unapproved: rejected virt-manager [source] (zesty-proposed) [1:1.3.2-3ubuntu6]
[08:52] <LocutusOfBorg> hello, the following packages have been regressed in release casync/i386 pycurl/ppc64el r-cran-curl/ppc64el xandikos/amd64/i386 and are preventing curl migration
[08:52] <LocutusOfBorg> also s390x might be sad, but it is not ran yet, maybe Laney knows an ETA for having it back online
[08:53] <cpaelzer> thanks apw
[08:54] <Laney> It's being investigated.
[08:54] -queuebot:#ubuntu-release- Unapproved: virt-manager (zesty-proposed/universe) [1:1.3.2-3ubuntu4 => 1:1.3.2-3ubuntu4.1] (no packageset)
[08:59] <LocutusOfBorg> please accept the new llvm "lld" package, it is the linker, and has its new package since the default llvm in yakkety/zesty/artful
[08:59] <LocutusOfBorg> just we were missing the metapackage from llvm-defaults
[09:01] <apw> LocutusOfBorg, where is that i don't see anything resembling that pending anywhere
[09:01] <LocutusOfBorg> it is just building
[09:01] <LocutusOfBorg> ok finished now
[09:02] -queuebot:#ubuntu-release- New binary: llvm-defaults [amd64] (artful-proposed/universe) [0.37~exp3] (no packageset)
[09:02] <LocutusOfBorg> hopefully having a new linker might help :)
[09:03] -queuebot:#ubuntu-release- New binary: llvm-defaults [arm64] (artful-proposed/universe) [0.37~exp3] (no packageset)
[09:03] -queuebot:#ubuntu-release- New binary: llvm-defaults [i386] (artful-proposed/universe) [0.37~exp3] (no packageset)
[09:04] -queuebot:#ubuntu-release- New binary: llvm-defaults [armhf] (artful-proposed/universe) [0.37~exp3] (no packageset)
[09:04] <LocutusOfBorg> sadly it still don't work on ppc64el and s390x... but meh, at least it is now in sync with debian experimental
[09:21] <sil2100> apw: hey, I have a new walinuxagent to be released, the package is not seeded and cloud-up-to-date essential - I guess I can push it to artful without a FFE, right?
[09:21] <sil2100> (by cloud-up-to-date essential I mean we always need to keep it up to date)
[09:36] <apw> sil2100, that one has an SRU exception for that reason doesn't it, so it seems reasonable it would something we can update yes
[09:37] <sil2100> apw: yeah, SRU exception it has, but I just wanted to make sure it also counts as a FF exception for the devel series
[09:37] <apw> sil2100, it seems reasonable to count it to me for all the reasons it is reasonable in stable
[09:38] <sil2100> Thanks!
[09:47] <LocutusOfBorg> thanks Laney for having a look!
[10:09] <Laney> LocutusOfBorg: Back up
[10:53] <LocutusOfBorg> thanks for the work!
[12:09] <cpaelzer> hi, does an FFE like https://bugs.launchpad.net/ubuntu/+source/slof/+bug/1706248 need any further pings/mails to be reviewed or is just a lot goging on atm delaying that?
[12:24] <flocculant> cpaelzer: thanks for finding that virt-manager issue - I've been scratching my head for a couple of weeks :)
[12:28] <cpaelzer> flocculant: which one actually :-)
[12:28] <cpaelzer> flocculant: I happen to hack on a few the recent days
[12:29] <flocculant> bug 1714638
[12:29] <cpaelzer> ah yeah, well I only came from another bug report
[12:29] <cpaelzer> was verifying what it is about and finally linked to the already existing issue report
[12:29] <flocculant> yup - but you did more than me - you found the dup :D
[13:12] -queuebot:#ubuntu-release- Unapproved: walinuxagent (trusty-proposed/main) [2.2.14-0ubuntu1~14.04.1 => 2.2.16-0ubuntu1~14.04.1] (ubuntu-cloud, ubuntu-server)
[13:12] -queuebot:#ubuntu-release- Unapproved: walinuxagent (zesty-proposed/main) [2.2.14-0ubuntu1~17.04.1 => 2.2.16-0ubuntu1~17.04.1] (ubuntu-cloud, ubuntu-server)
[13:12] -queuebot:#ubuntu-release- Unapproved: walinuxagent (xenial-proposed/main) [2.2.14-0ubuntu1~16.04.1 => 2.2.16-0ubuntu1~16.04.1] (ubuntu-cloud, ubuntu-server)
[13:16] <rbalint> Laney: could you please check if LP: #1714019 needs FFe and if it does tell what is missing? slangasek can't follow up on this soon
[13:22] -queuebot:#ubuntu-release- Unapproved: accepted walinuxagent [source] (zesty-proposed) [2.2.16-0ubuntu1~17.04.1]
[13:23] -queuebot:#ubuntu-release- Unapproved: accepted walinuxagent [source] (xenial-proposed) [2.2.16-0ubuntu1~16.04.1]
[13:24] -queuebot:#ubuntu-release- Unapproved: accepted walinuxagent [source] (trusty-proposed) [2.2.16-0ubuntu1~14.04.1]
[13:27] <apw> rbalint, do you feel that unattended-upgrades has any new features ?
[13:27] <apw> rbalint, the changelog looks like all fixes perhap with the exclusion of the new --download-only
[13:28] <rbalint> apw: thanks for the review
[13:28] <apw> rbalint, oh and we have that fix in our ubunut8 as a backport, so ignore that
[13:28] <rbalint> apw: there are no features, but there are minimal changes which are not strictly bug fixes
[13:29] <apw> rbalint, there does not appear to be anything there which would be concerning from a "changing behaviour" point of view, it looks to be mostly fixes, some cleanup of formatting but meh
[13:29] <rbalint> apw: there is also default behavior change (longer timeout, minimal steps by default) but those are needed to fix real life issues IMO
[13:30] <apw> if theey are being changed to fix bugs without the change, then that is a bug-fix none the less
[13:30] <rbalint> apw: i'm perfectly fine with not needing FFe, i felt it was better to ask and have release team take a look at the changes
[13:31] <apw> rbalint, i don't see anything in there warrenting it .. so i'd say you are good
[13:32] <rbalint> apw: ok thanks!
[14:15] <juliank> I uploaded gnutls28 on saturday, but it seems the autopkgtest for lxc on amd64, i386, ppc64el are borked _since some time_ and blocking the migration out of -proposed.
[14:15] <juliank> would be great to ignore those failures and allow it in
[14:16] <juliank> (BTW: there's also an SRU in the zesty unapproved queue with the same patches; bug 1707172 and bug 1714506 are being fixed)
[14:18] -queuebot:#ubuntu-release- New: accepted llvm-defaults [amd64] (artful-proposed) [0.37~exp3]
[14:18] -queuebot:#ubuntu-release- New: accepted llvm-defaults [armhf] (artful-proposed) [0.37~exp3]
[14:18] -queuebot:#ubuntu-release- New: accepted llvm-defaults [arm64] (artful-proposed) [0.37~exp3]
[14:18] -queuebot:#ubuntu-release- New: accepted llvm-defaults [i386] (artful-proposed) [0.37~exp3]
[14:19] <apw> juliank, indeed those look unreleased to you for sure
[14:23] <apw> juliank, ok hinted
[14:24] <juliank> apw: thanks
[14:24] <LocutusOfBorg> apw, the same happens on curl, all of them are regressed in release
[14:25] <Laney> I hate this regressed in release thing
[14:25] <Laney> It means people spend time finding out whether not to fix something rather than fixing it
[14:25] <Laney> because we suck at catching failures at the right time
[14:26] <apw> a very valid sentiment ...
[14:26] <LocutusOfBorg> as said, such stuff shoudl run from time to time already against release
[14:26] <LocutusOfBorg> specially when queues are emptu
[14:26] <LocutusOfBorg> tests for some packages are run once a yer
[14:26] <Laney> so we can find out whether to ignore breakage in an automated way?
[14:26] <LocutusOfBorg> year, so when you regress you have the world that changed in the meanwhile
[14:27] <jbicha> ci.debian.net runs more frequently
[14:27] <LocutusOfBorg> I would prefer rather to know "which" package regressed it, not to find it with a complete different set of stuff
[14:28] <apw> Laney, i assume this is happening because we have either 1) ignored some other failure and released (say systemd with regressions) or 2) we have a missing dependency here
[14:29] <apw> Laney, perhap netplan given the networking nature
[14:29] <Laney> could be - or something in the base system changed, or we only run for direct dependency changes so we miss anything transitive
[14:30] <Laney> anyway, the main problem I have is accepting an ever worsening baseline
[14:31] <LocutusOfBorg> "so we can find out whether to ignore breakage in an automated way?" <-- I still don't get if this was a joke or not :) I admit, in my brain I had this thought, but I never said it out there
[14:31] <Laney> that's what the proposal is
[14:32] <LocutusOfBorg> not from my side I hope :)
[14:32] <LocutusOfBorg> it will make testsuite useless
[14:32] <Laney> what is 'run against release' meant to achieve then?
[14:32] <LocutusOfBorg> or at least useless when the breakage is something else
[14:32] <LocutusOfBorg> it is meant to have more logs, more runs
[14:32] <Laney> you want to run against nothing from proposed, find out if it is already broken there, and if it is then don't treat the failure as a regression
[14:32] <LocutusOfBorg> and less changed packages between them
[14:32] <Laney> that is what requests like the curl one is
[14:33] <LocutusOfBorg> this is what I did for curl
[14:33] <LocutusOfBorg> but ok, I found release is broken, now, with some more test, I can diff the testbeds, and find "what" regressed it
[14:34] <Laney> In theory I wouldn't mind if someone were to schedule such tests if they were friendly to the infrastructure
[14:35] <LocutusOfBorg> of course, with less priority
[14:35] <Laney> using this to decide when to force-badtest, or changing the definition of REGRESSION, is where I start to have problems
[14:35] <LocutusOfBorg> also, having somebody running tests (results ignored), with --all-proposed would be nice
[14:35] <Laney> but if people on the release team want to do the former then I can't really stop them
[14:36] <Laney> there's no way to ignore results like that
[14:36] <LocutusOfBorg> I sometimes run against all-proposed, but I don't like to have the green button as result in case
[14:36] <LocutusOfBorg> so, if it becomes green, I try to make migrate the fixex package from proposed too
[14:37] <LocutusOfBorg> but again, choosing one architecture (e.g. arm64) to always run against proposed, will make us have a clear view of what regressed and where, and if a fix is already in place, just not migrated
[14:37] <LocutusOfBorg> (e.g. with k* qt* haskell* perl* this is normal)
[14:37] <Laney> I don't think it's normal with perl
[14:37] <Laney> or with haskell? they have correct dependencies
[14:38] <LocutusOfBorg> yes, perl testsuites should run against perl in proposed, if you rebuild
[14:38] <LocutusOfBorg> nope Laney
[14:38] <Laney> what?
[14:38] <Laney> they sure do
[14:38] <LocutusOfBorg> they are just uninstallable in release, because all the rebuilds are in proposed
[14:38] <LocutusOfBorg> I think I remember haskell-hoogle having this issue
[14:38] <Laney> you're not trying to migrate the release thing
[14:39] <LocutusOfBorg> I don't know what to say, I remember with perl slangasek did the --all-proposed stuff, because of this issue
[14:39] <LocutusOfBorg> (maybe it was somebody else, but the problem was there)
[14:39] <Laney> with haskell, I don't know what the specific problem with perl was
[14:40] <LocutusOfBorg> is that you rebuild 500 packages, and they are installable only with the correspective rebuilds
[14:40] <LocutusOfBorg> there is no strict dependency I would assume, don't remember
[14:40] <Laney> the haskell tooling makes you depend on the hash
[14:40] <Laney> if you're saying that doesn't happen for Test-Depends, well, it should :)
[14:41] <LocutusOfBorg> http://autopkgtest.ubuntu.com/packages/haskell-hgettext/artful/amd64
[14:41] <LocutusOfBorg> look as example at the first failure
[14:42] <apw> Laney, i wonder if we should upload a no-change rebuild of things which fail in this way so they get wedged in -proposed and emails sent to the owners
[14:43] <LocutusOfBorg> indeed, or put the test in some "depwait" mode
[14:43] <LocutusOfBorg> so we can aware that the regression is just because the archive is not yet fully in place
[14:43] <Laney> the first failure is an all-proposed run
[14:43] <Laney> and 2, 3, 4, and I get bored now and stop looking
[14:44] <Laney> https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-artful/artful/amd64/h/haskell-hgettext/20170715_153508_199d7@/log.gz these ones that weren't all-proposed worked
[14:46] <LocutusOfBorg> this one? https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-artful/artful/amd64/h/haskell-hgettext/20170622_040119_7b95b@/log.gz
[14:46] <LocutusOfBorg> the first failure
[14:46] <LocutusOfBorg> (the oldest)
[14:47] <LocutusOfBorg> so, maybe rebuilds were not complete then?
[14:47] <Laney> autopkgtest: WARNING: Test dependencies are unsatisfiable with using apt pinning. Retrying with using all packages from proposed
[14:47] <Laney> and it still didn't work
[14:47] <Laney> so I don't blame pinning
[14:48] <LocutusOfBorg> but having a "testbed unsatisfiable status" would have helped at least
[14:48] <LocutusOfBorg> I now agree with you
[14:48] <LocutusOfBorg> (I was just not aware of that pinning feature)
[14:53] <Laney> I wouldn't look forward to implementing that particularly :(
[14:53] <Laney> apw: Maybe, but the proposal I've heard is to make such things *not* get stuck because they wouldn't be regressions in proposed
[14:53] <Laney> also, things don't always have owners
[14:53] <Laney> did anyone file a bug about the lxc regression so that its maintainers can look? :-)
[14:54] <LocutusOfBorg> it would be somewhat fixed if britney in Debian would have start to looking at ci too :D
[14:54] <Laney> https://bugs.launchpad.net/ubuntu/+source/lxc/+bug/1713726 ♥
[15:06] <acheronuk> LocutusOfBorg: those kcrash tests should be ignored, as they pass here against the archive in a lxc adt containers. so something has gone a bit funky in the official ubuntu ones
[15:09] <LocutusOfBorg> s/should be ignored/ubuntu official adt containers should be fixed/ I would say :)
[15:09] <LocutusOfBorg> at least diverging makes local testing less effective
[15:35] <apw> Laney, yeah we tend to file bugs for everything we see in failure even if we ignore them, so they are not forgotten
[15:39] <LocutusOfBorg> filing bugs for stuff in universe is... strange
[16:00] <apw> LocutusOfBorg, why so?  just becasue we don't want to support things doesn't mean they arn't broken
[16:09] <LocutusOfBorg> apw, yes, but not many looks at universe bugs, unfortunately
[16:09] <LocutusOfBorg> (I do, but I feel alone)
[18:39] <LocutusOfBorg> sorry, please remove lld/arm64, it was built but not available from llvm-toolchain-4.0
[18:39] <LocutusOfBorg> old binaries left on arm64: lld (from 0.37~exp3) (NBS-proposed remove it)
[19:06] <flexiondotorg> doko: I see caja-admin and caja-rename are in the Artful NEW.
[19:07] <flexiondotorg> They took longer than expected to clear the Debian NEW queue, but we are hotly anticpating them for Ubuntu MATE.
[19:07] <flexiondotorg> Could you allow them through please.
[20:17] <Laney> jbicha: http://autopkgtest.ubuntu.com/packages/e/evolution-data-server/artful/i386 http://autopkgtest.ubuntu.com/packages/e/evolution-data-server/artful/s390x were all of these you?
[20:18] <jbicha> Laney: yes, the probably is that e-d-s is now running the installed-tests, I expected them to be flaky so I'll probably disable them in my next upload
[20:18] <jbicha> *the problem
[20:19] <Laney> 4 retries (5 attempts) is probably a bit much
[20:19] <jbicha> I now have data to show to upstream at least
[20:21] <jbicha> Laney: are you interested in ignoring the tests for this version to let e-d-s migrate?
[21:02] <slangasek> nacc: your sphinx-celery upload was binary rejected, but the source is still in -proposed; should we be expecting another upload, or should I just remove the corresponding source? https://launchpad.net/ubuntu/+source/sphinx-celery/1.3.1-1ubuntu1
[21:22] <tsimonq2> Could an archive admin please look at ubuntu-mate-guide in NEW when they can?
[21:50] <flexiondotorg> Could an archive admin please look at caja-admin and caja-rename in NEW when they can?