[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Request for advice on mariadb-10.5 migration schedule



Hello!

> > 1) Builds on armhf stopped working earlier this month due to compiler
> > bug #972564, perhaps in cmake or gcc. Upstream gcc has confirmed at
> > least one issue. There is no schedule on when it will be fixed and
> > there is nothing to my knowledge that I could reasonably do about
> > this.
>
> This, however, is concerning.
>
> > Could you override the excuses to make mariadb-10.5 migrate into testing?
>
> We could, but would that break setups on armhf? What if this doesn't get
> fixed before the release, do we than have to say "sorry armhf, no
> MariaDB for you"? I'd like to avoid that, as I think MariaDB
> functionality is an important one (substantiated by popcon).

Note that it was working earlier this month. The build log at
https://launchpad.net/~mysql-ubuntu/+archive/ubuntu/mariadb-10.5/+builds?build_text=&build_state=all
proves that the same MariaDB 10.5.6-2 build fine on armhf on Oct 21
but regressed by Oct 26 when some build dependency (most likely
cmake/libc) landed in Ubuntu. Same pattern on Debian buildd logs, but
not this clear as the MariaDB revision bumped in between builds.

I don't think it can be that hard to get this regression fixed in the
build toolchain by whatever introduced it. I am just afraid that it
will take several weeks, and having all MariaDB progression stalled
would mess up an otherwise nice transition period for mariadb-10.3 ->
mariadb-10.5.

It is very very unlikely that the armhf GCC/cmake bug would *not* be
fixed before bullseye is in freeze. Therefore I think it would be safe
to allow MariaDB 10.5 into testing now. I am more afraid of the other
issues we don't know about yet, and if MariaDB does not progress into
testing, the time when we start to learn about new bugs (that I can
actually fix in MariaDB packaging) would be postponed and I would end
up having a smaller time frame to fix them later on.


- Otto


Reply to: