date:20230317

Am Freitag, dem 17.03.2023 um 20:40 +0100 schrieb Andreas Enge:
> packagekit fails its installation phase (!) like so:
> /gnu/store/xrn2zn2ky4jkigg2cal0g8sacpkfai9m-meson-0.63.2/bin/meson
> install --no-rebuild
> ninja: build stopped: subcommand failed.
> error: in phase 'install': uncaught exception:
> %exception #<&invoke-error program: "ninja" arguments: ("install")
> exit-status: 1 term-signal: #f stop-signal: #f>
> phase `install' failed after 0.3 seconds
> command "ninja" "install" failed with status 1
> builder for `/gnu/store/4yvabkw23pwmxcanvl1qn8ch9jak7py4-packagekit-
> 1.2.5.drv' failed with exit code 1
> build of /gnu/store/4yvabkw23pwmxcanvl1qn8ch9jak7py4-packagekit-
> 1.2.5.drv failed
> View build log at
> '/var/log/guix/drvs/4y/vabkw23pwmxcanvl1qn8ch9jak7py4-packagekit-
> 1.2.5.drv.gz'.
This error is caused by trying to install
'/gnu/store/mxp199mvjb6dhyyg0pi4hn6c7m0xibvp-bash-completion-
2.11/share/bash-completion/completions/pkcon'.  Meson appears to have a
feature where it tries to use pkexec to gain elevated privileges. 
However, since that pkexec is actually the one pulled in for the build
system, that won't work here.

In any case, the attached patch fixes the more pressing issue of
getting the installation directory wrong.

Cheers
From b7c1a259815e97beeb9f60b8991fde87c31abf64 Mon Sep 17 00:00:00 2001
From: Liliana Marie Prikler 
Date: Fri, 17 Mar 2023 23:57:22 +0100
Subject: [PATCH] gnu: packagekit: Fix installation directory for bash
 completions.
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Without this patch, packagekit would attempt to install bash completions
to another store directory, invoking pkexec in the process and raising
a cryptic error.

* gnu/packages/freedesktop.scm (packagekit)[#:phases]: Add
‘fix-bash-completion-dir’.
---
 gnu/packages/freedesktop.scm | 10 +-
 1 file changed, 9 insertions(+), 1 deletion(-)

diff --git a/gnu/packages/freedesktop.scm b/gnu/packages/freedesktop.scm
index 9ba53cd044..9256dac0e0 100644
--- a/gnu/packages/freedesktop.scm
+++ b/gnu/packages/freedesktop.scm
@@ -1006,7 +1006,15 @@ (define-public packagekit
 (build-system meson-build-system)
 (arguments
  (list #:tests? #f
-   #:configure-flags #~'("-Dsystemd=false" "-Doffline_update=false")))
+   #:configure-flags #~'("-Dsystemd=false" "-Doffline_update=false")
+   #:phases
+   #~(modify-phases %standard-phases
+   (add-after 'unpack 'fix-bash-completion-dir
+ (lambda _
+   (substitute* "contrib/meson.build"
+ (("bash_.*_dep\\.get_.*\\('completionsdir', .*\\)")
+  "join_paths(get_option('prefix'), 'share',
+  'bash-completion', 'completions')")))
 (native-inputs
  (list bash-completion
docbook-xsl
-- 
2.39.2

March update on bordeaux.guix.gnu.org

2023-03-17 Thread Christopher Baines

Hey!

The last update was sent out back in January [1], while things are
stable there has been some activity in the last couple of months.

1: https://lists.gnu.org/archive/html/guix-devel/2023-01/msg00199.html

## Numbers

bordeaux.guix.gnu.org currently provides ~2.2 million nars, which take
up ~9.2TiB to store.

Substitute availability is still reasonable, although recent
availability for i686-linux has been lower than it has been previously.

## Mirrors

Still no progress has happened in terms of mirrors. This would still be
nice to get setup, but it's probably not the priority in terms of
administration and infrastructure.

## Serving fixed output files by hash

bordeaux.guix.gnu.org is now in the list of content addressed mirrors
[2].

2:
https://git.savannah.gnu.org/cgit/guix.git/commit/?id=7d0ebe040d80adcf143656e754a82b569243568c

In addition to the above change, some fixed output derivations use
download-nar rather than content addressed mirrors, so I've now updated
that to also fetch from bordeaux.guix.gnu.org [3].

3:
https://git.savannah.gnu.org/cgit/guix.git/commit/?id=b59f89cf18fbad9ee95521c4cadc6642c580feb8

## Referential integrity

This is usually something I think about in the context of databases, but
nars/narinfos have references, and I've been working to ensure that for
any nar provided by bordeaux.guix.gnu.org, you're also able to fetch any
nar it references.

I noticed something was lacking here a while ago when I went to
substitute an output for guix pull, but guix wasn't able to since some
referenced outputs weren't available. These missing outputs turned out
to be files that guix inserts in to the store to use as sources in the
derivations computed by guix pull. The build coordinator now knows about
this and will publish these as nars by default [4]. This was never an
issue when actually using guix pull, since it would compute the
derivations and create the missing outputs locally, so they aren't
usually substituted. To backfill the missing items, I wrote a script to
fetch the nars from data.guix.gnu.org, since it has them as part of
providing substitutes for the derivations.

4:
https://git.savannah.gnu.org/cgit/guix/build-coordinator.git/commit/?id=751910162c54d0bf85fa5a21c25ad229cb12828d

There's still a bit more work to do in terms of ensuring outputs aren't
missing when nars are inserted and removed, but this is nearly there.

## Offering zstd compressed nars

bordeaux.guix.gnu.org uses lzip to compress the nars, which is good
choice in terms of minimising the storage requirements and size of
downloads. It's been known for a while though that this might not suit
all users, as those with fast network connections may benefit from nars
that can be decompressed much quicker even if there's more bytes to
download.

5: https://guix.gnu.org/en/blog/2021/getting-bytes-to-disk-more-quickly/

To enable providing zstd compressed nars, without having to store every
nar as an lzip compressed file and zstd compressed file, the nar-herder
now supports generating cached nars with different compressions.

The nar-herder running on bayfront (which serves bordeaux.guix.gnu.org)
is now configured to generate and cache zstd nars [6]. Currently there
are ~25,000 cached nars taking up about 86GiB of space.

6:
https://git.savannah.gnu.org/cgit/guix/maintenance.git/commit/?id=c4778aa2689e0e73e77cadb71a04dc2dfee4ea27

## Next steps

Last time I said that I thought the main blocking issue in making
bordeaux.guix.gnu.org the default substitute server to try first was the
lack of zstd nars. Some nars are now available with zstd compression, so
there's progress been made on this at least. I think a good argument can
be made for trying bordeaux.guix.gnu.org being better for users than
trying ci.guix.gnu.org first, but it's not clear cut.

On the issue of expanding the storage for nars, I've submitted the
request to purchase an additional hard drive for hatysa to expand the
storage there. There is still a need to come up with a plan to replace
bishan when it runs out of space (ideally before!).

Now that bordeaux.guix.gnu.org is building things for the master branch,
plus qa.guix.gnu.org is submitting lots of builds for patches and
branches, there's more going on at varying priorities. This is really
good, but there's a greater need now to expose what's being built and
what the backlog looks like.

If you're interested in working on any of this, do let me know as while
I don't have time to work on much of it myself, I should be able to make
time to help others.

Let me know if you have any comments or questions!

Thanks,

Chris

signature.asc
Description: PGP signature

Re: Gnome dans core-updates

Am Freitag, dem 17.03.2023 um 21:46 +0100 schrieb Liliana Marie
Prikler:
> Also, the package definitions appear the same on master, so
> there is possibly something else going on (but what?)
Now that's quite embarrassing, but git worktree put my core-updates to
master...

Re: Gnome dans core-updates

2023-03-17 Thread Development of GNU Guix and the GNU System distribution.

Am Freitag, dem 17.03.2023 um 20:40 +0100 schrieb Andreas Enge:
> libcacard fails validate-runpath:
> starting phase `validate-runpath'
> validating RUNPATH of 1 binaries in
> "/gnu/store/29kdbd1q8lkyyr7apzczx53683mr0yhz-libcacard-2.8.1/lib"...
> /gnu/store/29kdbd1q8lkyyr7apzczx53683mr0yhz-libcacard-
> 2.8.1/lib/libcacard.so: error: depends on 'libnss3.so', which cannot
> be found in RUNPATH ("/gnu/store/gsjczqir1wbz8p770zndrpw4rnppmxi3-
> glibc-2.35/lib" "/gnu/store/mw4l4bap7xw3s4v9j4v395qp2n4gz3x4-glib-
> 2.72.3/lib" "/gnu/store/jxkn98nnk2pv3fy7cx2baaynkr4c63wp-nspr-
> 4.35/lib" "/gnu/store/x22qi9rkzdb8pafcv78wb5nayph9m1d9-pcsc-lite-
> 1.9.8/lib")
> error: in phase 'validate-runpath': uncaught exception:
> misc-error #f "RUNPATH validation failed" () #f
> phase `validate-runpath' failed after 0.0 seconds
> Backtrace:
>8 (primitive-load
> "/gnu/store/x2685x6mv5lcxf2l7idg1y5w7wb…")
> In guix/build/gnu-build-system.scm:
> 908:2  7 (gnu-build #:source _ #:outputs _ #:inputs _ #:phases .
> #)
> In ice-9/boot-9.scm:
>   1752:10  6 (with-exception-handler _ _ #:unwind? _ # _)
> In srfi/srfi-1.scm:
> 634:9  5 (for-each #
> …)
> In ice-9/boot-9.scm:
>   1752:10  4 (with-exception-handler _ _ #:unwind? _ # _)
> In guix/build/gnu-build-system.scm:
>929:23  3 (_)
>570:10  2 (validate-runpath #:validate-runpath? _ # _ #:outputs _)
> In ice-9/boot-9.scm:
>   1685:16  1 (raise-exception _ #:continuable? _)
>   1685:16  0 (raise-exception _ #:continuable? _)
> ice-9/boot-9.scm:1685:16: In procedure raise-exception:
> RUNPATH validation failed
> builder for `/gnu/store/sv800qqkvz6l2y54rp4jfrbqva8zhr52-libcacard-
> 2.8.1.drv' failed with exit code 1
> build of /gnu/store/sv800qqkvz6l2y54rp4jfrbqva8zhr52-libcacard-
> 2.8.1.drv failed
> View build log at
> '/var/log/guix/drvs/sv/800qqkvz6l2y54rp4jfrbqva8zhr52-libcacard-
> 2.8.1.drv.gz'.
> We have
> (propagated-inputs
>  (list ...
>nss
> and
> (native-inputs
>  (list ...
>`(,nss "bin")
> It looks like we need some of nss (the "normal" output, not "bin") as
> a standard input. I will give it a try.

> 
That doesn't change a thing when nss is already a propagated input:
Propagated inputs are also "standard" ones as far as linking is
concerned.  Also, the package definitions appear the same on master, so
there is possibly something else going on (but what?)

On a rather unrelated note, the uri
https://gitlab.freedesktop.org/spice/libcacard/uploads/13b249e695a0d9aa7cb501b1a85ebab1/libcacard-2.8.1.tar.xz
looks rather sus.  Should we perhaps replace that with a git-reference?

Re: State of core-updates

2023-03-17 Thread Kaelyn

Hi Felix and Andreas,

--- Original Message ---
On Friday, March 17th, 2023 at 8:27 PM, Felix Lechner 
 wrote:


> 
> 
> Hi Andreas and Kaelyn,
> 
> On Fri, Mar 17, 2023 at 1:18 PM Kaelyn kaelyn.al...@protonmail.com wrote:
> 
> > sorry about "git am" not working
> 
> 
> I hesitate to get in the middle, but it may be appropriate for
> attribution reasons to revert commit cc56be2f and then re-commit with
> the '--author' option, unless rebasing and breaking history is
> acceptable. [1]

I'm at least a little in favor of that, as the commit message for 
cc56be2f3858487cf1d8acfb345942f0784221ee is mis-formatted (it doesn't have the 
first 'gnu: ' prefixed summary line, and so git log --oneline doesn't format it 
right). I just quickly formatted and sent a v2 patch using "git format-patch 
--attach" and "git send-email" to try to get something at 
https://issues.guix.gnu.org/62209 that will work properly with "git am". (I'm 
still puzzled at what happened with the first one, as downloading the whole 
message and applying it with "git am" also fails for me.)

Cheers,
Kaelyn

> 
> Kind regards
> Felix
> 
> [1] https://stackoverflow.com/a/28845565

Re: State of core-updates

Hi Andreas and Kaelyn,

On Fri, Mar 17, 2023 at 1:18 PM Kaelyn  wrote:
>
> sorry about "git am" not working

I hesitate to get in the middle, but it may be appropriate for
attribution reasons to revert commit cc56be2f and then re-commit with
the '--author' option, unless rebasing and breaking history is
acceptable. [1]

Kind regards
Felix

[1] https://stackoverflow.com/a/28845565

Re: State of core-updates

2023-03-17 Thread Kaelyn

--- Original Message ---
On Friday, March 17th, 2023 at 8:01 PM, Andreas Enge  wrote:
 
> 
> Am Wed, Mar 15, 2023 at 05:59:12PM + schrieb Kaelyn:
> 
> > 1) glib-networking has a 32-bit-only patch left over from the upgrade from 
> > 2.70.0 to 2.72.2, which does not apply against the newer version, and which 
> > seems unneeded. I just sent in https://issues.guix.gnu.org/62209 to fix the 
> > package.
> 
> 
> Splendid, thanks a lot! I did not manage to extract a git commit that I
> could apply with "git am" out of your message, so I ended up pushing it
> under my name while adding yours as a comment in the git log.
> 
> The package builds under x86_64 and i686, I did not test the arm
> architectures. We will see what happens.
> 
> Thanks a lot!

You're welcome! I'm happy to help. :) And sorry about "git am" not working, 
though I'm not sure why. I sent the email with "git send-email 
--to=guix-patc...@gnu.org --subject-prefix="PATCH core-updates" HEAD^" as I've 
done with other patches (I also have format.useAutoBase set to whenAble in my 
.gitconfig).

Cheers,
Kaelyn

> 
> Andreas

Re: State of core-updates

Am Wed, Mar 15, 2023 at 05:59:12PM + schrieb Kaelyn:
> 1) glib-networking has a 32-bit-only patch left over from the upgrade from 
> 2.70.0 to 2.72.2, which does not apply against the newer version, and which 
> seems unneeded. I just sent in https://issues.guix.gnu.org/62209 to fix the 
> package.

Splendid, thanks a lot! I did not manage to extract a git commit that I
could apply with "git am" out of your message, so I ended up pushing it
under my name while adding yours as a comment in the git log.

The package builds under x86_64 and i686, I did not test the arm
architectures. We will see what happens.

Thanks a lot!

Andreas

Re: Gnome dans core-updates

Am Fri, Mar 17, 2023 at 08:40:00PM +0100 schrieb Andreas Enge:
> libcacard fails validate-runpath:
> It looks like we need some of nss (the "normal" output, not "bin") as a

This did not help, nss appears in no runpath; this is what is printed:
starting phase `shrink-runpath'
/gnu/store/clqhrdvg1jpf053dq281f86139v5afxz-libcacard-2.8.1/lib/libcacard.so: 
stripping RUNPATH to 
("/gnu/store/gsjczqir1wbz8p770zndrpw4rnppmxi3-glibc-2.35/lib" 
"/gnu/store/mw4l4bap7xw3s4v9j4v395qp2n4gz3x4-glib-2.72.3/lib" 
"/gnu/store/jxkn98nnk2pv3fy7cx2baaynkr4c63wp-nspr-4.35/lib" 
"/gnu/store/x22qi9rkzdb8pafcv78wb5nayph9m1d9-pcsc-lite-1.9.8/lib") (removed 
("/gnu/store/clqhrdvg1jpf053dq281f86139v5afxz-libcacard-2.8.1/lib" 
"/gnu/store/930nwsiysdvy2x5zv1sf6v7ym75z8ayk-gcc-11.3.0-lib/lib" 
"/gnu/store/930nwsiysdvy2x5zv1sf6v7ym75z8ayk-gcc-11.3.0-lib/lib/gcc/x86_64-unknown-linux-gnu/11.3.0/../../.."))
phase `shrink-runpath' succeeded after 0.0 seconds
starting phase `validate-runpath'
validating RUNPATH of 1 binaries in 
"/gnu/store/clqhrdvg1jpf053dq281f86139v5afxz-libcacard-2.8.1/lib"...
/gnu/store/clqhrdvg1jpf053dq281f86139v5afxz-libcacard-2.8.1/lib/libcacard.so: 
error: depends on 'libnss3.so', which cannot be found in RUNPATH 
("/gnu/store/gsjczqir1wbz8p770zndrpw4rnppmxi3-glibc-2.35/lib" 
"/gnu/store/mw4l4bap7xw3s4v9j4v395qp2n4gz3x4-glib-2.72.3/lib" 
"/gnu/store/jxkn98nnk2pv3fy7cx2baaynkr4c63wp-nspr-4.35/lib" 
"/gnu/store/x22qi9rkzdb8pafcv78wb5nayph9m1d9-pcsc-lite-1.9.8/lib")

Some special behaviour of meson-build-system as opposed to libtool?
Normally if something depends on nss and we add nss as an input, it should
be added automatically to the runpath, no?

Andreas

Gnome dans core-updates

Hello,

today I have compiled a maximum of inputs for gnome on berlin. Here is
what is missing:
The following derivations would be built:
  /gnu/store/1f71al4jx8pn7qnpp94642pvf6m4la5m-gnome-42.4.drv
  /gnu/store/4yvabkw23pwmxcanvl1qn8ch9jak7py4-packagekit-1.2.5.drv
  /gnu/store/pvbdfrkp0bq8n0hvnikjasccjly3vq3s-gnome-boxes-43.3.drv
  /gnu/store/0i008ksb4war4iglqcrhnypnnjiv3mgq-spice-gtk-0.42.drv
  /gnu/store/sv800qqkvz6l2y54rp4jfrbqva8zhr52-libcacard-2.8.1.drv
  /gnu/store/ry2kqxfgghknlykwjssz0xdakaiq83d5-qemu-minimal-7.2.0.drv
  /gnu/store/n6ssj7g7ha48kqb7x0vlksaxrd02q2f3-opensbi-qemu-1.1.drv
  /gnu/store/a5bk00q2m7k41fmafyqx7ndhgxn8p92p-opensbi-generic-1.1.drv
  /gnu/store/vn01aaqcd9wmxb8hc8c9wsav89mbjyxy-ipxe-qemu-1.21.1.drv
  /gnu/store/q838z0f92dbll0cr4xb4dgbzqyfdb51b-system-config-printer-1.5.16.drv
  /gnu/store/y3qcrzl8c8746z3g95jip95728xckzyv-gnome-initial-setup-42.2.drv

Substitutes for all other inputs should be available on berlin.

If someone knowledgeable with Gnome could have a look, that would be great!

Below a few more details.

Andreas


packagekit fails its installation phase (!) like so:
/gnu/store/xrn2zn2ky4jkigg2cal0g8sacpkfai9m-meson-0.63.2/bin/meson install 
--no-rebuild
ninja: build stopped: subcommand failed.
error: in phase 'install': uncaught exception:
%exception #<&invoke-error program: "ninja" arguments: ("install") exit-status: 
1 term-signal: #f stop-signal: #f>
phase `install' failed after 0.3 seconds
command "ninja" "install" failed with status 1
builder for `/gnu/store/4yvabkw23pwmxcanvl1qn8ch9jak7py4-packagekit-1.2.5.drv' 
failed with exit code 1
build of /gnu/store/4yvabkw23pwmxcanvl1qn8ch9jak7py4-packagekit-1.2.5.drv failed
View build log at 
'/var/log/guix/drvs/4y/vabkw23pwmxcanvl1qn8ch9jak7py4-packagekit-1.2.5.drv.gz'.


libcacard fails validate-runpath:
starting phase `validate-runpath'
validating RUNPATH of 1 binaries in 
"/gnu/store/29kdbd1q8lkyyr7apzczx53683mr0yhz-libcacard-2.8.1/lib"...
/gnu/store/29kdbd1q8lkyyr7apzczx53683mr0yhz-libcacard-2.8.1/lib/libcacard.so: 
error: depends on 'libnss3.so', which cannot be found in RUNPATH 
("/gnu/store/gsjczqir1wbz8p770zndrpw4rnppmxi3-glibc-2.35/lib" 
"/gnu/store/mw4l4bap7xw3s4v9j4v395qp2n4gz3x4-glib-2.72.3/lib" 
"/gnu/store/jxkn98nnk2pv3fy7cx2baaynkr4c63wp-nspr-4.35/lib" 
"/gnu/store/x22qi9rkzdb8pafcv78wb5nayph9m1d9-pcsc-lite-1.9.8/lib")
error: in phase 'validate-runpath': uncaught exception:
misc-error #f "RUNPATH validation failed" () #f
phase `validate-runpath' failed after 0.0 seconds
Backtrace:
   8 (primitive-load "/gnu/store/x2685x6mv5lcxf2l7idg1y5w7wb…")
In guix/build/gnu-build-system.scm:
908:2  7 (gnu-build #:source _ #:outputs _ #:inputs _ #:phases . #)
In ice-9/boot-9.scm:
  1752:10  6 (with-exception-handler _ _ #:unwind? _ # _)
In srfi/srfi-1.scm:
634:9  5 (for-each # …)
In ice-9/boot-9.scm:
  1752:10  4 (with-exception-handler _ _ #:unwind? _ # _)
In guix/build/gnu-build-system.scm:
   929:23  3 (_)
   570:10  2 (validate-runpath #:validate-runpath? _ # _ #:outputs _)
In ice-9/boot-9.scm:
  1685:16  1 (raise-exception _ #:continuable? _)
  1685:16  0 (raise-exception _ #:continuable? _)
ice-9/boot-9.scm:1685:16: In procedure raise-exception:
RUNPATH validation failed
builder for `/gnu/store/sv800qqkvz6l2y54rp4jfrbqva8zhr52-libcacard-2.8.1.drv' 
failed with exit code 1
build of /gnu/store/sv800qqkvz6l2y54rp4jfrbqva8zhr52-libcacard-2.8.1.drv failed
View build log at 
'/var/log/guix/drvs/sv/800qqkvz6l2y54rp4jfrbqva8zhr52-libcacard-2.8.1.drv.gz'.
We have
(propagated-inputs
 (list ...
   nss
and
(native-inputs
 (list ...
   `(,nss "bin")
It looks like we need some of nss (the "normal" output, not "bin") as a
standard input. I will give it a try.


opensbi-generic fails in the build phase:
error: in phase 'build': uncaught exception:
%exception #<&invoke-error program: "make" arguments: ("-j" "4" 
"PLATFORM=generic" "CROSS_COMPILE=riscv64-linux-gnu-" "FW_PAYLOAD=n" "V=1") 
exit-status: 2 term-signal: #f stop-signal: #f>
phase `build' failed after 3.8 seconds
command "make" "-j" "4" "PLATFORM=generic" "CROSS_COMPILE=riscv64-linux-gnu-" 
"FW_PAYLOAD=n" "V=1" failed with status 2
builder for 
`/gnu/store/a5bk00q2m7k41fmafyqx7ndhgxn8p92p-opensbi-generic-1.1.drv' failed 
with exit code 1
build of /gnu/store/a5bk00q2m7k41fmafyqx7ndhgxn8p92p-opensbi-generic-1.1.drv 
failed
View build log at 
'/var/log/guix/drvs/a5/bk00q2m7k41fmafyqx7ndhgxn8p92p-opensbi-generic-1.1.drv.gz'.
In the build log, there is this:
/tmp/guix-build-opensbi-generic-1.1.drv-0/source/lib/sbi/sbi_tlb.c:190: Error: 
unrecognized opcode `fence.i'
make: *** [Makefile:442: 
/tmp/guix-build-opensbi-generic-1.1.drv-0/source/build/lib/sbi/sbi_tlb.o] Error 
1
That looks serious.


ipxe-qemu also fails its build phase:
In file included from tests/bigint_test.c:38:
tests/bigint_test.c: In function ‘bigint_test_exec’:
tests/bigint_test.c:232:14: error: ‘result_raw’ may be used uninitialized 
[-Werror=maybe-uninitia

[PATCH] etc: Add gnome team.

* etc/teams.scm.in (gnome): New team.
("Liliana Marie Prikler"): Add to gnome.
---
Hi folks,

to get effort for GNOME 44 rolling while also recognizing the burden this
puts on folks, I've decided to add a gnome team to our teams.scm.

To those in Debbugs CC â you know who you are ;) â I've added you to CC,
because you've contributed changes to the mentioned scope since 2022.
If you'd like to be added to the team from the first commit, please
reply; otherwise feel free to add yourself at your convenience.

Cheers

 etc/teams.scm.in | 17 -
 1 file changed, 16 insertions(+), 1 deletion(-)

diff --git a/etc/teams.scm.in b/etc/teams.scm.in
index e582993450..9698c8b04c 100644
--- a/etc/teams.scm.in
+++ b/etc/teams.scm.in
@@ -436,6 +436,21 @@ (define-team reproduciblebuilds
 "Reproducible Builds tooling and issues that affect any guix packages."
 #:scope (list "gnu/packages/diffoscope.scm")))
 
+(define-team gnome
+  (team 'gnome
+#:name "Gnome team"
+#:description
+"The Gnome desktop environment, along with core technologies such as
+GLib/GIO, GTK, GStreamer and Webkit."
+#:scope (list "gnu/packages/glib.scm"
+  "gnu/packages/gstreamer.scm"
+  "gnu/packages/gtk.scm"
+  "gnu/packages/gnome.scm"
+  "gnu/packages/gnome-xyz.scm"
+  "gnu/packages/webkit.scm"
+  "guix/build/glib-or-gtk-build-system.scm"
+  "guix/build/meson-build-system.scm")))
+
 (define-team xfce
   (team 'xfce
 #:name "Xfce team"
@@ -511,7 +526,7 @@ (define-member (person "Florian Pelz"
 
 (define-member (person "Liliana Marie Prikler"
"liliana.prik...@gmail.com")
-  emacs games)
+  emacs games gnome)
 
 (define-member (person "Ricardo Wurmus"
"rek...@elephly.net")
-- 
2.39.2

Re: State of core-updates

Hi Felix,

Felix Lechner  writes:

> Hi Andreas,
>
> On Wed, Mar 15, 2023 at 7:57 AM Andreas Enge  wrote:
>>
>> Somehow the sending of store items when offloading poses problems
>
> Somehow I think I see a similar problem with 'guix deploy,' which I
> have to restart manually several times in order to complete the store
> transfer. In my case, the error presents as an SSH error ("parent
> process is not connected" I think) though, instead of a Cuirass
> timeout.

I can't be sure, but they don't seem related here: I can offload fine to
a distant machine, but using 'guix deploy' on the other hands often
caused GSSH errors, as I reported in #62213.

-- 
Thanks,
Maxim

Re: Offloading problems on berlin

Hi Andreas,

Andreas Enge  writes:

> Am Thu, Mar 16, 2023 at 02:50:53PM +0100 schrieb Ludovic Courtès:
>> There’s a problem with offloading on berlin:
>>   https://issues.guix.gnu.org/61839
>> I occasionally offload from my laptop to machines at work but didn’t hit
>> this bug, so we’ll have to see if it’s specific to berlin or not.
>
> Thanks for pointing out that it is a known issue!
> Is there a commandline program that can be used like gkrellm to check
> whether data is flowing out of berlin to the build node?

Just clarifying, it is *not* currently known issue outside of Berlin.

-- 
Thanks,
Maxim

Re: gnu: inetutils: Update to 2.4.

Hi Felix,

Felix Lechner  writes:

> Hi Maxim,
>
> On Tue, Mar 14, 2023 at 6:11 PM Maxim Cournoyer
>  wrote:
>>
>> Until everybody has a good grasp of the new process, I think sticking to
>> the documented one may be best for now
>
> The bug was retitled 'core-updates' per your request. [1]
>
> I didn't mean to set a tone in the discussion and merely hoped to
> embrace—by mistake it turns out—an existing consensus. My apologies!

No problem, I was a bit out of touch with the recent achievements from
the Guix Days workshop.  But yes, I think until these experiments are
settled in our reference manual, to ease our day to day collaboration we
can continue labeling our changes with the 'staging' or 'core-updates'
prefixes, as it help guards against mistakes :-).

-- 
Thanks,
Maxim

Re: The 🐑 Shepherd gets a service collection

Hi Ludo,

Ludovic Courtès  writes:

> Hi,
>
> Maxim Cournoyer  skribis:
>
>> Ludovic Courtès  writes:
>
> [...]
>
>>> I imagine we could develop more convenient services like this, such as a
>>> basic command scheduler similar to the ‘at’ command, and a syslogd
>>> implementation.  The latter could be nice for a couple of reasons:
>>> logging would happen from the start and till the end (an improvement
>>> over the external syslogd process), and it could let us provide a nicer
>>> user interface to view logs (taking inspiration from that of
>>> ‘journalctl’).
>>>
>>> Thoughts?  Ideas?
>>
>> While I also find the journalctl interface to be convenient, the
>> underlying database logs is costly in terms of storage and complexity
>
> Agreed (that’s why I mentioned the user interface of ‘journalctl’, not
> the storage mechanism of ‘journald’).

OK. In my mind both are probably hard to separate though (database logs
are more malleable, which is what journald exploits).

-- 
Thanks,
Maxim

Re: Feedback on indentation rules

Hello,

Ludovic Courtès  writes:

> Hi,
>
> Simon Tournier  skribis:
>
>> On Mon, 06 Mar 2023 at 17:56, Ludovic Courtès  wrote:
>>> Maxim Cournoyer  skribis:
>>>
 Thanks for the feedback.  I wonder if some are of the opinion that since
 gexp->derivation is a plain function rather than a syntax having a
 special form for its 2nd argument, we should leave the default
 indentation rules untouched for it?
>>>
>>> Yes, that’s my take and current practice so far: special rules for
>>> special forms (macros), not for procedures.
>>
>> What is the rationale?  Being able to know directly at the location when
>> it is a plain function or a special form?
>
> Yes.
>
> Now, it’s aesthetics so there’s no “rationale” per se but rather
> established practice: in the project, but also from what I can see in
> Guile and more generally Scheme (info "(guix) Formatting Code").

See commits d0b7858968a2c8c8cdacc3679447b250fb5b4dd9 and
933051281fbed0ae71bd40c24a701faf2a02791c, where I reverted to status quo
w.r.t. indentation rules of gexp->derivation and computed-file, given
the lack of clear consensus.

-- 
Thanks,
Maxim

Re: bug#61894: [PATCH RFC] Team approval for patches

2023-03-17 Thread Development of GNU Guix and the GNU System distribution.

Hi Ludovic,

Ludovic Courtès  writes:

> Hello!
>
> Maxim Cournoyer  skribis:
>
> [...]
>
>>> “Pacify” in the sense that, by being explicit, we avoid
>>> misunderstandings that could turn into unpleasant experiences.
>>>
>>> Like you I’m glad collaboration is nice and friendly; yet, over the past
>>> few months I’ve experienced misunderstandings that seemingly broke the
>>> consensus-based process that has always prevailed.
>>
>> I'm sorry that you feel that way.  I don't think consensus was willfully
>> broken,
>
> That’s my point: by being explicit about approval, we would avoid such
> misunderstandings.
>
>> and perhaps by studying some actual examples of these occurrences we
>> can better understand what went wrong and how the new suggested policy
>> would have helped or could be modified to help avoid such problems in
>> the future.
>
> I don’t want to rehash past occurrences of this problem.  It boils down
> to: changes where pushed despite consensus evidently not being met, at
> least not in the mind of every involved party.
>
> To some extent, that’s bound to happen due to an increase of the number
> of contributors, scope of the project, and diversity of backgrounds.  By
> making it clear that lack of “LGTM” from another team member equates
> with lack of consensus, we would avoid those misunderstandings.

I agree that firm conventions here would make things smoother.  It's
common that someone offers an incomplete review or just forget the LGTM,
and the author is left to ask if it's OK to push or not or assume it is.

> A good reference on consensus-based decision making is
> .
>
>> It's also worth noting that this consensus-based process has always
>> been implicit; for example, it is not defined/mentioned anywhere in
>> our documentation.  Perhaps it should?
>
> Those who’ve followed the project long enough, such as part of the
> current maintainer collective, are certainly aware of that; it’s also
> spelled out in
> .
>
> That said, again in the spirit of improving legibility, writing it down
> would be much welcome.

Yes, I've heard 'consensus' for years, and I think I have a good enough
understanding of it, but I think there are subtleties many (including
myself) fail to appreciate that the above link explains well, so I think
there's value in mentioning it somewhere.  I'll send a patch for
everyone to review.

>>> In a way, that’s probably bound to happen as the group grows, and I
>>> think that’s why we must be explicit about what the process is and about
>>> whether one is expressing consent or dissent.
>>>
>>> With so many things happening in Guix (yay!), it’s also easy to overlook
>>> a change and realize when it’s too late.  By having a rule that at least
>>> one other person on the team must approve (consent to) a change, we
>>> reduce that risk.
>>>
>>> Being on a team, then, is a way to express interest on a topic and to be
>>> “in the loop”.
>>
>> That's already what teams can do!
>
> Yes and no.  With the amount of activity going on, it’s easy to overlook
> something.  The explicit synchronization point could mitigate that.
>
>> I'd argue giving them the extra powers that would be conferred to
>> teams in this is not needed/desirable.  Some committer not a regular
>> member of X team may still be confident enough to push a patch sitting
>> on the tracker, and I think they should be able to.
>
> Self-assessment becomes tricky that this scale; I might be confident and
> yet someone will point out a problem (that literally happened to me two
> days ago in ).  That’s when review
> really helps.
>
> For “core” work, I insist that explicit approval (and thus peer review)
> is necessary.  I doubt anyone would seriously challenge that.
>
> Now, I agree, as I wrote before, that this may be overkill for “random
> packages”.
>
> Thus we need to find the right balance.
>
> What about team/scope-specific rules?  As in: “Changes covered by teams
> X, Y, and Z need to be explicitly approved by at least one other member
> of the team.”

To me, it seems challenging to partition the code correctly and avoid
overloading the core team with spurious changes, which would slow things
down more (as the core team would be a fraction of the committers
currently enabled to push such changes), but I agree in principle that
it makes sense.

>>> It is not about asserting power or building a hierarchy;
>>> it’s about formalizing existing relations and processes.
>>
>> OK; I think in practice it would amount to that though (building a
>> hierarchy which has some form power).
>
> I disagree: just because power relations are not spelled out doesn’t
> mean they don’t exist.  I don’t know where you’re talking from; one
> thing that to me shed light on these matters is “The Tyranny of
> Structurelessness” (I’m sure I mentioned it before, I certainly did
> during Q&A on

Re: Discussion notes on releases and branches

Hi Andreas,

On Thu, Feb 9, 2023 at 4:20 AM Andreas Enge  wrote:
>
> [excerpt from the attachment follows]
>
> - Smaller branches could be taken care of by dedicated persons
> [...]
> - Branch creators should fix a goal and tentative timeline.
> - We need a mapping between branches and maintainers responsible
>   for the merge.

Instead of dividing similar tasks among many people with different
priorities, I would appoint a "feature branch manager" (or perhaps,
chief pruner).

That person's job would be to keep an eye on the number of feature
branches on Savannah so they do not grow stale, or out of control.

Kind regards
Felix Lechner

Re: Notes from the Guix Days

Hello!

Ludovic Courtès  writes:

> Maxim Cournoyer  skribis:
>
>> Thanks for the explanations.  I'm out of the loop, not having been able
>> to attend physically the last Guix Days event.  Was there a recap of the
>> discussions posted somewhere?  Was the freeze announce somewhere?  I
>> wholly missed that, and I try to pay attention.
>
> Notes on the release and branching discussions are here:
>
>   https://lists.gnu.org/archive/html/guix-devel/2023-02/msg00066.html

All caught up now!

> Pjotr stored additional notes here (thanks!):
>
>   https://gitlab.com/pjotrp/guix-days-fosdem-2023/-/tree/main/

This is nice, I just peeked at "Debugging Guix beyond pk".  I'll
bookmark and read more of it, thank you!

-- 
Maxim

Re: Offloading problems on berlin