Bug 234907 – 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

• Status: RESOLVED WORKSFORME
• Product: Gentoo Linux

[Description Reinhard Kreim 2008-08-16 11:25:27 UTC]

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

[Comment 1 Rafał Mużyło 2008-08-16 11:34:55 UTC]

Of course, it's not possible.
sys-libs/e2fsprogs-libs is sys-libs/ss+sys-libs/com_err,
so this is invalid.

[Comment 2 Andrej Filipcic 2008-08-16 12:17:50 UTC]

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.

[Comment 3 Andreas Arens 2008-08-16 13:11:29 UTC]

(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!
 

[Comment 4 Jose daLuz 2008-08-16 13:56:08 UTC]

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...

[Comment 5 Kent Fredric (IRC: kent\n) (RETIRED) 2008-08-16 16:07:06 UTC]

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 /

[Comment 6 Oskar Ellström 2008-08-16 18:14:41 UTC]

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.

[Comment 7 DrChandra the Gentoo Person 2008-08-16 20:29:52 UTC]

(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.

[Comment 8 Izad-Yar Daniel Rasheed 2008-08-17 02:52:53 UTC]

#7 resolved this block on my ~amd64 system -- thanks!

[Comment 9 Kent Fredric (IRC: kent\n) (RETIRED) 2008-08-17 07:32:26 UTC]

(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. 

[Comment 10 Kent Fredric (IRC: kent\n) (RETIRED) 2008-08-17 08:07:22 UTC]

--- 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. :)

[Comment 11 Mark Tiefenbruck 2008-08-17 08:38:31 UTC]

I can confirm that the steps in #7 work, apart from needing 5.5: mkdir
/etc/portage/profile on my system.

[Comment 12 Panagiotis Christopoulos (RETIRED) 2008-08-17 08:41:58 UTC]

(In reply to comment #10)

> ...
> Fixes my problem. :)
> 

This was already fixed (bug 234885) ...

[Comment 13 Panagiotis Christopoulos (RETIRED) 2008-08-17 09:29:45 UTC]

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.

[Comment 14 Panagiotis Christopoulos (RETIRED) 2008-08-17 09:44:40 UTC]

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. 

[Comment 15 Graham Murray 2008-08-17 10:03:14 UTC]

(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 

[Comment 16 Graham Murray 2008-08-17 10:04:48 UTC]

oops, should also have said I am running ~x86

[Comment 17 Panagiotis Christopoulos (RETIRED) 2008-08-17 11:56:01 UTC]

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. 

[Comment 18 Panagiotis Christopoulos (RETIRED) 2008-08-17 13:06:22 UTC]

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.

[Comment 19 Renato Caldas 2008-08-17 18:15:54 UTC]

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.

[Comment 20 Zac Medico 2008-08-17 18:36:02 UTC]

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.

[Comment 21 Zac Medico 2008-08-17 18:40:02 UTC]

(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.

[Comment 22 Harris Landgarten 2008-08-17 18:55:14 UTC]

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

[Comment 23 Zac Medico 2008-08-17 20:15:03 UTC]

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.

[Comment 24 Neil 2008-08-18 06:07:50 UTC]

(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.

[Comment 25 Arun Raghavan (RETIRED) 2008-08-18 08:47:21 UTC]

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

[Comment 26 Kent Fredric (IRC: kent\n) (RETIRED) 2008-08-18 10:31:04 UTC]

(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. 

[Comment 27 DrChandra the Gentoo Person 2008-08-18 13:39:11 UTC]

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.

[Comment 28 DrChandra the Gentoo Person 2008-08-18 13:41:19 UTC]

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?

[Comment 29 DrChandra the Gentoo Person 2008-08-18 13:43:08 UTC]

(In reply to comment #28)
> As an experiment, I tried the steps in comment #21, but got this:
> 
I meant comment #20.

[Comment 30 DrChandra the Gentoo Person 2008-08-18 14:22:03 UTC]

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.

[Comment 31 Zac Medico 2008-08-18 19:19:50 UTC]

(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.

[Comment 32 SpanKY 2008-08-19 01:10:05 UTC]

leaving e2fsprogs out of system set is not a long term solution ... it provides "fsck" which is clearly "system"

[Comment 33 Zac Medico 2008-08-19 02:45:55 UTC]

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.

[Comment 34 Michael Hammer (RETIRED) 2008-08-19 13:04:46 UTC]

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

[Comment 35 Michael Hammer (RETIRED) 2008-08-19 13:05:33 UTC]

btw - why didn't anybody added [e-mail] to CC list?

[Comment 36 frilled 2008-08-20 08:11:30 UTC]

(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)

[Comment 37 Zac Medico 2008-08-20 16:32:23 UTC]

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'.

[Comment 38 Michael Evans 2008-08-21 11:50:36 UTC]

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

[Comment 39 Harris Landgarten 2008-08-21 12:48:18 UTC]

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)

[Comment 40 Michael Evans 2008-08-21 14:02:19 UTC]

(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.

[Comment 41 Harris Landgarten 2008-08-21 14:08:54 UTC]

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.

[Comment 42 Zac Medico 2008-08-21 18:58:03 UTC]

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.

[Comment 43 Thomas Anderson (tanderson) (RETIRED) 2008-08-26 18:41:52 UTC]

*** Bug 235619 has been marked as a duplicate of this bug. ***

[Comment 44 Thomas Anderson (tanderson) (RETIRED) 2008-08-26 18:47:28 UTC]

@Zac: This bug was never anything wrong with paludis.

@All: This is now fixed in CVS.

[Comment 45 Jeroen Roovers (RETIRED) 2008-09-02 18:12:04 UTC]

*** Bug 236475 has been marked as a duplicate of this bug. ***

[Comment 46 Volker Hemmann 2008-09-06 06:49:48 UTC]

@44 'fixed in cvs' does not mean 'fixed in the tree' right?
Because I just ran into it(it:this bug).

[Comment 47 Zac Medico 2008-09-06 16:28:49 UTC]

(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.

[Comment 48 Gasper Azman 2008-09-10 17:58:14 UTC]

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

[Comment 49 Zac Medico 2008-09-10 18:21:42 UTC]

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. 

[Comment 50 Kent Fredric (IRC: kent\n) (RETIRED) 2008-09-10 23:54:29 UTC]

(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?
   

[Comment 51 Zac Medico 2008-09-11 00:19:25 UTC]

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).

[Comment 52 Zac Medico 2008-09-11 00:24:11 UTC]

Kerberos maintainers, can we get your opinion on comment #19 and comment #20?

[Comment 53 Zac Medico 2008-09-11 00:25:16 UTC]

(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.

[Comment 54 Michael Hammer (RETIRED) 2008-09-11 06:52:53 UTC]

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)

[Comment 55 Michael Hammer (RETIRED) 2008-09-11 06:58:22 UTC]

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

[Comment 56 Zac Medico 2008-09-11 07:11:05 UTC]

(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.

[Comment 57 Michael Hammer (RETIRED) 2008-09-11 12:23:29 UTC]

I've removed the old libs and depend direct on e2fsprogs-libs in >=mit-krb5-1.6.3-r4

[Comment 58 Jeremy Gove 2008-09-12 16:01:57 UTC]

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?

[Comment 59 Zac Medico 2008-09-12 16:25:20 UTC]

(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).

[Comment 60 Jeroen Roovers (RETIRED) 2008-09-13 17:11:07 UTC]

*** Bug 237550 has been marked as a duplicate of this bug. ***

[Comment 61 Rob MacKinnon 2008-09-25 20:11:19 UTC]

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?

[Comment 62 Rob MacKinnon 2008-09-25 20:13:19 UTC]

tacking myself on to the CC...

[Comment 63 Zac Medico 2008-09-25 21:28:52 UTC]

(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.

[Comment 64 Michael Duelli 2008-10-27 22:06:15 UTC]

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.

[Comment 65 Scott McClung 2008-10-28 01:06:11 UTC]

(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.

[Comment 66 frilled 2008-10-28 07:06:07 UTC]

(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 ...

[Comment 67 Ortwin Glueck 2008-10-28 09:22:03 UTC]

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!

[Comment 68 Ville Oikarinen 2008-10-28 09:37:16 UTC]

Waiting for a proper fix (CC), delaying emerge world

[Comment 69 Zac Medico 2008-10-28 09:44:18 UTC]

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

[Comment 70 stupendoussteve 2008-10-28 10:03:12 UTC]

(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).

[Comment 71 Rodrigo Severo 2008-10-28 10:14:16 UTC]

(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.

[Comment 72 Jan Marten Simons 2008-10-28 12:16:26 UTC]

I also opt for reopenng this bug as it's affecting stable now.

[Comment 73 Stonie R. Cooper 2008-10-28 15:14:32 UTC]

Yes, this bug is not fixed, and needs to be reopened.  Stable versions are now being recursively blocked.

[Comment 74 Zac Medico 2008-10-28 16:29:52 UTC]

(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

[Comment 75 the_mgt 2008-10-28 17:25:49 UTC]

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!!!

[Comment 76 Doug Goldstein (RETIRED) 2008-10-28 17:34:28 UTC]

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.

[Comment 77 Joseph 2008-10-28 17:40:09 UTC]

(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

[Comment 78 Jeroen Roovers (RETIRED) 2008-10-29 03:38:37 UTC]

*** Bug 244842 has been marked as a duplicate of this bug. ***

[Comment 79 Till Korten 2008-10-29 10:10:13 UTC]

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!!!

[Comment 80 Marek Kozlowski 2008-10-29 10:25:31 UTC]

A critical bug (unresolved dependecies) still exists in the stable tree (x86). Who has marked it FIXED?!

[Comment 81 Andrea (Ben) Benini 2008-10-29 10:38:44 UTC]

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

[Comment 82 yaverot 2008-10-30 01:16:03 UTC]

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"]

[Comment 83 The Dude 2008-10-30 03:13:03 UTC]

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.

[Comment 84 Matthias Liebig 2008-10-30 03:20:03 UTC]

Please read the comments first before posting. This issue here is resolved in ~arch. The bug in stable occurred because of bug #244511.

[Comment 85 frilled 2008-10-30 08:09:56 UTC]

(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.

[Comment 86 Michael Hammer (RETIRED) 2008-10-30 08:53:09 UTC]

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

[Comment 87 Kayvan Javid 2008-10-30 09:36:17 UTC]

(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? 

[Comment 88 frilled 2008-10-30 09:48:22 UTC]

(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

[Comment 89 Marius Mauch (RETIRED) 2008-10-30 12:27:36 UTC]

Reopening for reassignment.

[Comment 90 Marius Mauch (RETIRED) 2008-10-30 12:30:07 UTC]

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.

[Comment 91 Zac Medico 2008-10-30 17:56:23 UTC]

(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.

[Comment 92 Glen Combe 2008-10-30 22:24:23 UTC]

(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.

[Comment 93 Ryan Tandy 2008-10-30 22:41:28 UTC]

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.

[Comment 94 Kent Fredric (IRC: kent\n) (RETIRED) 2008-10-31 02:17:28 UTC]

(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".  

[Comment 95 ebuc99 2008-10-31 04:37:27 UTC]

(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. 

[Comment 96 Chris Manigan 2008-10-31 15:27:21 UTC]

So why is this still open? And what is the current fix?

[Comment 97 Steven Elling 2008-11-01 02:22:50 UTC]

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.

[Comment 98 BlinkEye 2008-11-01 09:56:46 UTC]

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 

[Comment 99 yaverot 2008-11-02 17:50:36 UTC]

(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

[Comment 100 Jacob Godserv 2008-11-03 04:22:25 UTC]

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. ;)

[Comment 101 Lonnie Mullenix 2008-11-03 15:01:04 UTC]

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

[Comment 102 Dmitry Ivankov 2008-11-03 15:19:42 UTC]

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.

[Comment 103 Dmitry Ivankov 2008-11-03 15:54:14 UTC]

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

[Comment 104 Tom 2008-11-07 19:15:57 UTC]

(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.

[Comment 105 Zac Medico 2008-11-07 23:13:10 UTC]

(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.

[Comment 106 Stonie R. Cooper 2008-11-08 02:09:09 UTC]

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?

[Comment 107 Zac Medico 2008-11-08 02:38:05 UTC]

(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.

[Comment 108 Krisztian Loki 2008-11-09 02:54:26 UTC]

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
}

[Comment 109 Zac Medico 2008-11-09 03:45:05 UTC]

(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.

[Comment 110 Philippe Coulonges 2008-11-09 06:46:37 UTC]

(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.

[Comment 111 Ben de Groot (RETIRED) 2008-11-13 10:16:38 UTC]

*** Bug 246581 has been marked as a duplicate of this bug. ***

[Comment 112 Marek Kozlowski 2008-11-14 07:40:04 UTC]

(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...? 

[Comment 113 Kevin Bowling 2008-11-14 18:04:03 UTC]

I think the easy fix here is to just push portage 2.2 stable as soon as possible.

[Comment 114 Zac Medico 2008-11-14 18:22:14 UTC]

(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

[Comment 115 [e-mail] 2008-11-21 23:06:34 UTC]

(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 116 James Watt 2008-11-22 19:30:18 UTC]

(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!

[Comment 117 Martin Gramatke 2008-11-22 20:38:51 UTC]

Same story here. Mr.Smith for president!

[Comment 118 DrChandra the Gentoo Person 2008-11-23 17:36:31 UTC]

(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.

[Comment 119 Steven Elling 2008-11-27 19:26:09 UTC]

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.

[Comment 120 Zac Medico 2008-11-27 20:44:21 UTC]

(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.

[Comment 121 Kent Fredric (IRC: kent\n) (RETIRED) 2008-11-28 00:47:31 UTC]

(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

[Comment 122 Steven Elling 2008-11-29 21:30:54 UTC]

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.

[Comment 123 Rob MacKinnon 2008-11-29 22:12:51 UTC]

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...

[Comment 124 Alex Zorach 2008-12-02 20:13:53 UTC]

> 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?

[Comment 125 Zac Medico 2008-12-02 20:55:23 UTC]

(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.

[Comment 126 Alex Zorach 2008-12-02 21:57:06 UTC]

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!

[Comment 127 wayne 2008-12-05 19:59:43 UTC]

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 

[Comment 128 Marek Kozlowski 2008-12-30 22:14:13 UTC]

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.

[Comment 129 Cliff Barbier 2009-01-05 16:06:56 UTC]

(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?

[Comment 130 Marek Kozlowski 2009-01-05 18:39:24 UTC]

> 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) 

[Comment 131 Cliff Barbier 2009-01-05 19:44:48 UTC]

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! 

[Comment 132 Andrew Schaefer 2009-01-06 00:01:42 UTC]

Comment #115 worked on several of my gentoo boxes, all of which had the same issue.  Thanks!

[Comment 133 Steven Elling 2009-01-08 21:41:43 UTC]

Comment #128 worked like a charm on two of my boxen so far.

[Comment 134 Jacob Godserv 2009-01-10 15:33:57 UTC]

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. :)

[Comment 135 Jacob Godserv 2009-01-10 15:35:08 UTC]

...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.

[Comment 136 Robert Lippmann 2009-01-10 17:27:56 UTC]

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.

[Comment 137 Zac Medico 2009-01-10 19:35:25 UTC]

Created attachment 177993 [details, diff]
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

[Comment 138 Robert Lippmann 2009-01-12 01:17:31 UTC]

(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 :)

[Comment 139 Zac Medico 2009-01-12 04:03:25 UTC]

(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.

[Comment 140 Robert Lippmann 2009-01-12 04:35:18 UTC]

(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?

[Comment 141 Robert Lippmann 2009-01-12 04:40:32 UTC]

(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.

[Comment 142 Richard Scott 2009-02-12 14:59:17 UTC]

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

[Comment 143 Peter Alfredsen (RETIRED) 2009-02-15 01:25:44 UTC]

*** Bug 259030 has been marked as a duplicate of this bug. ***

[Comment 144 Brian Hales 2009-09-12 19:09:26 UTC]

(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

[Comment 145 SpanKY 2009-09-13 21:43:25 UTC]

a lot of random stuff breaks if /proc isnt mounted

[Comment 146 James alan 2021-11-22 12:58:47 UTC]

hi guys, just fixed the issue with version 2.1 hope this helps


* app-crypt/mit-krb5
* app-crypt/heimdal
* net-mail/fetchmail
* sci-mathematics/gimps