sakaki- / sakaki-tools Goto Github PK

Overlay containing various utility ebuilds for Gentoo on EFI.

Shell 99.40% Roff 0.60%

sakaki-tools's Introduction

sakaki-tools Gentoo Overlay

Overlay containing various utility ebuilds for Gentoo on EFI.

31 Oct 2020: sadly, due to legal obligations arising from a recent change in my 'real world' job, I must announce I am standing down as maintainer of this project with immediate effect. For the meantime, I will leave the repo up (for historical interest, and since the ebuilds etc. may be of use to others); however, I plan no further updates, nor will I be accepting / actioning further pull requests or bug reports from this point. Email requests for support will also have to be politely declined, so, please treat this as an effective EOL notice.

For further details, please see my post here.

If you have used my EFI Guide (and this repo) to install your PC-based Gentoo system, it should still continue to work for some time, but you should now take steps to migrate to a baseline Gentoo Handbook install (since the underlying tools, such as buildkernel, will also now no longer be supported and may eventually fail as more modern kernels etc. are released).

With sincere apologies, sakaki ><

Required for the tutorial "Sakaki's EFI Install Guide" on the Gentoo wiki.

List of ebuilds

app-portage/showem source
- Provides a simple utility script (showem(1)), which enables you to monitor the progress of a parallel emerge(1). A manpage is included.
sys-kernel/buildkernel source
- Provides a script (buildkernel(8)) to build a (stub EFI) kernel (with integral initramfs) suitable for booting from a USB key on UEFI BIOS PCs. Automatically sets the necessary kernel configuration parameters, including the command line, and signs the resulting kernel if possible (for secure boot). Has a interactive and non-interactive (batch) mode. Manpages for the script and its configuration file (/etc/buildkernel.conf) are included.
app-portage/genup source
- Provides the genup(8) script, to simplify the process of keeping your Gentoo system up-to-date. genup(8) can automatically update the Portage tree, all installed packages, and kernel. Has interactive and non-interactive (batch) modes. A manpage is included.
app-portage/porthash source
- Provides the porthash(1) script, which creates, or by default verifies, a signed sha512 "master" hash of the specified Portage repostitory tree (by default, /usr/portage). It is intended to provide assurance - when distributing a repo snapshot over an unauthenticated channel such as rsync - that the consitutent ebuilds, manifests etc. have not been tampered with in transit. A manpage is included.
app-portage/porthole
- A simple ebuild, extending porthole-0.6.1-r5, and patching an issue experienced on some systems where PORTDIR is undefined.
app-crypt/efitools
- This package provides various useful tools for manipulating the EFI secure boot variables. It is no longer required as a more modern version has become available in the main Gentoo tree.
app-crypt/staticgpg
- A simple ebuild, derived from app-crypt/gnupg version 1.4.16, which creates a statically linked, no-pinentry version of gpg(1) suitable for use in an initramfs context. It can safely be installed beside a standard 2.x version of app-crypt/gnupg (which isn't SLOTted). Deploys its executable to /usr/bin/staticgpg. A placeholder manpage is included.
sys-apps/coreboot-utils upstream
- This package provides a few utilities from the coreboot project, specifically ifdtool to parse and modify flash dumps of Intel firmware and (on amd64 only) intelmetool to query the status of the Intel Management Engine.
sys-apps/me_cleaner upstream
- Provides me_cleaner-1.2; a tool for disabling the Intel Management Engine, by modifying its firmware.
media-gfx/fotoxx upstream
- Provides fotoxx-18.01.3, a program for improving digital photographs (supports HDR etc.).
(eclass/)java-maven-pkg.eclass
- Provides an eclass to support building Maven pacakges from source. Use mvn2ebuild in place of mvn within a working Maven build tree, to create a 'starter' ebuild using this eclass.
app-portage/mvn2ebuild
- Provides a simple utility to create a starter ebuild for a working Maven Java build, leveraging the java-maven-pkg eclass.
dev-java/jitsi-sctp upstream
- Provides a from-source build of the JNI component for the usrsctp library (currently for ~arm64 and ~amd64). Uses java-maven-pkg eclass.
acct-group/jitsi
- Provides a runtime group used by Jitsi services. Currently set at 377.
acct-user/jicofo
- Provides a runtime uid for the JItsi COnference FOcus server. Currently set at 377.
acct-user/jvb
- Provides a runtime uid for the Jitsi Videobridge SFU. Currently set at 376.
net-im/jicofo upstream
- Provides a from-source build of the JItsi Meet COnference FOcus server (media session manager). Uses java-maven-pkg eclass.
net-im/jitsi-meet-master-config
- Provides master configuration settings for Jitsi Meet server, via a prompt-based tool.
net-im/jitsi-meet-prosody upstream
- Provides Prosody configuration and plugins for use with Jitsi Meet.
net-im/jitsi-meet-server
- Provides a top-level service for the Jitsi Meet baseline server set, allowing all subcomponents to be started and stopped together. Emerge this package to build the Jitsi complex, then run emerge --config jitsi-meet-master-config, and then start the jitsi-meet-server service. Supports both OpenRC and systemd.
net-im/jitsi-meet-turnserver upstream
- This package configures the net-im/coturn server to work with Jitsi Meet.
net-im/jitsi-meet-web-config upstream
- Provides Webserver (nginx/apache) configurations for use with Jitsi Meet.
net-im/jitsi-meet-web upstream
- Provides an (upstream deb-derived) WebRTC, JavaScript/WASM-based videoconferencing client webroot filestructure.
net-im/jitsi-videobridge upstream
- Provides a from-source build of Jitsi VideoBridge - a WebRTC compatible SFU. Uses java-maven-pkg eclass.
dev-python/xkcdpass upstream
- Provides a tool to generate secure multiword passwords/passphrases, inspired by XKCD 936.

Installation

As of version >= 2.2.16 of Portage, sakaki-tools is best installed (on Gentoo) via the new plug-in sync system. Full instructions are provided on the Gentoo wiki.

The following are short form instructions. If you haven't already installed git(1), do so first:

# emerge --ask --verbose dev-vcs/git

Next, create a custom /etc/portage/repos.conf entry for the sakaki-tools overlay, so Portage knows what to do. Make sure that /etc/portage/repos.conf exists, and is a directory. Then, fire up your favourite editor:

# nano -w /etc/portage/repos.conf/sakaki-tools.conf

and put the following text in the file:

[sakaki-tools]
 
# Various utility ebuilds for Gentoo on EFI
# Maintainer: sakaki ([email protected])
 
location = /usr/local/portage/sakaki-tools
sync-type = git
sync-uri = https://github.com/sakaki-/sakaki-tools.git
priority = 50
auto-sync = yes

Then run:

# emaint sync --repo sakaki-tools

If you are running on the stable branch by default, allow ~amd64 keyword files from this repository. Make sure that /etc/portage/package.accept_keywords exists, and is a directory. Then issue:

# echo "*/*::sakaki-tools ~amd64" >> /etc/portage/package.accept_keywords/sakaki-tools-repo

Now you can install packages from the overlay. For example:

# emerge --ask --verbose app-portage/genup

Maintainers

sakaki

sakaki-tools's People

Contributors

Stargazers

Watchers

sakaki-tools's Issues

app-crypt/staticgpg-1.4.16 fails to build

Hi,

Build log attached - emerge --info output attached as well. Note that I'm trying to compile this with gcc 10.1.0::gentoo and binutils 2.34-r1::gentoo.

emergeinfo.txt
staticgpg.txt

SRC_URI in net-im/jitsi-meet-web gives 404 - source seems to have been moved

I have no idea if this does or might soon apply to any other jitsi related packages, but this one gives a 404 for download.jitst.org/jitsi/debian/... I do find what looks like the right file in download.jitsi.org/stable/... (I manually downloaded it into the distfiles folder, and the emerge then completed without error.)

emerge of buildkernel fails due to ebuild not satisfied.

Hey,
My last emerge failed with the error:

emerge: there are no ebuilds to satisfy ">=app-crypt/sbsigntools-0.6-r1"..

It seems like it might be an error in the ebuild file for buildkernel on line 26 link.

I think that the line should be >=app-crypt/sbsigntool-0.6-r1 instead of >=app-crypt/sbsigntools-0.6-r1 as there is no ebuild for sbsigntools but there is one for sbsigntool.

Kernel relocs and gold linker

This has come up before for certain arches/configs, and still happens with 5.3.x and x86_64 if the default linker is set to gold, ie, something like:

  CALL    scripts/atomic/check-atomics.sh
  DESCEND  objtool
  CHK     include/generated/compile.h
  VDSOCHK arch/x86/entry/vdso/vdso64.so.dbg
  VDSOCHK arch/x86/entry/vdso/vdso32.so.dbg
  CHK     kernel/kheaders_data.tar.xz
  CC      arch/x86/boot/compressed/misc.o
  RELOCS  arch/x86/boot/compressed/vmlinux.relocs
Invalid absolute R_X86_64_32S relocation: __end_of_kernel_reserve
make[2]: *** [arch/x86/boot/compressed/Makefile:130: arch/x86/boot/compressed/vmlinux.relocs] Error 1
make[2]: *** Deleting file 'arch/x86/boot/compressed/vmlinux.relocs'
make[1]: *** [arch/x86/boot/Makefile:112: arch/x86/boot/compressed/vmlinux] Error 2
make: *** [arch/x86/Makefile:316: bzImage] Error 2

as well as failures building the VDSO.

In the past I've patched a makefile or two to force ld.bfd in the fail location, but based on the kernel thread discussion I think it's probably better to just force ld.bfd for the kernel build, so I added it to the "make" line in buildkernel:

    # setup make with specified niceness
    MAKE="nice -n ${ADJUSTMENT} make LD=ld.bfd"

The failure still depends on arch/config options (so is somewhat intermittent) and the above seems like the safest fix for now.

$tring U?

Why can't you just clone get sakaki-tools?
I can't use intelmetool to verify because the gentoo install is so difficult.
why don't you just stay on wiki gentoo please?
thanks anyway

RFC: add genkernel-next patches or switch to genkernel-4

Hi: I couldn't find a better place for this since it requires a decision if you want to test it (now) and think about buildkernel/EFI-Guide integration, or wait and see for a response to the bug I just submitted:

https://bugs.gentoo.org/698606

I did think about a PR but decided against it; I can if you want one (the ebuild is in my overlay here: https://github.com/sarnold/portage-overlay/tree/master/sys-kernel/genkernel-next )

The patches are for both ~arm64 and subdirs in the initramfs files option; the second works great on the Carbon X1 install:

 ls -lh /boot/EFI/*
/boot/EFI/Boot:
total 330M
-rwxr-xr-x 1 root root 135K Oct  8 12:52 2019-10-08-12-52-05-config.old
-rwxr-xr-x 1 root root 157M Oct  8 12:52 2019-10-08-12-52-05-gentoo.efi.old
-rwxr-xr-x 1 root root 134K Oct  7 11:29 KeyTool.efi
-rwxr-xr-x 1 root root 152K Oct 26 15:24 config
-rwxr-xr-x 1 root root 152K Oct 26 15:24 config.old
-rwxr-xr-x 1 root root  20M Oct 26 15:24 gentoo.efi
-rwxr-xr-x 1 root root 154M Oct 26 15:24 gentoo.efi.old

I have no idea if you can use it on pi64 but it works great with the kernel bootsplash patches on pinebook and nanopi-k2 (in a pitop even). Thanks for all the cool stuff; I'm going to test your (much) smaller EFI kernel approach on some chromebooks...

buildkernel Runtime Dependency Renamed

buildkernel-1.0.30.ebuild has >=app-crypt/sbsigntool-0.6-r1 as a runtime dependency. app-crypt/sbsigntool was renamed to app-crypt/sbsigntools (https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=c638678c995810739309b8582e90a3957bc98615)

genup: flood of "Processing CAT/PN" lines

This makes it painful to scroll back after genup has completed to review what it really did. 19000+ lines!
Wouldn't it be nice to make something (eix?) quieter to not output this to the console?

>>> Regenerating /etc/ld.so.cache...                  
* Updating eix metadata...                            
 * Syncing all portage overlays                       
/usr/bin/eix-sync: line 396: layman: command not found
 * layman -S failed                                   
 * Running @-hooks                                    
Regenerating cache entries...                         
Processing acct-group/adm                             
Processing acct-group/asterisk                        
...

Adding sakaki-tools to Gentoo's global repository list

Hello!
First off, thank you for writing these tools. They are quite useful.
Is there any particular reason why this overlay isn't in the repository list?
If you weren't aware, you can create a pull request to have it added.
The file to modify is /files/overlays/repositories.xml

EFI guide and 17.1 profile (plus keywords ~amd64)

Hi, I'm following the EFI/Luks install (which I normally don't do) on a "new" (surplus) laptop and after unpacking the stage3 I have no default profile selected. I've been banging on the arm profiles and haven't done a fresh amd64 install for a while, and it shows both 17.0 and 17.1 profiles as stable (except musl/uclibc) but without a default.

So it looks like the profile gets reset later in the install, but it's not clear if it needs 17.0 or just "latest" default stable amd64 profile. Do you have any recommendations one way or the other?

Thank you for all your work !

Hi Sakaki,
I wanted to thank you for all the work that you have done in creating this repository and its tools.
genup is amazingly awesome and I love it.
I can't express enough gratitude for making these tools ❤️

I hope you have fun in your new job and future endeavors in life.

Hope you have a good one for ever more,
Aisha

gnome login issue (EFI guide related?)

This has been somewhat intermittent, and even when it shows up (like now) I don't see any errors in the logs other than the gdm/greeter.log which is pretty much all errors (except nothing that points to a login freeze). What happens is this:

after boot up, gdm looks fine
try to login, as soon as you hit <enter> on the password the GUI freezes
poke at ctl-alt-F1 (or F2) a couple of times before it switches
Hmm..
switch back to vt7 and try to "unlock"
watch it freeze
repeat

At some point you can come back and login (maybe). Right now I haven't been able to use the GUI since I rebooted the machine several days ago. Just rebooted a few minutes ago, still locked out of GDM. Recent greeter log looks like this:

Have you possibly seen this before? Any thoughts? I'm out of ideas (and almost out of a job). Thanks!

The XKEYBOARD keymap compiler (xkbcomp) reports:
> Internal error:   Could not resolve keysym XF86FullScreen
Errors from xkbcomp are not fatal to the X server
dbus-daemon[4105]: [session uid=994 pid=4105] Activating service name='org.a11y.Bus' requested by ':1.11' (uid=994 pid=4115 comm="/usr/bin/gnome-shell " label="kernel")
dbus-daemon[4105]: [session uid=994 pid=4105] Successfully activated service 'org.a11y.Bus'
GNOME Shell-Message: 14:33:27.647: Unset XDG_SESSION_ID, getCurrentSessionProxy() called outside a user session. Asking logind directly.
GNOME Shell-Message: 14:33:27.647: Will monitor session c1
dbus-daemon[4105]: [session uid=994 pid=4105] Activating service name='org.freedesktop.portal.IBus' requested by ':1.13' (uid=994 pid=4204 comm="ibus-daemon --panel disable " label="kernel")
dbus-daemon[4105]: [session uid=994 pid=4105] Successfully activated service 'org.freedesktop.portal.IBus'
dbus-daemon[4188]: Activating service name='org.a11y.atspi.Registry' requested by ':1.0' (uid=994 pid=4115 comm="/usr/bin/gnome-shell " label="kernel")
dbus-daemon[4188]: Successfully activated service 'org.a11y.atspi.Registry'
SpiRegistry daemon is running with well-known name - org.a11y.atspi.Registry
GNOME Shell-Message: 14:33:28.658: Failed to get PolKit permission: Polkit.Error: GDBus.Error:org.freedesktop.PolicyKit1.Error.Failed: Action org.freedesktop.bolt.enroll is not registered
dbus-daemon[4105]: [session uid=994 pid=4105] Activating service name='org.freedesktop.portal.IBus' requested by ':1.21' (uid=994 pid=4282 comm="ibus-daemon --panel disable -r --xim " label="kernel")
dbus-daemon[4105]: [session uid=994 pid=4105] Successfully activated service 'org.freedesktop.portal.IBus'

(gnome-shell:4115): Clutter-WARNING **: 14:33:28.789: Getting invalid resource scale property

** (gnome-shell:4115): WARNING **: 14:33:28.803: Could not issue 'StartUnit' systemd call

(gnome-shell:4115): IBUS-WARNING **: 14:33:28.853: Unable to connect to ibus: The connection is closed

** (gnome-shell:4115): WARNING **: 14:33:28.854: Error checking authorization for action id org.freedesktop.bolt.enroll: GDBus.Error:org.freedesktop.PolicyKit1.Error.Failed: Action org.freedesktop.bolt.enroll is not registered

(gsd-dummy:4316): GLib-GIO-CRITICAL **: 14:33:28.875: g_bus_own_name: assertion 'g_dbus_is_name (name) && !g_dbus_is_unique_name (name)' failed

(gsd-dummy:4332): GLib-GIO-CRITICAL **: 14:33:28.877: g_bus_own_name: assertion 'g_dbus_is_name (name) && !g_dbus_is_unique_name (name)' failed

(gsd-sharing:4315): sharing-plugin-WARNING **: 14:33:28.883: Failed to StopUnit service: GDBus.Error:org.freedesktop.DBus.Error.ServiceUnknown: The name org.freedesktop.systemd1 was not provided by any .service files

(gsd-sharing:4315): sharing-plugin-WARNING **: 14:33:28.883: Failed to StopUnit service: GDBus.Error:org.freedesktop.DBus.Error.ServiceUnknown: The name org.freedesktop.systemd1 was not provided by any .service files

(gsd-sharing:4315): sharing-plugin-WARNING **: 14:33:28.884: Failed to StopUnit service: GDBus.Error:org.freedesktop.DBus.Error.ServiceUnknown: The name org.freedesktop.systemd1 was not provided by any .service files

(gsd-sharing:4315): sharing-plugin-WARNING **: 14:33:28.884: Failed to StopUnit service: GDBus.Error:org.freedesktop.DBus.Error.ServiceUnknown: The name org.freedesktop.systemd1 was not provided by any .service files
The XKEYBOARD keymap compiler (xkbcomp) reports:
> Warning:          Unsupported maximum keycode 569, clipping.
>                   X11 cannot support keycodes above 255.
> Internal error:   Could not resolve keysym Invalid
Errors from xkbcomp are not fatal to the X server
Gjs-Message: 14:33:28.959: JS WARNING: [resource:///org/gnome/shell/ui/windowManager.js 1637]: reference to undefined property "MetaWindowXwayland"
openConnection: connect: No such file or directory
cannot connect to braille devices daemon brltty at :0

(gsd-media-keys:4340): media-keys-plugin-WARNING **: 14:33:29.217: Failed to grab accelerator for keybinding settings:playback-random

(gsd-media-keys:4340): media-keys-plugin-WARNING **: 14:33:29.217: Failed to grab accelerator for keybinding settings:playback-repeat

(gsd-media-keys:4340): media-keys-plugin-WARNING **: 14:33:29.217: Failed to grab accelerator for keybinding settings:hibernate

(gsd-media-keys:4340): media-keys-plugin-WARNING **: 14:33:29.217: Failed to grab accelerator for keybinding settings:rfkill
GNOME Shell-Message: 14:33:29.595: Registering session with GDM
The XKEYBOARD keymap compiler (xkbcomp) reports:
> Warning:          Unsupported maximum keycode 569, clipping.
>                   X11 cannot support keycodes above 255.
> Internal error:   Could not resolve keysym Invalid
Errors from xkbcomp are not fatal to the X server
The XKEYBOARD keymap compiler (xkbcomp) reports:
> Warning:          Unsupported maximum keycode 569, clipping.
>                   X11 cannot support keycodes above 255.
> Internal error:   Could not resolve keysym Invalid
Errors from xkbcomp are not fatal to the X server

sys-boot/plymouth masked for removal

Hello! First of all, thank you for your awesome overlay and brilliant EFI-install guide! It made me to try Gentoo yet again and explained a lot of stuff that I did wrong last time. ^_^

Now to the sad part: Today I was upgrading my system, when Portage gave me this message:

/var/portage/repos/gentoo/profiles/package.mask:
# Michał Górny <[email protected]> (04 Aug 2017)
# sys-boot/plymouth is unmaintained since Apr 2016. The current version
# has multiple bugs, including not supporting OpenRC. It really needs
# an active maintainer. Removal in 30 days. Bug #621470.
#
# The remaining packages are sys-boot/plymouth reverse dependencies.
# They have no use without it, so they are being removed as well.

- sys-boot/plymouth-0.9.2-r1::gentoo (masked by: package.mask)
For more information, see the MASKED PACKAGES section in the emerge
man page or refer to the Gentoo Handbook.

Since buildkernel (and your EFI installation guide) uses Plymouth to provide a bootsplash, I thought that I had to open this issue ticket. I, myself, can just 'rip' current Plymouth ebuilds to my own overlay and continue to use it as usual, but this way I can't be sure that buildkernel (and other stuff) will still use it. :(

As far as I understand, Michal's point is that Plymouth didn't have a tagged release since April 2016. That's true, but git version is still (more or less) active, with latest commit happened in May. Maybe we should switch over to -9999?

sys-kernel/buildkernel ebuild dependencies

Hello again!

I've started using your buildkernel and genup scripts recently (I've finally moved my system to LUKS ^_^) and they work just right for me!
There's a one minor problem, however — if I undestand it right, buildkernel's ebuild contains hard dependency on one of three kernel sources variations from the Gentoo tree: gentoo-sources, hardened-sources and aufs-sources. As for me, I use pf-sources to build a kernel with post-factum's patchset, since it gives me a bit lower power consumption (3-6 watts instead of 5-8 while on idle or somewhat 'light' load) and includes the UKSM patch. buildkernel works with pf-sources kernel without problems, but this dependency requires me to have 2 sets of kernel sources installed.

This could be worked around if buildkernel's ebuild would specify virtual/linux-sources as a dependency instead.

sys-kernel/genkernel-next-70 - Could not find busybox source tarball

Running the buildkernel script with genkernel-next-70 fails with

* Creating initramfs (uncompressed)...
* Gentoo Linux Genkernel; Version 70
* Running with options: --install --no-mountboot --luks --lvm --no-gpg --udev --kernel-config="/var/tmp/buildkernel/buildkernel/.config" --busybox --no-compress-initramfs --all-ramdisk-modules --firmware --plymouth --plymouth-theme=breeze initramfs

* Using genkernel.conf from /etc/genkernel.conf
* Sourcing arch-specific config.sh from /usr/share/genkernel/arch/x86_64/config.sh ..
* Sourcing arch-specific modules_load from /usr/share/genkernel/arch/x86_64/modules_load ..

grep: : No such file or directory
Could not find source tarball /usr/portage/distfiles/busybox-1.32.0.tar.bz2. Please refetch.

* buildkernel: Error: Caught signal - exiting

Since my distfiles directory is /var/cache/distfiles/, I imagine the problem is genkernel-next-70 does not respect the appropriate environment variables.

genup & sys-kernel/buildkernel/

=app-admin/python-updater-0.11 mgorny think threw this under the bus... else its being rewritten to be callable more on as needed basis..

https://bugs.gentoo.org/468942 Bug 468942 - sys-kernel/genkernel-next should be merged into genkernel

genkernel? ( || ( sys-kernel/genkernel[crypt][gpg] >=sys-kernel/genkernel-next-58[cryptsetup,gpg,plymouth?]) )" merger is bing worked.. so , i'd take it under watch..

for now pentoo-updater script or genup lite is sufficient.

eselect repository beginning to replace , layman..

Dependency conflict between plymouth and buildkernel

Hi,
It appears sys-boot/plymouth was updated upstream in the main gentoo repository, and the gdm USE flag was removed from the ebuild. This now creates a conflict with sys-kernel/buildkernel. The warning message from portage is below.

WARNING: One or more updates/rebuilds have been skipped due to a dependency conflict:

sys-boot/plymouth:0

(sys-boot/plymouth-0.9.5:0/0::gentoo, ebuild scheduled for merge) USE="gtk libkms pango (split-usr) udev -debug -static-libs" ABI_X86="(64)" conflicts with
>=sys-boot/plymouth-0.8.8-r4[gdm,libkms,pango] required by (sys-kernel/buildkernel-1.0.36-r1:0/0::sakaki-tools, installed) USE="plymouth" ABI_X86="(64)"

sys-kernel/genkernel-next deprecation

The current genkernel-next package is being deprecated in the official Gentoo portage tree:

https://bugs.gentoo.org/719968

sakaki-tools:sys-kernel/buildkernel depends on sys-kernel/genkernel-next as a runtime dependency:

RDEPEND="${DEPEND}
	>=sys-libs/ncurses-5.9-r2
	>=virtual/linux-sources-3
	>=app-crypt/sbsigntools-0.6-r1
	plymouth? ( >=sys-boot/plymouth-0.8.8-r4[gdm,libkms,pango] )
	>=sys-kernel/genkernel-next-58[cryptsetup,gpg,plymouth?]
	=app-crypt/staticgpg-1.4.16-r1
	>=sys-boot/efibootmgr-0.5.4-r1"

Are there plans to support the Gentoo-supplied sys-kernel/genkernel?

Wrong initramfs filename with gentoo-sources-4.0.5 and genkernel-next-63

The latest stable gentoo-sources-4.0.5 and genkernel-next-63 generates initramfs-genkernel-x86_64-4.0.5-gentoo-gnu. Please append a -gnu in the INITRAMFSNAME variable.

*         >> Finalizing cpio...

* WARNING... WARNING... WARNING...
* Additional kernel cmdline arguments that *may* be required to boot properly...
* add "dolvm" for lvm support
* With support for several ext* filesystems available, it may be needed to
* add "rootfstype=ext3" or "rootfstype=ext4" to the list of boot parameters.

* Do NOT report kernel bugs as genkernel bugs unless your bug
* is about the default genkernel configuration...
*
* Make sure you have the latest ~arch genkernel before reporting bugs.
cp: cannot stat ‘/boot/initramfs-genkernel-x86_64-4.0.5-gentoo’: No such file or directory

perl-cleaner problem

Dear Sakaki,

Thank you for sharing this tools.

I use your repo sakaki-tools (efi system) and I noticed a problem that apparently has no solution:

pearl-cleaner (called by genup) is allways rebuilding some packages (in my case, texinfo, rxvt-unicode, weechat). As I have a cron job (daily) for genup and also an SSD drive, I am worried about it.

I know it is not about your script, but the forum seem not to worrie about this problem and I also assume it could be risky for solid state drives on the long term (at least it is annoying). Genup is wonderful and I want to keep using it.

Do you have any suggestion?

Thank you in advance,

All the best,

Diego Samuelle

net-im/jicofo fails to download maven-metadata.xml due to filesize mismatch

>>> Downloading 'https://repo.maven.apache.org/maven2/org/apache/felix/maven-bundle-plugin/maven-metadata.xml'
--2020-09-01 19:54:54--  https://repo.maven.apache.org/maven2/org/apache/felix/maven-bundle-plugin/maven-metadata.xml
Resolving repo.maven.apache.org... 151.101.116.215
Connecting to repo.maven.apache.org|151.101.116.215|:443... connected.
HTTP request sent, awaiting response... 200 OK
Length: 1303 (1.3K) [text/xml]
Saving to: '/usr/portage/tree/distfiles/org_apache_felix_maven-bundle-plugin_maven-metadata.xml.__download__'

     0K .                                                     100% 34.8M=0s

2020-09-01 19:54:54 (34.8 MB/s) - '/usr/portage/tree/distfiles/org_apache_felix_maven-bundle-plugin_maven-metadata.xml.__download__' saved [1303/1303]

!!! Fetched file: org_apache_felix_maven-bundle-plugin_maven-metadata.xml VERIFY FAILED!
!!! Reason: Filesize does not match recorded size
!!! Got:      1303
!!! Expected: 1272
Refetching... File renamed to '/usr/portage/tree/distfiles/org_apache_felix_maven-bundle-plugin_maven-metadata.xml._checksum_failure_.wmopocob'

I don't know if it's just a new version, in which case the Manifest just needs updating.

efitools-1.9.2::sakaki-tools fails to build, while ::gentoo works

Hi,
Looks like main tree's ebuild is well maintained, so perhaps could be dropped from this overlay?

cc -I/var/tmp/portage/app-crypt/efitools-1.9.2/work/efitools-1.9.2/include/ -I/usr/include/efi -I/usr/include/efi/x86_64 -I/usr/include/efi/protocol -O2 -pipe -march=skylake
 -fpic -Wall -fshort-wchar -fno-strict-aliasing -fno-merge-constants -fno-stack-protector -ffreestanding -fno-stack-check -DGNU_EFI_USE_MS_ABI -DEFI_FUNCTION_WRAPPER -mno-red
-zone  -fpic -Wall -fshort-wchar -fno-strict-aliasing -fno-merge-constants -fno-stack-protector -ffreestanding -fno-stack-check -DGNU_EFI_USE_MS_ABI -DEFI_FUNCTION_WRAPPER -m
no-red-zone -DCONFIG_x86_64 -fno-toplevel-reorder -DBUILD_EFI -c execute.c -o execute.efi.o
console.c:360:5: error: ‘EFI_WARN_UNKNOWN_GLYPH’ undeclared here (not in a function); did you mean ‘EFI_WARN_UNKOWN_GLYPH’?
  360 |  {  EFI_WARN_UNKNOWN_GLYPH,     L"Warning Unknown Glyph"},
      |     ^~~~~~~~~~~~~~~~~~~~~~
      |     EFI_WARN_UNKOWN_GLYPH
make[1]: *** [../Make.rules:105: console.efi.o] Error 1