Debian Bug report logs - #783876
gcc-5: consider stripping lto1 / cc1 / cc1plus

Reply or subscribe to this bug.

Toggle useless messages

Message #5 received at submit@bugs.debian.org (full text, mbox, reply):

From: Daniel Serpell <daniel.serpell@aplik.cl>

To: Debian Bug Tracking System <submit@bugs.debian.org>

Subject: gcc-5: consider stripping lto1 / cc1 / cc1plus

Date: Thu, 30 Apr 2015 17:43:00 -0300

Package: gcc-5
Version: 5.1.1-2
Severity: wishlist

Dear Maintainer,

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 files be striped in the default installation?

Thanks for your work,

-- System Information:
Debian Release: stretch/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (50, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 3.16.0-4-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages gcc-5 depends on:
ii  binutils      2.25-7
ii  cpp-5         5.1.1-2
ii  gcc-5-base    5.1.1-2
ii  libc6         2.19-18
ii  libcc1-0      5.1.1-2
ii  libgcc-5-dev  5.1.1-2
ii  libgcc1       1:5.1.1-2
ii  libgmp10      2:6.0.0+dfsg-6
ii  libisl13      0.14-2
ii  libmpc3       1.0.3-1
ii  libmpfr4      3.1.2-3
ii  libstdc++6    5.1.1-2
ii  zlib1g        1:1.2.8.dfsg-2+b1

Versions of packages gcc-5 recommends:
ii  libc6-dev  2.19-18

Versions of packages gcc-5 suggests:
pn  gcc-5-doc         <none>
pn  gcc-5-locales     <none>
pn  gcc-5-multilib    <none>
pn  libasan2-dbg      <none>
pn  libatomic1-dbg    <none>
pn  libcilkrts5-dbg   <none>
ii  libgcc1-dbg       1:5.1.1-2
pn  libgomp1-dbg      <none>
pn  libitm1-dbg       <none>
pn  liblsan0-dbg      <none>
pn  libmpx0-dbg       <none>
pn  libquadmath0-dbg  <none>
pn  libtsan0-dbg      <none>
pn  libubsan0-dbg     <none>

-- no debconf information

Message #10 received at 783876@bugs.debian.org (full text, mbox, reply):

From: Matthias Klose <doko@debian.org>

To: Daniel Serpell <daniel.serpell@aplik.cl>, 783876@bugs.debian.org

Subject: Re: Bug#783876: gcc-5: consider stripping lto1 / cc1 / cc1plus

Date: Thu, 30 Apr 2015 23:10:15 +0200

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 files be striped in the default installation?

I'd like to avoid this, and only change that near the next Debian release.
These binaries are linked against libbacktrace to provide a verbose backtrace on
internal compiler errors, which you can't get with stripped binaries.

Message #15 received at 783876@bugs.debian.org (full text, mbox, reply):

From: Guillem Jover <guillem@debian.org>

To: Daniel Serpell <daniel.serpell@aplik.cl>, 783876@bugs.debian.org

Subject: Re: Bug#783876: gcc-5: consider stripping lto1 / cc1 / cc1plus

Date: Sun, 28 Jun 2015 17:52:19 +0200

Hi!

On Thu, 2015-04-30 at 17:43:00 -0300, Daniel Serpell wrote:
> Package: gcc-5
> Version: 5.1.1-2
> Severity: wishlist

> 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 files be striped in the default installation?

I'd second that, in my case all the involved packages are using almost
1 GiB of additional disk space.

In the meantime I'm stripping the files on installation/upgrade via
triggers:

  <http://git.hadrons.org/cgit/debian/gcc-on-diet.git/>

in case others find it useful. And I guess I could create a package
repository for it, if there's demand.

Thanks,
Guillem

Message #20 received at 783876@bugs.debian.org (full text, mbox, reply):

From: Josh Triplett <josh@joshtriplett.org>

To: 783876@bugs.debian.org

Subject: Re: Bug#783876: gcc-5: consider stripping lto1 / cc1 / cc1plus

Date: Sat, 4 Jul 2015 07:23:10 -0700

On Thu, 30 Apr 2015 23:10:15 +0200 Matthias Klose <doko@debian.org> 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 files be striped in the default installation?
> 
> I'd like to avoid this, and only change that near the next Debian release.
> These binaries are linked against libbacktrace to provide a verbose backtrace on
> internal compiler errors, which you can't get with stripped binaries.

Linking against libbacktrace seems completely fine.  However, can
libbacktrace not use detached debug symbols, as found in -dbg packages?
And if so, could you move the symbols for those binaries into an
appropriate -dbg package?

- Josh Triplett

Message #23 received at 783876@bugs.debian.org (full text, mbox, reply):

From: Basile Starynkevitch <basile@starynkevitch.net>

To: debian-gcc@lists.debian.org

Subject: Re: Bug#783876: gcc-5: consider stripping lto1 / cc1 / cc1plus

Date: Sun, 28 Jun 2015 18:19:27 +0200

On 06/28/2015 05:52 PM, Guillem Jover wrote:
> Hi!
>
> On Thu, 2015-04-30 at 17:43:00 -0300, Daniel Serpell wrote:
>> Package: gcc-5
>> Version: 5.1.1-2
>> Severity: wishlist
>> 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 files be striped in the default installation?
> I'd second that, in my case all the involved packages are using almost
> 1 GiB of additional disk space.
>
> In the meantime I'm stripping the files on installation/upgrade via
> triggers:
>
>    <http://git.hadrons.org/cgit/debian/gcc-on-diet.git/>
>
> in case others find it useful. And I guess I could create a package
> repository for it, if there's demand.



Don't do that. If you strip cc1 & cc1plus (etc...) you cannot have GCC 
plugins.

Regards

-- 
Basile STARYNKEVITCH         http://starynkevitch.net/Basile/
email: basile<at>starynkevitch<dot>net mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mine, sont seulement les miennes} ***


-- 
To UNSUBSCRIBE, email to debian-gcc-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: https://lists.debian.org/55901E8F.5060206@starynkevitch.net

Message #28 received at 783876@bugs.debian.org (full text, mbox, reply):

From: Matthias Klose <doko@debian.org>

To: Josh Triplett <josh@joshtriplett.org>, 783876@bugs.debian.org

Cc: Basile Starynkevitch <basile@starynkevitch.net>

Subject: Re: Bug#783876: gcc-5: consider stripping lto1 / cc1 / cc1plus

Date: Tue, 07 Jul 2015 11:08:13 +0200

On 07/04/2015 04:23 PM, Josh Triplett wrote:
> On Thu, 30 Apr 2015 23:10:15 +0200 Matthias Klose <doko@debian.org> 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 files be striped in the default installation?
>>
>> I'd like to avoid this, and only change that near the next Debian release.
>> These binaries are linked against libbacktrace to provide a verbose backtrace on
>> internal compiler errors, which you can't get with stripped binaries.
> 
> Linking against libbacktrace seems completely fine.  However, can
> libbacktrace not use detached debug symbols, as found in -dbg packages?

No.

Plus, Basile mentions that plugins won't work anymore with stripped binaries,
however I fail to see why that would be the case. We had clang plugin working in
the past too.

Matthias

Message #33 received at 783876@bugs.debian.org (full text, mbox, reply):

From: Basile Starynkevitch <basile@starynkevitch.net>

To: Matthias Klose <doko@debian.org>, 783876@bugs.debian.org

Cc: Josh Triplett <josh@joshtriplett.org>, Basile Starynkevitch <basile@starynkevitch.net>

Subject: Re: Bug#783876: gcc-5: consider stripping lto1 / cc1 / cc1plus

Date: Fri, 10 Jul 2015 09:22:25 +0200

On Tue, Jul 07, 2015 at 11:08:13AM +0200, Matthias Klose wrote:
> On 07/04/2015 04:23 PM, Josh Triplett wrote:
> > On Thu, 30 Apr 2015 23:10:15 +0200 Matthias Klose <doko@debian.org> 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 files be striped in the default installation?
> >>
> >> I'd like to avoid this, and only change that near the next Debian release.
> >> These binaries are linked against libbacktrace to provide a verbose backtrace on
> >> internal compiler errors, which you can't get with stripped binaries.
> > 
> > Linking against libbacktrace seems completely fine.  However, can
> > libbacktrace not use detached debug symbols, as found in -dbg packages?
> 
> No.
> 
> Plus, Basile mentions that plugins won't work anymore with stripped binaries,
> however I fail to see why that would be the case. We had clang plugin working in
> the past too.
> 


How can a plugin call existing GCC functions, e.g. walk_gimple_seq
declared in
/usr/lib/gcc/x86_64-linux-gnu/5/plugin/include/gimple-walk.h and
implemented inside cc1 ?

(Unless you don't strip the dynamic symbols linked with -rdynamic when building cc1)

Regards.

-- 
Basile Starynkevitch      http://starynkevitch.net/Basile/
France

Message #38 received at 783876@bugs.debian.org (full text, mbox, reply):

From: Guillem Jover <guillem@debian.org>

To: Basile Starynkevitch <basile@starynkevitch.net>, 783876@bugs.debian.org

Cc: Matthias Klose <doko@debian.org>, Josh Triplett <josh@joshtriplett.org>

Subject: Re: Bug#783876: gcc-5: consider stripping lto1 / cc1 / cc1plus

Date: Sun, 12 Jul 2015 19:26:11 +0200

Hi!

On Fri, 2015-07-10 at 09:22:25 +0200, Basile Starynkevitch wrote:
> How can a plugin call existing GCC functions, e.g. walk_gimple_seq
> declared in
> /usr/lib/gcc/x86_64-linux-gnu/5/plugin/include/gimple-walk.h and
> implemented inside cc1 ?

I've not checked how plugins are implemented in gcc, but I'd assume it
either passes something like a struct with function pointers for its
"public interface", or it is linked with -rdynamic.

> (Unless you don't strip the dynamic symbols linked with -rdynamic when building cc1)

This does not make any sense, striping debugging symbols should not
affect either approach. Otherwise this is like suggesting shared
libraries cannot be stripped because programs will not be able to
link against them…

Also if the backends are actually compiled with -rdynamic this should
be giving better backtraces than otherwise, and might actually be enough
for what is being sought out in here anyway.

Thanks,
Guillem

Message #43 received at 783876@bugs.debian.org (full text, mbox, reply):

From: Aurelien Jarno <aurelien@aurel32.net>

To: Matthias Klose <doko@debian.org>

Cc: Daniel Serpell <daniel.serpell@aplik.cl>, 783876@bugs.debian.org

Subject: Re: Bug#783876: gcc-5: consider stripping lto1 / cc1 / cc1plus

Date: Mon, 3 Aug 2015 09:47:33 +0200

On 2015-04-30 23:10, 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 files be striped in the default installation?
> 
> I'd like to avoid this, and only change that near the next Debian release.
> These binaries are linked against libbacktrace to provide a verbose backtrace on
> internal compiler errors, which you can't get with stripped binaries.

If that's not possible could you please at least change these binaries to
use compressed debug sections at least? That should save quite some space
already.

-- 
Aurelien Jarno                          GPG: 4096R/1DDD8C9B
aurelien@aurel32.net                 http://www.aurel32.net

Message #48 received at 783876@bugs.debian.org (full text, mbox, reply):

From: Basile Starynkevitch <basile@starynkevitch.net>

To: Aurelien Jarno <aurelien@aurel32.net>, 783876@bugs.debian.org

Cc: Matthias Klose <doko@debian.org>, Daniel Serpell <daniel.serpell@aplik.cl>

Subject: Re: Bug#783876: gcc-5: consider stripping lto1 / cc1 / cc1plus

Date: Mon, 3 Aug 2015 09:57:06 +0200

On Mon, Aug 03, 2015 at 09:47:33AM +0200, Aurelien Jarno wrote:
> On 2015-04-30 23:10, 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 files be striped in the default installation?
> > 
> > I'd like to avoid this, and only change that near the next Debian release.
> > These binaries are linked against libbacktrace to provide a verbose backtrace on
> > internal compiler errors, which you can't get with stripped binaries.
> 
> If that's not possible could you please at least change these binaries to
> use compressed debug sections at least? That should save quite some space
> already.

I would believe that is not easily possible. I don't know the detailed
behavior of libbacktrace, but it is using & parsing the DWARF debug
information of the binaries (cc1, cc1plus, ...), so I guess you'll need
to patch (significantly) libbacktrace to compress the debug sections.

BTW, I don't see the size of cc1 etc... as an issue. Compilers are
useful on "development" machines, and these are usually not very small
(and have enought disk space).

Cheers
-- 
Basile Starynkevitch            http://starynkevitch.net/Basile/
France                          basile at starynkevitch.net

Message #53 received at 783876@bugs.debian.org (full text, mbox, reply):

From: Aurelien Jarno <aurelien@aurel32.net>

To: Basile Starynkevitch <basile@starynkevitch.net>

Cc: 783876@bugs.debian.org, Matthias Klose <doko@debian.org>, Daniel Serpell <daniel.serpell@aplik.cl>

Subject: Re: Bug#783876: gcc-5: consider stripping lto1 / cc1 / cc1plus

Date: Mon, 3 Aug 2015 10:26:59 +0200

On 2015-08-03 09:57, Basile Starynkevitch wrote:
> On Mon, Aug 03, 2015 at 09:47:33AM +0200, Aurelien Jarno wrote:
> > On 2015-04-30 23:10, 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 files be striped in the default installation?
> > > 
> > > I'd like to avoid this, and only change that near the next Debian release.
> > > These binaries are linked against libbacktrace to provide a verbose backtrace on
> > > internal compiler errors, which you can't get with stripped binaries.
> > 
> > If that's not possible could you please at least change these binaries to
> > use compressed debug sections at least? That should save quite some space
> > already.
> 
> I would believe that is not easily possible. I don't know the detailed
> behavior of libbacktrace, but it is using & parsing the DWARF debug
> information of the binaries (cc1, cc1plus, ...), so I guess you'll need
> to patch (significantly) libbacktrace to compress the debug sections.

compressed debug sections is kind of standard these days, so
libbacktrace should support that.

> BTW, I don't see the size of cc1 etc... as an issue. Compilers are
> useful on "development" machines, and these are usually not very small
> (and have enought disk space).

This adds roughly 1GB to the size of a chroot used on the Debian build
daemons. As it is unpacked from a tarball for each package to build, it 
has a significant impact on the time needed to unpack the chroot.

-- 
Aurelien Jarno                          GPG: 4096R/1DDD8C9B
aurelien@aurel32.net                 http://www.aurel32.net

Message #58 received at 783876@bugs.debian.org (full text, mbox, reply):

From: Matthias Klose <doko@debian.org>

To: Aurelien Jarno <aurelien@aurel32.net>, 783876@bugs.debian.org, Basile Starynkevitch <basile@starynkevitch.net>

Cc: Daniel Serpell <daniel.serpell@aplik.cl>

Subject: Re: Bug#783876: gcc-5: consider stripping lto1 / cc1 / cc1plus

Date: Sun, 09 Aug 2015 15:22:24 +0200

Control: forwarded -1 https://gcc.gnu.org/PR67165

On 08/03/2015 10:26 AM, Aurelien Jarno wrote:
> On 2015-08-03 09:57, Basile Starynkevitch wrote:
>> I would believe that is not easily possible. I don't know the detailed
>> behavior of libbacktrace, but it is using & parsing the DWARF debug
>> information of the binaries (cc1, cc1plus, ...), so I guess you'll need
>> to patch (significantly) libbacktrace to compress the debug sections.
> 
> compressed debug sections is kind of standard these days, so
> libbacktrace should support that.

no.

Message #69 received at 783876@bugs.debian.org (full text, mbox, reply):

From: Steve McIntyre <steve@einval.com>

To: 783876@bugs.debian.org

Cc: debian-devel@lists.debian.org

Subject: Seriously, these binaries should be stripped by default

Date: Thu, 21 Apr 2016 18:28:59 +0100

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 installations is now huge. The multi-arch netinst no longer even
fits on a single CD due to this waste of space.

There's not been any visible progress on this bug in since last
year. If upstream want to ship uncompressed binaries for diagnostics
and can't cope with separate debug symbols, maybe ship separate
alternative unstripped toolchain packages and point to those if people
want them?

-- 
Steve McIntyre, Cambridge, UK.                                steve@einval.com
"When C++ is your hammer, everything looks like a thumb." -- Steven M. Haflich

Message #76 received at 783876@bugs.debian.org (full text, mbox, reply):

From: Ondřej Surý <ondrej@sury.org>

To: Steve McIntyre <steve@einval.com>, 783876@bugs.debian.org

Subject: Re: Seriously, these binaries should be stripped by default

Date: Thu, 21 Apr 2016 20:08:17 +0200

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 variant. GCC plugins also
could depend on unstripped variant of the package. That would provide
both parties what they need.

Cheers,
-- 
Ondřej Surý <ondrej@sury.org>
Knot DNS (https://www.knot-dns.cz/) – a high-performance DNS server

Message #81 received at 783876@bugs.debian.org (full text, mbox, reply):

From: Matthias Klose <doko@debian.org>

To: Ondřej Surý <ondrej@sury.org>, 783876@bugs.debian.org, Steve McIntyre <steve@einval.com>

Subject: Re: Bug#783876: Seriously, these binaries should be stripped by default

Date: Thu, 21 Apr 2016 23:23:41 +0200

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 trace, you would install the second variant. GCC plugins also
> could depend on unstripped variant of the package. That would provide
> both parties what they need.

so how do the unstripped ones get installed by default on porter boxes? How are 
the unstripped ones installed on the buildds by default?

Matthias

Message #86 received at 783876@bugs.debian.org (full text, mbox, reply):

From: Matthias Klose <doko@debian.org>

To: Steve McIntyre <steve@einval.com>, 783876@bugs.debian.org

Cc: debian-devel@lists.debian.org, Ondřej Surý <ondrej@sury.org>

Subject: Re: Bug#783876: Seriously, these binaries should be stripped by default

Date: Thu, 21 Apr 2016 23:40:34 +0200

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.

No, we don't ship these, as clearly stated in this report. They are in the 
archive as unstripped versions.  Other software stacks as the Go stack ship 
unstripped binaries as well, because they need these.

> 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 installations is now huge. The multi-arch netinst no longer even
> fits on a single CD due to this waste of space.

So why does the netinst image need a compiler?

> There's not been any visible progress on this bug in since last
> year. If upstream want to ship uncompressed binaries for diagnostics
> and can't cope with separate debug symbols, maybe ship separate
> alternative unstripped toolchain packages and point to those if people
> want them?

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 for Debian developers to produce complete bug reports, and an increase 
on machine/bandwidth resources.  If I have the choice to select between human 
and other resources, I'll try to keep the time I have to spend on reproducing 
things rather small.

> There's not been any visible progress on this bug in since last
> year.

So you step in here like a bull in a china shop, raising the severity without 
doing anything else?  You are working for a Linux and open source aware 
organization, have you tried to get developer time to address issues like these? 
 Have you sent a patch proposal to implement such a change either upstream or 
on the packaging side?

Not that amused, Matthias

Message #93 received at 783876@bugs.debian.org (full text, mbox, reply):

From: Steve McIntyre <steve@einval.com>

To: Matthias Klose <doko@debian.org>

Cc: Ondřej Surý <ondrej@sury.org>, 783876@bugs.debian.org, debian-devel@lists.debian.org

Subject: Re: Bug#783876: Seriously, these binaries should be stripped by default

Date: Thu, 21 Apr 2016 23:05:54 +0100

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?
>>
>>The stripped one would be installed by default and if you need to
>>produce trace, you would install the second variant. GCC plugins also
>>could depend on unstripped variant of the package. That would provide
>>both parties what they need.
>
>so how do the unstripped ones get installed by default on porter boxes? How
>are the unstripped ones installed on the buildds by default?

By talking to the admins of those boxes, maybe? The setup on those is
already heavily scripted, so hopefully shouldn't be too difficult to
adapt.

-- 
Steve McIntyre, Cambridge, UK.                                steve@einval.com
"We're the technical experts.  We were hired so that management could
 ignore our recommendations and tell us how to do our jobs."  -- Mike Andrews

Message #98 received at 783876@bugs.debian.org (full text, mbox, reply):

From: Santiago Vila <sanvila@unex.es>

To: 783876@bugs.debian.org

Subject: Re: Bug#783876: gcc-5: consider stripping lto1 / cc1 / cc1plus

Date: Fri, 22 Apr 2016 00:11:47 +0200 (CEST)

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 files be striped in the default installation?
> 
> I'd like to avoid this, and only change that near the next Debian release.

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
course this is absolutely minor compared with the huge gcc binaries.

Message #103 received at 783876@bugs.debian.org (full text, mbox, reply):

From: Matthias Klose <doko@debian.org>

To: Santiago Vila <sanvila@unex.es>, 783876@bugs.debian.org

Subject: Re: Bug#783876: gcc-5: consider stripping lto1 / cc1 / cc1plus

Date: Fri, 22 Apr 2016 00:22:33 +0200

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 130MB.
>>>
>>> Please, can those files be striped in the default installation?
>>
>> I'd like to avoid this, and only change that near the next Debian release.
>
> 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
> course this is absolutely minor compared with the huge gcc binaries.

this is off topic, however I think this base-files change is rather serious, 
because it lies about the status of sid/unstable.  From my point of view such a 
change of base-files should go to testing directly.

Message #108 received at 783876@bugs.debian.org (full text, mbox, reply):

From: Steve McIntyre <steve@einval.com>

To: Matthias Klose <doko@debian.org>

Cc: 783876@bugs.debian.org, debian-devel@lists.debian.org, Ondřej Surý <ondrej@sury.org>

Subject: Re: Bug#783876: Seriously, these binaries should be stripped by default

Date: Thu, 21 Apr 2016 23:31:46 +0100

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 shipping broken toolchain packages
>
>please stop trolling. Nothing is broken.

Thanks for the insult. :-(

There's no trolling here - they're broken according to policy ("by
default all installed binaries should be stripped"), and this change
is causing real problems for people.

>>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 installations is now huge. The multi-arch netinst no longer even
>>fits on a single CD due to this waste of space.
>
>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.

>>There's not been any visible progress on this bug in since last
>>year. If upstream want to ship uncompressed binaries for diagnostics
>>and can't cope with separate debug symbols, maybe ship separate
>>alternative unstripped toolchain packages and point to those if people
>>want them?
>
>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 for Debian developers to produce complete bug reports, and an
>increase on machine/bandwidth resources.  If I have the choice to select
>between human and other resources, I'll try to keep the time I have to spend
>on reproducing things rather small.

With separate -unstripped (or whatever) packages, they could be
installed by admin choice in those situations.

>> There's not been any visible progress on this bug in since last
>> year.
>
>So you step in here like a bull in a china shop, raising the severity without
>doing anything else?  You are working for a Linux and open source aware
>organization, have you tried to get developer time to address issues like
>these?  Have you sent a patch proposal to implement such a change either
>upstream or on the packaging side?

Please don't go there. We're all busy, you know that.

-- 
Steve McIntyre, Cambridge, UK.                                steve@einval.com
Google-bait:       http://www.debian.org/CD/free-linux-cd
  Debian does NOT ship free CDs. Please do NOT contact the mailing
  lists asking us to send them to you.

Message #113 received at 783876@bugs.debian.org (full text, mbox, reply):

From: Steve McIntyre <steve@einval.com>

To: Matthias Klose <doko@debian.org>

Cc: 783876@bugs.debian.org, debian-devel@lists.debian.org

Subject: Re: Bug#783876: Seriously, these binaries should be stripped by default

Date: Thu, 21 Apr 2016 23:40:44 +0100

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 for Debian developers to produce complete bug reports, and an
>>increase on machine/bandwidth resources.  If I have the choice to select
>>between human and other resources, I'll try to keep the time I have to spend
>>on reproducing things rather small.
>
>With separate -unstripped (or whatever) packages, they could be
>installed by admin choice in those situations.

Following up a bit more - I understand what you've done here, and I
understand what you're trying to achieve here. Would you accept
patches to add -unstripped versions to the packaging if they were
offered?

-- 
Steve McIntyre, Cambridge, UK.                                steve@einval.com
"Because heaters aren't purple!" -- Catherine Pitt

Message #118 received at 783876@bugs.debian.org (full text, mbox, reply):

From: Matthias Klose <doko@debian.org>

To: Steve McIntyre <steve@einval.com>, 783876@bugs.debian.org

Cc: debian-devel@lists.debian.org, Ondřej Surý <ondrej@sury.org>

Subject: Re: Bug#783876: Seriously, these binaries should be stripped by default

Date: Fri, 22 Apr 2016 00:47:09 +0200

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, thanks for the explanation.

>>> There's not been any visible progress on this bug in since last
>>> year. If upstream want to ship uncompressed binaries for diagnostics
>>> and can't cope with separate debug symbols, maybe ship separate
>>> alternative unstripped toolchain packages and point to those if people
>>> want them?
>>
>> 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 for Debian developers to produce complete bug reports, and an
>> increase on machine/bandwidth resources.  If I have the choice to select
>> between human and other resources, I'll try to keep the time I have to spend
>> on reproducing things rather small.
>
> 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.

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.

Matthias

Message #123 received at 783876@bugs.debian.org (full text, mbox, reply):

From: Samuel Thibault <sthibault@debian.org>

To: Matthias Klose <doko@debian.org>

Cc: Steve McIntyre <steve@einval.com>, 783876@bugs.debian.org, debian-devel@lists.debian.org, Ondřej Surý <ondrej@sury.org>

Subject: Re: Bug#783876: Seriously, these binaries should be stripped by default

Date: Fri, 22 Apr 2016 00:53:50 +0200

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 packages & such is not very difficult.
It's a matter of changing the sbuild behavior for buildd chroots.

Samuel

Message #128 received at 783876@bugs.debian.org (full text, mbox, reply):

From: Santiago Vila <sanvila@unex.es>

To: Matthias Klose <doko@debian.org>

Cc: 783876@bugs.debian.org

Subject: Re: Bug#783876: gcc-5: consider stripping lto1 / cc1 / cc1plus

Date: Fri, 22 Apr 2016 00:55:54 +0200

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
> >course this is absolutely minor compared with the huge gcc binaries.
> 
> this is off topic, however I think this base-files change is rather serious,
> because it lies about the status of sid/unstable.  From my point of view
> such a change of base-files should go to testing directly.

During the freeze, the release managers usually request that all fixes
are handled via unstable, so the policy that testing and unstable are
sides of the same coin is still in effect.

Also, during the freeze we should worry about the stable distribution
we are about to release, not about /etc/debian_version telling or not
telling the "truth" in unstable. That's a completely minor thing.

Once that you realize that unstable is just a staging area for
testing, whatever thing that may happen in unstable and only in
unstable becomes irrelevant.


Speaking of testing/unstable: If it were possible for you to
ship stripped gcc binaries in testing (but not in unstable),
would you do it?

Thanks.

Message #133 received at 783876@bugs.debian.org (full text, mbox, reply):

From: Matthias Klose <doko@debian.org>

To: Santiago Vila <sanvila@unex.es>, 783876@bugs.debian.org

Subject: Re: Bug#783876: gcc-5: consider stripping lto1 / cc1 / cc1plus

Date: Fri, 22 Apr 2016 01:55:24 +0200

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 breaks such expectation too, but of
>>> course this is absolutely minor compared with the huge gcc binaries.
>>
>> this is off topic, however I think this base-files change is rather serious,
>> because it lies about the status of sid/unstable.  From my point of view
>> such a change of base-files should go to testing directly.
>
> During the freeze, the release managers usually request that all fixes
> are handled via unstable, so the policy that testing and unstable are
> sides of the same coin is still in effect.
>
> Also, during the freeze we should worry about the stable distribution
> we are about to release, not about /etc/debian_version telling or not
> telling the "truth" in unstable. That's a completely minor thing.

I disagree about that.  packages uploaded to unstable not ready for testing (and 
not disturbing the release process) should be able to build.

> Once that you realize that unstable is just a staging area for
> testing, whatever thing that may happen in unstable and only in
> unstable becomes irrelevant.
>
>
> Speaking of testing/unstable: If it were possible for you to
> ship stripped gcc binaries in testing (but not in unstable),
> would you do it?

sure, but it depends on base-files/lsb. I probably won't do that myself, but I'm 
open for patches to get these done with binNMUs.

Matthias

Message #138 received at 783876@bugs.debian.org (full text, mbox, reply):

From: Steve McIntyre <steve@einval.com>

To: Matthias Klose <doko@debian.org>

Cc: 783876@bugs.debian.org, debian-devel@lists.debian.org, Ondřej Surý <ondrej@sury.org>

Subject: Re: Bug#783876: Seriously, these binaries should be stripped by default

Date: Fri, 22 Apr 2016 01:02:10 +0100

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.

-- 
Steve McIntyre, Cambridge, UK.                                steve@einval.com
"This dress doesn't reverse." -- Alden Spiess

Message #143 received at 783876@bugs.debian.org (full text, mbox, reply):

From: Basile Starynkevitch <basile@starynkevitch.net>

To: Santiago Vila <sanvila@unex.es>, 783876@bugs.debian.org

Subject: Re: Bug#783876: gcc-5: consider stripping lto1 / cc1 / cc1plus

Date: Fri, 22 Apr 2016 07:41:23 +0200

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 about 130MB.
>>>
>>> Please, can those files be striped in the default installation?
>> I'd like to avoid this, and only change that near the next Debian release.

Notice that stripping cc1/cc1plus/lto1 is prohibiting the ability of 
using GCC plugins. So I believe it should not done, or at least by 
providing alternate packages like gcc-5-stripped and keeping the 
gcc-5-plugin-dev package depending on unstripped cc1plus.

Cheers.


-- 
Basile STARYNKEVITCH         http://starynkevitch.net/Basile/
email: basile<at>starynkevitch<dot>net mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mine, sont seulement les miennes} ***

Message #148 received at 783876@bugs.debian.org (full text, mbox, reply):

From: Basile Starynkevitch <basile@starynkevitch.net>

To: 783876@bugs.debian.org

Subject: Fwd: Re: Bug#783876: gcc-5: consider stripping lto1 / cc1 / cc1plus

Date: Fri, 22 Apr 2016 08:04:18 +0200

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 about 130MB.
>>>
>>> Please, can those files be striped in the default installation?
>> I'd like to avoid this, and only change that near the next Debian release.

Notice that stripping cc1/cc1plus/lto1 is prohibiting the ability of
using GCC plugins. So I believe it should not done, or at least by
providing alternate packages like gcc-5-stripped and keeping the
gcc-5-plugin-dev package depending on unstripped cc1plus (so keep gcc-5 and g++-5 providing unstripped binaries)

Cheers.


-- 
Basile STARYNKEVITCH         http://starynkevitch.net/Basile/
email: basile<at>starynkevitch<dot>net mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mine, sont seulement les miennes} ***

Message #153 received at 783876@bugs.debian.org (full text, mbox, reply):

From: Santiago Vila <sanvila@unex.es>

To: Matthias Klose <doko@debian.org>

Cc: 783876@bugs.debian.org

Subject: Re: Bug#783876: gcc-5: consider stripping lto1 / cc1 / cc1plus

Date: Thu, 4 Aug 2016 11:24:18 +0200 (CEST)

Hello Matthias.

With GCC 6 as the default, the size of a minimal build system has grown
by about 150 MB.

In particular, the size of "lto1" went from 20 MB to 144 MB.
Is this really normal/expected?

While we are at it, this bug is marked as "forwarded". Are there any
news from the upstream maintainers?

Thanks.

Message #158 received at 783876@bugs.debian.org (full text, mbox, reply):

From: Santiago Vila <sanvila@unex.es>

To: Matthias Klose <doko@debian.org>

Cc: 783876@bugs.debian.org

Subject: Re: Bug#783876: gcc-5: consider stripping lto1 / cc1 / cc1plus

Date: Thu, 4 Aug 2016 11:30:49 +0200 (CEST)

On Thu, 4 Aug 2016, Santiago Vila wrote:

> In particular, the size of "lto1" went from 20 MB to 144 MB.
> Is this really normal/expected?

Hmm, lto1 was stripped in GCC 5 (stretch) and now it's unstripped again
(sid, GCC 6). Is this intended or accidental?

Thanks.

Message #163 received at 783876@bugs.debian.org (full text, mbox, reply):

From: anosob@rambler.ru

To: 783876@bugs.debian.org

Subject: Notification status of your delivery (UPS 3660769)

Date: Tue, 21 Feb 2017 00:42:43 +0300

[Message part 1 (text/plain, inline)]

Dear Customer,

Your item has arrived at the UPS Post Office at February 17, but the courier was unable to deliver parcel to you.

Please check the attachment for complete details!

Thank you for your time,
Joel Chase,
UPS Support Manager.

[UPS-Label-3660769.zip (application/zip, attachment)]

Send a report that this bug log contains spam.