[bug#43276] [PATCH] gnu: emacs-org-contrib: Fix origin hash.

[zimoun <zimon.toutoune@gmail.com>]

On Wed, 9 Sep 2020 at 15:17, Pierre Langlois <pierre.langlois@gmx.com> wrote:
>
>
> zimoun writes:
>
> > Hi,
> >
> > On Wed, 9 Sep 2020 at 14:46, Pierre Langlois <pierre.langlois@gmx.com> wrote:
> >>
> >>
> >> Fixed with 057d584b981d9a3293be03ee863d40a61c8aae74
> >
> > Not for me.
>
> Actually, yeah it didn't fix it for me either, I was too quick closing
> this bug. But, the next commit does fix it I think.

Yes.  But as Tobias raised up:

   I think it's good not to normalize them by at least briefly describing
   the upstream changes in the commit message. ‘Fix’ is borderline
   misleading IMO.

i.e., something along:

--8<---------------cut here---------------start------------->8---
gnu: emacs-org-contrib: Update source hash.

The previous tarball was modified in-place; see????????

* gnu/packages/emacs-xyz.scm (emacs-org-contrib)[source](sha256): Update.
--8<---------------cut here---------------end--------------->8---
(tweaked from harfbuzz replacement a8bb8fccd8)

Anyway.

 > @Tobias, the hash that's now upstream is the only one I've seen locally,
> and I assume it's the same case for simon. Do you happen to still have
> the tar ball with the previous hash? I'm curious what changed upstream,
> if it's unstable we might be better off using a git repo instead of
> elpa, as in code.orgmode.org/bzg/worg/src/master/org-contrib. Although
> then I don't know which commit corresponds to what's on elpa :-/.

I agree.  If Tobias still has the tarball, then it could be on Berlin
as substitute.  Otherwise "guix time-machine" will be broken for a
couple of commits (the 35 ones of the 2 last days, if I count
correctly).
Going to something content-addressed is a good idea, IMHO.  But I do
not know either how from where this "org-plus-contrib" comes?
The future disassemble and SWH backend should fix this kind of issues, I guess.


All the best,
simon