bug#22550: (require 'magit) produces error: "no such file or directory" "dash"

[myglc2]

Alex Kost  writes:

> Alex Kost (2016-02-04 23:00 +0300) wrote:
>
> [...]
>> So to recap, you found 2 issues:
>>
>> 1. Emacs packages installed in a system profile are not automatically
>>added to 'load-path'.
>
> Fixed in commit 004ea62¹.  However, it will take effect when the new
> source of "guix-emacs.el" will be used.  It will happen only after we'll
> update our guix-devel snapshot (last time it was in commit 2c77615).
>

Thanks. Given that I am using git pull, is it feasible to for me test
this change now?

>> 2. With the current EMACSLOADPATH, a wrong "site-lisp.el" is loaded, so
>>"M-x guix-…" commands are not autoloaded.
>
> This one is fixed in commit b3fee14² (it will take effect when
> EMACSLOADPATH will be changed, i.e. after "guix pull", "guix system
> reconfigure" and rebooting).

Thanks, I can confirm this works for me.

bug#22010: bytecode timestamps

[Leo Famulari]

Those differing bytes are the timestamps of the .py sources files that
correspond to the compiled .pyc / .pyo files. So, the
python-2.7-source-date-epoch.patch is working for software compiled by
the patched compiler, but not on python-2.7 itself.

It's related to .

bug#22593: 'make check' fails

[myglc2]

guixSD installed on a server.

make check fails for user glc but succeeds for user glc3.



make.check.fail.log
Description: Binary data


test-suite.log
Description: Binary data


make.check.log
Description: Binary data

bug#22546: Download-Page is "hiding" what the options actually are

[Nils Gillmann]

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

> Robin Vobruba  skribis:
>
>> Being new to Guix, i went to the Download page:
>> https://www.gnu.org/software/guix/download/
>>
>> immediately saw the 3 big options
>> read their title/names
>> was confused what the difference might be between "GuixSD" and "Guix Binary"
>> could not find anything inside these 3 option's boxes that would help me
>> read the text below them
>> read the text above them
>> finally understood that the first option is the OS, and the second is only
>> the packag-manager
>
> I think I’ll have to disagree.  :-)
>
> For each option there’s a line right below the title saying what this
> is.  I’m no expert in “information architecture” but I’m under the
> impression that there’s little margin for improvement.
>

SD has a different Symbol than Guix, which works okay for me with
no colorblindness and no other visual problems.
But maybe it could help to highlight the 'System Distribution'
and to visually (with colors in accordance to w3 disability
standards) set apart GUIX from GUIXSD boxes?
Or, like fr example TAILS who now have some kind of questionaire
tour to the right download.

There are some things I am collection thoughts on, where the
actual output of them is slowed down by working on too many texts
at the same time.

> More importantly, I think that someone who cannot be bothered to read
> this will not install the thing at all since installing requires you to
> read the much longer installation instructions.  Of course we want them
> to be as small as possible, but I don’t think that’ll be a single line
> anytime soon.
>
> I hope this makes sense!
>
> Thanks for your feedback,
> Ludo’.
>
>
>

-- 
ng

bug#22588: root: UNEXPECTED INCONSISTENCY; RUN fsck MANUALLY

[Mark H Weaver]

I've been bitten by this once before, and a user on #guix did as well.
When there are problems in the root filesystem that fsck doesn't want to
fix automatically, the user is dumped into a guile prompt where PATH is
not set, and it's very inconvenient to run fsck manually.

This is what I just suggested that the user type, with apologies:

  (use-modules (ice-9 ftw) (srfi srfi-26))
  (define dirs (scandir "/gnu/store" (cut string-suffix? "e2fsprogs-1.42.13" 
<>)))
  (define e2fsck (string-append "/gnu/store/" (car dirs) "/sbin/e2fsck"))
  (system* e2fsck "/dev/XXX")

Is there a better way?

Speaking from personal experience, it's very painful to do anything
non-trivial in that REPL.  Even just adding readline would help a lot.

Maybe we should at least set PATH to include the available /bin and
/sbin directories before entering the REPL.

We should probably also handle errors from fsck specially.

Thoughts?
   Mark

bug#22572: Handling of system 'locale' field needs improvement

[Ludovic Courtès]

Mark H Weaver  skribis:

> Better yet, the value of the 'locale' field should be automatically
> added to the default value of 'locale-definitions' if it's not already
> there.  The overwhelming majority of users set their 'locale' and have
> no interest in 'locale-definitions'.

What about this?  This is not ideal in that it guesses the charset based
on the locale name, which won’t always work (the locale name is supposed
to use the normalized name, like “utf8”, whereas the real name is, say,
“UTF-8”), but it should cover 90% of the use cases.

diff --git a/doc/guix.texi b/doc/guix.texi
index 66ab384..f35a9fe 100644
--- a/doc/guix.texi
+++ b/doc/guix.texi
@@ -6452,11 +6452,12 @@ Usually, you will want to specify the default locale for the machine
 using the @code{locale} field of the @code{operating-system} declaration
 (@pxref{operating-system Reference, @code{locale}}).
 
-That locale must be among the @dfn{locale definitions} that are known to
-the system---and these are specified in the @code{locale-definitions}
-slot of @code{operating-system}.  The default value includes locale
-definitions for some widely used locales, but not for all the available
-locales, in order to save space.
+The selected locale is automatically added to the @dfn{locale
+definitions} known to the system.  Additional locale definitions can be
+specified in the @code{locale-definitions} slot of
+@code{operating-system}.  The default value includes locale definitions
+for some widely used locales, but not for all the available locales, in
+order to save space.
 
 If the locale specified in the @code{locale} field is not among the
 definitions listed in @code{locale-definitions}, @command{guix system}
diff --git a/gnu/system.scm b/gnu/system.scm
index d4759a0..324d071 100644
--- a/gnu/system.scm
+++ b/gnu/system.scm
@@ -669,14 +669,25 @@ hardware-related operations as necessary when booting a Linux container."
   "Return the directory containing the locales compiled for the definitions
 listed in OS.  The C library expects to find it under
 /run/current-system/locale."
-  ;; While we're at it, check whether the locale of OS is defined.
-  (unless (member (operating-system-locale os)
-  (map locale-definition-name
-   (operating-system-locale-definitions os)))
-(raise (condition
-(&message (message "system locale lacks a definition")
+  (define name
+(operating-system-locale os))
 
-  (locale-directory (operating-system-locale-definitions os)
+  (define definitions
+;; While we're at it, check whether the locale of OS is defined.
+(if (member (operating-system-locale os)
+(map locale-definition-name
+ (operating-system-locale-definitions os)))
+(operating-system-locale-definitions os)
+(cons (match (locale-name->definition name)
+(#f
+ (raise (condition
+ (&message
+  (message (format #f (_ "~a: invalid locale name")
+   name))
+(def def))
+  (operating-system-locale-definitions os
+
+  (locale-directory definitions
 #:libcs (operating-system-locale-libcs os)))
 
 (define (kernel->grub-label kernel)
diff --git a/gnu/system/locale.scm b/gnu/system/locale.scm
index e798827..9d695b3 100644
--- a/gnu/system/locale.scm
+++ b/gnu/system/locale.scm
@@ -1,5 +1,5 @@
 ;;; GNU Guix --- Functional package management for GNU
-;;; Copyright © 2014, 2015 Ludovic Courtès 
+;;; Copyright © 2014, 2015, 2016 Ludovic Courtès 
 ;;;
 ;;; This file is part of GNU Guix.
 ;;;
@@ -33,6 +33,7 @@
 locale-definition-source
 locale-definition-charset
 
+locale-name->definition
 locale-directory
 
 %default-locale-libcs
@@ -52,6 +53,22 @@
   (charset locale-definition-charset  ;string--e.g., "UTF-8"
(default "UTF-8")))
 
+(define %not-dot
+  (char-set-complement (char-set #\.)))
+
+(define (locale-name->definition name)
+  "Return a  corresponding to NAME, guessing the charset,
+or #f on failure."
+  (match (string-tokenize name %not-dot)
+((source charset)
+ (locale-definition (name name)
+(source source)
+(charset (if (string-ci=? charset "utf8")
+ "UTF-8"
+ charset
+(_
+ #f)))
+
 (define* (localedef-command locale
 #:key (libc (canonical-package glibc)))
   "Return a gexp that runs 'localedef' from LIBC to build LOCALE."

Thanks,
Ludo’.

bug#22558: gnupg-2.1.11 on x86_64 failed its tests many times on Hydra

[Ludovic Courtès]

Eric Bavier  skribis:

>> > * With 14 test failures.  This happened at least twice, on
>> >   hydra.gnunet.org.
>>
>> Eric Bavier reported on #guix that it failed to build on his machine
>> twice in a row, with 14 test failures.
>
> I used 'git bisect' on the gnupg repository to narrow the failures
> down. Commit ee87c653bf is the commit that introduces the failures.

Thanks for digging!  Could you report it upstream?

> Knowing this however doesn't explain why Ludo was not able to
> reproduce on his machine or why Hydra was eventually able to build it
> successfully.

This could be due to assembly using instructions available on one
machine and not the other.

Ludo’.

bug#22437: Fixing package-with-python2

[Ludovic Courtès]

Ricardo Wurmus  skribis:

> Efraim Flashner  writes:
>
>> On Wed, 03 Feb 2016 09:47:15 +0100
>> l...@gnu.org (Ludovic Courtès) wrote:
>>
>>> l...@gnu.org (Ludovic Courtès) skribis:
>>> 
>>> > An idea I haven’t taken the time to test yet would be to use
>>> > ‘properties’:
>>> >
>>> >   (define python-foobar   ;with Python 3
>>> > (package
>>> >   (name "foobar")
>>> >   ;; Specify which Python 2 variant to use.
>>> >   (properties `((python2-variant . ,(delay python2-foobar))
>>
>> This part I don't get. What's the period for?
>
> The “properties” field holds a regular alist.  Here the alist has one
> entry (a pair) with a symbol “python2-variant” as the key, and “,(delay
> python2-foobar)” as its value.
>
> The period is needed for the “dotted list” syntax, which is used to
> distinguish a pair (or an improper list) from a well-formed list.

This is a relic of the old days and probably kind of confusing to
newcomers, but since we started making this field an alist, let’s keep
it this way.

Ludo’.

bug#22437: Fixing package-with-python2

[Ludovic Courtès]

Efraim Flashner  skribis:

> On Wed, 03 Feb 2016 09:47:15 +0100
> l...@gnu.org (Ludovic Courtès) wrote:

[...]

>> This will trigger rebuilds (but with an identical result) because in
>> manually-written variants we would use “python2-foo” as the label of
>> inputs, whereas the automatic transformations keeps the original
>> “python-foo” label.
>
> rebuilds python-foo and python2-foo, or just the python2- variants?

The latter.

>> What do people think?
>
> I like it. It keeps the logic in the build-system. In terms of a speed test
> when figuring out the build/dependancy graph, how does it affect the time of
> `guix graph python2-scipy python2-matplotlib`?

It might be slightly faster, but it’s already rather fast.  :-)

--8<---cut here---start->8---
$ time guix graph python2-scipy python2-matplotlib >/dev/null

real0m0.664s
user0m0.768s
sys 0m0.056s
--8<---cut here---end--->8---


[...]

>> Does that make sense?  Any takers?  (This can be done incrementally.)
>
> It fits our "one change per commit" policy, and if we don't start at the base
> of the pyramid we'll be modifying and then removing the special variants. I
> don't mind doing the conversion process.

OK.

> Thinking aloud, I think for the time being we should keep the
> python-setuptools that are already part of the python- variants where they
> are and save that for another time.

Agreed.

Thanks for your feedback!

Ludo’.

bug#22437: Fixing package-with-python2

[Ludovic Courtès]

Andreas Enge  skribis:

> this looks really good, but I do not understand why we need the
> additional private variable, for instance %python-cython:

Glad you noticed.  :-)

> On Wed, Feb 03, 2016 at 09:47:15AM +0100, Ludovic Courtès wrote:
>> -(define-public python-cython
>> +(define %python-cython
>>(package
>>  (name "python-cython")
>>  (version "0.23.4")
>> @@ -2946,8 +2946,13 @@ programming language and the extended Cython 
>> programming language.  It makes
>>  writing C extensions for Python as easy as Python itself.")
>>  (license asl2.0)))
>>  
>> +(define-public python-cython
>> +  (package
>> +(inherit %python-cython)
>> +(properties `((python2-variant . ,(delay python2-cython))
>> +
>>  (define-public python2-cython
>> -  (package (inherit (package-with-python2 python-cython))
>> +  (package (inherit (package-with-python2 %python-cython))
>>  (name "python2-cython")
>>  (inputs
>
> If python2-cython inherits from (package-with-python2 python-cython),
> is not the only difference that it keeps the properties field? And
> would this not be harmless, as we are not going to call package-with-python2
> again? Or would this create a circular dependency with (delay python2-cython)?

So I thought!  In hindsight, I think this is unnecessary.

> (In C or Pascal, this would not be a problem

I can’t wait to see “Pasix”!  :-)

Ludo’.

bug#22587: ‘guix edit’ & ‘M-x guix-edit' typo, rename, & mode change

[myglc2]

Andreas Enge  writes:

> On Sun, Feb 07, 2016 at 02:22:36PM -0500, myglc2 wrote:
>> But, AIUI, this goes against the guix concept of an immutable store.
>> To describe and name this function to imply that one could/should edit
>> recipes in the store based on the "corner case" of root having the
>> ultimable ability to do so seems counter to how you would want to
>> encourage even a root user to proceed.
>
> Recipes are not in the store. For instance, after doing a "make install",
> they are in $PREFIX/share/guile/site/2.0/.
>
> Or maybe they are in the store after a "guix pull"?
>
> I am only using the "make install" version for a system-wide installation,
> and a git checkout for making more recent recipes available to one user.
>
> Andreas

On guixSD they are found under /root/.config/guix/latest which points,
for example, into the store like this:

latest -> /gnu/store/96s6sh92xyw0rljp3w1zxc8h3s4vb5zf-guix-latest

So it seems to me that editing these files will essenctially "corrupt" a
guix system.

bug#22546: Download-Page is "hiding" what the options actually are

[Ludovic Courtès]

Robin Vobruba  skribis:

> Being new to Guix, i went to the Download page:
> https://www.gnu.org/software/guix/download/
>
> immediately saw the 3 big options
> read their title/names
> was confused what the difference might be between "GuixSD" and "Guix Binary"
> could not find anything inside these 3 option's boxes that would help me
> read the text below them
> read the text above them
> finally understood that the first option is the OS, and the second is only
> the packag-manager

I think I’ll have to disagree.  :-)

For each option there’s a line right below the title saying what this
is.  I’m no expert in “information architecture” but I’m under the
impression that there’s little margin for improvement.

More importantly, I think that someone who cannot be bothered to read
this will not install the thing at all since installing requires you to
read the much longer installation instructions.  Of course we want them
to be as small as possible, but I don’t think that’ll be a single line
anytime soon.

I hope this makes sense!

Thanks for your feedback,
Ludo’.

bug#22573: critical error during 'guix pull'

[Ludovic Courtès]

Leo Famulari  skribis:

> On Sat, Feb 06, 2016 at 03:33:56PM +0100, Nils Gillmann wrote:
>> Hi, today 15:30 EU/Berlin Timezone I started guix pull and got this output:
>> 
>> Starting download of /tmp/guix-file.bHtiW7
>> From http://git.savannah.gnu.org/cgit/guix.git/snapshot/master.tar.gz...
>>  master.tar.gz  1KiB2.5MiB/s 00:00 [] 
>> 100.0%
>> unpacking '/gnu/store/ig37bb33y7vnpay722b541ljlqvmyjbm-guix-latest.tar.gz'...
>> 
>> gzip: stdin: not in gzip format
>> /gnu/store/9m8jg38cy0j95cb1gmi784ms85nn68vr-tar-1.28/bin/tar: Child returned 
>> status 1
>> /gnu/store/9m8jg38cy0j95cb1gmi784ms85nn68vr-tar-1.28/bin/tar: Error is not 
>> recoverable: exiting now
>> guix pull: error: failed to unpack source code
>
> Since the capabilities of hydra.gnu.org are sometimes outstripped by
> user demand, users sometimes experience repeatable network failures

This is true, but the tarball above is served by a completely different
machine, which is unlikely to be overloaded.  But yeah, maybe there was
a transient networking error on either side of the connection.

I’ve tried just now and it works fine currently, FWIW.

Thanks,
Ludo’.

bug#22587: ‘guix edit’ & ‘M-x guix-edit' typo, rename, & mode change

[Andreas Enge]

On Sun, Feb 07, 2016 at 02:22:36PM -0500, myglc2 wrote:
> But, AIUI, this goes against the guix concept of an immutable store.
> To describe and name this function to imply that one could/should edit
> recipes in the store based on the "corner case" of root having the
> ultimable ability to do so seems counter to how you would want to
> encourage even a root user to proceed.

Recipes are not in the store. For instance, after doing a "make install",
they are in $PREFIX/share/guile/site/2.0/.

Or maybe they are in the store after a "guix pull"?

I am only using the "make install" version for a system-wide installation,
and a git checkout for making more recent recipes available to one user.

Andreas

bug#22587: ‘guix edit’ & ‘M-x guix-edit' typo, rename, & mode change

[myglc2]

Andreas Enge  writes:

> On Sun, Feb 07, 2016 at 01:04:40PM -0500, myglc2 wrote:
>> TYPO:
>> "edit" (last line above) should be replaced with "view", "inspect", or
>> "examine".
>> RENAME:
>> Calling these functions 'guix edit' and 'M-x guix-edit' implies that the
>> user will be able to modify the recipe, but this is not actually the
>> case.
>
> This depends on the user's rights. In a global installation, root is allowed
> to modify. In a git checkout, one would need to do "./pre-inst-env guix edit"
> like with all other guix commands.
>
> Andreas

Of course, running as root, 'guix edit' opens the recipe read-only and
from there, root can do whatever he/she likes.

But, AIUI, this goes against the guix concept of an immutable store.

To describe and name this function to imply that one could/should edit
recipes in the store based on the "corner case" of root having the
ultimable ability to do so seems counter to how you would want to
encourage even a root user to proceed.

bug#22587: ‘guix edit’ & ‘M-x guix-edit' typo, rename, & mode change

[Andreas Enge]

On Sun, Feb 07, 2016 at 01:04:40PM -0500, myglc2 wrote:
> TYPO:
> "edit" (last line above) should be replaced with "view", "inspect", or
> "examine".
> RENAME:
> Calling these functions 'guix edit' and 'M-x guix-edit' implies that the
> user will be able to modify the recipe, but this is not actually the
> case.

This depends on the user's rights. In a global installation, root is allowed
to modify. In a git checkout, one would need to do "./pre-inst-env guix edit"
like with all other guix commands.

Andreas

bug#22587: ‘guix edit’ & ‘M-x guix-edit' typo, rename, & mode change

[myglc2]

Alex Kost  writes:
[...]
> The purpose of "M-x guix-edit" Emacs command (and "guix edit" shell
> command) is just to show you the source code of the package.  This
> source is usually placed in the store, and you shouldn't edit it.  If
> you are going to contribute to guix, (info "(guix) Building from Git")
> is the right way.

>From guix INFO:

6.2 Invoking ‘guix edit’
[...]
launches the program specified in the ‘VISUAL’ or in the ‘EDITOR’
environment variable to edit the recipe of GCC 4.8.4 and that of Vim."

TYPO:

"edit" (last line above) should be replaced with "view", "inspect", or
"examine".

RENAME:

Calling these functions 'guix edit' and 'M-x guix-edit' implies that the
user will be able to modify the recipe, but this is not actually the
case. The functions should be given a more informative and accurate
name, such as: 'guix view', 'guix inspect', or 'guix examine'.

MODE CHANGE:

In emacs, read-only .scm files should be opened in view-mode.

bug#22565: Cannot talk to upowerd over D-Bus

[Ludovic Courtès]

tags 22565 notabug
close 22565
thanks

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

> On GuixSD as of v0.9.0-1430-g234ea8a, attempts to talk to upowerd over
> D-Bus fail:
>
> $ sudo dbus-send --print-reply --system --dest=org.freedesktop.UPower 
> /org/freedesktop/UPower org.freedesktop.UPower.Suspend
> Error org.freedesktop.DBus.Error.UnknownMethod: Method "Suspend" with 
> signature "" on interface "org.freedesktop.UPower" doesn't exist
>
> See
> .

Actually the above method simply does not exist (the blog post
at  is several
years old.)

If we invoke methods that do exist, everything is fine:

--8<---cut here---start->8---
$ dbus-send --print-reply --system --dest=org.freedesktop.UPower 
/org/freedesktop/UPower org.freedesktop.UPower.GetCriticalAction
method return time=1454855982.307374 sender=:1.1 -> destination=:1.51 
serial=449 reply_serial=2
   string "PowerOff"
$ dbus-send --print-reply --system --dest=org.freedesktop.UPower 
/org/freedesktop/UPower org.freedesktop.UPower.GetDisplayDevice
method return time=1454855987.010638 sender=:1.1 -> destination=:1.52 
serial=450 reply_serial=2
   object path "/org/freedesktop/UPower/devices/DisplayDevice"
$ dbus-send --print-reply --system --dest=org.freedesktop.UPower 
/org/freedesktop/UPower org.freedesktop.UPower.EnumerateDevices
method return time=1454856012.554536 sender=:1.1 -> destination=:1.53 
serial=451 reply_serial=2
   array [
  object path "/org/freedesktop/UPower/devices/line_power_AC"
  object path "/org/freedesktop/UPower/devices/battery_BAT0"
   ]
--8<---cut here---end--->8---

The thing is, poweroff/suspend/hibernate is now delegated to logind (see
src/linux/up-backend.c in UPower.)

Indeed, the ‘loginctl’ command (or, presumably, other elogind clients
such as GNOME or Xfce) can talk to elogind:

--8<---cut here---start->8---
$ loginctl suspend 
Failed to suspend: Interactive authentication required.
--8<---cut here---end--->8---

I suppose we need some polkit magic to allow unprivileged users to
invoke those actions, but that’s a different issue.

Thanks,
Ludo’.

bug#21806: TeX Live: missing biber executable

[Ludovic Courtès]

Clément  skribis:

> Ludovic Courtès  writes:
>
>> Did you have a chance to look into it?  :-)
>
> I started, but I got scared by the number of dependencies. I
> still intend to work on it though, but will be a little short on
> time until the end of the month. Is that okay?

Sure, no problem.  I just wanted to know if you had given up or stumbled
upon a problem where we could help.  :-)

Thanks,
Ludo’.

bug#22437: Fixing package-with-python2

[Andreas Enge]

Hello,

this looks really good, but I do not understand why we need the
additional private variable, for instance %python-cython:

On Wed, Feb 03, 2016 at 09:47:15AM +0100, Ludovic Courtès wrote:
> -(define-public python-cython
> +(define %python-cython
>(package
>  (name "python-cython")
>  (version "0.23.4")
> @@ -2946,8 +2946,13 @@ programming language and the extended Cython 
> programming language.  It makes
>  writing C extensions for Python as easy as Python itself.")
>  (license asl2.0)))
>  
> +(define-public python-cython
> +  (package
> +(inherit %python-cython)
> +(properties `((python2-variant . ,(delay python2-cython))
> +
>  (define-public python2-cython
> -  (package (inherit (package-with-python2 python-cython))
> +  (package (inherit (package-with-python2 %python-cython))
>  (name "python2-cython")
>  (inputs

If python2-cython inherits from (package-with-python2 python-cython),
is not the only difference that it keeps the properties field? And
would this not be harmless, as we are not going to call package-with-python2
again? Or would this create a circular dependency with (delay python2-cython)?
(In C or Pascal, this would not be a problem, one could simply declare
things before they are used, and that is it.)

It would be more elegant to drop the additional variable if possible.

Andreas

bug#22437: Fixing package-with-python2

[Ricardo Wurmus]

Efraim Flashner  writes:

> On Wed, 03 Feb 2016 09:47:15 +0100
> l...@gnu.org (Ludovic Courtès) wrote:
>
>> l...@gnu.org (Ludovic Courtès) skribis:
>> 
>> > An idea I haven’t taken the time to test yet would be to use
>> > ‘properties’:
>> >
>> >   (define python-foobar   ;with Python 3
>> > (package
>> >   (name "foobar")
>> >   ;; Specify which Python 2 variant to use.
>> >   (properties `((python2-variant . ,(delay python2-foobar))
>
> This part I don't get. What's the period for?

The “properties” field holds a regular alist.  Here the alist has one
entry (a pair) with a symbol “python2-variant” as the key, and “,(delay
python2-foobar)” as its value.

The period is needed for the “dotted list” syntax, which is used to
distinguish a pair (or an improper list) from a well-formed list.

~~ Ricardo

bug#22550: (require 'magit) produces error: "no such file or directory" "dash"

[Alex Kost]

Alex Kost (2016-02-04 23:00 +0300) wrote:

[...]
> So to recap, you found 2 issues:
>
> 1. Emacs packages installed in a system profile are not automatically
>added to 'load-path'.

Fixed in commit 004ea62¹.  However, it will take effect when the new
source of "guix-emacs.el" will be used.  It will happen only after we'll
update our guix-devel snapshot (last time it was in commit 2c77615).

> 2. With the current EMACSLOADPATH, a wrong "site-lisp.el" is loaded, so
>"M-x guix-…" commands are not autoloaded.

This one is fixed in commit b3fee14² (it will take effect when
EMACSLOADPATH will be changed, i.e. after "guix pull", "guix system
reconfigure" and rebooting).

¹ 
http://git.savannah.gnu.org/cgit/guix.git/commit/?id=004ea62955a92f69efeaa90debde4e626acb6143
² 
http://git.savannah.gnu.org/cgit/guix.git/commit/?id=b3fee145df2a2cb310ced2e7f34e0a2b6083e661

-- 
Alex

bug#22437: Fixing package-with-python2

[Efraim Flashner]

On Wed, 03 Feb 2016 09:47:15 +0100
l...@gnu.org (Ludovic Courtès) wrote:

> l...@gnu.org (Ludovic Courtès) skribis:
> 
> > An idea I haven’t taken the time to test yet would be to use
> > ‘properties’:
> >
> >   (define python-foobar   ;with Python 3
> > (package
> >   (name "foobar")
> >   ;; Specify which Python 2 variant to use.
> >   (properties `((python2-variant . ,(delay python2-foobar))

This part I don't get. What's the period for?

> >   (define python2-foobar
> > (package (inherit python-foobar)
> >   ;; … stuff beyond the mechanical python 2→3 switch…
> >   ))
> >
> > ‘package-with-python2’ would honor this ‘python2-variant’ property.
> 
> Here’s a first stab at this.
> 
> As an example, I modified ‘python-matplotlib’ to use that feature, so we
> can test that ‘python2-scipy’ is using the right ‘python2-matplotlib’:
> 
> --8<---cut here---start->8---
> $ ./pre-inst-env guix build python2-matplotlib -d 2>/dev/null
> /gnu/store/07zr2pqg61b742czb2aqyisml2i90r4a-python2-matplotlib-1.4.3.drv
> $ ./pre-inst-env guix build python2-scipy -d 2>/dev/null
> /gnu/store/8yhxdbyjvx2xwynpqqcrj9ilksd2pb01-python2-scipy-0.16.0.drv
> $ guix gc --references 
> /gnu/store/8yhxdbyjvx2xwynpqqcrj9ilksd2pb01-python2-scipy-0.16.0.drv | grep 
> python2-matplotlib
> /gnu/store/07zr2pqg61b742czb2aqyisml2i90r4a-python2-matplotlib-1.4.3.drv
> --8<---cut here---end--->8---
> 
> This will trigger rebuilds (but with an identical result) because in
> manually-written variants we would use “python2-foo” as the label of
> inputs, whereas the automatic transformations keeps the original
> “python-foo” label.

rebuilds python-foo and python2-foo, or just the python2- variants?

> What do people think?

I like it. It keeps the logic in the build-system. In terms of a speed test
when figuring out the build/dependancy graph, how does it affect the time of
`guix graph python2-scipy python2-matplotlib`?

> I can apply this patch of the approach sounds good to you.  I think we
> should probably do one commit per rewrite for clarity.
> 
> We should probably start with the lowest level, like python2-pycairo and
> python2-pygobject and even python itself, because if we fix them then
> some of the higher-level stuff won’t even need their own
> ‘python2-variant’ property.  For instance, if python, pycairo, and
> pygobject have their ‘python2-variant’ set, then we no longer need this:
> 
> --8<---cut here---start->8---
> (define-public python2-matplotlib
>   (let ((matplotlib (package-with-python2 %python-matplotlib)))
> (package (inherit matplotlib)
>   ;; Make sure to use special packages for Python 2 instead
>   ;; of those automatically rewritten by package-with-python2.
>   (propagated-inputs
>`(("python2-pycairo" ,python2-pycairo)
>  ("python2-pygobject-2" ,python2-pygobject-2)
>  ("python2-tkinter" ,python-2 "tk")
>  ,@(fold alist-delete (package-propagated-inputs matplotlib)
>  '("python-pycairo" "python-pygobject" "python-tkinter")))
> --8<---cut here---end--->8---
> 
> … and as a consequence, we don’t need a ‘python2-variant’ in
> ‘python-matplotlib’.
> 
> Does that make sense?  Any takers?  (This can be done incrementally.)

It fits our "one change per commit" policy, and if we don't start at the base
of the pyramid we'll be modifying and then removing the special variants. I
don't mind doing the conversion process.

> Thanks,
> Ludo’.
> 

Thinking aloud, I think for the time being we should keep the
python-setuptools that are already part of the python- variants where they
are and save that for another time.

-- 
Efraim Flashner  אפרים פלשנר
GPG key = A28B F40C 3E55 1372 662D  14F7 41AA E7DC CA3D 8351
Confidentiality cannot be guaranteed on emails sent or received unencrypted


pgpHbDO5NNYF6.pgp
Description: OpenPGP digital signature

bug#22550: (require 'magit) produces error: "no such file or directory" "dash"

[Alex Kost]

Ludovic Courtès (2016-02-06 15:38 +0300) wrote:

> Alex Kost  skribis:
>
>> myglc2 (2016-02-05 17:52 +0300) wrote:
>
> [...]
>
>>> b) make a new/improved 'guix-edit' that prompts for guix-directory if it
>>>is not already not set, perhaps also refering the user to "8.1
>>>Building from Git".
>>
>> As I see it, 'M-x guix-edit' should do the same as 'guix edit' in shell,
>> i.e. it should open a package file without additional prompting.  OTOH I
>> think it would be good to improve 'guix-edit' so that with C-u it will
>> prompt for a directory with guix packages.
>
> Yes, that would be nice.  However, AIUI, it would require spawning a new
> Guix REPL for this specific ‘guix-directory’ value, no?

No, not at all.  The attached patch implements this.

>From 292c5f137f6cc3cf72e71e2dd5fa40f38fc7d7bb Mon Sep 17 00:00:00 2001
From: Alex Kost 
Date: Sun, 7 Feb 2016 11:08:57 +0300
Subject: [PATCH] emacs: 'C-u M-x guix-edit' prompts for directory.

* emacs/guix-base.el (guix-find-location, guix-edit): Add optional
  'directory' argument.
---
 emacs/guix-base.el | 21 ++---
 1 file changed, 14 insertions(+), 7 deletions(-)

diff --git a/emacs/guix-base.el b/emacs/guix-base.el
index 9f9f258..8282f2d 100644
--- a/emacs/guix-base.el
+++ b/emacs/guix-base.el
@@ -63,17 +63,17 @@ This directory is used to define location of the packages.")
 
 (add-hook 'guix-after-start-repl-hook 'guix-set-directory)
 
-(defun guix-find-location (location)
+(defun guix-find-location (location &optional directory)
   "Go to LOCATION of a package.
 LOCATION is a string of the form:
 
   \"PATH:LINE:COLUMN\"
 
 If PATH is relative, it is considered to be relative to
-`guix-directory'."
+DIRECTORY (`guix-directory' by default)."
   (cl-multiple-value-bind (path line col)
   (split-string location ":")
-(let ((file (expand-file-name path guix-directory))
+(let ((file (expand-file-name path (or directory guix-directory)))
   (line (string-to-number line))
   (col  (string-to-number col)))
   (find-file file)
@@ -113,12 +113,19 @@ See `guix-packages-profile'."
 (guix-packages-profile profile generation system?)))
 
 ;;;###autoload
-(defun guix-edit (id-or-name)
-  "Edit (go to location of) package with ID-OR-NAME."
-  (interactive (list (guix-read-package-name)))
+(defun guix-edit (id-or-name &optional directory)
+  "Edit (go to location of) package with ID-OR-NAME.
+See `guix-find-location' for the meaning of package location and
+DIRECTORY.
+Interactively, with prefix argument, prompt for DIRECTORY."
+  (interactive
+   (list (guix-read-package-name)
+ (when current-prefix-arg
+   (read-directory-name "Directory with Guix modules: "
+guix-directory
   (let ((loc (guix-package-location id-or-name)))
 (if loc
-(guix-find-location loc)
+(guix-find-location loc directory)
   (message "Couldn't find package location."
 
 
-- 
2.6.3