On Sat, 2006-12-16 at 10:19 +0000, Paul wrote:
> hunspell is in rawhide. I can see that. OOo requires hunspell-en though.
> Is this just a mistake on packaging hunspell or is it a problem with OOo
> and more over, when is a fix going to appear in rawhide for it?
Should all be good today, I jumped the gun on requiring hunspell-en
before it was actually available.
hunspell is the package which provides the spell checking library used
by OOo and the hunspell command line tool
hunspell-en is the package which provides the english dictionaries which
the OOo core requires, just as the core bundles the english resources as
the effective "C" final fallback locale.
All the noise is to kick off the master plan to reduce our dictionary
madness a bit for fc7 (rhbz#207571) or at least to enable this.
So hunspell has been moved out of OOo (rhbz#214764) and now the english
dictionaries have been moved out as well (rhbz#218769). Which will
enable firefox/thunderbird to reuse the same dictionaries if tweaked to
use hunspell instead of myspell and the firefox/thunderbird dictionary
dir is linked to /usr/share/myspell (rhbz#218762). Current
firefox/thunderbird use myspell, hunspell's predecessor and also include
copies of these english dictionaries, so that's a relatively small step.
Also vim has a rather baroque spellchecker which backs on to converted
copies of these same hunspell/myspell dictionaries. rhbz#219777 is a
semi-plausible route to avoiding the need for the converted copies
(which would come to approx 40megs in total I think)
So http://people.redhat.com/caolanm/hunspell/ are the src.rpms for the
rest of the dictionaries that are currently included as part of our OOo
langpacks. I'll take care of those myself (I guess)
I'd encourage anyone who wants to package dictionaries for other
languages for OOo (et.al) that are not listed at the above url, or
especially for anyone who might already have packaged in extras stuff
like "openoffice.org-dict.some_language" to repackage their dictionaries
along the lines of the like the above examples. i.e. take the dicts from
http://wiki.services.openoffice.org/wiki/Dictionaries set the correct
licence for the dict, and take the datestamp of the language there as
the pre-release version unless the dictionary otherwise notes a
Unlike the previous situation there's no need for the baroque "DICT name
foo whatever" line to be added to dictionary.lst, just name the
dictionary as the xx_YY language_region it supplies and it'll just work
out of the box in OOo.
With FC6 and updates-testing, I've gotten the following error for
almost a week now:
Transaction Check Error: file /usr/bin/pdftoppm from install of
poppler-utils-0.5.4-3.fc6 conflicts with file from package
file /usr/share/man/man1/pdftoppm.1.gz from install of
poppler-utils-0.5.4-3.fc6 conflicts with file from package
Looking at CVS, this appears to have been fixed 5 hours ago , but
the more generic question remains:
This isn't the first time this has happened. Shouldn't there be a
tool (or automatic check) with updates system that would check for
conflicts across all the packages in "official" Fedora repositories?
Pekka Savola "You each name yourselves king, yet the
Netcore Oy kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
Chris Lumens <clumens(a)redhat.com> wrote:
> Rahul Sundaram wrote:
> > I think the answer is that Xorg is moving into the direction of getting
> > things working properly by default by instead of having the user fiddle
> > with settings. The Xorg auto configuration mechanism in FC6 works better
> > and usually gets things right. If there are problems file bug reports
> > and help fix the issue rather than workaround it with configuration
> > tools and files manually. For Xorg 7.3, the plan is to use HAL and DBus
> > to enhance this further. Also see http://fedoraproject.org/wiki/XInFC7
> Yes, this is exactly right. We need to be improving autoconfiguration
> instead of relying on that display module more. If anyone is having
> problems with the autoconfig results, please file bugs about it. This
> stuff is still a little rough around the edges, particularly in the
> kickstart case (yet another thing on my todo list...)
> - Chris
This is a right direction to go -- but what about situations where it
just can't work?
For example, in the electronic classroom configuration where I teach,
the video output from the podium PC goes to a video splitter which
drives an LCD panel and an LCD projector. Each of those devices has an
optimal/native resolution, but the splitter prevents the use of DDC to
get the monitor specs (and rightly so, because the devices may have
The XInFC7 wiki page just says that we need to be able to remember/bind
EDIDs, but there are many cases like this where we won't *get* an EDID
at all, ever, and defaulting to the lowest common denominator is
"decidedly suboptimal". We can't switch entirely to autoconfiguration.
I would like to inquire as to why configuration of display settings
was removed from first boot. As it is, xorg often ignores resolutions
set by system-config-display, but now I'm not evening being given the
chance to be ignored, and frankly Fedora is terrible at guessing
display settings (from the past 4 FC6 install I've done). In the
latest install, FC6 correctly detected the VGA and monitor, but
botched the autoconfig enough that LCD blanked out (display out of
range) - fixing this was troublesome enough - and I've yet to get xorg
to accept the resolution as I set t exactly from
I was thinking of filing a bug report, but I figured that I should
better ask questions here first.
Fedora Core 6 and proud
We need a one time SIG to discuss the future of our version control
systems (CVS, SVN, mercurial, git?)
Interested parties please add approperate information to the SIG page:
(GIT and mercurial users especially requested) We will be sending out
the initial meeting notes in 1 week.
Yum only download the header part of the rpm files from the mirror to
feed it into rpm api, which does part of the depsolving.
I dont speed up thing to split out the header data into seperate files,
like earlier versions of yum did, the same number of bytes have to
be download any way. Depsolving is a complex task an it takes time to
do, i prefere good depsolving, more than fast depsolving.
Ah, I see. About the speed. I agree good depsolving IS better than fast
depsolving. BUT the choice is not necessarily between good and fast. as I
have stated Arch Linux's pacman pkg management tool and smart-pm (available
in fedora) as well as debian's tools all process dependencies MUCH faster
than yum. And they do it with comparable effectiveness to yum. I feel we can
make this process faster, not necessarily as "fast" but faster then what it
is. It does not seem to be a problem directly with rpm itself since smart
does work fairly fast even in fedora. So I am assuming it has to do with
something yum does. It could be due to python. In that case I recommend we
move more parts of yum to c. especially the "heavy" processes involved with
depchecks. What I want is for yum to be as fast as possible, without it's
quality taking a hit.
Looking at kernel memory use (based on 2.6.19 with a fedora config),
there's some not that hard ways to gain quite a bit of memory back.
Most important is CONFIG_NR_CPUS, right now that is set to 255 for
everyone; this value is used for scaling a LOT of things in the kernel,
and the sad thing is it's not even possible today to get a 255
core/processor machine (you run out of apic ids well before you get that
Setting CONFIG_NR_CPUS to 64 (which is still huge, even 16 would be more
than 99.99999% of the people who use fedora will ever use) will save
user 255 64 saving
irq_desc 2154496 294912 1859584
irq_domain 269312 18432 250880
irq_lists 134656 36864 97792
irq_2_pin 100992 27648 73344
irq_timer_state 67328 18432 48896
msi_desc 67328 18432 48896
per_cpu__kstat 33728 9280 24448
this alone saves 2.4Mb of memory in *static* buffers! Add a bunch more
in smaller buffers and all dynamic kernel allocations and it'll be
closer to 3Mb.. Easy gain right there.
Another one is __log_buf; this is currently 128Kb. Arguably it's
important for debugging to get 128Kb of dmesg info, but I wonder if 64Kb
would be enough as well, it's another easy save by setting
CONFIG_LOG_BUF_SHIFT to 16.
A third one is disabling CPU hotplug. CPU hotplug keeps quite a bit of
code in the kernel, that otherwise is boot-time only and gets evicted
right after boot..... You could argue the same for PCI hotplug but
cardbus is sort of the party spoiler there I suppose.
I don't know what Dave will pick for CONFIG_STACK_PROTECTOR_ALL; I would
suggest to turn this off (while enabling the normal
CONFIG_STACK_PROTECTOR); _ALL doesn't add much if any security while it
creates bigger and slower code everywhere. (The difference is that _ALL
forces the canary on every function, while the normal setting only
forces it for functions with buffers on the stack)