| 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:29 |
|---|---|---|
| -queuebot:#ubuntu-release- New binary: golang-github-go-macaron-captcha [amd64] (artful-proposed/universe) [0.0~git20170330.0.cbfb9d9-1] (no packageset) | 00:38 | |
| 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:49 |
| 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:55 |
| -queuebot:#ubuntu-release- New: accepted golang-github-go-macaron-captcha [amd64] (artful-proposed) [0.0~git20170330.0.cbfb9d9-1] | 00:56 | |
| -queuebot:#ubuntu-release- Unapproved: gnutls26 (trusty-proposed/main) [2.12.23-12ubuntu2.9 => 2.12.23-12ubuntu2.10] (core) | 06:13 | |
| LocutusOfBorg | doko, I saw them because jbicha pinged me *after* not before of course | 06:21 |
| 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:22 |
| LocutusOfBorg | I put it in queue 12h before noticing the bugs | 06:23 |
| 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:24 |
| LocutusOfBorg | the package uses functions such as tjDecompressHeader2, provided only by that library | 06:29 |
| LocutusOfBorg | not really sure how can we avoid that | 06:29 |
| -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) | 07:13 | |
| -queuebot:#ubuntu-release- Unapproved: virt-manager (zesty-proposed/universe) [1:1.3.2-3ubuntu4 => 1:1.3.2-3ubuntu6] (no packageset) | 08:34 | |
| cpaelzer | could one please reject the shameful mistake of version number increase in zesty-unapproved being virt-manager 1:1.3.2-3ubuntu6? | 08:40 |
| apw | cpaelzer, looking | 08:50 |
| -queuebot:#ubuntu-release- Unapproved: rejected virt-manager [source] (zesty-proposed) [1:1.3.2-3ubuntu6] | 08:51 | |
| 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:52 |
| cpaelzer | thanks apw | 08:53 |
| 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:54 | |
| 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 | 08:59 |
| 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:01 |
| -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:02 |
| -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:03 | |
| -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:04 |
| === santa is now known as Guest88511 | ||
| 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:21 |
| 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:36 |
| 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:37 |
| sil2100 | Thanks! | 09:38 |
| LocutusOfBorg | thanks Laney for having a look! | 09:47 |
| Laney | LocutusOfBorg: Back up | 10:09 |
| LocutusOfBorg | thanks for the work! | 10:53 |
| === santa is now known as Guest19413 | ||
| 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:09 |
| ubot5 | Ubuntu bug 1706248 in slof (Ubuntu) "[FFE] SLOF dhcp request doesn't include client architecture code 93" [Medium,Confirmed] | 12:09 |
| flocculant | cpaelzer: thanks for finding that virt-manager issue - I've been scratching my head for a couple of weeks :) | 12:24 |
| cpaelzer | flocculant: which one actually :-) | 12:28 |
| cpaelzer | flocculant: I happen to hack on a few the recent days | 12:28 |
| flocculant | bug 1714638 | 12:29 |
| ubot5 | 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 |
| 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 | 12:29 |
| === santa is now known as Guest56020 | ||
| -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:12 | |
| === Guest56020 is now known as santa_ | ||
| 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:16 |
| ubot5 | 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:16 |
| -queuebot:#ubuntu-release- Unapproved: accepted walinuxagent [source] (zesty-proposed) [2.2.16-0ubuntu1~17.04.1] | 13:22 | |
| -queuebot:#ubuntu-release- Unapproved: accepted walinuxagent [source] (xenial-proposed) [2.2.16-0ubuntu1~16.04.1] | 13:23 | |
| -queuebot:#ubuntu-release- Unapproved: accepted walinuxagent [source] (trusty-proposed) [2.2.16-0ubuntu1~14.04.1] | 13:24 | |
| 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:27 |
| 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:28 |
| 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:29 |
| 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:30 |
| apw | rbalint, i don't see anything in there warrenting it .. so i'd say you are good | 13:31 |
| rbalint | apw: ok thanks! | 13:32 |
| 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:15 |
| 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:16 |
| ubot5 | 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 |
| ubot5 | bug 1714506 in gnutls28 (Ubuntu Zesty) "libgnutls30 OCSP verification bug" [High,In progress] https://launchpad.net/bugs/1714506 | 14:16 |
| === santa is now known as Guest46152 | ||
| -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:18 | |
| apw | juliank, indeed those look unreleased to you for sure | 14:19 |
| apw | juliank, ok hinted | 14:23 |
| juliank | apw: thanks | 14:24 |
| LocutusOfBorg | apw, the same happens on curl, all of them are regressed in release | 14:24 |
| 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:25 |
| 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:26 |
| 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:27 |
| 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:28 |
| 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:29 |
| Laney | anyway, the main problem I have is accepting an ever worsening baseline | 14:30 |
| 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:31 |
| 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:32 |
| 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:33 |
| Laney | In theory I wouldn't mind if someone were to schedule such tests if they were friendly to the infrastructure | 14:34 |
| 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:35 |
| 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:36 |
| 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:37 |
| 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:38 |
| 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:39 |
| 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:40 |
| LocutusOfBorg | http://autopkgtest.ubuntu.com/packages/haskell-hgettext/artful/amd64 | 14:41 |
| LocutusOfBorg | look as example at the first failure | 14:41 |
| 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:42 |
| 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:43 |
| 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:44 |
| 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:46 |
| 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:47 |
| 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:48 |
| 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:53 |
| 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 ♥ | 14:54 |
| ubot5 | Ubuntu bug 1713726 in lxc (Ubuntu) "lxc 2.0.8-0ubuntu6 ADT test failure with linux 4.13.0-7.8" [Undecided,New] | 14:54 |
| 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:06 |
| 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:09 |
| 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:35 |
| LocutusOfBorg | filing bugs for stuff in universe is... strange | 15:39 |
| apw | LocutusOfBorg, why so? just becasue we don't want to support things doesn't mean they arn't broken | 16:00 |
| LocutusOfBorg | apw, yes, but not many looks at universe bugs, unfortunately | 16:09 |
| LocutusOfBorg | (I do, but I feel alone) | 16:09 |
| === tumbleweed_ is now known as tumbleweed | ||
| === tdaitx_ is now known as tdaitx | ||
| 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) | 18:39 |
| === Kamilion|ZNC is now known as Kamilion | ||
| flexiondotorg | doko: I see caja-admin and caja-rename are in the Artful NEW. | 19:06 |
| 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. | 19:07 |
| 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:17 |
| 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:18 |
| Laney | 4 retries (5 attempts) is probably a bit much | 20:19 |
| jbicha | I now have data to show to upstream at least | 20:19 |
| jbicha | Laney: are you interested in ignoring the tests for this version to let e-d-s migrate? | 20:21 |
| 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:02 |
| tsimonq2 | Could an archive admin please look at ubuntu-mate-guide in NEW when they can? | 21:22 |
| flexiondotorg | Could an archive admin please look at caja-admin and caja-rename in NEW when they can? | 21:50 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!