> Hey Brian,
>
> I noticed that upload and I'm curious about the motivation. It's really
> early in the cycle and we will get bluez updates and time for archive
> rebuilds later on so I guess the aim is not to get packages built with a new
> LTO by release time. Did we have a buggy LTO version in the archive and are
> we rebuilding things with a fixed version? Which packages do need a rebuild
> and do we need to organize the rebuilds with the owning teams?
>
> Cheers,
> Sebastien Bacher
>
> Le 13/05/2022 à 21:56, Brian Murray a écrit :
> > bluez (5.64-0ubuntu2) kinetic; urgency=medium
> >
> > * No change rebuild to pickup a new version of LTO.
> >
> > Date: Fri, 13 May 2022 12:36:19 -0700
> > Changed-By: Brian Murray <brian@ubuntu.com>
> > Maintainer: Ubuntu Bluetooth team <ubuntu-bluetooth@lists.ubuntu.com>
> > https://launchpad.net/ubuntu/+source/bluez/5.64-0ubuntu2
Hi Seb,
Brian uploaded this at my behest.
If you were to build with LTO against
/usr/lib/x86_64-linux-gnu/bluetooth/plugins/sixaxis.a, which can be found in
libbluetooth-dev, then you would see an error like:
fatal error: bytecode stream in file
'/tmp/tmphqmwfhcw/archive-1/sixaxis_la-sixaxis.o' generated with LTO
version 11.2 instead of the expected 11.3
I did some work last week detecting cases like this and requesting rebuilds.
My view on this was that if we built these proactively, we might prevent some
FTBFS. So not so much a buggy LTO as a mismatched one.
Real-world example of this sort of problem, when attempting to build gyoto
against liblorene-dev:
https://autopkgtest.ubuntu.com/results/autopkgtest-kinetic/kinetic/amd64/g/gyoto/20220503_215822_37721@/log.gz
lto1: fatal error: bytecode stream in file
'/usr/lib/x86_64-linux-gnu/lorene/Lib/liblorene_g.a' generated with LTO
version 11.2 instead of the expected 11.3
-Dan
--
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
