Re: ARC rebootstrap prereq (was Re: switching ARC to 64-bit time_t )

2020-08-26 Thread Helmut Grohne
Hi Vineet,

On Wed, Aug 26, 2020 at 02:39:53PM +, Vineet Gupta wrote:
> Following up as ARC glibc port was merged upstream in 2.32. Can we now give
> rebootstrap a spin for ARC Debian enablement.

That's great news. Unfortunately, it's not that easy yet. rebootstrap
requires the relevant software to be packaged for Debian and the glibc
packaging has only reached 2.31 yet. 2.32 is not even in experimental
yet.

Trying rebootstrap with an experimental glibc is not entirely trivial,
but possible.

Aurelien (Cced via d-glibc@l.d.o), are there plans to upload 2.32 to
experimental anytime soon?

Alternatively, can we segregate the relevant diff between 2.31 and 2.32
and apply it to the unstable package without bumping the version?

Helmut



Bug#91815: Patch to add memusage and memusagestat

2020-07-08 Thread 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

2020-05-09 Thread Helmut Grohne
Hi Stephen,

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?

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?
 * 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.

Neither of these touch the core of your thoughts.

I'm happy to review patches to make this happen. Please continue to Cc
me if you want my review.

Helmut



Bug#91815: Patch to add memusage and memusagestat

2020-05-03 Thread Helmut Grohne
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

2020-05-03 Thread Helmut Grohne
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 \

Bug#958674: glibc: refactor generation of multilib include symlinks

2020-04-24 Thread Helmut Grohne
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.

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_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; 
\
+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
 #
-#mkdir -p debian/libc6-dev-armhf/usr/include/sys
-#for i in `ls debian/tmp-libc/usr/include/arm-linux-gnueabi/sys` ; do \
-#  ln -sf ../arm-linux-gnueabi/sys/$$i 
debian/libc6-dev-armhf/usr/include/sys/$$i ; \
-#done
-#
 #endef
 #
 #define libc6-armhf_extra_pkg_install
diff --minimal

Bug#798955: [PATCH] libstdc++: don't use #include_next in c_global headers

2020-04-22 Thread Helmut Grohne
Hi,

On Mon, Apr 20, 2020 at 10:12:37AM +0100, Jonathan Wakely wrote:
> > Now you are probably going to say that "-isystem /usr/include" is a bad
> > idea and that you shouldn't do that.
> 
> Right.
> 
> > I'm inclined to agree. This isn't a
> > problem just yet. Debian wants to move /usr/include/stdlib.h to
> > /usr/include//stdlib.h. After that move, the problematic flag
> > becomes "-isystem /usr/include/". Unfortunately, around 30
> > Debian packages[1] do pass exactly that flag. Regardless whether doing
> > so is a bad idea, I guess we will have to support that.
> 
> Or Debian should fix what they're going to break.

This is not quite precise. The offending -isystem
/usr/include/ flag is already being passed. According to what
you write later, doing so is broken today. It just happens to work by
accident. So all we do is making the present breakage visible.

> > I am proposing to replace those two #include_next with plain #include.
> > That'll solve the problem described above, but it is not entirely
> > obvious that doing so doesn't break something else.
> > 
> > After switching those #include_next to #include,
> > libstdc++-v3/include/c_global/cstdlib will continue to temporarily
> > will #include . Now, it'll search all include directories. It
> > may find libstdc++-v3/include/c_comaptibility/stdlib.h or the libc's
> > version. We cannot tell which. If it finds the one from libstdc++-v3,
> > the header will notice the _GLIBCXX_INCLUDE_NEXT_C_HEADERS macro and
> > immediately #include_next  skipping the rest of the header.
> > That in turn will find the libc version. So in both cases, it ends up
> > using the right one. Precisely what we wanted.
> 
> As Marc said, this doesn't work.

That is not very precise either. Marc said that it won't fix all cases.
In practice, it would make those work that don't #include  but
use #include  instead.

Marc also indicated that using include_next for a header of a different
name is wrong. So this is a bug in libstdc++ regardless of whether it
breaks or unbreaks other pieces of software.

> If a program tries to include  it needs to get the libstdc++
> version, otherwise only the libc versions of certain functions are
> defined. That means the additional C++ overloads such as ::abs(long)
> and ::abs(long long) won't be defined. That is the reason why
> libstdc++ provides its own .
> 
> And if you do -isystem /usr/include (or any other option that causes
> libstdc++'s  to be skipped) that doesn't work. Only
> ::abs(int) gets defined.
> 
> So -isystem /usr/include breaks code, with or without your patch.

It is very difficult to disagree with -isystem /usr/include or -isystem
/usr/include/ being broken and unsupported. Having you state it
that clearly does help with communicating to other upstreams. For this
reason, I've looked into the remaining cases. It turns out that there
aren't that many left. In particular chromium, opencv and vtk got fixed
in the mean time. Basically all remaining failures could be attributed
to qmake, which passes all directories below /usr/include (including
/usr/include and /usr/include/ if a .pc file mentions them)
using -isystem. I've sent a patch https://bugs.debian.org/958479 to make
qmake stop doing that.

I therefore agree with you that the patch I sent for libstdc++ is not
necessary to make packages build on Debian. Removing the offending
-isystem flags from the respective builds is a manageable option and has
already happened to a large extend.

We can conclude that the motivation for my patch is not a good one,
because it embraces broken behaviour. However, the use of include_next
remains a bug, because the name of the including and the name of the
included header differ, and it should be fixed on that ground.

Helmut



Bug#91815: Patch to add memusage and memusagestat

2020-04-22 Thread Helmut Grohne
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!

>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.

Failing that, we'll have to cope with changing package contents for
stage2 and disable the new dependency for stage2 (or some other
profile).

Helmut



Bug#798955: [PATCH] libstdc++: don't use #include_next in c_global headers

2020-04-19 Thread Helmut Grohne
The  and  headers need their counter parts  and
 from the libc respectively, but libstdc++ wraps these
headers. Now  and  include these headers using

$ echo '#include ' | g++ -x c++ -E - -isystem /usr/include >/dev/null
In file included from :1:
/usr/include/c++/9/cstdlib:75:15: fatal error: stdlib.h: No such file or 
directory
   75 | #include_next 
  |   ^~
compilation terminated.
$

What happens here is that g++ includes
libstdc++-v3/include/c_global/cstdlib. That header temporarily #defines
_GLIBCXX_INCLUDE_NEXT_C_HEADERS and then does #include_next .
libstdc++-v3's replacement libstdc++-v3/include/c_comaptibility/stdlib.h
happens to come earlier and is not considered.  Unfortunately, the
-isystem above inserted glibc's header before the location containing
, so the #include_next continues searching and fails to find
.

Now you are probably going to say that "-isystem /usr/include" is a bad
idea and that you shouldn't do that. I'm inclined to agree. This isn't a
problem just yet. Debian wants to move /usr/include/stdlib.h to
/usr/include//stdlib.h. After that move, the problematic flag
becomes "-isystem /usr/include/". Unfortunately, around 30
Debian packages[1] do pass exactly that flag. Regardless whether doing
so is a bad idea, I guess we will have to support that.

I am proposing to replace those two #include_next with plain #include.
That'll solve the problem described above, but it is not entirely
obvious that doing so doesn't break something else.

After switching those #include_next to #include,
libstdc++-v3/include/c_global/cstdlib will continue to temporarily
will #include . Now, it'll search all include directories. It
may find libstdc++-v3/include/c_comaptibility/stdlib.h or the libc's
version. We cannot tell which. If it finds the one from libstdc++-v3,
the header will notice the _GLIBCXX_INCLUDE_NEXT_C_HEADERS macro and
immediately #include_next  skipping the rest of the header.
That in turn will find the libc version. So in both cases, it ends up
using the right one. Precisely what we wanted. #include_next is simply
not useful here.

The #include_next was originally added via PRs libstdc++/14608 and
libstdc++/60401. At that time, the _GLIBCXX_INCLUDE_NEXT_C_HEADERS guard
macro was also added. It seems like the #include_next was a meant as an
extra safe-guard, but actually breaks a practical use case.

For these reasons, I think that using #include_next here is harmful and
that replacing it with plain #include solves the problem without
introducing regressions.

[1] Including but not limited chromium-browser, inkscape, various kde
packages, opencv, and vtk.

libstdc++-v3/ChangeLog:

* include/c_global/cmath: Don't use #include_next.
* include/c_global/cstdlib: Likewise.
---
 libstdc++-v3/include/c_global/cmath   | 2 +-
 libstdc++-v3/include/c_global/cstdlib | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

Given the patch's size, I think that the copyright dance is not
necessary. The issue affects at least gcc-8 to gcc-10. Please Cc me in
replies.

Helmut

diff --git a/libstdc++-v3/include/c_global/cmath 
b/libstdc++-v3/include/c_global/cmath
index b99aaf8df40..8b2bb7c0785 100644
--- a/libstdc++-v3/include/c_global/cmath
+++ b/libstdc++-v3/include/c_global/cmath
@@ -42,7 +42,7 @@
 #include 
 #include 
 #define _GLIBCXX_INCLUDE_NEXT_C_HEADERS
-#include_next 
+#include 
 #undef _GLIBCXX_INCLUDE_NEXT_C_HEADERS
 #include 
 
diff --git a/libstdc++-v3/include/c_global/cstdlib 
b/libstdc++-v3/include/c_global/cstdlib
index f42db41fc51..80b39f6144f 100644
--- a/libstdc++-v3/include/c_global/cstdlib
+++ b/libstdc++-v3/include/c_global/cstdlib
@@ -72,7 +72,7 @@ namespace std
 // Need to ensure this finds the C library's  not a libstdc++
 // wrapper that might already be installed later in the include search path.
 #define _GLIBCXX_INCLUDE_NEXT_C_HEADERS
-#include_next 
+#include 
 #undef _GLIBCXX_INCLUDE_NEXT_C_HEADERS
 #include 
 
-- 
2.26.0



Bug#910685: glibc: please support DPKG_ROOT

2020-04-19 Thread Helmut Grohne
Hi Aurelien,

On Tue, Apr 14, 2020 at 05:49:38PM +0200, Helmut Grohne wrote:
> Yes, please. Is there anything blocking this? Without support in glibc,
> moving forward is a little difficult. Can you include it soonish?

I pinged Aurelien on IRC about this. Let me summarize your answer here:

 * The relevant maintainer scripts are fragile. Experience has shown
   that every time one touches them they break. They should be
   well-tested.
 * Does the patch actually make libc6 work the way it advertises?
 * What about libc-bin?
 * Why not move forward with more testing of more packages before
   applying this patch?

Yes, that makes sense. Let me give a partial answer already.

I've performed a number of upgrades from unstable to patched libc
packages in buildd-like environments now. The coverage is limited.

I've set up a little testing lab to build patched versions of
base-files, bash, coreutils, debhelper, debianutils, dpkg, glibc, shadow
and util-linux. When installing subsets of essential using these patched
packages, few packages fail to install. The failures are base-files,
base-passwd, bash, dash, debconf, libc-bin, libpam-modules-bin,
libpam-modules, libpam0g, login, mawk, sysvinit-utils, and util-linux.
The majority of failures is due to missing patches for debconf. libc-bin
is notable here as it will need changes to ldconfig to support this use
case. However, very few packages depend on libc-bin. Therefore, I think
solving libc-bin at a later time is reasonable.

Small steps have been made in various packages:
https://salsa.debian.org/pkg-debconf/debconf/-/merge_requests/4
https://salsa.debian.org/debian/shadow/-/merge_requests/10
https://salsa.debian.org/debian/shadow/-/merge_requests/11
https://salsa.debian.org/debian/debianutils/-/merge_requests/5
Guillem Jover resumed up work on dpkg-maintscript-helper and
update-alternatives.

In any case, I think that this patch does indeed make the library (not
libc-bin) work for DPKG_ROOT and I'd prefer libc-bin to be handled in a
separate issue.

So yeah, we can move forward without this being merged if we really
want. Questioning whether this patch blocks progress was a useful thing
to do. There will be more fixes.

Helmut



Bug#956855: consider reducing toolchain bootstrap stages

2020-04-15 Thread Helmut Grohne
Source: cross-toolchain-base
Version: 45
Severity: wishlist
Tags: patch moreinfo

I'm not sure anymore who told me, but glibc has a build_many_glibcs.py
script and it does the toolchain bootstrap dance with fewer stages than
Debian (i.e. cross-toolchain-base and rebootstrap) does. The current
Debian toolchain bootstrap looks like this:

 * binutils
 * linux-libc-dev
 * gcc stage1 (bare metal)
 * glibc stage1 (headers + stub libc.so)
 * gcc stage2
 * glibc stage2 (libc without systemtap and other optional features)
 * gcc stage3 (libc-integrated cross compiler)
 * gcc rtlibs (runtime libraries for the cross compiler)

The assertion is that we can skip glibc stage1 and gcc stage2 and go
directly from gcc stage1 to glibc stage2.

I've implemented this in rebootstrap and it seems to work reasonably
well for a number of architectures. I've not run it on the full test
matrix yet. Some observations on rebootstrap:
 * musl-linux-any already works like this since a while.
 * hurd-any formerly needed libihash-dev for libpthread, but no longer
   does. This sequence also works on hurd-i386.
 * I've had success with arm64, armel, armhf, m68k, mips (nobiarch),
   mipsel (nobiarch) and ppc64el thus far. Notably, these all lack
   multilibs and I'm still sorting out multilib issues.
 * I cannot tell about kfreebsd-any, since they didn't manage to get the
   relevant kernel header source package back into unstable yet.

I've implemented this for cross-toolchain-base (patch attached) and a
performed a successful testbuild. Using diffoscope to compare the
resulting packages with the ones from the archive was not a useful thing
to do as the build-ids changed.

So what do you think about going to fewer stages? I'd like to solicit
explicit feedback from the involved parties:

gcc maintainers / Matthias:
 * Do you have any objections to reducing stages?
 * Should we delete gcc stage2?
 * Should we rename gcc stage3 to gcc stage2?

glibc maintainers / Aurelien:
 * Do you have any objections to reducing stages?
 * Should we delete glibc stage1?
 * Should we rename glibc stage2 to glibc stage1?
 * Should we maybe split stage2 into a number of profiles
   pkg.glibc.noselinux, pkg.glibc.noxen, pkg.glibc.noalphaev,
   pkg.glibc.noxcryptdep?

Due to these open questions, I've tagged the bug moreinfo.

Helmut
diff --minimal -Nru cross-toolchain-base-45/debian/changelog 
cross-toolchain-base-45+nmu1/debian/changelog
--- cross-toolchain-base-45/debian/changelog2020-03-22 14:02:54.0 
+0100
+++ cross-toolchain-base-45+nmu1/debian/changelog   2020-04-15 
11:35:18.0 +0200
@@ -1,3 +1,10 @@
+cross-toolchain-base (45+nmu1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Bootstrap with fewer stages. (Closes: #-1)
+
+ -- Helmut Grohne   Wed, 15 Apr 2020 11:35:18 +0200
+
 cross-toolchain-base (45) unstable; urgency=medium
 
   * Build using glibc 2.30-2.
diff --minimal -Nru cross-toolchain-base-45/debian/rules 
cross-toolchain-base-45+nmu1/debian/rules
--- cross-toolchain-base-45/debian/rules2020-03-22 14:02:01.0 
+0100
+++ cross-toolchain-base-45+nmu1/debian/rules   2020-04-15 11:35:18.0 
+0200
@@ -343,96 +344,6 @@
  ln -sf ${CROSS_GNU_TYPE}-gcov-${VER_GCC_BASE} ${CROSS_GNU_TYPE}-gcov
 endef
 
-$(stamp)build-gcc2.%: $(stamp)init-gcc $(stamp)install-glibc1.%
-   @echo START $@
-   cd debian/tmp.${CROSS_ARCH}/$(PF)/bin/ && \
- rm -f ${CROSS_GNU_TYPE}-gcc-${VER_GCC_BASE} ${CROSS_GNU_TYPE}-gcc && \
- rm -f ${CROSS_GNU_TYPE}-cpp-${VER_GCC_BASE} ${CROSS_GNU_TYPE}-cpp && \
- rm -f ${CROSS_GNU_TYPE}-gcov-${VER_GCC_BASE} ${CROSS_GNU_TYPE}-gcov
-   cd gcc && \
- PATH=${CURDIR}/debian/tmp.${CROSS_ARCH}/$(PF)/bin:${PATH} \
- LD_LIBRARY_PATH=$(call 
binutils_ldpath,$*):${CURDIR}/debian/tmp.${CROSS_ARCH}/usr/lib:${CURDIR}/debian/tmp.${CROSS_ARCH}/lib
 \
- DH_VERBOSE=1 \
- WITH_SYSROOT=/ \
- WITH_BUILD_SYSROOT=${CURDIR}/debian/tmp.${CROSS_ARCH} \
- DEB_STAGE=stage2 \
- PKG_IGNORE_CURRENTLY_BUILDING=1 \
- BACKPORT=false \
- DEB_BUILD_OPTIONS="$(DEB_BUILD_OPTIONS) nocheck nopgo nolto nohppa64 
nojit nonvptx" \
- WITHOUT_LANG="hppa64 jit nvptx" \
- $(if $(filter $(HOST_ARCH),$(CROSS_ARCH)),FORCE_CROSS_LAYOUT=yes 
WITH_BOOTSTRAP=off) \
- dpkg-buildpackage -b -uc -us -d
-   touch $@
-
-$(stamp)install-gcc2.%: $(stamp)build-gcc2.%
-   @echo START $@
-   $(call install_gcc)
-   dpkg-deb -x libgcc[124]-${CROSS_ARCH}-cross_${DEB_VER_GCC}_all.deb \
-   debian/tmp.${CROSS_ARCH}
-ifneq (,$(ARM32_MULTILIBS))
-   $(if $(filter $(CROSS_ARCH),armhf), \
- dpkg-deb -x libsfgcc1-${CROSS_ARCH}-cross_${DEB_VER_GCC}_all.deb \
-   debian/tmp.${CROSS_ARCH}; \
- dpkg-deb -x 
libsfgcc-${VER_GCC_BASE}-dev-${CROSS_ARCH}-cross_${DEB_VER_GCC}_all.deb \
-   debian

Bug#910685: glibc: please support DPKG_ROOT

2020-04-14 Thread Helmut Grohne
On Tue, Oct 09, 2018 at 10:09:57PM +0200, Johannes 'josch' Schauer wrote:
> Currently in Debian sid, there are 57 packages that need to be installed
> for the whole Essential:yes set. Most of them Depend (directly or
> indirectly) on libc6. Attached patch adds $DPKG_ROOT to a couple of
> places of the preinst and postinst of libc6 and that will make 37 of
> these 57 install without problems. The patch adds $DPKG_ROOT in more
> places than strictly necessary for just installing packages. For example
> I didn't test the upgrade scenario. If you like, I can prepare a smaller
> patch with only the code paths that I tested.

I think that your approach is not ideal. Much of the code in the libc
scripts is for ensuring that a system is not bricked and that services
continue to work after a libc upgrade. When working with the chrootless
mode, we cannot assume that the running kernel version or other aspects
are relevant to the chroot at hand. In this case, it is much better to
skip the relevant code entirely. Doing so has the additional benefit of
not using debconf at all. When running in chrootless mode, there cannot
be any services running, because they'd have to be chrooted. So we can
simply skip all those checks. The patch becomes quite a bit simpler.

> It would be nice if you could consider applying attached patch because
> it is required for the majority of packages in the Essential:yes set to
> be successfully installed with the --force-script-chrootless mode.
> 
> To test you can run:
> 
> dpkg --root "$target" --log "$target/var/log/dpkg.log" 
> --force-script-chrootless -i libc6_2.27-6.1_amd64.deb

Yes, please. Is there anything blocking this? Without support in glibc,
moving forward is a little difficult. Can you include it soonish?

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-14 17:39:34.0 +0200
@@ -1,3 +1,10 @@
+glibc (2.30-4.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Initial, minimal support for DPKG_ROOT. (Closes: #910685)
+
+ -- Helmut Grohne   Tue, 14 Apr 2020 17:39:34 +0200
+
 glibc (2.30-4) unstable; urgency=medium
 
   [ Aurelien Jarno ]
diff --minimal -Nru glibc-2.30/debian/debhelper.in/libc.postinst 
glibc-2.30/debian/debhelper.in/libc.postinst
--- glibc-2.30/debian/debhelper.in/libc.postinst2020-03-25 
13:36:06.0 +0100
+++ glibc-2.30/debian/debhelper.in/libc.postinst2020-04-14 
17:36:49.0 +0200
@@ -17,11 +17,14 @@
 if [ "$type" = "configure" ]
 then
 # We don't use a registry anymore, remove the old file
-rm -f /etc/ld.so.hwcappkgs
+rm -f "$DPKG_ROOT/etc/ld.so.hwcappkgs"
  
 # /etc/ld.so.nohwcap code:
 __NOHWCAP__
+fi
 
+if [ "$type" = configure -a -z "$DPKG_ROOT" ]
+then
 # Load debconf module if available
 if [ -f /usr/share/debconf/confmodule ] ; then
. /usr/share/debconf/confmodule
diff --minimal -Nru glibc-2.30/debian/debhelper.in/libc.preinst 
glibc-2.30/debian/debhelper.in/libc.preinst
--- glibc-2.30/debian/debhelper.in/libc.preinst 2020-03-25 13:38:38.0 
+0100
+++ glibc-2.30/debian/debhelper.in/libc.preinst 2020-04-14 17:38:54.0 
+0200
@@ -19,7 +19,7 @@
 test $verA -$2 $verB
 }
 
-if [ "$type" != abort-upgrade ]
+if [ "$type" != abort-upgrade -a -z "$DPKG_ROOT" ]
 then
 # Load debconf module if available and usable
 if [ -f /usr/share/debconf/confmodule ] && \
@@ -148,7 +148,7 @@
 fi
 fi
 
-if [ "$type" = upgrade ]
+if [ "$type" = upgrade -a -z "$DPKG_ROOT" ]
 then
 if [ -n "$preversion" ] && [ -x "$(which ischroot)" ] && ! ischroot; then
# NSS authentication trouble guard
@@ -246,8 +246,8 @@
# unconditionally wipe ld.so.cache on major version upgrades; this
# makes those upgrades a bit slower, but is less error-prone than
# hoping we notice every time the cache format is changed upstream
-   rm -f /etc/ld.so.cache
-   rm -f /var/cache/ldconfig/aux-cache
+   rm -f "$DPKG_ROOT/etc/ld.so.cache"
+   rm -f "$DPKG_ROOT/var/cache/ldconfig/aux-cache"
 fi
 fi
 
diff --minimal -Nru glibc-2.30/debian/script.in/nohwcap.sh 
glibc-2.30/debian/script.in/nohwcap.sh
--- glibc-2.30/debian/script.in/nohwcap.sh  2019-08-16 12:57:33.0 
+0200
+++ glibc-2.30/debian/script.in/nohwcap.sh  2020-04-14 17:39:30.0 
+0200
@@ -18,5 +18,5 @@
 # one, we could remove /etc/ld.so.nohwcap. Otherwise, it will be removed
 # when all optimized packages are upgraded or removed.
 if [ "$all_upgraded" = yes ] ; then
-rm -f /etc/ld.so.nohwcap
+rm -f "$DPKG_ROOT/etc/ld.so.nohwcap"
 fi


Bug#954393: please Breaks: libc6-dev-${DEB_HOST_ARCH}-cross (<< ${CURRENT_UPSTREAM_VERSION})

2020-03-21 Thread Helmut Grohne
Package: libc6-dev
Version: 2.30-2
Severity: wishlist

Every time a new glibc upstream release gets uploaded,
cross-toolchain-base breaks in difficult to diagnose ways. This seems to
happen, because gcc uses the libc6-dev:somearch headers together with
libc6-dev-somearch-cross libraries.

Would you agree to have libc6-dev declare

Breaks: libc6-dev-${DEB_HOST_ARCH}-cross (<< ${CURRENT_UPSTREAM_VERSION}~)

where CURRENT_UPSTREAM_VERSION would presently be 2.30? I think that'd
spare us from diagnosing these issues in general.

Helmut



Bug#954392: libc6-dev-armhf-cross is incompatible with current libc6-dev:armhf

2020-03-21 Thread Helmut Grohne
Package: libc6-dev-armhf-cross
Version: 2.29-9cross1
Severity: serious

The current libc6-dev-armhf-cross is incompatible with libc6-dev:armhf
versioned >= 2.30. Typical symptoms include (mips64el this time, but
also reproducible for armhf):

/usr/lib/gcc-cross/mips64el-linux-gnuabi64/9/../../../../mips64el-linux-gnuabi64/bin/ld:
 /lib/mips64el-linux-gnuabi64/libpthread.so.0: undefined reference to 
`__twalk_r@GLIBC_PRIVATE'
/usr/lib/gcc-cross/mips64el-linux-gnuabi64/9/../../../../mips64el-linux-gnuabi64/bin/ld:
 /lib/mips64el-linux-gnuabi64/libsystemd.so: undefined reference to 
`gettid@GLIBC_2.30'

This seems to happen, because gcc uses the glibc 2.30 headers from
libc6-dev:armhf and then links the shared library from
libc6-dev-armhf-cross. Deferring the sysroot library path after the
multiarch library path might solve this.

In the mean time, please rebuild cross-toolchain-base with glibc >=
2.30.

Helmut



Bug#946396: glibc+libxcrypt breaks cross-toolchain-base

2019-12-08 Thread Helmut Grohne
Source: glibc
Version: 2.29-5
Severity: serious
Justification: installation failure
Control: affects -1 + src:cross-toolchain-base

Since glibc added dependencies on libxcrypt, building
cross-toolchain-base produces packages that are not installable:

| $ dpkg-deb -I libc6-dev-arm64-cross_2.29-5cross1_all.deb
|  new Debian package, version 2.0.
|  size 2261068 bytes: control archive=12892 bytes.
|  833 bytes,17 lines  control
|40350 bytes,   515 lines  md5sums
|  Package: libc6-dev-arm64-cross
|  Version: 2.29-5cross1
|  Section: libdevel
|  Priority: optional
|  Architecture: all
|  Maintainer: GNU Libc Maintainers 
|  Source: cross-toolchain-base (42)
|  Provides: libc-dev-arm64-cross, libc6-dev-arm64-dcv1
|  Depends: libc6-arm64-cross (= 2.29-5cross1), linux-libc-dev-arm64-cross, 
libcrypt1-dev-arm64-cross
|  Conflicts: libc0.1-dev-arm64-cross, libc0.3-dev-arm64-cross, 
libc6.1-dev-arm64-cross
|  Description: GNU C Library: Development Libraries and Header Files (for 
cross-compiling)
|   This package was generated by dpkg-cross for cross compiling.
|   .
|   Contains the symlinks, headers, and object files needed to compile
|   and link programs which use the standard C library.
|  Built-Using: binutils (= 2.33.1-5), linux (= 5.3.15-1), gcc-9 (= 9.2.1-21), 
glibc (= 2.29-5)
|  Multi-Arch: foreign
| $

However, there is no libcrypt1-dev-arm64-cross package produced by
anything in the archive. For this reason glibc/2.29-5 should not migrate
to testing until there is a solution to this problem.

Helmut



Bug#916588: libc6: uses non-essential runlevel in preinst and postinst

2018-12-16 Thread Helmut Grohne
Package: libc6
Version: 2.28-2
Severity: minor

While upgrading libc6 from 2.27-8 to 2.28-2, I saw this:

| Checking for services that may need to be restarted...
| Checking init scripts...
| /var/lib/dpkg/tmp.ci/preinst: 320: /var/lib/dpkg/tmp.ci/preinst: runlevel: 
not found

That's libc6's preinst using runlevel.

I also saw this:

| Checking for services that may need to be restarted...
| Checking init scripts...
| /var/lib/dpkg/info/libc6:amd64.postinst: 81: 
/var/lib/dpkg/info/libc6:amd64.postinst: runlevel: not found
| Nothing to restart.

That's the same thing for postinst.

The message is completely harmless. It's from
debian/script.in/nsscheck.sh and tells. When runlevel is not available,
we're not running any of sysvinit, systemd or runit and very likely no
services are running. In that case, the result is irrelevant and the
only negative effect is the message. The upgrade proceeds successfully.

Helmut



Re: Propose requiring Python 3.4 or later for building glibc.

2018-10-22 Thread Helmut Grohne
On Mon, Oct 22, 2018 at 11:38:15AM -0400, Carlos O'Donell wrote:
> It is possible that the build *and* host require python 3.4.
> 
> The reason being that when cross-testing glibc with the test-wrapper-env
> script the build system may execute a command on the host system to 
> run python (which is usually implemented as a ssh to a target system
> with a shared mounted filesystem).
> 
> There are at least several pretty-printing tests which use python, and
> require PExpect, and those run on the host during testing via the
> test-wrapper-env abstraction.
> 
> I've started a new thread of discussion here, but in general my expectation
> has always been that host and build environments need the same set of tools.
> 
> https://www.sourceware.org/ml/libc-alpha/2018-10/msg00395.html

I should have thought of testing indeed. In Debian, we tend to turn
testing off completely for a bootstrap and then rebuild the world (using
the bootstraped packages) with testing enabled. This is done, because it
removes a pile of dependencies and makes the problem a bit more
manageable. So as long as tests can be disabled (preferably without
changing the build result in terms of reproducible builds[1]), the cross
bootstrap won't be impacted.

In any case, requiring Python 3 for testing does not seem to be a new
thing. The dependency is already there and it is not causing problems
now. So from a cross bootstrap pov, I'm fine here.

Helmut

[1] We also use reproducible builds to validate cross buildt packages
against natively built (with tests enabled) ones.



Re: Propose requiring Python 3.4 or later for building glibc.

2018-10-22 Thread Helmut Grohne
On Mon, Oct 22, 2018 at 11:51:25AM +0200, Aurelien Jarno wrote:
> On 2018-10-19 09:47, Carlos O'Donell wrote:
> > This proposal is to being circulated to all the distribution
> > maintainers to gain their acceptance surrounding the use of
> > python 3.4 or greater for building glibc.
> > 
> > There has been concern expressed that requiring python 3.4
> > or greater for the bootstrap process will add an additional
> > tool the the bootstrap, and specifically a tool that may not
> > be available on older distributions.
> > 
> > Python is already mostly available for distributions because
> > of the integration into key OS components. Python can be 
> > built on older distributions, and on older distributions you
> > already have to build a lot of things to compile glibc (like
> > a newer gcc, and binutils).
> > 
> > The question today is:
> > 
> > * Is it OK to require python 3.4 or later to build glibc?
> 
> [...]
> 
> > Aurelian,
> > 
> > Any input from Debian?
> 
> From the Debian side, the version 3.4 is not an issue at all. The
> default Python 3 version in unstable (which is relevant for future
> versions of glibc) is already 3.6.
> 
> We also need to consider the process of bootstrapping Debian. In that
> case I believe it should also be fine as Python 3 from the host system
> can be used. I have added Helmut Grohne in Cc: who is much more aware
> of the bootstrapping process than me, and can confirm or infirm that.

I fear we need more precision here. There are multiple ways to bootstrap
Debian. There is "cross bootstrap" for jumping from one Debian
architecture to another, which is what I work on. As long as glibc only
needs to run the build architecture Python, I see no problems here. I
assume that you are not trying to integrate with the host architecture
Python as that would pose interesting problems. Given that Debian's
cross bootstraps are version locked, I don't see problems with requiring
recent versions either. In contrast, I'd love to be able to use Python 3
in Debian's glibc packaging. Also note that Debian's linux packaging
already requires Python 3 (for the build architecture) for quite a while
already.

>From a Debian cross bootstrap pov, no problems are to be expected.

Daniel Schepler is working on a native bootstrap approach. As far as I
understand, he natively bootstraps Debian from non-Debian (same
processor architecure and kernel). I expect that his work will be
impacted by the proposed change. I've added him to Cc to let him speak
up.

Requiring Python modules or extensions is another question. Some modules
(e.g. six) are easy, but ones with dependencies of their own tend to not
be. That's rooted in the way Debian handles cross architecture
dependencies unfortunately.

Thank you for reaching out in advance of the change and for relaying the
message to non-subscribers.

Helmut



Bug#798955: How to deal with gcc's with multiarch glibc headers?

2018-10-01 Thread Helmut Grohne
Hi,

I was offered some CPU cycles to research the impact of #798955 (moving
glibc's headers to /usr/include/). I'll post another mail with
a summary, but there is already one quite obvious issue affecting
multiple packages. The implications are not quite clear to me, so maybe
someone else can chime in?

/usr/include/c++/8/cstdlib contains the following code:

| // Need to ensure this finds the C library's  not a libstdc++
| // wrapper that might already be installed later in the include search path.
| #define _GLIBCXX_INCLUDE_NEXT_C_HEADERS
| #include_next 
| #undef _GLIBCXX_INCLUDE_NEXT_C_HEADERS

After fixing #798955, glibc's stdlib.h will live in
/usr/include/. One can figure out the default include search
path with "gcc -E -Wp,-v - 
comes before /usr/include. Adding -x c++ gives the search path for C++.
Notably /usr/include/c++/8 comes before both others.

Now most of the time, that works, but some packages (such as
chromium-browser, fcitx-qt5, fw4spl, or gemma) insist on adding some
-isystem /usr/include/.  That changes order and one can get:

| /usr/include/c++/8/cstdlib:75:15: fatal error: stdlib.h: No such file or 
directory
|  #include_next 
|^~
| compilation terminated.

You can trigger the very same error on a standard sid system using
-isystem /usr/include:

| echo '#include ' | g++ -isystem /usr/include -x c++ -E - >/dev/null

After messing with system include order, that's a little expected, but I
wonder whether it should work anyway.

Now gcc also ships /usr/include/c++/8/stdlib.h which starts with:

| #if !defined __cplusplus || defined _GLIBCXX_INCLUDE_NEXT_C_HEADERS
| # include_next 
| #else

So it seems that if we replaced the #include_next in cstdlib with a
plain #include, it should always work, regardless of the search order:
If glibc's header comes first, all is fine. Otherwise, the
_GLIBCXX_INCLUDE_NEXT_C_HEADERS macro will instruct gcc's stdlib.h to
#include_next glibc's stdlib.h, so it should also be fine. What I don't
understand is: why does cstdlib use #include_next at all? What problem
is solved by not using plain #include?

Then the question arises whether adding /usr/include/ via
-isystem is something that should work. Should we fix chromium-browser
et al here?

Thanks in advance

Helmut



Bug#902800: glibc FTBFS: dh_installdocs: Cannot find (any matches for) "BUGS" (tried in .)

2018-07-01 Thread Helmut Grohne
Source: glibc
Version: 2.27-3
Severity: serious
Justification: fails to build from source (but built successfully in the past)
Tags: ftbfs
User: helm...@debian.org
Usertags: rebootstrap

glibc fails to cross build from source. An arch-only build log (using
DEB_BUILD_OPTIONS=nocheck to speed things up) on amd64 ends with:

| dh_installdocs -plibc6 
| dh_installdocs: Cannot find (any matches for) "BUGS" (tried in .)
| 
| make: *** [debian/rules.d/debhelper.mk:27: 
/<>/stamp-dir/binaryinst_libc6] Error 2
| dpkg-buildpackage: error: fakeroot debian/rules binary-arch subprocess 
returned exit status 2

A certain coincidence with the debhelper/11.3.5 upload cannot be ruled
out. debhelper maintainers Cced.

A timely fix is appreciated as this breaks bootstrap QA.

Helmut



Bug#898743: breaks when #included after

2018-05-15 Thread Helmut Grohne
Package: linux-libc-dev,libc6-dev
Severity: serious
Justification: makes systemd ftbfs
User: helm...@debian.org
Usertags: rebootstrap
Control: affects -1 + src:systemd libmount-dev

systemd FTBFS here, because compiling load-fragment.c fails. I spent a while
minimizing that file and it boils down to:

$ cat test.c
#include 
#include 
$ gcc -c test.c
In file included from test.c:1:0:
/usr/include/x86_64-linux-gnu/sys/mount.h:35:3: error: expected identifier 
before numeric constant
   MS_RDONLY = 1,  /* Mount read-only.  */
   ^
$

linux/fs.h #defines MS_RDONLY and then sys/mount.h tries to create an
enum containing MS_RDONLY. That's a problem.

This is also known in fedora:
https://bugzilla.redhat.com/show_bug.cgi?id=1497501

That bug hints that sometimes headers need to #included in a certain
order. If that is the case, this bug should be reassigned to src:systemd
asking that  or  must be #included before
. It also means that  should #include
 before defining its own copies of these macros.

Helmut

PS: Let me briefly curse systemd for their use of cyclic #includes
(unit.h <-> cgroup.h) and #pragma once as that works pretty badly
with creduce. Thank you.



Bug#892126: glibc: stage1 build failure due to missing multilib lib-names-*.h

2018-03-05 Thread Helmut Grohne
Source: glibc
Version: 2.27-1
User: helm...@debian.org
Usertags: rebootstrap

Hi Aurelien,

I need a bug number for tracking this issue, so I am filing this bug
summarizing the problem and recording my knowledge.

Building glibc with DEB_BUILD_OPTIONS=nocheck DEB_BUILD_PROFILES=stage1
presently fails (even natively) on architectures with multilib packages.
The symptom always is that some variant of a multilib lib-names-*.h goes
missing in the packaging part of the installation procedure recently
added.

The headers in question are not generated during a (stage1) build and a
gcc stage2 (the only relevant user) does not use them. I verified that
simply not installing them makes a bootstrap of e.g. mips work again:

sed -i -e 's#debian/tmp-.*/usr/include/gnu/lib-names.*\.h#$(if $(filter 
stage1,$(DEB_BUILD_PROFILES)),,&)#' debian/sysdeps/*.mk

Now I am not asking you to include this fix (thus not adding a patch
tag), because we both know it is ugly, but I am recording the workaround
to improve our understanding. It confirms our intuition that the same
workaround as for gnu/stubs.h should be applicable here. My attempts at
implementing that properly weren't fruitful thus far. So all I can do
now is document the problem.

Helmut



Bug#886315: libc6-dev-$arch-cross incompatible with libc6-dev:$arch: glibc major version skew

2018-01-04 Thread Helmut Grohne
Package: 
libc6-dev-arm64-cross,libc6-dev-armel-cross,libc6-dev-armhf-cross,libc6-dev-mips-cross,libc6-dev-mips64el-cross,libc6-dev-mipsel-cross,libc6-dev-ppc64el-cross,libc6-dev-s390x-cross
Version: 2.25-3cross1
Severity: important
User: helm...@debian.org
Usertags: rebootstrap
Control: block -1 by 886301

The cross-toolchain-base package in unstable is still built from glibc
2.25 while unstable has glibc 2.26. When both are installed, gcc seems
to pick e.g. -lpthread from libc6-dev:$arch and -lc from
libc6-dev-$arch-cross. That can result in:

//lib/powerpc64le-linux-gnu/libpthread.so.0: undefined reference to 
`__mmap@GLIBC_PRIVATE'

Try configuring src:nvi to reproduce.

Please reupload cross-toolchain-base. You probably want to wait for the
fix of #886301 though.

This is not super exciting, but I need a bug number.

Helmut



Bug#886301: glibc: logme removal accidentally breaks stage1

2018-01-03 Thread Helmut Grohne
Source: glibc
Version: 2.26-1
Tags: patch
User: helm...@debian.org
Usertags: rebootstrap

Hi Aurelien,

pkg-glibc commit 74784d0d9e06adb57047548685e79ea0223a05ac
("debian/rules, debian/rules.d/build.mk: stop logging build/check
messages to files, both sbuild and debuild are able to do that.")
accidentally breaks stage1. It fails to remove a closing brace
corresponding to a prior logme call for install-headers, which is stage1
only code. It's a simple typo.

Helmut

--- a/debian/rules.d/build.mk
+++ b/debian/rules.d/build.mk
@@ -166,7 +166,7 @@
 ifneq ($(filter stage1,$(DEB_BUILD_PROFILES)),)
$(MAKE) -C $(DEB_BUILDDIR) $(NJOBS) \
cross-compiling=yes install_root=$(CURDIR)/debian/tmp-$(curpass)
\
-   install-bootstrap-headers=yes install-headers )
+   install-bootstrap-headers=yes install-headers

install -d $(CURDIR)/debian/tmp-$(curpass)/$(call xx,libdir)
install -m 644 $(DEB_BUILDDIR)/csu/crt[01in].o 
$(CURDIR)/debian/tmp-$(curpass)/$(call xx,libdir)/.



Bug#883186: e2fsprogs FTBFS on mips64el: undefined reference to `posix_fadvise64'

2017-11-30 Thread Helmut Grohne
Source: e2fsprogs
Version: 1.43.7-1
Severity: serious
Justification: FTBFS
User: helm...@debian.org
Usertags: rebootstrap

I was investigating a bootstrap failure for mips64el
(https://jenkins.debian.net/job/rebootstrap_mips64el_gcc7_nobiarch/51)
and wondered whether this was a native issue. Indeed a native build of
e2fsprogs fails on mips64el and the build log ends as follows:

| /usr/bin/make -C /home/helmutg/e2fsprogs-1.43.7/debian/BUILD-STD/e2fsck V=1 
e2fsck.static
| make[1]: Entering directory 
'/home/helmutg/e2fsprogs-1.43.7/debian/BUILD-STD/e2fsck'
| gcc -Wl,-z,relro -Wl,-z,now -static -o e2fsck.static unix.o e2fsck.o super.o 
pass1.o pass1b.o pass2.o pass3.o pass4.o pass5.o journal.o badblocks.o util.o 
dirinfo.o dx_dirinfo.o ehandler.o problem.o message.o quota.o recovery.o 
region.o revoke.o ea_refcount.o rehash.o logfile.o sigcatcher.o  readahead.o 
extents.o   ../lib/libsupport.a ../lib/libext2fs.a ../lib/libcom_err.a 
-lpthread -lblkid -luuid -luuid  -luuid   ../lib/libe2p.a -ldl -lblkid  
| logfile.o: In function `expand_percent_expression':
| ./debian/BUILD-STD/e2fsck/../../../e2fsck/logfile.c:141: warning: Using 
'getpwuid_r' in statically linked applications requires at runtime the shared 
libraries from the glibc version used for linking
| ../lib/libext2fs.a(unix_io.o): In function `unix_cache_readahead':
| ./debian/BUILD-STD/lib/ext2fs/../../../../lib/ext2fs/unix_io.c:969: undefined 
reference to `posix_fadvise64'
| ./debian/BUILD-STD/lib/ext2fs/../../../../lib/ext2fs/unix_io.c:969: undefined 
reference to `posix_fadvise64'
| collect2: error: ld returned 1 exit status
| Makefile:428: recipe for target 'e2fsck.static' failed
| make[1]: *** [e2fsck.static] Error 1
| make[1]: Leaving directory 
'/home/helmutg/e2fsprogs-1.43.7/debian/BUILD-STD/e2fsck'
| debian/rules:262: recipe for target 'debian/stampdir/build-std-stamp' failed
| make: *** [debian/stampdir/build-std-stamp] Error 2
| dpkg-buildpackage: error: debian/rules build-arch subprocess returned exit 
status 2

Since this could either be a mips issue or a glibc issue, I put both
lists into X-Debbugs-Cc and hope that someone will sort this out.

Helmut



Bug#882263: libc6-dev-mips64el-cross breaks linking executables

2017-11-20 Thread Helmut Grohne
Package: libc6-dev-mips64el-cross
Version: 20
Severity: serious
User: helm...@debian.org
Usertags: rebootstrap

I was trying to use gcc-mips64el-linux-gnuabi64 to link a trivial
executable:

$ echo 'int main(){return 0;}' | mips64el-linux-gnuabi64-gcc -x c - -o /dev/null

With libc6-dev:mips64el installed, this just works. As soon as I install
libc6-dev-mips64el-cross, it fails though:

/usr/lib/gcc-cross/mips64el-linux-gnuabi64/7/../../../../mips64el-linux-gnuabi64/bin/ld:
 cannot find /usr/mips64el-linux-gnuabi64/lib/ld.so.1
collect2: error: ld returned 1 exit status

This renders libc6-dev-mips64el-cross pretty much useless.

Helmut



Bug#869717: glibc FTBFS: Error: `loc1@GLIBC_2.2.5' can't be versioned to common symbol 'loc1'

2017-07-25 Thread Helmut Grohne
Source: glibc
Version: 2.24-12
Severity: serious
Tags: patch upstream fixed-upstream
Forwarded: 
https://sourceware.org/git/gitweb.cgi?p=glibc.git;a=commitdiff;h=388b4f1a02f3a801965028bbfcd48d905638b797
User: helm...@debian.org
Usertags: rebootstrap

glibc fails to build from source in unstable amd64:

| x86_64-linux-gnu-gcc-6 -no-pie -fno-PIE regexp.c -c -std=gnu11 -fgnu89-inline 
 -O2 -Wall -Werror -Wundef -Wwrite-strings -fmerge-all-constants 
-frounding-math -g -pipe -Wstrict-prototypes -Wold-style-definition   -fPIC   
-ftls-model=initial-exec-isystem /<>/debian/include  
-I../include -I/<>/build-tree/amd64-libc/misc  
-I/<>/build-tree/amd64-libc  
-I../sysdeps/unix/sysv/linux/x86_64/64  -I../sysdeps/unix/sysv/linux/x86_64  
-I../sysdeps/unix/sysv/linux/x86  -I../sysdeps/unix/sysv/linux/wordsize-64  
-I../sysdeps/x86_64/nptl  -I../sysdeps/unix/sysv/linux/include 
-I../sysdeps/unix/sysv/linux  -I../sysdeps/nptl  -I../sysdeps/pthread  
-I../sysdeps/gnu  -I../sysdeps/unix/inet  -I../sysdeps/unix/sysv  
-I../sysdeps/unix/x86_64  -I../sysdeps/unix  -I../sysdeps/posix  
-I../sysdeps/x86_64/64  -I../sysdeps/x86_64/fpu/multiarch  
-I../sysdeps/x86_64/fpu  -I../sysdeps/x86/fpu/include -I../sysdeps/x86/fpu  
-I../sysdeps/x86_64/multiarch  -I../sysdeps/x86_64  -I../sysdeps/x86  
-I../sysdeps/ieee754/ldbl-96  -I../sysdeps/ieee754/dbl-64/wordsize-64  
-I../sysdeps/ieee754/dbl-64  -I../sysdeps/ieee754/flt-32  
-I../sysdeps/wordsize-64  -I../sysdeps/ieee754  -I../sysdeps/generic  -I.. 
-I../libio -I. -nostdinc -isystem /usr/lib/gcc/x86_64-linux-gnu/6/include 
-isystem /usr/lib/gcc/x86_64-linux-gnu/6/include-fixed -isystem 
/<>/debian/include  -D_LIBC_REENTRANT -include 
/<>/build-tree/amd64-libc/libc-modules.h -DMODULE_NAME=libc 
-include ../include/libc-symbols.h  -DPIC -DSHARED -o 
/<>/build-tree/amd64-libc/misc/regexp.os -MD -MP -MF 
/<>/build-tree/amd64-libc/misc/regexp.os.dt -MT 
/<>/build-tree/amd64-libc/misc/regexp.os
| x86_64-linux-gnu-gcc-6 -no-pie -fno-PIE 
../sysdeps/unix/sysv/linux/getloadavg.c -c -std=gnu11 -fgnu89-inline  -O2 -Wall 
-Werror -Wundef -Wwrite-strings -fmerge-all-constants -frounding-math -g -pipe 
-Wstrict-prototypes -Wold-style-definition   -fPIC   -ftls-model=initial-exec   
 -isystem /<>/debian/include  -I../include 
-I/<>/build-tree/amd64-libc/misc  
-I/<>/build-tree/amd64-libc  
-I../sysdeps/unix/sysv/linux/x86_64/64  -I../sysdeps/unix/sysv/linux/x86_64  
-I../sysdeps/unix/sysv/linux/x86  -I../sysdeps/unix/sysv/linux/wordsize-64  
-I../sysdeps/x86_64/nptl  -I../sysdeps/unix/sysv/linux/include 
-I../sysdeps/unix/sysv/linux  -I../sysdeps/nptl  -I../sysdeps/pthread  
-I../sysdeps/gnu  -I../sysdeps/unix/inet  -I../sysdeps/unix/sysv  
-I../sysdeps/unix/x86_64  -I../sysdeps/unix  -I../sysdeps/posix  
-I../sysdeps/x86_64/64  -I../sysdeps/x86_64/fpu/multiarch  
-I../sysdeps/x86_64/fpu  -I../sysdeps/x86/fpu/include -I../sysdeps/x86/fpu  
-I../sysdeps/x86_64/multiarch  -I../sysdeps/x86_64  -I../sysdeps/x86  
-I../sysdeps/ieee754/ldbl-96  -I../sysdeps/ieee754/dbl-64/wordsize-64  
-I../sysdeps/ieee754/dbl-64  -I../sysdeps/ieee754/flt-32  
-I../sysdeps/wordsize-64  -I../sysdeps/ieee754  -I../sysdeps/generic  -I.. 
-I../libio -I. -nostdinc -isystem /usr/lib/gcc/x86_64-linux-gnu/6/include 
-isystem /usr/lib/gcc/x86_64-linux-gnu/6/include-fixed -isystem 
/<>/debian/include  -D_LIBC_REENTRANT -include 
/<>/build-tree/amd64-libc/libc-modules.h -DMODULE_NAME=libc 
-include ../include/libc-symbols.h  -DPIC -DSHARED -o 
/<>/build-tree/amd64-libc/misc/getloadavg.os -MD -MP -MF 
/<>/build-tree/amd64-libc/misc/getloadavg.os.dt -MT 
/<>/build-tree/amd64-libc/misc/getloadavg.os
| x86_64-linux-gnu-gcc-6 -no-pie -fno-PIE 
../sysdeps/unix/sysv/linux/getclktck.c -c -std=gnu11 -fgnu89-inline  -O2 -Wall 
-Werror -Wundef -Wwrite-strings -fmerge-all-constants -frounding-math -g -pipe 
-Wstrict-prototypes -Wold-style-definition   -fPIC   -ftls-model=initial-exec   
 -isystem /<>/debian/include  -I../include 
-I/<>/build-tree/amd64-libc/misc  
-I/<>/build-tree/amd64-libc  
-I../sysdeps/unix/sysv/linux/x86_64/64  -I../sysdeps/unix/sysv/linux/x86_64  
-I../sysdeps/unix/sysv/linux/x86  -I../sysdeps/unix/sysv/linux/wordsize-64  
-I../sysdeps/x86_64/nptl  -I../sysdeps/unix/sysv/linux/include 
-I../sysdeps/unix/sysv/linux  -I../sysdeps/nptl  -I../sysdeps/pthread  
-I../sysdeps/gnu  -I../sysdeps/unix/inet  -I../sysdeps/unix/sysv  
-I../sysdeps/unix/x86_64  -I../sysdeps/unix  -I../sysdeps/posix  
-I../sysdeps/x86_64/64  -I../sysdeps/x86_64/fpu/multiarch  
-I../sysdeps/x86_64/fpu  -I../sysdeps/x86/fpu/include -I../sysdeps/x86/fpu  
-I../sysdeps/x86_64/multiarch  -I../sysdeps/x86_64  -I../sysdeps/x86  
-I../sysdeps/ieee754/ldbl-96  -I../sysdeps/ieee754/dbl-64/wordsize-64  
-I../sysdeps/ieee754/dbl-64  -I../sysdeps/ieee754/flt-32  
-I../sysdeps/wordsize-64  -I../sysdeps/ieee754  -I../sysdeps/generic  -I.. 
-I../libio -I. -nostdinc -isystem /usr/lib/gcc/x86_64-linux-gnu/6/include 
-isystem 

Bug#840260: glibc: please support the tilegx architecture

2016-10-15 Thread Helmut Grohne
Hi Aurelien,

On Sat, Oct 15, 2016 at 09:15:36PM +0200, Aurelien Jarno wrote:
> Unfortunately this is not enough. Recent dak versions check that the
> architecture is known by dpkg, and ftp-master.debian.org is using
> jessie. If we add tilegx to the Architecture: list, the source package
> will then get rejected.

I agree.

> Please see #835851. Until this is solved or until ftp-master.debian.org
> is fixed, you will have to maintain the patch on your side.

I think this works rather well for me. You took the include change,
which is more relevant for me. rebootstrap automatically adds any
architectures that are missing from all libc*_archs to libc6_archs, so
there is nothing for me to maintain here. I probably won't even notice
when you apply it.

I hope it is ok for you to simply wait until dak has a sufficiently
recent dpkg and then add it. Bringing up full tilegx will take a while
anyway. Next up will be sending a patch for libatomic-ops.

Thanks for your support here.

Helmut



Bug#840260: glibc: please support the tilegx architecture

2016-10-09 Thread Helmut Grohne
Source: glibc
Version: 2.24-3
Severity: wishlist
Tags: patch
User: helm...@debian.org
Usertags: rebootstrap

Hi Aurelien,

Can you add support for the tilegx architecture to glibc? dpkg knows
about the architecture since 1.18.8 and gcc-6 has some preliminary
support already. The patch is quite small. Beyond adding it to
libc6_archs, care needs to be taken to use arch-specific linux headers
from /usr/include//arch. After applying the patch,
debian/control must be regeneratd (not included in the patch). Can you
maintain the diff?

Helmut
diff --minimal -Nru glibc-2.24/debian/changelog glibc-2.24/debian/changelog
--- glibc-2.24/debian/changelog 2016-09-17 20:00:44.0 +0200
+++ glibc-2.24/debian/changelog 2016-10-10 06:36:11.0 +0200
@@ -1,3 +1,10 @@
+glibc (2.24-3.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Support tilegx. (Closes: #-1)
+
+ -- Helmut Grohne <hel...@subdivi.de>  Mon, 10 Oct 2016 06:36:01 +0200
+
 glibc (2.24-3) unstable; urgency=medium
 
   [ Aurelien Jarno ]
diff --minimal -Nru glibc-2.24/debian/rules.d/control.mk 
glibc-2.24/debian/rules.d/control.mk
--- glibc-2.24/debian/rules.d/control.mk2016-09-04 01:26:39.0 
+0200
+++ glibc-2.24/debian/rules.d/control.mk2016-10-10 06:35:57.0 
+0200
@@ -1,7 +1,7 @@
 libc_packages := libc6 libc6.1 libc0.1 libc0.3
 libc0_1_archs := kfreebsd-amd64 kfreebsd-i386
 libc0_3_archs := hurd-i386
-libc6_archs   := amd64 arm64 armel armhf hppa i386 m68k mips mipsel mipsn32 
mipsn32el mips64 mips64el nios2 powerpc powerpcspe ppc64 ppc64el sparc sparc64 
s390x sh4 x32
+libc6_archs   := amd64 arm64 armel armhf hppa i386 m68k mips mipsel mipsn32 
mipsn32el mips64 mips64el nios2 powerpc powerpcspe ppc64 ppc64el sparc sparc64 
s390x sh4 tilegx x32
 libc6_1_archs := alpha
 
 control_deps := $(wildcard debian/control.in/*) $(addprefix 
debian/control.in/, $(libc_packages))
diff --minimal -Nru glibc-2.24/debian/sysdeps/linux.mk 
glibc-2.24/debian/sysdeps/linux.mk
--- glibc-2.24/debian/sysdeps/linux.mk  2016-09-04 01:26:39.0 +0200
+++ glibc-2.24/debian/sysdeps/linux.mk  2016-10-10 06:35:21.0 +0200
@@ -39,6 +39,11 @@
else \
ln -s $(LINUX_HEADERS)/asm debian/include ; \
fi
+   if [ -d "$(LINUX_ARCH_HEADERS)/arch" ]; then \
+   ln -s $(LINUX_ARCH_HEADERS)/arch debian/include ; \
+   else \
+   ln -s $(LINUX_HEADERS)/arch debian/include ; \
+   fi
ln -s $(LINUX_HEADERS)/asm-generic debian/include
ln -s $(LINUX_HEADERS)/linux debian/include
 


Bug#817944: nios2 support

2016-03-11 Thread Helmut Grohne
Source: glibc
Version: 2.22-2
Severity: wishlist
Tags: patch
User: helm...@debian.org
Usertags: rebootstrap

Dear glibc maintainers,

>From a Debian pov, nios2 is a pretty new architecture. It has been added
to dpkg in version 1.18.4. Marek Vasut has been working on actually
bootstrapping the port and things seem to be going well. At this time,
we need one binutils patch[1] and one gcc patch[2], both of which are
upstream already. The matter for glibc is rather simple as well with

sed -i -e 's/^libc6_archs *:=.*/& nios2/' debian/rules.d/control.mk

and then regenerating debian/control. No further nios2 patches on top of
Debian unstable are necessary to bootstrap the toolchain. Can you apply
this patch?

Helmut

[1] 
https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;a=patch;h=a7be2893a6449e64fe6cfcdd8700b0a367a69f19
[2] 
https://gcc.gnu.org/git/?p=gcc.git;a=commitdiff;h=1d67120d95c2c6e0ed4f7357d1cc62887eaba463



Bug#806912: Don't build optimized variants in stage1 or stage2 builds

2015-12-03 Thread Helmut Grohne
On Wed, Dec 02, 2015 at 09:20:58PM +0100, Matthias Klose wrote:
> Package: src:glibc
> Version: 2.21-1
> Tags: patch
> 
> Don't build optimized variants in stage1 or stage2 builds; saves a pass on
> alpha and i386.

I think that the functionality requested here is useful, but I have a
few remarks on the implementation.

1) stage1 shouldn't be doing any non *-dev passes at all, so limiting
   these here is less than ideal.
2) The ability to build without optimized packages is useful beyond
   bootstrapping and it also is not required for bootstrapping, so I'd
   rather see an orthogonal profile be used here.  We already have a
   number of "no*" profile names (e.g. noudeb, nodoc, nobiarch, ...)
   and we could certainly expand that.
3) When limiting packages to certain profiles, debian/control should be
   updated to reflect that.

Helmut



Bug#773300: Improve glibc bootstrap

2015-09-09 Thread Helmut Grohne
In the mean time, the other patch #766877 was merged into experimental.
Time to review this bug. Unfortunately, the original submission lacks
details on what problems are being solved, so assessing the solutions is
difficult and I do not understand all the aspects.

| diff -urN debian/rules /usr/src/glibc/debian/rules
| --- debian/rules  2015-03-18 11:08:54.0 +
| +++ /usr/src/glibc/debian/rules   2015-05-10 07:31:39.0 +
| @@ -140,8 +140,12 @@
|  endif
|  endif
|  
| +ifeq ($(DEB_STAGE),stage2)
| +  DEB_BUILD_PROFILES+=stage2
| +endif
| +

Do we still want to support DEB_STAGE or DEB_BUILD_PROFILE? Maybe we can
just remove support for these variables in 2.21 entirely?

|  ifneq ($(filter stage1,$(DEB_BUILD_PROFILES)),)
| -  DEB_ARCH_REGULAR_PACKAGES = $(libc)-dev
| +  DEB_ARCH_REGULAR_PACKAGES = $(libc)-dev $(libc)

I still disagree with this approach. The underlying problem is that
currently the resulting libc-dev packages from stage1 cannot be
installed, because they depend on libc packages that are not built in
stage1. I think that generating empty libc packages is wrong and that
the dependencies should be dropped in stage1 instead.

|DEB_INDEP_REGULAR_PACKAGES = 
|DEB_UDEB_PACKAGES = 
|  else
| diff -urN debian/rules.d/build.mk /usr/src/glibc/debian/rules.d/build.mk
| --- debian/rules.d/build.mk   2015-03-19 20:28:42.0 +
| +++ /usr/src/glibc/debian/rules.d/build.mk2015-05-10 07:31:39.0 
+
| @@ -160,10 +160,19 @@
|   cross-compiling=yes install_root=$(CURDIR)/debian/tmp-$(curpass)
\
|   install-bootstrap-headers=yes install-headers )
|  
| - install -d $(CURDIR)/debian/tmp-$(curpass)/lib
| - install -m 644 $(DEB_BUILDDIR)/csu/crt[1in].o 
$(CURDIR)/debian/tmp-$(curpass)/lib
| - ${CC} -nostdlib -nostartfiles -shared -x c /dev/null \
| - -o $(CURDIR)/debian/tmp-$(curpass)/lib/libc.so
| + install -d $(CURDIR)/debian/tmp-$(curpass)/$(call xx,libdir)
| + install -m 644 $(DEB_BUILDDIR)/csu/crt[1in].o 
$(CURDIR)/debian/tmp-$(curpass)/$(call xx,libdir)
| + $(call xx,CC) -nostdlib -nostartfiles -shared -x c /dev/null \
| + -o $(CURDIR)/debian/tmp-$(curpass)/$(call xx,libdir)/libc.so

Fixed in experimental.

| + if [ $(curpass) = libc ]; then \
| +   mkdir -p debian/tmp-$(curpass)/usr/include/$(DEB_HOST_MULTIARCH); \
| +   mv debian/tmp-$(curpass)/usr/include/bits 
debian/tmp-$(curpass)/usr/include/$(DEB_HOST_MULTIARCH); \
| +   mv debian/tmp-$(curpass)/usr/include/gnu 
debian/tmp-$(curpass)/usr/include/$(DEB_HOST_MULTIARCH); \
| +   mv debian/tmp-$(curpass)/usr/include/sys 
debian/tmp-$(curpass)/usr/include/$(DEB_HOST_MULTIARCH); \
| +   mv debian/tmp-$(curpass)/usr/include/fpu_control.h 
debian/tmp-$(curpass)/usr/include/$(DEB_HOST_MULTIARCH); \
| +   mv debian/tmp-$(curpass)/usr/include/a.out.h 
debian/tmp-$(curpass)/usr/include/$(DEB_HOST_MULTIARCH); \
| +   mv debian/tmp-$(curpass)/usr/include/ieee754.h 
debian/tmp-$(curpass)/usr/include/$(DEB_HOST_MULTIARCH); \
| + fi

I would appreciate an explanation on what problem this hunk solves.

|  else
|   : # FIXME: why just needed for ARM multilib?
|   case "$(curpass)" in \
| diff -urN debian/rules.d/debhelper.mk 
/usr/src/glibc/debian/rules.d/debhelper.mk
| --- debian/rules.d/debhelper.mk   2015-03-19 22:15:39.0 +
| +++ /usr/src/glibc/debian/rules.d/debhelper.mk2015-05-10 
12:12:25.937141495 +
| @@ -109,7 +109,8 @@
|   ./debian/shlibs-add-udebs $(curpass)
|  
|   dh_installdeb -p$(curpass)
| - dh_shlibdeps -p$(curpass)
| + [ -n "$$(echo $(curpass) | grep 'mips32')" ] && 
o32_libs="-l$(CURDIR)/debian/$(curpass)/libo32/"; \
| +dh_shlibdeps $$o32_libs  -p$(curpass)

Why does this special case mips32? Would it be possible to solve this
issue for more architectures by relying on slibdir instead?

|   dh_gencontrol -p$(curpass)
|   if [ $(curpass) = nscd ] ; then \
|   sed -i -e "s/\(Depends:.*libc[0-9.]\+\)-[a-z0-9]\+/\1/" 
debian/nscd/DEBIAN/control ; \
| @@ -179,7 +180,7 @@
|  
|   # Generate common substvars files.
|   : > tmp.substvars
| -ifeq ($(filter stage2,$(DEB_BUILD_PROFILES)),)
| +ifeq ($(filter stage1 stage2,$(DEB_BUILD_PROFILES)),)
|   echo 'libgcc:Depends=libgcc1 [!hppa !m68k], libgcc2 [m68k], libgcc4 
[hppa]' >> tmp.substvars
|  endif

The gcc stage2 (which can be built with glibc stage1 packages) includes
libgccN packages. Thus the dependency is satisfiable in stage2. Dropping
it here should not be necessary and I think it also is wrong.

|  
| @@ -197,9 +198,20 @@
|   slibdir=$(call xx,slibdir) ; \
|   rtlddir=$(call xx,rtlddir) ; \
|   curpass=$(curpass) ; \
| - templates="libc-dev" ;\
| - pass="" ; \
| - suffix="" ;\
| + templates="libc-dev" ; \
| + case "$$curpass:$$slibdir" in \
| +   libc:*) \
| + suffix="" \
| + pass="" \
| + 

Bug#797831: glibc: further problems with stage1

2015-09-08 Thread Helmut Grohne
Hi Aurelien,

On Tue, Sep 08, 2015 at 07:58:13PM +0200, Aurelien Jarno wrote:
> Thanks for the patch and the detailed explanation. The changes make sense,
> so I have applied the patch.

Thank you.

> That said looking as this part of the code as a whole, it ends up being a
> bit complicated. Basically we define defaults value before the case, but
> then we basically handle all cases. Then we use a for loop as a if, as
> $templates contains either zero or one value.

I concur with that observation.

> The complexity comes from the fact this piece of code has been forked from
> the non-staged one. I therefore wonder if we should try to either:
> 1) Simplify it.
> 2) make it as common as possible with the non-stage code. I believe it's
> not a problem if we generate debhelper files that we don't use in
> practice, as long as the stage ones are correct.

Maybe we should try 3) merge it into the non-stage code? Having these
two cases separate has the disadvantage that they will go out of sync as
the non-staged variant is adapted to the current needs. We should strive
for minimal differences in stage1 to minimize its maintenance cost.

So what actually is the difference between these two implementations of
the debhelper-common target? If I am not mistaken it is:
 * Generate fewer debhelper templates. As you observed there is no harm
   in just generating them anyway.
 * Interpolate more variables, in particular RTLD_SO. They are not used
   in the libc-dev templates. The computation of the shell variable
   rtld_so would probably result in garbage as
   debian/tmp-*/usr/bin/iconv will be missing, but maybe it still
   succeeds (from an exit code pov).
 * Remove lines containing LIBDIR in stage1. Unless I am missing
   something, this is the only relevant difference.

So maybe one could have something along the lines.

ifeq ($(filter stage1,$(DEB_BUILD_PROFILES)),)
STAGE1_TEMPLATE_FILTER=
else
STAGE1_TEMPLATE_FILTER=sed -e "/LIBDIR.*\.a /d" $$t
fi

and then add "$(STAGE1_TEMPLATE_FILTER);" to the pile of sed invocations
in the non-stage1 code path while eliminating the stage1 block
altogether. Do you think this idea would be worth trying and preparing a
proper patch? Do you have a better name for that strange make variable?

Helmut



Bug#798064: glibc: please find kfreebsd-kernel-headers in multiarch path

2015-09-05 Thread Helmut Grohne
Hi Steven,

On Sat, Sep 05, 2015 at 01:50:02AM +0100, Steven Chamberlain wrote:
> We're hoping to move kfreebsd-kernel-headers' files to multiarch
> path /usr/include/$(DEB_TARGET_MULTIARCH), so that headers of other
> kernels are co-installable on a build machine (for cross-building and
> bootstrapping).

Thanks for doing that work!

> Please could glibc be patched as attached, to always look in that
> directory for system includes, even for native builds (HOST==BUILD).

I'm not quite sure how much backwards compatibility we need here and
your patch probably breaks that. In former times (before multiarch based
cross building) cross libraries were installed in a sysroot, typically
/usr/$(DEB_HOST_GNU_TYPE). The package dpkg-cross was used to convert
regular :$(DEB_HOST_ARCH) packages to -$(DEB_HOST_ARCH)-cross:all
packages and convert the paths in the same way. (In
jenkins.d.n/view/rebootstrap this method is called "supported", because
it is the only way supported by the gcc maintainers.)

So maybe we could find a way that works for both the "dpkg-cross" way
(at least in theory) and the multiarch way.

For linux this is not sorted out either yet. The relevant code here is
in debian/sysdeps/linux.mk:
|   ifeq ($(DEB_HOST_GNU_TYPE),$(DEB_BUILD_GNU_TYPE))
| LINUX_HEADERS := /usr/include
|   else
| LINUX_HEADERS := /usr/$(DEB_HOST_GNU_TYPE)/include
|   endif
|   LINUX_ARCH_HEADERS := /usr/include/$(DEB_HOST_MULTIARCH)

The patch in bug #773300 (which is mostly obsolete due to merging
#766877), suggests to change this ifeq to the following line.

|   ifeq ($(shell dpkg-query --status linux-libc-dev-$(DEB_HOST_ARCH)-cross 
2>/dev/null),)

It might make sense to do something similar for kfreebsd, but I was
still wondering whether this particular test method works in all
relevant cases.

Aurelien, I shall follow up to #773300 again and explain what parts of
that bug are still applicable.

> -  ifeq ($(DEB_HOST_GNU_TYPE),$(DEB_BUILD_GNU_TYPE))
> -KFREEBSD_HEADERS := /usr/include
> -  else
> -KFREEBSD_HEADERS := /usr/$(DEB_HOST_GNU_TYPE)/include
> -  endif
> +  KFREEBSD_HEADERS := /usr/include/$(DEB_TARGET_MULTIARCH)

Using target variables is wrong here. It might work (because target
defaults to host), but it doesn't make sense semantically. This must be
DEB_HOST_MULTIARCH here. Target variables are only relevant for
compilers, but glibc isn't a compiler.

Helmut



Bug#797831: glibc: further problems with stage1

2015-09-02 Thread Helmut Grohne
Source: glibc
Version: 2.21-0experimental1
Tags: patch
User: helm...@debian.org
Usertags: rebootstrap

Hi Aurelien,

thank you very much for applying #766877 and uploading to experimental.
This has moved us a big step closer to a working stage1. We are not
quite there yet. At this point I estimate a remaining patch stack for
the following problems:

 * stage1 fails to build for various reasons
 * stage1 libc6-dev not installable due to dependency on libc6
 * wrong set of packages being built for stage1
 * dh_shlibdeps fails
 * linux headers cannot be found
 * various hurd things

Even though I still carry patches for these, it is not clear that all of
these problems are still reproducible. The above list is meant as an
outlook, not a cumulative bug report.

This particular bug shall address only the first of those problems
above, because I have a good understanding and can answer your
questions. I am attaching a patch and also explain the individual hunks
in what follows. All of them apply to stage1-specific code.

- *:/lib32 | *:/lib64 | *:/libx32 | *:/lib/arm-linux-gnueabi*) \
+ *:/lib32 | *:/lib64 | *:/libo32 | *:/libx32 | 
*:/lib/arm-linux-gnueabi*) \

The code fails to identify a certain mips architecture multilib build
and thus places the multilib build into the main package.

+ *:* ) \
+   templates="" \
+   ;; \

This extra case ensures that no templates are interpolated for optimized
builds (e.g. libc6-i686). These do not generate development packages
anyway, so dropping them (for stage1) is the right thing to do. Failing
to do so again overwrites the main package.

-   -e "/$$libdir.*.a /d" \
+   -e "/LIBDIR.*\.a /d" \

The immediate error resulting from this sed invocation is that the
command "u" is not understood by sed. $libdir becomes
"/usr/lib/triplet".  Thus the resulting sed command starts with "//u"
which sed does not like. Fixing the escaping is not enough however,
since LIBDIR is not yet interpolated. That only happens a few lines
later. So instead, the match needs to target non-interpolated filenames
and thus match LIBDIR.

I hope that the level of detail given is sufficient. If not, please ask.
Otherwise, please consider applying the patch. I would appreciate
another experimental upload that also includes the hurd changes staged
to SVN by Samuel Thibault already within a month from now. Thank you for
your support.

Helmut
diff -Nru glibc-2.19/debian/rules.d/debhelper.mk glibc-2.19/debian/rules.d/debhelper.mk
--- glibc-2.19/debian/rules.d/debhelper.mk
+++ glibc-2.19/debian/rules.d/debhelper.mk
@@ -197,10 +197,13 @@
 	case "$$curpass:$$slibdir" in \
 	  libc:*) \
 	;; \
-	  *:/lib32 | *:/lib64 | *:/libx32 | *:/lib/arm-linux-gnueabi*) \
+	  *:/lib32 | *:/lib64 | *:/libo32 | *:/libx32 | *:/lib/arm-linux-gnueabi*) \
 	pass="-alt" \
 	suffix="-$(curpass)" \
 	;; \
+	  *:* ) \
+   templates="" \
+	;; \
 	esac ; \
 	for t in $$templates ; do \
 	  for s in debian/$$t$$pass.* ; do \
@@ -219,7 +219,7 @@
 	  cp $$s $$t ; \
 	fi ; \
 	sed -i \
-		-e "/$$libdir.*.a /d" \
+		-e "/LIBDIR.*\.a /d" \
 		-e "s#TMPDIR#debian/tmp-$$curpass#g" \
 		-e "s#RTLDDIR#$$rtlddir#g" \
 		-e "s#SLIBDIR#$$slibdir#g" \


Re: Bug#787227: broken on armel due to broken RUNPATH: /usr/lib/ghc/bin/ghc: error while loading shared libraries: libHShaskeline-0.7.1.2-ghc7.8.4.so: cannot open shared object file: No such file or d

2015-05-30 Thread Helmut Grohne
Control: severity -1 wishlist
Control: reassign -1 libc6
Control: retitle -1 ld-linux.so loads libraries from . when /proc is not mounted
Control: affects -1 + ghc
Control: summary -1 0

When /proc is not mounted, a relative RPATH causes ld-linux.so to fall
back to using the working directory as the base directory for RPATH
resolution instead of using the (unknown) location of the executed
binary. This issue is hard to diagnose, because the error message does
not make it clear that fallback code is in use due to readlink
/proc/self/exe failing. Furthermore, it may pose a security risk by
loading libraries from unintended locations.

On Sat, May 30, 2015 at 11:54:26AM -0400, Joey Hess wrote:
 Sorry, I meant the linker should be fixed, not ghc.

Let's codify that in the bts.

Steps to reproduce (for glibc maintainers):

Create an unstable chroot. Install ghc. Do not mount /proc in that
chroot. Execute /usr/bin/ghc. You shall see that it fails loading
libraries.

I assume that any binary with a relative RPATH is affected.

Helmut


-- 
To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20150530165603.ga7...@alf.mars



Bug#784015: undeclared file conflict between libc6-i386 and libc6-mipsn32

2015-05-02 Thread Helmut Grohne
Package: libc6-i386,libc6-mipsn32
Version: 2.19-18
User: helm...@debian.org
Usertags: rebootstrap

| dpkg: error processing archive 
/tmp/repo/pool/main/g/glibc/libc6-mipsn32_2.19-18_mips.deb (--unpack):
|  trying to overwrite '/usr/lib32/gconv/ANSI_X3.110.so', which is also in 
package libc6-i386 2.19-18

I am filing this as a new bug report instead of merging it into #745552,
because I believe that this instance is easily fixable.

It should be possible to have the multilib packages with matching
multilib directories declare conflicts against each other as no M-A:same
is involved here.

The loader conflict issue shall remain with #745552.

Helmut


-- 
To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20150502063742.ga17...@alf.mars



Bug#766877: Fix multilib enabled stage1 cross builds

2015-04-30 Thread Helmut Grohne
On Tue, Dec 16, 2014 at 08:51:44PM +0100, Helmut Grohne wrote:
 Matthias patch does not work for architectures with optimized libcs
 (called otherarch in glibc packaging, i.e. i386, mipsel, alpha).

Matthias asked to clarify my stance on this patch. The above says that
the patch does not work for architectures with optimized libcs. What it
doesn't say there is that the patch goes a long way to fix architectures
without optimized libcs. It thus presents a good basis for further work
on the bootstrap problem. I would like to see that patch merged.

To be serious, the reason for me having stopped sending glibc patches is
that this essential patch still has not been merged.

Helmut


-- 
To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20150430150247.ga25...@alf.mars



Bug#780431: 2.19-16 breaks stage2 build

2015-03-13 Thread Helmut Grohne
Package: src:glibc
Version: 2.19-16
Tags: patch
User: helm...@debian.org
Usertags: rebootstrap

The glibc 2.19-16 upload regresses the stage2 build. The regression is
introudced in svn revision 6371 in debian/rules.d/debhelper.mk where
tmp.substvars is no longer generated for stage2. The build fails a few
lines later trying to copy tmp.substvars:

| cp: cannot stat 'tmp.substvars': No such file or directory

I verified that the attached patch solves the issue.

Adam Conrad committed a similar fix as svn revision 6376.

Helmut


-- 
To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20150313203600.ga31...@alf.mars



Bug#780431: 2.19-16 breaks stage2 build

2015-03-13 Thread Helmut Grohne
On Fri, Mar 13, 2015 at 09:36:01PM +0100, Helmut Grohne wrote:
 I verified that the attached patch solves the issue.

As Adam pointed out, my patch was missing. Sorry.

But it really is equivalent to what is already in SVN. So this mostly is
a confirmation.

Helmut
diff -Nru glibc-2.19/debian/changelog glibc-2.19/debian/changelog
--- glibc-2.19/debian/changelog 2015-03-12 22:00:48.0 +0100
+++ glibc-2.19/debian/changelog 2015-03-13 20:16:44.0 +0100
@@ -1,3 +1,10 @@
+glibc (2.19-16.1) UNRELEASED; urgency=low
+
+  * Non-maintainer upload.
+  * Unbreak stage2 build. (Closes: #-1)
+
+ -- Helmut Grohne hel...@subdivi.de  Fri, 13 Mar 2015 20:16:06 +0100
+
 glibc (2.19-16) unstable; urgency=medium
 
   [ Samuel Thibault ]
diff -Nru glibc-2.19/debian/rules.d/debhelper.mk 
glibc-2.19/debian/rules.d/debhelper.mk
--- glibc-2.19/debian/rules.d/debhelper.mk  2015-03-08 22:29:32.0 
+0100
+++ glibc-2.19/debian/rules.d/debhelper.mk  2015-03-13 20:16:03.0 
+0100
@@ -180,6 +180,8 @@
# Generate common substvars files.
 ifeq ($(filter stage2,$(DEB_BUILD_PROFILES)),)
echo 'libgcc:Depends=libgcc1 [!hppa !m68k], libgcc2 [m68k], libgcc4 
[hppa]'  tmp.substvars
+else
+   touch tmp.substvars
 endif
 
for pkg in $(DEB_ARCH_REGULAR_PACKAGES) $(DEB_INDEP_REGULAR_PACKAGES) 
$(DEB_UDEB_PACKAGES); do \


Bug#759530: CPU info?

2015-01-10 Thread Helmut Grohne
On Thu, Jan 01, 2015 at 10:09:58PM +0100, Yves-Alexis Perez wrote:
 I'm not experiencing that bug, but maybe it'd help if the submitters
 would provide their /proc/cpuinfo and maybe try to get a clue about
 where the segfault happens (maybe with coredumps)?

/proc/cpuinfo from Bernd Zeimetz (he was reporting segfaults as well):

processor   : 3
vendor_id   : GenuineIntel
cpu family  : 6
model   : 42
model name  : Intel(R) Core(TM) i5-2520M CPU @ 2.50GHz
stepping: 7
microcode   : 0x29
cpu MHz : 813.769
cache size  : 3072 KB
physical id : 0
siblings: 4
core id : 1
cpu cores   : 2
apicid  : 3
initial apicid  : 3
fpu : yes
fpu_exception   : yes
cpuid level : 13
wp  : yes
flags   : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov 
pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx rdtscp lm 
constant_tsc arch_perfmon pebs bts nopl xtopology nonstop_tsc aperfmperf 
eagerfpu pni pclmulqdq dtes64 monitor ds_cpl vmx smx est tm2 ssse3 cx16 xtpr 
pdcm pcid sse4_1 sse4_2 x2apic popcnt tsc_deadline_timer aes xsave avx lahf_lm 
ida arat epb xsaveopt pln pts dtherm tpr_shadow vnmi flexpriority ept vpid
bogomips: 4983.78
clflush size: 64
cache_alignment : 64
address sizes   : 36 bits physical, 48 bits virtual
power management:

Helmut


-- 
To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20150110201323.ga2...@alf.mars



Bug#773300: Improve glibc bootstrap

2014-12-16 Thread Helmut Grohne
On Tue, Dec 16, 2014 at 11:39:40PM +0800, YunQiang Su wrote:
 Hi, the attached patch can improve bootstrapping of glibc.

Partially, this seems to be a duplicate of #766877. Maybe these should
be merged?

 It produces the similiar stage1 glibc
 (libc6/libc6-dev and multilib version of them),
 at the same time, the dependencies of them are also correct.

The documentation and rationale of this patch are scarce. I have a few
comments on individual hunks though.

diff -Nru glibc-2.19/debian/rules glibc-2.19/debian/rules
--- glibc-2.19/debian/rules 2014-10-17 07:43:19.0 +
+++ glibc-2.19/debian/rules 2014-12-10 23:16:28.0 +
@@ -143,8 +143,12 @@
 endif
 endif
 
+ifeq ($(DEB_STAGE),stage2)
+  DEB_BUILD_PROFILES+=stage2
+endif
+
 ifneq ($(filter stage1,$(DEB_BUILD_PROFILES)),)
-  DEB_ARCH_REGULAR_PACKAGES = $(libc)-dev
+  DEB_ARCH_REGULAR_PACKAGES = $(libc)-dev $(libc)
   DEB_INDEP_REGULAR_PACKAGES = 
   DEB_UDEB_PACKAGES = 
 else

I have no clue how one would build the libc in stage1. The gcc stage1
does not provide the means for doing so. If anything those packages
would be empty. I.e. this seems rather wrong to me.

diff -Nru glibc-2.19/debian/sysdeps/linux.mk glibc-2.19/debian/sysdeps/linux.mk
--- glibc-2.19/debian/sysdeps/linux.mk  2014-07-16 18:43:31.0 +
+++ glibc-2.19/debian/sysdeps/linux.mk  2014-12-10 23:11:05.0 +
@@ -16,11 +16,7 @@
 endif
 
 ifndef LINUX_SOURCE
-  ifeq ($(DEB_HOST_GNU_TYPE),$(DEB_BUILD_GNU_TYPE))
-LINUX_HEADERS := /usr/include
-  else
-LINUX_HEADERS := /usr/$(DEB_HOST_GNU_TYPE)/include
-  endif
+  LINUX_HEADERS := /usr/include
   LINUX_ARCH_HEADERS := /usr/include/$(DEB_HOST_MULTIARCH)
 else
   LINUX_HEADERS := $(LINUX_SOURCE)/include

This breaks the supported cross build method.

diff -Nru glibc-2.19/debian/sysdeps/mips64.mk 
glibc-2.19/debian/sysdeps/mips64.mk
--- glibc-2.19/debian/sysdeps/mips64.mk 2014-10-17 07:43:19.0 +
+++ glibc-2.19/debian/sysdeps/mips64.mk 2014-12-11 03:50:09.0 +
@@ -59,5 +59,5 @@
 # create a symlink for the 32 bit dynamic linker in /lib
 define libc6-mips32_extra_pkg_install
 mkdir -p debian/libc6-mips32/lib
-ln -sf /libo32/ld.so.1 debian/libc6-mips32/lib
+ln -sf ../libo32/ld.so.1 debian/libc6-mips32/lib
 endef

This violates a should in Debian policy section 10.5.

Helmut


-- 
To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20141216191023.ga13...@alf.mars



Bug#766877: Fix multilib enabled stage1 cross builds

2014-12-16 Thread Helmut Grohne
Control: user helm...@debian.org
Control: usertags -1 + rebootstrap

On Sun, Oct 26, 2014 at 02:23:07PM +0100, Matthias Klose wrote:
 The patch fixes building multilib enabled stage1 cross, by doing the call xx
 dance for stage1 as well, as well as generating the debhelper files for 
 multilib
 stage1 packages.

Matthias patch does not work for architectures with optimized libcs
(called otherarch in glibc packaging, i.e. i386, mipsel, alpha).

Quoting the commit message of
http://anonscm.debian.org/cgit/users/helmutg/rebootstrap.git/commit/?id=b462ceb
for details:

| attempt at fixing glibc multilib stage1 builds
| 
| Currently for mipsel libc6-dev and libc6-dev-mips64 (stage1) are not
| coinstallable, because they have an undeclared file conflict in
| /usr/include/sys. Since libc6-dev is multiarch, it shouldn't contain
| that directory but use something below /usr/include/triplet.
| 
| The cause is the debhelper tooling affected by the patch below. It is
| run for each $curpass, where in case of mipsel passes include libc,
| mips64 and loongson2f. The last one is interesting, because it is not
| covered by either existing cases. In the non-stage1 variant of this
| code, it is classified as a pass=-otherbuild. Since we don't change
| templates or pass for loongson2f, the snippet overwrites the debhelper
| .install files for libc causing the libc6-dev package to contain the
| headers for loongson2f (in non-multiarch locations). So the non-stage1
| restricts templates to just libc for otherbuild. Since stage1 restricts
| templates to libc-dev, the intersection for stage1 and otherbuild is
| empty.
| 
| Arguably, the loongson2f pass should be skipped in stage1 entirely.
| 
| This bug should break any architecture with optimized libc packages:
|  * mipsel - loongon2f
|  * i386 - 686 (breaks in gcc earlier atm)
|  * alpha - alphaev67 (libc6.1-dev and libc6-dev conflict already)

Helmut


-- 
To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20141216195143.ga15...@alf.mars



Bug#756473: src:glibc: install multilib stubs-$abi.h when bootstrapping

2014-07-30 Thread Helmut Grohne
Package: src:glibc
Version: 2.19-7
Severity: wishlist
Tags: patch
User: helm...@debian.org
Usertags: rebootstrap

While attempting to do multilib glibc stage1 cross builds, i noticed
that certain libc*-dev-*_extra_pkg_install defines from
debian/sysdeps/*.mk would fail to install absent
debian/tmp-*/usr/include/gnu/stubs-*.h files. 

I dug into the reasons and discovered that Ubuntu's eglibc patch (in its
*-cross-toolchain-base packages) would just touch the missing files.
While this appears to work, I believe that it is the wrong solution,
because it adds cruft. Rather, I suggest to update the place that
handles them: debian/patches/any/local-bootstrap-headers.diff

Looking at that patch one can see that it predates multilib as it only
handles the main stubs.h, but doesn't handle the stubs-$abi.h headers.
To that end, I am proposing to update said patch rather than papering
over its deficiencies. This should keep the packaging simpler.

Please consider the attached patch.

Helmut
diff -Nru glibc-2.19/debian/changelog glibc-2.19/debian/changelog
--- glibc-2.19/debian/changelog 2014-07-13 01:31:22.0 +0200
+++ glibc-2.19/debian/changelog 2014-07-30 09:29:34.0 +0200
@@ -1,3 +1,11 @@
+glibc (2.19-7.1) UNRELEASED; urgency=low
+
+  * Non-maintainer upload.
+  * debian/patches/any/local-bootstrap-headers.diff: Update to handle
+stubs-$abi.h which is required for multilib bootstraps. (Closes: #-1)
+
+ -- Helmut Grohne hel...@subdivi.de  Wed, 30 Jul 2014 09:28:26 +0200
+
 glibc (2.19-7) unstable; urgency=high
 
   * debian/patches/localedata/unsubmitted-tst-setlocale3-ENV.diff: Apply
diff -Nru glibc-2.19/debian/patches/any/local-bootstrap-headers.diff 
glibc-2.19/debian/patches/any/local-bootstrap-headers.diff
--- glibc-2.19/debian/patches/any/local-bootstrap-headers.diff  2014-07-06 
10:13:13.0 +0200
+++ glibc-2.19/debian/patches/any/local-bootstrap-headers.diff  2014-07-30 
09:28:22.0 +0200
@@ -1,5 +1,11 @@
 Taken from EGLIBC, r1484 + r1525
 
+2014-07-30  Helmut Grohne hel...@subdivi.de
+
+   * With the advent of multilib gnu/stubs.h became a meta-header that
+   includes the correct stubs-$abi.h. So install gnu/stubs.h as usual
+   and install stubs-bootstrap.h as gnu/stubs-$abi.h
+
 2007-02-20  Jim Blandy  j...@codesourcery.com
 
* Makefile (install-headers): Preserve old behavior: depend on
@@ -33,48 +39,40 @@
 +   an empty stubs.h like this will do fine for GCC.  */
 --- a/Makefile
 +++ b/Makefile
-@@ -68,9 +68,18 @@
- vpath %.h $(subdir-dirs)
- 
- # What to install.
--install-others = $(inst_includedir)/gnu/stubs.h
- install-bin-script =
+@@ -177,6 +177,13 @@
+ install-others-nosubdir: $(installed-stubs)
+ endif
  
 +# If we're bootstrapping, install a dummy gnu/stubs.h along with the
 +# other headers, so 'make install-headers' produces a useable include
 +# tree.  Otherwise, install gnu/stubs.h later, after the rest of the
 +# build is done.
 +ifeq ($(install-bootstrap-headers),yes)
-+install-headers: $(inst_includedir)/gnu/stubs.h
-+else
-+install-others = $(inst_includedir)/gnu/stubs.h
++install-headers: $(inst_includedir)/gnu/stubs.h $(installed-stubs)
 +endif
-+
- ifeq (yes,$(build-shared))
- headers += gnu/lib-names.h
- endif
-@@ -150,6 +159,16 @@
- 
- subdir-stubs := $(foreach dir,$(subdirs),$(common-objpfx)$(dir)/stubs)
  
+ # Since stubs.h is never needed when building the library, we simplify the
+ # hairy installation process by producing it in place only as the last part
+@@ -184,6 +191,14 @@
+ # iterates over all the subdirs; subdir_install in each subdir depends on
+ # the subdir's stubs file.  Having more direct dependencies would result in
+ # extra iterations over the list for subdirs and many recursive makes.
++ifeq ($(install-bootstrap-headers),yes)
 +# gnu/stubs.h depends (via the subdir 'stubs' targets) on all the .o
 +# files in GLIBC.  For bootstrapping a GCC/GLIBC pair, an empty
 +# gnu/stubs.h is good enough.
-+ifeq ($(install-bootstrap-headers),yes)
-+$(inst_includedir)/gnu/stubs.h: include/stubs-bootstrap.h $(+force)
++$(installed-stubs): include/stubs-bootstrap.h $(+force)
 +  $(make-target-directory)
 +  $(INSTALL_DATA) $ $@
-+
-+installed-stubs =
 +else
- ifndef abi-variants
- installed-stubs = $(inst_includedir)/gnu/stubs.h
- else
-@@ -176,6 +195,7 @@
- 
- install-others-nosubdir: $(installed-stubs)
- endif
+ $(installed-stubs): include/stubs-prologue.h subdir_install
+   $(make-target-directory)
+   @rm -f $(objpfx)stubs.h
+@@ -192,6 +207,7 @@
+   then echo 'stubs.h unchanged'; \
+   else $(INSTALL_DATA) $(objpfx)stubs.h $@; fi
+   rm -f $(objpfx)stubs.h
 +endif
- 
- 
- # Since stubs.h is never needed when building the library, we simplify the
+ 
+ # This makes the Info or DVI file of the documentation from the Texinfo 
source.
+ .PHONY: info dvi pdf html


Bug#756095: src:glibc: application of debian/patches/ia64/local-rtld-compile-options.diff fails

2014-07-26 Thread Helmut Grohne
Package: src:glibc
Version: 2.19-7
Severity: normal
Tags: patch
User: helm...@debian.org
Usertags: rebootstrap

Building of glibc for ia64 fails in application of patch
debian/patches/ia64/local-rtld-compile-options.diff.

I am attaching a patch that fixes the above patch. Note that my patch
will not make ia64 build, because it then fails in conifgure:

| checking for forced unwind support... no
| configure: error: forced unwind support is required

This bug is only about the patch application part though.

Helmut
diff -Nru glibc-2.19/debian/changelog glibc-2.19/debian/changelog
--- glibc-2.19/debian/changelog 2014-07-13 01:31:22.0 +0200
+++ glibc-2.19/debian/changelog 2014-07-26 07:41:47.0 +0200
@@ -1,3 +1,11 @@
+glibc (2.19-7.1) UNRELEASED; urgency=low
+
+  * Non-maintainer upload.
+  * Fix application of debian/patches/ia64/local-rtld-compile-options.diff.
+(Closes: #-1)
+
+ -- Helmut Grohne hel...@subdivi.de  Sat, 26 Jul 2014 07:41:10 +0200
+
 glibc (2.19-7) unstable; urgency=high
 
   * debian/patches/localedata/unsubmitted-tst-setlocale3-ENV.diff: Apply
diff -Nru glibc-2.19/debian/patches/ia64/local-rtld-compile-options.diff 
glibc-2.19/debian/patches/ia64/local-rtld-compile-options.diff
--- glibc-2.19/debian/patches/ia64/local-rtld-compile-options.diff  
2013-12-08 11:40:29.0 +0100
+++ glibc-2.19/debian/patches/ia64/local-rtld-compile-options.diff  
2014-07-26 07:41:03.0 +0200
@@ -6,8 +6,8 @@
-D'SLIBDIR=$(slibdir)' -DIS_IN_ldconfig=1
  CFLAGS-dl-cache.c = $(SYSCONF-FLAGS)
  CFLAGS-cache.c = $(SYSCONF-FLAGS)
--CFLAGS-rtld.c = $(SYSCONF-FLAGS)
-+CFLAGS-rtld.c = $(SYSCONF-FLAGS) -O1 -fno-tree-copy-prop 
-fno-tree-dominator-opts -fno-tree-ccp
+-CFLAGS-rtld.c += $(SYSCONF-FLAGS)
++CFLAGS-rtld.c += $(SYSCONF-FLAGS) -O1 -fno-tree-copy-prop 
-fno-tree-dominator-opts -fno-tree-ccp
  
  CPPFLAGS-.os += $(if $(filter $(@F),$(patsubst %,%.os,$(all-rtld-routines))),\
 -DNOT_IN_libc=1 -DIS_IN_rtld=1 -DIN_LIB=rtld)


Bug#755580: src:glibc: drop libgcc dependency from stage2 builds

2014-07-22 Thread Helmut Grohne
Package: src:glibc
Version: 2.19-7
Severity: wishlist
Tags: patch
User: helm...@debian.org
Usertags: rebootstrap

Even if one manages to build glibc with profiles stage1 or stage2, the
results are not installable due to unmet dependencies. The following
issues occur:

 * stage1 libc6-dev Depends on libc6 which is not built in stage1
 * stage2 libc6 Depends on libgcc1 which is not built by gcc stage2

This bug shall only cover the second (easier) part and I shall report a
different bug for the first issue at a later time.

When we briefly discussed this issue, there was consensus that substvars
would be the tool to address it. So the attached patch turns those
libgcc dependencies into ${libgcc:Depends} and suppresses them for
stage2. It's a bit unfortunate that dependency information keeps
scattering over control and rules.d/debhelper.mk, but I didn't find a
better way.

Helmut
diff -Nru glibc-2.19/debian/changelog glibc-2.19/debian/changelog
--- glibc-2.19/debian/changelog 2014-07-13 01:31:22.0 +0200
+++ glibc-2.19/debian/changelog 2014-07-20 22:07:19.0 +0200
@@ -1,3 +1,10 @@
+glibc (2.19-7.1) UNRELEASED; urgency=low
+
+  * Non-maintainer upload.
+  * Don't emit dependencies on libgcc when building stage2. (Closes: #-1)
+
+ -- Helmut Grohne hel...@subdivi.de  Sun, 20 Jul 2014 22:06:57 +0200
+
 glibc (2.19-7) unstable; urgency=high
 
   * debian/patches/localedata/unsubmitted-tst-setlocale3-ENV.diff: Apply
diff -Nru glibc-2.19/debian/control.in/libc glibc-2.19/debian/control.in/libc
--- glibc-2.19/debian/control.in/libc   2014-06-27 04:28:51.0 +0200
+++ glibc-2.19/debian/control.in/libc   2014-07-20 22:09:20.0 +0200
@@ -3,7 +3,7 @@
 Section: libs
 Priority: required
 Multi-Arch: same
-Depends: ${shlibs:Depends}, libgcc1 [!hppa !m68k], libgcc2 [m68k], libgcc4 
[hppa]
+Depends: ${shlibs:Depends}, ${libgcc:Depends}
 Recommends: libc6-i686 [i386], libc0.1-i686 [kfreebsd-i386], libc0.3-i686 
[hurd-i386] 
 Suggests: glibc-doc, debconf | debconf-2.0, locales [!hurd-i386]
 Provides: ${locale-compat:Depends}, libc6-sparcv9b [sparc sparc64]
diff -Nru glibc-2.19/debian/rules.d/debhelper.mk 
glibc-2.19/debian/rules.d/debhelper.mk
--- glibc-2.19/debian/rules.d/debhelper.mk  2014-07-10 21:49:24.0 
+0200
+++ glibc-2.19/debian/rules.d/debhelper.mk  2014-07-20 22:08:45.0 
+0200
@@ -180,6 +180,9 @@
# Generate common substvars files.
echo locale:Depends=$(shell perl debian/debver2localesdep.pl 
$(LOCALES_DEP_VER))  tmp.substvars
echo locale-compat:Depends=$(shell perl debian/debver2localesdep.pl 
$(LOCALES_COMPAT_VER))  tmp.substvars
+ifeq ($(filter stage2,$(DEB_BUILD_PROFILES)),)
+   echo 'libgcc:Depends=libgcc1 [!hppa !m68k], libgcc2 [m68k], libgcc4 
[hppa]'  tmp.substvars
+endif
 
for pkg in $(DEB_ARCH_REGULAR_PACKAGES) $(DEB_INDEP_REGULAR_PACKAGES) 
$(DEB_UDEB_PACKAGES); do \
  cp tmp.substvars debian/$$pkg.substvars; \


Bug#745380: src:eglibc: support non-multilib builds

2014-07-20 Thread Helmut Grohne
On Mon, Apr 21, 2014 at 07:58:51AM +0200, Helmut Grohne wrote:
 Please consider the attached patch to achieve this goal.

Please find an updated patch attached. Changes since last version:

 * Add Build-Profiles headers to binary packages.
 * Don't treat optimized packages (e.g. i686) as multilib (thanks to
   Aurelien Jarno).
 * Introduce GLIBC_MULTILIB_PASSES to work the same way as
   DEB_ARCH_MULTILIB_PACKAGES (thanks to Aurelien Jarno).
 * Support new architectures (mips*).

Helmut
diff -Nru glibc-2.19/debian/changelog glibc-2.19/debian/changelog
--- glibc-2.19/debian/changelog 2014-07-13 01:31:22.0 +0200
+++ glibc-2.19/debian/changelog 2014-07-19 07:38:01.0 +0200
@@ -1,3 +1,11 @@
+glibc (2.19-7.1) UNRELEASED; urgency=low
+
+  * Non-maintainer upload.
+  * Add a nobiarch build profile that inhibits all multilib packages from
+being built. (Closes: #745380)
+
+ -- Helmut Grohne hel...@subdivi.de  Sat, 19 Jul 2014 07:37:22 +0200
+
 glibc (2.19-7) unstable; urgency=high
 
   * debian/patches/localedata/unsubmitted-tst-setlocale3-ENV.diff: Apply
diff -Nru glibc-2.19/debian/control.in/amd64 glibc-2.19/debian/control.in/amd64
--- glibc-2.19/debian/control.in/amd64  2014-06-27 04:28:51.0 +0200
+++ glibc-2.19/debian/control.in/amd64  2014-07-19 07:53:34.0 +0200
@@ -4,7 +4,7 @@
 Priority: optional
 Depends: libc6 (= ${binary:Version}), ${misc:Depends}
 Conflicts: amd64-libs (= 1.2)
-Build-Profiles: !stage1
+Build-Profiles: !stage1 !nobiarch
 Description: GNU C Library: 64bit Shared libraries for AMD64
  This package includes shared versions of the standard C library and the
  standard math library, as well as many others. This is the 64bit version
@@ -19,6 +19,7 @@
 Conflicts: libc6-dev ( 2.13-14)
 Replaces: amd64-libs-dev (= 1.2), libc6-dev ( 2.13-11)
 Provides: lib64c-dev
+Build-Profiles: !nobiarch
 Description: GNU C Library: 64bit Development Libraries for AMD64
  Contains the symlinks and object files needed to compile and link programs
  which use the standard C library. This is the 64bit version of the
diff -Nru glibc-2.19/debian/control.in/armel glibc-2.19/debian/control.in/armel
--- glibc-2.19/debian/control.in/armel  2014-06-27 04:28:51.0 +0200
+++ glibc-2.19/debian/control.in/armel  2014-07-19 07:53:48.0 +0200
@@ -3,7 +3,7 @@
 Section: libs
 Priority: optional
 Depends: libc6 (= ${binary:Version}), ${misc:Depends}
-Build-Profiles: !stage1
+Build-Profiles: !stage1 !nobiarch
 Description: GNU C Library: ARM softfp shared libraries for armhf
  This package includes shared versions of the standard C
  library and the standard math library, as well as many others.
@@ -15,6 +15,7 @@
 Priority: optional
 Depends: libc6-armel (= ${binary:Version}), libc6-dev (= ${binary:Version}), 
${misc:Depends}
 Recommends: gcc-multilib
+Build-Profiles: !nobiarch
 Description: GNU C Library: ARM softfp development libraries for armhf
  Contains the symlinks and object files needed to compile and link programs
  which use the standard C library. This is the ARM softfp version of the
diff -Nru glibc-2.19/debian/control.in/armhf glibc-2.19/debian/control.in/armhf
--- glibc-2.19/debian/control.in/armhf  2014-06-27 04:28:51.0 +0200
+++ glibc-2.19/debian/control.in/armhf  2014-07-19 07:54:00.0 +0200
@@ -3,7 +3,7 @@
 Section: libs
 Priority: optional
 Depends: libc6 (= ${binary:Version}), ${misc:Depends}
-Build-Profiles: !stage1
+Build-Profiles: !stage1 !nobiarch
 Description: GNU C Library: ARM hard float shared libraries for armel
  This package includes shared versions of the standard C
  library and the standard math library, as well as many others.
@@ -15,6 +15,7 @@
 Priority: optional
 Depends: libc6-armhf (= ${binary:Version}), libc6-dev (= ${binary:Version}), 
${misc:Depends}
 Recommends: gcc-multilib
+Build-Profiles: !nobiarch
 Description: GNU C Library: ARM hard float development libraries for armel
  Contains the symlinks and object files needed to compile and link programs
  which use the standard C library. This is the ARM hard float version of the
diff -Nru glibc-2.19/debian/control.in/i386 glibc-2.19/debian/control.in/i386
--- glibc-2.19/debian/control.in/i386   2014-06-27 04:28:51.0 +0200
+++ glibc-2.19/debian/control.in/i386   2014-07-19 07:54:14.0 +0200
@@ -5,7 +5,7 @@
 Depends: libc6 (= ${binary:Version}), ${misc:Depends}
 Replaces: libc6-dev-i386
 Breaks: fakeroot ( 1.12.3), gnu-efi ( 3.0e-3), fakechroot ( 2.9-1.1), 
fglrx-glx-ia32 ( 1:9-6-1), ia32-libs ( 20090804), ia32-libs-gtk ( 
20090804), lib32asound2 ( 1.0.20-3), lib32asound2-dev ( 1.0.20-3), 
lib32bz2-1.0 ( 1.0.5-3), lib32bz2-dev ( 1.0.5-3), lib32ffi-dev ( 
3.0.9~rc9-1), lib32ffi5 ( 3.0.9~rc9-1), lib32g2c0 ( 1:3.4.6-10), lib32gcc1 
( 1:4.4.0-7), lib32gfortran3 ( 4.4.0-7), lib32gmp3 ( 2:4.3.1+dfsg-3), 
lib32gmp3-dev ( 2:4.3.1+dfsg-3), lib32gmpxx4 ( 2:4.3.1+dfsg-3), lib32gomp1 
( 4.4.0-7), lib32icu-dev ( 4.0.1-3), lib32icu40 ( 4.0.1-3), lib32mudflap0 
( 4.4.0-7

Bug#742640: src:eglibc: build stage2 without selinux

2014-07-15 Thread Helmut Grohne
On Thu, Jul 10, 2014 at 09:46:05PM +0200, Aurelien Jarno wrote:
 Hmm, the above has actually been removed in favor of a test on
 $(DEB_BUILD_PROFILES).
 
 Instead of duplicating the code, please test for both stage1 and stage2
 in the same test.

Updating patch addressing both concerns. Successfully tested on
jenkins.d.n.

Helmut
diff -Nru eglibc-2.19/debian/sysdeps/linux.mk eglibc-2.19/debian/sysdeps/linux.mk
--- eglibc-2.19/debian/sysdeps/linux.mk
+++ eglibc-2.19/debian/sysdeps/linux.mk
@@ -11,5 +11,5 @@
 
-ifneq ($(filter stage1,$(DEB_BUILD_PROFILES)),)
+ifneq ($(filter stage1 stage2,$(DEB_BUILD_PROFILES)),)
   libc_extra_config_options = $(extra_config_options)
 else
   libc_extra_config_options = --with-selinux --enable-systemtap $(extra_config_options)


Bug#742640: src:eglibc: build stage2 without selinux

2014-07-10 Thread Helmut Grohne
Version: 2.19-5

On Tue, Mar 25, 2014 at 09:51:33PM +0100, Helmut Grohne wrote:
 The eglibc package currently lacks a stage2 build profile entirely. A
 stage2 is needed though, because libselinux cannot be built without an
 actual libc among other things and eglibc explicitly enabled selinux via
 a configure flag. The attached patch removes that flag when the package
 is built with dpkg-buildpackage -Pstage2.

Updated patch to apply against glibc 2.19. It also disables systemptap
now.

Helmut
diff -Nru eglibc-2.19/debian/sysdeps/linux.mk eglibc-2.19/debian/sysdeps/linux.mk
--- eglibc-2.19/debian/sysdeps/linux.mk
+++ eglibc-2.19/debian/sysdeps/linux.mk
@@ -12,7 +12,11 @@
 ifeq ($(DEB_BUILD_PROFILE),bootstrap)
   libc_extra_config_options = $(extra_config_options)
 else
-  libc_extra_config_options = --with-selinux --enable-systemtap $(extra_config_options)
+  ifneq ($(filter stage2,$(DEB_BUILD_PROFILES)),)
+libc_extra_config_options = $(extra_config_options)
+  else 
+libc_extra_config_options = --with-selinux --enable-systemtap $(extra_config_options)
+  endif
 endif
 
 ifndef LINUX_SOURCE


Bug#754350: src:glibc: fix dh_strip call in stage1

2014-07-10 Thread Helmut Grohne
Package: src:glibc
Version: 2.19-5
Severity: normal
Tags: patch
User: helm...@debian.org
Usertags: rebootstrap

I introduced a regression in my patch for #752480. All non-dev packages
were (correctly) marked with Build-Profiles: !stage1. For debhelper this
means, that those packages no longer exist. In particular passing a
non-existing package to dh_strip --dbg-package fails. Please apply the
attached patch or something equivalent.

Helmut
diff -Nru glibc-2.19/debian/rules.d/debhelper.mk glibc-2.19/debian/rules.d/debhelper.mk
--- glibc-2.19/debian/rules.d/debhelper.mk
+++ glibc-2.19/debian/rules.d/debhelper.mk
@@ -8,6 +8,10 @@
 non-debug-packages = $(filter-out %-dbg,$(DEB_ARCH_REGULAR_PACKAGES))
 $(patsubst %,$(stamp)binaryinst_%,$(debug-packages)):: $(patsubst %,$(stamp)binaryinst_%,$(non-debug-packages))
 
+ifeq ($(filter stage1,$(DEB_BUILD_PROFILES)),)
+DH_STRIP_DEBUG_PACKAGE=--dbg-package=$(libc)-dbg
+endif
+
 $(patsubst %,$(stamp)binaryinst_%,$(DEB_ARCH_REGULAR_PACKAGES) $(DEB_INDEP_REGULAR_PACKAGES)):: $(patsubst %,$(stamp)install_%,$(GLIBC_PASSES)) debhelper
 	@echo Running debhelper for $(curpass)
 	dh_testroot
@@ -49,7 +53,7 @@
 	# strip *.o files as dh_strip does not (yet?) do it.
 	if test $(NOSTRIP_$(curpass)) != 1; then\
 	  if test $(NODEBUG_$(curpass)) != 1; then\
-	dh_strip -p$(curpass) -Xlibpthread --dbg-package=$(libc)-dbg;	\
+	dh_strip -p$(curpass) -Xlibpthread $(DH_STRIP_DEBUG_PACKAGE);	\
 	(cd debian/$(curpass);		\
 	  find . -name libpthread-\*.so -exec objcopy			\
 	--only-keep-debug '{}' ../$(libc)-dbg/usr/lib/debug/'{}'	\


Bug#752480: src:eglibc: use the build profile spec

2014-06-23 Thread Helmut Grohne
Package: src:eglibc
Version: 2.19-3
Severity: wishlist
Tags: patch
User: helm...@debian.org
Usertags: rebootstrap

Dear eglibc maintainers,

You asked me to prepare a patch that maps the old ways of selecting
bootstrap stages to the current build profile specification
(https://wiki.debian.org/BuildProfileSpec). I therefore prepared the
attached patch. It keeps supporting the following environment variables:

 * DEB_STAGE=stage1
 * DEB_BUILD_PROFILE=bootstrap

It selects the original behaviour of DEB_BUILD_PROFILE=bootstrap and
implements it as DEB_BUILD_PROFILES=stage1 (in accordance with the above
specification). The code for the original DEB_STAGE=stage1 is dropped.

This patch does not yet annotate Build-Depends with build profiles,
because that would prevent the package from being uploaded due to
#744246.

Helmut
diff -Nru eglibc-2.19/debian/changelog eglibc-2.19/debian/changelog
--- eglibc-2.19/debian/changelog2014-06-17 18:58:21.0 +0200
+++ eglibc-2.19/debian/changelog2014-06-18 17:06:15.0 +0200
@@ -1,3 +1,11 @@
+eglibc (2.19-3.1) UNRELEASED; urgency=low
+
+  * Non-maintainer upload.
+  * Rename the bootstrap stage to DEB_BUILD_PROFILES=stage1 to conform with
+https://wiki.debian.org/BuildProfileSpec. Closes: #-1
+
+ -- Helmut Grohne hel...@subdivi.de  Wed, 18 Jun 2014 17:05:21 +0200
+
 eglibc (2.19-3) unstable; urgency=medium
 
   [ Aurelien Jarno ]
diff -Nru eglibc-2.19/debian/control.in/amd64 
eglibc-2.19/debian/control.in/amd64
--- eglibc-2.19/debian/control.in/amd64 2014-06-17 18:58:21.0 +0200
+++ eglibc-2.19/debian/control.in/amd64 2014-06-24 00:01:51.0 +0200
@@ -4,6 +4,7 @@
 Priority: optional
 Depends: libc6 (= ${binary:Version}), ${misc:Depends}
 Conflicts: amd64-libs (= 1.2)
+Build-Profiles: !stage1
 Description: Embedded GNU C Library: 64bit Shared libraries for AMD64
  This package includes shared versions of the standard C library and the
  standard math library, as well as many others. This is the 64bit version
diff -Nru eglibc-2.19/debian/control.in/armel 
eglibc-2.19/debian/control.in/armel
--- eglibc-2.19/debian/control.in/armel 2014-06-17 18:58:21.0 +0200
+++ eglibc-2.19/debian/control.in/armel 2014-06-24 00:02:05.0 +0200
@@ -3,6 +3,7 @@
 Section: libs
 Priority: optional
 Depends: libc6 (= ${binary:Version}), ${misc:Depends}
+Build-Profiles: !stage1
 Description: Embedded GNU C Library: ARM softfp shared libraries for armhf
  This package includes shared versions of the standard C
  library and the standard math library, as well as many others.
diff -Nru eglibc-2.19/debian/control.in/armhf 
eglibc-2.19/debian/control.in/armhf
--- eglibc-2.19/debian/control.in/armhf 2014-06-17 18:58:21.0 +0200
+++ eglibc-2.19/debian/control.in/armhf 2014-06-24 00:02:18.0 +0200
@@ -3,6 +3,7 @@
 Section: libs
 Priority: optional
 Depends: libc6 (= ${binary:Version}), ${misc:Depends}
+Build-Profiles: !stage1
 Description: Embedded GNU C Library: ARM hard float shared libraries for armel
  This package includes shared versions of the standard C
  library and the standard math library, as well as many others.
diff -Nru eglibc-2.19/debian/control.in/i386 eglibc-2.19/debian/control.in/i386
--- eglibc-2.19/debian/control.in/i386  2014-06-17 18:58:21.0 +0200
+++ eglibc-2.19/debian/control.in/i386  2014-06-24 00:02:24.0 +0200
@@ -5,6 +5,7 @@
 Depends: libc6 (= ${binary:Version}), ${misc:Depends}
 Replaces: libc6-dev-i386
 Breaks: fakeroot ( 1.12.3), gnu-efi ( 3.0e-3), fakechroot ( 2.9-1.1), 
fglrx-glx-ia32 ( 1:9-6-1), ia32-libs ( 20090804), ia32-libs-gtk ( 
20090804), lib32asound2 ( 1.0.20-3), lib32asound2-dev ( 1.0.20-3), 
lib32bz2-1.0 ( 1.0.5-3), lib32bz2-dev ( 1.0.5-3), lib32ffi-dev ( 
3.0.9~rc9-1), lib32ffi5 ( 3.0.9~rc9-1), lib32g2c0 ( 1:3.4.6-10), lib32gcc1 
( 1:4.4.0-7), lib32gfortran3 ( 4.4.0-7), lib32gmp3 ( 2:4.3.1+dfsg-3), 
lib32gmp3-dev ( 2:4.3.1+dfsg-3), lib32gmpxx4 ( 2:4.3.1+dfsg-3), lib32gomp1 
( 4.4.0-7), lib32icu-dev ( 4.0.1-3), lib32icu40 ( 4.0.1-3), lib32mudflap0 
( 4.4.0-7), lib32ncurses5 ( 5.7+20090523-1), lib32ncurses5-dev ( 
5.7+20090530-1), lib32ncursesw5 ( 5.7+20090530-1), lib32ncursesw5-dev ( 
5.7+20090530-1), lib32nss-mdns ( 0.10-3.1), lib32objc2 ( 4.4.0-7), 
lib32readline5 ( 5.2-5), lib32readline5-dev ( 5.2-5), lib32stdc++6 ( 
4.4.0-7), lib32stdc++6-4.4-dbg ( 4.4.0-7), lib32z1 ( 1:1.2.3.3.dfsg-14), 
lib32z1-dev ( 1:1.2.3.3.dfsg-14), libc6-dev-i386 ( 2.9-15), nvidia-glx-ia32 
( 185.18.14-2), nvidia-libvdpau1-ia32 ( 185.18.14-2)
+Build-Profiles: !stage1
 Description: Embedded GNU C Library: 32-bit shared libraries for AMD64
  This package includes shared versions of the standard C
  library and the standard math library, as well as many others.
diff -Nru eglibc-2.19/debian/control.in/kfreebsd-i386 
eglibc-2.19/debian/control.in/kfreebsd-i386
--- eglibc-2.19/debian/control.in/kfreebsd-i386 2014-06-17 18:58:21.0 
+0200
+++ eglibc-2.19/debian/control.in/kfreebsd-i386 2014-06-24 00

Bug#745380: src:eglibc: support non-multilib builds

2014-04-21 Thread Helmut Grohne
Package: src:eglibc
Version: 2.18-4
Severity: wishlist
Tags: patch
User: helm...@debian.org
Usertags: rebootstrap

It would be awesome, if eglibc had a variant to drop all the multilib
packages. In particular this helps for cross-building into an
architecture where a sibling architectures is momentarily broken. The
gcc-X.Y source packages have this feature for quite a while now and it
goes by the name DEB_CROSS_NO_BIARCH=yes. When I talked to Adam Conrad,
he indicated that he'd prefer using build profiles instead. So I am
suggesting to use nobiarch as the name for that profile, because it is
close to gcc's way of calling things.

Please consider the attached patch to achieve this goal.

Helmut
diff -Nru eglibc-2.18/debian/changelog eglibc-2.18/debian/changelog
--- eglibc-2.18/debian/changelog
+++ eglibc-2.18/debian/changelog
@@ -1,3 +1,11 @@
+eglibc (2.18-4.1) UNRELEASED; urgency=low
+
+  * Non-maintainer upload.
+  * Add a nobiarch stage that inhibits all multilib packages from being
+built. (Closes: #-1)
+
+ -- Helmut Grohne hel...@subdivi.de  Mon, 21 Apr 2014 07:44:15 +0200
+
 eglibc (2.18-4) unstable; urgency=high
 
   [ Aurelien Jarno ]
diff -Nru eglibc-2.18/debian/rules eglibc-2.18/debian/rules
--- eglibc-2.18/debian/rules
+++ eglibc-2.18/debian/rules
@@ -173,6 +173,10 @@
 -include debian/sysdeps/$(DEB_HOST_ARCH_OS).mk
 -include debian/sysdeps/$(DEB_HOST_ARCH).mk
 
+ifeq ($(filter nobiarch,$(DEB_BUILD_PROFILES)),)
+DEB_ARCH_REGULAR_PACKAGES += $(DEB_ARCH_MULTILIB_PACKAGES)
+endif
+
 # Don't run dh_strip on this package
 NOSTRIP_$(libc)-dbg = 1
 
@@ -196,6 +200,10 @@
   endif
 endif
 
+ifneq ($(filter nobiarch,$(DEB_BUILD_PROFILES)),)
+override EGLIBC_PASSES = libc
+endif
+
 # And now the rules...
 include debian/rules.d/*.mk
 
diff -Nru eglibc-2.18/debian/sysdeps/alpha.mk 
eglibc-2.18/debian/sysdeps/alpha.mk
--- eglibc-2.18/debian/sysdeps/alpha.mk
+++ eglibc-2.18/debian/sysdeps/alpha.mk
@@ -4,7 +4,7 @@
 
 # build an ev67 optimized library
 EGLIBC_PASSES += alphaev67
-DEB_ARCH_REGULAR_PACKAGES += libc6.1-alphaev67
+DEB_ARCH_MULTILIB_PACKAGES += libc6.1-alphaev67
 alphaev67_add-ons = ports nptl $(add-ons)
 alphaev67_configure_target = alphaev67-linux-gnu
 alphaev67_extra_cflags = -mcpu=ev67 -mtune=ev67 -O2
diff -Nru eglibc-2.18/debian/sysdeps/amd64.mk 
eglibc-2.18/debian/sysdeps/amd64.mk
--- eglibc-2.18/debian/sysdeps/amd64.mk
+++ eglibc-2.18/debian/sysdeps/amd64.mk
@@ -3,7 +3,7 @@
 
 # build 32-bit (i386) alternative library
 EGLIBC_PASSES += i386
-DEB_ARCH_REGULAR_PACKAGES += libc6-i386 libc6-dev-i386
+DEB_ARCH_MULTILIB_PACKAGES += libc6-i386 libc6-dev-i386
 libc6-i386_shlib_dep = libc6-i386 (= $(shlib_dep_ver))
 i386_add-ons = nptl $(add-ons)
 i386_configure_target = i686-linux-gnu
@@ -39,7 +39,7 @@
 
 # build x32 ABI alternative library
 EGLIBC_PASSES += x32
-DEB_ARCH_REGULAR_PACKAGES += libc6-x32 libc6-dev-x32
+DEB_ARCH_MULTILIB_PACKAGES += libc6-x32 libc6-dev-x32
 libc6-x32_shlib_dep = libc6-x32 (= $(shlib_dep_ver))
 x32_add-ons = nptl $(add-ons)
 x32_configure_target = x86_64-linux-gnux32
diff -Nru eglibc-2.18/debian/sysdeps/armel.mk 
eglibc-2.18/debian/sysdeps/armel.mk
--- eglibc-2.18/debian/sysdeps/armel.mk
+++ eglibc-2.18/debian/sysdeps/armel.mk
@@ -2,7 +2,7 @@
 extra_config_options = --enable-multi-arch
 
 #EGLIBC_PASSES += armhf
-#DEB_ARCH_REGULAR_PACKAGES += libc6-armhf libc6-dev-armhf
+#DEB_ARCH_MULTILIB_PACKAGES += libc6-armhf libc6-dev-armhf
 #armhf_add-ons = ports nptl $(add-ons)
 #armhf_configure_target = arm-linux-gnueabihf
 #armhf_CC = $(CC) -march=armv7-a -mfpu=vfpv3-d16 -mfloat-abi=hard
diff -Nru eglibc-2.18/debian/sysdeps/armhf.mk 
eglibc-2.18/debian/sysdeps/armhf.mk
--- eglibc-2.18/debian/sysdeps/armhf.mk
+++ eglibc-2.18/debian/sysdeps/armhf.mk
@@ -13,7 +13,7 @@
 endef
 
 #EGLIBC_PASSES += armel
-#DEB_ARCH_REGULAR_PACKAGES += libc6-armel libc6-dev-armel
+#DEB_ARCH_MULTILIB_PACKAGES += libc6-armel libc6-dev-armel
 #armel_add-ons = ports nptl $(add-ons)
 #armel_configure_target = arm-linux-gnueabi
 #armel_CC = $(CC) -mfloat-abi=soft
diff -Nru eglibc-2.18/debian/sysdeps/hurd-i386.mk 
eglibc-2.18/debian/sysdeps/hurd-i386.mk
--- eglibc-2.18/debian/sysdeps/hurd-i386.mk
+++ eglibc-2.18/debian/sysdeps/hurd-i386.mk
@@ -1,7 +1,7 @@
 # We use -march=i686 and glibc's i686 routines use cmov, so require it.
 # A Debian-local glibc patch adds cmov to the search path.
 EGLIBC_PASSES += i686
-DEB_ARCH_REGULAR_PACKAGES += libc0.3-i686
+DEB_ARCH_MULTILIB_PACKAGES += libc0.3-i686
 i686_add-ons = $(libc_add-ons)
 i686_configure_target=i686-gnu
 i686_extra_cflags = -march=i686 -mtune=generic
diff -Nru eglibc-2.18/debian/sysdeps/i386.mk eglibc-2.18/debian/sysdeps/i386.mk
--- eglibc-2.18/debian/sysdeps/i386.mk
+++ eglibc-2.18/debian/sysdeps/i386.mk
@@ -4,7 +4,7 @@
 # A Debian-local glibc patch adds cmov to the search path.
 # The optimized libraries also use NPTL!
 EGLIBC_PASSES += i686
-DEB_ARCH_REGULAR_PACKAGES += libc6-i686
+DEB_ARCH_MULTILIB_PACKAGES += libc6-i686
 i686_add-ons = nptl $(add

Bug#743676: FTCBFS: i386 stage1 tries to install xen stuff which is not built

2014-04-05 Thread Helmut Grohne
Package: src:eglibc
Version: 2.18-4
Severity: normal
Tags: patch

Hi Adam,

When trying to cross-build an eglibc stage1 for i386 on amd64 it fails
installing xen stuff:

# extra_debhelper_pkg_install is used for debhelper.mk only.
# when you want to install extra packages, use extra_pkg_install.
mkdir -p debian/libc6-dev//usr/lib/i386-linux-gnu/xen
cp -af debian/tmp-xen//usr/lib/i386-linux-gnu/*.a 
debian/libc6-dev//usr/lib/i386-linux-gnu/xen
cp: cannot stat 'debian/tmp-xen//usr/lib/i386-linux-gnu/*.a': No such file or 
directory
make: *** [/tmp/buildd/eglibc/eglibc-2.18/stamp-dir/binaryinst_libc6-dev] Error 
1
dpkg-buildpackage: error: debian/rules binary-arch gave error exit status 2

I propose not to install the xen stuff which is not built in stage1
anyway by making that part conditional.

Helmut
diff -Nru eglibc-2.18/debian/changelog eglibc-2.18/debian/changelog
--- eglibc-2.18/debian/changelog	2014-03-02 16:01:30.0 +0100
+++ eglibc-2.18/debian/changelog	2014-04-05 08:08:23.0 +0200
@@ -1,3 +1,11 @@
+eglibc (2.18-4.1) UNRELEASED; urgency=low
+
+  * Non-maintainer upload.
+  * Don't try to install xen headers in i386 bootstrap build, because they are
+not built.  Closes: #-1.
+
+ -- Helmut Grohne hel...@dedup1.subdivi.de  Sat, 05 Apr 2014 08:07:22 +0200
+
 eglibc (2.18-4) unstable; urgency=high
 
   [ Aurelien Jarno ]
diff -Nru eglibc-2.18/debian/sysdeps/i386.mk eglibc-2.18/debian/sysdeps/i386.mk
--- eglibc-2.18/debian/sysdeps/i386.mk	2014-03-02 16:01:31.0 +0100
+++ eglibc-2.18/debian/sysdeps/i386.mk	2014-04-05 08:09:22.0 +0200
@@ -51,11 +51,13 @@
 	debian/tmp-libc/usr/bin
 endef
 
+ifneq ($(DEB_BUILD_PROFILE),bootstrap)
 define libc6-dev_extra_pkg_install
 mkdir -p debian/libc6-dev/$(libdir)/xen
 cp -af debian/tmp-xen/$(libdir)/*.a \
 	debian/libc6-dev/$(libdir)/xen
 endef
+endif
 
 define libc6-dev-amd64_extra_pkg_install
 


Bug#742640: src:eglibc: build stage2 without selinux

2014-03-25 Thread Helmut Grohne
Package: src:eglibc
Version: 2.18-4
Severity: wishlist
Tags: patch

The eglibc package currently lacks a stage2 build profile entirely. A
stage2 is needed though, because libselinux cannot be built without an
actual libc among other things and eglibc explicitly enabled selinux via
a configure flag. The attached patch removes that flag when the package
is built with dpkg-buildpackage -Pstage2.

Note that I did not convert the stage1 code to comply with the build
profile spec. Thus eglibc now evaluates DEB_STAGE or DEB_BUILD_PROFILE
(singular) for stage1 and DEB_BUILD_PROFILES (plural, in accordance with
build profile spec) for stage2.

Not all architectures successfully build a stage2 with this patch, but
arm64, armel, armhf and m68k do.

Helmut
diff -Nru eglibc-2.18/debian/sysdeps/linux.mk eglibc-2.18/debian/sysdeps/linux.mk
--- eglibc-2.18/debian/sysdeps/linux.mk
+++ eglibc-2.18/debian/sysdeps/linux.mk
@@ -12,7 +12,11 @@
 ifeq ($(DEB_BUILD_PROFILE),bootstrap)
   libc_extra_config_options = $(extra_config_options)
 else
-  libc_extra_config_options = --with-selinux $(extra_config_options)
+  ifneq ($(filter stage2,$(DEB_BUILD_PROFILES)),)
+libc_extra_config_options = $(extra_config_options)
+  else 
+libc_extra_config_options = --with-selinux $(extra_config_options)
+  endif
 endif
 
 ifndef LINUX_SOURCE


Bug#708504: src:eglibc: drop always satisfied build-dependency sed

2013-05-16 Thread Helmut Grohne
Control: retitle -1 drop always satisfied build-dependencies sed and make

Sorry for the noise.

On Thu, May 16, 2013 at 07:45:59AM +0200, Helmut Grohne wrote:
 Could you drop sed from Build-Depends? Rationale:
 
  * Currently it is sed (= 4.0.5-4). The version required is satisfied
in old old stable and the package itself is essential.
  * sed lacks Multi-Arch foreign (#693872), so this makes cross building
eglibc a little harder.

This equally applies to make, since make is build-essential and its bug
is #693926.

Helmut


-- 
To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20130516060125.ga27...@alf.mars



Bug#708504: src:eglibc: drop always satisfied build-dependency sed

2013-05-15 Thread Helmut Grohne
Package: src:eglibc
Version: 2.17-2
Severity: wishlist

Could you drop sed from Build-Depends? Rationale:

 * Currently it is sed (= 4.0.5-4). The version required is satisfied
   in old old stable and the package itself is essential.
 * sed lacks Multi-Arch foreign (#693872), so this makes cross building
   eglibc a little harder.

Helmut


-- 
To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20130516054558.ga21...@alf.mars



Bug#667023: 2.15 brings x32 support

2012-05-27 Thread Helmut Grohne
block 667023 by 672934
thanks

x32 support has been merged into the 2.15 version of glibc. Since
carrying x32 patches ourselves seems like a useless waste of time, I
mark the x32 bug as being blocked by the new upstream version.

Helmut



-- 
To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120527093302.ga11...@alf.mars



Bug#667023: src:eglibc: please provide a binary package for the x32 sub architecture on amd64

2012-04-03 Thread Helmut Grohne
Package: src:eglibc
Version: 2.13-27
Severity: normal
Tags: upstream
Blocks: 667005

gcc-4.7 and binutils (2.22) already provide support for the x32 abi. The
missing piece to producing x32 binaries is a c library. Patches are
available at git://github.com/hjl-tools/glibc.git. An aspect that makes
supporting x32 more difficult is that glibc is currently compiled using
gcc-4.4 whereas the x32 abi requires at least gcc-4.7. Switching
compiler version is not a lightly taken decision and especially not this
late in the freeze process. I estimate the diff between 2.13 and
2.13+x32 to be around 202 files changed, 3967 insertions, 218 deletions,
and 568 modifications.

Due to the ongoing multiarch transition another question should be
asked: Should the new package be libc6-x32:amd64 or libc6:x32?

Helmut



-- 
To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120403130210.GA17099@localhost



Bug#286825: fixed in experimental

2007-03-06 Thread Helmut Grohne
tags 286825 = fixed-in-experimental
thanks

This bug seems to be fixed in experimental.

Helmut Grohne


signature.asc
Description: Digital signature


Bug#310445: More information needed

2007-03-06 Thread Helmut Grohne
tag 310445 moreinfo
severity 310445 normal
thanks

There are new versions of glibc available. Could you perhaps recheck
whether this bug is reproducible? Furthermore the source for that binary
would be helpful if available.

Helmut Grohne


signature.asc
Description: Digital signature


Bug#336843: adduser: removes user from group if /etc/group file ends with :

2007-03-06 Thread Helmut Grohne
tags 336843 wontfix
thanks

 Judged that : is the field separator in /etc/group, and that
 /etc/group might change its format to include more fields, and that a
 colon is not a valid character in a user name (it would wreck havoc in
 /etc/passwd), I would expect that perl would consider the : a
 delimiter here and not return it as part of the group name.
 perl doesn't parse /etc/group directly, it just calls libc's getgrname,
 which returns a list as gr_mem (the last entry of which has a trailing
 colon in this case).

There is specified behaviour on invalid passwd files, so whatever glibc
does here is within the specs. The function could also segfault at that
point. This could maybe reported to the upstream but they'll probably
think the same way.

Helmut Grohne


signature.asc
Description: Digital signature


Bug#331405: Accidential activation of nscd is too simple

2007-03-06 Thread Helmut Grohne
reassign 331405 libpam-ldap
tags 331405 patch
thanks

 It would be libpam-ldap which suggests libnss-ldap in my case. But
 running apt-rdepends and analyzing it's output suggests that there are
 35 packages which depends on nscd in etch today. That's depends as in
 any of the relationships that drags a package along, either directly or
 as a consequence of a second or higer order dependency.

The package description of nscd clearly states when nscd should be
installed. A wrong dependency on nscd is no bug with nscd, but with
the software depending on it. Most packages seem to have changed their
behaviour since there are only 5 packages in apt-cache rdepends nscd of
which at least one is a conflict. So maybe libpam-ldap could suggest
nscd instead of recommending it. Otherwise this bug should be tagged
wontfix.

Helmut Grohne


signature.asc
Description: Digital signature


Bug#352139: getopt optional arg does not work as documented

2007-03-06 Thread Helmut Grohne
tag 352139 -wontfix
reassign 352139 manpages-dev
thanks

 Now. This case is difficult. The string hello could also be just a
 normal filename argument. I think the glibc handles this case correctly
 and thus mark the bug as wontfix.

Actually it would be even better if the documentation could be adapted.
Thanks to Aurelien Jarno for pointing this out.

Helmut Grohne


signature.asc
Description: Digital signature


Bug#352139: getopt optional arg does not work as documented

2007-02-27 Thread Helmut Grohne
tag 352139 wontfix
thanks

 However, this does not seem to be the case. 

Actually it works quite similar.

 When run: 
   [EMAIL PROTECTED]:/tmp$ a.out -a
   a arg is: (null)

Correct behaviour.

$ ./a.out -afoo
a arg is: foo


   [EMAIL PROTECTED]:/tmp$ a.out -a hello
   a arg is: (null)

Now. This case is difficult. The string hello could also be just a
normal filename argument. I think the glibc handles this case correctly
and thus mark the bug as wontfix.

Helmut


signature.asc
Description: Digital signature


Bug#160683: date: long timezone offset sighlently changed

2007-02-27 Thread Helmut Grohne
tag 160683 moreinfo
thanks

On Thu, Sep 12, 2002 at 12:10:48PM -0700, Blars Blarson wrote:
 Gnu date apperently siglently limits the timezone offset to 23, so the
 above command will SOMETIMES show todays date instead with no error
 message.  (The SOMETIMES makes this even harder to debug.)  This
 breaks portable and older shell scripts.  (I realize there are better
 ways of doing this using Gnu date, but they don't work on solaris or
 aix.)

Could you be more precise on SOMETIMES and maybe include steps to
reproduce? Does it only happen for specific dates? Which? Does it depend
on the architecture? Which?

Helmut


signature.asc
Description: Digital signature


Bug#373779: libc6: assertion failure in gconv_db.c with smbclient

2006-06-15 Thread Helmut Grohne
Package: libc6
Version: 2.3.999.2-4
Severity: normal

# smbclient
smbclient: gconv_db.c:232: __gconv_release_step: Assertion `step-__end_fct == 
((void *)0)' failed.
Aborted
#

This does not happen with 2.3.6-9. The bug seems to occur while loading
shared libraries as different options to smbclient don't change the
behaviour and strace shows some library loading stuff before.

-- System Information:
Debian Release: testing/unstable
  APT prefers unstable
  APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.16
Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1)

Versions of packages libc6 depends on:
ii  tzdata2006g-2Time Zone and Daylight Saving Time

libc6 recommends no packages.

-- no debconf information


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]