bug#71011: [BUG] Fail to buidl latest kitty

[Sharlatan Hellseher]

Hi Lucy,

Thank you for your work on trouble shooting the issue. The master has go
1.22 now and I would like to proceed with Kitty update. While updating
other packages requiring "github.com/alecthomas/chroma/v2" I've faced
with the similar issue when it tries to use "embed" from standard
library, see 

--
Oleg


signature.asc
Description: PGP signature

bug#53533: [DISCUSSION] Quality of services in reproducible build environment Guix

[Sharlatan Hellseher]

signature.asc
Description: PGP signature

bug#71011: [BUG] Fail to buidl latest kitty

[Sharlatan Hellseher]

I could not reproduce it.

--8<---cut here---start->8---
(guix/linux-gnu)[sharlatan@guxtil ~]$: guix build kitty
substitute: updating substitutes from 'https://bordeaux.guix.gnu.org'... 100.0%
3.1 MB will be downloaded:
  /gnu/store/7h55d9yghc72q5lc43lrly9rvl59x39v-kitty-0.21.2
substituting /gnu/store/7h55d9yghc72q5lc43lrly9rvl59x39v-kitty-0.21.2...
downloading from 
https://bordeaux.guix.gnu.org/nar/lzip/7h55d9yghc72q5lc43lrly9rvl59x39v-kitty-0.21.2
 ...
 kitty-0.21.2  2.9MiB   


5.3MiB/s 00:01 ▕██▏ 100.0%

The following graft will be made:
   /gnu/store/4izr3alrcnacspq4i55mvgc9axbmfbfd-kitty-0.21.2.drv
applying 20 grafts for kitty-0.21.2 ...
grafting '/gnu/store/7h55d9yghc72q5lc43lrly9rvl59x39v-kitty-0.21.2' -> 
'/gnu/store/9n4nnswkk844m1mhpzh6s3ndqwx4zr88-kitty-0.21.2'...
successfully built /gnu/store/4izr3alrcnacspq4i55mvgc9axbmfbfd-kitty-0.21.2.drv
/gnu/store/9n4nnswkk844m1mhpzh6s3ndqwx4zr88-kitty-0.21.2
(guix/linux-gnu)[sharlatan@guxtil ~]$: guix describe
Generation 24   May 21 2024 16:59:57(current)
  guix 3fd9f25
repository URL: https://git.savannah.gnu.org/git/guix.git
branch: master
commit: 3fd9f25bb385723c70d0bd6af21aeaf784d08049
(guix/linux-gnu)[sharlatan@guxtil ~]$: guix build kitty --check
The following graft will be made:
   /gnu/store/4izr3alrcnacspq4i55mvgc9axbmfbfd-kitty-0.21.2.drv
applying 20 grafts for kitty-0.21.2 ...
grafting '/gnu/store/7h55d9yghc72q5lc43lrly9rvl59x39v-kitty-0.21.2' -> 
'/gnu/store/9n4nnswkk844m1mhpzh6s3ndqwx4zr88-kitty-0.21.2'...
successfully built /gnu/store/4izr3alrcnacspq4i55mvgc9axbmfbfd-kitty-0.21.2.drv
successfully built /gnu/store/4izr3alrcnacspq4i55mvgc9axbmfbfd-kitty-0.21.2.drv
/gnu/store/9n4nnswkk844m1mhpzh6s3ndqwx4zr88-kitty-0.21.2
--8<---cut here---end--->8---


signature.asc
Description: PGP signature

bug#71011: [BUG] Fail to buidl latest kitty

[Sharlatan Hellseher]

Hi Edison,

Thanks for reporting.

May you provide which commit you are on please?

--8<---cut here---start->8---
guix describe
--8<---cut here---end--->8---


signature.asc
Description: PGP signature

bug#70910: xdot has stopped working after update to 1.3

[Sharlatan Hellseher]

Hi,

Pushed as 0846eaecd45783bf40e8dc67b0c16f71068524b7 to master.

--
Oleg


signature.asc
Description: PGP signature

bug#57836: fzf 0.33.0 release commit fails to build

[Sharlatan Hellseher]

Hi,

Thank you for reporting this, I thinks this issue is outdated as fzf is
on 0.41.0 since 767edbb6fe781d19c19971f2ccd3b0da8fd053fc in master
branch.

Current upstream version is 0.49.0 to wic we may bump it.

Closing as no more relevant.
--
Oleg


signature.asc
Description: PGP signature

bug#70254: withershins - failed to build

[Sharlatan Hellseher]

Hi,

While refreshing and checking packages in (gnu packages code) I've
noticed that withershins is no longer buildable, it looks like the
source is not compatible with a new version of binutils.

One more thing - the project does not exist by
 but I could find it in
.

Cc: Ricardo as he was the last person who has added and updated the
package.

Error trace:
--8<---cut here---start->8---
starting phase `build'
/gnu/store/gl26kr5v6ch5lc3ignly61kb224drijc-cmake-minimal-3.24.2/bin/cmake 
-S/tmp/guix-build-withershins-0.1.drv-0/source 
-B/tmp/guix-build-withershins-0.1.drv-0/source --check-build-system 
CMakeFiles/Makefile.cmake 0
/gnu/store/gl26kr5v6ch5lc3ignly61kb224drijc-cmake-minimal-3.24.2/bin/cmake -E 
cmake_progress_start /tmp/guix-build-withershins-0.1.drv-0/source/CMakeFiles 
/tmp/guix-build-withershins-0.1.drv-0/source//CMakeFiles/progress.marks
make  -f CMakeFiles/Makefile2 all
make[1]: Entering directory '/tmp/guix-build-withershins-0.1.drv-0/source'
make  -f src/CMakeFiles/withershins.dir/build.make 
src/CMakeFiles/withershins.dir/depend
make[2]: Entering directory '/tmp/guix-build-withershins-0.1.drv-0/source'
cd /tmp/guix-build-withershins-0.1.drv-0/source && 
/gnu/store/gl26kr5v6ch5lc3ignly61kb224drijc-cmake-minimal-3.24.2/bin/cmake -E 
cmake_depends "Unix Makefiles" /tmp/guix-build-withershins-0.1.drv-0/source 
/tmp/guix-build-withershins-0.1.drv-0/source/src 
/tmp/guix-build-withershins-0.1.drv-0/source 
/tmp/guix-build-withershins-0.1.drv-0/source/src 
/tmp/guix-build-withershins-0.1.drv-0/source/src/CMakeFiles/withershins.dir/DependInfo.cmake
 --color=
make[2]: Leaving directory '/tmp/guix-build-withershins-0.1.drv-0/source'
make  -f src/CMakeFiles/withershins.dir/build.make 
src/CMakeFiles/withershins.dir/build
make[2]: Entering directory '/tmp/guix-build-withershins-0.1.drv-0/source'
[ 16%] Building CXX object src/CMakeFiles/withershins.dir/withershins.cpp.o
cd /tmp/guix-build-withershins-0.1.drv-0/source/src && 
/gnu/store/5lqhcv91ijy82p92ac6g5xw48l0lwwz4-gcc-11.3.0/bin/c++ 
-DWITHERSHINS_ENABLE_LIBBFD -I/tmp/guix-build-withershins-0.1.drv-0/source/src 
-std=c++11 -Wall -Wextra -pthread -O2 -g -DNDEBUG -MD -MT 
src/CMakeFiles/withershins.dir/withershins.cpp.o -MF 
CMakeFiles/withershins.dir/withershins.cpp.o.d -o 
CMakeFiles/withershins.dir/withershins.cpp.o -c 
/tmp/guix-build-withershins-0.1.drv-0/source/src/withershins.cpp
[ 33%] Building CXX object src/CMakeFiles/withershins.dir/withershins_unix.cpp.o
cd /tmp/guix-build-withershins-0.1.drv-0/source/src && 
/gnu/store/5lqhcv91ijy82p92ac6g5xw48l0lwwz4-gcc-11.3.0/bin/c++ 
-DWITHERSHINS_ENABLE_LIBBFD -I/tmp/guix-build-withershins-0.1.drv-0/source/src 
-std=c++11 -Wall -Wextra -pthread -O2 -g -DNDEBUG -MD -MT 
src/CMakeFiles/withershins.dir/withershins_unix.cpp.o -MF 
CMakeFiles/withershins.dir/withershins_unix.cpp.o.d -o 
CMakeFiles/withershins.dir/withershins_unix.cpp.o -c 
/tmp/guix-build-withershins-0.1.drv-0/source/src/withershins_unix.cpp
/tmp/guix-build-withershins-0.1.drv-0/source/src/withershins_unix.cpp: In 
function ‘bool find_file_info(const string&, const void*, std::string&, 
std::string&, int&)’:
/tmp/guix-build-withershins-0.1.drv-0/source/src/withershins_unix.cpp:151:37: 
error: ‘bfd_get_section_vma’ was not declared in this scope; did you mean 
‘bfd_set_section_vma’?
  151 | const bfd_vma section_vma = bfd_get_section_vma(abfd.get(), 
section);
  | ^~~
  | bfd_set_section_vma
/tmp/guix-build-withershins-0.1.drv-0/source/src/withershins_unix.cpp:153:58: 
error: cannot convert ‘std::unique_ptr::pointer’ {aka ‘bfd*’} 
to ‘const asection*’ {aka ‘const bfd_section*’}
  153 | vma < section_vma + bfd_section_size(abfd.get(), section))
  |  ^~
  |  |
  |  
std::unique_ptr::pointer {aka bfd*}
In file included from 
/tmp/guix-build-withershins-0.1.drv-0/source/src/withershins_unix.cpp:21:
/gnu/store/cv571kkg5hyk98yw48857h1d0zi9azni-binutils-2.38/include/bfd.h:1193:35:
 note:   initializing argument 1 of ‘bfd_size_type bfd_section_size(const 
asection*)’
 1193 | bfd_section_size (const asection *sec)
  |   ^~~
make[2]: *** [src/CMakeFiles/withershins.dir/build.make:93: 
src/CMakeFiles/withershins.dir/withershins_unix.cpp.o] Error 1
make[2]: Leaving directory '/tmp/guix-build-withershins-0.1.drv-0/source'
make[1]: *** [CMakeFiles/Makefile2:119: src/CMakeFiles/withershins.dir/all] 
Error 2
make[1]: Leaving directory '/tmp/guix-build-withershins-0.1.drv-0/source'
make: *** [Makefile:94: all] Error 2
error: in phase 'build': uncaught exception:
%exception #< program: "make" arguments: () 

bug#47506: [PATCH] gnu: fiano-fmap: turn off tests to build program.

[Sharlatan Hellseher]

Hi,

Closing this issue as resolved in .

--
Oleg


signature.asc
Description: PGP signature

bug#45172: fiano-fmap test failure

[Sharlatan Hellseher]

Hi,

Closing this issue as resolved in .

--
Oleg


signature.asc
Description: PGP signature

bug#55928: alacritty (Rust) is not reproducible

[Sharlatan Hellseher]

Hi Ludo,

It looks like it's self healed:

--8<---cut here---start->8---
(guix/linux-gnu)[sharlatan@guxtil ~]$: guix describe
Generation 5Mar 29 2024 19:22:49(current)
  guix 423ca23
repository URL: https://git.savannah.gnu.org/git/guix.git
branch: master
commit: 423ca234cbd7b4902fd2a3fbc089a6fd57ed5583
(guix/linux-gnu)[sharlatan@guxtil ~]$: guix challenge alacritty

1 store items were analyzed:
  - 1 (100.0%) were identical
  - 0 (0.0%) differed
  - 0 (0.0%) were inconclusive
(guix/linux-gnu)[sharlatan@guxtil ~]$: guix build alacritty --check
The following graft will be made:
   /gnu/store/ypq71v642idqm4if2sisb1dkycmprdx2-alacritty-0.13.1.drv
applying 16 grafts for alacritty-0.13.1 ...
grafting '/gnu/store/argc7bnl3ag5zdzy0j4aw2klnl79zi9f-alacritty-0.13.1' -> 
'/gnu/store/hc8677ij4w2jr6mh947xb4zkz8pxv829-alacritty-0.13.1'...
successfully built 
/gnu/store/ypq71v642idqm4if2sisb1dkycmprdx2-alacritty-0.13.1.drv
successfully built 
/gnu/store/ypq71v642idqm4if2sisb1dkycmprdx2-alacritty-0.13.1.drv
/gnu/store/hc8677ij4w2jr6mh947xb4zkz8pxv829-alacritty-0.13.1
--8<---cut here---end--->8---

Closing as resolved.

---
Oleg


signature.asc
Description: PGP signature

bug#68243: alacritty segmentation fault

[Sharlatan Hellseher]

Fixed with 423ca234cbd7b4902fd2a3fbc089a6fd57ed5583.

Closing as resolved.

--
Oleg


signature.asc
Description: PGP signature

bug#53129: Zathura: Index for epub files only go to show page 1

[Sharlatan Hellseher]

Hi,

Is it still relevant for you or it may be closed as resolved?
The issue can't be reproduced as not commit or version provided.

Thanks,
Oleg


signature.asc
Description: PGP signature

bug#69997: Should ‘guix import pypi’ get dependencies from pyproject files?

[Sharlatan Hellseher]

Hi Lido!

> Should ‘guix import pypi’ attempt to get dependency
> information fromn‘pyproject.toml’, in addition to
> ‘requirements.txt’ and wheel ‘METADATA’ as it already does?

It's quite a common practice in modern Python just to include
 pyproject.toml, that fact makes importing long chains problematic.

It would be nice to have common yaml/toml parser for that task.

Oleg

bug#69585: sbcl-fast-generic-functions: Failed to build

[Sharlatan Hellseher]

Hi Guix,

I've noticed that sbcl-fast-generic-functions is failed to build since
<12 Sep 2023 18:35> see .

Keep it tracked in issues for the future fix.

--8<---cut here---start->8---
; caught ERROR:
;   READ error during COMPILE-FILE:
;
; Lock on package SB-PCL violated when interning %NO-PRIMARY-METHOD while in
; package FAST-GENERIC-FUNCTIONS.
;   See also:
; The SBCL Manual, Node "Package Locks"
;
; (in form starting at line: 3, column: 0, position: 39)

; compilation aborted after 0:00:00.000
Unhandled UIOP/LISP-BUILD:COMPILE-FILE-ERROR in thread #:
  COMPILE-FILE-ERROR while compiling
   #
--8<---cut here---end--->8---


--
Oleg


signature.asc
Description: PGP signature

bug#69258: archivebox: Failed to build

[Sharlatan Hellseher]

Hi Guix!

While reviewing https://issues.guix.gnu.org/68491 and working on minor
adjustments in:

* 2f1ed825af * gnu: python-simpervisor: Enable tests.
* 8cab6bac1c * gnu: python-simpervisor: Update to 1.0.0.
* 4da2f179d2 * gnu: python-devtools: Update to 0.12.2, fix build.
* ccbf143927 * gnu: python-watchdog: Simplify package.
* 18240ae446 * gnu: python-humanize: Update to 4.0.0.
* 4daeae8583 * gnu: python-trio-websocket: Simplify package.
* 1a2c374c2c * gnu: python-xyzservices: Simplify package.
* e355848578 * gnu: python-zeroconf: Simplify package.
* eeaad8c906 * gnu: python-crontab: Update to 3.0.0.
* 170efe6e68 * gnu: python-crontab: Enable tests.

I've found that archivebox is failed to build for a long time due to
issue with python-django-3.1.14.

https://ci.guix.gnu.org/search?query=archivebox%200.6.2%20spec:master

--8<---cut here---start->8---
build of /gnu/store/mcdbyv6vgfxv7ppk1jkcpvrzq6pbfgrr-python-django-3.1.14.drv 
failed
View build log at 
'/var/log/guix/drvs/mc/dbyv6vgfxv7ppk1jkcpvrzq6pbfgrr-python-django-3.1.14.drv.gz'.
cannot build derivation 
`/gnu/store/n2ja2mmvd2ly0q8qxc3wvcp0qd0xqbvq-archivebox-0.6.2.drv': 1 
dependencies couldn't be built
--8<---cut here---end--->8---

It was added 2y ago by Pradana AUMARS  and never
updated since that time.

Maybe someone would like to volunteer to fix it ;-).

Thanks,
Oleg


signature.asc
Description: PGP signature

bug#69240: [PATCH 00/10] Fix failed builds from evaluation 1123386.

[Sharlatan Hellseher]

Duplicated https://issues.guix.gnu.org/69238


signature.asc
Description: PGP signature

bug#69240: [PATCH 00/10] Fix failed builds from evaluation 1123386.

[Sharlatan Hellseher]

Hi Guix!

After I've pushed

https://issues.guix.gnu.org/64916

it introduced some package build regression as seen in

https://ci.guix.gnu.org/eval/1123386?status=newly-failed

This patch series
fixes them.

Thanks,
Oleg

Sharlatan Hellseher (10):
  gnu: go-github-com-alecthomas-chroma: Move to golang-xyz.
  gnu: go-github-com-alecthomas-chroma: Update to 0.10.0.
  gnu: go-github-com-alecthomas-chroma: Remove bundled files.
  gnu: Add go-github-com-alecthomas-chroma-v2.
  gnu: go-github-com-alecthomas-assert: Depricate package.
  gnu: go-github-com-alecthomas-assert-v2: Update to 2.5.0.
  gnu: go-github-com-songmu-gitconfig: Move to golang-xyz.
  gnu: go-github-com-songmu-gitconfig: Fix build.
  gnu: ghq: Remove package labels.
  gnu: ghq: Fix build.

 gnu/packages/configuration-management.scm |  1 +
 gnu/packages/golang-check.scm | 50 -
 gnu/packages/golang-xyz.scm   | 86 ++-
 gnu/packages/golang.scm   | 55 ---
 gnu/packages/version-control.scm  | 52 +++---
 5 files changed, 125 insertions(+), 119 deletions(-)


base-commit: 91d80460296e2d5a01704d0f34fb966a45a165ae
-- 
2.41.0

bug#69129: sbcl-mcclim broke on upgrade to sbcl@2.4.0

[Sharlatan Hellseher]

Hi Carlo,

> I feel like this work was entirely mechanical, so I would have been
> fine without a copyright header, but I appreciate it.
I think it's reasonable to include copyright to highlight the efforts
contributed ;-). If you check the commit history it usually includes
copyright header for package updates and adjustments.

> I'm curious about the version/commit change, though. Given the -yule
> suffix on the tag name changes with each version we will still need to
> manually update the origin's commit. It feels like unnecessary
> indirection to me. What is the benefit to referencing the package's
> version in the origin like this?
I've done some research on how it looks like in scale, trying to stick
to some constancy, which is hard to determine... so I've decided to keep
version following semantic style and commit as combination of semantic
version and suffix.

How commit is compiled:
--8<---cut here---start->8---
grep "commit.*string-append.*version" gnu/packages/*scm | awk -F: '{print $2}' 
| sed -e 's/^[ \t]*//' | sort | uniq -c | sort -rn
   2780 (commit (string-append "v" version
 46 (commit (string-append "v" version))
 38 (commit (string-append "release-" version
 20 (commit (string-append name "-" version
 12 (commit (string-append "V" version
  9 (commit (string-append "v." version
  9 (commit (string-append "rocm-" version
  8 (commit (string-append "version-" version
  7 (commit (string-append version
  7 (commit (string-append "go" version
  6 (commit (string-append "r" version
  6 (commit (string-append "android-" version
  5 (commit (string-append "release_" version
  5 (commit (string-append "releases/" version
  4 (commit (string-append "VERSION_" version
  4 (commit (string-append "upstream/" version
  4 (commit (string-append "Release_" version
  3 (commit (string-append "rel-" version
  3 (commit (string-append "release/" version
  3 (commit (string-append "jb" version
  3 (commit (string-append "debian/" version
  3 (commit (string-append "apache-arrow-" version
  2 (commit (string-append "wsjtx-" version
  2 (commit (string-append "v" version "-stable"
  2 (commit (string-append "v_" version
  2 (commit (string-append "v" upstream-version
  2 (commit (string-append "v" (string-join (string-split version #\.)
  2 (commit (string-append "ver." version
  2 (commit (string-append "version_" version
  2 (commit (string-append version "-stable"
  2 (commit (string-append "rel" version
  2 (commit (string-append "RELEASE_" version
  2 (commit (string-append "Release-" version
  2 (commit (string-append "release_" version))
  2 (commit (string-append "ppp-" version
  2 (commit (string-append "plexus-utils-" version
  2 (commit (string-append "plexus-containers-" version
  2 (commit (string-append "plexus-components-" version
  2 (commit (string-append "plexus-cipher-" version
  2 (commit (string-append "mbedtls-" version
  2 (commit (string-append "llvmorg-" version
  2 (commit (string-append "jline-parent-" version
  2 (commit (string-append "edk2-stable" version
  2 (commit (string-append "easymock-" version
  2 (commit (string-append "cling-v" %cling-version
  2 (commit (string-append "biojava-" version
  2 (commit (string-append "aether-" version
  1 (commit (string-append "Zstd-v" version
  1 (commit (string-append "Zlib-v" version
  1 (commit (string-append "z3-" version
  1 (commit (string-append "yosys-" version
  1 (commit (string-append "XSLT-v" version
  1 (commit (string-append "Xorg_xtrans-v" version
  1 (commit (string-append "Xorg_xkeyboard_config-v" version
  1 (commit (string-append "Xorg_xkbcomp-v" version
  1 (commit (string-append "Xorg_xcb_util_wm-v" version
  1 (commit (string-append "Xorg_xcb_util-v" version
  1 (commit (string-append "Xorg_xcb_util_renderutil-v" version
  1 (commit (string-append "Xorg_xcb_util_keysyms-v" version
  1 (commit (string-append "Xorg_xcb_util_image-v" version
  1 (commit (string-append "Xorg_libXrender-v" version
  1 (commit (string-append "Xorg_libXrandr-v" version
  1 (commit (string-append "Xorg_libxkbfile-v" version
  1 (commit (string-append "Xorg_libXi-v" version
  1 (commit (string-append "Xorg_libXinerama-v" version
  1 (commit (string-append "Xorg_libXfixes-v" version
  1 (commit (string-append "Xorg_libXext-v" version
  1 (commit (string-append "Xorg_libXdmcp-v" version
  1 (commit (string-append "Xorg_libXcursor-v" version
  1 (commit (string-append 

bug#69129: sbcl-mcclim broke on upgrade to sbcl@2.4.0

[Sharlatan Hellseher]

Hi,

I've added copyright header and use version field for commit.

Pushed as 4fecd14409..3cf199dbcf to master.

--
Oleg


signature.asc
Description: PGP signature

bug#69129: [PATCH] gnu: sbcl-mcclim: Update to 0.9.8.

[Sharlatan Hellseher]

Hi Carlo,

Thank you for the patch!

May you split it into 2 please? One just updating version and adding missing
inputs the other indent it. It would ease the review process to visually
identify what was changed.

Looking froward for v2!

Thanks,
Oleg

bug#69125: python-trio transient test failures

[Sharlatan Hellseher]

Hi Josselin,

If we have a look at CI builds

https://ci.guix.gnu.org/search?query=python-trio%200.21.0%20spec:master

there are more failed builds than successful ones : -)

Maybe it's time to update it or disable some shaky tests.

WDYT?

Thanks,
Oleg

bug#53533: [DISCUSSION] Quality of services in reproducible build environment Guix

[Sharlatan Hellseher]

Hi,

I think I can close this now as all questions were covered.

Thanks,
Oleg


signature.asc
Description: PGP signature

bug#53423: nncp: Fails to build (renamed file not found)

[Sharlatan Hellseher]

Hi Vagrant,

Thank you for the ping on this issue.

It was on my radar to update nncp as the package was failed to build for
a long time and quite dated.

It looks like the current version is not compatible with versions of
golang packages available in Guix anymore. I have a chance to bump it to
the 8.0.0 to check if it may fix the build but it did not work any more and
the whole package need proper refactoring.

I'll place upgrading it to my TODO list.

Thanks,
Oleg


signature.asc
Description: PGP signature

bug#68835: Resolving package inheritance issue

[Sharlatan Hellseher]

Hi Guix!

> ./etc/teams.scm cc core
- g...@cbaines.net
- d...@jpoiret.xyz
- l...@gnu.org
- othac...@gnu.org
- rek...@elephly.net
- zimon.touto...@gmail.com
- m...@tobias.gr

Long story short, how to resolve package inheritance which would not
break CI ;-) ?

While reviewing and amending patch series from
 I've stabilized it on my local
checkout, which passed complete reconfigure and rebuild few times
(not...).

When I've pushed changes to 
the commit f8c2d8141efef4565d12d8247bade069889b720e broke CI
.

--8<---cut here---start->8---
In unknown file:
   6 (primitive-load-path "gnu/packages/web" #)
In ice-9/eval.scm:
619:8  5 (_ #f)
   626:19  4 (_ #)
   173:55  3 (_ #(#(#(# "minify") 
#) #))
159:9  2 (_ #(#(#(# "minify") 
#) #))
   223:20  1 (proc #(#(#(# "minify") 
#) #))
In unknown file:
   0 (%resolve-variable (7 . go-github-com-tdewolff-minify-v2) 
#)

ERROR: In procedure %resolve-variable:
error: go-github-com-tdewolff-minify-v2: unbound variable
--8<---cut here---end--->8---

My rational was to keep golang module in (gnu packages golang-web) and
the new inherited package providing executable in (gnu packages web)
which introduced the regression.

Here it is that bad boy!
--8<---cut here---start->8---
(define-public minify
  (package
(inherit go-github-com-tdewolff-minify-v2)
(name "minify")
(arguments
 (substitute-keyword-arguments
 (package-arguments go-github-com-tdewolff-minify-v2)
   ((#:install-source? _ #t) #f)
   ((#:import-path _ "github.com/tdewolff/minify/v2")
"github.com/tdewolff/minify/cmd/minify")))
(inputs
 (list go-github-com-djherbis-atime
   go-github-com-dustin-go-humanize
   go-github-com-fsnotify-fsnotify
   go-github-com-matryer-try
   go-github-com-spf13-pflag
--8<---cut here---end--->8---

Having that all too close to my heart I've pushed revert commit
c4687f5437ad89a7e87deed1933b60f6eac83176 wich fixed CI and `guix pull`.

I've started reviewing what could be wrong and maybe the current split
process of (gnu packages golang) into logical modules e.g. golang-xyz,
golang-check, golang-crypto, golang-web introduced deep level of
circular dependencies among Guile modules.

I search for solutions to mitigate the introduced issue.

My plan is to start cleaning up dependency to (gnu packages golang) for
each recently introduced module by moving packages away from it into
groups.

I would be appreciated on any documentation link or examples in code
where package inheritance is used to source package from other module
^.^

Regards,
Oleg


signature.asc
Description: PGP signature

bug#67304: Build python-cdflib.x86_64-linux on master is broken.

[Sharlatan Hellseher]

Hi,

I've open an issue in upstram.
Mean while please check the patch disabling the test.

Thanks,
Oleg

On Mon, 20 Nov 2023 at 22:39, Sharlatan Hellseher  wrote:
>
> Hi Guix,
>
> I've checked the cement to the test and it mentioned as a candidate to be
> removed as it's not stable
>
> https://github.com/MAVENSDC/cdflib/blob/master/tests/test_astropy_epochs.py#L116
> # Unfortunately, currently there is a pretty big loss of
> precision that comes with
> # the compute function.  Need to stop testing early.
>
> We may consider to disable it to stabilize build.
>
> Thanks,
> Oleg
>
> On Mon, 20 Nov 2023 at 19:25, Eric Bavier  wrote:
> >
> > Hi Maxim, thanks for the report.
> >
> > On Mon, 2023-11-20 at 14:02 -0500, Maxim Cournoyer wrote:
> > >
> > > It seems something in the commits series
> > > https://git.savannah.gnu.org/cgit/guix.git/log/?qt=range=2ab5e449246f98b049888dde3c310f5b4a0a64a2..b7abea0fd6a146563830db1dc4ddd0cceb6fcf1c
> > > either broke the test, else it's flaky.
> > >
> >
> > I have built the package locally many times without fail.
> >
> > The failed test is one that checks fidelity of a rountrip time format
> > conversion for a randomly-generated time, so failure may indeed be
> > intermittent.
> >
> > I will try to dig a bit further, and maybe Sharlatan can as well.
> >
> > `~Eric
>
>
>
> --
>
> … наш разум - превосходная объяснительная машина которая способна
> найти смысл почти в чем угодно, истолковать любой феномен, но
> совершенно не в состоянии принять мысль о непредсказуемости.



-- 

… наш разум - превосходная объяснительная машина которая способна
найти смысл почти в чем угодно, истолковать любой феномен, но
совершенно не в состоянии принять мысль о непредсказуемости.
From 2f55a5ac236952ea24d81998da488cff4553c272 Mon Sep 17 00:00:00 2001
Message-ID: <2f55a5ac236952ea24d81998da488cff4553c272.1700520904.git.sharlata...@gmail.com>
From: Sharlatan Hellseher 
Date: Mon, 20 Nov 2023 22:52:52 +
Subject: [PATCH] gnu: python-cdflib: Disable shaky test.

* gnu/packages/astronomy.scm (python-cdflib): Disable one test which
causing random build failure.
[arguments]{test-flags}: Add it.

Change-Id: I05ee2feca3bc0f0139fa1a5f00b4fe260b42ec80
---
 gnu/packages/astronomy.scm | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/gnu/packages/astronomy.scm b/gnu/packages/astronomy.scm
index c063285b52..da15283ef3 100644
--- a/gnu/packages/astronomy.scm
+++ b/gnu/packages/astronomy.scm
@@ -1807,7 +1807,10 @@ (define-public python-cdflib
 (base32 "0vpgcbc9pmx0qqfia1frnwq3jkgfp8y3ikqdnzs5bs1sr13p9p3w"
 (build-system pyproject-build-system)
 (arguments
- (list #:phases
+ ;; Disable shaky test.
+ ;; See https://github.com/MAVENSDC/cdflib/issues/234
+ (list #:test-flags #~(list "-k" "not test_compute_cdfepoch16")
+   #:phases
#~(modify-phases %standard-phases
(add-before 'build 'set-env-version
  (lambda _

base-commit: d20ece07dbb09382f361c8bbf0bcab9e83d8b73e
-- 
2.41.0

bug#67304: Build python-cdflib.x86_64-linux on master is broken.

[Sharlatan Hellseher]

Hi Guix,

I've checked the cement to the test and it mentioned as a candidate to be
removed as it's not stable

https://github.com/MAVENSDC/cdflib/blob/master/tests/test_astropy_epochs.py#L116
# Unfortunately, currently there is a pretty big loss of
precision that comes with
# the compute function.  Need to stop testing early.

We may consider to disable it to stabilize build.

Thanks,
Oleg

On Mon, 20 Nov 2023 at 19:25, Eric Bavier  wrote:
>
> Hi Maxim, thanks for the report.
>
> On Mon, 2023-11-20 at 14:02 -0500, Maxim Cournoyer wrote:
> >
> > It seems something in the commits series
> > https://git.savannah.gnu.org/cgit/guix.git/log/?qt=range=2ab5e449246f98b049888dde3c310f5b4a0a64a2..b7abea0fd6a146563830db1dc4ddd0cceb6fcf1c
> > either broke the test, else it's flaky.
> >
>
> I have built the package locally many times without fail.
>
> The failed test is one that checks fidelity of a rountrip time format
> conversion for a randomly-generated time, so failure may indeed be
> intermittent.
>
> I will try to dig a bit further, and maybe Sharlatan can as well.
>
> `~Eric



-- 

… наш разум - превосходная объяснительная машина которая способна
найти смысл почти в чем угодно, истолковать любой феномен, но
совершенно не в состоянии принять мысль о непредсказуемости.

bug#65765: nil

[Sharlatan Hellseher]

bug#66297: guix-daemon not starting after boot

[Sharlatan Hellseher]

Hi,

I think I just get used to kick it manually and forgot to replay on
this issue =)

No Herd/Shepherd logs since Sept 30 in messages

 sudo grep -i "shepherd\|herd" /var/log/messages  | tail
grep: /var/log/messages: binary file matches
Sep 30 21:16:03 localhost shepherd[1]: Service console-font-tty3
running with value #t.
Sep 30 21:16:03 localhost shepherd[1]: Service console-font-tty4 started.
Sep 30 21:16:03 localhost vmunix: [2.427621] shepherd[1]:
Sep 30 21:16:03 localhost vmunix: [2.428262] shepherd[1]:
Sep 30 21:16:03 localhost vmunix: [2.429207] shepherd[1]: Service
sysctl has been started.
Sep 30 21:16:03 localhost vmunix: [2.429434] shepherd[1]: Service
sysctl started.
Sep 30 21:16:03 localhost vmunix: [2.429666] shepherd[1]: Service
sysctl running with value #t.
Sep 30 21:16:03 localhost vmunix: [2.430082] shepherd[1]: Starting
service virtual-terminal...
Sep 30 21:16:03 localhost vmunix: [2.430416] shepherd[1]: Service
virtual-terminal started.
Sep 30 21:16:03 localhost vmunix: [2.430649] shepherd[1]: Service
virtual-terminal running with value #t.

There this no track of guix-daemon was starting in herd log

herd log | grep daemon
10 Oct 2023 00:03:30service upower-daemon is being started
10 Oct 2023 00:03:30service upower-daemon is running
10 Oct 2023 00:03:30service ssh-daemon is being started
10 Oct 2023 00:03:30service ssh-daemon is running

Thanks,
Oleg

On Thu, 5 Oct 2023 at 14:39, Ludovic Courtès  wrote:
>
> Hi,
>
> Sharlatan Hellseher  skribis:
>
> > After the recent pull and system reconfigure I've started experiencing
> > guix-daemon not starting up after the system boot.
>
> Anything in /var/log/messages?
>
> What does ‘herd log’ say?
>
> Thanks,
> Ludo’.



-- 

… наш разум - превосходная объяснительная машина которая способна
найти смысл почти в чем угодно, истолковать любой феномен, но
совершенно не в состоянии принять мысль о непредсказуемости.

bug#66297: guix-daemon not starting after boot

[Sharlatan Hellseher]

Hi Guix!

After the recent pull and system reconfigure I've started experiencing
guix-daemon not starting up after the system boot.

~# guix describe
Generation 29   Sep 27 2023 21:59:12(current)
  guix 0500af5
repository URL: https://git.savannah.gnu.org/git/guix.git
branch: master
commit: 0500af5556307d0a4c14a23864e9e4bccd2643d7
  nonguix bb184bd
repository URL: https://gitlab.com/nonguix/nonguix
branch: master
commit: bb184bd0a8f91beec3a00718759e96c7828853de

~# guix pull
guix pull: error: failed to connect to
`/var/guix/daemon-socket/socket': Connection refused
~# herd status guix-daemon
Status of guix-daemon:
  It is stopped.
  It is enabled.
  Provides (guix-daemon).
  Requires (user-processes).
  Will be respawned.

Logs are empty:
~# tail /var/log/guix-daemon.log | wc -l
0


-- 
… наш разум - превосходная объяснительная машина которая способна
найти смысл почти в чем угодно, истолковать любой феномен, но
совершенно не в состоянии принять мысль о непредсказуемости.

bug#65765:

[Sharlatan Hellseher]

Hi,

May you provide the way how to reproduce it?

> guix time-machine --no-channel-files 
> --commit=6113e0529d61df7425f64e30a6bf77f7cfdfe5a5 -- build celluloid
> /gnu/store/dps6ra33zfgpga7wig085p5k3bwdxqz2-celluloid-0.25

-- 
… наш разум - превосходная объяснительная машина которая способна
найти смысл почти в чем угодно, истолковать любой феномен, но
совершенно не в состоянии принять мысль о непредсказуемости.

bug#63427:

[Sharlatan Hellseher]

Hi,

How to reproduce the issue? May you, please provide some steps please.

-- 
… наш разум - превосходная объяснительная машина которая способна
найти смысл почти в чем угодно, истолковать любой феномен, но
совершенно не в состоянии принять мысль о непредсказуемости.

bug#63171:

[Sharlatan Hellseher]

Hi Apoorve,

Did you try to fix it?

It's failed in timemachine:

> guix time-machine --commit=64086a4fa449a9f6d2f835fcdf5498222b309e3a -- build 
> telegram-desktop -q
> guix build: error: build of 
> `/gnu/store/askm28ydsvx5iqr9lfqgp3vs7qzdwdzj-telegram-desktop-4.2.2.drv' 
> failed

Thanks,
Oleg
-- 
… наш разум - превосходная объяснительная машина которая способна
найти смысл почти в чем угодно, истолковать любой феномен, но
совершенно не в состоянии принять мысль о непредсказуемости.

bug#43579:

[Sharlatan Hellseher]

Hi,

Adding more petrol to ther fire:
I try to upgrade casacore to 3.5.0 which failed due to mentined
problem with C++:
---
[ 36%] Building CXX object
tables/Dysco/CMakeFiles/tDysco.dir/tests/runtests.cc.o


  [5/1881]
cd /tmp/guix-build-casacore-3.5.0.drv-0/build/tables/Dysco &&
/gnu/store/069aq2v993kpc41yabp5b6vm4wb9jkhg-gcc-10.3.0/bin/c++
-DBOOST_ALL_NO_LIB -DBOOST_ATOMIC_DYN_LINK -DBOOST_FILESYSTEM_DYN_LINK
-DBOOST_SYSTEM_DYN_LINK -DCFITSIO_VERSION_MAJOR=4
-DCFITSIO_VERSION_MINOR=200
-DHAVE_DYSCO -DHAVE_FFTW3 -DHAVE_FFTW3_THREADS -DHAVE_HDF5
-DHAVE_O_DIRECT -DHAVE_READLINE -DUSE_THREADS -DWCSLIB_VERSION_MAJOR=7
-DWCSLIB_VERSION_MINOR=12
-I/tmp/guix-build-casacore-3.5.0.drv-0/source
-I/tmp/guix-build-casacore-3.5.0.drv-0/build
-I/gnu/store/c2rz0vskpib35i
7jwx8s3i92fh8m5izq-wcslib-7.12/include
-I/gnu/store/s3kcslq2kycphdpzdjc93dnlmxrk599h-cfitsio-4.2.0/include
-I/gnu/store/imz1fhpcg603a4ny7k9yla72d6y302aw-hdf5-1.10.7/include
-I/gnu/store/hc7gxhfrawmwhqp7wf2xqxpkn3zx9mba-fftw-3.3.8/include
-I/tmp/guix-build-casacore-3.5.0.drv
-0/build/tables -isystem
/gnu/store/hm6dlgzkqz33fbiba07jjh8yzdikn7pp-boost-1.77.0/include
-fcx-fortran-rules -Wextra -Wall -W -Wpointer-arith
-Woverloaded-virtual -Wwrite-strings -pedantic -Wno-long-long
-std=c++11 -pthread -O2 -g -DNDEBUG -O3 -Wall -DNDEBUG -march=native -
std=c++11 -MD -MT
tables/Dysco/CMakeFiles/tDysco.dir/tests/runtests.cc.o -MF
CMakeFiles/tDysco.dir/tests/runtests.cc.o.d -o
CMakeFiles/tDysco.dir/tests/runtests.cc.o -c
/tmp/guix-build-casacore-3.5.0.drv-0/source/tables/Dysco/tests/runtests.cc
In file included from
/gnu/store/hm6dlgzkqz33fbiba07jjh8yzdikn7pp-boost-1.77.0/include/boost/detail/fenv.hpp:97,
 from
/gnu/store/hm6dlgzkqz33fbiba07jjh8yzdikn7pp-boost-1.77.0/include/boost/test/execution_monitor.hpp:64,
 from
/gnu/store/hm6dlgzkqz33fbiba07jjh8yzdikn7pp-boost-1.77.0/include/boost/test/impl/compiler_log_formatter.ipp:22,
 from
/gnu/store/hm6dlgzkqz33fbiba07jjh8yzdikn7pp-boost-1.77.0/include/boost/test/included/unit_test.hpp:18,
 from
/tmp/guix-build-casacore-3.5.0.drv-0/source/tables/Dysco/tests/runtests.cc:4:
/gnu/store/9dfwr7gh59iwg2wary3w853rnjzzk3r7-gfortran-10.3.0/include/c++/fenv.h:58:11:
error: ‘fenv_t’ has not been declared in ‘::’
   58 |   using ::fenv_t;
  |   ^~
/gnu/store/9dfwr7gh59iwg2wary3w853rnjzzk3r7-gfortran-10.3.0/include/c++/fenv.h:59:11:
error: ‘fexcept_t’ has not been declared in ‘::’
   59 |   using ::fexcept_t;
  |   ^
/gnu/store/9dfwr7gh59iwg2wary3w853rnjzzk3r7-gfortran-10.3.0/include/c++/fenv.h:62:11:
error: ‘feclearexcept’ has not been declared in ‘::’
   62 |   using ::feclearexcept;
  |   ^
/gnu/store/9dfwr7gh59iwg2wary3w853rnjzzk3r7-gfortran-10.3.0/include/c++/fenv.h:63:11:
error: ‘fegetexceptflag’ has not been declared in ‘::’
   63 |   using ::fegetexceptflag;
  |   ^~~
/gnu/store/9dfwr7gh59iwg2wary3w853rnjzzk3r7-gfortran-10.3.0/include/c++/fenv.h:64:11:
error: ‘feraiseexcept’ has not been declared in ‘::’
   64 |   using ::feraiseexcept;
  |   ^
/gnu/store/9dfwr7gh59iwg2wary3w853rnjzzk3r7-gfortran-10.3.0/include/c++/fenv.h:65:11:
error: ‘fesetexceptflag’ has not been declared in ‘::’
   65 |   using ::fesetexceptflag;
  |   ^~~
/gnu/store/9dfwr7gh59iwg2wary3w853rnjzzk3r7-gfortran-10.3.0/include/c++/fenv.h:66:11:
error: ‘fetestexcept’ has not been declared in ‘::’
   66 |   using ::fetestexcept;
  |   ^~~~
/gnu/store/9dfwr7gh59iwg2wary3w853rnjzzk3r7-gfortran-10.3.0/include/c++/fenv.h:68:11:
error: ‘fegetround’ has not been declared in ‘::’
   68 |   using ::fegetround;
  |   ^~
/gnu/store/9dfwr7gh59iwg2wary3w853rnjzzk3r7-gfortran-10.3.0/include/c++/fenv.h:69:11:
error: ‘fesetround’ has not been declared in ‘::’
   69 |   using ::fesetround;
  |   ^~
/gnu/store/9dfwr7gh59iwg2wary3w853rnjzzk3r7-gfortran-10.3.0/include/c++/fenv.h:71:11:
error: ‘fegetenv’ has not been declared in ‘::’
   71 |   using ::fegetenv;
  |   ^~~~
/gnu/store/9dfwr7gh59iwg2wary3w853rnjzzk3r7-gfortran-10.3.0/include/c++/fenv.h:72:11:
error: ‘feholdexcept’ has not been declared in ‘::’
   72 |   using ::feholdexcept;
  |   ^~~~
/gnu/store/9dfwr7gh59iwg2wary3w853rnjzzk3r7-gfortran-10.3.0/include/c++/fenv.h:73:11:
error: ‘fesetenv’ has not been declared in ‘::’
   73 |   using ::fesetenv;
  |   ^~~~
/gnu/store/9dfwr7gh59iwg2wary3w853rnjzzk3r7-gfortran-10.3.0/include/c++/fenv.h:74:11:
error: ‘feupdateenv’ has not been declared in ‘::’
   74 |   using ::feupdateenv;
  |   ^~~
In file included from
/gnu/store/hm6dlgzkqz33fbiba07jjh8yzdikn7pp-boost-1.77.0/include/boost/test/included/unit_test.hpp:23,
 from

bug#58586:

[Sharlatan Hellseher]

Hi Chris,

This issue is resolved now with listed patches applied.

Regards,
Oleg

-- 
… наш разум - превосходная объяснительная машина которая способна
найти смысл почти в чем угодно, истолковать любой феномен, но
совершенно не в состоянии принять мысль о непредсказуемости.

bug#59200:

[Sharlatan Hellseher]

Hi,

I've got the same issue while packing cl-graph which has cl-containers as
one of the inputs. It's fails exactly the same where it can't assess
cl-containers FASL file.

Regards,
Oleg

bug#58586:

[Sharlatan Hellseher]

Hi Guix!

This issue could be marked as resolved with after merging patches from here
https://issues.guix.gnu.org/59113

Regards,
Oleg

-- 
… наш разум - превосходная объяснительная машина которая способна
найти смысл почти в чем угодно, истолковать любой феномен, но
совершенно не в состоянии принять мысль о непредсказуемости.

bug#58586:

[Sharlatan Hellseher]

Hi,

I've sent patches in separate thread which fix this this issue:

https://issues.guix.gnu.org/58645

Regards,
Oleg

-- 
… наш разум - превосходная объяснительная машина которая способна
найти смысл почти в чем угодно, истолковать любой феномен, но
совершенно не в состоянии принять мысль о непредсказуемости.

bug#58586: Astropy 5.0.1 tests failed after staging->master marge

[Sharlatan Hellseher]

Hi Guix team,

It looks like Astropy stoped building with failed tests after commit
c567a82a6975e70c8207a4aeed55a72b5121213c.:

-
E   DeprecationWarning: FLIP_TOP_BOTTOM is deprecated and will be
removed in Pillow 10 (2023-07-01). Use Transpose.FLIP_TOP_BOTTOM
instead.

/gnu/store/q3hdznwiyz7ywhmfnddv9b3g3v1plhqw-python-pillow-9.2.0/lib/python3.9/site-packages/PIL/_deprecate.py:62:
DeprecationWarning
=== short test summary info 
FAILED 
astropy/visualization/wcsaxes/tests/test_misc.py::test_no_numpy_warnings[lines]
FAILED 
astropy/visualization/wcsaxes/tests/test_misc.py::test_no_numpy_warnings[contours]
FAILED astropy/visualization/wcsaxes/tests/test_misc.py::test_plt_imshow_origin
FAILED astropy/visualization/wcsaxes/tests/test_misc.py::test_ax_imshow_origin
FAILED astropy/visualization/wcsaxes/tests/test_wcsapi.py::test_edge_axes - D...
= 5 failed, 18427 passed, 1065 skipped, 126 deselected, 67 xfailed in
262.41s (0:04:22) =
error: in phase 'check': uncaught exception:
%exception #< program: "python" arguments: ("-m" "pytest"
"--pyargs" "astropy" "-m" "not remote_data") exit-status: 1
term-signal: #f stop-signal: #f>
phase `check' failed after 269.2 seconds
-

The test failing isues comes from Pillow update
https://github.com/astropy/astropy/issues/13044 and fixed in the
latest release of Astropy.

I've tried to urade it to the latest 5.1 but it requires:

https://github.com/astropy/astropy/blob/v5.1/setup.cfg#L57
pytest>=7.0

So I've stoped here for now. I'll give it a go to have all the chain
to be upgraded and see how deep it will go. This blocking me to sent
patches for SunPy which were built just fine :).

Regards,
Oleg

-- 
… наш разум - превосходная объяснительная машина которая способна
найти смысл почти в чем угодно, истолковать любой феномен, но
совершенно не в состоянии принять мысль о непредсказуемости.

bug#42601:

[Sharlatan Hellseher]

Hi,

I have experienced the same issue to build a package in Guix source.
It's built just fine outside the source.
My package definition
https://git.sr.ht/~hellseher/ffab/tree/5c3071c6e3490ee285d245ada5e161cd272a161f/item/ffab/packages/lisp-xyz.scm#L50

> ./pre-inst-env guix describe
Git checkout:
  repository: /mnt/library/code/guix
  branch: local/lisp-xyz/glop
  commit: c23d4871a609018b16ce27f2a131f9a20bf075c2
[env: /gnu/store/q781h6gmv1n2d05gkjs0fq84fjis78v3-profile]

Throw to key `unbound-variable' with args `("resolve-interface" "no
binding `~A' in module ~A" (python (gnu packages python)) #f)'.
Backtrace:
In guix/store.scm:
   659:37 19 (thunk)
   1298:8 18 (call-with-build-handler # …)
In guix/scripts/build.scm:
567:2 17 (_)
In srfi/srfi-1.scm:
   673:15 16 (append-map _ _ . _)
   586:17 15 (map1 ((argument . "sbcl-glop") (build-mode . 0) (. #) …))
In guix/scripts/build.scm:
   587:31 14 (_ _)
In gnu/packages.scm:
479:2 13 (%find-package "sbcl-glop" "sbcl-glop" #f)
364:6 12 (find-best-packages-by-name _ _)
   294:56 11 (_ "sbcl-glop" _)
In unknown file:
  10 (force #)
In gnu/packages.scm:
   241:33  9 (fold-packages # …)
In guix/discovery.scm:
   159:11  8 (all-modules _ #:warn _)
In srfi/srfi-1.scm:
   460:18  7 (fold # …)
In guix/discovery.scm:
   149:19  6 (_ _ ())
116:5  5 (scheme-modules _ _ #:warn _)
In srfi/srfi-1.scm:
   691:23  4 (filter-map # . #)
In guix/discovery.scm:
   124:24  3 (_ . _)
In guix/ui.scm:
319:2  2 (report-unbound-variable-error _ #:frame _)
In ice-9/boot-9.scm:
  1685:16  1 (raise-exception _ #:continuable? _)
  1685:16  0 (raise-exception _ #:continuable? _)

ice-9/boot-9.scm:1685:16: In procedure raise-exception:
Throw to key `match-error' with args `("match" "no matching pattern"
(unbound-variable "resolve-interface" "no binding `~A' in module ~A"
(python (gnu packages python)) #f))'.



-- 
… наш разум - превосходная объяснительная машина которая способна
найти смысл почти в чем угодно, истолковать любой феномен, но
совершенно не в состоянии принять мысль о непредсказуемости.

bug#50624:

[Sharlatan Hellseher]

Hi,

I've got the same when I try to build new package from latest
checkout, it's built from channel
https://git.sr.ht/~hellseher/ffab/tree/main/item/ffab/packages/lisp-xyz.scm#L50

[env: /gnu/store/46kmhq1wkbzsdxv09k774hlak3xvvc5q-profile]
> ./pre-inst-env guix build sbcl-glop
;;; note: source file /mnt/library/code/guix/gnu/packages/lisp-xyz.scm
;;;   newer than compiled /mnt/library/code/guix/gnu/packages/lisp-xyz.go
;;; note: source file /mnt/library/code/guix/gnu/packages/lisp-xyz.scm
;;;   newer than compiled
/run/current-system/profile/lib/guile/3.0/site-ccache/gnu/packages/lisp-xyz.go
;;; note: source file /mnt/library/code/guix/gnu/packages/lisp-xyz.scm
;;;   newer than compiled
/run/current-system/profile/lib/guile/3.0/site-ccache/gnu/packages/lisp-xyz.go
error: libxrandr: unbound variable
hint: Did you forget a `use-modules' form?

error: googletest: unbound variable
hint: Did you forget a `use-modules' form?

error: bzip2: unbound variable
hint: Did you forget a `use-modules' form?

error: binutils: unbound variable
hint: Did you forget a `use-modules' form?

error: gcc-4.9: unbound variable
hint: Did you forget a `use-modules' form?

error: xz: unbound variable
hint: Did you forget a `use-modules' form?

error: gash: unbound variable
hint: Did you forget a `use-modules' form?

error: gnu-make: unbound variable
hint: Did you forget a `use-modules' form?

error: binutils: unbound variable
hint: Did you forget a `use-modules' form?

error: ffmpeg: unbound variable
hint: Did you forget a `use-modules' form?

error: xorg-server: unbound variable
hint: Did you forget a `use-modules' form?

error: libdvdnav: unbound variable
hint: Did you forget a `use-modules' form?

error: perl: unbound variable
hint: Did you forget a `use-modules' form?

error: coreutils: unbound variable
hint: Did you forget a `use-modules' form?

error: libetpan: unbound variable
hint: Did you forget a `use-modules' form?

error: openmpi: unbound variable
hint: Did you forget a `use-modules' form?

Throw to key `unbound-variable' with args `("resolve-interface" "no
binding `~A' in module ~A" (python (gnu packages python)) #f)'.
Backtrace:
In guix/store.scm:
   659:37 19 (thunk)
   1298:8 18 (call-with-build-handler # …)
In guix/scripts/build.scm:
567:2 17 (_)
In srfi/srfi-1.scm:
   673:15 16 (append-map _ _ . _)
   586:17 15 (map1 ((argument . "sbcl-glop") (build-mode . 0) (. #) …))
In guix/scripts/build.scm:
   587:31 14 (_ _)
In gnu/packages.scm:
480:2 13 (%find-package "sbcl-glop" "sbcl-glop" #f)
365:6 12 (find-best-packages-by-name _ _)
   295:56 11 (_ "sbcl-glop" _)
In unknown file:
  10 (force #)
In gnu/packages.scm:
   242:33  9 (fold-packages # …)
In guix/discovery.scm:
   159:11  8 (all-modules _ #:warn _)
In srfi/srfi-1.scm:
   460:18  7 (fold # …)
In guix/discovery.scm:
   149:19  6 (_ _ ())
116:5  5 (scheme-modules _ _ #:warn _)
In srfi/srfi-1.scm:
   691:23  4 (filter-map # . #)
In guix/discovery.scm:
   124:24  3 (_ . _)
In guix/ui.scm:
319:2  2 (report-unbound-variable-error _ #:frame _)
In ice-9/boot-9.scm:
  1685:16  1 (raise-exception _ #:continuable? _)
  1685:16  0 (raise-exception _ #:continuable? _)

ice-9/boot-9.scm:1685:16: In procedure raise-exception:
Throw to key `match-error' with args `("match" "no matching pattern"
(unbound-variable "resolve-interface" "no binding `~A' in module ~A"
(python (gnu packages python)) #f))'.
[env: /gnu/store/46kmhq1wkbzsdxv09k774hlak3xvvc5q-profile]
> ./pre-inst-env guix describe
Git checkout:
  repository: /mnt/library/code/guix
  branch: local/lisp-xyz/glop
  commit: c4e03f82047a6a2a07cb34c94d2280183a901e8e

-- 
… наш разум - превосходная объяснительная машина которая способна
найти смысл почти в чем угодно, истолковать любой феномен, но
совершенно не в состоянии принять мысль о непредсказуемости.

bug#53533: [DISCUSSION] Quality of services in reproducible build environment Guix

[Sharlatan Hellseher]

Hi Guix team!

The current QA for the accepted changes in Gujx is far away from
trustible. For example, some
changes in package update may cause a faileur of the whole chain of
packages depending on it. It
would be nice to have some soft policy of changes, check list or some
procedure to have a "stable"
branch which may guarantee all packages build successfully and pass of
all enabled tests.

I find current [[id:60941898-0ed4-4188-b473-d2dcda158d61][CI/CD]]
(https://ci.guix.gnu.org/) is missleading in case of providing some
visibility
of all successful builds for the current pushed changes (on master
branch). I would like to conclude
from the CI is which commit broke how many packages. Other open
question - if I've sticked to a
specific "stable" branch how I may be sure that another ~guix pull~
will not break my packages in
case of un-pinned version?

Some missing features of CI
- Timing - current view has missing a clear representation of build date-time
- Overall slats for the current commit to the specific branch - and
how many package are become
  broken after update of package X.
- Sort of "blocking on merge" of a commit which causes some issues (do
not merge broken packages
  into stable branch)
- Some documentation for all UI features (green dots, red dots, grey dots etc.
  https://ci.guix.gnu.org/eval/54326/dashboard)

Some missing practice of packaging:
- Some essential message of the reason why tests were disabled and any
sort of suggestions on how to
  make them enabled. Contact upstream if required.
- Before sending patch make sure (at least for the localhost
architecture) it's built, linted and in
  case of bumping version - all dependent chain still can be built.

Related commits and issues which broke other packages in ~master~ branch:
- https://issues.guix.gnu.org/53230
- fix 6445f412b993ec7b52dc4c81e99f49af38b3a967 RawTherapee stopped
building with wrong configure key,
  the previous update to 5.8 was never tested before been merged.

  #+begin_src sh
git checkout master
git pull
git log -n1 --pretty="%h %s %cd - %cn"
  #+end_src
  : 4235c6ee92 gnu: QGIS: Build without QtWebKit. Tue Jan 25 15:10:19
2022 -0500 - Leo Famulari

  Excess changes which could be prevented with just local attempt to build
  #+begin_src sh
git log --grep="Fix build" --pretty="%h %s %cd - %cn" | wc -l
  #+end_src
  : 1025


-- 
… наш разум - превосходная объяснительная машина которая способна
найти смысл почти в чем угодно, истолковать любой феномен, но
совершенно не в состоянии принять мысль о непредсказуемости.

bug#46333: sbcl-common-lisp-jupyter does not install kernel.json

[Sharlatan Hellseher]

(head, exist_ok=exist_ok)
  File 
"/gnu/store/hq7qr7nc2j29z3pivm3azfjy6jq3d7nx-python-3.8.2/lib/python3.8/os.py",
line 213, in makedirs
makedirs(head, exist_ok=exist_ok)
  File 
"/gnu/store/hq7qr7nc2j29z3pivm3azfjy6jq3d7nx-python-3.8.2/lib/python3.8/os.py",
line 213, in makedirs
makedirs(head, exist_ok=exist_ok)
  [Previous line repeated 12 more times]
  File 
"/gnu/store/hq7qr7nc2j29z3pivm3azfjy6jq3d7nx-python-3.8.2/lib/python3.8/os.py",
line 223, in makedirs
mkdir(name, mode)
--8<---cut here---end--->8---

On Wed, 19 May 2021 at 22:23, Sharlatan Hellseher  wrote:
>
> Hi,
>
> I've checked the r-irkernel and it's coping existing kernelspec ,
> which is not useful in this case.
>
> As Guillaume mentioned we could tweak it before installation phase by
> using cl-jupyter:install, so here is my draft:
>
> --8<---cut here---start->8---
> (arguments
>  `(#:phases
>(modify-phases %standard-phases
>  (add-before 'install 'generate-kernelspec
>(lambda* (#:key outputs #:allow-other-keys)
>  (let* ((out (assoc-ref outputs "out"))
> (kernelspec (string-append out
> "/share/cl-jupyter/kernelspec")))
>(mkdir-p kernelspec)
>(invoke "sbcl"
>"--eval" "\"(require :asdf)\""
>"--eval" "\"(require :common-lisp-jupyter)\""
>"--eval"
>(string-append
> "\"(cl-jupyter:install"
> ":bin-path" (string-append
>  (assoc-ref %build-inputs "sbcl")
> "/bin/sbcl")
> ":prefix" out ")\"")
>"--eval" "\"(exit)\""))
>  #t))
>  (add-after 'install 'install-kernelspec
>(lambda* (#:key outputs #:allow-other-keys)
>  (let ((out (assoc-ref outputs "out"))
>(kernelspec (string-append out
> "/share/cl-jupyter/kernelspec")))
>(invoke "jupyter" "kernelspec" "install"
>"--name" "cl-jupyter"
>"--prefix" out
>kernelspec)
>#t))
> --8<---cut here---end--->8---
>
> But there could be a potential blocking issue with :prefix key
>
> https://github.com/yitzchak/common-lisp-jupyter/issues/78
>
> On Tue, 18 May 2021 at 16:58, Guillaume Le Vaillant  wrote:
> >
> > Hi Jack,
> >
> > I guess it will be easier to just add a phase writing the "kernel.json"
> > file in the right place. In this build phase, to know if the package is
> > being built for SBCL or ECL, the '(%lisp-type)' function that will
> > return "sbcl" or "ecl" can be used. There's an example in the
> > sbcl-trivial-backtrace package.
>
>
>
> --
>
> … наш разум - превосходная объяснительная машина которая способна
> найти смысл почти в чем угодно, истолковать любой феномен, но
> совершенно не в состоянии принять мысль о непредсказуемости.



-- 

… наш разум - превосходная объяснительная машина которая способна
найти смысл почти в чем угодно, истолковать любой феномен, но
совершенно не в состоянии принять мысль о непредсказуемости.
From cbc17c767069e8fa5175f2f0f30fc961a2be319a Mon Sep 17 00:00:00 2001
From: Sharlatan Hellseher 
Date: Mon, 24 May 2021 22:18:28 +0100
Subject: [PATCH] gnu: common-lisp-jupyter: Format kernelspec

---
 gnu/packages/lisp-xyz.scm | 35 +++
 1 file changed, 35 insertions(+)

diff --git a/gnu/packages/lisp-xyz.scm b/gnu/packages/lisp-xyz.scm
index 4a1e9064d5..91370c62c4 100644
--- a/gnu/packages/lisp-xyz.scm
+++ b/gnu/packages/lisp-xyz.scm
@@ -14897,6 +14897,41 @@ and @code{doseq*}.")
  (sha256
   (base32 "0si69xfzi769dprwfy7gp1x3bl7lxz6d4n98sa26w9r41wvay5ja"
   (build-system asdf-build-system/sbcl)
+  (arguments
+   `(#:phases
+ (modify-phases %standard-phases
+   (add-after 'create-asdf-configuration 'generate-kernelspec
+ (lambda* (#:key outputs #:allow-other-keys)
+   (let* ((out (assoc-ref outputs "out"))
+  (kernelspec (string-append out "/share/cl-jupyter/kernelspec")))
+ (mkdir-p kernelspec)
+ (copy-file (string-a

bug#46333: sbcl-common-lisp-jupyter does not install kernel.json

[Sharlatan Hellseher]

Hi,

I've checked the r-irkernel and it's coping existing kernelspec ,
which is not useful in this case.

As Guillaume mentioned we could tweak it before installation phase by
using cl-jupyter:install, so here is my draft:

--8<---cut here---start->8---
(arguments
 `(#:phases
   (modify-phases %standard-phases
 (add-before 'install 'generate-kernelspec
   (lambda* (#:key outputs #:allow-other-keys)
 (let* ((out (assoc-ref outputs "out"))
(kernelspec (string-append out
"/share/cl-jupyter/kernelspec")))
   (mkdir-p kernelspec)
   (invoke "sbcl"
   "--eval" "\"(require :asdf)\""
   "--eval" "\"(require :common-lisp-jupyter)\""
   "--eval"
   (string-append
"\"(cl-jupyter:install"
":bin-path" (string-append
 (assoc-ref %build-inputs "sbcl")
"/bin/sbcl")
":prefix" out ")\"")
   "--eval" "\"(exit)\""))
 #t))
 (add-after 'install 'install-kernelspec
   (lambda* (#:key outputs #:allow-other-keys)
 (let ((out (assoc-ref outputs "out"))
   (kernelspec (string-append out
"/share/cl-jupyter/kernelspec")))
   (invoke "jupyter" "kernelspec" "install"
   "--name" "cl-jupyter"
   "--prefix" out
   kernelspec)
   #t))
--8<---cut here---end--->8---

But there could be a potential blocking issue with :prefix key

https://github.com/yitzchak/common-lisp-jupyter/issues/78

On Tue, 18 May 2021 at 16:58, Guillaume Le Vaillant  wrote:
>
> Hi Jack,
>
> I guess it will be easier to just add a phase writing the "kernel.json"
> file in the right place. In this build phase, to know if the package is
> being built for SBCL or ECL, the '(%lisp-type)' function that will
> return "sbcl" or "ecl" can be used. There's an example in the
> sbcl-trivial-backtrace package.



--

… наш разум - превосходная объяснительная машина которая способна
найти смысл почти в чем угодно, истолковать любой феномен, но
совершенно не в состоянии принять мысль о непредсказуемости.

bug#48225: Simple workaround

[Sharlatan Hellseher]

Hi,

If chaining  `package-name->name+version` function  may affect a large
layer of infrastructure here is could a quick adhoc workaround:

sbcl-3d-vectors -> sbcl-cl3d-vectors
sbcl-3d-vectors -> sbcl-three-d-vectors
sbcl-3d-vectors -> sbcl-iiid-vectors

Or use any predictable common prefix which could be use and replaced
after the function is reviewed.
-- 
… наш разум - превосходная объяснительная машина которая способна
найти смысл почти в чем угодно, истолковать любой феномен, но
совершенно не в состоянии принять мысль о непредсказуемости.

bug#46424: Use load-systems or load-systems*

[Sharlatan Hellseher]

Hi I've just checked source of ASDF and it looks like there is a
native option to load multiple systems at once

> --8<---cut here---start->8--->
  (defun load-systems* (systems  keys)
"Loading multiple systems at once."
(dolist (s systems) (apply 'load-system s keys)))

  (defun load-systems ( systems)
"Loading multiple systems at once."
(load-systems* systems))
--8<---cut here---end--->8---

https://gitlab.common-lisp.net/asdf/asdf/-/blob/master/operate.lisp#L155

-- 
… наш разум - превосходная объяснительная машина которая способна
найти смысл почти в чем угодно, истолковать любой феномен, но
совершенно не в состоянии принять мысль о непредсказуемости.

bug#46624: Too many heap sections: Increase MAXHINCR or MAX_HEAP_SEC

[Sharlatan Hellseher]

./pre-inst-env guix build sbcl-cffi ;;; note: source file
/home/hellseher/code/guix/gnu/packages/lisp-xyz.scm ;;; newer than
compiled /home/hellseher/code/guix/gnu/packages/lisp-xyz.go Too many
heap sections: Increase MAXHINCR or MAX_HEAP_SECS
Aborted

-- 
… наш разум - превосходная объяснительная машина которая способна
найти смысл почти в чем угодно, истолковать любой феномен, но
совершенно не в состоянии принять мысль о непредсказуемости.

bug#46382: Failed to install Telegram-desktop

[Sharlatan Hellseher]

Hi Guix team!

there is a long chain issue with telegram desktop starting from

guix install telegram-desktop
...
uilding 
/gnu/store/rlpzjc0mfxgl9bdai45055pakdrpzgf9-cmake-helpers-for-telegram-desktop-2.5.1-checkout.drv...
downloading from
https://ci.guix.gnu.org/nar/lzip/qg3q18z8vi1z0wfdi0jkc75bs8b4q3r3-nimf-1.2
... nimf-1.2 1.1MiB 2.0MiB/s 00:01 [##] 100.0%
building 
/gnu/store/ahnnxxdy5z928qxsv5p734lggsj1ak5n-codegen-2.5.1-checkout.drv...
building 
/gnu/store/zzq845cc2idk5c24mgnsjan8i619dl4x-lib-base-for-telegram-desktop-2.5.1-checkout.drv...
building 
/gnu/store/s8qs2hra0xgsgc0nlvc8ssqgscsqjf6l-lib-crl-for-telegram-desktop-2.5.1-checkout.drv...
building 
/gnu/store/glm66g3f991fphf4zj63g8906p2jnh2g-lib-lottie-for-telegram-desktop-2.5.1-checkout.drv...
building 
/gnu/store/y5lqbbjnyp00cdd694p3q0yscldsvq6r-lib-qr-for-telegram-desktop-2.5.1-checkout.drv...
building 
/gnu/store/lcvwzvjdjlpxidr8v5pfvza8v4hrkf2f-lib-rlottie-for-telegram-desktop-2.5.1-checkout.drv...
building 
/gnu/store/72k6gwbibpbyrwq2sg6s80jp66s992ak-lib-rpl-for-telegram-desktop-2.5.1-checkout.drv...
building 
/gnu/store/hnpgrg99a3y1v7wy2wr11pj7cn3yvhs8-lib-spellcheck-for-telegram-desktop-2.5.1-checkout.drv...
building 
/gnu/store/yfris22p1k3v211n0shqppi3malrr5jw-lib-storage-for-telegram-desktop-2.5.1-checkout.drv...
building 
/gnu/store/61w2d20d8zvzrmravxdz4zm75r2zjaav-lib-tl-for-telegram-desktop-2.5.1-checkout.drv...
building 
/gnu/store/xlhmnzdvhf5arvk5mm80sbnskrr7p9l8-lib-ui-for-telegram-desktop-2.5.1-checkout.drv...
building 
/gnu/store/wa605m8939ds4jxz5jcx5mlwrhyq8a5g-lib-webrtc-for-telegram-desktop-2.5.1-checkout.drv...
building /gnu/store/ixb0r6glljn0p5x2v53xcq1z7m2xkzfd-libexpected-1.0.0.drv...
building 
/gnu/store/q9kawg6qqx9k0klay4nlwk1agnm4sfmk-materialdecoration-1.1.0-checkout.drv...
building 
/gnu/store/l9ijsdm4lhi782lmia5328m7rdyv7ddm-module-import-compiled.drv...
building 
/gnu/store/n68qqcxi8xpb0ic1a01gkmfh3871rgwp-materialdecoration-1.1.0.drv...
80% 
[#
] builder for 
`/gnu/store/n68qqcxi8xpb0ic1a01gkmfh3871rgwp-materialdecoration-1.1.0.drv'
failed with exit code 1 build of
/gnu/store/n68qqcxi8xpb0ic1a01gkmfh3871rgwp-materialdecoration-1.1.0.drv
failed View build log at
'/var/log/guix/drvs/n6/8qqcxi8xpb0ic1a01gkmfh3871rgwp-materialdecoration-1.1.0.drv.bz2'.
cannot build derivation
`/gnu/store/s3sd7r18kag8nvbg46c2zbsfsnz01ya5-telegram-desktop-2.5.1.drv':
1 dependencies couldn't be built cannot build derivation
`/gnu/store/w1pnih12rwk3s1mxr8i756wg0j34yklb-profile.drv': 1
dependencies couldn't be built guix install: error: build of
`/gnu/store/w1pnih12rwk3s1mxr8i756wg0j34yklb-profile.drv' failed
...

guix build materialdecoration
...
In file included from
/gnu/store/zzxq7q3fn6pnn1jahyzcf85hm8wakk1x-qtwayland-5.15.2/include/qt5/QtWaylandClient/5.15.2/QtWaylandClient/private/qwaylandwindow_p.h:66:0,
from 
/tmp/guix-build-materialdecoration-1.1.0.drv-0/source/src/plugins/decorations/material/materialdecoration.h:44,
from 
/tmp/guix-build-materialdecoration-1.1.0.drv-0/source/src/plugins/decorations/material/plugin.cpp:24:
/gnu/store/zzxq7q3fn6pnn1jahyzcf85hm8wakk1x-qtwayland-5.15.2/include/qt5/QtWaylandClient/5.15.2/QtWaylandClient/private/qwaylanddisplay_p.h:71:10:
fatal error: QtXkbCommonSupport/private/qxkbcommon_p.h: No such file
or directory #include ^~~ In
file included from
/gnu/store/zzxq7q3fn6pnn1jahyzcf85hm8wakk1x-qtwayland-5.15.2/include/qt5/QtWaylandClient/5.15.2/QtWaylandClient/private/qwaylandwindow_p.h:66:0,
from 
/tmp/guix-build-materialdecoration-1.1.0.drv-0/source/src/plugins/decorations/material/materialdecoration.h:44,
from 
/tmp/guix-build-materialdecoration-1.1.0.drv-0/build/src/plugins/decorations/material/materialdecoration_autogen/EWIEGA46WW/moc_materialdecoration.cpp:10,
from 
/tmp/guix-build-materialdecoration-1.1.0.drv-0/build/src/plugins/decorations/material/materialdecoration_autogen/mocs_compilation.cpp:2:
/gnu/store/zzxq7q3fn6pnn1jahyzcf85hm8wakk1x-qtwayland-5.15.2/include/qt5/QtWaylandClient/5.15.2/QtWaylandClient/private/qwaylanddisplay_p.h:71:10:
fatal error: QtXkbCommonSupport/private/qxkbcommon_p.h: No such file
or directory #include ^~~
compilation terminated. compilation terminated. make[2]: ***
[src/plugins/decorations/material/CMakeFiles/materialdecoration.dir/build.make:66:
src/plugins/decorations/material/CMakeFiles/materialdecoration.dir/materialdecoration_autogen/mocs_compilation.cpp.o]
Error 1 make[2]: *** Waiting for unfinished jobs make[2]: ***
[src/plugins/decorations/material/CMakeFiles/materialdecoration.dir/build.make:92:
src/plugins/decorations/material/CMakeFiles/materialdecoration.dir/plugin.cpp.o]
Error 1 In file included from