Add the git commit id to the generation information

[Roel Janssen]

Dear Guix,

I have a feature request.

When I run 'guix pull', install a package, run 'guix pull' again (on
another day), and install another package, I'd get two generations:

> Generation 181  May 22 2017 11:47:37
>  + haunt0.2.1   out 
> /gnu/store/x2bkpzrdbaxavl29r2xg0fip1jjici9q-haunt-0.2.1
>
> Generation 182  May 24 2017 09:52:06(current)
>  + guile-commonmark 0.1 out 
> /gnu/store/k8vq65czfb8k4hvvjvsca34scd9xsxik-guile-commonmark-0.1

Now, if I'd like to go to the Guix packages source code of generation
181, I can only guess at which actual state of the Guix repository this
was, because this timestamp is the timestamp of creating the generation,
not the timestamp of the Guix package state.  So, I'd like to propose to
add the commit id to the generation like so:

> Generation 181  May 22 2017 11:47:37
> (ae548434337cddf9677a4cd52b9370810b2cc9b6)
>  + haunt0.2.1   out 
> /gnu/store/x2bkpzrdbaxavl29r2xg0fip1jjici9q-haunt-0.2.1
>
> Generation 182  May 24 2017 09:52:06(current)
>  + guile-commonmark 0.1 out 
> /gnu/store/k8vq65czfb8k4hvvjvsca34scd9xsxik-guile-commonmark-0.1

So, 'current' is the one that is installed at that time.  Any other
should be traceable through the git commit ID.

This would probably require us to have the repository information
available when building the tarball that will be downloaded by 'guix
pull'.  I think this feature is very important because it makes the
generations traceable to the Guix source code, which is needed for
reproducing the same generation.

Is this something we could make?  And can we live with the implicit
requirement to have the git repository information available when
building the source tarballs used by 'guix pull'?

Kind regards,
Roel Janssen

Re: User-Friendlyness of Guix and non-scaryness, printing messages

[Roel Janssen]

Leo Famulari writes:

> On Sun, May 28, 2017 at 08:44:44PM +0200, Danny Milosavljevic wrote:
>> Ideally, a successful build & installation of a package should look
>> like this:
>> 
>> $ guix package -i foobar
>> $ 
>
> Silence is golden!
>
>> Nothing else.  If you can't help it, then:
>> 
>> $ guix package -i foobar
>> Package foobar in version 2.3.2 has been successfully installed into your 
>> profile.
>> $ 
>
> [...]
>
>> For a successful installation it should *never* print (as it does now):
>> 
>> $ guix package -i foobar
>> ...aphics/opentype 
>> -I/tmp/guix-build-webkitgtk-2.16.3.drv-0/webkitgtk-2.16.3/Source/WebCore/platform/graphics/transforms
>>  
>> -I/tmp/guix-build-webkitgtk-2.16.3.drv-0/webkitgtk-2.16.3/Source/WebCore/platform/mediastream
>>  
>> -I/tmp/guix-build-webkitgtk-2.16.3.drv-0/webkitgtk-2.16.3/Source/WebCore/platform/mediastream/libwebrtc
>>  
>> -I/tmp/guix-build-webkitgtk-2.16.3.drv-0/webkitgtk-2.16.3/Source/WebCore/platform/mock
>>  
>> -I/tmp/guix-build-webkitgtk-2.16.3.drv-0/webkitgtk-2.16.3/Source/WebCore/platform/mock/mediasource
>>  
>> -I/tmp/guix-build-webkitgtk-2.16.3.drv-0/webkitgtk-2.16.3/Source/WebCore/platform/network
>>  
>> -I/tmp/guix-build-webkitgtk-2.16.3.drv-0/webkitgtk-2.16.3/Source/WebCore/platform/sql
>>  
>> -I/tmp/guix-build-webkitgtk-2.16.3.drv-0/webkitgtk-2.16.3/Source/WebCore/platform/text
>>  
>> -I/tmp/guix-build-webkitgtk-2.16.3.drv-0/webkitgtk-2.16.3/Source/WebCore/platform/text/icu
>>  
>> -I/tmp/guix-build-webkitgtk-2.16.3.drv-0/webkitgtk-2.16.3/Source/WebCore/plugins
>>  -I/tmp/guix-build-webkitgtk-2.16.3.drv-0/webkitgtk-2.16.3/
>
> This sample omits the most useful output, which is the summary of what
> will be done. In my opinion, a successful run of `guix package` should
> either print this summary and the name of the new generation, or be as
> verbose as it is now.
>
>> I think that a line containing something like
>> "36pqsgbqi7n89sqrp2hyk3gxm8zv" (like install-file would print,
>> too) should never appear in front of the user in normal operation.
>> 
> Perhaps for `guix package`, but I disagree for `guix build` and others.
> It prints *only* the new store items on stdout, and this makes it very
> easy to compose Guix commands. We should not break this.

I agree.  'guix build' should be as verbose as it is now.  It is
actually very useful for detecting little things like missing
dependencies or wrong configuration options when building a package.

But I think 'guix package' can be made a lot more user-friendly by not
showing the build output (by default).  The summary of what will be
installed, and some progress indicator or at least something moving to
show the user it's doing something, and eventually the success or
failure message is enough.

You know what would be cool?  A progress indicator like so:

Building derivation 6 of 110..

With '6' progressing up to '110' as soon as a build succeeds.

It would be much more useful to me than to see these g++ commands (when
installing programs).

>> Some programmer (!) colleagues of mine actually remarked something
>> like "what is THAT? Looks scary" when they looked at what guix prints
>> when I install something in Guix.
>
> I understand that your colleagues share your opinion, but they are few,
> and don't even use Guix, so we should not take this small sample too
> seriously. We can all look at the interfaces of software or machines
> that we don't use and feel confused, but this feeling doesn't mean very
> much, in my opinion. I remember being mystified by car dashboards as
> child. Since I learned to drive, I never think twice about them, and I
> drive different cars and trucks often.
>
> Command-line interfaces are not suitable for usage by "non-technical
> users" anyways; they demand a GUI. Most of us are comfortable on the
> command-line, but we should not forget that we are in an extremely small
> minority. It would be great if everyone could learn to use their
> computers with the command-line, which offers great power and
> flexibility, but it's not a realistic goal, especially as new computer
> users eschew "real" computers in favor of mobile phones.

But at least we can try to make them more non-technical-user-friendly
wherever it doesn't hurt us.  And I think 'guix package' is such a
case.

We are also hiding a lot of information on 'guix package
--list-generations', because we only display the difference between two
generations.   I think it looks much better in practice than it did
before.

> So, I'm wary of sacrificing a flexible and powerful CLI on behalf of
> users who really will never use a CLI. Now, I'm not saying there is
> nothing to improve. Rather, I'm saying that the existing Guix CLI is
> pretty good, and we should be careful about changing it.

I don't think we are making the CLI less powerful by not showing the
build output in the 'guix package' command.  When the build fails, you
can review the build log.  And a failure is something you don't expect
when you a

`install-file' should print out verbose logs

[Arun Isaac]

`install-file' in (guix build utils) should print out verbose logs just
as `copy-recursively' does. Something like:

(format log-port "~a -> ~a~%" source destination)

It's nice to have flowing verbose output when building a package. I
believe it is "more reassuring" than waiting at a blank screen with a
long pause when files are being installed.

Putting the logging in the `install-file' procedure itself, will save us
the trouble of having to implement logging manually everywhere
`install-file' is used.

In an earlier conversation at
https://debbugs.gnu.org/cgi/bugreport.cgi?bug=26941#26 , Ludo said that
he's neither for or against this proposal, and that we can implement it
if there is enough support from the community.

So, please share your thoughts.

Thank you! :-)

Re: User-Friendlyness of Guix and non-scaryness, printing messages

[Ricardo Wurmus]

> Previously, I thought that the reason that guix prints so much is that
> it doesn't log it to a file.  But it turns out that it does log it (at
> least it has a build log per derivation), also in the failure case.
> Why print it then when there's no failure?  It doesn't help the user
> at all.  [They’re] not gonna frame the output and hang it on a wall :)

I agree that Guix is too verbose by default.  It would be sufficient if
Guix told the user that it is building from source for some reason.
Upon failure it can print the location of the build log.

--
Ricardo

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

Re: Add the git commit id to the generation information

[Ricardo Wurmus]

Hi Roel,

> I have a feature request.
>
> When I run 'guix pull', install a package, run 'guix pull' again (on
> another day), and install another package, I'd get two generations:
>
>> Generation 181  May 22 2017 11:47:37
>>  + haunt0.2.1   out 
>> /gnu/store/x2bkpzrdbaxavl29r2xg0fip1jjici9q-haunt-0.2.1
>>
>> Generation 182  May 24 2017 09:52:06(current)
>>  + guile-commonmark 0.1 out 
>> /gnu/store/k8vq65czfb8k4hvvjvsca34scd9xsxik-guile-commonmark-0.1
>
> Now, if I'd like to go to the Guix packages source code of generation
> 181, I can only guess at which actual state of the Guix repository this
> was, because this timestamp is the timestamp of creating the generation,
> not the timestamp of the Guix package state.  So, I'd like to propose to
> add the commit id to the generation like so:
>
>> Generation 181  May 22 2017 11:47:37
>> (ae548434337cddf9677a4cd52b9370810b2cc9b6)
>>  + haunt0.2.1   out 
>> /gnu/store/x2bkpzrdbaxavl29r2xg0fip1jjici9q-haunt-0.2.1
>>
>> Generation 182  May 24 2017 09:52:06(current)
>>  + guile-commonmark 0.1 out 
>> /gnu/store/k8vq65czfb8k4hvvjvsca34scd9xsxik-guile-commonmark-0.1

What would be the expected behaviour in the presence of
GUIX_PACKAGE_PATH?  I could have had GUIX_PACKAGE_PATH set pointing to a
module containing a custom variant of haunt.

I do agree that it would be very useful to know more about the state of
Guix for any given generation.  However, that state is more complex than
a single commit.

--
Ricardo

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

Re: Add the git commit id to the generation information

[Roel Janssen]

Ricardo Wurmus writes:

> Hi Roel,
>
>> I have a feature request.
>>
>> When I run 'guix pull', install a package, run 'guix pull' again (on
>> another day), and install another package, I'd get two generations:
>>
>>> Generation 181  May 22 2017 11:47:37
>>>  + haunt0.2.1   out 
>>> /gnu/store/x2bkpzrdbaxavl29r2xg0fip1jjici9q-haunt-0.2.1
>>>
>>> Generation 182  May 24 2017 09:52:06(current)
>>>  + guile-commonmark 0.1 out 
>>> /gnu/store/k8vq65czfb8k4hvvjvsca34scd9xsxik-guile-commonmark-0.1
>>
>> Now, if I'd like to go to the Guix packages source code of generation
>> 181, I can only guess at which actual state of the Guix repository this
>> was, because this timestamp is the timestamp of creating the generation,
>> not the timestamp of the Guix package state.  So, I'd like to propose to
>> add the commit id to the generation like so:
>>
>>> Generation 181  May 22 2017 11:47:37
>>> (ae548434337cddf9677a4cd52b9370810b2cc9b6)
>>>  + haunt0.2.1   out 
>>> /gnu/store/x2bkpzrdbaxavl29r2xg0fip1jjici9q-haunt-0.2.1
>>>
>>> Generation 182  May 24 2017 09:52:06(current)
>>>  + guile-commonmark 0.1 out 
>>> /gnu/store/k8vq65czfb8k4hvvjvsca34scd9xsxik-guile-commonmark-0.1
>
> What would be the expected behaviour in the presence of
> GUIX_PACKAGE_PATH?  I could have had GUIX_PACKAGE_PATH set pointing to a
> module containing a custom variant of haunt.
>
> I do agree that it would be very useful to know more about the state of
> Guix for any given generation.  However, that state is more complex than
> a single commit.

Oh, indeed..  Any suggestions?

My other thought on this, is to add a tagging mechanism, that users can
simply add tags to a generation, of which one could be the commit id.

I think that having the upstream git commit ID already improves the
situation.  Adding external repositories is not something the upstream
distribution can take care of.  Maybe if we would add a different, more
formal way of allowing external repositories, that could be dealt with
more easily.  (Is this what 'channels' could do?)

Kind regards,
Roel Janssen

Re: [PATCH] git-download: Fix 'git-predicate' to use absolute paths.

[Christopher Baines]

On 25/05/17 16:58, Christopher Baines wrote:
> git ls-files will return paths relative to the repository directory. This
> commit prepends the repository directory to those paths when calling lstat,
> such that 'git-predicate' works if the current working directory is not the
> repository directory.

I've just hit this issue again, but in a different way. This way is easy
to reproduce though.

  guix build -e "(begin (use-modules (gnu packages package-management))
(current-guix))"

If you run that while the current working directory is not the root of
the repository, you should get:

  ERROR: In procedure lstat: No such file or directory: ".dir-locals.el"




signature.asc
Description: OpenPGP digital signature

Re: "guix system" summary output?

[Danny Milosavljevic]

On Tue, 30 May 2017 03:47:46 +0200
Danny Milosavljevic  wrote:

> > This sample omits the most useful output, which is the summary of what
> > will be done.  
> 
> Just tested with the spinner so I could actually (potentially) see the 
> summary.
> 
> It seems that "guix package" prints such a summary (yay!), but "guix system 
> reconfigure" doesn't.  The latter just starts downloading stuff and then 
> builds stuff - no summary anywhere:

And now it does print the summary.  I've got no idea what's different now.

guix system: warning: Your Guix installation is 477 days old.
guix system: warning: Consider running 'guix pull' followed by
'guix system reconfigure' to get up-to-date packages and security updates.

The following derivations will be built:
   /gnu/store/0sm3cp68x056gq23a93l37bb725vhfi4-system.drv
   /gnu/store/jmnp4mfa5iv8ra01gzndb4xlf7kkw2ji-grub.cfg.drv
   /gnu/store/lmwi7z6s8601swnyyygv9ycdq6bjcmy8-m4-1.4.18.tar.xz.drv
...
\

[PATCH] doc: Move the NGinx service configuration documentation together.

[Christopher Baines]

* doc/guix.texi (Web Services): Add documentation for
  nginx-upstream-configuration and nginx-location-configuration.
  (VPN Services): Remove documentation for nginx-upstream-configuration and
  nginx-location-configuration.
---
 doc/guix.texi | 115 +-
 1 file changed, 58 insertions(+), 57 deletions(-)

diff --git a/doc/guix.texi b/doc/guix.texi
index f39724309..0f2c11bd3 100644
--- a/doc/guix.texi
+++ b/doc/guix.texi
@@ -13530,6 +13530,64 @@ Whether the server should add its configuration to 
response.
 @end table
 @end deftp
 
+@deftp {Data Type} nginx-upstream-configuration
+Data type representing the configuration of an nginx @code{upstream}
+block.  This type has the following parameters:
+
+@table @asis
+@item @code{name}
+Name for this group of servers.
+
+@item @code{servers}
+Specify the addresses of the servers in the group.  The address can be
+specified as a IP address (e.g. @samp{127.0.0.1}), domain name
+(e.g. @samp{backend1.example.com}) or a path to a UNIX socket using the
+prefix @samp{unix:}.  For addresses using an IP address or domain name,
+the default port is 80, and a different port can be specified
+explicitly.
+
+@end table
+@end deftp
+
+@deftp {Data Type} nginx-location-configuration
+Data type representing the configuration of an nginx @code{location}
+block.  This type has the following parameters:
+
+@table @asis
+@item @code{uri}
+URI which this location block matches.
+
+@anchor{nginx-location-configuration body}
+@item @code{body}
+Body of the location block, specified as a string. This can contain many
+configuration directives.  For example, to pass requests to a upstream
+server group defined using an @code{nginx-upstream-configuration} block,
+the following directive would be specified in the body @samp{proxy_pass
+http://upstream-name;}.
+
+@end table
+@end deftp
+
+@deftp {Data Type} nginx-named-location-configuration
+Data type representing the configuration of an nginx named location
+block.  Named location blocks are used for request redirection, and not
+used for regular request processing.  This type has the following
+parameters:
+
+@table @asis
+@item @code{name}
+Name to identify this location block.
+
+@item @code{body}
+@xref{nginx-location-configuration body}, as the body for named location
+blocks can be used in a similar way to the
+@code{nginx-location-configuration body}.  One restriction is that the
+body of a named location block cannot contain location blocks.
+
+@end table
+@end deftp
+
+
 @node DNS Services
 @subsubsection DNS Services
 @cindex DNS (domain name system)
@@ -14296,63 +14354,6 @@ Defaults to @samp{#f}.
 @c %end of automatic openvpn-server documentation
 
 
-@deftp {Data Type} nginx-upstream-configuration
-Data type representing the configuration of an nginx @code{upstream}
-block.  This type has the following parameters:
-
-@table @asis
-@item @code{name}
-Name for this group of servers.
-
-@item @code{servers}
-Specify the addresses of the servers in the group.  The address can be
-specified as a IP address (e.g. @samp{127.0.0.1}), domain name
-(e.g. @samp{backend1.example.com}) or a path to a UNIX socket using the
-prefix @samp{unix:}.  For addresses using an IP address or domain name,
-the default port is 80, and a different port can be specified
-explicitly.
-
-@end table
-@end deftp
-
-@deftp {Data Type} nginx-location-configuration
-Data type representing the configuration of an nginx @code{location}
-block.  This type has the following parameters:
-
-@table @asis
-@item @code{uri}
-URI which this location block matches.
-
-@anchor{nginx-location-configuration body}
-@item @code{body}
-Body of the location block, specified as a string. This can contain many
-configuration directives.  For example, to pass requests to a upstream
-server group defined using an @code{nginx-upstream-configuration} block,
-the following directive would be specified in the body @samp{proxy_pass
-http://upstream-name;}.
-
-@end table
-@end deftp
-
-@deftp {Data Type} nginx-named-location-configuration
-Data type representing the configuration of an nginx named location
-block.  Named location blocks are used for request redirection, and not
-used for regular request processing.  This type has the following
-parameters:
-
-@table @asis
-@item @code{name}
-Name to identify this location block.
-
-@item @code{body}
-@xref{nginx-location-configuration body}, as the body for named location
-blocks can be used in a similar way to the
-@code{nginx-location-configuration body}.  One restriction is that the
-body of a named location block cannot contain location blocks.
-
-@end table
-@end deftp
-
 @node Network File System
 @subsubsection Network File System
 @cindex NFS
-- 
2.13.0

Re: User-Friendlyness of Guix and non-scaryness, printing messages

[Arun Isaac]

> But I think 'guix package' can be made a lot more user-friendly by not
> showing the build output (by default).  The summary of what will be
> installed, and some progress indicator or at least something moving to
> show the user it's doing something, and eventually the success or
> failure message is enough.

Is it possible to have `guix package' NOT build from source? I really
hate it when big packages like icecat, epiphany, or libreoffice start
building on my machine. It takes about a day for each one of these
packages to build on my machine, and they generally swap so much into
HDD, that I can hardly do anything else when building. Because of this
inconvenience, I keep postponing upgrading my packages.

Also, sometimes having to "--fallback" to building source is such a
pain. I think the end user needs a Debian-like experience (or like other
conventional non-source distros) where they can ALWAYS download the
latest packages from the repos.

Re: [PATCH] git-download: Fix 'git-predicate' to use absolute paths.

[Ludovic Courtès]

Christopher Baines  skribis:

> git ls-files will return paths relative to the repository directory. This
> commit prepends the repository directory to those paths when calling lstat,
> such that 'git-predicate' works if the current working directory is not the
> repository directory.
>
> * guix/git-download.scm (git-predicate): Prepend repository directory to the
>   file path when calling lstat.

Good catch!  Applied, thanks.

Ludo’.

Re: User-Friendlyness of Guix and non-scaryness, printing messages

[Christopher Allan Webber]

Arun Isaac writes:

>> But I think 'guix package' can be made a lot more user-friendly by not
>> showing the build output (by default).  The summary of what will be
>> installed, and some progress indicator or at least something moving to
>> show the user it's doing something, and eventually the success or
>> failure message is enough.
>
> Is it possible to have `guix package' NOT build from source? I really
> hate it when big packages like icecat, epiphany, or libreoffice start
> building on my machine. It takes about a day for each one of these
> packages to build on my machine, and they generally swap so much into
> HDD, that I can hardly do anything else when building. Because of this
> inconvenience, I keep postponing upgrading my packages.
>
> Also, sometimes having to "--fallback" to building source is such a
> pain. I think the end user needs a Debian-like experience (or like other
> conventional non-source distros) where they can ALWAYS download the
> latest packages from the repos.

There's a bug I opened about adding an --only-substitutes option:
  https://debbugs.gnu.org/cgi/bugreport.cgi?bug=26608

Ludo seems to support it, so I guess really someone just needs to
implement it.  It would result in a lot less churn for a lot of us :)

Error when including openexr

[Hartmut Goebel]

Hi guix!

I try building a package using openexr. Building fails with

/gnu/store/…-openexr-2.2.0/include/OpenEXR/ImfInt64.h:44:24:
fatal error: ImathInt64.h: No such file or directory

but file …-openexr-2.2.0/include/OpenEXR/ImathInt64.h exists.

I discovered that OpenEXR/ImfInt64.h contains

#include "ImathInt64.h"
#include "ImfNamespace.h"

Maybe this should be "OpenEXR/ImathInt64.h" (same for the other)?

-- 
Regards
Hartmut Goebel

| Hartmut Goebel  | h.goe...@crazy-compilers.com   |
| www.crazy-compilers.com | compilers which you thought are impossible |



0xBF773B65.asc
Description: application/pgp-keys

Re: enter debugger on failure

[Ludovic Courtès]

Hi!

Ricardo Wurmus  skribis:

> sometimes Guix crashes.  That’s sometimes because of existing bugs
> (often in importers) or because I’ve just added something that doesn’t
> quite work.
>
> When Guix crashes it prints a backtrace and exits.  Would it be possible
> to change that behaviour and instead enter a debug REPL where I could
> inspect values and resume after correcting the error?

‘guix system’ has a ‘--on-error’ command-line option that we could
perhaps generalize somewhat.  WDYT?

Now, two comments:

  1. importers are “for developers”, so I’m personally more tolerant if
 they’re rough on the edges ;-)

  2. one can always do:

   ./pre-inst-env guile
   scheme@…> ,use(guix scripts import)
   scheme@…> (guix-import "foo" "bar")
   ;; crash!
   scheme@…>[1] ,bt

Ludo’.

Re: Combining Guix, direnv and Emacs for environment customisation

[Ludovic Courtès]

Hi Christopher!

Christopher Baines  skribis:

> direnv [1] is an environment switcher for shells, for example, you want
> to have a specific environment variable set when working on a particular
> project, you drop a .envrc file in to the relevant directory and
> providing direnv is hooked in to your shell, it will get loaded and
> unloaded as you move in and out of that directory.
>
> 1: https://direnv.net/
>
> While direnv is useful for simple environment variables, guix
> environment can output environment variables with the --shell-paths
> option. Using guix environment in a .envrc file would look something
> like:
>
>   eval "$(guix environment --ad-hoc guile --search-paths)"
>
> There is a use_guix helper function in the direnv stdlib [2] that helps
> with this, so you can just do:
>
>   use guix --ad-hoc guile

This is pretty cool!

However, using ‘guix environment --search-paths’ is kinda unsafe: the
items mentioned in its output are not protected from GC.  This is why
‘guix environment’ normally spawns a shell or some other process while
keep its guix-daemon session open.

> I've recently become aware of emacs-direnv [3], which provides access
> to the functionality of direnv from Emacs. When the global minor mode
> is active, this means that moving around between buffers in Emacs can
> completely change the environment within Emacs. This had made my
> workflow simpler, as I now just open Emacs, and navigate to the
> relevant directory, and direnv just works behind the scenes.
>
> 3: https://github.com/wbolster/emacs-direnv

I think it’d be great Emacs-Guix could do something similar, i.e.,
associate a ‘guix environment’ to a buffer.  :-)

> One issue with this is that running guix environment from direnv will
> slow down switching buffers. To make it a bit more useable, I found
> some bash code that caches the results of running commands, and wrapped
> that around guix environment when invoked from direnv. This helps speed
> things up, but I don't think its useful in the long term.
>
> For this particular use case, it would help if guix environment was
> faster, perhaps by doing caching internally? On my system, running guix
> environment --ad-hoc guile --search-paths repeatedly takes ~2 seconds,
> I haven't looked at what the breakdown of this is yet.

I agree that we could do a lot more things with a faster ‘guix
environment’.  My guess is that it won’t be easy to go optimize, and
very hard to go below 1 second.  We should profile that and see what can
be done.

Cheers,
Ludo’.

Re: Merge zip.scm into compression.scm

[Ludovic Courtès]

Arun Isaac  skribis:

> Why does zip and related packages get their own separate file
> (gnu/packages/zip.scm)? Why not merge them into
> gnu/packages/compression.scm? zip.scm only has 4 packages.

I think it would be worth merging, indeed.  :-)

Would you like to give it a try?

Thanks,
Ludo’.

Re: User-Friendlyness of Guix and non-scaryness, printing messages

[Ludovic Courtès]

Hi Danny,

Danny Milosavljevic  skribis:

> And also the spinner integrated:
>
> diff --git a/guix/scripts/package.scm b/guix/scripts/package.scm
> index f050fad97..d9ac61122 100644
> --- a/guix/scripts/package.scm
> +++ b/guix/scripts/package.scm
> @@ -46,6 +46,7 @@
>#:use-module (srfi srfi-34)
>#:use-module (srfi srfi-35)
>#:use-module (srfi srfi-37)
> +  #:use-module (rnrs io ports)
>#:use-module (gnu packages)
>#:autoload   (gnu packages base) (canonical-package)
>#:autoload   (gnu packages guile) (guile-2.0)
> @@ -187,6 +188,27 @@ denote ranges as interpreted by 'matching-generations'."
>(else
> (leave (G_ "invalid syntax: ~a~%") pattern)
>  
> +(define previous-output-port (current-error-port))
> +
> +(define spinner-port
> +  (let ((index 0)
> +(spinner-chars "|\\-/"))
> +(define (spin)
> +  (set! index (+ index 1))
> +  (if (>= index (string-length spinner-chars))
> +(set! index 0))
> +  (display (array-ref spinner-chars index) previous-output-port)
> +  (display #\backspace previous-output-port)
> +  (flush-output-port previous-output-port))
> +(make-soft-port
> +   (vector
> +(lambda (c) (if (char=? c #\newline) (spin))) ; putc
> +(lambda (s) (if (string-contains s "\n") (spin))) ; puts
> +(lambda () #t) ; flush
> +(lambda () #f) ; getc
> +(lambda () #t)) ; close
> +   "w")))

Nice hack!  I don’t think we should incorporate it just right now; I
would prefer something that writes “building foo” or “downloading bar”
in addition to the spinner, like ‘wip-ui’ tries to do.

WDYT?

Ludo’.

Re: User-Friendlyness of Guix and non-scaryness, printing messages

[Ludovic Courtès]

Arun Isaac  skribis:

> Is it possible to have `guix package' NOT build from source?

We should definitely add an option for this.  See also
.

Ludo’.

Re: What???s next?

[Ludovic Courtès]

Hi,

Maxim Cournoyer  skribis:

> l...@gnu.org (Ludovic Courtès) writes:
>
> [...]
>
>> On GuixSD, the key of hydra.gnu.org and bayfront.guixsd.org are always
>> registered by default.  We cannot do that for someone installing Guix on
>> a foreign distro because that involves creating a file in /etc.
>
> The bayfront key is now registered by default?

Yes!

> Does it mean that bayfront is ready to be part of the
> `%default-substitute-urls'?

Not yet!

Currently it only builds for x86_64/i686, it doesn’t offload anywhere,
etc.  But the fact that it’s registered means that we should eventually
be able to transition transparently (for GuixSD users at least).

Ludo’.

Re: What’s next?

[Ludovic Courtès]

Maxim Cournoyer  skribis:

> Hi,
>
> l...@gnu.org (Ludovic Courtès) writes:
>
>> Hi Brendan,
>>
>> Brendan Tildesley  skribis:
>>
>>> One little annoyance I have is that guix takes every opportunity to
>>> update the list of substitutes when guix build, guix package -u, etc...
>>> is run, and fills my terminal with output like:
>>>
>>> substitute: updating list of substitutes from
>>> 'https://mirror.hydra.gnu.org'... 100.0%
>>> substitute: updating list of substitutes from
>>> 'https://mirror.hydra.gnu.org'... 100.0%
>>> substitute: updating list of substitutes from
>>> 'https://mirror.hydra.gnu.org'... 100.0%
>>> substitute: updating list of substitutes from
>>> 'https://mirror.hydra.gnu.org'... 100.0%
>>> ...
>>
>> I agree, it’s actually a huge annoyance.  It relates to grafts and how
>> they are implemented; I took a stab at fixing this a while back but the
>> approach turned out to be (mostly?) misguided:
>>
>>   https://bugs.gnu.org/22990
>>
>> Would be worth thinking through it again!
>
> Maybe we could make a timer variable configurable, so that at least it
> doesn't try to refresh this information at *every* guix command?

That’s not what’s happening.  When you see repeated lines that go
directly to 100%, that’s because it’s fetching metadata for just a
single package, and does that one by one.

In other cases, it fetches as many as possible at once, and uses HTTP
pipelining to send all these requests to hydra.gnu.org.

Ludo’.

Re: What's next?

[Ludovic Courtès]

Roel Janssen  skribis:

> Ludovic Courtès writes:
>
>> Pjotr Prins  skribis:
>>
>>> On Sat, May 27, 2017 at 12:16:45PM +0200, Ludovic Court??s wrote:
 On GuixSD, the key of hydra.gnu.org and bayfront.guixsd.org are always
 registered by default.  We cannot do that for someone installing Guix on
 a foreign distro because that involves creating a file in /etc.
>>>
>>> Many installs are not on GuixSD. Can't we use the key that is stored
>>> in the store itself? If /etc does not exist then use what comes
>>> with the installation.
>>
>> The current behavior is to print a warning when /etc/guix/acl (the list
>> of authorized keys) is empty or nonexistent.
>>
>> Your suggestion would be to automatically populate it, right?
>>
>> I’m mildly reluctant to that, because we’d stealthily force every user
>> into trusting our substitute servers.  OTOH I agree that the current
>> situation is not optimal.
>>
>> What do people think?
>
> Maybe we could find a mid-way here by doing the same as Fedora does with
> RPMfusion repositories: It asks the user for trusting the signing keys
> before enabling the repository.
>
> So in our case it would be something like:
> $ guix package -i emacs
> A `substitute' is available for this package on
> https://mirror.hydra.gnu.org.  This means we can download the binary
> output for this package, instead of compiling it from its source code.
> Do you want to use this substitute server with key ... for this package,
> and for future packages? [y/N]

It cannot work this way because the decision has to be made by the
sysadmin, not by unprivileged users.

Also, I like that ‘guix package’ is non-interactive.

Ludo’.

Re: "guix system" summary output?

[Ludovic Courtès]

Danny Milosavljevic  skribis:

>> This sample omits the most useful output, which is the summary of what
>> will be done.
>
> Just tested with the spinner so I could actually (potentially) see the 
> summary.
>
> It seems that "guix package" prints such a summary (yay!), but "guix system 
> reconfigure" doesn't.  The latter just starts downloading stuff and then 
> builds stuff - no summary anywhere:

Probably this relates to grafts: store items need to be
substitutable/available so we can determine whether they need to be
grafted.

What happens with ‘guix system …  --no-grafts’?

Thanks,
Ludo’.

Re: Add the git commit id to the generation information

[Ludovic Courtès]

Roel Janssen  skribis:

> Ricardo Wurmus writes:
>
>> Hi Roel,
>>
>>> I have a feature request.
>>>
>>> When I run 'guix pull', install a package, run 'guix pull' again (on
>>> another day), and install another package, I'd get two generations:
>>>
 Generation 181  May 22 2017 11:47:37
  + haunt0.2.1   out 
 /gnu/store/x2bkpzrdbaxavl29r2xg0fip1jjici9q-haunt-0.2.1

 Generation 182  May 24 2017 09:52:06(current)
  + guile-commonmark 0.1 out 
 /gnu/store/k8vq65czfb8k4hvvjvsca34scd9xsxik-guile-commonmark-0.1
>>>
>>> Now, if I'd like to go to the Guix packages source code of generation
>>> 181, I can only guess at which actual state of the Guix repository this
>>> was, because this timestamp is the timestamp of creating the generation,
>>> not the timestamp of the Guix package state.  So, I'd like to propose to
>>> add the commit id to the generation like so:
>>>
 Generation 181  May 22 2017 11:47:37
 (ae548434337cddf9677a4cd52b9370810b2cc9b6)
  + haunt0.2.1   out 
 /gnu/store/x2bkpzrdbaxavl29r2xg0fip1jjici9q-haunt-0.2.1

 Generation 182  May 24 2017 09:52:06(current)
  + guile-commonmark 0.1 out 
 /gnu/store/k8vq65czfb8k4hvvjvsca34scd9xsxik-guile-commonmark-0.1
>>
>> What would be the expected behaviour in the presence of
>> GUIX_PACKAGE_PATH?  I could have had GUIX_PACKAGE_PATH set pointing to a
>> module containing a custom variant of haunt.
>>
>> I do agree that it would be very useful to know more about the state of
>> Guix for any given generation.  However, that state is more complex than
>> a single commit.
>
> Oh, indeed..  Any suggestions?

I think this is one of the things that channels mean to address.

As a first step, once ‘guix pull’ uses Guile-Git, we can at least record
the commit of Guix.

Ludo’.

Re: [PATCH] doc: Move the NGinx service configuration documentation together.

[Ludovic Courtès]

Christopher Baines  skribis:

> * doc/guix.texi (Web Services): Add documentation for
>   nginx-upstream-configuration and nginx-location-configuration.
>   (VPN Services): Remove documentation for nginx-upstream-configuration and
>   nginx-location-configuration.

Applied, thank you!

It’s terrible that nginx documentation ended up in “VPN Services”
without anyone noticing!

Ludo’.

Re: Merge zip.scm into compression.scm

[Arun Isaac]

Ludovic Courtès writes:

> Arun Isaac  skribis:
>
>> Why does zip and related packages get their own separate file
>> (gnu/packages/zip.scm)? Why not merge them into
>> gnu/packages/compression.scm? zip.scm only has 4 packages.
>
> I think it would be worth merging, indeed.  :-)
>
> Would you like to give it a try?

Sure! Will do!

Re: What’s next?

[Ludovic Courtès]

Ricardo Wurmus  skribis:

> Ludovic Courtès  writes:

[...]

>> Oops.  Here we go:
>>
>> modified   nix/libstore/build.cc
>> @@ -2449,8 +2449,11 @@ void DerivationGoal::registerOutputs()
>>  Hash h2 = recursive ? hashPath(ht, actualPath).first : 
>> hashFile(ht, actualPath);
>>  if (h != h2)
>>  throw BuildError(
>> -format("output path `%1%' should have %2% hash `%3%', 
>> instead has `%4%'")
>> -% path % i->second.hashAlgo % printHash16or32(h) % 
>> printHash16or32(h2));
>> +format("%1% hash mismatch for output path `%2%'\n"
>> +   "  expected: %3%\n"
>> +   "  actual:   %4%")
>> +% i->second.hashAlgo % path
>> +% printHash16or32(h) % printHash16or32(h2));
>>  }
>>
>>  /* Get rid of all weird permissions.  This also checks that
>> @@ -3096,7 +3099,9 @@ void SubstitutionGoal::finished()
>>  Hash expectedHash = parseHash16or32(hashType, 
>> string(expectedHashStr, n + 1));
>>  Hash actualHash = hashType == htSHA256 ? hash.first : 
>> hashPath(hashType, destPath).first;
>>  if (expectedHash != actualHash)
>> -throw SubstError(format("hash mismatch in downloaded path 
>> `%1%': expected %2%, got %3%")
>> +throw SubstError(format("hash mismatch in downloaded path 
>> `%1%'\n"
>> +"  expected: %2%\n"
>> +"  actual:   %3%")
>>  % storePath % printHash(expectedHash) % 
>> printHash(actualHash));
>>  }
>>
>> Should we apply it?
>
> Yes, please.  This looks much better!  Thank you!

Applied!

Ludo’.

Re: User-Friendlyness of Guix and non-scaryness, printing messages

[Arun Isaac]

Christopher Allan Webber writes:

> There's a bug I opened about adding an --only-substitutes option:
>   https://debbugs.gnu.org/cgi/bugreport.cgi?bug=26608
>
> Ludo seems to support it, so I guess really someone just needs to
> implement it.  It would result in a lot less churn for a lot of us :)

Great! Nice to see that this in the pipeline...

Re: GuixSD Success with grub-efi

[Marius Bakke]

James Richardson  writes:

> I just successfully installed guixsd 0.13.0 with efi on a new HP
> laptop. I found the manual to be somewhat lacking with specific details
> on exactly how to accomplish this. I've added to my todo list to post
> more details here.

Thanks for the report! Improvements to the manual are very welcome.

FWIW I recently went through the same installation and was confused by
the fact that the example files from "/etc/configuration" in the USB
disk image differed from the manual, but that is already fixed for the
next release.

But then, I did not actually follow the manual (having written the UEFI
parts), so I'm very interested in hearing "first impressions" from a new
user :-)


signature.asc
Description: PGP signature

Re: What's next?

[Pjotr Prins]

On Tue, May 30, 2017 at 05:19:09PM +0200, Ludovic Courtes wrote:
> > A `substitute' is available for this package on
> > https://mirror.hydra.gnu.org.  This means we can download the binary
> > output for this package, instead of compiling it from its source code.
> > Do you want to use this substitute server with key ... for this package,
> > and for future packages? [y/N]
> 
> It cannot work this way because the decision has to be made by the
> sysadmin, not by unprivileged users.

The first time guix is run it is by a system administrator (almost
100% certain), typically from a binary installation.

> Also, I like that 'guix package' is non-interactive.

Sure. But it is a step that is not required on GuixSD. The key comes
with the base install of the guix package. 

Can't we just fetch the key from the store? Why does it have to be
/etc? First look in /etc. If that does not exist, fetch from the guix
package itself. It is there. /etc overrides the key in the store.

Now it is a needless manual step. I say, it is an easy thing to
automate. Automate if you can.

Maybe not the highest priority, but if we come with a solution it
should be easy to do.

Pj.

-- 

Haskell updates?

[Ricardo Wurmus]

Hey Guix,

is anyone working on Haskell updates?  Looks like we have some catching
up to do.

-- 
Ricardo

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

Re: 02/02: gnu: emacs-debbugs: Install missing file.

[myglc2]

On 05/30/2017 at 11:30 Alex Kost writes:

> alezost pushed a commit to branch master
> in repository guix.
>
> commit 91762db6fe208365e64c32c8eb5d2cfeec36ebed
> Author: Alex Kost 
> Date:   Sat May 27 11:31:03 2017 +0300
>
> gnu: emacs-debbugs: Install missing file.
> 
[...]
Way cool! Thanks - George ;-)