The command `dircolors -b' produces a harmful code 'rs=0', among with many legal codes, in prefix portage. The code causes applications to refuse to work, for example mrxvt prints the diagnostic "Unknown colorls variable `rs'", and xterm just silently dies at startup. I have been noticing the latter fact for many weeks, with no clue as to the underlying reason. See http://bugs.gentoo.org/show_bug.cgi?id=233941 for a report on the mrxvt issue. It is also interesting to note that the 'rs' code is not listed on this webpage: <http://www.bigsoft.co.uk/blog/index.php/2008/04/11/configuring-ls_colors?blog=3>. According to that page there is no official documentation of the LS_COLORS codes, maybe this is in fact so. The rs=0 code has not always been there. When investigating a prefix tree bootstrapped on the same platform 2008-04-03 it turns out that two codes have disappeared since then (no=00, fi=00) and one code has been introduced (rs=0). The respective coreutils versions are 6.10-r1 and 6.12-r1. The problem may not be reproducible in every prefixed portage installation. Here are the details of my environment (see also emerge --info below): - host is x86-linux - Prefix tree bootstrapped 2008-08-14 - TERM is xterm - shell in use is bash I will keep the two prefix trees dated 2008-04-03 and 2008-08-14 for some time so that config files etc can be compared if needed. The info of the 2008-08-14 tree: Portage 2.2.00.11391-prefix (default-prefix/linux/x86, gcc-4.2.4, unavailable, 2.6.16.53-0.16-smp i686) ================================================================= System uname: Linux-2.6.16.53-0.16-smp-i686-Intel-R-_Core-TM-2_CPU_6600_@_2.40GHz-with-SuSE-10-i586 Timestamp of tree: Thu, 14 Aug 2008 00:51:30 +0000 ccache version 2.4 [disabled] app-shells/bash: 3.2_p39 dev-java/java-config: 1.3.7-r00.1, 2.1.6-r1 dev-lang/python: 2.5.2-r7 sys-apps/sandbox: 1.2.17 sys-devel/autoconf: 2.13, 2.61-r2 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.1-r1 sys-devel/binutils: 2.18.50.0.7 sys-devel/gcc-config: 1.4.0-r04.5 sys-devel/libtool: 1.5.26 ACCEPT_KEYWORDS="~x86-linux" CBUILD="i686-pc-linux-gnu" CFLAGS="-O2 -pipe" CHOST="i686-pc-linux-gnu" CONFIG_PROTECT="/etc" CONFIG_PROTECT_MASK="/etc/ca-certificates.conf /etc/env.d /etc/env.d/java/ /etc/fonts/fonts.conf /etc/gconf /etc/revdep-rebuild /etc/terminfo" CXXFLAGS="-O2 -pipe" DISTDIR="/local/tmp/nightly/2008-08-14/usr/portage/distfiles" EPREFIX="/local/tmp/nightly/2008-08-14" FEATURES="collision-protect distlocks parallel-fetch preserve-libs sandbox sfperms strict unmerge-orphans userfetch" GENTOO_MIRRORS="http://mirror.gentoo.no/ http://mirror.qubenet.net/mirror/gentoo/ http://mirror.muntinternet.net/pub/gentoo/ http://ftp.linux.ee/pub/gentoo/distfiles/ http://ftp.snt.utwente.nl/pub/os/linux/gentoo" LANG="en_US" LDFLAGS="" MAKEOPTS="-j2" PKGDIR="/local/tmp/nightly/2008-08-14/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="/local/scratch" PORTDIR="/local/tmp/nightly/2008-08-14/usr/portage" SYNC="rsync://rsync.prefix.freens.org/gentoo-portage-prefix" USE="X cracklib iconv midi mudflap ncurses nls openmp prefix readline ssl unicode x86 zlib" 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" KERNEL="linux" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" USERLAND="GNU" Unset: CPPFLAGS, CTARGET, EMERGE_DEFAULT_OPTS, INSTALL_MASK, LC_ALL, LINGUAS, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS, PORTDIR_OVERLAY
Created attachment 162865 [details] Differences in `emerge --info' output between 2008-04-03 and 2008-08-14 Differences in `emerge --info' output between 2008-04-03 and 2008-08-14.
http://forums.gentoo.org/viewtopic-t-699584.html?sid=9e0e88062520aede30c912769b60076c this forum thread suggests rs=0 is not prefix specific, and that RESET (would that be rs?) is introduced in a newer coreutils. It may have been introduced for you, as side effect of a fix in dircolors calling code that previously was not called due to a bug.
Some more thoughts, written in parallel with your entry Fabian, There is an array ls_codes[] in dircolors.c, defined at line 69. A number of initial values are given. In the coreutils-6.12-r1 version there is a value "rs" at line 71; in the 6.10-r1 version this value is not present. The array slack_codes[], defined at line 60, appears to be related to ls_codes[]. In the 6.12-r1 version the initial value "RESET" has been introduced in the position that matches "rs". The ChangeLog of coreutils does not mention dircolors. Looking upstream, at <http://git.savannah.gnu.org/gitweb/?p=coreutils.git;a=history;f=src/dircolors.c;h=79109b93455762f988c79eca44ea31ada455dd8a;hb=HEAD>, it seems that "rs" appeared 2008-02-17 (Jim Meyering, "Adjust dircolors to match ls.c"). So, obviously "rs" was introduced for some good reason, yet it causes problems in prefix portage. Would it be a solution to simply revert to an older version of coreutils? I notice that a native Gentoo box of mine (not running ~x86 but otherwise up-to-date) has coreutils-6.10-r2.
Well, for me it works fine, so I guess something of the host system is involved here that doesn't grok it. Another workaround would be to override LS_COLORS by setting an entry in your homedir which doesn't have the rs=0. I think a strace of xterm or mrxvt would be useful to identify what they're opening.
Created attachment 162877 [details] strace from launch of mrxvt when LS_COLORS contains rs=0 Here it is, 2284 lines, without having looked closely at it yet.
(In reply to comment #0) > The command `dircolors -b' produces a harmful code 'rs=0', among with many > legal codes, in prefix portage. Do you have references that say how it is harmful besides the error for you with xterm/mrxvt? It is hard to "point fingers" at the error when both grobian and I cannot reproduce this. Also, xterm not starting is kinda a big deal and no one else has brought this up. I agree with grobian, maybe the best solution here is for you to make your own .dir_colors file in $HOME since even you stated that this may not be reproducible on any other host. =/ With that being said, it is rather disturbing that this happened 'all of a sudden' and left you without a usable terminal one day. *shrugs*
Some new insight today, I have been using a bash wrapper of my own since the "startprefix" script is not entirely practical in my tcsh-heavy host environment. My bash wrapper did not reset SHELL in the environment so its value was /bin/tcsh, which is a 6.14.00 tcsh that doesn't understand "rs=0". A better way to start a prefix shell for me (with the intention of running bash, to have less interactions with the host environment) is something like this: tcsh> setenv EPREFIX /local/tmp/nightly/2008-08-15 tcsh> cd $EPREFIX tcsh> set path = ($EPREFIX/usr/local/bin $EPREFIX/usr/bin \ $EPREFIX/bin $EPREFIX/usr/sbin $EPREFIX/sbin $path) tcsh> setenv MANPATH $EPREFIX/usr/share/man:$MANPATH tcsh> unsetenv PKG_CONFIG_PATH tcsh> setenv SHELL /bin/bash tcsh> exec ./startprefix The LS_COLORS now includes the rs=0 code. Having done so, xterm starts with no problem! And so does mrxvt. The previously seen message "Unknown colorls variable `rs'" in mrxvt was most likely produced by tcsh. Not all terminal applications are happy though. For x11-terms/terminal-0.2.8 the command `terminal' refuses to start the application until I clear the rs=0 code from LS_COLORS.
how about: env SHELL=tcsh ./startprefix ? I'm a tcsh user, sometimes having to use bash as well, and that's how I do it. Anyone who knows what he/she is doing is welcome not to use startprefix, but my rule of thumb in environment problems like these is that if you don't use startprefix, I won't fix it, unless the same happens when using the startprefix script. Reason for this is that your "workaround" doesn't nearly do as much as startprefix. And it needs all those environment settings. Having SHELL point to /bin/tcsh is also poisonous, since anything that spawns a new shell (vim, mutt, screen, etc. etc.) will spawn the wrong shell, with misc environment problems as result. I think your problem is just one of them, which also explains why we couldn't reproduce. Just emerge your shell of choice and use ./startprefix. Solve problems afterwards (your pkgconfig for example, which indeed is a legitimate problem). Should we fix that in ./startprefix script?
> Should we fix that in ./startprefix script? Clearing PKG_CONFIG_PATH seems like a good idea. What are your thoughts about PATH and MANPATH? Since startprefix knows where the prefix tree is it could ensure that the prefix path components are included.
It does, but I suspect your .tcshrc or .bashrc to override them.
Precisely, this is what happens for tcsh over here. I wish I would have figured out the `env SHELL=bash startprefix' invocation, it would have saved me some trouble. And you and Jeremy--thanks indeed for your patience.
I did a quick check on all terminals in x11-terms. They all emerge nicely. Usability is quite good too: pssh: not really a terminal? tilda: hangs when launching, unrelated to rs=0 terminal: refuses to start if rs=0 present, as reported before aterm, clusterssh, kterm, mrxvt, uxterm, xterm, gnome-terminal all work (for gnome-terminal one may have to emerge corefonts too, #235553). So there are a bunch of usable terminals to choose from. It is fine with me to close this bug with no action. (Someone might consider to report a problem for the combination of coreutils-6.12-r1 and x11-terms/terminal-0.2.8 of course?)
This is an incompatibility between the latest coreutils and tcsh. It was also reported here: https://qa.mandriva.com/show_bug.cgi?id=40532 There's an ad-hoc patch to tcsh there as part of the grander mdvsys patch. Regards, -- Shlomi Fish
This is not about tcsh. Gentoo already has the mentioned patch for tcsh for quite some time now. Anyway, thanks for the suggestion. I'll close this bug now as per the suggestion of the previous poster.
