When trying to run emerge --depclean with the --pretend or --ask option, 2 bugs come out: 1. It reports that there is no world file. 2. It tries to unmerge most of the packages at your system. Will add more info soon... Reproducible: Always
Just wanted to say that when with the --ask option it also outputs this: superuser access is required... adding --pretend to options. Sorry I didn't told this from the first post but I thought I didn't have the time cause I had to go ;) . Anyway, these are all. I don't think anything else is needed...
Not here. Post your emerge --info output, and the exact emerge command you run and the output you get.
(In reply to comment #2) > Not here. Post your emerge --info output, and the exact emerge command you run > and the output you get. > My emerge --info output: Portage 2.1.3.16 (default-linux/x86/2007.0, gcc-4.1.2, glibc-2.6.1-r0, 2.6.22-gentoo-r8 i686) ================================================================= System uname: 2.6.22-gentoo-r8 i686 Intel(R) Pentium(R) 4 CPU 3.20GHz Timestamp of tree: Wed, 31 Oct 2007 20:20:01 +0000 app-shells/bash: 3.2_p17 dev-lang/python: 2.4.4-r6 dev-python/pycrypto: 2.0.1-r6 sys-apps/baselayout: 1.12.9-r2 sys-apps/sandbox: 1.2.18.1-r2 sys-devel/autoconf: 2.13, 2.61-r1 sys-devel/automake: 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6-r2, 1.10 sys-devel/binutils: 2.18-r1 sys-devel/gcc-config: 1.3.16 sys-devel/libtool: 1.5.24 virtual/os-headers: 2.6.22-r2 ACCEPT_KEYWORDS="x86" CBUILD="i686-pc-linux-gnu" CFLAGS="-O2 -march=i686 -pipe" CHOST="i686-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/share/X11/xkb" CONFIG_PROTECT_MASK="/etc/env.d /etc/fonts/fonts.conf /etc/gconf /etc/revdep-rebuild /etc/terminfo /etc/udev/rules.d" CXXFLAGS="-O2 -march=i686 -pipe" DISTDIR="/usr/portage/distfiles" FEATURES="distlocks metadata-transfer sandbox sfperms strict unmerge-orphans userfetch" GENTOO_MIRRORS="ftp://ftp.uoi.gr/mirror/OS/gentoo/ ftp://ftp.ntua.gr/pub/linux/gentoo/ " MAKEOPTS="-j2" PKGDIR="/usr/portage/packages" PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --delete-after --stats --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages --filter=H_**/files/digest-*" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" SYNC="rsync://rsync.europe.gentoo.org/gentoo-portage" USE="X acl alsa berkdb bitmap-fonts cdr cli cracklib crypt cups dri dvd dvdr fortran gdbm gnome gpm gtk hal iconv ipv6 isdnlog midi mudflap ncurses nls nptl nptlonly openmp pam pcre perl pppd python readline reflection session spell spl ssl tcpd truetype-fonts type1-fonts unicode x86 xorg 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 mulaw multi null plug rate route share shm softvol" ELIBC="glibc" INPUT_DEVICES="keyboard mouse" KERNEL="linux" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" USERLAND="GNU" VIDEO_CARDS="radeon" Unset: CPPFLAGS, CTARGET, EMERGE_DEFAULT_OPTS, INSTALL_MASK, LANG, LC_ALL, LDFLAGS, LINGUAS, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS, PORTDIR_OVERLAY And what to do exactly to reproduce it: Run as normal user (not root) the commend emerge --pretend --depclean. Then what i told before will happen. Here is the output of that command when running it as normal user (so when the bug appears): http://pastebin.com/f70582406 Here is the output of the command when running it as root: http://pastebin.com/feb86760 I believe that this is caused because the world file is not accessible to normal users. Thus the solution should be to output "emerge: superuser access is required." when someone tries to execute that command as normal user.
Never refer to pastebins in bugs, please. We have attachments feature for this.
Created attachment 134957 [details] Output when running it as normal user
Created attachment 134959 [details] Output when running it as root user
Ok, sry for that. I attached them. Now, what about the bug?
`ls -la /var/lib/portage/world` output, please.
(In reply to comment #8) > `ls -la /var/lib/portage/world` output, please. > -rw-r--r-- 1 root portage 459 Oct 31 22:16 /var/lib/portage/world
I'm not sure why portage does not make /var/lib/portage readable by all, especially considering that /var/db/pkg is already readable by all. Does anybody see a reason not to make the default permissions for /var/lib/portage readable by all? We can just make it so that portage no longer explicitly removes those bits. That way, anybody will be able to read it by default on new installs, but people can still remove those bits if they want to hide their world file.
As the code is already, you should be able to `chmod o+rx /var/lib/portage` in order to get the desired behavior. In svn it's now fixed so that portage won't explicitly remove those permission bits. Administrators can explicitly chmod o-rx that directory if necessary, and portage will leave those bits alone.
This has been released in 2.1.3.18.
OK, nice :)
I have upgraded to version 2.1.3.19 of portage and the problem still exists (world file still writable by root only). Any ideas? Was it not fixed or sth alike?
It's not supposed to change the permissions for you. The default permissions will only be different for new installations (probably starting with 2007.1, but it depends on the process used to create stages). Until then, users will have to set the permissions manually by running `chmod o+rx /var/lib/portage`. After you've done that once, you should be able to run `emerge --pretend --depclean` without any special privileges.
I meant owned by root and only he can view the file. Anyway, I suspected that but you told it was fixed in portage 2.1.3.18 .
Anyway, I marked it fixed.
(In reply to comment #16) > I meant owned by root and only he can view the file. Hmm, are you saying that the permissions were correct on the /var/lib/portage directory, but the the permissions on the world file itself were too restrictive? I suppose that could happen if you have a restrictive umask and then run `emaint --fix world`, which would create a new world file using your current umask setting. I can fix that by adding a umask call inside of emaint, similar to the one that emerge does.
(In reply to comment #18) > (In reply to comment #16) > > I meant owned by root and only he can view the file. > > Hmm, are you saying that the permissions were correct on the /var/lib/portage > directory, but the the permissions on the world file itself were too > restrictive? I suppose that could happen if you have a restrictive umask and > then run `emaint --fix world`, which would create a new world file using your > current umask setting. I can fix that by adding a umask call inside of emaint, > similar to the one that emerge does. > No, never mind, just something I confused :) .
