Re: No mutter on master

2024-07-04 Thread Andreas Enge
Hello,

Am Thu, Jul 04, 2024 at 06:25:35AM + schrieb Ada Stevenson:
> Mutter is one of those packages that fails on CI for no reason occasionally.
> The test suite is flaky.

that is annoying for such an important package! Maybe we can identify
the one (?) flaky test and disable it.

> Sometimes it passes, and we get a substitute, and
> sometimes it doesn't and we don't. We probably need to find the flaky test
> and disable it so this doesn't keep happening. Patches can pass straight
> through QA only to fail on CI. I had to build it locally the other day
> because of this substitute outage.

Well, if it passes QA, then this should create a substitute on
bordeaux.guix.gnu.org. This is now enabled by default, so QA should
solve the problem.

Andreas




Should we document how to detect if build machines are reachable before trying to offload?

2024-07-04 Thread Sergio Pastor Pérez
Hello.

I recently discovered that offloading builds to remote machines[1],
hangs when the machines are not available; instead of defaulting to
building locally[2]. This forces the user to use the `--no-offload`
flag.

I saw in the mailing list[2] that someone suggested that, the
`build-machines` field accepts a list of GEXPs instead of plain
`build-machine` record types.

This suggestion is almost correct but it only checks if the host is
known which does not guarantee that it is reachable. Therefore I came up
with this:
--8<---cut here---start->8---
(build-machines
 (list
  #~(let* ((resolvable? (lambda (machine)
  (zero? (system* #$(file-append netcat "/bin/nc")
  "-z" "-w1"
  (build-machine-name machine) "22")
  (filter resolvable?
  (list (build-machine
 (name "my-host")
 (systems (list "x86_64-linux" "i686-linux"))
 ;; NOTE: Located in '/etc/ssh/ssh_host_ed25519_key.pub' on 
the machine that does the build.
 ;; It will be generated by `openssh-service-type'.
 (host-key #$(plain-file-content %my-host-host-key))
 ;; NOTE: User on the build machine that allows SSH access 
with the key from `private-key' field.
 (user "my-host-user1")
 (private-key "/home/user1/.ssh/id_ed25519")))
--8<---cut here---end--->8---

Which allows to dynamically detect which machines are reachable.

If the user wanted to never build locally, the `-M 0` flag can be
used. Therefore, I would expect that it would graciously fallback to
building locally instead of getting stuck. If this is the desired
behaviour, I think we should document how to avoid the hanging.

Should we add this snippet to the manual/cookbook?

[1] https://guix.gnu.org/manual/en/html_node/Daemon-Offload-Setup.html
[2] https://lists.gnu.org/archive/html/help-guix/2023-12/msg00114.html
[3] https://lists.gnu.org/archive/html/help-guix/2023-12/msg00120.html


Regards,
Sergio.



Re: Sustainable funding and maintenance for our infrastructure

2024-07-04 Thread Simon Tournier
Hi,

On Tue, 02 Jul 2024 at 16:24, Ludovic Courtès  wrote:

>   The reason for this discussion is that we were
> thinking that we should not take our existing build farms for granted
> and be prepared for the future.

Could you explain the rationale?  I understand and fully agree that
sustainable funding and maintenance for infrastructure are key topics
for the project.  Do we need to move ci.guix soon?  Related to Ricardo
announcement [1]?

Well, I am missing some context or steps.  Currently, the project is
mainly in Option #3 (sponsored).  The main sponsor is MDC located in
Berlin.  The second sponsor is personal funds coupled to hardware bought
by us or donated to us – I have in mind the build farm behind the name
Bordeaux; thanks Chris! And the third sponsor – at some extent – is
Inria located in Bordeaux.

We had discussions about reinforcing the second sponsor by replacing
personal funds by project-wide funds, say Guix Foundation, community,
etc.

Is this description correct?


> The various options and back-of-the-envelope estimates we came up with
> are as follows:
>
>   1. Buying and hosting hardware:
>   250k€ for hardware
>   3k€/month (36k€/year)
>
>   2. Renting machines (e.g., on Hetzner):
>   6k€/month (72k€/year)
>
>   3. Sponsored:
>   get hardware and/or hosting sponsored (by academic institutions or
>   companies).

Well, on the paper, option #1 appears to me appealing but how do we get
this 250k€?  Somehow, 250k€ would mean being able to secure 3k€/month
for over almost 7 years, right?

Except if we have a large donation that I am not aware, I do not see how
it would be possible to sign in being sure to secure 3k€/month for over
almost 7 years; considering the project has 12 years.

Other said, option #1 does not appear to me an option.

Option #2 could be a temporary option for a short time.  But again,
that’s something.


> Option #3 potentially gives less control (depending on the project’s
> relation with the hosting organization) and makes the project dependent
> on the sponsor and/or person(s) in touch with them.  On the upside, it
> could significantly reduce costs (potentially to 0€).

It remains option #3. :-)

For me, that’s the only viable option at scale.  The main costs should
be covered by sponsor as academical ones.  From my point of view, the
only sustainable option is to group people behind GuixHPC (I recall the
domain name hpc.guix.info is paid by Guix Foundation ;-)) and ask: a) if
their institutions are ready to donate and/or a) if we could run for
some grants altogether.

Somehow, Guix starts to be run in various scientific data centers and we
could take advantage of this opportunity.

Indeed, it locks in some relation with the hosting organizations and/or
the person in touch with them.  That’s said, Ricardo showed it works
well – or at least it can. :-) The key appears to me to not put all the
eggs in the same basket.

That’s my half-baked current opinion.  WDYT?

Cheers,
simon


1: I'm retiring (for a while); help needed
Ricardo Wurmus 
Fri, 31 May 2024 08:08:15 +0200
id:87o78mldio@elephly.net
https://lists.gnu.org/archive/html/guix-devel/2024-05
https://yhetil.org/guix/87o78mldio@elephly.net



update Mate Desktop to 1.28

2024-07-04 Thread Andy Tai
Hi, in this patch series
https://issues.guix.gnu.org/71781

I sent would upgrade Mate to 1.28.  Hope someone with commit access
can review the patch series.  Keep desktop environments up to date is
good for GNU Guix.