Is anyone else having issues with the LSI Fusion SPI host driver
(mptspi.ko) on rawhide ?
rawhide is running as VMware guest OS. mptspi loads but fails to
correctly scan any of the connected disk. I had to change the VM disk
from scsi/lsilogic to an ide drive to be able to boot. I'll check with
the VMWare folks as well.
I notice that Jindrich Novy (tetex packages maintainer) is away until
27th March. Jindrich had previously mentioned his intention to move to
TeXLive for F7, due to tetex being unmaintained and quite out of date.
Is this still the intention? It would be useful to know from both a
user and packager perspective if there's any kind of roadmap in place
as some of you know, I'd prefer to have a separate mailing list for
discussions around EPEL. I didn't bring that topic up much until now,
but two people in private mails heavily insisted to have a special EPEL
mailing list. So I'm trying to move this discussion here.
Do you guys want a separate mailing list for EPEL?
The usual advantages and disadvantages apply. Maily: Users that are only
interested in EPEL don't have to subscribe to a mailinglist that has 95%
of traffic they are not interested in (advantage). Yet another mailing
list, where we need to get people that are interested subscribed while
most Fedora Contrbutors are already subscribed to fedora-devel
I'd like to propose a small change that involves many Fedora packages.
(First I thought I'd put it in bugzilla, but I don't know what the right
component would be.)
The proposed change is the following: when building RPM packages, let's
convert all .mo files (gettext translations) to UTF-8.
- As Fedora is a fully UTF-8 system, applications are likely to request
translations in UTF-8. (There might be a few applications that are
exceptions, and some users may have special setup or special wrappers to
run certain applications in some other charset, but in the vast majority
of the cases gettext is required to return UTF-8 string.)
If the .mo file is already in UTF-8, the gettext() call simply returns a
pointer pointing somewhere in the area where the .mo file is mmap()ed to.
This can simply be checked with strace. This way no run-time conversion
happens and no per-proecess memory is involved; translations are shared by
all the processes that use the same message catalog.
If, however, .mo file uses a different encoding, gettext() has to allocate
memory for the converted string and has to perform the conversion. This
way if more processes display the same localized string, they all allocate
their own memory area to store the UTF-8 version of the string and they
all perform the charset conversion. And actually they all load the
corresponding gconv module which could be avoided, too.
To summarize, having all the .mo files in UTF-8 would save both memory and
- Currently the encoding of the .mo files is completely arbitrary; it is
always what the software developers or the translators happened to use.
With this change, it would be consistently UTF-8. This would make it
easier to find which package ships a particular translation. It often
happens that I want to locate which package a particular message comes
from. It might happen because a word is misspelled, or because the whole
message shouldn't appear and I'd like to fix the buggy package. The
obvious solution is to do a recursive grep on /usr/share/locale/<lang>. If
all the .mo files of the distribution are converted to UTF-8, I can do it
simply, without having to worry about accented characters. (grep in UTF-8
mode works fine and finds the matching UTF-8 .mo files even though they
are not fully valid UTF-8 files, the UTF-8 strings are surrounded by other
binary data.) However, if multiple encodings are used, there is no
straightforward way to find accented letters, it becomes a much harder
- Due to RPM's flexibility, none of the packages needs to be modified, only
the RPM macros. I recommend to perform the conversion on the .mo files
after the '%install' step (in '%__install_post' or whatever it's called),
this way this whole story is independent from the package's build
procedure (does it use autotools or not; does it re-generate .mo files
from .po or ships pre-built .mo files; no need to worry about faulty and
hence skipped .po files; no need to take care of non-standard places of
po/mo files within the source tree; etc...)
- The only thing that needs to be done is an "msgunfmt" followed by "msgconv
-t UTF-8" and finally "msgfmt" for all the .mo files under the standard
- So, after all, it is _very_ easy to implement it.
Is it safe?
- The encoding inside the .mo files is completely transparent to the
applications as gettext() and its friends always convert the strings to
the charset requested by the application. So applications won't notice any
- We performed this step when building all the packages of the UHU-Linux 2.0
distribution, which was released a half year ago, and so far no known
problems arised. (During the test period there was only 1 package (namely
coreutils) where the converted .mo files were corrupted, but as it turned
out, it was caused by a bug in msgunfmt in gettext-0.15, which is already
fixed in gettext-0.16.)
- Not known by me, except for a negligible growth in the packages' sizes.
Well, I hope you like my idea :-)
I'd like to see all traces of no.po removed from the modules where
fedora is upstream. These were replaced by nb.po a while back and I've
added replacements to all modules AFAIR.
You probably also have to remove traces of these in the build like
ALL_LINGUAS in configure.in|ac etc.
I d like to report a kernel oops, but I don't know how to catch the
After an upgrade to kernel 2.6.19-1.2911, the system crashes at boot. I
didn't had this problem with 2.6.19-1.2895 version. I didn't found such
a bug in the bugzilla.
Is it possible to save the stacktrace in order to fill a bug report ?
How can I do that ?
Thanks in advance.
The bittorrent (and bittorrent-gui) package has been downgraded in the
Extras development repo from version 5.0.5 to 4.4.0, due to
compatibility problems between the GUI and wxPython 2.8.x
(http://bugzilla.redhat.com/223623). Since bittorrent upstream is still
doing development on wxPython 2.6, there is little prospect of a fix for
this before FC7 release, so the package has been downgraded to the last
version that had a working (pygtk2-based) GUI.
As this is still the development phase of the release, the downgrade was
done without an epoch bump, so:
MANUAL DOWNGRADE WILL BE NEEDED IF YOU USE THE bittorrent PACKAGE ON