* Press Ctrl-C to Stop * * sys-boot/syslinux-6.04_pre1-r3:0::gentoo * /usr/bin/keytab-lilo * * Package 'sys-boot/lilo-24.2-r1' NOT merged due to file collisions. If ------------------------------------------------------------------- This is an unstable amd64 chroot image at a tinderbox (==build bot) name: 17.1_desktop_plasma_systemd_merged_usr-j4-20221218-020005 ------------------------------------------------------------------- GNUMAKEFLAGS="$GNUMAKEFLAGS --jobserver-style=pipe" gcc-config -l: [1] x86_64-pc-linux-gnu-11 [2] x86_64-pc-linux-gnu-12 * clang/llvm (if any): clang version 15.0.6 Target: x86_64-pc-linux-gnu Thread model: posix InstalledDir: /usr/lib/llvm/15/bin Configuration file: /etc/clang/clang.cfg /usr/lib/llvm/15 15.0.6 Python 3.10.9 Available Rust versions: [1] rust-bin-1.65.0 * The following VMs are available for generation-2: 1) IcedTea JDK 3.16.0 [icedtea-bin-8] 2) Eclipse Temurin JDK 11.0.17_p8 [openjdk-bin-11] *) Eclipse Temurin JDK 17.0.5_p8 [openjdk-bin-17] 4) Eclipse Temurin JDK 8.352_p08 [openjdk-bin-8] Available Java Virtual Machines: [1] icedtea-bin-8 [2] openjdk-bin-8 [3] openjdk-bin-11 [4] openjdk-bin-17 system-vm The Glorious Glasgow Haskell Compilation System, version 9.0.2 php cli (if any): [1] php8.2 * HEAD of ::gentoo commit c9abe9f5d0b407654ae74125a3b68ded8198d043 Author: Repository mirror & CI <repomirrorci@gentoo.org> Date: Tue Dec 20 06:02:20 2022 +0000 2022-12-20 06:02:20 UTC emerge -qpvO sys-boot/lilo [ebuild N ] sys-boot/lilo-24.2-r1 USE="-device-mapper -minimal -pxeserial -static"
Created attachment 844065 [details] emerge-info.txt
Created attachment 844067 [details] emerge-history.txt
Created attachment 844069 [details] etc.clang.tar.bz2
Created attachment 844071 [details] etc.portage.tar.bz2
Created attachment 844073 [details] logs.tar.bz2
Created attachment 844075 [details] sys-boot:lilo-24.2-r1:20221220-072606.log
> * Detected file collision(s): > * > * /usr/sbin/keytab-lilo > * > * Searching all installed packages for file collisions... > * > * Press Ctrl-C to Stop > * > * sys-boot/syslinux-6.04_pre1-r3:0::gentoo > * /usr/bin/keytab-lilo > * I am puzzled here. How is a file in /usr/bin in syslinux colliding with a file in /usr/sbin in lilo? I checked my dev box, and lilo only has the aforementioned file in /usr/sbin. Nothing like it in /usr/bin. I don't run with /usr merge, though. Is syslinux installing a symlink in /usr/sbin and that's what is hitting?
FWIW, syslinux isn't compiling for me, either, so I can't tell at the moment what files it's trying to install: > x86_64-pc-linux-gnu-ld -m elf_i386 -shared --hash-style=gnu -T /ramfs/portage/sys-boot/syslinux-6.04_pre3/work/syslinux-6.04-pre3/com32/lib/i386/elf.ld --as-needed -o hdt.elf hdt-ata.o hdt-cli-acpi.o hdt-cli-cpu.o hdt-cli-disk.o hdt-cli-dmi.o hdt-cli-hdt.o hdt-cli-kernel.o hdt-cli-memory.o hdt-cli-pci.o hdt-cli-pxe.o hdt-cli-syslinux.o hdt-cli-vesa.o hdt-cli-vpd.o hdt-cli.o hdt-common.o hdt-dump-acpi.o hdt-dump-cpu.o hdt-dump-disks.o hdt-dump-dmi.o hdt-dump-hdt.o hdt-dump-kernel.o hdt-dump-memory.o hdt-dump-pci.o hdt-dump-pxe.o hdt-dump-syslinux.o hdt-dump-vesa.o hdt-dump-vpd.o hdt-dump.o hdt-menu-about.o hdt-menu-acpi.o hdt-menu-disk.o hdt-menu-dmi.o hdt-menu-kernel.o hdt-menu-memory.o hdt-menu-pci.o hdt-menu-processor.o hdt-menu-pxe.o hdt-menu-summary.o hdt-menu-syslinux.o hdt-menu-vesa.o hdt-menu-vpd.o hdt-menu.o hdt-util.o hdt.o /ramfs/portage/sys-boot/syslinux-6.04_pre3/work/syslinux-6.04-pre3/bios/com32/libupload/libcom32upload.a /ramfs/portage/sys-boot/syslinux-6.04_pre3/work/syslinux-6.04-pre3/bios/com32/libutil/libutil.c32 /ramfs/portage/sys-boot/syslinux-6.04_pre3/work/syslinux-6.04-pre3/bios/com32/gpllib/libgpl.c32 /ramfs/portage/sys-boot/syslinux-6.04_pre3/work/syslinux-6.04-pre3/bios/com32/lib/libcom32.c32 /ramfs/portage/sys-boot/syslinux-6.04_pre3/work/syslinux-6.04-pre3/bios/com32/cmenu/libmenu/libmenu.c32 > x86_64-pc-linux-gnu-ld: warning: hdt.elf has a LOAD segment with RWX permissions > x86_64-pc-linux-gnu-objcopy --strip-debug --strip-unneeded hdt.elf hdt.c32 > make[4]: Leaving directory '/ramfs/portage/sys-boot/syslinux-6.04_pre3/work/syslinux-6.04-pre3/bios/com32/hdt' > make[3]: Leaving directory '/ramfs/portage/sys-boot/syslinux-6.04_pre3/work/syslinux-6.04-pre3/bios/com32' > make[2]: Leaving directory '/ramfs/portage/sys-boot/syslinux-6.04_pre3/work/syslinux-6.04-pre3/bios' > make[1]: *** [/ramfs/portage/sys-boot/syslinux-6.04_pre3/work/syslinux-6.04-pre3/Makefile:257: bios] Error 2 > make[1]: Leaving directory '/ramfs/portage/sys-boot/syslinux-6.04_pre3/work/syslinux-6.04-pre3' > make: *** [Makefile:102: bios] Error 2 > * ERROR: sys-boot/syslinux-6.04_pre3::gentoo failed (compile phase): > * emake failed >
(In reply to Joshua Kinard from comment #7) > I am puzzled here. How is a file in /usr/bin in syslinux colliding with a > file in /usr/sbin in lilo? I checked my dev box, and lilo only has the > aforementioned file in /usr/sbin. Nothing like it in /usr/bin. I don't run > with /usr merge, though. Is syslinux installing a symlink in /usr/sbin and > that's what is hitting? Gentoo conflates merged-usr with merged-bin: on such a system, /usr/sbin is a symlink to /usr/bin. Therefore, /usr/sbin/keytab-lilo and /usr/bin/keytab-lilo are the same file. A few possible solutions: 1. Drop keytab-lilo from lilo or syslinux. 2. Rename keytab-lilo in lilo or syslinux. 3. Add a soft blocker to lilo and syslinux so they cannot be installed simultaneously. I'm not actually sure what this binary is used for, but I would guess that either 1 or 2 are acceptable solutions.
(In reply to Mike Gilbert from comment #9) > (In reply to Joshua Kinard from comment #7) > > I am puzzled here. How is a file in /usr/bin in syslinux colliding with a > > file in /usr/sbin in lilo? I checked my dev box, and lilo only has the > > aforementioned file in /usr/sbin. Nothing like it in /usr/bin. I don't run > > with /usr merge, though. Is syslinux installing a symlink in /usr/sbin and > > that's what is hitting? > > Gentoo conflates merged-usr with merged-bin: on such a system, /usr/sbin is > a symlink to /usr/bin. Therefore, /usr/sbin/keytab-lilo and > /usr/bin/keytab-lilo are the same file. Yikes, and I thought the whole /bin --> /usr/bin && /sbin --> /usr/sbin bit was bad enough. Now we're just dumping all binaries into essentially one location? That's just asking for all sorts of fun and this particular instance seems to be the tip of the proverbial iceberg. > > A few possible solutions: > > 1. Drop keytab-lilo from lilo or syslinux. > 2. Rename keytab-lilo in lilo or syslinux. > 3. Add a soft blocker to lilo and syslinux so they cannot be installed > simultaneously. > > I'm not actually sure what this binary is used for, but I would guess that > either 1 or 2 are acceptable solutions. According to the manpage keytab-lilo.pl(8): > keytab-lilo is a program which compiles keytable definitions (in the format > specified in keytables(5)) into a format which can be used by lilo(8) to set > the keyboard type when booting [using the keytable parameter in /etc/lilo.conf]. Based on this description, this looks like a semi-important utility if one uses a non-US keyboard layout (I am uncertain if this also affects systems using a DVORAK keyboard vs QWERTY, but possibly), so I'd scratch #1 out. For #2, without knowing what syslinux says of its similarly-named tool, I'd say the problem is syslinux's to fix, not lilo's, insofar as moving or renaming the file. Looking at #3, since we are talking bootloaders here, there should arguably only be a single bootloader on a system at a time, so blocking one against the other is certainly an option. But I believe syslinux also contains some tooling alongside its bootloader that is useful, especially if one uses catalyst on a system to generate release media (needs USE 'system-bootloader'). So I don't think adding a block against sys-boot/syslinux to lilo would be effective here, at least without sorting out side-effects. I wander if there would be any value in separating the tooling portion of syslinux out from the bootloader portion and into two separate packages might be sensible? Then I can add a block against a hypothetical sys-boot/syslinux-bootloader to lilo, while sys-boot/syslinux-utils (or maybe sys-apps/syslinux-utils is better) can still be mergeable on a system that uses lilo as its bootloader. It doesn't look like this would be easy, though. Not seeing any kind of configure system in syslinux's source, so it sounds like doing that would be a manual job for syslinux's maintainer. Checking another Linux distro, Devuan appears to have three distinct packages for syslinux, two for bootloaders (BIOS, UEFI), and then a syslinux-utils package that contains some kind of "auxiliary" utilities. So there might be some logic to splitting that package up that can be borrowed from them. Thoughts?
Addendum: Looking around in syslinux's source, there is the file 'doc/keytab-lilo.txt', and it states this at the very top: > This is the documentation for the keytab-lilo.pl program. It was > taken verbatim from the LILO-20 README file; only this header was > added. So that implies that syslinux is using the same exact source from lilo for the keytab-lilo.pl file, thus the onus is on syslinux to fix the collision, not lilo. Off the top of my head, I cannot remember if it's possible to check if a particular package is already installed during the src_install phase, but ideally, if syslinux can detect that sys-boot/lilo is installed, then it could simply omit installing the keytab-lilo file, since we could assume that it is already present. If lilo is not installed, then it would install it. If we can't do that kind of dynamism from src_install, then we may need a local USE flag for syslinux to make installing this lilo tool optional, and then I can add a very specific block to lilo against that particular local USE in syslinux.
(In reply to Joshua Kinard from comment #11) > > Off the top of my head, I cannot remember if it's possible to check if a > particular package is already installed during the src_install phase, but > ideally, if syslinux can detect that sys-boot/lilo is installed, then it > could simply omit installing the keytab-lilo file, since we could assume > that it is already present. If lilo is not installed, then it would install > it. > That can't work for binary packages. > If we can't do that kind of dynamism from src_install, then we may need a > local USE flag for syslinux to make installing this lilo tool optional, and > then I can add a very specific block to lilo against that particular local > USE in syslinux. Yes, that sounds best.
(In reply to Sam James from comment #12) > (In reply to Joshua Kinard from comment #11) > > > > Off the top of my head, I cannot remember if it's possible to check if a > > particular package is already installed during the src_install phase, but > > ideally, if syslinux can detect that sys-boot/lilo is installed, then it > > could simply omit installing the keytab-lilo file, since we could assume > > that it is already present. If lilo is not installed, then it would install > > it. > > > > That can't work for binary packages. Had a suspicion that idea wasn't going to fly. > > If we can't do that kind of dynamism from src_install, then we may need a > > local USE flag for syslinux to make installing this lilo tool optional, and > > then I can add a very specific block to lilo against that particular local > > USE in syslinux. > > Yes, that sounds best. Okay, then please let me know when the change to syslinux is complete, and I will modify lilo accordingly, either before or after the holidays.
A USE flag to control installation of a single file seems a bit stupid to me. I'll just rename the script in syslinux.
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=2312b1a486f1512ad0c7c09af65739f6d8775f3c commit 2312b1a486f1512ad0c7c09af65739f6d8775f3c Author: Mike Gilbert <floppym@gentoo.org> AuthorDate: 2022-12-20 23:24:39 +0000 Commit: Mike Gilbert <floppym@gentoo.org> CommitDate: 2022-12-20 23:25:35 +0000 sys-boot/syslinux: rename keytab-lilo to keytab-syslinux Avoids a collision with sys-boot/lilo. Closes: https://bugs.gentoo.org/887395 Signed-off-by: Mike Gilbert <floppym@gentoo.org> .../{syslinux-6.04_pre1-r2.ebuild => syslinux-6.04_pre1-r4.ebuild} | 3 ++- .../{syslinux-6.04_pre1-r3.ebuild => syslinux-6.04_pre1-r5.ebuild} | 1 + .../{syslinux-6.04_pre3.ebuild => syslinux-6.04_pre3-r1.ebuild} | 1 + 3 files changed, 4 insertions(+), 1 deletion(-)
