Brazilian ABNT-2 Keyboard got messed in the last fedora update.
Particularly quotation mark-stroke key got dead (so there are no ways to
write pathnames). Number pad became really the number-pad (no home,
arrows or other functions). Combination of control+alt+function-key
don't switch to console ...
The xorg-x11-xkbdata package up until version 1.0.1-4 contained
xkb data from the upstream X.Org official "xkbdata" tarball which
was part of the X11R7.0 release.
Ever since X.Org reformed, the primary XFree86 xkbdata maintainers
split out xkbdata into a separate project on freedesktop.org, so
they could maintain the data in one location for all open source
X11 implementations (primarily X.Org X11, and XFree86). The new
project was named "xkeyboard-config" and is in the "xkbdesc"
CVS module on freedesktop.org.
However, since then, both X.Org and XFree86 have shipped the
traditional xkbdata that they've always shipped, and have not
updated to using the new xkeyboard-config data. As such, what
has happened, is that the xkbdata in both projects has rotted,
with not much maintenance happening, and when bugs get reported
for xkbdata, the problems get fixed in xkeyboard-config if they're
present there also, and the bugs get marked closed in bugzilla.
Unfortunately, the users never see the bugfixes because neither
X project ships the xkeyboard-config data, and most distributions
ship what X.Org or XFree86 has provided.
There is fairly broad concensus that xkeyboard-config data is
"the future", and also that xkbdata from X.Org is more or less
totally unmaintained and abandoned. One might ask "why did they
ship abandoned unmaintained xkbdata instead of shipping
xkeyboard-config then?", and that's a good question. I don't
know the 100% authoritative answer, but I believe it was because
it was too big of a change at the time, plus the fact that the 7.0
and 6.9 releases had to be the same codebase, and that it wouldn't
be easy to integrate everything into 6.9.
Anyway the long and the short of it is that the GNOME project,
and I believe the KDE project as well, have standardized upstream
on using/expecting xkeyboard-config data present on the system,
and a whole slew of nasty problems happen if you're using the
X.Org or XFree86 unmaintained data.
As such, since xkeyboard-config is the future, and is very
actively maintained right now, we have decided to switch to using
it in FC5, so long as there are no major unresolveable regressions
between now and the final package build date. It is too late to
change package names, or to add new package names to the OS, so I
had to assimilate the xorg-x11-xkbdata package with the
xkeyboard-config tarball. Other than that it should be a drop-in
The new package (1.0.1-5) containing xkeyboard-config is now in
rawhide, so you're all going to be using it tomorrow. Many thanks
to the people who tested the pre-rawhide packages.
Please note that since the new data files have not been part of
the Fedora development process until now, so there could be some
problems potentially. Please be sure to reconfigure your keyboards
with the gnome keyboard applet, and generally pound on it.
If you experience bugs/problems with the new xkbdata, please report
them in the X.Org bugzilla at http://bugs.freedesktop.org, in the
"xkbdesc" component, and select version "0.7" if it is visible in
bugzilla. Once you've filed your bug in X.Org bugzilla, feel free
to file a tracking bug in Red Hat bugzilla also if you wish, and
we'll track the problem for FC5 as well. There will be a new
version released soon that we'll be updating too, hopefully before
FC5 final as well.
This should resolve various keyboard quirks that have been reported
in different components throughout FC5 testing, but may introduce
a few new bugs too. Overall, since it is the only maintained
xkbdata however, even if there are a few bumps, they'll be ironed
out via modular package updates easily enough, unlike the situation
we'd have if we shipped the X.Org xkbdata and let it rot.
Hope your keyboards all do the happy dance now.
Mike A. Harris * Open Source Advocate * http://mharris.ca
I have latest evolution packages from rawhide and have configured an
Fetching summary information for new messages seems quite slow.
For example, if I:
- open evolution and let synchronize inbox folder (3500 messages and
116MB in size)
- then I'm able to work well
- close evolution
- open evolution immediately after
- it takes quite much time (about 2 minutes) to redo fetch of summary
information (to fetch actually nothing) and in the mean time I have
the right screen for inbox contents that is empty, so that I'm not
able to see any past message and so on
I would like to have this fetch operation (that in my test btw should
be in some way instantaneous) done in background and start work with
my previous inbox e-mails at least.
Is there a setting I have to provide in configuration for exchange
account in evolution, or can I post as a bug? Where, upstream or
This software is for individual Fedora users and sys-admins who need
to update one or more Fedora systems that are connected to the
internet with low to medium bandwidth link (eg dialup, ISDN,
Not long after a new Fedora Core release, the bandwidth required to
update a fresh installation can become burdensome for low/medium
bandwidth internet connections. Some update RPMs can be over 80 MBytes
in size, yet the update may be almost identical to the original RPM on
the distribution disk.
This software presents two solutions to administrators of Fedora systems:
1. A HTTP service which acts as a virtual update RPM repository. It
update RPMs by downloading a small 'patch' or 'delta' file and
applying it to locally stored RPMs from the original distribution.
2. A command line tool which can regenerate an update RPM repository
from a delta repository + RPMs from the original distribution.
In addition to the virtual update repository, this software
distribution also contains the tools needed to create and maintain a
delta repository. I have also made an experimental
delta repository which is open to testers (subject to sufficient bandwidth).
Requirements and limitations:
* This system uses Michael Schroeder's deltarpm system and must be
installed (documented in the installation instructions)
* Java (tested with the Fedora free stack and Sun Java)
* For the HTTP service you need tomcat5 (the version in the Fedora
distribution will work)
* For delta repository generation you need lots of RAM to process some
of the larger RPMs (eg OpenOffice core). 512MB just about works with
some page faulting, 1024MB+ recommended.
0.2.0 (28 Feb 2006)
This question is specifically about the installonlyn plugin,
but is also a question regarding yum plugin packaging in general.
Currently I see the installonlyn plugin included in the fedora
yum-2.5 srpm, but was expecting to see it in the extras yum-utils,
since I have seen other plugins within the yum-utils including
changelog and fastestmirror.
Is placing installonlyn within yum just a one off, or are certain
plugins going to make it into yum, while others are in yum-utils?
Currently it is a bit confusing, since I am expecting to look
for plugins in yum-utils and would be more inclined to add a
plugin to yum-utils, rather than yum.
On Tue, 31 Jan 2006 22:04:59 +0100 Gianluca Cecchi wrote:
>> Asap I'll reboot ala windows and see if anything changes... ;-(
Actually I did:
- init 3
- yum update of other latest packages
- init 5
- re-login in gnome as gcecchi
- plug digicamera
- all ok now!
Are these known, do they need bugzilla reports?
1. Firstboot won't launch. There is a python traceback (something about
gtk?) that flashes by on the screen.
2. system-config-display won't launch, gives error:
Traceback (most recent call last):
File "/usr/share/system-config-display/xconf.py", line 22, in ?
ImportError: No module named gobject
3. Running "yum install kernel-devel" resulted in:
Loading "installonlyn" plugin
Setting up Install Process
Setting up repositories
development 100% |=========================| 1.1 kB 00:00
extras-development 100% |=========================| 1.1 kB 00:00
Reading repository metadata in from local files
primary.xml.gz 100% |=========================| 1.2 MB 00:04
developmen: ################################################## 4282/4282
Added 4282 new packages, deleted 0 old in 12.05 seconds
primary.xml.gz 100% |=========================| 1.3 MB 00:11
extras-dev: ################################################## 3643/3643
Added 3643 new packages, deleted 0 old in 12.15 seconds
python: Modules/gcmodule.c:240: update_refs: Assertion `gc->gc.gc_refs == (-3)' failed.
4. Evolution. When defining a mail account with the initial wizard and
selecting that SMTP authentication is required, the SMTP auth setting
doesn't stick. Later trying to send email fails and checking the account
details show that SMTP auth is not selected.
5. Evolution broken icons. Inside Evolution launched from the Edit menu,
the Evolution Preferences window has vertical column of icons on the
left. The icons "Mail Accounts", "Autocompletion", and "Calendar and
Tasks" look like a sheet of paper with a big red X in the middle.
On Fri, 17 Feb 2006 10:49:40 +0100 Gianluca Cecchi <gianluca cecchi gmail com>
>I cannot do "rpm -e GConf-1.0.9-18" because I get the same error as below.
>On Thu, 9 Feb 2006 07:58:28 -0800 Tom London <selinux gmail com> wrote:
>>I get this installing today:
>> Cleanup : GConf ##################### [351/638]
>>/sbin/ldconfig: relative path `1' used to build cache
>>error: %postun(GConf-1.0.9-18.i386) scriptlet failed, exit status 1
>> Cleanup : hdparm ##################### [352/638]
Just for tracking, I solved the problem using command
rpm -e --noscripts
GConf-1.0.9-18 and GConf-1.0.9-18.1
so now I have only one GConf package in RPMDB.
Does exist analog switch for yum? I didn't find so.