On 04/22/2016 12:11 AM, Santiago Vila wrote:
On Thu, 30 Apr 2015, Matthias Klose wrote:
On 04/30/2015 10:43 PM, Daniel Serpell wrote:
Currently, gcc-5 packages are really big because the files under
/usr/lib/gcc/x86_64-linux-gnu/5 are not stripped, and each one of
lto1, cc1 and cc1plus is abo
On 04/22/2016 12:11 AM, Santiago Vila wrote:
On Thu, 30 Apr 2015, Matthias Klose wrote:
On 04/30/2015 10:43 PM, Daniel Serpell wrote:
Currently, gcc-5 packages are really big because the files under
/usr/lib/gcc/x86_64-linux-gnu/5 are not stripped, and each one of
lto1, cc1 and cc1plus is abou
On Fri, Apr 22, 2016 at 12:47:09AM +0200, Matthias Klose wrote:
>
>you didn't write about how much the netinst image exceeds the cd size. If it
>helps, lto1 could be stripped by default, because it's not used by default
>for package builds.
Looking for about 70MB to (just) squeeze into 1 CD again
On 22.04.2016 00:55, Santiago Vila wrote:
On Fri, Apr 22, 2016 at 12:22:33AM +0200, Matthias Klose wrote:
On 22.04.2016 00:11, Santiago Vila wrote:
The problem with that is that it breaks the expectation that testing
is in an "always releaseable" state.
Sure, the file /etc/debian_version break
On Fri, Apr 22, 2016 at 12:22:33AM +0200, Matthias Klose wrote:
> On 22.04.2016 00:11, Santiago Vila wrote:
> >The problem with that is that it breaks the expectation that testing
> >is in an "always releaseable" state.
> >
> >Sure, the file /etc/debian_version breaks such expectation too, but of
>
Matthias Klose, on Fri 22 Apr 2016 00:47:09 +0200, wrote:
> >With separate -unstripped (or whatever) packages, they could be
> >installed by admin choice in those situations.
>
> well, admin choice is usually not the default. So this would miss the buildds.
Making the buildds install extra packag
On 22.04.2016 00:31, Steve McIntyre wrote:
On Thu, Apr 21, 2016 at 11:40:34PM +0200, Matthias Klose wrote:
So why does the netinst image need a compiler?
It's been a feature for years that we include a compiler and kernel
headers to allow people to build third party modules on amd64/i386.
ok
On Thu, Apr 21, 2016 at 11:31:46PM +0100, Steve McIntyre wrote:
>On Thu, Apr 21, 2016 at 11:40:34PM +0200, Matthias Klose wrote:
>>
>>The unstripped binaries should be installed by default on porter boxes and
>>buildds. Yes, this is a trade-off between (largely my) developer time, the
>>ability fo
On 22.04.2016 00:30, Hilko Bengen wrote:
* Matthias Klose:
gcc-multilib used to provide a symlink for /usr/include/asm (in my case
to x86_64-linux-gnu/asm). Restoring that symlink would fix the problem I
observed.
the /usr/include/asm symlink is shipped in the gcc-multilib package.
We can't s
* Matthias Klose:
>> gcc-multilib used to provide a symlink for /usr/include/asm (in my case
>> to x86_64-linux-gnu/asm). Restoring that symlink would fix the problem I
>> observed.
>
> the /usr/include/asm symlink is shipped in the gcc-multilib package.
> We can't ship it in any gcc-*-multilib pa
On Thu, Apr 21, 2016 at 11:40:34PM +0200, Matthias Klose wrote:
>Control: severity -1 important
>
>On 21.04.2016 19:28, Steve McIntyre wrote:
>>Control: severity -1 serious
>>Justification: wasting many megabytes of space and download
>
>sorry, I don't see this as a justification.
>
>>We're shippin
On 22.04.2016 00:11, Santiago Vila wrote:
On Thu, 30 Apr 2015, Matthias Klose wrote:
On 04/30/2015 10:43 PM, Daniel Serpell wrote:
Currently, gcc-5 packages are really big because the files under
/usr/lib/gcc/x86_64-linux-gnu/5 are not stripped, and each one of
lto1, cc1 and cc1plus is about 1
Control: tags -1 + wontfix
On 22.04.2016 00:03, Hilko Bengen wrote:
Package: gcc-5-multilib
Version: 5.3.1-14
Severity: important
Dear Maintainers,
when trying to build i386 binaries using gcc-5-multilib on an amd64
host, includes cannot be resolved.
,
| $ echo '#include ' | gcc -m32 -E
Your message dated Fri, 22 Apr 2016 00:13:46 +0200
with message-id <5719509a.2050...@debian.org>
and subject line Re: Bug#822189: gcc-5-multilib: asm/errno.h not found for
non-default architecture
has caused the Debian Bug report #822189,
regarding gcc-5-multilib: asm/errno.h not found for non-def
Processing control commands:
> tags -1 + wontfix
Bug #822189 [gcc-5-multilib] gcc-5-multilib: asm/errno.h not found for
non-default architecture
Added tag(s) wontfix.
--
822189: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=822189
Debian Bug Tracking System
Contact ow...@bugs.debian.org with
On Thu, 30 Apr 2015, Matthias Klose wrote:
> On 04/30/2015 10:43 PM, Daniel Serpell wrote:
> > Currently, gcc-5 packages are really big because the files under
> > /usr/lib/gcc/x86_64-linux-gnu/5 are not stripped, and each one of
> > lto1, cc1 and cc1plus is about 130MB.
> >
> > Please, can those
On Thu, Apr 21, 2016 at 11:23:41PM +0200, Matthias Klose wrote:
>On 21.04.2016 20:08, Ondřej Surý wrote:
>>>From reading the bug comments I can see both sides of the argument, so
>>why we don't ship just two versions that would be exchangeable - one
>>with symbols and one (default) stripped?
>>
>>T
Package: gcc-5-multilib
Version: 5.3.1-14
Severity: important
Dear Maintainers,
when trying to build i386 binaries using gcc-5-multilib on an amd64
host, includes cannot be resolved.
,
| $ echo '#include ' | gcc -m32 -E - > /dev/null
| In file included from /usr/include/bits/errno.h:24:0,
Control: severity -1 important
On 21.04.2016 19:28, Steve McIntyre wrote:
Control: severity -1 serious
Justification: wasting many megabytes of space and download
sorry, I don't see this as a justification.
We're shipping broken toolchain packages
please stop trolling. Nothing is broken.
Processing control commands:
> severity -1 important
Bug #783876 [gcc-5] gcc-5: consider stripping lto1 / cc1 / cc1plus
Severity set to 'important' from 'serious'
--
783876: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=783876
Debian Bug Tracking System
Contact ow...@bugs.debian.org with prob
On 21.04.2016 20:08, Ondřej Surý wrote:
From reading the bug comments I can see both sides of the argument, so
why we don't ship just two versions that would be exchangeable - one
with symbols and one (default) stripped?
The stripped one would be installed by default and if you need to
produce
>From reading the bug comments I can see both sides of the argument, so
why we don't ship just two versions that would be exchangeable - one
with symbols and one (default) stripped?
The stripped one would be installed by default and if you need to
produce trace, you would install the second varian
LAST_UPDATED: Thu Apr 14 22:10:49 UTC 2016 (revision 234994)
Target: i586-gnu
gcc version 6.0.0 20160414 (experimental) [trunk revision 234994] (Debian
20160415-1)
Native configuration is i586-pc-gnu
=== g++ tests ===
Running target unix
FAIL: g++.dg/cdce3.C -std=gnu++98 exec
Processing control commands:
> severity -1 serious
Bug #783876 [gcc-5] gcc-5: consider stripping lto1 / cc1 / cc1plus
Severity set to 'serious' from 'wishlist'
--
783876: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=783876
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problem
Control: severity -1 serious
Justification: wasting many megabytes of space and download
We're shipping broken toolchain packages that are intentionally too
large, and this is causing issues elsewhere. The "netinst" CD image
that we advertise to people as the default Debian image to use for
most i
25 matches
Mail list logo
