Re: [PATCH] doc: Update contribution guidelines on patches, etc.

[Liliana Marie Prikler]

Am Dienstag, dem 09.08.2022 um 22:30 +0200 schrieb Maxime Devos:
> 
> On 09-08-2022 21:08, Liliana Marie Prikler wrote:
> > [I]t doesn't take multiple lines to embed a store path, the change
> > usually happens on a single line
> I was thinking of files that contain multiple instances of "foo"
> (usually on multiple lines) to be replaced by
> "/gnu/store/.../bin/foo", not files were a "foo
>  bar" was broken over multiple lines and it needs to be replaced by
> "/gnu/store/.../bin/foo
>  bar".
That's a single-line change imho, even if the single line gets repeated
9000 times.

Cheers

Re: v2: A proposal of a consistent set of clear rules and guidelines involving snippets, phases and patches.

[Maxime Devos]

On 09-08-2022 20:58, david larsson wrote:

On 2022-08-05 15:59, Maxime Devos wrote:

[..]



20.4.5.3 Fixing technical issues (compilation errors, test failures,
other bugs ...)

Usually, a bug fix comes in the form of a patch copied from upstream
or another distribution. In that case, simply adding the patch to the
'patches' field is the most convenient and usually does not cause any
problems; there is no need to rewrite it as a snippet or a phase.

If no ready-made patch already exists, then choosing between a patch
or a snippet is a matter of convenience. However, there are two things
to keep in mind:

First, when the fix is not Guix-specific, it is strongly desired to
upstream the fix to avoid the additional maintenance cost to Guix. As
upstreams cannot accept a snippet, writing a patch can be a more
efficient use of time. Secondly, if the fix of a technical issue
embeds a store file name, then it has to be a phase. Otherwise, if a
store file name was embedded in the source, the result of 'guix build
--source' would be unusable on non-Guix systems and likely also
unusable on Guix systems of another architecture.


There may be other reasons to add patches: [...]


Agreed (*), but I don't think that subsection claims those are the only 
reasons for patches -- that section is only about fixing technical 
issues, not adding new features, as implied by the name of the section.


I can look at adding a new subsection 'Adding new functionality' for a v3.

Liliana's documentation contains some information not in my v2, I intend 
to look into integrating that information as well.




1. Functionality, that is not yet accepted upstream, because 
maintainer(s) do not have enough time to review all pull requests, or 
are simply slow to review. "if no response within X time from 
upstream, then guix may include your patch" might be a good policy here.


(*) We sometimes do such things already. Example: 
 (nowadays upstreamed). I don't think 
this thread is a good place for deciding on the exact rules though -- 
deciding on an appropriate value of X seems difficult, I would like to 
separate that from the current documentation patch.


Greetings,
Maxime.


OpenPGP_0x49E3EE22191725EE.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

Re: [PATCH] doc: Update contribution guidelines on patches, etc.

[Maxime Devos]

On 09-08-2022 21:08, Liliana Marie Prikler wrote:

To be clear, do you mean you:
  * think it's not better, maybe even worse
  * think it's not_much_  better (but still_slightly_  better)
  * are undecided
  * or something else
?
Also, "guix build -S" returns the source code (after snippet / patch,
if any), not its derivation. For the latter: "guix build -S -d"

FWIW I don't think mentioning patch-and-repack is too helpful here
either.  Also, I'd like to use consistent wording at least within this
section, so here "source" means "upstream source" whereas "source
derivation" is a shorthand for the stuff Guix builds.  Yes, the
derivation is not the same thing as the output, but I again fail to see
how being overly precise is helpful.  That being said, I'm open to
suggestions.


I am not reading an answer to my question.

I don't think I've mentioned patch-and-repack (at least not by name, 
which you seem to be referring to?).


I would not recommend "source = upstream source", as the more general 
meaning is used in (guix)Introduction and 
 and elsewhere, otherwise 
terminology would become inconsistent, which can lead to misinterpretations.


I don't think there's such a thing as 'overly precise'.

My suggestion is the same as your suggestion:


You could s/source derivation/the result of
@code{guix build -S}/, but I don't think that's much better.

Greetings,
Maxime.



OpenPGP_0x49E3EE22191725EE.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

Re: [PATCH] doc: Update contribution guidelines on patches, etc.

[Maxime Devos]

On 09-08-2022 21:08, Liliana Marie Prikler wrote:

On 06-08-2022 08:55, Liliana Marie Prikler wrote:



+If your package has a bug that takes multiple lines to fix,

I don't think this is true for replacing all instances of "foo"
by
"/gnu/store/.../bin/foo" in a file.

Should it?

I don't think so. Directly substituting all the instances instead of
first writing a patch that does "foo" -> "@foo@" or such seems
simpler to me.  This might be a bit too nit-picky though, maybe it's
clear from context that this is not the kind of fix meant by that
line.

I'm struggling to see the issue here.  For starters, it doesn't take
multiple lines to embed a store path, the change usually happens on a
single line.  Of course, translating this into a substitute*, you
expand this single line into multiple ones, but that's not what is
meant here.


I was thinking of files that contain multiple instances of "foo" 
(usually on multiple lines) to be replaced by "/gnu/store/.../bin/foo", 
not files were a "foo
bar" was broken over multiple lines and it needs to be replaced by 
"/gnu/store/.../bin/foo

bar".

At least for the former, I don't think an intermediate "@foo@" is useful 
(with some exceptions, when a pattern match would catch too much).


The latter could in principle happen, but it doesn't seem to happen in 
practice.


Greetings,
Maxime.



OpenPGP_0x49E3EE22191725EE.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

Re: [PATCH] doc: Update contribution guidelines on patches, etc.

[Liliana Marie Prikler]

Am Dienstag, dem 09.08.2022 um 20:19 +0200 schrieb Maxime Devos:
> > Am Dienstag, dem 09.08.2022 um 18:45 +0200 schrieb Maxime Devos:
> > 
> > > On 06-08-2022 08:55, Liliana Marie Prikler wrote:
> > > 
> > > 
> > > > +If your package has a bug that takes multiple lines to fix,
> > > I don't think this is true for replacing all instances of "foo"
> > > by 
> > > "/gnu/store/.../bin/foo" in a file.
> > Should it?
> I don't think so. Directly substituting all the instances instead of
> first writing a patch that does "foo" -> "@foo@" or such seems
> simpler to me.  This might be a bit too nit-picky though, maybe it's
> clear from context that this is not the kind of fix meant by that
> line.
I'm struggling to see the issue here.  For starters, it doesn't take
multiple lines to embed a store path, the change usually happens on a
single line.  Of course, translating this into a substitute*, you
expand this single line into multiple ones, but that's not what is
meant here.

However, there are exceptions to this rule.  For an example that
requires indirection, see webkitgtk.

> [...]
> > 
> > > > +Such changes include, but are not limited to, fixes of the
> > > > build
> > > > +script(s) or embeddings of store paths (e.g. [...])
> > > > 
> > > [...]
> > Is that how to English comma? Sorry, I'm not a native speaker so I
> > get
> > somewhat weirded out by the when to skip/not to skip rules.
> > 
> Neither am I. English doesn't seem to do "rules" much. I do think,
> however, that adding a comma after "to" makes things a bit simpler to
> read here, and it doesn't appear to be ungrammatical -- at least, in
> licenses "but is/are not limited to" is often used that way.
Fair enough, will add the comma.

> > Derivations are a rather low-level concept, could they be avoided
> > in the origin and phases documentation?
> > I don't quite see how. You could s/source derivation/the result of
> > @code{guix build -S}/, but I don't think that's much better.
> > 
> To be clear, do you mean you:
>  * think it's not better, maybe even worse
>  * think it's not _much_ better (but still _slightly_ better)
>  * are undecided
>  * or something else
> ?
> Also, "guix build -S" returns the source code (after snippet / patch,
> if any), not its derivation. For the latter: "guix build -S -d"
FWIW I don't think mentioning patch-and-repack is too helpful here
either.  Also, I'd like to use consistent wording at least within this
section, so here "source" means "upstream source" whereas "source
derivation" is a shorthand for the stuff Guix builds.  Yes, the
derivation is not the same thing as the output, but I again fail to see
how being overly precise is helpful.  That being said, I'm open to
suggestions.

> > > > +Build phases are limited in that they do not modify the source
> > > > +derivation.  Thus, they are inadequate for changes that are to
> > > > be
> > > > +reflected in the source code.  On the other hand, they only
> > > > cause
> > > > a
> > > > +single rebuild and are thus slightly easier to debug than
> > > > phases
> > > > and
> > > > +snippets.
> > > See Andreas' comment on phase->snippet.
> > > 
> > > Also, do I understand correctly that the argument here is that
> > > 'single rebuild -> less compilation time -> easier to debug'?
> > Easier to debug for the package author currently fiddling with the
> > phase/snippet. Not really a statement in any direction otherwise.
> I don't see how "slightly easier to debug than phases" follows from
> "they cause only a single rebuild". My guess was that the
> intermediate step was lower compilation time, but apparently this was
> not the argument. As such, I'm not following.
I think this follows from your "I only deal with small packages"
experience earlier.  In my experience, the sources that are more likely
to require patches or snippets to fix their... issues... are also the
ones that take larger time to patch and repack.  After all, you don't
have that much overhead unpacking a 7 gig blob that doesn't exist.

Cheers

Re: v2: A proposal of a consistent set of clear rules and guidelines involving snippets, phases and patches.

[david larsson]

On 2022-08-05 15:59, Maxime Devos wrote:

[..]



20.4.5.3 Fixing technical issues (compilation errors, test failures,
other bugs ...)

Usually, a bug fix comes in the form of a patch copied from upstream
or another distribution. In that case, simply adding the patch to the
'patches' field is the most convenient and usually does not cause any
problems; there is no need to rewrite it as a snippet or a phase.

If no ready-made patch already exists, then choosing between a patch
or a snippet is a matter of convenience. However, there are two things
to keep in mind:

First, when the fix is not Guix-specific, it is strongly desired to
upstream the fix to avoid the additional maintenance cost to Guix. As
upstreams cannot accept a snippet, writing a patch can be a more
efficient use of time. Secondly, if the fix of a technical issue
embeds a store file name, then it has to be a phase. Otherwise, if a
store file name was embedded in the source, the result of 'guix build
--source' would be unusable on non-Guix systems and likely also
unusable on Guix systems of another architecture.


There may be other reasons to add patches:

1. Functionality, that is not yet accepted upstream, because 
maintainer(s) do not have enough time to review all pull requests, or 
are simply slow to review. "if no response within X time from upstream, 
then guix may include your patch" might be a good policy here.


2. Bug fixes - as you mentioned - for such, it might be good with a: "if 
no response within X time from upstream, then guix may include your 
bug-fix patch".


3. Unmaintained projects - sometimes there are packages that are nice to 
include but which may no longer be maintained by upstream, and a few 
patches could still make the package usable and nice to have for Guix 
users. IMO such packages should generally be accepted, including minor 
patches that enhances the package. Examples would include guile-bash, 
and maybe emacs-company-tern (not in guix, but might be nice to have). 
There are probably more examples.


Im not a guix maintainer, so maintaining above varieties of patches 
might not be feasible, but there are potential benefits, like maybe guix 
is just "nicer" than other distros because of it. Or it might have the 
opposite effect if the maintenance burden is too high. Guix should 
spread more to mainstream IMO, and being able accept patches that are 
"nice", would benefit that purpose.


Best regards,
David

Re: [PATCH] doc: Update contribution guidelines on patches, etc.

[Maxime Devos]

Am Dienstag, dem 09.08.2022 um 18:45 +0200 schrieb Maxime Devos:

On 06-08-2022 08:55, Liliana Marie Prikler wrote:


+If your package has a bug that takes multiple lines to fix,

I don't think this is true for replacing all instances of "foo" by
"/gnu/store/.../bin/foo" in a file.

Should it?
I don't think so. Directly substituting all the instances instead of 
first writing a patch that does "foo" -> "@foo@" or such seems simpler 
to me.  This might be a bit too nit-picky though, maybe it's clear from 
context that this is not the kind of fix meant by that line.

+ Furthermore, as with patches, modifying the snippets causes two
derivations to be built.

This is true, but I don't think reviewers and package authors have to
worry about that.

It does make a difference to the author when debugging their package.
Starting with a phase and then moving it to a snippet can save good
time.
Hm, maybe, I guess I often work on 'small' packages where it doesn't 
matter much.


On 09-08-2022 19:05, Liliana Marie Prikler wrote:

+Such changes include, but are not limited to, fixes of the build
+script(s) or embeddings of store paths (e.g. [...])


[...]

Is that how to English comma?  Sorry, I'm not a native speaker so I get
somewhat weirded out by the when to skip/not to skip rules.

Neither am I. English doesn't seem to do "rules" much. I do think, 
however, that adding a comma after "to" makes things a bit simpler to 
read here, and it doesn't appear to be ungrammatical -- at least, in 
licenses "but is/are not limited to" is often used that way.



Derivations are a rather low-level concept, could they be avoided in
the origin and phases documentation?
I don't quite see how.  You could s/source derivation/the result of
@code{guix build -S}/, but I don't think that's much better.


To be clear, do you mean you:

 * think it's not better, maybe even worse
 * think it's not _much_ better (but still _slightly_ better)
 * are undecided
 * or something else

?

Also, "guix build -S" returns the source code (after snippet / patch, if 
any), not its derivation. For the latter: "guix build -S -d"



+Build phases are limited in that they do not modify the source
+derivation.  Thus, they are inadequate for changes that are to be
+reflected in the source code.  On the other hand, they only cause
a
+single rebuild and are thus slightly easier to debug than phases
and
+snippets.

See Andreas' comment on phase->snippet.

Also, do I understand correctly that the argument here is that
'single rebuild -> less compilation time -> easier to debug'?

Easier to debug for the package author currently fiddling with the
phase/snippet.  Not really a statement in any direction otherwise.
I don't see how "slightly easier to debug than phases" follows from 
"they cause only a single rebuild". My guess was that the intermediate 
step was lower compilation time, but apparently this was not the 
argument. As such, I'm not following.


Greetings,
Maxime.



OpenPGP_0x49E3EE22191725EE.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

Re: v2: A proposal of a consistent set of clear rules and guidelines involving snippets, phases and patches.

[Andreas Enge]

Am Tue, Aug 09, 2022 at 05:06:43PM +0200 schrieb Maxime Devos:
> WDYM with 'still' here? The v2 patch I sent preceded Liliana's patch.

I meant that I prefer it to your v1 patch, but still find it too verbose.

Andreas

Re: [PATCH] doc: Update contribution guidelines on patches, etc.

[Liliana Marie Prikler]

Am Dienstag, dem 09.08.2022 um 18:45 +0200 schrieb Maxime Devos:
> On 06-08-2022 08:55, Liliana Marie Prikler wrote:
> 
> > +If your package has a bug that takes multiple lines to fix,
> I don't think this is true for replacing all instances of "foo" by 
> "/gnu/store/.../bin/foo" in a file.
Should it?

> >   or a fix
> > +has already been accepted upstream, patches are the preferred way
> > of
> > +eliminating said bug
> > +Refer to the @code{origin} record documentation
> > +(particularly the fields @code{snippet} and @code{modules}), for
> > more
> > +information (@pxref{origin Reference}).
> > +
> 
> The "Refer to the ... documentation for more information" occurred in
> the old version of (guix)Snippets versus Phases. However, back then,
> I did not find more information on how to decide between snippets,
> patches and phases, and neither do I now.
> 
> Maybe:
> 
> +Refer to the @code{origin} record documentation
> +(@pxref{origin Reference}) (particularly the fields @code{snippet}
> and @code{modules})
> +for more information on how to use snippets
> 
> , to avoid a reader's assumption that that section contains
> information on deciding between snippets, phases and patches.
Yeah, this was meant for "how to use".

> > + Furthermore, as with patches, modifying the snippets causes two
> > derivations to be built.
> 
> This is true, but I don't think reviewers and package authors have to
> worry about that.
It does make a difference to the author when debugging their package. 
Starting with a phase and then moving it to a snippet can save good
time.

> > Such changes include, but are not limited to fixes of the
> > +build script(s) or embeddings of store paths (e.g. replacement of
> > +@file{/bin/sh} with @code{(search-input-file inputs "bin/sh")}).
> Include what? I think you need to close the subsentence here:
> 
> > +Such changes include, but are not limited to, fixes of the build
> > +script(s) or embeddings of store paths (e.g. [...])
> > 
> 
> [...]
Is that how to English comma?  Sorry, I'm not a native speaker so I get
somewhat weirded out by the when to skip/not to skip rules.

> > +Build phases are limited in that they do not modify the source
> > +derivation.  Thus, they are inadequate for changes that are to be
> > +reflected in the source code.  On the other hand, they only cause
> > a
> > +single rebuild and are thus slightly easier to debug than phases
> > and
> > +snippets.
> Derivations are a rather low-level concept, could they be avoided in
> the origin and phases documentation?
I don't quite see how.  You could s/source derivation/the result of
@code{guix build -S}/, but I don't think that's much better.

> > +Build phases are limited in that they do not modify the source
> > +derivation.  Thus, they are inadequate for changes that are to be
> > +reflected in the source code.  On the other hand, they only cause
> > a
> > +single rebuild and are thus slightly easier to debug than phases
> > and
> > +snippets.
> See Andreas' comment on phase->snippet.
> 
> Also, do I understand correctly that the argument here is that
> 'single rebuild -> less compilation time -> easier to debug'?
Easier to debug for the package author currently fiddling with the
phase/snippet.  Not really a statement in any direction otherwise.

Cheers

Re: “guix system container” script must run as root

[Ricardo Wurmus]

Ricardo Wurmus  writes:

> Hi Guix,
>
> I see that the container script generated by “guix system container”
> must be run as root.  Looking at “initialize-user-namespace” in (gnu
> build linux-container) there is conditional code to be executed only
> when running as an unprivileged user, namely writing to
> /proc/pid/setgroups.  This makes me think that this was originally meant
> to be usable without root privileges.
>
> Without root privileges write access to /proc/pid/* is denied.  The
> child process here is the result of issuing a clone syscall.
>
> Why can’t the parent process write to the child’s /proc/pid/* files?

“man 7 user_namespaces” explains what conditions must be met for a
parent process to write to /proc/childpid/uid_map.  There are many
conditions that could lead to EPERM.  It seems that writing to
/proc/pid/setgroups succeeds and only writing to uid_map and gid_map
fails.

The parent process should be able to write to these files at least
once; as the parent it should have the capabilities CAP_SETUID and
CAP_SETGID in the child process namespace.

-- 
Ricardo

Re: [PATCH] doc: Update contribution guidelines on patches, etc.

[Maxime Devos]

On 06-08-2022 08:55, Liliana Marie Prikler wrote:


+If your package has a bug that takes multiple lines to fix,
I don't think this is true for replacing all instances of "foo" by 
"/gnu/store/.../bin/foo" in a file.

  or a fix
+has already been accepted upstream, patches are the preferred way of
+eliminating said bug
+Refer to the @code{origin} record documentation
+(particularly the fields @code{snippet} and @code{modules}), for more
+information (@pxref{origin Reference}).
+


The "Refer to the ... documentation for more information" occurred in 
the old version of (guix)Snippets versus Phases. However, back then, I 
did not find more information on how to decide between snippets, patches 
and phases, and neither do I now.


Maybe:

+Refer to the @code{origin} record documentation
+(@pxref{origin Reference}) (particularly the fields @code{snippet} and 
@code{modules})
+for more information on how to use snippets

, to avoid a reader's assumption that that section contains information 
on deciding between snippets, phases and patches.



+ Furthermore, as with patches, modifying the snippets causes two derivations 
to be built.


This is true, but I don't think reviewers and package authors have to 
worry about that.



Such changes include, but are not limited to fixes of the
+build script(s) or embeddings of store paths (e.g. replacement of
+@file{/bin/sh} with @code{(search-input-file inputs "bin/sh")}).

Include what? I think you need to close the subsentence here:


+Such changes include, but are not limited to, fixes of the build
+script(s) or embeddings of store paths (e.g. [...])



[...]


+Build phases are limited in that they do not modify the source
+derivation.  Thus, they are inadequate for changes that are to be
+reflected in the source code.  On the other hand, they only cause a
+single rebuild and are thus slightly easier to debug than phases and
+snippets.
Derivations are a rather low-level concept, could they be avoided in the 
origin and phases documentation?



+Build phases are limited in that they do not modify the source
+derivation.  Thus, they are inadequate for changes that are to be
+reflected in the source code.  On the other hand, they only cause a
+single rebuild and are thus slightly easier to debug than phases and
+snippets.

See Andreas' comment on phase->snippet.

Also, do I understand correctly that the argument here is that 'single 
rebuild -> less compilation time -> easier to debug'?


Greetings,
Maxime.



OpenPGP_0x49E3EE22191725EE.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

Re: v2: A proposal of a consistent set of clear rules and guidelines involving snippets, phases and patches.

[Maxime Devos]

On 05-08-2022 18:59, bl...@reproduciblemedia.com wrote:

Hi Maxime,

Adding some basic grammatical corrections below:
I have read several proposed corrections, but most of them don't appear 
to be grammatical corrections but rather stylistic or about 
(non-grammar) clarity or contents.

August 5, 2022 1:59 PM, "Maxime Devos"  wrote:


Technical grammatical correction: the software that Guix "has" is that in the 
monorepo,
but it "distributes" many packages. Thus:
--8<---cut here---start->8---
* In principle, Guix only distributes free software; when the upstream source 
contains some
non-free software, it should be removed such that ‘guix build --source’ returns the 
"freed"
source code rather than the unmodified upstream source (see: 28.4.1 Software 
Freedom).
--8<---cut here---end--->8---

I consider the difference between referring to external source code by 
including a (snippet-sanitised) copy or downloading it from an URL + 
snippet-sanitising to be immaterial, except for space and I/O savings, 
so I consider "has" to include "distributes".


While "distributes" is more specific, I really meant "has" here -- 
gnu/packages/patches/... and gnu/packages/*.scm must be free too, even 
if it is was not a distributed package (more concretely, see the bits 
about patches failing to remove non-freeness).



[...]
* The source of the package needs to correspond to what is actually built 
(i.e., act as the
corresponding source), to fulfill our ethical and legal obligations.

The [i.e.] addendum above is redundant, its better worded as:
--8<---cut here---start->8---
* The source of a package must correspond to what is actually built (i.e., 
there must be
an explicit relation between source code and the result of its build for all 
builds),
to fulfill our ethical and legal obligations.
--8<---cut here---end--->8---


You write that the addendum is redundant, but then change the addendum 
by replacing a word in the addendum by a possible definition. I'm not 
following how that reduces redundancy, and it also appears to be 
contrary to the lack of verbosity that Andreas would like.



* It is convenient for the source derived from an origin to build on any system 
that the upstream
package supports.
* The source needs to actually work, not only on your Guix system but also for 
other systems; this
requires some care for substitutions involving store items and other 
architecture-specific changes.

* Sometimes, there is more than one way to do it. Let's go for the simplest 
one. Sometimes, which
tool is the simplest, is subjective, that's fine too.

I think would be more clearly worded as:
--8<---cut here---start->8---
* When presented with a variety of strategies for defining a package, choose 
whichever is simplest.
Sometimes this is subjective, which is also fine. What matters is that you 
prefer techniques that
are common within the community (i.e. patterns that appear throughout 
gnu/packages/...) and
are thus clearly legible for reviewers.
--8<---cut here---end--->8---


To be clear, this is to replace the third point (Sometimes, there's more 
than one way to do it, etc.), without removing the previous two?


I would not use combinations like 'presented with a variety of 
strategies' however, I don't think that leads to clarity. Also, the 
preferences of 'you' are not all that important here, it's what they 
choose for that's important even if it is not their preference. (Though 
the two coinciding would be ideal of course!) Maybe:


When there is more than one way to do something, choose whichever method is the 
simplest.
Sometimes this is subjective, which is also fine. What matters is that you use 
techniques that
are common within the community (i.e. patterns that appear throughout 
gnu/packages/...) and
are thus clearly legible for reviewers.


To make things more concrete and to resolve conflicts between the principles, a 
few cases have been
worked out:

To a newcomer (the target audience), the above may lead to confusion as to what 
wasn't already
concrete in the above descriptions, or what principles above come into 
conflict. There is a mild,
latent assumption that they are familiar with the Guix workflow, which should 
be avoided. Thus I
suggest:
--8<---cut here---start->8---
For the purpose of clarifying preferred practices and reducing friction in the 
review process
introduced by subjective variation, a few guidelines have been worked out:
--8<---cut here---end--->8---


I don't see how a fancy wording amounting to essentially the same thing 
would reduce confusion or avoid latent assumptions.


Anyway, I'm not seeing any assumption that they are already familiar 
with the Guix workflow -- the point of such 

“guix system container” script must run as root

[Ricardo Wurmus]

Hi Guix,

I see that the container script generated by “guix system container”
must be run as root.  Looking at “initialize-user-namespace” in (gnu
build linux-container) there is conditional code to be executed only
when running as an unprivileged user, namely writing to
/proc/pid/setgroups.  This makes me think that this was originally meant
to be usable without root privileges.

Without root privileges write access to /proc/pid/* is denied.  The
child process here is the result of issuing a clone syscall.

Why can’t the parent process write to the child’s /proc/pid/* files?
Why does the parent process need to do this at all?  Can’t the child
process take care of writing its /proc/self/uid_map?

-- 
Ricardo

Re: v2: A proposal of a consistent set of clear rules and guidelines involving snippets, phases and patches.

[Maxime Devos]

On 08-08-2022 23:51, Andreas Enge wrote:

Hello,

Am Fri, Aug 05, 2022 at 03:59:14PM +0200 schrieb Maxime Devos:

Here's a v2. I've changed the structure to something close to what Julien
proposed, it looks a lot better now to me!

thanks, it does! I still find it a bit too verbose compared to Liliana's
suggestion, which I would prefer as a starting point of the discussion.


WDYM with 'still' here? The v2 patch I sent preceded Liliana's patch.

I'm not seeing a 'too verbose'-ity or a difference in verbosity myself

---

Something I liked about Julien's proposed structure is:


[...] derive rules for specific cases, based on these principles:

How do I remove non-free software? -> snippet because …

How do I remove bundled libraries? -> snippet or phase because …

How do I fix a build issue? -> patch or snippet if this affects 
building from source, can also be a phase if the result of --sources 
can still build


A test issue?

…

This leaves some cases up to interpretation, but that's probably not 
so different from "it's not an absolute rule". It's also much clearer 
and quicker to figure out in which case you are. If not documented as 
a case, you can fall back to the general principles.
-- i.e., if I want to do $FOO, I could quickly find out how to do it.  
In the v2 I sent, this was reflected in the subsections, each subsection 
is a 'howto $FOO'. Whereas the patch Liliana sent is kind of the inverse 
-- each @item corresponds to a 'what can the method $FOO be used for'. 
Similarly, in the v1 I sent, I followed a similar structure (an item for 
patches, an item for snippets, an item for phases).


As such, the v2 I sent seems a better basis to me.

Greetings,
Maxime.



OpenPGP_0x49E3EE22191725EE.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature