Re: guix import doesn't like newlines anymore :(

[jgart]

On Mon, 10 Oct 2022 17:27:50 +0200 Ludovic Courtès  wrote:
> I’ll push a fix shortly.

Cool! Thanks!

all best,

jgart

Re: substitute derivation: also substitute grafts?

[Ricardo Wurmus]

zimoun  writes:

> Hi Ludo,
>
> On Mon, 10 Oct 2022 at 17:32, Ludovic Courtès  wrote:
>
>> This has to be compared with the cost of a rebuild/redownload of the
>> same set of packages.  Even in the worst case, grafts are faster than
>> that.  Now, the difference is that those grafts need to be recomputed
>> regularly, where the rebuild/redownload would be relatively rare.
>
> I have not done some stats, indeed. :-)
>
> The build/download or rebuild/redownload is really faster (at least
> for some R packages) than the graft part for some machines with
> spinning disks.  Well, I have been enough annoyed for some packages on
> that machine to end by systematically run the '--no-grafts' option for
> all packages. :-/

I’m not worried about grafts as such; I only think it’s a pity to have
grafts recomputed on machines on the very same network.  When I have a
direct link from one machine to another it is very fast to just copy
things over instead of performing the graft locally.

This is not something that can be decided generally.  When substituting
from a remote server it’s probably the right thing to compute the graft
locally, but there are a number of cases where that’s not a good idea
(e.g. machines on the same network, underpowered aarch64 machines
downloading substitutes from a faster machine, etc).

-- 
Ricardo

Re: Small change request to the manual page "Building from Git"

[zimoun]

Hi,

On lun., 10 oct. 2022 at 18:18, Mehmet Tekman  wrote:

> If "guix shell -D guix --pure" is included in the new version of the
> manual, then I'm more than happy to drop my suggestion.

You can find here the last version of the manual:

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

Moreover, Guix also includes a local copy at 
$HOME/.config/guix/current/share/info/
and using an info reader, it should be configured by default, i.e.,

info guix

displays the version of the manual for your current revision of Guix.


Hope that helps,
simon

Re: 01/03: guix-install.sh: Improve prompt_yes_no procedure.

[zimoun]

Hi,

On lun., 10 oct. 2022 at 17:44, Lars-Dominik Braun  wrote:

> I got a report here[1] that this refactoring broke my GitHub action,
> which simply pipes `yes` into guix-install.sh. Thus all pipelines
> depending on https://github.com/PromyLOPh/guix-install-action are (again)
> broken. Shall we revert this or do you have a quick fix at hand?

Oh, indeed.  I was expected that

bash -c 'yes | bash guix-install.sh'

would still work with ’_flush’.  Hum, why does it pass for
’chk_gpg_keyring’ and then not for ’configure_substitute_discovery’
called by ’sys_enable_guix_daemon’?


Cheers,
simon

Re: Small change request to the manual page "Building from Git"

[Mehmet Tekman]

Oh right - then yes mentioning "guix git authenticate" outside of the
environment as a small note should be enough, I think.

Re: Small change request to the manual page "Building from Git"

[Mehmet Tekman]

Sorry for the message duplication, it's the default with my email provider.

If "guix shell -D guix --pure" is included in the new version of the
manual, then I'm more than happy to drop my suggestion.
Thanks for the extra context, and the general tips!

Best,
Mehmet

Re: Small change request to the manual page "Building from Git"

[Maxime Devos]

On 10-10-2022 18:18, Mehmet Tekman wrote:

Sorry for the message duplication, it's the default with my email provider.

If "guix shell -D guix --pure" is included in the new version of the
manual, then I'm more than happy to drop my suggestion.
Thanks for the extra context, and the general tips!


If you do "guix shell -D guix --pure", you are using --pure, and 
consequently "guix git authenticate" and "make authenticate" will fail, 
contrary to what you seem to want.


My proposal was:


I suppose removing --pure (from the manual) might solve this problem.
However, --pure appears to have been added for a reason
(commit 43ec98ef3025f67ff4f66b7da0bcb79a6f088042), so I expect the solution is to rephrase things somehow (maybe something about running "guix git authenticate" outside "guix shell -D guix"). 


Greetings,
Maxime.


OpenPGP_0x49E3EE22191725EE.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

Re: Small change request to the manual page "Building from Git"

[Maxime Devos]

On 10-10-2022 16:18, Mehmet Tekman wrote:

Hello,


Try "guix environment guix --pure guix" or "guix shell guix -D guix" instead.


Yes I understand, but the manual states that:


The following command starts a new shell **where all the dependencies and 
appropriate environment variables are set up to hack on Guix**:
guix environment guix --pure


You are reading an old version of the manual, the latest version 
mentions "guix shell -D guix --pure".



This gives the impression that everything needed for `make
authenticate' to work is included in the above command (and I guess it
would be on the native distro).


> I think a small sentence mentioning the extra Guix dependency for
> non-native users isn't completely unwarranted, or perhaps maybe a hint
> in the linked "invoking guix environment" page?

As I wrote previously, foreign system / Guix System makes no difference 
-- in both cases, --pure changes the PATH, and not doing --pure should 
get you the 'guix' from ~/.guix-profile/bin/guix if Guix is set up

previously.

I suppose removing --pure (from the manual) might solve this problem.
However, --pure appears to have been added for a reason
(commit 43ec98ef3025f67ff4f66b7da0bcb79a6f088042), so I expect the 
solution is to rephrase things somehow (maybe something about running 
"guix git authenticate" outside "guix shell -D guix").

On Sun, 9 Oct 2022 at 11:08, Maxime Devos  wrote:

> [lots of text]

You seemed to have duplicated the previous mail here, but most e-mail 
clients keep the previous mails available, so there's no need.  Not 
top-posting also saves a little time for the reader.


Greetings,
Maxime;.


OpenPGP_0x49E3EE22191725EE.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

Re: Advanced network configuration

[Julien Lepiller]

Le 10 octobre 2022 17:17:16 GMT+02:00, "Ludovic Courtès"  a écrit 
:
>Hi!
>
>Alexey Abramov  skribis:
>
>[...]
>
>>> I’m not sure.  IIUC, a “networking target” here could translate to a
>>> Shepherd service that depends on all the relevant DHCP and static
>>> networking services.  The question the becomes how to express that
>>> grouping conveniently.
>>
>> Yes, I also would like to point out that their must be a way to
>> establish a firewall, for example, *before* any network interface is up
>> (After=network-pre.target in systemd [1]). And the same thing during the
>> shutdown procedure (Before=network-pre.target in systemd).
>
>I would do that by having ‘networking’ depend on ‘firewall’ (say).
>
>Does that make sense?

Wouldn't there be an issue if firewall rules reference interfaces created by 
the networking service?

>
>It’d be interesting to see whether we need something beyond this.
>

Re: substitute derivation: also substitute grafts?

[zimoun]

Hi Ludo,

On Mon, 10 Oct 2022 at 17:32, Ludovic Courtès  wrote:

> This has to be compared with the cost of a rebuild/redownload of the
> same set of packages.  Even in the worst case, grafts are faster than
> that.  Now, the difference is that those grafts need to be recomputed
> regularly, where the rebuild/redownload would be relatively rare.

I have not done some stats, indeed. :-)

The build/download or rebuild/redownload is really faster (at least
for some R packages) than the graft part for some machines with
spinning disks.  Well, I have been enough annoyed for some packages on
that machine to end by systematically run the '--no-grafts' option for
all packages. :-/

Cheers,
simon

Re: 01/03: guix-install.sh: Improve prompt_yes_no procedure.

[Lars-Dominik Braun]

Hi Maxim,

> commit 6a2e303d3a49baf7c222a70b91f453e9efd456c6
> Author: Maxim Cournoyer 
> AuthorDate: Wed Oct 5 21:48:25 2022 -0400
> 
> guix-install.sh: Improve prompt_yes_no procedure.
> 
> * etc/guix-install.sh (_flush): New function.
> (prompt_yes_no): Clear input, then only read the first character, 
> silently.
> Add the [Yes/no] string to the message.  When a newline is entered by the
> user, treat it as the default value, which is "yes".
> (chk_gpg_keyring): Remove "(yes/no)" from the prompt message.
> (configure_substitute_discovery): Likewise.
> (sys_authorize_build_farms): Likewise.
I got a report here[1] that this refactoring broke my GitHub action,
which simply pipes `yes` into guix-install.sh. Thus all pipelines
depending on https://github.com/PromyLOPh/guix-install-action are (again)
broken. Shall we revert this or do you have a quick fix at hand?

Lars

[1] https://github.com/PromyLOPh/guix-install-action/issues/16

Re: substitute derivation: also substitute grafts?

[Ludovic Courtès]

Hi,

zimoun  skribis:

> On Wed, 05 Oct 2022 at 12:03, Ludovic Courtès  wrote:

[...]

>> An is it too expensive for that machine to build grafts locally?
>
> Using my old desktop from work, yes the experience is really poor;
> especially for some packages where the number of grafts is sometimes
> something, e.g., see [1] where grafting were longer than building.
>
> 1: 

This has to be compared with the cost of a rebuild/redownload of the
same set of packages.  Even in the worst case, grafts are faster than
that.  Now, the difference is that those grafts need to be recomputed
regularly, where the rebuild/redownload would be relatively rare.

It’s a tradeoff.  We could have machinery to help determine when to
ungraft and perhaps even automate ungrafting.

Mark H Weaver  skribis:

> I wonder how fast grafting could be if it were rewritten in C.

I’d expect it to be I/O-bound, so maybe not that much?

Thanks,
Ludo’.

Re: guix import doesn't like newlines anymore :(

[Ludovic Courtès]

Hi,

zimoun  skribis:

> On jeu., 15 sept. 2022 at 19:10, jgart  wrote:
>> Hi does anyone know why guix import does not insert newlines anymore?
>
> You mean this,
>
> (define-public rust-snafu-0.7
>
> [...]
>
> (license (list license:expat license:asl2.0
> (define-public rust-lexiclean-0.0.1

That has to do with commit 371a83b764c4993d198666e1674454eecbefcdf1.

I’ll push a fix shortly.

Thanks,
Ludo’.

Re: Advanced network configuration

[Ludovic Courtès]

Hi!

Alexey Abramov  skribis:

[...]

>> I’m not sure.  IIUC, a “networking target” here could translate to a
>> Shepherd service that depends on all the relevant DHCP and static
>> networking services.  The question the becomes how to express that
>> grouping conveniently.
>
> Yes, I also would like to point out that their must be a way to
> establish a firewall, for example, *before* any network interface is up
> (After=network-pre.target in systemd [1]). And the same thing during the
> shutdown procedure (Before=network-pre.target in systemd).

I would do that by having ‘networking’ depend on ‘firewall’ (say).

Does that make sense?

It’d be interesting to see whether we need something beyond this.

> Applications have to be able to gracefully shutdown their network
> connections.  Is it the case right now, I don't know?

What do you mean?

> I am checking (shepherd services) where `shutdown-services' defined, and
> seems like it just walks across %services hash table. Am I missing
> something?

Correct, there’s nothing fancy going on there.

Thanks,
Ludo’.

Re: Small change request to the manual page "Building from Git"

[Mehmet Tekman]

Hello,

> Try "guix environment guix --pure guix" or "guix shell guix -D guix" instead.

Yes I understand, but the manual states that:

> The following command starts a new shell **where all the dependencies and 
> appropriate environment variables are set up to hack on Guix**:
> guix environment guix --pure

This gives the impression that everything needed for `make
authenticate' to work is included in the above command (and I guess it
would be on the native distro).

I think a small sentence mentioning the extra Guix dependency for
non-native users isn't completely unwarranted, or perhaps maybe a hint
in the linked "invoking guix environment" page?

> Despite the name on Reddit, the name is Guix, not GUIX.

Noted, thank you

> Also, assuming you have installed the Guix daemon with your foreign distro's 
> package manager, this is a bug in the foreign distro's packaging, see 
>  in case of Debian.
> You could ask your distro to do a similar fix.

Thanks, I'll report this to the package maintainer!

Best,
Mehmet



On Sun, 9 Oct 2022 at 11:08, Maxime Devos  wrote:
>
> On 06-10-2022 15:35, Mehmet Tekman wrote:
> > Hi there,
> >
> > I'd like to request some small changes be made on this page:
> >  > https://guix.gnu.org/manual/en/html_node/Building-from-Git.html
> > 
> >
> > 1. Authenticating on a foreign distro
> >
> > When at the "make authenticate" stage of the build process on a foreign
> > distro, this fails because it cannot find guix.
> > I think it's because the `guix environment guix --pure' command doesn't
> > include it, or obscures its path.
> >
> > As a workaround, I ran `PATH=/usr/local/bin/:$PATH make authenticate'
>
> "guix environment guix" only includes the dependencies of guix, not Guix
> itself.  Try "guix environment guix --pure guix" or "guix shell guix -D
> guix" instead.
>
> "guix environment guix --pure" does indeed 'obscure its path' -- that's
> what --pure is for, if you don't want that, don't include --pure.
>
> Both of these are independent of whether you are on a foreign distro or
> Guix System.
>
> > 2. Easy fix for failing `make check' tests
> >
> > I had a few failing tests on my foreign distro relating to setting locales.
> > Digging around led me to this reddit thread for the solution:
> >> https://old.reddit.com/r/GUIX/comments/jpq1uw/bashminimal507binbash_warning_setlocale_lc_all/
> >
> > Here they suggest running `sudo guix install glibc-locales` instead of as a 
> > user.
> > Maybe this should be mentioned, since I'm not the only one coming to GUIX 
> > from another distro.
>
> Despite the name on Reddit, the name is Guix, not GUIX.
>
> Also, assuming you have installed the Guix daemon with your foreign
> distro's package manager, this is a bug in the foreign distro's
> packaging, see
>  in case of
> Debian.  You could ask your distro to do a similar fix.
>
> Greetings,
> Maxime.

Re: Planning for a release, for real

[zimoun]

Hi,

On jeu., 06 oct. 2022 at 16:50, Ludovic Courtès  wrote:

>   • Update NEWS (mostly done already!), prepare a blog post listing the
> highlights and linking to the relevant material.  (See
>  for inspiration.)

Just a reminder about ’guix environment’:

--8<---cut here---start->8---
@quotation Deprecation warning
The @command{guix environment} command is deprecated in favor of
@command{guix shell}, which performs similar functions but is more
convenient to use.  @xref{Invoking guix shell}.

Being deprecated, @command{guix environment} is slated for eventual
removal, but the Guix project is committed to keeping it until May 1st,
2023.  Please get in touch with us at @email{guix-devel@@gnu.org} if you
would like to discuss it.
@end quotation
--8<---cut here---end--->8---

Therefore, it would appear helpful to mention that for this future
release.  Because May 1st, 2023 is… soon! :-)


Cheers,
simon

Heads-up: Run “make clean-go && make”

[Ludovic Courtès]

Hi,

Ludovic Courtès  skribis:

>   licenses: Let 'license?' expand to #t in trivial cases.
>   packages: Raise an exception for invalid 'license' values.

I pushed these two patches as b6bc4c109b807c646e99ec40360e681122d85b2c
(see  for context).

Now we all need to run “make clean-go && make”!

Thank you for your understanding.  :-)

Ludo’.

Re: Supported architectures

[Csepp]

Efraim Flashner  writes:

> Firstly, I'd like to mention that we, in general, have a minimum system
> requirement of 2GB of RAM, and IIRC there aren't a lot of armhf boards
> out there which have that much. We do have a difference between building
> natively and cross building / building with '--target'.

This really needs to be lowered IMHO.  2GB being the minimum should be
treated as a bug.

> I'd like to comment on armhf for a moment. My memory is a but rusty, but
> I'm pretty sure that in December of 2021 mesa was bumped from 21.2.x to
> 21.3.x, and at that time it stopped building on/for armhf. I noticed in
> May of 2022 (5 months later) and got the build working again. That we
> went 5 months without anyone saying anything in bug reports that mesa
> wasn't building shows that either everyone who is using it is using
> software that doesn't use mesa, or we really don't have any armhf-linux
> users. I'm not advocating dropping the architecture, but it does feel
> like we're already at a best-effort level with it. As far as the pieces
> needed for bootstrapping aarch64 software (go and probably others),
> those get built anyway as needed by aarch64, so there's no worry about
> losing support for those software bits.

Personally I'm not using Guix on my armhf machines *because* armhf is
buggy.  I would certainly love to use it, but right now postmarketOS is
sooo much better on armhf.  It would be great to be in a position where
I could submit bug reports from armhf but just doing it on i686 is
already a challenge.