About optflags
by Sergio Belkin
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
13 years, 3 months
Re: [Fedora-packaging] Removing -fexceptions from $RPM_OPT_FLAGS
by Pierre-Yves Chibon
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.
13 years, 3 months
RFC: packaging of PhotoFilmStrip
by Mario Torre
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/
13 years, 3 months
Re: [Fedora-packaging] rawhide report: 20110107 changes
by Thomas Spura
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.2Frep...
13 years, 3 months