update-motd fails autopkg test on armhf in noble, blocking python3-defaults

[Matthias Klose]

on armhf, update-motd fails autopkg test in noble, blocking python3-defaults:

309s autopkgtest [23:36:25]: test update-motd: [-----------------------
312s Attempting to lock /var/lib/apt/lists/lock to wait for any currently running apt updates to finish... Traceback (most recent call last):
312s File "/tmp/autopkgtest.WSDKm0/build.ply/src/debian/tests/wait-for-apt-update-to-finish", line 31, in <module>
312s rv = fcntl.fcntl(f, fcntl.F_SETLKW, lockdata)
312s ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
312s OSError: [Errno 22] Invalid argument
312s autopkgtest [23:36:28]: test update-motd: -----------------------]
315s update-motd FAIL non-zero exit status 1
315s autopkgtest [23:36:31]: test update-motd: - - - - - - - - - - results - - - - - - - - - -
316s autopkgtest [23:36:32]: test update-motd: - - - - - - - - - - stderr - - - - - - - - - -
316s Traceback (most recent call last):
316s File "/tmp/autopkgtest.WSDKm0/build.ply/src/debian/tests/wait-for-apt-update-to-finish", line 31, in <module>
316s rv = fcntl.fcntl(f, fcntl.F_SETLKW, lockdata)
316s ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
316s OSError: [Errno 22] Invalid argument
319s autopkgtest [23:36:35]: @@@@@@@@@@@@@@@@@@@@ summary
319s show-motd PASS
319s update-motd FAIL non-zero exit status 1

[Andreas Hasenack (ahasenack)]

I can reproduce this in an armhf container on an arm64 host.

With python3.11, it works. With python 3.12, it doesn't. We should be able to narrow this down now.

root@n-armhf:~# python3.12 ./wait-for-apt-update-to-finish
lockdata = b'\x01\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00'
Attempting to lock /var/lib/apt/lists/lock to wait for any currently running apt updates to finish... Traceback (most recent call last):
  File "/root/./wait-for-apt-update-to-finish", line 33, in <module>
    rv = fcntl.fcntl(f, fcntl.F_SETLKW, lockdata)
         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
OSError: [Errno 22] Invalid argument

root@n-armhf:~# python3.11 ./wait-for-apt-update-to-finish
lockdata = b'\x01\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00'
Attempting to lock /var/lib/apt/lists/lock to wait for any currently running apt updates to finish... locked, exiting.

root@n-armhf:~# uname -a
Linux n-armhf 6.5.0-17-generic #17-Ubuntu SMP PREEMPT_DYNAMIC Thu Jan 11 14:20:13 UTC 2024 armv8l armv8l armv8l GNU/Linux

root@n-armhf:~# dpkg --print-architecture
armhf

[Andreas Hasenack (ahasenack)]

With python 3.12:
5025 fcntl64(3, F_SETLKW64, {l_type=F_WRLCK, l_whence=SEEK_SET, l_start=0, l_len=-603427954308686296}) = -1 EINVAL (Invalid argument)

That looks like an invalid len indeed.

With python 3.11 it's:
5031 fcntl64(3, F_SETLKW64, {l_type=F_WRLCK, l_whence=SEEK_SET, l_start=0, l_len=12746825536}) = 0

[Andreas Hasenack (ahasenack)]

waveform on irc #ubuntu-devel figured it out:

<waveform> ahasenack, just had a bit of a google around and ran across the fcntl module tests in python (https://github.com/python/cpython/blob/main/Lib/test/test_fcntl.py) -- of particular interest is get_lockdata from line 53
<waveform> following that down we can see that on linux it'll use the struct 'hh'+start_len+'hh'; start_len is ll on platforms without os.O_LARGEFILE, but qq on platforms with (which would suggest the struct in use is too short on armhf?)
<waveform> (assuming armhf has os.O_LARGEFILE -- I'll try and check that in a bit)
<waveform> yes, armhf has os.O_LARGEFILE so it'll be using a struct that's too short

Looks like all our arches have os.O_LARGEFILE defined, so the size should be qq everywhere.

I'll prepare a branch with that change, but it also looks like we could just drop this script. When it was added, it was claimed that freedombox caused the issue[1], but that is gone[2] now.

1. https://git.launchpad.net/ubuntu/+source/update-motd/commit/?id=c060dd002473f5700d8db3916bd8da122ec94fc3
2. https://git.launchpad.net/ubuntu/+source/update-motd/commit/?id=1fb924d7cb573df5202a16d93ebcae1e20d62e2a

[Andreas Hasenack (ahasenack)]

Testing this fix:

https://code.launchpad.net/~ahasenack/ubuntu/+source/update-motd/+git/update-motd/+ref/noble-update-motd-fix-fcntl-size

Not sure the tests will finish tonight, but at the latest tomorrow (my) morning they will be green and this can be uploaded.

[Andreas Hasenack (ahasenack)]

All tests except s390x finished and are green. s390x has been running for ~14min and produced no output, so something is off there. I'll upload anyway:

Uploading update-motd_3.12.dsc
Uploading update-motd_3.12.tar.xz
Uploading update-motd_3.12_source.buildinfo
Uploading update-motd_3.12_source.changes

[Launchpad Janitor (janitor)]

This bug was fixed in the package update-motd - 3.12

---------------
update-motd (3.12) noble; urgency=medium

  * d/t/wait-for-apt-update-to-finish: adjust start_len for the fcntl
    call according to the os.O_LARGEFILE definition (LP: #2054369)

 -- Andreas Hasenack <email address hidden> Wed, 21 Feb 2024 20:53:27 -0300