packaging January 2011

packaging@lists.fedoraproject.org

25 participants
17 discussions

About default mtune=atom
by Sergio Belkin 24 Jan '11

24 Jan '11

Hi, I've read on http://fedoraproject.org/wiki/Packaging:RPMMacros#Build_flags_macros_and_va… that mtune=atom. Just because I'm curious, why? :) Thanks in advance! -- -- Sergio Belkin http://www.sergiobelkin.com Watch More TV http://sebelk.blogspot.com LPIC-2 Certified

2 1

Macro %{optflags}
by Sergio Belkin 23 Jan '11

23 Jan '11

Hi, Does Makefile flags from the tarball overrides %{optflags} ? Thanks in advance! -- -- Sergio Belkin http://www.sergiobelkin.com Watch More TV http://sebelk.blogspot.com Sergio Belkin -

5 10

About optflags
by Sergio Belkin 23 Jan '11

23 Jan '11

Hi, I am trying to build a RPM, I've found that optflags value is -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 Is it allowed to override "-O2" and use instead "-O3"? I see that those flags overrides those CXXFLAGS from Makefile sources. Thanks in advance! -- -- Sergio Belkin http://www.sergiobelkin.com Watch More TV http://sebelk.blogspot.com LPIC-2 Certified

4 5

Reviewing Tryton applicaiton modules
by Dan Horák 19 Jan '11

19 Jan '11

Hello all, I'm the owner of Tryton Feature for F-15 [1] and I need to add about 50 packages containing the application modules into Fedora. The source archives of the modules have a common structure so there is spec file generator that can prepare the spec files from a template. Their bugfix releases are done independently, so they can't be part of one big source package. My question is whether I could do the formal review on one of the modules, update the spec generator as required, refresh the spec files and then somehow mass-import the rest. I don't see much value in opening 50 reviews when they all would be the same, only the package name would differ. Naturally the whole process could be scripted ... the actual spec files are at http://fedora.danny.cz/tryton/modules/ the generator is http://fedora.danny.cz/tryton/modules/tryton-module2spec and corresponding template is http://fedora.danny.cz/tryton/modules/tryton-module2spec.template a placeholder bugzilla for the initial module review is https://bugzilla.redhat.com/show_bug.cgi?id=670860 Dan [1] https://fedoraproject.org/wiki/Features/Tryton

3 2

Re: [Fedora-packaging] Removing -fexceptions from $RPM_OPT_FLAGS
by Pierre-Yves Chibon 19 Jan '11

19 Jan '11

Hi, Although the original thread on devel(a)l.fp.o brought some feedbacks, the original question have not really been answered so I am bringing the question here. Is this a review blocker or should i just go on with the review ? Thanks for your help, Pierre On Tue, 2011-01-18 at 23:33 +0100, Pierre-Yves wrote: > Hi, > > I have been looking into the review #668863 in which the packager for > this library (who also happens to be upstream) is actually removing the > flag "-fexceptions" from $RPM_OPT_FLAGS in the %build. > > Asking this question on irc (on fedora-devel) as lead to a small > discussion without clear agreement. > > Unfortunately, my knowledge of C++ is not sufficient for me to take a > decision and I therefore would like to know if this would be a blocker > for the review. > > I have to say: > - The package compiles with and without the flag > - Upstream does not want to have this flag on, saying that if an > exception occurs the program should crash anyway (that is its expected > behavior)*. > > Thanks for your help, > > Pierre > > > * That is if I understood correctly.

1 0

RFC: packaging of PhotoFilmStrip
by Mario Torre 11 Jan '11

11 Jan '11

Hello all! I am in the process to package a simple application for creating short movies from a set of photos. The application is called PhotoFilmStrip and can be found here: http://www.photofilmstrip.org/ I initially submitted to RPM Fusion because of the dependency on mencoder, but a reviewer from RPM Fusion noticed that the application can be used without this dependecy, although it cannot output (render) the movie. This means that we can include in in Fedora, but keep a meta-package with the appropriate dependecy on mencoder to enable the rendering. I'm not entirely sure how this application could be useful if we remove the render functionality, though, as it's pretty limited otherwise and the risk is to give users the wrong perception that a fedora package is simply broken. There is also another problem, without mencoder, when clicking to the render box, I get a stack trace instead of a warning to install mencoder, so, at the very minimum, the app should be patched to allow a nice dialog instead of a scaring python stack trace. I will try to get in touch with the author to see if he is interested in fixing this behaviour (and perhaps if he wants to add support to WebM and Theora), but I would like to know what is the current guideline for issues such as this? Thanks, Mario -- pgp key: http://subkeys.pgp.net/ PGP Key ID: 80F240CF Fingerprint: BA39 9666 94EC 8B73 27FA FC7C 4086 63E3 80F2 40CF Proud GNU Classpath developer: http://www.classpath.org/ Read About us at: http://planet.classpath.org OpenJDK: http://openjdk.java.net/projects/caciocavallo/ Please, support open standards: http://endsoftpatents.org/

2 2

Re: [Fedora-packaging] rawhide report: 20110107 changes
by Thomas Spura 07 Jan '11

07 Jan '11

On Fri, 07 Jan 2011 10:01:17 -0500 seth vidal wrote: > On Fri, 2011-01-07 at 09:35 -0500, Andre Robatino wrote: > > Updating python on x86_64 tries to pull in 32-bit packages > > (including one i386): > > > > [root@localhost ~]# yum update python > > Loaded plugins: downloadonly, langpacks, presto, refresh-packagekit, > > security > > Adding en_US to language list > > Setting up Update Process > > Resolving Dependencies > > --> Running transaction check > > ---> Package python.x86_64 0:2.7.1-1.fc15 will be updated > > --> Processing Dependency: python = 2.7.1-1.fc15 for package: > > tkinter-2.7.1-1.fc15.x86_64 > > ---> Package python.i686 0:2.7.1-3.fc15 will be obsoleting > > --> Processing Dependency: python-libs(x86-32) = 2.7.1-3.fc15 for > > package: python-2.7.1-3.fc15.i686 > > Looks like it is replacing python-argparse? > > An obsolete will pull in both archs, I believe. > > -sv Yes, it now has this in it: Provides: python-argparse = %{version}-%{release} Obsoletes: python-argparse < 1.1-3 What would be the best solution for that now? Maybe this?: Provides: python-argparse = %{version}-%{release}%{?_isa} python-argparse itself was noarch, so this makes no sense either to me... (CC'ing fpc) At [1], there is no such case documented... Thomas [1]http://fedoraproject.org/wiki/Packaging:NamingGuidelines#Renaming.2Frepla…

2 1

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

packaging January 2011