bug#50066: core-update: Raw origin tarballs are not handled correctly.

[Maxim Cournoyer <maxim.cournoyer@gmail.com>]

Hello Mathieu,

Mathieu Othacehe <othacehe@gnu.org> writes:

> Hello,
>
> When building "emacs-org-contrib" on core-updates-frozen, the following
> message is printed:
>
> tar: Exiting with failure status due to previous errors
> error: in phase 'unpack': uncaught exception:
> %exception #<&invoke-error program: "tar" arguments: ("xvf" "/gnu/store/r3v4gkqqbxp2w739a0llvk9nrda9xn89-org-plus-contrib-20210809.tar") exit-status: 2 term-signal: #f stop-signal: #f> 
> phase `unpack' failed after 0.0 seconds
> command "tar" "xvf" "/gnu/store/r3v4gkqqbxp2w739a0llvk9nrda9xn89-org-plus-contrib-20210809.tar" failed with status 2
> note: keeping build directory `/tmp/guix-build-emacs-org-contrib-20210809.drv-6'
> builder for `/gnu/store/52jcx6rwnf0wrkrpcwkyz766fzg6asjy-emacs-org-contrib-20210809.drv' failed with exit code 1
> build of /gnu/store/52jcx6rwnf0wrkrpcwkyz766fzg6asjy-emacs-org-contrib-20210809.drv failed
> View build log at '/var/log/guix/drvs/52/jcx6rwnf0wrkrpcwkyz766fzg6asjy-emacs-org-contrib-20210809.drv.bz2'.
> guix build: error: build of `/gnu/store/52jcx6rwnf0wrkrpcwkyz766fzg6asjy-emacs-org-contrib-20210809.drv' failed
>
>
> That's because
> "/gnu/store/r3v4gkqqbxp2w739a0llvk9nrda9xn89-org-plus-contrib-20210809.tar"
> is empty. I believe this is a consequence of:
> cfcead2e515c0dae02127e5a76496463898be6b6, and in particular this
> section:
>
>               ;; If SOURCE is a directory (such as a checkout), return a
>               ;; directory.  Otherwise create a tarball.
>               (cond
>                ((file-is-directory? #+source)
>                 (copy-recursively directory #$output
>                                   #:log (%make-void-port "w")))
>                ((not #+comp)
>                 (copy-file file #$output)) <---------- We should call repack instead here for raw tarballs?
>                (else
>                 (repack directory #$output)))))))
>
> Maxim, could you please have a look?

Thanks for the report; it looks like a bug indeed.  I had probably
overlooked that case (where there is no compression but we are still
dealing with an archive format).  The annoying thing is that touching
this code will trigger a world rebuild; so unless we find other big
problems and batch the fixes, it may not be worth it.

The site.py problem you reported may be one, if I find a solution.

Other things on my mind:

1. rustc bootstrap from 1.39 (the itch to make it faster comes back
everytime I have to build it ;-)).

2. fontconfig update that should allow per-profile fonts management via
  XDG_DATA_DIRS (I have the commit ready, but failed to test it due to
  having to build rust and getting distracted by 1. :-))

Not a very useful reply in itself, but I felt that communicating what
I've been busy with was better than a longer silence :-).

Thank you,

Maxim