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

[myglc2]

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


glc@g1 ~/src/guix$ guix environment guix
glc@g1 ~/src/guix [env]$ ./bootstrap
glc@g1 ~/src/guix [env]$ ./configure --localstatedir=/var && make

glc@g1 ~/src/guix [env]$ git branch -v
* master ff22f01 gnu: dropbear: Update to 2016.72 [fixes CVE-2016-3116].

glc@g1 ~/src/guix [env]$ which guix
/run/current-system/profile/bin/guix

glc@g1 ~/src/guix [env]$ stat /run/current-system/profile/bin/guix
  File: ‘/run/current-system/profile/bin/guix’ ->
  ‘/gnu/store/3lg5c1nidbj0kjdz5b63hn3vp29kzf0s-guix-0.9.0.c3f29bc/bin/guix’

glc@g1 ~/src/guix [env]$ sudo guix system reconfigure ../configs/c05system.scm

USER glc5 test
==

glc5@g1 ~/src$ which guix
/run/current-system/profile/bin/guix

glc5@g1 ~/src$ stat /run/current-system/profile/bin/guix File:
  ‘/run/current-system/profile/bin/guix’ ->
  ‘/gnu/store/3lg5c1nidbj0kjdz5b63hn3vp29kzf0s-guix-0.9.0.c3f29bc/bin/guix’

glc5@g1 ~/src$ stat ~/.config/guix/latest
stat: cannot stat ‘/home/glc5/.config/guix/latest’: No such file or directory

## set up glc5's environment
glc5@g1 ~/src$ guix package -m glc5.scm 

## customize emacs following "8.3 The Perfect Setup"

glc5@g1 ~/src$ cat ~/.emacs.d/init.el | head -n4
;; from "8.3 The Perfect Setup"
;; Assuming the Guix checkout is in ~/src/guix.
(with-eval-after-load 'geiser-guile
  (add-to-list 'geiser-guile-load-path "~/src/guix"))

## clone guix
glc5@g1 ~/src$ git clone t://git.savannah.gnu.org/guix.git

### run emacs
emacs

M-x guix-edit screen

Problem: This finds read-only screen.src in store rather than in ~/src/guix/...



c05system.scm
Description: Binary data


glc5.scm
Description: Binary data

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

[Leo Famulari]

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.

I ran `guix pull` and confirmed the changes were in ~/.config/guix/latest.

I cleared the cache at /vat/guix/substitute/cache.

Then, I updated --substitute-urls in the daemon invocation and reloaded the
daemon, and then did `guix build hello`.

Did I miss a step?

> 
> I can no longer reproduce the ECONNRESET issue I mentioned for
> , but feel free to open a new bug if
> that comes up again!
> 
> For the record, the main test I used for that was:
> 
>   $ sudo rm -rf /var/guix/substitute/cache
>   $ guix build libreoffice --no-grafts -n \
> --substitute-urls=https://hydra.gnunet.org
> 
> That forces a redownload of all .narinfo files from hydra.gnunet.org,
> which involves HTTP pipelining.
> 
> Anyway, thanks for giving me an incentive to address this.  This was
> long overdue!
> 
> Ludo’.
> 
> 
> 

bug#22974: make check FAIL: tests/store

[myglc2]

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

> myglc2  skribis:
>
>> tests/store.scm:740: FAIL verify-store
>> tests/store.scm:757: FAIL verify-store + check-contents
>
> Does this pass after ‘make recheck’?
>
> If not, could you try:
>
>   rm -rf test-tmp
>   make check TESTS=tests/store.scm
[...]

git branch -v
* (HEAD detached at ce6027b) ce6027b gnu: nautilus: Don't propagate gtk+.
  master 9720651 gnu: libass: Update to 0.13.2.
make recheck
[...]

Testsuite summary for GNU Guix 0.9.1

# TOTAL: 1
# PASS:  0
# SKIP:  0
# XFAIL: 0
# FAIL:  1
# XPASS: 0
# ERROR: 0
[...]

sudo rm -rf test-tmp

make check TESTS=tests/store.scm
[...]

Testsuite summary for GNU Guix 0.9.1

# TOTAL: 1
# PASS:  1
# SKIP:  0
# XFAIL: 0
# FAIL:  0
# XPASS: 0
# ERROR: 0


hth - George

bug#22970: guix edit mutt -- not working

[Jean Louis]

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.

On Thu, Mar 10, 2016 at 12:44:33AM +0100, Andreas Enge wrote:
> On Thu, Mar 10, 2016 at 12:22:20AM +0100, Jean Louis wrote:
> > And I could not save the file in my home directory, and do:
> > guix package -i mutt -f mail.scm
> 
> As mentioned on IRC, modify the file mail.scm by adding a line
>mutt
> at the end. Then
>guix package -f mail.scm
> does "install the package that the code within FILE evaluates to" as
> explained by "guix package --help". mail.scm itself does not evaluate
> to anything, it just contains a number of variable definitions. By adding
> the line, it "returns" the value of the variable mutt, which is your
> package definition.
> 
> Better yet, use GUIX_PACKAGE_PATH, for instance as follows:
>export GUIX_PACKAGE_PATH=$HOME/guix
> Then create the same file layout in that directory as in the source code:
>mkdir -p $HOME/guix/gnu/packages
> Copy mail.scm there, modify mutt, then
>guix package -i mutt
> will first look for your modified package.
> 
> As this is not a bug, it would have been better to post to help-g...@gnu.org;
> let us continue the discussion there (if you are not yet subscribed, please
> do so), and I am closing this bug.
> 
> Andreas
> 
> 

bug#22974: make check FAIL: tests/store

[Ludovic Courtès]

myglc2  skribis:

> tests/store.scm:740: FAIL verify-store
> tests/store.scm:757: FAIL verify-store + check-contents

Does this pass after ‘make recheck’?

If not, could you try:

  rm -rf test-tmp
  make check TESTS=tests/store.scm

?

TIA,
Ludo’.

bug#22948: Porting ocl-icd to guix fails because of ruby

[Ludovic Courtès]

Dennis Mungai  skribis:

> After running the garbage collector, the problem went away (And saved me
> about 20GBs under /gnu/store).
>
> I'm suspecting this was a corrupt store.

OK, we’ll never know.  Make sure to never ever modify files under
/gnu/store and you should be fine.

Thanks,
Ludo’.

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

[Ludovic Courtès]

After some more testing and tweaks, notably with
 and its brand new Let’s Encrypt certificate,
I pushed the patch as 9b7bd1b160be7c740a798c09e3b8986368b92036.

I can no longer reproduce the ECONNRESET issue I mentioned for
, but feel free to open a new bug if
that comes up again!

For the record, the main test I used for that was:

  $ sudo rm -rf /var/guix/substitute/cache
  $ guix build libreoffice --no-grafts -n \
--substitute-urls=https://hydra.gnunet.org

That forces a redownload of all .narinfo files from hydra.gnunet.org,
which involves HTTP pipelining.

Anyway, thanks for giving me an incentive to address this.  This was
long overdue!

Ludo’.

bug#22948: Porting ocl-icd to guix fails because of ruby

[Dennis Mungai]

Hello,

And a small update:

After running the garbage collector, the problem went away (And saved me
about 20GBs under /gnu/store).

I'm suspecting this was a corrupt store.

On 9 March 2016 at 16:33, Ludovic Courtès  wrote:

> Dennis Mungai  skribis:
>
> > env TEMPDIR=/gnu/tmp GUIX_PACKAGE_PATH=../guix-bioinformatics
> > ./pre-inst-env guix build -K ocl-icd
>
> Note that setting TEMPDIR here (or even TMPDIR) has no effect, since
> it’s the ‘guix-daemon’ process, not ‘guix build’, that creates temporary
> files.
>
> > Error encountered:
> >
> > guix build: error: build failed: error parsing derivation
> > `/gnu/store/7f9hwk8v9vzghc93m93y94iibvcc3mvd-ruby-2.3.0.tar.xz.drv':
> > expected string `Derive(['
>
> Could you send the content of the file above?
>
> It looks like your store may be be corrupt.  Did you modify files by
> hand under /gnu/store?  This would void your warranty.  :-)
>
> Thanks,
> Ludo’.
>

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

[Andreas Enge]

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.

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.

>(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))

> 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.

Andreas

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

[Ludovic Courtès]

Andreas Enge  skribis:

> What is needed are the following two lines at the beginning of grub.cfg:
>
> insmod luks
> cryptomount -u 1aa...
>
> where 1aa... is the result of "cryptsetup luksUUID /dev/sda2".
>
> So the logic outlined in my previous message works:
> Determine the mapped-devices /dev/sdXY of type luks-device-mapping that
> lead to a file-system with needed-for-boot? set to #t.
> Using
>cryptsetup luksUUID /dev/sdXY
> determine a corresponding uuid 12345...0.
> If any such mapped-device exists, add
>insmod luks
> as the first line of grub.cfg. For any such mapped-device, add a line
>cryptomount -u 12345...0
> right after that.

IIUC we don’t *have* to pass the UUID to ‘cryptomount’; we could also
pass the device name, in GRUB format, which would allow us to use the
same strategy as in ‘grub-root-search’ in (gnu system grub)… with the
difficulty that we’d have to be able to map Linux /dev node names to
GRUB device names.

Furthermore, to allow users to specify a LUKS UUID as the ‘source’ of
their ‘mapped-device’ form, as in:

   (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.)

Thoughts?  Looks like more work than I initially thought.

Besides, I think we should only worry about the mapped device(s) that
back / and /boot, rather than any mapped device, no?

Thanks for looking into it,
Ludo’.

bug#22962: Something keeps overwriting /etc/hosts

[Alex Kost]

Leo Famulari (2016-03-10 04:43 +0300) wrote:

> On Thu, Mar 10, 2016 at 12:28:11AM +0100, Danny Milosavljevic wrote:
>> If I make it immutable, I get the following message on guix system 
>> reconfigure ... :
>>
>>   guix system: error: copy-file: Permission denied: "/etc/hosts"
>>
>> Aha!
>
> I think that on GuixSD, the hosts file is generated from the system
> configuration, specifically the 'hosts-file' field, which is mentioned
> in section 7.2.2 Operating System Reference [0].
>
> I assume that the resulting file is recreated each time you reconfigure.
>
> In that case, you'd want to leave the file /etc/hosts alone, and make
> your changes in the operating system configuration.
>
> I say "I think" and "I assume" because I haven't actually used
> 'hosts-file' yet, nor have I looked at that part of the code.

You are absolutely right!  On GuixSD, to modify /etc/hosts a user need
to adjust his/her system config.

Danny, you can keep your hosts file wherever you want, let's say
"~/my-config/hosts"; and you can add this line to your operating-system
declaration:

  (hosts-file (local-file (string-append (getenv "HOME")
 "/my-config/hosts")))

After reconfiguring your system, this file will be put into the store,
and /etc/hosts will have the same contents after reboot.

Moreover, every time you change this file and make a new system, a new
version of "hosts" will be put to the store.  So if you boot into some
old system, it will be booted with the hosts file that was used at that
time (as you can see, every system in /var/guix/profiles, has its own
"etc/hosts").

-- 
Alex