Bug#1056348: FTBFS: tests fail in clean environment

2023-11-28 Thread Steve McIntyre
Hey Nicolas!

On Fri, Nov 24, 2023 at 11:26:25AM -0500, Nicolas Mora wrote:
>Hello,
>
>I've forwarded the bug upstream [1] and they made a patch [2].
>
>Can you test their patch on your package, to check if the problem is fixed on
>your CI?
>
>Also, if this works, I suggest to apply their patch rather than yours to make
>the code more consistent with upstream, do you agree?
>
>[1] https://github.com/libssh2/libssh2/issues/1240
>[2] https://github.com/libssh2/libssh2/pull/1241

Thanks, that looks sane enough here! :-)

-- 
Steve McIntyre, Cambridge, UK.st...@einval.com
"War does not determine who is right - only who is left."
   -- Bertrand Russell



Bug#1056348: FTBFS: tests fail in clean environment

2023-11-24 Thread Nicolas Mora

Hello,

I've forwarded the bug upstream [1] and they made a patch [2].

Can you test their patch on your package, to check if the problem is 
fixed on your CI?


Also, if this works, I suggest to apply their patch rather than yours to 
make the code more consistent with upstream, do you agree?


[1] https://github.com/libssh2/libssh2/issues/1240
[2] https://github.com/libssh2/libssh2/pull/1241



Bug#1056348: FTBFS: tests fail in clean environment

2023-11-23 Thread Nicolas Mora

Le 2023-11-23 à 11 h 20, Steve McIntyre a écrit :


AFAICS in a non-interactive environment, USER isn't required to be set
but LOGNAME is; see

   https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap08.html

Alternatively, the tets should probably be calling get(e)uid and
getpwent() rather than relying on the environment here.



Indeed, I also had the same conclusion using other documentation.

But then, if LOGNAME is mandatory, I suppose it would be better to use 
$LOGNAME alone instead of the condition.


(I'm not refusing your patch, I just try to see if there's a better and 
cleaner way to fix it)


I'll open a bug upstream to get their feedback on this

/Nicolas



Bug#1056348: FTBFS: tests fail in clean environment

2023-11-23 Thread Steve McIntyre
On Thu, Nov 23, 2023 at 10:46:34AM -0500, Nicolas Mora wrote:
>Le 2023-11-23 à 09 h 46, Steve McIntyre a écrit :
>> 
>> Ah, apologies - that version is bogus, it's just the version on the
>> bullseye machine I ran reportbug from.
>> 
>> The tests are failing on current unstable source.
>> 
>
>OK, makes more sense then.
>
>Nevertheless I'm wondering about the seriousness of the bug, I can't
>reproduce on my environment and all the buildd environments where libssh2 is
>built don't have the problem.

AFAICS in a non-interactive environment, USER isn't required to be set
but LOGNAME is; see

  https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap08.html

Alternatively, the tets should probably be calling get(e)uid and
getpwent() rather than relying on the environment here.

>Could your issue be fixed by running something like this?
>USER=$LOGNAME dpkg-buiildpackage
>
>I'm just wondering if the patch is worth applying it to fix a less probable
>case.

The tests failed in a CI system we use at work, so I needed to fix it
there. The patch just adds fallback here, and makes things more robust.

-- 
Steve McIntyre, Cambridge, UK.st...@einval.com
You raise the blade, you make the change... You re-arrange me 'til I'm sane...



Bug#1056348: FTBFS: tests fail in clean environment

2023-11-23 Thread Nicolas Mora

Le 2023-11-23 à 09 h 46, Steve McIntyre a écrit :


Ah, apologies - that version is bogus, it's just the version on the
bullseye machine I ran reportbug from.

The tests are failing on current unstable source.



OK, makes more sense then.

Nevertheless I'm wondering about the seriousness of the bug, I can't 
reproduce on my environment and all the buildd environments where 
libssh2 is built don't have the problem.


Could your issue be fixed by running something like this?
USER=$LOGNAME dpkg-buiildpackage

I'm just wondering if the patch is worth applying it to fix a less 
probable case.


/Nicolas



Bug#1056348: FTBFS: tests fail in clean environment

2023-11-23 Thread Steve McIntyre
On Thu, Nov 23, 2023 at 09:20:37AM -0500, Nicolas Mora wrote:
>Hello,
>
>On Tue, 21 Nov 2023 13:30:31 + Steve McIntyre  wrote:
>> Source: libssh2
>> Version: 1.9.0-2
>> Severity: serious
>> Tags: ftbfs patch
>> 
>> Hi!
>> 
>> Building libssh2 using debuild in a clean local chroot, I get test
>> failures and even a core dump!
>> 
>Thanks for reporting the bug, although I have concerns on its scope.
>
>The package you have found the issue is the bullseye one, and the package
>updates for oldstable are allowed mostly for security patches.
>
>Your bug is related to the test suite, and the patch won't change the binary
>files in the package, so I assume the patch isn't going to be allowed for
>proposed-updates.
>
>I've added the release team to ask for their opinion.
>
>Friends from the release team, do you have a feedback on this?

Ah, apologies - that version is bogus, it's just the version on the
bullseye machine I ran reportbug from.

The tests are failing on current unstable source.

-- 
Steve McIntyre, Cambridge, UK.st...@einval.com
You lock the door
And throw away the key
There's someone in my head but it's not me 



Bug#1056348: FTBFS: tests fail in clean environment

2023-11-23 Thread Nicolas Mora

Hello,

On Tue, 21 Nov 2023 13:30:31 + Steve McIntyre  wrote:

Source: libssh2
Version: 1.9.0-2
Severity: serious
Tags: ftbfs patch

Hi!

Building libssh2 using debuild in a clean local chroot, I get test
failures and even a core dump!


Thanks for reporting the bug, although I have concerns on its scope.

The package you have found the issue is the bullseye one, and the 
package updates for oldstable are allowed mostly for security patches.


Your bug is related to the test suite, and the patch won't change the 
binary files in the package, so I assume the patch isn't going to be 
allowed for proposed-updates.


I've added the release team to ask for their opinion.

Friends from the release team, do you have a feedback on this?

/Nicolas



Bug#1056348: FTBFS: tests fail in clean environment

2023-11-21 Thread Steve McIntyre
Source: libssh2
Version: 1.9.0-2
Severity: serious
Tags: ftbfs patch

Hi!

Building libssh2 using debuild in a clean local chroot, I get test
failures and even a core dump!

...

PASS: mansyntax.sh  


PASS: test_simple   


FAIL: test_sshd.test 1 - sshd-test_ssh2 


FAIL: test_sshd.test 2 - sshd-test_auth_pubkey_ok_ed25519   


=   


   libssh2 -: tests/test-suite.log
=

# TOTAL: 4
# PASS:  2
# SKIP:  0
# XFAIL: 0
# FAIL:  2
# XPASS: 0
# ERROR: 0

.. contents:: :depth: 2

FAIL: test_sshd
===

Fingerprint: 12 FD AD 1E 3B 31 B1 0B AB B0 0F 2A 8D 1B 9A 62 C3 26 BD 2F 
Authentication methods: publickey,password,keyboard-interactive
Authentication by public key failed!
all done
./test_sshd.test: line 131: 2476672 Segmentation fault  (core dumped) 
"${test}"
# sshd executable: '/usr/sbin/sshd' (OpenSSH_9.4, OpenSSL 3.0.12 24 Oct 2023)
# ssh executable: '/usr/bin/ssh' (OpenSSH_9.4p1 Debian-1, OpenSSL 3.0.12 24 Oct 
2023)
1..2
not ok 1 - sshd-test_ssh2
FAIL: test_sshd.test 1 - sshd-test_ssh2
not ok 2 - sshd-test_auth_pubkey_ok_ed25519
FAIL: test_sshd.test 2 - sshd-test_auth_pubkey_ok_ed25519


Testsuite summary for libssh2 -

# TOTAL: 4
# PASS:  2
# SKIP:  0
# XFAIL: 0
# FAIL:  2
# XPASS: 0
# ERROR: 0


These are both down to environment: the test code assumes that "USER"
is a valid environment varliable, which is not necessarily
true. Here's a patch which fixes this for these two tests, and fails
cleanly with diagnostics if there's a problem.

-- System Information:
Debian Release: 11.8
  APT prefers oldstable-updates
  APT policy: (500, 'oldstable-updates'), (500, 'oldstable-security'), (500, 
'oldoldstable'), (500, 'oldstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.10.0-26-amd64 (SMP w/8 CPU threads)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_GB:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
diff --git a/tests/session_fixture.c b/tests/session_fixture.c
index 3bb9da2..4671117 100644
--- a/tests/session_fixture.c
+++ b/tests/session_fixture.c
@@ -430,11 +430,18 @@ int test_auth_pubkey(LIBSSH2_SESSION *session, int flags,
 
 /* Ignore our hard-wired Dockerfile user when not running under Docker */
 if(!openssh_fixture_have_docker() && strcmp(username, "libssh2") == 0) {
-username = getenv("USER");
+if(getenv("USER"))
+username = getenv("USER");
+else if(getenv("LOGNAME"))
+username = getenv("LOGNAME");
 #ifdef WIN32
-if(!username)
+else if(getenv("USERNAME"))
 username = getenv("USERNAME");
 #endif
+else {
+fprintf(stderr, "Failed to find a username from env\n");
+return 1;
+}
 }
 
 userauth_list = libssh2_userauth_list(session, username,
diff --git a/tests/test_ssh2.c b/tests/test_ssh2.c
index a637cdc..6e28598 100644
--- a/tests/test_ssh2.c
+++ b/tests/test_ssh2.c
@@ -63,10 +63,16 @@ int main(int argc, char *argv[])
 
 if(getenv("USER"))
 username = getenv("USER");
+else if(getenv("LOGNAME"))
+username = getenv("LOGNAME");
 #ifdef WIN32
 else if(getenv("USERNAME"))
 username = getenv("USERNAME");
 #endif
+else {
+fprintf(stderr, "Failed to find a username from env\n");
+return 1;
+}
 
 if(getenv("PRIVKEY"))
 privkey = getenv("PRIVKEY");