--vendor fedora, rationale/motivation?
by Rex Dieter
Per
http://fedoraproject.org/wiki/Extras/FedoraDesktopEntryGuidelines:
The vendor prefix (desktop-file-install --vendor=...) must be set to
fedora".
I don't understand the rationale/motivation behind requiring '--vendor
fedora'
I can, however, see that desktop-file-install's current
implementation(*) of prepending %{vendor}- to the .desktop file name has
some problems/issues:
1. .desktop filename now varies from upstream
2. --vendor may change when/if Extras bits are pulled into Core and/or
RHEL.
3. *In particular*: when users start employing menu editors, since
most(all?) of them base their customizations on the .desktop file name.
-- Rex
(*) If desktop-file-install's implementation instead followed something
like kde's practice of using a vendor directory (e.g.
/usr/share/applications/kde), then (1) and (3) would no longer be an issue.
17 years, 5 months
Accessibility packages (speech-dispatcher + speechd-up)
by Hynek Hanke
Hello,
I'm a part of a group of developers of accessibility for blind and
visually impaired. We are working under the project www.freebsoft.org
and collaborating basically with all other projects in
Free Software accessibility. We are seeking help with RPM
packaging of several software components which are now widely
used by the handicaped community.
Basically, we have a package called Speech Dispatcher which
provides access to sound synthesizers via a high-level socket
interface SSIP (Speech Synthesis Interface Protocol). There
are several tools (clients of speech-dispatcher) already developed and
being used: speechd-el (accessibility to Emacs), speechd-up (interface
for the Speakup screen reader to software synthesis), driver for Gnome
Speech (Gnome accessibility technologies). Also, KDE is planning to
migrate its speech services to Speech Dispatcher (via KTTSD)
for the KDE4 release.
Especially the combination speech-dispatcher/speechd-up/Speakup
is used quite a lot by Fedora Core users. Today, Speakup together
with Emacspeak are the most widely used accessibility tools for
blind people on Free Software. This is the only combination
which allows users to use Speakup with software speech synthesis
(otherwise many users are using hardware devices too). Already there
are available Speakup patched kernel packages for Fedora
(Speakup, the console screen reader, works in the kernel).
Many users have problems with compiling Speech Dispatcher
and SpeechD-Up from source code, but even more with setting up the rc
scripts and init.d startup (both packages are meant to be run as system
services). I believe the task of creating the packages is not difficult
for someone with knowledge of Fedora, our resources are however very
limited in accessibility and we are not using Fedora on our machines,
so we do not have the necessary experience here in Free-B-Soft.
Is there please somebody who would be kind enough to help
us and the users of our accessibility tools by creating and
maintaining at least these two packages? I can provide all
the support and guidance as a developer of these two packages.
I'm sorry if this is not the right place to ask. In such
case, please tell me where it would be more appropriate.
More information about Speech Dispatcher
http://www.freebsoft.org/speechd
and SpeechD-Up
http://www.freebsoft.org/speechd-up
as well as other accessibility tools from Free-B-Soft
http://www.freebsoft.org/projects
More information about the SpeakUp screen reader
http://www.linux-speakup.org/
Thank you,
Hynek Hanke
17 years, 12 months
teTeX is EOL
by Michael A. Peters
tetex has been EOL'd by upstream.
I don't know what the Red Hat maintainer intends to do for FC6 - but
clearly at some point the bit rot is going to demand moving to something
else, probably texlive (which is what Debian is doing).
I'm assuming this means a namespace change for tetex packages.
I personally would suggest a namespace that is tex distribution neutral.
The TDS is pretty much what all modern open source tex implementations
follow and are going to follow, so it makes sense (to me anyway) to use
a neutral namespace, like maybe texmf or something.
thoughts?
17 years, 12 months
%doc and docdir conflicts
by Orion Poplawski
Where is the appropriate place to put documentation that a package will
install during %install in the location specified by --docdir? I've
tried using %{_docdir}/%{name}-%{version}, but the %doc macro will clean
out that directory before copying over any files listed, wiping out
anything installed during %install.
--
Orion Poplawski
System Administrator 303-415-9701 x222
Colorado Research Associates/NWRA FAX: 303-415-9702
3380 Mitchell Lane, Boulder CO 80301 http://www.co-ra.com
18 years
Non standard locations for man pages
by Orion Poplawski
In an effort to package up multiple MPI libraries (LAM-MPI, Open-MPI,
and MPICH2), we're running into a number of issues with file conflicts.
The current strategy is to move many things into /usr/share/%{name}.
However, man pages put in /usr/share/%{name}/man are not compressed.
Should I just file a bug against /usr/lib/rpm/brp-compress (rpm-build)
to add that pattern? Current list is:
for d in ./usr/man/man* ./usr/man/*/man* ./usr/info \
./usr/share/man/man* ./usr/share/man/*/man* ./usr/share/info \
./usr/kerberos/man ./usr/X11R6/man/man* ./usr/lib/perl5/man/man* \
./usr/share/doc/*/man/man* ./usr/lib/*/man/man*
Or should the man pages go elsewhere?
Anything I should do in the meantime to compress the man pages manually
if this is the right location until rpm-build is fixed?
--
Orion Poplawski
System Administrator 303-415-9701 x222
Colorado Research Associates/NWRA FAX: 303-415-9702
3380 Mitchell Lane, Boulder CO 80301 http://www.co-ra.com
18 years
Re: xorg-x11- packaging prefix
by Axel Thimm
On Thu, May 04, 2006 at 06:50:21AM +0200, Thorsten Leemhuis wrote:
> Am Donnerstag, den 04.05.2006, 02:52 +0200 schrieb Axel Thimm:
> > On Thu, May 04, 2006 at 02:39:42AM +0200, Axel Thimm wrote:
> > > On Wed, May 03, 2006 at 11:05:03AM -0400, Kristian Høgsberg wrote:
> > > > Axel Thimm wrote:
> > > > >On Wed, May 03, 2006 at 01:54:17PM +0200, Arjan van de Ven wrote:
> > > > >>On Wed, 2006-05-03 at 12:58 +0200, dragoran wrote:
> > > > >>>Axel Thimm wrote:
> > > > >>>>Should packages with source from outside of the xorg-x11 tree carry
> > > > >>>>this prefix (e.g. ivtv, nvidia, ati, etc)? E.g. is this a prefix like
> > > > >>>>often used "for <prefix>" or is it a cendor prefix, e.g. "by
> > > > >>>><prefix>"?
> > > > >>>>
> > > > >>>>How would a 3rd party driver package be best named?
> > > > >>>>xorg-x11-drv-<driver> or <3rd-party-vendor>-drv-<driver>?
> > > > >>>>
> > > > >>>I would say use
> > > > >>>
> > > > >>>xorg-x11-drv-<driver>
> > > > >>>
> > > > >>>the second one only confuses users.
> > > > >>but xorg-x11 is the name of the upstream vendor, and probably
> > > > >>trademarked or close to that. So I would suggest to not do that; even if
> > > > >>it's not a legal trademark, it makes sure that users realize where it
> > > > >>comes from (and thus where to report bugs ;)
> > > > >
> > > > >Which brings us back to the question, does the prefix really imply "by
> > > > ><prefix>" or "for <prefix>". Usually in packaging practice
> > > > >"<prefix>-foo" means foo built for <prefix>, e.g. the miriads of
> > > > >perl-XXX packages, now python-XXX, too, java-XXX, gkrellm-XXX, and all
> > > > >other module- or plugin-type packages.
> > > > >I don't mind either way, I just want to hear a clear statement from
> > > > >the X11 packaging folks. Personally I tend to hear the sound of the
> > > > >vendor in it, but I see many folks suggesting to use it as a domain
> > > > >prefix. That's why I'm bringing it up.
> > > > It's used in a 'by' sense, notice that we have other out of tree drivers
> > > > in the distribution already: synaptics and linuxwacom.
> > > OK, thanks, that was what I was looking for. So oot drivers have free
> > > nomenclature (e.g. following the project's name), and when (if) they
> > > enter xorg-x11 they become canonicalized to xorg-x11-drv-foo.
> > > Maybe I should toss it to fedoraproject.org's wiki somehwere.
> > I've added an entry to
> > http://fedoraproject.org/wiki/Packaging/NamingGuidelines
> >
> > "Addon Packages (x11 drivers)"
>
> No offense, but I removed it again. Changes to these kind of documents
> are best (read "best" -- not "have to be") discussed with FESCo, on
> fedora-packaging and/or with spot, the original author and maintainer of
> this document and the Packaging Guidelines in general.
No problem, discuss it in FESCo and then add it again. :)
I've added fedora-packaging and spot in the Cc.
> BTW: Shortly before FC5 was released there was a irc-discussion
> regarding the package naming of the proprietary nvidia and fglrx
> drivers. It was on #fedora-extras (spot was involved in that discussion,
> too) -- the consensus was "use prefix xorg-x11-drv even for non-Xorg
> drivers". And that's what livna did for FC5 then.
>
> We should probably discuss this during the next FESCo-Meeting with spot.
We know that Fedora Extras and Fedora Core don't yet have identical
packaging rules, but they are converging. Wrt new packaging rules one
should discuss it with both sides, e.g. ask the x11 maintainers at FC
who introduced that prefix what the purpose of the prefix is like done
in this thread.
Creating new divergent views isn't helpful, I'd say either convince
FC's x11 folks to change their mind or follow along.
--
Axel.Thimm at ATrpms.net
18 years
License Review
by Jesse Keating
IANAL, so I need somebody to help me review this license to see if we
can include software licensed by this.
I'm going to put up a package review request for metasploit version 2.5,
as the 2.x tree is licensed with Perl Artistic/GPL, however the
developmental branch, metasploit 3.0 is licensed with a new license to
try and protect themselves from the difficulties recently experienced by
nessus and snort.
Can you look over
http://www.metasploit.com/projects/Framework/msf3/download.html?Release=a... for The Metasploit Framework License v1.0 ?
--
Jesse Keating
Release Engineer: Fedora
18 years
