Re: How to use guix hash --serializer?
Hi Timothy, On Tue, 04 Jan 2022 at 20:44, Timothy Sample wrote: > Done! The commit is 8646f1f7a53d28f305f30420ad23b670159c53a9. Cool, thanks! Cheers, simon
Re: How to use guix hash --serializer?
Hi zimoun, zimoun writes: > Feel free to adjust with your commit name and push. :-) Done! The commit is 8646f1f7a53d28f305f30420ad23b670159c53a9. -- Tim
Re: Aarch64 build of rust-1.39.0 fails
Hi Denis, Denis 'GNUtoo' Carikli writes: [...] > With both Guix system i686 and Parabola i686 (with linux-libre-pae) > htop sees 8GiB of RAM on my laptop[1], and I've also 9G of swap > available, and I can probably make it run builds the night, so I'll try > to get that built on my laptop and report here and/or on IRC. Actually I'm not sure I understand where the limits comes from; it seems when using 32 bits there's a 2 GB limit somewhere: https://github.com/thepowersgang/mrustc/issues/78#issuecomment-980830551 Note that you'll want to use the latest commit available of mrustc, or something recent enough like this in (gnu packages rust) as it includes recent fixes to the (still failing) i686 build: --8<---cut here---start->8--- ;;; Note: mrustc's only purpose is to be able to bootstap Rust; it's designed ;;; to be used in source form. The latest support for bootstrapping from ;;; 1.39.0 is not yet released so use the latest commit (see: ;;; https://github.com/thepowersgang/mrustc/issues/185). (define %mrustc-commit "c7066542f8e93d320323749216bf3c82aecb67c2") (define %mrustc-source (let* ((version "0.9") (commit %mrustc-commit) (revision "1") (name "mrustc")) (origin (method git-fetch) (uri (git-reference (url "https://github.com/thepowersgang/mrustc;) (commit commit))) (file-name (git-file-name name (git-version version revision commit))) (sha256 (base32 "0zv1x6601s5fnnkcdlqkc4bknisqz569qb0iyb9rjsmaf1kh0na3") --8<---cut here---end--->8--- HTH, Maxim
Re: How to use guix hash --serializer?
Thanks Tobias. I guess my thinking is that if you have a command line switch like -x that "excludes version control system directories" it could also exclude empty directories. Mortimer On Tue, Jan 4, 2022 at 4:07 PM zimoun wrote: > Hi, > > On Tue, 04 Jan 2022 at 15:44, Mortimer Cladwell > wrote: > > > looks like the difference, other than make/git related files are four > empty > > directories doc, scripts, shinyln and tests, so appears empty directories > > are not allowed? > > “guix hash” hashes all the bytes, not only the bytes tracked by Git. > > > > mbc@HP8300:~/projects/shinyln$ git --no-pager log -1 --oneline > > git status > > 9f06568 (HEAD -> master, origin/master) removed chmod statement > > On branch master > > Your branch is up to date with 'origin/master'. > > > > nothing to commit, working tree clean > > Oh, empty directories is not shown by “git status” and no option to > display them, if I read correctly. Ah, I did not known. > > Cheers, > simon >
Re: How to use guix hash --serializer?
Hi, On Tue, 04 Jan 2022 at 15:44, Mortimer Cladwell wrote: > looks like the difference, other than make/git related files are four empty > directories doc, scripts, shinyln and tests, so appears empty directories > are not allowed? “guix hash” hashes all the bytes, not only the bytes tracked by Git. > mbc@HP8300:~/projects/shinyln$ git --no-pager log -1 --oneline > git status > 9f06568 (HEAD -> master, origin/master) removed chmod statement > On branch master > Your branch is up to date with 'origin/master'. > > nothing to commit, working tree clean Oh, empty directories is not shown by “git status” and no option to display them, if I read correctly. Ah, I did not known. Cheers, simon
Re: How to use guix hash --serializer?
Martimer, Mortimer Cladwell 写道： looks like the difference, other than make/git related files are four empty directories doc, scripts, shinyln and tests, so appears empty directories are not allowed? They are allowed but they change the hash, just as any other difference would. Missing or extraneous directories are no less meaningful than files or permissions, etc., and can easily cause the build to fail (‘cd: blah: No such file or directory’, ‘mkdir: cannot create foo: File exists’) or otherwise behave very differently. Kind regards, T G-R signature.asc Description: PGP signature
Re: How to use guix hash --serializer?
Hi Timothy, On Tue, 04 Jan 2022 at 14:09, Timothy Sample wrote: > I’m pretty sure it’s a bug. Fortunately, with Disarchive 0.4.0, the > following (untested) patch should fix it: Yep! The tests require a minor adjustment adjusted too. See attached patch. Feel free to adjust with your commit name and push. :-) (I do not have commit rights.) Cheers, simon >From 6cc3b3b93912041112570d840f86f8c52467d316 Mon Sep 17 00:00:00 2001 From: zimoun Date: Tue, 4 Jan 2022 21:47:15 +0100 Subject: [PATCH] guix hash: Allow '--exclude-vcs' option using 'git' serializer. * guix/scripts/hash.scm (git-hash): Use '#:select?' with 'git-hash-directory'. * tests/guix-hash.sh: Adjust accordingly. --- guix/scripts/hash.scm | 2 +- tests/guix-hash.sh| 3 ++- 2 files changed, 3 insertions(+), 2 deletions(-) diff --git a/guix/scripts/hash.scm b/guix/scripts/hash.scm index d73e3d13dd..c44a4de9a4 100644 --- a/guix/scripts/hash.scm +++ b/guix/scripts/hash.scm @@ -69,7 +69,7 @@ (define directory? ((directory) #t) (else #f))) (if directory? - (git-hash-directory file algorithm) + (git-hash-directory file algorithm #:select? select?) (git-hash-file file algorithm))) diff --git a/tests/guix-hash.sh b/tests/guix-hash.sh index 854c493514..8b03c7985d 100644 --- a/tests/guix-hash.sh +++ b/tests/guix-hash.sh @@ -53,6 +53,7 @@ mkdir "$tmpdir/subdir" test `guix hash -S nar "$tmpdir"` = 10k1lw41wyrjf9mxydi0is5nkpynlsvgslinics4ppir13g7d74p test `guix hash -S nar "$tmpdir" -H sha512` = 301ra58c2vahczzxiyfin41mpyb0ljh4dh9zn3ijvwviaw1j40sfzw5skh9x945da88n3785ggifzig7acd6k72h0mpsc20m1f66m9n +test `guix hash -S git "$tmpdir"` = 1m9yxz99g7askm88h6hzyv4g2bfv57rp5wvwp3iq5ypsplq1xkkk test `guix hash -S git "$tmpdir" -H sha512` = 158b10d1bsdk4pm8ym9cg9ckfak1b0cgpw7365cl6s341ir380mh2f4ylicyh8khyrfnwq5cn9766d7m8fbfwwl94ndkv456v6a8knr # Deprecated --recursive option @@ -76,7 +77,7 @@ test `guix hash -S git $tmpdir` = 0ghlpca9xaswa1ay1g55dknwd9q899mi3ahfr43pq083v8 # ...but remains the same when using `-x' test `guix hash -S nar $tmpdir -x` = 10k1lw41wyrjf9mxydi0is5nkpynlsvgslinics4ppir13g7d74p -test `guix hash -S git $tmpdir -x` = 0ghlpca9xaswa1ay1g55dknwd9q899mi3ahfr43pq083v8wisjc7 +test `guix hash -S git $tmpdir -x` = 1m9yxz99g7askm88h6hzyv4g2bfv57rp5wvwp3iq5ypsplq1xkkk # Without '-r', this should fail. ! guix hash "$tmpdir" base-commit: 4c812db049d5c9f2c438748e180f9486ad221b0a -- 2.32.0
Re: How to use guix hash --serializer?
Thanks Tobias you are correct. My project is ~/projects/shinyln I repeat your suggestion of cloning a second copy into ~temp/shinyln, cd, git reset etc. I then compare the contents of the two 'clone' directories, see below looks like the difference, other than make/git related files are four empty directories doc, scripts, shinyln and tests, so appears empty directories are not allowed? Hi Simon, mbc@HP8300:~/projects/shinyln$ git --no-pager log -1 --oneline git status 9f06568 (HEAD -> master, origin/master) removed chmod statement On branch master Your branch is up to date with 'origin/master'. nothing to commit, working tree clean - Thanks! = output of find /home/mbc/projects/shinyln -type d -printf "%P\n" | sort > file1 find /home/mbc/temp/shinyln -type d -printf "%P\n" | sort | diff - file1 mbc@HP8300:~/temp$ cat file1 autom4te.cache build-aux doc .git .git/branches .git/hooks .git/info .git/logs .git/logs/refs .git/logs/refs/heads .git/logs/refs/remotes .git/logs/refs/remotes/origin .git/objects .git/objects/02 .git/objects/07 .git/objects/09 .git/objects/0a .git/objects/0c .git/objects/0d .git/objects/10 .git/objects/12 .git/objects/15 .git/objects/17 .git/objects/18 .git/objects/1a .git/objects/1e .git/objects/20 .git/objects/23 .git/objects/26 .git/objects/29 .git/objects/2e .git/objects/31 .git/objects/32 .git/objects/36 .git/objects/3e .git/objects/40 .git/objects/48 .git/objects/4c .git/objects/66 .git/objects/68 .git/objects/69 .git/objects/6d .git/objects/72 .git/objects/75 .git/objects/76 .git/objects/7f .git/objects/81 .git/objects/82 .git/objects/84 .git/objects/85 .git/objects/89 .git/objects/8b .git/objects/8d .git/objects/9b .git/objects/9e .git/objects/9f .git/objects/a1 .git/objects/a3 .git/objects/a4 .git/objects/aa .git/objects/b0 .git/objects/b5 .git/objects/b7 .git/objects/ba .git/objects/bc .git/objects/c8 .git/objects/ce .git/objects/d3 .git/objects/d4 .git/objects/d6 .git/objects/d8 .git/objects/d9 .git/objects/df .git/objects/e6 .git/objects/e9 .git/objects/ea .git/objects/f2 .git/objects/ff .git/objects/info .git/objects/pack .git/refs .git/refs/heads .git/refs/remotes .git/refs/remotes/origin .git/refs/tags scripts shinyln tests On Tue, Jan 4, 2022 at 3:21 PM zimoun wrote: > Hi Mortimer, > > On Tue, 04 Jan 2022 at 14:48, Mortimer Cladwell > wrote: > > > mbc@HP8300:~/projects$ cd shinyln/ > > mbc@HP8300:~/projects/shinyln$ guix hash -S nar -x . > > 1ykbpz6pqx0bkvfp3c60qfb9r0xvpmrs0ldlxm2qw0zd8f67lmaj > > Could you report: > > git --no-pager log -1 --oneline > git status > > ? > > > FYI from > https://guix.gnu.org/manual/en/html_node/Invoking-guix-hash.html > > at the bottom explaining --exclude-vcs: > > > > $ git clone http://example.org/foo.git > > $ cd foo > > $ guix hash -rx . > > > > Suggests (to me) that you go inside the directory to calculate hash, > > though as above seems not to matter. > > Yes, indeed. I tried outside without fulling checking. :-) > > > Cheers, > simon >
Re: How to use guix hash --serializer?
Hi Mortimer, On Tue, 04 Jan 2022 at 14:48, Mortimer Cladwell wrote: > mbc@HP8300:~/projects$ cd shinyln/ > mbc@HP8300:~/projects/shinyln$ guix hash -S nar -x . > 1ykbpz6pqx0bkvfp3c60qfb9r0xvpmrs0ldlxm2qw0zd8f67lmaj Could you report: git --no-pager log -1 --oneline git status ? > FYI from https://guix.gnu.org/manual/en/html_node/Invoking-guix-hash.html > at the bottom explaining --exclude-vcs: > > $ git clone http://example.org/foo.git > $ cd foo > $ guix hash -rx . > > Suggests (to me) that you go inside the directory to calculate hash, > though as above seems not to matter. Yes, indeed. I tried outside without fulling checking. :-) Cheers, simon
Re: How to use guix hash --serializer?
Hi Mortimer, This is no bug: expected hash: 1ykbpz6pqx0bkvfp3c60qfb9r0xvpmrs0ldlxm2qw0zd8f67lmaj actual hash: 10nfjllq28jrzxd4dfqm6xzx8f2g1m6p2vivzihxc7d3ac1imnk2 It really means you're not hashing what you think you're hashing and it won't matter which arguments you give ‘guix hash’: garbage in, garbage out :-) You probably have untracked files laying around. Reset your local checkout, or start again: /tmp λ git clone git://github.com/mbcladwell/shinyln.git Cloning into 'shinyln'... remote: Enumerating objects: 74, done. remote: Counting objects: 100% (74/74), done. remote: Compressing objects: 100% (48/48), done. remote: Total 74 (delta 34), reused 59 (delta 19), pack-reused 0 Receiving objects: 100% (74/74), 34.75 KiB | 444.00 KiB/s, done. Resolving deltas: 100% (34/34), done. /tmp λ cd shinyln /tmp/shinyln master λ git reset --hard 9f06568ffa61953ab48c93e1623d88b4e672af42 HEAD is now at 9f06568 removed chmod statement /tmp/shinyln master λ guix hash -S nar -x . 10nfjllq28jrzxd4dfqm6xzx8f2g1m6p2vivzihxc7d3ac1imnk2 The ‘-S git’ bug you found does not affect this. Kind regards, T G-R signature.asc Description: PGP signature
Re: How to use guix hash --serializer?
So I am seeing the result for guix hash -S . which is wrong, but when the bug is fixed I will get the results for guix hash -S -x . Is that what you are implying? Thanks Mortimer On Tue, Jan 4, 2022 at 2:48 PM Mortimer Cladwell wrote: > Thanks Tim, Simon, but that does not work for me. > > nar== > mbc@HP8300:~/projects$ guix hash -S nar -x ./shinyln > 1ykbpz6pqx0bkvfp3c60qfb9r0xvpmrs0ldlxm2qw0zd8f67lmaj > mbc@HP8300:~/projects$ cd shinyln/ > mbc@HP8300:~/projects/shinyln$ guix hash -S nar -x . > 1ykbpz6pqx0bkvfp3c60qfb9r0xvpmrs0ldlxm2qw0zd8f67lmaj > > git== > mbc@HP8300:~/projects/shinyln$ guix hash -S git -x . > 0lai57r0p11q041b3flriv56j6n8lizwb69yv7j396yiivkspv3x > mbc@HP8300:~/projects/shinyln$ cd .. > mbc@HP8300:~/projects$ guix hash -S git -x ./shinyln > 0lai57r0p11q041b3flriv56j6n8lizwb69yv7j396yiivkspv3x > > error during packaging= > building /gnu/store/2a2016wffiy0cwvayvsz64r1f88k05mg-git-checkout.drv... > \r:sha256 hash mismatch for > /gnu/store/w2sl6n4jnbhzs8qp1k4lff35h1yml2c4-git-checkout: > expected hash: 1ykbpz6pqx0bkvfp3c60qfb9r0xvpmrs0ldlxm2qw0zd8f67lmaj > actual hash: 10nfjllq28jrzxd4dfqm6xzx8f2g1m6p2vivzihxc7d3ac1imnk2 > > So seems like it doesn't matter whether I am inside or outside the > directory I get the same hash (reasonable). > Neither git nor nar provide the correct hash > > FYI from https://guix.gnu.org/manual/en/html_node/Invoking-guix-hash.html > at the bottom explaining --exclude-vcs: > > $ git clone http://example.org/foo.git > $ cd foo > $ guix hash -rx . > > Suggests (to me) that you go inside the directory to calculate hash, though > as above seems not to matter. > > Thanks > > Mortimer > > > > > > > > On Tue, Jan 4, 2022 at 2:09 PM Timothy Sample wrote: > >> Hi zimoun, >> >> zimoun writes: >> >> > Indeed, >> > >> > $ guix hash -S git foo -x >> > 0czq9304mdv9f2j6a8cdi9855sl8w595p06c1m8bn9pg391lhcal >> > $ guix hash -S git foo >> > 0czq9304mdv9f2j6a8cdi9855sl8w595p06c1m8bn9pg391lhcal >> > >> > Hum, I will check if it is expected. >> >> I’m pretty sure it’s a bug. Fortunately, with Disarchive 0.4.0, the >> following (untested) patch should fix it: >> >> >> Hope that helps! >> >> >> -- Tim >> >
Re: How to use guix hash --serializer?
Thanks Tim, Simon, but that does not work for me. nar== mbc@HP8300:~/projects$ guix hash -S nar -x ./shinyln 1ykbpz6pqx0bkvfp3c60qfb9r0xvpmrs0ldlxm2qw0zd8f67lmaj mbc@HP8300:~/projects$ cd shinyln/ mbc@HP8300:~/projects/shinyln$ guix hash -S nar -x . 1ykbpz6pqx0bkvfp3c60qfb9r0xvpmrs0ldlxm2qw0zd8f67lmaj git== mbc@HP8300:~/projects/shinyln$ guix hash -S git -x . 0lai57r0p11q041b3flriv56j6n8lizwb69yv7j396yiivkspv3x mbc@HP8300:~/projects/shinyln$ cd .. mbc@HP8300:~/projects$ guix hash -S git -x ./shinyln 0lai57r0p11q041b3flriv56j6n8lizwb69yv7j396yiivkspv3x error during packaging= building /gnu/store/2a2016wffiy0cwvayvsz64r1f88k05mg-git-checkout.drv... \r:sha256 hash mismatch for /gnu/store/w2sl6n4jnbhzs8qp1k4lff35h1yml2c4-git-checkout: expected hash: 1ykbpz6pqx0bkvfp3c60qfb9r0xvpmrs0ldlxm2qw0zd8f67lmaj actual hash: 10nfjllq28jrzxd4dfqm6xzx8f2g1m6p2vivzihxc7d3ac1imnk2 So seems like it doesn't matter whether I am inside or outside the directory I get the same hash (reasonable). Neither git nor nar provide the correct hash FYI from https://guix.gnu.org/manual/en/html_node/Invoking-guix-hash.html at the bottom explaining --exclude-vcs: $ git clone http://example.org/foo.git $ cd foo $ guix hash -rx . Suggests (to me) that you go inside the directory to calculate hash, though as above seems not to matter. Thanks Mortimer On Tue, Jan 4, 2022 at 2:09 PM Timothy Sample wrote: > Hi zimoun, > > zimoun writes: > > > Indeed, > > > > $ guix hash -S git foo -x > > 0czq9304mdv9f2j6a8cdi9855sl8w595p06c1m8bn9pg391lhcal > > $ guix hash -S git foo > > 0czq9304mdv9f2j6a8cdi9855sl8w595p06c1m8bn9pg391lhcal > > > > Hum, I will check if it is expected. > > I’m pretty sure it’s a bug. Fortunately, with Disarchive 0.4.0, the > following (untested) patch should fix it: > > > Hope that helps! > > > -- Tim >
Re: How to use guix hash --serializer?
Hi zimoun, zimoun writes: > Indeed, > > $ guix hash -S git foo -x > 0czq9304mdv9f2j6a8cdi9855sl8w595p06c1m8bn9pg391lhcal > $ guix hash -S git foo > 0czq9304mdv9f2j6a8cdi9855sl8w595p06c1m8bn9pg391lhcal > > Hum, I will check if it is expected. I’m pretty sure it’s a bug. Fortunately, with Disarchive 0.4.0, the following (untested) patch should fix it: diff --git a/guix/scripts/hash.scm b/guix/scripts/hash.scm index d73e3d13dd..c44a4de9a4 100644 --- a/guix/scripts/hash.scm +++ b/guix/scripts/hash.scm @@ -69,7 +69,7 @@ (define* (git-hash file #:optional ((directory) #t) (else #f))) (if directory? - (git-hash-directory file algorithm) + (git-hash-directory file algorithm #:select? select?) (git-hash-file file algorithm))) Hope that helps! -- Tim
Re: Commit of currently installed package?
Hi, On Tue, 4 Jan 2022 at 17:02, wrote: > At one point I installed emacs-next --with-branch=master. Well, [...] > --export-manifest is approximate and doesn't even give package > versions. Even if I start playing games with --export-channels > or Scheme %current-profile => manifest => lookup in inferior > that would still find whatever guix repo commit had for > emacs-next, not what I actually have installed. No, you cannot know. Well, that information is not stored by Guix, AFAIK. Indeed, it could nice, instead of the current "guix package --export-manifest": --8<---cut here---start->8--- (use-modules (guix transformations)) (define transform1 (options->transformation '((with-branch . "emacs-next=master" (packages->manifest (list (transform1 (specification->package "emacs-next" --8<---cut here---end--->8--- To replace 'master' by the commit used. As a workaround, if it is recent enough (not removed by last-expiry-cleanup ;-)), the temporary Emacs checkout could be still there. :-) Give a look at ~/.cache/guix/checkouts/ and probably 5buqmtmwqjycqg4thcbrvijjn74pijwvjy7ueikyoln7r7d7q6kq. Hope that helps, simon
Re: Aarch64 build of rust-1.39.0 fails
On Tue, 04 Jan 2022 11:18:31 -0500 Maxim Cournoyer wrote: > Hi Denis, Hi, > The impact of the lack of Rust on non-x86_64 architectures has been > reduced on non-x86_64 architectures on the master branch by > workarounds such as using polkit-duktape in place of the regular > polkit to avoid requiring Rust for non-x86_64 architectures or an > older librsvg that can be used to build GTK without SVG support. > > The i686 native build of rust 1.39 via mrustc nearly succeeds, but > fails due to GCC using too much memory (more than the 4 GiB limit > imposed by 32 bit addressing). With the growth of Rust, there's > growing value in contributing testing and patches to mrustc, so if > you'd like to help Rust on Guix, that's currently the best option to > pursue (there's a #mrustc channel on libera.chat where the mrustc > author is often available). There's also a wip-cross-built-rust > branch that I had started; I stopped working on it after finding out > rustc couldn't be built statically; other than that it was working to > build rust things on non-x86_64 platforms. Thanks a lot. All the infos you gave me suggest that it's probably easier to try to build it from master than trying to go back in time (the approach I was trying). With both Guix system i686 and Parabola i686 (with linux-libre-pae) htop sees 8GiB of RAM on my laptop[1], and I've also 9G of swap available, and I can probably make it run builds the night, so I'll try to get that built on my laptop and report here and/or on IRC. Though at the end of the day, it'll really be fixed for everybody when official substitutes are available (as not everybody has that amount of RAM and the time to build it) and unfortunatelyu I can't help much with substitute (I guess it's just a matter of waiting for builds as soon as the build works reliability with enough RAM+swap). So beside reporting success/failures if that works, I'll probably try to fix other issues instead (tests fails on i686 for several packages) as I don't run substitute servers. References: --- [1] It's a Thinkpad x200 which is capable of running in x86_64 mode, but due to various reason my systems need to run in i686 mode. Denis. pgpfRDwYR3GKV.pgp Description: OpenPGP digital signature
Re: Emacs inside container: preserved DISPLAY unavailable etc
Hi, On Tue, 4 Jan 2022 at 17:02, wrote: > $ guix shell --container --no-cwd --network emacs-next > --expose=$HOME/.emacs.d --preserve='^DISPLAY$' -- emacs This works for me using f43a783 on Debian foreign distro; without the expose part and I do not think the issue comes from there. Are you using Guix System or Guix on foreign distro? Cheers, simon
Re: How to use guix hash --serializer?
Hi, On Tue, 4 Jan 2022 at 17:39, Mortimer Cladwell wrote: > (uri (git-reference > (url "git://github.com/mbcladwell/shinyln.git") > (commit "9f06568ffa61953ab48c93e1623d88b4e672af42"))) > (sha256 (base32 > "10nfjllq28jrzxd4dfqm6xzx8f2g1m6p2vivzihxc7d3ac1imnk2")) > $guix hash -rx . > 1ykbpz6pqx0bkvfp3c60qfb9r0xvpmrs0ldlxm2qw0zd8f67lmaj That's because you are inside the folder. Go outside $ guix hash -rx shinyln 10nfjllq28jrzxd4dfqm6xzx8f2g1m6p2vivzihxc7d3ac1imnk2 where shinyln is whatever the name of the folder where the Git repo is. > $guix hash --serializer=git -x . > 0lai57r0p11q041b3flriv56j6n8lizwb69yv7j396yiivkspv3x Here, you are using the Git serializer when Guix uses the Nar one. The correct is: guix hash -S nar -x shinyln > Appears that the -x switch has no effect. Indeed, $ guix hash -S git foo -x 0czq9304mdv9f2j6a8cdi9855sl8w595p06c1m8bn9pg391lhcal $ guix hash -S git foo 0czq9304mdv9f2j6a8cdi9855sl8w595p06c1m8bn9pg391lhcal Hum, I will check if it is expected. Cheers, simon
How to use guix hash --serializer?
Hi, Using guix package --install-from-file=guix.scm I determined the commit hash from the error message. The git-reference that works is: (uri (git-reference (url "git://github.com/mbcladwell/shinyln.git") (commit "9f06568ffa61953ab48c93e1623d88b4e672af42"))) (sha256 (base32 "10nfjllq28jrzxd4dfqm6xzx8f2g1m6p2vivzihxc7d3ac1imnk2")) In the local directory from where I issued git commit -am "my message" I try the following: $git log -n 1 commit 9f06568ffa61953ab48c93e1623d88b4e672af42 (HEAD -> master, origin/master) Author: mbcladwell Date: Tue Jan 4 09:08:09 2022 -0500 removed chmod statement $guix hash -rx . 1ykbpz6pqx0bkvfp3c60qfb9r0xvpmrs0ldlxm2qw0zd8f67lmaj $guix hash --serializer=git -x . 0lai57r0p11q041b3flriv56j6n8lizwb69yv7j396yiivkspv3x $guix hash --serializer=git . 0lai57r0p11q041b3flriv56j6n8lizwb69yv7j396yiivkspv3x Appears that the -x switch has no effect. -r and --serializer give different results. Neither result matches the (valid) error message hash. Where did I go wrong? Thanks Mortimer the .gitignore--- *.eps *.go *.log *.pdf *.png *.tar.xz *.tar.gz *.tmp *~ .#* \#*\# ,* /ABOUT-NLS /INSTALL /aclocal.m4 /autom4te.cache /build-aux/ar-lib /build-aux/compile /build-aux/config.guess /build-aux/config.rpath /build-aux/config.sub /build-aux/depcomp /build-aux/install-sh /build-aux/mdate-sh /build-aux/missing /build-aux/test-driver /build-aux/texinfo.tex /config.status /configure /doc/*.1 /doc/.dirstamp /doc/contributing.*.texi /doc/*.aux /doc/*.cp /doc/*.cps /doc/*.fn /doc/*.fns /doc/*.html /doc/*.info /doc/*.info-[0-9] /doc/*.ky /doc/*.pg /doc/*.toc /doc/*.t2p /doc/*.tp /doc/*.vr /doc/*.vrs /doc/stamp-vti /doc/version.texi /doc/version-*.texi /m4/* /pre-inst-env /test-env /test-tmp /tests/*.trs GPATH GRTAGS GTAGS Makefile Makefile.in config.cache stamp-h[0-9] tmp /.version /doc/stamp-[0-9]
Re: Aarch64 build of rust-1.39.0 fails
Hi Denis, Denis 'GNUtoo' Carikli writes: > On Sun, 19 Dec 2021 21:55:21 -0500 > Maxim Cournoyer wrote: >> This is not a Rust but a (known) mrustc issue, which is used to >> bootstrap Rust starting at version 1.39.0. It currently only supports >> x86_64, although the author is interested in enabling support for >> other architectures (a WIP). > So that's why it also fails on i686. > > In that case would it be possible to revert to the way it > was before for non x86_64 architectures (so without mrustc), when it's > done to switch the remaining architectures to mrustc when they become > ready for that? Rust has been bootstrapped via mrustc since September 2018 (commit 3159ef7c99c646b78b04cedb1bd3525c301ef978); I don't think it supported non-x86_64 back then, it's just that Rust wasn't as widely used as it is today so it had a lesser impact. The impact of the lack of Rust on non-x86_64 architectures has been reduced on non-x86_64 architectures on the master branch by workarounds such as using polkit-duktape in place of the regular polkit to avoid requiring Rust for non-x86_64 architectures or an older librsvg that can be used to build GTK without SVG support. The i686 native build of rust 1.39 via mrustc nearly succeeds, but fails due to GCC using too much memory (more than the 4 GiB limit imposed by 32 bit addressing). With the growth of Rust, there's growing value in contributing testing and patches to mrustc, so if you'd like to help Rust on Guix, that's currently the best option to pursue (there's a #mrustc channel on libera.chat where the mrustc author is often available). There's also a wip-cross-built-rust branch that I had started; I stopped working on it after finding out rustc couldn't be built statically; other than that it was working to build rust things on non-x86_64 platforms. Thanks, Maxim
Emacs inside container: preserved DISPLAY unavailable etc
Hi guix. Straigt out of manual: $ guix shell --container --no-cwd --network emacs-next --expose=$HOME/.emacs.d --preserve='^DISPLAY$' -- emacs No protocol specified Display :1 unavailable, simulating -nw Please set the environment variable TERM; see 'tset'. Why? What's going on here? Am I supposed to expose some device or smth? This is almost verbatim from Guix manual. Is there a way to find out which process' reporting that error? Lets pretend it isn't XXI century and try terminal emacs: $ guix shell --container --no-cwd --network emacs-next --expose=$HOME/.emacs.d --preserve='^TERM$' -- emacs This starts emacs in the terminal, but fails to load any user installed libraries e.g. use-package. Looks like they reside inside ~/.guix-profile/share/emacs/site-lisp, so maybe all we need to do is again follow the manual and --link-profile $ guix shell --container --no-cwd --network emacs-next --expose=$HOME/.emacs.d --preserve='^TERM$' --link-profile -- emacs That doesn't help but load-path inside emacs has $HOME/.guix-profile/share/emacs/site-lisp as first entry, hm. However, if we look inside its almost empty. So, I'm not entirely sure exactly what --link-profile even achieves. Is there some magic in play that "trims" /gnu/store entries only to whatever was in manifest (or packages) passed to guix shell --container? That would make sense if we are indeed trying to isolate things. If so, solution would be to -m manifest.scm with all my emacs packages along with emacs-next. I'd really like to solve the 'display unavailable' above. Could anyone help, please? Thank you
Commit of currently installed package?
Hi guix. Is there a way to find which commit the installed package came from. So that I could, for instance, `guix shell` this exact package. Specific case where I'm at a loss is this. At one point I installed emacs-next --with-branch=master. Well, I've no clue what that master was pointing at at the time. I find myself in the situation where current upstream master appears subtly broken, but my local install is fine. But how do I get my currently installed emacs-next version run inside `guix shell` or `guix shell --container`? --export-manifest is approximate and doesn't even give package versions. Even if I start playing games with --export-channels or Scheme %current-profile => manifest => lookup in inferior that would still find whatever guix repo commit had for emacs-next, not what I actually have installed. Does guix track that sort of provenance for me to extract? Thanks
Ctrl-g inside `guix shell --container emacs` broken
Hi Guix. This one is both subtle and deadly given mussle memory we all develop with Emacs key bindings. Tested with both Emacs 27 and 28: $ guix shell --container --no-cwd --preserve='^TERM$' emacs -- emacs -nw -q -Q or $ guix shell --container --no-cwd --preserve='^TERM$' emacs-next -- emacs -nw -q -Q Starts terminal Emacs fine. Now Ctrl-g or M-x followed by Ctrl-g which typically would send `keyboard-quit` and also abort-recursive-edit. You get kicked out of Emacs and shell ends up in a weird state, with Ctrl-D being the only way to kill it. Replicated in xterm and gnome-terminal. This is specific to --container! The following works just fine: $ guix shell --preserve='^TERM$' emacs -- emacs -nw -q -Q For completness I also tried: $ guix shell --container --no-cwd --preserve='^TERM$' emacs bash -- bash -c 'emacs -nw -q -Q' Any idea where and why --container could be breaking things? Note that `abort-recursive-edit` works perfectly fine. How exactly --container starts those processes? Could it be running some weird "shell" version that treats C-g specially somehow? How do I make it stop? $ guix describe Generation 10 Dec 27 2021 15:36:01(current) guix 9e9489f repository URL: https://git.savannah.gnu.org/git/guix.git branch: master commit: 9e9489fb11ac73e51abe293235738d70365affa9 Thanks
CMake cannot find Kicad package input
Hi, I am trying to upgrade the Guix Kicad package from version 5.1.10 to 5.1.12. When I upgrade the version and hash of the package definition and try to build it, it fails with a CMake error saying the OpenCascade header files are missing. "opencascade-oce" is listed as a package input, just as it is for version 5.1.10, which seems to build just fine. I see that opencascade-oce is installed in my /gnu/store and I see the header files are in the include/oce/ directory within it. One of the Kicad build options may have changed, perhaps requiring "-DKICAD_USE_OCE=ON", but it still fails even when I add that. Another option is to switch from "opencascade-oce" to "opencascade-occt" and switch the build option to "-DKICAD_USE_OCC=ON". Then opencascade-occt gets installed into /gnu/store and I see the header files in the include/opencascade/ directory within it. CMake still fails saying it cannot find the opencascade header files. Do I need to put more information in the Kicad package definition to get CMake to find the opencascade header files? Or perhaps do I need to modify the opencascade package definition to make CMake work properly to find the header files. Thanks!
