Re: rakarrack - alternative desktop categories
by Development discussions related to Fedora
Fernando Lopez-Lezcano wrote:
> 0.2.x is now in Planet CCRMA thanks to Arnaud from IRCAM. Great if you
> can/want to migrate it to Fedora!
I did submit a package review that I think meets the Fedora guidelines:
https://bugzilla.redhat.com/show_bug.cgi?id=455953
> I would appreciate it if you could
> keep the extra categories in the desktop file, they are used to classify
> audio apps in an extra menu I added to Planet CCRMA (and rakarrack would
> drop out of it if they were ommited).
The question you ask is a good one, and I understand where you are
coming from: {ccrma .spec}
=====
# desktop file categories
BASE="X-Fedora Application AudioVideo"
XTRA="X-Digital_Processing X-Jack"
%{__mkdir} -p %{buildroot}%{_datadir}/applications
desktop-file-install --vendor fedora \
--dir %{buildroot}%{_datadir}/applications \
`for c in ${BASE} ${XTRA} ; do echo "--add-category $c " ; done` \
%{SOURCE1}
=====
As I understand it, a Fedora package can use only the categories present
in the freedesktop.org spec:
http://fedoraproject.org/wiki/Packaging/Guidelines#.desktop_file_creation
http://standards.freedesktop.org/menu-spec/latest/apa.html
Can a package use it's own categories, or must they meet the standards ?
If there will be many audio apps {aka ccrma} packages, it would be best
to have them grouped in the same menu; the AudioVideo menu on my machine
is already overflowing more than a screenful, so I think it would be
good if these audio {only} apps get their own menu ?
DaveT.
14 years, 8 months
Adding mod_ban to proftpd?
by Philip Prindeville
Matthias et al,
Could mod_ban be added to the built packages under Fedora? I run an FTP
server, and mod_ban is very handy for protecting against attacks.
It doesn't need to be made part of the base package. It could be
handled the same way proftpd-ldap or proftpd-postgres is...
Thanks,
-Philip
14 years, 10 months
Re: TeX fonts, part one [Was: Re: [Fedora-packaging] Proposed amendment to general packaging guidelines: no bundling of fonts in other packages]
by Vasile Gaburici
I had a look the TDS (http://www.ctan.org/get/tds/tds.pdf). Nothing
written there prevents the use of symlinks. In fact their not even
mentioned because TDS is supposed work even on MSDOS. The question is
if it will actually work if we do that. I guess Jindrich Novy, the
texlive packaged owner knows better than any of us, so I'm cc-ing him.
So, Jindrich, the question is whether ripping out the TeX fonts
formats that are usable by the system at large (via freetype etc.),
and replacing them with symlinks in the TDS is going to work? A
potential problem that I see is that if texlive gets installed after
some fonts it needs to figure out and link to them...
On Sat, Jul 26, 2008 at 7:49 PM, Behdad Esfahbod <behdad(a)behdad.org> wrote:
> On Fri, 2008-07-25 at 22:42 +0300, Vasile Gaburici wrote:
>>
>> XeTeX can do that. TeX probably NEVER will because that violates TDS.
>> If you don't what that means, then don't take on the subject of TeX
>> fonts.
>
> Symlinks?
>
> --
> behdad
> http://behdad.org/
>
> "Those who would give up Essential Liberty to purchase a little
> Temporary Safety, deserve neither Liberty nor Safety."
> -- Benjamin Franklin, 1759
>
>
14 years, 10 months
Libtool 2.x?
by Vasile Gaburici
I can't find libtool 2.x in Fedora. Any good reason for this? I need
it build freetype (2.3.8pre) from CVS.
14 years, 10 months
Fwd: TeX fonts, part one [Was: Re: [Fedora-packaging] Proposed amendment to general packaging guidelines: no bundling of fonts in other packages]
by Vasile Gaburici
Forwarding to the lists what I've just sent Jonathan...
---------- Forwarded message ----------
From: Vasile Gaburici <vgaburici(a)gmail.com>
Date: Sun, Jul 27, 2008 at 7:23 PM
To: Jonathan Underwood <jonathan.underwood(a)gmail.com>
On Sun, Jul 27, 2008 at 5:59 PM, Jonathan Underwood
<jonathan.underwood(a)gmail.com> wrote:
> 2008/7/27 Vasile Gaburici <vgaburici(a)gmail.com>:
>> So, Fedora would still have to ship TeX font files separately (for
>> some fonts) until the tool set and upstream OTF packaging matures. But
>> for mundane OTF fonts, which don't have optical sizes, I don't see
>> serious show stoppers for the proposal to (i) generate their .tfm TeX
>> metrics automatically, and (ii) convert them to type 1 on the user's
>> machine.
>
> Why do (ii) on the users machine instead of at package build time?
Nicolas had some concerns on the size of font packages we ship,
especially when duplication is involved. I agree that doing the work
on the user's machine is somewhat contrary to the idea of RPM... BTW,
generating the tfm takes far more time and space. An extreme example
is MinionPro (full commercial set, from Adobe):
- OTFs: 10Mb
- PFBs: 20Mb
- TFMs: 180Mb
A single type 1 pfb file can contain more than 256 glyphs, but these
are addressable only by AGL (Adobe Glyph List) name. Traditinoal TeX
encodings (T1, LY1) are limited to 256 glyphs per font, so in order to
access all glyphs (e.g. small caps, lining figures) multiple tfm files
are generated for the same pfb. This wouldn't be much of a problem if
the tfm files didn't ALSO have to contain the kerning info! Take the
class-based kerning info from the OTF and make it pairwise, then put
overlapping subsets in multiple encodings and the disk usage
explodes... Sadly TeX cannot use Adobe's afm file format which could
at least store all the kerning pairs without duplication.
Btw, Linux Libertine or DejaVu have more glyphs than MinionPro...
> These to jobs could be handled by a simple invocation of
>> autoinst (with some parameters, like telling it if the font is serif
>> or not). So, for most fonts the foo-font-tex package could be just
>> some emtpy dirs and a %post invocation of autoinst. This method needs
>> some testing with various fonts before we commit to it.
>>
>
> Again - why not use autoinst during package build time?
If Nicholas doesn't object, I surely don't. It would be a lot easier
to control what happens.
>> TrueType fonts can be used used without conversion by pdftex, but TeX
>> metrics still have to be generated. Other TeX drivers, like dvips and
>> dvipdfm, can use TrueType fonts only if they are converted to bitmaps;
>> I don't think this is worth the hassle since the output would suck on
>> screen.
>
> I agree they suck.. but, not doing so would be a problem for legacy
> users, I fear...
I doubt any legacy user uses »TrueType« fonts while generating
PostScript from TeX. Most legacy users that still rely on PostScript
output stick with Type 1 fonts, usually those that come with TeX
(Computer Modern, standard 35 PostScript fonts), because these can be
embedded as outlines in PostScript. Using TrueType fonts in TeX for
PostSript output is no different than using METAFONT fonts: PK bitmaps
have to be generated at the output resolution. Now, TeX doesn't ship
any bitmap PK fonts when METAFONT sources are available. TeX generates
(and caches) them as needed. Remember the old days when you had to
wait for "kpathsea: Running mktexpk --mfmode ..." I'm not aware of any
program that can do the magic for TrueType fonts, but I haven't used
TrueType fonts for PostScript output either. My point is that PK
bitmap generation is not something we want to do at packaging time!
-- Vasile
14 years, 10 months
broken links in Packaging/SourceURL
by Jens-Ulrik Petersen
Can someone with packaging pages wiki priveleges please fix the broken
links on https://fedoraproject.org/wiki/Packaging/SourceURL:
[wiki:Self:Packaging/NamingGuidelines#PackageVersion Version]
[wiki:Self:Packaging/NamingGuidelines#PackageRelease Release]
[wiki:Self:Packaging/NamingGuidelines#SnapshotPackages Naming Snapshots]
in the section "Using Revision Control".
Thanks, Jens
14 years, 10 months
Are debuginfos packaged for F9 updates?
by Vasile Gaburici
I can find the debuginfo packages for the F9 release and for the
rawhide, but the ones for the F9 updates seem nowhere to be found. Am
I missing something obvious?
14 years, 10 months
Re: TeX fonts, part one [Was: Re: [Fedora-packaging] Proposed amendment to general packaging guidelines: no bundling of fonts in other packages]
by Vasile Gaburici
On Fri, Jul 25, 2008 at 10:50 PM, Dave Crossland <dave(a)lab6.com> wrote:
> 2008/7/25 Vasile Gaburici <vgaburici(a)gmail.com>:
> I second the idea that TeX ought to be an exception to the guideline
> "not hide general-purpose fonts in app-specific directories"; TeX
> predates all other programs in a GNU/Linux system, and TeX users have
> hardended expectations about how it works; if Fedora's TeX package
> fiddles with things, that will be a loss for users.
If Fedora ships a screwed-up TeX, it would incur a loss of users,
mostly of PAYING academic ones that buy RHEL through their
departments, like UMD's CS dept., which just finished a big upgrade of
all the CS RHEL machines... FYI: Macs are already the preferred choice
for laptops amongst my colleagues, because the can run both Unix apps
and Powerpoint hassle-free (OOo is still pathetic for presentations,
and not everyone has the patience that Beamer requires, especially for
graphics).
Back to the technical side, a font for TeX requires a tfm file (TeX
font metrics). To use it with LaTeX you also need a fd file, an
sometimes a sty with macros is provided, especially if the font has
features. These files don't really belong the the system fonts
directory because nothing but TeX can use them... So, for fubu-fonts,
you'd need an extra fubu-fonts-tex, or possible even a
fubu-fonts-latex package to hold the extra files (you need the latter
if you consider that latex is not required to use plain tex).
What I would like to see system fonts installing themselves for TeX
use, say via an autoinst postinst script. Like I said my "draft"
email, that's a lot of hassle for the users to do manually. That's why
I'm trying to get fontools resurected...
Also, the current texlive package has inconsistent rules for font
formats. The Gyre fonts are included as OTF, while the LM (Latin
Modern) are not, even though XeTeX needs them that way if you wan to
select them as non-default fonts. I suspect this didn't originate from
upstream.
14 years, 10 months
