busybox compile/build results in linker error: ... rdate.c:(.text.rdate_main+0xfe): undefined reference to `stime' /usr/lib/gcc/x86_64-pc-linux-gnu/8.3.0/../../../../x86_64-pc-linux-gnu/bin/ld: coreutils/lib.a(date.o): in function ` date_main': date.c:(.text.date_main+0x283): undefined reference to `stime' ... because installed sys-libs/glibc-2.31-r2 (no longer contains 'stime') see https://bugs.gentoo.org/show_bug.cgi?id=708350 (sys-apps/busybox-1.31.1-r1 and newer contains a fix for this) Reproducible: Always Steps to Reproduce: 1. install sys-libs/glibc-2.31-r2 2. call genkernel to create a initramfs
How can we help to fix this?
I can confirm this is reproducible on my side - see related output. *Output of: *gcc -Wall -Wshadow -Wwrite-strings -Wundef -Wstrict-prototypes -Wunused -Wunused-parameter -Wunused-function -Wunused-value -Wmissing-prototypes -Wmissing-declarations -Wdeclaration-after-statement -Wold-style-definition -fno-builtin-strlen -finline-limit=0 -fomit-frame-pointer -ffunction-sections -fdata-sections -fno-guess-branch-probability -funsigned-char -static-libgcc -falign-functions=1 -falign-jumps=1 -falign-labels=1 -falign-loops=1 -Os -static -o busybox_unstripped -Wl,--sort-common -Wl,--sort-section,alignment -Wl,--start-group applets/built-in.o archival/lib.a archival/libarchive/lib.a console-tools/lib.a coreutils/lib.a coreutils/libcoreutils/lib.a debianutils/lib.a e2fsprogs/lib.a editors/lib.a findutils/lib.a init/lib.a libbb/lib.a libpwdgrp/lib.a loginutils/lib.a mailutils/lib.a miscutils/lib.a modutils/lib.a networking/lib.a networking/libiproute/lib.a networking/udhcp/lib.a printutils/lib.a procps/lib.a runit/lib.a selinux/lib.a shell/lib.a sysklogd/lib.a util-linux/lib.a util-linux/volume_id/lib.a archival/built-in.o archival/libarchive/built-in.o console-tools/built-in.o coreutils/built-in.o coreutils/libcoreutils/built-in.o debianutils/built-in.o e2fsprogs/built-in.o editors/built-in.o findutils/built-in.o init/built-in.o libbb/built-in.o libpwdgrp/built-in.o loginutils/built-in.o mailutils/built-in.o miscutils/built-in.o modutils/built-in.o networking/built-in.o networking/libiproute/built-in.o networking/udhcp/built-in.o printutils/built-in.o procps/built-in.o runit/built-in.o selinux/built-in.o shell/built-in.o sysklogd/built-in.o util-linux/built-in.o util-linux/volume_id/built-in.o -Wl,--end-group -Wl,--start-group -lcrypt -lm -Wl,--end-group *========== */usr/lib/gcc/x86_64-pc-linux-gnu/10.1.0/../../../../x86_64-pc-linux-gnu/bin/ld: debianutils/lib.a(mktemp.o): in function `mktemp_main': *mktemp.c:(.text.mktemp_main+0xd5): warning: the use of `tempnam' is dangerous, better use `mkstemp' */usr/lib/gcc/x86_64-pc-linux-gnu/10.1.0/../../../../x86_64-pc-linux-gnu/bin/ld: coreutils/lib.a(id.o): in function `get_groups': *id.c:(.text.get_groups+0xe): warning: Using 'getgrouplist' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking */usr/lib/gcc/x86_64-pc-linux-gnu/10.1.0/../../../../x86_64-pc-linux-gnu/bin/ld: libbb/lib.a(bb_pwd.o): in function `xgetgrgid': *bb_pwd.c:(.text.xgetgrgid+0x4): warning: Using 'getgrgid' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking */usr/lib/gcc/x86_64-pc-linux-gnu/10.1.0/../../../../x86_64-pc-linux-gnu/bin/ld: archival/libarchive/lib.a(data_extract_all.o): in function `data_extract_all': *data_extract_all.c:(.text.data_extract_all+0x36b): warning: Using 'getgrnam' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking */usr/lib/gcc/x86_64-pc-linux-gnu/10.1.0/../../../../x86_64-pc-linux-gnu/bin/ld: shell/lib.a(ash.o): in function `argstr': *ash.c:(.text.argstr+0xff): warning: Using 'getpwnam' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking */usr/lib/gcc/x86_64-pc-linux-gnu/10.1.0/../../../../x86_64-pc-linux-gnu/bin/ld: libbb/lib.a(bb_pwd.o): in function `xgetpwuid': *bb_pwd.c:(.text.xgetpwuid+0x4): warning: Using 'getpwuid' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking */usr/lib/gcc/x86_64-pc-linux-gnu/10.1.0/../../../../x86_64-pc-linux-gnu/bin/ld: libbb/lib.a(xconnect.o): in function `str2sockaddr': *xconnect.c:(.text.str2sockaddr+0x116): warning: Using 'getaddrinfo' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking */usr/lib/gcc/x86_64-pc-linux-gnu/10.1.0/../../../../x86_64-pc-linux-gnu/bin/ld: libbb/lib.a(inet_common.o): in function `INET_rresolve': *inet_common.c:(.text.INET_rresolve+0xdc): warning: Using 'gethostbyaddr' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking */usr/lib/gcc/x86_64-pc-linux-gnu/10.1.0/../../../../x86_64-pc-linux-gnu/bin/ld: libbb/lib.a(inet_common.o): in function `INET_resolve': *inet_common.c:(.text.INET_resolve+0x49): warning: Using 'gethostbyname' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking */usr/lib/gcc/x86_64-pc-linux-gnu/10.1.0/../../../../x86_64-pc-linux-gnu/bin/ld: libbb/lib.a(xconnect.o): in function `bb_lookup_port': *xconnect.c:(.text.bb_lookup_port+0x44): warning: Using 'getservbyname' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking */usr/lib/gcc/x86_64-pc-linux-gnu/10.1.0/../../../../x86_64-pc-linux-gnu/bin/ld: util-linux/lib.a(rdate.o): in function `rdate_main': *rdate.c:(.text.rdate_main+0xfa): undefined reference to `stime' */usr/lib/gcc/x86_64-pc-linux-gnu/10.1.0/../../../../x86_64-pc-linux-gnu/bin/ld: coreutils/lib.a(date.o): in function `date_main': *date.c:(.text.date_main+0x27a): undefined reference to `stime' *collect2: error: ld returned 1 exit status *make: *** [Makefile:715: busybox_unstripped] Error 1 *-- * 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 .. * Clearing cache dir contents from /var/cache/genkernel * * ERROR: Failed to compile the "all" target... * * -- End log... -- * * Please consult /var/log/genkernel.log for more information and any * errors that were reported above. * * Report any genkernel bugs to bugs.gentoo.org and * assign your bug to genkernel@gentoo.org. Please include * as much information as you can in your bug report; attaching * /var/log/genkernel.log so that your issue can be dealt with effectively. * * Please do *not* report compilation failures as genkernel bugs!
emerge --info output: x230 /var/log # emerge --info Portage 2.3.99 (python 3.7.7-final-0, default/linux/amd64/17.1/systemd, gcc-10.1.0, glibc-2.31-r3, 5.6.6-gentoo x86_64) ================================================================= System uname: Linux-5.6.6-gentoo-x86_64-Intel-R-_Core-TM-_i5-3320M_CPU_@_2.60GHz-with-gentoo-2.7 KiB Mem: 8041192 total, 751784 free KiB Swap: 0 total, 0 free Timestamp of repository gentoo: Tue, 12 May 2020 20:35:11 +0000 Head commit of repository gentoo: 600a5a5cf0e5ef565d1f029c9e3ad6c1a19c9f8a Head commit of repository frunzales-overlay: eeedce77e2846c5c49b7c5a98a3612a139d0620c Head commit of repository sakaki-tools: 213a4e46e0b95863e05049dd44ae29fdcb6a5d68 sh bash 5.0_p17 ld GNU ld (Gentoo 2.34 p1) 2.34.0 app-shells/bash: 5.0_p17::gentoo dev-lang/perl: 5.30.2::gentoo dev-lang/python: 3.7.7-r2::gentoo dev-util/cmake: 3.17.2::gentoo dev-util/pkgconfig: 0.29.2::gentoo sys-apps/baselayout: 2.7::gentoo sys-apps/sandbox: 2.18::gentoo sys-devel/autoconf: 2.69-r5::gentoo sys-devel/automake: 1.16.2::gentoo sys-devel/binutils: 2.34::gentoo sys-devel/gcc: 9.3.0::gentoo, 10.1.0::gentoo sys-devel/gcc-config: 2.2.1::gentoo sys-devel/libtool: 2.4.6-r6::gentoo sys-devel/make: 4.3::gentoo sys-kernel/linux-headers: 5.6::gentoo (virtual/os-headers) sys-libs/glibc: 2.31-r3::gentoo Repositories: gentoo location: /usr/portage sync-type: git sync-uri: https://anongit.gentoo.org/git/repo/sync/gentoo.git priority: -1000 frunzales-overlay location: /usr/local/portage/frunzales-overlay sync-type: git sync-uri: ssh://git@gitlab.com/frunzales/frunzales-overlay.git masters: gentoo priority: 10 sakaki-tools location: /usr/local/portage/sakaki-tools sync-type: git sync-uri: https://github.com/sakaki-/sakaki-tools.git masters: gentoo priority: 50 ACCEPT_KEYWORDS="amd64 ~amd64" ACCEPT_LICENSE="@FREE" CBUILD="x86_64-pc-linux-gnu" CFLAGS="-O2 -pipe -march=native" CHOST="x86_64-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/share/gnupg/qualified.txt" CONFIG_PROTECT_MASK="/etc/ca-certificates.conf /etc/env.d /etc/gconf /etc/gentoo-release /etc/revdep-rebuild /etc/sandbox.d /etc/terminfo" CXXFLAGS="-O2 -pipe -march=native" DISTDIR="/usr/portage/distfiles" ENV_UNSET="DBUS_SESSION_BUS_ADDRESS DISPLAY GOBIN PERL5LIB PERL5OPT PERLPREFIX PERL_CORE PERL_MB_OPT PERL_MM_OPT XAUTHORITY XDG_CACHE_HOME XDG_CONFIG_HOME XDG_DATA_HOME XDG_RUNTIME_DIR" FCFLAGS="-O2 -pipe" FEATURES="assume-digests binpkg-docompress binpkg-dostrip binpkg-logs config-protect-if-modified distlocks ebuild-locks fixlafiles ipc-sandbox merge-sync multilib-strict news parallel-fetch pid-sandbox preserve-libs protect-owned qa-unresolved-soname-deps sandbox sfperms strict unknown-features-warn unmerge-logs unmerge-orphans userfetch userpriv usersandbox usersync xattr" FFLAGS="-O2 -pipe" GENTOO_MIRRORS="http://distfiles.gentoo.org" LANG="en_US.utf8" LDFLAGS="-Wl,-O1 -Wl,--as-needed" MAKEOPTS="-j4" PKGDIR="/usr/portage/packages" PORTAGE_CONFIGROOT="/" PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --omit-dir-times --compress --force --whole-file --delete --stats --human-readable --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages --exclude=/.git" PORTAGE_TMPDIR="/var/tmp" USE="acl alsa amd64 berkdb bzip2 cli crypt cryptsetup gdbm gnutls gpg iconv ipv6 libtirpc lock multilib ncurses nptl pam pcre pulseaudio readline seccomp split-usr sqlite ssl systemd udev unicode upower xattr zlib" ABI_X86="64" ADA_TARGET="gnat_2018" ALSA_CARDS="hda-intel" CALLIGRA_FEATURES="karbon sheets words" COLLECTD_PLUGINS="df interface irq load memory rrdtool swap syslog" CPU_FLAGS_X86="mmx mmxext sse sse2" ELIBC="glibc" INPUT_DEVICES="libinput" KERNEL="linux" L10N="en-US" LIBREOFFICE_EXTENSIONS="presenter-console presenter-minimizer" OFFICE_IMPLEMENTATION="libreoffice" PHP_TARGETS="php7-2" POSTGRES_TARGETS="postgres10 postgres11" PYTHON_SINGLE_TARGET="python3_7" PYTHON_TARGETS="python3_7" RUBY_TARGETS="ruby27" USERLAND="GNU" VIDEO_CARDS="intel i915" XTABLES_ADDONS="quota2 psd pknock lscan length2 ipv4options ipset ipp2p iface geoip fuzzy condition tee tarpit sysrq steal rawnat logmark ipmark dhcpmac delude chaos account" Unset: CC, CPPFLAGS, CTARGET, CXX, EMERGE_DEFAULT_OPTS, INSTALL_MASK, LC_ALL, LINGUAS, PORTAGE_BINHOST, PORTAGE_BUNZIP2_COMMAND, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS
(In reply to Piotr from comment #1) > How can we help to fix this? I've been able to fix this issue by modifying the code (installed on disk) in order to use the newest busybox and apply the busybox patches from portage. It works just fine. I have yet to find the time to work on the ebuild, though.
What's the point of using a local, ebuild-specific version of busybox? Given that gentoo does a recent, working version of bb one would assume it can be used for such purpose.
I can fix this bug after switching to busybox-1.31.1: 1) I change busybox version in /usr/share/genkernel/defaults/software.sh to BUSYBOX_VER="${BUSYBOX_VER:-1.31.1}" 2) Copy busybox-1.31.1-x86_64.tar.bz2 /var/cache/genkernel/busybox-1.31.1-x86_64.tar.bz2 3) Copy busybox-1.31.1-glibc-2.31.patch from gentoo tree to /usr/share/genkernel/patches/busybox/1.31.1/ 3a) Maybe other patches from /usr/share/genkernel/patches/busybox/1.20.2/ are required. 4) Run genkernel all 5) Success.
(In reply to Viktor Yu. Kovalskii from comment #6) > I can fix this bug after switching to busybox-1.31.1: > > 1) I change busybox version in /usr/share/genkernel/defaults/software.sh to > > BUSYBOX_VER="${BUSYBOX_VER:-1.31.1}" > I use a similar work around also not very nice.. ... 1) I downloaded busybox-1.31.1.tar.bz 2) patched the busybox 3) zipped it again 4) put in my local /usr/portage/distfiles/ directory 5) added the lines to /etc/genkernel.conf ################################################ 200503 ## genkernel-next-70 uses old busybox ## own busybox tar file (because of patch) for glibc-2.31-r2 BUSYBOX_VER="1.31.1" BUSYBOX_SRCTAR="/usr/portage/distfiles/busybox-1.31.1.patched.tar.bz2" ################################################# 200503 works...
ping!
The following stanza in /etc/genkernel.conf works: BUSYBOX_VER="1.32.0" BUSYBOX_SRCTAR="/var/cache/distfiles/busybox-1.32.0.tar.bz2" Note that busybox v1.32.0 does not require any modifications or patching, builds fine using sys-libs/glibc-2.31-r5.
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=264b5939a20d051e0a799702588273f8596bb269 commit 264b5939a20d051e0a799702588273f8596bb269 Author: Andreas K. Hüttel <dilfridge@gentoo.org> AuthorDate: 2020-07-11 15:39:28 +0000 Commit: Andreas K. Hüttel <dilfridge@gentoo.org> CommitDate: 2020-07-11 15:40:41 +0000 package.mask: Mask genkernel-next for removal Signed-off-by: Andreas K. Hüttel <dilfridge@gentoo.org> Bug: https://bugs.gentoo.org/719968 profiles/package.mask | 5 +++++ 1 file changed, 5 insertions(+)
Not sure why this package has been removed. Last comment report a quick fix for glibc so the reason for removal seems a bit overstated. Moreover, I used genkernel and dracut but still genkernel-ng is the best fit for my use case. This decision, IMHO, does not seem to help anyone, more the opposite.
Yeah, removing the package is a poor move. All it takes to fix it is to replace the bundled busybox. Here you can find the package with busybox updated to the newer one which builds fine with new glibc: https://piorekf.org/genkernel-next-70.tar.gz
(In reply to Piotr from comment #12) > Yeah, removing the package is a poor move. All it takes to fix it is to > replace the bundled busybox. Here you can find the package with busybox > updated to the newer one which builds fine with new glibc: > https://piorekf.org/genkernel-next-70.tar.gz It wasn't removed, just masked for removal in 30 days. This move had to be taken as the maintainer does not respond, since April. If you want to jump in as (Proxy) Maintainer just create a PR for the package with the fix, hopefully you get the fix in so the package can stay in portage.
(In reply to Piotr from comment #12) > Yeah, removing the package is a poor move. All it takes to fix it is to > replace the bundled busybox. Here you can find the package with busybox > updated to the newer one which builds fine with new glibc: > https://piorekf.org/genkernel-next-70.tar.gz Moreover, stable 69 version is not affected by any bug with glibc-2,31-r5 so I do not see any kind of reason to mask all the package instead of masking just 70 version...
I installed the unstable 70 version, with the glibc-2.31-r5 installed too, and all worked fine... as can you see: howl ~ # genkernel --kernel-ld=ld.bfd --color --save-config --oldconfig --xconfig --no-mrproper --splash --all-ramdisk-modules --mountboot --udev --lvm --mdadm --makeopts=-j9 --install all * Gentoo Linux Genkernel; Version 70 * Running with options: --kernel-ld=ld.bfd --color --save-config --oldconfig --xconfig --no-mrproper --splash --all-ramdisk-modules --mountboot --udev --lvm --mdadm --makeopts=-j9 --install all * 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 .. * Linux Kernel 5.7.8-gentoo for x86_64... * .. with config file /etc/kernels/kernel-config-x86_64-5.7.8-gentoo * kernel: --mrproper is disabled; not running 'make mrproper'. * >> Running oldconfig... * kernel: --clean is disabled; not running 'make clean'. * kernel: >> Invoking xconfig... * >> Compiling 5.7.8-gentoo bzImage... * >> Not installing firmware as requested by configuration FIRMWARE_INSTALL=no... * >> Compiling 5.7.8-gentoo modules... * >> Generating module dependency data... * Copying config for successful build to /etc/kernels/kernel-config-x86_64-5.7.8-gentoo * busybox: >> Using cache * initramfs: >> Initializing... * >> Appending base_layout cpio data... * >> Appending udev cpio data... * >> Appending auxilary cpio data... * >> Copying keymaps * >> Appending busybox cpio data... * >> Appending lvm cpio data... * LVM: Adding support (copying binaries from system)... * >> Appending mdadm cpio data... * MDADM: Skipping inclusion of mdadm.conf * >> Appending modules cpio data... * >> Appending blkid cpio data... * >> Appending splash cpio data... * >> No splash detected; skipping! * >> Skipping modprobed copy * >> Appending ld_so_conf cpio data... * ldconfig: adding /sbin/ldconfig... * ld.so.conf: adding /etc/ld.so.conf{.d/*,}... cpio: usr/lib64 non creato: è presente la stessa versione o una più recente cpio: lib64 non creato: è presente la stessa versione o una più recente cpio: usr/lib64 non creato: è presente la stessa versione o una più recente cpio: usr/lib64/liblz4.so.1 non creato: è presente la stessa versione o una più recente cpio: usr/lib64/libgpg-error.so.0 non creato: è presente la stessa versione o una più recente cpio: usr/lib64/libgcrypt.so.20 non creato: è presente la stessa versione o una più recente cpio: lib64 non creato: è presente la stessa versione o una più recente cpio: lib64/librt.so.1 non creato: è presente la stessa versione o una più recente cpio: lib64/libpthread.so.0 non creato: è presente la stessa versione o una più recente cpio: lib64/libm.so.6 non creato: è presente la stessa versione o una più recente cpio: lib64/libc.so.6 non creato: è presente la stessa versione o una più recente cpio: lib64/libcap.so.2 non creato: è presente la stessa versione o una più recente cpio: lib64/libblkid.so.1 non creato: è presente la stessa versione o una più recente cpio: lib64/ld-linux-x86-64.so.2 non creato: è presente la stessa versione o una più recente cpio: lib64 non creato: è presente la stessa versione o una più recente cpio: lib64/libpthread.so.0 non creato: è presente la stessa versione o una più recente cpio: lib64/libdl.so.2 non creato: è presente la stessa versione o una più recente cpio: lib64/libc.so.6 non creato: è presente la stessa versione o una più recente cpio: lib64/ld-linux-x86-64.so.2 non creato: è presente la stessa versione o una più recente cpio: lib64 non creato: è presente la stessa versione o una più recente cpio: lib64/libc.so.6 non creato: è presente la stessa versione o una più recente cpio: lib64/libblkid.so.1 non creato: è presente la stessa versione o una più recente cpio: lib64/ld-linux-x86-64.so.2 non creato: è presente la stessa versione o una più recente * >> Finalizing cpio... * >> Compressing cpio data (.xz)... * * Kernel compiled successfully! * * Required Kernel Parameters: * root=/dev/$ROOT * * Where $ROOT is the device node for your root partition as the * one specified in /etc/fstab * * If you require Genkernel's hardware detection features; you MUST * tell your bootloader to use the provided INITRAMFS file. * WARNING... WARNING... WARNING... * Additional kernel cmdline arguments that *may* be required to boot properly... * add "vga=791 splash=silent,theme:default console=tty1 quiet" if you use a splash framebuffer ] * add "dolvm" for lvm support * add "domdadm" for RAID 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. howl ~ # ls /boot/ grub initramfs-genkernel-x86_64-5.7.7-gentoo kernel-genkernel-x86_64-5.7.6-gentoo kernel-genkernel-x86_64-5.7.8-gentoo System.map-genkernel-x86_64-5.7.7-gentoo initramfs-genkernel-x86_64-5.7.6-gentoo initramfs-genkernel-x86_64-5.7.8-gentoo kernel-genkernel-x86_64-5.7.7-gentoo System.map-genkernel-x86_64-5.7.6-gentoo System.map-genkernel-x86_64-5.7.8-gentoo howl ~ #
In the last ~3.5 years I reported several bugs for genkernel-next here in this bugtracker, I always wondered why they are still open. Of the current 30 open bugs the oldest still open, #600992 was reported by me - oh my, time flies - I guess I just came to genkernel-next right when it was abandoned? :-/ And now its final...
Created attachment 649044 [details] A new ebuild revision for genkernel-next to avoid deletion of the package after masking
(In reply to Franz Trischberger from comment #13) > (In reply to Piotr from comment #12) > > Yeah, removing the package is a poor move. All it takes to fix it is to > > replace the bundled busybox. Here you can find the package with busybox > > updated to the newer one which builds fine with new glibc: > > https://piorekf.org/genkernel-next-70.tar.gz > > It wasn't removed, just masked for removal in 30 days. > This move had to be taken as the maintainer does not respond, since April. > If you want to jump in as (Proxy) Maintainer just create a PR for the > package with the fix, hopefully you get the fix in so the package can stay > in portage. Anyway, I tryed to make a -r1 ebuild file ('genkernel-next-70-r1.ebuild' in the attechments) that automatically downloads the busybox-1.32.0.tar.bz2 and put it into /usr/portage/distfiles/ but I'm not able to show message at the end of install process with instructions to add the following lines at the end of /etc/genkernel.conf (or a way to automatize it): BUSYBOX_VER="1.32.0" BUSYBOX_SRCTAR="/usr/portage/distfiles/busybox-1.32.0.tar.bz2" Let me know if it works for you because I did it but in my Gentoo this bug does not appears even using the genkernel-next v.70. Regerds, Iade Gesso, PhD
You should be able to make the configuration change automatic by creating a .patch file of genkernel.conf as provided in the source (adding the two new lines) and including it in the PATCHES variable of your ebuild.
Created attachment 649128 [details, diff] genkernel-next-70_old_busybox.patch In your custom local overlay put it into the files subfolder of sys-kernel/genkernel-next ebuild folder, i,e, /path/to/your/local/overlay/sys-kernel/genkernel-next/files/genkernel-next-70_old_busybox.patch
Created attachment 649130 [details] genkernel-next-70-r1.ebuild In your custom local overlay put it into the root folder of sys-kernel/genkernel-next ebuild, i,e, /path/to/your/local/overlay/sys-kernel/genkernel-next/
(In reply to FlyingWaffle from comment #19) > You should be able to make the configuration change automatic by creating a > .patch file of genkernel.conf as provided in the source (adding the two new > lines) and including it in the PATCHES variable of your ebuild. Thank you, I revised my ebuild and created a patch as suggested. They are in the attachments, ready to be use for tests in your local overlay :) and if they work, I hope they will be used to avoid the package removal from the main tree. Iade Gesso, PhD Files: - genkernel-next-70-r1.ebuild - genkernel-next-70_old_busybox.patch
Please do not remove the package. I have been successfully using it for more than 10 years and it still seems to work just fine.
It would be great if this was kept in tree, I'm yet to find a more convenient way to build an initramfs with plymouth splash.
(In reply to Jari_42 from comment #24) > It would be great if this was kept in tree, I'm yet to find a more > convenient way to build an initramfs with plymouth splash. Hi, try with the two files I uploaded in the attachments, you just need to create your local overlay :) If you try them you can provide me some feedback... if the package will be removed in the official tree, I will provide it through a new overlay. Thanks, Iade
Tried it in my overlay; works just fine. Many thanks for the effort!
Everything works fine, unmask the package, please. # equery l busybox glibc genkernel-next * Searching for busybox ... [IP-] [ ] sys-apps/busybox-1.32.0:0 * Searching for glibc ... [IP-] [ ] sys-libs/glibc-2.31-r5:2.2 * Searching for genkernel-next ... [IP-] [ ] sys-kernel/genkernel-next-70:0
This would appreciate having a proxy maintainer as it seems current maintainer doesn't have much time for it :/ Otherwise it will likely break again in the future Maybe you could take a look to https://wiki.gentoo.org/wiki/Project:Proxy_Maintainers
(In reply to Pacho Ramos from comment #28) > This would appreciate having a proxy maintainer as it seems current > maintainer doesn't have much time for it :/ > > Otherwise it will likely break again in the future > > Maybe you could take a look to > https://wiki.gentoo.org/wiki/Project:Proxy_Maintainers What's the way to follow to propose as a Proxy Maintainer? Thanks, Iade Gesso, PhD
I think this link has the updated info and policies https://wiki.gentoo.org/wiki/Project:Proxy_Maintainers/User_Guide
Is this problem fixed? Because emerge still says this for me: !!! All ebuilds that could satisfy "=sys-kernel/genkernel-next-70" have been masked. !!! One of the following masked packages is required to complete your request: - sys-kernel/genkernel-next-70::gentoo (masked by: package.mask) /usr/portage/profiles/package.mask: # Andreas K. Hüttel <dilfridge@gentoo.org> (2020-07-11) # Fails to build with recent glibc, bug 719968 # Removal in 30 days There are no later versions of this and the currently installed one is also masked, so not sure if I should just wait or replace it with something else.
(In reply to Michele Santullo from comment #31) > Is this problem fixed? Because emerge still says this for me: > > !!! All ebuilds that could satisfy "=sys-kernel/genkernel-next-70" have been > masked. > !!! One of the following masked packages is required to complete your > request: > - sys-kernel/genkernel-next-70::gentoo (masked by: package.mask) > /usr/portage/profiles/package.mask: > # Andreas K. Hüttel <dilfridge@gentoo.org> (2020-07-11) > # Fails to build with recent glibc, bug 719968 > # Removal in 30 days > > There are no later versions of this and the currently installed one is also > masked, so not sure if I should just wait or replace it with something else. It seems to be fixed and, I can become a proxy mantainer but even if I read the documentation at the link which Pacho Ramos sent to me, I don't understand how to propose myself. Bye Iade
(In reply to Iade Gesso from comment #32) > > It seems to be fixed and, I can become a proxy mantainer but even if I read > the documentation at the link which Pacho Ramos sent to me, I don't > understand how to propose myself. > > Bye > > Iade If I understand the proxy maintainer docs, you just have to commit the ebuild fix via a GitHub pull request, adding yourself as proxy maintainer to metadata.xml.
So... it should be 30 days now - is it now final that genkernel-next will be removed from the tree?
(In reply to Morton Pellung from comment #34) > So... it should be 30 days now - is it now final that genkernel-next will be > removed from the tree? Well I made a pull request with Iade Gesso's patch so at this point it's up to the devs/maintainers to accept the pull request (or not).
(In reply to FlyingWaffle from comment #35) > (In reply to Morton Pellung from comment #34) > > So... it should be 30 days now - is it now final that genkernel-next will be > > removed from the tree? > > Well I made a pull request with Iade Gesso's patch so at this point it's up > to the devs/maintainers to accept the pull request (or not). Yes, but I feel a sort of "rubber wall"... anyway... if the Gentoo developpers will not accept my fix... I will create a new overlay... Iade PS: many thanks to FlyingWaffle :)
So the current status of this is that it's going to get removed from the tree, if so when? The 30 days has passed already.
Hi, my ebuild works fine and FlyingWaffle commited it to the git repo, but no one still accepted it to be merged... I think the Gentoo team not consider it... (In reply to Skyler Mäntysaari from comment #37) > So the current status of this is that it's going to get removed from the > tree, if so when? > > The 30 days has passed already.
It does not work fine. Calculating dependencies... done! [ebuild N ] dev-libs/libaio-0.3.110::gentoo USE="(split-usr) -static-libs -test" ABI_X86="(64) -32 (-x32)" 42 KiB [ebuild N ] dev-util/boost-build-1.72.0::gentoo USE="-examples" 104402 KiB [ebuild N ] app-text/asciidoc-8.6.10_p20181016-r1::gentoo USE="-examples -graphviz -highlight -test" PYTHON_SINGLE_TARGET="python3_7 (-pypy3) -python3_6" 564 KiB [ebuild N ] dev-libs/boost-1.72.0-r1:0/1.72.0::gentoo USE="bzip2 nls threads zlib -context -debug -doc -icu -lzma -mpi (-numpy) -python -static-libs -tools -zstd" ABI_X86="(64) -32 (-x32)" PYTHON_TARGETS="python2_7 python3_7 -python3_6 -python3_8" 0 KiB [ebuild N ] sys-block/thin-provisioning-tools-0.7.0::gentoo USE="-static -test" 226 KiB [ebuild N ] sys-fs/lvm2-2.02.187-r2::gentoo USE="readline thin udev -device-mapper-only -lvm2create_initrd -sanlock (-selinux) -static -static-libs -systemd" 0 KiB [ebuild N #] sys-kernel/genkernel-next-70-r1::localrepo USE="-cryptsetup -dmraid -gpg -iscsi -mdadm -plymouth (-selinux)" 0 KiB [blocks B ] sys-kernel/genkernel ("sys-kernel/genkernel" is blocking sys-kernel/genkernel-next-70-r1) Total: 7 packages (7 new), Size of downloads: 105232 KiB Conflict: 1 block (1 unsatisfied) * Error: The above package list contains packages which cannot be * installed at the same time on the same system. (sys-kernel/genkernel-4.0.10:0/0::gentoo, installed) pulled in by sys-kernel/genkernel required by @selected (sys-kernel/genkernel-next-70-r1:0/0::localrepo, ebuild scheduled for merge) pulled in by sys-kernel/genkernel-next (In reply to Iade Gesso from comment #38) > Hi, > my ebuild works fine and FlyingWaffle commited it to the git repo, but no > one still accepted it to be merged... > > I think the Gentoo team not consider it... > > (In reply to Skyler Mäntysaari from comment #37) > > So the current status of this is that it's going to get removed from the > > tree, if so when? > > > > The 30 days has passed already.
(In reply to Skyler Mäntysaari from comment #39) > It does not work fine. > > ...[cut out excess] > > * Error: The above package list contains packages which cannot be > * installed at the same time on the same system. > > (sys-kernel/genkernel-4.0.10:0/0::gentoo, installed) pulled in by > sys-kernel/genkernel required by @selected > > (sys-kernel/genkernel-next-70-r1:0/0::localrepo, ebuild scheduled for > merge) pulled in by > sys-kernel/genkernel-next ... Did you even read the error message there? You're trying to install genkernel-next when genkernel is already installed. They are mutually exclusive installs; pick ONE.
(In reply to FlyingWaffle from comment #40) > (In reply to Skyler Mäntysaari from comment #39) > > It does not work fine. > > > > ...[cut out excess] > > > > * Error: The above package list contains packages which cannot be > > * installed at the same time on the same system. > > > > (sys-kernel/genkernel-4.0.10:0/0::gentoo, installed) pulled in by > > sys-kernel/genkernel required by @selected > > > > (sys-kernel/genkernel-next-70-r1:0/0::localrepo, ebuild scheduled for > > merge) pulled in by > > sys-kernel/genkernel-next > > > ... Did you even read the error message there? You're trying to install > genkernel-next when genkernel is already installed. They are mutually > exclusive installs; pick ONE. Yeah, wow. Didn't catch that part of the error, but: >>> Emerging (1 of 1) sys-kernel/genkernel-next-70-r1::localrepo openpty failed: 'out of pty devices' * genkernel-next-70.tar.gz BLAKE2B SHA512 size ;-) ... [ ok ] * busybox-1.32.0.tar.bz2 BLAKE2B SHA512 size ;-) ... [ ok ] >>> Unpacking source... >>> Unpacking genkernel-next-70.tar.gz to /var/tmp/portage/sys-kernel/genkernel-next-70-r1/work >>> Unpacking busybox-1.32.0.tar.bz2 to /var/tmp/portage/sys-kernel/genkernel-next-70-r1/work >>> Source unpacked in /var/tmp/portage/sys-kernel/genkernel-next-70-r1/work >>> Preparing source in /var/tmp/portage/sys-kernel/genkernel-next-70-r1/work/genkernel-next-70 ... * Applying genkernel-next-70_old_busybox.patch ... /var/tmp/portage/sys-kernel/genkernel-next-70-r1/temp/environment: line 424: /var/tmp/portage/sys-kernel/genkernel-next-70-r1/files/genkernel-next-70_old_busybox.patch: No such file or directory /var/tmp/portage/sys-kernel/genkernel-next-70-r1/temp/environment: line 427: /var/tmp/portage/sys-kernel/genkernel-next-70-r1/files/genkernel-next-70_old_busybox.patch: No such file or directory [ !! ] * ERROR: sys-kernel/genkernel-next-70-r1::localrepo failed (prepare phase): * patch -p1 failed with /var/tmp/portage/sys-kernel/genkernel-next-70-r1/files/genkernel-next-70_old_busybox.patch * * Call stack: * ebuild.sh, line 125: Called src_prepare * environment, line 1148: Called default * phase-functions.sh, line 855: Called default_src_prepare * phase-functions.sh, line 920: Called __eapi6_src_prepare * environment, line 193: Called eapply '/var/tmp/portage/sys-kernel/genkernel-next-70-r1/files/genkernel-next-70_old_busybox.patch' * environment, line 492: Called _eapply_patch '/var/tmp/portage/sys-kernel/genkernel-next-70-r1/files/genkernel-next-70_old_busybox.patch' * environment, line 430: Called __helpers_die 'patch -p1 failed with /var/tmp/portage/sys-kernel/genkernel-next-70-r1/files/genkernel-next-70_old_busybox.patch' * isolated-functions.sh, line 112: Called die * The specific snippet of code: * die "$@" * * If you need support, post the output of `emerge --info '=sys-kernel/genkernel-next-70-r1::localrepo'`, * the complete build log and the output of `emerge -pqv '=sys-kernel/genkernel-next-70-r1::localrepo'`. * The complete build log is located at '/var/tmp/portage/sys-kernel/genkernel-next-70-r1/temp/build.log'. * The ebuild environment file is located at '/var/tmp/portage/sys-kernel/genkernel-next-70-r1/temp/environment'. * Working directory: '/var/tmp/portage/sys-kernel/genkernel-next-70-r1/work/genkernel-next-70' * S: '/var/tmp/portage/sys-kernel/genkernel-next-70-r1/work/genkernel-next-70' >>> Failed to emerge sys-kernel/genkernel-next-70-r1, Log file: >>> '/var/tmp/portage/sys-kernel/genkernel-next-70-r1/temp/build.log' * Messages for package sys-kernel/genkernel-next-70-r1: * ERROR: sys-kernel/genkernel-next-70-r1::localrepo failed (prepare phase): * patch -p1 failed with /var/tmp/portage/sys-kernel/genkernel-next-70-r1/files/genkernel-next-70_old_busybox.patch * * Call stack: * ebuild.sh, line 125: Called src_prepare * environment, line 1148: Called default * phase-functions.sh, line 855: Called default_src_prepare * phase-functions.sh, line 920: Called __eapi6_src_prepare * environment, line 193: Called eapply '/var/tmp/portage/sys-kernel/genkernel-next-70-r1/files/genkernel-next-70_old_busybox.patch' * environment, line 492: Called _eapply_patch '/var/tmp/portage/sys-kernel/genkernel-next-70-r1/files/genkernel-next-70_old_busybox.patch' * environment, line 430: Called __helpers_die 'patch -p1 failed with /var/tmp/portage/sys-kernel/genkernel-next-70-r1/files/genkernel-next-70_old_busybox.patch' * isolated-functions.sh, line 112: Called die * The specific snippet of code: * die "$@" * * If you need support, post the output of `emerge --info '=sys-kernel/genkernel-next-70-r1::localrepo'`, * the complete build log and the output of `emerge -pqv '=sys-kernel/genkernel-next-70-r1::localrepo'`. * The complete build log is located at '/var/tmp/portage/sys-kernel/genkernel-next-70-r1/temp/build.log'. * The ebuild environment file is located at '/var/tmp/portage/sys-kernel/genkernel-next-70-r1/temp/environment'. * Working directory: '/var/tmp/portage/sys-kernel/genkernel-next-70-r1/work/genkernel-next-70' * S: '/var/tmp/portage/sys-kernel/genkernel-next-70-r1/work/genkernel-next-70' Please post actual instructions on how to use the attachments correctly. I have them at /var/db/repos/localrepo/sys-kernel/genkernel-next, both files in the root of that.
(In reply to Skyler Mäntysaari from comment #41) > * Applying genkernel-next-70_old_busybox.patch ... > /var/tmp/portage/sys-kernel/genkernel-next-70-r1/temp/environment: line 424: > /var/tmp/portage/sys-kernel/genkernel-next-70-r1/files/genkernel-next- > 70_old_busybox.patch: No such file or directory > /var/tmp/portage/sys-kernel/genkernel-next-70-r1/temp/environment: line 427: > /var/tmp/portage/sys-kernel/genkernel-next-70-r1/files/genkernel-next- > 70_old_busybox.patch: No such file or directory > > [SNIP] > > Please post actual instructions on how to use the attachments correctly. > > I have them at /var/db/repos/localrepo/sys-kernel/genkernel-next, both files > in the root of that. As a general rule, ebuilds go in ".../REPO/PKG_CATEGORY/PKG_NAME". Any patch files will then generally go in ".../REPO/PKG_CATEGORY/PKG_NAME/files". As you can see from the error message above you don't have the patch file in the right directory.
Hello, I have been following this issue, as I use genkernel-next, on all my machines. So decided to report the issue to upstream, you can it here https://github.com/Sabayon/genkernel-next/issues/90 From package maintainance side, I think it is a good candidate for proxy-maintaince. On the ebuild / patch, I don't think it is the good fix, as you can see the report I did, the fix should be done in busybox, and it has been merged already, see https://bugs.gentoo.org/708350 So maybe the ebuild, need some cleanup / upgrade, but I hope we can keep this usefull software in gentoo :)
This patch by itself isn't going to be merged unless someone is able to fix at least some of the other (piling up) bugs for this package.
So you are refusing to take a working fix for a bug because other bugs exist? Sorry, this does not make any sense to me.
(In reply to Sam James from comment #44) > This patch by itself isn't going to be merged unless someone is able to fix > at least some of the other (piling up) bugs for this package. Yes, I'm able to read, but my ebuild is fixing on e of the bugs of the package... One is fixed... I think this can be a starting point... it has not to be a stop point... Otherwise, this is just a way to kill this package, in my opinion... Iade
(In reply to Sam James from comment #44) > This patch by itself isn't going to be merged unless someone is able to fix > at least some of the other (piling up) bugs for this package. I'm not sure to understand the reasoning behind this statement. Basically it means to me that you are not willing to fix a bug because there are other bugs around. I can't see the advantage of this position as it causes troubles to people that are using this package. I'd like to have a bug free distro, but I still like a situation where a package with several users have a bug less. Or shall we run thru all the packages that have bugs opened and prune them from portage?
I take a guess. Imagine your are one of the maintainers. There are genkernel and genkernel-next, the first one is the main and is maintained, the later one suggests by its name that it is newer and the future, but in fact is basically unmaintained with up to 3,5y old bug reports. I know, because I started with -next because I thought "why start with the soon to be deprecated stuff? I want the shiny new stuff!") So from a Gentoo maintainers perspective, over the last 3+y genkernel-next only caused extra work/noise due to user confusion which is which, unclear bug reports as users mix up genkernel and -next, and user creating traffic to due -next bugs. Fixing one -next bug does not improve the overall situation, there is still no motivated maintainer that attacks the all open issues bug by bug and raises the quality of -next, and timely investigates and fixes bugs as they are found. So, -next is scheduled to be removed if the overall quality trajectory of the package does not improve significantly.... ....am I right?
(In reply to Fabio Coatti from comment #47) > (In reply to Sam James from comment #44) > > This patch by itself isn't going to be merged unless someone is able to fix > > at least some of the other (piling up) bugs for this package. > > I'm not sure to understand the reasoning behind this statement. Basically it > means to me that you are not willing to fix a bug because there are other > bugs around. I can't see the advantage of this position as it causes > troubles to people that are using this package. I'd like to have a bug free > distro, but I still like a situation where a package with several users have > a bug less. > Or shall we run thru all the packages that have bugs opened and prune them > from portage? Please assume good faith. The problem is that yes, this is a really easy drive-by fix. It doesn't actually fix any of the problems which have developed over time, it's just a band-aid. There is no clear intention from anyone in this bug to fix any of the other bugs, so it'd just be prolonging the inevitable for unmaintained software. It's like patching an ancient Firefox to run on Windows 95, even though it's filled with security vulnerabilities. It helps nobody. (In reply to Morton Pellung from comment #48) This is exactly my view, and the view of many others. I've just (for some reason) decided to explain to people and end up getting criticised for it :(
(In reply to Sam James from comment #49) > (In reply to Fabio Coatti from comment #47) > > (In reply to Sam James from comment #44) > > > This patch by itself isn't going to be merged unless someone is able to fix > > > at least some of the other (piling up) bugs for this package. > > > > I'm not sure to understand the reasoning behind this statement. Basically it > > means to me that you are not willing to fix a bug because there are other > > bugs around. I can't see the advantage of this position as it causes > > troubles to people that are using this package. I'd like to have a bug free > > distro, but I still like a situation where a package with several users have > > a bug less. > > Or shall we run thru all the packages that have bugs opened and prune them > > from portage? > > Please assume good faith. The problem is that yes, this is a really easy > drive-by fix. It doesn't actually fix any of the > problems which have developed over time, it's just a band-aid. There is no > clear intention from anyone in this bug to fix any of the other bugs, so it'd > just be prolonging the inevitable for unmaintained software. > > It's like patching an ancient Firefox to run on Windows 95, even though it's > filled with security vulnerabilities. It helps nobody. > > (In reply to Morton Pellung from comment #48) > > This is exactly my view, and the view of many others. I've just (for some > reason) decided to explain to people and end up getting criticised for it :( Ok, but... If I propose a bugfix for another bug, since there still are other bugs I will get the same block while merging any other bugfix I submit... this in my opinion is the reason behind the proliferation of custom overlays, which deviates Gentoo system from quality... making us able to progressively fix bugs in the main tree, even for old packages can result in more fixes quality... Moreover, in my case, I need genkernel-next to make my Clevo laptop booting using Dracut init images... so, I need this package... Iade
(In reply to Iade Gesso from comment #50) > > Ok, but... If I propose a bugfix for another bug, since there still are > other bugs I will get the same block while merging any other bugfix I > submit... [...] My point is that this is a highly trivial fix. If someone is willing to fix other bugs which are not this trivial, this same reason wouldn't be used. That's why I call this a band-aid.
(In reply to Iade Gesso from comment #50) > Moreover, in my case, I need genkernel-next to make my Clevo laptop booting > using Dracut init images... so, I need this package... > Dracut itself should work or the latest genkernel.
(In reply to Sam James from comment #51) > (In reply to Iade Gesso from comment #50) > > > > Ok, but... If I propose a bugfix for another bug, since there still are > > other bugs I will get the same block while merging any other bugfix I > > submit... [...] > > My point is that this is a highly trivial fix. If someone is willing to fix > other bugs which are not this trivial, this same reason wouldn't be used. > That's why I call this a band-aid. But no one has told we don't want to fix other bugs, but my is "if for any bug the answer is the same 'we do not merge it because there are other open bugs' anyone of us will not start fixing any existing bug"... Iade
If it wasn't made clear: if people want to propose fixes for other bugs, I will review them and take them with this fix too. But I don't think one trivial fix is justification for letting the others continue to rot. This bug is getting really long now. Please feel free to message me on IRC (sam_) if you want to discuss it further.
(In reply to Sam James from comment #52) > (In reply to Iade Gesso from comment #50) > > Moreover, in my case, I need genkernel-next to make my Clevo laptop booting > > using Dracut init images... so, I need this package... > > > > Dracut itself should work or the latest genkernel. My setting required Dracut/genkernel-next to use mdadm instead of dmraid since my Clevo laptop in 2013 was not able to boot with dmraid... and it still works well... so I do not need to change, and I didn't checked the documentation of genkernel about this... Anyway, the point didn't changes... I want to fix bugs (when I can), but I need to be sure that none of my efforts will result in "there are other bugs to solve, so we do not merge it" every time... Iade
I've made clear I would be happy with other fixes together. It's just about this one being trivial and not really helpful to the larger problem.
(In reply to Sam James from comment #56) > I've made clear I would be happy with other fixes together. It's just about > this one being trivial and not really helpful to the larger problem. Can I point out that the "larger problem" is at least partly due to bug reports that haven't been closed after resolution (594252), a request to merge back into genkernel (468942), several reports that are actually upstream feature requests (or are otherwise upstream's problem, not Gentoo's, ie 600992), and many of them pertain to old versions of genkernel-next that aren't even offered as ebuilds anymore (< version 69) and though I haven't checked presumably no longer apply.
(In reply to FlyingWaffle from comment #57) > (In reply to Sam James from comment #56) > > I've made clear I would be happy with other fixes together. It's just about > > this one being trivial and not really helpful to the larger problem. Feel free to point out whatever you like. Plenty of the bugs don't have any such comment saying this, and given the very low activity in recent years, I don't think we can assume that all are necessarily fixed just because of the older version. I await seeing work on these bugs, either explaining that they no longer apply, or with fixes, or that it is not for genkernel-next to fix. I'm just an observer who is trying to explain our POV.
(In reply to FlyingWaffle from comment #57) > and many of them pertain to old versions of > genkernel-next that aren't even offered as ebuilds anymore (< version 69) > and though I haven't checked presumably no longer apply. This is wrong. Example bug #642096, reported by me end of 2017(!). Looking into -next-70, gen_initramfs.sh still has MOD_EXT=".ko": grep -n MOD_EXT= gen_initramfs.sh 780: local MOD_EXT=".ko" 824: local MOD_EXT=".ko" ...nothing changed in ~2,5 years! Bugs are reported and pile up here, sometimes with fix, sometimes not, but the overall trajectory is the code is unmaintained and rots.
(In reply to Sam James from comment #58) > I await seeing work on these bugs, either explaining that they no longer > apply, or with fixes, or that it is not for genkernel-next to fix. I'm just > an observer who is trying to explain our POV. OK. 719968 - This bug. Resolved if merged. (Issue is upstream though) 602842 - Feature request (can resolve by adding a USE flag for sys-fs/lvm2) 594252 - Resolved by new version (user confirms) 669792 - Resolved upstream by new version 712080 - Resolved upstream in ccache (wasn't caused by genkernel-next) 634038 - Resolved (problem with elftools python version) 642092 - Resolved (asciidoc needed python 3 support) 645696 - Resolved (caused by pax-utils) 651518 - Resolved upstream by new version 669792 - Resolved by new version 468942 - Irrelevant upstream feature request (merge back into genkernel) 596392 - Upstream feature request (similar to 600992, possible duplicate) 600992 - Upstream feature request (pull request exists; #50 on github) 496076 - Upstream feature request (BTRFS support; also this was due to user error) 629436 - Upstream feature request (BTRFS support, duplicate of 496076) 605340 - Upstream bug/feature request (possibly resolved by newer version) 642096 - Upstream bug/feature request (support compressed & uncompressed modules) 669232 - Upstream bug/feature request (patch provided though) 686680 - Upstream bug/feature request (unsure about this one) 730966 - Upstream bug/feature request (security issue) 549488 - Upstream bug (mdadm/raid issue) 549736 - Upstream bug (pull request exists; #25 on github) 583748 - Upstream bug (workarounds and solutions in issue #33 on github) 601444 - Upstream bug (default uas module inclusion) 649900 - Upstream bug (some kind of udev issue) 667502 - Upstream bug (issue #71 on github) 702580 - Upstream bug (patch provided) 644876 - Other (caused by ebuild removal, possibly resolved by new version) 695664 - Other (unsure) 29 total bugs in Gentoo tracker 8 already resolved. 2 trivially resolvable. 1 irrelevant request to merge into genkernel. Leaving us with a total of 18 actual bug reports, all of which should be redirected upstream (to an admittedly dead project). If we want to count the 4 patches/pull requests providing solutions then we only have 14 (12 if I'm right about the duplicates). I understand that the devs are busy and I appreciate your perspective on this package, however as you can see the problems with it aren't quite as "large" as they at first appear. (In reply to Morton Pellung from comment #59) > [snip] but the overall trajectory is the code is unmaintained and rots. I completely agree that upstream is basically abandoned, but the work has to start somewhere if people still want to use the package.
(In reply to FlyingWaffle from comment #60) Whoops, I counted 669792 twice. Still, that only leaves 19 (upstream) bugs unaccounted for.
(In reply to FlyingWaffle from comment #61) > (In reply to FlyingWaffle from comment #60) > > Whoops, I counted 669792 twice. Still, that only leaves 19 (upstream) bugs > unaccounted for. Why do you keep calling bugs "upstream"? Part of the problem is that gk-next is dead *upstream*. It was maintained in Gentoo by the same person who maintained it upstream.
(In reply to Sam James from comment #62) > Why do you keep calling bugs "upstream"? Part of the problem is that gk-next > is dead *upstream*. It was maintained in Gentoo by the same person who > maintained it upstream. I call it "upstream" because the first time I tried reporting a bug through the Gentoo tracker the responding dev made it extremely clear that anything unrelated to the package's actual ebuild was considered the responsibility of the upstream developers and not Gentoo. Since genkernel-next is part of the Sabayon project (even if it's main developer maintains the ebuild here) I'm applying the same logic. And I agree, development on genkernel-next is dead. However, as seen in this thread (and some other bug reports) many people still have specific use cases that require it. For me that is the plymouth support and my use of sakaki's buildkernel script. Unless the Gentoo wiki is outdated and genkernel now supports plymouth/udev/etc this is my attempt at helping keep genkernel-next available for those of us who use it.
(In reply to Sam James from comment #49) > (In reply to Fabio Coatti from comment #47) > > (In reply to Sam James from comment #44) > > > This patch by itself isn't going to be merged unless someone is able to fix > > > at least some of the other (piling up) bugs for this package. > > > > I'm not sure to understand the reasoning behind this statement. Basically it > > means to me that you are not willing to fix a bug because there are other > > bugs around. I can't see the advantage of this position as it causes > > troubles to people that are using this package. I'd like to have a bug free > > distro, but I still like a situation where a package with several users have > > a bug less. > > Or shall we run thru all the packages that have bugs opened and prune them > > from portage? > > Please assume good faith. The problem is that yes, this is a really easy > drive-by fix. It doesn't actually fix any of the > problems which have developed over time, it's just a band-aid. There is no > clear intention from anyone in this bug to fix any of the other bugs, so it'd > just be prolonging the inevitable for unmaintained software. > > It's like patching an ancient Firefox to run on Windows 95, even though it's > filled with security vulnerabilities. It helps nobody. > > (In reply to Morton Pellung from comment #48) > > This is exactly my view, and the view of many others. I've just (for some > reason) decided to explain to people and end up getting criticised for it :( I always assume good faith, but being criticized is somehow part of the game I guess :). My points are: 1. If the reason for dropping the package is that is not maintained, I can see the point but it leaves us with a problem: I tried to switch to genkernel exactly for this reason but something (I can't recall exactly atm what) was not supported in genkernel or dracut, so I had to go back to ng. I can find it out again I guess. However, this will cause me a major headache. 2. If the reason is that the package is not maintained, it should be dropped regardless of how many bugs can be fixed by some random and kind user. Not supporting this line of action, but I can understand it (and I'll be forced to add another thing to the overlay). What I can't understand is that a fix is not accepted because there are other bugs around. Hope to have clarified my position.
Package removed.
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=07151d9604b624228018c1e41521e37450989704 commit 07151d9604b624228018c1e41521e37450989704 Author: Michał Górny <mgorny@gentoo.org> AuthorDate: 2020-08-20 12:49:31 +0000 Commit: Michał Górny <mgorny@gentoo.org> CommitDate: 2020-08-20 12:50:31 +0000 sys-kernel/genkernel-next: Remove last-rited pkg Bug: https://bugs.gentoo.org/719968 Signed-off-by: Michał Górny <mgorny@gentoo.org> profiles/package.mask | 5 --- sys-kernel/genkernel-next/Manifest | 2 - sys-kernel/genkernel-next/genkernel-next-69.ebuild | 51 ---------------------- sys-kernel/genkernel-next/genkernel-next-70.ebuild | 51 ---------------------- sys-kernel/genkernel-next/metadata.xml | 19 -------- 5 files changed, 128 deletions(-)
In any case, here you can find my custom overlay with my patched version of the package: https://github.com/iadegesso/howl-gentoo-overlay
