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, 11 months
Question about how libgcj-devel requires zlib
by Bruno Wolff III
While playing with custom repos I noticed that libgcj-devel requires a
file from zlib-devel that isn't explicitly provided. In a mixed x86_86 / i386
environmentment this requires looking at the file lists to see that
libgcj-devel-4.3.2-4.i386 needs zlib-1.2.3-18.fc9.i386 and that
zlib-1.2.3-18.fc9.x86_64 isn't good enough.
I am not sure if this is actually a bug though and if so, which package
is at fault. I was hoping to get some guidance here on whether or not
this is something I should bugzilla.
15 years
Request : removal of gtk-sharp
by Paul F. Johnson
Hi,
From what I've discovered, gtk-sharp has been fully depricated by
gtk-sharp2 now and so as maintainer of this package for fedora, can I
ask that it is retired from rawhide and f9?
Thanks
Paul
--
Sie können mich aufreizen und wirklich heiß machen!
15 years
Please do not redefine %_bindir
by Michael A. Peters
Building the fedora 9 cpio package for a distribution that puts
install-info into /usr/bin (where it probably belongs - the info dir is
in /usr/share so /usr is going to be mounted when you run it, and users
can make there own info dir so it probably shouldn't be a /sbin or
/usr/sbin binary, but anyway ...)
So - to port the rpm I needed to change the references to
/sbin/install-info to %{_bindir}/install-info
After building, it would not install because - yup, the fedora spec file
redefines %_bindir at the top of the spec file to /bin
Don't do that.
There should be a packaging guideline against that.
It impacts more than just the %configure macro and the %files section,
which I assume is why it was done. It impacts anything else that uses
%{_binder}
just add --bindir=/bin to the end of the %configure line and specify
/bin/ in %files and don't redefine the filesystem path macros.
Thank you.
15 years
%doc and %attr problems
by François Kooman
Hi,
I'm trying to package globalplatform and gpshell but have some problems
now with packaging some of the example scripts included. They are
chmodded 755 instead of the wanted 644 so I tried to use this in the
spec file:
%attr(0644,root,root)%doc README COPYING.LESSER *.txt
But this will result in the /usr/share/doc/gpshell-1.4.2/ also being
chmodded 644 which will make rpmlint (correctly) complain:
gpshell.x86_64: E: non-standard-dir-perm /usr/share/doc/gpshell-1.4.2 0644
I tried using:
%doc
%attr(0644,root,root)%doc README LICENSE.LESSER *.txt
but that doesn't seem to help much.
I've already submitted this issue upstream and the maintainer said that
he'll fix it for the next release in a few months...
How can I deal with it best for now?
Regards,
François
15 years
OpenSuse / Fedora Packaging Compatibility?
by Ken Sedgwick
Greetings,
The ACE+TAO dev team currently has two different spec files for
generating RPMs. One has been oriented towards Fedora/Redhat build
environments and the other is used in the OpenSuse build environment.
The temptation is to make them the same (they are pretty similar).
Are there any unreconcilable differences between OpenSuse packaging and
Fedora Packaging?
More importantly, are there any examples of packages which currently use
the same spec file (perhaps with platform conditional blocks) for both
distributions? We'd sure love to use them as an example ...
Many thanks in advance!
Ken
--
Ken Sedgwick
Bonsai Software, Inc.
http://www.bonsai.com/ken/
(510) 610-4162
ken+5a4(a)bonsai.com
Public Key: http://www.bonsai.com/ken/ken.asc
GPG Fingerprint: 851E 3B07 E586 0843 9434 5CC7 4033 3B9B 3F3F 9640
15 years
Use of Internal Libraries
by Nigel Jones
Hey guys,
So I know we have
http://fedoraproject.org/wiki/Packaging/Guidelines#Duplication_of_system_... which I think is pretty good, easy to understand and fairly simple.
The problem I think is that some upstream's still want to ship internal,
modified libraries.
Prime examples are mono packages, I can think of Banshee, Cowbell and
f-spot from personal experience.
It's got to point where another upstream is giving me a little bit of
hard time over it all, I even had a Debian developer agree with our
guidelines (they have the same).
Upstream says "it's a guideline not a rule".
_MY_ question is, what can we (Fedora) do to make it clear that we have
clear cut rules for why we don't want packages providing internal
libraries?
- NJ
--
Nigel Jones <dev(a)nigelj.com>
15 years
Group tag in spec files
by Tim Jackson
Just a thought: perhaps the Packaging Guidelines should have a comment
about formulating the "Group" tag in spec files? If nothing else they
could tell you to go and read /usr/share/doc/rpm-*/GROUPS, but a bit of
advice would probably be welcome there, especially for new contributors.
Currently it only has one passing reference to the Group tag (in relation
to documentation-only packages).
Thanks
Tim
15 years
