On Mon, 19 Aug 2024 16:04:25 +0300 Faidon Liambotis <parav...@debian.org> wrote:
> On Sun, Aug 18, 2024 at 10:00:57PM +0200, Stefano Brivio wrote: > > Thanks Uroš for reporting and Faidon for the analysis! > > Thanks for the quick response! > > > > In this case, there is a comment that states: > > > * #syscalls clock_gettime arm:clock_gettime64 > > > ...but on i386, and likely other 32-bit architectures (like 32-bit arm, > > > which is seemingly already handled), glibc's clock_gettime() is wrapping > > > the clock_gettime64 syscall. > > > > I tested the full functionality on armhf quite recently, so I don't > > think there should be issues with this, but I'll give it another run. > > Was this before or after the time64 (and implicit LFS) transition? It turns out it was before that, and things actually started failing now, so I just posted a patch for armhf: https://archives.passt.top/passt-dev/20240819231529.1482175-1-sbri...@redhat.com/ > This > may affect the syscalls being used by the glibc wrappers... Note that > AIUI i386 is special, as it did not/will not migrate to time64. So it > may just well be that armhf works, but i386 doesn't. So, back to the original issue, that should be solved by: https://archives.passt.top/passt-dev/20240819231407.1481337-1-sbri...@redhat.com/ I plan to make a new release and update the package soon (days to a couple of weeks), then we can close this I guess. > > I'll run the full test suite on i686 and check if anything is missing. > > Unfortunately, I can't easily turn the existing upstream test suite > > into an autopkgtest, because it's rather complicated as it involves > > setting up guests with throughput tests. > > > > But we're working on a new approach to the test framework that should > > eventually enable some degree of modularity, and make > > running it as part of autopkgtests feasible. > > Ah that's great to hear! These issues can be tricky to identify and > diagnose. You could use the "isolation-machine" autopkgtest restriction > (as we do in e.g. crun) to run integration tests, but I think these only > work on amd64 at the moment which makes this moot... Ah, yes, that topic just came up recently at https://github.com/containers/podman/discussions/23558#discussioncomment-10334370. What we have upstream at the moment should actually cover multiple architectures: https://passt.top/passt/tree/test/distro those perform basic tests on a bunch of different architectures using QEMU TCG, but they take quite some time to run, and it's difficult to maintain them because those guest images disappear or change from time to time, and there's no single distribution consistently shipping guest images for all the architectures Debian supports. So they are currently disabled and it's been a while since the last time I ran them. Anyway, if we could run a small set of tests on multiple architectures with pasta only (no guests), we wouldn't probably need the isolation-machine restriction, and that would catch virtually all the issues we might hit because of architecture differences. > > > 1: "i686" because seccomp.sh calls `uname -m` if there is no TARGET > > > specified, which I think is a (cross-)portability bug of its own... > > > > On Debian builds (and I guess most other distribution builds, really) > > TARGET is always passed, we use `uname -m` as a fallback option only, > > so that if you just want to type 'make', you can do that. See also > > https://salsa.debian.org/reproducible-builds/reprotest/-/issues/6#note_386163 > > > > Ah, I see. What threw me off was that I had to use i686 in the code > comments, rather than i386, which is the Debian arch name. Right, yes, I'm trying to stick to Linux architecture names for those comments. -- Stefano
