openssh pubkeys as part of system config

[ng0]

Hi,

I will soon start to assemble an GuixSD system image for IN-Berlin
virtual servers.
I know bayfront uses a module which defines lsh pubkeys for user 'root'
(?) and makes them part of the system generation.

For IN-Berlin (and probably other hosters) it would help if there was a
way to define openssh pubkeys in the system config.
I know I could just generate an image, make it writable and put my key
into /root/.ssh/authorized_keys, but it would be better if this would be
possible to define directly.

Has someone looked into this before?

Re: Should synopsis handle texinfo markup?

[Alex Kost]

Ludovic Courtès (2017-03-15 17:14 +0100) wrote:

> Hi Alex,
>
> Alex Kost  skribis:
>
>> Hello, I've noticed that several packages contain "@code" structures in
>> their synopses, but only 'description' field supports texinfo markup.
>> For example, look at:
>>
>>   guix package -s ruby-minitest-bonus-assertions
>>
>> So I wonder, should these synopses be adjusted to remove @code things,
>> or would it be better to make sysnopses support it?
>
> Maybe we should support Texinfo in synopses after all.  I don’t think
> there were good reasons not to do it.
>
> Thoughts?

I'm not aware of potential problems so I think it would be good to add
this support to synopses.

-- 
Alex

Re: Question related to outputs

[Ludovic Courtès]

Hi!

Pjotr Prins  skribis:

> So, to have different build procedures for the same package I best
> define different packages and inherit? Rather than define different
> outputs - it just appeared natural to me ;).

Yeah it really depends.  For debugging info, it’s definitely better to
have a “debug” output; if you instead had two different packages, that
would make debugging much less convenient (you’d have to first remove
the package-without-debugging-info, then install the
package-with-debugging-info, rebuild your stuff, etc.)  In other cases,
the choice between an additional output and a separate package is less
obvious.

Thanks,
Ludo’.

Re: delete profile

[Alex Kost]

Federico Beffa (2017-03-14 17:43 +0100) wrote:

> Alex Kost  writes:
>
>> Federico Beffa (2017-03-14 09:42 +0100) wrote:
>>
>>> Pjotr Prins  writes:
>>> 'guix -p $HOME/guix-test-profile' lists only 1 generation (but I did
>>> create another one and then I rolled-back).
>>>
>>> I run 'guix gc' and now I find dangling symlinks in my $HOME.
>>
>> What dangling symlinks?  Just remove them :-)
>
> Of this type:
>
> $HOME/guix-test-profile-XXX-link -> /gnu/store/...
>
> Yes, sure, I deleted them.  It just seems strange that a GC leaves
> dangling links around.

GC can't remove such generation links; it removes only the stuff that is
placed in the store.  It's up to a user to remove profiles and their
generations.

-- 
Alex

Re: delete profile

[Alex Kost]

Pjotr Prins (2017-03-14 15:18 +) wrote:

> On Tue, Mar 14, 2017 at 05:28:52PM +0300, Alex Kost wrote:
>> No, "$HOME/guix-test-profile" was not a symlink to
>> "/var/guix/profiles/...".  Try this:
>
> Hmmm. You are right. ~/.guix-profile, meanwile, does point inside
> /var/guix.

Yes, "~/.guix-profile" is the only "special" profile that uses this
additional level of symlinking.  Profiles that you create with "guix
package -p ... -i ..." always point directly to store.

> I have wondered before how GC works on profiles not in /var/guix.
>
> Where does it store that state? In the database?

As Ludovic wrote, the links to the created profile generations are put
in "/var/guix/gcroots/auto" and "guix gc" does not clear the store of
these "registered gc roots".

> I mean, if I simply
> remove the symlink
>
>   lrwxrwxrwx  1 wrk   502   51 Feb 19 09:38 guix-build-system-1-link -> 
> /gnu/store/0lyv2p35ziymd6xjrfxy8sp502n2ii5d-profile
>
> how does Guix know it can GC 
> /gnu/store/0lyv2p35ziymd6xjrfxy8sp502n2ii5d-profile?

After you remove "foo-1-link", the according link in
"/var/guix/gcroots/auto" will become dead, so "guix gc" will remove it
and will clear the store of that profile.

-- 
Alex

Re: [PATCH] services: connman: Rework service.

[Ludovic Courtès]

Hi Mathieu,

Mathieu Othacehe  skribis:

> * gnu/services/networking.scm (connman-service): Remove.
> (): New record specifying the package
> to be used (connman) and whether vpn plugin shall be
> disabled (disable-vpn?).
> (connman-configuration): New exported variable.
> (connman-configuration?): New exported variable.
> (connman-service-type): Export it.
>
> * doc/guix.texi (Networking Services): Adjust accordingly.

This had fallen through the cracks, sorry about that!  I’ve just applied
it.

BTW, please use guix-patc...@gnu.org, which goes to
, to minimize the risk of patches
getting forgotten.  :-)

Thank you!

Ludo’.

Re: [PATCH 4/4] services: openssh: Add 'subsystems' option.

[Ludovic Courtès]

Hi Clément,

Clément Lassieur  skribis:

> I think there is a misunderstanding.  I didn't want to push this because
> it was not tested, and because subsystems are often useless without
> Match, and Match is unsupported.  The pair/list thing is not the
> problem.
>
> And I was waiting for ng0 to test, because he asked for this patch (see
> http://lists.gnu.org/archive/html/guix-devel/2017-02/msg00906.html), so
> I thought he was able to test.
>
> If ng0 still needs the patch and confirms that it works well, I'm
> willing to update it.  Otherwise, let's drop it.

The patch looks like a useful addition.  It would be sad to drop it, no?

If you could add a test to (gnu tests ssh) that would be perfect, but
otherwise it LGTM.  Perhaps the default value for ‘subsystems’ should
include internal-sftp though, as users probably expect sftp to just work.

I don’t have any issue with using two-element lists; I think the syntax
for pairs can be a bit confusing for newcomers to it’s probably better
to avoid it in service configuration.

Thanks,
Ludo’.

Re: [PATCH] build: Fix errors in "make dist"

[Ludovic Courtès]

John Darrington  skribis:

> * Makefile.am (EXTRA_DIST): Remove build-aux/hydra/demo-os.scm
> * gnu/packages/patches/vdirsyncer-test-suite-slow-machines.patch: Remove
> "/gnu/store/..."

Good catch.  Looks like this hasn't been applied yet.  Please push!

Thanks,
Ludo’.

Re: Dealing with CVEs that apply to unspecified package versions

[Ludovic Courtès]

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

> What about raising the issue on oss-sec?  Ideally the QEMU folks would
> take care of labeling QEMU’s CVEs, the libxml2 folks would take care of
> theirs, etc.

For the record I followed up on this discussion on oss-sec:

  http://www.openwall.com/lists/oss-security/2017/03/15/3

Ludo’.

Mass-packaging of 300 KDE application prepared - Help required

[Hartmut Goebel]

Hello all,

as promised earlier, I prepared a repository inclusing patches for more
than 300 KDE packages. I will not have time to work on them, though.
Others will need to implement the packages based on this preperations.

The repo contains prepared guix package descriptions for more than 300
KDE packages. The idea is to take a lot of stupid work from the
shoulders of those who want to add a KDE package and automatically
prepare as much as possible.

Prepared are
- name, version, url, hash
- synopsis (two variants)
- description (two variants)
- license (needs to be verified)
- inputs and native-inputs
- store-path of the archive

The synopsis and descriptions are taken from Debian and Mageia, chosen
by what was easy to access for me.

The license is taken from Debian but needs to be rechecked. Maybe
OpenSuSE is a good place to look since they seem to have a strong focus
on this.

The inputs and native-inputs are taken from the `CMakeList.txt` file,
which I processed and mapped many known requirements to guix's package
names. For your convenience unprocessed content of the `CMakeList.txt`
file has been put into the description, so you hopefully find all
necessary information there.

The repository can be found at
, detailed description on
how to work with it is available ins the README there. If you have any
enhancement requests, please let me know.

(I refained from sending the patches to some mailinglist since it is
more then 880KB data and more than 300 patches).

-- 
Regards
Hartmut Goebel

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

Re: delete profile

[Pjotr Prins]

Thanks for the explanation :)

Re: bug#26072: [PATCH 35/35] gnu: Add r-seurat.

[Ricardo Wurmus]

> Seurat seems to have it's last release as v1.4.0, and the usual
> approach would be to package that release. Is there some reason why a
> specific commit was used?

The latest version is 1.4.0.12, which appears to be 8 commits after the
commit selected for this patch.  The downloadable archive, however, does
not contain the sources.

The source archive for version 1.4.0 is from Oct 4, 2016.  The selected
commit probably was the latest version at the time.

I’ll add a comment to the top of this package expression and update the
commit to fccb77d, which is equivalent to the binary release 1.4.0.12.

Thanks for the patches, and thank you Ben for the review! 

--
Ricardo

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

Re: bug#26072: [PATCH 35/35] gnu: Add r-seurat.

[Ricardo Wurmus]

Ricardo Wurmus  writes:

> I’ll add a comment to the top of this package expression and update the
> commit to fccb77d, which is equivalent to the binary release 1.4.0.12.

I also deleted the bundled jar and added a build phase to build it from
source.  It’s now in master: 2441c284140ddbd354b61c9d1606af1357f95c1f.

--
Ricardo

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

Re: [PATCH] gnu: Add tftp-hpa.

[Thomas Danckaert]

<20170206225825.23935-1-boskov...@gmail.com>
X-Mailer: Mew version 6.7 on Emacs 25.1 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: base64

SGkgTGVvIGFuZCBHw6Fib3IsDQoNCkkganVzdCB0aG91Z2h0IG9mIHRoaXMgcGF0Y2ggYWdhaW4g
dG9kYXksIGJ1dCBMZW8gYmVhdCBtZSB0byBpdC4NCg0KSSd2ZSBsb29rZWQgaW50byB0aGUgbGlj
ZW5zaW5nIGEgYml0IG1vcmUuICBUaGUgQlNEIGFkdmVydGlzaW5nIGlzc3VlIA0Kc2VlbXMgdG8g
YmUgYSBtaXN1bmRlcnN0YW5kaW5nIG9uIHRoZSBwYXJ0IG9mIERlYmlhbiwgYXQgbGVhc3QgYXMg
ZmFyIA0KYXMgdGhlIGF1dGhvciBpcyBjb25jZXJuZWQ6DQpodHRwOi8vd3d3LnN5c2xpbnV4Lm9y
Zy9hcmNoaXZlcy8yMDAzLUphbnVhcnkvMDAxNDg0Lmh0bWwNCg0KU28sIHRoZXJlJ3Mgbm8gY2xl
YXIgbGljZW5zZSBzdGF0ZW1lbnQgaW5jbHVkZWQgaW4gdGhlIHBhY2thZ2UgDQpzb3VyY2UsIGJ1
dCB0aGUgYXV0aG9yJ3MgaW50ZW50aW9uIGlzIHRvIGRpc3RyaWJ1dGUgdGhlIGNvZGUgdW5kZXIg
YSANCnBlcm1pc3NpdmUgbGljZW5zZSwgd2l0aG91dCBhZHZlcnRpc2luZyBjbGF1c2UuICAgSSB0
aGluayB3ZSBjYW4gdXNlIA0KKGxpY2Vuc2Ugbm9uLWNvcHlsZWZ0KT8NCg0KV2l0aG91dCB0aGUg
QlNEIGFkdmVydGlzaW5nIGlzc3VlcywgbGlua2luZyB3aXRoIHJlYWRsaW5lIHNob3VsZCBub3Qg
DQpiZSBhIHByb2JsZW0gZWl0aGVyLCBzbyB3ZSBjYW4gaW5jbHVkZSByZWFkbGluZSBhcyBhbiBp
bnB1dCwgYW5kIA0KcmVtb3ZlIHN0YXRlbWVudHMgYWJvdXQgcmVhZGxpbmUgZnJvbSB0aGUgZGVz
Y3JpcHRpb24gKEkgdGhpbmsgdGhlIA0KZGVzY3JpcHRpb24gY29tZXMgZnJvbSB0aGUgRGViaWFu
L1VidW50dSBwYWNrYWdlIHJlcG9zaXRvcmllcz8pLiAgV2UgDQpjb3VsZCByZXVzZSB0aGUgZGVz
Y3JpcHRpb24gZnJvbSANCmh0dHBzOi8vZ2l0Lmtlcm5lbC5vcmcvcHViL3NjbS9uZXR3b3JrL3Rm
dHAvdGZ0cC1ocGEuZ2l0L2Fib3V0LCANCnNvbWV0aGluZyBsaWtlOg0KDQogICAgICAidGZ0cC1o
cGEgaXMgYSBjb25nbG9tZXJhdGUgb2YgYSBudW1iZXIgb2YgdmVyc2lvbnMgb2YgdGhlIEJTRCAN
ClRGVFAgY29kZSwNCmNoYW5nZWQgYXJvdW5kIHRvIHBvcnQgdG8gYSB3aG9sZSBjb2xsZWN0aW9u
IG9mIG9wZXJhdGluZyBzeXN0ZW1zLiAgDQpUaGUgZ29hbA0KaXMgdG8gd29yayBvbiBhbnkgcmVh
c29uYWJseSBtb2Rlcm4gVW5peCB3aXRoIHNvY2tldHMuIg0KDQpXRFlUPw0KDQpUaG9tYXMNCg==

Re: [PATCH] gnu: Add tftp-hpa.

[Thomas Danckaert]

(sorry, something went wrong with my message there)

Hi Leo and Gábor,

I just thought of this patch again today, but Leo beat me to it.

I've looked into the licensing a bit more.  The BSD advertising
issue seems to be a misunderstanding on the part of Debian, at least
as far as the author is concerned:
http://www.syslinux.org/archives/2003-January/001484.html

So, there's no clear license statement included in the package
source, but the author's intention is to distribute the code under a
permissive license, without advertising clause.  I think we can use
(license non-copyleft)?

Without the BSD advertising issues, linking with readline should not
be a problem either, so we can include readline as an input, and
remove statements about readline from the description (I think the
description comes from the Debian/Ubuntu package repositories?).  We
could reuse the description from
https://git.kernel.org/pub/scm/network/tftp/tftp-hpa.git/about,
something like:

 "tftp-hpa is a conglomerate of a number of versions of the BSD
 TFTP code, changed around to port to a whole collection of
 operating systems.  The goal is to work on any reasonably modern
 Unix with sockets."

WDYT?

Thomas

Re: [PATCH 2/2] gnu: Add GNU Mach.

[rennes]

Hello,
I'm helping Manolis forward some pending patches.
Attach the patch with suggested corrections.

Make sure the phase returns #t on success:

  (and (zero? (system* "make" …))
   (begin
 (copy-file …)
 #t))



+(synopsis "Microkernel of the GNU system")
+(description
+ "GNU Mach is the microkernel upon which a GNU Hurd system is 
based.")

+(license gpl2+)))


Does it build both on GNU/Linux and GNU/Hurd?

For GNU/Linux (core-updates) works, also works in Hurd.From 2128b50a0dda9e4e6dbad74f2706aee58f81708d Mon Sep 17 00:00:00 2001
From: rennes 
Date: Thu, 16 Mar 2017 09:29:55 -0600
Subject: [PATCH 2/2] gnu: Add GNU Mach.

* gnu/packages/hurd.scm (gnumach): New variable.

Co-authored-by: Rene Saavedra 
---
 gnu/packages/hurd.scm | 36 +++-
 1 file changed, 35 insertions(+), 1 deletion(-)

diff --git a/gnu/packages/hurd.scm b/gnu/packages/hurd.scm
index ba91b60be..66608f2d8 100644
--- a/gnu/packages/hurd.scm
+++ b/gnu/packages/hurd.scm
@@ -1,5 +1,5 @@
 ;;; GNU Guix --- Functional package management for GNU
-;;; Copyright © 2014, 2015, 2016 Manolis Fragkiskos Ragkousis 
+;;; Copyright © 2014, 2015, 2016, 2017 Manolis Fragkiskos Ragkousis 
 ;;;
 ;;; This file is part of GNU Guix.
 ;;;
@@ -210,3 +210,37 @@ Library for GNU/Hurd.")
 Hurd-minimal package which are needed for both glibc and GCC.")
 (home-page (package-home-page hurd-headers))
 (license (package-license hurd-headers
+
+(define-public gnumach
+  (package
+(name "gnumach")
+(version "1.8")
+(source
+ (origin
+   (method url-fetch)
+   (uri (gnumach-source-url version))
+   (sha256
+(base32
+ "02hygsfpd2dljl5lg1vjjg9pizi9jyxd4aiiqzjshz6jax62jm9f"
+(build-system gnu-build-system)
+(arguments
+ `(#:phases (modify-phases %standard-phases
+  (add-after 'install 'produce-image
+ (lambda* (#:key outputs #:allow-other-keys)
+   (let* ((out  (assoc-ref outputs "out"))
+  (boot (string-append out "/boot")))
+ (and (zero? (system* "make" "gnumach.gz"))
+  (begin
+(copy-file "gnumach.gz"
+   (string-append boot "/gnumach.gz"))
+#t
+(native-inputs
+ `(("mig" ,mig)
+   ("perl" ,perl)))
+(supported-systems %hurd-systems)
+(home-page
+ "https://www.gnu.org/software/hurd/microkernel/mach/gnumach.html";)
+(synopsis "Microkernel of the GNU system")
+(description
+  "GNU Mach is the microkernel upon which a GNU Hurd system is based.")
+(license gpl2+)))
-- 
2.12.0

Re: [PATCH 3/5] gnu: Add tlp service.

[Clément Lassieur]

Mathieu Othacehe  writes:

> * gnu/services/pm.scm: New file.
> * gnu/local.mk (GNU_SYSTEM_MODULES): Add gnu/services/tlp.scm.
> * doc/guix.texi (Power management Services): New section.

Hi Mathieu,

Very nice!

On my x200, with tlp, powertop reports:

The battery reports a discharge rate of 10.1 W
The estimated remaining time is 4 hours, 52 minutes

Without tlp:

The battery reports a discharge rate of 11.9 W
The estimated remaining time is 4 hours, 11 minutes


Here are a few comments:

[...]

> +(define-module (gnu services pm)
> +  #:use-module (guix gexp)
> +  #:use-module (guix packages)
> +  #:use-module (guix records)
> +  #:use-module (gnu packages linux)
> +  #:use-module (gnu services)
> +  #:use-module (gnu services base)
> +  #:use-module (gnu services configuration)
> +  #:use-module (gnu services shepherd)
> +  #:use-module (gnu system shadow)
> +  #:export (tlp-service-type
> +tlp-configuration
> +generate-tlp-documentation))

I don't think generate-tlp-documentation needs to be exported.

> +(define (uglify-field-name field-name)
> +  (let ((str (symbol->string field-name)))
> +(string-join (string-split
> +  (string-upcase
> +   (if (string-suffix? "?" str)
> +   (substring str 0 (1- (string-length str)))
> +   str))
> +  #\-)
> + "_")))
> +
> +(define (serialize-field field-name val)
> +  (format #t "~a=~a\n" (uglify-field-name field-name) val))
> +
> +(define (serialize-boolean field-name val)
> +  (serialize-field field-name (if val "1" "0")))
> +(define-maybe boolean)
> +
> +(define (serialize-string field-name val)
> +  (serialize-field field-name val))
> +(define-maybe string)
> +
> +(define (space-separated-string-list? val)
> +  (and (list? val)
> +   (and-map (lambda (x)
> +  (and (string? x) (not (string-index x #\space
> +val)))
> +(define (serialize-space-separated-string-list field-name val)
> +  (serialize-field field-name
> +   (format #f "~s"
> +   (string-join val " "
> +(define-maybe space-separated-string-list)
> +
> +(define (non-negative-integer? val)
> +  (and (exact-integer? val) (not (negative? val
> +(define (serialize-non-negative-integer field-name val)
> +  (serialize-field field-name val))
> +(define-maybe non-negative-integer)
> +
> +(define (on-off-boolean? val)
> +  (boolean? val))
> +(define (serialize-on-off-boolean field-name val)
> +  (serialize-field field-name (if val "on" "off")))
> +(define-maybe on-off-boolean)
> +
> +(define (y-n-boolean? val)
> +  (boolean? val))
> +(define (serialize-y-n-boolean field-name val)
> +  (serialize-field field-name (if val "Y" "N")))
> +
> +(define-configuration tlp-configuration
> +  (tlp
> +   (package tlp)
> +   "The TLP package.")
> +
> +  (tlp-enable?
> +   (boolean #t)
> +   "Set to true if you wish to enable TLP.")

>From this point, the indentation is broken.

> +   (tlp-default-mode
> +(string "AC")
> +"Default mode when no power supply can be detected. Alternatives are
> +AC and BAT.")
> +
> +   (disk-idle-secs-on-ac
> +(non-negative-integer 0)
> +"Number of seconds Linux kernel has to wait after the disk goes idle,
> +before syncing on AC.")
> +
> +   (disk-idle-secs-on-bat
> +(non-negative-integer 2)
> +"Same as @code{disk-idle-ac} but on BAT mode.")
> +
> +   (max-lost-work-secs-on-ac
> +(non-negative-integer 15)
> +"Dirty pages flushing periodicity, expressed in seconds.")
> +
> +   (max-lost-work-secs-on-bat
> +(non-negative-integer 60)
> +"Same as @code{max-lost-work-secs-on-ac} but on BAT mode.")
> +
> +   (cpu-scaling-governor-on-ac
> +(maybe-space-separated-string-list 'disabled)
> +"CPU frequency scaling governor on AC mode. With intel_pstate
> +driver, alternatives are powersave and performance. With acpi-cpufreq driver,
> +alternatives are ondemand, powersave, performance and conservative.")

Please, could you put two spaces between phrases? :) As in "and
performance.  With...".  I've seen this in other parts of your patch as
well.

[...]

> +(define (tlp-shepherd-service config)
> +  (let* ((tlp-bin (file-append
> +   (tlp-configuration-tlp config) "/bin/tlp"))
> + (tlp-action (lambda args
> +  #~(lambda _
> +  (zero? (system* #$tlp-bin #$@args))
> +(list (shepherd-service
> +   (documentation "Run TLP script.")
> +   (provision '(tlp))
> +   (requirement '(syslogd user-processes))

I have not been able to see anything related to tlp in
/var/log/messages.  And if I set trace mode (TLP_DEBUG, in /etc/tlp), I
have an error message: "logger: unknown facility name: debug", which I
think could be patched in tlp source, maybe by removing "-p debug".  Or
maybe it is logger that needs to be patched, I don't k

Re: [PATCH 3/5] gnu: Add tlp service.

[Clément Lassieur]

Sorry I forgot two things:

> +(define (tlp-activation config)
> +  (let* ((config-dir "/etc")
> + (config-str (with-output-to-string
> +   (lambda ()
> + (serialize-configuration
> +  config
> +  tlp-configuration-fields
> + (config-file (plain-file "tlp" config-str)))
> +  #~(begin
> +  (use-modules (guix build utils))
> +  (mkdir-p #$config-dir)
^
Is this necessary?  I think /etc should exist already.

Also, "tlp stat" does not work.

Re: [PATCH 1/5] gnu: tlp: Read configuration from /etc/tlp.

[Clément Lassieur]

> * gnu/packages/linux.scm (tlp): Set TLP_CONF to "/etc/tlp".
> ---
>  gnu/packages/linux.scm | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/gnu/packages/linux.scm b/gnu/packages/linux.scm
> index 28440297e..bb9dbcb3d 100644
> --- a/gnu/packages/linux.scm
> +++ b/gnu/packages/linux.scm
> @@ -3494,7 +3494,7 @@ Light is the successor of lightscript.")
> (setenv "TLP_BIN" (string-append out "/bin"))
> (setenv "TLP_TLIB" (string-append out "/share/tlp-pm"))
> (setenv "TLP_ULIB" (string-append out "/lib/udev"))
> -   (setenv "TLP_CONF" (string-append out "/etc/tlp"))
> +   (setenv "TLP_CONF" "/etc/tlp")
> (setenv "TLP_SHCPL"
> (string-append out 
> "/share/bash-completion/completions"))
> (setenv "TLP_MAN" (string-append out "/share/man")

LGTM!

Re: [PATCH 5/5] services: Fix a typo which was corrected in generated doc.

[Clément Lassieur]

> * gnu/services/vpn.scm (define-split-configuration): Fix typo.
> ---
>  gnu/services/vpn.scm | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/gnu/services/vpn.scm b/gnu/services/vpn.scm
> index 844a11b3d..e1a04a985 100644
> --- a/gnu/services/vpn.scm
> +++ b/gnu/services/vpn.scm
> @@ -1,6 +1,7 @@
>  ;;; GNU Guix --- Functional package management for GNU
>  ;;; Copyright © 2017 Julien Lepiller 
>  ;;; Copyright © 2017 Clément Lassieur 
> +;;; Copyright © 2017 Mathieu Othacehe 
>  ;;;
>  ;;; This file is part of GNU Guix.
>  ;;;
> @@ -279,7 +280,7 @@ by the authority given in @code{ca}.")
>  
> (key
>  (string "/etc/openvpn/client.key")
> -"The key of the machine the daemon is running on. It must be the whose
> +"The key of the machine the daemon is running on. It must be the key 
> whose
>  certificate is @code{cert}.")
>  
> (comp-lzo?

The commit message should be: "services: openvpn: ...", but otherwise
LGTM :)

Re: [PATCH 3/5] gnu: Add tlp service.

[Mathieu Othacehe]

Hi Clément !

Thanks for the review. I agree with all
your points, I'll publish a v2 but on debbugs this time !

Thank you,

Mathieu

> Here are a few comments:
>
> [...]
>
>> +(define-module (gnu services pm)
>> +  #:use-module (guix gexp)
>> +  #:use-module (guix packages)
>> +  #:use-module (guix records)
>> +  #:use-module (gnu packages linux)
>> +  #:use-module (gnu services)
>> +  #:use-module (gnu services base)
>> +  #:use-module (gnu services configuration)
>> +  #:use-module (gnu services shepherd)
>> +  #:use-module (gnu system shadow)
>> +  #:export (tlp-service-type
>> +tlp-configuration
>> +generate-tlp-documentation))
>
> I don't think generate-tlp-documentation needs to be exported.
>
>> +(define (uglify-field-name field-name)
>> +  (let ((str (symbol->string field-name)))
>> +(string-join (string-split
>> +  (string-upcase
>> +   (if (string-suffix? "?" str)
>> +   (substring str 0 (1- (string-length str)))
>> +   str))
>> +  #\-)
>> + "_")))
>> +
>> +(define (serialize-field field-name val)
>> +  (format #t "~a=~a\n" (uglify-field-name field-name) val))
>> +
>> +(define (serialize-boolean field-name val)
>> +  (serialize-field field-name (if val "1" "0")))
>> +(define-maybe boolean)
>> +
>> +(define (serialize-string field-name val)
>> +  (serialize-field field-name val))
>> +(define-maybe string)
>> +
>> +(define (space-separated-string-list? val)
>> +  (and (list? val)
>> +   (and-map (lambda (x)
>> +  (and (string? x) (not (string-index x #\space
>> +val)))
>> +(define (serialize-space-separated-string-list field-name val)
>> +  (serialize-field field-name
>> +   (format #f "~s"
>> +   (string-join val " "
>> +(define-maybe space-separated-string-list)
>> +
>> +(define (non-negative-integer? val)
>> +  (and (exact-integer? val) (not (negative? val
>> +(define (serialize-non-negative-integer field-name val)
>> +  (serialize-field field-name val))
>> +(define-maybe non-negative-integer)
>> +
>> +(define (on-off-boolean? val)
>> +  (boolean? val))
>> +(define (serialize-on-off-boolean field-name val)
>> +  (serialize-field field-name (if val "on" "off")))
>> +(define-maybe on-off-boolean)
>> +
>> +(define (y-n-boolean? val)
>> +  (boolean? val))
>> +(define (serialize-y-n-boolean field-name val)
>> +  (serialize-field field-name (if val "Y" "N")))
>> +
>> +(define-configuration tlp-configuration
>> +  (tlp
>> +   (package tlp)
>> +   "The TLP package.")
>> +
>> +  (tlp-enable?
>> +   (boolean #t)
>> +   "Set to true if you wish to enable TLP.")
>
> From this point, the indentation is broken.
>
>> +   (tlp-default-mode
>> +(string "AC")
>> +"Default mode when no power supply can be detected. Alternatives are
>> +AC and BAT.")
>> +
>> +   (disk-idle-secs-on-ac
>> +(non-negative-integer 0)
>> +"Number of seconds Linux kernel has to wait after the disk goes idle,
>> +before syncing on AC.")
>> +
>> +   (disk-idle-secs-on-bat
>> +(non-negative-integer 2)
>> +"Same as @code{disk-idle-ac} but on BAT mode.")
>> +
>> +   (max-lost-work-secs-on-ac
>> +(non-negative-integer 15)
>> +"Dirty pages flushing periodicity, expressed in seconds.")
>> +
>> +   (max-lost-work-secs-on-bat
>> +(non-negative-integer 60)
>> +"Same as @code{max-lost-work-secs-on-ac} but on BAT mode.")
>> +
>> +   (cpu-scaling-governor-on-ac
>> +(maybe-space-separated-string-list 'disabled)
>> +"CPU frequency scaling governor on AC mode. With intel_pstate
>> +driver, alternatives are powersave and performance. With acpi-cpufreq 
>> driver,
>> +alternatives are ondemand, powersave, performance and conservative.")
>
> Please, could you put two spaces between phrases? :) As in "and
> performance.  With...".  I've seen this in other parts of your patch as
> well.
>
> [...]
>
>> +(define (tlp-shepherd-service config)
>> +  (let* ((tlp-bin (file-append
>> +   (tlp-configuration-tlp config) "/bin/tlp"))
>> + (tlp-action (lambda args
>> +  #~(lambda _
>> +  (zero? (system* #$tlp-bin #$@args))
>> +(list (shepherd-service
>> +   (documentation "Run TLP script.")
>> +   (provision '(tlp))
>> +   (requirement '(syslogd user-processes))
>
> I have not been able to see anything related to tlp in
> /var/log/messages.  And if I set trace mode (TLP_DEBUG, in /etc/tlp), I
> have an error message: "logger: unknown facility name: debug", which I
> think could be patched in tlp source, maybe by removing "-p debug".  Or
> maybe it is logger that needs to be patched, I don't know.
>
> Otherwise syslogd would not be needed here.  WDYT?
>
> BTW, could you consider adding TLP_DEBUG to the service?
>
>> +   (start (tlp-action "init" "start"))
>> +   (stop  (tlp-act

Re: [PATCH 3/5] gnu: Add tlp service.

[Mathieu Othacehe]

> Also, "tlp stat" does not work.

It seems to work for me, could you elaborate on that ?

Note that you need to be root.

Mathieu

Re: [PATCH 3/5] gnu: Add tlp service.

[Clément Lassieur]

>> Also, "tlp stat" does not work.
>
> It seems to work for me, could you elaborate on that ?

Oh I see, it was because tlp wasn't installed...

Running it directly from the store like this:

/gnu/store/ymq6khzhnyxsq5z1mi2jnri93ww0ysji-tlp-0.9/bin/tlp init stat

Produced:

/gnu/store/ymq6khzhnyxsq5z1mi2jnri93ww0ysji-tlp-0.9/bin/.tlp-real: line 
322: tlp-stat: command not found

But I guess it is not a problem if the service does not use it.  And a
user willing to call tlp directy should install it.  So please ignore my
comment!

Re: [PATCH 2/5] services: Factorize define-maybe macro.

[Clément Lassieur]

Mathieu Othacehe  writes:

> * gnu/services/configuration.scm (define-maybe): New exported
>   procedure.
>   (id): New procedure extracted from define-configuration.
> * gnu/services/messaging.scm (define-all-configurations): Define id
>   inside procedure as define-all-configurations is now the only user.
> ---
>  gnu/services/configuration.scm | 28 
>  gnu/services/messaging.scm | 22 +++---
>  2 files changed, 23 insertions(+), 27 deletions(-)
>
> diff --git a/gnu/services/configuration.scm b/gnu/services/configuration.scm
> index 2ad3a637a..3fdaf705a 100644
> --- a/gnu/services/configuration.scm
> +++ b/gnu/services/configuration.scm
> @@ -1,5 +1,6 @@
>  ;;; GNU Guix --- Functional package management for GNU
>  ;;; Copyright © 2015 Andy Wingo 
> +;;; Copyright © 2017 Mathieu Othacehe 
>  ;;;
>  ;;; This file is part of GNU Guix.
>  ;;;
> @@ -36,6 +37,7 @@
>  configuration-field-default-value-thunk
>  configuration-field-documentation
>  serialize-configuration
> +define-maybe
>  define-configuration
>  validate-configuration
>  generate-documentation
> @@ -85,16 +87,26 @@
> (configuration-field-name field) val
>  fields))
>  
> +(define-syntax-rule (id ctx parts ...)
> +  (datum->syntax ctx (symbol-append (syntax->datum parts) ...)))

The docstring was helpful!  Could you put it too?

> +(define-syntax define-maybe
> +  (lambda (x)
> +(syntax-case x ()
> +  ((_ stem)
> +   (with-syntax
> +   ((stem?(id #'stem #'stem #'?))
> +(maybe-stem?  (id #'stem #'maybe- #'stem #'?))
> +(serialize-stem   (id #'stem #'serialize- #'stem))
> +(serialize-maybe-stem (id #'stem #'serialize-maybe- #'stem)))
> + #'(begin
> + (define (maybe-stem? val)
> +   (or (eq? val 'disabled) (stem? val)))
> + (define (serialize-maybe-stem field-name val)
> +   (when (stem? val) (serialize-stem field-name val)
> +
>  (define-syntax define-configuration
>(lambda (stx)
> -(define (id ctx part . parts)
> -  (let ((part (syntax->datum part)))
> -(datum->syntax
> - ctx
> - (match parts
> -   (() part)
> -   (parts (symbol-append part
> - (syntax->datum (apply id ctx parts

I think this part, that replaces the old version of "id" with the new
one deserves a specific patch, because it is not directly related to
moving define-maybe, and because it does more that just "moving code".

>  (syntax-case stx ()
>((_ stem (field (field-type def) doc) ...)
> (with-syntax (((field-getter ...)
> diff --git a/gnu/services/messaging.scm b/gnu/services/messaging.scm
> index 34723dc11..e50eeba8c 100644
> --- a/gnu/services/messaging.scm
> +++ b/gnu/services/messaging.scm
> @@ -1,5 +1,6 @@
>  ;;; GNU Guix --- Functional package management for GNU
>  ;;; Copyright © 2017 Clément Lassieur 
> +;;; Copyright © 2017 Mathieu Othacehe 
>  ;;;
>  ;;; This file is part of GNU Guix.
>  ;;;
> @@ -49,27 +50,10 @@
>  ;;;
>  ;;; Code:
>  
> -(define-syntax-rule (id ctx parts ...)
> -  "Assemble PARTS into a raw (unhygienic) identifier."
> -  (datum->syntax ctx (symbol-append (syntax->datum parts) ...)))
> -
> -(define-syntax define-maybe
> -  (lambda (x)
> -(syntax-case x ()
> -  ((_ stem)
> -   (with-syntax
> -   ((stem?(id #'stem #'stem #'?))
> -(maybe-stem?  (id #'stem #'maybe- #'stem #'?))
> -(serialize-stem   (id #'stem #'serialize- #'stem))
> -(serialize-maybe-stem (id #'stem #'serialize-maybe- #'stem)))
> - #'(begin
> - (define (maybe-stem? val)
> -   (or (eq? val 'disabled) (stem? val)))
> - (define (serialize-maybe-stem field-name val)
> -   (when (stem? val) (serialize-stem field-name val)
> -

>  (define-syntax define-all-configurations
>(lambda (stx)
> +(define-syntax-rule (id ctx parts ...)
> +  (datum->syntax ctx (symbol-append (syntax->datum parts) ...)))

This could go in the second patch as well.

>  (define (make-pred arg)
>(lambda (field target)
>  (and (memq (syntax->datum target) `(common ,arg)) field)))

Re: [PATCH 4/5] doc: Re-generate openvpn service documentation.

[Clément Lassieur]

Mathieu Othacehe  writes:

> * doc/guix.texi (VPN Services): Generate documentation with
> generate-openvpn-server-documentation and
> generate-openvpn-client-documentation helpers and guile 2.1.7.
> ---
>  doc/guix.texi | 88 
> +--
>  1 file changed, 44 insertions(+), 44 deletions(-)

LGTM, thanks :)

guix is the guildhall that we always wanted!

[Andy Wingo]

Hi all!

I've always wondered about the right solution for getting Guile users to
share code with each other.  At one point I thought that we would have a
Guile-specific packaging system like CPAN or NPM, but one with GNU
stow-like characteristics.  We had problems with C extensions though:
how do you build one?  Where do you get the compilers?  Where do you get
the libraries?

Guix (https://guixsd.org/) solves this in a comprehensive way.  From the
four or five bootstrap binaries, Guix can download and build the world
from source, for any of its supported architectures.  The result is a
farm of weirdly-named files in /gnu/store, but the transitive closure of
a store item works on any distribution of that architecture.

I got the feeling that Guix was what the guildhall should be long ago,
but something recent made it clear to me.  For background, consider
https://www.gnu.org/software/guix/manual/html_node/Binary-Installation.html,
the binary installation instructions for Guix.  These are directions for
how to install Guix on a "foreign" distro like Fedora.  Basically you
just untar a /gnu/store onto your system, make sure that your /var/guix
has some metadata so that Guix knows what's in the store, and there you
are.

The process of building that weird binary installation tarball was
always a bit ad-hoc though, geared to Guix's installation needs.

But it turns out that we can use the same strategy to distribute
reproducible binaries for any package that Guix includes.  Notably, if
you run:

  guix pack -S /opt/guile-fibers-1.0.0=/ guile-next guile-fibers 
glibc-utf8-locales

Then what you get is a tarball that has Guile, Fibers, and everything
they depend on.  It's safe to extract in / because it only adds files to
/gnu/store, and then it adds a symlink for /opt/guile-fibers-1.0.0.

Crucially, this "guix pack" is really an SDK for Guile and Fibers.
Fibers is a library.  You can now make an SDK for anything!!!  I
mean, I know, that's a lot of exclamation marks, but check it: you can
develop locally, say using

  /opt/guile-fibers-1.0.0/bin/guile -L /path/to/my/code

and it just works.  If you package up your code, you can make a Guix
package out of it and make a "guix pack" out of that closure and
distribute it to your users: REGARDLESS OF WHAT OPERATING SYSTEM THEY
RUN, AND WITH FULL SOURCE REPRODUCIBILITY.  It's huge.  It's the missing
piece of docker: not only do you get space-sharing (installing
guile-fibers-1.0.0 and my-app-built-on-guile-fibers-2.0 can share common
libraries as needed, instead of many huge image files), you also have
the keys to rebuild that image in a standard way.

So:

  * local development using packaged libraries: check.
  * distribution of your work to people without $package-manager: check.
  * easy addition of your code to a common NPM-like registry: ?

For this last bit, we have two options.  One is to add your package to
Guix.  It's relatively easy; here's what I added for Fibers:

(define-public guile-fibers
  (package
(name "guile-fibers")
(version "1.0.0")
(source (origin
  (method url-fetch)
  (uri (string-append "https://wingolog.org/pub/fibers/fibers-";
  version ".tar.gz"))
  (sha256
   (base32
"0vjkg72ghgdgphzbjz9ig8al8271rq8974viknb2r1rg4lz92ld0"
(build-system gnu-build-system)
(native-inputs
 `(("texinfo" ,texinfo)
   ("pkg-config" ,pkg-config)))
(inputs
 `(("guile" ,guile-next)))
(synopsis "Lightweight concurrency facility for Guile")
(description
 "Fibers is a Guile library that implements a a lightweight concurrency
facility, inspired by systems like Concurrent ML, Go, and Erlang.  A fiber 
is
like a \"goroutine\" from the Go language: a lightweight thread-like
abstraction.  Systems built with Fibers can scale up to millions of 
concurrent
fibers, tens of thousands of concurrent socket connections, and many 
parallel
cores.  The Fibers library also provides Concurrent ML-like channels for
communication between fibers.

Note that Fibers makes use of some Guile 2.1/2.2-specific features and
is not available for Guile 2.0.")
(home-page "https://github.com/wingo/fibers";)
(license license:lgpl3+)))

OK, so this uses gnu-build-system, which requires a tarball; we need to
extend this to have a "guile-build-system" for modules that are just
Scheme, in which we just "guild compile" everything.  That way you can
have a repo on gitlab or whatever and you just specify the URL and the
revision and you are done.  I don't know if we can get around specifying
the sha256 when we specify the git revision; probably not a good idea in
light of the SHA1 breakage.  Anyway, that's a thing.

But while getting your package into guix is easier than you think, it's
not automatic.  I think there's room for a

Re: guix is the guildhall that we always wanted!

[Amirouche Boubekki]

Héllo wingo!

On 2017-03-16 19:25, Andy Wingo wrote:

Hi all!



[...]


But it turns out that we can use the same strategy to distribute
reproducible binaries for any package that Guix includes.  Notably, if
you run:

  guix pack -S /opt/guile-fibers-1.0.0=/ guile-next guile-fibers
glibc-utf8-locales

Then what you get is a tarball that has Guile, Fibers, and everything
they depend on.  It's safe to extract in / because it only adds files 
to

/gnu/store, and then it adds a symlink for /opt/guile-fibers-1.0.0.



cf. http://git.savannah.gnu.org/cgit/guix.git/tree/doc/guix.texi#n2392



So:

  * local development using packaged libraries: check.
  * distribution of your work to people without $package-manager: 
check.

  * easy addition of your code to a common NPM-like registry: ?

For this last bit, we have two options.  One is to add your package to
Guix.  It's relatively easy; here's what I added for Fibers:

(define-public guile-fibers
  (package
(name "guile-fibers")
(version "1.0.0")
(source (origin
  (method url-fetch)
  (uri (string-append 
"https://wingolog.org/pub/fibers/fibers-";

  version ".tar.gz"))
  (sha256
   (base32

"0vjkg72ghgdgphzbjz9ig8al8271rq8974viknb2r1rg4lz92ld0"

(build-system gnu-build-system)
(native-inputs
 `(("texinfo" ,texinfo)
   ("pkg-config" ,pkg-config)))
(inputs
 `(("guile" ,guile-next)))
(synopsis "Lightweight concurrency facility for Guile")
(description
 "Fibers is a Guile library that implements a a lightweight 
concurrency

facility, inspired by systems like Concurrent ML, Go, and Erlang.
A fiber is
like a \"goroutine\" from the Go language: a lightweight 
thread-like

abstraction.  Systems built with Fibers can scale up to millions
of concurrent
fibers, tens of thousands of concurrent socket connections, and
many parallel
cores.  The Fibers library also provides Concurrent ML-like 
channels for

communication between fibers.

Note that Fibers makes use of some Guile 2.1/2.2-specific features 
and

is not available for Guile 2.0.")
(home-page "https://github.com/wingo/fibers";)
(license license:lgpl3+)))

OK, so this uses gnu-build-system, which requires a tarball; we need to
extend this to have a "guile-build-system" for modules that are just
Scheme, in which we just "guild compile" everything.  That way you can
have a repo on gitlab or whatever and you just specify the URL and the
revision and you are done.  I don't know if we can get around 
specifying
the sha256 when we specify the git revision; probably not a good idea 
in

light of the SHA1 breakage.  Anyway, that's a thing.

But while getting your package into guix is easier than you think, it's
not automatic.  I think there's room for a middle ground that's a bit
more decentralized than Guix, but more centralized than people using
GUIX_PACKAGE_PATH to add random directories of Guix package files.


Ok, I like the idea!



So!  My proposal for this new "guildhall" would be:

1. a web service



What would be the cli interface associated with that web service?
Some thing like the following will do:

  $ guildhall register

Register a package against the guildhall repository.
You must have a package.scm in the current working
directory that follows package specification of guix.
http://link/to/guix/doc/that/I/dont/know

Does it require login/password?

That is all I can think of.


2. on which users registers projects

3. a project is a name + a git repository with a /package.scm file


We can have that using guile-git: current commit + remote origin.

4. the package.scm contains Guix package definitions for that 
project


5. the web service administers a git repository collecting those
   packages
   - without any hydra.gnu.org overhead


What do you mean, by no hydra.gnu.org overhead? Where are
done the 'guix pack' command?


   - without any manual checks
   - in a form that you can just check out once and add to 
GUIX_PACKAGE_PATH




Ok, the 'guix pack' can be done by the maintainer and
'guix register' does upload the lz file to guildhall
website.


6. adding a new tag to a project's git repo of the form vX makes a
   release X and updates the guildhall package
   - it could be the web service has to poll git repos
   - or maybe you have to invoke some command to update guildhall


It's painful to have to "watch" git repositories, except if the git
repository is a remote of the develloper's git. Basically it requires
a manual intervention from the maintainer. Otherwise, guildhall website
need to pull regularly all git repositories.


7. probably we need to steal many ideas from npm.org


I think about their dependency resolution algorithm. I think
civodul shoul

Re: [PATCH 4/4] services: openssh: Add 'subsystems' option.

[ng0]

Ludovic Courtès transcribed 1.1K bytes:
> Hi Clément,
> 
> Clément Lassieur  skribis:
> 
> > I think there is a misunderstanding.  I didn't want to push this because
> > it was not tested, and because subsystems are often useless without
> > Match, and Match is unsupported.  The pair/list thing is not the
> > problem.
> >
> > And I was waiting for ng0 to test, because he asked for this patch (see
> > http://lists.gnu.org/archive/html/guix-devel/2017-02/msg00906.html), so
> > I thought he was able to test.
> >
> > If ng0 still needs the patch and confirms that it works well, I'm
> > willing to update it.  Otherwise, let's drop it.
> 
> The patch looks like a useful addition.  It would be sad to drop it, no?
> 
> If you could add a test to (gnu tests ssh) that would be perfect, but
> otherwise it LGTM.  Perhaps the default value for ‘subsystems’ should
> include internal-sftp though, as users probably expect sftp to just work.
> 
> I don’t have any issue with using two-element lists; I think the syntax
> for pairs can be a bit confusing for newcomers to it’s probably better
> to avoid it in service configuration.
> 
> Thanks,
> Ludo’.
> 

I'm taking a break currently and only deal with planing things or
documenting work and future Guix related work, so I won't test this in
the next 1 or 2 weeks.
I am fairly sure that sshfs still needs this.

ps Clément: 'them'/'they' are pronouns if you don't know the gender and/or
prefered pronoun of a person :)

Re: [PATCH 4/4] services: openssh: Add 'subsystems' option.

[Clément Lassieur]

ng0  writes:

> Ludovic Courtès transcribed 1.1K bytes:
>> Hi Clément,
>> 
>> Clément Lassieur  skribis:
>> 
>> > I think there is a misunderstanding.  I didn't want to push this because
>> > it was not tested, and because subsystems are often useless without
>> > Match, and Match is unsupported.  The pair/list thing is not the
>> > problem.
>> >
>> > And I was waiting for ng0 to test, because he asked for this patch (see
>> > http://lists.gnu.org/archive/html/guix-devel/2017-02/msg00906.html), so
>> > I thought he was able to test.
>> >
>> > If ng0 still needs the patch and confirms that it works well, I'm
>> > willing to update it.  Otherwise, let's drop it.
>> 
>> The patch looks like a useful addition.  It would be sad to drop it, no?
>> 
>> If you could add a test to (gnu tests ssh) that would be perfect, but
>> otherwise it LGTM.  Perhaps the default value for ‘subsystems’ should
>> include internal-sftp though, as users probably expect sftp to just work.
>> 
>> I don’t have any issue with using two-element lists; I think the syntax
>> for pairs can be a bit confusing for newcomers to it’s probably better
>> to avoid it in service configuration.
>> 
>> Thanks,
>> Ludo’.
>> 
>
> I'm taking a break currently and only deal with planing things or
> documenting work and future Guix related work, so I won't test this in
> the next 1 or 2 weeks.
> I am fairly sure that sshfs still needs this.
>
> ps Clément: 'them'/'they' are pronouns if you don't know the gender and/or
> prefered pronoun of a person :)

Oh, I apologize.

Re: [PATCH 3/5] gnu: Add tlp service.

[Mathieu Othacehe]

> I have not been able to see anything related to tlp in
> /var/log/messages.  And if I set trace mode (TLP_DEBUG, in /etc/tlp), I
> have an error message: "logger: unknown facility name: debug", which I
> think could be patched in tlp source, maybe by removing "-p debug".  Or
> maybe it is logger that needs to be patched, I don't know.
>
> Otherwise syslogd would not be needed here.  WDYT?

Well when you call logger -p debug, it means with facility = debug and
priority = default one = notice. syslog does only support predefined
facilities like auth, cron, kern ...
The complete list can be found here (section 19.1):

https://www.gnu.org/software/inetutils/manual/html_node/syslogd-invocation.html

The facility debug does not exist and cannot be created.
So logger -p debug makes no sense to me.

However, debug is a priority, so logger -p user.debug or daemon.debug
would be correct.

I could patch those logger calls in guix tlp package but I prefer to
contact tlp maintainer to see if he can fix it upstream.

>
> BTW, could you consider adding TLP_DEBUG to the service?

It is not needed for now as it enables a broken feature !

I will remove syslogd requirement from this service for now.

Thanks for testing this out !

Mathieu

Re: branch core-updates updated (49c2a46 -> 568004c)

[Efraim Flashner]

On Wed, Mar 15, 2017 at 01:00:24AM -0400, Leo Famulari wrote:
> On Tue, Mar 14, 2017 at 02:49:00PM -0400, Efraim Flashner wrote:
> > efraim pushed a change to branch core-updates
> > in repository guix.
> > 
> >   from  49c2a46   gnu: python@2.7: Update to 2.7.13
> >new  c5e9101   gnu: mesa: Use llvm backend for Intel hardware only.
> >new  2a8b89c   gnu: mesa: Customize build flags based on 
> > architecture.
> >new  044006f   gnu: mesa: Enable gallium tests.
> >new  568004c   gnu: nss: Build for aarch64-linux with 64-bit support.
> 
> Some in this push broke mesa for me on x86_64.
> 
> It fails in the configure phase like this:
> 
> checking if more special flags are required for pthreads... no
> checking for PTHREAD_PRIO_INHERIT... yes
> checking for PTHREADSTUBS... yes
> checking for LIBDRM... yes
> checking for SHA1Init... no
> checking for CC_SHA1_Init... no
> checking for wincrypt.h... no
> checking for SHA1Init in -lmd... no
> checking for LIBSHA1... no
> checking for nettle_sha1_init in -lnettle... no
> checking for gcry_md_open in -lgcrypt... no
> checking for SHA1_Init in -lcrypto... no
> checking for OPENSSL... no
> checking for SHA1 implementation...
> checking for GLPROTO... yes
> checking for DRI2PROTO... yes
> checking for DRI3PROTO... yes
> checking for PRESENTPROTO... yes 
> checking for XCB_DRI3... yes
> checking for XF86VIDMODE... yes
> checking for DRIGL... yes
> checking for EXPAT... yes
> configure: error: classic DRI driver '915' does not exist
> phase `configure' failed after 12.6 seconds
> 
> Please tell me what other information or debugging I can provide.

for everyone not on IRC just now and curious, it should be i915


-- 
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: guix is the guildhall that we always wanted!

[Mark H Weaver]

Andy Wingo  writes:

> So!  My proposal for this new "guildhall" would be:
>
> 1. a web service
>
> 2. on which users registers projects
>
> 3. a project is a name + a git repository with a /package.scm file
>
> 4. the package.scm contains Guix package definitions for that project

We need to keep all Guix package definitions within Guix itself, for the
same reason that Linux (the kernel) developers insist on keeping all
device drivers within a single monolithic tree.  If we start encouraging
a decentralized approach, that would result in strong pressure on us to
freeze our API, which includes even such details as which module each
package is exported from.  This would drastically reduce the freedom
Guix has to evolve the way its packages are specified.

   Mark

Re: guix is the guildhall that we always wanted!

[Ludovic Courtès]

Hello!

Mark H Weaver  skribis:

> Andy Wingo  writes:
>
>> So!  My proposal for this new "guildhall" would be:
>>
>> 1. a web service
>>
>> 2. on which users registers projects
>>
>> 3. a project is a name + a git repository with a /package.scm file
>>
>> 4. the package.scm contains Guix package definitions for that project
>
> We need to keep all Guix package definitions within Guix itself, for the
> same reason that Linux (the kernel) developers insist on keeping all
> device drivers within a single monolithic tree.  If we start encouraging
> a decentralized approach, that would result in strong pressure on us to
> freeze our API, which includes even such details as which module each
> package is exported from.  This would drastically reduce the freedom
> Guix has to evolve the way its packages are specified.

I think having repos maintained elsewhere is OKish, but it’s true that
it requires people who maintain those repos to follow closely what’s
going on in Guix proper because we’re not guaranteeing API stability.

There’s a couple of ways to mitigate potential API instability: using
‘specification->package’ instead of referring to packages by variable
name, and using (guix) and (gnu) instead of more specific modules.

So I think having an external repo for guildhall would be possible, but
we need to make sure the connection to Guix APIs is loose enough.

Also, guildhall would be a privileged “customer” I suppose.  :-)

Ludo’.

Re: Introducing ‘guix pack’

[Ludovic Courtès]

Hello Guix!  Hello 2.2 Guilers!

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

> I’d like to move support for Docker (currently in ‘guix archive’) to
> this new command because I think it’s more appropriate: ‘guix archive’
> is supposed to be rather low-level so it would not create a profile, for
> instance.

As of right now, ‘guix pack’ can create Docker image (‘guix archive’
can no longer do that):

  guix pack guile-next -S /opt/guile-2.2.0= -f docker

I’d be grateful if someone could check with Docker that I didn’t break
anything though.  Any takers?  :-)

The archive build process is bit-reproducible too, which is pretty cool
(Docker images created in January, 1970!).

That’s it!

Ludo’.

Re: Should synopsis handle texinfo markup?

[Ludovic Courtès]

Alex Kost  skribis:

> Ludovic Courtès (2017-03-15 17:14 +0100) wrote:
>
>> Hi Alex,
>>
>> Alex Kost  skribis:
>>
>>> Hello, I've noticed that several packages contain "@code" structures in
>>> their synopses, but only 'description' field supports texinfo markup.
>>> For example, look at:
>>>
>>>   guix package -s ruby-minitest-bonus-assertions
>>>
>>> So I wonder, should these synopses be adjusted to remove @code things,
>>> or would it be better to make sysnopses support it?
>>
>> Maybe we should support Texinfo in synopses after all.  I don’t think
>> there were good reasons not to do it.
>>
>> Thoughts?
>
> I'm not aware of potential problems so I think it would be good to add
> this support to synopses.

Cool.  Would you or anyone like to give it a try?  Alternatively we can
mail it to bug-guix for later.

Ludo’.

Re: [PATCH 4/4] services: openssh: Add 'subsystems' option.

[John Darrington]

On Thu, Mar 16, 2017 at 08:45:27PM +, ng0 wrote:

 ps Cl??ment: 'them'/'they' are pronouns if you don't know the gender and/or
 prefered pronoun of a person :)


... according to some. -  but most linguists, and many orators (the president 
of 
the Free Software Foundation being one of them) consider this to be a misuse of 
the English language and refuse to (mis)use these words for such a purpose.

J'
 

-- 
Avoid eavesdropping.  Send strong encrypted email.
PGP Public key ID: 1024D/2DE827B3 
fingerprint = 8797 A26D 0854 2EAB 0285  A290 8A67 719C 2DE8 27B3
See http://sks-keyservers.net or any PGP keyserver for public key.



signature.asc
Description: Digital signature

Re: [PATCH] gnu: Add lmms

[Rodger Fox]

Qt 4 is no longer supported by the Qt project, but security
vulnerabilities continue to be discovered in it, and so we should not
add new packages that depend on it.

Apparently, LMMS can be built with Qt 5:

https://github.com/LMMS/lmms/wiki/Compiling-lmms#using-qt5

Can you try it and let us know how it goes?


Ok, I looked into this. Qt5 is supported only in the newest development
version of lmms, but what I packaged is the latest stable release.

I will make a note of this for when I update the package, but what can
we do for the mean time? Accept this as is? Package the release
candidiate? Or just wait for the next stable release of lmms before
adding this to guix?

To be honest, the RC looks like it has some cool new features, so I
will probably be building it for myself either way. Also, lmms is on
a pretty slow release cycle. The last stable was 2015, RC-1 was
early 2016, and RC-2 was Jan 2017. So maybe if it seems stable enough
when I build it I can package the RC-2. I could do one for each if that
makes sense, kind of like the guile and guile-next packages.
What do you think? lmms and lmms-rc?

-Rodger