libtool: link: (cd .libs/libdbus-testutils.lax/libdbus-internal.a && aarch64-unknown-linux-gnu-ar x "/var/tmp/portage/sys-apps/dbus-1.15.6/work/dbus-1.15.6-.arm64/test/../dbus/.libs/libdbus-internal.a") libtool: link: aarch64-unknown-linux-gnu-ar cr .libs/libdbus-testutils.a .libs/disable-crash-handling.o .libs/test-utils.o .libs/libdbus-testutils.lax/libdbus-internal.a/dbus-asv-util.o .libs/libdbus-testutils.lax/libdbus-internal.a/dbus-mainloop.o .libs/libdbus-testutils.lax/libdbus-internal.a/dbus-message-util.o .libs/libdbus-testutils.lax/libdbus-internal.a/dbus-pollable-set-epoll.o .libs/libdbus-testutils.lax/libdbus-internal.a/dbus-pollable-set-poll.o .libs/libdbus-testutils.lax/libdbus-internal.a/dbus-pollable-set.o .libs/libdbus-testutils.lax/libdbus-internal.a/dbus-shell.o .libs/libdbus-testutils.lax/libdbus-internal.a/dbus-spawn-unix.o .libs/libdbus-testutils.lax/libdbus-internal.a/dbus-string-util.o .libs/libdbus-testutils.lax/libdbus-internal.a/dbus-sysdeps-util-unix.o .libs/libdbus-testutils.lax/libdbus-internal.a/dbus-sysdeps-util.o .libs/libdbus-testutils.lax/libdbus-internal.a/dbus-userdb-util.o libtool: link: aarch64-unknown-linux-gnu-ranlib .libs/libdbus-testutils.a libtool: link: rm -fr .libs/libdbus-testutils.lax libtool: link: ( cd ".libs" && rm -f "libdbus-testutils.la" && ln -s "../libdbus-testutils.la" "libdbus-testutils.la" ) /bin/mkdir -p XDG_RUNTIME_DIR chmod 0700 XDG_RUNTIME_DIR || true make[3]: Leaving directory '/var/tmp/portage/sys-apps/dbus-1.15.6/work/dbus-1.15.6-.arm64/test' Making all in name-test make[3]: Entering directory '/var/tmp/portage/sys-apps/dbus-1.15.6/work/dbus-1.15.6-.arm64/test/name-test' make[3]: Nothing to be done for 'all'. make[3]: Leaving directory '/var/tmp/portage/sys-apps/dbus-1.15.6/work/dbus-1.15.6-.arm64/test/name-test' make[2]: Leaving directory '/var/tmp/portage/sys-apps/dbus-1.15.6/work/dbus-1.15.6-.arm64/test' Making all in doc make[2]: Entering directory '/var/tmp/portage/sys-apps/dbus-1.15.6/work/dbus-1.15.6-.arm64/doc' /usr/bin/xmlto man dbus-cleanup-sockets.1.xml /usr/bin/xmlto man dbus-daemon.1.xml /usr/bin/xmlto man dbus-launch.1.xml /usr/bin/xmlto man dbus-monitor.1.xml /usr/bin/xmlto man dbus-run-session.1.xml /usr/bin/xmlto man dbus-send.1.xml make[2]: /usr/bin/xmlto: No such file or directory /usr/bin/xmlto man dbus-test-tool.1.xml make[2]: *** [Makefile:912: dbus-cleanup-sockets.1] Error 127 make[2]: /usr/bin/xmlto: No such file or directory make[2]: *** Waiting for unfinished jobs.... make[2]: *** [Makefile:912: dbus-daemon.1] Error 127 make[2]: /usr/bin/xmlto: No such file or directory make[2]: /usr/bin/xmlto: No such file or directory make[2]: /usr/bin/xmlto: No such file or directory make[2]: *** [Makefile:912: dbus-run-session.1] Error 127 make[2]: /usr/bin/xmlto: No such file or directory make[2]: *** [Makefile:912: dbus-monitor.1] Error 127 make[2]: *** [Makefile:912: dbus-launch.1] Error 127 make[2]: *** [Makefile:912: dbus-send.1] Error 127 make[2]: /usr/bin/xmlto: No such file or directory make[2]: *** [Makefile:912: dbus-test-tool.1] Error 127 make[2]: Leaving directory '/var/tmp/portage/sys-apps/dbus-1.15.6/work/dbus-1.15.6-.arm64/doc' make[1]: *** [Makefile:721: all-recursive] Error 1 make[1]: Leaving directory '/var/tmp/portage/sys-apps/dbus-1.15.6/work/dbus-1.15.6-.arm64' make: *** [Makefile:588: all] Error 2 * ERROR: sys-apps/dbus-1.15.6::gentoo failed (compile phase): * emake failed * * If you need support, post the output of `emerge --info '=sys-apps/dbus-1.15.6::gentoo'`, * the complete build log and the output of `emerge -pqv '=sys-apps/dbus-1.15.6::gentoo'`. * The complete build log is located at '/var/tmp/portage/sys-apps/dbus-1.15.6/temp/build.log.gz'. * The ebuild environment file is located at '/var/tmp/portage/sys-apps/dbus-1.15.6/temp/environment'. * Working directory: '/var/tmp/portage/sys-apps/dbus-1.15.6/work/dbus-1.15.6-.arm64' * S: '/var/tmp/portage/sys-apps/dbus-1.15.6/work/dbus-1.15.6' I see that app-text/xmlto was scheduled to be merged, but it wasn't merged *prior* to sys-apps/dbus. Maybe its set as the wrong kind of dependency? Needs to be labled as a build dependency instead of runtime?
installing ONLY sys-apps/dbus with emerge -1 --ignore-default-opts sys-apps/dbus failed installing ONLY sys-apps/dbus and app-text/xmlto with emerge -1 --ignore-default-opts sys-apps/dbus app-text/xmlto failed but installing app-text/xmlto first, and then after that completed, installing sys-apps/dbus succeeded.
It's in the ebuild: https://gitweb.gentoo.org/repo/gentoo.git/tree/sys-apps/dbus/dbus-1.15.6.ebuild#n33. Please include the full build.log, emerge --info, and ideally the emerge command and the merge order.
I am unable to reproduce the issue by running the following: emerge -C app-text/xmlto emerge -1 --ignore-default-opts sys-apps/dbus
Gotta say, closing bugs immediately is pretty discouraging, even if you need more info from the reporter. I've reproduced this 3 times in my build environment. Getting logs out of it is a pita, but i'll do it since it's apparently needed.
(In reply to Michael Jones from comment #4) > Gotta say, closing bugs immediately is pretty discouraging, even if you need > more info from the reporter. Sorry about that, but this isn't exactly a high quality bug report. Your bug report makes a claim that is demonstrably false: sys-apps/dbus is not missing a dependency on app-text/xmlto. I suspect that is part of why Sam closed it immediately. I have a hunch this is user error, and not a bug at all. You'll have to provide sufficient info to convince us otherwise.
> Sorry about that, but this isn't exactly a high quality bug report. Reporting bugs to gentoo is such a massive pain in the ass that sometimes i don't want to put in the work to describe every facet of the problem until i know what information is needed. It's not like I haven't uploaded every log under the sun and still had my report closed or ignored in the past. We're all volunteers here. My time isn't free either. Maybe provide us with an automatic bug creation tool in the pkgdev tool that'll automatically upload the information you're looking for, instead of the current process of manually attaching files to --------------------- > Your bug report makes a claim that is demonstrably false: That was a speculation. It's not like my claim that the build of dbus failed, or the error message that the log contains is somehow false. > make[2]: /usr/bin/xmlto: No such file or directory --------------------- > I have a hunch this is user error, and not a bug at all. It's an automated build environment. Its not user error. My suspicion is that it's got something to do with the xmlto package being a binpkg, and the dbus package being built from source. I retriggered the build, i'll upload all of the logs as soon as it reproduces the problem. > You'll have to provide sufficient info to convince us otherwise. As someone who's worked in various open source projects for a long time (just like you have), my unsolicited advice is that this is a pretty terrible position to take. I wouldn't have opened the report if there wasn't a problem. I don't have to convince you that a problem exists. I know it exists. I have to convince you to put your volunteer time into fixing it. Being antagonistic to user-provided problem reports simply means that your users stop providing you with reports, and you get to live in the echo-chamber you created as a result. It's extremely demotivating to people to constantly be met with negative responses whenever they bring problems to Gentoo.
> manually attaching files to I meant > manually attaching files to bugzilla
I think we really just need to see exactly how you are invoking emerge and the output it produces.
Also, emerge --info should be included in every bug report you create.
> Also, emerge --info should be included in every bug report you create. that's what the `pkgdev` suggestion was for.
Patches welcome. In the mean time, expect us to ask for it every time.
I can't reproduce the problem anymore. Presumably the underlying issue was something to do with binpkgs, but manually interfering with the build environment to get dbus to build worked around the underlying issue, and blowing everything away and starting from a clean slate didn't reproduce it. This probably indicates the issue wasn't really an issue with dbus or xmlto, but something else related to the binpkg generated from a previous build. If it happens again, i'll report it with more log information. The build environment in question is https://github.com/GenPi64/Build.Dist , which executes the build inside of a qemu-aarch64 chroot. This makes it very difficult to extract logs, especially in our CI environment https://ci.genpi64.com/ , as the next build would blow everything away. if I had a flag for emerge that could be used to make portage automatically open a bug report on a build failure with all of the appropraite logs, i would enable that.
> If it happens again, i'll report it with more log information. Sounds good. To be fully transparent, my hunch is that your build scripts are invoking emerge in some way that disables build-time dependency resolution. That's what I mean by "user error". I took a quick look at the repo you linked, and it wasn't immediately obvious to me where/how emerge is invoked. I would highly suggest you add the full emerge command line to whatever logging the scripts produce by default. You could also add emerge --info there as well. It's also possible that Portage has some bug that causes the merge order to get mixed up. This has happened in the past, usually when cycles exist in the dependency graph (circular dependencies). If it happens again, file a bug against sys-apps/portage. You can select the "Portage Development" product when creating a bug to get your report routed directly to the dev-portage team.
The commands are listed here, they're executed in order. https://github.com/GenPi64/Build.Dist/blob/master/subtargets/gentoo-base.json emerge --info is here Portage 3.0.49 (python 3.11.4-final-0, default/linux/arm64/17.0, gcc-12, glibc-2.37-r3, 6.4.9-gentoo aarch64) ================================================================= System uname: Linux-6.4.9-gentoo-aarch64-with-glibc2.37 KiB Mem: 131009904 total, 94459092 free KiB Swap: 0 total, 0 free Timestamp of repository gentoo: Mon, 14 Aug 2023 21:31:43 +0000 sh bash 5.1_p16-r6 ld GNU ld (Gentoo 2.40 p5) 2.40.0 ccache version 4.8.2 [enabled] app-misc/pax-utils: 1.3.7::gentoo app-shells/bash: 5.1_p16-r6::gentoo dev-lang/perl: 5.36.1-r3::gentoo dev-lang/python: 3.11.4::gentoo dev-util/ccache: 4.8.2::gentoo dev-util/cmake: 3.26.4-r2::gentoo dev-util/meson: 1.1.1::gentoo sys-apps/baselayout: 2.13-r1::gentoo sys-apps/openrc: 0.47.1::gentoo sys-apps/sandbox: 2.37::gentoo sys-devel/autoconf: 2.71-r6::gentoo sys-devel/automake: 1.16.5::gentoo sys-devel/binutils: 2.40-r5::gentoo sys-devel/binutils-config: 5.5::gentoo sys-devel/gcc: 12.3.1_p20230526::gentoo sys-devel/gcc-config: 2.11::gentoo sys-devel/libtool: 2.4.7-r1::gentoo sys-devel/make: 4.4.1-r1::gentoo sys-kernel/linux-headers: 6.1::gentoo (virtual/os-headers) sys-libs/glibc: 2.37-r3::gentoo Repositories: gentoo location: /var/db/repos/gentoo sync-type: git sync-uri: https://github.com/gentoo-mirror/gentoo priority: -1000 volatile: False sync-git-verify-commit-signature: true genpi-tools location: /var/db/repos/genpi-tools sync-type: git sync-uri: https://github.com/GenPi64/genpi-tools.git masters: gentoo priority: 50 volatile: False genpi64 location: /var/db/repos/genpi64 sync-type: git sync-uri: https://github.com/GenPi64/genpi64-overlay.git masters: gentoo priority: 100 volatile: False sync-git-clone-extra-opts: --single-branch --branch master Binary Repositories: genpi64-binhost priority: 9999 sync-uri: https://s3.genpi64.com/binpkgs ACCEPT_KEYWORDS="arm64" ACCEPT_LICENSE="@FREE" CBUILD="aarch64-unknown-linux-gnu" CFLAGS="-O2 -march=armv8-a+crc -mtune=cortex-a72 -ftree-vectorize -O2 -pipe" CHOST="aarch64-unknown-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/sandbox.d /etc/terminfo" CXXFLAGS="-O2 -march=armv8-a+crc -mtune=cortex-a72 -ftree-vectorize -O2 -pipe" DISTDIR="/var/cache/distfiles" EMERGE_DEFAULT_OPTS="--jobs --newrepo --newuse --changed-use --changed-deps --changed-slot --deep --tree --unordered-display --nospinner --backtrack=3000 --complete-graph --with-bdeps=y --rebuild-if-new-rev --rebuild-if-new-ver --rebuild-if-unbuilt --rebuilt-binaries --binpkg-respect-use=y --binpkg-changed-deps=y --usepkg=y --buildpkg-exclude 'virtual/* sys-kernel/*-sources */*-bin acct-user/* acct-group/*'" ENV_UNSET="CARGO_HOME DBUS_SESSION_BUS_ADDRESS DISPLAY GDK_PIXBUF_MODULE_FILE GOBIN GOPATH PERL5LIB PERL5OPT PERLPREFIX PERL_CORE PERL_MB_OPT PERL_MM_OPT XAUTHORITY XDG_CACHE_HOME XDG_CONFIG_HOME XDG_DATA_HOME XDG_RUNTIME_DIR XDG_STATE_HOME" FCFLAGS="-O2 -march=armv8-a+crc -mtune=cortex-a72 -ftree-vectorize -O2 -pipe" FEATURES="assume-digests binpkg-docompress binpkg-dostrip binpkg-logs binpkg-multi-instance buildpkg buildpkg-live ccache clean-logs compress-build-logs config-protect-if-modified distlocks ebuild-locks fixlafiles ipc-sandbox merge-sync multilib-strict news parallel-fetch parallel-install preserve-libs protect-owned qa-unresolved-soname-deps sandbox sfperms strict unknown-features-warn unmerge-logs unmerge-orphans userfetch usersync xattr" FFLAGS="-O2 -march=armv8-a+crc -mtune=cortex-a72 -ftree-vectorize -O2 -pipe" GENTOO_MIRRORS="http://distfiles.gentoo.org" LANG="C.UTF-8" LDFLAGS="-Wl,-O1 -Wl,--as-needed" LEX="flex" MAKEOPTS="-j4 -l4" PKGDIR="/var/cache/binpkgs" PORTAGE_COMPRESS="zstd" PORTAGE_COMPRESS_FLAGS="-15" 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 arm64 bindist bzip2 cli crypt dri elogind fortran gdbm iconv ipv6 libtirpc ncurses nls nptl openmp pam pcre readline seccomp split-usr ssl test-rust unicode xattr zlib" ADA_TARGET="gnat_2021" APACHE2_MODULES="authn_core authz_core socache_shmcb unixd actions alias auth_basic authn_alias authn_anon authn_dbm authn_default authn_file authz_dbm authz_default authz_groupfile authz_host authz_owner authz_user autoindex cache cgi cgid dav dav_fs dav_lock deflate dir disk_cache env expires ext_filter file_cache filter headers include info log_config logio mem_cache mime mime_magic negotiation rewrite setenvif speling status unique_id userdir usertrack vhost_alias" CALLIGRA_FEATURES="karbon sheets words" COLLECTD_PLUGINS="df interface irq load memory rrdtool swap syslog" CPU_FLAGS_ARM="edsp v8 vfp vfp-d32 vfpv3 vfpv4" ELIBC="glibc" GPSD_PROTOCOLS="ashtech aivdm earthmate evermore fv18 garmin garmintxt gpsclock greis isync itrax mtk3301 nmea ntrip navcom oceanserver oldstyle oncore rtcm104v2 rtcm104v3 sirf skytraq superstar2 timing tsip tripmate tnt ublox ubx" INPUT_DEVICES="libinput" KERNEL="linux" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" LIBREOFFICE_EXTENSIONS="presenter-console presenter-minimizer" LUA_SINGLE_TARGET="lua5-1" LUA_TARGETS="lua5-1" OFFICE_IMPLEMENTATION="libreoffice" PHP_TARGETS="php8-1" POSTGRES_TARGETS="postgres15" PYTHON_SINGLE_TARGET="python3_11" PYTHON_TARGETS="python3_11" RUBY_TARGETS="ruby31" VIDEO_CARDS="vc4 v3d fbdev" XTABLES_ADDONS="quota2 psd pknock lscan length2 ipv4options ipset ipp2p iface geoip fuzzy condition tee tarpit sysrq proto steal rawnat logmark ipmark dhcpmac delude chaos account" Unset: ADDR2LINE, AR, ARFLAGS, AS, ASFLAGS, CC, CCLD, CONFIG_SHELL, CPP, CPPFLAGS, CTARGET, CXX, CXXFILT, ELFEDIT, EXTRA_ECONF, F77FLAGS, FC, GCOV, GPROF, INSTALL_MASK, LC_ALL, LD, LFLAGS, LIBTOOL, LINGUAS, MAKE, MAKEFLAGS, NM, OBJCOPY, OBJDUMP, PORTAGE_BINHOST, PORTAGE_BUNZIP2_COMMAND, PORTAGE_RSYNC_EXTRA_OPTS, RANLIB, READELF, RUSTFLAGS, SHELL, SIZE, STRINGS, STRIP, YACC, YFLAGS make.conf is c86f6e44-9300-4af3-abd9-bece7f41d672 /var/tmp/portage # cat /etc/portage/make.conf CFLAGS="${CFLAGS} -march=armv8-a+crc -mtune=cortex-a72 -ftree-vectorize -O2 -pipe" CXXFLAGS="${CFLAGS}" FCFLAGS="${CFLAGS}" FFLAGS="${CFLAGS}" USE="bindist -checkboot -systemd elogind" FEATURES="buildpkg binpkg-multi-instance clean-logs compress-build-logs parallel-fetch parallel-install userfetch usersync ccache -userpriv -usersandbox -network-sandbox -pid-sandbox" MAKEOPTS="-j4 -l4" VIDEO_CARDS="vc4 v3d fbdev" INPUT_DEVICES="libinput" BINPKG_FORMAT="gpkg" BINPKG_COMPRESS="zstd" BINPKG_COMPRESS_FLAGS="-15" PORTAGE_COMPRESS="zstd" PORTAGE_COMPRESS_FLAGS="-15" PORTAGE_NICENESS="20" EMERGE_DEFAULT_OPTS="--jobs --newrepo --newuse --changed-use --changed-deps --changed-slot --deep --tree --unordered-display --nospinner --backtrack=3000 --complete-graph --with-bdeps=y --rebuild-if-new-rev --rebuild-if-new-ver --rebuild-if-unbuilt --rebuilt-binaries --binpkg-respect-use=y --binpkg-changed-deps=y --usepkg=y --buildpkg-exclude 'virtual/* sys-kernel/*-sources */*-bin acct-user/* acct-group/*'" CHOST="aarch64-unknown-linux-gnu"
I determined the immediate cause of this failure $ head -n 2 /usr/bin/xmlto #!/usr/bin/bash But there is no /usr/bin/bash. bash is installed in /bin/bash on this system. $ /usr/bin/xmlto bash: /usr/bin/xmlto: /usr/bin/bash: bad interpreter: No such file or directory $ which bash /bin/bash Changing the first line of /usr/bin/xmlto to #!/usr/bin/env bash allows the compilation to proceed. This is with the following profile: 91fb6e89-7bb2-4657-9776-1de5aaddb9e1 /etc/portage # eselect profile list Available profile symlink targets: [1] default/linux/arm64/17.0 (stable) * Which, as far as I can tell, does not have the usr-merge applied to it. Portage 3.0.49 (python 3.11.5-final-0, default/linux/arm64/17.0, gcc-12, glibc-2.37-r3, 6.4.11-gentoo aarch64) ================================================================= System Settings ================================================================= System uname: Linux-6.4.11-gentoo-aarch64-with-glibc2.37 KiB Mem: 131011176 total, 28867964 free KiB Swap: 0 total, 0 free Timestamp of repository gentoo: Thu, 14 Sep 2023 00:01:42 +0000 sh bash 5.1_p16-r6 ld GNU ld (Gentoo 2.40 p5) 2.40.0 ccache version 4.8.2 [enabled] app-misc/pax-utils: 1.3.7::gentoo app-shells/bash: 5.1_p16-r6::gentoo dev-lang/perl: 5.36.1-r3::gentoo dev-lang/python: 3.11.5::gentoo dev-util/ccache: 4.8.2::gentoo dev-util/cmake: 3.26.5-r2::gentoo dev-util/meson: 1.1.1::gentoo sys-apps/baselayout: 2.14::gentoo sys-apps/openrc: 0.47.1::gentoo sys-apps/sandbox: 2.37::gentoo sys-devel/autoconf: 2.71-r6::gentoo sys-devel/automake: 1.16.5::gentoo sys-devel/binutils: 2.40-r5::gentoo sys-devel/binutils-config: 5.5::gentoo sys-devel/gcc: 12.3.1_p20230526::gentoo sys-devel/gcc-config: 2.11::gentoo sys-devel/libtool: 2.4.7-r1::gentoo sys-devel/make: 4.4.1-r1::gentoo sys-kernel/linux-headers: 6.1::gentoo (virtual/os-headers) sys-libs/glibc: 2.37-r3::gentoo Repositories: gentoo location: /var/db/repos/gentoo sync-type: git sync-uri: https://github.com/gentoo-mirror/gentoo priority: -1000 volatile: False sync-git-verify-commit-signature: true genpi-tools location: /var/db/repos/genpi-tools sync-type: git sync-uri: https://github.com/GenPi64/genpi-tools.git masters: gentoo priority: 50 volatile: False genpi64 location: /var/db/repos/genpi64 sync-type: git sync-uri: https://github.com/GenPi64/genpi64-overlay.git masters: gentoo priority: 100 volatile: False sync-git-clone-extra-opts: --single-branch --branch master Binary Repositories: genpi64-binhost priority: 9999 sync-uri: https://s3.genpi64.com/binpkgs ACCEPT_KEYWORDS="arm64" ACCEPT_LICENSE="@FREE" CBUILD="aarch64-unknown-linux-gnu" CFLAGS="-O2 -march=armv8-a+crc -mtune=cortex-a72 -ftree-vectorize -O2 -pipe" CHOST="aarch64-unknown-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/sandbox.d /etc/terminfo" CXXFLAGS="-O2 -march=armv8-a+crc -mtune=cortex-a72 -ftree-vectorize -O2 -pipe" DISTDIR="/var/cache/distfiles" EMERGE_DEFAULT_OPTS="--jobs --newrepo --newuse --changed-use --changed-deps --changed-slot --deep --tree --unordered-display --nospinner --backtrack=3000 --complete-graph --with-bdeps=y --rebuild-if-new-rev --rebuild-if-new-ver --rebuild-if-unbuilt --rebuilt-binaries --binpkg-respect-use=y --binpkg-changed-deps=y --usepkg=y --buildpkg-exclude='virtual/*' --buildpkg-exclude='sys-kernel/*-sources' --buildpkg-exclude='*/*-bin' --buildpkg-exclude='acct-user/*' --buildpkg-exclude='acct-group/*' --buildpkg-exclude='dev-perl/*' --usepkg-exclude='virtual/*' --usepkg-exclude='sys-kernel/*-sources' --usepkg-exclude='*/*-bin' --usepkg-exclude='acct-user/*' --usepkg-exclude='acct-group/*' --usepkg-exclude='dev-perl/*'" ENV_UNSET="CARGO_HOME DBUS_SESSION_BUS_ADDRESS DISPLAY GDK_PIXBUF_MODULE_FILE GOBIN GOPATH PERL5LIB PERL5OPT PERLPREFIX PERL_CORE PERL_MB_OPT PERL_MM_OPT XAUTHORITY XDG_CACHE_HOME XDG_CONFIG_HOME XDG_DATA_HOME XDG_RUNTIME_DIR XDG_STATE_HOME" FCFLAGS="-O2 -march=armv8-a+crc -mtune=cortex-a72 -ftree-vectorize -O2 -pipe" FEATURES="assume-digests binpkg-docompress binpkg-dostrip binpkg-logs binpkg-multi-instance buildpkg buildpkg-live ccache clean-logs compress-build-logs config-protect-if-modified distlocks ebuild-locks fixlafiles ipc-sandbox merge-sync multilib-strict news parallel-fetch parallel-install preserve-libs protect-owned qa-unresolved-soname-deps sandbox sfperms strict unknown-features-warn unmerge-logs unmerge-orphans userfetch usersync xattr" FFLAGS="-O2 -march=armv8-a+crc -mtune=cortex-a72 -ftree-vectorize -O2 -pipe" GENTOO_MIRRORS="http://distfiles.gentoo.org" LANG="C.UTF-8" LDFLAGS="-Wl,-O1 -Wl,--as-needed" LEX="flex" MAKEOPTS="-j4 -l4" PKGDIR="/var/cache/binpkgs" PORTAGE_COMPRESS="zstd" PORTAGE_COMPRESS_FLAGS="-15" 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 arm64 bindist bzip2 cli crypt dri elogind fortran gdbm iconv ipv6 libtirpc ncurses nls nptl openmp pam pcre readline seccomp split-usr ssl test-rust unicode xattr zlib" ADA_TARGET="gnat_2021" APACHE2_MODULES="authn_core authz_core socache_shmcb unixd actions alias auth_basic authn_alias authn_anon authn_dbm authn_default authn_file authz_dbm authz_default authz_groupfile authz_host authz_owner authz_user autoindex cache cgi cgid dav dav_fs dav_lock deflate dir disk_cache env expires ext_filter file_cache filter headers include info log_config logio mem_cache mime mime_magic negotiation rewrite setenvif speling status unique_id userdir usertrack vhost_alias" CALLIGRA_FEATURES="karbon sheets words" COLLECTD_PLUGINS="df interface irq load memory rrdtool swap syslog" CPU_FLAGS_ARM="edsp v8 vfp vfp-d32 vfpv3 vfpv4" ELIBC="glibc" GPSD_PROTOCOLS="ashtech aivdm earthmate evermore fv18 garmin garmintxt gpsclock greis isync itrax mtk3301 nmea ntrip navcom oceanserver oldstyle oncore rtcm104v2 rtcm104v3 sirf skytraq superstar2 timing tsip tripmate tnt ublox ubx" INPUT_DEVICES="libinput" KERNEL="linux" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" LIBREOFFICE_EXTENSIONS="presenter-console presenter-minimizer" LUA_SINGLE_TARGET="lua5-1" LUA_TARGETS="lua5-1" OFFICE_IMPLEMENTATION="libreoffice" PHP_TARGETS="php8-1" POSTGRES_TARGETS="postgres15" PYTHON_SINGLE_TARGET="python3_11" PYTHON_TARGETS="python3_11" RUBY_TARGETS="ruby31" VIDEO_CARDS="vc4 v3d fbdev" XTABLES_ADDONS="quota2 psd pknock lscan length2 ipv4options ipset ipp2p iface geoip fuzzy condition tee tarpit sysrq proto steal rawnat logmark ipmark dhcpmac delude chaos account" Unset: ADDR2LINE, AR, ARFLAGS, AS, ASFLAGS, CC, CCLD, CONFIG_SHELL, CPP, CPPFLAGS, CTARGET, CXX, CXXFILT, ELFEDIT, EXTRA_ECONF, F77FLAGS, FC, GCOV, GPROF, INSTALL_MASK, LC_ALL, LD, LFLAGS, LIBTOOL, LINGUAS, MAKE, MAKEFLAGS, NM, OBJCOPY, OBJDUMP, PORTAGE_BINHOST, PORTAGE_BUNZIP2_COMMAND, PORTAGE_RSYNC_EXTRA_OPTS, RANLIB, READELF, RUSTFLAGS, SHELL, SIZE, STRINGS, STRIP, YACC, YFLAGS ================================================================= Package Settings ================================================================= app-text/xmlto-0.0.28-r10::gentoo was built with the following: USE="(-latex) -text" CFLAGS="-march=armv8-a+crc -mtune=cortex-a72 -ftree-vectorize -O2 -pipe -march=armv8-a+crc -mtune=cortex-a72 -ftree-vectorize -O2 -pipe" CXXFLAGS="-march=armv8-a+crc -mtune=cortex-a72 -ftree-vectorize -O2 -pipe -march=armv8-a+crc -mtune=cortex-a72 -ftree-vectorize -O2 -pipe"
I'm unable to change the title of the bug,
(In reply to Michael Jones from comment #16) > I'm unable to change the title of the bug, Ugh, nevermind this. It submitted this comment *because* i changed the title.
temporarily modifying /var/db/repos/gentoo/app-text/xmlto/xmlto-0.0.28-r10.ebuild to add echo "BASH=${BASH}" to the src_configure() function and then running ebuild /var/db/repos/gentoo/app-text/xmlto/xmlto-0.0.28-r10.ebuild configure | grep BASH I see that portage is detecting bash as BASH=/bin/bash which is what i expect What appears to be happening (Hard to tell), is that the image builder (for the genpi64 project, which i detailed in other comments) is picking up the binpkg from the systemd variant that was built just before the openrc build was started. This implies that the xmlto binpkg has something missing from it's list of dependencies, since the systemd build *does* have the usr-merge applied to it, so the /usr/bin/bash path is valid. switching the app-text/xmlto package to *always* use /usr/bin/env to detect where bash is at runtime would solve this problem without having to figure out how to express in the binpkg that the xmlto binpkg can't be installed on an openrc system unless it's had the usr-merge procedure applied to it.
This would also explain why i couldn't reproduce the problem previously, with a clean-slate. Since the problem is only reproducable if a binpkg is installed with the wrong path to bash.
This seems like a good reason not to mix binpkgs between merged-usr and split-usr systems.
To expand on that: we could certainly modify xmlto to use a more generic shebang, but I worry this will just be the tip of the iceberg and you will continue to run into similar problems in other packages.
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=6545573120c2238469c76b383358f507bfab6e58 commit 6545573120c2238469c76b383358f507bfab6e58 Author: Mike Gilbert <floppym@gentoo.org> AuthorDate: 2023-09-14 20:43:29 +0000 Commit: Mike Gilbert <floppym@gentoo.org> CommitDate: 2023-09-14 20:45:31 +0000 app-text/xmlto: pass BASH=/bin/bash to configure This ensures the same xmlto script can be used on merged-usr and split-usr systems. Closes: https://bugs.gentoo.org/912286 Signed-off-by: Mike Gilbert <floppym@gentoo.org> .../xmlto/{xmlto-0.0.28-r10.ebuild => xmlto-0.0.28-r11.ebuild} | 10 +++++++--- 1 file changed, 7 insertions(+), 3 deletions(-)
Is the experimental binhost project (which I don't know if that's still a thing or not: https://dilfridge.blogspot.com/2021/09/experimental-binary-gentoo-package.html ) going to only ever support one profile, and you're out of luck if you aren't using that profile? How would this be communicated? The client device has no way to know what the binpkg was built on unless the binpkg includes that information. As far as I know, there's nothing documented (e.g. on the wiki https://wiki.gentoo.org/wiki/Binary_package_guide , or man pages) about the binpkgs that have the caveat emptor that the binpkgs must match the same profile as the build host. One of the reason why the genpi64 project sets EMERGE_DEFAULT_OPTS with such a large list of flags: EMERGE_DEFAULT_OPTS="--jobs --newrepo --newuse --changed-use --changed-deps --changed-slot --deep --tree --unordered-display --nospinner --backtrack=3000 --complete-graph --with-bdeps=y --rebuild-if-new-rev --rebuild-if-new-ver --rebuild-if-unbuilt --rebuilt-binaries --binpkg-respect-use=y --binpkg-changed-deps=y --usepkg=y" Is specifically to try to minimize the places where packages, whether binpkgs or built from source, can get out of sync with each other. I'm happy to change the way I'm doing things if you have any suggestions.
Mixing profiles for binpkgs is sometimes safe, but not always. merged-usr is one exception, for exactly the issue demonstrated in this bug report. Another exception differences in SYMLINK_LIB (see the 17.0 vs 17.1 profiles for amd64). And of course, you could never mix profiles with different ARCH values.
(In reply to Mike Gilbert from comment #24) > Mixing profiles for binpkgs is sometimes safe, but not always. > > merged-usr is one exception, for exactly the issue demonstrated in this bug > report. > Can this be encoded into the binpkg? > Another exception differences in SYMLINK_LIB (see the 17.0 vs 17.1 profiles > for amd64). > Similar to the above. > And of course, you could never mix profiles with different ARCH values. My understanding is that this would implicitly not work. If it would, wouldn't we want portage to prevent itself from installing packages that don't match the ARCH of the system?
(In reply to Michael Jones from comment #25) > Can this be encoded into the binpkg? At the moment, no.
(In reply to Michael Jones from comment #25) > > And of course, you could never mix profiles with different ARCH values. > > My understanding is that this would implicitly not work. If it would, > wouldn't we want portage to prevent itself from installing packages that > don't match the ARCH of the system? Ah, you're right. That's mainly because ARCH is a implicit USE flag, and that lets Portage tell them apart. merged-usr/split-usr is problematic because sys-apps/baselayout[split-usr] and sys-apps/baselayout[-split-usr] produce different filesystem layouts, which implicitly affects every other package.
I had thought that all packages implicitly depend on baselayout ? clearly they don't, but if they did, wouldn't that resolve this?
No, an implicit dependency on sys-apps/baselayout would not resolve it. If we added IUSE="split-usr" to every package, that would resolve it, but it would also be overkill since not every package is actually affected by this issue. It would also cause you to effectively have 2 sets of distinct binpkgs anyway, which eliminates the benefit of sharing a binhost.
(In reply to Mike Gilbert from comment #29) > No, an implicit dependency on sys-apps/baselayout would not resolve it. > I'm not following you. the binpkg records what it's dependencies are, including the useflags of them. The --binpkg-changed-deps=y flag to emerge tells emerge that if the dependencies for the binpkg don't match the current system, then don't install the binpkg but install from source instead. > --binpkg-changed-deps [ y | n ] > Tells emerge to ignore binary packages for which the corresponding ebuild dependencies have changed since the packages were built. In order to help avoid issues with resolving inconsistent dependencies, this option is > automatically enabled unless the --usepkgonly option is enabled. Behavior with respect to changed build-time dependencies is controlled by the --with-bdeps option. So adding an implicit dependency on `sys-apps/baselayout` would mean adding an implicit dependency on `sys-apps/baselayout[split-user]` or `sys-apps/baselayout[-split-user]`, and prevent a binpkg from a split-user system from being installed on a non-split-user system (and vice versa), unless the user asks portage to ignore the changed dependency for the binpkg. Am I misunderstanding what binpkg-changed-deps does? If so, what flag is intended to control the behavior of "don't install the binpkg if the dependencies don't match exactly" ?
(In reply to Michael Jones from comment #30) That flag covers the case where you have a baselayout binpkg with RDPEND="app-misc/foo", and someone updates the baselayout ebuild in gentoo.git to have RDEPEND="app-misc/bar" instead. In that case, running emerge --usepkg --binpkg-changed-deps sys-apps/baselayout would ignore the binpkg and build a fresh copy of baselayout usign the the ebuild. It really has nothing to do with USE flags.
(In reply to Mike Gilbert from comment #31) > (In reply to Michael Jones from comment #30) > > That flag covers the case where you have a baselayout binpkg with > RDPEND="app-misc/foo", and someone updates the baselayout ebuild in > gentoo.git to have RDEPEND="app-misc/bar" instead. > > In that case, running emerge --usepkg --binpkg-changed-deps > sys-apps/baselayout would ignore the binpkg and build a fresh copy of > baselayout usign the the ebuild. > > It really has nothing to do with USE flags. Ok. Thanks for the explanation. The documentation in the manpage is misleading and should be improved. Is there really no flag for portage to force it to not install binpkgs when the use-flags of packages listed as depedencies have changed? Honestly I was under the impression that this was the default behavior of portage in the first place, with a flag to turn it off, not a flag to turn it on.
I'm not aware of any way to make portage do that.
(In reply to Mike Gilbert from comment #33) > I'm not aware of any way to make portage do that. Ok. Then how can any binpkg be safe to install, ever? If it's not possible to make portage enforce that a binpkg that depends on some-category/some-library[some-useflag] not be installed on a system that has some-category/some-library[-some-useflag], then surely the entire binpkg feature is effectively unusable?
You have made quite a leap there. In any case this is not the right venue for this discussion. Please drop in on IRC if you want to discuss further.
(In reply to Mike Gilbert from comment #35) > You have made quite a leap there. > > In any case this is not the right venue for this discussion. Please drop in > on IRC if you want to discuss further. *sigh*, dude I didn't make a leap at all. You just told me that portage isn't able to verify that dependencies of packages have the use flags that the packages declare they need. That makes the entire binpkg feature fundementally unsafe. Either I misunderstood your response, or you misunderstood my question. Thank you for the offer of IRC. I will pass. That's not an appropriate forum for any form of technical conversation. Thank you for your time, and the change to the xmlto package.
(In reply to Michael Jones from comment #36) Nothing depends in sys-apps/baselayout[split-usr] or sys-apps/baselayout[-split-usr]. Some things depend on sys-apps/baselayout, but they express no dependency on the split-usr USE flag.
(In reply to Mike Gilbert from comment #37) > (In reply to Michael Jones from comment #36) > > Nothing depends in sys-apps/baselayout[split-usr] or > sys-apps/baselayout[-split-usr]. > > Some things depend on sys-apps/baselayout, but they express no dependency on > the split-usr USE flag. That's.... the whole reason that I asked about an implicit dependency being added to the binpkg. The entire discussion was based around 1. Perforce calculates package requirements based on use flags. 2. today perforce does not include anything related to split-usr in the packages 3. perforce could add an implicit dependency on baselayout, recorded in the binpkg, so that this kind of problem is avoided. Then you told me that there is nothing in portage that prevents a binpkg which depends on a specific-package with a specific use flag from being installed on a system that lacked that package with that use flag. Perhaps my questions were written in a confusing manner or something? In the future, please tell me if you find my questions to be confusing. Answering a question in a straight forward manner is a signal to the person you're talking to that you fully understand what's being asked. I see that you unsubscribed from this ticket, so i don't expect a reply.
(In reply to Michael Jones from comment #38) > Then you told me that there is nothing in portage that prevents a binpkg > which depends on a specific-package with a specific use flag from being > installed on a system that lacked that package with that use flag. > > Perhaps my questions were written in a confusing manner or something? > > In the future, please tell me if you find my questions to be confusing. > Answering a question in a straight forward manner is a signal to the person > you're talking to that you fully understand what's being asked. > > I see that you unsubscribed from this ticket, so i don't expect a reply. This is a falsehood. Here's what you said: (In reply to Michael Jones from comment #38) > Is there really no flag for portage to force it to not install binpkgs when > the use-flags of packages listed as depedencies have changed? Honestly I was > under the impression that this was the default behavior of portage in the > first place, with a flag to turn it off, not a flag to turn it on. The response was "I'm not aware of any way to make portage do that." That == "make portage ensure that a binpkg can only be installed when its dependencies' USE flags precisely match the USE flags that were used in the binpkg build environment". There are two completely unrelated topics here: - ensure that a binpkg can only be installed when its dependencies are satisfied, including RDEPEND of the form `dep-misc/foobar[use-flag]`, since the original ebuild encoded the information that the status of the "use-flag" USE flag is part of the dependency relationship - ensure that a binpkg which RDEPEND on `dep-misc/foobar` with no opinion about USE flags, but which *happened* to be built on a system where `dep-misc/foobar` was emerged with USE=use-flag, can only be installed on a system where dep-misc/foobar has been emerged with USE=use-flag You requested the latter case. The former case was replied to with the following message: (In reply to Mike Gilbert from comment #37) > (In reply to Michael Jones from comment #36) > > Nothing depends in sys-apps/baselayout[split-usr] or > sys-apps/baselayout[-split-usr]. > > Some things depend on sys-apps/baselayout, but they express no dependency on > the split-usr USE flag. The disconnect here is that (In reply to Michael Jones from comment #38) > Then you told me that there is nothing in portage that prevents a binpkg > which depends on a specific-package with a specific use flag from being > installed on a system that lacked that package with that use flag. In this case, a binpkg is built from an ebuild that depends on "a specific package", but does NOT depend on "a specific package with a specific USE flag". You are effectively requesting that the entire nature of binpkgs be *changed* and modified, such that binpkgs no longer encode the dependency metadata of the installed package, but encode the dependency metadata of the union between the installed package and a bunch of other details that the ebuild did not express an interest in, but an abundance of over-caution has expressed an interest in. In conclusion: - you are being toxic in your accusations of malfeasance, please stop doing that - you want binpkgs to be overly restrictive in ways that would damage their general usability, because *one* package had an unannounced USE-dependency; this doesn't quite feel like the best decision to make IMHO
> In conclusion: > > - you are being toxic in your accusations of malfeasance, please stop doing > that This is a massively inappropriate thing to say to someone. I think you should take a serious think about the behavior that you're exhibiting here of calling people toxic. > - you want binpkgs to be overly restrictive in ways that would damage their > general usability, because *one* package had an unannounced USE-dependency; > this doesn't quite feel like the best decision to make IMHO While I agree with your analysis of what was written from a *very* strict and harsh interpretational perspective, and it's clear that I was not communicating the *exact* technical ideas in the *exact* technical way that would be needed for 100% full mis-understanding-less communication. Re-reading the entire discussion, it's pretty damn obvious to me and the two co-workers who I just asked what I was trying, in-expertly and poorly, to communicate. Despite you're excessively strict interpretation, you clearly didn't understand either. I never asked for a single package to have an unannounced USE-dependency, i asked how we could make *ALL* packages properly understand split-user. I'm not going to respond to this bug again, and I'll refer further public accusations of toxicity to the community relations team for action. Direct character insults are unacceptable.
