Re: Introduce Cuirass and remove Hydra on https://www.gnu.org/software/devel.html

[Jing Luo]

On 2024-03-09 02:41, Simon Tournier wrote:

Hi,

Well, I do not see if there is a reply.  If no, sorry!  If yes, I am
just adding my own curiosity. :-)


Hello :) This was the first reply.


CC: guix-maintainers and guix-sysadmin
CC: Mark Weaver

On lun., 08 janv. 2024 at 13:19, Jing Luo  wrote:


[...]

[1] https://www.gnu.org/software/devel.html


[...]

The webpage [1] starts with:

This page describes many of the development resources available
for GNU developers on GNU Project machines.

Jing Luo, could you provide more details on the purpose of this
webpage?  What is the intent of this webpage?


This page was created at least 15 years ago. It lists the resources that 
a GNU package can use (hosting, testing, mailing list, etc.), since 
maintainers are expected to use machines/resources associated with or 
managed by GNU, instead of things like github.


For cuirass it would boil down to these questions:

- what is cuirass? how does it work?
- how can other GNU packages use ci.guix? (if they can)


[...]


--
Jing Luo
About me: https://jing.rocks/about/
PGP Fingerprint: 4E09 8D19 00AA 3F72 1899 2614 09B3 316E 13A1 1EFC


signature.asc
Description: OpenPGP digital signature

Re: Request to add a go-team branch and set it on CI.

[Maxim Cournoyer]

Hi,

Simon Tournier  writes:

> Hi,
>
> CC: guix-maintainers
> CC: guix-sysadmin
>
> On lun., 22 janv. 2024 at 19:58, Sharlatan Hellseher  
> wrote:
>
>> May I ask someone with admin rights to the build farm to set up
>>  go-team branch, please?
>
> What is the status of this request?  Is it doable?  I do not see the
> specification on .  Do I miss something?

IIRC, I think I had sent a private TLS client certificate to Sharlatan
so they can manage the go-team branch creation/jobs themselves from the
web UI.

-- 
Thanks,
Maxim

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

[Vagrant Cascadian]

On 2024-03-11, John Kehayias wrote:
> On Sunday, March 10th, 2024 at 9:58 PM, Vagrant Cascadian 
>  wrote:
>> On 2024-03-10, Suhail Singh wrote:
>> 
>> > Vagrant Cascadian vagr...@debian.org writes:
>> > 
>> > > but "guix pull" does not update the running guix-daemon;
>> > 
>> > Just to be clear, however, if one were to do =sudo -i guix pull=
>> > instead, followed by =systemctl restart guix-daemon.service= it /would/
>> > update the running guix-daemon on Debian, correct? Or is that not the
>> > case?
>> 
>> 
>> No, out of the box guix-daemon is provided by the Debian guix package.
>> 
>
> That means the instructions to update the guix daemon in the manual,
> 
> is incorrect or doesn't work? Or am I misunderstanding what you meant
> here?

I presume it works fine if you install from the GNU Guix binary tarball,
but not with the Debian guix packages without configuring systemd or
whatever init system to use the guix daemon provided by "guix pull".


> (I know in the past some discussions have come up about older
> guix-daemon on foreign distros, presumably because the packages there
> don't get updated and a user wouldn't think to upgrade guix
> separately? But it seems you are saying you can't upgrade without
> modifying the e.g. systemd service definition? This is also important
> for security updates to guix itself, of course.)

As with other packages in Debian, security updates would, at least in
theory, be uploaded via Debian's security update process, like any other
package in Debian... unless you actually configure it to work like the
instructions above (e.g. add a systemd override).

At least once, I pulled patches from guix upstream into the Debian
package to resolve security issues in the Debian packages.

Just to be absolutely clear here, "guix pull" and whatnot works fine;
that part of upgrading is no different than Guix System or Guix Binary
installation on a foreign distro.


live well,
  vagrant

>> > In other words, on Debian, does the systemd unit reference
>> > =/var/guix/profiles/per-user/root/current-guix/bin/guix-daemon= ?
>> 
>> 
>> But you could provide an override pointing at whatever guix-daemon you
>> want, of course! :)
>> 
>> Once you do that, you may as well remove the Debian packaged guix,
>> although users that have not yet run "guix pull" would need to guess
>> where to find guix, as there will be no guix on PATH.


signature.asc
Description: PGP signature

Handling expensive packages

[Skyler Ferris]

Hello,

I am looking through the [backlog of open patch 
submissions](https://issues.guix.gnu.org/search?query=is%3Aopen+tag%3Apatch) to 
see if any are actionable on my end. One such patch is [issue 55728 which 
updates python-mock](https://issues.guix.gnu.org/55728). Based on the output of 
`guix refresh --list-dependent python-mock | wc`, this will impact more than 
2000 packages. While this submission is very old, neither the master nor 
python-team branches have updated this package yet. In [section 22.8.2 
"Managing Patches and 
Branches"](https://guix.gnu.org/en/manual/devel/en/html_node/Managing-Patches-and-Branches.html),
 there is a recommendation that changes which effect more than 300 dependents 
are added to a different branch for testing.

These dependents presumably still work, as there are not 2000 build failures or 
a flood of related bug reports. So I think it would make sense to first ask the 
submitter for their motivation for sending the patch (for example, it might be 
a prerequisite for a package they want to add and they did not send it as a 
series for some reason). Depending on their response it might make sense to do 
something other than apply the update as given (for example, by providing both 
versions of the package so that a new package can be added without impacting 
existing branches). But there also might be some reason why it makes sense to 
apply the update everywhere (for example, if significant optimizations in the 
update reduces build times for all of the dependent packages).

So my main question is whether or not people agree that it makes sense to ask 
the submitter for more information and take no other action at this time. And 
as a secondary question, if it does make sense to update the package everywhere 
is there anything actionable on my end?

Regards,
Skyler

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: Helping with abandoned patches

[Simon Tournier]

Hi Greg,

On mer., 17 janv. 2024 at 12:17, Greg Hogan  wrote:
> What is the preferred process for when a patch review is provided
> (often by a committer) but no response is received from the submitter
> (for many weeks or months)?
>
> Is it appropriate to make the recommended changes and submit an updated patch?

Yes because the aim is to improve the code so the review is not lost.

Moreover, in that case of no response after a delay, if the reviewer
does not have commit access, the best (more helpful) seems sending by
the reviewer or anyone else a new version including the recommended
changes.

Cheers,
simon

Re: Check for ANSI compliance

[Simon Tournier]

Hi,

On lun., 29 janv. 2024 at 17:44, Ludovic Courtès  wrote:

> That used to be the case until commit
> 672d3d4a87839b0692c307df0edb66cd16bcbf1a, which enabled colors even when
> ‘INSIDE_EMACS’ is set.
>
> Pierre, do you remember what the rationale was?

I am not Pierre. :-)  The context seems:

Guix search, colors and INSIDE_EMACS
Pierre Neidhardt 
Tue, 04 Feb 2020 16:23:43 +0100
id:87blqeml4w@ambrevar.xyz
https://lists.gnu.org/archive/html/guix-devel/2020-02
https://yhetil.org/guix/87blqeml4w@ambrevar.xyz

Quoting [1]:

--8<---cut here---start->8---
>  new d7545a6  ui: Only display link in capable terminals.
>  new 672d3d4  ui: Don't disable colors when INSIDE_EMACS is set.

Forgive me if I missed the discussion, but I thought we had reached
rough consensus in favor of the status quo.  What happened?
--8<---cut here---end--->8---

Then quoting [2]:

--8<---cut here---start->8---
I’ve reverted it in c2f9ea2b502a617bb69227d5f858eee9d4288a6a, also
because if was causing a test failure.
--8<---cut here---end--->8---

where c2f9ea2b502a617bb69227d5f858eee9d4288a6a reads,

--8<---cut here---start->8---
Revert "ui: Only display link in capable terminals."

This reverts commit d7545a6b538813e88195d084f75a3e87065c999e.

The commit led to a test failure in 'tests/guix-package-net.sh'.  It
also led to disagreements discussed here:

  https://lists.gnu.org/archive/html/guix-devel/2020-02/msg00353.html

Reverting until these are addressed.
--8<---cut here---end--->8---

and thus 672d3d4 had not been reverted.  Let revert it since it does not
make sense without d7545a6, IMHO.

Cheers,
simon

1: Re: branch master updated (0aa0e1f -> 9b7f9e6)
Ludovic Courtès 
Mon, 24 Feb 2020 16:31:06 +0100
id:87blpom285@gnu.org
https://lists.gnu.org/archive/html/guix-devel/2020-02
https://yhetil.org/guix/87blpom285@gnu.org

2: Re: 01/03: ui: Only display link in capable terminals.
Ludovic Courtès 
Fri, 28 Feb 2020 00:16:25 +0100
id:87wo87aaeu@gnu.org
https://lists.gnu.org/archive/html/guix-devel/2020-02
https://yhetil.org/guix/87wo87aaeu@gnu.org

Re: Request to add a go-team branch and set it on CI.

[Simon Tournier]

Hi,

CC: guix-maintainers
CC: guix-sysadmin

On lun., 22 janv. 2024 at 19:58, Sharlatan Hellseher  
wrote:

> May I ask someone with admin rights to the build farm to set up
>  go-team branch, please?

What is the status of this request?  Is it doable?  I do not see the
specification on .  Do I miss something?

Cheers,
simon

Re: Building container images with nix2container

[Simon Tournier]

Hi Antoine,

Reading this blog post:

https://lewo.abesis.fr/posts/nix-build-container-image/

and from my understanding, “guix pack” is currently something similar to
’dockerTools.buildImage’ [1]

On lun., 26 févr. 2024 at 18:33, Simon Tournier  
wrote:

> Well, I have not followed on which strategy Guix relies.  What is the
> one of nix2container?  The one described here:
>
> https://grahamc.com/blog/nix-and-layered-docker-images/

To answer to my question, the way to build the container image is
different, hence it does not make much sense to speak about a
“strategy“. :-)

However, the blog post says:

To address this issue, we could add a nonReproducible option in
the containerTools.buildLayer function. Instead of only storing
the digest, we would also store the tar. Note in practice, an
important part of nixpkgs is bit reproducible and this would
rarely be needed.

And so the question is how do you know beforehand if the flag
’nonReproducible’ must be applied or not?

Indeed, the approach of nix2container could be helpful in addition to
‘guix pack’.  Maybe an extension… :-)

Cheers,
simon

Re: Introduce Cuirass and remove Hydra on https://www.gnu.org/software/devel.html

[Simon Tournier]

Hi,

Well, I do not see if there is a reply.  If no, sorry!  If yes, I am
just adding my own curiosity. :-)

CC: guix-maintainers and guix-sysadmin
CC: Mark Weaver

On lun., 08 janv. 2024 at 13:19, Jing Luo  wrote:

> I am Jing Luo, a new member from the GNU webmaster team. I noticed that 
> gnu.org has a page on "GNU Development Resources" [1], which has a 
> section about "Hydra: Continuous builds and portability testing". As I 
> know, Guix now uses Cuirass for CI. The text [1] has not been updated 
> since 2012. Would anyone on this list be interested in writing something 
> about Cuirass to replace the Hydra section? Or does anyone have other 
> ideas about this page? You can send an email to webmasters@gnu (plural!) 
> or just reply to me.
>
>
> [1] https://www.gnu.org/software/devel.html

AFAIK, Hydra is now down.  IIRC, Mark was in charge.  Mark?

The webpage [1] starts with:

This page describes many of the development resources available
for GNU developers on GNU Project machines.

Jing Luo, could you provide more details on the purpose of this
webpage?  What is the intent of this webpage?

The Guix project relieson two Continuous Integration systems deployed on
two infrastructures, visible at ci.guix.gnu.org and
bordeaux.guix.gnu.org.  One is indeed Cuirass [2].  The other one is
Build Coordinator [3].

AFAIK, GNU Guile is continuously built on ci.guix but there is no other
GNU projects.  And I do not know if the Guix projects has the capacity
or the resource to host more GNU projects on their infrastructure.

Cheers,
simon








2: https://guix.gnu.org/en/cuirass
3: https://git.savannah.gnu.org/cgit/guix/build-coordinator.git

Re: [PATCH 2/2] gnu: grub: Modernize.

[Fabio Natali]

On 2024-03-09, 10:42 +0100, Josselin Poiret  wrote:
> Of course, I'm known as jpoiret there.

Hi Josselin,

Thanks for the patches , which I've applied and tested as follows.

./pre-inst-env guix build grub
./pre-inst-env guix lint grub
./pre-inst-env guix build --check grub

Everything passed successfully, both in the case of the first patch
alone and when using the two patches together. I made sure that the
package built was version 2.12 instead of 2.06.

When building a system image, the first patch gave me an error if used
by itself. The error was along the lines of:

ice-9/read.scm:126:4: In procedure read-expr*: Unknown # object: "#<"

I haven't investigated this further as the error resolved when applying
both patches together.

I then installed GRUB 2.12 on a spare x86 machine. With this new version
of GRUB, I was able to use a LUKS2 partition with PBKDF2
public-key-based key derivation function. Yay! 

When building GRUB 2.12 on the spare machine this test initially failed:

https://git.savannah.gnu.org/cgit/grub.git/tree/tests/grub_cmd_date.in

The error vanished when I tried a second time and I haven't been able to
reproduce it since then.

The patches have two micro-typos:

- First patch, s/Theses/These/.
- Second patch, s/use-abolute-ovmf-path/use-absolute-ovmf-path/.

I haven't tried the patches on any non-x86 architecture, but will ping
you on IRC to see if and how I can help with that.

Thanks, best, Fabio.


-- 
Fabio Natali
https://fabionatali.com

Re: Creating an unversioned rust-cargo symbol

[Efraim Flashner]

On Thu, Feb 29, 2024 at 05:42:20PM -0500, Richard Sent wrote:
> Hi Guix,
> 
> There isn't an unversioned symbol for rust-cargo defined or exported by
> the (gnu packages crates-io) module. I think it would be best if an
> unversioned rust-cargo symbol was created that was equal to the highest
> rust-cargo release. (i.e. rust-cargo, not rust-cargo-0.76)
> 
> Alternatively, since (seemingly) only one rust-cargo package is present
> at a time, perhaps the version information could be removed outright and
> only an unversioned symbol used.
> 
> The alternative, (specification->package), does not work in all
> circumstances (primarily with -L) [1]. This would also make Scheme code
> that refers to rust-cargo cleaner, either not needing updating every new
> version when the symbol changes or removing potentially awkward
> (specification->package) calls.
> 
> I see that most/all of the symbols in crates-io are versioned. While
> from a user perspective it would be nice if there were more unversioned
> symbols, rust-cargo is /probably/ the one that needs it the most since
> it's so central to the ecosystem. I can also see why versioning every
> symbol might help with development given Rust's release schedule and
> bootstrapping chain.
> 
> This would follow the pattern of linux-libre.
> 
> Posting to guix-devel instead of bug-guix since I'm not entirely sure
> this is a bug or working as intended.
> 
> [1] https://lists.gnu.org/archive/html/guix-devel/2022-12/msg00310.html
> 

I've added a rust-cargo package in rust-apps.scm and a note in
crates-io.scm to remove it with the next rust-team merge.

-- 
Efraim Flashner  רנשלפ םירפא
GPG key = A28B F40C 3E55 1372 662D  14F7 41AA E7DC CA3D 8351
Confidentiality cannot be guaranteed on emails sent or received unencrypted


signature.asc
Description: PGP signature

Re: GSoC 2024

[Efraim Flashner]

On Thu, Mar 07, 2024 at 02:09:32PM +, Steve George wrote:
> 
> Hi,
> 
> I had a couple of ideas - but would need help from someone to mentor
> 
> 1. Moldable development in Guix
> Exploratory REPL experience is one of the hall-marks of 'moldable' systems. 
> This shortens the development cycle and improves the ability of users to 
> explore Guix.
> 
> The best REPL experience today is through Emacs. We have a modern nREPL 
> implementation that is compatible with Guile. This needs further development 
> and the Guix client side improved.
> 
> * Develop a basic CLI Nrepl experience in guile-ares-rs 
> (https://git.sr.ht/~abcdw/guile-ares-rs)
> * Add further CLI REPL functions to Guix 
> * Stretch goal to add a Guix / Guile Scheme nrepl support to Conjure 
> (https://github.com/Olical/conjure/issues/549) 
> 
> This would need co-ordination with Andrew Tropin (abcw) and Oliver Caldwell 
> (Olical), and some help from a Guix mentor. 
> 
> 2. Improving Docker image output (guix pack)
> Docker containers are a common deployment method for applications. While they 
> may be good for deployment, they have weak reproducibilty which Guix solves. 
> Docker containers generated by Guix for deployment are large compared to 
> similar deployments using Nix or Alpine. The purpose of this project is to 
> optimise the build and deployment pipeline in Guix.
> 
> * Examine the current 'guix pack' process for optimisations
> * Optimise the build process to add docker specific capabilities like 
> multi-stage builds
> * Explore using grafts or masking to reduce final image size
> 
> ** NOTE:** I know this is a bit weak - I don't know enough about this myself 
> yet - is this even a good target - I think it's interesting for scientific 
> computing?

This would also be useful for "deploy this guix service as a docker
container".

> 3. Add sandboxing to guix packages
> Improving the security for end-users by implementing optional sandboxing for 
> desktop applications. The likes of Bubblewrap and Flatseal are available for 
> Linux. There's some existing Nix prior-art that could be a good starting 
> point (https://nixos.wiki/wiki/Firejail) and 
> (https://sr.ht/~fgaz/nix-bubblewrap/)
> 
> * Figure out which of the available options is the most sustainable
> * Integrate policys and implementation into high-profile packages
> * Stretch would be to create a Guile native library / approach
> 
> Anyone interested in these - willing to mentor/co-mentor with me?
> 
> On  4 Mar, Gábor Boskovits wrote:
> > Hello guix,
> > 
> > I coordinated with the GNU org admins, and we can still do this round,
> > but we have to go fast to make this happen. I have already taken the
> > initiative to try to get an ideas page up, now I would like to confirm
> > if the mentors from last year are still available, and that the ideas
> > are still valid.
> > 
> > Hereby I quickly collected the projects with the respective mentors,
> > please pm me your availability:
> > 
> > Decentralized substitute distribution
> > pukkamustard (pukkamustard [at] posteo [dot] net)
> > attila.lendvai (ethswarm.org, scheme)
> > 
> > Robustify long-term support for Reproducible Research
> > Simon Tournier (zimoun)
> > 
> > Develop a Web interface to configure Guix System
> > Ludovic Courtès (civodul)
> > 
> > Trusted computing: Goblins for GNU Guix
> > Christopher Webber, Ludovic Courtès and Pjotr Prins
> > 
> > Guix Data Service revision processing instrumentation and performance
> > Christopher Baines
> > 
> > Guile based build-tool
> > Pjotr Prins
> > 
> > GNU Guix system monitor
> > Pjotr Prins
> > 
> > Booting via network
> > Danny Milosavljevic
> > 
> > Syntax and semantics of systemd units in the Shepherd
> > Ludovic Courtès (civodul)
> > 
> > GNUnet integration
> > no mentor available
> > 
> > Adding modules in support of continuous integration to cuirass
> > Ludovic Courtès (civodul)
> > 
> > Continue rewrite build daemon in Guile Scheme
> > Ludovic Courtès (civodul)
> > 
> > I myself am available to co-mentor, and also to be the formal mentor
> > in case someone does not feel like doing the official dance with
> > Google. Currently I can commit to devoting two hours a week to this.
> > 
> > Regards,
> > g_bor
> > 
> 

-- 
Efraim Flashner  רנשלפ םירפא
GPG key = A28B F40C 3E55 1372 662D  14F7 41AA E7DC CA3D 8351
Confidentiality cannot be guaranteed on emails sent or received unencrypted


signature.asc
Description: PGP signature