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

Request for exception: seabios-bin on ppc64
by Richard W.M. Jones 17 Oct '12

17 Oct '12

[Bug: https://bugzilla.redhat.com/show_bug.cgi?id=866664] Here's the situation, since the bug doesn't explain it well. (1) qemu can run any architecture on any other architecture, using software emulation. eg. It can run x86_64 guest operating systems on top of ppc64 hosts (albeit not at full speed). (2) In order to run guests, you have to provide a BIOS (or some sort of other boot ROM), since most guests wouldn't be able to boot without BIOS services. This applies for all guests, but of particular interest to us are i686/x86_64 guests. (3) SeaBIOS is a free, open source PC BIOS implementation. It is what we use to provide services to i686/x86_64 PC guests. (4) Although qemu itself bundles some binary BIOSes, in Fedora we have chosen to recompile these from source. We now (on i686/x86_64) compile or cross-compile all ROMs from source. (5) 'seabios-bin' is the name of the RPM package that contains the SeaBIOS ROMs. I have no idea why (historical?) this package has '-bin' in the name, but the important point is that it is NOT a binary-only package. It is built from source. (6) In order to compile SeaBIOS you need a program called 'iasl' (part of the ACPICA.org project). This program is needed to compile the ACPI tables which are an integral part of the ROM data that is needed for i686/x86_64 guests to boot. (7) Unfortunately the iasl program, which runs fine on little-endian platforms, has endianness issues. Such that when you run it on a ppc64 host it produces big-endian ACPI tables, which are of course completely broken. 'iasl' itself is a very large program, and I do not know the scope of the fix for this issue -- it may be trivial, or it may require auditing every line of code. Therefore: We would like a packaging exception which would allow us to import the seabios-bin package (built on little-endian) into the ppc & ppc64 buildroots. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones virt-df lists disk usage of guests without needing to install any software inside the virtual machine. Supports Linux and Windows. http://et.redhat.com/~rjones/virt-df/

3 10

RFD: C/C++ template packages
by Ralf Corsepius 15 Oct '12

15 Oct '12

Hi, Fedora carries some "C/C++" "template"/"header-only" packages (Packages which contain C/C++-headers only). Typically, these packages are being built "BuildArch: noarch". == These packages are supposed to be arch-independent. In reality, many of these packages often are wrapper headers, trying to wrap to something highly OS-/arch-dependent, from system-headers and compiler built-ins defines. I.e. though these packages are supposed to be arch-independent, there is no guarantee nor check whether these packages actually are arch-independent. I am proposing to: Proposal: All "C/C++-template/header-only packages" must be built using an "arch'ed BuildArch", with the resulting binary packages implemented as "Arch: noarch"-subpackages. Benefits: - This would assure such packages would be built on all architectures Fedora supports and not only the architecture noarch-packages are being built. - This would exercise potentially existing configuration-scripts on all architectures and would allow to exercise test-scripts rsp. coding examples (which can be regarded as compilation-checks) on all Fedora supported architectures. Comments, opinions? Ralf

2 2

Dependence on initscripts/chkconfig
by Milan Broz 10 Oct '12

10 Oct '12

Hi, there seems to be a lot of packages which still require initscripts and chkconfig. Majority of them are because of pre/post upgrade scriptlet (sysv->systemd). Example - rsyslog: %triggerpostun -n rsyslog-sysvinit -- rsyslog < 5.8.2-3 /sbin/chkconfig --add rsyslog >/dev/null 2>&1 || : Without removing these triggers it is impossible to get rid of these unnecessary dependences. (IMHO only *-sysv sub-packages should require it). It is quite important mainly for minimal install but there are many packages in the whole distro. But because Fedora supports only upgrade from N-1 version, I think there should be some guideline to remove these scriptlets after N+1 release. Can you provide some guidance what to do here now? Shouldn't be these triggers removed in rawhide (F19) now? Thanks, Milan

2 1

APT,YUM and package status
by Mohsen Pahlevanzadeh 08 Oct '12

08 Oct '12

Dear all, Recently, i'm writing a benchmark between APT and YUM, by default i didn't know yum and know apt, i didn't find the following status in the yum: ////////////////////////////////////// PACKAGE STATES not-installed The package is not installed on your system. config-files Only the configuration files of the package exist on the system. half-installed The installation of the package has been started, but not completed for some reason. unpacked The package is unpacked, but not configured. half-configured The package is unpacked and configuration has been started, but not yet completed for some reason. triggers-awaited The package awaits trigger processing by another package. triggers-pending The package has been triggered. installed The package is unpacked and configured OK. ////////////////////////////////////////////// Where can i find above feature or yum doesn't has them? --mohsen

5 8

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

08 Oct '12

A few minor changes to the Fedora Packaging Guidelines have been made: --- The Ruby Packaging guidelines were updated to reflect the fact that rubygem packages must have a Requires: rubygems, because that package (rubygems) owns the RubyGems? directory structure. https://fedoraproject.org/wiki/Packaging:Ruby#RubyGems --- The systemd Scriptlets for Fedora 18+ have had their corresponding scriptlet Requires adjusted from "systemd-units" to "systemd", since "systemd-units" is provided by the "systemd" package in Fedora 18+. There is still a separation in previous releases of Fedora (16/17), so packagers can choose to continue using the old Requires (systemd-units) if they are targeting multiple versions of Fedora with a single spec file. https://fedoraproject.org/wiki/Packaging:ScriptletSnippets#Macroized_script… --- This guideline change was approved by the Fedora Packaging Committee (FPC). Many thanks to Vit Ondruch, Lennart Poettering, 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

Exceptions for packages placing files into /bin, /sbin, /lib or /lib64
by Jaroslav Skarvada 02 Oct '12

02 Oct '12

According to the packaging guidelines [1] packages for F17+ must not place files or directories into /bin, /sbin, /lib or /lib64. But it seems it is not possible with glibc [2] (and maybe others), thus I propose adding exceptions list to the guidelines thanks & regards Jaroslav [1] http://fedoraproject.org/wiki/Packaging:Guidelines#Filesystem_Layout [2] https://bugzilla.redhat.com/show_bug.cgi?id=860579

4 3

mp3 source (but not compiled) in squeak package
by Matthew Miller 01 Oct '12

01 Oct '12

I'm sure I've seen discussion of this before, but I can't find it in the mailing list, and https://fedoraproject.org/wiki/Forbidden_items?rd=ForbiddenItems#MP3_Support doesn't spell it out. The Squeak VM package in Fedora includes the upstream source code for MP3 support, but disables actually building it. Is that okay, or does the tarball need to be sanitized? -- Matthew Miller ☁☁☁ Fedora Cloud Architect ☁☁☁ <mattdm(a)fedoraproject.org>

4 15

requiring a (non-specific) font?
by Matthew Miller 30 Sep '12

30 Sep '12

I happened to install Scratch onto a remove VM (on Fedora Infrastructure's new private cloud, in fact) where no fonts were installed. It runs, but Pango throws warnings about not having anything for 'latin' or 'common' -- and of course the UI has boxes where the menus and variables should be. I could require something generic, like 'font(:lang=en)', but that's likely to pull in a random decorative font. I could require some specific font, but that seems wrong. (Particularly since if a "better" match for latin or common happen to be installed, whatever I said is a requirement will actually be irrelevant.) Orrr, should I just not worry about this case? -- Matthew Miller ☁☁☁ Fedora Cloud Architect ☁☁☁ <mattdm(a)fedoraproject.org>

5 5

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

packaging October 2012