On Fri, Apr 10, 2009 at 2:33 AM, Mat Booth wrote:

On Wed, Apr 8, 2009 at 9:07 PM, Ville Skyttä wrote:

...

Hello,

Quite a few packages that produce *-debuginfo without sources have crept again in rawhide.  See https://fedoraproject.org/wiki/Packaging/Debuginfo for possible reasons, the most usual of which in my (past, haven't checked this batch that closely) experience is failure to honor $RPM_OPT_FLAGS during build which can also mean that the default security related compiler flags aren't being applied either.

List of such packages identified by my debuginfo-check.py is attached (ownership info generated with Thorsten's fedoradev-pkgowners).  I intend to submit debuginfo-check.py to yum-utils (probably as debugrepo-check) and have added a similar check in upstream svn rpmlint, hopefully with these additions people will start noticing the issues easier.

Maintainer   Package                     Co-maintainers

mbooth       brazil                      (none)

This is a Java package that is AOT compiled for GCJ so the RPM flags are beyond my control. Compilation is done by the aot-compile-rpm script from the java-1.5.0-gcj-devel package. What do I need to do (if anything)?

Do you see error messages during find-debuginfo stage, such as in this bug? https://bugzilla.redhat.com/show_bug.cgi?id=472292

If so, sometimes (underlined), passing -g to javac helps. If you are using ant, try to add debug="on" on the javac part of your build.xml

Orcan

On Wednesday 08 April 2009, Ville Skyttä wrote:

Hello,

Quite a few packages that produce *-debuginfo without sources have crept again in rawhide. See https://fedoraproject.org/wiki/Packaging/Debuginfo for possible reasons, the most usual of which in my (past, haven't checked this batch that closely) experience is failure to honor $RPM_OPT_FLAGS during build which can also mean that the default security related compiler flags aren't being applied either.

Unfortunately there hasn't been much movement in getting these fixed. Updated list follows, after a while I'll file bugs for the remaining ones and/or excercise provenpackager rights in CVS but it'd be better if maintainers took care of these as appropriate before that.

Maintainer Package Co-maintainers ---------------------------------------------------------------- aconway rhm nsantos alexlan pvm (none) amdunn why (none) athimm mediawiki (none) ausil elftoaout pjones,spot,jima awjb multisync (none) bjensen colrdx sindrepb,sconklin,dp67 bonii moe (none) caolanm sac (none) ctyler nled overholt cweyl perl-DBI-Dumper perl-sig cwickert emelfm2 (none) dbhole antlr (none) dbhole jakarta-commons-logging overholt,kasal dbhole sinjdoc (none) dcbw csound pfj dchen libchewing i18n-team dchen tomoe-gtk i18n-team,ryo deji atlas deji devrim byaccj dbhole devrim postgresql-odbcng (none) devrim regexp (none) dledford lam (none) drepper pfstools (none) dwalluck hamcrest (none) dwheeler zenon pertusus fab rfdump (none) fab timespan (none) fnasser gnu-getopt (none) gemi curry (none) gemi erlang (none) gemi GtkAda (none) gemi wings (none) green phasex (none) guthrie simplyhtml (none) ianweller csstidy (none) ifoox mysql-connector-java (none) itamarjp balance (none) ixs ddrescue (none) ixs hevea (none) jkeating email2trac (none) jmagne esc (none) jsafrane freeipmi pknirsch jsafrane OpenIPMI pknirsch jwrdegoede elice (none) jwrdegoede lostlabyrinth (none) kasal transfig pertusus kdudka curl (none) konradm genus2reduction (none) konradm taginfo (none) kvolny vodovod (none) langel bouncycastle langel,oget laxathom gammu (none) limb astromenace (none) limb planets mmahut limb wesnoth wtogami linville b43-fwcutter (none) makghosh qps (none) maxamillion ifstatus (none) maxamillion ninvaders (none) maxamillion shed (none) mbooth brazil (none) mmahut nightfall astronomy-sig mwringe xerces-j2 (none) ovasik star mildew overholt jython jmatthews pcheung avalon-logkit (none) pcheung concurrent (none) pcheung jakarta-commons-httpclient akurtakov pfj mono-debugger (none) pvrabec sectool jhrozek,mildew rishi osmo (none) rrankin denemo (none) sconklin splat bjensen,dp67 sergiopr blitz (none) sindrepb xdotool (none) snecker libflaim (none) tanguy gperiodic (none) terjeros simdock (none) thias gentoo (none) twaugh cups (none) verdurin gnomint (none) wart wormux (none) wtogami ldm toshio,pertusus,eharrison,ryan52 zprikryl libtrash (none) (orphan) olpc-utils dcbw,johnp

On Sunday 19 April 2009, Debarshi Ray wrote:

I am sure rpmlint used to indicate when debuginfos were empty.

It did, and it still does. But this package is not empty:

[rishi@ginger x86_64]$ rpm --list -qp osmo-debuginfo-0.2.4-5.fc11.x86_64.rpm /usr/lib/debug /usr/lib/debug/.build-id /usr/lib/debug/.build-id/97 /usr/lib/debug/.build-id/97/8fa669630401596774b8c60d2ed8e857becc26 /usr/lib/debug/.build-id/97/8fa669630401596774b8c60d2ed8e857becc26.debug /usr/lib/debug/usr /usr/lib/debug/usr/bin /usr/lib/debug/usr/bin/osmo.debug

On the other hand, as mentioned in my first mail about these a week or so ago, catching the above case (debuginfo with no sources) was only recently implemented upstream, there's no release out with it yet: http://rpmlint.zarb.org/cgi-bin/trac.cgi/changeset/1581

I was unfortunately not able to get to the packages that are mine the other day, but I was able to start some work on them today. Here is my question at risk of sounding like I have no clue what I'm doing: "What process should I follow to verify that I have fixed the issue?". I read the wiki link that was posted (https://fedoraproject.org/wiki/Packaging/Debuginfo) and did verify that one of the packages in question (shed) had a -s in the install section of the makefile, so I created a patch for the Makefile.in and wanted to find a way to test the resulting package before submitting it as a patch or a fix.

Thank you, -Adam

On Monday 20 April 2009, Adam Miller wrote:

I was unfortunately not able to get to the packages that are mine the other day, but I was able to start some work on them today. Here is my question at risk of sounding like I have no clue what I'm doing: "What process should I follow to verify that I have fixed the issue?". I read the wiki link that was posted (https://fedoraproject.org/wiki/Packaging/Debuginfo) and did verify that one of the packages in question (shed) had a -s in the install section of the makefile, so I created a patch for the Makefile.in and wanted to find a way to test the resulting package before submitting it as a patch or a fix.

Quick surface check: build the package, look at the build logs and verify that the expected $RPM_OPT_FLAGS (not only -g) are there and that there are no "install -s", "gcc -s", "ld -s", "strip" or the like in it, run rpm -qlp (or rpmls) on the debuginfo package, verify that it contains both *.debug as well as source files. The new debuginfo package should also be larger, sometimes much larger, than the non-fixed one.

http://fpaste.org/paste/9713

I've looked through the output and this is with my patched Makefile.in and I really have no clue as to why the resulting debuginfo package has no sources

SRPM: http://maxamillion.fedorapeople.org/shed-1.15-2.src.rpm Spec: http://maxamillion.fedorapeople.org/shed.spec

Any help would be appreciated.

-Adam

On Tue, Apr 21, 2009 at 8:31 AM, Debarshi Ray debarshi.ray@gmail.com wrote:

...

Maintainer   Package                     Co-maintainers

gemi         erlang                      (none)

https://bugzilla.redhat.com/496851

Happy hacking, Debarshi -- One reason that life is complex is that it has a real part and an imaginary part.    -- Andrew Koenig

-- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list

Maintainer   Package                     Co-maintainers

dchen        libchewing                  i18n-team

https://bugzilla.redhat.com/496886

Happy hacking, Debarshi

How do I go about forcing those CFLAGS to be used? I was under the impression that if they are specified then they are used, the makefile appears to me that it supports the CFLAGS correctly, but I could be wrong.

-Adam

On Tue, Apr 21, 2009 at 9:32 AM, Jerry James loganjerry@gmail.com wrote:

On Tue, Apr 21, 2009 at 8:20 AM, Adam Miller maxamillion@gmail.com wrote:

...

http://fpaste.org/paste/9713

I've looked through the output and this is with my patched Makefile.in and I really have no clue as to why the resulting debuginfo package has no sources

SRPM:  http://maxamillion.fedorapeople.org/shed-1.15-2.src.rpm Spec:    http://maxamillion.fedorapeople.org/shed.spec

Any help would be appreciated.

-Adam

The CFLAGS you specified aren't being used.  Look at lines 76, 77, and 80.  There's no "-g" anywhere on those lines. -- Jerry James http://loganjerry.googlepages.com/

-- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list

I actually just got some help in #fedora-devel, thanks for the idea though. I've patched the configure script and works, i will push the update and then start working on my other packages.

-Adam

On Tue, Apr 21, 2009 at 11:15 AM, Jerry James loganjerry@gmail.com wrote:

On Tue, Apr 21, 2009 at 9:56 AM, Adam Miller maxamillion@gmail.com wrote:

...

How do I go about forcing those CFLAGS to be used? I was under the impression that if they are specified then they are used, the makefile appears to me that it supports the CFLAGS correctly, but I could be wrong.

-Adam

The problem is configure.in, which blows away anything you specified and rebuilds a set of CFLAGS from scratch.  Try this in your %prep section:

sed -i -e "s/CFLAGS="-Wall"/CFLAGS="${RPM_OPT_FLAGS}"/" configure

Jerry James http://loganjerry.googlepages.com/

-- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list

but out of curiosity, what's the reason for asking people to request F-11 freeze overrides for these fixes?

Because without them the debuginfos are pretty useless. So if we don't override the freeze and release them as zero-day updates, then, as far as I understand, a user who wants to use the debuginfo will have to pull in the updated package and the updated debuginfo, instead of just the debuginfo.

Other than that, the changes are pretty trivial. So why not get them in and have a polished F11 GA instead of burdening the average Joe user who likes to tell PK to "download all updates"? Not everyone has a nice broadband connection, you know. :-)

If compiler security features enabled by stuff in $RPM_OPT_FLAGS are not used it could be argued to be a potential security issue, is that why?

Yes, that is another reason, but to me having a polished GA looks more important.

Happy hacking, Debarshi

What steps are needed to get the package into the GA instead of as a zero day update?

Please request a freeze override for Fedora 11 according to https://fedoraproject.org/wiki/ReleaseEngineering/FinalFreezePolicy

Happy hacking, Debarshi

On Tuesday 21 April 2009, Matej Cepl wrote:

On 2009-04-21, 16:44 GMT, Ville Skyttä wrote:

...

On Tuesday 21 April 2009, Debarshi Ray wrote:

...

https://bugzilla.redhat.com/496897

[and others]

It would help more if there was a tracking bug which all these individual bugs would be blocking.

Done: https://bugzilla.redhat.com/show_bug.cgi?id=DebugInfo

Additionally, I know these packages have been fixed since I posted the previous list: freeipmi OpenIPMI osmo olpc-utils

The rest: https://fedoraproject.org/wiki/User:Scop/DebugInfoProblems

On Tue, Apr 21, 2009 at 3:20 PM, Jesse Keating jkeating@redhat.com wrote:

https://fedoraproject.org/wiki/Packaging:Guidelines#Compiler_flags could certainly use some details on /how/ to apply RPM_OPT_FLAGS correctly (and why aren't these just autoapplied?)

-- Jesse Keating Fedora -- Freedom² is a feature! identi.ca: http://identi.ca/jkeating

I've seen a number of cases where the upstream developers think they know the best compiler flags to use, so they ignore the usual means of supplying CFLAGS and just set their own. This means that the /how/ you are asking for involves manual inspection of configuration scripts and makefiles. Fun for the whole family!

On Tue, 2009-04-21 at 15:27 -0600, Jerry James wrote:

I've seen a number of cases where the upstream developers think they know the best compiler flags to use, so they ignore the usual means of supplying CFLAGS and just set their own. This means that the /how/ you are asking for involves manual inspection of configuration scripts and makefiles. Fun for the whole family!

In some cases yes, but in the general case, I had to do make %{?_smp_mflags} CFLAGS="$RPM_OPT_FLAGS"

and I had to google around to figure out where to stuff the RPM_OPT_FLAGS at. This kind of info should be in the guidelines.

On Di April 21 2009, Adam Miller wrote:

I fixed both ninvaders and shed, but ifstatus seems to be quite the pain. The makefile is lacking to say the least and I can't seem to figure out how to make it spit out a valid debuginfo rpm. When I got it reviewed, my reviewer had me make a comment in the spec about the fact that its makefile can't handle %{?_smp_mflags} ... is it possible that it just won't spit out a debuginfo?

If that's not a possibility, then I would greatly appreciate some direction. http://maxamillion.fedorapeople.org/ifstatus-1.1.0-3.src.rpm http://maxamillion.fedorapeople.org/ifstatus.spec

The Makefile uses the default target to create .o files from .cc files. You can run this in the spec to get the optflags into make (or adjust the Makefile patch to also set CXXFLAGS to RPM_OPT_FLAGS by default):

make "CXXFLAGS=%{optflags}"

Regards Till

Jesse Keating wrote:

On Tue, 2009-04-21 at 15:27 -0600, Jerry James wrote:

...

I've seen a number of cases where the upstream developers think they know the best compiler flags to use, so they ignore the usual means of supplying CFLAGS and just set their own. This means that the /how/ you are asking for involves manual inspection of configuration scripts and makefiles. Fun for the whole family!

In some cases yes, but in the general case, I had to do make %{?_smp_mflags} CFLAGS="$RPM_OPT_FLAGS"

and I had to google around to figure out where to stuff the RPM_OPT_FLAGS at. This kind of info should be in the guidelines.

Current paragraph: """ Compilers used to build packages should honor the applicable compiler flags set in the system rpm configuration. As of Aug 2006, this means in practice $RPM_OPT_FLAGS/%{optflags} for C, C++, and Fortran compilers. Honoring means that the contents of that variable is used as the basis of the flags actually used by the compiler during the package build. Adding to and overriding or filtering parts of these flags is permitted if there's a good reason to do so; the rationale for doing so should be reviewed and documented in the specfile especially in the override and filter cases. """

Proposed additional paragraph:

""" Most C, C++, and Fortran programs will pick up the correct compiler flags from the %configure macro. If your program does not use %configure the de facto standard is that C compiler flags are picked up via the CFLAGS make variable, C++ Compiler flags via the CXXFLAGS variable, and Fortran flags via FFLAGS. So, you could have something like this in your spec file:

<pre> make CFLAGS=%{optflags} all </pre>

If the build still does not pick up the proper compiler flags, you will have to look in the configure script or Makefiles to diagnose what's going on. """

If you guys like this, I'll propose it to the Packaging Committee.

-Toshio

On Wednesday 22 April 2009, Toshio Kuratomi wrote:

Proposed additional paragraph:

""" Most C, C++, and Fortran programs will pick up the correct compiler flags from the %configure macro. If your program does not use %configure [...]

I would make this less %configure centric, maybe something like:

... correct compiler flags if you use a macro that automatically sets them to build the package, such as %configure or %cmake (check macro contents with "rpm -E %somemacro" while redhat-rpm-config and the package possibly providing the macro in /etc/rpm/* is installed if unsure whether a macro sets them). If there are no such macros that would apply to your package, the de facto standard is that ...

make CFLAGS=%{optflags} all

This bit needs quotes around %{optflags}.

I am happy to say that my three packages from the list now have proper debuginfo packages and have been accepted for Fedora 11 Preview.

-Adam