[00:29] 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] 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] 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] 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] doko, I saw them because jbicha pinged me *after* not before of course [06:22] 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] 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] I put it in queue 12h before noticing the bugs [06:24] 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] the package uses functions such as tjDecompressHeader2, provided only by that library [06:29] 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] could one please reject the shameful mistake of version number increase in zesty-unapproved being virt-manager 1:1.3.2-3ubuntu6? [08:50] cpaelzer, looking [08:51] -queuebot:#ubuntu-release- Unapproved: rejected virt-manager [source] (zesty-proposed) [1:1.3.2-3ubuntu6] [08:52] 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] also s390x might be sad, but it is not ran yet, maybe Laney knows an ETA for having it back online [08:53] thanks apw [08:54] 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] 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] just we were missing the metapackage from llvm-defaults [09:01] LocutusOfBorg, where is that i don't see anything resembling that pending anywhere [09:01] it is just building [09:01] ok finished now [09:02] -queuebot:#ubuntu-release- New binary: llvm-defaults [amd64] (artful-proposed/universe) [0.37~exp3] (no packageset) [09:02] 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] sadly it still don't work on ppc64el and s390x... but meh, at least it is now in sync with debian experimental === santa is now known as Guest88511 [09:21] 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] (by cloud-up-to-date essential I mean we always need to keep it up to date) [09:36] 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] 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] sil2100, it seems reasonable to count it to me for all the reasons it is reasonable in stable [09:38] Thanks! [09:47] thanks Laney for having a look! [10:09] LocutusOfBorg: Back up [10:53] thanks for the work! === santa is now known as Guest19413 [12:09] 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:09] Ubuntu bug 1706248 in slof (Ubuntu) "[FFE] SLOF dhcp request doesn't include client architecture code 93" [Medium,Confirmed] [12:24] cpaelzer: thanks for finding that virt-manager issue - I've been scratching my head for a couple of weeks :) [12:28] flocculant: which one actually :-) [12:28] flocculant: I happen to hack on a few the recent days [12:29] bug 1714638 [12:29] bug 1711358 in ubiquity (Ubuntu) "duplicate for #1714638 20170817 - ISO hangs on boot on qemu with splash screen enabled and qxl graphics driver" [Undecided,Confirmed] https://launchpad.net/bugs/1711358 [12:29] ah yeah, well I only came from another bug report [12:29] was verifying what it is about and finally linked to the already existing issue report [12:29] yup - but you did more than me - you found the dup :D === santa is now known as Guest56020 [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) === Guest56020 is now known as santa_ [13:16] 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:16] Launchpad bug 1714019 in unattended-upgrades (Ubuntu) "Please merge unattended-upgrades 0.96 (main) from Debian unstable (main)" [Undecided,Confirmed] https://launchpad.net/bugs/1714019 [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] rbalint, do you feel that unattended-upgrades has any new features ? [13:27] rbalint, the changelog looks like all fixes perhap with the exclusion of the new --download-only [13:28] apw: thanks for the review [13:28] rbalint, oh and we have that fix in our ubunut8 as a backport, so ignore that [13:28] apw: there are no features, but there are minimal changes which are not strictly bug fixes [13:29] 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] 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] if theey are being changed to fix bugs without the change, then that is a bug-fix none the less [13:30] 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] rbalint, i don't see anything in there warrenting it .. so i'd say you are good [13:32] apw: ok thanks! [14:15] 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] would be great to ignore those failures and allow it in [14:16] (BTW: there's also an SRU in the zesty unapproved queue with the same patches; bug 1707172 and bug 1714506 are being fixed) [14:16] bug 1707172 in gnutls28 (Ubuntu Zesty) "AES256-GCM emits all-zeros ciphertext on aarch64 with hardware acceleration" [High,In progress] https://launchpad.net/bugs/1707172 [14:16] bug 1714506 in gnutls28 (Ubuntu Zesty) "libgnutls30 OCSP verification bug" [High,In progress] https://launchpad.net/bugs/1714506 === santa is now known as Guest46152 [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] juliank, indeed those look unreleased to you for sure [14:23] juliank, ok hinted [14:24] apw: thanks [14:24] apw, the same happens on curl, all of them are regressed in release [14:25] I hate this regressed in release thing [14:25] It means people spend time finding out whether not to fix something rather than fixing it [14:25] because we suck at catching failures at the right time [14:26] a very valid sentiment ... [14:26] as said, such stuff shoudl run from time to time already against release [14:26] specially when queues are emptu [14:26] tests for some packages are run once a yer [14:26] so we can find out whether to ignore breakage in an automated way? [14:26] year, so when you regress you have the world that changed in the meanwhile [14:27] ci.debian.net runs more frequently [14:27] I would prefer rather to know "which" package regressed it, not to find it with a complete different set of stuff [14:28] 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] Laney, perhap netplan given the networking nature [14:29] could be - or something in the base system changed, or we only run for direct dependency changes so we miss anything transitive [14:30] anyway, the main problem I have is accepting an ever worsening baseline [14:31] "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] that's what the proposal is [14:32] not from my side I hope :) [14:32] it will make testsuite useless [14:32] what is 'run against release' meant to achieve then? [14:32] or at least useless when the breakage is something else [14:32] it is meant to have more logs, more runs [14:32] 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] and less changed packages between them [14:32] that is what requests like the curl one is [14:33] this is what I did for curl [14:33] but ok, I found release is broken, now, with some more test, I can diff the testbeds, and find "what" regressed it [14:34] In theory I wouldn't mind if someone were to schedule such tests if they were friendly to the infrastructure [14:35] of course, with less priority [14:35] using this to decide when to force-badtest, or changing the definition of REGRESSION, is where I start to have problems [14:35] also, having somebody running tests (results ignored), with --all-proposed would be nice [14:35] but if people on the release team want to do the former then I can't really stop them [14:36] there's no way to ignore results like that [14:36] I sometimes run against all-proposed, but I don't like to have the green button as result in case [14:36] so, if it becomes green, I try to make migrate the fixex package from proposed too [14:37] 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] (e.g. with k* qt* haskell* perl* this is normal) [14:37] I don't think it's normal with perl [14:37] or with haskell? they have correct dependencies [14:38] yes, perl testsuites should run against perl in proposed, if you rebuild [14:38] nope Laney [14:38] what? [14:38] they sure do [14:38] they are just uninstallable in release, because all the rebuilds are in proposed [14:38] I think I remember haskell-hoogle having this issue [14:38] you're not trying to migrate the release thing [14:39] I don't know what to say, I remember with perl slangasek did the --all-proposed stuff, because of this issue [14:39] (maybe it was somebody else, but the problem was there) [14:39] with haskell, I don't know what the specific problem with perl was [14:40] is that you rebuild 500 packages, and they are installable only with the correspective rebuilds [14:40] there is no strict dependency I would assume, don't remember [14:40] the haskell tooling makes you depend on the hash [14:40] if you're saying that doesn't happen for Test-Depends, well, it should :) [14:41] http://autopkgtest.ubuntu.com/packages/haskell-hgettext/artful/amd64 [14:41] look as example at the first failure [14:42] 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] indeed, or put the test in some "depwait" mode [14:43] so we can aware that the regression is just because the archive is not yet fully in place [14:43] the first failure is an all-proposed run [14:43] and 2, 3, 4, and I get bored now and stop looking [14:44] 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] 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] the first failure [14:46] (the oldest) [14:47] so, maybe rebuilds were not complete then? [14:47] autopkgtest: WARNING: Test dependencies are unsatisfiable with using apt pinning. Retrying with using all packages from proposed [14:47] and it still didn't work [14:47] so I don't blame pinning [14:48] but having a "testbed unsatisfiable status" would have helped at least [14:48] I now agree with you [14:48] (I was just not aware of that pinning feature) [14:53] I wouldn't look forward to implementing that particularly :( [14:53] 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] also, things don't always have owners [14:53] did anyone file a bug about the lxc regression so that its maintainers can look? :-) [14:54] it would be somewhat fixed if britney in Debian would have start to looking at ci too :D [14:54] https://bugs.launchpad.net/ubuntu/+source/lxc/+bug/1713726 ♥ [14:54] Ubuntu bug 1713726 in lxc (Ubuntu) "lxc 2.0.8-0ubuntu6 ADT test failure with linux 4.13.0-7.8" [Undecided,New] [15:06] 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] s/should be ignored/ubuntu official adt containers should be fixed/ I would say :) [15:09] at least diverging makes local testing less effective [15:35] 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] filing bugs for stuff in universe is... strange [16:00] LocutusOfBorg, why so? just becasue we don't want to support things doesn't mean they arn't broken [16:09] apw, yes, but not many looks at universe bugs, unfortunately [16:09] (I do, but I feel alone) === tumbleweed_ is now known as tumbleweed === tdaitx_ is now known as tdaitx [18:39] sorry, please remove lld/arm64, it was built but not available from llvm-toolchain-4.0 [18:39] old binaries left on arm64: lld (from 0.37~exp3) (NBS-proposed remove it) === Kamilion|ZNC is now known as Kamilion [19:06] doko: I see caja-admin and caja-rename are in the Artful NEW. [19:07] They took longer than expected to clear the Debian NEW queue, but we are hotly anticpating them for Ubuntu MATE. [19:07] Could you allow them through please. [20:17] 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] 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] *the problem [20:19] 4 retries (5 attempts) is probably a bit much [20:19] I now have data to show to upstream at least [20:21] Laney: are you interested in ignoring the tests for this version to let e-d-s migrate? [21:02] 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] Could an archive admin please look at ubuntu-mate-guide in NEW when they can? [21:50] Could an archive admin please look at caja-admin and caja-rename in NEW when they can?