bug#41738: Jupyter propagates two different versions of ipython

[paul]

Hi Guix,

On Guix System

  guix ecab53c
    repository URL: https://git.savannah.gnu.org/git/guix.git
    branch: master
    commit: ecab53c320b1584a08f811b17a92bd9a50a50ff3

it's impossible to install jupyter in a new profile because it tries to 
propagate two different versions of python-ipython, you should be able 
to reproduce with:


$ guix package -p /tmp/tmp-profile -i jupyter
The following package will be installed:
   jupyter 1.0.0

guix package: error: profile contains conflicting entries for python-ipython
guix package: error:   first entry: python-ipython@7.9.0 
/gnu/store/z0yarar134q6sziqncjdlfg2h2w5b2yh-python-ipython-7.9.0

guix package: error:    ... propagated from python-ipywidgets@7.5.1
guix package: error:    ... propagated from jupyter@1.0.0
guix package: error:   second entry: python-ipython@7.9.0 
/gnu/store/avmg5jd7kccchxadsd9c7zq0p3shlk3w-python-ipython-7.9.0

guix package: error:    ... propagated from python-qtconsole@4.4.3
guix package: error:    ... propagated from jupyter@1.0.0
hint: You cannot have two different versions or variants of `jupyter' in 
the same profile.



The conflict seems to be caused because:

- 
/gnu/store/avmg5jd7kccchxadsd9c7zq0p3shlk3w-python-ipython-7.9.0depends 
on python-prompt-toolkit@3.0.5


- 
/gnu/store/z0yarar134q6sziqncjdlfg2h2w5b2yh-python-ipython-7.9.0depends 
on python-prompt-toolkit@2.0.7



This change seems to be introduced with 
32ba87c14fd5e5b54d95211cd9a159d568ce7c67 , which updates 
python-prompt-toolkit to 3.0.5 and to prevent python-ipywidgets, 
python-jupyter-console and python-widgetsnbextension tests from crashing 
builds them with python-prompt-toolkit@2.0.7.



Giacomo

bug#20597: ‘unlinkat’ bug in Linux 4.0.2 leads to tar test failure

[Paul Eggert]

Pádraig Brady wrote:

Yes I agree, either behavior is possible


In that case let's change the test case to not run afoul of this 
implementtion-defined behavior.  I don't think we need to change tar, as it's a 
contrived test case that users are not likely to run into.

bug#25476: pivot-root test fails on Ubuntu 16.04

[Paul Garlick]

Hi,

I have noticed that the pivot-root test on my development system has
started to fail.  After running 'make check' the result: FAIL is
recorded for the syscalls.scm test.

I have recently updated the system.  It is running Ubuntu 16.04.
 Previously, the test passed.  Now:

$ uname -r
4.4.0-59-generic

Best,

Paul.

bug#25476: pivot-root test fails on Ubuntu 16.04

[Paul Garlick]

Hi Ludo,
> That’s on Git master, right?
Yes, back on the master branch the test still fails:
$ git describe
v0.11.0-3373-g2df3d14
> Could you post tests/syscalls.log?
> 

Attached.
Best,
Paul.

test-name: mount, ENOENT
location: /data/paul/sourceCode/guix/tests/syscalls.scm:38
source:
+ (test-equal
+   "mount, ENOENT"
+   ENOENT
+   (catch 'system-error
+  (lambda ()
+(mount "/dev/null" "/does-not-exist" "ext2")
+#f)
+  (compose system-error-errno list)))
expected-value: 2
actual-value: 2
result: PASS

test-name: umount, ENOENT/EPERM
location: /data/paul/sourceCode/guix/tests/syscalls.scm:46
source:
+ (test-assert
+   "umount, ENOENT/EPERM"
+   (catch 'system-error
+  (lambda () (umount "/does-not-exist") #f)
+  (lambda args
+(memv (system-error-errno args)
+  (list EPERM ENOENT)
actual-value: (1 2)
result: PASS

test-name: mount-points
location: /data/paul/sourceCode/guix/tests/syscalls.scm:55
source:
+ (test-assert
+   "mount-points"
+   (any (cute member <> (mount-points))
+'("/" "/proc" "/sys" "/dev")))
actual-value: (/ /sys/kernel/security /dev/shm /run/lock /sys/fs/cgroup /sys/fs/cgroup/systemd /sys/fs/pstore /sys/fs/cgroup/memory /sys/fs/cgroup/net_cls,net_prio /sys/fs/cgroup/pids /sys/fs/cgroup/cpuset /sys/fs/cgroup/cpu,cpuacct /sys/fs/cgroup/blkio /sys/fs/cgroup/devices /sys/fs/cgroup/freezer /sys/fs/cgroup/perf_event /sys/fs/cgroup/hugetlb /proc/sys/fs/binfmt_misc /sys/kernel/debug /dev/mqueue /dev/hugepages /run/rpc_pipefs /sys/fs/fuse/connections /data /run/cgmanager/fs /run/user/1000 /run/user/1000/gvfs)
result: PASS

test-name: swapon, ENOENT/EPERM
location: /data/paul/sourceCode/guix/tests/syscalls.scm:61
source:
+ (test-assert
+   "swapon, ENOENT/EPERM"
+   (catch 'system-error
+  (lambda () (swapon "/does-not-exist") #f)
+  (lambda args
+(memv (system-error-errno args)
+  (list EPERM ENOENT)
actual-value: (1 2)
result: PASS

test-name: swapoff, ENOENT/EINVAL/EPERM
location: /data/paul/sourceCode/guix/tests/syscalls.scm:69
source:
+ (test-assert
+   "swapoff, ENOENT/EINVAL/EPERM"
+   (catch 'system-error
+  (lambda () (swapoff "/does-not-exist") #f)
+  (lambda args
+(memv (system-error-errno args)
+  (list EPERM EINVAL ENOENT)
actual-value: (1 22 2)
result: PASS

test-name: mkdtemp!
location: /data/paul/sourceCode/guix/tests/syscalls.scm:77
source:
+ (test-assert
+   "mkdtemp!"
+   (let* ((tmp (or (getenv "TMPDIR") "/tmp"))
+  (dir (mkdtemp!
+ (string-append tmp "/guix-test-XX"
+ (and (file-exists? dir) (begin (rmdir dir) #t
actual-value: #t
result: PASS

test-name: statfs, ENOENT
location: /data/paul/sourceCode/guix/tests/syscalls.scm:85
source:
+ (test-equal
+   "statfs, ENOENT"
+   ENOENT
+   (catch 'system-error
+  (lambda () (statfs "/does-not-exist"))
+  (compose system-error-errno list)))
expected-value: 2
actual-value: 2
result: PASS

test-name: statfs
location: /data/paul/sourceCode/guix/tests/syscalls.scm:92
source:
+ (test-assert
+   "statfs"
+   (let ((fs (statfs "/")))
+ (and (file-system? fs)
+  (> (file-system-block-size fs) 0)
+  (>= (file-system-blocks-available fs) 0)
+  (>= (file-system-blocks-free fs)
+  (file-system-blocks-available fs)
actual-value: #t
result: PASS

test-name: clone
location: /data/paul/sourceCode/guix/tests/syscalls.scm:109
source:
+ (test-assert
+   "clone"
+   (match (clone (logior CLONE_NEWUSER SIGCHLD))
+  (0 (primitive-exit 42))
+  (pid (and (not (equal?
+   (readlink (user-namespace pid))
+   (readlink (user-namespace (getpid)
+(match (waitpid pid)
+   ((_ . status) (= 42 (status:exit-val status
actual-value: #t
result: PASS

test-name: setns
location: /data/paul/sourceCode/guix/tests/syscalls.scm:122
source:
+ (test-assert
+   "setns"
+   (match (clone (logior CLONE_NEWUSER SIGCHLD))
+  (0 (primitive-exit 0))
+  (clone-pid
+(match (pipe)
+   ((in . out)
+(match (primitive-fork)
+   (0
+(close in)
+(call-with-input-file
+  (user-namespace clone-pid)
+  (lambda (port) (setns (port->fdes port) 0)))
+(write 'done out)
+(close out)
+ 

bug#25476: pivot-root test fails on Ubuntu 16.04

[Paul Garlick]

> 
> Could you change “(eq? #t result)” to “result”, rerun the test, and
> send
> syscalls.log?
> 
> 
Hi Ludo,
After a 'git pull --rebase' I now have:
$ git describe
v0.12.0-984-gabb7eb7
The pivot-root test still fails.  The 'actual-value' is now #.  I
have attached the syscalls.log file.  
In fact there is also a new FAIL result, for utmpx-entries.  Is this
unrelated?
Best,
Paul.test-name: mount, ENOENT
location: /data/paul/sourceCode/guix/tests/syscalls.scm:38
source:
+ (test-equal
+   "mount, ENOENT"
+   ENOENT
+   (catch 'system-error
+  (lambda ()
+(mount "/dev/null" "/does-not-exist" "ext2")
+#f)
+  (compose system-error-errno list)))
expected-value: 2
actual-value: 2
result: PASS

test-name: umount, ENOENT/EPERM
location: /data/paul/sourceCode/guix/tests/syscalls.scm:46
source:
+ (test-assert
+   "umount, ENOENT/EPERM"
+   (catch 'system-error
+  (lambda () (umount "/does-not-exist") #f)
+  (lambda args
+(memv (system-error-errno args)
+  (list EPERM ENOENT)
actual-value: (1 2)
result: PASS

test-name: mount-points
location: /data/paul/sourceCode/guix/tests/syscalls.scm:55
source:
+ (test-assert
+   "mount-points"
+   (any (cute member <> (mount-points))
+'("/" "/proc" "/sys" "/dev")))
actual-value: (/ /sys/kernel/security /dev/shm /run/lock /sys/fs/cgroup /sys/fs/cgroup/systemd /sys/fs/pstore /sys/fs/cgroup/devices /sys/fs/cgroup/pids /sys/fs/cgroup/memory /sys/fs/cgroup/freezer /sys/fs/cgroup/net_cls,net_prio /sys/fs/cgroup/hugetlb /sys/fs/cgroup/cpu,cpuacct /sys/fs/cgroup/blkio /sys/fs/cgroup/cpuset /sys/fs/cgroup/perf_event /proc/sys/fs/binfmt_misc /dev/hugepages /dev/mqueue /sys/kernel/debug /run/rpc_pipefs /sys/fs/fuse/connections /data /run/cgmanager/fs /run/user/1000 /run/user/1000/gvfs)
result: PASS

test-name: swapon, ENOENT/EPERM
location: /data/paul/sourceCode/guix/tests/syscalls.scm:61
source:
+ (test-assert
+   "swapon, ENOENT/EPERM"
+   (catch 'system-error
+  (lambda () (swapon "/does-not-exist") #f)
+      (lambda args
+(memv (system-error-errno args)
+  (list EPERM ENOENT)
actual-value: (1 2)
result: PASS

test-name: swapoff, ENOENT/EINVAL/EPERM
location: /data/paul/sourceCode/guix/tests/syscalls.scm:69
source:
+ (test-assert
+   "swapoff, ENOENT/EINVAL/EPERM"
+   (catch 'system-error
+  (lambda () (swapoff "/does-not-exist") #f)
+  (lambda args
+(memv (system-error-errno args)
+  (list EPERM EINVAL ENOENT)
actual-value: (1 22 2)
result: PASS

test-name: mkdtemp!
location: /data/paul/sourceCode/guix/tests/syscalls.scm:77
source:
+ (test-assert
+   "mkdtemp!"
+   (let* ((tmp (or (getenv "TMPDIR") "/tmp"))
+  (dir (mkdtemp!
+ (string-append tmp "/guix-test-XX"
+ (and (file-exists? dir) (begin (rmdir dir) #t
actual-value: #t
result: PASS

test-name: statfs, ENOENT
location: /data/paul/sourceCode/guix/tests/syscalls.scm:85
source:
+ (test-equal
+   "statfs, ENOENT"
+   ENOENT
+   (catch 'system-error
+  (lambda () (statfs "/does-not-exist"))
+  (compose system-error-errno list)))
expected-value: 2
actual-value: 2
result: PASS

test-name: statfs
location: /data/paul/sourceCode/guix/tests/syscalls.scm:92
source:
+ (test-assert
+   "statfs"
+   (let ((fs (statfs "/")))
+ (and (file-system? fs)
+  (> (file-system-block-size fs) 0)
+  (>= (file-system-blocks-available fs) 0)
+  (>= (file-system-blocks-free fs)
+  (file-system-blocks-available fs)
actual-value: #t
result: PASS

test-name: clone
location: /data/paul/sourceCode/guix/tests/syscalls.scm:109
source:
+ (test-assert
+   "clone"
+   (match (clone (logior CLONE_NEWUSER SIGCHLD))
+  (0 (primitive-exit 42))
+  (pid (and (not (equal?
+   (readlink (user-namespace pid))
+   (readlink (user-namespace (getpid)
+(match (waitpid pid)
+   ((_ . status) (= 42 (status:exit-val status
actual-value: #t
result: PASS

test-name: setns
location: /data/paul/sourceCode/guix/tests/syscalls.scm:122
source:
+ (test-assert
+   "setns"
+   (match (clone (logior CLONE_NEWUSER SIGCHLD))
+  (0 (primitive-exit 0))
+  (clone-pid
+(match (pipe)
+   ((in . out)
+(match (primitive-fork)
+   (0
+(close in)
+(call-with-input-file
+  (user-namespace clone-pid

bug#25476: pivot-root test fails on Ubuntu 16.04

[Paul Garlick]

Hi Ludo,

Here is the output from the guile session:

paul$ ./pre-inst-env guile
GNU Guile 2.0.13
Copyright (C) 1995-2016 Free Software Foundation, Inc.

Guile comes with ABSOLUTELY NO WARRANTY; for details type `,show w'.
This program is free software, and you are welcome to redistribute it
under certain conditions; type `,show c' for details.

Enter `,help' for help.
scheme@(guile-user)> ,use(guix build syscalls)
scheme@(guile-user)> (utmpx-entries)
$1 = (#< type: 2 pid: 0 line: "~" id: (126 126 0 0) user:
"reboot" host: "4.4.0-59-generic" termination: 0 exit: 0 session: 0
time: #
address: (0 0 0 0)> #< type: 1 pid: 53 line: "~" id: (126
126 0 0) user: "runlevel" host: "4.4.0-59-generic" termination: 0 exit:
0 session: 0 time: # address: (0 0 0 0)> #< type: 6 pid: 1589 line:
"tty1" id: (116 116 121 49) user: "LOGIN" host: #f termination: 0 exit:
0 session: 1589 time: # address: (0 0 0 0)> #< type: 7 pid:
1908 line: "tty7" id: (58 48 0 0) user: "paul" host: ":0" termination:
0 exit: 0 session: 0 time: # address: (0 0 0 0)> #< type: 7 pid:
2486 line: "pts/11" id: (47 49 49 0) user: "paul" host: ":0.0"
termination: 0 exit: 0 session: 0 time: # address: (0 0 0 0)> #< type: 7 pid: 2486 line: "pts/2" id: (47 50 0 0) user: "paul"
host: ":0.0" termination: 0 exit: 0 session: 0 time: # address: (0 0 0 0)>)
scheme@(guile-user)> ,use(srfi srfi-1)
scheme@(guile-user)> (find (lambda (entry) (and (string? (utmpx-user 
entry))(zero? (utmpx-pid entry)))) (utmpx-entries))
$2 = #< type: 2 pid: 0 line: "~" id: (126 126 0 0) user:
"reboot" host: "4.4.0-59-generic" termination: 0 exit: 0 session: 0
time: #
address: (0 0 0 0)>

The $2 ##SELECTION_END##output is not false in this case.

Paul.

bug#25476: pivot-root test fails on Ubuntu 16.04

[Paul Garlick]

> I think a1a8b7f2e20513a3ad968e74e7ec52546404e3c6 fixes this.
> 
> 
Yes, confirmed.  The utmpx-entries test now passes.
The pivot-root test still fails.  One thought; I made a change to the
guix-daemon.service file, at about the same time as updating Ubuntu to
16.04, setting TMPDIR to /data/tmp.  Could that be related?
Paul.

bug#27975: guix sd 32b was not installed because of adwaita-icon-theme-3.24.0

[Paul Dufresne]

I have taken pencil notes which was probably a bit broken.

I have tried to install guix sd 0.13.0 32 bit on usb key.

It broke at some file, at 78% (12.8 MiB file):
https://mirror.hydra.gnu.org/guix/nar/gzip/qs27jxbxjpvw5bv49nzw9r91hj00r12j-adaita.icon-theme-3.24.0
well that's what I have noted but this exact file cannot be retrieved.
this was followed by gzip error

I then tried to relaunch: guix system init /mnt/etc/config.scm /mnt
but this time with --failback (or --fallback?)

this time, at first I have seen it load the adwaita gzip file... but quite
later, it did seems to build from source,
and this time I stop it after 25-45 mins after:
going to copy
8x8
...
256x256
Enterning directory /tmp/guix builds-adwaita-icon-...src/symbolic
for size in ; do \
 ...
done
for file in 'cd ../../Adwaita/scalable; find . "*.svg"'; do \
...
done
 [there I waited about 25-45 mins before doing Ctrl-C]

bug#27976: install 32b xfce no gnome: collision hicolor/icon-theme.cache

[Paul Dufresne]

After having problem with adwaita-icon-them-3.24.0, (reported in other bug)
 I decided to give a try by removing gnome service from the
list of "meta-package" to install.

So in fact keeping 'only' XFCE.

I tried two times, once after the adwaita problem, the other after a reboot
and from scratch (except partitioning).

The result was the same (from poorly taken notes):
...
warning: collision encountered:
/gnu/store/7qnfb279...hicolor/icon-theme.cache
...
warning: arbitrarily choosing 7qnfb...icons/hicolor/icons-theme.cache
...
Backtrace:
In Ice-0/boot-9.scm
...
In unknown file
   gtk-in-modules-builder

That's it, what I had noted.

So, I had to boot with an other system to report this, was unable to get
guix-sd 0.13.0 usb install 32b to install.

bug#27976: install 32b xfce no gnome: collision hicolor/icon-theme.cache

[Paul Dufresne]

I installed with 64b.

The collision happened in 64b, but did not stop installation.

bug#31977: clone tests fail on CentOS 7

[Paul Garlick]

Hi Guix,

Running 'make check' in the guix source tree on a CentOS 7 system
results in 15 FAILS:

tests/containers.log: 9 FAILS
tests/syscalls.log: 3 FAILS
tests/guix-environment-container.log: 1 FAIL
tests/guix-pack.log: 1 FAIL
tests/pack.log: 1 FAIL

Referring to bug#24108, the cause may be that the clone-related tests
are being executed instead of being skipped. 

The output of 'uname -srv' is:

Linux 3.10.0-862.3.3.el7.x86_64 #1 SMP Fri Jun 15 04:15:27 UTC 2018

Files:
a)  '/proc/self/ns/user' exists
b) '/proc/sys/kernel/unprivileged_userns_clone' does not exist.

On CentOS 7 I believe user namespaces are supported but disabled by
default.  The output of 'cat /proc/sys/user/max_user_namespaces' is
'0'.

Perhaps the 'perform-container-tests?' logic should include an extra
check for the default, disabled case to ensure that the tests are
skipped.

Attached are the log files, except 'guix-pack.log' (~100MB) and
'pack.log' (~7MB).

Best regards,

Paul.

test-name: call-with-container, exit with 0 when there is no error
location: /data/paul/sourceCode/guix/tests/containers.scm:41
source:
+ (test-assert
+   "call-with-container, exit with 0 when there is no error"
+   (zero? (call-with-container
+'()
+(const #t)
+#:namespaces
+'(user
actual-value: #f
actual-error:
+ (system-error
+   "clone"
+   "~d: ~A"
+   (268435473 "Invalid argument")
+   (22))
result: FAIL

test-name: call-with-container, user namespace
location: /data/paul/sourceCode/guix/tests/containers.scm:46
source:
+ (test-assert
+   "call-with-container, user namespace"
+   (zero? (call-with-container
+'()
+(lambda ()
+  (assert-exit
+(and (zero? (getuid)) (zero? (getgid)
+#:namespaces
+'(user
actual-value: #f
actual-error:
+ (system-error
+   "clone"
+   "~d: ~A"
+   (268435473 "Invalid argument")
+   (22))
result: FAIL

test-name: call-with-container, uts namespace
location: /data/paul/sourceCode/guix/tests/containers.scm:55
source:
+ (test-assert
+   "call-with-container, uts namespace"
+   (zero? (call-with-container
+'()
+(lambda ()
+  (sethostname "test-container")
+  (primitive-exit 0))
+#:namespaces
+    '(user uts
actual-value: #f
actual-error:
+ (system-error
+   "clone"
+   "~d: ~A"
+   (335544337 "Invalid argument")
+   (22))
result: FAIL

test-name: call-with-container, pid namespace
location: /data/paul/sourceCode/guix/tests/containers.scm:66
source:
+ (test-assert
+   "call-with-container, pid namespace"
+   (zero? (call-with-container
+'()
+(lambda ()
+  (match (primitive-fork)
+ (0 (assert-exit (= 2 (getpid
+ (pid (primitive-exit
+(match (waitpid pid)
+   ((_ . status)
+(status:exit-val status)))
+#:namespaces
+'(user pid
actual-value: #f
actual-error:
+ (system-error
+   "clone"
+   "~d: ~A"
+   (805306385 "Invalid argument")
+   (22))
result: FAIL

test-name: call-with-container, mnt namespace
location: /data/paul/sourceCode/guix/tests/containers.scm:82
source:
+ (test-assert
+   "call-with-container, mnt namespace"
+   (zero? (call-with-container
+(list (file-system
+(device "none")
+(mount-point "/testing")
+(type "tmpfs")
+(check? #f)))
+(lambda ()
+  (assert-exit (file-exists? "/testing")))
+#:namespaces
+'(user mnt
actual-value: #f
actual-error:
+ (system-error
+   "clone"
+   "~d: ~A"
+   (268566545 "Invalid argument")
+   (22))
result: FAIL

test-name: call-with-container, mnt namespace, wrong bind mount
location: /data/paul/sourceCode/guix/tests/containers.scm:94
source:
+ (test-equal
+   "call-with-container, mnt namespace, wrong bind mount"
+   `(system-error ,ENOENT)
+   (catch 'system-error
+  (lambda ()
+(call-with-container
+  (list (file-system
+  (device "/does-not-exist")
+  (mount-point "/foo")
+  (type "none")
+  (flags '(bind-mount))
+  (check? #f)))
+  (const #t)
+  #:namespaces
+  '(user mnt)))
+  (lambda args
+(list 'system-error (sys

bug#32261: guix packages website: add mechanism to link to individual packages

[Paul Wise]

Hi all,

It used to be possible to link to individual Guix packages like this:

https://www.gnu.org/software/guix/packages/m.html#myrepos

Since the recent change to the packages website the packages pages are
paginated and have no anchors, which means they will break as more
packages are added and also I cannot link directly to a package,
only to a location that contains lots of other packages too.

https://www.gnu.org/software/guix/packages/M/page/3/

Fixing this would be useful for the Repology support of GNU Guix,
which currently cannot link to GNU Guix packages:

https://repology.org/repository/gnuguix
https://repology.org/metapackage/myrepos/versions

-- 
bye,
pabs

https://bonedaddy.net/pabs3/

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

bug#32261: guix packages website: add mechanism to link to individual packages

[Paul Wise]

On Tue, 2018-07-24 at 16:52 +, Nils Gillmann wrote:

> It is not just repology, but easy linking to details for external
> parties/downstreams we need to point to somewhere.

Indeed.

> I think there were some remaining ideas for the new websites,
> where a package gets detail page on its own.

That sounds good to me and is how a number of distros do it.

> The pages are statically generated

In that case, perhaps when a package is updated in the VCS, the static
generation tool could be triggered to update just that package.

> the old "useful" page format was taking a very long time to load,
> with each release and increase of package count we got k more
> seconds. Nothing I'd like to go back to.

Agreed, going back to the previous version would not be useful.

-- 
bye,
pabs

https://bonedaddy.net/pabs3/

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

bug#31977: clone tests fail on CentOS 7

[Paul Garlick]

Hi Simon,

On Tue, 2020-12-01 at 19:12 +0100, zimoun wrote:
> This old bug #31977 is about an issue on your CentOS 7 machine.  Is
> it still relevant?

Yes, this bug still exists.

However, I have just tested a fix:

--- a/gnu/build/linux-container.scm
+++ b/gnu/build/linux-container.scm
@@ -44,7 +44,7 @@
   (let ((userns-file "/proc/sys/kernel/unprivileged_userns_clone"))
 (if (file-exists? userns-file)
 (eqv? #\1 (call-with-input-file userns-file read-char))
-#t)))
+#f)))
 
 (define (setgroups-supported?)
   "Return #t if the setgroups proc file, introduced in Linux-libre
3.19,

This ensures that tests are skipped if user namespaces are not enabled
for unprivileged users.

Best regards,

Paul.

bug#31977: clone tests fail on CentOS 7

[Paul Garlick]

Hi Simon,

I have pushed the fix as 8bc5ca5160db3d82bd5b6b2b7ed80c96f42bd33e.

Best regards,

Paul.

bug#45069: BUG: Re: guix environment: error: cannot create container: unprivileged user cannot create user namespaces

[Paul Garlick]

Hi Pierre,

Can you try, as root on Guix System:

$ echo 1 > /proc/sys/kernel/unprivileged_userns_clone

If you could report success or failure that would be helpful; the
unprivileged-user-namespace-supported? test in gnu/build/linux-
container.scm should be the same irrespective of the underlying
distribution (Debian, CentOS, Guix System ...).

Best regards,

Paul.

On Mon, 2020-12-07 at 12:57 +0100, Pierre Neidhardt wrote:
> Hi!
> 
> I can reproduce the issue since I 'recondigure'd my Guix System.
> I'm on cebfb29abb151ede95696181d2446c63504593d7.
> 
> Guix' bug?
> 
> 

bug#45069: BUG: Re: guix environment: error: cannot create container: unprivileged user cannot create user namespaces

[Paul Garlick]

Hi Pierre,

> # echo 1 > /proc/sys/kernel/unprivileged_userns_clone
> -bash: /proc/sys/kernel/unprivileged_userns_clone: No such file or
> directory

Thanks, that gives us a clue.  So all or part of the path
'/proc/sys/kernel' is missing?

Best regards,

Paul.

bug#31977: clone tests fail on CentOS 7

[Paul Garlick]

Hi Simon,

> If I understand well your message:
> 
> Files:
> a) '/proc/self/ns/user' exists
> b) '/proc/sys/kernel/unprivileged_userns_clone' does not exist.

Yes, this is the case on CentOS.  

So testing for the existence of the unprivileged_userns_clone file is
an insufficent test for unprivileged user namespaces.  We have learnt
that trying to create the file as a dummy file does not work, since the
/proc/sys/kernel directory is read-only even for root.

So the current 'unprivileged-user-namespace-supported?' function in
gnu/build/linux-container.scm really only works for Debian-derived
systems.  Other systems, that co not create the
unprivileged_userns_clone file, differ in their default configurations.
CentOS, for example, disables the feature.  However, Guix System
enables it.

It has been suggested that the feature itself should be tested, instead
of relying on the /proc filesystem.  This could well be a better idea
and I gather from the thread that this idea is being worked on.  I can
test on CentOS when a new patch is available.

Best regards,

Paul. 

bug#54833: system reconfigure fails: error: live-service-transient: unbound variable

[Paul Alesius]

.drv
  /gnu/store/1m905231f0wmrl6hyz50za33q21hk3ix-profile.drv
  /gnu/store/495pawm0pr0c8figwc7v4qa9m33sfjd0-inferior-script.scm.drv

building /gnu/store/rf0si3432vzpjiaxk6gg8bbbq52zsj19-guix-config.drv...
building /gnu/store/nnkckwm63pd6wxkbmpaakmpdwhkkvf8f-guix-system.drv...
 48% [#

]builder for `/gnu/store/nnkckwm63pd6wxkbmpaakmpdwhkkvf8f-guix-system.drv'
failed with exit code 1
build of /gnu/store/nnkckwm63pd6wxkbmpaakmpdwhkkvf8f-guix-system.drv failed
View build log at
'/var/log/guix/drvs/nn/kckwm63pd6wxkbmpaakmpdwhkkvf8f-guix-system.drv.gz'.
cannot build derivation
`/gnu/store/k8mnrvgi80xgdv692x41a3nxdckd7pcg-guix-cli.drv': 1
dependencies couldn't be built
building /gnu/store/pk556x6jd84d64s6s57g8gmzvncfskql-guix-config-modules.drv...
cannot build derivation
`/gnu/store/yiwl413d15g6n5phqk2kg4alkzsx8x1f-guix-home.drv': 1
dependencies couldn't be built
cannot build derivation
`/gnu/store/bb3bmmkq21xrm7c46zmb0iamplpqy5w8-guix-system-modules.drv':
1 dependencies couldn't be built
cannot build derivation
`/gnu/store/pv0ylz4nmryl41bxd7x914b7l5afrbzv-guix-system-tests.drv': 1
dependencies couldn't be built
cannot build derivation
`/gnu/store/i5mqv501hqfijdg0wfvfgjp844wcgsbx-guix-a2c759c83-modules.drv':
1 dependencies couldn't be built
cannot build derivation
`/gnu/store/3zjzklpbgvld3n28ggszsv5pn3xw92ym-guix-a2c759c83.drv': 1
dependencies couldn't be built
cannot build derivation
`/gnu/store/grn1kqxqdh20hql31fvpyjk15pyaaazh-profile.drv': 1
dependencies couldn't be built
guix pull: error: build of
`/gnu/store/grn1kqxqdh20hql31fvpyjk15pyaaazh-profile.drv' failed
-- end log

-- start log
noname@devbox ~$ zcat
/var/log/guix/drvs/nn/kckwm63pd6wxkbmpaakmpdwhkkvf8f-guix-system.drv.gz
[ 93/194] loading... 95.9% of 97 filesice-9/psyntax.scm:2813:12:
In procedure syntax-violation:
Syntax error:
guix/scripts/system/reconfigure.scm:147:20: live-service: Wrong number
of arguments in form (live-service provision requirement running)
-- end log

With regards,
- Paul

bug#52904: nmtui - user authorisation

[Paul Jewell]

On 31/12/2021 18:41, Josselin Poiret wrote:

Hello,
raingloom  writes:


On Wed, 29 Dec 2021 11:04:39 +
Paul Jewell  wrote:


On 29/12/2021 00:50, raingloom wrote:

On Tue, 28 Dec 2021 18:39:52 +
Paul Jewell   wrote:
  

On 27/12/2021 23:20, Leo Famulari wrote:

On Mon, Dec 27, 2021 at 10:07:17PM +, Paul Jewell wrote:

Solved this - nmtui needs to be run as root; my script which
invoked the program didn't consider that. Changing it to run as
sudo gives me an opportunity to enter my password, and then
successfully setup the wifi interface details.

Another option is to add nmtui to the list of programs that are
setuid. That way, any user on your system could configure wifi,
which may be more ergonomic.

https://guix.gnu.org/manual/devel/en/html_node/Setuid-Programs.html
 

This option did work as expected. The only additional point for
anyone else coming across this post with the same issue: remember
to add the

#:use-module (gnu system setuid)

so the setuid record is known.

Thanks Leo!

Uhm, I'm pretty sure NetworkManager lets any user modify networking
settings as long as they are in a certain group?
https://wiki.archlinux.org/title/NetworkManager#Set_up_PolicyKit_permissions

At least that's how it is on postmarketOS and I'm also fairly
certain I never needed root access to set up WiFi under Guix
either, but I don't have a system at hand to verify that on.

I did also think this, but I couldn't identify which group would let
this happen. I thought it would be the netdev group, but my user
account is already a member of that group. The network group is
unknown to the system (as in I had an error when trying to add the
user to the supplementary group) so I added it, but it didn't have
any effect (after rebooting). If there is another group I should be
in, I am not sure how to find out. At the moment, the setuid approach
seems to work OK (although I would prefer a group solution!).

I am interested in anyone else's experience!

It might be that everyone else is including some default configuration
for NetworkManager and we aren't. At the very least it should be
documented how to set it up to use groups.

CC-ing bugs-guix

NetworkManager uses dbus to communicate with its root-run service, and
Polkit to check for permissions.  By default, the NetworkManager actions
are pretty permissive, you can do most of them without reauthenticating,
except for a couple specific ones.

More in detail, Polkit works by looking up the PID of processes that
ask for specific actions, and then asking systemd-logind/elogind which
session that process is attached to.  Then, there are three different
cases:
* the session is active (not locked, I think that means in logind
parlance).  In this case, Polkit looks at the `allow_active` rule.
* the session is inactive (or locked).  Then, Polkit looks at the
`allow_inactive`.
* there is no session attached to the process (possible for eg. system
services).  Then, Polkit looks at the `allow_any` rule.

Now, if you look at network-manager's
/share/polkit-1/actions/org.freedesktop.NetworkManager.policy, you can
see that some actions are possible for active sessions, while impossible
for inactive sessions, or even processes not attached to the session.

So, I think the issue is that you are trying to do some actions outside
of a session, or in an inactive session, and Polkit refuses to let you
do that.  I don't think there is a way to circumvent that, since there
is no `allow_any` rule for many actions, but I don't know what this
entails (if it is an implicit `no`, `auth_admin`, etc...).

Note that we have a catch-all rule defined at `polkit-wheel` in
gnu/services/desktop.scm that says that administrative users are exactly
the users in the group `wheel`.  That means that when Polkit needs to
authenticate an administrative user, it will ask for your own password
if you're in the `wheel` group, but you still need to reauthenticate,
you cannot bypass that check.

I hope this clears up how Polkit works, and why the action is denied.


Good morning Josselin, and Happy New Year!

Many thanks for taking the time to explain this in detail for us. If I 
have properly understood your explanation, it suggests I am running 
network-manager from outside of the dbus session. If I look at the 
processes running on my system at this moment, the dbus-launch process 
has an id of 881, while the network-manager session has an id of 463, 
suggesting that it was started before dbus. My system configuration is 
relatively standard (if there is such a thing) - I don't do anything to 
change how dbus or network manager are launched, but rely on the 
defaults provided by the the desktop-service. Is there any way to ensure 
network-manager is launched inside the dbus session? I am using slim 
rather than gdm, and as a desktop manager I am using dwm (with some 
local changes).


Regarding the wheel group - my user is in this gro

bug#54061: thermald-2.4.7 build fail following upower update to 0.99.15

[Paul Jewell]

When building thermald-2.4.7, I am getting a build failure:

8<-
src/thd_engine_adaptive.cpp: In member function ‘int 
cthd_engine_adaptive::evaluate_lid_condition(condition)’:
src/thd_engine_adaptive.cpp:1002:61: error: ‘gboolean 
up_client_get_lid_is_closed(UpClient*)’ is deprecated 
[-Werror=deprecated-declarations

]

8<-

According to jpoiret (via IRC), this is due to the upower update from 
0.99.13 to 0.99.15, and the marking of the "up_client_get_lid_is_closed" 
function as deprecated.


I am not sure where the compiler flag setting is made turning this 
warning into an error. I have no configuration in my system config which 
could be doing this (at least not explicitly).

bug#54061: thermald-2.4.7 build fail following upower update to 0.99.15

[Paul Jewell]

I have reported this upstream: 
https://github.com/intel/thermal_daemon/issues/340


It seems the problem was known (at least by the upower developers) for 9 
months, but there was no comment on the thermald github issue list.

bug#54061: thermald-2.4.7 build fail following upower update to 0.99.15

[Paul Jewell]

On 19/02/2022 14:55, Maxime Devos wrote:

Paul Jewell schreef op vr 18-02-2022 om 17:07 [+]:

When building thermald-2.4.7, I am getting a build failure:

[... deprecation error ...]



The attached two patches should fix this.

Greetings,
Maxime.


Hi Maxime,
Many thanks for this - with the patches everything builds OK.

I also noted a pull request is outstanding for thermald which will 
remove the need for the deprecated functions, so hopefully the changes 
can be reversed with the next version of thermald.


When do you think these patches can be merged (notwithstanding the 
comments from Nicolas of course)?


Best regards,
Paul

bug#54061: thermald-2.4.7 build fail following upower update to 0.99.15

[Paul Jewell]

Good afternoon,

Thanks Ludo, and also Maxime and Guillaume.

Upstream have also merged a fix to the original problem, so I guess the 
change made here can be removed again after the next release.


Best regards,
Paul

On 02/03/2022 17:03, Ludovic Courtès wrote:

Hi,

Maxime Devos  skribis:


 From d066a7dcd11757fb19edc79028104f7dbcffeab1 Mon Sep 17 00:00:00 2001
From: Maxime Devos
Date: Sat, 19 Feb 2022 14:52:17 +
Subject: [PATCH 2/2] gnu: thermald: Fix build failure.

* gnu/packages/admin.scm (thermald)[arguments]<#:configure-flags>: Add
'--disable-werror'.

Fixes:<https://issues.guix.gnu.org/54061>
Reported-by: Paul Jewell

Guillaume fixed it independently in commit
73db69bea15e390a31289fdfadb1d5b9a7d13557.

Closing!

Ludo’.

bug#39727: statx error running 'guix gc' on CentOS 7

[Paul Garlick]

Hi Guix,

After a 'guix pull' today to commit
536cc4aae5b58b45b974530646a4916a29a8aa6c I noticed that 'guix gc' fails
with the message:

guix gc: error: statting `/gnu/store/.links/0pck...': Invalid argument

The system is running CentOS 7:

$ cat /etc/centos-release
CentOS Linux release 7.7.1908 (Core)

A temporary fix is to remove 'statx' from the list of functions checked
in 
config-daemon.ac (line 96):

-  statvfs nanosleep strsignal statx])
+ statvfs nanosleep strsignal])

This could a problem with the kernel version or coreutils [0] in CentOS
7.  

It seems that HAVE_STATX is set in the guix build process but then
runtime calls to statx generate errors.

Best regards,

Paul.

[0] https://bugzilla.redhat.com/show_bug.cgi?id=1760300

bug#39727: statx error running 'guix gc' on CentOS 7

[Paul Garlick]

Hi Ludo,

> This was during the “removing unused link” phase, right?
> 
Yes, that's it.

> The system is running CentOS 7:
> 
> $ cat /etc/centos-release
> CentOS Linux release 7.7.1908 (Core)
> 
> What does “uname -r” return?

3.10.0-1062.12.1.el7.x86_64

> Let me know how it goes!

I compiled a C program with the following code using gcc-toolchain
9.2.0:

#define _GNU_SOURCE
#include 
#include 
#include 
#include 
#include 

int main(void)
{
  struct statx st;
  if (statx(AT_FDCWD, "/",
AT_SYMLINK_NOFOLLOW | AT_STATX_DONT_SYNC,
/* AT_SYMLINK_NOFOLLOW, */
STATX_SIZE | STATX_NLINK, &st) == -1)
printf ("failed: %m\n");

  return 0;
}

Initially, with the AT_STATX_DONT_SYNC flag, the output is:

$ failed: Invalid argument

Then, without the  AT_STATX_DONT_SYNC flag, the program runs and there
is no output.

Best regards,

Paul.

bug#39727: statx error running 'guix gc' on CentOS 7

[Paul Garlick]

Hi Ludo,


> Great.  Could you apply the following patch, run the daemon with:
> 
>   sudo -E ./pre-inst-env guix-daemon --build-users-group=…
> 
> then run:
> 
>   guix gc -C42

Yes, all is good.  

I have re-built guix with your patch and started the daemon.  Now 'guix
gc' runs as expected:

.
.
.
deleted or invalidated more than 42 bytes; stopping
deleting `/gnu/store/trash'
deleting unused links...
note: currently hard linking saves 3264.68 MiB
guix gc: freed 0.91850 MiBs

Many thanks!  CentOS 7 will be around for a few years yet.

Best regards,

Paul.

bug#65523: package `guile@3.0.9' has an invalid input: ("_" #)

[Paul Alesius]

In the source code directory of Guix, when trying to build a package from
gnu/packages/python-xyz.scm, it fails with the following error:

guix build: error:
/storage/src/guix/guix-gnu/guix/build-system/gnu.scm:146:8: package
`guile@3.0.9' has an invalid input: ("_" #)

For example:
guix build -L $(pwd) -e "(begin (use-modules (gnu packages python-xyz))
poetry)"
guix build -L $(pwd) -e "(begin (use-modules (gnu packages python-xyz))
python-lsp-server)"

It fails for all packages in python-xyz.scm. But you can build other
packages:
guix build -L $(pwd) -e "(begin (use-modules (gnu packages any-other))
program)"

/ Paul

bug#66169: guix reconfigure error no match for id 4f35ff1275e05be31f5d41464ccf147e9dbfd016

[Paul Szenher]

On 9/24/23 5:22 AM, Guillaume Le Vaillant wrote:

Liliana Marie Prikler  skribis:


Am Sonntag, dem 24.09.2023 um 08:49 + schrieb Guillaume Le
Vaillant:

Liliana Marie Prikler  skribis:


Am Samstag, dem 23.09.2023 um 22:02 +0300 schrieb Roman Riabenko:

I am trying to upgrade my guix systems. I ran guix pull and now I
am
trying to run guix system reconfigure. It failed on two different
machines with the same backtrace. Please see the full backtrace
attached. The error message from it:

ice-9/boot-9.scm:1685:16: In procedure raise-exception:
Git error: object not found - no match for id
(4f35ff1275e05be31f5d41464ccf147e9dbfd016)


$ guix describe
Generation 28   Sep 23 2023 19:30:36(current)
   guix 4f35ff1
     repository URL: https://git.savannah.gnu.org/git/guix.git
     branch: master
     commit: 4f35ff1275e05be31f5d41464ccf147e9dbfd016

Considering that I experience it on two guix machines with
different
system configurations, I assume that there is some bug somewhere.

Experiencing the same for commit
35fd25af9bbcce84908101a9f487ba106a8d6df7.  I would hazard a guess
that it's due to them being merge commits.  Interestingly,
allow-downgrades does not have an effect on this message.

Cheers


I reconfigured two machines using commit
4f35ff1275e05be31f5d41464ccf147e9dbfd016, and it succeeded on both
machines, I didn't get this "no match for id" issue.
That's strange...

Do you have provenance tracking on your machines (the default)?


Yes. I use an additional channel, not only the "guix" default channel.
Maybe that makes a difference...


Also reporting similar issues on a Guix machine with multiple channels.

In my case, I have a local 'file://...' channel that I use for 
development, and have found that the following sequence of actions will 
consistently exhibit the above behavior on guix master:


1. Commit update to local channel git
2. guix pull
3. sudo guix system reconfigure

The issue is resolved by removal of the root user's guix cache in 
/root/.cache/guix (forcing a full fetch during system reconfigure), but 
repeating the above steps will cause the issue to reoccur.


I suspect it might have to do with the recent changes made to the 
'reference-available?' function in 
6d33c1f8061e86d63ab5c9ec75df9c58130c7264 (though it's not entirely clear 
why that change would cause this failure).


After downgrading my "guix" channel to 
f45c0c82289d409b4fac00464ea8b323839ba53f (the commit immediately prior 
to the above change) I am again able to receive changes from my local 
channel without issue.

bug#74687: Bug while guix pull

[Paul Allen]

building /gnu/store/irdgdf1yycafngq7rmba4fmwd10dib1n-coreutils-9.1.drv...
\ 'check' phaseBacktrace:
  14 (primitive-load
"/gnu/store/f0kr3m78cmy6qpg3zfy03hps98i8f1rb-compute-guix-derivation")
In ice-9/eval.scm:
155:9 13 (_ _)
159:9 12 (_ #(#(#(#(#(#(#(#(#(#(#(#(#(#(#(#(# ?)
?) ?) ?) ?) ?) ?) ?) ?) ?) ?) ?) ?) ?) ?) ?))
In ice-9/boot-9.scm:
152:2 11 (with-fluid* _ _ _)
152:2 10 (with-fluid* _ _ _)
In guix/store.scm:
  2210:24  9 (run-with-store #
# ?)
   2038:8  8 (_ #)
In guix/gexp.scm:
   300:22  7 (_ #)
   1218:2  6 (_ #)
   1085:2  5 (_ #)
926:4  4 (_ #)
In guix/store.scm:
  2095:12  3 (_ #)
   1433:5  2 (map/accumulate-builds #
# ?)
  1449:15  1 (_ #
("/gnu/store/k94x9l1f56iaaxhl9h0wcnnzqyfifvv8-curl-8.6.0?" ?) ?)
  1449:15  0 (loop #f)

guix/store.scm:1449:15: In procedure loop:
ERROR:
  1. &store-protocol-error:
  message: "build of
`/gnu/store/k94x9l1f56iaaxhl9h0wcnnzqyfifvv8-curl-8.6.0.drv' failed"
  status: 100
guix pull: error: You found a bug: the program
'/gnu/store/f0kr3m78cmy6qpg3zfy03hps98i8f1rb-compute-guix-derivation'
failed to compute the derivation for Guix (version:
"3e2442de5268782213b04048463fcbc5d76accd7"; system: "aarch64-linux";
host version: "2756c660fb2d9e2fe3e1fd0898e4d7038c8273c7"; pull-version: 1).
Please report the COMPLETE output above by email to .

bug#77195: [PATCH 0/7] Remove fenics

[Paul Garlick]

Hi Guix,

Thank you for the notification that fenics-dolfin is not currently
building.

It has been a while :-) but I plan to resume maintaining the fenics
packages in Guix by the end of this month.

A quick look at the build log for fenics-dolfin suggests that the
problem is VTK-related; possibly a new VTK version containing an
updated function.

In terms of the upstream project, fenicsx will replace fenics.  It has
currently reached version 0.9; the production version may be released
later this year.

I intend to package fenicsx for Guix, including its new dependencies. 
Ideally, the fenicsx and fenics packages would co-exist for a period,

Best regards,

Paul.


On Tue, 2025-04-01 at 15:54 +0200, Andreas Enge wrote:
> Am Tue, Apr 01, 2025 at 02:33:24PM +0200 schrieb Ludovic Courtès:
> > My understanding of <https://issues.guix.gnu.org/77195> is that
> > only
> > ‘fenics-dolfin’ fails to build, so perhaps we could limit to this
> > one
> > package?
> > No strong opinion though.
> 
> Me neither. I tend to rather the other side, why should we keep a
> package that is outdated and that probably nobody uses anymore, but
> that uses project resources (builds; people trying to fix it when it
> potentially stops building, which is bound to happen with
> unmaintained
> software)?
> 
> So I would drop them all unless someone speaks up who uses any of
> them
> (or knows someone else who does).
> 
> Andreas
> 

bug#21949: git-2.6.3: 108M download, but 23M installed

[Florian Paul Schmidt]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256


Hi,

I noticed this earlier and wonder if it's a bug or not:

When downloading the git-2.6.3 substitute from hydra it is a hefty
108M download, but installed in the store it's just 23M.

Compression failure? :)

Regards,
Flo

- -- 
https://fps.io
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQEbBAEBCAAGBQJWTCKwAAoJEA5f4Coltk8ZKRgH9iDfZsPd7x5k6XZ3MmCKtj/x
4FkuNHAnaZs2yZ1uQnGoK4cdPzSHkzPPl5A//ZvO7WXrgaw0fW1m2iFe4fcc7uHW
oU81s7GszXHMEha8WelhzUtr+NyLYWnICg5/9EIHc75eNQcA9hVa514wbkSKXokS
DYo3iH+h0CkxdV4QnwDKP2Rv+TS5ZR9UoLjRcawafM7ZeXbbPW2yyKJxUrsRc+ti
uG3MIgfeRyqOus1StlntYZRt+eMZzY9RmmRaocWxDsSBT4WL7Tx8CzqIO6YA66T7
Kb1eMib5gCYmk8HXpxXGPRaRdhGUzlzBpWCP4uvIGW7LrJWHZVAeJIAVF1HldQ==
=QV3F
-END PGP SIGNATURE-

bug#22024: openssh does not install ssh-copy-id and its manpage

[Florian Paul Schmidt]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256


see. subject.

- -- 
https://fps.io
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQEcBAEBCAAGBQJWWA/YAAoJEA5f4Coltk8Zv0gH/AxyEXh6g0op+xNuWgbLCM5c
zc/rSDIlHIXL6IraclfhsvTPv6pPOTY33z9aV8mJ4vZJ2/Y+6VcuSb+qikTLUPiW
KeiAwdhPcG/MN2fN2pQVT8DyNFIgh7tCkmEUdPhzREhuudUgQTS0W3BhjxXIFE22
DMNb35bej0bFPjLOWt5kO2EoisIZA/DRwZH10/G3TAC+Io/Mc20RMN9LAA7K9uko
Oqm34OyFcwPpQZhtRP1SaSr4ipcMqaWzDxkHGeI6RNZb7WS0RrCajDub/8gGL+iW
WPjZUcvylx6L7wSmZ/3Z8S1L9p7DVMnz3Q9oQO1IBWlsHYUHG8b2/1bB8n7wKws=
=sXuD
-END PGP SIGNATURE-

bug#22024: [PATCH] openssh: install ssh-copy-id.

[Florian Paul Schmidt]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 11/27/2015 11:38 AM, Ricardo Wurmus wrote:
> This fixes bug #22024.
> 

Wow, thanks :)

Flo

- -- 
https://fps.io
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQEcBAEBCAAGBQJWWIXZAAoJEA5f4Coltk8ZlksH/18HM9V/ao40QXgVw06D0lO2
8xeVcGXmCJV5Nv4S7juZQyAfGZliMZQE5W17BZy8b4wprBIFM6JlUf5sydj4a4Bh
h2nZL/jHMscgTGuQlFqeO+TVwJGNL3Oj/lUoS5zDZXNwHYFfqwU0wOoOra724pF6
UQvAgJU8oDAf9gXoK0FX+GgYQrZRyJsErTM6LGJ/ykLNrETkL7F1sjLX6TjNVhN8
4N7UahP7l6tI2658vWemHVyBdbTRPr9VDryDOx+bXMis7eIGiNc22ZvrxoGLUc2F
GfM1OpS1XBpkH4IBK9B6ZXAgJjde1nPwIReeNqhJb7/hFwLiNTrkEir0f8ed1Pg=
=U2Ow
-END PGP SIGNATURE-

bug#22078: failed builds due to exceeding max-silent-time not marked as failed in db

[Florian Paul Schmidt]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256


Hi,

on my system bulding the derivation for the package tbb (version
4.3.2) does not complete due to exceeding the max-silent-time default
value of 3600 seconds (one hour).

It seems that in this case the path is not marked as failed in the
sqlite3 db

/var/guix/db/db.sqlite

in the table FailedPaths. This is quite annoying since it seems that
several packages depend on it causing the derivation to be built
several times (each taking over an hour to fail).

The guix daemon is running with the --cache-failures option and I
would expect the second run of

for n in `guix package -A | cut -f1`; do guix build --no-substitutes
"$n" || true; done

to be mostly a NOOP, since all failures from the first run should be
cached. And even in the first run I wouldn't expect failed
dependencies to be tried to build again. Contrary to this on this box
even the second run of this takes about half a day or so to complete ;)

Flo

P.S.: FYI: The thing that takes over an hour to run is

./test_atomic.exe


- -- 
https://fps.io
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQEcBAEBCAAGBQJWX2qaAAoJEA5f4Coltk8ZnasH/jOg+E0Y/CDxw5SGgcJN0Q6K
TYo41AVz0u9tLJEVYW4ZW9Z7A3UL5OTB+03LwC1zT7iDtFzU6a7BzaW2N3gP+GGi
Tx+Rq0z7ZIHEF1t71YFtPOAIpuyxwl1yMnRo0kd8BVsrNu843ITI4w+kzGV4tcP1
l9uDf7c+WQ8MFhoMDUqjW5ufIb3zy6yKk1GDXw14xZ8laeiE8hrXFE2LFV4WCxzP
VMPDgHBlPF6pAKLYpWSpL2RtL/WxO9tYIYpQ16EW7GjOouCy2ObT+1CJ75kSIOie
DZ/RLUSxa39amDFwii5liR+ETgvz3FCoBAcyI5AP/76uMToub1z3S1PNt58EnsE=
=Hivd
-END PGP SIGNATURE-

bug#22078: failed builds due to exceeding max-silent-time not marked as failed in db

[Florian Paul Schmidt]

Attached is a first stab at fixing this. There are additional options to 
guix-daemons now:


  --cache-failures   cache build failures
  --cache-hook-failures  cache build failures due to hook failures 
(depends

 on cache-failures)
  --cache-timeout-failures   cache build failures due to timeouts 
(depends

 on cache-failures)

Patch compiles, but is yet untested since the system I need it has gone 
away for the time being..


Flo

On 12/02/2015 11:03 PM, Florian Paul Schmidt wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256


Hi,

on my system bulding the derivation for the package tbb (version
4.3.2) does not complete due to exceeding the max-silent-time default
value of 3600 seconds (one hour).

It seems that in this case the path is not marked as failed in the
sqlite3 db

/var/guix/db/db.sqlite

in the table FailedPaths. This is quite annoying since it seems that
several packages depend on it causing the derivation to be built
several times (each taking over an hour to fail).

The guix daemon is running with the --cache-failures option and I
would expect the second run of

for n in `guix package -A | cut -f1`; do guix build --no-substitutes
"$n" || true; done

to be mostly a NOOP, since all failures from the first run should be
cached. And even in the first run I wouldn't expect failed
dependencies to be tried to build again. Contrary to this on this box
even the second run of this takes about half a day or so to complete ;)

Flo

P.S.: FYI: The thing that takes over an hour to run is

./test_atomic.exe


- -- 
https://fps.io

-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQEcBAEBCAAGBQJWX2qaAAoJEA5f4Coltk8ZnasH/jOg+E0Y/CDxw5SGgcJN0Q6K
TYo41AVz0u9tLJEVYW4ZW9Z7A3UL5OTB+03LwC1zT7iDtFzU6a7BzaW2N3gP+GGi
Tx+Rq0z7ZIHEF1t71YFtPOAIpuyxwl1yMnRo0kd8BVsrNu843ITI4w+kzGV4tcP1
l9uDf7c+WQ8MFhoMDUqjW5ufIb3zy6yKk1GDXw14xZ8laeiE8hrXFE2LFV4WCxzP
VMPDgHBlPF6pAKLYpWSpL2RtL/WxO9tYIYpQ16EW7GjOouCy2ObT+1CJ75kSIOie
DZ/RLUSxa39amDFwii5liR+ETgvz3FCoBAcyI5AP/76uMToub1z3S1PNt58EnsE=
=Hivd
-END PGP SIGNATURE-





From 3e376f7d22a62c19491d830c34182f2f4828f0a3 Mon Sep 17 00:00:00 2001
From: Florian Paul Schmidt 
Date: Fri, 4 Dec 2015 23:37:13 +0100
Subject: [PATCH] guix-daemon: cache more failures if requested

---
 nix/libstore/build.cc |  8 
 nix/libstore/globals.cc   |  4 
 nix/libstore/globals.hh   |  6 ++
 nix/nix-daemon/guix-daemon.cc | 12 
 4 files changed, 30 insertions(+)

diff --git a/nix/libstore/build.cc b/nix/libstore/build.cc
index efe1ab2..48936f9 100644
--- a/nix/libstore/build.cc
+++ b/nix/libstore/build.cc
@@ -1483,12 +1483,20 @@ void DerivationGoal::buildDone()
 if (settings.printBuildTrace)
 printMsg(lvlError, format("@ build-failed %1% - timeout") % 
drvPath);
 worker.timedOut = true;
+
+if (settings.cacheFailure && settings.cacheTimeoutFailure)
+foreach (DerivationOutputs::iterator, i, drv.outputs)
+worker.store.registerFailedPath(i->second.path);
 }
 
 else if (hook && (!WIFEXITED(status) || WEXITSTATUS(status) != 100)) {
 if (settings.printBuildTrace)
 printMsg(lvlError, format("@ hook-failed %1% - %2% %3%")
 % drvPath % status % e.msg());
+
+if (settings.cacheFailure && settings.cacheHookFailure)
+foreach (DerivationOutputs::iterator, i, drv.outputs)
+worker.store.registerFailedPath(i->second.path);
 }
 
 else {
diff --git a/nix/libstore/globals.cc b/nix/libstore/globals.cc
index 07f23d4..7829c1c 100644
--- a/nix/libstore/globals.cc
+++ b/nix/libstore/globals.cc
@@ -48,6 +48,8 @@ Settings::Settings()
 compressLog = true;
 maxLogSize = 0;
 cacheFailure = false;
+cacheTimeoutFailure = false;
+cacheHookFailure = false;
 pollInterval = 5;
 checkRootReachability = false;
 gcKeepOutputs = false;
@@ -158,6 +160,8 @@ void Settings::update()
 _get(compressLog, "build-compress-log");
 _get(maxLogSize, "build-max-log-size");
 _get(cacheFailure, "build-cache-failure");
+_get(cacheTimeoutFailure, "build-cache-timeout-failure");
+_get(cacheHookFailure, "build-cache-hook-failure");
 _get(pollInterval, "build-poll-interval");
 _get(checkRootReachability, "gc-check-reachability");
 _get(gcKeepOutputs, "gc-keep-outputs");
diff --git a/nix/libstore/globals.hh b/nix/libstore/globals.hh
index c17e10d..bf8666a 100644
--- a/nix/libstore/globals.hh
+++ b/nix/libstore/globals.hh
@@ -170,6 +170,12 @@ struct Settings {
 /* Whether to cache build failures. */
 bool cacheFailure;
 
+/* Whether to cache timeout failures */
+bool cacheTimeoutFailure;
+
+/* Whether to c

bug#22094: jack2: jack_control uses wrong python version

[Florian Paul Schmidt]

jack_control needs to be run with python2:

fps@cherry ~/src/guix$ jack_control ep
  File "/home/fps/.guix-profile/bin/jack_control", line 80
print 'shit'

[sic]

The interpreter shebang points to a python3.4 though

#!/gnu/store/l9vhjpqza8piap4r047m5xfz86wnxgqw-python-wrapper-3.4.3/bin/python

name_base = 'org.jackaudio'
control_interface_name = name_base + '.JackControl'

Flo

bug#22094: jack2: jack_control uses wrong python version

[Florian Paul Schmidt]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 12/05/2015 09:55 AM, Ricardo Wurmus wrote:
> I’m pretty sure that this was fixed with commit 
> bc8bf605fcef7d9e8a7732caa0fd54604304635b.  Are you using the
> latest version?

Yes, no :)

Thanks!

Flo


- -- 
https://fps.io
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQEcBAEBCAAGBQJWYqm2AAoJEA5f4Coltk8ZGMEH/RDZ+GpK4V3u4WF/AbZW15XQ
+Xu3txRG08XIi/ro3EPxHbNcfrS8wa0rodywBplYTR44f966eSUEwmaOkS999CTj
3IaLe4QdHVtsjUN52Z5C1efvn8k1E7ZF8Jf+SozetZp0HOTT0gy8Ml9pR24jJqiA
mKkuQVvi7LhxwsfDwZWMkx2PuspF6tjtyrTSgsy2GAjjwqoBMr/Kbb9fE4vt0XUV
btVR+m/I32Z+OoA0u648ZL88vOO/NKYKmqgpg/5H83iuYq3MJR0hvNnb+KTqteue
FSNuzu0PSdOPmPIS4F+ICEJ7p5kczn7OU9oNkfPBQoJr+Tr61SUS1cRcKzHoV0Y=
=k00L
-END PGP SIGNATURE-

bug#22078: failed builds due to exceeding max-silent-time not marked as failed in db

[Florian Paul Schmidt]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 14.12.2015 00:11, Ludovic Courtès wrote:

> OK.  I’m unsure whether it makes sense to cache failures due to
> timeout because, by definition, they’re non-deterministic.

Except for cases where they are deterministic (Consider a buggy
package that has a testcase that reduces to while (true) { } that is
not optimized away). They very seldom are though. Ayways: I'm not
proposing to make any of this the default.

> Another problem is that clients can choose what the timeout is
> (both max-silent-time and absolute max-time), so it’d be easy for a
> client to force a timeout failure; on a multi-user system, that
> would amount to a DoS attack.

You mean a user just builds all packages with a timeout that's
impossible to fulfill? And consequently all their failures will be
cached and if then another user tries to build them they just get the
cached failure? That points out another (though more contrived) flaw
indeed:

Even without caching failures a package might be nondeterministic for
some reason (bugs always happen). A user who knows how to trigger the
failure (assuming it's depending on something under the user's
control) then could DOS that particular build.

In general it would probably be good to have a way of resetting the
cached failures in the db. Maybe --check does almost this: If a failed
derivation gets built again with --check will the subsequent success
overwrite the failed one and remove the entry from the FailedPaths
table? Or will --check just happily report that the build is
nondeterministic?

> 
> I’m not sure how to address these issues, so I’m rather in favor of
> the status quo.

I found that the changes I made don't seem to work correctly anyways.
So LNGTMUAC (let's not get that merged under any circumstances).

Flo

- -- 
https://fps.io
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQEcBAEBCAAGBQJWboAmAAoJEA5f4Coltk8Zhe4H/2B8jFpvjyTCn87eRoPCVjYV
3bHgjl/WXByrei93l65q+TY+IxFxA66p1Q9GV/cBoj7k/gkFxylUamaqw0wbQEbm
yohD0G7YnKpywXCLp1pwJeFeBUGmAe/F0Fw4G45OGcAeIQ7AbDZRHmYq4KRe9x1q
i0n96plAirsy5zvBY88bdZU8Fbc4c8pm1Mw2e8B9i3EEWjwcXh8UWeuerTKHhMK4
KNtxgX+Wnx05ZmzOnM3yJKOM8qgujW4peYhVJl3SRAMv/5kLFVCOOUC3XbsijdMM
8ny68tXgE5pNtfHsGko/rqwBT/LQ0C94zO+ggkitd51sgLFKXMRdt+j9pmDLfS0=
=ZFzw
-END PGP SIGNATURE-

bug#22176: operating-system entry file-system should have auto-mount? flag

[Florian Paul Schmidt]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256


So the user can specify file systems _not_ to be mounted at boot but
at a later point in time at will.

Regards,
Florian Schmidt

- -- 
https://fps.io
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQEcBAEBCAAGBQJWb+SxAAoJEA5f4Coltk8Zcz8IAI54qGgpocPqW8+oEIwe+XUF
jeBDs+k3UCmJJVy78R6njXZbWlta70RxFFzMs2APNJKBtRcz7Zao/LcJl8s3Eire
QW58Esig6fqkXDzRCV/EpbmOoxZ3RYjKtjPdemhqjB4FHVVMkl4Qm3L6XULNT3Mz
o6UZQHGbKhjynQhRM685fPk1n9AQowAiUkFz2hArnOzYZDhHMqTtb64OSJKsjU4E
QR25OeBJ7eWhsb3QFiaMybZg43+9QxHaF2DqDBXsHW03uk0heO+k/hEg+X2WO976
doz9wi614n3j2z7z8TCwk66A6WoFWpeNHsj/7yjnbBrWTYL5xtktbuuYFaPHKL4=
=eM+N
-END PGP SIGNATURE-

bug#22209: name resolution failures in installer image

[Florian Paul Schmidt]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256


Hi,

this occurs over and over to me and I saw other people's reports on
IRC, too:

After booting the installer image, doing the ifconfig/dhclient dance,
preparing the target fs, mounting it and starting the guix system init
invocation at some point in time, though not predictably so, but
usually after a couple of minutes (about 10 or so) name resolution
will start to fail causing guix system init to fail.

killall dhclient; dhclient 

and a subsequent invocation to guix system init will make the
installation continue and usually succeed.

On the first few occasions it seemed to me that my local network could
be at fault, but it's _almost_ reliably reproducable in qemu,
virtualbox and even on bare metal and is not limited to myself (check
the channel logs with some good search queries).

So it might be worth looking into.

The installed system does not have this problem after a reboot.

Regards,
Flo

- -- 
https://fps.io
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQEcBAEBCAAGBQJWdQ+YAAoJEA5f4Coltk8ZgdoIAJ9rDLDhTztcfs4fHWBF+mcf
U6SYAX36nc7R+TiT7FCWQVxcp38bG5LrTInmP4C/ojyPHEYZcMQLQg2CoT4/q6Ys
kjMUKvBgFqMsjeZzvo9oXP1VDWygC9YeCg55BGPzpEW5x3oQHcVH0zw8acNrlZ6A
I9sVoQnaEDKhsNECBwPDMNujqjik6TilvddEl0AS7HYCbyNgPy+dR97G5z+gRt8w
Wrio0ua5QeyAW5kFCLX7LdDa44OBPoiAlLyWa9dXgFUOORgh88z/dtCPbV0vRNJc
FKpVmAzcovximrPGgDXs9DzERaSkROM05GGRb/uYFfs5GdoGja5YwjXcoWaHUzo=
=9+XX
-END PGP SIGNATURE-

bug#22209: name resolution failures in installer image

[Florian Paul Schmidt]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 19.12.2015 19:09, Ludovic Courtès wrote:

> However, nscd is reportedly behaving strangely: 
> .
> 
> Do you initially get successful lookups for hydra.gnu.org, and 
> eventually lookup failures?

Yes, that's at least in my case precisely what happens. It works for
the first few packages during system init, and then at some point in
time fails.

I'll try to reproduce and then restart the nscd to see if it helps
(when I find time to do it)..

Flo


- -- 
https://fps.io
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQEcBAEBCAAGBQJWdn8QAAoJEA5f4Coltk8ZrSIH/3YKmBO2ZDCqxxZGWYJDRgQc
Q74OFkSrw56ov29uSU+Xs63njem19PLxyECLoICex2tOMOuELpowKt0ee8hS/7PT
eYyRlMiUfIk4WC2qpFGQtfURDOmsAiWCGP2LzBO1RqhgU5CtgnChH5Z7ZVmlNloy
EqVKZ0tpquagf1k6FkMsk65fY6gPa2D+2Ova1SkwtEiIRwMDMNkguadHXu9LShKu
9fSOnP7BXwAZfPC6hPyrB8tjUWtr8PUlzYNsLsW6PTqtRNry5QSSa2I4wsx9Gjse
HQ3NeRjp3RPvOx/LwP5+nGaTsUN8R8aPSX3eMumpBfzrImLqANExhcOvkFtkL6U=
=R54m
-END PGP SIGNATURE-

bug#22215: guix package fails to use more than the first substitute server in case of 404 failure

[Florian Paul Schmidt]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256


guix package --substitute-urls="http://fps.io:
http://hydra.gnu.org"; -i emacs

fails due to

http://debbugs.gnu.org/cgi/bugreport.cgi?bug=21888

with a 404 and consequently fails to try hydra for the download after
the download from fps.io failed.

Regards,
Flo

- -- 
https://fps.io
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQEcBAEBCAAGBQJWdyBUAAoJEA5f4Coltk8Zxr0H/2rYvNj9tUifhM6A1kPCT48A
y8pSYn33dRDToCjJmZf74X6i0qrULohv0npX2wgfI1AY/fzO0lXrWNtqK2KhcGcK
8KPxNzAdCUgu/Ekx/OIRn2LD/PtvFHcWDkIW4rVuCUNKA/A2VB8GCca8ZLDai9EW
vSf9VWG+5MtZ/wbwU6Ec3sY+5fX2RCTlNIs++HmD+6/jSmigXP4mQyvXd2h+WABM
DTs8URtvONataGYiLWjuRmqYUaMhYukdJZJ980XjTHr38uCCltavthL3RumWp0L8
kJcsbb2Zi9W/T7O5ILk4K9615TISCtmHjVIBzejwJBpI8W171vvXzM8Oid5/xz0=
=FIZ/
-END PGP SIGNATURE-

bug#22687: Online manual not updated automatically

[Florian Paul Schmidt]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 16.02.2016 17:42, Andreas Enge wrote:
> On Tue, Feb 16, 2016 at 05:33:27PM +0100, Ricardo Wurmus wrote:
>> I was not courageous enough to suggest that, but this does sound
>> like a good idea.
> 
> It is easy enough to have that courage when one is not the person
> making the releases :-)

Hmm, shouldn't that process be mostly automated? And if not, maybe
it's worth thinking about how to do that. I guess from a functional
point of view a release is just a function that takes a revision and
has as its outputs installer images, binary installers, a new website,
yada yada yada..

Regards,
Flo


- -- 
https://fps.io
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQEcBAEBCAAGBQJWw1kKAAoJEA5f4Coltk8Z/6sH/1CuqcAbB+RC/b4bmyBkSJ0z
SlJBjkfs9BUxLtjzLXMn52t0dKOmA92CiVpZblTxb0M3rcruOY44Wlkc3J5PqP3U
Aqh+YzrowqKHBi+iikftiJYj9X7beh7rWxmM48nWkdtPTfLUYdbi5+AJtz7bwvQ8
ZHx5wilEVaUnXKyiora3V2Nm8bjGQXIfncvQy7rrON2XaNZut8ruIAI0FSn8F4xD
WPWP5tuTTdHJNCOSmsPr1kM2kmoBZ3hDs4BeJWbiTUMJTsh3G/P+z1XUBuoS3zWJ
CwYrTwZzulq9JTP10JdMOEBcoZ9/za3cpiHM2n8rA1CEpVKRKM/s9tnKZjl+oZ8=
=ODkW
-END PGP SIGNATURE-

bug#23072: GuixSD SSD install hangs at clocksource

[Florian Paul Schmidt]

On 20.03.2016 20:56, myglc2 wrote:

> - I did a near-identical install to a SSD (Kingston ssdnow300), see
>   "c06system-ssd.scm.log". If installed on the 1st server this shows
>   Guix welcome screen, loads the keyboard & mouse drivers, then hangs
>   showing:
> 
>   "clocksource: Switched to clocksource tsc"

This is just a shot in the dark, but I use SSD systems, too, and I
noticed that the first boot of a guixsd installation hangs for a while
collecting entropy before displaying a corresponding message IIRC and I
faintly remember the "switching to clocksource" message. Did you try
banging the keyboard? Maybe that's not possible on a headless server
though. Did you let it sit for a while?

Flo


-- 
https://fps.io



signature.asc
Description: OpenPGP digital signature

bug#28393: Sound output broken in Audacity

[Florian Paul Schmidt]

Hi,

what ALSA pcm device have you configured Audacity to use? From the log 
it looks like it tries to use some pcm devices that are commonly 
configured in a global alsa.conf (on ubuntu for example in 
/usr/share/alsa/alsa.conf (.d). Possibly you do not have these global 
definitions available?


Does using "hw:0,0" work if set as pcm device in the audacity config?

Regards,
Flo

P.S.: I'm not using guix ATM, so I have no idea on where the guix ALSA 
packages would store global configs, etc..


On 08.09.2017 18:24, Mark H Weaver wrote:

Sound output is broken in Audacity on my Thinkpad X200 running GuixSD,
at least within GNOME 3 (I haven't tried it anywhere else).  It worked
in the past.  I see the following error messages in Audacity's
stdout/stderr:

(audacity:893): Gtk-WARNING **: Unable to locate theme engine in module_path: 
"adwaita",

(audacity:893): Gtk-WARNING **: Unable to locate theme engine in module_path: 
"adwaita",
ALSA lib pcm.c:2501:(snd_pcm_open_noupdate) Unknown PCM cards.pcm.rear
ALSA lib pcm.c:2501:(snd_pcm_open_noupdate) Unknown PCM cards.pcm.center_lfe
ALSA lib pcm.c:2501:(snd_pcm_open_noupdate) Unknown PCM cards.pcm.side
ALSA lib pcm_route.c:867:(find_matching_chmap) Found no matching channel map
ALSA lib pcm_route.c:867:(find_matching_chmap) Found no matching channel map
ALSA lib pcm_route.c:867:(find_matching_chmap) Found no matching channel map
ALSA lib pcm_route.c:867:(find_matching_chmap) Found no matching channel map
Expression 'stream->playback.pcm' failed in 'src/hostapi/alsa/pa_linux_alsa.c', 
line: 4628
Expression 'stream->playback.pcm' failed in 'src/hostapi/alsa/pa_linux_alsa.c', 
line: 4628
Expression 'stream->playback.pcm' failed in 'src/hostapi/alsa/pa_linux_alsa.c', 
line: 4628

Mark

bug#30032: https://www.gnu.org/software/guix/contact/ misses link to mailman interface of bug-guix

[Florian Paul Schmidt]

The contact page on the guix website lists links to the mailman 
interfaces of all mailing lists except for bug-guix.


Flo

bug#47492: texlive: texlua fails to run

[Paul A. Patience]

Hello,

With Guix 9feef62b73e284e106717a386624d6da90750a3d, texlua (from the
texlive package) fails to run (even if I install zziplib):

/gnu/store/nwqgyc69hrakjcrqd0ydc8zbwh5q6zka-texlive-bin-20190410/bin/texlua:
error while loading shared libraries: libzzip-0.so.13: cannot open
shared object file: No such file or directory

Best regards,
Paul

bug#61555: Failed install : installer-dump-8deefb3d

[Paul Connelly (Student)]

Good day,

Just trying to install Guix as a standalone OS , core i5 4460, on SSD, graphics 
intel 460. I have submitted  installer-dump-8deefb3d. I hope it helps.

Regards



paul connelly

M101(1993), M205(1994),M261(2003),
S151(2005), S207(2005), S154(2007),
S104(2008), M150(2009), MST121(2010),
TU100(2014), TM129(2014), M250(2017)
M269(2018), T227(2020), MST125(2021).
MST210(to date)
---
Cert. Computing & Mathematics – C50 (2011),
Cert. Natural Sciences – C26 (2008),
BSc Open (to date)

[PastedGraphic-3.png]

---
The cat is most uncertainly alive
##

bug#61555: Failed install : installer-dump-8deefb3d

[Paul Connelly (Student)]

Dear Ludo’,

Thank you for your response and walking me through the log file 

I can confirm my homer-simpson-style error as being not using the 64bit OS..

The system is installed and the install process was a very different and 
enjoyable experience :)

Thank you .

Paul.

> On 24 Feb 2023, at 11:09, Ludovic Courtès  wrote:
> 
> Hi Paul,
> 
> "Paul Connelly (Student)"  skribis:
> 
>> Just trying to install Guix as a standalone OS , core i5 4460, on SSD, 
>> graphics intel 460. I have submitted  installer-dump-8deefb3d. I hope it 
>> helps.
> 
> It’s perfect, thank you for reporting the problem.
> 
> The system log in that dump shows that ‘guix system init’ ended up
> building Rust and gnome-system-monitor (instead of downloading pre-built
> binaries), and it failed to build Rust, which is one of these
> dependencies:
> 
> --8<---cut here---start->8---
> Feb 16 17:28:45 localhost vmunix: [0.00] Linux version 6.0.10-gnu 
> (guix@guix) (gcc (GCC) 10.3.0, GNU ld (GNU Binutils) 2.37) #1 SMP 
> PREEMPT_DYNAMIC 1
> […]
> Feb 16 17:33:51 localhost installer[381]: running command ("guix" "system" 
> "init" "--fallback" "/mnt/etc/config.scm" "/mnt") 
> Feb 16 17:34:04 localhost installer[381]: substitute:  
> Feb 16 17:34:07 localhost installer[381]: substitute: ^[[Kupdating 
> substitutes from 'https://ci.guix.gnu.org'...   0.0% 
> Feb 16 17:34:07 localhost installer[381]: substitute: ^[[Kupdating 
> substitutes from 'https://ci.guix.gnu.org'...   0.3% 
> Feb 16 17:34:07 localhost installer[381]: substitute: ^[[Kupdating 
> substitutes from 'https://ci.guix.gnu.org'...   0.6% 
> […]
> Feb 16 17:34:10 localhost installer[381]: substitute: ^[[Kupdating 
> substitutes from 'https://bordeaux.guix.gnu.org'...  98.9% 
> Feb 16 17:34:10 localhost installer[381]: substitute: ^[[Kupdating 
> substitutes from 'https://bordeaux.guix.gnu.org'... 100.0% 
> Feb 16 17:34:10 localhost installer[381]:  
> Feb 16 17:34:11 localhost installer[381]: ^[[1m27.1 MB will be downloaded 
> […]
> Feb 16 17:36:13 localhost installer[381]: substitute: ^[[Kupdating 
> substitutes from 'https://ci.guix.gnu.org'...  91.9% 
> Feb 16 17:36:13 localhost last message repeated 2 times
> […]
> Feb 16 17:36:34 localhost installer[381]: substitute: ^[[Kupdating 
> substitutes from 'https://bordeaux.guix.gnu.org'... 100.0% 
> Feb 16 17:36:34 localhost installer[381]:  
> Feb 16 17:36:38 localhost installer[381]: ^[[1;35mThe following derivations 
> will be built: 
> Feb 16 17:36:38 localhost installer[381]:  
> Feb 16 17:36:38 localhost installer[381]: ^[[0m  
> ^[[2m/gnu/store/d7y2ws6khc3vwxig10ransz2rjm2r4rn-^[[0mgnome-system-monitor-42.0.drv
>  
> Feb 16 17:36:38 localhost installer[381]:  
> Feb 16 17:36:38 localhost installer[381]:   
> ^[[2m/gnu/store/9c6piv330wp9ph7df68n80ig0f8zj99n-^[[0mlibrsvg-2.50.7.drv 
> Feb 16 17:36:38 localhost installer[381]:  
> Feb 16 17:36:38 localhost installer[381]:   
> ^[[2m/gnu/store/ndd85agyp1r75q98ljmjy7nvys4m7gpa-^[[0mrust-1.60.0.drv 
> Feb 16 17:36:38 localhost installer[381]:  
> Feb 16 17:36:38 localhost installer[381]:   
> ^[[2m/gnu/store/64q9r8mq6ak4jpriswq61g3n6cdhd1mk-^[[0mrust-1.59.0.drv 
> Feb 16 17:36:38 localhost installer[381]:  
> Feb 16 17:36:38 localhost installer[381]:   
> ^[[2m/gnu/store/ik7ifm27ypaab1c2q7amawc6cwap3is3-^[[0mrust-1.58.1.drv 
> Feb 16 17:36:38 localhost installer[381]:  
> Feb 16 17:36:38 localhost installer[381]:   
> ^[[2m/gnu/store/5c88c47v73imc88gqhn8b9bls75f27dq-^[[0mrust-1.57.0.drv 
> Feb 16 17:36:38 localhost installer[381]:  
> Feb 16 17:36:38 localhost installer[381]:   
> ^[[2m/gnu/store/f8a0l2ivqsascss7g1zabq3bizn1g7va-^[[0mrust-1.56.1.drv 
> Feb 16 17:36:38 localhost installer[381]:  
> Feb 16 17:36:38 localhost installer[381]:   
> ^[[2m/gnu/store/5gghj8m2ppnwk9nj7fx1a53fri2qg17g-^[[0mrust-1.55.0.drv 
> Feb 16 17:36:38 localhost installer[381]:  
> Feb 16 17:36:38 localhost installer[381]:   
> ^[[2m/gnu/store/lh7ra87mjhbr14rr6scm3yiyc0i5sps9-^[[0mrust-1.54.0.drv 
> Feb 16 17:36:38 localhost installer[381]:  
> Feb 16 17:36:38 localhost installer[381]:   
> ^[[2m/gnu/store/f4x2s9g8gcdcjjcrbj810qmpnydy3yrp-^[[0mgnome-control-center-42.4.drv
>  
> […]
> Feb 16 17:45:09 localhost installer[381]: ^[[Kbuilding 
> /gnu/store/lh7ra87mjhbr14rr6scm3yiyc0i5sps9-rust-1.54.0.drv... 
> […]
> Feb 16 18:50:22 localhost installer[25727]: ^[[K- 'build' phase 
> Feb 16 18:50:24 localhost installer[25727]: ^[[K\ 'build' phasebuilder for 
> `/gnu/store/lh7ra87mjhbr14rr6scm3yiyc0i5sps9-rust-1.54.0.drv' fail

bug#50536: Gem import should wrap description lines

[Stephen Paul Weber]

Since guix lint has a line-length preference, the generated packages should have
their description strings wrapped to conform to this preference.


signature.asc
Description: PGP signature

bug#50595: Faliure in guix import go

[Stephen Paul Weber]

$ guix import go -r bdd.fi/x/runitor

guix import: warning: Failed to import package "bdd.fi/x/runitor".
reason: ("struct-vtable" "Wrong type argument in position 1 (expecting struct): 
~S" (#f) (#f)).


signature.asc
Description: PGP signature

bug#50596: Cannot get guix copy to work...

[Stephen Paul Weber]

$ guix copy --to=SERVER package

guix copy: sending 72 store items (203 MiB) to 'SERVER'...
guix copy: error: corrupt input while restoring archive from #


This is what I get no matter what package I try to send.  Any idea what could be
going wrong?


signature.asc
Description: PGP signature

bug#50595: Failure in guix import go

[Stephen Paul Weber]

Getting a similar failure here:

$ guix import go github.com/cncf/udpa/go/

following redirection to 
`https://proxy.golang.org/github.com/cncf/udpa/go/@v/list'...
following redirection to 
`https://proxy.golang.org/github.com/cncf/udpa/go/@latest'...
following redirection to 
`https://proxy.golang.org/github.com/cncf/udpa/go/@v/v0.0.0-20210322005330-6414d713912e.mod'...
guix import: warning: Failed to import package "github.com/cncf/udpa/go/".
reason: ("vector-ref" "Wrong type argument in position 1 (expecting vector): 
~S" (#f) (#f)).
guix import: error: failed to download meta-data for module 
'github.com/cncf/udpa/go/'


signature.asc
Description: PGP signature

bug#50596: Cannot get guix copy to work...

[Stephen Paul Weber]

It seems I get the same error even with just guix archive:

$ guix archive --export -r package

... snip lots of output ...

entry(nameunitnode(type 
directoryentry(namepromise_spec.rbnode(typeregulacontents�nguix archive: error: 
corrupt input while restoring archive from #


signature.asc
Description: PGP signature

bug#50596: Cannot get guix copy to work...

[Stephen Paul Weber]

Ah, finally found http://issues.guix.gnu.org/43739 -- guix pull as root and all 
fixed.


signature.asc
Description: PGP signature

bug#50613: guix copy does not respect --no-grafts

[Stephen Paul Weber]

If I use guix archive --export --no-grafts then import on another system, then
guix build -n --no-grafts it works as expected.  If instead I use guix copy
--no-grafts then the target system gets the version *with* grafts and guix build
-n --no-grafts says it would still need to build.


signature.asc
Description: PGP signature

bug#50596: Cannot get guix copy to work...

[Stephen Paul Weber]

Thanks for the follow up.
Does it mean this bug can be closed?


Yes, thanks.

bug#52362: guix import go error

[Stephen Paul Weber]

$ guix import go github.com/Azure/go-autorest/autorest

guix import: warning: Failed to import package 
"github.com/Azure/go-autorest/autorest".
reason: (#< code: -3 message: "reference 'refs/tags/v0.11.22' not 
found" class: 4>).
guix import: error: failed to download meta-data for module 
'github.com/Azure/go-autorest/autorest'.

Similarly:

$ guix import go github.com/Azure/go-autorest/autorest/adal

guix import: warning: Failed to import package 
"github.com/Azure/go-autorest/autorest/adal".
reason: (#< code: -3 message: "reference 'refs/tags/v0.9.17' not found" 
class: 4>).
guix import: error: failed to download meta-data for module 
'github.com/Azure/go-autorest/autorest/adal'.

And, from a different package but seems also similar:

$ guix import go cloud.google.com/go/storage

guix import: warning: Failed to import package "cloud.google.com/go/storage".
reason: (#< code: -3 message: "reference 'refs/tags/v1.18.2' not found" 
class: 4>).
guix import: error: failed to download meta-data for module 
'cloud.google.com/go/storage'.


signature.asc
Description: PGP signature

bug#53064: pioneer FTBFS

[Stephen Paul Weber]

Hello,

Today I tried to `guix install pioneer` and it seems there is no substitute.  It
very quickly fails to build from source with this error in log:

-- Checking for module 'sigc++-2.0'
--   No package 'sigc++-2.0' found
CMake Error at 
/gnu/store/aain9m7r37jlzd21kvgvrkhc2pm7mk1w-cmake-minimal-3.21.3/share/cmake-3.21/Modules/FindPkgConfig.cmake:562
 (message):
  A required package was not found


signature.asc
Description: PGP signature

bug#53064: Already fixed

[Stephen Paul Weber]

A push to master right after I filed this has fixed it already.


signature.asc
Description: PGP signature

bug#52362: guix import go error

[Stephen Paul Weber]

Ran into another like this today:

guix import go github.com/aws/aws-sdk-go-v2/service/s3

Gives:

Backtrace:
  14 (primitive-load "/gnu/store/6rjb4c80l53n98cl6h0s3q1zmkg…")
In guix/ui.scm:
   2209:7 13 (run-guix . _)
  2172:10 12 (run-guix-command _ . _)
In guix/scripts/import.scm:
   124:11 11 (guix-import . _)
In ice-9/boot-9.scm:
  1752:10 10 (with-exception-handler _ _ #:unwind? _ # _)
In guix/scripts/import/go.scm:
   116:29  9 (_)
In ice-9/exceptions.scm:
   406:15  8 (go-module->guix-package* . _)
In ice-9/boot-9.scm:
  1752:10  7 (with-exception-handler _ _ #:unwind? _ # _)
In guix/import/go.scm:
   519:18  6 (go-module->guix-package "github.com/aws/aws-sdk-go-v2…" …)
In guix/git.scm:
277:4  5 (update-cached-checkout _ #:ref _ #:recursive? _ # _ # _ …)
   266:18  4 (resolve _)
In git/reference.scm:
 60:8  3 (_ _ _)
In git/bindings.scm:
 77:2  2 (raise-git-error _)
In ice-9/boot-9.scm:
  1685:16  1 (raise-exception _ #:continuable? _)
  1683:16  0 (raise-exception _ #:continuable? _)

ice-9/boot-9.scm:1683:16: In procedure raise-exception:
Git error: reference 'refs/tags/v1.23.0' not found


signature.asc
Description: PGP signature

bug#52362: guix import go error

[Stephen Paul Weber]

Alright, I think I have found the issue.  https://go.dev/ref/mod says:


If a module is defined in a subdirectory within the repository, that is,
the module subdirectory portion of the module path is not empty, then each
tag name must be prefixed with the module subdirectory, followed by a slash.
For example, the module golang.org/x/tools/gopls is defined in the gopls
subdirectory of the repository with root path golang.org/x/tools. The version
v0.4.0 of that module must have the tag named gopls/v0.4.0 in that repository.


Right now the importer code assumes that either we have a pseudo version (and
thus can extract a raw commit hash) or else that the tag will be exactly
(string-append "v" version) but this does not take into account the rule about
subdirectory packages.


signature.asc
Description: PGP signature

bug#52362: [PATCH] guix: import: go: Use correct tag for go module in subdirectory.

[Stephen Paul Weber]

https://go.dev/ref/mod says a module in a subdirectory has a tag prefixed with
the subdirectory.

* guix/import/go.scm (version+subdirectory->tag-name): New variable.
(vcs->origin): New argument module-path-subdirectory.
---
 guix/import/go.scm | 26 +++---
 1 file changed, 15 insertions(+), 11 deletions(-)

diff --git a/guix/import/go.scm b/guix/import/go.scm
index d00c13475a..6fae1994b8 100644
--- a/guix/import/go.scm
+++ b/guix/import/go.scm
@@ -521,28 +521,30 @@ tag."
   `(tag-or-commit . ,reference)
 (file-hash* checkout #:algorithm algorithm #:recursive? #true)))
 
-(define (vcs->origin vcs-type vcs-repo-url version)
+(define (version+subdirectory->tag-name version subdirectory)
+  (if (string=? subdirectory "")
+  version
+  (string-append (substring subdirectory 1) "/" version)))
+
+(define (vcs->origin vcs-type vcs-repo-url module-path-subdirectory version)
   "Generate the `origin' block of a package depending on what type of source
 control system is being used."
   (case vcs-type
 ((git)
- (let ((plain-version? (string=? version (go-version->git-ref version)))
-   (v-prefixed?(string-prefix? "v" version)))
+ (let ((git-commit (if (string=? version (go-version->git-ref version))
+   (version+subdirectory->tag-name
+  version module-path-subdirectory)
+   (go-version->git-ref version
`(origin
   (method git-fetch)
   (uri (git-reference
 (url ,vcs-repo-url)
-;; This is done because the version field of the package,
-;; which the generated quoted expression refers to, has been
-;; stripped of any 'v' prefixed.
-(commit ,(if (and plain-version? v-prefixed?)
- '(string-append "v" version)
- '(go-version->git-ref version)
+(commit ,git-commit)))
   (file-name (git-file-name name version))
   (sha256
(base32
 ,(bytevector->nix-base32-string
-  (git-checkout-hash vcs-repo-url (go-version->git-ref version)
+  (git-checkout-hash vcs-repo-url git-commit
  (hash-algorithm sha256
 ((hg)
  `(origin
@@ -621,6 +623,8 @@ When VERSION is unspecified, the latest version available 
is used."
   (match:prefix (string-match "([\\./]v[0-9]+)?$" module-path)))
  (guix-name (go-module->guix-package-name module-path))
  (root-module-path (module-path->repository-root module-path))
+ (module-path-subdirectory
+   (substring module-path (string-length root-module-path)))
  ;; The VCS type and URL are not included in goproxy information. For
  ;; this we need to fetch it from the official module page.
  (meta-data (fetch-module-meta-data root-module-path))
@@ -634,7 +638,7 @@ When VERSION is unspecified, the latest version available 
is used."
 (name ,guix-name)
 (version ,(strip-v-prefix version*))
 (source
- ,(vcs->origin vcs-type vcs-repo-url version*))
+ ,(vcs->origin vcs-type vcs-repo-url module-path-subdirectory 
version*))
 (build-system go-build-system)
 (arguments
  '(#:import-path ,module-path
-- 
2.30.2

bug#52362: [PATCH] guix: import: go: Use correct tag for go module in subdirectory.

[Stephen Paul Weber]

Somebody claiming to be Stephen Paul Weber wrote:

https://go.dev/ref/mod says a module in a subdirectory has a tag prefixed with
the subdirectory.


Dang.  This patch as written causes import of guix import go
github.com/jackc/pgx/v4 to fail. The /v4 suffix in this case appears to refer to
a branch and not a subdirectory, but the syntax is identical?


signature.asc
Description: PGP signature

bug#52362: [PATCH v2] guix: import: go: Use correct tag for go module in subdirectory.

[Stephen Paul Weber]

https://go.dev/ref/mod says a module in a subdirectory has a tag prefixed with
the subdirectory.

* guix/import/go.scm (version+subdirectory->tag-prefix): New variable.
(vcs->origin): New argument module-path-subdirectory.
---
 guix/import/go.scm | 35 ---
 1 file changed, 24 insertions(+), 11 deletions(-)

diff --git a/guix/import/go.scm b/guix/import/go.scm
index d00c13475a..b6f8686c0d 100644
--- a/guix/import/go.scm
+++ b/guix/import/go.scm
@@ -521,28 +521,37 @@ tag."
   `(tag-or-commit . ,reference)
 (file-hash* checkout #:algorithm algorithm #:recursive? #true)))
 
-(define (vcs->origin vcs-type vcs-repo-url version)
+(define (version+subdirectory->tag-prefix subdirectory)
+  (if (string=? subdirectory "")
+  ""
+  (string-append (substring subdirectory 1) "/")))
+
+(define (vcs->origin vcs-type vcs-repo-url module-path-subdirectory version)
   "Generate the `origin' block of a package depending on what type of source
 control system is being used."
   (case vcs-type
 ((git)
- (let ((plain-version? (string=? version (go-version->git-ref version)))
-   (v-prefixed?(string-prefix? "v" version)))
+ (let* ((plain-version? (string=? version (go-version->git-ref version)))
+(v-prefixed?(string-prefix? "v" version))
+(tag-prefix (version+subdirectory->tag-prefix
+ module-path-subdirectory))
+(git-commit (if plain-version?
+(string-append tag-prefix version)
+(go-version->git-ref version
`(origin
   (method git-fetch)
   (uri (git-reference
 (url ,vcs-repo-url)
-;; This is done because the version field of the package,
-;; which the generated quoted expression refers to, has been
-;; stripped of any 'v' prefixed.
 (commit ,(if (and plain-version? v-prefixed?)
- '(string-append "v" version)
+ (if (string=? module-path-subdirectory "")
+ '(string-append "v" version)
+ `(string-append ,tag-prefix "v" version))
  '(go-version->git-ref version)
   (file-name (git-file-name name version))
   (sha256
(base32
 ,(bytevector->nix-base32-string
-  (git-checkout-hash vcs-repo-url (go-version->git-ref version)
+  (git-checkout-hash vcs-repo-url git-commit
  (hash-algorithm sha256
 ((hg)
  `(origin
@@ -618,9 +627,13 @@ When VERSION is unspecified, the latest version available 
is used."
dependencies+versions
(map car dependencies+versions)))
  (module-path-sans-suffix
-  (match:prefix (string-match "([\\./]v[0-9]+)?$" module-path)))
+   (if (string-prefix? "gopkg.in" module-path)
+   module-path
+   (match:prefix (string-match "([\\./]v[0-9]+)?$" module-path
  (guix-name (go-module->guix-package-name module-path))
- (root-module-path (module-path->repository-root module-path))
+ (root-module-path (module-path->repository-root 
module-path-sans-suffix))
+ (module-path-subdirectory
+   (substring module-path-sans-suffix (string-length 
root-module-path)))
  ;; The VCS type and URL are not included in goproxy information. For
  ;; this we need to fetch it from the official module page.
  (meta-data (fetch-module-meta-data root-module-path))
@@ -634,7 +647,7 @@ When VERSION is unspecified, the latest version available 
is used."
 (name ,guix-name)
 (version ,(strip-v-prefix version*))
 (source
- ,(vcs->origin vcs-type vcs-repo-url version*))
+ ,(vcs->origin vcs-type vcs-repo-url module-path-subdirectory 
version*))
 (build-system go-build-system)
 (arguments
  '(#:import-path ,module-path
-- 
2.30.2

bug#52362: [PATCH v3] guix: import: go: Use correct tag for go module in subdirectory.

[Stephen Paul Weber]

https://go.dev/ref/mod says a module in a subdirectory has a tag prefixed with
the subdirectory.

* guix/import/go.scm (version+subdirectory->tag-prefix): New variable.
(vcs->origin): New argument module-path-subdirectory.
---
 guix/import/go.scm | 36 +---
 1 file changed, 25 insertions(+), 11 deletions(-)

diff --git a/guix/import/go.scm b/guix/import/go.scm
index d00c13475a..f2ea9dbbae 100644
--- a/guix/import/go.scm
+++ b/guix/import/go.scm
@@ -521,28 +521,37 @@ tag."
   `(tag-or-commit . ,reference)
 (file-hash* checkout #:algorithm algorithm #:recursive? #true)))
 
-(define (vcs->origin vcs-type vcs-repo-url version)
+(define (version+subdirectory->tag-prefix subdirectory)
+  (if (string=? subdirectory "")
+  ""
+  (string-append (substring subdirectory 1) "/")))
+
+(define (vcs->origin vcs-type vcs-repo-url module-path-subdirectory version)
   "Generate the `origin' block of a package depending on what type of source
 control system is being used."
   (case vcs-type
 ((git)
- (let ((plain-version? (string=? version (go-version->git-ref version)))
-   (v-prefixed?(string-prefix? "v" version)))
+ (let* ((plain-version? (string=? version (go-version->git-ref version)))
+(v-prefixed?(string-prefix? "v" version))
+(tag-prefix (version+subdirectory->tag-prefix
+ module-path-subdirectory))
+(git-commit (if plain-version?
+(string-append tag-prefix version)
+(go-version->git-ref version
`(origin
   (method git-fetch)
   (uri (git-reference
 (url ,vcs-repo-url)
-;; This is done because the version field of the package,
-;; which the generated quoted expression refers to, has been
-;; stripped of any 'v' prefixed.
 (commit ,(if (and plain-version? v-prefixed?)
- '(string-append "v" version)
+ (if (string=? module-path-subdirectory "")
+ '(string-append "v" version)
+ `(string-append ,tag-prefix "v" version))
  '(go-version->git-ref version)
   (file-name (git-file-name name version))
   (sha256
(base32
 ,(bytevector->nix-base32-string
-  (git-checkout-hash vcs-repo-url (go-version->git-ref version)
+  (git-checkout-hash vcs-repo-url git-commit
  (hash-algorithm sha256
 ((hg)
  `(origin
@@ -618,12 +627,17 @@ When VERSION is unspecified, the latest version available 
is used."
dependencies+versions
(map car dependencies+versions)))
  (module-path-sans-suffix
-  (match:prefix (string-match "([\\./]v[0-9]+)?$" module-path)))
+   (if (string-prefix? "gopkg.in" module-path)
+   module-path
+   (match:prefix (string-match "([\\./]v[0-9]+)?$" module-path
  (guix-name (go-module->guix-package-name module-path))
- (root-module-path (module-path->repository-root module-path))
+ (root-module-path (module-path->repository-root 
module-path-sans-suffix))
  ;; The VCS type and URL are not included in goproxy information. For
  ;; this we need to fetch it from the official module page.
  (meta-data (fetch-module-meta-data root-module-path))
+ (module-path-subdirectory
+   (substring module-path-sans-suffix
+ (string-length (module-meta-import-prefix meta-data
  (vcs-type (module-meta-vcs meta-data))
  (vcs-repo-url (module-meta-data-repo-url meta-data goproxy))
  (synopsis (go-package-synopsis module-path))
@@ -634,7 +648,7 @@ When VERSION is unspecified, the latest version available 
is used."
 (name ,guix-name)
 (version ,(strip-v-prefix version*))
 (source
- ,(vcs->origin vcs-type vcs-repo-url version*))
+ ,(vcs->origin vcs-type vcs-repo-url module-path-subdirectory 
version*))
 (build-system go-build-system)
 (arguments
  '(#:import-path ,module-path
-- 
2.30.2

bug#62765: Python importer gets confused about network access

[Stephen Paul Weber]

Trying `guix import pypi -r gruut` I get:

Starting download of /tmp/guix-file.hITnlA
From 
https://files.pythonhosted.org/packages/74/67/3008e4f0b97d9a5701c8ef3bf95f1941c5b0a620c8f88f32e849117f8dc0/num2words-0.5.12.tar.gz...
In procedure connect: Network is unreachable

But doing `guix import pypi -r num2words` works fine.


signature.asc
Description: PGP signature

bug#62765: Python importer gets confused about network access

[Stephen Paul Weber]

I cannot reproduce.


Does the import work when you run it?


signature.asc
Description: PGP signature

bug#21829: guix import hackage failures

[Paul van der Walt]

Hello bug-guix,

I have found that the command `guix import hackage foo` sometimes fails.
I will try to provide a few examples.

-8<--
$ guix import hackage xmonad-contrib

Starting download of /tmp/guix-file.Bt94ZV
>From http://hackage.haskell.org/package/xmonad-contrib/xmonad-contrib.cabal...
 xmonad-contrib.cabal 355KiB/s 00:00 | 13KiB transferred
Syntax error: unexpected token : true (at line 75, column 7)
Syntax error: unexpected end of input
guix import: error: failed to download cabal file for package '
FORMAT: error with call: (format # "~:[~*~;guix ~a: 
~]~afailed to download cabal file for package '~a<==='~%" import import error:  
===>)
missing argument(s)
Backtrace:
In ice-9/boot-9.scm:
 157: 15 [catch #t # ...]
In unknown file:
   ?: 14 [apply-smob/1 #]
In ice-9/boot-9.scm:
  63: 13 [call-with-prompt prompt0 ...]
In ice-9/eval.scm:
 432: 12 [eval # #]
In ice-9/boot-9.scm:
2401: 11 [save-module-excursion #]
4050: 10 [#]
1724: 9 [%start-stack load-stack #]
1729: 8 [#]
In unknown file:
   ?: 7 [primitive-load 
"/gnu/store/1pvqvwcck48izizrl17hygbb9r7bzi44-guix-0.8.3.abbe2c6/bin/.guix-real"]
In guix/ui.scm:
1173: 6 [run-guix-command import "hackage" "xmonad-contrib"]
In guix/scripts/import.scm:
 110: 5 [guix-import "hackage" "xmonad-contrib"]
In guix/scripts/import/hackage.scm:
 137: 4 [guix-import-hackage "xmonad-contrib"]
In ice-9/format.scm:
1593: 3 [format # ...]
 766: 2 [format:format-work "~:[~*~;guix ~a: ~]~afailed to download cabal file 
for package '~a'~%" ...]
 200: 1 [tilde-dispatch]
In unknown file:
   ?: 0 [scm-error misc-error #f "~A" ("error in format") #f]

ERROR: In procedure scm-error:
ERROR: error in format
-8<--

Of course, the errors will all be relatively similar since they seem to
be parsing errors.  Packages which fail include:

* base-compat
* base-orphans
* clock
* fast-logger
* fgl
* generic-deriving
* happy
* hscolour
* nats
* ObjectName
* old-locale
* QuickCheck
* SDL
* setenv
* split
* StateVar
* streaming-commons
* syb
* tagged
* transformers-base
* wai
* xmonad
* xmonad-contrib
* xmonad-extras
* zip-archive
* zlib

Cheers,
p.

bug#40710: node-build-system should not install tests

[paul via Bug reports for GNU Guix]

close 40710

bug#36667: crates-io.scm packages should build on master

[paul via Bug reports for GNU Guix]

close 36667

bug#37740: Deja-dup fails to build on c2734ff80987de8f0bb3e31d4339e5496a9821d2

[paul via Bug reports for GNU Guix]

close 37740

bug#65982: Pinebook Pro image broken

[paul via Bug reports for GNU Guix]

Hi Gabriel, thank you for taking the time to bisect and find the first 
working commit!



I can confirm that

guix time-machine --commit=d6a53849935f8584e1df57faa79c18c23fbb2aa1 -- 
system image -e '(@ (gnu system images pinebook-pro) 
pinebook-pro-barebones-raw-image)' --system=aarch64-linux


is able to build a bootable image, contrary to what happens on master.


I'm not an expert but I'd love to learn more and help solving this. 
Please do CC me if someone has some idea about how to fix but doesn't 
have the hardware.

bug#68848: gnu: home: dotfiles: Avoid creating extra directory in $HOME.

[paul via Bug reports for GNU Guix]

Hello,

I'm sending a patch supposed to fix https://issues.guix.gnu.org/68848  . 
Please let me know if this is ok for you and fixes your issues.



Thank you,


giacomo

bug#73453: Close

[paul via Bug reports for GNU Guix]

Fixed by b6ea4f82986af507d787c1271077f61d504730ad

bug#73454: Close

[paul via Bug reports for GNU Guix]

Fixed by 9a966bace1ce6a038ab580fe9103afa588101449

bug#73453: mix-build-system does not make Erlang packages available as Elixir dependencies

[paul via Bug reports for GNU Guix]

Dear Guix ,

please consider the attached guix.scm. If you try to build it you will 
notice many messages as the following:


 warning: :telemetry.execute/3 is undefined (module :telemetry is not available 
or is yet to be defined)


until the build fails with:

16:26:55.642 [notice] Application eex exited: :stopped
** (Mix) Could not start application telemetry: could not find application 
file: telemetry.app
error: in phase 'check': uncaught exception:
%exception #<&invoke-error program: "mix" arguments: ("do" "compile" "--no-deps-check" "--no-prune-code-paths" 
"+" "test" "--no-deps-check") exit-status: 1 term-signal: #f stop-signal: #f>
phase `check' failed after 0.4 seconds
command "mix" "do" "compile" "--no-deps-check" "--no-prune-code-paths" "+" "test" 
"--no-deps-check" failed with status 1
build process 18 exited with status 256




This is because Erlang dependencies are not made available to Elixir 
builds. I'm sending a patch addressing this issue.



Thank you for your work,


giacomo
(use-modules (guix packages)
 (guix download)
 (guix licenses)
 (guix build-system mix)
 (guix build-system rebar)
 (gnu packages elixir-xyz)
 (gnu packages erlang-xyz))
(define-public elixir-stream-data
  (package
(name "elixir-stream-data")
(version "1.1.1")
(source
 (origin
   (method url-fetch)
   (uri (hexpm-uri "stream_data" version))
   (sha256
(base32 "134c7dyvprvnfm7fz6dvhk1mifrd0iq2pwjkzmiq8wq6pm3cvl25"
(build-system mix-build-system)
(native-inputs
 (list elixir-excoveralls))
(synopsis "Data generation and property-based testing for Elixir")
(description "@code{StreamData} is an Elixir library for data generation and
property-based testing.")
(home-page "https://hexdocs.pm/stream_data/";)
(license asl2.0)))
(define-public elixir-decimal
  (package
(name "elixir-decimal")
(version "2.1.1")
(source
 (origin
   (method url-fetch)
   (uri (hexpm-uri "decimal" version))
   (sha256
(base32 "1k7z418b6cj977wswpxsk5844xrxc1smaiqsmrqpf3pdjzsfbksk"
(build-system mix-build-system)
(native-inputs
 (list elixir-stream-data))
(synopsis "Arbitrary precision decimal arithmetic")
(description "This package provides @code{elixir-decimal}, a library that
represents values internally using three integers: a sign, a coefficient, and an
exponent.  In this way, numbers of any size and with any number of decimal
places can be represented exactly.")
(home-page "https://hexdocs.pm/decimal/";)
(license asl2.0)))
(define-public erlang-telemetry
  (package
(name "erlang-telemetry")
(version "1.3.0")
(source
 (origin
   (method url-fetch)
   (uri (hexpm-uri "telemetry" version))
   (sha256
(base32 "1rkrbf3z7my9dsz9km7077anp6f0nyapmf5lyij3grnv364zq5bh"
(build-system rebar-build-system)
(synopsis "Dynamic dispatching library for metrics and instrumentations")
(description
 "@code{Telemetry} is a lightweight library for dynamic dispatching of
events, with a focus on metrics and instrumentation.  Any Erlang or Elixir
library can use @code{telemetry} to emit events.  Application code and other
libraries can then hook into those events and run custom handlers.")
(home-page "https://hexdocs.pm/telemetry/";)
(license asl2.0)))
(define-public elixir-ecto
  (package
(name "elixir-ecto")
(version "3.12.3")
(source
 (origin
   (method url-fetch)
   (uri (hexpm-uri "ecto" version))
   (sha256
(base32 "0rcisp34m8b058jrcf52nziyscmn1h6yfjfw91ggj8p7d9893zcy"
(build-system mix-build-system)
(propagated-inputs (list elixir-decimal elixir-jason erlang-telemetry))
(synopsis
 "Toolkit for data mapping and language integrated query for Elixir")
(description
 "This package provides a toolkit for data mapping and language integrated query
for Elixir.")
(home-page "https://hexdocs.pm/ecto/";)
(license asl2.0)))
elixir-ecto

bug#73454: mix-build-system does not support git-version output

[paul via Bug reports for GNU Guix]

Dear Guix,

consider the following procedure invokation:

scheme@(guile-user)> (package-name->elixir-name "elixir-a-pkg-1.2.3")
$1 = "a_pkg"

This is the behaviour manifested when the procedure is called with a 
version created with the git-version procedure from (guix git-download):


scheme@(guile-user)> (package-name->elixir-name "a_pkg-0.0.0-0.e51e36e")
$1 = "a_pkg_0.0.0

while the expected behaviour would be:

scheme@(guile-user)> (package-name->elixir-name "a_pkg-0.0.0-0.e51e36e")
$1 = "a_pkg"

I'm sending a patch addressing this, thank you for your work!

bug#74774: Commit 5d284ebc8df87b0e21cee5844d66dc7c80863464 breaks reconfigure for systems using gnome-desktop-service-type

[paul via Bug reports for GNU Guix]

Hi Danny, thank you so much for the quick action. I'm not sure about the 
right solution for this but maybe the gnome-desktop-service-type should 
install xdg-desktop-portal-next in the system profile instead of 
xdg-desktop-portal? I think this way there wouldn't be any collision but 
it would need some test for sure.

bug#74774: Commit 5d284ebc8df87b0e21cee5844d66dc7c80863464 breaks reconfigure for systems using gnome-desktop-service-type

[paul via Bug reports for GNU Guix]

Hi,

since 5d284ebc8df87b0e21cee5844d66dc7c80863464 it's not possible anymore 
to have gnome-desktop-service-type and xdg-destkop-portal-gtk installed 
in the system profile. Is this intended? Is there any workaround?


Thank you for your help,

giacomo

bug#74967: About /etc/subuid and /etc/subgid commits

[paul via Bug reports for GNU Guix]

Hi Nicolas, apologies for breaking your system :( Is is possible for you 
to try and bisect the history to find the culprit commit?


On 12/19/24 10:36, Nicolas Graves wrote:

It is a bit circumvoluted, but it worked properly on my side on
guix@478b9ccea8. Do you see a reason why your patches could break my
user login?


I'm not sure, I was wondering: do you use/extend the subids-service-type 
in your configuration or did you already have manually setup /etc/subuid 
or /etc/subgid? Otherwise I'm not sure how it can impact your system, if 
you could share even some parts of your operating-system configuration 
it would make finding the problem a little easier.


Since you mentioned PAM, these two changes that I authored were recently 
merged. Could you try and see whether your system work at commit 
a1ecd7f56c4ffadc49d5501a0df7f4c4556120c2 which is the parent of the 
first pam change?


Thank you very much :)

bug#74967: About /etc/subuid and /etc/subgid commits

[paul via Bug reports for GNU Guix]

I forgot to attach the two PAM related commits, apologies for the noise.

[0]: 
https://git.savannah.gnu.org/cgit/guix.git/commit/?id=3eb720bd0b4bab233918f979bb51b58437db06ad
[1]: 
https://git.savannah.gnu.org/cgit/guix.git/commit/?id=9411a1495f7cb2b116129a71a1fc1817e962fa5d

bug#74967: About /etc/subuid and /etc/subgid commits

[paul via Bug reports for GNU Guix]

Hi Nicolas, awesome! I'm closing this.


Cheers,

giacomo

Il 21 dicembre 2024 17:49:08 CET, Nicolas Graves  ha 
scritto:
>On 2024-12-19 12:32, paul wrote:
>
>> Hi Nicolas, apologies for breaking your system :( Is is possible for you 
>> to try and bisect the history to find the culprit commit?
>>
>> On 12/19/24 10:36, Nicolas Graves wrote:
>>> It is a bit circumvoluted, but it worked properly on my side on
>>> guix@478b9ccea8. Do you see a reason why your patches could break my
>>> user login?
>>
>> I'm not sure, I was wondering: do you use/extend the subids-service-type 
>> in your configuration or did you already have manually setup /etc/subuid 
>> or /etc/subgid? Otherwise I'm not sure how it can impact your system, if 
>> you could share even some parts of your operating-system configuration 
>> it would make finding the problem a little easier.
>>
>> Since you mentioned PAM, these two changes that I authored were recently 
>> merged. Could you try and see whether your system work at commit 
>> a1ecd7f56c4ffadc49d5501a0df7f4c4556120c2 which is the parent of the 
>> first pam change?
>>
>> Thank you very much :)
>
>I've tried bisecting and this time it seems to work properly.  I'm not
>sure what it was then, but it works fine now!
>
>-- 
>Best regards,
>Nicolas Graves

bug#74967: About /etc/subuid and /etc/subgid commits

[paul via Bug reports for GNU Guix]

Hi Nicolas, awesome! I'm closing this.

Cheers,

giacomo

Il 21 dicembre 2024 17:49:08 CET, Nicolas Graves  ha 
scritto:
>On 2024-12-19 12:32, paul wrote:
>
>> Hi Nicolas, apologies for breaking your system :( Is is possible for you 
>> to try and bisect the history to find the culprit commit?
>>
>> On 12/19/24 10:36, Nicolas Graves wrote:
>>> It is a bit circumvoluted, but it worked properly on my side on
>>> guix@478b9ccea8. Do you see a reason why your patches could break my
>>> user login?
>>
>> I'm not sure, I was wondering: do you use/extend the subids-service-type 
>> in your configuration or did you already have manually setup /etc/subuid 
>> or /etc/subgid? Otherwise I'm not sure how it can impact your system, if 
>> you could share even some parts of your operating-system configuration 
>> it would make finding the problem a little easier.
>>
>> Since you mentioned PAM, these two changes that I authored were recently 
>> merged. Could you try and see whether your system work at commit 
>> a1ecd7f56c4ffadc49d5501a0df7f4c4556120c2 which is the parent of the 
>> first pam change?
>>
>> Thank you very much :)
>
>I've tried bisecting and this time it seems to work properly.  I'm not
>sure what it was then, but it works fine now!
>
>-- 
>Best regards,
>Nicolas Graves