Re: Following Guix weather.
On Fri, 09 Apr 2021 15:53:49 +0200 Mathieu Othacehe wrote: > Hello, > > I have deployed a bunch of changes at https://ci.guix.gnu.org/. I'd > like to introduce some of them here. > > First, there are some new specifications: "images", "tarball" and > "tests". Those specifications are configured to build respectively, > the %guix-system-images declared in (gnu ci), the Guix binary tarball > and the Guix System tests. > > Each Guix commit potentially triggers a rebuilt of all those > specifications. We have previously established that this is too > resource consuming. > > That's why I have added a "period" field to the specification > definition. This field only allows a new evaluation when at least X > seconds have elapsed since the last evaluation. Right now, the three > aforementioned specifications have a period field set to 86400 seconds > (24 hours). > > I have also improved the visibility of latest state of a > specification. For instance, if you want to know what's the current > status of the "master" branch or the "staging" branch, you will find > some statistics directly on the home page. For a more detailed view, > you can consult dashboards for each specification. > > master dashboard: https://ci.guix.gnu.org/eval/19534/dashboard > staging dashboard: https://ci.guix.gnu.org/eval/19488/dashboard > test dashboard: https://ci.guix.gnu.org/eval/19464/dashboard > > By having a look at those dashboards, it's obvious that we still have > a lot of work before all those circles turn to green. > > Finally, in the evaluation view there's a "Toggle" button to switch > between: > > - The number of newly fixed/broken/pending builds for each evaluation > (default) > - The total number of fixed/broken/pending builds for each evaluation. > > Don't hesitate to comment on those new features :) > > Thanks, > > Mathieu > > Speaking of visibility, please don't use color as the sole carrier of information. I don't know if you did any accessibility testing for that page, but not requiring perfect color vision should be step 0. Luckily it should be an easy fix, just use some shapes.
Add a way to disable serialization support to (guix services configuration)
Hello Guix! I've rediscovered the little gem that is (guix services configurations), and attempted to make it more generally useful by adding an option to opt out of serialization (which is not well adapted for producing a list of command line arguments from the configuration for example): --8<---cut here---start->8--- 1 file changed, 10 insertions(+), 1 deletion(-) gnu/services/configuration.scm | 11 ++- modified gnu/services/configuration.scm @@ -38,6 +38,9 @@ configuration-field-getter configuration-field-default-value-thunk configuration-field-documentation + +%with-serialization? + serialize-configuration define-maybe define-configuration @@ -51,6 +54,11 @@ ;;; ;;; Code: +;;; XXX: This doesn't actually work as a parameter with macros such as +;;; define-configuration; it is to be used as a plain global variable. +;;; Experiments with define-syntax-parameter did not work either. +(define %with-serialization? (make-parameter #true)) + (define-condition-type configuration-error?) @@ -123,7 +131,8 @@ #'(field-type ...))) ((field-serializer ...) (map (lambda (type) - (id #'stem #'serialize- type)) + (and (%with-serialization?) + (id #'stem #'serialize- type))) #'(field-type ... #`(begin (define-record-type* #,(id #'stem #'< #'stem #'>) --8<---cut here---end--->8--- Unfortunately, it doesn't work, at least when using it from 'guix system'. I've also tried a version relying on syntax-parameter instead of a parameter, with the same result. Would someone know how it could be made to work? Thanks, Maxim
Re: Please review blog post draft: powerpc64le-linux support
Hi, Chris Marusich writes: > This is the final draft, I think. I intend to commit it to the "posts" > directory in guix-artwork on Monday morning, USA time, at which point I > believe it will automatically show up on the blog. I have published it in commit 0129dd529347bfefee96644ac9fbabc29adbe772. Thank you again to everyone for your help! -- Chris signature.asc Description: PGP signature
Re: Guix Data Service - Outreachy: questions about render-compare/derivation
Luciana Lima Brito writes: > I'm lubrito on Guix IRC, the Outreachy applicant. > > I'm working on the json output for the render-compare/derivation > procedure (controller.scm). Hi lubrito, Good to hear from you. > I would like to know if I am on the right path with what I've > accomplished until now. You've got some JSON being rendered, so you're definitely on the right path :) > The attached .ppm file shows the json I have so far. The json is > showing only the data for the "outputs", but I already got the data for > the rest and I could do the same to them. I am still thinking about how > to make the code cleaner, because the way I'm doing could produce many > redundancies. > > I also would like to know if the general structure of the json is > correct or if it should be different. For example, under "outputs" "0" > is denoting base and "1" is denoting target. > > The current code for the function is here http://sprunge.us/mKkzX2 So, there's no "correct" structure for the JSON, but some structures might better represent the data than others, there's a number of factors to balance. I think an object with base and target names would easier to understand than using an array. Some of the types in the JSON are a bit off as well, part of this is the query processing is not working quite right, but that's a different issue. For the JSON you've got so far, I'd specifically look at the hash, hash-algorithm and recursive fields. hash and hash-algorithm are only set for some outputs (only for fixed output derivations), it would probably be better to have these fields set to null if they don't have a string value, or not included in the object. For recursive, that's a boolean, so it should be a boolean in the JSON too. Hope that helps! Chris signature.asc Description: PGP signature
String freeze
Hi Guix! This message is a remainder that, according to our release schedule we are now entering string freeze. Please refrain from pushing any change that affects strings in the manual or guix itself. This is to give enough time to translators so they can update and finish the translation. Synopsis and descriptions (i.e. packages) can still be modified. Since I haven't yet pushed the latest strings to weblate, I am leaving you until 22:00 UTC (that's midnight French time or 6pm EDT (New York)) to push your last string changes! Thank you!
Re: Test failures on new build
On Sun, 2021-04-11 at 21:29 -0500, Stephen Paul Weber wrote: > [...], but I get these failures: > > FAIL: tests/guix-git-authenticate.sh Could you attach tests/guix-git-authenticate.log? > PASS: tests/workers.scm > make[4]: *** [Makefile:5605: tests/derivations.log] Error 1 Likewise. > make[4]: *** Waiting for unfinished jobs > FAIL: tests/build-utils.scm Likewise. > make[4]: *** [Makefile:5605: tests/grafts.log] Error 1 Likewise. Greetings, Maxime. signature.asc Description: This is a digitally signed message part
Test failures on new build
Trying to get an environment for hacking on Guix going on my new computer. Installed guix on my Debian stable using guix-install.sh then ran guix pull. Did a fresh git clone on guix then guix environment guix --pure ./bootstrap ./configure --localstatedir=/var make -j24 make -j24 check mostly works, but I get these failures: FAIL: tests/guix-git-authenticate.sh PASS: tests/workers.scm make[4]: *** [Makefile:5605: tests/derivations.log] Error 1 make[4]: *** Waiting for unfinished jobs FAIL: tests/build-utils.scm make[4]: *** [Makefile:5605: tests/grafts.log] Error 1 any thoughts? signature.asc Description: PGP signature
