Hi! On Thu, 2020-08-27 at 23:00:43 +0200, Sören Tempel wrote: > Noticed one more thing: dpkg uses '%ld' to print values of the time_t > type. This does, however, not work on 32-Bit Alpine Linux architectures > (which use musl libc) as musl libc recently switched to a 64-Bit (long > long int) time_t on 32-bit arches. This causes dpkg test failures on > Alpine 32-bit architectures (e.g. armhf).
Oh, this needs fixing, yes. I've switched now locally almost all time_t usage to intmax_t, and added some protection for 64-bit time for file formats not supporting that large of a precession. Will include this in git in my next push. > Sören Tempel <soe...@soeren-tempel.net> wrote: > > Hope this is the right please to sent patches for dpkg. I am currently > > trying to get the dpkg test suite to pass for our Alpine Linux dpkg > > package. While doing so I noticed a mistake in the test_command_exec() > > function from t-command.c, the function doesn't set arg0 correctly. This > > causes the test to fail as our busybox multicall binary (which provides > > /bin/true) is not capable of finding an applet for "arg 0". Other > > invocations of command_exec in dpkg explicitly set arg0 manually too. > > The patch is attached as a git-format-patch(1). Indeed, thanks for the patch! Will include it in git in my next push. > > The only remaining test failing on Alpine is ./t/dpkg_buildpackage.t it > > fails with: ”error: Unmet build dependencies: build-essential:native“. > > I guess that's because we don't actually use dpkg and don't have a > > build-essential package? I disabled the test for now, if there is any > > way to make it pass please let me know. Ah, right, because the code uses the local t/origins/ directory with the default vendor pointing to debian, which means the Dpkg::Vendor::Debian module is used which makes the program require that build-dependency. I'll check how to handle that on non-Debian-based distributions. Thanks, Guillem
