Control: tags -1 + patch
Hi Kurt,
On Sun, Apr 27, 2025 at 09:06:22PM +0200, Kurt Roeckx wrote:
> > $ apt-cache show gnat-13-arm-linux-gnueabihf:amd64 | grep ^Conflicts
> > Conflicts: gnat-10-arm-linux-gnueabihf, gnat-11-arm-linux-gnueabihf,
> > gnat-12-arm-linux-gnueabihf, gnat-4.9, gnat-5-arm-l
Processing control commands:
> tags -1 + patch
Bug #1063664
[gnat-13-aarch64-linux-gnu,gnat-13-arm-linux-gnueabihf,gnat-13-i686-linux-gnu,gnat-13-powerpc64le-linux-gnu,gnat-13-riscv64-linux-gnu,gnat-13-s390x-linux-gnu]
gcc-13-cross: file conflicts between gnat-13- and
gnat-{9,10}-
Ignor
nclude -isystem
/usr/amdgcn-amdhsa/sys-include -isystem /gcc-13-13.3.0/build-gcn/sys-include
-c -g -O2 conftest.c >&5
LLVM ERROR: Unsupported AMDHSA Code Object Version 3
PLEASE submit a bug report to https://github.com/llvm/llvm-project/issues/ and
include the crash backtrace.
Stack
diversion for the affected file.
Please figure out which of these packages should properly own the
affected file and reassign the bug as appropriate. When doing so, please
add the other package to the set of affected packages using "Control:
affects -1 + " to avoid the filing of duplicates.
On Sun, Apr 27, 2025 at 05:39:10PM +0200, Helmut Grohne wrote:
> Hi Kurt,
>
> This is more subtle in two regards. For one thing, I implied that the
> problem would be fully architecture-generic. It is not. For
> gnat-13-aarch64-linux-gnu, no problem exists, because there is no
> gnat-12-aarch64-li
Hi Kurt,
On Sun, Apr 27, 2025 at 01:53:12PM +0200, Kurt Roeckx wrote:
> I don't see the problem:
> $ apt-cache show gnat-13-aarch64-linux-gnu
> Package: gnat-13-aarch64-linux-gnu
> Source: gcc-13-cross (17)
> Version: 13.3.0-13cross1
> Installed-Size: 98436
> Maintainer: Debian GCC Maintainers
>
On Fri, Apr 11, 2025 at 09:59:01PM +0200, Helmut Grohne wrote:
> Control: reopen -1
>
> Hi Matthias,
>
> On Thu, Nov 14, 2024 at 11:21:01AM +0000, Debian Bug Tracking System wrote:
> > no feedback, closing this issue.
>
> I can still reproduce it in quite some vari
On 27.04.25 00:07, Sylvestre Ledru wrote:
and what is wrong with amdgcn-tools? I can build with -18
sure, you can, it's just a package providing symlinks. and then gcc-13
ftbfs, because some gcn targets are missing.
On Sat, 2025-04-26 at 19:23 +0200, Chris Hofstaedtler wrote:
> On Sat, Apr 26, 2025 at 05:32:58PM +0200, Ben Hutchings wrote:
> > - This does not affect the default C and C++ toolchain
>
> #1103592 is I think a case that does affect the default C and C++
> toolchain.
I see lots of LLVM in the bu
Le 26/04/2025 à 15:51, Kurt Roeckx a écrit :
On Fri, Jan 10, 2025 at 12:08:39PM +0100, Emilio Pozuelo Monfort wrote:
I don't see in the changelog for llvm 18 or 19 that the targets were
removed, so perhaps the removal was unintentional? Sylvestre, can those be
added back, so that amdgcn-tools
On Sat, Apr 26, 2025 at 05:32:58PM +0200, Ben Hutchings wrote:
> - This does not affect the default C and C++ toolchain
#1103592 is I think a case that does affect the default C and C++
toolchain.
Control: severity -1 important
Downgrading this from serious because:
- This does not affect the default C and C++ toolchain
- There are workarounds available:
- Build with -gdwarf-4
- Disable use of dh_dwz
Ben.
--
Ben Hutchings
[W]e found...that it wasn't as easy to get programs right as
On Fri, Jan 10, 2025 at 12:08:39PM +0100, Emilio Pozuelo Monfort wrote:
> I don't see in the changelog for llvm 18 or 19 that the targets were
> removed, so perhaps the removal was unintentional? Sylvestre, can those be
> added back, so that amdgcn-tools can move to a newer llvm? This is one of
> t
Your message dated Sat, 26 Apr 2025 02:36:10 +
with message-id
and subject line Bug#1103019: fixed in gcc-15 15.1.0-1
has caused the Debian Bug report #1103019,
regarding 5 packages have an undeclared file conflict on
/usr/share/man/man3/gcobol.3.gz
to be marked as done.
This means that you
Your message dated Thu, 24 Apr 2025 18:00:33 +
with message-id
and subject line Bug#1102350: fixed in gcc-15 15-20250423-1
has caused the Debian Bug report #1102350,
regarding libstdc++-15-dev: libstdc++-modules.json points at wrong location
to be marked as done.
This means that you claim
||a/show_bug.cgi?id=80328
--
You are receiving this mail because:
You reported the bug.
Your message dated Fri, 18 Apr 2025 12:49:46 +0200
with message-id <16e53beb-8818-49ff-b381-109e4798d...@debian.org>
and subject line Re: src:gcc-13-cross: unsatisfied build dependency in testing:
libc6-dev:$host and libc6-dev-amd64-cross:$build
has caused the Debian Bug report #1
]
|invalid parameter forward |invalid parameter forward
|declarations not diagnosed |declarations not diagnosed
--
You are receiving this mail because:
You are on the CC list for the bug.
Package: elfutils
Version: N/A
Severity: wishlist
Tags: l10n patch
Hello,
Find attached the (updated) Turkish translation of the elfutils debconf
messages.
It has been submitted for review to the debian-l10n-turkish mailing
list.
Regards,
Atila KOÇ
# Turkish debconf translation of elfutils pack
Source: gcc-15
Followup-For: Bug #1092866
Hello.
Thank you for adapting the time64 patches in 15-2025014-1.
I have updated the gcc-15 branch with v15 from PR Ada/114065, and
removed large parts that Debian does not need in the hope to reduce
the rebasing burden.
x27; -e ' \\f.$' -e ' \\"'
to find (most) trailing spaces.]
["test-groff" is a script in the repository for "groff"; is not shipped]
(local copy and "troff" slightly changed by me).
[The fate of "test-nroff" was decided in
x27; -e ' \\f.$' -e ' \\"'
to find (most) trailing spaces.]
["test-groff" is a script in the repository for "groff"; is not shipped]
(local copy and "troff" slightly changed by me).
[The fate of "test-nroff" was decided in
diversion for the affected file.
Please figure out which of these packages should properly own the
affected file and reassign the bug as appropriate. When doing so, please
add the other packages to the set of affected packages using "Control:
affects -1 + " to avoid the filing of duplic
Processing control commands:
> reopen -1
Bug #1101749 {Done: Matthias Klose } [ga68-15,ga68-15-doc]
ga68-15 and ga68-15-doc have undefined unpack behavior due to filesystem
aliasing
'reopen' may be inappropriate when a bug has been closed with a version;
all fixed versions will be
Processing control commands:
> reopen -1
Bug #1063664 {Done: Matthias Klose }
[gnat-13-aarch64-linux-gnu,gnat-13-arm-linux-gnueabihf,gnat-13-i686-linux-gnu,gnat-13-powerpc64le-linux-gnu,gnat-13-riscv64-linux-gnu,gnat-13-s390x-linux-gnu]
gcc-13-cross: file conflicts between gnat-13- and
g
Control: reopen -1
Hi Matthias,
On Thu, Nov 14, 2024 at 11:21:01AM +, Debian Bug Tracking System wrote:
> no feedback, closing this issue.
I can still reproduce it in quite some variety.
gnat-13- as built from src:gcc-13 still contains unversioned
tools. There are declared conflicts
Control: reopen -1
On Sun, Apr 06, 2025 at 06:51:02PM +, Debian Bug Tracking System wrote:
> #1101749: ga68-15 and ga68-15-doc have undefined unpack behavior due to
> filesystem aliasing
>
> It has been closed by Debian FTP Masters
> (reply to Matthias Klose ).
I fear w
Your message dated Fri, 11 Apr 2025 16:48:54 +0200
with message-id <20250411144854.ge2...@cventin.lip.ens-lyon.fr>
and subject line Re: Bug#1057355: libmpfr6: major formatted output function
bugs with %c and the value 0
has caused the Debian Bug report #1057355,
regarding libmpfr6:
ncent Lefevre wrote:
> > > > I've reported the following bug in the MPFR mailing-list. I think
> > > > I've fixed the issues on the MPFR side in master, but MPFR is still
> > > > affected by the bug on the GMP side (gmp_vasprintf):
> > > > &
Status|NEW |RESOLVED
Resolution|--- |FIXED
--- Comment #11 from sandra at gcc dot gnu.org ---
Finally did something about this ancient bug! I hope I didn't screw it up even
worse, since I'm not an expert on this.
former from the latter. Recommend using
-fexcess-precision=standard
instead of -ffloat-store.
--
You are receiving this mail because:
You reported the bug.
that might be a question for syq, or mips porters ...
On 07.04.25 09:39, Helmut Grohne wrote:
Package: lib32atomic1,libn32atomic1
Version: 15-20250329-1
Severity: serious
User: debian...@lists.debian.org
Usertags: fileconflict
Hi Matthias,
I observe that lib32atomic1 and libn32atomic1 both ins
Processing control commands:
> reassign 1102350 libstdc++-15-dev
Bug #1102350 [cmake] cmake 4.0 couldn't find correct std module source file
Bug reassigned from package 'cmake' to 'libstdc++-15-dev'.
No longer marked as found in versions 4.0.0.
Ignoring request to
Bumping this, as Trixie is nearing the soft-freeze date and this still
hasn't been fixed with 2
reports, this one and #1102039. I don't know if elfutils is strictly part
of the toolchain freeze
or not, but being toolchain adjacent, with a rather nasty linking bug
that's already fixe
Package: lib32atomic1,libn32atomic1
Version: 15-20250329-1
Severity: serious
User: debian...@lists.debian.org
Usertags: fileconflict
Hi Matthias,
I observe that lib32atomic1 and libn32atomic1 both install
/usr/lib32/libatomic.so.1 and /usr/lib32/libatomic.so.1.2.0 without
declaring any suitable r
Your message dated Sun, 06 Apr 2025 18:48:37 +
with message-id
and subject line Bug#1101750: fixed in gcc-15 15-20250406-1
has caused the Debian Bug report #1101750,
regarding libgccjit-15-doc overwrites info files from libgccjit-14-doc
to be marked as done.
This means that you claim that
Your message dated Sun, 06 Apr 2025 18:48:36 +
with message-id
and subject line Bug#1101749: fixed in gcc-15 15-20250406-1
has caused the Debian Bug report #1101749,
regarding ga68-15 and ga68-15-doc have undefined unpack behavior due to
filesystem aliasing
to be marked as done.
This means
't
change anything.
The bug is very difficult to debug due to valgrind being involved.
Despite many tries I haven't been able to reproduce it outside of
valgrind. The problem disappears with gcc-13 13.3.0-13, but is still
there with gcc-15 15-20250315-1.
So far my finding are quite l
Package: libelf-dev
Version: 0.192-4
Severity: important
Tags: patch
X-Debbugs-Cc: zhouwei...@gmail.com
Dear Maintainer,
When building with libelf with -static, it fails:
/usr/bin/ld:
/usr/lib/gcc/x86_64-linux-gnu/14/../../../x86_64-linux-gnu/libelf.a(elf_begin.o):
in function `file_read_elf':
after it. Overall it seems that memmove() wrongly jumps to
memcpy() for cases it shouldn't, but I don't really see why and while
alignment would matter.
I am puzzled by all of that I and don't really know how to debug that
further.
It could very well be that this is a bug in val
Package: gcc-14
Version: 14.2.0-19
Severity: normal
X-Debbugs-Cc: martin-eric.rac...@iki.fi
It appears that GCC for amd64 does not ship with support for the -m32 flag.
Could this be fixed?
Thanks!
Martin-Éric
PS: This seemingly also applies to previous GCC releases e.g. gcc-12 in
Bookworm.
Your message dated Fri, 21 Mar 2025 14:35:01 +0100
with message-id
and subject line Re: Bug#1100984: gcc-14: checking if x86_64-linux-gnu-gcc
supports the -m32 Intel/AMD option... no
has caused the Debian Bug report #1100984,
regarding gcc-14: checking if x86_64-linux-gnu-gcc supports the -m32
So to make sure I understand - cross-compiling Debian->Pi arm64 is fine,
but even generic C binaries aren't guaranteed to work on Pi armhf,
and the best way to compile a Pi armhf binary on Debian is with qemubuilder?
Given how much time this has/will cost me, I'm minded to propose a
section in ht
W dniu 4.04.2025 o 18:08, Andrew Sayers pisze:
Package: libstdc++-12-dev
Version: 12.2.0-14+rpi1
Severity: important
X-Debbugs-Cc: debian-...@lists.debian.org
User: debian-...@lists.debian.org
Usertags: armhf
The _GLIBCXX_HAVE_ATOMIC_LOCK_POLICY setting differs between Debian
and Raspberry Pi O
Bookworm armhf
to appear to run on Rasbperry Pi OS Bookworm armhf, then later crash
for no obvious reason. For details, see the (now closed) upstream bug report:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119627
I'm not sure whether the Debian or Raspberry Pi OS version is correct,
but the D
||https://bugs.debian.org/513
||420
--
You are receiving this mail because:
You are on the CC list for the bug.
-e ' \\f.$' -e ' "$'
to find (most) trailing spaces.]
["test-groff" is a script in the repository for "groff"; is not shipped]
(local copy and "troff" slightly changed by me).
[The fate of "test-nroff" was decided in groff
ug, 0 );
|
^
|
Dwarf_Debug
/<>/libHSAIL/BrigDwarfGenerator.cpp::33: error:
âdwarf_transform_to_disk_formâ was not declared in this scope
Package: libgccjit-15-doc
Version: 15-20250319-1
Severity: serious
User: debian...@lists.debian.org
Usertags: fileconflict
Control: affects -1 + libgccjit-14-doc
libgccjit-{14,15}-doc both install files into /usr/share/info/. For one
thing, that's libgccjit.info.gz and for another image files belo
Package: ga68-15,ga68-15-doc
Version: 15-20250329-1
Severity: serious
User: debian...@lists.debian.org
Usertags: fileconflict
ga68-15 installs /usr/share/doc/ga68-15 as a symbolic link pointing to
gcc-15-base whereas ga68-15-doc installs the same location as a
directory containing a file. Where th
Your message dated Fri, 28 Mar 2025 16:54:01 +0100
with message-id
and subject line Bug #1101322 is a duplicated of #980429 (closed)
has caused the Debian Bug report #1101322,
regarding g++-10: g++ randomly segfaults on clang code on Debian 11
to be marked as done.
This means that you claim that
Your message dated Thu, 27 Mar 2025 19:42:08 +0100
with message-id
and subject line bug report should never been filed. libxml2 is now fixed
has caused the Debian Bug report #1101231,
regarding libabigail: FTBFS: /usr/include/unicode/localpointer.h:561:26: error:
parameter declared 'auto&#
Package: g++-10
Version: 10.2.1-6
Severity: normal
X-Debbugs-Cc: yoann.con...@smile.fr
Dear Maintainer,
* What led up to the situation?
I was trying to build clang for the Yocto project and it failed
randomly (See [0] for the bug reported on the Yocto project)
The file triggering the crash is
ointer.h:561:26: error: parameter declared 'auto'
561 | template
| ^~~~
/usr/include/unicode/localpointer.h:573:76: error: template argument 2 is
invalid
573 | explicit LocalOpenPointer(std::unique_ptr &&p)
|
su 23.3.2025 klo 16.54 Samuel Thibault (sthiba...@debian.org) kirjoitti:
>
> Martin-Éric Racine, le dim. 23 mars 2025 13:54:11 +0200, a ecrit:
> > su 23.3.2025 klo 10.06 Samuel Thibault (sthiba...@debian.org) kirjoitti:
> > > Martin-Éric Racine, le dim. 23 mars 2025 09:21:49 +0200, a ecrit:
> > > >
Martin-Éric Racine, le dim. 23 mars 2025 13:54:11 +0200, a ecrit:
> su 23.3.2025 klo 10.06 Samuel Thibault (sthiba...@debian.org) kirjoitti:
> > Martin-Éric Racine, le dim. 23 mars 2025 09:21:49 +0200, a ecrit:
> > > X-Debbugs-Cc: debian-am...@lists.debian.org, debian-h...@lists.debian.org
> > > ,
attachment file in the bug report let
us know.
Thank you,
--
Carles Pina i Estany
https://carles.pina.cat | car...@pina.cat | cp...@debian.org
signature.asc
Description: PGP signature
su 23.3.2025 klo 10.06 Samuel Thibault (sthiba...@debian.org) kirjoitti:
> Martin-Éric Racine, le dim. 23 mars 2025 09:21:49 +0200, a ecrit:
> > X-Debbugs-Cc: debian-am...@lists.debian.org, debian-h...@lists.debian.org ,
> > martin-eric.rac...@iki.fi
> > User: debian-am...@lists.debian.org
> > Use
Hi Paul,
On 2025-03-23 11:17:52 +0100, Paul Gevers wrote:
> Hi Vincent,
>
> On Fri, 15 Dec 2023 04:53:51 +0100 Vincent Lefevre
> wrote:
> > On 2023-12-03 22:13:03 +0100, Vincent Lefevre wrote:
> > > I've reported the following bug in the MPFR mailing-list. I thin
Hi Vincent,
On Fri, 15 Dec 2023 04:53:51 +0100 Vincent Lefevre
wrote:
On 2023-12-03 22:13:03 +0100, Vincent Lefevre wrote:
> I've reported the following bug in the MPFR mailing-list. I think
> I've fixed the issues on the MPFR side in master, but MPFR is still
> affected by
t; Could gcc-multilib & dependencies be compiled for hurd-amd64 as well? Without
> it we're missing the -m32 flag.
Please produce patches, test them and send them to bug reports.
Put another way: why do you need -m32? We didn't feel it was worth
spending the time to fix the 32
Package: gcc-multilib
Version: 4:14.2.0-1
Severity: wishlist
X-Debbugs-Cc: debian-am...@lists.debian.org, debian-h...@lists.debian.org ,
martin-eric.rac...@iki.fi
User: debian-am...@lists.debian.org
User: debian-h...@lists.debian.org
Usertags: amd64
Could gcc-multilib & dependencies be compiled f
Processing control commands:
> clone -1 -2
Bug #1100805 [gcc-14] gcc-14 version 14.2.0-18 causes glibc to be miscompiled
on armhf
Bug 1100805 cloned as bug 1100939
> reassign -2 src:libinsane
Bug #1100939 [gcc-14] gcc-14 version 14.2.0-18 causes glibc to be miscompiled
on armhf
Bug reas
t; functions located after it. Overall it seems that memmove() wrongly jumps to
> memcpy() for cases it shouldn't, but I don't really see why and while
> alignment would matter.
>
> I am puzzled by all of that I and don't really know how to debug that
> further.
It could
failure not to
happen at all.
It was you who said "patches welcome" a long time ago
regarding this bug. Now I expect you to honor your word.
Please could you address this upstream,
if it's really important for you?
I could report this upstream, but there are several problems
wi
Your message dated Wed, 19 Mar 2025 12:16:01 +
with message-id
and subject line Bug#1100683: fixed in python-pebble 5.1.1-1
has caused the Debian Bug report #1100683,
regarding python-pebble: please fix d/watch for the new PyPi archive naming
policy
to be marked as done.
This means that you
On 18.03.25 20:56, Aurelien Jarno wrote:
This is fully reproducible when glibc 2.41-6 is built with gcc-14
14.2.0-18 or 14.2.0-19. On the contrary the problem disappears when
rebuilding glibc 2.41-6 with gcc-14 14.2.0-17 currently in testing. In
turn this prevent glibc 2.41-6 to migrate to testin
Processing control commands:
> clone -1 -2
Bug #1100805 [gcc-14] gcc-14 version 14.2.0-18 causes glibc to be miscompiled
on armhf
Bug 1100805 cloned as bug 1100821
> reassign -2 src:glibc
Bug #1100821 [gcc-14] gcc-14 version 14.2.0-18 causes glibc to be miscompiled
on armhf
Bug reassigne
Control: clone -1 -2
Control: reassign -2 src:glibc
this is not seen with a glibc-2.41-1 built with gcc-14 14.2.0-18.
No, I'm not suggesting to revert to that version, like you do for
gcc-14, but to investigate the issue.
On 18.03.25 20:56, Aurelien Jarno wrote:
Package: gcc-14
Version: 14.
Package: gcc-14
Version: 14.2.0-17
Severity: serious
Justification: breaks autopkgtest of unrelated package
X-Debbugs-Cc: debian-gl...@lists.debian.org, debian-...@lists.debian.org
Control: affects -1 src:glibc
Control: affects -1 src:libinsane
Hi,
When glibc is compiled with gcc-14 >= 14.2.0-18,
Source: python-pebble
Version: 5.1.0-1
Severity: normal
Dear Maintainer,
For some $reason, PyPi decided that the archives should be lowercase from now
on.
I guess you now need to adapt a single letter in d/watch
to make it see available 5.1.1 upstream release.
Greetings,
Alexandre
https://
Processing control commands:
> block -1 by 1096181 1100460 1100461
Bug #1099646 [release.debian.org] transition: gnat
1099646 was not blocked by any bugs.
1099646 was not blocking any bugs.
Added blocking bug(s) of 1099646: 1100460, 1096181, and 1100461
--
1099646: https://bugs.debian.org/
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: transition
X-Debbugs-Cc: gcc...@packages.debian.org, Graham Inggs
Control: affects -1 + src:gcc-14
Hello.
This bug tracks the libgnat-14 transition.
In unstable and testing, Ada packages depend
le within
a method implementation. If I add a local declaration, I get "local
declaration shadows ivar" warning. That's absurd.
I included a minimal example that doesn't depend on gnustep-base in
the upstream report, and also pointed out the change that introduced
this bug.
Processing control commands:
> clone -1 -2
Bug #1096423 [src:cenon.app] cenon.app: ftbfs with GCC-15
Bug 1096423 cloned as bug 1099541
> reassign -2 gobjc-15 15-20250220-1
Bug #1099541 [src:cenon.app] cenon.app: ftbfs with GCC-15
Bug reassigned from package 'src:cenon.app' t
x27; " to find obvious trailing spaces.]
["test-groff" is a script in the repository for "groff"; is not shipped]
(local copy and "troff" slightly changed by me).
[The fate of "test-nroff" was decided in groff bug #55941.]
* What was the outcome
x27; " to find obvious trailing spaces.]
["test-groff" is a script in the repository for "groff"; is not shipped]
(local copy and "troff" slightly changed by me).
[The fate of "test-nroff" was decided in groff bug #55941.]
* What was the outcome
|RESOLVED
--- Comment #11 from Jeffrey A. Law ---
This is really a problem with the libffi project, not GCC which is a downstream
consumer of libffi.
--
You are receiving this mail because:
You are on the CC list for the bug.
We believe that the bug you reported is now fixed; the following
package(s) have been removed from unstable:
amdgcn-tools-18 | 18.2 | source, amd64
--- Reason ---
amdgcn-tools-19
--
Note that the package(s) have
ccSEyJuT.out is attached generated after adding "-freport-bug"
to build/platforms/cuda/sharedTarget/CMakeFiles/OpenMMCUDA.dir/flags.make file
initial value:
CXX_FLAGS = -I/d12/shared/cuda/12.8.0_570.86.10/include -O2 -DNDEBUG -fPIC
-msse2 -DLEPTON_USE_JIT -DOPENMM_COMMON_BUILDING_SHAR
Package: g++-12
Version: 12.2.0-14
Severity: normal
Dear Maintainer,
*** Reporter, please consider answering these questions, where appropriate ***
* What led up to the situation?
compiling openMM relesed version 8.2.0 with cuda 12.8 support on
x86_64
* What exactly did you do (or no
' $' -e '\\~$' " to find obvious trailing spaces.]
>
> ["test-groff" is a script in the repository for "groff"; is not shipped]
> (local copy and "troff" slightly changed by me).
>
> [The fate of "test-nroff" was d
-e '\\~$' " to find obvious trailing spaces.]
["test-groff" is a script in the repository for "groff"; is not shipped]
(local copy and "troff" slightly changed by me).
[The fate of "test-nroff" was decided in groff bug #55941.]
* What was th
Source: elfutils
Version: 0.188-2
d/copyright has two Comments each for the paragraphs starting with Files:
backends/* and Files: libelf/dl-hash.h.
This is not allowed by the machine-readable format. Full disclosure: I am the
one responsible for the syntax error.
On Fri, Feb 14, 2025 at 02:20:50PM +0100, Erez wrote:
> My real question is why do we have gcc-14-aarch64-linux-gnu:arm64 in the
> pool?
It's the native compiler used for natively building arm64 packages.
Without it, we cannot build any packages on arm64.
> Cross compilers using the same host and
Package: src:creduce
Version: 2.11.0~20240909-2
Severity: important
Tags: sid forky
User: debian-gcc@lists.debian.org
Usertags: ftbfs-gcc-15
[This bug is NOT targeted to the upcoming trixie release]
Please keep this issue open in the bug tracker for the package it
was filed for. If a fix in
Dear Maintainer / Matthias Klose,
As with bug report 1094919: after upgrading g++ to g++-15 the code for
which I filed a bug-report on Sat, 01 Feb 2025 11:08:23 +0100 compiles
flawlessly when using g++-15.
Since the issue I reported in bug report 1094907 has disappeared I'd like to
clos
Dear Maintainer / Matthias Klose,
Following the suggestion I received from Matthias (Wed, 12 Feb 2025 11:06:02
+0100) I just installed g++-15 from experimental ((Debian 15-20250213-1)
15.0.1 20250213), and reran the code for which I filed a bug-report on Sat,
01 Feb 2025 14:16:05 +0100.
With g
On 2/14/25 15:17, Matthias Klose wrote:
Control: tags -1 + moreinfo
On 13.02.25 21:41, Mo Zhou wrote:
Control: reopen -1
The problem persists, and the buildd is still failing on it several
hours ago:
still unable to reproduce with
g++ -c -std=gnu++17 -g -gsplit-dwarf -O3 -fopenmp -fPIC
-f
ng CC=gcc-13 and CXX=g++-13 in d/rules can avoid
this issue. The problem persists with GCC-15 in experimental.
ok, pytorch 2.6.0.
the build log says:
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug
Processing control commands:
> tags -1 + moreinfo
Bug #1094828 [g++-14] g++ internal compiler error on arm64 when compiling
pytorch
Ignoring request to alter tags of bug #1094828 to the same tags previously set
--
1094828: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1094828
Debian
Control: tags -1 + moreinfo
On 13.02.25 21:41, Mo Zhou wrote:
Control: reopen -1
The problem persists, and the buildd is still failing on it several
hours ago:
still unable to reproduce with
g++ -c -std=gnu++17 -g -gsplit-dwarf -O3 -fopenmp -fPIC
-fstack-protector-strong -fstack-clash-prot
Source: gcc-15
Version: 15-20250208-1 (experimental)
Severity: normal
Dear Maintainer,
The following warning occurs in most c++ compilations and it will
cause many testsuite fails:
In file included from /<>/src/libstdc++-v3/libsupc++/cxxabi.h:51,
from ../../../../src/libstdc++-v
Hi Matthias,
On Fri, Feb 14, 2025 at 04:26:02PM +0100, Matthias Klose wrote:
> I don't want to apply this patch for trixie. Having these as and ld
> symlinks in the gcc_lib_dir had other issues. The main reason for that
Fair enough. However, we need some mechanism to redirect gcc into using
the
On 14.02.25 10:52, Helmut Grohne wrote:
Control: retitle -1 gcc-VER-TRIPLET may use binutils for a different
architecture
Control: severity -1 important
Control: tags -1 = confirmed patch
On Thu, Oct 03, 2024 at 12:40:53PM +0200, Erez wrote:
Just update my trixie container.
builder@5ba2a4b665
Yes, you are right.
Removing gcc-14-aarch64-linux-gnu:arm64 does solve the problem.
It was installed by dependencies.
I am using multiple architectures for cross compilation.
My real question is why do we have gcc-14-aarch64-linux-gnu:arm64 in the
pool?
Cross compilers using the same host and tar
Control: retitle -1 gcc-VER-TRIPLET may use binutils for a different
architecture
Control: severity -1 important
Control: tags -1 = confirmed patch
On Thu, Oct 03, 2024 at 12:40:53PM +0200, Erez wrote:
> Just update my trixie container.
>
> builder@5ba2a4b665d9:~$ cat /etc/debian_version
> trixi
Processing control commands:
> retitle -1 gcc-VER-TRIPLET may use binutils for a different architecture
Bug #1083135 [gcc-14-aarch64-linux-gnu] gcc-14-aarch64-linux-gnu: cross
compiler 'aarch64-linux-gnu-gcc' always error: "as: unrecognized option '-EL'"
Changed
Processing control commands:
> reopen -1
Bug #1094828 {Done: Matthias Klose } [g++-14] g++ internal
compiler error on arm64 when compiling pytorch
Bug reopened
Ignoring request to alter fixed versions of bug #1094828 to the same values
previously set
--
1094828: https://bugs.debian.org/
Your message dated Wed, 12 Feb 2025 20:51:43 +0100
with message-id
and subject line unable to reproduce, closing
has caused the Debian Bug report #1094828,
regarding g++ internal compiler error on arm64 when compiling pytorch
to be marked as done.
This means that you claim that the problem has
1 - 100 of 3659 matches
Mail list logo
