bug#65056: https://issues.guix.gnu.org/ cannot be accessed through Tor
Ricardo Wurmus skribis: > 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? It’s just my ISP, no Tor involved. I can share privately my home IP address if that helps investigate the problem; let me know. Ludo’.
bug#66033: Package name conflict for "helm"
Hi, There seems to be a recently introduced package name conflict. There are two packages named "helm". One is is the package manager for Kubernetes and the other is a synthesizer. I noticed after upgrading and helm suddenly jumped from 0.9.0 to 3.12.3. `guix install helm@0.9.0` restores helm-lv2 as a temp fix. I suggest the latter be renamed "helm-lv2" to fix the issue. Panos
bug#66014: Unable to use UUIDs to construct RAID array in mapped-devices
Lars Rustand writes: > [[PGP Signed Part:Undecided]] > Setting up a RAID array using UUIDs does not work. > > The following mapped-devices block works: > > (mapped-devices > (list > (mapped-device > (source (list "/dev/nvme0n1p2" "/dev/nvme1n1p3")) > (target "/dev/md0") > (type raid-device-mapping > > But this one fails: > > (mapped-devices > (list > (mapped-device > (source (list (uuid "a07c54da-eb61-4135-86b8-8791e863e46a") (uuid > "c40026af-ace9-47fc-9d3f-4b8d6a2219cb"))) > (target "/dev/md0") > (type raid-device-mapping > > The error message I get is guix system: error: #< type: dce bv: > #vu8(160 124 84 218 235 97 65 53 134 184 135 145 232 99 228 106)>: invalid > G-expression input > > [[End of PGP Signed Part]] Would it be possible to use /dev/disk/by-uuid paths instead of uuid objects for these? I think this big "typeof" based dynamic dispatch that we're using in Scheme is erm, not very robust, to put it mildly.
bug#66072: Duplicate/conflicting definitions for ocl-icd
Hi.
There are currently two conflicting definitions of ocl-icd in
"opencl.scm":
--8<---cut here---start->8---
(define-public ocl-icd
(deprecated-package "ocl-icd" opencl-icd-loader))
--8<---cut here---end--->8---
and
--8<---cut here---start->8---
(define-public ocl-icd
(package
(name "ocl-icd")
(version "2.3.2")
(source
(origin
(method git-fetch)
(uri (git-reference
(url "https://github.com/OCL-dev/ocl-icd";)
(commit (string-append "v" version
(file-name (git-file-name name version))
(sha256
(base32 "0y0lnxb6zlhfb5vxxib5n1vvxa4b23qc0j3lsih6yjz9j37mj7wz"
(build-system gnu-build-system)
(native-inputs
(list autoconf automake libtool ruby))
(home-page "https://github.com/OCL-dev/ocl-icd";)
(synopsis "Generic OpenCL @acronym{ICD, Installable Client Driver} loader")
(description
"This package provides an OpenCL @acronym{ICD, Installable Client Driver}
loader. It maintains a YAML database of all known and guessed function pointers
from vendor-specific drivers. It also delivers a skeleton of bindings to
incorporate inside an OpenCL implementation to give it ICD functionalities.")
(license license:bsd-2)))
--8<---cut here---end--->8---
Which is the good one?
signature.asc
Description: PGP signature
bug#66072: Duplicate/conflicting definitions for ocl-icd
Hi, > Which is the good one? according to commit 4d1157fca7627c11672df0cd80fae4f4d27e2185 ocl-icd was dead, which is why I replaced it. I cannot tell which one is better though. Tobias maybe? Lars
bug#65809: mumi: Add msg number and subject in search results when searching for subject:
Hi Arun, Arun Isaac writes: > Sorry for my late reply. No problem: async! :-D [...] > In our case, we index entire issues as Xapian documents; we don't index > each individual email message as its own Xapian document. Ooh, I understand now! > This means that an issue is the smallest unit we can address. We > cannot address each individual email message. So, localizing a subject > to a specific email message is difficult. Yes, I see. > Maybe what you are looking for is some context in the search results to > know why that particular search result was produced. This can be done by > displaying a snippet of text from the issue with the search terms > highlighted. For a working demo of what I mean, see for example, > https://issues.genenetwork.org/search?query=database&type=all . Oooh: a live example is more than a thousand words: thanks! (I'm following Tissue but someway I missed that feature) > Notice how the search term "database" is highlighted in the search > results. This is relatively easy to do with Xapian, and indeed I do > plan to implement this at some point. OK: can we consider this bug report (wishlist) as the "official" one for that feature? :-) Can I retitle it to better reflect the upcoming implementation and assign it to you? Actually I dont' know if there is some written or unwritten convention in Guix or GNU about bug assignment, I don't want to put pressure on you! > WDYT? Would this meet your needs? Yes, absolutely yes: thank you! Happy hacking! Gio' -- Giovanni Biscuolo Xelera IT Infrastructures signature.asc Description: PGP signature
bug#66072: Duplicate/conflicting definitions for ocl-icd
Hi Lars, Guillaume, Thanks for catching the duplicate! I removed the ‘deprecated’ one in commit 71ec12d8bacd3901e8c7853d3c9403f3d09dfb31. On 2023-09-18 16:23, Lars-Dominik Braun wrote: Which is the good one? according to commit 4d1157fca7627c11672df0cd80fae4f4d27e2185 ocl-icd was dead, which is why I replaced it. It's not clear to me how opencl-icd-loader is related to ocl-icd, so I can't partake in that discussion. They look like totally different packages to me. My only motivation was to fix beignet, which was broken by the ocl-icd(.h) removal. Kind regards, T G-R Sent from a Web browser. Excuse or enjoy my brevity.
bug#65809: mumi: Add msg number and subject in search results when searching for subject:
>> Notice how the search term "database" is highlighted in the search >> results. This is relatively easy to do with Xapian, and indeed I do >> plan to implement this at some point. > > OK: can we consider this bug report (wishlist) as the "official" one for > that feature? :-) Sure! > Can I retitle it to better reflect the upcoming implementation and > assign it to you? Yes, please! > Actually I dont' know if there is some written or unwritten convention > in Guix or GNU about bug assignment, I don't want to put pressure on > you! No problem! I do intend to implement this feature at some point anyway. Even if I don't do it, it's good to list this as an issue so that someone interested can try and hack on it.
bug#65056: https://issues.guix.gnu.org available through Tor again
Hi, it seems https://issues.guix.gnu.org can again be accessed when using Tor Browser. Kind regards, Altadil
bug#66053: Childhurd fails to run inside ‘guix system vm’
Ludovic Courtès skribis: > When I run it by hand with KVM on my bare-metal GNU/Linux machine, it’s > all good: 👍 > > $ > "/gnu/store/1rg1fb9mj65rh82467vwlrkmi12p4v89-qemu-minimal-8.1.0/bin/qemu-system-i386" > "-m" 2048 "--device" "rtl8139,netdev=net0" "--netdev" > "user,id=net0,hostfwd=tcp:127.0.0.1:11004-:1004,hostfwd=tcp:127.0.0.1:10022-:,hostfwd=tcp:127.0.0.1:15900-:5900" > "--snapshot" "--hda" > "/gnu/store/iqacww23byvw9c5ssja9fkx6m4s057b0-disk-image" "--no-reboot" > --enable-kvm > VNC server running on 127.0.0.1:5900 > > > However, the same thing *without* KVM (as happens within ‘guix system > vm’) reproduces the “Bad ram pointer” issue: > > $ > "/gnu/store/1rg1fb9mj65rh82467vwlrkmi12p4v89-qemu-minimal-8.1.0/bin/qemu-system-i386" > "-m" 2048 "--device" "rtl8139,netdev=net0" "--netdev" > "user,id=net0,hostfwd=tcp:127.0.0.1:11004-:1004,hostfwd=tcp:127.0.0.1:10022-:,hostfwd=tcp:127.0.0.1:15900-:5900" > "--snapshot" "--hda" > "/gnu/store/iqacww23byvw9c5ssja9fkx6m4s057b0-disk-image" "--no-reboot" > VNC server running on 127.0.0.1:5900 > qemu-system-i386: Bad ram pointer 0x7fa930e0001e > Aborted > > > Good news: I found a workaround! Just use the x86_64 emulator: Done in 5e0ae2684615b6d10751390420e7db296785112b! Ludo’.
bug#66014: Unable to use UUIDs to construct RAID array in mapped-devices
Hi, Csepp skribis: > Lars Rustand writes: [...] >> But this one fails: >> >> (mapped-devices >> (list >> (mapped-device >> (source (list (uuid "a07c54da-eb61-4135-86b8-8791e863e46a") (uuid >> "c40026af-ace9-47fc-9d3f-4b8d6a2219cb"))) >> (target "/dev/md0") >> (type raid-device-mapping >> >> The error message I get is guix system: error: #< type: dce bv: >> #vu8(160 124 84 218 235 97 65 53 134 184 135 145 232 99 228 106)>: invalid >> G-expression input >> >> [[End of PGP Signed Part]] > > Would it be possible to use /dev/disk/by-uuid paths instead of uuid > objects for these? Depends: /dev/disk/by-uuid is populated by eudev, which is not running at the time initrd code runs; IOW it’s OK to use /dev/disk/by-uuid if and only if the mapped device is not “needed for boot”. > I think this big "typeof" based dynamic dispatch that we're using in > Scheme is erm, not very robust, to put it mildly. Yeah, it’s not great. What would you suggest? Ludo’.
bug#65720: Guile-Git-managed checkouts grow way too much
Ludovic Courtès skribis: > As reported by Tobias on IRC (in the context of ‘hpcguix-web’), > checkouts managed by Guile-Git appear to grow beyond reason. As an > example, here’s the same ‘.git’ managed with Guile-Git and with Git: > > $ du -hs > ~/.cache/guix/checkouts/pjmkglp4t7znuugeurpurzikxq3tnlaywmisyr27shj7apsnalwq > 6.7G > /home/ludo/.cache/guix/checkouts/pjmkglp4t7znuugeurpurzikxq3tnlaywmisyr27shj7apsnalwq > $ du -hs .git > 517M.git More data… The biggest file in that repo is a pack that was created when that repo was first cloned (Aug. 2021): --8<---cut here---start->8--- $ du /home/ludo/.cache/guix/checkouts/pjmkglp4t7znuugeurpurzikxq3tnlaywmisyr27shj7apsnalwq/.git/objects/pack/* |sort -k1 -n| tail -3 44272 /home/ludo/.cache/guix/checkouts/pjmkglp4t7znuugeurpurzikxq3tnlaywmisyr27shj7apsnalwq/.git/objects/pack/pack-3c2f1857501b01c321bc67ba1f30704deb9e18e9.pack 47272 /home/ludo/.cache/guix/checkouts/pjmkglp4t7znuugeurpurzikxq3tnlaywmisyr27shj7apsnalwq/.git/objects/pack/pack-30d5b35ad14a8398464e49e224811b162f673d66.pack 191492 /home/ludo/.cache/guix/checkouts/pjmkglp4t7znuugeurpurzikxq3tnlaywmisyr27shj7apsnalwq/.git/objects/pack/pack-d39507858782209d1ad87e389e4dffd4b6ff7ea2.pack $ ls -l /home/ludo/.cache/guix/checkouts/pjmkglp4t7znuugeurpurzikxq3tnlaywmisyr27shj7apsnalwq/.git/objects/pack/pack-d39507858782209d1ad87e389e4dffd4b6ff7ea2.pack -r--r--r-- 1 ludo users 196079671 Aug 9 2021 /home/ludo/.cache/guix/checkouts/pjmkglp4t7znuugeurpurzikxq3tnlaywmisyr27shj7apsnalwq/.git/objects/pack/pack-d39507858782209d1ad87e389e4dffd4b6ff7ea2.pack $ ls -ld /home/ludo/.cache/guix/checkouts/pjmkglp4t7znuugeurpurzikxq3tnlaywmisyr27shj7apsnalwq/.git/config -rw-r--r-- 1 ludo users 266 Aug 9 2021 /home/ludo/.cache/guix/checkouts/pjmkglp4t7znuugeurpurzikxq3tnlaywmisyr27shj7apsnalwq/.git/config --8<---cut here---end--->8--- The pack starts with things from Aug. 2021: --8<---cut here---start->8--- $ git show-index < pack-d39507858782209d1ad87e389e4dffd4b6ff7ea2.idx|sort -k1 -n|head -3 12 30289f4d4638452520f52c1a36240220d0d940ff (852d8cb3) 927 d7ffc535c52f49177a8e5553569cdb1e321b5bc6 (2007c5d0) 1800 0a379de3249d5e9ff66fb404f7e5aa8ce2cb3d24 (b1e69aa4) $ git show 30289f4d4638452520f52c1a36240220d0d940ff commit 30289f4d4638452520f52c1a36240220d0d940ff Author: Milkey Mouse Date: Sun Aug 8 22:15:40 2021 -0700 […] --8<---cut here---end--->8--- … and at the bottom (large offsets) it contains very old blogs from the Nix repo that somehow made it here. I figured we still had a ‘nix’ branch from the early days, that contains the history of Nix. I’ve now removed it, which helps a bit: --8<---cut here---start->8--- scheme@(guile-user)> ,use(git) scheme@(guile-user)> ,t (clone "https://git.savannah.gnu.org/git/guix.git"; "/tmp/guix") $5 = # ;; 600.534529s real time, 435.260926s run time. 0.00s spent in GC. scheme@(guile-user)> ,t (clone "https://git.savannah.gnu.org/git/guix.git"; "/tmp/guix-after-removing-nix-branch") $6 = # ;; 420.321511s real time, 398.772963s run time. 0.00s spent in GC. --8<---cut here---end--->8--- … and more importantly: --8<---cut here---start->8--- $ du -hs /tmp/guix/.git 373M/tmp/guix/.git $ du -hs /tmp/guix-after-removing-nix-branch/.git 362M/tmp/guix-after-removing-nix-branch/.git --8<---cut here---end--->8--- Anyway, what seems to happen is that every pull (every call to ‘remote-fetch’) creates a new pack (see ‘git_fetch_download_pack’ in libgit2), which becomes inefficient in the long run (lots of small poorly-compressed packs). That’s at least one possible explanation. To be continued… Ludo’.
bug#66097: New test "rewrite-url, without to-version" needs network
Hi Maxim,
As mentioned on IRC, the recently-added "rewrite-url, without
to-version" test needs not only nss-certs installed, as I found when
building it for the Hurd. New we also found it to fail in a container
without network access. That means a guix package build (in a
container) now fails.
After I updated the guix version to 1.4.0-11.658de25e99 yesterday
morning to (finally) get `guix pull' to work on the Hurd, several people
reported failure to reconfigure on IRC.
This
guix shell -CD guix
export SCM_LOG_DRIVER_FLAGS="--select=^rewrite-url, without to-version"
make check TESTS=tests/gnu-maintenance.scm
gives
--8<---cut here---start->8---
test-name: rewrite-url, without to-version
[..]
expected-value: "https://dist.libuv.org/dist/v1.46.0/libuv-v1.46.0.tar.gz";
actual-value: #f
actual-error:
+ (getaddrinfo-error -8)
result: FAIL
--8<---cut here---end--->8---
When changing the code like this
--8<---cut here---start->8---
-(test-equal "rewrite-url, without to-version"
+(pk "rewrite-url, without to-version"
"https://dist.libuv.org/dist/v1.46.0/libuv-v1.46.0.tar.gz";
- (with-http-server
+ "=>"(with-http-server
--8<---cut here---end--->8---
to create a backtrace, I get
--8<---cut here---start->8---
Backtrace:
15 (primitive-load-path "tests/gnu-maintenance.scm")
In ice-9/eval.scm:
214:21 14 (_ #f)
217:33 13 (lp (#))
In guix/tests/http.scm:
174:8 12 (call-with-http-server _ _)
In guix/gnu-maintenance.scm:
568:6 11 (rewrite-url _ "1.45.0" #:to-version _)
In srfi/srfi-1.scm:
460:18 10 (fold # ?)
In guix/gnu-maintenance.scm:
500:16 9 (_ _ ("dist" "dist.libuv.org" "" "https:"))
In ice-9/exceptions.scm:
406:15 8 (update-cache _)
In ice-9/boot-9.scm:
1752:10 7 (with-exception-handler _ _ #:unwind? _ # _)
In guix/http-client.scm:
340:20 6 (_)
107:28 5 (http-fetch _ #:port _ #:text? _ #:buffered? _ # _ # _ # ?)
In guix/build/download.scm:
468:4 4 (open-connection-for-uri _ #:timeout _ # _)
469:14 3 (thunk)
396:8 2 (open-socket-for-uri _ #:timeout _)
In unknown file:
1 (getaddrinfo "dist.libuv.org" "https" 32 # # #)
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 getaddrinfo: Servname not supported for ai_socktype
--8<---cut here---end--->8---
Greetings,
Janneke
PS: Without nss-certs installed, which was the usual case in a childhurd
until yesterday, I got
--8<---cut here---start->8---
+ (tls-certificate-error
+ invalid-certificate
+ #
+ "dist.libuv.org"
+ (#
+#))
--8<---cut here---end--->8---
backtrace:
--8<---cut here---start->8---
Backtrace:
11 (primitive-load-path "tests/gnu-maintenance.scm")
In guix/tests/http.scm:
174:8 10 (call-with-http-server _ _)
In guix/gnu-maintenance.scm:
568:6 9 (rewrite-url _ "1.45.0" #:to-version _)
In srfi/srfi-1.scm:
460:18 8 (fold # _ _)
In guix/gnu-maintenance.scm:
500:16 7 (_ _ ("dist" "dist.libuv.org" "" "https:"))
In ice-9/exceptions.scm:
406:15 6 (update-cache _)
In ice-9/boot-9.scm:
1752:10 5 (with-exception-handler _ _ #:unwind? _ #:unwind-for-type _)
In guix/http-client.scm:
340:20 4 (_)
107:28 3 (http-fetch _ #:port _ #:text? _ #:buffered? _ #:open-connection _
# _ # _ # _ ?)
In guix/build/download.scm:
468:4 2 (open-connection-for-uri _ #:timeout _ #:verify-certificate? _)
360:6 1 (tls-wrap # _ #:verify-certificate? _)
In ice-9/boot-9.scm:
1685:16 0 (raise-exception _ #:continuable? _)
ice-9/boot-9.scm:1685:16: In procedure raise-exception:
X.509 certificate of 'dist.libuv.org' could not be verified:
signer-not-found
invalid
--8<---cut here---end--->8---
--
Janneke Nieuwenhuizen | GNU LilyPond https://LilyPond.org
Freelance IT https://www.JoyOfSource.com | Avatar® https://AvatarAcademy.com
