Re: Proposal: Separate the guix repo

[Ryan Prior]

‐‐‐ Original Message ‐‐‐

On Sunday, January 16th, 2022 at 4:21 AM, Jacob Hrbek  
wrote:

> Currently it's taking me 1~4 hours (depending on the system without
>
> outsourcing the load on high performance system) to build the guix
>
> repository in order to be able to test the contribution and contribute

I have this issue too. Whether or not we split the repo, providing lightweight 
makefile targets that don't build everything would be great. I don't need to 
build all the localization stuff for every language regularly when I'm only 
going to be testing Guix in English, and so on with lots of tools I'm not 
necessarily testing.

Ryan

Re: GNU Shepherd config contribution

[jbranso]

Hey, Adam thanks for this submission!

I think it's great that you can give examples of shepherd services!  I don't 
really know 
much about how to define shepherd services.  Maybe you could teach me sometime.

Since, you are wanting to submit code, we recommend that you paste your code to
guix-patc...@gnu.org.

https://guix.gnu.org/manual/en/html_node/Submitting-Patches.html#Submitting-Patches

Where do you want your code snippets/documentation to go?  Do you want to add 
to the cookbook?

Or do you want to add to the manual?

Thanks,

Joshua

January 15, 2022 10:56 AM, "Adam Faiz"  wrote:

> Hello! I would like to contribute examples of Shepherd services, by sending 
> my Shepherd system
> configuration file that I use. Attached is the configuration file.
> 
> I hope this will help add more detailed examples to the GNU Shepherd manual.

Re: Proposal: Separate the guix repo

[Julien Lepiller]

You probably want "make make-packages-go" and similar targets (maybe also 
make-cli-go).

Le 16 janvier 2022 09:30:54 GMT+01:00, Ryan Prior  a 
écrit :
>‐‐‐ Original Message ‐‐‐
>
>On Sunday, January 16th, 2022 at 4:21 AM, Jacob Hrbek  
>wrote:
>
>> Currently it's taking me 1~4 hours (depending on the system without
>>
>> outsourcing the load on high performance system) to build the guix
>>
>> repository in order to be able to test the contribution and contribute
>
>I have this issue too. Whether or not we split the repo, providing lightweight 
>makefile targets that don't build everything would be great. I don't need to 
>build all the localization stuff for every language regularly when I'm only 
>going to be testing Guix in English, and so on with lots of tools I'm not 
>necessarily testing.
>
>Ryan
>

Re: Document /homeless-shelter?

[Matt]

  On Sun, 16 Jan 2022 00:20:49 -0500 Leo Famulari  
wrote 

 > It could be documented briefly in the manual section Build Environment
 > Setup.

How does this look?

>From 34fcd075efad1577aa139012c5d2fccf44e10058 Mon Sep 17 00:00:00 2001
From: Matt 
Date: Sun, 16 Jan 2022 12:30:37 -0500
Subject: [PATCH] Document /homeless-shelter

---
 doc/guix.texi | 13 +
 1 file changed, 13 insertions(+)

diff --git a/doc/guix.texi b/doc/guix.texi
index 42691570ff..fd48a0dcd2 100644
--- a/doc/guix.texi
+++ b/doc/guix.texi
@@ -1193,6 +1193,19 @@ environment variables for HTTP and HTTPS downloads it 
performs, be it
 for fixed-output derivations (@pxref{Derivations}) or for substitutes
 (@pxref{Substitutes}).
 
+The @env{HOME} environment variable is set to @file{/homeless-shelter}
+during the build process.  This ensures builds are determistic and
+highlights all uses of @env{HOME}.  Packages should not depend on the
+pathname of a home directory.  Instead, modify the build phase to set
+@env{HOME} to @file{/tmp}:
+
+@lisp
+(modify-phases %standard-phases
+  (add-before 'check 'fix-home-directory
+(lambda _
+  (setenv "HOME" "/tmp"
+@end lisp
+
 If you are installing Guix as an unprivileged user, it is still possible
 to run @command{guix-daemon} provided you pass @option{--disable-chroot}.
 However, build processes will not be isolated from one another, and not
-- 
2.34.0




0001-Document-homeless-shelter.patch
Description: Binary data

Re: Document /homeless-shelter?

[Maxime Devos]

Hi,

Matt schreef op zo 16-01-2022 om 12:38 [-0500]:
> +The @env{HOME} environment variable is set to @file{/homeless-shelter}
> +during the build process.  This ensures builds are determistic and
> +highlights all uses of @env{HOME}.  Packages should not depend on the
> +pathname of a home directory.  Instead, modify the build phase to set
> +@env{HOME} to @file{/tmp}:
> +
> +@lisp
> +(modify-phases %standard-phases
> +  (add-before 'check 'fix-home-directory
> +(lambda _
> +  (setenv "HOME" "/tmp"
> +@end lisp

Sometimes ‘hand-written, automake/cmake/... is bloat!’-style Makefiles
install things to $HOME in the 'install' target, maybe you could give
something like that as an example for when setting HOME to /tmp won't
work?

Greetings,
Maxime.


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

Re: Document /homeless-shelter?

[Leo Famulari]

On Sun, Jan 16, 2022 at 12:38:52PM -0500, Matt wrote:
> Subject: [PATCH] Document /homeless-shelter

I pushed a simpler addition to the manual:

https://git.savannah.gnu.org/cgit/guix.git/tree/doc/guix.texi#n1181

Of course I made a silly typo and so this change takes place over two
commits.

> +The @env{HOME} environment variable is set to @file{/homeless-shelter}
> +during the build process.  This ensures builds are determistic and
> +highlights all uses of @env{HOME}.  Packages should not depend on the
> +pathname of a home directory.  Instead, modify the build phase to set
> +@env{HOME} to @file{/tmp}:
> +
> +@lisp
> +(modify-phases %standard-phases
> +  (add-before 'check 'fix-home-directory
> +(lambda _
> +  (setenv "HOME" "/tmp"
> +@end lisp

This text is basically correct but we have to balance verbosity with
readability.

The important thing was to document /homeless-shelter, so that packagers
understand it comes from Guix, and to explain its rationale.

It's not 100% true that setting HOME=homeless-shelter ensures that
builds are deterministic and highlights all uses of $HOME, although it
does help with those goals.

I don't think we want to document the use of /tmp, or recommend it as an
authoritative workaround.

Rather, it's a common solution, but packagers must seek to understand
how the package build scripts are trying to use $HOME and make a
judgement.

Additionally, I don't think that Build Environment Setup is the right
place to document workarounds.

Re: Document /homeless-shelter?

[Leo Famulari]

On Sun, Jan 16, 2022 at 07:16:11PM +0100, Maxime Devos wrote:
> > +(modify-phases %standard-phases
> > +  (add-before 'check 'fix-home-directory
> > +(lambda _
> > +  (setenv "HOME" "/tmp"
> > +@end lisp
> 
> Sometimes ‘hand-written, automake/cmake/... is bloat!’-style Makefiles
> install things to $HOME in the 'install' target, maybe you could give
> something like that as an example for when setting HOME to /tmp won't
> work?

As I suggested in my reply (concurrent to yours), this use of /tmp is
not something we need to document authoritatively. Rather, packagers
have to make a judgement about how to handle package build scripts that
try using $HOME.


signature.asc
Description: PGP signature

Re: Document /homeless-shelter?

[Matt]

  On Sun, 16 Jan 2022 13:25:57 -0500 Leo Famulari  
wrote 
 > On Sun, Jan 16, 2022 at 12:38:52PM -0500, Matt wrote:
 > > Subject: [PATCH] Document /homeless-shelter
 > 
 > I pushed a simpler addition to the manual:
 > 
 > https://git.savannah.gnu.org/cgit/guix.git/tree/doc/guix.texi#n1181

That looks great. 

 > > +The @env{HOME} environment variable is set to @file{/homeless-shelter}
 > > +during the build process.  This ensures builds are determistic and
 > > +highlights all uses of @env{HOME}.  Packages should not depend on the
 > > +pathname of a home directory.  Instead, modify the build phase to set
 > > +@env{HOME} to @file{/tmp}:
 > > +
 > > +@lisp
 > > +(modify-phases %standard-phases
 > > +  (add-before 'check 'fix-home-directory
 > > +(lambda _
 > > +  (setenv "HOME" "/tmp"
 > > +@end lisp
 > 
 > This text is basically correct but we have to balance verbosity with
 > readability.
 > 
 > The important thing was to document /homeless-shelter, so that packagers
 > understand it comes from Guix, and to explain its rationale.
 > 
 > It's not 100% true that setting HOME=homeless-shelter ensures that
 > builds are deterministic and highlights all uses of $HOME, although it
 > does help with those goals.
 > 
 > I don't think we want to document the use of /tmp, or recommend it as an
 > authoritative workaround.
 > 
 > Rather, it's a common solution, but packagers must seek to understand
 > how the package build scripts are trying to use $HOME and make a
 > judgement.
 > 
 > Additionally, I don't think that Build Environment Setup is the right
 > place to document workarounds.
 
This all looks sound to me. Thanks for taking the time to work with me on this.

Preservation of Guix report 2022-01-16

[Timothy Sample]

Hi all,

I’ve published a new preservation of Guix report:

https://ngyro.com/pog-reports/latest/

Actually, the URL is , but I
thought having a way to reference the latest report would be helpful.

There’s no big news in the report.  I’ve tracked down a handful of ‘git’
and ‘text’ sources.  There are a few new ‘git’ sources missing from SWH.
Two of them are Mumi and guile-netlink, which both failed when I tried
to get SWH to visit them.

Mostly things look pretty good.  For commit 195bb1f from a week ago, we
have 85.8% coverage.  There are about 300 sources missing from SWH.
I’ve looked over the list, but there are no big obvious problems.  There
are a handful of Ruby “.gem” files, which I guess SWH skips when
visiting our “sources.json” (it probably only takes archives).  There
are some things that aren’t in “sources.json” (e.g., parts of IcedTea
like Shenandoah).  There are also some things that should be fine, but
aren’t in SWH anyway, like Guile Plotutils.  It’s a pretty normal
looking tarball listed in “sources.json”, but SWH doesn’t have it
(despite visiting “sources.json” yesterday).

A really important thing to do at this point is to verify that some
reasonable looking computation is covered by what we are doing already.
For instance, is every source used to build Guile (or Python or R)
preserved?  This will ensure that key sources are not missing, which is
a real possibility given that everything so far has been purely a
numbers game!


-- Tim

Re: 02/06: installer: Check if ci.guix.gnu.org can be reached.

[Ludovic Courtès]

Hi,

guix-comm...@gnu.org skribis:

> commit ee897e5f51104f41b3c2a0c2cbc7eb4e6c1e4d3e
> Author: Mathieu Othacehe 
> AuthorDate: Tue Dec 28 11:19:55 2021 +0100
>
> installer: Check if ci.guix.gnu.org can be reached.
> 
> * gnu/installer.scm (installer-program): Add gnutls extension.
> * gnu/installer/newt/network.scm (wait-service-online): Check if the CI 
> server
> can be reached.

[...]

> +  (define (ci-available?)
> +(dynamic-wind
> +  (lambda ()
> +(sigaction SIGALRM
> +  (lambda _ #f))
> +(alarm 3))
> +  (lambda ()
> +(false-if-exception
> + (= (response-code
> + (http-request "https://ci.guix.gnu.org";))
> +200)))

What about replacing the hard-coded URL with a reference to
‘%default-substitute-urls’?

Since it’s a list, we could check that at least one of the URLs in that
list is reachable.

Also, perhaps replace ‘http-request’ (which does GET by default) by
‘http-head’?

My 2¢,
Ludo’.

Re: GNU Shepherd config contribution

[Adam Faiz]

On 16/01/2022 16:41, jbra...@dismail.de wrote:

Hey, Adam thanks for this submission!

I think it's great that you can give examples of shepherd services!  I don't 
really know
much about how to define shepherd services.  Maybe you could teach me sometime.

Since, you are wanting to submit code, we recommend that you paste your code to
guix-patc...@gnu.org.

https://guix.gnu.org/manual/en/html_node/Submitting-Patches.html#Submitting-Patches

Where do you want your code snippets/documentation to go?  Do you want to add 
to the cookbook?

Or do you want to add to the manual?

Thanks,

Joshua


I think the code snippets should go in the "Service Examples" section of 
the GNU Shepherd manual.

Re: version-1.4.0 branch updated

[Chris Marusich]

Hi Maxim,

I've CC'd Mathieu on this email because he sent an email recently asking
for help with the 1.4.0 release, and Ludo because he was working on bug
52752.

Maxim Cournoyer  writes:

> Hi Maxime,
>
> Maxime Devos  writes:
>
>> Efraim Flashner schreef op di 11-01-2022 om 12:39 [+0200]:
>>> On Mon, Jan 10, 2022 at 02:57:09PM -0500, Maxim Cournoyer wrote:
>>> > If nobody has another world rebuilding change deemed necessary in time
>>> > for the release, I suggest we enable substitutes on the branch soon, and
>>> > then get busy trying to get 'make dist' to succeed so that we can issue
>>> > a first RC.
>>
>> The fix for a non-deterministic test suite failure in Guile:
>> https://issues.guix.gnu.org/48389#11
>
> That one slipped :-/.  Sorry!  I should have checked my emails more
> carefully before turning on the switch in Cuirass yesterday.

On aarch64-linux, on master, bug 52943 prevents the "guix" package from
building successfully.  I've committed a fix for this on the master
branch in commit 24c3485bb3ffc05e687ef6513ac287b8d3048bab.  However, I
haven't yet updated the "guix" package, since Ludo mentioned here that
he wanted to update the "guix" package to include a different fix (for
bug 52752), but I'm not sure that he's done that yet:

  https://issues.guix.gnu.org/52752#2

I figured we could coordinate and update the "guix" package at the right
time, all at once.

It would be good to ensure that the "guix" package builds successfully
on aarch64-linux for the 1.4.0 release.  Therefore, I'd like to get the
fix for 52943 included in the version-1.4.0 branch, but I don't want to
step on anyone's toes.  What can I do to get the fix included in the
release?

-- 
Chris

PGP: https://savannah.gnu.org/people/viewgpg.php?user_id=106836


signature.asc
Description: PGP signature

Re: GNU Shepherd config contribution

[jbranso]

January 16, 2022 8:06 PM, "Adam Faiz"  wrote:

> On 16/01/2022 16:41, jbra...@dismail.de wrote:
> 
>> Hey, Adam thanks for this submission!
>> I think it's great that you can give examples of shepherd services! I don't 
>> really know
>> much about how to define shepherd services. Maybe you could teach me 
>> sometime.
>> Since, you are wanting to submit code, we recommend that you paste your code 
>> to
>> guix-patc...@gnu.org.
>> https://guix.gnu.org/manual/en/html_node/Submitting-Patches.html#Submitting-Patches
>> Where do you want your code snippets/documentation to go? Do you want to add 
>> to the cookbook?
>> Or do you want to add to the manual?
>> Thanks,
>> Joshua
> 
> I think the code snippets should go in the "Service Examples" section of the 
> GNU Shepherd manual.

Sounds like a plan.  I encourage you to send a git patch to 
guix-patc...@gnu.org.

You can also see me do some documentation things for guix here:

https://video.hardlimit.com/w/p/1QcKYmwsbAptwmizJDsxSD?playlistPosition=27&resume=true

This is a good guide for how to use git send-email.

https://git-send-email.io/