packaging October 2012

packaging@lists.fedoraproject.org

24 participants
18 discussions

Get paid to package! (Etherpad Lite)
by Rich Jones 20 Feb '13

20 Feb '13

Hey all! I didn't post this bounty, but it came across our system and it seems like you guys might be able to earn a quick bit of money on this one: http://gun.io/contracts/16/rpm-based-install-for-etherpad-lite-on-rhel-128 Any takers? -- Rich Jones Director, Gun.io

7 6

[Guidelines Change] Changes to the Packaging Guidelines
by Tom Callaway 31 Oct '12

31 Oct '12

Some changes to the Fedora Packaging Guidelines have been made: --- In the specific case where multiple software components generate identically named (but incompatible) binaries, Fedora Packagers should make every effort to convince the upstreams to rename the binaries to resolve the conflict (see: Packaging:Conflicts#Binary_Name_Conflicts). However, if neither upstream is willing to rename the binaries to resolve the conflict, AND the binaries are not viable candidates for alternatives or environment modules (incompatible runtimes), as long as there are no clear cases for both packages to be installed simultaneously, explicit Conflicts are permitted at the packager's discretion. Both packages must carry Conflicts in this case. Be aware, adding explicit Conflicts means that if any other packages depend on your package, you may be creating a chain-of-conflicts that could cause user pain. Please consider this as a last resort. https://fedoraproject.org/wiki/Packaging:Conflicts#Incompatible_Binary_File… --- The PEAR section of the PHP Guidelines has been updated to reflect the existence of a new macro, %{pear_metadir}, along with an example of how it is to be used, and a new EPEL specific section relating to the fact that %{pear_metadir} does not exist in RHEL php builds. https://fedoraproject.org/wiki/Packaging:PHP#PEAR_Modules --- The MPI Guidelines have been updated to install the module files under a "mpi" sub-directory and adds "conflict mpi" to the module files to avoid being able to load multiple mpi modules at one time. https://fedoraproject.org/wiki/Packaging:MPI --- These guideline changes were approved by the Fedora Packaging Committee (FPC). Many thanks to Remi Collet, Orion Poplawski, Michal Sekletar, and all of the members of the FPC, for assisting in drafting, refining, and passing these guidelines. As a reminder: The Fedora Packaging Guidelines are living documents! If you find something missing, incorrect, or in need of revision, you can suggest a draft change. The procedure for this is documented here: https://fedoraproject.org/wiki/Packaging/Committee#GuidelineChangeProcedure Thanks, ~tom

1 0

Self-hosting LLVM/Clang?
by Michel Alexandre Salim 27 Oct '12

27 Oct '12

Fedora's policy is to not depend on LLVM/Clang as much as possible, but would it be acceptable to use LLVM/Clang to compile newer LLVM and Clang releases? Some more experimental features (such as LLDB, which some developers have been asking for) appear to be better tested with Clang. For example: http://lldb.llvm.org/build.html the "make CXXFLAGS=-std=c++11" suggested at the bottom applies only to clang and is unrecognized by GCC. I can file an FPC request if necessary, but would like to check with the list first whether it's a sensible thing to have or not. Best, -- Michel Alexandre Salim Fedora Project Contributor: http://fedoraproject.org/ Email: salimma(a)fedoraproject.org | GPG key ID: A36A937A Jabber: hircus(a)jabber.ccc.de | IRC: hircus(a)irc.freenode.net () ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachments

4 5

Fwd: [fpc] #229: New mpi module install location and content
by Orion Poplawski 25 Oct '12

25 Oct '12

-------- Original Message -------- Subject: [fpc] #229: New mpi module install location and content Date: Fri, 26 Oct 2012 04:25:50 -0000 From: fpc <trac(a)fedorahosted.org> Reply-To: nobody(a)fedoraproject.org To: undisclosed-recipients:; #229: New mpi module install location and content -----------------------------+------------------ Reporter: orion | Owner: Type: task | Status: new Priority: minor | Milestone: Component: Guideline Draft | Version: Keywords: | Blocked By: Blocking: | -----------------------------+------------------ I've put up a revised version of the mpi package guidelines here: https://fedoraproject.org/wiki/PackagingDrafts/MPI The change is to install the module file under a "mpi" sub-directory and and "conflict mpi" to the module file to avoid being able to load multiple mpi modules at one time. See https://bugzilla.redhat.com/show_bug.cgi?id=651074 for some background. This has already been done in the openmpi package, but not yet in the mpich2 package, but I believe it should. This is a common standard to use with environment modules. In fact it calls for a revision of that guideline as well, which I'll try to get to soon. -- Ticket URL: <https://fedorahosted.org/fpc/ticket/229> fpc <https://fedoraproject.org/wiki/Packaging:Committee> Fedora Packages Collection Task Tracking

1 0

PHP Guidelines - minor change
by Remi Collet 24 Oct '12

24 Oct '12

Hi, I open a minor change request for PHP Guildelines, ro reflect the latest change in Rawhide. https://fedorahosted.org/fpc/ticket/228 Remi.

1 0

Multiple packages with the same base name versioning
by Vít Ondruch 24 Oct '12

24 Oct '12

Hi, Since my original proposal [1] was rejected, before there was even single attempt to improve my draft, I am moving this topic here in hope that somebody can build upon it: ``` Always consider to let a nonversioned package to follow an upstream release versions. The other versions of package kept in Fedora for compatibility reasons should be either prefixed by compat- prefix or their name should be suffixed by version string. For example, lets have in Fedora foo package of version 1.0 (foo-1.0) while upstream releases version 2.0. 1. If you are reasonably sure that the 1.0 version of foo package will be needed just temporary, then update the original package to foo-2.0 and introduce compat-foo-1.0 package. 2. If there might be more then one older version of library, then migrate the foo-1.0 to foo-2.0 and introduce the compatibility package foo1-1.0 or optionally foo10-1.0 package (the version in name depends on versioning scheme used by upstream). Try to avoid foo2-2.0 package as much as possible, since it prevents innovation and make package version irrelevant. ``` There was also a lot of valid feedback on FPC meeting [2], so I hope you guys are going to elaborate here. Thank you. Vit [1] https://fedorahosted.org/fpc/ticket/227 [2] http://meetbot.fedoraproject.org/fedora-meeting-1/2012-10-24/fpc.2012-10-24…

1 0

Re: [Fedora-packaging] [perl-Coro] Work-aroung missing libecb package on build-triggering host
by Ralf Corsepius 22 Oct '12

22 Oct '12

On 10/22/2012 03:47 PM, Petr Pisar wrote: > commit e00f8293097f8331883f1df35f74be70fbb290b9 > Author: Petr Písař <ppisar(a)redhat.com> > Date: Mon Oct 22 15:46:27 2012 +0200 > > Work-aroung missing libecb package on build-triggering host > > perl-Coro.spec | 2 +- > 1 files changed, 1 insertions(+), 1 deletions(-) > --- > diff --git a/perl-Coro.spec b/perl-Coro.spec > index 50a855d..31589a5 100644 > --- a/perl-Coro.spec > +++ b/perl-Coro.spec > @@ -35,7 +35,7 @@ Requires: perl(EV) >= 3 > Requires: perl(Event) >= 1.08 > Requires: perl(Guard) >= 0.5 > Requires: perl(Storable) >= 2.15 > -Provides: bundled(libecb) = %(rpm -q libecb --qf '%{VERSION}') > +Provides: bundled(libecb)%(rpm -q libecb --qf ' = %{VERSION}' 2>/dev/null) I could be wrong, but IIRC, calling rpm inside of rpm specs is not allowed in Fedora. Apart of this, what you are doing is rendering your built non-deterministic - Another "strictly forbidden" item. Ralf

3 2

Rules for obsoleting or conflicting packages
by Mario Blättermann 19 Oct '12

19 Oct '12

Hi all, I'm currently reviewing the following package: https://bugzilla.redhat.com/show_bug.cgi?id=865535 The package python-datanommer-models seems to be a splitout from datanommer, that's why we have currently: Conflicts: datanommer < 0.2.0 In my mind, it should be "Obsoletes" instead of "Conflicts" because it is the successor of datanommer. But we have a somewhat more difficult scenario here. The packager writes: "Regarding the Conflicts/Obsoletes/Provides, I'd like to still maintain the datanommer package itself as a kind of meta-package that installs the splitoffs but also includes "fedmsg-hub" which will turn on a new service. Once these packages are approved, I would bump the datanommer meta package from 0.1.8 to 0.2.0 to match them." Could we split out the appropriate files from datanommmer instead, throwing away the new review request? Means, we have a "datanommer" base package which is a metapackage only with some common files, which pulls the needed dependencies. Any ideas for a convenient solution while keeping a proper upgrade path? Best Regards, Mario

3 7

discussion around 'policy' for multiple versions of same software in EPEL
by Greg Swift 18 Oct '12

18 Oct '12

Hi. I recently started a discussion on the EPEL list about handling packages with multiple version. A few already exist, but it seems more are on their way. There, in my eyes or from what I've gathered, seem to be few clear thoughts on the best way to handle this. One of the suggestions was to ask this list's thoughts on the matter, especially the concept of 'conflict' packages. The thread is in the archives starting here: http://www.redhat.com/archives/epel-devel-list/2012-October/msg00015.html thanks for your time greg/xaeth

2 1

Unbundling oscpack and boost libraries under review
by Brendan Jones 18 Oct '12

18 Oct '12

Hi all, I'm porting supercollider (sc - an audio synthesis engine and programming language[1]) from CCRMA to Fedora. The source tree has a couple of bundled static libraries which I'm not sure meet grounds for a bundling exemption. 1. oscpack (open sound control) - the bundled version is significantly different from upstream. The author of sc has submitted patches but they were not accepted by oscpack upstream 2. boost_lockfree and boost_atomic - the sc author is the boost dev of boost_lockfree but not boost_atomic. Both libraries have been submitted to the upstream boost team for inclusion but are not yet available outside of trunk (lockfree has been approved but is waiting on review of atomic [2]). Eventually these will become part of a boost release but not for a while (boost 1.53 or later) Are these good grounds for exemption, or should we wait and simply let CCRMA host the supercollider package until they become available? [1] http://supercollider.sourceforge.net/ [2] https://svn.boost.org/trac/boost/wiki/ReviewScheduleLibraries#Boost.LockFree Brendan

2 1

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

packaging October 2012