[Qa-jenkins-dev] Bug#903545: Bug#903545: reproducible: Please don't vary kernel architecture personality

[Vagrant Cascadian]

On 2018-07-11, Christoph Berg wrote:
> 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

The running kernel shouldn't be used to determine the userspace
architecture.

Using "uname -m" for this in not really accurate or reliable; patching
the Makefiles to use the appropriate architecture information according
to dpkg would be one option for debian-based packages, at least. Not
sure what a good approach for an upstream solution would be off the top
of my head.


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


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


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


live well,
  vagrant
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 832 bytes
Desc: not available
URL: <http://alioth-lists.debian.net/pipermail/qa-jenkins-dev/attachments/20180711/7c9d8d9b/attachment.sig>