IRC channel logs

<zimoun>civodul: Giving a look at 2 things: merging 2 graphs and improving the generation of “pack -f docker” (based on nixery tricks), I note that the almost identical code appears in (guix graph), (guix build store-copy) and (guix import utils). Is it on purpose? Does it make to move the code (guix graph) and tweak the rest?

<civodul>zimoun: which code specifically?

<civodul>re Docker image layering, cbaines posted patches before

<civodul>hmm maybe that was on guix-devel

<rekado>it’s a bummer that the Docker format makes tricks like this necessary.

<rekado>it really is a step down from traditional file systems in this regard.

<zimoun>civodul: topological-sort and traverse/depth-first

<rekado>I haven’t read this yet, but I wonder if Singularity’s SCIF would allow for easier composition: https://academic.oup.com/gigascience/article/7/5/giy023/4931737

<zimoun>do you know when cbaines posted patches on guix-devel about image layering?

<zimoun>I was thinking to something like that: https://storage.googleapis.com/nixdoc/nixery-layers.html and https://grahamc.com/blog/nix-and-layered-docker-images

<rekado>hmm, the article says almost nothing about composing containers

<zimoun>rekado: I do not remember if you sent this http://datacolada.org/95 or someone else. Weird approach to address by dates.

<zimoun>civodul: from the author ;-) The reference is https://lists.gnu.org/archive/html/guix-devel/2020-03/msg00299.html

<rekado>zimoun: yes, it was me. A colleague of mine found it.

<rekado>this approach has one virtue: it is based on information that an unprepared person has.

<rekado>they might know that things worked three months ago, so they can install the version from three months ago without having to know anything more.

<rekado>I think the guix time-machine could benefit from something like that

<rekado>i.e. don’t give it a commit or a channels file but a relative time and have it figure out the rest

<rekado>makes time travel all that more timey whimey.

<zimoun>yes, it should not be too hard to implement. Well, even I will ask to Magali to add a first draft to “guix git log --date=YYYY-MM-DD” and return a range of commits. Then in another step, “guix time-machine” could accept a date. Somehow, it could be useful to fallback to MRAN.

<zimoun>However, dates is a fake impression that it is enough for reproducibility.

<rekado>I agree with everything you wrote

<rekado>I also thought that this is a feature we can borrow frm “guix git log”

<rekado>MRAN: I should work on this today

<rekado>and yes, dates are not sufficient, but neither are version strings, etc

<rekado>for us to offer a way to select by date, however, is a great way to bridge the … uhm… “impedance mismatch” between functional package management and users of other tools.

<rekado>it’s probably even easier than offering to install packages by version string (which would look up the last commit before an upgrade, for example)

<civodul>traveling by date would be nice

<civodul>we could find the nearest commit from a given date, using only local knowledge

<civodul>though we'd get better results by asking the Data Service

<civodul>but then, that raises (again) the question of how to integrate with those services

<zimoun>469 2020-12-09 for instance

<civodul>well it's pick the first or last commit that matches the spec

<civodul>obviously it's fuzzy compared to specifying the commit

<civodul>but for some use cases it might be good enough

<civodul>the other day i almost implemented a ";;guix history PKG" command for Guix-Jupyter, that would query the Data Service for versions of PKG

<civodul>(i frequently "almost implement" things :-))

<zimoun>I thought the averange range would be smaller; I guess it is ~30 commits per day on average.

<civodul>yeah it depends on merges, batches of Rust commits, etc.

<zimoun>I have something like that, almost implemented for the Guix Past Hackathon. The issue is the Data Service starts after 1rst Jan 2020

<zimoun>Or CRAN/Biocondcutor updates. And commits are not packages but services or Guix itself. Yeah for sure. But this gives an idea on the size of the range, i.e., an idea of the “approximation”.

<zimoun>Well, thanks for the idea. :-) “guix git log --date”, and --after/before :-)

<civodul>zimoun: 2020, not earlier?

<zimoun>civodul: right, 1rst jan 2019. My bad.

<rekado>in order to fix the time machine problems where old URLs no longer work we may need to implement a quirks mechanism

<zimoun>rekado: what do you have in mind?

<rekado>we have (guix quirks). It could apply a patch to the r-build-system to inject the MRAN source URL as a fallback.

<rekado>AIUI (guix quirks) is really made for minimal patches to Guix just to get the trampoline working, but I guess it could be extended to also provide modern fallback URLs to ancient URLs.

<civodul>did we lose the source of CRAN packages?

<zimoun>at least one.

<zimoun>rekado: you want to hard code all the missing (CRAN) packages in (guix quirks)?

<zimoun>I have not checked, but SWH claims CRAN ingestion, IIUC.

<civodul>IMO we should work on SWH + Disarchive

<civodul>i'd love to keep (guix quirks) as small as possible :-)

<zimoun>From Singularity training past week: wget https://golang.org/dl/go1.15.6.linux-amd64.tar.gz ;sudo tar -C /usr/local -xzf go1.15.6.linux-amd64.tar.gz… euh?! :-)

<civodul>heh

<rekado>I don’t suggest putting all sources in (guix quirks), no

<rekado>I’m saying that we can use that mechanism to patch the cran-url procedure retroactively

<rekado>if we add MRAN URLs to cran-url these days it seems to me that we should also add them for past CRAN/bioconductor sources

<civodul>we have content-addressing though

<civodul>so to me, URLs don't matter all that much

IRC channel logs

2021-02-01.log