time-machine broken from 2019-04-07 to 2019-05-04

time-machine broken from 2019-04-07 to 2019-05-04

[zimoun]

Dear,

This bug [1] shows that 1100+ commits are broken for the time machine, i.e,,

  guix time-machine --commit=<xxx> -- <anything>

will fail.

The reason is the upstream in-place update of the SHA (bad practise!
bouhbouh!! :-)).

Upstream has released the version 2.4.0 of harfbuzz with the hash
1mpah6kwqid1kxsj4rwqsniivqbrx231j65v51yncx6s0dch0dch then changed it
[2] to  0vrkvdlmihdg62a4c6h5kx27khc33xmb95l50zgnwnavvpwyyw5l.

The version 2.4.0 has been introduced in Guix with the commit
2da9b81837fd1e6f08a10952784d3358be982855 using the first hash. Then
the commit  a8bb8fccd82a10a46f127b2235675b4f6cbaaf98 fixes the
upstream mess.

But, it means that all the commits between these two ones cannot be
built by Guix because a SHA mismatch error is raised.


Is the diagnostic correct?


What should be the fix?
Because it is annoying to be dependent of upstream bad practise.

Well, is it fixable?

(The initial tarball could recreated by one of us and then pushed to
SWH, but I am not convinced it is enough... because the time-machine
should check the availability of the source etc. which adds a lot of
complexity.)


What do you think?


All the best,
simon


[1] https://debbugs.gnu.org/cgi/bugreport.cgi?bug=39575
[2] https://github.com/harfbuzz/harfbuzz/issues/1641.

Re: time-machine broken from 2019-04-07 to 2019-05-04

[zimoun]

The error message is:

--8<---------------cut here---------------start------------->8---
building /gnu/store/9lh33jvs123jyfpd3vqv0q2gbynsy0cx-gcc-mesboot-wrapper-4.7.4.drv...
building /gnu/store/cjim33x0q1bv1ppkv3qijvr1pvsn4y0q-harfbuzz-2.4.0.tar.bz2.drv...
downloading from
https://www.freedesktop.org/software/harfbuzz/release/harfbuzz-2.4.0.tar.bz2...
/sha256 hash mismatch for
/gnu/store/b4cdp9sp44848348lrpzbfafhmjqf8nr-harfbuzz-2.4.0.tar.bz2:
  expected hash: 1mpah6kwqid1kxsj4rwqsniivqbrx231j65v51yncx6s0dch0dch
  actual hash:   0vrkvdlmihdg62a4c6h5kx27khc33xmb95l50zgnwnavvpwyyw5l
hash mismatch for store item
'/gnu/store/b4cdp9sp44848348lrpzbfafhmjqf8nr-harfbuzz-2.4.0.tar.bz2'
build of /gnu/store/cjim33x0q1bv1ppkv3qijvr1pvsn4y0q-harfbuzz-2.4.0.tar.bz2.drv
failed
View build log at
'/var/log/guix/drvs/cj/im33x0q1bv1ppkv3qijvr1pvsn4y0q-harfbuzz-2.4.0.tar.bz2.drv.bz2'.
cannot build derivation
`/gnu/store/p6gfcdacjcqf2br0zwsyzx1chfvg9gxi-harfbuzz-2.4.0.drv': 1
dependencies couldn't be built
building /gnu/store/jykjkg97dsm1s6dpbjf2aa2s3vpzj3zp-make-boot0-4.2.1.drv...
cannot build derivation
`/gnu/store/f458ygy0q7k2kyvx2dyhbdpdg0bx7fms-graphviz-2.40.1.drv': 1
dependencies couldn't be built
cannot build derivation
`/gnu/store/zq8g10nd1a6nap8nahdvcx9c34fzj7ya-texlive-bin-20180414.drv':
1 dependencies couldn't be built
cannot build derivation
`/gnu/store/czqmsdf8h3xmjakxgfpiz78q31lp8i78-guix-manual.drv': 1
dependencies couldn't be built
cannot build derivation
`/gnu/store/yqpxm07zm0mirrdvl2c4qvf8biyzg468-guix-56e95d54d.drv': 1
dependencies couldn't be built
cannot build derivation
`/gnu/store/7z7p0m7abi246gzigw8as2q3w33k1n31-profile.drv': 1
dependencies couldn't be built
guix time-machine: error: build of
`/gnu/store/7z7p0m7abi246gzigw8as2q3w33k1n31-profile.drv' failed
--8<---------------cut here---------------end--------------->8---

and examining the derivations, the culprit is 'guix-manual'. It needs
'graphviz' which needs a lot of things... and 'harfbuzz'.

Where is 'guix-manual' defined? In 'guix/self.scm'?


Aside the initial question about what to do when the source origin is
not reliable, this issue joins the question about cross-compilation
and lightweight graph. :-)

Re: time-machine broken from 2019-04-07 to 2019-05-04

[Konrad Hinsen]

zimoun <zimon.toutoune@gmail.com> writes:

> What should be the fix?
> Because it is annoying to be dependent of upstream bad practise.
>
> Well, is it fixable?

The root cause of the problem is the mutability of URLs. The solution is
to move on to immutable references. Such as git commits.

My impression is that tarballs are the preferred source code reference
used in Guix today, with git commits used only when there is no release
tarball. Is that an official policy, or just historical accident?
If a policy, what's the reason for it?

Cheers,
  Konrad.

Re: time-machine broken from 2019-04-07 to 2019-05-04

[zimoun]

Hi Konrad,

On Mon, 17 Feb 2020 at 10:48, Konrad Hinsen <konrad.hinsen@fastmail.net> wrote:
>
> zimoun <zimon.toutoune@gmail.com> writes:
>
> > What should be the fix?
> > Because it is annoying to be dependent of upstream bad practise.
> >
> > Well, is it fixable?
>
> The root cause of the problem is the mutability of URLs. The solution is
> to move on to immutable references. Such as git commits.

I agree. It is more or less an implicit rule in Guix: 'git-fetch' is
preferable than 'url-fetch' when possible.
Moreover, by using "git" origin, it is easier to archive in SWH; "guix
lint" does that. :-)


> My impression is that tarballs are the preferred source code reference
> used in Guix today, with git commits used only when there is no release
> tarball. Is that an official policy, or just historical accident?
> If a policy, what's the reason for it?

The current fix is to have the correct copy on ci.guix.gnu.org.

https://debbugs.gnu.org/cgi/bugreport.cgi?bug=39575#32


Well, Guix will export soon all the sources ('origin') of its packages
in JSON file (the patch still needs minor tweaks), then SWH could
ingest and archive. It is a join task with Nix: the SWH crawler is
written by lewo and it already seems working for the type 'url'; soon
the type 'git' (or 'svn', 'hg', etc.).

Therefore, the future should be fixed. ;-)
The past is not yet... because there is no guarantee that all the
upstreams are still reachable... and/or archived. Probably a TODO item
for the Guix Data Service. ;-)

https://lists.gnu.org/archive/html/guix-devel/2020-02/msg00233.html


Cheers,
simon

Re: time-machine broken from 2019-04-07 to 2019-05-04

[Ludovic Courtès]

Hi,

Konrad Hinsen <konrad.hinsen@fastmail.net> skribis:

> My impression is that tarballs are the preferred source code reference
> used in Guix today, with git commits used only when there is no release
> tarball. Is that an official policy, or just historical accident?
> If a policy, what's the reason for it?

There’s no real policy, other than to take a tarball when it contains
build system bits (typically when the tarball is made with GNU’s “make
dist”.)

Actually, we have more and more packages built from a Git checkout,
because this is becoming common practice.

I must say that the fact that SWH currently allows us to archive Git
checkouts more easily than tarballs gives a bit of an incentive to use
Git checkouts when there’s a choice.

Ludo’.