[I wanted to prepare a bit more before writing this, but it seems
everyone is asking about the same things at once, so this will have to
I'd like know what people think of setting up a font SIG, and if there
are enough would-be contributors for such a SIG to be viable. Fonts
are a very transversal subject in Fedora, and the initial To: list
reflects this. Please take care to reply on fedora-devel only however.
The situation right now is:
1. we have several font packages in Fedora, but are only scratching
what could be packaged.
2. In particular the art team wants a lot more fonts in for its Art spin
3. I don't believe our font selection is optimal for every locale. It
took a near-revolt by our Greek users to get their situation fixed in
Fedora Core 6, and there are probably many other problem locales,
where users just pass on Fedora or bear their pain silently instead of
telling us about problems.
4. The i18n team is nominally in charge of selecting the best fonts
for each locale, but does not always have the right local contacts to
do so. So far i18n has focused on technical problems : if your locale
needs complex IM methods you have i18n visibility, if your locale
poses no technical challenge but your default fonts are suboptimal the
i18n team may not notice you.
4. The l10n team has local contacts and could provide useful feedback
on font choices, currently packaged font problems, local
foundries/font designers that could be contacted to contribute to the
FLOSS font pool, etc but has mostly focused on translation so far.
5. The desktop team handles our font infrastructure and takes the heat
when a font is badly rendered (since we can not use the patented
freetype autohinter many fonts that work fine under windows do not
6. We already have some font-related material disseminated on our wiki:
- packaging rules,
- licensing rules
7. The font situation is bad enough we have a font exception to our
[for example we ship Luxi even though its licensing forbids
modification, making it non-free
8. There are efforts to drain the font licensing swamp and promote
FLOSS fonts (http://unifont.org/go_for_ofl/), they are aligned with
Fedora general objectives yet Fedora has totally ignored them so far
(cf Liberation licensing choices)
This is a stark contrast with the very active debian font team :
The main part of the OLPC font page is the Debian font list!
I believe there is enough interest in the various Fedora groups to
improve the current situation through a font SIG.
This SIG would be tasked with:
A. providing a single point of entry for Fedora people interested in
fonts, centralizing all our packaging rules or at least indexing them
in a single place
B. completing the existing font packaging documentation
C. helping the i18n team maintain the font install list for each locale
D. identifying fonts worthy of packaging for l10n or art reasons
E. identifying problems in existing font packages and helping relay
the info upstream
F. identifying problems in our font infrastructure, packaging
necessary font tools
G. coordinating and effectively packaging new fonts
As the current maintainer of dejavu, and a co-maintainer of charis and
dejavu-lgc, I am ready to write a commented font spec example (B)
(without legacy core font bits, which IMHO should be optional nowadays
; however I'm sure there are people ready and willing to write this
part as an extension), and package a few fonts (G).
The l10n and i18n groups are naturals for (C). We just have to steal
the Debian receipe of having a font-by-locale table in our wiki.
I think it's pretty obvious the art team is motivated by (E). IMHO the
l10n team should have a role there too. Note that doing the legal
analysis of a potential font is far from easy as font licensing
practices are far less clean than software licensing practices. Also
we should try to build font from sources whenever possible, but font
building is often a mess.
G will demand packagers and reviewers. By nature most of them will be
active in other Fedora forums, so we're not talking of a few full-time
SIG members but a lot of part-time contributors.
I created a mockup wiki page to try to make all this clear
It's far from complete, but I hope it's complete enough to give
everyone an idea of the potential SIG scope.
So, who wants to play? Is Fedora ready for a font SIG or should I ask
again next year?
I am running 7.92, and I see that the new firewire stack is in place.
There is a page at the linux1394 wiki that suggests that kernel
packagers build the old stack into the kernel for the time being:
Any chance of this happenign for Fedora 8?
I'm going to be building a new, unfinished gdm into the devel branch
today. It's going to be very different than the gdm we are shipping
now and will need quite a bit of development before it's ready for
It won't hit rawhide until rawhide switches over to F-9.
Details about it can be found here:
As part, of the build process I need to upgrade dbus-glib to 0.74.
This will require a number of package rebuilds.
Anyway, just wanted to give everyone a heads up.
I put firefox-trunk SRPM based on current fedora rawhide one at
Notice: this package breaks the dependency against devhelp and yelp.
Janina Sajka <janina(a)rednote.net> wrote:
> Does anyone know of any rpm builds of Firefox 3? I'm aware it's nowhere
> near ready for prime time, but I have a compelling reason to start using
> ff3 fairly soon and would rather install from rpm, of course.
> BTW: My compelling reason is that FF3 will contain a11y support that
> should prove superior to any yet seen on any platform. Fingers crossed,
> etc ...
On Sunday 12 August 2007 23:01:34 Jochen Schmitt wrote:
> in the past we have removed itext and pdftk which depends on itext from
> the Fedora distribution due
> license issue.
> In the new iText package itext-2.0.4 I have found a text file about the
> licensing situation of the
> source file coming from Sun Corporation Inc.
> I have uploaded this file for review on
> I want to know, it this ok for Fedora. But I assume, that the last term
> about usage this
> file for nuclear weapons may be a blocker.
Jochen, do you have an update of the situation? Will upstream agree to modify
the license scheme a bit?
I use pdftk randomly in my job, several times a year, but I really need it. It
is not so nice to see one usefull package go away from Fedora.
OK so I have that problem where Doxygen generates links as hashes
including something like a time stamp, so the -devel packages end up
causing multilib conflicts.
Is there some silver bullet to actually SOLVE this?
I saw that Hans solved this by tar.gz:ing up the docs and add as separate
source and then suppress compile-time building of the docs, replacing with
Myself I simply deleted the docs for now.
I sort of believe Doxygen should be fixed to do something more
predictable, atleast on request.
On F7, the latest nfs-utils update (1:1.1.0-4.fc7.x86_64) seems to be
resulting in a lot of SELinux denials (accesses to /dev/usbmon?).
Not knowing what to do next, I thought I'd ask at fedora-devel. Is there
something I should do that I'm not (ie. rebooting, restarting some
daemon, restorecon)? Is this a bug in nfs-utils?
selinux-policy-targeted? Is this some malicious software update?
I could use a little help in troubleshooting.
Okay, so there's a Second Life bug open pointing out what appears to be
a license problem with some OpenGL headers:
There is indeed a bunch of headers with "SGI Free Software License B"
boilerplate in them:
$ grep -l "SGI Free" /usr/include/GL/*
$ grep -l "SGI Free" /usr/include/GL/* |xargs rpm -qf|sort|uniq
The devel packages say they're all MIT license:
$ grep -l "SGI Free" /usr/include/GL/* |xargs rpm -qfi|grep License|
Size : 1393741 License: MIT
Size : 82501 License: MIT
Size : 872295 License: MIT
"SGI Free Software License B" is explicitly not acceptable in Fedora:
I've googled up and down and I haven't found an explanation as to what
is going on. Mesa's merge review is untouched:
Is there a reason these files don't fall under the SGI license? There's
a provision for "an alternative license" but I'm not even going to
pretend to understand the mechanics. If so, could the headers be
clarified, and an explanation made in Mesa's review? And a reply made
here? And Mesa's home page fixed? ;P
GLEW apparently had the same problem, fixed by taking headers from Mesa,
so I'm very confused as to what is going on:
I've acquired a moderately large stable of packages that is starting to
consume too much of my time. I'm looking for people interesting in
either taking over or co-maintaining any of the following. Don't worry,
I won't be dropping anything in any case.
* apcupsd -- APC UPS Power Control Daemon for Linux
* cmake -- Cross-platform make system
* environment-modules -- Provides dynamic modification of a user's
* freefont -- Free UCS Outline Fonts
* ftnchek -- Static analyzer for Fortran 77 programs
* gdl -- GNU Data Language
* gifsicle -- Powerful program for manipulating GIF images and
* gocr -- GNU Optical Character Recognition program
* gv -- A X front-end for the Ghostscript PostScript(TM) interpreter
* hdf -- A general purpose library and file format for storing
* hdf5 -- A general purpose library and file format for storing
* kdesvn -- A subversion client for KDE
* kompose -- Provides a full screen view of all open windows
* ksynaptics -- KDE configuration for synaptics module
* lasi -- C++ library for creating Postscript documents
* libsynaptics -- Synaptics touchpad driver library
* ncarg -- A Fortran and C based software package for scientific
* netcdf-decoders -- Converts WMO GRIB products into NetCDF files
* netcdf-perl -- Perl extension module for scientific data access
via the netCDF API
* paraview -- Parallel visualization application
* perl-Astro-FITS-CFITSIO -- Perl extension for using the cfitsio
* perl-Boulder -- An API for hierarchical tag/value structures
* perl-Cflow -- Find flows in flow files
* perl-Device-SerialPort -- Linux/POSIX emulation of
* perl-ExtUtils-F77 -- Simple interface to F77 libs
* perl-HTML-Table -- Create HTML tables using simple interface
* perl-Net-IP-CMatch -- Efficiently match IP addresses against IP
ranges with C
* perl-Net-Patricia -- Patricia Trie perl module for fast IP
* perl-String-Approx -- Perl extension for approximate matching
* perl-XML-DOM -- DOM extension to XML::Parser
* perl-XML-RegExp -- Regular expressions for XML tokens
* plplot -- Library of functions for making scientific plots
* python-basemap -- Plots data on map projections (with continental
and political boundaries)
* python-basemap-data -- Data for python-basemap
* python-dateutil -- Powerful extensions to the standard datetime
* python-matplotlib -- Python plotting library
* python-numarray -- Python array manipulation and computational
* pytz -- World Timezone Definitions for Python
* R-multcomp -- Simultaneous inference for general linear
hypotheses R Package
* R-mvtnorm -- Multivariate normal and T distribution R Package
* R-systemfit -- Simultaneous Equation Estimation R Package
* ruby-mysql -- A Ruby interface to MySQL
* wgrib -- Manipulate, inventory and decode GRIB files
Technical Manager 303-415-9701 x222
NWRA/CoRA Division FAX: 303-415-9702
3380 Mitchell Lane orion(a)cora.nwra.com
Boulder, CO 80301 http://www.cora.nwra.com