in /usr/X11R6/bin/startx: if [ -f $userclientrc ]; then defaultclientargs=$userclientrc elif [ -f $sysclientrc ]; then defaultclientargs=$sysclientrc fi this is not good, because /etc/X11/xinit/xinitrc itself sources ~/.xinitrc, so why is the use of the system-wide xinitrc not allowed if a per-user settings exists. this causes problems like ~/.Xmodmap isnt used and so on. Reproducible: Always Steps to Reproduce: 1.install 4.3.0-r5 2.create own ~/.xinitrc 3.startx Actual Results: for me, my .Xmodmap wasnt used any more and even not the System-wide xmodmap and so my AltGr key remains unusable as I am using the German layout this is not good :/ Expected Results: use /etc/X11/xinit/xinitrc in ALL cases. if a ~/.xinitrc exists, this will be handeld in /etc/X11/xinit/xinitrc there is no need to do so in startx Portage 2.0.50-r1 (default-x86-1.4, gcc-3.3.2, glibc-2.3.2-r9, 2.6.2-gentoo-r1) ================================================================= System uname: 2.6.2-gentoo-r1 i686 mobile AMD Athlon(tm) XP 2200+ Gentoo Base System version 1.4.3.13 Autoconf: sys-devel/autoconf-2.58-r1 Automake: sys-devel/automake-1.7.7 ACCEPT_KEYWORDS="x86" AUTOCLEAN="yes" CFLAGS="-O3 -march=athlon-xp -fforce-addr -fomit-frame-pointer -funroll-loops -frerun-cse-after-loop -frerun-loop-opt -falign-functions=4" CHOST="i686-pc-linux-gnu" COMPILER="gcc3" CONFIG_PROTECT="/etc /usr/X11R6/lib/X11/xkb /usr/kde/2/share/config /usr/kde/3/share/config /usr/share/config /var/qmail/control" CONFIG_PROTECT_MASK="/etc/gconf /etc/env.d" CXXFLAGS="-O3 -march=athlon-xp -fforce-addr -fomit-frame-pointer -funroll-loops -frerun-cse-after-loop -frerun-loop-opt -falign-functions=4" DISTDIR="/usr/portage/distfiles" FEATURES="autoaddcvs ccache sandbox" GENTOO_MIRRORS="ftp://ftp.uni-erlangen.de/pub/mirrors/gentoo" MAKEOPTS="-j2" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="" SYNC="rsync://rsync.europe.gentoo.org/gentoo-portage" USE="3dnow X aalib acl acpi acpi4linux alsa apache2 avi berkdb cdr chroot clamav crypt cscope cups dedicated dga dillo directfb dvd encode esd etwin exiscan exiscan-acl fbcon fbdev foomaticdb foreign-package foreign-sysvinit freetype fs gd gdbm geoip gif gimpprint gtk gtk2 imagemagick imap imlib imlib2 ipv6 irda jabber java javascript jbig jikes jpeg libg++ libwww lirc mad maildir md5sum migemo mikmod mmx motif moznocompose moznoirc moznomail mpeg mpeg4 msn mysql nas ncurses net nls nntp oggvorbis opengl operanom2 oscar pam pcmcia pdflib perl php png python qt quicktime readline samba sasl sdl slang snmp spell sse ssl svga tcltk tcpd tcsim transcode truetype usb videos vim-with-x wmf wxwindows x86 xine xml2 xmms xosd xv xvid yahoo zlib"
Same here. This seems very illogical. I know the default startx is just a example/template: (from /usr/bin/startx) # This is just a sample implementation of a slightly less primitive # interface than xinit. It looks for user .xinitrc and .xserverrc # files, then system xinitrc and xserverrc files, else lets xinit choose # its default. The system xinitrc should probably do things like check # for .Xresources files and merge them in, startup up a window manager, # and pop a clock and serveral xterms. # But the "example" startx should be consistent with the rest of the system. One solution would be to change the file that the global xinitrc uses from ~/.xinitrc to (for example) ~/.xsession. This is better than just removing the if clause that handles the user .xinitrc because the user should be (IMHO) able to override the global xinitrc.
Created attachment 63099 [details, diff] Change the order that resources are loaded This patch will cause startx to look for the system files first and then the user files. This seems to make sense as the system files will look for and use the user's files if they exist. Personally I don't want this patch and it contradicts the startx man page. If this is not accepted, then why does /etc/X11/xinit/xinitrc even bother to look for a file in the user's home directory (startx tried that first). It should just fall through to the chooser. The cleanest solution would be to have the user's ~/.xinitrc source /etc/X11/xinit/xinitrc for any additions but in that case the system file should NOT then try to source the user's file or we will create an infinite loop.
(In reply to comment #2) > The cleanest solution would be to have the user's ~/.xinitrc source > /etc/X11/xinit/xinitrc for any additions but in that case the system file > should NOT then try to source the user's file or we will create an infinite > loop. [I have to pipe in on this...] This suggestion above is how it should work; the system xinitrc should not be run unless the user does not have an ~/.xinitrc; users who want anything in the system xinitrc should either source it or copy the parts they like.
+if [ -f $sysclientrc ]; then defaultclientargs=$userclientrc wtf? Are you sure this is what you meant to post ? Well if this is still marked as new after 2 yrs I guess no-one's bothered to look at it anyway.
(In reply to comment #4) > > Well if this is still marked as new after 2 yrs I guess no-one's bothered to > look at it anyway. > Or more likely, everybody who does know how these things actually are supposed to work, is fed up with Gentoo's greediness/dishonesty. More often than not, they'll sell user supplied patches as a Gentoo invention and claim full credit for it. Remember two years ago, when people were forced to (implicitely) sign over copyright to any code (see my comments in bug #49455) attached to bugs.gentoo.org? After that didn't work out, it got worse: now they're just taking people's intellectual property and claim it's Gentoo's own work! Example 1: xserver Everybody remember bug #96053? Would still be around if it hadn't been for a patch by a non Gentoo person, despite my warning to be careful. Supposedly applied on 3rd October 2005. No trace in Xorg changelog to be found! Example 2: imake Gentoo changelog dishonestly claims: #v+ *imake-1.0.2 (20 May 2006) 20 May 2006; Donnie Berkholz <spyderous@gentoo.org>; -files/0128_all_4.2.0-imake-tmpdir-v2.patch, -imake-1.0.1.ebuild, -imake-1.0.1-r1.ebuild, +imake-1.0.2.ebuild: Bump. Incorporates 0128_all_4.2.0-imake-tmpdir-v2.patch, finally -- years after azarah wrote it. #v- Xorg changelog dishonestly claims: #v+ 2006-04-08 Donnie Berkholz <spyderous@gentoo.org> reviewed by: Adam Jackson * imake.c: (get_libc_version): Allow specifying TMPDIR environment variable to use instead of /tmp, for systems on which /tmp is mounted noexec (Martin Schlemmer). #v- Truth is, this patch is due to a non Gentoo person after it was discovered that Schlemmer's patch sucks elephant balls! Yet Gentoo claims they've come up with it all by themselves! Need more examples? There's plenty more. I said this before and I'll say it again: Be careful, people. Just write your own X startup scripts. I've seen hundreds of people who have done so. It's not that hard. Just don't put those up at bugs.gentoo.org if you don't want to lose control over your own code.
Please take your rants somewhere other than Bugzilla, I have no interest in reading them.
Oh, as a further note, if I've made a mistake, please point out where I can find the correct information and I will be happy to fix it.
(In reply to comment #6) > Please take your rants somewhere other than Bugzilla, > Nah, I think one slashdot coverage per month is enough. Maybe later. > I have no interest in reading them. > Right, stick your fingers in your ears. Also, abusive attitude noted. I'm afraid I'll have to let you do your own homework now. (In reply to comment #7) > Oh, as a further note, if I've made a mistake, please point out where I can > find the correct information > Well it's not my code that's been stolen, so to be honest, I couldn't care less if you don't know your own sources. But since I already gave you two examples that you have no interest in reading, what would be the point to provide more of them? > and I will be happy to fix it. > I'll believe that when I see it happen. Until then, I'll continue to believe these aren't mistakes, and not recommend Gentoo to my clients.
Could you be a bit less hypocritical about abusive attitudes? I've done research every time I've attributed something, I'm clearly not making mistakes on purpose.
Created attachment 100059 [details] moo no further comment in 3 weeks so this can be closed invalid then heres a picture of duck dodgers
I just finally tracked this down too, I think it needs to be fixed. The proposed patch is only partially complete but I think the idea is correct - the system xinitrc should be run first, and then that will run the user's own .xinitrc, where they're free to override anything the system script may have done. Alternatively if ~/.xsession is the best place to put things, there are a lot of docs that need to be updated...
There's nothing of value in the system's xinitrc that can't be done directly inside a user's .xinitrc. xrdb and xmodmap (the latter is deprecated...) can be called by the user script. Thanks
