Dear maintainer:

During a rebuild of all packages in unstable, this package failed to build.

Below you will find the last part of the build log (probably the most
relevant part, but not necessarily). If required, the full build log
is available here:

https://people.debian.org/~sanvila/build-logs/202606/

About the archive rebuild: The build was made on virtual machines from AWS,
using sbuild and a reduced chroot with only build-essential packages.

If you cannot reproduce the bug please contact me privately, as I
am willing to provide ssh access to a virtual machine where the bug is
fully reproducible.

If this is really a bug in one of the build-depends, please use
reassign and add an affects on src:galera-4, so that this is still
visible in the BTS web page for this package.

Thanks.
--------------------------------------------------------------------------------
[...]
[ 24%] Building CXX object galerautils/src/CMakeFiles/galerautilsxx.dir/gu_stats.cpp.o
cd /<<PKGBUILDDIR>>/obj-x86_64-linux-gnu/galerautils/src &&  [too-long-redacted] >>/galerautils/src/gu_stats.cpp
[ 24%] Building CXX object galerautils/src/CMakeFiles/galerautilsxx.dir/gu_asio.cpp.o
cd /<<PKGBUILDDIR>>/obj-x86_64-linux-gnu/galerautils/src &&  [too-long-redacted] R>>/galerautils/src/gu_asio.cpp
In file included from /<<PKGBUILDDIR>>/galerautils/src/gu_asio.cpp:26:
/<<PKGBUILDDIR>>/galerautils/src/gu_asio_io_service_impl.hpp:19:10: fatal error: asio/io_service.hpp: No such file or directory
   19 | #include "asio/io_service.hpp"
      |          ^~~~~~~~~~~~~~~~~~~~~
compilation terminated.
make[3]: *** [galerautils/src/CMakeFiles/galerautilsxx.dir/build.make:390: galerautils/src/CMakeFiles/galerautilsxx.dir/gu_asio.cpp.o] Error 1
make[3]: *** Waiting for unfinished jobs....
make[3]: Leaving directory '/<<PKGBUILDDIR>>/obj-x86_64-linux-gnu'
make[2]: *** [CMakeFiles/Makefile2:1547: galerautils/src/CMakeFiles/galerautilsxx.dir/all] Error 2
make[2]: Leaving directory '/<<PKGBUILDDIR>>/obj-x86_64-linux-gnu'
make[1]: *** [Makefile:169: all] Error 2
make[1]: Leaving directory '/<<PKGBUILDDIR>>/obj-x86_64-linux-gnu'
dh_auto_build: error: cd obj-x86_64-linux-gnu && make -j2 INSTALL="install --strip-program=true" VERBOSE=1 returned exit code 2
make: *** [debian/rules:36: binary] Error 25
dpkg-buildpackage: error: debian/rules binary subprocess failed with exit status 2
--------------------------------------------------------------------------------

Hi,

When you do these rebuilds, could you somehow automate to file the bugs on
the packages that caused them, insted of just packages that suffers from
them?

Maybe insted of doing full rebuilds, just rebuild a list of reverse
dependencies each time a library updates or something?

Or at least file with 'severity: normal'? Now anyone who uploads a new
library without proper testing will with your help cause dependencies to be
automatically removed from Debian, putting all the onus on downstreams of
the problem instead of making new updates have better transition planning.

Hello Otto,

thank you for contributing to Debian and maintaining galera-4.

I'm sorry the upload of asio is causing trouble and unnecessary urgency.

Note that asio is currently blocked from migrating to testing. The
excuses page only shows a regression of ableton-link, though. galera-4
isn't showing up here: https://qa.debian.org/excuses.php?package=asio

Markus

Hello Otto.

I see some misunderstandings here.

First and foremost, I'm not a DPL delegate for doing archive rebuilds,
I'm just doing them because I can. If I were a delegate for doing
archive rebuilds, I would have resigned a lot of time ago.

You seem to imply that a build-dependency which causes other packages
to FTBFS is usually the one having the bug.

That's not true in general. Usually, packages have to be adapted to
work with newer libraries all the time.

But even if the proportion was 50%/50%, there is no algorithm to determine
if the blame is in a buggy build-dependency, or it's a case where individual
packages have to be adapted, other than researching the subject, which
takes time and effort and it has never been my job.

Instead of all that, you should consider a FTBFS bug merely as a
statement of a fact: that some package failed during a rebuild.

The root cause is for the maintainers to determine, not for the
person filing the bug.

As I said above, doing archive rebuilds is not even my job.

Making sure that a library update does not break a lot of packages is
the job of library maintainers.

I try to do my part for the library packages I maintain (for example,
packages which FTBFS with gettext 0.26 were reported a lot of time
before it was finally uploaded for unstable) but I can't care about
each library in Debian, that's simply not my job.
particular when using the words "with your help".

As it's often said: "Don't kill the messenger".

Thanks.

Hello,

Bug #1139668 in galera-4 reported by you has been fixed in the
Git repository and is awaiting an upload. You can see the commit
message below and you can check the diff of the fix at:

https://salsa.debian.org/mariadb-team/galera-4/-/commit/a895802e4a7dd84ef1b1b80be50d1a0bbc8fbd38

(this message was generated automatically)
-- 
Greetings

https://bugs.debian.org/1139668

We believe that the bug you reported is fixed in the latest version of
galera-4, which is due to be installed in the Debian FTP archive.

A summary of the changes between this version and the previous one is
attached.

Thank you for reporting the bug, which will now be closed.  If you
have further comments please address them to 1139668@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Otto Kekäläinen <otto@debian.org> (supplier of updated galera-4 package)

(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmaster@ftp-master.debian.org)
Format: 1.8
Date: Thu, 11 Jun 2026 08:08:08 +0000
Source: galera-4
Architecture: source
Version: 26.4.25-3
Distribution: unstable
Urgency: medium
Maintainer: Debian MySQL Maintainers <pkg-mysql-maint@lists.alioth.debian.org>
Changed-By: Otto Kekäläinen <otto@debian.org>
Closes: 1139668
Changes:
 galera-4 (26.4.25-3) unstable; urgency=medium
 .
   [ Luca Boccassi ]
   * Install and use sysusers.d config file
   * Salsa CI: Make shellcheck robust against empty file lists
 .
   [ Otto Kekäläinen ]
   * Port ASIO usage to ASIO 1.33+ API (Closes: #1139668)
   * Salsa CI: Disable new uscan test that is not suitable for Galera
   * Drop redundant `Priority: optional`
   * Drop redundant `Rules-Requires-Root: no`
   * Bump Debian Policy version to 4.7.4
   * Fix spelling
Checksums-Sha1:
 50dc49f2b98050ebeb29fbfce5b25b2bfa06bb36 2447 galera-4_26.4.25-3.dsc
 95c74389c2d253b096050c97f6accc7f1f32da32 34272 galera-4_26.4.25-3.debian.tar.xz
 9a7d86e74ca9b52f8ff4ad62c8fbc68574052f8c 6516 galera-4_26.4.25-3_source.buildinfo
Checksums-Sha256:
 bb6bb29c39cf354fb9f02430f15933ba6cbecbf47cee930e7018249de63a9e17 2447 galera-4_26.4.25-3.dsc
 20eef5cb1e31cece405ea188ce1e413e9664241839cefc2210d8bd9687a3a830 34272 galera-4_26.4.25-3.debian.tar.xz
 e86cb0f257d8cb8e1dbf7aebf1b36878790e8f5d2214d57ef95a5fed4d3d299c 6516 galera-4_26.4.25-3_source.buildinfo
Files:
 173cc0d4896d69b9b99394ae08c0c93d 2447 database optional galera-4_26.4.25-3.dsc
 8b3ddb2ea55f4269bc71691850786398 34272 database optional galera-4_26.4.25-3.debian.tar.xz
 7233fd207d0da1b8c789d038527c8bb0 6516 database optional galera-4_26.4.25-3_source.buildinfo
-----BEGIN PGP SIGNATURE-----

iQIzBAEBCgAdFiEEmbRSsR88dMO0U+RvvthEn87o2ogFAmoqsKkACgkQvthEn87o
2oh9lQ//bRxWRmTJBbaXD+S7hpYENB+jKSm977foUg1EamqlQ9C0Ykv4Ez7wx/ZK
vuJ6RzdT6rxyCeThsRfAe1eFLfoDefgwQ5Brt8JtM2VlAXMzjsMNGY49s4VlI8Hh
6O8iRcYmL1THFBIYr5mhK/U5cmlbz8NPE881kzw/c/ICUC8a93s0Kw5x9dhctqjn
YaY+45Y1vpIAis7Ivssc9i94R7aHeN2vmlkG+6xcRlYW0QV760oF53URQbqnHERw
XyXczyv/NHDrzQCUwNQ7EUjBS6W4+el62xpJPIbRztJvm8lFLpSJrr+REJ6lDjWK
Zr+Gc7b+pDh5CLy0mJ6QiTZOzUtJoDL8CSr+lobKOSjbfmyjirgyj9aPbC1vl3FV
iKZT2W6tPhn0pxujR90rrkg6n7w/g4nlhtzbDuio1QzB0P1sXgsJK06YbHb0aEdF
DEHEmIetZZYDb6wtee5kiZIuauZUJuXvLY3fffVH7VcvPcmxvgb56xt8DRi+OpJi
EUvp9dFktf0xiIQ1QFIHhFg9z4d6JBtFnBNISkgdl+4wMysa7ZWBwnfBSLzWweiS
0NNxIlAn2cB4kb5dtDrkfWXFJm+u4SsQmUDkF19jTXrlsOotSyta59SXxBQA5z6f
EU6SerYE6/GCmuU/HGAB478yq78N5WKP6B2lnUkEi/GPDk8fhBw=
=VDKs
-----END PGP SIGNATURE-----

Hi,

I fixed this for Galera now in a quick defensive upload:
https://tracker.debian.org/news/1762331/accepted-galera-4-26425-3-source-into-unstable/

It would be nicer though if those FTBFS bugs were not 'severe' and
less urgent, so that there is time to e.g. import new upstream that
has this and other fixes included and thus spend overall less
maintenance work on a single package.

If you want to know in advance that your package will break, you have
to talk with the maintainers of libraries which break other packages,
not to me.

When I'm on the other side, I really try to do my part: For both
gettext 0.26 and gettext 1.0, I started with "normal" when the package
was available in a private repository, then raised to "important"
after uploading for experimental, and only raise to serious when the
package is in unstable.

But as a QA tester, once that a package fails to build from source in
a release architecture like amd64, the right severity is "serious"
according to both Debian Policy and Release Policy.

Note that the effect of reporting bugs as "important" and raising them
to "serious" after N weeks would be the same as reporting the bugs
as "serious" and raising the standard autoremoval time by N weeks.

So, IMO, what you really want is a raise in the autoremoval time,
and we don't need to make the bug reporting thing a two-stage process.

In either case, if you really need more time to fix a RC bug, you
can "ping" the bug (by sending *anything* to the bug address) and
the autoremoval (if already started) will be delayed by some amount
of time.

Thanks.

Hi,

...

Yes, I know how to test my *own* packages. Moreover I maintain ratt in
Debian, which most people use for this, and I mentored the development
of reverse dependency build automation in Salsa CI for this kind of
testing.

What I was trying to explain is that your AUTORM bugs will cause
urgent issues for dependant packages (on a Debian scale 3-4 weeks is
somewhat urgent) that are not maintained by *different people* than
the package that broke builds.

..

This might be in accordance with the policy, but I am just explaining
the viewpoint of a packager who currently has 3 AUTORM bugs open, even
after fixing most of them recently. It feel stressful to get the
AUTORM bug reports. Maybe you can do something to alleviate such a
feeling, perhaps file bugs with lower severity and wait longer before
raising the severity. Even better if there would be some mechanism to
put the burden more on the person who uploaded the package that
triggered the failure to actually test it (which is nowadays very
easy) and not let them "off the hook" that easily and put 100% of the
burden on the maintainers of dependent packages.

I don't have solution on the top of my mind, just letting you know how
it "feels" right now.