From: zimoun <zimon.toutoune@gmail.com>
To: "Wiktor Żelazny" <wz@freeshell.de>, help-guix@gnu.org
Subject: Re: guix time-machine, broken hash in an old package definition, a workaround?
Date: Fri, 15 Jan 2021 21:48:20 +0100 [thread overview]
Message-ID: <86h7nikju3.fsf@gmail.com> (raw)
In-Reply-To: <20210115201859.z4rlqu4xnsphowm4@wzguix>
Hi,
On Fri, 15 Jan 2021 at 21:18, Wiktor Żelazny <wz@freeshell.de> wrote:
> On Thu, Jan 14, 2021 at 09:29:48PM +0100, zimoun wrote:
>> you will not get the exact R packages as they were at the time of
>> d81fb2a;
>
> Can you, please, elaborate on that? Do you mean by that that the
> different r-foreign will result in a different r, and that will
Yes. Bit-to-bit different but you can expect functionally similar.
> propagate to the packages, as they depend on r? But R does not compile
> the R code in the packages while they are being installed, does it? Am I
> missing something? If it were the issue wouldn’t it occur also in your
> `./pre-inst-env` approach?
Same root of problem, same consequence. :-)
This upstream bad practise is not fixable; whatever the mean.
> A new idea: I just checked “CRAN Time Machine” at MRAN. The tarball with
> the 0g4mi101srjbl17ydb2hl3854m3xj0llj6861lfr30sp08nkqavl hash is there.
> I guess I can use `build --with-source=` now, maybe even `environment
> --with-source=r-foreign=`? Perhaps a more elegant solution would be to
> define r-foreign-fixed, as you describe above, yet this time leaving the
> hash, but changing the URL. Are there philosophical reasons for not
> using MRAN?
Oh, thanks for the pointer. Yeah, in this case it is possible to use
--with-source, maybe combined with another trick to populate your store
with the expected by d81fb2a tarball. And then simply use “guix
time-machine” as usual.
The API needs to be checked, maybe it should be possible to automatise
the fallback: try Guix build farm, then upstream, then SWH, then CRAN
for R build system. Maybe. :-)
All the best,
simon
next prev parent reply other threads:[~2021-01-15 20:50 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-01-13 13:22 guix time-machine, broken hash in an old package definition, a workaround? Wiktor Żelazny
2021-01-13 16:24 ` zimoun
2021-01-13 19:28 ` Wiktor Żelazny
2021-01-13 18:57 ` Leo Famulari
2021-01-13 19:37 ` Wiktor Żelazny
2021-01-13 20:44 ` Leo Famulari
2021-01-14 8:30 ` Wiktor Żelazny
2021-01-14 9:48 ` zimoun
2021-01-14 19:00 ` Wiktor Żelazny
2021-01-14 20:29 ` zimoun
2021-01-15 20:18 ` Wiktor Żelazny
2021-01-15 20:48 ` zimoun [this message]
2021-01-18 8:57 ` Wiktor Żelazny
2021-01-18 9:11 ` Wiktor Żelazny
2021-01-20 9:35 ` Wiktor Żelazny
2021-01-20 10:15 ` zimoun
2021-01-20 12:26 ` Wiktor Żelazny
2021-01-20 15:03 ` zimoun
2021-01-22 11:36 ` Wiktor Żelazny
2021-01-22 16:29 ` zimoun
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://guix.gnu.org/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=86h7nikju3.fsf@gmail.com \
--to=zimon.toutoune@gmail.com \
--cc=help-guix@gnu.org \
--cc=wz@freeshell.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).