Re: Welcome to our new committer!

[Andrew Tropin]

On 2022-08-05 23:07, Tobias Geerinckx-Rice wrote:

> Hi Andrew,
>
> A big fat welcome from me as well.

Yay!)

>
> Savannah UI being what it is, I'm almost completely certain that I
> managed to make you a member of the ‘GNU Guix’ organisation there. 
> You should be able to push to the Git repository.

Thank you, I see myself in the group and as you probably already know
can push :)

>
> For my own future reference: did you get any automated mails about
> that from Savannah?
>

No automated emails recieved.

-- 
Best regards,
Andrew Tropin


signature.asc
Description: PGP signature

Tempel snippets

[Development of GNU Guix and the GNU System distribution.]

Hi guix!

I'm translating the snippets used in the snippets dir so that we can
provide an alternative (here tempel) for snippets in the Perfect Setup.
I have two practical questions about where to put that code.

1) For reproducible development purposes (e.g. rde), it would
be great to have snippets shipped with guix itself (the snippets
directory is not in the store of the guix package), or alternatively in
a package, instead of in a possibly moving directory. WDYT? Which
alternative is the best?

2) Where should I add tempel-ready snippets? The etc/snippets dir can't
be used directly because it's the one used by yasnippet. Or in the
option of packages, I can rather make one.

3) I'll send a first series with basic working templates, but in the
process have seen that there may be some refactoring / snippets
improvements, but I'm not yet emacs-fluent enough to get that done
easily. Will probably send a mail with the series with some ideas for
refactoring and where I'm stuck. Also I think that we can add a snippet
for license: completion, include an alternative snippet for copyright
(since we must be at the right spot to insert anyway), and have an
option to compute base32 hash during template completion (if possible,
I'll see what I can do).

-- 
Best regards,
Nicolas Graves

Re: GitLab to plans to delete dormant projects

[John Kehayias]

Hi all,

--- Original Message ---
On Saturday, August 6th, 2022 at 9:08 AM, Olivier Dion via "Development of GNU 
Guix and the GNU System distribution."  wrote:

>
>
> Hi,
>
> Following this article https://lwn.net/Articles/903858/, GitLab is
> planning to start deleting project that were idle for > 12 months.
>
> Many packages origin in Guix use an url to a GitLab project. What are
> the consequence of such deletion on Guix reproducibility? Will it
> affects the time-machine?
>

I think having good backup and archival plans are great, so not to dissuade 
anyone on this, but as an update here looks like GitLab has walked back on this:

https://www.theregister.com/2022/08/05/gitlab_reverses_deletion_policy/

John

Idea: fallback for guix pull?

[Christopher Rodriguez]

I haven't looked at the code at all, but perhaps it would be useful to
users of Guix if, upon a guix pull with a commit that fails to
authenticate, guix pull would still pull up to the last in the chain of
successfully authenticated commmits?

Right now, it stops the entire operation if one commit from one channel
fails to authenticate, which has value (and might be useful as a setting
or flag, for those with greater security concerns or those maintaining
the channel).

But assuming the authentications are done in order, could we make the
default an effective "pin" to the last authenticated commit? This is
probably the way users /should/ deal with this kind of issue anyway
(disable-authentication is worrisome), and having the default be this
kind of fallback would make it so users are still able to pull other
channels they might have, or at least update to the last "good" commit.

What do You think?

--

Christopher Rodriguez


signature.asc
Description: PGP signature

Re: FSDG issues of SCUMMVM-based games

[Liliana Marie Prikler]

Am Samstag, dem 06.08.2022 um 17:24 +0200 schrieb Maxime Devos:
> On 06-08-2022 06:59, Liliana Marie Prikler wrote:
> 
> > 2. The "sources" consist of binaries that are installed as-is.
> 
> The credits of ScummVM state that the source code is available for 
> Drascula[0]
> 
> [0] https://docs.scummvm.org/en/latest/help/credits.html: Emilio de Paz
> Aragón from Alcachofa Soft for sharing the source code of Drascula:
> The Vampire Strikes Back with us and his generosity with freewaring the
> game.
> 
> Maybe that only covered the engine and not the game bytecode though
While that does mean that ScummVM folks have the source, it is not what
they distribute:

Archive:  /gnu/store/wn9043a134dai59shxss6byrlfj2pp9x-drascula-1.0.zip
  Length  DateTimeName
-  -- -   
 32847563  05-11-2008 08:38   Packet.001
46080  05-11-2008 08:38   drascula.doc
 2871  08-31-2008 03:29   readme.txt
- ---
 32896514 3 files

Also note the difference between freeware and free software.

Cheers

Re: FSDG issues of SCUMMVM-based games

[Maxime Devos]

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


2. The "sources" consist of binaries that are installed as-is.


The credits of ScummVM state that the source code is available for 
Drascula[0]


[0] https://docs.scummvm.org/en/latest/help/credits.html: Emilio de Paz 
Aragón from Alcachofa Soft for sharing the source code of Drascula: The 
Vampire Strikes Back with us and his generosity with freewaring the game.


Maybe that only covered the engine and not the game bytecode though ...

I don't think bytecode falls under the 'non-functional data' exception 
of the FSDG, because code (the sprites, backgrounds and sound are 
another matter).


As such, I agree they should not be distributed (unless the actual 
sources are found, but even then there is (1.)), as per the first 
sentence of ‘(guix)GNU Distribution’.


Greetings,
Maxime.


OpenPGP_0x49E3EE22191725EE.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

Re: GitLab to plans to delete dormant projects

[Development of GNU Guix and the GNU System distribution.]

On Sat, 06 Aug 2022, Julien Lepiller  wrote:
> Our build farms need those sources, so they keep them in cache. If you
> need a source, you can always substitute from the build farms if the
> origin disappeared (that's actually the default and you don't even
> need to trust the build farm for that to work).

Does the cache as a time to live?  For example, would a source from 2020 in
20 years still be available on the build farms?  Or would the build
farms make a request to Software Heritage?

> Another fallback option when substitution is not possible is to get
> the source from Software Heritage. They keep an archive of almost
> everything. To do that, they have listers that help tgem find sources
> fsom different sesvices. They have a lister for GitLab, and even one
> for Guix. Also, as part of guix lint, a request is sert to swh if the
> oriqin is not yet archived.
>
> Hopefully that means our origins are saved by Software Heritage, so we
> can transparently fall back to them.

Okay great then.  Maybe it would be a good idea to test this by
simulating the deletion of a Gitlab repo.  Better find it out now than
when it's too late.

-- 
Olivier Dion
oldiob.dev

Re: FSDG issues of SCUMMVM-based games

[Tobias Geerinckx-Rice]

I've sent an e-mail to the FSF licencing department asking for 
their guidance on the matter.  I erred on the side of netiquette 
caution and didn't CC this list.


Either the inclusion of [a subset of] Drascula in Trisquel[0] is a 
similar oversight, or we're missing some legal subtlety.


I'm hoping for the latter, as I'd hate to see old art become less 
accessible.


Kind regards,

T G-R

[0]: https://packages.trisquel.info/hu/nabia/all/drascula/filelist


signature.asc
Description: PGP signature

Re: GitLab to plans to delete dormant projects

[Julien Lepiller]

Our build farms need those sources, so they keep them in cache. If you need a 
source, you can always substitute from the build farms if the origin 
disappeared (that's actually the default and you don't even need to trust the 
build farm for that to work).

Another fallback option when substitution is not possible is to get the source 
from Software Heritage. They keep an archive of almost everything. To do that, 
they have listers that help tgem find sources fsom different sesvices. They 
have a lister for GitLab, and even one for Guix. Also, as part of guix lint, a 
request is sert to swh if the oriqin is not yet archived.

Hopefully that means our origins are saved by Software Heritage, so we can 
transparently fall back to them.

Le 6 août 2022 15:08:21 GMT+02:00, "Olivier Dion via Development of GNU Guix 
and the GNU System distribution."  a écrit :
>Hi,
>
>Following this article , GitLab is
>planning to start deleting project that were idle for > 12 months.
>
>Many packages origin in Guix use an url to a GitLab project.  What are
>the consequence of such deletion on Guix reproducibility?  Will it
>affects the time-machine?
>
>-- 
>Olivier Dion
>oldiob.dev
>
>

Re: GitLab to plans to delete dormant projects

[Maxime Devos]

On 06-08-2022 15:08, Olivier Dion via Development of GNU Guix and the 
GNU System distribution. wrote:

Hi,

Following this article, GitLab is
planning to start deleting project that were idle for > 12 months.

Many packages origin in Guix use an url to a GitLab project.  What are
the consequence of such deletion on Guix reproducibility?  Will it
affects the time-machine?


software heritage should avoid some problems, but from what I've heard 
it doesn't support all edge cases yet (something about recursive 
checkouts?).


I think it would be a good idea to make some Guile script to find all 
GitLab git checkouts in Guix and run the swh linter on them to make sure 
they are archived.


Additionally, it would be nice to support multiple URLs as fallbacks in 
the 'origin' record for git-fetch (like we have for url-fetch) to avoid 
the three points of failures (SWH and the copy at the substitute 
servers) in the fallback mechanism.


Greetings,
Maxime.



OpenPGP_0x49E3EE22191725EE.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

Re: Welcome to our new committer!

[jgart]

Congrats Andrew, make yourself at home ;()

all best,

jgart

Re: Texinfo, Free Beer

[Ekaitz Zarraga]

Hi,

--- Original Message ---
On Saturday, August 6th, 2022 at 3:30 PM, jgart  wrote:


> Hi Guixers,
>
> wdyt of having some modern TLDR entry in the cookbook for getting Guix 
> neophytes up to par with texinfo?
>
> Since texinfo is the defacto markup for the GNU Guix project and we're not 
> likely to change it any time soon,
> I was think we could have some distilled/TLDR docs for users who mostly write 
> and consume markdown.
>
> I was thinking something along the lines of what chicken has for rubyists or 
> pythonistas:
>
> https://wiki.call-cc.org/chicken-for-ruby-programmers
> https://wiki.call-cc.org/chicken-for-python-programmers
>
> "Texinfo for MDs"
>
> roptat started a TLDR Texinfo guide on the learnxinyminutes series*.
>
> Should we just improve on roptat's guide and link it in a Guix doc somewhere 
> so
> that it is more discoverable or integrate/fork it or similar into our docs?
>
> Same way we have a Scheme crash course, we can have a Texinfo crash course?


I could use that!

Texinfo, Free Beer

[jgart]

Hi Guixers,

wdyt of having some modern TLDR entry in the cookbook for getting Guix 
neophytes up to par with texinfo?

Since texinfo is the defacto markup for the GNU Guix project and we're not 
likely to change it any time soon, 
I was think we could have some distilled/TLDR docs for users who mostly write 
and consume markdown.

I was thinking something along the lines of what chicken has for rubyists or 
pythonistas:

https://wiki.call-cc.org/chicken-for-ruby-programmers
https://wiki.call-cc.org/chicken-for-python-programmers

"Texinfo for MDs"

roptat started a TLDR Texinfo guide on the learnxinyminutes series*.

Should we just improve on roptat's guide and link it in a Guix doc somewhere so
that it is more discoverable or integrate/fork it or similar into our docs?

Same way we have a Scheme crash course, we can have a Texinfo crash course?

It would be worth it since Texinfo seems more complex than Scheme from
a syntactic perspective and our new documentation contributors could
benefit from a crash course in Texinfo.

I think the GNU docs for texinfo are TMI for a new user just wanting to write 
some Guix docs for great good.

Another option could be to integrate guile-commonmark** into Guix so that
we could support markdown in addition to Texinfo? Please don't boo and
throw free beer at the stage.

Nix used to mostly have their docs in docbook but now they support
markdown and their users are much happier***

--
jgart

* https://learnxinyminutes.com/docs/texinfo/
** https://github.com/OrangeShark/guile-commonmark
*** https://invidious.osi.kr/watch?v=WwgSMgpX6TM

GitLab to plans to delete dormant projects

[Development of GNU Guix and the GNU System distribution.]

Hi,

Following this article , GitLab is
planning to start deleting project that were idle for > 12 months.

Many packages origin in Guix use an url to a GitLab project.  What are
the consequence of such deletion on Guix reproducibility?  Will it
affects the time-machine?

-- 
Olivier Dion
oldiob.dev

Re: Welcome to our new committer!

[Lars-Dominik Braun]

Hello Andrew,

> The Guix Maintainer Collective (tm) would like to welcome Andrew Tropin,
> aka abcdw, as our newest committer! I'm sure many of you recognize them
> from their work on Guix Home and their regular videos hacking on Guix,
> among other things.
welcome! Good to have you here as a committer!

Cheers,
Lars

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

[Liliana Marie Prikler]

* doc/contributing.texi ("Snippets versus Phases"): Replaced with...
("Modifying Sources"): ... this.  List more use cases and some principles.
---
 doc/contributing.texi | 85 ---
 1 file changed, 72 insertions(+), 13 deletions(-)

diff --git a/doc/contributing.texi b/doc/contributing.texi
index 02c7c5ae59..7a03715abf 100644
--- a/doc/contributing.texi
+++ b/doc/contributing.texi
@@ -441,7 +441,7 @@ needed is to review and apply the patch.
 * Package Naming::  What's in a name?
 * Version Numbers:: When the name is not enough.
 * Synopses and Descriptions::   Helping users find the right package.
-* Snippets versus Phases::  Whether to use a snippet, or a build phase.
+* Modifying Sources::   When to use patches, snippets, or build phases.
 * Emacs Packages::  Your Elisp fix.
 * Python Modules::  A touch of British comedy.
 * Perl Modules::Little pearls.
@@ -698,20 +698,79 @@ Gettext}):
 for the X11 resize-and-rotate (RandR) extension. @dots{}")
 @end lisp
 
-@node Snippets versus Phases
-@subsection Snippets versus Phases
+@node Modifying Sources
+@subsection Modifying Sources
 
+@cindex patches, when to use
 @cindex snippets, when to use
-The boundary between using an origin snippet versus a build phase to
-modify the sources of a package can be elusive.  Origin snippets are
-typically used to remove unwanted files such as bundled libraries,
-nonfree sources, or to apply simple substitutions.  The source derived
-from an origin should produce a source that can be used to build the
-package on any system that the upstream package supports (i.e., act as
-the corresponding source).  In particular, origin snippets must not
-embed store items in the sources; such patching should rather be done
-using build phases.  Refer to the @code{origin} record documentation for
-more information (@pxref{origin Reference}).
+
+Guix has three main ways of modifying the source code of a package,
+that you as a packager may use.  Each one has its strengths and
+drawbacks, along with intended and historically derived use cases.
+These are
+
+@table @asis
+
+@item patches
+If your package has a bug that takes multiple lines to fix, 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{patches}, @code{patch-inputs}, and
+@code{patch-flags}) for more information (@pxref{origin Reference}).
+When adding a patch, do not forget to also list it in
+@code{dist_patch_DATA} of @file{gnu/local.mk}
+
+Patches are limited in that they lack the expressiveness of Guile.
+If all changes are constrained to single lines, a patch might be much
+larger than the equivalent @code{substitute*}.  Furthermore, building
+a package with an additional patch causes two new derivations to be
+built: First the source, then the package.
+
+@item snippets
+If your package contains non-free sources, these need to be removed
+through a snippet.  This snippet should not only remove the sources in
+question, but also references to the removed sources in build scripts,
+documentation, and so on. @ref{Software Freedom}
+
+If your package bundles external libraries, snippets are the preferred
+way of removing said them.  Unlike with non-free sources, it is not a
+requirement to remove @emph{all} bundled libraries, although doing so
+is very much preferred.  Bundled libraries that are kept should be
+clearly indicated, preferrably with a reason as to why the bundled copy
+remains.  As with non-free sources, references to the removed libraries
+should also be updated in the snippet.
+
+Refer to the @code{origin} record documentation
+(particularly the fields @code{snippet} and @code{modules}), for more
+information (@pxref{origin Reference}).
+
+Snippets are limited in that @code{substitute*} can not deal with
+multi-line changes well.  Furthermore, as with patches, modifying the
+snippets causes two derivations to be built.
+
+@item build phases
+For modifications that retain the intended functionality of the
+package, build phases (usually between @code{unpack} and
+@code{configure}, sometimes between @code{configure} and @code{build})
+can be used.  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")}).
+
+If you need to embed a store path, do so only inside a build phase.
+A workaround for patches that span multiple lines, is to use a variable
+such as @code{@@store_path@@} inside the patch and substitute the actual
+store path at build time via @code{substitute*}.
+
+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 th