Created attachment 646870 [details] db-mips.txt - dev-lang/perl currently depends on sys-libs/db - dev-lang/perl is currently keyworded for ~mips Subsequently, its pertinent that sys-libs/db:6.0 be eventually keyworded. However, it seems this has gone on like this for too long, and its subsequently a giant mess to fix. I got digging into it, starting with an explicit keywording of sys-libs/db:6.0, and then using a repoman (-d -e y) driven process to find out what breaks, but after it exceeded 100 items (passing through icedtea-bin, and qt in the process), I concluded that I don't have the tools to do this correctly. Deep in the stack I found annoying problems I couldn't make repoman shut up about, so I'm guessing I'm missing some profile love in repoman. eg: > dependency.badinexp media-sound/pulseaudio/pulseaudio-13.0.ebuild: PDEPEND: ~mips(default/linux/mips/17.0/mipsel/multilib/n32) ['>=media-plugins/alsa-plugins-1.0.27-r1[pulseaudio,abi_x86_32(-)?,abi_x86_64(-)?,abi_x86_x32(-)?,abi_mips_n32(-)?,abi_mips_n64(-)?,abi_mips_o32(-)?,abi_riscv_lp64d(-)?,abi_riscv_lp64(-)?,abi_s390_32(-)?,abi_s390_64(-)?]'] > dependency.badinexp media-sound/pulseaudio/pulseaudio-13.0.ebuild: PDEPEND: ~mips(default/linux/mips/17.0/mipsel/multilib/n64) ['>=media-plugins/alsa-plugins-1.0.27-r1[pulseaudio,abi_x86_32(-)?,abi_x86_64(-)?,abi_x86_x32(-)?,abi_mips_n32(-)?,abi_mips_n64(-)?,abi_mips_o32(-)?,abi_riscv_lp64d(-)?,abi_riscv_lp64(-)?,abi_s390_32(-)?,abi_s390_64(-)?]'] > dependency.badinexp media-sound/pulseaudio/pulseaudio-13.0.ebuild: PDEPEND: ~mips(default/linux/mips/17.0/mipsel/multilib/o32) ['>=media-plugins/alsa-plugins-1.0.27-r1[pulseaudio,abi_x86_32(-)?,abi_x86_64(-)?,abi_x86_x32(-)?,abi_mips_n32(-)?,abi_mips_n64(-)?,abi_mips_o32(-)?,abi_riscv_lp64d(-)?,abi_riscv_lp64(-)?,abi_s390_32(-)?,abi_s390_64(-)?]'] > dependency.badinexp media-sound/pulseaudio/pulseaudio-13.0.ebuild: PDEPEND: ~mips(default/linux/mips/17.0/mipsel/n32) ['>=media-plugins/alsa-plugins-1.0.27-r1[pulseaudio,abi_x86_32(-)?,abi_x86_64(-)?,abi_x86_x32(-)?,abi_mips_n32(-)?,abi_mips_n64(-)?,abi_mips_o32(-)?,abi_riscv_lp64d(-)?,abi_riscv_lp64(-)?,abi_s390_32(-)?,abi_s390_64(-)?]'] > dependency.badinexp media-sound/pulseaudio/pulseaudio-13.0.ebuild: PDEPEND: ~mips(default/linux/mips/17.0/mipsel/n64) ['>=media-plugins/alsa-plugins-1.0.27-r1[pulseaudio,abi_x86_32(-)?,abi_x86_64(-)?,abi_x86_x32(-)?,abi_mips_n32(-)?,abi_mips_n64(-)?,abi_mips_o32(-)?,abi_riscv_lp64d(-)?,abi_riscv_lp64(-)?,abi_s390_32(-)?,abi_s390_64(-)?]'] > dependency.badinexp media-sound/pulseaudio/pulseaudio-13.0.ebuild: PDEPEND: ~mips(default/linux/mips/17.0/mipsel/o32) ['>=media-plugins/alsa-plugins-1.0.27-r1[pulseaudio,abi_x86_32(-)?,abi_x86_64(-)?,abi_x86_x32(-)?,abi_mips_n32(-)?,abi_mips_n64(-)?,abi_mips_o32(-)?,abi_riscv_lp64d(-)?,abi_riscv_lp64(-)?,abi_s390_32(-)?,abi_s390_64(-)?]'] > dependency.badinexp media-sound/pulseaudio/pulseaudio-13.0.ebuild: PDEPEND: ~mips(default/linux/mips/17.0/multilib/n32) ['>=media-plugins/alsa-plugins-1.0.27-r1[pulseaudio,abi_x86_32(-)?,abi_x86_64(-)?,abi_x86_x32(-)?,abi_mips_n32(-)?,abi_mips_n64(-)?,abi_mips_o32(-)?,abi_riscv_lp64d(-)?,abi_riscv_lp64(-)?,abi_s390_32(-)?,abi_s390_64(-)?]'] > dependency.badinexp media-sound/pulseaudio/pulseaudio-13.0.ebuild: PDEPEND: ~mips(default/linux/mips/17.0/multilib/n64) ['>=media-plugins/alsa-plugins-1.0.27-r1[pulseaudio,abi_x86_32(-)?,abi_x86_64(-)?,abi_x86_x32(-)?,abi_mips_n32(-)?,abi_mips_n64(-)?,abi_mips_o32(-)?,abi_riscv_lp64d(-)?,abi_riscv_lp64(-)?,abi_s390_32(-)?,abi_s390_64(-)?]'] > dependency.badinexp media-sound/pulseaudio/pulseaudio-13.0.ebuild: PDEPEND: ~mips(default/linux/mips/17.0/multilib/o32) ['>=media-plugins/alsa-plugins-1.0.27-r1[pulseaudio,abi_x86_32(-)?,abi_x86_64(-)?,abi_x86_x32(-)?,abi_mips_n32(-)?,abi_mips_n64(-)?,abi_mips_o32(-)?,abi_riscv_lp64d(-)?,abi_riscv_lp64(-)?,abi_s390_32(-)?,abi_s390_64(-)?]'] > dependency.badinexp media-sound/pulseaudio/pulseaudio-13.0.ebuild: PDEPEND: ~mips(default/linux/mips/17.0/n32) ['>=media-plugins/alsa-plugins-1.0.27-r1[pulseaudio,abi_x86_32(-)?,abi_x86_64(-)?,abi_x86_x32(-)?,abi_mips_n32(-)?,abi_mips_n64(-)?,abi_mips_o32(-)?,abi_riscv_lp64d(-)?,abi_riscv_lp64(-)?,abi_s390_32(-)?,abi_s390_64(-)?]'] > dependency.badinexp media-sound/pulseaudio/pulseaudio-13.0.ebuild: PDEPEND: ~mips(default/linux/mips/17.0/n64) ['>=media-plugins/alsa-plugins-1.0.27-r1[pulseaudio,abi_x86_32(-)?,abi_x86_64(-)?,abi_x86_x32(-)?,abi_mips_n32(-)?,abi_mips_n64(-)?,abi_mips_o32(-)?,abi_riscv_lp64d(-)?,abi_riscv_lp64(-)?,abi_s390_32(-)?,abi_s390_64(-)?]'] > dependency.badinexp media-sound/pulseaudio/pulseaudio-13.0.ebuild: PDEPEND: ~mips(default/linux/mips/17.0/o32) ['>=media-plugins/alsa-plugins-1.0.27-r1[pulseaudio,abi_x86_32(-)?,abi_x86_64(-)?,abi_x86_x32(-)?,abi_mips_n32(-)?,abi_mips_n64(-)?,abi_mips_o32(-)?,abi_riscv_lp64d(-)?,abi_riscv_lp64(-)?,abi_s390_32(-)?,abi_s390_64(-)?]'] And I really didn't want to CC 100+ different maintainers on a huge monobug. So I'll file this bug and hope base-system can push it forwards in some way, even if it turns into punting it onto dependents with their own bugs. I'm also prematurely CCing mips on this, because some insight into this mess is needed on their part, and maybe they need to package.use.mask a whole lot of things to bring this back into a workable situation. ( I was actually hoping to put together a worklist for prefix, but their job is even worse for this, and mips turned up in the process, and it turned up as a lower hanging fruit to target first ... ) If we can't see anyway to make headway on this, it *might* be time to start thinking about de-mipsing dev-lang/perl, but based on what I see, that's basically a "kill off mips" situation. But I have a strong feeling that the data I collected using repoman is critically flawed for reasons I don't yet understand. Attached is as far as I got before I gave up on working out the dependencies that also needed keywording, with a stats blob at the bottom with maintainers in, so you can understand *why* I gave up.
> If we can't see anyway to make headway on this, it *might* be time to start thinking about de-mipsing dev-lang/perl, but based on what I see, that's basically a "kill off mips" situation. Does dev-lang/perl actually need db-6.0? Older versions of db are keyworded on mips, and they are not going to be removed for the foreseeable future. Also, pkgcheck doesn't complain when I add '~mips' to sys-libs/db-6.0.35-r2. repoman complains about all version when I run it with "-e y". I think masking the java USE flag would suffice.
(In reply to Mike Gilbert from comment #1) > > If we can't see anyway to make headway on this, it *might* be time to start thinking about de-mipsing dev-lang/perl, but based on what I see, that's basically a "kill off mips" situation. > > Does dev-lang/perl actually need db-6.0? Older versions of db are keyworded > on mips, and they are not going to be removed for the foreseeable future. > > Also, pkgcheck doesn't complain when I add '~mips' to sys-libs/db-6.0.35-r2. > > repoman complains about all version when I run it with "-e y". I think > masking the java USE flag would suffice. Sure, but I am just thinking about the future, hence, there's no panic here. But seeing all the other major arches have it keyworded, I'm just kicking the tires. *Apparently* the `java` use flag is *already* masked. profiles/arch/mips/use.mask:# masked because of silly java deps with gnome (we have no jre on mips) profiles/arch/mips/use.mask:# There is no java in this profile (if there is it must be available). Without profiles/arch/mips/use.mask:java So Repoman is being utterly stupid and not helping at all. (Or maybe there are mips profiles that don't properly inherit mips/use.mask? idk, the whole thing is a mess)
Unable to check for sanity: > package masked: sys-libs/db-18.1.32
Unable to check for sanity: > no match for package: sys-libs/db-6.0.35-r2
All sanity-check issues have been resolved
Unable to check for sanity: > no match for package: sys-libs/db-6.0.35-r3
The dependency calculation seems off when run outside of a MIPS environment. Likely a bug somewhere in our profiles setup. This is what I get on my SGI Octane system when I keyword sys-libs/db-6.0.35-r4: # emerge =sys-libs/db-6.0.35-r4 -pv These are the packages that would be merged, in order: Calculating dependencies ... done! [ebuild NS ] sys-libs/db-6.0.35-r4:6.0::gentoo [4.8.30-r4:4.8::gentoo] USE="-cxx -doc -examples (-java) -tcl -test" 0 KiB Total: 1 package (1 in new slot), Size of downloads: 0 KiB So it looks easy to test-compile this. I'll do that and add our keyword if it compiles cleanly. I don't know of a good test-case, though so a compile test will have to do.
(In reply to Joshua Kinard from comment #8) > The dependency calculation seems off when run outside of a MIPS environment. > Likely a bug somewhere in our profiles setup. This is what I get on my SGI > Octane system when I keyword sys-libs/db-6.0.35-r4: Do you mean the missing indication that it's unkeyworded? That seems odd to me too. Are you sure there's no weird e.g. package.keywords in /etc/portage/* or similar? grep -rsin "sys-libs/db" /etc/portage emerge --info > > # emerge =sys-libs/db-6.0.35-r4 -pv > > These are the packages that would be merged, in order: > > Calculating dependencies ... done! > [ebuild NS ] sys-libs/db-6.0.35-r4:6.0::gentoo [4.8.30-r4:4.8::gentoo] > USE="-cxx -doc -examples (-java) -tcl -test" 0 KiB > > Total: 1 package (1 in new slot), Size of downloads: 0 KiB > > So it looks easy to test-compile this. I'll do that and add our keyword if > it compiles cleanly. I don't know of a good test-case, though so a compile > test will have to do. Run the test suite with FEATURES=test? (do --with-test-deps without the FEATURES first)
(In reply to Sam James from comment #9) > (In reply to Joshua Kinard from comment #8) > > The dependency calculation seems off when run outside of a MIPS environment. > > Likely a bug somewhere in our profiles setup. This is what I get on my SGI > > Octane system when I keyword sys-libs/db-6.0.35-r4: > > Do you mean the missing indication that it's unkeyworded? That seems odd to > me too. > > Are you sure there's no weird e.g. package.keywords in /etc/portage/* or > similar? > > grep -rsin "sys-libs/db" /etc/portage Nothing returned for this command. That means the USE masking for us is happening at the profile level. I suspect the Qt and other GUI-related packages were getting dragged in by the 'java' USE not being evaluated correctly by Kent's repoman run. Java and MIPS have a "complicated" history, so it's been masked for the longest time IIRC. > emerge --info See attachment in a few minutes. Note this machine is behind quite a bit, as I haven't updated it in 2+ months. > > > > # emerge =sys-libs/db-6.0.35-r4 -pv > > > > These are the packages that would be merged, in order: > > > > Calculating dependencies ... done! > > [ebuild NS ] sys-libs/db-6.0.35-r4:6.0::gentoo [4.8.30-r4:4.8::gentoo] > > USE="-cxx -doc -examples (-java) -tcl -test" 0 KiB > > > > Total: 1 package (1 in new slot), Size of downloads: 0 KiB > > > > So it looks easy to test-compile this. I'll do that and add our keyword if > > it compiles cleanly. I don't know of a good test-case, though so a compile > > test will have to do. > > Run the test suite with FEATURES=test? (do --with-test-deps without the > FEATURES first) The ebuild itself restricts testing it looks: Compile test ran fine, so I'll push the addition of the ~mips keyword. I'll circle back to running the testsuite later on after I catch this machine up to more recent packages. It's not the fastest thing on the planet anymore.
Created attachment 708819 [details] emerge --info from running MIPS system 20210515
(In reply to Joshua Kinard from comment #10) > The ebuild itself restricts testing it looks: Ignore this bit, typed in error and forgot to delete.
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=ea7f9b143ea1b003ed79aff53e53f176ad6e9e66 commit ea7f9b143ea1b003ed79aff53e53f176ad6e9e66 Author: Joshua Kinard <kumba@gentoo.org> AuthorDate: 2021-05-15 20:07:12 +0000 Commit: Joshua Kinard <kumba@gentoo.org> CommitDate: 2021-05-15 20:07:33 +0000 sys-libs/db: Added ~mips to KEYWORDS Bug: https://bugs.gentoo.org/729932 Signed-off-by: Joshua Kinard <kumba@gentoo.org> Package-Manager: Portage-3.0.18, Repoman-3.0.3 sys-libs/db/db-6.0.35-r4.ebuild | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
~mips was already done in #comment 13 All arches done. Closing.
