Hi,
On Fri, 22 Jan 2021 at 12:36, Wiktor Żelazny wrote:
> Would be cool, however for MRAN you also need the snapshot date. Would
> it be feasible to extract it from the commit date? There are dates at
Extract date from ~/.cache/guix/checkouts/pj... and author date of the
commit provided at the
On Wed, Jan 20, 2021 at 04:03:09PM +0100, zimoun wrote:
> I was thinking to add MRAN as fallback for CRAN packages. I will give
> a look.
Hi simon,
Would be cool, however for MRAN you also need the snapshot date. Would
it be feasible to extract it from the commit date? There are dates at
CRAN,
Hi,
On Wed, 20 Jan 2021 at 13:26, Wiktor Żelazny wrote:
> On Wed, Jan 20, 2021 at 11:15:17AM +0100, zimoun wrote:
> > Cool if Microsoft support long time archive of CRAN packages. Well, it
> > seems possible to use it as fallback.
> Thanks for the review. You could say the same thing about
On Wed, Jan 20, 2021 at 11:15:17AM +0100, zimoun wrote:
> Cool if Microsoft support long time archive of CRAN packages. Well, it
> seems possible to use it as fallback.
Hi,
Thanks for the review. You could say the same thing about Software
Heritage. You never know. I was considering starting a
Hi,
On Wed, 20 Jan 2021 at 10:35, Wiktor Żelazny wrote:
> On Fri, Jan 15, 2021 at 09:19:01PM +0100, Wiktor Żelazny wrote:
>
>> A new idea: I just checked “CRAN Time Machine” at MRAN. The tarball
>> with the 0g4mi101srjbl17ydb2hl3854m3xj0llj6861lfr30sp08nkqavl hash is
>> there.
>
> A solution
On Fri, Jan 15, 2021 at 09:19:01PM +0100, Wiktor Żelazny wrote:
> A new idea: I just checked “CRAN Time Machine” at MRAN. The tarball
> with the 0g4mi101srjbl17ydb2hl3854m3xj0llj6861lfr30sp08nkqavl hash is
> there.
A solution with an inferior:
in guix-packages.git/local/cran.scm
On Mon, Jan 18, 2021 at 09:57:32AM +0100, Wiktor Żelazny wrote:
> $ guix time-machine --commit=d81fb2ae9443994ae5dd1cb5837276fad63f842c
> --channels=channel-specs.scm -- \
>build --with-source=r-foreign=foreign_0.8-75.tar.gz r-foreign
>
On Fri, Jan 15, 2021 at 09:48:20PM +0100, zimoun wrote:
> On Fri, 15 Jan 2021 at 21:18, Wiktor Żelazny wrote:
>
> > 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
Hi,
On Fri, 15 Jan 2021 at 21:18, Wiktor Żelazny 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
On Thu, Jan 14, 2021 at 09:29:48PM +0100, zimoun wrote:
> But I am doubtful that is what you really want. Instead, I guess you
> want packages that depends on r-foreign, as r for instance. Let take
> r-hmisc and r-rio for simplicity.
Hi,
Thank you for the great explanation.
>
Hi,
On Thu, 14 Jan 2021 at 20:00, Wiktor Żelazny wrote:
>> About the hash mismatch, game over with time-machine.
>
> Are you sure? I remember a situation where a package was defined in my
> private channel. Then, someone committed a definition for the same
> package to guix, but the definition
On Thu, Jan 14, 2021 at 10:48:35AM +0100, zimoun wrote:
> I guess it will not change your problem at hand: the missing tarball.
A tarball is there, just a different one. I would like to make guix
accept it.
> About the hash mismatch, game over with time-machine.
Are you sure? I remember a
Hi,
On Thu, 14 Jan 2021 at 09:30, Wiktor Żelazny wrote:
> I will retry now my attempts to fix the r-foreign problem with
> --no-substitutes added.
I guess it will not change your problem at hand: the missing tarball.
If I understand correctly, your initial message describes 2 issues:
- hash
On Wed, Jan 13, 2021 at 03:44:41PM -0500, Leo Famulari wrote:
> You might spend a loong time building things but it depends on the
> specific package(s).
I would argue that while using time-machine one does not expect
substitutes to be available, any way, since the old binaries are removed
On Wed, Jan 13, 2021 at 08:37:30PM +0100, Wiktor Żelazny wrote:
> Yeah, there may be a connection. Is --no-substitutes a way to avoid this
> error?
Yes, the problem is in the substituter so --no-substitutes will avoid
it. You might spend a loong time building things but it depends on
the
On Wed, Jan 13, 2021 at 01:57:06PM -0500, Leo Famulari wrote:
> On Wed, Jan 13, 2021 at 02:22:23PM +0100, Wiktor Żelazny wrote:
> > These attempts were either ignored by guix or resulted in
> >
> > guix time-machine: error: got unexpected path `Backtrace:' from substituter
>
> I don't think this
On Wed, Jan 13, 2021 at 05:24:39PM +0100, zimoun wrote:
> One way to locally fix is: checkout the Guix repo at commit
> d81fb2ae9443994ae5dd1cb5837276fad63f842c, then tweak the checksum, build
> from this source, and use:
>
> ./pre-inst-env guix environment -C -m manifest.scm
Hi simon,
Thanks
On Wed, Jan 13, 2021 at 02:22:23PM +0100, Wiktor Żelazny wrote:
> These attempts were either ignored by guix or resulted in
>
> guix time-machine: error: got unexpected path `Backtrace:' from substituter
I don't think this error is related to time-machine and unstable source
code. It appears to
Hi,
Sadly, nothing can be done. Well, I hope that someone will show me I am
wrong. :-)
--8<---cut here---start->8---
$ guix time-machine --commit=d81fb2ae9443994ae5dd1cb5837276fad63f842c \
-- weather r-foreign \
Hi list,
It appears that the package bundles at CRAN are not stable. The bundle
contents can change, and so its hash. I’ve encountered such a problem
three times, I think, already, so it’s presumably systemic. The latest
(minimal working) example:
$ cat manifest.scm
(specifications->manifest
20 matches
Mail list logo
