Re: Neovim plugin/addon packaging

[Efraim Flashner]

On Mon, May 03, 2021 at 12:46:30AM -0400, Jack Hill wrote:
> On Sun, 2 May 2021, Efraim Flashner wrote:
> 
> > ng0/nikita thought about it a few years ago but I think the
> > copy-build-system works well enough. I know for vim we need a vim
> > profile hook to create the documentation, does neovim need something
> > like that too?
> 
> I'm not sure and will need to investigate. With the XDG_DATA_DIRS search
> path, if I install neovim and neovim-syntastic into the same environment, I
> am able to see references to the syntastic documentation in the main help
> index, but trying to navigate to them results in a 'E149: Sorry, no help for
> syntastic-checkers.txt' error, so clearly something is not quite right.
> 

That's always something we can fix later. It's also not more broken than
it is now.

-- 
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: Neovim plugin/addon packaging

[Jack Hill]

On Sun, 2 May 2021, Efraim Flashner wrote:


ng0/nikita thought about it a few years ago but I think the
copy-build-system works well enough. I know for vim we need a vim
profile hook to create the documentation, does neovim need something
like that too?


I'm not sure and will need to investigate. With the XDG_DATA_DIRS search 
path, if I install neovim and neovim-syntastic into the same environment, 
I am able to see references to the syntastic documentation in the main 
help index, but trying to navigate to them results in a 'E149: Sorry, no 
help for syntastic-checkers.txt' error, so clearly something is not quite 
right.


Best,
Jack

Re: [PATCH] maint: Do not xz-compress ISO images.

[Julien Lepiller]

Le Sun,  2 May 2021 23:16:48 +0200,
Ludovic Courtès  a écrit :

> The xz-compressed image is 23% smaller than the original ISO image
> (with built-in zlib compression), but the extra decompression step is
> unconventional and often a hindrance for users.  See discussion at
> .
> 
> * Makefile.am (release): Do not compress ISO images.
> * doc/guix.texi (USB Stick and DVD Installation): Remove ".xz" suffix
> from URL and file name.
> (Copying to a USB Stick, Burning on a DVD): Remove introductory words,
> @enumerate, and first item.

I have to ask about the patch title: what does "maint" mean?

> ---
>  Makefile.am   |  6 +++---
>  doc/guix.texi | 30 +++---
>  2 files changed, 6 insertions(+), 30 deletions(-)
> 
> Hi!
> 
> This takes the simple step of providing plain ISOs only (rather than
> .iso + .iso.xz as some suggested).
> 
> One advantage is that, unless I’m mistaken, this can be done without
> breaking string freeze.
> 
> We’ll also have to update  on the
> release day.
> 
> Thoughts?
> 
> Ludo’.
> 
> diff --git a/Makefile.am b/Makefile.am
> index 8d059eb033..623b1c497f 100644
> --- a/Makefile.am
> +++ b/Makefile.am
> @@ -886,9 +886,9 @@ release: dist-with-updated-version all
>   echo "failed to produced Guix installation image for
> $$system" >&2 ;   \ exit 1 ;
>   \ fi ;
>   \
> -   xz < "$$image" >
> "$(releasedir)/$(GUIX_SYSTEM_IMAGE_BASE).$$system.iso.xz.tmp"
> ; \
> -   mv
> "$(releasedir)/$(GUIX_SYSTEM_IMAGE_BASE).$$system.iso.xz.tmp"
>   \
> -
> "$(releasedir)/$(GUIX_SYSTEM_IMAGE_BASE).$$system.iso.xz" ;
>   \
> +   cp "$$image"
> "$(releasedir)/$(GUIX_SYSTEM_IMAGE_BASE).$$system.iso.tmp" ;  \
> +   mv
> "$(releasedir)/$(GUIX_SYSTEM_IMAGE_BASE).$$system.iso.tmp"
>   \
> +  "$(releasedir)/$(GUIX_SYSTEM_IMAGE_BASE).$$system.iso"
> ; \ done
>  # Generate the VM images.
>   for system in $(GUIX_SYSTEM_VM_SYSTEMS) ; do
>   \ diff --git a/doc/guix.texi b/doc/guix.texi
> index 2fe7ad3a2a..3460c58cbc 100644
> --- a/doc/guix.texi
> +++ b/doc/guix.texi
> @@ -2099,7 +2099,7 @@ about their support in GNU/Linux.
>  
>  An ISO-9660 installation image that can be written to a USB stick or
>  burnt to a DVD can be downloaded from
> -@indicateurl{@value{BASE-URL}/guix-system-install-@value{VERSION}.x86_64-linux.iso.xz},
> +@indicateurl{@value{BASE-URL}/guix-system-install-@value{VERSION}.x86_64-linux.iso},
>  where you can replace @code{x86_64-linux} with one of:

Sorry, this actually breaks string freeze. Now for something like this,
we could grant an exception? It's not like it's too hard to fix, even
manually and even if you don't know the language :)

>  
>  @table @code
> @@ -2115,8 +2115,8 @@ Make sure to download the associated
> @file{.sig} file and to verify the authenticity of the image against
> it, along these lines: 
>  @example
> -$ wget
> @value{BASE-URL}/guix-system-install-@value{VERSION}.x86_64-linux.iso.xz.sig
> -$ gpg --verify
> guix-system-install-@value{VERSION}.x86_64-linux.iso.xz.sig +$ wget
> @value{BASE-URL}/guix-system-install-@value{VERSION}.x86_64-linux.iso.sig
> +$ gpg --verify
> guix-system-install-@value{VERSION}.x86_64-linux.iso.sig @end example

Even that example actually breaks it: examples can contain comments
that should be translated, so po4a lets translators do whatever they
want with them. Again, it's easy to fix.

> If that command fails because you do not have the required public
> key, @@ -2140,17 +2140,6 @@ It is meant to be copied @emph{as is} to
> a large-enough USB stick or DVD. @unnumberedsubsec Copying to a USB
> Stick 
> -To copy the image to a USB stick, follow these steps:
> -
> -@enumerate
> -@item
> -Decompress the image using the @command{xz} command:
> -
> -@example
> -xz -d guix-system-install-@value{VERSION}.x86_64-linux.iso.xz
> -@end example
> -
> -@item

Now removing text is fine :)

LGTM, but what should we do about the strings?

Re: RISC-V is giving away developer boards

[Danny Milosavljevic]

> Could interested developers raise their hands?  :-)

*raises hand*

In other news, tinycc has now an RISC-V assembler[1] :)

[1] https://lists.nongnu.org/archive/html/tinycc-devel/2021-04/msg9.html

Re: linux-libre source tarballs

[Leo Famulari]

On Sun, May 02, 2021 at 06:26:15PM -0400, Leo Famulari wrote:
> In the meantime, can we make a 'kernel-updates' Cuirass job again, that
> would build a kernel-updates branch on Savannah?

Mistake: I'd want to call the branch wip-kernel-updates, so that it's
rebaseable.

> We had one recently for a brief period but I stopped using it, because I
> could work more quickly building the tarballs "by hand" (although I've
> only been doing it for x86_64).
> 
> However, it would be helpful to let Cuirass at least try to build these
> derivations, with me checking the results and retrying failures before
> pushing kernel-updates to master.

Re: linux-libre source tarballs

[Leo Famulari]

On Sun, May 02, 2021 at 11:08:49PM +0200, Ludovic Courtès wrote:
> For packages we can add a ‘max-silent-time’ property, but there’s
> nothing like this for origins.

Oh, right.

> I wonder if there’s a way we could address it in (gnu ci).
> 
> Thoughts?

In the meantime, can we make a 'kernel-updates' Cuirass job again, that
would build a kernel-updates branch on Savannah?

We had one recently for a brief period but I stopped using it, because I
could work more quickly building the tarballs "by hand" (although I've
only been doing it for x86_64).

However, it would be helpful to let Cuirass at least try to build these
derivations, with me checking the results and retrying failures before
pushing kernel-updates to master.

Re: GNU Guix 1.3.0rc1 available for testing!

[Leo Famulari]

On Sun, May 02, 2021 at 02:45:18PM -0400, Maxim Cournoyer wrote:
> It should fail only once (as it currently would if Ludo's key was
> missing), and display two messages/two commands instead of one to get
> the missing keys.  This is because we exit after the loop, based on the
> exit_flag variable value we set in the loop.  Did it not behave that way
> for you?

I did not think that it had, but I tried it again just now, and it
worked as you described.

I noticed that it was 404 an hour or two ago. Maybe the revision of the
script being served by the website was cached and obsolete or something.

Anyways, it seems fine now!

We just need to update the manual on the version-1.3.0 branch (and
probably master too).

Re: Pinebook Pro no longer WIP

[Vincent Legoll]

Hello,

On Sun, May 2, 2021 at 2:33 AM Vagrant Cascadian  wrote:
> Untested:
>   eMMC

I've tested this today. I was on sdcard, and migrated "/" to emmc,
keeping the bootloader on sdcard because I don't like opening
the PBP to get back to a booting state in case of problems.

I modified the root FS UUID in system config, then `guix system
init`'ed to the emmc, rebooted and it was working OK. then did a
pull+reconfigure to double check.

> Outstanding bugs and/or quirks:
>
>   often hangs on reboot and keeps draining power
>   sometimes hangs on shutdown and keeps draining power

Yes, I'm also having problems to (re)boot.

> I've only tested with the "linux-libre-arm64-generic" kernels

Same here.

Thanks

-- 
Vincent Legoll

Re: Criticisms of my "tone" (was Re: A "cosmetic changes" commit that removes security fixes)

[Leo Prikler]

Hi Mark,

Am Sonntag, den 02.05.2021, 17:02 -0400 schrieb Mark H Weaver:
> Hi Leo,
> 
> Leo Prikler  writes:
> 
> > Am Sonntag, den 02.05.2021, 15:29 -0400 schrieb Mark H Weaver:
> > 
> > Likewise, there's no middle ground on assuming evil
> > intentions, you either assume they exist or you don't.
> 
> That's true also, but this is a different dichotomy than the one you
> presented above.  In the sentence above, the dichotomy is between:
> 
>   (1) You assume bad faith
>   (2) You do not assume bad faith
> 
> In your list of scenarios above, there's a (false) dichotomy between:
> 
>   (1) You assume bad faith
>   (2) You assume good faith
> 
> It's a false dichotomy because neither of these is the logical
> negation of the other.  They cannot both be true, but they _can_ both
> be false.
> 
> In other words, I think that you have conflated "not assuming bad
> faith" with "assuming good faith".  Do you see the difference?
> 
> This is not mere nitpicking.  It's a very important distinction.
> It's analogous to being forced to choose between "faith in god" and
> "atheism", without allowing for the possibility of "agnosticism".
> 
> Does that make sense?
When it comes to interactions, "good faith" is defined as being "fair,
open and honest".  Negate any of these, and you arrive at some form of
bad faith.  I think more commonly "bad faith" means that the honesty is
negated, while openness is contrasted with lack of transparency and
fairness with unfairness.

You could say "Well, technically, I don't know whether they're being
honest", and that is correct, but it is also a form of casting doubt,
which I would argue constitutes an assumption of bad faith.  Of course,
"you're not sure about it", but the other party is still guilty until
proven innocent.

I'm not sure what definitions of "good" and "bad" faith you're using,
but please consider that I meant "acting in bad faith" to be the same
as "not acting in good faith".

> > > This is, in fact, the current scenario.  I'm not making any
> > > assumptions.  That is truly the state of my mind on this
> > > question, and I think it's the only rational position to take.
> > Which one is the rational position now?  Not assuming evil
> > intentions or assuming them?
> 
> I think the only rational position to take here is to not make
> assumptions.
You're always making an assumption, however.  Even if it's not one
governed by the situation at hand, you have a natural bias to trust or
distrust others in their words.  Claiming you don't is misleading
yourself and others.

Regards,
Leo

Re: Bringing substitutes from the Guix Build Coordinator to users

[Ludovic Courtès]

Hi Christopher,

Thanks for your message!  It’s great to see a summary of what’s been
cooking in the Coordinator and your vision around it.

Christopher Baines  skribis:

> More specifically, while the architecture is similar to daemon
> offloading, there are some practical advantages. Since the switch to
> Cuirass remote workers for ci.guix.gnu.org, the advantages of building
> things across multiple machines in a coordinated manor have also become
> clear. Additionally, there are things that the Guix Build Coordinator
> enables, like automated retries, with the option to target specific
> agents, which can help with avoiding issues with non-reproducible
> failures, as well as helping to avoid issues when mixing QEMU emulated
> and native builds.

These are nice examples of current QA blind spots that would be nice to
address.

[...]

> This is a topic I haven't got directly involved in, until now. I'm just
> a volunteer, in some ways the most involved I am is that I host an idle
> ARM build machine, I don't have any particular connection in the default
> approach to substitutes for users, or the hardware currently
> involved.

It would be great to have that OverDrive plugged in behind ci.guix
because we’re still short on CPU power for ARM.  (Not great we had
forgotten about this one!)

It could be reconfigured with a config similar to
,
with a different host name and IP.  We can discuss the details in a
separate thread and/or on guix-sysadmin, let me know!

> However, I think some of the stuff I've been working on could be
> helpful, as I say, I think the Guix Build Coordinator is a step
> forward in terms of building things for substitutes, and that shows in
> the substitute availability percentages.
>
> Is there still a path to bring some of these benefits to users, and if
> so, what things need doing?

My understanding is that, to build substitutes, we need more than the
Coordinator; we also need something to perform evaluations, similar to
the “top half” of Cuirass and the Data Service, right?  How would you
envision setting it up?

To me, the way forward is not necessarily substitutes; it could be QA,
as you showed that it has helpful features.  You already have access to
bayfront and it’d be great to experiment there.  Do you have ideas on
how to do make progress on that front?


Besides, I feel that the Data Service has a huge role to play with a
variety of applications, including QA, but also way beyond as you showed
in the blog post¹.  I think it’s time take advantage of it.  :-)

Specifically, as far as QA is concerned, I think we should place the
Data Service at the center of the stage.  It already does things that
Cuirass cannot and will not do, notably: linting, challenging substitute
servers to estimate reproducibility, and recording the history of all
this.  Couldn’t it gather these other QA metrics mentioned above,
possibly from a Coordinator-powered bayfront?

What I’d love to see is a set of “skins” for the Data Service:
purpose-specific interfaces to the service.  There’s already the
reproducibility one, the one for package versions, etc.  It would be
great to have a qa.guix.gnu.org entry point with a simplified interface
that would only show (say) reproducibility data, lint warnings, and so
forth.  (Then we can also think of other skins, like Guix Weekly News, a
page dedicated to browsing package version history, a security-related
page, etc.  But now I feel like a spoiled kid asking for yet more
presents.  :-))

How does that sound?

Thanks!

Ludo’.

¹ 
https://guix.gnu.org/en/blog/2020/introduction-to-the-guix-data-service-the-missing-blog-post/

Re: Criticisms of my "tone" (was Re: A "cosmetic changes" commit that removes security fixes)

[Mark H Weaver]

Hi Ludovic,

Ludovic Courtès  writes:
> I’m sorry to inform you that this is not a philosophy or linguistics
> mailing list.

*lol*  Indeed, this conversation has wandered quite far off-topic.
Thanks for stepping in.

> I invite you to continue this discussion off-list.  We have a release
> coming up that needs everyone’s focus and attention.  :-)

Sounds good to me.  Let's get back to work :)

 Regards,
   Mark

-- 
Disinformation flourishes because many people care deeply about injustice
but very few check the facts.  Ask me about .

[PATCH] maint: Do not xz-compress ISO images.

[Ludovic Courtès]

The xz-compressed image is 23% smaller than the original ISO image (with
built-in zlib compression), but the extra decompression step is
unconventional and often a hindrance for users.  See discussion at
.

* Makefile.am (release): Do not compress ISO images.
* doc/guix.texi (USB Stick and DVD Installation): Remove ".xz" suffix
from URL and file name.
(Copying to a USB Stick, Burning on a DVD): Remove introductory words,
@enumerate, and first item.
---
 Makefile.am   |  6 +++---
 doc/guix.texi | 30 +++---
 2 files changed, 6 insertions(+), 30 deletions(-)

Hi!

This takes the simple step of providing plain ISOs only (rather than
.iso + .iso.xz as some suggested).

One advantage is that, unless I’m mistaken, this can be done without
breaking string freeze.

We’ll also have to update  on the
release day.

Thoughts?

Ludo’.

diff --git a/Makefile.am b/Makefile.am
index 8d059eb033..623b1c497f 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -886,9 +886,9 @@ release: dist-with-updated-version all
echo "failed to produced Guix installation image for $$system" >&2 
;\
exit 1 ;
\
  fi ;  
\
- xz < "$$image" > 
"$(releasedir)/$(GUIX_SYSTEM_IMAGE_BASE).$$system.iso.xz.tmp" ;  \
- mv "$(releasedir)/$(GUIX_SYSTEM_IMAGE_BASE).$$system.iso.xz.tmp"  
\
-"$(releasedir)/$(GUIX_SYSTEM_IMAGE_BASE).$$system.iso.xz" ;
\
+ cp "$$image" 
"$(releasedir)/$(GUIX_SYSTEM_IMAGE_BASE).$$system.iso.tmp" ; \
+ mv "$(releasedir)/$(GUIX_SYSTEM_IMAGE_BASE).$$system.iso.tmp" 
\
+"$(releasedir)/$(GUIX_SYSTEM_IMAGE_BASE).$$system.iso" ;   
\
done
 # Generate the VM images.
for system in $(GUIX_SYSTEM_VM_SYSTEMS) ; do
\
diff --git a/doc/guix.texi b/doc/guix.texi
index 2fe7ad3a2a..3460c58cbc 100644
--- a/doc/guix.texi
+++ b/doc/guix.texi
@@ -2099,7 +2099,7 @@ about their support in GNU/Linux.
 
 An ISO-9660 installation image that can be written to a USB stick or
 burnt to a DVD can be downloaded from
-@indicateurl{@value{BASE-URL}/guix-system-install-@value{VERSION}.x86_64-linux.iso.xz},
+@indicateurl{@value{BASE-URL}/guix-system-install-@value{VERSION}.x86_64-linux.iso},
 where you can replace @code{x86_64-linux} with one of:
 
 @table @code
@@ -2115,8 +2115,8 @@ Make sure to download the associated @file{.sig} file and 
to verify the
 authenticity of the image against it, along these lines:
 
 @example
-$ wget 
@value{BASE-URL}/guix-system-install-@value{VERSION}.x86_64-linux.iso.xz.sig
-$ gpg --verify guix-system-install-@value{VERSION}.x86_64-linux.iso.xz.sig
+$ wget 
@value{BASE-URL}/guix-system-install-@value{VERSION}.x86_64-linux.iso.sig
+$ gpg --verify guix-system-install-@value{VERSION}.x86_64-linux.iso.sig
 @end example
 
 If that command fails because you do not have the required public key,
@@ -2140,17 +2140,6 @@ It is meant to be copied @emph{as is} to a large-enough 
USB stick or DVD.
 
 @unnumberedsubsec Copying to a USB Stick
 
-To copy the image to a USB stick, follow these steps:
-
-@enumerate
-@item
-Decompress the image using the @command{xz} command:
-
-@example
-xz -d guix-system-install-@value{VERSION}.x86_64-linux.iso.xz
-@end example
-
-@item
 Insert a USB stick of 1@tie{}GiB or more into your machine, and determine
 its device name.  Assuming that the USB stick is known as @file{/dev/sdX},
 copy the image with:
@@ -2161,21 +2150,9 @@ sync
 @end example
 
 Access to @file{/dev/sdX} usually requires root privileges.
-@end enumerate
 
 @unnumberedsubsec Burning on a DVD
 
-To copy the image to a DVD, follow these steps:
-
-@enumerate
-@item
-Decompress the image using the @command{xz} command:
-
-@example
-xz -d guix-system-install-@value{VERSION}.x86_64-linux.iso.xz
-@end example
-
-@item
 Insert a blank DVD into your machine, and determine
 its device name.  Assuming that the DVD drive is known as @file{/dev/srX},
 copy the image with:
@@ -2185,7 +2162,6 @@ growisofs -dvd-compat -Z 
/dev/srX=guix-system-install-@value{VERSION}.x86_64-lin
 @end example
 
 Access to @file{/dev/srX} usually requires root privileges.
-@end enumerate
 
 @unnumberedsubsec Booting
 
-- 
2.31.1

Re: Jam: which licence is this?

[Ludovic Courtès]

Hi,

Mark H Weaver  skribis:

> For most purposes, the relevant question is: which license(s) cover the
> source code, because that's where users will want to exercise the four
> freedoms of free software.  The license(s) that cover the package
> outputs are of far less interest, because that's not where users will
> exercise the four freedoms.
>
> The 'license' field can only mean one of these two things, and I think
> it's fairly clear which one it should be.  Moreover, I think that this
> is what it has always meant in Guix.  If not, that's a problem.
>
> Perhaps Ludovic would like to clarify?

I think Leo’s description reflects the initial intent (I believe this
was discussed a few times on the mailing lists in the early years).

The GNU Hello example Leo gave is a good one: we state the license that
applies to what gets installed and do not list licenses applicable to
auxiliary build scripts, say.

HTH!

Ludo’.

Re: linux-libre source tarballs

[Ludovic Courtès]

Leo Famulari  skribis:

> On Sat, May 01, 2021 at 10:45:22PM -0400, Leo Famulari wrote:
>> The immediate solution is for me to make sure the tarballs have built
>> before committing the updates. I already do this for x86_64 and I can
>> start doing it for aarch64 too.
>
> I started building the current derivations "by hand" on the build farm
> with a longer max-silent-time.

For packages we can add a ‘max-silent-time’ property, but there’s
nothing like this for origins.

I wonder if there’s a way we could address it in (gnu ci).

Thoughts?

Ludo’.

Re: Pinebook Pro no longer WIP

[Ludovic Courtès]

Vagrant Cascadian  skribis:

> Someone pointed to me various patches[0][1] and kernel module
> selections[2] related to the Pinebook Pro that lead to me feeling
> confident to merge some kernel and u-boot changes for the Pinebook Pro
> into guix/master...
>
> Which now means that you should be able to run Guix System on a Pinebook
> Pro without too much trouble, even using the bootloader form the
> keyboard and screen rather than serial console.

Woohoo, quite a milestone!  Thumbs up to you and everyone who helped!

Ludo’.

Re: Criticisms of my "tone" (was Re: A "cosmetic changes" commit that removes security fixes)

[Mark H Weaver]

Hi Leo,

Leo Prikler  writes:

> Am Sonntag, den 02.05.2021, 15:29 -0400 schrieb Mark H Weaver:
>> 
>> Leo Prikler  writes:
>> 
>> > Let us assume for the sake of argument I were to introduce a bug
>> > into Guix.  There are a number of ways this can happen, but let's
>> > focus on the important distinction here, which is me purposefully
>> > introducing that bug vs.  it happening due to oversight.
>> > 
>> > Let us imagine the following four scenarios:
>> > 1. You assume I'm acting in bad faith and I indeed am.
>> > 2. You assume I'm acting in bad faith and I am not.
>> > 3. You assume I'm acting in good faith and I am not.
>> > 4. You assume I'm acting in good faith and I am.
>> 
>> This is a false dilemma ,
>> because you've missed a very important case, namely:
>> 
>> 5. You assume *nothing*.

> I think you're nitpicking here.

I don't think so.

> clearly I either have evil intentions or I don't – there's no middle
> ground.

Yes, I agree with this.

> Likewise, there's no middle ground on assuming evil
> intentions, you either assume they exist or you don't.

That's true also, but this is a different dichotomy than the one you
presented above.  In the sentence above, the dichotomy is between:

  (1) You assume bad faith
  (2) You do not assume bad faith

In your list of scenarios above, there's a (false) dichotomy between:

  (1) You assume bad faith
  (2) You assume good faith

It's a false dichotomy because neither of these is the logical negation
of the other.  They cannot both be true, but they _can_ both be false.

In other words, I think that you have conflated "not assuming bad faith"
with "assuming good faith".  Do you see the difference?

This is not mere nitpicking.  It's a very important distinction.
It's analogous to being forced to choose between "faith in god" and
"atheism", without allowing for the possibility of "agnosticism".

Does that make sense?

>> This is, in fact, the current scenario.  I'm not making any
>> assumptions.
>> That is truly the state of my mind on this question, and I think it's
>> the only rational position to take.
> Which one is the rational position now?  Not assuming evil intentions
> or assuming them?

I think the only rational position to take here is to not make
assumptions.

 Regards,
   Mark

-- 
Disinformation flourishes because many people care deeply about injustice
but very few check the facts.  Ask me about .

Re: Guix Home upstreaming plan

[Ludovic Courtès]

Hi,

Xinglu Chen  skribis:

> On Fri, Apr 30 2021, Ludovic Courtès wrote:

[...]

>> Since this kind of tool is rather unusual (there’s no real equivalent
>> I’m aware of in other distros)
>
> Nix Home Manager[2] is very similar to Guix Home, it allows for the same
> kind of declarative configuration as Guix Home, but using Nix.  I have
> been using and hacking on Guix Home on NixOS and it’s getting closer to
> replacing Nix Home Manager for me. :)

Ah sure, I’ve heard about this one.  By “other distros” I really meant
the “traditional” distros.  :-)

>> I think the manual will have to carefully explain what problems this
>> solves and explain why someone would want to use it.  For example, I
>> think the term “home environment” should be defined upfront (I’d
>> summarize it as user configuration files + user services, from my
>> reading.)
>
> Plus user packages and state management, e.g. automatically cloning Git
> repositories the user has declared in their config.scm, or periodically
> rsync’ing some files with a remote host.

Right!

>> If people agree, I think we could aim for merging it in the next Guix
>> release, which would leave us a few months.
>
> To clarify, do you mean v1.3.0 or v1.4.0 (or whatever it’s going to be
> called)?  IIUC v1.3.0 is going to be released in a few weeks (rc1 was
> just announced), that might not be enough time for merging Guix Home as
> the API for some of the core services are still subject to change.  WDYT
> Andrew?

I meant 1.4.0 (or whatever it’ll be called).

Thanks!

Ludo’.

Re: Criticisms of my "tone" (was Re: A "cosmetic changes" commit that removes security fixes)

[Ludovic Courtès]

Leo, Mark,

Mark H Weaver  skribis:

> This is a false dilemma ,
> because you've missed a very important case, namely:
>
> 5. You assume *nothing*.

I’m sorry to inform you that this is not a philosophy or linguistics
mailing list.

I invite you to continue this discussion off-list.  We have a release
coming up that needs everyone’s focus and attention.  :-)

Thanks in advance!

Ludo’.

Re: FYI: guile-scheme bindings to GNU Mach and the Hurd

[Ludovic Courtès]

Hi Maxime & all,

Maxime Devos  skribis:

> Joshua Branson schreef op za 01-05-2021 om 11:04 [-0400]:
>> Hey guix people,
>> 
>> I just ran across a pretty recent thread in bug-hurd land.  Apparently
>> there is a VERY WIP effort to get some guile-scheme bindings for GNU
>> Mach and the Hurd.
>> 
>> Since it might be of interest to guixy people, I thought I'd share:
>> https://notabug.org/mdevos/guile-hurd
>
> I moved it to .

Nice!  I knew of the Common Lisp effort this is based on, and the idea
of reusing the .lisp code unchanged is smart.  Looks promising!

Ludo’.

Re: Criticisms of my "tone" (was Re: A "cosmetic changes" commit that removes security fixes)

[Leo Prikler]

Hi Mark,

Am Sonntag, den 02.05.2021, 15:29 -0400 schrieb Mark H Weaver:
> Hi Leo,
> 
> Leo Prikler  writes:
> 
> > Let us assume for
> > the sake of argument I were to introduce a bug into Guix.  There
> > are a
> > number of ways this can happen, but let's focus on the important
> > distinction here, which is me purposefully introducing that bug vs.
> > it
> > happening due to oversight.
> > 
> > Let us imagine the following four scenarios:
> > 1. You assume I'm acting in bad faith and I indeed am.
> > 2. You assume I'm acting in bad faith and I am not.
> > 3. You assume I'm acting in good faith and I am not.
> > 4. You assume I'm acting in good faith and I am.
> 
> This is a false dilemma 
> ;,
> because you've missed a very important case, namely:
> 
> 5. You assume *nothing*.
I think you're nitpicking here.  If "good faith vs. bad faith" is not a
boolean value, I could also be acting without one or the other, but
clearly I either have evil intentions or I don't – there's no middle
ground.  Likewise, there's no middle ground on assuming evil
intentions, you either assume they exist or you don't.  Of course, we
could get into technicalities of how evil you assume my intentions to
be, but that's not going to help us here.

> This is, in fact, the current scenario.  I'm not making any
> assumptions.
> That is truly the state of my mind on this question, and I think it's
> the only rational position to take.
Which one is the rational position now?  Not assuming evil intentions
or assuming them?

> In particular, I don't feel the need to introduce assumptions in
> order to justify my question in the opening email of this thread,
> namely whether someone who pushed a "cosmetic changes" commit that
> removes security fixes should have commit access.
> 
> That question does _not_ imply that anyone acted in bad faith.  From
> my perspective, it doesn't matter for our purposes.  (Of course, it
> would be good to know, but I'd rather not be distracted by questions
> that we have little hope of ever answering.)
IIRC I already answered that question as one of the first things in
this thread (before it got renamed), so I don't want to repeat myself
at lengths here.

> My primary concern here is to protect our users, and the integrity of
> our systems and of Guix itself.  I don't know how to do that if we
> tolerate committers who repeatedly push commits with misleading
> commit messages.
> 
> In order for meaningful oversight of Guix to be practical, it is of
> *paramount* importance that the summary lines of commits be
> reasonably accurate.  I have neither the time nor the interest in
> scrutinizing _every_ commit pushed to our repository, just in case
> the summary lines are misleading.  Therefore, I claim that we *must
> not* tolerate committers who repeatedly push commits with misleading
> commit logs.
> 
> We are lucky that this incident was discovered.  There's no guarantee
> that the next one will be.
I'm not sure what you're trying to say here, but if it's something
along the lines of "Raghav must not be trusted", I disagree.  They
themselves have stated, that they have since learned from their past
mistakes and the only reason this commit was even introduced at this
point was because one of their older commits did not receive careful
review.

> This is _not_ about being a beginner.  No technical expertise should
> have been required to avoid this incident, only some basic care
> before pushing commits.  Even the most cursory glance at the commit
> log should have immediately raised red flags, because its summary
> line clearly contradicts the next few lines of the commit log itself:
> 
> --8<---cut here---start->8---
> gnu: cairo: Make some cosmetic changes.
> 
> * gnu/packages/patches/cairo-CVE-2018-19876.patch,
> gnu/packages/patches/cairo-CVE-2020-35492.patch: Remove patches.
> * gnu/local.mk (dist_patch_DATA): Unregister them.
> * gnu/packages/gtk.scm (cairo): Make some cosmetic changes.
> [replacement]: Remove.
> (cairo/fixed): Remove.
> --8<---cut here---end--->8---
> 
> I don't know what went wrong here, but it doesn't really matter to
> me.  Whatever the reason, I don't want someone who pushes commits
> like this to have commit access.  If people want to condemn me for
> saying that, so be it.
I don't know why your rehashing this at this point, we went over this
already.  Please refer to Raghav's messages at the time, they were
helpful in clearing up the matter.

Regards,
Leo

Re: Criticisms of my "tone" (was Re: A "cosmetic changes" commit that removes security fixes)

[Mark H Weaver]

Hi Leo,

Leo Prikler  writes:

> Let us assume for
> the sake of argument I were to introduce a bug into Guix.  There are a
> number of ways this can happen, but let's focus on the important
> distinction here, which is me purposefully introducing that bug vs. it
> happening due to oversight.
>
> Let us imagine the following four scenarios:
> 1. You assume I'm acting in bad faith and I indeed am.
> 2. You assume I'm acting in bad faith and I am not.
> 3. You assume I'm acting in good faith and I am not.
> 4. You assume I'm acting in good faith and I am.

This is a false dilemma ,
because you've missed a very important case, namely:

5. You assume *nothing*.

This is, in fact, the current scenario.  I'm not making any assumptions.
That is truly the state of my mind on this question, and I think it's
the only rational position to take.

In particular, I don't feel the need to introduce assumptions in order
to justify my question in the opening email of this thread, namely
whether someone who pushed a "cosmetic changes" commit that removes
security fixes should have commit access.

That question does _not_ imply that anyone acted in bad faith.  From my
perspective, it doesn't matter for our purposes.  (Of course, it would
be good to know, but I'd rather not be distracted by questions that we
have little hope of ever answering.)

My primary concern here is to protect our users, and the integrity of
our systems and of Guix itself.  I don't know how to do that if we
tolerate committers who repeatedly push commits with misleading commit
messages.

In order for meaningful oversight of Guix to be practical, it is of
*paramount* importance that the summary lines of commits be reasonably
accurate.  I have neither the time nor the interest in scrutinizing
_every_ commit pushed to our repository, just in case the summary lines
are misleading.  Therefore, I claim that we *must not* tolerate
committers who repeatedly push commits with misleading commit logs.

We are lucky that this incident was discovered.  There's no guarantee
that the next one will be.

This is _not_ about being a beginner.  No technical expertise should
have been required to avoid this incident, only some basic care before
pushing commits.  Even the most cursory glance at the commit log should
have immediately raised red flags, because its summary line clearly
contradicts the next few lines of the commit log itself:

--8<---cut here---start->8---
gnu: cairo: Make some cosmetic changes.

* gnu/packages/patches/cairo-CVE-2018-19876.patch,
gnu/packages/patches/cairo-CVE-2020-35492.patch: Remove patches.
* gnu/local.mk (dist_patch_DATA): Unregister them.
* gnu/packages/gtk.scm (cairo): Make some cosmetic changes.
[replacement]: Remove.
(cairo/fixed): Remove.
--8<---cut here---end--->8---

I don't know what went wrong here, but it doesn't really matter to me.
Whatever the reason, I don't want someone who pushes commits like this
to have commit access.  If people want to condemn me for saying that,
so be it.

 Regards,
   Mark

-- 
Disinformation flourishes because many people care deeply about injustice
but very few check the facts.  Ask me about .

Re: GNU Guix 1.3.0rc1 available for testing!

[Maxim Cournoyer]

Hi Leo,

Leo Famulari  writes:

> On Sat, May 01, 2021 at 05:25:45PM -0400, Leo Famulari wrote:
>> Maybe we should update the manual to mention "1.3.0rc1" and the correct
>> key.
>
> I've attached a patch.
>
>> >   1. Testing the binary tarball on the distro of your choice.  You can
>> >  download .  Uncomment the
>> >  ‘GNU_URL’ variable assignment that refers to alpha.gnu.org and it
>> >  should pick up 1.3.0rc1 automatically.
>> 
>> The install.sh script also recommends installing Ludo's key, but of
>> course fails to verify the signature with it. After installing Ludo's
>> key, the installer does suggest the correct key — Maxim's.
>
> I looked at 'guix-install.sh' and see that it recommends both Ludo's and
> Maxim's keys. It's not great that it fails, recommends users to download
> Ludo's key, and then fails again.

It should fail only once (as it currently would if Ludo's key was
missing), and display two messages/two commands instead of one to get
the missing keys.  This is because we exit after the loop, based on the
exit_flag variable value we set in the loop.  Did it not behave that way
for you?

> I tried re-sorting the array so that Maxim's key is first but, no matter
> what, it still requires every key in the GPG_SIGNING_KEY array, and the
> user will have to try the script three times before it can succeed. If
> the next release is signed by someone besides Ludo or Maxim, then the
> script will require four runs, etc.

Could you help me understand what is failing?  I tested with no keys, or
with just Ludovic's key, and it was working as intended when attempting
to install the 1.3.0rc1 release (e.g., aborting + printing all the keys
missing with the accompanying suggested commands to resolve the issue,
and proceed with the installation normally thereafter)

Thank you!

Maxim

Re: please, let avoid misunderstandings

[Pjotr Prins]

Hi Simon,

Thanks for your heroic explanation. I think it also tells us something
about the grief some of the maintainers went through. This is a good
point to close the threads. All points have been made and it is
necessary not to burden the people too much who do the real work. As
in talk is cheap... We all treasure everyone who contributes to GNU
Guix and it does amaze me how many here are really mature individuals.

Even so, we would benefit from an in-person Guix day again :).

Ryan here is the only one who has made a concrete suggestion with a
double sign-off of patches for contributors. That sounds like a bit of
overhead we may not need (yet). But it may be that Guix is growing
fast and we need to add a layer of maintainers - Linux kernel style.
Or we split off the packages from core development - Nix style. Or we
lean more heavily on channels (I would favour that). Or we wait until
the next flare up. You know, shit happens - we can live with that.

The one thing I would like to avoid is that we become more hesitant of
offering commit access. The project is most agile when flat. I think
we should be easy, but be clear what is given easily can be taken away
(easily).  And may take it away quicker, also for people who do not
contribute for a long time. If it is dynamic it will be less hurtful.

Pj.

Re: branch master updated: gnu: sbcl: Update to 2.1.4.

[Pierre Neidhardt]

OK, thanks for the update!

Cheers!

-- 
Pierre Neidhardt
https://ambrevar.xyz/


signature.asc
Description: PGP signature

Re: guix-install.sh: Add support for more than one signing key.

[Tobias Geerinckx-Rice]

Maxim,

Maxim Cournoyer 写道：

The forthcoming 1.3.0 release will be signed with my personal
GnuPG key


\o/

Don't forget to also update OPENPGP-SIGNING-KEY-{ID,URL} in 
doc/guix.texi on the master and release-1.3.0 branches.


Thank you!

T G-R


signature.asc
Description: PGP signature

Re: Jam: which licence is this?

[Leo Famulari]

On Sun, May 02, 2021 at 12:53:07AM -0400, Mark H Weaver wrote:
> My understanding is that the 'license' field of a package in Guix has
> _always_ been meant to summarize the license restrictions associated
> with the package source (the output of "guix build --source"), and
> *not* merely the package outputs.

My understanding is that the license field describes the license that
the package is redistributed under, which is typically a single license,
but could be a dual (or multiple) license if that is the case.

The manual section "package Reference" says:

The license of the package; a value from (guix licenses), or a list of
such values.

It's the license of the package, overall. Not of every single file in
the source code.

> Really?  Can you give some examples of this from our core packages?

The 'hello' package is not core, but it is a typical Autotools-based
package, and the core packages will be similar.

It is, overall, GPL3 or later. However, the component source files bear
these other licenses too:

aclocal.m4: An unnamed permissive license
AUTHORS: An unnamed permissive license
configure: An unnamed permissive license
configure.ac: An unnamed permissive license
INSTALL: An unnamed permissive license
maint.mk: An unnamed permissive license
Makefile.am, Makefile.in: An unnamed permissive license
README, README-dev: An unnamed permissive license
THANKS: An unnamed permissive license

build-aux/compile: GPL2+
build-aux/config.rpath: An unnamed permissive license
build-aux/depcomp: GPL2+
build-aux/install-sh: Expat license
build-aux/mdate-sh: GPL2+
build-aux/missing: GPL2+
build-aux/test-driver: GPL2+

doc: Some files bear the GFDL

m4: Maybe unnamed permissive licenses (I'm getting tired)

po/Makefile.in.in: The "GPL" with no version mentioned. I assume GPL1.
po/POTFILES.in: An unnamed permissive license

tests/*: An unnamed permissive license

Some of those unnamed permissive licenses are the same as each other,
some are different.

It would be unhelpful if the package definition's license field said
"gpl3+ gpl2+ gpl1 non-copyleft expat gfdl". Nobody would be able to
answer the question "What is the license of the 'hello' package?"

> The 'license' field can only mean one of these two things, and I think
> it's fairly clear which one it should be.  Moreover, I think that this
> is what it has always meant in Guix.  If not, that's a problem.

My survey of the "hello" package shows that the license field in Guix is
about the overall license of the program, not an exhaustive list of the
many licenses used for various components of the source code.

I don't think it's a problem to not mention those licenses in the
package definition. When the user acquires the source code, they still
get the benefits of the freely licensed components. Nothing is being
hidden.

The suggestion that our package definitions' license field should
mention every license contain in the source code has no precedent in
Guix, at least since I joined. I don't there is a demonstrated benefit
to making that change.

How is the LaTeX-related file psfonts.map installed on Guix?

[Rovanion Luckey]

Hi,
I'm trying to define a Guix environment that enables the following LaTeX
document to be compiled:

\documentclass[a4paper,12pt]{article}
> \usepackage[utf8]{inputenc}
> \usepackage[swedish]{babel}
> \usepackage{url}
> \usepackage{color}
> \usepackage[colorlinks=true, linkcolor=blue, urlcolor=blue]{hyperref\
> }
> \usepackage[T1]{fontenc}
> \usepackage{lmodern}
> \usepackage{morefloats}
> \usepackage{sectsty}
> \usepackage{ifmtarg}
> \usepackage{pagenote}
>
> \makepagenote
> \let\footnote\pagenote
> \renewcommand*{\notedivision}{\section*{\notesname}}
> \renewcommand*{\pagenotesubhead}[2]{}
>
> \begin{document}
>
> \title{\textsc{\Huge Curriculum Vitae\\[0.5cm]}}
> \newpage
>
> \setlength{\hoffset}{0pt}
>
> \printnotes
>
> \end{document}
>

It's a reduced version of the real document I'm writing. Right now I've
packaged a bunch of things that were missing like
texlive-generic-babel-swedish, texlive-morefloats, texlive-sectsty,
texlive-ifmtarg and texlive-pagenote for an environment that is started
with the following call:

$ ~/source/guix/main/pre-inst-env guix environment --ad-hoc texlive-base
texlive-generic-babel-swedish texlive-url texlive-latex-hyperref
texlive-fonts-ec texlive-lm texlive-morefloats texlive-sectsty
texlive-pagenote

But I'm now stuck at the following error that pdflatex throws at me:

kpathsea: Running mktexpk --mfmode / --bdpi 600 --mag 1+0/600 --dpi 600
> ec-lmr12
> gsftopk: fatal: map file `psfonts.map' not found.
> mktexpk: don't know how to create bitmap font for ec-lmr12.
> mktexpk: perhaps ec-lmr12 is missing from the map file.
> kpathsea: Appending font creation commands to missfont.log.
>  )
> !pdfTeX error: pdflatex (file ec-lmr12): Font ec-lmr12 at 600 not found
>  ==> Fatal error occurred, no output PDF file produced!
>

I've looked at the Debian package and it looks to be provided by
texlive-base: https://packages.debian.org/buster/all/texlive-base/filelist.
The same folder path in Guix seems to be generated by the function
gnu/packages/tex.scm:texlive-union; but I have no idea how I would go about
having it generate the .map-file I want it to.

Does anyone happen to have any idea what to do here. I've spent a couple of
hours without getting anywhere, so any hints would be appreciated.

Re: branch master updated: gnu: sbcl: Update to 2.1.4.

[Leo Famulari]

On Sun, May 02, 2021 at 11:57:10AM +0200, Pierre Neidhardt wrote:
> Indeed, as far as I can remember we've always updated SBCL directly on
> master, because it's one of those exceptions.

Alright, I didn't know that. Let's keep the status quo in that case.
Maybe we should mention this kind of exception to the guidelines in the
manual. I want to revisit those guidelines after the upcoming release.

> What do you mean with "coordinate it in advance"?  Is there a better way
> to handle the process?

For example, we could make an sbcl-updates branch and build that in its
own Cuirass job. It makes it a little easier to schedule and manage the
computing resources used for a task. But if these packages are actually
cheap to build, then it's probably not necessary.

> Otherwise I can remove aarch64 from the list of supported systems in the
> SBCL package.

We try to avoid limiting the utility of packages just to work around
problems with the build farm (SBCL does build on real aarch64 hardware),
so it would be ideal if we could avoid this. I don't really know a good
way to deal with this particular problem.


signature.asc
Description: PGP signature

Re: Criticisms of my "tone" (was Re: A "cosmetic changes" commit that removes security fixes)

[Leo Prikler]

Am Sonntag, den 02.05.2021, 12:17 +0800 schrieb 宋文武:
> Hello Leo, I see nothing wrong for assuming bad faith when security
> fixes of packages are removed, in the end the truth matter, which I
> believe is: You thought the patches for cario is not needed now on
> core-updates, so you remove them.

> what I mean is "for assuming bad intent", or more clearly: "for
> assuming that you remove thoese security patches to introduce
> backdoors on purpose".  I don't think Mark try to prove you're lying
> from his messages, if that's what "assumed bad faith" means...

Now, lfam has already pointed out, that I'm not Léo, but I don't think
whether I am or am not matters much in this context.  Let us assume for
the sake of argument I were to introduce a bug into Guix.  There are a
number of ways this can happen, but let's focus on the important
distinction here, which is me purposefully introducing that bug vs. it
happening due to oversight.

Let us imagine the following four scenarios:
1. You assume I'm acting in bad faith and I indeed am.
2. You assume I'm acting in bad faith and I am not.
3. You assume I'm acting in good faith and I am not.
4. You assume I'm acting in good faith and I am.

In scenarios 1 and 4, your judgement is completely correct and we need
not further discuss it.  But what about 2 and 3?  
First, let's believe myself to be acting in bad faith while I am not. 
You will attack me for introducing a bug into Guix and (because you've
already determined I'm acting in bad faith) strip me from commit
rights.  This can either be the end of the story or the start of a long
rant started by me on how unfairly I was treated by Guix.  Bad optics.
Now let's say you assume I'm acting in good faith while I am not.  You
might want to (politely) ask me to come up with an explanation as to
why I introduced this bug.  I might respond or not.  Depending on my
response, you might even be fooled into believing I acted in good faith
until I conveniently introduce another bug.  At some point, you will
probably have to conclude, that I'm not.  In this scenario, I am kept
around longer than necessary and my repeated introduction of bugs
produces headaches to everyone, particularly when I circumvent the
review process.

To be honest, the way I presented 3, it looks very grim, but
realistically speaking, I don't think all of the maintainers will be
fooled for very long.  With regards to the recent issue, we have a
clear account from Raghav as to what happened as well as their
statement, that they have since learned to be less misleading in their
commit messages.  I often collaborate with Raghav or review their
patches and when doing so I can feel clear commitment from their side,
but also a sense of eagerness, that at times I feel uneasy about. 
Rather than worrying, that they might intentionally do bad, I fear they
might do bad out of haste and I'm still in the process of learning how
to best communicate that to them.  They are awfully fast at churning
out patch sets and at times I find myself outpaced, especially
recently, when Guix has not been the only project I'm working on. 
Writing long essays by email also takes precious time away from patch
review, working on my own contributions or leisure.  In short, I'm
slowly starting to feel a little too stressed.

But enough about my complaints.  Long story short, I think we ought to
assume good faith when engaging in criticism, so as to not discourage
people, who otherwise do good work.

Regards,
Leo

Re: [Outreachy] [Guix Data Service]: Identify the slow parts of process

[Christopher Baines]

Canan Talayhan  writes:

>>From this I'm guessing the temp_package_metadata table has only one
>>row. My understanding is that this table would normally have as many
>>rows as packages in the revision of Guix being processed. It might not
>>be possible to reproduce the slowness of the query without more rows.
>
> I've inserted one row just as an example. As you've already said,
> the temp_package_metadata table should have as many rows
> as package_metadata.

"as many rows as packages in the revision of Guix being processed" is
only going to be similar to the number of rows in the package_metadata
table if there's only been one or a number of similar revisions
processed, since the package_metadata table has entires covering all
processed revisions.

> After populated the temp_package_metadata with 500 rows of
> package_metadata, the query takes a long time as we expected.

Great, being able to reproduce the problem in a way that makes trying
things out easy is a good step forward.

I'd pull on this thread further, now you've got a slow query, how can
you make it faster?

> I'm using Flame Graph to visualize the slow paths on the revision part.
> At first, I choose the slow one that I already know.
> However, I can't successfully trigger the slow query following the below step:
>
> * Run the **guix-data-service-process-job** under guix-data-service/scripts
> folder as standalone providing an existing revision on my local db.
>
> Am I on the right path for adding new jobs log to my local db?
>
> In addition, I've successfully generated simple Flame Graph using Linux perf.
> It visualizes only the data that was captured while I'm browsing on the
> Guix Data Service Page. Please find the svg file attached.

If this relates to the query involving the temp_package_metadata table,
I'd focus on analyzing the slow query you're able to execute manually,
rather than processing an entire revision.

If you do however want to add more unprocessed jobs to your local
database, then you can use the
guix-data-service-process-branch-updated-mbox script to do this. It
takes one argument, an mbox file (file containing a bunch of
emails). You can download files by month from here [1], and you'll
probably want the month or next month on from the latest revision your
local database knows about.

1: https://lists.gnu.org/archive/mbox/guix-commits/


signature.asc
Description: PGP signature

Re: please, let avoid misunderstandings

[zimoun]

On Sun, 02 May 2021 at 12:37, zimoun  wrote:

> Personally, I am still staying away from Guix proper because I felt hurt
> by the fact that the whole community did nothing for two months to
> prevent such escalations.

I apology for this wording.  I do not mean that individuals had not
tried to privately reach out Léo in order to prevent such escalations.
I do mean that I have been disappointed by the public messages over the
month of March.

Re: [Outreachy] [Guix Data Service]: Identify the slow parts of process

[Canan Talayhan]

>From this I'm guessing the temp_package_metadata table has only one
>row. My understanding is that this table would normally have as many
>rows as packages in the revision of Guix being processed. It might not
>be possible to reproduce the slowness of the query without more rows.

I've inserted one row just as an example. As you've already said,
the temp_package_metadata table should have as many rows
as package_metadata. After populated the temp_package_metadata
with 500 rows of package_metadata, the query takes a long time
as we expected.

I'm using Flame Graph to visualize the slow paths on the revision part.
At first, I choose the slow one that I already know.
However, I can't successfully trigger the slow query following the below step:

* Run the **guix-data-service-process-job** under guix-data-service/scripts
folder as standalone providing an existing revision on my local db.

Am I on the right path for adding new jobs log to my local db?

In addition, I've successfully generated simple Flame Graph using Linux perf.
It visualizes only the data that was captured while I'm browsing on the
Guix Data Service Page. Please find the svg file attached.

Thanks,
Canan Talayhan

On Tue, Apr 27, 2021 at 9:26 PM Christopher Baines  wrote:
>
>
> Canan Talayhan  writes:
>
> > I am writing to give you an update on the progress that I have made.
>
> Great :)
>
> > I've created a temporary table named temp_package_metadata[1] and
> > insert a revision that already in my local database[2]. Then as you
> > said I've run the slow query with EXPLAIN ANALYZE. (screenshot is
> > attached) I may understand the slow query's working logic.
> >
> > [1]CREATE TEMPORARY TABLE temp_package_metadata (LIKE package_metadata
> > INCLUDING ALL)
> >
> > [2]INSERT INTO temp_package_metadata (home_page,
> > location_id,license_set_id,package_description_set_id,
> > package_synopsis_set_id) VALUES ('https://zlib.net/',9,9,2373,1407)
>
> From this I'm guessing the temp_package_metadata table has only one
> row. My understanding is that this table would normally have as many
> rows as packages in the revision of Guix being processed. It might not
> be possible to reproduce the slowness of the query without more rows.

Re: Hero culture among Guix maintainers

[Jelle Licht]

Hello Ryan,

tl;dr: (!= 'accountability 'blame), but accountability is essential to
any social endeavour.

Ryan Prior  writes:

> Hey Guix. There's a specific thing I'm motivated to address after the
> recent security incident with the "cosmetic" patches & all the fallout
> of that.

Some proposals and ideas have been put forward on how to prevent
situations such as the recent one from getting to the ugly point they
did. I do understand the values of the proposed ideas, yet I think they
are an orthogonal concern to what actually went on here, and that is
vagueness on the nature of accountability (and trust, to a lesser
extent).

> One way or another, part of the subtext I got from that thread is that
> Mark, an established and respected senior contributor here, believes
> making an error like the one Léo and Raghav made is beneath the level
> of somebody who's entrusted with membership in the committer
> group. That reminds me of a common attitude I've seen in operations at
> a lot of companies, that ops are heroes who take their duties very
> seriously and feel an extreme responsibility to follow procedures and
> avoid using their power destructively.

If you can indulge me a bit and allow me to make a snide remark: I
sincerely hope we hold folks to the standard of not using their power
destructively, in the general case.

What do you think trust is, essentially? To me, it means exactly what
you describe as being a hero; being expected to be accountable for your
actions and commitments. 

That is not to say that anyone has the expectation you won't be making
mistakes; you will, inevitably. But it is your own responsibility to
either decline the accountability, or to live up to it. Is that scary?
Yes, but so is driving a car the first time, or caring for a newborn, or
operating heavy machinery etc etc.

> That attitude is a liability at any organization, because we're all
> fallible and guaranteed to fault on occasions, but I think especially
> so in a high-trust inclusive atmosphere like what Guix has been
> building. I noticed that Léo joined, got really engaged with improving
> the software, and was quickly accepted as a committer, which I thought
> was really cool. I haven't applied for commit access myself yet, both
> because I have anxiety about acting out of line and thus want more
> time to learn the norms of the community, and also because I feel
> reasonably at ease with the tools and processes for non-committers to
> contribute. But I saw that and thought it was a great sign that a
> committed contributor like Léo was able to gain the group's trust so
> quickly. It's a strength and would be a shame to lose that.

What you describe as hero culture comes across as an uncharitable
interpretation of accountability in general, IMHO. Things only get iffy
if accountability is seen as a zero sum game; 'someone else's mistakes
are my Golden Ticket to a promotion'. Guix does not seem to be such a
project to me.

> But if everyone who's entrusted with commit access is also expected to
> live up to the heroic responsibilities of the classic ops/sysadmin
> role, then I think we're setting people up for failure. Ops at the
> best companies are guaranteed to make mistakes, and they have the
> cultural training to be Very Sorry about it and Learn Their Lesson and
> so on. But how do we expect every committer to a volunteer open source
> project to behave that way? Blaming a volunteer for a bad commit,
> calling them out on the mat to fess up and say they're sorry, is big
> "blame the intern" energy and it's ultimately not conducive to our
> security as an organization. I think that's still true even if you
> assume good faith and use only factual statements throughout.

Because of language barriers this might not be a clear distinction (at
least in my mother tongue), but accountability in a functional
organisation is not at all about blame. It is about being criticial,
reflective and open minded on your role and how one can contribute to
reach a desired outcome. Very often, that involves stating "I forked up"
in case you made an honest mistake. From my point of view, folks are
given the benefit of the doubt in most cases in the Guix community.

> It felt to me like Mark was expecting (demanding?) a certain cultural
> performance from Léo: acknowledgement of what was done wrong,
> contrition for his part in it, and a promise not to repeat it. This is
> typical in ops organizations, but it's not necessarily humane, and I
> don't think it's a reasonable expectation in a volunteer project. A
> reexamination of the hero culture among the Guix developers might be
> in order to avoid similar confrontations in the future.

What you refer to as a cultural performance, might be just that, but
it does serve a set of important functions;

1 (short) confirmation that there was no act of bad faith (e.g. "Oops,
  my mistake")

2 clarify continued dedication to the goals of the organisation/group

3 actionable steps to 

please, let avoid misunderstandings

[zimoun]

Dear Léo,
Dear Guix,

My name pops up here so let me expose *my* feelings.

I am truly sad by the situation.  From my eyes, such escalation and such
wordings means we––as a community––collectively failed somewhere.
Instead of speaking, we have to individually introspect and ask what
each of us should have done differently.  A friendly environment where
we peacefully discuss is spanned by a proactive whole community on a
daily basis.

Let me say again to you Léo that I appreciate your valuable work,
especially about security.  And I am convinced that your enthusiasm is a
really good thing for Guix.  It makes me sad that you leave.

Attentive observer probably has noticed that I stopped my interactions
with Guix proper ~one month ago.  Indeed, because I have been strongly
irritated.  Léo, your behaviour over all the month of March is the only
reason that I went away; the lack of actions or messages by the whole
community simply reinforced my decision to take away.

The decision to suspend your, Léo, commit access is not mine and if five
long-standing people, who are responsible, among many others, to keep
the friendly environment we all praise, if they take such decision, then
at best your only answer should be: apology then introspect to look for
what was wrong.  For transparency, my contribution here had been to show
using our interactions on March what I identified as a pattern: the one
we are seeing here again.

Léo, you said: «They also wanted to go», it is false.  For instance I am
still roaming on #guix-hpc, I provided feedback about the POWER9 blog
post, I am going to partly write the blog entry for GuixHPC about v1.3,
I am in touch with Timothy about the recent addition of disarchive,
etc. and it makes me torn to not have taken my part in helping for v1.3
since I have pleaded for releasing more often.

For what it is worth, I silently stopped because I wanted to avoid a
fight that Guix does not deserve.  I am still in the same mindset and my
intent here is to avoid unpleasant dispute for all and restore smooth
discussions, and even move on.

Again for transparency, here the list, for what it is worth, to whom I
privately said I take away for some time:

  guix-maintainers Wed, 31 Mar 2021 13:21:52 +0200
  Ricardo  Fri, 02 Apr 2021 14:11:44 +0200
  Leo (F)  Fri, 02 Apr 2021 17:11:30 +0200
  Mark Fri, 02 Apr 2021 20:05:16 +0200
  Chris (M)Tue, 06 Apr 2021 18:10:45 +0200
  Julien   Fri, 16 Apr 2021 14:21:46 +0200
  Andreas  Tue, 20 Apr 2021 14:04:03 +0200
  Raghav   Sat, 24 Apr 2021 12:10:51 +0200
  PjotrMon, 26 Apr 2021 23:48:13 +0200
  Arun and Pierre  Thu, 29 Apr 2021 18:29:49 +0200
  Leo (P)  Thu, 29 Apr 2021 18:55:16 +0200

I still think that informing only people with who I had ongoing work was
the best move.  Being publicly silent about my decision to take away
avoided to add again fuel to the fire and let the door open for peaceful
collaborations beyond my exasperation against Léo.  Then, I should
always reconsider my position and be back months later once or if I
would have been realigned.

I am again hurt that you, Léo, use the same «harassed» word when it
carries a strong meaning.  Why do you not take in count my own feelings
when I explicitly expressed to you that such word hurts me?  Without
saying that the CoC had publicly been pointed to you.  You are
generating *exactly* what you are advocating against: «I do not feel
welcome to acknowledge criticism when it is not written in a friendly
manner (because it generates confrontation), and also I can disagree
with criticism».  Please keep your house in order.

Just to put numbers about «felt harassed» by me.  For only the month of
March, I sent ~300 emails/patch to various Guix lists.  Moreover, part
of (old) bugs squashing month, I closed more than 30 old bugs on
December, and I do not know how many since I have started my attempt to
reduce as much as I can the Bug Tracker load.  For what it is worth,
from my experience, it is much easier to fix as early as possible
instead of dig later and unknot.

Considering this frame, my complaints had never been about the
contributions (patch) but always about pushed mistakes avoidable by
review.  Léo, it appears to me that the net of our argument is expressed
by you here [1] and I cannot say how strongly I oppose this opinion from
a committer.  Do not take me wrong, I think I have a track record to
underline how I try to welcome people and provide constructive feedback
where the aim is to try as much as possible to reach high quality.

1: 

Here, I will not provide more references because now we moved on and I
consider all is behind.  Interested reader can still open the archives.

However, if someone witnessed from me something wrong, please point me
such, privately or even publicly.  I take seriously what a welcoming
place means.  I have already 

Re: Criticisms of my "tone" (was Re: A "cosmetic changes" commit that removes security fixes)

[Leo Prikler]

Am Samstag, den 01.05.2021, 23:13 -0400 schrieb Mark H Weaver:
> Hi Leo,
> 
> I took the liberty of refilling the quotations in your email to make
> them more readable.
Please do.
> 
> Leo Prikler  writes:
> 
> > Am Samstag, den 01.05.2021, 18:12 -0400 schrieb Mark H Weaver:
> > > Can you please point out which of my words led you to conclude
> > > that I was assuming bad faith?
> > 
> > I am basing this on the following exchange:
> > 
> > Am Montag, den 26.04.2021, 19:17 +0200 schrieb Ludovic Courtès:
> > > > I feel an obligation to protect our users, and among other
> > > > things
> > > > that means calling attention to Guix committers that are doing
> > > > things like pushing commits with misleading commit logs (which
> > > > evade proper review) and pushing "cosmetic changes" that remove
> > > > security fixes.
> > > 
> > > That you called attention on these issues is a great service to
> > > all of
> > > us, Mark.  But I have to agree with Ricardo: the harsh accusatory
> > > tone
> > > towards Raghav and Léo was not warranted; please assume good
> > > faith.
> > > 
> > To re-iterate, I believe you were (and are) right to call out
> > commits
> > for their misleading messages, but the unique circumstances of this
> > thread led people to think you were assuming ill intent or
> > something
> > along those lines.
> 
> I asked you to point out which of *my* words led you to conclude that
> I was assuming bad faith, and it seems that you haven't been able to
> do that, nor has anyone else.
> 
> Do you see the problem here?
I am not arguing, that you were assuming bad faith, I'm making the much
weaker argument, that people were led to believe you were.  For me, the
root cause of understanding it this was were Léo's defensive attitudes
coupled with Ludo's statement.  I personally don't think you were
assuming bad faith, especially after your clarification, but I can see
how people might construct that view.  Refer to my response to Giovanni
to see how cherry-picking your messages might result in that.

When asking more generally, however, I'm afraid I can't give you a
definitive answer on this one.  Only Léo can tell why they assumed bad
faith on your part, but looking at the situation, they are emotionally
not able to do so or at the very least not willing.  The best advice I
can give you is to listen to them when they do respond, but also listen
to others when they point out concrete issues with your wording.  For
instance, someone made the case that "Behold" sounded rather sarcastic,
and while I've personally watched enough anime to consider it a
completely normal word, they might have a point.

> > That being said, I think it is fair to argue, that some people read
> > your posts as assuming bad faith from Léo and some did the
> > reverse.  I can't put hard numbers to that, but given the
> > number of participants an existence "proof" ought to suffice.
> 
> It's true that some people have gotten the mistaken impression that I
> assumed bad faith.  The problem is that it's flat wrong.  There's
> *nothing* to back it up, and in fact it's simply false.
> 
> It's unjust to blame me for other people's bogus, evidence-free
> claims about what they *imagine* I assumed.
I don't think I can agree with that.  I think it's good practice to
preempt misunderstandings and to clarify your intent when they happen. 
>From what I recall, you did do that, but in that clarification lied
other problems.

For instance:
"It seems to me that the facts speak for themselves, and those
facts naturally cast Raghav and Léo in a bad light."
This phrase only serves to further cast Raghav and Léo in a bad light
and should thus be avoided.  A better way of phrasing this paragraph
(assuming you were focused on the mistake, not who made it):
"With very few exceptions, almost every sentence that I wrote was
purely factual.  I was not aiming to cast Raghav or Léo in a bad light,
commits like these are dangerous regardless of who authors or signs
them.  It is important for us all to learn from this mistake and to not
repeat it."
The above, though not perfect (and I'd be happy for someone to point
out flaws in them), would have taken some emotional weight off of
Raghav and Léo and in my opinion made it easier to respond to the facts
alone, the fact being that a poorly reviewed commit made it onto an
important branch.

> > > For what it's worth, I have *never* assumed bad faith, and I
> > > don't
> > > think I said anything to imply it either.
> > > 
> > > > (or at the very least incompetence, which, if you are the party
> > > > being accused, does not sound too nice either).
> > > 
> > > I pointed out facts.  I did not engage in speculation beyond the
> > > facts.
> > Well, you did fumble on those facts a little, because the true
> > history
> > of the misleading commits was only discovered later.
> 
> I don't think I fumbled on the facts at all.  It's true that I didn't
> yet have _all_ of the relevant facts, but as far as I know, every
> 

Re: branch master updated: gnu: sbcl: Update to 2.1.4.

[Pierre Neidhardt]

Hi Leo,

Indeed, as far as I can remember we've always updated SBCL directly on
master, because it's one of those exceptions.

> `guix refresh -l sbcl` shows "Building the following 221 packages would
> ensure 988 dependent packages are rebuilt [...]"

Note that most of these packages are "cl-*" packages, which effectively
just copy the source code of SBCL packages.  They don't compile anything.

> Remember, the rebuild limit for the master branch is 300 rebuilds,
> according to item 8 of the manual section Submitting Patches:
>
> https://guix.gnu.org/manual/en/html_node/Submitting-Patches.html
>
> Sometimes it's fine to go over the limit a little bit, especially for 
> packages that are cheap to build, but SBCL packages are pretty
> expensive.

In my experience it is indeed one of theses cases where it's fine to go
over the limit, because beside the check phase of very few packages
(sbcl-lparallel and sbcl-ironclad come to mind), most SBCL packages
build in an instant.

The whole set of Lisp packages builds in a few minutes on my machine.

What do you think?  Do you think it would still be wiser to update on
staging instead?

What do you mean with "coordinate it in advance"?  Is there a better way
to handle the process?

> The aarch64 builders, which are mostly emulated on x86_64 machines,
> cannot build SBCL [0], and we need to cancel those derivations
> manually, or they'll spend weeks repeatedly failing to build it. Maybe
> we should just disable SBCL on aarch64 until the build farm can build
> it reliably?

Sure thing, but I'm not an aarch64 user so maybe someone else would like
to comment about this.
Thoughts, anyone?

Otherwise I can remove aarch64 from the list of supported systems in the
SBCL package.

Cheers!

-- 
Pierre Neidhardt
https://ambrevar.xyz/


signature.asc
Description: PGP signature

Re: Outreachy: Timeline tasks

[Christopher Baines]

Luciana Lima Brito  writes:

> On Sat, 01 May 2021 20:07:56 +0100
> Christopher Baines  wrote:
>
>> Luciana Lima Brito  writes:
>>
>> > For that I propose to build 2 charts, one of the
>> > macro view, what we call "overview first", showing the
>> > sections(processes) and their whole time taken. This way we could
>> > just see what we were aiming for, which is to identify slowness.
>> > The second chart would be what we call "details on demand", in
>> > which we could have the subsections(actions) being shown. To differ
>> > to which section(process) they are bound, we could use two
>> > meaningless alternating colours (just to group the subsections of a
>> > section), and they would follow the same order as the first chart.
>> >
>> > The use of alternating colours could be applied to both charts in
>> > order to make clear the equivalence. Both charts should appear at
>> > the same time, one above the other, to ease comparison.
>>
>> That sounds better, although I think a timeline, similar to what the
>> systemd-analyze example uses [1] might be a more natural
>> representation of the data, colour could then be used to represent
>> relatively how long each part takes.
>>
>> 1: https://lizards.opensuse.org/wp-content/uploads/2012/07/plot001.gif
>
> Here I have two observations to debate:
> 1 - Is the starting and ending time of each process an important
> information to determine its slowness? If this information is not
> necessary, maybe we should avoid the timeline, in order to make the
> chart cleaner. A timeline could impair the comparisons of bars, so I
> would recommend simple bar charts.

I think what things are happening when is relevant, but that's more
about understanding the hierarchy, rather than specific start and end
times.

> 2 - About the colours to represent how long each part takes, I don't
> know if I get it right. Do you mean to have one colour for slow parts
> and other colour to normal parts?

Basically, although using more colours (from a gradient, like white to
red) would probably convey more information than just two colours.


signature.asc
Description: PGP signature

Re: Neovim plugin/addon packaging

[Efraim Flashner]

On Sat, May 01, 2021 at 04:25:18PM -0400, Jack Hill wrote:
> Thanks for your reply.
> 
> On Fri, 30 Apr 2021, Efraim Flashner wrote:
> 
> > On Fri, Apr 30, 2021 at 01:03:23AM -0400, Jack Hill wrote:
> > > Greetings Guix,
> > > 
> > > I'd like to improve the experience of installing Neovim plugins/add-ons 
> > > with
> > > Guix. I've submitted #48112 [0] which adds an XDG_DATA_DIRS search path so
> > > nvim (the Neovim executable name) will be able to find plugins installed 
> > > by
> > > guix at …/share/nvim/site.
> > 
> > I guess my first question is does it work? I think I first tried
> > something similar for vim with 'share/vim/vimfiles' but it didn't
> > actually work for vim.
> 
> Yes, it does work! I tested it with neovim-syntastic and a local
> neovim-fugitive package both with a guix environment and manually
> manipulated environment variables.
> 
> A difference between Neovim and Vim is that Neovim supports XDG_DATA_DIRS
> (and XDG_CONFIG_DIRS) as real search paths while the environment variables
> for Vim are single directories (compare `:help runtimepath` in the two
> editors).
> 
> > > Currently, we only have one such package, neovim-syntastic. I'd like to 
> > > add
> > > more. Many plugins are compatible with both vim and nvim. However, they
> > > search for plugins at different paths. Therefore, the vim-syntastic and
> > > neovim-syntastic packages, which use the copy-build-system, differ only in
> > > the destination directories of the install-plan (and changing "Vim" to
> > > "Neovim" in the description).
> > > 
> > > My initial inclination is to remove the duplication of maintaining two
> > > install-plans (and other arguments) by creating a procedure that would 
> > > take
> > > as input a Vim package that uses copy-build-system and output a Neovim
> > > package with the install-plan re-written.
> > > 
> > > Perhaps that solution would be overwrought. How would you recommend 
> > > handling
> > > this situation?
> > 
> > My first idea would be to have the one package install the files into
> > both directories and combine them, but I feel like it falls apart when
> > it comes to searching for vim/neovim plugins and naming. One package
> > with two names? Call it vim-neovim-syntastic?
> > 
> > If vim/neovim move more apart and actually need separate plugins in the
> > future then I guess it would make more sense to have two actual packages
> > that can be installed by name (vim-foo and neovim-foo).
> 
> A combined package is an interesting suggestion. However, I share the
> concern about searching for packages. Having packages that are compatible
> with both editors use one naming scheme and ones that are compatible with
> only one use a different naming scheme seems like a implementation detail
> that would be better not to expose to me.
> 
> I drew inspiration for creating the Neovim package variants with a procedure
> from the package-for-python2 and sbcl-package->ecl-package. Of course those
> procedures have build system support and aren't depending on a common usage
> pattern of copy-build-system.
> 
> Is it time a a vim-build-system? Perhaps not, but I'm still not sure what
> the right way forward is.

ng0/nikita thought about it a few years ago but I think the
copy-build-system works well enough. I know for vim we need a vim
profile hook to create the documentation, does neovim need something
like that too?


-- 
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: rust-tempfile-3 update to 3.2.0 breaks sequoia build

[Hartmut Goebel]

Hi Nicolas,

I was able to fix sequoia by updating to 1.1 and applying some more
changes. Please review  so we
can get it into upcoming guix 1.3. Thanks in advance

-- 
Regards
Hartmut Goebel

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

Re: Criticisms of my "tone" (was Re: A "cosmetic changes" commit that removes security fixes)

[宋文武]

Leo Famulari  writes:

> [...]
> To clarify, Leo Prikler is not the same person that was involved in
> removing the Cairo bug fixes. That was a different person, also named
> Leo.
>
> Not me, either :)

Um, my bad, thank you!

Re: FYI: guile-scheme bindings to GNU Mach and the Hurd

[Mark H Weaver]

Hi Maxime,

Maxime Devos  writes:

> Joshua Branson schreef op za 01-05-2021 om 11:04 [-0400]:
>> Hey guix people,
>> 
>> I just ran across a pretty recent thread in bug-hurd land.  Apparently
>> there is a VERY WIP effort to get some guile-scheme bindings for GNU
>> Mach and the Hurd.
>> 
>> Since it might be of interest to guixy people, I thought I'd share:
>> https://notabug.org/mdevos/guile-hurd
>
> I moved it to .

This is very exciting work.  I've often thought that it would be nice to
have such bindings.  Among other things, it potentially opens up many
interesting possibilities for Guix running on the Hurd.  I have no time
at the moment to elaborate on this, but perhaps in a future message.
For now, I will simply offer my thanks and kudos :)

 Regards,
   Mark

-- 
Disinformation flourishes because many people care deeply about injustice
but very few check the facts.  Ask me about .

Re: What processor features does Guix support on i686?

[Mark H Weaver]

Hi Leo,

Thanks for asking about this, and for ably taking care of our
Linux-libre packages.  I'm grateful for your work on this.

Leo Famulari  writes:

> I noticed that Linux 5.12 has a new config option regarding "Processor
> family". The default choice, Pentium-Pro (M686), is highlighted in this
> quote:
>
> --
> Processor family
>   1. 486SX (M486SX) (NEW)
>   2. 486DX (M486) (NEW)
>   3. 586/K5/5x86/6x86/6x86MX (M586) (NEW)
>   4. Pentium-Classic (M586TSC) (NEW)
>   5. Pentium-MMX (M586MMX) (NEW)
>> 6. Pentium-Pro (M686) (NEW)
>   7. Pentium-II/Celeron(pre-Coppermine) (MPENTIUMII) (NEW)
>   8. Pentium-III/Celeron(Coppermine)/Pentium-III Xeon (MPENTIUMIII) (NEW)
>   9. Pentium M (MPENTIUMM) (NEW)
>   10. Pentium-4/Celeron(P4-based)/Pentium-4 M/older Xeon (MPENTIUM4) (NEW)
>   11. K6/K6-II/K6-III (MK6) (NEW)
>   12. Athlon/Duron/K7 (MK7) (NEW)
>   13. Opteron/Athlon64/Hammer/K8 (MK8)
>   14. Crusoe (MCRUSOE) (NEW)
>   15. Efficeon (MEFFICEON) (NEW)
>   16. Winchip-C6 (MWINCHIPC6) (NEW)
>   17. Winchip-2/Winchip-2A/Winchip-3 (MWINCHIP3D) (NEW)
>   18. AMD Elan (MELAN) (NEW)
>   19. GeodeGX1 (MGEODEGX1) (NEW)
>   20. Geode GX/LX (MGEODE_LX) (NEW)
>   21. CyrixIII/VIA-C3 (MCYRIXIII) (NEW)
>   22. VIA C3-2 (Nehemiah) (MVIAC3_2) (NEW)
>   23. VIA C7 (MVIAC7) (NEW)
>   24. Core 2/newer Xeon (MCORE2)
>   25. Intel Atom (MATOM)
> --
>
> info: https://cateee.net/lkddb/web-lkddb/M686.html
>
> I know that, in the past, we have been careful to not require certain
> processor features on i686, such as SSE [0].
>
> I would appreciate some guidance, both about this kernel configuration
> option, and what we have historically considered to be the "minimum
> requirements" for i686 hardware. I will put that information the manual
> so that it doesn't get lost.
[...]
> [0] https://lists.gnu.org/archive/html/guix-devel/2016-07/msg01534.html

It's been a long while since I looked at this, and of course we may wish
to revisit the issue, but for now, I think that the right choice above
is the default one, namely: "6. Pentium-Pro (M686) (NEW)"

   Thanks again,
   Mark

-- 
Disinformation flourishes because many people care deeply about injustice
but very few check the facts.  Ask me about .