[debian-mysql] Bug#1139668: Bug#1117454: Bug#1139668: galera-4: FTBFS: /<<PKGBUILDDIR>>/galerautils/src/gu_asio_io_service_impl.hpp:19:10: fatal error: asio/io_service.hpp: No such file or directory

[Santiago Vila]

On Sat, Jun 13, 2026 at 12:13:52AM +0800, Otto Kekäläinen wrote:

> 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.

I already answered to that, but will do again:

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.