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:
ht
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
backpor
On Wed, 13 Jun 2012, Raphael Hertzog wrote:
> If some of them are no longer "internal machinery" and no longer present in
> random libraries, then we ought to de-blacklist them.
Or rather, you should force their inclusion in libgcc's symbols file.
We created the "ignore-
Hello,
On Wed, 13 Jun 2012, Guillem Jover wrote:
> On Wed, 2012-06-13 at 07:06:47 +0200, Guillem Jover wrote:
> > I've actually have had this on my TODO to deal with, which I found
> > when checking libudt on armel some time ago. I'm reassigning and will
> > push a fix for dpkg 1.16.5.
>
> Actual
On Tue, 12 Jun 2012, Matthias Klose wrote:
> Raphael, should dpkg-shlibdeps behave differently about these? I can't see
> anything wrong on the GCC side.
I don't know. Is there anything special about this symbol?
We have a bunch of "blacklisted" symbols in dpkg-shlibdeps. Should this
one be added
On Sat, 19 Nov 2011, Ben Hutchings wrote:
> Also possibly:
> 6. DM&P/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
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
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
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 approach
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 m
[ 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 rmiregistr
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 scr
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 le
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 s
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 ow
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
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
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.
Dur
pposed to unapply them (because dpkg-source -b might
have applied them back)
Cheers,
[1] http://lists.debian.org/debian-devel-announce/2008/04/msg4.html
[2] the upcoming dpkg-dev 1.14.20 is more tolerant with patches, you can
grab it here if you want to try with that version:
http://people.debian.org/~hertzog/packages/dpkg-dev_1.14.20_all.deb
--
Raphael Hertzog
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
s supposed to unapply them (because dpkg-source -b might
have applied them back)
Cheers,
[1] http://lists.debian.org/debian-devel-announce/2008/04/msg4.html
[2] the upcoming dpkg-dev 1.14.20 is more tolerant with patches, you can
grab it here if you want to try with that version:
http://pe
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:
http://lists.de
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 thi
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 a
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 Willia
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.
27 matches
Mail list logo
