[PATCH] Fix test_command_exec test (t-command)

2020-08-27 Thread Sören Tempel
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)

2020-08-27 Thread Sören Tempel
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)

2020-08-27 Thread Guillem Jover
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)

2020-08-27 Thread Guillem Jover
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