Given a file, find the package that builds it

2018-03-29 Thread Chris Marusich
Pierre Neidhardt  writes:

>>> A more general question: How do I find to which non-installed package a
>>> filename belongs?
>>
>> Guix does not currently know anything about the files inside each
>> package, I typically do a web search...
>
> This is too bad, I believe it's an important feature for any package
> manager.
> As far as I can tell, `portage` and `pacman` can both do it.
>
> Any plan regarding guix?

I don't know of any plan at the moment.  Nothing is stopping a motivated
individual from creating a mapping of packages to programs, of course,
and then making it available to anyone who is interested.

Here's one idea: what if somebody defined a package which used every
other package as input, scanned their output paths and created such a
mapping, and then wrote that mapping (or built a tool to easily query
that mapping) as its own output?  You could call it the "xiug" package!
;-)

Until a solution is created, I find that the following heuristic usually
works (where $program is the name of the program I'm interested in):

* Try: guix package --search=$program
* Search the Internet for $program, and find out what package provides
  the $program on existing distributions.  Then try "guix package
  --search=$package" where $package is the package name used in the
  other distro.  The name is often the same or similar.
* Brute force search your local store for the build output:
find -L /gnu/store -iname "*${program}*"
* Ask on IRC or email!

-- 
Chris


signature.asc
Description: PGP signature


Re: Package requests: Udisks helpers (udiskie, udevil)

2018-03-29 Thread Pierre Neidhardt

Chris Marusich  writes:

>> I don't use Nautilus
>
> What do you use?  If you are using another desktop environment besides
> GNOME, and automatic mounting of removable storage devices does not
> occur, perhaps it's a bug we need to fix.  (And maybe that bug is as
> simple as adding the packages you mentioned.)

I don't use a desktop environment.  More specifically, I use EXWM (Emacs
W Window Manager): https://github.com/ch11ng/exwm.

-- 
Pierre Neidhardt


signature.asc
Description: PGP signature


Re: Package requests: Udisks helpers (udiskie, udevil)

2018-03-29 Thread Chris Marusich
Pierre Neidhardt  writes:

> I don't use Nautilus

What do you use?  If you are using another desktop environment besides
GNOME, and automatic mounting of removable storage devices does not
occur, perhaps it's a bug we need to fix.  (And maybe that bug is as
simple as adding the packages you mentioned.)

> Some udev rules might be enough though.

That could very well be true!  I don't know a lot about how the various
desktop environments like GNOME auto-mount removable storage devices,
but I'd be surprised if you couldn't whip something up with udev rules.

-- 
Chris


signature.asc
Description: PGP signature


Re: Locale error: Falling back to C locale

2018-03-29 Thread Pierre Neidhardt

Ricardo Wurmus  writes:

> Pierre Neidhardt  writes:
>
>> Glibc was not installed, but installing it pulls 3 packages:
>>
>>  > guix build glibc
>>  
>> /gnu/store/2kjscn5i1zjq2h3j0dcwfnzmc69lajz1-glibc-2.26.105-g0890d5379c-debug
>>  /gnu/store/9j55362h2xgndjgy45f6283spjjx5990-glibc-2.26.105-g0890d5379c
>>  
>> /gnu/store/zpy7n3jjlgnq55lhzkdixf3dvk25vhlj-glibc-2.26.105-g0890d5379c-static
>>
>> Interestingly, `bin/locale` does not end up in the user PATH.
>
> That’s expected.  “guix build” doesn’t install anything and so the
> executables of built packages don’t automatically end up in PATH.
> That’s by design.

Duh!  That was so obvious, I completely forgot I wasn't "installing" :p

The problem is gone for Emacs (hurray!) but not for stow.

What does it mean?  That glibc _must_ be installed on all user profiles?

-- 
Pierre Neidhardt


signature.asc
Description: PGP signature


Re: Locale error: Falling back to C locale

2018-03-29 Thread Ricardo Wurmus

Pierre Neidhardt  writes:

> Glibc was not installed, but installing it pulls 3 packages:
>
>   > guix build glibc
>   
> /gnu/store/2kjscn5i1zjq2h3j0dcwfnzmc69lajz1-glibc-2.26.105-g0890d5379c-debug
>   /gnu/store/9j55362h2xgndjgy45f6283spjjx5990-glibc-2.26.105-g0890d5379c
>   
> /gnu/store/zpy7n3jjlgnq55lhzkdixf3dvk25vhlj-glibc-2.26.105-g0890d5379c-static
>
> Interestingly, `bin/locale` does not end up in the user PATH.

That’s expected.  “guix build” doesn’t install anything and so the
executables of built packages don’t automatically end up in PATH.
That’s by design.

--
Ricardo

GPG: BCA6 89B6 3655 3801 C3C6  2150 197A 5888 235F ACAC
https://elephly.net





Re: Locale error: Falling back to C locale

2018-03-29 Thread Pierre Neidhardt

Marius Bakke  writes:

> Pierre Neidhardt  writes:
>
>> Marius Bakke  writes:
>>
>>> Can you post the output of these commands in a terminal:
>>>
>>> $ locale
>>
>> locale: command not found
>
> Try: "$(guix build glibc)/bin/locale" instead.

Glibc was not installed, but installing it pulls 3 packages:

> guix build glibc

/gnu/store/2kjscn5i1zjq2h3j0dcwfnzmc69lajz1-glibc-2.26.105-g0890d5379c-debug
/gnu/store/9j55362h2xgndjgy45f6283spjjx5990-glibc-2.26.105-g0890d5379c

/gnu/store/zpy7n3jjlgnq55lhzkdixf3dvk25vhlj-glibc-2.26.105-g0890d5379c-static

Interestingly, `bin/locale` does not end up in the user PATH.

> 
/gnu/store/9j55362h2xgndjgy45f6283spjjx5990-glibc-2.26.105-g0890d5379c/bin/locale
 
LANG=en_US.utf8
LC_CTYPE="en_US.utf8"
LC_NUMERIC="en_US.utf8"
LC_TIME="en_US.utf8"
LC_COLLATE="en_US.utf8"
LC_MONETARY="en_US.utf8"
LC_MESSAGES="en_US.utf8"
LC_PAPER="en_US.utf8"
LC_NAME="en_US.utf8"
LC_ADDRESS="en_US.utf8"
LC_TELEPHONE="en_US.utf8"
LC_MEASUREMENT="en_US.utf8"
LC_IDENTIFICATION="en_US.utf8"
LC_ALL=

> And then `ls -l /run/current-system/locale/2.26/`.

> ls -l /run/current-system/locale/2.26/
total 136
dr-xr-xr-x   3 root   root 4096 1970-01-01  1970 ca_ES.utf8
dr-xr-xr-x   3 root   root 4096 1970-01-01  1970 cs_CZ.utf8
dr-xr-xr-x   3 root   root 4096 1970-01-01  1970 da_DK.utf8
dr-xr-xr-x   3 root   root 4096 1970-01-01  1970 de_DE.utf8
dr-xr-xr-x   3 root   root 4096 1970-01-01  1970 el_GR.utf8
dr-xr-xr-x   3 root   root 4096 1970-01-01  1970 en_AU.utf8
dr-xr-xr-x   3 root   root 4096 1970-01-01  1970 en_CA.utf8
dr-xr-xr-x   3 root   root 4096 1970-01-01  1970 en_GB.utf8
dr-xr-xr-x   3 root   root 4096 1970-01-01  1970 en_US.UTF-8
dr-xr-xr-x   3 root   root 4096 1970-01-01  1970 en_US.utf8
dr-xr-xr-x   3 root   root 4096 1970-01-01  1970 es_AR.utf8
dr-xr-xr-x   3 root   root 4096 1970-01-01  1970 es_CL.utf8
dr-xr-xr-x   3 root   root 4096 1970-01-01  1970 es_ES.utf8
dr-xr-xr-x   3 root   root 4096 1970-01-01  1970 es_MX.utf8
dr-xr-xr-x   3 root   root 4096 1970-01-01  1970 fi_FI.utf8
dr-xr-xr-x   3 root   root 4096 1970-01-01  1970 fr_BE.utf8
dr-xr-xr-x   3 root   root 4096 1970-01-01  1970 fr_CA.utf8
dr-xr-xr-x   3 root   root 4096 1970-01-01  1970 fr_CH.utf8
dr-xr-xr-x   3 root   root 4096 1970-01-01  1970 fr_FR.utf8
dr-xr-xr-x   3 root   root 4096 1970-01-01  1970 ga_IE.utf8
dr-xr-xr-x   3 root   root 4096 1970-01-01  1970 it_IT.utf8
dr-xr-xr-x   3 root   root 4096 1970-01-01  1970 ja_JP.utf8
dr-xr-xr-x   3 root   root 4096 1970-01-01  1970 ko_KR.utf8
dr-xr-xr-x   3 root   root 4096 1970-01-01  1970 nb_NO.utf8
dr-xr-xr-x   3 root   root 4096 1970-01-01  1970 nl_NL.utf8
dr-xr-xr-x   3 root   root 4096 1970-01-01  1970 pl_PL.utf8
dr-xr-xr-x   3 root   root 4096 1970-01-01  1970 pt_PT.utf8
dr-xr-xr-x   3 root   root 4096 1970-01-01  1970 ro_RO.utf8
dr-xr-xr-x   3 root   root 4096 1970-01-01  1970 ru_RU.utf8
dr-xr-xr-x   3 root   root 4096 1970-01-01  1970 sv_SE.utf8
dr-xr-xr-x   3 root   root 4096 1970-01-01  1970 tr_TR.utf8
dr-xr-xr-x   3 root   root 4096 1970-01-01  1970 uk_UA.utf8
dr-xr-xr-x   3 root   root 4096 1970-01-01  1970 vi_VN.utf8
dr-xr-xr-x   3 root   root 4096 1970-01-01  1970 zh_CN.utf8

-- 
Pierre Neidhardt


signature.asc
Description: PGP signature


Re: Locale error: Falling back to C locale

2018-03-29 Thread Marius Bakke
Pierre Neidhardt  writes:

> Marius Bakke  writes:
>
>> Can you post the output of these commands in a terminal:
>>
>> $ locale
>
> locale: command not found

Try: "$(guix build glibc)/bin/locale" instead.

And then `ls -l /run/current-system/locale/2.26/`.


signature.asc
Description: PGP signature


Re: Locale error: Falling back to C locale

2018-03-29 Thread Pierre Neidhardt

Marius Bakke  writes:

> Can you post the output of these commands in a terminal:
>
> $ locale

locale: command not found

> $ env | grep LOCPATH

GUIX_LOCPATH=/run/current-system/locale


> $ ls -l /run/current-system/locale/

total 4
dr-xr-xr-x  36 root   root 4096 1970-01-01  1970 2.26

-- 
Pierre Neidhardt


signature.asc
Description: PGP signature


Re: Locale error: Falling back to C locale

2018-03-29 Thread Marius Bakke
Pierre Neidhardt  writes:

> Marius Bakke  writes:
>
>> Pierre Neidhardt  writes:
>>
 guix package -I local
>>> glibc-utf8-locales  2.26.105-g0890d5379cout 
>>> /gnu/store/3k6hl20c3b7big8ngrsl6mj9k8xav99d-glibc-utf8-locales-2.26.105-g0890d5379c
>>>
 guix package -I emacs
>>> emacs   25.3out 
>>> /gnu/store/y335nx4r08m6kg0yrna7spfwr4s05n36-emacs-25.3
>>>
>>> How do I check which glibc Emacs is using?
>>> I can think of `ldd emacs` but... Where is ldd? :p
>>
>> "ldd" is in "glibc" :-)
>>
>> You can also use `guix gc -R /gnu/store/...-emacs-25.3 | grep glibc`.
>
> Here:
>
>   > guix gc -R ${guix build emacs} | grep glibc
>   /gnu/store/4sqaib7c2dfjv62ivrg9b8wa7bh226la-glibc-2.26.105-g0890d5379c

This looks good.  Let's rewind for a bit.  The original error message
was:


> stow .
perl: warning: Setting locale failed.
perl: warning: Please check that your locale settings:
LANGUAGE = (unset),
LC_ALL = (unset),
LANG = "en_US.utf8"
are supported and installed on your system.
perl: warning: Falling back to the standard locale ("C").

> emacs
(process:7796): Gtk-WARNING **: Locale not supported by C library.
Using the fallback 'C' locale.

Can you post the output of these commands in a terminal:

$ locale
$ env | grep LOCPATH
$ ls -l /run/current-system/locale/


signature.asc
Description: PGP signature


Re: Test fail

2018-03-29 Thread Maria Sidorova



On 29.03.2018 15:51, Gábor Boskovits wrote:
2018-03-29 14:46 GMT+02:00 Maria Sidorova >:




On 29.03.2018 09:17, Gábor Boskovits wrote:

2018-03-28 15:51 GMT+02:00 Gábor Boskovits  >>:

     2018-03-28 8:36 GMT+02:00 Maria Sidorova

     >>:



         On 28.03.2018 09:33, Gábor Boskovits wrote:

             2018-03-27 23:34 GMT+02:00 Maria Sidorova
             
>
              
     >
     in our bug tracker that might be affecting you, or the
shared mounts
     I noticed much later. I'm going to investigate this and
report back.


I've created a vm image with a current Ubuntu 16.04 yesterday,
installed
the guix 

Re: Test fail

2018-03-29 Thread Maria Sidorova



On 29.03.2018 09:17, Gábor Boskovits wrote:
2018-03-28 15:51 GMT+02:00 Gábor Boskovits >:


2018-03-28 8:36 GMT+02:00 Maria Sidorova >:



On 28.03.2018 09:33, Gábor Boskovits wrote:

2018-03-27 23:34 GMT+02:00 Maria Sidorova

>>:


     Hello,

     Running the test suite (`make check`) gives me one of
the tests failed.

     This is from test-suite.log

     test-name: pivot-root
     location: /home/masha/src/guix/tests/syscalls.scm:156
     source:
     + (test-equal
     +   "pivot-root"
     +   #t
     +   (match (pipe)
     +          ((in . out)
     +           (match (clone (logior CLONE_NEWUSER
CLONE_NEWNS SIGCHLD))
     +                  (0
     +                   (dynamic-wind
     +                     (const #t)
     +                     (lambda ()
     +                       (close in)
     +                       (call-with-temporary-directory
     +                         (lambda (root)
     +                           (let ((put-old
(string-append root
     "/real-root")))
     +                             (mount "none" root "tmpfs")
     +                             (mkdir put-old)
     +                             (call-with-output-file
     +                               (string-append root
"/test")
     +                               (lambda (port) (display
"testing\n"
     port)))
     +                             (pivot-root root put-old)
     +                             (write (file-exists?
"/test") out)
     +                             (close out)
     +                     (lambda () (primitive-exit 0
     +                  (pid (close out)
     +                       (let ((result (read in)))
     +                         (close in)
     +                         (and (zero? (match (waitpid pid)
     +                                            ((_ . status)
     +   
  (status:exit-val

     status
     +                              (eq? #t result
     expected-value: #t
     actual-value: #f
     result: FAIL


     The summary is:
     # TOTAL: 777
     # PASS:  772
     # SKIP:  4
     # XFAIL: 0
     # FAIL:  1
     # XPASS: 0
     # ERROR: 0

     I'm novice in Guix, can anyone give me a clue?


Actually there are two possibilities. I'm trying to narrow this down
now.
There is a bug:https://bugzilla.kernel.org/show_bug.cgi?id=183461

in our bug tracker that might be affecting you, or the shared mounts
I noticed much later. I'm going to investigate this and report back.


I've created a vm image with a current Ubuntu 16.04 yesterday, installed
the guix binary tarball, and did a make check in a guix environment guix.
This error was not shown in my case.

My uname -r is:
  4.10.0-28-generic

This test should be skipped, if kernel version > 4.7.5.
Can you please send the output of uname -r ?


4.4.0-116-generic



Re: Package requests: Udisks helpers (udiskie, udevil)

2018-03-29 Thread Pierre Neidhardt

I don't use Nautilus and I just want to automate the ~udisksctl mount~
command whenever a disk is plugged-in.
Some udev rules might be enough though.

-- 
Pierre Neidhardt


signature.asc
Description: PGP signature


Re: Package requests: Udisks helpers (udiskie, udevil)

2018-03-29 Thread Ricardo Wurmus

Hi Pierre,

> udevil:   Mount and unmount without password
> Upstream URL: http://ignorantguru.github.com/udevil/

This is a setuid binary, which doesn’t seem like a good idea in general.

For what it’s worth, automounting works just fine for me.  When using
Nautilus USB drives are automatically detected and can be mounted (and
unmounted) with a single click.

Even without Nautilus you can mount and unmount drives without the need
for root privileges, e.g. with

udisksctl mount -b /dev/sdb2
udisksctl unmount -b /dev/sdb2

I’m curious: What do these tools offer compared to udiskctl or the magic
of Nautilus?

--
Ricardo

GPG: BCA6 89B6 3655 3801 C3C6  2150 197A 5888 235F ACAC
https://elephly.net





Package requests: Udisks helpers (udiskie, udevil)

2018-03-29 Thread Pierre Neidhardt

At the moment, Guix does not seem to feature any helper to auto-mount
disks managed by udisks (such as external hard drives).

Common options include

udiskie:Removable disk automounter using udisks
Upstream URL:   https://pypi.python.org/pypi/udiskie

udevil: Mount and unmount without password
Upstream URL:   http://ignorantguru.github.com/udevil/

I'm willing to package one of them.  Does anyone have an opinion on the matter?

-- 
Pierre Neidhardt


signature.asc
Description: PGP signature


Re: Missing pinentry-emacs for gpg-agent?

2018-03-29 Thread Pierre Neidhardt

Oleg Pykhalov  writes:

>>  > cp ~/.config/guix/latest/gnu/packages/gnupg.scm ~/.guix-packages/
>>  > chmod +w ~/.guix-packages/gnupg.scm
>> [...]
>> Then add the above the the file
>
> Sorry, I don't understand what do you mean.

I meant adding the ~(define-public ... (package...))~ I quoted to the
new gnupg.scm file.

> Do you mean ‘#:use-module (gnu packages gnupg)’?

No. For now I just wanted to do some out-of-tree hacking, as a first
step towards contributing to Guix.

What I had in mind:

1. Copy gnupg.scm.
2. Modify it to add the new recipe plus the new use-module requirements.
3. Build.

I understand it's not how Guix is meant to be patched, I'll go on with a
proper checkout next.

That said, the new ~define-module~ is as follows:


(define-module (gnu packages gnupg)
  #:use-module ((guix licenses) #:prefix license:)
  #:use-module (gnu packages)
  #:use-module (gnu packages emacs) ; NEW
...

>> Now if I do
>>
>>  > guix package -s pinentry-emacs
>>  guix package: warning: failed to load '(gnupg)':
>>  no code for module (gnupg)
>>  name: pinentry-emacs
>>  version: 1.1.0
>>  outputs: out
>>  systems: x86_64-linux i686-linux armhf-linux aarch64-linux 
>> mips64el-linux
>>  dependencies: emacs-25.3 libassuan-2.5.1 libsecret-0.18.5 
>> ncurses-6.0-20170930
>>  + pkg-config-0.29.2
>>  location: /home/ambrevar/.guix-packages/gnupg.scm:991:2
>>  homepage: https://gnupg.org/aegypten2/
>>  license: GPL 2+
>>  synopsis: GnuPG's interface to passphrase input
>>  description: Pinentry provides a console and an Emacs interface that 
>> allows users to enter a
>>  + passphrase when required by `gpg' or other software.
>>  relevance: 4
>>
>> Notive the error at th beginning:
>>
>>  guix package: warning: failed to load '(gnupg)':
>>  no code for module (gnupg)
>>
>> I don't understand this.
>
> You want to name your Guile module properly [2].  In case of
> ‘GUIX_PACKAGE_PATH=$HOME/.guix-packages’:
>
> (define-module (gnupg) …)

So ~(define-module (gnu packages gnupg)...)~ means the package must lie
in a "gnu/packages/gnupg.scm" file.  Did not know that, I assumed the
namespace was detached from

> [2]  
> https://www.gnu.org/software/guile/manual/html_node/Using-the-Guile-Module-System.html

The manual you linked shows examples of paths linked to the namespaces.
But I can't seem to find where it states that it is a requirement.

I always thought this requirement on path-linked namespaces (that we
find in many languages) to be redundant.

> Local checkout allows you prepare patches and use ‘guix’ without ‘guix
> pull’.  If you plan to contribute more it's definitely worth to have it.

Will do just now.
Thanks a lot for your help.

--
Pierre Neidhardt


signature.asc
Description: PGP signature


updatedb.conf is missing, should it be configurable via ~guix system reconfigure~?

2018-03-29 Thread Pierre Neidhardt

~man updatedb.conf~ shows

   /gnu/store/d51d0bnpiwmarcjp8kckxb5wvs6kr7dz-mlocate-0.26/etc/updat‐
   edb.conf - a configuration file for updatedb(8)

Which does not exist.

> guix build mlocate
/gnu/store/5ry4cnrnfx54mjvh20n4idfv7xqfc95m-mlocate-0.26

> tree -a /gnu/store/5ry4cnrnfx54mjvh20n4idfv7xqfc95m-mlocate-0.26
/gnu/store/5ry4cnrnfx54mjvh20n4idfv7xqfc95m-mlocate-0.26
|-- bin
|   |-- locate
|   `-- updatedb
|-- share
|   |-- doc
|   |   `-- mlocate-0.26
|   |   `-- COPYING
|   |-- locale
|   |   [...]
|   `-- man
|   |-- man1
|   |   `-- locate.1.gz
|   |-- man5
|   |   |-- mlocate.db.5.gz
|   |   `-- updatedb.conf.5.gz
|   `-- man8
|   `-- updatedb.8.gz
`-- var
`-- mlocate

A global search on the filesystem reveals no updatedb.conf.  I think we
need some rules to configure it from a system configuration with ~guix
system reconfigure~.

-- 
Pierre Neidhardt


signature.asc
Description: PGP signature


Re: Missing pinentry-emacs for gpg-agent?

2018-03-29 Thread Oleg Pykhalov
Pierre Neidhardt  writes:

> Thinking more about it, wouldn't it make more sense to use several
> outputs instead of several packages?

In case of ‘pinentry-emacs’ and other ‘pinentry-*’, you use different
‘configure-flags’ (because of security or other reasons).  I guess you
cannot specify different ‘configure-flags’ for several outputs.

> Is it possible to specify additional inputs for specific outputs?

My guess is *no*.  But I hope someone answer this question more clearly.

Oleg.


signature.asc
Description: PGP signature


Re: Missing pinentry-emacs for gpg-agent?

2018-03-29 Thread Oleg Pykhalov
Pierre Neidhardt  writes:

[…]

> What about a separate package?  E.g.
>
>   (define-public pinentry-emacs
> (package
>  (inherit pinentry-tty)
>  (name "pinentry-emacs")
>  (inputs
>   `(("emacs" ,emacs)
> ,@(package-inputs pinentry-tty)))
>  (arguments
>   `(#:configure-flags '("--enable-pinentry-emacs")))
>  (description
>   "Pinentry provides a console and an Emacs interface that allows 
> users to
>   enter a passphrase when required by @code{gpg} or other software.")))

Looks like what ‘pinentry-gtk2’, ‘pinentry-gnome3’, ‘pinentry-qt’ do.

I think it's a way to go.

> I haven't delved into packaging so far.  I have read the manual but I'm
> unsure about the best practice for local hacking.

To prepare a patch you should have a Guix from a Git checkout [1].

You could still just send a package recipe in plain text.

> I have set GUIX_PACKAGE_PATH=~/.guix-packages, then
>
>   > cp ~/.config/guix/latest/gnu/packages/gnupg.scm ~/.guix-packages/
>   > chmod +w ~/.guix-packages/gnupg.scm
^
You probably mean this.  ;-)

> Then add the above the the file

Sorry, I don't understand what do you mean.

Do you mean ‘#:use-module (gnu packages gnupg)’?

[…]

> Now if I do
>
>   > guix package -s pinentry-emacs
>   guix package: warning: failed to load '(gnupg)':
>   no code for module (gnupg)
>   name: pinentry-emacs
>   version: 1.1.0
>   outputs: out
>   systems: x86_64-linux i686-linux armhf-linux aarch64-linux 
> mips64el-linux
>   dependencies: emacs-25.3 libassuan-2.5.1 libsecret-0.18.5 
> ncurses-6.0-20170930
>   + pkg-config-0.29.2
>   location: /home/ambrevar/.guix-packages/gnupg.scm:991:2
>   homepage: https://gnupg.org/aegypten2/
>   license: GPL 2+
>   synopsis: GnuPG's interface to passphrase input  
>   description: Pinentry provides a console and an Emacs interface that 
> allows users to enter a
>   + passphrase when required by `gpg' or other software.
>   relevance: 4
>
> Notive the error at th beginning:
>
>   guix package: warning: failed to load '(gnupg)':
>   no code for module (gnupg)
>
> I don't understand this.

You want to name your Guile module properly [2].  In case of
‘GUIX_PACKAGE_PATH=$HOME/.guix-packages’:

(define-module (gnupg) …)

> That said, is this the commended way to proceed?  

Sorry, I don't fully understand the question.  As far as I understand,
the answer is you could use ‘GUIX_PACKAGE_PATH’ to have recipes that
cannot be in Guix package collection for some reason, e.g. customized
for own purpose recipes.  It's not the case of ‘pinentry-emacs’.  ;-)

> Or should I work from a local checkout of guix?

Local checkout allows you prepare patches and use ‘guix’ without ‘guix
pull’.  If you plan to contribute more it's definitely worth to have it.

[…]

[1]  https://www.gnu.org/software/guix/manual/html_node/Building-from-Git.html
[2]  
https://www.gnu.org/software/guile/manual/html_node/Using-the-Guile-Module-System.html

Thanks,
Oleg.


signature.asc
Description: PGP signature