Hero culture among Guix maintainers

[Ryan Prior]

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.

In one of the comments that lead off that thread, Mark asked "does anyone else 
find it worrisome that Raghav has commit access?" I speculate this comment may 
have predisposed some people to read subsequent comments from Mark as harsh or 
suspicious.

I distinctly remember reading that message and thinking "oh Mark is not 
amused." I'd write a message like that if I'd already tried privately to 
resolve a person's practices and they'd been resistant, causing me to give up 
on them and leaving me feeling little choice but assuming bad faith. I don't 
know what history the participants in that incident had with one another, I 
don't follow the list or know everybody well enough to have any knowledge or 
good guess.

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.

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.

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.

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 does it look like to step back from hero culture? One tool I've used 
working for paranoid security organizations is to require at least two 
signatures/sign-offs on any merge to a "protected" branch (like master or 
core-updates,) one of whom has to be part of a "security ops" subgroup who take 
on responsibility of this extra review. This pratice works on the simple 
acknowledgement that any given committer is fallible and two heads are better 
than one. It's impossible to know for sure, but I imagine this practice would 
have caught the mistake in Léo's commit to core-updates, and might have avoided 
a lot of anxiety. Some of Christopher Baines recent work on visualizing the 
impact of commits could also help aid this review task.

I'd also be interested to see a mechanism for marking commits in the 
"protected" branches as vulnerable, such that "pull" and "time-machine" can 
give a warning (or refuse to use those commits.) This might make occasional bad 
commits less catastrophic and thus reduce anxiety, allowing us to maintain a 
safer git tree without having to rewrite history or maintain heroically high 
standards of judgment about every commit.

Cheers, and an honest thank you for everybody's thoughtful messages this past 
week!
Ryan

Re: Jam: which licence is this?

[Mark H Weaver]

Hi Jack,

Jack Hill  writes:

> On Sun, 25 Apr 2021, Jack Hill wrote:
>
>> I have asked the FSF licensing lab about this in RT #1718940

Thanks very much for doing this, Jack.

> I've also asked OSI: 
> https://lists.opensource.org/pipermail/license-review_lists.opensource.org/2021-April/005139.html

Since the Guix project has committed to follow the GNU FSDG, the
relevant question here is whether the license is a "free software"
license, and that's a question for the FSF, not the OSI.

The OSI is only qualified to answer a different question: whether a
license is an "open source" license.  That question is not relevant for
our purposes.

Anyway, thanks again for your diligence here.

 Regards,
   Mark

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

What processor features does Guix support on i686?

[Leo Famulari]

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.

Leo

[0] https://lists.gnu.org/archive/html/guix-devel/2016-07/msg01534.html

Re: Jam: which licence is this?

[Mark H Weaver]

Hi Leo,

I took the liberty of adding a bit more context to your quotation of me
below, since I've added Ludovic to the CC list.

Leo Famulari  writes:

> On Sun, Apr 25, 2021 at 04:37:42PM -0400, Mark H Weaver wrote:
>> It's true that Guix has a
>> longstanding practice of omitting more lax licenses when there's also a
>> more restrictive license covering the same package.  I should have
>> mentioned that.
>>
>> However, I think that longstanding practice is orthogonal to the
>> question of whether licenses covering build system components can be
>> omitted from the 'license' field.
> [...]
>> Specifically, I'm objecting to the idea that the 'license' field need
>> only describe the files present in the build outputs.  For example, if a
>> hypothetical package is licensed under Expat but uses a build system
>> covered by the the Q Public License (QPL), I don't think we can omit
>> mention of the QPL just because those components are only used during
>> the build.
>> 
>> Does that make sense?
>
> I think I understand what you are suggesting.
>
> However, there is no precedent in Guix for mentioning the licenses of
> build system components in package definitions.

I think you're mistaken, or at least this would be news to me.

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.

> I'd guess that almost every single package in Guix would need several
> new licenses added to its field,

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

> and that field would become useless for conveying the license of the
> program itself.

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?

  Thanks,
Mark

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

Re: linux-libre source tarballs

[Leo Famulari]

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.

I'll check in a day or so if it succeeded and how long it took. We can
adjust the packages based on that to avoid "silent time" timeouts even
when I don't pre-build these tarballs.

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

[Leo Famulari]

On Sun, May 02, 2021 at 12:17:59PM +0800, 宋文武 wrote:
> 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.
> 
> 
> > [...]
> > Well, you did fumble on those facts a little, because the true history
> > of the misleading commits was only discovered later.  So did I in the
> > same thread.  Either way, "just pointing out facts" is not an accurate
> > assessment in my opinion; facts are nothing without interpretation,
> > which see.
> 
> Yes, you have to take actions based on interpretation to get more clues
> from existed facts to reach the truth.
> 
> > [...]
> > Let it be said, that I don't condemn you for starting this thread.  Not
> > only did it highlight an issue, that would otherwise have gone
> > unnoticed, I think most of the participants are now more acutely aware
> > of what might go wrong if they evade review.  It is sad, that things
> > turned out the way they did, but despite what others might claim you
> > don't bear sole responsibility for that.
> 
> Sure, I think we just lack some trust.  With the trust, you'll know that
> Mark only want to confirm the truth with you and avoid this kind of
> issues in the future.

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

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

[宋文武]

宋文武  writes:

> Leo Prikler  writes:
>
>> Hi Mark,
>>
>> Am Samstag, den 01.05.2021, 18:12 -0400 schrieb Mark H Weaver:
>>> Hi Leo,
>>> 
>>> Leo Prikler  writes:
>>> 
>>> > Am Samstag, den 01.05.2021, 19:02 +0200 schrieb Giovanni Biscuolo:
>>> > > I also spent some time re-reading messages that Mark sent in this
>>> > > thread and, like him, I really don't understand what Mark did
>>> > > wrong.
>>> > > 
>>> > > For sure Mark /insisted/ that Raghav and Léo did something wrong
>>> > > with
>>> > > some commits, we can say Mark did it being /direct/ and
>>> > > /accusatory/
>>> > > but we cannot really say Mark assumed bad faith from them.
>>> > He did wrong insofar as his accusatory message read as though he
>>> > was
>>> > assuming bad faith
>
> 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.

Sorry, I'm not a native English speaker, 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...

Re: GNU Guix 1.3.0rc1 available for testing!

[Leo Famulari]

On Sun, May 02, 2021 at 12:05:42AM -0400, Leo Famulari wrote:
> I've attached a patch.

I sent this before seeing your patch. Feel free to disregard it.

Re: GNU Guix 1.3.0rc1 available for testing!

[Leo Famulari]

On Sat, May 01, 2021 at 10:52:18PM -0400, Maxim Cournoyer wrote:
> > https://guix.gnu.org/manual/en/
> > https://guix.gnu.org/manual/devel/en/
> 
> Thank you for pointing that issue; I caught the problem with
> guix-install.sh before posting, but overlooked that one.  As you
> pointed, that won't be reflected on our website, but I agree that having
> the new key covered in the devel manual (master branch) is already an
> improvement.  The attached patch augments the manual to cover for the
> new key.  Let me know if it looks good to you.  If it does, I will push
> it to the master branch (IIUC we can't push this change to the
> version-1.3.0 branch as that would break the string freeze there).

The "devel" manual on the website reflects the master branch. So, there
will be a web-based location where users can find these instructions
documented immediately.

The non-"devel" website manual is tied to the release tag. So, we have
no choice but to make these changes on the version-1.3.0 branch, right?
Or else the "1.3.0" manual will mention the wrong signing key?

Your patch looks good except that the instructions about 'mykeyring.kbx'
are a no-op: The created keyring contains no keys afterwards. This is
with GnuPG 2.2.27 from current Guix. We should just remove these
instructions since "--recv-keys" almost never works these days, since
the keyserver network collapsed. For example:

--
$ gpg --no-default-keyring --keyring mykeyring.kbx --recv-keys 
27D586A4F8900854329FF09F1260E46482E63562 
gpg: keybox '/home/leo/.gnupg/mykeyring.kbx' created
gpg: WARNING: server 'dirmngr' is older than us (2.2.12 < 2.2.27)
gpg: Note: Outdated servers may lack important security fixes.
gpg: Note: Use the command "gpgconf --kill all" to restart them.
gpg: key 1260E46482E63562: no user ID
gpg: Total number processed: 1
$ gpg --no-default-keyring --keyring mykeyring.kbx --recv-keys 
3CE464558A84FDC69DB40CFB090B11993D9AEBB5  
gpg: WARNING: server 'dirmngr' is older than us (2.2.12 < 2.2.27)   
 
gpg: Note: Outdated servers may lack important security fixes.
gpg: Note: Use the command "gpgconf --kill all" to restart them.
gpg: key 090B11993D9AEBB5: no user ID
gpg: Total number processed: 1
$ cat ~/.gnupg/mykeyring.kbx 
 KBXf`)y`)y%
$ wc -c ~/.gnupg/mykeyring.kbx
32 /home/leo/.gnupg/mykeyring.kbx
--

As you can see, it does not contain two PGP keys.

> Are you sure you downloaded it from https://guix.gnu.org/install.sh
> (which just redirects to the current copy on the master branch) ?

Yes.

> Since commit e64af2060e8cfa48e74b887281acb3fd4c7e7781 (which was made
> just before writing the original message), it checks for both keys.

It checks for them one at a time, failing after each missing key. I
described it here:

https://lists.gnu.org/archive/html/guix-devel/2021-05/msg00039.html

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

[宋文武]

Leo Prikler  writes:

> Hi Mark,
>
> Am Samstag, den 01.05.2021, 18:12 -0400 schrieb Mark H Weaver:
>> Hi Leo,
>> 
>> Leo Prikler  writes:
>> 
>> > Am Samstag, den 01.05.2021, 19:02 +0200 schrieb Giovanni Biscuolo:
>> > > I also spent some time re-reading messages that Mark sent in this
>> > > thread and, like him, I really don't understand what Mark did
>> > > wrong.
>> > > 
>> > > For sure Mark /insisted/ that Raghav and Léo did something wrong
>> > > with
>> > > some commits, we can say Mark did it being /direct/ and
>> > > /accusatory/
>> > > but we cannot really say Mark assumed bad faith from them.
>> > He did wrong insofar as his accusatory message read as though he
>> > was
>> > assuming bad faith

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.


> [...]
> Well, you did fumble on those facts a little, because the true history
> of the misleading commits was only discovered later.  So did I in the
> same thread.  Either way, "just pointing out facts" is not an accurate
> assessment in my opinion; facts are nothing without interpretation,
> which see.

Yes, you have to take actions based on interpretation to get more clues
from existed facts to reach the truth.

> [...]
> Let it be said, that I don't condemn you for starting this thread.  Not
> only did it highlight an issue, that would otherwise have gone
> unnoticed, I think most of the participants are now more acutely aware
> of what might go wrong if they evade review.  It is sad, that things
> turned out the way they did, but despite what others might claim you
> don't bear sole responsibility for that.

Sure, I think we just lack some trust.  With the trust, you'll know that
Mark only want to confirm the truth with you and avoid this kind of
issues in the future.

Re: GNU Guix 1.3.0rc1 available for testing!

[Leo Famulari]

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.

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.

It's annoying but hard to work around because the script is distributed
via that unversioned URL show above.

Ideas?
>From 205c786b985bd7cb2754aadf3adf91e1401b9d1b Mon Sep 17 00:00:00 2001
From: Leo Famulari 
Date: Sat, 1 May 2021 23:54:03 -0400
Subject: [PATCH] doc: Update the release signing key for 1.3.0rc1.

* doc/guix.texi (OPENPGP-SIGNING-KEY-ID): Use Maxim Cournoyer's key.
(OPENPGP-SIGNING-KEY-URL): Adjust accordingly.
---
 doc/guix.texi | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/doc/guix.texi b/doc/guix.texi
index dbea5cadcb..3ca681a48b 100644
--- a/doc/guix.texi
+++ b/doc/guix.texi
@@ -10,8 +10,8 @@
 @include version.texi
 
 @c Identifier of the OpenPGP key used to sign tarballs and such.
-@set OPENPGP-SIGNING-KEY-ID 3CE464558A84FDC69DB40CFB090B11993D9AEBB5
-@set OPENPGP-SIGNING-KEY-URL 
https://sv.gnu.org/people/viewgpg.php?user_id=15145
+@set OPENPGP-SIGNING-KEY-ID 27D586A4F8900854329FF09F1260E46482E63562
+@set OPENPGP-SIGNING-KEY-URL 
https://sv.gnu.org/people/viewgpg.php?user_id=127547
 
 @c Base URL for downloads.
 @set BASE-URL https://ftp.gnu.org/gnu/guix
-- 
2.31.1

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

[Leo Famulari]

On Sat, May 01, 2021 at 07:53:26AM -0400, guix-comm...@gnu.org wrote:
> commit c04dfb39f62f764b1c3988d9b0fcedc8221afa67
> Author: Pierre Neidhardt 
> AuthorDate: Sat May 1 13:53:09 2021 +0200
> 
> gnu: sbcl: Update to 2.1.4.
> 
> * gnu/packages/lisp.scm (sbcl): Update to 2.1.4.

Hi Pierre,

I noticed this evaluation had a lot of queued builds:

https://ci.guix.gnu.org/eval/29613

It's based on the SBCL update:

https://git.savannah.gnu.org/cgit/guix.git/commit/?id=c04dfb39f62f764b1c3988d9b0fcedc8221afa67

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

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.

If we do want to be able to update SBCL on the master branch, please
coordinate it in advance. 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?

The build farm seems to have mostly built the derivations now (aside
from aarch64), so there's no action required at this point.

Leo

[0] 

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

[Mark H Weaver]

Hi Leo,

I took the liberty of refilling the quotations in your email to make
them more readable.

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?

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

>> 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 fact
that I presented is true.

If you disagree, can you please provide a counterexample?

> Either way, "just pointing out facts" is not an accurate
> assessment in my opinion; facts are nothing without interpretation,
> which see.

I don't understand what you're getting at here.  Can you please
elaborate?

>> Here, I think that you are making your own speculations based on the
>> facts that I uncovered, and are attributing those speculations to me.
>> That's unfair.  Your speculations are not my responsibility.
>> 
>> Moreover, even if it were true that most people would make similar
>> speculations based on the facts I exposed, that's not my
>> responsibility either.
>>
> Here, I believe, you are wrong.  If your audience is led to a certain
> view due to your speech, even if it's not something you explicitly
> stated, you are still the one who made them hold that view (or
> reinforced it, if they already held it before and you merely made a
> claim in support of their view).  From an utilitarian point of view, it
> is the effects of your actions, that matter.

For purposes of deciding what actions one should take to achieve a
certain goal, I certainly agree that what ultimately matters are the
predictable effects of one's actions, and not the intent behind them.
So, in that context, I agree with much of what you wrote above.

However, if you mean to suggest that people should be held accountable
for all effects of their actions, I must *strenuously* object.

For example, if a speaker at a Black Lives Matter protest gives a speech
which recounts the many unjustifiable killings of innocent black people
by police, and later that day some of the people attending the protest
loot small businesses, I hope that we can agree that it would be unjust
to hold the speaker accountable for that.

If speakers at a protest can be held accountable for the actions of
every person who attends the protest, then protests would *effectively*
become illegal, because the opposition can always hire infiltrators to
*ensure* that someone does something illegal.

In this case, if I cannot point out a "cosmetic changes" commit that
removes security fixes without being accused of insinuating that the
person was acting in bad faith, then effectively it becomes unsafe for
me to point out breaches such as this one.

> Let it be said, that I don't condemn you for starting this thread.  Not
> only did it highlight an issue, that would otherwise have gone
> unnoticed, I think 

Re: GNU Guix 1.3.0rc1 available for testing!

[Maxim Cournoyer]

Hi Vagrant,

Vagrant Cascadian  writes:

> On 2021-05-01, Maxim Cournoyer wrote:
>> A first RC for the upcoming 1.3.0 release is now available for testing:
>
> Thanks for all the hard work getting rc1 ready!
>
>
> Also soon coming to a Debian mirror near you:
>
>   https://buildd.debian.org/status/package.php?p=guix=experimental

Swift!  On all 5 architectures supported!  Nice work :-).

Maxim

Re: GNU Guix 1.3.0rc1 available for testing!

[Maxim Cournoyer]

Hi Leo,

Leo Famulari  writes:

> On Sat, May 01, 2021 at 01:45:57AM -0400, Maxim Cournoyer wrote:
>> https://alpha.gnu.org/gnu/guix/guix-binary-1.3.0rc1.x86_64-linux.tar.xz
>
> I tested the binary tarball on x86_64.
>
> I used `guix package --export-manifest > manifest` before beginning the
> test, so that I could easily recreate my profile afterwards.
>
>> All these files have an associated ‘.sig’, an OpenPGP signature that you
>> can verify as explained at
>> .
>
> These instructions explain how to get Ludo's key, but that wasn't used
> here.
>
> In doc/guix.texi, the variables OPENPGP-SIGNING-KEY-ID and
> OPENPGP-SIGNING-KEY-URL are defined.
>
> Maybe we should update the manual to mention "1.3.0rc1" and the correct
> key.
>
> The "normal" manual would still mention 1.2.0, but the devel manual
> would work for 1.3.0rc1. I think that it's fine to mention the release
> candidate in the "devel" manual.
>
> https://guix.gnu.org/manual/en/
> https://guix.gnu.org/manual/devel/en/

Thank you for pointing that issue; I caught the problem with
guix-install.sh before posting, but overlooked that one.  As you
pointed, that won't be reflected on our website, but I agree that having
the new key covered in the devel manual (master branch) is already an
improvement.  The attached patch augments the manual to cover for the
new key.  Let me know if it looks good to you.  If it does, I will push
it to the master branch (IIUC we can't push this change to the
version-1.3.0 branch as that would break the string freeze there).

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

Are you sure you downloaded it from https://guix.gnu.org/install.sh
(which just redirects to the current copy on the master branch) ?  Since
commit e64af2060e8cfa48e74b887281acb3fd4c7e7781 (which was made just
before writing the original message), it checks for both keys.

> Aside from that, the install.sh script worked fine on current Debian,
> and I was able to conveniently restore my Guix profile with `guix
> package -m ./manifest`.
>
> Then I did `guix pull && guix upgrade`. All good!
>
> I forgot to remove the existing Guix build users and the guixbuild group
> before my test. It would be great if somebody can remember to check that
> they are created successfully by the script.

I've tested the install script in a Ubuntu 20.04 VM which had never
known Guix, and it was successful.  I guess that part is covered :-).

Thanks for the tests and feedback!

Maxim
>From 3b942cb833688520c4c4dadfb281270520510564 Mon Sep 17 00:00:00 2001
From: Maxim Cournoyer 
Date: Sat, 1 May 2021 22:35:09 -0400
Subject: [PATCH] doc: Update to cover for an additional OpenPGP signing key.

The upcoming 1.3.0 release will be signed with my OpenPGP key, and further
releases may also be.

* doc/guix.texi (OPENPGP-SIGNING-KEY-ID, OPENPGP-SIGNING-KEY-URL): Rename to...
(OPENPGP-SIGNING-KEY-ID-1, OPENPGP-SIGNING-KEY-URL-1): ... these,
respectively.
(OPENPGP-SIGNING-KEY-ID-2, OPENPGP-SIGNING-KEY-URL-2): New variables.
(Binary Installation): Adjust to cover for the new key.
(USB Stick and DVD Installation): Likewise.
(Invoking guix refresh): Adjust accordingly.
---
 doc/guix.texi | 26 --
 1 file changed, 16 insertions(+), 10 deletions(-)

diff --git a/doc/guix.texi b/doc/guix.texi
index 2fe7ad3a2a..b1bb0db74d 100644
--- a/doc/guix.texi
+++ b/doc/guix.texi
@@ -9,9 +9,11 @@
 
 @include version.texi
 
-@c Identifier of the OpenPGP key used to sign tarballs and such.
-@set OPENPGP-SIGNING-KEY-ID 3CE464558A84FDC69DB40CFB090B11993D9AEBB5
-@set OPENPGP-SIGNING-KEY-URL https://sv.gnu.org/people/viewgpg.php?user_id=15145
+@c Identifier of the OpenPGP keys used to sign tarballs and such.
+@set OPENPGP-SIGNING-KEY-ID-1 3CE464558A84FDC69DB40CFB090B11993D9AEBB5 @c ludo
+@set OPENPGP-SIGNING-KEY-URL-1 https://sv.gnu.org/people/viewgpg.php?user_id=15145
+@set OPENPGP-SIGNING-KEY-ID-2 27D586A4F8900854329FF09F1260E46482E63562 @c maxim
+@set OPENPGP-SIGNING-KEY-URL-2 https://sv.gnu.org/people/viewgpg.php?user_id=127547
 
 @c Base URL for downloads.
 @set BASE-URL https://ftp.gnu.org/gnu/guix
@@ -649,11 +651,13 @@ $ wget @value{BASE-URL}/guix-binary-@value{VERSION}.x86_64-linux.tar.xz.sig
 $ gpg --verify guix-binary-@value{VERSION}.x86_64-linux.tar.xz.sig
 @end example
 
-If that command fails because you do not have the required public key,
-then run this command to import it:
+If that command fails because you do not have the required public keys,
+then run these commands to import them:
 
 

Re: linux-libre source tarballs

[Leo Famulari]

On Sat, May 01, 2021 at 06:45:32PM -0700, Vagrant Cascadian wrote:
> Pragmatically speaking, on slower platforms this is a huge resource
> overhead. So much so that ci.guix.gnu.org *usually* times out when
> generating the linux-libre aarch64 tarballs:
> 
>   
> https://ci.guix.gnu.org/search?query=system%3Aaarch64-linux+linux-libre-arm64-generic

Thanks for letting me know. I didn't know this was happening.

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.

> * Using linux-libre's git repository.

We could do this. The decision is up to the maintainers, ultimately. I'd
rather we did not because linux-libre is not the "upstream" of the
kernel in a meaningful way (they do not develop or fix bugs), and it's
not "source code" in the GNU sense, which is the "preferred form of the
work for making changes in it":

http://www.gnu.org/licenses/gpl-faq.en.html#GPLOtherThanSoftware

Not to mention that cloning a 1 GB Git repo is rather expensive compared
to downloading a tarball, and thus also suboptimal for the ARM boards
that can't easily deblob. Although if people are building the
linux-libre tarballs, they are also compiling, which is of course way
more expensive.
  
> * Using the linux-libre tarballs. May have some issues with long-term
>   availability, but fast to download and the deblobbing scripts have
>   effectively already been run, saving a lot of local work. There is
>   basically support for this in guix already, and was the method used in
>   guix before july 2019 1ad9c105c208caa9059924cbfbe4759c8101f6c9.

As you say, these tarballs are not available for very long.  I think
this option is not practical for that reason.

> * Bump the timeouts on ci.guix.gnu.org for linux-libre so that the
>   deblob scripts actually get a chance to finish. Doesn't require much
>   change in the guix infrastructure to significantly improve the status
>   quo for slower architectures. Might take some tweaking over time to
>   find the right timeouts.

Will do.

linux-libre source tarballs

[Vagrant Cascadian]

So, for better or worse, I do a lot with guix on aarch64 platforms and
sometimes even armhf ones. And these platforms are...  often...
quite...  slow...

The way guix does updates of linux-libre sources by downloading upstream
linux tarballs and applying the linux-libre deblobbing and related
scripts to them is really technically excellent.

Pragmatically speaking, on slower platforms this is a huge resource
overhead. So much so that ci.guix.gnu.org *usually* times out when
generating the linux-libre aarch64 tarballs:

  
https://ci.guix.gnu.org/search?query=system%3Aaarch64-linux+linux-libre-arm64-generic

Same story for "linux-libre".

This means that platforms that are already fairly slow have to build one
or more source tarballs every linux-libre update, which can take several
hours to build the source for a kernel that takes only an hour or less
of compilation time.


I explored some of the alternatives last year:

  https://lists.gnu.org/archive/html/guix-devel/2020-08/msg00089.html

Some of the surrounding threads also go into various issues around this
topic, but I'll summarize what I tried:

* Using linux-libre's git repository. A *bit* slow to download and
  consumed ~1GB of space in /gnu/store, though much faster than running
  the deblobbing scripts. Probably would deduplicate fairly well between
  different versions, but would require re-downloading a lot of
  content. Maybe a more savvy method to make use of this would be
  possible. If a method somewhat like the mirror:// syntax for git
  repositories allowed for a local git cache or a local git proxy, this
  could save a lot of downloading and still get some benefits of
  git. Needs someone to actually do the work, of course...
 
* Using the linux-libre tarballs. May have some issues with long-term
  availability, but fast to download and the deblobbing scripts have
  effectively already been run, saving a lot of local work. There is
  basically support for this in guix already, and was the method used in
  guix before july 2019 1ad9c105c208caa9059924cbfbe4759c8101f6c9.


Recently I've been thinking more about this for aarch64 and armhf; there
are a few things that might help considerably:

* Bump the timeouts on ci.guix.gnu.org for linux-libre so that the
  deblob scripts actually get a chance to finish. Doesn't require much
  change in the guix infrastructure to significantly improve the status
  quo for slower architectures. Might take some tweaking over time to
  find the right timeouts.

* Default to using the fsfla linux-libre tarballs on aarch64 and armhf,
  while doing the full local deblobbing process for other faster
  architectures. This keeps the infrastructure of both methods
  up-to-date and tested, and can be used to do interesting things like
  comparing to make sure the linux-libre tarballs guix generates and the
  fsfla linux-libre tarballs do not contain significant
  differences. This may very well require maintenance overhead by
  generating two different hashes (one for the guix deblobbed tarball,
  and one for the linux-libre deblobbed tarball), and doing things a
  little differently by architecture is a little awkward.

* Produce the guix tarballs in a way that architectures could share the
  resulting tarball. I'm not sure what hoops this would require jumping
  through, something like generate the tarball, upload somewhere, update
  hash. The tarball produced by running the deblob scripts really
  shouldn't be architecture-dependent; re-doing this work on each
  architecture seems suboptimal (though I get is also somewhat a result
  of the functional package management model).


I like the idea of keeping all the infrastructure there to handle what
is currently done now, but would really like to figure out alternatives
at least for aarch64 and armhf.


Thanks for reading so far, please let me know what you think!


live well,
  vagrant


signature.asc
Description: PGP signature

Pinebook Pro no longer WIP

[Vagrant Cascadian]

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.


Things I've tested that work:

  eDP panel (a.k.a. the monitor)
  keyboard
  trackpad
  microSD
  basic battery and charger monitoring
  USB ports (ethernet, keyboard)
  Sufficient graphics acceleration to run "sway"
  Pinebook Pro USB-C dock (ethernet, USB 3.0 ports, USB-C ports, microSD reader)
  cpu frequency scalining

Untested:

  NVMe adapter (no pcie bus detected, needs further investigation)
  eMMC
  WiFi (non-free drivers)
  suspend in any form

Outstanding bugs and/or quirks:

  often hangs on reboot and keeps draining power
  sometimes hangs on shutdown and keeps draining power
  charging from usb-c only works sometimes
  usb-c dock ethernet/usb-3 only works with the usb-c plug in the "correct" 
orientation

Further exploration:

I've only tested with the "linux-libre-arm64-generic" kernels, but in
theory if the right modules are enabled and you add them to your initrd,
the regular "linux-libre" package should work as well.

There's one patch in wip-pinebook-pro still that included a system
configuration for the pinebook pro; it may need some slight updating to
be brought current. Other than that, it is probably time to completely
deprecate and/or remove the wip-pinebook-pro branch!

I also haven't ever played with the disk-image that's merged in guix
master, but in theory these improvments should make it work better!


In closing, it's a somewhat usable, quirky laptop running aarch64!

Big thanks to janneke for the initial work on the wip-pinebook-pro
branch, Lionel Fourquaux for bringing the minimal changes needed to my
attention, and everyone else who's helped along the way.


live well,
  vagrant

[0] 
https://patchwork.ozlabs.org/project/uboot/patch/20210406151059.1187379-1-icen...@aosc.io/
[1] 
https://patchwork.kernel.org/project/linux-rockchip/patch/20200924063042.41545-1-...@endlessos.org/
[2] https://bugs.debian.org/987638


signature.asc
Description: PGP signature

Making technology more inclusive Was: Leaving the GNU Guix community

[Denis 'GNUtoo' Carikli]

On Fri, 30 Apr 2021 01:43:37 +0200
Leo Le Bouter  wrote:

> I think that the technicality of software development must be
> redefined so that the hierarchy between the experienced and the
> beginner disappears [...]
I've been thinking a lot about these topics, and there are radical
solutions that can work today, but the scope is quite limited.

Sadly, technology in general is way too complex to enable any individual
to be able to practically exercise the freedom to modify how it works
at every level: For instance, computer hardware is way too complex, not
everyone is able to modify how the RAM initialization is done in
Libreboot. And that's just for the software side that is visible to
users. There is also a big interest in modifying how the hardware
works, for instance by making custom CPUs on FPGAs, which again
requires domain specific knowledge.

Despite that, several indigenous communities run their own GSM
networks[1] and while doing that at least some of them seem to have
managed to do what you are talking about (remove power relationships
between the people with specific knowledge and the people without that
specific knowledge):
- The people running the network have to obey what the village assembly
  decided. So everybody decide together with the people running the
  networks.
- They also managed to have the protocol modified for them at a deeper
  level[2] to make their GSM network behave more like peer to peer
  networks between villages instead of the way GSM networks are
  typically deployed.

Note that in this example above many of the communities that run their
own GSM networks didn't chose (yet?) to have Internet access for
instance so the scope is quite limited.

Things get more complicated when trying to bring this amount of control
down to every single individual for every aspect of every digital
technologies. And many people have personal computers this also looks
important to reflect on.

The approach taken by lisp machines was interesting: it enabled users to
practically modify all the source code (most or all of it wasn't free
software if I understood right). They used CPUs made specifically to
run lisp code to do that but as I understand the downside was that,
even if most of the code was in lisp, there was probably still some
code in assembly or other languages as the lisp interpreter was
probably not written in lisp.

Another approach that I find interesting is the one taken by operating
systems like OpenBSD (which is not FSDG compliant) where the design is
much more simple. The downside is that it lacks many functionalities
that some users might miss.

Hyperbola (which is FSDG compliant) is working on a new operating
system which will reuse the OpenBSD kernel, so it might be interesting.

Here the bar is probably higher as it requires to be able to write C to
modify the kernel, but at least some part of it looks a lot more simple
than Linux. For instance if we compare OpenBSD's pledge system call and
Linux's secomp, pledge is only one driver in the kernel whereas secomp
also requires a compiler and so on. And more importantly, software is
being written to take advantage of secomp, so I guess that at least in
some cases some people depend on secomp because of that.

One approach which seems to also have been taken by Guix is to work to
make it more simple to modify how things works. Since lisp is parsable
it might even be possible to write graphical user interfaces (in lisp
for instance) to enable users to modify how the system is configured,
how it works, etc.

But the downside is that it still depends on complex code in the
software it packages (like linux-libre, gcc, etc).

With learning, there are also interesting approaches used for learning
concepts used in digital technology (like the concepts used by git,
etc)[3] which could potentially enable more people to be able to modify
the way technology works, but it also requires time.

And for hardware, we start to have ISAs like RISCV or PPC64LE that can
at least be implemented with designs under free licenses. So it could
potentially open the door for more simple hardware, but that hardware
also needs to be fast and not too expensive or complex to produce, so
it could also not work out because of that.

So I'm really wondering where we could go with all that, could it all
become step by step, incrementally more accessible when combining
several of these things together (like better teaching + more simple
software and hardware)? Or do we really need to re-do it from scratch
to make technology accessible? Or change the way we live and interact
with technology to make it fit people instead of having people be
required to fit technology?

Unfortunately I don't really have a deep enough vision on this topic to
know which step to take in advance so I've mostly resorted to the
incremental improvements, hoping to advance things in the right
direction up to the point where it could work well enough or show us
its limit and push us to 

Re: Outreachy: Timeline tasks

[Luciana Lima Brito]

On Sat, 01 May 2021 20:07:56 +0100
Christopher Baines  wrote:

> Luciana Lima Brito  writes:
> 
> > On Sat, 01 May 2021 09:16:08 +0100
> > Christopher Baines  wrote:
> >  
> >> Currently the timing of various sections of the process includes
> >> timing smaller sections, and that may complicate reading the chart,
> >> since it won't convey which timed sections include other timed
> >> sections. Does that make sense?  
> >
> > Yes, I understand. But just to make sure, you say that the actions
> > we see in the logs are actually subsections of a bigger process? The
> > problem here would be to clearly mark in the code actions of a same
> > process. I'll take this into account on my planning.  
> 
> Take the lint warnings for example, currently the time to fetch all
> lint warnings is timed, but the usage of each individual linter is
> timed. Both bits of information are helpful.

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

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? 

Anyway, I think all this can be further discussed while the work is in
progress.

> > I'll add this to the plan and to the final application, ok?  
> 
> Yep.

-- 
Best Regards,

Luciana Lima Brito
MSc. in Computer Science

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

[Leo Prikler]

Hi Mark,

Am Samstag, den 01.05.2021, 18:12 -0400 schrieb Mark H Weaver:
> Hi Leo,
> 
> Leo Prikler  writes:
> 
> > Am Samstag, den 01.05.2021, 19:02 +0200 schrieb Giovanni Biscuolo:
> > > I also spent some time re-reading messages that Mark sent in this
> > > thread and, like him, I really don't understand what Mark did
> > > wrong.
> > > 
> > > For sure Mark /insisted/ that Raghav and Léo did something wrong
> > > with
> > > some commits, we can say Mark did it being /direct/ and
> > > /accusatory/
> > > but we cannot really say Mark assumed bad faith from them.
> > He did wrong insofar as his accusatory message read as though he
> > was
> > assuming bad faith
> 
> 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.
Again, I might just be reading Ludo's message wrong here (and if not,
Ludo might have read Ricardo wrong at the time; the original message
seems to be directed towards Léo for insinuating you assumed bad faith
when you weren't).  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.

> 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.  So did I in the
same thread.  Either way, "just pointing out facts" is not an accurate
assessment in my opinion; facts are nothing without interpretation,
which see.

> Here, I think that you are making your own speculations based on the
> facts that I uncovered, and are attributing those speculations to me.
> That's unfair.  Your speculations are not my responsibility.
> 
> Moreover, even if it were true that most people would make similar
> speculations based on the facts I exposed, that's not my
> responsibility
> either.
Here, I believe, you are wrong.  If your audience is led to a certain
view due to your speech, even if it's not something you explicitly
stated, you are still the one who made them hold that view (or
reinforced it, if they already held it before and you merely made a
claim in support of their view).  From an utilitarian point of view, it
is the effects of your actions, that matter.

> > > If you want you can consider Mark used an /harsh/ tone but this
> > > is a
> > > personal feeling, something one /could/ read "between the lines"
> > > even
> > > if actually in a written communication I find it hard to read
> > > between
> > > the lines, it is not something factual.  Maybe Mark intended to
> > > be
> > > harsh, maybe not: who knows?  Is /this/ (finding he was harsh)
> > > important?
> > It is definitely of some importance.
> 
> I agree that it's of some importance, but it's also a fundamentally
> hard
> thing to do.  I'm genuinely surprised by some of the claims being
> made
> about my messages, especially the claim that I assumed "bad
> faith".  I
> didn't say anything to imply that, I didn't think it, and I still
> don't.
I agree, it is hard, and it is also not immediately obvious what
effects a given statement might have.  We can only ever evaluate such
things a posteriori and try to learn from them.

> Sorry, what I meant to write above was "it's also fundamentally hard
> to
> anticipate the 'tone' that others will attribute to my writing."
Don't worry, that's more or less the way I read it.  In case you
wonder, the way I read it "reading between lines" is hard, which
certainly also holds, especially outside one's first language.

Let it be said, that I don't condemn you for starting this thread.  Not
only did it highlight an issue, that would otherwise have gone
unnoticed, I think most of the participants are now more acutely aware
of what might go wrong if they evade review.  

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

[Mark H Weaver]

Mark H Weaver  writes:

> Leo Prikler  writes:
>
>> Am Samstag, den 01.05.2021, 19:02 +0200 schrieb Giovanni Biscuolo:
>>> If you want you can consider Mark used an /harsh/ tone but this is a
>>> personal feeling, something one /could/ read "between the lines" even
>>> if actually in a written communication I find it hard to read between
>>> the lines, it is not something factual.  Maybe Mark intended to be
>>> harsh, maybe not: who knows?  Is /this/ (finding he was harsh)
>>> important?
>> It is definitely of some importance.
>
> I agree that it's of some importance, but it's also a fundamentally hard
> thing to do.

Sorry, what I meant to write above was "it's also fundamentally hard to
anticipate the 'tone' that others will attribute to my writing."

> I'm genuinely surprised by some of the claims being made
> about my messages, especially the claim that I assumed "bad faith".  I
> didn't say anything to imply that, I didn't think it, and I still don't.
>
> Thanks for discussing this, Leo.  I appreciate your feedback, even where
> we disagree.

  Regards,
Mark

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

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

[Mark H Weaver]

Hi Leo,

Leo Prikler  writes:

> Am Samstag, den 01.05.2021, 19:02 +0200 schrieb Giovanni Biscuolo:
>> I also spent some time re-reading messages that Mark sent in this
>> thread and, like him, I really don't understand what Mark did wrong.
>> 
>> For sure Mark /insisted/ that Raghav and Léo did something wrong with
>> some commits, we can say Mark did it being /direct/ and /accusatory/
>> but we cannot really say Mark assumed bad faith from them.
> He did wrong insofar as his accusatory message read as though he was
> assuming bad faith

Can you please point out which of my words led you to conclude that I
was assuming bad faith?

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.

Here, I think that you are making your own speculations based on the
facts that I uncovered, and are attributing those speculations to me.
That's unfair.  Your speculations are not my responsibility.

Moreover, even if it were true that most people would make similar
speculations based on the facts I exposed, that's not my responsibility
either.

>> If you want you can consider Mark used an /harsh/ tone but this is a
>> personal feeling, something one /could/ read "between the lines" even
>> if actually in a written communication I find it hard to read between
>> the lines, it is not something factual.  Maybe Mark intended to be
>> harsh, maybe not: who knows?  Is /this/ (finding he was harsh)
>> important?
> It is definitely of some importance.

I agree that it's of some importance, but it's also a fundamentally hard
thing to do.  I'm genuinely surprised by some of the claims being made
about my messages, especially the claim that I assumed "bad faith".  I
didn't say anything to imply that, I didn't think it, and I still don't.

Thanks for discussing this, Leo.  I appreciate your feedback, even where
we disagree.

 Regards,
   Mark

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

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

[Maxime Devos]

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 .

Greetings,
Maxime.


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

Re: GNU Guix 1.3.0rc1 available for testing!

[Leo Famulari]

On Sat, May 01, 2021 at 01:45:57AM -0400, Maxim Cournoyer wrote:
> https://alpha.gnu.org/gnu/guix/guix-binary-1.3.0rc1.x86_64-linux.tar.xz

I tested the binary tarball on x86_64.

I used `guix package --export-manifest > manifest` before beginning the
test, so that I could easily recreate my profile afterwards.

> All these files have an associated ‘.sig’, an OpenPGP signature that you
> can verify as explained at
> .

These instructions explain how to get Ludo's key, but that wasn't used
here.

In doc/guix.texi, the variables OPENPGP-SIGNING-KEY-ID and
OPENPGP-SIGNING-KEY-URL are defined.

Maybe we should update the manual to mention "1.3.0rc1" and the correct
key.

The "normal" manual would still mention 1.2.0, but the devel manual
would work for 1.3.0rc1. I think that it's fine to mention the release
candidate in the "devel" manual.

https://guix.gnu.org/manual/en/
https://guix.gnu.org/manual/devel/en/

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

Aside from that, the install.sh script worked fine on current Debian,
and I was able to conveniently restore my Guix profile with `guix
package -m ./manifest`.

Then I did `guix pull && guix upgrade`. All good!

I forgot to remove the existing Guix build users and the guixbuild group
before my test. It would be great if somebody can remember to check that
they are created successfully by the script.

Re: Neovim plugin/addon packaging

[Jack Hill]

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.


Best,
Jack

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

[Leo Prikler]

Hello Giovanni,

I am not Mark or Ludo, but as a /generic other/, I'd still like to
reply.

Am Samstag, den 01.05.2021, 19:02 +0200 schrieb Giovanni Biscuolo:
> Hello Mark and Ludovic,
> 
> please forgive me if I'm going forward with this thread but, after
> some
> hesitation, I decided to write this message because I /feel/ we could
> do
> better in dealing with issues like this one.
> 
> Please when you'll read "you" consider it a /generic you/ ("you the
> reader") not Mark, Ludovic or any specific person;  please also
> consider
> that "we" is a /plurali maiestatis/ :-D
Nitpick, should be /pluralis/ :P

> I also spent some time re-reading messages that Mark sent in this
> thread
> and, like him, I really don't understand what Mark did wrong.
> 
> For sure Mark /insisted/ that Raghav and Léo did something wrong with
> some commits, we can say Mark did it being /direct/ and /accusatory/
> but
> we cannot really say Mark assumed bad faith from them.
He did wrong insofar as his accusatory message read as though he was
assuming bad faith (or at the very least incompetence, which, if you
are the party being accused, does not sound too nice either).

> If you want you can consider Mark used an /harsh/ tone but this is a
> personal feeling, something one /could/ read "between the lines" even
> if
> actually in a written communication I find it hard to read between
> the
> lines, it is not something factual.  Maybe Mark intended to be harsh,
> maybe not: who knows?  Is /this/ (finding he was harsh) important?
It is definitely of some importance.  You want your readers to
interpret your message in the same way you interpret them and "sounding
pointlessly harsh" is (I would assume) not the way anyone wants to be
read.  Of course, there is a complex interplay between reader and
writer at hand here, but only one variable for the writer to control.

In this case, what was read between the lines caused one of the
participants to assume a very defensive stance, and might also have
been uncomfortable for others, who were involved.  While I personally
disagree with tone policing (the act of dismissing criticism based
solely on issues of tone), I think trying to phrase things in a way
you're less likely to be misunderstood is in general a good idea.

> As I said above, at most Mark communication should be considered
> /direct/ and /accusatory/, I say this considering statements like
> this:
> 
> «Léo Le Bouter [...] bears primary responsibility for these
> mistakes.»
> 
> «I would very much like to hear an explanation from Léo about how
> this
> happened.»
> 
> «Nonetheless, you (Raghav) also bear some responsibility»
> 
> «blatantly [1] misleading commit log [...] Most of the changes above
> are
> not mentioned in the commit log at all, and of course the summary
> line
> is extremely misleading.»
Each of those phrases on their own might not look too bad, but
stringing them together like this constructs an image in which Mark is
just looking for someone to blame.  Of course, with full context, it's
slightly less severe, but you can't ignore the possibility, that your
conversation partner might choose to get riled up by those alone.

> So: Mark gave responsibilities and complained "loudly" about
> misleading
> commits, giving precise explanations of the reasons for how bad he
> considered the situation, from his point of view (the point of view
> of a
> person with competence /and/ previous commints in the domain he was
> analyzing).  You can agree or disagree with him, but /now/ this is
> not
> the point.
> 
> You can call it /accusation/, I call it /asking for responsibility/.
> 
> You can call it /harsh/, I call it /direct/.
> 
> Is it really important to find a proper definition for words used by
> Mark?  Is it important to define if some word was proper or improper
> to
> in this context?
> 
> In my opinion we should refrain questioning language here (I mean in
> Guix mailing lists), especially questioning (perceived) "tone";
> /unless/
> containing accusations of bad faith or insults, we should be
> forgiving
> /each other/ on how people choose how to use [2] language.
> 
> If we question language usage we risk to shame people for improper
> use
> of language and this is bad in my opinion because we risk to isolate
> or
> alienate people who - for whatever reason they choose - use direct
> (or
> harsh, or accusatory) language to express controversial ideas or
> report
> issues, never intending to offend really no one: please respect
> people
> /also/ if you find they improperly use language.
You make a somewhat decent point against tone policing and since I
agree on the position, I don't want to take away from your argument. 
However, I think it'd be better not to consider this as an issue of
people "choosing to be harsh" (which could well be avoided), but in
terms of inclusivity (not everyone is a native English speaker and we
come from different cultural backgrounds; we shouldn't discourage people from 

Re: Guix Home upstreaming plan

[Xinglu Chen]

Hi,

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

> Hi Andrew,
>
> Andrew Tropin  skribis:
>
>> There is a goal[0] to make Guix Home[1] a part of GNU Guix.  It will reduce
>> the duplications between projects, increase integrity and will provide
>> Guix users with a missing tool for declarative configuration of home
>> environments improving out of the box experience and allowing Guix users
>> on foreign distros to have Guix System-like experience.
>
> So, I have yet to go ahead and use it for myself to get a better feel.
> In the meantime, I looked at
> , and I like what I
> see!

There is also a development mailing list[1] if you want to get a better
idea of what’s currently cooking. :)

> 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. :)

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

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

[1]: https://lists.sr.ht/~abcdw/rde-devel
[2]: https://github.com/nix-community/home-manager

Bringing substitutes from the Guix Build Coordinator to users

[Christopher Baines]

Hey,

The Guix Build Coordinator has been around for a while, it's been
available in Guix for more than 6 months now. The setup I've been using
to test the Guix Build Coordinator for building things for substitutes
(guix.cbaines.net) has been running since mid 2020.

Anecdotally, the test setup I've been running (guix.cbaines.net) has for
a while now, generally had higher percentage substitute availability
compared to ci.guix.gnu.org, as reported by guix weather. I think it
might also be building more things since cross derivations are built
plus i586-gnu builds.

I think there are some benefits for using the Guix Build Coordinator to
build things for substitutes, and it would be good to work out how to
get those benefits to users of Guix generally.

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.

Going back to discussions in 2020, I think there was a path for starting
to experiment with the Guix Build Coordinator, trying it on a few
machines in the berlin build farm, but as I say, this was last year and
before any work on implementing similar functionality in Cuirass as far
as I'm aware. Since then, I've also got an instance of the Guix Build
Coordinator running on bayfront with a couple of extra machines also
involved for performing builds, but this is just starting off, and
doesn't bring any benefit in terms of substitutes, at least not yet.

This is a small part of the wider puzzle, when I was designing the Guix
Build Coordinator, it was meant for much more than building things for
substitutes, and those things are also happening. The Guix Build
Coordinator has enabled things like building packages affected by
patches, building fixed output derivations regularly, and will hopefully
enable a whole load of quality assurance things. But my hope was also to
try and tackle building things for substitutes, such that there's not
more software to maintain, and also to inform future work on the
guix-daemon itself, like whether it would be good for it to have an
asynchronous API, and how that might work.

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

Thanks,

Chris


signature.asc
Description: PGP signature

Re: Outreachy: Timeline tasks

[Christopher Baines]

Luciana Lima Brito  writes:

> On Sat, 01 May 2021 09:16:08 +0100
> Christopher Baines  wrote:
>
>> Currently the timing of various sections of the process includes
>> timing smaller sections, and that may complicate reading the chart,
>> since it won't convey which timed sections include other timed
>> sections. Does that make sense?
>
> Yes, I understand. But just to make sure, you say that the actions we
> see in the logs are actually subsections of a bigger process? The
> problem here would be to clearly mark in the code actions of a same
> process. I'll take this into account on my planning.

Take the lint warnings for example, currently the time to fetch all lint
warnings is timed, but the usage of each individual linter is
timed. Both bits of information are helpful.

> 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

>> Great, this is a good amount of detail.
>
> I'll add this to the plan and to the final application, ok?

Yep.


signature.asc
Description: PGP signature

Re: Leaving the GNU Guix community

[Léo Le Bouter]

Hello Tobias,

On Sat, 2021-05-01 at 04:34 +0200, Tobias Geerinckx-Rice wrote:
> Léo,
> 
> Leo Le Bouter 写道：
> > I feel like what has happened is really a disaster,
> 
> I'm relieved that we share, at least, this.  I think everyone 
> does.
> 
> > I don't feel like contributing to GNU Guix anymore in the 
> > future.
> 
> That's a great pity.  I hope to welcome you back some day.  Guix 
> is better off with your fixes.
> 
> Yet I'm convinced that the decision to suspend commit access was 
> the right one.  It wasn't easy.  Nobody was happy about it.
> 
> I also hope that you can accept your role in the events that lead 
> to it and learn from them and make adjustments.
> 
> I'm disappointed that you still deflect the brunt of the 
> responsibility to others and refuse to acknowledge that this, 
> itself, is a problem.  Saving face consistently took precedence 
> over accepting feedback.  That's a dangerous blind spot to have.
> 

I do not think that is true, I think that 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. I think I have acknowledged lots of criticism over the
course of contributing to GNU Guix and this is not taken into account
AT ALL, and that you think that this decision was right I think further
re-inforces that I will not be contributing to GNU Guix in the future.
You failed to recognize the effect of the tone in the messages, and how
deeply it affects me and my ability to feel happy and also to be
constructive (which includes responding in a useful way to criticism).
I don't feel that I can change that. I can only survive in environments
where discussion is exceptionally caring and friendly for this very
reason. I feel deeply affected by everything that's said by people,
even through Internet messages.

I think it is a disaster that you (maintainers) choose to blame someone
publicly for feeling so bad after having received messages of
exceptional aggressivity. I think it is not fair and not justified.
That you insist for me to reply to some aggressive message, I think
that is a disaster. I think it is an horrible thing to ask to someone.

> > I think that the GNU
> > Guix maintainers justify unacceptable behavior and have acted 
> > upon
> > things without understanding them, not understanding why 
> > incidents have
> > happened
> 
> We have a much better understanding of the *complete* situation 
> than you imply.  It's far too common and too convenient to claim 
> that people you don't agree with are (at best) uninformed.

I don't think I am doing any of that and it's hurtful you say I am. I
am not. I really do think that we do not understand each other, on an
emotional level.

> 
> We've certainly made mistakes over the years.  Being buggy humans 
> we'll be sure to make more.
> 
> Several contributors expressed (in at least one case: severe) 
> unease with your attitude long before Mark sent his own unpleasant 
> message, and I think we did too little and waited too long to 
> publicly address either in a coordinated manner.  Lesson 
> hard-learnt.

I think that there's been disagreements and that it's been difficult to
handle for both me and other people. I think people must acknowledge
that I can have my own way of contributing to GNU Guix that can really
make sense and that I am not bound to listen to anyone's criticism if
it doesnt make sense to me and that I cannot or am not willing to do
the work to adapt my contributions to said criticism. If you are
talking about the Zimoun case, as unfortunate as it is that they went
away, I don't think it can be blamed solely on me. They also wanted to
go. What I expressed earlier about their postings remains true for me.
I felt harassed by their postings and that's the reason it also went
off the rails. I think that there's a difference in treatment between
people that contribute to GNU Guix, that not all contributors to GNU
Guix are considered equal, that I have been the subject of criticism
but that some other contributors to GNU Guix will not be the subject of
criticism for various other reasons. I feel like I should be treated
like a person with their own opinions and preferences when it comes to
contributing and that the way I choose to do the contributions as long
as I am the one making them should be respected and that if there's
criticism it is welcome but that if I do not agree with such criticism
that my disagreement be respected. As comparison, I rarely go and
criticize other's work, I trust people to do the best. I know everyone
goes and checks if their own contributions work great from time to
time, but for that to happen you must give the authors that time. I am
able to and I know everyone is able to self-criticize their work and
adapt also. You just have to give trust. I have not heard many people
criticize code quality or anything else when it is maintainers like
Mathieu or Ludovic that broke stuff. I 

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

[Giovanni Biscuolo]

Hello Mark and Ludovic,

please forgive me if I'm going forward with this thread but, after some
hesitation, I decided to write this message because I /feel/ we could do
better in dealing with issues like this one.

Please when you'll read "you" consider it a /generic you/ ("you the
reader") not Mark, Ludovic or any specific person;  please also consider
that "we" is a /plurali maiestatis/ :-D

Mark H Weaver  writes:

> Ludovic Courtès  writes:

[...]

>> 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.
>
> I'm sorry if this comes off as obtuse, but having now re-read all of my
> messages in this thread, I honestly do not see what I did wrong here.
> I will need some help to understand.

I also spent some time re-reading messages that Mark sent in this thread
and, like him, I really don't understand what Mark did wrong.

For sure Mark /insisted/ that Raghav and Léo did something wrong with
some commits, we can say Mark did it being /direct/ and /accusatory/ but
we cannot really say Mark assumed bad faith from them.

If you want you can consider Mark used an /harsh/ tone but this is a
personal feeling, something one /could/ read "between the lines" even if
actually in a written communication I find it hard to read between the
lines, it is not something factual.  Maybe Mark intended to be harsh,
maybe not: who knows?  Is /this/ (finding he was harsh) important?

As I said above, at most Mark communication should be considered
/direct/ and /accusatory/, I say this considering statements like this:

«Léo Le Bouter [...] bears primary responsibility for these mistakes.»

«I would very much like to hear an explanation from Léo about how this
happened.»

«Nonetheless, you (Raghav) also bear some responsibility»

«blatantly [1] misleading commit log [...] Most of the changes above are
not mentioned in the commit log at all, and of course the summary line
is extremely misleading.»

So: Mark gave responsibilities and complained "loudly" about misleading
commits, giving precise explanations of the reasons for how bad he
considered the situation, from his point of view (the point of view of a
person with competence /and/ previous commints in the domain he was
analyzing).  You can agree or disagree with him, but /now/ this is not
the point.

You can call it /accusation/, I call it /asking for responsibility/.

You can call it /harsh/, I call it /direct/.

Is it really important to find a proper definition for words used by
Mark?  Is it important to define if some word was proper or improper to
in this context?

In my opinion we should refrain questioning language here (I mean in
Guix mailing lists), especially questioning (perceived) "tone"; /unless/
containing accusations of bad faith or insults, we should be forgiving
/each other/ on how people choose how to use [2] language.

If we question language usage we risk to shame people for improper use
of language and this is bad in my opinion because we risk to isolate or
alienate people who - for whatever reason they choose - use direct (or
harsh, or accusatory) language to express controversial ideas or report
issues, never intending to offend really no one: please respect people
/also/ if you find they improperly use language.

[...]

> It would be very helpful if you could point out specific messages or
> quotes of mine to illustrate your criticisms, and to clearly explain
> what's wrong with them.  I'm not trying to be obstructionist here.  I
> honestly don't understand, and I cannot improve without understanding.

Also, if I overlooked, misinterpreted or missed something please tell me
so I can also improve.

Thanks! Giovanni.



[1] in a way that is very obvious and intentional, when this is a bad
thing (from Cambridge Dictionary).

[2] or misuse, in case of not native (or not so good) english speakers

-- 
Giovanni Biscuolo

Xelera IT Infrastructures


signature.asc
Description: PGP signature

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

[Joshua Branson]

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

Cheers!

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

Re: A "cosmetic changes" commit that removes security fixes

[Giovanni Biscuolo]

Hi Pierre,

Pierre Neidhardt  writes:

> I haven't really followed the issue,

I have, very carefully ;-)

> so I couldn't say whether the decision taken by the core maintainers
> was right or not.

From my point of view it was /but/ this is *not* relevant: what's
relevant here is that /if/ we trust Guix maintainers (I do) when they
give commit access rights to people, whe /have/ to trust them when they
revoke those rights.  We /should/ disccus /if/ the rules and best
practices to have and maintain the commit acces are well documented:
please make proposals (patches wellcome :-) ) but please we have to keep
trusting Guix maintainers (that is a collective of very competent
people).

[...]

>> I am not a core maintainer, but it should be obvious that core
>> maintainers would not take a decision to revoke commit rights lightly.
>
> I trust that it is the case, but being the devil's advocate,

Please don't:
«Why the Devil's Advocate Doesn't Help Reach the Truth»
https://www.gnu.org/philosophy/devils-advocate.html

--8<---cut here---start->8---

The devil achieves that by twisting my words: presenting a misleading
context in which my words appear to mean something other than what I
intended.

--8<---cut here---end--->8---

;-)

[...]

> Another question one could ask: why just the core maintainers
> actually?  Shouldn't everyone be involved?  Maybe the right answer is
> "no" here, and if so, I believe we should explain why in the community
> guidelines.

Guix is a GNU project and AFAIU GNU project management is well
documented:

https://www.gnu.org/gnu/gnu-structure.html

I don't know if Guix project needs specific «GNU Guix structure»
documentation but /if/ the answer is yes it should complement the
official GNU one, not replace it, IMHO.

BTW I see Guix contributors with commit access as "package maintanance
assistants" delegated by maintainers to make some technical decisions:

--8<---cut here---start->8---

The maintainers of a package often recruit others to contribute to its
development, and delegate some technical decisions to them. However,
the maintainers retain authority over the whole of the package so they
can carry out their responsibility to the GNU Project.

--8<---cut here---end--->8---

Please we should always consider that GNU maintainers are the persons
that carry out the responsibility to the GNU project, not contributors
with commit access.

Maybe the contributing section of Guix manual should mention it and link
the relevant GNU project's documents: do you think it'd be useful?

> Lest the community present an image where a few would benefit from
> arbitrary privileges.

...or seen from /the other side of the moon/: a few carry out the
precious work to be /responsible/ to do a good, practical job of
developing and maintaining Guix according to the GNU project's mission
and general decision.  If you want call it /arbitrary privilege/ but I
have a different point of view :-D

The "community" (whatever this means) should acknowledge that
contributing also means to be responsible toward other users of free
software: this needs competence in the specific matter (also domain
specific), discipline (i.e. properly documenting changes in commit
messages) and commitment to a set of common shared rules (documented in
Guix and GNU project manual).

[...]

> Last, maybe a more important question: if core maintainers are
> entrusted to take executive decisions about the community members,
> what about executive decisions about the core maintainers themselves?

Maintainers are appointed by the GNU project.

> Are there such provisions?  Example: what if a core maintainers
> misbehaves?  Can they see there privileges revoked?  How?  Is this
> documented?

«GNU Software Evaluation»
https://www.gnu.org/help/evaluation.html#whatmeans

Does this answer your question?

[...]

Happy hacking! Gio'

-- 
Giovanni Biscuolo

Xelera IT Infrastructures


signature.asc
Description: PGP signature

Re: Leaving the GNU Guix community

[Joshua Branson]

Tobias Geerinckx-Rice  writes:

> Léo,
>
> Leo Le Bouter 写道：
>> I feel like what has happened is really a disaster,
>
> I'm relieved that we share, at least, this.  I think everyone does.
>
>> I don't feel like contributing to GNU Guix anymore in the future.
>
> That's a great pity.  I hope to welcome you back some day.  Guix is
> better off with your fixes.
>
> Yet I'm convinced that the decision to suspend commit access was the
> right one.  It wasn't easy.  Nobody was happy about it.

May I humbly suggest, that in the future if guix
maintainers/developers/super-humans suspend someone's commit
access, this "punishment"/"education" happens privately?  Perhaps this
"education" should not be announced on guix-devel.  Instead it should
only be sent privately to the developer in question.  Perhaps that would
lessen the sting.

Thanks!

Joshua

P.S.  I'm definitely NOT a guix developer (maybe some day), but I hope
it's ok that I share my thoughts.  :)


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

Re: Unfortunate statefulness of Guix Install image

[Tobias Geerinckx-Rice]

Vladilen,

I'm writing mainly to save you some time testing ‘guix system init 
--localstatedir’.  That is a ./configure option used when building 
Guix from source.  I don't think any option will help you here.


Vladilen Kozin 写道：

Except, when you try to do the manual install off the same USB
... twice.


You're likely the first person to try this!

I *think* it implies that /var/guix/db is low-key bogus once 
cow-store is stopped, but I didn't test that assertion.  It should 
be reverted together with /gnu/store.


IMO what you want should be possible.  That it's not is a bug, 
albeit a low-priority one.


My best guess from what I've read in the manual is this. Store 
is not
the only place where derivations appear. /var/guix/db stores 
metadata
about said derivations. So the first time you do `herd start 
cow-store
/mnt` trick it'll create the store there but will populate the 
db on
that USB drive. Next time you try to install from that same USB 
on a
different machine it'll have its db reference derivations that 
are no
longer available. I worked around this by stupidly `mv 
/var/guix/db

/var/guix/db.old` and `guix system init` went without trouble.


This is a relatively simple fix.  Thanks for testing it.  Would 
you be able and willing to modify cow-store to handle /var/guix/db 
as well?


Kind regards,

T G-R


signature.asc
Description: PGP signature

Re: Outreachy: Timeline tasks

[Luciana Lima Brito]

Hi,

On Sat, 01 May 2021 09:16:08 +0100
Christopher Baines  wrote:
 
> Currently the timing of various sections of the process includes
> timing smaller sections, and that may complicate reading the chart,
> since it won't convey which timed sections include other timed
> sections. Does that make sense?

Yes, I understand. But just to make sure, you say that the actions we
see in the logs are actually subsections of a bigger process? The
problem here would be to clearly mark in the code actions of a same
process. I'll take this into account on my planning.

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.

> Great, this is a good amount of detail.

I'll add this to the plan and to the final application, ok?

-- 
Best Regards,

Luciana Lima Brito
MSc. in Computer Science

Re: A "cosmetic changes" commit that removes security fixes

[Pjotr Prins]

On Sat, May 01, 2021 at 12:53:43PM +0530, Arun Isaac wrote:
> We may like to imagine that being a core maintainer is not a badge of
> honor, but in reality, it *is* a badge of honor. A core maintainer is
> not just a regular participant any more than the President is just a
> public servant. If core maintainership is not to be associated with
> power and honor, we should put in place processes to achieve that. 

It is an interesting perspective. One problem I see with assuming a
badge of honor is that it will make it much harder to decide on giving
commit rights because it will have to be based on merit/selection and
make even harder to revoke them. Are you suggesting we elect
committers?

At this point, my personal assumption about the procedure and what I
have seen is that if someone is promising and active they get commit
rights - i.e., to make it easier on everyone who is maintaining Guix.
It is about flow of work and convenience. 

A core committer is arguably not even a core maintainer.

Nothing makes me think a core committer is comparable to an elected
president.

The Debian project is much larger than Guix and has unwieldy selection
criteria for people joining certain levels. Is that what we want? One
of the attractions of Guix to me is that it is a flat project and, as
far as I can tell, we have mostly avoided regular politics distracting
us from real work. We have channels so people can do what they want.
No reason to meddle with the core project if you are not so inclined.

I would vote to keep the Guix project structure as simple and flat as
possible without overheads. Nimble is the word. Want to build your own
cathedral? Start a channel. 

Pj.

PS: I am not a core committer and not a core maintainer. All opinions
are my own.

Re: Unfortunate statefulness of Guix Install image

[Vladilen Kozin]

If I read this https://guix.gnu.org/manual/en/html_node/The-Store.html#The-Store
correctly, then perhaps a proper solution to this is to also supply
--localstatedir in attempt to ensure that the db with metadata ends up
on the target partition? So e.g. like this:

guix system --localstatedir /mnt/var init /mnt/etc/config.scm /mnt

I've not tried it, but if it is the way to solve this, then perhaps
this extra step belongs in the Manual Installation section of the
manual.

On Fri, 30 Apr 2021 at 20:32, Vladilen Kozin  wrote:
>
> Hello Guix.
>
> This may or may not be a "bug", but thought I'd report something I run
> into. I found that GUI install never worked for me but booting off
> Guix Install USB and then following
> https://guix.gnu.org/manual/en/html_node/Manual-Installation.html
> worked perfectly fine. Except, when you try to do the manual install
> off the same USB ... twice. That is, having installed a system once
> off that USB, you then try to install another and your `guix system
> init path/to/config.scm /mnt` would almost immediately fail with error
> saying that some expected derivation have not been found in the store.
>
> My best guess from what I've read in the manual is this. Store is not
> the only place where derivations appear. /var/guix/db stores metadata
> about said derivations. So the first time you do `herd start cow-store
> /mnt` trick it'll create the store there but will populate the db on
> that USB drive. Next time you try to install from that same USB on a
> different machine it'll have its db reference derivations that are no
> longer available. I worked around this by stupidly `mv /var/guix/db
> /var/guix/db.old` and `guix system init` went without trouble.
>
> I guess my complaint is that at least the manual way (maybe GUI
> install, too) is completely stateful and turns that USB stick into
> "consumable good" unless you know about the database.
>
> Sorry, dunno enough about Guix, so maybe I've been doing something wrong.
> --
> Best regards
> Vlad Kozin



-- 
Best regards
Vlad Kozin

Re: Add a way to disable serialization support to (guix services configuration)

[Xinglu Chen]

Hi,

On Fri, Apr 23 2021, Xinglu Chen wrote:

>> Wouldn’t it be nicer to write:
>>
>>   (define-configuration foo
>> (bar (integer 123) "doc" no-serializer)
>> (baz (string "") "doc"))
>>
>> where ‘bar’ wouldn’t have a serializer and ‘baz’ would?
>>
>> It’s also probably easier to implement correctly.
>
> I think that would be a good idea, maybe it could also make having a
> default value be optional, like this:
>
> #+begin_src scheme
> (define-configuration foo
>   (bar (integer) "doc" no-serializer) ;no default
>   (baz (string "default") "doc"))
> #+end_src

Since nobody seemed to show any objections, I went ahead and did
something like this myself (see the attached patches).  My macros skills
aren’t that good so I hope I didn’t make any obvious mistakes. :)

I haven’t tested it thoroughly, but at least it didn’t break anything
when I ran ‘./pre-inst-env guix home build ...’. :)

>From 231281ebf555295e83513873293a1ad3eab884a8 Mon Sep 17 00:00:00 2001
Message-Id: <231281ebf555295e83513873293a1ad3eab884a8.1619869705.git.pub...@yoctocell.xyz>
In-Reply-To: 
References: 
From: Xinglu Chen 
Date: Sat, 1 May 2021 13:24:43 +0200
Subject: [PATCH 1/2] services: configuration: Support fields without default
 values.
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Not all fields in a configuration have a sensible default value,
e.g. ‘user.name’ in gitconfig, the user should have to set that themselves

* gnu/services/configuration.scm (configuration-missing-field): New procedure.
(define-configuration): Make default value optional.
---
 gnu/services/configuration.scm | 78 ++
 1 file changed, 51 insertions(+), 27 deletions(-)

diff --git a/gnu/services/configuration.scm b/gnu/services/configuration.scm
index 90f12a8d39..85e1ac78cb 100644
--- a/gnu/services/configuration.scm
+++ b/gnu/services/configuration.scm
@@ -2,6 +2,7 @@
 ;;; Copyright © 2015 Andy Wingo 
 ;;; Copyright © 2017 Mathieu Othacehe 
 ;;; Copyright © 2017, 2018 Clément Lassieur 
+;;; Copyright © 2021 Xinglu Chen 
 ;;;
 ;;; This file is part of GNU Guix.
 ;;;
@@ -63,6 +64,9 @@
 (define (configuration-missing-field kind field)
   (configuration-error
(format #f "~a configuration missing required field ~a" kind field)))
+(define (configuration-no-default-value kind field)
+  (configuration-error
+   (format #f "`~a' in `~a' does not have a default value" kind field)))
 
 (define-record-type* 
   configuration-field make-configuration-field configuration-field?
@@ -112,7 +116,7 @@
 (define-syntax define-configuration
   (lambda (stx)
 (syntax-case stx ()
-  ((_ stem (field (field-type def) doc) ...)
+  ((_ stem (field (field-type properties ...) doc) ...)
(with-syntax (((field-getter ...)
   (map (lambda (field)
  (id #'stem #'stem #'- field))
@@ -121,36 +125,56 @@
   (map (lambda (type)
  (id #'stem type #'?))
#'(field-type ...)))
+ ((field-default ...)
+  (map (match-lambda
+ ((field-type default _ ...) default)
+ ;; We get warnings about `disabled' being an
+ ;; unbound variable unless we quote it.
+ (_ (syntax 'disabled)))
+   #'((field-type properties ...) ...)))
  ((field-serializer ...)
   (map (lambda (type)
  (id #'stem #'serialize- type))
#'(field-type ...
-   #`(begin
-   (define-record-type* #,(id #'stem #'< #'stem #'>)
- #,(id #'stem #'% #'stem)
- #,(id #'stem #'make- #'stem)
- #,(id #'stem #'stem #'?)
- (%location #,(id #'stem #'-location)
-(default (and=> (current-source-location)
-source-properties->location))
-(innate))
- (field field-getter (default def))
- ...)
-   (define #,(id #'stem #'stem #'-fields)
- (list (configuration-field
-(name 'field)
-(type 'field-type)
-(getter field-getter)
-(predicate field-predicate)
-(serializer field-serializer)
-(default-value-thunk (lambda () def))
-(documentation doc))
-   ...))
-   (define-syntax-rule (stem arg (... ...))
- (let ((conf (#,(id #'stem #'% #'stem) arg (... ...
-   (validate-configuration conf
-   #,(id #'stem #'stem #'-fields))
-   conf
+ 

Re: A "cosmetic changes" commit that removes security fixes

[Yasuaki Kudo]

Hello!

I don't know the details of the case at all but let met mention this:
https://communityrule.info/
It comes from the world of worker cooperatives and I think them "rules of the 
community" is discussed a lot there as well 

Cheers,
Yasu

> On May 1, 2021, at 18:16, Pierre Neidhardt  wrote:
> 
> Pjotr Prins  writes:
> 
>> Being a core committer is *not* a badge of honour. It does not give
>> special privileges beyond what is expected.
> 
> But this may not be true.  Quite a few people have expressed otherwise
> over the years.
> 
> Maybe an issue is that much of the organizational structure of Guix is
> implicit.  The roles are not well defined and as a result, they may
> reach beyond what is commonly understood.
> 
> Some time ago, I was discussing the quetsion of implicit structure with
> Ludo, who sent me this essay:
> 
>  https://www.jofreeman.com/joreen/tyranny.htm
> 
> I found it enlightening and quite relevant to the matter at hand.
> 
> Even if in the end my concerns end up being unjustified, I find it good
> practice to always question the status quo: maybe something better could
> come out of it! :)
> 
> Cheers!
> 
> -- 
> Pierre Neidhardt
> https://ambrevar.xyz/

Re: #:cargo-inputs don't honor --with-input

[Hartmut Goebel]

Hi Ludo,

Am 30.04.21 um 12:45 schrieb Ludovic Courtès:


Uh.  More generally, Rust packages kinda create a “shadow dependency
graph” via #:cargo-inputs & co., which breaks all the tools that are
unaware of it.  It was discussed several times on this list, and
apparently it’s unfortunately unavoidable at this time.  :-/


Maybe we can get rid of #:cargo-inputs at least:

guix/build-system/cargo.scm says: "Although cargo does not permit cyclic 
dependencies between crates,

however, it permits cycles to occur via dev-dependencies"

So we could change #:cargo-inputs into normal inputs and get at least 
part of the dependencies right.


I'm aware of the "special treatment" of cargo-inputs. Anyhow we could 
apply the following changes to the cargo build-system:


 *

   The cargo build-system copies the "pre-built crate" (more on this
   below) into a new output called "rlib" or "crate". There already is
   a phase "packaging" which only needs to be changed to use the other
   output.

 *

   All of today's #:cargo-inputs will be changed into normal inputs
   using the "rlib/crate" output. (To avoid duplicate assoc-rec keys we
   might need to change the name/keys, but this should be a minor issue.)

 *

   If required, the cargo build-system can easily identify former
   #:cargo-inputs  by being inputs from a "rlib/crate" output.

Benefits up to here:

 * The dependency graph would be much more complete - although
   "#:cargo-development-inputs" would still be missing.
 * Package transformation options would work -again except for
   "#:cargo-development-inputs".
 * If(!) we actually manage to make cargo pick "pre-built" crates,
   package definition will already be adjusted to use them.

|Drawbacks up to here:|

 * ||Since the "packaging" phase copies the source, there is not much
   benefit in having a "rlib/crate" output yet. Actually, when a
   "rlib/crate" output needs to be build, the user will end up with two
   copies of the source (one from the git-checkout, one from packaging)

About "pre-built" crate: Given the many possible ways to build crates 
(e.g. switching on and off "features", different crate types), we might 
never be able to provide pre-built packages for all cases. Thus we might 
end up always providing the source, even if we manage to make cargo pick 
of pre-built artifacts.


About the output name: Rust has a notion of "rlib" (a specialized .a 
file), which seems to be the pre-built artifacts we are seeking. Thus 
the proposed name.


WDYT?

--
Regards
Hartmut Goebel

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

Re: Outreachy: Timeline tasks

[Christopher Baines]

Luciana Lima Brito  writes:

> On Fri, 30 Apr 2021 18:05:15 +0100
> Christopher Baines  wrote:
>
>> >
>> > Task 1: Add instrumentation to identify the slow parts of processing
>> > new revisions:
>> >
>> >   - Implementing a chart over time to identify slow parts:
>> >- The chart should consider two aspects, the time took by
>> >  each specific part, and its name, for identification
>> >   purpose. A bar chart is a good candidate for this task, it is
>> >   simple and can show the whole picture of the time taken by the
>> >  system to process a new revision;
>> >- The bars on the chart should be sorted in order of
>> >   precedence of the process in the X axis, and its height, which
>> >   is determined by the time it takes, measured in the Y
>> >  axis;
>>
>> I'm not sure what you mean by "precedence of the process" here?
>
> As we are concerned only with the time each process takes, and each bar
> on the chart will be presented side by side, the order of the bars would
> be the order that the processes appear. If you prefer, they could be
> sorted alphabetically, or by time taken.

Ok, I think I follow.

Currently the timing of various sections of the process includes timing
smaller sections, and that may complicate reading the chart, since it
won't convey which timed sections include other timed sections. Does
that make sense?

>> >- The charts should work as picture-logs for timing;
>> >- A chart should be generated for each new revision in real
>> >  time; 
>> 
>> It would be good to say explicitly how the chart will be stored, since
>> "the same way as the logs already are" is quite vague.
>
> I misunderstood this point so this part about storing the chart is
> completely messed. But I think now I got it. Let me correct the last
> point and add some more:
>   ...
>   - The time is already being computed for each part and it
> is shown in the logs, the same data can be used to build the charts.
> The data to build the chart for each revision could be
> stored as a new table in the database*, first in parts, for
> when a revision is still being processed, then combining their
> parts when the processing is finished.
>   - The new table on the database should store three information:
> the job_id, the action, and the time taken.
>   - Then, when one wants to see the chart, this table is queried
> and the chart is rendered as html.
>
> * Although the information is already in the log, it is stored as a
>   text, so it is harder to get the names of the actions and the time
>   taken by each, so I think that create a new table, with only these
>   values, is more suitable.

Great, this is a good amount of detail.


signature.asc
Description: PGP signature

Re: GNU Guix 1.3.0rc1 available for testing!

[Vagrant Cascadian]

On 2021-05-01, Maxim Cournoyer wrote:
> A first RC for the upcoming 1.3.0 release is now available for testing:

Thanks for all the hard work getting rc1 ready!


Also soon coming to a Debian mirror near you:

  https://buildd.debian.org/status/package.php?p=guix=experimental


live well,
  vagrant


signature.asc
Description: PGP signature

Re: A "cosmetic changes" commit that removes security fixes

[Arun Isaac]

Hi everyone,

This decision aside, I share some of the general concerns raised by
Pierre about core maintainership and the behind closed doors decision
making process.

> Being a core committer is *not* a badge of honour. It does not give
> special privileges beyond what is expected. It does not give you
> money, a degree or a knighthood. It only allows you to push code
> directly where it interferes with the work of others :)

We may like to imagine that being a core maintainer is not a badge of
honor, but in reality, it *is* a badge of honor. A core maintainer is
not just a regular participant any more than the President is just a
public servant. If core maintainership is not to be associated with
power and honor, we should put in place processes to achieve that. In
that regard, Guix has done better than most other free software
projects. For example, we don't assign people as maintainers (or owners)
of specific packages or groups of packages like other distributions
have. Still, I'm sure there's more we can do.

Cheers!
Arun


signature.asc
Description: PGP signature