Re: Blog post on the Full-Source Bootstrap

2023-04-28 Thread Janneke Nieuwenhuizen
Simon Tournier writes:

Hi Simon,

> On mer., 26 avril 2023 at 16:12, Janneke Nieuwenhuizen  
> wrote:
>
>>   
>> https://gnu.org/software/guix/blog/2023/the-full-source-bootstrap-building-from-source-all-the-way-down/
>
> Really cool!

Yeah, thanks!

> Maybe I misread the wording:
>
> If you run guix pull today, you get a package graph of more than
> 22,000 nodes rooted in a 357-byte program
> or
> First, while the package graph is rooted in a 357-byte program,
>
> Well, without being the accountant, considering the “more than 22,000
> nodes”, the revision fa685c8 contains ~23,000 packages and more than
> 1700 packages depends on GHC (Haskell) which is not bootstrapped from
> this 357-byte program, AFAIK.

Yeah, IWBN if someone would fix that and make the story more accurate
;-)

> $ guix refresh -l ghc@9.2 | cut -f1 -d':'

[..]

> In addition, that’s similar for ~450 packages relying on OCaml.
>
> Bah, I am nitpicking.  Am I? :-)

Yeah, but most enjoyably so :-)  Also, it's nice to know that someone
checked we're not telling too big a lie.

> What achievement this bootstrap story!  Thanks to all the people
> involved.  Back on FOSDEM 2017, I remember “Mes -- Maxwell's Equations
> of Software An attempt at dissolving bootstrap binaries” [1].  Thanks to
> this talk, I had this kind of revelation:
>
> Yes, that was the big revelation to me when I was in graduate
> school—when I finally understood that the half page of code on
> the bottom of page 13 of the Lisp 1.5 manual was Lisp in
> itself. These were “Maxwell’s Equations of Software!”
>
> – Alan Kay – 
>
> Then, I got the point with Yogurt metaphor [2] on FOSDEM 2019.  Anyway!

Lovely.  Thanks for you comments, most appreciated!

Janneke

-- 
Janneke Nieuwenhuizen   | GNU LilyPond https://LilyPond.org
Freelance IT https://www.JoyOfSource.com | Avatar® https://AvatarAcademy.com



Re: Blog post on the Full-Source Bootstrap

2023-04-27 Thread Simon Tournier
Hi Janneke,

On mer., 26 avril 2023 at 16:12, Janneke Nieuwenhuizen  wrote:

>   
> https://gnu.org/software/guix/blog/2023/the-full-source-bootstrap-building-from-source-all-the-way-down/

Really cool!


Maybe I misread the wording:

If you run guix pull today, you get a package graph of more than
22,000 nodes rooted in a 357-byte program
or
First, while the package graph is rooted in a 357-byte program,

Well, without being the accountant, considering the “more than 22,000
nodes”, the revision fa685c8 contains ~23,000 packages and more than
1700 packages depends on GHC (Haskell) which is not bootstrapped from
this 357-byte program, AFAIK.

--8<---cut here---start->8---
$ guix refresh -l ghc@9.2 | cut -f1 -d':'
Building the following 569 packages would ensure 1712 dependent packages are 
rebuilt
--8<---cut here---end--->8---

Because Pandoc, it appears in many non-Haskell packages, here an example
about R and bioinformatics:

--8<---cut here---start->8---
$ guix show r-catalyst | recsel -p synopsis
synopsis: Cytometry data analysis tools  

$ guix graph --path r-catalyst ghc@9.2 -t bag-emerged
r-catalyst@1.22.0
r-dplyr@1.1.1
r-pillar@1.9.0
r-utf8@1.2.3
r-rmarkdown@2.21
pandoc@2.19.2
ghc@9.2.5
--8<---cut here---end--->8---

In addition, that’s similar for ~450 packages relying on OCaml.

Bah, I am nitpicking.  Am I? :-)


What achievement this bootstrap story!  Thanks to all the people
involved.  Back on FOSDEM 2017, I remember “Mes -- Maxwell's Equations
of Software An attempt at dissolving bootstrap binaries” [1].  Thanks to
this talk, I had this kind of revelation:

Yes, that was the big revelation to me when I was in graduate
school—when I finally understood that the half page of code on
the bottom of page 13 of the Lisp 1.5 manual was Lisp in
itself. These were “Maxwell’s Equations of Software!”

– Alan Kay – 

Then, I got the point with Yogurt metaphor [2] on FOSDEM 2019.  Anyway!

Thank you.

Cheers,
simon

1: https://archive.fosdem.org/2017/schedule/event/guixsdbootstrap/
2: https://archive.fosdem.org/2019/schedule/speaker/jan_janneke_nieuwenhuizen/



Re: Blog post on the Full-Source Bootstrap

2023-04-26 Thread Tobias Platen
This looks good, I am interested in doing a port to the POWER ISA.
Currently on my OrangeCrab I only have one small C program running,
coldboot. Everything from the HDL to the BIOS should be Full-Source.

https://git.libre-soc.org/?p=ls2.git;a=blob;f=coldboot/coldboot.c 

Tobias

On Wed, 2023-04-26 at 16:12 +0200, Janneke Nieuwenhuizen wrote:
> Hello Guix!
> 
> Now that core-updates has been merged, the Full-Source Bootstrap has
> come to Guix!  This means we're building packages from source all the
> way down.  Read all about it in this new post:
> 
>  
> https://gnu.org/software/guix/blog/2023/the-full-source-bootstrap-building-from-source-all-the-way-down/
> 
> Janneke & Ludo
> 




Re: Drafting a Guix blog post on the FHS container

2023-01-04 Thread John Kehayias
Hi Jim,

On Wed, Jan 04, 2023 at 06:07 PM, Jim Newsome wrote:

> Thanks, looks good, and the command in your patch also works for me.
>

Great, thanks for testing!

> I agree that passing and exposing XAUTHORITY seems better. Experimentally, 
> sharing the directory
> read-only also works (using `--expose` instead of `--share`) also works, but 
> I'm not familiar enough with
> this mechanism to be confident that'll work for everyone, or whether making 
> it read-only is worth the
> fuss.
>

Ah, you are right, that seems to be just fine for VSCodium and Tor, in my quick 
test. I think I'll change that.

> Btw it turns out that `libevent` and `openssl@1` can be dropped; they're 
> already bundled. All together,
> here's my current "best" version:
>
> ```
> guix shell --container --network --emulate-fhs \
> --preserve='^DISPLAY$' --preserve='^XAUTHORITY$' --expose=$XAUTHORITY \
> alsa-lib bash coreutils dbus-glib file gcc:lib grep gtk+ \
> libcxx pciutils sed \
> -- ./start-tor-browser.desktop -v
> ```

Nice, thanks for that too! I tried eliminating a few random inputs, but they 
were needed. It is difficult sometimes to get a really minimal set, but this 
looks good to me.

John




Re: Drafting a Guix blog post on the FHS container

2023-01-04 Thread Jim Newsome


On Wed, Jan 4, 2023, at 5:47 PM, John Kehayias wrote:
> Hi Jim,
> 
> On Fri, Dec 16, 2022 at 05:39 PM, Jim Newsome wrote:
> 
> > Sorry for (presumably) breaking threading; I came across this online and
> > don't see a way to set my in-reply-to-email header properly.
> >
> > Anyways just thought I'd mention that I recently learned about this
> > feature, and was able to use it to get a downloaded [Tor Browser Bundle]
> > running with:
> >
> >
> > ```
> > guix shell \
> >--container \
> >--network \
> >--emulate-fhs \
> >--preserve='^DISPLAY$'
> >--share=/run/user/$(id -u)/gdm \
> >openssl@1 \
> >libevent \
> >pciutils \
> >dbus-glib \
> >bash \
> >libgccjit \
> >libcxx \
> >gtk+ \
> >coreutils \
> >grep \
> >sed \
> >file \
> >alsa-lib \
> >-- \
> >./start-tor-browser.desktop -v
> > ```
> >
> > `--preserve='^DISPLAY$'` and `--share=/run/user/$(id -u)/gdm` are to get
> > access to the display. I'm not sure the second parameter is universally
> > correct; I reverse-engineered it via roughly `ps aux | grep -- -auth`.
> >
> > The `-v` parameter to the browser script keeps it from trying to
> > background itself, which otherwise causes the container and browser to
> > terminate.
> >
> > It'd ultimately be nice to package the Tor Browser Bundle properly for
> > guix, but it's nice to be able to use it this way in the meantime.
> 
> Thanks again for this! I slightly modified it for the blog post, which you 
> can see in draft form at <https://issues.guix.gnu.org/60112>. I used 
> 'gcc:lib' instead of 'libgccjit' as it is smaller, and changed the needed 
> display options to be like the previous ones I had. Yours didn't work for me 
> since it looks like it relies on sharing something from GDM, which I don't 
> use. But do let me know if my version doesn't work for you.
> 
> Also gave you credit for this example; if you prefer not to be mentioned by 
> name/link to the mailing list for any reason, just let me know.
> 
> Oh, and we do have some (older) patches for building the Tor Browser from 
> source, but I don't know if they currently work: 
> <https://issues.guix.gnu.org/42380> Your example was great though, something 
> very useful!
> 
> John

Thanks, looks good, and the command in your patch also works for me.

I agree that passing and exposing XAUTHORITY seems better. Experimentally, 
sharing the directory read-only also works (using `--expose` instead of 
`--share`) also works, but I'm not familiar enough with this mechanism to be 
confident that'll work for everyone, or whether making it read-only is worth 
the fuss.

Btw it turns out that `libevent` and `openssl@1` can be dropped; they're 
already bundled. All together, here's my current "best" version:

```
guix shell --container --network --emulate-fhs \
--preserve='^DISPLAY$' --preserve='^XAUTHORITY$' --expose=$XAUTHORITY \
alsa-lib bash coreutils dbus-glib file gcc:lib grep gtk+ \
libcxx pciutils sed \
-- ./start-tor-browser.desktop -v
```

Re: Drafting a Guix blog post on the FHS container

2023-01-04 Thread John Kehayias
Hi Jim,

On Fri, Dec 16, 2022 at 05:39 PM, Jim Newsome wrote:

> Sorry for (presumably) breaking threading; I came across this online and
> don't see a way to set my in-reply-to-email header properly.
>
> Anyways just thought I'd mention that I recently learned about this
> feature, and was able to use it to get a downloaded [Tor Browser Bundle]
> running with:
>
>
> ```
> guix shell \
>--container \
>--network \
>--emulate-fhs \
>--preserve='^DISPLAY$'
>--share=/run/user/$(id -u)/gdm \
>openssl@1 \
>libevent \
>pciutils \
>dbus-glib \
>bash \
>libgccjit \
>libcxx \
>gtk+ \
>coreutils \
>grep \
>sed \
>file \
>alsa-lib \
>-- \
>./start-tor-browser.desktop -v
> ```
>
> `--preserve='^DISPLAY$'` and `--share=/run/user/$(id -u)/gdm` are to get
> access to the display. I'm not sure the second parameter is universally
> correct; I reverse-engineered it via roughly `ps aux | grep -- -auth`.
>
> The `-v` parameter to the browser script keeps it from trying to
> background itself, which otherwise causes the container and browser to
> terminate.
>
> It'd ultimately be nice to package the Tor Browser Bundle properly for
> guix, but it's nice to be able to use it this way in the meantime.

Thanks again for this! I slightly modified it for the blog post, which you can 
see in draft form at <https://issues.guix.gnu.org/60112>. I used 'gcc:lib' 
instead of 'libgccjit' as it is smaller, and changed the needed display options 
to be like the previous ones I had. Yours didn't work for me since it looks 
like it relies on sharing something from GDM, which I don't use. But do let me 
know if my version doesn't work for you.

Also gave you credit for this example; if you prefer not to be mentioned by 
name/link to the mailing list for any reason, just let me know.

Oh, and we do have some (older) patches for building the Tor Browser from 
source, but I don't know if they currently work: 
<https://issues.guix.gnu.org/42380> Your example was great though, something 
very useful!

John




Re: Drafting a Guix blog post on the FHS container

2022-12-25 Thread John Kehayias
Hi all,

On Fri, Dec 23, 2022 at 03:04 AM, Csepp wrote:

> Jim Newsome  writes:
>
>> Sorry for (presumably) breaking threading; I came across this online
>> and don't see a way to set my in-reply-to-email header properly.
>>
>> Anyways just thought I'd mention that I recently learned about this
>> feature, and was able to use it to get a downloaded [Tor Browser
>> Bundle] running with:
>>
>>
>> ```
>> guix shell \
>>   --container \
>>   --network \
>>   --emulate-fhs \
>>   --preserve='^DISPLAY$'
>>   --share=/run/user/$(id -u)/gdm \
>>   openssl@1 \
>>   libevent \
>>   pciutils \
>>   dbus-glib \
>>   bash \
>>   libgccjit \
>>   libcxx \
>>   gtk+ \
>>   coreutils \
>>   grep \
>>   sed \
>>   file \
>>   alsa-lib \
>>   -- \
>>   ./start-tor-browser.desktop -v
>> ```
>>
>> `--preserve='^DISPLAY$'` and `--share=/run/user/$(id -u)/gdm` are to
>> get access to the display. I'm not sure the second parameter is
>> universally correct; I reverse-engineered it via roughly `ps aux |
>> grep -- -auth`.
>>

Thanks for the example! That's a slight variation of what I've seen/used for 
display access, as you can see in my previous examples and the current draft of 
the blog post: <https://issues.guix.gnu.org/60112>

>> The `-v` parameter to the browser script keeps it from trying to
>> background itself, which otherwise causes the container and browser to
>> terminate.
>>
>> It'd ultimately be nice to package the Tor Browser Bundle properly for
>> guix, but it's nice to be able to use it this way in the meantime.
>>

Yes, that's handy, and some extra isolation via the container too.

>> -Jim
>>
>> [Tor Browser Bundle]: <https://www.torproject.org/download/>
>
> Any idea how to use this for running appimages?  Or anything that
> requires FUSE in general?

Please see my previous emails and the current draft, linked above, for exactly 
that. In short, use '--appimage-extract-and-run' instead of letting the 
appimage try to mount itself via FUSE.

For FUSE, one can't run it directly in the container as it is setuid. You can 
use flatpak-spawn from flatpak-xdg-utils though, to work around that, sort of. 
To be merged as soon as I have a chance (sadly dealing with an unexpected 
crisis at home these past weeks so I haven't committed anything yet): 
<https://issues.guix.gnu.org/59825>

Unfortunately the container that does this, or actually any created before the 
mounting, will not see the mounted appimage. I think this has something to do 
with namespaces and how containers are created, but I'm not sure the details. 
You can see some discussion of this in the IRC logs, but I can provide more 
summary later if you are interested, roughly 
<https://logs.guix.gnu.org/guix/2022-12-08.log#211221> and 
<https://logs.guix.gnu.org/guix/2022-12-09.log#020202> has the discussion.

John




Re: Drafting a Guix blog post on the FHS container

2022-12-22 Thread Csepp


Jim Newsome  writes:

> Sorry for (presumably) breaking threading; I came across this online
> and don't see a way to set my in-reply-to-email header properly.
>
> Anyways just thought I'd mention that I recently learned about this
> feature, and was able to use it to get a downloaded [Tor Browser
> Bundle] running with:
>
>
> ```
> guix shell \
>   --container \
>   --network \
>   --emulate-fhs \
>   --preserve='^DISPLAY$'
>   --share=/run/user/$(id -u)/gdm \
>   openssl@1 \
>   libevent \
>   pciutils \
>   dbus-glib \
>   bash \
>   libgccjit \
>   libcxx \
>   gtk+ \
>   coreutils \
>   grep \
>   sed \
>   file \
>   alsa-lib \
>   -- \
>   ./start-tor-browser.desktop -v
> ```
>
> `--preserve='^DISPLAY$'` and `--share=/run/user/$(id -u)/gdm` are to
> get access to the display. I'm not sure the second parameter is
> universally correct; I reverse-engineered it via roughly `ps aux |
> grep -- -auth`.
>
> The `-v` parameter to the browser script keeps it from trying to
> background itself, which otherwise causes the container and browser to
> terminate.
>
> It'd ultimately be nice to package the Tor Browser Bundle properly for
> guix, but it's nice to be able to use it this way in the meantime.
>
> -Jim
>
> [Tor Browser Bundle]: https://www.torproject.org/download/

Any idea how to use this for running appimages?  Or anything that
requires FUSE in general?



Re: Drafting a Guix blog post on the FHS container

2022-12-19 Thread Ludovic Courtès
Hi Jim,

Jim Newsome  skribis:

> Anyways just thought I'd mention that I recently learned about this
> feature, and was able to use it to get a downloaded [Tor Browser
> Bundle] running with:

That’s another good example, thanks for sharing!  It’s especially
interesting because the Tor project vets the binaries they provide.

Ludo’.



re: Drafting a Guix blog post on the FHS container

2022-12-18 Thread Jim Newsome
Sorry for (presumably) breaking threading; I came across this online and 
don't see a way to set my in-reply-to-email header properly.


Anyways just thought I'd mention that I recently learned about this 
feature, and was able to use it to get a downloaded [Tor Browser Bundle] 
running with:



```
guix shell \
  --container \
  --network \
  --emulate-fhs \
  --preserve='^DISPLAY$'
  --share=/run/user/$(id -u)/gdm \
  openssl@1 \
  libevent \
  pciutils \
  dbus-glib \
  bash \
  libgccjit \
  libcxx \
  gtk+ \
  coreutils \
  grep \
  sed \
  file \
  alsa-lib \
  -- \
  ./start-tor-browser.desktop -v
```

`--preserve='^DISPLAY$'` and `--share=/run/user/$(id -u)/gdm` are to get 
access to the display. I'm not sure the second parameter is universally 
correct; I reverse-engineered it via roughly `ps aux | grep -- -auth`.


The `-v` parameter to the browser script keeps it from trying to 
background itself, which otherwise causes the container and browser to 
terminate.


It'd ultimately be nice to package the Tor Browser Bundle properly for 
guix, but it's nice to be able to use it this way in the meantime.


-Jim

[Tor Browser Bundle]: https://www.torproject.org/download/



Re: Drafting a Guix blog post on the FHS container

2022-12-15 Thread John Kehayias
Hi again!

On Thu, Dec 15, 2022 at 03:53 PM, Ludovic Courtès wrote:

> Hello!
>
> John Kehayias  skribis:
>
>> First, let's dive right into a big one: the popular VSCodium editor. This is 
>> a freely
>> licensed build of VS Code: 
>> 
>>
>> This comes in AppImage format. Downloading it and making it executable (with 
>> a 'chmod
>> +x') I can run it in a container as
>>
>> guix shell -CNF -D ungoogled-chromium gcc:lib \
>>  --preserve='^DISPLAY$' --preserve='^XAUTHORITY$' --share=$XAUTHORITY \
>>  --preserve='^DBUS_' --expose=/var/run/dbus \
>>  --expose=/sys/dev --expose=/sys/devices --expose=/dev/dri \
>>  -- ./VSCodium-1.74.0.22342.glibc2.17-x86_64.AppImage 
>> --appimage-extract-and-run
>
> The code in that AppImage is free software, right?
>

The usual disclaimer of IANAL, but I linked to the part of their readme which 
describes the project licensing. So it seems all free to me, similar maybe to 
ungoogled-chromium: all the source without the telemetry and non-free branding, 
etc. But please do check.

>> Another example is to get the latest nightly builds of Rust, via 
>> 
>
> That’s a nice one too!
>
>> Happy to try other examples and to hear feedback on these!
>
> I think these are two good examples, likely to correspond to the kind of
> thing people may want to try.
>

Great, thanks!

>>> Actually you can use or get inspiration from this animated GIF if you
>>> like:
>>>
>>>   
>>>
>>
>> Either I forgot to save this or wasn't able to access it before, and can't 
>> access it
>> now.
>
> Yeah, the TLS setup on that machine is broken, so you’d have to “Accept
> the risk and continue”; I sent you a copy off-list.
>

Thank you. I included it but realize now I forgot to add credit, so I can do 
that later.

> If we release on Monday, it would be great to have it published…
> tomorrow (Friday).  Otherwise next Friday maybe?
>

It has gotten crazy here this week, hence my slow response (and not using my 
new found commit powers yet!). I've just sent the draft post which is the 
previous version with changes you suggested and a slightly expanded version of 
the examples from my previous message.



I did some manual tweaking to the markdown export but I think it should look 
okay. Wasn't sure about the footnotes or if that should just be in-text. Oh, 
and now realized may want it with a fill column rather than long lines. (It 
always wraps nicely on my Emacs setup so I forget.)

I should be able to make quick edits tomorrow (it is very late here now), but 
we don't need to rush if there are other changes or checks anyone wants to 
make. I can also record some screen grabs if that is helpful.

> Thanks!
>
> Ludo’.

Thanks for the input, wish I had some more time this past week to have gotten 
this done earlier.

John




Re: Drafting a Guix blog post on the FHS container

2022-12-15 Thread Ludovic Courtès
Hello!

John Kehayias  skribis:

> First, let's dive right into a big one: the popular VSCodium editor. This is 
> a freely licensed build of VS Code: 
> 
>
> This comes in AppImage format. Downloading it and making it executable (with 
> a 'chmod +x') I can run it in a container as
>
> guix shell -CNF -D ungoogled-chromium gcc:lib \
>  --preserve='^DISPLAY$' --preserve='^XAUTHORITY$' --share=$XAUTHORITY \
>  --preserve='^DBUS_' --expose=/var/run/dbus \
>  --expose=/sys/dev --expose=/sys/devices --expose=/dev/dri \
>  -- ./VSCodium-1.74.0.22342.glibc2.17-x86_64.AppImage 
> --appimage-extract-and-run

The code in that AppImage is free software, right?

> Another example is to get the latest nightly builds of Rust, via 
> 

That’s a nice one too!

> Happy to try other examples and to hear feedback on these!

I think these are two good examples, likely to correspond to the kind of
thing people may want to try.

>> Actually you can use or get inspiration from this animated GIF if you
>> like:
>>
>>   
>>
>
> Either I forgot to save this or wasn't able to access it before, and can't 
> access it now.

Yeah, the TLS setup on that machine is broken, so you’d have to “Accept
the risk and continue”; I sent you a copy off-list.

If we release on Monday, it would be great to have it published…
tomorrow (Friday).  Otherwise next Friday maybe?

Thanks!

Ludo’.



Re: Dissecting Guix -- blog post series

2022-12-12 Thread (
Heya,

On Mon Dec 12, 2022 at 1:43 AM GMT, Mekeor Melire wrote:
> Or auto-fill-mode? :)

I'm pretty new to Emacs, so I dunno which way is best -.o.-

> Personally, I felt kind of fooled at that point, because it felt 
> like I had made needless efforts to read an irrelevant code 
> snippet.

Fair enough, but I also think if I remove it people will be left wondering how
``recursive?'' is serialised.

I think that code snippet might be irrelevant anyway, since I can just show the
result of serialising a derivation with ``recursive? #t''.

> By the way, sorry for the malformatted e-mail; I was tweaking 
> around with my mail-client's settings. (I'm now using f=f and 
> non-broken lines.) Hope my mails are well readable at your end. 
> Please let me know if they're not.

They're perfectly readable, but the lines are quite short.

-- (


signature.asc
Description: PGP signature


Re: Dissecting Guix -- blog post series

2022-12-12 Thread Bengt Richter
Hi,

On +2022-12-09 17:25:35 +, ( wrote:
> Heya,
> 
> On Fri Dec 9, 2022 at 9:32 AM GMT,  wrote:
> > How does a gullible noob like me know what the dangers might be, (e.g. 
> > http:)
> > and how to avoid (most of) them by finding a guix version that has been
> > gone through with a fine-tooth comb by trusted guix devs and has been
> > re-hosted at gitlab or gnu.org, etc ... for added security?
> 
> Sorry, I don't really understand; how is this relevant to derivations? :)
> 
> -- (

Maybe I mis-imagine your assumptions about your audience.

For myself, I would like an emacs M-x idiot-mode
so I could run a boot-bricker-test.sh script someone
has posted, without worrying that in plain cli context,
it will /actually/ brick my machine :)

I am assuming if your lowlevel examples are really good,
they will be used as bases for cut/paste variants that people
will then post and implicitly prompt each other to try..

I don't trust that everything thus posted
will be both benevolent and competently avoiding security vulns.

I can't even trust my own stuff. I make too many mistakes :)

So, narrowly focusing on derivations, maybe trust is not technically
relevant, but in the larger social context gullible noobs like me
need all the help we can get about recognizing potentially dangerous
code.

And I think derivations can potentially contain or generate or activate
code one should not trust.

So that's how I see asking for trust info being relevant to derivations :)
--
Regards,
Bengt Richter




Re: Drafting a Guix blog post on the FHS container

2022-12-11 Thread John Kehayias
Hi Ludo’ and Guixers,

Before I get to some quick responses, I wanted to share some FHS container 
examples I've been testing. I hope others can try as I did get a response on 
IRC that one didn't work as expected. I think it might be when needing to 
expose some of the host for things like hardware access.

First, let's dive right into a big one: the popular VSCodium editor. This is a 
freely licensed build of VS Code: 
<https://github.com/VSCodium/vscodium#why-does-this-exist>

This comes in AppImage format. Downloading it and making it executable (with a 
'chmod +x') I can run it in a container as

--8<---cut here---start->8---
guix shell -CNF -D ungoogled-chromium gcc:lib \
 --preserve='^DISPLAY$' --preserve='^XAUTHORITY$' --share=$XAUTHORITY \
 --preserve='^DBUS_' --expose=/var/run/dbus \
 --expose=/sys/dev --expose=/sys/devices --expose=/dev/dri \
 -- ./VSCodium-1.74.0.22342.glibc2.17-x86_64.AppImage 
--appimage-extract-and-run
--8<---cut here---end--->8---

where the first line is a cheat I like to get lots of libraries often needed 
for graphical applications (development inputs of ungoogled-chromium) though it 
is a bit overkill if the AppImage does actually bundle everything (they 
don't!). Next line is for display on the host's X server, the one after for 
DBus communication, and lastly exposing some of the host hardware for rendering 
(perhaps can be disabled in VSCodium somehow?). This is what may need some 
tweaking for others, but I'm not sure.

Note that we can't run an AppImage with out the 'appimage-extract-and-run' as 
it will want to use fuse to mount the image which we can't do from the 
container. I have some more details on this and actually did get this to mount, 
though it wasn't visible from the container, in the coming blog post draft.

Another example is to get the latest nightly builds of Rust, via 
<https://rustup.rs/>

--8<---cut here---start->8---
$ mkdir ~/temphome

$ guix shell -NCF bash coreutils curl grep nss-certs gcc:lib gcc-toolchain 
pkg-config glib cairo atk pango@1.48.10 gdk-pixbuf gtk+ git 
--share=$HOME/temphome=$HOME

~/temphome [env]$ curl --proto '=https' --tlsv1.2 -sSf <https://sh.rustup.rs> | 
sh
--8<---cut here---end--->8---

where I first created a '~/temphome' directory to use as $HOME in the container 
and included a bunch of libraries for the next example.

Finally, we can build a Rust project of desktop widgets, 
<https://github.com/elkowar/eww>, following their directions 
<https://elkowar.github.io/eww/> Ultimately this uses just 'cargo build 
--release' and this builds after downloading all the needed libraries. It needs 
similar stuff from the host as the VSCodium example to get things to run and 
display, which I'll detail in the blog post.

Happy to try other examples and to hear feedback on these!

Now, back to the rest of the email.

On Tue, Dec 06, 2022 at 11:41 AM, Ludovic Courtès wrote:

> Hello!
>
> John Kehayias  skribis:
>
>> One question: what is appropriate or recommended for examples concerning 
>> things like
>> pre-built binaries? As an example, I had tested the FHS container by running 
>> the Siril
>> appimage, which has since been packaged for Guix (nice work!). There are 
>> ones that I
>> don't see that happening for anytime soon, like an Electron-based app. 
>> Something like
>> VSCodium is very popular, free (as in freedom and I believe the FSDG sense), 
>> but just
>> not something you can package fully from source due to JavaScript as I 
>> understand it. It
>> runs in the FHS container.
>
> A good example might be a free application not currently packaged in
> Guix, for example due to being full of JavaScript, or nightly builds as
> you wrote provided by an upstream project.
>

I used VSCodium above, though honestly I've only seen that it opens and seems 
to work fine. Open to other suggestions but that one will probably get some 
attention :)

>> Here is a current (rough!) draft. For the ease of plain text email I've 
>> exported from
>> the org source to text with some light edits:
>
> Note that the blog takes Markdown¹, but hopefully the Org-to-markdown
> export works well.
>
> ¹ <https://git.savannah.gnu.org/cgit/guix/guix-artwork.git/tree/website/posts>
>

Thanks, and I saw simon's email about this as well. I may have to tweak the 
Markdown a little, but should work easily enough.

> The post looks great to me!  I have minor suggestions below:
>

Thank you!

>> GNU Guix is different from most other GNU/Linux distributions and
>> perhaps nowhere is that more obvious than the organization of the
>> filesystem: Guix does not conform to the [F

Re: Drafting a Guix blog post on the FHS container

2022-12-11 Thread John Kehayias
Hi simon,

On Fri, Dec 09, 2022 at 06:56 PM, zimoun wrote:

> Hi,
>
> On Mon, 05 Dec 2022 at 02:32, John Kehayias  
> wrote:
>
>> Here is a current (rough!) draft. For the ease of plain text email
>> I've exported from the org source to text with some light edits:
>
> Nice!  If you can turn the draft into Markdown and format a patch for
> guix-artwork [1] under website/drafts, it could be awesome! :-)
>
> Then you could send the patch to guix-devel, guix-blog or guix-patches.
>
> 1: 
>
>

Ah, thanks for this info, I'll take care of that. In the meantime I'll at least 
send out the current examples I've been using, as I want to make sure they work 
pretty generally. Of course they should since they will produce the same 
environment (until perhaps what is run in the environment), but a few of the 
commands may depend on what needs to be shared from the host. For example, to 
get graphical support.

I'll get the markdown formatted patch sent too and update everyone on that.

Thanks!
John




Re: Drafting a Guix blog post on the FHS container

2022-12-11 Thread John Kehayias
Hi Wojtek,

Thanks for your input!

On Mon, Dec 05, 2022 at 07:51 AM, Wojtek Kosior wrote:

> Hello,
>
>
>> Hi Guixers!
>>
>> I've started working on a little blog post about our new
>> --emulate-fhs option for Guix containers. In short, this sets up an
>> FHS-like (Filesystem Hierarchy Standard) container which has things
>> like /lib and /bin.
>>
>> I would like to get some suggestions on good examples to include.
>> More general feedback, questions, and other comments are also
>> welcome! I've included a rough draft of the beginning of the post,
>> leading up to showing some examples.
>
> Hi,
>
> One recent real-life example of `--emulate-fhs` being useful is with
> Python's virtualenv. I mentioned it in one help-guix thread which
> you can see here[1] :)
>
> Wojtek
>
> [1] <https://lists.gnu.org/archive/html/help-guix/2022-11/msg00305.html>
>

I took a look but wasn't sure the exact commands I would use to show this, I 
guess it is when invoking vitualenv and using Guix python packages? I'm not a 
virtualenv user, so apologies for the simple question!

Though I'm happy to generally mention this as an example use and point to the 
linked email thread.

Thanks again,
John




Re: Dissecting Guix -- blog post series

2022-12-11 Thread Mekeor Melire

2022-12-11 10:08 pa...@disroot.org:


On Sat Dec 10, 2022 at 9:25 PM GMT, Mekeor Melire wrote:

> By the way, the text does not seem to strictly fill columns at 
> a certain line width. So I did not bother to fill columns in 
> the "patch".


Right, I should set up FILL-COLUMNS-INDICATOR... :)


Or auto-fill-mode? :)

> If the purpose is out of scope, then we should not dive in 
> that deeply. Especially, I'd suggest skip the code snippet.


I'm not sure about this.


Personally, I felt kind of fooled at that point, because it felt 
like I had made needless efforts to read an irrelevant code 
snippet.


> I think an example for invoking read-derivation-from-file 
> would round up this tutorial really nicely because it'd close 
> the circle between .drv-files and -objects.


Okay!  And one for write-derivation, too.


Sure :)

By the way, sorry for the malformatted e-mail; I was tweaking 
around with my mail-client's settings. (I'm now using f=f and 
non-broken lines.) Hope my mails are well readable at your end. 
Please let me know if they're not.




Re: Dissecting Guix -- blog post series

2022-12-11 Thread (
Heya,

On Sat Dec 10, 2022 at 9:25 PM GMT, Mekeor Melire wrote:
> I think it'd also be fine to come up with the titles during the process of 
> writing as sometimes that process itself is insightful. E.g. I could imagine 
> parts 2 and 4 to collapse. Maybe, maybe not, you'll see.

Perhaps.  I think monads are complex enough to warrant their own post, though.

> How'd this part differ from section "12.18 Defining Services" of the manual?

Along with a low-level description of the workings of services, it'd contain a
complex, concrete example of a service.  The manual mostly has an API reference
and some high-level-ish examples.

> How'd this part differ from sections 22 and "22.6 Submitting Patches" from 
> the manual?

Again, it'd be more concrete than what the manual shows.  It'd explain the
process by demonstrating the development of an *actual patch*, and showing how
it could be sent to guix-patc...@gnu.org.

> By the way, the text does not seem to strictly fill columns at a certain line 
> width. So I did not bother to fill columns in the "patch".

Right, I should set up FILL-COLUMNS-INDICATOR... :)

> If the purpose is out of scope, then we should not dive in that deeply. 
> Especially, I'd suggest skip the code snippet.

I'm not sure about this.  

> Here you write "pretty simple". Later you also write "self-explanatory" and 
> "obviously". I suggest to let the reader decide what's simple.

Fair.

> Before this point, the record fields have been called '"argument"'s all the 
> time. I think it's not nice style to carry on a quoted term through many 
> paragraphs like this. Let's simply write "record field" all the time, instead.

This is fair too :)

> I think an example for invoking read-derivation-from-file would round up this 
> tutorial really nicely because it'd close the circle between .drv-files and 
> -objects.

Okay!  And one for write-derivation, too.

> Here, in the conclusion, IMHO, there could be another brief listing of all 
> fields of a derivation.

Good idea.

-- (


signature.asc
Description: PGP signature


Re: Dissecting Guix -- blog post series

2022-12-10 Thread Mekeor Melire
2022-12-08 18:24 pa...@disroot.org:

> Some of you may have seen on IRC that I've been writing a post for the Guix 
> blog that I hope will form the first part of a series. This series aims to 
> dissect the internals of Guix, from bottom to top.

Great, I'm looking forward to read it! Especially, personally, I'm eager for 
the rather fundamental concepts of Guix (and Nix).

> Perhaps they could go in the cookbook once the series is done?

Yes, I personally think the content should be published at two places at the 
same time: OTOH, it should either be incorporated into either the manual or the 
cookbook; and OTOH, it should be published as a blog-post. The blog-post should 
also link to the respective section of the manual or cookbook in a preamble.

> * Dissecting Guix, Part 1: Derivations
> * Dissecting Guix, Part 2: The Humble G-Expression
> * Dissecting Guix, Part 3: Packages
> * Dissecting Guix, Part 4: Monads
> * Dissecting Guix, Part 5: Profiles and Search Paths
> * Dissecting Guix, Part 6: Goings-On in the Build Container
> * Dissecting Guix, Part 7: Record Types
> * Dissecting Guix, Part 8: Substitutes and Grafts
> * Dissecting Guix, Part 9: Cross-Compilation

I think it'd also be fine to come up with the titles during the process of 
writing as sometimes that process itself is insightful. E.g. I could imagine 
parts 2 and 4 to collapse. Maybe, maybe not, you'll see.

> * Dissecting Guix, Part 10: Services
>
> Walks you through the process of creating a service, and thouroughly explains 
> system configuration.

How'd this part differ from section "12.18 Defining Services" of the manual?

> * Dissecting Guix, Part 11: Home Services
> * Dissecting Guix, Part 12: Writing a Subcommand
> * Dissecting Guix, Part 13: Lending a Hand
>
> How to edit the Guix source code and submit patches to be reviewed by the 
> lovely Guix community!

How'd this part differ from sections 22 and "22.6 Submitting Patches" from the 
manual?

Now, as for the actual article. Firstly, I added some comments below. Secondly, 
I created a "patch" suggesting some changes.

By the way, the text does not seem to strictly fill columns at a certain line 
width. So I did not bother to fill columns in the "patch".

> title: Dissecting Guix, Part 1: Derivations and Derivation
> date: TBC
> author: (
> tags: Dissecting Guix, Functional package management, Programming interfaces, 
> Scheme API
> ---
> To a new user, Guix's functional architecture can seem quite alien, and
> possibly offputting.  With a combination of extensive `#guix`-querying,
> determined manual-reading, and plenty of source-perusing, they may
> eventually figure out how everything fits together by themselves, but this
> can be frustrating and often takes a fairly long time.
>
> However, once you peel back the layers, the "Nix way" is actually rather
> elegant, if perhaps not as simple as the mutable, imperative style
> implemented by the likes of [`dpkg`](https://wiki.debian.org/dpkg) and,
> [`pacman`](https://wiki.archlinux.org/title/pacman).  This series of blog
> posts will cover basic Guix concepts, taking a "ground-up" approach by
> dealing with lower-level concepts first, and hopefully make those months of
> information-gathering unnecessary.
>
> Before we dig in to Guix-specific concepts, we'll need to learn about one
> inherited from [Nix](https://nixos.org), the original functional package
> manager and the inspiration for Guix; the idea of a _derivation_ and its
> corresponding _store items_.
>
> These concepts were originally described by Eelco Dolstra, the author of Nix,
> in their [PhD thesis](https://edolstra.github.io/pubs/phd-thesis.pdf); see
> _§ 2.1 The Nix store_ and _§ 2.4 Store Derivations_.
>
> # Store Items
>
> As you almost certainly know, everything that Guix builds is stored in the
> _store_, which is almost always the `/gnu/store` directory.  It's the job of
> the 
> [`guix-daemon`](https://guix.gnu.org/manual/en/html_node/Invoking-guix_002ddaemon.html)
> to manage the store and build things.  If you run
> [`guix build 
> PKG`](https://guix.gnu.org/manual/en/html_node/Invoking-guix-build.html),
> `PKG` will be built or downloaded from a substitute server if available, and
> a path to an item in the store will be displayed.
>
> ```
> $ guix build irssi
> /gnu/store/v5pd69j3hjs1fck4b5p9hd91wc8yf5qx-irssi-1.4.3
> ```
>
> This item contains the final result of building [`irssi`](https://irssi.org).
> Let's peek inside:
>
> ```
> $ ls $(guix build irssi)
> bin/  etc/  include/  lib/  share/
> $ ls $(guix build irssi)/bin
> irssi*
> ```
>
> `irssi` is quite a simple package.  What about a more complex one, like
> [`glib`](https://doc

Re: Drafting a Guix blog post on the FHS container

2022-12-09 Thread zimoun
Hi,

On Mon, 05 Dec 2022 at 02:32, John Kehayias  
wrote:

> Here is a current (rough!) draft. For the ease of plain text email
> I've exported from the org source to text with some light edits:

Nice!  If you can turn the draft into Markdown and format a patch for
guix-artwork [1] under website/drafts, it could be awesome! :-)

Then you could send the patch to guix-devel, guix-blog or guix-patches.

1: 


Cheers,
simon



Re: Dissecting Guix -- blog post series

2022-12-09 Thread (
Heya,

On Fri Dec 9, 2022 at 9:32 AM GMT,  wrote:
> How does a gullible noob like me know what the dangers might be, (e.g. http:)
> and how to avoid (most of) them by finding a guix version that has been
> gone through with a fine-tooth comb by trusted guix devs and has been
> re-hosted at gitlab or gnu.org, etc ... for added security?

Sorry, I don't really understand; how is this relevant to derivations? :)

-- (


signature.asc
Description: PGP signature


Re: Dissecting Guix -- blog post series

2022-12-09 Thread bokr
Hi,

On +2022-12-09 07:33:16 +, ( wrote:
> On Fri Dec 9, 2022 at 7:31 AM GMT, 宋文武 wrote:
> > I think it's missing what "build-derivations" do, or "Part 0: Store".
> 
> Hmm, do you mean adding an example of building a derivation in Scheme with
> ``build-derivations''?  I'll definitiely add that :)
> 
> -- (

Where is a "What can I trust?" section?

I.e., when some well-meaning enthusiast says,

--8<---cut here---start->8---
"Can we package the "warm-fuzzy-floss-name" package that they have at
http://www.lesser-known-but-nice-sounding-distro.org/fantabulous/;
--8<---cut here---end--->8---

How does a gullible noob like me know what the dangers might be, (e.g. http:)
and how to avoid (most of) them by finding a guix version that has been
gone through with a fine-tooth comb by trusted guix devs and has been
re-hosted at gitlab or gnu.org, etc ... for added security?

--
Regards,
Bengt Richter




Re: Dissecting Guix -- blog post series

2022-12-08 Thread (
On Fri Dec 9, 2022 at 7:31 AM GMT, 宋文武 wrote:
> I think it's missing what "build-derivations" do, or "Part 0: Store".

Hmm, do you mean adding an example of building a derivation in Scheme with
``build-derivations''?  I'll definitiely add that :)

-- (


signature.asc
Description: PGP signature


Re: Dissecting Guix -- blog post series

2022-12-08 Thread 宋文武
"("  writes:

> Heya!
>
> Some of you may have seen on IRC that I've been writing a post for the Guix
> blog that I hope will form the first part of a series.  This series aims to
> dissect the internals of Guix, from bottom to top.  Perhaps they could go in
> the cookbook once the series is done?  My aim is to write the following posts
> (complete with cheesy titles :P), hopefully one per week:
>
> * Dissecting Guix, Part 1: Derivations
>
> Discusses derivations, the bottom layer of the Guix compilation tower, and
> dissects some example derivations.
>
> A draft of this post may be found below. Please feel free to critique! :)

Great, thank you!

I think it's missing what "build-derivations" do, or "Part 0: Store".



Dissecting Guix -- blog post series

2022-12-08 Thread (
Heya!

Some of you may have seen on IRC that I've been writing a post for the Guix
blog that I hope will form the first part of a series.  This series aims to
dissect the internals of Guix, from bottom to top.  Perhaps they could go in
the cookbook once the series is done?  My aim is to write the following posts
(complete with cheesy titles :P), hopefully one per week:

* Dissecting Guix, Part 1: Derivations

Discusses derivations, the bottom layer of the Guix compilation tower, and
dissects some example derivations.

A draft of this post may be found below. Please feel free to critique! :)

* Dissecting Guix, Part 2: The Humble G-Expression

Talks about g-expressions and why they're necessary, explains file-like objects,
and provides demonstrations of each kind of file-like.

* Dissecting Guix, Part 3: Packages

A walkthrough for package creation.

* Dissecting Guix, Part 4: Monads

``mlet'', ``>>='', ``define-monad'', ``return'', and all that.

* Dissecting Guix, Part 5: Profiles and Search Paths

Explores profiles and search paths.

* Dissecting Guix, Part 6: Goings-On in the Build Container

Explains build systems, examines a build script, and talks about what exactly
happens when a package is built.  Also demonstrates some of the
``(guix build utils)'' APIs.

* Dissecting Guix, Part 7: Record Types

Demonstrates the ``(guix records)'' API in all its glory.

* Dissecting Guix, Part 8: Substitutes and Grafts

Discusses substitutes, and that persistent thorn in our sides, grafting.

* Dissecting Guix, Part 9: Cross-Compilation

Building packages on architecture X for architecture Y, and how that all
works.

* Dissecting Guix, Part 10: Services

Walks you through the process of creating a service, and thouroughly explains
system configuration.

* Dissecting Guix, Part 11: Home Services

Similar to Part 9, except it's about ``guix home'', of course.

* Dissecting Guix, Part 12: Writing a Subcommand

Guides you through the process of adding a new command to Guix with the
extensions feature, demonstrating several utility APIs in the process.

* Dissecting Guix, Part 13: Lending a Hand

How to edit the Guix source code and submit patches to be reviewed by the
lovely Guix community!

-- (

title: Dissecting Guix, Part 1: Derivations and Derivation
date: TBC
author: (
tags: Dissecting Guix, Functional package management, Programming interfaces, 
Scheme API
---
To a new user, Guix's functional architecture can seem quite alien, and
possibly offputting.  With a combination of extensive `#guix`-querying,
determined manual-reading, and plenty of source-perusing, they may
eventually figure out how everything fits together by themselves, but this
can be frustrating and often takes a fairly long time.

However, once you peel back the layers, the "Nix way" is actually rather
elegant, if perhaps not as simple as the mutable, imperative style
implemented by the likes of [`dpkg`](https://wiki.debian.org/dpkg) and, 
[`pacman`](https://wiki.archlinux.org/title/pacman).  This series of blog
posts will cover basic Guix concepts, taking a "ground-up" approach by
dealing with lower-level concepts first, and hopefully make those months of
information-gathering unnecessary.

Before we dig in to Guix-specific concepts, we'll need to learn about one
inherited from [Nix](https://nixos.org), the original functional package
manager and the inspiration for Guix; the idea of a _derivation_ and its
corresponding _store items_.

These concepts were originally described by Eelco Dolstra, the author of Nix,
in their [PhD thesis](https://edolstra.github.io/pubs/phd-thesis.pdf); see
_§ 2.1 The Nix store_ and _§ 2.4 Store Derivations_.

# Store Items

As you almost certainly know, everything that Guix builds is stored in the
_store_, which is almost always the `/gnu/store` directory.  It's the job of
the 
[`guix-daemon`](https://guix.gnu.org/manual/en/html_node/Invoking-guix_002ddaemon.html)
to manage the store and build things.  If you run
[`guix build 
PKG`](https://guix.gnu.org/manual/en/html_node/Invoking-guix-build.html),
`PKG` will be built or downloaded from a substitute server if available, and
a path to an item in the store will be displayed.

```
$ guix build irssi
/gnu/store/v5pd69j3hjs1fck4b5p9hd91wc8yf5qx-irssi-1.4.3
```

This item contains the final result of building [`irssi`](https://irssi.org).
Let's peek inside:

```
$ ls $(guix build irssi)
bin/  etc/  include/  lib/  share/
$ ls $(guix build irssi)/bin
irssi*
```

`irssi` is quite a simple package.  What about a more complex one, like
[`glib`](https://docs.gtk.org/glib)?

```
$ guix build glib
/gnu/store/bx8qq76idlmjrlqf1faslsq6zjc6f426-glib-2.73.3-bin
/gnu/store/j65bhqwr7qq7l77nj0ahmk1f1ilnjr3a-glib-2.73.3-debug
/gnu/store/3pn4ll6qakgfvfpc4mw89qrrbsgj3jf3-glib-2.73.3-doc
/gnu/store/dvsk6x7d26nmwsqhnzws4iirb6dhhr1d-glib-2.73.3
/gnu/store/4c8ycz501n2d0xdi4blahvnbjhd5hpa8-glib-2.73.3-static
```

`glib` produces five `/gnu/store` items, because it's possible for a package

Re: Drafting a Guix blog post on the FHS container

2022-12-06 Thread Ludovic Courtès
Hello!

John Kehayias  skribis:

> One question: what is appropriate or recommended for examples concerning 
> things like pre-built binaries? As an example, I had tested the FHS container 
> by running the Siril appimage, which has since been packaged for Guix (nice 
> work!). There are ones that I don't see that happening for anytime soon, like 
> an Electron-based app. Something like VSCodium is very popular, free (as in 
> freedom and I believe the FSDG sense), but just not something you can package 
> fully from source due to JavaScript as I understand it. It runs in the FHS 
> container.

A good example might be a free application not currently packaged in
Guix, for example due to being full of JavaScript, or nightly builds as
you wrote provided by an upstream project.

> Here is a current (rough!) draft. For the ease of plain text email I've 
> exported from the org source to text with some light edits:

Note that the blog takes Markdown¹, but hopefully the Org-to-markdown
export works well.

¹ https://git.savannah.gnu.org/cgit/guix/guix-artwork.git/tree/website/posts

The post looks great to me!  I have minor suggestions below:

> GNU Guix is different from most other GNU/Linux distributions and
> perhaps nowhere is that more obvious than the organization of the
> filesystem: Guix does not conform to the [File Hierarchy Standard]
> (FHS). In practical terms, this means there is no global `/lib'

It’s “Filesystem Hierarchy Standard”.

> To that end, we've [recently added] a new option for Guix containers,
> `--emulate-fhs' (or `-F'). This will set up an environment in the

Perhaps s/Guix containers/`guix shell`/ and add a few words about what
‘guix shell --container’ does (you can link to the manual or blog post).

> container that follows FHS expectations, so that libraries are visible
> in `/lib' in the container, as an example. Additionally, for the more
> technically-minded, the [`glibc' used in this container] will read from
> a global cache in `/etc/ld.so.cache' contrary to the behavior in [Guix
> otherwise].

Since the ld.so.cache issue is more involved (compared to simply having
/lib and /bin), maybe you can move it after the “ls /bin” example?

> Contrast that with `/bin' on a Guix system:
> ,
>  ls /bin -la
> `
>
> lrwxrwxrwx  1  root  root   61  Dec  3  16:37  sh  ->  
> /gnu/store/d99ykvj3axzzidygsmdmzxah4lvxd6hw-bash-5.1.8/bin/sh

You can show ‘ls /lib’ too.  :-)

Actually you can use or get inspiration from this animated GIF if you
like:

  https://web.fdn.fr/~lcourtes/tmp/guix-shell-fhs.gif

> useful. For example, there may be software that is free and conforms to
> the FSDG Guix follows, yet is not feasible to be [packaged] by our

s/FSDG/Free System Distribution Guidelines (FSDG)/

Thanks,
Ludo’.



Re: Drafting a Guix blog post on the FHS container

2022-12-04 Thread Development of GNU Guix and the GNU System distribution.
Hello,


> Hi Guixers!
> 
> I've started working on a little blog post about our new
> --emulate-fhs option for Guix containers. In short, this sets up an
> FHS-like (Filesystem Hierarchy Standard) container which has things
> like /lib and /bin.
> 
> I would like to get some suggestions on good examples to include.
> More general feedback, questions, and other comments are also
> welcome! I've included a rough draft of the beginning of the post,
> leading up to showing some examples.

Hi,

One recent real-life example of `--emulate-fhs` being useful is with
Python's virtualenv. I mentioned it in one help-guix thread which
you can see here[1] :)

Wojtek

[1] https://lists.gnu.org/archive/html/help-guix/2022-11/msg00305.html

-- (sig_start)
website: https://koszko.org/koszko.html
PGP: https://koszko.org/key.gpg
fingerprint: E972 7060 E3C5 637C 8A4F  4B42 4BC5 221C 5A79 FD1A

Meet Kraków saints!   #11: saint Jacek Odrowąż
Poznaj świętych krakowskich!  #11: święty Jacek Odrowąż
https://pl.wikipedia.org/wiki/Jacek_Odrowąż
-- (sig_end)


On Mon, 05 Dec 2022 02:32:40 +
John Kehayias  wrote:

> Hi Guixers!
> 
> I've started working on a little blog post about our new --emulate-fhs option 
> for Guix containers. In short, this sets up an FHS-like (Filesystem Hierarchy 
> Standard) container which has things like /lib and /bin.
> 
> I would like to get some suggestions on good examples to include. More 
> general feedback, questions, and other comments are also welcome! I've 
> included a rough draft of the beginning of the post, leading up to showing 
> some examples.
> 
> (I've sent this to the devel and help list as I think input from different 
> types of users will be helpful given the feature being discussed. I'm not 
> currently subscribed to the help list, so please cc the devel list or me 
> directly.)
> 
> One question: what is appropriate or recommended for examples concerning 
> things like pre-built binaries? As an example, I had tested the FHS container 
> by running the Siril appimage, which has since been packaged for Guix (nice 
> work!). There are ones that I don't see that happening for anytime soon, like 
> an Electron-based app. Something like VSCodium is very popular, free (as in 
> freedom and I believe the FSDG sense), but just not something you can package 
> fully from source due to JavaScript as I understand it. It runs in the FHS 
> container.
> 
> Examples I was thinking of including: using rustup (uses pre-build rust 
> binaries) and building a package that depends on newer (nightly) rust, like 
> eww <https://github.com/elkowar/eww> This builds and nicely is 
> screenshot-able with pretty looking desktop widgets.
> 
> What would be useful examples? What is the right line to toe regarding 
> binaries? I don't want to necessarily advocate for that, yet sometimes we may 
> feel we have no other choice or want to be able to test something. I was 
> thinking to keep it to what we do have packaged in Guix yet may want to run 
> in a different way, or something that would fit if the language ecosystem 
> wasn't so at odds with the Guix approach (and reproducibility more generally).
> 
> Appreciative of any and all thoughts!
> 
> John
> 
> 
> Here is a current (rough!) draft. For the ease of plain text email I've 
> exported from the org source to text with some light edits:
> 
> 
> __
> 
> FHS COMES TO GUIX CONTAINERS
> 
> John Kehayias
> __
> 
> 
> GNU Guix is different from most other GNU/Linux distributions and
> perhaps nowhere is that more obvious than the organization of the
> filesystem: Guix does not conform to the [File Hierarchy Standard]
> (FHS). In practical terms, this means there is no global `/lib'
> containing libraries, `/bin' containing binaries[1], and so on. This is
> very much at the core of how Guix works and some of the convenient
> features, like per-user installation of programs (different versions,
> for instance) and a declarative system configuration where the system is
> determined from a configuration file.
> 
> However, this also leads to a difference in how many pieces of software
> expect their world to look like, relying on finding a library in `/lib'
> or an external tool in `/bin'. When these are hard coded and not
> overcome with appropriate build options, we patch code to refer to
> absolute paths in the store, like
> `/gnu/store/hrgqa7m498wfavq4awai3xz86ifkjxdr-grep-3.6/bin/grep', to keep
> everything consistently contained within the store.
> 
> It all works great and is thanks to the hard work of everyone that has
> contributed to Guix. But what if we need a more FHS-like environment for
> developing, tes

Drafting a Guix blog post on the FHS container

2022-12-04 Thread John Kehayias
Hi Guixers!

I've started working on a little blog post about our new --emulate-fhs option 
for Guix containers. In short, this sets up an FHS-like (Filesystem Hierarchy 
Standard) container which has things like /lib and /bin.

I would like to get some suggestions on good examples to include. More general 
feedback, questions, and other comments are also welcome! I've included a rough 
draft of the beginning of the post, leading up to showing some examples.

(I've sent this to the devel and help list as I think input from different 
types of users will be helpful given the feature being discussed. I'm not 
currently subscribed to the help list, so please cc the devel list or me 
directly.)

One question: what is appropriate or recommended for examples concerning things 
like pre-built binaries? As an example, I had tested the FHS container by 
running the Siril appimage, which has since been packaged for Guix (nice 
work!). There are ones that I don't see that happening for anytime soon, like 
an Electron-based app. Something like VSCodium is very popular, free (as in 
freedom and I believe the FSDG sense), but just not something you can package 
fully from source due to JavaScript as I understand it. It runs in the FHS 
container.

Examples I was thinking of including: using rustup (uses pre-build rust 
binaries) and building a package that depends on newer (nightly) rust, like eww 
<https://github.com/elkowar/eww> This builds and nicely is screenshot-able with 
pretty looking desktop widgets.

What would be useful examples? What is the right line to toe regarding 
binaries? I don't want to necessarily advocate for that, yet sometimes we may 
feel we have no other choice or want to be able to test something. I was 
thinking to keep it to what we do have packaged in Guix yet may want to run in 
a different way, or something that would fit if the language ecosystem wasn't 
so at odds with the Guix approach (and reproducibility more generally).

Appreciative of any and all thoughts!

John


Here is a current (rough!) draft. For the ease of plain text email I've 
exported from the org source to text with some light edits:


__

FHS COMES TO GUIX CONTAINERS

John Kehayias
__


GNU Guix is different from most other GNU/Linux distributions and
perhaps nowhere is that more obvious than the organization of the
filesystem: Guix does not conform to the [File Hierarchy Standard]
(FHS). In practical terms, this means there is no global `/lib'
containing libraries, `/bin' containing binaries[1], and so on. This is
very much at the core of how Guix works and some of the convenient
features, like per-user installation of programs (different versions,
for instance) and a declarative system configuration where the system is
determined from a configuration file.

However, this also leads to a difference in how many pieces of software
expect their world to look like, relying on finding a library in `/lib'
or an external tool in `/bin'. When these are hard coded and not
overcome with appropriate build options, we patch code to refer to
absolute paths in the store, like
`/gnu/store/hrgqa7m498wfavq4awai3xz86ifkjxdr-grep-3.6/bin/grep', to keep
everything consistently contained within the store.

It all works great and is thanks to the hard work of everyone that has
contributed to Guix. But what if we need a more FHS-like environment for
developing, testing, or running a piece of software?

To that end, we've [recently added] a new option for Guix containers,
`--emulate-fhs' (or `-F'). This will set up an environment in the
container that follows FHS expectations, so that libraries are visible
in `/lib' in the container, as an example. Additionally, for the more
technically-minded, the [`glibc' used in this container] will read from
a global cache in `/etc/ld.so.cache' contrary to the behavior in [Guix
otherwise].

Here is a very simple example:
,
 guix shell --container --emulate-fhs coreutils -- ls /bin
`

[
b2sum
base32
base64
basename
basenc
cat
catchsegv
chcon
chgrp
chmod
...

Contrast that with `/bin' on a Guix system:
,
 ls /bin -la
`

lrwxrwxrwx  1  root  root   61  Dec  3  16:37  sh  ->  
/gnu/store/d99ykvj3axzzidygsmdmzxah4lvxd6hw-bash-5.1.8/bin/sh

There are several uses that spring to mind for such a container in Guix.
For developers, or those aspiring to hack on a project, this is a
helpful tool when needing to emulate a different (non-Guix) environment.
For example, one could use this to more easily follow build instructions
meant for a general distribution, say when a Guix package is not (yet)
available or easy to write immediately. Another usage is to be able to
use tools that don't really fit into Guix's model, like ones that use
pre-built binaries. There are many reasons why this is not ideal and
Guix strives to replace or supplement such tools, but practically
speaking they can be hard to avoid entirely. The FHS contai

Re: Clarifying blog post licensing

2022-02-05 Thread Maxim Cournoyer
Hi Ludovic,

Ludovic Courtès  writes:

> Hi,
>
> Maxim Cournoyer  skribis:
>
>> Ludovic Courtès  writes:
>>
>>> Hello Guix!
>>>
>>> With a few exceptions, our blog posts do not have a license, which is
>>> not great as it prevents sharing and reuse, at least by those outside
>>> Guix circles (we discussed it in the past but never got around to fixing
>>> it).
>>>
>>> I’d like us to clarify that, with a footer on blog posts saying that,
>>> unless otherwise stated, posts are dual-licensed under CC-BY-SA 4.0 and
>>> GFDL 1.3+ (the latter so we can reuse material in the cookbook and in
>>> the manual).  Patch below.
>>>
>>> What do people think?
>>
>> Sounds good to me.  I'm curious though; why do we need CC-BY-SA,
>> additionally to GFDL?
>
> We don’t “need” it, but I think it’s nice to have since it’s used by
> many free culture projects out there, starting with Wikipedia.

Thanks for the information.

Maxim



Re: Clarifying blog post licensing

2022-02-05 Thread Ludovic Courtès
Hi,

Vagrant Cascadian  skribis:

> Just for clarity, do you mean the GFDL with a laundry-list of non-free
> anti-features excluded, like the guix manual:
>
>   Permission is granted to copy, distribute and/or modify this document
>   under the terms of the GNU Free Documentation License, Version 1.3 or
>   any later version published by the Free Software Foundation; with no
>   Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts.

Yes of course; the patch I proposed explicitly states that:

  https://lists.gnu.org/archive/html/guix-devel/2022-01/msg00389.html

Thanks for asking!

Ludo’.



Re: Clarifying blog post licensing

2022-02-05 Thread Ludovic Courtès
Hi,

Maxim Cournoyer  skribis:

> Ludovic Courtès  writes:
>
>> Hello Guix!
>>
>> With a few exceptions, our blog posts do not have a license, which is
>> not great as it prevents sharing and reuse, at least by those outside
>> Guix circles (we discussed it in the past but never got around to fixing
>> it).
>>
>> I’d like us to clarify that, with a footer on blog posts saying that,
>> unless otherwise stated, posts are dual-licensed under CC-BY-SA 4.0 and
>> GFDL 1.3+ (the latter so we can reuse material in the cookbook and in
>> the manual).  Patch below.
>>
>> What do people think?
>
> Sounds good to me.  I'm curious though; why do we need CC-BY-SA,
> additionally to GFDL?

We don’t “need” it, but I think it’s nice to have since it’s used by
many free culture projects out there, starting with Wikipedia.

Ludo’.



Re: Clarifying blog post licensing

2022-01-29 Thread jbranso
January 27, 2022 12:59 AM, "Jan Nieuwenhuizen"  wrote:

> Ludovic Courtès writes:
> 
>> With a few exceptions, our blog posts do not have a license, which is
>> not great
> 

I agree.

Joshua Branson.


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



Re: Clarifying blog post licensing

2022-01-28 Thread Gábor Boskovits
I agree.

pelzflorian (Florian Pelz)  ezt írta (időpont:
2022. jan. 27., Cs 18:35):

> I agree.
>
> On Wed, Jan 26, 2022 at 10:24:11AM +0100, Ludovic Courtès wrote:
> > Hello Guix!
> >
> > With a few exceptions, our blog posts do not have a license, which is
> > not great as it prevents sharing and reuse, at least by those outside
> > Guix circles (we discussed it in the past but never got around to fixing
> > it).
> >
> > I’d like us to clarify that, with a footer on blog posts saying that,
> > unless otherwise stated, posts are dual-licensed under CC-BY-SA 4.0 and
> > GFDL 1.3+ (the latter so we can reuse material in the cookbook and in
> > the manual).  Patch below.
> >
> > What do people think?
> >
> > If maintainers and everyone agrees, I’d like to publicly email all the
> > authors asking them whether they agree with the proposed licensing
> > terms, or whether they’d like a different free license.  The script
> > below enumerates blog post authors (the list needs a bit of cleanup
> > still):
>
>


Re: Clarifying blog post licensing

2022-01-27 Thread pelzflorian (Florian Pelz)
I agree.

On Wed, Jan 26, 2022 at 10:24:11AM +0100, Ludovic Courtès wrote:
> Hello Guix!
> 
> With a few exceptions, our blog posts do not have a license, which is
> not great as it prevents sharing and reuse, at least by those outside
> Guix circles (we discussed it in the past but never got around to fixing
> it).
> 
> I’d like us to clarify that, with a footer on blog posts saying that,
> unless otherwise stated, posts are dual-licensed under CC-BY-SA 4.0 and
> GFDL 1.3+ (the latter so we can reuse material in the cookbook and in
> the manual).  Patch below.
> 
> What do people think?
> 
> If maintainers and everyone agrees, I’d like to publicly email all the
> authors asking them whether they agree with the proposed licensing
> terms, or whether they’d like a different free license.  The script
> below enumerates blog post authors (the list needs a bit of cleanup
> still):



Re: Clarifying blog post licensing

2022-01-26 Thread Jan Nieuwenhuizen
Ludovic Courtès writes:

> With a few exceptions, our blog posts do not have a license, which is
> not great

Good catch, I agree!

Janneke

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



Re: Clarifying blog post licensing

2022-01-26 Thread Tobias Geerinckx-Rice

Vagrant Cascadian 写道:
Just for clarity, do you mean the GFDL with a laundry-list of 
non-free

anti-features excluded, like the guix manual:


I think that goes without saying, but clarity is good: thanks for 
bringing it up.


Invariants would be a deal-breaker for several of us I'm sure, 
including myself.


Kind regards,

T G-R


signature.asc
Description: PGP signature


Re: Clarifying blog post licensing

2022-01-26 Thread Vagrant Cascadian
On 2022-01-26, Ludovic Courtès wrote:
> With a few exceptions, our blog posts do not have a license, which is
> not great as it prevents sharing and reuse, at least by those outside
> Guix circles (we discussed it in the past but never got around to fixing
> it).
>
> I’d like us to clarify that, with a footer on blog posts saying that,
> unless otherwise stated, posts are dual-licensed under CC-BY-SA 4.0 and
> GFDL 1.3+ (the latter so we can reuse material in the cookbook and in
> the manual).  Patch below.

Just for clarity, do you mean the GFDL with a laundry-list of non-free
anti-features excluded, like the guix manual:

  Permission is granted to copy, distribute and/or modify this document
  under the terms of the GNU Free Documentation License, Version 1.3 or
  any later version published by the Free Software Foundation; with no
  Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts.

Without that, I'm not sure you can actually include it in the guix
manual (other than, perhaps, by using CC-BY-SA 4.0, maybe)...

live well,
  vagrant


signature.asc
Description: PGP signature


Re: Clarifying blog post licensing

2022-01-26 Thread Tobias Geerinckx-Rice

How does that sound?


Excellent.

Thanks!

T G-R


signature.asc
Description: PGP signature


Re: Clarifying blog post licensing

2022-01-26 Thread Maxim Cournoyer
Hello,

Ludovic Courtès  writes:

> Hello Guix!
>
> With a few exceptions, our blog posts do not have a license, which is
> not great as it prevents sharing and reuse, at least by those outside
> Guix circles (we discussed it in the past but never got around to fixing
> it).
>
> I’d like us to clarify that, with a footer on blog posts saying that,
> unless otherwise stated, posts are dual-licensed under CC-BY-SA 4.0 and
> GFDL 1.3+ (the latter so we can reuse material in the cookbook and in
> the manual).  Patch below.
>
> What do people think?

Sounds good to me.  I'm curious though; why do we need CC-BY-SA,
additionally to GFDL?

Thanks,

Maxim



Re: Clarifying blog post licensing

2022-01-26 Thread Ricardo Wurmus


Ludovic Courtès  writes:

> With a few exceptions, our blog posts do not have a license, which is
> not great as it prevents sharing and reuse, at least by those outside
> Guix circles (we discussed it in the past but never got around to fixing
> it).
>
> I’d like us to clarify that, with a footer on blog posts saying that,
> unless otherwise stated, posts are dual-licensed under CC-BY-SA 4.0 and
> GFDL 1.3+ (the latter so we can reuse material in the cookbook and in
> the manual).  Patch below.
>
> What do people think?

Sounds good.

> If maintainers and everyone agrees, I’d like to publicly email all the
> authors asking them whether they agree with the proposed licensing
> terms, or whether they’d like a different free license.  The script
> below enumerates blog post authors (the list needs a bit of cleanup
> still):
>
> scheme@(guile-user)> ,pp authors
> $22 = ("A collective of GNU maintainers"
[…]
>  "Ricardo (rekado) Wurmus"
>  "Ricardo Wurmus"

I agree.

-- 
Ricardo



Re: Clarifying blog post licensing

2022-01-26 Thread Oliver Propst

Me too.

--
Kinds regards Oliver Propst
https://twitter.com/Opropst



Re: Clarifying blog post licensing

2022-01-26 Thread Julien Lepiller
On January 26, 2022 10:24:11 AM GMT+01:00, "Ludovic Courtès"  
wrote:
>Hello Guix!
>
>With a few exceptions, our blog posts do not have a license, which is
>not great as it prevents sharing and reuse, at least by those outside
>Guix circles (we discussed it in the past but never got around to fixing
>it).
>
>I’d like us to clarify that, with a footer on blog posts saying that,
>unless otherwise stated, posts are dual-licensed under CC-BY-SA 4.0 and
>GFDL 1.3+ (the latter so we can reuse material in the cookbook and in
>the manual).  Patch below.
>
>What do people think?
>
>If maintainers and everyone agrees, I’d like to publicly email all the
>authors asking them whether they agree with the proposed licensing
>terms, or whether they’d like a different free license.  The script
>below enumerates blog post authors (the list needs a bit of cleanup
>still):
>
>--8<---cut here---start->8---
>scheme@(guile-user)> ,pp authors
>$22 = ("A collective of GNU maintainers"
> "Andreas Enge"
> "Chris Marusich"
> "Chris Marusich and Léo Le Bouter"
> "Christopher Baines"
> "Christopher Lemmer Webber"
> "Danjela Lura"
> "Danny Milosavljevic"
> "David Thompson"
> "Efraim Flashner"
> "Florian Pelz"
> "Guix Hackers"
> "Gábor Boskovits"
> "Jakob L. Kreuze"
> "Jan (janneke) Nieuwenhuizen"
> "Jan Nieuwenhuizen"
> "Joshua Branson"
> "Julien Lepiller"
> "Konrad Hinsen"
> "Laura Lazzati"
> "Ludovic (civodul) Courtès"
> "Ludovic Courtès"
> "Ludovic Courtès and Leo Famulari"
> "Magali Lemes"
> "Manolis Ragkousis"
> "Marius (mbakke) Bakke"
> "Marius Bakke"
> "Mathieu Othacehe"
> "Maxim Cournoyer"
> "Pierre Neidhardt"
> "Pjotr Prins"
> "Ricardo (rekado) Wurmus"
> "Ricardo Wurmus"
> "Roel Janssen"
> "Simon Tournier"
> "Tatiana Sholokhova"
> "Tobias Geerinckx-Rice"
> "sirgazil")
>--8<---cut here---end--->8---
>
>How does that sound?
>
>Thanks,
>Ludo’.
>

I agree



Re: Clarifying blog post licensing

2022-01-26 Thread Efraim Flashner
On Wed, Jan 26, 2022 at 10:24:11AM +0100, Ludovic Courtès wrote:
> Hello Guix!
> 
> With a few exceptions, our blog posts do not have a license, which is
> not great as it prevents sharing and reuse, at least by those outside
> Guix circles (we discussed it in the past but never got around to fixing
> it).
> 
> I’d like us to clarify that, with a footer on blog posts saying that,
> unless otherwise stated, posts are dual-licensed under CC-BY-SA 4.0 and
> GFDL 1.3+ (the latter so we can reuse material in the cookbook and in
> the manual).  Patch below.
> 
> What do people think?

I agree


-- 
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: Clarifying blog post licensing

2022-01-26 Thread Manolis Ragkousis

I agree!

On 1/26/22 11:24, Ludovic Courtès wrote:

Hello Guix!

With a few exceptions, our blog posts do not have a license, which is
not great as it prevents sharing and reuse, at least by those outside
Guix circles (we discussed it in the past but never got around to fixing
it).

I’d like us to clarify that, with a footer on blog posts saying that,
unless otherwise stated, posts are dual-licensed under CC-BY-SA 4.0 and
GFDL 1.3+ (the latter so we can reuse material in the cookbook and in
the manual).  Patch below.

What do people think?

If maintainers and everyone agrees, I’d like to publicly email all the
authors asking them whether they agree with the proposed licensing
terms, or whether they’d like a different free license.  The script
below enumerates blog post authors (the list needs a bit of cleanup
still):

--8<---cut here---start->8---
scheme@(guile-user)> ,pp authors
$22 = ("A collective of GNU maintainers"
  "Andreas Enge"
  "Chris Marusich"
  "Chris Marusich and Léo Le Bouter"
  "Christopher Baines"
  "Christopher Lemmer Webber"
  "Danjela Lura"
  "Danny Milosavljevic"
  "David Thompson"
  "Efraim Flashner"
  "Florian Pelz"
  "Guix Hackers"
  "Gábor Boskovits"
  "Jakob L. Kreuze"
  "Jan (janneke) Nieuwenhuizen"
  "Jan Nieuwenhuizen"
  "Joshua Branson"
  "Julien Lepiller"
  "Konrad Hinsen"
  "Laura Lazzati"
  "Ludovic (civodul) Courtès"
  "Ludovic Courtès"
  "Ludovic Courtès and Leo Famulari"
  "Magali Lemes"
  "Manolis Ragkousis"
  "Marius (mbakke) Bakke"
  "Marius Bakke"
  "Mathieu Othacehe"
  "Maxim Cournoyer"
  "Pierre Neidhardt"
  "Pjotr Prins"
  "Ricardo (rekado) Wurmus"
  "Ricardo Wurmus"
  "Roel Janssen"
  "Simon Tournier"
  "Tatiana Sholokhova"
  "Tobias Geerinckx-Rice"
  "sirgazil")
--8<---cut here---end--->8---

How does that sound?

Thanks,
Ludo’.


diff --git a/website/apps/blog/templates/post.scm 
b/website/apps/blog/templates/post.scm
index de02c6c..0d6b08e 100644
--- a/website/apps/blog/templates/post.scm
+++ b/website/apps/blog/templates/post.scm
@@ -60,4 +60,19 @@
#:label tag
#:url (guix-url (tag-url-path tag)))
   " ")) ; NOTE: Force space for readability in non-CSS browsers.
-   (sort tags tag-first?
+   (sort tags tag-first?)))
+
+(div
+ (@ (class "license"))
+ ,(G_ `(p "Unless otherwise stated, blog posts on this site are
+copyrighted by their respective authors and published under the terms of
+the " ,(G_
+`(a (@ (href 
"https://creativecommons.org/licenses/by-sa/4.0/;))
+"CC-BY-SA 4.0"))
+  " license and those of the "
+  ,(G_
+`(a (@ (href
+"https://www.gnu.org/licenses/fdl-1.3.html;))
+"GNU Free Documentation License"))
+  " (version 1.3 or later, with no Invariant Sections, no
+Front-Cover Texts, and no Back-Cover Texts)."
diff --git a/website/static/blog/css/post.css b/website/static/blog/css/post.css
index 57d7f0d..95035ba 100644
--- a/website/static/blog/css/post.css
+++ b/website/static/blog/css/post.css
@@ -38,3 +38,8 @@ article {
  article.limit-width {
  max-width: 720px;
  }
+
+.license {
+font-size: 0.8em;
+line-height: 1.4em;
+}




Clarifying blog post licensing

2022-01-26 Thread Ludovic Courtès
Hello Guix!

With a few exceptions, our blog posts do not have a license, which is
not great as it prevents sharing and reuse, at least by those outside
Guix circles (we discussed it in the past but never got around to fixing
it).

I’d like us to clarify that, with a footer on blog posts saying that,
unless otherwise stated, posts are dual-licensed under CC-BY-SA 4.0 and
GFDL 1.3+ (the latter so we can reuse material in the cookbook and in
the manual).  Patch below.

What do people think?

If maintainers and everyone agrees, I’d like to publicly email all the
authors asking them whether they agree with the proposed licensing
terms, or whether they’d like a different free license.  The script
below enumerates blog post authors (the list needs a bit of cleanup
still):

--8<---cut here---start->8---
scheme@(guile-user)> ,pp authors
$22 = ("A collective of GNU maintainers"
 "Andreas Enge"
 "Chris Marusich"
 "Chris Marusich and Léo Le Bouter"
 "Christopher Baines"
 "Christopher Lemmer Webber"
 "Danjela Lura"
 "Danny Milosavljevic"
 "David Thompson"
 "Efraim Flashner"
 "Florian Pelz"
 "Guix Hackers"
 "Gábor Boskovits"
 "Jakob L. Kreuze"
 "Jan (janneke) Nieuwenhuizen"
 "Jan Nieuwenhuizen"
 "Joshua Branson"
 "Julien Lepiller"
 "Konrad Hinsen"
 "Laura Lazzati"
 "Ludovic (civodul) Courtès"
 "Ludovic Courtès"
 "Ludovic Courtès and Leo Famulari"
 "Magali Lemes"
 "Manolis Ragkousis"
 "Marius (mbakke) Bakke"
 "Marius Bakke"
 "Mathieu Othacehe"
 "Maxim Cournoyer"
 "Pierre Neidhardt"
 "Pjotr Prins"
 "Ricardo (rekado) Wurmus"
 "Ricardo Wurmus"
 "Roel Janssen"
 "Simon Tournier"
 "Tatiana Sholokhova"
 "Tobias Geerinckx-Rice"
 "sirgazil")
--8<---cut here---end--->8---

How does that sound?

Thanks,
Ludo’.

(use-modules (haunt reader commonmark)
 (haunt reader)
 (haunt post)
 (guix build utils)
 (srfi srfi-1))

(define files
  (find-files "posts" "\\.(md|sxml)$"))

(define authors
  (delete-duplicates
   (append-map (lambda (file)
 (define reader
   (if (string-suffix? ".md" file)
   commonmark-reader
   sxml-reader))

 (map string-trim-both
  (string-split (post-ref (read-post reader file) 'author)
#\,)))
   files)))
diff --git a/website/apps/blog/templates/post.scm b/website/apps/blog/templates/post.scm
index de02c6c..0d6b08e 100644
--- a/website/apps/blog/templates/post.scm
+++ b/website/apps/blog/templates/post.scm
@@ -60,4 +60,19 @@
 		#:label tag
 		#:url (guix-url (tag-url-path tag)))
 	   " ")) ; NOTE: Force space for readability in non-CSS browsers.
-	(sort tags tag-first?
+	(sort tags tag-first?)))
+
+(div
+ (@ (class "license"))
+ ,(G_ `(p "Unless otherwise stated, blog posts on this site are
+copyrighted by their respective authors and published under the terms of
+the " ,(G_
+`(a (@ (href "https://creativecommons.org/licenses/by-sa/4.0/;))
+"CC-BY-SA 4.0"))
+  " license and those of the "
+  ,(G_
+`(a (@ (href
+"https://www.gnu.org/licenses/fdl-1.3.html;))
+"GNU Free Documentation License"))
+  " (version 1.3 or later, with no Invariant Sections, no
+Front-Cover Texts, and no Back-Cover Texts)."
diff --git a/website/static/blog/css/post.css b/website/static/blog/css/post.css
index 57d7f0d..95035ba 100644
--- a/website/static/blog/css/post.css
+++ b/website/static/blog/css/post.css
@@ -38,3 +38,8 @@ article {
 article.limit-width {
 max-width: 720px;
 }
+
+.license {
+font-size: 0.8em;
+line-height: 1.4em;
+}


Re: blog post about shepher user services

2021-05-22 Thread Adriano Peluso
Il giorno sab, 22/05/2021 alle 15.49 +0200, Leo Prikler ha scritto:
> Hi,
> 
> the blog post you've linked
>   
> https://guix.gnu.org/en/blog/2017/running-system-services-in-containers/
> seems to neither contain mentions of XDG_CONFIG_DIR, nor mcron.
> 
> Did you mean 
>   https://guix.gnu.org/en/blog/2020/gnu-shepherd-user-services/
> instead?

yes, I pasted the wrong one, sorry


> 
> FWIW, $XDG_CONFIG_DIR should be $XDG_CONFIG_HOME, I myself always mix
> those up as well.  

Good to know

> As far as mcron integration is concerned, it doesn't
> look as though this has been done yet and I think work remains to be
> done to have mcron running "as a part of shepherd" rather than as its
> own daemon.  You can right now already run regular cron-jobs through
> mcron just how people did before systemd was a thing.  You just need
> to
> make sure you launch mcron as a user service if you want to go with
> this particular configuration style, otherwise mcron as a system
> service ought to suffice as well.
> 
> Regards,
> Leo
> 

Ok, thanks




Re: New blog post on the Guix Build Coordinator: Building derivations, how complicated can it be?

2021-04-30 Thread Vincent Legoll
Thanks Christopher, Mathieu & Ludo to help us understand what's going on

-- 
Vincent Legoll



Re: New blog post on the Guix Build Coordinator: Building derivations, how complicated can it be?

2021-04-30 Thread Ludovic Courtès
Hello!

Mathieu Othacehe  skribis:

> We have already discussed the Cuirass vs Build coordinator situation in
> the past. I haven't changed by mind on that subject. The Guix Build
> Coordinator is more or less the equivalent of the Cuirass remote build
> mechanism[2].

Yes.  So to answer Vincent’s question with my own words and as an
outsider: the Guix Build Coordinator focuses on distributing builds
across several machines that may come and go dynamically.  This is
similar to cuirass-remote-worker.

One difference I see is that cuirass-remote-worker uses ZMQ for
communication while the Coordinator uses HTTP, which makes it easier to
use in a more distributed and dynamic context (HTTP goes through all
firewalls).  Cuirass-remote-worker can discover the central server via
Avahi discovery, which makes it easy to add new workers but is limited
to LANs.  On berlin, a WireGuard VPN was set up to address this (the
non-x86 build nodes are far away from the rest of the build farm).

Another one is that, because the Coordinator focuses on builds, it
brings specific features, such as retrying failed builds.

I like that the Coordinator is quite orthogonal; you can use it together
with the Data Service, or you can use it as an alternative to the
daemon’s offload mechanism.

Conversely, Cuirass is more of an all-in-one solution.  Depending on how
you look at it, it can be a weakness, but it’s also a strength when it
comes to deploying a “build farm” kind of service (I think it’s a good
fit for ci.guix).  Its monitoring features and dashboards have become
very nice and well adapted to someone willing to build packages from a
bunch of channels.

> Integrating the Build coordinator in the Berlin build farm would mean
> hooking in to Cuirass as an alternative to the remote build mechanism. I
> don't think it would be wise because:

[...]

> It really makes me sad that we have two pieces of software that are
> stepping on each other toes. The Build coordinator has a nice concept
> and represents a huge amount of work. However, integrating it to Berlin
> is not an option for me.
>
> I think that the next challenges on the CI front are:
>
> * Increase the number of ARM machines in the build farm.
>
> * Work on substitutes mirrors.
>
> * Find a way to make Cuirass and the Data Service work together.
>
> and we should face those issues together, rather than having competing
> software sharing the few build machines we own.

Right, I think the fruitful way to frame it is not “which one is
better”, but rather how can we take the good things from each approach.

For example, I believe the Guix Data Service relied on the former
Cuirass notification mechanism to learn about build status.  That
mechanism is gone, so “we” (i.e., you :-) Chris & Mathieu) should make
sure the Data Service can take advantage of the new notification
mechanism, possibly adjusting it so there’s a good match.

There are certainly other opportunities for cooperation in this area.
The Data Service does things that Cuirass doesn’t do, such as linting.
It wouldn’t make sense IMO to extend Cuirass to do these things; instead
we should find ways to aggregate and present all this information in the
Data Service.  It already does that to a large extent, but maybe we can
think of tighter integration, such as providing QA-oriented pages
instead of the more generic interface it currently provides.

Thoughts?

Ludo’.



Re: New blog post on the Guix Build Coordinator: Building derivations, how complicated can it be?

2021-04-25 Thread Mathieu Othacehe


Hello,

> On Sat, Apr 24, 2021 at 11:10 AM Christopher Baines  wrote:
>> I did think about trying to include something about Cuirass, but I don't
>> have a clear picture of it's scope or purpose, so I'm not really the
>> right person to attempt to write authoritatively about it.
>
> OK, fair enough, Matthieu, Ludo, or anyone else can shed some light
> here ?

You can learn more about Cuirass by reading its online manual[1].
The Cuirass server at https://ci.guix.gnu.org currently:

* Evaluates new Guix derivations on several branches (master,
  core-updates, ...).

* Builds those derivations on a build farm of 29 machines, some of them
  connected using a Wireguard VPN.

* Reports the build status on the Web interface, by email at
  guix...@gnu.org, though a Web API used by "guix pull" and "guix
  weather".
  
Maintaining and improving this whole architecture has been keeping me
busy for the last year. It involved a constant monitoring of the build
farm, upgrading the database, and rewriting Cuirass almost completely,
between other things.

The situation is now much better. Cuirass offers a nice substitutes
coverage, at least for Intel architectures, it is stable, well covered
by unit tests and documented.

We have already discussed the Cuirass vs Build coordinator situation in
the past. I haven't changed by mind on that subject. The Guix Build
Coordinator is more or less the equivalent of the Cuirass remote build
mechanism[2].

Integrating the Build coordinator in the Berlin build farm would mean
hooking in to Cuirass as an alternative to the remote build mechanism. I
don't think it would be wise because:

* It wouldn't bring any new features as far as I can tell.

* It would mean maintaining a new SQLite database.

  When Cuirass was using an SQLite database, maintaining it was a
  nightmare. I had to dive into SQLite sources, apply a wide variety of
  hacks[3] to make it scale.

  Even if the Build coordinator is updated to use a PostgreSQL database,
  that would mean having two databases, sitting next to each other,
  with a very similar content, which is a nonsense in my opinion.

* The Build coordinator has no documentation, no unit tests and a large
  code base that would drastically increase the system administrator
  burden.

It really makes me sad that we have two pieces of software that are
stepping on each other toes. The Build coordinator has a nice concept
and represents a huge amount of work. However, integrating it to Berlin
is not an option for me.

I think that the next challenges on the CI front are:

* Increase the number of ARM machines in the build farm.

* Work on substitutes mirrors.

* Find a way to make Cuirass and the Data Service work together.

and we should face those issues together, rather than having competing
software sharing the few build machines we own.

Thanks,

Mathieu

[1]: https://guix.gnu.org/cuirass/manual/html_node/index.html
[2]: 
https://guix.gnu.org/cuirass/manual/html_node/Build-modes.html#With-the-remote-build-mechanism_002e
[3]: 
https://wiki.mozilla.org/Performance/Avoid_SQLite_In_Your_Next_Firefox_Feature



Re: New blog post on the Guix Build Coordinator: Building derivations, how complicated can it be?

2021-04-24 Thread Vincent Legoll
On Sat, Apr 24, 2021 at 11:10 AM Christopher Baines  wrote:
> I did think about trying to include something about Cuirass, but I don't
> have a clear picture of it's scope or purpose, so I'm not really the
> right person to attempt to write authoritatively about it.

OK, fair enough, Matthieu, Ludo, or anyone else can shed some light
here ?

> I try to avoid using the CI (Continuous Integration) term as I'm not
> sure there's a shared understanding of the term (I think it's the
> practice of multiple people frequently merging their changes to some
> software they're all working on).

Yes, I know the term is overloaded, but it's easy and conveys at least
a bit of the subject at hands, so...

> Does that make any sense? Do say if you have more questions.

Yes, and I will, thanks

-- 
Vincent Legoll



Re: New blog post on the Guix Build Coordinator: Building derivations, how complicated can it be?

2021-04-24 Thread Christopher Baines

Vincent Legoll  writes:

> Hello,
>
> On Sat, Apr 24, 2021 at 8:28 AM Christopher Baines  wrote:
>> With some prompting, there's now a blog post about the Guix Build
>> Coordinator
>
> Nice post that explains a lot, but I'm still not so sure about the
> relations to cuirass. I'd have liked a small paragraph explaining
> what the differences are, how can they complement each other,
> kind of the CI envisionned big picture...

Thanks for the feedback Vincent :)

I did think about trying to include something about Cuirass, but I don't
have a clear picture of it's scope or purpose, so I'm not really the
right person to attempt to write authoritatively about it.

On a technical level, there's no connection, although there was talk
over the last 6 months or so about trying to have or allow Cuirass to
benefit from the Guix Build Coordinator's ability to perform builds in a
methodical manor across multiple machines. That hasn't happened yet
though, and in the mean time, Cuirass has gained it's own mechanism of
running builds on other machines.

I try to avoid using the CI (Continuous Integration) term as I'm not
sure there's a shared understanding of the term (I think it's the
practice of multiple people frequently merging their changes to some
software they're all working on).

In terms of building things for substitutes, that's one of the use cases
I had in mind when I designed the Guix Build Coordinator, and I think
that design has worked out well, so I'm still interested in trying to
get some benefits for Guix users through using the Guix Build
Coordinator to produce substitutes in a faster and more reliable way.

Does that make any sense? Do say if you have more questions.

Thanks,

Chris


signature.asc
Description: PGP signature


Re: New blog post on the Guix Build Coordinator: Building derivations, how complicated can it be?

2021-04-24 Thread Vincent Legoll
Hello,

On Sat, Apr 24, 2021 at 8:28 AM Christopher Baines  wrote:
> With some prompting, there's now a blog post about the Guix Build
> Coordinator

Nice post that explains a lot, but I'm still not so sure about the
relations to cuirass. I'd have liked a small paragraph explaining
what the differences are, how can they complement each other,
kind of the CI envisionned big picture...

Regards

-- 
Vincent Legoll



New blog post on the Guix Build Coordinator: Building derivations, how complicated can it be?

2021-04-24 Thread Christopher Baines
Hey,

With some prompting, there's now a blog post about the Guix Build
Coordinator: 

  
https://guix.gnu.org/en/blog/2021/building-derivations-how-complicated-can-it-be/

Since it doesn't have a web interface like the Guix Data Service, and
doesn't directly meet a widespread need, I think it's probably harder
than usual to understand the intent and design , but hopefully this
helps.

Thanks to Ludo for his review and feedback.

Do let me know if you notice any mistakes or have any questions!

Chris


signature.asc
Description: PGP signature


Re: Please review blog post draft: powerpc64le-linux support

2021-04-15 Thread Léo Le Bouter
On Mon, 2021-04-12 at 12:46 -0700, Chris Marusich wrote:
> Hi,
> 
> Chris Marusich  writes:
> 
> > This is the final draft, I think.  I intend to commit it to the
> > "posts"
> > directory in guix-artwork on Monday morning, USA time, at which
> > point I
> > believe it will automatically show up on the blog.
> 
> I have published it in commit
> 0129dd529347bfefee96644ac9fbabc29adbe772.
> Thank you again to everyone for your help!
> 

Awesome! I also sent an email to Micheal from Phoronix earlier, but it
seems they either didnt take it into account or didnt see it for now.

Léo


signature.asc
Description: This is a digitally signed message part


Re: Please review blog post draft: powerpc64le-linux support

2021-04-12 Thread Chris Marusich
Hi,

Chris Marusich  writes:

> This is the final draft, I think.  I intend to commit it to the "posts"
> directory in guix-artwork on Monday morning, USA time, at which point I
> believe it will automatically show up on the blog.

I have published it in commit 0129dd529347bfefee96644ac9fbabc29adbe772.
Thank you again to everyone for your help!

-- 
Chris


signature.asc
Description: PGP signature


Re: Please review blog post draft: powerpc64le-linux support

2021-04-11 Thread Chris Marusich
op-now-fsf-certified-to-respect-your-freedom),
+this is an obstacle that nobody should have to overcome just to
+control their own computer.  Many of the existing RYF-certified
+options (e.g., the venerable Lenovo x200) use hardware that can only
+be considered RYF-certified after someone has gone through the extra
+effort of removing those back doors.  No such obstacles exist when
+using the Talos II, Talos II Lite, or Blackbird.  In fact, although
+[Intel](https://arstechnica.com/gadgets/2020/10/in-a-first-researchers-extract-secret-key-used-to-encrypt-intel-cpu-code/)
+and
+[AMD](https://www.extremetech.com/computing/292722-amds-secure-processor-firmware-is-now-explorable-thanks-to-new-tool)
+both go out of their way to keep you from understanding what is going
+on in your own computer, Raptor Computing Systems releases [all of the
+software and firmware used in their
+boards](https://git.raptorcs.com/git/) as free software.  They even
+include circuit diagrams when they ship you the machine!
+
+Compared to the existing options, the Talos II, Talos II Lite, and
+Blackbird are a breath of fresh air that the free software community
+really deserves.  Raptor Computing Systems' commitment to software
+freedom and owner control is an inspiring reminder that it **is**
+possible to ship a great product while still respecting the freedom of
+your customers.  And going forward, the future looks bright for the
+open, royalty-free Power ISA stewarded by the OpenPOWER Foundation,
+[which is now a Linux Foundation
+project](https://www.linuxfoundation.org/press-release/2019/08/the-linux-foundation-announces-new-open-hardware-technologies-and-collaboration/)
+(see also: [the same announcement from the OpenPOWER
+Foundation](https://openpowerfoundation.org/the-next-step-in-the-openpower-foundation-journey/).
+
+In the rest of this blog post, we will discuss the steps we took to
+port Guix to powerpc64le-linux, the issues we encountered, and the
+steps we can take going forward to further solidify support for this
+exciting new platform.
+
+### Bootstrapping powerpc64le-linux: A Journey
+
+To build software, you need software.  How can one port Guix to a
+platform before support for that platform exists?  This is a
+[bootstrapping
+problem](https://guix.gnu.org/manual/en/html_node/Bootstrapping.html).
+
+In Guix, all software for a given platform (e.g., powerpc64le-linux)
+is built starting from a small set of "bootstrap binaries".  These are
+binaries of Guile, GCC, Binutils, libc, and a few other packages,
+pre-built for the relevant platform.  It is intended that the
+bootstrap binaries are the only pieces of software in the entire
+package collection that Guix cannot build from source.  In practice,
+[additional bootstrap roots are
+possible](https://lists.gnu.org/archive/html/guix-devel/2015-02/msg00814.html),
+but introducing them in Guix is highly discouraged, and our community
+[actively](https://guix.gnu.org/en/blog/2019/guix-reduces-bootstrap-seed-by-50/)
+[works](https://guix.gnu.org/en/blog/2020/guix-further-reduces-bootstrap-seed-to-25/)
+to [reduce](https://guix.gnu.org/en/blog/2018/bootstrapping-rust/) our
+overall bootstrap footprint.  There is one set of bootstrap binaries
+for each platform that Guix supports.
+
+This means that to port Guix to a new platform, you must first build
+the bootstrap binaries for that platform.  In theory, you can do this
+in many ways.  For example, you might try to manually compile them on
+an existing system.  However, Guix has [package
+definitions](https://git.savannah.gnu.org/cgit/guix.git/tree/gnu/packages/make-bootstrap.scm?id=5d8c2c00d60196c46a32b68c618ccbe2b3aa48f4)
+that you can use to build them - using Guix, of course!
+
+Commonly, the first step in [porting Guix to a new
+platform](https://guix.gnu.org/manual/en/html_node/Porting.html) is to
+use Guix to cross-compile the bootstrap binaries for that new platform
+from a platform on which Guix is already supported. This can be done
+by running a command like the following on a system where Guix is
+already installed:
+
+```scheme
+guix build --target=powerpc64le-linux-gnu bootstrap-tarballs
+```
+
+This is the route that we took when building the powerpc64le-linux
+bootstrap binaries, as described in commit
+[8a1118a](https://git.savannah.gnu.org/cgit/guix.git/commit/?id=8a1118a96c9ae128302c3d435ae77cb3dd693aea).
+You might wonder why the target above is "powerpc64le-linux-gnu" even
+though the new Guix platform is called "powerpc64le-linux".  This is
+because "powerpc64le-linux-gnu" is a GNU
+[triplet](https://wiki.osdev.org/Target_Triplet) identifying the new
+platform, but "powerpc64le-linux" is the name of a "system" (i.e., a
+platform) in Guix.  Guix contains code that converts between the two
+as needed (see `nix-system->gnu-triplet` and `gnu-triplet->nix-system`
+in
+[`guix/utils.scm`](https://git.savannah.gnu.org/cgit/guix.git/tree/guix/u

Re: Please review blog post draft: powerpc64le-linux support

2021-04-11 Thread Chris Marusich
Hi Tobias,

Thank you very much for taking the time to review the blog post!

Tobias Platen  writes:

> On Fri, 09 Apr 2021 00:59:44 +0200
> Léo Le Bouter  wrote:
>
>> On Thu, 2021-04-08 at 09:37 -0700, Chris Marusich wrote:
>> > They also say in that Twitter thread: "We have been putting together
>> > our
>> > systems from blob-free components only (sans NIC as is known and
>> > being
>> > actively worked), and this is an area where no low-cost blob-free
>> > silicon is available right now."
>> > 
>> 
>> I've been using the Free Software firmware replacement for the NIC
>> since a while now and it's working great: 
>> https://github.com/meklort/bcm5719-fw/
>
> I've install that firmware on my Talos II and I can confirm that it works.
> I have reviewed 0001-website-drafts-Add-powerpc64le-linux-announcement.patch 
> and it looks good.
> It would be good to mention the Libre-SoC project(https://libre-soc.org/), 
> which might be a good target for the future.

I think that project is interesting, but I don't think I'll add a
section expliclty mentioning it in the post this time.  I originally did
discuss RISC-V in passing, but it felt out of place, since the focus of
the blog post is really on the POWER9 support.  The blog post is already
quite long, so I tried to cut out what I could.

I appreciate the suggestion, though.  I hope that somebody will try
porting to Libre-SoC as well, and RISC-V, too!

-- 
Chris


signature.asc
Description: PGP signature


Re: Please review blog post draft: powerpc64le-linux support

2021-04-10 Thread Tobias Platen
On Fri, 09 Apr 2021 00:59:44 +0200
Léo Le Bouter  wrote:

> On Thu, 2021-04-08 at 09:37 -0700, Chris Marusich wrote:
> > They also say in that Twitter thread: "We have been putting together
> > our
> > systems from blob-free components only (sans NIC as is known and
> > being
> > actively worked), and this is an area where no low-cost blob-free
> > silicon is available right now."
> > 
> 
> I've been using the Free Software firmware replacement for the NIC
> since a while now and it's working great: 
> https://github.com/meklort/bcm5719-fw/

I've install that firmware on my Talos II and I can confirm that it works.
I have reviewed 0001-website-drafts-Add-powerpc64le-linux-announcement.patch 
and it looks good.
It would be good to mention the Libre-SoC project(https://libre-soc.org/), 
which might be a good target for the future.

Tobias

--
Sent from my IBM 7094



Re: Please review blog post draft: powerpc64le-linux support

2021-04-08 Thread Léo Le Bouter
On Thu, 2021-04-08 at 09:37 -0700, Chris Marusich wrote:
> They also say in that Twitter thread: "We have been putting together
> our
> systems from blob-free components only (sans NIC as is known and
> being
> actively worked), and this is an area where no low-cost blob-free
> silicon is available right now."
> 

I've been using the Free Software firmware replacement for the NIC
since a while now and it's working great: 
https://github.com/meklort/bcm5719-fw/


signature.asc
Description: This is a digitally signed message part


Re: Please review blog post draft: powerpc64le-linux support

2021-04-08 Thread Vincent Legoll
Hello,

On Thu, Apr 8, 2021 at 6:37 PM Chris Marusich  wrote:
> I specifically avoided speaking about the Blackbird, only because it's
> not yet RYF-certified.  However, perhaps I'm being too strict about it.

Ah, yes, I forgot about this detail. I'd have chosen the blackbird myself,
for the same reasons. But it's still a bit pricey for me though.

I'd say you can talk about it, the way you proposed, as there's a high
probability that it will get the certification.

-- 
Vincent Legoll



Re: Please review blog post draft: powerpc64le-linux support

2021-04-08 Thread Chris Marusich
Vincent Legoll  writes:

> Why only speaking of Talos and not about the 3rd option: the blackbird ?
> Maybe just concentrate on the vendor, more than on particular models...

I specifically avoided speaking about the Blackbird, only because it's
not yet RYF-certified.  However, perhaps I'm being too strict about it.

I actually own a Blackbird, myself.  I chose to buy it instead of the
Talos II or Talos II Lite because of its physically smaller form factor
and its lower cost.  I don't know why it isn't RYF-certified yet, but
according to this Phoronix article, they are "pursuing RYF
certification" for Blackbird, too:

https://www.phoronix.com/scan.php?page=news_item=FSF-RYF-Talos-II

Raptor Computing Systems claims that the Blackbird is "completely blob
free":

https://twitter.com/RaptorCompSys/status/1048373354695208960

They also say in that Twitter thread: "We have been putting together our
systems from blob-free components only (sans NIC as is known and being
actively worked), and this is an area where no low-cost blob-free
silicon is available right now."

However, the Talos II and Blackbird both use the same NIC, so I guess
that wouldn't stop it from meeting the RYF requirements:

https://wiki.raptorcs.com/wiki/Talos_II
Networking: 2x GbE (Broadcom BCM5719)

https://wiki.raptorcs.com/wiki/Blackbird
Networking: 3x GbE (Broadcom BCM5719)

See also:

https://wiki.raptorcs.com/wiki/BCM5719

"As the BCM5719 is the only on-board device on the non-SAS Talos™ II
variants to use proprietary firmware, Raptor Computing Systems has
started a contest to see who can create a truly libre replacement
firmware[1]. Anyone with the appropriate skill set is encouraged to take
up the challenge, and contributions to this page as the device is
analyzed in detail are welcomed.

While the BCM5719 does, at least for now, execute proprietary firmware
it is prevented from corrupting the operating system and/or other
protected memory regions via the system IOMMU[2]."

Thinking about this more, I think we should mention Blackbird in our
blog post as a more affordable option.  Let's explain that it doesn't
yet have RYF certification, but the platform is very similar to the
Talos II, and Raptor Computing Systems is currently pursuing RYF
certification for it, too.

-- 
Chris


signature.asc
Description: PGP signature


Re: Please review blog post draft: powerpc64le-linux support

2021-04-08 Thread Vincent Legoll
Hello Chris,

Great blog post !
I've not seen anything more than the already reported issues.

On Thu, Apr 8, 2021 at 10:55 AM Chris Marusich  wrote:
> Talos II and Talos II Lite

Why only speaking of Talos and not about the 3rd option: the blackbird ?
Maybe just concentrate on the vendor, more than on particular models...

Thanks

-- 
Vincent Legoll



Re: Please review blog post draft: powerpc64le-linux support

2021-04-08 Thread Chris Marusich
Hi,

Here's a new version of the blog post.  It incorporates all the feedback
so far.  I've also removed the "About other freedom-friendly platforms"
because it didn't seem to add much substance.

I significantly rewrote the "Why Is This Important?" section, mainly
because I realized that I was incorrectly and unfairly implying that
POWER9 CPUs are not vulnerable to Spectre/Meltdown-style
vulnerabilities.  In fact, some POWER9 CPUs were found to be vulnerable,
but the most recent models have been fixed.  I've rewritten this section
so that it focuses more on explaining why the RYF Talos II and Talos II
Lite are "more free" than the popular Intel and AMD mainstays (even the
older, RYF-certified models, where you still have to jump over the
hurdle of removing the Intel ME or equivalent.)

For details on Spectre/Meltdown on POWER9, see:

https://wiki.raptorcs.com/wiki/Speculative_Execution_Vulnerabilities_of_2018

I added a footer describing GNU Guix, as is customary on most of our
blog posts.

I changed the title.

I also fixed various links and rephrased a few things.

Anyway, if you can cast your eye over it once more, I would appreciate
it.  I think it's just about done!

-- 
Chris
From 4d9133e51fc666f14074c1da18bb16af0d76066f Mon Sep 17 00:00:00 2001
From: Chris Marusich 
Date: Tue, 6 Apr 2021 00:10:35 -0700
Subject: [PATCH] website: drafts: Add powerpc64le-linux announcement.

* website/drafts/new-system-powerpc64le-linux.md: New file.
---
 .../drafts/new-system-powerpc64le-linux.md| 389 ++
 1 file changed, 389 insertions(+)
 create mode 100644 website/drafts/new-system-powerpc64le-linux.md

diff --git a/website/drafts/new-system-powerpc64le-linux.md b/website/drafts/new-system-powerpc64le-linux.md
new file mode 100644
index 000..d2104aa
--- /dev/null
+++ b/website/drafts/new-system-powerpc64le-linux.md
@@ -0,0 +1,389 @@
+title: New Supported Platform: powerpc64le-linux
+date: 2021-04-08 00:00
+author: Chris Marusich and Léo Le Bouter
+tags: porting, powerpc64le, bootstrapping, cross-compilation, reproducibility
+---
+
+It is a pleasure to announce that support for powerpc64le-linux
+(PowerISA v.2.07 and later) has now been
+[merged](https://issues.guix.gnu.org/47182) to the master branch of
+GNU Guix!
+
+This means that GNU Guix can be used immediately on this platform from
+a [from a Git
+checkout](https://guix.gnu.org/manual/en/html_node/Building-from-Git.html).
+Starting with the next release (Guix v1.2.1), you will also be able to
+[download a copy of Guix pre-built for
+powerpc64le-linux](https://guix.gnu.org/manual/en/html_node/Binary-Installation.html#Binary-Installation).
+Regardless of how you get it, you can run the new powerpc64le-linux
+port of GNU Guix on top of any existing powerpc64le GNU/Linux
+distribution.
+
+This new platform is available as a "technology preview".  This means
+that although it is supported,
+[substitutes](https://guix.gnu.org/manual/en/html_node/Substitutes.html)
+are not yet available from the build farm, and some packages may fail
+to build.  Although powerpc64le-linux support is nascent, the Guix
+community is actively working on improving it, and this is a great
+time to [get
+involved](https://guix.gnu.org/manual/en/html_node/Contributing.html)!
+
+### Why Is This Important?
+
+This is important because it means that GNU Guix now works on the
+[Talos II and Talos II Lite
+mainboards](https://www.fsf.org/news/talos-ii-mainboard-and-talos-ii-lite-mainboard-now-fsf-certified-to-respect-your-freedom),
+which use [IBM POWER9
+processors](https://wiki.raptorcs.com/wiki/POWER9).  This is a modern,
+performant hardware platform that has recently received [Respects Your
+Freedom (RYF) certification](https://ryf.fsf.org/) from the FSF.  It
+can run without any non-free code, all the way down to its bootloader
+and firmware.  In other words, it's a freedom-friendly platform that
+aligns well with GNU Guix's commitment to software freedom.
+
+How is this any different from existing RYF hardware, you might ask?
+One reason is performance.  The existing RYF
+[laptops](https://ryf.fsf.org/products?category=1=All_by=created_order=DESC),
+[mainboards](https://ryf.fsf.org/products?category=5=All_by=created_order=DESC),
+and
+[workstations](https://ryf.fsf.org/products?category=30=All_by=created_order=DESC)
+can only really be used with Intel Core Duo or AMD Opteron processors.
+Those processors were released over 15 years ago.  Since then,
+processor performance has increased drastically.  People should not
+have to choose between performance and freedom, but for many years
+that is exactly what we were forced to do.  However, the Talos II and
+Talos II Lite have changed this: the free software community now has
+an RYF-certified option that [can compete with the performance of
+modern Intel and AMD
+systems](https://www.phoronix.com/scan.php?page=article=power9-threadripper-core9=1).
+
+Although the perform

Re: Please review blog post draft: powerpc64le-linux support

2021-04-08 Thread Chris Marusich
Hi Léo,

Léo Le Bouter  writes:

> It's been mostly you here Chris, thank you so much for writing it, as
> others said, it is really beautifully written! Unfortunately I havent
> felt enough peace of mind to write like you did :-(

You've been busy!  It's totally understandable.  The encouragement from
you and others has been very useful and motivating for me, so thank you.

> I would've liked to write about the early days where I met some
> problems with the core-updates branch having to rebase several times
> and learning GNU Guix at the same time since my first ever project
> related to GNU Guix was porting before even trying to use it elsewhere.
> Having to learn the GNU commit message guidelines, then learning git-
> send-email and GNU Emacs (since that's where all dev tools are), all
> that to contribute to GNU Guix and get this port in. Aaaahh very long
> story!

I agree.  Those are interesting topics.  I tried to include some
discussion about it, but the post became too lengthy.  I just want it to
be about the new support, mainly, and why it's exciting.

I think that the following related topics would make good candidates for
future blog posts:

- An analysis of trust in Guix, with an eye towards bootstrapping.  If
  you use substitutes, what are you implicitly trusting?  If you build
  without substitutes, what are you implicitly trusting?  If you build
  Guix from source without using Guix, like you have to do when you
  first port Guix to a new platform, what are you trusting?  A
  comparison of similar paths of trust when using other software.  Make
  a script to find out if there are any forgotten "bootstrap roots"
  beyond the bootstrap binaries, like there apparently used to be for
  some self-hosted compilers (see:
  https://lists.gnu.org/archive/html/guix-devel/2015-02/msg00814.html).
  Stuff like that.  I think it is not obvious.

- An analysis of the hurdles / friction involved in contributing.
  Preferably with suggestions for ways to remove the hurdles and reduce
  friction.  It is easy to complain or bikeshed, of course, but the
  point is not to do that.  The point is to discuss issues to try and
  make things better.

Thank you again for your help!  This is just the beginning - let's keep
hacking away at it and improving POWER9 support together!  Hopefully
others will see the benefits of the platform and join us along the way.

-- 
Chris


signature.asc
Description: PGP signature


Re: Please review blog post draft: powerpc64le-linux support

2021-04-07 Thread Chris Marusich
Hi Joshua,

Joshua Branson  writes:

> Awesome!  Great work!  I read the below draft blog post like a Harry
> Potter novel!  It is superbly written.  And it makes a lot of sense!

Thank you for the kind words, and your feedback!

>> +### Why Is This Important?
>> +
>> +This is important because it means that GNU Guix now works on the [RYF
>> +Talos II and Talos II Lite
>> +mainboards](https://www.fsf.org/news/talos-ii-mainboard-and-talos-ii-lite-mainboard-now-fsf-certified-to-respect-your-freedom)
>> +and it's IBM POWER9 processor.  This is a modern, performant hardware
>
> I believe you should use "its".  it's is short for "it is".

Good catch!

>> +platform that respects your freedom.  It can run without any non-free
>> +code, all the way down to its bootloader and firmware.  It's a
>> +freedom-friendly platform that aligns well with GNU Guix's commitment
>> +to software freedom.
>> +
>> +How is this any different from existing RYF hardware, you might ask?
>> +The existing RYF
>> +[laptops](https://ryf.fsf.org/products?category=1=All_by=created_order=DESC),
>> +[mainboards](https://ryf.fsf.org/products?category=5=All_by=created_order=DESC),
>> +and
>> +[workstations](https://ryf.fsf.org/products?category=30=All_by=created_order=DESC)
>> +can only really be used with Intel Core Duo or AMD Opteron processors.
>> +Those processors were released over 15 years ago.  Since then,
>> +processor performance has increased drastically.  People should not
>> +have to choose between performance and freedom, but the fact is that
>> +for many years, that is exactly what we were forced to do.  However,
>> +the Talos II and Talos II Lite have changed this: the free software
>> +community now has an RYF-certified option that can compete with the
>> +performance of modern Intel and AMD systems.
>> +
>> +Although the performance of POWER9 processors is competitive with
>> +modern Intel and AMD processors, its real advantage is that it<
>
> Why is there "it<"  ?  Is that some markup I'm not familiar with?

Nope, it's a typo.  Good eyes!

>> +respects your freedom.  Modern processors from [both Intel and AMD
>> +include back
>> +doors](https://www.fsf.org/blogs/sysadmin/the-management-engine-an-attack-on-computer-users-freedom)
>> +over which you are given no control.  Additionally, hardware design
>> +defects in the processors of both vendors have been discovered, giving
>> +rise to critical security vulnerabilities like
>> +[Spectre](https://en.wikipedia.org/wiki/Spectre_(security_vulnerability))
>> +and
>> +[Meltdown](https://en.wikipedia.org/wiki/Meltdown_(security_vulnerability)).
>> +In many cases, these vulnerabilities can only be fixed by installing
>> +[non-free CPU microcode](https://wiki.debian.org/Microcode) - unless,
>> +of course, [the vendor decides not to provide any fix at
>> +all](https://arstechnica.com/gadgets/2018/04/intel-drops-plans-to-develop-spectre-microcode-for-ancient-chips/)!
>> +
>> +Compared to that, the RYF Talos II and Talos II Lite are a breath of
>> +fresh air that the free software community really deserves.  Raptor
>> +Computing Systems' commitment to software freedom and owner control is
>> +an inspiring reminder that it **is** possible to ship a great product
>> +that respects the freedom of your customers.  And going forward, the
>> +future looks bright for the open, royalty-free Power ISA, [which is
>> +now a Linux Foundation
>> +project](https://www.linuxfoundation.org/press-release/2019/08/the-linux-foundation-announces-new-open-hardware-technologies-and-collaboration/)
>> +(see also: [the same announcement from The OpenPOWER
>> +Foundation](https://openpowerfoundation.org/the-next-step-in-the-openpower-foundation-journey/).
>> +
>> +
>> +In Guix, all software for a given system (e.g., powerpc64le-linux) is
>> +built starting from its bootstrap binaries.  It is intended that the
>> +bootstrap binaries are the only pieces of software in the entire
>> +package collection that Guix cannot build from source.  In practice,
>> +[additional bootstrap roots are
>> +possible](https://lists.gnu.org/archive/html/guix-devel/2015-02/msg00814.html),
>> +but introducing them in Guix is highly discouraged, and our community
>> +[actively](https://guix.gnu.org/en/blog/2019/guix-reduces-bootstrap-seed-by-50/)
>> +[works](https://guix.gnu.org/en/blog/2020/guix-further-reduces-bootstrap-seed-to-25/)
>> +to [reduce](https://guix.gnu.org/en/blog/2018/bootstrapping-rust/) our
>> +overall bootstrap footprint.
>> +
>> +So first you need to build the the boot

Re: Please review blog post draft: powerpc64le-linux support

2021-04-06 Thread Léo Le Bouter
On Tue, 2021-04-06 at 00:15 -0700, Chris Marusich wrote:
> Hi,
> 
> Léo and I have drafted the following blog post.  Could you take a few
> minutes to read it and give us your thoughts?
> 
> It's a work in progress.  The primary goal is to announce the new
> powerpc64le-linux support and explain why it matters (POWER9 is an
> exciting, freedom-friendly platform!).  The secondary goal is to
> explain
> some of the details about what we did, and invite people to get
> involved.
> 
> Your feedback would be highly appreciated!
> 

It's been mostly you here Chris, thank you so much for writing it, as
others said, it is really beautifully written! Unfortunately I havent
felt enough peace of mind to write like you did :-(

I would've liked to write about the early days where I met some
problems with the core-updates branch having to rebase several times
and learning GNU Guix at the same time since my first ever project
related to GNU Guix was porting before even trying to use it elsewhere.
Having to learn the GNU commit message guidelines, then learning git-
send-email and GNU Emacs (since that's where all dev tools are), all
that to contribute to GNU Guix and get this port in. Aaaahh very long
story!

Léo


signature.asc
Description: This is a digitally signed message part


Re: Please review blog post draft: powerpc64le-linux support

2021-04-06 Thread Joshua Branson


Awesome!  Great work!  I read the below draft blog post like a Harry
Potter novel!  It is superbly written.  And it makes a lot of sense!

Chris Marusich  writes:

> Hi,
>
> Léo and I have drafted the following blog post.  Could you take a few
> minutes to read it and give us your thoughts?
>
> It's a work in progress.  The primary goal is to announce the new
> powerpc64le-linux support and explain why it matters (POWER9 is an
> exciting, freedom-friendly platform!).  The secondary goal is to explain
> some of the details about what we did, and invite people to get
> involved.
>
> Your feedback would be highly appreciated!
>
> --
> Chris

Seriously good job on this blog post, and all involved in the powerPC
porting work!  Fabulous job chaps!  Cheerio!  Also below are my tiny
edits:

> +
> +### Why Is This Important?
> +
> +This is important because it means that GNU Guix now works on the [RYF
> +Talos II and Talos II Lite
> +mainboards](https://www.fsf.org/news/talos-ii-mainboard-and-talos-ii-lite-mainboard-now-fsf-certified-to-respect-your-freedom)
> +and it's IBM POWER9 processor.  This is a modern, performant hardware

I believe you should use "its".  it's is short for "it is".

> +platform that respects your freedom.  It can run without any non-free
> +code, all the way down to its bootloader and firmware.  It's a
> +freedom-friendly platform that aligns well with GNU Guix's commitment
> +to software freedom.
> +
> +How is this any different from existing RYF hardware, you might ask?
> +The existing RYF
> +[laptops](https://ryf.fsf.org/products?category=1=All_by=created_order=DESC),
> +[mainboards](https://ryf.fsf.org/products?category=5=All_by=created_order=DESC),
> +and
> +[workstations](https://ryf.fsf.org/products?category=30=All_by=created_order=DESC)
> +can only really be used with Intel Core Duo or AMD Opteron processors.
> +Those processors were released over 15 years ago.  Since then,
> +processor performance has increased drastically.  People should not
> +have to choose between performance and freedom, but the fact is that
> +for many years, that is exactly what we were forced to do.  However,
> +the Talos II and Talos II Lite have changed this: the free software
> +community now has an RYF-certified option that can compete with the
> +performance of modern Intel and AMD systems.
> +
> +Although the performance of POWER9 processors is competitive with
> +modern Intel and AMD processors, its real advantage is that it<

Why is there "it<"  ?  Is that some markup I'm not familiar with?

> +respects your freedom.  Modern processors from [both Intel and AMD
> +include back
> +doors](https://www.fsf.org/blogs/sysadmin/the-management-engine-an-attack-on-computer-users-freedom)
> +over which you are given no control.  Additionally, hardware design
> +defects in the processors of both vendors have been discovered, giving
> +rise to critical security vulnerabilities like
> +[Spectre](https://en.wikipedia.org/wiki/Spectre_(security_vulnerability))
> +and
> +[Meltdown](https://en.wikipedia.org/wiki/Meltdown_(security_vulnerability)).
> +In many cases, these vulnerabilities can only be fixed by installing
> +[non-free CPU microcode](https://wiki.debian.org/Microcode) - unless,
> +of course, [the vendor decides not to provide any fix at
> +all](https://arstechnica.com/gadgets/2018/04/intel-drops-plans-to-develop-spectre-microcode-for-ancient-chips/)!
> +
> +Compared to that, the RYF Talos II and Talos II Lite are a breath of
> +fresh air that the free software community really deserves.  Raptor
> +Computing Systems' commitment to software freedom and owner control is
> +an inspiring reminder that it **is** possible to ship a great product
> +that respects the freedom of your customers.  And going forward, the
> +future looks bright for the open, royalty-free Power ISA, [which is
> +now a Linux Foundation
> +project](https://www.linuxfoundation.org/press-release/2019/08/the-linux-foundation-announces-new-open-hardware-technologies-and-collaboration/)
> +(see also: [the same announcement from The OpenPOWER
> +Foundation](https://openpowerfoundation.org/the-next-step-in-the-openpower-foundation-journey/).
> +
> +
> +In Guix, all software for a given system (e.g., powerpc64le-linux) is
> +built starting from its bootstrap binaries.  It is intended that the
> +bootstrap binaries are the only pieces of software in the entire
> +package collection that Guix cannot build from source.  In practice,
> +[additional bootstrap roots are
> +possible](https://lists.gnu.org/archive/html/guix-devel/2015-02/msg00814.html),
> +but introducing them in Guix is highly discouraged, and our community
> +[actively](https://guix.gnu.org/en/blog/2019/guix-reduces

Please review blog post draft: powerpc64le-linux support

2021-04-06 Thread Chris Marusich
Hi,

Léo and I have drafted the following blog post.  Could you take a few
minutes to read it and give us your thoughts?

It's a work in progress.  The primary goal is to announce the new
powerpc64le-linux support and explain why it matters (POWER9 is an
exciting, freedom-friendly platform!).  The secondary goal is to explain
some of the details about what we did, and invite people to get
involved.

Your feedback would be highly appreciated!

-- 
Chris
From 8900d918106f6a70b20df461c5f086b5275773cc Mon Sep 17 00:00:00 2001
From: Chris Marusich 
Date: Tue, 6 Apr 2021 00:10:35 -0700
Subject: [PATCH] website: drafts: Add powerpc64le-linux announcement.

* website/drafts/new-system-powerpc64le-linux.md: New file.
---
 .../drafts/new-system-powerpc64le-linux.md| 326 ++
 1 file changed, 326 insertions(+)
 create mode 100644 website/drafts/new-system-powerpc64le-linux.md

diff --git a/website/drafts/new-system-powerpc64le-linux.md b/website/drafts/new-system-powerpc64le-linux.md
new file mode 100644
index 000..e3de5ba
--- /dev/null
+++ b/website/drafts/new-system-powerpc64le-linux.md
@@ -0,0 +1,326 @@
+title: powerpc64le-linux support in GNU Guix
+date: 2021-03-26 00:00
+author: Chris Marusich and Léo Le Bouter
+tags: porting, powerpc64le
+---
+
+It is a pleasure to announce that support for powerpc64le-linux
+(PowerISA v.2.07 and later) has now been
+[merged](https://issues.guix.gnu.org/47182) to the master branch of
+GNU Guix!
+
+This means that GNU Guix can be used immediately on this platform from
+a [from a Git
+checkout](https://guix.gnu.org/manual/en/html_node/Building-from-Git.html).
+Starting with the next release (Guix v1.2.1), you will also be able to
+[download a copy of Guix pre-built for
+powerpc64le-linux](https://guix.gnu.org/manual/en/guix.html#Binary-Installation).
+Regardless of how you get it, you can run the new powerpc64le-linux
+port of GNU Guix on top of any existing powerpc64le GNU/Linux
+distribution.
+
+This new platform is available as a "technology preview".  This means
+that although it is supported, substitutes are not yet available from
+the build farm, and some packages may fail to build.  Although
+powerpc64le-linux support is nascent, the Guix community is actively
+working on improving it, and this is a great time to [get
+involved](https://guix.gnu.org/manual/en/html_node/Contributing.html)!
+
+### Why Is This Important?
+
+This is important because it means that GNU Guix now works on the [RYF
+Talos II and Talos II Lite
+mainboards](https://www.fsf.org/news/talos-ii-mainboard-and-talos-ii-lite-mainboard-now-fsf-certified-to-respect-your-freedom)
+and it's IBM POWER9 processor.  This is a modern, performant hardware
+platform that respects your freedom.  It can run without any non-free
+code, all the way down to its bootloader and firmware.  It's a
+freedom-friendly platform that aligns well with GNU Guix's commitment
+to software freedom.
+
+How is this any different from existing RYF hardware, you might ask?
+The existing RYF
+[laptops](https://ryf.fsf.org/products?category=1=All_by=created_order=DESC),
+[mainboards](https://ryf.fsf.org/products?category=5=All_by=created_order=DESC),
+and
+[workstations](https://ryf.fsf.org/products?category=30=All_by=created_order=DESC)
+can only really be used with Intel Core Duo or AMD Opteron processors.
+Those processors were released over 15 years ago.  Since then,
+processor performance has increased drastically.  People should not
+have to choose between performance and freedom, but the fact is that
+for many years, that is exactly what we were forced to do.  However,
+the Talos II and Talos II Lite have changed this: the free software
+community now has an RYF-certified option that can compete with the
+performance of modern Intel and AMD systems.
+
+Although the performance of POWER9 processors is competitive with
+modern Intel and AMD processors, its real advantage is that it<
+respects your freedom.  Modern processors from [both Intel and AMD
+include back
+doors](https://www.fsf.org/blogs/sysadmin/the-management-engine-an-attack-on-computer-users-freedom)
+over which you are given no control.  Additionally, hardware design
+defects in the processors of both vendors have been discovered, giving
+rise to critical security vulnerabilities like
+[Spectre](https://en.wikipedia.org/wiki/Spectre_(security_vulnerability))
+and
+[Meltdown](https://en.wikipedia.org/wiki/Meltdown_(security_vulnerability)).
+In many cases, these vulnerabilities can only be fixed by installing
+[non-free CPU microcode](https://wiki.debian.org/Microcode) - unless,
+of course, [the vendor decides not to provide any fix at
+all](https://arstechnica.com/gadgets/2018/04/intel-drops-plans-to-develop-spectre-microcode-for-ancient-chips/)!
+
+Compared to that, the RYF Talos II and Talos II Lite are a breath of
+fresh air that the free software community really deserves.  Raptor
+Computing Systems' commitment to software free

Re: Blog post about the upcoming FOSDEM + Guix Day

2021-02-07 Thread Pjotr Prins
Just a reminder: tomorrow we have a GNU Guix day online! Free for all.

See 

https://libreplanet.org/wiki/Group:Guix/FOSDEM2021

Starts at 5am UTC with a Greek breakfast and runs all day until we are
done! See the link in above page.

Pj.




Re: Blog post about the upcoming FOSDEM + Guix Day

2021-02-05 Thread Leo Famulari
On Fri, Feb 05, 2021 at 11:37:49AM +0100, Ludovic Courtès wrote:
> On IRC Leo (American timezone) was thinking about having a session to
> discuss branching strategies, and there were also discussions about
> substitute availability and continuous builds for QA.

Yes, I think we can discuss branching and CI / QA in the same session.

I'm in the New York time zone, UTC−05:00

By the way, can we record these sessions?



Re: Blog post about the upcoming FOSDEM + Guix Day

2021-02-05 Thread Ludovic Courtès
Hi,

Pjotr Prins  skribis:

> We start Monday at 5am UTC (6am AMS/Berlin, 7am Athens) to cater for
> some of Asia. The day ends when the last one switches off the lights
> :).  Manolis, Efraim and Bonface have promised to be there. The
> bluebutton link will be announced a day ahead.

Could you update ?

Are there planned sessions and associated facilitators?  I think the
things on the wiki page are copy/pasted from last year and should be
updated.

I’m happy to have be on a “state of the union” session with the other
co-maintainers but we’ll need to know in advance (like now :-)) so we
can structure our thoughts a bit.  (Timezones would be Europe +
America.)

On IRC Leo (American timezone) was thinking about having a session to
discuss branching strategies, and there were also discussions about
substitute availability and continuous builds for QA.

(But really, I don’t think I can make it at 6AM local time…)

Thanks for organizing this!

Ludo’.



Re: Blog post about the upcoming FOSDEM + Guix Day

2021-02-03 Thread Bonface Munyoki K .
Efraim Flashner  writes:

> Send coffee. Lots of coffee ;D
>

Tea is more polite(?) :)

-- 
Bonface M. K. D4F09EB110177E03C28E2FE1F5BBAE1E0392253F
Humble GNU Emacs User / Bearer of scheme-y parens
Curator:  / Twitter: @BonfaceKilz


signature.asc
Description: PGP signature


Re: Blog post about the upcoming FOSDEM + Guix Day

2021-02-03 Thread Development of GNU Guix and the GNU System distribution.
We will start the day with coffee, continue with tea, and finish the day with 
some belgian beer. :)

Sent from ProtonMail mobile

 Original Message 
On Feb 3, 2021, 12:32, Bonface Munyoki K. wrote:

> Efraim Flashner  writes: > Send coffee. Lots of coffee ;D > Tea is more 
> polite(?) :) -- Bonface M. K. D4F09EB110177E03C28E2FE1F5BBAE1E0392253F Humble 
> GNU Emacs User / Bearer of scheme-y parens Curator:  / Twitter: @BonfaceKilz

Re: Blog post about the upcoming FOSDEM + Guix Day

2021-02-03 Thread Efraim Flashner
Send coffee. Lots of coffee ;D

On Wed, Feb 03, 2021 at 08:35:36AM +0100, Pjotr Prins wrote:
> We start Monday at 5am UTC (6am AMS/Berlin, 7am Athens) to cater for
> some of Asia. The day ends when the last one switches off the lights
> :).  Manolis, Efraim and Bonface have promised to be there. The
> bluebutton link will be announced a day ahead.
> 
> Pj.
> 
> On Tue, Feb 02, 2021 at 05:40:04PM -0500, Leo Famulari wrote:
> > On Tue, Feb 02, 2021 at 07:07:47PM +0100, Ludovic Courtès wrote:
> > > Here we go!
> > > 
> > >   https://guix.gnu.org/en/blog/2021/meet-guix-at-fosdem-2021/
> > 
> > People in #guix were asking, "When exactly does it start?" Can we update
> > the blog post to say?
> > 

-- 
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: Blog post about the upcoming FOSDEM + Guix Day

2021-02-02 Thread Pjotr Prins
We start Monday at 5am UTC (6am AMS/Berlin, 7am Athens) to cater for
some of Asia. The day ends when the last one switches off the lights
:).  Manolis, Efraim and Bonface have promised to be there. The
bluebutton link will be announced a day ahead.

Pj.

On Tue, Feb 02, 2021 at 05:40:04PM -0500, Leo Famulari wrote:
> On Tue, Feb 02, 2021 at 07:07:47PM +0100, Ludovic Courtès wrote:
> > Here we go!
> > 
> >   https://guix.gnu.org/en/blog/2021/meet-guix-at-fosdem-2021/
> 
> People in #guix were asking, "When exactly does it start?" Can we update
> the blog post to say?
> 



Re: Blog post about the upcoming FOSDEM + Guix Day

2021-02-02 Thread Leo Famulari
On Tue, Feb 02, 2021 at 07:07:47PM +0100, Ludovic Courtès wrote:
> Here we go!
> 
>   https://guix.gnu.org/en/blog/2021/meet-guix-at-fosdem-2021/

People in #guix were asking, "When exactly does it start?" Can we update
the blog post to say?



Re: Blog post about the upcoming FOSDEM + Guix Day

2021-02-02 Thread Ludovic Courtès
Here we go!

  https://guix.gnu.org/en/blog/2021/meet-guix-at-fosdem-2021/

Ludo’.



Re: Blog post about the upcoming FOSDEM + Guix Day

2021-02-02 Thread Development of GNU Guix and the GNU System distribution.
It seems I can create rooms. I created a `Guix Day` one.

https://guixbbb.fosshost.org/b/man-wtf-odj-91i

Let's try to coordinate tomorrow through email/irc and join for a test.

On 2/1/21 8:51 PM, Pjotr Prins wrote:
> 
> Sure. Call a time tomorrow and anyone on IRC/mail/matrix can pop in. Are you
> a host Manolis? A host can create rooms.
> 
> On Mon, Feb 01, 2021 at 06:31:37PM +, Manolis Ragkousis wrote:
>>Maybe it would be a good idea to test big blue button tomorrow? How
>>about a call?
>>Sent from ProtonMail mobile
>> Original Message 
>>On Feb 1, 2021, 19:49, zimoun < zimon.touto...@gmail.com> wrote:
>>
>>  Hi,
>>
>>  On Mon, 01 Feb 2021 at 17:30, Ludovic Courtès  wrote:
>>
>>  > Attendance to the workshop is free and open to everyone, though
>>  you are
>>  > -invited to register (there are only a few seats left!). Check out
>>  [the
>>  > -workshop’s wiki
>>  > +invited to register (there are only a few seats left!). Join [our
>>  > +BigBlueButton instance]([1]https://guixbbb.fosshost.org) on
>>  Monday 8th at
>>  > +10AM CET, and check out [the workshop’s wiki
>>  > page]([2]https://libreplanet.org/wiki/Group:Guix/FOSDEM2021) for
>>  practical
>>  > info. Hope to see you on-line!
>>
>>  [...]
>>
>>  > If we’re not prepared for a broader event, maybe we can make it a
>>  > small-case developer gathering and not announce it publicly?
>>
>>  Reading the Pjotr’s answer, maybe small-case developer gathering and
>>  not
>>  announce it publicly seems better; even if we are announcing
>>  publicly
>>  right now. ;-)
>>
>>  The program of the fringe event says:
>>
>>  In the European morning the following presentations are planned:
>>
>>  1. Guix State of the Union by Ludovic Courtès + Tobias
>>  Geerinckx-Rice
>>  2. Guix Data Service by Christopher Baines
>>  3. Bootstrapping Intro by Jan Nieuwenhuizen
>>
>>  …and many more…
>>
>>  Is it still something in the pipes? If yes, is it possible to set
>>  something more precise than «European morning»?
>>
>>  BTW, do we fix hour/check points to organize the day? Or is it an
>>  usual
>>  day on #guix/#guix-hpc where some video chats is hypothetically
>>  added?
>>
>>  Cheers,
>>  simon
>>
>> References
>>
>>1. https://guixbbb.fosshost.org/
>>2. https://libreplanet.org/wiki/Group:Guix/FOSDEM2021

-- 
Manolis Ragkousis   |  Tel: +30 6985855120




Re: Blog post about the upcoming FOSDEM + Guix Day

2021-02-02 Thread Development of GNU Guix and the GNU System distribution.
Maybe it would be a good idea to test big blue button tomorrow? How about a 
call?

Sent from ProtonMail mobile

 Original Message 
On Feb 1, 2021, 19:49, zimoun wrote:

> Hi,
>
> On Mon, 01 Feb 2021 at 17:30, Ludovic Courtès  wrote:
>
>> Attendance to the workshop is free and open to everyone, though you are
>> -invited to register (there are only a few seats left!). Check out [the
>> -workshop’s wiki
>> +invited to register (there are only a few seats left!). Join [our
>> +BigBlueButton instance](https://guixbbb.fosshost.org) on Monday 8th at
>> +10AM CET, and check out [the workshop’s wiki
>> page](https://libreplanet.org/wiki/Group:Guix/FOSDEM2021) for practical
>> info. Hope to see you on-line!
>
> [...]
>
>> If we’re not prepared for a broader event, maybe we can make it a
>> small-case developer gathering and not announce it publicly?
>
> Reading the Pjotr’s answer, maybe small-case developer gathering and not
> announce it publicly seems better; even if we are announcing publicly
> right now. ;-)
>
> The program of the fringe event says:
>
> In the European morning the following presentations are planned:
>
> 1. Guix State of the Union by Ludovic Courtès + Tobias Geerinckx-Rice
> 2. Guix Data Service by Christopher Baines
> 3. Bootstrapping Intro by Jan Nieuwenhuizen
>
> …and many more…
>
> Is it still something in the pipes? If yes, is it possible to set
> something more precise than «European morning»?
>
> BTW, do we fix hour/check points to organize the day? Or is it an usual
> day on #guix/#guix-hpc where some video chats is hypothetically added?
>
> Cheers,
> simon

Re: Blog post about the upcoming FOSDEM + Guix Day

2021-02-01 Thread Leo Famulari
On Mon, Feb 01, 2021 at 04:57:58PM +0100, Pjotr Prins wrote:
> So far, we'll have a GNU Hurd session and a Rust packaging session. We
> will also discuss ARM, RISC-V and GNU Mes. Otherwise the program is
> open for newbies and unconference topics alike. If you want to propose
> something this may be the time.

I think we should discuss the state of the build farm, the Guix Build
Coordinator, and proposed changes to the "big updates strategy" (i.e.
core-updates).



Re: Blog post about the upcoming FOSDEM + Guix Day

2021-02-01 Thread Pjotr Prins
Sure. Call a time tomorrow and anyone on IRC/mail/matrix can pop in. Are you
a host Manolis? A host can create rooms.

On Mon, Feb 01, 2021 at 06:31:37PM +, Manolis Ragkousis wrote:
>Maybe it would be a good idea to test big blue button tomorrow? How
>about a call?
>Sent from ProtonMail mobile
> Original Message 
>On Feb 1, 2021, 19:49, zimoun < zimon.touto...@gmail.com> wrote:
> 
>  Hi,
> 
>  On Mon, 01 Feb 2021 at 17:30, Ludovic Courtès  wrote:
> 
>  > Attendance to the workshop is free and open to everyone, though
>  you are
>  > -invited to register (there are only a few seats left!). Check out
>  [the
>  > -workshop’s wiki
>  > +invited to register (there are only a few seats left!). Join [our
>  > +BigBlueButton instance]([1]https://guixbbb.fosshost.org) on
>  Monday 8th at
>  > +10AM CET, and check out [the workshop’s wiki
>  > page]([2]https://libreplanet.org/wiki/Group:Guix/FOSDEM2021) for
>  practical
>  > info. Hope to see you on-line!
> 
>  [...]
> 
>  > If we’re not prepared for a broader event, maybe we can make it a
>  > small-case developer gathering and not announce it publicly?
> 
>  Reading the Pjotr’s answer, maybe small-case developer gathering and
>  not
>  announce it publicly seems better; even if we are announcing
>  publicly
>  right now. ;-)
> 
>  The program of the fringe event says:
> 
>  In the European morning the following presentations are planned:
> 
>  1. Guix State of the Union by Ludovic Courtès + Tobias
>  Geerinckx-Rice
>  2. Guix Data Service by Christopher Baines
>  3. Bootstrapping Intro by Jan Nieuwenhuizen
> 
>  …and many more…
> 
>  Is it still something in the pipes? If yes, is it possible to set
>  something more precise than «European morning»?
> 
>  BTW, do we fix hour/check points to organize the day? Or is it an
>  usual
>  day on #guix/#guix-hpc where some video chats is hypothetically
>  added?
> 
>  Cheers,
>  simon
> 
> References
> 
>1. https://guixbbb.fosshost.org/
>2. https://libreplanet.org/wiki/Group:Guix/FOSDEM2021



Re: Blog post about the upcoming FOSDEM + Guix Day

2021-02-01 Thread zimoun
Hi,

On Mon, 01 Feb 2021 at 17:30, Ludovic Courtès  wrote:

>  Attendance to the workshop is free and open to everyone, though you are
> -invited to register (there are only a few seats left!).  Check out [the
> -workshop’s wiki
> +invited to register (there are only a few seats left!).  Join [our
> +BigBlueButton instance](https://guixbbb.fosshost.org) on Monday 8th at
> +10AM CET, and check out [the workshop’s wiki
>  page](https://libreplanet.org/wiki/Group:Guix/FOSDEM2021) for practical
>  info.  Hope to see you on-line!

[...]

> If we’re not prepared for a broader event, maybe we can make it a
> small-case developer gathering and not announce it publicly?

Reading the Pjotr’s answer, maybe small-case developer gathering and not
announce it publicly seems better; even if we are announcing publicly
right now. ;-)

The program of the fringe event says:

In the European morning the following presentations are planned:

   1. Guix State of the Union by Ludovic Courtès + Tobias Geerinckx-Rice
   2. Guix Data Service by Christopher Baines
   3. Bootstrapping Intro by Jan Nieuwenhuizen

…and many more…

Is it still something in the pipes?  If yes, is it possible to set
something more precise than «European morning»?

BTW, do we fix hour/check points to organize the day?  Or is it an usual
day on #guix/#guix-hpc where some video chats is hypothetically added?


Cheers,
simon



Re: Blog post about the upcoming FOSDEM + Guix Day

2021-02-01 Thread Pjotr Prins
On Mon, Feb 01, 2021 at 05:30:26PM +0100, Ludovic Courtès wrote:
> Pjotr, Manolis, what are you thoughts?  I’m happy to have this event and
> to make something unconference-style, but IMO we need to have a clearer
> view of when it’ll take place, what we’ll be doing, who’s going to
> moderate, that sort of thing.  :-)

We have the moderators and plan to cross 3 TZs. Bonface and Efraim
start in the Asia slot (6am EU). Manolis and me will take Europe and
after from 9am.

> If we’re not prepared for a broader event, maybe we can make it a
> small-case developer gathering and not announce it publicly?

It is already public as a fringe event :). But, I think, realistically
it will be just us having a discussion/hacking day. But if anyone
walks in the door we should be happy to facilitate. 

  https://fosdem.org/2021/fringe/

I know we don't like lack of structure, but I feel this is just an
open door kinda thing. 

Pj.



Re: Blog post about the upcoming FOSDEM + Guix Day

2021-02-01 Thread Ludovic Courtès
Hi,

zimoun  skribis:

> On Mon, 1 Feb 2021 at 10:35, Ludovic Courtès  wrote:
>
>>   
>> https://git.savannah.gnu.org/cgit/guix/guix-artwork.git/tree/website/drafts/meet-guix-at-fosdem-2021.md
>
> LGTM!
>
>> Regarding the Guix Day next Monday, do we have the BBB URL or will it be
>> disclosed later?  What should we say regarding practical connection
>> info?
>
> The Fosshost BBB instance at  is still
> alive.  We are using it every week to run our Outreachy Weekly
> meeting.
> Aside that, I do not know what is planned for the Day.

So what about:

diff --git a/website/drafts/meet-guix-at-fosdem-2021.md b/website/drafts/meet-guix-at-fosdem-2021.md
index 724ba02..773796b 100644
--- a/website/drafts/meet-guix-at-fosdem-2021.md
+++ b/website/drafts/meet-guix-at-fosdem-2021.md
@@ -70,8 +70,9 @@ sessions focused on specific hot topics about Guix, the Shepherd,
 continuous integration, and related tools and workflows.
 
 Attendance to the workshop is free and open to everyone, though you are
-invited to register (there are only a few seats left!).  Check out [the
-workshop’s wiki
+invited to register (there are only a few seats left!).  Join [our
+BigBlueButton instance](https://guixbbb.fosshost.org) on Monday 8th at
+10AM CET, and check out [the workshop’s wiki
 page](https://libreplanet.org/wiki/Group:Guix/FOSDEM2021) for practical
 info.  Hope to see you on-line!
 

Pjotr, Manolis, what are you thoughts?  I’m happy to have this event and
to make something unconference-style, but IMO we need to have a clearer
view of when it’ll take place, what we’ll be doing, who’s going to
moderate, that sort of thing.  :-)

If we’re not prepared for a broader event, maybe we can make it a
small-case developer gathering and not announce it publicly?

Thanks,
Ludo’.


Re: Blog post about the upcoming FOSDEM + Guix Day

2021-02-01 Thread Pjotr Prins
On Mon, Feb 01, 2021 at 10:41:53AM +0100, zimoun wrote:
> Hi Ludo,
> 
> On Mon, 1 Feb 2021 at 10:35, Ludovic Courtès  wrote:
> 
> >   
> > https://git.savannah.gnu.org/cgit/guix/guix-artwork.git/tree/website/drafts/meet-guix-at-fosdem-2021.md
> 
> LGTM!
> 
> > Regarding the Guix Day next Monday, do we have the BBB URL or will it be
> > disclosed later?  What should we say regarding practical connection
> > info?
> 
> The Fosshost BBB instance at  is still
> alive.  We are using it every week to run our Outreachy Weekly
> meeting.
> Aside that, I do not know what is planned for the Day.

So far, we'll have a GNU Hurd session and a Rust packaging session. We
will also discuss ARM, RISC-V and GNU Mes. Otherwise the program is
open for newbies and unconference topics alike. If you want to propose
something this may be the time.

BTW Manolis and I previewed the talks of the FOSDEM devroom and it is
going to be amazing!

  https://fosdem.org/2021/schedule/track/declarative_and_minimalistic_computing/

Attending is free. Just click on the talk when it starts. It'll stream
on Jitsy and we have matrix for chat (join http://chat.fosdem.org).
Thank you to all those who took the trouble of recording a
presentation :)

Pj.

PS the talks will be available after for viewing too.




Re: Blog post about the upcoming FOSDEM + Guix Day

2021-02-01 Thread zimoun
Hi Ludo,

On Mon, 1 Feb 2021 at 10:35, Ludovic Courtès  wrote:

>   
> https://git.savannah.gnu.org/cgit/guix/guix-artwork.git/tree/website/drafts/meet-guix-at-fosdem-2021.md

LGTM!

> Regarding the Guix Day next Monday, do we have the BBB URL or will it be
> disclosed later?  What should we say regarding practical connection
> info?

The Fosshost BBB instance at  is still
alive.  We are using it every week to run our Outreachy Weekly
meeting.
Aside that, I do not know what is planned for the Day.

Cheers,
simon



Re: Blog post on Further reduced bootstrap seed to 25%

2020-06-16 Thread Jan Nieuwenhuizen
Danny Milosavljevic writes:

Hi Danny,

> On Mon, 15 Jun 2020 14:54:39 +0200
> Jan Nieuwenhuizen  wrote:
>
>> I’ve published a post about the second big reduction of the Guix
>> bootstrap binaries
>> 
>> https://guix.gnu.org/blog/2020/guix-further-reduces-bootstrap-seed-to-25/
>
> "again decided to sponsor this work" link is broken
>
> Otherwise good :)

Thanks, fix pushed!

Janneke

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



Re: Blog post on Further reduced bootstrap seed to 25%

2020-06-15 Thread Maxim Cournoyer
Hello Jan,

Jan Nieuwenhuizen  writes:

> Hello Guix!
>
> I’ve published a post about the second big reduction of the Guix
> bootstrap binaries
>
> https://guix.gnu.org/blog/2020/guix-further-reduces-bootstrap-seed-to-25/
>
> Thanks to the recent merge of ‘core-updates’ some weeks days ago, the
> set of bootstrap binaries now weighs in at approximately 60 MiB; about
> 25% of what it used to be.
>
> Thanks to Timothy Samplet, Danny Milosavljevic and Ludovic Courtès for
> their feedback and help on an earlier version of this post!
>
> Greetings,
> Janneke

Thank you for this very well written blog post!  It's a fantastic
achievement that benefits us all Guix users.

Congratulations!

Maxim



Re: Blog post on Further reduced bootstrap seed to 25%

2020-06-15 Thread Danny Milosavljevic
Hi Janneke,

On Mon, 15 Jun 2020 14:54:39 +0200
Jan Nieuwenhuizen  wrote:

> I’ve published a post about the second big reduction of the Guix
> bootstrap binaries
> 
> https://guix.gnu.org/blog/2020/guix-further-reduces-bootstrap-seed-to-25/

"again decided to sponsor this work" link is broken

Otherwise good :)


pgpF6DS0rJec8.pgp
Description: OpenPGP digital signature


Re: unexpected reproducibility of reproducible blog post?

2020-05-05 Thread Konrad Hinsen
Hi Ludo,

> Grafts are normal derivations, and they’re deterministic: it’s just
> about replacing a set of strings by another set of strings.
>
> On the implementation, see also
> .

Thanks for the clarification. That post makes it clear that grafts only
modify the build process of grafted packages.

Cheers,
  Konrad



Re: unexpected reproducibility of reproducible blog post?

2020-05-05 Thread Ludovic Courtès
Hi,

Konrad Hinsen  skribis:

> I looked a bit at grafts. The documentation at
>
>   https://guix.gnu.org/manual/en/html_node/Security-Updates.html
>
> isn't very explicit about the reproducibility of grafts. In particular,
> it doesn't say if a package containing patched binaries retains its
> original hash, or receives a new unique one. With a unique hash, grafts
> would just be a tweak in the build system, and no less reproducible than
> standard builds. It looks like I have to dive into the source code to
> find out!

Grafts are normal derivations, and they’re deterministic: it’s just
about replacing a set of strings by another set of strings.

On the implementation, see also
.
I’m also preparing a post of the recent (pre-1.1.0) changes in that
area.

Ludo’.



Re: unexpected reproducibility of reproducible blog post?

2020-05-04 Thread zimoun
Hi Konrad,

(add Ludo for advice :-))

On Mon, 4 May 2020 at 15:50, Konrad Hinsen  wrote:

> > I will add something overthere for tracking reproduciblity infos in
> > the future.
>
> It would actually be nice to have some external Guix reproducibility
> surveillance. A few benchmark packages that will be rebuilt regularly,
> using frozen commits via time-machine, and checked for bit-by-bit
> identity explicitly, not relying on Guix' hash mechanism. Trust but
> verify.
>
> My example is perhaps not such a bad start. Building a Docker container
> containing gcc exercises a lot of code in Guix.

Does it make sense to:

add the file "tests/guix-reproducibility.sh"?
So that reproducibility issues are detected by "make check".

Or add another rule in the Makefile?

Or test reproducibility outside the Guix tree?


All the best,
simon



>
> I looked a bit at grafts. The documentation at
>
>   https://guix.gnu.org/manual/en/html_node/Security-Updates.html
>
> isn't very explicit about the reproducibility of grafts. In particular,
> it doesn't say if a package containing patched binaries retains its
> original hash, or receives a new unique one. With a unique hash, grafts
> would just be a tweak in the build system, and no less reproducible than
> standard builds. It looks like I have to dive into the source code to
> find out!
>
> Cheers,
>   Konrad



Re: unexpected reproducibility of reproducible blog post?

2020-05-04 Thread Konrad Hinsen
Hi Simon,

> I will add something overthere for tracking reproduciblity infos in
> the future.

It would actually be nice to have some external Guix reproducibility
surveillance. A few benchmark packages that will be rebuilt regularly,
using frozen commits via time-machine, and checked for bit-by-bit
identity explicitly, not relying on Guix' hash mechanism. Trust but
verify.

My example is perhaps not such a bad start. Building a Docker container
containing gcc exercises a lot of code in Guix.

I looked a bit at grafts. The documentation at

  https://guix.gnu.org/manual/en/html_node/Security-Updates.html

isn't very explicit about the reproducibility of grafts. In particular,
it doesn't say if a package containing patched binaries retains its
original hash, or receives a new unique one. With a unique hash, grafts
would just be a tweak in the build system, and no less reproducible than
standard builds. It looks like I have to dive into the source code to
find out!

Cheers,
  Konrad



Re: unexpected reproducibility of reproducible blog post?

2020-04-30 Thread zimoun
On Wed, 29 Apr 2020 at 18:00, Konrad Hinsen  wrote:

> I have also opened an issue for this:
>
>   https://github.com/khinsen/reproducibility-with-guix/issues/2

I will add something overthere for tracking reproduciblity infos in the future.


> > Grafts or maybe Guile 2 -> 3?
>
> With time-machine, you run the full Guix from back then, so you run
> Guile 2 if that's what it takes. What I am not so sure about is how the
> old Guix release is built. If the build uses the equivalent of "guix
> environment guix", it would start using Guile 3.

>From [1] and assuming that the commit was the same, i.e.,
769b96b62e8c09b078f73adc09fb860505920f8f, there is also a mismatch
about the resulting binary.

Expected:
1be3c1b5d1e065017e4c56f725b1a692

Now:
2805a33e2e48f648307c6b913b69e41c

--8<---cut here---start->8---
guix describe # f03e5ca
guix time-machine \
 --commit=769b96b62e8c09b078f73adc09fb860505920f8f \
 -- environment --container --ad-hoc gcc-toolchain \
 -- gcc pi.c -o pi-guix
--8<---cut here---end--->8---

[1] https://lists.gnu.org/archive/html/guix-devel/2020-01/msg00192.html

>From f03e5ca, the time machine downloads the substitute:
   
https://ci.guix.gnu.org/nar/lzip/ij38zh495f81xpzmp4qzqz4fprczwck2-gcc-toolchain-9.2.0


> Time travelling is not as simple as it looks, but then we should have
> expected that!

I agree but it is annoying.
Because `in fine` the computations are not more reproducible than say
Debian if 3 months later we are not able to reproduce them bit-to-bit.
I do not know. Maybe it is about 'time-machine', maybe about the exact
commit used (most probable! :-)), maybe about the Guix build toolchain
(seed) used to travel back and restore the previous build toolchain.
Who knows? :-)

Well, I will try later with my desktop machine when I will be back at
the office; hoping that I did not garbage collected. :-)


Cheers,
simon



Re: unexpected reproducibility of reproducible blog post?

2020-04-29 Thread Konrad Hinsen
zimoun  writes:

> Argh! The author should watch the Fun MOOC about computational
> reproducibility. ;-)

That would probably help. I'll pass on the message ;-)

I have also opened an issue for this:

  https://github.com/khinsen/reproducibility-with-guix/issues/2

> Grafts or maybe Guile 2 -> 3?

With time-machine, you run the full Guix from back then, so you run
Guile 2 if that's what it takes. What I am not so sure about is how the
old Guix release is built. If the build uses the equivalent of "guix
environment guix", it would start using Guile 3.

Time travelling is not as simple as it looks, but then we should have
expected that!

Cheers,
  Konrad



Re: unexpected reproducibility of reproducible blog post?

2020-04-29 Thread zimoun
Hi Ricardo,

On Wed, 29 Apr 2020 at 14:44, Ricardo Wurmus  wrote:
>
>
> Konrad Hinsen  writes:
>
> > One question I have been wondering about is the possibility of grafts
> > being an obstacle to reproducibility. Grafts are something I don't
> > really understand yet, so I cannot answer this question. In particular,
> > does a grafted package get a different hash from a package built with
> > grafting disabled?
>
> Yes.
>
> A grafted package is a copy of the original package but with all
> references to /gnu/store/AA-… replaced with /gnu/store/BB-….
> This is done recursively starting with the direct users of the
> replaced package and for all users of those users.

Could the grafts explain the mismatch reported before?


Cheers,
simon



Re: unexpected reproducibility of reproducible blog post?

2020-04-29 Thread Ricardo Wurmus


Konrad Hinsen  writes:

> One question I have been wondering about is the possibility of grafts
> being an obstacle to reproducibility. Grafts are something I don't
> really understand yet, so I cannot answer this question. In particular,
> does a grafted package get a different hash from a package built with
> grafting disabled?

Yes.

A grafted package is a copy of the original package but with all
references to /gnu/store/AA-… replaced with /gnu/store/BB-….
This is done recursively starting with the direct users of the
replaced package and for all users of those users.

--
Ricardo



Re: unexpected reproducibility of reproducible blog post?

2020-04-29 Thread zimoun
Hi Konrad,

On Wed, 29 Apr 2020 at 11:26, Konrad Hinsen  wrote:

> > Has the file 'guix-version-for-reproduction.txt' been tracked?
>
> Unfortunately not. The repository for the preparation of the post
> is at
>
>   https://github.com/khinsen/reproducibility-with-guix/
>
> but it doesn't contain the file 'guix-version-for-reproduction.txt'.

Argh! The author should watch the Fun MOOC about computational
reproducibility. ;-)


> > Is really the commit 769b96b62e8c09b078f73adc09fb860505920f8f used to
> > produce the Docker image listed in the blog post?
>
> Hard to say... I can't play with that right now because I am running
> jobs on my computer that eat all the memory.

Leo reproduced the new observed hash.


> One question I have been wondering about is the possibility of grafts
> being an obstacle to reproducibility. Grafts are something I don't
> really understand yet, so I cannot answer this question. In particular,
> does a grafted package get a different hash from a package built with
> grafting disabled?

Grafts or maybe Guile 2 -> 3?


Cheers,
simon



Re: unexpected reproducibility of reproducible blog post?

2020-04-29 Thread Konrad Hinsen
Hi Simon,

> Based on the nice blog post [1], instead of really travelling I just
> travel in time. :-)
> If I read correctly and if I did not do any mistake, the final hash is
> not the same now than before. It is not what I was expecting.
>
> Expected output (blog post):
> /gnu/store/iqn9yyvi8im18g7y9f064lw9s9knxp0w-docker-pack.tar
>
> Returned output:
> /gnu/store/klisfr3a4wxb9dc5sgibb45kky72kg65-docker-pack.tar
>
> Has the file 'guix-version-for-reproduction.txt' been tracked?

Unfortunately not. The repository for the preparation of the post
is at 

  https://github.com/khinsen/reproducibility-with-guix/

but it doesn't contain the file 'guix-version-for-reproduction.txt'.

> Is really the commit 769b96b62e8c09b078f73adc09fb860505920f8f used to
> produce the Docker image listed in the blog post?

Hard to say... I can't play with that right now because I am running
jobs on my computer that eat all the memory.

One question I have been wondering about is the possibility of grafts
being an obstacle to reproducibility. Grafts are something I don't
really understand yet, so I cannot answer this question. In particular,
does a grafted package get a different hash from a package built with
grafting disabled?

Cheers,
  Konrad.



  1   2   >