Re: Emacs in multiple profiles

[Alex Kost]

Pierre Neidhardt (2019-10-16 21:54 +0200) wrote:

> Hi!
>
> I'm resurrecting this since I got bitten by this today.
>
> I'm currently writing a blog article on profiles and manifest, and I
> realized that Emacs is the only program so far that does not behave
> consistently with the rest of Guix.
>
> When I source the etc/profile where I've installed my Emacs packages,
> I'd expect the appropriate environment variables to be set so that
> `guix-emacs-autoload-packages' knows where to load the packages from.
>
> I believe the solution to be simple:
>
> 1. Make Emacs packages set XDG_DATA_DIRS in etc/profile
> 2. guix-emacs.el: Remove guix-user-profile
> 3. guix-emacs.el: Set profiles to all the paths in XDG_DATA_DIRS in the
> guix-emacs-autoload-packages function.
>
> Thoughts?

Hello, I'm not sure if my answer was expected, so just in case:
Please do whatever looks appropriate to you :-)

-- 
Alex

Re: conkeror superseded by icecat, why?

[Alex Kost]

白い熊 (2019-06-02 12:19 +0200) wrote:

> Hi everyone:
>
> I've long had conkeror installed, now after the latest Guix update it won't 
> start, it's not installed anymore.
>
> “guix package -i conkeror” tells me:
>  guix package: package 'conkeror' has been superseded by 'icecat'
>
> Why? These are two very different browsers.

As Pierre wrote, Conkeror is abandoned, unfortunately.  It does not work
with the modern versions of icecat/firefox.  I.e., it is not possible to
start conkeror anymore (only conkeror on top of some old icecat/firefox
version could work), so it is (or will be) excluded from all GNU/Linux
distributions.

-- 
Alex

Re: emacs-guix throwing errors

[Alex Kost]

bre...@posteo.net (2019-04-07 17:37 -0500) wrote:

> Hey Alex, I think I mentioned earlier that I can replicate this bug
> on a fresh install of Guix. Only installing Emacs and emacs-guix to
> my profile. Can you see if you can replicate it that way?

No, I don't reproduce it, sorry.  Perhaps you have not run "guix pull"
for a long time (?).  If so, this may be a problem if emacs-guix is
compiled with a "fresh" guix and is used with an older guix.

BTW, are you on Guix System or do you use guix package manager on a
foreign system?

-- 
Alex

Re: emacs-guix throwing errors

[Alex Kost]

bre...@posteo.net (2019-04-06 02:59 +0200) wrote:

> On 04.04.2019 21:38, Alex Kost wrote:
>> Brett Gilio (2019-04-01 16:13 -0500) wrote:
>>
>>> Hi all. I am hoping the maintainer of emacs-guix will see this:
>>
>> Hello,
>>
>>> Whenever I try to search for a package, or perform any of the routine
>>> guix commands using the emacs-guix interface, I am getting this error.
>>>
>>> guix-geiser-eval: Error in evaluating guile expression: ERROR: In
>>> procedure string-append:
>>> In procedure string-append: Wrong type (expecting string):
>>> #< variable: "GHC_PACKAGE_PATH" files:
>>> ("lib/ghc-8.0.2") separator: ":" file-type: directory file-pattern:
>>> ".*\\.conf\\.d$">
>>>
>>> The specifics of the string seem to change based on what I am trying
>>> to
>>> do, but regardless it does not work and I have to perform those
>>> commands
>>> using the command line.
>>>
>>> Any ideas?
>>
>> No ideas currently, but could you please switch to *Guix Internal REPL*
>> buffer, run ",bt" command there and show its output.  Thanks.
>
> Hi Alex,
>
> Here is the backtrace for doing a regexp search for 'emacs'
[...]

Sorry, I'm afraid I don't know what causes this error.  I hope I will
face this bug soon, so that I could figure it out.  Maybe it happens
only to people who installed "ghc" package (as the error says about
GHC_PACKAGE_PATH variable), I don't know :-(

-- 
Alex

Re: emacs-guix throwing errors

[Alex Kost]

Brett Gilio (2019-04-01 16:13 -0500) wrote:

> Hi all. I am hoping the maintainer of emacs-guix will see this:

Hello,

> Whenever I try to search for a package, or perform any of the routine
> guix commands using the emacs-guix interface, I am getting this error.
>
> guix-geiser-eval: Error in evaluating guile expression: ERROR: In procedure 
> string-append:
> In procedure string-append: Wrong type (expecting string):
> #< variable: "GHC_PACKAGE_PATH" files:
> ("lib/ghc-8.0.2") separator: ":" file-type: directory file-pattern:
> ".*\\.conf\\.d$">
>
> The specifics of the string seem to change based on what I am trying to
> do, but regardless it does not work and I have to perform those commands
> using the command line.
>
> Any ideas?

No ideas currently, but could you please switch to *Guix Internal REPL*
buffer, run ",bt" command there and show its output.  Thanks.

-- 
Alex

Re: How to start Xorg server with startx

[Alex Kost]

Chris Marusich (2019-02-14 02:51 -0800) wrote:

> I don't use startx, so I don't know enough to answer this question.
> Maybe someone else can help?

There is a tutorial on how "xinit" can be used on GuixSD:

  https://lists.gnu.org/archive/html/help-guix/2018-07/msg00080.html

Perhaps it misses some details, but overall it should be workable.  IIRC
the main missing point is that your user should be added to "input" and
"tty" groups.

-- 
Alex

Re: emacs-guix error

[Alex Kost]

Maxim Cournoyer (2019-01-27 20:49 -0500) wrote:

> Hello!
>
> [...]
>
>> Are you using Guix from a git checkout?  In that case you’ll need to
>> recompile as there has been an ABI change.
>
> My normal Guix run from guix pull, but I do have a Guix checkout that I
> use with the pre-inst-env wrapper.
>
> I have this set in my ~/.emacs.
>
> (setq guix-directory "~/src/guix")
>
> IIUC, that doesn't cause Emacs-Guix to use that Guix, only locate
> package definition.

This is correct.  If someone wants to augment the default load path used
by Emacs-Guix, they can set 'guix-load-path' variable.

-- 
Alex

Re: emacs-guix error

[Alex Kost]

Yoshinori Arai (2019-01-26 12:31 +0900) wrote:

> On Fri, Jan 25, 2019 at 08:48:21PM +0300, Alex Kost wrote:
>  
>> Hello, do you use Guix on a foreign system (not GuixSD)?  If so, please
>> look at:
>> 
>>   https://github.com/alezost/guix.el#important-note-for-non-guixsd-users
>> 
>> Try the workaround described there and let me know if it works or not.
>> 
>> -- 
>> Alex
>
> Hello, I use both, foreign system and GuixSD. There is problem on GuixSD.
> I followed the link you pointed but I can't recover. 

Ouch, I'm afraid I can't help then, as I don't know what could cause
this problem, sorry :-(

-- 
Alex

Re: emacs-guix error

[Alex Kost]

bre...@posteo.net (2019-01-23 20:34 -0600) wrote:

> I reported this issue two days ago and haven't heard anything yet

Hello, where did you report it?  Sorry, I don't see it anywhere.

-- 
Alex

Re: emacs-guix error

[Alex Kost]

Yoshinori Arai (2019-01-24 09:20 +0900) wrote:

> hello,
>
> When I will execute install pacakge or dry-run on emacs-guix, this error is
> showed. It's success to install on command line.
>
> (process-package-actions "/var/guix/profiles/per-user/yoshi/guix-profile" 
> #:install '((145722368 "out")) #:upgrade '() #:remove '() #:use-substitutes? 
> #t #:dry-run? #f)
> The process begins ...
> ERROR: Wrong type to apply: #
>
> Entering a new prompt.  Type `,bt' for a backtrace or `,q' to continue.
>
> Please tell me the pointer to resolve this issue.

Hello, do you use Guix on a foreign system (not GuixSD)?  If so, please
look at:

  https://github.com/alezost/guix.el#important-note-for-non-guixsd-users

Try the workaround described there and let me know if it works or not.

-- 
Alex

Re: [ANN] Emacs-Guix 0.5.1

[Alex Kost]

Ricardo Wurmus (2019-01-06 00:49 +0100) wrote:

> Hi Alex,
>
>> zimoun answered correctly.  I think it is the same problem as several
>> people have on non-GuixSD system.  Most likely, it will not be fixed on
>> Emacs-Guix side.  The only workaround I know is "guix package -i guix".
>
> Would it be feasible for Emacs-Guix to use
> “~/.config/guix/current/bin/guix repl”, which would have the effect of
> setting the load path as expected?

Interesting idea!  But AFAICT it is impossible: Emacs-Guix needs to run
Geiser in one way or another, but if you try:

  (setq geiser-guile-binary '("guix" "repl"))
  "M-x geiser"

it will fail because geiser tries to run it with "-q" and "-L" (with a
directory with Geiser Guile modules).  Obviously these options are not
supported by "guix repl".  Above that, Emacs-Guix uses "--listen"
option.

So I'm afraid as long as "guix repl" options are incompatible with
"guile" ones, it can't be used by Emacs-Guix.

-- 
Alex

Re: [ANN] Emacs-Guix 0.5.1

[Alex Kost]

Benjamin Slade (2019-01-04 15:12 -0700) wrote:

> I love Emacs-Guix - thank you for this.
>
> Relatedly - I'm trying to debug an issue: so on my both pure GuixSD
> machine and on my Arch machine with standalone Guix binary installer,
> =guix-all-packages= shows me 9213 packages, but on my Void machine with
> standalone Guix binary installer, the same command only shows me around
> 900(!) packages. But on the same machine, the expected full range of
> Guix packages are available in the terminal via =guix package=. What
> could cause Emacs-Guix to only show a subset of packages in this one
> case?

zimoun answered correctly.  I think it is the same problem as several
people have on non-GuixSD system.  Most likely, it will not be fixed on
Emacs-Guix side.  The only workaround I know is "guix package -i guix".

-- 
Alex

Re: Emacs-guix: variable is void: guix-current-profile

[Alex Kost]

zimoun (2019-01-03 22:58 +0100) wrote:

> Dear Alex,
>
> Thank you for your answer and the nice emacs-guix interface.

Thanks :-)

>> It should be fixed by the latest commit:
>>
>>   
>> https://notabug.org/alezost/emacs-guix/commit/d7b54784bc3962570519aac472f54598c10299ae
>>
>> So you may try to reinstall it from MELPA to check if it works now.  BTW
>> installing from MELPA should be as fine, as from Guix.  As far as I
>> understand, the problems you faced are not related to the way you
>> install Emacs-Guix.
>
> After the reinstall from MELPA, it appears to me that the guix popup
> works as expected. :-)
>
> Note that the popup does work properly with emacs-guix, since the
> letter p is binded twice (processes and package).
> I guess that the next release (available in MELPA) will fix this.

The current Emacs-Guix release (0.5.1) already has a fix for it
("processes" is bound to "o" there), so it looks like you installed some
previous version of emacs-guix with guix.  Make sure your guix is
up-to-date.  Have you ever run "guix pull"?

>> > Last, 'guix package -s gmsh' returns the package that I am looking for.
>> > However, `M-x guix p n gmsh' does not.
>> > I need to do 'guix package -i guix' to find gmsh with emacs-guix. Hum?
>>
>> Yes, this is a big problem on non-GuixSD systems.  In short, "guix pull"
>> does not install its guile dependencies in the pulled profile.  Instead
>> they are hardcoded in "~/.config/guix/current/bin/guix", so Emacs-Guix
>> can't use these modules and this leads to unexpected errors.
>>
>> The only workaround is to install "guix" in a user profile: this will
>> automatically "propagate" (install) all the missing Guile dependencies.
>>
>> People usually don't face this problem on GuixSD because "guix" (thus,
>> all its propagated dependencies) is installed in a system profile there.
>>
>> I don't see a way to fix this problem on the Emacs-Guix side.  For more
>> details, you may look at the discussion at
>> .
>
> Hum? I am too newbie to have an opinion. :-)

No problem, I just tried to describe this problem.

> A random idea.
> What Guix needs to expose to emacs-guix?
> And these missing guile modules should be packed to e.g. guix-minimal.
> What do you think?

I think guix should either install its guile dependencies to the pulled
profile (as it does with any usual profile), or make an auxiliary file
with "Guile load path" environment that can be used both by
"~/.config/guix/current/bin/guix" and by Emacs-Guix.

-- 
Alex

Re: Emacs-guix: variable is void: guix-current-profile

[Alex Kost]

zimoun (2019-01-02 16:34 +0100) wrote:

> Dear,
>
> Happy New Year !
>
> Thank you this nice interface !!
>
> I am have installed Guix on the top of Debian.
> If I understand well, I installed the packages guile, guile-gcrypt and
> Emacs, obviously. :-)
> And emacs-guix comes from MELPA, Geiser too.
> Then I am a bit confused.
>
> M-x guix pops up.
> However, press p leads to the message:
> "guix-popup-format-profile: Symbol’s value as variable is void:
> guix-current-profile"
> But, C-h v guix-current-profile returns
> "/var/guix/profiles/per-user/simon/guix-profile"

Ouch, this is a bug!  Sorry and thank you for the report!
It should be fixed by the latest commit:

  
https://notabug.org/alezost/emacs-guix/commit/d7b54784bc3962570519aac472f54598c10299ae

So you may try to reinstall it from MELPA to check if it works now.  BTW
installing from MELPA should be as fine, as from Guix.  As far as I
understand, the problems you faced are not related to the way you
install Emacs-Guix.

> Last, 'guix package -s gmsh' returns the package that I am looking for.
> However, `M-x guix p n gmsh' does not.
> I need to do 'guix package -i guix' to find gmsh with emacs-guix. Hum?

Yes, this is a big problem on non-GuixSD systems.  In short, "guix pull"
does not install its guile dependencies in the pulled profile.  Instead
they are hardcoded in "~/.config/guix/current/bin/guix", so Emacs-Guix
can't use these modules and this leads to unexpected errors.

The only workaround is to install "guix" in a user profile: this will
automatically "propagate" (install) all the missing Guile dependencies.

People usually don't face this problem on GuixSD because "guix" (thus,
all its propagated dependencies) is installed in a system profile there.

I don't see a way to fix this problem on the Emacs-Guix side.  For more
details, you may look at the discussion at
.

-- 
Alex

[ANN] Emacs-Guix 0.5.1

[Alex Kost]

Hello, Emacs-Guix (Emacs interface for GNU Guix) version 0.5.1 has been
released.  If you are not familiar with it yet, you may try it with:
‘guix package -i emacs-guix’ and "M-x guix".

Summary of the new features:

* M-x guix

  This is the *new* "M-x guix" which is a popup interface for the rest
  Emacs-Guix commands.  You may find a screenshot of this popup window
  at .

  The old "M-x guix" (interface for guix shell commands) was renamed to
  "M-x guix-command".  Also you can reach it from the new "M-x guix"
  with "c" key.

* M-x guix-set-emacs-environment

  This command sets Emacs environment according to a specified profile.
  Note that after calling this command, the whole Emacs will have a new
  environment (you may check ‘process-environment’ variable), so "M-x
  shell" or any other process will inherit this environment.

  Many thanks to Jan Nieuwenhuizen for inventing and implementing this
  command.

* "Total size" messages in "Guix Store Items" buffer

  Now, whenever this buffer is displayed (for example, after "M-x
  guix-store-dead-items"), a minibuffer message will display total size
  of the listed store items.  Also you can mark several items (with "m")
  and press "z" to get their total size.

  Thanks to Pierre Neidhardt for the idea of this feature.

-- 
Alex

Re: GC hints

[Alex Kost]

Mark H Weaver (2018-12-20 07:12 -0500) wrote:

> Hi Ludovic,
>
> Ludovic Courtès  writes:
>
>> Actually, I was also wondering whether we should provide a configurable
>> mechanism that would, by default, automatically delete old GC roots and
>> maybe even run the GC automatically when needed—similar to what Git
>> does.
>>
>> Thoughts?
>
> I think it's reasonable to automatically run GC by default, but I would
> strongly advise against deleting GC roots automatically by default
> without the user's knowledge and consent.
>
> It's certainly true that git performs GC automatically, but does it
> automatically delete GC roots by default?  I've never seen it do this,
> and I would be surprised and angry if it did.
>
> I consider Guix GC roots to be potentially valuable user data,
> regardless of age.  For example, an old GC root might be valuable
> because it was used to perform an experiment that should be repeatable,
> or because it is known to work reliably for a given job, and newer
> versions have not yet been tested.
>
> I, for one, expect my old profiles, system generations, and other GC
> roots to be kept unless I explicitly delete them, and I suspect I'm not
> alone.  If I hadn't been paying close attention to Guix development, and
> later discovered that Guix had deleted my GC roots without my consent, I
> would be surprised and angry.

You are not alone!  I completely agree with your points.

-- 
Alex

Re: How do I cope with Geiser in Emacs

[Alex Kost]

Luther Thompson (2018-12-01 19:34 -0500) wrote:

Hello,

> I don't know where to ask about this, but since the problem seems to
> involve many interconnected Emacs-related packages, I'll see if you
> guys can help.
>
> When I'm editing a Scheme file (not Guix-related) in Emacs and
> company-mode activates, I get this error message: 'Company: backend
> company-capf error "No Geiser REPL for this buffer (try M-x
> run-geiser)" with args (prefix)'. If I appease the error by running M-x
> run-geiser, I get completion lists that don't make much sense. They
> fail to include names that are already in the file, and they do include
> what appear to be many obscure library functions.
>
> I would expect company mode to fall back to a backend that doesn't
> throw an error, but the strange completion lists that I get with Geiser
> suggest that the problem is more complicated than that.
>
> Here's what I've been able to figure out so far:
>
> emacs-geiser is a propagated input of emacs-guix. (I don't directly use
> emacs-geiser.)
>
> company-capf is a backend for company-mode.
>
> While in Scheme mode, company-capf must be indirectly calling some
> function that throws this error.
>
>
> Is there some kind of configuration I can do to fix this? There are so
> many different Elisp files that might be involved, I don't know where
> to start looking for a solution.

Since this error comes from Geiser (from 'geiser-repl--connection'
function), I would ask at .
Alternatively, you may send a message at 

-- 
Alex

Re: Guix and Emacs Integration for Polyglot Development

[Alex Kost]

George Clemmer (2018-10-28 17:19 -0400) wrote:

> Alex Kost  writes:
[...]
>> BTW, in general, I think that hiding features is a bad thing… however,
>> there is one hidden feature in Emacs-Guix (although, it is hidden just
>> because it is also hidden in Guix itself ;-) )
>
> Is this a riddle?

Yeah, this feature is rather easy to find in Emacs-Guix, because it is
"hidden" ;-)

-- 
grep

Re: Guix and Emacs Integration for Polyglot Development

[Alex Kost]

George Clemmer (2018-10-27 15:32 -0400) wrote:

> Alex Kost  writes:
>
>> George Clemmer (2018-10-26 16:56 -0400) wrote:
>>
>>> I have another question. Is there a shortcut to
>>> guix-installed-system-packages in the popup that I am missing?
>>
>> No, there is a direct shortcut.  Currently there are 2 "long" ways
>> to access system packages from "M-x guix":
>>
>> 1) setting current profile to the system one ("p" in "packages"
>> sub-popup) and openning installed packages (with "i" key), or
>>
>> 2) through *Guix Profiles* buffer (which can be accessed with "M-x guix
>> P a"): there you can move to the system profile and press "P".
>
> I also found ... 'M-x guix P s P' ... which I had missed and is all I
> want/need ;-)

Oh, cool, I forgot about it :-)

>> I'm afraid, I am not going to add a shortcut for system packages inside
>> "packages" sub-popup, as it and "profiles" sub-popup are designed to
>> work with the current profile, so if you want to open packages or
>> generations from some profile, you need to make it the current one at
>> first.
>>
>> But maybe it would be good to add a new sub-popup for system commands,
>> where a key for system packages will be placed, WDYT?
>
> I agree with your approach.  I think this is all REALLY GREAT STUFF. You
> can leave it just the way it is and I will be happy.
>
> FWIW, here are a few comments/ideas ...
>
> It would be handy if 'quit-window' in the final buffer reached via
> *guix-popup* took me take me back 'UP' the "tree" of sub-popups that
> lead there so I could chose another option.

Is "q" key what you are looking for?  It is a general "magit-popup"
thing and there is nothing I can do about it on Emacs-Guix side.

Note, however, that "q" works only for one level, I mean if you press
"q" one time, it will take you back to the previous popup, but if you
press it again, it will simply quit.  Yet again, this is how
"magit-popup" works.

> With regard to system/user profiles. First, to state what may not be
> obvious to a novice guix user ...
>
> - In addition to the "default user" profile, you may use multiple "user
>   project" profiles.
>
> - In practice, a novice uses the packages in the union of the system and
>   default "user" profile. A more advanced user may have 1 or more
>   "project" profiles as well.
>
> - The system profile is fundamentally "a different kind of
>   animal". There is only one and you need different guix "tools" to
>   modify it.
>
> In the present design, presenting the system profile as "just another
> profile" in *Guix Profiles* leads to slapping the user's hand if/when
> they try to change the system profile, E.g.,
>
> user-error: Packages cannot be installed or removed to/from profile 
> ’/var/guix/profiles/system/profile’.
> Use ’guix system reconfigure’ shell command to modify a system profile.
>
> If, as you suggest, you create the system sub-popup

I went ahead and added it (by commit bffd65a).  I think keeping system
commands in one place is good.

> you might consider
> removing the system profile from *Guix Profiles* since the user can get
> to the system profile package list via system generations + 'P'.

No, no, I will not hide system profile.  Yes, you can't install anything
to it with the usual means, but it is a profile after all, and you can
see what packages are installed there.  Besides, some day a user should
learn that the only way to update a system profile is "guix system …"
command.

BTW, in general, I think that hiding features is a bad thing… however,
there is one hidden feature in Emacs-Guix (although, it is hidden just
because it is also hidden in Guix itself ;-) )

> Of
> course, you may still choose to show the user the error message above,
> but it would no longer be an asymmetric behavior on one of a group of
> things presented as equals.
>
> It might be useful to allow the user to see system profile packages in
> the context a user/project profile. E.g., a key could toggle the system
> profile packages into and out of the *Guix Packages * list view.

Sorry, I didn't understand this phrase.  Do you mean there should be a
key in *Guix Packages* buffer to show system packages along with the
current user packages?  If so, I'm afraid it is not possible, as these
"Packages" buffers are designed to show packages only from a single
profile.

-- 
Alex

Re: Guix and Emacs Integration for Polyglot Development

[Alex Kost]

George Clemmer (2018-10-26 16:56 -0400) wrote:

>> Alex Kost  writes:
>>
>>>   Hint: since you are on this commit, you may check the new "M-x guix" -
>>>   you will be the first person who will try it (maybe you will like it
>>>   this time)  ;-)
>
> I am sorry if I gave the impression that I disliked it.

No problem, I dislike it :-)

> I do like the
> new one better. It makes it easier to find and use Emacs-guix features.

Great!  It was the main intention.

> I have another question. Is there a shortcut to
> guix-installed-system-packages in the popup that I am missing?

No, there is a direct shortcut.  Currently there are 2 "long" ways
to access system packages from "M-x guix":

1) setting current profile to the system one ("p" in "packages"
sub-popup) and openning installed packages (with "i" key), or

2) through *Guix Profiles* buffer (which can be accessed with "M-x guix
P a"): there you can move to the system profile and press "P".

I'm afraid, I am not going to add a shortcut for system packages inside
"packages" sub-popup, as it and "profiles" sub-popup are designed to
work with the current profile, so if you want to open packages or
generations from some profile, you need to make it the current one at
first.

But maybe it would be good to add a new sub-popup for system commands,
where a key for system packages will be placed, WDYT?

-- 
Alex

Re: Guix and Emacs Integration for Polyglot Development

[Alex Kost]

George Clemmer (2018-10-26 00:59 -0400) wrote:

> Hi Alex,

Hello George!

> I have been using code like ...
>
> (with-eval-after-load (quote guix-ui-profile)
>   (setq guix-profiles
>   (append (quote("/home/glc/gom/.guix-profile")) guix-profiles)))
> (setq guix-current-profile "/home/glc/gom/.guix-profile")
>
> ... to add a "project" profile to *Guix Profile* and make it
> current. This has my desired effect: "making" emacs-guix package-related
> commands operate on a "project" profile instead of the "default user
> profile". Using your commit ...
>
> 4ce2b6a * master origin/master Add new 'guix' command and rename the old
> one to 'guix-command'

  Hint: since you are on this commit, you may check the new "M-x guix" -
  you will be the first person who will try it (maybe you will like it
  this time)  ;-)

> ... I tried "guix-set-emacs-environment" expecting it to be another way
> to do the same thing.  I was surprised when it didn't add the "new"
> profile to *Guix Profiles*. Shouldn't it do this, or am I missing
> something? In fact, it doesn't seem to be doing anything :-(

"M-x guix-set-emacs-environment" sets environment variables for Emacs
itself!  For example, you may check "M-x getenv PATH" or other
variables.  They should be augmented for the profile you selected.

-- 
Alex

Re: Guix and Emacs Integration for Polyglot Development

[Alex Kost]

Jan Nieuwenhuizen (2018-09-15 07:21 +0200) wrote:

> Alex Kost writes:
>
>> Jan Nieuwenhuizen (2018-09-13 22:45 +0200) wrote:
>>
>>> (defun guix-switch-profile ( profile)
>
>> Thank you!  I'm going to apply it.  I have extracted the guile code and
>> put it to the "scheme side" of Emacs-Guix, also I have rewritten this
>> command a bit.  The only thing: I don't like the name (neither
>> "guix-switch-profile" nor "guix-profile-apply").  I think
>> "guix-set-emacs-environment" suits better, as setting the environment is
>> exactly what this command does, WDYT?
>
>> You may look at my version of your patch (not in "master" yet) here:
>>
>>   
>> https://notabug.org/alezost/emacs-guix/commit/a4bd696f0b8c564c1e654c426e9059cac1607996
>
> Thank you, I enjoyed reading your rewrite, makes me happy!  Moving the
> scheme side makes it cleaner and I learned about -let, nice :-)

"-let" (and other "-foo" procedures and macros) is from "emacs-dash"
package.  This library contains many useful things to work with lists:

  https://github.com/magnars/dash.el

> I also like the new name better, you see that I struggled/renaed because
> I wasn't happy with it.  The initial switch-profile name was simply
> chosen because that's how I use it: to switch between my named profiles.

Ah, I see.

>> Let me know, if you think something should be fixed there.
>
> I think it's OK to go in.

Thanks, it is in master now.

> The thing I'm not really happy with yet is
> the UX of how to switch to temporary `guix environment ...'
> environments.  You have to do: echo $GUIX_ENVIRONMENT, , ,
> M-x guix-set-emacs-environment RET  ... but I have no idea how we
> could improve on that.  Thoughts?

Sorry, I also don't see a way to simplify this.

-- 
Alex

Re: Guix and Emacs Integration for Polyglot Development

[Alex Kost]

Jan Nieuwenhuizen (2018-09-13 22:45 +0200) wrote:

> (defun guix-switch-profile ( profile)
>   "Switch Emacs' environment to PROFILE.  PROFILE can be a named
> profile (like ~/.guix-profile, ~/.config/guix/work) or an
> environment (like: echo $GUIX_ENVIRONMENT)."
>
>   (interactive "fprofile: ")
>   (lexical-let* ((guix-program
>   `(begin
> (use-modules (ice-9 match)
>  (guix profiles)
>  (guix search-paths))
> (let ((specs (profile-search-paths ,(expand-file-name 
> profile
>   (map
>(match-lambda ((spec . dir)
>   (list 
> (search-path-specification-variable spec)
> (or 
> (search-path-specification-separator spec) "")
> dir)))
>specs
>  (guix-output (guix-eval (format "%S" guix-program)))
>  (profile-sexp (car (read-from-string (car guix-output)
> (mapcar*
>  (lambda (variable separator path)
>(lexical-let ((value (cond ((string-empty-p separator) path)
>   ((getenv variable) (concat path separator 
> (getenv variable)))
>   (t path
>  (setenv variable value)))
>  (mapcar #'car profile-sexp)
>  (mapcar #'cadr profile-sexp)
>  (mapcar #'caddr profile-sexp

Thank you!  I'm going to apply it.  I have extracted the guile code and
put it to the "scheme side" of Emacs-Guix, also I have rewritten this
command a bit.  The only thing: I don't like the name (neither
"guix-switch-profile" nor "guix-profile-apply").  I think
"guix-set-emacs-environment" suits better, as setting the environment is
exactly what this command does, WDYT?

You may look at my version of your patch (not in "master" yet) here:

  
https://notabug.org/alezost/emacs-guix/commit/a4bd696f0b8c564c1e654c426e9059cac1607996

Let me know, if you think something should be fixed there.

-- 
Alex

Re: Guix and Emacs Integration for Polyglot Development

[Alex Kost]

Ludovic Courtès (2018-08-24 23:55 +0200) wrote:

[...]
> It would be nice if we could somehow attach an environment to a buffer,
> and for instance have M-x compile operate under that environment.
>
> Another interesting thing would be the ability to have Babel snippet
> specify their complete environment, instead of just the language.  For
> that we’d need help from Emacs-Guix to keep track of existing
> environments.
>
> Maybe if Alex Kost is reading this they can comment.  :-)

I am not "they", I prefer to be called "he" ;-)

I am afraid I don't plan to do anything related to the features you
discuss, sorry.

-- 
Alex

Re: Enable guix-devel-mode only in guix source files

[Alex Kost]

Pierre Neidhardt (2018-08-21 17:23 +0200) wrote:

>> Ah, that's what you meant.  I think this is horrible :-)
>
> Why?

As I explained, configuring third-party packages in dir-locals does not
look right to me.  It may lead to problems if you remember:

  http://lists.gnu.org/archive/html/guix-devel/2018-05/msg00231.html

And in general, I don't like when developers make default settings that
are hard to "fix".  What if I don't want to use 'guix-devel-mode' at
all?  Why do you force me to use it?

That's why I disabled all these dir-locals in my emacs config:
developers often put to ".dir-locals.el" their personal settings.  I
just can't stand it.

-- 
Alex

Re: Enable guix-devel-mode only in guix source files

[Alex Kost]

Pierre Neidhardt (2018-08-21 00:18 +0200) wrote:

>> - add a function to the Guix ".dir-locals.el" (does dir-locals support
>>   functions at all?)
>
> I haven't tested, but currently .dir-locals.el contains
>
>  (scheme-mode
>   .
>   (indent-tabs-mode . nil)
>
> I suppose we can add
>
>  (scheme-mode
>   .
>   (indent-tabs-mode . nil)
>   (guix-devel-mode . t)

Ah, that's what you meant.  I think this is horrible :-)

>> - the function to set up a third-party package (Emacs-Guix)!  Why Guix
>>   should do it?
>
> Sorry, what do you mean?

Guix and Emacs-Guix are separate projects.  And a user is not forced to
use Emacs-Guix, so calling 'guix-devel-mode' will simply fail if
Emacs-Guix is not installed.  So I think this addition to dir-locals
would be a bad decision.

-- 
Alex

Re: Enable guix-devel-mode only in guix source files

[Alex Kost]

Arun Isaac (2018-08-19 23:38 +0530) wrote:

>>> A better approach might be to add it to .dir-locals.el upstream.  What do 
>>> you
>>> people think?
>>
>> I think the less is added to "dir-locals" the better.  Especially, there
>> shouldn't be any functions there in my opinion.
>
> Thanks, Alex and Pierre, for your replies. But, why is adding to
> dir-locals not a good idea?

It's not a good idea only in my opinion :-)

I personally don't like when someone decides what settings I should use
so much, that I disable all these dir-locals stuff completely (using
'enable-dir-local-variables' variable).

But if I understood this situation correctly, Pierre suggested to:

- add a function to the Guix ".dir-locals.el" (does dir-locals support
  functions at all?)

- the function to set up a third-party package (Emacs-Guix)!  Why Guix
  should do it?

Both these points doesn't look right to me.

-- 
Alex

Re: Enable guix-devel-mode only in guix source files

[Alex Kost]

Pierre Neidhardt (2018-08-17 18:44 +0200) wrote:

> I do exactly what you suggested:
>
> (defun ambrevar/init-guix ()
>   (and buffer-file-name
>(string-match "\\" buffer-file-name) ; Adapt this to your 
> install.
>(guix-devel-mode)))
> (add-hook 'scheme-mode-hook 'ambrevar/init-guix)
>
> A better approach might be to add it to .dir-locals.el upstream.  What do you
> people think?

I think the less is added to "dir-locals" the better.  Especially, there
shouldn't be any functions there in my opinion.

-- 
Alex

Re: Guix and desktop files

[Alex Kost]

hiph...@openmailbox.org (2018-08-11 19:46 +) wrote:

> Hello everyone,
>
> I am using Kubuntu 18.04 and I recently installed Guix as a secondary package
> manager. I'm still feeling my way around and I have been wondering whether
> the desktop files provided by some applications can be integrated with the
> desktop environment.
>
> When I install an application through apt a desktop file is placed in
>
> /usr/share/applications
>
> and the application shows up in my Application menu. Guix has an analogue to
> this under
>
>   ~/.guix-profile/share/applications/
>
> and it contains Gimp at the moment, but I have no idea how to hook this
> directory up to the menu. Is there an environment variable like there is for
> $PATH?

Probably XDG_DATA_DIRS, although it should be set appropriately if you
source your ~/.guix-profile/etc/profile

-- 
Alex

Re: [ANN] Emacs-Guix 0.4.1

[Alex Kost]

Pierre Neidhardt (2018-07-04 11:51 +0200) wrote:

>> %load-path
> $4 = ("/home/ambrevar/.guix-packages" "/home/ambrevar/projects/guix"
> "/gnu/store/hjx7wm756cxfl91j8iphrl5izd8xvp3f-emacs-guix-0.4.1.1/share/guile/site/2.2"
> "/home/ambrevar/.config/guix/current/share/guile/site/2.2"

Aha! here it is: your "~/projects/guix" appears before the pulled
profile.  I think it can happen only if you added it to
GUIX_PACKAGE_PATH, did you?

I think GUIX_PACKAGE_PATH is intended only for the user packages, not
for the whole guix checkout as it may lead to problems (I forgot what
kind of problems but I recall people did this in the past and had some
troubles).

Anyway, it should probably work… but only if your checkout is built
properly.  Did you run make there? any errors?  maybe there are some ABI
incompatibilities ("make clean-go" and "make" should fix them).  Did you
experience any problem with "guix" shell commands?

-- 
Alex

Re: [ANN] Emacs-Guix 0.4.1

[Alex Kost]

Alex Kost (2018-07-03 22:14 +0300) wrote:

> Pierre Neidhardt (2018-07-03 18:40 +0200) wrote:
[...]
>> With
>>
>>  (add-to-list 'geiser-guile-load-path "~/projects/guix")
>>
>> I still experience the transaction issue.

This geiser-guile-load-path should be placed after
"~/.config/guix/current/…" in guile %load-path so it shouldn't make any
effect.  So the only possibility for your error I see is that the
"pull"-ed directories are not added to the guile load paths.

>> Can you reproduce?
>
> No.  Please show what "M-: (guix-repl-guile-args)" returns.

Also, please check the values of %load-path and %load-compiled-path
variables in Guix REPL.


-- 
Alex

Re: [ANN] Emacs-Guix 0.4.1

[Alex Kost]

Pierre Neidhardt (2018-07-03 18:40 +0200) wrote:

> Alex Kost  writes:
>
>> Pierre Neidhardt (2018-06-28 19:04 +0200) wrote:
>>> Indeed, I had this:
>>>
>>> (add-to-list 'geiser-guile-load-path "~/projects/guix")
>>>
>>> as per "(guix) The Perfect Setup" of the Guix manual.  Removing this
>>> fixed the transaction issues.
>>>
>>> Insights?
>>
>> "~/.config/guix/current/…" overrides "~/projects/guix" in %load-path of
>> Guix REPL, but the problem is that %load-compiled-path does not have the
>> according .go files as I wrote in the previous message, so the
>> incompatibility between .scm (from "~/.config/guix/current") and .go
>> (from "~/projects/guix") led to errors.
>>
>> I have fixed it in Emacs-Guix:
>>
>>   
>> https://notabug.org/alezost/emacs-guix/commit/38a20cefe14969970817de97693c3f0f00b1c099
>
> Hmm... I think there is a misunderstanding.
> With
>
>   (add-to-list 'geiser-guile-load-path "~/projects/guix")
>
> I still experience the transaction issue.
> Can you reproduce?

No.  Please show what "M-: (guix-repl-guile-args)" returns.

-- 
Alex

Re: [ANN] Emacs-Guix 0.4.1

[Alex Kost]

Pierre Neidhardt (2018-06-28 19:04 +0200) wrote:

> Alex Kost  writes:
>
>> I don't know.  This error looks like guile load paths are not set
>> correctly.  Could you switch to Guix REPL and check whether %load-path
>> contains "~/.config/guix/current/share/guile/site/2.2" ?
>
> Indeed, I had this:
>
>   (add-to-list 'geiser-guile-load-path "~/projects/guix")
>
> as per "(guix) The Perfect Setup" of the Guix manual.  Removing this
> fixed the transaction issues.
>
> Insights?

"~/.config/guix/current/…" overrides "~/projects/guix" in %load-path of
Guix REPL, but the problem is that %load-compiled-path does not have the
according .go files as I wrote in the previous message, so the
incompatibility between .scm (from "~/.config/guix/current") and .go
(from "~/projects/guix") led to errors.

I have fixed it in Emacs-Guix:

  
https://notabug.org/alezost/emacs-guix/commit/38a20cefe14969970817de97693c3f0f00b1c099

BTW if you want Emacs-Guix to use Guix modules from your checkout, you
can set it like this:

  (setq guix-load-path "~/projects/guix")

This ↑ setting overrides everything (including the profile populated by
"guix pull").

> But the wrong outdated packaged remained.
>
>> (setq guix-load-path "~/.config/guix/current/share/guile/site/2.2"
>>   guix-load-compiled-path 
>> "~/.config/guix/current/lib/guile/2.2/site-ccache")
>
> This fixes the oudated package issue.

Great, thank you for checking!  I have made a new release (0.4.1.1), so
hopefully it should be OK now :-)

-- 
Alex

Re: [ANN] Emacs-Guix 0.4.1

[Alex Kost]

Pierre Neidhardt (2018-06-28 12:23 +0200) wrote:

> ERROR: In procedure scm-error:
> no code for module (guix build utils)
>
> Is something wrong my setup?

I don't know.  This error looks like guile load paths are not set
correctly.  Could you switch to Guix REPL and check whether %load-path
contains "~/.config/guix/current/share/guile/site/2.2" ?

...Oh, wait, I've just noticed that the mentioned directory contains
only .scm files.  When I experimented with "guix pull", it contained
both .scm and .go files, but now .go files are installed in
"~/.config/guix/current/lib/guile/2.2/site-ccache".  Apparently there
was another more recent change in "guix pull", that I did not notice.

This incompatibility between .scm and .go files may lead to
unpredictable problems, so I think I have to make another release :-)
Thanks for reporting!

To make sure that this is indeed the problem you have, could you please
add the following to you emacs config:

(setq guix-load-path "~/.config/guix/current/share/guile/site/2.2"
  guix-load-compiled-path 
"~/.config/guix/current/lib/guile/2.2/site-ccache")

and check if this fixes the problem you mentioned or not.

-- 
Alex

Re: [ANN] Emacs-Guix 0.4

[Alex Kost]

myg...@gmail.com (2018-05-24 21:02 -0400) wrote:

> Hi Alex,
>
> Thank you for this new release. I am enjoying the cool new features!
>
> On 05/24/2018 at 20:21 Alex Kost writes:
>
> [...]
>
>> I recalled that C-u prefix is already occupied by specifying an
>> arbitrary profile for the package commands.  So, I'm afraid instead of
>> "C-u M-x guix-dependent-packages" there will be "M-x
>> guix-direct-dependent-packages".
>>
>> Or maybe I should just break this dull "convention" (I mean "C-u" for
>> profiles) as probably no one uses it anyway :-)
>
> +1
>
> FWIW, ISTM this use of "C-u" is more global than typical and thus feels
> a bit counter-intuitive. Since you have made it very easy to jump
> between profiles in *Guix Profiles* I think it would be good to switch
> to using "C-u" for more command-specific modifications. This might also
> help avoid "function bloat in emacs-guix."

I agree.  Although I decided to make another solution for this case:
"M-x guix-dependent-packages" will ask you for the "dependent type" in
the minibuffer: "all" (default) or "direct".

-- 
Alex

Re: [ANN] Emacs-Guix 0.4

[Alex Kost]

Ludovic Courtès (2018-05-24 14:16 +0200) wrote:

> Hello!
>
> Alex Kost <alez...@gmail.com> skribis:
>
>> Ludovic Courtès (2018-05-23 17:30 +0200) wrote:
>
> [...]
>
>>> I think ‘guix-dependent-packages’ is going to be very useful.  I wonder
>>> if we could have ‘C-u guix-dependent-packages’ list only packages that
>>> are direct dependents?  That would be helpful in some situations.
>>
>> I agree!  Is there a shell command for this?  I mean I'd like to know
>> what Guile code can do this :-)
>
> No, there’s no such command.  Perhaps something to add to ‘guix refresh
> -l’, say ‘guix refresh -l direct’?

It would be good!

>> Currently, the following code is used to get dependent packages:
>>
>> (with-store store
>>   (run-with-store store
>> (mlet %store-monad ((edges (node-back-edges %bag-node-type
>> (all-packages
>>   (return (node-transitive-edges packages edges)
>
> ‘node-transitive-edges’ traverses the whole DAG, so you should simply
> call ‘edges’ instead.
>
> HTH!

Yes, now it's clear, thanks!

I recalled that C-u prefix is already occupied by specifying an
arbitrary profile for the package commands.  So, I'm afraid instead of
"C-u M-x guix-dependent-packages" there will be "M-x
guix-direct-dependent-packages".

Or maybe I should just break this dull "convention" (I mean "C-u" for
profiles) as probably no one uses it anyway :-)

-- 
Alex

Re: [ANN] Emacs-Guix 0.4

[Alex Kost]

Ludovic Courtès (2018-05-23 17:30 +0200) wrote:

> Hello!
>
> Maxim Cournoyer <maxim.courno...@gmail.com> skribis:
>
>> Alex Kost <alez...@gmail.com> writes:
>>
>>> Hello, Emacs-Guix (Emacs interface for GNU Guix) version 0.4 has been
>>> released.  If you are not familiar with it yet, you may start with:
>>> ‘guix package -i emacs-guix’ and "M-x guix-about".
>>
>> Just wanted to say thank you for this new feature packed release! I look
>> forward to trying it out :)
>
> +1  I just tried it out and these new features are awesome, as usual!
>
> ‘guix-all-services’ is very cool!  (It shows that we lack descriptions
> for roughly a third of the services; if you’re reading along, consider
> helping out.  :-))
>
> I think ‘guix-dependent-packages’ is going to be very useful.  I wonder
> if we could have ‘C-u guix-dependent-packages’ list only packages that
> are direct dependents?  That would be helpful in some situations.

I agree!  Is there a shell command for this?  I mean I'd like to know
what Guile code can do this :-)

Currently, the following code is used to get dependent packages:

(with-store store
  (run-with-store store
(mlet %store-monad ((edges (node-back-edges %bag-node-type
(all-packages
  (return (node-transitive-edges packages edges)

-- 
Alex

[ANN] Emacs-Guix 0.4

[Alex Kost]

Hello, Emacs-Guix (Emacs interface for GNU Guix) version 0.4 has been
released.  If you are not familiar with it yet, you may start with:
‘guix package -i emacs-guix’ and "M-x guix-about".

Summary of the new features:

* Interface to display services

  It is very similar to the interface for packages: the following
  commands will show you a list of services, where you can press RET to
  get more info about the current (or marked) service(s).  The new
  commands are:

- M-x guix-all-services
- M-x guix-default-services
- M-x guix-services-by-name
- M-x guix-services-by-regexp
- M-x guix-services-by-location

  "M-x guix-default-services" allows you to look at %base-services and
  %desktop-services.

  You may look at the screenshot for this new interface here:

https://alezost.github.io/guix.el/images/screenshots/services.png

  Also, similarly to "M-x guix-package-locations" (renamed from "M-x
  guix-locations"), now there is:

- M-x guix-service-locations

  (Now there are so many commands that even "M-x guix-help" may look
  terrifying :-))

* Additions for 'guix-devel-mode'

  - [C-c . '] key binding (‘guix-devel-code-block-edit’ command) allows
you to edit synopsis or description of the current package in the
texinfo-mode.  This feature is very similarly to the org-mode
[C-c '] facility.

  - If you add the following code to your .emacs, you'll be able to find
package patches with "M-x ffap":

  (add-to-list 'ffap-alist '("\\.patch" . guix-devel-ffap-patch))

* guix-env-var-mode

  When you build a package with ‘guix build --keep-failed’, you can find
  "/tmp/guix-build-*-*.drv-*/environment-variables" file which is now
  prettified with ‘guix-env-var-mode’: it is the same as ‘sh-mode’ but
  it also reformats the buffer to make the long guix file names more
  readable.

* M-x guix-dependent-packages

  It displays packages that depend on the specified package(s); this is
  analogous to ‘guix refresh --list-dependent’ shell command.

* M-x guix-number-of-packages

  It just displays the total number of Guix packages (including the
  packages placed in your GUIX_PACKAGE_PATH) in the minibuffer.

* M-x guix-report-bug

  Similarly, to "M-x report-emacs-bug", it prompts for a bug subject and
  opens a mail buffer with  address, and that's all.

* Performance improvements

  You probably noticed that "M-x guix-all-available-packages" was very
  slow (it could even fail on not-so-powerful machines).  This slowness
  happened when big chunks of data were passed from the "Guile side" to
  "Emacs side" through Geiser (the problem may not be Geiser itself, but
  some underlying Emacs code).  Anyway, now the big portions of guile
  data are passed through a temporary file instead, and it is much
  faster!

Many thanks to Pierre Neidhardt for the idea of ‘guix-report-bug’ and
‘guix-dependent-packages’ commands, and all credits to Oleg Pykhalov for
inventing and implementing ‘guix-env-var-mode’ and the new features for
‘guix-devel-mode’ (synopsis/description editing and finding a patch with
ffap).

-- 
Alex

Re: Font installed in non-default profile doesn't appear.

[Alex Kost]

Hello George,

George Clemmer (2018-05-08 20:04 -0400) wrote:

> In a "headless" vm-image (sysi29.scm, attached), "font-dejavu" installed
> by manifest (attached) into the "empty" default profile ...
>
> 'guix package -m manifest'
>
> ... appears in the emacs 'M-x menu-set-font' choice box. But it doesn't
> appear with the same manifest installed in the "foo" profile ...

To make fonts available from a non-standard profile I added the
following line into my "~/config/fontconfig/fonts.conf":

  ~/path-to-my-profile/share/fonts

-- 
Alex

Re: warning: could not locate elisp directory under `/gnu/store/...`

[Alex Kost]

Pierre Neidhardt (2018-04-08 22:27 +0530) wrote:

Hello, Pierre!

> I'm down to write my first Emacs package declaration (attached).
> It seems quite straightforward and yet it fails to byte-compile:
[...]
> What am I missing?

Probably nothing.  I have just tried your package recipe and *.el files
have been successfully compiled for me (on the latest guix checkout).  I
noticed there were multiple changes in the 'emacs-build-system' lately,
so perhaps you just tried to build your package in a "wrong" time :-)

So I think your package is OK.  Could you just do "guix pull" and
rebuild it?

-- 
Alex

Re: Guix does not understand config.scm

[Alex Kost]

Jone (2018-04-23 19:22 +) wrote:

> This is my new (and wrong) config:
[...]
> 56  (sudoers-file (local-file (config-file "/etc/sudoers")))

He-he, I recognize this :-)
I guess you took this line from my os config, anyway...

> Next I run 'guix system reconfigure new.scm':
>
>new.scm:49:9: config-file: unbound variable
>hint: Did you forget a `use-modules' form?

... this means that you did not define 'config-file'.

'config-file' is a simple function I use to return file names from my
"~/config" directory, i.e.:

  (config-file "/etc/sudoers")  returns  "/home//config/etc/sudoers"

So if you want to specify sudoers file, you can just use:

  (sudoers-file (local-file "/path/to/your/sudoers-file"))

-- 
Alex

Re: pcspkr only loaded after waking up from sleep

[Alex Kost]

Pierre Neidhardt (2018-04-18 23:54 +0530) wrote:

> Alex Kost <alez...@gmail.com> writes:
>
>>>   (kernel-arguments '("modprobe.blacklist=pcspkr"))
>>
>> Yes, it is.  I recall I also needed to blacklist "snd_pcsp" module to get
>> rid of this annoying beep (so I have "modprobe.blacklist=pcspkr,snd_pcsp");
>> although it was several years ago, maybe it is not necessary anymore.
>
> Thanks!  Any idea why the module does not load properly at boot time?

Sorry, no idea :-)

-- 
Alex

Re: pcspkr only loaded after waking up from sleep

[Alex Kost]

Pierre Neidhardt (2018-04-18 14:00 +0530) wrote:

> Anyways, I'd like to turn it off for good.  Is the following the right
> way to go?
>
>   (kernel-arguments '("modprobe.blacklist=pcspkr"))

Yes, it is.  I recall I also needed to blacklist "snd_pcsp" module to get
rid of this annoying beep (so I have "modprobe.blacklist=pcspkr,snd_pcsp");
although it was several years ago, maybe it is not necessary anymore.

-- 
Alex

Re: Missing glibc man pages?

[Alex Kost]

Pierre Neidhardt (2018-04-18 12:00 +0530) wrote:

> I've installed the `glibc` package in my user profile, but I cannot find
> the man pages of `ldd`, `ldconfig`, etc.  Is it an oversight?

They are placed in 'man-pages' package.

-- 
Alex

Re: Missing pinentry-emacs for gpg-agent?

[Alex Kost]

Ludovic Courtès (2018-03-27 11:53 +0200) wrote:

> Pierre Neidhardt  skribis:
>
>> Somewhat surprisingly, pinentry-emacs does not seem to be in the repo.
>> Is it intentional?  I'd love to have it back.
>
> I didn’t know its existence.  :-)
>
> Please do submit a package!
>
>   https://www.gnu.org/software/guix/manual/html_node/Submitting-Patches.html
>
>> On a related topic, is it possible to share a gpg-agent.conf between a
>> Guix-based system and another system?
>> What I mean here is that the following line in gpg-agent.conf:
>>
>>  pinentry-program /home/ambrevar/.guix-profile/bin/pinentry
>>
>> won't work on other systems (/usr/bin/pinentry on other systems is
>> somewhat more universal, but hey...).
>
> I can’t think of any solution to that problem… apart from installing
> Guix on the other systems.  :-)

I use another solution: I just run "gpg-agent" with "--pinentry-program"
option (instead of adding "pinentry-program ..." line to the conf-file).

-- 
Alex

Re: Emacs in multiple profiles

[Alex Kost]

Konrad Hinsen (2018-03-26 10:24 +0200) wrote:

> Alex Kost <alez...@gmail.com> writes:
>
>> But what your "current profile" is?  How can emacs know about it?  It
>> "knows" only about the default (system and user) profiles.  So if you
>
> I'd say Emacs knows nothing at all about profiles. It's Guix that
> manages profiles for everyone else, be it bash, Python, or Emacs. To get
> the behavior that I expected, Guix would have to define and manage an
> environment variable, let's call it EMACS_PATH, which would be used in
> site-start.el.
>
> What I cannot judge is how much effort it would be to implement such a
> feature, and if it could have undesirable side-effects.

As for me, I think the current behaviour (looking for packages only in
the user and the system profiles) is the right one.  If you want to
auto-load emacs packages from some non-standard profiles, you can easily
do this on your own (as I showed in the previous message).

Anyway, if you think that some feature is missing, I would recommend to
send a message to <bug-g...@gnu.org> about it.  Perhaps other people
will agree with your point.

-- 
Alex

Re: Emacs in multiple profiles

[Alex Kost]

Konrad Hinsen (2018-03-24 13:14 +0100) wrote:

> Alex Kost <alez...@gmail.com> writes:
>
>> It is completely different: with "-Q", your .emacs file is not loaded at
>> all, and with "--no-site-file", only the emacs packages from the guix
>> profile are not autoloaded.  Isn't that what you wanted?
>
> Not quite: I want it to autoload the packages from my current Guix
> profile, not from my main Guix profile.

But what your "current profile" is?  How can emacs know about it?  It
"knows" only about the default (system and user) profiles.  So if you
wish to load packages from non-standard profiles, you need to do it on
your own (as I showed below).

>> If you want to autoload emacs packages from a guix environment (or
>> similarly from any non-standard guix profile), you can do it like this:
>>
>> (let ((guix-env (getenv "GUIX_ENVIRONMENT")))
>>   (when (and guix-env
>>  (require 'guix-emacs nil t))
>> (guix-emacs-autoload-packages guix-env)))
>
> Except that GUIX_ENVIRONMENT is defined only by "guix environment", not
> by profiles. Otherwise this would be exactly what I want - and in fact
> what I'd expect guix-emacs.el to do, instead of accessing the user's
> main profile.

Again, I don't understand how emacs could guess in what profile you
installed your emacs packages, so it just autoloads whatever is found in
the system and user profile.

So for your situation, you can just run emacs with --no-site-file option
and put a code like this in your emacs config file:

(when (require 'guix-emacs nil t)
  (guix-emacs-autoload-packages "/path/to/your/profile"))

-- 
Alex

Re: Emacs in multiple profiles

[Alex Kost]

Konrad Hinsen (2018-03-23 08:57 +0100) wrote:

> Hi Alex,
>
> Alex Kost <alez...@gmail.com> writes:
>
>>> Since nothing runs before site-start.el, I don't see how I could
>>> override this definition. My only choice is to use the -Q option on the
>>> Emacs command line to bypass site-start.el altogether. But then I don't
>>> get the packages from my new profile either.
>>
>> It's not the only choice.  You can also use "--no-site-file".  It is
>> also mentioned at:
>>
>> https://www.gnu.org/software/guix/manual/html_node/Application-Setup.html#Emacs-Packages
>
> Right, but that's not very different from -Q:

It is completely different: with "-Q", your .emacs file is not loaded at
all, and with "--no-site-file", only the emacs packages from the guix
profile are not autoloaded.  Isn't that what you wanted?

> I get no start-site at all
> and thus none of the Guix-installed packages. What I am looking for is a
> way to get the packages that I put into the profile from which I started
> Emacs.
>
> I suspect that this could only be done via some environment variable,
> analogous $PATH and others. Emacs doesn't consult any such variable, and
> it seems that Guix didn't introduce one either. At least I didn't find
> any.

If you want to autoload emacs packages from a guix environment (or
similarly from any non-standard guix profile), you can do it like this:

(let ((guix-env (getenv "GUIX_ENVIRONMENT")))
  (when (and guix-env
 (require 'guix-emacs nil t))
(guix-emacs-autoload-packages guix-env)))

> Is this a decision made for a good reason, or just something "to be
> done"?

Sorry, I don't understand your use case (I think I just didn't read your
message carefully enough), but if you think there is something to be
done, please tell.

-- 
Alex

Re: Modify system behavior after reconfigure

[Alex Kost]

Jone (2018-03-20 23:12 +0300) wrote:

>> If you want, you can write in one of the other languages that
>> developers speak:
>
> Хорошо, Ludo’, я пишу на своем языке. У меня куча вопросов, но к
> сожалению мануалы GNU не являются "быстрорастворимыми". А кроме
> мануалов любая другая документация с примерами ("howto") отсутствует!

Действительно, никакой другой официальной документации кроме мануала
нет, и это, в общем, политика Guix: "если что-то нуждается в
документировании, то это должно быть в мануале" (ну, что-то в этом
духе). Так что, как сказал Олег, если вам что-либо не понятно,
пожалуйста, спрашивайте и не стесняйтесь сообщить, если считаете, что
что-нибудь в мануале должно быть улучшено/исправлено/дополнено.

Создание же отдельных "howto" или wiki не планируется, хотя есть
несколько неофициальных источников, например:

https://gitlab.com/rain1/guix-wiki/wikis/home
https://gitlab.com/pjotrp/guix-notes


Concise translation: Jone said that the manual is not an easy read and
unfortunately there are no HOWTOs.  Oleg and I answered that the manual
is indeed the only official source of documentation and people are
always welcome to improve it in any way.

-- 
Alex

Re: Posts in languages other than English on help-guix?

[Alex Kost]

Oleg Pykhalov (2018-03-07 12:46 +0300) wrote:

> Hello Ludovic and Guix,
>
> l...@gnu.org (Ludovic Courtès) writes:
[...]
>> +`(("en"
>> +   "Subscribe to the Help mailing list to get support from the GuixSD
>> +and GNU Guix community via email.  You can post messages in English though 
>> we
>> +also accept other languages.")
>
>   ("ru"
>"Подпишитесь на список рассылки «Help», чтобы получить помощь от
> сообществ GuixSD и GNU Guix по электронной почте.  Вы можете писать на русском
  ^

I would write "сообщества" here (in a singular form, not the plural one)
as there is a single GuixSD and GNU Guix community, not 2 separate
communities.

> языке.")

-- 
Alex

Re: Error system reconfigure with guix-latest

[Alex Kost]

Jone (2018-03-04 15:46 +0300) wrote:

> Hello!
> I'm newbie. After update system (guix pull) I see this error:
>
> root@guix ~# guix system -n reconfigure /etc/CURRENT.scm
> /etc/CURRENT.scm:37:24: error: you need these modules in the initrd
> for /dev/sdb2: sata_nv pata_acpi

As 宋文武 pointed, you can use 'initrd-modules' now.  To make it clear,
you need to replace this:

>   (initrd (lambda (file-systems . rest)
>   (apply base-initrd file-systems
>         #:extra-modules '("sata_nv" "pata_acpi")
>         rest)))

with this:

  (initrd-modules (cons* "sata_nv" "pata_acpi" %base-initrd-modules))

-- 
Alex

Re: [ANN] Emacs-Guix 0.3.4

[Alex Kost]

Ludovic Courtès (2018-01-08 15:57 +0100) wrote:

[...]
> I have a minor issue: I use ‘ido’ and ‘ido-find-file’ insist on browsing
> the entire /gnu/store when I do C-x C-f with a store file name at point
> (except if the file name denotes a directory.)

I'm not sure I understand your problem.  I think ido-find-file prompts
with "/gnu/store" directory just because you do "C-x C-f" from a buffer
which 'default-directory' variable is set to "/gnu/store".

I don't think ido checks a file name at point, at least it doesn't by
default: I've tried (with "emacs -Q" and ido-mode enabled) to do "C-x
C-f" on a store file, and I got a propmt with files from the current
directory (not from /gnu/store as you describe).

> So to open a .drv file, I have to work around that.

Sorry, I don't understand what you mean.  As other people point, if you
have a drv file at point, you may open it with "M-x ffap".  If you wish
to open a store file from 'guix-derivation-mode', you can just press RET
on it.

-- 
Alex

Re: [ANN] Emacs-Guix 0.3.4

[Alex Kost]

Oleg Pykhalov (2017-12-29 20:44 +0300) wrote:

> Hello Alex, Guix
>
> Alex Kost <alez...@gmail.com> writes:
>
>> Hello, Emacs-Guix (Emacs interface for GNU Guix) version 0.3.4 has been
>> released.  It may be installed with "guix package -i emacs-guix".
>>
>> The main new features are:
>
> By the way, 'guix-edit' supports a new behavior:
>
> Read symbol at point and if it is a package name, return it.  If it
> is not a package name or if current command has a prefix argument,
> read the name from minibuffer.
>
> (from 'guix-read-package-name-at-point' documentation string).

Oh, right, I forgot about it, sorry :-)

(this feature is also the Oleg's idea)

>> 1. "M-x guix-hash": it prompts for a file, calculates its hash and puts
>>it into kill-ring (i.e., you can insert it with "C-y").  If it is
>>called on a directory, it ignores VCS files (like "guix hash
>>--recursive --exclude-vcs").  Also it supports dired-mode.  Thanks to
>>ng0 for the idea of this command!
>
> I like this, but as I undertand it works only with files or directories
> locally.

Yes, it is the analog of "guix hash", so it works with local files only.

> Could we do something like:
>
> (defun guix-download (url)
>   (interactive "sDownload URL: ")
>   (insert (shell-command-to-string (concat "guix download "
>url
>" 2>/dev/null"
>"| tail -n 1"
>"| tr -d '\n'"
>
> which will download a thing and paste a hash at the cursor position.

I wouldn't like to have such a wrapper for a shell command as using
"Guix REPL" would be faster.  Although the main problem is: what you
suggest is a *synchronous* command, and downloading files may take a
long time, so Emacs will become unresponsive until the file will be
downloaded and its hash will be calculated.

> We have a 'guix-devel-download-package-source', but it basically the
> same as a shell command 'guix download PACKAGE' which requires to copy
> hash manually.  What we probably want is to get a hash into Emacs
> kill-ring as guix-hash does.

I don't see how this can be done.  Is it OK for you that this
downloading will happen synchronously?  Or do you have ideas how it can
be implemented otherwise?

-- 
Alex

[ANN] Emacs-Guix 0.3.4

[Alex Kost]

Hello, Emacs-Guix (Emacs interface for GNU Guix) version 0.3.4 has been
released.  It may be installed with "guix package -i emacs-guix".

The main new features are:

1. "M-x guix-hash": it prompts for a file, calculates its hash and puts
   it into kill-ring (i.e., you can insert it with "C-y").  If it is
   called on a directory, it ignores VCS files (like "guix hash
   --recursive --exclude-vcs").  Also it supports dired-mode.  Thanks to
   ng0 for the idea of this command!

2. "M-x guix-derivation-mode": this major mode makes Guix derivations
   more human readable by indenting them and by making buttons from the
   store file names.  It is enabled automatically in "/gnu/store/….drv"
   files.  Many thanks to Oleg Pykhalov for inventing and implementing
   this feature!

3. As you probably know there are many single-line Guile files in the
   store, for example:

 /gnu/store/…-shepherd.conf
 /gnu/store/…-activate-service
 /var/guix/profiles/system/boot

   Similarly to the derivation files, the above files are not human
   readable as they are one-liners.  Now (I mean with Emacs-Guix 0.3.4),
   whenever you open such a file, it will be re-indented (its buffer,
   not the file itself!) and scheme-mode will be enabled there.

4. "M-x guix-superseded-packages": well, it just displays a list of
   superseded packages.

Happy Guix Year :-)

-- 
Alex

Re: Guix upgrade leads to different hashes

[Alex Kost]

Oleg Pykhalov (2017-10-02 05:15 +0300) wrote:

> Hello Guix,
>
> Something strange happens on my machine with upgrades.  I check for new
> available upgrades with dry-run and get “available upgrades” all the
> time.
[...]
> If I upgrade again I'll get same hashes as in “Check upgrades.”.  Like a
> loop.  It's not related to grafts, is it?

It is: since commit fd59105c4¹, --dry-run also disables grafts, so
using just "--dry-run" is the same as "--dry-run --no-grafts".  It was
discussed in the following thread:

  http://lists.gnu.org/archive/html/guix-devel/2016-07/msg01035.html

¹ 
http://git.savannah.gnu.org/cgit/guix.git/commit/?id=fd59105c49965db956fac73c68d8b00d068f5d5c

-- 
Alex

Re: Which Emacs version used to build Emacs packages with emacs-checkout?

[Alex Kost]

Oleg Pykhalov (2017-09-22 16:49 +0300) wrote:

> Hello Alex,
Hi!

> Alex Kost <alez...@gmail.com> writes:
[...]
>> Yes.  Note that this default emacs can be overrided on a package level
>> by using #:emacs keyword in the arguments.  See 'emacs-auctex' package
>> for example.
>
> Ah, this is bad for me.  Now I need to redefine all those “#:emacs
> ,emacs” to “#:emacs ,emacs-checkout” as I guess.  Or I need to redefine
> “emacs” variable instead of inherit it in “emacs-checkout”.

I think making your packages with #:emacs argument is the right way.
And it is not so bad as it may seem, as you can use some Guile code to
reduce the duplication.  For example, look at the attached file: it
shows how you may inherit the packages you need from the original emacs
packages.  To check it, put it into your GUIX_PACKAGE_PATH and call
"guix package --show=my-emacs-paredit".  This is just an example, but I
think you get the idea ;-)

> I want to have Emacs builded from my local Git repository.  And I also
> want Emacs packages builded with this my Emacs version.

Actually, why do you want to do this?  I mean it doesn't matter what
version of Emacs you use to compile .el files.  There is no difference:
if you build a package with Emacs 24 it will still work with Emacs 26.

(define-module (my-emacs)
  #:use-module (guix packages)
  #:use-module (guix utils)
  #:use-module (gnu packages emacs))

(define-syntax-rule (define-my-packages (var-name pkg) ...)
  (begin
(define-public var-name
  (package (inherit pkg)
(name (string-append "my-" (package-name pkg)))
(arguments
 (cons* #:emacs emacs-no-x
(package-arguments pkg)
...))

(define-my-packages
  (my-emacs-ag emacs-ag)
  (my-paredit paredit)
  (my-smex emacs-smex)
  ;; ...and the other packages you need.
  )

Re: Which Emacs version used to build Emacs packages with emacs-checkout?

[Alex Kost]

Oleg Pykhalov (2017-09-07 21:49 +0300) wrote:

> Hello Guix,
>
> Here is a =emacs-checkout= snippet which works for me.  Enjoy it if
> somebody need it.
>
> I'm little bit confused about Emacs **version** that is used inside
> =emacs-build-systems= and inputs which use =emacs-minimal=.
>
> If I define a new package with =-checkout= suffix and install it, for
> example =guix package -i emacs@26.0.50-1.f0eb70d= it works fine.
>
> As I notice all packages which uses =emacs-build-system= will use
> original Guix Emacs version package.  Am I right?

Right, by default 'emacs-build-system' uses the current 'emacs-minimal'
package.

> Then, all Emacs packages will be build by =emacs-minimal= which is
> original Guix Emacs version.

Yes.  Note that this default emacs can be overrided on a package level
by using #:emacs keyword in the arguments.  See 'emacs-auctex' package
for example.

> I found =(setq load-prefer-newer t)= way to avoid loading old compiled
> elisp files, but it's not what I really want.

This (I mean 'load-prefer-newer') is one of my favourite setting :-)
But it is not clear for me, what do you really want?

> Thoughts?  :-)

Sorry, but I don't understand what you are asking about :-)

-- 
Alex

[ANN] Emacs-Guix 0.3.3

[Alex Kost]

Hello, I have released Emacs-Guix (Emacs interface for GNU Guix) version
0.3.3, and updated 'emacs-guix' Guix package.

This release provides some small bug fixes and tweaks to keep it in-sync
with the current Guix code-base.  Also, it provides 2 new features:

1. A way to look at "search paths" environment variables:

   In "M-x guix-profiles" you can press "E" key to see the analog of:

 guix package --search-paths=... --profile=...

   (You can mark several profiles with "m" key before pressing "E" to see
   the combined search paths).

   Analogously, you can press "E" in a list of generations (for example,
   in "M-x guix-generations").

2. The new "info" interface for profiles: Press "RET" (or "i") in the
   list of profiles to see it.  Nothing fancy there; similarly to
   "Generation Info", it is just an alternative way to look at available
   functionality for profiles.

-- 
Alex

Re: Tip of the day: storing your GuixSD config in the instantiated system

[Alex Kost]

Ludovic Courtès (2017-08-28 14:04 +0200) wrote:

> Hi Mekeor,
>
> (I think you forgot to Cc: the list.)
>
> Mekeor Melire  skribis:
>
>> Ludovic Courtès  writes:
>>
>>> Hello Guix!
>>>
>>> Following a discussion we had at the GHM today, here’s the tip of the
>>> day!
>>
>> Greetings to everyone at GHM!
>>
>>> But wait: we can already store the config file in the instantiated
>>> system!  Here’s how:
>>>
>>>   (operating-system
>>> ;; …
>>> (services (cons (simple-service 'store-my-config
>>> etc-service-type
>>> `(("config.scm"
>>>,(local-file (assoc-ref
>>>  
>>> (current-source-location)
>>>  'filename)
>>> …)))
>>>
>>> You instantiate that, and then /etc/config.scm (aka.
>>> /run/current-system/etc/config.scm,
>>> aka. /var/guix/profiles/system/etc/config.scm) contains the config file.
>>
>> Because of the frequent demand for it, I think it would make sense to
>> offer this as pre-defined service by default, as part of Guix itself.
>> What do you think?

I was going to write the same: I also think it would be good to make
this service the default one, so that we can always point a user to the
system config the current system was reconfigured with.

-- 
Alex

Re: Tip of the day: storing your GuixSD config in the instantiated system

[Alex Kost]

Ludovic Courtès (2017-08-25 22:27 +0200) wrote:

> Hello Guix!
>
> Following a discussion we had at the GHM today, here’s the tip of the day!
>
> People often ask how they could store their GuixSD config alongside the
> instantiated system in the store.  Guix maintainers usually grumpily
> reply “nah, don’t do this, because the config file is not
> self-contained, so that’s not good enough.”
>
> But wait: we can already store the config file in the instantiated
> system!  Here’s how:
>
>   (operating-system
> ;; …
> (services (cons (simple-service 'store-my-config
> etc-service-type
> `(("config.scm"
>,(local-file (assoc-ref
>  (current-source-location)
>  'filename)
> …)))
>
> You instantiate that, and then /etc/config.scm (aka.
> /run/current-system/etc/config.scm,
> aka. /var/guix/profiles/system/etc/config.scm) contains the config file.
>
> Pretty neat no?

Nice tip indeed, thanks!

-- 
Alex

Re: xawtv: no font found

[Alex Kost]

Dmitry Nikolaev (2017-08-26 22:25 +0300) wrote:

> Hello. I wrote a package file for Xawtv. It builds, but not runs.
>
> $ xawtv
> xawtv: Relink `/gnu/store/
> 88wvqp60hbrdvbp0xsqad5c6njjfshcw-libpng-1.6.28/lib/libpng16.so.16'
> with `/gnu/store/ybpgv1v7606xw7mafda66w10hiynpiw2-glibc-2.25/lib/
> libpthread.so.0' for IFUNC symbol `longjmp'
> xawtv: Relink `/gnu/store/
> 2sq8w3x8glbjlfn22im6nwwycmbdlzws-freetype-2.7.1/lib/libfreetype.so.6'
> with `/gnu/store/ybpgv1v7606xw7mafda66w10hiynpiw2-glibc-2.25/lib/
> libpthread.so.0' for IFUNC symbol `longjmp'
> This is xawtv-3.103, running on Linux/x86_64 (4.11.12)
> vid-open-auto: using grabber/webcam device /dev/video0
> Warning: Unable to load any usable ISO8859 font
> Warning: Missing charsets in String to FontSet conversion
> Error: Aborting: no font found
>
>
> What should I do to solve this issue? How to tell xawtv about any
> usable font?

I don't know but I looked at nix package and I don't see anything
specific there:

  
https://github.com/NixOS/nixpkgs/blob/master/pkgs/applications/video/xawtv/default.nix

Perhaps you just missed some dependencies? ('fontsproto' maybe)

-- 
Alex

Re: I need examples of Shepherd services without GuixSD

[Alex Kost]

ng0 (2017-08-20 13:35 +) wrote:

> As IRC wasn't very responsive:
>
> Does someone of you keep their Shepherd user-services, for shepherd running on
> non-GuixSD systems (side by side with systemd for example), online somewhere?

I have my Shepherd user config at
, but it is rather
complicated and too specialized for my needs, I'm not sure if it may be
helpful for anyone else.

David also has his config available:

  
https://git.dthompson.us/dotfiles.git/blob/HEAD:/dotfiles/.config/shepherd/init.scm

But why do you ask specifically about non-GuixSD system?  AFAICT there
is absolutely no difference whether you run a user shepherd under GuixSD
or non-GuixSD system (I use my config on both GuixSD and ArchLinux).

-- 
Alex

Re: overriding essential-services

[Alex Kost]

Ricardo Wurmus (2017-08-15 22:05 +0200) wrote:

> Alex Kost <alez...@gmail.com> writes:
>
>> Ricardo Wurmus (2017-08-11 22:26 +0200) wrote:
>>
>>> Hi Guix,
>>>
>>> I want to make sure that /etc/environment includes GUILE_LOAD_PATH and
>>> GUILE_LOAD_COMPILED_PATH, because that’s needed for offloading.
>>> “/etc/environment” is created by the “session-environment-service”
>>> service, which is part of “essential-services”.  It is not part of
>>> %base-services, so I cannot catch it with “modify-services” and extend
>>> it.
>>>
>>> How would I go about extending it?
>>
>> There is probably no convenient way now.
>>
>>> For now I’ll use ~/.ssh/environment and “PermitUserEnvironment=yes”, but
>>> I think it would anyway be good to have a mechanism to easily change the
>>> contents of /etc/environment.
>>
>> IFIUC the intention of <https://bugs.gnu.org/27155> is to provide the
>> extension facility for any service.
>
> I don’t know… I never quite warmed up to the implementation.  It looks
> much too powerful for something as simple as e.g. overwriting
> /etc/environment.
>
> Maybe “session-environment-service-type” is an outlier here anyway.  I
> see the utility of 27155 for the other services, but using it for
> “session-environment-service-type” really seems wrong.  Maybe we can
> move it to %base-services?
>
> And maybe we could avoid essential-services altogether and make these
> services explicit, so that they can be modified with “modify-services”.
> Right now they are special in that they are always added to whatever
> services the user defines.

I agree!  I always vote for providing users a freedom to shoot
themselves in their feet.  The more ways to customize various aspects of
a system there are, the better.  So I think that moving as much services
as possible (from essential-services to base-services) would be great.

-- 
Alex

Re: overriding essential-services

[Alex Kost]

Ricardo Wurmus (2017-08-11 22:26 +0200) wrote:

> Hi Guix,
>
> I want to make sure that /etc/environment includes GUILE_LOAD_PATH and
> GUILE_LOAD_COMPILED_PATH, because that’s needed for offloading.
> “/etc/environment” is created by the “session-environment-service”
> service, which is part of “essential-services”.  It is not part of
> %base-services, so I cannot catch it with “modify-services” and extend
> it.
>
> How would I go about extending it?

There is probably no convenient way now.

> For now I’ll use ~/.ssh/environment and “PermitUserEnvironment=yes”, but
> I think it would anyway be good to have a mechanism to easily change the
> contents of /etc/environment.

IFIUC the intention of  is to provide the
extension facility for any service.

-- 
Alex

Re: Manual pages for glibc.

[Alex Kost]

Roel Janssen (2017-08-09 10:49 +0200) wrote:

> Dear Guix,
>
> Which package do I need to install to be able to read the man pages of
> functions in glibc like 'snprintf' and 'malloc'?

Many man pages (including 'snprintf' and 'malloc') come with 'man-pages'
package.

-- 
Alex

[ANN] Emacs-Guix 0.3.2

[Alex Kost]

Hello, Emacs-Guix (Emacs interface for GNU Guix) has been updated to
version 0.3.2.  It can be installed with:

  guix package -i emacs-guix

This release was done to be consistent with the latest Guix code (see
technical details below if you are interested). If you did "guix pull"
recently, you may get an error like this:

  Invalid read syntax: "#"

if you try to get a list of packages.  So if you see this error, it's
time to update Emacs-Guix :-)

Above that, there is only one new "feature": the new key bindings in
*Guix Package Info* buffer.  These keys are similar to the keys in *Guix
Packages* buffer, and they are just "shortcuts" that you can use instead
of pressing buttons in "Package Info".

See (info "(emacs-guix) Package Keys") in the Emacs info manual or:

  
https://alezost.github.io/guix.el/manual/0.3.2/html_node/Package-Keys.html#Info-Buffer

to learn about these keys (btw, you can press "h" in almost any Guix
buffer to get a "hint" with the keys).

Now about the "breaking" change in Guix: In the past,
'manifest-entry-dependencies' procedure returned a list of file names,
and now¹, it returns a list of manifest entries.  This change caused an
error during parsing an output from the scheme side in Emacs-Guix.  This
is fixed² in the new release.

¹ 
http://git.savannah.gnu.org/cgit/guix.git/commit/?id=55b4715fd4c03e46501f123c5c9bc6072edf12a4
² 
https://github.com/alezost/guix.el/commit/f4b0d8d83bad30b99a919639b387189350c6fc62

-- 
Alex

Re: Using tramp with guixsd install image

[Alex Kost]

Divan Santana (2017-06-30 22:15 +0200) wrote:

> Hi,
>
> Trying to use my emacs (on arch linux) with the guixsd system from the
> 0.13 image and ssh-daemon. By image, this is a fresh VM booted
> guixsd-usb-install-0.13.0.x86_64-linux and about to install guixsd .
>
> This Used to work with 0.12 image.
>
> Now I have this set
>
>   ;; ;; TRAMP and guix settings
>   (setq tramp-default-method "scp")
>   ;; https://lists.gnu.org/archive/html/help-guix/2016-10/msg00049.html
>   (setq tramp-remote-path
> (append tramp-remote-path
> '("~/.guix-profile/bin" "~/.guix-profile/sbin"
>   "/run/current-system/profile/bin"
>   "/run/current-system/profile/sbin")))

With this ^^^ your additional paths are "shadowed" by the default
value of 'tramp-remote-path'.  Try to make it reverse:

   (setq tramp-remote-path
 (append '("~/.guix-profile/bin" "~/.guix-profile/sbin"
   "/run/current-system/profile/bin"
   "/run/current-system/profile/sbin")
 tramp-remote-path))

However I don't think you need to set all these paths manually.

The different behavior between 0.12 and 0.13 may be caused by this
commit:

  
http://git.savannah.gnu.org/cgit/guix.git/commit/?id=dc7010911dd3285fe9089352e92c77501595d100

i.e. your problem may occur because 'tramp-default-remote-path' is the
first element of 'tramp-remote-path' variable now.

> How can one configure tramp to work without the above hack?

I don't know if it will help you or not, but here is the setting I have
in my emacs config, which works for me for years:

(with-eval-after-load 'tramp-sh
  (push 'tramp-own-remote-path tramp-remote-path))

-- 
Alex

Re: failed to resolve partition “my-root”

[Alex Kost]

Ludovic Courtès (2017-06-29 16:33 +0200) wrote:

> Marius Bakke  skribis:
>
>> Maybe we could add all disk drivers to the base initrd image?
>>
>> $ du -h $(guix build linux-libre 
>> 2>/dev/null)/lib/modules/*/kernel/drivers/ata
>> 1.3M
>> /gnu/store/b7nk7glwlrjk8fnw4g7zylzlx7g2f6jd-linux-libre-4.11.6/lib/modules/4.11.6-gnu/kernel/drivers/ata
>>
>> That doesn't sound too much to me and will save many users some trouble.
>
> Maybe not “all” because it’s a moving target, but at least “some”.

I vote for adding "sata_nv".  It is also required for my computer.  And
as Ricardo, I had a hard time trying to figure out why I get:

  waiting for partition 'root' to appear

Also I recall there was another person who had the same problem (missing
"sata_nv" module).  There was a conversation on the subject here:

  https://gnunet.org/bot/log/guix/2015-05-30#T666910

A missing kernel module required for HDD, may be the end of the game for
most users who want to try GuixSD, so I think we should add such modules
by default.  I don't know what else is missing, but "sata_nv" looks like
a good candidate to be added.

-- 
Alex

Re: Unable to use Aspell installed via Guix

[Alex Kost]

Niall Dooley (2017-05-06 15:49 +0200) wrote:

[...]
> Do I have to explicitly install the Aspell dictionaries?

Yes, do this (or with any other dict you need):

  guix package -i aspell-dict-en

-- 
Alex

[ANN] Emacs-Guix 0.3.1

[Alex Kost]

Hello, Emacs-Guix (Emacs interface for GNU Guix) has been updated to
version 0.3.1.  It can be installed with:

  guix package -i emacs-guix

This release was done mostly to be consistent with some recent changes
in Guix (introduced since Guix 0.12.0 release), i.e. to keep "M-x guix"
keys up-to-date and to add some 'guix' completions for "M-x shell".

There are only 2 new commands:

1. "M-x guix-info": it opens Emacs-Guix info manual (with C-u, it opens
   the Guix manual).  Thanks to George Clemmer (aka myglc2) for
   suggesting this command.

2. "M-x guix-services-from-system-config-file": well, this command is
   rather useless at the current state, as it just shows a list of
   services (for a specified "config.scm") and nothing more.

BTW, if you don't like to read "info", Emacs-Guix manual is available
online now:

  https://alezost.github.io/guix.el/manual/latest/html_node/index.html

Many thanks to George for the huge help with this task!

-- 
Alex

Re: is it me ?

[Alex Kost]

Catonano (2017-05-01 13:11 +0200) wrote:

> Recently I've been suggested to look at the definition o scmutils as
> a reference
>
> I made a really short screencast about how a a procedure in there is
> not browsable with geiser.

As myglc2 noted "make-img" is just a variable defined in that "let*".
It is not some Guix procedure, it's a local variable that has a string
value (which is "echo ...").

OTOH, there is some build-side code as Ludovic mentioned that can be
browsable with Geiser.  For example, to be able to “edit”
‘with-directory-excursion’ thing, at first you need to evaluate
‘,use (guix build utils)’ in the REPL.


BTW there is a quicker way to move to a package definition from a "Guix
Packages" buffer – you can simply press "e" key there.  Also you may use
"M-x guix-edit" command (press TAB there to complete a package name).

-- 
Alex

Re: mumble issues with pulseaudio

[Alex Kost]

Ludovic Courtès (2017-04-03 23:18 +0200) wrote:

[...]
> I was talking of the account skeletons, i.e., the files that are
> automatically installed in the home directory of a newly-created account
> (see (gnu system shadow)).  These files can always be modified or
> removed by the user afterwards.
>
> Still I understand that choosing a default is always difficult.  :-)

OTOH, AFAIK PulseAudio is the default choice on most distros these days,
so it's probably OK to default to it.

-- 
Alex

Re: Tool to format/indent scheme code

[Alex Kost]

Huang, Ying (2017-03-04 13:54 +0800) wrote:

> Hi, All,
>
> Sometimes, I want to check the contents of auto-generated scheme code in
> store.  But the readability is not very good.  So I want to use a code
> format/indent tool to help on this.  Do you know is there such tool in
> Guix?  If no, any tool not in Guix?  Thanks in advance!

In Emacs you can use "C-u M-x indent-pp-sexp" to pretty print a sexp
after the point.

BTW, if anyone is interested, Emacs-Guix uses 'indent-pp-sexp' to
pretty-print Shepherd config of a system generation, which can be shown
like this:

1. Run "M-x guix-system-generations"
2. Press "RET" on any generation to get more info
3. Press "Pretty print" button

-- 
Alex

Re: Emacs autoloads

[Alex Kost]

Thomas Danckaert (2017-03-02 14:13 +0100) wrote:

> From: Catonano 
> Subject: Emacs autoloads
> Date: Thu, 2 Mar 2017 12:51:13 +0100
>
>> I installed emacs-debbugs
>>
>> But it doesn't get autoloaded, so I had to comment out this line in
>> my .emacs file
>>
>> (add-to-list 'debbugs-gnu-all-packages "guix-patches")
>>
>> because otherwise when launching emacs it claims that
>> "debbugs-gnu-all-packages" value is void
>
> I had the same issue, solved it using “with-eval-after-load”, like this:

This is not the issue, it is expected (see my answer to Catonano), and
'with-eval-after-load' is exactly what should be used in such cases.

> (with-eval-after-load 'debbugs-gnu
>   (add-to-list 'debbugs-gnu-all-packages "guix-patches"))
>
> In fact I sent a message to guix-devel about this, but it never made it
> through...

-- 
Alex

Re: Package Installation Queries

[Alex Kost]

Niall Dooley (2017-02-18 17:22 +0100) wrote:

> On 10 February 2017 at 09:55, Alex Kost <alez...@gmail.com> wrote:
[...]
>> BTW Symbola package can't be a part of Guix due to a really stupid
>> license problem.  If you are interested, I have a Guix package for this
>> font here:
>>
>>   https://github.com/alezost/guix-config/blob/master/packages/fonts.scm
>>
>
> That would be great, can you explain how I can make use of your package?

Along with the default Guix packages, you can use your own packages.
Basically, you can do it like this: at first, make some
"/path/to/my-guix-packages.scm" file with your packages, then add
"/path/to" directory to GUIX_PACKAGE_PATH environment variable.  Then
"guix" commands should find your packages automatically.

Also look at the manual:

https://www.gnu.org/software/guix/manual/html_node/Package-Modules.html#Package-Modules

-- 
Alex

Re: guix-daemon might be unmounting filesystems

[Alex Kost]

Myles English (2017-02-14 10:49 +) wrote:

> Hello,
>
> About one time out of ten when I use a guix command my filesystems,
> including /home, become unmounted and I have to manually remount them.

Hm, maybe you added your user to 'guixbuild' group? (check /etc/group)
If so, you shouldn't (!); this group is only for "build users"
(guixbuilder01, etc.).

-- 
Alex

Re: Starting user services at boot

[Alex Kost]

Ludovic Courtès (2017-02-13 10:30 +0100) wrote:

> Hi Leo!
>
> Leo Famulari  skribis:
>
>> Does anyone have advice about how to start an unprivileged user's
>> services when the system boots?
>>
>> On other systems, I could at least invoke them in /etc/rc.local, but I'm
>> not sure how to do it on GuixSD.
>
> Currently I run shepherd as myself, which reads from
> ~/.config/shepherd/init.scm.  It gets started from my ~/.xsession.

I do the same but in ~/.bash-profile like this:

# Start shepherd if it is not already running.
[[ -z $(pgrep -U $(id --user) "^shepherd$") ]] \
&& shepherd &>> $HOME/.config/shepherd/shepherd.log

-- 
Alex

Re: Package Installation Queries

[Alex Kost]

Niall Dooley (2017-02-09 22:36 +0100) wrote:

> On 8 February 2017 at 21:51, Alex Kost <alez...@gmail.com> wrote:
[...]
>> > (1) When I installed magit, v2.8.0 was installed instead of the
>> > v2.10.1 listed on hydra. Is this a bug or an error on my part?
>>
>> You probably didn't run "guix pull", so you installed the old magit (and
>> you will continue to install the old packages until you run "guix pull").
>
> I see but how often does one need to run 'guix pull' to ensure they install
> the latest available packages. Running it now installs guix as explained in
> the manual but it doesn't explain how often one needs to run it.

I don't know, it's up to you to decide how often :-)
"guix pull" just fetches and builds the latest Guix git snapshot, and as
you can guess Guix git tree is updated all the time.  Someone does "guix
pull" daily, someone weekly.  As for me, I'm not fancy of frequent
updates, sometimes I don't update packages for months (but it's not a
good practice).

[...]
>> > (3) Before installing Guix I used SCP as my font for Emacs. However,
>> > following the installation of SCP via Guix some unicode glyphs are
>> > not rendered correctly as they were before. Note, I did a fresh
>> > install of my foreign distro before installing Guix and did not
>> > re-install SCP on it. Is there further steps I need to perform to
>> > have these unicode glyphs rendered correctly?
>>
>> What unicode symbols are not displayed correctly for you?  If I
>> understood correctly, SCP is a font and you installed it with Guix,
>> right?  What name does this (SCP) package have in Guix?
>
> Yes, sorry SCP := Source Code Pro, and yes I've installed it via Guix using
> Guix package name font-adobe-source-code-pro. Examples of unicode
> characters which were displaying correctly before but not now include:
> U+232B, U+2326, U+23CE. Reading about this subject some more
> these characters may not in fact be available in SCP but were rather supplied
> by another available font.

Yeah, I think these chars are not supported by this font.  Emacs
displays U+232B and U+2326 with "Symbola" font for me, and U+23CE is
unrecognized (Symbola and any other font I have do not support it).

BTW Symbola package can't be a part of Guix due to a really stupid
license problem.  If you are interested, I have a Guix package for this
font here:

  https://github.com/alezost/guix-config/blob/master/packages/fonts.scm

> It seems Emacs maintains font mappings on
> a per-glyph basis, meaning that multiple fonts are used at the same time
> (transparently) to display any character for which you have a font
> (source: https://github.com/rolandwalker/unicode-fonts). So I guess before
> there was other fonts available to Emacs that I didn't necessarily configure.

I think this is case, and I know that Emacs tries to use "Symbola" font
for many ranges of chars including (#x2322 . #x23FF) as you can see with
"M-x find-library fontset" (search for "Symbola" there).

-- 
Alex

Re: Package Installation Queries

[Alex Kost]

Niall Dooley (2017-02-08 17:24 +0100) wrote:

> Firstly, I'm an aspiring programmer/hacker and I've gone straight
> into the deep end with trying to learn GNU/Linux, Emacs etc. I'm also
> new to Guix and this community so excuse my ignorance. 

Hello and welcome!

> I've installed Guix as a package manager on the Trisquel 7
> distribution of GNU/Linux running on a (Minifree) Libreboot X60s. I
> believe it was successful. Hoping to transition to GuixSD at some
> point and would be grateful to hear if others have had success with
> this. Anyway,...
>
> I proceeded to install Emacs, Geiser, Magit (subsequently removed),
> the Source Code Pro (SCP) font, GNU Stow, Git for now and for which I
> have a number of perhaps trivial queries. A limited search on the
> list archives turned up nothing so forgive me if these queries have
> been covered elsewhere.

No problem, this mailing list was created for such questions.

> (1) When I installed magit, v2.8.0 was installed instead of the
> v2.10.1 listed on hydra. Is this a bug or an error on my part? 

You probably didn't run "guix pull", so you installed the old magit (and
you will continue to install the old packages until you run "guix pull").

> (2) In terms of Emacs, do fellow Guix users install all packages via
> Guix instead of the traditional ELPA, MELPA route. I suspect they do
> as I guess that is the point.

Well, I don't, because currently Guix does not have all the emacs
packages I use (but it's my fault that I didn't package them :-)), so I
use some packages from Guix and some from… other places.

> But I ask for advice as my 'pre-guix'
> emacs config makes heavy use of the use-package macro installing all
> third party packages to ~/.emacs.d/elpa . I guess I could add the
> 'guix-emacs' site-lisp directory for each guix installed package to
> the load-path specifying this in each specific use-package package
> declaration. Is that what others do?

No, if you use Emacs from Guix ("guix package -i emacs"), you will not
have to add all those site-lisp directories as Guix's Emacs is patched
to find and autoload the packages there automatically.

I think use-package is completely unrelated to this question.  It's not
"use-package" that installs into "~/.emacs.d/elpa", it's an in-built
Emacs package system (aka "package.el"), "use-package" does not perform
any installation by itself.  You can still use Emacs from Guix and use
"use-package" from MELPA if that's your concern.  You don't need to
adjust your emacs config for Guix at all.

> (3) Before installing Guix I used SCP as my font for Emacs. However,
> following the installation of SCP via Guix some unicode glyphs are
> not rendered correctly as they were before. Note, I did a fresh
> install of my foreign distro before installing Guix and did not
> re-install SCP on it. Is there further steps I need to perform to
> have these unicode glyphs rendered correctly?

What unicode symbols are not displayed correctly for you?  If I
understood correctly, SCP is a font and you installed it with Guix,
right?  What name does this (SCP) package have in Guix?

> (4) I wish to manage my dotfiles with GNU stow. Traditionally, I
> understand people create a dotfiles directory say under $HOME and
> create the various subdirectories in this directory from which the
> symlinks are produced. Is this approach still the same with GNU stow
> installed via Guix or is the 'stow' directory created elsewhere?

I know nothing about 'stow', but it should behave the same as on any
other system.

-- 
Alex

Re: Seeking advice: preparing releases on GuixSD.

[Alex Kost]

ng0 (2016-12-23 13:35 +) wrote:

> Hi,
>
> my previous releases of gnurl (https://gnunet.org/gnurl) have
> been tested on Gentoo and GuixSD and prepared to release only on
> Gentoo, copied back to GuixSD and finished up on that GuixSD
> system.
> With my switch to GuixSD (and leaving Gentoo) 2 or 3 versions ago
> I have to advice people to run ./buildconf again (essentially:
> run autotools again), because of artifacts in shebangs and paths
> of generated files.

Do you mean "configure" and "Makefile.in" files?  I don't see any
"/gnu/store" artifacts, if that's what you mean.

> I see three solutions right now:
>
>  1. Opt out of the ./buildconf part and make it a responsibility
> of users and distributions to run it.
>
>  2. Patch (adjust) maketgz, make dist, or any similar hook/script
> to my needs on GuixSD.
>
>  3. Simply remove all occurences of any /gnu/store/… (if it's
> that simple) which could also happen in (2).
>
> I hope I'm not the only person using GuixSD for releasing
> software. How do you all deal with these shebangs and paths?

I made releases on GuixSD multiple times, but I've never faced the
problem you describe: "make dist" prepares system-independent files
without any artifacts AFAICT.

-- 
Alex

Re: locale warning and postgresql

[Alex Kost]

Ludovic Courtès (2016-11-28 21:48 +0100) wrote:

> Hi Myles,
>
> Myles English  skribis:
>
>> I have always had trouble with my locale after installing guix on Arch
>> Linux (with zsh and a basic window manager, bspwm).  I have set
>> GUIX_LOCPATH in ~/.zshenv and it appears correct in my shell.  The
>> system-wide locale looks right.  When I install postgresql it gives the
>> usual "warning: failed to install locale: Invalid argument".  When I try
>> to initialise a database cluster, passing the locale doesn't work.
>>
>> Does anyone using Arch Linux and a basic WM know which file to put
>> GUIX_LOCPATH in so that the warning goes away?
>>
>> How can I find out what guix thinks its locale is or what are available?
>>
>> Is there a way to use initdb even though there is a locale warning?
>>
>> Shell experiments:
>>
>> $ locale
>> LANG=en_GB.UTF-8
>> LC_CTYPE="en_GB.UTF-8"
>> LC_NUMERIC="en_GB.UTF-8"
>> LC_TIME="en_GB.UTF-8"
>> LC_COLLATE="en_GB.UTF-8"
>> LC_MONETARY="en_GB.UTF-8"
>> LC_MESSAGES="en_GB.UTF-8"
>> LC_PAPER="en_GB.UTF-8"
>> LC_NAME="en_GB.UTF-8"
>> LC_ADDRESS="en_GB.UTF-8"
>> LC_TELEPHONE="en_GB.UTF-8"
>> LC_MEASUREMENT="en_GB.UTF-8"
>> LC_IDENTIFICATION="en_GB.UTF-8"
>> LC_ALL=
>>
>> $ echo $GUIX_LOCPATH
>> /home/myles/.guix-profile/lib/locale
>
> What does “ls $GUIX_LOCPATH/2.24” show?
>
> You must make sure you have the ‘glibc-locales’ or ‘glibc-utf8-locales’
> that correspond to the glibc version of the program you are using (if
> you just installed postgresql, it’s using glibc 2.24.)
>
> Then you need to make sure GUIX_LOCPATH is set both in the environment
> of the postgresql daemon, and in the environment of the commands you
> invoke (initdb, etc.).

Including the guix-daemon, as this warning:

>> $ guix package -i postgresql
>> warning: failed to install locale: Invalid argument
>> The following package will be upgraded:
>>postgresql9.5.3 -> 9.5.3  
>> /gnu/store/sfgg20a7jnwfisajsvqdijjm2zj905az-postgresql-9.5.3

comes from the daemon, so make sure your "guix-daemon.service" has a
line like this:

  Environment=GUIX_LOCPATH=/root/.guix-profile/lib/locale

-- 
Alex

Re: GuixSD and TRAMP

[Alex Kost]

Ludovic Courtès (2016-10-20 23:00 +0200) wrote:

> Christopher Allan Webber  skribis:
>
>> Ho-ho, it turns out the snippet Ludo pasted me on IRC was the answer
>> after all:
>>
>>   ;; Make sure we work on remote guixsd machines :)
>>   ;; probably only helps if you start on a guixsd machine..!
>>   (setq tramp-remote-path
>> (append tramp-remote-path
>> '(tramp-own-remote-path)))

I also add 'tramp-own-remote-path' to tramp-remote-path in my emacs
config; as well as Ricardo and David.

> Good to know!
>
> Should we patch Emacs or something so that it works by default?

Just to mention, a year ago David and I (and probably Ricardo) also
agreed that it would be good to patch our Emacs for this.  It's just
that no one have sent such a patch since then :-)

The conversation was happening from
 to


-- 
Alex

Re: Error in gexp.scm. Unrecognized keyword.

[Alex Kost]

Dmitry Nikolaev (2016-09-28 12:06 +0300) wrote:

>
> > What is wrong with my guix installation and gexp.scm? I haven't
> seen
> > anybody complaining about it in this mailing list. What do I
> have to do to
> > update my GuixSD installation?
>
> Most likely there is some problem with your OS configuration
> (typically
> '/etc/config.scm'). Can you share it if there is nothing
> sensitive or
> private in it?
>
>
> Looks like something is wrong in my xorg-ati.scm module.
>
> I'm using non-libre linux with free drivers for Radeon with blob in
> kernel and some additional configuration for it.
>
> My entire configuration is open and located on github
>
> https://github.com/8p8c/my-guix
>
> You can find my config.scm there
>
> https://github.com/8p8c/my-guix/blob/master/config.scm
>
> As my xorg-ati.scm
>
> https://github.com/8p8c/my-guix/blob/master/packages/xorg-ati.scm

This file looks like you copied its contents from (gnu services xorg)
some time ago.  I think the problem is that this code is already old
enough to conflict with the current guix code.

Such copying of some part of the guix code and using it in a system
config instead of the current guix code is not a right approach IMO.  If
you think there is something that can't be configured by a user, please
report.  But is using #:extra-config for 'xorg-configuration-file'
procedure not enough for you needs?

-- 
Alex

Re: Error in gexp.scm. Unrecognized keyword.

[Alex Kost]

Dmitry Nikolaev (2016-09-24 23:35 +0300) wrote:

> Hi.
>
> I wanted to update my GuixSD installation, but everytime I run "guix
> system reconfigure ..." I'm getting
>
> guix/gexp.scm:314:0: In procedure computed-file:
> guix/gexp.scm:314:0: In procedure # gexp #:key options)>: Unrecognized keyword
>
> I've tried guix pull and guix refresh, nothing helped.
>
> What is wrong with my guix installation and gexp.scm? I haven't seen
> anybody complaining about it in this mailing list. What do I have to
> do to update my GuixSD installation?

Perhaps something is wrong with you system config.

-- 
Alex

Re: Package installation problem

[Alex Kost]

Roel Janssen (2016-09-06 11:16 +0300) wrote:

> [rjanssen2@hpc-mirror-001 ~]$ guix package -i macs --fallback
> --profile=/hpc/cog_bioinf/guix-state/guix/profiles/per-pipeline/atac-seq/guix-profile
> Backtrace:
> In guix/packages.scm:
> 1015: 19 [bag->derivation # # #]
> In srfi/srfi-1.scm:
>  578: 18 [map # #]
> In guix/packages.scm:
>  824: 17 [expand-input # # # ...]
>  779: 16 [cache! # # # ...]
> 1083: 15 [thunk]
> 1015: 14 [bag->derivation # # #]
> In srfi/srfi-1.scm:
>  578: 13 [map # #]
> In guix/packages.scm:
>  827: 12 [expand-input # # # ...]
>  779: 11 [cache! # # # ...]
> 1083: 10 [thunk]
> 1015: 9 [bag->derivation # # #]
> In srfi/srfi-1.scm:
>  578: 8 [map # #]
> In guix/packages.scm:
>  839: 7 [expand-input # # # ...]
> In guix/store.scm:
> 1182: 6 [run-with-store # ...]
> In guix/packages.scm:
> 1185: 5 [# #]
> In guix/store.scm:
> 1105: 4 [# #]
> In guix/packages.scm:
>  779: 3 [cache! # () ...]
> 1083: 2 [thunk]
>  779: 1 [cache! # () ...]
>  863: 0 [thunk]
>
> guix/packages.scm:863:12: In procedure thunk:
> guix/packages.scm:863:12: Throw to key `match-error' with args `("match" "no 
> matching pattern")'.

Did you try "make clean-go" (and "make" again)?  Perhaps it will help.

-- 
Alex

Re: Packaging packages with GPG signed source archives

[Alex Kost]

Arun Isaac (2016-08-31 08:37 +0300) wrote:

> I am trying to package a package that provides a GPG signed source
> archive. Is there any way to get Guix to verify this signature, by say,
> specifying it in the 'origin' object of the 'source' field of the
> package? What is the standard way this is done in Guix?

I think the procedure is: a packager verifies the source and that's it.
Since a package has a hash of the source, we can be sure that the source
wasn't changed since it was packaged, so if we find that a package has
a compromised source, we can blame the packager.

-- 
Alex

Re: simplest package definition?

[Alex Kost]

John J Foerch (2016-08-25 04:07 +0300) wrote:

> Hello Guix,
>
> What is the simplest possible package definition, to install a single
> shell script?  If possible, I would like to install it from the
> directory in which I'm developing it, and the package definition would
> also be in a file in this directory.

So you have some dir and 2 files there: "my-shell-script" and
"guix.scm", right?  If you don't care about shebang (I mean if you have
"#!/bin/sh" in the script, it will not be changed to
/gnu/store/.../bash), then you can use trivial-build-system.  So the
contents of "guix.scm" can be:

(use-modules
 (guix gexp)
 (guix packages)
 (guix build-system trivial))

(let ((script-name "my-shell-script"))
  (package
(name script-name)
(version "0.1")
(source (local-file (string-append (dirname (current-filename))
   "/" script-name)))
(build-system trivial-build-system)
(arguments
 `(#:modules ((guix build utils))
   #:builder
   (begin
 (use-modules (guix build utils))
 (let* ((bin-dir  (string-append %output "/bin"))
(bin-file (string-append bin-dir "/" ,script-name)))
   (mkdir-p bin-dir)
   (copy-file (assoc-ref %build-inputs "source") bin-file)
   (chmod bin-file #o555)
(home-page #f)
(synopsis "bla bla")
(description "More verbose bla bla")
(license #f)))

Use "guix build -f .../guix.scm" to build it.

If you care about shebang, I think you need to use gnu-build-system
(there is a phase that patches shebangs), but it requires removing many
phases and probably some additional tweaking.

-- 
Alex

Re: transmission-remote-cli not symlinked in ~/.guix-profile/bin/

[Alex Kost]

Leo Famulari (2016-08-23 18:38 +0300) wrote:

> On Tue, Aug 23, 2016 at 04:52:12PM +0530, Arun Isaac wrote:
>> 
>> > What is the output of:
>> >
>> >   $ file ~/.guix-profile
>> 
>> /home/arunisaac/.guix-profile: symbolic link to 
>> /home/arunisaac/.guix-profile-2-link
>
> That looks unusual to me.

I would replace "unusual" with "wrong" :-)

> For me, it's like this, both on GuixSD and
> Guix on another distro:
>
> $ file ~/.guix-profile
> /home/leo/.guix-profile: symbolic link to 
> /var/guix/profiles/per-user/leo/guix-profile

Right, this is what it should be.  Arun, somehow ~/.guix-profile link
becomes broken for you.  I don't know how it could happen, maybe you did
"guix package -p ~/.guix-profile ...", not sure if it could lead to
this.  Anyway you can relink "~/.guix-profile" to
"/var/guix/profiles/per-user/arunisaac/guix-profile" to fix the problem
you faced.

Also note that "~/.guix-profile-N-link" shouldn't exist, you can remove
these links.

-- 
Alex

Re: Counting Packages yields wrong result

[Alex Kost]

Björn Höfling (2016-08-23 00:10 +0300) wrote:

> I tried to count the number of packages in GuixSD for myself, but my
> result differs from the package list on the home page
> (https://www.gnu.org/software/guix/packages/). Why?
>
> Here is how I did it:
>
> #!/run/current-system/profile/bin/guile -s
> !#
>
> ; Counting number of packages in current system.
> ; This also includes packages with the same name,
> ; but different version string.
>
> (use-modules (gnu))
> (use-modules (guix))

Only (use-modules (gnu packages)) is needed.

> (display "Number of packages: ")
> (define cnt
>   (fold-packages
> (lambda (pkg ctr)
>   (+ 1 ctr))
> 0))
> (display cnt)
> (newline)
>
> Is that the correct way to walk through the list of packages anyway?

Yes (btw it gives me 3886 on the latest guix master).

Also note that it will also count your packages placed in
GUIX_PACKAGE_PATH.  So to make a pure experiment you need to unset this
environment variable at first (if you use it of course).

> I always get the number 3747 back, even after a guix pull. The homepage
> gives me 3881, and counting.
>
> guix --version give me:
>
> 20160822.18
>
>
> Looking at %load-path I figured out that
>
> /run/current-system/profile/share/guile/site/2.0/guix
>
> points to the ...guix-0.11.0-1 store path.
>
> Is that my problem? How can I script over the newest pull?

"guix pull" updates "~/.config/guix/latest" link, and when you run
"guix" command, it uses the packages from that directory.  So after
"guix pull" you'll get the latest package recipes for "guix ..."
commands.

But "guix pull" doesn't influence your guile script that uses guix
modules from some directories that come from GUILE_LOAD_PATH and
GUILE_LOAD_COMPILED_PATH.  So to make your script use those fresh
"guix-pulled" modules, you can modify these environment variables to
include "/home//.config/guix/latest".

An alternative is to use guix directly from a git checkout.
See (info "(guix) Building from Git") for details.

Finally, note that 'fold-packages' folds over package objects, while
packages may have multiple outputs (for example "git" has 4 outputs),
which can be installed separately, so if you consider each output as a
separate package, then the number is bigger.  The following blatant
violation of functional style gives me 4078 outputs:

(use-modules
 (gnu packages)
 (guix packages))

(define number-of-packages 0)
(define number-of-outputs 0)

(fold-packages
 (lambda (package _)
   (set! number-of-packages (1+ number-of-packages))
   (set! number-of-outputs (+ number-of-outputs
  (length (package-outputs package)
 #f)

(format #t "Number of packages: ~d~%" number-of-packages)
(format #t "Number of outputs: ~d~%" number-of-outputs)

-- 
Alex

Re: transmission-remote-cli not symlinked in ~/.guix-profile/bin/

[Alex Kost]

Arun Isaac (2016-08-23 08:35 +0300) wrote:

>> $ guix package -i transmission-remote-cli && which transmission-remote-cli 
>> && realpath $(which transmission-remote-cli)
> The following package will be installed:
>transmission-remote-cli1.7.1   
> /gnu/store/h620vv6ik6ybqaw22bdd4v83iadf7mw3-transmission-remote-cli-1.7.1
>
> 64 packages in profile
> The following environment variable definitions may be needed:
>export 
> PATH="/var/guix/profiles/per-user/arunisaac/guix-profile/bin:/var/guix/profiles/per-user/arunisaac/guix-profile/sbin${PATH:+:}$PATH"
>export 
> CROSS_CPATH="/var/guix/profiles/per-user/arunisaac/guix-profile/avr/include${CROSS_CPATH:+:}$CROSS_CPATH"
>export 
> CROSS_LIBRARY_PATH="/var/guix/profiles/per-user/arunisaac/guix-profile/avr/lib${CROSS_LIBRARY_PATH:+:}$CROSS_LIBRARY_PATH"
>export 
> ZATHURA_PLUGIN_PATH="/var/guix/profiles/per-user/arunisaac/guix-profile/lib/zathura${ZATHURA_PLUGIN_PATH:+:}$ZATHURA_PLUGIN_PATH"
>export 
> INFOPATH="/var/guix/profiles/per-user/arunisaac/guix-profile/share/info${INFOPATH:+:}$INFOPATH"
> which: no transmission-remote-cli in
> (/home/arunisaac/.guix-profile/bin:/home/arunisaac/.guix-profile/sbin:/run/setuid-programs:/run/current-system/profile/bin:/run/current-system/profile/sbin)
>
> Any pointers on how to debug this issue? Where could I be going wrong?
> Is it possible I'm missing some environment variables? I'm on GuixSD.

What is the output of:

  $ file ~/.guix-profile
  $ file ~/.guix-profile/bin/transmission-remote-cli

-- 
Alex

Re: neo tty layout

[Alex Kost]

ng0 (2016-08-14 12:07 +0300) wrote:

> Leo Famulari  writes:
>
>> On Sat, Aug 13, 2016 at 04:15:15PM +, ng0 wrote:
>>> Hi,
>>> 
>>> I just installed NixOS on another system and noticed they offer neo
>>> layout not only in X11 but also for tty. Would it be okay to replicate
>>> this for Guix? I'll be looking into this soon for me personally, but
>>> maybe others can benefit from it by including it in Guix.
>>
>> Hi,
>>
>> I'm not sure what the neo layout is. Is it a keyboard layout?
>
> Yes, it can be loaded in X11 in all system distributions and operating
> systems I know, but that it can be loaded for tty is rare. Most system
> for tty are limited to qwert{y,z} and some layouts where neo draws
> inspiration from.
> It's a layout specific to german keyboards and language but extends to
> other areas (scientic etc): http://neo-layout.org/index_en.html
> It can be loaded with `setxkbmap neo` or the desktop environment
> specific tool of it.
> I just need to figure out what nix patches or adds to make it available
> with `loadkeys neo` outside of X11.

If I undrestand it right from
,
they just download "neo.map" file and put it into appropirate dir of
'kbd' package.

See also


-- 
Alex

Re: How to install an old package version?

[Alex Kost]

Hartmut Goebel (2016-08-11 22:16 +0300) wrote:

> Hi,
>
> I'm curious about how to install an old package version with guix.
>
> Example for what I mean:
>
> In e.g Debian, the list of available packages is separate from
> apt-get (et al.). So I can query all available versions of a package
> and install the version I need:
>
>  $ apt-cache madison nginx
>  nginx | 1.9.10-1~bpo8+3 | http://debian.mirror.lrz.de/debian/
> jessie-backports/ma
>  nginx | 1.6.2-5+deb8u2 | http://security.debian.org/ jessie/
> updates/main amd64 Pa
>
>
> Now in guix, the list of available packages is build into guix, there
> is no external cache. So how can I e.g. install python-2.7.10 after I
> installed guix 0.11.0, which only defines python-2.7.11?

You have to make your own package for this version, that would look like
this:

(define-public python-2.7.10
  (package
(inherit python)
(version "2.7.10")
(source (origin
  (inherit (package-source python-2.7))
  (uri (string-append "https://www.python.org/ftp/python/;
  version "/Python-" version ".tar.xz"))
  (sha256 (base32 "some-letters-and-numbers"))

and to put it to a file from GUIX_PACKAGE_PATH.
See (info "(guix) Package Modules") for details.

Alternatively, you can use a guix git checkout on a specific commit that
still has python-2.7.10, but it's probably not what you want.

-- 
Alex

Re: Reverse dependencies

[Alex Kost]

Vincent Legoll (2016-08-11 17:43 +0300) wrote:

> Hello,
>
>>> I'm trying to understand which package(s) depends on some other package,
>>> kind of the reverse of what guix graph does (I think).
>>
>> I think that `guix refresh --list-dependent foo` is what you are asking
>> for, or at least it's close. We use it to learn what will need to be
>> rebuilt when upgrading foo.
>
> Not really what I want to know:
>
> # guix refresh --list-dependent inkscape
> Building the following 5 packages would ensure 10 dependent packages
> are rebuilt: frescobaldi-2.19.0 solfege-3.22.2 simple-scan-3.19.91
> termite-11 hydra-20150407.4c0e3e4
>
> None of those are installed, but inkscape is pulled in by something
> which I want to know

I think you mean inkscape is pulled when you build the system.  Then you
will not find it like this.  It is needed to build the fancy grub image,
and it is "pulled" by the system building code (specifically by
'svg->png' procedure in (gnu system grub) module).  If you want to avoid
it, you can specify an "empty" theme for example:

  (bootloader (grub-configuration (device "/dev/sda")
  (theme (grub-theme

-- 
Alex

Re: json module

[Alex Kost]

Catonano (2016-07-27 00:35 +0300) wrote:

> I'm trying this Guix project
> https://github.com/wordempire/guix/
>
> because I wanted to try Jelle's recursive npm importer
>
> but when I
> ./pre-inst-env guix import npm ciccio
>
> I get a backtrace and an error:
> ERROR: In procedure scm-error:
> ERROR: no code for module (json)
>
> (I can provide the whole backtrace if requested)
>
> This doesn't happen with the Guix I cloned from the official repo
>
> In the chat I was advised that (json) is an external module, to
> inspect the GUIX_LOAD_PATH and GUIX_LOAD_COMPILED_PATH variables

When you left, jlicht wrote you something:


Did you install guile-json and check that guile can find it?  Start
guile and run ",use(json)" there.

-- 
Alex

Re: installing libraries

[Alex Kost]

Vincent Legoll (2016-07-22 15:36 +0300) wrote:

> Hello (again),
>
> I'm trying to do a kernel "make menuconfig", so I have to install some 
> packages,
> make, gcc, binutils, ncurses, glibc, linux-libre-headers...
>
> but ncurses despite being installed, is not picked up...

Try to install 'gcc-toolchain' instead of 'gcc'.

-- 
Alex

Re: Is there a way to see 'Globally-Installed Packages' from the CLI?

[Alex Kost]

myglc2 (2016-07-22 00:42 +0300) wrote:

> See subject. In other words can I produce the list shown by 'M-x
> installed-system-packages' in the CLI?

guix package --list-installed --profile=/run/current-system/profile

-- 
Alex

Re: change resolution (new style) + question about qxl driver

[Alex Kost]

tk0 (2016-07-20 12:42 +0300) wrote:

[...]
> Another question is about the qxl display driver. This is the
> standard on my kvm image.  There is this weird message from X:
>
> 
> 11.379] (II) Module glx: vendor="X.Org Foundation"
> [11.379]compiled for 1.18.1, module version = 1.0.0
> [11.379]ABI class: X.Org Server Extension, version 9.0
> [11.379] (==) AIGLX enabled
> [11.379] (==) Matched qxl as autoconfigured driver 0
> [11.380] (==) Matched qxl as autoconfigured driver 1
> [11.380] (==) Matched modesetting as autoconfigured driver 2
> [11.380] (==) Matched fbdev as autoconfigured driver 3
> [11.380] (==) Matched vesa as autoconfigured driver 4
> [11.380] (==) Assigned the driver to the xf86ConfigLayout
> [11.380] (II) LoadModule: "qxl"
> [11.381] (WW) Warning, couldn't open module qxl
> [11.381] (II) UnloadModule: "qxl"
> [11.381] (II) Unloading qxl
> [ 11.381] (EE) Failed to load module "qxl" (module does not exist, 0)
> 

> It seems qxl gets unloaded, and I'm unable to push the resolution in
> the vm higher than 1024x768. Does anyone have an idea what is the
> issue here and how to fix it?

"Unloading" means that this module is not loaded at all because it is
not found.  If you look at 'xorg-configuration-file' in (gnu services
xorg)¹, you'll see that there is no ModulePath line for
'xf86-video-qxl'.  Moreover, this module is not even packaged :-)

If I understand it right, this qxl module is
.
If it's just a usual X video driver, it shouldn't be hard to package it
– it would be very similar to 'xf86-video-vesa', 'xf86-video-nouveau',
and other video driver packages in (gnu packages xorg) module².

Patches welcome :-)

¹ http://git.savannah.gnu.org/cgit/guix.git/tree/gnu/services/xorg.scm#n105
² http://git.savannah.gnu.org/cgit/guix.git/tree/gnu/packages/xorg.scm#n3021

-- 
Alex

Re: exploring the code

[Alex Kost]

Ludovic Courtès (2016-07-19 15:31 +0300) wrote:

> Catonano  skribis:
>
>> I opened the file guix/scripts/build.scm in Emacs
>>
>> For Geiser to be able to jump to the definition of a symbol at point
>> or to open a documentation buffer, I need the Guile REPL to "load" the
>> file 
>>
>> C-x C-b does the trick, but I see this error in the REPL, then
>>
>> http://paste.lisp.org/display/320775
>
> I use C-c C-k (geiser-compile-current-buffer), which works well for me.

I never liked this command.  I found it too slow, and I didn't
understand why it does so much, I always prefered
",use()".  That's why I added "C-c . u" key to
guix-devel-mode.  It does exactly that: uses the current module.

-- 
Alex

Re: Geiser documentation buffers

[Alex Kost]

Ludovic Courtès (2016-07-17 22:37 +0300) wrote:

> myglc2 <myg...@gmail.com> skribis:
[...]
>> geiser-next also has the problem.

It doesn't :-)

>> I also hit "when pressing q the buffer won't close". An install from
>> https://github.com/jaor/geiser.git to ~./emacs.d/lisp works for me ;-)
>
> On closer inspection, it seems to be fixed by this commit:
>
> commit 8e75455dfbd46355d777c26366e7ccfcb59ace20
> Author: Jose Antonio Ortega Ruiz <j...@gnu.org>
> Date:   Sun Dec 27 04:11:50 2015 +0100
>
> Avoiding uses of geiser-doc--with-buffer before its definition
>
> As patiently pointed out by Alex Kost in the discussion of issue #121,
> using the macro defined by the geiser-popup--define macro before its
> actual definition causes problems when geiser is loaded after
> compilation.  Thanks again, Alex and Federico.
>
> (Discussed at <https://github.com/jaor/geiser/issues/121>.)
>
> Alex, Fede: how about backporting it in our package?

'geiser-next' is already new enough to have this fix (myglc2 confirms:
<http://lists.gnu.org/archive/html/help-guix/2016-07/msg00133.html>)

-- 
Alex

Re: Geiser documentation buffers

[Alex Kost]

Ludovic Courtès (2016-07-16 23:51 +0300) wrote:

> Catonano  skribis:
>
>> This is not about Guix, admittedly. It's about Geiser
>>
>> I tried to post on the Geiser mailing list 3 times, to no avail
>>
>> So I'm trying here now. Supposedly Geiser is serving most of the people
>> hacking on Guix, so I hope this is not an outrageously off topic post
>>
>> When I ask Geiser to open the documentation buffer on some symbol at point,
>> then when pressing q the buffer won't close. A q will appear in the buffer
>> and it will persist.
>>
>> C-x k closes not only the documentation buffer but also the source code
>> buffer that I started from in the first place
>>
>> So I'd have to start all over again
>
> It’s a bug that made its way in the last Geiser version, I think, but
> ISTR that it’s fixed upstream.  Maybe Alex knows?

Yes, it was actually me who suggested a fix :-)

The bug was originally reported by Federico:
.

To make it clear: the fix is in the Geiser master, but not in the latest
Geiser version (which is 0.8.1).

-- 
Alex