bug#66207: Cannot boot any recent VM built with “guix system image -t qcow2”
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#66207: Cannot boot any recent VM built with “guix system image -t qcow2”
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#63986: Julia is very slow
On Mon, Sep 25, 2023 at 04:46:57PM +0200, Ludovic Courtès wrote: > Hi, > > Simon Tournier skribis: > > > It is almost good except one strong annoyance [1]@ > > > > Singular value decomposition | 57 57 5.0s > > Hermitian: Error During Test at > > /gnu/store/zkx6p7kz3m5k5w5iy0l1d09b2n8b0ib3-julia-genericlinearalgebra-0.2.5/share/julia/loadpath/GenericLinearAlgebra/test/rectfullpacked.jl:12 > > Got exception outside of a @test > > could not load symbol "dsfrk_64_": > > > > /gnu/store/h5mgc7ar7a05f9rwrd1makhzays5wd3s-julia-1.8.3/bin/../lib/julia/liblapack.so: > > undefined symbol: dsfrk_64_ > > The ‘_64’ suffix is added by a patch in this very series, that adds > ‘SYMBOLSUFFIX=64_’ to ‘openblas-ilp64’. > > I don’t know what the rationale was for that configuration change, but > this is a good area of investigation. > > Efraim, WDYT? the SYMBOLSUFFIX change seems to be standard across other distributions, and in fact there seem to be packages out there which rely on it directly. Looking at this error specifically and also the pcre2-8 errors we get during the 'test phase for julia, it seems the suggested fix is to build those libraries with julia. So we'd want to replace the pcre2 and the lapack libraries in the julia sources (for pcre2 for all the architectures, for lapack for x86_64 specifically) and let julia build and link to them during the build phase. -- Efraim Flashner רנשלפ םירפא GPG key = A28B F40C 3E55 1372 662D 14F7 41AA E7DC CA3D 8351 Confidentiality cannot be guaranteed on emails sent or received unencrypted signature.asc Description: PGP signature
bug#52002: Fwd: missing $GUIX_PROFILE/share/emacs/site-lisp in EMACSLOADPATH
This happens when I remove emacs from the default profile `guix remove emacs` and install it via `guix home ...`. IOW the bug is not that $GUIX_PROFILE/share/emacs/site-lisp is missing in EMACSLOADPATH, but that "$HOME/.guix-profile/share/emacs/site-lisp" is in the load-path even if emacs is not installed in the default profile. Cheers Bost
bug#57134: [PATCH] powerpc64le: gst-plugins-good build link error on aalib (libgstaasink.so)
close 57134 quit This is fixed with https://git.savannah.gnu.org/cgit/guix.git/commit/?id=fafd3caef0d51811a5da81d6061789e2908b0dac See: https://issues.guix.gnu.org/65646
bug#65979: incorrect “guix hash” for FastQC
Hi,
On Thu, 14 Sep 2023 at 18:46, Simon Tournier wrote:
> $ guix hash -rx $(guix build
> /gnu/store/8gxx74w8pa0fx74lx1ka654rhyyr51cs-fastqc-0.11.9-checkout.drv)
> 0jyk90kg6s62w3dn6qjx9nrawjs12qx172lii0yxbvsfylhnx479
>
> Oh, it is not the expected result! Instead, I have to omit the option
> ’-x’:
>
> $ guix hash -r $(guix build
> /gnu/store/8gxx74w8pa0fx74lx1ka654rhyyr51cs-fastqc-0.11.9-checkout.drv)
> 00y9drm0bkpxw8xfl8ysss18jmnhj8blgqgr6fpa58rkpfcbg8qk
[...]
> $ git clone https://github.com/s-andrews/FastQC
> $ git -C FastQC checkout v0.11.9
> $ guix hash -rx FastQC
> 0jyk90kg6s62w3dn6qjx9nrawjs12qx172lii0yxbvsfylhnx479
[...]
> $ mv FastQC/.git bye-bye
> $ guix hash -r FastQC
> 00y9drm0bkpxw8xfl8ysss18jmnhj8blgqgr6fpa58rkpfcbg8qk
[...]
> Any idea?
The issue is from .svn folders.
--8<---cut here---start->8---
$ find $(guix build
/gnu/store/8gxx74w8pa0fx74lx1ka654rhyyr51cs-fastqc-0.11.9-checkout.drv) \
-type d -name ".svn" -print
/gnu/store/5dyvjgylwiixhp8z9a08rnddh53h4cdx-fastqc-0.11.9-checkout/Help/1
Introduction/.svn
/gnu/store/5dyvjgylwiixhp8z9a08rnddh53h4cdx-fastqc-0.11.9-checkout/Help/3
Analysis Modules/.svn
/gnu/store/5dyvjgylwiixhp8z9a08rnddh53h4cdx-fastqc-0.11.9-checkout/Help/2 Basic
Operations/.svn
--8<---cut here---end--->8---
The option ’-x’ excludes them; see vcs-file? from (guix hash) module,
and let confirm:
$ git clone https://github.com/s-andrews/FastQC
$ git -C FastQC checkout v0.11.9
$ guix hash -rx FastQC
0jyk90kg6s62w3dn6qjx9nrawjs12qx172lii0yxbvsfylhnx479
$ find FastQC -type d -name ".svn" -exec rm -r "{}" \;
$ mv FastQC/.git bye-bye
$ guix hash -r FastQC
0jyk90kg6s62w3dn6qjx9nrawjs12qx172lii0yxbvsfylhnx479
Therefore, we have a discrepancy between “guix hash” command-line and
checksum verification from ’source’ field.
The package definition reads:
(source
(origin
(method git-fetch)
(uri (git-reference
(url "https://github.com/s-andrews/FastQC";)
(commit (string-append "v" version
(file-name (git-file-name name version))
(sha256
(base32
"00y9drm0bkpxw8xfl8ysss18jmnhj8blgqgr6fpa58rkpfcbg8qk"))
when this hash contains .svn subfolders that are excluded by ’-x’
command-line option.
What do we fix? The procedure vcs-file? or fixed-output computation?
Cheers,
simon
bug#65979: incorrect “guix hash” for FastQC
Hi! Simon Tournier skribis: > Let pick the correct one and I get: > > $ guix hash -rx $(guix build > /gnu/store/8gxx74w8pa0fx74lx1ka654rhyyr51cs-fastqc-0.11.9-checkout.drv) > 0jyk90kg6s62w3dn6qjx9nrawjs12qx172lii0yxbvsfylhnx479 > > > Oh, it is not the expected result! Instead, I have to omit the option > ’-x’: > > $ guix hash -r $(guix build > /gnu/store/8gxx74w8pa0fx74lx1ka654rhyyr51cs-fastqc-0.11.9-checkout.drv) > 00y9drm0bkpxw8xfl8ysss18jmnhj8blgqgr6fpa58rkpfcbg8qk This is because: --8<---cut here---start->8--- $ find $( guix build /gnu/store/8gxx74w8pa0fx74lx1ka654rhyyr51cs-fastqc-0.11.9-checkout.drv) -name .svn /gnu/store/5dyvjgylwiixhp8z9a08rnddh53h4cdx-fastqc-0.11.9-checkout/Help/3 Analysis Modules/.svn /gnu/store/5dyvjgylwiixhp8z9a08rnddh53h4cdx-fastqc-0.11.9-checkout/Help/1 Introduction/.svn /gnu/store/5dyvjgylwiixhp8z9a08rnddh53h4cdx-fastqc-0.11.9-checkout/Help/2 Basic Operations/.svn --8<---cut here---end--->8--- Not a bug, IMO (‘vcs-file?’ shouldn’t try to be smart in this case.) Ludo’.
bug#65979: incorrect “guix hash” for FastQC
(Oops, now I see you had already found the reason.) Simon Tournier skribis: > What do we fix? The procedure vcs-file? or fixed-output computation? There are two things are: 1. ‘vcs-file?’, used by ‘guix hash -rx’; 2. ‘git-fetch’, which does (delete-file-recursively ".git"). Clearly #2 is correct (it’s perfectly fine to have a ‘.svn’ directory in a Git repo), whereas #1 is an approximation that, in corner cases like this one, gives the wrong answer. My take is that it’s OK to keep ‘vcs-file?’ as is: the best we could do would be to add complicated heuristics in the hope corner cases like this one would be better dealt with, but it wouldn’t be bullet-proof anyway. WDYT? Ludo’.
bug#65979: incorrect “guix hash” for FastQC
Hi, On Tue, 26 Sept 2023 at 15:34, Ludovic Courtès wrote: > There are two things are: > > 1. ‘vcs-file?’, used by ‘guix hash -rx’; > > 2. ‘git-fetch’, which does (delete-file-recursively ".git"). Yes. > Clearly #2 is correct (it’s perfectly fine to have a ‘.svn’ directory in > a Git repo), whereas #1 is an approximation that, in corner cases like > this one, gives the wrong answer. These corner cases matter for some SWH loader implementing Nar hashes in Python. Since they load sources.json (conversion of hash checksum from package recipe), read the Nar hash and compare it with the one they internal compute, then they need to implement in Python the correct behavior. See https://gitlab.softwareheritage.org/swh/devel/swh-loader-git/-/issues/4751#note_149180 and all the thread for context. > My take is that it’s OK to keep ‘vcs-file?’ as is: the best we could do > would be to add complicated heuristics in the hope corner cases like > this one would be better dealt with, but it wouldn’t be bullet-proof > anyway. Well, the question is what other VCS as 'svn-fetch', etc. are doing? Maybe, we can just have a special case for Git repository. Somehow, since the problem needs to be solved for SWH, the same solution applies for vcs-file? and "guix hash", no? Cheers, simon
bug#66169: guix reconfigure error no match for id 4f35ff1275e05be31f5d41464ccf147e9dbfd016
On 9/24/23 5:22 AM, Guillaume Le Vaillant wrote: Liliana Marie Prikler skribis: Am Sonntag, dem 24.09.2023 um 08:49 + schrieb Guillaume Le Vaillant: Liliana Marie Prikler skribis: Am Samstag, dem 23.09.2023 um 22:02 +0300 schrieb Roman Riabenko: I am trying to upgrade my guix systems. I ran guix pull and now I am trying to run guix system reconfigure. It failed on two different machines with the same backtrace. Please see the full backtrace attached. The error message from it: ice-9/boot-9.scm:1685:16: In procedure raise-exception: Git error: object not found - no match for id (4f35ff1275e05be31f5d41464ccf147e9dbfd016) $ guix describe Generation 28 Sep 23 2023 19:30:36(current) guix 4f35ff1 repository URL: https://git.savannah.gnu.org/git/guix.git branch: master commit: 4f35ff1275e05be31f5d41464ccf147e9dbfd016 Considering that I experience it on two guix machines with different system configurations, I assume that there is some bug somewhere. Experiencing the same for commit 35fd25af9bbcce84908101a9f487ba106a8d6df7. I would hazard a guess that it's due to them being merge commits. Interestingly, allow-downgrades does not have an effect on this message. Cheers I reconfigured two machines using commit 4f35ff1275e05be31f5d41464ccf147e9dbfd016, and it succeeded on both machines, I didn't get this "no match for id" issue. That's strange... Do you have provenance tracking on your machines (the default)? Yes. I use an additional channel, not only the "guix" default channel. Maybe that makes a difference... Also reporting similar issues on a Guix machine with multiple channels. In my case, I have a local 'file://...' channel that I use for development, and have found that the following sequence of actions will consistently exhibit the above behavior on guix master: 1. Commit update to local channel git 2. guix pull 3. sudo guix system reconfigure The issue is resolved by removal of the root user's guix cache in /root/.cache/guix (forcing a full fetch during system reconfigure), but repeating the above steps will cause the issue to reoccur. I suspect it might have to do with the recent changes made to the 'reference-available?' function in 6d33c1f8061e86d63ab5c9ec75df9c58130c7264 (though it's not entirely clear why that change would cause this failure). After downgrading my "guix" channel to f45c0c82289d409b4fac00464ea8b323839ba53f (the commit immediately prior to the above change) I am again able to receive changes from my local channel without issue.
bug#66205: GuixSD on powerpc64le
I'm currently working on building Guix System for powerpc64le, and I've
encountered a few issues that I could use some assistance with.
Firstly, linux-initrd failing because gcc-7.5 package used for
bootstrap-glibc do not support --with-long-double-128. Removing this works
just fine -- with last gcc package:
> /gnu/packages/make-bootstrap.scm
> (native-inputs
> `(("gcc" ,gcc-7.5)
> ,@(package-native-inputs base)))
I'm curious why gcc-7.5 was built without --with-long-double-128,
especially considering it's defined for powerpc64le-linux in
/gnu/packages/gcc.scm under (gcc-configure-flags-for-triplet).
Furthermore, I've encountered issues with Grub, which are detailed in this
issue: https://issues.guix.gnu.org/54407. I believe that porting
gcc-12-multilib from Debian could potentially resolve this problem.
Lastly, any image generated from (system-disk-image) depends on
grub-efi{,32}, but (a) grub-efi build fails on ppc*, and (b) ppc* systems
do not use EFI.
The remaining problems mostly involve software patching or minor code
adjustments.
Best regards,
Mykhailo Chernysh
iskrim...@gmail.com
bug#65847: I think it's running
Your container is running. Try to reach it, via: sudo nsenter -a -t sh
bug#66131: Follow up regarding 'installer-dump-8e0c3401'.
Just wanted to provide some more details on this crash in case it helps. I'm attempting to install Guix on an Asus EeePC 1000HE, its only modification is having been upgraded to a whopping 2GB of RAM. It's an old relic, but it still runs, so I'd like to save it from the landfill and use it as a machine for learning, practicing and immersing in Lisp. Aside from the logs I've uploaded, I also took a couple of photographs. One of them shows the part where the installer hangs for a little over 15 minutes, the other one shows the output after the installation crashes. With your permission, I will attach them in another message. I have no previous experience with Guix, but I have been using other Linux distributions for a little over fifteen years (Ubuntu, Slackware, Gentoo, NixOS, many others), and I am good at following instructions if there's anything you need me to test for you. Thank you for any help you can offer! -- Bradley Ansell signature.asc Description: PGP signature
bug#66220: VM root file system has no label
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#65881: FSDG violation in alex4
Thanks. Removed in commit 15fdeaeb2d4df755811db92cc7c3c7cb19155dec. Kind regards, T G-R Sent from a Web browser. Excuse or enjoy my brevity.
