234907 2008-08-16 11:25 0000 Unmerging sys-libs/com_err in order to emerge =sys-fs/e2fsprogs(-libs)-1.41, breaks mit-krb5, which breaks openssl when built with USE="kerberos", breaking every package depending on openssl 2009-09-13 21:43:25 0000 1 1 1 Unclassified Gentoo Linux Core system unspecified x86 Linux RESOLVED WORKSFORME P2 normal --- 234886 249663 66 1 reini@crimer.de base-system@gentoo.org ari@goron.de billie@gentoo.org bug@therealms.com bugzilla@bennee.com c4blem0nkey@gmail.com caster@gentoo.org cedric.godin@skynet.be chad.simmons@member.fsf.org che@chrekh.se ciklop1979@gmail.com daniel.hornung@gmx.de dkarasik@gmail.com ellingsw+20942@gmail.com enyawix@yahoo.com esycat@gmail.com felix@crowfix.com ford_prefect@gentoo.org fuzzyray@gentoo.org gasper.azman@gmail.com genehack@genehack.org gentoo.bugs@pointb.co.uk gentoo@matt.mchenryfamily.org gentoo@scribeofthenile.com gentoobugs@ncode.nl graham@gmurray.org.uk harrisl@lhjonline.com ivor.prebeg@fer.hr j.romildo@gmail.com jacobgodserv@gmail.com James@superbug.demon.co.uk jer@gentoo.org kentfredric@gmail.com kerberos@gentoo.org kevin.bowling@kev009.com k_javid@hotmail.com le.retired@gmail.com linux@evolone.org m.debruijne@matrict.nl marten@xtal.rwth-aachen.de mjevans1983@gmail.com mluisser@gmail.com nlshep@gmail.com olav@sandstaa.net oskar.ellstrom@gmail.com pchrist@gentoo.org pqGungnir@gmx.de rlippmann@hotmail.com rmay31@gmail.com rodrigo@fabricadeideias.com simon+bugzilla@matthews-family.org.uk stonie.cooper@planetarydata.com th982a@gmail.com tom@ritter.vg transacid@centerim.org ville@oikarinen.org vladimirkotulskiy@gmail.com voyageur@gentoo.org x86@gentoo.org xmit@gmx.de zmedico@gentoo.org zzam@gentoo.org reini@crimer.de 2008-08-16 11:25:27 0000 It is not possible to solve this block. Reproducible: Always Steps to Reproduce: 1.emerge -avu e2fsprogs 2. 3. Actual Results: Calculating dependencies... done! [ebuild N ] sys-libs/e2fsprogs-libs-1.41.0 USE="nls" 476 kB [ebuild U ] sys-fs/e2fsprogs-1.41.0 [1.40.11] USE="nls -static" 4,161 kB [blocks B ] <sys-fs/e2fsprogs-1.41 (is blocking sys-libs/e2fsprogs-libs-1.41.0) [blocks B ] sys-libs/ss (is blocking sys-libs/e2fsprogs-libs-1.41.0) [blocks B ] sys-libs/com_err (is blocking sys-libs/e2fsprogs-libs-1.41.0) Expected Results: Probably that sys-libs/e2fsprogs-libs-1.41.0 should replace sys-libs/ss and sys-libs/com_err? emerge --info Portage 2.2_rc8 (default/linux/x86/2008.0/desktop, gcc-4.3.1, glibc-2.8_p20080602-r0, 2.6.26-gentoo-r1 i686) ================================================================= System uname: Linux-2.6.26-gentoo-r1-i686-Intel-R-_Core-TM-2_CPU_T7600_@_2.33GHz-with-glibc2.0 Timestamp of tree: Sat, 16 Aug 2008 09:45:01 +0000 ccache version 2.4 [enabled] app-shells/bash: 3.2_p39 dev-java/java-config: 1.3.7, 2.1.6-r1 dev-lang/python: 2.5.2-r7 dev-util/ccache: 2.4-r7 sys-apps/baselayout: 2.0.0 sys-apps/openrc: 0.2.5 sys-apps/sandbox: 1.2.18.1-r3 sys-devel/autoconf: 2.13, 2.62-r1 sys-devel/automake: 1.5, 1.7.9-r1, 1.8.5-r3, 1.9.6-r2, 1.10.1-r1 sys-devel/binutils: 2.18-r3 sys-devel/gcc-config: 1.4.0-r4 sys-devel/libtool: 2.2.4 virtual/os-headers: 2.6.25-r4 ACCEPT_KEYWORDS="x86 ~x86" CBUILD="i686-pc-linux-gnu" CFLAGS="-O2 -march=core2 -pipe -fomit-frame-pointer" CHOST="i686-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/kde/3.5/env /usr/kde/3.5/share/config /usr/kde/3.5/shutdown /usr/share/config" CONFIG_PROTECT_MASK="/etc/ca-certificates.conf /etc/env.d /etc/env.d/java/ /etc/eselect/postgresql /etc/fonts/fonts.conf /etc/gconf /etc/gentoo-release /etc/php/apache2-php5/ext-active/ /etc/php/cgi-php5/ext-active/ /etc/php/cli-php5/ext-active/ /etc/revdep-rebuild /etc/splash /etc/terminfo /etc/texmf/web2c /etc/udev/rules.d" CXXFLAGS="-O2 -march=core2 -pipe -fomit-frame-pointer" DISTDIR="/usr/portage/distfiles" FEATURES="ccache distlocks parallel-fetch preserve-libs sandbox sfperms strict unmerge-orphans userfetch" GENTOO_MIRRORS="http://linux.rz.ruhr-uni-bochum.de/download/gentoo-mirror/ http://gentoo.mirror.pw.edu.pl/ http://ftp.uni-erlangen.de/pub/mirrors/gentoo" LANG="de_DE.UTF-8" LC_ALL="de_DE.UTF-8" LDFLAGS="-Wl,-O1" LINGUAS="de" MAKEOPTS="-j3" PKGDIR="/usr/portage/packages" PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --stats --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/local/portage/layman/desktop-effects /usr/local/portage/layman/je_fro /usr/local/portage/layman/x11 /usr/local/portage" SYNC="rsync://rsync.europe.gentoo.org/gentoo-portage" USE="3dnow X X509 a52 aac aalib accessibility acl acpi akode alsa amr async audiofile automount avahi bash-completion berkdb bidi bl blas bluetooth bonjour branding bzip2 cairo caps cblas cdda cddb cdio cdparanoia cdr chroot cisco cli conntest cpudetection cracklib crypt cscope css cups curl custom-cflags custom-optimization daap dbus deprecated devil directfb divx double-precision dri dts dv dvd dvdr dvdread eds emboss enca encode esd evo exif extrafilters fam fame fbcon fbcondecor fbsplash ffmpeg fftw firefox flac fontconfig foomaticdb fortran fping ftp fuse gadu gd gdbm ggi gif gimp glib glitz gmedia gnutls gpm groupwise gstreamer gtk gtkhtml hal hddtemp howl-compat hpn iconv icu idn imagemagick imap imlib immqt-bc inkjar ipv6 isdnlog jack java javascript jpeg jpeg2k kde kerberos krb4 lame lapack laptop latex lcms ldap lesstif levels libcaca libnotify live logrotate lzo mad mailwrapper matroska mdnsresponder-compat meanwhile midi mikmod mixer mjpeg mmx mmxext mng mod motif mp3 mpeg mpi mplayer msn mudflap musepack music musicbrainz mysql nano-syntax nas ncurses neXt network networkmanager nls nntp nptl nptlonly nsplugin oav odbc ogg openal openexr opengl openmp openvpn oss pam pcre pdf perl php physfs plotutils png portaudio postgres povray ppds pppd prediction pyste python qq qt3 qt3support qt4 quicktime rar rdesktop readline real realmedia reflection regex remix rtc rtsp samba sametime sasl scanner scenarios sdl sdl-image sensord session shout silc skey skins slp smp sndfile songs sounds speex spell spl sqlite sse sse2 ssl ssse3 startup-notification stream subtitles svg svga swat sysfs syslog talkfilters tcl tcpd tetex tga themes theora threads tidy tiff timidity tk tools truetype umfpack unicode unsupported usb utempter v4l v4l2 vcd vdr vidix vim-pager vim-syntax vim-with-x visualization voice vorbis wavpack wifi win32codecs winbind wireshark wmf wmp wxwindows x264 x86 xanim xcb xcomposite xforms xine xinerama xml xorg xosd xpm xprint xulrunner xv xvid xvmc yv12 zephyr zlib" ALSA_CARDS="ali5451 als4000 atiixp atiixp-modem bt87x ca0106 cmipci emu10k1 emu10k1x ens1370 ens1371 es1938 es1968 fm801 hda-intel intel8x0 intel8x0m maestro3 trident usb-audio via82xx via82xx-modem ymfpci" ALSA_PCM_PLUGINS="adpcm alaw asym copy dmix dshare dsnoop empty extplug file hooks iec958 ioplug ladspa lfloat linear meter mmap_emul mulaw multi null plug rate route share shm softvol" APACHE2_MODULES="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 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" ELIBC="glibc" INPUT_DEVICES="keyboard mouse synaptics" KERNEL="linux" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" LINGUAS="de" USERLAND="GNU" VIDEO_CARDS="vesa fbdev radeon" Unset: CPPFLAGS, CTARGET, EMERGE_DEFAULT_OPTS, INSTALL_MASK, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS galtgendo@o2.pl 2008-08-16 11:34:55 0000 Of course, it's not possible. sys-libs/e2fsprogs-libs is sys-libs/ss+sys-libs/com_err, so this is invalid. andrej.filipcic@ijs.si 2008-08-16 12:17:50 0000 Well, the installation is not that simple. If ss and com_err are unmerged first, it is very likely that wget will not work, so maybe clear instructions how to upgrade should be given. There are also packages with explicit ss+com_err dependencies like app-crypt/mit-krb5-1.6.3-r1 which should be corrected. ari@goron.de 2008-08-16 13:11:29 0000 (In reply to comment #2) > Well, the installation is not that simple. If ss and com_err are unmerged > first, it is very likely that wget will not work, so maybe clear instructions > how to upgrade should be given. > > There are also packages with explicit ss+com_err dependencies like > app-crypt/mit-krb5-1.6.3-r1 which should be corrected. > Yep, I ran into the same. Unmerged e2fsprogs to get rid of the block, then on 'emerge e2fsprogs' wget failed due to missing library. Being as essential for merging wget should be static, or it's dependency libs should be protected. Was easy to download the e2fsprogs tarball with a browser and put into distfiles, but once this change goes into stable less pragmatic users will get into real trouble. Then, off course, I also ran into the krb5 trap. To get the merge going I removed the 2 old libs from RDEPEND in the ebuild and rebuilt the digest, but thats once again something less technical users would not do. If you change / update libs which are part of the system profile, please at least do a dependency check first so that people always have working systems! jdaluz@gmail.com 2008-08-16 13:56:08 0000 The summary should probably be changed to indicate unmerging these two packages b0rks wget and therefore portage/paludis/pkgcore. It might be hard to get this bug triaged properly with the current summary... kentfredric@gmail.com 2008-08-16 16:07:06 0000 I am confused as to how to proceed. It would appear any solution that does not involve hosing your system involves eliminating collision protect. this is rather hackish. Can we tweak lib-paths in such a way that satisfies : if com/ss and e2fsprogs-libs are both present, e2fsprogs-libs takes priority if com/ss is present and the other is absent, com/ss still works and you can install e2fsprogs-libs if com/ss is absent, e2fsprogs-libs is your new boss. Then we can get a silent/seamless install Colliding files ( after ebuild hacking to avert the dep ) collision-protect> * /lib64/libcom_err.so already exists in / collision-protect> * /lib64/libcom_err.so.2 already exists in / collision-protect> * /lib64/libcom_err.so.2.1 already exists in / collision-protect> * /lib64/libss.so already exists in / collision-protect> * /lib64/libss.so.2 already exists in / collision-protect> * /lib64/libss.so.2.0 already exists in / collision-protect> * /usr/bin/compile_et already exists in / collision-protect> * /usr/bin/mk_cmds already exists in / collision-protect> * /usr/include/et/com_err.h already exists in / collision-protect> * /usr/include/ss/ss.h already exists in / collision-protect> * /usr/include/ss/ss_err.h already exists in / collision-protect> * /usr/lib64/libcom_err.a already exists in / collision-protect> * /usr/lib64/libcom_err.so already exists in / collision-protect> * /usr/lib64/libss.a already exists in / collision-protect> * /usr/lib64/libss.so already exists in / collision-protect> * /usr/lib64/pkgconfig/com_err.pc already exists in / collision-protect> * /usr/lib64/pkgconfig/ss.pc already exists in / collision-protect> * /usr/share/et/et_c.awk already exists in / collision-protect> * /usr/share/et/et_h.awk already exists in / collision-protect> * /usr/share/ss/ct_c.awk already exists in / collision-protect> * /usr/share/ss/ct_c.sed already exists in / oskar.ellstrom@gmail.com 2008-08-16 18:14:41 0000 What I did to install e2fsprogs-libs is a story I never recommend! Not even my fellow enemies. Well, maybe the worst ones... ;-) Let's just say I ran into to deep sh.. ehm, had some problems. What I did was "emerge -Cav ss com_err" - went fine until next emerge - the whole filesystem managing and wget b0rked. The only solution was to reboot into a gentoo livecd, download the e2fsprogs* files into a chroot of my harddrives and emerge e2fsprogs-libs from there. After that, everything started to work properly again and I could reboot back into my regular system w/o proplems. So the sum of all this... DON'T un-emerge sys-libs/ss and sys-libs/com_err like I did no matter how good e2fsprogs-libs work. However, sys-libs/ss and sys-libs/com_err still appears as blocking dependencies when emerge -avDNu world. gentooperson@yahoo.com 2008-08-16 20:29:52 0000 (In reply to comment #5) > I am confused as to how to proceed. Since losing wget support is the problem, emerge --fetchonly the new packages, and *then* unmerge ss and com_err. Since the packages are already present, no wget will be attempted. After ss, com_err, and the old e2fsprogs are unmerged use --nodeps to emerge just e2fsprogs-libs and the new e2fsprogs specifically. Otherwise, ss and com_err will try to come back in as deps. e2fsprogs needs to be removed to deal with the package collisions that would otherwise occur. All of these changes should be done specifically to these packages in one short session, and not as part of a larger "world" update. e2fsprogs supplies libraries that, if absent, will prevent a large number of programs from working, and will probably prevent reliable emerges of other packages. Here are the steps: 1. emerge -NuDav --fetchonly world 2. emerge -C ss com_err e2fsprogs 3. emerge -NuDav --nodeps e2fsprogs-libs e2fsprogs 4. echo "sys-libs/com_err" >>/etc/portage/package.mask 5. echo "sys-libs/ss" >>/etc/portage/package.mask 6. echo "sys-libs/com_err-1.40.11" >>/etc/portage/profile/package.provided 7. echo "sys-libs/ss-1.40.11" >>/etc/portage/profile/package.provided The last two are to prevent other packages such as app-crypt/mit-krb5 which have runtime dependencies directly on com_err or ss. Running revdep-rebuild afterward did not find any packages in need of updates. danierrr@gmail.com 2008-08-17 02:52:53 0000 #7 resolved this block on my ~amd64 system -- thanks! kentfredric@gmail.com 2008-08-17 07:32:26 0000 (In reply to comment #7) And for Paludis: > Here are the steps: > > 1. emerge -NuDav --fetchonly world paludis -i -f system > 2. emerge -C ss com_err e2fsprogs paludis --permit-unsafe-uninstalls -u ss com_err e2fsprogs > 3. emerge -NuDav --nodeps e2fsprogs-libs e2fsprogs paludis -i -1 --dl-deps-default discard e2fsprogs-libs e2fsprogs However, still one remaining collision here on /usr/share/info/libext2fs.info.gz Also, a mild confusion in terms: e2fsprogs vs e2fsprogs-libs. Why the hell are these files in e2fsprogs instead of in libs? O_o? --- /usr/lib64/libe2p.so --- /usr/lib64/libext2fs.so spl /lib64/libe2p.so.2.3 -> /usr/lib64/debug/lib64/libe2p.so.2.3.debug str /lib64/libe2p.so.2.3 spl /lib64/libext2fs.so.2.4 -> /usr/lib64/debug/lib64/libext2fs.so.2.4.debug str /lib64/libext2fs.so.2.4 Seems like this commit load is just made of fail. kentfredric@gmail.com 2008-08-17 08:07:22 0000 --- old/e2fsprogs-libs-1.41.0.ebuild 2008-08-17 08:04:07.721243682 +0000 +++ new/e2fsprogs-libs-1.41.0.ebuild 2008-08-17 08:03:53.676522481 +0000 @@ -62,4 +62,7 @@ mv "${lib%.a}"$(get_libname)* "${D}"/$(get_libdir)/ || die "moving lib ${slib}" gen_usr_ldscript ${slib%.a}$(get_libname) done + # Remove this, because presently its library is not in this package + # and e2fsprogs collides + rm "${D}"/usr/share/info/* } Fixes my problem. :) mark@fluxbox.org 2008-08-17 08:38:31 0000 I can confirm that the steps in #7 work, apart from needing 5.5: mkdir /etc/portage/profile on my system. pchrist@gentoo.org 2008-08-17 08:41:58 0000 (In reply to comment #10) > ... > Fixes my problem. :) > This was already fixed (bug 234885) ... pchrist@gentoo.org 2008-08-17 09:29:45 0000 Please, remember that you 're all running ~arch. The only reason, I didn't resolve the default bug as invalid, is that base-system team, should think of how to handle the issue with wget(if there is one) when e2fsprogs-libs will reach stable. The workarounds in comments #7 and #9 are ok for now, if you want to try. But you can also echo =sys-fs/e2fsprogs-1.41.0 >> /etc/portage/package.mask and wait a couple of hours until the proper developers respond. Let's give them time. Thank you all. pchrist@gentoo.org 2008-08-17 09:44:40 0000 Also, for the record, I tried to reproduce the wget issue, by unmerging ss, com_err and e2fsprogs, from my amd64 testing box, and wget works flawlessly, so I expect at least, from you who experienced the wget failure, to give us feedback. Wget versions, error messages, maybe USE flags which were ON, when emerging wget and anything else which you think would help us to trace a *real* bug. graham@gmurray.org.uk 2008-08-17 10:03:14 0000 (In reply to comment #14) > Also, for the record, I tried to reproduce the wget issue, by unmerging ss, > com_err and e2fsprogs, from my amd64 testing box, and wget works flawlessly, so > I expect at least, from you who experienced the wget failure, to give us > feedback. Wget versions, error messages, maybe USE flags which were ON, when > emerging wget and anything else which you think would help us to trace a *real* > bug. > It is pulled into wget by libssl.so.0.9.8. readelf -d /usr/bin/wget Dynamic section at offset 0x30f00 contains 25 entries: Tag Type Name/Value 0x00000001 (NEEDED) Shared library: [libssl.so.0.9.8] 0x00000001 (NEEDED) Shared library: [libcrypto.so.0.9.8] 0x00000001 (NEEDED) Shared library: [libdl.so.2] 0x00000001 (NEEDED) Shared library: [librt.so.1] 0x00000001 (NEEDED) Shared library: [libc.so.6] readelf -d /usr/lib/libssl.so Dynamic section at offset 0x46e7c contains 31 entries: Tag Type Name/Value 0x00000001 (NEEDED) Shared library: [libgssapi_krb5.so.2] 0x00000001 (NEEDED) Shared library: [libkrb5.so.3] 0x00000001 (NEEDED) Shared library: [libcom_err.so.2] 0x00000001 (NEEDED) Shared library: [libk5crypto.so.3] 0x00000001 (NEEDED) Shared library: [libresolv.so.2] 0x00000001 (NEEDED) Shared library: [libcrypto.so.0.9.8] 0x00000001 (NEEDED) Shared library: [libdl.so.2] 0x00000001 (NEEDED) Shared library: [libc.so.6] 0x0000000e (SONAME) Library soname: [libssl.so.0.9.8] readelf -d /usr/lib/libkrb5.so.3 Dynamic section at offset 0x8be5c contains 30 entries: Tag Type Name/Value 0x00000001 (NEEDED) Shared library: [libk5crypto.so.3] 0x00000001 (NEEDED) Shared library: [libcom_err.so.2] 0x00000001 (NEEDED) Shared library: [libkrb5support.so.0] 0x00000001 (NEEDED) Shared library: [libresolv.so.2] 0x00000001 (NEEDED) Shared library: [libc.so.6] 0x0000000e (SONAME) Library soname: [libkrb5.so.3] 0x0000000f (RPATH) Library rpath: [/usr/lib] 0x0000001d (RUNPATH) Library runpath: [/usr/lib] Relevent use flags are: emerge -pv wget openssl mit-krb5 These are the packages that would be merged, in order: Calculating dependencies... done! [ebuild R ] app-crypt/mit-krb5-1.6.3-r1 USE="doc ipv6 tcl -krb4" 0 kB [ebuild R ] dev-libs/openssl-0.9.8h-r1 USE="gmp kerberos sse2 zlib -bindist -test" 0 kB [ebuild R ] net-misc/wget-1.11.4 USE="ipv6 nls ssl -debug -socks5 -static" 0 kB graham@gmurray.org.uk 2008-08-17 10:04:48 0000 oops, should also have said I am running ~x86 pchrist@gentoo.org 2008-08-17 11:56:01 0000 This sucks. The conclusion is that unmerging com_err, breaks kerberos, which breaks openssl when kerberos USE flag is enabled, which breaks every package depending on openssl. pchrist@gentoo.org 2008-08-17 13:06:22 0000 Ok, the direct problem with wget, can be solved if: echo net-misc/wget -ssl >> /etc/portage/package.use && emerge -1 wget or echo dev-libs/openssl -kerberos >> /etc/portage/package.use && emerge -1 openssl Then you will be able to download any distfiles, emerge e2fsprogs-libs etc. and then,rebuild wget and/or openssl with your default, use flags, again. app-crypt/mit-krb5 needs to be fixed. I think that the above solution is safer than comments #7,#9. I can't find myself a better solution. @base-system, sorry for this madness. seventhguardian@gmail.com 2008-08-17 18:15:54 0000 Fixing it by just using #7 may not work if recompiling mit-krb5. It seems that the com_err headers are put in /usr/include/et/, and mit-krb5 doesn't find them. I had to add "-I/usr/include/et" to my CFLAGS in /etc/make.conf (hacky, I know). Other than that it should work fine. So the mit-krb5 ebuild should definitely be fixed. zmedico@gentoo.org 2008-08-17 18:36:02 0000 Another possible workaround is to temporarily remove e2fsprogs from the system set, in order to allow emerge to solve the blockers automatically by allowing files belonging to the old e2fsprogs version to be temporarily overwritten with files from the new e2fsprogs-libs package: mkdir -p /etc/portage/profile echo "-*sys-fs/e2fsprogs" >> /etc/portage/profile/packages emerge -p e2fsprogs These are the packages that would be merged, in order: Calculating dependencies... done! [ebuild N ] sys-libs/e2fsprogs-libs-1.41.0 USE="nls" [ebuild U ] sys-fs/e2fsprogs-1.41.0 [1.40.11] [blocks b ] <sys-fs/e2fsprogs-1.41 (is blocking sys-libs/e2fsprogs-libs-1.41.0) [uninstall ] sys-libs/com_err-1.40.11 [blocks b ] sys-libs/com_err (is blocking sys-libs/e2fsprogs-libs-1.41.0) [uninstall ] sys-libs/ss-1.40.11 [blocks b ] sys-libs/ss (is blocking sys-libs/e2fsprogs-libs-1.41.0) Note that the above blockers are solved automatically, indicated with a small 'b' instead of a big 'B'. After the updated is complete, don't forget to remove the temporary entry from /etc/portage/profile/packages. In order to automatically handle cases like this in the future, we can add some new ebuild metadata to serve as an indicator that it is safe for e2fsprogs-libs to overwrite the files of the old e2fsprogs version. Then there won't be any need to temporarily remove e2fsprogs from the system set. zmedico@gentoo.org 2008-08-17 18:40:02 0000 (In reply to comment #20) > In order to automatically handle cases like this in the future, we can add some > new ebuild metadata to serve as an indicator that it is safe for e2fsprogs-libs > to overwrite the files of the old e2fsprogs version. Then there won't be any > need to temporarily remove e2fsprogs from the system set. We may even want to consider removing sys-fs/e2fsprogs from the system set since it's already pulled in by sys-apps/util-linux which also happens to be in the system set. harrisl@lhjonline.com 2008-08-17 18:55:14 0000 paludis has a different problem than portage. Paludis, after e2fsprogs-1.41.0 etc what put in the tree failed on paludis -ip world with !com_err blocks because of runtime checking. Therefore, e2fsprogs-libs was never installed and nothing was broken. To get paludis -ip world working again it was necessary to add: =sys-fs/e2fsprogs-1.41.0 =net-fs/nfs-utils-1.1.3 to /etc/paludis/package_mask.conf Once mit-krb is fixed the mask entries should be removed zmedico@gentoo.org 2008-08-17 20:15:03 0000 As suggested in comment #21, in order to allow automatic blocker resolution, I've removed sys-fs/e2fsprogs from the system set. This change shouldn't hurt since the sys-fs/e2fsprogs package is pulled in as a dependency of sys-apps/util-linux, which is a member of the system set for relevant profiles. nshephard@gmail.com 2008-08-18 06:07:50 0000 (In reply to comment #13) > But you can also > > echo =sys-fs/e2fsprogs-1.41.0 >> /etc/portage/package.mask > Doesn't quite work here, as sys-libs/e2fsprogs-libs-1.41.0 is a dependency of net-fs/nfs-utils-1.1.3 so that needs masking too. ford_prefect@gentoo.org 2008-08-18 08:47:21 0000 The following apps need fixed deps (for eg.: "|| ( sys-libs/e2fsprogs-libs ( sys-libs/com_err sys-libs/ss ) )") * app-crypt/mit-krb5 * app-crypt/heimdal * net-mail/fetchmail * sci-mathematics/gimps kentfredric@gmail.com 2008-08-18 10:31:04 0000 (In reply to comment #24) > (In reply to comment #13) > > But you can also > > > > echo =sys-fs/e2fsprogs-1.41.0 >> /etc/portage/package.mask > > > > Doesn't quite work here, as sys-libs/e2fsprogs-libs-1.41.0 is a dependency of > net-fs/nfs-utils-1.1.3 so that needs masking too. > A forward warning to people removing sys-fs/e2fsprogs: I found a few other apps such as Vim break when e2fsprogs goes missing ( libuuid.so link dep via libSM.so , which i believe is heavily used for X apps ), so forward warning, that you want to do this as fast as practical or lots of things may randomly stop working. gentooperson@yahoo.com 2008-08-18 13:39:11 0000 FYI: My machine is ~x86, and mit-krb5 is emerged on it, and it's the only package on my system that is affected by this problem. This explains why some of the people I was talking to in #getnoo at the same time I was fixing this were not also seeing the problem (to the same degree). I did experience the wget problem when I first unmerged com_err and ss. I just re-emerged the same older versions, and restarted the fix with the --fetchonly step from comment #7. I have another ~x86 machine suffering from the same problem, today. Going to do the steps from comment #7 on it. gentooperson@yahoo.com 2008-08-18 13:41:19 0000 As an experiment, I tried the steps in comment #21, but got this: # emerge -p e2fsprogs These are the packages that would be merged, in order: Calculating dependencies... done! [ebuild N ] sys-libs/e2fsprogs-libs-1.41.0 USE="nls" [ebuild U ] sys-fs/e2fsprogs-1.41.0 [1.40.11] [blocks b ] <sys-fs/e2fsprogs-1.41 (is blocking sys-libs/e2fsprogs-libs-1.41.0) [blocks B ] sys-libs/ss (is blocking sys-libs/e2fsprogs-libs-1.41.0) [blocks B ] sys-libs/com_err (is blocking sys-libs/e2fsprogs-libs-1.41.0) What version of portage does the automatic removals? gentooperson@yahoo.com 2008-08-18 13:43:08 0000 (In reply to comment #28) > As an experiment, I tried the steps in comment #21, but got this: > I meant comment #20. gentooperson@yahoo.com 2008-08-18 14:22:03 0000 NOTE: I submitted bug 235110 against mit-krb5. It can't be rebuilt after e2fsprogs-libs-1.41.0 has been emerged. For runtime, it appears to be fine. zmedico@gentoo.org 2008-08-18 19:19:50 0000 (In reply to comment #29) > (In reply to comment #28) > > As an experiment, I tried the steps in comment #21, but got this: > > > I meant comment #20. > It worked for me because I have the kerberos USE flag disabled globally. For those that have the kerberos USE flag enabled, you'll need a kerberos implementation that can use sys-libs/e2fsprogs-libs as a substitute for sys-libs/ss and sys-libs/com_err (see bug 234886). Once we have a new app-crypt/mit-krb5 ebuild that supports using sys-libs/e2fsprogs-libs as a substitute for sys-libs/ss and sys-libs/com_err, the blocker resolution occur automatically as shown in comment #20. Until then, the recommended practice is to mask the sys-libs/e2fsprogs and sys-libs/e2fsprogs-libs updates if you have the kerberos USE flag enabled. vapier@gentoo.org 2008-08-19 01:10:05 0000 leaving e2fsprogs out of system set is not a long term solution ... it provides "fsck" which is clearly "system" zmedico@gentoo.org 2008-08-19 02:45:55 0000 I'm going to propose some kind of ebuild metadata extension to solve cases like that. Once we've got that in place, we can add e2fsprogs back to system. Until then, having e2fsprogs in system is too much of a support nightmare given that kerberos is enabled by default in the profiles. mueli@gentoo.org 2008-08-19 13:04:46 0000 kerberos is fixed. Your bad luck was only that I was on vacation last week, no need to live without e2fsprogs ;) Once again I'd like to remind everyone to think about if it is really necessary to have a global kerberos use - sometimes I feel like people have enabled it just to be cool. Even if you've kerberos auth well configured, a global "kerberos" use might be the wrong decision because you don't want to enable the GSS/kerberos bindings in all apps. g, mueli mueli@gentoo.org 2008-08-19 13:05:33 0000 btw - why didn't anybody added kerberos@gentoo.org to CC list? wgi@muenster.de 2008-08-20 08:11:30 0000 (In reply to comment #34) > kerberos is fixed. Your bad luck was only that I was on vacation last week, no > need to live without e2fsprogs ;) Nice, which version can we expect to not depend on com_err anymore? # equery d sys-libs/com_err [ Searching for packages depending on sys-libs/com_err... ] app-crypt/mit-krb5-1.6.3-r2 (sys-libs/com_err) sys-fs/e2fsprogs-1.40.11 (~sys-libs/com_err-1.40.11) sys-libs/ss-1.40.11 (~sys-libs/com_err-1.40.11) zmedico@gentoo.org 2008-08-20 16:32:23 0000 If you look in the ebuild then you'll see that it has e2fsprogs-libs listed as an alternative choice: || ( ( sys-libs/com_err sys-libs/ss ) ( >sys-libs/e2fsprogs-libs-1.40.11 ) ) It will solve automatically if you mask the sys-libs/com_err and sys-libs/ss packages in /etc/portage/package.mask: $ emerge -pv mit-krb5 e2fsprogs These are the packages that would be merged, in order: Calculating dependencies... done! [ebuild N ] sys-libs/e2fsprogs-libs-1.41.0 USE="nls" 476 kB [ebuild U ] sys-fs/e2fsprogs-1.41.0 [1.40.11] USE="nls (-static%)" 4,161 kB [blocks b ] <sys-fs/e2fsprogs-1.41 (is blocking sys-libs/e2fsprogs-libs-1.41.0) [ebuild N ] app-crypt/mit-krb5-1.6.3-r2 USE="-doc -krb4" 11,636 kB [uninstall ] sys-libs/com_err-1.40.11 USE="nls" [blocks b ] sys-libs/com_err (is blocking sys-libs/e2fsprogs-libs-1.41.0) [uninstall ] sys-libs/ss-1.40.11 USE="nls" [blocks b ] sys-libs/ss (is blocking sys-libs/e2fsprogs-libs-1.41.0) Note that the above blockers are solved automatically, indicated with a small 'b' instead of a big 'B'. mjevans1983@gmail.com 2008-08-21 11:50:36 0000 Paludis steps that work: Verify ONLY the two blocks mentioned above exist for this. paludis -ip e2fsprogs-libs (The second is optional) paludis --dl-blocks discard -if e2fsprogs-libs paludis --dl-blocks discard -ip e2fsprogs-libs paludis --dl-blocks discard -i e2fsprogs-libs harrisl@lhjonline.com 2008-08-21 12:48:18 0000 e2fsprogs-1.41.0 and e2fsprogs-libs-1.41.0 are already installed. Is this a bug in paludis? paludis -ip mit-krb5 Building target list... paludis@1219322750: [WARNING e.vdb.provides.no_package] In program paludis -ip mit-krb5: ... When performing install action from command line: ... When adding install target 'mit-krb5': ... When parsing user package dep spec 'mit-krb5': ... When parsing generic package dep spec 'mit-krb5': ... When disambiguating package name 'mit-krb5': ... When finding all versions in some arbitrary order from packages matching */mit-krb5 with filter all matches filtered through supports action install: ... When finding category names containing package 'mit-krb5': ... When loading names for virtuals repository: ... When finding provided packages for 'installed': ... No package available for 'media-libs/libquicktime 1.0.2' Building dependency list... These packages will be installed: * sys-libs/com_err [N 1.40.11] Reasons: *app-crypt/mit-krb5-1.6.3-r2:0::gentoo, *sys-libs/ss-1.40.11:0::gentoo "common error display library" nls * sys-libs/ss [N 1.40.11] Reasons: *app-crypt/mit-krb5-1.6.3-r2:0::gentoo "Subsystem command parsing library" nls * app-crypt/mit-krb5 [R 1.6.3-r2] <target> Reasons: dev-libs/openssl-0.9.8h-r1:0::installed -doc -krb4 Total: 3 packages (2 new, 1 rebuild) mjevans1983@gmail.com 2008-08-21 14:02:19 0000 (In reply to comment #39) > e2fsprogs-1.41.0 and e2fsprogs-libs-1.41.0 are already installed. Is this a bug > in paludis? > It might be, I had mine synced as of 3am this morning and it -still- required a manual re-slotting. It might be paludis or it could be the way the .ebuild is written. RDEPEND="!virtual/krb5 || ( ( sys-libs/com_err sys-libs/ss ) ( >sys-libs/e2fsprogs-libs-1.40.11 ) )" DEPEND="${RDEPEND} I'm not sure what they're supposed to look like, but I'd guess that the || is in the wrong place unless they like that strange stack-style notation. harrisl@lhjonline.com 2008-08-21 14:08:54 0000 removing the com_err ss dependency from the ebuild fixes the problem so I assume paludis doesn't understand the ||() () syntax or is mishandling the short circuit as in taking the first option as true and trying to install com_err and ss and ignoring the fact that efs2progs-libs is installed. zmedico@gentoo.org 2008-08-21 18:58:03 0000 If you're have paludis problems then please file a separate bug for paludis. For portage users, the recommended solution is detailed in comment #37. tanderson@gentoo.org 2008-08-26 18:41:52 0000 *** Bug 235619 has been marked as a duplicate of this bug. *** tanderson@gentoo.org 2008-08-26 18:47:28 0000 @Zac: This bug was never anything wrong with paludis. @All: This is now fixed in CVS. jer@gentoo.org 2008-09-02 18:12:04 0000 *** Bug 236475 has been marked as a duplicate of this bug. *** volkerarmin@googlemail.com 2008-09-06 06:49:48 0000 @44 'fixed in cvs' does not mean 'fixed in the tree' right? Because I just ran into it(it:this bug). zmedico@gentoo.org 2008-09-06 16:28:49 0000 (In reply to comment #46) > @44 'fixed in cvs' does not mean 'fixed in the tree' right? > Because I just ran into it(it:this bug). It is fixed in the tree. However, you need to mask sys-libs/com_err and sys-libs/ss. Once you've masked those packages, the blockers will resolve automatically as noted in comment #37. You may also need to removed sys-libs/com_err and/or sys-libs/ss from /var/lib/portage/world if they happen to be in there. gasper.azman@gmail.com 2008-09-10 17:58:14 0000 Is this resolved-fixed as in works for everybody or resolved-fixed "should be oh-right", because my gentoo noob girlfriend just ran into this bug, and it wasn't fixed even when she did emerge portage and synced the tree. We had to repeat the 7 steps from comment #7. She's on ~amd64, just in case. Cheers, Gašper zmedico@gentoo.org 2008-09-10 18:21:42 0000 It's fixed but you have to follow these steps: 1) Mask sys-libs/com_err and sys-libs/ss in /etc/portage/package.mask: echo sys-libs/com_err >> /etc/portage/package.mask echo sys-libs/ss >> /etc/portage/package.mask 2) Check /var/lib/portage/world and if it contains either sys-libs/com_err or sys-libs/ss then remove those atoms from the world file. Once you've masked those packages and ensured that they are not in your world file, the blockers will resolve automatically as noted in comment #37. kentfredric@gmail.com 2008-09-10 23:54:29 0000 (In reply to comment #49) > It's fixed but you have to follow these steps: > > 1) Mask sys-libs/com_err and sys-libs/ss in /etc/portage/package.mask: > > echo sys-libs/com_err >> /etc/portage/package.mask > echo sys-libs/ss >> /etc/portage/package.mask > > 2) Check /var/lib/portage/world and if it contains either sys-libs/com_err or > sys-libs/ss then remove those atoms from the world file. > > Once you've masked those se packages and ensured that they are not in your world > file, the blockers will resolve automatically as noted in comment #37. > Can we have a fix that doesn't require these manual steps? Or I would hope, at least some sort of warning message *SOMEWHERE* that this is going to occur/need to be done. I can't imagine for instance, a windows update disk stopping midway with a "oops. hmm. looks like you have windows installed, can't help you" that required *all* users to look up the solution in google and then boot up a recovery cd and manually edit registry keys ... ok, maybe i can, but /were/ not so horrendous. Even if we could realase say, =sys-libs/com_err-9000 and =sys-libs/ss-9000 which are just dummy meta-packages that do nothing, and nothing blocks on them. ie: sys-libs/com_err-9000 pdepend e2fsprogs-libs sys-libs/ss-9000 pdepend e2fsprogs-libs sys-fs/e2fsprogs-libs depend !<sys-libs/com_err-9000 !<sys-libs/ss-9000 sys-fs/e2fsprogs depend e2fsprogs-libs Surely that would be a closer approximation to a working fix? zmedico@gentoo.org 2008-09-11 00:19:25 0000 I'd suggest removing sys-libs/com_err and sys-libs/ss from the dependency choices in the mit-krb5 ebuild, which would make sys-libs/e2fsprogs-libs the only choice. Then the masking step wouldn't be necessary and the upgrade would proceed automatically, except in cases when the world file contains sys-libs/com_err or sys-libs/ss (normally it doesn't). zmedico@gentoo.org 2008-09-11 00:24:11 0000 Kerberos maintainers, can we get your opinion on comment #19 and comment #20? zmedico@gentoo.org 2008-09-11 00:25:16 0000 (In reply to comment #52) > Kerberos maintainers, can we get your opinion on comment #19 and comment #20? > Pardon, I mean comment #50 and comment #51. mueli@gentoo.org 2008-09-11 06:52:53 0000 But comment #19 is what we are about. I've already fixed the issue in the unstable >=app-crypt/mit-krb5-1.6.3-r2 by changing the RDPEEND and adding: || ( ( sys-libs/com_err sys-libs/ss ) ( >sys-libs/e2fsprogs-libs-1.40.11 ) ) and adding the include flag. # needed to work with sys-libs/e2fsprogs-libs <- should be removed!! append-flags "-I/usr/include/et" You have to use the unstable mit-krb5 if you want to use e2fsprogs in the new version. Add "app-crypt/mit-krb5" to your package.keywords and the problem should be fixed. g, mueli p.S.: See also bug #234886 (dependency) mueli@gentoo.org 2008-09-11 06:58:22 0000 Oh - SRY. comment #50 is about a solution for the upgrade path. I am not sure if that's a good solution because then I am only able to use mit-krb5 with the unstable e2fsprogs. Once again it's more a bug in paludis then in the mit-krb5 ebuild. The package manager should handle || really as "or" and not as "i take the first one even if the second one is emerged" ;) If the removal of the dependency to the old libs is the only way around it, than I am willing to remove the dep. g, mueli zmedico@gentoo.org 2008-09-11 07:11:05 0000 (In reply to comment #55) > I am not sure if that's a good solution because then I am only able to use > mit-krb5 with the unstable e2fsprogs. Well, the solution in comment #49 works well enough for portage so if you have a good reason to keep using sys-libs/com_err and sys-libs/ss then I suppose you should keep the || as it is. mueli@gentoo.org 2008-09-11 12:23:29 0000 I've removed the old libs and depend direct on e2fsprogs-libs in >=mit-krb5-1.6.3-r4 jeremy.gove@gmail.com 2008-09-12 16:01:57 0000 I just practically destroyed my system by unmerging e2fsprogs, and thankfully I found this post. I just wonder: how did the people in 3 and 6 fix the problem? I can't do anything. I can't install it via ebuilt because wget is missing; I have the file e2fsprogs-1.41.1.tar.gz2 on my hard drive. What do I do from here? zmedico@gentoo.org 2008-09-12 16:25:20 0000 (In reply to comment #58) There's enough noise in here already so please take questions of that nature to forums.gentoo.org or the gentoo-user mailing list (subscription instructions are at lists.gentoo.org). jer@gentoo.org 2008-09-13 17:11:07 0000 *** Bug 237550 has been marked as a duplicate of this bug. *** c4blem0nkey@gmail.com 2008-09-25 20:11:19 0000 This bug doesn't seem to be resolved unstream as I've held back from tackling this blocker for 2 program minor versions and 3 months or so portage updates. Before checking for bugs, I resorted to manually copying the libs to out of /lib and `emerge -C ss com_err` then cp them back in and performing a normal emerge of e2fsprogs and e2fsprogs-libs. The result of the emerge for e2fsprogs-libs states a collision-protect message, but that can be cleared up by simply remerge e2fsprogs-libs. The quickest path to results seems to be: for i in libss.so.2.0 libcom_err.so.2.1; do cp /lib/${i} /root/; done emerge -C ss com_err for i in libss.so.2.0 libcom_err.so.2.1; do cp /root/${i} /lib/; done $(cd /lib; ln -s /lib/libss.so.2.0 libss.so.2; ln -s /lib/libss.so.2.0 libss.so) $(cd /lib; ln -s /lib/libcom_err.so.2.1 libcom_err.so.2; ln -s /lib/libcom_err.so.2.1 libcom_err.so) emerge -1 e2fsprogs e2fsprogs-libs emerge e2fsprogs-libs That's how I got around the problem of having the deps for ss and com_err without having to pre-fetch the source for everything else. Mose people won't think to pre-fetch the goods, they'll just -C ss and com_err and then have a dead system... :/ What are the chance that we could insert a fix in a ${PV}-r1 of e2fsprogs that would have a script snippet like mine above that would resort to rebuilding the packages with proper dependent libs while not truly removing the lib files? Just, you know...shuffling them a bit? c4blem0nkey@gmail.com 2008-09-25 20:13:19 0000 tacking myself on to the CC... zmedico@gentoo.org 2008-09-25 21:28:52 0000 (In reply to comment #61) It should resolve automatically now as long as you have >=sys-apps/portage-2.1.5 and /var/lib/portage/world contains neither sys-libs/com_err nor sys-libs/ss. If you still have trouble then please file a new bug and attach emerge --debug output for the case where it bails out due to blockers. m.duelli@web.de 2008-10-27 22:06:15 0000 Today, I stumbled upon this bug and found that I had to remove the kerberos USE flag to prevent sys-libs/ss and sys-libs/com_err to block e2fsprogs and e2fsprogs-libs. scott@mcclung.com 2008-10-28 01:06:11 0000 (In reply to comment #64) > Today, I stumbled upon this bug and found that I had to remove the kerberos USE > flag to prevent sys-libs/ss and sys-libs/com_err to block e2fsprogs and > e2fsprogs-libs. I was able to keep kerberos by unmasking app-crypt/mit-krb5-1.6.3-r4. If you're having the same problem as I was (missing com_err.h), that might help. wgi@muenster.de 2008-10-28 07:06:07 0000 (In reply to comment #63) > It should resolve automatically now as long as you have > >=sys-apps/portage-2.1.5 and /var/lib/portage/world contains neither > sys-libs/com_err nor sys-libs/ss. Great - the problem just hit stable, since portage x86 ist still 2.1.4.5 ... odi@odi.ch 2008-10-28 09:22:03 0000 As this is a severe problem in stable, this bug should be reopened and the problem must be fixed ASAP or you will have a lot of people breaking their systems accidentially. This is doing a lot of damage to Gentoo's reputation. So better fix this immediately! ville@oikarinen.org 2008-10-28 09:37:16 0000 Waiting for a proper fix (CC), delaying emerge world zmedico@gentoo.org 2008-10-28 09:44:18 0000 Please direct complaints about the stabilization of sys-fs/e2fsprogs-1.41.2 to bug #244511. You can mask the packages locally in /etc/portage/package.mask if you don't want to deal with these updated now: echo =sys-fs/e2fsprogs-1.41.2 >> /etc/portage/package.mask echo =sys-libs/e2fsprogs-libs-1.41.2 >> /etc/portage/package.mask echo =app-crypt/mit-krb5-1.6.3-r4 >> /etc/portage/package.mask stupendoussteve@hotmail.com 2008-10-28 10:03:12 0000 (In reply to comment #67) > As this is a severe problem in stable, this bug should be reopened and the > problem must be fixed ASAP or you will have a lot of people breaking their > systems accidentially. This is doing a lot of damage to Gentoo's reputation. So > better fix this immediately! > This issue can be fixed or avoided, by either masking or (as mentioned) adding app-crypt/mit-krb5-1.6.3-r4 ~ARCH to package.keywords. At that point you may emerge -f all of the packages to be built and remove the blockers. Update should run smoothly from there (works on stable x86). rodrigo@fabricadeideias.com 2008-10-28 10:14:16 0000 (In reply to comment #69) > You can mask the packages locally in /etc/portage/package.mask if > you don't want to deal with these updated now: > > echo =sys-fs/e2fsprogs-1.41.2 >> /etc/portage/package.mask > echo =sys-libs/e2fsprogs-libs-1.41.2 >> /etc/portage/package.mask > echo =app-crypt/mit-krb5-1.6.3-r4 >> /etc/portage/package.mask I needed to add echo =net-fs/nfs-utils-1.1.3 >> /etc/portage/package.mask as this nfs-utils update depends on e2fsprogs-libs. marten@xtal.rwth-aachen.de 2008-10-28 12:16:26 0000 I also opt for reopenng this bug as it's affecting stable now. stonie.cooper@planetarydata.com 2008-10-28 15:14:32 0000 Yes, this bug is not fixed, and needs to be reopened. Stable versions are now being recursively blocked. zmedico@gentoo.org 2008-10-28 16:29:52 0000 (In reply to comment #73) > Yes, this bug is not fixed, and needs to be reopened. Stable versions are now > being recursively blocked. Actually, this bug has already been fixed. The main problem is that stabilization of sys-fs/e2fsprogs-1.41.2 has occurred before stabilization of >=sys-apps/portage-2.1.5 (which is able to resolve the blockers automatically). Unfortunately, >=sys-apps/portage-2.1.5 is not yet ready for stabilization. Please direct complaints about the stabilization of sys-fs/e2fsprogs-1.41.2 to bug #244511. You can mask the packages locally in /etc/portage/package.mask if you don't want to deal with these updates now: echo =sys-fs/e2fsprogs-1.41.2 >> /etc/portage/package.mask echo =sys-libs/e2fsprogs-libs-1.41.2 >> /etc/portage/package.mask echo =app-crypt/mit-krb5-1.6.3-r4 >> /etc/portage/package.mask echo =net-fs/nfs-utils-1.1.3 >> /etc/portage/package.mask themgt@mail.ru 2008-10-28 17:25:49 0000 This bug is SO not fixed! I synced today at about 15 o'clock CET, had the here mentioned blocks. I am using 2008.0/desktop profile, kerberos useflag set by default, x86 system. Luckily I made quickpkgs before unmerging any stuff, of course I b0rked wget after unmerging com_err (mounting tmpfs for /var/tmp/portage also failed, luckily I do not use any nfs or something). So i had to read the forums and find this bug to get around further trouble, emerged "-f world", unmerged com_err, ss and e2fsprogs and emerged e2fprogs and e2fsprogs-libs. Unluckily, mit-krb5-1.6.3-r1 (the latest STABLE package!)still depends on com_err and ss. So masking both (which i consider an ugly hack) gives me the same error I "resolved" (manually!!!) earlier! Adding both to package.provided is an even more ugly hack and does not resolv the mit-krb5 issue, because manually rebuilding the package is impossible since it does not find com_err.h! All in all, this is the worst case of causing users of the stable tree a bunch of trouble I ever witnessed! The bug is known since mid August, there was plenty of time to test a solution which does not involve hours of reading and fiddling around! Please reopen and take care of proper fixing!!! cardoe@gentoo.org 2008-10-28 17:34:28 0000 Yes, currently dependencies are broken on stable x86 due to someone keywording things in the wrong order. But that issue should be taken up on the stabilization bug. Not here. syscon780@gmail.com 2008-10-28 17:40:09 0000 (In reply to comment #74) > (In reply to comment #73) > > Yes, this bug is not fixed, and needs to be reopened. Stable versions are now > > being recursively blocked. > > Actually, this bug has already been fixed. The main problem is that > stabilization of sys-fs/e2fsprogs-1.41.2 has occurred before stabilization of > >=sys-apps/portage-2.1.5 (which is able to resolve the blockers automatically). > Unfortunately, >=sys-apps/portage-2.1.5 is not yet ready for stabilization. You can not mark packages sable or fixed that depends on another that is not marked as sable in this case "portage-2.1.5" Please reopen this bug and/or mark the "e2fsprogs-1.41.2" unstable before the it gets any worse :-/ Lately this is the second week on a row that something is borked (last week was openoffice) now is e2fsprogs. #Joseph jer@gentoo.org 2008-10-29 03:38:37 0000 *** Bug 244842 has been marked as a duplicate of this bug. *** webmaster@korten-privat.de 2008-10-29 10:10:13 0000 I also encountered this bug and am very annoyed that it is marked FIXED when it is not! Bugs like this in the STABLE tree make me start to think about using ubuntu instead of Gentoo. Just a simple question: What do com_err and ss have to do with e2fsprogs-libs? To me it sounds like a stupid idea to combine these things into one package. Especially since the kernel developers are already working on Btrfs, a replacement for the ext filesystem which will eventually make e2fsprogs obsolete (granted, this will take another few years). and when that time comes, we will have exactly the same problems with dependencies again!!! kozlowsm@mini.pw.edu.pl 2008-10-29 10:25:31 0000 A critical bug (unresolved dependecies) still exists in the stable tree (x86). Who has marked it FIXED?! andreabenini@gmail.com 2008-10-29 10:38:44 0000 Platform : X86, 32Bit, Pentium4 3.0GHz, 2Mb RAM I've finally solved as suggested in this bug report. after following comment #7 i've everything set except kerberos (mit-krb5) so i've added this line : app-crypt/mit-krb5 ~x86 to /etc/portage/package.keywords to get the latest mit-krb5 package, it seems this package supports e2fsprogs, current stable only uses ss and com_err libraries Everything worked like a charm now. I think you need to make stable latest mit-krb5 package or patch current stable if you want it compiled. Thanks guys Andrea Ben Benini yaverot@mail.com 2008-10-30 01:16:03 0000 Apparently I can't update the depends to include 244511, as one person indicates THAT is where the real problem is hiding. He should have no problem fixing that dependency if that is the correct solution. This bug has existed since yesterday in x86 stable and involves programs that are part of _system_ and unlike the mktemp blocker can't be resolved by --unmerge and merge as --unmerge apparently kills wget and therefore portage. Also shown in the comments are a number of other programs that need to know e2fsprogs(-lib) instead of ss & com_err and those need to be fixed to before this version of e2fsprogs is marked stable. Someone may want to file bug reports on all those too. There are no intermediate versions that overlap "works with old" and "works with new" (if there are, then they're masked in the tree) as is an important part to allow upgrades to work automatically. Stable cannot depend on unstable. [As an aside, if you want this in the forums, post a link here to the topic there you want, and/or get google to prefer forums.gentoo.org instead of bugs.gentoo.org as there isn't a single link to the forums in the first 10 pages of google hits with "blocks e2fsprogs ss com_err site:gentoo.org"] king0999@mailinator.com 2008-10-30 03:13:03 0000 This bug needs to be left open until the issue is resolved. This needs to be a high priority. Unstabilize e2fsprogs or do whatever it takes until its resolved. This issue is totally unacceptable. When a big problem with a trivial fix is available, you do it. Sure, there may be a better long term solution but you don't have to kill the users with a major pain in the ass just because the developer doesn't know how to revert his stabilization of something that should have remained stable. Mistakes happen. Accidents happen. Fixes should happen as well. Don't close this issue yet. pqGungnir@gmx.de 2008-10-30 03:20:03 0000 Please read the comments first before posting. This issue here is resolved in ~arch. The bug in stable occurred because of bug #244511. wgi@muenster.de 2008-10-30 08:09:56 0000 (In reply to comment #84) > Please read the comments first before posting. This issue here is resolved in > ~arch. The bug in stable occurred because of bug #244511. > I may be wrong, but I think that's entirely correct: new stable mit-krb5-1.6.3-r4 no longer depends on e2fsprogs-libs, OR ss|com_err, but e2fsprogs-libs exclusively, making this even worse. mueli@gentoo.org 2008-10-30 08:53:09 0000 What Do you mean by that? By depending only on e2fsprogs-libs I can enable the upgrade on actual stable portage ... please be more verbose if you argue such reproaches. g, mueli k_javid@hotmail.com 2008-10-30 09:36:17 0000 (In reply to comment #85) > (In reply to comment #84) > > Please read the comments first before posting. This issue here is resolved in > > ~arch. The bug in stable occurred because of bug #244511. > > How is this in any way whatsoever resolved fixed. An emerge -e after a sync and portage update on a fresh install of an amd64 system resulted in the ss com_err blocking e2fsprogs debacle. How has this bug which several mention as a trivial fix spanned an entire half year - is someone getting kicks out of this or something? wgi@muenster.de 2008-10-30 09:48:22 0000 (In reply to comment #86) > What Do you mean by that? By depending only on e2fsprogs-libs I can enable the > upgrade on actual stable portage ... please be more verbose if you argue such > reproaches. Sorry if that was not precise. The new dependency would be fine, if the blocker-resolving portage was stable, which it isn't. Now the deps for mit-krb5 definitely require e2fsprogs-lib, so the workaround listed somewhere above doesn't work anymore. Alternatively, I'm too confused by now. I'll just keep hoping portage gets stabilized quickly ;P genone@gentoo.org 2008-10-30 12:27:36 0000 Reopening for reassignment. genone@gentoo.org 2008-10-30 12:30:07 0000 I don't know why this was assigned to dev-portage in the first place. Mike, deal with it how you prefer, but if you want to reassign it back please provide a comment explaining how this is a portage problem. zmedico@gentoo.org 2008-10-30 17:56:23 0000 (In reply to comment #33) > I'm going to propose some kind of ebuild metadata extension to solve cases like > that. Once we've got that in place, we can add e2fsprogs back to system. Until > then, having e2fsprogs in system is too much of a support nightmare given that > kerberos is enabled by default in the profiles. FWIW, the metadata extension that I've suggested above is available in EAPI 2. With EAPI 2, temporary simultaneous installation is allowed for !atom blockers (even for packages in the system set) and !!atom blockers can be used to explicitly disallow temporary simultaneous installation. gcombe@co.weber.ut.us 2008-10-30 22:24:23 0000 (In reply to comment #91) > (In reply to comment #33) > > I'm going to propose some kind of ebuild metadata extension to solve cases like > > that. Once we've got that in place, we can add e2fsprogs back to system. Until > > then, having e2fsprogs in system is too much of a support nightmare given that > > kerberos is enabled by default in the profiles. > FWIW, the metadata extension that I've suggested above is available in EAPI 2. > With EAPI 2, temporary simultaneous installation is allowed for !atom blockers > (even for packages in the system set) and !!atom blockers can be used to > explicitly disallow temporary simultaneous installation. (In reply to comment #89) > Reopening for reassignment. thank god.. I am so sick of this crap with Gentoo. Everytime i touch a system its some conflict or broken dependency. I swear to good if portage wasnt such a good package mgt system i would so go another distro. tarpman@gmail.com 2008-10-30 22:41:28 0000 I've never actually removed myself from CC on a bug before because of the amount of whining, but this is simply ridiculous. (In reply to comment #92) > thank god.. I am so sick of this crap with Gentoo. Everytime i touch a > system its some conflict or broken dependency. I swear to good if portage > wasnt such a good package mgt system i would so go another distro. Don't let the door hit you on your way out. kentfredric@gmail.com 2008-10-31 02:17:28 0000 (In reply to comment #92) > thank god.. I am so sick of this crap with Gentoo. Everytime i touch a > system its some conflict or broken dependency. I swear to good if portage > wasnt such a good package mgt system i would so go another distro. > Drama? On the internet? So Original. Any time now some bright genius will figure out how to get sarcasm on the internet and I'll never need to leave home. Yeah, so this is a bit annoying. Hardly worth the barrage of 'OMGZTHISSUCKS11!!11SHIFTIMLEAVING' messages. Be nice to the lovely people whom work long hours for free producing a system that rocks. Bugs happen. People create bugs. Get over it. Solve the problem, get on with the future. +1 to every Gentoo developer whom *doesn't* quit from the barrage of abuse they get for the 1 time they slip up, but never get accolade for the dozens of bugs they've solved without so much as a "thankyou". daniel.wuerfel@gmx.net 2008-10-31 04:37:27 0000 (In reply to comment #94) > Be nice to the lovely people whom work long hours for free producing a system > that rocks. Bugs happen. People create bugs. Get over it. Solve the problem, > get on with the future. > > +1 to every Gentoo developer whom *doesn't* quit from the barrage of abuse they > get for the 1 time they slip up, but never get accolade for the dozens of bugs > they've solved without so much as a "thankyou". > Yes, you are right. It's off topic, but "thank you" for the good work to every gentoo developer. I'm a developer too (not gentoo) and i know, that everybody bash you for every little bug, but nobody praise you for the years of good work. ganiman@gmail.com 2008-10-31 15:27:21 0000 So why is this still open? And what is the current fix? ellingsw+20942@gmail.com 2008-11-01 02:22:50 0000 Experiencing the same problem here on stable x86 and I have masked the stated packages. Gentoo was good when I started using it back in 2002/3, but IMHO, it is really starting to go downhill. The powers that be---if there are any left---need to step in and get things straightened out. I may end up having to switch to something else more stable and reliable as I use Linux solely at work and cannot afford downtime. I shutter to think of going back to Debian or its derivatives and their ancient packages. BlinkEye@gmx.ch 2008-11-01 09:56:46 0000 The following solves the blockers: 1. emerge -fDu world (get all packages) 2. emerge -C sys-libs/ss 3. emerge -C sys-libs/com_err 4. Open /var/lib/portage/world and remove sys-libs/ss and sys-libs/com_err 5. emerge --oneshot --nodeps e2fsprogs-libs 6. emerge --oneshot --nodep e2fsprogs yaverot@mail.com 2008-11-02 17:50:36 0000 (In reply to comment #98) > The following solves the blockers: It only resolves blockers (as seen by portage). A revdep-rebuild tries to rebuild e2fsprogs-1.41.2 and fails (it also queued sys-apps/util-linux & xfsprogs to rebuild on my system). e2fschk --version gives: e2fschk: error while loading shared libraries: libblkid.so.1: cannot open shared object file: No such file or directory jacobgodserv@gmail.com 2008-11-03 04:22:25 0000 Beware, sudo users! Be sure you are capable of launching su before removing libcom_err as isntructed in comment #7, since sudo requires that library (and possibly others). My heart skipped a beat when a "sudo emerge ..." command reported a missing library. Hopefully I can save someone else a heart-attack. ;) mullenix@scicable.com 2008-11-03 15:01:04 0000 Responding to comment #98. Doing a fresh install because I hosed up my system when I ran into this little problem. Anyway, I am now getting a libblkid.so.1 error, /proc/mounts is empty, I am unable to get grub to install either manually or automagically, etc, etc. I want to get this system back up and running, as Gentoo has proven to be the best print server I have run across in Linux. I followed these instructions: 1. emerge -fDu world (get all packages) 2. emerge -C sys-libs/ss 3. emerge -C sys-libs/com_err 4. Open /var/lib/portage/world and remove sys-libs/ss and sys-libs/com_err 5. emerge --oneshot --nodeps e2fsprogs-libs 6. emerge --oneshot --nodep e2fsprogs And that is where I'm at at the moment. Off to work for now, will check back here when I get home. Thanks Blinkeye, Lonnie divanorama@gmail.com 2008-11-03 15:19:42 0000 One more workaround is to temporarily use unstable portage. I like it more as it's more automatic and probably more reliable and "right". 1) Unmask it: echo "=app-admin/eselect-news-20080320 **" >> /etc/portage/package.keywords echo "=app-admin/eselect-1.0.11-r1 **" >> /etc/portage/package.keywords echo "=sys-apps/portage-2.2_rc13" >> /etc/portage/package.keywords 2) Resolve with new portage and revert to stable one emerge =sys-apps/portage-2.2_rc13 emerge -uvDN world emerge =sys-apps/portage-2.1.4.5 3) Undo unmasking In 2) maybe just "emerge e2fsprogs-libs e2fsprogs" is enough. I also run etc-update when it was recommended. Now running revdep-rebuild and will try to reboot and check if everything is ok. divanorama@gmail.com 2008-11-03 15:54:14 0000 Wow, system is alive :) Updated version: #Unmask portage: echo "=app-admin/eselect-news-20080320 **" >> /etc/portage/package.keywords echo "=app-admin/eselect-1.0.11-r1 **" >> /etc/portage/package.keywords echo "=sys-apps/portage-2.2_rc13" >> /etc/portage/package.keywords #Resolve with new portage emerge =sys-apps/portage-2.2_rc13 emerge e2fsprogs #will pull all other stuff #reverting back to stable portage vim /etc/portage/package.keywords #undo 3 unmasking made before emerge eselect portage #will complain about all ebuilds of eselect-news masked emerge --unmerge eselect-news #if previous step complained #emerge eselect-news #otherwise revdep-rebuild #probably unnecessary, in my case nothing important was rebuild tom@ritter.vg 2008-11-07 19:15:57 0000 (In reply to comment #103) > Wow, system is alive :) > Updated version: I followed these and after unmasking and updating portage - it was still telling me about the blocked packages, and didn't just automagically go through. zmedico@gentoo.org 2008-11-07 23:13:10 0000 (In reply to comment #104) > I followed these and after unmasking and updating portage - it was still > telling me about the blocked packages, and didn't just automagically go > through. It should resolve automatically now as long as you have >=sys-apps/portage-2.1.5 and /var/lib/portage/world contains neither sys-libs/com_err nor sys-libs/ss. If you still have trouble then please file a new bug and attach emerge --debug output for the case where it bails out due to blockers. stonie.cooper@planetarydata.com 2008-11-08 02:09:09 0000 And within the last comment (#105) lies the problem - at least for me. I have done an emerge --sync, but there is no portage 2.1.5 in the tree: ls /usr/portage/sys-apps/portage/ ChangeLog files portage-2.1.1-r2.ebuild portage-2.2_rc12.ebuild Manifest metadata.xml portage-2.1.4.5.ebuild portage-2.2_rc13.ebuild What gives? zmedico@gentoo.org 2008-11-08 02:38:05 0000 (In reply to comment #106) > I have done an emerge --sync, but there is no portage 2.1.5 in the tree: portage-2.1.5.x never got stablized, so portage-2.2_rc* is the nearest thing in the tree these days. krisztianloki@gmail.com 2008-11-09 02:54:26 0000 Wouldn't it be useful to put something like this into the ss and com_err ebuilds? pkg_prerm() { if built_with_use dev-libs/openssl kerberos && built_with_use net-misc/wget ssl; then eerror "Please re-emerge dev-libs/openssl without the kerberos useflag"; die "Refused to b0rk wget!"; fi } zmedico@gentoo.org 2008-11-09 03:45:05 0000 (In reply to comment #108) > Wouldn't it be useful to put something like this into the ss and com_err > ebuilds? > pkg_prerm() { > if built_with_use dev-libs/openssl kerberos && > built_with_use net-misc/wget ssl; then > eerror "Please re-emerge dev-libs/openssl without the kerberos > useflag"; > die "Refused to b0rk wget!"; > fi > } > You'd have to add a `! has_version sys-libs/e2fsprogs-libs` conditional in order to avoid generating a false alarm when newer portage uninstalls it automatically as shown in comment #37. Also worth noting, it won't help for people who already have the existing ss and com_err ebuilds installed since the pkg_prerm functions come from /var/db/pkg/*/*/environment.bz2 in that case. Side note: If you bork wget then you can use your existing wget sources in $DISTDIR to temporarily rebuild wget with the ssl USE flag disabled. That should allow you to fetch what you need to get things working again. cphil@cphil.net 2008-11-09 06:46:37 0000 (In reply to comment #89) > Reopening for reassignment. > I would just like to thanks all the people who asked for the reopening of this bug. As I checked routinely bugzilla for the blocage, it certainly saved my system. yngwin@gentoo.org 2008-11-13 10:16:38 0000 *** Bug 246581 has been marked as a duplicate of this bug. *** kozlowsm@mini.pw.edu.pl 2008-11-14 07:40:04 0000 (In reply to comment #110) > > (In reply to comment #89) > I would just like to thanks all the people who asked for the reopening of this > bug. > > As I checked routinely bugzilla for the blocage, it certainly saved my system. There is a bug that may seriously damage system during proper system upgrade (if someone doesn't read the forum but follows standard procedures). But its serverity is NORMAL...? kevin.bowling@kev009.com 2008-11-14 18:04:03 0000 I think the easy fix here is to just push portage 2.2 stable as soon as possible. zmedico@gentoo.org 2008-11-14 18:22:14 0000 (In reply to comment #113) > I think the easy fix here is to just push portage 2.2 stable as soon as > possible. I've created a portage-2.1.6 release branch from the same codebase as portage-2.2 and I'm planning to release portage-2.1.6_rc1 this weekend. There's a short discussion about it here: http://archives.gentoo.org/gentoo-portage-dev/msg_4c32326710ea40e1912d85df8ca7d9aa.xml michael@smith-li.com 2008-11-21 23:06:34 0000 (In reply to comment #7) > Here are the steps: > > 1. emerge -NuDav --fetchonly world > 2. emerge -C ss com_err e2fsprogs > 3. emerge -NuDav --nodeps e2fsprogs-libs e2fsprogs > 4. echo "sys-libs/com_err" >>/etc/portage/package.mask > 5. echo "sys-libs/ss" >>/etc/portage/package.mask > 6. echo "sys-libs/com_err-1.40.11" >>/etc/portage/profile/package.provided > 7. echo "sys-libs/ss-1.40.11" >>/etc/portage/profile/package.provided All respect to DrChandra, I think the maskings and package.provided are unnecessary. (Or it could be that they're just no _longer_ necessary) Either way, I'd like to offer an alternative, simpler workaround. quickpkg com_err ss e2fsprogs && emerge -uDNf world && emerge -C com_err ss e2fsprogs && emerge e2fsprogs && emerge -uDN world && revdep-rebuild #(, if necessary) If anything fails, you can always emerge -K from the binary packages. jameswatt@gmail.com 2008-11-22 19:30:18 0000 (In reply to comment #115) > (In reply to comment #7) > > Here are the steps: > > > > 1. emerge -NuDav --fetchonly world > > 2. emerge -C ss com_err e2fsprogs > > 3. emerge -NuDav --nodeps e2fsprogs-libs e2fsprogs > > 4. echo "sys-libs/com_err" >>/etc/portage/package.mask > > 5. echo "sys-libs/ss" >>/etc/portage/package.mask > > 6. echo "sys-libs/com_err-1.40.11" >>/etc/portage/profile/package.provided > > 7. echo "sys-libs/ss-1.40.11" >>/etc/portage/profile/package.provided > All respect to DrChandra, I think the maskings and package.provided are > unnecessary. (Or it could be that they're just no _longer_ necessary) Either > way, I'd like to offer an alternative, simpler workaround. > quickpkg com_err ss e2fsprogs && > emerge -uDNf world && > emerge -C com_err ss e2fsprogs && > emerge e2fsprogs && > emerge -uDN world && > revdep-rebuild #(, if necessary) > If anything fails, you can always emerge -K from the binary packages. Comment 115 fixed my problem I tried EVERY SINGLE comment the whole way through this page and basically wasted my time and was unable to get any of them to work. Then I just copied and pasted this code and it worked!! THANK YOU! xmit@gmx.de 2008-11-22 20:38:51 0000 Same story here. Mr.Smith for president! gentooperson@yahoo.com 2008-11-23 17:36:31 0000 (In reply to comment #115) > (In reply to comment #7) > > Here are the steps: > > > > 1. emerge -NuDav --fetchonly world > > 2. emerge -C ss com_err e2fsprogs > > 3. emerge -NuDav --nodeps e2fsprogs-libs e2fsprogs > > 4. echo "sys-libs/com_err" >>/etc/portage/package.mask > > 5. echo "sys-libs/ss" >>/etc/portage/package.mask > > 6. echo "sys-libs/com_err-1.40.11" >>/etc/portage/profile/package.provided > > 7. echo "sys-libs/ss-1.40.11" >>/etc/portage/profile/package.provided > > All respect to DrChandra, I think the maskings and package.provided are > unnecessary. (Or it could be that they're just no _longer_ necessary) Either > way, I'd like to offer an alternative, simpler workaround. > > quickpkg com_err ss e2fsprogs && > emerge -uDNf world && > emerge -C com_err ss e2fsprogs && > emerge e2fsprogs &&linux-2.6.27-gentoo-r2 > emerge -uDN world && > revdep-rebuild #(, if necessary) > > If anything fails, you can always emerge -K from the binary packages. > What probably happened was: The other packages which depended on com_err and ss were superceded by ones which depend on e2fsprogs-libs. That wasn't the case back when I worked on this. I ran into specific problems which required the addition of the latter four steps. That might also be an explanation for why the steps in comment #7 did not work for some people. ellingsw+20942@gmail.com 2008-11-27 19:26:09 0000 This bug brings up an important question. Should portage be modified to have a fallback fetch command in the event wget is broken? And, as pointed out in comment #3, wget and its fallback (if implemented) should be statically linked. zmedico@gentoo.org 2008-11-27 20:44:21 0000 (In reply to comment #119) > Should portage be modified to have a fallback fetch command in the event wget > is broken? How would it distinguish between a broken wget and a normal failed fetch though? It seems like the user is needed to check the output and recognize that the fetcher is broken. We already have busybox in the system set, so you can replace your broken wget binary with a symlink to busybox when necessary. kentfredric@gmail.com 2008-11-28 00:47:31 0000 (In reply to comment #120) > (In reply to comment #119) > > Should portage be modified to have a fallback fetch command in the event wget > > is broken? > > How would it distinguish between a broken wget and a normal failed fetch > though? It seems like the user is needed to check the output and recognize that You probably could work it out with LDD for the obvious cases of breakages, but how do we handle when LDD is broken, how do we handle when the user doesn't have a working kernel that can connect to the internet etc etc. ? You could possibly also test wget with a minimalist webserver, possibly a perl script, or something like this[1] bash script. But that's getting a bit extreme. Or, seeing emerge is a python script as it is, somebody could write a minimalist fetch utility that doesn't need anything other than a working python, then at least if it were to fail, you would have /much/ bigger problems in the first place. [1] http://paulbuchheit.blogspot.com/2007/04/webserver-in-bash.html ellingsw+20942@gmail.com 2008-11-29 21:30:54 0000 Checking whether wget is broken or not and distinguishing between a normal failed fetch may be simpler than the suggestions in comment #120 and comment #121. From the bash man page: "EXIT STATUS "... A non-zero exit status indicates failure. When a command terminates on a fatal signal N, bash uses the value of 128+N as the exit status. "If a command is not found, the child process created to execute it returns a status of 127. If a command is found but is not executable, the return status is 126." When a library dependency is missing, it is equivalent to the command not being found as far as bash is concerned as indicated below after I renamed libssl.so.0.9.8 to libssl.so.0.9.8.disabled. # ldd $(type -p wget) linux-gate.so.1 => (0xffffe000) libssl.so.0.9.8 => not found libcrypto.so.0.9.8 => /usr/lib/libcrypto.so.0.9.8 (0xb7df1000) librt.so.1 => /lib/librt.so.1 (0xb7de8000) libc.so.6 => /lib/libc.so.6 (0xb7cb8000) libdl.so.2 => /lib/libdl.so.2 (0xb7cb4000) libpthread.so.0 => /lib/libpthread.so.0 (0xb7c9d000) /lib/ld-linux.so.2 (0xb7f67000) # wget -O /dev/null http://www.gentoo.org/; echo Exit Status: $? wget: error while loading shared libraries: libssl.so.0.9.8: cannot open shared object file: No such file or directory Exit Status: 127 When wget is compiled for a different arch than the one it is installed on, bash will return an exit status of 130. # /tmp/usr/bin/wget -O /dev/null http://www.gentoo.org/; echo Exit Status: $? Illegal instruction Exit Status: 132 As for ABI or API changes, I'm sure they will have an exit status above 127 but I cannot simulate it because I don't have old enough binary packages. Now, I don't know python but I would be surprised if it wasn't able to check the exit status of a command and determine that an executable is broken based on its exit status. As for the signals to check for to determine that an executable is broken? I would start with the relevant signals that have an "Action" of "Core" as defined in the signal(7) man page. Oh, I like the idea of a python based fetch utility as long as the dependencies are not burdensome. c4blem0nkey@gmail.com 2008-11-29 22:12:51 0000 Steven in post #119 had a excellent suggestion. Seems the easiest solution would be to statically build wget, would ensure against future breakage and would not require any reworking or additional code else where. With the number of dynamically linked libraries used by wget (openssl, e2fsprog/e2fsprog-libs, mit-krb5) statically linking wget previous to this issue would have made this bug non-existant. Imagine if there is a change in openssl, where they were to fork the libs from the apps, we'd potentially be in the same pickle again, unless wget was statically linked. Sure we're need to rebuild wget after the update of any of it's dependent libs...but I'd be much happier with that... cazort@yahoo.com 2008-12-02 20:13:53 0000 > Actually, this bug has already been fixed. The main problem is that > stabilization of sys-fs/e2fsprogs-1.41.2 has occurred before stabilization of > >=sys-apps/portage-2.1.5 (which is able to resolve the blockers automatically). > Unfortunately, >=sys-apps/portage-2.1.5 is not yet ready for stabilization. How about issuing a small patch to portage before that version, that could be stabilized, if the version as a whole is not yet ready for stabilization? Or is the problem that this fix in portage is complex enough that it's one of the big reasons that version is not stable? zmedico@gentoo.org 2008-12-02 20:55:23 0000 (In reply to comment #124) > How about issuing a small patch to portage before that version, that could be > stabilized, if the version as a whole is not yet ready for stabilization? It's in portage-2.1.6 which will be going stable this month. See bug #249545. cazort@yahoo.com 2008-12-02 21:57:06 0000 I followed these directions, and it fixed the problem, but the last two steps did not work: echo "sys-libs/com_err-1.40.11" >>/etc/portage/profile/package.provided -su: /etc/portage/profile/package.provided: No such file or directory I created the /etc/portage/profile directory...is this the correct course of action? Or have I done something wrong? Thanks! enyawix@yahoo.com 2008-12-05 19:59:43 0000 TYPING "emerge -C sys-apps/coreutils" WILL BREAK YOUR SYSTEM! DO NOT "emerge -C sys-apps/coreutils" TYPING "emerge -C sys-apps/coreutils" WILL BREAK YOUR SYSTEM! You may get a message that looks like sys-apps/mktemp is blocking sys-apps/coreutils sys-apps/coreutils is blocking sys-apps/mktemp DO NOT "emerge -C sys-apps/coreutils" TYPING "emerge -C sys-apps/coreutils" WILL BREAK YOUR SYSTEM! only remove sys-apps/mktemp kozlowsm@mini.pw.edu.pl 2008-12-30 22:14:13 0000 The latest stable portage (portage-2.1.6.4, stable since 29 Dec) deals with this bug :-) Just: # emerge -1 portage # emerge -DuN world and it's OK. cliffb@tracesecurity.com 2009-01-05 16:06:56 0000 (In reply to comment #128) > The latest stable portage (portage-2.1.6.4, stable since 29 Dec) deals with > this bug :-) Just: > # emerge -1 portage > # emerge -DuN world > and it's OK. The way I understand it, you're saying that portage-2.1.6.4 will automatically deal with the com_err & e2fsprogs blocking bug. Unfortunately, I did not find that worked on my system. I have two Gentoo systems. One I did the workaround on, and one I did not. For the system I did not do the workaround on, I haven't run any 'emerge -deep world' updates. When I ran these two commands, the block still exists. I won't copy/paste the other 83 items to be emerged, I'll only include the blockers below: [blocks b ] <sys-fs/e2fsprogs-1.41 ("<sys-fs/e2fsprogs-1.41" is blocking sys-libs/e2fsprogs-libs-1.41.3-r1) [blocks B ] sys-libs/com_err ("sys-libs/com_err" is blocking sys-libs/e2fsprogs-libs-1.41.3-r1) [blocks B ] sys-libs/e2fsprogs-libs ("sys-libs/e2fsprogs-libs" is blocking sys-libs/ss-1.40.9, sys-libs/com_err-1.40.9) [blocks B ] sys-libs/ss ("sys-libs/ss" is blocking sys-libs/e2fsprogs-libs-1.41.3-r1) I've held off on this one system because I heard there would be an elegant solution coming up. Was portage-2.1.6.4 supposed to be it? kozlowsm@mini.pw.edu.pl 2009-01-05 18:39:24 0000 > I've held off on this one system because I heard there would be an elegant > solution coming up. Was portage-2.1.6.4 supposed to be it? It works on all my laptops (3 ones) cliffb@tracesecurity.com 2009-01-05 19:44:48 0000 Ahhh. I found the problem. From an old, old, old hack that predates this problem, I had placed '=app-crypt/mit-krb5-1.6.3-r1' in my /etc/portage/package.keywords, and '=app-crypt/mit-krb5-1.6.3-r4' in package.mask. I forget why I even needed to do it. I didn't comment as much in those days. :-) Removing those did allow portage-2.1.6.4 to solve the block for me automatically. Thanks to everyone who worked on this the past few months! andrew@schaefer.nu 2009-01-06 00:01:42 0000 Comment #115 worked on several of my gentoo boxes, all of which had the same issue. Thanks! ellingsw+20942@gmail.com 2009-01-08 21:41:43 0000 Comment #128 worked like a charm on two of my boxen so far. jacobgodserv@gmail.com 2009-01-10 15:33:57 0000 I'd like to point out that the latest emerge at least recognizes this issue. I haven't yet had the gumption to see if my system breaks if I let it fix it on its own. :) jacobgodserv@gmail.com 2009-01-10 15:35:08 0000 ...and then I'd also like to point out my own stupidity for not reading the latest comments and see you guys've already figured this out. rlippmann@hotmail.com 2009-01-10 17:27:56 0000 I'm still having problems with this (and I'm running portage 2.1.6.4). I don't have kerberos installed at all, in fact I have -kerberos in my /etc/make.conf: emerge --info Portage 2.1.6.4 (default/linux/x86/2008.0/desktop, gcc-4.1.2, glibc-2.6.1-r0, 2.6.26-gentoo-r3 i686) ================================================================= System uname: Linux-2.6.26-gentoo-r3-i686-Intel-R-_Pentium-R-_4_CPU_2.66GHz-with-glibc2.0 Timestamp of tree: Sat, 10 Jan 2009 08:00:02 +0000 distcc 3.0 i686-pc-linux-gnu [disabled] ccache version 2.4 [enabled] app-shells/bash: 3.2_p39 dev-java/java-config: 1.3.7-r1, 2.1.6-r1 dev-lang/python: 2.4.4-r14, 2.5.2-r7 dev-python/pycrypto: 2.0.1-r6 dev-util/ccache: 2.4-r7 dev-util/cmake: 2.4.6-r1 sys-apps/baselayout: 1.12.11.1 sys-apps/sandbox: 1.2.18.1-r2 sys-devel/autoconf: 2.13, 2.63 sys-devel/automake: 1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6-r2, 1.10.2 sys-devel/binutils: 2.18-r3 sys-devel/gcc-config: 1.4.0-r4 sys-devel/libtool: 1.5.26 virtual/os-headers: 2.6.23-r3 ACCEPT_KEYWORDS="x86" CBUILD="i686-pc-linux-gnu" CFLAGS="-O2 -march=pentium4 -fomit-frame-pointer -msse2 -mfpmath=sse -pipe" CHOST="i686-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/kde/3.5/env /usr/kde/3.5/share/config /usr/kde/3.5/shutdown /usr/share/config /var/bind /var/lib/hsqldb" CONFIG_PROTECT_MASK="/etc/ca-certificates.conf /etc/env.d /etc/env.d/java/ /etc/fonts/fonts.conf /etc/gconf /etc/php/apache2-php5/ext-active/ /etc/php/cgi-php5/ext-active/ /etc/php/cli-php5/ext-active/ /etc/revdep-rebuild /etc/terminfo /etc/texmf/web2c /etc/udev/rules.d" CXXFLAGS="-O2 -march=pentium4 -fomit-frame-pointer -msse2 -mfpmath=sse -pipe" DISTDIR="/usr/portage/distfiles" FEATURES="ccache distlocks fixpackages parallel-fetch protect-owned sandbox sfperms strict unmerge-orphans userfetch" GENTOO_MIRRORS="http://mirror.datapipe.net/gentoo http://mirrors.acm.cs.rpi.edu/gentoo/ http://open-systems.ufl.edu/mirrors/gentoo" LDFLAGS="-Wl,-O1" PKGDIR="/usr/portage/packages" PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --stats --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/portage/local/layman/pro-audio /usr/local/portage" SYNC="rsync://rsync.gentoo.org/gentoo-portage" USE="X Xaw3d a52 aac acl acpi alsa apache2 apm asf audiofile avahi berkdb bluetooth branding bzip2 cairo cdda cdio cdparanoia cdr clamav cli cracklib crypt cups curl dbus dga dpms dri dssi dts dvb dvd dvdread encode esd evo exif fam fat ffmpeg fftw firefox flac fuse gdbm gif gimp gmp gphoto2 gpm gstreamer gtk2 hal hfs i8x0 iconv imagemagick imap innodb ipod isdnlog ivtv jack java jpeg jpeg2k kde lash lcms libclamav libnotify lirc live lm_sensors logrotate mad maildir midi mikmod mmx mmxext mng mp3 mpeg mplayer msn mudflap musicbrainz mysql mythtv nas ncurses nls nptl nptlonly nsplugin ntfs ogg opengl openmp oracle pam parport pcre pdf perl pic png ppds pppd python qt3 qt3support qt4 quicktime readline reflection rtc samba scanner sdl session sndfile sound spell spl sqlite sqlite3 sse sse2 ssl startup-notification svg svga sysfs tcpd tetex theora threads tiff transcode truetype unicode usb v4l v4l2 visualization vorbis vst win32codecs wxwindows x86 xfs xine xinerama xml xml2 xorg xosd xscreensaver xulrunner xv xvid xvmc yahoo zlib" ALSA_CARDS="ali5451 als4000 atiixp atiixp-modem bt87x ca0106 cmipci emu10k1 emu10k1x ens1370 ens1371 es1938 es1968 fm801 hda-intel intel8x0 intel8x0m maestro3 trident usb-audio via82xx via82xx-modem ymfpci" ALSA_PCM_PLUGINS="adpcm alaw asym copy dmix dshare dsnoop empty extplug file hooks iec958 ioplug ladspa lfloat linear meter mmap_emul mulaw multi null plug rate route share shm softvol" APACHE2_MODULES="actions alias auth_basic auth_digest authn_anon authn_dbd authn_dbm authn_default authn_file authz_dbm authz_default authz_groupfile authz_host authz_owner authz_user autoindex cache dav dav_fs dav_lock dbd deflate dir disk_cache env expires ext_filter file_cache filter headers ident imagemap include info log_config logio mem_cache mime mime_magic negotiation proxy proxy_ajp proxy_balancer proxy_connect proxy_http rewrite setenvif so speling status unique_id userdir usertrack vhost_alias" ELIBC="glibc" INPUT_DEVICES="keyboard mouse evdev" KERNEL="linux" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" LIRC_DEVICES="hauppauge" USERLAND="GNU" VIDEO_CARDS="i810 i830 i915 vesa fbdev v4l" Unset: CPPFLAGS, CTARGET, EMERGE_DEFAULT_OPTS, FFLAGS, INSTALL_MASK, LANG, LC_ALL, LINGUAS, MAKEOPTS, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS emerge -NuDp world These are the packages that would be merged, in order: Calculating dependencies... done! [ebuild U ] sys-kernel/linux-headers-2.6.27-r2 [2.6.23-r3] [ebuild R ] x11-libs/cairo-1.8.6 USE="-cleartype%" [ebuild N ] sys-libs/e2fsprogs-libs-1.41.3-r1 USE="nls" [ebuild U ] sys-fs/e2fsprogs-1.41.3 [1.40.9] [blocks b ] <sys-fs/e2fsprogs-1.41 ("<sys-fs/e2fsprogs-1.41" is blocking sys-libs/e2fsprogs-libs-1.41.3-r1) [blocks B ] sys-libs/com_err ("sys-libs/com_err" is blocking sys-libs/e2fsprogs-libs-1.41.3-r1) [blocks B ] sys-libs/ss ("sys-libs/ss" is blocking sys-libs/e2fsprogs-libs-1.41.3-r1) [blocks B ] sys-libs/e2fsprogs-libs ("sys-libs/e2fsprogs-libs" is blocking sys-libs/com_err-1.40.9, sys-libs/ss-1.40.9) Even if I package.mask the nfs update, I get the same thing. zmedico@gentoo.org 2009-01-10 19:35:25 0000 Created an attachment (id=177993) show more information for troubleshooting blockers (applies to portage-2.1.6.4) (In reply to comment #136) > I'm still having problems with this (and I'm running portage 2.1.6.4). I don't > have kerberos installed at all, in fact I have -kerberos in my /etc/make.conf: This patch should help when troubleshooting blockers like these. If the patch is saved as /tmp/blocker_info.patch, then it can be applied as follows: patch /usr/lib/portage/pym/_emerge/__init__.py /tmp/blocker_info.patch rlippmann@hotmail.com 2009-01-12 01:17:31 0000 (In reply to comment #137) After I install the patch, I get: emerge -NuDp world These are the packages that would be merged, in order: Calculating dependencies... done! [ebuild N ] sys-libs/e2fsprogs-libs-1.41.3-r1 USE="nls" [ebuild U ] sys-fs/e2fsprogs-1.41.3 [1.40.9] [blocks b ] <sys-fs/e2fsprogs-1.41 ("<sys-fs/e2fsprogs-1.41" is blocking sys-libs/e2fsprogs-libs-1.41.3-r1) [blocks B ] sys-libs/com_err ("sys-libs/com_err" is blocking sys-libs/e2fsprogs-libs-1.41.3-r1) [blocks B ] sys-libs/ss ("sys-libs/ss" is blocking sys-libs/e2fsprogs-libs-1.41.3-r1) [blocks B ] sys-libs/e2fsprogs-libs ("sys-libs/e2fsprogs-libs" is blocking sys-libs/com_err-1.40.9, sys-libs/ss-1.40.9) * Error: The above package list contains packages which cannot be * installed at the same time on the same system. ('installed', '/', 'sys-libs/com_err-1.40.9', 'nomerge') pulled in by ~sys-libs/com_err-1.40.9 required by ('installed', '/', 'sys-libs/ss-1.40.9', 'nomerge') ('installed', '/', 'sys-libs/ss-1.40.9', 'nomerge') pulled in by sys-libs/ss required by world ('ebuild', '/', 'sys-libs/e2fsprogs-libs-1.41.3-r1', 'merge') pulled in by >=sys-libs/e2fsprogs-libs-1.41 required by ('installed', '/', 'sys-apps/util-linux-2.14.1', 'nomerge') ~sys-libs/e2fsprogs-libs-1.41.3 required by ('ebuild', '/', 'sys-fs/e2fsprogs-1.41.3', 'merge') It's greek to me, but I hope it helps someone :) zmedico@gentoo.org 2009-01-12 04:03:25 0000 (In reply to comment #138) > ('installed', '/', 'sys-libs/com_err-1.40.9', 'nomerge') pulled in by > ~sys-libs/com_err-1.40.9 required by ('installed', '/', > 'sys-libs/ss-1.40.9', 'nomerge') > > ('installed', '/', 'sys-libs/ss-1.40.9', 'nomerge') pulled in by > sys-libs/ss required by world You need to remove sys-libs/ss from /var/lib/portage/world. rlippmann@hotmail.com 2009-01-12 04:35:18 0000 (In reply to comment #139) > (In reply to comment #138) > > ('installed', '/', 'sys-libs/com_err-1.40.9', 'nomerge') pulled in by > > ~sys-libs/com_err-1.40.9 required by ('installed', '/', > > 'sys-libs/ss-1.40.9', 'nomerge') > > > > ('installed', '/', 'sys-libs/ss-1.40.9', 'nomerge') pulled in by > > sys-libs/ss required by world > > You need to remove sys-libs/ss from /var/lib/portage/world. > Do you mean manually remove it via vi/nano/whatever, or emerge --unmerge? rlippmann@hotmail.com 2009-01-12 04:40:32 0000 (In reply to comment #140) > (In reply to comment #139) > > (In reply to comment #138) > > > ('installed', '/', 'sys-libs/com_err-1.40.9', 'nomerge') pulled in by > > > ~sys-libs/com_err-1.40.9 required by ('installed', '/', > > > 'sys-libs/ss-1.40.9', 'nomerge') > > > > > > ('installed', '/', 'sys-libs/ss-1.40.9', 'nomerge') pulled in by > > > sys-libs/ss required by world > > > > You need to remove sys-libs/ss from /var/lib/portage/world. > > > > Do you mean manually remove it via vi/nano/whatever, or emerge --unmerge? > Never mind, got it, removed via vi, then ss will be uninstalled by portage. gentoo.bugs@pointb.co.uk 2009-02-12 14:59:17 0000 If your reading this because you have blocking packages on your system then please see this thread: http://forums.gentoo.org/viewtopic-t-712898-highlight-.html Cheers, Rich loki_val@gentoo.org 2009-02-15 01:25:44 0000 *** Bug 259030 has been marked as a duplicate of this bug. *** brian.hales@gatech.edu 2009-09-12 19:09:26 0000 (In reply to comment #115) > quickpkg com_err ss e2fsprogs && > emerge -uDNf world && > emerge -C com_err ss e2fsprogs && > emerge e2fsprogs && > emerge -uDN world && > revdep-rebuild #(, if necessary) > > If anything fails, you can always emerge -K from the binary packages. This list of commands will not work if /proc/ is not mounted. More specificially, the step "emerge e2fsprogs" produces errors. This can be fixed by mounting /proc. Cheers, Brian vapier@gentoo.org 2009-09-13 21:43:25 0000 a lot of random stuff breaks if /proc isnt mounted 177993 2009-01-10 19:35 0000 show more information for troubleshooting blockers (applies to portage-2.1.6.4) blocker_info.patch text/plain SW5kZXg6IHB5bS9fZW1lcmdlL19faW5pdF9fLnB5Cj09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0KLS0tIHB5bS9fZW1lcmdl L19faW5pdF9fLnB5CShyZXZpc2lvbiAxMjQwNykKKysrIHB5bS9fZW1lcmdlL19faW5pdF9fLnB5 CShyZXZpc2lvbiAxMjQwOCkKQEAgLTQ0ODQsNiArNDQ4NCwxMiBAQAogCQlzZWxmLl9pcnJlbGV2 YW50X2Jsb2NrZXJzID0gZGlncmFwaCgpCiAJCSMgQ29udGFpbnMgb25seSB1bnNvbHZhYmxlIFBh Y2thZ2UgLT4gQmxvY2tlciBlZGdlcwogCQlzZWxmLl91bnNvbHZhYmxlX2Jsb2NrZXJzID0gZGln cmFwaCgpCisJCSMgQ29udGFpbnMgYWxsIEJsb2NrZXIgLT4gQmxvY2tlZCBQYWNrYWdlIGVkZ2Vz CisJCXNlbGYuX2Jsb2NrZWRfcGtncyA9IGRpZ3JhcGgoKQorCQkjIENvbnRhaW5zIHdvcmxkIHBh Y2thZ2VzIHRoYXQgaGF2ZSBiZWVuIHByb3RlY3RlZCBmcm9tCisJCSMgdW5pbnN0YWxsYXRpb24g YnV0IG1heSBub3QgaGF2ZSBiZWVuIGFkZGVkIHRvIHRoZSBncmFwaAorCQkjIGlmIHRoZSBncmFw aCBpcyBub3QgY29tcGxldGUgeWV0LgorCQlzZWxmLl9ibG9ja2VkX3dvcmxkX3BrZ3MgPSB7fQog CQlzZWxmLl9zbG90X2NvbGxpc2lvbl9pbmZvID0ge30KIAkJIyBTbG90IGNvbGxpc2lvbiBub2Rl cyBhcmUgbm90IGFsbG93ZWQgdG8gYmxvY2sgb3RoZXIgcGFja2FnZXMgc2luY2UKIAkJIyBibG9j a2VyIHZhbGlkYXRpb24gaXMgb25seSBhYmxlIHRvIGFjY291bnQgZm9yIG9uZSBwYWNrYWdlIHBl ciBzbG90LgpAQCAtNjQ0NCw2ICs2NDUwLDkgQEAKIAkJCQkJCSMgaXMgYWxyZWFkeSBkb25lIGFu ZCB0aGlzIHdvdWxkIGJlIGxpa2VseSB0bwogCQkJCQkJIyBjb25mdXNlIHVzZXJzIGlmIGRpc3Bs YXllZCBsaWtlIGEgbm9ybWFsIGJsb2NrZXIuCiAJCQkJCQljb250aW51ZQorCisJCQkJCXNlbGYu X2Jsb2NrZWRfcGtncy5hZGQocGtnLCBibG9ja2VyKQorCiAJCQkJCWlmIHBhcmVudC5vcGVyYXRp b24gPT0gIm1lcmdlIjoKIAkJCQkJCSMgTWF5YmUgdGhlIGJsb2NrZWQgcGFja2FnZSBjYW4gYmUg cmVwbGFjZWQgb3Igc2ltcGx5CiAJCQkJCQkjIHVubWVyZ2VkIHRvIHJlc29sdmUgdGhpcyBibG9j ay4KQEAgLTY0NjIsNiArNjQ3MSw4IEBACiAJCQkJCQkjIG1lcmdlIG9mIGVpdGhlciBwYWNrYWdl IGlzIHRyaWdnZXJlZC4KIAkJCQkJCWNvbnRpbnVlCiAKKwkJCQkJc2VsZi5fYmxvY2tlZF9wa2dz LmFkZChwa2csIGJsb2NrZXIpCisKIAkJCQkJIyBNYXliZSB0aGUgYmxvY2tpbmcgcGFja2FnZSBj YW4gYmUKIAkJCQkJIyB1bm1lcmdlZCB0byByZXNvbHZlIHRoaXMgYmxvY2suCiAJCQkJCWlmIHBh cmVudC5vcGVyYXRpb24gPT0gIm1lcmdlIiBhbmQgcGtnLmluc3RhbGxlZDoKQEAgLTY1MTQsNyAr NjUyNSw3IEBACiAJZGVmIF9hY2NlcHRfYmxvY2tlcl9jb25mbGljdHMoc2VsZik6CiAJCWFjY2Vw dGFibGUgPSBGYWxzZQogCQlmb3IgeCBpbiAoIi0tYnVpbGRwa2dvbmx5IiwgIi0tZmV0Y2hvbmx5 IiwKLQkJCSItLWZldGNoLWFsbC11cmkiLCAiLS1ub2RlcHMiLCAiLS1wcmV0ZW5kIik6CisJCQki LS1mZXRjaC1hbGwtdXJpIiwgIi0tbm9kZXBzIik6CiAJCQlpZiB4IGluIHNlbGYubXlvcHRzOgog CQkJCWFjY2VwdGFibGUgPSBUcnVlCiAJCQkJYnJlYWsKQEAgLTY5NzcsNiArNjk4OCw3IEBACiAJ CQkJCQkJCQlicmVhawogCQkJCQkJCQlpZiBub3Qgc2F0aXNmaWVkOgogCQkJCQkJCQkJc2tpcCA9 IFRydWUKKwkJCQkJCQkJCXNlbGYuX2Jsb2NrZWRfd29ybGRfcGtnc1tpbnN0X3BrZ10gPSBhdG9t CiAJCQkJCQkJCQlicmVhawogCQkJCQkJZXhjZXB0IHBvcnRhZ2UuZXhjZXB0aW9uLkludmFsaWRE ZXBlbmRTdHJpbmcsIGU6CiAJCQkJCQkJcG9ydGFnZS53cml0ZW1zZygiISEhIEludmFsaWQgUFJP VklERSBpbiAiICsgXApAQCAtNzIwOCw2ICs3MjIwLDc0IEBACiAJCXBvcnRhZ2Uud3JpdGVtc2co IlxuIiwgbm9pc2VsZXZlbD0tMSkKIAkJZm9yIGxpbmUgaW4gd3JhcChtc2csIDcwKToKIAkJCXBv cnRhZ2Uud3JpdGVtc2cocHJlZml4ICsgbGluZSArICJcbiIsIG5vaXNlbGV2ZWw9LTEpCisKKwkJ IyBEaXNwbGF5IHRoZSBjb25mbGljdGluZyBwYWNrYWdlcyBhbG9uZyB3aXRoIHRoZSBwYWNrYWdl cworCQkjIHRoYXQgcHVsbGVkIHRoZW0gaW4uIFRoaXMgaXMgaGVscGZ1bCBmb3IgdHJvdWJsZXNo b290aW5nCisJCSMgY2FzZXMgaW4gd2hpY2ggYmxvY2tlcnMgZG9uJ3Qgc29sdmUgYXV0b21hdGlj YWxseSBhbmQKKwkJIyB0aGUgcmVhc29ucyBhcmUgbm90IGFwcGFyZW50IGZyb20gdGhlIG5vcm1h bCBtZXJnZSBsaXN0CisJCSMgZGlzcGxheS4KKworCQljb25mbGljdF9wa2dzID0ge30KKwkJZm9y IGJsb2NrZXIgaW4gYmxvY2tlcnM6CisJCQlmb3IgcGtnIGluIGNoYWluKHNlbGYuX2Jsb2NrZWRf cGtncy5jaGlsZF9ub2RlcyhibG9ja2VyKSwgXAorCQkJCXNlbGYuX2Jsb2NrZXJfcGFyZW50cy5w YXJlbnRfbm9kZXMoYmxvY2tlcikpOgorCQkJCXBhcmVudF9hdG9tcyA9IHNlbGYuX3BhcmVudF9h dG9tcy5nZXQocGtnKQorCQkJCWlmIG5vdCBwYXJlbnRfYXRvbXM6CisJCQkJCWF0b20gPSBzZWxm Ll9ibG9ja2VkX3dvcmxkX3BrZ3MuZ2V0KHBrZykKKwkJCQkJaWYgYXRvbSBpcyBub3QgTm9uZToK KwkJCQkJCXBhcmVudF9hdG9tcyA9IHNldChbKCJAd29ybGQiLCBhdG9tKV0pCisJCQkJaWYgcGFy ZW50X2F0b21zOgorCQkJCQljb25mbGljdF9wa2dzW3BrZ10gPSBwYXJlbnRfYXRvbXMKKworCQlp ZiBjb25mbGljdF9wa2dzOgorCQkJbXNnID0gW10KKwkJCW1zZy5hcHBlbmQoIlxuIikKKwkJCWlu ZGVudCA9ICIgICIKKwkJCSMgTWF4IG51bWJlciBvZiBwYXJlbnRzIHNob3duLCB0byBhdm9pZCBm bG9vZGluZyB0aGUgZGlzcGxheS4KKwkJCW1heF9wYXJlbnRzID0gMworCQkJZm9yIHBrZywgcGFy ZW50X2F0b21zIGluIGNvbmZsaWN0X3BrZ3MuaXRlcml0ZW1zKCk6CisKKwkJCQlwcnVuZWRfbGlz dCA9IHNldCgpCisKKwkJCQkjIFByZWZlciBjb25mbGljdCBwYWNrYWdlcyBvdmVyIG90aGVycy4K KwkJCQlmb3IgcGFyZW50X2F0b20gaW4gcGFyZW50X2F0b21zOgorCQkJCQlpZiBsZW4ocHJ1bmVk X2xpc3QpID49IG1heF9wYXJlbnRzOgorCQkJCQkJYnJlYWsKKwkJCQkJcGFyZW50LCBhdG9tID0g cGFyZW50X2F0b20KKwkJCQkJaWYgcGFyZW50IGluIGNvbmZsaWN0X3BrZ3M6CisJCQkJCQlwcnVu ZWRfbGlzdC5hZGQocGFyZW50X2F0b20pCisKKwkJCQlmb3IgcGFyZW50X2F0b20gaW4gcGFyZW50 X2F0b21zOgorCQkJCQlpZiBsZW4ocHJ1bmVkX2xpc3QpID49IG1heF9wYXJlbnRzOgorCQkJCQkJ YnJlYWsKKwkJCQkJcHJ1bmVkX2xpc3QuYWRkKHBhcmVudF9hdG9tKQorCisJCQkJb21pdHRlZF9w YXJlbnRzID0gbGVuKHBhcmVudF9hdG9tcykgLSBsZW4ocHJ1bmVkX2xpc3QpCisJCQkJbXNnLmFw cGVuZChpbmRlbnQgKyAiJXMgcHVsbGVkIGluIGJ5XG4iICUgcGtnKQorCisJCQkJZm9yIHBhcmVu dF9hdG9tIGluIHBydW5lZF9saXN0OgorCQkJCQlwYXJlbnQsIGF0b20gPSBwYXJlbnRfYXRvbQor CQkJCQltc2cuYXBwZW5kKDIqaW5kZW50KQorCQkJCQlpZiBpc2luc3RhbmNlKHBhcmVudCwKKwkJ CQkJCShQYWNrYWdlQXJnLCBBdG9tQXJnKSk6CisJCQkJCQkjIEZvciBQYWNrYWdlQXJnIGFuZCBB dG9tQXJnIHR5cGVzLCBpdCdzCisJCQkJCQkjIHJlZHVuZGFudCB0byBkaXNwbGF5IHRoZSBhdG9t IGF0dHJpYnV0ZS4KKwkJCQkJCW1zZy5hcHBlbmQoc3RyKHBhcmVudCkpCisJCQkJCWVsc2U6CisJ CQkJCQkjIERpc3BsYXkgdGhlIHNwZWNpZmljIGF0b20gZnJvbSBTZXRBcmcgb3IKKwkJCQkJCSMg UGFja2FnZSB0eXBlcy4KKwkJCQkJCW1zZy5hcHBlbmQoIiVzIHJlcXVpcmVkIGJ5ICVzIiAlIChh dG9tLCBwYXJlbnQpKQorCQkJCQltc2cuYXBwZW5kKCJcbiIpCisKKwkJCQlpZiBvbWl0dGVkX3Bh cmVudHM6CisJCQkJCW1zZy5hcHBlbmQoMippbmRlbnQpCisJCQkJCW1zZy5hcHBlbmQoIihhbmQg JWQgbW9yZSlcbiIgJSBvbWl0dGVkX3BhcmVudHMpCisKKwkJCQltc2cuYXBwZW5kKCJcbiIpCisK KwkJCXN5cy5zdGRlcnIud3JpdGUoIiIuam9pbihtc2cpKQorCQkJc3lzLnN0ZGVyci5mbHVzaCgp CisKIAkJaWYgIi0tcXVpZXQiIG5vdCBpbiBzZWxmLm15b3B0czoKIAkJCXNob3dfYmxvY2tlcl9k b2NzX2xpbmsoKQogCg==