Your message dated Thu, 12 Jul 2018 09:53:33 +0200
with message-id <20180712075333.ga9...@msg.credativ.de>
and subject line Re: [Qa-jenkins-dev] Bug#903545: reproducible: Please don't
vary kernel architecture personality
has caused the Debian Bug report #903545,
regarding reproducible: Please don't vary kernel architecture personality
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)
--
903545: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=903545
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: jenkins.debian.org
Severity: normal
User: jenkins.debian....@packages.debian.org
Usertags: reproducible
Hi,
the only remaining variation in the postgresql-10 builds is the `uname -m`
information captured in pg_config.h:
/usr/include/postgresql/10/server/pg_config.h:
#define PG_VERSION_STR "PostgreSQL 10.4 (Debian 10.4-2.pgdg+1) on
x86_64-pc-linux-gnu, compiled by gcc (Debian 7.3.0-18) 7.3.0, 64-bit"
#define PG_VERSION_STR "PostgreSQL 10.4 (Debian 10.4-2.pgdg+1) on
i686-pc-linux-gnu, compiled by gcc (Debian 7.3.0-18) 7.3.0, 64-bit"
This information is also stored in Makefile.global, which is used by
extension modules to configure themselves for the PostgreSQL server
they are targetting:
/usr/lib/postgresql/10/lib/pgxs/src/Makefile.global:
host_tuple = x86_64-pc-linux-gnu
host_os = linux-gnu
host_cpu = x86_64
host_tuple = i686-pc-linux-gnu
host_os = linux-gnu
host_cpu = i686
I could probably remove the "on $host" part from PG_VERSION_STR, but
Makefile.global is not so easy, because 3rd-party extensions might
need the information.
The difference stems from altering the kernel personality to report
the i686 architecture name even on x86_64 aka amd64 systems.
I think this is damaging an otherwise functional environment, i.e.
systems should always be running with their native architecture
(x86_64 on amd64, armv7l on armhf, etc) - otherwise the system is just
broken. Chroots for related architectures should be using the
corresponding architecture personality, and indeed, schroot can switch
personality on entering chroots.
Please don't vary kernel architecture personality for reproducibility
testing.
(Does (or did) this variation even catch real-world reproducibility
problems in packages?)
Thanks,
Christoph
--- End Message ---
--- Begin Message ---
Re: Vagrant Cascadian 2018-07-11 <8736wplnr4....@aikidev.net>
> > The difference stems from altering the kernel personality to report
> > the i686 architecture name even on x86_64 aka amd64 systems.
>
> It doesn't alter the kernel personality, it's running an i386 userland
> with an amd64 kernel without changing the personality to match the
> userland.
The 2nd build here is still an amd64 userland with a amd64 kernel (or
else it wouldn't be a 64-bit build which it is), but the kernel got
told to report itself as i686.
> > I think this is damaging an otherwise functional environment, i.e.
> > systems should always be running with their native architecture
> > (x86_64 on amd64, armv7l on armhf, etc) - otherwise the system is just
> > broken. Chroots for related architectures should be using the
> > corresponding architecture personality, and indeed, schroot can switch
> > personality on entering chroots.
>
> I can see the argument that that is a fairly reasonable expectation, but
> I don't think it's safe to assume; code should be more robust to handle
> when it isn't true.
The fix here I'm going to try (pointed out by Helmut, thanks!) is
./configure --build=$(dpkg-architecture -qDEB_BUILD_GNU_TYPE)
> > Please don't vary kernel architecture personality for reproducibility
> > testing.
> >
> > (Does (or did) this variation even catch real-world reproducibility
> > problems in packages?)
>
> It appears to have caught this bug, and several others like it.
I'm arguing this isn't a bug, but overzealous mangling with the
environment. But I got told that real portability problems have been
found due to it, so I'm closing the bug report because a friendly,
non-intrusive fix exists.
Thanks!
Christoph
--
Senior Berater, Tel.: +49 2166 9901 187
credativ GmbH, HRB Mönchengladbach 12080, USt-ID-Nummer: DE204566209
Trompeterallee 108, 41189 Mönchengladbach
Geschäftsführung: Dr. Michael Meskes, Jörg Folz, Sascha Heuer
Datenschutzerklärung: https://www.credativ.de/datenschutz
--- End Message ---
