Dear maintainer:

During a rebuild of all packages in bullseye, your package failed to build:
--------------------------------------------------------------------------------
[...]
  debian/rules binary-arch
dh binary-arch --buildsystem=meson
    dh_update_autotools_config -a -O--buildsystem=meson
    dh_autoreconf -a -O--buildsystem=meson
    dh_auto_configure -a -O--buildsystem=meson
	cd obj-x86_64-linux-gnu && LC_ALL=C.UTF-8 meson .. --wrap-mode=nodownload --buildtype=plain --prefix=/usr --sysconfdir=/etc --localstatedir=/var --libdir=lib/x86_64-linux-gnu
The Meson build system
Version: 0.56.2
Source dir: /<<PKGBUILDDIR>>
Build dir: /<<PKGBUILDDIR>>/obj-x86_64-linux-gnu
Build type: native build
Project name: sshfs
Project version: 3.7.1
Using 'CFLAGS' from environment with value: '-g -O2 -ffile-prefix-map=/<<PKGBUILDDIR>>=. -fstack-protector-strong -Wformat -Werror=format-security'
Using 'LDFLAGS' from environment with value: '-Wl,-z,relro -Wl,-z,now'
Using 'CPPFLAGS' from environment with value: '-Wdate-time -D_FORTIFY_SOURCE=2'
C compiler for the host machine: cc (gcc 10.2.1 "cc (Debian 10.2.1-6) 10.2.1 20210110")
C linker for the host machine: cc ld.bfd 2.35.2
Using 'CFLAGS' from environment with value: '-g -O2 -ffile-prefix-map=/<<PKGBUILDDIR>>=. -fstack-protector-strong -Wformat -Werror=format-security'
Using 'LDFLAGS' from environment with value: '-Wl,-z,relro -Wl,-z,now'
Using 'CPPFLAGS' from environment with value: '-Wdate-time -D_FORTIFY_SOURCE=2'
Host machine cpu family: x86_64
Host machine cpu: x86_64
../meson.build:8: WARNING: Consider using the built-in warning_level option instead of using "-Wall".
../meson.build:8: WARNING: Consider using the built-in warning_level option instead of using "-Wextra".
Message: Compiler warns about unused result even when casting to void
Program rst2man found: YES (/usr/bin/rst2man)
Configuring config.h using configuration
Found pkg-config: /usr/bin/pkg-config (0.29.2)
Run-time dependency fuse3 found: YES 3.10.3
Run-time dependency glib-2.0 found: YES 2.66.8
Run-time dependency gthread-2.0 found: YES 2.66.8
Program utils/install_helper.sh found: YES (/<<PKGBUILDDIR>>/utils/install_helper.sh)
Build targets in project: 4

Option buildtype is: plain [default: debugoptimized]
Found ninja-1.10.1 at /usr/bin/ninja
    dh_auto_build -a -O--buildsystem=meson
	cd obj-x86_64-linux-gnu && LC_ALL=C.UTF-8 ninja -j1 -v
[1/7] cc -Isshfs.p -I. -I.. -I/usr/include/fuse3 -I/usr/include/glib-2.0 -I/usr/lib/x86_64-linux-gnu/glib-2.0/include -fdiagnostics-color=always -pipe -D_FILE_OFFSET_BITS=64 -Wall -Winvalid-pch -D_REENTRANT -DHAVE_CONFIG_H -Wall -Wextra -Wno-sign-compare -Wmissing-declarations -Wwrite-strings -Wno-unused-result -g -O2 -ffile-prefix-map=/<<PKGBUILDDIR>>=. -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -pthread -DFUSE_USE_VERSION=31 -MD -MQ sshfs.p/sshfs.c.o -MF sshfs.p/sshfs.c.o.d -o sshfs.p/sshfs.c.o -c ../sshfs.c
[2/7] cc -Isshfs.p -I. -I.. -I/usr/include/fuse3 -I/usr/include/glib-2.0 -I/usr/lib/x86_64-linux-gnu/glib-2.0/include -fdiagnostics-color=always -pipe -D_FILE_OFFSET_BITS=64 -Wall -Winvalid-pch -D_REENTRANT -DHAVE_CONFIG_H -Wall -Wextra -Wno-sign-compare -Wmissing-declarations -Wwrite-strings -Wno-unused-result -g -O2 -ffile-prefix-map=/<<PKGBUILDDIR>>=. -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -pthread -DFUSE_USE_VERSION=31 -MD -MQ sshfs.p/cache.c.o -MF sshfs.p/cache.c.o.d -o sshfs.p/cache.c.o -c ../cache.c
[3/7] cc  -o sshfs sshfs.p/sshfs.c.o sshfs.p/cache.c.o -Wl,--as-needed -Wl,--no-undefined -g -O2 -ffile-prefix-map=/<<PKGBUILDDIR>>=. -fstack-protector-strong -Wformat -Werror=format-security -Wl,-z,relro -Wl,-z,now -Wl,--start-group /usr/lib/x86_64-linux-gnu/libfuse3.so -lpthread /usr/lib/x86_64-linux-gnu/libglib-2.0.so /usr/lib/x86_64-linux-gnu/libgthread-2.0.so -Wl,--end-group -pthread
[4/7] /usr/bin/rst2man ../sshfs.rst sshfs.1
[5/7] cp -fPp ../test/conftest.py ../test/pytest.ini ../test/test_sshfs.py ../test/util.py /<<PKGBUILDDIR>>/obj-x86_64-linux-gnu/test
[6/7] cc -Itest/wrong_command.p -Itest -I../test -fdiagnostics-color=always -pipe -D_FILE_OFFSET_BITS=64 -Wall -Winvalid-pch -D_REENTRANT -DHAVE_CONFIG_H -Wall -Wextra -Wno-sign-compare -Wmissing-declarations -Wwrite-strings -Wno-unused-result -g -O2 -ffile-prefix-map=/<<PKGBUILDDIR>>=. -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -MD -MQ test/wrong_command.p/wrong_command.c.o -MF test/wrong_command.p/wrong_command.c.o.d -o test/wrong_command.p/wrong_command.c.o -c ../test/wrong_command.c
[7/7] cc  -o test/wrong_command test/wrong_command.p/wrong_command.c.o -Wl,--as-needed -Wl,--no-undefined -g -O2 -ffile-prefix-map=/<<PKGBUILDDIR>>=. -fstack-protector-strong -Wformat -Werror=format-security -Wl,-z,relro -Wl,-z,now
    debian/rules override_dh_auto_test
make[1]: Entering directory '/<<PKGBUILDDIR>>'
python3 -m pytest test/
============================= test session starts ==============================
platform linux -- Python 3.9.2, pytest-6.0.2, py-1.10.0, pluggy-0.13.0 -- /usr/bin/python3
cachedir: .pytest_cache
rootdir: /<<PKGBUILDDIR>>/test, configfile: pytest.ini
collecting ... collected 16 items

test/test_sshfs.py::test_sshfs[True-True-0-False] FAILED                 [  6%]

=================================== FAILURES ===================================

There are a couple of odd things about this bug.

First: it doesn't seem like an RC bug because the test manifestly runs fine on
buildds -- see https://buildd.debian.org/status/package.php?p=sshfs-fuse

I'd suggest to downgrade the bug on this basis.

Second: the bug log shows python 3.9.2 is used.  That hasn't been the default
python since 2021 -- so it's an unusual test environment.

El 5/2/23 a las 21:54, Steven Robbins escribió:

The package is trying to access the network. This is considered RC even if
it works in the official buildds.

Maybe I was reporting the failure in bullseye (because packages in stable must
build in stable).

Here is a recent build log from January in bookworm.

Thanks.

tags 1028163 + patch
thanks

Hi.

I propose that we make the package compliant with Policy 4.2 by disabling
the tests which blindly assume there is a ssh service running in the host
machine.

(Otherwise, what kind of build-depends should be used for that?)

The attached patch works for me.

To do it right without breaking Policy 4.2, the package should maybe
enable its own ssh service on a non-standard port to avoid conflict
with a more than possible standard ssh service in the host machine,
which may or may not be present.

Thanks.

El 5/2/23 a las 21:54, Steven Robbins escribió:

The tests do not even *run* on the buildds, because they are skipped.

Take this one for example:

https://buildd.debian.org/status/fetch.php?pkg=sshfs-fuse&arch=amd64&ver=3.7.3-1&stamp=1670232073&raw=0

test/test_sshfs.py::test_sshfs[True-True-0-False] SKIPPED (FUSE kern...) [  6%]
test/test_sshfs.py::test_sshfs[True-True-0-True] SKIPPED (FUSE kerne...) [ 12%]
test/test_sshfs.py::test_sshfs[True-True-1-False] SKIPPED (FUSE kern...) [ 18%]
test/test_sshfs.py::test_sshfs[True-True-1-True] SKIPPED (FUSE kerne...) [ 25%]
test/test_sshfs.py::test_sshfs[True-False-0-False] SKIPPED (FUSE ker...) [ 31%]
test/test_sshfs.py::test_sshfs[True-False-0-True] SKIPPED (FUSE kern...) [ 37%]
test/test_sshfs.py::test_sshfs[True-False-1-False] SKIPPED (FUSE ker...) [ 43%]
test/test_sshfs.py::test_sshfs[True-False-1-True] SKIPPED (FUSE kern...) [ 50%]
test/test_sshfs.py::test_sshfs[False-True-0-False] SKIPPED (FUSE ker...) [ 56%]
test/test_sshfs.py::test_sshfs[False-True-0-True] SKIPPED (FUSE kern...) [ 62%]
test/test_sshfs.py::test_sshfs[False-True-1-False] SKIPPED (FUSE ker...) [ 68%]
test/test_sshfs.py::test_sshfs[False-True-1-True] SKIPPED (FUSE kern...) [ 75%]
test/test_sshfs.py::test_sshfs[False-False-0-False] SKIPPED (FUSE ke...) [ 81%]
test/test_sshfs.py::test_sshfs[False-False-0-True] SKIPPED (FUSE ker...) [ 87%]
test/test_sshfs.py::test_sshfs[False-False-1-False] SKIPPED (FUSE ke...) [ 93%]
test/test_sshfs.py::test_sshfs[False-False-1-True] SKIPPED (FUSE ker...) [100%]

and also:

SKIPPED [16] test/test_sshfs.py:33: FUSE kernel module does not seem to be loaded

Those tests are being skipped in the buildds at least since version 2.10+repack-2.

Thanks.

severity 1028163 normal
thanks

Given the conditions to get this to trigger: Having a host sshd and the
ability to load kernel modules (or having specific kernel modules loaded), I
don't think this is a RC critical bug.

There is a test suite that is skipped if the kernel module is not loaded.

It would probably be nice to have it more detailed configured, but it is also
quite okay that once you load specific kernel modules *and* executes the tests
with the right users that it actually can be tested.

/Sune

El 6/2/23 a las 19:30, Sune Stolborg Vuorela escribió:

The "openssh-client" package is not build-essential, and it's not even installed
by default by debootstrap.

There was a consensus that a missing build-depends on a required-but-not-build-essential
package was not RC, and I'm no longer using "serious" for those bugs.

But this is not the case here.

Thanks.

But I think the larger point remains: there is no build failure in practice.
What is different in your environment that makes it fail?

El 7/2/23 a las 4:04, Steven Robbins escribió:
modules required to run the tests.

So, the ordinary user who wants to rebuild the package with or without changes
will be able to run the tests and they will see that it does not work at all
(command "ssh" is used for the tests and there is not even a build-depends
on openssh-client!).

My feeling is that the usual maintainers for this package have never built
this correctly in a chroot using dpkg-buildpackage in a clean chroot, or maybe
they have always used pbuilder and never noticed that the tests are skipped.

I'm changing my suggestion to disable the tests which do not work
using "@pytest.mark.skip", as there would still be the problem of using
ssh and requiring a build-depends.

The most simple and effective way to fix this (at this point of the
release cycle) is to skip the tests altogether for everybody, as in
the attached patch.

Dear maintainers: Would be possible to apply the attached patch?
(temporarily disable the tests until we find a way to do it right).

(Cc: to all people who did an upload in the last two years).

Thanks.

We believe that the bug you reported is fixed in the latest version of
sshfs-fuse, which is due to be installed in the Debian FTP archive.

A summary of the changes between this version and the previous one is
attached.

Thank you for reporting the bug, which will now be closed.  If you
have further comments please address them to 1028163@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Daniel Baumann <daniel.baumann@progress-linux.org> (supplier of updated sshfs-fuse package)

(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmaster@ftp-master.debian.org)
Format: 1.8
Date: Tue, 07 Feb 2023 20:33:53 +0100
Source: sshfs-fuse
Architecture: source
Version: 3.7.3-1.1
Distribution: unstable
Urgency: high
Maintainer: Bartosz Fenski <fenio@debian.org>
Changed-By: Daniel Baumann <daniel.baumann@progress-linux.org>
Closes: 1028163
Changes:
 sshfs-fuse (3.7.3-1.1) unstable; urgency=high
 .
   * Non-maintainer upload.
   * Disabling test suite (Closes: #1028163):
     - First, given that there's no progress on #1028163 for some time now,
       and it's not quite clear on how to "properly" address the issue
       of using ssh of the host during the test suite (maybe replacing
       test with autopkg tests?), I think it's better to disable the test
       suite for now rather than to have no sshfs at all (in bookworm).
     - Second, in order to prevent the risk of other packages to be autoremoved
       that depend on sshfs without having the chance of being re-introduced to
       testing after the upcoming freeze in case nobody fixes #1028163 properly,
       let's disable the test suite and re-enable it once it's clear how to deal
       with it (re-enabling test should be easier to get an unblock for).
Checksums-Sha1:
 9da3e54f6bb49da7a8f4f0eaa824a096d7c720d6 1983 sshfs-fuse_3.7.3-1.1.dsc
 75b2c17a60a7629057f46a4826b89a28023e630e 8308 sshfs-fuse_3.7.3-1.1.debian.tar.xz
 e3324d1855414b25409ebc9ab6c387cf4c687df3 8112 sshfs-fuse_3.7.3-1.1_amd64.buildinfo
Checksums-Sha256:
 4e99ccd8e526d0ab5940f057760638a652265d597168d95637b8fbc2f2bebbe2 1983 sshfs-fuse_3.7.3-1.1.dsc
 8e5e792818fad69a66172d7465829c53b5a282b04cd3bd4ce86553cffba0cd41 8308 sshfs-fuse_3.7.3-1.1.debian.tar.xz
 06a968926ca805fb3361e7ff84515ba74ff6fd56649dd45611b822dfb92218ec 8112 sshfs-fuse_3.7.3-1.1_amd64.buildinfo
Files:
 8751f49608722ad6c53d46baf0e4d47d 1983 utils optional sshfs-fuse_3.7.3-1.1.dsc
 31c1d564066f0874740b2fbe005ae154 8308 utils optional sshfs-fuse_3.7.3-1.1.debian.tar.xz
 895bb89d5fec8c46ef1b4da31398fd06 8112 utils optional sshfs-fuse_3.7.3-1.1_amd64.buildinfo
-----BEGIN PGP SIGNATURE-----

iQIzBAEBCgAdFiEEgTbtJcfWfpLHSkKSVc8b+YaruccFAmPiuVgACgkQVc8b+Yar
ucf7bQ//fktCV4AvAq33wifFUU57dZjdrPDZiy4HZgeOGGDnk3pdR8Tomk3wjiiY
hgkPN8Cp8RI1yFkctHahz0VAsls3s4rHXmI4Cl3TfjK9z0vXxWJgAxsInkQQCnZ3
ZFxOgIQwdgjlBKQ1BlG0mafmmQTz7lcCW8cKrrfutc9ymj+XQ9pBawNET7x6/+x6
eyvuuDrW6v4Um1nMXQqoUhEqgxMvDJJiznI7B+uFRubrFb1zJ5zVlRpe62iwqCBY
PMNMMlhMxG9agnf9Jt6BeAiNnbXVOJN1RoeVLu26tiDvIA0UdVbQOi/1rLso34jQ
DL7c2I5wD2lar9WJ2l7rApfAc5sLsLt7teoqWTSv0iR2/NQiqHTPspbGFlRf4HoY
trcP/oJPPJeY3ZVmNuP+AsteS0FRUxbNcArX86j4Et2Rg5vT649weG2IUcgReF9v
kKxuhU8y8ZNtSnYqvJhfTPsVAksVmV4C0BuYC2xe6Ry+YjgxONAEMlaYQRD3aMNE
vYTUv8pfMeXmHi/YTx/U91flv0j+Xsbi9uKlKnbie7vFaYkxOwrem0oZ/kotC/oL
Dr4XTbk+slinbulefRg1M6QektYDzvhayv+1FUW2M7JudghdU70FQfLexewcpl3T
T4CwHRB9M9pN/Ez5ZVUbiMdOnmgXK7JmIFaM7U4nuWEwucgayI4=
=ch9w
-----END PGP SIGNATURE-----