From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040506
Description of problem:
It was found that in script /etc/X11/xinitrc/xinitrc, it will only
execute those scripts with extension as ".sh".
However, the two scripts (xinput and xmbind) come with the package
doesn't renamed to the correct extension.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Choose A language other than English
2. Choose KDE Desktop
Ack! This change made on Saturday May 8th breaks CJK support for both
XIM and IIIMF methods. It would be VERY embarassing to release FC2
with this problem. I am making and testing a potential update, so
mharris can approve it quickly when he wakes up.
RCS file: /cvs/devel/xinitrc/xinitrc.spec,v
retrieving revision 1.66
diff -u -r1.66 xinitrc.spec
--- xinitrc.spec 7 May 2004 14:22:01 -0000 1.66
+++ xinitrc.spec 10 May 2004 08:32:12 -0000
@@ -38,6 +38,7 @@
rm -rf $RPM_BUILD_ROOT
make DESTDIR=$RPM_BUILD_ROOT install
rm -rf $RPM_BUILD_ROOT
Please downgrade to xinitrc-3.39-1 which works fine. xinitrc-3.40-1
was reverted from the tree because it would require too many other
packages to be changed. Well... two... but they didn't want to risk it.
Ok, me and Jens chatted about this in IRC today and we seem to have
come to a rough decision how to proceed for this issue.
We both believe that having the xinitrc.d directory only process
*.sh scripts is a good idea, much for the same reason it is a good
idea for other directories throughout the system of the form
"foo.d" do the same thing. It prevents random files from being
executed or sourced accidentally, and it is all to possible that
any variety of backup files may exist, including ones with
The question then is how we should proceed to make the change. We
know of 2 scripts in Fedora Core 2 that break with this change
currently, one of which is in the openmotif package.
If we were to fix xinput to xinput.sh, and to fix the openmotif
package, then we'd need to issue erratum for all 3 packages for FC2,
which is definitely doable.
There may however be other lurking issues that we have not forseen
and which may come back to haunt us a few days/weeks/months later,
such as a 3rd party package plopping a script in the dir that does
not end in .sh, causing it to break. Jens and I both believe that
it would be very bad to have an erratum update break something
in a stable cycle in this manner.
The other alternative we have is to push an updated package into
updates-testing, which would shield things a bit for a while until
we find out if anything breaks. In order to get a reasonable
guarantee however, we'd be best to leave it in testing for a few
weeks, and if we do that, we might as well just do it in rawhide
instead, where we /can/ break things in a reasonable manner.
It may be useful to get feedback from fedora-devel-list also
tpb package from fedora.us creates /etc/X11/xinit/xinitrc.d/tpb file,
which would stop working after those changes.
Anl, can't the tpb script be renamed to tpb.sh?
Mike, you still haven't renamed xinput.sh in xinitrc-3.41. :-/
The latest incarnation of tpb in the fedora.us QA queue has been
"fixed" wrt this, thanks to Ani for the heads up.
(I think it's a good idea to limit xinitrc.d processing to *.sh only.)
Ville, that is nice to hear! However xinitrc and openmotif
still haven't been fixed!! :-(
Changing product version to 2 since xinitrc-3.41 went into fc2-updates.
*** Bug 125205 has been marked as a duplicate of this bug. ***
openmotif has been fixed: so that just leaves xinput...
Sorry, the fix for FC2 was in 3.42-1: 4.0.1-1 is for FC-devel.