bug#69861: OpenTaxSolver Current tax year
Hi all, I know this isn't a properly submitted patch, but I think the change is pretty simple. 2024 taxes are comming up in the US. Could someone bump the version number for opentaxsolver? I tested the following changes which passed moderate testing on my part. diff --git a/gnu/packages/finance.scm b/gnu/packages/finance.scm index 8c30bd1a30..4fc1b3b711 100644 --- a/gnu/packages/finance.scm +++ b/gnu/packages/finance.scm @@ -2362,8 +2362,8 @@ (define-public opentaxsolver ;; writing, the version is 2022_20.00. Each part of this is used in ;; different places in the source uri, so it's convenient to have them ;; separately like this. - (let ((tax-year "2022") -(ots-version "20.00")) + (let ((tax-year "2023") +(ots-version "21.03")) (package (name "opentaxsolver") (version (string-append tax-year "_" ots-version)) @@ -2375,7 +2375,7 @@ (define-public opentaxsolver "_linux/OpenTaxSolver" version "_linux64.tgz")) (sha256 (base32 - "06k0a72bmwdmr71dvrp8b4vl8vilnggsh92hrp7wjdgcjj9m074w")) + "1i543bvclnyiwnyjlskhr2bxlsigggvwdhg2519rf12lsghgfszq")) (patches (search-patches "opentaxsolver-file-browser-fix.patch" (build-system glib-or-gtk-build-system) (arguments
bug#68811: build hash inconsistency
Hi all, I just tried the previous command on Device C, an x86_64-linux Guix System: ~ $ guix time-machine --commit=deeb7d1f53d7ddfa977b3eadd760312bbd0a2509 -- build qtwebengine --derivations --system=aarch64-linux --no-grafts --dry-run /gnu/store/gnrk76mlrv3ipm2k3lpmy1533mn9dqc3-qtwebengine-6.5.2.drv As suspected, the hash matches that of device A. I'm tempted to reflash Device B, wipe and reencrypt the SD (which has /gnu/store), and reinstall Guix, but I also want to get to the bottom of this. So long as this thread doesn't get stale, I'm happy to try whatever suggestions people have. -Zacchae
bug#68811: build hash inconsistency
Hi Josselin, Alas, the problem persists ~.~ Device A: ~ $ guix time-machine --commit=deeb7d1f53d7ddfa977b3eadd760312bbd0a2509 -- build qtwebengine --derivations --system=aarch64-linux --no-grafts --dry-run /gnu/store/gnrk76mlrv3ipm2k3lpmy1533mn9dqc3-qtwebengine-6.5.2.drv Device B: ~ $ guix time-machine --commit=deeb7d1f53d7ddfa977b3eadd760312bbd0a2509 -- build qtwebengine --derivations --system=aarch64-linux --no-grafts --dry-run /gnu/store/qpb6d1qqx357rkydk0xv6ail6b9dcqs6-qtwebengine-6.5.2.drv The fact that Device A finds substitutes for nearly everything while Device B doesn't makes me think that B is "wrong". Device A is a 3GiB RAM Librem 5 (made in China), and Device B is a 4GiB RAM Liberty Phone (made in USA). (Maybe US backdoor bots need to up their stealth game?) You can find info on how I set up guix at https://zacchae.us/guix-usd.org, specifically the section "Setting up guix home" -Zacchae PS - I see your response on issues.guix.gnu.org, but didn't get an email. I thought submitting bugs automatically subscribed me?
bug#68811: build hash inconsistency
Saku Laesvuori writes: > Those hashes are not comparable: i9ir..nd (A) is the hash of the built > store item and 6n9aq..qn (B) is the hash of the derivation that builds > the store item. Ah, rookie mistake :| > But I do think it is weird if the derivation is not present on the > machine that build qutebrowser. Would you mind sending the output of > `guix time-machine ... -- build --derivations ...` from both machines? > If they return a different hash you could maybe also check the returned > `/gnu/store/...-qutebrowser-2.5.4.drv` files to see what is the > difference between them. The derivations returned by guix build are still different: Device A: ~ $ guix time-machine --commit=deeb7d1f53d7ddfa977b3eadd760312bbd0a2509 -- build qutebrowser --derivations --dry-run /gnu/store/vyk5zfr2bjh4cilw4zk3d5xkjiar99h0-qutebrowser-2.5.4.drv Device B: ~ $ guix time-machine --commit=deeb7d1f53d7ddfa977b3eadd760312bbd0a2509 -- build qutebrowser --derivations --dry-run The following derivations would be built: /gnu/store/6n9aq7l5x26xfgrbvws7gvscbzvq5gqn-qutebrowser-2.5.4.drv /gnu/store/05wj7wf7bdlkm1ar58kpakvp52drrz7p-qtwebengine-5.15.10.drv /gnu/store/7nmv55qqw62jwzrd650vm434s3wpi7i3-python-pyqtwebengine-5.15.9.drv I wanted to build the .drv for qutebrowser as you suggested, but trying to do so caused qtwebengine to actually begin to build (not an option). I decided to try and build the .drv for qtwebengine on both devices and got even more interesting differences (see below). Main things I noticed: qtwebengine-everywhere-src has different hashes but they are both found on substitute servers, the qtwebengine .drv file also has different hashes, oh no that's a lot of thing my device is trying to build. I get errors if I try to build for armhf-linux, so I don't think I installed the wrong version of Guix. Could it be a difference in guix-daemon version? I have Guix on foreign distro, but I modified the guix-daemon service to point to /var/guix/../root/../guix daemon instead of /usr/bin/guix-daemon. Those root profile versions could be quite different between the two devices (though in theory that shouldn't matter). -Zacchae Device A: ~ $ guix time-machine --commit=deeb7d1f53d7ddfa977b3eadd760312bbd0a2509 -- build qtwebengine --derivations --dry-run 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 would be built: /gnu/store/gnrk76mlrv3ipm2k3lpmy1533mn9dqc3-qtwebengine-6.5.2.drv 470.1 MB would be downloaded: /gnu/store/yw7r6bzl0yya0s0h9glz06vy2j88f14d-python-soupsieve-2.2.1 /gnu/store/i42j0d1797cw6jh3mnrdfgwz2mvsgnv7-clang-14.0.6 /gnu/store/2ghh4x5j4hsanan9rpka80lxdh1kxnrq-lld-wrapper-0 /gnu/store/9ylcnhf8rcgwd3jazghz72jcq67kb7hs-lld-14.0.6 /gnu/store/zsa0xdc4pqjils8j8gn6s0cgcf22j48c-ld.lld-wrapper-0 /gnu/store/bjd1gyvag1fjwbm4q8fdkx4ci348khwn-lld-as-ld-wrapper-14.0.6 /gnu/store/b3j2dabjfk3z8vrcdn04dxdr4m8834hs-openh264-2.3.0 /gnu/store/ymjvjq5cyi8cclsrkqmmih6jsmxidjwp-cmake-minimal-3.24.2 /gnu/store/66anfjz8bv5a5rf9ii9fd66dzga9dlv6-jsoncpp-1.9.5 /gnu/store/b2bkchln7na32bk5mfd1gl896ac2ng9d-clang-runtime-14.0.6 /gnu/store/na1xngg46bwpxh9jl74hnsw5gp5q8mbp-python-beautifulsoup4-4.11.1 /gnu/store/i5hhylp02w3qqf2xjyws9kbii93jjqcs-libxkbfile-1.1.0 /gnu/store/cy356bl5cj9sd915pwzvx1l2njvvh80l-qtmultimedia-6.5.2 /gnu/store/w3ja0fcg7x2g8pr0l5ggzpbjbs1sxzw2-python-html5lib-1.1 /gnu/store/8c5al6nn6ihqm6vv71fszv0k3pm0zy4b-llvm-14.0.6 /gnu/store/i74mgypyv2j7i6p28x5z5r1l7mn3q11d-python-chardet-5.1.0 /gnu/store/x0j572gnp5az71lcxs58274z11g27rsg-qtwebchannel-6.5.2 /gnu/store/yqppj5kr0fzph6wvbhxlq6v6ynpa5xsq-protobuf-3.21.9 /gnu/store/0cwx6qvc0jl5amb6lcanninis5xwsm49-md4c-0.4.8 /gnu/store/a51gd25m22p623c3mwpbsc0bah30r534-qtbase-6.5.2 /gnu/store/xylrvhrdv72x62vi94f73m7wdq8361r6-qtlanguageserver-6.5.2 /gnu/store/6m5andsmqhxk7jrk1f0fmsa5012jmiw9-qtdeclarative-6.5.2 /gnu/store/qi88j5lvxg2cmc391frvvlz91m4jv3ij-qtwebengine-everywhere-src-6.5.2.tar.xz /gnu/store/733pxaaxhdqs95a7qp7ydh831a77lyzp-ninja-1.11.1 /gnu/store/qjby2hz1d2154jx06755x8wxyfi5ycmd-python-webencodings-0.5.1 /gnu/store/1ik19yadbhc959nbk42gb548139vypp3-node-18.19.0 Device B: ~ $ guix time-machine --commit=deeb7d1f53d7ddfa977b3eadd760312bbd0a2509 -- build --derivations qtwebengine --dry-run substitute: updating substitutes from 'https://ci.guix.gnu.org'... 100.0% substitute: updating substitutes from 'https://bordeaux.guix.gnu.org'... 100.0% The following derivations would be built: /gnu/store/qgk0k5312p9bfikhgi87644rdb9h71g5-qtwebengine-6.5.2.drv /gnu/store/3kr5g43593v5x42nhz2396hb8a4sp7k8-qtwebchannel-6.5.2.drv /gnu/store/1waf6s55grvdx686nn4fg5mfsxz0567g-qtwebsockets-6.5.2.drv /gnu/store/lffwivm3lgk8p5sgifa49wx3j29srlc7-qtdeclarative-6.5.2.drv /gnu/store/082dd9z9d8n5s09x4m6k4d1ckxx4yzj2-qtshadertools-6.5.2.drv
bug#68811: build hash inconsistency
Some more context might be useful: Device A (which successfully built qutebrowser over a couple days) ~ $ guix time-machine --commit=deeb7d1f53d7ddfa977b3eadd760312bbd0a2509 -- build qutebrowser --dry-run /gnu/store/i9ir7a26gv1ii98b4bzgvxp1sx0akind-qutebrowser-2.5.4 Device B (trying to avoid building qutebrowser) ~ $ guix time-machine --commit=deeb7d1f53d7ddfa977b3eadd760312bbd0a2509 -- build qutebrowser --dry-run The following derivations would be built: /gnu/store/6n9aq7l5x26xfgrbvws7gvscbzvq5gqn-qutebrowser-2.5.4.drv /gnu/store/05wj7wf7bdlkm1ar58kpakvp52drrz7p-qtwebengine-5.15.10.drv /gnu/store/7nmv55qqw62jwzrd650vm434s3wpi7i3-python-pyqtwebengine-5.15.9.drv I have noticed in the past that sometimes a package gets built twice with two hashes, so I went back and checked if device A had built the 6n9..5gqn qutebrowser store item reported by B in addition to the i9i..ind one A was reporting. There was no 6n9..5gqn qutebrowser build on device A. I don't believe I have never run guix gc on either device. -Zacchae
bug#68811: build hash inconsistency
Hi all, tl;dr I run the following command on two aarch64-linux machines and get two different hashes for the 'qutebrowser' package: guix time-machine --commit=deeb7d1f53d7ddfa977b3eadd760312bbd0a2509 -- build qutebrowser --dry-run Both machines use only the main guix repository, and guix describe gives the same output (except generation number and date, which is fine). Coming from aarch64, building is incredibly expensive. If the build hash doesn't match, then (I believe) there is no hope that my machine will find the packages on a substitute server. To get around this issue, I built my guix home once, guix copy'd the store items, and manually added a symlink in /var/guix/profiles/per-user/USER/guix-home-N-link to point to the foreign guix home build. I couldn't find this issue elsewhere in the issues, but my "hashes don't match" problem is pretty vague. Is this an expected problem? Is this a novel problem? Am I misunderstanding guix time-machine (which seems like it should produce an identical store item)? -Zacchae
bug#64534: emacs tramp-remote-path does not include guix home
Hi Guix! I noticed that the emacs package has the following value for tramp-remote-path out of the box: (tramp-default-remote-path "~/.guix-profile/bin" "~/.guix-profile/sbin" "/run/current-system/profile/bin" "/run/current-system/profile/sbin" "/bin" "/usr/bin" "/sbin" "/usr/sbin" "/usr/local/bin" ...) This does not seem to include guix home bin dirs. Indeed, when I connect to my remote machine via tramp, and try to run "git", I get: git: command not found This can be fixed by evaluating: (setq tramp-remote-path (-cons* "~/.guix-home/profile/bin" "~/.guix-home/profile/sbin" tramp-remote-path)) (tramp-cleanup-all-connections) In which case, running "git" in a remote shell gives the expected git help message. Is there a reason guix home bin dirs are omitted? -Zacchae
bug#62955: (no subject)
And just like that, i find there is already a discussion of some of this in 56050, though the fact that non-existant paths can be added by guix home to those variables is seems to be missing from that discussion. Could someone merge the threads? (I assume I can't do that.) -Zacchae
bug#62955: Guix Home Breaks Some Foreign Distros
Hi all! $HOME/PROFILE/setup-environment contains the following lines: case $XDG_CONFIG_DIRS in *$HOME_ENVIRONMENT/profile/etc/xdg*) ;; *) export XDG_CONFIG_DIRS=$HOME_ENVIRONMENT/profile/etc/xdg:$XDG_CONFIG_DIRS ;; esac There are two bugs in this code. Both bugs revolve around what happens if XDG_CONFIG_DIRS is unset, as is the case in some foreign distros. The first problem is if, XDG_CONFIG_DIRS is unset, and $HOME_ENVIRONMENT/profile/etc/xdg does not exist, then the conditional resolves to "is the empty string in the empty string", so XDG_CONFIG_DIRS is prepended with $HOME_ENVIRONMENT/profile/etc/xdg, despite it not existing. I'm not sure if incuding a nonexistant path in XDG_CONFIG_DIRS should cause problems, but this scenario is not mentioned in the XDG specifications[1], so some programs are bound to crash because of this. The second problem (more important) relates to how XDG_CONFIG_DIRS is interpreted if empty vs set to a value. As per the xdg specifications[1], if XDG_CONFIG_DIRS is unset, then a value of /etc/xdg should be used. When an empty XDG_CONFIG_DIRS is set by guix home, programs find a non-empty value and ignore /etc/xdg. The above problem means that when I do a guix home reconfigure on my Librem 5 running PureOS, I get a black screen as Phosh fails to start as it needs files in /etc/xdg. I can fix it by adding: XDG_CONFIG_DIRS="$XDG_CONFIG_DIRS:/etc/xdg" to my .zlogin. A similar issue can be seen with the lines regarding XDG_DATA_DIRS in $HOME/PROFILE/setup-environment. I think a good step to resovling this issue is to set empty variables to their default value first. Maybe something like the following in gnu/home/services.scm:267 ... [ -f $PROFILE_FILE ] && . $PROFILE_FILE [ -z "$XDG_DATA_DIRS"] && XDG_DATA_DIRS=/usr/local/share/:/usr/share/ [ -z "$XDG_CONFIG_DIRS"] && XDG_CONFIG_DIRS=/etc/xdg case $XDG_DATA_DIRS in ... This addresses the second problem, but not the first. Someone may find a more elegant way to deal with both issues. -Zacchae [1] https://specifications.freedesktop.org/basedir-spec/basedir-spec-latest.html
bug#60545: Keras h5py Version Mismatch
Hi, I should probably mention that I am not looking into this. I want to learn more guix, but keras and the additional dependencies required for later versions is kind of a monster to me at the moment. Thanks, Zacchae From: zimoun Sent: Friday, January 6, 2023 6:40 AM To: Zacchaeus Scheffer ; 60...@debbugs.gnu.org <60...@debbugs.gnu.org> Subject: Re: bug#60545: Keras h5py Version Mismatch CAUTION: Email originated externally, do not click links or open attachments unless you recognize the sender and know the content is safe. Hi, On Wed, 04 Jan 2023 at 01:37, Zacchaeus Scheffer wrote: > working (pip): keras 2.10.0, h5py 3.7.0 > not working (current guix): keras 2.2.4, h5py 3.6.0 Indeed, it is collateral to ea403bf290f4bf8c7bae314e32dbb90653f92996 --8<---cut here---start->8--- gnu: python-h5py: Update to 3.6.0. * gnu/packages/python-xyz.scm (python-h5py): Update to 3.6.0. [arguments]: Set HDF5_DIR variable instead of patching files. --8<---cut here---end--->8--- Well, the update of Keras to 2.11.0 (the current latest) requires some work. First, fetch from Github instead of PyPI because the sources are not available after v2.6.0; e.g., https://urldefense.proofpoint.com/v2/url?u=https-3A__pypi.org_project_keras_2.11.0_-23files=DwIBAg=7dfBJ8cXbWjhc0BhImu8wVIoUFmBzj1s88r8EGyM0UY=1moyBSYvgSFmdTYHNEHEwakZGFkPl3pixLezH1qWWXFZPpSXOvpoeGr4XIg6G8V0=NqD4egq46utBpoyT-8Gr6A3lESGvdg2j7CIMrB0r_y4I-pFRV2Gxn2-Lb7s7tsyD=Ro23h-Sd5x7VKOXeIYl4j5KGqDMAyZprruKUgdacbCo= Then, second adapt the recipe. Do you want to give a try? Cheers, simon
bug#57844:
Oh wow, should have read closer. That's a shepherd socket, not a syncthing socket. (happened across this thread searching syncthing) Please Disregard, Zacchae
bug#57844: (no subject)
Hi all, Not sure if it is relevant, but I have often had this problem, and it has always been from an orphaned syncthing process. I.e, the user login session which has my guix home services running in it ends, but the syncthing process is not terminated. Then I start a new login, and it tries to start a NEW syncthing service, and gives this same error. You can check this (next time syncthing fails to start) with: ps -e | grep syncthing Hope this helps, Zacchae
bug#60545: Keras h5py Version Mismatch
Hi Guix!
It would seem that the current keras version expects an earlier h5py version
for loading models. Specifically, running:
from tensorflow.keras.models import load_model
model = load_model("model.h5")
fails with:
File
"/gnu/store/idfn4l2kxil9id21v1yci4jcw6103fah-profile/lib/python3.9/site-packages/tensorflow/python/keras/engine/saving.py",
line 228, in load_model
model_config = json.loads(model_config.decode('utf-8'))
AttributeError: 'str' object has no attribute 'decode'
The above works fine in my local pip environment (see below). A quick search
online indicates that this can be fixed by downgrading h5py to version 2.10.
The current h5py version in guix is 3.6.
My assumption is that this could also be fixed with an upgrade to keras, but
upgrading keras sounds much more involved. For a short-term fix, would it be
possible to add back a package definition for an earlier h5py in addition to
the current version? I'm sure an appropriate version exists somewhere in
guix's git history, though my git-foo is too weak for me to check.
Thanks,
Zacchae
P.S.
working (pip): keras 2.10.0, h5py 3.7.0
not working (current guix): keras 2.2.4, h5py 3.6.0
bug#54014: guix home pinentry weirdness
On Mon, Jul 4, 2022 at 1:50 AM Andrew Tropin wrote: > On 2022-02-15 13:46, Zacchaeus Scheffer wrote: > > There seems to be some problem installing password-store + pinentry > > entirely via guix home. When I have both installed as such, I get the > > following outputs: > > > > $ pinentry > > OK Pleased to meet you > > > > $ gpg --import ... > > [prompts normally with pinentry, allows me to import] > > $ pass > > [my password entries] > > $ pass [entry name] > > gpg: decryption failed: No secret key > > $ guix package -i pinentry > > $ pass [entry name] > > [prompts with pinentry and works normally] > > > > So pinentry and pass seem to both be available, but don't work together > > unless I install pinentry via guix package. > > I suspect that the problem is that someone at some moment of time > doesn't have ~/.guix-home/profile/bin in its $PATH and thus it can't > find a pinentry. Can you show `which gpg`, `which pass`, `which > pinentry`? > Before running "guix package -i pinentry" $ which -a pinentry /home/zacchae/.guix-home/profile/bin/pinentry $ which -a gpg /home/zacchae/.guix-home/profile/bin/gpg $ which -a pass /home/zacchae/.guix-home/profile/bin/pass After runing "guix package -i pinentry" $ which -a pinentry /home/zacchae/.guix-home/profile/bin/pinentry /home/zacchae/.guix-profile/bin/pinentry $ which -a gpg /home/zacchae/.guix-home/profile/bin/gpg $ which -a pass /home/zacchae/.guix-home/profile/bin/pass I can easily reproduce the behavior by removing or installing pinentry with guix package. Paths behave as expected. The gnupg home service from rde project goes a slightly other way and > just sets pinentry-program to absolute path in the store. Such approach > works with pass well, you can take a look at it for inspiration: > > https://git.sr.ht/~abcdw/rde/tree/master/item/gnu/home-services/gnupg.scm#L127 > I don't totally follow what's going on here, but maybe it will make more sense later.
bug#56373: Updating synapse (Matrix Homeserver) Because it is Broken
Hi Guix! I'm trying to update synapse because it seems an update somewhere has broken synapse (I'm thinking python -> 3.9.*?). Specifically, I get the following traceback: $ synctl start .config/synapse/homeserver.yaml --no-daemonize Starting ... Traceback (most recent call last): File "/gnu/store/z561ps804hs0shwicdw076wwg4mim8ml-python-3.9.9/lib/python3.9/runpy.py", line 197, in _run_module_as_main return _run_code(code, main_globals, None, File "/gnu/store/z561ps804hs0shwicdw076wwg4mim8ml-python-3.9.9/lib/python3.9/runpy.py", line 87, in _run_code exec(code, run_globals) File "/gnu/store/sgxq33kpvbc56j1ag0rwhj3f9w16wfz0-synapse-1.29.0/lib/python3.9/site-packages/synapse/app/homeserver.py", line 45, in from synapse.federation.transport.server import TransportLayerServer File "/gnu/store/sgxq33kpvbc56j1ag0rwhj3f9w16wfz0-synapse-1.29.0/lib/python3.9/site-packages/synapse/federation/transport/server.py", line 46, in from synapse.server import HomeServer File "/gnu/store/sgxq33kpvbc56j1ag0rwhj3f9w16wfz0-synapse-1.29.0/lib/python3.9/site-packages/synapse/server.py", line 55, in from synapse.events.spamcheck import SpamChecker File "/gnu/store/sgxq33kpvbc56j1ag0rwhj3f9w16wfz0-synapse-1.29.0/lib/python3.9/site-packages/synapse/events/spamcheck.py", line 20, in from synapse.rest.media.v1._base import FileInfo File "/gnu/store/sgxq33kpvbc56j1ag0rwhj3f9w16wfz0-synapse-1.29.0/lib/python3.9/site-packages/synapse/rest/__init__.py", line 32, in from synapse.rest.client.v2_alpha import ( File "/gnu/store/sgxq33kpvbc56j1ag0rwhj3f9w16wfz0-synapse-1.29.0/lib/python3.9/site-packages/synapse/rest/client/v2_alpha/account.py", line 40, in from synapse.push.mailer import Mailer File "/gnu/store/sgxq33kpvbc56j1ag0rwhj3f9w16wfz0-synapse-1.29.0/lib/python3.9/site-packages/synapse/push/mailer.py", line 860, in def safe_markup(raw_html: str) -> jinja2.Markup: AttributeError: module 'jinja2' has no attribute 'Markup' error starting (exit code: 1); see above for logs No logs are saved because the code crashes before it can get to that. A quick search brought me to https://github.com/YunoHost-Apps/synapse_ynh/issues/304 which indicates that the problem is expected and fixed in later versions. It seems matrix abstracted some code to a new repository, as just increasing the synapse version number causes it to fail as it looks for a library: "matrix-common". My current working definition for matrix-common is: (define-public python-matrix-common (package (name "python-matrix-common") (version "1.2.0") ; tried 1.2.1 and 1.2.0 (source (origin (method url-fetch) (uri (pypi-uri "matrix_common" version)) (sha256 (base32 "0lrqzb6s57fxp0kwffdqnkr2pj9aia459cv1b95b55dxlq1cz7d9" ;"1bgdhzvqs51z079zjszhd5xqb100mbr5w8gpxs9z31r5xmi5nw7a" (build-system python-build-system) (arguments `(#:use-setuptools? #f ; tried with and without this #:phases (modify-phases %standard-phases (replace 'build (lambda _ (setenv "SOURCE_DATE_EPOCH" "315532800") (invoke "python" "-m" "build" "--wheel" "--no-isolation" "."))) (delete 'check) (replace 'install (lambda* (#:key outputs #:allow-other-keys) (let ((out (assoc-ref outputs "out")) (whl (car (find-files "dist" "\\.whl$" (invoke "pip" "--no-cache-dir" "--no-input" "install" "--no-deps" "--prefix" out whl (delete 'sanity-check (propagated-inputs (list)) (native-inputs (list python-pypa-build python-attrs)) (home-page "https://github.com/matrix-org/matrix-python-common;) (synopsis "Common utilities for Synapse, Sydent and Sygnal") (description "") (license license:asl2.0))) The matrix-common library has no setup.py, hence I tried replacing the build and install phase with something similar to what was done for python-isort as suggested in the irc. I deleted check for now because it was looking for setup.py. This definition builds without printing errors. However, when I try to build synapse in v1.61.1 (adding python-matrix-common to the native-inputs), I get the following output: starting phase `check' running "python setup.py" with command "test" and parameters () running test WARNING: Testing via this command is deprecated and will be removed in a future version. Users looking for a generic test entry point independent of test runner are encouraged to use tox. WARNING: The wheel package is not available. WARNING: The directory '/homeless-shelter/.cache/pip' or its parent directory is not owned or is not writable by the current user. The cache has been disabled. Check the permissions and owner of that directory. If executing pip with sudo, you should use sudo's -H flag. WARNING: Retrying
bug#54014: guix home pinentry weirdness
I thought it might be important to confirm package versions. Here is some sample commands and their output: before guix package -i pinentry (pass not giving pinentry prompt) $ ls -l $(which -a pinentry) lrwxrwxrwx 1 root root 71 Dec 31 1969 /home/zacchae/.guix-home/profile/bin/pinentry -> /gnu/store/3hl7w63q0axngysrslkdw2a6jmgnm8kf-pinentry-1.2.0/bin/pinentry after guix package -i pinentry (pass works normally) $ ls -l $(which -a pinentry) lrwxrwxrwx 1 root root 71 Dec 31 1969 /home/zacchae/.guix-home/profile/bin/pinentry -> /gnu/store/3hl7w63q0axngysrslkdw2a6jmgnm8kf-pinentry-1.2.0/bin/pinentry lrwxrwxrwx 1 root root 71 Dec 31 1969 /home/zacchae/.guix-profile/bin/pinentry -> /gnu/store/3hl7w63q0axngysrslkdw2a6jmgnm8kf-pinentry-1.2.0/bin/pinentry So it's not as simple as a version mismatch. -Zacchaeus
bug#54014: guix home pinentry weirdness
Hi Guix, There seems to be some problem installing password-store + pinentry entirely via guix home. When I have both installed as such, I get the following outputs: $ pinentry OK Pleased to meet you $ gpg --import ... [prompts normally with pinentry, allows me to import] $ pass [my password entries] $ pass [entry name] gpg: decryption failed: No secret key $ guix package -i pinentry $ pass [entry name] [prompts with pinentry and works normally] So pinentry and pass seem to both be available, but don't work together unless I install pinentry via guix package. My guix install is about two months behind, so sorry if this has already been patched. -Zacchaeus
bug#53886: guix home not respecting guix pull -C
> > I believe that's the main misunderstanding here, `guix home` acts like > `guix system`: it creates home generations, inside which there is a > profile. That profile is _not_ ~/.guix-profile, but rather > ~/.guix-home/profile. They are disjoint and not operated on by the same > commands, guix home will not touch ~/.guix-profile. If you configure > your shell environment variables with guix home alone, I believe only > the the guix home profile is available by default. > I think I tracked down the problem. In my home-zsh-service, I added the contents of my previous .zprofile to to my new .zprofile, including "source /etc/profile", so my .zprofile (with autogenerated lines) looked like: source /etc/profile source ~/.profile source /etc/profile Basically, /etc/profile stripped from my PATH the ~/.guix-home/profile which was added by ~/.profile I think this solves the original problem, but I don't like that ~/.guix-profile/ AND ~/.guix-home/profile are added to your path by default. I admit this is probably a "sane default" for most users, but I care a lot about reproducibility. Though I think there should be a better solution, for now I am going to have guix home run "guix package -m" with an empty manifest on reconfigure. Thanks all for your help, Zacchaeus
bug#53886: guix home not respecting guix pull -C
/home/zacchae/.ssh (not an empty directory)... done Removing /home/zacchae/.local/bin/stdinedit... done Removing /home/zacchae/.local/bin... done Skipping /home/zacchae/.local (not an empty directory)... done Removing /home/zacchae/.gitconfig... done Removing /home/zacchae/.exwm... done Removing /home/zacchae/.zshenv... done Removing /home/zacchae/.profile... done Cleanup finished. New symlinks to home-environment will be created soon. All conflicting files will go to /home/zacchae/1644387797-guix-home-legacy-configs-backup. Skipping /home/zacchae/.config (directory already exists)... done Creating /home/zacchae/.config/fontconfig... done Symlinking /home/zacchae/.config/fontconfig/fonts.conf -> /gnu/store/3hd0w1mcm3zg7gy3ifgvdf8w1n77khnm-fonts.conf... done Skipping /home/zacchae/.config/zsh (directory already exists)... done Symlinking /home/zacchae/.config/zsh/.zshrc -> /gnu/store/hyvqqy8i6ibi72xc5361p08qjibnwfk4-zshrc... done Symlinking /home/zacchae/.config/zsh/.zprofile -> /gnu/store/jgz1ykacgqwkjbwagd301nj4y9ygdi9m-zprofile... done Symlinking /home/zacchae/.config/zsh/.zshenv -> /gnu/store/251xg38dsqifyw3dzwzpvl28vi7c8wd6-zshenv... done Skipping /home/zacchae/.config/syncthing (directory already exists)... done Symlinking /home/zacchae/.config/syncthing/config -> /gnu/store/7svbwjb0ixzjz2kllk6fxc8737aavd35-syncthing-config.xml... done Skipping /home/zacchae/.config/emacs (directory already exists)... done Symlinking /home/zacchae/.config/emacs/init.el -> /gnu/store/7p09csma6wk8bcanqm8wrra0v4yw496y-emacs-config... done Creating /home/zacchae/.config/kitty... done Symlinking /home/zacchae/.config/kitty/kitty.conf -> /gnu/store/pmnr4ivcviwyi2h2yrx1rg8gf0rjs0ay-kitty.conf... done Skipping /home/zacchae/.config/qutebrowser (directory already exists)... done Symlinking /home/zacchae/.config/qutebrowser/config.py -> /gnu/store/c50z8wfsc4k1m0h7k3sbv0xsndh7bw6j-qutebrowser-config... done Creating /home/zacchae/.config/zathura... done Symlinking /home/zacchae/.config/zathura/zathurarc -> /gnu/store/kdi0gfbz5gcq2ay32yv89amvhbd5r3wg-zathura-config... done Creating /home/zacchae/.config/redshift... done Symlinking /home/zacchae/.config/redshift/redshift.conf -> /gnu/store/p1y1xfxf63pjn1dsd92vwp1xbrcsh7wn-redshift-config... done Skipping /home/zacchae/.ssh (directory already exists)... done Symlinking /home/zacchae/.ssh/config -> /gnu/store/519n9v56q5qnhwrb3yj8dh87lwspqlrb-ssh-config... done Skipping /home/zacchae/.local (directory already exists)... done Creating /home/zacchae/.local/bin... done Symlinking /home/zacchae/.local/bin/stdinedit -> /gnu/store/3rx8zb8phkr8a88sg5v8pd33qxn62zyh-stdinedit... done Symlinking /home/zacchae/.gitconfig -> /gnu/store/ci21256g0sys1a0gpwlrvakgazwbh5kb-git-config... done Symlinking /home/zacchae/.exwm -> /gnu/store/z43zay3w80cp0bnwdd1pi5j4zxay75mp-exwm-init... done Symlinking /home/zacchae/.zshenv -> /gnu/store/j1558r4rqn5nlj3caxs62jcs7rb2j4x4-auxiliary-zshenv... done Symlinking /home/zacchae/.profile -> /gnu/store/rnf1g1a1lywvy3lw4h8ywfs9i8f35fiq-shell-profile... done done Finished updating symlinks. Loading /gnu/store/2z8k6n538446fm0r5byk81kcv3khgkkn-shepherd.conf. Starting services... Comparing /gnu/store/02q0hr0k29wr866b1mrh88qnaixnk3v7-home/profile/share/fonts and /gnu/store/02q0hr0k29wr866b1mrh88qnaixnk3v7-home/profile/share/fonts... done (same) Evaluating on-change gexps. On-change gexps evaluation finished. ## END RECONFIGURE PASTE On Tue, Feb 8, 2022 at 8:06 PM Leo Famulari wrote: > On Tue, Feb 08, 2022 at 06:57:14PM -0500, Zacchaeus Scheffer wrote: > > Hi Guix! > > > > I came across some weird behavior with guix home. I wanted to recreate a > > working home environment from one machine on another (because I need a > > working qutebrowser install :3). I did this by doing "guix pull > > --allow-downgrades -C" on my non-working computer using a channels file > on > > the working one generated with "guix package --export-channels". > However, > > when I did "guix home reconfigure ...", old versions of packages were NOT > > installed. I was able to downgrade the desired package with "guix > package > > -i" (only that package was downgraded). > > I'm curious, after you did `guix pull --allow-downgrades -C`, did you > use `guix show foo` before reconfiguring, in order to check if the pull > had taken effect? > > Also, did you pull and reconfigure as the same user, with the same > privileges? Remember that your "view" of Guix (i.e. `guix pull`) is > per-user. > > > My understanding is that "guix home reconfigure" SHOULD behave like "guix > > package --manifest", and install all packages in the most recent guix > pull. > > That's my understanding as well. >
bug#53886: guix home not respecting guix pull -C
Hi Guix! I came across some weird behavior with guix home. I wanted to recreate a working home environment from one machine on another (because I need a working qutebrowser install :3). I did this by doing "guix pull --allow-downgrades -C" on my non-working computer using a channels file on the working one generated with "guix package --export-channels". However, when I did "guix home reconfigure ...", old versions of packages were NOT installed. I was able to downgrade the desired package with "guix package -i" (only that package was downgraded). My understanding is that "guix home reconfigure" SHOULD behave like "guix package --manifest", and install all packages in the most recent guix pull. Very minor and not impeding me, but thought y'all should know, -Zacchaeus Scheffer
bug#53752: guix home symlink permissions
> > > I finally migrated my home configuration to guix home. However, it >> > seems guix home creates all symlinks with 777 permissions. This causes >> > problems with openssh as it will not recognize my >> > ~/.ssh/authorized_keys. It seems the directories have reasonable >> > permissions (maybe because they already existed?), but it seems like >> > someone could in theory edit the symlinks in-place (though I wasn't >> > able to figure that out). >> Instead of using symllinks for ~/.ssh/authorized_keys, you could try to >> write a home-activation-service, which >> >> 1. creates ~/.ssh with chmod 700 >> 1a. if it already existed, enforces chmod 700 anyways >> 2. creates authorized_keys with chmod 600 if it doesn't exist >> 3. writes the authorized keys. >> > > I'll try that soon (next 1-3 days), and hopefully then we can close this > issue. > I was able create the desired effect with the following service definition: (simple-service 'my-activation-service home-activation-service-type (gexp (begin (chdir (ungexp user-home)) (if (not (file-exists? ".ssh")) (mkdir ".ssh")) (chmod ".ssh" #o700) (chdir ".ssh") (let ((port (open-output-file "authorized_keys"))) (display (ungexp authorized-keys) port) (close-port port)) (chmod "authorized_keys" #o600) (chdir ".." where 'user-home and 'authorized-keys are appropriate strings defined earlier in the file. I believe that resolves the issue, Zacchaeus Scheffer
bug#53752: guix home symlink permissions
> > > I finally migrated my home configuration to guix home. However, it > > seems guix home creates all symlinks with 777 permissions. This causes > > problems with openssh as it will not recognize my > > ~/.ssh/authorized_keys. It seems the directories have reasonable > > permissions (maybe because they already existed?), but it seems like > > someone could in theory edit the symlinks in-place (though I wasn't > > able to figure that out). > Instead of using symllinks for ~/.ssh/authorized_keys, you could try to > write a home-activation-service, which > > 1. creates ~/.ssh with chmod 700 > 1a. if it already existed, enforces chmod 700 anyways > 2. creates authorized_keys with chmod 600 if it doesn't exist > 3. writes the authorized keys. > I'll try that soon (next 1-3 days), and hopefully then we can close this issue. I would strongly advise against that however. While user homes are by > default 700 in Guix, the store is world readable and so are your > authorized keys if you put them there. A malicious user can't > necessarily change them, but they can spy on you. > For context, I keep such info in my password store, but am ok with certain things from it not being "secret". It is already standard for public keys to be kept in the store; see: - operating-system -> services -> openssh -> authorized-keys and as a more extreme example, encrypted user passwords are often kept in the store; see: - operating-system -> users -> user -> password It's not ideal that someone can snoop my public keys, but that is worth enabling me to have private keys that can reproducibly connect to my user. If one is worried about it, they could avoid usage of those specific private keys as much as possible, so I think it's ok... > Guix currently has no way of securely storing your data in the store > (in a cryptographic sense). This is exacerbated by the fact that such > files aren't well-encrypted by default -- user read-only is "good > enough" in many cases, e.g. gnome-keyring does encrypt passwords, but > stores metadata in plain. Emacs plstores and Recfiles likewise support > partial encryption based on GPG. > > This issue has been known since June 2020 [1]. While there would in > theory exist solutions that can work for (guix home) but not (guix > system), I can not yet make any statements regarding their quality. > Indeed, storing secrets with Guix is an open issue, that will likely be > given some attention during the upcoming Guix Days. > At the end of the day, there will be setup that should NOT happen automatically (should require gpg passphrase input). Currently, I do this for private keys by automatically pulling from my password store (requiring password input) using fancy emacs org tangling. I'll look into managing even this with guix home, but that is probably a discussion for guix-devel. Thanks all, Zacchaeus Scheffer
bug#53752: guix home symlink permissions
It seems the permissions on the symlink don't matter. The problem is that the file linked to in the store is readable by everyone (which I am ok with because it's just public keys). There is a solution with guix system by configuring openssh directly (see openssh-configuration -> authorized-keys), but there really should be a way to do this with guix home. (anyone that can call guix home for my user can see/modify my authorized_keys anyway) Maybe this bug should be renamed to something like "guix home cannot configure authorized_keys"?
bug#53752: guix home symlink permissions
I finally migrated my home configuration to guix home. However, it seems
guix home creates all symlinks with 777 permissions. This causes problems
with openssh as it will not recognize my ~/.ssh/authorized_keys. It seems
the directories have reasonable permissions (maybe because they already
existed?), but it seems like someone could in theory edit the symlinks
in-place (though I wasn't able to figure that out).
I formulated based on the example in Section 11.1 of the devel user
manual. You should be able to recreate the problem with (replacing ):
(home-environment
(services
(list
(simple-service
'my-home-files-service
home-files-service-type
(list
`("ssh/authorized_keys"
,(plain-file
"home-authorized-keys"
"")))
bug#53272: Password-store Not Building
Hi Guix! I've been having trouble updating for a couple of days because password-store won't build. I haven't seen others complain, and I think this package is widely used, so I'm a bit worried the problem is related to the fact that I haven't updated guix for some time... It fails with: command "make" "test" "CC=gcc" "PREFIX=/gnu/store/jyjm47609k160r2rcfaiwz3ncs0qjwry-password-store-1.7.4" "WITH_ALLCOMP=yes" "BASHCOMPDIR=/gnu/store/jyjm47609k160r2rcfaiwz3ncs0qjwry-password-store-1.7.4/etc/bash_completion.d" failed with status 2 full log attached. -Zacchaeus gi05zpfkpcrlliqvkm4v5qbj143d2c-password-store-1.7.4.drv.bz2 Description: application/bzip
bug#50897: Octave package installation
That certainly works as a hack. I ended up installing from source locally because I needed it to work now. It is strange that my local build didn't encounter this problem when all I did was grab the tarball, untar, cd in and >./configure --prefix=~/.local && make && make install which should be more or less equivalent to how guix builds it (build system is gnu-build-system). An octave-build-system is definitely a good idea, but the ability to install octave packages the "normal" way should probably be resolved first and preserved (just like you can still install emacs packages through (M)ELPA or through guix). -zacchae
bug#50897: Octave package installation
Hi Guix! After installing octave, I tried to install the image package in octave in two ways. One by running: > pkg install image-.tar.gz where image-.tar.gz is in my cwd. I also tried installing with: > pkg install -forge image In both cases, I had the same problem. The first error I was getting was: >configure: error: in `/tmp/oct-6RV451/image-2.12.0/src': >configure: error: C++ compiler cannot create executables This error can be fixed by installing gcc-toolchain. After doing so, attempting to install image gives: >ld: cannot find -loctinterp >ld: cannot find -loctave repeatedly (full output below). These libraries seem like they should be included in the octave installation, and also like they should be absolute paths. I looked for any instance of octinterp in filenames and found these in the octave install: ./include/octave-6.2.0/octave/liboctinterp-build-info.h ./lib/octave/6.2.0/liboctinterp.la ./lib/octave/6.2.0/liboctinterp.so.8.0.1 ./lib/octave/6.2.0/liboctinterp.so ./lib/octave/6.2.0/liboctinterp.so.8 ./lib/pkgconfig/octinterp.pc I tried installing image with these in my cwd, but no dice. Even if these are the correct library files, octave is installing this in my user directory so the cwd won't be the same. I need this to work for a class, so I'm willing to put in some hours (days) to make this work, but I'm pretty lost if anyone has ideas on where to go next. Thanks, Zacchae
bug#50858: Installing git-annex for aarch64 fails on ghc build
Hi Guix! I'm trying to install git-annex for aarch64, but it fails on the following line: \ 'configure-bin' phasebuilder for `/gnu/store/b6j0zdnbpdhx81npbk25m4nls5y1h3f5-ghc-7.10.2.drv' failed with exit code 1 I have attached the log for the failed ghc build. The first error there seems to be: /tmp/guix-build-ghc-7.10.2.drv-0/ghc-7.10.2/ghc-bin/ghc-7.8.4/utils/ghc-pwd/dist-install/build/tmp/ghc-pwd: cannot execute binary file: Exec format error Seeing as this works fine for x86, I'm guessing that a ghc-pwd is being used that was compiled for x86, maybe an error in setting up cross compiling? Thanks, Zacchae j0zdnbpdhx81npbk25m4nls5y1h3f5-ghc-7.10.2.drv.bz2 Description: application/bzip
bug#50788: Swapfile on Btrfs does not start at boot
Hi Brice,
Yes, setting "(needed-for-boot? #t)" did it for me. I agree that adding a
dependencies field for swap devices is the "correct" solution.
Thanks,
-Zacchae
On Sat, Sep 25, 2021 at 8:54 AM Brice Waegeneire wrote:
>
> Hello John and Zacchaeus,
>
> A month ago I open a thread in guix-devel titled “Using a swapfile on
> btrfs for
> hibernation”¹ describing in depth my setup about your specific issue but
> it had
> no response so far. It should be detailled enought for you to reproduce a
> similar setup and if not I would like your feedbakc on it.
>
> John Kehayias writes:
>
> > This has been discussed a few times on #guix, with some having success,
> but mostly it seems not. The issue is having a swapfile (maybe also for
> partition?) on Btrfs and swap not being activated on boot. In my case, I
> can manually start with `sudo herd start swap-/swap/swapfile` and it will
> work fine. There might be an issue with when different filesystems are
> loaded with Btrfs subvolumes? I have my swap as a file on a subvolume.
> >
>
>
> >>From syslog, just before and after the only "swap" related message:
>
> [...]
>
> > Checking the status of the service shows:
>
> [...]
>
> > This is the file-systems and swap part of my system configuration:
>
> Following are the same output as yours but from a working setup.
>
> --8<---cut here---start->8---
> # dmesg
> [...]
> [6.393304] shepherd[1]: Service udev has been started.
> [6.431318] Adding 32488200k swap on /swap/swapfile. Priority:-2
> extents:2 across:32706248k FS
> [6.433275] shepherd[1]: Service swap-/swap/swapfile has been started.
> [6.434347] shepherd[1]: Service user-file-systems has been started.
> [6.469352] shepherd[1]: Service file-system-/boot/efi has been started.
> [6.535679] shepherd[1]: Service file-system-/home has been started.
> [...]
> --8<---cut here---end--->8---
>
> --8<---cut here---start->8---
> # herd status swap-/swap/swapfile
> Status of swap-/swap/swapfile:
> It is started.
> Running value is #t.
> It is enabled.
> Provides (swap-/swap/swapfile).
> Requires (udev).
> Conflicts with ().
> Will not be respawned.
> --8<---cut here---end--->8---
>
> Here are the file-systems and swap-devices fields of my operating-system:
> --8<---cut here---start->8---
> (file-systems
> (append (list (file-system
> (mount-point "/boot/efi")
> (device (uuid "588A-2266" 'fat32))
> (type "vfat"))
> (file-system
> (mount-point "/swap")
> (device (uuid "2ab8e658-5878-4acd-ba33-8a46707a3828"
> 'btrfs))
> (type "btrfs")
> (needed-for-boot? #t)
> (options "compress=zstd,subvol=swap")))
> (hash-map->list
>(lambda (mount-point subvolume)
> (file-system
>(mount-point mount-point)
>(device (uuid "2ab8e658-5878-4acd-ba33-8a46707a3828"
> 'btrfs))
>(type "btrfs")
>(options (string-append "compress=zstd" ",subvol="
> subvolume
>(alist->hash-table '(("/" . "guix-system")
> ("/home" . "home")
> ;; ("/swap" . "swap")
> ("/mnt/btrfs-root" . "/"
> %base-file-systems))
>
> (swap-devices (list "/swap/swapfile"))
> --8<---cut here---end--->8---
>
> > Hope this is helpful in tracking down what is happening, I know I'm not
> alone in this issue.
>
> I think you are just missing “(needed-for-boot? #t)” on your swap
> subvolume,
> even tho you shouldn't need to have it mounted from the initramfs (except
> if you
> want to hibernate on your swapfile). On the thread previsouly cited¹, I
> suggest
> two new records “swap-file” and “swap-device” where it would make sense to
> add
> an additional “dependecies” field, similar to the one in ”file-system”
> record,
> which would list the “file-system” to be mounted before activating that
> swap
> file (or device).
>
> Hope it helps.
>
> ¹ https://yhetil.org/guix/87zgt9nrmg@waegenei.re/
>
> Cheers,
> - Brice
>
bug#50788: Swapfile on Btrfs does not start at boot
I have the same problem. I can start the swapfile normally with herd start swap-/swap/swapfile, but it fails to start at boot. Here are the (possibly) relevant parts of my system configuration: (mapped-devices (list (mapped-device (source (uuid "59d615e4-8a35-469c-aa24-88f28f084847")) (target "ex") (type luks-device-mapping (file-systems (append (list (file-system (type "btrfs") (mount-point "/") (device (file-system-label "ex")) (options "subvol=guix") (dependencies mapped-devices)) (file-system (type "btrfs") (mount-point "/swap") (device (file-system-label "ex")) (options "subvol=swap") (dependencies mapped-devices)) (file-system (type "vfat") (mount-point "/boot/efi") (device (file-system-label "EFI" %base-file-systems)) (swap-devices (list "/swap/swapfile")) Let me know if I should include more info. -Zacchae
bug#50592: Acknowledgement (Can't guix system init with grub-efi-bootloader from system that boots using grub-bootloader)
I should probably give some more details. Here is the bootloader config I'm using (bootloader (bootloader-configuration (bootloader grub-efi-bootloader) (targets (list "/boot/efi")) (keyboard-layout keyboard-layout))) My mounts look like: /dev/mapper/jake /mnt/jake # with -o subvol=guix /dev/mapper/jake /mnt/jake/swap # with -o subvol=swap /dev/sdb2 /mnt/jake/boot/efi I've been using the same system config without problem, and just changed the bootloader config to the above -zacchaeus On Tue, Sep 14, 2021 at 6:34 PM GNU bug Tracking System < help-debb...@gnu.org> wrote: > Thank you for filing a new bug report with debbugs.gnu.org. > > This is an automatically generated reply to let you know your message > has been received. > > Your message is being forwarded to the package maintainers and other > interested parties for their attention; they will reply in due course. > > Your message has been sent to the package maintainer(s): > bug-guix@gnu.org > > If you wish to submit further information on this problem, please > send it to 50...@debbugs.gnu.org. > > Please do not send mail to help-debb...@gnu.org unless you wish > to report a problem with the Bug-tracking system. > > -- > 50592: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=50592 > GNU Bug Tracking System > Contact help-debb...@gnu.org with problems >
bug#50592: Can't guix system init with grub-efi-bootloader from system that boots using grub-bootloader
Hi Guix! I'm trying to install guix to a new drive using my main machine which boots using grub-bootloader (legacy bios). I want to put grub-efi-bootloader (EFI) on the new drive install (for use on another computer). However, the install fails when running grub-install. The full output at the end is: copying to '/mnt/jake'... populating '/mnt/jake'... guix system: error: '/gnu/store/w8v5d1i6xfqlpj78w89jg1x7f8dchh4k-grub-efi-2.06/sbin/grub-install --boot-directory /mnt/jake/boot --bootloader-id=Guix --efi-directory /boot/efi' exited with status 1; output follows: /gnu/store/w8v5d1i6xfqlpj78w89jg1x7f8dchh4k-grub-efi-2.06/sbin/grub-install: error: /gnu/store/w8v5d1i6xfqlpj78w89jg1x7f8dchh4k-grub-efi-2.06/lib/grub/i386-pc/modinfo.sh doesn't exist. Please specify --target or --directory. I'm not sure if the fact that I'm currently booted in legacy bios mode is important, but the problem persists after a guix pull && guix system reconfigure, and I doubt grub-efi is broken for everyone. Thanks, zacchae
bug#49553: ARM installation
Hi bug-guix, I tried running: guix system image --system=armhf-linux -e '((@ (gnu system install) os-with-u-boot) (@ (gnu system install) installation-os) "aoeuthant")' And got two unexpected behaviors. First of all, I get the error: |builder for `/gnu/store/05njkp7140yzkik9c3r3imfj0jdj68k1-dhcp-4.4.2-P1.tar.xz.drv' failed with exit code 1 build of /gnu/store/05njkp7140yzkik9c3r3imfj0jdj68k1-dhcp-4.4.2-P1.tar.xz.drv failed View build log at '/var/log/guix/drvs/05/njkp7140yzkik9c3r3imfj0jdj68k1-dhcp-4.4.2-P1.tar.xz.drv.bz2'. cannot build derivation `/gnu/store/4nswzq8wdnj77z16v3gmjb2b31pphh7f-isc-dhcp-4.4.2-P1.drv': 1 dependencies couldn't be built guix system: error: build of `/gnu/store/4nswzq8wdnj77z16v3gmjb2b31pphh7f-isc-dhcp-4.4.2-P1.drv' failed (log attached here) According to https://guix.gnu.org/manual/en/html_node/Building-the-Installation-Image.html, specifying an invalid board (notice "aoeuthant" at the end of the command I tried) should print a list of possible boards. A list of possible boards was NOT printed, though it is possible this was caused by the first error, though I would expect a list of boards before it tries to make the image. -Zacchaeus njkp7140yzkik9c3r3imfj0jdj68k1-dhcp-4.4.2-P1.tar.xz.drv.bz2 Description: Binary data
bug#49297: zsh-autosuggestions build fail
Hi GUIX, I tried installing zsh-autosuggestions, but the build fails in three places on the same file when running rspec, all with the same discrepancy: >expected: "echo " >got: "echo aaa\na" I'm including the full log as well. Thanks, Zacchaeus Scheffer v3qmpzjvjcjg0ksgp2j57m3di86lbw-zsh-autosuggestions-0.6.4.drv.bz2 Description: application/bzip
