Re: [Whonix-devel] GNU Guix Questions

[bancfc]

On 2017-03-06 17:15, ng0 wrote:

Hi bancfc,



Hi ng0, great to see you here :)


On 17-03-06 16:14:08, ban...@openmailbox.org wrote:
Hi Guix devs, I am a privacy distro dev and we are looking at using 
Guix in

our OS. I have a few questions:

* Is the Guix package archive available from a Tor hidden service? 
There are
many advantages of updating a system over Tor such as preventing a 
target

adversary from fingerprinting and targeting hosts that run vulnerable
packages and protecting systems in case the package manager has a 
security
bug. Debian and Tor now provide onion mirrors for their packages. Can 
you

please consider doing the same?


As far as I know this might be discussed currently at GNU
sysadministration level,
at least that's the last info I got when I suggested this last week to
RMS.
There is an onion mirror which is run by another community. It doesn't
mirror alpha.gnu.org yet (where guix binaries are located), but it 
plans

to do so. I need to get in touch with the community to ask wether they
would be okay with more bandwidth.
Do you have an estimation on how high your usage would be for the guix
download from the onion mirror?




The amount for bandwidth is approximately the size of GNUnet x 15K 
users. Later on we will expand the selection to include Tor Browser once 
you package it - if that pans out that would be a massive achievement. 
The Torproject have discussed packaging it for years but they couldn't 
work it out because of the breakneck speed of development and the 
cumbersome process of creating Debian packages. Meanwhile anonymity 
distros were forced to come up with a workaround safe downloader 
mechanism in absence of a package fecthable from a package manager. Its 
been a high maintenance effort over the years and a Guix package would 
finally solve this.


Another "wishlist" package would be GNU-libre kernel that includes the 
Grsecurity patchset so we can include that out of the box instead of 
requiring users to manually patch and tweak settings with every (weekly) 
new upstream release.


I realize I'm going offtopic but its really exciting to finally find a 
better way to package things.




* Does Guix defend against the variety of attacks described in the TUF
threat model document? (described in link below) How resilient is it 
against
key compromise? (TUF was designed from the ground up to provide a 
highly
resilient and secure update framework as a drop in replacement to 
crappy
standalone updaters - a problem that's become very serious for 
proprietary
OSes. The security research and implementation behind it are an 
excellent

rubric that one can apply to any updater/package manager.)

https://github.com/theupdateframework/tuf/blob/develop/SECURITY.md


* How does one setup a third part package archive? After looking at 
the

manual I believe its as simple as fetching source from one's git repo?

Thanks
___
You are receiving this e-mail because you subscribed Whonix-devel 
mailing list. To unsubscribe visit 
https://www.whonix.org/cgi-bin/mailman/listinfo/whonix-devel or mail 
"unsubscribe" to whonix-devel-unsubscr...@whonix.org.


Sie erhalten diese E-Mail, weil Sie die Whonix-devel Mailingliste 
aboniert haben. Zum abbestellen besuchen Sie 
https://www.whonix.org/cgi-bin/mailman/listinfo/whonix-devel oder 
mailen Sie "unsubscribe" an whonix-devel-unsubscr...@whonix.org.

Re: support for non-list search paths

[Troy Sankey]

Quoting Ludovic Courtès (2017-03-06 16:22:52)
> Hi,
> 
> Troy Sankey  skribis:
> 
> > My workaround involves using `guix package --search-paths=exact`, but
> > this cost me some time debugging which I'd like to save the next person.
> > I am not sure what the solution should be.  Maybe just a clarification
> > in documentation?  What about an argument for search-path-specification
> > to force the variable to always be "exact"?
> 
> This last option has been implemented in the ‘core-updates’ branch,
> which is meant to be merged Real Soon (hopefully within one or two
> weeks):
> 
>   https://bugs.gnu.org/25422

Wow! yay!

Troy
From faf99fec917115cdce11b48e5bb68159322c9eef Mon Sep 17 00:00:00 2001
From: Troy Sankey 
Date: Mon, 6 Mar 2017 19:31:02 -0500
Subject: [PATCH] gnu: git: force GIT_EXEC_PATH to be single-entry

* gnu/packages/version-control.scm (git)[native-search-paths](separator):
New field.
---
 gnu/packages/version-control.scm | 1 +
 1 file changed, 1 insertion(+)

diff --git a/gnu/packages/version-control.scm b/gnu/packages/version-control.scm
index 9cbd49220..d2ddfeef0 100644
--- a/gnu/packages/version-control.scm
+++ b/gnu/packages/version-control.scm
@@ -295,6 +295,7 @@ as well as the classic centralized workflow.")
(files '("etc/ssl/certs/ca-certificates.crt")))
   (search-path-specification
(variable "GIT_EXEC_PATH")
+   (separator #f) ;single entry
(files '("libexec/git-core")
 
(synopsis "Distributed version control system")
-- 
2.12.0



signature.asc
Description: signature

Re: bug#25463: guile-2.0.13 Check errors

[Ludovic Courtès]

Manolis Ragkousis  skribis:

> Hello Ludo, welcome back!
>
> On 03/06/2017 06:00 PM, Ludovic Courtès wrote:
>
>> Is it 100% reproducible if you run:
>> 
>>   ./check-guile 00-repl-server.test
>> 
>> from Guile’s build tree?
>> 
>> This test uses a Unix-domain socket, which on the Hurd means that
>> /servers/socket/3 (I think?) must have the right translator on it.
>> 
>> 00-socket.test also uses Unix-domain sockets.  Does it pass?
>> 
>> Looking more closely, it might be that one of the hunks of the patch
>> below solves the problem.  Could you try and report back?
>> 
>> (Looking at
>> , I
>> think ECONNRESET is more appropriate than ENOTCONN in the second case.)
>> 
>> HTH,
>> Ludo’.
>> 
>
> Since the last email I sent, I found out that I was getting ENOTCONN
> only after the second time I was running the test, and every time after
> that, unless I delete /tmp/repl-server.

Oh, interesting.

> The error you get the first time you run the test is
>
> FAIL: 00-repl-server.test: repl-server: simple expression - arguments:
> (expected-value "scheme@(repl-server)> $1 = 42\n" actual-value
> "scheme@(repl-server)> While reading expression:\nERROR: In procedure
> fport_fill_input: Resource temporarily
> unavailable\nscheme@(repl-server)> While reading expression:\nERROR: In
> procedure fport_fill_input: Resource temporarily
> unavailable\nscheme@(repl-server)> While reading expression:\nERROR: In
> procedure fport_fill_input: Resource temporarily
> unavailable\nscheme@(repl-server)> While reading expression:\nERROR: In
> procedure fport_fill_input: Resource temporarily
> unavailable\nscheme@(repl-server)> While reading expression:\nERROR: In
> procedure fport_fill_input: Resource temporarily unavailable\n$1 = 42\n")

Hmm!

> I am testing with "GUILE_LOAD_PATH=. ./guile-test

You mean ./check-guile, right?

> tests/00-initial-env.test tests/00-repl-server.test" and it's 100%
> reproducible if you delete /tmp/repl-server after each run.
> 00-socket.test passes each time successfully. Your patch doesn't solve
> the first error.

OK.

> Trying to debug the problem using rpctrace causes both tests to end with
> unresolved test cases. I am attaching the rpc-trace output.

[...]

> task192(pid5107)->mach_port_mod_refs (pn{ 46} 1 -1) = 0 
>   169<--197(pid5107)->io_write ("guile: ./pthread/pt-create.c:186: 
> __pthread_create_internal: Assertion `({ mach_" -1) = 0 225

This is the problem.  ↑

>   100<--196(pid5107)->dir_lookup ("servers/crash" 0 0) = 0 1 ""
> 207<--202(pid5107)
> task192(pid5107)->mach_port_mod_refs (pn{ 10} 0 1) = 0 
>   77<--147(pid5107)->dir_mkfile (18 384) = 0220<--210(pid5107)
>   207<--202(pid5107)->crash_dump_task ( task192(pid5107)
> 220<--210(pid5107) 4 0 0 2 13 0118<--281(pid5107)) ...238

It leads to a core dump…

> task133(pid5084)->mach_port_destroy (pn{ 49}) = 0 
> 238... = 0 
>   225<--265(pid-1)->msg_sig_post (20 1  task133(pid5084));
>   100<--250(pid5084)->dir_lookup ("tmp/repl-server" 0 0) ...238
> task133(pid5084)->mach_port_deallocate (pn{  1}) ...167
> 238... = 0 1 ""192<--221(pid5084)
> 167... = 0 
>   192<--221(pid5084)->ifsock_getsockaddr () = 0280<--220(pid5084)
> task133(pid5084)->mach_port_deallocate (pn{ 49}) = 0 
>   287<--266(pid5084)->socket_connect (   280<--220(pid5084)) = 0x403d 
> (Connection refused) 

… and subsequent connection attempts fail, hence “unresolved” test cases
I think.

Could you report the assertion failure to the Hurd folks?

Thanks for investigating!

Ludo’.

Re: [PATCH 7/8] vm: Fix full-boot? option.

[Ludovic Courtès]

David Craven  skribis:

> * gnu/system/vm.scm (virtualized-operating-system): Add full-boot?
>   option. Don't add a %store-mapping when full-boot? is passed. This leads
>   the grub-configuration-file procedure to look for the kernel and initrd in
>   / instead of /gnu/store.

Good catch.  I added a comment and committed, thanks!

Ludo’.

Re: Let’s freeze and build ‘core-updates’!

[Leo Famulari]

On Mon, Mar 06, 2017 at 04:39:56PM +0100, Ludovic Courtès wrote:
> It’s been 3 days since their message and it hasn’t happened yet, so
> perhaps we should simply run autoreconf.
> 
> Thoughts?

Okay.

> BTW, xorg-server is a build-time dependency of gtk+@3 (for test
> purposes), which is the main reason why it has so many dependents.
> Perhaps it would be fine to keep using 1.9.12 for GTK+.  That way, we
> can update xorg-server without rebuilding the world.

Good idea. Should xorg-server-for-gtk inherit from xorg-server or be a
completely separate package? Or something else?

Re: [PATCH 0/8] WIP: Better support for non-grub bootloaders.

[Ludovic Courtès]

Hi David,

Please let me know if you don’t want to be bothered about this.  Problem
is there’s exciting stuff in this patch series and I’d probably have a
few questions for you if you want.

David Craven  skribis:

> These patches make changes to the bootloader API and will break 
> operating-system's
> and some scripts (--no-grub is renamed to --no-bootloader).
>
> I would like some feedback on the API and also ideas on how to handle API 
> changes
> with minimal discomfort to our users.
>
> The most interesting commit is 8a01985d7a936809102b10d494dc2286b3f8c6f2 which 
> defines
> a  record. extlinux-configuration, 
> grub-configuration and
> syslinux-configuration are designed as transformation passes on a 
> bootloader-configuration
> record. The idea is that someone that wants to add support for a new 
> bootloader can
> use
>
> (bootloader (bootloader-configuration
>  ...))
>
> and users that want to use a supported bootloader can configure it like this
>
> (bootloader (grub-configuration
>  (bootloader-configuration
>   (device "/dev/sda1"

Perhaps this could be:

  (bootloader-configuration
(type grub-bootloader)
(device "/dev/sda1"))

That way, people would always write ‘bootloader-configuration’
regardless of the bootloader being used, which sounds simpler.

We could have this compatibility macro:

  (define-syntax-rule (grub-configuration fields ...)
(bootloader-configuration
  (type grub-bootloader)
  fields ...))

> another important API change is that an operating-system does not need to set
> the bootloader when it is only intended to run through guix system vm or on
> an embedded system that has an extlinux compatible bootloader in ROM.
>
> Things that don't work yet:
> * system tests are broken due to API changes
> * grub-efi needs an installation procedure and the vm code needs
>   support for alternative firmware like ovmf, gpt partition table
>   and EFI boot partition.
> * The syslinux and grub bootloader configurations still require
>   guix/scripts/system.scm to handle the new API on init and reconfigure
>   and requires extensive testing on real hardware.
> * No automated system tests yet.

OK.

I’ll look more closely at the rest.  I’m glad Danny already applied the
non-controversial patches!

Thanks,
Ludo’.

Re: 'guix build --target=' handling questions

[Sergei Trofimovich]

On Mon, 06 Mar 2017 17:04:18 +0100
l...@gnu.org (Ludovic Courtès) wrote:

> Sergei Trofimovich  skribis:
> 
> >> Question time:
> >> 
> >> - Is there a way to run 'guix environment --target=' in the same way as 
> >> 'guix build --target='
> >>   sets it up? I'd like to see how both compilers are supposed to be 
> >> present in there.
> >>
> >> - Why default g++ in PATH is the host g++ and not target g++?
> >>   Target seems to make most sense if no explicit compiler is specified.
> >> 
> >> - How to actually set CXX to point to target g++?
> >>   It looks like implicitly there already both host (through native-inputs)
> >>   and target (through build-inputs) compilers available.
> >>   I would expect something like
> >>   #:make-flags (list (string-append "CXX=" <.?.>)) 
> >>   What should be in place of that "<.?.>" to refer to target g++?  
> >
> > I think I've found a workaround at least for my third question.
> >
> > Both host and target compilers are available as g++ and ${target}-g++.
> >
> > Thus the following workaround seems to work:
> >
> > diff --git a/gnu/packages/regex.scm b/gnu/packages/regex.scm
> > index f04cba706..a8fa689ab 100644
> > --- a/gnu/packages/regex.scm
> > +++ b/gnu/packages/regex.scm
> > @@ -20,11 +20,13 @@
> >
> >  (define-module (gnu packages regex)
> >#:use-module ((guix licenses) #:prefix license:)
> >#:use-module (guix packages)
> >#:use-module (guix download)
> > -  #:use-module (guix build-system gnu))
> > +  #:use-module (guix build-system gnu)
> > +  #:use-module (guix utils) ; for %current-target-system
> > +  )
> >
> >  (define-public re2
> > (package
> >   (name "re2")
> >   (version "2017-01-01")
> > @@ -40,11 +42,15 @@
> >   "0yij1ajh66h3pj3kfz7y0ldrsww8rlpjzaavyr5lchl98as1jq74"
> >   (build-system gnu-build-system)
> >   (arguments
> >`(#:test-target "test"
> >  ;; There is no configure step, but the Makefile respects a prefix.
> > -#:make-flags (list (string-append "prefix=" %output))
> > +#:make-flags (list (string-append "prefix=" %output)
> > +   (string-append "CXX=" ,(string-append (if 
> > (%current-target-system)
> > + 
> > (string-append (%current-target-system) "-")
> > + "")
> > + "g++")))  
> 
> As John wrote, this is the right fix for this package.

Aha!

> If you can send it with ‘git send-email’ (see
> ),

Sent as:
http://debbugs.gnu.org/cgi/bugreport.cgi?bug=26004

About the 'guix environment --target=' / 'guix build --target=' part or 
question:

Would it make sense to have '--target=' support in 'guix environment' tool or 
is it
too tricky?

Thanks!

-- 

  Sergei


pgphhaqvbAs20.pgp
Description: Цифровая подпись OpenPGP

Dealing with CVEs that apply to unspecified package versions

[Ludovic Courtès]

Hi!

A couple of weeks ago you mentioned that CVE-2016-10165 (for lcms) is
not reported by ‘guix lint -c cve’.  This is due to the fact that the
CVE does not specify the lcms version number it applies to, and thus
(guix cve) ignores it.

The attached patch fixes (guix cve) to honor CVEs with an unspecified
version number.

Unfortunately, there’s no way to know whether such CVEs are actually
fixed at a specific package version or not, and they’re not uncommon.
Consequently, ‘guix lint -c cve’ would now report old CVEs that possibly
no longer apply to our package versions.

In the patch, I added the ability to specify a ‘patched-vulnerabilities’
property to work around that (with Coreutils as an example).  The
downside is that we’d have to maintain these lists by ourselves, which
is not great, but might still be better than the status quo.

Thoughts?

Ludo’.

diff --git a/gnu/packages/base.scm b/gnu/packages/base.scm
index c75e03828..c84571c21 100644
--- a/gnu/packages/base.scm
+++ b/gnu/packages/base.scm
@@ -1,5 +1,5 @@
 ;;; GNU Guix --- Functional package management for GNU
-;;; Copyright © 2012, 2013, 2014, 2015, 2016 Ludovic Courtès 
+;;; Copyright © 2012, 2013, 2014, 2015, 2016, 2017 Ludovic Courtès 
 ;;; Copyright © 2014 Andreas Enge 
 ;;; Copyright © 2012 Nikita Karetnikov 
 ;;; Copyright © 2014, 2015, 2016 Mark H Weaver 
@@ -320,6 +320,7 @@ used to apply commands with arbitrarily long arguments.")
   (("#!/bin/sh")
(format #f "#!~a/bin/sh" bash)
 %standard-phases)))
+   (properties '((patched-vulnerabilities "CVE-2016-2781"))) ;really?
(synopsis "Core GNU utilities (file, text, shell)")
(description
 "GNU Coreutils includes all of the basic command-line tools that are
diff --git a/guix/cve.scm b/guix/cve.scm
index 088e39837..771b82d05 100644
--- a/guix/cve.scm
+++ b/guix/cve.scm
@@ -1,5 +1,5 @@
 ;;; GNU Guix --- Functional package management for GNU
-;;; Copyright © 2015, 2016 Ludovic Courtès 
+;;; Copyright © 2015, 2016, 2017 Ludovic Courtès 
 ;;;
 ;;; This file is part of GNU Guix.
 ;;;
@@ -88,9 +88,17 @@
 (close-port port)
 
 (define %cpe-package-rx
+  ;; The CPE syntax as defined in the CPE 2.2 specs from
+  ;; .
+  ;;
   ;; For applications: "cpe:/a:VENDOR:PACKAGE:VERSION", or sometimes
-  ;; "cpe/a:VENDOR:PACKAGE:VERSION:PATCH-LEVEL".
-  (make-regexp "^cpe:/a:([^:]+):([^:]+):([^:]+)((:.+)?)"))
+  ;; "cpe/a:VENDOR:PACKAGE:VERSION:PATCH-LEVEL"; in some cases, simply
+  ;; "cpe:/a:VENDOR:PACKAGE", meaning that the affected versions are not
+  ;; specified.
+  (make-regexp "^c[pP][eE]:/[aA]:([^:]+):(.*)"))
+
+(define %not-colon
+  (char-set-complement (char-set #\:)))
 
 (define (cpe->package-name cpe)
   "Converts the Common Platform Enumeration (CPE) string CPE to a package
@@ -99,15 +107,17 @@ version string.  Return #f and #f if CPE does not look like an application CPE
 string."
   (cond ((regexp-exec %cpe-package-rx (string-trim-both cpe))
  =>
- (lambda (matches)
-   (values (match:substring matches 2)
-   (string-append (match:substring matches 3)
-  (match (match:substring matches 4)
-("" "")
-(patch-level
- ;; Drop the colon from things like
- ;; "cpe:/a:openbsd:openssh:6.8:p1".
- (string-drop patch-level 1)))
+ (lambda (rx-match)
+   (match (string-tokenize (match:substring rx-match 2)
+   %not-colon)
+ ((package)
+  ;; No version component, as in
+  ;; "cpe:/a:littlecms:little_cms_color_engine".
+  (values package 'any))
+ ((package version _ ...)
+  ;; Ignore the "patch level" part if there is one, as in
+  ;; "cpe:/a:openbsd:openssh:6.8:p1".
+  (values package version)
 (else
  (values #f #f
 
@@ -119,6 +129,11 @@ applications listed in PRODUCTS, with names converted to package names:
 '(\"cpe:/a:gnu:libtasn1:4.7\" \"cpe:/a:gnu:libtasn1:4.6\" \"cpe:/a:gnu:cpio:2.11\"))
   => ((\"libtasn1\" \"4.7\" \"4.6\") (\"cpio\" \"2.11\"))
 "
+  (define (version-cons v lst)
+(cond ((eq? v 'any) 'any)
+  ((eq? lst 'any) 'any)
+  (else (cons v lst
+
   (fold (lambda (product result)
   (let-values (((name version) (cpe->package-name product)))
 (if name
@@ -126,10 +141,10 @@ applications listed in PRODUCTS, with names converted to package names:
   (((previous . versions) . tail)
;; Attempt to coalesce NAME and PREVIOUS.
 

Re: [PATCH] gnu: fontconfig: Fix for PATH_MAX.

[Ludovic Courtès]

Hi,

Manolis Ragkousis  skribis:

> I added a line in your commit message saying in which file you apply the
> patch and also removed all the one space indentation changes, with the
> purpose of making the patch more clear.
>
> I pushed it in core-updates.

Right in time, thanks.  :-)

BTW, I’d encourage you to team up with the Debian folks so that all the
PATH_MAX patches end up upstream.  Otherwise they’ll end up occupying
half of our repo.  ;-)

Ludo’.

Re: support for non-list search paths

[Ludovic Courtès]

Hi,

Troy Sankey  skribis:

> My workaround involves using `guix package --search-paths=exact`, but
> this cost me some time debugging which I'd like to save the next person.
> I am not sure what the solution should be.  Maybe just a clarification
> in documentation?  What about an argument for search-path-specification
> to force the variable to always be "exact"?

This last option has been implemented in the ‘core-updates’ branch,
which is meant to be merged Real Soon (hopefully within one or two
weeks):

  https://bugs.gnu.org/25422

Ludo’.

Re: [PATCH] gnu: icecat: Add skia support.

[Leo Famulari]

On Mon, Mar 06, 2017 at 07:09:14PM +0100, Julien Lepiller wrote:
> Hi,
> 
> Here are three patches to add skia, a graphics library and add support
> for it in icecat. It is not made the default graphics engine, so to
> enable it, you need to go in about:config and change
> `gfx.content.azure.backends' and `gfx.canvas.azure.backends' to `skia'
> instead of cairo. Doing this seems to solve the random crashes.

These patches are valuable for unbundling.

It should be noted that our IceCat package already includes skia, and
users have to take the same steps to enable skia. Let's see what the
difference is between the skia provided by IceCat and this skia, to make
sure we don't introduce new bugs or compatibility issues.


signature.asc
Description: PGP signature

Re: Let’s freeze and build ‘core-updates’!

[Leo Famulari]

On Mon, Mar 06, 2017 at 07:54:06PM +0100, Marius Bakke wrote:
> Another option is to keep version 2.6.2 around, which is better than a
> specialized "flex-for-grub". If the previous version works for both grub
> and wireshark, I prefer this alternative.

The choices are a bit overwhelming; there are problems with 2.6.2 as
well:

https://github.com/westes/flex/issues/134 (kservice broken)
https://github.com/westes/flex/issues/113 (doxygen broken)
https://github.com/westes/flex/issues/98 (flex tests fail)

2.6.4 is "due" today, although I'm not sure what changes could be
included:

https://github.com/westes/flex/milestones

We should not go back to anything before 2.6.1, due to CVE-2016-6354:

https://security-tracker.debian.org/tracker/CVE-2016-6354


signature.asc
Description: PGP signature

Re: Can (grub-configuration (device $DEV)) accept UUIDs?

[dian_cecht]

On Mon, 06 Mar 2017 17:19:21 +0100
l...@gnu.org (Ludovic Courtès) wrote:
> Unfortunately it can’t, because there are no UUIDs (that I know of) to
> identify drives.
> 
> However, as the manual vaguely suggests (too vaguely I admit), you can
> use a GRUB device identifier such as “(hd0)”.  This is stable across
> reboot, AIUI.  I’ve never tried it but if you can confirm that it
> works this way, we could/should update the documentation to propose
> that.

How about a (maybe better) option; if (grub-configuration ...) is
passed something like (uuid "$UUID"), instead of simply passing this
directly to grub-install (or whatever is used), guix /could/ take the
UUID, check what drive the UUID points to, then pass the related
arguement to GRUB. It would be a reasonably fix for what I'd assume is
a bug/missing feature in GRUB.

In my quick searching, apparently blkid can accept '-t', which lets you
search for a drive by label, uuid, or (the manpage doesn't state this)
uuid_sub.

I don't know Guile nor Guix so I can't submit a patch, but what I
think /should/ work is, if grub-configuration is called with a UUID,
the UUID is passed to blkid[0] (probably checking both UUID[1] and
UUID_SUB[2]), and the output checked for a valid drive (in the form,
I'd expect, of /dev/sda or similar), cleaned up, then that is passed
to grub-configuration.

Someone with better knowledge of Guile, Guix, and Linux can probably
expand on this (or figure out how it might be broken), but it should be
a start for adding this feature.

[0]. According to blkid, it's simply an interface to libblkid, so
maybe a FFI call (or several) would be better here than just calling the
CLI program?
[1]. RAID members will share a UUID, so simply relying on that isn't
practical.
[2]. UUID_SUB is the actual UUID of the underlying drive (apparently),
and should probably be used when someone it trying to install GRUB,
otherwise you could end up with multiple RAID members as output, and
then I can only see things becoming hard[3].
[3]. Like trying to decide which drive the sysadmin meant, or if they
meant all of them, or if they passed the wrong UUID(_SUB) in the system
config...

Re: documentation/behavior unclear of (tor-hidden-service)

[ng0]

On 17-03-06 13:47:12, Leo Famulari wrote:
> On Mon, Mar 06, 2017 at 06:00:30PM +, ng0 wrote:
> > from my experience they are not needed for a relay. Okay, they would be
> > useful to increase security and to see how how Chinese government
> > officials and their automated services want to get into your server, but
> > it's not really necessary for the relay.
> 
> Slight nitpick: In my experience with iptables, it's not just Chinese
> officials that want to break in to my servers, but rather a dazzling
> multitude of people from all over the world ;)
> 
My experience with OpenNIC and tor on the server side was that it's
mostly government IPs running lazy standard methods trying to get in
where they won't get in anyway.
Just don't use port 22, rate-limit connections (with OpenNIC this worked
a bit) and the IPs which traced back directly to those red zones in
chinese cities marked as "military/government zones" went away :).

But yeah, with tor they were in company of russia, USA, and other
nations trying to do the same ;D

Re: Let’s freeze and build ‘core-updates’!

[Leo Famulari]

On Mon, Mar 06, 2017 at 07:49:42PM +0100, Marius Bakke wrote:
> Leo Famulari  writes:
> > Let's also decide what to do about GRUB. I updated it originally because
> > something (I forgot what) failed to build without a newer GRUB.
> 
> I think you meant "flex" here.

Yup! :p

> According to https://github.com/westes/flex/issues/162 , this commit
> should fix the grub issue:
> 
> https://github.com/westes/flex/commit/f5d87f1a26f4a5c3402497008ae10e9a1345d327

I was wary of cherry-picking this due to the flex maintainer's comment:

"f5d87f1

should bwhat you want, but there are a couple others that are
related/relevant."

https://github.com/westes/flex/issues/162#issuecomment-274608469

But we can try it out on core-updates and see how it goes. Will you try
making the patch?


signature.asc
Description: PGP signature

Re: Let’s freeze and build ‘core-updates’!

[Marius Bakke]

Marius Bakke  writes:

> Leo Famulari  writes:
>
>> On Mon, Mar 06, 2017 at 10:19:34AM +0100, Ludovic Courtès wrote:
>>> Hello Guix!
>>> 
>>> Looks like there’s been a disk space issue a few days ago that’s now
>>> solved, so I’ve restarted an evaluation of the “core” subset.
>>> 
>>> Is there any blocker left or should we move forward after that?
>>
>> Let's also decide what to do about GRUB. I updated it originally because
>> something (I forgot what) failed to build without a newer GRUB.
>
> I think you meant "flex" here.
>
> According to https://github.com/westes/flex/issues/162 , this commit
> should fix the grub issue:
>
> https://github.com/westes/flex/commit/f5d87f1a26f4a5c3402497008ae10e9a1345d327
>
> Seeing as wireshark is apparently also affected according to the
> upstream bug, I would suggest applying this fix on our flex package.

Another option is to keep version 2.6.2 around, which is better than a
specialized "flex-for-grub". If the previous version works for both grub
and wireshark, I prefer this alternative.


signature.asc
Description: PGP signature

Re: Let’s freeze and build ‘core-updates’!

[Marius Bakke]

Leo Famulari  writes:

> On Mon, Mar 06, 2017 at 10:19:34AM +0100, Ludovic Courtès wrote:
>> Hello Guix!
>> 
>> Looks like there’s been a disk space issue a few days ago that’s now
>> solved, so I’ve restarted an evaluation of the “core” subset.
>> 
>> Is there any blocker left or should we move forward after that?
>
> Let's also decide what to do about GRUB. I updated it originally because
> something (I forgot what) failed to build without a newer GRUB.

I think you meant "flex" here.

According to https://github.com/westes/flex/issues/162 , this commit
should fix the grub issue:

https://github.com/westes/flex/commit/f5d87f1a26f4a5c3402497008ae10e9a1345d327

Seeing as wireshark is apparently also affected according to the
upstream bug, I would suggest applying this fix on our flex package.

Alternatively package a "flex-for-grub" variant, but that's not very
re-usable.


signature.asc
Description: PGP signature

Re: documentation/behavior unclear of (tor-hidden-service)

[Leo Famulari]

On Mon, Mar 06, 2017 at 06:00:30PM +, ng0 wrote:
> from my experience they are not needed for a relay. Okay, they would be
> useful to increase security and to see how how Chinese government
> officials and their automated services want to get into your server, but
> it's not really necessary for the relay.

Slight nitpick: In my experience with iptables, it's not just Chinese
officials that want to break in to my servers, but rather a dazzling
multitude of people from all over the world ;)

Re: Let’s freeze and build ‘core-updates’!

[Leo Famulari]

On Mon, Mar 06, 2017 at 10:19:34AM +0100, Ludovic Courtès wrote:
> Hello Guix!
> 
> Looks like there’s been a disk space issue a few days ago that’s now
> solved, so I’ve restarted an evaluation of the “core” subset.
> 
> Is there any blocker left or should we move forward after that?

Let's also decide what to do about GRUB. I updated it originally because
something (I forgot what) failed to build without a newer GRUB.

Re: [PATCH 1/1] gnu: linux-libre@4.1, linux-libre@4.4, linux-libre@4.9: Fix CVE-2017-6074.

[Leo Famulari]

On Mon, Mar 06, 2017 at 11:00:15AM +0100, Ludovic Courtès wrote:
> Leo Famulari  skribis:
> 
> > * gnu/packages/linux.scm (linux-libre-4.1, linux-libre-4.4,
> > linux-libre-4.9): Add patch for CVE-2017-6074.
> 
> If you haven’t done already, please push!  Especially since this
> vulnerability is ranked as “high”.

Pushed as 8923441951133c33ab0ef5ae1031559eba3268fd on February 22.


signature.asc
Description: PGP signature

[PATCH] gnu: icecat: Add skia support.

[Julien Lepiller]

Hi,

Here are three patches to add skia, a graphics library and add support
for it in icecat. It is not made the default graphics engine, so to
enable it, you need to go in about:config and change
`gfx.content.azure.backends' and `gfx.canvas.azure.backends' to `skia'
instead of cairo. Doing this seems to solve the random crashes.From a0dab7d185393d3698c7305cd39429e360ca1a37 Mon Sep 17 00:00:00 2001
From: Julien Lepiller 
Date: Sun, 5 Mar 2017 09:01:58 +0100
Subject: [PATCH 1/3] gnu: Add google-gn.

* gnu/packages/google.scm: New file.
* gnu/packages/patches/google-gn-remove-third-party.patch: New file.
* gnu/local.mk (GNU_SYSTEM_MODULES, dist_patch_DATA): Add them.
---
 gnu/local.mk   |  2 +
 gnu/packages/google.scm| 83 ++
 .../patches/google-gn-remove-third-party.patch | 76 
 3 files changed, 161 insertions(+)
 create mode 100644 gnu/packages/google.scm
 create mode 100644 gnu/packages/patches/google-gn-remove-third-party.patch

diff --git a/gnu/local.mk b/gnu/local.mk
index c88892df5..3e5e5f804 100644
--- a/gnu/local.mk
+++ b/gnu/local.mk
@@ -165,6 +165,7 @@ GNU_SYSTEM_MODULES =\
   %D%/packages/gnu-pw-mgr.scm			\
   %D%/packages/gobby.scm			\
   %D%/packages/golang.scm			\
+  %D%/packages/google.scm			\
   %D%/packages/gperf.scm			\
   %D%/packages/gprolog.scm			\
   %D%/packages/gps.scm\
@@ -599,6 +600,7 @@ dist_patch_DATA =		\
   %D%/packages/patches/gobject-introspection-absolute-shlib-path.patch \
   %D%/packages/patches/gobject-introspection-cc.patch		\
   %D%/packages/patches/gobject-introspection-girepository.patch	\
+  %D%/packages/patches/google-gn-remove-third-party.patch \
   %D%/packages/patches/grep-timing-sensitive-test.patch		\
   %D%/packages/patches/grub-CVE-2015-8370.patch			\
   %D%/packages/patches/grub-gets-undeclared.patch		\
diff --git a/gnu/packages/google.scm b/gnu/packages/google.scm
new file mode 100644
index 0..6bc75d000
--- /dev/null
+++ b/gnu/packages/google.scm
@@ -0,0 +1,83 @@
+;;; GNU Guix --- Functional package management for GNU
+;;; Copyright © 2017 Julien Lepiller 
+;;;
+;;; This file is part of GNU Guix.
+;;;
+;;; GNU Guix is free software; you can redistribute it and/or modify it
+;;; under the terms of the GNU General Public License as published by
+;;; the Free Software Foundation; either version 3 of the License, or (at
+;;; your option) any later version.
+;;;
+;;; GNU Guix is distributed in the hope that it will be useful, but
+;;; WITHOUT ANY WARRANTY; without even the implied warranty of
+;;; MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+;;; GNU General Public License for more details.
+;;;
+;;; You should have received a copy of the GNU General Public License
+;;; along with GNU Guix.  If not, see .
+
+(define-module (gnu packages google)
+  #:use-module ((guix licenses) #:prefix license:)
+  #:use-module (gnu packages)
+  #:use-module (gnu packages gnuzilla)
+  #:use-module (gnu packages icu4c)
+  #:use-module (gnu packages libevent)
+  #:use-module (gnu packages python)
+  #:use-module (gnu packages ninja)
+  #:use-module (guix packages)
+  #:use-module (guix download)
+  #:use-module (guix git-download)
+  #:use-module (guix utils)
+  #:use-module (guix build-system gnu)
+  #:use-module (srfi srfi-1))
+
+(define-public google-gn
+  (package
+(name "google-gn")
+(version "56.0.2924.87")
+(source
+  (origin
+(method url-fetch)
+(uri (string-append "https://commondatastorage.googleapis.com/;
+"chromium-browser-official/chromium-" version ".tar.xz"))
+(sha256
+ (base32
+  "1q2kg85pd6lv036w7lsss5mhiiva9rx4f0410sbn9bnazhghib4s"))
+(patches (search-patches "google-gn-remove-third-party.patch"))
+(modules '((guix build utils)))
+(snippet
+ '(begin
+   (delete-file-recursively "base/third_party/libevent")
+(build-system gnu-build-system)
+(arguments
+ `(#:tests? #f
+   #:phases
+   (modify-phases %standard-phases
+ (delete 'configure)
+ (add-before 'build 'fix-include
+   (lambda* (#:key inputs #:allow-other-keys)
+ (let* ((libevent (assoc-ref inputs "libevent"))
+(event-h (string-append libevent "/include/event.h")))
+   (substitute* "base/message_loop/message_pump_libevent.cc"
+ (("base/third_party/libevent/event.h") event-h)
+ (replace 'build
+   (lambda* (#:key outputs #:allow-other-keys)
+ (chdir "tools/gn")
+ (setenv "CC" (which "gcc"))
+ (zero? (system* "python" "bootstrap/bootstrap.py" "-s"
+ (replace 'install
+   (lambda* (#:key outputs #:allow-other-keys)
+ (let ((bin (string-append (assoc-ref outputs "out") "/bin")))
+

Re: documentation/behavior unclear of (tor-hidden-service)

[ng0]

On 17-03-06 08:19:00, dian_ce...@zoho.com wrote:
> On Mon, 6 Mar 2017 12:08:20 +
> ng0  wrote:> 
> > Maybe someone else can try and implement this, I only know what'S
> > needed for running the relay but can't do it at the moment ;)
> 
> Just for reference sake:
> https://www.torproject.org/docs/tor-doc-relay.html.en
> 
> What is the policy on creating/modifying firewalls? Would any relay
> service be allowed to automatically reconfigure the firewall to allow
> a relay to run? Does the sysadmin have to configure it theirself
> (English really needs gender-neutral pronouns.)? Does anything else in

themselves, there are gender neutral pronouns in english.

> GuixSD modify the firewall at this point?

No, there are no services for iptables or nftables at this point. And
from my experience they are not needed for a relay. Okay, they would be
useful to increase security and to see how how Chinese government
officials and their automated services want to get into your server, but
it's not really necessary for the relay.
The relays are just some definitions in the torrc, and that's it.

I would only ask people who currently or previously ran a tor relay,
maybe even with Guix/GuixSD, to work on this. You can't break anything,
but to test it would be good. Which is something I can't do currently.

> These all feel like rather important questions to me that need
> answering before anyone does this.
> 
> 

Re: torbrowser

[ng0]

On 17-03-06 08:06:52, dian_ce...@zoho.com wrote:
> On Mon, 6 Mar 2017 15:14:59 +
> ng0  wrote:
> > My idea is now to just reconstruct what torproject does, from the git
> > checkout of torbrowser and eventually later fix Guix specific
> > issues and fine tuning (freedom issues etc etc).
> 
> Would it be possible to grab the patches Torbrowser uses against
> Firefox and simply try to apply them to IceCat? I don't know exactly
> what version of FF Icecat and Torbrowser build off of, but if that
> could work it might make life a bit easier.
> 
> Alternativly, maybe applying the icecat patches to Torbrowser might
> work, too.
> 
> 

Not really. Icecat is just too old, and the firefox version torbrowser
is based on is not compatible with the one icecat uses. I would not want
the extra work to backport patches.

So far, I haven't investigated all possible ways, it seems too much work
to cherry-pick what torbrowser does to firefox. as they seem to maintain
all in the repository it could work out to just build from there. Their
release workflow (not automated but well documented) includes pulling in
from firefox, so there has to be firefox code in the repository.
The time and effort to base this on icecat is not worth it... unless
someone wants to start an icecat-torbrowser which *closely* tracks
torbrowser and does not become so unresponsive to bugs/issues like
icecat currently is.
And in both cases, the browser I assemble, and in the not-existing case
of a blend of torbrowser,I want to compare against upstream releases to
see how much we would differ and how much it'll affect fingerprinting
etc.
This difference will go into the description, as it can't be described
as a 1:1 port of torbrowser.

Re: Can (grub-configuration (device $DEV)) accept UUIDs?

[Ludovic Courtès]

Hi,

 skribis:

> I am in the process of trying to get GuixSD installed on my desktop and
> I've run into a minor issue. The documentation doesn't mention any
> support for UUIDs for grub-configuration (I'm going by the webpage with
> the install instead of the info files on the LiveUSB). Anyways, since
> the boot drive is very likely to change between install and the first
> LiveUSBless install, I'd rather use UUIDs. Can grub-configuration
> support this?

Unfortunately it can’t, because there are no UUIDs (that I know of) to
identify drives.

However, as the manual vaguely suggests (too vaguely I admit), you can
use a GRUB device identifier such as “(hd0)”.  This is stable across
reboot, AIUI.  I’ve never tried it but if you can confirm that it works
this way, we could/should update the documentation to propose that.

Thanks,
Ludo’.

Re: documentation/behavior unclear of (tor-hidden-service)

[dian_cecht]

On Mon, 6 Mar 2017 12:08:20 +
ng0  wrote:> 
> Maybe someone else can try and implement this, I only know what'S
> needed for running the relay but can't do it at the moment ;)

Just for reference sake:
https://www.torproject.org/docs/tor-doc-relay.html.en

What is the policy on creating/modifying firewalls? Would any relay
service be allowed to automatically reconfigure the firewall to allow
a relay to run? Does the sysadmin have to configure it theirself
(English really needs gender-neutral pronouns.)? Does anything else in
GuixSD modify the firewall at this point?

These all feel like rather important questions to me that need
answering before anyone does this.

Re: torbrowser

[ng0]

On 17-03-06 16:47:26, Ludovic Courtès wrote:
> ng0  skribis:
> 

> > Cloning takes a rather long time, this is where Andy's shallow-clone
> > would be useful, which is where I ran into issue and delayed re-working
> > this for now. If someone is interested I can post the patch which
> > applied on master recently.
> 
> If you’ve made changes to what Andy posted back then, or if it doesn’t
> work as you want, please post and make it clear what’s left to address.
> 
> Thanks,
> Ludo’.

Too little experience with debugging another persons style of writing
Guile. There are issues I can't figure out with only little time
spending on the code and the changes in the last 2 years in the file. I
would have to ask Andy what this and that was meant to express or
achieve, etc.
I will send in the patch, hoping that it still applies after the latest
changes.
I only changed parts of the code so that it's similar to what the
original patch (which no longer applies after 2 years) changed.
Debugging some things here and there and personal matters take up too
much time, so it's not effective if I work on this.
Patch will be send either tonight or tomorrow afternoon.

Thanks!

Re: gnu-patches back log

[Ludovic Courtès]

Hi Pjotr!

Pjotr Prins  skribis:

> Now we have debbugs we can see there is a building back-log:
>
>   
> https://debbugs.gnu.org/cgi/pkgreport.cgi?package=guix-patches;max-bugs=100;base-order=1;bug-rev=1
>
> A patch like this one
>
>   https://debbugs.gnu.org/cgi/bugreport.cgi?bug=25725
>
> has been two weeks without comment. I think we should not leave patches 
> without
> feedback longer than one week - even 3 days, to be honest. It is the surest 
> way
> to kill enthusiasm.

I’ll echo what others wrote: we don’t want to put more pressure on those
who do that review work.  The last thing I’d want is someone burning out
because of that; it’s already hard enough, believe me.

However, we should try hard to balance the review workload more evenly
among the 30 committers.  I’m not sure how to incentivize that, though;
some projects add Reviewed-by tags and then publish stats; would that
help?  A reviewer’s hall of a fame?  :-)

And of course, we should have more committers.

> Would it be an idea to send out weekly E-mails with patches that had
> no attention to a select list of reviewers? Or maybe to the ML as a
> whole? Basically it would read:

Personally I would not use that, but if others want it, we should
set it up!

Thanks,
Ludo’.

support for non-list search paths

[Troy Sankey]

The file "~/.guix-profile/etc/profile" treats all search paths as
colon-separated lists.  Some variables are not supposed to be lists, but
treating them as such could confuse programs which read them.
GIT_EXEC_PATH is one that has caused me trouble, so I'll be using it as
an example below.

The relevant line from "~/.guix-profile/etc/profile":

% grep GIT_EXEC_PATH ~/.guix-profile/etc/profile
export 
GIT_EXEC_PATH="${GUIX_PROFILE:-/gnu/store/9wwv7rl8n6ydcpa0h22nd38amwssfrbh-profile}/libexec/git-core${GIT_EXEC_PATH:+:}$GIT_EXEC_PATH"

Here's what my GIT_EXEC_PATH looks like from a terminal emulator:

% echo $GIT_EXEC_PATH
/home/sankey/.guix-profile/libexec/git-core:/home/sankey/.guix-profile/libexec/git-core

Here's the error from git:

% git rebase
/home/sankey/.guix-profile/libexec/git-core/git-sh-setup: line 46: 
/home/sankey/.guix-profile/libexec/git-core:/home/sankey/.guix-profile/libexec/git-core/git-sh-i18n:
 No such file or directory

Since my shell rcfile is sourced twice, GIT_EXEC_PATH becomes a
colon-separated list.  Double-sourcing the shell rcfile may not be the
only way to surface this issue.  If my rcfile simply set GIT_EXEC_PATH
before sourcing "~/.guix-profile/etc/profile", then I would still end up
with a corrupt GIT_EXEC_PATH.

My workaround involves using `guix package --search-paths=exact`, but
this cost me some time debugging which I'd like to save the next person.
I am not sure what the solution should be.  Maybe just a clarification
in documentation?  What about an argument for search-path-specification
to force the variable to always be "exact"?

Troy


signature.asc
Description: signature

Re: torbrowser

[dian_cecht]

On Mon, 6 Mar 2017 15:14:59 +
ng0  wrote:
> My idea is now to just reconstruct what torproject does, from the git
> checkout of torbrowser and eventually later fix Guix specific
> issues and fine tuning (freedom issues etc etc).

Would it be possible to grab the patches Torbrowser uses against
Firefox and simply try to apply them to IceCat? I don't know exactly
what version of FF Icecat and Torbrowser build off of, but if that
could work it might make life a bit easier.

Alternativly, maybe applying the icecat patches to Torbrowser might
work, too.

Re: [Whonix-devel] GNU Guix Questions

[ng0]

Hi bancfc,

On 17-03-06 16:14:08, ban...@openmailbox.org wrote:
> Hi Guix devs, I am a privacy distro dev and we are looking at using Guix in
> our OS. I have a few questions:
> 
> * Is the Guix package archive available from a Tor hidden service? There are
> many advantages of updating a system over Tor such as preventing a target
> adversary from fingerprinting and targeting hosts that run vulnerable
> packages and protecting systems in case the package manager has a security
> bug. Debian and Tor now provide onion mirrors for their packages. Can you
> please consider doing the same?

As far as I know this might be discussed currently at GNU sysadministration 
level,
at least that's the last info I got when I suggested this last week to
RMS.
There is an onion mirror which is run by another community. It doesn't
mirror alpha.gnu.org yet (where guix binaries are located), but it plans
to do so. I need to get in touch with the community to ask wether they
would be okay with more bandwidth.
Do you have an estimation on how high your usage would be for the guix
download from the onion mirror?

> 
> * Does Guix defend against the variety of attacks described in the TUF
> threat model document? (described in link below) How resilient is it against
> key compromise? (TUF was designed from the ground up to provide a highly
> resilient and secure update framework as a drop in replacement to crappy
> standalone updaters - a problem that's become very serious for proprietary
> OSes. The security research and implementation behind it are an excellent
> rubric that one can apply to any updater/package manager.)
> 
> https://github.com/theupdateframework/tuf/blob/develop/SECURITY.md
> 
> 
> * How does one setup a third part package archive? After looking at the
> manual I believe its as simple as fetching source from one's git repo?
> 
> Thanks
> ___
> You are receiving this e-mail because you subscribed Whonix-devel mailing 
> list. To unsubscribe visit 
> https://www.whonix.org/cgi-bin/mailman/listinfo/whonix-devel or mail 
> "unsubscribe" to whonix-devel-unsubscr...@whonix.org.
> 
> Sie erhalten diese E-Mail, weil Sie die Whonix-devel Mailingliste aboniert 
> haben. Zum abbestellen besuchen Sie 
> https://www.whonix.org/cgi-bin/mailman/listinfo/whonix-devel oder mailen Sie 
> "unsubscribe" an whonix-devel-unsubscr...@whonix.org.

Re: 'guix build --target=' handling questions

[Ludovic Courtès]

Sergei Trofimovich  skribis:

>> Question time:
>> 
>> - Is there a way to run 'guix environment --target=' in the same way as 
>> 'guix build --target='
>>   sets it up? I'd like to see how both compilers are supposed to be present 
>> in there.
>>
>> - Why default g++ in PATH is the host g++ and not target g++?
>>   Target seems to make most sense if no explicit compiler is specified.
>> 
>> - How to actually set CXX to point to target g++?
>>   It looks like implicitly there already both host (through native-inputs)
>>   and target (through build-inputs) compilers available.
>>   I would expect something like
>>   #:make-flags (list (string-append "CXX=" <.?.>)) 
>>   What should be in place of that "<.?.>" to refer to target g++?
>
> I think I've found a workaround at least for my third question.
>
> Both host and target compilers are available as g++ and ${target}-g++.
>
> Thus the following workaround seems to work:
>
> diff --git a/gnu/packages/regex.scm b/gnu/packages/regex.scm
> index f04cba706..a8fa689ab 100644
> --- a/gnu/packages/regex.scm
> +++ b/gnu/packages/regex.scm
> @@ -20,11 +20,13 @@
>
>  (define-module (gnu packages regex)
>#:use-module ((guix licenses) #:prefix license:)
>#:use-module (guix packages)
>#:use-module (guix download)
> -  #:use-module (guix build-system gnu))
> +  #:use-module (guix build-system gnu)
> +  #:use-module (guix utils) ; for %current-target-system
> +  )
>
>  (define-public re2
> (package
>   (name "re2")
>   (version "2017-01-01")
> @@ -40,11 +42,15 @@
>   "0yij1ajh66h3pj3kfz7y0ldrsww8rlpjzaavyr5lchl98as1jq74"
>   (build-system gnu-build-system)
>   (arguments
>`(#:test-target "test"
>  ;; There is no configure step, but the Makefile respects a prefix.
> -#:make-flags (list (string-append "prefix=" %output))
> +#:make-flags (list (string-append "prefix=" %output)
> +   (string-append "CXX=" ,(string-append (if 
> (%current-target-system)
> + 
> (string-append (%current-target-system) "-")
> + "")
> + "g++")))

As John wrote, this is the right fix for this package.

If you can send it with ‘git send-email’ (see
),
I’ll apply it right away.  Otherwise I can do it on your behalf.

Thanks!

Ludo’.

Re: bug#25463: guile-2.0.13 Check errors

[Ludovic Courtès]

Hi Manolis,

Manolis Ragkousis  skribis:

> On 02/11/2017 11:03 PM, Ludovic Courtès wrote:
>> Hello!
>> 
>> ren...@openmailbox.org skribis:
>> 
>>> I am trying to build guile version 2.0.13 in GNU Hurd through Guix
>>> package manager, in the 'Check' phase I have 4 errors; I am attaching
>>> the build log(config.zip), environment
>>> variables(environment-variables) and test log(check-guile.zip).
>>>
>>> This is a grep of errors, any idea how I can deal with this?
>>>
>>> /*-*/
>>> ERROR: 00-repl-server.test: repl-server: simple expression -
>>> arguments: ((system-error "fport_fill_input" "~A" ("Transport endpoint
>>> is not connected") (1073741881)))
>>> ERROR: 00-repl-server.test: repl-server: HTTP inter-protocol attack - 
>>> arguments: ((system-error "fport_fill_input" "~A" ("Transport endpoint
>>> is not connected") (1073741881)))
>> 
>> The Guix package for Guile incorporates a patch that corresponds to
>> Guile commit 2fbde7f02adb8c6585e9baf6e293ee49cd23d4c4, which fixes a
>> race condition for these tests.
>> 
>
> While using guile 2.0.14, which has commit 2fbde7f02adb8c6, the bug is
> still present. Any ideas on what could be causing this Ludo?

Is it 100% reproducible if you run:

  ./check-guile 00-repl-server.test

from Guile’s build tree?

This test uses a Unix-domain socket, which on the Hurd means that
/servers/socket/3 (I think?) must have the right translator on it.

00-socket.test also uses Unix-domain sockets.  Does it pass?

Looking more closely, it might be that one of the hunks of the patch
below solves the problem.  Could you try and report back?

(Looking at
, I
think ECONNRESET is more appropriate than ENOTCONN in the second case.)

HTH,
Ludo’.

diff --git a/test-suite/tests/00-repl-server.test b/test-suite/tests/00-repl-server.test
index 4b5ec0cb3..0b4d0c6b0 100644
--- a/test-suite/tests/00-repl-server.test
+++ b/test-suite/tests/00-repl-server.test
@@ -62,7 +62,7 @@ socket connected to that server."
  (connect client-socket sockaddr))
(lambda args
  (when (memv (system-error-errno args)
- (list ENOENT ECONNREFUSED))
+ (list ENOENT ECONNREFUSED ENOTCONN))
(when (> tries 30)
  (throw 'unresolved))
(usleep 100)
@@ -139,7 +139,7 @@ reached."
   (loop (+ 1 n))
 (lambda args
   (->bool (memv (system-error-errno args)
-(list ECONNRESET EPIPE
+(list ECONNRESET EPIPE ENOTCONN
 
 ;;; Local Variables:
 ;;; eval: (put 'with-repl-server 'scheme-indent-function 1)

Re: [PATCH 0/5] gnu/packages/aux-files

[Ludovic Courtès]

Alex Kost  skribis:

> Alex Kost (2017-02-18 12:21 +0300) wrote:
>
>> Hello, as discussed at
>>
>>   http://lists.gnu.org/archive/html/guix-devel/2016-12/msg01174.html
>>
>> this patchset moves linux-libre .conf files and "guix-emacs.el" (needed
>> for Emacs) to "gnu/packages/aux-files", also it modifies "guix-emacs.el"
>> a bit.  These patches shouldn't change anything in a user experience.
>>
>> The .conf files will be called like this:
>>
>>   gnu/packages/aux-files/linux-libre/4.9-i686.conf
>>
>> or is it better to name them like this:
>>
>>   gnu/packages/aux-files/linux-libre/linux-libre-4.9-i686.conf   or
>>   gnu/packages/aux-files/linux-libre-4.9-i686.conf
>>
>> or something else?
>>
>> IIUC Ludovic is AFK now, so I would like to push these patches in a week
>> or so, if there will be no comments.
>
> Since there were no comments, I applied this patchset to master.

Great, thanks for working on it!  It looks right to me.

Ludo’.

Re: torbrowser

[Ludovic Courtès]

ng0  skribis:

> NixOS in Nixpkgs[2] makes use of patchelf to just fix up the prebuild
> variant found on dist.torproject.org.
>
>
> I suspect that the way Nix 'fixes' this is a no-go for us.

Indeed.  :-)

> My idea is now to just reconstruct what torproject does, from the git
> checkout of torbrowser[3] and eventually later fix Guix specific issues
> and fine tuning (freedom issues etc etc). 

Sounds like a plan.

> Cloning takes a rather long time, this is where Andy's shallow-clone
> would be useful, which is where I ran into issue and delayed re-working
> this for now. If someone is interested I can post the patch which
> applied on master recently.

If you’ve made changes to what Andy posted back then, or if it doesn’t
work as you want, please post and make it clear what’s left to address.

Thanks,
Ludo’.

GNU Guix Questions

[bancfc]

Hi Guix devs, I am a privacy distro dev and we are looking at using Guix 
in our OS. I have a few questions:


* Is the Guix package archive available from a Tor hidden service? There 
are many advantages of updating a system over Tor such as preventing a 
target adversary from fingerprinting and targeting hosts that run 
vulnerable packages and protecting systems in case the package manager 
has a security bug. Debian and Tor now provide onion mirrors for their 
packages. Can you please consider doing the same?



* Does Guix defend against the variety of attacks described in the TUF 
threat model document? (described in link below) How resilient is it 
against key compromise? (TUF was designed from the ground up to provide 
a highly resilient and secure update framework as a drop in replacement 
to crappy standalone updaters - a problem that's become very serious for 
proprietary OSes. The security research and implementation behind it are 
an excellent rubric that one can apply to any updater/package manager.)


https://github.com/theupdateframework/tuf/blob/develop/SECURITY.md


* How does one setup a third part package archive? After looking at the 
manual I believe its as simple as fetching source from one's git repo?


Thanks

Re: documentation/behavior unclear of (tor-hidden-service)

[Ludovic Courtès]

ng0  skribis:

> On 17-03-06 11:13:32, Ludovic Courtès wrote:
>> Hi!
>> 
>> ng0  skribis:
>> 
>> > moving on, this could be improved:
>> > In case one aims for keeping the config public this is a bad idea but
>> > what about creating the hostname + private_key in $name as plain-file?
>> > Would this be overwritten by (tor-hidden-service) or would this just be
>> > bad practice but "whatever works for you"?
>> 
>> Tor is stateful here: it creates the
>> /var/lib/tor/hidden-services/SERVICE directory once, and then never
>> touches it again.
>> 
>> Do you think our documentation should be improved?  Could you suggest a
>> patch that improves things, while at the same time not paraphrasing too
>> much of Tor’s own documentation?

[...]

> What do you think about the private-key + hostname option? Too much
> of bad practice to implement it for the service?

What do you mean?

Now that I checked, I see the documentation explains exactly what I
wrote above, with a link to upstream’s documentation for details.  What
should we add?

> I was thinking of adding a (tor-relay-node) once I have the option to
> run a GuixSD system not in my home and/or other circumstances are
> solved which now prevent certain things.

Would be nice.

Thanks,
Ludo’.

Re: ANNOUNCE: Guix on Aarch64 !!

[Ludovic Courtès]

Efraim Flashner  skribis:

> On March 6, 2017 11:57:44 AM GMT+02:00, l...@gnu.org wrote:

[...]

>>It would be great if you could start looking for an aarch64 machine
>> to
>>plug into Hydra, or maybe start with a VM.
>>
>>Thoughts?
>>
>>Cheers,
>>Ludo’.
>
> The odroid-c2 is under $50, I've been using that. Can be powered from
> the USB flashing port, comes with 4 USB ports, Ethernet and a micro-SD
> card slot. It does come with 2GB of RAM, some of which is lost to
> video, but I've had zram enabled and didn't run into any problems
> until I tried to build boost, which needed more than the 1GB of swap I
> had. 4xA53 isn't the fastest, but I'm pretty sure its the cheapest
> option for the RAM. Downside is that it isn't quite yet supported by
> mainline kernel but there are people actively working on it.
>
> Firefly has a couple of boards with 4 GB of RAM but they're closer to
> $200 each. I have one ordered to see how that goes.

OK.  Once you have experience with the Firefly one, we could buy
whichever seems most appropriate, we have funds for that.

Thanks,
Ludo’.

Re: Let’s freeze and build ‘core-updates’!

[Ludovic Courtès]

Marius Bakke  skribis:

> Ludovic Courtès  writes:
>
>> Hello Guix!
>>
>> Looks like there’s been a disk space issue a few days ago that’s now
>> solved, so I’ve restarted an evaluation of the “core” subset.
>>
>> Is there any blocker left or should we move forward after that?
>
> We were waiting for the xorg-server 1.19.3 hotfix that was announced a
> few days ago [0], but it hasn't been released yet.
>
> I suggest we either run "autoreconf" in the build process of 1.19.2, or
> graft 1.19.3 when available. Any preference?
>
> [0] https://lists.x.org/archives/xorg-announce/2017-March/002780.html

It’s been 3 days since their message and it hasn’t happened yet, so
perhaps we should simply run autoreconf.

Thoughts?

BTW, xorg-server is a build-time dependency of gtk+@3 (for test
purposes), which is the main reason why it has so many dependents.
Perhaps it would be fine to keep using 1.9.12 for GTK+.  That way, we
can update xorg-server without rebuilding the world.

Ludo’.

torbrowser

[ng0]

I'm currently occupying the time where I don't study various things and
debug gnunet-service with packaging torbrowser.

So Gentoo (inofficially, 'torbrowser-overlay'[1]) uses the pre-build
archives found on dist.torproject.org in combination with a git checkout
and the torbrowser + firefox patches done by Gentoo devs[1.1].

NixOS in Nixpkgs[2] makes use of patchelf to just fix up the prebuild
variant found on dist.torproject.org.


I suspect that the way Nix 'fixes' this is a no-go for us.

My idea is now to just reconstruct what torproject does, from the git
checkout of torbrowser[3] and eventually later fix Guix specific issues
and fine tuning (freedom issues etc etc). 


Cloning takes a rather long time, this is where Andy's shallow-clone
would be useful, which is where I ran into issue and delayed re-working
this for now. If someone is interested I can post the patch which
applied on master recently.



1: An overlay can be compared to what we have as 'GUIX_PACKAGE_PATH',
   distributed in official and inofficial forms.
1.1: The raw data of the ebuild can be seen here, excluding eclasses:
   
https://data.gpo.zugaina.org/torbrowser/www-client/torbrowser/torbrowser-45.7.0_p650.ebuild
2: 
https://github.com/NixOS/nixpkgs/blob/3d104ab2b3e578cb4599b6fffbcc019b09547521/pkgs/tools/security/tor/torbrowser.nix
3: http://dccbbv6cooddgcrq.onion/tor-browser.git

Re: Let’s freeze and build ‘core-updates’!

[Marius Bakke]

Ludovic Courtès  writes:

> Hello Guix!
>
> Looks like there’s been a disk space issue a few days ago that’s now
> solved, so I’ve restarted an evaluation of the “core” subset.
>
> Is there any blocker left or should we move forward after that?

We were waiting for the xorg-server 1.19.3 hotfix that was announced a
few days ago [0], but it hasn't been released yet.

I suggest we either run "autoreconf" in the build process of 1.19.2, or
graft 1.19.3 when available. Any preference?

[0] https://lists.x.org/archives/xorg-announce/2017-March/002780.html


signature.asc
Description: PGP signature

Re: `guix pull` over HTTPS

[Marius Bakke]

Ludovic Courtès  writes:

> Hi!
>
> Marius Bakke  skribis:
>
>> From 800051909362b5817bbb386029edf14ffd8269a8 Mon Sep 17 00:00:00 2001
>> From: Marius Bakke 
>> Date: Tue, 28 Feb 2017 22:34:29 +0100
>> Subject: [PATCH] pull: Default to HTTPS.
>>
>> * guix/build/download.scm (tls-wrap): Allow #:verify-certificate? to be a
>>   search string for certificates.
>> * guix/scripts/pull.scm (%snapshot-url): Use HTTPS.
>> (guix-pull): Verify against the store path of NSS-CERTS.
>> ---
>>  guix/build/download.scm | 7 +--
>>  guix/scripts/pull.scm   | 8 ++--
>>  2 files changed, 11 insertions(+), 4 deletions(-)
>>
>> diff --git a/guix/build/download.scm b/guix/build/download.scm
>> index 203338b52..88da1776f 100644
>> --- a/guix/build/download.scm
>> +++ b/guix/build/download.scm
>> @@ -342,13 +342,16 @@ way."
>>  
>>  (define* (tls-wrap port server #:key (verify-certificate? #t))
>>"Return PORT wrapped in a TLS connection to SERVER.  SERVER must be a DNS
>> -host name without trailing dot."
>> +host name without trailing dot.  If VERIFY-CERTIFICATE? is a string, it is
>> +assumed to be the search path for TLS certificates passed to gnutls."
>>(define (log level str)
>>  (format (current-error-port)
>>  "gnutls: [~a|~a] ~a" (getpid) level str))
>>  
>>(let ((session  (make-session connection-end/client))
>> -(ca-certs (%x509-certificate-directory)))
>> +(ca-certs (if (string? verify-certificate?)
>> +  verify-certificate?
>> +  (%x509-certificate-directory
>
> Nitpick: I would prefer to use a different argument for the certificate
> directory.  Something like this:
>
>   (define* (tls-wrap port server #:key (verify-certificate? #t)
>  (certificate-directory
>   (%x509-certificate-directory)))
> …) 
>
> Also the ‘guix pull’ part should be a separate patch.
>
> Great work, thank you!

Hello!

Please see https://debbugs.gnu.org/cgi/bugreport.cgi?bug=25975

... for the latest version of this patch.


signature.asc
Description: PGP signature

hiawatha package description

[ng0]

Hi,

I'm not very happy with the description and synopsis I initially
provided. Any ideas what could be fixed? I'll comment on what I think is
bad:

 >synopsis: Webserver with focus on security
 >description: Hiawatha has been written with security in mind.  This

The entire second sentence is unfortunate, I would delete it.

 >resulted in a highly secure webserver in both code and features.
 >Hiawatha can stop SQL injections, XSS and CSRF attacks and exploit
 >attempts.

Again Hiawatha at the beginning of the sentence, and "can stop"… I would
replace it with:

Features include the ability to stop SQL injections, XSS and CSRF
attacks and exploit attempts.

 >+ Via a specially crafted monitoring tool, you can keep track of all
 >your webservers.

This is not included in the current version of our package and is a
separate application. I think this sentence should be removed.

Re: documentation/behavior unclear of (tor-hidden-service)

[ng0]

On 17-03-06 11:13:32, Ludovic Courtès wrote:
> Hi!
> 
> ng0  skribis:
> 
> > moving on, this could be improved:
> > In case one aims for keeping the config public this is a bad idea but
> > what about creating the hostname + private_key in $name as plain-file?
> > Would this be overwritten by (tor-hidden-service) or would this just be
> > bad practice but "whatever works for you"?
> 
> Tor is stateful here: it creates the
> /var/lib/tor/hidden-services/SERVICE directory once, and then never
> touches it again.
> 
> Do you think our documentation should be improved?  Could you suggest a
> patch that improves things, while at the same time not paraphrasing too
> much of Tor’s own documentation?
> 
> Thanks,
> Ludo’.
> 

Thanks.

I'll think of something along the lines next time I have time to spend
for documentation.

What do you think about the private-key + hostname option? Too much
of bad practice to implement it for the service?

I was thinking of adding a (tor-relay-node) once I have the option to
run a GuixSD system not in my home and/or other circumstances are
solved which now prevent certain things.

Maybe someone else can try and implement this, I only know what'S needed
for running the relay but can't do it at the moment ;)

Re: [PATCH 1/2] doc: Symlink daemon start-up files.

[Ludovic Courtès]

Leo Famulari  skribis:

> On Mon, Jan 16, 2017 at 10:49:32AM +0100, Ludovic Courtès wrote:
>> > On Fri, Nov 18, 2016 at 03:31:24PM -0500, Leo Famulari wrote:
>> > I think we should go back to the "old way" of instructing users to copy
>> > the file...
>> >
>> >> I'd argue it should point to /var/guix/profiles/per-user/root/...
>> >
>> > ... and make the service file execute this path.
>> 
>> Could you send a patch?
>
> I've attached two patches. The first updates the instructions in the
> manual, and the second builds the service files with the '/var/guix...'
> path.
>
> From 62249ac64fb5cd0235bba28197cb7ac697719b83 Mon Sep 17 00:00:00 2001
> From: Leo Famulari 
> Date: Sun, 5 Mar 2017 14:04:34 -0500
> Subject: [PATCH 1/2] Revert "doc: Symlink daemon start-up files."
>
> This reverts commit b7230de54b493da5a78922b4226255763b525a98.
>
> Versions of systemd that supported symlinked service files are not yet widely
> deployed.
>
> See this thread for more information:
> http://lists.gnu.org/archive/html/guix-devel/2017-01/msg01199.html

Could you add this reference in a @c comment in the .texi file?

Otherwise LGTM!

> From b79385c076ba4921fdf5f3ad2af76d3d171515c8 Mon Sep 17 00:00:00 2001
> From: Leo Famulari 
> Date: Sun, 5 Mar 2017 14:33:13 -0500
> Subject: [PATCH 2/2] build: Don't embed absolute paths in .service and .conf
>  service files.
>
> Otherwise, users will be stuck running an old copy of guix and the guix-daemon
> if they copy the service files instead of symlinking them.
>
> * etc/guix-daemon.conf.in, etc/guix-daemon.service.in, 
> etc/guix-publish.conf.in,
> etc/guix-publish.service.in: Expand @localstatedir@ instead of @bindir@.
> * nix/local.mk (etc/guix-%.service, etc/guix-%.conf): Use @localstatedir@
> instead of @bindir@.

OK.

Thanks for addressing this!

Ludo’.

Re: [PATCH 1/1] services: openssh: Parameterize the OpenSSH package used by the service.

[Ludovic Courtès]

Leo Famulari  skribis:

> * gnu/services/ssh.scm ()[openssh]: New field.
> (openssh-activation), (openssh-shepherd-service): Use it.
 ^  ^
(Nitpick: no need to close/open parens here.)

It’s a good idea, please push!

Thanks,
Ludo’.

Re: Changing guix download page from using HTTP to HTTPS

[Ludovic Courtès]

Leo Famulari  skribis:

> On Sun, Mar 05, 2017 at 11:15:25PM +0800, Alex Vong wrote:
>> Hello,
>> 
>> In the guix download page[0], it mentions "Source code for the Guix
>> System Distribution USB installation images as well as GNU Guix can be
>> found on the GNU ftp server for alpha releases:
>> http://alpha.gnu.org/gnu/guix/ (via HTTP) and
>> ftp://alpha.gnu.org/gnu/guix/ (via FTP).".
>> 
>> Should we change "http://alpha.gnu.org/gnu/guix/ (via HTTP)" to
>> "https://alpha.gnu.org/gnu/guix/ (via HTTPS)"?
>
> The web page is created from the guix-artwork repo:
>
> https://git.savannah.gnu.org/cgit/guix/guix-artwork.git
>
> You can send patches for that repo and then we will build the site and
> deploy the changes with CVS (!).

Yup!  It’s a good idea Alex, please send a patch.

Thanks,
Ludo’.

Re: ANNOUNCE: Guix on Aarch64 !!

[Efraim Flashner]

On March 6, 2017 11:57:44 AM GMT+02:00, l...@gnu.org wrote:
>Hello!
>
>Efraim Flashner  skribis:
>
>> Its my pleasure to announce that guix now has all the code necessary
>to
>> support aarch64! Currently support is limited to the core-updates
>> branch, but that shouldn't be too much of a problem, since currently
>> everything needs to be built from source.
>
>Woohoo!  \o/
>
>Congratulations and a big thank you for all the tireless work!
>
>Let us know if there are still pending patches or anything that needs
>to
>be addressed.
>
>It would be great if you could start looking for an aarch64 machine to
>plug into Hydra, or maybe start with a VM.
>
>Thoughts?
>
>Cheers,
>Ludo’.

The odroid-c2 is under $50, I've been using that. Can be powered from the USB 
flashing port, comes with 4 USB ports, Ethernet and a micro-SD card slot. It 
does come with 2GB of RAM, some of which is lost to video, but I've had zram 
enabled and didn't run into any problems until I tried to build boost, which 
needed more than the 1GB of swap I had. 4xA53 isn't the fastest, but I'm pretty 
sure its the cheapest option for the RAM. Downside is that it isn't quite yet 
supported by mainline kernel but there are people actively working on it.

Firefly has a couple of boards with 4 GB of RAM but they're closer to $200 
each. I have one ordered to see how that goes.
-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

Re: core-updates: flex is broken [was: GRUB fails to build]

[Ludovic Courtès]

Leo Famulari  skribis:

> On Sat, Mar 04, 2017 at 01:42:34PM -0500, Leo Famulari wrote:
>> On core-updates, GRUB fails to build like this:
>
>> ./grub-core/script/yylex.l:34:0: error: "yyalloc" redefined [-Werror]
>>  #define yyalloc(size, scanner)   (grub_malloc((size)))
>>  ^
>> grub_script.yy.c:104:0: note: this is the location of the previous definition
>> 
>>  ^
>> ./grub-core/script/yylex.l:35:0: error: "yyfree" redefined [-Werror]
>>  #define yyfree(ptr, scanner)   (grub_free((ptr)))
>>  ^
>> grub_script.yy.c:108:0: note: this is the location of the previous definition
>> 
>>  ^
>> ./grub-core/script/yylex.l:36:0: error: "yyrealloc" redefined [-Werror]
>>  #define yyrealloc(ptr, size, scanner) (grub_realloc((ptr), (size)))
>>  ^
>> grub_script.yy.c:106:0: note: this is the location of the previous definition
>> 
>>  ^
>> cc1: all warnings being treated as errors
>
> Discussion in the GRUB project; they've decided not to fix this in their
> code and to instead wait for it to be fixed in flex:
>
> http://lists.gnu.org/archive/html/grub-devel/2017-02/msg00133.html
>
> flex discussion:
>
> https://github.com/westes/flex/issues/162
>
> So, the flex package on core-updates is not ready to be deployed,
> unfortunately :(
>
> We can wait for a flex update or try to port the bug fix.

Any idea how many packages aside from GRUB are affected?  Would it work
to simply provide the old Flex in addition to the new one, and have GRUB
use it?

Thanks,
Ludo’.

Re: documentation/behavior unclear of (tor-hidden-service)

[Ludovic Courtès]

Hi!

ng0  skribis:

> moving on, this could be improved:
> In case one aims for keeping the config public this is a bad idea but
> what about creating the hostname + private_key in $name as plain-file?
> Would this be overwritten by (tor-hidden-service) or would this just be
> bad practice but "whatever works for you"?

Tor is stateful here: it creates the
/var/lib/tor/hidden-services/SERVICE directory once, and then never
touches it again.

Do you think our documentation should be improved?  Could you suggest a
patch that improves things, while at the same time not paraphrasing too
much of Tor’s own documentation?

Thanks,
Ludo’.

Re: `guix pull` over HTTPS

[Ludovic Courtès]

Hi!

Marius Bakke  skribis:

> From 800051909362b5817bbb386029edf14ffd8269a8 Mon Sep 17 00:00:00 2001
> From: Marius Bakke 
> Date: Tue, 28 Feb 2017 22:34:29 +0100
> Subject: [PATCH] pull: Default to HTTPS.
>
> * guix/build/download.scm (tls-wrap): Allow #:verify-certificate? to be a
>   search string for certificates.
> * guix/scripts/pull.scm (%snapshot-url): Use HTTPS.
> (guix-pull): Verify against the store path of NSS-CERTS.
> ---
>  guix/build/download.scm | 7 +--
>  guix/scripts/pull.scm   | 8 ++--
>  2 files changed, 11 insertions(+), 4 deletions(-)
>
> diff --git a/guix/build/download.scm b/guix/build/download.scm
> index 203338b52..88da1776f 100644
> --- a/guix/build/download.scm
> +++ b/guix/build/download.scm
> @@ -342,13 +342,16 @@ way."
>  
>  (define* (tls-wrap port server #:key (verify-certificate? #t))
>"Return PORT wrapped in a TLS connection to SERVER.  SERVER must be a DNS
> -host name without trailing dot."
> +host name without trailing dot.  If VERIFY-CERTIFICATE? is a string, it is
> +assumed to be the search path for TLS certificates passed to gnutls."
>(define (log level str)
>  (format (current-error-port)
>  "gnutls: [~a|~a] ~a" (getpid) level str))
>  
>(let ((session  (make-session connection-end/client))
> -(ca-certs (%x509-certificate-directory)))
> +(ca-certs (if (string? verify-certificate?)
> +  verify-certificate?
> +  (%x509-certificate-directory

Nitpick: I would prefer to use a different argument for the certificate
directory.  Something like this:

  (define* (tls-wrap port server #:key (verify-certificate? #t)
 (certificate-directory
  (%x509-certificate-directory)))
…) 

Also the ‘guix pull’ part should be a separate patch.

Great work, thank you!

Ludo’.

Re: midnight commander package fixes, opinions wanted

[ng0]

On 17-03-06 11:55:27, Efraim Flashner wrote:
> On Wed, Mar 01, 2017 at 05:01:23PM +, ng0 wrote:
> > On 17-03-01 16:58:41, ng0 wrote:
> > > Hi,
> > > 
> > > I already fixed some of the open issues with our package of 'mc'.
> > > 
> > > I think people will expect features to just work and not being broken
> > > (as they are right now).
> > > My personal opinion ignored, how do you want to proceed? The vim way
> > > where we have $package (basic, as small as it gets) and $package-full
> > > (with all the features you can have enabled)?
> > > 
> > > I'd like to hear your opionion so that I can proceed fixing mc with
> > > what we agreed on.
> > > 
> > 
> > And also your opinion, I don't know what an opionion is but it sounds
> > like opium combined with onion and I don't want that.
> > 
> 
> I've been sitting on a patch for ranger for a while. I also couldn't
> decide between packaging just ranger or also linking in the various
> programs it calls.
> 
> I think that if mc would use libcaca to display an image, and just
> installing libcaca in profile would satisfy that dependancy, then
> leaving it out is "not great, but acceptable".
> 
> -- 
> Efraim Flashner      אפרים פלשנר
> GPG key = A28B F40C 3E55 1372 662D  14F7 41AA E7DC CA3D 8351
> Confidentiality cannot be guaranteed on emails sent or received unencrypted


It's not that easy. The references to applications are absolute
using '/usr/{bin,sbin}' and similar ones.

Maybe it's possible to just use the application name, but that depends
on the context in the code, etc.

Re: `guix pull` over HTTPS

[Ludovic Courtès]

Leo Famulari  skribis:

> On Wed, Mar 01, 2017 at 03:36:11AM +0100, Marius Bakke wrote:
>> Subject: [PATCH] pull: Default to HTTPS.
>> 
>> * guix/build/download.scm (tls-wrap): Add CERTIFICATE-DIRECTORY parameter.
>> (open-connection-for-uri): Adjust parameters to match.
>> (http-fetch): Likewise.
>> (url-fetch): Likewise.
>> * guix/download.scm (download-to-store): Likewise.
>> * guix/scripts/pull.scm (%snapshot-url): Use HTTPS.
>> (guix-pull): Verify against the store path of NSS-CERTS.
>
> When I don't have GnuTLS in my environment, it fails like this:
>
> Starting download of /tmp/guix-file.pSCYyI
> From https://git.savannah.gnu.org/cgit/guix.git/snapshot/master.tar.gz...
> ;;; Failed to autoload make-session in (gnutls):
> ;;; ERROR: missing interface for module (gnutls)
> ERROR: In procedure module-lookup: Unbound variable: make-session
> failed to download "/tmp/guix-file.pSCYyI" from 
> "https://git.savannah.gnu.org/cgit/guix.git/snapshot/master.tar.gz;
> guix pull: error: failed to download up-to-date source, exiting

What about making GnuTLS a hard requirement for Guix?

Ludo’.

Re: midnight commander package fixes, opinions wanted

[ng0]

On 17-03-01 17:01:23, ng0 wrote:
> On 17-03-01 16:58:41, ng0 wrote:
> > Hi,
> > 
> > I already fixed some of the open issues with our package of 'mc'.
> > 
> > I think people will expect features to just work and not being broken
> > (as they are right now).
> > My personal opinion ignored, how do you want to proceed? The vim way
> > where we have $package (basic, as small as it gets) and $package-full
> > (with all the features you can have enabled)?
> > 
> > I'd like to hear your opionion so that I can proceed fixing mc with
> > what we agreed on.
> > 
> 
> And also your opinion, I don't know what an opionion is but it sounds
> like opium combined with onion and I don't want that.
> 

For the lack of reaction for a long time, due to whatever reasons, I
will simply propose that we go the way of vim and vim-full.

'mc-full' will have many more dependencies than our current 'mc' and
should in the end be fully functional, while 'mc' will still complain
about missing features. The description of mc-full shall reflect that
you get full functionality with this application variant.

Anyone who wants this, feel free to pick it up and fix the related bug.

Re: [PATCH 1/1] gnu: linux-libre@4.1, linux-libre@4.4, linux-libre@4.9: Fix CVE-2017-6074.

[Ludovic Courtès]

Leo Famulari  skribis:

> * gnu/packages/linux.scm (linux-libre-4.1, linux-libre-4.4,
> linux-libre-4.9): Add patch for CVE-2017-6074.

If you haven’t done already, please push!  Especially since this
vulnerability is ranked as “high”.

Thank you!

Ludo’.

Re: ANNOUNCE: Guix on Aarch64 !!

[Ludovic Courtès]

Hello!

Efraim Flashner  skribis:

> Its my pleasure to announce that guix now has all the code necessary to
> support aarch64! Currently support is limited to the core-updates
> branch, but that shouldn't be too much of a problem, since currently
> everything needs to be built from source.

Woohoo!  \o/

Congratulations and a big thank you for all the tireless work!

Let us know if there are still pending patches or anything that needs to
be addressed.

It would be great if you could start looking for an aarch64 machine to
plug into Hydra, or maybe start with a VM.

Thoughts?

Cheers,
Ludo’.

Re: midnight commander package fixes, opinions wanted

[Efraim Flashner]

On Wed, Mar 01, 2017 at 05:01:23PM +, ng0 wrote:
> On 17-03-01 16:58:41, ng0 wrote:
> > Hi,
> > 
> > I already fixed some of the open issues with our package of 'mc'.
> > 
> > I think people will expect features to just work and not being broken
> > (as they are right now).
> > My personal opinion ignored, how do you want to proceed? The vim way
> > where we have $package (basic, as small as it gets) and $package-full
> > (with all the features you can have enabled)?
> > 
> > I'd like to hear your opionion so that I can proceed fixing mc with
> > what we agreed on.
> > 
> 
> And also your opinion, I don't know what an opionion is but it sounds
> like opium combined with onion and I don't want that.
> 

I've been sitting on a patch for ranger for a while. I also couldn't
decide between packaging just ranger or also linking in the various
programs it calls.

I think that if mc would use libcaca to display an image, and just
installing libcaca in profile would satisfy that dependancy, then
leaving it out is "not great, but acceptable".

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


signature.asc
Description: PGP signature

Re: building packages with git+ssh

[Ludovic Courtès]

Hello,

Sorry for the late reply.

Chaitan Rogers  skribis:

> We are trying to build code that is stored in a internal repository that is 
> only accessible via git+ssh. This failed because openssh isn't included in the
> set of inputs that are available to the cloning process. After speaking to 
> "rekado" and others on IRC, I forked git-download.scm and modified it to
> include ssh. This meant that git was able to invoke ssh successfully but the 
> process subsequently failed due to failed host key verification. Perhaps
> with some hacking we may be able to convince ssh to ignore the host key but 
> we'll probably have more problems with keys / secrets etc that aren't
> in the jail.

I think you could arrange to set ‘HOME’ in git-download.scm (in the #~
expression that’s in there), and then populate ~/.ssh/known_hosts with
the relevant OpenSSH host public key (see ‘local-file’ for how to intern
a file into the store.)

If that sounds obscure to you, we can discuss the details here starting
from the patch you have.

> I also tried to get the package source into the jail by building with 
> --with-source. This almost worked but I noticed that the flag seems to apply 
> to the
> package being built but not any of its dependencies - i.e providing it 
> multiple times for dependent packages had no effect. 

Right, currently --with-source only applies to the “tip” (unlike
--with-input, which rewrites the dependency graph recursively).

We could change that or add a different option to do what you want.
Either way it’s mainly a matter of using ‘package-input-rewriting’ and
shouldn’t be hard.

Thoughts?

Thanks,
Ludo’.

Re: Leaving the guix project

[Ludovic Courtès]

Hello David,

This is bad news for my first day back from vacations (I knew I should
have stayed on vacation!  ;-)).

I’m sad to see you leave.  I understand we have disagreements on the
project’s goals, and I respect that.  The goals haven’t changed since
Day 1 though, and I think it’s a project where we can both have fun
(make cool technical contributions) and help further user freedom.

You have made lots of great contributions to this project that truly
made a difference; they will be missed.  I wish you the best for your
future free software endeavors!

Ludo’.

Re: [PATCH 5/6] gnu: gcc: Force Aarch64 to use /lib.

[Ludovic Courtès]

Efraim Flashner  skribis:

> On February 22, 2017 9:42:58 PM GMT+02:00, Efraim Flashner 
>  wrote:
>>On Tue, Feb 14, 2017 at 09:51:20PM +0200, Efraim Flashner wrote:
>>> On Tue, Feb 14, 2017 at 09:51:47AM +0100, Ludovic Courtès wrote:
>>> > Danny Milosavljevic  skribis:
>>> > 
>>> > >> +  ;; Force Aarch64 libdir to be /lib and not /lib64
>>> > >> +  (substitute* "gcc/config/aarch64/t-aarch64-linux"
>>> > >> +(("lib64") "lib"))
>>> > >> +
>>> > >
>>> > > I'd amend the comment to say why.
>>> > 
>>> > I think we should just skip this patch.  There’s no reason one
>>> > architecture should be treated different from the others in that
>>> > respect.
>>> > 
>>> > WDYT, Efraim?
>>> > 
>>> > Ludo’.
>>> 
>>> I don't think it should cause a problem either way. As far as I can
>>tell
>>> it doesn't make a difference to the software built further down the
>>> line.
>>> 
>>
>>Looks like I spoke too soon. I tried to build gccgo which failed at the
>>linking stage, since it turned out libgcc_s was in gccgo/lib64 and not
>>gccgo/lib. I then tried gcc@4.9 and had a similar failure, the lib
>>files
>>were split between lib and lib64. Other than this patch (with a when
>>file-exists), the other idea is to change libdir in gcc.scm:86 to be
>>lib64 on aarch64.
>>
>>Unfortunately it looks like it'd cause a full rebuild on core-updates.
>>I'll test it overnight and see how it goes.
>>
>>-- 
>>Efraim Flashner      אפרים פלשנר
>>GPG key = A28B F40C 3E55 1372 662D  14F7 41AA E7DC CA3D 8351
>>Confidentiality cannot be guaranteed on emails sent or received
>>unencrypted
>
> As is, all of our GCC versions FTBFS on aarch64, except the versions used 
> during bootstrapping. This includes gccgo, but I haven't checked the other 
> 'special GCCs' to see if also affects them.
>
> With the above patch I was able to build GCC@4.9 and gccgo, and gccgo@5 
> failed as expected.
>
> Unfortunately pushing this patch would result in a full rebuild on 
> core-updates. Suggestions?

Given that ‘core-updates’ is still in the stage where we haven’t build
everything, you could push this ‘substitute*’ statement now IMO.

It’s pretty bad that software insists on using /lib64 down the road,
though.

Thanks,
Ludo’.

Re: Let’s freeze and build ‘core-updates’!

[Ludovic Courtès]

Hello Guix!

Looks like there’s been a disk space issue a few days ago that’s now
solved, so I’ve restarted an evaluation of the “core” subset.

Is there any blocker left or should we move forward after that?

Thanks,
Ludo’.

Re: [PATCH 0/15]: Add pplacer and OCaml dependencies.

[Ludovic Courtès]

Hi Ben,

Sorry for the delay.

Ben Woodcroft  skribis:

> On 10/02/17 08:32, Ludovic Courtès wrote:
>> Hi Ben,
>>
>> Ben Woodcroft  skribis:
>>
>>> I'm quite happy to send these patches in, pplacer has been near the
>>> top of my most wanted list since I started contributing. There's two
>>> parts that are a little out of the ordinary:
>>>
>>> 1) Unfortunately pplacer requires the outdated OCaml 4.01, so I
>>> adapted the package-with-python2 approach.
>> Is there really no way upstream could update the package to current
>> OCaml?  That would save us a lot of packages and associated work.
>
> I'm afraid I don't think so. I asked about this, but haven't received
> a response for 3 weeks.
> https://github.com/matsen/pplacer/issues/354
>
> The recommended way of installing this software is to download
> binaries, so updating the OCaml dependency may not be at the top of
> the priority list. This is maintained software and there's a number of
> pieces of software which rely on pplacer (including a few of my own),
> so I think it is worth packaging. So, IMO we should wear the costs on
> this one.

OK, that makes sense.

To make progress, how about applying the non-4.01-specific parts of the
patch series first (I think you didn’t get any feedback on these, so
it’s safe to assume they’re OK if ‘guix lint’ has nothing to say)?

Second, could you submit the bits about supporting 4.01 to guix-patches?
I’ll take a look if nobody beats me at it.

Thanks,
Ludo’.

Re: [PATCH 1/2] doc: Symlink daemon start-up files.

[Hartmut Goebel]

Am 05.03.2017 um 21:55 schrieb Leo Famulari:
> I've attached two patches. The first updates the instructions in the
> manual, and the second builds the service files with the '/var/guix...'
> path.

LGTM

-- 
Regards
Hartmut Goebel

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