Core fonts packaging guidelines writer WANTED
by Nicolas Mailhot
Hi,
As most of you know server-side fonts accessed through the core X11
protocol (aka core fonts) were superceded by client-side
(fontconfig...) fonts in the past years.
We've finally acknowledged this fact in Fedora 8 by removing xfs and
the brutal check that killed user X sessions if more fonts were
misconfigured (the dreaded "can not find font 'fixed'"). IIRC this was
an OLPC request and I fully support this decision.
As a result the burden of keeping core fonts working moved from the
distribution as a whole to the group of people maintaining and using
the small group of legacy applications that still use them.
It seems this change was not integrated properly and several core font
packages slipped in Fedora 8 in a broken state without anyone noticing
(not through evil intent, just because the affected packages are old
and
crufty and the people that stridently defend core fonts use were
doing something else). For the calendar-impaired, that was before the
Fonts SIG started its activities.
To fix this situation, I call for one or several core font users to
rise to the occasion:
A. Please join the fonts SIG
http://fedoraproject.org/wiki/SIGs/Fonts
B. Please write well-though core fonts packaging guidelines consistent
with the objectives of people already doing fonts work for other font
backends. That means in particular not having core font utilities
dependencies in font packages
http://fedoraproject.org/wiki/PackagingDrafts/FontsPolicy#no-handler-deps
Several possible technical solutions have already been posted on the
list, such as:
1. pre-generating fonts.* files at %build time or
2. duplicating the solution used for the fontconfig backend. That means:
a. dynamically generating fonts.* files in conditionnal scriptlets
(if core font tools are present on system), and
b. have one package responsible for walking the configured core font
directories and re-generating fonts.* files when installed, and make
core font apps depend on it (so things still work if a core font
using app is installed after fonts packages are)
There may be other solutions, it's up to the core fonts community to
choose one.
Do not fall in the facility of brutaly making font packages depend on
mkfontdir, as a lot of font packages are not exposed only via the core
X11 protocol and most of their users do not want the core font stack
installed. (OLPC is such a group).
C. Please discuss your guidelines on the Fonts SIG list and among core
fonts users so we have consensus. Then get your guidelines
officialised
D. Please audit all the existing core fonts packages and make them
conform to the resulting core font guidelines, so we don't get
accidental breakage like right now
Anyone stepping in to do this will have my complete support, and I
hope the one of the whole distribution.
Otherwise Jens has indicated he may end up writing core fonts
packaging guidelines, but frankly given the level of abuse we've seen
from core font users lately I'd understand if he passed. And in the
end core fonts users would be better served by guidelines written by
less busy people who actually use the core fonts backend.
This will be my last statement on the subject. Thank you for your
attention.
--
Nicolas Mailhot
16 years, 4 months
Re: Versioning svn checkouts [Was: Re: alpha/beta software in Fedora 8?]
by Nicolas Mailhot
Le Mer 28 novembre 2007 21:33, Petr Machata a écrit :
> Steve Grubb wrote:
>> kdepim-enterprise-svn20070926.tar.bz2
>
> As a side note, I always wondered why to use date in the release tag
> of
> package, whose sources come from non-cvs versioning system. For svn,
> in
> my opinion, it would make more sense to use the tree revision number;
> for git, similarly, sha1 id of the tree.
For git that would not be a number but for svn any shuffling upstream
does in its VCS can result in revision number changes, so relying on
them to identify sources is a big no-go.
--
Nicolas Mailhot
16 years, 4 months
Re: [Fwd: [Inkscape-user] Fedora Package Maintainer]
by Nicu Buculei
Michael Beckwith wrote:
> Found this interesting and something that one of us could perhaps
> partake in?
Michael, you should have forwarded this to the devel not art list.
/me grumpy about not being able to install Inkscape autopackaged nightly
builds due to bad library requirements since F8 and not even able to
submit a bug report after they changed the tracker from sf.net to Launchpad.
> ------------------------------------------------------------------------
>
> Subject:
> [Inkscape-user] Fedora Package Maintainer
>
>
> Hello,
>
> Denis Leroy e-mail me off list and mentioned that he's no longer
> interested in maintaining the Fedora package of Inkscape. If there is
> any other Fedora packagers that are willing to pick it up, that'd be
> great. I'm not sure of other Fedora lists that this should be posted
> to, but if people could forward it to those that would be great.
>
> Thanks,
> Ted
--
nicu :: http://nicubunu.ro :: http://nicubunu.blogspot.com
Cool Fedora wallpapers: http://fedora.nicubunu.ro/wallpapers/
Open Clip Art Library: http://www.openclipart.org
my Fedora stuff: http://fedora.nicubunu.ro
16 years, 4 months
So Cal Linux Expo Calls For Papers close Friday!
by Gareth J. Greenaway
The Calls for Paper for the So Cal Linux Expo, and its Friday special
sessions, Women in Open Source, Demonstrating Open Source Software
Health Care Solutions, and Open Source Software in Education, close
Friday 11/30.
If you're contemplating submitting a paper for any of these session,
don't delay - there are only a few speaker slots left.
--
Gareth J. Greenaway <g(a)socallinuxexpo.org>
Voice - 877-831-2569 x130
Southern California Linux Expo
http://www.socallinuxexpo.org
16 years, 4 months
Bugzilla 'version' changes for Fedora this Friday!
by Will Woods
Hi folks!
To help make Bugzilla easier to use and understand, we're going to make
two changes to the 'version' field:
1) Stop using the fNtestX versions, and
2) Rename "devel" to "rawhide".
We're doing this because of two facts about Fedora development:
First, test releases are just rawhide snapshots, so they shouldn't be
tracked as their own special versions. Second, everyone calls the
development tree "Rawhide", so Bugzilla should reflect that.
So here's what's happening. This Friday, all bugs filed against Test
versions of Fedora will be moved to the corresponding final release -
for example, fc6test2 bugs will be moved to fc6. The testX versions will
then be removed from the version list in Bugzilla. Finally we'll rename
"devel" to "rawhide".
NOTE: this MAY BREAK scripts or links that used "devel". If you have any
such scripts, make sure you update them as soon as possible!
Thanks!
-w
_______________________________________________
Fedora-devel-announce mailing list
Fedora-devel-announce(a)redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-announce
16 years, 4 months
Driver transition: via -> openchrome
by Adam Jackson
Just a heads-up:
The via driver in Xorg is pretty much dead. Therefore, rawhide will be
switching to openchrome. xorg-x11-drivers now Requires openchrome on
x86 and amd64 machines, and the openchrome package (once it builds
again) will both provide and obsolete the via package, and munge your
config file (if present) to change the driver name appropriately. Also,
X will load the new driver if started without a config file.
Shouldn't break anything, but if it does, as always, bugzilla is
standing by and ready to take your call.
- ajax
16 years, 4 months
RSSOwl status?
by Jack Tanner
As far as I can tell by googling around, RSSOwl 1.x got dropped at some
point because it depended on iText, which had licensing issues. RSSOwl 2.x,
which is not yet out, will dispense with iText, and we can have it back then.
In the meantime, RSSOwl 2.x is up to Milestone 6, and iText's homepage
talks about a dual LGPL/MPL license. It'd be nice if we could could we have
RSSOwl in some form now. Either 2M6 or 1.2 with the (seemingly kosher) iText
would be great.
16 years, 4 months
