Macro expansion problem
by Michel Salim
At the risk of asking the obvious, why does this fail:
%define nunitver %(gacutil -l nunit.core | tail -n 2 | grep nunit.core
| cut -d "=" -f 2 | cut -
d "," -f 1)
Requires: mono(nunit.core) = %{nunitver}
but this succeeds:
%define nunitver 2.2.10.0
Requires: mono(nunit.core) = %{nunitver}
context: this is for monodevelop, that comes from upstream with
bundled nunit DLLs. I've patched it to use the system-provided nunit
DLLs, but find-mono.req.sh does not pick up the correct dependencies,
thus the manual patch.
Thanks,
--
Michel Salim
http://hircus.jaiku.com/
15 years, 7 months
Re: GNUstep filesystem layout discussion
by Dominik 'Rathann' Mierzejewski
On Sunday, 24 August 2008 at 00:20, Kevin Kofler wrote:
> Michel Salim <michel.sylvan <at> gmail.com> writes:
> > - FHS, flattened (like Debian). We would need to override GNUstep-make
> > to install under %{_libdir} rather than %{_prefix}/lib. It will
> > require a customized openapp to handle multilib systems
>
> I consider this to be the only way to really comply with the FHS as required by
> the Fedora Packaging Guidelines.
>
> And as Axel rightly pointed out, binaries do not belong to /usr/bin/GNUstep/:
> if they're intended to be run directly, they should be directly under /usr/bin,
> otherwise they should be under /usr/libexec/GNUstep.
Sounds reasonable, +1.
Regards,
R.
--
Fedora http://fedoraproject.org/wiki/User:Rathann
Livna http://rpm.livna.org | MPlayer http://mplayerhq.hu
"Faith manages."
-- Delenn to Lennier in Babylon 5:"Confessions and Lamentations"
15 years, 8 months
Re: GNUstep filesystem layout discussion
by Axel Thimm
On Sat, Aug 23, 2008 at 10:26:06PM +0000, Kevin Kofler wrote:
> Axel Thimm <Axel.Thimm <at> ATrpms.net> writes:
> > Please note that the unflattened layout is not just for different
> > archs, but even different compilers/libcombos. In a flattened world
> > one can only support one combo which for example will make
> > opengroupware conflict with other GNUstep apps.
>
> Yuck! IMHO the answer there is the same as for other packages which think they
> are a distro: they need to be fixed to work with the system libraries instead
> (or the system libraries fixed to work with the packages, if that's where the
> problem lies).
I agree, but the library combo at GNUstep is a different beast, it
doesn't have to do with different system libraries and gnustep-make
does not ship any private libraries. The issue is whether gnustep-make
will allow one and only one Objective-C runtime/ foundation
library/graphical interface tuple (flattened), or allow for any
sensible combination.
Objective-C runtime is probably just gcc. For the graphical interface
there is also more or less one choice in the Linux world. But for the
foundation libraries there are several choices, most prominently
gnustep-base and libFoundation in Linux space, and while most GNUstep
owned apps use the in-house gnustep-base lib, some other prominent
ones like opengroupware.org use libFoundation.
So we do need to allow for the choice at runtime instead of
build-time, e.g. allow for non-flattened installs of gnustep-make.
I hope this makes the issues a bit clearer. IMHO we need to start with
gnustep-make's FHS and non-flattened layout and fix it where it still
needs fixing (gnustep-make FHS layout is very young and one could say
that we are shaking out the bugs and when we are finished hopefully
upstream will be glad to accept any patch we will have made to the FHS
mode layout of gnustep-make).
--
Axel.Thimm at ATrpms.net
15 years, 8 months
GNUstep filesystem layout discussion
by Michel Salim
What
===
GNUstep is a Obj-C-based framework, similar to Mac OS X's Cocoa
State of GNUstep in Fedora
================
GNUstep has long been excluded from Fedora due to its non-standard
filesystem layout. Recently, however, its support for being installed
under the FHS layout has improved. gnustep-make is now in Fedora.
There are some problems with the current layout used by Fedora; see
below.
Other distributions
===========
Debian and its derived distributions have the complete GNUstep stack
already packaged. The file system layout they adopted seem to be a
flattened FHS layout.
Current problems
==========
OpenStep/GNUstep/Cocoa allow for application bundles: self-contained
directories that is treated by the application launcher (openapp in
GNUstep) as applications. In GNUstep terminology, a "flattened"
layout, such as used in Debian, makes the application bundles
platform-specific. In an unflattened layout, however, such as used by
default when using the GNUstep layout (as opposed to the FHS layout
that we are constrained to use in Fedora), fat binaries are possible:
binaries are stored under a directory specifying their platform.
for instance:
Hello.app
\--- i386
| \--- hello
\--- x86_64
\--- hello
This seems more desirable, in that it will allow an unmodified
'openapp' launcher to work on multilib systems: the default
application path is /usr/lib/GNUstep/Applications, regardless of
whether %{_libdir} is /usr/lib or /usr/lib64.
The problem, right now, is that GNUstep tools are currently installed
in /usr/bin/<arch>. Which conflicts with util-linux-ng, where
/usr/bin/<arch> is an executable wrapper around 'setarch <arch>'.
We would need to settle on our GNUstep layout, before the rest of
GNUstep can be packaged. The main options right now seem to be:
- FHS, flattened (like Debian). We would need to override GNUstep-make
to install under %{_libdir} rather than %{_prefix}/lib. It will
require a customized openapp to handle multilib systems
- FHS, unflattened (like our current gnustep-make). Works well with
multilib. We need to decide where to put GNUstep tools: Axel suggests
/usr/bin/GNUstep/<arch>. Base libraries currently go in
/usr/lib/<arch>, and are probably fine there. Moving them to
/usr/lib/GNUstep/<arch> might cause confusion as the higher-level
frameworks are installed there.
- Pure GNUstep layout. Everything goes in /usr/GNUstep
Thoughts? Once we come up with a consensus I'll probably start a page
on the Wiki. Anyone interested in joining a GNUstep SIG?
Regards,
--
Michel Salim
http://hircus.jaiku.com/
15 years, 8 months
Removal of illegal packages
by Stephen Sweeney
Hi there,
It is with much regret that I have to ask you to remove the following
packages from your repositories,
blobwars (Blob Wars : Metal Blob Solid)
starfighter (Project: Starfighter)
blobAndConquer (Blob Wars : Blob And Conquer)
viruskiller (Virus Killer)
It has been brought to my attention by a Happy Penguin regular, leileilol,
that the packages contain resources that are non-free and, in some cases,
ripped from other games and still copyrighted. They should all be removed
immediately to avoid any legal issues.
It would be within the interests of all if we could get these games removed
ASAP so that your distributions are not affected by any legal issues.
Please could you forward this email along to any one else you may know who
is a package maintainer.
Thank you,
Stephen Sweeney
--
The Battle for the Solar System
http://www.battleforthesolarsystem.com
15 years, 8 months
resolving rpmlint absolute symlinks issue
by Development discussions related to Fedora
I am getting the following with a package I'm working on:
$ rpmlint --info RPMS/noarch/pyvnc2swf-0.9.3-3.fc9.noarch.rpm
pyvnc2swf.noarch: W: symlink-should-be-relative /usr/bin/vnc2swf
/usr/lib/python2.5/site-packages/pyvnc2swf/vnc2swf.py
Absolute symlinks are problematic eg. when working with chroot environments.
pyvnc2swf.noarch: W: symlink-should-be-relative /usr/bin/vnc2swf-edit
/usr/lib/python2.5/site-packages/pyvnc2swf/edit.py
Absolute symlinks are problematic eg. when working with chroot environments.
1 packages and 0 specfiles checked; 0 errors, 2 warnings.
I did a bit of a search on absolute symlinks, and tried to make such
using symlinks -cs:
http://rpmlint.zarb.org/cgi-bin/trac.cgi/ticket/25
, but that didn't resolve the rpm warning. Do you know if this is
considered normal to ignore, or can you point to a way to resolve it ?
[https://bugzilla.redhat.com/show_bug.cgi?id=448201]
DaveT.
15 years, 8 months
Next meeting?
by Anthony Green
When is the next packaging meeting? According to the minutes page,
there hasn't been a meeting in over two months, but prior to that there
were two or three meetings a month.
I'm mainly interested in getting approval for my Lisp packaging guidelines.
Thanks,
AG
15 years, 8 months
Best way to add a line to a config file from another package?
by Vasile Gaburici
I need to add line to /usr/share/texmf/dvips/config/config.ps to get
some extra functionality enabled for lcdf-typetools, namely Type 42
support. The config.ps file is properly marked as a config file in
texlive-texmf-dvips. Is there some infrastructure that's normally used
to hack config files or should I just echo "..." >> config.ps?
15 years, 8 months
