packaging November 2012

packaging@lists.fedoraproject.org

13 participants
7 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

need review
by Philippe Makowski 22 Nov '12

22 Nov '12

Hi, is there someone that can review this package ? https://bugzilla.redhat.com/show_bug.cgi?id=875506 thanks

1 0

How important is %{_libdir} to arch-specific but non-multilib packages
by Toshio Kuratomi 19 Nov '12

19 Nov '12

In discussing the new Java Guidelines, we've run into the question of whether arch-sepcific but non-multilib packages need to use %{_libdir} for files or if they can be placed in %{_prefix}/lib/ on all arches. Although this is a question brought to the fore by java, it also has bearing on other situations. For instance, this fesco ticket: https://fedorahosted.org/fesco/ticket/969 could also be affected by this question. (as noted by rdieter here: https://fedorahosted.org/fpc/ticket/158#comment:3 ) Although we could grant a special case exception just for java, I think that would be unfair. Making this decision on the more generic level and applying it to java, systemd, and other packages makes more sense to me. So what are thoughts on allowing both 32bit and 64bit binaries into %{_prefix}/lib if those binaries are not part of a package that will be %multilib'd? -Tosio

7 15

should packages be changed to use libexec?
by Matthew Miller 07 Nov '12

07 Nov '12

The Squeak VM package has several possible interpretters -- for example, a an experimental JIT version, and a version which handles 64-bit images (a separate issue from the arch of the system they're running on). There's also a helper binary used solely to determine the bit-size format of an image. Right now, these are all in %{libdir}/squeak/ with the plugins. A script installed as /usr/bin/squeak has the logic which calls them. And in the current test package, it's failing because the script doesn't understand about /usr/lib64 If this stuff were packaged in the upstream to use /usr/libexec/squeak/, then this would fit with the Fedora packaging guidelines and the /usr/bin script wouldn't have to be tricky. It's not, though. In this case, is it better to package the binaries into /usr/libexec/squeak, or is it better to patch the bin script to know about lib64? And in that case, is it better to patch the script for the right path at rpm build time, or use runtime detection logic? -- Matthew Miller ☁☁☁ Fedora Cloud Architect ☁☁☁ <mattdm(a)fedoraproject.org>

2 1

Re: [Fedora-packaging] [Bug 874105] New: Review Request: qpid-proton - Proton is a high performance, lightweight messaging library
by Darryl L. Pierce 07 Nov '12

07 Nov '12

On Wed, Nov 07, 2012 at 02:01:30PM +0000, bugzilla(a)redhat.com wrote: > https://bugzilla.redhat.com/show_bug.cgi?id=874105 > > Bug ID: 874105 > QA Contact: extras-qa(a)fedoraproject.org > Severity: unspecified > Version: rawhide > Priority: unspecified > CC: notting(a)redhat.com, > package-review(a)lists.fedoraproject.org > Assignee: nobody(a)fedoraproject.org > Summary: Review Request: qpid-proton - Proton is a high > performance, lightweight messaging library > Regression: --- > Story Points: --- > Classification: Fedora > OS: Unspecified > Reporter: dpierce(a)redhat.com > Type: Bug > Documentation: --- > Hardware: Unspecified > Mount Type: --- > Status: NEW > Component: Package Review > Product: Fedora > > Spec URL: http://mcpierce.fedorapeople.org/rpms/qpid-proton.spec > SRPM URL: http://mcpierce.fedorapeople.org/rpms/qpid-proton-0.2-1.fc17.src.rpm > Description: Proton is a high performance, lightweight messaging library. It > can be used in the widest range of messaging applications including brokers, > client libraries, routers, bridges, proxies, and more. Proton is based on the > AMQP 1.0 messaging standard. Using Proton it is trivial to integrate with the > AMQP 1.0 ecosystem from any platform, environment, or language. > Scratch build: http://koji.fedoraproject.org/koji/taskinfo?taskID=4662498 > Fedora Account System Username: mcpierce I'm willing to swap reviews to get this package through the process. -- Darryl L. Pierce <mcpierce(a)gmail.com> http://mcpierce.multiply.com/ "What do you care what people think, Mr. Feynman?"

1 0

SPEC for multiple python versions
by Jakov Sosic 06 Nov '12

06 Nov '12

Hi. First of all I don't know if this is the right list to ask this question - because I'm packaging primarily for CentOS/RHEL 5/6, and not Fedora... so if it's not please direct me to the right list. And now to my main question. I want to write SPEC file for python module, that should build on multiple versions of python and both CentOS 5 and 6. I need two defines - pyver and pybasever. If I hardcode them in my spec file -> I cannot override them from rpmbuild command line, so what's the right approach for this problem? I'm trying to write spec file for following combinations: CentOS/RHEL 5 + native python (2.4) CentOS/RHEL 5 + python26 (from EPEL) CentOS/RHEL 6 + native python (2.6) CentOS/RHEL 6 + python27 (my own RPM's) and maybe some other combination too. So far I've got this on top of my spec file: %if ! 0%{?pybasever:1} %define pybasever 2.6 %endif %define __python /usr/bin/python%{pybasever} %define pyver %(%{__python} -c "import sys ; print sys.version[:3].replace('.','')") If I build package with just: rpmbuild -ba my.spec' then python 2.6 i used, and If I specify: rpmbuild -ba my.spec --define 'pybasever 2.x' then python 2.x is used. Is this by any means OK?

2 1

is /etc/cron.*/* config file?
by Miroslav Suchý 05 Nov '12

05 Nov '12

Lets have this rpmlint error: hylafax+.x86_64: E: executable-marked-as-config-file /etc/cron.daily/hylafax My question is: Is /etc/cron.*/* files config file or not? We have both precedence in Fedora. E.g package cups do not mark /etc/cron.daily/cups as config file, but package tmpwatch mark /etc/cron.daily/tmpwatch as config file. -- Miroslav Suchy Red Hat Systems Management Engineering

3 2

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

packaging November 2012