Since the corresponding major dependencies app-i18n/fcitx:5 and
app-i18n/fcitx:4 are mutually blocked, it is sufficient to make these
two also mutually blocked.
Closes: https://bugs.gentoo.org/923578
Signed-off-by: Ryan Qian <i@bitbili.net>
Signed-off-by: WANG Xuerui <xen0n@gentoo.org>
Since the corresponding major dependencies app-i18n/fcitx:5 and
app-i18n/fcitx:4 are mutually blocked, it is sufficient to make these
two also mutually blocked.
Closes: https://bugs.gentoo.org/923580
Signed-off-by: Ryan Qian <i@bitbili.net>
Signed-off-by: WANG Xuerui <xen0n@gentoo.org>
Since the corresponding major dependencies app-i18n/fcitx:5 and
app-i18n/fcitx:4 are mutually blocked, it is sufficient to make these
two also mutually blocked.
Closes: https://bugs.gentoo.org/923579
Signed-off-by: Ryan Qian <i@bitbili.net>
Signed-off-by: WANG Xuerui <xen0n@gentoo.org>
Mostly due to the openrc service's "need dbus" which is an annoyance
when dbus is missing (preventing from being a runtime-only optfeature),
but even with systemd this now also allows to properly check for
multilib on dbus (used by 32bit glcore/eglcore libraries to communicate
with powerd).
*Technically* needs a revbump given --changed-use does not know it
needs to rebuild here, but given this only cause problems for rare
users without dbus (e.g. headless cuda servers with USE=-tools) and
will propagate with kernel updates+rebuilds let's not bother every
users over this.
Hopefully users of powerd (incl. for systemd which may have more
existing ones) will notice the new USE and enable it.
Also re-arrange arm64 handling, it makes more sense to mask the USE
on arm64 than keep it as a no-op by checking if use !amd64.
Exception to this is 0/550 branch which started to include a arm64
nvidia-powerd build (albeit do not think hardware that need this even
exists yet). Hope did not break installation there given did not test
on arm64, please report if so.
Bug: https://bugs.gentoo.org/923117
Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
Followup to:
* 854887066c (profiles/prefix/darwin/macos/10.5/x86: add gcc sub-profile)
* 3788eef280 (profiles: restore 32-bits Intel Mac OS X 10.5 profile)
This fixes the following from pkgcheck (and a new warning in CI -> PRs fail):
```
ArchesOutOfSync 'profiles/arches.desc' is out of sync with 'arch.list', arch: x86-macos
```
Signed-off-by: Sam James <sam@gentoo.org>
Per news item 2024-01-05-usr-initramfs, we no longer support this use
case. It is fragile and hacky and leads to bizarre forms of load errors.
The functionality is, despite being called "split-usr", not really about
split-usr at all.
[sam: Add bug #332175 and bug #498878 ref.]
Bug: https://bugs.gentoo.org/332175
Bug: https://bugs.gentoo.org/498878
Signed-off-by: Eli Schwartz <eschwartz93@gmail.com>
Signed-off-by: Sam James <sam@gentoo.org>
Per news item 2024-01-05-usr-initramfs, we no longer support this use
case. It is fragile and hacky and leads to bizarre forms of load errors.
The functionality is, despite being called "split-usr", not really about
split-usr at all.
Signed-off-by: Eli Schwartz <eschwartz93@gmail.com>
Signed-off-by: Sam James <sam@gentoo.org>
Per news item 2024-01-05-usr-initramfs, we no longer support this use
case. It is fragile and hacky and leads to bizarre forms of load errors.
The functionality is, despite being called "split-usr", not really about
split-usr at all.
Signed-off-by: Eli Schwartz <eschwartz93@gmail.com>
Signed-off-by: Sam James <sam@gentoo.org>
Per news item 2024-01-05-usr-initramfs, we no longer support this use
case. It is fragile and hacky and leads to bizarre forms of load errors.
The functionality is, despite being called "split-usr", not really about
split-usr at all.
Signed-off-by: Eli Schwartz <eschwartz93@gmail.com>
Signed-off-by: Sam James <sam@gentoo.org>
Per news item 2024-01-05-usr-initramfs, we no longer support this use
case. It is fragile and hacky and leads to bizarre forms of load errors.
The functionality is, despite being called "split-usr", not really about
split-usr at all.
Signed-off-by: Eli Schwartz <eschwartz93@gmail.com>
Signed-off-by: Sam James <sam@gentoo.org>
Per news item 2024-01-05-usr-initramfs, we no longer support this use
case. It is fragile and hacky and leads to bizarre forms of load errors.
The functionality is, despite being called "split-usr", not really about
split-usr at all.
Signed-off-by: Eli Schwartz <eschwartz93@gmail.com>
Signed-off-by: Sam James <sam@gentoo.org>
Per news item 2024-01-05-usr-initramfs, we no longer support this use
case. It is fragile and hacky and leads to bizarre forms of load errors.
The functionality is, despite being called "split-usr", not really about
split-usr at all.
Signed-off-by: Eli Schwartz <eschwartz93@gmail.com>
Signed-off-by: Sam James <sam@gentoo.org>
elibtoolize is not good enough for this software because it uses a
random libtool version, so patches don't tend to apply.
Fixes QA warnings for failing to respect -frecord-gcc-switches.
Signed-off-by: Eli Schwartz <eschwartz93@gmail.com>
Signed-off-by: Sam James <sam@gentoo.org>
Per news item 2024-01-05-usr-initramfs, we no longer support this use
case. It is fragile and hacky and leads to bizarre forms of load errors.
The functionality is, despite being called "split-usr", not really about
split-usr at all.
Signed-off-by: Eli Schwartz <eschwartz93@gmail.com>
Signed-off-by: Sam James <sam@gentoo.org>
Ryan Qian
Ionen Wolkens
Matoro Mahri
Sam James
Patrick McLean
Eli Schwartz