Re: Guix Days: Patch flow discussion

[Kyle Meyer]

Hi Ricardo,

Ricardo Wurmus writes:

> Hi Josselin,

>> They both can co-exist with debbugs, and for now the patchwork instance
>> of QA is not usable for status tracking (because it is not meant to be
>> used as such for now).  One can already use both of them, but using both
>> supercedes debbugs, and gets rid of its limitations.  I've been using
>> b4/lei with the yhetil public-inbox instance, with piem.el as an
>> interface, and it's really useful.  With a properly configured b4, one
>> could simply run `b4 shazam some-msg-id` and it would automatically
>> apply the corresponding patchset.
>
> I’m interested in adopting this workflow.  Where can I find more
> information on how to configure this?

In 889a6204f8 (doc: Add some guidelines for reviewing, 2023-11-07),
Maxim added some b4 configuration to Guix's etc/git/gitconfig that
points at yhetil.org.  With that setup, running 'b4 shazam MESSAGE-ID'
from a Guix checkout should work.

You may have just be asking about configuring 'b4 shazam', but if you
(or others) are interested in configuring piem, read on :)


piem setup and use
==

For piem, you need some custom setup in your Emacs config.

  https://docs.kyleam.com/piem/Registering-inboxes.html

piem-inboxes contains entries that provide info to help piem map from a
message (say in Notmuch or Gnus) to a public-inbox URL and to a local
checkout of the repo.

  (setq piem-inboxes
'(("guix"
   :coderepo "/path/to/your/clone/of/guix/"
   :url "https://yhetil.org/guix/;
   :listid "bug-guix.gnu.org")))

Further setup depends on how (in Emacs) you read your messages.

  https://docs.kyleam.com/piem/Enabling-integration-libraries.html

For example, a Notmuch user would enable piem-notmuch-mode:

  (piem-notmuch-mode 1)

Or a debbugs.el user would enable piem-debbugs-mode (contributed by
Jelle Licht).  You can enable more than one integration library.

Once that's set up, the main entry point to b4 is the piem-b4-am
transient.  That transient in turn has the main command of interest,
piem-b4-am-from-mid.

  https://docs.kyleam.com/piem/Using-b4-to-apply-patches.html

Calling piem-b4-am-from-mid from, say, a Notmuch message with a patch
series will prepare the "am-ready" series, prompt you for the name of a
branch to create, and apply the series with 'git am' to the configured
repo.


piem-b4-am-from-mid vs b4 shazam


piem-b4-am-from-mid (from Emacs) and 'b4 shazam' (from the shell
visiting Guix repo) are similar in spirit: use 'b4 am' to prepare an
am-ready mbox from a thread's full mbox and then use 'git am' apply it
to a repo.  A key difference is that, with piem, you start off in some
non-repository Emacs buffer containing a message and then piem knows how
to get to the repository (using the config above).

As a side note: 'b4 shazam' didn't exist when I wrote piem's b4
integration.  At some point, I plan to add 'b4 shazam' support to piem,
similar to how there is a piem command (piem-b4-am-ready-from-mid)
that's a direct interface to 'b4 am', without the extra handling of
piem-b4-am-from-mid.  This will allow callers that prefer to use shazam
invoke it from Emacs rather than the command line.


lei
===

There's also mention upthread of lei.  I don't think you're asking about
configuring that, but fwiw that's public-inbox's local command-line
client.  I gave a short (and incomplete) description of it here:

  https://yhetil.org/guix-devel/87a6izsoio@kyleam.com

piem currently has some basic support for lei, focused on searching
public-inbox instances and displaying the results in Emacs.

Re: Git-LFS or Git Annex?

[Kyle Meyer]

Timothy Sample writes:

> I’ve written a special remote in Guile.  If anyone wants to do so, the
> following file might help.  It implements the basic protocol.
>
> https://git.ngyro.com/git-annex-remote-clouda/tree/git-annex-remote-clouda/remote.scm

Looks like a great reference.  Thanks for sharing.

(And thanks for doing the initial work packaging git-annex years ago!  I
remember being very excited to see it because I had tried multiple times
and kept getting stuck.)

Re: Git-LFS or Git Annex?

[Kyle Meyer]

Simon Tournier writes:
> As we see, since ’origin’ is unreachable, it fetches directly from the
> web.  Well, on machine-B running:
>
> git annex sync && git annex get -A
>
> allows to first update the keys and then to fetch all the new content
> from ’origin’.  It eases the maintenance of backups, IMHO.

One sync wrinkle to consider: by default 'git annex sync' does things
like commit staged changes and sync the checked out branch.  That's
useful in some scenarios, but, in the context of these repos, I'm
guessing people would prefer to continue to manually manage the primary
Git history.  You can tack on an --only-annex to that 'git annex sync'
to tell git-annex to just sync its git-annex branch.

> Well, if some motivated Haskeller would find fun to implement NAR as
> backend, it would allow transparent substitution; from my understanding,
> if the key contains NAR hash then it would be possible to bridge with
> Guix content-addressed system. :-)

Fwiw I think someone could do that outside Haskell, if they preferred,
via a custom backend:

  https://git-annex.branchable.com/design/external_backend_protocol/

Special remotes can also be written in other languages:

  https://git-annex.branchable.com/design/external_special_remote_protocol/

Re: Commit Access: Sharlatan Hellseher

[Kyle Meyer]

Hi Maxim,

Maxim Cournoyer writes:

> Another easy option is to retrieve the Message-ID of any message in the
> series (via the source HTML of the mail archives, or directly from the
> mail headers if you have the mail locally), and then use B4, Linux
> style [0].  Example: suppose I wanted to apply and review this Perl
> series [1], then I could apply locally to my Guix git checkout with:

I was going to add that a key part of using b4 with public-inbox
instances outside of the default lore.kernel.org is setting b4.midmask.
But then I noticed that Guix's etc/git/gitconfig now has

[b4]
attestation-check-dkim = off
attestation-policy = off
linkmask = https://yhetil.org/guix/%s
linktrailermask = https://yhetil.org/guix/%s
midmask = https://yhetil.org/guix/%s

Neat.  Thanks for adding that!

Re: Guidelines for pre-trained ML model weight binaries (Was re: Where should we put machine learning model parameters?)

[Kyle]

>Since it is computing, we could ask about the bootstrap of such
>generated data.  I think it is a slippery slope because it is totally
>not affordable to re-train for many cases: (1) we would not have the
>hardware resources from a practical point of view,, (2) it is almost
>impossible to tackle the source of indeterminism (the optimization is
>too entailed with randomness). 

I have only seen situations where the optimization is "too entailed with 
randomness" when models are trained on proprietary GPUs with specific settings. 
Otherwise, pseudo-random seeds are perfectly sufficient to remove the 
indeterminism. 

=> 
https://discourse.julialang.org/t/flux-reproducibility-of-gpu-experiments/62092

Many people think that "ultimate" reproducibility is not a practical either. 
It's always going to be easier in the short term to take shortcuts which make 
conclusions dependent on secret sauce which few can understand.

=> https://hpc.guix.info/blog/2022/07/is-reproducibility-practical/

 From my point of view, pre-trained
>weights should be considered as the output of a (numerical) experiment,
>similarly as we include other experimental data (from genome to
>astronomy dataset).

I think its a stretch to consider a data compression as an experiment. In 
experiments I am always finding mistakes which confuse the interpretation 
hidden by prematurely compressing data, e.g. by taking inappropriate averages. 
Don't confuse the actual experimental results with dubious data processing 
steps.

Re: Google Summer of Code 2023 Inquiry

[Kyle]

>I do not know what you have in mind with “working satisfiable
>configurations” or with “a variant of the solver”.  To my knowledge,
>this implies some SAT solver.  Well, before going this direction, I
>would suggest to read some output of the Mancoosi project [8].
>Especially this part [9].  From my point of view, the direction “working
>satisfiable configurations” or “a variant of the solver” would break the
>reproducibility of a specific configuration for the general case.  Part
>of the problem about computational environment reproducibility is
>because package manager implements solvers for installing some packages.

Yeah, we definitely don't want a solver for instantiating a profile. We want 
that explicit already in the manifest.scm. However, my understanding is that 
the role of an importer is to create a manifest.scm or, more realistically, 
help a user get started creating it. There will probably usually need to be 
additional tweaking related to the intended application the computational 
environment supports. The CRAN importer, for example, cannot yet detect non-R 
dependencies. So, the profile author has to figure those out for themselves. 
It's still very useful despite not being perfect. 

>Last, considering all Guix the version fields, I am not convinced it is
>straightforward to guarantee some “nearby” or newer versions.  It can
>only be heuristics working with more or less accuracy; see “guix
>refresh” and all the updaters.

Sure, but as is shown with "guix import cran" as I previously mentioned, it 
doesn't have to be perfect to be really useful in many cases.

>All in all, I am not convinced Guix should try to implement a way to
>“specify the exact software version”.  Because it leads to false
>considerations that label versions are enough for reproducing
>computational environments, when it is far to be.

It definitely is not enough, but that is where its up to the profile author to 
flesh out many examples of what their software is supposed to do and verify 
those still work under Guix.

Having tools to benchmark against existing, but not long term reproducible, 
software environments would help in this import case because that is the goal 
with conda. Researchers should not expect to go from "good enough" for now to 
guaranteed reproducibility without also doing a lot of empirical testing. 

Researchers have to start somewhere and convenience often trumps other 
considerations at the beginning since most new projects fail. To get 
researchers to start from Guix, they need either an army of packagers willing 
to assist them with packaging or for there to be so much convenience in Guix to 
package new software such that it isn't much of a hassle for the researcher to 
do it. I hope for both, but feel like working towards the latter would bolster 
the chances of the former. You could imagine Xapian being used to suggest also 
additional package inputs just as "guix build -f" already suggests missing 
scheme modules.

Re: Google Summer of Code 2023 Inquiry

[Kyle]

Hi Spencer,

Here is the documentation for the git commit-graph cache file. The authors also 
made their own blog posts about it as well with a bit more explanation.

=> https://git-scm.com/docs/commit-graph
=> 
https://devblogs.microsoft.com/devops/updates-to-the-git-commit-graph-feature/

Maybe it won't turn out to be needed... just thought it might help get you 
thinking. Please read all my suggestions from that perspective as a reasonable 
default.

I will have to defer to others for gauging the size of projects. I have found 
as a rule there are always many more details to be considered than I could have 
anticipated at the start of a project. That said I liked your earlier stated 
plan of starting simple. Handling latest releases seems a reasonable minimal 
viable product.

Cheers,
Kyle





On April 3, 2023 8:41:53 PM EDT, Spencer Skylar Chan  
wrote:
>Hi Kyle,
>
>On 3/31/23 11:15, Kyle wrote:
>> I would expect most software versions to not be in Guix. Simon had mentioned 
>> that this is mostly what the guix-past repository is for. However, some 
>> packages might be buried on some branch or some commit in some Guix related 
>> git repository. It may be helpful to facilitate their discovery and 
>> extraction for conda import.
>> 
>> Git has a newish binary file format for caching searches across commits. 
>> Maybe it would be helpful to figure out how to parse this format (its 
>> documented) and index the data further using Xapian or a graph data 
>> structure (or tree sitter?) with the relevant metadata needed to find and 
>> efficiently extract scheme code and its dependencies?
>
>If the format is documented then this is possible, although I'm not super 
>familiar with these kinds of data structures.
>
>> You make an interesting point about compilation errors. It may more 
>> productive to help researchers test for working satisfiable configurations 
>> as a more relaxed approach to having to specify the exact software version. 
>> Maybe some "nearby" or newer version is packaged and that is enough to 
>> successfully run a test suite? I'm imagining something between git bisect 
>> and Guix's own package solver.
>
>Yes, we could have a variant of the solver that's more relaxed. It could 
>output multiple solutions so the user can inspect them and pick the best one.
>
>> It might also be productive to add infrastructure to help scientists more 
>> conveniently track and study their recent packaging experiments. Guix will 
>> only become more useful the more packages which are already available. Work 
>> which makes packaging more approachable by more people benefits everyone. 
>> Perhaps you can think of other ideas in this direction?
>
>I'm not sure how "packaging experiments" are different from packaging software 
>the usual way. I think making the importers easier to use and debug would 
>help, although that sounds outside the scope of the projects.
>
>Finally, would these projects be considered large or medium for the purposes 
>of GSOC?
>
>Thanks,
>Skylar
>
>> On March 30, 2023 7:22:14 PM EDT, Spencer Skylar Chan 
>>  wrote:
>>> Hi Kyle,
>>> 
>>> On 3/24/23 14:59, Kyle wrote:
>>>> I am a bit worried about your proposed project is too focused on replacing 
>>>> python with guile. I think the project would benefit more from making 
>>>> python users more comfortable productively using Guix tools in concert 
>>>> with the tools they are already comfortable with.
>>> 
>>> Yes, I agree with you. Replacing Python with Guile is a much more ambitious 
>>> task and is not the highest priority here.
>>> 
>>>> I'm wondering if you might consider modifying your project goals toward 
>>>> exploring how GWL might be enhanced so that it could better complement 
>>>> more expressive language specific workflow tools like snakemake. I am also 
>>>> personally interested in exploring such a facilities from the targets 
>>>> workflow system in R as well. Alternatively, perhaps you could focus kn 
>>>> extending the GWL with more features?
>>> 
>>> I would also be interested in extending GWL with more features, I will 
>>> follow up with this on the GWL mailing list.
>>> 
>>>> I agree that establishing an achievable scope within a short timeline is 
>>>> crucial. The conda env importer idea would be quite an ambitious 
>>>> undertaking by itself and would lead you towards thinking about some 
>>>> pretty interesting and impactful problems.
>>> 
>>> While it's a challenging project, it 

Re: Where should we put machine learning model parameters ?

[Kyle]

My view as a statistician and Guix user is that trained machine learning models 
should at best be provided as substitutes. They are opaque binary artifacts of 
purely digital compilation processes and should not be treated exceptionally to 
any other build artifact.

It would seem to me most consistent with the goals of the project to insist on 
fully reproducible builds for machine learning models for them to be considered 
for inclusion into the main Guix distribution.

Full reproducibility would make the space requirements for including them even 
bigger than just the parameters but would ensure that the four freedoms could 
be preserved.



On April 3, 2023 12:48:12 PM EDT, "Nicolas Graves via Development of GNU Guix 
and the GNU System distribution."  wrote:
>
>Hi Guix!
>
>I've recently contributed a few tools that make a few OSS machine
>learning programs usable for Guix, namely nerd-dictation for dictation
>and llama-cpp as a converstional bot.
>
>In the first case, I would also like to contribute parameters of some
>localized models so that they can be used more easily through Guix. I've
>already discussed this subject when submitting these patches, without a
>clear answer.
>
>In the case of nerd-dictation, the model parameters that can be used
>are listed here : https://alphacephei.com/vosk/models
>
>One caveat is that using all these models can take a lot of space on the
>servers, a burden which is not useful because no build step are really
>needed (except an unzip step). In this case, we can use the
>#:substitutable? #f flag. You can find an example of some of these
>packages right here :
>https://git.sr.ht/~ngraves/dotfiles/tree/main/item/packages.scm
>
>So my question is: Should we add this type of models in packages for
>Guix? If yes, where should we put them? In machine-learning.scm? In a
>new file machine-learning-models.scm (such a file would never need new
>modules, and it might avoid some confusion between the tools and the
>parameters needed to use the tools)?
>
>
>-- 
>Best regards,
>Nicolas Graves
>

Re: Google Summer of Code 2023 Inquiry

[Kyle]

I would expect most software versions to not be in Guix. Simon had mentioned 
that this is mostly what the guix-past repository is for. However, some 
packages might be buried on some branch or some commit in some Guix related git 
repository. It may be helpful to facilitate their discovery and extraction for 
conda import.

Git has a newish binary file format for caching searches across commits. Maybe 
it would be helpful to figure out how to parse this format (its documented) and 
index the data further using Xapian or a graph data structure (or tree sitter?) 
with the relevant metadata needed to find and efficiently extract scheme code 
and its dependencies?

You make an interesting point about compilation errors. It may more productive 
to help researchers test for working satisfiable configurations as a more 
relaxed approach to having to specify the exact software version. Maybe some 
"nearby" or newer version is packaged and that is enough to successfully run a 
test suite? I'm imagining something between git bisect and Guix's own package 
solver. 

It might also be productive to add infrastructure to help scientists more 
conveniently track and study their recent packaging experiments. Guix will only 
become more useful the more packages which are already available. Work which 
makes packaging more approachable by more people benefits everyone. Perhaps you 
can think of other ideas in this direction?

On March 30, 2023 7:22:14 PM EDT, Spencer Skylar Chan 
 wrote:
>Hi Kyle,
>
>On 3/24/23 14:59, Kyle wrote:
>> I am a bit worried about your proposed project is too focused on replacing 
>> python with guile. I think the project would benefit more from making python 
>> users more comfortable productively using Guix tools in concert with the 
>> tools they are already comfortable with.
>
>Yes, I agree with you. Replacing Python with Guile is a much more ambitious 
>task and is not the highest priority here.
>
>> I'm wondering if you might consider modifying your project goals toward 
>> exploring how GWL might be enhanced so that it could better complement more 
>> expressive language specific workflow tools like snakemake. I am also 
>> personally interested in exploring such a facilities from the targets 
>> workflow system in R as well. Alternatively, perhaps you could focus kn 
>> extending the GWL with more features?
>
>I would also be interested in extending GWL with more features, I will follow 
>up with this on the GWL mailing list.
>
>> I agree that establishing an achievable scope within a short timeline is 
>> crucial. The conda env importer idea would be quite an ambitious undertaking 
>> by itself and would lead you towards thinking about some pretty interesting 
>> and impactful problems.
>
>While it's a challenging project, it could be broken into smaller steps:
>
>1. import packages by exact matching names only, without versioning.
>2. extend `guix import` to have `guix import conda` to help with package names 
>that do not match exactly, and to accelerate adoption of Conda packages not in 
>Guix
>3. match software version numbers when translating Conda packages to Guix
>
>What's currently undefined is the error handling:
>- if a Conda package does not exist in Guix
>- if the dependency graph is not solvable
>- if compiling the environment fails (due to mismatching dependency versions)
>
>I believe there are many satisfactory stopping points for successful 
>completion within the timeline of the summer, which I hope to present with my 
>proposal soon.
>
>Thanks,
>Skylar
>
>> 
>> On March 22, 2023 5:44:52 PM EDT, Spencer Skylar Chan 
>>  wrote:
>> 
>> Hi Ricardo,
>> 
>> On 3/22/23 14:19, Ricardo Wurmus wrote:
>> 
>> 
>> - Translating Snakemake to Guix Workflow Language (GWL)
>> 
>> 
>> Ricardo, maybe you would have some suggestions. :-)
>> 
>> 
>> Oh, this looks interesting. Could you please elaborate on the idea?
>> 
>> My idea is to take as input a Snakemake workflow file and eventually 
>> output an equivalent GWL workflow file.
>> 
>> Currently, Snakemake workflows can be exported to CWL (Common Workflow 
>> Language):
>> 
>> 
>> https://snakemake.readthedocs.io/en/stable/executing/interoperability.html  
>> <https://snakemake.readthedocs.io/en/stable/executing/interoperability.html>
>> 
>> One approach could be to add CWL import/export capabilities to GWL. Then 
>> Snakemake/GWL conversion would be a 2 step process, using CWL as an 
>> intermediate step:
>> 
>> 1. Snakemake -> CWL
>> 2. CWL -> GWL
>> 
&

Re: Google Summer of Code 2023 Inquiry

[Kyle]

As a statistician who always wants to get the most information for the least 
effort, I am particularly interested in being able to reprioritize workflow 
jobs interactively within the equivalent portions of the topological sort. I 
thought perhaps this would be possible with GWL if it could talk to SLURM with 
DRMAA version 2 (https://en.wikipedia.org/wiki/DRMAA). This would also be more 
readily useful to researchers if Guix had a conveniently available slurm 
service which worked out of the box even on a single machine. 

Stepping back, there might be a more ambitious question hidden in there in 
terms of how to handle indeterminism in a deterministic workflow manager. 
Without that external information the problem just involves choosing your 
random seeds up front. However,  I would prefer to write a procedure which is 
constantly reprioritizing labeled sub jobs within their associated containers 
either until I hit a resource limit or I have achieved certain target 
statistical diagnostics. Perhaps I would want GWL to tell me how to replay my 
build after the fact so I can make that reproducible even though I didn't know 
what I needed to focus my computations on up front and let the computer do 
that. Making that sort of thing possible might be a longer term effort, but 
working out what's needed for initial steps might be a fun project.

On March 30, 2023 7:27:37 PM EDT, Spencer Skylar Chan 
 wrote:
>Hi Ricardo,
>
>On 3/23/23 03:58, Ricardo Wurmus wrote:
>> Hi,
>> 
>> Spencer Skylar Chan  writes:
>> 
>>> One approach could be to add CWL import/export capabilities to
>>> GWL. Then Snakemake/GWL conversion would be a 2 step process, using
>>> CWL as an intermediate step:
>>> 
>>> 1. Snakemake -> CWL
>>> 2. CWL -> GWL
>> 
>> This seems doable.
>
>Great! I've been reading the chapter in Evolutionary Genomics on different 
>scalable workflows to understand this process better.
>
>>> However, CWL is not as expressive as Snakemake. There may be some
>>> details that are lost from Snakemake workflows.
>>> 
>>> So a 1-step Snakemake/GWL transpiler could be interesting, as both
>>> Snakemake/GWL use a domain-specific language inside a general purpose
>>> language (Python/Guile respectively). There may be a possibility to
>>> achieve more "accurate" translations between workflows.
>> 
>> Compared to the previous approach this seems vastly more complex.  It’s
>> one thing to *execute* Snakemake code without running it through Python,
>> but quite a bit more challenging to transpile Python to Scheme.
>> 
>> Personally, I wouldn’t know where to start.  Do you have an idea
>> already?
>> 
>
>Actually I was hoping you might have some ideas :)
>I do think that if the execution of the pipeline is more important than its 
>representation (Snakemake or otherwise), then it would make more sense to 
>focus efforts on increasing GWL's capabilities.
>
>Thanks,
>Skylar

Re: Google Summer of Code 2023 Inquiry

[Kyle]

Dear Spencer, 

I am a bit worried about your proposed project is too focused on replacing 
python with guile. I think the project would benefit more from making python 
users more comfortable productively using Guix tools in concert with the tools 
they are already comfortable with.

I'm wondering if you might consider modifying your project goals toward 
exploring how GWL might be enhanced so that it could better complement more 
expressive language specific workflow tools like snakemake. I am also 
personally interested in exploring such a facilities from the targets workflow 
system in R as well. Alternatively, perhaps you could focus kn extending the 
GWL with more features?

I agree that establishing an achievable scope within a short timeline is 
crucial. The conda env importer idea would be quite an ambitious undertaking by 
itself and would lead you towards thinking about some pretty interesting and 
impactful problems.


On March 22, 2023 5:44:52 PM EDT, Spencer Skylar Chan 
 wrote:
>Hi Ricardo,
>
>On 3/22/23 14:19, Ricardo Wurmus wrote:
>> 
 - Translating Snakemake to Guix Workflow Language (GWL)
>>> 
>>> Ricardo, maybe you would have some suggestions. :-)
>> 
>> Oh, this looks interesting.  Could you please elaborate on the idea?
>> 
>My idea is to take as input a Snakemake workflow file and eventually output an 
>equivalent GWL workflow file.
>
>Currently, Snakemake workflows can be exported to CWL (Common Workflow 
>Language):
>
>https://snakemake.readthedocs.io/en/stable/executing/interoperability.html
>
>One approach could be to add CWL import/export capabilities to GWL. Then 
>Snakemake/GWL conversion would be a 2 step process, using CWL as an 
>intermediate step:
>
>1. Snakemake -> CWL
>2. CWL -> GWL
>
>However, CWL is not as expressive as Snakemake. There may be some details that 
>are lost from Snakemake workflows.
>
>So a 1-step Snakemake/GWL transpiler could be interesting, as both 
>Snakemake/GWL use a domain-specific language inside a general purpose language 
>(Python/Guile respectively). There may be a possibility to achieve more 
>"accurate" translations between workflows.
>
>Is this topic something that could fit into a summer project?

Re: Projects for the Google Summer of Code

[Kyle Andrews]

Simon Tournier  writes:

> Hi,
>
>
> On Sun, 26 Feb 2023 at 16:52, Kyle  wrote:
>
>> One idea might be to write a conda importer which looks at the
>> versions of software in the resulting environment and tries to make
>> feasible package variants of make a manifest which matches the
>> existing conda environment as close as possible.
>
> Do you mean, from ’conda env export’ Which outputs something like, 
>
> name: justnumpy
> channels:
>   - defaults
> dependencies:
>   - _libgcc_mutex=0.1=main
>   - _openmp_mutex=5.1=1_gnu
>   - blas=1.0=mkl
>   - libuuid=1.41.5=h5eee18b_0
>   - mkl=2021.4.0=h06a4308_640
>   - mkl-service=2.4.0=py310h7f8727e_0
>   - mkl_fft=1.3.1=py310hd6ae3a3_0
>   - mkl_random=1.2.2=py310h00e6091_0
>   - ncurses=6.3=h5eee18b_3
>   - numpy=1.23.4=py310hd5efca6_0
>   - numpy-base=1.23.4=py310h8e6c178_0
>   - ...
>   - ...
>
> transform this into some Guix manifest.scm?  Well, indeed, it could help
> people for transitioning.

Yes, exactly. Parse the output of this command and generate a bunch of
definitions for a manifest file but which might also be upstreamed to
the guix-past repository.

>> Another idea would be to create a python package for working with Guix
>> more directly from inside their preferred language environment instead
>> of through the shell. I also wouldn't mind it if such a thing existed
>> for R as well.
>
> Do you mean ’guix.install()’ from r-guix-install?
>
> https://cran.rstudio.com/web/packages/guix.install/index.html
>
> How do you install Python packages from the Python REPL?

With the reticulate package in R, a python environment can be readily
instantiated using R code like `use_condaenv`.

https://rstudio.github.io/reticulate/articles/versions.html

In my dreams there would be a `use_guix()` command as well. Of course,
right now that R code is limited to setting up python-specific
environments and conda environments (and installing python packages into
them). However, it still might be valuable to get the name recognition
for Guix in this limited context.

While guix would be responsible for just the python environment in the
context of the reticulate package, that isn't the only possible use
case. It would be nice to write that integration for reticulate by
having them use another R package with deeper integrations built out for
managing guix itself from R. That's why I brought up RcppGuile as a path
for how R could interface directly with the Guix scheme libraries. Such
an interface might be useful for other interactive scientific
environments like python as well. The goal would be to make Guix seem
less exotic to researchers in typical scientific languages. If it's part
of their "home" computing environment, then they might be much more
interested in trying it out. This reflects a bigger scope than just
being a replacement for install.packages.

> Cheers,
> simon
>
> PS:
>
>>  Simon thought often
>> the python version usually didn't matter, but it makes users a lot
>> less woosy to stick with software combinations they have already
>> tested.
>
> This is out of context. :-)  For the context, see [1].

Thanks for the point of clarification. Sorry, I didn't add the reference
in my initial message.

> Well, if you have only one Python version, you only test against this
> one, so being able to combine on the fly the matrix of Python versions
> is not so much important – it is a collective practise inherited from
> the “unstable” Python ecosystem and I am doubtful about its relevancy
> concerning referencing software for reproducing.  Now Conda is more than
> 10 years and very very broadly used, so if its specification using
> version labels and relying on some matrix of Python versions would be
> enough for reproducibility, then I would have never landed in Guix. ;-)
>
> 1: https://yhetil.org/guix/86pma2t3jd@gmail.com
>
> My 2 cents. :-)

Later in that conversation you made the point that the purpose of the
guix-past channel was to make things like this possible. I added my
voice to this (GSOC Project) thread because I thought it would be useful
to place a fresh pair of eyes at tackling the combinatorial
configuration problems which still stand in the way of curating a large
Guix package repository with the breadth of scientific package versions
that a platform like conda provides... even if it cheats a lot by not
doing that reproducibly. Whatever they learn might also help elsewhere
in the project, such as potentially helping to curate large collections
of packages in other languages like those in Go, Rust, or even
JavaScript.

Re: Projects for the Google Summer of Code

[Kyle]

Dear Guix,

 I have been reading on this list of Andreas struggles updating python packages 
as an outsider to that community. If python programmers are not sticking 
around, then that may be sign they could use more help.

Python provides access to an unparalleled amount of functionality which greatly 
empowers users of free software. I want that functionality in Guix for everyone 
to benefit from. No one person can do it all themselves. There needs to be a 
healthy community.

I personally would love to see more support for helping scientists port their 
existing workflows from conda environments to actually reproducible containers, 
e.g. meeting them where they are and giving them more options for working with 
older versions of python3.

One idea might be to write a conda importer which looks at the versions of 
software in the resulting environment and tries to make feasible package 
variants of make a manifest which matches the existing conda environment as 
close as possible. Simon thought often the python version usually didn't 
matter, but it makes users a lot less woosy to stick with software combinations 
they have already tested.

Another idea would be to create a python package for working with Guix more 
directly from inside their preferred language environment instead of through 
the shell. I also wouldn't mind it if such a thing existed for R as well. Both 
python and R extensively interface with C. On the R side there is an RcppGuile 
proof of concept package for example. Maybe there could be a project around 
curating a standard non-bash interface of guile scripts for these and other 
interactive languages? The rational is that users in these ecosystems often 
don't have much familiarity with shell programming. Learning both shell and 
scheme at the same time can be very intimidating and demands a large upfront 
effort before the value case is clear.

As an enthusiastic beginner, I want to help as much as I can to make Guix 
better, but I  am not an expert. I just wanted to throw those ideas out there 
for you real experts to consider and maybe translate into more interesting 
technical goals you think would help the python community (and other 
communities) become more engaged.

Cheers,
Kyle



On February 26, 2023 2:38:36 AM EST, Pjotr Prins  
wrote:
>To follow up on Gábor: we excited to announce that the GNU project is
>selected as an organisation for the Google Summer of Code (GSoc). GSoC
>attracts talent and we have some people in our group who came in
>through that route! I have done 10 years of GSoC and it has paid off
>in my projects. You can still add ideas to:
>
>https://libreplanet.org/wiki/Group:Guix/GSoC-2023
>
>Currently only pukkamustard's project is listed, feel free to add
>more. You can register/login yourself. Make sure to add below
>information - title, email, hours etc. Tasks can be challenging - you
>get more interesting applicants that way. Also add simple tasks, that
>helps attract learners in Lisp, for example.
>
>The overall GNU project proposals, including GNU Mes, are listed at:
>
>https://www.gnu.org/software/soc-projects/ideas-2023.html
>
>People are already inquiring, so today is a good day to add your idea.
>
>When it comes to mentoring, in my experience it takes a few hours a
>week that have a decent ROI. Before GSoC starts we'll have a get
>together to share experiences and ideas.
>
>Pj.
>
>On Fri, Feb 24, 2023 at 07:21:51PM +0100, Gábor Boskovits wrote:
>>Hello Guix,
>>Here follows a short summary on where we are regarding the internship
>>programs.
>>GSoC:
>>This year the GNU Project was applying again for GSoC, and
>>we got the word yesterday that the GNU Project was accepted.
>>Thanks to Jose E. Marches for taking care of this.
>>This basically means that we should have a look at our ideas page,
>>and run a quick health check on the proposals, enriching them with
>>the following information where needed:
>>(quoted from the mail on the summer of code list)
>>  + Title, and description.
>>  + Skills required.
>>  + A mentor with an email address.
>>  + Whether it is a 175 hour or a 350 hour project.
>>  + Difficulty: easy, medium or hard.
>>  + CLEAR contact method for interested students.
>>From now to March 19, be ready to be contacted by contributors, in
>>whatever contact means you specified in your ideas page.  Starting in
>>March 20, contributors will start submitting their proposals through
>>the
>>program website.
>>(end quote)
>>Next week I am on holiday, so I asked Pjotr Prins to take over the
>>initial
>>coordination tasks until I am back on 6th of March, 2023.
>>Outreachy:
>>Com

Re: Building arm64 guix system image

[Akira Kyle]

On Fri, Feb 17, 2023 at 10:29 AM, Max Brieiev 
 wrote:



I want to run Guix on Apple M1 as a Qemu virtual machine.


I think I may be one of the few (only?) guix users that has a 
setup like this. IIRC getting grub setup with qemu was the one 
trickier parts of this. Feel free to ping me directly if you're 
having trouble.


On the Mac machine I run arm64 dedian image. I installed there 
guix as a
package manager. Now I am trying to create a guix system image 
to use

with Qemu, but it fails.


This is also how I got my guix system on qemu setup. For the 
record, I initially tried fedora but iirc, selinux was causing 
some difficulties.



...
I don't know where to look to fix this error. Please, help me.


This is the relevant issue 
https://issues.guix.gnu.org/60719. Unfortunately until this is 
fixed, guix system won't build since grub-efi depends on 
qemu-minimial which in turn (recently) depends on 
openbios-qemu-ppc. Fortunately this can be worked around, and I 
posted how I'm working around this for now on that issue. Maybe 
this will also work for you.


Also, I thought I could find somewhere arm64 guix build, but 
apparently

there is none?


It's been awhile since I've looked into the current status of 
building guix system installer images for aarch64 but this is the 
issue I have in my notes that was blocking this last time I looked 
into it: https://issues.guix.gnu.org/41120

Re: Help adding a graph backend

[Kyle]

Thanks, Andreas! 

For my own education I just tried running ./configure with no arguments on 
Ubuntu and it ran without error. I wasnt actually able to run pre-inst-env 
afterwards though since I am not an administrator on that system. That 
behavior, though, seems consistent with what I think you are saying: setting up 
pre-inst-env is currently easier by default for foreign distro users than for 
guixsd users. I can see how that made perfect sense when Guix was only used 
with a foreign distro. I don't know much about what is actually happening in 
./configure, but it also makes sense to me that the default now should depend 
on what the host system actually is. Then the manual could include those 
standard lines in a source block explicitly and it will all seem routine and 
not at all scary to people like me. It already seems smart enough to do that 
given it could make the right suggestion in my case.

On February 10, 2023 4:30:49 AM EST, Andreas Enge  wrote:
>Hello Kyle,
>
>Am Fri, Feb 10, 2023 at 03:10:02AM + schrieb Kyle Andrews:
>> configure: error: chosen localstatedir '/usr/local/var' does not match that 
>> of the existing installation '/var'
>
>you should do exactly as suggested: Before running "make", configure the
>Guix source code not by "./configure", but
>   ./configure --localstatedir=/var
>
>Personally I think this is a bug in Guix: It was chosen to follow the
>standard configure behaviour (installation directories under /usr/local).
>But it would probably be better to let the Guix behaviour be the one
>that everybody wants (especially newcomers), and to leave options like
>--localstatedir to people needing to do something unusual.
>
>Andreas
>

Help adding a graph backend

[Kyle Andrews]

Dear Guix,

I am not very comfortable editing Guix source code. However, I would
very much like to add a new backend for `guix graph`. Right now guix
graph descriptions can only be exported into special purpose tools like
graphviz, D3, and cypher. I would like to add a fourth option which
would support loading the dependency data into general purpose network analysis 
software tools: an edgelist backend.

=> https://en.wikipedia.org/wiki/Edge_list

I think this code will do the job, but I don't know how to test it. So, I don't 
know for sure.

``` guix/graph.scm
(define (el-prologue name port)
  (display "from, to" port))

(define (el-epilogue port)
  (display "\n" port))

(define (el-node id label port)
  (display "" port))

(define (el-edge id1 id2 port)
  (format port "~a, ~a\n"))

(define %edgelist-backend
  (graph-backend "edgelist"
 "Generate graph in CSV edge list format"
 el-prologue el-epilogue
 el-node el-edge))

(define %graph-backends
  (list %graphviz-backend
%d3js-backend
%cypher-backend
%edgelist-backend)) ; <- the new proposed backend
```

Maybe it would be using some incantation involving ./pre-inst-env? I gave it a 
try following the manual:

```
cd ~/{{path/to/guix}}
guix shell -D guix
./bootstrap
./configure
```

This gave an error:

```
configure: error: chosen localstatedir '/usr/local/var' does not match that of 
the existing installation '/var'
Installing may corrupt /gnu/store!
Use './configure --localstatedir=/var'.
```

Since I am not that excited about corrupting my /gnu/store given that I don't 
know what I am doing, I didn't proceed further. 

I figured because I wanted to extend Guix with a new feature and that I
could piece together a story in my head about how the code should look, my 
query should be sent to this list rather than to help-guix.

Thanks in advance for any helpful suggestions towards getting this backend 
added to Guix!

Cheers,
Kyle

Re: Mailman From header rewrite

[Kyle Meyer]

Kyle Meyer writes:

> Sarah Morgensen writes:
>
>> On Tuesday, January 5th, 2021 at 5:01 AM, Kyle Meyer  wrote:
>>
>>> add the appropriate "From:" header to the body of each patch. `git am`
>>> will take the in-body header over the actual header.
>>
>> I wonder if there is a way to automate the duplication of the "From"
>> header into the body of the patch?
>
> I'm not aware of an existing way at the git level.  Here's the only
> discussion I found about it on the git list [...]

Git 2.38.0 gained support for this via a --force-in-body-from option and
the associated format.forceInBodyFrom config variable.

  https://lore.kernel.org/git/20220829213837.13849-1-gits...@pobox.com/

Re: public-inbox v1.7 update (was: Updating mumi on berlin)

[Kyle Meyer]

zimoun writes:

> [...]
> Well, using the plain Git repo, it is easy to:
>
>  1. get messages from a list starting at a date;
> using ’git clone --mirror --shallow-since=’
>
>  2. get all the new messages;
> (using ’git pull)
>[...]
> IIUC, ’lei’ avoid this manual dance with the Git repo and do it for me.

It depends.  Yes, you can use it in a way that avoids needing to clone
down repos and index them; in that case you're relying on the remote
instance.

Or you can clone and index the repos yourself and point lei at them.
You can do this with `lei add-external --mirror', but you still have to
update the repos yourself (see example at
).

If you go the clone/index route, however, I'd recommend using grokmirror
to fetch Git repositories from public-inbox instances.  (In
https://issues.guix.gnu.org/43637#1 <878scww903@kyleam.com/>, I
provided an example config that mirrors Guix-related inboxes at
yhetil.org.)

> Well, what I miss is the lei “saved search” query for all messages.
> Other said,
>
> lei q d:..
> lei up
>
> fits #1.  Then, how do I achieve #2?

For remote externals, `lei up' will pull in updates from the remote.
For local externals (things you've cloned down and indexed yourself),
you need to do something to pull in those update (e.g., a grok-pull or a
`git fetch').

> The workflow using “saved search” is not clear for me.  Before investing
> some time, especially when ’lei’ is not packaged in Guix, I would like
> to be sure about how to run «my workflow».

I don't regularly used saved searches myself, so I don't know that I can
be much help, even if I had a clear picture of what you wanted in your
workflow.

Fwiw my setup is:

 1) use nntp via Gnus to skim new messages on mailing lists

 2) if I want to participate in a thread, use
piem-inject-thread-into-maildir to get the messages into my local
mail store and my Notmuch index.

 3) If I want to search for messages, I use lei-q via piem-lei-q.

Using grokmirror and a configured pull.post_update_hook, I fetch
updates for and index a subset yhetil.org inboxes that I want to
have available locally for searching.

(I use piem-inject-thread-into-maildir here too.)

I'd eventually like to be able to follow list with lei via piem's
interface, but things aren't there yet.

public-inbox v1.7 update (was: Updating mumi on berlin)

[Kyle Meyer]

zimoun writes:

> …why not just disable the specific test or if not possible, turn off the
> test suite ’#:tests? #f’.  Whereas it is not the best, it would allow to
> have ’lei’ while waiting the fix at the Guix build environment level.
>
> WDYT?

public-inbox has a good test suite, so it'd be nice to keep most of it
wired up.  No objections from me about disabling the lei tests (or a
subset of them), though I haven't looked into it, so perhaps it's tricky
to do cleanly.

>> $ guix shell -p path/to/profile -- lei up --all
>
> How do you query all new ones for a specific list?

Rather than pass --all, you can call `lei up OUTPUT', where OUTPUT is a
particular saved search generated by `lei q', so you could have a saved
search that's specific for a list or set of lists:

   $ lei ls-external | grep guix
   /home/kyle/inboxes/guix-bugs boost=0
   /home/kyle/inboxes/guix-devel boost=0
   /home/kyle/inboxes/guix-patches boost=0
   /home/kyle/inboxes/guix-science boost=0
   /home/kyle/inboxes/guix-user boost=0

   $ lei q -I 'guix-*' -o /tmp/zimoun-on-guix d:20.days.ago.. f:zimoun
   $ lei up /tmp/zimoun-on-guix

See https://public-inbox.org/lei-up.txt and
https://public-inbox.org/lei-q.txt

> Kyle, the function ’piem-inject-thread-into-maildir’ [2] is really
> handy.  But I would like this signature instead:
>
> --8<---cut here---start->8---
>   (defun piem-inject-thread-into-maildir (mid  inbox message-only)
> --8<---cut here---end--->8---
> [...]

Without thinking too much about it, that sounds fine to me.  I'll plan
to send a patch to piem's inbox with you cc'd within the next week or
two.

Re: Updating mumi on berlin

[Kyle Meyer]

zimoun writes:

> On Tue, 03 May 2022 at 17:42, Thiago Jung Bauermann  
> wrote:
[...]
>> Just an aside about public-inbox: Starting with version 0.7 it ships
>> with a ‘lei’ tool that can be used to query a local or remote
>> public-inbox repo, and export the matching messages to a maildir.
>
> Thanks.  Maybe I am missing something, “guix show public-inbox” tells
> version 1.6.1 but I do not find ’lei’.  Anyway.

Yes, Thiago must have meant to write 1.7, not 0.7.

I've tried sit down and update Guix's public-inbox definition a few
times, but there are various test failures that I didn't figure out how
to handle in the time I had.  (IIRC, I think they're related to the lei
tests expecting to be able to kill the lei-daemon process, which isn't
the case in Guix's build environment.)

Re: WARNING: Git merges are tricky. Rebasing is better?

[Kyle Meyer]

Leo Famulari writes:

> On Mon, Jan 17, 2022 at 05:26:08PM -0500, Kyle Meyer wrote:
>> Fwiw I don't think Git automatically resolved that conflict:
>> 
>>   $ git checkout 276f40fdc349d2ad62582b23ea55e061b689cfc0^
>>   $ git merge 276f40fdc349d2ad62582b23ea55e061b689cfc0^2
> [...]   
>>   ++<<<<<<< HEAD
>>+"0r7m34xzz3shdfxf2abxb069izak3yv3ijlg29qy4pfmyawkilfs"))
>>+  (patches
>>+   (search-patches 
>> "epiphany-update-libportal-usage.patch"
>>   ++||| d91de53caa
>>   ++
>> "0r7m34xzz3shdfxf2abxb069izak3yv3ijlg29qy4pfmyawkilfs"
>>   ++
>>   ++===
>>   + 
>> "0k7b22zq3z1kllzqxgwsvwb1lp0j6rjb3k1hvhna3i573wc4mpji"
>>   + 
>>   ++>>>>>>> 276f40fdc349d2ad62582b23ea55e061b689cfc0^2
>
> So, you think it was a mistake made when resolving conflicts by hand? I
> can certainly understand that.

Yes.

> Either way, it's bad that the Git history doesn't show these types of
> changes.

Right, inspecting merge results can be confusing.  By default that
change is pruned from diffs as "uninteresting" because the merge result
matched the content in one of the parents (discussed in the "COMBINED
DIFF FORMAT" section of git-diff's manpage and the --diff-merges
description of git-show's manpage).

  $ git show 276f40fd | grep 0r7m34xzz
  $ git show --diff-merges=combined 276f40fd | grep 0r7m34xzz
   +"0r7m34xzz3shdfxf2abxb069izak3yv3ijlg29qy4pfmyawkilfs"))

Re: WARNING: Git merges are tricky. Rebasing is better?

[Kyle Meyer]

Leo Famulari writes:

> --
> $ git show 276f40fdc349d2ad62582b23ea55e061b689cfc0:gnu/packages/gnome.scm | 
> grep "define-public epiphany" -A11
> (define-public epiphany
>   (package
> (name "epiphany")
> (version "41.2")
> (source (origin
>   (method url-fetch)
>   (uri (string-append "mirror://gnome/sources/epiphany/"
>   (version-major version) "/"
>   "epiphany-" version ".tar.xz"))
>   (sha256
>(base32
> "0r7m34xzz3shdfxf2abxb069izak3yv3ijlg29qy4pfmyawkilfs"))
> --   ^
> *This is the hash of Epiphany 40.3, the old version!*
>
> Git's automatic merge conflict resolution algorithm did the wrong thing
> here. And Git does not show the reversion in `git log`, hiding it from
> review.
>
> My guess is that commit f7afefba0 ("gnu: epiphany: Fix build with
> libportal-0.5."), which happened on the master branch while the
> version-1.4.0 branch was forked off, made Git think that this line was
> more "up to date" on master than on version-1.4.0, causing it to select
> the old hash when faced with the conflict.

Fwiw I don't think Git automatically resolved that conflict:

  $ git checkout 276f40fdc349d2ad62582b23ea55e061b689cfc0^
  $ git merge 276f40fdc349d2ad62582b23ea55e061b689cfc0^2
  
  $ git status -- gnu/packages/gnome.scm
  HEAD detached at b2f6b6f6b9
  You have unmerged paths.
  
  Unmerged paths:
both modified:   gnu/packages/gnome.scm
  
  no changes added to commit
  
  $ git diff -- gnu/packages/gnome.scm
  diff --cc gnu/packages/gnome.scm
  index d8d34c89ed,6c63b8bc59..00
  --- a/gnu/packages/gnome.scm
  +++ b/gnu/packages/gnome.scm
  @@@ -6433,13 -6415,10 +6421,12 @@@ supports playlists, song ratings, and a
name "-" version ".tar.xz"))
(sha256
 (base32
   -  "0ddjwcd77nw0rxb5x5bz5hd671m8gya9827p8rsnb58x103kpai8"
   +  "0ddjwcd77nw0rxb5x5bz5hd671m8gya9827p8rsnb58x103kpai8"))
   +;; XXX: Remove when upgrading to 42.0
   +(patches (search-patches "eog-update-libportal-usage.patch"
   (build-system meson-build-system)
   (arguments
  - `(#:meson ,meson-0.59 ;positional arguments error with meson 
0.60
  -   #:configure-flags
  + `(#:configure-flags
  ;; Otherwise, the RUNPATH will lack the final 'eog' path component.
  (list (string-append "-Dc_link_args=-Wl,-rpath="
   (assoc-ref %outputs "out") "/lib/eog"))
  @@@ -6798,9 -6776,8 +6784,17 @@@ a secret password store, an adblocker, 
  "epiphany-" version ".tar.xz"))
  (sha256
   (base32
  ++<<< HEAD
   +"0r7m34xzz3shdfxf2abxb069izak3yv3ijlg29qy4pfmyawkilfs"))
   +  (patches
   +   (search-patches "epiphany-update-libportal-usage.patch"
  ++||| d91de53caa
  ++"0r7m34xzz3shdfxf2abxb069izak3yv3ijlg29qy4pfmyawkilfs"
  ++
  ++===
  + "0k7b22zq3z1kllzqxgwsvwb1lp0j6rjb3k1hvhna3i573wc4mpji"
  + 
  ++>>> 276f40fdc349d2ad62582b23ea55e061b689cfc0^2
(build-system meson-build-system)
(arguments
 `(#:glib-or-gtk? #t

Re: guix fails to build on aarch64

[Akira Kyle]

Ricardo Wurmus  writes:
> > test-name: file-needed/recursive
> > location:
> > /tmp/guix-build-guix-1.3.0-14.2a621f1.drv-0/source/tests/gremlin.scm:70
> > source:
> …
> > + (and (zero? (close-pipe pipe))
> > +  (lset= string=?
> > + (pk 'truth ground-truth)
> > + (pk 'needed needed)
> > actual-value: #f
> > result: FAIL

> Did the logs not contain the values for truth and needed?  That would
> mean that the test already failed to close the pipe.

I've been trying to debug failing guix tests on aarch64. At the end of
logfile for the gremlin test suite there's the following which may be
related to why the truth and needed values were not printed:

a.out: stripping RUNPATH to
("/gnu/store/skfhr2f8b7jnnpiarrrcjn6qx0xzfw00-glibc-2.33/lib"
"/gnu/store/47snyrq6pq6896m9dysp2s5vx53m6x08-gcc-10.3.0-lib/lib"
"/gnu/store/47snyrq6pq6896m9dysp2s5vx53m6x08-gcc-10.3.0-lib/lib/gcc/aarch64-unknown-linux-gnu/10.3.0/../../.."
"/gnu/store/40lx91wz35qci25qzi9xfqvxwby85xha-profile/lib") (removed
("/foo" "/bar"))
a.out: warning: RUNPATH contains bogus entries:
("/gnu/store/skfhr2f8b7jnnpiarrrcjn6qx0xzfw00-glibc-2.33/lib"
"/gnu/store/47snyrq6pq6896m9dysp2s5vx53m6x08-gcc-10.3.0-lib/lib"
"/gnu/store/47snyrq6pq6896m9dysp2s5vx53m6x08-gcc-10.3.0-lib/lib/gcc/aarch64-unknown-linux-gnu/10.3.0/../../.."
"/gnu/store/40lx91wz35qci25qzi9xfqvxwby85xha-profile/lib")
a.out: error: depends on 'libgcc_s.so.1', which cannot be found in RUNPATH ()
WARNING: (test-gremlin): imported module (guix build utils) overrides
core binding `delete'

There are other tests failing as well and the full test-suite.log I
posted here: https://issues.guix.gnu.org/52943

I'm a newcomer to guix so I feel a bit out of my depth trying to debug
these failures. I'd really like to be able to use guix as my daily
driver but so far it's been difficult since my machine is aarch64!

guix fails to build on aarch64

[Akira Kyle]

I think this is the related issue: https://issues.guix.gnu.org/52943

Re: Formalizing teams

[Kyle Meyer]

Lars-Dominik Braun writes:

> Hi Maxim,
>
>> I've grown to like our apparent lack of structure; we interact globally
>> on any topic of interest and the discussions all happen in a shared
>> space, which makes it easy to stay informed with everything that's going
>> on (do we really need more mailing lists to follow?  I don't think so --
>> our current volume doesn't warrant it).
> to me this is a disadvantage. I don’t have enough time at my hands to
> look at every single thread and patch in my inbox and decide whether
> I can/want to work on it. Thus I’d prefer if I could unsubscribe
> from -patches (I’m not even subscribed to -bug/-commit) and instead
> only look at bugs/patches/commits related to packages/components I’m
> interested into/I actually use.

Fwiw public-inbox indexes the file name from diffs, so you might find
searching with the "dfn:" against the archive at
 useful.  For example:

  https://yhetil.org/guix-patches/?q=dfn%3Agnu%2Fpackages%2Fpython-web.scm

Or with public-inbox's lei (from v1.7.0, which isn't yet packaged for
Guix), you could dump those results to a maildir:

  $ lei q -o /tmp/mdir --mua mutt \
-I https://yhetil.org/guix-patches dfn:gnu/packages/python-web.scm 
d:4.months.ago..
  # later: update with new results and visit in mutt
  $ lei up --mua mutt /tmp/mdir

If you're interested, I went into a bit more detail about this at
.

public-inbox/elfeed -> Maildir bridge (was: Incentives for review)

[Kyle Meyer]

zimoun writes:

> On Fri, 22 Oct 2021 at 21:43, Kyle Meyer  wrote:
[...]
>>   https://yhetil.org/guix-patches/?q=dfn:docker=A
>
> Oh, that’s really cool!
>
> Do you know a bridge from Elfeed to Message-mode?
>
> I mean, using the feed you are referring, Alice gets:
>
> --8<---cut here---start->8---
> Title: [bug#50227] [PATCH] build-system/go: Trim store references using the 
> native compiler option.
> Author: Marius Bakke 
> Date: Fri, 27 Aug 2021 18:45:37 CEST
> Feed: dfn:docker - search results
> Link: https://yhetil.org/guix-patches/20210827164423.17109-1-mar...@gnu.org/
>
> * guix/build/go-build-system.scm (build): Add '-trimpath' to the 'go install'
> invocation.
> […]
> --8<---cut here---end--->8---
>
> This is really nice for filtering and only reading what is of interest
> (for Alice).
>
> However, it is not handy for commenting.  It could be cool to have a way
> to turn what I showed (above) into a reply message.  Does a bridge exist
> somewhere?

Good question.  It does :)

With the link in the Elfeed buffer, we can grab the mbox for a message
or entire thread from a public-inbox instance.  So, for those that use a
Maildir locally, the steps are to

  1) download the message (or thread)
  2) convert the mbox into Maildir messages
  3) visit the message in your regular mail client
  4) proceed as usual

piem can take care of 1 and 2 (as well as 3, with some user
configuration) via its piem-inject-thread-into-maildir command:

  https://docs.kyleam.com/piem/Injecting-messages-into-a-Maildir-directory.html

This command isn't specific to Elfeed buffers.  It just needs to be in a
buffer where piem knows how to grab the public-inbox link:

  https://docs.kyleam.com/piem/Enabling-integration-libraries.html

The other supported modes that are interesting in this context are EWW
and Gnus.

Elfeed -> Notmuch
=

zimoun, I know you're a Notmuch user, so here's how you could configure
things so that calling piem-inject-thread-into-maildir from the Elfeed
buffer above throws you into a Notmuch show buffer for the message.

 * add a guix-patches entry to piem-inboxes

 (add-to-list 'piem-inboxes
  '("guix-patches" :url "https://yhetil.org/guix-patches/;))

 * point piem to your Maildir

 (setq piem-maildir-directory "/path/to/maildir/")

   Alternatively, messages for different projects can be sent to
   different Maildir directories using the :maildir keyword in the
   piem-inboxes entry.  (This feature was added by Xinglu Chen :>)

 * enable Elfeed integration

 (piem-elfeed-mode 1)

 * tell piem to visit the message in Notmuch after injecting

 (add-hook 'piem-after-mail-injection-functions
 (lambda (mid)
   (require 'notmuch-lib)
   (message "Running notmuch new")
   (call-process notmuch-command nil nil nil "new")
   (notmuch-show (concat "id:"  mid

   You actually asked about ending up in a (Notmuch) message mode buffer
   rather than a Notmuch show buffer.  Perhaps tossing a
   notmuch-show-reply in there after notmuch-show will work as expected,
   though I haven't tested it.

lei
===

This email is already too long, but I should briefly mention that Eric
Wong (public-inbox's creator) has been working on a local command-client
client for public-inbox called lei (local email interface).

To continue with the original dfn example, you could do something like
this with lei to dump those results to a Maildir and then view those in
mutt:

  $ lei q -o /tmp/mdir --mua mutt \
-I https://yhetil.org/guix-patches dfn:docker d:4.months.ago..
  # later: update with new results and visit in mutt
  $ lei up --mua mutt /tmp/mdir

Anyway, that's just a small piece of what lei can do, and IMO it's
really impressive and exciting.  It will be a part of the next
public-inbox release, v1.7.  (How this all ends up integrating with piem
is very much up in the air.)

For a high-level picture that includes public-inbox, lei, and b4:
Konstantin Ryabitsev, b4's creator, recently talked at the Linux
Plumbers Conference:

  
https://linuxplumbersconf.org/event/11/contributions/983/attachments/759/1421/Doing%20more%20with%20lore%20and%20b4.pdf

The lei part starts on page 24.  I believe there's a video out there,
but I haven't watched it and don't have a link on hand.

Re: Incentives for review

[Kyle Meyer]

Thiago Jung Bauermann writes:

> Em quinta-feira, 21 de outubro de 2021, às 10:38:44 -03, Artem Chernyak 
> escreveu:
[...]
>> One thing that could help this, is to include a little more info in
>> the subject line for patches. Right now we include the broad area
>> (e.g. "gnu: ..."). But we could go on level deeper and include the
>> specific file (e.g. "gnu: docker: ..."). This becomes important
>> because gnu as an area of guix spans a lot of different packages and
>> languages. With the extra file level information, we can easily filter
>> it down to only the areas we know about.
>
> That is a good idea. I agree that it would be helpful.

Fwiw public-inbox () indexes the file name
from diffs.  Searching with the "dfn:" prefix against
, you can get a feed of changes
touching particular paths by using the "dfn:" prefix .  For example:

  https://yhetil.org/guix-patches/?q=dfn:docker=A

Re: Mailman From header rewrite

[Kyle Meyer]

Sarah Morgensen writes:

> On Tuesday, January 5th, 2021 at 5:01 AM, Kyle Meyer  wrote:
>
>> add the appropriate "From:" header to the body of each patch. `git am`
>> will take the in-body header over the actual header.
>
> I wonder if there is a way to automate the duplication of the "From"
> header into the body of the patch?

I'm not aware of an existing way at the git level.  Here's the only
discussion I found about it on the git list:

  
https://lore.kernel.org/git/305577c2-709a-b632-4056-658277117...@redhat.com/T/#u

As a hacky/ugly way, for those that are okay tweaking the way their
names ends up on the mailing list, they can adjust `send-email --from=`
(or sendemail.from) slightly so that it doesn't match
user.name/user.email, and then send-email should take care of adding an
in-body header for user.name/user.email.

Another option is of course to feed the patches to a custom
post-processing script that adds the in-body "From:", where the details
would depend a bit on the person's patch workflow.

Or, moving that work a bit upstream, I think it'd be fairly
straightforward to wire up a prepare-commit-msg hook that would insert
an in-body "From:" (after checking some things, like whether the commit
is being amended).  I guess the main disadvantage of handling it at this
spot is the risk of commits with in-body "From:" headers unintentionally
being merged/pushed directly to the main line (given the person has
commit access).

Re: Mailman From header rewrite (was: [bug#45644] closed (Re: [bug#45644] [PATCH] gnu: esbuild: Update to 0.8.29.))

[Kyle Meyer]

Kyle Meyer writes:

> As an example, the patch you feed to git-send-email would look something
> like this:
>
> --8<---cut here---start->8---
> From ad2469ec86357b1a46dd63dcd17d5831969d5270 Mon Sep 17 00:00:00 2001
> From: Ryan Prior 
> Date: Mon, 4 Jan 2021 01:47:34 +
> Subject: [PATCH] gnu: esbuild: Update to 0.8.29.
>
> From: Ryan Prior 
>
> * gnu/packages/web.scm (esbuild): Update to 0.8.29.
>
> Signed-off-by: Leo Famulari 

Oops, sorry about the spurious Signed-off-by trailer here.  I forgot to
prune that after calling format-patch with ad2469ec86.

Mailman From header rewrite (was: [bug#45644] closed (Re: [bug#45644] [PATCH] gnu: esbuild: Update to 0.8.29.))

[Kyle Meyer]

Ryan Prior via Guix-patches via writes:

>> By the way, your patches show that they are authored by "Ryan Prior
>> via Guix-patches via guix-patc...@gnu.org". Is that the correct email
>> address?
>
> No, the correct email address is rpr...@protonmail.com
>
> There's maybe 15 commits in Guix that have that incorrect email
> address. I'm not sure where it comes from or how to get rid of it. I
> send my patches by running a command like:
>
> git send-email --to=guix-patc...@gnu.org --suppress-cc=self 
> 0001-gnu-esbuild-Update-to-0.8.29.patch
>
> Git has my correct email address:
>
> $ git config user.email
> rpr...@protonmail.com
>
> So I have to imagine that either Protonmail or your email server are
> changing the email address.

To add a couple of links to what Tobias mentioned downstream, I believe
the From header rewrite is a DMARC-related mitigation on Mailman's part:

  https://wiki.list.org/DEV/DMARC
  
https://docs.mailman3.org/projects/mailman/en/latest/src/mailman/handlers/docs/dmarc-mitigations.html

As far as I understand, protonmail is relevant here only in that,
depending on the Mailman configuration, the originating server's DMARC
policy will affect Mailman's decision to rewrite the From header.

> If there's some behavior I can change to keep it from happening again
> the future I will certainly be flexible.
>
> One thing I'm going to try (unless there's any objection) is to try
> sending email [...]

Here's a way that doesn't involve changing where you're sending from:
add the appropriate "From:" header to the *body* of each patch.  `git
am` will take the in-body header over the actual header.  (One use of
this technique is to include a patch from someone else in a series.)

As an example, the patch you feed to git-send-email would look something
like this:

--8<---cut here---start->8---
>From ad2469ec86357b1a46dd63dcd17d5831969d5270 Mon Sep 17 00:00:00 2001
From: Ryan Prior 
Date: Mon, 4 Jan 2021 01:47:34 +
Subject: [PATCH] gnu: esbuild: Update to 0.8.29.

From: Ryan Prior 

* gnu/packages/web.scm (esbuild): Update to 0.8.29.

Signed-off-by: Leo Famulari 
---
 gnu/packages/web.scm | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/gnu/packages/web.scm b/gnu/packages/web.scm
index 34998b94a5..20a40560e2 100644
--- a/gnu/packages/web.scm
+++ b/gnu/packages/web.scm
@@ -1487,7 +1487,7 @@ (define-public tidy
 (define-public esbuild
   (package
 (name "esbuild")
-(version "0.8.27")
+(version "0.8.29")
 (source
  (origin
(method git-fetch)
@@ -1496,7 +1496,7 @@ (define-public esbuild
  (commit (string-append "v" version
(file-name (git-file-name name version))
(sha256
-(base32 "1n9h6r3q6mik7p5j0cyybh1sdcllig0awbryrx28r03cxv4ip2ij"))
+(base32 "142gc21aaqmx0d01vmqsg7zi85pjgi3higr4ba0m52qf3mvxd6as"))
(modules '((guix build utils)))
(snippet
 '(begin
-- 
2.29.2
--8<---cut here---end--->8---

Re: Mummi wishlist: API using Message-ID

[Kyle Meyer]

Kyle Meyer writes:

> For public-inbox URLs, there is one character that needs to be escaped:
> "/" with "%2F" (see <https://yhetil.org/guix-devel/_/text/help/>).

Correcting myself: I shouldn't take that help page as a complete
description of what needs to be escaped for public-inbox URLs.  It'd be
better to look at what public-inbox's code does itself, particularly
when it generates the path component of the URL for its Archived-At
header.  It feeds the message ID through this function:

,[ lib/PublicInbox/MID.pm ]
| # RFC3986, section 3.3:
| sub MID_ESC () { '^A-Za-z0-9\-\._~!\$\&\';\(\)\*\+,;=:@' }
| sub mid_escape ($) { uri_escape_utf8($_[0], MID_ESC) }
`

That code came with 9d1e5fad (www: do not unecessarily escape some chars
in paths, 2016-08-14).

So, if you want to perform the same escaping for your custom Elisp
function that generates public-inbox URLs, you can do something like
this:

(let ((unreserved-chars
   (append url-unreserved-chars
   '(?! ?$ ?& ?' ?\( ?\) ?* ?+ ?, ?= ?: ?@ ?\;
  (url-hexify-string "8...@e.com" unreserved-chars)  ; => "8...@e.com"
  (url-hexify-string "8...@e.com" unreserved-chars)  ; => "8...@e.com"
  (url-hexify-string "8/@e.com" unreserved-chars)) ; => "8...@e.com"

Or, if you don't mind the unnecessary escaping (particularly of "@"),
you can just use url-hexify-string with the default set of unreserved
characters.

Re: Mummi wishlist: API using Message-ID

[Kyle Meyer]

zimoun writes:

> On Thu, 17 Sep 2020 at 12:00, Ricardo Wurmus  wrote:

>> This is an interesting idea!  I don’t know if it’ll work as a plain URL,
>> because not all characters of a message id might be usable in a URL (you
>> may need to URL-encode it and can’t just paste it in the URL bar of your
>> browser), but it would certainly work as a search query.  The only
>> problem is that we’re not currently indexing the message ids.
>
> I do not know but public-inbox is doing such thing, isn't it?
> I mean, the example with emacs-debbugs, my "custom" function and the
> service :
>
[...]
> Is it not enough?
> The URL,  is it not always ready-to-be-pasted?
> The link contains '@' but it works (on my webbrowser at least :-)).

For public-inbox URLs, there is one character that needs to be escaped:
"/" with "%2F" (see ).

However, in its current form, your custom function has a good chance of
being enough.  Here is the number of message IDs known to
yhetil.org/guix-devel:

$ echo 'SELECT COUNT(*) FROM msgmap' | \
sqlite3 -readonly guix-devel-msgmap.sqlite3
55231

And of those, only 11 have "/" in them:

$ echo 'SELECT mid FROM msgmap' | \
sqlite3 -readonly guix-devel-msgmap.sqlite3 | grep -c "/"
11

Re: bug#38529: Make --ad-hoc the default for guix environment proposed deprecation mechanism

[Kyle Meyer]

Gábor Boskovits  writes:

> Konrad Hinsen  ezt írta (időpont: 2019. dec.
> 17., Ke 7:52):
[...]
>> How about a more drastic measure: deprecate "guix environment" and
>> introduce a new subcommand with the desired new behaviour?
>>
> That is also the other option I was thinking about. Do you have any good
> idea in mind as how to call it? Of course the classic guix environment2
> comes to my mind, but it does not look very appealing to me.

Perhaps "guix env"?

Re: git-annex: problematic shebangs in .git/hooks/pre-commit?

[Kyle Meyer]

Timothy Sample  writes:

> Kyle Meyer  writes:

[...]

>> Perhaps I'm just missing something, but to spell out my concern a
>> little
>> more: I have /gnu/store/A/git-annex and /gnu/store/X/bash-minimal.  I
>> set up a repo with 'git annex init', and
>> /gnu/store/X/bash-minimal/bin/sh is used in the shebang.
>>
>> Some time later I am using /gnu/store/B/git-annex, which references
>> /gnu/store/Y/bash-minimal.  That repo's hook still uses the
>> X/bash-minimal/bin/sh.  But if /gnu/store/X/bash-minimal is no longer
>> referenced by any package, it could be garbage collected, leading to
>> the
>> hook failing.
>
> Ah yes!  That could be a problem indeed.  Good catch.  Following the
> example of autoconf, it seems it should just be left alone.

Revisiting this, I tried to simply remove the patch-shell phase (diff
below).  That worked as intended when I tested manually, but it caused
many test failures with messages like

fatal: cannot run .git/hooks/pre-commit: No such file or directory

Although the error message isn't too clear, this happens because
/bin/sh, now used in the hook shebangs, isn't available to the tests
executed in the build environment.

Any suggestions on how to deal with this?

---
diff --git a/gnu/packages/version-control.scm b/gnu/packages/version-control.scm
index dc2abb0c71..56fe6f5e7a 100644
--- a/gnu/packages/version-control.scm
+++ b/gnu/packages/version-control.scm
@@ -2236,11 +2236,6 @@ (define-public git-annex
'("--flags=-Android -Assistant -Pairing -S3 -Webapp -WebDAV")
#:phases
(modify-phases %standard-phases
- (add-before 'configure 'patch-shell
-   (lambda _
- (substitute* "Utility/Shell.hs"
-   (("/bin/sh") (which "sh")))
- #t))
  (add-before 'configure 'factor-setup
(lambda _
  ;; Factor out necessary build logic from the provided

Re: improve installation instructions

[Kyle Meyer]

Ricardo Wurmus  writes:

> Hey,
>
> I just installed Guix as a package manager on an aarch64 box.  The
> manual makes it a little difficult to perform all these steps, because
> the commands cannot be easily copied.  We do have the shell script, but
> the manual mentions it only in passing – as a user I skipped over the
> introduction and went straight to step 1, right past the script.

I've installed Guix on a foreign distro a few times and didn't realize
that that script existed, so I must have skipped past it each time.

> What do you think about mentioning the script in the Installation
> section and only asking users to look in the subsections for details?

Looks good.  I think it would certainly help hasty readers like me.

Thanks.

-- 
Kyle

Re: failing git-annex build

[Kyle Meyer]

Hi Ricardo,

Ricardo Wurmus  writes:

[...]

>> % ./pre-inst-env guix build -K --check git-annex
>> Utility/Exception.hs:29:1: error:
>> Bad interface file: 
>> /gnu/store/qb3knv1h536sdjqc4nfkm3j1l8n7q87a-ghc-exceptions-0.10.0/lib/ghc-8.4.3/exceptions-0.10.0/Control/Monad/Catch.dyn_hi
>> Something is amiss; requested module  
>> exceptions-0.10.0:Control.Monad.Catch differs from name found in the 
>> interface file exceptions-0.10.0:Control.Monad.Catch (if these names look 
>> the same, try again with -dppr-debug)
>>|
>> 29 | import Control.Monad.Catch as X hiding (Handler)
>>| 
>
> It seems to me that this is a more general problem affecting all of our
> Haskell packages.  The configure phase that you didn’t paste should show
> that modules are provided by slightly different packages.

Sorry for snipping relevant output (I meant to at least indicate that I
had snipped :/ ).  I've attached the full output now.  (FWIW it looks
like that failure happens in the pre-configure stage, so it doesn't get
to the configure phase.)

> The haskell-build-system suffers from non-determinism.  It might just be
> limited to the package database files that are generated by ghc-pkg
> (where readdir is used and the result isn’t sorted).
>
> I’m opening a bug report for this issue.

OK, thank you.

building /gnu/store/yf5bkdya8krhdc29n518gbhvwkbn2ax4-git-annex-6.20180926.drv...
starting phase `set-SOURCE-DATE-EPOCH'
phase `set-SOURCE-DATE-EPOCH' succeeded after 0.0 seconds
starting phase `set-paths'
environment variable `PATH' set to 
`/gnu/store/564215v4ma3jqxai20hf1ymcrn60nm44-ghc-8.4.3/bin:/gnu/store/f0w0v1hn3rryh1351xjqrv3p8v7x80xa-curl-7.61.1/bin:/gnu/store/5hyjiyjzfhlnh5zzrqwnf8z9ywyy97q1-git-2.20.1/bin:/gnu/store/lyf1wd60rj8pcbkvivg9id5jc5hfh096-rsync-3.1.3/bin:/gnu/store/bl3pxxj6frg0dww8pj5dvh2d1akwvj47-tar-1.30/bin:/gnu/store/h0c398zan9ibhk4w0c944vp5pwgzkfpd-gzip-1.9/bin:/gnu/store/j74aabxwayjl9yfyrm6ni482gykxq48b-bzip2-1.0.6/bin:/gnu/store/9425b5dwpfc04bb4p58hsjypxghliyr3-xz-5.2.4/bin:/gnu/store/ypiyk8ngn79cz655jrl0hng37xv54yjr-file-5.33/bin:/gnu/store/4bzzz0lzjc9b7bfsnqbq2j22d4fvf433-diffutils-3.6/bin:/gnu/store/a4rxl40jr7gmq8bp3dryq4yq67cwkwiw-patch-2.7.6/bin:/gnu/store/fd621k6fmdnr1yiw0lbvw5spqaa169j3-findutils-4.6.0/bin:/gnu/store/l67sib1ld0fgyf0f4vrzyxnmn4yvimvb-gawk-4.2.1/bin:/gnu/store/lmfddplnplxd03bcqv3w9pynbnr1fp8k-sed-4.5/bin:/gnu/store/02k245xy33cvcnr8vm3lagm9zmb1s2wa-grep-3.1/bin:/gnu/store/5s2nib1lrd2101bbrivcl17kjx1mspw6-coreutils-8.30/bin:/gnu/store/7j3941iannrngdvgbclyxid12vds5w9i-make-4.2.1/bin:/gnu/store/q19l04vd2za80mk1845pz7r8cz29qk43-bash-minimal-4.4.23/bin:/gnu/store/9ysmg2739n1ms84lx6hifncgc5l2hiy9-ld-wrapper-0/bin:/gnu/store/02iklp4swqs0ipxhg5x9b2shmj6b30h1-binutils-2.31.1/bin:/gnu/store/n2p1zs14y89lwkg9da68y12pc10c6sw9-gcc-5.5.0/bin:/gnu/store/h90vnqw0nwd0hhm1l5dgxsdrigddfmq4-glibc-2.28/bin:/gnu/store/h90vnqw0nwd0hhm1l5dgxsdrigddfmq4-glibc-2.28/sbin'
find-files: 
/gnu/store/95kh84bshclvjlbjndf1255pgq16sdlj-git-annex-6.20180926.tar.gz/lib/ghc-8.4.3:
 Not a directory
find-files: 
/gnu/store/f0w0v1hn3rryh1351xjqrv3p8v7x80xa-curl-7.61.1/lib/ghc-8.4.3: No such 
file or directory
find-files: 
/gnu/store/5hyjiyjzfhlnh5zzrqwnf8z9ywyy97q1-git-2.20.1/lib/ghc-8.4.3: No such 
file or directory
find-files: 
/gnu/store/lyf1wd60rj8pcbkvivg9id5jc5hfh096-rsync-3.1.3/lib/ghc-8.4.3: No such 
file or directory
find-files: /gnu/store/bl3pxxj6frg0dww8pj5dvh2d1akwvj47-tar-1.30/lib/ghc-8.4.3: 
No such file or directory
find-files: /gnu/store/h0c398zan9ibhk4w0c944vp5pwgzkfpd-gzip-1.9/lib/ghc-8.4.3: 
No such file or directory
find-files: 
/gnu/store/j74aabxwayjl9yfyrm6ni482gykxq48b-bzip2-1.0.6/lib/ghc-8.4.3: No such 
file or directory
find-files: /gnu/store/9425b5dwpfc04bb4p58hsjypxghliyr3-xz-5.2.4/lib/ghc-8.4.3: 
No such file or directory
find-files: 
/gnu/store/ypiyk8ngn79cz655jrl0hng37xv54yjr-file-5.33/lib/ghc-8.4.3: No such 
file or directory
find-files: 
/gnu/store/4bzzz0lzjc9b7bfsnqbq2j22d4fvf433-diffutils-3.6/lib/ghc-8.4.3: No 
such file or directory
find-files: 
/gnu/store/a4rxl40jr7gmq8bp3dryq4yq67cwkwiw-patch-2.7.6/lib/ghc-8.4.3: No such 
file or directory
find-files: 
/gnu/store/fd621k6fmdnr1yiw0lbvw5spqaa169j3-findutils-4.6.0/lib/ghc-8.4.3: No 
such file or directory
find-files: 
/gnu/store/l67sib1ld0fgyf0f4vrzyxnmn4yvimvb-gawk-4.2.1/lib/ghc-8.4.3: No such 
file or directory
find-files: /gnu/store/lmfddplnplxd03bcqv3w9pynbnr1fp8k-sed-4.5/lib/ghc-8.4.3: 
No such file or directory
find-files: /gnu/store/02k245xy33cvcnr8vm3lagm9zmb1s2wa-grep-3.1/lib/ghc-8.4.3: 
No such file or directory
find-files: 
/gnu/store/5s2nib1lrd2101bbrivcl17kjx1mspw6-coreutils-8.30/lib/ghc-8.4.3: No 
such file or directory
find-files: 
/gnu/store/7j3941iannrngdvgbclyxid12vds5w9i-make-4.2.1/lib/ghc-8.4.3: No such 
file or directory
find-files: 
/gnu/store/q19l04vd2za80mk1845pz7r8cz29qk43-bash-minimal-4.4.23/lib/ghc-8.4.3: 
No such file or directory
find-files: 

failing git-annex build

[Kyle Meyer]

Hello,

I'm seeing the failure below when trying to build git-annex.  Can anyone
else reproduce this failure?  Any ideas how to resolve it?

--8<---cut here---start->8---
% git describe
v0.16.0-400-g4f36d98f7b

% ./pre-inst-env guix build -K --check git-annex
Utility/Exception.hs:29:1: error:
Bad interface file: 
/gnu/store/qb3knv1h536sdjqc4nfkm3j1l8n7q87a-ghc-exceptions-0.10.0/lib/ghc-8.4.3/exceptions-0.10.0/Control/Monad/Catch.dyn_hi
Something is amiss; requested module  
exceptions-0.10.0:Control.Monad.Catch differs from name found in the interface 
file exceptions-0.10.0:Control.Monad.Catch (if these names look the same, try 
again with -dppr-debug)
   |
29 | import Control.Monad.Catch as X hiding (Handler)
   | 
Backtrace:
   5 (primitive-load "/gnu/store/xayhspk534wq4fyralxivfnl3vx…")
In ice-9/eval.scm:
   191:35  4 (_ _)
In srfi/srfi-1.scm:
   863:16  3 (every1 # …)
In 
/gnu/store/79jn1m4ax1zr5hlf3q7aalnb4vhx17ac-module-import/guix/build/gnu-build-system.scm:
   799:28  2 (_ _)
In ice-9/eval.scm:
619:8  1 (_ #(#(#) (#:inputs # …)))
In 
/gnu/store/79jn1m4ax1zr5hlf3q7aalnb4vhx17ac-module-import/guix/build/utils.scm:
616:6  0 (invoke _ . _)

/gnu/store/79jn1m4ax1zr5hlf3q7aalnb4vhx17ac-module-import/guix/build/utils.scm:616:6:
 In procedure invoke:
Throw to key `srfi-34' with args `(#)'.
note: keeping build directory `/tmp/guix-build-git-annex-6.20180926.drv-1'
builder for 
`/gnu/store/yf5bkdya8krhdc29n518gbhvwkbn2ax4-git-annex-6.20180926.drv' failed 
with exit code 1
build of /gnu/store/yf5bkdya8krhdc29n518gbhvwkbn2ax4-git-annex-6.20180926.drv 
failed
View build log at 
'/var/log/guix/drvs/yf/5bkdya8krhdc29n518gbhvwkbn2ax4-git-annex-6.20180926.drv.bz2'.
guix build: error: build failed: build of 
`/gnu/store/yf5bkdya8krhdc29n518gbhvwkbn2ax4-git-annex-6.20180926.drv' failed
--8<---cut here---end--->8---

Re: Magit is painfully slow

[Kyle Meyer]

Brett Gilio  writes:

> Kyle Meyer writes:
>
>> Ricardo Wurmus  writes:

[...]

>>> That’s because it’s trying to colorize the diff of thousands of lines of
>>> .po and .texi changes.
>>
>> With the default settings and no cached visibility for the repo, the
>> hunks should not be expanded, so Magit isn't actually coloring/painting
>> them yet.  In this case, the processing of these diffs will be slow
>> regardless of whether they are painted and the CLI "git checkout"
>> suggestion is good, but I think the delayed painting is worth noting
>> because users may not realize that their custom visibility settings are
>> making things slower.

[...]

> Kyle,
> What do you suggest here?

Sorry for not being clear.  I agree with Ricardo's suggestion and wasn't
offering another one.  I was pointing out that, with the default
configuration, the lag is due to diff processing *other than colorizing*
because Magit delays painting hidden diffs.  Based on how the user
configures section visibility (e.g., via
magit-section-initial-visibility-alist and
magit-section-cache-visibility), the diffs may not be hidden, leading to
additional time spent painting the diffs.

Re: Magit is painfully slow

[Kyle Meyer]

Hello,

Ricardo Wurmus  writes:

[...]

> However, after compiling and generating several .po and .texi
>> files Magit takes almost a whole minute to open.
>
> That’s because it’s trying to colorize the diff of thousands of lines of
> .po and .texi changes.

With the default settings and no cached visibility for the repo, the
hunks should not be expanded, so Magit isn't actually coloring/painting
them yet.  In this case, the processing of these diffs will be slow
regardless of whether they are painted and the CLI "git checkout"
suggestion is good, but I think the delayed painting is worth noting
because users may not realize that their custom visibility settings are
making things slower.

-- 
Kyle

Re: 03/04: gnu: Add git-when-merged.

[Kyle Meyer]

Mark H Weaver  writes:

>> * gnu/packages/version-control.scm (git-when-merged): New variable.

[...]

> The license field of this package is incorrect.  It has this:
>
>   (license license:gpl2)
>
> which is understandable given that GitHub shows the license as "GPL-2.0"
> on the main project page <https://github.com/mhagger/git-when-merged>.
> However, if you look at the actual code, there's only one source file
> and it has a proper GNU GPLv2+ copyright notice at the top.

Sorry about that, and thanks for spotting my mistake.  I'm happy to send
a patch to guix-patches, but I imagine it is easier for someone with
push access to correct it.

-- 
Kyle

Re: git-annex: problematic shebangs in .git/hooks/pre-commit?

[Kyle Meyer]

Timothy Sample  writes:

[...]

>> I'm wondering whether the shebang patching in .git/hooks/pre-commit will
>> cause a problem.  Using the patched shellPath_portable, 'git annex init'
>> generates a hook like this:
>>
>> % cat .git/hooks/pre-commit
>> #!/gnu/store/rbrandv7anzjxqkr40d7fkanzssslk4b-bash-minimal-4.4.19/bin/sh
>> # automatically configured by git-annex
>> git annex pre-commit .
>>
>> But won't this break if that particular bash-mininimal is garbage collected?
>
> My understanding is that since git-annex contains a reference to
> bash-minimal, the garbage collector will leave it alone.  Indeed,
> running “guix gc --references /gnu/store/…-git-annex-20180626” shows
> that Guix knows that git-annex needs bash-minimal.  As long as git-annex
> is available (a prerequisite to the pre-commit hook working)
> bash-minimal will be available.

Hmm, I'm not convinced that *that* bash-minimal will be available.

Perhaps I'm just missing something, but to spell out my concern a little
more: I have /gnu/store/A/git-annex and /gnu/store/X/bash-minimal.  I
set up a repo with 'git annex init', and
/gnu/store/X/bash-minimal/bin/sh is used in the shebang.

Some time later I am using /gnu/store/B/git-annex, which references
/gnu/store/Y/bash-minimal.  That repo's hook still uses the
X/bash-minimal/bin/sh.  But if /gnu/store/X/bash-minimal is no longer
referenced by any package, it could be garbage collected, leading to the
hook failing.

git-annex: problematic shebangs in .git/hooks/pre-commit?

[Kyle Meyer]

Hello,

Thanks for packaging git-annex, Tim!  I'm excited to see it in Guix.

I'm wondering whether the shebang patching in .git/hooks/pre-commit will
cause a problem.  Using the patched shellPath_portable, 'git annex init'
generates a hook like this:

% cat .git/hooks/pre-commit
#!/gnu/store/rbrandv7anzjxqkr40d7fkanzssslk4b-bash-minimal-4.4.19/bin/sh
# automatically configured by git-annex
git annex pre-commit .

But won't this break if that particular bash-mininimal is garbage collected?

Re: Should guix-emacs-autoload-packages use GUIX_ENVIRONMENT?

[Kyle Meyer]

Alex Kost <alez...@gmail.com> writes:

> OK, so if the others agree with "along with" policy, would you like to
> update your patch for it?

Sure, sent to guix-patches (#27845).

-- 
Kyle

Re: Should guix-emacs-autoload-packages use GUIX_ENVIRONMENT?

[Kyle Meyer]

Marius Bakke <mba...@fastmail.com> writes:

> Wait, isn't this what --pure is for?  I haven't followed the
> discussion, but I would expect `guix environment` to *add* to my
> current profile, and use '--pure' if I want a "clean" environment.

I think the behavior here is unspecified because --pure is about
unsetting shell variables while this is about how the load-path and
autoloads are set up within an environment's Emacs instance.
Conceptually, though, I agree that a --pure flag would match
guix-emacs-autoload-packages considering only the environment's Emacs
packages, whereas no --pure flag would match adding the environment's to
the current profile's.

But in the discussion so far, I've been assuming that currently there's
not a direct way for guix-emacs-autoload-packages to detect if --pure
was given.  If that's not true, I'd be happy with the behavior you
propose.

-- 
Kyle

Re: Should guix-emacs-autoload-packages use GUIX_ENVIRONMENT?

[Kyle Meyer]

Alex Kost <alez...@gmail.com> writes:

> Kyle Meyer (2017-07-22 21:39 -0400) wrote:
>
>> I noticed that Emacs packages from the user's profile leak into guix
>> environment calls.
>
> As for me, this is a natural behaviour.  If you want to be safe from any
> external packages, site settings, etc., run "emacs -Q".

I want "-q" rather than "-Q" because I want the Emacs instance to
autoload the Emacs packages that I've given as arguments to "guix
environment".

> I'm not sure.  I think if you run "emacs -q", you really want "emacs -Q".
> Otherwise, if you start emacs normally, you probably don't want to ignore
> emacs packages from your guix profile.

Maybe I'm underestimating all the ways people use "guix environment".
When I use it, I'm interested in getting an isolated environment,
usually for testing, and in this case I don't want the Emacs packages
from my profile.

But sure, I can use "emacs -Q" and then evaluate something similar to
what Guix puts in site-start.el, modifying it to only look at
GUIX_ENVIRONMENT.

> However, I agree that GUIX_ENVIRONMENT should be honored, but as I wrote
> *not instead* but *along with* the default profiles.  So if you start
> emacs like this:
>
>   guix environment --ad-hoc emacs emacs-wget -- emacs
>
> it should contain emacs-wget in its load-path.  WDYT?

I certainly agree with that load-path should include emacs-wget.  I'm
just not sure I agree with the "along with".

Anyway, as I said above, it's easy enough to get the behavior I want
with "emacs -Q" and a custom guix-emacs-autoload-packages call.

Thanks for your thoughts.

-- 
Kyle

Should guix-emacs-autoload-packages use GUIX_ENVIRONMENT?

[Kyle Meyer]

Hello,

I noticed that Emacs packages from the user's profile leak into guix
environment calls.

For example, when I run

$ guix environment --pure --ad-hoc emacs -- emacs -q

load-path contains the Emacs packages from my main profile.

I expected it to use GUIX_ENVIRONMENT instead (something like the patch
below, I think).

Does guix-emacs-autoload-packages ignore GUIX_ENVIRONMENT by design?  I
suppose one downside of honoring GUIX_ENVIRONMENT is that, if the --pure
flag isn't passed and the package arguments aren't Emacs-related, a user
may be surprised that their Emacs packages are no longer available in
newly created Emacs instances.

Thanks.

-- >8 --
diff --git a/gnu/packages/aux-files/emacs/guix-emacs.el 
b/gnu/packages/aux-files/emacs/guix-emacs.el
index 2bbd639ff..2d0d50e11 100644
--- a/gnu/packages/aux-files/emacs/guix-emacs.el
+++ b/gnu/packages/aux-files/emacs/guix-emacs.el
@@ -87,9 +87,11 @@ (defun guix-emacs-autoload-packages ( profiles)
   (interactive (list (if (fboundp 'guix-read-package-profile)
  (funcall 'guix-read-package-profile)
guix-user-profile)))
-  (let ((profiles (or profiles
-  (list "/run/current-system/profile"
-guix-user-profile
+  (let* ((env  (getenv "GUIX_ENVIRONMENT"))
+ (profiles (or profiles
+   (and env (list env))
+   (list "/run/current-system/profile"
+ guix-user-profile
 (dolist (profile profiles)
   (let ((dirs (guix-emacs-directories profile)))
 (when dirs
-- 
2.13.3

Re: R

[Kyle Meyer]

Ricardo Wurmus <ricardo.wur...@mdc-berlin.de> writes:

[...]

> I can also confirm that dropping openblas from the R build “fixes” the
> segfault when running
>
> x <- eigen(crossprod(matrix(rnorm(50 * 500), 50, 500)))
>
> as reported here: https://github.com/xianyi/OpenBLAS/issues/703
>
> So, I think it’s a good idea to build R without OpenBLAS on all
> architectures for now.

Thank you, Ricardo.  I'm sorry I wasn't able make any progress on
figuring out what the underlying issue was there.

-- 
Kyle

[PATCH v2] gnu: Add python-docopt.

[Kyle Meyer]

* gnu/packages/python.scm (python-docopt, python2-docopt): New
  variables.
---
 gnu/packages/python.scm | 36 
 1 file changed, 36 insertions(+)

diff --git a/gnu/packages/python.scm b/gnu/packages/python.scm
index 3385393..273486b 100644
--- a/gnu/packages/python.scm
+++ b/gnu/packages/python.scm
@@ -14,6 +14,7 @@
 ;;; Copyright © 2015 Ben Woodcroft <donttrust...@gmail.com>
 ;;; Copyright © 2015 Erik Edrosa <erik.edr...@gmail.com>
 ;;; Copyright © 2015 Efraim Flashner <efr...@flashner.co.il>
+;;; Copyright © 2015 Kyle Meyer <k...@kyleam.com>
 ;;;
 ;;; This file is part of GNU Guix.
 ;;;
@@ -6006,3 +6007,38 @@ automatically detect a wide range of file encodings.")
 
 (define-public python2-chardet
   (package-with-python2 python-chardet))
+
+(define-public python-docopt
+  (package
+(name "python-docopt")
+(version "0.6.2")
+(source
+ (origin
+   (method url-fetch)
+   ;; The release on PyPI does not include tests.
+   (uri (string-append
+ "https://github.com/docopt/docopt/archive/;
+ version ".tar.gz"))
+   (file-name (string-append name "-" version ".tar.gz"))
+   (sha256
+(base32
+ "16bf890xbdz3m30rsv2qacklh2rdn1zrfspfnwzx9g7vwz8yw4r1"
+(build-system python-build-system)
+(native-inputs
+ `(("python-pytest" ,python-pytest)
+   ("python-setuptools" ,python-setuptools)))
+(arguments
+ `(#:phases (alist-replace
+ 'check
+ (lambda _ (zero? (system* "py.test")))
+ %standard-phases)))
+(home-page "http://docopt.org;)
+(synopsis "Command-line interface description language for Python")
+(description "This library allows the user to define a command-line
+interface from a program's help message rather than specifying it
+programatically with command-line parsers like @code{getopt} and
+@code{argparse}.")
+(license license:expat)))
+
+(define-public python2-docopt
+  (package-with-python2 python-docopt))
-- 
2.6.3

Re: [PATCH] gnu: Add docopt.

[Kyle Meyer]

Leo Famulari <l...@famulari.name> writes:

> On Thu, Dec 03, 2015 at 01:24:09AM -0500, Kyle Meyer wrote:
>> * gnu/packages/python.scm (python-docopt, python2-docopt): New
>>   variables.
>
> Have you tested the software provided by this patch to make sure it
> works? I'm not sure how to test it since it's just a library.

Yes, I've been using the py3 version locally for a while and haven't
noticed any issues.  I didn't test the py2 version.

>> +(arguments '(#:tests? #f))   ; Tests are not included in the PyPI 
>> release.
>
> Are there tests in any other releases? If not, I would change the
> comment to "No test suite", just to make it more clear. If yes, we
> should probably package that release while asking upstream to include
> the tests in the PyPi release.

There's a test file in the GitHub repo.  I'll open a PR adding it to the
source distribution and change the package definition to use the GitHub
source for now.

Thanks for the feedback.  I'll send an update.

[I also just realized that I put docopt rather than python-docopt in the
commit subject.]

--
Kyle

[PATCH] gnu: Add docopt.

[Kyle Meyer]

* gnu/packages/python.scm (python-docopt, python2-docopt): New
  variables.
---
 gnu/packages/python.scm | 26 ++
 1 file changed, 26 insertions(+)

diff --git a/gnu/packages/python.scm b/gnu/packages/python.scm
index 45222e9..5b31ae8 100644
--- a/gnu/packages/python.scm
+++ b/gnu/packages/python.scm
@@ -5994,3 +5994,29 @@ automatically detect a wide range of file encodings.")
 
 (define-public python2-chardet
   (package-with-python2 python-chardet))
+
+(define-public python-docopt
+  (package
+(name "python-docopt")
+(version "0.6.2")
+(source
+ (origin
+   (method url-fetch)
+   (uri (pypi-uri "docopt" version))
+   (sha256
+(base32
+ "14f4hn6d1j4b99svwbaji8n2zj58qicyz19mm0x6pmhb50jsics9"
+(build-system python-build-system)
+(inputs
+ `(("python-setuptools" ,python-setuptools)))
+(arguments '(#:tests? #f))   ; Tests are not included in the PyPI release.
+(home-page "http://docopt.org;)
+(synopsis "Command-line interface description language for Python")
+(description "This library allows the user to define a command-line
+interface from a program's help message rather than specifying it
+programatically with command-line parsers like @code{getopt} and
+@code{argparse}.")
+(license license:expat)))
+
+(define-public python2-docopt
+  (package-with-python2 python-docopt))
-- 
2.6.2

Re: [PATCH] gnu: Add myrepos.

[Kyle Meyer]

Ricardo Wurmus <ricardo.wur...@mdc-berlin.de> writes:

[...]

> You should add a ‘(file-name ...)’ expression here, because the tarball
> does not include the name of the package:
>
>(file-name (string-append name "-" version ".tar.gz"))

OK.

>> +   #:make-flags (list (string-append "DESTDIR=" (assoc-ref %outputs 
>> "out"))
>> +  "PREFIX=")))
>
> Is it really correct to set DESTDIR and unset PREFIX?  I thought setting
> PREFIX would be sufficient.

Right, setting PREFIX works fine.  Myrepo's Makefile forms the path as
"${DESTDIR}${PREFIX}", so the end result should be the same.  I'm not
sure why I decided setting DESTDIR would be better.

Sending an updated patch.  Thanks for the comments.

--
Kyle

[PATCH v2] gnu: Add myrepos.

[Kyle Meyer]

* gnu/packages/version-control.scm (myrepos): New variable.
---
 gnu/packages/version-control.scm | 30 ++
 1 file changed, 30 insertions(+)

diff --git a/gnu/packages/version-control.scm b/gnu/packages/version-control.scm
index b132663..548fb7f 100644
--- a/gnu/packages/version-control.scm
+++ b/gnu/packages/version-control.scm
@@ -7,6 +7,7 @@
 ;;; Copyright © 2014, 2015 Mark H Weaver <m...@netris.org>
 ;;; Copyright © 2014 Eric Bavier <bav...@member.fsf.org>
 ;;; Copyright © 2015 Efraim Flashner <efr...@flashner.co.il>
+;;; Copyright © 2015 Kyle Meyer <k...@kyleam.com>
 ;;;
 ;;; This file is part of GNU Guix.
 ;;;
@@ -925,3 +926,32 @@ any project with more than one developer, is one of 
Aegis's major functions.")
 a history browser.  It can also stage hunks for commit, or colorize the
 output of the 'git' command.")
 (license gpl2+)))
+
+(define-public myrepos
+  (package
+(name "myrepos")
+(version "1.20151022")
+(source
+ (origin
+   (method url-fetch)
+   (uri (string-append
+ "https://github.com/joeyh/myrepos/archive/;
+ version ".tar.gz"))
+   (file-name (string-append name "-" version ".tar.gz"))
+   (sha256
+(base32 "0c93lqsngpsxsca7nygk4qhidr40ijgih86q81x1mfcwbs0gbds8"
+(build-system gnu-build-system)
+(inputs
+ `(("perl" ,perl)))
+(arguments
+ `(#:test-target "test"
+   #:phases (alist-delete 'configure %standard-phases)
+   #:make-flags (list (string-append "PREFIX=" %output
+(home-page "http://myrepos.branchable.com/;)
+(synopsis "Multiple repository management tool")
+(description
+ "Myrepos provides the @code{mr} command, which maps an operation (e.g.,
+fetching updates) over a collection of version control repositories.  It
+supports a large number of version control systems: git, svn, mercurial, bzr,
+darcs, cvs, fossil and veracity.")
+(license gpl2+)))
-- 
2.6.2

[PATCH] gnu: Add myrepos.

[Kyle Meyer]

* gnu/packages/version-control.scm (myrepos): New variable.
---
 gnu/packages/version-control.scm | 30 ++
 1 file changed, 30 insertions(+)

diff --git a/gnu/packages/version-control.scm b/gnu/packages/version-control.scm
index b132663..d7c4f8c 100644
--- a/gnu/packages/version-control.scm
+++ b/gnu/packages/version-control.scm
@@ -7,6 +7,7 @@
 ;;; Copyright © 2014, 2015 Mark H Weaver <m...@netris.org>
 ;;; Copyright © 2014 Eric Bavier <bav...@member.fsf.org>
 ;;; Copyright © 2015 Efraim Flashner <efr...@flashner.co.il>
+;;; Copyright © 2015 Kyle Meyer <k...@kyleam.com>
 ;;;
 ;;; This file is part of GNU Guix.
 ;;;
@@ -925,3 +926,32 @@ any project with more than one developer, is one of 
Aegis's major functions.")
 a history browser.  It can also stage hunks for commit, or colorize the
 output of the 'git' command.")
 (license gpl2+)))
+
+(define-public myrepos
+  (package
+(name "myrepos")
+(version "1.20151022")
+(source
+ (origin
+   (method url-fetch)
+   (uri (string-append
+ "https://github.com/joeyh/myrepos/archive/;
+ version ".tar.gz"))
+   (sha256
+(base32 "0c93lqsngpsxsca7nygk4qhidr40ijgih86q81x1mfcwbs0gbds8"
+(build-system gnu-build-system)
+(inputs
+ `(("perl" ,perl)))
+(arguments
+ `(#:test-target "test"
+   #:phases (alist-delete 'configure %standard-phases)
+   #:make-flags (list (string-append "DESTDIR=" (assoc-ref %outputs "out"))
+  "PREFIX=")))
+(home-page "http://myrepos.branchable.com/;)
+(synopsis "Multiple repository management tool")
+(description
+ "Myrepos provides the @code{mr} command, which maps an operation (e.g.,
+fetching updates) over a collection of version control repositories.  It
+supports a large number of version control systems: git, svn, mercurial, bzr,
+darcs, cvs, fossil and veracity.")
+(license gpl2+)))
-- 
2.6.2

Re: [PATCH]: Five R packages.

[Kyle Meyer]

Ricardo Wurmus <ricardo.wur...@mdc-berlin.de> writes:

> Kyle Meyer <k...@kyleam.com> writes:
>
>> In any case, I don't see these prompts as much of an issue because I'd
>> prefer to just use Guix for all R packages.  Why not manage bioconductor
>> packages with Guix as well?
>
> I’m working on it already.  Currently, we cannot easily import
> bioconductor packages, but I’m planning to rewrite the CRAN importer
> such that it works on the DESCRIPTION file in the tarball rather than
> the CRAN HTML page.  Once that’s done I’ll try to package much of
> bioconductor 3.2 for Guix.

That's great.  Thank you!

--
Kyle

Re: [PATCH]: Five R packages.

[Kyle Meyer]

Ricardo Wurmus <ricardo.wur...@mdc-berlin.de> writes:

>> Isn't lattice already included with the main R build as a recommended
>> package?
>
> You’re right again.
>
> Is there ever a reason to upgrade the included recommended packages?  I
> know that when installing some bioconductor packages R asks whether to
> upgrade some included packages, such as MASS.  I’m not sure if it makes
> sense to offer separate packages for the latest versions of these
> modules.
>
> What do you think?  I’m not much of an R-user myself.

Hmm... I also don't spend much time in R.  I'd guess that the
recommended packages are quite stable, so the only advantage I see of
running a version of a package newer than the one included with R is
that you get rid of the prompt when using install.packages or
bioconductor.  I've always answered no to these prompts and haven't
noticed any issues (but my use of R is fairly limited, so that may not
be worth much).

In any case, I don't see these prompts as much of an issue because I'd
prefer to just use Guix for all R packages.  Why not manage bioconductor
packages with Guix as well?

-- 
Kyle

Re: [PATCH]: Five R packages.

[Kyle Meyer]

Hello,

Ricardo Wurmus <ricardo.wur...@mdc-berlin.de> writes:

> From 9b319907000ad6b1796d1887cabcf010aa806d3e Mon Sep 17 00:00:00 2001
> From: Ricardo Wurmus <ricardo.wur...@mdc-berlin.de>
> Date: Thu, 26 Nov 2015 16:59:08 +0100
> Subject: [PATCH 1/5] gnu: Add r-data-table.
>
> * gnu/packages/statistics.scm (r-data-table): New variable.

It seems data.table was already packaged under a different name in
0e4e03f (2015-09-26).

> From 0e6557d12cba8e25aad9789b3fb4c454ce16c244 Mon Sep 17 00:00:00 2001
> From: Ricardo Wurmus <ricardo.wur...@mdc-berlin.de>
> Date: Thu, 26 Nov 2015 17:00:26 +0100
> Subject: [PATCH 5/5] gnu: Add r-lattice.
>
> * gnu/packages/statistics.scm (r-lattice): New variable.

Isn't lattice already included with the main R build as a recommended
package?

-- 
Kyle