Hi,

During a rebuild of all packages in sid, your package failed to build
on armhf.


Relevant part (hopefully):
The full build log is available from:
http://qa-logs.debian.net/2024/04/20/socket-wrapper_1.4.2-3_unstable-armhf.log

All bugs filed during this archive rebuild are listed at:
https://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=ftbfs-20240420;users=lucas@debian.org
or:
https://udd.debian.org/bugs/?release=na&merged=ign&fnewerval=7&flastmodval=7&fusertag=only&fusertagtag=ftbfs-20240420&fusertaguser=lucas@debian.org&allbugs=1&cseverity=1&ctags=1&caffected=1#results

A list of current common problems and possible solutions is available at
http://wiki.debian.org/qa.debian.org/FTBFS . You're welcome to contribute!

If you reassign this bug to another package, please mark it as 'affects'-ing
this package. See https://www.debian.org/Bugs/server-control#affects

If you fail to reproduce this, please provide a build log and diff it with mine
so that we can identify if something relevant changed in the meantime.

Just a warning that trying to brute force a fix for this is likely to
end badly.  A lot of developer time was spent to get to this current
delicate situation, which relied on the narrow behaviour that is now
eliminated by the Debian time_t 64 transition rules.

Socket-wrapper starts with:

/*
 * Make sure we do not redirect (f)open(at)() or fcntl() to their 64bit
 * variants
 */
#undef _FILE_OFFSET_BITS

This was added in
https://gitlab.com/cwrap/socket_wrapper/-/commit/bbe14cc3200ca553b13ed49357e2e88ba487eeaa

Setting  -D_FILE_OFFSET_BITS=64 will break the fcntl64 wrapper and so
break Samba's tests.

I don't know if there is a good fix for this actually.

Andrew Bartlett

64bit
https://gitlab.com/cwrap/socket_wrapper/-/commit/bbe14cc3200ca553b13ed49357e2e88ba487eeaa

How about simply dropping armv7 support from socket-wrapper and uid-
wrapper? Having architectures that are actually used being blocked by
these issues is suboptimal at best

Luca Boccassi <bluca@debian.org> writes:

Yes, I'm a bit uncertain how to fix these bugs, and lack time to debug
it.  If someone wants to help, please do!

/Simon

I am in the process of uploading a new upstream version into unstable
that disables armel+armhf builds.

While the bug has been discussed upstream, I didn't find a proper bug
report, so I filed this one:

https://bugzilla.samba.org/show_bug.cgi?id=15720

If anyone has time to debug or look into a fix for this, that would be
great!

/Simon

You don't need to explicitly disable the architecutres, if your
package won't successfully build on them.
Just have the existing binaries removed from unstable and you should
be good. And downgrade this bug's severity, of course.

Chris

severity -1 important
thanks

Chris Hofstaedtler <zeha@debian.org> writes:
believe downgrading this bug report is now okay, since after the recent
1.4.3-1 upload armel/armhf is simply no longer supported, so build
failures on those archs shouldn't happen any more.  I chose to keep the
bug report open as a reminder to patch upstream's code to support
armel+armhf.

I used the 'Build-Depends: not-supported-on [armel armhf]' approach to
disable builds on armel and armhf for 1.4.3-1.

What would you recommend doing now?  Is one or more of the following
ideas relevant?  Thanks for guidance.

1) Drop the B-D hack so that instead builds on armel+armhf will just
fail forever?  Won't that stall migration or lead to other problems?

2) Is requesting removal of libsocket-wrapper from unstable on
armel+armhf necessary?  Or will it happen automatically, since the
version in unstable on those archs are now not the latest?  I don't know
the unstable cleanup policy.

3) Should I open bug reports on the packages that Build-Depends on
libsocket-wrapper armel/armhf?  What should the recommendation be?  I
suspect most usages of this package is optional and not required for
building, so maybe a 'Build-Depends: libsocket-wrapper [!armel !armhf]'
would work?

4) Are any removal requests of reverse dependencies necessary or
relevant?  Will libsocket-wrapper migrate to testing without that?

/Simon

Makes sense. It's good to have the build failure documented.

Basically your choice. Some maintainers consider it cleaner to have
the "Architecture:" field list just the supported archs, or use a
"Build-Depends:" variant to fail building, or just fail building.

For architectures that are not armel or armhf I suppose it's nicer
to just fail building, as porters could then work on your package.
For armel and armhf it seems unlikely that such porters would show
up, so I wouldn't spend extra time on it.

"not-supported-on" is a bit weird as an invention, but workable. I
would probably have used "architecture-is-64-bit", as that's an
actual virtual package that has defined properties. But as said, it
doesn't really matter.

No. A package can fail to build on most architectures, and that's
"just fine". But please see the answer to 4) below.

Yes. You need to request this by filing a bug against
ftp.debian.org.

It doesn't happen automatically.

Yes. I'm not sure what the severity for such bugs should be; I think
if you already made the change in unstable, then these bugs can
immediately be release critical.

Yeah, if it is really optional, then that would work. Otherwise the
packages build-depending on libsocket-wrapper will also have to stop
being built; again that could just be because libsocket-wrapper will
be unavailable as a Build-Depends on armel armhf, or by explicitly
failing the build in some way.

Yes. You also should arrange for these removals before (or maybe
together) with the removal of libsocket-wrapper itself. One option
is to file all these bugs and have the bug for ftp.debian.org being
blocked by them.

No.

Testing migration will be blocked upon these things:

1) as long as old versions of your package exist in testing, build
failures are considered blocking. To get rid of the old versions in
testing, you have to ask for removal from unstable (!). (This sounds
weird, but it correct.)

2) if your package has autopkgtests and they previously succeeded on
an arch that you stop building for, the now "failing" autopkgtests
*may* block testing migration. If this happens, you'll have to ask
the release team to help you. The release team documents that they
want bugs to keep track of things, but sometimes asking nicely on
IRC in #debian-release also works.

3) as long as other packages need your package, either as
(Pre-)Depends or Build-Depends, testing migration will be blocked.
These need to be fixed.


Hope that helps!

Chris

Thank you so much for explaining!  Going down this path looks like it
involves more work than fixing the real upstream problem.  Even a
"solution" to add some ugly patch that hides the problem on armel+armhf
feels attractive now.  It feels a bit weird that removing things from
Debian has that property, but I'm sure there are good historical reasons
for all the steps of the process you describe.

Meanwhile, upstream has engaged in the bug report, so unless someone
else wants to take action on the removal path, I'm going to wait and
give upstream some time to look into this, and will try to help them
instead of working on the removal.

/Simon

Since socket_wrapper is a low level library which
wraps some syscalls, it should not be part of the time64
transition which we did for some 32-bit architectures
in debian.

The patch below fixes the build and runtime issues by
simply disabling the transition. It simply prevents that
"-D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -D_TIME_BITS=64"
gets added.

I've tested this patch on an armhf debian porterbox and on
a hppa 32-bit porterbox. Both machines were able to build
the package including successful testcase.

Please install.
Helge

We believe that the bug you reported is fixed in the latest version of
socket-wrapper, 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 1069450@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Simon Josefsson <simon@josefsson.org> (supplier of updated socket-wrapper 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, 05 Nov 2024 19:40:43 +0100
Source: socket-wrapper
Architecture: source
Version: 1.4.3-2
Distribution: unstable
Urgency: medium
Maintainer: Debian SSSD Team <pkg-sssd-devel@alioth-lists.debian.net>
Changed-By: Simon Josefsson <simon@josefsson.org>
Closes: 1069450
Changes:
 socket-wrapper (1.4.3-2) unstable; urgency=medium
 .
   [ Simon Josefsson ]
   * Mark our no-soname patch as not needing forwarding.
 .
   [ Helge Deller ]
   * Disable time64 transition.  Closes: #1069450.
Checksums-Sha1:
 0ec4c3656a34267bdccfcc649546956c664791f9 1896 socket-wrapper_1.4.3-2.dsc
 18d91caec5870d4eb8ad6f2ceb36b1a5c7e9dc83 8832 socket-wrapper_1.4.3-2.debian.tar.xz
 f9a734b7b695e1ff0f85b9acb4e35ee7b976daee 7017 socket-wrapper_1.4.3-2_amd64.buildinfo
Checksums-Sha256:
 6c2a8b57877f3555c343a2b3ef332b577e5348d3e6702cb0821b243d2466a73d 1896 socket-wrapper_1.4.3-2.dsc
 e4672b074a77aa55c986f6ccea4f7f3c769730508b0b2c28d392805811a0a4e2 8832 socket-wrapper_1.4.3-2.debian.tar.xz
 48c71f6b54603d8cb4fa622cab9636792637aebd8b67052f7c04bb92835603e3 7017 socket-wrapper_1.4.3-2_amd64.buildinfo
Files:
 2cbcdc3470b14cc944013ec7181b5d94 1896 devel optional socket-wrapper_1.4.3-2.dsc
 c054f7265b2d13d662df28a1b052db5e 8832 devel optional socket-wrapper_1.4.3-2.debian.tar.xz
 bfe359e99bd96a87793d13cada9f5eec 7017 devel optional socket-wrapper_1.4.3-2_amd64.buildinfo
-----BEGIN PGP SIGNATURE-----

iIoEARYIADIWIQSjzJyHC50xCrrUzy9RcisI/kdFogUCZypnshQcc2ltb25Aam9z
ZWZzc29uLm9yZwAKCRBRcisI/kdFohPFAQDDKTcK5qxM7ZnVBc06aJYXs4zCQz1f
dRrFNqNGR/mCGwEApIhwciinvkY0wOG+mSiYxoUxrz7wtyVNP9zSJI0IYgk=
=bjYM
-----END PGP SIGNATURE-----

(Resend to BTS only, since my last mail got rejected.)

Hi all,

socket-wrapper still fails its tests on armel and armhf, also blocking its
(and all dependencies') migration to testing. Since trixie freeze is coming
soon, I think we should try to fix this soon.

The failed autopkgtest [1] (take test_swrap_unit as example) actually passes on
build [2]. The offending -D_FILE_OFFSET_BITS=64 (and friends) in the command line
comes from upstream tests/CMakeLists.txt:

if (CMAKE_SIZEOF_VOID_P EQUAL 4)
    execute_process(
        COMMAND getconf LFS_CFLAGS
        OUTPUT_VARIABLE GETCONF_LFS_CFLAGS
        OUTPUT_STRIP_TRAILING_WHITESPACE)
    # Create a list from the string
    set(LFS_CFLAGS)
    if (GETCONF_LFS_CFLAGS)
        string(REPLACE " " ";" LFS_CFLAGS ${GETCONF_LFS_CFLAGS})
    endif()
    message(STATUS "Enabling large file support for tests: ${LFS_CFLAGS}")
endif()

And it is inverted (to be confirmed) by -U_FILE_OFFSET_BITS set by dpkg-buildflags
when abi=-time64 is specified when building. They are not set any more when
running autopkgtest, so things would go south.

I would recommend using consistent build flags in autopkgtest script, i.e., adding
something looking like in d/tests/tests:

export DEB_BUILD_MAINT_OPTIONS=abi=-time64
export CFLAGS=$(dpkg-buildflags --get CFLAGS)
export CPPFLAGS=$(dpkg-buildflags --get CPPFLAGS)

[1]: https://ci.debian.net/packages/s/socket-wrapper/testing/armhf/57471265/
[2]: https://buildd.debian.org/status/fetch.php?pkg=socket-wrapper&arch=armhf&ver=1.4.3-2&stamp=1730834460&raw=0

Thanks for working on this!  It is a bit delicate issue, and I've been
unable to find the right spell to fix things.  Could you propose this as
a Salsa merge request, or at least a concrete patch?  It would indeed be
nice to get this fixed and uploaded.

/Simon

Chen Shengqi <harry@debian.org> writes:

Hi Simon,

As I suggested, the patch should look like (not 100% sure it would work):

diff --git a/debian/tests/tests b/debian/tests/tests
index e164be5..2931d30 100755
--- a/debian/tests/tests
+++ b/debian/tests/tests
@@ -1,5 +1,10 @@
 #!/bin/sh
 set -e -u
+
+export DEB_BUILD_MAINT_OPTIONS=abi=-time64
+export CFLAGS=$(dpkg-buildflags --get CFLAGS)
+export CPPFLAGS=$(dpkg-buildflags --get CPPFLAGS)
+
 cp -a . "$AUTOPKGTEST_TMP"
 cd "$AUTOPKGTEST_TMP"
 rm -rf obj debian

P.S I would also suggest using make V=1 where possible to show the actual build commands.

I'm not certain this is the right approach, but we should do what it
takes to get the package into trixie.  I started with an upload of
1.4.4-1 that makes the build logs a bit more verbose, which may help to
debug things more.  Assuming debci still breaks, let's try your patch.
Salsa pipelines has armhf/armel builders, but not autopkgtest testing --
that would help the patch-test iteration cycle a bit.

/Simon

Chen Shengqi <harry@debian.org> writes:

Andrew Bartlett <abartlet@samba.org> writes:

One problem with the above is that this is the test will no longer
mimick reality: we cannot really ask that everyone adopts the same
non-time64 CFLAGS for everything they build.

At this point, I would be happy if we just got the package into trixie
and we may realize that it is somehow broken on armel/armhf.  That is
better than not having it available on amd64 and arm64 at all.

/Simon

The "will it work" is the key here.  Like Simon, I agree it is
delicate, and I'm not entirely convinced there is actually a valid
spell.

Andrew Bartlett

The 1.4.4-1 upload fails the same way in debci on armel+armhf, as
expected, but now we got more debug info to look at:

https://ci.debian.net/packages/s/socket-wrapper/testing/armel/58455649/
https://ci.debian.net/packages/s/socket-wrapper/testing/armhf/58455579/

Compare with working amd64 and i386:

https://ci.debian.net/packages/s/socket-wrapper/testing/amd64/58455500/
https://ci.debian.net/packages/s/socket-wrapper/testing/i386/58455619/

I have uploaded 1.4.4-2 with your patch as the only change, let's see
what happens.

/Simon

Simon Josefsson <simon@josefsson.org> writes:

Hi Simon,


Thank you for your prompt response. 1.4.4-2, however, is still failing
autopkgtest on armel / armhf. Miao Wang pointed out that it is due
to cmake not reading CPPFLAGS from env, so the needed flags is not
added to the gcc cmdline.

I will upload a new version with patched cmake call, i.e.:

CFLAGS="${CFLAGS} ${CPPFLAGS}” cmake -DUNIT_TESTING=1 -DCMAKE_VERBOSE_MAKEFILE=ON ..

Hi Simon,


Thank you for your prompt response. 1.4.4-2, however, is still failing
autopkgtest on armel / armhf. Miao Wang pointed out that it is due
to cmake not reading CPPFLAGS from env, so the needed flags is not
added to the gcc cmdline.

I will upload a new version with patched cmake call, i.e.:

CFLAGS="${CFLAGS} ${CPPFLAGS}” cmake -DUNIT_TESTING=1 -DCMAKE_VERBOSE_MAKEFILE=ON ..

Hi,

It works as intended, and tests on armhf and armel are passing again :).
But as you said, this certainly does not mean it works from the user side,
so I will keep an eye on possible bug reports on this.

BTW, sorry for not mentioning NMU in my upload.

Thanks,
Shengqi Chen