$USER and $LOGNAME unset in sbuild on goedel (alpha) and zandonai (s390) (and peri (hppa)?)

[Magnus Holmgren]

Hi!

Some of the tests of lsh-utils failed on hppa, alpha, and s390
(https://buildd.debian.org/status/package.php?p=lsh-utils) after I enabled
them, the reason being that they expect $USER or $LOGNAME to be set. Is there
some particular reason that this is the case (shouldn't one expect these
variables to be set?) or was the environment merely cleaned a bit too
thoroughly?

Subsequent to the first failure on hppa, someone apparently noticed and
scheduled a rebuild, which went fine, although on a different machine
(penalosa).

[Kurt Roeckx]

Post by Magnus Holmgren
Hi!
Some of the tests of lsh-utils failed on hppa, alpha, and s390
(https://buildd.debian.org/status/package.php?p=lsh-utils) after I enabled
them, the reason being that they expect $USER or $LOGNAME to be set. Is there
some particular reason that this is the case (shouldn't one expect these
variables to be set?) or was the environment merely cleaned a bit too
thoroughly?

The behaviour should be the same on all buildds since they should
all be using the same software. I've tried it manually and
both are set.


Kurt

[Magnus Holmgren]

Post by Kurt Roeckx

Post by Magnus Holmgren
Hi!
Some of the tests of lsh-utils failed on hppa, alpha, and s390
(https://buildd.debian.org/status/package.php?p=lsh-utils) after I
enabled them, the reason being that they expect $USER or $LOGNAME to be
set. Is there some particular reason that this is the case (shouldn't
one expect these variables to be set?) or was the environment merely
cleaned a bit too thoroughly?

The behaviour should be the same on all buildds since they should
all be using the same software. I've tried it manually and
both are set.

Strange. What could be the problem then? The code looks something like this:

#define USER_NAME_FROM_ENV(s) do { \
(s) = getenv("LOGNAME"); \
if (!(s)) \
(s) = getenv("USER"); \
} while (0)

...

USER_NAME_FROM_ENV(self->user);

...

if (!options->user)
{
argp_error(state, "No user name given. Use the -l option, or set LOGNAME
in the environment.");
break;
}

[Witold Baryluk]

Post by Magnus Holmgren

Post by Kurt Roeckx

Post by Magnus Holmgren
Hi!
Some of the tests of lsh-utils failed on hppa, alpha, and s390
(https://buildd.debian.org/status/package.php?p=lsh-utils) after I
enabled them, the reason being that they expect $USER or $LOGNAME to be
set. Is there some particular reason that this is the case (shouldn't
one expect these variables to be set?) or was the environment merely
cleaned a bit too thoroughly?

The behaviour should be the same on all buildds since they should
all be using the same software. I've tried it manually and
both are set.

#define USER_NAME_FROM_ENV(s) do { \
(s) = getenv("LOGNAME"); \
if (!(s)) \
(s) = getenv("USER"); \
} while (0)
...
USER_NAME_FROM_ENV(self->user);
...
if (!options->user)
{
argp_error(state, "No user name given. Use the -l option, or set LOGNAME
in the environment.");
break;
}
--
Debian Developer

Hmm, probably stupid question, but is self == options ?


It can be also some memory corruption (as always),
which only shows on little-endian machines, or something :)

Create smaller test case, with just this small snippet.

PS. I created similar sample code in C, and it works properly.