[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: RFS: xfe (updated package - new upstream release)

Hello Rogério, 

Am Thu, 19 Nov 2009 04:45:42 -0200 schrieb
Rogério Brito <rbrito@ime.usp.br>:

> You should still give a hint (a short phrase is enough) that other
> people worked on the package and give them credit.

> > > * you can remove comments from the watch file.
> > Some lines came from the template.
> Just kill them. The templates serve as examples for people to know what
> values to put in the appropriate fields.

> > > * why do you have two patches to xferc? The patches have no comments on
> > >   them (See DEP-3).
> > I should use better names for patches.
> Right. If you find some time, just put a description there so that
> people that will possibly make a non-maintainer upload understand why
> the patch is there.

> > > * why does it get compiled with -O3? Why not -O2? Why not -Os
> > >   (especially useful for machines without a lot of cache).
> > I think this should be checked together with upstream - that's right?
> No, this one should be fixed. Getting rid of the unconditional -O3, the
> -ffast-math, -fomit-frame-pointer and so on should be done as a way to
> control how the builds happen.
> 1 - Somebody may want to use the (Debian-policy described) variable
>     DEB_BUILD_OPTIONS=noopt to disable optimization (to hunt some potential
>     bug), but, as you package is right now, it always compiles with
>     optimizations turned on.
> These options get set in configure and configure.in. You can change
> those and convince upstream to flexibilize things a little bit.
The upstream author hase defined in configure[.in]:

  if test "x$enable_debug" = "xyes" ; then
  elif test "x$enable_release" = "xyes" ; then
    if test "${GXX}" = "yes" ; then
      CXXFLAGS="${CXXFLAGS} -O3 -Wuninitialized -ffast-math \
               -fomit-frame-pointer -fno-strict-aliasing" fi

Should I remove / reduce (per patch) this and define it in debian/rules?
At first step I have no "enable_debug" and no "enable_release", so it
comes only with "-O2".

> > > * can't you compile the C++ code with -Wextra and -Weffc++? This way,
> > >   more warnings could be emitted and some potential bug that is lurking
> > >   there would just be discovered soon.
> > I can do it for testing. But I think this is the job for the upstream
> > developer, isn't it?
> Yes, it is. But it already reveals some code improvements.
Ok, I will look for.

> Oh, as a last point, just give a look at the output of lintian. It's
> telling some things that are ultra-easy to fix.
Lintian seems clean (with version 2.2.18).

Thanks for your detailed support!

Fondest regards,
 Joachim Wiedorn

Attachment: signature.asc
Description: PGP signature

Reply to: