Control: severity -1 important
Control: tag -1 + patch
On Tue, 16 Jan 2018, Aurelien Jarno wrote:
> > Instead it looks like fixing PR81481 [1] on the GCC 7 side, and then
> > rebuilding glibc is the way to go. I am therefore cloning this bug to
> > gcc-7 so that it can happens.
>
> Note that the
Hello Matthias,
The Debian LTS team would like to fix the security issue which is
currently open in the Wheezy version of libffi:
https://security-tracker.debian.org/tracker/CVE-2017-1000376
Would you like to take care of this yourself?
If yes, please follow the workflow we have defined here:
Hi,
On Sun, 20 Nov 2016, Markus Koschany wrote:
> the Debian LTS team would like to fix the security issues which are
> currently open in the Wheezy version of libgc:
> https://security-tracker.debian.org/tracker/CVE-2016-9427
I have prepared an updated package (it required lots of manual
On Sat, 19 Nov 2011, Ben Hutchings wrote:
Also possibly:
6. DMP/SiS Vortex86 and Vortex86SX. These supposedly have all
586-class features except an FPU, and we could probably keep FPU
emulation for them.
FWIW, I do run Debian on such systems albeit with a custom kernel.
Given those CPU
On Sun, 15 May 2011, Henrique de Moraes Holschuh wrote:
On Sun, 15 May 2011, Mike Hommey wrote:
I'm wondering. Is the project at large aware that we're not building for
i486, but for i586 ? That even the maintainer doesn't know why for
No. And unless we got a bug report form an i486 user,
Hi,
On Sun, 21 Nov 2010, Matthias Klose wrote:
I assume that there is a decision to turn on hardening defaults?
Who made it, and which defaults to turn on? Which ports should it
use? Where is it documented? So involvement of the ctte seems to
be a bit premature, asking the *how* before the
reassign 552688 tech-ctte
retitle 552688 Please decide how Debian should enable hardening build flags
tag 552688 - wontfix
thanks
I think none of the discussions up to now have resulted in a consensus
among all the parties. Most people are in favor of changing the defaults
in GCC, except the gcc
CCing Kees Cook, he has been the one leading the efforts up to now. I hope
he can answer your queries.
Hi,
On Sat, 20 Nov 2010, Don Armstrong wrote:
There are a couple of things here that should be worked out first
before the CTTE can make a decision:
1) Has gcc's upstream been approached
[ Same message sent in bcc to all remaining FTBFS with new source format ]
Hello,
the new source format 3.0 (quilt) is now allowed in testing/unstable and
having all packages buildable with the new format is a release goal
(http://wiki.debian.org/ReleaseGoals/NewDebFormats).
Thus it would be
On Fri, 11 Sep 2009, Graham Cobb wrote:
On Friday 11 September 2009 14:24:49 Raphael Hertzog wrote:
On Fri, 11 Sep 2009, Matthias Klose wrote:
the only fix I can think of would be adding conflicts to every
package listing rmiregistry et al as a slave alternative. But I
don't know
On Fri, 11 Sep 2009, Matthias Klose wrote:
Setting up gcj-4.4-jre-headless (4.4.1-1) ...
update-alternatives: error: alternative rmiregistry can't be master: it is a
slave of java
dpkg: error processing gcj-4.4-jre-headless (--configure):
subprocess installed post-installation script
Hello,
it is well known that C++ symbol mangling result in different symbol
names from one architecture to the other. It means that libraries that
want to provide symbol files have to maintain one symbol file for each
architecture. To avoid this problem Modestas Vainius has written a patch
that
On Sat, 20 Jun 2009, Matthias Klose wrote:
Under normal curcumstances, I'd expect every shared library and application
to
require __aeabi_* from libgcc. Under normal circumstances these will come
from
libgcc_s.so, but if you link with --static-libgcc then you'll get your own
clone 533642 -1
reassign -1 libgcc1 1:4.4.0-7
retitle -1 Ensure __aeabi_* symbols are listed in libgcc1.symbols for armel
severity -1 important
thanks
On Sat, 20 Jun 2009, Raphael Hertzog wrote:
I think that to properly resolve my issue I have to allow you to export
those blacklisted symbols
On Fri, 19 Jun 2009, Christoph Egger wrote:
Building the NEW package I'm working on (irrlicht [3]) on my
ARM(el)[4] box (up-to-date sid pbuilder) causes dpkg-shlibdeps to
complain about missing symbols [0]. These symbols seem to be some gcc
internals that should be covered by libgcc_s.so
On Fri, 19 Jun 2009, Paul Brook wrote:
Now it seems that the irrlicht library depends on those symbols
provided by libgcc_s.so.1 (and does not define them locally contrary to
what was seen by Aurélien in libvorbis in #462318) and of course
dpkg-shlibdeps complains because they can't be found
On Sat, 07 Jun 2008, Ludovic Brenta wrote:
Read debian/README.maintainers for instructions on how to use quilt
with gnat-4.3.
If I read it correctly, the file debian/patches/series shouldn't be
in the gnat-4.3 source package at all since it's only used by the
maintainer to update patches.
On Tue, 06 May 2008, Filippo Giunchedi wrote:
Nevermind, those bugs have been already filed by Raphael.
Regarding packages Depending on binary libffi4 but source not build-depending
libffi-dev those should be:
binnmus have been filed already, see thread on debian-release:
On Sun, 09 Dec 2007, Neil Williams wrote:
Emdebian cannot build, patch or test every permutation of toolchain that
people need so this isn't about us patching locally, it is about
lowering the barrier to cross building on Debian by not forcing every
user to patch locally. This is why we are at
On Sun, 09 Dec 2007, Neil Williams wrote:
I'm ok with a
supplementary specific check for building of a cross-compiler, but not
with a generic check like testing the ARCH environment variable.
OK, I have a solution for that - replace $ARCH with $GCC_TARGET.
I've tested with this change
On Wed, 05 Dec 2007, Neil Williams wrote:
Raphael Hertzog wrote:
On Tue, 04 Dec 2007, Neil Williams wrote:
On Wed, 5 Dec 2007 00:01:22 +0100
Raphael Hertzog [EMAIL PROTECTED] wrote:
On Tue, 04 Dec 2007, Neil Williams wrote:
+my @shlibdeps=();
+# ARCH for some awkward builds
+my
Hello glibc/gcc maintainers,
I have a problem with generating a reduced libc6 using the PIC version.
I don't know if the problem comes from libc6, from gcc or from myself.
I asked on debian-boot but nobody answered since the problem doesn't
appear to come from mklibs bur rather glibc and/or gcc.
22 matches
Mail list logo
