Your message dated Fri, 16 Sep 2022 11:00:36 +0200
with message-id <166331883603.1158954.3015680733964701818@localhost>
and subject line Re: Bug#1015853: sbuild: fails to use foreign --extra-package
has caused the Debian Bug report #1015853,
regarding sbuild: fails to use foreign --extra-package
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact [email protected]
immediately.)
--
1015853: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1015853
Debian Bug Tracking System
Contact [email protected] with problems
--- Begin Message ---
Package: sbuild
Version: 0.83.1
X-Debbugs-Cc: [email protected]
Control: submitter -1 [email protected]
Hi,
Antonio attempted cross building a ruby extension with a custom gem2deb
and tried doing so with sbuild --extra-package. Apparently, that didn't
work out.
I tried:
sbuild --host=arm64 -d unstable --extra-package=./hostname_..._arm64.deb
hostname
This is kinda stupid, I know, but we see this:
| Err:4 file:/build/hostname-emvq9a/resolver-5aZssX/apt_archive ./ Packages
| Could not open file
/build/hostname-emvq9a/resolver-5aZssX/apt_archive/./Packages - open (13:
Permission denied)
In particular, my foreign hostname wasn't installed.
I think Antonio has found a bug.
Helmut
--- End Message ---
--- Begin Message ---
Hi,
Quoting Johannes Schauer Marin Rodrigues (2022-09-15 11:55:09)
> On Fri, 22 Jul 2022 14:58:22 +0200 Helmut Grohne <[email protected]> wrote:
> > Antonio attempted cross building a ruby extension with a custom gem2deb
> > and tried doing so with sbuild --extra-package. Apparently, that didn't
> > work out.
> >
> > I tried:
> >
> > sbuild --host=arm64 -d unstable
> > --extra-package=./hostname_..._arm64.deb hostname
> >
> > This is kinda stupid, I know, but we see this:
> >
> > | Err:4 file:/build/hostname-emvq9a/resolver-5aZssX/apt_archive ./ Packages
> > | Could not open file
> > /build/hostname-emvq9a/resolver-5aZssX/apt_archive/./Packages - open (13:
> > Permission denied)
> >
> > In particular, my foreign hostname wasn't installed.
> >
> > I think Antonio has found a bug.
>
> there is a bug, yes. I am able to create a situation in which I see that line
> in my log.
>
> But I cannot reproduce the failure to install a foreign architecture binary
> package passed via --extra-package. I chose src:hello to test this. I first
> bumped the version with `dch -i` and then cross-built it normally to produce
> hello_2.10-2.1_arm64.deb. I then added "hello:arm64 (=2.10-2.1)" to the
> Build-Depends and rebuilt again with
> --extra-package=/tmp/hello_2.10-2.1_arm64.deb and I get this:
>
> Get:4 file:/build/hello-OnCNa2/resolver-xXDWfu/apt_archive ./ Packages [630 B]
> Err:4 file:/build/hello-OnCNa2/resolver-xXDWfu/apt_archive ./ Packages
> Could not open file
> /build/hello-OnCNa2/resolver-xXDWfu/apt_archive/./Packages - open (13:
> Permission denied)
> Get:4 file:/build/hello-OnCNa2/resolver-xXDWfu/apt_archive ./ Packages [969 B]
> [...]
> Get:2 file:/<<BUILDDIR>>/resolver-xXDWfu/apt_archive ./ hello 2.10-2.1 [58.2
> kB]
> [...]
> Selecting previously unselected package hello:arm64.
> Preparing to unpack .../076-hello_2.10-2.1_arm64.deb ...
> Unpacking hello:arm64 (2.10-2.1) ...
> [...]
> Setting up hello:arm64 (2.10-2.1) ...
>
> So yes, there is an error message from apt (no idea why it is produced yet)
> but
> the package gets installed.
>
> Do you have a full build log of your build failure?
since helmut was unable to reproduce this bug, it seems like the "Err" line
indeed was a red herring, leading to the assumption that the extra packages
could not successfully be loaded. Bringing this up in #debian-apt yielded, that
the following is happening when running "apt update":
1. apt retrieves the Packages.gz (the log doesn't talk about gzip but
re-running apt update with debug::pkgAcquire::Worker=1 reveals this)
2. apt tries to decompress the Packages.gz to Packages in the same directory
because this is a file:/ mirror
3. apt fails to write to the existing Packages file because the _apt user has
no permission to do so
4. apt reports a "Permission denied" error
5. apt retries retrieving the uncompressed Packages file
6. apt succeeds and everything is good
I worked around this behaviour of apt by just not emitting the compressed
Packages files anymore here:
https://salsa.debian.org/debian/sbuild/-/commit/52e28e078ba8b08e23c89a1d1eec261cfa5a3d34
Thanks!
cheers, josch
signature.asc
Description: signature
--- End Message ---
