[Long] Do we need a font SIG ?
by Nicolas Mailhot
Hi all
[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
do]
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.
http://mihmo.livejournal.com/45152.html
2. In particular the art team wants a lot more fonts in for its Art spin
http://fedoraproject.org/wiki/Artwork/ArtTeamProjects/FedoraArtStudio
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
under Fedora)
6. We already have some font-related material disseminated on our wiki:
- packaging rules,
http://fedoraproject.org/wiki/Packaging/ScriptletSnippets#head-4863fc4c93...
- licensing rules
http://fedoraproject.org/wiki/Licensing#head-63f9d798a33b23a752e5a3b22a08...
- other
http://fedoraproject.org/wiki/Fonts/DejaVu
7. The font situation is bad enough we have a font exception to our
FLOSS rules
http://fedoraproject.org/wiki/Packaging/Guidelines#head-daa717ea096fa4d9c...
[for example we ship Luxi even though its licensing forbids
modification, making it non-free
http://www.xfree86.org/current/LICENSE11.html]
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 :
http://wiki.debian.org/DebianInstaller/GUIFonts
The main part of the OLPC font page is the Debian font list!
http://wiki.laptop.org/go/Fonts
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
http://fedoraproject.org/wiki/NicolasMailhot/FontMatrix
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?
Kind regards,
--
Nicolas Mailhot
15 years, 3 months
linux1394 and f8
by Doug McLain
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:
http://wiki.linux1394.org/JujuMigration
Any chance of this happenign for Fedora 8?
Doug
15 years, 4 months
big changes going into F-9
by Ray Strode
Hi guys,
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
F-9.
It won't hit rawhide until rawhide switches over to F-9.
Details about it can be found here:
http://live.gnome.org/GDM/NewDesign
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.
--Ray
15 years, 4 months
Re: Firefox 3
by Takanori MATSUURA
Hi all,
I put firefox-trunk SRPM based on current fedora rawhide one at
http://homepage2.nifty.com/t-matsuu/install-memo/fc/
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 ...
MATSUURA Takanori
15 years, 4 months
Re: License review for new itext version
by Laurent Rineau
On Sunday 12 August 2007 23:01:34 Jochen Schmitt wrote:
> Hello,
>
> 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
>
> http://www.herr-schmitt.de/pub/itext/sun.txt
>
> 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.
--
Laurent Rineau
http://fedoraproject.org/wiki/LaurentRineau
15 years, 4 months
Doxygen and multilib
by Linus Walleij
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
pre-generated contents.
Myself I simply deleted the docs for now.
I sort of believe Doxygen should be fixed to do something more
predictable, atleast on request.
Any ideas?
Linus
15 years, 4 months
NFS Update and SELinux
by Richi Plana
Hi,
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.
--
Richi Plana
15 years, 4 months
Mesa license issue?
by Callum Lerwick
Okay, so there's a Second Life bug open pointing out what appears to be
a license problem with some OpenGL headers:
http://jira.secondlife.com/browse/VWR-2881
There is indeed a bunch of headers with "SGI Free Software License B"
boilerplate in them:
$ grep -l "SGI Free" /usr/include/GL/*
/usr/include/GL/glext.h
/usr/include/GL/glu.h
/usr/include/GL/glxext.h
/usr/include/GL/glxmd.h
/usr/include/GL/glxproto.h
/usr/include/GL/glxtokens.h
$ grep -l "SGI Free" /usr/include/GL/* |xargs rpm -qf|sort|uniq
mesa-libGL-devel-6.5.2-13.fc7.i386
mesa-libGL-devel-6.5.2-13.fc7.x86_64
mesa-libGLU-devel-6.5.2-13.fc7.i386
mesa-libGLU-devel-6.5.2-13.fc7.x86_64
xorg-x11-proto-devel-7.2-9.fc7.x86_64
The devel packages say they're all MIT license:
$ grep -l "SGI Free" /usr/include/GL/* |xargs rpm -qfi|grep License|
sort|uniq
Size : 1393741 License: MIT
Size : 82501 License: MIT
Size : 872295 License: MIT
"SGI Free Software License B" is explicitly not acceptable in Fedora:
http://fedoraproject.org/wiki/Licensing#head-d8cc605dd386091c8b6be97b8a43...
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:
http://bugzilla.redhat.com/show_bug.cgi?id=226136
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
http://www.mesa3d.org/license.html
GLEW apparently had the same problem, fixed by taking headers from Mesa,
so I'm very confused as to what is going on:
http://bugzilla.redhat.com/show_bug.cgi?id=251191
15 years, 4 months
glade3 in fedora7
by Deependra Singh Shekhawat
Hi,
Is Glade3 available on Fedora7. I saw it has been stable for long time
now and I found no package with name Glade3.
Is there no Glade3 in Fedora7 and if it isn't why is it so ?
Thanks
15 years, 4 months
Looking for help with my packages
by Orion Poplawski
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
environment
* freefont -- Free UCS Outline Fonts
* ftnchek -- Static analyzer for Fortran 77 programs
* gdl -- GNU Data Language
* gifsicle -- Powerful program for manipulating GIF images and
animations
* 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
scientific data
* hdf5 -- A general purpose library and file format for storing
scientific data
* 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
visualization
* 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
library
* perl-Boulder -- An API for hierarchical tag/value structures
* perl-Cflow -- Find flows in flow files
* perl-Device-SerialPort -- Linux/POSIX emulation of
Win32::SerialPort functions
* 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
address lookups
* perl-String-Approx -- Perl extension for approximate matching
(fuzzy 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
module
* python-matplotlib -- Python plotting library
* python-numarray -- Python array manipulation and computational
library
* 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
--
Orion Poplawski
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
15 years, 4 months