Bug#91815: Patch to add memusage and memusagestat
Hi Aurelien and Stephen, On Mon, May 04, 2020 at 12:00:28AM +0200, Aurelien Jarno wrote: > It's something we can fix. I found strange nobody notice so far. Does it > mean the bootstrap is done ignoring the build-dependencies? Yes, I still ignore build-depends entirely. glibc depends on a specific version of the compiler and such dependencies are not compatible with cross compilation until we fix #666743 aka gcc-for-host. That bug has a patch, but nobody wants to review it and communication isn't working best on the issue either. If you really want to make a dent now, you need to do like src:linux does: Build-Depends: g++-9 , g++-9-aarch64-linux-gnu [arm64] , g++-9-arm-linux-gnueabi [armel] , ... Do you want that? Doing so still means me hacking up the package during bootstrap, because I always force the compiler version regardless of whether glibc supports that. > Thanks for the detailed explanations. It looks to me that it's better to > add a different package. And while mtrace looks a good candidate to join > this package, I am not sure we can handle the transition easily. It > would mean that libc6-dev-bin need to depends on that new package at > least for one release cycle. And we actually don't want that for stage > 2, which means producing different packages for stage2... Let me point out that a transitional dependency is not a huge cost to reproducibility. Making the dependency optional to stage2 is reasonable. libc packages are not yet reproducible across stages. That's more of a vision. In diffoscope, such a dependency difference is very light. I agree with everything else you said around moving mtrace though. So judge it on its own knowing that it won't negatively impact bootstrap. When thinking about bootstrap, it helps to always think of any kind of transition as atomic (i.e. completed once started). It might be temporarily broken, but since you always rebuild everything from source, you can simply fix up anyth broken rdeps immediately. Helmut
Bug#958674: glibc: refactor generation of multilib include symlinks
Hi Aurelien, On Sun, May 03, 2020 at 11:32:41PM +0200, Aurelien Jarno wrote: > On the principle I am fine with it, it's a nice cleanup. Now I still > have one comment about it, see below. Thank you for taking the time to review the patch. > > --- glibc-2.30/debian/rules.d/build.mk 2020-03-25 13:36:06.0 > > +0100 > > +++ glibc-2.30/debian/rules.d/build.mk 2020-04-24 08:02:08.0 > > +0200 > > @@ -2,6 +2,16 @@ > > # PASS_VAR, we need to call all variables as $(call xx,VAR) > > # This little bit of magic makes it possible: > > xx=$(if $($(curpass)_$(1)),$($(curpass)_$(1)),$($(1))) > > +define generic_multilib_extra_pkg_install > > +set -e; \ > > +mkdir -p debian/$(1)/usr/include/sys; \ > > +ln -sf $(DEB_HOST_GNU_TYPE)/bits debian/$(1)/usr/include/; \ > > +ln -sf $(DEB_HOST_GNU_TYPE)/gnu debian/$(1)/usr/include/; \ > > +ln -sf $(DEB_HOST_GNU_TYPE)/fpu_control.h debian/$(1)/usr/include/; \ > > +for i in `ls debian/tmp-libc/usr/include/$(DEB_HOST_GNU_TYPE)/sys`; do \ > > + ln -sf ../$(DEB_HOST_GNU_TYPE)/sys/$$i debian/$(1)/usr/include/sys/$$i; > > \ > > DEB_HOST_GNU_TYPE doesn't look correct here. What we want here is the > multiarch path, not the gnu triplet. They are similar on most > architectures, but differ at least on i386. You're right. This should be DEB_HOST_MULTIARCH of course. It's a little embarrassing as I should know better. I've attached a revised version. Is there anything else you object to? Helmut diff --minimal -Nru glibc-2.30/debian/changelog glibc-2.30/debian/changelog --- glibc-2.30/debian/changelog 2020-03-25 13:56:56.0 +0100 +++ glibc-2.30/debian/changelog 2020-04-24 08:02:13.0 +0200 @@ -1,3 +1,10 @@ +glibc (2.30-4.1) UNRELEASED; urgency=medium + + * Non-maintainer upload. + * Refactor generation of multilib include symlinks. (Closes: #-1) + + -- Helmut Grohne Fri, 24 Apr 2020 08:02:13 +0200 + glibc (2.30-4) unstable; urgency=medium [ Aurelien Jarno ] diff --minimal -Nru glibc-2.30/debian/rules.d/build.mk glibc-2.30/debian/rules.d/build.mk --- glibc-2.30/debian/rules.d/build.mk 2020-03-25 13:36:06.0 +0100 +++ glibc-2.30/debian/rules.d/build.mk 2020-04-24 08:02:08.0 +0200 @@ -2,6 +2,16 @@ # PASS_VAR, we need to call all variables as $(call xx,VAR) # This little bit of magic makes it possible: xx=$(if $($(curpass)_$(1)),$($(curpass)_$(1)),$($(1))) +define generic_multilib_extra_pkg_install +set -e; \ +mkdir -p debian/$(1)/usr/include/sys; \ +ln -sf $(DEB_HOST_MULTIARCH)/bits debian/$(1)/usr/include/; \ +ln -sf $(DEB_HOST_MULTIARCH)/gnu debian/$(1)/usr/include/; \ +ln -sf $(DEB_HOST_MULTIARCH)/fpu_control.h debian/$(1)/usr/include/; \ +for i in `ls debian/tmp-libc/usr/include/$(DEB_HOST_MULTIARCH)/sys`; do \ + ln -sf ../$(DEB_HOST_MULTIARCH)/sys/$$i debian/$(1)/usr/include/sys/$$i; \ +done +endef ifneq ($(filter stage1,$(DEB_BUILD_PROFILES)),) libc_extra_config_options = $(extra_config_options) --disable-sanity-checks \ diff --minimal -Nru glibc-2.30/debian/sysdeps/amd64.mk glibc-2.30/debian/sysdeps/amd64.mk --- glibc-2.30/debian/sysdeps/amd64.mk 2020-03-25 13:36:06.0 +0100 +++ glibc-2.30/debian/sysdeps/amd64.mk 2020-04-24 08:02:08.0 +0200 @@ -20,21 +20,13 @@ define libc6-dev-i386_extra_pkg_install -mkdir -p debian/libc6-dev-i386/usr/include -ln -sf x86_64-linux-gnu/bits debian/libc6-dev-i386/usr/include/ -ln -sf x86_64-linux-gnu/gnu debian/libc6-dev-i386/usr/include/ -ln -sf x86_64-linux-gnu/fpu_control.h debian/libc6-dev-i386/usr/include/ +$(call generic_multilib_extra_pkg_install,libc6-dev-i386) mkdir -p debian/libc6-dev-i386/usr/include/x86_64-linux-gnu/gnu cp -a debian/tmp-i386/usr/include/gnu/lib-names-32.h \ debian/tmp-i386/usr/include/gnu/stubs-32.h \ debian/libc6-dev-i386/usr/include/x86_64-linux-gnu/gnu -mkdir -p debian/libc6-dev-i386/usr/include/sys -for i in `ls debian/tmp-libc/usr/include/x86_64-linux-gnu/sys` ; do \ -ln -sf ../x86_64-linux-gnu/sys/$$i debian/libc6-dev-i386/usr/include/sys/$$i ; \ -done - endef define libc6-i386_extra_pkg_install diff --minimal -Nru glibc-2.30/debian/sysdeps/armel.mk glibc-2.30/debian/sysdeps/armel.mk --- glibc-2.30/debian/sysdeps/armel.mk 2020-03-11 22:13:40.0 +0100 +++ glibc-2.30/debian/sysdeps/armel.mk 2020-04-24 08:02:08.0 +0200 @@ -15,21 +15,13 @@ # #define libc6-dev-armhf_extra_pkg_install # -#mkdir -p debian/libc6-dev-armhf/usr/include -#ln -sf arm-linux-gnueabi/bits debian/libc6-dev-armhf/usr/include/ -#ln -sf arm-linux-gnueabi/gnu debian/libc6-dev-armhf/usr/include/ -#ln -sf arm-linux-gnueabi/fpu_control.h debian/libc6-dev-armhf/usr/include/ +#$(call generic_multilib_extra_pkg_install,libc6-dev-armhf) # #mkdir -p debian/libc6-dev-armhf/usr/include/arm-linux-gnueabi/gnu #cp -a debian/tmp-armhf/usr/include/gnu/lib-names-hard.h \ # debian/tmp-armhf/usr/include/gnu/stubs-hard.h \ # debian/libc6-dev-armhf/usr/include/arm-linux-gnueabi/gnu #
Bug#903514: dringende Antwort
Ich habe wichtige Geschäfte mit Ihnen zu besprechen. Antwort für weitere Details. Wang Jianlin -- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus
Processed: Bug#953654 marked as pending in glibc
Processing control commands: > tag -1 pending Bug #953654 [libc6-dbg] libc6-dbg should be renamed (or at least Provide:) libc6-dbgsym Added tag(s) pending. -- 953654: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=953654 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
[Git][glibc-team/glibc][sid] debian/control.in/libc: add a Provides: libc6-dbgsym to the libc6-dbg package. Closes: #953654.
Aurelien Jarno pushed to branch sid at GNU Libc Maintainers / glibc Commits: af69bb20 by Aurelien Jarno at 2020-05-04T00:39:06+02:00 debian/control.in/libc: add a Provides: libc6-dbgsym to the libc6-dbg package. Closes: #953654. - - - - - 3 changed files: - debian/changelog - debian/control - debian/control.in/libc View it on GitLab: https://salsa.debian.org/glibc-team/glibc/-/commit/af69bb201d64791b046d99d542920210ea202b90 -- View it on GitLab: https://salsa.debian.org/glibc-team/glibc/-/commit/af69bb201d64791b046d99d542920210ea202b90 You're receiving this email because of your account on salsa.debian.org.
[Git][glibc-team/glibc][sid] 2 commits: debian/rules.d/debhelper.mk: install the dynamic loader symlink in the udeb package.
Aurelien Jarno pushed to branch sid at GNU Libc Maintainers / glibc Commits: c1f09fc2 by Aurelien Jarno at 2020-05-04T00:30:24+02:00 debian/rules.d/debhelper.mk: install the dynamic loader symlink in the udeb package. - - - - - 716d6054 by Aurelien Jarno at 2020-05-04T00:30:24+02:00 debian/control: conflict against libgcc-X-dev versions that might need the __glibc_has_include macro. * debian/control: conflict against libgcc-X-dev versions that might need the __glibc_has_include macro. * debian/patches/any/local-revert-glibc_has_include.diff: drop patch, obsolete. - - - - - 6 changed files: - debian/changelog - debian/control - debian/control.in/libc - − debian/patches/any/local-revert-glibc_has_include.diff - debian/patches/series - debian/rules.d/debhelper.mk View it on GitLab: https://salsa.debian.org/glibc-team/glibc/-/compare/f91552fbbb8869d81df366a688ed62382b0f09e2...716d60543c444740e8af7ad37ebe3bf10341fd52 -- View it on GitLab: https://salsa.debian.org/glibc-team/glibc/-/compare/f91552fbbb8869d81df366a688ed62382b0f09e2...716d60543c444740e8af7ad37ebe3bf10341fd52 You're receiving this email because of your account on salsa.debian.org.
Bug#91815: Patch to add memusage and memusagestat
Hi, On 2020-04-22 06:53, Helmut Grohne wrote: > Hi Aurelien and Stephen, > > On Wed, Apr 22, 2020 at 12:04:32AM +0200, Aurelien Jarno wrote: > > > The attached patch adds memusage and memusagestat to the libc-bin package. > > > This does mean that the latter becomes dependent on libgd3, so it might be > > > better to add a new memusage package; I can take care of that if the > > > maintainers think it’s better. > > > > I am not sure we want to add a new dependency for libc-bin, I am sure > > people running embedded systems won't appreciate. Any reason for not > > shipping it in libc-dev-bin instead? For me that looks more like a tool > > to be used for "development". At least the memusagestat is similar to > > the mtrace one that is in libc-dev-bin. > > > > We also have to make sure that this new build-dependency doesn't break > > bootstrapping. I have added Helmut in Cc so that he can have a look. > > Thank you for notifying me. Indeed, the patch doesn't work for > bootstrapping as is. A stage2 build of glibc would start requiring > libgd-dev -> libgd3 -> libc6, but the stage1 libc6 will not be > sufficient to build src:libgd2. It must be possible to build stage2 > without that dependency. > > (Note that this is going to become more confusing as there is ongoing > work on removing stage1 and maybe renaming stage2, but let's stick to > the current names for now.) > > >From a bootstrapping pov, the libgd-dev dependency is similar to the > libselinux-dev dependency, but I notice just now that it is not > correctly annotated with in Build-Depends! It's something we can fix. I found strange nobody notice so far. Does it mean the bootstrap is done ignoring the build-dependencies? > >From a build profile pov, it is very undesirable to have package > contents change with profiles. Doing so makes it impossible to validate > them using reproducible builds. However, since we need libc6-dev from > stage2 and it depends on libc-dev-bin we cannot skip generating > libc-dev-bin in stage2. I wonder whether it would make sense to add > another binary package for development tools that are not normally > needed for building software. Then we could skip generating that > package. mtrace would be a good candidate to join that package indeed. Thanks for the detailed explanations. It looks to me that it's better to add a different package. And while mtrace looks a good candidate to join this package, I am not sure we can handle the transition easily. It would mean that libc6-dev-bin need to depends on that new package at least for one release cycle. And we actually don't want that for stage 2, which means producing different packages for stage2... Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://www.aurel32.net
Bug#956418: src:glibc: Please provide optimized builds for ARMv8.1
On 2020-04-21 18:37, Noah Meyerhans wrote: > > To be honest from a glibc maintenance point of view it's something I > > would like to avoid. We haven't been actively trying to remove the > > remaining optimized libraries (on i386, hurd and alpha), but we have > > tried to avoid adding new ones. The problem is not building a second > > optimized glibc, but rather providing a safe upgrade as the optimized > > and the non-optimized package have to be at the same version or one of > > them has to be disabled. This has caused many system breakages overall. > > Understood, that makes sense. I wonder if it's worth it to investigate > techniques to improve the situation around optimized libraries. Do you > have any thoughts on what such an improvement might look like? The hardware capabilities system works fine upstream, but doesn't work for us because: 1) we want to be able to upgrade major upstream version online (as opposed to fedora for example) 2) we ship the optimized libraries in a different package The various libc librairies need to have the same version at any time, this is especially true for ld.so vs libc.so. As we do not upgrade the default libc and the optimized one exactly at the same time (they are in different packages), we upgrade first the default libc and then we have the Debian specific nohwcap mechanism to prevent using the optimize library until it has also been upgraded. One solution for this would be to ship the optimized library in the same package as the default library. Now this is not acceptable for embedded systems as they might not need that library and can't remove it. This is even more problematic if we need to add more optimized libraries. I guess this might be the case for arm64 as there are many new extensions in the pipe. Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://www.aurel32.net
Bug#958674: glibc: refactor generation of multilib include symlinks
Hi, On 2020-04-24 11:24, Helmut Grohne wrote: > Source: glibc > Version: 2.30-4 > Severity: wishlist > Tags: patch > Control: block 798955 by -1 > > Hi Aurelien, > > as you might have noticed, I resumed work on the long-standing multiarch > glibc headers issue. It seems that we're mostly done with prerequisites > now. Most patches with the exception of a qmake one have been filed a > while ago, so it seems like time to move forward a little. > > The resulting patch to glibc is not entirely trivial, so I've tried to > split it into more manageable pieces: > > * This bug: Refactor generation of multilib include symlinks. It is >essentially pulling a pile of duplicated code into a make define. As >such it can be considered a cleanup patch (net -160 lines) and does >not affect resulting packages in an observable way. It is readily >applicable. > > * #798955 will receive an updated patch after applying this one. The >updated patch is much smaller, which makes it easier to review. > > Please don't let this patch sit in the bts for long. Either you like my > approach of splitting the diff and can apply it. Fine. Or you disagree > with it on some level. In that case, I'd like to learn your reason and > have this bug closed and tagged wontfix. On the principle I am fine with it, it's a nice cleanup. Now I still have one comment about it, see below. > diff --minimal -Nru glibc-2.30/debian/changelog glibc-2.30/debian/changelog > --- glibc-2.30/debian/changelog 2020-03-25 13:56:56.0 +0100 > +++ glibc-2.30/debian/changelog 2020-04-24 08:02:13.0 +0200 > @@ -1,3 +1,10 @@ > +glibc (2.30-4.1) UNRELEASED; urgency=medium > + > + * Non-maintainer upload. > + * Refactor generation of multilib include symlinks. (Closes: #-1) > + > + -- Helmut Grohne Fri, 24 Apr 2020 08:02:13 +0200 > + > glibc (2.30-4) unstable; urgency=medium > >[ Aurelien Jarno ] > diff --minimal -Nru glibc-2.30/debian/rules.d/build.mk > glibc-2.30/debian/rules.d/build.mk > --- glibc-2.30/debian/rules.d/build.mk2020-03-25 13:36:06.0 > +0100 > +++ glibc-2.30/debian/rules.d/build.mk2020-04-24 08:02:08.0 > +0200 > @@ -2,6 +2,16 @@ > # PASS_VAR, we need to call all variables as $(call xx,VAR) > # This little bit of magic makes it possible: > xx=$(if $($(curpass)_$(1)),$($(curpass)_$(1)),$($(1))) > +define generic_multilib_extra_pkg_install > +set -e; \ > +mkdir -p debian/$(1)/usr/include/sys; \ > +ln -sf $(DEB_HOST_GNU_TYPE)/bits debian/$(1)/usr/include/; \ > +ln -sf $(DEB_HOST_GNU_TYPE)/gnu debian/$(1)/usr/include/; \ > +ln -sf $(DEB_HOST_GNU_TYPE)/fpu_control.h debian/$(1)/usr/include/; \ > +for i in `ls debian/tmp-libc/usr/include/$(DEB_HOST_GNU_TYPE)/sys`; do \ > + ln -sf ../$(DEB_HOST_GNU_TYPE)/sys/$$i debian/$(1)/usr/include/sys/$$i; > \ DEB_HOST_GNU_TYPE doesn't look correct here. What we want here is the multiarch path, not the gnu triplet. They are similar on most architectures, but differ at least on i386. Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://www.aurel32.net
