packaging July 2008

packaging@lists.fedoraproject.org

36 participants
22 discussions

Re: rakarrack - alternative desktop categories
by Development discussions related to Fedora 12 Oct '08

12 Oct '08

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.

2 3

Early MinGW packaging guidelines draft
by Richard W.M. Jones 01 Aug '08

01 Aug '08

https://fedoraproject.org/wiki/PackagingDrafts/MinGW Comments welcome. It's at a rather early stage at the moment. There are some packages already if you'd like to take a look at them: http://hg.et.redhat.com/misc/fedora-mingw--devel I have some misgivings (actually a lot of misgivings) about the use of the /usr/i686-pc-mingw32 directory. See Ralf's reply to my email here for some justification: http://sourceware.org/ml/binutils/2008-07/msg00105.html Rich. -- Richard Jones, Emerging Technologies, Red Hat http://et.redhat.com/~rjones virt-top is 'top' for virtual machines. Tiny program with many powerful monitoring features, net stats, disk stats, logging, etc. http://et.redhat.com/~rjones/virt-top

13 51

Adding mod_ban to proftpd?
by Philip Prindeville 30 Jul '08

30 Jul '08

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

2 2

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 30 Jul '08

30 Jul '08

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 > >

3 7

Libtool 2.x?
by Vasile Gaburici 29 Jul '08

29 Jul '08

I can't find libtool 2.x in Fedora. Any good reason for this? I need it build freetype (2.3.8pre) from CVS.

2 1

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 29 Jul '08

29 Jul '08

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

1 1

broken links in Packaging/SourceURL
by Jens-Ulrik Petersen 28 Jul '08

28 Jul '08

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

2 1

Remakes legality question
by Cristian Morales Vega 27 Jul '08

27 Jul '08

I was trying to package a Road Fighter (http://en.wikipedia.org/wiki/Road_Fighter) remake: http://roadfighter.jorito.net/ - http://www.braingames.getput.com/roadf/default.asp in the openSUSE Build Service for openSUSE and Fedora. Since looks like Fedora has more experience and looks deeper at legal questions I'm asking here. The problem is nobody is very sure about the legal questions (http://www.braingames.getput.com/forum/forum_posts.asp?TID=678&PN=1) - Can the remake be named "Road Fighter"? - If isn't just also a "cars game", but even the tracks are made thinking in being the same than in the original game... it's a problem? (if it's a copy of the full game the "full game copyright" applies?) - I suppose the tracks can't have "ads" with "Konami" name, true? - Should any mention to Konami be removed, or things like this one (http://img360.imageshack.us/my.php?image=roadfighterscreenwi0.jpg) aren't a problem? Thanks.

2 1

Are debuginfos packaged for F9 updates?
by Vasile Gaburici 27 Jul '08

27 Jul '08

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?

2 2

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 25 Jul '08

25 Jul '08

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.

2 1

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

packaging July 2008