On Tue, 2023-04-18 at 16:07 +0200, Florian Weimer wrote:
> TL;DR: I want to propose a GCC 14 change which will impact
> distributions, so I'd like to gather some feedback from Debian.
Is this change being made the upstream defaults?
Or will it be a distro override like the hardening flags are?
Control: user debian-ri...@lists.debian.org
Control: usertags 1012107 - riscv64
Control: forcemerge 1000449 1012107
On Mon, 2022-05-30 at 09:48 +, xiao sheng wen wrote:
> Usertags: riscv64
> readelf -h
> /usr/lib/debug/.build-id/3b/7ede587dea6f4387552e0baad2596c7bec28dc.debug
> readelf:
On Mon, 2022-01-17 at 18:38 +0100, наб wrote:
> I don't disagree, but /e/p.d/* can't be symlinks to /u/s.
I don't think that is correct (since systemd symlinks from /etc to
/usr), but if it were then just copying the files would work instead.
> However, please consider new, simplified, patch
On Mon, 16 Aug 2021 17:13:50 +0200 наб wrote:
> Here's a debdiff, which:
> 1. installs the conffiles 644
> 2. simplifies on/off toggling
> 3. => doesn't pollute the environment with an empty DEBUGINFOD_URLS
> when off
> 4. fixes debuginfod.csh on the csh from current sid
> (it
Control: reassign -1 wnpp
Control: retitle -1 RFP: gcc-riscv32-none -- GCC cross compiler for 32-bit
RISC-V processors
On Thu, 10 Jan 2019 20:45:49 +0100 Stefan Tauner wrote:
> So this should actually be an RFP class bug?
> Should this one be converted or closed and another one opened?
Package: libdebuginfod-common
Version: 0.183-7
Severity: normal
The libdebuginfod-common package is just a copy of the libdebuginfo1
package with "common files" tacked on:
Description: library to interact with debuginfod (common files)
The libdebuginfo1 package provides a library with an
On Fri, Apr 20, 2018 at 12:05 PM, Karsten Merker wrote:
> I'm CCing the debian-riscv list in case somebody there should
> have further insights regarding riscv32 support in glibc.
I think Heinrich was looking for a bare-metal compiler for
microcontroller-class RISC-V rather than one for a
Package: libmpx2
Version: 7.2.0-19
Severity: minor
File: /usr/lib/x86_64-linux-gnu/libmpxwrappers.so.2.0.1
User: debian...@lists.debian.org
Usertags: undefined-symbol adequate
libmpxwrappers.so needs to link with -lmpx, see the output of adequate,
symtree and objdump below. I detected this on
n/changelog 2015-05-06 04:43:02.0 +0800
+++ gcc-doc-defaults-15/debian/changelog 2016-09-08 04:48:17.0 +0800
@@ -1,3 +1,16 @@
+gcc-doc-defaults (5:15) unstable; urgency=medium
+
+ * Non-maintainer upload.
+
+ [ Dmitry Eremin-Solenikov ]
+ * Updated to 6.1 versions. (Closes: #794778
Package: gnat-6
Version: 6.2.0-5
File: /usr/bin/gnatgcc
Severity: minor
The gnatgcc link is not versioned like the other gnat links are.
gnatgcc should point at gnatgcc-6, which should point at the
arch-qualified name x86_64-linux-gnu-gcc-6, as the links for
gnat and other names do.
$ ls -l
On Mon, Jan 13, 2014 at 12:51 PM, Matthias Klose wrote:
Are the armv4t defaults still needed, or would it be
better to default to some newer arm version like armv5t?
There is one Debian derivative, QtMoko, which is one of the few usable
distributions on the Openmoko Freerunner (gta02).
Has the FSF been asked to switch to plain GFDL so that we can move the
GCC docs to main? They did that for the autoconf documentation
recently.
--
bye,
pabs
http://wiki.debian.org/PaulWise
--
To UNSUBSCRIBE, email to debian-gcc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble?
On Tue, Oct 27, 2009 at 4:41 AM, Christoph Anton Mitterer
cales...@scientia.net wrote:
Ever thought about integrating PaX [0] per default in Debian?
I'm however not sure how much this actually breaks ;)
Any idea if these patches will be merged upstream?
--
bye,
pabs
Package: g++-4.1
Version: 4.1.0-4
Severity: normal
When synfig is compiled with g++-4.1 from sid, it no longer renders
animation files correctly. I was able to get a user running etch to
confirm that the g++-4.1 version in etch also miscompiles synfig.
Severity set to normal because it obviously
14 matches
Mail list logo
