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: 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: 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 .
> 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  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  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  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  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  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  writes:

> From 9b319907000ad6b1796d1887cabcf010aa806d3e Mon Sep 17 00:00:00 2001
> From: Ricardo Wurmus 
> 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 
> 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