Re: Second Kinetic Kudu test rebuild
On Tue, Sep 20, 2022 at 9:39 PM Steve Langasek wrote: > > On Tue, Sep 20, 2022 at 12:16:37PM +0200, Christian Ehrhardt wrote: > > > But by the related discussions it seems pgsql isn't ready for llvm-15 yet > > and changing the symbol to overcome the build error might lead to more > > subtle and sinister issues later on. > > I guess to avoid unknown further fallout in Kinetic, instead of trying > > to fix the bug in pgsql partially to fail later it is better - for now - to > > change the pgsql build dependency to llvm-14-dev. > > AFAICS libllvm14 + libllvm15 are in main in Kinetic still and postgres as > > well as maybe others will need to stick with the safer one for now. > > > For a minimal rant, postgresql just moved to llvm 14, also in Debian llvm-15 > > is only in experimental. Who knows how many more subtle changes there are > > breaking things (also in other packages). It might have been a bit too > > aggressive to move that into kinetic-release so much after feature > > freeze ([5] shows 14th Sept). It seems to be the same core-lib/toolchain > > discussion we have too often. > > The rationale for allowing late landing of llvm-defaults to date has been > that almost no packages in the archive build-depend on the unversioned > -defaults packages *because* the behavior changes frequently in incompatible > ways. It is thus not realistic that we ship only one version of > llvm-toolchain in a release (despite the small number of > reverse-build-dependencies vs gcc), and the target of -defaults matters much > less. Thanks for the explanation, it always helps to follow the thoughts behind why things happened. > We should make it a condition of this late landing that > reverse-build-dependencies of llvm-defaults get build-tested after the > update, and any that prove incompatible move to a versioned build-dep. Great idea, that (switch to versioned dep) is exactly what I did to resolve our case. And I believe it would indeed help if those builds could be checked as part of landing of the new version. > As far as this being experimental-only, there are lots of reasons why a > package might be in experimental that may or may not be relevant to Ubuntu. > It is not experimental upstream but has had its GA release, and that's the > version that we have in kinetic. > > -- > Steve Langasek Give me a lever long enough and a Free OS > Debian Developer to set it on, and I can move the world. > Ubuntu Developer https://www.debian.org/ > slanga...@ubuntu.com vor...@debian.org -- Christian Ehrhardt Senior Staff Engineer, Ubuntu Server Canonical Ltd -- ubuntu-server mailing list ubuntu-server@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-server More info: https://wiki.ubuntu.com/ServerTeam
Re: Second Kinetic Kudu test rebuild
On Tue, Sep 20, 2022 at 12:16:37PM +0200, Christian Ehrhardt wrote: > But by the related discussions it seems pgsql isn't ready for llvm-15 yet > and changing the symbol to overcome the build error might lead to more > subtle and sinister issues later on. > I guess to avoid unknown further fallout in Kinetic, instead of trying > to fix the bug in pgsql partially to fail later it is better - for now - to > change the pgsql build dependency to llvm-14-dev. > AFAICS libllvm14 + libllvm15 are in main in Kinetic still and postgres as > well as maybe others will need to stick with the safer one for now. > For a minimal rant, postgresql just moved to llvm 14, also in Debian llvm-15 > is only in experimental. Who knows how many more subtle changes there are > breaking things (also in other packages). It might have been a bit too > aggressive to move that into kinetic-release so much after feature > freeze ([5] shows 14th Sept). It seems to be the same core-lib/toolchain > discussion we have too often. The rationale for allowing late landing of llvm-defaults to date has been that almost no packages in the archive build-depend on the unversioned -defaults packages *because* the behavior changes frequently in incompatible ways. It is thus not realistic that we ship only one version of llvm-toolchain in a release (despite the small number of reverse-build-dependencies vs gcc), and the target of -defaults matters much less. We should make it a condition of this late landing that reverse-build-dependencies of llvm-defaults get build-tested after the update, and any that prove incompatible move to a versioned build-dep. As far as this being experimental-only, there are lots of reasons why a package might be in experimental that may or may not be relevant to Ubuntu. It is not experimental upstream but has had its GA release, and that's the version that we have in kinetic. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developer https://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: PGP signature -- ubuntu-server mailing list ubuntu-server@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-server More info: https://wiki.ubuntu.com/ServerTeam
Re: Second Kinetic Kudu test rebuild
freeradius was a flaky failure, the retry was successful and the package is gone from the FTBFS list. On Mon, Sep 19, 2022 at 6:13 PM Andreas Hasenack wrote: > > I checked pam-p11 and freeradius. > > pam-p11 is legit, and I filed a bug[1] for it. I tested on s390x and > ppc64el and the ftbfs happens there indeed. > > freeradius looked odd, and when I retried in an s390x VM with > kinetic-proposed, it passed. I asked Graham on irc if he could retry > it on his ppa, or if I should upload a no-change rebuild (probably the > former is best). > > 1. https://bugs.launchpad.net/ubuntu/+source/pam-p11/+bug/1990194 > > On Mon, Sep 19, 2022 at 8:45 AM Graham Inggs wrote: > > > > The second test rebuild of Kinetic Kudu was started on September 14, > > 2022 for all architectures, all components. The rebuild is finished > > for the main component on all architectures, finished for > > universe/multiverse on amd64, i386 and ppc64el, and still running on > > the other architectures. > > > > Results (please also look at the superseded builds) can be found at > > > > https://people.canonical.com/~ginggs/ftbfs-report/test-rebuild-20220914-kinetic-kinetic.html > > > > Additional build failures for packages in kinetic-proposed (not yet > > migrated to kinetic) can be found at > > > > http://qa.ubuntuwire.com/ftbfs/ > > > > Please help fixing the build failures. > > > > Graham > > > > -- > > ubuntu-devel mailing list > > ubuntu-de...@lists.ubuntu.com > > Modify settings or unsubscribe at: > > https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel -- ubuntu-server mailing list ubuntu-server@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-server More info: https://wiki.ubuntu.com/ServerTeam
Re: Second Kinetic Kudu test rebuild
On Tue, Sep 20, 2022 at 7:55 AM Bryce Harrington wrote: > > * nbd is a 'Connection reset by peer' network error, and might be a flaky > build. Might be worth retrying the build once just in case that's it. > > > * spice appears to be suffering from this upstream bug, which has a patch: > - https://gitlab.freedesktop.org/spice/spice-common/-/issues/5 # spice That is already in 0.15.0-3 and 0.15.0-4 added openssl fixes which we had in 0.15.0-2ubuntu2. So it seems to need just a merge to resolve (which is functionally the same, but nicer than just picking [1] Reproduced locally, confirmed to be fixed with the merge. PPA and MP up for the team to have a look, expect this to be fixed soon. # qemu In addition qemu is on the list and one more likely to be serviced and therefore rebuilt often. We (and Foundations for the gcc part) have been working on qemu via bug 1988710 for a while now and it is fixed as of last night. # Postgresql Postgresql built a month ago [2] just fine which was on llvm 1:14.0.6-2. Since then llvm has transitioned to 1:15.0.0-2 in kinetic and is now breaking this [3]. Per upstream latest postgresql 14.x and even the main branch still has that code. A few llvm15 changes landed there, but not enough to consider it compatible. If only looking at llvm the compiler suggested rename seems to be correct root@j:~# grep -Hrn 'SymbolMapPair;' /usr/include/ /usr/include/llvm-c-14/llvm-c/Orc.h:125:} LLVMJITCSymbolMapPair; root@k:~# grep -Hrn 'SymbolMapPair;' /usr/include/ /usr/include/llvm-c-15/llvm-c/Orc.h:126:} LLVMOrcCSymbolMapPair; This was changed here [4]. But by the related discussions it seems pgsql isn't ready for llvm-15 yet and changing the symbol to overcome the build error might lead to more subtle and sinister issues later on. I guess to avoid unknown further fallout in Kinetic, instead of trying to fix the bug in pgsql partially to fail later it is better - for now - to change the pgsql build dependency to llvm-14-dev. AFAICS libllvm14 + libllvm15 are in main in Kinetic still and postgres as well as maybe others will need to stick with the safer one for now. For a minimal rant, postgresql just moved to llvm 14, also in Debian llvm-15 is only in experimental. Who knows how many more subtle changes there are breaking things (also in other packages). It might have been a bit too aggressive to move that into kinetic-release so much after feature freeze ([5] shows 14th Sept). It seems to be the same core-lib/toolchain discussion we have too often. I have a test PPA and MP up for the team to have a look at my suggested fix. [1]: https://gitlab.freedesktop.org/spice/spice-common/-/commit/a7b5474bf808934cf0ee1107a58d5f4d97b9afbf [2]: https://launchpad.net/ubuntu/+source/postgresql-14/14.5-1 [3]: https://launchpadlibrarian.net/617875520/buildlog_ubuntu-kinetic-amd64.postgresql-14_14.5-1_BUILDING.txt.gz [4]: https://github.com/llvm/llvm-project/commit/b425f556935c1105dea59871a46caa7af2d378ad [5]: https://launchpad.net/ubuntu/+source/llvm-toolchain-15 > * mako's test error seems to be a change in the html formatting, which expects > to see this in the page: > > > > but now sees > > class="syntax-highlightedtable"> > > This appears to match this debian bug: > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1015048 > > which was fixed by just pulling a newer upstream. Poking through git I > suspect it's fixed by: > > > https://github.com/sqlalchemy/mako/commit/eae8e3aaa420f4305450e4f1a55881ea9a46bba0 > > Bryce > > On Mon, Sep 19, 2022 at 06:13:11PM -0300, Andreas Hasenack wrote: > > I checked pam-p11 and freeradius. > > > > pam-p11 is legit, and I filed a bug[1] for it. I tested on s390x and > > ppc64el and the ftbfs happens there indeed. > > > > freeradius looked odd, and when I retried in an s390x VM with > > kinetic-proposed, it passed. I asked Graham on irc if he could retry > > it on his ppa, or if I should upload a no-change rebuild (probably the > > former is best). > > > > 1. https://bugs.launchpad.net/ubuntu/+source/pam-p11/+bug/1990194 > > > > On Mon, Sep 19, 2022 at 8:45 AM Graham Inggs wrote: > > > > > > The second test rebuild of Kinetic Kudu was started on September 14, > > > 2022 for all architectures, all components. The rebuild is finished > > > for the main component on all architectures, finished for > > > universe/multiverse on amd64, i386 and ppc64el, and still running on > > > the other architectures. > > > > > > Results (please also look at the superseded builds) can be found at > > > > > > https://people.canonical.com/~ginggs/ftbfs-report/test-rebuild-20220914-kinetic-kinetic.html > > > > > > Additional build failures for packages in kinetic-proposed (not yet > > > migrated to kinetic) can be found at > > > > > > http://qa.ubuntuwire.com/ftbfs/ > > > > > > Please help fixing the build failures. > > > > > > Graham > > > > > > -- > > > ubuntu-devel mailing list > > > ubuntu-de...@lists.ubuntu.com > > > Modify settings or unsu
Re: Second Kinetic Kudu test rebuild
* nbd is a 'Connection reset by peer' network error, and might be a flaky build. Might be worth retrying the build once just in case that's it. * spice appears to be suffering from this upstream bug, which has a patch: - https://gitlab.freedesktop.org/spice/spice-common/-/issues/5 * mako's test error seems to be a change in the html formatting, which expects to see this in the page: but now sees This appears to match this debian bug: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1015048 which was fixed by just pulling a newer upstream. Poking through git I suspect it's fixed by: https://github.com/sqlalchemy/mako/commit/eae8e3aaa420f4305450e4f1a55881ea9a46bba0 Bryce On Mon, Sep 19, 2022 at 06:13:11PM -0300, Andreas Hasenack wrote: > I checked pam-p11 and freeradius. > > pam-p11 is legit, and I filed a bug[1] for it. I tested on s390x and > ppc64el and the ftbfs happens there indeed. > > freeradius looked odd, and when I retried in an s390x VM with > kinetic-proposed, it passed. I asked Graham on irc if he could retry > it on his ppa, or if I should upload a no-change rebuild (probably the > former is best). > > 1. https://bugs.launchpad.net/ubuntu/+source/pam-p11/+bug/1990194 > > On Mon, Sep 19, 2022 at 8:45 AM Graham Inggs wrote: > > > > The second test rebuild of Kinetic Kudu was started on September 14, > > 2022 for all architectures, all components. The rebuild is finished > > for the main component on all architectures, finished for > > universe/multiverse on amd64, i386 and ppc64el, and still running on > > the other architectures. > > > > Results (please also look at the superseded builds) can be found at > > > > https://people.canonical.com/~ginggs/ftbfs-report/test-rebuild-20220914-kinetic-kinetic.html > > > > Additional build failures for packages in kinetic-proposed (not yet > > migrated to kinetic) can be found at > > > > http://qa.ubuntuwire.com/ftbfs/ > > > > Please help fixing the build failures. > > > > Graham > > > > -- > > ubuntu-devel mailing list > > ubuntu-de...@lists.ubuntu.com > > Modify settings or unsubscribe at: > > https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel > > -- > ubuntu-server mailing list > ubuntu-server@lists.ubuntu.com > https://lists.ubuntu.com/mailman/listinfo/ubuntu-server > More info: https://wiki.ubuntu.com/ServerTeam -- ubuntu-server mailing list ubuntu-server@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-server More info: https://wiki.ubuntu.com/ServerTeam
Re: Second Kinetic Kudu test rebuild
I checked pam-p11 and freeradius. pam-p11 is legit, and I filed a bug[1] for it. I tested on s390x and ppc64el and the ftbfs happens there indeed. freeradius looked odd, and when I retried in an s390x VM with kinetic-proposed, it passed. I asked Graham on irc if he could retry it on his ppa, or if I should upload a no-change rebuild (probably the former is best). 1. https://bugs.launchpad.net/ubuntu/+source/pam-p11/+bug/1990194 On Mon, Sep 19, 2022 at 8:45 AM Graham Inggs wrote: > > The second test rebuild of Kinetic Kudu was started on September 14, > 2022 for all architectures, all components. The rebuild is finished > for the main component on all architectures, finished for > universe/multiverse on amd64, i386 and ppc64el, and still running on > the other architectures. > > Results (please also look at the superseded builds) can be found at > > https://people.canonical.com/~ginggs/ftbfs-report/test-rebuild-20220914-kinetic-kinetic.html > > Additional build failures for packages in kinetic-proposed (not yet > migrated to kinetic) can be found at > > http://qa.ubuntuwire.com/ftbfs/ > > Please help fixing the build failures. > > Graham > > -- > ubuntu-devel mailing list > ubuntu-de...@lists.ubuntu.com > Modify settings or unsubscribe at: > https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel -- ubuntu-server mailing list ubuntu-server@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-server More info: https://wiki.ubuntu.com/ServerTeam
