packaging October 2011

packaging@lists.fedoraproject.org

24 participants
10 discussions

Packaging thread safe version of libraries
by Sergio Pascual 29 Oct '11

29 Oct '11

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

6 6

Problems using mock on Fedora 15
by Brad Bell 20 Oct '11

20 Oct '11

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

3 4

Package Groups / "Meta-Packages"
by Stuart Mumford 17 Oct '11

17 Oct '11

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

2 1

Vanilla builds guideline?
by Ondřej Vašík 17 Oct '11

17 Oct '11

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

1 0

Packaging mozilla extensions
by Thomas Spura 16 Oct '11

16 Oct '11

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

1 0

Fwd: Fwd: Broken dependencies: gstreamer-java
by Farkas Levente 14 Oct '11

14 Oct '11

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.

3 4

Re: [Fedora-packaging] Package review SIG dead?
by Pierre-Yves Chibon 13 Oct '11

13 Oct '11

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

7 9

Package naming question
by Juan Orti Alcaine 11 Oct '11

11 Oct '11

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/

3 2

Review Guidelines on -devel packages
by Michael Schwendt 06 Oct '11

06 Oct '11

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

2 2

Creation of directories via tmpfiles.d directly after package installation
by Jochen Schmitt 06 Oct '11

06 Oct '11

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

4 3

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

packaging October 2011