| View previous topic :: View next topic |
| Author |
Message |
pjp
Administrator
Joined: 16 Apr 2002
Posts: 20485
|
 Posted: Wed Jul 24, 2019 9:47 pm Post subject: binary updates skipped due to a dependency conflct |
 |
|
I've been building generic binaries in a chroot on an AMD for an Intel client. Other than the process of delivery, I haven't had many issues.
With /usr/portage being the same, /etc/portage being the same, and having synced the built packages from the chroot to the BINHOST, everything appears to be correct. Other updates have completed.
Within the chroot, I didn't have a major problem updating libressl and dependencies.
"--binpkg-respect-use=n" included as I believed there were USE changes and thought that might have been partly the issue.
On the client: | Code: | $ /usr/bin/sudo /usr/bin/emerge -atuvgK --ask-enter-invalid --complete-graph --verbose-conflicts --exclude "getnoo-sources firefox gcc" --binpkg-respect-use=n @world
Password:
These are the packages that would be merged, in reverse order:
Calculating dependencies... done!
Total: 0 packages, Size of downloads: 0 KiB
WARNING: One or more updates/rebuilds have been skipped due to a dependency conflict:
dev-libs/libressl:0
(dev-libs/libressl-2.9.2:0/47::gentoo, binary scheduled for merge) conflicts with
dev-libs/libressl:0/46= required by (net-misc/openssh-7.9_p1-r4:0/0::gentoo, installed)
^^^^^^
dev-libs/libressl:0/46=[abi_x86_64(-)] required by (net-libs/libssh2-1.8.2:0/0::gentoo, installed)
^^^^^^
dev-libs/libressl:0/46=[abi_x86_64(-)] required by (dev-libs/libevent-2.1.8:0/2.1-6::gentoo, installed)
^^^^^^
dev-libs/libressl:0/46=[abi_x86_64(-)] required by (net-misc/curl-7.64.1:0/0::gentoo, installed)
^^^^^^
dev-libs/libressl:0/46= required by (dev-lang/python-2.7.15:2.7/2.7::gentoo, installed)
^^^^^^
dev-libs/libressl:0/46=[abi_x86_64(-)] required by (media-video/ffmpeg-4.1.3:0/56.58.58::gentoo, installed)
^^^^^^
dev-libs/libressl:0/46= required by (net-wireless/crda-3.18-r1:0/0::gentoo, installed)
^^^^^^
dev-libs/libressl:0/46= required by (app-admin/passwordsafe-1.08_beta:0/0::gentoo, installed)
^^^^^^
dev-libs/libressl:0/46= required by (dev-vcs/git-2.21.0:0/0::gentoo, installed)
^^^^^^
dev-libs/libressl:0/46= required by (net-wireless/wpa_supplicant-2.6-r10:0/0::gentoo, installed)
^^^^^^
dev-libs/libressl:0/46= required by (dev-lang/python-3.6.5:3.6/3.6m::gentoo, installed)
^^^^^^
dev-libs/libressl:0/46= required by (dev-lang/rust-bin-1.34.2:stable/stable::gentoo, installed)
^^^^^^
dev-libs/libressl:0/46= required by (x11-base/xorg-server-1.20.3:0/1.20.3::gentoo-local, installed)
^^^^^^
dev-libs/libressl:0/46= required by (dev-python/cryptography-2.6.1:0/0::gentoo, installed)
^^^^^^
Nothing to merge; quitting. |
I had previously masked the libressl update just to delay while ironing out the process of delivering upates to the client. I think the perl updates (output of the below command) made it easier to not delay the upgrade.
| Code: | | $ /usr/bin/sudo /usr/bin/emerge -atuUDNvgK --ask-enter-invalid --complete-graph --verbose-conflicts --exclude "getnoo-sources firefox gcc" --binpkg-respect-use=n --color n @world > emerge.out 2>&1 |
Output:
http://dpaste.com/3MY3BJS
emerge --info (client):
http://dpaste.com/13RB2CJ
emerge --info (chroot):
http://dpaste.com/0CDGFGG
Should I be doing something else for the upgrade command?
Thanks.
_________________
Quis separabit? Quo animo? |
|
| Back to top |
|
 |
eccerr0r
Watchman
Joined: 01 Jul 2004
Posts: 9824
Location: almost Mile High in the USA
|
| Posted: Wed Jul 24, 2019 11:46 pm Post subject: |
|
|
Try --depclean orphans first, then try again perhaps? Just a guess....
_________________
Intel Core i7 2700K/Radeon R7 250/24GB DDR3/256GB SSD
What am I supposed watching? |
|
| Back to top |
|
|
pjp
Administrator
Joined: 16 Apr 2002
Posts: 20485
|
| Posted: Thu Jul 25, 2019 12:33 am Post subject: |
|
|
Good reminder, but didn't seem to make much difference. I removed a couple things and added a couple to world.
Previous: | Code: | | Total: 375 packages (34 upgrades, 341 reinstalls, 375 binaries) |
After depclean: | Code: | | Total: 378 packages (34 upgrades, 344 reinstalls, 378 binaries) |
The main issues with libressl and perl remain.
I'm thinking of trying to downgrade libressl in the chroot, but I'd prefer to not. That seems likely to be messy, especially since I'd still have to upgrade at some point.
_________________
Quis separabit? Quo animo? |
|
| Back to top |
|
|
Ant P.
Watchman
Joined: 18 Apr 2009
Posts: 6920
|
| Posted: Thu Jul 25, 2019 1:04 am Post subject: |
|
|
The problem is your libressl binpkg has a different ABI than what those packages need; installing them will never work.
Rebuilding them --with-bdeps=y might unstick it, or making a binpkg of the exact libressl it wants (2.8.3). If the rest of your packages don't like that version it won't help though. |
|
| Back to top |
|
|
Hu
Administrator
Joined: 06 Mar 2007
Posts: 22686
|
| Posted: Thu Jul 25, 2019 2:11 am Post subject: |
|
|
| Have you tried having the host rebuild (and build binary packages) all the packages that want the older libressl subslot? In the last paste, that is just Python 2.7 and Python 3.6. You want every installed package, and every tbz2 that is scheduled for install, to agree about the subslot of libressl. Those two are holding out for the prior version. I find it a bit odd that the host system isn't complaining too, but maybe you rebuilt those two on the host with FEATURES=-buildpkg, so the host has them updated to the newer ABI, but did not provide updated tbz2 files for the client. |
|
| Back to top |
|
|
Aiken
Apprentice
Joined: 22 Jan 2003
Posts: 239
Location: Toowoomba/Australia
|
| Posted: Thu Jul 25, 2019 2:54 am Post subject: |
|
|
| Hu wrote: | | Have you tried having the host rebuild (and build binary packages) all the packages that want the older libressl subslot? In the last paste, that is just Python 2.7 and Python 3.6. You want every installed package, and every tbz2 that is scheduled for install, to agree about the subslot of libressl. Those two are holding out for the prior version. I find it a bit odd that the host system isn't complaining too, but maybe you rebuilt those two on the host with FEATURES=-buildpkg, so the host has them updated to the newer ABI, but did not provide updated tbz2 files for the client. |
My build server always builds with FEATURES=buildpkg so a new binary package is created every time. What pjp showed reminds me of the problems I have and there are days I get very tempted to blame when an ebuild is changed but there is no corresponding version bump and the package is not rebuilt. End up with some binary packages having out of date dependency information and refusing to install on the client machines.
When I think of it I do
| Code: |
ROOT=/var/tmp/images/delme emerge -pv -K $(qlist -CI)
|
Where ROOT is pointing at an empty directory. Using qlist like that picks up 599 more packages then if I specified -pve world. This shows up problems like in the OP then I start rebuilding the offending packages until the binary packages are consistent again. Have also learnt to not trust preserved libs and occasionally run revdep-rebuild to verify things are still good on that front.
| pjp wrote: |
dev-libs/libressl:0
(dev-libs/libressl-2.9.2:0/47::gentoo, binary scheduled for merge) conflicts with
dev-libs/libressl:0/46= required by (net-misc/openssh-7.9_p1-r4:0/0::gentoo, installed)
^^^^^^
|
I am wondering if you recently went from libressl-2.8.3 to 2.9.2 with openssh and the other affected packages not being rebuilt. Follow that with something like a eclean-pkg -d cleaning all old binary packages and I can imagine leaving you with an openssh binary package looking for an older libressl which does not exist any more. If that is the case this where I would start rebuilding those packages so they are built against the newer libressl.
_________________
Beware the grue. |
|
| Back to top |
|
|
pjp
Administrator
Joined: 16 Apr 2002
Posts: 20485
|
| Posted: Thu Jul 25, 2019 3:18 am Post subject: |
|
|
| Ant P. wrote: | The problem is your libressl binpkg has a different ABI than what those packages need; installing them will never work.
Rebuilding them --with-bdeps=y might unstick it, or making a binpkg of the exact libressl it wants (2.8.3). If the rest of your packages don't like that version it won't help though. |
I noticed that as well, but didn't quite understand the output because it seemed that the ABIs were actually the same. Am I interpretin gthis incorrectly? | Code: | $ emerge -vp =dev-libs/libressl-2.8.3
These are the packages that would be merged, in order:
Calculating dependencies... done!
[ebuild R ] dev-libs/libressl-2.8.3:0/46::gentoo USE="asm -static-libs -test" ABI_X86="(64) -32 (-x32)" 0 KiB |
| Code: | $ emerge -vp =dev-libs/libressl-2.9.2
These are the packages that would be merged, in order:
Calculating dependencies... done!
[ebuild r U ] dev-libs/libressl-2.9.2:0/47::gentoo [2.8.3:0/46::gentoo] USE="asm -static-libs -test" ABI_X86="(64) -32 (-x32)" 0 KiB |
Although, that last command acts as if it would work... that's more confusing. If this were sources, I'd let it continue, but it seems a strange approach for upgrading: | Code: | $ /usr/bin/sudo /usr/bin/emerge -av =dev-libs/libressl-2.9.2
These are the packages that would be merged, in order:
Calculating dependencies... done!
[ebuild r U ] dev-libs/libressl-2.9.2:0/47::gentoo [2.8.3:0/46::gentoo] USE="asm -static-libs -test" ABI_X86="(64) -32 (-x32)" 0 KiB
[ebuild rR ] dev-libs/libevent-2.1.8:0/2.1-6::libressl [2.1.8:0/2.1-6::gentoo] USE="libressl ssl threads -debug -static-libs -test" ABI_X86="(64) -32 (-x32)" 0 KiB
[ebuild rR ] dev-lang/python-3.6.5:3.6/3.6m::gentoo USE="gdbm libressl ncurses readline sqlite ssl (threads) xml -build -examples -hardened -ipv6 -test -tk -wininst" 0 KiB
[ebuild rR ] dev-lang/python-2.7.15:2.7::gentoo USE="gdbm libressl ncurses readline sqlite ssl (threads) (wide-unicode) xml (-berkdb) -bluetooth -build -doc -examples -hardened -ipv6 -tk -wininst" 0 KiB
[ebuild r U ] net-misc/curl-7.65.0::gentoo [7.64.1::gentoo] USE="ssl -adns -brotli -http2 -idn -ipv6 -kerberos -ldap -metalink -rtmp -samba -ssh -static-libs -test -threads" ABI_X86="(64) -32 (-x32)" CURL_SSL="libressl -gnutls -mbedtls -nss -openssl (-winssl)" 0 KiB
[ebuild rR ] www-client/w3m-0.5.3_p20180125::gentoo USE="X libressl nls ssl unicode -fbcon -gdk-pixbuf -gpm -imlib -lynxkeymap -nntp -xface" L10N="-de -ja" 0 KiB
[ebuild rR ] net-misc/openssh-7.9_p1-r4::gentoo USE="X libressl pam pie ssl -X509 -audit -bindist -debug -hpn -kerberos -ldns -libedit -livecd -sctp (-selinux) -static -test" 0 KiB
[ebuild rR ] app-arch/libarchive-3.3.3:0/13::gentoo USE="acl bzip2 e2fsprogs iconv libressl lzma threads xattr zlib -expat -lz4 -lzo -nettle -static-libs -zstd" ABI_X86="(64) -32 (-x32)" 0 KiB
[ebuild r U ] net-misc/wget-1.20.3-r1::gentoo [1.20.3::gentoo] USE="libressl nls pcre ssl zlib -debug -gnutls -idn -ipv6 -ntlm -static -test -uuid" 0 KiB
[ebuild rR ] app-crypt/rhash-1.3.6-r1::gentoo USE="libressl nls ssl -debug -static-libs" ABI_X86="(64) -32 (-x32)" 0 KiB
[ebuild rR ] dev-vcs/git-2.21.0::gentoo USE="blksha1 curl gpg iconv libressl nls pcre pcre-jit python threads webdav -cgi -cvs -doc -emacs -gnome-keyring -highlight -mediawiki -mediawiki-experimental -perl (-ppcsha1) -subversion -test -tk -xinetd" PYTHON_TARGETS="python2_7" 0 KiB
[ebuild rR ] net-libs/libssh2-1.8.2::gentoo USE="libressl zlib -gcrypt -mbedtls" ABI_X86="(64) -32 (-x32)" 0 KiB
[ebuild rR ] dev-lang/rust-bin-1.34.2:stable::gentoo USE="libressl -clippy -doc -rustfmt" ABI_X86="(64) -32 (-x32)" CPU_FLAGS_X86="sse2" 0 KiB
[ebuild rR ] x11-base/xorg-server-1.20.3:0/1.20.3::gentoo-local USE="glamor libressl udev xorg -debug -dmx -doc -ipv6 -kdrive -minimal (-selinux) -static-libs -systemd -unwind -wayland -xcsecurity -xephyr -xnest -xvfb (-suid%*)" 6,060 KiB
[ebuild rR ] dev-python/m2crypto-0.31.0-r2::gentoo USE="libressl" PYTHON_TARGETS="python2_7 python3_6 -python3_5 (-python3_7)" 0 KiB
[ebuild rR ] dev-python/cryptography-2.6.1::gentoo USE="libressl -idna -test" PYTHON_TARGETS="python2_7 python3_6 (-pypy) (-pypy3) -python3_5 (-python3_7)" 0 KiB
[ebuild r U ] net-wireless/crda-3.18-r3::gentoo [3.18-r1::gentoo] USE="libressl -gcrypt" 0 KiB
[ebuild rR ] net-wireless/wpa_supplicant-2.6-r10::gentoo USE="hs2-0 libressl readline ssl -ap -bindist -dbus -eap-sim -eapol_test -fasteap -gnutls -p2p -privsep (-ps3) -qt5 (-selinux) -smartcard -suiteb -tdls -uncommon-eap-types (-wimax) -wps" 0 KiB
[ebuild rR ] media-video/ffmpeg-4.1.3:0/56.58.58::gentoo USE="X alsa bzip2 encode gpl hardcoded-tables iconv libressl mp3 network opengl openssl postproc svg threads truetype vorbis x264 xcb xvid zlib (-altivec) -amr -amrenc (-appkit) -bluray -bs2b -cdio -chromaprint -chromium -codec2 -cpudetection -debug -doc -fdk -flite -fontconfig -frei0r -fribidi -gcrypt -gme -gmp -gnutls -gsm -iec61883 -ieee1394 -jack -jpeg2k -kvazaar -ladspa -libaom -libass -libcaca -libdrm -libilbc -librtmp -libsoxr -libv4l -libxml2 -lv2 -lzma (-mipsdspr1) (-mipsdspr2) (-mipsfpu) (-mmal) -modplug -openal -opencl -openh264 -opus -oss -pic -pulseaudio -rubberband -samba -sdl -snappy -speex -srt -ssh -static-libs -test -theora -twolame -v4l -vaapi -vdpau -vpx -wavpack -webp -x265 -zeromq -zimg -zvbi" ABI_X86="(64) -32 (-x32)" CPU_FLAGS_X86="mmx mmxext sse sse2 -3dnow -3dnowext -aes -avx -avx2 -fma3 -fma4 -sse3 -sse4_1 -sse4_2 -ssse3 -xop" FFTOOLS="aviocat cws2fws ffescape ffeval ffhash fourcc2pixfmt graph2dot ismindex pktdumper qt-faststart sidxindex trasher" VIDEO_CARDS="-nvidia" 0 KiB
[ebuild rR ~] app-admin/passwordsafe-1.08_beta::gentoo USE="libressl xml -minimal -qr -test -xvkbd -yubikey" 0 KiB
Total: 20 packages (4 upgrades, 16 reinstalls), Size of downloads: 6,060 KiB
The following packages are causing rebuilds:
(dev-libs/libressl-2.9.2:0/47::gentoo, ebuild scheduled for merge) causes rebuilds for:
(net-wireless/crda-3.18-r3:0/0::gentoo, ebuild scheduled for merge)
(dev-libs/libevent-2.1.8:0/2.1-6::libressl, ebuild scheduled for merge)
(app-crypt/rhash-1.3.6-r1:0/0::gentoo, ebuild scheduled for merge)
(x11-base/xorg-server-1.20.3:0/1.20.3::gentoo-local, ebuild scheduled for merge)
(app-admin/passwordsafe-1.08_beta:0/0::gentoo, ebuild scheduled for merge)
(net-libs/libssh2-1.8.2:0/0::gentoo, ebuild scheduled for merge)
(dev-vcs/git-2.21.0:0/0::gentoo, ebuild scheduled for merge)
(net-misc/openssh-7.9_p1-r4:0/0::gentoo, ebuild scheduled for merge)
(dev-lang/rust-bin-1.34.2:stable/stable::gentoo, ebuild scheduled for merge)
(media-video/ffmpeg-4.1.3:0/56.58.58::gentoo, ebuild scheduled for merge)
(dev-python/m2crypto-0.31.0-r2:0/0::gentoo, ebuild scheduled for merge)
(www-client/w3m-0.5.3_p20180125:0/0::gentoo, ebuild scheduled for merge)
(app-arch/libarchive-3.3.3:0/13::gentoo, ebuild scheduled for merge)
(net-misc/curl-7.65.0:0/0::gentoo, ebuild scheduled for merge)
(net-misc/wget-1.20.3-r1:0/0::gentoo, ebuild scheduled for merge)
(net-wireless/wpa_supplicant-2.6-r10:0/0::gentoo, ebuild scheduled for merge)
(dev-lang/python-3.6.5:3.6/3.6m::gentoo, ebuild scheduled for merge)
(dev-lang/python-2.7.15:2.7/2.7::gentoo, ebuild scheduled for merge)
(dev-python/cryptography-2.6.1:0/0::gentoo, ebuild scheduled for merge)
Would you like to merge these packages? [Yes/No] |
_________________
Quis separabit? Quo animo? |
|
| Back to top |
|
|
Ant P.
Watchman
Joined: 18 Apr 2009
Posts: 6920
|
| Posted: Thu Jul 25, 2019 3:34 am Post subject: |
|
|
Well, that's confusing...
Do you have a stray libressl-2.9 binpkg existing? Maybe p.masking so it can't try to upgrade to that version would help. At the very least, it should produce a better error. |
|
| Back to top |
|
|
pjp
Administrator
Joined: 16 Apr 2002
Posts: 20485
|
| Posted: Thu Jul 25, 2019 3:51 am Post subject: |
|
|
| Hu wrote: | | Have you tried having the host rebuild (and build binary packages) all the packages that want the older libressl subslot? In the last paste, that is just Python 2.7 and Python 3.6. You want every installed package, and every tbz2 that is scheduled for install, to agree about the subslot of libressl. Those two are holding out for the prior version. I find it a bit odd that the host system isn't complaining too, but maybe you rebuilt those two on the host with FEATURES=-buildpkg, so the host has them updated to the newer ABI, but did not provide updated tbz2 files for the client. |
I believe it rebuilt a lot of stuff, but I haven't done anything specific to force rebuilds. I noticed the two versions of python as well, which is probably my biggest concern. The several important packages rely on libressl makes it a close second. I'll see if I can force a rebuild, though I don't believe I've ever done that intentionally in this manner.
Between the client and host, I believe this shows some differences... particularly on the client, python 3.6.5, wget and crda stand out.
Client: | Code: | $ qlist -SURv libressl
dev-libs/libressl-2.8.3:0::gentoo (abi_x86_64 asm)
$ equery d libressl
* These packages depend on libressl:
app-admin/passwordsafe-1.08_beta (libressl ? dev-libs/libressl:0)
app-admin/sudo-1.8.25_p1-r1 (libressl ? dev-libs/libressl:0)
app-arch/libarchive-3.3.3 (libressl ? dev-libs/libressl:0[abi_x86_32(-)?,abi_x86_64(-)?,abi_x86_x32(-)?,abi_mips_n32(-)?,abi_mips_n64(-)?,abi_mips_o32(-)?,
abi_riscv_lp64d(-)?,abi_riscv_lp64(-)?,abi_s390_32(-)?,abi_s390_64(-)?])
app-crypt/rhash-1.3.6-r1 (libressl ? dev-libs/libressl:0[abi_x86_32(-)?,abi_x86_64(-)?,abi_x86_x32(-)?,abi_mips_n32(-)?,abi_mips_n64(-)?,abi_mips_o32(-)?,
abi_riscv_lp64d(-)?,abi_riscv_lp64(-)?,abi_s390_32(-)?,abi_s390_64(-)?])
dev-lang/python-2.7.15 (libressl ? dev-libs/libressl:0)
dev-lang/python-3.6.5 (libressl ? dev-libs/libressl)
dev-lang/rust-bin-1.34.2 (libressl ? dev-libs/libressl:0)
dev-libs/libevent-2.1.8 (libressl ? dev-libs/libressl[abi_x86_32(-)?,abi_x86_64(-)?,abi_x86_x32(-)?,abi_mips_n32(-)?,abi_mips_n64(-)?,abi_mips_o32(-)?,
abi_riscv_lp64d(-)?,abi_riscv_lp64(-)?,abi_s390_32(-)?,abi_s390_64(-)?])
dev-python/cryptography-2.6.1 (libressl ? dev-libs/libressl:0)
dev-python/m2crypto-0.31.0-r2 (libressl ? dev-libs/libressl:0)
dev-vcs/git-2.21.0 (libressl ? dev-libs/libressl)
media-video/ffmpeg-4.1.3 (libressl ? dev-libs/libressl:0[abi_x86_32(-)?,abi_x86_64(-)?,abi_x86_x32(-)?,abi_mips_n32(-)?,abi_mips_n64(-)?,abi_mips_o32(-)?,
abi_riscv_lp64d(-)?,abi_riscv_lp64(-)?,abi_s390_32(-)?,abi_s390_64(-)?])
net-im/bitlbee-3.5.1 (libressl ? dev-libs/libressl)
net-libs/libssh2-1.8.2 (libressl ? dev-libs/libressl:0[abi_x86_32(-)?,abi_x86_64(-)?,abi_x86_x32(-)?,abi_mips_n32(-)?,abi_mips_n64(-)?,abi_mips_o32(-)?,
abi_riscv_lp64d(-)?,abi_riscv_lp64(-)?,abi_s390_32(-)?,abi_s390_64(-)?])
net-misc/curl-7.64.1 (curl_ssl_libressl ? dev-libs/libressl:0[static-libs?,abi_x86_32(-)?,abi_x86_64(-)?,abi_x86_x32(-)?,abi_mips_n32(-)?,abi_mips_n64(-)?,abi_mips_o32(-)?,
abi_riscv_lp64d(-)?,abi_riscv_lp64(-)?,abi_s390_32(-)?,abi_s390_64(-)?])
net-misc/iputils-20180629 (libressl ? dev-libs/libressl:0)
(libressl ? dev-libs/libressl:0[static-libs(+)])
net-misc/openssh-7.9_p1-r4 (libressl ? dev-libs/libressl:0)
(libressl ? dev-libs/libressl:0[static-libs(+)])
net-misc/wget-1.20.3 (dev-libs/libressl:0/46)
net-wireless/crda-3.18-r1 (dev-libs/libressl:0/46)
net-wireless/wpa_supplicant-2.6-r10 (libressl ? dev-libs/libressl:0)
www-client/w3m-0.5.3_p20180125 (libressl ? dev-libs/libressl:0)
x11-base/xorg-server-1.20.3 (libressl ? dev-libs/libressl:0) |
Host: | Code: | # qlist -SURv libressl
dev-libs/libressl-2.9.2:0::gentoo (abi_x86_64 asm)
# equery d libressl
* These packages depend on libressl:
app-admin/passwordsafe-1.08_beta (libressl ? dev-libs/libressl:0)
app-arch/libarchive-3.3.3 (libressl ? dev-libs/libressl:0[abi_x86_32(-)?,abi_x86_64(-)?,abi_x86_x32(-)?,abi_mips_n32(-)?,abi_mips_n64(-)?,abi_mips_o32(-)?,
abi_riscv_lp64d(-)?,abi_riscv_lp64(-)?,abi_s390_32(-)?,abi_s390_64(-)?])
app-crypt/rhash-1.3.6-r1 (libressl ? dev-libs/libressl:0[abi_x86_32(-)?,abi_x86_64(-)?,abi_x86_x32(-)?,abi_mips_n32(-)?,abi_mips_n64(-)?,abi_mips_o32(-)?,
abi_riscv_lp64d(-)?,abi_riscv_lp64(-)?,abi_s390_32(-)?,abi_s390_64(-)?])
dev-lang/python-2.7.15 (libressl ? dev-libs/libressl:0)
dev-lang/python-3.6.5 (libressl ? dev-libs/libressl:0)
dev-lang/rust-bin-1.34.2 (libressl ? dev-libs/libressl:0)
dev-libs/libevent-2.1.8 (libressl ? dev-libs/libressl[abi_x86_32(-)?,abi_x86_64(-)?,abi_x86_x32(-)?,abi_mips_n32(-)?,abi_mips_n64(-)?,abi_mips_o32(-)?,
abi_riscv_lp64d(-)?,abi_riscv_lp64(-)?,abi_s390_32(-)?,abi_s390_64(-)?])
dev-python/cryptography-2.6.1 (libressl ? dev-libs/libressl:0)
dev-python/m2crypto-0.31.0-r2 (libressl ? dev-libs/libressl:0)
dev-vcs/git-2.21.0 (libressl ? dev-libs/libressl)
media-video/ffmpeg-4.1.3 (libressl ? dev-libs/libressl:0[abi_x86_32(-)?,abi_x86_64(-)?,abi_x86_x32(-)?,abi_mips_n32(-)?,abi_mips_n64(-)?,abi_mips_o32(-)?,
abi_riscv_lp64d(-)?,abi_riscv_lp64(-)?,abi_s390_32(-)?,abi_s390_64(-)?])
net-im/bitlbee-3.5.1 (libressl ? dev-libs/libressl)
net-libs/libssh2-1.8.2 (libressl ? dev-libs/libressl:0[abi_x86_32(-)?,abi_x86_64(-)?,abi_x86_x32(-)?,abi_mips_n32(-)?,abi_mips_n64(-)?,abi_mips_o32(-)?,
abi_riscv_lp64d(-)?,abi_riscv_lp64(-)?,abi_s390_32(-)?,abi_s390_64(-)?])
net-misc/curl-7.65.0 (curl_ssl_libressl ? dev-libs/libressl:0[static-libs?,abi_x86_32(-)?,abi_x86_64(-)?,abi_x86_x32(-)?,abi_mips_n32(-)?,abi_mips_n64(-)?,abi_mips_o32(-)?,
abi_riscv_lp64d(-)?,abi_riscv_lp64(-)?,abi_s390_32(-)?,abi_s390_64(-)?])
net-misc/iputils-20180629 (libressl ? dev-libs/libressl:0)
(libressl ? dev-libs/libressl:0[static-libs(+)])
net-misc/openssh-7.9_p1-r4 (libressl ? dev-libs/libressl:0)
(libressl ? dev-libs/libressl:0[static-libs(+)])
net-misc/wget-1.20.3-r1 (libressl ? dev-libs/libressl:0)
(libressl ? dev-libs/libressl:0[static-libs(+)])
net-wireless/crda-3.18-r3 (libressl ? dev-libs/libressl:0)
net-wireless/wpa_supplicant-2.6-r10 (libressl ? dev-libs/libressl:0)
www-client/w3m-0.5.3_p20180125 (libressl ? dev-libs/libressl:0)
x11-base/xorg-server-1.20.3 (libressl ? dev-libs/libressl:0) |
_________________
Quis separabit? Quo animo? |
|
| Back to top |
|
|
pjp
Administrator
Joined: 16 Apr 2002
Posts: 20485
|
| Posted: Thu Jul 25, 2019 4:07 am Post subject: |
|
|
| Aiken wrote: | | My build server always builds with FEATURES=buildpkg so a new binary package is created every time. What pjp showed reminds me of the problems I have and there are days I get very tempted to blame when an ebuild is changed but there is no corresponding version bump and the package is not rebuilt. End up with some binary packages having out of date dependency information and refusing to install on the client machines. |
I've only recently started using binary packages built in the chroot, so the client almost certainly hasn't done a complete upgrade yet. In fact, until now, I had only been doiog small updates, so it wouldn't surprise me if that's at least not part of the problem. At least I'm hoping this isn't common :).
| Aiken wrote: | When I think of it I do
| Code: |
ROOT=/var/tmp/images/delme emerge -pv -K $(qlist -CI)
|
Where ROOT is pointing at an empty directory. Using qlist like that picks up 599 more packages then if I specified -pve world. This shows up problems like in the OP then I start rebuilding the offending packages until the binary packages are consistent again. Have also learnt to not trust preserved libs and occasionally run revdep-rebuild to verify things are still good on that front. |
I'll have to look into that. I have a coarse understanding of the intent, but not exactly what it means.
| Aiken wrote: | | pjp wrote: |
dev-libs/libressl:0
(dev-libs/libressl-2.9.2:0/47::gentoo, binary scheduled for merge) conflicts with
dev-libs/libressl:0/46= required by (net-misc/openssh-7.9_p1-r4:0/0::gentoo, installed)
^^^^^^
|
I am wondering if you recently went from libressl-2.8.3 to 2.9.2 with openssh and the other affected packages not being rebuilt. Follow that with something like a eclean-pkg -d cleaning all old binary packages and I can imagine leaving you with an openssh binary package looking for an older libressl which does not exist any more. If that is the case this where I would start rebuilding those packages so they are built against the newer libressl. |
On the client, that's the openssh that has not been upgraded. On the host, I believe this shows that it has been upgraded: | Code: | # eix libressl
[?] dev-libs/libressl
Available versions: 2.6.5(0/44){tbz2} 2.8.3(0/46){tbz2} ~2.9.1(0/47) ~2.9.2(0/47){tbz2} {+asm static-libs test ABI_MIPS="n32 n64 o32" ABI_RISCV="lp64 lp64d" ABI_S390="32 64" ABI_X86="32 64 x32"}
Installed versions: 2.9.2(0/47){tbz2}(03:04:54 PM 07/13/2019)(asm -static-libs -test ABI_MIPS="-n32 -n64 -o32" ABI_RISCV="-lp64 -lp64d" ABI_S390="-32 -64" ABI_X86="64 -32 -x32")
Homepage: https://www.libressl.org/
Description: Free version of the SSL/TLS protocol forked from OpenSSL
# cat /var/db/pkg/net-misc/openssh-7.9_p1-r4/RDEPEND
dev-libs/libressl:0/47= >=sys-libs/zlib-1.2.3:0/1= virtual/pam >=sys-auth/pambase-20081028 virtual/shadow x11-apps/xauth |
Client, showing old version info: | Code: | $ eix libressl
[?] dev-libs/libressl
Available versions: 2.6.4(0/44) 2.6.5(0/44) ~2.7.3(0/45) ~2.7.4(0/45) ~2.8.0(0/45) ~2.8.1(0/46) ~2.8.2(0/46) {+asm static-libs test ABI_MIPS="n32 n64 o32" ABI_PPC="32 64" ABI_S390="32 64" ABI_X86="32 64 x32"}
Installed versions: 2.8.3(0/46){tbz2}(04:59:43 PM 05/27/2019)(asm -static-libs -test ABI_MIPS="-n32 -n64 -o32" ABI_RISCV="-lp64 -lp64d" ABI_S390="-32 -64" ABI_X86="64 -32 -x32")
Homepage: https://www.libressl.org/
Description: Free version of the SSL/TLS protocol forked from OpenSSL
$ cat /var/db/pkg/net-misc/openssh-7.9_p1-r4/RDEPEND
dev-libs/libressl:0/46= >=sys-libs/zlib-1.2.3:0/1= virtual/pam >=sys-auth/pambase-20081028 virtual/shadow x11-apps/xauth |
And that's part of what makes this "interesting." It seems as though it is ignoring the updates, although I'm guessing that is because of some conflict still requiring the old stuff.
_________________
Quis separabit? Quo animo?
Last edited by pjp on Thu Jul 25, 2019 4:34 am; edited 1 time in total |
|
| Back to top |
|
|
Hu
Administrator
Joined: 06 Mar 2007
Posts: 22686
|
| Posted: Thu Jul 25, 2019 4:08 am Post subject: |
|
|
| On the host, emerge --ask --verbose dev-lang/python:{2.7,3.6}. After that, retry the --usepkg run on the client. Currently, the client is consistent on the /46 subslot. Thus, if you tell it to rebuild that subslot, everything is fine. If you ask it to build something in subslot /47, then many other packages need to be updated to use the new subslot. Although it may not seem like it, Portage is trying to help by ensuring you don't keep around packages that rely on the removed subslot, which would have varying results between no observable effect or packages failing at runtime. |
|
| Back to top |
|
|
pjp
Administrator
Joined: 16 Apr 2002
Posts: 20485
|
| Posted: Thu Jul 25, 2019 4:21 am Post subject: |
|
|
| Ant P. wrote: | Well, that's confusing...
Do you have a stray libressl-2.9 binpkg existing? Maybe p.masking so it can't try to upgrade to that version would help. At the very least, it should produce a better error. |
Hmm. I don't think so? Am I missing somewhere?
From the binhost: | Code: | libressl-2.6.5.tbz2 07-Apr-2019 01:58 2595801
libressl-2.8.3.tbz2 27-May-2019 23:00 2788801
libressl-2.9.2.tbz2 13-Jul-2019 21:05 2829267 |
Client: | Code: | $ ls -1 /var/portage/packages/dev-libs/libressl-2.*
/var/portage/packages/dev-libs/libressl-2.8.3.tbz2
/var/portage/packages/dev-libs/libressl-2.9.2.tbz2
$ ls -1d /var/db/pkg/dev-libs/libressl-2.*
/var/db/pkg/dev-libs/libressl-2.8.3
$ ls -1 /var/portage/distfiles/libressl-2.*
/var/portage/distfiles/libressl-2.6.5.tar.gz
/var/portage/distfiles/libressl-2.8.3.tar.gz
/var/portage/distfiles/libressl-2.9.2.tar.gz |
Masking everything below the upgrade version, results seem the same: | Code: | $ cat /etc/portage/package.mask/libressl-upgrade-testing
<dev-libs/libressl-2.9.2:0::gentoo
$ /usr/bin/sudo /usr/bin/emerge -atuvgK --ask-enter-invalid --complete-graph --verbose-conflicts --exclude "getnoo-sources firefox gcc" --binpkg-respect-use=n @world
These are the packages that would be merged, in reverse order:
Calculating dependencies... done!
Total: 0 packages, Size of downloads: 0 KiB
WARNING: One or more updates/rebuilds have been skipped due to a dependency conflict:
dev-libs/libressl:0
(dev-libs/libressl-2.9.2:0/47::gentoo, binary scheduled for merge) conflicts with
dev-libs/libressl:0/46= required by (net-wireless/wpa_supplicant-2.6-r10:0/0::gentoo, installed)
^^^^^^
dev-libs/libressl:0/46= required by (dev-lang/python-3.6.5:3.6/3.6m::gentoo, installed)
^^^^^^
dev-libs/libressl:0/46= required by (dev-python/cryptography-2.6.1:0/0::gentoo, installed)
^^^^^^
dev-libs/libressl:0/46=[abi_x86_64(-)] required by (net-misc/curl-7.64.1:0/0::gentoo, installed)
^^^^^^
dev-libs/libressl:0/46= required by (dev-vcs/git-2.21.0:0/0::gentoo, installed)
^^^^^^
dev-libs/libressl:0/46=[abi_x86_64(-)] required by (net-libs/libssh2-1.8.2:0/0::gentoo, installed)
^^^^^^
dev-libs/libressl:0/46=[abi_x86_64(-)] required by (media-video/ffmpeg-4.1.3:0/56.58.58::gentoo, installed)
^^^^^^
dev-libs/libressl:0/46= required by (x11-base/xorg-server-1.20.3:0/1.20.3::gentoo-local, installed)
^^^^^^
dev-libs/libressl:0/46=[abi_x86_64(-)] required by (dev-libs/libevent-2.1.8:0/2.1-6::gentoo, installed)
^^^^^^
dev-libs/libressl:0/46= required by (net-misc/openssh-7.9_p1-r4:0/0::gentoo, installed)
^^^^^^
dev-libs/libressl:0/46= required by (app-admin/passwordsafe-1.08_beta:0/0::gentoo, installed)
^^^^^^
dev-libs/libressl:0/46= required by (dev-lang/python-2.7.15:2.7/2.7::gentoo, installed)
^^^^^^
dev-libs/libressl:0/46= required by (dev-lang/rust-bin-1.34.2:stable/stable::gentoo, installed)
^^^^^^
dev-libs/libressl:0/46= required by (net-wireless/crda-3.18-r1:0/0::gentoo, installed)
^^^^^^
!!! The following update(s) have been skipped due to unsatisfied dependencies
!!! triggered by backtracking:
net-misc/wget:0
!!! The following installed packages are masked:
- dev-libs/libressl-2.8.3::gentoo (masked by: package.mask)
For more information, see the MASKED PACKAGES section in the emerge
man page or refer to the Gentoo Handbook.
Nothing to merge; quitting. |
_________________
Quis separabit? Quo animo? |
|
| Back to top |
|
|
pjp
Administrator
Joined: 16 Apr 2002
Posts: 20485
|
| Posted: Thu Jul 25, 2019 4:26 am Post subject: |
|
|
| Hu wrote: | | On the host, emerge --ask --verbose dev-lang/python:{2.7,3.6}. After that, retry the --usepkg run on the client. Currently, the client is consistent on the /46 subslot. Thus, if you tell it to rebuild that subslot, everything is fine. If you ask it to build something in subslot /47, then many other packages need to be updated to use the new subslot. Although it may not seem like it, Portage is trying to help by ensuring you don't keep around packages that rely on the removed subslot, which would have varying results between no observable effect or packages failing at runtime. |
Is the intent for the host to force rebuilding dependences and then upgrade those changes to the client? I don't think the host has anything to do? | Code: | # emerge --ask --verbose dev-lang/python:{2.7,3.6}
* IMPORTANT: 19 news items need reading for repository 'gentoo'.
* Use eselect news read to view new items.
These are the packages that would be merged, in order:
Calculating dependencies... done!
[ebuild R ] dev-lang/python-2.7.15:2.7::gentoo USE="gdbm libressl ncurses readline sqlite ssl (threads) (wide-unicode) xml (-berkdb) -bluetooth -build -doc -examples -hardened -ipv6 -tk -wininst" 0 KiB
[ebuild R ] dev-lang/python-3.6.5:3.6/3.6m::gentoo USE="gdbm libressl ncurses readline sqlite ssl (threads) xml -build -examples -hardened -ipv6 -test -tk -wininst" 0 KiB
Total: 2 packages (2 reinstalls), Size of downloads: 0 KiB
Would you like to merge these packages? [Yes/No] |
EDIT: | Code: | # cat /var/db/pkg/dev-lang/python-2.7.15/RDEPEND
app-arch/bzip2:0/1= >=sys-libs/zlib-1.1.3:0/1= virtual/libffi:0/0= virtual/libintl sys-libs/gdbm:0/1.13=[berkdb] >=sys-libs/ncurses-5.2:0/6= >=sys-libs/readline-4.1:0/7= >=dev-db/sqlite-3.3.8:3/3= dev-libs/libressl:0/47= >=dev-libs/expat-2.1 !!<sys-apps/portage-2.1.9 app-misc/mime-types
# cat /var/db/pkg/dev-lang/python-3.6.5/RDEPEND
app-arch/bzip2:0/1= app-arch/xz-utils:0/0= >=sys-libs/zlib-1.1.3:0/1= virtual/libffi:0/0= virtual/libintl sys-libs/gdbm:0/1.13=[berkdb] >=sys-libs/ncurses-5.2:0/6= >=sys-libs/readline-4.1:0/7= >=dev-db/sqlite-3.3.8:3/3= dev-libs/libressl:0/47= >=dev-libs/expat-2.1:0/0= !!<sys-apps/sandbox-2.6-r1 app-misc/mime-types |
_________________
Quis separabit? Quo animo? |
|
| Back to top |
|
|
Aiken
Apprentice
Joined: 22 Jan 2003
Posts: 239
Location: Toowoomba/Australia
|
| Posted: Thu Jul 25, 2019 5:35 am Post subject: |
|
|
| pjp wrote: |
I'll have to look into that. I have a coarse understanding of the intent, but not exactly what it means.
|
| Code: |
ROOT=/var/tmp/images/delme emerge -pv -K $(qlist -CI)
|
Using qlist -CI is one way to get a list of installed packages. The ROOT= changes it from the default of / and in my case /var/tmp/images/delme is a sacrificial empty directory. All it does is go through the motions of seeing what will happen when trying to install all binary packages in that directory. If every installed package has a corresponding binary package and if the binary packages are consistent it works otherwise get the error messages that I think of when I read your post.
Something else that has given me some frustrating moments is the client machine having a copy of old binary packages and is trying to use them. That is frustrating when it happens. Waste a lot of time on the build server chasing a problem when a simple clearing of any cached binary packages on the client would have been enough. I generally run with /tmp on tmpfs. On the machines that are shutdown over night I have PKGDIR pointing to a directory under /tmp and with updates no more than once a day there are no stale binary packages cached on those client machines.
As well as making sure the client machines do not have old cached binary packages on the build server I also do eclean-pkg -d which will delete every binary packages that does not correspond to a currently installed package. I use -d with both eclean-pkg and eclean-dist so I only have the minimum files needed for a full reinstall of what is installed at the point in time.
At the moment continuing to pick on openssh I am curious what would happen if on the build server you forced a rebuild of openssh to generate a new binary package.
_________________
Beware the grue. |
|
| Back to top |
|
|
pjp
Administrator
Joined: 16 Apr 2002
Posts: 20485
|
| Posted: Thu Jul 25, 2019 11:52 pm Post subject: |
|
|
Thanks. I was mainly wanting to think through and make sure disk space wasn't going to be an issue.
So, the ROOT/qlist didn't solve the issue but helped idnetify another issue. Namely an obvious error that wasn't registering with me... that the 403 errors when fetching packages meant something :). I guess that's not so critical when fetching sources which is why I probably didn't think much about it. That's fixed, and I'll have to add a permissions check to the process.
The ROOT/qlist method apparently aborts with each missing package. So after a number of manual downloads, I just sent the output of the qlist command to a fetchonly emerge. That downloaded quite a few packages. But I still had to manually go throuh it for a few more packages.
So with all that said, the last run of the command still points to the same or very similar errors. Skipping the list of packages: | Code: | Total: 553 packages (553 new, 553 binaries), Size of downloads: 0 KiB
!!! Multiple package instances within a single package slot have been pulled
!!! into the dependency graph, resulting in a slot conflict:
dev-libs/libressl:0 for /var/tmp/portage/temp/
(dev-libs/libressl-2.9.2:0/47::gentoo, binary scheduled for merge to '/var/tmp/portage/temp/') pulled in by
dev-libs/libressl:0/47=[abi_x86_64(-)] required by (app-arch/libarchive-3.3.3:0/13::gentoo, binary scheduled for merge to '/var/tmp/portage/temp/')
^^^^^^
(and 33 more with the same problem)
(dev-libs/libressl-2.6.5:0/44::gentoo, binary scheduled for merge to '/var/tmp/portage/temp/') pulled in by
dev-libs/libressl:0/44= required by (dev-lang/python-2.7.15:2.7/2.7::gentoo, binary scheduled for merge to '/var/tmp/portage/temp/')
^^^^^^
(and 1 more with the same problem)
(dev-libs/libressl-2.8.3:0/46::gentoo, binary scheduled for merge to '/var/tmp/portage/temp/') pulled in by
dev-libs/libressl:0/46= required by (dev-lang/python-3.6.5:3.6/3.6m::gentoo, binary scheduled for merge to '/var/tmp/portage/temp/')
^^^^^^
(and 1 more with the same problem)
dev-lang/perl:0 for /var/tmp/portage/temp/
(dev-lang/perl-5.28.2-r1:0/5.28::gentoo, binary scheduled for merge to '/var/tmp/portage/temp/') pulled in by
=dev-lang/perl-5.28* required by (virtual/perl-Parse-CPAN-Meta-2.150.10-r2:0/0::gentoo, binary scheduled for merge to '/var/tmp/portage/temp/')
^ ^^^^^
dev-lang/perl:0/5.28= required by (virtual/perl-Exporter-5.730.0-r1:0/0::gentoo, binary scheduled for merge to '/var/tmp/portage/temp/')
^^^^^^^^
(and 54 more with the same problems)
(dev-lang/perl-5.26.2:0/5.26::gentoo, binary scheduled for merge to '/var/tmp/portage/temp/') pulled in by
dev-lang/perl:0/5.26= required by (dev-perl/Module-Build-0.422.400:0/0::gentoo, binary scheduled for merge to '/var/tmp/portage/temp/')
^^^^^^^^
(and 12 more with the same problem) |
I had previously run eclean distfiles/packages, but I'll recheck to see what it lists. And I'll give your openssh suggestion a try too.
_________________
Quis separabit? Quo animo? |
|
| Back to top |
|
|
Aiken
Apprentice
Joined: 22 Jan 2003
Posts: 239
Location: Toowoomba/Australia
|
| Posted: Thu Jul 25, 2019 11:54 pm Post subject: |
|
|
I do the that command on the build server to make sure the binary packages are consistent before a client machine tries using them.
_________________
Beware the grue. |
|
| Back to top |
|
|
Hu
Administrator
Joined: 06 Mar 2007
Posts: 22686
|
| Posted: Fri Jul 26, 2019 2:01 am Post subject: |
|
|
| pjp wrote: | | Code: | | $ /usr/bin/sudo /usr/bin/emerge -atuvgK --ask-enter-invalid --complete-graph --verbose-conflicts --exclude "getnoo-sources firefox gcc" --binpkg-respect-use=n @world |
|
As an aside, you misspelled gentoo-sources, so the --exclude is not acting on it. | pjp wrote: | | Code: | dev-libs/libressl:0
(dev-libs/libressl-2.9.2:0/47::gentoo, binary scheduled for merge) conflicts with
dev-libs/libressl:0/46= required by (net-wireless/wpa_supplicant-2.6-r10:0/0::gentoo, installed)
^^^^^^ |
|
(With other conflicts snipped ...)
I see two possible explanations for these conflicts. Possibility #1 is that Portage has no access to a binary package of net-wireless/wpa_supplicant (and the others listed) that RDEPENDs on subslot 47. Possibility #2 is that the particular Portage invocation is preventing it from trying to reinstall net-wireless/wpa_supplicant, so the availability of a binary package with the correct subslot is not considered or helpful. Please try emerge --ask --verbose --getbinpkgonly --verbose-conflicts --oneshot @world net-wireless/wpa_supplicant (and others...). I hope that will force Portage to try to install a same-version, but more recently recompiled and therefore subslot compatible, version of the listed packages. You might also check that the binary packages the client uses have the correct subslot in their RDEPEND data. | pjp wrote: | | Is the intent for the host to force rebuilding dependences and then upgrade those changes to the client? |
Yes. | pjp wrote: | I don't think the host has anything to do? | Code: | # emerge --ask --verbose dev-lang/python:{2.7,3.6}
[ebuild R ] dev-lang/python-2.7.15:2.7::gentoo USE="gdbm libressl ncurses readline sqlite ssl (threads) (wide-unicode) xml (-berkdb) -bluetooth -build -doc -examples -hardened -ipv6 -tk -wininst" 0 KiB
[ebuild R ] dev-lang/python-3.6.5:3.6/3.6m::gentoo USE="gdbm libressl ncurses readline sqlite ssl (threads) xml -build -examples -hardened -ipv6 -test -tk -wininst" 0 KiB |
|
This output does not show what subslot the packages depend on, so I cannot determine from this whether there is anything to do.
| pjp wrote: | EDIT: | Code: | # cat /var/db/pkg/dev-lang/python-2.7.15/RDEPEND
app-arch/bzip2:0/1= >=sys-libs/zlib-1.1.3:0/1= virtual/libffi:0/0= virtual/libintl sys-libs/gdbm:0/1.13=[berkdb] >=sys-libs/ncurses-5.2:0/6= >=sys-libs/readline-4.1:0/7= >=dev-db/sqlite-3.3.8:3/3= dev-libs/libressl:0/47= >=dev-libs/expat-2.1 !!<sys-apps/portage-2.1.9 app-misc/mime-types
# cat /var/db/pkg/dev-lang/python-3.6.5/RDEPEND
app-arch/bzip2:0/1= app-arch/xz-utils:0/0= >=sys-libs/zlib-1.1.3:0/1= virtual/libffi:0/0= virtual/libintl sys-libs/gdbm:0/1.13=[berkdb] >=sys-libs/ncurses-5.2:0/6= >=sys-libs/readline-4.1:0/7= >=dev-db/sqlite-3.3.8:3/3= dev-libs/libressl:0/47= >=dev-libs/expat-2.1:0/0= !!<sys-apps/sandbox-2.6-r1 app-misc/mime-types |
|
This looks good, but is unfortunately not quite definitive. It confirms that the instances installed on the host have the good subslot. It doesn't tell us whether the binary packages offered to the client have the good subslot. They should, if they were built by FEATURES=buildpkg during the emerge that produced the packages you showed here. However, they might not if the host built for subslot /46 with FEATURES=buildpkg enabled, then disabled FEATURES=buildpkg, then rebuilt for subslot /47. | pjp wrote: | | Code: | (dev-libs/libressl-2.6.5:0/44::gentoo, binary scheduled for merge to '/var/tmp/portage/temp/') pulled in by
dev-libs/libressl:0/44= required by (dev-lang/python-2.7.15:2.7/2.7::gentoo, binary scheduled for merge to '/var/tmp/portage/temp/')
^^^^^^
(and 1 more with the same problem)
(dev-libs/libressl-2.8.3:0/46::gentoo, binary scheduled for merge to '/var/tmp/portage/temp/') pulled in by
dev-libs/libressl:0/46= required by (dev-lang/python-3.6.5:3.6/3.6m::gentoo, binary scheduled for merge to '/var/tmp/portage/temp/')
^^^^^^
(and 1 more with the same problem) |
|
This is interesting. How is the host using the correct subslot, yet offering to the client packages that have two different incorrect subslots? Your post mentioned permissions errors. Could the client be using outdated copies of these binpkgs, where the host has already fixed them but the client uses the older ones anyway? |
|
| Back to top |
|
|
pjp
Administrator
Joined: 16 Apr 2002
Posts: 20485
|
| Posted: Fri Jul 26, 2019 3:32 am Post subject: |
|
|
| Aiken wrote: | | I do the that command on the build server to make sure the binary packages are consistent before a client machine tries using them. |
OK, I'll check that too. I did try rebuilding openssh, but no apparent change. I'll try again after running the checs on the host.
_________________
Quis separabit? Quo animo? |
|
| Back to top |
|
|
pjp
Administrator
Joined: 16 Apr 2002
Posts: 20485
|
| Posted: Fri Jul 26, 2019 4:08 am Post subject: |
|
|
| Hu wrote: | | As an aside, you misspelled gentoo-sources, so the --exclude is not acting on it. |
Thanks.
| Hu wrote: | | I see two possible explanations for these conflicts. Possibility #1 is that Portage has no access to a binary package of net-wireless/wpa_supplicant (and the others listed) that RDEPENDs on subslot 47. Possibility #2 is that the particular Portage invocation is preventing it from trying to reinstall net-wireless/wpa_supplicant, so the availability of a binary package with the correct subslot is not considered or helpful. Please try emerge --ask --verbose --getbinpkgonly --verbose-conflicts --oneshot @world net-wireless/wpa_supplicant (and others...). I hope that will force Portage to try to install a same-version, but more recently recompiled and therefore subslot compatible, version of the listed packages. You might also check that the binary packages the client uses have the correct subslot in their RDEPEND data. |
As I was running the requested oneshot command, I thought I forgot to remove @world, so I did. I ran them per package ('--oneshot <package>'). Notably, I thought, neither version of python had any conflicts, and libssh2 was going to downgrade. All of the output was appended to a single file.
Output: http://dpaste.com/0YAJKEV
And the python parts reminded me that you previously mentioned something about those, so I'll re-read to see if I was supposed to do something.
When I realized that wasn't what you asked for, I reran this, not certain of how you meant "and others..." to be handled: | Code: | | /usr/bin/sudo /usr/bin/emerge --ask --verbose --getbinpkgonly --verbose-conflicts --oneshot @world net-wireless/wpa_supplicant dev-lang/python dev-python/cryptography net-misc/curl dev-vcs/git net-libs/libssh2 media-video/ffmpeg x11-base/xorg-server dev-libs/libevent net-misc/openssh app-admin/passwordsafe dev-lang/rust-bin net-wireless/crda > emerge-world.out 2>&1 |
Output: http://dpaste.com/22B9W5D
| Hu wrote: | | It confirms that the instances installed on the host have the good subslot. It doesn't tell us whether the binary packages offered to the client have the good subslot. They should, if they were built by FEATURES=buildpkg during the emerge that produced the packages you showed here. However, they might not if the host built for subslot /46 with FEATURES=buildpkg enabled, then disabled FEATURES=buildpkg, then rebuilt for subslot /47. |
I'll check the binaries. I'm as certain as possible without change control that I did not disable buildpkg. So 46/enabled, 47/disabled highly improbable. Maybe (but I doubt) 46/disabled, 47/enabled, depending on when I inserted FEATURES into make.conf.
| Hu wrote: | | This is interesting. How is the host using the correct subslot, yet offering to the client packages that have two different incorrect subslots? Your post mentioned permissions errors. Could the client be using outdated copies of these binpkgs, where the host has already fixed them but the client uses the older ones anyway? |
I don't grasp how binaries are evaluated. At least one descriptoin mentions that everything must be available. That's fairly vague. If portage can't tell me what is or isn't there, how am I supposed to evaluate that?
That said, from my original "how do I do this in a chroot" thread, my intent was to continue running native compiled packages, and then perforum upgrades from generic packages built in the chroot. So the client almost certainly contains some native built binaries. Is there a way to determine which are native and which are generic?
_________________
Quis separabit? Quo animo? |
|
| Back to top |
|
|
Aiken
Apprentice
Joined: 22 Jan 2003
Posts: 239
Location: Toowoomba/Australia
|
| Posted: Fri Jul 26, 2019 4:33 am Post subject: |
|
|
| pjp wrote: |
That said, from my original "how do I do this in a chroot" thread, my intent was to continue running native compiled packages, and then perforum upgrades from generic packages built in the chroot. So the client almost certainly contains some native built binaries. Is there a way to determine which are native and which are generic? |
I am reading that as the client machines build or have in the past some/all of their own packages. That is a bit different compared to what i do. All my client machines use -K with emerge so if a binary package on the build server does not exist it can not be installed. None of them will build their own packages.
Long enough ago I can not remember if it was because of problems or as simple I got fed up with building the bigger packages many times when with a build server they are built once.
When the client machines were still allowed to build their own packages if a binary package did not exist on the build server there were some issues if the various /etc/portage got out of sync with each other. If use flags or keywords/mask/unmask were different may cause problems. Now part of my update procedure on each client machine is to rsync /etc/portage from the build server so that directory is identical on all of them.
_________________
Beware the grue. |
|
| Back to top |
|
|
pjp
Administrator
Joined: 16 Apr 2002
Posts: 20485
|
| Posted: Fri Jul 26, 2019 4:34 am Post subject: |
|
|
From the client, it appears your suspicions were correct? | Code: | $ /usr/bin/sudo /bin/cp -a /var/portage/packages/dev-lang/python-{2,3}* .
$ qtbz2 -s python-2.7.15.tbz2
$ qxpak -x python-2.7.15.xpak RDEPEND
$ cat RDEPEND
app-arch/bzip2:0/1= >=sys-libs/zlib-1.1.3:0/1= virtual/libffi:0/0= virtual/libintl sys-libs/gdbm:0/1.13=[berkdb] >=sys-libs/ncurses-5.2:0/6= >=sys-libs/readline-4.1:0/7= dev-libs/libressl:0/44= >=dev-libs/expat-2.1 !!<sys-apps/portage-2.1.9 app-misc/mime-types |
| Code: | $ qtbz2 -s python-3.6.5.tbz2
$ qxpak -x python-3.6.5.xpak RDEPEND
$ cat RDEPEND
app-arch/bzip2:0/1= app-arch/xz-utils:0/0= >=sys-libs/zlib-1.1.3:0/1= virtual/libffi:0/0= virtual/libintl sys-libs/gdbm:0/1.13=[berkdb] >=sys-libs/ncurses-5.2:0/6= >=sys-libs/readline-4.1:0/7= >=dev-db/sqlite-3.3.8:3/3= dev-libs/libressl:0/46= >=dev-libs/expat-2.1:0/0= !!<sys-apps/sandbox-2.6-r1 app-misc/mime-types |
Checksums, on the client: | Code: | $ sha1sum python-{2,3}*.tbz2
db7a208fcd30eae43ae8c61a2f9b82e74c445239 python-2.7.15.tbz2
c66a459d7e333ab7cca536d979b3befc9689e843 python-3.6.5.tbz2 |
On the http/binhost: | Code: | [0] sha1sum packages/dev-lang/python-{2,3}*
0f2fdbd49d3c5677f1beed56fd65b280a4ac30bb packages/dev-lang/python-2.7.15.tbz2
c66a459d7e333ab7cca536d979b3befc9689e843 packages/dev-lang/python-3.6.5.tbz2 |
And the chroot: | Code: | # sha1sum /var/portage/packages/dev-lang/python-{2,3}*
0f2fdbd49d3c5677f1beed56fd65b280a4ac30bb /var/portage/packages/dev-lang/python-2.7.15.tbz2
c66a459d7e333ab7cca536d979b3befc9689e843 /var/portage/packages/dev-lang/python-3.6.5.tbz2 |
Which confuses me greatly. Given what is supposedly installed in the chroot. Rechecking the chroot /var/db/pkg entries: | Code: | # cat /var/db/pkg/dev-lang/python-2.7.15/RDEPEND
app-arch/bzip2:0/1= >=sys-libs/zlib-1.1.3:0/1= virtual/libffi:0/0= virtual/libintl sys-libs/gdbm:0/1.13=[berkdb] >=sys-libs/ncurses-5.2:0/6= >=sys-libs/readline-4.1:0/7= >=dev-db/sqlite-3.3.8:3/3= dev-libs/libressl:0/47= >=dev-libs/expat-2.1 !!<sys-apps/portage-2.1.9 app-misc/mime-types
# cat /var/db/pkg/dev-lang/python-3.6.5/RDEPEND
app-arch/bzip2:0/1= app-arch/xz-utils:0/0= >=sys-libs/zlib-1.1.3:0/1= virtual/libffi:0/0= virtual/libintl sys-libs/gdbm:0/1.13=[berkdb] >=sys-libs/ncurses-5.2:0/6= >=sys-libs/readline-4.1:0/7= >=dev-db/sqlite-3.3.8:3/3= dev-libs/libressl:0/47= >=dev-libs/expat-2.1:0/0= !!<sys-apps/sandbox-2.6-r1 app-misc/mime-types |
_________________
Quis separabit? Quo animo? |
|
| Back to top |
|
|
pjp
Administrator
Joined: 16 Apr 2002
Posts: 20485
|
| Posted: Fri Jul 26, 2019 4:49 am Post subject: |
|
|
| Aiken wrote: | | I am reading that as the client machines build or have in the past some/all of their own packages. That is a bit different compared to what i do. All my client machines use -K with emerge so if a binary package on the build server does not exist it can not be installed. None of them will build their own packages. |
That's correct. The client being a laptop, I've decided it isn't practical for my use to build on it. Either I'll be able to "create a binary distro" for it, or I'll have move to something other than Gentoo. In the long run, my goal is to only (or mostly) ever install binaries built in this fashion, on anything. That may be "server", "desktop", "vm", etc. Well, that's the goal. The original thread, although I don't think it contains any revelations: Build and run mixed native and generic binaries?
| Aiken wrote: | | When the client machines were still allowed to build their own packages if a binary package did not exist on the build server there were some issues if the various /etc/portage got out of sync with each other. If use flags or keywords/mask/unmask were different may cause problems. Now part of my update procedure on each client machine is to rsync /etc/portage from the build server so that directory is identical on all of them. |
Yes, the /usr/portage, /etc/portage and now apparently the binaries are quite the nuissance. /usr/portage isn't too bad, I use squashfs mounts, so I just have to remember to copy (and remount!) it. /etc/portage is an ugly one. I don't like using rsync (as may be evident by my binhost seemingly not updating as I expect). So my temporary solution for /etc/portage is /etc/portage being a link to /etc/portage.d/<current portage directory>. That allows me to make sure what was there is preserved and easily accessible with minimal fuss (no juggling tar files or the like). Once everything is ironed out, I was planning to test using git for maintaining /etc/portage along with an "etc-portage" ebuild?
_________________
Quis separabit? Quo animo? |
|
| Back to top |
|
|
pjp
Administrator
Joined: 16 Apr 2002
Posts: 20485
|
| Posted: Fri Jul 26, 2019 2:58 pm Post subject: |
|
|
| pjp wrote: | | Aiken wrote: | | I do the that command on the build server to make sure the binary packages are consistent before a client machine tries using them. |
OK, I'll check that too. I did try rebuilding openssh, but no apparent change. I'll try again after running the checs on the host. |
I guess the chroot is not consistent, although no upgrade command I've tried suggested there is anything to do. Output below. Meanwhile, currently running the python reinstall Hu recommended (emerge --ask --verbose dev-lang/python:{2.7,3.6}). Will update with testing after that is complete.
EDIT 2: Never mind. It hasn't changed anything on the client with binary updates. Both python versions are still requiring the older slot 46 libressl. I similarly rebuilt openssh, same results. But if I run the following on the client, perl is the only issue: emerge -atuUDNvgK --ask-enter-invalid --complete-graph --verbose-conflicts @world. I'm thinking downgrading perl from 5.28 to 5.26 in the chroot may be necessary.
EDIT: Didn't take long. That seems to have resolved the python issue in the chroot, but did not resolve the perl issue. Output of the ROOT/qlist command in the chroot after reinstalling both python versions and perl 5.28: http://dpaste.com/02T44K9
Removed previous, outdated output.
BINHOST sees the updates: | Code: | sending incremental file list
packages/
packages/Packages
packages/dev-lang/
packages/dev-lang/perl-5.28.2-r1.tbz2
packages/dev-lang/python-2.7.15.tbz2
packages/dev-lang/python-3.6.5.tbz2
sent 33.88K bytes received 694 bytes 69.14K bytes/sec
total size is 2.84G speedup is 82,239.44 (DRY RUN) |
_________________
Quis separabit? Quo animo? |
|
| Back to top |
|
|
pjp
Administrator
Joined: 16 Apr 2002
Posts: 20485
|
| Posted: Sat Jul 27, 2019 12:50 am Post subject: |
|
|
After several attempts that didn't work, the solution seems to have been rebuilding anything being complained about regarding perl 0/5.26.
I was hoping to avoid major wholesale upgrades, but no such luck... | Code: | emerge -avuUND -gK --verbose-conflicts @world
Total: 377 packages (35 upgrades, 342 reinstalls, 377 binaries) |
*fingers crossed*
_________________
Quis separabit? Quo animo? |
|
| Back to top |
|
|
Hu
Administrator
Joined: 06 Mar 2007
Posts: 22686
|
| Posted: Sat Jul 27, 2019 1:03 am Post subject: |
|
|
| So the binhost and the chroot have the same files, and they are the "good" files for this discussion (newer subslot). The client has different files, which appear to be outdated. What if you explicitly remove the Python tbz2 files on the client and refresh them from the binhost? Does that get them to the same checksum? If so, does reinstalling them then get the right subslot in /var/db/pkg? |
|
| Back to top |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
Portage & Programming
