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
|
Bug#:
234907
|
Product: Gentoo Linux
|
Version: unspecified
|
Platform: x86
|
|
OS/Version: Linux
|
Status: RESOLVED
|
Severity: normal
|
Priority: P2
|
|
Resolution: WORKSFORME
|
Assigned To: base-system@gentoo.org
|
Reported By: reini@crimer.de
|
|
Component: Core system
|
|
|
URL:
|
|
Summary: 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
|
|
Keywords:
|
|
Status Whiteboard:
|
|
Opened: 2008-08-16 11:25 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
Of course, it's not possible.
sys-libs/e2fsprogs-libs is sys-libs/ss+sys-libs/com_err,
so this is invalid.
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.
(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!
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...
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 /
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.
(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.
#7 resolved this block on my ~amd64 system -- thanks!
(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.
--- 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. :)
I can confirm that the steps in #7 work, apart from needing 5.5: mkdir
/etc/portage/profile on my system.
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.
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.
(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
oops, should also have said I am running ~x86
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.
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.
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.
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.
(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.
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
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.
(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.
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
(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.
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.
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?
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.
(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.
leaving e2fsprogs out of system set is not a long term solution ... it provides
"fsck" which is clearly "system"
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.
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
(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)
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'.
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
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)
(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.
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.
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.
*** Bug 235619 has been marked as a duplicate of this bug. ***
@Zac: This bug was never anything wrong with paludis.
@All: This is now fixed in CVS.
*** Bug 236475 has been marked as a duplicate of this bug. ***
@44 'fixed in cvs' does not mean 'fixed in the tree' right?
Because I just ran into it(it:this bug).
(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.
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
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.
(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?
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).
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)
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
(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.
I've removed the old libs and depend direct on e2fsprogs-libs in
>=mit-krb5-1.6.3-r4
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?
(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).
*** Bug 237550 has been marked as a duplicate of this bug. ***
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?
tacking myself on to the CC...
(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.
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.
(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.
(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 ...
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!
Waiting for a proper fix (CC), delaying emerge world
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
(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).
(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.
I also opt for reopenng this bug as it's affecting stable now.
Yes, this bug is not fixed, and needs to be reopened. Stable versions are now
being recursively blocked.
(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
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!!!
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.
(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
*** Bug 244842 has been marked as a duplicate of this bug. ***
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!!!
A critical bug (unresolved dependecies) still exists in the stable tree (x86).
Who has marked it FIXED?!
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
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"]
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.
Please read the comments first before posting. This issue here is resolved in
~arch. The bug in stable occurred because of bug #244511.
(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.
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
(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?
(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
Reopening for reassignment.
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.
(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 #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.
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.
(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".
(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.
So why is this still open? And what is the current fix?
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.
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
(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
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. ;)
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
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.
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
(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.
(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.
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?
(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.
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
}
(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.
(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.
*** Bug 246581 has been marked as a duplicate of this bug. ***
(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...?
I think the easy fix here is to just push portage 2.2 stable as soon as
possible.
(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.
(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!
Same story here. Mr.Smith for president!
(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.
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.
(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.
(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
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.
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...
> 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?
(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.
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!
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
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.
(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?
> 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)
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 #115 worked on several of my gentoo boxes, all of which had the same
issue. Thanks!
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. :)
...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.
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.
Created an attachment (id=177993) [details]
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
(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 :)
(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.
(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?
(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.
*** Bug 259030 has been marked as a duplicate of this bug. ***
(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
a lot of random stuff breaks if /proc isnt mounted
