Re: Fallout from recent nss-certs changes

[pelzflorian (Florian Pelz)]

Ian Eure  writes:
> The change is mentioned in the channel news, but it says nothing about
> needing to remove that part of the config.

You are right; I have added more explicit instructions as commit
e5c0ea22e68cc8d6f99957295bc9198afb8455df.

Users should see it when they guix pull again.

Regards,
Florian

Re: Should we include nss-certs out of the box?

[pelzflorian (Florian Pelz)]

Fabio Natali  writes:
> For what it's worth, I put together a micro-patch and sent it over as a
> follow-up to #70451.

Pushed as 67a3a83170c038d2eb084d3f53a7ea7b033aea74.

Thank you!

Regards,
Florian

Re: [PATCH] Fix typo (Re: Feedback of the GNU Guix manual)

[pelzflorian (Florian Pelz)]

Pushed as b8ccbc942e0ec7baf695d383e575991289c6e033.

Thank you for trudging on through the list.

Regards,
Florian

Re: Fallout from recent nss-certs changes

[pelzflorian (Florian Pelz)]

Hello Ian.  My understanding of the nss-certs etc/news.scm item had been
that we should remove (specification->package "nss-certs"), which became
unnecessary and clutters config.scm.  From what you write, this was
actually not intended, but it is still not a bug IMHO.

(I’m not involved with the change, though.)

Regards,
Florian

Re: Fix grammar and markup (was Re: Feedback of the GNU Guix manual)

[pelzflorian (Florian Pelz)]

Hello Matt, pushed as 86fb0e039bf30cf85e2066401f9a384427c47ea8.

I was bold enough to retain the xref change in (Setting Up the Daemon)
prompted by Ludo, because starting a sentence with @xref is recommended
in the Texinfo manual and its examples, while @pxref at the start of a
phrase is not preferrable, according to the “info "(texinfo)@pxref"”.

Again, Texinfo cross-references are complicated.

(In the German translations, I always wrote only @ref, but only because
@xref is not properly translated; Emacs in particular is not
internationalized at all.)

Regards,
Florian

Re: Creating a documentation team?

[pelzflorian (Florian Pelz)]

Ludovic Courtès  writes:
> Hi Florian and all,
>
> I figure you’ve been doing a lot of review and writing of the manual.
> Should we create a documentation team, of which you could be a honorary
> member?  :-)

Yes, please add this team for documentation.  I agree and would like to
be in that team.  (Although I am already not able to keep up with all
outstanding doc patches like bug#70202.)

Regards,
Florian

Re: Fix grammar and markup (was Re: Feedback of the GNU Guix manual)

[pelzflorian (Florian Pelz)]

Hi Matt.  When triple checking, I read in “info "(texinfo)@pxref"”:

   In past versions of Texinfo, it was not allowed to write punctuation
after a '@pxref', so it could be used _only_ before a right parenthesis.
This is no longer the case.  The effect of '@pxref{NODE-NAME}' is
similar to that of 'see @ref{NODE-NAME}'.  However, in many circumstance
the latter is preferrable, as this makes it clear in the Info output
that the word "see" should be present.

Because of this last sentence, my tendency would now be to use @pxref
only for parentheses.  (Texinfo is really confusing.)  Should I just cut
these changes:

(Linux Services): Use @pxref to start phrase.
(Configuring the Shell): Use @pxref to start phrase.

or is there more that should go in this patch?

Matt  writes:
>   On Mon, 15 Apr 2024 14:58:50 +0200  pelzflorian (Florian Pelz)  wrote 
> --- 
>  > I believe the Emacs errors are historical; looking at Emacs 29.3 as
>  > packaged in Guix, Emacs-Info displays xref properly as See.  Display
>  > errors had existed, but in the past only.
>
> I reported it to emacs-devel (it's addressed now) and the issue isn't
> technically @xrefs; it's the compilation of @xref and @ref, '*Note'
> and '*note' respectively.  Emacs looks at the context around these and
> renders them as 'See' or 'see' according to what's nearby.  […]

Ohh thank you and them for the fix.

Regards,
Florian

Re: Fix grammar and markup (was Re: Feedback of the GNU Guix manual)

[pelzflorian (Florian Pelz)]

Matt  writes:
> The problem is that the Emacs Info reader incorrectly renders
> cross-references by default.  I was reading the Texinfo documentation
> in Emacs.

I believe the Emacs errors are historical; looking at Emacs 29.3 as
packaged in Guix, Emacs-Info displays xref properly as See.  Display
errors had existed, but in the past only.

Again thank you for tediously working through deficiencies in Guix’ docs.

Do you agree that I should commit your docs correction with @pxref?
I believe it is an improvement over current “see @ref”, even though it
looks different in the info reader.

Regards,
Florian

Re: Fix grammar and markup (was Re: Feedback of the GNU Guix manual)

[pelzflorian (Florian Pelz)]

Matt  writes:
> The attached change updates "Libera Chat" to the "Libera.Chat" stylization.

Pushed as df7b569b464c05036871f23d37ba319be78e5f64.

Thanks!

Regards,
Florian

Re: Fix grammar and markup (was Re: Feedback of the GNU Guix manual)

[pelzflorian (Florian Pelz)]

Matt  writes:
> #+begin_quote
> 3.7 After System Installation
> L27 Libera_Chat, why the underscore. It is colored as well for me so
> I guess this is a special char. Should be anways just Libera Chat
> #+end_quote
>
> "Libera_Chat" is not, or no longer, in the docs (d3fe763fe3).
> However, there are two variations present: "Libera Chat" and
> "Libera.Chat".

Currently Libera Chat is written using a non-breaking space.  We could
also use @tie{} instead of the special char  .  I do agree with your
Libera.Chat stylization, will push it later.  It will not matter to
search engines, I think.

Regards,
Florian

Re: Fix grammar and markup (was Re: Feedback of the GNU Guix manual)

[pelzflorian (Florian Pelz)]

Hello Matt.  Thank you for fixing the oversight.  However:

Matt  writes:
> From: Matthew Trzcinski 
> Date: Sat, 13 Apr 2024 10:12:05 +0200
> Subject: [PATCH] doc: Fix cross-references
>
> * doc/guix.texi (Setting Up the Daemon): use @xref to start sentence.
> (Build Systems): capitalize "python" and start parenthesized reference with
> @pxref.
> (Linux Services): use @xref to start phrase.

@xref produces a capital See instead of see.  This should be @pxref.
See the Texinfo manual “info texinfo” or the Web manual Ludo points to.

In info, this will use the word *note instead of *see, but it’s still
right, if Matt you agree.

> (Configuring the Shell): use @xref to start phrase.

This should be @pxref.

Additionally, the commit message’s first sentence should end with a
period.  The sentences in the commit message describing a section should
start with a capital letter.

Regards,
Florian

Re: Fix grammar and markup (was Re: Feedback of the GNU Guix manual)

[pelzflorian (Florian Pelz)]

Pushed as cd557e2d1c83839dd587016279900d31f053efc8.

Matt  writes:
> The next item reported is:
>
> #+begin_quote
> 2.4 Setting up the deamon
>
> Seems like an issue with info.  Have seen this in the Emacs manual as well.  
> There is also sometimes see see (doc)
>
> L15 See also see Substitutes.
> #+end_quote
>
>
> This sounds like the use of an @xref instead of @ref.  However, I
> can't find it in the current version (5a95cf76) of the documentation,
> nor the reported version (ee7c9d25).  […]

I believe the rendering of @ref was an issue with Emacs that is gone in
latest Emacs.


> It was advised to submit the previous patch to guix-patches.  I opted
> to submit this next patch here to keep the thread connected since it's
> part of a larger discussion (I suppose).  If we're agreed that
> guix-patches is more appropriate, I can submit the next item in a new
> thread there using the same message format I've been following.
> Thoughts?

I believe guix-devel is OK for such changes.

Regards,
Florian

Re: Security-Enhancement: Fine Control for guix pull --allow-downgrades

[pelzflorian (Florian Pelz)]

"pelzflorian (Florian Pelz)"  writes:
> And use ‘guix style --whole-file’ for formatting code,

This was bad advice in this case, sorry.

Regards,
Florian

Re: Security-Enhancement: Fine Control for guix pull --allow-downgrades

[pelzflorian (Florian Pelz)]

Hello Rostislav.  This is a good idea in my opinion, but please send the
patch as a mail to guix-patc...@gnu.org.

Also do not use [] for parentheses; always use (), which is Guix policy.

And use ‘guix style --whole-file’ for formatting code, see the manual
by running the command “info "(guix)Formatting Code"”.

Regards,
Florian

Re: Bug#1066113: guix: CVE-2024-27297

[pelzflorian (Florian Pelz)]

On 2024-03-16, Vagrant Cascadian wrote:
> For anyone with Guix or Nix installed, if I understand correctly, it
> basically allows arbitrarily replacing the source code for anything that
> you might build using Guix or Nix.

Yes, for multi-user systems and people running untrusted code in “guix
shell -CW” container isolation, there is risk.

Regards,
Florian

Re: the right to rewrite history to rectify the past (was Re: Concerns/questions around Software Heritage Archive)

[pelzflorian (Florian Pelz)]

Hello all.  I object to this argument:

MSavoritias  writes:
> We are talking about social rules that we have here in the Guix
> community not legal/state rules.

No, legal rules come from deliberation of social arguments.

CoC-wise, it seems to me that SWH was unfriendly and this is important
to Guix.

But SWH’s legal arguments are also social arguments and cannot be
dismissed.  I do not know if SWH really is an archive in the sense of
the law, but certainly we are facing a trade-off.

It would be nice if Guix could handle harmless deletion or
rectifications.  Whether that is possible shapes laws.  I believe it is
possible, but “show me how” is a valid response.

Regards,
Florian

Re: rewriting history; Was: Concerns/questions around Software Heritage Archive

[pelzflorian (Florian Pelz)]

The guix-daemon does the hashing, so guix-daemon would have to be fixed
to override integrity checks (and it would have to be patched
retroactively in every time-travel).  Noone likes touching guix-daemon
(until it is rewritten in Guile), so I can imagine it would be
frustrating.

Now ftfy is not in Guix, but if Software Heritage deleted the data,
their customers might be equally frustrated.  It is SWH’s obligation to
delete the data, but looking at how rare GDPR action is and how
frequently Icecat’s TPRB add-on lays bare GDPR violations, if they do
not follow the obligation, there likely will not be legal action or the
legal action can be dismissed somehow.

The problem is, such inaction by SWH may be relevant for Guix’ Code of
Conduct, as pointed out by MSavoritias.

Regards,
Florian

Re: doc: installation: fix ~root confusion (was Re: doc: Removing much of Binary Installation)

[pelzflorian (Florian Pelz)]

Hello Matt and thank you for your precise wording.  You have made clear
the differences:

Matt  writes:
> There are several actions which we have deferred and other topics
> which still need to be addressed, such as those raised by Vagrant and
> Suhail.  My hope is to 1) resolve and merge this immediate patch, as
> we appear to be converging on a consensus, 2) discuss how we could
> better handle documentation changes than how I've handled them here
> (that is, in one ever evolving diff),

I think the diff was quite appropriate.  You could make a patch via “git
format-patch” or “git send-email”, which would include a commit message
and which could include a move of sections 2.2 and 2.3 to the
contributing.texi.  But it is not necessary for documentation changes.


> 3) compile a list of deferred
> actions, 4) compile a list of deferred topics, and 5) address points 3
> and 4 according to 2.
>
>  On Mon, 11 Mar 2024 16:54:01 +0100  pelzflorian (Florian Pelz)  wrote ---
>> Yes, however the removal means that we should move the sections
>>
>> * 2.2 Requirements
>> * 2.3 Running the Test Suite
>>
>> to the Contributing manual in doc/contributing.texi.  WDYT?  You said,
>> it could be a separate discussion, but in my opinion it would be part of
>> the same patch.
>
> I was thinking of the opposite, of moving "Building from Git" into
> Installation.  What you say makes more sense and I agree.  Since the
> suggested patch is already quite complex, I have not added moving
> Sections 2.2 and 2.3 to the changes.  I propose we make the move in a
> separate commit.

Yes, it should probably be a separate commit, to make it possible to
revert it separately.


>> > +@cindex foreign distro
>> > +@cindex Guix System
>>
>> “@cindex Guix System” is inappropriate, because instructions on Guix
>> System are not here.
>
> Removed.  Good catch!
>
>> > +You can install the Guix package management tool on top of an existing
>> > +GNU/Linux or GNU/Hurd system@footnote{Currently only the Linux-libre
>> > +kernel is fully supported. […]
>>
>> No.
>>
>> First of all, using guix-install.sh as per your instructions, one
>> installs the Guix distribution *and* package management tool.  Either
>> say “You can install the Guix package management tool and distribution”
>> or “You can install Guix”.
>
> I'm afraid I don't follow.  Where do you see the suggested changes
> confusing the installation process for Guix as a distribution and Guix
> as a package management tool?
>
> The sentence you quote is the suggested first sentence for the Chapter
> 2: Installation.  The complete sentence reads,
>
> "You can install the Guix package management tool on top of an
> existing GNU/Linux or GNU/Hurd system(1), referred to as a "foreign
> distro", or as a standalone operating system distribution, the "Guix
> System"."
>
> It literally says Guix is a package manager or a distribution.

Precisely this terminology is the issue.  Nix is a package manager;
Nixpkgs is a distribution.  For Guix, Guix is both a package manager and
distribution.  Guix System is not a distribution in this sense; Guix is
the distribution.  I am aware that some people expect distribution to
mean a self-sufficient operating system, but we should not subscribe to
one side of terminology.  (Actually, the term operating system is
complex as well, for example GNU is an operating system and the people
from Robot Operating System call ROS an operating system.)

I would not address Hurd here at all.  Hurd support would be important
and is promising, but documentation for it should come after it works on
more than a Childhurd.



> No
> mention of 'guix-install.sh' is made on that page.

I wanted to give an example what I mean, not a suggestion.


>
> The current "introduction" to Chapter 2: Installation is this:
>
> "Note: We recommend the use of this  to
> install Guix on top of a running GNU/Linux system, thereafter called a
> foreign distro. The script automates the download, installation, and
> initial configuration of Guix. It should be run as the root user."
>
> https://guix.gnu.org/en/manual/devel/en/html_node/Installation.html
>
> Maybe the diff didn't apply correctly?  Maybe it's confusing how the
> Texinfo syntax puts the footnote markup in the middle of the source
> sentence, even though footnotes render at the bottom of the page?
>
>> Next, I believe Guix cannot currently be built on existing GNU/Hurd
>> systems, because guile-fibers does not work.  I do not really know
>> enough, but I would not mention Hurd support.
>
> The are two issues here, what is said and what should be said.
&g

Re: doc: installation: fix ~root confusion (was Re: doc: Removing much of Binary Installation)

[pelzflorian (Florian Pelz)]

Hi Matt.  I would almost want to push your changes, but we still
disagree on some wordings.

Also,

Matt  writes:
> I realigned the subject.  It was previously changed to "doc: Removing
> much of Binary Installation" which is misleading.  The topic is how to
> clarify installation based on reported confusion, not about removing
> text.  The reported confusion was on the use of '~root'.  Explicit
> mention of '~root' is only necessary when the manual details how
> 'guix-install.sh' works.  Since 'guix-install.sh' is the recommended
> method of installation, such level of detail is unnecessary,
> inappropriate, and impractical.  The suggested changes address the
> issue, only incidentally, by removing text.

Yes, however the removal means that we should move the sections

* 2.2 Requirements
* 2.3 Running the Test Suite

to the Contributing manual in doc/contributing.texi.  WDYT?  You said,
it could be a separate discussion, but in my opinion it would be part of
the same patch.


> +@cindex foreign distro
> +@cindex Guix System

“@cindex Guix System” is inappropriate, because instructions on Guix
System are not here.


> +You can install the Guix package management tool on top of an existing
> +GNU/Linux or GNU/Hurd system@footnote{Currently only the Linux-libre
> +kernel is fully supported. […]

No.

First of all, using guix-install.sh as per your instructions, one
installs the Guix distribution *and* package management tool.  Either
say “You can install the Guix package management tool and distribution”
or “You can install Guix”.

Next, I believe Guix cannot currently be built on existing GNU/Hurd
systems, because guile-fibers does not work.  I do not really know
enough, but I would not mention Hurd support.  Additionally “only the
Linux-libre kernel” is incorrect, because running Guix on non-libre
Linux is fully supported.  Running Guix System there is not supported
(by us).


>> You suggested in your mail:
>>
>> Matt m...@excalamus.com> writes:
>> > Readers interested in those details may read the code for 
>> > 'guix-install.sh'.
>>
>> Could you add this suggestion to your diff?
>
> I don't see that as relevant to the reader.  The ability to read the
> source is implicit in it being provided, which it is.

Yes, you are right.


> The suggested changes remove superfluous commentary on the recommended
> binary installation process which create confusion.

“remove superfluous commentary” could be part of a commit message for
your changes, if you agree.


> What do you think is lost that isn't captured by the following bulleted list?
>
> +The script guides you through the following:
> +@itemize
> +@item Download and extract the binary tarball
> +@item Set up the build daemon
> +@item Make the ‘guix’ command available to non-root users
> +@item Configure substitute servers
> +@end itemize

The list is fine.


>> Therefore, the sentence would have to be removed: “The following
>> sections describe two methods of installation, binary installation
>> and building from source.”
>
> I've removed that sentence for a different reason.  I also revised the
> sentence, "This is often quicker than installing from source, which is
> described in the next sections", to simply, "described later".
>
> The reason is that Chapter 2 doesn't currently explain building or
> installing from source.  Building and installing from source is
> currently covered much later in Section 22.1.  Whether or not the
> Installation section should cover building from source is a separate
> issue and shouldn't be part of this discussion.

This could be:

described later (@pxref{Building from Git}).


>> Matt m...@excalamus.com> writes:
>> > - Add commas in appropriate places; after "For...Ubuntu-based
>> > systems", "Likewise", and the 'or' within the list of substitutes
>>
>> I’m not a native speaker, but I believe the commas are not
>> necessary.  There particularly does not need to be an Oxford comma
>> before ‘or’.  There could be, but there is no reason to change it.
>
> Ah, the One True Brace Style of natural language :)
>
> I think there's already enough controversy in this thread.  I've changed it 
> back :)

:D  However, please also do not change:

> -Likewise on openSUSE:
> +Likewise, on openSUSE:



>> Similarly, IMO the nuances are more appropriate in the old wording
>> “For Debian or a derivative such as Ubuntu,” rather than your change
>> “For Debian and Ubuntu-based systems”.
>
> The current wording is, "If you're running Debian or a derivative such
> as Ubuntu..."  None of the suggested changes include the wording you
> give.
>
> What are the nuances?  If they matter, we should probably make them explicit.

The nuance is that Ubuntu is a derivative of Debian.  It can be
bootstrapped with Debian’s dpkg, although I did not follow a recent
e-mail thread on how to do this from a Guix-provided dpkg.


> +@quotation Note
> +By default, binary installations of Guix build @emph{everything} from
> +source.  This makes each installation 

Re: doc: Removing much of Binary Installation

[pelzflorian (Florian Pelz)]

Hello Matt and all.  As a more proper review, I first tried
guix-install.sh on a Debian GNU/Hurd VM.  It fails, telling me:

[1709825168.049]: [ INFO ] init system is: sysv-init
[1709825168.059]: [ FAIL ] Unsupported CPU type: i686-AT386

The script guix-install.sh cannot be used on any GNU/Hurd system.
Vagrant’s guix package is missing on Debian GNU/Hurd as well, which is
fine of course, but we should not claim otherwise.  Therefore, could you
change it like the old instructions and only talk about GNU/Linux?

> If, instead, you want to install the complete GNU operating system,
> @pxref{System Installation}.

Maybe better say “complete Guix operating system”?  *complete* GNU
operating system maybe should only be used for GNU/Hurd.

You suggested in your mail:

Matt  writes:
> Readers interested
> in those details may read the code for 'guix-install.sh'.

Could you add this suggestion to your diff?

Further:

IIRC, you are removing the manual installation.  Therefore, the sentence
would have to be removed: “The following sections describe two methods
of installation, binary installation and building from source.”

Also,

Matt  writes:
> - Add commas in appropriate places; after "For...Ubuntu-based
> systems", "Likewise", and the 'or' within the list of substitutes

I’m not a native speaker, but I believe the commas are not necessary.
There particularly does not need to be an Oxford comma before ‘or’.
There could be, but there is no reason to change it.

Similarly, IMO the nuances are more appropriate in the old wording “For
Debian or a derivative such as Ubuntu,” rather than your change “For
Debian and Ubuntu-based systems”.

At the beginning, “You can install the Guix package management tool on
top of an existing” makes it appear as if Guix were not a distribution.
It is both a tool and a distro.  A distro does not need to be an OS.
For example, MSYS2 is a distribution.  I therefore nitpickingly prefer
“You can install Guix”.  Admittedly, the wording was vague before,
perhaps deliberately.

“Use of @file{guix-install.sh} requires Bash, GNU@tie{}tar, wget, and
Xz.” is incomplete when applied to guix-install.sh, which also requires
GnuPG.

Regards,
Florian

doc: Removing much of Binary Installation (was: Feedback of the GNU Guix manual)

[pelzflorian (Florian Pelz)]

Thank you Matt for the suggested diff.

Yes, I agree some simplification as you suggested would be beneficial,
so that the description of Binary Installation looks as simple as it
really is.  (In particular, I have witnessed people, to whom I had
suggested Guix, fail at trying Guix because they tried Guix System on a
not libre-friendly laptop, when they could/should have tried Binary
Installation.)

> - Places
> directions for 'guix-install.sh' after directions to use
> distribution-specific package managers, giving preference to those
> simpler install processes over the more manual 'guix-install.sh'
> process

I don’t feel qualified to judge, but is this the preference?  Arch wiki
advises against the Arch AUR package: “Therefore, after updating Guix
once, the AUR advantage really turns into a disadvantage, as there will
be many unnecessary files in the /usr file tree that are part of the
Guix AUR package but that are never used by Guix anymore.  Therefore,
consider using the manual installation.” [0]

The reason of existence for these distribution packages is probably
similar to the reason why the Binary Installation section exists.

As for the suggested diff where much of Binary Installation gets
removed,

> -@item
> -@cindex substitutes, authorization thereof
> -To use substitutes from @code{@value{SUBSTITUTE-SERVER-1}},
> -@code{@value{SUBSTITUTE-SERVER-2}} or a mirror (@pxref{Substitutes}),
> -authorize them:
> -
> -@example
> -# guix archive --authorize < \
> - ~root/.config/guix/current/share/guix/@value{SUBSTITUTE-SERVER-1}.pub
> -# guix archive --authorize < \
> - ~root/.config/guix/current/share/guix/@value{SUBSTITUTE-SERVER-2}.pub
> -@end example
> -
> -@quotation Note
> -If you do not enable substitutes, Guix will end up building
> -@emph{everything} from source on your machine, making each installation
> -and upgrade very expensive.  @xref{On Trusting Binaries}, for a
> -discussion of reasons why one might want do disable substitutes.
> -@end quotation

I disagree with this chunk.  This must stay.  Not enabling substitutes
is an option in guix-install.sh and the Guix System installer.  Users
might want to enable substitutes later on.

Regards,
Florian

[0] https://wiki.archlinux.org/title/Guix

Re: service 'term-tty2' provided more than once

[pelzflorian (Florian Pelz)]

Hello Felix Lechner.

A workaround is in  namely
multiple (delete mingetty-service-type) as in

(modify-services %base-services
 (delete login-service-type)
 (delete mingetty-service-type)
 (delete mingetty-service-type)
 (delete mingetty-service-type)
 (delete mingetty-service-type)
 (delete mingetty-service-type)
 (delete mingetty-service-type))

David Wilson has described a way to fix this bug in Guix
, but noone has done it yet.

Regards,
Florian

[shepherd bug] Re: Format specification issue in the translations...

[pelzflorian (Florian Pelz)]

Sebastian Rasmussen  writes:
> I will contribute a similar translation in Swedish, but I also
> want the bug in the original code fixed.
>
> I have attached my attempt at a patch to this mail.
> Maybe someone can review it and help push it to git HEAD?

Cc to Ludo with changed subject.

Regards,
Florian

Re: Format specification issue in the translations...

[pelzflorian (Florian Pelz)]

Hi Sebastian, in German I have translated in this way and it got
accepted.  Although, I have not actually tested if it displays
correctly.  I assume Guile formatting is tolerant.

#: modules/shepherd/service.scm:1087
#, scheme-format
msgid "Cannot unregister service ~a, which is still running"
msgid_plural "Cannot unregister services~{ ~a,~} which are still running"
msgstr[0] "Der Dienst~{ ~a,~} bleibt registriert, weil er noch läuft"
msgstr[1] "Die Dienste~{ ~a,~} bleiben registriert, weil sie noch laufen"

Regards,
Florian

Re: GNU Shepherd 0.10.0rc1 available for testing!

[pelzflorian (Florian Pelz)]

Hi Tanguy,

Tanguy LE CARROUR  writes:
> I did that and… I ended up with the following build error:
> […]
> checking if (fibers) is available... no
> configure: error: Fibers is missing; please install it.

Could it be that you have not run “guix pull” recently
or that a wrong Guix program gets called (you can check what it printed
by “which guix”; perhaps at the end of your .bashrc you have something
configured differently from what Guix expects)?

Regards,
Florian

Re: GNU Shepherd 0.10.0rc1 available for testing!

[pelzflorian (Florian Pelz)]

Wow, shepherd 0.10.0rc1 put an end to occasional hangups when rebooting
my slow Beebox server!  Thanks once more.

Regards,
Florian

Re: GNU Shepherd 0.10.0rc1 available for testing!

[pelzflorian (Florian Pelz)]

Thank you shepherds!  Also the explanations in the news are great.
Finally I understand why GOOPS is not desirable in shepherd.

For Guix Home:

Ludovic Courtès  writes:
> In your operating system configuration (and similarly for your
> ‘home-environment’), make the following changes:

For Guix Home, it works for me to put this in home-environment; no need
to fiddle with home-environment-essential-services.

(home-environment
  …
  (services
   (list (service home-shepherd-service-type
  (home-shepherd-configuration
   (shepherd shepherd-next)))
 …


Regards,
Florian

Re: Packages grow, no longer fit on a 

[pelzflorian (Florian Pelz)]

Hello all.

Ludovic Courtès  writes:
> Over the course of a few years, the size of our packages has apparently
> kept growing.

Disregarding dependencies, most store items got slightly bigger.  This
is what I wrote at bug#58760 “Guix System iso too big for cdrom again”
:

> it was possible to burn the Guix System install image to a 700MB CD.
> But it fits no more. I compared using the du tool (comparison between
> good old Guix version e427593 and bad new Guix version 3734857f […]).
> The result is that most packages got slightly bigger and this broke
> the camel’s back.

Regards,
Florian

Re: u-boot-am335x-boneblack -> u-boot-am335x-evm-boneblack

[pelzflorian (Florian Pelz)]

Vagrant Cascadian  writes:
> With all that said... having 512MB of ram, I wonder how well a
> beaglebone black would do running guix at all...

I used to use Guix on Debian (not Guix System) on my BeagleboneBlack.
With swap space, it worked well, even though `guix pull` took multiple
days to complete.

But I haven’t used it since 2020 and lost my UART (gotta be somewhere…)
and the BBB’s screen remains black now for some reason.

Regards,
Florian

Re: cirrus (was Re: Release progress, week 10)

[pelzflorian (Florian Pelz)]

Ludovic Courtès  writes:
> "pelzflorian (Florian Pelz)"  skribis:
>> That hold-up aside, maybe could you also tentatively add the cirrus
>> initrd module to the 1.4.0 installation image?  I suppose it won’t break
>> anything, but it might help with bugs like
>> <https://issues.guix.gnu.org/60002>.
>
> This wasn’t under my radar and I think it’s too late for such a change
> now.

OK.


> But look, we can do 1.4.1 next month if we want it.  There’s a position
> for a release management team (2–3 people) coming up BTW, so you can all
> prepare your applications.  :-)

I cannot guarantee being available or a good enough decision maker, but
I’m most grateful to you and all maintainers.

Regards,
Florian

Re: cirrus (was Re: Release progress, week 10)

[pelzflorian (Florian Pelz)]

"pelzflorian (Florian Pelz)"  writes:
> That hold-up aside, maybe could you also tentatively add the cirrus
> initrd module to the 1.4.0 installation image?  I suppose it won’t break
> anything, but it might help with bugs like
> <https://issues.guix.gnu.org/60002>.

I tested the following chance:

diff --git a/gnu/system/install.scm b/gnu/system/install.scm
index 3dd9e0e87b..dfa6db9408 100644
--- a/gnu/system/install.scm
+++ b/gnu/system/install.scm
@@ -507,6 +507,10 @@ (define installation-os
 ;; Thus, blacklist it.
 (kernel-arguments '("quiet" "modprobe.blacklist=radeon,amdgpu"))
 
+(initrd-modules (append
+(list "cirrus")
+%base-initrd-modules))
+
 (file-systems
  ;; Note: the disk image build code overrides this root file system with
  ;; the appropriate one.

This makes the installer work on QEMU with '-vga cirrus'.

It also still works under default QEMU (cirrus isn’t default anymore
since QEMU 2.2 according to the docs).

The installer also still works on my:

* Beebox with Intel

* PC with Nvidia

and thanks to the resolution of the
  https://issues.guix.gnu.org/60010
  it also works on my

* PC with AMD

* laptop with AMD

None is modern hardware, but still, please add cirrus.

Regards,
Florian

cirrus (was Re: Release progress, week 10)

[pelzflorian (Florian Pelz)]

Ludovic Courtès  writes:
> There are currently two installer bugs that I think now have a valid fix:
>
>   https://issues.guix.gnu.org/60010
>   https://issues.guix.gnu.org/59784

Sadly those are still not completely fixed…

That hold-up aside, maybe could you also tentatively add the cirrus
initrd module to the 1.4.0 installation image?  I suppose it won’t break
anything, but it might help with bugs like
.

Regards,
Florian

Re: Packaging big generated data files?

[pelzflorian (Florian Pelz)]

Denis 'GNUtoo' Carikli  writes:
> Is there any policies or past decisions of the Guix project on
> packaging big generated data files?

commit 183db725a4e7ef6a0ae5170bfa0967bb2eafded7
Author: Ricardo Wurmus 
Date:   Tue May 15 12:55:27 2018 +0200

gnu: Add r-bsgenome-dmelanogaster-ucsc-dm6.

* gnu/packages/bioconductor.scm (r-bsgenome-dmelanogaster-ucsc-dm6): New 
variable.

HTH.

Regards,
Florian

Re: GNU Guix 1.4.0rc1 available for testing!

[pelzflorian (Florian Pelz)]

There are some release blockers.  To summarize, IMHO it would be
regrettable if these bugs were not fixed before release:

* [PATCH v2 2/3] install: Add missing e2fsprogs utility.
  
  Otherwise manual installation does not work as advertised.

* [version 1.4.0rc1] reconfigure fails
  
  Otherwise users cannot update Guix System once installed
  unless they take manual action.

* [version 1.4.0rc1] install.sh script should authorize bordeaux
  
  Otherwise especially ARM users get far less substitutes
  unless they take manual action.

Julien Lepiller  writes:
> Do we string freeze?

About string freeze: I do not know if that is the case, but changes to
critical parts of doc/guix.texi on master should not be reflected on
Weblate if they don’t get into 1.4.0.

Regards,
Florian

Re: GNU Guix 1.4.0rc1 available for testing!

[pelzflorian (Florian Pelz)]

Hello Svante,

Svante Signell  writes:
> What about hurd?

Hurd can be used with QEMU on Linux-based Guix System; see the
childhurd section in the manual.  However, I tried and somewhat failed
to run on my real hardware (a Beebox mini PC): When booting, the Hurd
runs an rc script which freezes.

I make /dev/sda1 an ext2 filesystem and use a slightly modified
/run/current-system/profile/share/guile/site/3.0/gnu/system/examples/bare-hurd.scm
as the template for a manual installation (with the usual steps from
the Guix manual).  Note: e2fsprogs is needed for manual installation
but is not installed in the rc1 installer image; a bug
.

(Thank you for making me notice the bug!)

After these preparations, I run:

guix system init /mnt/etc/config.scm /mnt --target=i586-pc-gnu --skip-checks

Then a last step: Open `guix repl` and run

,use (gnu build hurd-boot)
(make-hurd-device-nodes "/mnt")

It installs and runs somewhat iff I edit the GRUB boot options (with
the E key in the boot menu) to boot from sd0s1 instead of hd0s1, on
every boot.  If I forget to do this, I need to run `fsck.ext2
/dev/sda1` from the installer image before I can boot the already
installed Hurd again.

Anyway, it starts /gnu/store/38sb8h…-system/rc, which freezes.

Also note that the Hurd release shipped with Guix has known security
issues (see Sergey Bugaev’s writeups; there has not yet been a new mig
release since and Guix would need it for newer Hurd, I think).

Note: These instructions are the result of trial and error.  I am not a
hurd user (yet) and don’t know details.

Regards,
Florian

Re: Licence of the Guix blog posts

[pelzflorian (Florian Pelz)]

Ludovic Courtès  writes:
> Therefore, I propose to apply the following patch, which leaves out a

Yes!  The patch looks good.  I‘m fine with that license.

Regards,
Florian

Re: Permanent URL for GUIX packages

[pelzflorian (Florian Pelz)]

Hello Sunshine,

Sunshine via "Development of GNU Guix and the GNU System distribution."
 writes:
> I'd like to link guix.gnu.org/packages/monolith-2.6.1/ […]

Something similar is possible, see .

Regards,
Florian

Re: Translation: Would regional translation fall back to primary language?

[pelzflorian (Florian Pelz)]

Hello Luis.

Luis Felipe  writes:
> I think I'll go with that option, thanks.

:)


> I don't know if I understand correctly the organizational problem
> related to leaving the es-CO catalog partially translated,
> intentionally. Is it that Weblate would display the es-CO translation
> as incomplete and so translators would end up duplicating work? (Start
> translating the rest of the catalog not knowing that the "es-CO"
> regional catalog is supposed to be left incomplete so that the missing
> translations are taken from the almost complete "es" catalog?)

Yes, that is precisely what I expect to happen.


> Because if that's the case, I'd like to propose Weblate developers
> that progress gauges for regional catalogs take into account the
> progress of the primary language. That way, the progress of a regional
> catalog would always be greater or equal to the progress of the
> catalog of the primary language.

It’s not just the progress bars.  Yes, Weblate could somehow display it
as already translated if the fallback language has a translation, but
when downloading the PO file, other editors would not display it.

Regards,
Florian

Re: Translation: Would regional translation fall back to primary language?

[pelzflorian (Florian Pelz)]

Hello Luis/sirgazil.  Translation help sounds great.

That said, I believe that, because others will add to the translation,
that it would be best if you Downloaded the Spain Spanish file from
Weblate and then uploaded that PO file as the first translation in
Colombian Spanish.  Then change it from that base.

Luis Felipe  writes:
> So, assuming an incomplete es-CO translation catalog already exists,
> would the translation system (gettext?) retrieve missing translations
> from the catalog corresponding to the primary language (es) or would
> it retrieve the source string in English?

I just tested adding a dummy de_CH.po translation file to Guix and yes,
it falls back to de translations if the msgstr in de_CH is empty, even
without changing the LANGUAGE environment variable and only setting
LC_ALL=de_CH.utf8.

But still, from an organizational view, I suggest not doing a partial
translation.  I don’t know though.

Regards,
Florian

Re: Translating news on weblate?

[pelzflorian (Florian Pelz)]

Hi Julien; sorry for the late answer.

Julien Lepiller  writes:
> I was thinking we could have our news file translated at weblate, which
> would help having more people translate it. Attached is a script that[…]

Translating etc/news.scm via Weblate adds delay but reaches more
translators.  Now delay is not so important when reading old news from
--list-generations or when one hasn’t upgraded in a while, but I would
prefer if those who make news, continue to request translations on some
mailing list (I forgot the name of the list alias; where is it?).  Even
though I was too slow to react to such mail in the past, I think I can
improve.

Also, Weblate has lazy commits
,
i.e., it only commits new changes to your (Julien’s) repository after a
while, which adds slightly more delay when it comes to news, unless the
uploader or a news download script logs in and uses the Web API’s File
Download button.  Or maybe the hypothetical Fedora Weblate component for
Guix news can be configured to push changes to your repo right away.

Thank you Julien for your maintenance of translations!  There’s not much
to say about your nice script.

Regards,
Florian

Re: Merging ‘staging’?

[pelzflorian (Florian Pelz)]

On Thu, Jun 09, 2022 at 09:02:14PM +0200, pelzflorian (Florian Pelz) wrote:
> I will try again with staging at 091eb323ba27.  But it will take a
> long time; feel free to proceed regardless.

All my manifest built and runs on rock64 aarch64.  Thank you all!

Regards,
Florian

Re: Merging ‘staging’?

[pelzflorian (Florian Pelz)]

On Thu, Jun 09, 2022 at 09:02:14PM +0200, pelzflorian (Florian Pelz) wrote:
> I will try again with staging at 091eb323ba27.

llvm@11 was built successfully.  Sorry for the noise.

Regards,
Florian

Re: Merging ‘staging’?

[pelzflorian (Florian Pelz)]

On Thu, Jun 09, 2022 at 08:41:21PM +0300, Efraim Flashner wrote:
> I know I've built llvm@11 and mesa on aarch64 hardware for staging.

Oh I see I'm missing the last merge; I'm still at commit b422687cbd.

I will try again with staging at 091eb323ba27.  But it will take a
long time; feel free to proceed regardless.

Regards,
Florian

Re: Merging ‘staging’?

[pelzflorian (Florian Pelz)]

On Mon, Jun 06, 2022 at 11:17:47PM +0200, Ludovic Courtès wrote:
> We have to check for AArch64 & co.  Any takers?
> 
> Overall it seems to me we should be able to merge ‘staging’ within a
> couple of days.  Thoughts?
> 
> Ludo’.
> 

I mostly succeeded in updating my rock64 aarch64 machine

guix time-machine --branch=staging -- package -m 
~/keep/guixsd/rock64-manifest.scm

but building llvm@11 fails (needed for mesa, I think).  The log ends with:

[...]
make[2]: Leaving directory '/tmp/guix-build-llvm-11.0.0.drv-0/build'
[ 97%] Built target verify-uselistorder
make  -f tools/yaml2obj/CMakeFiles/yaml2obj.dir/build.make 
tools/yaml2obj/CMakeFiles/yaml2obj.dir/depend
make[2]: Entering directory '/tmp/guix-build-llvm-11.0.0.drv-0/build'
cd /tmp/guix-build-llvm-11.0.0.drv-0/build && 
/gnu/store/6lfyb68pdy0b1vggzbvw8grkv2ws6vhl-cmake-minimal-3.21.4/bin/cmake -E 
cmake_depends "Unix Makefiles" 
/tmp/guix-build-llvm-11.0.0.drv-0/llvm-11.0.0.src 
/tmp/guix-build-llvm-11.0.0.drv-0/llvm-11.0.0.src/tools/yaml2obj 
/tmp/guix-build-llvm-11.0.0.drv-0/build 
/tmp/guix-build-llvm-11.0.0.drv-0/build/tools/yaml2obj 
/tmp/guix-build-llvm-11.0.0.drv-0/build/tools/yaml2obj/CMakeFiles/yaml2obj.dir/DependInfo.cmake
 --color=
Consolidate compiler generated dependencies of target yaml2obj
make[2]: Leaving directory '/tmp/guix-build-llvm-11.0.0.drv-0/build'
make  -f tools/yaml2obj/CMakeFiles/yaml2obj.dir/build.make 
tools/yaml2obj/CMakeFiles/yaml2obj.dir/build
make[2]: Entering directory '/tmp/guix-build-llvm-11.0.0.drv-0/build'
[ 98%] Linking CXX executable ../../bin/yaml2obj
cd /tmp/guix-build-llvm-11.0.0.drv-0/build/tools/yaml2obj && 
/gnu/store/6lfyb68pdy0b1vggzbvw8grkv2ws6vhl-cmake-minimal-3.21.4/bin/cmake -E 
cmake_link_script CMakeFiles/yaml2obj.dir/link.txt --verbose=1
/gnu/store/dbcbcaxq20kbkhh2mr8k98qfnymq22kp-gcc-10.3.0/bin/c++  -fPIC 
-fvisibility-inlines-hidden -Werror=date-time -Wall -Wextra 
-Wno-unused-parameter -Wwrite-strings -Wcast-qual 
-Wno-missing-field-initializers -pedantic -Wno-long-long -Wimplicit-fallthrough 
-Wno-maybe-uninitialized -Wno-class-memaccess -Wno-redundant-move 
-Wno-noexcept-type -Wdelete-non-virtual-dtor -Wno-comment -ffunction-sections 
-fdata-sections -O3 -DNDEBUG  -Wl,-allow-shlib-undefined  -Wl,-O3 
-Wl,--gc-sections CMakeFiles/yaml2obj.dir/yaml2obj.cpp.o -o ../../bin/yaml2obj  
-Wl,-rpath,/tmp/guix-build-llvm-11.0.0.drv-0/build/lib 
../../lib/libLLVMObjectYAML.so.11 -lpthread ../../lib/libLLVMSupport.so.11 
-Wl,-rpath-link,/tmp/guix-build-llvm-11.0.0.drv-0/build/lib 
make[2]: Leaving directory '/tmp/guix-build-llvm-11.0.0.drv-0/build'
[ 98%] Built target yaml2obj
make  -f examples/Bye/CMakeFiles/Bye.dir/build.make 
examples/Bye/CMakeFiles/Bye.dir/depend
make[2]: Entering directory '/tmp/guix-build-llvm-11.0.0.drv-0/build'
cd /tmp/guix-build-llvm-11.0.0.drv-0/build && 
/gnu/store/6lfyb68pdy0b1vggzbvw8grkv2ws6vhl-cmake-minimal-3.21.4/bin/cmake -E 
cmake_depends "Unix Makefiles" 
/tmp/guix-build-llvm-11.0.0.drv-0/llvm-11.0.0.src 
/tmp/guix-build-llvm-11.0.0.drv-0/llvm-11.0.0.src/examples/Bye 
/tmp/guix-build-llvm-11.0.0.drv-0/build 
/tmp/guix-build-llvm-11.0.0.drv-0/build/examples/Bye 
/tmp/guix-build-llvm-11.0.0.drv-0/build/examples/Bye/CMakeFiles/Bye.dir/DependInfo.cmake
 --color=
Consolidate compiler generated dependencies of target Bye
make[2]: Leaving directory '/tmp/guix-build-llvm-11.0.0.drv-0/build'
make  -f examples/Bye/CMakeFiles/Bye.dir/build.make 
examples/Bye/CMakeFiles/Bye.dir/build
make[2]: Entering directory '/tmp/guix-build-llvm-11.0.0.drv-0/build'
make[2]: Nothing to be done for 'examples/Bye/CMakeFiles/Bye.dir/build'.
make[2]: Leaving directory '/tmp/guix-build-llvm-11.0.0.drv-0/build'
[ 98%] Built target Bye
make  -f unittests/Passes/CMakeFiles/TestPlugin.dir/build.make 
unittests/Passes/CMakeFiles/TestPlugin.dir/depend
make[2]: Entering directory '/tmp/guix-build-llvm-11.0.0.drv-0/build'
cd /tmp/guix-build-llvm-11.0.0.drv-0/build && 
/gnu/store/6lfyb68pdy0b1vggzbvw8grkv2ws6vhl-cmake-minimal-3.21.4/bin/cmake -E 
cmake_depends "Unix Makefiles" 
/tmp/guix-build-llvm-11.0.0.drv-0/llvm-11.0.0.src 
/tmp/guix-build-llvm-11.0.0.drv-0/llvm-11.0.0.src/unittests/Passes 
/tmp/guix-build-llvm-11.0.0.drv-0/build 
/tmp/guix-build-llvm-11.0.0.drv-0/build/unittests/Passes 
/tmp/guix-build-llvm-11.0.0.drv-0/build/unittests/Passes/CMakeFiles/TestPlugin.dir/DependInfo.cmake
 --color=
Consolidate compiler generated dependencies of target TestPlugin
make[2]: Leaving directory '/tmp/guix-build-llvm-11.0.0.drv-0/build'
make  -f unittests/Passes/CMakeFiles/TestPlugin.dir/build.make 
unittests/Passes/CMakeFiles/TestPlugin.dir/build
make[2]: Entering directory '/tmp/guix-build-llvm-11.0.0.drv-0/build'
make[2]: Nothing to be done for 
'unittests/Passes/CMakeFiles/TestPlugin.dir/build'.
make[2]: Leaving directory '/tmp/guix-build-llvm-11.0.0.drv-0/build'
[ 98%] Built target TestPlugin
make  -f unittests/Support/DynamicLibrary/CMakeFiles/SecondLib.dir/build.make 

Re: Teams

[pelzflorian (Florian Pelz)]

On Sat, Jun 04, 2022 at 02:50:49PM +, Tobias Geerinckx-Rice wrote:
> I think we should also have (natural) language 'teams' who can be
> pinged when, e.g., a news item lands, through a single
> guix-translators@ meta-alias, and who can co-ordinate before
> releases.

If we do so, please add me too for -de.

Regards,
Florian

Re: 10 years of stories behind Guix

[pelzflorian (Florian Pelz)]

On Mon, Apr 18, 2022 at 10:37:40PM +0200, Ludovic Courtès wrote:
> To celebrate
> it, zimoun has collected stories from a sample of the 600+ people who’ve
> contributed to Guix over the years, which you can read here:
> 
>   https://guix.gnu.org/en/blog/2022/10-years-of-stories-behind-guix/

Thank you very much for the stories!  And for the hyperlinks.

Took me until now just to finish reading, so I’m even more impressed
Hubert already translated the blog post to French some time ago:

https://lists.gnu.org/archive/html/help-guix/2022-04/msg00114.html

Regards,
Florian

Re: The GNU Shepherd 0.9.0rc1 available for testing!

[pelzflorian (Florian Pelz)]

On Wed, Mar 30, 2022 at 06:59:33PM +0200, Ludovic Courtès wrote:
> You can test it on Guix System with:
> 
>   guix time-machine --branch=wip-shepherd-upgrade -- \
> system reconfigure …

On my 2010 Macbook Pro (with hard disk, not using SSD), boot time to
GDM got a few seconds slower/faster from 3:08--3:22 minutes to
3:19--3:20 minutes.  (Faster old boot times are a few days old; seems
to vary with temperature or phase of the moon or something.  So it is
maybe not slower at all or maybe even 2 seconds faster.)

I’m using none of the new Shepherd features; no sshd and no childhurds
nor secrets service, just desktop services and GNOME.

But still the new Shepherd is the right thing to do, I think.

Regards,
Florian

Re: The Shepherd on Fibers

[pelzflorian (Florian Pelz)]

On Sat, Mar 26, 2022 at 07:27:00PM +0800, Zhu Zihao wrote:
> 
> IIUC, After fork and execute the program, shepherd will wait for the pid
> file to appear. This is a block operation.
> 
> Shepherd on Fiber make this operation non-blocking (because the pid file
> is created by Linux kernel, Shepherd just need to wait for it), every
> service activation runs on its own fiber. after fork+exec, shepherd
> suspend current fiber, andspawn another fiber to start another service
> immediately.
> 
> But finally all fibers are co-operatively scheduled on 1 thread.

Thank you Zhu for explaining!  I had not understood waiting for the
PID file is the issue solved by fibers.

Regards,
Florian

Re: The Shepherd on Fibers

[pelzflorian (Florian Pelz)]

On Sat, Mar 26, 2022 at 12:59:20PM +0100, Maxime Devos wrote:
> Grafting is not necessary.  See (guix)Shepherd Services:
> 
> 
>;; Use own Shepherd package.
>(essential-services
> (modify-services (operating-system-default-essential-services
>   this-operating-system)
>   (shepherd-root-service-type config => (shepherd-configuration
>  (inherit config)
>  (shepherd my-
> shepherd))
> 

Oh yes, I had not tried that.  Thank you Maxime.  Still with unchanged
original shepherd package, I get exactly the same
shepherd-avahi-daemon.go.drv.gz build failure iff I set (shepherd
new-shepherd).  Therefore I ask how Ludo or perhaps you tested it.
Perhaps you have a proper new-shepherd package definition.

Regards,
Florian

Re: The Shepherd on Fibers

[pelzflorian (Florian Pelz)]

On Sat, Mar 26, 2022 at 07:09:12PM +0800, Zhu Zihao wrote:
> > So shepherd service authors still cannot write blocking code but need
> > to yield?
> 
> IMO, service should not block service, if they have something important
> to do before running a program, why not fork first and do it in the
> child-process (maybe wrap the actual startup program in Guile script)?

In other words, all stays the same as without fibers?

Regards,
Florian

Re: The Shepherd on Fibers

[pelzflorian (Florian Pelz)]

Hi Ludo!  That you add fibers to Shepherd is great news.

On Wed, Mar 23, 2022 at 11:36:30PM +0100, Ludovic Courtès wrote:
> Fibers is used in a single-threaded fashion, which is the main
> constraint for shepherd since it forks.  That also means that fibers
> cannot be preempted, so it’s fully cooperative scheduling.

To understand what you mean, I needed to read shepherd commit
934204fbd158aa9fbd42914b89aa960f99eef125

+  ;; Run Fibers in such a way that it does not create any POSIX thread,
+  ;; because POSIX threads and 'fork' cannot be used together

So shepherd service authors still cannot write blocking code but need
to yield?


> I’ve done some Guix System testing in VMs and didn’t notice any major
> issues.  I’d like to merge that branch in ‘master’ and to eventually
> release it as 0.9.0 (with or without socket activation, we’ll see.)
> Hopefully, we could be running it within a couple of weeks.

I wanted to test too how much time it takes to boot to GDM on my slow
2010 dual-core Macbook, but I can’t quite figure out each shepherd-
service failing to build.  How did you test the new shepherd in Guix?

florian@florianmacbook ~/git/guix [env]$ gzip -cd 
/var/log/guix/drvs/f3/g9drzlg8vkzp6z81dcdsnfnaqa2anx-shepherd-avahi-daemon.go.drv.gz
 
Backtrace:
  16 (primitive-load "/gnu/store/4qk3x8dl8hxnwry637kq4ahh2z2?")
In ice-9/eval.scm:
619:8 15 (_ #(# #))
159:9 14 (_ #(# #))
In ice-9/boot-9.scm:
  3326:17 13 (resolve-interface (shepherd service) #:select _ #:hide ?)
In ice-9/threads.scm:
390:8 12 (_ _)
In ice-9/boot-9.scm:
  3252:13 11 (_)
In ice-9/threads.scm:
390:8 10 (_ _)
In ice-9/boot-9.scm:
  3536:20  9 (_)
   2835:4  8 (save-module-excursion #)
  3556:26  7 (_)
In unknown file:
   6 (primitive-load-path "shepherd/service" #)
In shepherd/service.scm:
 26:0  5 (_)
In ice-9/boot-9.scm:
   3409:4  4 (define-module* _ #:filename _ #:pure _ #:version _ # _ ?)
  2594:24  3 (call-with-deferred-observers #)
  3422:24  2 (_)
   222:17  1 (map1 (((fibers)) ((fibers scheduler) #:select (#)) # ?))
   3329:6  0 (resolve-interface (fibers) #:select _ #:hide _ #:prefix ?)

ice-9/boot-9.scm:3329:6: In procedure resolve-interface:
no code for module (fibers)



Anyway, testing my boot time is not so important.  I’d probably have
to change something in gnu/services/shepherd.scm.  Or I should rebuild
shepherd in a less crude way.

Feel free to ignore me, though for completeness, here’s what I did:

* Pull shepherd wip-fibers commit
  abbdd1e8b0f8bd4b3952efc5614f560aab9a79bf.

* I changed its Makefile.am and added -O1 to '$(GUILD) compile'
  because Guix normally does likewise in an origin snippet.

* Then `guix shell -D shepherd autoconf automake guile-fibers help2man
  texinfo -- sh -c 'autoreconf -vif && ./configure
  --prefix=/home/florian/git/shepherd/out && make && make install'`.

* Then to Guix I added to gnu/packages/admin.scm:

(define-public new-shepherd
  (package
(name "shepherd")
(version "0.9.0")
(source (local-file "/home/florian/git/shepherd/out" #:recursive? #t))
(build-system copy-build-system)
(propagated-inputs (list guile-fibers))
(arguments
   `(#:install-plan '(("./" ""
…)) ;; and synopsis, description, license, homepage

and at the top #:use-module (gnu packages guile-xyz) to add
guile-fibers to new-shepherd’s propagated inputs.  Also #:use-module
(guix build-system copy).

* Lastly I grafted

(define-public shepherd
  (package
(name "shepherd")
(replacement new-shepherd)
…

* Compiled Guix and reconfigured.  Building
  /gnu/store/f3g9drzlg8vkzp6z81dcdsnfnaqa2anx-shepherd-avahi-daemon.go.drv
  failed.

The same error happens when using new-shepherd as shepherd and
rebuilding the GNOME world.

Regards,
Florian

Re: Clarifying blog post licensing

[pelzflorian (Florian Pelz)]

I agree.

On Wed, Jan 26, 2022 at 10:24:11AM +0100, Ludovic Courtès wrote:
> Hello Guix!
> 
> With a few exceptions, our blog posts do not have a license, which is
> not great as it prevents sharing and reuse, at least by those outside
> Guix circles (we discussed it in the past but never got around to fixing
> it).
> 
> I’d like us to clarify that, with a footer on blog posts saying that,
> unless otherwise stated, posts are dual-licensed under CC-BY-SA 4.0 and
> GFDL 1.3+ (the latter so we can reuse material in the cookbook and in
> the manual).  Patch below.
> 
> What do people think?
> 
> If maintainers and everyone agrees, I’d like to publicly email all the
> authors asking them whether they agree with the proposed licensing
> terms, or whether they’d like a different free license.  The script
> below enumerates blog post authors (the list needs a bit of cleanup
> still):

Re: Language menu in the HTML manual

[pelzflorian (Florian Pelz)]

On Wed, Jan 19, 2022 at 03:48:07PM +0100, Ludovic Courtès wrote:
> Commit fa580bf3b456273ea20b3f4de1afdac3d031 should fix that.  It
> also introduces the navigation bar as found on the Guix web site; I
> didn’t plan to do that, but that sorta came with the rest, so…

You accomplished quite a feat there, thank you!


> Yes.  What makes it difficult is that Texinfo transliterates node names
> to ASCII (which I find imperialistic and ridiculous, or at least
> anachronistic):

The Text::Unidecode script [1], which Texinfo uses, says
> The Text::Unidecode motto is:
>
>   It's better than nothing!

IMHO rightly so.  Transliteration is important for security.  Proper
transliteration is unreasonable.

Regards,
Florian

[1] 
https://git.savannah.gnu.org/cgit/texinfo.git/tree/tp/maintain/lib/Text-Unidecode/lib/Text/Unidecode.pm

Re: ZFS part of Guix? RFC? (Re: Effectively force all GNOME users to locally compile ZFS?)

[pelzflorian (Florian Pelz)]

On Wed, Nov 24, 2021 at 01:32:56PM +0100, pelzflorian (Florian Pelz) wrote:
> Sorry I misunderstood.  I think your claim is that the ZFS decisions
> listed by Ludo i.e. to disallow binary substitutes but to allow
> patches for a ZFS file-system object (once reviewed) are inconsistent.
> Right?
> 
> I don't know if that convinces maintainers to change decisions.
On Wed, Nov 24, 2021 at 01:51:08PM +0100, zimoun wrote:
> This decision is consistent with the analysis [1] done by Software
> Conservancy Freedom, at least.

I did not speak about one decision.

What I meant is that maybe Denis argued “dynamic linking creates a
derivative work” if and only if “ZFS source code is a derivative
work of Linux”.

Case 1, “ZFS source code is a derivative work of Linux” is true, then
it does not have a valid license, i.e. no free software license.

Case 2, “dynamic linking creates a derivative work” is false, then we
should offer binary substitutes as well.

It would follow that Guix’ decisions are inconsistent.

Then again, from Denis’ new mail,

On Wed, Nov 24, 2021 at 02:33:00PM +0100, Denis 'GNUtoo' Carikli wrote:
> The issue here is that I think that we need to find a valid and
> plausible explanation that makes the ZFS kernel module source code legal
> in a way that doesn't undermine copyleft.

Maybe Denis argued that any support for ZFS is at odds with the FSF
opinion that “dynamic linking creates a derivative work”.

On Wed, Nov 24, 2021 at 02:33:00PM +0100, Denis 'GNUtoo' Carikli wrote:
> So is it legal because zfs-on-linux is distributed as source and that
> the CDDL license incompatible requirements are waived when it is
> distributed as source? And that combining that work with GPLv2 code in
> source form is OK because GPLv2 is not violated because the
> incompatible CDDL requirements are only activated when distributed in
> executable form?

That the CDDL has terms specific to source code distribution
complicates things further and it is hard to tell if copyright law can
even impose all of CDDL’s terms.

Regards,
Florian

Re: ZFS part of Guix? RFC? (Re: Effectively force all GNOME users to locally compile ZFS?)

[pelzflorian (Florian Pelz)]

On Wed, Nov 24, 2021 at 01:03:29PM +0100, pelzflorian (Florian Pelz) wrote:
> On Wed, Nov 24, 2021 at 01:45:19AM +0100, Denis 'GNUtoo' Carikli wrote:
> > If that's the case then it would also be legal to redistribute binaries
> > too as long as they are dynamically linked as the linking happens at
> > runtime.
> 
> The FSF is unable to have such a position.
> 
> It seems unrelated to the FSDG, so GNU Guix need not care.

Sorry I misunderstood.  I think your claim is that the ZFS decisions
listed by Ludo i.e. to disallow binary substitutes but to allow
patches for a ZFS file-system object (once reviewed) are inconsistent.
Right?

I don't know if that convinces maintainers to change decisions.

Regards,
Florian

Re: ZFS part of Guix? RFC? (Re: Effectively force all GNOME users to locally compile ZFS?)

[pelzflorian (Florian Pelz)]

On Wed, Nov 24, 2021 at 01:45:19AM +0100, Denis 'GNUtoo' Carikli wrote:
> If that's the case then it would also be legal to redistribute binaries
> too as long as they are dynamically linked as the linking happens at
> runtime.

The FSF is unable to have such a position.

It seems unrelated to the FSDG, so GNU Guix need not care.

Regards,
Florian

Re: ZFS part of Guix? RFC? (Re: Effectively force all GNOME users to locally compile ZFS?)

[pelzflorian (Florian Pelz)]

On Sun, Nov 21, 2021 at 11:54:15AM +0100, pelzflorian (Florian Pelz) wrote:
> raid5atemyhomework wrote patches to add ZFS to Guix
> <https://issues.guix.gnu.org/45692>.  I put them in CC.  That there is
> no decision on ZFS and their patches is bad.  Maybe their patches
> would be for the RFC model to decide?

Maybe there is consensus that adding ZFS is a legal risk.

There is no consensus on the amount of risk.

Are there two camps,

- one unwilling to impose any such risk on users (i.e. close as
  won’t-fix <https://issues.guix.gnu.org/45692> and remove traces of
  ZFS)

- one “Worse is better” camp that likes to move fast and break things?
  I think of
  <https://lists.gnu.org/archive/html/guix-devel/2021-09/msg00220.html>,
  even though Katherine Cox-Buday did not get involved here at all.

Then who decides?

I don’t actually care about ZFS myself, but there should be a decision
because I think current badly supported ZFS makes people here unhappy.

Regards,
Florian

ZFS part of Guix? RFC? (Re: Effectively force all GNOME users to locally compile ZFS?)

[pelzflorian (Florian Pelz)]

Hello Denis.  Thank you for your write-up.

raid5atemyhomework wrote patches to add ZFS to Guix
.  I put them in CC.  That there is
no decision on ZFS and their patches is bad.  Maybe their patches
would be for the RFC model to decide?

As for Denis’ arguments
:

IANAL but I would dispute this:

On Sun, Nov 21, 2021 at 02:33:24AM +0100, Denis 'GNUtoo' Carikli wrote:
> If I take individual drivers from Linux which are under the GPLv2 or
> the GPLv2 or later, and I combine them in a new combined work on a new
> git repository with code under the CDDL license, this is not legal
> either. And here too I hope that there is some consensus on that too.

If we are talking about source code, the GPLv2 files and the CDDL
files are not intertwined into a combined work at all.  They are just
in the same git repo on the same file-system.

However I agree that ZFS is unsafe territory; courts might decide
otherwise.

Regards,
Florian

Re: Mailman packaging (was: Re: Python package naming: Dots vs hyphens)

[pelzflorian (Florian Pelz)]

Hello Christine,

On Wed, Sep 29, 2021 at 12:34:06PM -0400, Christine Lemmer-Webber wrote:
> Has anyone worked on this or used it in recent times?

Sorry no, it was too much for me.

> The above link no
> longer works.  However I see:
> 
>   https://gitlab.com/genenetwork/guix-bioinformatics/-/tree/wip-mailman
> 
> ... which hasn't seen activity for about a year, but seems promising?

Note that Mailman-core is not enough, you will need hyperkitty and an
MTA and such things.

There are other Django services in Guix by now (Patchwork); perhaps it
will be similar, I have not tried.

Regards,
Florian

Re: bug#47867: [1.2.1 pre-release testing] substitute downloading and TLS errors

[pelzflorian (Florian Pelz)]

On Sat, Apr 24, 2021 at 07:13:01PM +0200, Ludovic Courtès wrote:
> I’ve pushed these as two separate patches:
> 
>   c50db7156d http-client: Remove exception mishandling in 'http-multiple-get'.
>   02d62978f4 http-client, substitute: Gracefully handle GnuTLS EAGAIN/EINTR.

I assume they will be cherry-picked to the version-1.3.0 branch and
the guix package will be updated.

> This bug should be gone now.

Yes, after and only after locally updating the guix package I can
create good installer images.

Closing.

Note though that "Guu, Jin-Cheng"  reported the TLS
errors before me, but to guix-devel and not as a bug report.

> I’ll go ahead and fix ‘write_to_session_record_port’ in GnuTLS.

Thank you for all the work!

Regards,
Florian

Re: bug#47867: [1.2.1 pre-release testing] substitute downloading and TLS errors

[pelzflorian (Florian Pelz)]

Success!  Thank you.
65;6003;1c
On Fri, Apr 23, 2021 at 11:19:28AM +0200, Ludovic Courtès wrote:
> Florian, could you try again with the attached patch?

It succeeds on two full installs of Enlightenment, no errors, no
prolonged getting stuck.


> If you have the courage, it would be awesome if you could also try the
> patch without the ‘error/again’ bits.

This fails.  I tried with

-(unless (false-if-networking-error
- (begin
-   (for-each (cut write-request <> buffer) batch)
-   (put-bytevector p (get))
-   (force-output p)
-   #t))
-  ;; If PORT becomes unusable, open a fresh connection and retry.
-  (close-port p)  ; close the broken port
-  (connect #f requests result)))
+;; Swallow networking errors that could occur due to connection reuse
+;; and the like; they will be handled down the road when trying to
+;; read responses.
+(false-if-networking-error
+ (begin
+   (for-each (cut write-request <> buffer) batch)
+   (put-bytevector p (get))
+   (force-output p


only and not the rest of your patch, on Guix git master where the full
patch had worked, it fails again with TLS errors (the same error of
Resource temporarily unavailable in procedure
'write_to_session_record_port') after downloading the enlightenment
substitute.


> I double-checked and the GnuTLS Guile bindings already
> handle GNUTLS_E_AGAIN and GNUTLS_E_INTERRUPTED, so my guess is that this
> was just a side effect of dealing with stale TLS sessions:
>   https://gitlab.com/gnutls/gnutls/-/blob/master/guile/src/core.c#L1042

Strange,.

Regards,
Florian

Re: bug#47867: [1.2.1 pre-release testing] substitute downloading and TLS errors

[pelzflorian (Florian Pelz)]

Sorry for the slow response.

On Wed, Apr 21, 2021 at 12:38:58AM +0200, Ludovic Courtès wrote:
> Hi Florian,
> 
> "pelzflorian (Florian Pelz)"  skribis:
> > On Tue, Apr 20, 2021 at 03:21:13AM +0200, pelzflorian (Florian Pelz) wrote:
> >> > git revert be5a75ebb5988b87b2392e2113f6590f353dd6cd
> > It seems this is the bad commit.  Downloading the enlightenment
> > substitute got stuck and after a few minutes displayed the usual TLS
> > error.
> Note that on master there have been changes in this area since this
> commit, in particular 20c08a8a45d0f137ead7c05e720456b2aea44402.

I have tested 20c08a in my reverts, it is neither the bad commit nor
does it fix it.
> I assume the error we’re after is still this one:
> 
> >>|substitute: updating substitutes from 'https://ci.guix.gnu.org'... 
> >> 0.0%guix substitute: error: TSL error in procedure 
> >> 'write_to_session_port': Resource temporarily unavailable, try again.

Yes.

> I believe the attached patch “addresses” this problem.

It still gets stuck (sometimes with enlightenment, one time with
udisks, restarting the install fixed it once).  After getting stuck,
this different error message is shown now; no TLS error (copied by
manual typing, there may be typos):

gtk-doc-1.28  653KiB2.4MiB/s 00:00 [] 100.0%
udisks-2.8.4  842KiB1.6MiB/s 00:00 [] 100.0%

substitute: updating substitutes from 'https://ci.guix.gnu.org'... 
100.0%Backtrace:
substitute: In ice-9/boot-9.scm:
substitute:   1736:10 17 (with-exception-handler _ _ #:unwind? _ # _)
substitute: In unknown file:
substitute:   16 (apply-smob/0 #)
substitute: In ice-9/boot-9.scm:
substitute: 718:2 15 (call-with-prompt _ _ #)
substitute: In ice-9/eval.scm:
substitute: 619:8 14 (_ #(#(#)))
substitute: In guix/ui.scm:
substitute:   2164:12 13 (run-guix-command _ . _)
substitute: In ice-9/boot-9.scm:
substitute:   1736:10 12 (with-exception-handler _ _ #:unwind? _ # _)
substitute:   1736:10 11 (with-exception-handler _ _ #:unwind? _ # _)
substitute:   1731:15 10 (with-exception-handler _ _ #:unwind? _ # _)
substitute: In guix/scripts/substitute.scm:
substitute:745:18  9 (_)
substitute:346:26  8 (process-query # _ #:cache-urls _ 
#:acl _)
substitute: In guix/substitutes.scm:
substitute:358:27  7 (lookup-narinfos/diverse _ _ #
substitute:315:31  6 (lookup-narinfos _ _ #:open-connection _ # _)
substitute:238:26  5 (fetch-narinfos _ _ #:open-connection _ # _)
substitute: In ice-9/boot-9.scm:
substitute:   1669:16  4 (raise-exception _ #:continuable? _)
substitute:   1669:16  3 (raise-exception _ #:continuable? _)
substitute:   1764:13  2 (_ #< _ components: 
assertion-fail…>)
substitute:   1669:16  1 (raise-exception _ #:continuable? _)
substitute:   1669:16  0 (raise-exception _ #:continuable? _)
substitute:
substitute: In ice-9/boot-9.scm:1669:16 In procedure raise-exception:
substitute: In procedure %read-line: Wrong type argument in position 1 
(expecting open input port): #
guix system: error: 
`/gnu/store/k3n98i1fk9awd5ydv4ry4k4rlpp7i13m7-guix-1.2.0-22.c467718/bin/guix 
substitute' died unexpectedly

Command failed with exit code 1.
Press Enter to continue.

> Can you reproduce the substitute issue in a simpler environment?
> For instance, by running:
> 
>   rm -rf ~/.cache/guix/substitute/
>   ./pre-inst-env guix weather $(guix package -A |head -2000 |cut -f1) 

Nope, this always works without issue.  Ricardo had written about TLS
errors with 0ad some two or three days ago, but I do not get errors
with 0ad.  The issue is present when installing Enlightenment DE from
the installer on both my Macbook and my Beebox every time, but not
when installing to a VM (but maybe it was just luck)

Regards,
Florian

Re: bug#47867: [1.2.1 pre-release testing] substitute downloading and TLS errors

[pelzflorian (Florian Pelz)]

On Tue, Apr 20, 2021 at 02:00:54PM -0400, Leo Famulari wrote:
> On Tue, Apr 20, 2021 at 07:03:26PM +0200, pelzflorian (Florian Pelz) wrote:
> > On Tue, Apr 20, 2021 at 05:27:54PM +0200, pelzflorian (Florian Pelz) wrote:
> > > It seems this is the bad commit.  Downloading the enlightenment
> > > substitute got stuck and after a few minutes displayed the usual TLS
> > > error.
> > 
> > P.S. There are no issues on my Macbook on the same internet
> > connection, the issue is only with the Beebox PC.
> 
> To clarify, you're running the same Guix on both machines, but it only
> fails on one of them?

No sorry I was mistaken, sorry for misguiding you.

I had thought so, but the actions were different on both machines.
Only full installs fail.

Doing a full install with the Enlightenment desktop environment fails
with TLS errors on the Beebox PC.

guix build enlightenment succeeds on the Macbook (with same Guix
commit), but

Running
mount /dev/sda2 /mnt
guile -c '((@ (gnu build install) mount-cow-store) "/mnt" "/tmp/guix-inst")'
guix build enlightenment
succeeds though.  (Without mount-cow-store disk space is insufficient.)

So I will try to do a full reinstall with Enlightenment on the Macbook
now after a backup.

Regards,
Florian

Re: bug#47867: [1.2.1 pre-release testing] substitute downloading and TLS errors

[pelzflorian (Florian Pelz)]

On Tue, Apr 20, 2021 at 05:27:54PM +0200, pelzflorian (Florian Pelz) wrote:
> On Tue, Apr 20, 2021 at 03:21:13AM +0200, pelzflorian (Florian Pelz) wrote:
> > > git revert be5a75ebb5988b87b2392e2113f6590f353dd6cd
> 
> It seems this is the bad commit.  Downloading the enlightenment
> substitute got stuck and after a few minutes displayed the usual TLS
> error.

P.S. There are no issues on my Macbook on the same internet
connection, the issue is only with the Beebox PC.

Regards,
Florian

Re: bug#47867: [1.2.1 pre-release testing] substitute downloading and TLS errors

[pelzflorian (Florian Pelz)]

On Tue, Apr 20, 2021 at 03:21:13AM +0200, pelzflorian (Florian Pelz) wrote:
> > git revert be5a75ebb5988b87b2392e2113f6590f353dd6cd

It seems this is the bad commit.  Downloading the enlightenment
substitute got stuck and after a few minutes displayed the usual TLS
error.

Regards,
Florian

Re: bug#47867: [1.2.1 pre-release testing] substitute downloading and TLS errors

[pelzflorian (Florian Pelz)]

After flashing the CMOS I can test again.

Without reverts TLS errors happen while or after downloading the
enlightenment substitute from the installer.

With all of those reverts *no* TLS errors happen:

On Mon, Apr 19, 2021 at 10:05:25AM +0200, pelzflorian (Florian Pelz) wrote:
> git revert 2d73086262e1fb33cd0f0f16f74a495fe06b38aa
> git revert 673e5276f6b4dda4bfa9dd5bb70220fc8b17abd2
> git revert 45fce38fb0b6c6796906149ade145b8d3594c1c6
> git revert 9da5ec7099b992a8969a17627548cd341c01bd90
> git revert c5ab78f90b111839508d0ab10c0e5ac2038002ca
> git revert b48204259aa9cad80c5b23a4060e2d796007ec7a
> git revert c37e3b92ad0334ba2fe7ee4e98631f0a4edeee21
> git revert 728c90862eb967a1679efdb69e26d7ba37cdc3a3
> git revert fd5b77503e852b78a43e1bee4d6bdfbbb1f27e8f
> git revert 112692c0d546d35cd67c5dc70dbd1dc609b18f64
> git revert ee3226e9d54891c7e696912245e4904435be191c
> git revert e2572aa95007558b008f04decff095f46d20e087
> git revert 20c08a8a45d0f137ead7c05e720456b2aea44402
> git revert 187e97096825d2bcceb144cead6eccc27385acd7
> git revert 8116cc66733134a8fb6f9117d4648288b83c8356
> git revert b9d058e3f7982eed04cc748cc0b24173a3969c52
> git revert 7c85877fdf964694061e3192eac35723ebc047bf
> git revert f50f5751fff4cfc6d5abba9681054569694b7a5c
> git revert 05f38ca8dccc49d9ec70d1f63461976b97d74d52
> git revert 7b812f7c84c43455cdd68a0e51b6ded018afcc8e
> git revert f50b501a7472f4f237023831aa415a948115d1d1
> git revert 205833b72c5517915a47a50dbe28e7024dc74e57
> git revert e2e853ddb0d964e7b0300334ab51ab89950c2376
> git revert 87734503a4a1761a4432b601352e5b02340a97f0
> git revert 08acee2f98321d57c4faa3ba641a5543b74f10a4
> git revert fbd61b5d3de353bfa468641d087bc53aaa1e63a5
> git revert be5a75ebb5988b87b2392e2113f6590f353dd6cd

The bad commit must be one of those.
c7c7f068c15e419aaf5ef616516aa5ad4e55c2fa is not the problem.

I will bisect tomorrow.

Regards,
Florian

Re: bug#47867: [1.2.1 pre-release testing] substitute downloading and TLS errors

[pelzflorian (Florian Pelz)]

On Mon, Apr 19, 2021 at 10:05:25AM +0200, pelzflorian (Florian Pelz) wrote:
> I will bisect which reverts are needed, but it takes time …

My UEFI broke; the PC cannot display anything anymore.  Don’t wait for
my debugging.

Re: bug#47867: [1.2.1 pre-release testing] substitute downloading and TLS errors

[pelzflorian (Florian Pelz)]

On Mon, Apr 19, 2021 at 10:05:25AM +0200, pelzflorian (Florian Pelz) wrote:
> I dd’d the resulting image to a USB drive and the TLS errors no longer
> appear (tried installing everything two times now; without reverts
> downloading enlightenment needed retrys everytime).
> […] I suspect restarting the
> install causes grub-install to fail because it cannot find /boot/efi
> anymore, but maybe my grub-install error had other reasons.

No sorry, grub-install still fails, even with no TLS errors no prior
installation restarts.  grub-install failing is an unrelated bug.  I
had not let the install run past the “copying everthing to /mnt” step
last time.

Re: bug#47867: [1.2.1 pre-release testing] substitute downloading and TLS errors

[pelzflorian (Florian Pelz)]

On Sun, Apr 18, 2021 at 02:10:06PM +0200, pelzflorian (Florian Pelz) wrote:
> On IRC Ricardo/rekado suspected
> c7c7f068c15e419aaf5ef616516aa5ad4e55c2fa, I will try reverting it.

It was necessary to revert follow-up commits before reverting
c7c7f068c15e419aaf5ef616516aa5ad4e55c2fa.

I tried on Guix master commit fef2f08bc640f78cc0a86fc7be3eccbc07b5e98c
the following commands:

sed -i '/vi/d' po/packages/LINGUAS #otherwise errors; Julien fixed this by now 
I think
git add po/packages/LINGUAS
git commit -m fixLINGUAS
git revert 2d73086262e1fb33cd0f0f16f74a495fe06b38aa
git revert 673e5276f6b4dda4bfa9dd5bb70220fc8b17abd2
git revert 45fce38fb0b6c6796906149ade145b8d3594c1c6
git revert 9da5ec7099b992a8969a17627548cd341c01bd90
git revert c5ab78f90b111839508d0ab10c0e5ac2038002ca
git revert b48204259aa9cad80c5b23a4060e2d796007ec7a
git revert c37e3b92ad0334ba2fe7ee4e98631f0a4edeee21
git revert 728c90862eb967a1679efdb69e26d7ba37cdc3a3
git revert fd5b77503e852b78a43e1bee4d6bdfbbb1f27e8f
git revert 112692c0d546d35cd67c5dc70dbd1dc609b18f64
git revert ee3226e9d54891c7e696912245e4904435be191c
git revert e2572aa95007558b008f04decff095f46d20e087
git revert 20c08a8a45d0f137ead7c05e720456b2aea44402
git revert 187e97096825d2bcceb144cead6eccc27385acd7
git revert 8116cc66733134a8fb6f9117d4648288b83c8356
git revert b9d058e3f7982eed04cc748cc0b24173a3969c52
git revert 7c85877fdf964694061e3192eac35723ebc047bf
git revert f50f5751fff4cfc6d5abba9681054569694b7a5c
git revert 05f38ca8dccc49d9ec70d1f63461976b97d74d52
git revert 7b812f7c84c43455cdd68a0e51b6ded018afcc8e
git revert f50b501a7472f4f237023831aa415a948115d1d1
git revert 205833b72c5517915a47a50dbe28e7024dc74e57
git revert e2e853ddb0d964e7b0300334ab51ab89950c2376
git revert 87734503a4a1761a4432b601352e5b02340a97f0
git revert 08acee2f98321d57c4faa3ba641a5543b74f10a4
git revert fbd61b5d3de353bfa468641d087bc53aaa1e63a5
git revert be5a75ebb5988b87b2392e2113f6590f353dd6cd
git revert c7c7f068c15e419aaf5ef616516aa5ad4e55c2fa
./bootstrap
./configure --localstatedir=/var
make
GUIX_ALLOW_ME_TO_USE_PRIVATE_COMMIT=y make update-guix-package
# disabling #:tests? on the guix package was *not* necessary once all reverts 
were in place
make
./pre-inst-env guix system image -t iso9660 gnu/system/install.scm

I dd’d the resulting image to a USB drive and the TLS errors no longer
appear (tried installing everything two times now; without reverts
downloading enlightenment needed retrys everytime).

I suppose if we leave this bug in the new Guix release, then some
substitutes like enlightenment get stuck and fail to download for some
people and therefore the installation fails.  I suspect restarting the
install causes grub-install to fail because it cannot find /boot/efi
anymore, but maybe my grub-install error had other reasons.

I will bisect which reverts are needed, but it takes time …

Regards,
Florian

Re: bug#47867: [1.2.1 pre-release testing] substitute downloading and TLS errors

[pelzflorian (Florian Pelz)]

On Sun, Apr 18, 2021 at 01:33:37PM +0200, pelzflorian (Florian Pelz) wrote:
> (well with an unrelated error by
> grub-install that it could not determine the canonical path of
> /boot/efi).

Probably

> I will try reproducing, but Jin and me both had this
> error.

I got the error again with enlightenment.

On IRC Ricardo/rekado suspected
c7c7f068c15e419aaf5ef616516aa5ad4e55c2fa, I will try reverting it.

Regards,
Florian

Re: bug#47867: [1.2.1 pre-release testing] substitute downloading and TLS errors

[pelzflorian (Florian Pelz)]

On Sun, Apr 18, 2021 at 12:15:47PM +0200, Ludovic Courtès wrote:
> Was this in a VM?

No, an Asrock Beebox (real x86_64 hardware).


> Could it be that networking was unstable (e.g., you
> were running this over a flaky WiFi connection)?

It is a stable Ethernet connection.


> How reproducible is
> this?  Any tips on how to reproduce it?
> 
> I did a full bare-bones OS install in a VM, which went fine, but maybe
> that’s not representative of your setup.
> 
> Thanks,
> Ludo’.

The installer completed just now after continuing from the last
install step another time (well with an unrelated error by
grub-install that it could not determine the canonical path of
/boot/efi).  I will try reproducing, but Jin and me both had this
error.

Regards,
Florian

Re: bug#47867: [1.2.1 pre-release testing] substitute downloading and TLS errors

[pelzflorian (Florian Pelz)]

On Sun, Apr 18, 2021 at 11:48:47AM +0200, pelzflorian (Florian Pelz) wrote:
> On Sun, Apr 18, 2021 at 11:44:25AM +0200, pelzflorian (Florian Pelz) wrote:
> > But now after maybe 10 minutes it finally continued and died with the
> > same TLS error about write_to_session_record_port and Resource not
> > available.
> 
> The error happened while
> 
> substitute: updating substitutes from […]

After starting one more time from the last installer step it
downloaded the same enlightenment substitute again and got stuck the
same way.

Re: bug#47867: [1.2.1 pre-release testing] substitute downloading and TLS errors

[pelzflorian (Florian Pelz)]

On Sun, Apr 18, 2021 at 11:44:25AM +0200, pelzflorian (Florian Pelz) wrote:
> But now after maybe 10 minutes it finally continued and died with the
> same TLS error about write_to_session_record_port and Resource not
> available.

The error happened while

substitute: updating substitutes from […]

Re: bug#47867: [1.2.1 pre-release testing] substitute downloading and TLS errors

[pelzflorian (Florian Pelz)]

On Sun, Apr 18, 2021 at 11:38:56AM +0200, pelzflorian (Florian Pelz) wrote:
> I needed to restart the installer at the last step, this stopped while
> downloading enlightenment with no error but it does not continue.

Note: The last message was

enlightenment-0.24.2  27.0MiB  3.7MiB/s 00:07 
[] 100.0%

But now after maybe 10 minutes it finally continued and died with the
same TLS error about write_to_session_record_port and Resource not
available.

[1.2.1 pre-release testing] substitute downloading and TLS errors

[pelzflorian (Florian Pelz)]

On Fri, Apr 16, 2021 at 10:40:55PM -0500, jcguu95 wrote:
>2.2. Unexpected failure
> 
>After running `guix system init /mnt/etc/config.scm /mnt' for 5 to 10
>minutes, I got the error
> 
>,
>|substitute: updating substitutes from 'https://ci.guix.gnu.org'... 
> 0.0%guix substitute: error: TSL error in procedure 'write_to_session_port': 
> Resource temporarily unavailable, try again.
>| 
>|guix system: error: 
> `/gnu/store/1nmwil4cs...vc2p-guix-1.2.0-21.4dff6ec/bin/guix substitute` died 
> unexpectedly
>|root@gnu ~# _
>`
> 
>Retrying it did resolve the problem. And I got a working guix system
>out of it :)

I’ve got the same TLS error (though the procedure for me is
‘write_to_session_record_port’.

I needed to restart the installer at the last step, this stopped while
downloading enlightenment with no error but it does not continue.

Regards,
Florian

Re: 1.2.1 pre-release testing

[pelzflorian (Florian Pelz)]

On Sat, Apr 17, 2021 at 07:09:59PM -0500, Guu, Jin-Cheng wrote:
> Not sure if it's appropriate to say here.. but when I was installing,
> there was non-free kernel in my machine. And that's why my wifi was
> working.

If I remember correctly, on some machines the wifi only works after a
reboot from a non-free system.

> My machine is Lenovo's b50-80, which isn't on the site.

I find Z50 with working wifi and ethernet

and G50 with*out* working wifi
.
This won’t be fixed at the Guix level though.

Regards,
Florian

Re: 1.2.1 pre-release testing

[pelzflorian (Florian Pelz)]

Hello Jin,

On Sat, Apr 17, 2021 at 01:27:09PM -0400, Leo Famulari wrote:
> I re-installed my Guix System based on the ISO found here:
> 
> https://ci.guix.gnu.org/build/175632/details
> 
> That's '/gnu/store/lw1j4gn8h51cbfp9dg0g025ngkg83sw1-image.iso.drv'.

Ethernet works on the four machines I tested.  Probably it is an issue
with missing hardware support in the Linux-libre kernel, but you could
try again or look at h-node.org if they have or have not listed your
laptop having working Ethernet.

Regards,
Florian

Re: 1.2.1 pre-release testing

[pelzflorian (Florian Pelz)]

Hello Jin,

On Sat, Apr 17, 2021 at 07:58:30AM -0500, Guu, Jin-Cheng wrote:
> > Does the ethernet cable work on the installed system?  Or on other
> > free distros?
> 
> It has never failed on me before, even when I was installing arch
> linux. So I was a bit surprise yesterday.

Arch ships with non-free drivers and firmware.

> It had also worked before in
> the Guix System I got from the official - so I suppose that's a
> completely free distro.

If you had used Guix System on the same Ethernet connection on the
same machine, no nonfree channels and it worked, then the installer
image is at fault.  I will test later today if there is anything is
wrong on any of my machines.

Regards,
Florian

Re: 1.2.1 pre-release testing

[pelzflorian (Florian Pelz)]

Hello Jin.  Thank you for testing!

On Fri, Apr 16, 2021 at 10:40:55PM -0500, jcguu95 wrote:
> 1. Graphical Installation
> 
>I chose the graphical method for the first installation. Everything
>went well, except my wired internet connection failed as it
>indicated. Weirdly enough, my ethernet cable has been always on my
>machine for a while, and never failed. […]

Does the ethernet cable work on the installed system?  Or on other
free distros?

In the distant past, I had trouble using the built-in Ethernet on my
11-year old Macbook until (I think) a newer Linux-libre kernel release
added support.  Maybe this is similar.

If Ethernet is only broken in the installer though, then the installer
is at fault.

Regards,
Florian

Re: Building the web site is slow

[pelzflorian (Florian Pelz)]

On Mon, Nov 23, 2020 at 11:46:08PM +0100, pelzflorian (Florian Pelz) wrote:
> It is funny, when I try to profile via
> 
> cd ~/src/guix-artwork/website
> guix install -p haunt-profile guile-syntax-highlight guile-commonmark haunt
> LC_ALL=en_US.utf8 \
>  GUILE_LOAD_PATH=haunt-profile/share/guile/site/3.0:$GUILE_LOAD_PATH \
>  /gnu/store/18hp7flyb3yid3yp49i6qcdq0sbi5l1n-guile-3.0.2/bin/guile
> scheme@(guile-user)> ,profile ((@ (haunt ui) haunt-main) "haunt" "build")
> 
> it crashes, but only when using ,profile.  I will investigate
> tomorrow.

The crash is prevented by deleting ~/.cache/guile and additionally
launching guile with --no-auto-compile.  I wonder if a compiled file
even had the right translation or if the macro-expanded translation
would be part of the compiled file.

The profile log is attached.  I will investigate next week.

Regards,
Florian
build completed successfully
% cumulative   self 
time   seconds seconds  procedure
  8.75 59.50 54.85  anon #x85c3d0
  6.54 41.02 40.98  anon #x863de0
  6.22 38.97 38.97  ice-9/eval.scm:123:11
  4.71 29.55 29.52  ice-9/eval.scm:333:13
  3.03 19.02 19.02  ice-9/eval.scm:182:7
  3.00 18.86 18.79  anon #x861cb8
  2.52   8908.74 15.76  ice-9/eval.scm:292:11
  2.31 14.49 14.49  ice-9/eval.scm:604:6
  2.26 15.57 14.18  anon #x862858
  2.16 13.60 13.56  anon #x85d560
  1.97 84.71 12.36  ice-9/format.scm:39:0:format
  1.82 58.99 11.39  ice-9/format.scm:113:2:format:format-work
  1.67   1186.44 10.46  ice-9/eval.scm:159:9
  1.58  9.88  9.88  anon #x866cf4
  1.43  8.95  8.95  ice-9/eval.scm:124:11
  1.37  8.56  8.56  anon #x85d978
  1.34  8.41  8.41  ice-9/eval.scm:273:7
  1.34  8.75  8.37  ice-9/psyntax.scm:749:8:search
  1.34  8.37  8.37  anon #x85bbb8
  1.32  8.29  8.29  ice-9/eval.scm:125:11
  1.30  8.13  8.13  anon #x863e88
  1.23941.87  7.71  ice-9/eval.scm:155:9
  1.13  7.09  7.09  ice-9/eval.scm:226:7
  1.11  6.97  6.97  anon #x85eef8
  1.05  7.32  6.58  ice-9/popen.scm:145:0:reap-pipes
  1.04  6.51  6.51  anon #x85d590
  0.99 15.46  6.20  ice-9/boot-9.scm:3128:0:module-gensym
  0.94  5.97  5.89  ice-9/eval.scm:339:13
  0.83  5.27  5.23  anon #x85e550
  0.79  4.92  4.92  anon #x85f8e8
  0.75  4.69  4.69  ice-9/eval.scm:282:4
  0.70 57.64  4.42  ice-9/eval.scm:259:9
  0.66  4.14  4.14  anon #x867250
  0.64   8397.56  3.99  ice-9/eval.scm:40:0:primitive-eval
  0.60  3.76  3.76  anon #x866590
  0.58  3.68  3.64  anon #x8661a0
  0.57  3.60  3.60  ice-9/eval.scm:222:7
  0.56191.31  3.52  ice-9/eval.scm:202:12
  0.56 10.42  3.49  ice-9/eval.scm:278:9
  0.53  3.29  3.29  anon #x862828
  0.51  3.18  3.18  ice-9/eval.scm:224:11
  0.49 22.12  3.10  ice-9/eval.scm:263:9
  0.49  3.06  3.06  anon #x85e520
  0.46  3.87  2.91  texinfo/string-utils.scm:98:5
  0.46  2.91  2.91  anon #x863f5c
  0.45  2.79  2.79  anon #x85bd88
  0.44 21.07  2.75  ice-9/psyntax.scm:855:4:resolve-identifier
  0.44  2.75  2.75  anon #x8670e8
  0.41  2.56  2.56  ice-9/eval.scm:126:12
  0.40  2.48  2.48  anon #x85d788
  0.39  2.44  2.44  anon #x85c91c
  0.38  2.36  2.36  anon #x8665c0
  0.38  2.36  2.36  anon #x8652d0
  0.37 35.75  2.32  ice-9/format.scm:759:2:format:out-obj-padded
  0.36208.28  2.25  ice-9/psyntax.scm:1527:8:rebuild-macro-output
  0.36  2.25  2.25  anon #x8665f0
  0.34  6.66  2.13  ice-9/eval.scm:159:9
  0.33  2.32  2.09  ice-9/eval.scm:417:6
  0.33  2.09  2.09  anon #x85e7c8
  0.32   2822.35  1.98  ice-9/eval.scm:618:6
  0.32  3.52  1.98  ice-9/eval.scm:259:9
  0.30  1.90  1.90  ice-9/eval.scm:329:11
  0.30  1.86  1.86  ice-9/boot-9.scm:1738:4:throw
  0.29  16781.40  1.82  ice-9/threads.scm:388:4
  0.29 63.45  1.82  ice-9/eval.scm:586:29
  0.29  1.82  1.82  anon #x866620
  0.28  1.74  1.74  anon #x85e798
  0.27  1.67  1.67  anon #x861978
  0.26 98.15  1.63  ice-9/psyntax.scm:1319:4:syntax-type
  0.26  5.11  1.63  ice-9/psyntax.scm:3001:6:match
  0.25  1.63  1.59  ice-9/eval.scm:336:13
  0.25  1.59  1.59  anon #x85c8b8
  0.25  1.55  1.55  anon #x866a78
  0.25  1.55  1.55  ice-9/eval.scm:590:16
  0.24 29.75  1.51  ice-9/psyntax.scm:2964:6:match*
  0.24  2.25  1.51  ice-9/eval.scm:263:9
  0.22  1.39  1.39  anon #x867780
  0.22  1.39  1.36  ice-9/boot-9.scm:3209:4
  0.22  1.36  1.36  srfi/srfi-1.scm:912:15
  0.21 10.73  1.32  ice-9/eval.scm:297:11
  0.20   2052.46  1.28  ice-9/boot-9.scm:253:2

Re: Building the web site is slow

[pelzflorian (Florian Pelz)]

OK, I now believe `haunt build` is what costs the time.

On Mon, Nov 23, 2020 at 11:46:08PM +0100, pelzflorian (Florian Pelz) wrote:
> Anyway, I am not sure the `haunt build` runs are the culprit.  If it
> is a problem with spinning disks only, maybe .guix.scm can be made to
> copy less from the same disk to the same disk but copy more from disk
> to a file system in RAM and from a file system in RAM to disk.

Negative, unless I misunderstood what /dev/shm is.  I did `time guix
build -f .guix.scm`:

real7m3.909s
user1m3.639s
sys 0m0.841s

Instead of `time` I now enclosed most of the build procedure in

(statprof (lambda () …))

% cumulative   self
time   seconds seconds  procedure
 18.62  2.13  2.11  ice-9/boot-9.scm:1738:4:throw
 14.81  1.68  1.68  display
 14.22  1.61  1.61  copy-file
  8.36  0.95  0.95  readdir
  6.89  0.78  0.78  mkdir
  4.11  0.47  0.47  opendir
  3.96  0.47  0.45  lstat
  2.20  0.25  0.25  ice-9/boot-9.scm:1202:6
  1.91  4.83  0.22  ice-9/boot-9.scm:1673:4:with-exception-handler
  1.91  0.22  0.22  string-append


I added at the beginning of the build procedure:

(let ((where "/dev/shm/website-construction-site"))
  (mkdir-p where)
  (chdir where))

Now I get

real7m4.632s
user1m4.254s
sys 0m0.744s

% cumulative   self
time   seconds seconds  procedure
 17.66  2.06  2.06  copy-file
 17.52  2.07  2.04  ice-9/boot-9.scm:1738:4:throw
  9.97  1.16  1.16  display
  8.40  0.98  0.98  mkdir
  8.26  0.98  0.96  readdir
  5.41  0.63  0.63  opendir
  3.85  0.46  0.45  lstat
  2.71  5.57  0.32  ice-9/boot-9.scm:1673:4:with-exception-handler
  2.14  0.25  0.25  string-append

I will instead try profiling haunt runs again.

Regards,
Florian

Re: Building the web site is slow

[pelzflorian (Florian Pelz)]

On Mon, Nov 23, 2020 at 11:46:17PM +0100, pelzflorian (Florian Pelz) wrote:
> it crashes, but only when using ,profile.  I will investigate
> tomorrow.

No sorry the crash is not due to ,profile.  It is when invoking Haunt
from Guile instead of haunt build.  haunt build must be doing
something special.  Strange.

Re: Building the web site is slow

[pelzflorian (Florian Pelz)]

On Mon, Nov 23, 2020 at 04:03:26PM +0100, Ludovic Courtès wrote:
> Do you think we could arrange
> to build all the languages in a single ‘haunt build’ run, would that
> help?

What kept me from doing a single `haunt build` run are two things.
The lesser is that, when not using .guix.scm, running `haunt build`
builds only the current locale when testing, which is quick.  Only
when building all languages via .guix.scm it becomes slow.

But the real reason for using multiple haunt invocations
is that the website i18n runs as a macro when
loading a Scheme file.  That is, if a Scheme file contains

(G_ `(a (@ (href ,(guix-url "contribute/"))) "Git repositories"))

then the G_ macro will use gettext with the currently set locale to
change it to, for example

`(a (@ (href ,(guix-url "contribute/"))) "repositorios Git")

All this runs at macro expansion time before procedure calls like
guix-url unlike regular gettext.  That is, it runs when Haunt first
processes the G_.  If the same invocation of Haunt is to process the
G_ for multiple translations, it would somehow have to unload and
macro expand the code a second time.

Anyway, I am not sure the `haunt build` runs are the culprit.  If it
is a problem with spinning disks only, maybe .guix.scm can be made to
copy less from the same disk to the same disk but copy more from disk
to a file system in RAM and from a file system in RAM to disk.


> I haven’t tried profiling yet, but I can take a look.
> 
> Ludo’.

It is funny, when I try to profile via

cd ~/src/guix-artwork/website
guix install -p haunt-profile guile-syntax-highlight guile-commonmark haunt
LC_ALL=en_US.utf8 \
 GUILE_LOAD_PATH=haunt-profile/share/guile/site/3.0:$GUILE_LOAD_PATH \
 /gnu/store/18hp7flyb3yid3yp49i6qcdq0sbi5l1n-guile-3.0.2/bin/guile
scheme@(guile-user)> ,profile ((@ (haunt ui) haunt-main) "haunt" "build")

it crashes, but only when using ,profile.  I will investigate
tomorrow.

Regards,
Florian

Re: GNU Guix 1.2.0rc1 available for testing!

[pelzflorian (Florian Pelz)]

On Tue, Nov 17, 2020 at 03:41:34PM +0100, Ludovic Courtès wrote:
> One this patch is in, I think we’re ready for either an RC2 or the real
> thing.
> 
> WDYT?
> 
> Ludo’.

With the patch I see no problems on x86_64 Guix system, install script
or VM, but I have no idea of current Guix bugs.

Regards,
Florian

Re: GNU Guix 1.2.0rc1 available for testing!

[pelzflorian (Florian Pelz)]

On Tue, Nov 17, 2020 at 10:02:33AM +0100, Mathieu Othacehe wrote:
> That's good news! Here's a more complete patch that I intend to push on
> the 1.2.0 branch. It logs the time spent waiting for disk
> synchronization.
> 
> It would be great if you could test it one more time, so that we know if
> 4 seconds is enough or if we should use an even higher delay.
> 
> Thanks again,
> 
> Mathieu


It succeeded three times in a row.

Regards,
Florian

Re: GNU Guix 1.2.0rc1 available for testing!

[pelzflorian (Florian Pelz)]

On Mon, Nov 16, 2020 at 10:12:09AM +0100, Mathieu Othacehe wrote:
> Many thanks (again) for your help here! According to the backtrace you
> sent earlier in this thread, it looks like the crash occurs in the
> "free-parted" procedure.
> 
> This procedure tries to unallocate Parted resources and waits for the
> partition table changes to be synchronized to disk. The
> "with-delay-device-in-use?" tries 4 times every 250ms to detect if the
> device is still in use.
> 
> Maybe it takes longer on your HW to synchronize the partition tables. If
> you could test the attached patch on top of 1.2.0 it would be terrific.
> 
> Thanks,
> 
> Mathieu


Thank you for the quick patch!  Clearly you have been spot-on.
“Partition formatting is in progress, please wait” is displayed
considerably longer but eventually succeeds.  I tried 3 times
successfully with your patch.  I tried again without your patch and it
failed.  I tried once more with your patch and formatting succeeded
again.

(Install failed due to a loss of network connectivity and restarting
is impossible, but that is less important, normally all works.)

Regards,
Florian

Re: GNU Guix 1.2.0rc1 available for testing!

[pelzflorian (Florian Pelz)]

On Sun, Nov 15, 2020 at 10:53:29PM +0100, Marius Bakke wrote:
> I have just installed a system using manual partitioning through the
> installer, with encryption.  Everything worked like a charm.
> 
> Can you provide more details about the steps you did to arrive at the
> error?  And information about the (new and old) partition layout?

Thank you for trying.  Hmm strange.  I tried once again (I think I did
the same steps as before) and it worked.  Maybe I forgot something?
Maybe it depends on how fast the machine completes a formatting task?
So I tried again two more times and it failed again, I got the error
again both times during partition formatting.

So all the partitioning is already done except for the encryption.
/dev/sdc is the install USB drive.  /dev/sda is the hard disk.
/dev/sda1 is the EFI system partition; I do not format it.  /dev/sda5
is the partition I try to put the encrypted root fs on.  I check
encryption and set its mount point to “/”.

/var/log/messages has the following log for the installer:

Nov 15 23:49:30 localhost installer[259]: Display is 128x42. 
Nov 15 23:49:30 localhost installer[259]: running step 'locale' 
Nov 15 23:49:30 localhost installer[259]: running step 'language' 
Nov 15 23:49:31 localhost installer[259]: running form # 
("Locale language") with 0 clients 
Nov 15 23:49:40 localhost vmunix: [   56.102132] tg3 :03:00.0 enp3s0: Link 
is down
Nov 15 23:49:40 localhost connmand[210]: enp3s0 {RX} 24 packets 3438 bytes
Nov 15 23:49:40 localhost connmand[210]: enp3s0 {TX} 31 packets 3795 bytes
Nov 15 23:49:40 localhost connmand[210]: enp3s0 {update} flags 36867 
Nov 15 23:49:40 localhost connmand[210]: enp3s0 {newlink} index 2 address 
10:9A:DD:46:4F:9F mtu 1500
Nov 15 23:49:40 localhost connmand[210]: enp3s0 {newlink} index 2 operstate 2 

Nov 15 23:49:40 localhost nscd: 211 monitored file `/etc/resolv.conf` was 
written to
Nov 15 23:49:40 localhost nscd: 211 monitored file `/etc/resolv.conf` was 
written to
Nov 15 23:49:40 localhost connmand[210]: enp3s0 {del} address 192.168.178.74/24 
label enp3s0
Nov 15 23:49:40 localhost connmand[210]: enp3s0 {del} route 192.168.178.0 gw 
0.0.0.0 scope 253 
Nov 15 23:49:40 localhost connmand[210]: enp3s0 {del} route fd00:: gw :: scope 
0 
Nov 15 23:49:40 localhost connmand[210]: enp3s0 {del} route fe80:: gw :: scope 
0 
Nov 15 23:49:40 localhost connmand[210]: enp3s0 {del} address 
fd00::129a:ddff:fe46:4f9f/64 label (null)
Nov 15 23:50:23 localhost installer[259]: running step 'territory' 
Nov 15 23:50:23 localhost installer[259]: running form # 
("Locale location") with 0 clients 
Nov 15 23:50:26 localhost installer[259]: running step 'codeset' 
Nov 15 23:50:26 localhost installer[259]: running step 'modifier' 
Nov 15 23:50:26 localhost shepherd[1]: Service console-font-tty2 has been 
stopped. 
Nov 15 23:50:26 localhost shepherd[1]: Service term-tty2 has been stopped. 
Nov 15 23:50:26 localhost shepherd[1]: Service host-name has been started. 
Nov 15 23:50:26 localhost shepherd[1]: Service term-tty2 has been started. 
Nov 15 23:50:26 localhost installer[259]: running step 'welcome' 
Nov 15 23:50:26 localhost installer[259]: running form # 
("GNU Guix install") with 0 clients 
Nov 15 23:50:27 localhost installer[259]: running step 'timezone' 
Nov 15 23:50:27 localhost installer[259]: running form # 
("Timezone") with 0 clients 
Nov 15 23:50:32 localhost installer[259]: running form # 
("Timezone") with 0 clients 
Nov 15 23:50:34 localhost installer[259]: running step 'keymap' 
Nov 15 23:50:34 localhost installer[259]: running step 'layout' 
Nov 15 23:50:34 localhost installer[259]: running form # 
("Layout") with 0 clients 
Nov 15 23:50:36 localhost installer[259]: running step 'variant' 
Nov 15 23:50:36 localhost installer[259]: running form # 
("Variant") with 0 clients 
Nov 15 23:50:41 localhost installer[259]: running step 'hostname' 
Nov 15 23:50:41 localhost installer[259]: running form # 
("Hostname") with 0 clients 
Nov 15 23:50:53 localhost installer[259]: running step 'network' 
Nov 15 23:50:53 localhost installer[259]: running step 'select-technology' 
Nov 15 23:50:53 localhost installer[259]: running step 'power-technology' 
Nov 15 23:50:54 localhost installer[259]: running step 'connect-service' 
Nov 15 23:50:54 localhost installer[259]: running form # ("No 
service") with 0 clients 
Nov 15 23:51:00 localhost vmunix: [  135.760473] tg3 :03:00.0 enp3s0: Link 
is up at 100 Mbps, full duplex
Nov 15 23:51:00 localhost vmunix: [  135.760478] tg3 :03:00.0 enp3s0: Flow 
control is on for TX and on for RX
Nov 15 23:51:00 localhost vmunix: [  135.760598] IPv6: ADDRCONF(NETDEV_CHANGE): 
enp3s0: link becomes ready
Nov 15 23:51:00 localhost connmand[210]: enp3s0 {add} route fe80:: gw :: scope 
0 
Nov 15 23:51:00 localhost connmand[210]: enp3s0 {RX} 24 packets 3438 bytes
Nov 15 23:51:00 localhost connmand[210]: enp3s0 {TX} 31 packets 3795 bytes
Nov 15 23:51:00 localhost connmand[210]: enp3s0 {update} flags 102467 

Re: GNU Guix 1.2.0rc1 available for testing!

[pelzflorian (Florian Pelz)]

On Fri, Nov 13, 2020 at 06:07:32PM +0100, Ludovic Courtès wrote:
>   system installation:
> […]
> 
> https://alpha.gnu.org/gnu/guix/guix-system-install-1.2.0rc1.x86_64-linux.iso.xz

Sorry for testing so late.  For me the graphical installer crashes
when doing a Manual Partitioning with an encrypted partition.
I attach the last-installer-error after Manual Partitioning.

Can others successfully use encryption with the installer?

Regards,
Florian
In ./gnu/installer/newt/partition.scm:
785:4 19 (run-partitioning-page)
In srfi/srfi-1.scm:
634:9 18 (for-each # ("/dev/sda" "/dev/sdb"))
In ./gnu/installer/parted.scm:
  1395:23 17 (_ _)
In ice-9/boot-9.scm:
  1669:16 16 (raise-exception _ #:continuable? _)
  1667:16 15 (raise-exception _ #:continuable? _)
  1667:16 14 (raise-exception _ #:continuable? _)
  1667:16 13 (raise-exception _ #:continuable? _)
  1667:16 12 (raise-exception _ #:continuable? _)
  1667:16 11 (raise-exception _ #:continuable? _)
  1667:16 10 (raise-exception _ #:continuable? _)
  1667:16  9 (raise-exception _ #:continuable? _)
  1667:16  8 (raise-exception _ #:continuable? _)
  1667:16  7 (raise-exception _ #:continuable? _)
  1764:13  6 (_ #< components: (#<> #< origin: 
#f> #< message: "~A"> #< irritants: ("Device /dev/sda is 
still in use.")> #<…>)
In ice-9/eval.scm:
619:8  5 (_ #(#(# #< name: 
newt init: # exit: # exit-error: 
# f…>) …))
619:8  4 (_ #(#(#(# #< 
name: newt init: # exit: # exit-error: 
#) …) #))
In ice-9/ports.scm:
   463:17  3 (call-with-output-file _ _ #:binary _ #:encoding _)
In ice-9/eval.scm:
619:8  2 (_ #(#(# misc-error (#f "~A" 
("Device /dev/sda is still in use.") #f)) #))
159:9  1 (_ #(#(# misc-error (#f "~A" 
("Device /dev/sda is still in use.") #f)) #))
In unknown file:
   0 (make-stack #t)
ice-9/eval.scm:159:9: Device /dev/sda is still in use.

Re: Branching for v1.2?

[pelzflorian (Florian Pelz)]

On Tue, Nov 03, 2020 at 01:51:18PM +0100, Tobias Geerinckx-Rice wrote:
> Thanks for your work on the German translation!  Could you incorporate this
> fix[0] back into the TP version? […]
> [0]: 
> http://git.savannah.gnu.org/cgit/guix.git/commit/?id=1aced9aa0c32849939d1facfaa0f3e5f1a6c11e0

> wenn [-@sasmp{/tftp/1.2.3.4}-]{+@samp{/tftp/1.2.3.4}+} existiert,

Done.  Thank you for fixing it!

Regards,
Florian

Re: Branching for v1.2?

[pelzflorian (Florian Pelz)]

On Mon, Nov 02, 2020 at 10:00:38AM -0500, Julien Lepiller wrote:
> Le 2 novembre 2020 08:20:34 GMT-05:00, "Miguel Ángel Arruga Vivas" 
>  a écrit :
> >With my translator hat on: a new tarball for TP has to be generated
> >before or after creating the branch (1.2.0-pre3).  If done tomorrow, I
> >think the translations could need a bit later than Friday to catch up;
> >Florian and Julien, what do you think?
> 
> I think I can manage the deadline on the 6th if there aren't too
> many changes, and we generate the tarball today or tomorrow. […]

That would be OK for me.

Regards,
Florian

Re: Update on the timeline for the release v1.2.

[pelzflorian (Florian Pelz)]

Thank you zimoun for managing all this!  About the string freeze:

On Mon, Oct 19, 2020 at 08:26:31PM +0200, Miguel Ángel Arruga Vivas wrote:
> zimoun  writes:
> > The proposed coming timeline is:
> >
> >  - freeze starting the Oct. 26th
> >  - last round for testing all over the week
> >  - unfreeze the Oct. 29th and then create the branch
> >  - minor bug fixes and all the papeword around (NEWS, blog, etc.)
> >  - release Nov. 6th.
> >
> > Does this timeline sound good,
> >
> > @Mathieu: to generate the various images?
> > @Marius: to merge staging?
> > @Translators: about the string-freeze,  almost 2 weeks?
> 
> From my side everything is A-OK, 2 weeks is more than enough to
> translate the delta with pre1 and to make the final fine-tune; more than
> that shouldn't be expected for the freeze period.  I hope I can do some
> extra work too... :)
> 
> Happy hacking!
> Miguel
> 

>From my side such a long string freeze is not needed, but perhaps a
long freeze is useful for other languages’ translators.  I don’t know.
I regularly sync my translation with a POT file from git master:

cd ~/src/guix
git pull
make doc-pot-update
msgmerge --previous --no-wrap --lang=de old-translations.po 
~/src/guix/po/doc/guix-manual.pot > new-translations.po

Regards,
Florian

Re: Commit access

[pelzflorian (Florian Pelz)]

On Sat, Oct 17, 2020 at 03:57:19PM +0200, Miguel Ángel Arruga Vivas wrote:
> Hello, everybody!
> 
> I'm happy to announce with this message my access to the repository and
> the key I'll use to sign the commits.  This text has been signed with
> it, which has the following information and fingerprint:
> 
> pub   rsa3072 2020-09-09 [SC] [expires: 2022-01-01]
>   888784C41459ACCB83E7E84C634C6E8979FABEC2
> uid   [ultimate] Miguel Ángel Arruga Vivas 
> sub   rsa3072 2020-09-09 [E] [expires: 2022-01-01]
> 
> Happy hacking!
> Miguel

I’m happy you’re with us!

Regards,
Florian

signature.asc
Description: PGP signature

Re: Call for 1.2 installer testing.

[pelzflorian (Florian Pelz)]

On Sun, Oct 11, 2020 at 05:23:30PM +1100, Brendan Tildesley wrote:
> Hi, I went through the installer looking for anything negative I could say
> about it :) hope there is something helpful here:

Thank you for testing!


> Unrelated driver bug: installer was just a black screen until I rebooted
> with nomodeset:  https://paste.debian.net/1166581/
> Even with nomodeset, I get an error about no UMS supported in radeon, but it
> doesn't stop anything.

This black screen regression should be “fixed” now (commit
34d436a4082b5c5f23b00e13eb8e5a92d957d704) by passing a kernel argument
“modprobe.blacklist=radeon” which disables the radeon driver.

(This was also blacklisted in the last release 1.1.0 of Guix, see
.  I had removed
“modprobe.blacklist=radeon” because it was for some time no longer
needed on one of my machines.)

Some users will have a black screen in the installed system as well
(if they use Linux-libre).  I don’t think we can do much about that.
Niels  only had trouble with the
installer but did not on the installed system.  It seems not feasible
to predict which users would have a black screen in the installed
system, so we cannot add instructions only for them.



> Languages listed in the language selection are sometimes in English, Rarely
> in the native language. […]
> Random thought: could we adapt the installer to use the same sentences from
> an existing installer, like the ubuntu one, so that all the translations can
> be copied in for free? All the basic quesions like please choose a password
> are surely shared between these installers.

Yes, we could copy translations without understanding the language (at
least after our planned switch from the Translation Project to our own
hosted Weblate translation infrastructure).

Regards,
Florian

Re: Release v1.2 timetable

[pelzflorian (Florian Pelz)]

On Tue, Sep 29, 2020 at 02:16:30PM +0200, zimoun wrote:
> To help the release process, please:
> […]
>  d. translate

Julien, shall I just push my translation without going through the TP?

Regards,
Florian

Re: Translating the web site

[pelzflorian (Florian Pelz)]

On Thu, Sep 24, 2020 at 09:31:19AM -0400, Julien Lepiller wrote:
> I'll try to contact everyone today, but some of these emails might
> end up in a spam folder, because my server is so small. Can you also
> send something to the translators alias?

So aside from Julien and me that’s,
(from the French PO file) Simon Tournier,
(from the German PO file) Mario Blättermann, Jonathan Brielmaier,
(from the Russian PO file) znavko, Pavlo Marianov, Adam,
(for Spanish) Miguel, (for Chinese) Meiyo Peng, and, I
wonder, have Ali Reza Hayati and Amin Bandali been working on the
manual already; are they listed as part of the guix-i...@gnu.org?
They had asked how they could help with translating on
.

Regards,
Florian

etc/news copyright (was Re: Translating the web site)

[pelzflorian (Florian Pelz)]

On Thu, Sep 24, 2020 at 09:25:56AM +0200, Ludovic Courtès wrote:
> Julien Lepiller  skribis:
> > To get the project, we need to clarify the license on the translation 
> > files, as we discussed before. How should we proceed on that?
> 
> There was a question about copyright holders for translations; to me
> it’s clearly individual translators, and translations that indicate
> otherwise are probably the result of misconfiguration in ‘Makevars’
> and/or copy/paste.
> 
> The PO files at  and
>  state:
> 
>   This file is distributed under the same license as the guix package.
> 
> which is perfect.
> 
> Those at  have
> the same statement, but it should rather be the same license as the
> manual (GFDL).  Perhaps a ‘Makevars’ issue too?  Since there are a
> handful of translators involved, we can probably just contact them and
> change that sentence.
> 
> Thoughts?
> 
> Ludo’.

I’m fine with any licensing changes you see fit.

I guess we should add proper copyright notices to etc/news.scm too?

Sorry for not starting its translations with a proper copyright, but I
wasn’t sure because of etc/news.scm’s license:

“;; Copying and distribution of this file, with or without modification, are
;; permitted in any medium without royalty provided the copyright notice and
;; this notice are preserved.”

I attach a patch adding copyright notices, but I guess the authors
should agree.  I put them in Cc.

Regards,
Florian
>From c84d333eea4ed5a654214d5cfa3186237c57bd69 Mon Sep 17 00:00:00 2001
From: Florian Pelz 
Date: Thu, 24 Sep 2020 10:37:51 +0200
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Subject: [PATCH] news: Update copyright.

* etc/news.scm: Add missing copyright headers.
---
 etc/news.scm | 5 +
 1 file changed, 5 insertions(+)

diff --git a/etc/news.scm b/etc/news.scm
index 1ef238ca2d..86c1555fc7 100644
--- a/etc/news.scm
+++ b/etc/news.scm
@@ -2,8 +2,13 @@
 ;;
 ;; Copyright © 2019, 2020 Ludovic Courtès 
 ;; Copyright © 2019, 2020 Tobias Geerinckx-Rice 
+;; Copyright © 2019, 2020 Konrad Hinsen 
+;; Copyright © 2019 Miguel 
+;; Copyright © 2019, 2020 Julien Lepiller 
+;; Copyright © 2019, 2020 Florian Pelz 
 ;; Copyright © 2020 Mathieu Othacehe 
 ;; Copyright © 2020 Jan (janneke) Nieuwenhuizen 
+;; Copyright © 2020 Marius Bakke 
 ;; Copyright © 2020 Maxim Cournoyer 
 ;;
 ;; Copying and distribution of this file, with or without modification, are
-- 
2.28.0

Re: Translating the web site

[pelzflorian (Florian Pelz)]

Thank you for the heads-up.

On Wed, Sep 23, 2020 at 08:50:46AM -0400, Julien Lepiller wrote:
> Eventually it could be nice to have our own instance, but dividing
> the translator community even further might not be a very good idea.

Hmm it would seem nice if the Translation Project website would point
translators also to projects that do not use their infrastructure.
Have they disagreed on hyperlinking to weblate?

Regards,
Florian

Re: [website]: Fix rendering of entities.

[pelzflorian (Florian Pelz)]

On Wed, Sep 09, 2020 at 11:35:06PM +0200, Ricardo Wurmus wrote:
> Hi Guix,
> 
> this page looks wrong: https://guix.gnu.org/packages/mpc-1.1.0/
> 
> The non-breaking space is rendered as “GNU<*ENTITY*>nbspMPC”.  The
> attached patch processes the SHTML to remove *ENTITY* nodes, replacing
> the “nbsp” entity with an actual non-breaking space; other entities are
> silently converted to a single space.
> […]
> +  (match entity
> +("nbsp" (string #\xa0))
> +(_ " "

Nice find.  LGTM as far as I can tell, except it would be nice if the ... / … in
 were not rendered as
a space.

Before:

The (hashing <*ENTITY*>hellip) modules implement cryptographic hash functions 
in pure R6RS Scheme: CRC, HMAC, MD5, SHA-1, and SHA-2 (SHA-256, SHA-512).

(or in SHTML
(div (p "The " (code "(hashing " (*ENTITY* "hellip") ")") " modules implement …"

After:

The (hashing ) modules implement cryptographic hash functions in pure R6RS 
Scheme: CRC, HMAC, MD5, SHA-1, and SHA-2 (SHA-256, SHA-512).


Regards,
Florian

Re: Translation copyright

[pelzflorian (Florian Pelz)]

On Mon, Aug 31, 2020 at 02:20:37PM +0200, Julien Lepiller wrote:
> I'd like to change all of these headers to something like this:
>
> Copyright (C) 2018-2020 the authors of Guix (msgids)

Yes, I think you are right with this change, but where to make it?

It seems this “authors of Guix” line in po/guix/*.po files originates
from the Translation Project
.

Changing the PO files directly would make them differ from the
authoritative version at the Translation Project.  Unless you plan to
switch to Weblate right away, that change is something that should be
discussed with the TP coordinator, I think.

Other PO files at the Translation Project seem to do different things
here, e.g. the German lynx translation
 only lists
translator copyrights, the French assigns copyright to the FSF, the
POT file does not mention any copyrights, also the format differs for
each of lynx’ translated PO files.


> Followed by the copyright of individual translators (or maybe the
> previous line is enough?)
> 
> This is probably the header to use in the pot files too.
> 
> Thank you!

I think the copyright of individual translators should be put in PO
files like for all other source files.

Regards,
Florian

Re: Persian translation

[pelzflorian (Florian Pelz)]

On Tue, Aug 04, 2020 at 12:57:37PM -0400, Amin Bandali wrote:
> Hi Ali Reza,
> 
> Ali Reza Hayati writes:
> 
> > Hey guys.
> > I hope you all are well.
> >
> > I wanted to contribute to GNU and Guix but I'm not a programmer so I
> > thought maybe I can translate Guix to Persian if it's needed. Can you
> > guys help me to start? What should I do? Where should I start?
> >
> > I have a GNU Savannah account now. What's the next step?
> 
> Thanks for your interest and for volunteering to translate Guix into
> Persian.  I'd be happy to help with translating and/or reviewing
> yours/others' translations.
> 
> I believe the translation of Guix is done using the Translation Project,
> consisting of the three "packages" guix [0], guix-manual [1], and
> guix-packages [2] as of now.
> 
> [0]: 
> [1]: 
> [2]: 
> 
> We should probably start by emailing the "team lead" for the Persian
> team  and ask to join the
> team.  I don't think translating Guix requires a disclaimer, but you may
> consider doing so anyway, if you may at some point in the future
> contribute translations to other projects which require it.  It would
> probably be a good idea to join the translation-team-fa mailing list as
> well.
> 
>  contains general
> instructions for translators.

This is very much correct.  You just need to edit the PO file from
 in a PO editor and after
adding some translations submit it to the Translation Project.  But
you should first talk to your team.

However I see little activity on
.  Please report back if
there are any problems reaching the team lead.  Also the Guix System
installer does not support right-to-left scripts yet (the bug was
reported here ).

Regards,
Florian