packaging July 2008

packaging@lists.fedoraproject.org

36 participants
22 discussions

Re: TeX fonts, part one [Was: Re: [Fedora-packaging] Proposed amendment to general packaging guidelines: no bundling of fonts in other packages]
by Nicolas Mailhot 25 Jul '08

25 Jul '08

On Fri, 2008-07-25 at 20:50 +0100, Dave Crossland wrote: > 2008/7/25 Vasile Gaburici <vgaburici(a)gmail.com>: > > On Fri, Jul 25, 2008 at 4:18 PM, Nicolas Mailhot > > <nicolas.mailhot(a)laposte.net> wrote: > >> — We should not hide general-purpose fonts in app-specific directories. > >> TEX should use system fonts directly. > > > > 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. > > 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. We're under a *nix. The TEX packagers can symlink the files to TEX internal directories if that makes TEX users feel better. Though we've been resorbing various private font repositories in the past years (starting with the xorg ones) and mid term I don't see how TEX can escape the trend. That's the bad thing of switching to a common font format. (The good thing being of course that you get access to the fonts other groups provide) > (I'm still not getting Nicolas' emails :-( I'm routing lab6.com through another smtp now. Of course that won't change mails sent directly to the list. Someone is blackholing me between Red Hat servers and yours. -- Nicolas Mailhot

1 0

TeX fonts, part one [Was: Re: [Fedora-packaging] Proposed amendment to general packaging guidelines: no bundling of fonts in other packages]
by Vasile Gaburici 25 Jul '08

25 Jul '08

I did not have time finish writing all the details below, I'll write some more tonight, but before this Type 1 bashing gets out of hand, read the stuff below. If you don't want the gory details, the bottom line is that the mainstream TeX still works best with type-1 fonts. And it isn't likely to go away soon. So I would not rush to deprecate type 1 fonts, unless you want TeX users to stop using Fedora. This isn't likely to change anytime soon. XeTeX is not as robust as the old TeX, and still lacks some features next to pdftex. XeTeX's acceptance with academic publishers is virtually nil today. And they, the publishers dictate what most academics use to write papers, books etc. The mainstream TeX (and by that I mean dvips, dvipdfm and pdftex) cannot currently use OpenType/CFF, but only Type 1 (and some TeX font specialties that are irrelevant in this discussion). CFF fonts need to be converted to Type 1 using otftotfm. Several tools exist to automate the CFF to Type 1 conversion for large font families because this can be a LOT of work using otfotfm directly for fonts that have optical sizes (like the Adobe Pro series). The most notable automation tools are, in order of how complete they are: autoinst from fontools, otfinst, and otftofd. Each has some features the other lacks, however. Most notably fontools lacks optical size support. Some LaTeX packages, like MinionPro, have their own otfotfm wrapper scripts, which are a lot easier to use because some files (enc, fd) come pre-generated. Furthermore, dvips and dvipdfm cannot use TrueType fonts directly (regardless whether they have OpenType features), but can convert them to bitmap PK fonts, which print ok, but may look bad on screen. In contrast pdftex can embed TrueType as outlines in the pdf using \DeclareTruetypeFont. Unfortunately, generating the TeX infrastructure (tfm font metrics, encodings) for TrueType fonts requires MORE work than generating the Type 1 from a CFF. This happens because a different, less featured tool must be used: ttf2tfm. There are some wrappers like ttf2tex (no longer maintained), and fontinst, which is rather outdated. Autoinst (from fontools) is the only tool that handles both OpenType CFF and TrueType. Most tutorials for using TrueType with pdftex recommend using ttf2tfm directly. FYI: XeTeX uses dvipdfmx as backend, which supports all flavors of OpenType, but this requires xdv input that is not the same as the traditional dvi produced by TeX. pdftex does not produce any intermediate format. For some simple usage examples see (note - first one is XeTeX): http://existentialtype.net/2008/07/12/fonts-in-latex-part-one-xelatex/ http://existentialtype.net/2008/07/12/fonts-in-latex-part-two-pdftex-and-op… http://existentialtype.net/2008/07/19/fonts-in-latex-part-three-pdftex-and-… A complex example using Gentium via ttf2tfm: http://tclab.kaist.ac.kr/ipe/pdftex_3.html To be continued... On Fri, Jul 25, 2008 at 2:33 PM, Nicolas Mailhot <nicolas.mailhot(a)laposte.net> wrote: > On Fri, 2008-07-25 at 13:03 +0200, Patrice Dumas wrote: >> On Fri, Jul 25, 2008 at 12:36:40PM +0200, Nicolas Mailhot wrote: >> > >> > Frankly, the other font formats are so much less useful than modern font >> > formats, the probability someone did creative legal restructuring is >> > much lower. > > Anyway, I've amended the proposal in a less format-oriented version > https://fedoraproject.org/wiki/PackagingDrafts/No_bundling_of_fonts_in_othe… > >> > The big exception are Type1 fonts but I just hope they can >> > die die die (and if the Tex-Gyre situation is fixed and we can use OTF > >> I don't think this may happen in a while because some very interesting >> apps (though not mainstream desktop apps, fortunately) uses type1 >> fonts, mostly using t1lib, like xfig, xdvi, grace. > > Our TEX can use TTF (OpenType TT) and OTF (OpenType CFF) now. Given that > OTF (OpenType CFF) embeds something very close to what PDF uses, I'd be > surprised if Ghostscript could not use the OTF TEX-Gyre fonts directly. > > Do we really have so much interecting stuff that depends on Type1 once > TEX and GS are out of the way? > >> > In the meanwhile, it may make sense to add Type1 to the list. >> >> For tex I believe that it will be too complicated to use the system >> fonts. > > TEX now uses the same formats as everyone else (TTF and OTF). I frankly > do not think we can afford (or have the resources) to duplicate megs of > fonts in TEX-specific packages. If TEX can not use the fonts in > fontconfig directories, it just has to symlink them somewhere it can. > > Regards, > > -- > Nicolas Mailhot > > -- > Fedora-packaging mailing list > Fedora-packaging(a)redhat.com > https://www.redhat.com/mailman/listinfo/fedora-packaging > >

2 2

Fedora Packaging Committee Meeting (Tuesday July 22)
by Tom Callaway 25 Jul '08

25 Jul '08

The next Fedora Packaging Committee Meeting will be held on Tuesday, July 22, 2008. (Note: Normally, the FPC meets every other week, but this meeting was scheduled since we did not have quorum on July 15, 2008) Meeting time is at 17:00 UTC. FPC members, please try to be on-time, as the Fedora Board meets at 18:00 UTC. Items scheduled to be discussed: Python virtual Provides: PackagingDrafts/Python Haskell: PackagingDrafts/Haskell Font bundles amendement to Fonts policy: PackagingDrafts/Packaging_font_bundles Lisp: PackagingDrafts/Lisp As a reminder, the process for getting items onto the FPC's agenda is documented here: http://fedoraproject.org/wiki/Packaging/Committee#Guideline_Change_Procedure Thanks, ~spot

10 23

Proposed amendment to general packaging guidelines: no bundling of fonts in other packages
by Nicolas Mailhot 25 Jul '08

25 Jul '08

Hi, Given what happened there: https://bugzilla.redhat.com/show_bug.cgi?id=456580 I'm proposing the following guidelines amendment: https://fedoraproject.org/wiki/PackagingDrafts/No_bundling_of_fonts_in_othe… Regards, -- Nicolas Mailhot

3 4

Case-insensitive "yum install"?
by Chris Ball 25 Jul '08

25 Jul '08

Hi, [Looks like this has been discussed previously, though perhaps not here. Sorry if it's annoying to have it brought up again.] I'd like to make "yum install" case-insensitive (for occasions where there is only one useful interpretation of case), so that I can do e.g. "yum install wxgtk" without first doing "yum search wxgtk" and finding that the required case is "yum install wxGTK". In the unlikely event of repositories containing two packages with the same case-insensitive interpretation (would this meet packaging rules, and is it used by anyone?) we can refuse to operate on anything but the correct case. There is no potential for damage here -- we don't proceed if you might have meant something else. What do people here think? Is there anything I've missed? Thanks, - Chris. -- Chris Ball <cjb(a)laptop.org>

4 3

Packaging xulrunner extensions: dependencies
by Ville-Pekka Vainio 22 Jul '08

22 Jul '08

Hi, I recently posted an email about Firefox/xulrunner extensions and dependencies to fedora-devel, but I got no answers, so I'll try this list as well. Here's what I wrote: > As we just saw with nspluginwrapper, packaging things dependening on > xulrunner/Firefox is a bit problematic. My Mozvoikko package was recently > approved by Ville Skyttä > (https://bugzilla.redhat.com/show_bug.cgi?id=448215) but he had a good > question about the dependencies: > > "If I understand correctly, using xulrunner-unstable makes this prone to > breakage on updates - is there some versioned dependency towards some > package that could be used so that it would be easier to notice such > cases?" > > I think the answer here is no. Or is there? We just saw what happens if you > hardcode a xulrunner version as a dependency, there will be breakage as > soon as xulrunner is updated. I had the Mozvoikko package from that review > installed as well and it worked fine after the update of Firefox and > xulrunner. So I think I should just leave the xulrunner dependency > unversioned and rebuild the mozvoikko package if I notice the extension > being broken after a xulrunner update. > > I also noticed something interesting about xulrunner-devel and > xulrunner-devel-unstable. Mozvoikko can't be built just with the stable > headers which apparently are in /usr/include/xulrunner-sdk-1.9/stable/. For > example it needs mozISpellCheckingEngine.h. This file can be found from two > locations, however. The xulrunner-devel package puts it > in /usr/include/xulrunner-sdk-1.9/spellchecker/mozISpellCheckingEngine.h > and the xulrunner-devel-unstable package puts it > in /usr/include/xulrunner-sdk-1.9/unstable/mozISpellCheckingEngine.h. Why > are there two copies and is it considered stable or unstable? I'm thinking > it's "classified" as unstable, but why is it in the "stable devel package" > then as well? If anyone has any answers or ideas on packaging the extension, I would really appreciate the feedback. -- Ville-Pekka Vainio

1 0

Fedora Common Lisp update
by Anthony Green 13 Jul '08

13 Jul '08

While I'm waiting for my Lisp packaging guidelines to be reviewed again, I've taken the liberty of updating sbcl, cmucl and clisp to take advantage of the new common-lisp-controller package (which, I believe is approved, but the reviewer needs to flip the bit, or do I do that? https://bugzilla.redhat.com/show_bug.cgi?id=427411). I've also uploaded a collection of popular Common Lisp library packages for eventual submission here: http://people.redhat.com/green/Fedora. If you, for instance, install this new sbcl as well as a library like cl-clsql, you should be able to just run execute (require 'clsql-sqlite3) and the compiler will populate /var/cache/common-lisp-controller/sbcl/$USER/clsql with .fasl files. The sbcl package is working really well. I'm still having a little trouble with cmucl and clisp, but I thought I'd let people know what I was up to anyway. So, bottom line... I need some forward motion on my Lisp packaging draft. http://fedoraproject.org/wiki/PackagingDrafts/Lisp Thanks! AG

1 0

Regarding PHP guidelines -- pear packages
by Rakesh Pandit 13 Jul '08

13 Jul '08

Hello all, I had a confusion regarding PHP libraries which have a pending draft at pear.php.net but haven't been yet included in pear. May we go ahead packaging them as pear? Or package them as non pear PHP libraries and wait for proposal to pass? Or it is upto packager? For example php-openid[1] or php-oauth[2] has a proposed status for pear. OpenID review is already going on and i am a bit impatient getting oauth also in ;-) Suggestions? May be PHP Packaging wiki page[3] requires some update regarding this. Thanks. [1] http://pear.php.net/pepr/pepr-proposal-show.php?id=500 [2] http://pear.php.net/pepr/pepr-proposal-show.php?id=512 [3] https://fedoraproject.org/wiki/Packaging/PHP -- Regards, Rakesh Pandit

3 3

desktop file icon/pixmap locations
by Chuck Anderson 08 Jul '08

08 Jul '08

Where should icons for desktop files be stored? Some packages use /usr/share/pixmaps. Others use subdirectories under /usr/share/pixmaps (some directories are unowned too). Some use a private directory under /usr/share/<name>. Still others use /usr/share/icons/. Icon=/usr/share/sane/xsane/xsane-logo.xpm >rpm -ql gnome-utils | grep /usr/share/pixmaps /usr/share/pixmaps/gsearchtool/thumbnail_frame.png file /usr/share/pixmaps/gsearchtool is not owned by any package How should the icon be referred to in a desktop file? Some use absolute paths, others no path at all. desktop-file-install complains if there is a relative or partial path. Icon=/usr/share/system-config-lvm/pixmaps/lv_icon.png Icon=/usr/share/system-config-selinux/system-config-selinux.png Some desktop file icons don't use an extention, but some do: Icon=accessories-calculator Icon=accessories-dictionary.png It looks like the majority of the desktop files on my F9 system are using the form without an extension. All of this is confusing. For new applications, what should they use? What are the semantics for the various syntaxes that are used? What should be done for upstream packages that have icons? What if they are in xpm format rather than png? Thanks.

5 10

Fonts packaging amendment
by Nicolas Mailhot 07 Jul '08

07 Jul '08

Hi, I'm proposing the following amendment: http://fedoraproject.org/wiki/PackagingDrafts/Packaging_font_bundles to our fonts packaging policy: http://fedoraproject.org/wiki/Packaging/FontsPolicy (official page, broken by the wiki migration) http://fedoraproject.org/wiki/Fonts_packaging_policy (unofficial cleaned-up font page ; I hope someone will the right accesses picks it up) Nothing earth-shattering, just a write-up of our current unwritten rules Regards, -- Nicolas Mailhot

3 4

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

packaging July 2008