bug#65282: The problem is not with datefudge.

2023-08-15 Thread Dmitry Nikolaev via Bug reports for GNU Guix
The problem with guix-1.3 on Ubuntu-22.04 is not with datefudge. The 
problem if ci.guix.gnu.org connectivity from Russia.







bug#65282: guix-1.3 on Ubuntu-22.04 is broken because of outdated datefudge.

2023-08-15 Thread Dmitry Nikolaev via Bug reports for GNU Guix

Hello.

I recently tried to install guix on Ubuntu 22.04 from APT. Installation 
goes well, but 'guix pull' does not work. It tries to download 
datefudge-1.23, but fails.


Starting download of 
/gnu/store/g0ha1fd0x299w48hfgs2sa1sl1b6vlnq-datefudge_1.23.tar.xz
From 

http://ftp.de.debian.org/debian/pool/main/d/datefudge/datefudge_1.23.tar.xz...
download failed 
"http://ftp.de.debian.org/debian/pool/main/d/datefudge/datefudge_1.23.tar.xz; 
404 "Not Found"


Starting download of 
/gnu/store/g0ha1fd0x299w48hfgs2sa1sl1b6vlnq-datefudge_1.23.tar.xz
From 

http://ftp.fr.debian.org/debian/pool/main/d/datefudge/datefudge_1.23.tar.xz...
download failed 
"http://ftp.fr.debian.org/debian/pool/main/d/datefudge/datefudge_1.23.tar.xz; 
404 "Not Found"


Starting download of 
/gnu/store/g0ha1fd0x299w48hfgs2sa1sl1b6vlnq-datefudge_1.23.tar.xz
From 

http://ftp.debian.org/debian/pool/main/d/datefudge/datefudge_1.23.tar.xz...
download failed 
"http://ftp.debian.org/debian/pool/main/d/datefudge/datefudge_1.23.tar.xz; 
404 "Not Found"


Starting download of 
/gnu/store/g0ha1fd0x299w48hfgs2sa1sl1b6vlnq-datefudge_1.23.tar.xz
From 

http://archive.debian.org/debian/pool/main/d/datefudge/datefudge_1.23.tar.xz...
download failed 
"http://archive.debian.org/debian/pool/main/d/datefudge/datefudge_1.23.tar.xz; 
404 "Not Found"


Starting download of 
/gnu/store/g0ha1fd0x299w48hfgs2sa1sl1b6vlnq-datefudge_1.23.tar.xz
From 

https://ci.guix.gnu.org/file/datefudge_1.23.tar.xz/sha256/0ifnlb0mc8qc2kb5042pbz0ns6rwcb7201di8wyrsphl0yhnhxiv...
Throw to key gnutls-error' with args (#pull function.> handshake)'.


Starting download of 
/gnu/store/g0ha1fd0x299w48hfgs2sa1sl1b6vlnq-datefudge_1.23.tar.xz
From 

https://tarballs.nixos.org/sha256/0ifnlb0mc8qc2kb5042pbz0ns6rwcb7201di8wyrsphl0yhnhxiv...
download failed 
"https://tarballs.nixos.org/sha256/0ifnlb0mc8qc2kb5042pbz0ns6rwcb7201di8wyrsphl0yhnhxiv; 
404 "Not Found"


Starting download of 
/gnu/store/g0ha1fd0x299w48hfgs2sa1sl1b6vlnq-datefudge_1.23.tar.xz
From 

https://archive.softwareheritage.org/api/1/content/sha256:3b7668a107145e9d3d47b10520ce623c1b6dc15f571050d6140c2356c1a2d645/raw/...
download failed 
"https://archive.softwareheritage.org/api/1/content/sha256:3b7668a107145e9d3d47b10520ce623c1b6dc15f571050d6140c2356c1a2d645/raw/; 
404 "Not Found"
failed to download 
"/gnu/store/g0ha1fd0x299w48hfgs2sa1sl1b6vlnq-datefudge_1.23.tar.xz" from 
"mirror://debian/pool/main/d/datefudge/datefudge_1.23.tar.xz"



As you can see, datefudge-1.23 is outdated. Even Debian oldstable is 
using datefudge-1.24. My last hope was to download it from 
ci.guix.gnu.org, but I got gnutls-error.


Looks like guix-1.3 is completely unusable on Ubuntu.


Dmitry Nikolaev






bug#65281: GUIX Installer Error - installer-dump-15d44843

2023-08-15 Thread the middle third via Bug reports for GNU Guix
Reporting a GUIX installation error for installer-dump-15d44843.

Fairly stock install with just i3 window manager, but can't get past one of the 
substitute pulls.  
~Cantor





bug#64827: Texlive-biber not installable

2023-08-15 Thread Vinicius Monego
Hi,

I have a similar issue when trying to modify a profile containing
jupyter or python-jupyterlab-server:

guix shell jupyter python-jupyterlab-server

Error:

building TeX Live font maps...
-builder for `/gnu/store/q6gakg3lp5rgmcyhmlf5fz7vnhw0vvaz-texlive-font-
maps.drv' failed with exit code 1
a compilação de /gnu/store/q6gakg3lp5rgmcyhmlf5fz7vnhw0vvaz-texlive-
font-maps.drv falhou
Veja o log de compilação em
"/var/log/guix/drvs/q6/gakg3lp5rgmcyhmlf5fz7vnhw0vvaz-texlive-font-
maps.drv.gz".
cannot build derivation `/gnu/store/j98hmraklblr70ggasarp49pk9jgih0d-
profile.drv': 1 dependencies couldn't be built
guix package: erro: build of
`/gnu/store/j98hmraklblr70ggasarp49pk9jgih0d-profile.drv' failed

Content of the decompressed the log file:

Backtrace:
 3 (primitive-load "/gnu/store/4msdwzccfp51zhmnkr61vvpdllz?")
In ice-9/eval.scm:
 619:8 2 (_ #f)
In ice-9/boot-9.scm:
 140:2 1 (dynamic-wind # ?)
In unknown file:
 0 (chdir "/tmp/texlive/share/texmf-dist")

ERROR: In procedure chdir:
In procedure chdir: No such file or directory

Vinicius





bug#64920: conda-22.9.0 fails to build (missing `mock`?)

2023-08-15 Thread Ludovic Courtès
Hi Alexandre,

Alexandre Hannud Abdo  skribis:

> guix shell: error: build of 
> `/gnu/store/1fjkvsgwys8wj8s63dwc7ig92w5rkadj-conda-22.9.0.drv' failed
>
> In the guix logs I see:
>
>  ERRORS 
> 
> __ ERROR collecting tests/test_cli.py 
> __
> ImportError while importing test module 
> '/tmp/guix-build-conda-22.9.0.drv-0/source/tests/test_cli.py'.
> Hint: make sure your test modules/packages have valid Python names.
> Traceback:
> /gnu/store/9kmpn99l328qx5q5gyn6hs9dk5hm3mmg-python-pytest-7.1.3/lib/python3.10/site-packages/_pytest/python.py:608:
>  in _importtestmodule
>     mod = import_path(self.path, mode=importmode, root=self.config.rootpath)
> /gnu/store/9kmpn99l328qx5q5gyn6hs9dk5hm3mmg-python-pytest-7.1.3/lib/python3.10/site-packages/_pytest/pathlib.py:533:
>  in import_path
>     importlib.import_module(module_name)
> /gnu/store/dy3xh053ahkhrp2jamggq8cpsyvp8mg0-python-3.10.7/lib/python3.10/importlib/__init__.py:126:
>  in import_module
>     return _bootstrap._gcd_import(name[level:], package, level)
> :1050: in _gcd_import
>     ???
> :1027: in _find_and_load
>     ???
> :1006: in _find_and_load_unlocked
>     ???
> :688: in _load_unlocked
>     ???
> /gnu/store/9kmpn99l328qx5q5gyn6hs9dk5hm3mmg-python-pytest-7.1.3/lib/python3.10/site-packages/_pytest/assertion/rewrite.py:168:
>  in exec_module
>     exec(co, module.__dict__)
> tests/test_cli.py:10: in 
>     from mock import patch
> E   ModuleNotFoundError: No module named 'mock'

I believe this was fixed by 0069db9154c164d757a2969af5f2dabbb979daae a
few days ago.

Thanks,
Ludo’.





bug#64509: Guile packages should install versioned aliases for binaries (guile-X.Y, guild-X.Y, etc.)

2023-08-15 Thread Ludovic Courtès
Hi Zack,

"Zack Weinberg"  skribis:

> The Guile packages currently install all their binaries under their
> basic name only, e.g.
>
> $ ls /gnu/store/4gvgcfdiz67wv04ihqfa8pqwzsb0qpv5-guile-3.0.9/bin
> /gnu/store/4gvgcfdiz67wv04ihqfa8pqwzsb0qpv5-guile-3.0.9/bin:
> guild  guile  guile-config  guile-snarf  guile-tools
>
> However, the Autoconf macro GUILE_PROGS (from guile.m4) looks first
> for a guile binary with a version number suffix (e.g. ‘guile-3.0’).
> If it finds one, then it looks *only* for a matching guild-X.Y and
> errors out if it can’t find that.  This is a problem for building Guix
> itself from source in a non-pure ‘guix shell -D guix’ on top of a
> foreign distro that provides a ‘guile-3.0’ binary but not the other
> four programs:

I think the solution is to use ‘guix shell -D guix -CP’: that’ll give
you a container, where /usr/bin/guile-3.0 isn’t accessible, which
ensures there’s no interference.

(FWIW this is what I do, even on Guix System, for my development
environments.)

Does that work for you?

If your distro doesn’t support unprivileged user namespaces, which ‘-C’
relies on, you can fall back to ‘--pure’.

Ludo’.





bug#64981: GTK4 applications broken (missing libGLESv2)

2023-08-15 Thread Efraim Flashner
On Tue, Aug 01, 2023 at 12:06:31AM +0200, Csepp wrote:
> for example:
> $ transmission-gtk
> Couldn't open libGLESv2.so.2: libGLESv2.so.2
> 
> I get the same error with Tuba.  It likely affects other applications.
> 
> Guix commit: 182be30
> System: x86_64

I've been getting this too, I'm "glad" to see I'm not the only one.  If
I set GSK_RENDERER=cairo (the fallback renderer) then I can launch gtk4
applications.

(ins)efraim@pbp ~$ guix shell mesa-utils -- glxinfo | grep 'profile version 
string'
OpenGL core profile version string: 3.1 Mesa 23.1.4
OpenGL ES profile version string: OpenGL ES 3.1 Mesa 23.1.4
(ins)efraim@pbp ~$ guix shell mesa-utils -- eglinfo | grep -B2 -A1 'version 
string'
EGL API version: 1.4
EGL vendor string: Mesa Project
EGL version string: 1.4
EGL client APIs: OpenGL OpenGL_ES
--
EGL API version: 1.4
EGL vendor string: Mesa Project
EGL version string: 1.4
EGL client APIs: OpenGL OpenGL_ES
--
EGL API version: 1.4
EGL vendor string: Mesa Project
EGL version string: 1.4
EGL client APIs: OpenGL OpenGL_ES

-- 
Efraim Flashner  רנשלפ םירפא
GPG key = A28B F40C 3E55 1372 662D  14F7 41AA E7DC CA3D 8351
Confidentiality cannot be guaranteed on emails sent or received unencrypted


signature.asc
Description: PGP signature


bug#64410: Acknowledgement (Request for merging "rust-team" branch)

2023-08-15 Thread Efraim Flashner
Branch merged

-- 
Efraim Flashner  רנשלפ םירפא
GPG key = A28B F40C 3E55 1372 662D  14F7 41AA E7DC CA3D 8351
Confidentiality cannot be guaranteed on emails sent or received unencrypted


signature.asc
Description: PGP signature


bug#65306: [shepherd] ntpd throws shepherd out of the loop

2023-08-15 Thread Timotej Lazar
Liliana Marie Prikler  [2023-08-15 07:18:02+0200]:
> As of recently (maybe it dates back longer, but I first experienced it
> two weeks ago and just now got to debugging it a little), Shepherd gets
> stuck at 100% CPU usage "early" on first boot.

I have this issue on all Guix systems without a (working) RTC. It seems
to be caused by a recentish update to guile-fibers:

https://github.com/wingo/fibers/issues/89

For me this happens regardless of whether the system time is pushed
forward manually or by ntpd. Depending on the time delta and CPU speed,
the usage returns to normal after a couple of days. During that time any
socket-activated services like SSH are also unreachable.





bug#65178: Shepherd hangs (was: Getting Guix to shutdown my laptop properly with Sway and no DE)

2023-08-15 Thread Hilton Chain via Bug reports for GNU Guix
On Sun, 13 Aug 2023 23:25:59 +0800,
Hilton Chain wrote:
>
> Today I encountered the home reconfiguration issue.  The behavior is
> similar to .

And today Shepherd hung after starting a service [1], the service
itself started successfully (process started, logs available):
--8<---cut here---start->8---
$ sudo herd enable cloudflare-tunnel && sudo herd start cloudflare-tunnel
Enabled service cloudflare-tunnel.

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

[1]: 






bug#65306: [shepherd] ntpd throws shepherd out of the loop

2023-08-15 Thread Csepp


Liliana Marie Prikler  writes:

> Hi Guix,
>
> I have a laptop that's a little stuck in the past… more accurately
> January of 2020 thanks to what I believe to be an empty CMOS battery. 
> As of recently (maybe it dates back longer, but I first experienced it
> two weeks ago and just now got to debugging it a little), Shepherd gets
> stuck at 100% CPU usage "early" on first boot.  I can prevent this
> issue by getting the system time "close enough" to the actual time
> before the NTP sync, but see the first sentence.  Not having a network
> connection also works, but that's somewhat unpractical.  Also, the high
> CPU usage still occurs if a sync is done later.  I have yet to
> encounter the bug post hibernation, but I also wish not to.  There
> doesn't appear to be anything particular interesting in the logs
> either.
>
> Cheers

This sounds like an issue with slow incremental system time updates,
although I don't understand why that would cause Shepherd to hang, but
maybe the NTP service is configured to only report itself as initialized
once it has finished synchronizing, which defeats the point of
incremental updating.
There is probably a config setting to tell ntpd to perform the update in
a single step, at least I know chrony has one.

ps.: don't wait until the battery starts leaking to replace it





bug#65282: guix-1.3 on Ubuntu-22.04 is broken because of outdated datefudge.

2023-08-15 Thread 宋文武 via Bug reports for GNU Guix
Dmitry Nikolaev  writes:

> The problem with guix-1.3 on Ubuntu-22.04 is not with datefudge. The
> problem is ci.guix.gnu.org connectivity from Russia.

Hello, you could try follow substitute mirrors if ci doesn't works:

ci mirror:   https://mirror.sjtu.edu.cn/guix/
bordeaux:https://bordeaux.guix.gnu.org
bordeaux mirror: https://bordeaux-singapore-mirror.cbaines.net
bordeaux mirror: https://bordeaux-us-east-mirror.cbaines.net

Hope this could be useful, thanks!