Summary: | dev-db/mariadb: rekeywording for dev-perl/DBD-MariaDB | ||||||
---|---|---|---|---|---|---|---|
Product: | Gentoo Linux | Reporter: | Sam James <sam> | ||||
Component: | Keywording | Assignee: | Gentoo Linux MySQL bugs team <mysql-bugs> | ||||
Status: | IN_PROGRESS --- | ||||||
Severity: | normal | CC: | alpha, arkamar, hppa, hydrapolic, loong, matoro_gentoo, mips, parona, perl, s390 | ||||
Priority: | Normal | Keywords: | CC-ARCHES, SECURITY | ||||
Version: | unspecified | Flags: | nattka:
sanity-check+
|
||||
Hardware: | All | ||||||
OS: | Linux | ||||||
See Also: | https://bugs.gentoo.org/show_bug.cgi?id=927278 | ||||||
Whiteboard: | |||||||
Package list: |
>=dev-db/mariadb-10.11.5-r1:10.11
>=dev-db/mariadb-10.6.15-r1:10.6
dev-perl/DBD-MariaDB
dev-perl/Proc-ProcessTable
<dev-libs/libfmt-10 s390
|
Runtime testing required: | --- | ||||
Bug Depends on: | |||||||
Bug Blocks: | 915511, 917515 | ||||||
Attachments: |
|
Description
Sam James
2023-12-14 06:44:31 UTC
Sanity check failed:
> dev-perl/DBD-MariaDB-1.230.0
> bdepend ~loong stable profile default/linux/loong/22.0/la64v100/lp64d (9 total)
> dev-db/mysql:*
> dev-perl/Proc-ProcessTable
> bdepend ~loong dev profile default/linux/loong/22.0/la64v100/lp64d/desktop/gnome (3 total)
> dev-db/mysql:*
> dev-perl/Proc-ProcessTable
> bdepend ~s390 stable profile default/linux/s390/17.0 (4 total)
> dev-perl/Proc-ProcessTable
*** Bug 913026 has been marked as a duplicate of this bug. *** Sanity check failed:
> dev-perl/DBD-MariaDB-1.230.0
> bdepend ~loong stable profile default/linux/loong/22.0/la64v100/lp64d (9 total)
> dev-db/mysql:*
> bdepend ~loong dev profile default/linux/loong/22.0/la64v100/lp64d/desktop/gnome (3 total)
> dev-db/mysql:*
Hello Sam, would be good to proceed as we need to stabilize a newer version of MariaDB due to security issues, thanks! sec The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=31a91f41b46cbdac7e714fa86126ba3c9e4406d2 commit 31a91f41b46cbdac7e714fa86126ba3c9e4406d2 Author: Sam James <sam@gentoo.org> AuthorDate: 2024-02-03 10:38:45 +0000 Commit: Sam James <sam@gentoo.org> CommitDate: 2024-02-03 10:39:07 +0000 profiles/arch/loong: force dev-perl/DBD-MariaDB[mariadb] No MySQL here. Bug: https://bugs.gentoo.org/919865 Signed-off-by: Sam James <sam@gentoo.org> profiles/arch/loong/package.use.force | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=4a645015b14793aab35252a2916c43ad4244c151 commit 4a645015b14793aab35252a2916c43ad4244c151 Author: Sam James <sam@gentoo.org> AuthorDate: 2024-02-03 10:40:20 +0000 Commit: Sam James <sam@gentoo.org> CommitDate: 2024-02-03 10:40:20 +0000 profiles/arch/loong: mask dev-perl/DBD-MariaDB[mysql] No MySQL here. Note that not use.mask-ing USE=mysql as it has a generic meaning too. Bug: https://bugs.gentoo.org/919865 Signed-off-by: Sam James <sam@gentoo.org> profiles/arch/loong/package.use.mask | 4 ++++ 1 file changed, 4 insertions(+) riscv done matoro, I don't understand why you've changed it from depends on <-> blocks. The point of this bug is to let people get rid of DBD-MySQL. What's dragging it in for you when doing this package list? (In reply to Sam James from comment #9) > matoro, I don't understand why you've changed it from depends on <-> blocks. > > The point of this bug is to let people get rid of DBD-MySQL. What's dragging > it in for you when doing this package list? When I try to emerge dev-db/mariadb:10.11 it pulls in dev-perl/DBD-mysql which then fails to build. See: https://paste.matoro.tk/b1z1sxr (In reply to matoro from comment #10) > (In reply to Sam James from comment #9) > > matoro, I don't understand why you've changed it from depends on <-> blocks. > > > > The point of this bug is to let people get rid of DBD-MySQL. What's dragging > > it in for you when doing this package list? > > When I try to emerge dev-db/mariadb:10.11 it pulls in dev-perl/DBD-mysql > which then fails to build. See: https://paste.matoro.tk/b1z1sxr You need to do mariadb-10.11-r1 which changes the dep, that's why this is a rekeywording bug. (In reply to Sam James from comment #11) > (In reply to matoro from comment #10) > > (In reply to Sam James from comment #9) > > > matoro, I don't understand why you've changed it from depends on <-> blocks. > > > > > > The point of this bug is to let people get rid of DBD-MySQL. What's dragging > > > it in for you when doing this package list? > > > > When I try to emerge dev-db/mariadb:10.11 it pulls in dev-perl/DBD-mysql > > which then fails to build. See: https://paste.matoro.tk/b1z1sxr > > You need to do mariadb-10.11-r1 which changes the dep, that's why this is a > rekeywording bug. You mean 10.11.5-r1? So should package list say >=dev-db/mariadb-10.11.5-r1:10.11 ? Yes -- although it's very weird it has to, given the package list normally handles this fine...? Created attachment 886132 [details]
test summary
Here's my summary of the test suite status on all of the requested architectures (see attachment). How do we want to approach the ones with more drastic failures?
Passes: arm64, ia64, ppc64le
One failure: ppc64, loong64
mips64 has a handful of failures. One due to big-endian.
arm has 2 failures on 10.6, but regresses severely to 10.11.
Many failures: alpha, hppa, ppc
I can open individual bugs for these, but would like to understand if that would be helpful first.
(In reply to matoro from comment #14) > Created attachment 886132 [details] > test summary > > Here's my summary of the test suite status on all of the requested > architectures (see attachment). How do we want to approach the ones with > more drastic failures? > > Passes: arm64, ia64, ppc64le > One failure: ppc64, loong64 > mips64 has a handful of failures. One due to big-endian. > arm has 2 failures on 10.6, but regresses severely to 10.11. > Many failures: alpha, hppa, ppc > > I can open individual bugs for these, but would like to understand if that > would be helpful first. Thank you matoro for testing, actually I only use MariaDB on amd64 where the tests pass, no idea about the others arches, I don't use any of others. However this is KW request, so probably we should proceed if it can be compiled and started, the tests itself may be flaky. A failing test doesn't really mean it won't work, however I do understand it would be great to 100% of success rate. On the other side, it's blocking a security stabilization where users are now stuck with old and vulnerable version. (In reply to Tomáš Mózes from comment #15) > (In reply to matoro from comment #14) > > Created attachment 886132 [details] > > test summary > > > > Here's my summary of the test suite status on all of the requested > > architectures (see attachment). How do we want to approach the ones with > > more drastic failures? > > > > Passes: arm64, ia64, ppc64le > > One failure: ppc64, loong64 > > mips64 has a handful of failures. One due to big-endian. > > arm has 2 failures on 10.6, but regresses severely to 10.11. > > Many failures: alpha, hppa, ppc > > > > I can open individual bugs for these, but would like to understand if that > > would be helpful first. > > Thank you matoro for testing, actually I only use MariaDB on amd64 where the > tests pass, no idea about the others arches, I don't use any of others. > However this is KW request, so probably we should proceed if it can be > compiled and started, the tests itself may be flaky. > > A failing test doesn't really mean it won't work, however I do understand it > would be great to 100% of success rate. On the other side, it's blocking a > security stabilization where users are now stuck with old and vulnerable > version. If this is blocking a kwreq, then let's split it up into two bugs - one for arches blocking the stablereq, one for new arches. Regardless, my vote on this would be to investigate the small failures - ppc64, loong64 - and drop keywords elsewhere. I think it's unlikely to be running a mariadb server on the remaining arches - alpha, arm, hppa, mips, ppc. agreed^2, can you do the split + file bugs for those arches and then a mega bug is ok for the other random failures all in one (hppa etc) (sorry for brevity, on mobile) ia64 done arm done arm64 done ppc done ppc64 done |