bug#22937: guix package fails when --substitute-urls specifies an HTTPS endpoint

[Ludovic Courtès]

Leo Famulari  skribis:

> On Thu, Mar 10, 2016 at 02:08:17PM +0100, Ludovic Courtès wrote:
>> After some more testing and tweaks, notably with
>>  and its brand new Let’s Encrypt certificate,
>> I pushed the patch as 9b7bd1b160be7c740a798c09e3b8986368b92036.
>
> With this commit, I still get the backtrace in the original report of
> this bug.

You need to make sure that ‘guix-daemon’ launches the right ‘guix
substitute’.

A simple way to do that from your Git checkout is:

  sudo ./pre-inst-env guix-daemon --build-users-group=guixbuild \
 --substitute-urls=https://mirror.guixsd.org

Make sure to stop any running guix-daemon before; on GuixSD, this goes
like this:

  sudo herd stop guix-daemon

HTH!

Ludo’.

bug#21843: Generated grub.cfg does not support encrypted roots

[Ludovic Courtès]

Andreas Enge  skribis:

> On Thu, Mar 10, 2016 at 10:17:46AM +0100, Ludovic Courtès wrote:
>> IIUC we don’t *have* to pass the UUID to ‘cryptomount’; we could also
>> pass the device name, in GRUB format
>
> Yes, but my idea was that the uuid is something we can determine
> at instantiation time. If the mapped device is /dev/sdd3, we can run
>(system* "cryptsetup" "luksUUID" "/dev/sdd3")
> and obtain the uuid.

Hmm yeah, but we don’t even do that for regular partitions.

> I suppose we could also use the grub device (hd3,msdos3) in this case,
> but I do not know what is the mapping between /dev nodes and these devices,
> and if it is actually a function that could be computed from the file name
> in /dev only or not.

‘grub-probe’ should know, I think.

>>(mapped-device
>>  (source (uuid "cb67fc72-0d54-4c88-9d4b-b225f30b0f44")) ;LUKS UUID
>>  (target "root")
>>  (type luks-device-mapping))
>> we’d have to extend  with a method to resolve UUIDs
>> (in this case, to map a UUID to a /dev node.)
>
> We can also let the users do the work (and document this in the manual),
> by having them supply all the informatin:
>
>(mapped-device
>  (source "/dev/sdd3")
>  (uuid "cb67fc72-0d54-4c88-9d4b-b225f30b0f44") ;LUKS UUID
>  (target "root")
>  (type luks-device-mapping)
>  (needed-for-boot? #t))

I think the goal of providing a UUID is to not have to worry about the
actual device name (which could change).

The ‘needed-for-boot?’ flag should be unnecessary because it can be
inferred from corresponding file systems, as is already the case.

>> Besides, I think we should only worry about the mapped device(s) that
>> back / and /boot, rather than any mapped device, no?
>
> This could either be solved by determining which file systems have
> needed-for-boot? #t and determine the corresponding mapped devices,
> or by adding such a parameter for the mapped-device as in my suggestion
> above.
>
> Or we do it all automatically for / and /boot and drop the parameter
> needed-for-boot? everywhere.

We keep it only in ‘file-system’, I think.

Anyway, sounds like quite a bit of work here.  :-)

Ludo’.

bug#22970: guix edit mutt -- not working

[Alex Kost]

Jean Louis (2016-03-10 22:34 +0300) wrote:

> Hello Andreas,
>
> I have now 2 files in gnu/guix/packages/*.scm, for mutt and postgresql:
> and now I get each time on running guix, following:
>
> guix package: warning: failed to load '(databases)':
> ERROR: no code for module (databases)
> guix package: warning: failed to load '(mutt)':
> ERROR: no code for module (mutt)
>
> because 2 files are: databases.scm and mutt.scm
>
> I have already installed mutt, with changes, and it works. On the end of
> file there is word "mutt". Similar for PostgreSQL, only it did not yet
> compile.
>
> Now I get a feeling, if I have 20 files to change or adapt to my system,
> I will get 20 warnings by each run of guix package manager.
>
> Somehow it does not feel right.
>
> It would be more logical to have GUIX_PACKAGE_PATH plus one separate
> file where some modified or user related packages are listed, instead of
> having the package name on the end of *.scm file.

I agree, using GUIX_PACKAGE_PATH is such a nice way to keep your own
packages.  I don't understand why Andreas recommended to use "guix
package -f".  I think it is suitable to build some development
"guix.scm" file (not related, but see ¹).  But for user packages, I
think keeping them in GUIX_PACKAGE_PATH directories is a much better
solution.

I also don't recommend to use the same /gnu/packages/*.scm structure, as
there may be problems with this.  For example, you copied
/gnu/packages/databases.scm to your GUIX_PACKAGE_PATH dir and modified
some package in it.  Then you have to follow the changes in this file
made in Guix, and update your local databases.scm accordingly all the
time.

So if you want to keep all your packages in a single file, you can make
"/my-guix-packages.scm", add  to GUIX_PACKAGE_PATH,
and that's it!  This "my-guix-packages.scm" file will look like this:

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

(define-public my-mutt
  (package
(inherit mutt)
(name "my-mutt")
(arguments
 (substitute-keyword-arguments (package-arguments mutt)
   ((#:configure-flags cf)
`(cons "--enable-hcache" ,cf
(synopsis (string-append (package-synopsis mutt)
 " (configured with --enable-hcache)"

And all guix commands will find packages in this file, for example you
can do: "guix package -i my-mutt".  Try it!

¹ http://lists.gnu.org/archive/html/guix-devel/2016-03/msg00419.html

-- 
Alex

bug#22981: guix-edit does not find git checkout directory

[Alex Kost]

myglc2 (2016-03-11 00:56 +0300) wrote:

> Situation: GuixSD sysetm managaed by user glc using a git checkout in
> /home/glc/sre/guix.
>
> Problem: When I follow the manual to set up a vanila user (glc5) with a
> separate git checkout in /home/glc5/src/guix, guix-edit does not find
> the checkout source.
>
> Note: I followed comments from the #guix irc channel to set links in glc
> and root that point to the glc checkout:
>
> glc@g1 ~/src/guix [env]$ stat ~/.config/guix/latest
>   File: ‘/home/glc/.config/guix/latest’ -> ‘../../src/guix’
>
> glc@g1 ~/src/guix [env]$ stat /root/.config/guix/latest
>   File: ‘/root/.config/guix/latest’ -> ‘/home/glc/src/guix’
>
>
> CREATE USER glc5
[...]
> glc5@g1 ~/src$ stat ~/.config/guix/latest
> stat: cannot stat ‘/home/glc5/.config/guix/latest’: No such file or directory

I don't understand, so you made the links for user 'glc', but then you
check another user 'glc5'.  If you run emacs under glc, and try "M-x
guix-edit" there, you should be pointed to "~/.config/guix/latest".
Since you didn't make such a link for 'glc5', you are pointed to the
store.

Anyway, you can configure any directory for "M-x guix-edit" by setting
'guix-directory' variable.  See (info "(guix) Emacs Commands").  It is
not in the hmtl manual yet.

-- 
Alex

bug#22970: guix edit mutt -- not working

[Jean Louis]

Hello Alex,

Thank you much. That looks like a solution that is valuable, and I would
like to see that in future documentation.

The info documentation and guix package --help now provide the option to
read the file and evaluate from file, and I guess that this solution you
provided is better for future:

- people can learn Guile, scheme and programming
- every user can modify the package.scm according to the needs

I will copy this to guix-devel

Louis

On Fri, Mar 11, 2016 at 01:48:39PM +0300, Alex Kost wrote:
> 
> > Hello Andreas,
> >
> > I have now 2 files in gnu/guix/packages/*.scm, for mutt and postgresql:
> > and now I get each time on running guix, following:
> >
> > guix package: warning: failed to load '(databases)':
> > ERROR: no code for module (databases)
> > guix package: warning: failed to load '(mutt)':
> > ERROR: no code for module (mutt)
> >
> > because 2 files are: databases.scm and mutt.scm
> >
> > I have already installed mutt, with changes, and it works. On the end of
> > file there is word "mutt". Similar for PostgreSQL, only it did not yet
> > compile.
> >
> > Now I get a feeling, if I have 20 files to change or adapt to my system,
> > I will get 20 warnings by each run of guix package manager.
> >
> > Somehow it does not feel right.
> >
> > It would be more logical to have GUIX_PACKAGE_PATH plus one separate
> > file where some modified or user related packages are listed, instead of
> > having the package name on the end of *.scm file.
> 
> I agree, using GUIX_PACKAGE_PATH is such a nice way to keep your own
> packages.  I don't understand why Andreas recommended to use "guix
> package -f".  I think it is suitable to build some development
> "guix.scm" file (not related, but see ¹).  But for user packages, I
> think keeping them in GUIX_PACKAGE_PATH directories is a much better
> solution.
> 
> I also don't recommend to use the same /gnu/packages/*.scm structure, as
> there may be problems with this.  For example, you copied
> /gnu/packages/databases.scm to your GUIX_PACKAGE_PATH dir and modified
> some package in it.  Then you have to follow the changes in this file
> made in Guix, and update your local databases.scm accordingly all the
> time.
> 
> So if you want to keep all your packages in a single file, you can make
> "/my-guix-packages.scm", add  to GUIX_PACKAGE_PATH,
> and that's it!  This "my-guix-packages.scm" file will look like this:
> 

> (define-module (my-guix-packages)
>   #:use-module (guix packages)
>   #:use-module (guix download)
>   #:use-module (guix utils)
>   #:use-module (gnu packages mail))
> 
> (define-public my-mutt
>   (package
> (inherit mutt)
> (name "my-mutt")
> (arguments
>  (substitute-keyword-arguments (package-arguments mutt)
>((#:configure-flags cf)
> `(cons "--enable-hcache" ,cf
> (synopsis (string-append (package-synopsis mutt)
>  " (configured with --enable-hcache)"

> 
> And all guix commands will find packages in this file, for example you
> can do: "guix package -i my-mutt".  Try it!
> 
> ¹ http://lists.gnu.org/archive/html/guix-devel/2016-03/msg00419.html
> 
> -- 
> Alex

bug#22974: make check FAIL: tests/store

[Ludovic Courtès]

myglc2  skribis:

> make check TESTS=tests/store.scm
> [...]
> 
> Testsuite summary for GNU Guix 0.9.1
> 
> # TOTAL: 1
> # PASS:  1

Well closing this bug, then.

Perhaps close inspection of the content of test-tmp would have allowed
us to find out what it is that led these ‘verify-store’ tests to fail.

Ludo’.

bug#22981: guix-edit does not find git checkout directory

[myglc2]

Alex Kost  writes:

> myglc2 (2016-03-11 00:56 +0300) wrote:
>
>> Situation: GuixSD sysetm managaed by user glc using a git checkout in
>> /home/glc/sre/guix.
>>
>> Problem: When I follow the manual to set up a vanila user (glc5) with a
>> separate git checkout in /home/glc5/src/guix, guix-edit does not find
>> the checkout source.
>>
>> Note: I followed comments from the #guix irc channel to set links in glc
>> and root that point to the glc checkout:
>>
>> glc@g1 ~/src/guix [env]$ stat ~/.config/guix/latest
>>   File: ‘/home/glc/.config/guix/latest’ -> ‘../../src/guix’
>>
>> glc@g1 ~/src/guix [env]$ stat /root/.config/guix/latest
>>   File: ‘/root/.config/guix/latest’ -> ‘/home/glc/src/guix’
>>
>>
>> CREATE USER glc5
> [...]
>> glc5@g1 ~/src$ stat ~/.config/guix/latest
>> stat: cannot stat ‘/home/glc5/.config/guix/latest’: No such file or directory
>
> I don't understand, so you made the links for user 'glc', but then you
> check another user 'glc5'.  If you run emacs under glc, and try "M-x
> guix-edit" there, you should be pointed to "~/.config/guix/latest".

Yes, but it only it works for me (glc) because I studied guix for 6
weeks and learned an unpublished trick on #guix IRC channel.

> Since you didn't make such a link for 'glc5', you are pointed to the
> store.

Yes because I am trying to help you improve the user experience. So glc5
is a simulated new user following the manual literally ;)

> Anyway, you can configure any directory for "M-x guix-edit" by setting
> 'guix-directory' variable.  See (info "(guix) Emacs Commands").  It is
> not in the hmtl manual yet.

But what is the _recommended_ way to do this?

A) set 'guix-directory' variable in emacs init file?

B) make symbolic link to ~/src/guix from ~/.config/guix/latest?

C) something else?

And if a _new_ user starts reading in "8.1 Building from Git", how do
they find this information?

FWIW, I vote for method B.

bug#22985: using gnune-gtk with ratpoison (gnunet-fs in -gtk nonfunctional) -> needs participation and input

[Nils Gillmann]

This describes a bug with our gnunet-gtk package I am tracking
now in gnu/packages/gnunet.scm and will include it to refer to in
the patch I will send in as soon as I have enough time on this
conference to rebase my (big) patch of gnunet.scm

Description/Problem:

- Using ratpoison as WM, running gnunet-gtk (svn) gives GSettings
  related errors when opening gnunet-fs (filesharing) tab.
  The error gets more specific when installing gsettings into
  your profile (see irc log, 10.03.2016, grep for "gnunet"
  "gsettings"). I can't be more precise at the moment due to the
  lack of time. I provided some details on IRC on thursday, if I
  have the time this weekend I'll add the exact error messages
  you'll experience, though they are obvious in the terminal
  output.

- Reconfiguring the system with xfce in the desktop profile seems
  to provide more than ratpoison, the bug is gone. I have to
  assume that xfce provides gsettings on its own, and that this
  error is specific to minimal window managers without certain
  X11/gtk profiles or otherwise configuration settings which get
  delivered with xfce and the like.

The output (from memory) is visible when you kill/close
gnunet-gtk, look for something related to gnunet-fs ... GIO
 GSettings  and later: org.gtk.FileChooser (or something
like that), also in relation to gnunet-fs.

I want people to do the following:
- Install gnunet and gnunet-gtk (both 0.10.1), skip over
  gnunet-setup, and see in gnunet-gtk after running "gnunet-arm
  --start" if the tab for filesharing / publishing is just
  black. In either case of positive or negative confirmation I
  want to know about the used desktop/window manager and
  environment variables to nail down the problem.
- Do the exact same for gnunet-gtk-svn + gnunet-svn.


This bug is published before gnunet-svn, gnunet-gtk-svn and other
changes to gnu/packages/gnunet.scm are send in as patches. I am
currently not in reach of a permanent connection and will provide
rebase and create a patch as soon as I can. Time and too much
input in talks is another factor keeping me from currently
rebasing the patch against master.
Just know that the patch is functional and this bug is considered
something people using windowmanagers equal to ratposion should
help me in solving, as this is caused by an external factor I
have to pin and optimize the gnunet package on or provide a note
for certain environments. In itself, based on a work I
co-authored with Jookia, it is functional.


Sorry if this might read verbose or confusing but I write this
based on something I have written between yesterday, this morning
and in between rushing to the next talk :)

Thanks for your patience,
-- 
ng
personal contact: http://krosos.sdf.org
EDN: https://wiki.c3d2.de/Echt_Dezentrales_Netz/en

bug#22990: Grafts leads to inefficient substitute info retrieval

[Ludovic Courtès]

As of right now (v0.9.0-2007-g66a30a3), ‘graft-derivation’ works either by:

  1. Fetching substitute info about the things being built so that it
 can determine its references, which in turns allows it to determine
 whether they need to be grafted.

  2. Building stuff, as a last resort, so that it can determine its
 references.

Case #1 is hopefully going to be the most common.

The problem with #1 is that when building a profile, we do one
‘package-derivation’ call for each package in the profile, which
translates in one ‘graft-derivation’ call for each relevant package¹,
which translates into one ‘references/substitutes’ call for each.

Concretely, what this means is this:

  $ guix package -u
  substitute: updating list of substitutes from 'http://mirror.guixsd.org'... 
100.0%
  substitute: updating list of substitutes from 'http://mirror.guixsd.org'... 
100.0%
  substitute: updating list of substitutes from 'http://mirror.guixsd.org'... 
100.0%
  substitute: updating list of substitutes from 'http://mirror.guixsd.org'... 
100.0%
  substitute: updating list of substitutes from 'http://mirror.guixsd.org'... 
100.0%
  substitute: updating list of substitutes from 'http://mirror.guixsd.org'... 
100.0%
  substitute: updating list of substitutes from 'http://mirror.guixsd.org'... 
100.0%
  […]
  The following files would be downloaded:

Each of the initial “updating list” message corresponds to an HTTP
request for a single narinfo file, which can take around 1 second.

Instead, the ideal thing would be to fetch the narinfo files for all the
relevant packages at once; that way, we’d spawn ‘guix substitute’ only
once, and it would benefit from HTTP pipelining (one round-trip instead
of N.)

To achieve this, I’m thinking of extending gexp code such that gexp
compilers can return a list of applicable grafts.  The ‘package’
compiler would do #:graft? #f and instead let ‘gexp->derivation’ call
‘graft-derivation’.

I’ll give it a try and report back.

Ludo’.

¹ A package is “relevant” if ‘package-grafts’ returns a non-empty list.