Bug#976462: debian bug 976462

Hi Sean, On Wed, 2021-03-17 at 09:36 -0700, Sean Whitton wrote: > On Wed 10 Mar 2021 at 04:54PM +01, Mark Wielaard wrote: > > > For reference, this is the dwz bug for [dwz] Support compressed debug > > sections: https://sourceware.org/bugzilla/show_bug.cgi?id=24725 > >

Bug#976462: debian bug 976462

For reference, this is the dwz bug for [dwz] Support compressed debug sections: https://sourceware.org/bugzilla/show_bug.cgi?id=24725 It has low priority because it has a simple workaround: you could use eu-elfcompress before/after the dwz run $ eu-elfcompress --type=none ./a.out $ dwz ./a.out

Bug#966705: elfutils introduced a bootstrap loop via libmicrohttpd-dev

Hi Helmut, On Sun, Aug 02, 2020 at 07:57:00PM +0200, Helmut Grohne wrote: > I don't think that anything (in Debian) links > libdebuginfod at present. There is a list of programs here: https://sourceware.org/elfutils/Debuginfod.html We hope it will be used by any program that uses debuginfo. Ask

Bug#966705: elfutils introduced a bootstrap loop via libmicrohttpd-dev

er or just the client would be build: commit f7f0cdc59a13780938ae3f578955737a75e60ea9 Author: Mark Wielaard Date: Fri Jun 19 19:41:08 2020 +0200 debuginfod: Add --disable-libdebuginfod and --enable-libdebuginfod=dummy. Make it possible to build just the debuginfod client or

Bug#960644: valgrind: Doesn't support D programming language demangling

Hi, On Fri, 2020-05-15 at 02:28 +, Witold Baryluk wrote: > Package: valgrind > Version: 1:3.15.0-1 > Severity: normal > > It looks like valgrind doesn't support D programming language symbol > mangling (as emitted by DMD, GDC or LDC2 compilers); > > ==29535== valgrind: Unrecognised

Bug#931278: bzip2: Fix for CVE-2019-12900 breaks uncompressing some lbzip2 files

On Tue, 2019-07-09 at 22:06 +0200, Salvatore Bonaccorso wrote: > The patch seems to have evolved to > https://sourceware.org/ml/bzip2-devel/2019-q3/msg7.html. Were > there any more issues found? Should downstream distros who picked up > the CVE-2019-12900 safely include this patch? Yes. It

Bug#931278: bzip2: Fix for CVE-2019-12900 breaks uncompressing some lbzip2 files

Hi Salvatore, On Sun, 2019-06-30 at 19:28 +0200, Salvatore Bonaccorso wrote: > Testing and feedback appreciated. > > it is not very helpfull I think, because I do not have a good testing > corpus. What I did is to apply the patch on top of our current > 1.0.6-9.1 (which has the issue after

Bug#931278: bzip2: Fix for CVE-2019-12900 breaks uncompressing some lbzip2 files

See the upstream discussion on the bzip2-devel mailinglist: https://sourceware.org/ml/bzip2-devel/2019-q2/msg00024.html In particular this workaround patch for some (buggy lbzip2 compressed) files that bzip2 1.0.6 could decompress, but 1.0.7 (with the CVE-2019- 12900 hardening patch) cannot:

Bug#832456: elfutils: improve handling of DEB_BUILD_OPTIONS=nocheck

On Sun, Jun 17, 2018 at 09:11:54PM +0200, Helmut Grohne wrote: > it breaks architecture bootstrap. I am missing context I am afraid. But which architecture is broken atm? We do have an upstream buildbot for elfutils that checks various distro, architectures:

Bug#886004: elfutils should build without -Werror

On Tue, Jan 02, 2018 at 01:49:06PM +0100, Helmut Grohne wrote: > On Tue, Jan 02, 2018 at 10:57:44AM +0100, Mark Wielaard wrote: > > Could you please file a bug for that. I am not aware of any such issue. > > So would like to fix it, and would if I knew about it. Thanks. > &g

Bug#886004: elfutils should build without -Werror

BTW. I see two GCC8 related fixes in elfutils git since the last release: commit 268a27211b152d876185ff95255e5025c43b9c13 Author: Mark Wielaard <m...@klomp.org> Date:   Mon Nov 20 14:11:02 2017 +0100 libdwfl: Don't dereference possibly unaligned auxv entry pointer fro

Bug#886004: elfutils should build without -Werror

Hi Helmut, On Tue, 2018-01-02 at 09:42 +0100, Helmut Grohne wrote: > For example, it FTBFS with gcc-8 atm. Could you please file a bug for that. I am not aware of any such issue. So would like to fix it, and would if I knew about it. Thanks. > Even if that checking was happening in > practise,

Bug#886004: elfutils should build without -Werror

On Mon, Jan 01, 2018 at 01:53:00PM +0100, Helmut Grohne wrote: > elfutils upstream enables -Werror for compilation by default. This has > caused FTBFS with gcc-6 and gcc-7 and is going to cause FTBFS with gcc-8 > soon. Using -Werror is good if those issues are fixed proactively. > However that is

Bug#847096: elfutils: Does not build when using eatmydata

On Mon, 2016-12-05 at 16:17 +0100, Santiago Vila wrote: > I can't build this package from source when using eatmydata. The problem is that eatmydata defines an LD_PRELOAD library for the primary architecture. The run-backtrace-native-biarch.sh testcase tests the secondary (biarch) architecture

Bug#838203: valgrind: unusable on armhf: assertion 'sizeof(TTEntryC) <= 88' failed

On Sun, 2016-09-18 at 14:44 +0200, Eugene V. Lyubimkin wrote: > Package: valgrind > Version: 1:3.12.0~svn20160714-1+b1 > Severity: important > > Dear Maintainer, > > I've just attempted to use valgrind on the armel porterbox, > harris.debian.org. Here's what I got: > >

Bug#832456: elfutils: improve handling of DEB_BUILD_OPTIONS=nocheck

Hi, On Wed, 2016-07-27 at 18:16 +0200, Helmut Grohne wrote: > > I'm wondering if I should just disable the biarch tests on all > > arches and remove the gcc-multilib Depends completly. > > I won't disagree with that. > > Personally, I'd like to see biarch/multilib to die as soon as possible. >

Bug#831265: elfutils: FTBFS: tests failures

On Thu, 2016-07-14 at 11:52 +0200, Lucas Nussbaum wrote: > Source: elfutils > Version: 0.165-3 > Severity: serious > Tags: stretch sid > User: debian...@lists.debian.org > Usertags: qa-ftbfs-20160714 qa-ftbfs > Justification: FTBFS on amd64 > [...] > >

Bug#827441: systemtap: "print_stack_address" incompatible pointer type

On Thu, 2016-06-16 at 09:30 +0200, Ph. Marek wrote: > and I installed linux-image-4.6.0-1-amd64-dbg, but I don't quite see how > one of these could cause that error. > [...] > The problematic call in my stap file is "print_backtrace()" - if I comment > that out, I can compile, but that won't

Bug#752891: systemtap on ppc64el

On Wed, 2016-05-11 at 22:00 +0200, Vincent Bernat wrote: > ❦ 11 mai 2016 13:25 +0200, Philipp Marek : > > > Ubuntu ships systemtap for ppc64el, so it should "just work" - or at least > > not be any worse, right? ;) > > Well, it should compile, but has anybody run the

Bug#682101: Bug#662041: elfutils FTBFS on hurd-i386

On Sun, 2016-02-28 at 15:29 +0100, Samuel Thibault wrote: > Kurt Roeckx, on Thu 19 Jul 2012 18:54:01 +0200, wrote: > > I'm also happy with a patch that does the right thin on hurd that > > doesn't use /proc/$pid/maps. > > The maps file was added, it however for now lacks the paths. > > Perhaps

Bug#816394: elfutils: FTBFS[!linux] with gcc-6: unused const, functions

On Tue, 2016-03-01 at 14:18 +, Steven Chamberlain wrote: > elfutils will FTBFS on kfreebsd (and I suspect on hurd) with gcc-6, > because there is an unused const and several unused, unexported stub > functions in linux-pid-attach.c inside a code block guarded by > #ifndef __linux__ > > A

Bug#811600: FTBFS with GCC 6: statement indented as if it were guarded by

On Tue, 2016-01-19 at 16:08 -0800, Martin Michlmayr wrote: > > sbuild (Debian sbuild) 0.67.0 (26 Dec 2015) on dl580gen9-02.hlinux > ... > > g++ -DHAVE_CONFIG_H -I. -DBINDIR='"/usr/bin"' -DSYSCONFDIR='"/etc"' > > -DPKGDATADIR='"/usr/share/systemtap"' -DPKGLIBDIR='"/usr/lib/systemtap"' > >

Bug#810885: [PATCH] libelf: Add ELF compression types and defines to libelf.h for older glibc.

On Wed, 2016-01-13 at 18:37 +0100, Kurt Roeckx wrote: > On Wed, Jan 13, 2016 at 06:20:17PM +0100, Mark Wielaard wrote: > > > > Does the attached work for you? > > Yes. Thanks for testing. Pushed to master.

Bug#810885: [PATCH] libelf: Add ELF compression types and defines to libelf.h for older glibc.

/bugreport.cgi?bug=810885 Signed-off-by: Mark Wielaard <m...@redhat.com> --- libelf/ChangeLog | 5 + libelf/libelf.h| 28 tests/ChangeLog| 8 tests/Makefile.am | 9 +++-- tests/syst

Bug#810885: libelf-dev requires libc >= 2.22

On Wed, 2016-01-13 at 16:58 +0100, Kurt Roeckx wrote: > But maybe I can fix the installed headers to not require a newer > glibc version ... I just posted an upstream fix to do this: https://lists.fedorahosted.org/archives/list/elfutils-devel%

Bug#810885: [PATCH] libelf: Add ELF compression types and defines to libelf.h for older glibc.

On Wed, 2016-01-13 at 18:01 +0100, Kurt Roeckx wrote: > On Wed, Jan 13, 2016 at 05:22:35PM +0100, Mark Wielaard wrote: > > Older glibc elf.h might not define the new ELF compression defines and > > types. If not just define them in libelf.h directly to make the libelf > >

Bug#776362: closed by Hector Oron zu...@debian.org (Re: Bug#776362: dejagnu: spurious failures on multi-core setups)

On Fri, 2015-08-28 at 11:52 +, Debian Bug Tracking System wrote: It is fixed in stable distribution. Therefore I am closing this report. Just for the record, it has been fixed in dejagnu 1.5.3 which is now in stretch (testing). jessie (stable), still contains 1.5.1 with this bug.

Bug#794488: Piglit tests in Mesa crash, if radeonsi_dri.so is linked with libelf1 (libelfg0 works)

On Sat, Aug 08, 2015 at 10:58:15AM +0200, Kai Wasserbäch wrote: And there *IS* a difference vs. your output: for you the relocations in 794488_elfs/libelf1/dump.elf.J4EnbO look fine, for me the second relocation is botched with libelf1 while it works with libelfg0. libelf1: relocations: 2

Bug#794488: Piglit tests in Mesa crash, if radeonsi_dri.so is linked with libelf1 (libelfg0 works)

On Sat, Aug 08, 2015 at 12:31:54PM +0200, Kai Wasserbäch wrote: https://sources.debian.net/src/elfutils/0.163-4/debian/patches/0003-Add-mips-n64-relocation-format-hack.patch/?hl=34#L34 Note how that replaces the cast and sizeof Elf64_Rel with Elf64_Rela in the memcpy. Those are not the

Bug#794488: Re: Bug#794488: Piglit tests in Mesa crash, if radeonsi_dri.so is linked with libelf1 (libelfg0 works)

On Thu, Aug 06, 2015 at 05:14:25PM +0200, Kai Wasserbäch wrote: Could you compile the following with: gcc -g -lelf -o elfrel elfrel.c this does not work for several reasons: 1. I certainly need -std=c99 for the inline initialisation of the counter in the for() statement. Ah, yes, this

Bug#794488: Re: Bug#794488: Piglit tests in Mesa crash, if radeonsi_dri.so is linked with libelf1 (libelfg0 works)

On Wed, 2015-08-05 at 11:13 +0900, Michel Dänzer wrote: Note that the ELF object is actually created in LLVM. Do you happen to know whether that also uses libelf to generate the file? I am assuming there is some bug in the relocation section parsing and that the generated ELF images are

Bug#794488: Re: Bug#794488: Piglit tests in Mesa crash, if radeonsi_dri.so is linked with libelf1 (libelfg0 works)

On Wed, 2015-08-05 at 17:55 +0200, Kai Wasserbäch wrote: So, if I've understood you correctly, you want an ELF dump of a Mesa build linked against libelfg0 and one linked against libelf1. You can find the generated files in the attached Tar archive. Please note, that the run with libelf1 only

Bug#794488: Piglit tests in Mesa crash, if radeonsi_dri.so is linked with libelf1 (libelfg0 works)

On Tue, Aug 04, 2015 at 07:26:19PM +0200, Kai Wasserbäch wrote: Thanks that was really helpful. It looks like the real problem is the parsing of the relocation section. Would it be possible for you to dump the ELF image that is being parsed in radeon/radeon_elf_util.c (radeon_elf_read)

Bug#794488: Piglit tests in Mesa crash, if radeonsi_dri.so is linked with libelf1 (libelfg0 works)

On Mon, Aug 03, 2015 at 10:34:19PM +0200, Kai Wasserbäch wrote: Could you point me to the source code that does the libelf calls to create the ELF file? Maybe reading the source helps to figure out what might go wrong. The stacktrace from the test doesn't immediately seem to give a direct

Bug#794488: Piglit tests in Mesa crash, if radeonsi_dri.so is linked with libelf1 (libelfg0 works)

On Mon, Aug 03, 2015 at 05:44:01PM +0200, Kai Wasserbäch wrote: when I link my Mesa build against libelf1, some Piglit [0] tests start throwing SIGSEGVs. Two of those tests are spec@arb_gpu_shader_fp64@execution@fs-indirect-temp-double-{dst,src}. When I link Mesa (or more specifically my

Bug#794488: Piglit tests in Mesa crash, if radeonsi_dri.so is linked with libelf1 (libelfg0 works)

On Mon, Aug 03, 2015 at 08:31:12PM +0200, Kai Wasserbäch wrote: Steps to reproduce: This is going to be a bit hard for me to reproduce since I don't actually use Debian for development (sorry). I do work on upstream elfutils though. - you need a AMD GPU powered by the radeonsi driver I don't

Bug#753981: elfutils: FTBFS on hppa -- FAIL: run-strip-reloc.sh

On Wed, 2015-06-10 at 15:23 +0200, Helge Deller wrote: On 10.06.2015 08:58, Mark Wielaard wrote: - The hppa elfutils backend isn't upstream (yet?). That seems correct. Would upstream be willing to include the hppa patches? Sure. https://git.fedorahosted.org/cgit/elfutils.git/plain

Bug#775536: [Secure-testing-team] Bug#775536: CVE-2014-9447

/ptrace.h header, so let's use them. Annoyingly this will cause new elfutils to FTBFS on old glibc, and vice versa. So include a new configure check for the new struct names and use the old ones if they are not avilable. Signed-off-by: Kyle McMartin k...@redhat.com Signed-off-by: Mark

Bug#776362: dejagnu: spurious failures on multi-core setups

Package: dejagnu Version: 1.5-3 Severity: important Tags: upstream patch Dear Maintainer, A very old bug, that was only recently patched in upstream dejagnu, but that has been fixed in some other distros, causes dejagnu when running on multiple cores to produce spurious errors/FAILs. Depending

Bug#775117: eu-make-debug-archive: spurious /usr/bin/eu-

On Sun, 2015-01-11 at 19:24 +0100, Jakub Wilk wrote: Package: elfutils Version: 0.159-4 Apparently eu-make-debug-archive fell victim to overzealous searchreplace: This was fixed upstream in elfutils 0.160 by: commit f1ec744b5747a3bd66297c9f965be6ea10cb7f86 Author: Josh Stone

Bug#766247: systemtap: fails to compile stp module, with message: semantic error: failed to retrieve location attribute for local 'bio'

On Wed, Oct 22, 2014 at 12:50:17PM +0300, Timo Juhani Lindfors wrote: semantic error: failed to retrieve location attribute for local 'bio' This wiki page has some pointers on how to debug such issues: https://sourceware.org/systemtap/wiki/TipContextVariables -- To UNSUBSCRIBE, email to

Bug#758905: valgrind: Valgrind needs updated suppressions

On Thu, Aug 28, 2014 at 07:05:12PM +0200, Alessandro Ghedini wrote: FWIW this doesn't happen on amd64 but I can reproduce on armhf (haven't tried any other platforms). It also doesn't seem to be fixed upstream. Depending on the glibc and arm version this might be:

Bug#752891: systemtap: build on ppc64el

On Thu, 2014-07-10 at 16:11 -0300, Mauricio Faria de Oliveira wrote: I built an elfutils package w/ your patches. The unexpected failures decreased by 24 (from 835 to 811). I'd like to submit those for Debian once the 2nd patch is accepted. (I believe it's close, for I haven't seen replies

Bug#752891: systemtap: build on ppc64el

BTW. From the systemtap README: Consider configuring with --enable-dejazilla to automatically contribute to our public test result database. That makes it easier to compare test results at https://web.elastic.org/~dejazilla/viewsummary.php Also since systemtap depends on elfutils you might

Bug#748694: sys/sdt.h is architecture specific, and causing issues on unsupported architectures

Hi Matthias, On Sat, 2014-07-05 at 17:01 +0200, Matthias Klose wrote: re-raising the severity of the issue, and preparing a NMU to move the header file to an architecture specific location. What is the issue you are seeing? I thought that what you saw was something unrelated to sys/sdt.h. And

Bug#748694: sys/sdt.h is architecture specific, and causing issues on unsupported architectures

On Sat, 2014-07-05 at 18:32 +0200, Matthias Klose wrote: could you tell me why you need the header on architectures that don't need it? Which architectures don't need it? Any architecture that support glibc and gdb for example benefits from having sdt markers available. -- To UNSUBSCRIBE,

Bug#753552: elfutils: FTBFS on arm64 (test failed)

On Thu, 2014-07-03 at 03:41 +0100, Wookey wrote: FAIL: run-native-test.sh /home/buildd/packages/elfutils-0.159/tests/funcretval: dwfl_module_return_value_location: cannot handle DWARF type description I've not yet worked out what the exact issue here is, or

Bug#753552: elfutils: FTBFS on arm64 (test failed)

Hi Wookey (and hi Petr, see below, this is a debian elfutils aarch64 backend bug report, see for full context http://bugs.debian.org/753552 but the below is probably all you'll need) On Thu, 2014-07-03 at 17:32 +0100, Wookey wrote: (/lib/aarch64-linux-gnu/libc-2.19.so) round_away:

Bug#750996: eglibc FTBFS on Alpha: malloc/malloc.os build failure and testsuite failures.

On Mon, 2014-06-09 at 18:02 +0200, Aurelien Jarno wrote: systemtap-sdt-dev was supposed to be something transparent for the glibc, but in practice it causes build failure on at least on alpha (see above). Looking at the BTS, I see it also causes problems with GCC, so I am a bit concerned on

Bug#750996: eglibc FTBFS on Alpha: malloc/malloc.os build failure and testsuite failures.

On Tue, 2014-06-10 at 21:25 +0200, Aurelien Jarno wrote: On Tue, Jun 10, 2014 at 08:10:00PM +0200, Mark Wielaard wrote: On Mon, 2014-06-09 at 18:02 +0200, Aurelien Jarno wrote: systemtap-sdt-dev was supposed to be something transparent for the glibc, but in practice it causes build

Bug#748694: sys/sdt.h is architecture specific, and causing issues on unsupported architectures

On Mon, 2014-05-19 at 22:53 +0200, Matthias Klose wrote: Am 19.05.2014 21:00, schrieb Mark Wielaard: It is just the package name that refers to systemtap, but it could as well have been called gdb-sdt-devel for example. In which case it should at least work as is on any arch gdb supports

Bug#748694: sys/sdt.h is architecture specific, and causing issues on unsupported architectures

On Mon, 2014-05-19 at 20:17 +0200, Matthias Klose wrote: The sys/sdt.h header file is shipped in an architecture independent package, and installed into /usr/include where it is found on the include path for every architecture. [...] what about issues on architectures not supported by

Bug#746426: gcc: Enable -fasynchronous-unwind-tables on more arches.

On Sun, 2014-05-18 at 16:37 +0200, Matthias Klose wrote: Is this enabled by any other distributions? On fedora and RHEL -fasynchronous-unwind-tables is enabled on all architectures for gcc (otherwise rpmbuild will add it as standard flag). So all packages are always build with it so you will

Bug#746426: gcc: Enable -fasynchronous-unwind-tables on more arches.

On Mon, 2014-05-19 at 00:03 +0200, Kurt Roeckx wrote: Am 30.04.2014 00:04, schrieb Kurt Roeckx: So reading about this, this might break glibc when you enable it and they might need to build some files without it. Is this enabled by any other distributions? I assume this is enabled

Bug#740233: parse_type_DIE: confused by: 1275c: DW_TAG_array_type

On Thu, 2014-02-27 at 11:15 +0100, Mathieu Malaterre wrote: Package: valgrind Version: 1:3.7.0-6 Looks like sgcheck does not like something: parse_type_DIE: confused by: 1275c: DW_TAG_array_type DW_AT_type: 8 byte signature: 14 38 5f 4d 24 66 cc 9e DW_AT_sibling :

Bug#736994: valgrind: stair-step indented list items in valgrind(1) manpage

On Wed, 2014-01-29 at 00:48 -0500, Samuel Bronson wrote: Package: valgrind Version: 1:3.9.0-4 Severity: normal File: /usr/share/man/man1/valgrind.1.gz (Maybe later I'll feel up for finding out what's *really* going wrong and reporting that against docbook-xsl.) This is upstream bug

Bug#730019: systemtap: insufficient versionned builddep on libdw-dev friends

On Thu, 2013-11-21 at 09:03 +0100, Yann Dirson wrote: Yes, I was ready to do some backporting - I would have backported elfutils if required, I'm just glad 1.7 was less work :) If this is just for sys/sdt.h then that should be fine. But you might want to incorporate the fix for

Bug#649038: elfutils FTBFS on kfreebsd

On Mon, 2013-11-11 at 23:31 +0100, Robert Millan wrote: On 11/11/2013 15:32, Mark Wielaard wrote: On Sun, 2013-11-10 at 00:45 +0100, Robert Millan wrote: Nothing as far as ELF compliance is concerned. This tag is ment to be consumed by the kernel ELF loader only. For elfutils elflint

Bug#649038: elfutils FTBFS on kfreebsd

On Sun, 2013-11-10 at 00:45 +0100, Robert Millan wrote: ELFOSABI_FREEBSD indicates this binary has been built to run on kFreeBSD and uses its kernel ABI. If a binary is set to ELFOSABI_LINUX, then the kernel will enable Linux emulation mode, i.e. Linux syscall interface. Aha. Interesting.

Bug#728539: elfutils: eu-readelf crashes when reading a shared library

On Sun, Nov 03, 2013 at 02:58:54AM +0100, Kurt Roeckx wrote: On Sat, Nov 02, 2013 at 10:06:20PM +0100, Mark Wielaard wrote: Although the public ABI of libelf is stable and should never break, the elfutils tools (at least readelf) also use some internals from libelf, which isn't public ABI

Bug#728539: elfutils: eu-readelf crashes when reading a shared library

On Sun, Nov 03, 2013 at 02:28:45PM +0100, Kurt Roeckx wrote: The problem actually seems to be that I removed the configure option --enable-thread-safety. Not sure how exactly this has an effect yet. That changes the definition of rwlock_define as used in the internal libelfP.h struct Elf,

Bug#728539: elfutils: eu-readelf crashes when reading a shared library

On Sun, 2013-11-03 at 15:53 +0100, Kurt Roeckx wrote: I missed that part about rwlock_define. I know also see that struct Elf is used in libelf.h, and things start to make sense to me. Note that in libelf.h struct Elf is opaque, users that just use libelf.h cannot access the struct fields

Bug#728539: elfutils: eu-readelf crashes when reading a shared library

On Sun, 2013-11-03 at 16:38 +0100, Kurt Roeckx wrote: So after some changed I'm currently having this: Package: elfutils Version: 0.156-2 Depends: libasm1 (= 0.132), libc6 (= 2.14), libdw1 (= 0.156-2), libelf1 (= 0.156-2), libstdc++6 (= 4.1.1) This is right, none of the elfutils tools use

Bug#728539: elfutils: eu-readelf crashes when reading a shared library

On Sat, Nov 02, 2013 at 06:23:14PM +0100, Vadim Zeitlin wrote: I'm trying to use abi-dumper tool for analyzing the ABI of my own shared library. This tools uses eu-readelf to actually read the library symbols but eu-readelf crashes, making it unusable: % eu-readelf -N --debug-dump=loc

Bug#728539: elfutils: eu-readelf crashes when reading a shared library

On Sat, Nov 02, 2013 at 07:35:39PM +0100, Kurt Roeckx wrote: So for me I have this problem with this combination: elfutils 0.157-1 libdw1 0.157-1 libelf1 0.153-2 Upgrading libelf1 to 0.157-1 makes the problem go away for me. This looks like some ABI breakage in libelf? Although the

Bug#649038: elfutils FTBFS on kfreebsd

Two questions: - Would it help to just disable the testsuite on the kfreebsd arch? Clearly the package itself build fine. But some tests are failing. Although it would be nice to have 100% PASS as on GNU/Linux, the failures don't look too terrible for a new architecture that has not been

Bug#726248: sdt.h conflict with kfreebsd-kernel-headers and systemtap-sdt-dev

On Sun, Oct 20, 2013 at 01:07:33AM +0200, Robert Millan wrote: But then programs that expect the header to be in the default place wouldn't build. The whole idea is that programs that use sys/sdt.h (and optionally the dtrace script) to use DTRACE_PROBE macros to define SDT probe points get

Bug#726248: sdt.h conflict with kfreebsd-kernel-headers and systemtap-sdt-dev

On Sat, Oct 19, 2013 at 05:00:48PM +0200, Robert Millan wrote: If you want to avoid modifying programs that #include sys/sdt.h, why not just install it in /usr/include/systemtap/sys/sdt.h ? Then you can build them with -I/usr/include/systemtap so that your version takes preference. But then

Bug#726248: sdt.h conflict with kfreebsd-kernel-headers and systemtap-sdt-dev

On Fri, 2013-10-18 at 10:39 +0200, Robert Millan wrote: I'm sorry, but I just can't see how this could fly. If systemtap-sdt-dev is not meant unusable on non-Linux architectures, and you provide it in them, you have to be able to deal with the fact that this package will fail on them. It is

Bug#726248: sdt.h conflict with kfreebsd-kernel-headers and systemtap-sdt-dev

BTW. Wouldn't it be an option to put the conflicting header file from kfreebsd-kernel-headers in its own (recommended) package? Say kfreebsd-kernel-sdt-header. Then the two packages could just conflict. And other packages can explicitly depend on it if they want the kfreebsd variant instead of the

Bug#726248: sdt.h conflict with kfreebsd-kernel-headers and systemtap-sdt-dev

On Sat, 2013-10-19 at 02:21 +0200, Robert Millan wrote: On 18/10/2013 22:18, Timo Juhani Lindfors wrote: It is certainly meant to be usable for software that wants to use SDT probes (like glibc in this example) and software that wants to read/inspect the SDT probes embedded in other

Bug#726248: systemtap-sdt-dev: should be Arch: all so gcc and libc can B-D on it

On Tue, 2013-10-15 at 09:47 +0300, Timo Juhani Lindfors wrote: (It was later switched from linux-any to i386 amd64 ia64 s390 powerpc arm armel armeb armhf since it cause build failures on mips, mipsel, s390x and sparc.) sys/sdt.h really should compile on all arches. It does have arch specific

Bug#722649: dtrace leaves temporary files

be removed, not when generating a header file. Fixed upstream by: commit 114bb022c46991e9595cbddbb1ea5b11a2ad5788 Author: Mark Wielaard m...@redhat.com Date: Fri Sep 13 12:22:05 2013 +0200 Remove temporary cpp file also when generating header file. Debian #722649 diff --git a/dtrace.in b

Bug#707438: valgrind: FTBFS: x86_64-linux-gnu-gcc: error: unrecognized command line option '-V'

On Thu, May 09, 2013 at 10:18:58AM +0200, Lucas Nussbaum wrote: Source: valgrind Version: 1:3.8.1-2 Severity: serious Tags: jessie sid User: debian...@lists.debian.org Usertags: qa-ftbfs-20130509 qa-ftbfs Justification: FTBFS on amd64 During a rebuild of all packages in sid, your package

Bug#706817: systemtap: Error, 'stap_...' is not a zombie systemtap module.

On Sun, 2013-05-05 at 12:07 +0300, Timo Juhani Lindfors wrote: I guess this is caused by linux (3.2.29-1) unstable; urgency=low ... * debugfs: Add mode, uid and gid mount options; set default mode to 700 (Closes: #681418) -- Ben Hutchings b...@decadent.org.uk Sun, 16 Sep 2012

Bug#701271: elfutils: ftbfs with GCC-4.8

McGrath rol...@hack.frob.com Date: Tue Dec 11 09:42:07 2012 -0800 nm: Fix size passed to snprintf for invalid sh_name case. Signed-off-by: Roland McGrath rol...@hack.frob.com commit 7df3d2cd70932cd70515dbeb75e4db66fd27f192 Author: Mark Wielaard m...@redhat.com Date: Tue Dec 11 22:27:05

Bug#647359:

On Thu, Feb 07, 2013 at 09:45:56PM +0100, Kurt Roeckx wrote: On Thu, Feb 07, 2013 at 08:33:03PM +, Debian Bug Tracking System wrote: Bug #647359 [elfutils] eu-elflint: test suite fails with binutils-gold Added tag(s) fixed-upstream. I guess that was commit

Bug#684825: elfutils: FTBFS: md5.c:108:3: error: dereferencing type-punned pointer will break strict-aliasing rules [-Werror=strict-aliasing]

On Tue, 2012-08-14 at 09:07 +0200, Lucas Nussbaum wrote: During a rebuild of all packages in *wheezy*, your package failed to build on amd64. Relevant part: gcc -D_GNU_SOURCE -DHAVE_CONFIG_H -DLOCALEDIR='/usr/share/locale' -I. -I.. -I. -I. -I../lib -I.. -I./../libelf -std=gnu99 -Wall

Bug#558291: libtool issue

The libtool error seems to have been resolved upstream with this patch: http://developer.classpath.org/pipermail/classpath-patches/2010-January/006381.html -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact

Bug#356805: classpath: missing java.lang.Thread.UncaughtExceptionHandler interface

The following was added upstream: 2006-04-12 Mark Wielaard [EMAIL PROTECTED] Port UncaughtExceptionHandler support from generics branch. * NEWS: Document Thread.UncaughtExceptionHandler VMThread change. 2006-04-12 Andrew John Hughes [EMAIL PROTECTED] * java/lang/Thread.java

Bug#359267: cacao: XML parsing fail while running openjump

On Mon, 2006-03-27 at 17:03 +0200, Petter Reinholdtsen wrote: When trying to run the openjump debian package (aptitude install openjump) with cacao, I get an XML parsing error. The splash screen show up, and then a dialog box with title Assertion Failed Exception and Should never reach here

Bug#357830: classpath: deadlock in image drawing code

On Sun, 2006-03-19 at 20:18 +0100, Petter Reinholdtsen wrote: As reported in bug #348504, classpath can sometimes deadlock when image drawing is done in parallel with other graphics operations. This was discovered when testing worldwind2d with cacao. Mark Wielaard had a look at this problem

Bug#348504: cacao: Fail to run java version of World Wind

On Sun, 2006-03-19 at 15:39 +0100, Petter Reinholdtsen wrote: I've been told by Mark Wielaard on IRC that this hang problem is a problem with locking in the gui code. Hopefully he will get a fix ready soon. Proposed patch can be found at: http://article.gmane.org

Bug#356805: classpath: missing java.lang.Thread.UncaughtExceptionHandler interface

On Tue, 2006-03-14 at 08:54 +0100, Petter Reinholdtsen wrote: Package: classpath Version: 2:0.90-1 When trying to run the java standalone client for Openstreetmap, URL:http://www.eigenheimstrasse.de/josm/josm-latest.jar, it crashes with the given error message. According to Michael Koch on

Bug#353555: jvm_find: command not found

Package: eclipse-efj Version: 3.1.2-1 Severity: grave Justification: renders package unusable eclipse-efj wants to source /usr/share/java-common/java-common.sh which is not available. /usr/bin/efj starts with: #!/bin/bash source /usr/share/java-common/java-common.sh JAVA_HOME=`jvm_find ecj` if

Bug#344177: eclipse: Eclipse CDT missing

Package: eclipse Version: 3.1.1-6 Severity: wishlist The CDT seems to be missing. Or I might not know which package it is in. I would expect eclipse-cdt, but that package doesn't seem to exist. -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500,

Bug#344178: Installing plugins makes eclipse not startup anymore

Package: eclipse Version: 3.1.1-6 Severity: normal These instructions come from http://developer.classpath.org/mediation/ClasspathHackingWithEclipse go to the Help - Software Updates - Find and Install... menu and choose the Search for new features option. Click Next and then in the next dialog

Bug#344177: eclipse: Eclipse CDT missing

Hi Stephane, On Tue, 2005-12-20 at 19:10 +0100, Stephan Michels wrote: On 12/20/05, Mark Wielaard [EMAIL PROTECTED] wrote: The CDT seems to be missing. Or I might not know which package it is in. I would expect eclipse-cdt, but that package doesn't seem to exist. CDT is not part

Bug#344177: eclipse: Eclipse CDT missing

On Wed, 2005-12-21 at 08:57 +0100, Michael Koch wrote: Michael comitted a cdt package to pkg-java, which is in a pretty good shape. I use it for some time now without problems. So, I think it's ready for an upload. Is there a way I can try out this package? Well, I'm still

Bug#344178: Installing plugins makes eclipse not startup anymore

On Wed, 2005-12-21 at 09:02 +0100, Michael Koch wrote: I raise the severity of this bug to important as it is really annoying that its not so easy to install plugins via this mechanism. We will need to take a deep breath and think about a solution for this. I wonder what fedora does in this

Bug#337510: eclipse-ecj: ant code completion generates nullpointer exception

Hi David, On Fri, 2005-11-04 at 19:22 +0100, David N. Welton wrote: This generates a dialog saying that code completion didn't complete because of a NullPointerException. Could you post the actual stack trace? Run with -consoleLog -debug or look in the

Bug#327177: Missing Graphics2D support

Hi, On Thu, 2005-09-08 at 09:09 +0200, Petter Reinholdtsen wrote: I suspect 'Grahics2D' is a typo and should read 'Graphics2D'. Bleah. Fixed upstream in CVS. Please add Graphics2D support to classpath. That depends on cairo. We tested against 0.5.0. It seems it might also work with the 1.0.0

Bug#325930: eclipse-platform: eclipse.buildId should contain debian package version

Package: eclipse-platform Version: 3.1-9 Severity: wishlist It would be nice if the eclipse.buildId in the various config.ini files had their debian package version appended so it shows up in the log files, about and configuration dialogs. Basically this means that all config.ini property files

Bug#323080: libgtk2.0-0: libgtk2 should be compiled against libxfixes

Package: libgtk2.0-0 Version: 2.6.9-1 Severity: wishlist When compiled against xfixes gtk+ can much more efficiently handle clipboard selection changes and support clipboard owner-changes to applications using it. See gdk_display_supports_selection_notification and friends. I compiled my own

Bug#276096: Eclipse Debian package status

Hi, On Mon, 2005-08-01 at 16:42 -0400, Charles Fry wrote: I am attempting to contact anyone who has previously expressed an interest in packaging a new Eclipse release for Debian. I grabbed everyone from the ITA, as well as the Alioth project, and the Java list for good measure. :-) I have

Bug#307211: saxon-catalog: FTBFS (testing): Semantic Error: The abstract method java.lang.String getRawName(int $1);, inherited from type org.xml.sax.Attributes, is not implemented in the non-abstract class cz.kosek.CatalogXMLReader.

Hi, On Sun, 2005-05-01 at 15:19 -0700, Steve Langasek wrote: And classpath is going nowhere fast, because the current version of gjdoc depends on kaffe, which is not built on arm. Note that the gjdoc dependency is only needed when you want to generate the documentation as published on

Bug#300388: libxml-commons-resolver1.1-java: FTBFS: NullPointerException

Hi, On Sat, 2005-03-19 at 15:34 +0100, Michael Koch wrote: java.lang.NullPointerException at java.text.DecimalFormatSymbols.setCurrency (DecimalFormatSymbols.java:397) at java.text.DecimalFormatSymbols.DecimalFormatSymbols (DecimalFormatSymbols.java:151) at

Bug#299426: Upstream URL outdated

Hi, On Mon, 2005-03-14 at 02:18 +0100, Jeroen van Wolffelaar wrote: Package: gjdoc Version: 0.7.2-2 Severity: normal The copyright file should refer to the upstream location/website where to retrieve upstream versions. However, you refer to http://savannah.gnu.org/cvs/?group=cp-tools,

Bug#265767: requested removal of kissme from debian

Hi, On Sat, 2005-01-29 at 15:08 +0700, John Leuner wrote: I have requested the removal of kissme from debian: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=291993 Although there are no released versions. kissme CVS keeps up to date with the latest GNU Classpath releases pretty well. I am