bug#70877: guix-daemon fails to copy 4+GB file to store

[Ricardo Wurmus]

Ludovic Courtès  writes:

> Could you confirm that it works for you?

I've applied this locally, started the new daemon, and used it to build
the 4+GB source code derivation of a big package that used to fail
before.  It works now.  Thank you!

-- 
Ricardo

bug#70877: guix-daemon fails to copy 4+GB file to store

[Ricardo Wurmus]

The guix-daemon's libutil/util.cc uses copy_file_range to copy a
downloaded file into the store.  copy_file_range fails on files larger
than 4GB with an error like this:

guix build: error: short write in copy_file_range `15' to `16': No such 
file or directory

The man page for copy_file_range says that it could return EFBIG when
the range exceeds the maximum range.  The daemon code does not check any
limits and will attempt to copy the whole file.

I believe our code ought to check the value of st.size and fall back to
a boring copy if it exceeds some "reasonable" value.

This is where copy_file_range is used:
https://git.savannah.gnu.org/cgit/guix.git/tree/nix/libutil/util.cc#n382

Here is a little reproducer:

(use-modules (guix download)
 (guix packages)
 (guix build-system trivial))

(package
  (name "chungus")
  (version "1")
  (source
   (origin
 (method url-fetch)
 (uri "http://localhost:/chungus;)
 (sha256
  (base32 "0nx67d4ls2nfwcfdmg81vf240z6lpwpdqypssr1wzn3hyz4szci4"
  (build-system trivial-build-system)
  (home-page "")
  (synopsis "")
  (description "")
  (license #f))

--8<---cut here---start->8---
# generate a big file
dd bs=1M count=4096 if=/dev/zero of=/tmp/chungus
# serve it
guix shell woof -- woof -i 127.0.0.1 -p  -c 1 /tmp/chungus
# build the source derivation
guix build --no-grafts -Sf bug.scm
# observe the error
# guix build: error: short write in copy_file_range `15' to `16': No such file 
or directory
--8<---cut here---end--->8---

-- 
Ricardo

bug#70433: customize-kernel does not accept inferior package

[Ricardo Wurmus]

Especially on underpowered aarch64 systems with custom kernels it may be
desirable to avoid rebuilding the kernel on "guix deploy" or "guix
system reconfigure".  It's possible to use an inferior to pin the kernel
to a known good version.

Unfortunately, this doesn't work when attempting to customize the kernel
with "customize-kernel" as that procedure doesn't accept an inferior as
an input package.

-- 
Ricardo

bug#70258: FreeCAD dependency probably outdated

[Ricardo Wurmus]

I'm unable to build python-pivy with the suggested changes.  Here is the
actual diff I used:

diff --git a/gnu/packages/python-xyz.scm b/gnu/packages/python-xyz.scm
index 92566abfed..8c8b162b55 100644
--- a/gnu/packages/python-xyz.scm
+++ b/gnu/packages/python-xyz.scm
@@ -32389,43 +32389,42 @@ (define-public python-retry
 (define-public python-pivy
   (package
 (name "python-pivy")
-(version "0.6.5")
+(version "0.6.9.a0")
 (source
-  (origin
-(method git-fetch)
-(uri (git-reference
-   (url "https://github.com/coin3d/pivy;)
-   (commit version)))
-(file-name (git-file-name name version))
-(sha256
-  (base32 "0vids7sxk8w5vr73xdnf8xdci71a7syl6cd35aiisppbqyyfmykx"
+ (origin
+   (method git-fetch)
+   (uri (git-reference
+ (url "https://github.com/coin3d/pivy;)
+ (commit version)))
+   (file-name (git-file-name name version))
+   (sha256
+(base32 "13v9bfmipfhjbwnrl96d82fgb317j2sijgpzhhk02390649qbx6c"
 (build-system python-build-system)
 (arguments
-  `(;; The test suite fails due to an import cycle between 'pivy' and '_coin'
-#:tests? #f
-#:phases
-(modify-phases %standard-phases
-  (add-after 'unpack 'patch-cmake-include-dirs
+ `( ;; The test suite fails due to an import cycle between 'pivy' and '_coin'
+   #:tests? #f
+   #:phases
+   (modify-phases %standard-phases
+ (add-after 'unpack 'patch-cmake-include-dirs
(lambda _
- ;; Patch buildsystem to respect Coin3D include directory
- (substitute* "CMakeLists.txt"
-  (("\\$\\{SoQt_INCLUDE_DIRS}")
-   "${Coin_INCLUDE_DIR};${SoQt_INCLUDE_DIRS}"))
- #t)
+ ;; Patch build system to respect Coin3D include directory
+ (substitute* "interfaces/CMakeLists.txt"
+   (("\\$\\{SoQt_INCLUDE_DIRS\\}")
+"${Coin_INCLUDE_DIR};${SoQt_INCLUDE_DIRS}")))
 (native-inputs
-  (list cmake swig))
+ (list cmake swig))
 (inputs
-  (list python-wrapper
-qtbase-5
-libxi
-libice
-soqt
-glew
-coin3D))
+ (list python-wrapper
+   qtbase-5
+   libxi
+   libice
+   soqt
+   glew
+   coin3D))
 (home-page "https://github.com/coin3d/pivy;)
 (synopsis "Python bindings to Coin3D")
 (description
-  "Pivy provides python bindings for Coin, a 3D graphics library with an
+ "Pivy provides python bindings for Coin, a 3D graphics library with an
 Application Programming Interface based on the Open Inventor 2.1 API.")
 (license license:isc)))
 

I get lots of errors like these:

--8<---cut here---start->8---
interfaces/coin_header_includes.h:662: Error: Unable to find 
'Inventor/VRMLnodes/SoVRMLViewpoint.h'
interfaces/coin_header_includes.h:663: Error: Unable to find 
'Inventor/VRMLnodes/SoVRMLVisibilitySensor.h'
interfaces/coin_header_includes.h:664: Error: Unable to find 
'Inventor/VRMLnodes/SoVRMLWorldInfo.h'
/gnu/store/ivbbmgrvhdc46p2ywx1x2zsmal3x0z5n-soqt-1.6.0-1.fb8f655/include/Inventor/Qt/devices/SoQtDevice.h:66:
 Error: Unable to find 'Inventor/SbLinear.h'
/gnu/store/ivbbmgrvhdc46p2ywx1x2zsmal3x0z5n-soqt-1.6.0-1.fb8f655/include/Inventor/Qt/SoQtObject.h:40:
 Error: Unable to find 'Inventor/SbBasic.h'
--8<---cut here---end--->8---


-- 
Ricardo

bug#70192: guix pull: error

[Ricardo Wurmus]

Thanks for the bug report.

This looks like a temporary network failure.  Can you reproduce this
reliably?  If so, could you please tell us a bit more about your system?

Thanks!

-- 
Ricardo

bug#70254: withershins - failed to build

[Ricardo Wurmus]

Closing, because withershins is no more.

-- 
Ricardo

bug#70254: withershins - failed to build

[Ricardo Wurmus]

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.

We only ever needed it for powertabeditor.  It no longer uses the
package, so I just removed it.

Thanks for letting me know!

-- 
Ricardo

bug#70210: i686: openjdk 9 linker segfaults

[Ricardo Wurmus]

For some time now openjdk 9 could not be built on i686.  The linker segfaults:

--8<---cut here---start->8---
ld: 
/tmp/guix-build-openjdk-9.181.drv-0/source/build/linux-x86-normal-server-release/hotspot/variant-server/libjvm/objs/adaptiveFreeList.o:
 warning: relocation in read-only section `.text'
ld: BFD (GNU Binutils) 2.38 assertion fail 
../../binutils-2.38/bfd/elfxx-x86.c:529
collect2: fatal error: ld terminated with signal 11 [Segmentation fault]
compilation terminated.
make[3]: *** [lib/CompileJvm.gmk:209: 
/tmp/guix-build-openjdk-9.181.drv-0/source/build/linux-x86-normal-server-release/support/modules_libs/java.base/server/libjvm.so]
 Error 1
make[3]: *** Deleting file 
'/tmp/guix-build-openjdk-9.181.drv-0/source/build/linux-x86-normal-server-release/support/modules_libs/java.base/server/libjvm.so'
make[2]: *** [make/Main.gmk:263: hotspot-server-libs] Error 2
make[2]: *** Waiting for unfinished jobs
--8<---cut here---end--->8---

-- 
Ricardo

bug#29934: in virtual machines the graphical dektop environment randomly fails to show up

[Ricardo Wurmus]

I'm closing this for lack of recent activity, and as it appears that the
issue has been solved.

If this decision was incorrect please open a new issue.

Thanks!

-- 
Ricardo

bug#30130: Add ‘guix whereis’ command

[Ricardo Wurmus]

I’m closing this because we now have “guix locate”.

-- 
Ricardo

bug#68558: Build r-randomforestsrc.x86_64-linux on master is broken.

[Ricardo Wurmus]

My bad.  I accidentally pushed this update.  On every mass update of
CRAN packages I have to exclude r-sungeo and r-randomforestsrc because
of their unpackageable new dependencies.

I reverted the commit.

-- 
Ricardo

bug#39885: Bioconductor tarballs are not archived

[Ricardo Wurmus]

Ludovic Courtès  writes:

> I my previous message, I wrote:
>
>> As for past tarballs, #swh-devel comrades say we could send them a list
>> of URLs and they’d create “Save Code Now” requests on our behalf (we
>> cannot do it ourselves since the site doesn’t accept plain tarballs.)
>
> Were you able to retrieve some of these?  What are the chances of
> success?

Do we have a list of desired tarballs?  I still have an archived
/gnu/store from before we moved the shared cluster installation at the
MDC to different storage.  It might contain old tarballs that we no
longer have elsewhere.

-- 
Ricardo

bug#39885: Bioconductor URI, fallback and time-machine

[Ricardo Wurmus]

Ludovic Courtès  writes:

>> With all these notes out of the way I’ll prepare a series of patches
>> next.
>
> I don’t think it happened but it’d still be nice.  :-)

The WIP commit is here:

https://git.savannah.gnu.org/cgit/guix.git/commit/?h=wip-r=e81a75a7b28c633a658ceeb0a728255674f56c58

-- 
Ricardo

bug#67038: Inconsistent use of space before ellipsis

[Ricardo Wurmus]

When running “guix shell python python-numpy” we see output like this:

--8<---cut here---start->8---
applying 3 grafts for python-pytest-bootstrap-7.1.3 ...
applying 9 grafts for libxslt-1.1.37 ...
applying 6 grafts for python-lxml-4.9.1 ...
waiting for locks or build slots...
applying 4 grafts for python-xmlschema-1.2.5 ...
applying 7 grafts for python-pytest-7.1.3 ...
applying 11 grafts for python-numpy-1.23.2 ...
building CA certificate bundle...
listing Emacs sub-directories...
building fonts directory...
building directory of Info manuals...
building profile with 2 packages...
--8<---cut here---end--->8---

Note the inconsistency in whether we separate the ellipses from the
preceding text with a space or not.

-- 
Ricardo

bug#66850: %inferior-packages fails with match error

[Ricardo Wurmus]

Sometimes when using %inferior-packages from (guix inferior) I get a
match error like this:

--8<---cut here---start->8---
Oct 31 16:10:56 my-host script.sh[11211]: ERROR:
Oct 31 16:10:56 my-host script.sh[11211]: 1. : 
#
Oct 31 16:10:56 my-host script.sh[11211]: In srfi/srfi-1.scm:
Oct 31 16:10:56 my-host script.sh[11211]: 586:29 19 (map1 (("emacs-ivy-hydra" 
"0.14.0" 140456890688544) ("emacs-unfill" "0.3" 140456890595920) ("emacs-kbd" 
"0.0.1-0.a7f4c9b" 140456889541840) (…
Oct 31 16:10:57 my-host script.sh[11211]: o-types" "0.12.1" 140456892858544) 
("rust-tap" "1.0.1" 140456869622112) ("rust-is-terminal" "0.4.7" 
140457009467744) ("rust-glam" "0.16.0" 14045700937…
Oct 31 16:10:57 my-host script.sh[11211]: ("rust-darling" "0.9.0" 
140457190695264) ("rust-memchr" "2.5.0" 140457009579568) ("rust-sha2" "0.9.5" 
140456869400752) ("rust-base64" "0.11.0" 1404568…
…
Oct 31 16:11:00 my-host script.sh[11211]: 6) ("rust-rustc-version" "0.1.7" 
140457010237216) ("rust-crossterm" "0.25.0" 140456889098016) 
("rust-rust-hawktracer" "0.7.0" 140457010188288) ("rust-…
Oct 31 16:11:00 my-host script.sh[11211]: 586:17  2 (map1 
(("emacs-org-re-reveal" 140456890183456) ("emacs-eldoc" "1.14.0" 
140456889995040) ("emacs-skewer-mode" "1.8.0" 140456889618032) ("emac…
Oct 31 16:11:00 my-host script.sh[11211]: 7009533808) 
("rust-pathfinder-geometry" "0.5.1" 140456869437440) ("rust-speedy-derive" 
"0.8.5" 140456869482672) ("rust-cc" "1.0.79" 140456910742560) (…
Oct 31 16:11:00 my-host script.sh[11211]: ("rust-crossterm" "0.25.0" 
140456889098016) ("rust-rust-hawktracer" "0.7.0" 140457010188288) 
("rust-normpath" "1.1.1" 140457009715616) ("rust-cast5" "…
Oct 31 16:11:00 my-host script.sh[11211]: In guix/inferior.scm:
Oct 31 16:11:00 my-host script.sh[11211]: 415:9  1 (_ _)
Oct 31 16:11:00 my-host script.sh[11211]: In ice-9/boot-9.scm:
Oct 31 16:11:00 my-host script.sh[11211]: 1685:16  0 (raise-exception _ 
#:continuable? _)
Oct 31 16:11:00 my-host script.sh[11211]: ice-9/boot-9.scm:1685:16: In 
procedure raise-exception:
Oct 31 16:11:00 my-host script.sh[11211]: Throw to key `match-error' with args 
`("match" "no matching pattern" ("emacs-org-re-reveal" 140456890183456))'.
--8<---cut here---end--->8---

I don’t see how this could possibly happen because the expression to be
evaluated by the inferior only ever returns a list where each item
contains of three elements: name, version, and id.

-- 
Ricardo

bug#45835: (gnu machine digital-ocean) installs old Guix

[Ricardo Wurmus]

This is no longer the case.  The module no longer references Guile 2,
and it installs the latest version of Guix.

-- 
Ricardo

bug#41211: texlive-luatex-luaotfload fails to build

[Ricardo Wurmus]

As of commit 321979a15317eaf93b15e9cca30d328d39cca4b1 texlive-luaotfload
builds fine.  This may have been fixed with the massive number of
changes to the texlive packages.

-- 
Ricardo

bug#60608: keras is broken –> package bazel?

[Ricardo Wurmus]

Bazel is now available in the guix-science channel.  We may need to move
keras there too and build it with bazel.

-- 
Ricardo

bug#66384: [cuirass] /search/latest/archive fails

[Ricardo Wurmus]

This is a consequence of commit
9b227abd29b15e7e25c54a71c524e7b26252a270, and it should be enough to fix
it like this:

--8<---cut here---start->8---
diff --git a/src/cuirass/http.scm b/src/cuirass/http.scm
index 7e4fd3b..9c4c723 100644
--- a/src/cuirass/http.scm
+++ b/src/cuirass/http.scm
@@ -133,7 +133,8 @@
 (finished . ,(bool->int finished?))
 (buildproducts . ,(list->vector
(map (lambda (product)
-  `((type . ,(build-product-type product))
+  `((id . ,(build-product-id product))
+(type . ,(build-product-type product))
 (path . ,(build-product-file product))
 (file-size . ,(build-product-file-size 
product
 (build-products build))
--8<---cut here---end--->8---


-- 
Ricardo

bug#66384: [cuirass] /search/latest/archive fails

[Ricardo Wurmus]

Hi,

I noticed that queries like this now consistently fail:


https://ci.guix.gnu.org/search/latest/archive?query=spec%3Atarball+status%3Asuccess+system%3Ax86_64-linux+guix-binary.tar.xz

This should redirect to a download URL.

I went through the code and found that the problem lies in the return
value of HANDLE-BUILDS-SEARCH-REQUEST, which does not include the ID
field for BUILDPRODUCTS:

--8<---cut here---start->8---
scheme@(guile-user)> ,use (cuirass database)
scheme@(guile-user)> ,m (cuirass http)
scheme@(cuirass http)> (define query (uri-decode 
"spec%3Atarball+status%3Asuccess+system%3Ax86_64-linux+guix-binary.tar.xz"))
scheme@(cuirass http)> (vector->list
   (handle-builds-search-request
`((query . ,query)
  (nr . 1)
  (order . finish-time+build-id
2023-10-07T11:15:58 builds search request took 0.256186 seconds
$1 = (((id . 2190078) (evaluation . "827027") (jobset . "tarball") (job . 
"binary-tarball.x86_64-linux") (timestamp . 1696611284) (starttime . 
1696611211) (stoptime . 1696611284) (derivation . 
"/gnu/store/icam3qbpkjhsgrglx4wsy53bsrznqvs3-guix-binary.tar.xz.drv") 
(buildoutputs ("out" ("path" . 
"/gnu/store/0yb96ks4fa6781817ala5w706f945zq4-guix-binary.tar.xz"))) (system . 
"x86_64-linux") (nixname . "guix-binary.tar.xz") (buildstatus . 0) (weather . 
-1) (busy . 0) (priority . 9) (finished . 1) (buildproducts . #(((type . 
"archive") (path . 
"/gnu/store/0yb96ks4fa6781817ala5w706f945zq4-guix-binary.tar.xz") (file-size . 
108105168))
scheme@(cuirass http)> (define build (car $1)
)
scheme@(cuirass http)> 
(assoc-ref build 'id)
$2 = 2190078
scheme@(cuirass http)> (define products (vector->list
(assoc-ref build 'buildproducts)))
scheme@(cuirass http)> products
$3 = (((type . "archive") (path . 
"/gnu/store/0yb96ks4fa6781817ala5w706f945zq4-guix-binary.tar.xz") (file-size . 
108105168)))
scheme@(cuirass http)> (define product-type "archive")
scheme@(cuirass http)> (find (lambda (product)
  (string=? (assoc-ref product 'type)
product-type))
products)
$4 = ((type . "archive") (path . 
"/gnu/store/0yb96ks4fa6781817ala5w706f945zq4-guix-binary.tar.xz") (file-size . 
108105168))
scheme@(cuirass http)> (define product $4)
scheme@(cuirass http)> (assoc-ref product 'id)
$5 = #f
--8<---cut here---end--->8---

Without the ID of the build product cuirass cannot build the download
URL.

-- 
Ricardo

bug#66227: 'emacs-next' is almost unusable

[Ricardo Wurmus]

> 'emacs-next' doesn't work.  Because native-compilation doesn't work and
> it breaks everything else.

What exactly doesn’t work?

It would be better to actually fix whatever problem there might be than
just disabling native compilation.

-- 
Ricardo

bug#66207: Cannot boot VMs with grub-efi-bootloader

[Ricardo Wurmus]

Mathieu Othacehe  writes:

> Now it looks to me that what Ricardo is observing is not linked to any
> of the changes mentioned above.  When using the grub-efi-bootloader,
> Grub is never installed in the post-MBR gap. This was already the case
> in 1.4.0 and is still true. Those images cannot be booted without the
> qemu -bios option unless I'm mistaken.

FWIW I tried the 1.4.0 image at
https://ftpmirror.gnu.org/gnu/guix/guix-system-vm-image-1.4.0.x86_64-linux.qcow2,
which did boot just fine.

I suppose that one isn’t using the grub-efi-bootloader.

It’s quite possible that I’m one of only few people who are unaware of
the “-bios” option to qemu.  So there really isn’t any bug or regression
here, it’s just that my primitive mental model (use “guix system” to
build a VM, run with qemu) had not required upgrading until now.

For the benefit of people like me or newcomers perhaps the documentation
could make the dependency between the use of the grub-efi-bootloader and
additionally required qemu arguments a little clearer.

-- 
Ricardo

bug#66207: Cannot boot VMs with grub-efi-bootloader

[Ricardo Wurmus]

Ludovic Courtès  writes:

> Hi,
>
> Ricardo Wurmus  skribis:
>
>> I’m trying to build a more recent VM image than 1.4.0.  The 1.4.0 qcow2
>> image that’s available for download on the Guix website boots fine, but
>> any image created with a current Guix cannot be booted.
>>
>> I’m on Guix commit be5bec47f7942a5e4d2a30eadd9a6fa4c715e88b.
>>
>> I ran
>>
>> ./pre-inst-env guix system image -t qcow2 \
>> doc/os-config-lightweight-desktop.texi
>>
>> to generate the VM image and then I used
>>
>> qemu-system-x86_64 -enable-kvm \
>>-m 4096 -monitor stdio \
>>-drive file=/tmp/guixvm.qcow2,id=myhd \
>>-vnc :1
>>
>> and connected Remmina to :1.
>>
>> The fan spins up to top speed and I see “Booting from Hard Disk…” with
>> no progress whatsoever.
>
> There have been recent changes in this area:
>
>   6bd17a0806 image: Do not allow BIOS bootloader and GPT.
>   e5ed1712da image: Introduce the mbr-hybrid-raw image type.
>
> The latter changes the default image type.  Before that, there was:
>
>   d57cab7641 image: Add mbr-raw-image-type and use by default.
>
> I’m not sure if this could explain the problem.

It’s due to the bootloader.  This field from the bare bones template
works:

  (bootloader (bootloader-configuration
(bootloader grub-bootloader)
(targets '("/dev/sdX"

but this from the desktop template doesn’t:

  (bootloader (bootloader-configuration
(bootloader grub-efi-bootloader)
(targets '("/boot/efi"

The manual for “guix system” gives a somewhat complicated invocation
that I only found out about later:

  image=$(guix system image --image-type=qcow2 \
  gnu/system/examples/lightweight-desktop.tmpl)
  cp $image /tmp/my-image.qcow2
  chmod +w /tmp/my-image.qcow2
  qemu-system-x86_64 -enable-kvm -hda /tmp/my-image.qcow2 -m 1000 \
 -bios $(guix build 
ovmf)/share/firmware/ovmf_x64.bin

I haven’t tried it yet, but I assume that providing this extra “-bios”
option would fix it.  It wasn’t necessary before, though, and I think
it’s an inconvenient complication when running Guix VMs.

Perhaps an example invocation of qemu-system-* could be added as a
comment to the templates?

-- 
Ricardo

bug#66220: VM root file system has no label

[Ricardo Wurmus]

When building a Guix System VM (qcow2) image from an operating system
file containing the following file systems

  (file-systems (append
 (list (file-system
 (device (file-system-label "my-root"))
 (mount-point "/")
 (type "ext4")))
 %base-file-systems))

the resulting image will not have the label “my-root”.  When booting the
virtual machine and reconfiguring with the configuration file (as saved
by “--save-provenance”) Guix will complain about the fact that there is
no disk with the given label.

-- 
Ricardo

bug#66207: Cannot boot any recent VM built with “guix system image -t qcow2”

[Ricardo Wurmus]

Ricardo Wurmus  writes:

> I’m trying to build a more recent VM image than 1.4.0.  The 1.4.0 qcow2
> image that’s available for download on the Guix website boots fine, but
> any image created with a current Guix cannot be booted.
>
> I’m on Guix commit be5bec47f7942a5e4d2a30eadd9a6fa4c715e88b.
>
> I ran
>
> ./pre-inst-env guix system image -t qcow2 \
> doc/os-config-lightweight-desktop.texi

Interestingly, the configuration in doc/os-config-bare-bones.texi does
boot fine.

-- 
Ricardo

bug#66207: Cannot boot any recent VM built with “guix system image -t qcow2”

[Ricardo Wurmus]

I’m trying to build a more recent VM image than 1.4.0.  The 1.4.0 qcow2
image that’s available for download on the Guix website boots fine, but
any image created with a current Guix cannot be booted.

I’m on Guix commit be5bec47f7942a5e4d2a30eadd9a6fa4c715e88b.

I ran

./pre-inst-env guix system image -t qcow2 \
doc/os-config-lightweight-desktop.texi

to generate the VM image and then I used

qemu-system-x86_64 -enable-kvm \
   -m 4096 -monitor stdio \
   -drive file=/tmp/guixvm.qcow2,id=myhd \
   -vnc :1

and connected Remmina to :1.

The fan spins up to top speed and I see “Booting from Hard Disk…” with
no progress whatsoever.

-- 
Ricardo

bug#65056: https://issues.guix.gnu.org/ cannot be accessed through Tor

[Ricardo Wurmus]

Giovanni Biscuolo  writes:

> Anyway the DoS Attack protection of the network hosting ci.guix.gnu.org
> /seems/ problematic: how could it be that home IP resposible of a DoS
> attack?  Was it a false positive or was it some temporary problem from
> the originating IP network?

IT had installed some DoS attack protection thing for the DMZ with
different thresholds based on past access patterns.

Upon my request they have now disabled this completely for our IPs
corresponding to ci.guix.gnu.org and its sibling node.

-- 
Ricardo

bug#65056: https://issues.guix.gnu.org/ cannot be accessed through Tor

[Ricardo Wurmus]

Ludovic Courtès  writes:

> I confirm that I still get the problem right now from my home network,
> without even really trying: […]

Is that through Tor or just your ISP?

-- 
Ricardo

bug#65056: https://issues.guix.gnu.org/ cannot be accessed through Tor

[Ricardo Wurmus]

Ludovic Courtès  writes:

> Hello!
>
> Ricardo Wurmus  skribis:
>
>> I don’t know.  I’m on holidays now, but I’ve opened yet another ticket
>> to get a definitive answer to my more elaborate variant of “WTF?”.
>
> Did you eventually get feedback from them?

I got one response to ask for more information, which I supplied.
Nothing since.  I requested a response just now.

> If not, we can start looking for a way to move public-facing services
> elsewhere.  (It may not be trivial because bayfront, which is the other
> node we’ve traditionally used for that, is super busy these days.)

Yeah, I’d really like this to be fixed.  It worked pretty well for
years, so these seemingly unnecessary changes and the way they are
applied without any recourse (and without anyone being able to confirm
that they have in fact changed somehing) really bother me.

But if our public services keep getting restricted I agree that we
should look for an alternative way to host them.

-- 
Ricardo

bug#54206: [aarch64] kodi fails because of just one test

[Ricardo Wurmus]

This seems to have been fixed in the meantime.  I was able to install
kodi on aarch64 with guix e365c26a34fa485f9af46538fcea128db681c33d.

-- 
Ricardo

bug#33094: latex-koma-script: scrlttr2: ERROR: Argument of \strip@prefix has an extra }.

[Ricardo Wurmus]

This is now fixed:

--8<---cut here---start->8---
$ guix shell texlive-collection-latexrecommended -- pdflatex latex.tex

pdflatex latex.tex 
This is pdfTeX, Version 3.141592653-2.6-1.40.25 (TeX Live 2023/GNU Guix) 
(preloaded format=pdflatex)
 restricted \write18 enabled.
entering extended mode
(./latex.tex
LaTeX2e <2022-11-01> patch level 1
L3 programming layer <2023-02-22> 
(/gnu/store/k6d1433yxpb1g3whfdh1h5pmf4bnmlzg-profile/share/texmf-dist/tex/latex/koma-script/scrlttr2.cls
Document Class: scrlttr2 2022/10/12 v3.38 KOMA-Script document class (letter)
(/gnu/store/k6d1433yxpb1g3whfdh1h5pmf4bnmlzg-profile/share/texmf-dist/tex/latex/koma-script/scrkbase.sty
 
(/gnu/store/k6d1433yxpb1g3whfdh1h5pmf4bnmlzg-profile/share/texmf-dist/tex/latex/koma-script/scrbase.sty
 
(/gnu/store/k6d1433yxpb1g3whfdh1h5pmf4bnmlzg-profile/share/texmf-dist/tex/latex/koma-script/scrlfile.sty
 
(/gnu/store/k6d1433yxpb1g3whfdh1h5pmf4bnmlzg-profile/share/texmf-dist/tex/latex/koma-script/scrlfile-hook.sty
 
(/gnu/store/k6d1433yxpb1g3whfdh1h5pmf4bnmlzg-profile/share/texmf-dist/tex/latex/koma-script/scrlogo.sty)))
 
(/gnu/store/k6d1433yxpb1g3whfdh1h5pmf4bnmlzg-profile/share/texmf-dist/tex/latex/graphics/keyval.sty)))
 
(/gnu/store/k6d1433yxpb1g3whfdh1h5pmf4bnmlzg-profile/share/texmf-dist/tex/latex/koma-script/scrsize12pt.clo)
 
(/gnu/store/k6d1433yxpb1g3whfdh1h5pmf4bnmlzg-profile/share/texmf-dist/tex/latex/koma-script/typearea.sty))
 
(/gnu/store/k6d1433yxpb1g3whfdh1h5pmf4bnmlzg-profile/share/texmf-dist/tex/latex/koma-script/DIN.lco)
(/gnu/store/k6d1433yxpb1g3whfdh1h5pmf4bnmlzg-profile/share/texmf-dist/tex/latex/base/inputenc.sty)

Class scrlttr2 Warning: \date changes the internal \LaTeX date only.
(scrlttr2)  You should note that this changes the default
(scrlttr2)  value of variable `date' only as long as nobody
(scrlttr2)  uses `\setkomavar` to change the content of
(scrlttr2)  variable `date'.
(scrlttr2)  Therefore, usage of `\setkomavar' is recommended
(scrlttr2)  to change the letter's date on input line 6.

(/gnu/store/k6d1433yxpb1g3whfdh1h5pmf4bnmlzg-profile/share/texmf-dist/tex/latex/l3backend/l3backend-pdftex.def)
No file latex.aux.
[1{/gnu/store/k6d1433yxpb1g3whfdh1h5pmf4bnmlzg-profile/share/texmf-dist/fonts/map/pdftex/updmap/pdftex.map}]
 (./latex.aux) 
)
Output written on latex.pdf (1 page, 16397 bytes).
Transcript written on latex.log.
--8<---cut here---end--->8---

The resulting document looks fine to me.

-- 
Ricardo

bug#65056: https://issues.guix.gnu.org/ cannot be accessed through Tor

[Ricardo Wurmus]

Tobias Geerinckx-Rice  writes:

> On 13 August 2023 00:25:51 UTC, "Ludovic Courtès"  wrote:
>>I think it’s worse than this.  I noticed that ci.guix.gnu.org (same
>>machine) would occasionally time out on my side, without Tor, starting
>>from this week (I was on vacation before, so I don’t know exactly when
>>it started).  From a browser, I get this “DoS attack” HTML page:
>
> Oh, wow.  This is new to me.
>
> It's frustrating that $IT keeps adding new significant hurdles with
> apparently 0 communications, and that our only option is often 'ask
> rekado, again, to ask things, again'.  That's not right.
>
> Ricardo, do you think there's a chance this trend will improve (without you 
> burning out)?

I don’t know.  I’m on holidays now, but I’ve opened yet another ticket
to get a definitive answer to my more elaborate variant of “WTF?”.

> Otherwise, I'd like to suggest wireguarding berlin's impressive
> hardware resources to bayfront or to a new head node not hosted at the
> MDC, or something similarly provocative.  Just give up on hosting
> public services there, like we already migrated the home page.  This
> isn't meaningful redundancy.

Good plan.

Sorry about this.  It’s frustrating, and I’m stocking up on towels to
throw.

-- 
Ricardo

bug#64990: jupyter kernels install kernel.json without GUIX_PYTHONPATH

[Ricardo Wurmus]

Consider this scenario: a number of users access a shared jupyterhub /
jupyterlab installation, which allows them to launch their own jupyter
kernels.  The shared installation was deployed with Guix.  The user
kernels are installed like this:

$ guix shell python python-ipykernel python-foo python-bar …
$ [env] python3 -m ipykernel install --user --name whatever --display-name 
whatever
Installed kernelspec whatever in 
/home/rekado/.local/share/jupyter/kernels/whatever

The installed kernel.json looks like this:

--8<---cut here---start->8---
{
 "argv": [
  "/gnu/store/…-profile/bin/python3",
  "-m",
  "ipykernel_launcher",
  "-f",
  "{connection_file}"
 ],
 "display_name": "whatever",
 "language": "python",
 "metadata": {
  "debugger": true
 }
]
--8<---cut here---end--->8---

That’s not sufficient because the “ipykernel_launcher” module is
provided by the python-ipykernel package and the shared jupyter{hub,lab}
doesn’t know about this package.  That’s because it doesn’t use the
GUIX_PYTHONPATH of the profile containing the user’s packages.

Perhaps we could add a profile hook that adds an “env” field to the
generated kernel.json file, which augments the existing GUIX_PYTHONPATH
with the appropriate value for the current profile.

We can do this on the command line like this:

--8<---cut here---start->8---
  python3 -m ipykernel install \
--user --name whatever --display-name whatever \
--env GUIX_PYTHONPATH "${GUIX_PYTHONPATH}:\${GUIX_PYTHONPATH}"
--8<---cut here---end--->8---

Or we can edit the JSON directly.

The documentation of the kernel.json format is available here:
https://jupyter-client.readthedocs.io/en/stable/kernels.html#kernel-specs

-- 
Ricardo

bug#64827: Acknowledgement (Texlive-biber not installable)

[Ricardo Wurmus]

Hi Andreas,

> I can't find the format file `pdflatex.fmt'!

This sounds like a sibling of https://issues.guix.gnu.org/64729

-- 
Ricardo

bug#64729: xelatex is broken, because xelatex.fmt is missing

[Ricardo Wurmus]

Since the merge of the tex-team-next branch earlier this week xelatex is
broken.  I tried installing different collection packages, but I cannot
find any package providing the xelatex.fmt file.

This also affects packages like python-nbconvert, which now has a
failing test suite as it can no longer build PDFs with xelatex.

--
Ricardo

bug#64187: guix locate: unsupported manifest format

[Ricardo Wurmus]

Ludovic Courtès  writes:

>>> The last manifest it reads is
>>> /gnu/var/guix/profiles/per-user/wneuber/guix-profile-1-link/manifest
>>> with the following contents
>>>
>>> (manifest
>>>   (version 1)
>>>   (packages
>>> (("gcc"
>>>   "4.9.2"
>>>   "out"
>>>   "/gnu/store/ym7sybrdifnm3g0rafhclv891niaczcv-gcc-4.9.2"
>>>   ()
>>
>> Woow, this profile predates May 2015 and commit
>> dedb17ad010ee9ef67f3f4f3997dd17f226c8090.  And indeed, it’s no longer
>> recognized since e7e04396c0e91569bf493e1352d6539babc15327 (July 2022).
>>
>> I’ll work on a fix…
>
> Fixed in commit e1c2c2f042e8741c0759e21e634cd2271e078177!

Thank you!  I confirm that it is now successfully indexing all packages
on the cluster.

-- 
Ricardo

bug#64358: “guix refresh” chokes on cran.scm

[Ricardo Wurmus]

Fixed in commit b43841c124d15eaecc41b3928f08a26dbd5c653a
-- 
Ricardo

bug#64358: “guix refresh” chokes on cran.scm

[Ricardo Wurmus]

Ludovic Courtès  writes:

> The way ‘guix style -S inputs’ handles it is by starting editing
> packages from the bottom of the file and upwards (see the bottom of
> (guix scripts style)).  That way, source location is valid as it edits
> things.
>
> Perhaps we can do that here?

Oh, that’s a very good idea.  Worth a try!

-- 
Ricardo

bug#64187: guix locate: unsupported manifest format

[Ricardo Wurmus]

Ludovic Courtès  writes:

> However, how can it happen?  ‘guix locate’ knows all the manifest format
> version, so maybe it mistook a file for a manifest when in fact it’s
> something else?
>
> Could you ‘strace -o /tmp/log.strace guix locate ls’ to get the name of
> the offending file for now?

The last manifest it reads is
/gnu/var/guix/profiles/per-user/wneuber/guix-profile-1-link/manifest
with the following contents

--8<---cut here---start->8---
(manifest
  (version 1)
  (packages
(("gcc"
  "4.9.2"
  "out"
  "/gnu/store/ym7sybrdifnm3g0rafhclv891niaczcv-gcc-4.9.2"
  ()
--8<---cut here---end--->8---

-- 
Ricardo

bug#64358: “guix refresh” chokes on cran.scm

[Ricardo Wurmus]

> Prior to that we see warnings like this:
>
> /home/rekado/dev/gx/branches/master/gnu/packages/cran.scm:36350:2: 
> r-readtext: updating from version 0.82 to version 0.90...
> /home/rekado/dev/gx/branches/master/gnu/packages/cran.scm:36350:2: warning: 
> r-readtext: no `version' field in source; skipping
>
> It’s as if the position in the file has been lost and it tries to update
> the definition of r-readtext that is no longer where the current port
> position is.

It seems that this is indeed the problem.  The value for a ’s
“location” field is known at compile/eval time and this value will not
be correct after the first substantial edit has taken place.

I see these options:

1 - pass a value to “update-package” that corresponds to line changes so
  far and let it return an updated value, making “update-package” aware
  of file changes.  This would be rather ugly.

2 - compute the location of the target package anew if the file it is
  located in has since been edited.

3 - never rely on the line number of the package location value; just open
  the specified file and always search it for a package definition.
  Optionally take the line number into account as a starting point for a
  search in both directions.

4 - integrate changes with git, so that all edits are commits that are
  applied to the very same base commit.

The third option seems the most reasonable and lightweight to me.

-- 
Ricardo

bug#64389: java: stripping timestamps breaks jmods.

[Ricardo Wurmus]

The 'strip-archive-timestamps phase in our openjdk packages breaks the
jmod feature because it invalidates the content hashes.

Here I try to extend the JDK with modules from openjfx:

--8<---cut here---start->8---
jlink --add-modules 
java.desktop,javafx.swing,javafx.controls,jdk.unsupported.desktop --output 
myjdk --module-path openjfx-17.0.7_linux-x64_bin-jmods/javafx-jmods-17.0.7/
Error: Hash of java.xml 
(da39a79e291a7cc5b8e240390a4386a7d2323017871d6c2d635301826d0159f9) differs to 
expected hash 
(e3ee7150f05504485371ab9bac2d724a553f975eca5d529dca786599cc5f98a3) recorded in 
java.base
java.lang.module.FindException: Hash of java.xml 
(da39a79e291a7cc5b8e240390a4386a7d2323017871d6c2d635301826d0159f9) differs to 
expected hash 
(e3ee7150f05504485371ab9bac2d724a553f975eca5d529dca786599cc5f98a3) recorded in 
java.base
at java.base/java.lang.module.Resolver.findFail(Resolver.java:892)
at java.base/java.lang.module.Resolver.checkHashes(Resolver.java:480)
at java.base/java.lang.module.Resolver.finish(Resolver.java:378)
at 
java.base/java.lang.module.Configuration.(Configuration.java:139)
at 
java.base/java.lang.module.Configuration.resolve(Configuration.java:422)
at 
java.base/java.lang.module.Configuration.resolve(Configuration.java:254)
at 
jdk.jlink/jdk.tools.jlink.internal.Jlink$JlinkConfiguration.resolve(Jlink.java:217)
at 
jdk.jlink/jdk.tools.jlink.internal.JlinkTask.createImageProvider(JlinkTask.java:536)
at 
jdk.jlink/jdk.tools.jlink.internal.JlinkTask.createImage(JlinkTask.java:424)
at jdk.jlink/jdk.tools.jlink.internal.JlinkTask.run(JlinkTask.java:276)
at jdk.jlink/jdk.tools.jlink.internal.Main.run(Main.java:56)
at jdk.jlink/jdk.tools.jlink.internal.Main.main(Main.java:34)
--8<---cut here---end--->8---

When I remove the 'strip-archive-timestamps phase and try using jlink
from this variant of the openjdk package things work fine:

--8<---cut here---start->8---
java.base 
file:///gnu/store/c3hxi9pd9mpj3f6qk4qiysdqvchq8apm-openjdk-19.0.2-jdk/jmods/java.base.jmod
java.datatransfer 
file:///gnu/store/c3hxi9pd9mpj3f6qk4qiysdqvchq8apm-openjdk-19.0.2-jdk/jmods/java.datatransfer.jmod
java.desktop 
file:///gnu/store/c3hxi9pd9mpj3f6qk4qiysdqvchq8apm-openjdk-19.0.2-jdk/jmods/java.desktop.jmod
java.prefs 
file:///gnu/store/c3hxi9pd9mpj3f6qk4qiysdqvchq8apm-openjdk-19.0.2-jdk/jmods/java.prefs.jmod
java.xml 
file:///gnu/store/c3hxi9pd9mpj3f6qk4qiysdqvchq8apm-openjdk-19.0.2-jdk/jmods/java.xml.jmod
javafx.base 
file:///home/rekado/Downloads/java/openjfx-17.0.7_linux-x64_bin-jmods/javafx-jmods-17.0.7/javafx.base.jmod
javafx.controls 
file:///home/rekado/Downloads/java/openjfx-17.0.7_linux-x64_bin-jmods/javafx-jmods-17.0.7/javafx.controls.jmod
javafx.graphics 
file:///home/rekado/Downloads/java/openjfx-17.0.7_linux-x64_bin-jmods/javafx-jmods-17.0.7/javafx.graphics.jmod
javafx.swing 
file:///home/rekado/Downloads/java/openjfx-17.0.7_linux-x64_bin-jmods/javafx-jmods-17.0.7/javafx.swing.jmod
jdk.unsupported 
file:///gnu/store/c3hxi9pd9mpj3f6qk4qiysdqvchq8apm-openjdk-19.0.2-jdk/jmods/jdk.unsupported.jmod
jdk.unsupported.desktop 
file:///gnu/store/c3hxi9pd9mpj3f6qk4qiysdqvchq8apm-openjdk-19.0.2-jdk/jmods/jdk.unsupported.desktop.jmod

Providers:
  java.desktop provides java.net.ContentHandlerFactory used by java.base
  java.base provides java.nio.file.spi.FileSystemProvider used by java.base
  java.base provides java.util.random.RandomGenerator used by java.base
  java.desktop provides javax.print.PrintServiceLookup used by java.desktop
  java.desktop provides javax.print.StreamPrintServiceFactory used by 
java.desktop
  java.desktop provides javax.sound.midi.spi.MidiDeviceProvider used by 
java.desktop
  java.desktop provides javax.sound.midi.spi.MidiFileReader used by java.desktop
  java.desktop provides javax.sound.midi.spi.MidiFileWriter used by java.desktop
  java.desktop provides javax.sound.midi.spi.SoundbankReader used by 
java.desktop
  java.desktop provides javax.sound.sampled.spi.AudioFileReader used by 
java.desktop
  java.desktop provides javax.sound.sampled.spi.AudioFileWriter used by 
java.desktop
  java.desktop provides javax.sound.sampled.spi.FormatConversionProvider used 
by java.desktop
  java.desktop provides javax.sound.sampled.spi.MixerProvider used by 
java.desktop
  java.desktop provides sun.datatransfer.DesktopDatatransferService used by 
java.datatransfer
  jdk.unsupported.desktop provides sun.swing.InteropProvider used by 
java.desktop
--8<---cut here---end--->8---

We will need to find a way to remove timestamps without leaving invalid
hashes behind.  Can we recompute the file hashes or avoid embedding
timestamps in the first place?

-- 
Ricardo

bug#64358: “guix refresh” chokes on cran.scm

[Ricardo Wurmus]

The new refresh behavior to update inputs automatically seems to
sometimes cause the updater to lose track of the position in the file,
leading to errors like this:

--8<---cut here---start->8---
Backtrace:
In ice-9/boot-9.scm:
  1752:10 18 (with-exception-handler _ _ #:unwind? _ #:unwind-for-type _)
In unknown file:
  17 (apply-smob/0 #)
In ice-9/boot-9.scm:
724:2 16 (call-with-prompt _ _ #)
In ice-9/eval.scm:
619:8 15 (_ #(#(#)))
In guix/ui.scm:
   2309:7 14 (run-guix . _)
  2272:10 13 (run-guix-command _ . _)
In ice-9/boot-9.scm:
  1752:10 12 (with-exception-handler _ _ #:unwind? _ #:unwind-for-type _)
  1752:10 11 (with-exception-handler _ _ #:unwind? _ #:unwind-for-type _)
In guix/store.scm:
   659:37 10 (thunk)
  2168:25  9 (run-with-store # _ 
#:guile-for-build _ #:system _ #:target _)
In guix/scripts/refresh.scm:
   592:16  8 (_ _)
In srfi/srfi-1.scm:
634:9  7 (for-each # _)
In guix/scripts/refresh.scm:
   363:21  6 (update-package _ # _ 
…)
In ice-9/boot-9.scm:
  1747:15  5 (with-exception-handler # _ #:unwind? _ #:unwind-for-type _)
In ice-9/ports.scm:
   433:17  4 (call-with-input-file _ _ #:binary _ #:encoding _ #:guess-encoding 
_)
In guix/packages.scm:
   762:17  3 (_ #)
In guix/utils.scm:
   423:23  2 (go-to-location # 30341 2)
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:
unexpected end of line #
--8<---cut here---end--->8---

Prior to that we see warnings like this:

--8<---cut here---start->8---
/home/rekado/dev/gx/branches/master/gnu/packages/cran.scm:36350:2: r-readtext: 
updating from version 0.82 to version 0.90...
/home/rekado/dev/gx/branches/master/gnu/packages/cran.scm:36350:2: warning: 
r-readtext: no `version' field in source; skipping
--8<---cut here---end--->8---

It’s as if the position in the file has been lost and it tries to update
the definition of r-readtext that is no longer where the current port
position is.

I use “./pre-inst-env guix refresh -t cran -u”, which updates dozens of
packages.  Perhaps the changes result in untracked position shifts in
the file?

-- 
Ricardo

bug#64187: guix locate: unsupported manifest format

[Ricardo Wurmus]

I ran “guix locate” on the HPC cluster where we generally don’t ever run
“guix gc”.  Here’s what I got:

--8<---cut here---start->8---
$ time guix locate ls
guix locate: indexing files from /gnu/store...
guix locate: traversing local profile manifests...
guix locate: error: unsupported manifest format

real2m24.029s
user3m11.519s
sys 0m5.617s
--8<---cut here---end--->8---

It would be good if it printed the location of the problematic manifest
and ignored it.

-- 
Ricardo

bug#63857: importer fails to find “main” branch on github

[Ricardo Wurmus]

This fails:

   ./pre-inst-env guix import cran -a git -r 
https://github.com/zdebruine/singlet

With this error:

--8<---cut here---start->8---
Backtrace:
In guix/ui.scm:
   1374:6 19 (guix-import-cran . _)
In ice-9/boot-9.scm:
  1752:10 18 (with-exception-handler _ _ #:unwind? _ #:unwind-for-type _)
In guix/scripts/import/cran.scm:
   121:31 17 (_)
In guix/import/utils.scm:
   647:27 16 (recursive-import _ #:repo->guix-package _ #:guix-name _ #:version 
_ . _)
   639:33 15 (lookup-node "https://github.com/zdebruine/singlet; #f)
In guix/memoization.scm:
 98:0 14 (mproc "https://github.com/zdebruine/singlet; #:version #f #:repo 
git #:repo->guix-package # #:guix-name …)
In unknown file:
  13 (_ # 
# (this is nothing))
In guix/import/cran.scm:
   748:24 12 (_ "https://github.com/zdebruine/singlet; #:repo _ #:version _ 
#:license-prefix _ #:fetch-description _ #:download-source _)
   320:25 11 (fetch-description _ "https://github.com/zdebruine/singlet; _)
In guix/memoization.scm:
 98:0 10 (mproc "https://github.com/zdebruine/singlet; #:method git)
In unknown file:
   9 (_ # 
# (this is nothing))
In ice-9/boot-9.scm:
  1752:10  8 (with-exception-handler _ _ #:unwind? _ #:unwind-for-type _)
In guix/store.scm:
   659:37  7 (thunk)
In guix/git.scm:
562:8  6 (latest-repository-commit # 
"https://github.com/zdebruine/singlet; #:recursive? _ # _ # _ …)
291:4  5 (update-cached-checkout _ #:ref _ #:recursive? _ #:check-out? _ 
#:starting-commit _ #:log-port _ #:cache-directory _)
   241: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? _)
  1685:16  0 (raise-exception _ #:continuable? _)

ice-9/boot-9.scm:1685:16: In procedure raise-exception:
Git error: reference 'refs/remotes/origin/HEAD' not found
--8<---cut here---end--->8---

The default branch of this repository is called “main”.

-- 
Ricardo

bug#63783: r-dismo bundles pre-built jars

[Ricardo Wurmus]

Fixed with commit bb27e3b8b13b4dbbb698b3ff5a4f6cf5793e9d5c.

-- 
Ricardo

bug#63783: r-dismo bundles pre-built jars

[Ricardo Wurmus]

The files dismo.jar and maxent.jar in the r-dismo package don’t have any
associated source code and are not built from source.

-- 
Ricardo

bug#63198: cups-service-type uses PAM-enabled 'cups' by default which prevents authentication

[Ricardo Wurmus]

I’ll second muradm: these changes broke my printing setup:

* my printer is no longer found because cups-minimal has minimal
  features and does not include dnssd
* I cannot add a new printer with ipp://192.168.x.x manually because of
  authentication problems.  The logs tell me that cups-brf needs to run
  as root.

As a bonus problem I cannot restart Cups with the “cups” package because
it cannot be killed.  I disabled the “cups” service and stopped it, but
cups still runs; killing it is of no use because it’s respawned
immediately.  Shepherd says it didn’t do it.  I also tried deleting the
cups socket file, but that also didn’t help.

-- 
Ricardo

bug#63529: awscli doesn’t use global certificate store on foreign distro

[Ricardo Wurmus]

On a foreign distro, awscli does not use the global certificate store.
It seems to only use certifi.pem from the python-certifi package.  There
seems to be no way to override the certificate store.

This makes awscli unusable on foreign distros.

-- 
Ricardo

bug#63507: [mumi] /recent causes crash

[Ricardo Wurmus]

Visiting issues.guix.gnu.org/recent leads to this crash:

--8<---cut here---start->8---
2023-05-14 23:11:35 GET /recent
2023-05-14 23:11:35 In mumi/web/server.scm:
2023-05-14 23:11:35  35:9 95 (handler _ _)
2023-05-14 23:11:35 In mumi/web/controller.scm:
2023-05-14 23:11:35 66:19 94 (_ _)
2023-05-14 23:11:35 In mumi/web/view/html.scm:
2023-05-14 23:11:35779:10 93 (list-of-recent-issues _)
2023-05-14 23:11:35 In srfi/srfi-1.scm:
2023-05-14 23:11:35586:29 92 (map1 (#< num: 63506 archived: #f 
blocke…> …))
2023-05-14 23:11:35586:29 91 (map1 (#< num: 63505 archived: #f 
blocke…> …))
2023-05-14 23:11:35586:29 90 (map1 (#< num: 63504 archived: #f 
blocke…> …))
2023-05-14 23:11:35586:29 89 (map1 (#< num: 63503 archived: #f 
blocke…> …))
2023-05-14 23:11:35586:29 88 (map1 (#< num: 63502 archived: #f 
blocke…> …))
2023-05-14 23:11:35586:29 87 (map1 (#< num: 63501 archived: #f 
blocke…> …))
2023-05-14 23:11:35586:29 86 (map1 (#< num: 63500 archived: #f 
blocke…> …))
2023-05-14 23:11:35586:29 85 (map1 (#< num: 63499 archived: #f 
blocke…> …))
2023-05-14 23:11:35586:29 84 (map1 (#< num: 63498 archived: #f 
blocke…> …))
2023-05-14 23:11:35586:29 83 (map1 (#< num: 63494 archived: #f 
blocke…> …))
2023-05-14 23:11:35586:29 82 (map1 (#< num: 63491 archived: #f 
blocke…> …))
2023-05-14 23:11:35586:29 81 (map1 (#< num: 63490 archived: #f 
blocke…> …))
2023-05-14 23:11:35586:29 80 (map1 (#< num: 63489 archived: #f 
blocke…> …))
2023-05-14 23:11:35586:29 79 (map1 (#< num: 63488 archived: #f 
blocke…> …))
2023-05-14 23:11:35586:29 78 (map1 (#< num: 63486 archived: #f 
blocke…> …))
2023-05-14 23:11:35586:29 77 (map1 (#< num: 63485 archived: #f 
blocke…> …))
2023-05-14 23:11:35586:29 76 (map1 (#< num: 63483 archived: #f 
blocke…> …))
2023-05-14 23:11:35586:29 75 (map1 (#< num: 63482 archived: #f 
blocke…> …))
2023-05-14 23:11:35586:29 74 (map1 (#< num: 63479 archived: #f 
blocke…> …))
2023-05-14 23:11:35586:29 73 (map1 (#< num: 63478 archived: #f 
blocke…> …))
2023-05-14 23:11:35586:29 72 (map1 (#< num: 63477 archived: #f 
blocke…> …))
2023-05-14 23:11:35586:29 71 (map1 (#< num: 63476 archived: #f 
blocke…> …))
2023-05-14 23:11:35586:29 70 (map1 (#< num: 63475 archived: #f 
blocke…> …))
2023-05-14 23:11:35586:29 69 (map1 (#< num: 63474 archived: #f 
blocke…> …))
2023-05-14 23:11:35586:29 68 (map1 (#< num: 63473 archived: #f 
blocke…> …))
2023-05-14 23:11:35586:29 67 (map1 (#< num: 63471 archived: #f 
blocke…> …))
2023-05-14 23:11:35586:29 66 (map1 (#< num: 63468 archived: #f 
blocke…> …))
2023-05-14 23:11:35586:29 65 (map1 (#< num: 63467 archived: #f 
blocke…> …))
2023-05-14 23:11:35586:29 64 (map1 (#< num: 63466 archived: #f 
blocke…> …))
2023-05-14 23:11:35586:29 63 (map1 (#< num: 63465 archived: #f 
blocke…> …))
2023-05-14 23:11:35586:29 62 (map1 (#< num: 63464 archived: #f 
blocke…> …))
2023-05-14 23:11:35586:29 61 (map1 (#< num: 63462 archived: #f 
blocke…> …))
2023-05-14 23:11:35586:29 60 (map1 (#< num: 63461 archived: #f 
blocke…> …))
2023-05-14 23:11:35586:29 59 (map1 (#< num: 63460 archived: #f 
blocke…> …))
2023-05-14 23:11:35586:29 58 (map1 (#< num: 63459 archived: #f 
blocke…> …))
2023-05-14 23:11:35586:29 57 (map1 (#< num: 63458 archived: #f 
blocke…> …))
2023-05-14 23:11:35586:29 56 (map1 (#< num: 63457 archived: #f 
blocke…> …))
2023-05-14 23:11:35586:29 55 (map1 (#< num: 63456 archived: #f 
blocke…> …))
2023-05-14 23:11:35586:29 54 (map1 (#< num: 63454 archived: #f 
blocke…> …))
2023-05-14 23:11:35586:29 53 (map1 (#< num: 63453 archived: #f 
blocke…> …))
2023-05-14 23:11:35586:29 52 (map1 (#< num: 63452 archived: #f 
blocke…> …))
2023-05-14 23:11:35586:29 51 (map1 (#< num: 63451 archived: #f 
blocke…> …))
2023-05-14 23:11:35586:29 50 (map1 (#< num: 63450 archived: #f 
blocke…> …))
2023-05-14 23:11:35586:29 49 (map1 (#< num: 63449 archived: #f 
blocke…> …))
2023-05-14 23:11:35586:29 48 (map1 (#< num: 63448 archived: #f 
blocke…> …))
2023-05-14 23:11:35586:29 47 (map1 (#< num: 63447 archived: #f 
blocke…> …))
2023-05-14 23:11:35586:29 46 (map1 (#< num: 63446 archived: #f 
blocke…> …))
2023-05-14 23:11:35586:29 45 (map1 (#< num: 63445 archived: #f 
blocke…> …))
2023-05-14 23:11:35 Mumi web server listening on http://0.0.0.0:1234/
2023-05-14 23:11:35 In procedure struct-vtable: Wrong type argument in position 
1 (expecting struct): #f
--8<---cut here---end--->8---

-- 
Ricardo

bug#63471: python-pytorch has bogus version string

[Ricardo Wurmus]

The wheel generated for python-pytorch embeds a bad version string:

…
Building wheel torch-1.13.0a0+gitUnknown
…

This lets the version check in downstream packages fail.

-- 
Ricardo

bug#62972: rseqc installs __pycache__ directory to $out/bin

[Ricardo Wurmus]

The rseqc package installs a __pycache__ directory to the bin directory.

-- 
Ricardo

bug#62493: xelatex won't render fonts correctly without full texlive

[Ricardo Wurmus]

John Kehayias  writes:

> "Ricardo Wurmus"  writes:
>
>> John Kehayias  writes:
>>
>>> Exported revision 59745.
>>> svn: E160013: File not found: revision 66702, path
>>> '/tags/texlive-2021.3/Master/texmf-dist/tcode'
>>> command "svn" "export" "--non-interactive" "--trust-server-cert"
>>> "-r" "59745"
>>> "svn://www.tug.org/texlive/tags/texlive-2021.3/Master/texmf-dist/tcode/"
>>> "/tmp/guix-directory.XcAtR6/tcode/" failed with status 1
>>
>> The importer is naive and assumes that any file in tlpdb starts with
>> “texmf-dist/”.  For the xetex package there’s a file
>> “tlpkg/tlpostcode/xetex.pl” and if you drop the same number of
>> characters that you would for “texmf-dist/” you end up with
>> “tcode/xetex.pl”.
>>
>> Oops!
>
> Unfortunately that leaves me at a bit of a loss for making a
> texlive-xetex package as I'm not understanding the whole texlive package
> structure at first glance. I've tried something similar to other
> packages I see but haven't gotten anywhere.

Commit cbf731ae481b434e657b05c80b4a32282e5d112b adds texlive-xetex.  Now
the quotes look fine.

I adjusted the importer in a few commits after that, but generally the
recursive texlive importer suffers from the fact that we have a lot of
inconsistent package names.

-- 
Ricardo

bug#62493: xelatex won't render fonts correctly without full texlive

[Ricardo Wurmus]

John Kehayias  writes:

> Exported revision 59745.
> svn: E160013: File not found: revision 66702, path 
> '/tags/texlive-2021.3/Master/texmf-dist/tcode'
> command "svn" "export" "--non-interactive" "--trust-server-cert" "-r" "59745" 
> "svn://www.tug.org/texlive/tags/texlive-2021.3/Master/texmf-dist/tcode/" 
> "/tmp/guix-directory.XcAtR6/tcode/" failed with status 1

The importer is naive and assumes that any file in tlpdb starts with
“texmf-dist/”.  For the xetex package there’s a file
“tlpkg/tlpostcode/xetex.pl” and if you drop the same number of
characters that you would for “texmf-dist/” you end up with
“tcode/xetex.pl”.

Oops!

-- 
Ricardo

bug#62493: xelatex won't render fonts correctly without full texlive

[Ricardo Wurmus]

We seem to be missing the xetex package that provides files for font mapping:

--8<---cut here---start->8---
$ info tex-text.tec
tlmgr.pl: cannot find package tex-text.tec, searching for other matches:

Packages containing `tex-text.tec' in their title/description:

Packages containing files matching `tex-text.tec':
xepersian:
texmf-dist/fonts/misc/xetex/fontmapping/xepersian/persian-tex-text.tec
xetex:
texmf-dist/fonts/misc/xetex/fontmapping/base/tex-text.tec
--8<---cut here---end--->8---

I was under the impression that we did have a xetex package, but I can’t
find it now.

-- 
Ricardo

bug#62493: xelatex won't render fonts correctly without full texlive

[Ricardo Wurmus]

FWIW, it does work with lualatex:

  guix shell --container texlive-base texlive-fontspec -- lualatex test.tex

-- 
Ricardo

bug#55013: Guix-emacs doesn't work

[Ricardo Wurmus]

Ryan Prior  writes:

>> this no longer seems to be a problem. Can you please confirm that this
>> issue can be closed now?
>
> I can confirm that the emacs-guix package is still broken.
>
> ## Steps to reproduce
> 1. launch Emacs in a container:
>   $ guix shell -C --no-cwd --expose=/gnu --expose=/var --share=/tmp  -E 
> DISPLAY emacs emacs-guix -- emacs
> 2. run M-x guix-installed-packages
>
> ### Expected result
> A list of installed packages should appear.

FWIW M-x guix-installed-packages (and all the other stuff) works for me
with my Emacs config.  I haven’t tried to reproduce this in a container
yet without my Emacs config, but I’ll try soon.

-- 
Ricardo

bug#55013: Guix-emacs doesn't work

[Ricardo Wurmus]

Hi Giovanni,

thank you for testing.

Can you please confirm that this is reproducible even in “guix shell -C”?

-- 
Ricardo

bug#55013: Guix-emacs doesn't work

[Ricardo Wurmus]

Hi,

this no longer seems to be a problem.  Can you please confirm that this
issue can be closed now?

-- 
Ricardo

bug#62280: r-learnr contains minified JavaScript

[Ricardo Wurmus]

The r-learnr package contains minified JavaScript files that need to be
minified from source:

learnr/inst/lib/tutorial/tutorial.js
learnr/inst/lib/i18n/i18next.min.js
learnr/inst/lib/i18n/tutorial-i18n-init.js
learnr/inst/lib/i18next/i18next.min.js
learnr/inst/lib/ace/ace.js
learnr/inst/lib/clipboardjs/clipboard.min.js
learnr/inst/lib/bootbox/bootbox.min.js
learnr/inst/lib/idb-keyval/idb-keyval-iife.js
learnr/inst/lib/idb-keyval/idb-keyval-iife-compat.min.js
learnr/inst/rmarkdown/templates/tutorial/resources/tutorial-format.js

-- 
Ricardo

bug#61902: r-maaslin2 is not reproducible

[Ricardo Wurmus]

The r-maaslin2 package builds example plots in PNG and PDF format.  The
scatter plots and box plots are not reproducible as the points are not
plotted in deterministic order.

-- 
Ricardo

bug#61795: “guix deploy” doesn’t build all derivations remotely

[Ricardo Wurmus]

I’m running “guix deploy deploy.scm” on a x86_64 host.  The deploy.scm
file looks like this:



deploy.scm
Description: Binary data

The target machine architecture is aarch64-linux, and the x86_64 host
cannot offload to any aarch64-linux machines.  The machine declaration
has the “build-locally?” property set to #false.  The manual says:

 ‘build-locally?’ (default: ‘#t’)
  If false, system derivations will be built on the machine
  being deployed to.

Not all derivations are built on the target machine, though:

--8<---cut here---start->8---
$ guix deploy deploy.scm
The following 1 machine will be deployed:
  elephly

guix deploy: deploying to elephly...
guix deploy: sending 0 store items (0 MiB) to '192.168.178.20'...
guix deploy: sending 0 store items (0 MiB) to '192.168.178.20'...
guix deploy: warning: the following accounts appear more than once: mpd
guix deploy: warning: the following accounts appear more than once: mpd
substitute: updating substitutes from 'https://ci.guix.gnu.org'... 100.0%
substitute: updating substitutes from 'https://bordeaux.guix.gnu.org'... 100.0%
The following derivation will be built:
  
/gnu/store/4cpy9hlikcqddydl5dh02lnxdqn67nzb-linux-libre-arm64-generic-with-midi-6.1.13.drv

8.1 MB will be downloaded
 guile-static-stripped-3.0.9  6.7MiB
   2.3MiB/s 00:03 ▕██▏ 100.0%
 e2fsprogs-1.46.4  1.1MiB   
   2.3MiB/s 00:00 ▕██▏ 100.0%
building 
/gnu/store/4cpy9hlikcqddydl5dh02lnxdqn67nzb-linux-libre-arm64-generic-with-midi-6.1.13.drv...
|builder for 
`/gnu/store/4cpy9hlikcqddydl5dh02lnxdqn67nzb-linux-libre-arm64-generic-with-midi-6.1.13.drv'
 failed with exit code 1
build of 
/gnu/store/4cpy9hlikcqddydl5dh02lnxdqn67nzb-linux-libre-arm64-generic-with-midi-6.1.13.drv
 failed
View build log at 
'/var/log/guix/drvs/4c/py9hlikcqddydl5dh02lnxdqn67nzb-linux-libre-arm64-generic-with-midi-6.1.13.drv.gz'.
guix deploy: error: build of 
`/gnu/store/4cpy9hlikcqddydl5dh02lnxdqn67nzb-linux-libre-arm64-generic-with-midi-6.1.13.drv'
 failed
--8<---cut here---end--->8---

These are the contents of the build log:

--8<---cut here---start->8---
@ unsupported-platform 
/gnu/store/4cpy9hlikcqddydl5dh02lnxdqn67nzb-linux-libre-arm64-generic-with-midi-6.1.13.drv
 aarch64-linux
while setting up the build environment: a `aarch64-linux' is required to build 
`/gnu/store/4cpy9hlikcqddydl5dh02lnxdqn67nzb-linux-libre-arm64-generic-with-midi-6.1.13.drv',
 but I am a `x86_64-linux'
--8<---cut here---end--->8---

It is also of note that a build of this derivation is attempted even
though it has successfully been built on the target machine.

-- 
Ricardo

bug#47985: CentOS : SELinux is preventing /usr/lib/systemd/systemd from read access on the lnk_file current-guix

[Ricardo Wurmus]

Hi,

the cil file has been updated to work with a more recent base policy as
provided by current Fedora releases.  We also updated the documentation
to make the relabeling step a little clearer.

Does this solve your problem?

-- 
Ricardo

bug#60946: java-logback-classic fails to build

[Ricardo Wurmus]

Hi,

I applied the patch and pushed commit
0d169401cbc9e1a418290d4d6cb03dac8babcde3.

-- 
Ricardo

bug#60719: [aarch64] grub-efi cannot be built because of qemu changes

[Ricardo Wurmus]

Ricardo Wurmus  writes:

> commit 71b8707100e2fbc00f123566717ba3958c6afabb seems to have broken
> reconfiguration of my aarch64 machine.

See also https://issues.guix.gnu.org/60719

-- 
Ricardo

bug#60608: keras is broken –> package bazel?

[Ricardo Wurmus]

We have an old version of keras.  This is now broken.  It is not
compatible with python-h5py > 2.10.  Our version of Tensorflow also
won’t work with h5py 3.

We can’t upgrade keras to anything above 2.2.5 because any later version
is built with Bazel.  We cannot build Bazel, because it needs a big pile
of jars that we haven’t packaged yet.

Tensorflow > 1.9 also requires Bazel.

We should work towards packaging Bazel.  Debian has a Bazel bootstrap
package, so I’m hopeful that it’s possible to package with some effort.

-- 
Ricardo

bug#49115: [PATCH 1/1] debbugs: Do not check for MIME encoded words in subject.

[Ricardo Wurmus]

Arun Isaac  writes:

> guile-email transparently handles MIME encoded words. We do not have
> to check for them.
>
> * mumi/debbugs.scm (bug-status): Do not check for MIME encoded words
> in subject.

Thank you, I applied it.

-- 
Ricardo

bug#49115: Mumi inserts spurious underscore in bug title

[Ricardo Wurmus]

Hi Arun,

> Thanks for the bug report!
>
> It's very strange, but I'm not able to reproduce this.

Thank you for your analysis!

> Even at https://issues.guix.gnu.org/49114 , only the "bug title" has the
> spurious underscore. The subject of the first message does not. Is the
> bug title something stored in the xapian index? Could it be that this
> was an older bug that has corrupted the xapian index?

As part of #60410 I rebuilt the xapian database (deleted it and then ran
“mumi fetch”), so it’s not that.

[… time passes …]

I think I found the culprit in mumi/debbugs.scm:

(define qp-pattern "=\\?UTF-8\\?Q\\?([^?]+)\\?=")
…
(let ((subject (or (assoc-ref properties "Subject") "")))
  (if (string-contains subject "=?UTF-8?Q?")
  (or (false-if-exception
   (utf8->string
(quoted-printable-decode
 (regexp-substitute/global #f qp-pattern
   subject 'pre 1 'post
  subject)
  subject))

I’m probably not using quoted-printable-decode correctly.  My apologies
for assuming a bug in Guile Email.  I changed this with commit
9d7eb3c5efe6427a1a89fb3e4c7165259edff4dd, using parse-email-headers.

> If I understand correctly, mumi does not rebuild its xapian index. I
> think it should do so from time to time. It would help prevent old bugs
> from getting persisted in storage.

True.  I’ll be sure to rebuild the index on the next upgrade.

> Cheers, and wish you a Happy New Year! :-)

Thank you, and a Happy New Year to you too!

-- 
Ricardo

bug#54206: [aarch64] kodi fails because of just one test

[Ricardo Wurmus]

This is still a problem as of Guix commit
e84f17ea939013f25a0dd1276659e27bc4c2198f.

I’ll try upgrading Kodi to 19.5.  There have been a few changes with
regard to the CPUInfo code.

-- 
Ricardo

bug#57775: guix shell --root fails

[Ricardo Wurmus]

I can no longer reproduce this.

-- 
Ricardo

bug#55120: “guix import cran” fails for some git repositories

[Ricardo Wurmus]

This has been fixed in the meantime.  If you still have this problem you
may need to remove your git checkout cache in ~/.cache/guix/checkouts.

-- 
Ricardo

bug#49115: Mumi inserts spurious underscore in bug title

[Ricardo Wurmus]

> See http://issues.guix.gnu.org/49114, which Mumi currently 
> titles
>
>   ‘guix_ lint’ should catch certificate validation exceptions
>
> There's no underscore in the original subject.

The debbugs “.log” file for issue 49114 contains this line:

  Subject: bug#49114: =?UTF-8?Q?=E2=80=98guix_?= =?UTF-8?Q?lint=E2=80=99?= 
should catch certificate validation exceptions

This is MIME Q encoding (similar to “quoted printable” encoding), as
specified in RFC 2047.

The underscore is mentioned in 4.2 (2):

   (2) The 8-bit hexadecimal value 20 (e.g., ISO-8859-1 SPACE) may be
   represented as "_" (underscore, ASCII 95.).  (This character may
   not pass through some internetwork mail gateways, but its use
   will greatly enhance readability of "Q" encoded data with mail
   readers that do not support this encoding.)  Note that the "_"
   always represents hexadecimal 20, even if the SPACE character
   occupies a different code position in the character set in use.

So, the underscore above ought to be replaced with a space.  This seems
to be a bug in guile-email.

-- 
Ricardo

bug#47520: mumi: wrong message is downloaded

[Ricardo Wurmus]

I cannot reproduce this with the current version of mumi.

https://issues.guix.gnu.org/47513#3 points to the restinio email, and
the download links fetch the corresponding email / message parts.

-- 
Ricardo

bug#41906: [mumi] Raw mailbox download not usable with mutt

[Ricardo Wurmus]

Commit 0a90eeda9b5e12a2f83e3917c46fa539f308d0c8 fixes this.  Debbugs
apparently stores the raw email with the first two lines swapped.  I
just swap the two lines back.  The output from mumi’s /raw endpoint now
only differs in trailing white space.

-- 
Ricardo

bug#48160: Mumi renders huge messages

[Ricardo Wurmus]

This is now fixed with mumi commit
ca4d83865943f2851b07deaf34b026705c46dd41.

The problem here was that the attachment did not come with a
content-disposition header reporting the size of the attachment.  As a
fall back mumi now also looks at the actual size of the message when
determining whether to hide a multipart message part.

-- 
Ricardo

bug#47739: Mumi: sorting the list of issues by date

[Ricardo Wurmus]

This is now fixed in mumi commit
4361d69de393a55ad27574d10d7c6ad62477a13e.

-- 
Ricardo

bug#58690: [PATCH] gnu: emacs-ess: Update to 18.10.2-1.01e7f5b.

[Ricardo Wurmus]

* gnu/packages/statistics.scm (emacs-ess): Update to 18.10.2-1.01e7f5b.
[source]: Update snippet; remove patch.
[arguments]: Use gexp; add phase "patch-test-suite"; run tests conditionally.
[inputs]: Drop package labels.
* gnu/packages/patches/emacs-ess-fix-obsolete-function-alias.patch: Remove file.
* gnu/local.mk (dist_patch_DATA): Remove it.
---
 gnu/local.mk  |  1 -
 ...macs-ess-fix-obsolete-function-alias.patch | 23 -
 gnu/packages/statistics.scm   | 87 +--
 3 files changed, 60 insertions(+), 51 deletions(-)
 delete mode 100644 
gnu/packages/patches/emacs-ess-fix-obsolete-function-alias.patch

diff --git a/gnu/local.mk b/gnu/local.mk
index 9443dd617a..f61141dd27 100644
--- a/gnu/local.mk
+++ b/gnu/local.mk
@@ -1055,7 +1055,6 @@ dist_patch_DATA = 
\
   %D%/packages/patches/elogind-revert-polkit-detection.patch   \
   %D%/packages/patches/emacs-deferred-fix-number-of-arguments.patch\
   %D%/packages/patches/emacs-exec-path.patch   \
-  %D%/packages/patches/emacs-ess-fix-obsolete-function-alias.patch \
   %D%/packages/patches/emacs-git-email-missing-parens.patch\
   %D%/packages/patches/emacs-fix-scheme-indent-function.patch  \
   %D%/packages/patches/emacs-json-reformat-fix-tests.patch \
diff --git a/gnu/packages/patches/emacs-ess-fix-obsolete-function-alias.patch 
b/gnu/packages/patches/emacs-ess-fix-obsolete-function-alias.patch
deleted file mode 100644
index f7b61391c3..00
--- a/gnu/packages/patches/emacs-ess-fix-obsolete-function-alias.patch
+++ /dev/null
@@ -1,23 +0,0 @@
-From 9cc5520e1998d03f5dec0fbb1fe71b7cdec38b65 Mon Sep 17 00:00:00 2001
-From: Alex Branham 
-Date: Wed, 6 Jan 2021 06:41:20 -0500
-Subject: [PATCH] Add required when to obsolete function alias
-
-Closes #1085

- lisp/ess-r-package.el | 2 +-
- 1 file changed, 1 insertion(+), 1 deletion(-)
-
-diff --git a/lisp/ess-r-package.el b/lisp/ess-r-package.el
-index 260959955..397ce14e6 100644
 a/lisp/ess-r-package.el
-+++ b/lisp/ess-r-package.el
-@@ -577,7 +577,7 @@ package mode. Use this function if state of the buffer 
such as
-   (error "As of ESS 16.04, `ess-developer' is deprecated. Use 
`ess-r-set-evaluation-env' instead"))
- 
- (defalias 'ess-toggle-developer 'ess-developer)
--(define-obsolete-function-alias 'ess-r-devtools-check-package-buildwin 
'ess-r-devtools-check-with-winbuilder)
-+(define-obsolete-function-alias 'ess-r-devtools-check-package-buildwin 
'ess-r-devtools-check-with-winbuilder "18.04")
- (define-obsolete-function-alias 'ess-r-devtools-ask 
'ess-r-devtools-execute-command "18.04")
- 
- (make-obsolete-variable 'ess-developer "Please use 
`ess-developer-select-package' and `ess-r-set-evaluation-env' instead." "16.04")
diff --git a/gnu/packages/statistics.scm b/gnu/packages/statistics.scm
index 16fb06e35a..3be9aea6cd 100644
--- a/gnu/packages/statistics.scm
+++ b/gnu/packages/statistics.scm
@@ -6426,11 +6426,10 @@ (define-public java-jdistlib
 (license license:gpl2+)))
 
 (define-public emacs-ess
-  ;; Latest release is old.  This is not the latest commit either due to bug
-  ;; reported here: .
-  (let ((commit "24da603184ce39246611dd5b8602e769d7ebd5bf")
+  ;; Latest release is old.
+  (let ((commit "01e7f5b482b8a3331f1341483dedf2bd30403423")
 (version "18.10.2")
-(revision "0"))
+(revision "1"))
 (package
   (name "emacs-ess")
   (version (git-version version revision commit))
@@ -6441,7 +6440,7 @@ (define-public emacs-ess
(url "https://github.com/emacs-ess/ESS;)
(commit commit)))
  (sha256
-  (base32 "0j98lv07nzwzd54d4dgcfz01wy5gj48m0mnirxzh5r45ik2myh1r"))
+  (base32 "1b40rbbqzgfxj88357aixq646g3v3f88k9kwhgmyyjy9lb2dljkb"))
  (file-name (git-file-name name version))
  (modules '((guix build utils)))
  (snippet
@@ -6459,9 +6458,6 @@ (define-public emacs-ess
  ;; Stop install-info from trying to update the info directory.
  (substitute* "doc/Makefile"
((".*/dir.*") ""))
- ;; Fix r-help-mode test.
- (substitute* "test/ess-test-r.el"
-   (("\\(equal ess-help-object \"plot.default\")") "t"))
  ;; Avoid generating ess-autoloads.el twice.
  (substitute* "Makefile"
(("all: lisp doc etc autoloads")
@@ -6471,30 +6467,67 @@ (define-public emacs-ess
(("mkdir -p \\$\\(ESSDESTDIR)")
 "$(MAKE) -C lisp install; $(MAKE) -C doc install")
(("\\$\\(INSTALL) -R \\./\\* \\$\\(ESSDESTDIR)/")
-"$(MAKE) -C etc install"))
- #t))
- (patches
-  (search-patches "emacs-ess-fix-obsolete-function-alias.patch"
+"$(MAKE) -C etc install"))
   (build-system gnu-build-system)
   (arguments
-   (let 

bug#59519: LibreOffice 7.3.5.2 fails to build on i686-linux

[Ricardo Wurmus]

I applied this patch:

  https://bug-attachments.documentfoundation.org/attachment.cgi?id=172646

And the error changed:

--8<---cut here---start->8---
ld: 
/tmp/guix-build-libreoffice-7.3.5.2.drv-0/libreoffice-7.3.5.2/workdir/CxxObject/xmloff/source/core/xmlimp.o:
 warning: relocation against 
`_ZThn20_N4cppu14WeakImplHelperIJN3com3sun4star3xml3sax18XFastAttributeListENS3_4util10XCloneableEEE7acquireEv'
 in read-only section `.text'
ld: 
/tmp/guix-build-libreoffice-7.3.5.2.drv-0/libreoffice-7.3.5.2/workdir/CxxObject/xmloff/source/core/xmlimp.o:
 in function `SvXMLImport::SetAutoStyles(SvXMLStylesContext*)':
xmlimp.cxx:(.text+0x86f2): undefined reference to `non-virtual thunk to 
cppu::WeakImplHelper::acquire()'
ld: warning: creating DT_TEXTREL in a shared object
collect2: error: ld returned 1 exit status
make[1]: *** 
[/tmp/guix-build-libreoffice-7.3.5.2.drv-0/libreoffice-7.3.5.2/xmloff/Library_xo.mk:20:
 
/tmp/guix-build-libreoffice-7.3.5.2.drv-0/libreoffice-7.3.5.2/instdir/program/libxolo.so]
 Error 1
--8<---cut here---end--->8---

I think this is pretty good.  We got past the original error and have a
very similar error in xmlimp, so I guess we’ll just extend this patch.

-- 
Ricardo

bug#59519: LibreOffice 7.3.5.2 fails to build on i686-linux

[Ricardo Wurmus]

I tried building with ld-gold-wrapper, but it didn’t fix it:

--8<---cut here---start->8---
ld: 
/tmp/guix-build-libreoffice-7.3.5.2.drv-0/libreoffice-7.3.5.2/workdir/CxxObject/svtools/source/misc/imageresourceaccess.o:
 warning: relocation against 
`_ZThn20_N4cppu21ImplInheritanceHelperIN3utl19OInputStreamWrapperEJN3com3sun4star2io9XSeekableEEE7acquireEv'
 in read-only section `.text'
[build CXX] reportdesign/source/ui/dlg/DateTime.cxx
ld: 
/tmp/guix-build-libreoffice-7.3.5.2.drv-0/libreoffice-7.3.5.2/workdir/CxxObject/svtools/source/misc/imageresourceaccess.o:
 in function 
`svt::GraphicAccess::getImageStream(com::sun::star::uno::Reference
 const&, rtl::OUString const&)':
imageresourceaccess.cxx:(.text+0xabb): undefined reference to `non-virtual 
thunk to cppu::ImplInheritanceHelper::acquire()'
ld: 
/tmp/guix-build-libreoffice-7.3.5.2.drv-0/libreoffice-7.3.5.2/workdir/CxxObject/svtools/source/misc/imageresourceaccess.o:
 in function `svt::GraphicAccess::getImageXStream(com::sun::star
::uno::Reference const&, rtl::OUString 
const&)':
imageresourceaccess.cxx:(.text+0x100e): undefined reference to `non-virtual 
thunk to cppu::ImplInheritanceHelper::acquire()'
ld: warning: creating DT_TEXTREL in a shared object
collect2: error: ld returned 1 exit status
make[1]: *** 
[/tmp/guix-build-libreoffice-7.3.5.2.drv-0/libreoffice-7.3.5.2/svtools/Library_svt.mk:20:
 
/tmp/guix-build-libreoffice-7.3.5.2.drv-0/libreoffice-7.3.5.2/instdir/program/libsvtlo.
so] Error 1
make[1]: *** Waiting for unfinished jobs
make: *** [Makefile:289: build] Error 2
--8<---cut here---end--->8---

Here’s the command I used:

  guix build --system=i686-linux -e "(begin (import (guix)) (let ((p (@ (gnu 
packages libreoffice) libreoffice))) (package (inherit p) (native-inputs 
(modify-inputs (package-native-inputs p) (prepend (module-ref 
(resolve-interface '(gnu packages commencement)) 'ld-gold-wrapper)))"

-- 
Ricardo

bug#59185: Trouble mounting recursive file systems in containers

[Ricardo Wurmus]

Ludovic Courtès  writes:

> Ricardo Wurmus  skribis:
>
>> yes, mounting with MS_REC seems sensible.  Not mounting with MS_REC is
>> also responsible for a couple of errors e.g. when trying to map / inside
>> the container (when / has other bind mounts).
>
> Having reread mount(2), bind-mounting with MS_REC by default seems like
> a reasonable choice, indeed.

Great.  I’ve pushed this with commit c585b4bc68813a351d6a87d19b9adf4041506355.

-- 
Ricardo

bug#59185: Trouble mounting recursive file systems in containers

[Ricardo Wurmus]

Hi Morgan,

yes, mounting with MS_REC seems sensible.  Not mounting with MS_REC is
also responsible for a couple of errors e.g. when trying to map / inside
the container (when / has other bind mounts).

Here’s a patch that works for me:

>From 806969ad86038052bf4d0dd2755617beaaa33cb6 Mon Sep 17 00:00:00 2001
From: Ricardo Wurmus 
Date: Sat, 19 Nov 2022 23:16:52 +0100
Subject: [PATCH] WIP

---
 gnu/build/file-systems.scm | 2 +-
 guix/build/syscalls.scm| 2 ++
 2 files changed, 3 insertions(+), 1 deletion(-)

diff --git a/gnu/build/file-systems.scm b/gnu/build/file-systems.scm
index 15b8f73312..66ca22d6ea 100644
--- a/gnu/build/file-systems.scm
+++ b/gnu/build/file-systems.scm
@@ -1127,7 +1127,7 @@ (define (mount-flags->bit-mask flags)
   (('read-only rest ...)
(logior MS_RDONLY (loop rest)))
   (('bind-mount rest ...)
-   (logior MS_BIND (loop rest)))
+   (logior MS_REC (logior MS_BIND (loop rest
   (('no-suid rest ...)
(logior MS_NOSUID (loop rest)))
   (('no-dev rest ...)
diff --git a/guix/build/syscalls.scm b/guix/build/syscalls.scm
index 61926beb80..2a12567b15 100644
--- a/guix/build/syscalls.scm
+++ b/guix/build/syscalls.scm
@@ -51,6 +51,7 @@ (define-module (guix build syscalls)
 MS_RELATIME
 MS_BIND
 MS_MOVE
+MS_REC
 MS_SHARED
 MS_LAZYTIME
 MNT_FORCE
@@ -541,6 +542,7 @@ (define MS_NOATIME 1024)
 (define MS_NODIRATIME  2048)
 (define MS_BIND4096)
 (define MS_MOVE8192)
+(define MS_REC16384)
 (define MS_SHARED   1048576)
 (define MS_RELATIME 2097152)
 (define MS_STRICTATIME 16777216)
-- 
2.36.1



-- 
Ricardo

bug#58878: build log filter broken by odd characters in build output

[Ricardo Wurmus]

Here I am, minding my own business, building GHC 6.10.4 with GHC 6.6 and
I see this in the build output:

--8<---cut here---start->8---
/gnu/store/km47738v7q4qgym9zkggngqxr05q165h-ghc-6.6/bin/ghc -#include cutils.h 
-DSTAGE=1 -package-name ghc-6.10.4 -hide-all-packages -no-user-package-conf 
-package-conf 
/tmp/guix-build-ghc-6.10.4.drv-0/ghc-6.10.4/libraries/bootstrapping.conf -i 
-idist-stage1/build -inativeGen -ibasicTypes -icmm -icodeGen -icoreSyn 
-icprAnalysis -ideSugar -ighci -ihsSyn -iiface -imain -iparser -iprelude 
-iprofiling -irename -isimplCore -isimplStg -ispecialise -istgSyn -istranal 
-itypecheck -itypes -iutils -ivectorise -idist-stage1/build/autogen 
-Idist-stage1/build/autogen -Idist-stage1/build -Istage1 
-I../libraries/base/cbits -I../libraries/base/include -I. -Iparser -Iutils 
-optP-include -optPdist-stage1/build/autogen/cabal_macros.h -odir 
dist-stage1/build -hidir dist-stage1/build -package Cabal-1.6.0.3 -package 
base-2.0 -package extensible-exceptions-0.1.1.0 -package filepath-1.1.0.2 
-package haskell98-1.0 -package hpc-0.5.0.3 -package unix-1.0 -O -Wall 
-fno-warn-name-shadowing -fno-warn-orphans -fglasgow-exts -cpp -fffi 
-fscoped-type-variables -idist-stage1/build  -H32m -O -Rghc-timing   -c 
nativeGen/MachCodeGen.hs -o dist-stage1/build/MachCodeGen.o  -ohi 
dist-stage1/build/MachCodeGen.hi
/tmp/guix-build-ghc-6.10.4.drv-0/ghc7957_0/ghc7957_0.hc: In function ���@ 
build-log 17895 2
��@ build-log 17895 2
sb@ build-log 17895 3
ZI_@ build-log 17895 2
0_@ build-log 17895 2
al@ build-log 17895 2
t�@ build-log 17895 2
��@ build-log 17895 2
:

/tmp/guix-build-ghc-6.10.4.drv-0/ghc7957_0/ghc7957_0.hc:2881:1:
 warning: implicit declaration of function ‘stg_intToInt64’ 
[-Wimplicit-function-declaration]
 _s9Fa = (StgWord64)stg_intToInt64((I_)_cc02);
 ^

/tmp/guix-build-ghc-6.10.4.drv-0/ghc7957_0/ghc7957_0.hc:2884:1:
 warning: implicit declaration of function ‘stg_negateInt64’ 
[-Wimplicit-function-declaration]
 _s9Ff = (StgWord64)stg_negateInt64((StgInt64)_s9Fa);
 ^
/tmp/guix-build-ghc-6.10.4.drv-0/ghc7957_0/ghc7957_0.hc: In function 
‘sbZI_1_alt’:

/tmp/guix-build-ghc-6.10.4.drv-0/ghc7957_0/ghc7957_0.hc:2910:1:
 warning: implicit declaration of function ���@ build-log 17895 1
�@ build-log 17895 1
�@ build-log 17895 1
s@ build-log 17895 1
t@ build-log 17895 1
g@ build-log 17895 1
_@ build-log 17895 1
i@ build-log 17895 1
n@ build-log 17895 1
t@ build-log 17895 1
e@ build-log 17895 1
g@ build-log 17895 1
e@ build-log 17895 1
r@ build-log 17895 1
T@ build-log 17895 1
o@ build-log 17895 1
I@ build-log 17895 1
n@ build-log 17895 1
t@ build-log 17895 1
6@ build-log 17895 1
4@ build-log 17895 1
�@ build-log 17895 1
�@ build-log 17895 1
�@ build-log 17895 1
 @ build-log 17895 1
[@ build-log 17895 1
-@ build-log 17895 1
W@ build-log 17895 1
i@ build-log 17895 1
m@ build-log 17895 1
p@ build-log 17895 1
l@ build-log 17895 1
i@ build-log 17895 1
c@ build-log 17895 1
i@ build-log 17895 1
t@ build-log 17895 1
-@ build-log 17895 1
f@ build-log 17895 1
u@ build-log 17895 1
n@ build-log 17895 1
c@ build-log 17895 1
t@ build-log 17895 1
i@ build-log 17895 1
o@ build-log 17895 1
n@ build-log 17895 1
-@ build-log 17895 1
d@ build-log 17895 1
e@ build-log 17895 1
c@ build-log 17895 1
l@ build-log 17895 1
a@ build-log 17895 1
r@ build-log 17895 1
a@ build-log 17895 1
t@ build-log 17895 1
i@ build-log 17895 1
o@ build-log 17895 1
n@ build-log 17895 1
]@ build-log 17895 1

 _s9Fq = (StgWord64)stg_integerToInt64((I_)_cc0a, (void *)_cc09);
 ^
--8<---cut here---end--->8---

Whatever this “���” is, it seems to have escaped the build log filter.

-- 
Ricardo

bug#28240: bad backtrace on “guix archive -x”

[Ricardo Wurmus]

zimoun  writes:

>> guix archive: error: corrupt input while restoring '/tmp/ci' from #> file 0>
>
> The situation is still the same.  Well, is the “guix archive” error the
> point of this bug report?

The point is the terrible backtrace.  While this error is a little
better it’s also not great.

But my primary concern is to prevent ’guix archive’ from printing a bad
backtrace.  Doesn’t matter what we feed it.

-- 
Ricardo

bug#58333: Manual PDFs other than en and es fail to build

[Ricardo Wurmus]

Julien Lepiller  writes:

> You can push this fix directly to the repo, but please also fix it on
> weblate or it'll break again next time I update translations.

I pushed the fix and made a change in the German translation on weblate;
the change for the French translation had already been made on weblate.

-- 
Ricardo

bug#58333: Manual PDFs other than en and es fail to build

[Ricardo Wurmus]

With these two changes I can build both German and French PDF manuals:

diff --git a/po/doc/guix-manual.de.po b/po/doc/guix-manual.de.po
index edbe853248..cd7eff86f5 100644
--- a/po/doc/guix-manual.de.po
+++ b/po/doc/guix-manual.de.po
@@ -38181,7 +38181,7 @@ msgstr "{Scheme-Variable} webssh-service-type"
 #. type: deffn
 #: guix-git/doc/guix.texi:20494
 msgid "This is the type for the @uref{https://webssh.huashengdun.org/, WebSSH} program that runs a web SSH client.  WebSSH can be run manually from the command-line by passing arguments to the binary @command{wssh} from the package @code{webssh}, but it can also be run as a Guix service.  This latter use case is documented here."
-msgstr "Dies ist der Diensttyp für das Programm @uref{@uref{https://webssh.huashengdun.org/, WebSSH}}, das einen webbasierten SSH-Client ausführt. WebSSH kann von Hand aus der Befehlszeile heraus aufgerufen werden, indem man Argumente an die Binärdatei @command{wssh} aus dem Paket @code{webssh} übergibt, aber es kann auch als ein Guix-Dienst ausgeführt werden. Letzteres wird hier beschrieben."
+msgstr "Dies ist der Diensttyp für das Programm @uref{https://webssh.huashengdun.org/, WebSSH}, das einen webbasierten SSH-Client ausführt. WebSSH kann von Hand aus der Befehlszeile heraus aufgerufen werden, indem man Argumente an die Binärdatei @command{wssh} aus dem Paket @code{webssh} übergibt, aber es kann auch als ein Guix-Dienst ausgeführt werden. Letzteres wird hier beschrieben."
 
 #. type: deffn
 #: guix-git/doc/guix.texi:20500
diff --git a/po/doc/guix-manual.fr.po b/po/doc/guix-manual.fr.po
index 6762909beb..b0de8a75ba 100644
--- a/po/doc/guix-manual.fr.po
+++ b/po/doc/guix-manual.fr.po
@@ -48355,7 +48355,7 @@ msgstr "Les champs de @code{getmail-retriever-configuration} disponibles sont :"
 #: guix-git/doc/guix.texi:25540
 #, no-wrap
 msgid "{@code{getmail-retriever-configuration} parameter} string type"
-msgstr "{paramètre de @code{getmail-retriever-configuration}}string type"
+msgstr "{paramètre de @code{getmail-retriever-configuration}} string type"
 
 #. type: deftypevr
 #: guix-git/doc/guix.texi:25543

-- 
Ricardo

bug#58333: Manual PDFs other than en and es fail to build

[Ricardo Wurmus]

Ricardo Wurmus  writes:

> The error in guix.de.texi is an infinite loop.  The location it points
> out is wrong syntax:
>
> @uref{@uref{https://webssh.huashengdun.org/, WebSSH}}
>
> There shouldn’t be a double-wrapping in @uref.

I can confirm that fixing the bad translation in
po/doc/guix-manual.de.po allows us to build the German version of the
PDF manual.

-- 
Ricardo

bug#58333: Manual PDFs other than en and es fail to build

[Ricardo Wurmus]

The first error in guix.fr.texi is encountered here:

--8<---cut here---start->8---
Overfull \hbox (31.11255pt too wide) in paragraph at lines 26508--26508
 []@deftt getmail-retriever-configuration[] |
Runaway argument?
1 @advance @rightskip by 0pt plus 1fil@relax @endgraf @nobreak @vskip 
-@parskip @penalty @defunpenalty @checkparencounts @endgroup Le type de 
récupérateur de courriel à utiliser. Des valeurs valides sont @samp {passwd} et 
@samp {static}.@ETC.
/gnu/store/lrw46dlqll6z9pxm18zqvwxfmi03w7kp-texinfo-manual-source/guix.fr.texi:26517:
 Paragraph ended before @deftypecvgeneral was complete.
 
   @par 
l.26517 
--8<---cut here---end--->8---

I don’t see anything wrong here, but I’ll note a missing space after }}
on the first line:

--8<---cut here---start->8---
@deftypevr {paramètre de @code{getmail-retriever-configuration}}string type
Le type de récupérateur de courriel à utiliser.  Des valeurs valides sont
@samp{passwd} et @samp{static}.

La valeur par défaut est @samp{"SimpleIMAPSSLRetriever"}.

@end deftypevr
--8<---cut here---end--->8---


-- 
Ricardo

bug#58333: Manual PDFs other than en and es fail to build

[Ricardo Wurmus]

The error in guix.de.texi is an infinite loop.  The location it points
out is wrong syntax:

@uref{@uref{https://webssh.huashengdun.org/, WebSSH}}

There shouldn’t be a double-wrapping in @uref.

-- 
Ricardo

bug#58308: guix import -r swallows errors

[Ricardo Wurmus]

Consider this:

   $ ./pre-inst-env guix import elpa -r syslog
   $ echo $?
   0

And now this:

   $ ./pre-inst-env guix import elpa syslog
   guix import: error: failed to download package 'syslog'
   $ echo $?
   1

The recursive importer swallows the error.

-- 
Ricardo

bug#58149: Unable to pull when using a pre-lzip version of guix-daemon

[Ricardo Wurmus]

I’d just like to note what I do when I’m finding myself in a situation
where I’m tempted to run “guix pull” from a very old version of Guix:

1. visit https://ci.guix.gnu.org and select the “guix” jobset.
2. select a recent successful evaluation, e.g. 
https://ci.guix.gnu.org/eval/686692
3. select a build for your architecture, e.g. 
https://ci.guix.gnu.org/build/1565155/details
4. copy the derivation, e.g. 
/gnu/store/z0zhkvvmnjaji1i6lan0gxdqxhkr59as-guix-17134b9ec.drv
5. run “guix build 
/gnu/store/z0zhkvvmnjaji1i6lan0gxdqxhkr59as-guix-17134b9ec.drv”; this very 
noisily substitutes
the derivation and eventually prints 
“/gnu/store/pl3vs9a35mb0zmmpqimsxvl8ddl1bn41-guix-17134b9ec”

You now have an inconveniently named, but very recent Guix!

If your guix-daemon is too old you can replace it with
/gnu/store/pl3vs9a35mb0zmmpqimsxvl8ddl1bn41-guix-17134b9ec/bin/guix-daemon;
then you run 
/gnu/store/pl3vs9a35mb0zmmpqimsxvl8ddl1bn41-guix-17134b9ec/bin/guix pull, which 
upgrades
your Guix at ~/.config/guix/current.

Hope this helps!

-- 
Ricardo

bug#42141: blast+ is not reproducible

[Ricardo Wurmus]

zimoun  writes:

> Hi,
>
> On Thu, 29 Sep 2022 at 23:09, Maxim Cournoyer  
> wrote:
>> Ricardo Wurmus  writes:
>>
>>> Fixed with commit 1ee2d117d8fa9e2e0d4ec46cc497bb5e6337.
>>
>> Yay!  Thank you!  And for my curiosity, how did I get the two build
>> farms to agree on an identical build, as reported in 'guix challenge'?
>>
>> That is odd.
>
> Because blast+ is multi-outputs and ’out’ is fine contrary to ’include’:
>
> $ guix challenge blast+:include
> /gnu/store/0kbsdr61qpj0vkc6s8g2kbp4dq936n0p-blast+-2.11.0-include contents 
> differ:
>   local hash: 0q4nssknlmc54m8abndn9bhrlwm4m28lkb75i1wnwr0ghbalj02x
>   
> https://ci.guix.gnu.org/nar/lzip/0kbsdr61qpj0vkc6s8g2kbp4dq936n0p-blast%2B-2.11.0-include:
>  0q4nssknlmc54m8abndn9bhrlwm4m28lkb75i1wnwr0ghbalj02x
>   
> https://bordeaux.guix.gnu.org/nar/lzip/0kbsdr61qpj0vkc6s8g2kbp4dq936n0p-blast%2B-2.11.0-include:
>  0cakizfsqb1lla62cmwnng1h9gvqgf3lyjk0k7lkiaisj713mpzx
>   differing files:
> /include/ncbi-tools++/ncbi-tools++/ncbi_random_macro.h
> /include/ncbi-tools++/ncbi-tools++/ncbiconf_unix.h
>
> 1 store items were analyzed:
>   - 0 (0.0%) were identical
>   - 1 (100.0%) differed
>   - 0 (0.0%) were inconclusive

Ah, thanks for explaining!

-- 
Ricardo

bug#42141: blast+ is not reproducible

[Ricardo Wurmus]

Maxim Cournoyer  writes:

> Ricardo Wurmus  writes:
>
>> Fixed with commit 1ee2d117d8fa9e2e0d4ec46cc497bb5e6337.
>
> Yay!  Thank you!  And for my curiosity, how did I get the two build
> farms to agree on an identical build, as reported in 'guix challenge'?
>
> That is odd.

I don’t know.  I also got the same result from “guix challenge”, but I
hadn’t built it locally.  It was only when I built it on my machine (and
with “--check”) that I confirmed that the issue still existed.

Any way of making “guix challenge” tell us more about what it actually
compared?

-- 
Ricardo

bug#42141: blast+ is not reproducible

[Ricardo Wurmus]

Fixed with commit 1ee2d117d8fa9e2e0d4ec46cc497bb5e6337.

-- 
Ricardo

bug#42141: blast+ is not reproducible

[Ricardo Wurmus]

Ricardo Wurmus  writes:

> reopen 42141
> thanks
>
> Maxim Cournoyer  writes:
>
>> Hi,
>>
>> Ricardo Wurmus  writes:
>>
>>> This should be rather easy to fix:
>>>
>>> diff -r
>>> /gnu/store/3y97kfanv9ynxnahyykixchlbpbyvjmm-blast+-2.10.1-include
>>> /gnu/store/3y97kfanv9ynxnahyykixchlbpbyvjmm-blast+-2.10.1-include-check
>>> diff -r
>>> /gnu/store/3y97kfanv9ynxnahyykixchlbpbyvjmm-blast+-2.10.1-include/include/ncbi-tools++/ncbi-tools++/ncbi_random_macro.h
>>> /gnu/store/3y97kfanv9ynxnahyykixchlbpbyvjmm-blast+-2.10.1-include-check/include/ncbi-tools++/ncbi-tools++/ncbi_random_macro.h
>>> 4,13c4,13
>>> < #define NCBI_RANDOM_VALUE_01770246234u
>>> < #define NCBI_RANDOM_VALUE_12685550394u
>>> < #define NCBI_RANDOM_VALUE_21952513968u
>>> < #define NCBI_RANDOM_VALUE_34081691487u
>>> < #define NCBI_RANDOM_VALUE_41126642990u
>>> < #define NCBI_RANDOM_VALUE_52363626105u
>>> < #define NCBI_RANDOM_VALUE_6444644742u
>>> < #define NCBI_RANDOM_VALUE_72799580837u
>>> < #define NCBI_RANDOM_VALUE_8216161479u
>>> < #define NCBI_RANDOM_VALUE_9992434062u
>>> ---
>>>> #define NCBI_RANDOM_VALUE_02851596927u
>>>> #define NCBI_RANDOM_VALUE_14039058594u
>>>> #define NCBI_RANDOM_VALUE_23204116600u
>>>> #define NCBI_RANDOM_VALUE_34270143185u
>>>> #define NCBI_RANDOM_VALUE_41366873742u
>>>> #define NCBI_RANDOM_VALUE_5703144487u
>>>> #define NCBI_RANDOM_VALUE_62507785646u
>>>> #define NCBI_RANDOM_VALUE_73995716134u
>>>> #define NCBI_RANDOM_VALUE_8907933519u
>>>> #define NCBI_RANDOM_VALUE_91149060107u
>>
>> Not anymore, according to:
>>
>> $ guix challenge blast+
>>
>> 1 store items were analyzed:
>>   - 1 (100.0%) were identical
>>   - 0 (0.0%) differed
>>   - 0 (0.0%) were inconclusive
>
> This is still a problem:
>
> $ diff -ru /gnu/store/0kbsdr61qpj0vkc6s8g2kbp4dq936n0p-blast+-2.11.0-include 
> /gnu/store/0kbsdr61qpj0vkc6s8g2kbp4dq936n0p-blast+-2.11.0-include-check
> diff -ru 
> /gnu/store/0kbsdr61qpj0vkc6s8g2kbp4dq936n0p-blast+-2.11.0-include/include/ncbi-tools++/ncbi-tools++/ncbiconf_unix.h
>  
> /gnu/store/0kbsdr61qpj0vkc6s8g2kbp4dq936n0p-blast+-2.11.0-include-check/include/ncbi-tools++/ncbi-tools++/ncbiconf_unix.h
> --- 
> /gnu/store/0kbsdr61qpj0vkc6s8g2kbp4dq936n0p-blast+-2.11.0-include/include/ncbi-tools++/ncbi-tools++/ncbiconf_unix.h
>1970-01-01 01:00:01.0 +0100
> +++ 
> /gnu/store/0kbsdr61qpj0vkc6s8g2kbp4dq936n0p-blast+-2.11.0-include-check/include/ncbi-tools++/ncbi-tools++/ncbiconf_unix.h
>  1970-01-01 01:00:01.0 +0100
> @@ -1095,7 +1095,7 @@
>  
>  /* Build signature: compiler-name '_' compiler-version '-' configuration '--'
> platform-name '-' hostname */
> -#define NCBI_SIGNATURE 
> "GCC_1030-DebugMTDLL64--x86_64-unknown-linux5.15.10-gnu2.33-localhost"
> +#define NCBI_SIGNATURE 
> "GCC_1030-DebugMTDLL64--x86_64-unknown-linux5.15.59-gnu2.33-localhost"
>  
>  /* Define to 1 if SQLColAttribute's last argument is an SQLLEN * */
>  #define NCBI_SQLCOLATTRIBUTE_SQLLEN 1
> diff -ru 
> /gnu/store/0kbsdr61qpj0vkc6s8g2kbp4dq936n0p-blast+-2.11.0-include/include/ncbi-tools++/ncbi-tools++/ncbi_random_macro.h
>  
> /gnu/store/0kbsdr61qpj0vkc6s8g2kbp4dq936n0p-blast+-2.11.0-include-check/include/ncbi-tools++/ncbi-tools++/ncbi_random_macro.h
> --- 
> /gnu/store/0kbsdr61qpj0vkc6s8g2kbp4dq936n0p-blast+-2.11.0-include/include/ncbi-tools++/ncbi-tools++/ncbi_random_macro.h
>1970-01-01 01:00:01.0 +0100
> +++ 
> /gnu/store/0kbsdr61qpj0vkc6s8g2kbp4dq936n0p-blast+-2.11.0-include-check/include/ncbi-tools++/ncbi-tools++/ncbi_random_macro.h
>  1970-01-01 01:00:01.0 +0100
> @@ -1,13 +1,13 @@
>  #define NCBI_RANDOM_VALUE_TYPE Uint4
>  #define NCBI_RANDOM_VALUE_MIN  0
>  #define NCBI_RANDOM_VALUE_MAX  0xu
> -#define NCBI_RANDOM_VALUE_03249030781u
> -#define NCBI_RANDOM_VALUE_13573796697u
> -#define NCBI_RANDOM_VALUE_22130009325u
> -#define NCBI_RANDOM_VALUE_34284761029u
> -#define NCBI_RANDOM_VALUE_43467737853u
> -#define NCBI_RANDOM_VALUE_53267844710u
> -#define NCBI_RANDOM_VALUE_64107058373u
> -#define NCBI_RANDOM_VALUE_7166436459u
> -#define NCBI_RANDOM_VALUE_8960927418u
> -#define NCBI_RANDOM_VALUE_93839848519u
> +#define NCBI_RANDOM_VALUE_02845495105u
> +#define NCBI_RANDOM_VALUE_12158634051u
> +#define NCBI_RANDOM_VALUE_24072202242u
> +#define NCBI_RANDOM_VALUE

bug#42141: blast+ is not reproducible

[Ricardo Wurmus]

reopen 42141
thanks

Maxim Cournoyer  writes:

> Hi,
>
> Ricardo Wurmus  writes:
>
>> This should be rather easy to fix:
>>
>> diff -r
>> /gnu/store/3y97kfanv9ynxnahyykixchlbpbyvjmm-blast+-2.10.1-include
>> /gnu/store/3y97kfanv9ynxnahyykixchlbpbyvjmm-blast+-2.10.1-include-check
>> diff -r
>> /gnu/store/3y97kfanv9ynxnahyykixchlbpbyvjmm-blast+-2.10.1-include/include/ncbi-tools++/ncbi-tools++/ncbi_random_macro.h
>> /gnu/store/3y97kfanv9ynxnahyykixchlbpbyvjmm-blast+-2.10.1-include-check/include/ncbi-tools++/ncbi-tools++/ncbi_random_macro.h
>> 4,13c4,13
>> < #define NCBI_RANDOM_VALUE_01770246234u
>> < #define NCBI_RANDOM_VALUE_12685550394u
>> < #define NCBI_RANDOM_VALUE_21952513968u
>> < #define NCBI_RANDOM_VALUE_34081691487u
>> < #define NCBI_RANDOM_VALUE_41126642990u
>> < #define NCBI_RANDOM_VALUE_52363626105u
>> < #define NCBI_RANDOM_VALUE_6444644742u
>> < #define NCBI_RANDOM_VALUE_72799580837u
>> < #define NCBI_RANDOM_VALUE_8216161479u
>> < #define NCBI_RANDOM_VALUE_9992434062u
>> ---
>>> #define NCBI_RANDOM_VALUE_02851596927u
>>> #define NCBI_RANDOM_VALUE_14039058594u
>>> #define NCBI_RANDOM_VALUE_23204116600u
>>> #define NCBI_RANDOM_VALUE_34270143185u
>>> #define NCBI_RANDOM_VALUE_41366873742u
>>> #define NCBI_RANDOM_VALUE_5703144487u
>>> #define NCBI_RANDOM_VALUE_62507785646u
>>> #define NCBI_RANDOM_VALUE_73995716134u
>>> #define NCBI_RANDOM_VALUE_8907933519u
>>> #define NCBI_RANDOM_VALUE_91149060107u
>
> Not anymore, according to:
>
> $ guix challenge blast+
>
> 1 store items were analyzed:
>   - 1 (100.0%) were identical
>   - 0 (0.0%) differed
>   - 0 (0.0%) were inconclusive

This is still a problem:

--8<---cut here---start->8---
$ diff -ru /gnu/store/0kbsdr61qpj0vkc6s8g2kbp4dq936n0p-blast+-2.11.0-include 
/gnu/store/0kbsdr61qpj0vkc6s8g2kbp4dq936n0p-blast+-2.11.0-include-check
diff -ru 
/gnu/store/0kbsdr61qpj0vkc6s8g2kbp4dq936n0p-blast+-2.11.0-include/include/ncbi-tools++/ncbi-tools++/ncbiconf_unix.h
 
/gnu/store/0kbsdr61qpj0vkc6s8g2kbp4dq936n0p-blast+-2.11.0-include-check/include/ncbi-tools++/ncbi-tools++/ncbiconf_unix.h
--- 
/gnu/store/0kbsdr61qpj0vkc6s8g2kbp4dq936n0p-blast+-2.11.0-include/include/ncbi-tools++/ncbi-tools++/ncbiconf_unix.h
 1970-01-01 01:00:01.0 +0100
+++ 
/gnu/store/0kbsdr61qpj0vkc6s8g2kbp4dq936n0p-blast+-2.11.0-include-check/include/ncbi-tools++/ncbi-tools++/ncbiconf_unix.h
   1970-01-01 01:00:01.0 +0100
@@ -1095,7 +1095,7 @@
 
 /* Build signature: compiler-name '_' compiler-version '-' configuration '--'
platform-name '-' hostname */
-#define NCBI_SIGNATURE 
"GCC_1030-DebugMTDLL64--x86_64-unknown-linux5.15.10-gnu2.33-localhost"
+#define NCBI_SIGNATURE 
"GCC_1030-DebugMTDLL64--x86_64-unknown-linux5.15.59-gnu2.33-localhost"
 
 /* Define to 1 if SQLColAttribute's last argument is an SQLLEN * */
 #define NCBI_SQLCOLATTRIBUTE_SQLLEN 1
diff -ru 
/gnu/store/0kbsdr61qpj0vkc6s8g2kbp4dq936n0p-blast+-2.11.0-include/include/ncbi-tools++/ncbi-tools++/ncbi_random_macro.h
 
/gnu/store/0kbsdr61qpj0vkc6s8g2kbp4dq936n0p-blast+-2.11.0-include-check/include/ncbi-tools++/ncbi-tools++/ncbi_random_macro.h
--- 
/gnu/store/0kbsdr61qpj0vkc6s8g2kbp4dq936n0p-blast+-2.11.0-include/include/ncbi-tools++/ncbi-tools++/ncbi_random_macro.h
 1970-01-01 01:00:01.0 +0100
+++ 
/gnu/store/0kbsdr61qpj0vkc6s8g2kbp4dq936n0p-blast+-2.11.0-include-check/include/ncbi-tools++/ncbi-tools++/ncbi_random_macro.h
   1970-01-01 01:00:01.0 +0100
@@ -1,13 +1,13 @@
 #define NCBI_RANDOM_VALUE_TYPE Uint4
 #define NCBI_RANDOM_VALUE_MIN  0
 #define NCBI_RANDOM_VALUE_MAX  0xu
-#define NCBI_RANDOM_VALUE_03249030781u
-#define NCBI_RANDOM_VALUE_13573796697u
-#define NCBI_RANDOM_VALUE_22130009325u
-#define NCBI_RANDOM_VALUE_34284761029u
-#define NCBI_RANDOM_VALUE_43467737853u
-#define NCBI_RANDOM_VALUE_53267844710u
-#define NCBI_RANDOM_VALUE_64107058373u
-#define NCBI_RANDOM_VALUE_7166436459u
-#define NCBI_RANDOM_VALUE_8960927418u
-#define NCBI_RANDOM_VALUE_93839848519u
+#define NCBI_RANDOM_VALUE_02845495105u
+#define NCBI_RANDOM_VALUE_12158634051u
+#define NCBI_RANDOM_VALUE_24072202242u
+#define NCBI_RANDOM_VALUE_3902228395u
+#define NCBI_RANDOM_VALUE_41353323915u
+#define NCBI_RANDOM_VALUE_5574823513u
+#define NCBI_RANDOM_VALUE_64119501261u
+#define NCBI_RANDOM_VALUE_72477640938u
+#define NCBI_RANDOM_VALUE_82776595395u
+#define NCBI_RANDOM_VALUE_9270550684u
--8<---cut here---end--->8---

-- 
Ricardo

bug#57853: “inappropriate ioctl for device” when running in RStudio Server

[Ricardo Wurmus]

When running “guix” in RStudio Server the “terminal-window-size”
procedure triggers an error.  (You can ignore the cause of the error,
because I’m running this in a container where
/var/guix/profiles/per-user/rekado doesn’t exist.)

--8<---cut here---start->8---
> system("/bin/guix pull")
guix pull: error: while creating directory 
`/var/guix/profiles/per-user/rekado': Permission denied
hint: Backtrace:
  18 (primitive-load "/bin/guix")
In guix/ui.scm:
   2263:7 17 (run-guix . _)
  2226:10 16 (run-guix-command _ . _)
In ice-9/boot-9.scm:
  1752:10 15 (with-exception-handler _ _ #:unwind? _ # _)
  1747:15 14 (with-exception-handler # …)
  1752:10 13 (with-exception-handler _ _ #:unwind? _ # _)
In guix/store.scm:
   656:37 12 (thunk)
In guix/status.scm:
815:4 11 (call-with-status-report _ _)
In guix/store.scm:
   1318:3 10 (_)
   1295:8  9 (call-with-build-handler # …)
In guix/scripts/pull.scm:
526:3  8 (_)
In guix/profiles.scm:
   2300:6  7 (ensure-profile-directory)
In ice-9/boot-9.scm:
  1685:16  6 (raise-exception _ #:continuable? _)
  1685:16  5 (raise-exception _ #:continuable? _)
In guix/ui.scm:
   827:16  4 (_ _)
   311:42  3 (display-hint "Please create the @file{/var/guix/profi…" …)
In ice-9/boot-9.scm:
  1747:15  2 (with-exception-handler # …)
In guix/build/syscalls.scm:
  2287:35  1 (_)
   2276:8  0 (terminal-window-size _)

guix/build/syscalls.scm:2276:8: In procedure terminal-window-size:
In procedure terminal-window-size: Inappropriate ioctl for device
--8<---cut here---end--->8---

Here yousee that the call to terminal-window-size fails because the
RStudio Server IDE in the web browser is not a true TTY.
“terminal-window-size” should fail gracefully.

-- 
Ricardo

bug#57077: guix-jupyter fails a test

[Ricardo Wurmus]

Unfortunately, guix-jupyter still fails to build for me as of commit
29d52a56f2d254781b65dbec0f1009db0b9d06e6.

--8<---cut here---start->8---
==
   Guix-Jupyter 0.2.2: ./test-suite.log
==

# TOTAL: 36
# PASS:  33
# SKIP:  0
# XFAIL: 0
# FAIL:  3
# XPASS: 0
# ERROR: 0

.. contents:: :depth: 2

FAIL: tests/kernels
===

/gnu/store/msd98spsahl2vxc2g2z2wgyai10dyr14-python-ipython-8.2.0/lib/python3.9/site-packages/IPython/paths.py:70:
 UserWarning: IPython parent '/homeless-shelter' is not a writable location, 
using a temp directory.
  warn("IPython parent '{0}' is not a writable location,"
NOTE: When using the `ipython kernel` entry point, Ctrl-C will not work.

To exit, you will have to explicitly quit this process, by either sending
"quit" from a client, or using Ctrl-\ in UNIX-like environments.

To read more about this, see https://github.com/ipython/ipython/issues/2049


To connect another client to this kernel, use:
--existing 
/tmp/guix-build-guix-jupyter-0.2.2.drv-0/guix-jupyter-kernel.U55aZ4/conn/2031766281046451459.json
test-name: run-kernel python3
location: /tmp/guix-build-guix-jupyter-0.2.2.drv-0/source/tests/kernels.scm:44
source:
+ (test-assert
+   "run-kernel python3"
+   (let ((kernel
+   (run-kernel %context %python3-specs %kernel-key)))
+ (set! %kernel kernel)
+ (and (kernel? (pk 'kernel kernel))
+  (begin
+(kill (kernel-pid kernel) 0)
+(let ((greetings (read-message %kernel 5000)))
+  (or (not greetings)
+  (list (message-type greetings)
+(kernel-status-execution-state
+  (json->kernel-status
+(message-content greetings))

;;; (kernel #< name: "Python 3 (ipykernel)" pid: 884 key: "secretkey" 
control: # shell: # stdin: # heartbeat: # iosub: # properties: ()>)
actual-value: #f
actual-error:
+ (wrong-type-arg
+   "string->symbol"
+   "Wrong type argument in position ~A (expecting ~A): ~S"
+   (1 "string" #f)
+   (#f))
result: FAIL

test-name: kernel_info_request
location: /tmp/guix-build-guix-jupyter-0.2.2.drv-0/source/tests/kernels.scm:61
source:
+ (test-equal
+   "kernel_info_request"
+   "python"
+   (let ((request
+   (message
+ (header "kernel_info_request" "luser" "12345")
+ "{}")))
+ (send-message %kernel request)
+ (let* ((replies
+  (unfold
+(cut > <> 2)
+(lambda (_) (read-message %kernel 1))
+#{1+}#
+0)))
+   (define (type-predicate type)
+ (lambda (message)
+   (string=? (message-type message) type)))
+   (and (every message? (pk 'replies replies))
+(match (filter (type-predicate "status") replies)
+   ((busy idle)
+(and (eq? 'busy
+  (kernel-status-execution-state
+(json->kernel-status (message-content busy
+ (eq? 'idle
+  (kernel-status-execution-state
+(json->kernel-status (message-content idle
+ (equal?
+   (message-parent-header busy)
+   (message-header request))
+ (equal?
+   (message-parent-header idle)
+   (message-header request)
+(let ((reply (find (type-predicate "kernel_info_reply")
+   replies)))
+  (and (equal?
+ (message-parent-header reply)
+ (message-header request))
+   (let ((reply (json->kernel-info-reply
+  (message-content reply
+ (language-info-name
+   (kernel-info-reply-language-info reply)

;;; (replies (#< header: #< id: 
"377e5f0c-c85d2027900218a7a09c8021_884_1" user: "username" session: 
"377e5f0c-c85d2027900218a7a09c8021" date: "2022-09-14T16:03:05.486528Z" type: 
"status" version: "5.3" sender: #vu8(107 101 114 110 101 108 46 97 53 55 99 49 
102 53 54 45 52 49 98 100 45 52 99 98 98 45 98 101 97 57 45 57 51 57 102 97 99 
97 56 55 55 102 52 46 115 116 97 116 117 115)> parent-header: #f metadata: "{}" 
content: "{\"execution_state\": \"starting\"}" buffers: ()> #< header: 
#< id: "377e5f0c-c85d2027900218a7a09c8021_884_2" user: "username" 
session: "377e5f0c-c85d2027900218a7a09c8021" date: 
"2022-09-14T16:03:05.505955Z" type: "status" version: "5.3" sender: #vu8(107 
101 114 110 101 108 46 97 53 55 99 49 102 53 54 45 52 49 98 100 45 52 99 98 98 
45 98 101 97 57 45 57 51 57 102 97 99 97 56 55 55 102 52 46 115 116 97 116 117 
115)> parent-header: #< id: "7b136e32ddcbe2e226edffb116a4fca9" user: 

bug#57775: guix shell --root fails

[Ricardo Wurmus]

This fails on the first try:

--8<---cut here---start->8---
$ guix shell -D -f guix.scm --root=env-test
Backtrace:
  10 (primitive-load "/home/rekado/.config/guix/current/bin/guix")
In guix/ui.scm:
   2238:7  9 (run-guix . _)
  2201:10  8 (run-guix-command _ . _)
In ice-9/boot-9.scm:
  1752:10  7 (with-exception-handler _ _ #:unwind? _ #:unwind-for-type _)
In guix/status.scm:
815:4  6 (call-with-status-report _ _)
In guix/scripts/environment.scm:
   946:13  5 (_)
In guix/store.scm:
  2168:25  4 (run-with-store #f # #:guile-for-build _ #:system _ # _)
In guix/scripts/environment.scm:
   963:16  3 (_ _)
In guix/store.scm:
  2040:38  2 (_ #f)
   1475:0  1 (add-indirect-root #f "/home/rekado/dev/pigx/pigx_bsseq/env-test")
In ice-9/boot-9.scm:
  1685:16  0 (raise-exception _ #:continuable? _)

ice-9/boot-9.scm:1685:16: In procedure raise-exception:
In procedure struct-vtable: Wrong type argument in position 1 (expecting 
struct): #f
--8<---cut here---end--->8---

On the second try it does work and links the profile to ./env-test.

-- 
Ricardo

bug#57501: call-with-file-lock does not remove lock file

[Ricardo Wurmus]

“call-with-file-lock” and “call-with-file-lock/no-wait” create a lock
file but don’t remove the lock file when they exit.

(guix build syscalls) defines these procedures with “dynamic-wind” so
that the lock is always lifted with “unlock-file”.  While “unlock-file”
uses the fcntl syscall to remove the lock on the file, the lock file
itself is not deleted.

I think it should be deleted.  When the lock file sticks around we may
run into problems due to lock file ownership.  For example, imagine a
cron job running as a different user that upgrades the contents of a
user profile.  That cron job would leave behind an unlocked lock file
owned by that user, preventing the owner of the profile from operating
on the profile even though the lock has already been lifted with
“unlock-file”.

I propose letting either unlock-file or with-profile-lock delete the
lock file.

-- 
Ricardo

bug#57210: reproducibility: r-bgx tests CPU at configure time

[Ricardo Wurmus]

Fixed with commit 593327ef5b506f031d75349fdcda1ad04e6684ed.

-- 
Ricardo

bug#57210: reproducibility: r-bgx tests CPU at configure time

[Ricardo Wurmus]

The r-bgx package tests the CPU of the build node to determine whether
to use -march options.

On my laptop it does not, but on berlin it adds -march=k8 to the
compiler options.

This is due to AX_GCC_ARCHFLAG.

-- 
Ricardo