several times inside Ubuntu
engineering. I understand this topic has come up several times in the past
for Debian as well, but nothing has really come of it to date.
I also had a chat about this with Matthias Klose (CCed) around 2022-05.
I've spent a while thinking through the options and comi
On 24.11.23 07:19, Emanuele Rocca wrote:
Hello!
On 2023-11-24 01:34, Guillem Jover wrote:
According to https://bugs.debian.org/918914#73 there were no pending
toolchain issues related to this.
That is correct. The GCC maintainers at Arm confirm that
stack-clash-protection is supported on 32 b
Hi,
it looks like enabling this flag on armel/armhf is a little bit premature.
Apparently it's not completely supported upstream, and might cause
regressions, according to
https://bugzilla.redhat.com/show_bug.cgi?id=1522678
Is that a feature that the Debian ARM32 porters and the security team
On 08/24/2015 11:12 PM, Niels Thykier wrote:
> * debhelper will be including debug-ids in the control file to make it
>easier to find the necessary debug symbols for a given file.
>- Thanks to paultag for this idea.
>- This is merged into git and will be included in the next upload.
a
Am 16.04.2013 15:19, schrieb Wookey:
> +++ Игорь Пашев [2013-04-16 16:49 +0400]:
>> 2013/4/16 Neil Williams :
>>> On Tue, 16 Apr 2013 16:11:24 +0400
>>>
>>
>>
>> So, is it important, that multiarch dirs go after crossdirs:
>> our @librarypaths = (DEFAULT_LIBRARY_PATH, @crosslibrarypaths);
>> ?
>
>
[CC-ing dpkg]
Am 17.02.2013 11:27, schrieb Jonathan Nieder:
> tags 700737 + moreinfo
> quit
>
> Hi Michael,
>
> Michael Gilbert wrote:
>
>> -
>> (optional|c++)"WebCore::TextIterator::getLocationAndLengthFromRange(WebCore::Element*,
>> WebCore::Range const*, unsigned int&, unsigned int&)@Base"
For toolchain packages like gcc-4.7, you can't deduce the build dependencies
automatically. Cross building the gcc-4.7 package (not building the cross
compiler) requires additional build dependencies, which for a native build are
used from the current build. These are:
g++-
g++-multilib- []
On 07/27/2011 11:56 PM, Raphael Hertzog wrote:
Hi,
On Tue, 26 Jul 2011, Raphael Hertzog wrote:
Assuming that all those improvements are done, the consensus was that
it's fine for dpkg-buildflags to start emitting the hardening build
flags by default. According to Ubuntu's experience only a few
On 21.03.2011 11:25, Neil Williams wrote:
> The people who are most likely to be doing this now are Linaro.
> Emdebian Crush stalled after Lenny (and used ARM not armel), so the
> version of gcc-4.2 in Lenny should still build with the typical
> "dpkg-buildpackage -aarm". Later versions of gcc prob
On 18.02.2011 11:13, Guillem Jover wrote:
[ CCing Matthias, as I'd like your opinion on my proposed solution
involving some Debian gcc changes. ]
The armhf patch for gcc looks ok, however I would like to see this better
addressed in Linaro and/or upstream.
Yes but x86 goes to the other
: Matthias Klose
To: debian-de...@lists.debian.org
I was looking at http://patches.ubuntu.com/o/openoffice.org/, a 133MB "patch"
for OOo. Afaiu the diff is cause by updating the ooo-build tarball from
openoffice.org_3.2.1.orig-ooo-build-3-2-1-2.tar.gz
to openoffice.org_3.2.1.orig-ooo-bui
On 27.04.2010 01:36, Joey Hess wrote:
Matthias Klose wrote:
calling dh_testdir in v5 mode on mips in the gcc-4.4 build starts 569 processes
The difficulty is that, for each package with a line like:
Architecture: $arch $arch $arch
If $arch is not "all"/"any", in order to
On 10.08.2009 23:55, Graham Cobb wrote:
Package: gcj-4.4-jre-headless
Version: 4.4.1-1
Severity: important
Doing 'aptitude safe-upgrade' on my squeeze system has resulted in
gcj-4.4-jre-headless being unable to be configured. The aptitude error is:
Setting up gcj-4.4-jre-headless (4.4.1-1) ...
Raphael Hertzog writes:
> On Tue, 24 Jun 2008, Matthias Klose wrote:
> > I'm preparing a build-essential upload; build-essential currently
> > depends on dpkg-dev (>= 1.13.5). Should the dependency tightened? If
> > yes, which version should be used?
>
> Why do
I'm preparing a build-essential upload; build-essential currently
depends on dpkg-dev (>= 1.13.5). Should the dependency tightened? If
yes, which version should be used? If a version greater than 1.14.6 is
used, I have to depend on dpkg and dpkg-dev, because dpkg-dev only
requires dpkg (>= 1.14.6).
> a few days ago we had a discussion on IRC about numerous problems created
> by a change in dpkg-dev:
> - http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=465282
>
> doko pointed out that several packages had to be updated to cope with the
> change and most notably the libc which had a run-time f
To ease the packaging of python modules, extensions and applications,
some extra meta information should be added to packages building
python modules, extensions and applications. This information says
something about for which python versions the package should be built
and which python versions c
Scott James Remnant writes:
> On Sun, 2005-04-03 at 15:29 +0200, Matthias Klose wrote:
>
> > Kamaraju Kusumanchi writes:
> > > Package: gcc-snapshot
> > > Version: 20050319-1
> > > Severity: normal
> > >
> > >
> > > While
Package: dpkg
Version: 1.13.4
Tags: experimental
looks like we're changing this variable anyway, substituting linux by
linux-gnu. There are some packages, for which the change from i386 to
i486 makes a difference, and we're not targeting i386 anymore.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTE
tags 308000 - experimental
thanks
Even with an uninstalled lsb-release package, dpkg-checkbuilddeps returns with
error code 0.
Build-Depends: lsb-release, foo [ia64, hppa]
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
why do you think this a bug in gcc-snapshot? dpkg-architecture flags
this as a warning. shouldn't it be dpkg's responsibility to map
between i386-linux and i486-linux-gnu. The gcc system type does not
have to match the gnu system type.
Kamaraju Kusumanchi writes:
> Package: gcc-snapshot
> Version:
Package: dpkg
Version: 1.10.23
Severity: important
g++-3.4 (3.4.1-7) has a dependency of the form
gcc-3.4 (>= 3.4.1-7), gcc-3.4 (<< 3.4.2)
to ensure that the g++ driver (/usr/bin/g++-3.4) can find files in the
gcclibdir (/usr/lib/gcc//3.4.1 or /usr/lib/gcc//3.4.2).
Having installed all
The ~ character can be used in package versions, so that x.y~pre1-1 <<
x.y-1, but it's currently not used and lintian complains about
it. nevertheless it seems to work. can this notation already be used
for packages, which could be part of sarge? what are the required
versions of dpkg and apt to us
Wichert Akkerman writes:
> * there is a dpkg-patch tool that can apply or reverse patches. It will
> check if patches are applied in order, and can unpack the original source
> and produce a diff from that to the current source so we can easily
> generate a new patch. The status for each patch
Package: dpkg
Version: 1.4.1.6
Severity: important
gcj-2.95.1-0pre1 triggers the following assertion. I cannot see a
mistake in the control fields. Please reassign the bug to gcj, if it's
a gcj configuration error.
Unpacking gcj (from .../gcj_1%3a2.95.1-0pre1_i386.deb) ...
dpkg: ../../../main/pa
When building a source package, where the binary packages get their
own version numbers, dpkg-genchanges does not get the correct version
number. If you look at the package python-rng, then it get's its own
version number 1.1-11.1. It is correctly built as
dh_gencontrol -ppython-rng -u-v1.1-11.1
Package: dpkg
Version: 1.4.0.31
I still have an entry
libncurses 3.4 ncurses3.4
in /etc/dpkg/shlibs.default. Should this be updated for slink?
This file doesn't belong to any package ...
[not submitted as a bug report, rather a question]
Package: lintian
Severity: wishlist
It would be nice, if lintian can parse the Depends/Recommends etc
lines and check for bad version numbers. Not sure if this issue should
be addressed in lintian or in packages like dpkg or debhelper.
A depend
28 matches
Mail list logo
