Packaging thread safe version of libraries
by Sergio Pascual
Hi list
In this bug https://bugzilla.redhat.com/show_bug.cgi?id=743249 the
user requests to enable thread safety in the cfitsio library. I'm not
completely sure of substituting one library by the other.
So I was wondering if it's a good idea to compile the code twice and
distribute two versions of the library, libcfitsio.so and
libcfitsio-mt.so. This implies to distribute two pkg-config files,
cfistio.pc and cfitsio-mt.pc
Are there any recommendations or good practices regarding this issue?
Best, Sergio
11 years, 7 months
Problems using mock on Fedora 15
by Brad Bell
I am having trouble using mock on Fedora 15 and am not sure what the
problem is. Here are the error messages I am getting:
[bradbell@brad-home cppad]$ fedpkg mockbuild
warning: Could not canonicalize hostname: brad-home.localdomain
Wrote: /home/bradbell/fedpkg/cppad/cppad-20110101.5-1.fc17.src.rpm
ERROR: Must be member of 'mock' group to run mock! ([])
... snip ...
[bradbell@brad-home cppad]$ mock --version
ERROR: Must be member of 'mock' group to run mock! ([])
[bradbell@brad-home cppad]$ groups
mock
11 years, 7 months
Package Groups / "Meta-Packages"
by Stuart Mumford
Hello,
Firstly I hope this is the right place to ask this!!
I have been having a discussion on the Fedora SciTech mailing list and we
thought that someone on here might be able to offer us some advice / a
solution!
In discussing the packages to include in a Fedora scientific spin, I
suggested that it might be worth while including the dependencies for IDL
(Interactive Data Language) which is a widely used proprietary data analysis
and visualisation package. (As much as I would rather just use Python this
is not really possible.)
I suggested that perhaps some kind of package group or "meta package" could
be created that would hold all the dependencies for IDL making the install
process easier, if all the dependencies were not included by default . (see
http://goo.gl/6a7jM for a list of the deps)
Does such a mechanism exist within the packaging framework for Fedora and if
so how easy is it to create and maintain such a package?
Thanks
Stuart
11 years, 7 months
Vanilla builds guideline?
by Ondřej Vašík
Hi,
for better automation of our static analysis tools we would like to have
some defined way how to get "as close to vanilla as possible" build from
Fedora srpms. Based on our statistics ~15% of packages are affected -
you can't simply build them without Fedora patches.
This can also be used for other purposes - if you want to rule out
influence of distro specific patches before reporting problem upstream
in the case that upstream sources are hard to compile/get running on
Fedora system. This could reduce false alarms to upstream lists.
In many cases it is not possible to simply disable all the patches -
some are required to get the rpm built but do not affect program
functionality. We have discussed that problem with rpm guy - to get a
way with the lowest possible impact on the package. As a solution, we
are proposing %{?_rawbuild} conditional.
Note: Some packages already use this %{?_rawbuild} anotation, some use %
global _with_vanilla 0 to give user a chance for vanilla build.
Change in the spec file is very simple - just for the patches required
for vanilla build this conditional should be added.
e.g. from the sudo spec file
%patch3 -p1 -b .m4path
->
%patch3 -p1 -b .m4path %{?_rawbuild}
After this change you can simply create a wrapper for rpmbuild, which
will apply only patches with the %{?_rawbuild} annotation. For more
complicated changes, _with_vanilla global is probably better option.
Our wrapper is available at
http://kdudka.fedorapeople.org/rpmbuild-rawbuild .
Is it possible to establish some common rule for Vanilla builds in
Packaging Guidelines?
Thanks in advance for consideration!
(or pointing me to better place where to ask)
Greetings,
Ondrej Vasik
11 years, 7 months
Packaging mozilla extensions
by Thomas Spura
Hi,
with the recent fast release cycle of firefox, it's harder to check
which extension is compatible with which firefox version.
There are two possibilities to add rpm dependencies to check that:
* add Requires e.g.
Requires: firefox =< 10.0
Requires: firefox >= 6.0
* add Conflicts, e.g.
Conflicts: firefox > 10.0
Conflicts: firefox < 6.0
The requires are quite easy to add and I currently requested a
subpackage of mozilla-filesystem, to add such requires at [1].
The drawback of this is, that the extensions need to be more
granulary: When a extension runs with firefox and seahorse, both
extensions need to be in a firefox-extension and seahorse-extension
package, or any firefox user are forced to install seahorse and vice
versa.
And here now my questions about that above:
* Is there something like rpm auto"conflicts" or only the
autoprovides implemented in the bug mentioned above?
* Is it maybe possible to add something like this to a .spec:
Conflicts: $(shellscript)
Which then uses scripts, to actually fill in the conflicts?
If that's possible, I'd say this is the way to go. If not,
the requires would be better.
Or do you have other solutions for this?
Greetings,
Tom
[1] https://bugzilla.redhat.com/show_bug.cgi?id=745038
11 years, 7 months
Fwd: Fwd: Broken dependencies: gstreamer-java
by Farkas Levente
anybody can help in this?
thanks
-------- Original Message --------
Subject: Fwd: Broken dependencies: gstreamer-java
Date: Mon, 10 Oct 2011 15:35:49 +0200
From: Farkas Levente <lfarkas(a)lfarkas.org>
To: Discussion of Fedora build system <buildsys(a)lists.fedoraproject.org>
hi,
can anybody tell meg why i get these mails for all fedora release?
imho on all fedora version eclipse-swt provides libswt3-gtk2 (and even
you think so):
---------------------------
yum --disablerepo=\* --enablerepo=fedora-rawhide provides libswt3-gtk2
Loaded plugins: aliases, downloadonly, list-data,
post-transaction-actions, priorities, refresh-packagekit, versionlock
1:eclipse-swt-3.7.0-1.3.fc16.x86_64 : SWT Library for GTK+-2.0
Repo : fedora-rawhide
Matched from:
Other : libswt3-gtk2
---------------------------
so what can be the problem???
thanks.
-------- Original Message --------
Subject: Broken dependencies: gstreamer-java
Date: Mon, 10 Oct 2011 13:20:08 +0000 (UTC)
From: buildsys(a)fedoraproject.org
To: gstreamer-java-owner(a)fedoraproject.org
gstreamer-java has broken dependencies in the rawhide tree:
On x86_64:
gstreamer-java-swt-1.5-1.fc16.x86_64 requires libswt3-gtk2
On i386:
gstreamer-java-swt-1.5-1.fc16.i686 requires libswt3-gtk2
Please resolve this as soon as possible.
11 years, 7 months
Re: [Fedora-packaging] Package review SIG dead?
by Pierre-Yves Chibon
On Wed, 2011-10-12 at 08:33 -0500, Richard Shaw wrote:
> On Wed, Oct 12, 2011 at 8:26 AM, Pierre-Yves Chibon
> <pingou(a)pingoured.fr> wrote:
> > On Fri, 2011-10-07 at 10:03 -0500, Richard Shaw wrote:
> >>
> >> Should we request a separate mailing list? I don't expect it to be
> >> high volume obviously but it could make communication easier since
> >> people live across multiple time zones. Also, it would make
> subjects
> >> easier since right now on the devel list we have to make it pretty
> >> obvious to catch the right peoples attention.
> >>
> >> Personally it would be very difficult to make IRC meetings with
> work
> >> and home obligations but I think the mailing lit would mitigate
> that
> >> somewhat.
> >
> > It is easy to get one, are there more people interested by having a
> > dedicated mailing-list ?
> > Knowing that:
> > - on #fedora-review for the moment there are three person (including
> me)
> > - there is already the packaging mailing-list for packaging
> questions
>
> Good thinking! I didn't even think of checking for an existing mailing
> list for some reason.
>
> Are the current owners of the packaging mailing list amenable to us
> using the it for the Packaging SIG?
Would you be ?
Thanks,
Pierre
11 years, 7 months
Package naming question
by Juan Orti Alcaine
Hello, I'm currently packaging the program arm (anonymizing relay
monitor [1]), a program to monitor Tor routers, and I have doubts about
possible conflicts in the name.
Apart of the architecture name, I have found in the package database
programs like:
arm4 -- Application Response Measurement V4.0
arm-gp2x-linux-gcc -- Cross Compiling GNU GCC targeted at arm-gp2x-linux
In Debian it is named tor-arm.
What do you suggest? I think the Debian name will cause less problems.
Thank you.
[1] http://www.atagar.com/arm/
11 years, 7 months
Review Guidelines on -devel packages
by Michael Schwendt
https://fedoraproject.org/wiki/Packaging:ReviewGuidelines
| MUST: If a package contains library files with a suffix
| (e.g. libfoo.so.1.1), then library files that end in .so (without suffix)
| must go in a -devel package. [19]
[19] https://fedoraproject.org/wiki/Packaging/Guidelines#DevelPackages
Based on just the ReviewGuidelines, some packagers and reviewers
still get this wrong and create -devel packages for plugin .so libraries.
In particular because it is a MUST. The linked Packaging Guidelines page
on "Devel Packages" makes it a SHOULD and also mentions a rule of thumb,
but apparently this is still not clear enough.
How about this?
MUST: If a package contains library files with a numeric suffix
(e.g. libfoo.so.1 or libfoo.so.1.1), extra care must be taken to
distinguish between libraries needed at run-time and libraries
needed only when compiling/building software. Library files needed
only at build-time must be put into a -devel package. [19]
--
Fedora release 16 (Verne) - Linux 3.1.0-0.rc6.git0.3.fc16.x86_64
loadavg: 0.02 0.08 0.12
11 years, 7 months
Creation of directories via tmpfiles.d directly after package installation
by Jochen Schmitt
Hallo,
I have implement the creation of the /var/run/news directory in the
inn package via tmpfiles.d.
But It's seems, that the directory will not created directly after the
package was installed. so I have add the line
systemd-tmpfiles --create %{_sysconfdir}/tmpfiles/inn.conf
on the %post stanza.
I have look on
http://www.maclife.de/
to be sure to confim with the packaging guidelines. Unfortunately,
I could not found any information to this related topic.
So I would like to ask for the opinion of other people on
this list.
Best Regards:
Jochen Schmitt
11 years, 7 months
