Archive rebuild to test potential stdlib.h / sys/types.h changes in glibc 2.23

  glibc upstream would like to fix a long-standing problem involving
<stdlib.h> polluting the user namespace with macros named 'major' and
'minor'.  This is not technically an ISO nor POSIX conformance violation
since it only happens in extended compilation modes, but extensions are
on by default (and worse, g++ unconditionally defines _GNU_SOURCE
regardless of conformance mode - which is agreed to be a bug, but very
difficult to fix due to libstdc++ headers needing some of those
extensions) so it's likely to trip people up.  For more detail see
https://sourceware.org/bugzilla/show_bug.cgi?id=19239 and the libc-alpha
discussion starting at
https://sourceware.org/ml/libc-alpha/2015-11/msg00253.html .

We have identified two potential changes which could fix this problem;
unfortunately both of them have fairly high risk of breaking software
which expects stdlib.h to include sys/types.h, sys/types.h to include
sys/sysmacros.h, or both.  (Neither of those is guaranteed by any
standard, but I think we all know how little that means.)  We would
therefore like to ask for an archive-rebuild test using the modified
glibc.  This would involve updating the glibc packages to 2.23-dev
first, and then applying one or both of the attached patches.  (Ideally
there would be four tests - 2.23-dev baseline, patch 1 only, patch 2
only, and both patches.  But we realize that this is an expensive
proposition.)

How can we arrange for this to happen?

Thanks,
zw
  

On Mon, Nov 16, 2015 at 5:19 AM, Zack Weinberg wrote:

> How can we arrange for this to happen?

I'm not involved in the archive rebuilds stuff but the documentation
for it is here:

https://wiki.debian.org/qa.debian.org/ArchiveTesting
  

Zack Weinberg <zackw@panix.com> writes:

> We have identified two potential changes which could fix this problem;
> unfortunately both of them have fairly high risk of breaking software
> which expects stdlib.h to include sys/types.h, sys/types.h to include
> sys/sysmacros.h, or both.  (Neither of those is guaranteed by any
> standard, but I think we all know how little that means.)  We would
> therefore like to ask for an archive-rebuild test using the modified
> glibc.

I can rebuild any set of packages in my OBS project
https://build.opensuse.org/project/show/home:Andreas_Schwab:glibc that I
use for testing.

Andreas.
  

Here are the first fallouts from the first patch:

https://build.opensuse.org/package/live_build_log/home:Andreas_Schwab:glibc/gpm/rebuild/x86_64

prog/display-buttons.c:69:4: error: unknown type name 'fd_set'

https://build.opensuse.org/package/live_build_log/home:Andreas_Schwab:glibc/sysvinit/rebuild/x86_64

/home/abuild/rpmbuild/BUILD/sysvinit-2.88+dsf/src/mountpoint.c:125: undefined reference to `minor'

Andreas.
  

On Mon, Nov 16, 2015 at 9:37 AM, Andreas Schwab <schwab@suse.de> wrote:
> Here are the first fallouts from the first patch:

Which do you mean by "the first patch"?  This ...

> https://build.opensuse.org/package/live_build_log/home:Andreas_Schwab:glibc/gpm/rebuild/x86_64
> prog/display-buttons.c:69:4: error: unknown type name 'fd_set'

... should only be possible as a consequence of the patch numbered 0002-.

> https://build.opensuse.org/package/live_build_log/home:Andreas_Schwab:glibc/sysvinit/rebuild/x86_64
> /home/abuild/rpmbuild/BUILD/sysvinit-2.88+dsf/src/mountpoint.c:125: undefined reference to `minor'

Unfortunately, this code is going to break with either patch!  It
includes neither sys/types.h nor sys/sysmacros.h and it expects the
sys/sysmacros.h definition of 'major' and 'minor'.

(Neither of these programs appears to have been written with C library
portability in mind, which is understandable considering they're both
quite Linux-specific in other ways.)

zw
  

On Sun, Nov 15, 2015 at 9:26 PM, Paul Wise <pabs@debian.org> wrote:
>
> I'm not involved in the archive rebuilds stuff but the documentation
> for it is here:
>
> https://wiki.debian.org/qa.debian.org/ArchiveTesting

Thanks, but unfortunately it doesn't help me much, because I'm not a
DD, and because it doesn't explain how to do "custom rebuilds" (i.e.
with the patched glibc).

zw
  

Zack Weinberg <zackw@panix.com> writes:

> On Mon, Nov 16, 2015 at 9:37 AM, Andreas Schwab <schwab@suse.de> wrote:
>> Here are the first fallouts from the first patch:
>
> Which do you mean by "the first patch"?  This ...
>
>> https://build.opensuse.org/package/live_build_log/home:Andreas_Schwab:glibc/gpm/rebuild/x86_64
>> prog/display-buttons.c:69:4: error: unknown type name 'fd_set'
>
> ... should only be possible as a consequence of the patch numbered 0002-.

Which is the first patch.

Here are more:

https://build.opensuse.org/package/live_build_log/home:Andreas_Schwab:glibc/systemd-mini/rebuild/x86_64

./src/basic/strbuf.h:52:1: error: unknown type name 'ssize_t'

https://build.opensuse.org/package/live_build_log/home:Andreas_Schwab:glibc/libhugetlbfs/rebuild/x86_64

hugetests.h:50:1: error: unknown type name 'ino_t'

https://build.opensuse.org/package/live_build_log/home:Andreas_Schwab:glibc/dosfstools/rebuild/x86_64

src/fsck.fat.h:138:5: error: unknown type name 'loff_t'

Andreas.
  

On Mon, Nov 16, 2015 at 10:34 AM, Andreas Schwab <schwab@suse.de> wrote:
> Zack Weinberg <zackw@panix.com> writes:
>>
>> ... should only be possible as a consequence of the patch numbered 0002-.
>
> Which is the first patch.

It's not terribly important, but what ordering are you using to define
it as the "first patch"?

> ./src/basic/strbuf.h:52:1: error: unknown type name 'ssize_t'
> hugetests.h:50:1: error: unknown type name 'ino_t'
> src/fsck.fat.h:138:5: error: unknown type name 'loff_t'

It's starting to sound like lots of programs assume stdlib.h pulls in
sys/types.h...

zw
  

Zack Weinberg <zackw@panix.com> writes:

> It's not terribly important, but what ordering are you using to define
> it as the "first patch"?

The order you sent the patches.

Andreas.