Debian Bug report logs - #1002496
rakudo: pre-compiled files are unreproducible

Reply or subscribe to this bug.

Toggle useless messages

Message #5 received at submit@bugs.debian.org (full text, mbox, reply):

From: "Chris Lamb" <lamby@debian.org>

To: submit@bugs.debian.org

Subject: perl6-readline: Strange files under /usr/lib/perl6/vendor/dist?

Date: Thu, 23 Dec 2021 09:19:50 +0000

Package: perl6-readline
Version: 0.1.5-3
Severity: minor
User: reproducible-builds@lists.alioth.debian.org
Usertags: randomness
X-Debbugs-Cc: reproducible-bugs@lists.alioth.debian.org

Hi,

Dear Maintainer,

The latest version of perl6-readline seems to ship a number of
interesting-looking files under /usr/lib/perl6/vendor, such as:

  /usr/lib/perl6/vendor/dist/A8475E6287F45455F9F68569C07ADC25AA5BEFDF

Is this some kind of .pyc equivalent for Perl 6? Either way, I'd love
to know more as these files appear to be unreproducible.


Regards,

-- 
      ,''`.
     : :'  :     Chris Lamb
     `. `'`      lamby@debian.org / chris-lamb.co.uk
       `-

Message #10 received at 1002496@bugs.debian.org (full text, mbox, reply):

From: Dominique Dumont <domi.dumont@free.fr>

To: Chris Lamb <lamby@debian.org>, 1002496@bugs.debian.org, Debian Rakudo Maintainers development mailing list <pkg-rakudo-devel@alioth-lists.debian.net>

Subject: Re: Bug#1002496: perl6-readline: Strange files under /usr/lib/perl6/vendor/dist?

Date: Fri, 24 Dec 2021 15:45:16 +0100

Hi

On Thursday, 23 December 2021 10:19:50 CET Chris Lamb wrote:
> The latest version of perl6-readline seems to ship a number of
> interesting-looking files under /usr/lib/perl6/vendor, such as:
> 
>   /usr/lib/perl6/vendor/dist/A8475E6287F45455F9F68569C07ADC25AA5BEFDF
> 
> Is this some kind of .pyc equivalent for Perl 6? Either way, I'd love
> to know more as these files appear to be unreproducible.

Yes, theses are Raku modules pre-compiled at build time.

A more detailed explanation is provided on Debian wiki:

https://wiki.debian.org/Perl6PreCompProposal

I don't really know why the pre-compilation is not reproducible.

As a matter of fact, neither rakudo, nqp or moarvm are reproducible. I've 
never found the time or energy to find why.

All the best

Dod

Message #21 received at 1002496@bugs.debian.org (full text, mbox, reply):

From: "Chris Lamb" <lamby@debian.org>

To: "Dominique Dumont" <domi.dumont@free.fr>, 1002496@bugs.debian.org, "Debian Rakudo Maintainers development mailing list" <pkg-rakudo-devel@alioth-lists.debian.net>

Subject: Re: Bug#1002496: perl6-readline: Strange files under /usr/lib/perl6/vendor/dist?

Date: Wed, 05 Jan 2022 12:02:06 +0000

Hey Dominique,

> I don't really know why the pre-compilation is not reproducible.

First, thank you for the links and explanation: I thought they were
I accidentally-included files at first. Anyway, I've just spent a few
minutes looking into this issue and it seems like the pre-compiled
modules reference the absolute build path:

  $ strings EBC1B2DDA59A9D91D483BD81DAA416714D2D1276 | grep lamby
  /home/lamby/temp/cdt.20220105114153.LbQvXzNPwU.repro.perl6-readline/build-a/perl6-readline-0.1.5

(There might be other 'nondeterminisms' as well, however.)

> As a matter of fact, neither rakudo, nqp or moarvm are reproducible. I've
> never found the time or energy to find why.

I assume you're referring to the build of the rakudo source package
itself. If so, that feels like an important yet distinct issue: let's
keep this particular bug to the reproducibility of the *output* of
rakudo… even if it turns out to be the same underlying problem.

Anyway, just thought I'd brain-dump the above for now.


Best wishes,

-- 
      ,''`.
     : :'  :     Chris Lamb
     `. `'`      lamby@debian.org 🍥 chris-lamb.co.uk
       `-

Message #26 received at 1002496@bugs.debian.org (full text, mbox, reply):

From: "Chris Lamb" <lamby@debian.org>

To: "gregor herrmann" <gregoa@debian.org>, "Debian Rakudo Maintainers development mailing list" <pkg-rakudo-devel@alioth-lists.debian.net>

Cc: "Vagrant Cascadian" <vagrant@reproducible-builds.org>, "Reproducible builds folks" <reproducible-builds@lists.alioth.debian.org>, "Dominique Dumont" <dod@debian.org>, 1002496@bugs.debian.org

Subject: Re: dh-perl6 vs. dh-raku: reproducibility issues with vendor/precompiled

Date: Thu, 20 Jan 2022 20:30:06 -0000

[adding 1002496@bugs.debian.org to CC]

Hi all,

>> I just noticed a reproducibility issue in a package that transitioned
>> from dh-perl6 to dh-raku, and it introduced some reproducibility issues
>> in the raku-tap-harness in precomp files, e.g.:
>
> I think this was already briefly discussed in #1002496

Yes, indeed. As I mentioned in that bug, I initially thought they were
accidentally-distributed temporary/build files; something that's
actually quite common in Debian and comes up quite a lot when doing
Reproducible Builds stuff.

If I had realised they were the result of deliberate pre-compilation
efforts, I would probably not have filed that bug. Or, rather: I
wouldn't have done without a patch to fix the issue! In other words,
sorry for the essentially unactionable bug, although it *is* serving as
a useful place to dump information as we inch towards a solution.

(I have included #1002496 on the CC of this thread, perhaps to avoid any
potential duplication in the future.)

>> But there aren't many [tagged] packages there (yay?), and the
>> description is a bit terse suggesting that these files should not
>> be shipped at all...
>
> Well …

Oh, don't read into that description, Vagrant! That's likely my
description based on my jejune understanding of the problem at the
time (see above). Please feel free to update it — I have nothing
against precompilation as a general rule.

>> They appear to be hashed filenames, what goes into the hash that
>> produces them (file path? timestamp? etc.), and could that be made
>> reproducible?
>
> That would be nice indeed.
>
> I once experimented by comparing the "old"
> precompiled-at-instalation-time and the precompiled-at-build-time
> files on my laptop, and interesetingly they were the same. Or I
> missed something. But yeah, rebuilding with reprepo shows that paths
> are embedded which ist Not Good™.

Thanks for confirming in reprepro. This is also confirmed by me at the
end of #1002496. I haven't done any other investigating yet.

For completeness, another related bug in this area is:

  https://bugs.debian.org/1003159

... although that is related to the contents of foo.dh-raku.list
files. It is, I think, pretty uncontroversial.


Regards,

-- 
      ,''`.
     : :'  :     Chris Lamb
     `. `'`      lamby@debian.org 🍥 chris-lamb.co.uk
       `-

Message #31 received at 1002496@bugs.debian.org (full text, mbox, reply):

From: Vagrant Cascadian <vagrant@reproducible-builds.org>

To: Chris Lamb <lamby@debian.org>, gregor herrmann <gregoa@debian.org>, Debian Rakudo Maintainers development mailing list <pkg-rakudo-devel@alioth-lists.debian.net>

Cc: Reproducible builds folks <reproducible-builds@lists.alioth.debian.org>, Dominique Dumont <dod@debian.org>, 1002496@bugs.debian.org

Subject: Re: dh-perl6 vs. dh-raku: reproducibility issues with vendor/precompiled

Date: Thu, 20 Jan 2022 13:27:33 -0800

[Message part 1 (text/plain, inline)]

On 2022-01-20, Chris Lamb wrote:
>>> I just noticed a reproducibility issue in a package that transitioned
>>> from dh-perl6 to dh-raku, and it introduced some reproducibility issues
>>> in the raku-tap-harness in precomp files, e.g.:
>>
>> I think this was already briefly discussed in #1002496
>
> Yes, indeed. As I mentioned in that bug, I initially thought they were
> accidentally-distributed temporary/build files; something that's
> actually quite common in Debian and comes up quite a lot when doing
> Reproducible Builds stuff.
>
> If I had realised they were the result of deliberate pre-compilation
> efforts, I would probably not have filed that bug. Or, rather: I
> wouldn't have done without a patch to fix the issue! In other words,
> sorry for the essentially unactionable bug, although it *is* serving as
> a useful place to dump information as we inch towards a solution.
>
> (I have included #1002496 on the CC of this thread, perhaps to avoid any
> potential duplication in the future.)
>
>>> But there aren't many [tagged] packages there (yay?), and the
>>> description is a bit terse suggesting that these files should not
>>> be shipped at all...
>>
>> Well …
>
> Oh, don't read into that description, Vagrant! That's likely my
> description based on my jejune understanding of the problem at the
> time (see above). Please feel free to update it — I have nothing
> against precompilation as a general rule.

Yes... of course, shortly after I sent the mail starting this thread I
found more information on this issue!

I've added links to the bug and wiki page describing perl6
precompilation files in our reproducible builds notes and will think
about how to better describe and/or even rename the issue. :)


>>> They appear to be hashed filenames, what goes into the hash that
>>> produces them (file path? timestamp? etc.), and could that be made
>>> reproducible?
>>
>> That would be nice indeed.
>>
>> I once experimented by comparing the "old"
>> precompiled-at-instalation-time and the precompiled-at-build-time
>> files on my laptop, and interesetingly they were the same. Or I
>> missed something. But yeah, rebuilding with reprepo shows that paths
>> are embedded which ist Not Good™.
>
> Thanks for confirming in reprepro. This is also confirmed by me at the
> end of #1002496. I haven't done any other investigating yet.

I presume "reprotest"? Which I've also used to confirm this issue with a
few packages.


live well,
  vagrant

[signature.asc (application/pgp-signature, inline)]

Message #36 received at 1002496@bugs.debian.org (full text, mbox, reply):

From: gregor herrmann <gregoa@debian.org>

To: Vagrant Cascadian <vagrant@reproducible-builds.org>, 1002496@bugs.debian.org, Debian Rakudo Maintainers development mailing list <pkg-rakudo-devel@alioth-lists.debian.net>

Cc: Chris Lamb <lamby@debian.org>, Reproducible builds folks <reproducible-builds@lists.alioth.debian.org>, Dominique Dumont <dod@debian.org>

Subject: Re: Bug#1002496: dh-perl6 vs. dh-raku: reproducibility issues with vendor/precompiled

Date: Fri, 21 Jan 2022 22:55:59 +0100

[Message part 1 (text/plain, inline)]

On Thu, 20 Jan 2022 13:27:33 -0800, Vagrant Cascadian wrote:

> >> But yeah, rebuilding with reprepo shows that paths
> >> are embedded which ist Not Good™.
> > Thanks for confirming in reprepro. This is also confirmed by me at the
> > end of #1002496. I haven't done any other investigating yet.
> I presume "reprotest"? Which I've also used to confirm this issue with a
> few packages.

Right, I meant reprotest, sorry.


Cheers,
gregor

-- 
 .''`.  https://info.comodo.priv.at -- Debian Developer https://www.debian.org
 : :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D  85FA BB3A 6801 8649 AA06
 `. `'  Member VIBE!AT & SPI Inc. -- Supporter Free Software Foundation Europe
   `-   NP: Bob Dylan: Mr Tambourine Man

[signature.asc (application/pgp-signature, inline)]

Message #45 received at 1002496@bugs.debian.org (full text, mbox, reply):

From: "Chris Lamb" <lamby@debian.org>

To: "Debian Rakudo Maintainers development mailing list" <pkg-rakudo-devel@alioth-lists.debian.net>, "gregor herrmann" <gregoa@debian.org>

Cc: "Vagrant Cascadian" <vagrant@reproducible-builds.org>, "Reproducible builds folks" <reproducible-builds@lists.alioth.debian.org>, "Dominique Dumont" <dod@debian.org>, 1002496@bugs.debian.org

Subject: Re: dh-perl6 vs. dh-raku: reproducibility issues with vendor/precompiled

Date: Thu, 27 Jan 2022 10:40:14 -0800

Chris Lamb wrote:

> [...]

Just some further scrappy braindumping here; this is, unfortunately, not a
complete solution yet.

Looking into this further, a lot of this revolves around this method in
src/core.c/CompUnit/Repository/Installation.pm6:

    method id() {
        return $!id if $!id;
        my $name = self.path-spec;
        $name ~= ',' ~ self.next-repo.id if self.next-repo;
        my $dist-dir = $.prefix.add('dist');
        $!id = nqp::sha1(nqp::sha1($name) ~ ($dist-dir.e ?? $dist-dir.dir !! ''))
    }

... and this one in lib/CompUnit/Repository/Staging.rakumod:

    method path-spec(CompUnit::Repository::Staging:D:) {
        self.^name ~ '#name(' ~ $!name ~ ')#' ~ $.prefix.absolute;
    }


Taken together, these basically hash together two things:

  a) All of the repository names/paths used in the precompilation process.

  b) The target directory for the precompilation.

This value is then encoded in the filename of the repo-id file and
similar. (Just to check: is this file even needed?)

Just to take these two things in turn:


## A. Repository paths

It is fine that the hash includes things like /usr/lib/perl6/site.
However, pre-compilation looks in $HOME/.raku for modules and encodes
that value into the hash of the precompiled files. The hash therefore
varies on the build user's home directory location/name.

This occurs via RepositoryRegistry.pm6:

    nqp::bindkey($custom-lib,'home',
      $next-repo := self!register-repository(
        $home-spec,
        CompUnit::Repository::Installation.new(
          :prefix($home),
          :$next-repo
        )
      )
    ) if $home-spec and nqp::not_i(nqp::existskey($unique,$home-spec));

It probably isn't a good idea that Debian package builds inherits anything from
the build user's home directory anyway, so the following should be okay:

    --- a/dh_raku_build
    +++ b/dh_raku_build
    @@ -39,6 +39,7 @@ foreach my $pkg (getpackages()) {
                      --from=. --to=debian/tmp/pre-compiled!;
         doit({
             update_env => {
    +            HOME => "/nonexistent",
                 RAKUDO_RERESOLVE_DEPENDENCIES => 0,
             }
         },@cmd);


## B. Target directory

This directory is typically `debian/tmp/pre-compiled` in Debian (via
`dh_raku_build`). Although this is a relative path name and should
therefore not embed the full path name, the directory is converted to
its absolute version within Staging.rakumod:

    self.^name ~ '#name(' ~ $!name ~ ')#' ~ $.prefix.absolute;

Raku will thus embed the fully-qualified pathname such as
/tmp/arbitrary-build-dir/perl6-module/debian/tmp/pre-compiled).

This could be fixed via:

    --- a/lib/CompUnit/Repository/Staging.rakumod
    +++ b/lib/CompUnit/Repository/Staging.rakumod
    @@ -11,7 +11,7 @@ class CompUnit::Repository::Staging is CompUnit::Repository::Installation {
             $!name
         }
         method path-spec(CompUnit::Repository::Staging:D:) {
    -        self.^name ~ '#name(' ~ $!name ~ ')#' ~ $.prefix.absolute;
    +        self.^name ~ '#name(' ~ $!name ~ ')#' ~ ($!name ne 'vendor' ?? $.prefix.absolute !! '');
         }
         method source-file(Str $name --> IO::Path) {
             my $file = self.prefix.add($name);

This cannot be fixed by replacing $.prefix.absolute with
$.prefix.relative, otherwise the build will vary on the number of
directory levels (eg. "../../../target" vs "../../../../target"). And
it doesn't appear to be fixable using $.prefix.path either; this is also
an absolute value, so something is converting it.

(Oh, misc: this proof-of-concept patch only changes the value for
"vendor" types. This is the repository type for local/Debian builds,
leaving the global "inst" types such as /usr/lib/perl6/site, etc.
unchanged.)


Another solution might be to do something quite aggressive like this:

  --- a/src/core.c/CompUnit/Repository/Installation.pm6
  +++ b/src/core.c/CompUnit/Repository/Installation.pm6
  @@ -616,6 +616,11 @@ sub MAIN(:$name, :$auth, :$ver, *@, *%) {

       method id() {
           return $!id if $!id;
  +        if %*ENV<SOURCE_DATE_EPOCH> -> $sde {
  +            $!id = nqp::sha1($sde);
  +            return $!id;
  +        }
           my $name = self.path-spec;
           $name ~= ',' ~ self.next-repo.id if self.next-repo;
           my $dist-dir = $.prefix.add('dist');

Whilst this sidesteps some of the above issues, it strangely doesn't
fix the contents of the files, which still seem to contain the target
(and possibly the source) directory.

Anyway, again, just braindumping here so I don't forget stuff. Thanks
for maintaining Rakudo.


-- 
      ,''`.
     : :'  :     Chris Lamb
     `. `'`      lamby@debian.org 🍥 chris-lamb.co.uk
       `-

Message #50 received at 1002496@bugs.debian.org (full text, mbox, reply):

From: Dominique Dumont <dod@debian.org>

To: Chris Lamb <lamby@debian.org>

Cc: Debian Rakudo Maintainers development mailing list <pkg-rakudo-devel@alioth-lists.debian.net>, gregor herrmann <gregoa@debian.org>, Vagrant Cascadian <vagrant@reproducible-builds.org>, Reproducible builds folks <reproducible-builds@lists.alioth.debian.org>, 1002496@bugs.debian.org

Subject: Re: dh-perl6 vs. dh-raku: reproducibility issues with vendor/precompiled

Date: Wed, 09 Feb 2022 19:29:43 +0100

On Thursday, 27 January 2022 19:40:14 CET Chris Lamb wrote:
> It probably isn't a good idea that Debian package builds inherits anything
> from the build user's home directory anyway, so the following should be
> okay:
> 
>     --- a/dh_raku_build
>     +++ b/dh_raku_build
>     @@ -39,6 +39,7 @@ foreach my $pkg (getpackages()) {
>                       --from=. --to=debian/tmp/pre-compiled!;
>          doit({
>              update_env => {
>     +            HOME => "/nonexistent",
>                  RAKUDO_RERESOLVE_DEPENDENCIES => 0,
>              }
>          },@cmd);

Unfortunately, the build of perl6-zef with cowbuilder is already broken with cowbuilder. The nonexistant home dir leads to build failures.

I get a lot of warnings like:

WARNING: unhandled Failure detected in DESTROY. If you meant to ignore it, you can mark it as handled by calling .Bool, .so, .not, or .defined methods. The Failure was:
Failed to create directory '/nonexistent/.raku/short' with mode '0o777': Failed to mkdir: No such file or directory
  in sub MAIN at /usr/bin/prove6 line 3
  in block <unit> at /usr/bin/prove6 line 1

And the build fails with:

===SORRY!=== Error while compiling /usr/lib/perl6/vendor/sources/B4401FC2C8E71132AE0D3CE2C47A7D2FBB0D50F1
Could not find Getopt::Long in:
    inst#/nonexistent/.raku
    inst#/usr/lib/perl6/site
    inst#/usr/lib/perl6/vendor
    inst#/usr/lib/perl6/core
    ap#
    nqp#
    perl5#
at /usr/lib/perl6/vendor/sources/B4401FC2C8E71132AE0D3CE2C47A7D2FBB0D50F1:2
dh_raku_test: error: /usr/bin/prove6 -l -v returned exit code 1

All the best

Message #55 received at 1002496@bugs.debian.org (full text, mbox, reply):

From: "Chris Lamb" <lamby@debian.org>

To: "Dominique Dumont" <dod@debian.org>

Cc: "Debian Rakudo Maintainers development mailing list" <pkg-rakudo-devel@alioth-lists.debian.net>, "gregor herrmann" <gregoa@debian.org>, "Vagrant Cascadian" <vagrant@reproducible-builds.org>, "Reproducible builds folks" <reproducible-builds@lists.alioth.debian.org>, 1002496@bugs.debian.org

Subject: Re: dh-perl6 vs. dh-raku: reproducibility issues with vendor/precompiled

Date: Wed, 09 Feb 2022 10:36:16 -0800

Hi Dominique,

>>     --- a/dh_raku_build
>>     +++ b/dh_raku_build
>>     @@ -39,6 +39,7 @@ foreach my $pkg (getpackages()) {
>>                       --from=. --to=debian/tmp/pre-compiled!;
>>          doit({
>>              update_env => {
>>     +            HOME => "/nonexistent",
>>                  RAKUDO_RERESOLVE_DEPENDENCIES => 0,
>>              }
>>          },@cmd);
>
> Unfortunately, the build of perl6-zef with cowbuilder is already broken
> with cowbuilder. The nonexistant home dir leads to build failures.

Ah, shame. Although I wasn't experiencing a build failure, I was
getting the same or similar warnings when building "perl6-readline".

My gut sense is that this will require a change to Raku itself to not
fail if the home directory does not exist. That would feel like a
desired property anyway.


Regards,

-- 
      ,''`.
     : :'  :     Chris Lamb
     `. `'`      lamby@debian.org 🍥 chris-lamb.co.uk
       `-

Message #60 received at 1002496@bugs.debian.org (full text, mbox, reply):

From: Mattia Rizzolo <mattia@debian.org>

To: Chris Lamb <lamby@debian.org>

Cc: Dominique Dumont <dod@debian.org>, Debian Rakudo Maintainers development mailing list <pkg-rakudo-devel@alioth-lists.debian.net>, gregor herrmann <gregoa@debian.org>, Vagrant Cascadian <vagrant@reproducible-builds.org>, Reproducible builds folks <reproducible-builds@lists.alioth.debian.org>, 1002496@bugs.debian.org

Subject: Re: dh-perl6 vs. dh-raku: reproducibility issues with vendor/precompiled

Date: Wed, 9 Feb 2022 23:45:10 +0100

[Message part 1 (text/plain, inline)]

(just dumping a quick point else I'm sure I'll forget by the time I get to
this mail when on the computer..)

A build process really must not create random files in HOME, and possibly
not even try to access them...

If having a nonexistent home dir (which... Isn't the case of boh default
pbuilder and sbuild?) leads to an ftbfs, that's pretty much a RC bug.
Although I don't remember the reference by heart, I'm quite sure I've seen
such RC bugs filed in the past.


On Wed, 9 Feb 2022, 7:36 pm Chris Lamb, <lamby@debian.org> wrote:

> Hi Dominique,
>
> >>     --- a/dh_raku_build
> >>     +++ b/dh_raku_build
> >>     @@ -39,6 +39,7 @@ foreach my $pkg (getpackages()) {
> >>                       --from=. --to=debian/tmp/pre-compiled!;
> >>          doit({
> >>              update_env => {
> >>     +            HOME => "/nonexistent",
> >>                  RAKUDO_RERESOLVE_DEPENDENCIES => 0,
> >>              }
> >>          },@cmd);
> >
> > Unfortunately, the build of perl6-zef with cowbuilder is already broken
> > with cowbuilder. The nonexistant home dir leads to build failures.
>
> Ah, shame. Although I wasn't experiencing a build failure, I was
> getting the same or similar warnings when building "perl6-readline".
>
> My gut sense is that this will require a change to Raku itself to not
> fail if the home directory does not exist. That would feel like a
> desired property anyway.
>
>
> Regards,
>
> --
>       ,''`.
>      : :'  :     Chris Lamb
>      `. `'`      lamby@debian.org 🍥 chris-lamb.co.uk
>        `-
>
> _______________________________________________
> Reproducible-builds mailing list
> Reproducible-builds@alioth-lists.debian.net
>
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/reproducible-builds
>

[Message part 2 (text/html, inline)]

Message #65 received at 1002496@bugs.debian.org (full text, mbox, reply):

From: Dominique Dumont <dod@debian.org>

To: Chris Lamb <lamby@debian.org>, 1002496@bugs.debian.org

Cc: Debian Rakudo Maintainers development mailing list <pkg-rakudo-devel@alioth-lists.debian.net>, gregor herrmann <gregoa@debian.org>, Vagrant Cascadian <vagrant@reproducible-builds.org>, Reproducible builds folks <reproducible-builds@lists.alioth.debian.org>, 1002496@bugs.debian.org

Subject: Re: Bug#1002496: dh-perl6 vs. dh-raku: reproducibility issues with vendor/precompiled

Date: Sun, 20 Feb 2022 18:33:52 +0100

On Wednesday, 9 February 2022 19:36:16 CET Chris Lamb wrote:
> > Unfortunately, the build of perl6-zef with cowbuilder is already broken
> > with cowbuilder. The nonexistant home dir leads to build failures.
> 
> Ah, shame. Although I wasn't experiencing a build failure, I was
> getting the same or similar warnings when building "perl6-readline".

Sorry, I got confused.

The pre-compilation phase works fine with HOME set to a non-existent directory.

On the other hand, zef tests require a writable HOME directory. I've changed 
dh_raku_test to set HOME to debian/tmp/home (and cleanup afterwards).

With these changes, perl6-zef builds without problems.

This does not change the reproducible build issue.

All the best

Dod

Send a report that this bug log contains spam.