Re: Article: Playing with Guix REPL from scratch

[swedebugia]

"Ludovic Courtès"  skrev: (5 januari 2019 18:37:10 CET)
>Hello swedebugia,
>
>Sorry for the late reply!
>
>swedebugia  skribis:
>
>> Today I wrote this draft blog post while playing around:
>>
>> Playing with Guix REPL from scratch
>
>That sounds like a great topic for a blog post!
>
>I would suggest adding a bit of context: what does “REPL” mean? what
>are
>the possible use cases? how does it differ from what other package
>managers provide? etc.
>
>> This is a small example of how to quickly get an environment to play
>> with Guix in guile.
>>
>> First setup your environment.
>>
>> I choose a x86_64 PC and booted up the installer from an usb stick.
>
>That’s an option, but you could mention that one can install Guix or
>GuixSD and run ‘guix repl’ from there.
>
>> This is a nice environment because it already is running GuixSD in a
>> console and you have are in Guix land with 8500 packages at your
>> fingertips.
>>
>> I started by installing a sensible array of packages:
>>
>>  $ guix package -i emacs-no-x lynx git-minimal guile-readline
>> guile-colorized emacs-paredit nss-certs
>>
>> To set this up as intended then run:
>>
>>  $ export
>>
>GUILE_LOAD_PATH=$HOME/.guix-profile/share/guile/site/2.2:/run/current-system/profile/share/guile/site/2.2
>>  $ export SSL_CERT_DIR=/root/.guix-profile/etc/ssl/certs
>
>I don’t think GUILE_LOAD_PATH is needed if you use ‘guix repl’.
>
>> Now fire up the guix repl with
>>
>>  $guix repl
>>
>> Load e.g. this to start hacking on package records:
>>
>> (use-modules
>>  (guix packages)
>>  (guix import utils)
>>  (gnu)
>>  (gnu packages sync))
>
>I’d suggest (guix) instead of (guix packages).
>
>> Now you can start hacking on all packages in sync.scm using Scheme
>> procedures from (gnu packages) (see the source of this module for
>> details or guess and press tab)
>>
>> E.g. (package shows this list of nice procedures
>availiable:
>> package
>> package->cross-derivation
>
>[...]
>
>> What can we do with this you might ask?
>
>You could show ,describe and ,apropos at the REPL:
>
>--8<---cut here---start->8---
>scheme@(guix-user)> ,describe package-derivation
>Return the  object of PACKAGE for SYSTEM.
>scheme@(guix-user)> ,a origin
>(guix packages): origin-patch-guile
>(guix packages): origin-method
>(guix packages): origin-patch-inputs
>(guix packages): origin-patch-flags
>(guix packages): origin-patches
>(guix packages): origin->derivation #derivation
>(origin #:optional system)>
>(guix packages): origin-snippet
>(guix packages): origin-modules
>(guix packages): origin-actual-file-name#origin-actual-file-name (origin)>
>(guix packages): origin
>(guix packages): origin-uri
>(guix packages): origin?
>(guix packages): origin-file-name
>(guix packages): origin-sha256
>--8<---cut here---end--->8---
>
>Though for some reason ,a doesn’t seem to work if you only use (guix),
>hmm…
>
>> scheme@(guile-user)> (define snakes
>>(fold-packages
>> (lambda (package lst)
>>  (if (string-prefix? "python"
>>   (package-name package))
>> (cons (origin-url package) lst)
>>   lst))
>>  '()))
>
>‘origin-url’ does not exist.  :-)  Make sure all the examples work so
>that users are not disappointed.  It may be worth explaining how
>‘fold-packages’ works as it may be the first encounter of ‘fold’ for
>someone not familiar with functional programming.
>
>Perhaps you could give another examples or two such as using
>‘package-derivation’ and ‘build-derivations’, or integration with (guix
>swh) as sketched at
>,
>or uses of ‘package-input-rewriting’, just to give a feel that it’s
>actually useful.  ;-)
>
>For the blog we write text in Markdown and there’s markup to get proper
>syntax highlighting for Scheme.  See the .md files at
>.
>
>Also I think it’s a good idea to add links to the relevant parts of the
>Guix and Guile manuals so that interested readers know where to find
>more info about each topic.
>
>Thanks for working on it!
>
>Ludo’.

Wow, thanks a lot for the suggestions. I did not know about apropos and I found 
the tab-completion by accident. 
I still got much to learn about the repl which seem to have all kinds of neat 
(a bit hidden) eggs 

An ideas pop to mind:
1) the repl could hint at startup about some feature

A question too:
2) are there ways to hinder gnutls from flooding the ,trace of e.g. import 
commands?
-- 
Sent from my p≡p for Android.


pEpkey.asc
Description: application/pgp-keys

Re: Docker and singularity containers

[Mike Gerwitz]

On Sat, Jan 05, 2019 at 17:14:31 +0100, Ricardo Wurmus wrote:
> That’s easier: with “guix pack”.  We would create a Cuirass job to build
> a pack regularly.  We’d need to add support for hooks to publish the
> generated pack on DockerHub, though we could just as well host them
> ourselves.

Last I checked, an account couldn't be registered on DockerHub without
running non-free JS.  Here's a thread on emacs-devel where I raised this
issue:

  https://lists.gnu.org/archive/html/emacs-devel/2017-02/msg00114.html

But I haven't verified this since.  After an account is registered,
though, their APIs can be used without having to use DockerHub's web
interface.

-- 
Mike Gerwitz
Free Software Hacker+Activist | GNU Maintainer & Volunteer
GPG: D6E9 B930 028A 6C38 F43B  2388 FEF6 3574 5E6F 6D05
https://mikegerwitz.com


signature.asc
Description: PGP signature

Re: Merging ‘wip-newt-installer’ in master?

[Ludovic Courtès]

Hi Mathieu,

Mathieu Othacehe  skribis:

> I pushed a few commits to the branch. All main features are now
> implemented. The only important stuff missing (in my opinion) is the
> encryption support during partitioning (as well as RAID and LVM I
> guess). I also took most of Thorsten remarks into account.
>
> I'll keep tinkering the branch in the next few days, but it is now
> possible to have a complete experience and install a real system!

Sorry for the long delay!

I gave it a try with ‘guix system vm gnu/system/install.scm’ and overall
it looks really nice to me!  A few random things:

  • On the first screen, should “Graphical install” come first?

  • Should the choice of a locale come before the welcome screen?

  • Should the keyboard layout default to “English (US)” rather than
“Afghani”?  Likewise for the layout variant.

  • s/Ok/OK/  :-)

  • For the partition encryption passphrase, we should probably ask for
confirmation, no?

  • There’s a debug dialog box called “user-partitions” that pops up
after hitting “Ok” on the partition choice.  :-)

  • In the “Desktop environments” screen, we should we allow for no
desktop environments, and then (or before?) have a second screen
where users can choose between a headless server kind of install or
a lightweight-X11-desktop kind of install?

  • At the end, after seeing the complete OS definition, I got “execlp:
cryptsetup: Operation not permitted” written at the top of the
“Congratulations” screen, and it looks like nothing was actually
installed (I had chosen the encrypted-root setup).  After that I
got:

  ERROR: pty: failed to exec child /gnu/store/…-installer: Operation not 
permitted (exec_child() in src/pty.c:299)

in a loop and the VM became unusable.  Not sure what happened!

So what are the next steps?  IMO we should consider merging real soon
and get people to test.  WDYT?

Thanks!

Ludo’.

Re: Learning the match-syntax...

[Ricardo Wurmus]

Hi swedebugia,

> (define (metadata-ref file lookup)
>   ^ 2 arguments
>   (fold (lambda (record acc)
>   ^2 formals, why the acc?

“fold” is a higher order function that takes a two-argument procedure
(the lambda here), an initial value, and a list to fold over.

The procedure that is provided as the first argument is applied to each
element of the list *and* is given the current value of the
so-called accumulator (here bound to “acc”).

The accumulator first gets the initial value; in this case that’s #F.
The return value of the procedure is the new value of the accumulator.
The body is essentially just an “if” expression: the new value of the
accumulator is either whatever the “match” expression returns or it is
the unchanged value “acc”.

But nothing of this has anything to do with “match”.  Let’s look at the
match expressions.

>   (match record
>  ^input
> ((record key val)
>^match "record" "key" "val" in a list?

This is really destructuring the value of “record”, assuming that it is
a three element list, and binding each of the elements to a variable.
Try this:

--8<---cut here---start->8---
(use-modules (ice-9 match))
(match '(hello world how are you ?)
  ((greeting object . question)
   (length question)))
--8<---cut here---end--->8---

This will match the quoted expression against a pattern that binds a
list with at least two values to the variables “greeting”, “object”, and
“question” (for everything after the first two values).

>  (match val
>^input
>  (('list-pat . stuff) stuff)
>  ^ if 'list-pat return stuff

If (eq? (car val) 'list-pat) then return (cdr val), even if that might
be the empty list.

>  (('string-pat stuff) stuff)
>  ^ if 'string-pat return stuff

This matches if “val” is a two element list where the car is
'string-pat.  It returns the cadr of “val” (cadr = car of the cdr).

>  (('multiline-string stuff) stuff)

Similar here.

>  (('dict records ...) records))
> ^if 'dict return first record

Close.  It returns all the values following 'dict.  This is the same as
if the pattern ('dict . records) had been used.

Hope this helps!

--
Ricardo

Re: GNU Guix Days before FOSDEM

[Ludovic Courtès]

Hello,

Pjotr Prins  skribis:

> We have an exciting program for the minimalism devroom at FOSDEM, see 
>
>   https://fosdem.org/2019/schedule/track/minimalistic_languages/
>
> We also have two GNU Guix days before FOSDEM. The idea is to break out
> into working groups during those two days. I have added a few ideas
> here:
>
>   https://libreplanet.org/wiki/Group:Guix/FOSDEM2019#Programme
>
> Feel free to add your favourite topics! If you want to attend be sure
> to add your name. We can't allow more than 40 people.

Awesome, looking forward to this year’s FOSDEM!

Ludo’.

Re: Some utility functions

[Ludovic Courtès]

Hi Gábor,

Gábor Boskovits  skribis:

> I am not sure if I am duplicating functionality here, and also where
> these should belong, so I will send them here for discussion.

Thanks for sharing!  As Alex notes, some of these procedures are
more or less available in (guix build utils):

> (define (rm-recursive dir)

delete-file-recursively

> (define (check-header file header)

file-header-match

> (define (reset-zip-timestamps dir)
>   "Resets the timestamps of all zip achives under DIR."
>   (for-each repack-zip
>   (find-files dir ".*.(zip|jar|diz)$")))

That we don’t have (there’s ‘reset-gzip-timestamp’, with a ‘g’.)

How do we deal with that currently in Java packages?

Thanks,
Ludo’.

Learning the match-syntax...

[swedebugia]

Saluton Ludo' :)

I write this to you for no other reason than I like the code your write
and would love to learn more.

If you don't have time/energy just let me know and I will ask Pierre or
somebody else. :)

On 2019-01-05 18:39, Ludovic Courtès wrote:
> One last thing:
> 
>> +(define (check-source-unstable-tarball package)
>> +  "Emit a warning if PACKAGE's source is an autogenerated tarball."
>> +  (define (check-source-uri uri)
>> +(when (and (string=? (uri-host (string->uri uri)) "github.com")
>> +   (string=? (third (split-and-decode-uri-path
>> +   (uri-path (string->uri uri
>> + "archive"))
> 
> ‘third’ could fail badly if the list has fewer elements, so I’d suggest
> writing it something like:
> 
>   (when (and …
>  (match (split-and-decode-uri-path …)
>((_ _ "archive" _ ...) #t)
>(_ #f)))
>  …)

This is an elegant rewrite to return a boolean #f in case the URL is bad
in some way.

I'm trying very hard to learn the guile match-syntax.

To make sure I understand the above I would like to explain it and you
can verify that I got it right. Ok?

>  (match (split-and-decode-uri-path …) <- this is the input
>((_ _ "archive" _ ...) #t)
   ^ ^ ^ =third  ^   ^return true if the clause
match
 ^fourth & more
   ^ ^ = anything twice 
>(_ #f)))
  ^ =the general case =else return #f.

Correct?

This is a more complicated (nested) match example from Juliens opam
importer which I find is an elegant functional way to find what we need:

(define (metadata-ref file lookup)
  (fold (lambda (record acc)
  (match record
((record key val)
 (if (equal? key lookup)
   (match val
 (('list-pat . stuff) stuff)
 (('string-pat stuff) stuff)
 (('multiline-string stuff) stuff)
 (('dict records ...) records))
   acc
#f file))

(define (metadata-ref file lookup)
  ^ 2 arguments
  (fold (lambda (record acc)
  ^2 formals, why the acc?
  (match record
 ^input
((record key val)
   ^match "record" "key" "val" in a list?
 (if (equal? key lookup)
  ^ we continue if the key is right
   (match val
   ^input
 (('list-pat . stuff) stuff)
 ^ if 'list-pat return stuff
 (('string-pat stuff) stuff)
 ^ if 'string-pat return stuff
 (('multiline-string stuff) stuff)
 (('dict records ...) records))
^if 'dict return first record
   acc
^ this is the else (what is this good for?)
#f file))
 ^ input to fold
 ^ no initial in the fold

If I understood this correctly I hope I will be able to get something
like this to work in the quicklisp importer :)

-- 
Cheers 
Swedebugia

Re: GDM future work

[Ludovic Courtès]

Hi Timothy!

Timothy Sample  skribis:

> I have been using GDM on GuixSD for the past few days, and I am quite
> happy with it.  A few patches that make it usable just landed on
> master.

Nice!

> The main issue is the way that GDM launches the session bus (the
> instance of D-Bus that manages the session).  It launches it from a
> clean environment that has little more than what PAM gives from
> “/etc/environment” (and “~/.pam_environment”, if it exists).  The result
> is that D-Bus can’t find any services, because it doesn’t have
> “XDG_DATA_DIRS” set.
>
> Currently, this is solved by patching GDM to thread “XDG_DATA_DIRS” into
> the process the launches D-Bus, but that’s not great.  There are at
> least two better options.
>
> (1) Extend the PAM environment service so that it puts important
> environment variables for D-Bus in “/etc/environment”.  This is easy to
> do, and fits pretty naturally with the way that GDM works.
>
> (2) Set up a wrapper script for D-Bus like the wrapper script we
> currently use for X.  This way, we could very precisely set up where the
> session bus looks for system and user service files.  This seems to be
> more like “the Guix way”, but it would mean threading a
> “GDM_DBUS_LAUNCH” environment variable through the GDM code (like we
> currently do with “GDM_X_SERVER”).

Option #2 looks reasonable to me (for the reasons you wrote, “static
binding” and all.)

> Besides these two options, I get tempted to think even bigger.  We could
> replace a lot of the GDM session initialization code with our own code,
> and then if we only had per-session Shepherd instances….  That’s
> probably too big for right now.  :)

Heh, sounds tempting… once 1.0 is out!  :-)

> Besides this, there are few straight-forward things to do.  We need to
> make a “libgdm” package that does not depend on “gnome-shell” [1].  It
> would be nice to fill out the config record and get rid of the opaque
> configuration text file.  We need documentation for GDM in the manual.
> Finally, I already miss the Guix logo from SLiM, so even if it is not
> the default, I would like a Guix theme to be available.  :)
>
> I will chip away at these as I have time, but of course anyone is
> welcome to jump on them if I’m too slow.

Cool, I’d be happy to test it, let us know when you’d like to get test
feedback!

Thanks for working on it!

Ludo’.

Re: 01/01: scripts: refresh: Allow searching recursively.

[swedebugia]

On 2019-01-05 18:43, Ludovic Courtès wrote:
> Efraim Flashner  skribis:
> 
>> On Tue, Dec 25, 2018 at 04:05:11PM +0100, Ludovic Courtès wrote:
>>> Hello!
>>> 
>>> guix-comm...@gnu.org skribis:
>>> 
>>> > efraim pushed a commit to branch master
>>> > in repository guix.
>>> >
>>> > commit c39491829a0c1d870f8133b8f7a699152fc71503
>>> > Author: Efraim Flashner 
>>> > Date:   Wed Dec 19 22:08:18 2018 +0200
>>> >
>>> > scripts: refresh: Allow searching recursively.
>>> >
>>> > * guix/scripts/refresh.scm (refresh-recursive, list-transitive): New
>>> > procedures.
>>> > (show-help): Document it.
>>> > (guix-refresh): Add flags and checks for new options.
>>> > * doc/guix.texi (Invoking guix refresh): Document new options.
>>> 
>>> Nice work!
>>> 
>>> > +@item --list-transitive
>>> > +List all the packages which one or more packages depend upon.
>>> 
>>> What about ‘--list-dependencies’, for clarity and symmetry with
>>> ‘--list-dependents’?
>>> 
>> 
>> It was originally '--list-recursive' but Bavier suggested
>> '--list-transitive' so it would match 'guix build --sources=transitive'
>> 
>> If it's too close to '--list-dependents' then I'm worried people could
>> look at it and ask 'packages FOO is dependent on or packages that are
>> dependent on FOO?'
> 
> Good point.  I do feel like ‘--list-dependencies’ is clearer though.
> With ‘list-transitive’, since “transitive” is an adjective, I first
> wondered: transitive what?
> 
> What do people think?

I pondered this a bit. 

What about evolving our terminology as if we talk about the graph
produced by "guix graph"?

That means we have only 2 directions. Upwards: 'packages that are
dependent on FOO'
Downwards: 'packages FOO is dependent on'

This could give us the following terms:
X is an upwards dependency to Y.
FOO is a downward dependency of BAR.
=>
--list-upwards-dependencies
--list-downwards-dependencies

Furthermore we could create words to describe packages with many/few
dependencies:

Package X is a heavy root with 120 upward links.

We could define a scale and make our commands output it consistently:

- light root <=50 upward links
- medium root >50<=100 upward links
- heavy root >100<=500 upward links
- very heavy root >500<=1000 upward links
- extremely heavy root >1000 upward links

(The numbers above are just an example)

With npm-packages we could say:
Package X is a heavy root with 3 versions in use.
Package Y is a light root with only the latest in use.

(In npm a package can appear multiple times as dependency to
dependencies and sometimes in different versions meaning we have to
package it multiple versions of some packages.)

Thoughts?

-- 
Cheers
Swedebugia

Re: Trustworthiness of build farms (was Re: CDN performance)

[jeremiah]

> In other words, it's anecdotal.
True, it definitely was not a formal proof just data based upon real
world development with large teams of programmers and formal
specifications for correct behavior.

> Obviously, the flaw in this argument is that there exist much more
> efficient ways to add numbers than counting beads.  A claim of
> complexity doesn't mean anything unless you can prove that it's a lower
> bound.
I don't deny that there are possibly lower bounds for the work, rather
that is the observed values from large teams doing that development are
what I have available to share.

> There's a reason that I followed my call for bug-free compilers with the
> claim: "In practice, this requires provably correct compilers."  I wrote
> that because I know that it's the only known practical way to do it for
> non-trivial languages.
Perfection is a road, not a destination.
One requires a "provabily correct compiler" to bootstrap a "provabily
correct compiler". A step completely skipped.

> Interesting.  I hadn't heard of those.  Can you cite the details?
One the most obvious is the float size definition and rounding behavior
on x86 hardware. The C standard requires rounding towards even, IEEE
only supports rounding towards infinity, negative infinity and zero. The
C standard allows floats to be expanded (to 80bits) but IEEE doesn't as
it can change the stability of some algorithms.


> Right, which shows the problems with depending on unverified components,
> but CompCert is no longer the state of the art in this regard.
It goes deeper than that.

> In contrast, the CakeML compiler not only produces raw machine code,
> moreover the proofs apply to the raw machine code of the CakeML compiler
> itself.  As a result, the only trusted specifications are those of the
> source language and of the underlying machine code behavior (for the
> subset of instructions that are actually generated).
So either CakeML must refuse to compile valid code or will generate
invalid binaries or both.

> I agree that IEEE floating point (and more generally inexact arithmetic)
> is a problem, but a great many useful programs can be written without
> using them, including most (if not all) of the programs that are most
> important for us to trust.  Operating systems, compilers, editors, and
> communication tools such as chat clients and mail readers, have no need
> for inexact arithmetic.  These are the programs I care most about.
Aside from the compilers that janneke and I have written, no other real
world compilers don't depend upon floating point; why do you think
janneke spent so many hours adding floating point to Mescc?
Try to build Linux without floating point support, it can't be done.
To to build emacs or vim without floating point support in your
compiler.

The reason is simple: Math libraries abuse it for performance and
performance is the only metric most people care about.

The Countless sins of our Industry exit because of those cursed words.

> Why do you include garbage collection in this list?  I consider garbage
> collection to be a _requirement_ for human model first behavior.  Do you
> consider it a hindrance?  Also, multiple verified garbage collectors
> already exist, e.g. those used in the runtimes of CakeML and Jitawa.
Find me one Enterprise grade Operating system that isn't a Lisp machine
that includes garbage collection at the native level.

> I think it's too ambitious to target non-programmers, because they do
> not have the required skills to understand the behavior of complex
> programs, regardless of what language is used.  They could perhaps
> understand toy programs, but that's not useful for helping them evaluate
> the trustworthiness of the computing tools they actually use, which is
> what I'm interested in.
Fair preference to have

> Anyway, what language(s) would you consider to be superior to ML or a
> subset of Scheme, based on the goal of human model first behavior?
As much as I hate to admit it but C# and Go tend to be far easier for
most people new to programming. Not that I would ever claim they are
superior languages in any technical sense.

> Would you consider your low-level macro languages to be better suited to
> this task?
Oh no, it exists solely to create a floor for bootstrapping ease and
simplify the problem of cross-platform bootstrap verification.

> I might agree that such simple assembly-like languages are more
> straightforward for understanding the behavior of toy programs, where
> one can keep all of the moving parts in one's head.  However, I would
> argue that those desirable properties of assembly-like languages do not
> scale to larger programs.
A self-hosting C compiler isn't exactly a toy program and if you read
it's code, you'll quickly discover there is no need to keep very much in
one's head at all.

It's real weakness is it's type system and lack of runtime.

One must remember a language's greatest strength is also it's greatest
weakness as well. Every desired 

Re: keep spinning even without new line

[Ludovic Courtès]

Hi,

Ricardo Wurmus  skribis:

> Ricardo Wurmus  writes:
>
>> Hi Guix,
>>
>> when using “guix package -i” the build log lines are replaced with a
>> spinner character.  In some cases, the build log does not produce new
>> lines for a long time, so that the spinner appears to be stuck.
>>
>> What do you think of advancing the spinner even when the build log is
>> not verbose enough to trigger the display of the next character?  How
>> can this be accomplished?
>
> One way to accomplish this is to generate periodic “(build-log
> heartbeat)” events, so that “print-build-event” in (guix status) only
> needs to advance the spinner when the last event was a build-log event.
>
> Currently, events are produced only by “build-event-output-port”, which
> generates them when processing build trace strings sent by the daemon.
> I don’t really want to change the daemon to intersperse the actual build
> output with heartbeat traces, so maybe a timer should generate these
> events in “build-event-output-port” or even earlier in “process-stderr”.
>
> “process-stderr” is probably too low-level, and there’s a chance that
> injecting output there would corrupt the output sent by the daemon.

I wonder if we could use Guile 2.2’s suspendable ports to deal with this
case (info "(guile) Non-Blocking I/O").  To avoid global effects, I
think we could explicitly use the (ice-9 suspendable-ports) procedures
in ‘process-stderr’ and the caller in (guix status) maybe would set a
‘current-read-waiter’.

Thoughts?

Ludo’.

Re: Missing fonts issue with GNU Icecat

[Ludovic Courtès]

Hi Ricardo,

Ricardo Wurmus  skribis:

>> Resolved by applying this advice (which is output when running `guix
>> package -i pango` explicitly, but not when pango is installed as a
>> dependency -- or I missed it):
>>
>> ```
>> The following environment variable definitions may be needed:
>>   export
>> XDG_DATA_DIRS="$HOME/.guix-profile/share${XDG_DATA_DIRS:+:}$XDG_DATA_DIRS"
>>   export
>> GIO_EXTRA_MODULES="$HOME/.guix-profile/lib/gio/modules${GIO_EXTRA_MODULES:+:}$GIO_EXTRA_MODULES"
>> ```
>
> I’m glad you figured this out.  I wonder if this means that we should
> change the icecat package to set these variables (e.g. by adding a shell
> wrapper).

This is what ‘glib-or-gtk-build-system’ does.  It would be worth trying
to change IceCat to use that build system.

Ludo’.

Re: Plan for Guix security (was Re: Long term plan for GuixSD security: microkernels, ocap, RISC-V support)

[Ludovic Courtès]

Hello,

Marius Bakke  skribis:

> Alex Vong  writes:
>
>> Besides, I remember we have discuss about hardening before. Should I
>> start a new hardening branch? (although I don't time to work on it right
>> now). I think this is something we can do now.
>>
>> My idea is to create a new guix module (guix build hardening) which
>> should contains various build flags. Then we should modifiy each build
>> system to import from this new module and fix any build error caused by
>> it. We can ask the build farm to evaluate this new branch, right?
>>
>>
>> What do you think?
>
> Thank you for taking the initiative!  This sounds great to me.  I
> imagine the build systems could get an argument along the lines of
> #:hardening-flags '(pie fortify stack-protector ...).
>
> For gnu-build-system, I suppose we'd build up CFLAGS, LDFLAGS and
> friends?  We'll also have to modify all packages that override those
> variables.

Sounds like a plan.  I think Alex proposed something along these lines
long ago.

The difficulty will lie in finding a way to pass those flags reliably
through the build system…

Ludo’.

Re: Better names for Guix versions from git?

[Ludovic Courtès]

Hello,

Marius Bakke  skribis:

> I like the "git describe" format:
>
> $ git describe
> v0.16.0-414-ge99d036828

I’d love that.  We just need to add the missing bindings to Guile-Git.
Hint hint.  ;-)

As for the date, note that ‘guix describe’ displays the generation’s
date already.

Thanks,
Ludo’.

Re: 01/01: scripts: refresh: Allow searching recursively.

[Ludovic Courtès]

Efraim Flashner  skribis:

> On Tue, Dec 25, 2018 at 04:05:11PM +0100, Ludovic Courtès wrote:
>> Hello!
>> 
>> guix-comm...@gnu.org skribis:
>> 
>> > efraim pushed a commit to branch master
>> > in repository guix.
>> >
>> > commit c39491829a0c1d870f8133b8f7a699152fc71503
>> > Author: Efraim Flashner 
>> > Date:   Wed Dec 19 22:08:18 2018 +0200
>> >
>> > scripts: refresh: Allow searching recursively.
>> > 
>> > * guix/scripts/refresh.scm (refresh-recursive, list-transitive): New
>> > procedures.
>> > (show-help): Document it.
>> > (guix-refresh): Add flags and checks for new options.
>> > * doc/guix.texi (Invoking guix refresh): Document new options.
>> 
>> Nice work!
>> 
>> > +@item --list-transitive
>> > +List all the packages which one or more packages depend upon.
>> 
>> What about ‘--list-dependencies’, for clarity and symmetry with
>> ‘--list-dependents’?
>> 
>
> It was originally '--list-recursive' but Bavier suggested
> '--list-transitive' so it would match 'guix build --sources=transitive'
>
> If it's too close to '--list-dependents' then I'm worried people could
> look at it and ask 'packages FOO is dependent on or packages that are
> dependent on FOO?'

Good point.  I do feel like ‘--list-dependencies’ is clearer though.
With ‘list-transitive’, since “transitive” is an adjective, I first
wondered: transitive what?

What do people think?

Thanks,
Ludo’.

Re: `guix lint' warn of GitHub autogenerated source tarballs

[Ludovic Courtès]

Hello!

Efraim Flashner  skribis:

> From dcd8b207f932289cb3b35720af45f49f849b7c27 Mon Sep 17 00:00:00 2001
> From: Efraim Flashner 
> Date: Tue, 25 Dec 2018 16:29:12 +0200
> Subject: [PATCH] lint: Add checker for unstable tarballs.
>
> * guix/scripts/lint.scm (check-source-unstable-tarball): New procedure.
> (%checkers): Add it.
> * tests/lint.scm ("source-unstable-tarball", "source-unstable-tarball:
> source #f", "source-unstable-tarball: valid", "source-unstable-tarball:
> package named archive", "source-unstable-tarball: not-github",
> "source-unstable-tarball: git-fetch"): New tests.

One last thing:

> +(define (check-source-unstable-tarball package)
> +  "Emit a warning if PACKAGE's source is an autogenerated tarball."
> +  (define (check-source-uri uri)
> +(when (and (string=? (uri-host (string->uri uri)) "github.com")
> +   (string=? (third (split-and-decode-uri-path
> +   (uri-path (string->uri uri
> + "archive"))

‘third’ could fail badly if the list has fewer elements, so I’d suggest
writing it something like:

  (when (and …
 (match (split-and-decode-uri-path …)
   ((_ _ "archive" _ ...) #t)
   (_ #f)))
 …)

Otherwise LGTM, thank you!

Ludo’.

Re: Article: Playing with Guix REPL from scratch

[Ludovic Courtès]

Hello swedebugia,

Sorry for the late reply!

swedebugia  skribis:

> Today I wrote this draft blog post while playing around:
>
> Playing with Guix REPL from scratch

That sounds like a great topic for a blog post!

I would suggest adding a bit of context: what does “REPL” mean? what are
the possible use cases? how does it differ from what other package
managers provide? etc.

> This is a small example of how to quickly get an environment to play
> with Guix in guile.
>
> First setup your environment.
>
> I choose a x86_64 PC and booted up the installer from an usb stick.

That’s an option, but you could mention that one can install Guix or
GuixSD and run ‘guix repl’ from there.

> This is a nice environment because it already is running GuixSD in a
> console and you have are in Guix land with 8500 packages at your
> fingertips.
>
> I started by installing a sensible array of packages:
>
>  $ guix package -i emacs-no-x lynx git-minimal guile-readline
> guile-colorized emacs-paredit nss-certs
>
> To set this up as intended then run:
>
>  $ export
> GUILE_LOAD_PATH=$HOME/.guix-profile/share/guile/site/2.2:/run/current-system/profile/share/guile/site/2.2
>  $ export SSL_CERT_DIR=/root/.guix-profile/etc/ssl/certs

I don’t think GUILE_LOAD_PATH is needed if you use ‘guix repl’.

> Now fire up the guix repl with
>
>  $guix repl
>
> Load e.g. this to start hacking on package records:
>
> (use-modules
>   (guix packages)
>   (guix import utils)
>   (gnu)
>   (gnu packages sync))

I’d suggest (guix) instead of (guix packages).

> Now you can start hacking on all packages in sync.scm using Scheme
> procedures from (gnu packages) (see the source of this module for
> details or guess and press tab)
>
> E.g. (package shows this list of nice procedures availiable:
> package
> package->cross-derivation

[...]

> What can we do with this you might ask?

You could show ,describe and ,apropos at the REPL:

--8<---cut here---start->8---
scheme@(guix-user)> ,describe package-derivation
Return the  object of PACKAGE for SYSTEM.
scheme@(guix-user)> ,a origin
(guix packages): origin-patch-guile
(guix packages): origin-method
(guix packages): origin-patch-inputs
(guix packages): origin-patch-flags
(guix packages): origin-patches
(guix packages): origin->derivation #derivation (origin 
#:optional system)>
(guix packages): origin-snippet
(guix packages): origin-modules
(guix packages): origin-actual-file-name#
(guix packages): origin
(guix packages): origin-uri
(guix packages): origin?
(guix packages): origin-file-name
(guix packages): origin-sha256
--8<---cut here---end--->8---

Though for some reason ,a doesn’t seem to work if you only use (guix),
hmm…

> scheme@(guile-user)> (define snakes
>(fold-packages
> (lambda (package lst)
>   (if (string-prefix? "python"
>   (package-name package))
>  (cons (origin-url package) lst)
>lst))
>   '()))

‘origin-url’ does not exist.  :-)  Make sure all the examples work so
that users are not disappointed.  It may be worth explaining how
‘fold-packages’ works as it may be the first encounter of ‘fold’ for
someone not familiar with functional programming.

Perhaps you could give another examples or two such as using
‘package-derivation’ and ‘build-derivations’, or integration with (guix
swh) as sketched at
,
or uses of ‘package-input-rewriting’, just to give a feel that it’s
actually useful.  ;-)

For the blog we write text in Markdown and there’s markup to get proper
syntax highlighting for Scheme.  See the .md files at
.

Also I think it’s a good idea to add links to the relevant parts of the
Guix and Guile manuals so that interested readers know where to find
more info about each topic.

Thanks for working on it!

Ludo’.

Re: Trustworthiness of build farms (was Re: CDN performance)

[Mark H Weaver]

Hi Jeremiah,

jerem...@pdp10.guru writes:

 To truly solve that problem, we need bug-free compilers.
>>> Impossible for all but the simplest of languages as the complexity of
>>> implementing a compiler/assembler/interpreter is ln(c)+a but the
>>> complexity of implementing a bug-free compiler/assembler/interpreter
>>> is (e^(c))! - a. Where a is the complexity cost of supporting it's
>>> host architecture.
>>
>> Where are you getting those complexity expressions from?
> Approximation of developer effort spent on single pass workflows and
> bugfree libraries in the State of Michigan Welfware Eligibility System
> extracted from it's ClearCase commit history. (Thank god, I finally got
> them to convert to git after 3 years of wailing and gnashing of teeth)
>
>> Can you cite references to back them up?
> I can site the numbers I used to generate those approximate complexity 
> equations
>
>> If not, can you explain how you arrived at them?
> Simple graphing and curve matching of collected data.

In other words, it's anecdotal.  This is analogous to saying:

  "I once saw someone adding numbers A and B by counting beads, and
  observed that the time required was |A| + |B|.  From this I will
  conclude that the complexity of adding numbers is |A| + |B|, and
  therefore that adding numbers is impossible for all but the smallest
  numbers."

Obviously, the flaw in this argument is that there exist much more
efficient ways to add numbers than counting beads.  A claim of
complexity doesn't mean anything unless you can prove that it's a lower
bound.

There's a reason that I followed my call for bug-free compilers with the
claim: "In practice, this requires provably correct compilers."  I wrote
that because I know that it's the only known practical way to do it for
non-trivial languages.

>> If you're referring to the bugs found in CompCert, the ones I know about
>> were actually bugs in the unverified parts of the toolchain.
> I was referring to the bugs in the verified parts in regards to C's
> undefined behavior.

Interesting.  I hadn't heard of those.  Can you cite the details?

>> In the past, its frontend was unverified, and several bugs were found there.
>> Even today, it produces assembly code, and depends on an unverified
>> assembler and linker.
> Which depending on if the compiler has been formally proven to only
> output valid assembly (no 33bit offset loads) then that is less of a
> concern.
> (Let us just hope the assembler doesn't arbitrarily choose 8bit
> immediates for performance reasons when given a 32bit int)

Right, which shows the problems with depending on unverified components,
but CompCert is no longer the state of the art in this regard.  In
contrast, the CakeML compiler not only produces raw machine code,
moreover the proofs apply to the raw machine code of the CakeML compiler
itself.  As a result, the only trusted specifications are those of the
source language and of the underlying machine code behavior (for the
subset of instructions that are actually generated).

>> Bugs can also exist in the specifications themselves, of course.
> The most important class of bugs indeed
>
>> I'm not sure what "and human model first behavior" means, but if you
>> mean that the semantics of languages should strive to match what a human
>> would naturally expect, avoiding surprising or unintuitive behavior, I
>> certainly agree.
> That is exactly what I mean. The problem is ultimately do be useful
> things one has to support things that violate that in very terriable
> ways (like support IEEE floating point,

I agree that IEEE floating point (and more generally inexact arithmetic)
is a problem, but a great many useful programs can be written without
using them, including most (if not all) of the programs that are most
important for us to trust.  Operating systems, compilers, editors, and
communication tools such as chat clients and mail readers, have no need
for inexact arithmetic.  These are the programs I care most about.

> disable garbage collection, etc).

Why do you include garbage collection in this list?  I consider garbage
collection to be a _requirement_ for human model first behavior.  Do you
consider it a hindrance?  Also, multiple verified garbage collectors
already exist, e.g. those used in the runtimes of CakeML and Jitawa.

>> I consider Standard ML, and some subsets of Scheme and
>> Lisp, to be such languages
> They certainly do have wonderful properties but I wouldn't say they
> qualify as matching the human model first behavior requirement (easy to
> verify by doing the 50 non-programmers first hand test)

I think it's too ambitious to target non-programmers, because they do
not have the required skills to understand the behavior of complex
programs, regardless of what language is used.  They could perhaps
understand toy programs, but that's not useful for helping them evaluate
the trustworthiness of the computing tools they actually use, which is
what I'm interested in.

Anyway, 

Re: New Gash build Bash without Bash, Coreutils, and a few others

[Ludovic Courtès]

Hi Timothy,

Timothy Sample  skribis:

> I am very pleased to announce that Gash (having absorbed Geesh) is now
> capable of building Bash without Bash, Coreutils, Grep, Sed, or Tar.
> That is, Gash provides alternatives, written in Scheme, to all the
> utilities needed by the “gnu-build-system” that are normally provided by
> those packages.  Note, however, that this work is still very much at the
> “proof of concept” level.

Woohoo!  \o/  It’s one of these things we’ve been talking about for some
time and it’s exciting to see it come to fruition.

Also, thumbs up to the two of you for coming up with a merger plan.

Thank you, and best bootstrapping wishes for the new year!

Ludo’.

Re: improve installation instructions

[Kyle Meyer]

Ricardo Wurmus  writes:

> Hey,
>
> I just installed Guix as a package manager on an aarch64 box.  The
> manual makes it a little difficult to perform all these steps, because
> the commands cannot be easily copied.  We do have the shell script, but
> the manual mentions it only in passing – as a user I skipped over the
> introduction and went straight to step 1, right past the script.

I've installed Guix on a foreign distro a few times and didn't realize
that that script existed, so I must have skipped past it each time.

> What do you think about mentioning the script in the Installation
> section and only asking users to look in the subsections for details?

Looks good.  I think it would certainly help hasty readers like me.

Thanks.

-- 
Kyle

Re: How I got stuck (and ways to resolve)

[Ludovic Courtès]

Hello!

Laura Lazzati  skribis:

> Thank you both for sharing your experience :)

+1!

I’m late to the party but I think your message was certainly insightful
to many of us.  Even with years of experience one is never done learning
new tricks!

Thanks,
Ludo’.

Re: Brain storming cool Guix features

[Ricardo Wurmus]

Hi Joshua,

> Ricardo Wurmus  writes:
>
>> Joshua Branson  writes:
>>
>>> I had some cool ideas/features for things that GuixSD could potentially
>>> add, and I wanted to share.  Are any of these possible?
>>>
>>> #+BEGIN_SRC scheme
>>> (operating system
>>>   (keymap  "dvorak")
>>>   ...)
>>> #+END_SRC
>>>
>>> The above would make the bootloader, console, X, and wayland all use the
>>> dvorak layout.  That would be a nice feature!  I currently use "dvorak",
>>> and it's slightly annoying that grub uses qwerty.  :(
>>
>> Same here.  Some of this might be accomplished with a system service
>> that extends configuration files with the required settings.  Would you
>> like to give this a try?
>
> Yes I would!  I will probably need some mentoring to figure it all out,
> but I will take a go at it.  I think I know how to go about trying it.
> I'll get back to you next week, when I'll probably need some more
> direction.

Excellent!  I recommend looking at the manual section “6.2.15.1 Service
Composition”.  We would like to have a service that extends other
existing services — in some cases we want an extension of the
etc-service-type, which adds files to /etc.  In other cases we may want
to extend the configuration of some X11 service, which is trickier.

Before you try to write any code at all, it would make sense to figure
out what exactly we want to happen.  Currently, the way to configure X11
is a bit awkward: I need to do something like this to override X11
settings:

--8<---cut here---start->8---
(slim-service-type
 config => (slim-configuration
(inherit config)
(startx (xorg-start-command
 #:configuration-file
 (xorg-configuration-file
  #:extra-config
  (list dvorak-evdev))
--8<---cut here---end--->8---

But what should the service do if we aren’t using slim-service-type?  It
seems to me that maybe slim-service-type should extend some new
x11-service-type that has its own configuration, instead of having the
X11 configuration be a side effect of specifying the “startx” field of
the slim-configuration.

Feel free to come up with a better way and discuss it here on the list
rather than trying to squeeze the desired behaviour into the current
implementation.

--
Ricardo

Re: improve installation instructions

[Amirouche Boubekki]

Le sam. 5 janv. 2019 17:59, Ricardo Wurmus  a écrit :

> Hey,
>
> I just installed Guix as a package manager on an aarch64 box.  The
> manual makes it a little difficult to perform all these steps, because
> the commands cannot be easily copied.  We do have the shell script, but
> the manual mentions it only in passing – as a user I skipped over the
> introduction and went straight to step 1, right past the script.
>
> What do you think about mentioning the script in the Installation
> section and only asking users to look in the subsections for details?
>
> Here’s a draft patch:
>
> --8<---cut here---start->8---
> diff --git a/doc/guix.texi b/doc/guix.texi
> index fcb5b8c08..f9afe2bc3 100644
> --- a/doc/guix.texi
> +++ b/doc/guix.texi
> @@ -25,7 +25,7 @@ Copyright @copyright{} 2015, 2016 Mathieu Lirzin@*
>  Copyright @copyright{} 2014 Pierre-Antoine Rault@*
>  Copyright @copyright{} 2015 Taylan Ulrich Bayırlı/Kammer@*
>  Copyright @copyright{} 2015, 2016, 2017 Leo Famulari@*
> -Copyright @copyright{} 2015, 2016, 2017, 2018 Ricardo Wurmus@*
> +Copyright @copyright{} 2015, 2016, 2017, 2018, 2019 Ricardo Wurmus@*
>  Copyright @copyright{} 2016 Ben Woodcroft@*
>  Copyright @copyright{} 2016, 2017, 2018 Chris Marusich@*
>  Copyright @copyright{} 2016, 2017, 2018 Efraim Flashner@*
> @@ -394,29 +394,32 @@ garbage collection of packages (@pxref{Features}).
>  @chapter Installation
>
>  @cindex installing Guix
> -@cindex official website
> -GNU Guix is available for download from its website at
> -@url{http://www.gnu.org/software/guix/}.  This section describes the
> -software requirements of Guix, as well as how to install it and get
> -ready to use it.
>
> -Note that this section is concerned with the installation of the package
> -manager, which can be done on top of a running GNU/Linux system.  If,
> -instead, you want to install the complete GNU operating system,
> -@pxref{System Installation}.
> +We recommend the use of this
> +@uref{
> https://git.savannah.gnu.org/cgit/guix.git/plain/etc/guix-install.sh,
> +shell installer script} to install Guix on top of a running GNU/Linux
> system,
> +thereafter called a @dfn{foreign distro}.@footnote{This section is
> concerned
> +with the installation of the package manager, which can be done on top of
> a
> +running GNU/Linux system.  If, instead, you want to install the complete
> GNU
> +operating system, @pxref{System Installation}.} The script automates the
> +download, installation, and initial configuration of Guix.  It should be
> run
> +as the root user.
>
>  @cindex foreign distro
>  @cindex directories related to foreign distro
> -
> -When installed on a running GNU/Linux system---thereafter called a
> -@dfn{foreign distro}---GNU@tie{}Guix complements the available tools
> -without interference.  Its data lives exclusively in two directories,
> -usually @file{/gnu/store} and @file{/var/guix}; other files on your
> -system, such as @file{/etc}, are left untouched.
> +When installed on a foreign distro, GNU@tie{}Guix complements the
> available
> +tools without interference.  Its data lives exclusively in two
> directories,
> +usually @file{/gnu/store} and @file{/var/guix}; other files on your
> system,
> +such as @file{/etc}, are left untouched.
>
>  Once installed, Guix can be updated by running @command{guix pull}
>  (@pxref{Invoking guix pull}).
>
> +If you prefer to perform the installation steps manually or want to tweak
> +them, you may find the following subsections useful.  They describe the
> +software requirements of Guix, as well as how to install it manually and
> get
> +ready to use it.
> +
>  @menu
>  * Binary Installation:: Getting Guix running in no time!
>  * Requirements::Software needed to build and run Guix.
> @@ -437,11 +440,6 @@ dependencies.  This is often quicker than installing
> from source, which
>  is described in the next sections.  The only requirement is to have
>  GNU@tie{}tar and Xz.
>
> -We provide a
> -@uref{
> https://git.savannah.gnu.org/cgit/guix.git/plain/etc/guix-install.sh,
> -shell installer script}, which automates the download, installation, and
> -initial configuration of Guix.  It should be run as the root user.
> -
>  Installing goes along these lines:
>
>  @enumerate
> @@ -638,6 +636,10 @@ build procedure for Guix is the same as for other GNU
> software, and is
>  not covered here.  Please see the files @file{README} and @file{INSTALL}
>  in the Guix source tree for additional details.
>
> +@cindex official website
> +GNU Guix is available for download from its website at
> +@url{https://www.gnu.org/software/guix/}.
> +
>  GNU Guix depends on the following packages:
>
>  @itemize
> --8<---cut here---end--->8---
>

LGTM

>

improve installation instructions

[Ricardo Wurmus]

Hey,

I just installed Guix as a package manager on an aarch64 box.  The
manual makes it a little difficult to perform all these steps, because
the commands cannot be easily copied.  We do have the shell script, but
the manual mentions it only in passing – as a user I skipped over the
introduction and went straight to step 1, right past the script.

What do you think about mentioning the script in the Installation
section and only asking users to look in the subsections for details?

Here’s a draft patch:

--8<---cut here---start->8---
diff --git a/doc/guix.texi b/doc/guix.texi
index fcb5b8c08..f9afe2bc3 100644
--- a/doc/guix.texi
+++ b/doc/guix.texi
@@ -25,7 +25,7 @@ Copyright @copyright{} 2015, 2016 Mathieu Lirzin@*
 Copyright @copyright{} 2014 Pierre-Antoine Rault@*
 Copyright @copyright{} 2015 Taylan Ulrich Bayırlı/Kammer@*
 Copyright @copyright{} 2015, 2016, 2017 Leo Famulari@*
-Copyright @copyright{} 2015, 2016, 2017, 2018 Ricardo Wurmus@*
+Copyright @copyright{} 2015, 2016, 2017, 2018, 2019 Ricardo Wurmus@*
 Copyright @copyright{} 2016 Ben Woodcroft@*
 Copyright @copyright{} 2016, 2017, 2018 Chris Marusich@*
 Copyright @copyright{} 2016, 2017, 2018 Efraim Flashner@*
@@ -394,29 +394,32 @@ garbage collection of packages (@pxref{Features}).
 @chapter Installation
 
 @cindex installing Guix
-@cindex official website
-GNU Guix is available for download from its website at
-@url{http://www.gnu.org/software/guix/}.  This section describes the
-software requirements of Guix, as well as how to install it and get
-ready to use it.
 
-Note that this section is concerned with the installation of the package
-manager, which can be done on top of a running GNU/Linux system.  If,
-instead, you want to install the complete GNU operating system,
-@pxref{System Installation}.
+We recommend the use of this
+@uref{https://git.savannah.gnu.org/cgit/guix.git/plain/etc/guix-install.sh,
+shell installer script} to install Guix on top of a running GNU/Linux system,
+thereafter called a @dfn{foreign distro}.@footnote{This section is concerned
+with the installation of the package manager, which can be done on top of a
+running GNU/Linux system.  If, instead, you want to install the complete GNU
+operating system, @pxref{System Installation}.} The script automates the
+download, installation, and initial configuration of Guix.  It should be run
+as the root user.
 
 @cindex foreign distro
 @cindex directories related to foreign distro
-
-When installed on a running GNU/Linux system---thereafter called a
-@dfn{foreign distro}---GNU@tie{}Guix complements the available tools
-without interference.  Its data lives exclusively in two directories,
-usually @file{/gnu/store} and @file{/var/guix}; other files on your
-system, such as @file{/etc}, are left untouched.
+When installed on a foreign distro, GNU@tie{}Guix complements the available
+tools without interference.  Its data lives exclusively in two directories,
+usually @file{/gnu/store} and @file{/var/guix}; other files on your system,
+such as @file{/etc}, are left untouched.
 
 Once installed, Guix can be updated by running @command{guix pull}
 (@pxref{Invoking guix pull}).
 
+If you prefer to perform the installation steps manually or want to tweak
+them, you may find the following subsections useful.  They describe the
+software requirements of Guix, as well as how to install it manually and get
+ready to use it.
+
 @menu
 * Binary Installation:: Getting Guix running in no time!
 * Requirements::Software needed to build and run Guix.
@@ -437,11 +440,6 @@ dependencies.  This is often quicker than installing from 
source, which
 is described in the next sections.  The only requirement is to have
 GNU@tie{}tar and Xz.
 
-We provide a
-@uref{https://git.savannah.gnu.org/cgit/guix.git/plain/etc/guix-install.sh,
-shell installer script}, which automates the download, installation, and
-initial configuration of Guix.  It should be run as the root user.
-
 Installing goes along these lines:
 
 @enumerate
@@ -638,6 +636,10 @@ build procedure for Guix is the same as for other GNU 
software, and is
 not covered here.  Please see the files @file{README} and @file{INSTALL}
 in the Guix source tree for additional details.
 
+@cindex official website
+GNU Guix is available for download from its website at
+@url{https://www.gnu.org/software/guix/}.
+
 GNU Guix depends on the following packages:
 
 @itemize
--8<---cut here---end--->8---


--
Ricardo

Re: Docker and singularity containers

[Ricardo Wurmus]

Hi simon,

> Well, why not push to DockerHub time to time.
> I agree that will attract people if Guix provide an official docker
> image reachable from DockerHub.
[…]
> Therefore:
>  - which tasks and which packages?

I don’t know.  We could have one with R + all CRAN and bioconductor
packages that we currently offer.

>  - how?

That’s easier: with “guix pack”.  We would create a Cuirass job to build
a pack regularly.  We’d need to add support for hooks to publish the
generated pack on DockerHub, though we could just as well host them
ourselves.

Would you like to give this a try?  A good first step is to list the
steps that need to be performed.  A first implementation might even be
done with a cron job.  I could add this to berlin.guixsd.org when you’re
ready.

--
Ricardo

Re: 07/09: gnu: kinit: Use LIBRARY_PATH to search for dynamically loaded libs.

[Ludovic Courtès]

Hi Hartmut,

guix-comm...@gnu.org skribis:

> commit 16b8aff85bcdb9799496c4a27257210cd45158e5
> Author: Hartmut Goebel 
> Date:   Thu Mar 1 23:08:44 2018 +0100
>
> gnu: kinit: Use LIBRARY_PATH to search for dynamically loaded libs.
> 
> Transfer the NixOS "kdeinit-libpath" patch for kinit as of
> 2018-02-17.
> 
> * gnu/packages/patches/kinit-kdeinit-libpath.patch: New file.
> * gnu/local.mk (dist_patch_DATA): Add it.
> * gnu/packages/kde-frameworks.scm (kinit)[source]: Use it.

[...]

> ++// Try to load the library relative to the active profiles.
> ++QByteArrayList profiles = 
> qgetenv("LIBRARY_PATH").split(':');
> ++for (const QByteArray : profiles) {
> ++if (!profile.isEmpty()) {
> ++l.setFileName(QFile::decodeName(profile) + 
> QStringLiteral("/") + libpath);
> ++if (l.load()) break;
> ++}

I find this use of LIBRARY_PATH questionable: it’s the variable normally
used by the compiler driver (gcc) at link time, not by the loader
(ld.so).  IOW, it’s really a compile-time variable, and one that has
nothing to do with Qt or KDE.

What about using a different variable for this purpose?  It could be
KDE_PLUGIN_PATH or something like this, and we could add it to
‘native-search-paths’ of kinit.  We could also avoid the “+ libpath” bit
I suppose.

Thoughts?

Apologies if this has been discussed elsewhere…

Thank you,
Ludo’.

Re: Brain storming cool Guix features

[Joshua Branson]

Ricardo Wurmus  writes:

> Joshua Branson  writes:
>
>> I had some cool ideas/features for things that GuixSD could potentially
>> add, and I wanted to share.  Are any of these possible?
>>
>> #+BEGIN_SRC scheme
>> (operating system
>>   (keymap  "dvorak")
>>   ...)
>> #+END_SRC
>>
>> The above would make the bootloader, console, X, and wayland all use the
>> dvorak layout.  That would be a nice feature!  I currently use "dvorak",
>> and it's slightly annoying that grub uses qwerty.  :(
>
> Same here.  Some of this might be accomplished with a system service
> that extends configuration files with the required settings.  Would you
> like to give this a try?

Yes I would!  I will probably need some mentoring to figure it all out,
but I will take a go at it.  I think I know how to go about trying it.
I'll get back to you next week, when I'll probably need some more
direction. 

>
>> How about automatic updates?  Since a guixSD user can always downgrade
>> to the previous version, it would be nice if it would automatically
>> update my user profile, root profile and reconfigure say once a week.
>>
>> #+BEGIN_SRC scheme
>> (operating system
>>   (auto-upgrade #t)
>>   (auto-upgrade-interval 'once-a-week)
>>   ...)
>> #+END_SRC
>
> Cron jobs can be used here via the mcron service.

--
Joshua Branson
Sent from Emacs and Gnus

Re: GNU Guix Days before FOSDEM

[Pjotr Prins]

Dear all,

On Fri, Aug 24, 2018 at 11:58:54AM +0200, Ludovic Courtès wrote:
> The real URL is:
> 
>   https://libreplanet.org/wiki/Group:Guix/FOSDEM2019#GNU_Guix_Days
> 
> I copied and adjusted the text from last year’s page.
> 
> Anyway, feel free to add your name if you would come, and ideas of talks
> or hacking sessions we may have, so we can start planning!
> 
> Thanks,
> Ludo’.

We have an exciting program for the minimalism devroom at FOSDEM, see 

  https://fosdem.org/2019/schedule/track/minimalistic_languages/

We also have two GNU Guix days before FOSDEM. The idea is to break out
into working groups during those two days. I have added a few ideas
here:

  https://libreplanet.org/wiki/Group:Guix/FOSDEM2019#Programme

Feel free to add your favourite topics! If you want to attend be sure
to add your name. We can't allow more than 40 people.

Pj.