Bug#1090824: gcc-14: still tries to use ld --package-metadata if backported to bullseye

Mon Sep 17 00:00:00 2001 From: Simon McVittie Date: Thu, 19 Dec 2024 17:05:48 + Subject: [PATCH] d/rules.patch: Don't assume bullseye binutils supports --package-metadata MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit As clarified by the c

Bug#1063767: debuginfod: should have Recommends or Depends on libarchive-tools, for bsdtar

Package: debuginfod Version: 0.188-2.1 Severity: important Control: found -1 0.190-1 By default, debuginfod wants to unpack detached debug symbols and libraries from Debian packages using bsdtar: > Feb 12 13:14:46 REDACTED docker[2367192]: [Mon Feb 12 13:14:46 2024] (7/7): > accepting archive ty

Bug#1063768: debuginfod: man page gives an outdated equivalent of -U

Package: debuginfod Version: 0.188-2.1 Severity: minor Tags: upstream Control: found -1 0.190-1 Related to the bug I recently opened regarding a missing dependency on libarchive-tools, debuginfod(8) says: -U Activate DEB/DDEB patterns in archive scanning. The default is

Re: Bug#992476: override: gcc-9-base:libs/optional

On Thu, 19 Aug 2021 at 00:06:00 -0500, Daniel Lewart wrote: > Please change gcc-9-base from: > libs/required > to: > libs/optional Reminder that this request for a priority reduction is still outstanding. gcc 9 has not been the default gcc since 2020, and Debian 11 was released with gcc 1

Bug#997826: gcc-11: Current/future gcc-N-base packages should not declare Priority: required

ntrol will need to be regenerated afterwards), but there might be subtleties that I'm missing. Thanks, smcv >From f485b1e8e618ef12056d1eea54aa4b617ec10117 Mon Sep 17 00:00:00 2001 From: Simon McVittie Date: Mon, 25 Oct 2021 14:20:16 +0100 Subject: [PATCH] d/control.m4: Make all pack

Re: Bug#993760: libexiv2-27:i386: non-baseline instructions cause crash on AMD Geode

Control: retitle -1 libexiv2-27:i386: non-baseline instructions cause SIGILL on AMD Geode Control: reassign -1 libexiv2-27 Control: affects -1 + tracker-extract Control: tags -1 + moreinfo On Mon, 06 Sep 2021 at 09:48:00 +0300, Martin-Éric Racine wrote: >Message: Process 838 (tracker-extr

Bug#972936: libgcc-s1 buster -> bullseye upgrade issues

On Sat, 13 Feb 2021 at 19:52:10 +0100, Paul Gevers wrote: > [The release team are] pretty concerned about a couple of known RC bugs > which need the proper attention of people familiar with upgrade paths > as there's potential to leave upgrading systems unbootable and/or > without a working apt. ..

Bug#981999: elfutils: please consider separating locales into elfutils-l10n or elfutils-common

Source: elfutils Version: 0.182+20210203 Severity: wishlist It seems to be easy for the locale data in libelf1 to trigger multiarch non-co-installability (#981835, etc.). This could be avoided if the locale data was in a separate Architecture: all package. The locale data is also a significant fr

Bug#981924: Bug#981930: libelf1: fails to install

On Fri, 05 Feb 2021 at 15:41:18 +, Simon McVittie wrote: > On Fri, 05 Feb 2021 at 13:11:26 +0100, Helmut Grohne wrote: > > dh-strip-nondeterminism needs to be fixed and elfutils needs to be > > binNMUed after that. > > Unfortunately, the binNMU hasn't resolve

Bug#981930: libelf1: fails to install

Control: reopen -1 On Fri, 05 Feb 2021 at 13:11:26 +0100, Helmut Grohne wrote: > dh-strip-nondeterminism needs to be fixed and elfutils needs to be > binNMUed after that. Unfortunately, the binNMU hasn't resolved this. Perhaps dh-strip-nondeterminism needs further changes, or perhaps elfutils is

Bug#981835: libelf1 violates Multi-Arch: same / unreproducible

Control: reopen -1 On Thu, 04 Feb 2021 at 13:34:09 +0100, Helmut Grohne wrote: > libelf1 is presently marked Multi-Arch: same, but coinstallation on e.g. > amd64 + mipsel fails with a file conflict: > > | Unpacking libelf1:mipsel (0.182+20210203-1) ... > | dpkg: error processing archive > /tmp/a

Re: Bug#973414: libmozjs-78-0: invalid opcodes in libmozjs when launching GDM3

Control: tags -1 + moreinfo On Fri, 30 Oct 2020 at 10:35:21 +0200, Martin-Éric Racine wrote: > [ 165.903916] traps: gnome-shell[869] trap invalid opcode ip:b5518f8a > sp:b17d6d80 error:0 in libmozjs-78.so.78.3.0[b4b98000+98c000] Which specific x86 CPU is this? I see `uname -m` is i586 rather th

Bug#972269: dwz: dbus-python FTFBS on mipsel: dwz: debian/python3-dbus-tests/usr/lib/debug/.dwz/mipsel-linux-gnu/python3-dbus-tests.debug: .debug_line reference above end of section

Package: dwz Version: 0.13-5 Severity: normal Tags: ftbfs X-Debbugs-Cc: binut...@packages.debian.org, debian-m...@lists.debian.org Control: affects -1 + src:dbus-python During the binNMUs to add Python 3.9 support, dbus-python_1.2.16-3+b1 failed to build on mipsel with binutils_2.35.1-2: dh_dw

Bug#960913: gcc-10: FTBFS with build-indep (Architecture: all only): /<>/build/./gcc/xgcc: No such file or directory

Control: severity -1 important Control: found -1 10-20200425-1 Control: retitle -1 gcc-10: intermittently FTBFS with build-indep: /<>/build/./gcc/xgcc: No such file or directory On Mon, 18 May 2020 at 11:08:36 +0200, Matthias Klose wrote: > I don't think this is an issue in the package. > > http

Bug#960913: gcc-10: FTBFS with build-indep (Architecture: all only): /<>/build/./gcc/xgcc: No such file or directory

Source: gcc-10 Version: 10.1.0-2 Severity: serious Tags: ftbfs Justification: fails to build from source (but built successfully in the past) I'm not sure exactly what is going on here, but in gcc-10_10.1.0-2 building the Architecture: all packages on the buildds, the stage2 build seems to have fa

Bug#950579: libgcc1: multiple packages FTBFS on s390x: /usr/bin/ld: cannot find -lgcc_s

Package: libgcc1 Version: 1:10-20200202-1 Severity: serious Justification: FTBFS Tags: ftbfs Control: affects -1 src:glib2.0 src:xterm src:hdrmerge src:esorex https://buildd.debian.org/status/fetch.php?pkg=glib2.0&arch=s390x&ver=2.62.4-2&stamp=1580755175&file=log > Package versions: [with linebre

Bug#946285: libgcc-s1: probably needs Breaks: libgcc1 (<< 1:10)

On Fri, 06 Dec 2019 at 17:49:09 +0100, Matthias Klose wrote: > On 06.12.19 17:36, Simon McVittie wrote: > > I notice gcc-10 has switched from packaging libgcc_s.so.1 as > > "libgcc1" to the Policy-recommended name libgcc-s1. > > it's not an old version, it&

Bug#946285: libgcc-s1: probably needs Breaks: libgcc1 (<< 1:10)

Package: libgcc-s1 Version: 10-20191205-1 Severity: important I notice gcc-10 has switched from packaging libgcc_s.so.1 as "libgcc1" to the Policy-recommended name libgcc-s1. Because libgcc-s1 contains /usr/lib/MULTIARCH/libgcc_s.so.1 and libgcc1 contains /lib/MULTIARCH/libgcc_s.so.1, the new libg

Bug#931921: clutter's autopkgtests hang when ran with a libglib2.0-0 built with gcc-9

Control: reassign -1 clutter-1.0-tests Control: severity -1 serious We were trying so hard to solve this in either gcc-9 or libglib2.0-0 that we didn't consider whether it could be a clutter bug. (It is.) On Fri, 12 Jul 2019 at 11:16:53 +0100, Iain Lane wrote: > Here's the bit of code. > > >

Bug#931921: clutter's autopkgtests hang when ran with a libglib2.0-0 built with gcc-9

binary package that makes the clutter tests fail to terminate. clutter is a library that depends on glib2.0. As Iain previously noted, this is very, very far from a minimal reproducer, but it's the only one we have. > On 02.08.19 23:27, Simon McVittie wrote: > > On Fri, 02 Aug 2019 at 19

Bug#931921: clutter's autopkgtests hang when ran with a libglib2.0-0 built with gcc-9

On Fri, 02 Aug 2019 at 19:49:20 +0100, Simon McVittie wrote: > If you compile test_run_seed() with -O1, and the rest of gtestutils.c > with -O2, the clutter test hangs. Binary-searching through the extra optimizations enabled by -O2 [1] led me to the minimal change being: if you

Bug#931921: clutter's autopkgtests hang when ran with a libglib2.0-0 built with gcc-9

On Fri, 02 Aug 2019 at 11:41:05 +0100, Iain Lane wrote: > For the record: at Debconf doko suggested to me that a way to start > debugging this from the GCC end would be to produce one working and one > "broken" build of the same version of glib2.0, and then copy object > files from the broken to th

Bug#931921: clutter's autopkgtests hang when ran with a libglib2.0-0 built with gcc-9

On Fri, 12 Jul 2019 at 11:16:53 +0100, Iain Lane wrote: > I saw this on Ubuntu (9.1.0-8ubuntu1) but I've also reproduced this with > 9.1.0-8 on sid (w/gcc-defaults from experimental to use gcc-9 by > default). > > clutter's tests hang: ... > It's adding some stuff to a main loop and expecting it t

Re: Bug#907277: autoconf: AC_SEARCH_LIBS for __atomic_foo fails with AC_LANG([C++]) and g++-8

Control: retitle -1 autoconf: AC_SEARCH_LIBS for __atomic_foo fails with AC_LANG([C++]) and g++-8 On Thu, 17 Jan 2019 at 11:00:40 -0500, Nick Bowler wrote: > I'm not familiar with the library in question but the problem > appears to be specific to these __atomic_xyz builtins which seem > to get s

Re: [Pkg-utopia-maintainers] Bug#903837: dbus: SDDM with theme Breeze and KDE programs (e.g. Dolphin) take +30 seconds to start

Control: reassign 903837 libffi6 3.3~20160224-1 Control: close 903837 3.2.1-8 On Mon, 16 Jul 2018 at 01:12:01 +0200, Michael Biebl wrote: > You have an outdated version of libffi6 installed from experimental. Packages in experimental are not expected to be ready for general use (if they were read

Bug#865154: cloog-ppl: please build-depend on automake, not obsolete automake1.11

Source: cloog-ppl Version: 0.16.1-7 Severity: normal User: debian...@lists.debian.org Usertags: automake1.11 automake1.11-only This package Build-Depends on the obsolete automake1.11 package. Please check whether this package can be built correctly with the recommended automake version, as provid

Bug#818996: Please enable -Wabi-tag warning for C++ programs

On Thu, 24 Mar 2016 at 08:57:22 -0400, Jeffrey Walton wrote: > "What a fine mess we're in" comes to mind right about now... The transition within Debian was no fun either: https://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=libstdc%2B%2B-cxx11;users=debian-gcc@lists.debian.org

Bug#818996: Please enable -Wabi-tag warning for C++ programs

[Removing debian-devel from Cc] On Wed, 23 Mar 2016 at 13:31:32 +0100, Matthias Klose wrote: > If you want to change that, that change should be made in dpkg-buildflags. >From the original report: > >On Tue, 22 Mar 2016 at 10:34:29 -0400, Jeffrey Walton wrote: > >>It appears Debian built the lib

Bug#818996: Please enable -Wabi-tag warning for C++ programs

Package: g++ Control: submitter -1 Jeffrey Walton On Tue, 22 Mar 2016 at 10:34:29 -0400, Jeffrey Walton wrote: > We just took a report due to > http://gcc.gnu.org/onlinedocs/libstdc++/manual/using_dual_abi.html > > It appears Debian built the library with GCC, and GCC used > _GLIBCXX_USE_CXX11_A

Bug#807133: gcc-5-base: Fails to install on multiarch.

On Sat, 05 Dec 2015 at 18:51:15 -0200, felipe wrote: > Fails to build on multiarch. Sorry, but this isn't specific enough to be a useful bug report. Is this the same bug described in , with the error message "trying to overwrite shared '/

Bug#797109: libstdc++6: please consider bumping shlibs to version >= 5

On 27/08/15 21:50, Simon McVittie wrote: > On 27/08/15 21:41, Matthias Klose wrote: >> please could you name such a package and point out why it is broken? > > Sorry, no; that's second-hand information, I don't use KDE (or testing) > myself. I think https://lists.de

Bug#797109: libstdc++6: please consider bumping shlibs to version >= 5

On 27/08/15 21:41, Matthias Klose wrote: > On 08/27/2015 10:24 PM, Simon McVittie wrote: >> The libstdc++ transition would be easier to track if its shlibs forced >> a dependency on libstdc++ (>= 5) even for packages not using any of >> the new symbols. > > I

Bug#797109: libstdc++6: please consider bumping shlibs to version >= 5

Package: libstdc++6 Version: 5.2.1-15 Severity: normal The libstdc++ transition would be easier to track if its shlibs forced a dependency on libstdc++ (>= 5) even for packages not using any of the new symbols. In practice I suspect most C++ packages depend on a package that has needed a transiti

Re: Bug#790756: Packages are not [depending on libstdc++6 >= 5] after rebuild

On Tue, 25 Aug 2015 at 16:50:16 -0300, Lisandro Damián Nicanor Pérez Meyer wrote: > And this is because the packages do not use any of the new symbols, so they > do not get the dependency on the last version. there is nothing packagers > can do about it. I wonder whether g++-5 should artificially

Bug#619719: Bug#708781: fix for non-free files in autoconf packages

On Sat, 08 Nov 2014 at 13:34:59 +, Simon McVittie wrote: > On Sat, 01 Nov 2014 at 18:55:58 -0400, Michael Gilbert wrote: > > A patch for the autoconf rc issues is available in bug #695704 for > > autoconf2.59. > > Thanks, I've made a similar change to autoconf2.64.

Bug#767699: closed by Michael Gilbert (not a problem)

On Sun, 02 Nov 2014 at 20:05:52 +0100, Bastien ROUCARIES wrote: > source include license-problem-gfdl-invariants in doc/autoconf.info (aka > invariant section and back cover) > It is not a source is missing problem. It a not modifiable problem The winning option of https://www.debian.org/vote/2006

Bug#677606: gcc-4.7: ICE compiling ByteToDir() from ioquake3 on any-i386

> I have been able to reduce the failing file to a self-contained file > with no #include directives, mini_q_math.c (also attached), and the > failing command-line to: > > /usr/lib/gcc/i486-linux-gnu/4.7/cc1 mini_q_math.c \ > -g -fPIC -O -fvisibility=hidden -funroll-loops -fschedule-insns2 -o - Th

Bug#619719: autoconf2.64: ftbfs with dash from experimental (AC_PROG_GNU_M4 relies on echo preserving backslashes)

On Sat, 26 Mar 2011 at 08:01:26 -0500, Jonathan Nieder wrote: > Suggested fix: patch m4/m4.m4 to use $as_echo. Fixed upstream in autoconf 2.66... but this is 2.64. > Or set CONFIG_SHELL in debian/rules. Given that this outdated version of autoconf is only packaged to be able to build gcc, I thin

Bug#552224: gcc-4.3: [armel] __thread variable uses R_ARM_GOTOFF32 relocation if optimizing => SEGV

Package: gcc-4.3 Version: 4.3.4-5 Severity: normal (I'm guessing that this is a compiler bug, but it could conceivably be the linker or some other toolchain component; if so, please reassign.) As described in , libcap-ng0 0.6.1 contains a _

Bug#460660: gcc-4.2-doc fails to upgrade to 4.2.2-6

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Package: gcc-4.2-doc Version: 4.2.2-6 Severity: grave Justification: renders package unusable gcc-4.2-doc installs info files for gcc-4.2 and gccint-4.2 only, but its postinst calls install-info for gcc-4.2, gccint-4.2 and libgomp-4.2, causing the fol