Issue installing buildkernel with Plymouth

[CodeBleu]

This issue is created, because the Plymouth issue still remains from #17

sys-boot/plymouth-22.02.122-r1::gentoo (Missing IUSE: libkms)

I tried adding the libkms flag to the USE of plymouth, but still didn't work. I have to install buildkernel with USE=-plymouth to get it to install.

[jonesmz]

Could I get some context on why you're using buildkernel over https://github.com/GenPi64/genpi64-overlay/tree/master/sys-kernel/raspberrypi-kernel ?

After Sakaki stopped working on their gentoo for raspberry pi project, the new maintainers haven't touched on buildkernel, preferring the raspberrypi-kernel package

[CodeBleu]

Michael, I guess because I'm not working with a Raspberry PI.  I looked at which fork was the most recent updated form Sakaki, and found this repo.  Even though the repo has "GenPI" in it, the description/README is still mostly the same from Sakaki, and no mention of anything specific to Raspberry PI or the Raspberry PI kernel.  - https://github.com/GenPi64/genpi-tools Thanks, Jason

…

---- On Tue, 21 Mar 2023 10:15:12 -0400 Michael Jones ***@***.***> wrote --- Could I get some context on why you're using buildkernel over https://github.com/GenPi64/genpi64-overlay/tree/master/sys-kernel/raspberrypi-kernel ? After Sakaki stopped working on their gentoo for raspberry pi project, the new maintainers haven't touched on buildkernel, preferring the raspberrypi-kernel package — Reply to this email directly, #19 (comment), or https://github.com/notifications/unsubscribe-auth/AADB4UZCDXZNTE2NSD33I5LW5GZXBANCNFSM6AAAAAAV53EPNA. You are receiving this because you authored the thread.

[jonesmz]

Gotcha, thanks for the context.

What platform are you working with?

I'm wondering if using upstream gentoo's kernel (e.g. sys-kernel/gentoo-kernel or sys-kernel/vanilla-kernel) would work for your situation?

[CodeBleu]

amd64 platforms.  I've not found any other docs or info to  be able to do a USB boot/ EFI /gpg encrypted to  a full LUKS encrypted disk.  I know GenPI repo is not supporting the staticgpg, but I was able to update that and get that to  work as well, so that buildkernel can put the staticgpg in the initramfs so that it can decrypt the LUKS key from the  USB.  I was hoping to just contribute to this  repo and  not have to fork  another one, but now I need  to  decide if I want to keep the for I have of the GenPi repo and add the staticgpg to  it and continue on...or if it would make more sense to for Sakaki directly and make those changes?  I just assumed that the GenPi repo had some good updates that I would need, however it seems like it's maybe geared only for RaspberryPI's?

…

---- On Tue, 21 Mar 2023 11:33:18 -0400 Michael Jones ***@***.***> wrote --- Gotcha, thanks for the context. What platform are you working with? I'm wondering if using upstream gentoo's kernel (e.g. sys-kernel/gentoo-kernel or sys-kernel/vanilla-kernel) would work for your situation? — Reply to this email directly, #19 (comment), or https://github.com/notifications/unsubscribe-auth/AADB4U2JPHKKBWE7PJT23ATW5HC35ANCNFSM6AAAAAAV53EPNA. You are receiving this because you authored the thread.

[jonesmz]

Sakaki announced that due to their job, they immediately halted all open source work globally.

The repositories under our project aren't exclusive to raspberry pi, we have some experimental x86_64 work as well.

Looking at the ebuild in question here it doesn't seem particularly complicated, so I suppose I'm not sure if using an ebuild is actually the right approach for what you're trying to do

[CodeBleu]

---- On Tue, 21 Mar 2023 11:58:49 -0400 Michael Jones ***@***.***> wrote --- ## see inline comments Sakaki announced that due to their job, they immediately halted all open source work globally. ##Yes, I'm aware, that is why I looked for most recent updated fork of that The repositories under our project aren't exclusive to raspberry pi, we have some experimental x86_64 work as well. Looking at the ebuild in question here it doesn't seem particularly complicated, so I suppose I'm not sure if using an ebuild is actually the right approach for what you're trying to do ##What do you suggest? — Reply to this email directly, #19 (comment), or https://github.com/notifications/unsubscribe-auth/AADB4U43K4J7BCE6PQIWY5TW5HF3TANCNFSM6AAAAAAV53EPNA. You are receiving this because you authored the thread.

[jonesmz]

What do you suggest?

Well my suggestion is that you probably don't want to use the "buildkernel" package, you probably want to use a small script that does the same thing.

There's several different related issues here.

The first is that, as you observed, while we don't explicitly discard x86 related things, our project is largely about the raspberry pi, so you're not going to be able to get much help from us because we aren't all that familiar with x86 specific things in the context of this project. Obviously we all have x86 machines so we aren't clueless, but it's still a bit off-topic and largely we don't use the ebuilds in this repo.

The second is that looking at the buildkernel package, which as we noted isn't particularly complex, it does seem to be doing some weird things like using the package manager to detect and mutate system configuration, which isn't necessarily wrong but is a yellow flag.

Third is that it's depending on genkernel-next, and not upstream's genkernel package. That's probably a bad idea, since no one's tried to keep genkernel-next up to date, there's probably plenty wrong with it.

Fourth is that, as observed by samip5 it's not really a good idea to rely on us to maintain a package we don't use, so it's very probably that we'll do something wrong.

I suppose that at the end of the day, you can officially adopt this repository if you'd like. I think it's pretty likely that we'll drop it from our project entirely some time in the future, with any ebuilds we keep being moved into https://github.com/GenPi64/genpi64-overlay

Out of the ebuilds in this specific repository, at most we would keep the genup and showem tools, the other's are all either out of date, better managed by some repository like the sunrise repo, superseded by something in the official gentoo repo, or just out of scope (or all of the above)

If you open pull requests for this repo, we'll review them and merge any that make sense, obviously. But just be aware that this repo isn't well aligned with our project at this time.

[CodeBleu]

Than you for that detailed explanation/update.  I just wish there was a good replacement for the Sakaki Guide with updated info.  It just sounds like there are bits and pieces floating around in different places/repos.  I guess I will try at some point to keep digging  in more  myself to try and understand how all the UFI/GPG/LUKS from a bootable USB works....but most of what I found is where people are just using grub and not booting from a USB. Thanks again for the  info

…

---- On Tue, 21 Mar 2023 12:44:35 -0400 Michael Jones ***@***.***> wrote --- What do you suggest? Well my suggestion is that you probably don't want to use the "buildkernel" package, you probably want to use a small script that does the same thing. There's several different related issues here. The first is that, as you observed, while we don't explicitly discard x86 related things, our project is largely about the raspberry pi, so you're not going to be able to get much help from us because we aren't all that familiar with x86 specific things in the context of this project. Obviously we all have x86 machines so we aren't clueless, but it's still a bit off-topic and largely we don't use the ebuilds in this repo. The second is that looking at the buildkernel package, which as we noted isn't particularly complex, it does seem to be doing some weird things like using the package manager to detect and mutate system configuration, which isn't necessarily wrong but is a yellow flag. Third is that it's depending on genkernel-next, and not upstream's genkernel package. That's probably a bad idea, since no one's tried to keep genkernel-next up to date, there's probably plenty wrong with it. Fourth is that, as observed by samip5 it's not really a good idea to rely on us to maintain a package we don't use, so it's very probably that we'll do something wrong. I suppose that at the end of the day, you can officially adopt this repository if you'd like. I think it's pretty likely that we'll drop it from our project entirely some time in the future, with any ebuilds we keep being moved into https://github.com/GenPi64/genpi64-overlay Out of the ebuilds in this specific repository, at most we would keep the genup and showem tools, the other's are all either out of date, better managed by some repository like the sunrise repo, superseded by something in the official gentoo repo, or just out of scope (or all of the above) If you open pull requests for this repo, we'll review them and merge any that make sense, obviously. But just be aware that this repo isn't well aligned with our project at this time. — Reply to this email directly, #19 (comment), or https://github.com/notifications/unsubscribe-auth/AADB4UYX53R2TO4LGE3EBQTW5HLHHANCNFSM6AAAAAAV53EPNA. You are receiving this because you authored the thread.