Hi Otto, On 29-10-2020 16:28, Otto Kekäläinen wrote: > I kindly ask assistance from the Debian release team what to do about > MariaDB 10.5. I think it's good that you reach out. > I have been working on MariaDB 10.5 packaging since August[1] and I've > had it in unstable since early September[2]. It is currently however > stuck on two migration excuses: To start with item 2: > 2) autopkgtest for mariadb-10.3/1:10.3.24-2 fail on i386 (and armhf > when it build earlier this month). The test is installing > "mariadb-server" which in unstable pulls in mariadb-10.5. I silenced > this false positive (or indifferent failure of access denied vs > password invalid) for mariadb-10.5 but I cannot upload a new > mariadb-10.3 with autopkgtest fixes anymore. As it's the intention to not have mariadb-10.3 in bullseye, this to me doesn't really seems concerning. I don't get why you wouldn't be able to upload a new version of mariadb-10.3 with a fix, I guess you mean "can't do it without major changes to the packaging as most binary packages were taken over by mariadb-10.5". > 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). > I would like to have mariadb-10.5 in bullseye and any remnants of > mariadb-10.3 (and even older) removed from unstable/testing, but this > migration process is now stalled on this, and I am afraid that if I > don't push it, there would not be a safe margin of time to get more > testing feedback and weed out any other potential issues in > testing/bullseye. So, if you really want to move this forward, and you don't want to dive into the toolchain, how do you propose to support armhf? Paul
Attachment:
signature.asc
Description: OpenPGP digital signature