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

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

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

Attachment: signature.asc
Description: PGP signature

Reply via email to