Am Montag, den 05.02.2024 um 23:44:10 Uhr + schrieb Sam James
:
> [...]
> > +However, this will clobber any BOOTX64.EFI image provded by other
> > +loaders. If dual-booting using another boot loader, users must take care
> > +not to replace BOOTX64.EFI if it is not provided by GRUB.
Hi, I thin
On Mon, Feb 05, 2024 at 11:44:37PM +, Sam James wrote:>
> We should mention that https://bugs.gentoo.org/923228 was the motivation
> that tipped us over the edge here.
>
> We should also consider the https://bugs.gentoo.org/880671 /
> https://bugs.gentoo.org/821955 case, as I think this is go
Sam James writes:
> Michał Górny writes:
>
>> [[PGP Signed Part:Undecided]]
>> Hi,
>>
>> TL;DR: Given that (not really surprising) the current approach for LLVM
>> dependencies doesn't work, I think it's time to give up and introduce
>> LLVM_TARGETS. This would probably mean introduce llvm-r1
Michał Górny writes:
> [[PGP Signed Part:Undecided]]
> Hi,
>
> TL;DR: Given that (not really surprising) the current approach for LLVM
> dependencies doesn't work, I think it's time to give up and introduce
> LLVM_TARGETS. This would probably mean introduce llvm-r1.eclass.
>
> However, since r
Mike Gilbert writes:
> Signed-off-by: Mike Gilbert
> ---
> .../2024-02-01-grub-upgrades.en.txt | 40 +++
> 1 file changed, 40 insertions(+)
> create mode 100644 2024-02-01-grub-upgrades/2024-02-01-grub-upgrades.en.txt
>
LGTM.
> diff --git a/2024-02-01-grub-upgrade
Hi,
TL;DR: Given that (not really surprising) the current approach for LLVM
dependencies doesn't work, I think it's time to give up and introduce
LLVM_TARGETS. This would probably mean introduce llvm-r1.eclass.
However, since random apps tend to require old versions of LLVM, I do
wonder if we sh
