bug#60803: Cuirass stopped processing jobs for aarch64-linux and x86_64-linux

2023-01-14 Thread Marius Bakke
Marius Bakke  skriver:

> The 335212 build is for x86_64-linux, we have the same problem with
> 335087 (also perftest) on aarch64.  i686-linux and powerpc64le-linux is
> fine.

I deleted these two from the Builds and BuildDependencies tables which
allowed Cuirass to move forward (or backwards, really, as it was
processing new jobs just fine).

Not sure how to mitigate the problem (race when two evaluations create
different derivations with identical outputs at the same time?), but at
least we know how to deal with it.

Speaking of builds, I started debugging #60016 and accidentally deleted
build 175246!  Enough late night debugging for me...  I'll set up my own
Cuirass to experiment on "soon".


signature.asc
Description: PGP signature


bug#60821: "failed to compute the derivation" and openssl build failure

2023-01-14 Thread Zach Philipchook
Hi!

I installed guix on Ubuntu 20.04 from a tarball and I'm getting an error
while doing an initial `guix pull`. Apparently, openssl fails to build.

The command output: https://pastebin.com/BVvdcXX2
The openssl build ouput: https://pastebin.com/Kpn0avU1

--
Zach


bug#60811: Can’t change the build system of p11-kit to meson

2023-01-14 Thread Vivien Kraus via Bug reports for GNU Guix
Hello!

Le samedi 14 janvier 2023 à 21:10 +0100, Csepp a écrit :
> The way I debugged a cycle was:
> * use package graph type
> * import graph into Python's networkx using pydot
> * run networkx's cycle detection

If I select the "package" graph type, guix graph completes:

$ ./pre-inst-env guix graph --type=package p11-kit
digraph "Guix package" {
  "14023452720" [label = "p11-kit@0.23.22", shape = box, fontname =
sans];
  "14023452720" -> "14023453072" [color = magenta];
  "14023452720" -> "140300286436736" [color = magenta];
  "14023452720" -> "140299980957936" [color = magenta];
  "14023452720" -> "14023453072" [color = magenta];
  "14023453072" [label = "libtasn1@4.17.0", shape = box, fontname =
sans];
  "14023453072" -> "140299983720224" [color = blue];
  "140299983720224" [label = "perl@5.34.0", shape = box, fontname =
sans];
  "140299983720224" -> "140299983567616" [color = red];
  "140299983567616" [label = "coreutils-minimal@8.32", shape = box,
fontname = sans];
  "140300286436736" [label = "pkg-config@0.29.2", shape = box, fontname
= sans];
  "140299980957936" [label = "libffi@3.3", shape = box, fontname =
sans];

}

Thank you for your python script! Unfortunately, it does not detect any
cycles here.

Vivien





bug#60811: Can’t change the build system of p11-kit to meson

2023-01-14 Thread Csepp


Vivien Kraus via Bug reports for GNU Guix  writes:

> Dear guix,
>
> p11-kit is switching its build system to meson. The README already
> advertises it as the way to build p11-kit. When I try to change that,
> guix builds fine. Then, if I try to run guix build p11-kit, guix will
> crash after exhausting all my memory. I suspect a circular dependency
> of some sort, but I don’t know how to debug it.
>
> If I try and run:
> $ ./pre-inst-env guix graph --type=bag p11-kit
>
> Then I get as an output,
>
> digraph "Guix bag" {
>
> And then guix starts eating my memory indefinitely until I cancel it.
>
> How can I debug this?
>
> Best regards,
>
> Vivien

The way I debugged a cycle was:
* use package graph type
* import graph into Python's networkx using pydot
* run networkx's cycle detection

Here is the script so you don't have to figure it out yourself:

```
#!/usr/bin/env python
# coding: utf-8
import networkx
import sys
G = networkx.drawing.nx_pydot.read_dot(sys.stdin)
Va = networkx.function.get_node_attributes(G, "label")
print(*[Va[e[0]] for e in networkx.find_cycle(G)])
```





bug#60816: guix pull ("computing Guix derivation") is not reproducible

2023-01-14 Thread Julien Lepiller
Hi Guix!

I found out today that guix pull does not compute the same derivation
on two machines, with the same architecture (x86_64), using the same
initial Guix revision (4473be9) and pulling to the same commit
(c77978d).

guix-packages-base.drv seems to be the first derivation to differ. I
get:

/gnu/store/185wzzjc6dslrw1avz7cfrafrr0l7bp9-guix-packages-base.drv on
one machine and
/gnu/store/v7jvidnqxdjkhnxi846lsc91ak7ala9k-guix-packages-base.drv on
the other.

Here's the diff (I used a sed to s/,/,\n/g for the diff to be more
meaningful :)):

2c2
< "/gnu/store/866q7lb582jid68alzpd5z0cj88gpm3j-guix-packages-base",
---
> "/gnu/store/kmqhq1fa1ah7x7iz3jqfqcm4p53rln6p-guix-packages-base",
42,44c42,44
<
"/gnu/store/8wdw7l4badagdzs7pay8fj15v50p8by3-guix-packages-base-source",
< "/gnu/store/rybrv6mrbb8yihk4mdhsmnfqlq3i4rq8-module-import",
<
"/gnu/store/svssahra9ahb73knj7jq666jnhrcjk4z-guix-packages-base-builder"],
---
> "/gnu/store/8s93iwfi0kscr5911h8b4312krwywa7q-guix-packages-base-source",
> "/gnu/store/pxwsa9i2sqy96f153jcbs1m4sb8bmqs2-guix-packages-base-builder",
> "/gnu/store/rybrv6mrbb8yihk4mdhsmnfqlq3i4rq8-module-import"],
52c52
<
"/gnu/store/svssahra9ahb73knj7jq666jnhrcjk4z-guix-packages-base-builder"],
---
> "/gnu/store/pxwsa9i2sqy96f153jcbs1m4sb8bmqs2-guix-packages-base-builder"],
58c58
< "/gnu/store/866q7lb582jid68alzpd5z0cj88gpm3j-guix-packages-base")])
\ Pas de fin de ligne à la fin du fichier
---
> "/gnu/store/kmqhq1fa1ah7x7iz3jqfqcm4p53rln6p-guix-packages-base")])
\ Pas de fin de ligne à la fin du fichier


So, apart from the output filename which obviously changes, it seems
that the differences are:

- order of dependencies,
- source output,
- builder (only because it references the source output)

Here's the result of diffoscope on the source outputs (ignore
modification date, I used touch to make them all the same, not to make
them sensible ;)):

--- source1
+++ source2
│   --- source1/gnu
├── +++ source2/gnu
│ │   --- source1/gnu/packages
│ ├── +++ source2/gnu/packages
│ │ │   --- source1/gnu/packages/aux-files
│ │ ├── +++ source2/gnu/packages/aux-files
│ │ │ │   --- source1/gnu/packages/aux-files/linux-libre
│ │ │ ├── +++ source2/gnu/packages/aux-files/linux-libre
│ │ │ │ ├── file list
│ │ │ │ │ @@ -9,18 +9,14 @@
│ │ │ │ │  5.10-arm64.conf
│ │ │ │ │  5.10-i686.conf
│ │ │ │ │  5.10-x86_64.conf
│ │ │ │ │  5.15-arm.conf
│ │ │ │ │  5.15-arm64.conf
│ │ │ │ │  5.15-i686.conf
│ │ │ │ │  5.15-x86_64.conf
│ │ │ │ │ -5.18-arm.conf
│ │ │ │ │ -5.18-arm64.conf
│ │ │ │ │ -5.18-i686.conf
│ │ │ │ │ -5.18-x86_64.conf
│ │ │ │ │  5.4-arm.conf
│ │ │ │ │  5.4-arm64.conf
│ │ │ │ │  5.4-i686.conf
│ │ │ │ │  5.4-x86_64.conf
│ │ │ │ │  6.1-arm.conf
│ │ │ │ │  6.1-arm64.conf
│ │ │ │ │  6.1-i686.conf
│ │ │ │ ├──
/gnu/store/8fpk2cja3f07xls48jfnpgrzrljpqivr-coreutils-8.32/bin/stat {}
│ │ │ │ │ @@ -1,8 +1,8 @@
│ │ │ │ │  
│ │ │ │ │ -  Size: 766  Blocks: 0  IO Block: 4096
 directory
│ │ │ │ │ +  Size: 650  Blocks: 0  IO Block: 4096
 directory
│ │ │ │ │  Links: 1
│ │ │ │ │  Access: (0555/dr-xr-xr-x)  Uid: ( 1000/tyreunom)   Gid: (
998/   users)
│ │ │ │ │  
│ │ │ │ │  Modify: 2019-12-31 23:00:00.0 +
│ │ │ │ ├──
/gnu/store/8fpk2cja3f07xls48jfnpgrzrljpqivr-coreutils-8.32/bin/stat {}
│ │ │ │ │ @@ -1,8 +1,8 @@
│ │ │ │ │  
│ │ │ │ │ +  Size: 650  Blocks: 0  IO Block: 4096
 directory
│ │ │ │ │ -  Size: 766  Blocks: 0  IO Block: 4096
 directory
│ │ │ │ │  Links: 1
│ │ │ │ │  Access: (0555/dr-xr-xr-x)  Uid: ( 1000/tyreunom)   Gid: (
998/   users)
│ │ │ │ │  
│ │ │ │ │  Modify: 2019-12-31 23:00:00.0 +
│ │ │   --- source1/gnu/packages/patches
│ │ ├── +++ source2/gnu/packages/patches
│ │ │ ├── file list
│ │ │ │ @@ -136,15 +136,14 @@
│ │ │ │  classpath-aarch64-support.patch
│ │ │ │  classpath-miscompilation.patch
│ │ │ │  cling-use-shared-library.patch
│ │ │ │  clucene-contribs-lib.patch
│ │ │ │  clucene-pkgconfig.patch
│ │ │ │  cmake-curl-certificates-3.24.patch
│ │ │ │  cmake-curl-certificates.patch
│ │ │ │ -cmh-support-fplll.patch
│ │ │ │  coda-use-system-libs.patch
│ │ │ │  collectd-5.11.0-noinstallvar.patch
│ │ │ │  combinatorial-blas-awpm.patch
│ │ │ │  combinatorial-blas-io-fix.patch
│ │ │ │  connman-CVE-2022-32292.patch
│ │ │ │  connman-CVE-2022-32293-pt1.patch
│ │ │ │  connman-CVE-2022-32293-pt2.patch
│ │ │ │ @@ -216,15 +215,14 @@
│ │ │ │  emacs-source-date-epoch.patch
│ │ │ │  emacs-telega-path-placeholder.patch
│ │ │ │  emacs-telega-test-env.patch
│ │ │ │  emacs-wordnut-require-adaptive-wrap.patch
│ │ │ │  emacs-yasnippet-fix-tests.patch
│ │ │ │  enjarify-setup-py.patch
│ │ │ │  enlightenment-fix-setuid-path.patch
│ │ │ │ -eog-update-libportal-usage.patch
│ │ │ │  erlang-man-path.patch
│ │ │ │  esmtp-add-lesmtp.patch
│ │ │ │  eudev-rules-directory.patch
│ │ │ │  exercism-disable-self-update.patch
│ │ │ │  extempore-unbundle-external-dependencies.patch
│ │ │ │  extundelete-e2fsprogs-1.44.patch
│ │ │ │  fail2ban-0.11.2_CVE-2021-32749.patch
│ 

bug#57493: should allow for customizing home directory permission bits

2023-01-14 Thread Thompson, David
On Tue, Aug 30, 2022 at 1:10 PM Thompson, David
 wrote:
>
> Hi Guix,
>
> Issue 56444 (https://issues.guix.gnu.org/56444) was caused by the 
> activate-users+groups procedure in (gnu build activation) unconditionally 
> setting all user home directory permission bits to 700. The fix for that bug 
> was to set the bits for a particular user to 750 in a service activation 
> script.  The fix is quite imperfect, however, because during system 
> reconfiguration the bits are temporarily reset back to 700 by 
> activate-users+groups, breaking Guix's promise of atomicity.  The proper fix 
> would be to add something like a 'home-directory-permission-bits' field to 
> , which defaults to 700, and have activate-users+groups use 
> that value.  This way, there will no longer be an unknown amount of time 
> where the bits are reset and potentially breaking some service during that 
> time.

FInally got around to writing a patch for this!

- Dave
From 013ad524971dc6ea810fe3b92042c039cecd2f8a Mon Sep 17 00:00:00 2001
From: David Thompson 
Date: Sat, 14 Jan 2023 10:53:16 -0500
Subject: [PATCH 1/2] gnu: system: Add home-directory-permissions field to
 .

* gnu/system/accounts.scm ()[home-directory-permissions]: New
field.
(user-account-home-directory-permissions): New accessor.
* gnu/build/activation.scm (activate-users+groups): Use home directory
permission bits from the user account object.
* doc/guix.texi (User Accounts): Document new field.
---
 doc/guix.texi| 4 
 gnu/build/activation.scm | 6 +++---
 gnu/system/accounts.scm  | 3 +++
 3 files changed, 10 insertions(+), 3 deletions(-)

diff --git a/doc/guix.texi b/doc/guix.texi
index c07ec89b2f..52548c3dfa 100644
--- a/doc/guix.texi
+++ b/doc/guix.texi
@@ -17337,6 +17337,10 @@ administrator's choice; reconfiguring does @emph{not} change their name.
 @item @code{home-directory}
 This is the name of the home directory for the account.
 
+@item @code{home-directory-permissions} (default: @code{#o700})
+The permission bits for the home directory.  By default, full access is
+granted to the user account and all other access is denied.
+
 @item @code{create-home-directory?} (default: @code{#t})
 Indicates whether the home directory of this account should be created
 if it does not exist yet.
diff --git a/gnu/build/activation.scm b/gnu/build/activation.scm
index eea2233563..fd043ca131 100644
--- a/gnu/build/activation.scm
+++ b/gnu/build/activation.scm
@@ -162,14 +162,14 @@ (define (activate-users+groups users groups)
 group records) are all available."
   (define (make-home-directory user)
 (let ((home (user-account-home-directory user))
+  (home-permissions (user-account-home-directory-permissions user))
   (pwd  (getpwnam (user-account-name user
   (mkdir-p home)
 
   ;; Always set ownership and permissions for home directories of system
-  ;; accounts.  If a service needs looser permissions on its home
-  ;; directories, it can always chmod it in an activation snippet.
+  ;; accounts.
   (chown home (passwd:uid pwd) (passwd:gid pwd))
-  (chmod home #o700)))
+  (chmod home home-permissions)))
 
   (define system-accounts
 (filter (lambda (user)
diff --git a/gnu/system/accounts.scm b/gnu/system/accounts.scm
index 586cff1842..dd6930c619 100644
--- a/gnu/system/accounts.scm
+++ b/gnu/system/accounts.scm
@@ -28,6 +28,7 @@ (define-module (gnu system accounts)
 user-account-supplementary-groups
 user-account-comment
 user-account-home-directory
+user-account-home-directory-permissions
 user-account-create-home-directory?
 user-account-shell
 user-account-system?
@@ -69,6 +70,8 @@ (define-record-type* 
   (commentuser-account-comment (default ""))
   (home-directory user-account-home-directory (thunked)
   (default (default-home-directory this-record)))
+  (home-directory-permissions user-account-home-directory-permissions
+  (default #o700))
   (create-home-directory? user-account-create-home-directory? ;Boolean
   (default #t))
   (shell  user-account-shell  ; gexp
-- 
2.38.1



bug#60566: [PATCH] environment: Fix '--emulate-fhs' option overriding $PATH.

2023-01-14 Thread Ludovic Courtès
Hi John,

John Kehayias  skribis:

> From beb6f9255fc62fe52e237f82c7e953a21b7f82f4 Mon Sep 17 00:00:00 2001
> From: John Kehayias 
> Date: Thu, 5 Jan 2023 16:06:19 -0500
> Subject: [PATCH] * environment: Fix '--emulate-fhs' option overriding $PATH.
>
> Fixes  where even if "--preserve='^PATH$'"
> was passed to 'guix shell' it would be replaced by just the FHS directories
> when '--emulate-fhs' was also set.
>
> * gnu/scripts/environment.scm (launch-environment): Add the FHS directories to
> $PATH rather than overriding $PATH completely.
> * tests/guix-environment-container.sh: Test that FHS directories are in $PATH
> in the container and that $PATH can be preserved.

[...]

> -   (setenv "PATH" "/bin:/usr/bin:/sbin:/usr/sbin")
> +   (setenv "PATH" (string-append "/bin:/usr/bin:/sbin:/usr/sbin"
> + (when (getenv "PATH")
> +   (string-append ":" (getenv 
> "PATH")

Remember that ‘when’ returns *unspecified* when the condition is false,
so you’d get a type error here when PATH is undefined.

Instead write: (if (getenv "PATH") … "").

> +# Test that $PATH inside the container has FHS directories.
> +guix shell -CF --bootstrap guile-bootstrap \
> + -- guile -c '(exit (if (string-contains (getenv "PATH")
> +"/bin:/usr/bin:/sbin:/usr/sbin")
> +   0
> +   1))'

Even (exit (string=? (getenv "PATH") "/bin:/usr/bin:/sbin:/usr/sbin")).

> +# Make sure '--preserve' is honored for $PATH, which the '--emulate-fhs'
> +# option will modify.  We can't (easily) check the whole $PATH as it will
> +# differ inside and outside the container, so just check for an added string.
> +PATH=this-is-a-test:$PATH guix shell -CF --bootstrap guile-bootstrap -E PATH 
> \
> + -- guile -c '(exit (if (string-contains (getenv "PATH")
> +"this-is-a-test")
> +   0
> +   1))'

It might be slightly more concise with ‘env’:

  PATH=/foo $(type -P guix) shell -E ^PATH$ -C coreutils -- env |grep 
^PATH=.*:/foo

(I think ‘--bootstrap’ doesn’t buy us much here because we have to
download/build ‘glibc-for-fhs’ anyway.  ‘--bootstrap’ and
‘guile-bootstrap’ are particularly useful for testse that can run
without network access and without building tons of stuff, as in
‘tests/guix-environment.sh’ for instance.)

Otherwise LGTM, thanks!

Ludo’.





bug#60786: unsupported mips64el architecture can cause cryptic backtraces

2023-01-14 Thread Ludovic Courtès
Hi,

Maxim Cournoyer  skribis:

> Maxim Cournoyer  writes:

[...]

>> This issue was triggered by having make-uboot-package uses #:target [0],
>> but it already exists on current master.  I've spent some time narrowing
>> down the issue, and it is caused by the package returned by
>> cross-kernel-headers in (gnu packages cross-base) being produced with a
>> bogus arguments field, or at least one that can't be access via the
>> package-arguments accessor:

It’s not that the field cannot be accessed; the field is thunked, and
thus exceptions can be thrown when you access it, as you found out:

> OK, I think I've found the culprit:
>
>  (setenv "ARCH" ,(platform-linux-architecture
>   (lookup-platform-by-target target)))

Ludo’.





bug#60811: Can’t change the build system of p11-kit to meson

2023-01-14 Thread Vivien Kraus via Bug reports for GNU Guix
Dear guix,

p11-kit is switching its build system to meson. The README already
advertises it as the way to build p11-kit. When I try to change that,
guix builds fine. Then, if I try to run guix build p11-kit, guix will
crash after exhausting all my memory. I suspect a circular dependency
of some sort, but I don’t know how to debug it.

If I try and run:
$ ./pre-inst-env guix graph --type=bag p11-kit

Then I get as an output,

digraph "Guix bag" {

And then guix starts eating my memory indefinitely until I cancel it.

How can I debug this?

Best regards,

Vivien