On Mon, 2011-03-28 at 16:55 +0200, Karel Klíč wrote:
> Mark Wielaard writes:
> > eu-readelf does a lot more than you seem to need (you want to at least
> > use --numeric-addresses, so it doesn't try to map all addresses it
> > prints out to the associated symbol names).
> >
> > Attached is a littl
Jan Kratochvil writes:
> On Mon, 28 Mar 2011 16:55:35 +0200, Karel Klíč wrote:
>> I have observed GDB displaying wrong source file lines when stepping through
>> a program several times, and I think such a check could discover some
>> issues.
>
> Could you provide a reproducer?
I have never tried
On Mon, 28 Mar 2011 16:55:35 +0200, Karel Klíč wrote:
> I have observed GDB displaying wrong source file lines when stepping through
> a program several times, and I think such a check could discover some
> issues.
Could you provide a reproducer? How it could be fixed by the package
maintainer?
Mark Wielaard writes:
> On Fri, 2011-03-18 at 21:00 +0100, Karel Klíč wrote:
>> eu-readelf -winfo/-wline output is huge, so it takes several days to
>> make one attampt to check whole rawhide repository. This slows
>> development a bit.
>
> eu-readelf does a lot more than you seem to need (you wan
On Fri, 2011-03-18 at 21:00 +0100, Karel Klíč wrote:
> eu-readelf -winfo/-wline output is huge, so it takes several days to
> make one attampt to check whole rawhide repository. This slows
> development a bit.
eu-readelf does a lot more than you seem to need (you want to at least
use --numeric-add
Jan Kratochvil writes:
> On Thu, 24 Feb 2011 09:28:10 +0100, Karel Klic wrote:
>> Is there something else that should be checked?
>
> Sometimes references to the source file dirname/filename are broken.
>
> One fix for all packages:
> debugedit: Include empty CU current directories
> h
On Fri, Mar 04, 2011 at 03:08:37PM +0100, Karel Klic wrote:
> I modified the script to skip OCaml-generated packages. There seem to be
> no reasonable way to correctly detect OCaml-generated _binaries_.
I had a quick look at ELF headers and so on, but I think you are
right. One issue is that no
Ben Boeckel wrote:
> Anything with ghc-* can be ignored; ghc does not have debuginfo in its
> libraries. A list of other Haskell packages which don't fit the ghc-*
> pattern can be gathered as well.
Ok, I modified the script to skip Haskell packages. The list is not
needed, a simple detection log
Richard W.M. Jones wrote:
> On Thu, Feb 24, 2011 at 09:28:10AM +0100, Karel Klic wrote:
>> component: cduce (rjones)
>> file: cduce-0.5.3-8.fc15.i686/usr/bin/cduce
>>- debuginfo missing; ELF stripped
>> file: cduce-0.5.3-8.fc15.i686/usr/bin/dtd2cduce
>>- debuginfo missing; ELF stripped
Richard W.M. Jones wrote:
> The OCaml compiler doesn't generate DWARF output (because nothing at the
> moment could consume it, so what would be the point).
Uh, GDB could consume it (for ocamlopt native compilation, not for bytecode
compilation, of course), you can use GDB to debug languages not
On Thu, Feb 24, 2011 at 09:28:10AM +0100, Karel Klic wrote:
> component: cduce (rjones)
> file: cduce-0.5.3-8.fc15.i686/usr/bin/cduce
> - debuginfo missing; ELF stripped
> file: cduce-0.5.3-8.fc15.i686/usr/bin/dtd2cduce
> - debuginfo missing; ELF stripped
This and many of the other ones that
On Thu, 24 Feb 2011 09:28:10 +0100, Karel Klic wrote:
> Is there something else that should be checked?
Sometimes references to the source file dirname/filename are broken.
One fix for all packages:
debugedit: Include empty CU current directories
https://bugzilla.redhat.com/show_b
Karel Klic wrote:
> component: kdissert (rdieter)
> file: kdissert-1.0.7-8.fc15.i686/usr/lib/kde3/libkdissapplet.so
> - debuginfo missing; ELF is not stripped
> file: kdissert-1.0.7-8.fc15.i686/usr/lib/kde3/libkdisshtmldoc.so
> - debuginfo missing; ELF is not stripped
> file: kdissert-1.0.7-8.fc15.
Ben Boeckel wrote:
> Anything with ghc-* can be ignored; ghc does not have debuginfo in its
> libraries. A list of other Haskell packages which don't fit the ghc-*
> pattern can be gathered as well.
Actually, GHC has something somewhat equivalent to debuginfo, but it's in a
completely different fo
On 02/24/2011 10:33 AM, Radek Vokál wrote:
> Thanks Karel, I vote for opening bugs for all of these. Especially those
> which are ELF stripped might even have wrong compiler flags.
See also https://bugzilla.redhat.com/show_bug.cgi?id=DebugInfo
These have been caught by debugrepo-check [1] which
Haïkel Guémar wrote:
> Not sure, at least, it is used in kernel and glibc spec. Also mentionned
> in the RPM package creation howto featured in Packages Maintainer wiki page.
Actually, we don't generate -debuginfo packages[1], so I'd say the
script is looking for the debuginfo for the libs, not f
> On Thu, 24 Feb 2011 09:28:10 +0100,
> "KK" == Karel Klic wrote:
KK> component: Canna (tagoh)
KK> file: Canna-3.7p3-31.fc15.i686/usr/bin/cannaping
KK>- debuginfo missing; ELF stripped
KK> file: Canna-3.7p3-31.fc15.i686/usr/sbin/cannaserver
KK>- debuginfo missing; ELF stripped
Roland McGrath wrote, at 02/25/2011 10:16 AM +9:00:
>> component: CCfits (sergiopr)
>>file:
>> CCfits-debuginfo-2.3-2.fc15.i686/usr/lib/debug/.build-id/da/7236759b8c63fab2925bd308123b9b277a238c
>> - unused debuginfo, binary is not packaged: /usr/bin/cookbook
>
> The debuginfo is collected
> component: CCfits (sergiopr)
> file:
> CCfits-debuginfo-2.3-2.fc15.i686/usr/lib/debug/.build-id/da/7236759b8c63fab2925bd308123b9b277a238c
>- unused debuginfo, binary is not packaged: /usr/bin/cookbook
The debuginfo is collected from the %buildroot directories. There is an
rpmbuild check
Le 25/02/2011 02:13, Ben Boeckel a écrit :
> Haïkel Guémar wrote:
>> %define _enable_debug_packages %{nil}
>> %define debug_package %{nil}
>
> Is the first required now? Currently only the second is used.
>
> http://pkgs.fedoraproject.org/gitweb/?p=ghc-libmpd.git;a=blob;f=ghc-libmpd.spe
Haïkel Guémar wrote:
> %define _enable_debug_packages %{nil}
> %define debug_package %{nil}
Is the first required now? Currently only the second is used.
http://pkgs.fedoraproject.org/gitweb/?p=ghc-libmpd.git;a=blob;f=ghc-libmpd.spec;h=4696b69987012aaedc81160fe1dd7b72235b70c9;hb=HEAD
-
Le 25/02/2011 01:57, Ben Boeckel a écrit :
> Karel Klic wrote:
>
>
> Anything with ghc-* can be ignored; ghc does not have debuginfo in its
> libraries. A list of other Haskell packages which don't fit the ghc-*
> pattern can be gathered as well.
>
> --Ben
>
why not just disabling debuginfo g
Karel Klic wrote:
Anything with ghc-* can be ignored; ghc does not have debuginfo in its
libraries. A list of other Haskell packages which don't fit the ghc-*
pattern can be gathered as well.
--Ben
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/lis
On Thu, 24 Feb 2011 16:53:07 +0100, Karel wrote:
> Is this explanation understandable?
Yes.
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
On 24.2.2011 at 16:17, Michael Schwendt wrote:
> On Thu, 24 Feb 2011 09:28:10 +0100, Karel wrote:
>
>> - debuginfo symlink points to another binary in another RPM package
>> which might not be installed
>>
>
> Which is perfectly normal for subpackages, isn't it?
>
> There is only a single -
On Thu, 24 Feb 2011 09:28:10 +0100, Karel wrote:
>- debuginfo symlink points to another binary in another RPM package which
> might not be installed
>
Which is perfectly normal for subpackages, isn't it?
There is only a single -debuginfo package for a src.rpm, but the src.rpm
may build mult
On Thu, 24 Feb 2011 09:28:10 +0100, Karel Klic wrote:
> I have written a script which checks the completeness and correctness of the
> debuginfo packages.
Thanks, it would be great to run it automatically like the `Broken deps'
checker.
> Regarding the report below: it is interesting that /usr/b
27 matches
Mail list logo
