Re: [PATCH 0/1] Possible fix of the Cuirass build with the latest Guix

[Ludovic Courtès]

Hi,

Rodion Goritskov  skribis:

> Got some problems due to the change re-exports in (guix utils).
> Also, should I send patches for Cuirass here or to the guix-patches?

Good catch!  I see that Maxim fixed these issues just recently; it
should be fine now.

Thanks,
Ludo’.

[PATCH 0/1] Possible fix of the Cuirass build with the latest Guix

[Rodion Goritskov]

Got some problems due to the change re-exports in (guix utils).
Also, should I send patches for Cuirass here or to the guix-patches?

Rodion Goritskov (1):
  remote-server: Fix guix modules selects

 src/cuirass/scripts/remote-server.scm | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)


base-commit: 9a1452ee021c9f773424961cfeef47ca0b7c5c5a
-- 
2.41.0

Re: cuirass building and deployment

[Jim Dupont]

i will report more, for now you can see there are thousands of build errors
tryign to bootstrap
http://34.41.82.208:8080/eval/7?status=failed

On Sun, Mar 24, 2024, 07:27 Ludovic Courtès  wrote:

> Hi,
>
> Jim Dupont  skribis:
>
> > have been struggling to deploy cuirass on  a gcp cluster.
> > I was able to install it manually on one machine and use it from guix
> > talking to postgres and nginx running in ubuntu. the shepherd wont build
> or
> > install, needs more love.
> > I have gotten to finally build on guix and can export the package from
> one
> > system to another.
> > Can someone help me understand how to document the exact steps to
> reproduce
> > a build?
> > There are constant issues with guile modules not found or loading,
> > autoconfig failing or other errors,
>
> Could you be more specific about the build errors you encounter?
>
> To run Cuirass, the best option is install the ‘cuirass’ package in
> Guix: ‘guix install cuirass’.  Then you can start the ‘cuirass register’
> and ‘cuirass web’ processes manually or get systemd to handle them (I
> don’t think Cuirass provides ‘.service’ files, but it should.)
>
> If you want to be on the bleeding edge (not recommended), the easiest
> way is to run ‘guix build -f guix.scm’ from the Cuirass source tree.
>
> HTH!
>
> Ludo’.
>

Re: cuirass building and deployment

[Ludovic Courtès]

Hi,

Jim Dupont  skribis:

> have been struggling to deploy cuirass on  a gcp cluster.
> I was able to install it manually on one machine and use it from guix
> talking to postgres and nginx running in ubuntu. the shepherd wont build or
> install, needs more love.
> I have gotten to finally build on guix and can export the package from one
> system to another.
> Can someone help me understand how to document the exact steps to reproduce
> a build?
> There are constant issues with guile modules not found or loading,
> autoconfig failing or other errors,

Could you be more specific about the build errors you encounter?

To run Cuirass, the best option is install the ‘cuirass’ package in
Guix: ‘guix install cuirass’.  Then you can start the ‘cuirass register’
and ‘cuirass web’ processes manually or get systemd to handle them (I
don’t think Cuirass provides ‘.service’ files, but it should.)

If you want to be on the bleeding edge (not recommended), the easiest
way is to run ‘guix build -f guix.scm’ from the Cuirass source tree.

HTH!

Ludo’.

cuirass building and deployment

[Jim Dupont]

Hi team,
have been struggling to deploy cuirass on  a gcp cluster.
I was able to install it manually on one machine and use it from guix
talking to postgres and nginx running in ubuntu. the shepherd wont build or
install, needs more love.
I have gotten to finally build on guix and can export the package from one
system to another.
Can someone help me understand how to document the exact steps to reproduce
a build?
There are constant issues with guile modules not found or loading,
autoconfig failing or other errors,
Is anyone interested in looking at them? the first cuirass is running as I
said and I am willing to build packages there and share the logs if someone
wants to help me debug this.
thanks,
mike

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

[Jing Luo]

On 2024-03-12 23:22, Mark H Weaver wrote:

Simon Tournier  writes:


[...]

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


Yes, our instance of Hydra was retired many years ago.  I agree that it
makes sense to remove it from 
.


  Thanks,
Mark


Thanks, the section was removed from 
.


--
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: Introduce Cuirass and remove Hydra on https://www.gnu.org/software/devel.html

[Mark H Weaver]

Simon Tournier  writes:

> 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?

Yes, our instance of Hydra was retired many years ago.  I agree that it
makes sense to remove it from <https://www.gnu.org/software/devel.html>.

  Thanks,
Mark

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: 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

Cuirass 1.2.0-2.7bcd3d0 (and manual): latest install image not available for download (wrong URL?)

[Giovanni Biscuolo]

Hello Tanguy,

IMO there is a bug in the CI UI

Tanguy LE CARROUR  writes:

> In order to test the latest installer, I went to the "latest download"
> page [1] and clicked on "x86_64-linux" under "GNU Guix System on Linux"
> and ended up on an error page [2]:
>
> """
> {"error":"Could not find the requested build product."}
> """
>
> [1]: https://guix.gnu.org/en/download/latest/

the exact URL is this one:

https://ci.guix.gnu.org/search/latest/ISO-9660?query=spec:images+status:success+system:x86_64-linux+image.iso

Looking at this results:
https://ci.guix.gnu.org/search?query=spec:images+status:success+system:x86_64-linux+image.iso

there are plenty of images succesfully built.

Unfortunately the "Build outputs" URL available in the datails page are
broken so there is no way to download them via ci.guix.gnu.org (AFAIU)

> [2]: https://ci.guix.gnu.org/download/1907

I also tested:

- https://ci.guix.gnu.org/build/3395955/details pointing to
  https://ci.guix.gnu.org/download/1927

- https://ci.guix.gnu.org/build/3267415/details pointing to
  https://ci.guix.gnu.org/download/1894

and the result is the same:

--8<---cut here---start->8---

{"error":"Could not find the requested build product."}

--8<---cut here---end--->8---

[...]

> Is it the ISO that has to be tested? How can I download it?

Unfortunately also the latest (devel) manual

https://guix.gnu.org/en/manual/devel/en/html_node/USB-Stick-and-DVD-Installation.html

now is pointing to an invalid url:

https://ftp.gnu.org/gnu/guix/guix-system-install-f29f80c.x86_64-linux.iso

I'm almost sure not so log ago it was pointing to a valid file.

Are the two issues linked of do I need to file a separate bug for the
manual?

Sorry I don't know how to help to fix it.

Best regards, Gio'

-- 
Giovanni Biscuolo

Xelera IT Infrastructures


signature.asc
Description: PGP signature

Re: [Cuirass] JavaScript work

[Ricardo Wurmus]

Janneke Nieuwenhuizen  writes:

> I'm wondering though what the net gain of minification is
> with current bandwiths.  On the few sites that I use javascript on I just
> ship the preferred readable code.

JavaScript libraries can weigh several megabytes unminified.  With
minification applied to the concatenation of all JavaScript code we can
reduce the number of requests that need to be made and the weight of the
request.

[I remember that accessing anything JavaScript heavy (by byte-count) was
no fun in China.]

But minification may not be worth it anyway once we get rid of all
unnecessary JavaScript like jQuery, bootstrap, and DT.

-- 
Ricardo

Re: [Cuirass] JavaScript work

[Ludovic Courtès]

Hi,

Ricardo Wurmus  skribis:

> I noticed that Cuirass bundles minified JavaScript.  I’ve started a new
> branch that replaces the minified JavaScript with readable source code
> and minifies the files as part of the build.
>
> I also tried to remove the need for jQuery, at least in our own
> JavaScript code.  (Datatables.js still uses jQuery.)
>
> Eventually, I’d like to remove Bootstrap (both CSS and JS) all together
> and switch to Pico.css for conventional default styles without the need
> for bootstrap classes everywhere.  I’d like to remove JS for thing that
> HTML+CSS can do just fine.
>
> (Pico is also used in mumi.)
>
> What do you think?

I’m all for it.  Thanks a lot for working on it!

Ludo’.

Re: [Cuirass] JavaScript work

[Maxim Cournoyer]

Hi,

Ricardo Wurmus  writes:

> Hi,
>
> I noticed that Cuirass bundles minified JavaScript.  I’ve started a new
> branch that replaces the minified JavaScript with readable source code
> and minifies the files as part of the build.
>
> I also tried to remove the need for jQuery, at least in our own
> JavaScript code.  (Datatables.js still uses jQuery.)
>
> Eventually, I’d like to remove Bootstrap (both CSS and JS) all together
> and switch to Pico.css for conventional default styles without the need
> for bootstrap classes everywhere.  I’d like to remove JS for thing that
> HTML+CSS can do just fine.
>
> (Pico is also used in mumi.)
>
> What do you think?

Sounds good to me.  Like Janneke, I also think we can do without JS
obfuscation (minification).

-- 
Thanks,
Maxim

Re: [Cuirass] JavaScript work

[Janneke Nieuwenhuizen]

Ricardo Wurmus writes:

> I noticed that Cuirass bundles minified JavaScript.  I’ve started a new
> branch that replaces the minified JavaScript with readable source code
> and minifies the files as part of the build.

Yay for that.  I'm wondering though what the net gain of minification is
with current bandwiths.  On the few sites that I use javascript on I just
ship the preferred readable code.

Janneke

-- 
Janneke Nieuwenhuizen   | GNU LilyPond https://LilyPond.org
Freelance IT https://www.JoyOfSource.com | Avatar® https://AvatarAcademy.com

[Cuirass] JavaScript work

[Ricardo Wurmus]

Hi,

I noticed that Cuirass bundles minified JavaScript.  I’ve started a new
branch that replaces the minified JavaScript with readable source code
and minifies the files as part of the build.

I also tried to remove the need for jQuery, at least in our own
JavaScript code.  (Datatables.js still uses jQuery.)

Eventually, I’d like to remove Bootstrap (both CSS and JS) all together
and switch to Pico.css for conventional default styles without the need
for bootstrap classes everywhere.  I’d like to remove JS for thing that
HTML+CSS can do just fine.

(Pico is also used in mumi.)

What do you think?

The branch is here:
https://git.savannah.gnu.org/cgit/guix/guix-cuirass.git/log/?h=wip-js%2bcss

-- 
Ricardo

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

[Jing Luo]

Hi Guix,

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

--
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

[cuirass] Typo?

[Ricardo Wurmus]

Hi,

In (cuirass base) there is this definition:

--8<---cut here---start->8---
(define (exception-reporter . results)
  "Return an exception handler that reports the exception on the error port
and returns the values RESULTS."
  (lambda (key . args)
(false-if-exception
 (let* ((stack (make-stack #t))
(depth (stack-length stack))
(frame (or (and (> depth 1) (stack-ref stack 1))
   (and (> depth 0)) (stack-ref stack 0
   (print-exception (current-error-port) frame key args)
   (apply values results)
--8<---cut here---end--->8---

The parentheses for the binding of “frame” look wrong to me:

(frame (or (and (> depth 1) (stack-ref stack 1))
   (and (> depth 0))
   (stack-ref stack 0)))

-- 
Ricardo

Re: Cuirass 1.2.0 released

[Katherine Cox-Buday]

On 10/30/23 10:42 AM, Ludovic Courtès wrote:

Hello Guix!

It’s a bit of a non-event since we’ve been packaging and using snapshots
of Cuirass all along, but nevertheless, I’m totally thrilled to announce
that Cuirass 1.2.0 is out!


Congratulations! It might be my holiday project this year to stand up a 
local instance :)

Cuirass 1.2.0 released

[Ludovic Courtès]

Hello Guix!

It’s a bit of a non-event since we’ve been packaging and using snapshots
of Cuirass all along, but nevertheless, I’m totally thrilled to announce
that Cuirass 1.2.0 is out!

  https://guix.gnu.org/en/cuirass/

Changes since 1.1.0 (excerpt from the ‘NEWS’ file):

  ** Core
  *** Require Fibers >= 1.1.0
  (<https://issues.guix.gnu.org/63389>)
  *** Require Guile >= 3.0.6
  *** Channels are always authenticated
  *** Use a database connection pool instead of a worker thread
  *** Now useless (cuirass watchdog) module has been removed
  *** (cuirass database) now uses records instead of alists for data types
  *** (cuirass base) rewritten as a set of actors
  *** ‘cuirass register’ limits the number of concurrent evaluations
  *** ‘cuirass register’ listens to ‘cuirass web’ on a “bridge” local socket
  *** Keep GC roots for derivations that are queued
  (<https://issues.guix.gnu.org/54447>)
  *** Register a GC root for “build products”
  (<https://issues.guix.gnu.org/64317>)
  *** Logging level can be controlled with ‘CUIRASS_LOGGING_LEVEL’ env. variable

  ** Database
  *** Allow specifications to be inactive

  ** Remote building
  *** Worker stops requesting work when disk space is too low
  *** Worker now asks for work as soon as it’s available
  *** (cuirass remote) provides a higher-level interface for messages
  *** ‘remote-worker’ and ‘remote-server’ are now a fiberized process
  *** ‘remote-worker’ defines distributes available cores among workers
  *** Fix memory corruption leading ‘remote-server’ to never reply
  *** New ‘--log-expiry’ option for ‘cuirass remote-server’
  *** Fix bug that would lead ‘remote-worker’ to wrongfully report failure
  (<https://issues.guix.gnu.org/66692>)
  *** ‘cuirass remote-worker’ periodically removes its own GC roots

  ** Web
  *** Add /admin/specification/deactivate endpoint
  *** Evaluation dashboard now supports filtering by build name
  *** Evaluation dashboard shows completion time and commits
  *** New /eval/latest?spec=… endpoint, linking to the latest dashboard
  *** Evaluation page uncluttered
  *** New /jobset/SPEC/hook/evaluation POST endpoint to trigger an evaluation
  *** Build page provides hints for failed builds
  *** Build page shows the build machine and/or worker ID
  *** New /build/ID/log endpoint, with syntax-highlighted build logs
  *** New ‘etc/new-client-cert.scm’ script; see “Authentication” in the manual

And guess what? 1.2.0 is already running at <https://ci.guix.gnu.org>.

Enjoy the colorful build logs and all that!  :-)

Ludo’.


signature.asc
Description: PGP signature

Re: [PATCH cuirass] doc: Fix remaining evaluation hook example.

[Maxim Cournoyer]

Hello,

vicvbcun  writes:

> This is a follow-up to commit 0b63c3b6989af77d4e1c9a98dd25c8f26b37d930.
>
> * doc/cuirass.texi (Triggering an Evaluation): Fix URL in example.

Also applied!

-- 
Thanks,
Maxim

[PATCH cuirass] doc: Fix remaining evaluation hook example.

[vicvbcun]

This is a follow-up to commit 0b63c3b6989af77d4e1c9a98dd25c8f26b37d930.

* doc/cuirass.texi (Triggering an Evaluation): Fix URL in example.
---
It seems that it has been copy-pasted in the meantime :).

doc/cuirass.texi | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/doc/cuirass.texi b/doc/cuirass.texi
index ea2b10e..c3e6c33 100644
--- a/doc/cuirass.texi
+++ b/doc/cuirass.texi
@@ -939,7 +939,7 @@ jobset, along these lines:
 
 @example
 wget --post-data="" -O /dev/null \
-  https://cuirass.example.org/@var{jobset}/hooks/evaluate
+  https://cuirass.example.org/jobset/@var{jobset}/hook/evaluate
 @end example
 
 A good idea is to do that from the post-push hook of the relevant Git

base-commit: 0b63c3b6989af77d4e1c9a98dd25c8f26b37d930
-- 
2.42.0

Re: [PATCH cuirass] doc: Fix evaluation hook URL example.

[Maxim Cournoyer]

Hi,

vicvbcun  writes:

> * doc/cuirass.texi (Invocation): Fix URL in the example of the push hook.
> ---
>  doc/cuirass.texi | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/doc/cuirass.texi b/doc/cuirass.texi
> index 69c58f7..00f00c1 100644
> --- a/doc/cuirass.texi
> +++ b/doc/cuirass.texi
> @@ -561,7 +561,7 @@ example with a command along these lines:
>  
>  @example
>  wget --post-data="" -O /dev/null \
> -  https://cuirass.example.org/@var{jobset}/hooks/evaluate
> +  https://cuirass.example.org/jobset/@var{jobset}/hook/evaluate
>  @end example
>  
>  You would typically run that command as a @dfn{push hook} on the servers
>
> base-commit: e159c74ca6f666a32eb9b778067e00941a4bfa36

Installed! :-)

-- 
Thanks,
Maxim

[PATCH cuirass] doc: Fix evaluation hook URL example.

[vicvbcun]

* doc/cuirass.texi (Invocation): Fix URL in the example of the push hook.
---
 doc/cuirass.texi | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/doc/cuirass.texi b/doc/cuirass.texi
index 69c58f7..00f00c1 100644
--- a/doc/cuirass.texi
+++ b/doc/cuirass.texi
@@ -561,7 +561,7 @@ example with a command along these lines:
 
 @example
 wget --post-data="" -O /dev/null \
-  https://cuirass.example.org/@var{jobset}/hooks/evaluate
+  https://cuirass.example.org/jobset/@var{jobset}/hook/evaluate
 @end example
 
 You would typically run that command as a @dfn{push hook} on the servers

base-commit: e159c74ca6f666a32eb9b778067e00941a4bfa36
-- 
2.42.0

Re: Cuirass upgrade on ci.guix

[Simon Tournier]

Hi Ludo,

On Mon, 02 Oct 2023 at 23:46, Ludovic Courtès  wrote:

> A few hours ago I deployed current Cuirass on ci.guix and its build
> machines.  The expected benefits are:

Really cool!  Thank you!


> As a bonus, we may finally get native GNU/Hurd builds again, via the
> childhurds running on some of the build nodes.

Would it be possible to use Cuirass (add a manifest file) for building
Hurd?  As the one for Guile [1].  I do not speak about the package Hurd
or Guile, but follow upstream (some branches, etc.).

I do not know if building Hurd is resource-hungry but that’s could be
cool to Guixify the “development of Hurd“. :-)

I have recently watched the FSODEM 2019 talk: “A roadmap for the Hurd?”
and setting up with Guix some Hurd CI could help the Hurd project and so
whole GNU, no?

Cheers,
simon

1: Resurrecting top-notch continuous integration for Guile
Ludovic Courtès 
Sun, 29 Jan 2023 18:36:19 +0100
id:87lell2qgc@inria.fr
https://lists.gnu.org/archive/html/guile-devel/2023-01/msg00121.html

2: https://archive.fosdem.org/2019/schedule/event/roadmap_for_the_hurd/

Re: Cuirass upgrade on ci.guix

[Mathieu Othacehe]

Hey,

>   1. Better throughput.  I fixed a bug that would lead “workers” to
>  eventually get ignored by ‘cuirass remote-server’, meaning they
>  would become idle until either the server or the worker is
>  restarted¹.

Wow, that's a nice catch!

>   2. Evaluation can be triggered via POST requests, which should make
>  things a bit more reactive and will allow us to poll repos less
>  frequently.  I submitted a support request on Savannah:
>  <https://savannah.nongnu.org/support/?110939>.
>
>   3. Improved resilience against “evaluation storms” since ‘cuirass
>  register’ now has an upper limit on the number of evaluations that
>  may occur in parallel.
>
>   4. Build priority handling has been restored (it had been lost
>  recently).

Nice as well! Thanks for your awesome contributions to Cuirass :)

Mathieu

Re: Cuirass upgrade on ci.guix

[Janneke Nieuwenhuizen]

Ludovic Courtès writes:

Hi Ludo!

> A few hours ago I deployed current Cuirass on ci.guix and its build
> machines.  The expected benefits are:

Thank you for this (often seemingly) unthankful work!

> As a bonus, we may finally get native GNU/Hurd builds again, via the
> childhurds running on some of the build nodes.

...and with an amazing bonus!  Anything else that needs to be done
before we can see hurd builds showing up?

(or where, possibly i'm looking in all the wrong places?
>https://ci.guix.gnu.org/search?query=system%3Ai586-gnu+spec%3Amaster>
<https://ci.guix.gnu.org/search?query=system%3Ai586-gnu+spec%3Aguix>)

Greetings,
Janneke

-- 
Janneke Nieuwenhuizen   | GNU LilyPond https://LilyPond.org
Freelance IT https://www.JoyOfSource.com | Avatar® https://AvatarAcademy.com

Cuirass upgrade on ci.guix

[Ludovic Courtès]

Hello Guix!

A few hours ago I deployed current Cuirass on ci.guix and its build
machines.  The expected benefits are:

  1. Better throughput.  I fixed a bug that would lead “workers” to
 eventually get ignored by ‘cuirass remote-server’, meaning they
 would become idle until either the server or the worker is
 restarted¹.

 When I reconfigured, there were 45k pending builds (!), visible on
 <https://ci.guix.gnu.org/metrics> and the vast majority of workers
 at <https://ci.guix.gnu.org/workers> were idle.

 We’re now at ~22k pending builds (okay, I cheated by canceling ~15k
 from ‘emacs-team’, but I also restarted many builds en masse),
 which are mostly non-x86.

 My hope is that we can get close to zero soon and have headroom for
 feature branches.

  2. Evaluation can be triggered via POST requests, which should make
 things a bit more reactive and will allow us to poll repos less
 frequently.  I submitted a support request on Savannah:
 <https://savannah.nongnu.org/support/?110939>.

  3. Improved resilience against “evaluation storms” since ‘cuirass
 register’ now has an upper limit on the number of evaluations that
 may occur in parallel.

  4. Build priority handling has been restored (it had been lost
 recently).

As a bonus, we may finally get native GNU/Hurd builds again, via the
childhurds running on some of the build nodes.

That’s it!

Ludo’.

¹ 
https://git.savannah.gnu.org/cgit/guix/guix-cuirass.git/commit/?id=40f70d28aed55c404cca6a0760860fb4942e6bee

Re: Cuirass actors

[Thompson, David]

On Thu, Sep 14, 2023 at 11:31 AM Ludovic Courtès  wrote:
>
> Hi!
>
> "Thompson, David"  skribis:
>
> > I'm curious to hear more about your inter-process transport needs!
>
> I’d like to have actors running in separate processes on the same
> machine.  I wouldn’t want them to communicate over Tor or TCP+TLS;
> rather, I’d like them to use AF_UNIX sockets, “abstract sockets”, pipes,
> socketpairs—one of these local IPC mechanisms.
>
> My understanding is that there could be an ocapn “netlayer” based on
> that.  Does that make sense?  Is this something you’re considering?

Thanks for clarifying! Yes, we definitely intend to provide local IPC
netlayers such as UNIX domain sockets.  We actually have a test
netlayer that uses UNIX domain sockets, so some of this work has
already been done.

- Dave

Re: Cuirass actors

[Ludovic Courtès]

Simon Tournier  skribis:

> IIUC, the current two “builder” backend are:
>
>  + local ’guix-daemon’: the queue of derivations is processed using one
>strategy – the one implemented in C++,
>
>  + ’cuirass remote-server’: the queue of derivations is processed using
>another strategy – implemented in Guile relying on ZeroMQ (something
>like steal of work, if I remember correctly).
>
> Is it correct?

Yes.

> The Build Coordinator also implements the other actors “channel
> updater”, “evaluator”, etc., right?

No.

> From my rough understanding, the first aim of Build Coordinator is the
> implementation of the “builder”.  Is it correct?

Yes.

> My two questions are:
>
>  1. Is the Build Coordinator able to only process the queue of
> derivations?  (being a “builder” backend).  And if yes, what is its
> strategy for processing?

Yes, you give it derivations and it builds them; as for what its
scheduling strategy is, I don’t know!

>  2. In this picture of actor model, would it make sense (or would it be
> possible) to replace the “builder” actor from the Cuirass one to the
> Build Coordinator one?

Yes, that’s exactly the message I tried to convey.  :-)

Thanks,
Ludo’.

Re: Cuirass actors

[Ludovic Courtès]

Hi!

"Thompson, David"  skribis:

> I'm curious to hear more about your inter-process transport needs!

I’d like to have actors running in separate processes on the same
machine.  I wouldn’t want them to communicate over Tor or TCP+TLS;
rather, I’d like them to use AF_UNIX sockets, “abstract sockets”, pipes,
socketpairs—one of these local IPC mechanisms.

My understanding is that there could be an ocapn “netlayer” based on
that.  Does that make sense?  Is this something you’re considering?

Thanks,
Ludo’.

Re: Cuirass actors

[Thompson, David]

Hey Ludo,

On Wed, Sep 13, 2023 at 5:08 PM Ludovic Courtès  wrote:
>
> With this actor split, one could implement another “builder” backend,
> for instance one that talks to a Build Coordinator process.  It’s also
> obviously close to the programming model encouraged by Goblins, which
> should make eventual migration easier (and when that happens, if Goblins
> provides an inter-process transport, we’ll no longer need the custom
> “bridge” and we’ll be able to move actors from one process to another
> much more easily.)

We're obviously very excited by this development over at Spritely. :)

I'm curious to hear more about your inter-process transport needs!

- Dave

Re: Cuirass actors

[Simon Tournier]

Hi,

It is really cool! :-)

On Wed, 13 Sep 2023 at 23:08, Ludovic Courtès  wrote:

>   - The "builder" spawns derivation builds.  There are currently two
> implementations: the local builder sends build requests to the local
> 'guix-daemon' process, while the remote build delegates builds to
> 'cuirass remote-server'.

[...]

> With this actor split, one could implement another “builder” backend,
> for instance one that talks to a Build Coordinator process.

IIUC, the current two “builder” backend are:

 + local ’guix-daemon’: the queue of derivations is processed using one
   strategy – the one implemented in C++,

 + ’cuirass remote-server’: the queue of derivations is processed using
   another strategy – implemented in Guile relying on ZeroMQ (something
   like steal of work, if I remember correctly).

Is it correct?

The Build Coordinator also implements the other actors “channel
updater”, “evaluator”, etc., right?  From my rough understanding, the
first aim of Build Coordinator is the implementation of the “builder”.
Is it correct?

My two questions are:

 1. Is the Build Coordinator able to only process the queue of
derivations?  (being a “builder” backend).  And if yes, what is its
strategy for processing?

 2. In this picture of actor model, would it make sense (or would it be
possible) to replace the “builder” actor from the Cuirass one to the
Build Coordinator one?

Cheers,
simon

 

Cuirass actors

[Ludovic Courtès]

Hello Guix!

My (useful? misguided? questionable?) quest around Cuirass has led me
closer to some of the goals mentioned in my previous message¹ and in the
‘TODO’ file².

The ‘wip-actors’ branch³, which I plan to merge soon, splits activities
of the ‘cuirass register’ process among several actors.  Quoth ‘base.scm’:

  - The "channel updater" is responsible for updating Git checkouts for
channels.  There's a single instance of this actor; it limits
concurrent Git updates.

  - The "evaluator" spawns evaluations of jobsets for the given channel
instances, again limiting the number of concurrent evaluations.

  - The "builder" spawns derivation builds.  There are currently two
implementations: the local builder sends build requests to the local
'guix-daemon' process, while the remote build delegates builds to
'cuirass remote-server'.

  - Each jobset as an associated "monitor"; it requests channel updates,
evaluations, and builds to the actors above.  It also receives requests
such as evaluation triggers that can come, for example, from the
/jobset/NAME/hook/evaluate HTTP endpoint.

  - The "jobset" registry is a directory that maps jobset names to their
monitor.

In addition, ‘cuirass register’ implements a “bridge”: it listens for
connections on a Unix-domain socket, which allows ‘cuirass web’ to send
it commands.

This is used for instance to implement the /jobset/NAME/hook/evaluate
HTTP endpoint, which lets users trigger an evaluation of the given
jobset.

With this actor split, one could implement another “builder” backend,
for instance one that talks to a Build Coordinator process.  It’s also
obviously close to the programming model encouraged by Goblins, which
should make eventual migration easier (and when that happens, if Goblins
provides an inter-process transport, we’ll no longer need the custom
“bridge” and we’ll be able to move actors from one process to another
much more easily.)

Feedback welcome!

Ludo’.

¹ https://lists.gnu.org/archive/html/guix-devel/2023-07/msg00096.html
² 
https://git.savannah.gnu.org/cgit/guix/guix-cuirass.git/tree/TODO?id=9b227abd29b15e7e25c54a71c524e7b26252a270
³ https://git.savannah.gnu.org/cgit/guix/guix-cuirass.git/log/?h=wip-actors

Re: News from Cuirass

[Ludovic Courtès]

Hello!

Felix Lechner  skribis:

> On Sun, Jul 16, 2023 at 6:53 AM Ludovic Courtès  wrote:
>>
>> Cuirass now uses a database
>> connection pool
>
> That is super exciting! In another implementation the pooling code
> comes with the database interface [1] which makes it available more
> broadly. Could the pooling code, which presumably lives here, [2]
> perhaps become part of Guile-Squee?

The pool implementation is here:

  
https://git.savannah.gnu.org/cgit/guix/guix-cuirass.git/tree/src/cuirass/utils.scm?id=c4743b54720e86b0e0b0295fb6d33977e4293644#n96

Currently Guile-Squee does not depend on Fibers, so I don’t think we can
move the pool there, or at least not without changing that (but I think
it’s good that one can use Guile-Squee without Fibers).

Thanks,
Ludo’.

Re: News from Cuirass

[Development of GNU Guix and the GNU System distribution.]

Hi Ludovic,

On Sun, Jul 16, 2023 at 6:53 AM Ludovic Courtès  wrote:
>
> Cuirass now uses a database
> connection pool

That is super exciting! In another implementation the pooling code
comes with the database interface [1] which makes it available more
broadly. Could the pooling code, which presumably lives here, [2]
perhaps become part of Guile-Squee?

Also, Kudos on your dive into ZeroMQ! I hope you find the experience
as rewarding as I did.

Kind regards & thanks,
Felix

[1] https://node-postgres.com/features/pooling
[2] 
https://git.savannah.gnu.org/cgit/guix/guix-cuirass.git/tree/src/cuirass/database.scm#n269

News from Cuirass

[Ludovic Courtès]

Hello Guix!

A couple of months ago, I found myself working on hot fixes for Cuirass,
whose repository had been gathering dust for months.  One thing leads to
another, and I’ve worked on a few improvements recently:

  • Guile-Squee (interface to PostgreSQL) now cooperates with Fibers,
meaning that ‘exec-query’ is suspendable.

  • Thanks to advice from Chris Baines, Cuirass now uses a database
connection pool instead of the database service thread it used to
have.

  • ‘cuirass remote-server’ and ‘cuirass remote-worker’, the processes
in charge of distributing builds remotely and that communicate over
ZeroMQ, are now single fiberized processes (this was made possible
by making the ‘receive-message’ procedure, built upon
Guile-Simple-ZMQ, cooperative).  These commands used to spawn a
bunch of processes and threads.

  • Assorted improvements to the web interface and to logging.

I’m regularly deploying the latest revision at
<https://guix.bordeaux.inria.fr> using the Cuirass channel (I’m
purposefully postponing an update of the ‘cuirass’ package until I’ve
acquired more experience and confidence.)  If you’re running an instance
of Cuirass and feeling adventurous, you can try it as well:

  (cons* (channel
  (name 'cuirass)
  (url "https://git.savannah.gnu.org/git/guix/guix-cuirass.git;)
  (introduction
   (make-channel-introduction
"c75620777c33273fcd14261660288ec1b2dc8123"
(openpgp-fingerprint
 "3CE4 6455 8A84 FDC6 9DB4  0CFB 090B 1199 3D9A EBB5"
 %default-channels)

With these architectural changes, we should be able to make more visible
improvements such as adding web hooks (so a Git repo can trigger a new
evaluation), replacing polling with notifications in many cases, adding
a Build Coordinator backend (convergence!), etc.  See
<https://git.savannah.gnu.org/cgit/guix/guix-cuirass.git/tree/TODO>.

Contributions welcome!  :-)

Ludo’.

Cuirass package build timeouts and max-silent-time [was Re: Merging branch wip-haskell]

[Leo Famulari]

On Wed, Mar 08, 2023 at 08:31:33PM +0100, Lars-Dominik Braun wrote:
> Hello Felix,
> 
> > I see build failures [1] for Ghc 9.2.5 in the Cuirass job set [2] for
> > my own feature branch. [3] They are caused by a one-hour timeout. Did
> > you folks figure out how to extend the timeout limit on Cuirass when
> > working on your own branch? Thanks!
> 
> I don’t see GHC being rebuild in [2] and GHC 9.2 should
> have a higher max-silent-time than 1 hour on master since
> 3bb2078a12d78a13f1e1520fe3705333a74ef6e3 (which is part of your
> branch). So I’m slightly confused.

I suspect that GHC was never built by Cuirass, but that somebody logged
in to the build server and invoked `guix build ghc
--max-silent-time=9`.

There's no logs of a successful build of GHC 9.2.5 available through the
Cuirass web interface, which is a clue that my hunch is correct. Builds
performed "by hand" don't appear in the web interface.

https://ci.guix.gnu.org/search?query=spec%3Amaster+ghc-9.2.5

Are we sure that Cuirass honors the max-silent-time property? If I
remember correctly, it did not do so in the past.

Re: rust-team cuirass build

[Joshua Branson]

Efraim Flashner  writes:

> The Rust Team has been hard at work updating the rust compiler and a
> number of rust packages. We've tested a number of packages¹ to ensure
> that everything looks okay.
>
> Quick stats for the branch:
> 404 commits by 4 people.
> 181 packages updated
> 50 packages removed
> 155 new packages
> rust updated to 1.67.
> '#:skip-build? #t' no longer breaks the 'package phase.
> librsvg updated to 2.54.5.
> gdk-pixbuf updated to 2.42.10.
> rav1e updated to 0.6.3.
> tealdeer updated to 1.6.1.
>
>
> ¹ librsvg -e '(@@ (gnu packages gnome) librsvg-bootstrap)' rav1e 
> rust-cbindgen@0.23 ripgrep tealdeer fd newsboat

Great job team!  From what I hear rust is really hard to package
properly!  Great work!

Is there work on a new rust build system? Is that still being worked on?

Re: [PATCH] Cuirass: Complete IPv6 support

[Leo Famulari]

On Sat, Mar 4, 2023, at 03:12, Christopher Baines wrote:
> Leo Famulari  writes:
>
>> On Wed, Mar 01, 2023 at 12:34:08AM -0800, Ryan Sundberg wrote:
>>> Hello Guix hackers,
>>> 
>>> I have implemented IPv6 support for Cuirass in the attached patchset.
>>> This has been tested on a multi-node cluster running Cuirass over IPv6
>>> with some real builds. It should maintain full backwards compatibility
>>> with the default IPv4, only enabling IPv6 when given the arguments to
>>> bind to IPv6 addresses. See the commit log for full details!
>>
>> Thanks, this is great! Can you send the patches to
>> , so that we can use qa.guix.gnu.org for testing?
>
> Note that these are patches for cuirass rather than guix, which
> qa.guix.gnu.org doesn't currently support applying/testing.

Oh right! Well, who shall review? :)

Re: [PATCH] Cuirass: Complete IPv6 support

[Christopher Baines]

Leo Famulari  writes:

> On Wed, Mar 01, 2023 at 12:34:08AM -0800, Ryan Sundberg wrote:
>> Hello Guix hackers,
>> 
>> I have implemented IPv6 support for Cuirass in the attached patchset.
>> This has been tested on a multi-node cluster running Cuirass over IPv6
>> with some real builds. It should maintain full backwards compatibility
>> with the default IPv4, only enabling IPv6 when given the arguments to
>> bind to IPv6 addresses. See the commit log for full details!
>
> Thanks, this is great! Can you send the patches to
> , so that we can use qa.guix.gnu.org for testing?

Note that these are patches for cuirass rather than guix, which
qa.guix.gnu.org doesn't currently support applying/testing.


signature.asc
Description: PGP signature

Re: [PATCH] Cuirass: Complete IPv6 support

[Leo Famulari]

On Wed, Mar 01, 2023 at 12:34:08AM -0800, Ryan Sundberg wrote:
> Hello Guix hackers,
> 
> I have implemented IPv6 support for Cuirass in the attached patchset.
> This has been tested on a multi-node cluster running Cuirass over IPv6
> with some real builds. It should maintain full backwards compatibility
> with the default IPv4, only enabling IPv6 when given the arguments to
> bind to IPv6 addresses. See the commit log for full details!

Thanks, this is great! Can you send the patches to
, so that we can use qa.guix.gnu.org for testing?

To send a multi-patch series, you'll need to first send an introductory
message to , and then send the patches to the
special ticket-number email address that it gives you in response.

rust-team cuirass build

[Efraim Flashner]

The Rust Team has been hard at work updating the rust compiler and a
number of rust packages. We've tested a number of packages¹ to ensure
that everything looks okay.

Real world testing has occurred on x86_64 and has started on riscv64 but
we'd like to request that a job be added to cuirass so we can make sure
that everything builds nicely on the build farm and on the other
architectures.

Quick stats for the branch:
404 commits by 4 people.
181 packages updated
50 packages removed
155 new packages
rust updated to 1.67.
'#:skip-build? #t' no longer breaks the 'package phase.
librsvg updated to 2.54.5.
gdk-pixbuf updated to 2.42.10.
rav1e updated to 0.6.3.
tealdeer updated to 1.6.1.


¹ librsvg -e '(@@ (gnu packages gnome) librsvg-bootstrap)' rav1e 
rust-cbindgen@0.23 ripgrep tealdeer fd newsboat

-- 
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

[PATCH] Cuirass: Complete IPv6 support

[Ryan Sundberg]

Hello Guix hackers,

I have implemented IPv6 support for Cuirass in the attached patchset.
This has been tested on a multi-node cluster running Cuirass over IPv6
with some real builds. It should maintain full backwards compatibility
with the default IPv4, only enabling IPv6 when given the arguments to
bind to IPv6 addresses. See the commit log for full details!


-- 
--
Sincerely,
Ryan SundbergFrom 42de39c21dc234571b498ba4dd9dd0ab1a4d3f57 Mon Sep 17 00:00:00 2001
From: Ryan Sundberg 
Date: Tue, 17 Jan 2023 22:35:31 -0800
Subject: [PATCH 4/4] remote: support IPv6 publish urls

When the server address is IPv6, build a compatible publish-url.

* src/cuirass/remote.scm (ipv6-address?): New function
(publish-url): Build IPv6 compatible URLs
---
 src/cuirass/remote.scm | 12 ++--
 1 file changed, 10 insertions(+), 2 deletions(-)

diff --git a/src/cuirass/remote.scm b/src/cuirass/remote.scm
index 44b342d..caec985 100644
--- a/src/cuirass/remote.scm
+++ b/src/cuirass/remote.scm
@@ -162,7 +162,11 @@
 
 (define (publish-url address port)
   "Return the publish url at ADDRESS and PORT."
-  (string-append "http://; address ":" (number->string port)))
+  (format #f "http://~a:~d;
+  (if (ipv6-address? address)
+(format #f "[~a]" address)
+address)
+  port))
 
 (define (avahi-service->params service)
   "Return the URL of the publish server corresponding to the service with the
@@ -223,11 +227,15 @@ properties."
  #:verbosity 1
  #:substitute-urls urls))
 
+(define (ipv6-address? address)
+  "Is ADDRESS an ipv6 address?"
+  (not (not (string-index address #\:
+
 (define (parse-host-address host)
   (cond
 ((not host)
  (values AF_INET PF_INET INADDR_ANY))
-((string-index host #\:)
+((ipv6-address? host)
  (values AF_INET6 PF_INET6 (inet-pton AF_INET6 host)))
 (else
  (values AF_INET PF_INET (inet-pton AF_INET host)
-- 
2.37.2

From c2f00c82e7b2ba3789e58d772d6cde41f651ed9d Mon Sep 17 00:00:00 2001
From: Ryan Sundberg 
Date: Sat, 14 Jan 2023 09:20:20 -0800
Subject: [PATCH 3/4] web: Support binding to IPv6 addresses with --listen

* src/cuirass/http.scm (run-cuirass-server): Detect AF_INET6 addresses
* src/web/server/fiberized.scm (make-default-socket): Ditto
---
 src/cuirass/http.scm | 19 +++
 src/web/server/fiberized.scm |  5 -
 2 files changed, 19 insertions(+), 5 deletions(-)

diff --git a/src/cuirass/http.scm b/src/cuirass/http.scm
index a9fc3ea..07359c2 100644
--- a/src/cuirass/http.scm
+++ b/src/cuirass/http.scm
@@ -1148,10 +1148,19 @@ passed, only display JOBS targeting this SYSTEM."
 (_
  (respond-not-found (uri->string (request-uri request))
 
+(define (lookup-host host)
+  (cond
+;; Detect IPv6 addresses and skip DNS resolution
+((string-index host #\:)
+ (values AF_INET6 host))
+
+(else
+  (let* ((host-info (gethostbyname host))
+ (family (hostent:addrtype host-info)))
+(values family (inet-ntop family (car (hostent:addr-list host-info
+
 (define* (run-cuirass-server #:key (host "localhost") (port 8080))
-  (let* ((host-info  (gethostbyname host))
- (address(inet-ntop (hostent:addrtype host-info)
-(car (hostent:addr-list host-info)
+  (let-values (((family address) (lookup-host host)))
 (log-info "listening on ~A:~A" address port)
 
 ;; Here we use our own web backend, call 'fiberized'.  We cannot use the
@@ -1168,7 +1177,9 @@ passed, only display JOBS targeting this SYSTEM."
 ;;
 ;; XXX: We don't do 'call-with-sigint' like 'run-server' does.
 (let* ((impl (lookup-server-impl 'fiberized))
-   (server (open-server impl `(#:host ,address #:port ,port
+   (server (open-server impl `(#:host ,address
+   #:family ,family
+   #:port ,port
   (let loop ()
 (let-values (((client request body)
   (read-client impl server)))
diff --git a/src/web/server/fiberized.scm b/src/web/server/fiberized.scm
index 23a2bd9..78edab5 100644
--- a/src/web/server/fiberized.scm
+++ b/src/web/server/fiberized.scm
@@ -49,7 +49,10 @@
   #:use-module (cuirass utils))
 
 (define (make-default-socket family addr port)
-  (let ((sock (socket PF_INET SOCK_STREAM 0)))
+  (let* ((proto-family (cond
+ ((= family AF_INET) PF_INET)
+ ((= family AF_INET6) PF_INET6)))
+ (sock (socket proto-family SOCK_STREAM 0)))
 (setsockopt sock SOL_SOCKET SO_REUSEADDR 1)
 (fcntl sock F_SETFD FD_CLOEXEC)
 (bind sock family addr port)
-- 
2.37.2

From d688a4bce88310ed4b3001c7b3a38c13e9eff891 Mon Sep 17 00:00:00 2001
From: Ryan Sundberg 
Date: Fri, 13 Jan 2023 23:42:21 -0800
Subject: [PATCH 2/4] remot

cuirass manual not found

[Andy Tai]

on the cuirass web page,

https://guix.gnu.org/cuirass/

the link to the cuirass manual, https://guix.gnu.org/cuirass/manual/,
leads to a 404 not found error

Re: Questions about Cuirass

[Maxime Devos]

On 30-10-2022 13:50, James Hobson wrote:

Sorry for not getting back to you.

Looks promising!

I wish I could release everything under a free license. Baby steps though! I’ve 
managed to release a few things under LGPL since I started! That’s 100% more 
than before!


Sounds good.


But anyway. The biggest hurdle I see is that updating in an air gapped 
environment doesn’t seem supported because guix’s git url is hard coded. Does 
this need to be the case? If not, I might see if I can find an nice way of 
making this more configurable


There is a default, yes, but it's not hardcoded, you can override it. 
Have a look at "Invoking 'guix pull'" in the manual, in particular its 
'--url=URL' argument.



James


> [...]

I prefer no top-posting; my e-mail client, and more generally almost all 
e-mail clients I think, keep a thread of previous messages.  I would 
prefer to not to have to scroll down to read the rest of the message 
only to discover there is none.


Greetings,
Maxime


OpenPGP_0x49E3EE22191725EE.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

Re: Questions about Cuirass

[James Hobson]

Sorry for not getting back to you.

Looks promising!

I wish I could release everything under a free license. Baby steps though! I’ve 
managed to release a few things under LGPL since I started! That’s 100% more 
than before!

But anyway. The biggest hurdle I see is that updating in an air gapped 
environment doesn’t seem supported because guix’s git url is hard coded. Does 
this need to be the case? If not, I might see if I can find an nice way of 
making this more configurable

James

> On 21 Oct 2022, at 11:01, Maxime Devos  wrote:
> 
> On 20-10-2022 23:19, James Hobson wrote:
>> Hello!
>> Currently evaluating guix for embedded systems at work. But I have a few 
>> questions that I can’t quite work out from the docs. Please feel no 
>> obligation to answer!
>> Please note that my guix journey is at its very beginning. I’ve not even had 
>> a go at packaging!
>> Question 1
>> We would need to host the guix substitute server in an airgapped 
>> environment. The server would contain plain guix packages, our in house 
>> packages, and maybe patched guix packages. Would that be possible without 
>> having to rebuild the entire guix package set? We don’t have so many build 
>> machines, especially not for armv7.
> 
> You can tell Cuirass to only build a selection of packages (and their 
> dependencies), by using a manifest, then not all of Guix is compiled but only 
> what's necessary for your particular purpose.
> 
> Also, your Cuirass instance still needs access to the source code of the 
> packages somehow, which will need to be somehow be squared with your 
> 'airgapped environment', though maybe 'copy over the result of guix build 
> --sources=transitive" would be acceptable (*).
> 
> (*) except that this is after application of snippet; some kind of 
> "--sources=raw,transitive" may be needed.
> 
>> Question 2 [...]
> 
> I don't know the answer to this.
> 
>> Question 3
>> Our software is sadly proprietary. Is there a way for guix build to 
>> selectively unpack and patch all non-proprietary sources so that we can 
>> provide it to anyone who asks? I feel like if this isn’t a thing already, I 
>> guess I can write it in scheme?
> 
> I assume you meant 'patch all non-proprietary' -> 'patch out all 
> proprietary', such that at least the free parts can be used?
> 
> In that case, this is done already in some package definitions in Guix, by a 
> 'snippet' removing parts that are non-free, such that they are not built and 
> are not part of "guix build --source". (See: ‘Snippets versus Phases’ in the 
> documentation, though it doesn't mention non-free things directly).
> 
> The Guix user can still access the unpatched source code though, by 
> inspecting the package definition and removing the snippet, so it looks to me 
> like that option is only good for 'you aren't allowed to modify this part of 
> the source code + guix build --source must produce something free', not for 
> 'you aren't allowed to see or distribute this' situations.
> 
> Alternatively, you could avoid all this complexity by making your software 
> free.
> 
> Greetings,
> Maxime.
> 

Re: Questions about Cuirass

[Maxime Devos]

On 20-10-2022 23:19, James Hobson wrote:

Hello!

Currently evaluating guix for embedded systems at work. But I have a few 
questions that I can’t quite work out from the docs. Please feel no obligation 
to answer!

Please note that my guix journey is at its very beginning. I’ve not even had a 
go at packaging!

Question 1
We would need to host the guix substitute server in an airgapped environment. 
The server would contain plain guix packages, our in house packages, and maybe 
patched guix packages. Would that be possible without having to rebuild the 
entire guix package set? We don’t have so many build machines, especially not 
for armv7.


You can tell Cuirass to only build a selection of packages (and their 
dependencies), by using a manifest, then not all of Guix is compiled but 
only what's necessary for your particular purpose.


Also, your Cuirass instance still needs access to the source code of the 
packages somehow, which will need to be somehow be squared with your 
'airgapped environment', though maybe 'copy over the result of guix 
build --sources=transitive" would be acceptable (*).


(*) except that this is after application of snippet; some kind of 
"--sources=raw,transitive" may be needed.



Question 2 [...]


I don't know the answer to this.


Question 3
Our software is sadly proprietary. Is there a way for guix build to selectively 
unpack and patch all non-proprietary sources so that we can provide it to 
anyone who asks? I feel like if this isn’t a thing already, I guess I can write 
it in scheme?


I assume you meant 'patch all non-proprietary' -> 'patch out all 
proprietary', such that at least the free parts can be used?


In that case, this is done already in some package definitions in Guix, 
by a 'snippet' removing parts that are non-free, such that they are not 
built and are not part of "guix build --source". (See: ‘Snippets versus 
Phases’ in the documentation, though it doesn't mention non-free things 
directly).


The Guix user can still access the unpatched source code though, by 
inspecting the package definition and removing the snippet, so it looks 
to me like that option is only good for 'you aren't allowed to modify 
this part of the source code + guix build --source must produce 
something free', not for 'you aren't allowed to see or distribute this' 
situations.


Alternatively, you could avoid all this complexity by making your 
software free.


Greetings,
Maxime.


OpenPGP_0x49E3EE22191725EE.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

Questions about Cuirass

[James Hobson]

Hello!

Currently evaluating guix for embedded systems at work. But I have a few 
questions that I can’t quite work out from the docs. Please feel no obligation 
to answer!

Please note that my guix journey is at its very beginning. I’ve not even had a 
go at packaging!

Question 1
We would need to host the guix substitute server in an airgapped environment. 
The server would contain plain guix packages, our in house packages, and maybe 
patched guix packages. Would that be possible without having to rebuild the 
entire guix package set? We don’t have so many build machines, especially not 
for armv7.

Question 2
Does cuirass garbage collect? Or is that done through guix gc? We would need to 
host the binary packages for maybe 3 revisions at a time in this air gapped 
server.

Question 3
Our software is sadly proprietary. Is there a way for guix build to selectively 
unpack and patch all non-proprietary sources so that we can provide it to 
anyone who asks? I feel like if this isn’t a thing already, I guess I can write 
it in scheme?

Thanks

James

Re: Cuirass and SQL

[Ludovic Courtès]

Hi,

Arun Isaac  skribis:

>> Years before, Hydra (https://nixos.org/hydra) also dropped its SQLite
>> backend in favor of PostgreSQL only.
>>
>> Like you, not being a database person, I liked that SQLite was easy to
>> deploy and had a clear model: it just touches this one file and that’s
>> it.
>
> Exactly! :-)
>
> If we use guile-dbi, it should be possible to support both sqlite and
> postgresql. Popular projects like Nextcloud do allow the user to choose
> their preferred database system. But, then again, Cuirass is built for
> very large scale. So, perhaps it is best to not try and also cover the
> small scale end.

That too was my understanding some years ago.  :-)

But then I discovered that in practice, you optimize for a specific
DBMS.  The way you’d optimize a Postgres or an SQLite database for your
application can be quite different.  An abstraction wouldn’t let you do
that.

> Scale may not be an issue at least for the CI. Unlike Guix which needs
> to rebuild the entire world of software, most other software are only
> going to have a handful of jobs---easily less than 5 or less than 10 in
> the worst case. So, even if we trigger all these jobs on every commit,
> the total number of runs will easily be manageable with sqlite.

Yes, could be!

Thanks,
Ludo’.

Re: Cuirass and SQL

[Arun Isaac]

Hi Ludo,

> Years before, Hydra (https://nixos.org/hydra) also dropped its SQLite
> backend in favor of PostgreSQL only.
>
> Like you, not being a database person, I liked that SQLite was easy to
> deploy and had a clear model: it just touches this one file and that’s
> it.

Exactly! :-)

If we use guile-dbi, it should be possible to support both sqlite and
postgresql. Popular projects like Nextcloud do allow the user to choose
their preferred database system. But, then again, Cuirass is built for
very large scale. So, perhaps it is best to not try and also cover the
small scale end.

> SQLite may be good enough at a small scale; the problem is that you
> never know how long it’ll be before the project you’re hosting is no
> longer small-scale.

Scale may not be an issue at least for the CI. Unlike Guix which needs
to rebuild the entire world of software, most other software are only
going to have a handful of jobs---easily less than 5 or less than 10 in
the worst case. So, even if we trigger all these jobs on every commit,
the total number of runs will easily be manageable with sqlite.

Regards,
Arun

Re: Cuirass and SQL

[Ludovic Courtès]

Hi,

Arun Isaac  skribis:

>> Initially, Cuirass was using SQLite but then switched [1] to
>> PostgreSQL.  The main reason is scalability.
>
> Ah, I see. I didn't know that.

Years before, Hydra (https://nixos.org/hydra) also dropped its SQLite
backend in favor of PostgreSQL only.

Like you, not being a database person, I liked that SQLite was easy to
deploy and had a clear model: it just touches this one file and that’s it.

Yet, I’m starting to see a pattern.  :-)

SQLite may be good enough at a small scale; the problem is that you
never know how long it’ll be before the project you’re hosting is no
longer small-scale.

Ludo’.

Re: Cuirass and SQL

[Development of GNU Guix and the GNU System distribution.]

On Fri, 27 May 2022, zimoun  wrote:

> Initially, Cuirass was using SQLite but then switched [1] to
> PostgreSQL.  The main reason is scalability.

Make sens for the main CI used by Guix or for an organization.

> I do not know if it is a technically doable to have two SQL backends and
> let the user pick the one they prefer.  For sure, it is not doable from
> a maintenance point of view.

With guile-dbi, the maintenance is trivial.

> About the complexity of PostgreSQL, I think the Guix services [2,3]
> help here.

This is what I did.  I have a local CI as a service that build my
projects at every new commits on a specific branch.  It works, but I
feel thing would have been easier to setup with SQLite.  It could had
been a guix-home service for example instead of a system service and
testing the configuration is much easier with a scratch DB.

-- 
Olivier Dion
oldiob.dev

Re: Cuirass and SQL

[jgart]

On Fri, 27 May 2022 11:06:24 +0200 zimoun  wrote:

Hi Guixers,

Here is the video recording from today:

https://archive.org/details/guix-forge-arun-isaac-may-28-2022

enjoy,

jgart

https://whereis.xn--q9jyb4c/

Re: Cuirass and SQL

[Arun Isaac]

> For simplicity in a single-system deployment I recommend running
> postgres in "trust" mode and listen on a local unix socket rather than
> exposing it to the network. This allows you to use the same access
> control for Postgres that you'd use for an sqlite3 db file: file
> permissions.

This is useful, thanks! I didn't know about this.

Re: Cuirass and SQL

[Ryan Prior]

--- Original Message ---
On Saturday, May 28th, 2022 at 8:45 AM, Arun Isaac  
wrote:

> There's still the complexity of backing up a PostgreSQL
> database

How much easier is sqlite3?

I host a Postgres server on DigitalOcean with automatic db backup. I've had to 
restore, it's easy and it works. I also have a few apps in Fly.io using 
sqlite3, backups are equivalently easy.

> Then, there's the added complexity of
> maintaining database users and authentication

For simplicity in a single-system deployment I recommend running postgres in 
"trust" mode and listen on a local unix socket rather than exposing it to the 
network. This allows you to use the same access control for Postgres that you'd 
use for an sqlite3 db file: file permissions.

Re: Cuirass and SQL

[Arun Isaac]

Hi zimoun,

> Initially, Cuirass was using SQLite but then switched [1] to
> PostgreSQL.  The main reason is scalability.

Ah, I see. I didn't know that.

> I do not know if it is a technically doable to have two SQL backends and
> let the user pick the one they prefer.  For sure, it is not doable from
> a maintenance point of view.

It should be possible with guile-dbi and guile-dbd-*, which abstract
away the database server in use. But, cuirass switched from
guile-sqlite3 to guile-squee, both of which are database server
specific.

> About the complexity of PostgreSQL, I think the Guix services [2,3]
> help here.

There's still the complexity of backing up a PostgreSQL
database---something IIUC the Guix service does not help with, and
probably cannot help with. Then, there's the added complexity of
maintaining database users and authentication. All this is very overkill
for a small CI system.

Cheers!
Arun

Re: Cuirass and SQL

[Blake Shaw]

For any cuirass-curious readers, I want to say I deployed it on Linode a
week ago and its been one of the most "just works" out-of-the-box tools in
the guix arsenal that I've encountered. It was really easy and painless to
get going, and makes "pinning" milestone system & profile generations a
breeze so that you always have substitutes available for them. This has
sped up my guix workflow tremendously, as I'm able to just commit push,
branch off, try other ideas, push, review past results and keep moving,
instead of getting distracted by checking the news or what have you.

 The remote-server sometimes stops allocating builds to workers though, but
I just restart the server and its fine.

Feels like proper boutique gear, too ;)

On Fri, May 27, 2022, 16:41 zimoun  wrote:

> Hi,
>
> On jeu., 26 mai 2022 at 00:24, Arun Isaac 
> wrote:
>
> >> Quick question about guix-forge.  Why laminar instead of cuirass as
> >> the CI?
> >
> > Two reasons:
> >
> > - Cuirass requires a PostgreSQL database, but I wanted guix-forge to be
> >   as stateless as possible and definitely not require a complex database
> >   server like PostgreSQL. Laminar just uses sqlite.
>
> Initially, Cuirass was using SQLite but then switched [1] to
> PostgreSQL.  The main reason is scalability.
>
> I do not know if it is a technically doable to have two SQL backends and
> let the user pick the one they prefer.  For sure, it is not doable from
> a maintenance point of view.
>
> About the complexity of PostgreSQL, I think the Guix services [2,3] help
> here.
>
>
>
> 1: <
> http://git.savannah.gnu.org/cgit/guix/guix-cuirass.git/commit/?id=cbc462679d2647ecc897231cc78781a90fa2441a
> >
> 2: <
> https://guix.gnu.org/en/manual/devel/en/guix.html#Continuous-Integration>
> 3: <https://guix.gnu.org/en/manual/devel/en/guix.html#Database-Services>
>
>
> Cheers,
> simon
>
>

Cuirass and SQL

[zimoun]

Hi,

On jeu., 26 mai 2022 at 00:24, Arun Isaac  wrote:

>> Quick question about guix-forge.  Why laminar instead of cuirass as
>> the CI?
>
> Two reasons:
>
> - Cuirass requires a PostgreSQL database, but I wanted guix-forge to be
>   as stateless as possible and definitely not require a complex database
>   server like PostgreSQL. Laminar just uses sqlite.

Initially, Cuirass was using SQLite but then switched [1] to
PostgreSQL.  The main reason is scalability.

I do not know if it is a technically doable to have two SQL backends and
let the user pick the one they prefer.  For sure, it is not doable from
a maintenance point of view.

About the complexity of PostgreSQL, I think the Guix services [2,3] help here.



1: 
<http://git.savannah.gnu.org/cgit/guix/guix-cuirass.git/commit/?id=cbc462679d2647ecc897231cc78781a90fa2441a>
2: <https://guix.gnu.org/en/manual/devel/en/guix.html#Continuous-Integration>
3: <https://guix.gnu.org/en/manual/devel/en/guix.html#Database-Services>


Cheers,
simon

[BUG] Cuirass seems stuck in a loop.

[Pierre-Henry Fröhring]

Hello Guix!

I've a strange behaviour using Cuirass.

* Symptoms

#+begin_example
$ cat /var/log/cuirass.log 
…
2022-02-22T16:18:17 Fetching channels for spec 'flat'.  

  
2022-02-22T16:18:18 next evaluation in 60 seconds   

  
2022-02-22T16:18:26 error: build succeeded: 
'/gnu/store/rrp2yqlff0b6mz7frwdghclxb7qhqr2n-texlive-psnfss-59745-checkout.drv' 
  
2022-02-22T16:18:26 error: build started: 
'/gnu/store/gqc8jcd6vwh6gd64xfjiisjn5jzynvvv-texlive-ruhyphen-59745-checkout.drv'
   
2022-02-22T16:18:26 error: build succeeded: 
'/gnu/store/gqc8jcd6vwh6gd64xfjiisjn5jzynvvv-texlive-ruhyphen-59745-checkout.drv'
 
2022-02-22T16:18:27 error: build started: 
'/gnu/store/v8596k4spyd6j71zb1vsw3bbvpn232r4-texlive-scripts-59745-checkout.drv'

2022-02-22T16:18:27 error: build succeeded: 
'/gnu/store/v8596k4spyd6j71zb1vsw3bbvpn232r4-texlive-scripts-59745-checkout.drv'
 
…
#+end_example


* Guix describe

#+begin_example
# guix describe
Generation 2  Feb 22 2022 14:58:35  (current)
  guix 218400c
repository URL: https://git.savannah.gnu.org/git/guix.git
branch: master
commit: 218400c0f7d754467eac20bbdea3c5282efe7b2e
#+end_example


* Operating system

#+begin_example
(use-modules (gnu)
 (gnu services web)
 (gnu services rsync)
 (gnu services avahi)
   (gnu services cuirass)
   (gnu packages certs)
 (gnu packages rsync))
(use-service-modules networking ssh)
(use-package-modules screen ssh)


(define %nftables-ruleset
  (plain-file "nftables.conf"
  "# A simple and safe firewall
table inet filter {
  chain input {
type filter hook input priority 0; policy drop;

# early drop of invalid connections
ct state invalid drop

# allow established/related connections
ct state { established, related } accept

# allow from loopback
iifname lo accept

# allow icmp
ip protocol icmp accept
ip6 nexthdr icmpv6 accept

# allow ssh and http
tcp dport {ssh, https, http, rsync} accept

# reject everything else
reject with icmpx type port-unreachable
  }
  chain forward {
type filter hook forward priority 0; policy drop;
  }
  chain output {
type filter hook output priority 0; policy accept;
  }
}
"))


(operating-system
 (host-name "guixsd-1")

 (timezone "Europe/Paris")

 (locale "en_US.UTF-8")

 (bootloader (bootloader-configuration
  (bootloader grub-bootloader)
  (target "/dev/vda")))

 (file-systems (cons (file-system
  (device "/dev/vda1")
  (mount-point "/")
  (type "ext4"))
 %base-file-systems))

 (users (cons (user-account
   (name "phf")
   (group "users")
   (supplementary-groups '("wheel"))
   (home-directory "/home/phf"))
  %base-user-accounts))

 (packages (cons*

;; rsync is installed system wide.
;;
 When connecting non-interactively over SSH, Guix will
 source /etc/profile. It will not source your users's
 own profile, but only the system profile.
 see: 
https://git.savannah.gnu.org/cgit/guix.git/tree/gnu/system/shadow.scm?id=1684ed6537fbd91ae5c14fb0314564e71799d390#n136
rsync
nss-certs
screen
openssh
%base-packages))

 ;; Set your Droplet, static network configuration
 (services
  (append
   (list ;; Static address
(service static-networking-service-type
 (list (static-networking
(addresses
 (list (network-address
(device "eth0")
;; ip a
(value "134.209.246.249/20"
(routes
 (list (network-route
(destination "default")
    ;; ip r
    (gateway "134.209.240.1"
(name-servers '("8.8.8.8" "8.8.4.4")

;; SSH
;; ( … )

;; Cuirass
(service cuirass-service-type
 (cuirass-configuration
  (specifications #~'())
  (host "0.0.0.0")))

 

Re: cuirass schedules aarch64 jobs on x86_64?

[Ricardo Wurmus]

Ricardo Wurmus  writes:

> We have a lot of aarch64 failures that I’m manually restarting and or
> building on the honeycomb machines on my desk.
>
> Here’s one of them that fails in Cuirass:
>
> https://ci.guix.gnu.org/build/323991/details

I reconfigured all of the build nodes at the MDC with

guix deploy -L modules/ berlin-nodes.scm

followed by

guix deploy -L modules/ berlin-nodes.scm --execute -- herd restart 
guix-daemon

and now this should no longer happen.

Commit 027f0e7a589e2500f7e6cdc6332b0069ffc7f33b in the maintenance.git
repo removes aarch64-linux from the default systems for berlin build
nodes.

-- 
Ricardo

cuirass schedules aarch64 jobs on x86_64?

[Ricardo Wurmus]

We have a lot of aarch64 failures that I’m manually restarting and or
building on the honeycomb machines on my desk.

Here’s one of them that fails in Cuirass:

https://ci.guix.gnu.org/build/323991/details

And here’s the associated log:

--8<---cut here---start->8---
building path(s) `/gnu/store/cv9kv5x2dq1sx52rcll07isblwh9ax4a-libxtst-1.2.3'
|   @ build-started 
/gnu/store/pxc6wrwkwcsw2y10h48i7rkykbcjnm67-libxtst-1.2.3.drv - aarch64-linux 
/var/log/guix/drvs/px//c6wrwkwcsw2y10h48i7rkykbcjnm67-libxtst-1.2.3.drv.gz 49075
|   @ unsupported-platform 
/gnu/store/pxc6wrwkwcsw2y10h48i7rkykbcjnm67-libxtst-1.2.3.drv aarch64-linux
while setting up the build environment: a `aarch64-linux' is required to build 
`/gnu/store/pxc6wrwkwcsw2y10h48i7rkykbcjnm67-libxtst-1.2.3.drv', but I am a 
`x86_64-linux'
builder for `/gnu/store/pxc6wrwkwcsw2y10h48i7rkykbcjnm67-libxtst-1.2.3.drv' 
failed with exit code 1
@ build-failed /gnu/store/pxc6wrwkwcsw2y10h48i7rkykbcjnm67-libxtst-1.2.3.drv - 
1 builder for `/gnu/store/pxc6wrwkwcsw2y10h48i7rkykbcjnm67-libxtst-1.2.3.drv' 
failed with exit code 1
--8<---cut here---end--->8---

What gives?

-- 
Ricardo

Re: Could someone please restart this Cuirass build?

[Thiago Jung Bauermann]

Em quinta-feira, 13 de janeiro de 2022, às 15:41:49 -03, Tobias Geerinckx-
Rice escreveu:
> Thiago Jung Bauermann 写道：
> 
> > Therefore, could someone please restart this Cuirass build?
> 
> Done.

Thank you!

-- 
Thanks,
Thiago

Re: Could someone please restart this Cuirass build?

[Tobias Geerinckx-Rice]

Thiago Jung Bauermann 写道：

Therefore, could someone please restart this Cuirass build?


Done.

Kind regards,

T G-R


signature.asc
Description: PGP signature

Could someone please restart this Cuirass build?

[Thiago Jung Bauermann]

Hello!

This powerpc64le-linux build:

https://ci.guix.gnu.org/build/70/details

failed because of the intermitent TLS error:

--8<---cut here---start->8---
guix substitute: error: TLS error in procedure 'read_from_session_record_port': 
Error decoding the received TLS packet.
fetching path 
`/gnu/store/fkkfffvwrj103zs5cf6d8bf9as46ywhc-python-minimal-3.5.9' (empty 
status: '')
@ substituter-failed 
/gnu/store/fkkfffvwrj103zs5cf6d8bf9as46ywhc-python-minimal-3.5.9  fetching path 
`/gnu/store/fkkfffvwrj103zs5cf6d8bf9as46ywhc-python-minimal-3.5.9' (empty 
status: '')
--8<---cut here---end--->8---

The problem is tracked in this issue:

https://issues.guix.gnu.org/42902

This build is very early in the dependency tree and thus causes a lot of
powerpc64le-linux builds to fail because of missing dependencies.
Therefore, could someone please restart this Cuirass build?
-- 
Thanks,
Thiago

Re: branch master updated: services: cuirass: Add a no-publish argument.

[Mathieu Othacehe]

Hey,

> So I’d suggest turning that into ‘publish?’, defaulting to #t.

Yeah, you're completely right, I reversed the logic with:
cfd2442488971420289a12d5ca8f07816e1149bf.

Thanks,

Mathieu

Re: branch master updated: services: cuirass: Add a no-publish argument.

[Ludovic Courtès]

Hi!

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

> commit d128c6fd33f46ec4e2d0ef352d20a858c377bf6f
> Author: Mathieu Othacehe 
> AuthorDate: Thu Aug 12 12:58:34 2021 +0200
>
> services: cuirass: Add a no-publish argument.
> 
> * gnu/services/cuirass.scm (): Add a
> no-publish? field.
> (cuirass-shepherd-service): Honor it.
> * doc/guix.texi (Cuirass remote building): Document it.

[...]

> +++ b/gnu/services/cuirass.scm
> @@ -72,6 +72,8 @@
>      (default "/var/log/cuirass-remote-server.log"))
>(cachecuirass-remote-server-configuration-cache ;string
>  (default "/var/cache/cuirass/remote/"))
> +  (no-publish?  cuirass-remote-server-configuration-no-publish? ;boolean
> +(default #f))

Nitpick: as a rule of thumb, I personally avoid negative options,
otherwise discussions easily end up with phrases like “disable
no-publish” and then you have to think twice before you’re confident
about the meaning.  :-)

So I’d suggest turning that into ‘publish?’, defaulting to #t.

Ludo’.

Re: Cuirass job names and package variants

[Leo Prikler]

Am Freitag, den 25.06.2021, 16:30 +0200 schrieb Ludovic Courtès:
> Leo Prikler  skribis:
> 
> > Am Freitag, den 25.06.2021, 13:44 +0200 schrieb Ludovic Courtès:
> 
> [...]
> 
> > > However, variants of a given package have the same package
> > > name/version,
> > > and thus the same job name.  Apparently Cuirass only takes the
> > > first
> > > job
> > > with a given name into account and dismisses subsequent ones.
> > > 
> > > What would be a good way to address this, either in Cuirass or in
> > > the
> > > user config?
> > Do we already know – or could we compute – store paths at this
> > point in
> > time?  It seems as though this could be solved once more by
> > assigning
> > ids based on hashed inputs.  So each job-name would be something
> > like
> > (package-name)-(package-version)-(first-bytes-of-package-input-
> > hash).
> > WDYT?
> 
> That job names are human-readable is a feature.  :-)
> 
> However, what we could do is have an autoincrement ID or similar (?)
> rather than the package name used as the actual key.  Dunno.
In that case there is nothing to relate jobs to packages, which I'd
assume is also a feature?  We could have job names be unique id +
package name, but since those ids grow larger and larger, i think
they'd soon become unreadable as well.  Maybe add -1, -2, -3,... to the
job names if a job with the same name is already queued like backup
systems do?

Re: Cuirass job names and package variants

[Ludovic Courtès]

Leo Prikler  skribis:

> Am Freitag, den 25.06.2021, 13:44 +0200 schrieb Ludovic Courtès:

[...]

>> However, variants of a given package have the same package
>> name/version,
>> and thus the same job name.  Apparently Cuirass only takes the first
>> job
>> with a given name into account and dismisses subsequent ones.
>> 
>> What would be a good way to address this, either in Cuirass or in the
>> user config?
> Do we already know – or could we compute – store paths at this point in
> time?  It seems as though this could be solved once more by assigning
> ids based on hashed inputs.  So each job-name would be something like
> (package-name)-(package-version)-(first-bytes-of-package-input-hash).
> WDYT?

That job names are human-readable is a feature.  :-)

However, what we could do is have an autoincrement ID or similar (?)
rather than the package name used as the actual key.  Dunno.

Thanks,
Ludo’.

Re: Cuirass job names and package variants

[Leo Prikler]

Am Freitag, den 25.06.2021, 13:44 +0200 schrieb Ludovic Courtès:
> Hello!
> 
> Cuirass support in (gnu ci) computes job names as a function of
> package
> names (the ‘job-name’ procedure).  I wanted to build several package
> variants using ‘--with-input’, which I expressed in a manifest:
> 
>   
> https://gitlab.inria.fr/guix-hpc/guix-hpc/-/blob/master/manifest#L33-50
> 
> However, variants of a given package have the same package
> name/version,
> and thus the same job name.  Apparently Cuirass only takes the first
> job
> with a given name into account and dismisses subsequent ones.
> 
> What would be a good way to address this, either in Cuirass or in the
> user config?
Do we already know – or could we compute – store paths at this point in
time?  It seems as though this could be solved once more by assigning
ids based on hashed inputs.  So each job-name would be something like
(package-name)-(package-version)-(first-bytes-of-package-input-hash).
WDYT?

Cuirass job names and package variants

[Ludovic Courtès]

Hello!

Cuirass support in (gnu ci) computes job names as a function of package
names (the ‘job-name’ procedure).  I wanted to build several package
variants using ‘--with-input’, which I expressed in a manifest:

  https://gitlab.inria.fr/guix-hpc/guix-hpc/-/blob/master/manifest#L33-50

However, variants of a given package have the same package name/version,
and thus the same job name.  Apparently Cuirass only takes the first job
with a given name into account and dismisses subsequent ones.

What would be a good way to address this, either in Cuirass or in the
user config?

I thought about changing the name that appears in manifest entries
(without changing the actual package name), but (@ (gnu ci)
manifests->packages) ignores manifest entry names.

Ideas?

Thanks,
Ludo’.

Re: Cuirass 1.1 released

[Ludovic Courtès]

Hi!

Mathieu Othacehe  skribis:

> We are pleased to announce the release of Cuirass 1.1.
>
> This is the second official release of Cuirass, the GNU Guix continuous
> integration software.  For the last six months, this project has been
> funded through the NGI0 PET Fund, a fund established by NLNet[1].
>
> Thanks to this support, Cuirass has seen numerous improvements, such as
> a switch to PostgreSQL and the introduction of a distributed build
> mechanism.  Cuirass is now providing substitutes to all Guix users in a
> faster and more reliable way while providing better monitoring.

Woohoo, congrats!  I started using Cuirass badges at work today, and I’m
sure it’s one of these things that’ll make my colleagues happier.  :-)

Thank you,
Ludo’.

Re: Cuirass 1.1 released

[Leo Famulari]

On Sun, Jun 13, 2021 at 12:59:55PM +0200, Mathieu Othacehe wrote:
> We are pleased to announce the release of Cuirass 1.1.
> 
> This is the second official release of Cuirass, the GNU Guix continuous
> integration software.  For the last six months, this project has been
> funded through the NGI0 PET Fund, a fund established by NLNet[1].
> 
> Thanks to this support, Cuirass has seen numerous improvements, such as
> a switch to PostgreSQL and the introduction of a distributed build
> mechanism.  Cuirass is now providing substitutes to all Guix users in a
> faster and more reliable way while providing better monitoring.

Congratulations on 1.1! Thank you for your hard work! And thanks to
NLNet for making it possible!  

Cuirass 1.1 released

[Mathieu Othacehe]

We are pleased to announce the release of Cuirass 1.1.

This is the second official release of Cuirass, the GNU Guix continuous
integration software.  For the last six months, this project has been
funded through the NGI0 PET Fund, a fund established by NLNet[1].

Thanks to this support, Cuirass has seen numerous improvements, such as
a switch to PostgreSQL and the introduction of a distributed build
mechanism.  Cuirass is now providing substitutes to all Guix users in a
faster and more reliable way while providing better monitoring.

• About

Cuirass is the GNU Guix continuous integration software. It's a general
purpose build automation server written in GNU Guile that checks out
sources from VCS repositories, execute build jobs and store build
results in a database. Cuirass also provides a web interface to monitor
the build results.

Cuirass is running on GNU Guix build farm[2].

• Download

  Here are the compressed sources and a GPG detached signature:
https://guix.gnu.org/cuirass/releases/cuirass-1.1.0.tar.gz
https://guix.gnu.org/cuirass/releases/cuirass-1.1.0.tar.gz.sig

  Here are the SHA1 checksums:

  90a4ddbbb255353a1a90807b5dcc4ec7ed7e  cuirass-1.1.0.tar.gz
  fe46ad674be0c3d1578d2c3950717f1dcf775e1f  cuirass-1.1.0.tar.gz.sig

• Changes since version 1.1.0 (excerpt from the NEWS file)

** Database
*** Add Jobs table
*** Add BuildDependencies table
*** Add Dashboards table

** Remote building
*** Add GC roots for the build outputs
*** Increase the fetch workers count to 8
*** Build derivations in a topological order using the BuildDependencies table
*** Resume dependent builds when a build is successful after a restart
*** Display the remote-server fetch queue size

** Specifications
*** Add period support
*** Add "images", "system-tests" and tarball build types

** Web
*** Add a footer with the Cuirass version
*** Add table order buttons
*** Add a pagination button on the evaluation page
*** Add a build dashboard page
*** Improve accessibility and add the Accessiblity Foundation report
*** Add badges support
*** Display build dependencies in the build details page
   
Please report bugs to bug-g...@gnu.org
Join guix-devel@gnu.org and #guix on Freenode for discussions.

Mathieu

[1]: https://nlnet.nl/
[2]: https://ci.guix.gnu.org


smime.p7s
Description: S/MIME cryptographic signature

Re: Cuirass badges

[Mathieu Othacehe]

Hey Ludo,

> This is not yet deployed in the current ‘cuirass’ package, right?

Yes it is :) For instance, to get the badge of the guix-hpc
specification at https://guix.bordeaux.inria.fr, you can use the
following URL: https://guix.bordeaux.inria.fr/jobset/guix-hpc/badge.svg.

There are some additional details in the Cuirass documentation.

Thanks,

Mathieu

Haskell update (was: Release 1.2.1: Cuirass failed to build Haskell 179 packages)

[Xinglu Chen]

On Tue, Mar 23 2021, zimoun wrote:

>> Maybe its time to update to a newer Stackage LTS release? :)
>
> Well, I do not know if it possible to do so before the next release.
> IMHO, let focus on what remains for the next release and let upgrade the
> Stackage LTS after.

Any updates on this?  I managed to build GHC 8.10.5 (on x86_64), but I
had to disable some tests.  I have attached the patch if anyone wants to
take a look.  :)

From 9ecfe7cb3f94b928dbd883d4b7e7c007278c0fa8 Mon Sep 17 00:00:00 2001
Message-Id: <9ecfe7cb3f94b928dbd883d4b7e7c007278c0fa8.1623177424.git.pub...@yoctocell.xyz>
From: Xinglu Chen 
Date: Tue, 18 May 2021 23:32:38 +0200
Subject: [RFC PATCH] gnu: Add ghc-8.10.

* gnu/packages/haskell.scm (ghc-8.10): New variable.
---
 gnu/packages/haskell.scm | 66 
 1 file changed, 66 insertions(+)

diff --git a/gnu/packages/haskell.scm b/gnu/packages/haskell.scm
index 09732fc594..8de3118136 100644
--- a/gnu/packages/haskell.scm
+++ b/gnu/packages/haskell.scm
@@ -657,6 +657,72 @@ interactive environment for the functional language Haskell.")
 (file-pattern ".*\\.conf\\.d$")
 (file-type 'directory))
 
+(define-public ghc-8.10
+  (package
+(inherit ghc-8.8)
+(name "ghc")
+(version "8.10.5")
+(source
+ (origin
+   (method url-fetch)
+   (uri (string-append "https://www.haskell.org/ghc/dist/;
+   version "/ghc-" version "-src.tar.xz"))
+   (sha256
+(base32 "0vq7wch0wfvy2b5dbi308lq5225vf691n95m19c9igagdvql22gi"
+(native-inputs
+ `(("ghc-bootstrap" ,ghc-8.6)
+   ("ghc-testsuite"
+,(origin
+   (method url-fetch)
+   (uri (string-append
+ "https://www.haskell.org/ghc/dist/;
+ version "/ghc-" version "-testsuite.tar.xz"))
+   (patches (search-patches "ghc-testsuite-dlopen-pie.patch"))
+   (sha256
+(base32
+ "0vcq774rfb6q8vsnh7p5clxp2qaz8ip6d2bm2ghbq53n8jl296d6"
+   ("git" ,git-minimal) ; invoked during tests
+   ,@(filter (match-lambda
+   (("ghc-bootstrap" . _) #f)
+   (("ghc-testsuite" . _) #f)
+   (_ #t))
+ (package-native-inputs ghc-8.6
+(arguments
+ (substitute-keyword-arguments (package-arguments ghc-8.6)
+   ((#:phases phases '%standard-phases)
+`(modify-phases ,phases
+   (add-after 'unpack-testsuite 'skip-more-tests
+ (lambda _
+   ;; XXX: This test fails because our ld-wrapper script
+   ;; mangles the response file passed to the linker.
+   (substitute* "testsuite/tests/hp2ps/all.T"
+ (("^test\\('T15904'") "# guix skipped: test('T15904'"))
+   ;; The following tests fail because they are unable to
+   ;; find a C compiler.
+   (substitute* "testsuite/tests/hsc2hs/all.T"
+ (("^test\\('" all)
+  (string-append "# guix skipped: " all)))
+   (substitute* "testsuite/tests/ffi/should_run/all.T"
+ (("^test\\('Capi_Ctype_00(1|2)'" all)
+  (string-append "# guix skipped: " all)))
+   (substitute* "testsuite/tests/ffi/should_run/all.T"
+ (("makefile_test, \\['Capi_Ctype_00(1|2)'\\].*" all)
+  (string-append "# guix skipped: " all)))
+   (substitute* "libraries/base/tests/IO/T12010/test.T"
+ (("^.*" all)
+  (string-append "# guix skipped: " all)))
+   ;; No idea why these are failing
+   (substitute* '("testsuite/tests/driver/T8602/T8602.T"
+  "testsuite/tests/driver/T16521/all.T")
+ (("^.*" all)
+  (string-append "# guix skipped: " all)
+(native-search-paths (list (search-path-specification
+(variable "GHC_PACKAGE_PATH")
+(files (list
+(string-append "lib/ghc-" version)))
+(file-pattern ".*\\.conf\\.d$")
+(file-type 'directory))
+
 (define-public ghc-8 ghc-8.6)
 
 (define-public ghc ghc-8)

base-commit: 503c2039a280dd52a751a6852b4157fccd1b4195
-- 
2.32.0



signature.asc
Description: PGP signature

Re: Cuirass badges

[Ludovic Courtès]

Hi!

Mathieu Othacehe  skribis:

> Cuirass is now able to generate badges like any respectable CI
> system. For instance:
>
> * https://ci.guix.gnu.org/jobset/master/badge generates a badge showing
>   the percentage of successful jobs for the master specification.

Fanciness.  :-)

This is not yet deployed in the current ‘cuirass’ package, right?

Thanks,
Ludo’.

Re: Cuirass badges

[Mathieu Othacehe]

Hey Luis,

> And the source file:
>
> https://luis-felipe.gitlab.io/media/2021/05/cuirass-badges-proposal-2021-05-28.svg
>
> I think I like d and d*.

Wooh, that's great! I updated Cuirass to use the d badge proposal.

Many thanks for your help,

Mathieu

Re: Cuirass badges

[Leo Famulari]

On Fri, May 28, 2021 at 07:24:50PM +, Luis Felipe wrote:
> Here's my initial proposal:
> 
> https://luis-felipe.gitlab.io/media/2021/05/cuirass-badges-proposal-2021-05-28.png

Wow!

> And the source file:
> 
> https://luis-felipe.gitlab.io/media/2021/05/cuirass-badges-proposal-2021-05-28.svg
> 
> I think I like d and d*.

Me too, and I prefer d over d*

Re: Cuirass badges

[Luis Felipe]

On Friday, May 28, 2021 4:49 PM, Luis Felipe  
wrote:

> On Friday, May 28, 2021 1:10 PM, Mathieu Othacehe othac...@gnu.org wrote:
>
> > Hello,
> > Cuirass is now able to generate badges like any respectable CI
> > system. For instance:
> >
> > -   https://ci.guix.gnu.org/jobset/master/badge generates a badge showing
> > the percentage of successful jobs for the master specification.
> >
> > -   https://ci.guix.gnu.org/jobset/guix/badge generates a badge showing
> > the percentage of successful jobs for the guix specification.
> > You can integrate those badges in your Git forge. There's a screenshot
> > of a Gitlab integration attached.
> > I think that the badge design1 could be significantly improved by
> > anyone with artistic abilities. It would also be nice if the badge could
> > display the specification name so that badges corresponding to multiple
> > specifications can be displayed together.
> > Thanks,
> > Mathieu
> >
>
> I'm giving this a try.

Here's my initial proposal:

https://luis-felipe.gitlab.io/media/2021/05/cuirass-badges-proposal-2021-05-28.png

And the source file:

https://luis-felipe.gitlab.io/media/2021/05/cuirass-badges-proposal-2021-05-28.svg

I think I like d and d*.

Re: Cuirass badges

[Luis Felipe]

On Friday, May 28, 2021 1:10 PM, Mathieu Othacehe  wrote:

> Hello,
>
> Cuirass is now able to generate badges like any respectable CI
> system. For instance:
>
> -   https://ci.guix.gnu.org/jobset/master/badge generates a badge showing
> the percentage of successful jobs for the master specification.
>
> -   https://ci.guix.gnu.org/jobset/guix/badge generates a badge showing
> the percentage of successful jobs for the guix specification.
>
> You can integrate those badges in your Git forge. There's a screenshot
> of a Gitlab integration attached.
>
> I think that the badge design[1] could be significantly improved by
> anyone with artistic abilities. It would also be nice if the badge could
> display the specification name so that badges corresponding to multiple
> specifications can be displayed together.
>
> Thanks,
>
> Mathieu
>
> [1]:
> 
> https://git.savannah.gnu.org/cgit/guix/guix-cuirass.git/tree/src/static/images/badge-per.svg
>

I'm giving this a try.

Cuirass badges

[Mathieu Othacehe]

Hello,

Cuirass is now able to generate badges like any respectable CI
system. For instance:

* https://ci.guix.gnu.org/jobset/master/badge generates a badge showing
  the percentage of successful jobs for the master specification.

* https://ci.guix.gnu.org/jobset/guix/badge generates a badge showing
  the percentage of successful jobs for the guix specification.

You can integrate those badges in your Git forge. There's a screenshot
of a Gitlab integration attached.

I think that the badge design[1] could be significantly improved by
anyone with artistic abilities. It would also be nice if the badge could
display the specification name so that badges corresponding to multiple
specifications can be displayed together.

Thanks,

Mathieu

[1]:
https://git.savannah.gnu.org/cgit/guix/guix-cuirass.git/tree/src/static/images/badge-per.svg

Re: Cuirass accessibility

[Ludovic Courtès]

Hi Mathieu,

Mathieu Othacehe  skribis:

> I have made the report public here[3]. Although I have already applied a
> bunch of accessibility related fixes, there's still some work left. The
> report if full of interesting teachings, and if some people want to join
> me, they are more than welcome :).

Nice!  (Direct link:
.)

It’s great that NLNet offers that.  I learned the phrase “hamburger
menu”, which makes a lot of sense!

Ludo’.

Re: Cuirass accessibility

[Luis Felipe]

On Thursday, May 13, 2021 7:07 PM, Mathieu Othacehe  wrote:

> Hello,
>
> As part of the Cuirass NLNet grant[1], the website at
> https://ci.guix.gnu.org has been audited by the Accessibility
> Foundation[2].

That's nice.


> I have made the report public here[3]. Although I have already applied a
> bunch of accessibility related fixes, there's still some work left. The
> report if full of interesting teachings, and if some people want to join
> me, they are more than welcome :).

Not offering to help right now, but just wanted to comment that I've audited a 
couple of websites before for accessibility using the WCAG-EM 1.0 (although I'm 
not an expert), and I've found that while website developers tend to improve 
accessibility based on the results, websites lose part of that accessibility 
again when their maintenance change hands or depend on new people that are not 
familiar with accessibility.

Personally, I also tend to forget some best practices with time...

Maybe, with Guix websites, READMEs could state clearly developers are aiming 
for Level AA conformance, and suggest contributors to check for common 
accessibility problems (and even HTML/CSS/FEED validity) when they make 
structural or style changes.

Cuirass accessibility

[Mathieu Othacehe]

Hello,

As part of the Cuirass NLNet grant[1], the website at
https://ci.guix.gnu.org has been audited by the Accessibility
Foundation[2].

I have made the report public here[3]. Although I have already applied a
bunch of accessibility related fixes, there's still some work left. The
report if full of interesting teachings, and if some people want to join
me, they are more than welcome :).

Thanks,

Mathieu

[1]: https://othacehe.org/gnu-guix-continuous-integration---nlnet-grant.html
[2]: https://www.accessibility.nl/en/english
[3]: 
https://git.savannah.gnu.org/cgit/guix/guix-cuirass.git/commit/?id=a9925ec3b5c3be1ee1fe16d9fd51225a8be32a1d

Re: Cuirass 1.0 released

[Leo Famulari]

On Thu, Apr 01, 2021 at 10:23:07AM +0200, Mathieu Othacehe wrote:
> We are pleased to announce the release of Cuirass 1.0.

Awesome! Your hard work is making a big difference for Guix :)

> This is the first official release of Cuirass, the GNU Guix continuous
> integration software. Since January, this project is funded through the
> NGI0 PET Fund, a fund established by NLNet[1]. Thanks to this support,
> we were able to speed up the developments and finally propose this
> release.

Thank you to NLnet for their support!

Re: Cuirass 1.0 released

[Ludovic Courtès]

Hi Mathieu,

Mathieu Othacehe  skribis:

> We are pleased to announce the release of Cuirass 1.0.
>
> This is the first official release of Cuirass, the GNU Guix continuous
> integration software. Since January, this project is funded through the
> NGI0 PET Fund, a fund established by NLNet[1]. Thanks to this support,
> we were able to speed up the developments and finally propose this
> release.
>
> Read more about today’s announcement at:
>
>   https://gnu.org/software/guix/blog/2021/cuirass-10-released/

Woohoo, thumbs up!  

It’s crazy how much you’ve achieved since January, when we were still
looking at all these build machines sitting desperately idle.  Really
happy that you were able to fix this situation and more in so little time!

Ludo’.

Cuirass 1.0 released

[Mathieu Othacehe]

We are pleased to announce the release of Cuirass 1.0.

This is the first official release of Cuirass, the GNU Guix continuous
integration software. Since January, this project is funded through the
NGI0 PET Fund, a fund established by NLNet[1]. Thanks to this support,
we were able to speed up the developments and finally propose this
release.

Read more about today’s announcement at:

  https://gnu.org/software/guix/blog/2021/cuirass-10-released/

• About

Cuirass is the GNU Guix continuous integration software. It's a general
purpose build automation server written in GNU Guile that checks out
sources from VCS repositories, execute build jobs and store build
results in a database. Cuirass also provides a web interface to monitor
the build results.

Cuirass is running on GNU Guix build farm[2].

• Download

  Here are the compressed sources and a GPG detached signature:
https://guix.gnu.org/cuirass/releases/cuirass-1.0.0.tar.gz
https://guix.gnu.org/cuirass/releases/cuirass-1.0.0.tar.gz.sig

  Here are the SHA1 checksums:

  90a4ddbbb255353a1a90807b5dcc4ec7ed7e  cuirass-1.0.0.tar.gz
  fe46ad674be0c3d1578d2c3950717f1dcf775e1f  cuirass-1.0.0.tar.gz.sig

• Changes since version 0.0.1 (excerpt from the NEWS file)

  ** Database
  *** Switch from SQLite to PostgreSQL
  *** New test cases covering most of the SQL queries
  ** Notifications
  *** New notification mechanism with Email and Mastodon backends
  *** Add RSS events support
  
  ** Remote building
  *** Add a remote building mechanism
  *** Add a live build log mechanism
  *** Honor timeout and max-silent-time package properties
  *** Add specification and package priorities support
  *** Add Workers monitoring support with Zabbix
  ** Evaluation
  *** Rewrite evaluation mechanism to rely on Guix inferiors.
  *** Change the specifications format from an association list to a record.
  *** Use Guix Channels instead of custom Inputs.
  ** Web
  *** Add a Workers status page to monitor the remote workers status
  *** Add actions
  - Add a specification
  - Edit a specification
  - Delete a specification
  - Cancel an evaluation pending builds
  - Retry all build of an evaluation
  - Retry an evaluation
  - Restart a build
  *** Improve the specification display
  *** Fix pagination
  *** Add build weather support
  *** Add build history support

Please report bugs to bug-g...@gnu.org
Join guix-devel@gnu.org and #guix on Freenode for discussions.

Thanks to everyone who contributed to this release:

19  Christopher Baines
22  Clément Lassieur
10  Danny Milosavljevic
 8  Jan Nieuwenhuizen
 1  Jonathan Brielmaier
 1  Leo Famulari
   177  Ludovic Courtès
   143  Mathieu Lirzin
   296  Mathieu Othacehe
36  Ricardo Wurmus
 1  Robert Vollmert
 1  Roel Janssen
 6  TSholokhova
 1  Tobias Geerinckx-Rice
 1  Vincent Legoll

Mathieu

[1]: https://nlnet.nl/
[2]: https://ci.guix.gnu.org


smime.p7s
Description: S/MIME cryptographic signature

Re: Cuirass not processing core-updates (or weirdly)

[Vincent Legoll]

Maybe we can have both: a core-updates:'core with
a sufficient priority so that it is built often enough,
and then a core-updates:'all with the lowest priority
(batch) so that it does not steal any processing power
from the other more important stuff...

-- 
Vincent Legoll

Re: Cuirass not processing core-updates (or weirdly)

[Léo Le Bouter]

On Sat, 2021-03-27 at 04:24 +0100, Léo Le Bouter wrote:
> Hello!
> 
> If you look at https://ci.guix.gnu.org/eval/13652 you can see that
> the
> evaluation of the derivation seems completed but there's no pending
> builds.
> 
> What is happening here?
> 
> Thank you

I think it may be because core-updates is setup to only build 'core and
not 'all.


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

Re: Cuirass not processing core-updates (or weirdly)

[Mathieu Othacehe]

Hello Leo,

> If you look at https://ci.guix.gnu.org/eval/13652 you can see that the
> evaluation of the derivation seems completed but there's no pending
> builds.

If you have a look to
https://ci.guix.gnu.org/specification/edit/core-updates you will see
that this specification is configured to build to "core"[1] subset of
the "core-updates" branch with the "4" priority.

The 13652 evaluation does not trigger any new derivation in the core
packages subset, hence there are no triggered builds.

When there are some new derivations to build, like for the 12656
evaluation, because of the low priority, they can stay pending for a
long time.

Thanks,

Mathieu

[1]: 
http://guix.gnu.org/cuirass/manual/html_node/Specifications.html#Specifications

Cuirass not processing core-updates (or weirdly)

[Léo Le Bouter]

Hello!

If you look at https://ci.guix.gnu.org/eval/13652 you can see that the
evaluation of the derivation seems completed but there's no pending
builds.

What is happening here?

Thank you


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

Re: cuirass

[Mathieu Othacehe]

Hello,

> * The "Home" & "Guix logo" buttons bothlink back to the home page (duplicate).

Yes, but I'm not sure what to do about that. Maybe remove the logo link.

>
> * The search combobox help popup window
> is not on top level, probably on all pages.
> So other page elements are displayed over
> it.

I applied your patch, thanks!

> * Overdirve1 does not have infos (missing
> zabbix)

Yes, that's on purpose, the Overdrive resources are limited, and running
Zabbix and its PostgreSQL database wouldn't help.

> I have collected a buch of ideas for additions.
>
> Should I create bugs for those or just the
> above list will suffice ?

We can discuss them here I think. Don't hesitate if you have other
improvements ideas.

Thanks,

Mathieu

Re: cuirass

[Vincent Legoll]

> The rule for “#search #search-hints” should have a “z-index: 1;” or
> similar, so that the icons don’t overlap the search box.

Like the following ?

diff --git a/src/static/css/cuirass.css b/src/static/css/cuirass.css
index e713b6f..2754415 100644
--- a/src/static/css/cuirass.css
+++ b/src/static/css/cuirass.css
@@ -4,6 +4,7 @@
 #search #search-hints {
 display: none;
 position: absolute;
+z-index: 1;
 top: 3em;
 background: white;
 border: 1px solid #ced4da;

-- 
Vincent Legoll

Re: cuirass

[Ricardo Wurmus]

Vincent Legoll  writes:

> * The search combobox help popup window
> is not on top level, probably on all pages.
> So other page elements are displayed over
> it.

I noticed that too.

The rule for “#search #search-hints” should have a “z-index: 1;” or
similar, so that the icons don’t overlap the search box.

-- 
Ricardo

cuirass

[Vincent Legoll]

Hello,

I just made a tour of the new cuirass, this is
much nicer than when I last visited (a long
time ago). Kudos !

I saw a few glitches (with firefox 78.8.0esr)

* The "Home" & "Guix logo" buttons bothlink back to the home page (duplicate).

* The search combobox help popup window
is not on top level, probably on all pages.
So other page elements are displayed over
it.

* Overdirve1 does not have infos (missing
zabbix)

I have collected a buch of ideas for additions.

Should I create bugs for those or just the
above list will suffice ?

Thanks a lot for the improvements !

PS: Sorry for ENOPATCH but I'm not good at
web.

-- 
Vincent Legoll

Re: Release 1.2.1: Cuirass failed to build Haskell 179 packages

[Xinglu Chen]

On Tue, Mar 23 2021, zimoun wrote:

> Hi,
>
> On Tue, 23 Mar 2021 at 11:32, Xinglu Chen  wrote:
>
>>> And if someone is in the mood to check why ghc-haddock is broken. :-)
>>
>> This was an issue with upstream[1], it has since been fixed but the
>> releases that include the fix are only built for GHC 8.8 or later.
>
> Thanks!  Much appreciated.

You are welcome!

>> Maybe its time to update to a newer Stackage LTS release? :)
>
> Well, I do not know if it possible to do so before the next release.
> IMHO, let focus on what remains for the next release and let upgrade the
> Stackage LTS after.

Ok, sounds good to me.

Re: Release 1.2.1: Cuirass failed to build Haskell 179 packages

[zimoun]

Hi,

On Tue, 23 Mar 2021 at 11:32, Xinglu Chen  wrote:

>> And if someone is in the mood to check why ghc-haddock is broken. :-)
>
> This was an issue with upstream[1], it has since been fixed but the
> releases that include the fix are only built for GHC 8.8 or later.

Thanks!  Much appreciated.


> Maybe its time to update to a newer Stackage LTS release? :)

Well, I do not know if it possible to do so before the next release.
IMHO, let focus on what remains for the next release and let upgrade the
Stackage LTS after.

Cheers,
simon

Re: Release 1.2.1: Cuirass failed to build Haskell 179 packages

[Xinglu Chen]

On Wed, Mar 10 2021, zimoun wrote:

> Using the command “guix weather --display-missing” at commit 6bed29b, I
> identify 180 packages ghc-* which are missing.  Then I locally rebuild
> all of them and they build successfully.  The only one broken is:
>
>   ghc-haddock
>
> Therefore, is it possible to “restart” the build on Cuirass of these 179
> ghc-* packages?  It could be nice to have substitutes for the next
> release.
>
> And if someone is in the mood to check why ghc-haddock is broken. :-)

This was an issue with upstream[1], it has since been fixed but the
releases that include the fix are only built for GHC 8.8 or later.

Maybe its time to update to a newer Stackage LTS release? :)

[1]: https://github.com/haskell/haddock/issues/850

Re: Release 1.2.1: Cuirass failed to build Haskell 179 packages

[zimoun]

Hi Tobias,

On Thu, 11 Mar 2021 at 00:37, Tobias Geerinckx-Rice  wrote:

>> Attached, the list of the 180 ghc-* packages.
>
> I've started the builds on berlin except haddock.  Not restarted: 
> none of these had failed. Judging by how quickly it finished I 
> think most of them had already been built, but I didn't pay enough 
> attention to be certain.

Thanks!

I do not know from where the issue was.  Now “guix weather
--display-missing” lists the GHC packages:

  ghcid-0.8.7
  ghc-prettyprinter-1.2.1.1
  ghc-repline-0.2.0.0
  ghc-haddock-2.22.0
  ghc-generic-random-1.2.0.0

  ghcid-0.8.7-static
  ghc-prettyprinter-1.2.1.1-static
  ghc-repline-0.2.0.0-static
  ghc-haddock-2.22.0-static
  ghc-generic-random-1.2.0.0-static
  ghc-atomic-write-0.2.0.6-static

which is acceptable for a release, IMHO.


Cheers,
simon

Re: Release 1.2.1: Cuirass failed to build Haskell 179 packages

[Tobias Geerinckx-Rice]

zimoun 写道：

Therefore, is it possible to “restart” the build on Cuirass


I used ‘guix build’, not Cuirass (AIUI its CLI is still ‘poke the 
SQL database with a stick’?).


Kind regards,

T G-R


signature.asc
Description: PGP signature