Re: [PATCH] DISCUSSION: Jookia's Libreboot+LUKS+LVM FDE patch.

[Taylan Ulrich Bayırlı/Kammer]

FYI this landed in my Gmail spam folder.  Maybe because of the
all-caps. :-)

Taylan

Re: [PATCH] doc: Explain --localstatedir some more.

[Ricardo Wurmus]

Andreas Enge  writes:

> On Thu, Mar 10, 2016 at 08:24:44AM +1100, Jookia wrote:
>> As much as that's appealing, this breaks GNU conventions. I think it'd be 
>> nice
>> to put the state in the store directory by default since it seems the two are
>> related, though this might not be the case in other situations.
>
> This would also be an interesting option; actually, I think things were like
> that a long time ago... It would make sense to keep everything related to
> the management of the store in /gnu, so that the complete store could
> be copied easily.
>
> Maybe we should make the new convention that localstatedit should default to
> /gnu; this cannot be against GNU standards, at least not in spirit :-)

I’d like to keep all things in /gnu, but note that we also have
/etc/guix/acl and possibly other files that are distributed across the
filesystem.

~~ Ricardo

[PATCH] DISCUSSION: Jookia's Libreboot+LUKS+LVM FDE patch.

[Jookia]

DISCLMAIMER: This commit isn't meant for merging, so donut merge it.
It's meant for people to use until we get something better. There's
also code I haven't fully checked is needed (particularly mknodes)
so there's duplicates. Use this at the risk of having to ask me
to fix it and possibly have me say no.

So I've come up with the following hack commit that effectively
stops any sort of dependency management and adds some new targets
for LVM and LUKS with a keyfile.

Here's my current setup, take note that order of mapped devices
matter since there's no dependency management:

  (mapped-devices (list (mapped-device
  (source "/dev/sda")
  (target "hdd")
  (type (luks-device-keyfile-mapping
  (local-file "/root/keyfile"
(mapped-device
  (source "/dev/mapper/hdd")
  (target "matrix")
  (type lvm-device-mapping

  (file-systems (cons (file-system
(device "/dev/mapper/matrix-root")
(title 'device)
(mount-point "/")
(type "ext4"))
  %base-file-systems))

  (swap-devices '("/dev/mapper/matrix-swap"))

This shouldn't break existing installs, but don't rely on this
behaviour or API unless you're willing to maintain it.

You'll note that I'm using a keyfile. It gets copied to initramfs,
but you generate it like so:

  dd bs=512 count=4 if=/dev/urandom of=/root/keyfile iflag=fullblock

Then you add it to your cryptsetup device like:

  cryptsetup luksAddKey /dev/sda /root/keyfile

I'm assuming you're using /dev/sda. But you might not be? Anyways
that means you only have the enter the password to decrypt root
once (at GRUB) instead of twice.

BE WARNED THAT YOUR DRIVE CAN BE DECRYPTED BY USING THE COPY OF YOUR
KEYFILE IN /GNU/STORE OR YOUR INITRAMFS IN /GNU/STORE.

  root@t400-apparent-situation ~# ls /gnu/store | grep keyfile
  rfwrwxpcvqqw8az8c6k37bqzqvgzrh34-keyfile

IF YOU ARE LOOKING FOR SECURITY IT IS NOT HERE. ANY APPLICATION YOU
RUN CAN READ /GNU/STORE. YOU HAVE BEEN WARNED.

Also you can do something like this to autologin, making it only one
password to get in to your system (GRUB):

(services (modify-services %desktop-services
  (slim-service-type config =>
 (slim-configuration
   (inherit config)
   (auto-login? #t)
   (default-user "jookia")
   (auto-login-session
#~(string-append #$xfce "/bin/startxfce4"))

Cheers,
Jookia.
---
 gnu/services/base.scm   |  8 +
 gnu/system.scm  | 73 -
 gnu/system/linux-initrd.scm | 15 +-
 3 files changed, 74 insertions(+), 22 deletions(-)

diff --git a/gnu/services/base.scm b/gnu/services/base.scm
index 9b3dc73..cb248fc 100644
--- a/gnu/services/base.scm
+++ b/gnu/services/base.scm
@@ -1200,15 +1200,9 @@ gexp, to open it, and evaluate @var{close} to close it."
   (shepherd-service-type
'swap
(lambda (device)
- (define requirement
-   (if (string-prefix? "/dev/mapper/" device)
-   (list (symbol-append 'device-mapping-
-(string->symbol (basename device
-   '()))
-
  (shepherd-service
   (provision (list (symbol-append 'swap- (string->symbol device
-  (requirement `(udev ,@requirement))
+  (requirement `(udev root-file-system))
   (documentation "Enable the given swap device.")
   (start #~(lambda ()
  (restart-on-EINTR (swapon #$device))
diff --git a/gnu/system.scm b/gnu/system.scm
index 5be24ba..922e1f0 100644
--- a/gnu/system.scm
+++ b/gnu/system.scm
@@ -44,6 +44,7 @@
   #:use-module (gnu packages compression)
   #:use-module (gnu packages firmware)
   #:autoload   (gnu packages cryptsetup) (cryptsetup)
+  #:autoload   (gnu packages linux) (lvm2)
   #:use-module (gnu services)
   #:use-module (gnu services shepherd)
   #:use-module (gnu services base)
@@ -103,7 +104,9 @@
 %base-packages
 %base-firmware
 
-luks-device-mapping))
+luks-device-mapping
+luks-device-keyfile-mapping
+lvm-device-mapping))
 
 ;;; Commentary:
 ;;;
@@ -194,6 +197,46 @@
(open open-luks-device)
(close close-luks-device)))
 
+;;; HACK HACK HACCKK
+
+(define (open-luks-device-keyfile key-file)
+  "Return a gexp that maps SOURCE to TARGET as a LUKS device, using
+'cryptsetup'."
+  (lambda (source target)
+#~(zero? (system* (string-append #$cryptsetup "/sbin/cryptsetup")
+"open" "--type" "luks"
+(string-append "--key-file=" #$key-file)
+#$source #$target
+
+(define (luks-device-keyfile-mapping key-file)
+  ;; The type of 

[PATCH] DISCUSSION: Jookia's Libreboot+LUKS+LVM FDE patch.

[Jookia]

DISCLMAIMER: This commit isn't meant for merging, so donut merge it.
It's meant for people to use until we get something better. There's
also code I haven't fully checked is needed (particularly mknodes)
so there's duplicates. Use this at the risk of having to ask me
to fix it and possibly have me say no.

So I've come up with the following hack commit that effectively
stops any sort of dependency management and adds some new targets
for LVM and LUKS with a keyfile.

Here's my current setup, take note that order of mapped devices
matter since there's no dependency management:

  (mapped-devices (list (mapped-device
  (source "/dev/sda")
  (target "hdd")
  (type (luks-device-keyfile-mapping
  (local-file "/root/keyfile"
(mapped-device
  (source "/dev/mapper/hdd")
  (target "matrix")
  (type lvm-device-mapping

  (file-systems (cons (file-system
(device "/dev/mapper/matrix-root")
(title 'device)
(mount-point "/")
(type "ext4"))
  %base-file-systems))

  (swap-devices '("/dev/mapper/matrix-swap"))

This shouldn't break existing installs, but don't rely on this
behaviour or API unless you're willing to maintain it.

You'll note that I'm using a keyfile. It gets copied to initramfs,
but you generate it like so:

  dd bs=512 count=4 if=/dev/urandom of=/root/keyfile iflag=fullblock

Then you add it to your cryptsetup device like:

  cryptsetup luksAddKey /dev/sda /root/keyfile

I'm assuming you're using /dev/sda. But you might not be? Anyways
that means you only have the enter the password to decrypt root
once (at GRUB) instead of twice.

BE WARNED THAT YOUR DRIVE CAN BE DECRYPTED BY USING THE COPY OF YOUR
KEYFILE IN /GNU/STORE OR YOUR INITRAMFS IN /GNU/STORE.

  root@t400-apparent-situation ~# ls /gnu/store | grep keyfile
  rfwrwxpcvqqw8az8c6k37bqzqvgzrh34-keyfile

IF YOU ARE LOOKING FOR SECURITY IT IS NOT HERE. ANY APPLICATION YOU
RUN CAN READ /GNU/STORE. YOU HAVE BEEN WARNED.

Also you can do something like this to autologin, making it only one
password to get in to your system (GRUB):

(services (modify-services %desktop-services
  (slim-service-type config =>
 (slim-configuration
   (inherit config)
   (auto-login? #t)
   (default-user "jookia")
   (auto-login-session
#~(string-append #$xfce "/bin/startxfce4"))

Cheers,
Jookia.
---
 gnu/services/base.scm   |  8 +
 gnu/system.scm  | 73 -
 gnu/system/linux-initrd.scm | 15 +-
 3 files changed, 74 insertions(+), 22 deletions(-)

diff --git a/gnu/services/base.scm b/gnu/services/base.scm
index 9b3dc73..cb248fc 100644
--- a/gnu/services/base.scm
+++ b/gnu/services/base.scm
@@ -1200,15 +1200,9 @@ gexp, to open it, and evaluate @var{close} to close it."
   (shepherd-service-type
'swap
(lambda (device)
- (define requirement
-   (if (string-prefix? "/dev/mapper/" device)
-   (list (symbol-append 'device-mapping-
-(string->symbol (basename device
-   '()))
-
  (shepherd-service
   (provision (list (symbol-append 'swap- (string->symbol device
-  (requirement `(udev ,@requirement))
+  (requirement `(udev root-file-system))
   (documentation "Enable the given swap device.")
   (start #~(lambda ()
  (restart-on-EINTR (swapon #$device))
diff --git a/gnu/system.scm b/gnu/system.scm
index 5be24ba..922e1f0 100644
--- a/gnu/system.scm
+++ b/gnu/system.scm
@@ -44,6 +44,7 @@
   #:use-module (gnu packages compression)
   #:use-module (gnu packages firmware)
   #:autoload   (gnu packages cryptsetup) (cryptsetup)
+  #:autoload   (gnu packages linux) (lvm2)
   #:use-module (gnu services)
   #:use-module (gnu services shepherd)
   #:use-module (gnu services base)
@@ -103,7 +104,9 @@
 %base-packages
 %base-firmware
 
-luks-device-mapping))
+luks-device-mapping
+luks-device-keyfile-mapping
+lvm-device-mapping))
 
 ;;; Commentary:
 ;;;
@@ -194,6 +197,46 @@
(open open-luks-device)
(close close-luks-device)))
 
+;;; HACK HACK HACCKK
+
+(define (open-luks-device-keyfile key-file)
+  "Return a gexp that maps SOURCE to TARGET as a LUKS device, using
+'cryptsetup'."
+  (lambda (source target)
+#~(zero? (system* (string-append #$cryptsetup "/sbin/cryptsetup")
+"open" "--type" "luks"
+(string-append "--key-file=" #$key-file)
+#$source #$target
+
+(define (luks-device-keyfile-mapping key-file)
+  ;; The type of 

Re: [PATCH] gnu: Add powwow.

[宋文武]

Nils Gillmann  writes:

> I removed gplv3+ as addressed by ludo' and rekado,
> corrected the url in "website" (added missing ".net").
>
> Here's the new patch, rebased against current master.
Thanks!
>
> From f59e5027d4fb9559e179fb4693617820f6680223 Mon Sep 17 00:00:00 2001
> From: Nils Gillmann 
> Date: Thu, 3 Mar 2016 12:41:08 +0100
> Subject: [PATCH] gnu: Add powwow.
>
> * gnu/packages/admin.scm (powwow): New variable.
> ---
>  gnu/packages/admin.scm | 25 +
>  1 file changed, 25 insertions(+)
>
> diff --git a/gnu/packages/admin.scm b/gnu/packages/admin.scm
> index b0b2046..1a26fa0 100644
> --- a/gnu/packages/admin.scm
> +++ b/gnu/packages/admin.scm
I think it isn’t for admin…  how about put it in games.scm?
> @@ -9,6 +9,7 @@
>  ;;; Copyright © 2016 Leo Famulari 
>  ;;; Copyright © 2016 Pjotr Prins 
>  ;;; Copyright © 2016 Ricardo Wurmus 
> +;;; Copyright © 2016 Nils Gillmann 
>  ;;;
>  ;;; This file is part of GNU Guix.
>  ;;;
> @@ -1496,3 +1497,27 @@ for writing audit records to the disk.  Viewing the 
> logs is done with the
>  @code{ausearch} or @code{aureport} utilities.  Configuring the audit rules is
>  done with the @code{auditctl} utility.")
>  (license license:gpl2+)))
> +
> +(define-public powwow
> +  (package
> +(name "powwow")
> +(version "1.2.17")
> +(source (origin
> +  (method url-fetch)
> +  (uri (string-append 
> "http://www.hoopajoo.net/static/projects/powwow-;
Make it under 80 characters limit?
> +  version ".tar.gz"))
> +  (file-name (string-append name "-" version ".tar.gz"))
> +  (sha256
> +   (base32
> +"1xmsg2y7qcvj67i9ilnih0mvfxcpni7fzrz343x9rdfnkkzf3pp8"
> +(inputs
> + `(("ncurses" ,ncurses)))
> +(build-system gnu-build-system)
> +(home-page "http://www.hoopajoo.net/projects/powwow.html;)
> +(synopsis "POWWOW is a enhanced telnet client which can be used for MUD")
Don’t mention itself in synopsis, I think “MUD and telnet client” should do.
> +(description
> + "POWWOW is a client software which can be used for telnet as well as for
> +@dfn{Multi-User Dungeon} (MUD).  Additionally it can serve as a nice client 
> for
> +the chat server psyced with the specific config located at
> +http://lavachat.symlynx.com/unix/;)
> +(license license:gpl2+)))
> -- 
> 2.6.3
Otherwise, look good to me!

Re: should gnome-desktop-service really provide all of this to a profile?

[Ludovic Courtès]

iyzs...@member.fsf.org (宋文武) skribis:

> l...@gnu.org (Ludovic Courtès) writes:
>
>> Pulseaudio also propagates a few things.
> Yes, I think it should be splited into “out” and “dev”, if we can make
> only the “dev” output propagating libcap and gdbm.

Yeah.

>> Two things here:
>>
>>   • Back in the day, I couldn’t think of a situation where it would make
>> sense for ‘propagated-inputs’ to be different from
>> ‘propagated-user-env-packages’ (at the time, the latter was little
>> known so in practice people had to install dependencies by
>> themselves.)  So in Guix I chose to have just one.
> In nix ‘propagated-build-inputs’ is propagations and ‘inputs’ for building
> while ‘propagated-user-env-packages’ is propagations for profile.
> In guix ‘propagated-inputs’ is propagations for both building and profile
> and at the same time is ‘inputs’ for building.

Yes.

> I agree that propagations for building or for profile is the same thing,
> and there’re some runtime only dependencies worthing treating as
> non-inputs (eg: adwaita-icon-themes, plugins for gstreamer).

Yes, though I would not worry about these “non-inputs” for now.

> How about seperating propagations from ‘propagated-inputs’?
> This requires listing some packages twice, but I think it will be more
> clear considering ‘inputs’ are for building the whole package while
> ‘propagations’ are (should be) per-output.
>
> eg:
> (package
>   (name "pulseaudio")
>   (outputs '("out" "include" "lib" "dev"))
>   (inputs
>`(("libpcap" ,libcap)
>  ("gdbm" ,gdmb)
>  ...))
>   (propagations
> #:output "dev"
> `(("pulseaudio:include" ,pulseaudio "include")
>   ("pulseaudio:lib" ,pulseaudio "lib")
>   ("libpcap" ,libpcap)
>   ("gdbm" ,gdbm)))
>   ...)

Sure.  There’s a years-old example in ‘TODO’, even.  :-)

The syntax cannot be exactly like what you suggest, but it could be
along the lines of what’s in ‘TODO’:

  (propagated-inputs
`"i1" ,p1 "o1")
("i2" ,p2))
   => "include")
  ("i3" ,p3)))

>>   • I found the ‘nix-support’ trick (that is, having high-level
>> information on the build side) kind of hacky, which is why this
>> information is solely on the build side in Guix.  This is what
>> allows higher-level functionality such as --search-paths to be
>> implemented on the host side.
>>
>> OTOH, things like  could be more easily
>> addressed if all the info was already on the build side.
> Agree :-)

With which part?  :-)

>> Anyway, what do you think would be the best way to avoid “profile
>> pollution” with the GNOME meta-package?
> I think, for now:
>
> From 7206310f7320ed99eabd7f774a083c7b1f78c81f Mon Sep 17 00:00:00 2001
> From: =?UTF-8?q?=E5=AE=8B=E6=96=87=E6=AD=A6?= 
> Date: Wed, 9 Mar 2016 13:17:48 +0800
> Subject: [PATCH] gnu: nautilus: Don't propagate gtk+.
>
> This reduces "profile pollution" of the 'gnome' meta package.
> See .
>
> * gnu/packages/gnome.scm (nautilus): Move gtk+ from propagated-inputs to 
> inputs.

Please move the sentence “This reduces …” to a comment in the code.
Otherwise LGTM!

Thanks,
Ludo’.

Re: [PATCH] system: grub: Add 'libreboot?' install flag.

[Jookia]

On Wed, Mar 09, 2016 at 10:37:43PM +0100, Danny Milosavljevic wrote:
> Hi,

Hi there, this is an old patch set so if you intend on using it you should use
my newer RFC posted earlier this month. :)

> just adding a few bits of information:
> 
> It's true that libreboot can (and does) source other grub config files. GRUB 
> should also be able to chainload other bootloaders, however I tried that 
> several times now and it just doesn't work. Is this a known limitation?
> 
> insmod ahci
> insmod ext2
> insmod part_msdos
> insmod chain
> 
> set default=0
> set timeout=1
> 
> submenu "Load Config" 0 {
>   root=(ahci0,msdos1)
>   source /boot/grub/grub.cfg <--- works
>   unset superusers
> }
> 
> menuentry "Chainload GuixSD" {
>   chainloader (ahci0)+1  <-- doesn't work, "unknown payload"
> }

I'm unsure if it can chainload from another drive's MBR like this.

> But I can confirm that having /boot/grub/libreboot_grub.cfg makes libreboot 
> use that by default (after a 1 second or so delay where you can choose 
> something else for it to do).
> 
> Personally, I just use
> 
>   $ ln -s grub.cfg /boot/grub/libreboot_grub.cfg
> 
> without any other patches instead. Works fine. Also auto-updates.

Unfortunately this doesn't work for encrypted disks.

Jookia.

Re: [PATCH] doc: Explain --localstatedir some more.

[Andreas Enge]

On Thu, Mar 10, 2016 at 08:24:44AM +1100, Jookia wrote:
> As much as that's appealing, this breaks GNU conventions. I think it'd be nice
> to put the state in the store directory by default since it seems the two are
> related, though this might not be the case in other situations.

This would also be an interesting option; actually, I think things were like
that a long time ago... It would make sense to keep everything related to
the management of the store in /gnu, so that the complete store could
be copied easily.

Maybe we should make the new convention that localstatedit should default to
/gnu; this cannot be against GNU standards, at least not in spirit :-)

Andreas

Re: [PATCH] system: grub: Add 'libreboot?' install flag.

[Danny Milosavljevic]

Hi,

just adding a few bits of information:

It's true that libreboot can (and does) source other grub config files. GRUB 
should also be able to chainload other bootloaders, however I tried that 
several times now and it just doesn't work. Is this a known limitation?

insmod ahci
insmod ext2
insmod part_msdos
insmod chain

set default=0
set timeout=1

submenu "Load Config" 0 {
root=(ahci0,msdos1)
source /boot/grub/grub.cfg <--- works
unset superusers
}

menuentry "Chainload GuixSD" {
chainloader (ahci0)+1  <-- doesn't work, "unknown payload"
}

But I can confirm that having /boot/grub/libreboot_grub.cfg makes libreboot use 
that by default (after a 1 second or so delay where you can choose something 
else for it to do).

Personally, I just use

  $ ln -s grub.cfg /boot/grub/libreboot_grub.cfg

without any other patches instead. Works fine. Also auto-updates.

The default libreboot grub config (in flash) is:

set prefix=(memdisk)/boot/grub

insmod nativedisk
insmod ehci
insmod ohci
insmod uhci
insmod usb
insmod usbserial_pl2303
insmod usbserial_ftdi
insmod usbserial_usbdebug

# Serial and keyboard configuration, very important.
serial --speed=115200 --unit=0 --word=8 --parity=no --stop=1
terminal_input --append  serial
terminal_output --append serial
terminal_input --append at_keyboard

gfxpayload=keep
terminal_output --append gfxterm

# Default to first option, automatically boot after 1 second
set default="0"
set timeout=1

# This is useful when using 'cat' on long files on GRUB terminal
set pager=1

# # Play a beep on startup
# play 480 440 1
insmod jpeg

background_image (cbfsdisk)/background.jpg
loadfont (memdisk)/dejavusansmono.pf2

keymap ukqwerty
menuentry 'Load Operating System' {
insmod ahci
insmod part_msdos
insmod part_gpt
for x in (ahci0,1) (ahci0,2) (ahci0,3) (ahci0,4); do
if [ -f "$x/grub/libreboot_grub.cfg" ] ; then
set root=$x
configfile /grub/libreboot_grub.cfg
fi
if [ -f "$x/boot/grub/libreboot_grub.cfg" ] ; then
set root=$x
configfile /boot/grub/libreboot_grub.cfg
fi
done

set root='ahci0,1'
linux  /vmlinuz root=/dev/sda1 rw
if [ -f "/initrd.img" ] ; then
initrd /initrd.img
fi
}
menuentry 'Parse ISOLINUX menu (ahci0)' {
insmod ahci
insmod part_msdos
insmod part_gpt
for x in (ahci0,1) (ahci0,2) (ahci0,3) (ahci0,4); do
set root=$x
if [ -f "/isolinux/isolinux.cfg" ] ; then
syslinux_configfile -i /isolinux/isolinux.cfg
elif [ -f "/syslinux/syslinux.cfg" ] ; then
syslinux_configfile -i /syslinux/syslinux.cfg
elif [ -f "/boot/isolinux/isolinux.cfg" ] ; then
syslinux_configfile -i /boot/isolinux/isolinux.cfg
elif [ -f "/boot/syslinux/syslinux.cfg" ] ; then
syslinux_configfile -i /boot/syslinux/syslinux.cfg
fi
done
}
menuentry 'Parse ISOLINUX menu (USB)' {
insmod usbms
insmod part_msdos
insmod part_gpt
for x in (usb0) (usb0,1) (usb0,2) (usb0,3) (usb0,4); do
set root=$x
if [ -f "/isolinux/isolinux.cfg" ] ; then
syslinux_configfile -i /isolinux/isolinux.cfg
elif [ -f "/syslinux/syslinux.cfg" ] ; then
syslinux_configfile -i /syslinux/syslinux.cfg
elif [ -f "/boot/isolinux/isolinux.cfg" ] ; then
syslinux_configfile -i /boot/isolinux/isolinux.cfg
elif [ -f "/boot/syslinux/syslinux.cfg" ] ; then
syslinux_configfile -i /boot/syslinux/syslinux.cfg
fi
done
}
menuentry 'Parse ISOLINUX menu (CD/DVD)' {
insmod ahci
insmod ata
insmod iso9660
for x in (ata0) (ahci1); do
set root=$x
if [ -f "/isolinux/isolinux.cfg" ] ; then
syslinux_configfile -i /isolinux/isolinux.cfg
elif [ -f "/syslinux/syslinux.cfg" ] ; then
syslinux_configfile -i /syslinux/syslinux.cfg
elif [ -f "/boot/isolinux/isolinux.cfg" ] ; then
syslinux_configfile -i /boot/isolinux/isolinux.cfg
elif [ -f "/boot/syslinux/syslinux.cfg" ] ; then
syslinux_configfile -i /boot/syslinux/syslinux.cfg
fi
done
}
menuentry 'Switch to grubtest.cfg' {
set root='cbfsdisk'
configfile (cbfsdisk)/grubtest.cfg
}
menuentry 'Search for GRUB configuration (grub.cfg) outside of CBFS' {
insmod ahci
insmod usbms
insmod part_msdos
insmod part_gpt
for x in 

Re: [PATCH] doc: Explain --localstatedir some more.

[Jookia]

On Wed, Mar 09, 2016 at 10:07:03PM +0100, Andreas Enge wrote:
> I still think we should make /var the default of localstatedir; this would
> avoid most problems.
> 
> Andreas, doing his Cicero

As much as that's appealing, this breaks GNU conventions. I think it'd be nice
to put the state in the store directory by default since it seems the two are
related, though this might not be the case in other situations.

Jookia.

[PATCH] Suggest `guix.scm' for upstream maintainers.

[Jan Nieuwenhuizen]

Hi,

In reference to ponderings on #guix, find minor doc patch attached.

Greetings,
Jan

>From fc6dd2108dae76e09e1bfcd6d04c36943469434f Mon Sep 17 00:00:00 2001
From: Jan Nieuwenhuizen 
Date: Wed, 9 Mar 2016 22:18:48 +0100
Subject: [PATCH] Suggest `guix.scm' for upstream maintainers.

* doc/guix.texi (Invoking guix package): Suggest `guix.scm'.
---
 doc/guix.texi | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/doc/guix.texi b/doc/guix.texi
index 06b40fa..f23c7fc 100644
--- a/doc/guix.texi
+++ b/doc/guix.texi
@@ -1350,7 +1350,7 @@ As an example, @var{file} might contain a definition like this
 @verbatiminclude package-hello.scm
 @end example
 
-Developers may find it useful to include such a @file{package.scm} file
+Developers may find it useful to include such a @file{guix.scm} file
 in the root of their project source tree that can be used to test
 development snapshots and create reproducible development environments
 (@pxref{Invoking guix environment}).
-- 
2.6.3


-- 
Jan Nieuwenhuizen  | GNU LilyPond http://lilypond.org
Freelance IT http://JoyofSource.com | Avatar®  http://AvatarAcademy.nl  

Re: [PATCH] doc: Explain --localstatedir some more.

[Andreas Enge]

On Thu, Mar 10, 2016 at 07:35:53AM +1100, Jookia wrote:
> This should hopefully stop people from running in to issues when
> building Guix from source as they have in the past.

I still think we should make /var the default of localstatedir; this would
avoid most problems.

Andreas, doing his Cicero

Re: [PATCH] gnu: simple-scan: Update to 3.19.91.

[Leo Famulari]

On Wed, Mar 09, 2016 at 02:28:03PM +0100, Ludovic Courtès wrote:
> Leo Famulari  skribis:
> 
> > On Tue, Mar 08, 2016 at 08:39:37PM -0500, Leo Famulari wrote:
> >> On Wed, Mar 09, 2016 at 01:25:04AM +0100, Tobias Geerinckx-Rice wrote:
> >> > On 09/03/2016, Leo Famulari  wrote:
> >> > > [...] pass to ./configure '--disable-packagekit'. Would that work?
> >> > 
> >> > So do ‘we’:
> >> > 
> >> > On Tue, Mar 08, 2016 at 11:04:35PM +0100, Tobias Geerinckx-Rice wrote:
> >> > > '(#:configure-flags '("--disable-packagekit")
> >> 
> >> Oops! Serves me right for trying to squeeze this review in earlier ;)
> >> 
> >> > There are various ways to code this, but none that don't amount to
> >> > deleting (generated) source files.[1]
> >> 
> >> I didn't realize this was generated C code. In that case it's closer to
> >> a compiled binary than source code, don't you think? Can we delete all
> >> the generated files and rebuild them from source?
> >
> > Anyways, that is probably something to look into later. I think it makes
> > sense to do this update, remove that file, and include a link to the bug
> > report with a bit of context.
> >
> > Does anyone have any objections to that plan?
> 
> I’m not sure I fully grasped everything, but the plan looks good.  And
> since it’s an update and the problem was already there, let’s not annoy
> Tobias more than this.  :-)

Pushed with some additional context as fb9ca51130a.

[PATCH] doc: Explain --localstatedir some more.

[Jookia]

This should hopefully stop people from running in to issues when
building Guix from source as they have in the past.

* doc/guix.texi (Requirements): Add explanation of the localstatedir flag.
  Discuss how to keep compatibility with binary installation and the package.
---
 doc/guix.texi | 17 +++--
 1 file changed, 15 insertions(+), 2 deletions(-)

diff --git a/doc/guix.texi b/doc/guix.texi
index 0e8e5ad..94323ff 100644
--- a/doc/guix.texi
+++ b/doc/guix.texi
@@ -16,8 +16,9 @@ Copyright @copyright{} 2013 Nikita Karetnikov@*
 Copyright @copyright{} 2015, 2016 Mathieu Lirzin@*
 Copyright @copyright{} 2014 Pierre-Antoine Rault@*
 Copyright @copyright{} 2015 Taylan Ulrich Bayırlı/Kammer@*
-Copyright @copyright{} 2015, 2016 Leo Famulari
-Copyright @copyright{} 2016 Ben Woodcroft
+Copyright @copyright{} 2015, 2016 Leo Famulari@*
+Copyright @copyright{} 2016 Ben Woodcroft@*
+Copyright @copyright{} 2016 Jookia
 
 Permission is granted to copy, distribute and/or modify this document
 under the terms of the GNU Free Documentation License, Version 1.3 or
@@ -514,6 +515,18 @@ manager} is available, you
 can instead configure Guix with @code{--disable-daemon}.  In that case,
 Nix replaces the three dependencies above.
 
+Tradionally Guix stores its state in @var{localstatedir} as most GNU
+applications do.  In certain situations you may want to change this setting,
+by passing the @code{--localstatedir=@var{path}} flag to @command{configure}.
+
+The binary installation of Guix and the package of Guix both use @code{/var} as
+their @var{localstatedir} path.  If you wish to have compatibility with one of
+these versions of Guix installed or you plan to install, passing
+@code{--localstatedir=/var} to @command{configure} will allow your compiled 
Guix
+to share state.  Be warned that sharing the same Guix store (usually located at
+@code{/gnu}) with different sets of state could cause issues such as garbage
+collecting store entries that are alive in one Guix's state but not the 
other's.
+
 Guix is compatible with Nix, so it is possible to share the same store
 between both.  To do so, you must pass @command{configure} not only the
 same @code{--with-store-dir} value, but also the same
-- 
2.7.0

Re: [CVE] libotr -> upgrade to 4.1.1

[Andreas Enge]

On Wed, Mar 09, 2016 at 03:27:33PM -0500, Leo Famulari wrote:
> Thanks for the notification! Updated with 89e58e8e8c.

It is difficult to beat you!

There was also a libotr-3 without any dependent package, so I simply
removed it.

Andreas

Re: [CVE] libotr -> upgrade to 4.1.1

[Leo Famulari]

On Wed, Mar 09, 2016 at 08:59:20PM +0100, Nils Gillmann wrote:
> I have no time to do and testrun this upgrade myself (in the
> middle of testing gnunet related things), but someone if not
> already on this, could (more like should) upgrade our libotr
> package:
> 
> https://lists.cypherpunks.ca/pipermail/otr-users/2016-March/002581.html

Thanks for the notification! Updated with 89e58e8e8c.

> 
> thanks,
> -- 
> ng
> personal contact: http://krosos.sdf.org
> EDN: https://wiki.c3d2.de/Echt_Dezentrales_Netz/en
> 
> 

[RFCv3] install: Create a GC root during install-grub.

[Jookia]

While previously creating a GC root for GRUB's resources was the caller's
responsibility, it's much less repetitive to put it in install-grub now that
it's wrapped by error handling. This also means we can replace the install-grub*
function with a small definition inside perform-action named 'install-boot'.

* gnu/build/install.scm (install-grub): Make a GC root for grub.cfg on success.
  (register-grub.cfg-root): Remove function, install-grub does this now.
* gnu/system/vm.scm (qemu-image): Don't explicitly make a GC root.
* guix/scripts/system.scm (install-grub*): Move useful parts to perform-action.
  (perform-action): Use inline definition install-boot to install GRUB.
---
 gnu/build/install.scm   | 22 +-
 gnu/system/vm.scm   | 15 +++
 guix/scripts/system.scm | 48 +---
 3 files changed, 29 insertions(+), 56 deletions(-)

diff --git a/gnu/build/install.scm b/gnu/build/install.scm
index e4f087f..b28dea8 100644
--- a/gnu/build/install.scm
+++ b/gnu/build/install.scm
@@ -22,7 +22,6 @@
   #:use-module (srfi srfi-26)
   #:use-module (ice-9 match)
   #:export (install-grub
-register-grub.cfg-root
 populate-root-file-system
 reset-timestamps
 register-closure
@@ -39,13 +38,10 @@
 
 (define* (install-grub grub.cfg device mount-point)
   "Install GRUB with GRUB.CFG on DEVICE, which is assumed to be mounted on
-MOUNT-POINT.
-
-Note that the caller must make sure that GRUB.CFG is registered as a GC root
-so that the fonts, background images, etc. referred to by GRUB.CFG are not
-GC'd."
+MOUNT-POINT."
   (let* ((target (string-append mount-point "/boot/grub/grub.cfg"))
- (pivot  (string-append target ".new")))
+ (pivot  (string-append target ".new"))
+ (gcroot "/var/guix/gcroots"))
 (mkdir-p (dirname target))
 
 ;; Copy GRUB.CFG instead of just symlinking it, because symlinks won't
@@ -57,13 +53,13 @@ GC'd."
 "--boot-directory"
 (string-append mount-point "/boot")
 device))
-  (error "failed to install GRUB"
+  (error "failed to install GRUB"))
 
-(define (register-grub.cfg-root target grub.cfg)
-  "On file system TARGET, register GRUB.CFG as a GC root."
-  (let ((directory (string-append target "/var/guix/gcroots")))
-(mkdir-p directory)
-(symlink grub.cfg (string-append directory "/grub.cfg"
+;; Register GRUB.CFG as a GC root so the fonts, background images, etc.
+;; referred to by GRUB.CFG are not GC'd.
+(evaluate-populate-directive `(directory ,gcroot) mount-point)
+(evaluate-populate-directive
+  `(,(string-append gcroot "/grub.cfg") -> ,grub.cfg) mount-point)))
 
 (define (evaluate-populate-directive directive target)
   "Evaluate DIRECTIVE, an sexp describing a file or directory to create under
diff --git a/gnu/system/vm.scm b/gnu/system/vm.scm
index 35c573d..e8a577c 100644
--- a/gnu/system/vm.scm
+++ b/gnu/system/vm.scm
@@ -228,14 +228,13 @@ the image."
   (guix build utils))
 
  (define* (do-install-grub #:key device target)
-   (and #$(prepare-install-grub
-#:mount-point 'target
-#:grub.cfg grub.cfg
-#:config
-  (grub-configuration
-(inherit (operating-system-bootloader 
os-configuration))
-(device drive)))
-(register-grub.cfg-root target #$grub.cfg)))
+   #$(prepare-install-grub
+   #:mount-point 'target
+   #:grub.cfg grub.cfg
+   #:config
+ (grub-configuration
+   (inherit (operating-system-bootloader os-configuration))
+   (device drive
 
  (let ((inputs
 '#$(append (list qemu parted grub e2fsprogs)
diff --git a/guix/scripts/system.scm b/guix/scripts/system.scm
index dae47a5..57e5a18 100644
--- a/guix/scripts/system.scm
+++ b/guix/scripts/system.scm
@@ -126,33 +126,6 @@ TARGET, and register them."
   (map (cut copy-item <> target #:log-port log-port)
to-copy
 
-(define* (install-grub* #:key grub.cfg config target)
-  "This is a variant of 'install-grub' with error handling, lifted in
-%STORE-MONAD"
-  (let* ((gc-root  (string-append target %gc-roots-directory
-  "/grub.cfg"))
- (temp-gc-root (string-append gc-root ".new"))
- (delete-file  (lift1 delete-file %store-monad))
- (make-symlink (lift2 switch-symlinks %store-monad))
- (rename   (lift2 rename-file %store-monad)))
-(mbegin %store-monad
-  ;; Prepare the symlink to GRUB.CFG to make sure that it's a GC root when
-  ;; 'install-grub' completes (being a bit paranoid.)
-  (make-symlink temp-gc-root grub.cfg)
-
-  (munless (eval 

[CVE] libotr -> upgrade to 4.1.1

[Nils Gillmann]

I have no time to do and testrun this upgrade myself (in the
middle of testing gnunet related things), but someone if not
already on this, could (more like should) upgrade our libotr
package:

https://lists.cypherpunks.ca/pipermail/otr-users/2016-March/002581.html

thanks,
-- 
ng
personal contact: http://krosos.sdf.org
EDN: https://wiki.c3d2.de/Echt_Dezentrales_Netz/en

Re: [PATCH] gnunet-gtk: adds --with-gnunet to configure-flags

[Nils Gillmann]

Andreas Enge  writes:

> On Tue, Mar 08, 2016 at 06:22:23PM +0100, Ricardo Wurmus wrote:
>> > Guix should provide a stable experience, but if stable means too
>> > old to deliver a useable experience of an still in development
>> > network, what do we suggest? I would not replace gnunet and
>> > gnunet-gtk, I would just make gnunet-svn the default (gnunet will
>> > default to gnunet-svn) and gnunet-0.10.1 will have to be
>> > installed explicitly.
>> The reply to my bug report said something similar.  If version 0.10.1 is
>> so old that upstream suggest taking the latest from SVN I suppose we
>> should do this too.
>
> I would argue that if upstream cannot be bothered to make a stable release
> every once in a while, this is not our business, unless there are dependent
> packages that stop working.
>
> On the other hand, as I fear that the number of users of the current gnunet 
> is very limited, it probably does not hurt to update it with the version
> number 0.10.1-1-xxx for some svn checkout xxx.

I am currently working on it, see also my latest Email to
guix-devel including the whys and tl;drs.

> Andreas
>
>
>

-- 
ng
personal contact: http://krosos.sdf.org
EDN: https://wiki.c3d2.de/Echt_Dezentrales_Netz/en

Re: [PATCH] gnu: Include CodingQuarry gene predictor

[Andreas Enge]

On Tue, Mar 08, 2016 at 06:39:37PM -0500, Leo Famulari wrote:
> > + (delete 'check) ;; Don't run the 'make check' step of the
> > gnu-build-system
> When skippping the tests, we prefer to say why in the comment. It can be
> as simple as "no test suite" if that is the case.

And use in the argument block:
#:tests? #f
instead of deleting the phase.

Andreas

Re: [PATCH] gnunet-gtk: adds --with-gnunet to configure-flags

[Andreas Enge]

On Tue, Mar 08, 2016 at 06:22:23PM +0100, Ricardo Wurmus wrote:
> > Guix should provide a stable experience, but if stable means too
> > old to deliver a useable experience of an still in development
> > network, what do we suggest? I would not replace gnunet and
> > gnunet-gtk, I would just make gnunet-svn the default (gnunet will
> > default to gnunet-svn) and gnunet-0.10.1 will have to be
> > installed explicitly.
> The reply to my bug report said something similar.  If version 0.10.1 is
> so old that upstream suggest taking the latest from SVN I suppose we
> should do this too.

I would argue that if upstream cannot be bothered to make a stable release
every once in a while, this is not our business, unless there are dependent
packages that stop working.

On the other hand, as I fear that the number of users of the current gnunet 
is very limited, it probably does not hurt to update it with the version
number 0.10.1-1-xxx for some svn checkout xxx.

Andreas

addresses: works around gnunet-gtk, gnunet, attention push for powwow, un-font, general question

[Nils Gillmann]

Multiple questions:
Hi,

I am curious (not impatient) about if people with commit access
are just busy and/or focused on other issues or if my way to
reply to my own messages and make threads a bit uncomfortable to
read and update information gets lost as I mainly use nntp access
via gmane.org now and don't CC people anymore.
If there's something I can do to improve this situation, I am
open for suggestions.

There's 2 fixed packages, this one with the fixed patch for the
new package un-font, which will for now be hosted at my sdf.org
account:
https://lists.gnu.org/archive/html/guix-devel/2016-03/msg00244.html
if you still spot issues, try to search the thread for a newer
one without issues as indeed, the threading became bad,

and this one for powwow, fixes all issues:
https://lists.gnu.org/archive/html/guix-devel/2016-03/msg00282.html

Then there's the recent patch for gnunet-gtk 0.10.1, a short
message exchange with Christian Grothoff, Jookia, and myself
today leads to the following conclusion which will be further
explained in a new patch series coming either today or on sunday:

- we will keep 0.10.1 (please apply the recent patch I did send)
- I will modify the description of 0.10.1 related packages of
  gnunet and gnunet-gtk to relect cg's and my conversation's
  outcome.
- gnunet will get a new, additional package, co-authored with
  Jookia, using a recent svn checkout which will be explained
  in the message send with the patch.
TL;DR in before I send them:

0.10.1 is old. There has been no new release so far because the
next one needs to be stable. CADET has open bugs which need to be
fixed to get to a new release candidate. API *and* protocol
compability will break with /newer/ versions than 0.10.1 (0.10.1
incompatible towards >0.10.1), which is why you should use SVN
when you want to test the in development network stack and the
application developed around and inside it, to get a 2 year old
version of it is bound to provide an outdated experience.

Regarding un-font and hosting:
Outcome of the conversation with IN-Berlin so far was, that due
to the nature of their project they have no common shared
infrastructure for a public download server, but my intention is
to introduce them to GuixSD at some point when it is functional
enough for production servers. Un-font file will remain on my
sdf.org space for the time being, when traffic should get too
much, I will use one of my servers and set up an access for file
hosting purposes and also upload it to more public/cdn spaces to
provide more than just one url. (then again: it's only one font
so far...)


I will be gone from thursday evening to sunday morning to the
Logan CIJ Symposium but try to get my gnunet changes finished
either before, during or afterwards.

thanks & happy hacking,
-- 
ng
personal contact: http://krosos.sdf.org
EDN: https://wiki.c3d2.de/Echt_Dezentrales_Netz/en

Re: Releasing 0.9.1

[Ludovic Courtès]

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

> So, on this branch, I’d incorporate:
>
>   dbus and dbus/activation
>   eudev and eudev-with-blkid
>   graphite2 and its replacement
>   perl and its replacement
>   openssl and its replacement

Done in ‘security-updates’.

I’ll get it built by Hydra if there are no objections!

Ludo’.

Re: [PATCH 5/6] gnu: libetonyek: Update to 0.1.6.

[Andreas Enge]

On Wed, Mar 09, 2016 at 10:50:46AM +0100, Andreas Enge wrote:
> Now I will try if libreoffice 5.1 builds without updating other libraries.

It does not, I think your patches are really necessary, Efraim. I pushed
the liblangtag one. Libreoffice 5.1 still checks for the old mdds, and
insists on the non-existing orcus-0.10 (instead of the 0.9 we have and the
0.11 that is available). I modified the configure script to search for the
newer versions instead, but now the build fails in a part related to orcus.
So I think all we can do now is wait and hope that libreoffice sorts out
this mess in the next release.

I modified a few packages, in particular to document all modifications in the
commit message. For maybe future use, I am attaching them all, as well as the
error message from the build.

Andreas

>From 951c16948908343566c2234f55e6bd7a4b390233 Mon Sep 17 00:00:00 2001
From: Efraim Flashner 
Date: Mon, 7 Mar 2016 12:42:03 +0200
Subject: [PATCH 1/5] gnu: mdds: Update to 1.1.0.

* gnu/packages/boost.scm (mdds): Update to 1.1.0.
[home-page]: Update to new homepage.
(mdds-0.12.1): Keep for libreoffice.
---
 gnu/packages/boost.scm | 26 +-
 1 file changed, 21 insertions(+), 5 deletions(-)

diff --git a/gnu/packages/boost.scm b/gnu/packages/boost.scm
index 0a644e8..47eacd1 100644
--- a/gnu/packages/boost.scm
+++ b/gnu/packages/boost.scm
@@ -2,8 +2,9 @@
 ;;; Copyright © 2014 John Darrington 
 ;;; Copyright © 2014, 2015 Mark H Weaver 
 ;;; Copyright © 2015 Andreas Enge 
-;;; Copyright © 2016 Eric Bavier 
 ;;; Copyright © 2015 Ludovic Courtès 
+;;; Copyright © 2016 Eric Bavier 
+;;; Copyright © 2016 Efraim Flashner 
 ;;;
 ;;; This file is part of GNU Guix.
 ;;;
@@ -107,21 +108,36 @@ across a broad spectrum of applications.")
 (define-public mdds
   (package
 (name "mdds")
-(version "0.12.1")
+(version "1.1.0")
 (source (origin
  (method url-fetch)
  (uri (string-append
-   "http://kohei.us/files/mdds/src/mdds_; version ".tar.bz2"))
+   "http://kohei.us/files/mdds/src/mdds-; version ".tar.bz2"))
  (sha256
   (base32
-   "0gg8mb9kxh3wggh7njj1gf90xy27p0yq2cw88wqar9hhg2fmwmi3"
+   "07qnzg9qn6vlh70wdn72kywil680z3qlgqjh38r7kdcbzs9snls2"
 (build-system gnu-build-system)
 (propagated-inputs
   `(("boost" ,boost))) ; inclusion of header files
-(home-page "https://code.google.com/p/multidimalgorithm/;)
+(home-page "https://gitlab.com/mdds/mdds;)
 (synopsis "Multi-dimensional C++ data structures and indexing algorithms")
 (description "Mdds (multi-dimensional data structure) provides a
 collection of multi-dimensional data structures and indexing algorithms
 for C++.  It includes flat segment trees, segment trees, rectangle sets,
 point quad trees, multi-type vectors and multi-type matrices.")
 (license license:expat)))
+
+;; Libreoffice needs mdds-0.12.1 to build, but its dependancies need mdds-1.0+.
+;; Rather than use an external binary while building libreoffice, it's better
+;; to keep this version around until Libreoffice updates its dependancy.
+(define-public mdds-0.12.1
+  (package
+(inherit mdds)
+(version "0.12.1")
+(source
+  (origin
+(method url-fetch)
+(uri (string-append "http://kohei.us/files/mdds/src/mdds_; version 
".tar.bz2"))
+(sha256
+ (base32
+  "0gg8mb9kxh3wggh7njj1gf90xy27p0yq2cw88wqar9hhg2fmwmi3"))
-- 
2.6.3

>From 3c0843d049634d6a20dd6aa791ae5382bd3a1aab Mon Sep 17 00:00:00 2001
From: Efraim Flashner 
Date: Mon, 7 Mar 2016 12:42:06 +0200
Subject: [PATCH 2/5] gnu: libetonyek: Update to 0.1.6.

* gnu/packages/libreoffice.scm (libetonyek)[source]: Update to 0.1.6.
  [inputs]: Add required input liblangtag.
---
 gnu/packages/libreoffice.scm | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/gnu/packages/libreoffice.scm b/gnu/packages/libreoffice.scm
index 9d58a26..57e53b7 100644
--- a/gnu/packages/libreoffice.scm
+++ b/gnu/packages/libreoffice.scm
@@ -347,20 +347,21 @@ CorelDRAW documents of all versions.")
 (define-public libetonyek
   (package
 (name "libetonyek")
-(version "0.1.3")
+(version "0.1.6")
 (source
  (origin
   (method url-fetch)
   (uri (string-append "http://dev-www.libreoffice.org/src/; name "/"
   name "-" version ".tar.xz"))
   (sha256 (base32
-   "0mghaqzj0qqza8z1gzprw62702adlww4kgdzynj5qpxxc9m2f4py"
+   "0y60vi1plyq69fqbcjnc0v8mvcjqjsl1ry6rmb3bq3q7j8a2fm6z"
 (build-system gnu-build-system)
 (native-inputs
  `(("cppunit" ,cppunit)
("doxygen" ,doxygen)
("glm" ,glm)
("gperf" ,gperf)
+   ("liblangtag" ,liblangtag)

Re: [PATCH] gnu: simple-scan: Update to 3.19.91.

[Ludovic Courtès]

Leo Famulari  skribis:

> On Tue, Mar 08, 2016 at 08:39:37PM -0500, Leo Famulari wrote:
>> On Wed, Mar 09, 2016 at 01:25:04AM +0100, Tobias Geerinckx-Rice wrote:
>> > On 09/03/2016, Leo Famulari  wrote:
>> > > [...] pass to ./configure '--disable-packagekit'. Would that work?
>> > 
>> > So do ‘we’:
>> > 
>> > On Tue, Mar 08, 2016 at 11:04:35PM +0100, Tobias Geerinckx-Rice wrote:
>> > > '(#:configure-flags '("--disable-packagekit")
>> 
>> Oops! Serves me right for trying to squeeze this review in earlier ;)
>> 
>> > There are various ways to code this, but none that don't amount to
>> > deleting (generated) source files.[1]
>> 
>> I didn't realize this was generated C code. In that case it's closer to
>> a compiled binary than source code, don't you think? Can we delete all
>> the generated files and rebuild them from source?
>
> Anyways, that is probably something to look into later. I think it makes
> sense to do this update, remove that file, and include a link to the bug
> report with a bit of context.
>
> Does anyone have any objections to that plan?

I’m not sure I fully grasped everything, but the plan looks good.  And
since it’s an update and the problem was already there, let’s not annoy
Tobias more than this.  :-)

Eventually, I agree it’ll be best to remove the generated C files,
though.

Ludo’.

Re: Releasing 0.9.1

[Ludovic Courtès]

So!  It seems that this time releasing is really hard.  :-)

I’d like to do a rebuild without any package replacements, in the hope
that the release itself has no or few grafts in place, mostly because:

  • performance is currently degraded in the presence of grafts, in
particular the repeated “updating the list of substitutes” (I have a
rough idea on how to fix, but we’d rather not hold our breath);

  • they increase disk usage, so the USB images would be bigger.

So, on this branch, I’d incorporate:

  dbus and dbus/activation
  eudev and eudev-with-blkid
  graphite2 and its replacement
  perl and its replacement
  openssl and its replacement

I don’t want to base it on ‘core-updates’ because there are potentially
disrupting changes in there.

Thoughts?

Ludo’.

Re: Yet another Hydra mirror: hydra-mirror.marusich.info

[Ludovic Courtès]

Chris Marusich  skribis:

> No, I'm not using that at the moment. In the future, if I set up any
> nginx servers to accomplish the same task, I will definitely use it. I
> would prefer to run my own servers, but for now this is something I can
> do immediately to help the project, so I decided to do it.
>
> CloudFront is a service, so you use its API (or the AWS Management
> Console, which is a web UI for the API) to create a "distribution" and
> configure it to use hydra.gnu.org as its "origin". A little extra work
> is required to glue everything together. For example, I had to create a
> CNAME pointing from hydra-mirror.marusich.info to
> d2xj50ygrk34qq.cloudfront.net, which is the canonical name of my
> distribution. Once it's configured, all requests sent to
> hydra-mirror.marusich.info are serviced by a nearby point of presence in
> the CloudFront content distribution network, and the results are cached.

OK.

Do you know exactly how much is cached?  Also, when does caching happen?

When using nginx as a proxy as on mirror.guixsd.org, it fetches things
lazily, so on a cache miss it goes connect to hydra.gnu.org.

> I've noticed that Hydra does not include cache-related headers (e.g.,
> Cache-Control). Perhaps for this reason, the nginx config you linked
> seems to pick arbitrary caching settings. When using CloudFront, a
> distribution can be configured to respect the Cache-Control headers sent
> by the origin server. Does nginx provide similar functionality? Would it
> make sense to have hydra.gnu.org return such headers?

Dunno, maybe!  Maybe we could tell nginx to add such headers?  What
would be the right thing?

> For now, I've configured hydra-mirror.marusich.info to cache all
> successful requests for 1 week, and to respect cache-related headers
> from the hydra.gnu.org if it ever decides to send them. This seemed like
> a reasonable configuration for data which is not expected to change.

Yeah, mirror.guixsd.org also caches for one week now.  I wasn’t sure how
much disk space that would represent, but so far we’re around 10G, so
increasing to 1 week seemed reasonable.

Thanks,
Ludo’.

Re: Yet another Hydra mirror: hydra-mirror.marusich.info

[Ludovic Courtès]

Andreas Enge  skribis:

> On Tue, Mar 08, 2016 at 10:04:33AM +0100, Andy Wingo wrote:
>> Right now hydra.gnu.org is in this weird situation where people who use
>> it have to trust it, modulo "guix challenge" of course.  But really all
>> we have to trust is the mapping from the derivation (like the "foo"
>> package) to a hash of the build results; the actual build result could
>> be transferred from anywhere with no trust issues at all, provided that
>> we verify the hash.  (Do I understand the situation correctly?)
>
> Yes, if I understand you correctly :-)

I think you both understand correctly.  :-)

That is, hydra.gnu.org serves narinfos like:

  http://hydra.gnu.org/n0rgvy9c0cwv453k5bczwscp6iwqa4fc.narinfo

They contain all the meta-data for the corresponding store item,
including a hash of its content, and said meta-data is signed.  See
(guix pki) and

for details

This is why we can mirror things as-is and have users benefit from it
without having to trust any additional party.


Mirrors are nice because they’re easy to set up, completely transparent
for users, and allow our infrastructure to scale quickly.  Now, another
thing that would be great is to have independent build farms (running
‘guix publish’) so there is no single point of trust.

Ludo’.

Re: Updating Vim

[Efraim Flashner]

On Wed, 9 Mar 2016 10:45:44 +0100
Andreas Enge  wrote:

> On Wed, Mar 09, 2016 at 11:16:16AM +0200, Efraim Flashner wrote:
>  [...]  
> 
> Well, it is not quite a release, I would say, if they simply tag every git
> commit and do not even make sure that the tests succeed each time. Normally,
> our policy in guix is to follow "official" upstream releases.
> 
> Is there a compelling reason to update nevertheless?
> 
> Andreas
> 

There was something that was not interacting well with my .vimrc, but I just
checked with 7.4 and 7.4.963 and there wasn't actually a change. Either I
stopped using some plugin that wanted a newer version or I misread it before.
"Because its 2 years old" isn't a great reason. There is a list of patches
with a 1-liner[1] for what it fixes, so I suppose for that it would be good
to have those issues taken care of, and also to have our copy of vim more
up-to-date with other distros.

[1] ftp://ftp.vim.org/pub/vim/patches/7.4/README

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


pgpLXlyPps_cB.pgp
Description: OpenPGP digital signature

Re: [PATCH] gnu: Add freebayes.

[Ricardo Wurmus]

Roel Janssen  writes:

> One of the problems with the patch is probably the bulk of dependencies
> dragged in (for example, vcflib).  They use specific versions so they
> are tied to this package (so that's why I cannot package them separately).

Yeah, this is worrying.

> From 38302e8cac77275694c8793933be414ec26906ec Mon Sep 17 00:00:00 2001
> From: Roel Janssen 
> Date: Tue, 8 Mar 2016 16:38:46 +0100
> Subject: [PATCH] gnu: Add freebayes.

> * gnu/packages/bioinformatics.scm (freebayes): New variable.

[...]

> +(define-public freebayes
> +  (let ((commit "3ce827d8ebf89bb3bdc097ee0fe7f46f9f30d5fb"))
> +(package
> +  (name "freebayes")
> +  (version (string-append "v1.0.2-" (string-take commit 7)))

The version should not start with “v” and it should include a numeric
revision because later git commits may be sorted lower than the current
commit.

(let ((commit )
  (revision "1"))
  ...
  (version (string-append "1.0.2-" revision "." commit))
  ...)

Why does it have to be a git clone, though?  I see that only six commits
were made to master since release 1.0.2.  If fetching from git must
happen it would be good to have a reason in a comment.

> +  (native-inputs
> +   `(("cmake" ,cmake)
> + ("htslib" ,htslib)
> + ("zlib" ,zlib)

“htslib” and “zlib” sound like regular inputs.

> + ("python" ,python-2)
> + ("perl" ,perl)

These maybe as well.

> + ("bamtools-src"
> +  ,(origin
> + (method url-fetch)
> + (uri (string-append "https://github.com/ekg/bamtools/archive/;
> +  "e77a43f5097ea7eee432ee765049c6b246d49baa" ".tar.gz"))
> + (file-name "bamtools-src.tar.gz")
> + (sha256
> +  (base32 
> "0rqymka21g6lfjfgxzr40pxz4c4fcl77jpy1np1li70pnc7h2cs1"

We already have bamtools, I think.  Is there no way to link with that
version?  Does it have to be this arbitrary-looking commit?

> + ("vcflib-src"
> +  ,(origin
> + (method url-fetch)
> + (uri (string-append "https://github.com/vcflib/vcflib/archive/;
> +  "5ac091365fdc716cc47cc5410bb97ee5dc2a2c92" ".tar.gz"))
> + (file-name "vcflib-5ac0913.tar.gz")
> + (sha256
> +  (base32 
> "0ywshwpif059z5h0g7zzrdfzzdj2gr8xvwlwcsdxrms3p9iy35h8"

> + ;; These are submodules for the vcflib version used in freebayes
> + ("tabixpp-src"
> + ("intervaltree-src"
> + ("smithwaterman-src"
> + ("multichoose-src"
> + ("fsom-src"
> + ("filevercmp-src"
> + ("fastahack-src"

If these are submodules of this particular version of vcflib I think it
would be better to create a separate vcflib package where these
submodules are included.  If ever possible you would then coerce
freebayes to link with that version of vcflib.

Note that vcflib doesn’t *have* to be exported via define-public.  It
would be nice, though, if we could get a regular vcflib package as a
side-effect of all this.

> +  (arguments
> +   `(#:tests? #f

Please quickly comment on why the tests are disabled.

> + #:phases
> + (modify-phases %standard-phases
> +   (delete 'configure)
> +   (delete 'check)

You won’t need this when tests are disabled already.

> +   (add-after 'unpack 'unpack-submodule-sources
> + (lambda* (#:key inputs #:allow-other-keys)
> +   (let ((unpack (lambda (source target)
> +   (with-directory-excursion target
> + (zero? (system* "tar" "xvf"
> + (assoc-ref inputs source)
> + "--strip-components=1"))
> + (and
> +  (unpack "bamtools-src" "bamtools")
> +  (unpack "vcflib-src" "vcflib")
> +  (unpack "intervaltree-src" "intervaltree")
> +  (unpack "fastahack-src" "vcflib/fastahack")
> +  (unpack "filevercmp-src" "vcflib/filevercmp")
> +  (unpack "fsom-src" "vcflib/fsom")
> +  (unpack "intervaltree-src" "vcflib/intervaltree")
> +  (unpack "multichoose-src" "vcflib/multichoose")
> +  (unpack "smithwaterman-src" "vcflib/smithwaterman")
> +  (unpack "tabixpp-src" "vcflib/tabixpp")
> +   (add-after 'unpack-submodule-sources 'fix-makefile
> + (lambda* (#:key inputs #:allow-other-keys)
> +   ;; We don't have the .git folder to get the version tag from.
> +   ;; For this checkout of the code, it's v1.0.0.
> +   (substitute* '("vcflib/Makefile")
> + (("^GIT_VERSION.*") "GIT_VERSION = v1.0.0"
> +   (replace
> +'build
> +(lambda* (#:key inputs make-flags 

Re: [PATCH 5/6] gnu: libetonyek: Update to 0.1.6.

[Andreas Enge]

Hello,

I locally applied it, but changed the commit message as follows:

gnu: libetonyek: Update to 0.1.6.

* gnu/packages/libreoffice.scm (libetonyek)[source]: Update to 0.1.6.
  [inputs]: Add required input liblangtag.

to record all modifications. This requires the 1.0 version of mdds, which
may not be compatible with what libreoffice currently needs. So I will
hold it back for the moment.

I also (re-)enabled parallel builds for libreoffice; at least on my x86_64
laptop, this works, and libreoffice does not build an any other architecture
right now anyway...

Now I will try if libreoffice 5.1 builds without updating other libraries.

None of this is pushed so far, but I consider pushing the parallel build
feature as well as Efraim's liblangtag with a modified description as I
suggested in a previous message; since this library is not used yet, it
cannot break anything...

Andreas

Re: Updating Vim

[Andreas Enge]

On Wed, Mar 09, 2016 at 11:16:16AM +0200, Efraim Flashner wrote:
> Our current vim package is 2.5 years old, and the current patch set on top of
> it to bring it up to today is ~1500 patches. Interestingly, every. single.
> commit. is tagged in git, so updating to a more recent release is rather easy.

Well, it is not quite a release, I would say, if they simply tag every git
commit and do not even make sure that the tests succeed each time. Normally,
our policy in guix is to follow "official" upstream releases.

Is there a compelling reason to update nevertheless?

Andreas

Re: [PATCH] gnu: Add bioawk.

[Ricardo Wurmus]

Roel Janssen  writes:

> Please let me know when something is wrong with the patch.

In addition to Leo’s comments here are mine:

> +(arguments
> + `(#:parallel-build? #f

Why is parallel-build disabled?  Could you add a comment?

> +   #:phases
> +   (modify-phases %standard-phases
> + (delete 'configure)
> + (delete 'check)

We usually just do “#:tests? #f” with a comment, instead of deleting the
“check” phase.

> + (replace
> +  'install

Please put “'install” on the same line as “(replace”.

> +  (lambda* (#:key outputs #:allow-other-keys)
> +(let ((bin (string-append (assoc-ref outputs "out") "/bin")))
> +  (install-file "bioawk" bin)))
> +(home-page "https://github.com/lh3/bioawk;)
> +(synopsis "AWK with bioinformatics extensions")
> +(description "Bioawk is an extension to Brian Kernighan's awk, adding the
> +support of several common biological data formats, including optionally 
> gzip'ed
> +BED, GFF, SAM, VCF, FASTA/Q and TAB-delimited formats with column names.  It
> +also adds a few built-in functions and an command line option to use TAB as 
> the

“a command-line option”, not “an”

Thanks!

~~ Ricardo

Re: Updating Vim

[Efraim Flashner]

On Wed, 9 Mar 2016 10:39:08 +0100
Ricardo Wurmus  wrote:

> Efraim Flashner  writes:
> 
>  [...]  
> 
> Interesting.
> 
> Both patches look good to me.  If I was in nit-picking mode I’d say that
> 
> “[source]: Use git-tags for downloading.”
> 
> in the commit message is a little confusing because “git-tags” sounds
> like a procedure name.  I’d just write “[source]: Fetch from git.”.
> 
> ~~ Ricardo

"Fetch from git." does sound much better.

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


pgpWuUO9HIPVF.pgp
Description: OpenPGP digital signature

Re: Updating Vim

[Ricardo Wurmus]

Efraim Flashner  writes:

> Our current vim package is 2.5 years old, and the current patch set on top of
> it to bring it up to today is ~1500 patches. Interestingly, every. single.
> commit. is tagged in git, so updating to a more recent release is rather easy.
> This has been one of the things that has kept me using Debian's vim over
> Guix's vim.In this patch I've only updated it to 7.4.963 because that's the
> version Debian is currently shipping (in sid), which is only 3 months old,
> and some of the later versions had issues with the test. This'll bump us
> forward a lot, which is a good starting point.

Interesting.

Both patches look good to me.  If I was in nit-picking mode I’d say that

“[source]: Use git-tags for downloading.”

in the commit message is a little confusing because “git-tags” sounds
like a procedure name.  I’d just write “[source]: Fetch from git.”.

~~ Ricardo

Updating Vim

[Efraim Flashner]

Our current vim package is 2.5 years old, and the current patch set on top of
it to bring it up to today is ~1500 patches. Interestingly, every. single.
commit. is tagged in git, so updating to a more recent release is rather easy.
This has been one of the things that has kept me using Debian's vim over
Guix's vim.In this patch I've only updated it to 7.4.963 because that's the
version Debian is currently shipping (in sid), which is only 3 months old,
and some of the later versions had issues with the test. This'll bump us
forward a lot, which is a good starting point.

-- 
Efraim Flashner      אפרים פלשנר
GPG key = A28B F40C 3E55 1372 662D  14F7 41AA E7DC CA3D 8351
Confidentiality cannot be guaranteed on emails sent or received unencrypted
From d99bead9ea8ea9d72ab128aab404f8513cfc5253 Mon Sep 17 00:00:00 2001
From: Efraim Flashner 
Date: Wed, 9 Mar 2016 11:07:39 +0200
Subject: [PATCH 1/2] gnu: vim: Update to 7.4.963.

* gnu/packages/vim.scm (vim): Update to 7.4.963.
[source]: Use git-tags for downloading.
---
 gnu/packages/vim.scm | 22 +-
 1 file changed, 13 insertions(+), 9 deletions(-)

diff --git a/gnu/packages/vim.scm b/gnu/packages/vim.scm
index 2418963..4834b69 100644
--- a/gnu/packages/vim.scm
+++ b/gnu/packages/vim.scm
@@ -1,5 +1,6 @@
 ;;; GNU Guix --- Functional package management for GNU
 ;;; Copyright © 2013 Cyril Roelandt 
+;;; Copyright © 2016 Efraim Flashner 
 ;;;
 ;;; This file is part of GNU Guix.
 ;;;
@@ -19,7 +20,7 @@
 (define-module (gnu packages vim)
   #:use-module ((guix licenses) #:prefix license:)
   #:use-module (guix packages)
-  #:use-module (guix download)
+  #:use-module (guix git-download)
   #:use-module (guix build-system gnu)
   #:use-module (gnu packages)
   #:use-module (gnu packages gawk)
@@ -31,14 +32,17 @@
 (define-public vim
   (package
 (name "vim")
-(version "7.4")
-(source (origin
- (method url-fetch)
- (uri (string-append "ftp://ftp.vim.org/pub/vim/unix/vim-;
- version ".tar.bz2"))
- (sha256
-  (base32
-   "1pjaffap91l2rb9pjnlbrpvb3ay5yhhr3g91zabjvw1rqk9adxfh"
+(version "7.4.963")
+(source
+  (origin
+(method git-fetch)
+(uri (git-reference
+   (url "https://github.com/vim/vim.git;)
+   (commit (string-append "v" version
+(file-name (string-append "vim-" version "-checkout"))
+(sha256
+ (base32
+  "1k4n5ybw5wp2iwfp8ax7x3cq5x137rq1hc10h51c9a13qmby741b"
 (build-system gnu-build-system)
 (arguments
  `(#:test-target "test"
-- 
2.7.0

From 0b2d7df57366d27aa715ba4d824ef0b80b458823 Mon Sep 17 00:00:00 2001
From: Efraim Flashner 
Date: Wed, 9 Mar 2016 11:09:06 +0200
Subject: [PATCH 2/2] gnu: vim: Use 'modify-phases'.

* gnu/packages/vim.scm (vim)[arguments]: Use 'modify-phases' syntax.
---
 gnu/packages/vim.scm | 15 +++
 1 file changed, 7 insertions(+), 8 deletions(-)

diff --git a/gnu/packages/vim.scm b/gnu/packages/vim.scm
index 4834b69..959bccf 100644
--- a/gnu/packages/vim.scm
+++ b/gnu/packages/vim.scm
@@ -48,14 +48,13 @@
  `(#:test-target "test"
#:parallel-tests? #f
#:phases
-(alist-cons-after
- 'configure 'patch-config-files
- (lambda _
-   (substitute* "runtime/tools/mve.awk"
- (("/usr/bin/nawk") (which "gawk")))
-   (substitute* "src/testdir/Makefile"
- (("/bin/sh") (which "sh"
-  %standard-phases)))
+   (modify-phases %standard-phases
+ (add-after 'configure 'patch-config-files
+   (lambda _
+ (substitute* "runtime/tools/mve.awk"
+   (("/usr/bin/nawk") (which "gawk")))
+ (substitute* "src/testdir/Makefile"
+   (("/bin/sh") (which "sh"
 (inputs
  `(("gawk" ,gawk)
("inetutils" ,inetutils)
-- 
2.7.0



signature.asc
Description: PGP signature

Re: 01/01: doc: Typos and small stylistic changes.

[Alex Kost]

Andreas Enge (2016-03-05 18:27 +0300) wrote:

> commit 1068f26b797ed7c1475d93cab6eed53c9097c7f6
> Author: Andreas Enge 
> Date:   Sat Mar 5 16:26:55 2016 +0100
>
> doc: Typos and small stylistic changes.
>
> * guix.texi: Correct typos and make minor changes.

[...]
> @@ -5928,7 +5928,7 @@ system} command, specifically:
>  guix system disk-image --image-size=850MiB gnu/system/install.scm
>  @end example
>
> -@xref{Invoking guix system}, for more information.  See
> +@xref{Invoking guix system} and
>  @file{gnu/system/install.scm} in the source tree for more information
>  about the installation image.

I think this should be rephrased, because after this change, makeinfo
complains:

  ./doc/guix.texi:5937: warning: `.' or `,' must follow @xref

And in the generated guix.info there is a dot before "and".

--
Alex

Re: Staying on top of Qt security

[Ricardo Wurmus]

Andreas Enge  writes:

> On Sat, Mar 05, 2016 at 10:16:05PM +0100, Ricardo Wurmus wrote:
>> We could ask drobilla for a new suil release.  I don’t think we should
>> package the development version as it’s not clear if dependent
>> applications would work with the latest suil.
>
> Sounds good. Would you like to do it, since you are clearly the expert?

I just checked some packaging information for Suil.  Maybe we should
just split it into different packages:

The purpose of Suil is to abstract plugin UI toolkits away from host
code.  To achieve this, Suil performs its magic by dynamically
loading modules for each toolkit.  The main Suil library does NOT
depend on any toolkit libraries, and thus neither should your
package.  Please package the individual modules
(e.g. libsuil_gtk2_in_qt4.so) as separate packages, which themselves
depend on the involved toolkits.  These packages should also be
versioned as described above to support parallel installation.

Please do not make the main Suil package depend on any toolkit
package, this defeats the purpose of Suil and will severely irritate
those who for whatever reason do not want a particular toolkit
dependency.  The main Suil package may have a weak dependency
(e.g. "recommends") on the individual wrapper modules, and it's fine
if these are installed by default, but it must be possible to
install Suil without installing them if the user explicitly wishes
to do so.

[http://svn.drobilla.net/lad/trunk/suil/PACKAGING]

How about we do just that?  Maybe we’ll find that the qt4 backend is not
needed by any other package at all.

~~ Ricardo

Re: Yet another Hydra mirror: hydra-mirror.marusich.info

[Chris Marusich]

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

> Nice!  Are you using the nginx config that’s in guix-maintenance.git?

No, I'm not using that at the moment. In the future, if I set up any
nginx servers to accomplish the same task, I will definitely use it. I
would prefer to run my own servers, but for now this is something I can
do immediately to help the project, so I decided to do it.

CloudFront is a service, so you use its API (or the AWS Management
Console, which is a web UI for the API) to create a "distribution" and
configure it to use hydra.gnu.org as its "origin". A little extra work
is required to glue everything together. For example, I had to create a
CNAME pointing from hydra-mirror.marusich.info to
d2xj50ygrk34qq.cloudfront.net, which is the canonical name of my
distribution. Once it's configured, all requests sent to
hydra-mirror.marusich.info are serviced by a nearby point of presence in
the CloudFront content distribution network, and the results are cached.

I've noticed that Hydra does not include cache-related headers (e.g.,
Cache-Control). Perhaps for this reason, the nginx config you linked
seems to pick arbitrary caching settings. When using CloudFront, a
distribution can be configured to respect the Cache-Control headers sent
by the origin server. Does nginx provide similar functionality? Would it
make sense to have hydra.gnu.org return such headers?

For now, I've configured hydra-mirror.marusich.info to cache all
successful requests for 1 week, and to respect cache-related headers
from the hydra.gnu.org if it ever decides to send them. This seemed like
a reasonable configuration for data which is not expected to change.

Chris