[PATCH] Fix test_command_exec test (t-command)
Hello, 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). 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. I am not subscribed to the list, please CC me. Greetings, Sören >From d57373153f86770bda9298b69a2ada8ce676769c Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?S=C3=B6ren=20Tempel?= Date: Thu, 27 Aug 2020 21:43:40 +0200 Subject: [PATCH] t-command: Fix test_command_exec program invocation >From exec(3): The argument arg0 should point to a filename string that is associated with the process being started by one of the exec functions. Unfortunately, this test sets arg0 to the string "arg 0" this causes the busybox multicall binary on Alpine Linux to assume that the applet "arg 0" (instead of true) should be executed. However, as such an applet does not exist, the tests fails. This commit fixes the failing test by setting arg0 correctly (as other parts of the dpkg codebase using the command API do too). --- lib/dpkg/t/t-command.c | 1 + 1 file changed, 1 insertion(+) diff --git a/lib/dpkg/t/t-command.c b/lib/dpkg/t/t-command.c index 099884560..aeed7a1f2 100644 --- a/lib/dpkg/t/t-command.c +++ b/lib/dpkg/t/t-command.c @@ -170,6 +170,7 @@ test_command_exec(void) command_init(&cmd, "true", "exec test"); + command_add_arg(&cmd, "true"); command_add_arg(&cmd, "arg 0"); command_add_arg(&cmd, "arg 1");
Re: [PATCH] Fix test_command_exec test (t-command)
Hi, 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). See: http://musl.libc.org/time64.html > Undefined behavior and unwarranted assumptions: > • Use of %ld format to print time_t or suseconds_t. Greetings, Sören Sören Tempel wrote: > Hello, > > 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). > > 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. > > I am not subscribed to the list, please CC me. > > Greetings, > Sören > > From d57373153f86770bda9298b69a2ada8ce676769c Mon Sep 17 00:00:00 2001 > From: =?UTF-8?q?S=C3=B6ren=20Tempel?= > Date: Thu, 27 Aug 2020 21:43:40 +0200 > Subject: [PATCH] t-command: Fix test_command_exec program invocation > > From exec(3): > > The argument arg0 should point to a filename string that is > associated with the process being started by one of the exec > functions. > > Unfortunately, this test sets arg0 to the string "arg 0" this causes the > busybox multicall binary on Alpine Linux to assume that the applet "arg > 0" (instead of true) should be executed. However, as such an applet does > not exist, the tests fails. This commit fixes the failing test by > setting arg0 correctly (as other parts of the dpkg codebase using the > command API do too). > --- > lib/dpkg/t/t-command.c | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/lib/dpkg/t/t-command.c b/lib/dpkg/t/t-command.c > index 099884560..aeed7a1f2 100644 > --- a/lib/dpkg/t/t-command.c > +++ b/lib/dpkg/t/t-command.c > @@ -170,6 +170,7 @@ test_command_exec(void) > > command_init(&cmd, "true", "exec test"); > > + command_add_arg(&cmd, "true"); > command_add_arg(&cmd, "arg 0"); > command_add_arg(&cmd, "arg 1"); >
Re: dpkg: error: info database format (2)
On Sun, 2020-08-23 at 08:25:11 +0300, sam wrote: > I have been having below error with below command. > > $ sudo apt-get update && sudo apt-get upgrade > > Do you want to continue? [Y/n] y > dpkg: error: info database format (2) is bogus or too new; try getting a > newer dpkg > E: Sub-process /usr/bin/dpkg returned an error code (2) > > What I should do the next to get freedom of above error ?? Well that database format is the one for the mtree layout, which has never even been in git master, less so in any upstream release. So either you installed dpkg from that branch or some unofficial repo or similar? Which would mean you database has probably been switched, depending on what code base that was based on, and reverting that change would also depend on that. Otherwise the only other explanation I can think of is someone manually edited that file? Regards, Guillem
Re: [PATCH] Fix test_command_exec test (t-command)
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 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