Re: guix home

[Ryan Prior]

On March 14, 2021, Joshua Branson  wrote:
> Andrew Tropin  writes:
>
> > There is an implementation of `guix home` subcommand, which behaves
> > similar to `guix system`

Thanks for sharing this Andrew, it looks awesome & I'm going to give it
a try!

What do you think about changing the command? It manages user files,
user services, user environment variables, the lifecycle of user
sessions. So we could have "guix system" for system-level things, and
"guix user" for user-level things. Similarly, many of the services you
describe sound to me like they would be easier to understand what they
do with names like "user-service," "user-environment-vars," etc.

I feel Guix needs something like this upstream. Whether this is the
right implementation or not I'm not qualified to judge, but I'll read
the source code and see what I can learn or contribute!

Ryan

Re: Guile Netlink 1.0 released

[Julien Lepiller]

Thanks for the feedback Vincent and Vladimir!

Le Sun, 14 Mar 2021 16:12:05 -0700,
Vladimir Sedach  a écrit :

> Julien Lepiller  writes:
> > I'm proud to announce the first release of Guile Netlink!  
> 
> This is great! I have been wishing for this for Guile ever since I
> started using Guix. Thank you.
> 
> Vincent Legoll  writes:
> >>   (addr-add "enp1s0" "2001:db8::1a4c/64" #:ipv6? #t)  
> >
> > what does the "ipv6?" parameter add ? This could be
> > deduced from the address length, no ?  
> 
> IPv6 configuration is so different from IPv4 configuration that I
> think it should have its own functions, not just a keyword parameter.
> 
> For example, right now you cannot assign multiple static IPv6
> addresses to the same interface (a basic IPv6 task) with
> static-networking-service. Putting the conditional logic for IPv4
> versus IPv6 rules inside the same functions is an invitation for more
> similar bugs. Trying to dispatch based on parsing the provided string
> makes it even more confusing. Dispatching based on a keyword
> parameter is not much better, and introduces the possibility of user
> error ("I forgot the #:ipv6 keyword").

The high-level API is just a wrapper around the low-level API, and in
rtnetlink, the only different between IPv4 and IPv6 is a family
parameter in message, namely AF_INET or AF_INET6. Basically, the
messages are exactly the same, except that in the IPv6 case, you use
IPv6 addresses which obviously take a little bit more space, so I
expect the wrappers to work the same.

If you want multiple addresses on the same interface, you can simply
call addr-add multiple times, one per address, and that has nothing to
do with whether it is IPv6 or IPv4 (you can have multiple IPv4
addresses on the same interface).

I don't think there's any reason why the procedures should be separate
between IPv4 and IPv6. I like the idea of deducing IPv4 vs IPv6 from
address format (not length though, as that may vary and overlap. After
all, 1.1 and ::1 are valid IPv4 and IPv6 addresses of the same length
;)). But simply detecting a dot vs a colon should work well. I've
always been bothered by "ip" vs "ip -6".

I don't really like the idea of having to separate the address and
prefix len, simply because this is the notation used by iproute2. It's
also easier for consumers of the API: you pass a string that contains
all the information, and don't really have to care.

> 
> --
> Vladimir Sedach
> Software engineering services in Los Angeles https://oneofus.la

Re: [bootstrappable] Re: Can Guile be bootstrapped from source without psyntax-pp.scm?

[Michael Schierl]

Hello Jan,


Am 14.03.2021 um 14:57 schrieb Jan Nieuwenhuizen:

Michael Schierl writes:

Hello,


For the record, I have written a psyntax implementation that can be used
by Guile (3.0.2) and does not require an expanded version of itself.


Oh, that's amazing!  I see that you are using make-syntax-transformer
(and others) which GNU Mes does not support yet; it only has
define-macro.  This may be a good reason/opportunity to work towards
better Guile support in Mes.


In fact, I use make-syntax-transformer only because Guile does not have
native define-macro support (it uses psyntax to emulate it).

When there is native define-macro support, you can replace step1.scm by

(define s1*-define-macro define-macro)

(define-macro (s1*-expand-with-side-effects seff1 body seff2)
  (list '(lambda (a b . c) (apply values b))
seff1
(list 'call-with-values (list 'lambda '() body)
  '(lambda rest rest))
seff2))

which will make the bootstrap even shorter.

Probably you should validate whether the evaluation order is right so
that s1*-expand-with-side-effects will really expand the side effect 1
before the body and side effect 2 after the body (there is an example in
psyntax-bootstrapping.scm line 76 which should display 1 2 3 and return 42).

You can skip step 2 as well, as you already have a quasiquote expander
that does not rely on psyntex.

The further steps up to step 7 will not use make-syntax-transformer, it
will come back in step 8 (patched psyntax.scm). But probably for step 8
you would have to patch your own psyntax.scm instead of patching guile's
version anyway.


Regards,


Michael

Re: Can Guile be bootstrapped from source without psyntax-pp.scm?

[Michael Schierl]

Hello,


Jan Nieuwenhuizen wrote to guile-u...@gnu.org[1] on 07 Jul 2017:

Mark H Weaver writes:


Does this mean Guile is not bootstrappable from source only?


That's correct.  psyntax-pp.scm is not source code, and it is needed to
bootstrap Guile.


I'm facing the same problem with Mes.  I have an implemenation of
syntax-rules that is just about 200 lines of define-macro source code,
but not syntax case.



Having said this, I agree that it would be better if psyntax.scm were
written in such a way that it could be bootstrapped without the use of
itself.  Maybe some day we'll rewrite it to make it so.


That could be essential to our full source bootstrapping efforts so I'm
very much interested!



For the record, I have written a psyntax implementation that can be used
by Guile (3.0.2) and does not require an expanded version of itself. It
is not ideal (not fully hygienic and does not support with-ellipsis),
but it works well enough to bootstrap a slightly patched version of
psyntax.scm, which then can be used to bootstrap "the real thing" and
then regenerate psyntax-pp.scm (resulting in a bit-for-bit identical
version if you run the bootstrap on 64-bit Linux).

The project is at
.

It may still contain some unnecessary code, and the patch for the
patched vesion is definitely not minimal, but for now I'm glad that it
works.

I may improve it later. Contributions are welcome as well.


Regards,


Michael


[1]: https://mail.gnu.org/archive/html/guile-user/2017-07/msg00011.html

Re: Guile Netlink 1.0 released

[Vladimir Sedach]

Julien Lepiller  writes:
> I'm proud to announce the first release of Guile Netlink!

This is great! I have been wishing for this for Guile ever since I
started using Guix. Thank you.

Vincent Legoll  writes:
>>   (addr-add "enp1s0" "2001:db8::1a4c/64" #:ipv6? #t)
>
> what does the "ipv6?" parameter add ? This could be
> deduced from the address length, no ?

IPv6 configuration is so different from IPv4 configuration that I
think it should have its own functions, not just a keyword parameter.

For example, right now you cannot assign multiple static IPv6
addresses to the same interface (a basic IPv6 task) with
static-networking-service. Putting the conditional logic for IPv4
versus IPv6 rules inside the same functions is an invitation for more
similar bugs. Trying to dispatch based on parsing the provided string
makes it even more confusing. Dispatching based on a keyword
parameter is not much better, and introduces the possibility of user
error ("I forgot the #:ipv6 keyword").

--
Vladimir Sedach
Software engineering services in Los Angeles https://oneofus.la

Re: bsdiff package vulnerable to CVE-2020-14315

[Mark H Weaver]

Léo Le Bouter  writes:

> On Wed, 2021-03-10 at 12:32 -0500, Leo Famulari wrote:
>> Well, we could also just remove this package. It sounds like it is
>> not
>> supported on Linux. Does it offer some unique functionality?
>
> I would advocate for removal of the package, or at least warning about
> absence of security patches for security issues at install/show time.

For the record, Léo removed this package in commit
373c7b5791acd8f377455be47260948b843dd5db on the 'master' branch.

  Mark

Re: Examples on why ungrafting is necessary

[Leo Famulari]

On Thu, Mar 11, 2021 at 02:16:16PM +0100, zimoun wrote:
> Updating the package r-chemminer, it leads to this huge stack of
> grafts.  To be concrete, it is 84 grafts for a “simple” R packages.  On
> my machine, the grafting steps are longer than building (compiling and R
> dance).

The performance of grafting largely corresponds to I/O speed.

> We definitively need a way to tackle this.  Maybe when is in frozen
> state, we could spend 2-5 days to tackle as much as graft that we can.
> 
> The previous Leo’s initiative is really worth and maybe we should have a
> hackathon or something because my feeling is that more grafts are added
> than removed.

To clarify: the number of grafts added is exactly the same number of
grafts that are removed. But, it takes longer to remove them, because
ungrafted requires us to recompile every affected package.

Re: Guile Netlink 1.0 released

[Vincent Legoll]

Hello,

just a few questions about the API

On Sun, Mar 14, 2021 at 8:31 PM Julien Lepiller  wrote:

>   ;; same as "ip a add 192.0.2.15/24 dev enp1s0
>   (addr-add "enp1s0" "192.0.2.15/24")

Why not separating the netmask from the address ?

It forces to do string manipulation, and prevent
the use of bitfield, or the dotted bytes representation
"255.255.255.0".

>   (addr-add "enp1s0" "2001:db8::1a4c/64" #:ipv6? #t)

what does the "ipv6?" parameter add ? This could be
deduced from the address length, no ?

>   ;; same as "ip r add default via 192.0.2.1 dev enp1s0"
>   (route-add "default" #:device "enp1s0" #:via "192.0.2.1")

"via" could also be called "gateway" (maybe that's an oldtimer
thing ;-) )

But that's all kind of bikesheddy...

-- 
Vincent Legoll

Guile Netlink 1.0 released

[Julien Lepiller]

Hi!

I'm proud to announce the first release of Guile Netlink!

  git clone https://git.lepiller.eu/git/guile-netlink
  cd guile-netlink
  git checkout 1.0 # or 29ff43368f1cc2d10a7e5f09dc9f80f85582d6ee
  git tag -v 1.0

The 'git tag -v' command check the authenticity of your checkout. You
may need to retrieve the signing key first:

  gpg --keyserver pool.sks-keyservers.net \
  --recv-keys 1EFB09091F17D28CCBF9B13A53D457B2D636EE82

Guile Netlink provides three components:

- A helper library for implementing netlink protocols
- An implementation of rtnetlink, one of the netlink protocols. It is
  used to query and alter the state of the network stack in Linux.
- A high-level API implemented on top of rtnetlink and inspired by
  iproute2's commands

Here are a few examples (most of which will only work as root and will
really modify your network), extracted from the manual:

  ;; same as "ip l add v0p0 type veth peer v0p1"
  (link-add "v0p0" "veth" #:type-args '((peer . "v0p1")))

  ;; same as "ip a add 192.0.2.15/24 dev enp1s0
  (addr-add "enp1s0" "192.0.2.15/24")
  (addr-add "enp1s0" "2001:db8::1a4c/64" #:ipv6? #t)

  ;; removing the previous addresses, as in "ip a del 192.0.2.15/24 dev
  ;; enp1s0"
  (addr-del "enp1s0" "192.0.2.15/24")
  (addr-del "enp1s0" "2001:db8::1a4c/64" #:ipv6? #t)

  ;; same as "ip a" or "ip addr show"
  (addr-show)

  ;; same as "ip r add default via 192.0.2.1 dev enp1s0"
  (route-add "default" #:device "enp1s0" #:via "192.0.2.1")
  ;; same as "ip r add 192.0.2.0/24 dev enp1s0 src 192.0.2.15"
  (route-add "192.0.2.0/24" #:device "enp1s0" #:src "192.0.2.15")

Hopefully, the high-level API can be used on Linux to replace our
current implementation of container networking and static networking
service type.

You will find the complete documentation online at
https://git.lepiller.eu/guile-netlink/manual, the code is available at
https://git.lepiller.eu/guile-netlink (note that the clone URL is
different, see above) and you can report any issue, patch and ideas to
me, by email.

Hope you'll enjoy!

Julien

Re: 01/09: gnu: Add python-sphobjinv.

[Mathieu Othacehe]

Hello,

> +   (patches (search-patches "python-sphobjinv-system-ca.patch"

Looks like this patch is missing, causing an evaluation failure.

Thanks,

Mathieu

Re: 01/09: gnu: Add python-sphobjinv.

[Mathieu Othacehe]

Hello,

> +   (patches (search-patches "python-sphobjinv-system-ca.patch"

Looks like this patch is missing, causing an evaluation failure.

Thanks,

Mathieu

Re: GNU Mes 0.23 released

[Efraim Flashner]

Great work everybody!

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

GNU Mes 0.23 released

[Jan Nieuwenhuizen]

We are happy to announce the release of GNU Mes 0.23, representing 125
commits over one year by four people.

Mes was ported to ARM and can now be used in the GNU Guix Reduced Binary
Seed bootstrap as described here

https://guix.gnu.org/blog/2020/guix-further-reduces-bootstrap-seed-to-25/

and now also for armhf-linux and aarch-linux.  Work to integrate this
into Guix is ongoing: tinycc and gcc-core-2.95.3 have been built.

We are excited that the Nlnet Foundation is now sponsoring this work!

Enjoy,
Janneke and Danny.


* About

  GNU Mes[0] is a Scheme interpreter and C compiler for bootstrapping the
  GNU System.  Since version 0.22 it has again helped to halve the size of
  opaque, uninspectable binary seeds that are currently being used in the
  Reduced Binary Seed bootstrap[1] of GNU Guix[2].  The final goal is to
  help create a full source bootstrap as part of the bootstrappable
  builds[3] effort for UNIX-like operating systems.

  The Scheme interpreter is written in ~5,000 LOC of simple C, and the C
  compiler written in Scheme and these are mutual self-hosting.  This
  mes.c is now being simplified to be transpiled by M2-Planet[4].

  Mes has a Garbage Collector, a library of loadable Scheme modules--
  notably Dominique Boucher's LALR[5], Pre-R6RS portable syntax-case[6]
  with R7RS ellipsis, Matt Wette's Nyacc[7] --and test suite, just
  enough to support a REPL and a C99 compiler: mescc.

  Mes + MesCC + Mes C Library can build a bootstrappable TinyCC[8] that
  is self-hosting.  Using this tcc and the Mes C library we now have a
  Reduced Binary Seed bootstrap for the gnutools triplet: glibc-2.2.5,
  binutils-2.20.1, gcc-2.95.3.  This is enough to bootstrap Guix for
  i686-linux, x86_64-linux, armhf-linux and aarch64-linux.

  Mes is inspired by The Maxwell Equations of Software: LISP-1.5[9] -- John
  McCarthy page 13, GNU Guix's source/binary packaging transparency and
  Jeremiah Orians's stage0[10] ~500 byte self-hosting hex assembler.

  We are very grateful to NLNet for sponsoring the Reduced Binary Seed
  bootstrap[11] and the ARM port[12].

* Download

  git clone git://git.savannah.gnu.org/mes.git

  Here are the compressed sources and a GPG detached signature[*]:
https://ftp.gnu.org/gnu/mes/mes-0.23.tar.gz
https://ftp.gnu.org/gnu/mes/mes-0.23.tar.gz.sig

  Use a mirror for higher download bandwidth:
https://ftpmirror.gnu.org/mes/mes-0.23.tar.gz
https://ftpmirror.gnu.org/mes/mes-0.23.tar.gz.sig

  Here are the MD5 and SHA1 checksums:

e9a0ae6e2c3842cf57fccb54909463ba  mes-0.23.tar.gz
0560879358e5a980f7374844c495c92014b47878  mes-0.23.tar.gz

  [*] Use a .sig file to verify that the corresponding file (without the
  .sig suffix) is intact.  First, be sure to download both the .sig file
  and the corresponding tarball.  Then, run a command like this:

gpg --verify mes-0.23.tar.gz.sig

  If that command fails because you don't have the required public key,
  then run this command to import it:

gpg --keyserver keys.gnupg.net --recv-keys 
1A858392E331EAFDB8C27FFBF3C1A0D9C1D65273

  and rerun the 'gpg --verify' command.

* Get informed, get involved

  See https://bootstrappable.org
  Join #bootstrappable on irc.freenode.net.

* NEWS
 * Changes in 0.23 since 0.22
 ** Core
 *** Mes and Mes C Library can now be built with GCC 10.x.
 ** MesCC
 *** The Mes C Library now supports an armhf-linux bootstrap.
 *** MesCC now supports ARM.
 *** mini.c library was split into _exit.c, and _write.c.
 *** When building with GCC, -lgcc is now used.
 *** MesCC now has it's own support library libmescc.a (-lmescc).
 *** MesCC now requires mescc-tools-0.7.0 or later for ARM.
 *** MesCC can be now built with nyacc-1.00.2:
 note that nyacc-1.03.0 is not (backwards) compatible.
 *** MesCC can be built with Guile 3.0.x:
 See https://bugs.gnu.org/43831; use guild compile -O1 with Guile 3.0.x.
 *** MesCC now raises SIGABRT on abort, if supported.
 ** Noteworthy bug fixes
 *** unreadchar on EOF is now a no-op.
 *** malloc now aligns the blocks it gives out to max_align_t.

[0] https://www.gnu.org/software/mes
[1] https://guix.gnu.org/blog/2020/guix-further-reduces-bootstrap-seed-to-25
[2] https://www.gnu.org/software/guix
[3] https://bootstrappable.org
[4] https://github.com/oriansj/m2-planet
[5] https://github.com/schemeway/lalr-scm
[6] https://www.cs.indiana.edu/chezscheme/syntax-case/old-psyntax.html
[7] https://www.nongnu.org/nyacc
[8] https://gitlab.com/janneke/tinycc
[9] 
http://www.softwarepreservation.org/projects/LISP/book/LISP%201.5%20Programmers%20Manual.pdf
[10] https://savannah.nongnu.org/projects/stage0
[11] https://nlnet.nl/project/GNUMes
[12] https://nlnet.nl/project/GNUMes-arm

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


signature.asc
Description: PGP signature

Re: Examples on why ungrafting is necessary

[Joshua Branson]

zimoun  writes:

> Hi,
>
> Updating the package r-chemminer, it leads to this huge stack of
> grafts.  To be concrete, it is 84 grafts for a “simple” R packages.  On
> my machine, the grafting steps are longer than building (compiling and R
> dance).
>
> We definitively need a way to tackle this.  Maybe when is in frozen
> state, we could spend 2-5 days to tackle as much as graft that we can.
>
> The previous Leo’s initiative is really worth and maybe we should have a
> hackathon or something because my feeling is that more grafts are added
> than removed.

Thanks for sharing!  I didn't realize that grafts were getting that
annoying.  :)
>
> Cheers,
> simon
>
> applying 1 graft for /gnu/store/…-dbus-1.12.16.drv ...
> grafting '/gnu/store/…-dbus-1.12.16' -> '/gnu/store/…-dbus-1.12.16'...
> successfully built /gnu/store/…-dbus-1.12.16.drv
> applying 1 graft for /gnu/store/…-cyrus-sasl-2.1.27.drv ...
> grafting '/gnu/store/…-cyrus-sasl-2.1.27' -> 
> '/gnu/store/…-cyrus-sasl-2.1.27'...
> successfully built /gnu/store/…-cyrus-sasl-2.1.27.drv
> applying 1 graft for /gnu/store/…-libxrender-0.9.10.drv ...
> grafting '/gnu/store/…-libxrender-0.9.10' -> 
> '/gnu/store/…-libxrender-0.9.10'...
> successfully built /gnu/store/…-libxrender-0.9.10.drv
> applying 1 graft for /gnu/store/…-libxt-1.2.0.drv ...
> grafting '/gnu/store/…-libxt-1.2.0' -> '/gnu/store/…-libxt-1.2.0'...
> successfully built /gnu/store/…-libxt-1.2.0.drv
> applying 2 grafts for /gnu/store/…-libxft-2.3.3.drv ...
> grafting '/gnu/store/…-libxft-2.3.3' -> '/gnu/store/…-libxft-2.3.3'...
> successfully built /gnu/store/…-libxft-2.3.3.drv
> applying 3 grafts for /gnu/store/…-libxmu-1.1.3.drv ...
> grafting '/gnu/store/…-libxmu-1.1.3' -> '/gnu/store/…-libxmu-1.1.3'...
> successfully built /gnu/store/…-libxmu-1.1.3.drv
> applying 3 grafts for /gnu/store/…-libxpm-3.5.13.drv ...
> grafting '/gnu/store/…-libxpm-3.5.13' -> '/gnu/store/…-libxpm-3.5.13'...
> successfully built /gnu/store/…-libxpm-3.5.13.drv
> applying 2 grafts for /gnu/store/…-openjpeg-2.3.1.drv ...
> grafting '/gnu/store/…-openjpeg-2.3.1' -> '/gnu/store/…-openjpeg-2.3.1'...
> successfully built /gnu/store/…-openjpeg-2.3.1.drv
> applying 5 grafts for /gnu/store/…-libxaw-1.0.13.drv ...
> grafting '/gnu/store/…-libxaw-1.0.13' -> '/gnu/store/…-libxaw-1.0.13'...
> successfully built /gnu/store/…-libxaw-1.0.13.drv
> applying 1 graft for /gnu/store/…-openldap-2.4.57.drv ...
> grafting '/gnu/store/…-openldap-2.4.57' -> '/gnu/store/…-openldap-2.4.57'...
> successfully built /gnu/store/…-openldap-2.4.57.drv
> applying 1 graft for /gnu/store/…-ruby-2.6.5.drv ...
> grafting '/gnu/store/…-ruby-2.6.5' -> '/gnu/store/…-ruby-2.6.5'...
> successfully built /gnu/store/…-ruby-2.6.5.drv
> applying 2 grafts for /gnu/store/…-curl-7.74.0.drv ...
> grafting '/gnu/store/…-curl-7.74.0' -> '/gnu/store/…-curl-7.74.0'...
> successfully built /gnu/store/…-curl-7.74.0.drv
> applying 2 grafts for /gnu/store/…-tk-8.6.10.drv ...
> grafting '/gnu/store/…-tk-8.6.10' -> '/gnu/store/…-tk-8.6.10'...
> successfully built /gnu/store/…-tk-8.6.10.drv
> applying 3 grafts for /gnu/store/…-python-3.8.2.drv ...
> grafting '/gnu/store/…-python-3.8.2' -> '/gnu/store/…-python-3.8.2'...
> grafting '/gnu/store/…-python-3.8.2-tk' -> '/gnu/store/…-python-3.8.2-tk'...
> successfully built /gnu/store/…-python-3.8.2.drv
> applying 3 grafts for /gnu/store/…-python2-2.7.17.drv ...
> grafting '/gnu/store/…-python2-2.7.17' -> '/gnu/store/…-python2-2.7.17'...
> grafting '/gnu/store/…-python2-2.7.17-tk' -> 
> '/gnu/store/…-python2-2.7.17-tk'...
> successfully built /gnu/store/…-python2-2.7.17.drv
> applying 2 grafts for /gnu/store/…-glib-2.62.6.drv ...
> grafting '/gnu/store/…-glib-2.62.6-bin' -> '/gnu/store/…-glib-2.62.6-bin'...
> grafting '/gnu/store/…-glib-2.62.6' -> '/gnu/store/…-glib-2.62.6'...
> successfully built /gnu/store/…-glib-2.62.6.drv
> applying 4 grafts for /gnu/store/…-cairo-1.16.0.drv ...
> grafting '/gnu/store/…-cairo-1.16.0' -> '/gnu/store/…-cairo-1.16.0'...
> successfully built /gnu/store/…-cairo-1.16.0.drv
> applying 4 grafts for /gnu/store/…-cairo-1.16.0.drv ...
> grafting '/gnu/store/…-cairo-1.16.0' -> '/gnu/store/…-cairo-1.16.0'...
> successfully built /gnu/store/…-cairo-1.16.0.drv
> applying 1 graft for /gnu/store/…-harfbuzz-2.6.4.drv ...
> grafting '/gnu/store/…-harfbuzz-2.6.4' -> '/gnu/store/…-harfbuzz-2.6.4'...
> successfully built /gnu/store/…-harfbuzz-2.6.4.drv
> applying 5 grafts for /gnu/store/…-poppler-0.86.1.drv ...
> grafting '/gnu/store/…-poppler-0.86.1' -> '/gnu/store/…-poppler-0.86.1'...
> successfully built /gnu/store/…-poppler-0.86.1.drv
> applying 6 grafts for /gnu/store/…-pango-1.44.7.drv ...
> grafting '/gnu/store/…-pango-1.44.7' -> '/gnu/store/…-pango-1.44.7'...
> successfully built /gnu/store/…-pango-1.44.7.drv
> applying 13 grafts for /gnu/store/…-texlive-bin-20190410.drv ...
> grafting '/gnu/store/…-texlive-bin-20190410' -> 
> '/gnu/store/…-texlive-bin-20190410'...
> GC Warning: Repeated allocation of very 

Re: guix home

[Joshua Branson]

Andrew Tropin  writes:

> Hi guix!
>
> There is an implementation of `guix home` subcommand, which behaves
> similar to `guix system`, allowing declaratively manage applications and
> their configurations, but for a particular user, not the whole OS:
> https://git.sr.ht/~abcdw/rde/tree/master/item/gnu

Thanks for sharing this!  And it's on sourcehut!  Very rock star of you!

>
> For now I personally manage just a few applications on my system and it
> seems that everything works as expected, but I plan to migrate all the
> "dotfiles" to it in nearest future. AFAIK, some people succesfully use
> it on other GNU/Linux distributions.

That's awesome!

>
> * Alternative solutions
> In contrast to guix-home-manager, `guix home` doesn't introduce any too

For those interested the guix-home-manager is here:
https://framagit.org/tyreunom/guix-home-manager

> innovative approaches (those ideas are cool, but in some use cases are
> too radical), `guix home` uses the same extension mechanism [fn:1] as
> guix system services and doesn't require to make HOME read-only. Thus,
> it's possible to start using `guix home` gradually, along with other
> tools and workflows (stow, guix package, chezmoi, yadm, etc).

Honestly, this is why I haven't tried the guix-home-manager.  I didn't
want to make /home read only.  That sounded hard to switch to.  I'll
have to give your guix home command a try!  It sounds easy!

> * Future steps
> `guix home` still under active development, but already complete enough
> for exloration and early adoption. There is no any documentation yet,
> because things were changing often and probably will change one more
> time during comming cleanup, however there were few video streams,
> explaining internals of `guix home`:
> mpv https://youtu.be/t3zRzQnarUI
> mpv https://youtu.be/4lJaVzxO_Bs
> mpv https://youtu.be/ZRQtCvo8MoM
>
> The question is: do we want and need at all `guix home` to be a part of
> the guix? As for me, the tool seems like a natural addition to guix's
> declarative configuration management approach and covers the missing
> piece of user space software management and as I mentioned early
> upstreaming will allow to make it better integrated with the rest of the
> guix and easier to use for newcommers and casual users, but my
> perception is obviously biased.

I believe the goal is to eventually merge guix-home-manager (or
something like it) into guix.  (I'm more of a guix documentation guy, so
perhaps a guix developer can better answer this).

> --
> Best regards,
> Andrew Tropin

I'm going to remember that name.  Andrew's going places!

--
Joshua Branson (joshuaBPMan in #guix)
Sent from Emacs and Gnus
  https://gnucode.me
  https://video.hardlimit.com/accounts/joshua_branson/video-channels
  https://propernaming.org
  "You can have whatever you want, as long as you help
enough other people get what they want." - Zig Ziglar

Re: [bootstrappable] Re: Can Guile be bootstrapped from source without psyntax-pp.scm?

[Jan Nieuwenhuizen]

Michael Schierl writes:

Hello,

> Jan Nieuwenhuizen wrote to guile-u...@gnu.org[1] on 07 Jul 2017:
>> Mark H Weaver writes:
>>
 Does this mean Guile is not bootstrappable from source only?
>>>
>>> That's correct.  psyntax-pp.scm is not source code, and it is needed to
>>> bootstrap Guile.
>>
>> I'm facing the same problem with Mes.  I have an implemenation of
>> syntax-rules that is just about 200 lines of define-macro source code,
>> but not syntax case.
>
>>> Having said this, I agree that it would be better if psyntax.scm were
>>> written in such a way that it could be bootstrapped without the use of
>>> itself.  Maybe some day we'll rewrite it to make it so.
>>
>> That could be essential to our full source bootstrapping efforts so I'm
>> very much interested!
>
> For the record, I have written a psyntax implementation that can be used
> by Guile (3.0.2) and does not require an expanded version of itself.

Oh, that's amazing!  I see that you are using make-syntax-transformer
(and others) which GNU Mes does not support yet; it only has
define-macro.  This may be a good reason/opportunity to work towards
better Guile support in Mes.

Greetings,
Janneke

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

Re: Release on April 18th?

[Vincent Legoll]

Hello Chris,

On Fri, Mar 12, 2021 at 7:42 PM Chris Marusich  wrote:
> Vincent Legoll  writes:
> > I rebuilt guix on core-updates with gcc-8 succesfully
> > I'll now try the same above wip-ppc64le.
>
> Awesome!  Thank you for doing this.  I'm sure there will be some bumps,
> and the sooner we can fix them, the easier it will be to integrate
> later.

I did not `make check` on core-updates + gcc 8, will retry that later.

On wip-ppc64le, guix built OK, but am meeting `make check` failures:


Testsuite summary for GNU Guix 1.0.1.31332-e8b83e

# TOTAL: 1171
# PASS:  1153
# SKIP:  7
# XFAIL: 2
# FAIL:  9
# XPASS: 0
# ERROR: 0

See ./test-suite.log
Please report to bug-g...@gnu.org


I'm looking at those log files now...

> I'm still working on getting you access to ppc64le hardware or a VM.

I already send my public key to Tobias, so that is WIP.

Tchuss

-- 
Vincent Legoll