| vorlon | doko: don't know if you were aware, but gcc-9 has to be migratable at the same time as glibc because libgphobos has a versioned dep on libc6 on s390x | 00:07 |
|---|---|---|
| -queuebot:#ubuntu-release- Unapproved: fwupd (focal-proposed/main) [1.3.9-2 => 1.3.9-2] (core) | 02:20 | |
| -queuebot:#ubuntu-release- Unapproved: fwupd (focal-proposed/main) [1.3.9-2 => 1.3.9-2] (core) | 02:23 | |
| -queuebot:#ubuntu-release- Unapproved: fwupd (focal-proposed/main) [1.3.9-2 => 1.3.9-2] (core) | 02:23 | |
| vorlon | doko: so how long should this gcc-9 build on amd64 take? since it's been going for 14 hours | 06:19 |
| cpaelzer | hi, can I aske ubuntu-archive to consider accepting javaproperties in focal-new for bug 1866612? | 06:45 |
| ubot5 | bug 1866612 in azure-cli (Ubuntu) "Wrong dependency javaproperties -> pyjavaproperties" [Undecided,In progress] https://launchpad.net/bugs/1866612 | 06:45 |
| vorlon | done | 06:45 |
| -queuebot:#ubuntu-release- New: accepted javaproperties [sync] (focal-proposed) [0.6.0-2] | 06:46 | |
| cpaelzer | Thank you vorlon | 06:47 |
| cpaelzer | I'll try to help this community member to get the further moving bits of this synced so that things will work properly in 20.04 | 06:48 |
| -queuebot:#ubuntu-release- New binary: javaproperties [amd64] (focal-proposed/universe) [0.6.0-2] (no packageset) | 06:48 | |
| cpaelzer | vorlon: you accepted the source in NEW, now the build is complete and as one would expect now the binary is in NEW | 07:06 |
| cpaelzer | would you mind accepting that as well? | 07:06 |
| cpaelzer | in case vorlon is EOD now ubuntu-archive ^^ | 07:07 |
| doko | vorlon: I can find builds talking up to 18h, but also ones getting built in about six. so it should probably finish soonish | 07:15 |
| -queuebot:#ubuntu-release- New: accepted javaproperties [amd64] (focal-proposed) [0.6.0-2] | 07:17 | |
| === pieq_ is now known as pieq | ||
| cpaelzer | doko: https://bugs.launchpad.net/ubuntu/+source/chrony/+bug/1867316 | 07:48 |
| ubot5 | Ubuntu bug 1867316 in chrony (Ubuntu) "FTFBS in Focal armhf/ppc64/s390x" [Undecided,New] | 07:48 |
| cpaelzer | does that mean anything including sys/param.h is FTBFS now? | 07:48 |
| cpaelzer | actually limits.h | 07:49 |
| cpaelzer | doko: to my naive view it seems libgcc-9-dev 9.3.0-1ubuntu2 will break everyone :-/ | 08:05 |
| cpaelzer | oh I see, only because of that long build time vorlon mentioned amd64 still works | 08:07 |
| cpaelzer | as soon as that is built and published it most likely breaks as well | 08:07 |
| cpaelzer | => https://launchpad.net/ubuntu/+source/gcc-9/9.3.0-1ubuntu2 | 08:07 |
| doko | yes, better I'm removing that one from -proposed. amd64 is working because it's not yet built | 08:07 |
| cpaelzer | I might be misjudging the situation, but I'm tempted to ask to abourt that build and use ubuntu-archive powers to remove that new version from proposed | 08:08 |
| cpaelzer | that might avoid a near global FTFBS until we have another gcc-9 pushed and built | 08:09 |
| cpaelzer | ok, found a 5h old dup, which matches when s390x completed | 08:10 |
| RikMills | yes, test building a few things I see the same, except obviously on amd64 | 08:12 |
| cpaelzer | even this will do | 08:12 |
| cpaelzer | echo "#include <limits.h>" | gcc -E -Wp,-v - | 08:13 |
| cpaelzer | breaks on all but amd64 | 08:13 |
| cpaelzer | and once built and published there as well | 08:13 |
| cpaelzer | thanks RikMills for confirming - I was starting to feel I might be the outlier and on a totally crazy island here | 08:13 |
| cpaelzer | I also a few minutes ago found https://bugs.launchpad.net/ubuntu/+source/gcc-9/+bug/1867303 | 08:13 |
| ubot5 | Ubuntu bug 1867316 in gcc-9 (Ubuntu) "duplicate for #1867303 FTFBS in Focal armhf/ppc64/s390x" [Critical,Confirmed] | 08:13 |
| RikMills | yeah, I was just test buildings a few things I wanted to sync for bugfixes, and 'bang' | 08:14 |
| cpaelzer | I know ubuntu-archive should highlight all of you already, but I'm panicing (a bit) sorry, but apw seb128 doko vorlon infinity ^^ | 08:16 |
| RikMills | and seb128's sync did the same https://launchpad.net/ubuntu/+source/gnome-photos/3.34.1-1 | 08:16 |
| seb128 | cpaelzer, hey, sorry I just joined and lack the backlog/context, what do you need exactly? | 08:17 |
| cpaelzer | I think mostly we'd need doko, but for now read https://bugs.launchpad.net/ubuntu/+source/gcc-9/+bug/1867303 | 08:18 |
| RikMills | ggc-9 in proposed is ftbfs the world | 08:18 |
| ubot5 | Ubuntu bug 1867316 in gcc-9 (Ubuntu) "duplicate for #1867303 Almost global FTFBS due to dropping include-fixed dir in 9.3.0-1" [Critical,Confirmed] | 08:18 |
| doko | <doko> yes, better I'm removing that one from -proposed. amd64 is working because it's not yet built | 08:18 |
| cpaelzer | oh you are here | 08:18 |
| cpaelzer | \o/ | 08:18 |
| doko | and I replied | 08:18 |
| cpaelzer | yes that was my triage of the situation as well doko | 08:18 |
| seb128 | why do we get through such disruptive changes and transitions after ff? :( | 08:18 |
| cpaelzer | lol | 08:18 |
| cpaelzer | I was rading from too many channels at once | 08:19 |
| cpaelzer | thanks doko, now that I realized you have seen it I'll leave it to your capable hands | 08:20 |
| * cpaelzer stops panic mode | 08:20 | |
| doko | it was supposed to be a fix for an glibc issue | 08:21 |
| cpaelzer | doko: if you could give a ping here once it is aborted and removed from proposed (for now) that would be great | 08:23 |
| doko | cpaelzer: copy is now done, need to wait for the next publisher run | 08:36 |
| cpaelzer | thank you | 08:40 |
| doko | cpaelzer: now restored, and given back failed builds, afaics those in update_excuses | 09:39 |
| -queuebot:#ubuntu-release- Unapproved: accepted fwupd [amd64] (focal-proposed) [1.3.9-2] | 09:49 | |
| -queuebot:#ubuntu-release- Unapproved: accepted fwupd [armhf] (focal-proposed) [1.3.9-2] | 09:49 | |
| -queuebot:#ubuntu-release- Unapproved: accepted fwupd [arm64] (focal-proposed) [1.3.9-2] | 09:49 | |
| -queuebot:#ubuntu-release- New source: nv-codec-headers (focal-proposed/primary) [9.1.23.1-0ubuntu1] | 09:49 | |
| -queuebot:#ubuntu-release- New: accepted nv-codec-headers [source] (focal-proposed) [9.1.23.1-0ubuntu1] | 09:50 | |
| -queuebot:#ubuntu-release- New: accepted hud [source] (focal-proposed) [14.10+17.10.20170619-0ubuntu3] | 09:50 | |
| cpaelzer | thank you doko | 09:50 |
| bluca | seb128: hi - the GP patch for network-manager-openconnect has moved from debian experimental to unstable now - I also imported all the patches you added downstream in 19.10 and 20.04 | 09:53 |
| bluca | https://tracker.debian.org/pkg/network-manager-openconnect | 09:53 |
| bluca | any chance https://bugs.launchpad.net/ubuntu/+source/network-manager-openconnect/+bug/1857624 could be reconsidered for focal? | 09:53 |
| ubot5 | Ubuntu bug 1857624 in network-manager-openconnect (Ubuntu) "Option Protocol gp (Palo Alto GlobalProtect) missing on nmcli" [Undecided,Confirmed] | 09:53 |
| bluca | unstable now is at the focal state + the 2 GP patches, so a sync would be enough | 09:54 |
| cpaelzer | seb128: ^^ is that a package usually maintained by the desktop team? | 09:54 |
| -queuebot:#ubuntu-release- New binary: nv-codec-headers [amd64] (focal-proposed/universe) [9.1.23.1-0ubuntu1] (no packageset) | 09:55 | |
| seb128 | cpaelzer, not really, but it's not maintained by anyone afaik so we do best effort to keep up with the n-m updates and fixes | 09:56 |
| seb128 | cpaelzer, do you want to do at if it's ok to sync or should I? | 09:56 |
| seb128 | bluca, thx for the fixes & ping | 09:56 |
| cpaelzer | I can take a look and would sync if it is ok in terms of not needing an FFe | 09:57 |
| bluca | thanks! debdiff: http://paste.debian.net/1134759/ | 09:57 |
| cpaelzer | bluca: BTW azure-cli is in -proposed now | 09:58 |
| bluca | thanks! | 09:58 |
| bluca | in the near future (so for 20.10 in Ubuntu terms) I will do the openconnect + network-manager-openconnect updates to the latest upstream versions as well | 09:58 |
| seb128 | cpaelzer, thanks | 09:59 |
| kanashiro | hi, I've been investigating an autopkgtest regression on puppet/5.5.10-4ubuntu1 with the Debian maintainer and we can't reproduce the error locally: https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-focal/focal/amd64/p/puppet/20200310_054016_1a91c@/log.gz | 11:54 |
| kanashiro | is there any known issue with 'hostname --fqdn' inside a testbed? in a local container all the tests pass | 11:54 |
| ahasenack | hi ubuntu-release, if someone could take a look at this nginx FFe bug please, thanks! https://bugs.launchpad.net/ubuntu/+source/nginx/+bug/1867150 | 12:12 |
| ubot5 | Ubuntu bug 1867150 in nginx (Ubuntu) "FFe: nginx: demote bin:libnginx-mod-http-geoip" [Undecided,New] | 12:12 |
| Laney | kanashiro: Here's an example from a running instance | 12:26 |
| Laney | ubuntu@autopkgtest:~$ hostname --fqdn | 12:26 |
| Laney | adt-focal-amd64-systemd-20200313-113041.novalocal | 12:26 |
| Laney | If you're expecting it to be the same as /etc/hostname, I guess that's an assumption that doesn't hold | 12:27 |
| kanashiro | Laney, thanks for the info | 12:47 |
| Laney | kanashiro: np, seems like the tests could be a bit more verbose on failure I would say | 13:21 |
| Laney | like, what was the hostname you supplied and which certs did puppet know about | 13:21 |
| Laney | that kind of thing | 13:22 |
| -queuebot:#ubuntu-release- Unapproved: kmod (bionic-proposed/main) [24-1ubuntu3.2 => 24-1ubuntu3.3] (core) | 14:30 | |
| -queuebot:#ubuntu-release- Unapproved: vala (bionic-proposed/universe) [0.40.17-0ubuntu1 => 0.40.19-0ubuntu1] (ubuntu-desktop) | 16:33 | |
| vorlon | hmm re-queuing the glibc autopkgtests and getting results back would actually speed up the britney runs right now :P> | 16:37 |
| vorlon | ah but queues aren't empty, so no point | 16:38 |
| Laney | After the britney rebase™, we should optimise test submission / retrieval | 16:42 |
| Laney | We could build up the list of tests to submit and then do them all in one go, and try to retrieve all pending test results at once too | 16:47 |
| cjwatson | autopkgtests may suffer from the issues we're seeing in London scalingstacks at the moment FWIW. See #is | 17:03 |
| Laney | Ah, that'll probably explain why I got All The CD Build Failure Mails | 17:05 |
| cjwatson | Dunno exactly what it is but something networky is Very Sad | 17:05 |
| Laney | hmm | 17:17 |
| Laney | perhaps not | 17:17 |
| Laney | https://people.canonical.com/~ubuntu-archive/cd-build-logs/ubuntu/focal/daily-live-20200313.3.log <- no livefs build requested | 17:18 |
| Laney | ER no that's me being stupid and forgetting --live | 17:19 |
| Laney | xnox: take it you saw the arm64 failure :-) | 17:20 |
| xnox | Laney: yes. Will work on the weekend to fix it. | 17:21 |
| Laney | ✅ | 17:22 |
| vorlon | Laney: xnox raised a question of why britney can't get its test results by just downloading the sqlite db and parsing | 17:40 |
| xnox | oooh yes | 17:41 |
| Laney | backchannels eh | 17:41 |
| xnox | Laney: and my other question was how does debian's britney download tests, and do we need to change our autopkgtests, to yeah cherrypick what debian does? | 17:42 |
| Laney | well, currently that is often subject to latency which we don't have when fetching directly from swift | 17:42 |
| xnox | cause debian's britney invalidates out of date results, and re-requests them, and our britney doesn't. | 17:42 |
| Laney | We need to rebase on the upstream version of britney2, and then we can have nice things | 17:42 |
| xnox | my problem was that today we have only 13 britney runs per 24h. I don't care if britney fetches a 15minute stale sqlite db of results; as long as we can have britney complete 30+ runs per 24h. | 17:43 |
| Laney | but the specific question of requesting and fetching tests in the way that Debian does (whatever that is) is not going to be one of them, since we don't use debci | 17:43 |
| xnox | right | 17:43 |
| xnox | cause i think swift latency gain is now killing us due to number of requests we need to make (thousands, when we have glibc & boost & icu & python stuck in proposed) | 17:44 |
| xnox | versus using a stale sqlite3 db and just querieng that, a thousand times, but very quickly. | 17:45 |
| Laney | Well, I don't know about killing, but it could be improved yes | 17:45 |
| xnox | Laney: i can run britney, locally, against the production autopkgtest.ubuntu.com results, right? | 17:45 |
| xnox | to like attempt to profile it / speed a run up? | 17:45 |
| Laney | Sure | 17:45 |
| Laney | But I don't really suggest doing much work on top of our current britney2-ubuntu fork | 17:45 |
| xnox | but it needs swift creds, or are those like public? | 17:45 |
| Laney | No | 17:46 |
| * xnox realises i asked two questions, which a single answer doesn't map to =) | 17:46 | |
| * xnox assumes it needs no creds | 17:46 | |
| Laney | It's public, anyone can use the swift API | 17:46 |
| xnox | ah, cool. | 17:46 |
| xnox | i guess i should look into the rebase then first | 17:47 |
| xnox | even moving a little bit forward / merging a bit will help. | 17:47 |
| xnox | to reduce the delta. | 17:47 |
| Laney | That is a whole task of work on its own which I'm going to get on the roadmap | 17:47 |
| xnox | ooooh | 17:47 |
| Laney | well, try to | 17:47 |
| Laney | but hopefully with success :-) | 17:47 |
| vorlon | ahasenack: why do we have i386-specific bind NBS on https://people.canonical.com/~ubuntu-archive/nbs.html ? | 17:49 |
| ahasenack | vorlon: these come from the old bind9-9.11.x perhaps? | 17:50 |
| vorlon | Laney: latency> who cares? if it takes 1h+ to even poll all the swift URLs | 17:50 |
| ahasenack | src:bind9-9.11.x | 17:50 |
| ahasenack | let me check the sonames | 17:50 |
| vorlon | ahasenack: so specifically, they can't be removed because e.g. libbind-dev is listed as having a dep on them only on i386 | 17:51 |
| Laney | vorlon: ok | 17:51 |
| Laney | so I thought I was clear that polling all of the URLs one by one is dumb, sorry if that wasn't true | 17:51 |
| vorlon | Laney: I think the autopkgtest db updates at a much higher frequency than britney itself does at the moment; and I also don't care if a given britney run has all the latest results when it runs, if we will be able to iterate britney runs more quickly | 17:51 |
| vorlon | right :-) | 17:52 |
| Laney | I wouldn't go as far as specifying what the solution should be right off the bat | 17:52 |
| vorlon | but I also don't think that polling them all should be in the main loop | 17:52 |
| ahasenack | libbind-dev also existed only in src:bind9-9.11.x | 17:52 |
| vorlon | because the results will come $eventually and when they're there they're there and britney will DTRT with them | 17:52 |
| vorlon | ahasenack: but libbind-dev itself is not listed as NBS | 17:52 |
| ahasenack | ah, bind9-libs builds it | 17:53 |
| ahasenack | src_bind9-libs | 17:53 |
| vorlon | so bind9-libs is missing from the i386 whitelist? | 17:53 |
| ahasenack | yep | 17:53 |
| vorlon | or | 17:53 |
| vorlon | do we actually need bind9-libs on i386 or should I manually remove these binaries | 17:53 |
| ahasenack | we had old bind9 9.11.x building for i386 | 17:54 |
| ahasenack | that was libs + server | 17:54 |
| vorlon | it doesn't look like any of the revdeps of bind9-libs in the archive exist on i386 (which makes sense, else this wouldn't have migrated) | 17:54 |
| vorlon | so I'll hand-remove the binaries | 17:54 |
| vorlon | ahasenack: thanks | 17:54 |
| ahasenack | sounds good | 17:54 |
| ahasenack | vorlon: I'm gonna need libmaxminddb on i386 going forward, because bind9 has i386 builds | 18:52 |
| ahasenack | Missing build dependencies: libmaxminddb-dev (>= 1.3.0) (in a ppa) | 18:52 |
| vorlon | ahasenack: done | 19:48 |
| -queuebot:#ubuntu-release- Packageset: Added libmaxminddb to i386-whitelist in focal | 20:07 | |
| xnox | vorlon: Laney: deffo _my_ changes in focal livecd-rootfs regressed the arm64 builds, lolz. | 20:27 |
| ahasenack | thanks vorlon | 20:36 |
| -queuebot:#ubuntu-release- New sync: node-debbundle-es-to-primitive (focal-proposed/primary) [1.2.0+~1.1.4+~1.1.0+~1.1.0+~1.0.1+~1.0.2+~1.0.0+~1.0.1-2] | 20:49 | |
| vorlon | doko: gcc-snapshot also has a versioned glibc dep on s390x, which is precisely the architecture where it ftbfs; retrying now in case the ICE was transient, but if not I'll just remove the s390x binaries from the release pocket | 21:05 |
| vorlon | doko: actually I'll just remove the binary now and we'll go from there | 21:05 |
| Laney | xnox: ah man that reminds me about the hateful 20.04 hardcoded there | 21:11 |
| -queuebot:#ubuntu-release- New binary: linux-signed-azure [amd64] (focal-proposed/main) [5.4.0-1006.6] (core, kernel) | 21:38 | |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!