Re: [PATCH 1/2] emacs: Simplify defining package ID in a list buffer.

[Ludovic Courtès]

Alex Kost  skribis:

> From baad22cdd084b2981f6dddbb3a11a7375c5768af Mon Sep 17 00:00:00 2001
> From: Alex Kost 
> Date: Fri, 19 Jun 2015 21:47:31 +0300
> Subject: [PATCH 1/2] emacs: Simplify defining package ID in a list buffer.
>
> * emacs/guix-list.el: Always retrieve 'package-id' parameter for a list
>   of outputs.
>   (guix-list-current-package-id): New function.

OK, I trust you.  ;-)

Ludo’.

Re: [PATCH 2/2] emacs: Add "edit" command to a list of packages.

[Ludovic Courtès]

Alex Kost  skribis:

> From 387e91bfc31f31eb983d8a6589c442d7138ab6aa Mon Sep 17 00:00:00 2001
> From: Alex Kost 
> Date: Fri, 19 Jun 2015 21:57:04 +0300
> Subject: [PATCH 2/2] emacs: Add "edit" command to a list of packages.
>
> * emacs/guix-base.el (guix-edit-package): New function.
> * emacs/guix-list.el (guix-list-edit-package): New command.  Bind it to
>   "e" key.
> * emacs/guix-main.scm (package-location-string): New procedure.
> * doc/emacs.texi (Emacs List buffer): Document "e" key binding.
> * doc/guix.texi (Invoking guix edit): Mention "package list" buffer.

Nice, please push!

Ludo’.

Re: emacs packages

[Federico Beffa]

On Sun, Jun 21, 2015 at 11:12 PM, Ludovic Courtès  wrote:
> Federico Beffa  skribis:
>
>> On Fri, Jun 19, 2015 at 2:13 PM, Ludovic Courtès  wrote:
> guix.el already takes care of that (info "(guix) Emacs Initial Setup"),
> so that should be enough.

 Unfortunately this doesn't work without modification. The reason is
 that I follow the emacs package.el strategy to install each ELPA
 package in it's own sub-directory. Specifically, I'm installing each
 package into ".../site-lisp/guix.d/PACKAGE-NAME-VERSION/".  The code
 in 'guix.el', however, doesn't look in sub-directories below the
 profile's '.../site-lisp'.
>>>
>>> What does it bring us to follow package.el’s strategy?
>>>
>>> My impression is that we could simply follow what guix.el already does,
>>> and thus avoid that guix.d/PACKAGE-VERSION sub-directory.  Of course we
>>> can adjust guix.el as we see fit, but package.el is a completely
>>> separate beast anyway.  Am I missing something?
>>
>> Hi Ludo,
>>
>> the reason for using separate sub-directories is that many packages
>> include files, such as README, ChangeLog, ..., that are likely to
>> clash. Even if we would delete all non ".el" files (which probably is
>> not safe), with more than 2500 packages on MELPA, it is possible that
>> we would still experience some name clashes. I can imagine that
>> someone preparing a package may be unaware of the existence of some
>> other package, possibly not very popular in his circle.
>
> What about copying all the .el files to .../site-lisp, and copy the
> other files elsewhere (for instance, ‘README’ and ‘ChangeLog’ to
> share/doc/$PACKAGE, and .info files to share/info)?

I am copying .info files to share/info. I'm not copying README files
to share/doc because these usually do not provide useful documentation
for the user and ChangeLog are usually not up-to-date relict. But if
somebody feels strongly about it, I can change that.

>
> Note that name clashes in profiles are annoying, but not fatal.

For .el files they are.

I also do not think that it is very sane ending up with a flat
directory including hundreds of files. Some hierarchy makes the
organization much more apparent and clean.

Regards,
Fede

Re: Preparing for core-updates merge

[Ludovic Courtès]

Mark merged ‘core-updates’ yesterday (thanks!).
Please report any issues.

Ludo’.

Re: The reason why gst-libav is broken on x86_64

[Ludovic Courtès]

Mark H Weaver  skribis:

> FYI, I investigated the problem with gst-libav on x86_64, and it turns
> out that it began when we updated nettle from 2.7 to 3.1, the latter of
> which is configured with --enable-fat.  For details, see my post on
> bug-nettle:
>
>   http://lists.lysator.liu.se/pipermail/nettle-bugs/2015/003389.html

Interesting, thanks for investigating.  Followup at
.

> We could work around the problem by removing the --enable-fat configure
> option, although it will entail a lot of rebuilding.  While we're at it,
> we should also update to nettle-3.1.1.

If we don’t use --enable-fat, then we get non portable binaries,
don’t we?

Would it work to use nettle-2.7 for instance for gst-libav?

Thanks,
Ludo’.

Re: [PATCH 3/5] build: Add 'emacs-build-system'

[Federico Beffa]

On Sun, Jun 21, 2015 at 10:40 PM, Alex Kost  wrote:
>> new file mode 100644
>> index 000..da2b594
>> --- /dev/null
>> +++ b/guix/build-system/emacs.scm
> [...]
>> +#:tests? ,tests?
>> +#:phases ,phases
>> +#:outputs %outputs
>> +#:search-paths ',(map search-path-specification->sexp
>> +  search-paths)
>> +#:inputs %build-inputs)))
>> +
> spaces on this line ^

Hi, thanks for the review!

This and other spaces that you indicate as "extra", are included by
Emacs by pressing TAB. This is because, as an example, the above
snippet finishes an internal define form and not a top-level form.

I'm following the Emacs behavior. Is there a convention to suppress
all spaces (in spite of what Emacs does)?

Regards,
Fede

Re: [PATCH 3/5] build: Add 'emacs-build-system'

[Mathieu Lirzin]

Federico Beffa  writes:

> I'm following the Emacs behavior. Is there a convention to suppress
> all spaces (in spite of what Emacs does)?

'M-x delete-trailing-whitespace' ?

--
Mathieu Lirzin

Re: Guix package steps

[Daniel Pimentel]

On 2015-06-22 03:09, Mark H Weaver wrote:

Daniel Pimentel  writes:


On 2015-06-17 00:57, Mark H Weaver wrote:

Daniel Pimentel  writes:


I tried create new packages (ipcalc, nmap, xfburn and others) but
without success.

My steps (based on talk GNU Guix packaging by Andreas Enge):
0. Git clone guix repository by savannah;
1. Copy gnu/package/indent.scm to mypackage.scm in this same folder;
2. Add module to gnu-system.am
3. Download mypackage;
4. Edit mypackage.scm and add hash, license and other information;
5. ./pre-inst-env guix build mypackage -K
6. Erro: bash: ./pre-inst-env: No such file or directory

But there is pre-inst-env.in only. The script pre-inst-env not exist
in repository. So where is pre-inst-env?


You have to build guix before you can run it.  See
doc/contributing.texi, especially the "Building from Git" section.
Also, you should pass --localstatedir=/var to ./configure.

 Mark


I tried again, follow README file but there's a error (dot command?)
when I run "make":

/bin/sh /home/dani/Desktop/development/git/guix/build-aux/missing dot
-Tpng -Gratio=.9 -Gnodesep=.005 -Granksep=.5 -Nfontsize=9
-Nheight=.1 -Nwidth=.1 < "doc/images/bootstrap-graph.dot" >
"doc/images/bootstrap-graph.png.tmp"
/home/dani/Desktop/development/git/guix/build-aux/missing: line 81:
dot: command not found


'dot' is part of the graphviz package, which is listed as a required
package in the "Building from Git" section that I cited above.

  Mark


Hi Guix,

After:
-clone Guix repository -> ok
-Read README and install requirements -> ok
-guix environment guix -> ok
-./configure --with-libgcrypt-prefix=$HOME/.guix-profile/ -> ok
-make -> ok
-make check -> error: FAIL: tests/lint.scm

I tried again build (./pre-inst-env guix build ipcalc -K): guix build: 
error: failed to connect to `/usr/local/var/guix/daemon-socket/socket': 
No such file or directory


Thanks Mark and Guix team.

--
Daniel Pimentel (d4n1 3:)

Re: Guix package steps

[Amirouche Boubekki]

On 2015-06-22 15:42, Daniel Pimentel wrote:

On 2015-06-22 03:09, Mark H Weaver wrote:

Daniel Pimentel  writes:


On 2015-06-17 00:57, Mark H Weaver wrote:

Daniel Pimentel  writes:


I tried create new packages (ipcalc, nmap, xfburn and others) but
without success.

My steps (based on talk GNU Guix packaging by Andreas Enge):
0. Git clone guix repository by savannah;
1. Copy gnu/package/indent.scm to mypackage.scm in this same 
folder;

2. Add module to gnu-system.am
3. Download mypackage;
4. Edit mypackage.scm and add hash, license and other information;
5. ./pre-inst-env guix build mypackage -K
6. Erro: bash: ./pre-inst-env: No such file or directory

But there is pre-inst-env.in only. The script pre-inst-env not 
exist

in repository. So where is pre-inst-env?


You have to build guix before you can run it.  See
doc/contributing.texi, especially the "Building from Git" section.
Also, you should pass --localstatedir=/var to ./configure.

 Mark


I tried again, follow README file but there's a error (dot command?)
when I run "make":

/bin/sh /home/dani/Desktop/development/git/guix/build-aux/missing dot
-Tpng -Gratio=.9 -Gnodesep=.005 -Granksep=.5 -Nfontsize=9
-Nheight=.1 -Nwidth=.1 < "doc/images/bootstrap-graph.dot" >
"doc/images/bootstrap-graph.png.tmp"
/home/dani/Desktop/development/git/guix/build-aux/missing: line 81:
dot: command not found


'dot' is part of the graphviz package, which is listed as a required
package in the "Building from Git" section that I cited above.

  Mark


Hi Guix,

After:
-clone Guix repository -> ok
-Read README and install requirements -> ok
-guix environment guix -> ok
-./configure --with-libgcrypt-prefix=$HOME/.guix-profile/ -> ok
-make -> ok
-make check -> error: FAIL: tests/lint.scm

I tried again build (./pre-inst-env guix build ipcalc -K): guix build:
error: failed to connect to
`/usr/local/var/guix/daemon-socket/socket': No such file or directory



You need to run the guix daemon [1], but before create as root the guix 
builders [2]:


# groupadd --system guix-builder
# for i in `seq 1 10`;
  do
useradd -g guix-builder -G guix-builder   \
-d /var/empty -s `which nologin`  \
-c "Guix build user $i" --system  \
guix-builder$i;
  done

The guix-daemon program may then be run as root with:

# guix-daemon --build-users-group=guix-builder

Also don't forget to add hydra pub key as discribed in [3]:

# guix archive --authorize < hydra.gnu.org.pub

[1] 
https://www.gnu.org/software/guix/manual/guix.html#Invoking-guix_002ddaemon
[2] 
https://www.gnu.org/software/guix/manual/guix.html#Build-Environment-Setup
[3] 
https://www.gnu.org/software/guix/manual/guix.html#Binary-Installation

Re: [PATCH] gnu/package/pv.scm (pv): New file, new variable

[韋嘉誠]

On Fri, Jun 19, 2015 at 8:51 PM, Claes Wallin (韋嘉誠)
 wrote:
> Argh. Why is there always some small detail you don't notice until you
> posted, even in a small file like this?
>
> Removed commented-out lines.

Bump?


0001-gnu-package-pv.scm-pv-New-file-new-variable.patch
Description: Binary data

Re: The reason why gst-libav is broken on x86_64

[Mark H Weaver]

l...@gnu.org (Ludovic Courtès) writes:

> Mark H Weaver  skribis:
>
>> FYI, I investigated the problem with gst-libav on x86_64, and it turns
>> out that it began when we updated nettle from 2.7 to 3.1, the latter of
>> which is configured with --enable-fat.  For details, see my post on
>> bug-nettle:
>>
>>   http://lists.lysator.liu.se/pipermail/nettle-bugs/2015/003389.html
>
> Interesting, thanks for investigating.  Followup at
> .
>
>> We could work around the problem by removing the --enable-fat configure
>> option, although it will entail a lot of rebuilding.  While we're at it,
>> we should also update to nettle-3.1.1.
>
> If we don’t use --enable-fat, then we get non portable binaries,
> don’t we?

Maybe it's not enough to simply remove --enable-fat, but presumably
there's a way to compile a non-fat nettle that targets a machine with
the minimum set of required features for a given target.

Anyway, a better option would be to simply disable the IFUNC method of
initializing nettle.

> Would it work to use nettle-2.7 for instance for gst-libav?

No, nettle is getting linked into gst-libav via several levels of
indirection.  One way is via the path:

  gst-libav -> ffmpeg -> libquvi -> curl -> gnutls -> nettle

Maybe there are other paths as well, I don't know.  Anyway, if we were
to introduce nettle-2.7 back into the mix, then we'd surely end up with
two different versions of nettle being linked into the same program,
which caused problems for us some time ago as I recall.

 Mark

Re: [PATCH] Integrate the package list in the website.

[Ludovic Courtès]

Luis Felipe López Acevedo  skribis:

> One thing I found is that the page does not validate. "The error was:
> utf8 "\xE9" does not map to Unicode" ().
>
> In my Web browser, the  of the page reads "Packages ?
> GuixSD". Maybe that question mark has something to do with the error
> above.

Right, the page was exported in locale encoding (which happened to be
ASCII on hydra.gnu.org) instead of UTF-8.  Fixed in 1bc4c07.

> Also, I noticed that the page is starting to take more time to load,
> at least in this computer. What would you think of adding pagination?
> I can't help with the code right now, but I could draw a mockup this
> weekend.

I’m not sure what you mean by pagination.

What would be ideal would be to use the JS code found in guix-web
 that allows users to search for
packages (basically all the package data would still be available in the
client, just not displayed.)

WDYT?

(I’m not offering to help with this code, though. :-))

Thanks,
Ludo’.

Third party guix repositories could be used for housing guile modules and other things.

[crocket]

Guile hasn't had an official repository. That's why guile hasn't
accumulated thousands of modules.
Since the official gnu guix repository is mainly for GuixSD, it makes
sense to make another guix repository for guile modules to be used on
multiple linux distributions. I'm not sure if guix works on windows
and Mac OS, too.

If you made it possible to add third party guix repository URLs,
people would add third party repositories later without upfront
coordination with guix developers.

Re: [PATCH 3/5] build: Add 'emacs-build-system'

[Alex Kost]

Federico Beffa (2015-06-22 11:51 +0300) wrote:

> On Sun, Jun 21, 2015 at 10:40 PM, Alex Kost  wrote:
>>> new file mode 100644
>>> index 000..da2b594
>>> --- /dev/null
>>> +++ b/guix/build-system/emacs.scm
>> [...]
>>> +#:tests? ,tests?
>>> +#:phases ,phases
>>> +#:outputs %outputs
>>> +#:search-paths ',(map search-path-specification->sexp
>>> +  search-paths)
>>> +#:inputs %build-inputs)))
>>> +
>> spaces on this line ^
>
> Hi, thanks for the review!
>
> This and other spaces that you indicate as "extra", are included by
> Emacs by pressing TAB. This is because, as an example, the above
> snippet finishes an internal define form and not a top-level form.

Then don't press TAB on an empty line if you are not going to write
something there :-)

> I'm following the Emacs behavior. Is there a convention to suppress
> all spaces (in spite of what Emacs does)?

Well, these trailing spaces are artifacts of (inaccurate) coding.  Emacs
can't read user's mind to decide if the spaces are redundant or
intended.

As Mathieu, I also use 'delete-trailing-whitespace' command when I want
to get rid of the whitespaces in the current buffer.  You may try to put
it into 'after-save-hook', but I would not do this as I don't like when
my files are edited without asking me.

Also I prefer to _see_ the trailing whitespaces.  For that I set
'show-trailing-whitespace' variable to t in "text" and "prog" buffers:



show-whitespaces.el
Description: application/emacs-lisp

-- 
Alex

Re: [PATCHES] Add cogl, clutter, clutter-gtk, and clutter-gst

[Ludovic Courtès]

Mark H Weaver  skribis:

> + `(#:configure-flags (list "--enable-cogl-gst"
> +   ;; Arrange to pass an absolute pathname to

s/pathname/file name/ :-)

> +   ;; dlopen for libGL.so.
> +   (string-append "--with-gl-libname="
> +  (assoc-ref %build-inputs 
> "mesa")
> +  "/lib/libGL.so"))
> +   ;; XXX FIXME: All tests fail, with many errors printed like this:
> +   ;;   _FontTransOpen: Unable to Parse address
> +   ;;   ${prefix}/share/fonts/X11/misc/

I don’t think this is the actual error, but rather a warning from the X
server saying that it can’t find fonts.

Other than that the patches look good to me.

Thank you!

Ludo’.

Re: [PATCH] gnu: Add gom

[Ludovic Courtès]

Mark H Weaver  skribis:

> From 3a095ad57dacaf0e369a70f0241a9f25698e1a0f Mon Sep 17 00:00:00 2001
> From: Mark H Weaver 
> Date: Sat, 20 Jun 2015 23:39:18 -0400
> Subject: [PATCH] gnu: Add gom.
>
> * gnu/packages/gnome.scm (gom): New variable.

LGTM!

Ludo'.

Re: [PATCHES] Add totem

[Ludovic Courtès]

Mark H Weaver  skribis:

> A few caveats: in order for totem to work properly, you must have
> several other packages installed in your profile.  I'm not entirely sure
> of the full set needed, but I guess it includes:
>
>   grilo
>   grilo-plugins
>   gstreamer
>   gst-plugins-base
>   gst-plugins-good
>   dconf
>
> You will also need to set the GRL_PLUGIN_PATH and GST_PLUGIN_SYSTEM_PATH
> environment variables as advised by "guix package --search-paths".

I can imagine why the plugins package need to be in the profile, but I
find the others more surprising.  Do you know what happens?  Are Grilo,
GStreamer, and DConf dlopened, or is it just to get the right search
path recommendation that they are needed?

> From 4bdac7f9e1ffeec6e3a2b26d366bfe8d71cd5ae2 Mon Sep 17 00:00:00 2001
> From: Mark H Weaver 
> Date: Sat, 20 Jun 2015 19:34:50 -0400
> Subject: [PATCH 1/3] gnu: Add grilo.
>
> * gnu/packages/gnome.scm (grilo): New variable.

LGTM.

> From ba786fa3d1d7896336dca3b364bb630142c30fa1 Mon Sep 17 00:00:00 2001
> From: Mark H Weaver 
> Date: Sat, 20 Jun 2015 21:09:54 -0400
> Subject: [PATCH 2/3] gnu: Add grilo-plugins.
>
> * gnu/packages/gnome.scm (grilo-plugins): New variable.

[...]

> + `(#:make-flags (list (string-append "GRL_PLUGINS_DIR="
> + %output
> + "/lib/grilo-"
> + ,(version-major+minor version)))
> +   ;; XXX FIXME: Investigate test failure:
> +   ;;   TEST: test_apple_trailers... (pid=8718)
> +   ;; /apple-trailers/browse/count:
> +   ;;   ERROR:test_apple_trailers.c:88:test_browse_count: assertion 
> failed: (source)
> +   ;;   FAIL
> +   #:tests? #f))

Would it be OK to skip just this for now?  If that’s too much, we can
leave it for later.

> +(synopsis "Framework for discovering and browsing media - Plugins")

Maybe “Plugins for the Grilo media discovery library”?

> From 2bbcefc85149fa4d6b8513de26fc4ba749e4111b Mon Sep 17 00:00:00 2001
> From: Mark H Weaver 
> Date: Sat, 20 Jun 2015 18:26:34 -0400
> Subject: [PATCH 3/3] gnu: Add totem.
>
> * gnu/packages/gnome.scm (totem): New variable.

OK.

Thank you!

Ludo’.

Re: Guix package steps

[Ludovic Courtès]

Daniel Pimentel  skribis:

> -make check -> error: FAIL: tests/lint.scm

To complement what Amirouche wrote, please see

on how to report test failures.

Thanks!

Ludo’.

Re: [PATCH 3/5] build: Add 'emacs-build-system'

[Federico Beffa]

On Mon, Jun 22, 2015 at 7:59 PM, Alex Kost  wrote:
> Federico Beffa (2015-06-22 11:51 +0300) wrote:
>
>> On Sun, Jun 21, 2015 at 10:40 PM, Alex Kost  wrote:
 new file mode 100644
 index 000..da2b594
 --- /dev/null
 +++ b/guix/build-system/emacs.scm
>>> [...]
 +#:tests? ,tests?
 +#:phases ,phases
 +#:outputs %outputs
 +#:search-paths ',(map search-path-specification->sexp
 +  search-paths)
 +#:inputs %build-inputs)))
 +
>>> spaces on this line ^
>>
>> Hi, thanks for the review!
>>
>> This and other spaces that you indicate as "extra", are included by
>> Emacs by pressing TAB. This is because, as an example, the above
>> snippet finishes an internal define form and not a top-level form.
>
> Then don't press TAB on an empty line if you are not going to write
> something there :-)
>
>> I'm following the Emacs behavior. Is there a convention to suppress
>> all spaces (in spite of what Emacs does)?
>
> Well, these trailing spaces are artifacts of (inaccurate) coding.  Emacs
> can't read user's mind to decide if the spaces are redundant or
> intended.

No need to read the mind... you just look if there are characters
other than white spaces (and possibly TABs) between newlines :-)

But, my question was NOT: how can I see white spaces. Rather: is there
a Guix coding style "rule" which states that white spaces there are
undesired.

I personally prefer to have them, because then, if I use M-up/down, I
move to the beginning/end of a whole top-level block, without stopping
at internal points and that's what I want most of the time.

So, these spaces are not just coding artifacts, but have some use.

Fede

Re: [PATCH 3/5] build: Add 'emacs-build-system'

[Thompson, David]

On Mon, Jun 22, 2015 at 3:33 PM, Federico Beffa  wrote:
>
> But, my question was NOT: how can I see white spaces. Rather: is there
> a Guix coding style "rule" which states that white spaces there are
> undesired.
>
> I personally prefer to have them, because then, if I use M-up/down, I
> move to the beginning/end of a whole top-level block, without stopping
> at internal points and that's what I want most of the time.
>
> So, these spaces are not just coding artifacts, but have some use.

There should be *no* trailing whitespace in submitted patches, and we
should add a note about it to our contribution guidelines if it's not
already there.

- Dave

Re: emacs packages

[Ludovic Courtès]

Federico Beffa  skribis:

> On Sun, Jun 21, 2015 at 11:12 PM, Ludovic Courtès  wrote:
>> Federico Beffa  skribis:

[...]

> Unfortunately this doesn't work without modification. The reason is
> that I follow the emacs package.el strategy to install each ELPA
> package in it's own sub-directory. Specifically, I'm installing each
> package into ".../site-lisp/guix.d/PACKAGE-NAME-VERSION/".  The code
> in 'guix.el', however, doesn't look in sub-directories below the
> profile's '.../site-lisp'.

[...]

>>> the reason for using separate sub-directories is that many packages
>>> include files, such as README, ChangeLog, ..., that are likely to
>>> clash. Even if we would delete all non ".el" files (which probably is
>>> not safe), with more than 2500 packages on MELPA, it is possible that
>>> we would still experience some name clashes. I can imagine that
>>> someone preparing a package may be unaware of the existence of some
>>> other package, possibly not very popular in his circle.
>>
>> What about copying all the .el files to .../site-lisp, and copy the
>> other files elsewhere (for instance, ‘README’ and ‘ChangeLog’ to
>> share/doc/$PACKAGE, and .info files to share/info)?
>
> I am copying .info files to share/info.

Ah OK, perfect then!

> I'm not copying README files to share/doc because these usually do not
> provide useful documentation for the user and ChangeLog are usually
> not up-to-date relict. But if somebody feels strongly about it, I can
> change that.

No, that’s fine.

>> Note that name clashes in profiles are annoying, but not fatal.
>
> For .el files they are.

They are fatal but rare, no?  My impression is that people prefix their
.el file names with the package name.  In my profile I have emms, bbdb,
emacs-w3m, magit & deps, geiser, cflow, etc. and there are zero clashes.
I don’t see any clash in the dozen of packages I still have in
~/.emacs.d/elpa/ either.

> I also do not think that it is very sane ending up with a flat
> directory including hundreds of files. Some hierarchy makes the
> organization much more apparent and clean.

The problem is that, unlike Guile modules, elisp module names are
inherently flat, hence the PACKAGE-foo.el convention that people seem to
follow.

But perhaps that convention is not strictly followed, which would
explain why package.el took this route?

I don’t feel strongly against what you suggest.  My main concern would
be the introduction of extra complexity that’s not strictly needed, but
you seem to be saying that it *is* needed.

Regardless, what matters most to me is that guix.el and
‘emacs-build-system’ work consistently.

Thank you!

Ludo’.

Re: [PATCH] gnu: geiser: Symlink Guile modules to the right 'guilesitedir'.

[Ludovic Courtès]

宋文武  skribis:

> * gnu/packages/emacs.scm (geiser)[arguments]: Symlink Guile modules
>   to the right 'guilesitedir' in the 'post-install' phase.

宋文武  skribis:

> The previous patch was intend to fix a issue that manually spawned Guile
> doesn't know the geiser module.
>
> When discuss this issue in IRC with alezost, I suddenly notice that add
> a simple '(require 'geiser-install)' to my init.el make it work.
>
> Here is the new patch for '/etc/emacs/site-start.el' (not tested yet!):

LGTM, but please check with ‘guix system vm’ or similar that it works as
expected.

Thanks!

Ludo’.

Re: [PATCH] gnu: geiser: Symlink Guile modules to the right 'guilesitedir'.

[宋文武]

Ludovic Courtès  writes:

> 宋文武  skribis:
>
>> * gnu/packages/emacs.scm (geiser)[arguments]: Symlink Guile modules
>>   to the right 'guilesitedir' in the 'post-install' phase.
>
> 宋文武  skribis:
>
>> The previous patch was intend to fix a issue that manually spawned Guile
>> doesn't know the geiser module.
>>
>> When discuss this issue in IRC with alezost, I suddenly notice that add
>> a simple '(require 'geiser-install)' to my init.el make it work.
>>
>> Here is the new patch for '/etc/emacs/site-start.el' (not tested yet!):
>
> LGTM, but please check with ‘guix system vm’ or similar that it works as
> expected.
Done, thanks for review!

Re: emacs packages

[Federico Beffa]

On Mon, Jun 22, 2015 at 9:43 PM, Ludovic Courtès  wrote:
> Federico Beffa  skribis:
>
>> On Sun, Jun 21, 2015 at 11:12 PM, Ludovic Courtès  wrote:
>>> Federico Beffa  skribis:
>
> [...]
>
>> Unfortunately this doesn't work without modification. The reason is
>> that I follow the emacs package.el strategy to install each ELPA
>> package in it's own sub-directory. Specifically, I'm installing each
>> package into ".../site-lisp/guix.d/PACKAGE-NAME-VERSION/".  The code
>> in 'guix.el', however, doesn't look in sub-directories below the
>> profile's '.../site-lisp'.
>
> [...]
>
 the reason for using separate sub-directories is that many packages
 include files, such as README, ChangeLog, ..., that are likely to
 clash. Even if we would delete all non ".el" files (which probably is
 not safe), with more than 2500 packages on MELPA, it is possible that
 we would still experience some name clashes. I can imagine that
 someone preparing a package may be unaware of the existence of some
 other package, possibly not very popular in his circle.
>>>
>>> What about copying all the .el files to .../site-lisp, and copy the
>>> other files elsewhere (for instance, ‘README’ and ‘ChangeLog’ to
>>> share/doc/$PACKAGE, and .info files to share/info)?
>>
>> I am copying .info files to share/info.
>
> Ah OK, perfect then!
>
>> I'm not copying README files to share/doc because these usually do not
>> provide useful documentation for the user and ChangeLog are usually
>> not up-to-date relict. But if somebody feels strongly about it, I can
>> change that.
>
> No, that’s fine.
>
>>> Note that name clashes in profiles are annoying, but not fatal.
>>
>> For .el files they are.
>
> They are fatal but rare, no?  My impression is that people prefix their
> .el file names with the package name.  In my profile I have emms, bbdb,
> emacs-w3m, magit & deps, geiser, cflow, etc. and there are zero clashes.
> I don’t see any clash in the dozen of packages I still have in
> ~/.emacs.d/elpa/ either.
>
>> I also do not think that it is very sane ending up with a flat
>> directory including hundreds of files. Some hierarchy makes the
>> organization much more apparent and clean.
>
> The problem is that, unlike Guile modules, elisp module names are
> inherently flat, hence the PACKAGE-foo.el convention that people seem to
> follow.
>
> But perhaps that convention is not strictly followed, which would
> explain why package.el took this route?
>
> I don’t feel strongly against what you suggest.  My main concern would
> be the introduction of extra complexity that’s not strictly needed, but
> you seem to be saying that it *is* needed.

I'm just saying: If we use separate directories as package.el does, we
avoid all name clashes with probability 1. If we use a flat structure
such a claim can not be done.

Even if the clash "only" happens with, say, a README file, the state
of the system (user profile) would depend on the order of
installation. To me that is very bad, especially if there is an easy
solution to prevent that as in this case.

>
> Regardless, what matters most to me is that guix.el and
> ‘emacs-build-system’ work consistently.

I fully agree and Alex last Friday already posted a small patch to
make guix.el look into sub-directories.

https://lists.gnu.org/archive/html/guix-devel/2015-06/msg00382.html

Regards,
Fede

Re: [PATCH 3/5] build: Add 'emacs-build-system'

[Federico Beffa]

On Mon, Jun 22, 2015 at 9:40 PM, Thompson, David
 wrote:
> On Mon, Jun 22, 2015 at 3:33 PM, Federico Beffa  wrote:
>>
>> But, my question was NOT: how can I see white spaces. Rather: is there
>> a Guix coding style "rule" which states that white spaces there are
>> undesired.
>>
>> I personally prefer to have them, because then, if I use M-up/down, I
>> move to the beginning/end of a whole top-level block, without stopping
>> at internal points and that's what I want most of the time.
>>
>> So, these spaces are not just coding artifacts, but have some use.
>
> There should be *no* trailing whitespace in submitted patches, and we
> should add a note about it to our contribution guidelines if it's not
> already there.

OK, I will delete those spaces then. But, I'm curious about the
rationale for such a rule.

Regards,
Fede