Bug#91815: Patch to add memusage and memusagestat

[Stephen Kitt]

Hi Helmut,

On Wed, 8 Jul 2020 18:49:42 +0200, Helmut Grohne  wrote:
[...]
> > diff --git a/debian/control.in/main b/debian/control.in/main
> > index 659267bd..c513a01a 100644
> > --- a/debian/control.in/main
> > +++ b/debian/control.in/main
> > @@ -12,7 +12,8 @@ Build-Depends: gettext, dpkg (>= 1.18.7), dpkg-dev (>=
> > 1.17.14), xz-utils, file, g++-9, g++-9-multilib [amd64 i386
> > kfreebsd-amd64 mips mipsel mipsn32 mipsn32el mips64 mips64el mipsr6
> > mipsr6el mipsn32r6 mipsn32r6el mips64r6 mips64r6el powerpc ppc64 s390x
> > sparc sparc64 x32] , python3:native, libidn2-0 (>= 2.0.5~)
> > ,
> > - libc-bin (>= @GLIBC_VERSION@) 
> > + libc-bin (>= @GLIBC_VERSION@) ,
> > + libgd-dev
> 
> I suggest adding a trailing comma to make the diff for the next change
> smaller.
> 
> >  Build-Depends-Indep: perl, po-debconf (>= 1.0)
> >  Maintainer: GNU Libc Maintainers 
> >  Uploaders: Clint Adams , Aurelien Jarno
> > , Adam Conrad , Samuel Thibault
> >  @@ -47,11 +48,31 @@ Section: libdevel Priority:
> > optional Multi-Arch: foreign
> >  Depends: ${shlibs:Depends}, ${misc:Depends}
> > -Recommends: manpages, manpages-dev
> > +Recommends: libc-devtools (>> @GLIBC_VERSION@)
> >  Build-Profiles: 
> >  Description: GNU C Library: Development binaries
> >   This package contains utility programs related to the GNU C Library
> >   development package.
> > + .
> > +  * gencat: generate message catalogs
> > +  * rpcgen: compile RPC protocols to C
> > +
> > +Package: libc-devtools
> > +Architecture: any
> > +Section: devel
> > +Priority: optional
> > +Multi-Arch: foreign  
> 
> I doubt that memusage is eligible for Multi-Arch: foreign.
> 
> > +Depends: ${shlibs:Depends}, ${misc:Depends}
> > +Recommends: manpages, manpages-dev
> > +Build-Profiles:
> 
> You need Breaks + Replaces here. With the current patch, piuparts should
> be unhappy.

Thanks for the careful review, I’ve fixed all the above in the attached patch
(using ${binary:Version} for Breaks/Replaces for now).

Regards,

Stephen
From c0322308d2be0a5e54fa39ae1437f0fad7901540 Mon Sep 17 00:00:00 2001
From: Stephen Kitt 
Date: Tue, 21 Apr 2020 20:55:53 +0200
Subject: [PATCH] Build and package memusage*

This builds memusage and memusagestat in the libc pass, and ships them
in a new package, libc-devtools (short for "libc-provided developer
tools", and not libc-dev-tools to avoid making it seem to
closely-related to libc-dev-bin). This involves adding a
build-dependency on libgd-dev (outside stage1 and stage2). Other tools
which are not used to build *with* libc, but useful for development in
general, are moved to libc-devtools: mtrace, sotruss, sprof.

libc-dev-bin recommends libc-devtools to provide a simple
transition (see #91815 for the discussion).

Closes: #91815
Signed-off-by: Stephen Kitt 
---
 debian/control.in/main| 27 +--
 debian/debhelper.in/libc-dev-bin.install  |  3 ---
 debian/debhelper.in/libc-dev-bin.manpages |  1 -
 debian/debhelper.in/libc-devtools.install |  5 
 ...rrides => libc-devtools.lintian-overrides} |  2 ++
 debian/debhelper.in/libc-devtools.manpages|  1 +
 debian/rules  |  3 +++
 debian/rules.d/build.mk   |  8 ++
 8 files changed, 44 insertions(+), 6 deletions(-)
 create mode 100644 debian/debhelper.in/libc-devtools.install
 rename debian/debhelper.in/{libc-dev-bin.lintian-overrides => libc-devtools.lintian-overrides} (58%)
 create mode 100644 debian/debhelper.in/libc-devtools.manpages

diff --git a/debian/control.in/main b/debian/control.in/main
index 659267bd..2a2fb5a8 100644
--- a/debian/control.in/main
+++ b/debian/control.in/main
@@ -12,7 +12,8 @@ Build-Depends: gettext, dpkg (>= 1.18.7), dpkg-dev (>= 1.17.14), xz-utils, file,
  g++-9, g++-9-multilib [amd64 i386 kfreebsd-amd64 mips mipsel mipsn32 mipsn32el mips64 mips64el mipsr6 mipsr6el mipsn32r6 mipsn32r6el mips64r6 mips64r6el powerpc ppc64 s390x sparc sparc64 x32] ,
  python3:native,
  libidn2-0 (>= 2.0.5~) ,
- libc-bin (>= @GLIBC_VERSION@) 
+ libc-bin (>= @GLIBC_VERSION@) ,
+ libgd-dev  ,
 Build-Depends-Indep: perl, po-debconf (>= 1.0)
 Maintainer: GNU Libc Maintainers 
 Uploaders: Clint Adams , Aurelien Jarno , Adam Conrad , Samuel Thibault 
@@ -47,11 +48,33 @@ Section: libdevel
 Priority: optional
 Multi-Arch: foreign
 Depends: ${shlibs:Depends}, ${misc:Depends}
-Recommends: manpages, manpages-dev
+Recommends: libc-devtools (>> @GLIBC_VERSION@)
 Build-Profiles: 
 Description: GNU C Library: Development binaries
  This package contains utility programs related to the GNU C Library
  development package.
+ .
+  * gencat: generate message catalogs
+  * rpcgen: compile RPC protocols to C
+
+Package: libc-devtools
+Architecture: any
+Section: devel
+Priority: optional
+Multi-Arch: no
+Depends: ${shlibs:Depends}, ${misc:Depends}
+Breaks: libc-dev-bin (<< ${binary:Version})
+Replaces: libc-dev-bin (<< ${binary:Version})
+Recommends: manpages, manpages-dev

Arch qualification for buster: call for DSA, Security, toolchain concerns

[Paul Gevers]

Hi,

[Note, this e-mail may look familiar as it is mostly copied over from
the buster call, not much has changed, AFAICT].

As part of the interim architecture qualification for bullseye, we
request that DSA, the security team, Wanna build, and the toolchain
maintainers review and update their list of known concerns for bullseye
release architectures.

Summary of the current concerns and issues:
 * DSA have announced a blocking issue for armel and armhf (see below)
 * Concerns from DSA about ppc64el and s390x have been carried over from
   (stretch and) buster.
 * Concerns from the GCC maintainers about i386, armel, armhf, mips64el
   and mipsel have been carried over from (stretch and) buster.

If the issues and concerns from you or your team are not up to date,
then please follow up to this email (keeping debian-release@l.d.o in CC
to ensure we are notified).

Whilst porters remain ultimately responsible for ensuring the
architectures are ready for release, we do expect that you / your team
are willing to assist with clarifications of the concerns and to apply
patches/changes in a timely manner to resolve the concerns.


List of blocking issues by architecture
===

The following is a summary from the current architecture qualification
table.

armel/armhf:


 * Undesirable to keep the hardware running beyond 2020.  armhf VM
   support uncertain. (DSA)
   - Source: [DSA Sprint report]
   - I was under the impression that this issue has been resolved (at
 least for armhf) by now, but we like a fresh statement on this.


[DSA Sprint report]:
https://lists.debian.org/debian-project/2018/02/msg4.html


List of concerns for architectures
==

The following is a summary from the current architecture qualification
table.

 * Concern for ppc64el and s390x: we are dependent on sponsors for
   hardware.
   (Raised by DSA; carried over from stretch and buster)

 * Concern for armel and armhf: only secondary upstream support in GCC
   (Raised by the GCC maintainer; carried over from stretch and buster)

 * Concern for mips, mips64el, mipsel and ppc64el: no upstream support
   in GCC; Debian carries patches in binutils and GCC that haven't been
   integrated upstream even after a long time.
   (Raised by the GCC maintainer; carried over from stretch and buster)


Architecture status
===

These are the architectures currently being built for bullseye:

 * Intel/AMD-based: amd64, i386
 * ARM-based: arm64, armel, armhf
 * MIPS-based: mipsel, mips64el
 * Other: ppc64el, s390x

If the blocking issues cannot be resolved, affected architectures are at
risk of removal from testing before bullseye is frozen.

We are currently unaware of any new architectures likely to be ready in
time for inclusion in bullseye.

On behalf of the release team,
Paul Gevers



signature.asc
Description: OpenPGP digital signature

Bug#91815: Patch to add memusage and memusagestat

[Helmut Grohne]

Hi Stephen,

On Wed, Jul 08, 2020 at 05:38:46PM +0200, Stephen Kitt wrote:
> I don’t mind, it’s not as if this is an urgent bug ;-).

Thank you for your patience and work on this.

> I went for libc-devtools to avoid making it too closely-tied to libc-dev-bin,
> on purpose; it’s not only useful for people needing libc-dev.

Sounds good to me.

> I’ve implemented this, see the attached patch. I’m not sure the upgrade
> scenario is ideal though: recommends are ignored on upgrades. This means
> that, if libc-dev-bin recommends libc-devtools, upgrades won’t install the
> latter, but new installations of libc-dev-bin will.

There is little to add here.

> Pushing memusage* to a separate package would result in that being installed
> on upgrade: libc-dev-bin would depend on libc-devtools (following the
> transition rules strictly), so that would get pulled in automatically on
> upgrade, and since it’s a new package, it would count as installation, and
> thus pull in its recommendations.

I don't have an opinion on this and leave it to the glibc maintainers.

> diff --git a/debian/control.in/main b/debian/control.in/main
> index 659267bd..c513a01a 100644
> --- a/debian/control.in/main
> +++ b/debian/control.in/main
> @@ -12,7 +12,8 @@ Build-Depends: gettext, dpkg (>= 1.18.7), dpkg-dev (>= 
> 1.17.14), xz-utils, file,
>   g++-9, g++-9-multilib [amd64 i386 kfreebsd-amd64 mips mipsel mipsn32 
> mipsn32el mips64 mips64el mipsr6 mipsr6el mipsn32r6 mipsn32r6el mips64r6 
> mips64r6el powerpc ppc64 s390x sparc sparc64 x32] ,
>   python3:native,
>   libidn2-0 (>= 2.0.5~) ,
> - libc-bin (>= @GLIBC_VERSION@) 
> + libc-bin (>= @GLIBC_VERSION@) ,
> + libgd-dev  

I suggest adding a trailing comma to make the diff for the next change
smaller.

>  Build-Depends-Indep: perl, po-debconf (>= 1.0)
>  Maintainer: GNU Libc Maintainers 
>  Uploaders: Clint Adams , Aurelien Jarno 
> , Adam Conrad , Samuel Thibault 
> 
> @@ -47,11 +48,31 @@ Section: libdevel
>  Priority: optional
>  Multi-Arch: foreign
>  Depends: ${shlibs:Depends}, ${misc:Depends}
> -Recommends: manpages, manpages-dev
> +Recommends: libc-devtools (>> @GLIBC_VERSION@)
>  Build-Profiles: 
>  Description: GNU C Library: Development binaries
>   This package contains utility programs related to the GNU C Library
>   development package.
> + .
> +  * gencat: generate message catalogs
> +  * rpcgen: compile RPC protocols to C
> +
> +Package: libc-devtools
> +Architecture: any
> +Section: devel
> +Priority: optional
> +Multi-Arch: foreign

I doubt that memusage is eligible for Multi-Arch: foreign.

> +Depends: ${shlibs:Depends}, ${misc:Depends}
> +Recommends: manpages, manpages-dev
> +Build-Profiles:  

You need Breaks + Replaces here. With the current patch, piuparts should
be unhappy.

> +Description: GNU C Library: Development tools
> + This package contains development tools shipped by the GNU C
> + Library.
> + .
> +  * memusage, memusagestat: profile a program's memory usage
> +  * mtrace: interpret the malloc trace log
> +  * sotruss: trace shared library calls
> +  * sprof: display shared object profiling data
>  
>  Package: libc-l10n
>  Architecture: all
> diff --git a/debian/debhelper.in/libc-dev-bin.install 
> b/debian/debhelper.in/libc-dev-bin.install
> index 0d760a7e..902029b5 100644
> --- a/debian/debhelper.in/libc-dev-bin.install
> +++ b/debian/debhelper.in/libc-dev-bin.install
> @@ -1,5 +1,2 @@
>  debian/tmp-libc/usr/bin/gencat usr/bin
> -debian/tmp-libc/usr/bin/mtrace usr/bin
>  debian/tmp-libc/usr/bin/rpcgen usr/bin
> -debian/tmp-libc/usr/bin/sotruss usr/bin
> -debian/tmp-libc/usr/bin/sprof usr/bin
> diff --git a/debian/debhelper.in/libc-dev-bin.manpages 
> b/debian/debhelper.in/libc-dev-bin.manpages
> index c33123a0..576ec52c 100644
> --- a/debian/debhelper.in/libc-dev-bin.manpages
> +++ b/debian/debhelper.in/libc-dev-bin.manpages
> @@ -1,3 +1,2 @@
>  debian/local/manpages/gencat.1
>  debian/local/manpages/rpcgen.1 
> -debian/local/manpages/sotruss.1
> diff --git a/debian/debhelper.in/libc-devtools.install 
> b/debian/debhelper.in/libc-devtools.install
> new file mode 100644
> index ..7a0024da
> --- /dev/null
> +++ b/debian/debhelper.in/libc-devtools.install
> @@ -0,0 +1,5 @@
> +debian/tmp-libc/usr/bin/memusage usr/bin
> +debian/tmp-libc/usr/bin/memusagestat usr/bin
> +debian/tmp-libc/usr/bin/mtrace usr/bin
> +debian/tmp-libc/usr/bin/sotruss usr/bin
> +debian/tmp-libc/usr/bin/sprof usr/bin
> diff --git a/debian/debhelper.in/libc-dev-bin.lintian-overrides 
> b/debian/debhelper.in/libc-devtools.lintian-overrides
> similarity index 58%
> rename from debian/debhelper.in/libc-dev-bin.lintian-overrides
> rename to debian/debhelper.in/libc-devtools.lintian-overrides
> index eedd7cbd..1031449a 100644
> --- a/debian/debhelper.in/libc-dev-bin.lintian-overrides
> +++ b/debian/debhelper.in/libc-devtools.lintian-overrides
> @@ -1,3 +1,5 @@
>  # these manpages are provided by the manpages package
> +libc-dev-bin: binary-without-manpage usr/bin/memusage
> 

Bug#91815: Patch to add memusage and memusagestat

[Stephen Kitt]

Hi,

On Sat, 16 May 2020 13:35:02 +0200, Aurelien Jarno  wrote:
> On 2020-05-09 12:27, Helmut Grohne wrote:
> > Thank you for not dropping the ball after my initial "it's not that
> > easy" reply.
> > 
> > On Sat, May 09, 2020 at 10:53:10AM +0200, Stephen Kitt wrote:  
> > > There’s another part of the transition which bothers me: if we add
> > > memusage to a package which is depended upon (albeit temporarily) by
> > > libc-dev-bin, it becomes part of build-essential, and adding memusage
> > > means adding libgd3, libfontconfig1, libfreetype6, etc. to all builds...
> > > 
> > > It occurred to me that there is however a way to add memusage while
> > > transitioning cleanly, over a few years. It seems to me that the
> > > binaries in libc-dev-bin can be split into two categories: binaries
> > > that are expected as build tools (gencat and rpcgen), and binaries that
> > > are useful as tools for understanding programs but not building them
> > > (memusage, memusagestat, mtrace, sotruss, sprof). How about the
> > > following?
> > > 
> > > * We add a new package, say libc-devtools, containing the second type of
> > >   tools (mtrace, sotruss, sprof). For transition purposes, libc-dev-bin
> > >   depends on that in Bullseye.
> > > * We add another package, memusage, containing memusage and
> > > memusagestat. That’s the package which ends up with all the annoying
> > > extra dependencies, but nothing depends on it.
> > > * In Bookworm, libc-dev-bin can drop the dependency on libc-devtools,
> > > and we can merge memusage into libc-devtools.
> > > 
> > > Does that make sense?  
> 
> Yes, with the points raised by Helmut, I think it makes sense.
> Unfortunately many changes in glibc requires transitions lasting many
> years...

I don’t mind, it’s not as if this is an urgent bug ;-).

> I just wonder if we should call it libc-devtools or libc-dev-tools to
> match the pattern from libc-dev-bin. But that's a minor detail over the
> whole plan.

I went for libc-devtools to avoid making it too closely-tied to libc-dev-bin,
on purpose; it’s not only useful for people needing libc-dev.

> > All of what you write here makes very much sense to me and the
> > trade-offs seem good to me. What you propose will result in making the
> > bootstrapping/profile stuff simpler/better. That said, I am not a glibc
> > maintainer. I don't see the full picture.
> > 
> > I have two minor remarks:
> >  * Should libc-devtools maybe recommend memusage already?  
> 
> It's something we can do, I think it mostly depends if we basically want
> libc-dev-bin to recommends memusage.
> 
> >  * We cannot simply have libc-devtools absorb memusage in bookworm.
> >Doing so would break upgrades when someone has memusage, but not
> >libc-devtools installed. Therefore memusage likely needs to be a
> >transitional dummy package in bookworm and can only be removed one
> >release later. I'm wondering whether this could be avoided if we had
> >memusage depend on libc-devtools.  
> 
> I agree with that.
> 
> > Neither of these touch the core of your thoughts.  
> 
> Another faster alternative that came to my mind is to rely n the fact
> that recommends are enabled by default, but not used to resolve
> build-dependencies. In that case we can already create libc-devtools
> with memstatusage and also move mtrace, sotruss, sprof there. Those 3
> binaries are very unlikely to be used to build packages, so I don't
> expect breakages. From the user point of view, it's just like if (part
> of) a dependency has been demoted to a recommends. It's something that
> is often done for other packages, and it seems we accept that even if it
> causes breakages (latest example that comes to my mind is util-linux
> dropping the dependency on fdisk). I guess adding an entry in NEWS would
> be necessary though.

I’ve implemented this, see the attached patch. I’m not sure the upgrade
scenario is ideal though: recommends are ignored on upgrades. This means
that, if libc-dev-bin recommends libc-devtools, upgrades won’t install the
latter, but new installations of libc-dev-bin will.

Pushing memusage* to a separate package would result in that being installed
on upgrade: libc-dev-bin would depend on libc-devtools (following the
transition rules strictly), so that would get pulled in automatically on
upgrade, and since it’s a new package, it would count as installation, and
thus pull in its recommendations.

> I don't know if it's something that's acceptable. What do you think?
> Maybe we should ask the release team?

That would be useful! I need to check the upgrades scenarios again, I’ll
reach out to them in a couple of weeks’ time, unless you want to do it
directly.

Regards,

Stephen
From 95f482efe7c2ae6d9a87d0a47cd5619cb26a4f55 Mon Sep 17 00:00:00 2001
From: Stephen Kitt 
Date: Tue, 21 Apr 2020 20:55:53 +0200
Subject: [PATCH] Build and package memusage*

This builds memusage and memusagestat in the libc pass, and ships them
in a new package, libc-devtools 

✍ Voordeeldagen -10% extra vanaf nu met ons huismerk of Xerox-XRC.

[Inktbestellen.be | Doe er uw voordeel mee.]

Geniet nu van een extra voordeel van 10% op ons kwalitatief huismerk.

Open deze mail in uw browser


In juli willen we u 10% extra voordeel bieden op onze huismerken.
Beste Rossignol M-R,
Voor iedereen die vanaf vandaag tot en met 31 juli 2020 een order plaatst
voor producten uit ons Huismerk-gamma of Xerox-gamma krijgt nog een extra
korting van 10%.
Allen samen kunnen we het coronavirus overwinnen en steunt u ook nog
#KoopLokaalOnline

Belangrijk! De enige voorwaarde is dat de bestelling producten bevat uit
ons gamma "Huismerk" en/of "Xerox-XRC" en dan wordt de korting automatisch
toegepast bij het afrekenen.
Deze promotie is geldig tot en met 31 Juli 2020
Met vriendelijke groeten
Sarah van Inktbestellen.be
U zoekt inkt

U zoekt toners

Bestellen kan u 24/7, maar bestelt u voor 17 uur dan worden deze de
volgende dag reeds bij U geleverd door BPost (voor 90% van de leveringen –
op werkdagen).



Dit is een commeriële mail, wenst u verder geen informatie meer te
ontvangen,

click hier

© 2017 INKTBESTELLEN.BE | Kwatrechtsesteenweg 111 | 9230 - WETTEREN