bug#30434: magit won’t work over TRAMP
Op 21-09-2023 om 09:34 schreef Simon Tournier: Hi, This bug#30434 [1] had been closed on 14 Feb 2018 and then reopened on 18 May 2022. 1: https://issues.guix.gnu.org/issue/30434 On Thu, 21 Jul 2022 at 00:04, Maxim Cournoyer wrote: More concretely, try "guix shell emacs emacs-magit --pure -- emacs" followed by "M-x magit-status" in a Git checkout, it will fail due to not finding the 'git' executable. So my idea is to use the new magit changes to both make the remote TRAMP work and _also_ make local things work in a pure environment, undoing the regression that was caused by reverting the git->/gnu/store/.../bin/git substitution without creating new regressions. Sounds good to me! I'll be happy to review any patch implementing it. Now, we are 1 year, 17 weeks, 6 later after this message. So I propose to close this issue and then open another one for this potential patch. WDYT? The time since that message is irrelevant. The bug is still there, so there is no good reason to close it. If the point of closing unresolved bug reports is some kind of prioritization of bug reports, there's tags, severity levels, etc., you can use instead faking a high bug resolving statistics. Best regards, Maxime Devos. OpenPGP_0x49E3EE22191725EE.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature
bug#30434: magit won’t work over TRAMP
Op 23-09-2023 om 12:17 schreef Maxime Devos: Op 21-09-2023 om 09:34 schreef Simon Tournier: Hi, This bug#30434 [1] had been closed on 14 Feb 2018 and then reopened on 18 May 2022. 1: https://issues.guix.gnu.org/issue/30434 On Thu, 21 Jul 2022 at 00:04, Maxim Cournoyer wrote: More concretely, try "guix shell emacs emacs-magit --pure -- emacs" followed by "M-x magit-status" in a Git checkout, it will fail due to not finding the 'git' executable. So my idea is to use the new magit changes to both make the remote TRAMP work and _also_ make local things work in a pure environment, undoing the regression that was caused by reverting the git->/gnu/store/.../bin/git substitution without creating new regressions. Sounds good to me! I'll be happy to review any patch implementing it. Now, we are 1 year, 17 weeks, 6 later after this message. So I propose to close this issue and then open another one for this potential patch. WDYT? The time since that message is irrelevant. The bug is still there, so there is no good reason to close it. If the point of closing unresolved bug reports is some kind of prioritization of bug reports, there's tags, severity levels, etc., you can use instead faking a high bug resolving statistics. Wait, I misread -- feel free to open that new bug report. I assumed ‘open another one when that potential patch exists’ instead of ‘right now’. OpenPGP_0x49E3EE22191725EE.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature
bug#66168: zsh home service breaks guix shell via ssh
Hi, i set up a new system last weekend and am connecting to it via ssh. I also just recently started using guix home. I noticed that after connecting via ssh the profile that gets created when doing `guix shell' is not sourced, therefore the environment variables are not correct. This seems to be because guix home inserts "[ -n \"$SSH_CLIENT\" ] && source /etc/profile" into the zshenv file. I assume this is meant to ensure that /etc/profile is sourced because ssh does not start a login shell? Anyway, removing that line makes everything work normally. So am i doing it wrong or is this actually unnecessary? mfg²
bug#47543: “Repeated allocation of very large block” during ‘guix pull’
Janneke Nieuwenhuizen writes: Hi! Just a headsup with more information. > Ludovic Courtès writes: > >> If you experience it, please share the command line and command output! > > Never seen this before, but here it is... [..] > ./guix/store.scm:1036:9: ERROR: > 1. &store-protocol-error: > message: "error parsing derivation > `/gnu/store/2zb0lb5bkg5868vvwqi6a8nh07p23610-guix-6bd17a080-modules.drv': > expected string `Derive(['" > status: 1 This bit, i.e., the fact that `guix pull' failed, was due to store corruption. Something else that I've also never experienced before. > guix pull: error: You found a bug: the program > '/gnu/store/sv5bgbzisyii7g45c3bd3w8jk59gfvx0-compute-guix-derivation' > failed to compute the derivation for Guix (version: > "6bd17a0806ad32d1493ac51a7443276f719c4224"; system: "x86_64-linux"; > host version: "445a0359083388b5ee686e6e855f94a3aac5f79c"; pull-version: 1). > Please report the COMPLETE output above by email to . And on that last note, I wonder how apt this massage is, in this particular case running `guix gc --repair=content' would have been helpful. > This seems to be somewhat repeatable, it was the third time in a row > this failed. After the second time, I removed ~/.cache/guix/checkouts. After repairing the store, the `large block' warning was also gone. Greetings, Janneke -- Janneke Nieuwenhuizen | GNU LilyPond https://LilyPond.org Freelance IT https://www.JoyOfSource.com | Avatar® https://AvatarAcademy.com
bug#30434: magit won’t work over TRAMP
Hi, On Sat, 23 Sep 2023 at 12:17, Maxime Devos wrote: More concretely, try "guix shell emacs emacs-magit --pure -- emacs" followed by "M-x magit-status" in a Git checkout, it will fail due to not finding the 'git' executable. For one, this had been corrected by b59b033af3957e0de9a44733e26cbcc7114a4dfb, IMHO. For me, guix shell emacs emacs-magit --pure -- emacs -q -f magit-status just works. So my idea is to use the new magit changes to both make the remote TRAMP work and _also_ make local things work in a pure environment, undoing the regression that was caused by reverting the git->/gnu/store/.../bin/git substitution without creating new regressions. For two, as explained by [1], the case for TRAMP seems handled, no? >>> Sounds good to me! I'll be happy to review any patch implementing it. >> >> Now, we are 1 year, 17 weeks, 6 later after this message. So I propose >> to close this issue and then open another one for this potential patch. >> >> WDYT? > > The time since that message is irrelevant. The bug is still there, so > there is no good reason to close it. Your report (reopened a closed one) is about two issues. Which one is still there? One? Both? None? Having a clear fresh bug report for specific issue makes easier to deal with instead of a lot old thread mixing several issues where some had been already fixed. Somehow, it makes it hard to know what is currently still accurate and what is not, IMHO. > If the point of closing unresolved > bug reports is some kind of prioritization of bug reports, there's tags, > severity levels, etc., you can use instead faking a high bug resolving > statistics. The point is to have an actionable bug tracker and not some spaghetti thread where it is hard to follow between the still accurate and the already fixed. Ricardo opened an issue tracked as #30434. Subject: bug#30434: magit won’t work over TRAMP Date: Mon, 12 Feb 2018 13:53:22 +0100 (5 years, 31 weeks, 5 days ago) Closed by Mark with the message: Agreed. Done, in commit 5fe9ba59ba1cea12a70d011aacbace52e3bfda18 on master and commit 317e8e9404058af35d9843e076934560f95d895a on core-updates. I'm closing this bug now. Date: Wed, 14 Feb 2018 08:52:02 + (5 years, 31 weeks, 3 days ago) And the discussion ends on: Date: Fri, 16 Feb 2018 14:00:50 -0500 (5 years, 31 weeks, 1 day ago) Then, years later you unarchive and reopen. Date: Wed, 18 May 2022 15:36:02 +0200 (1 year, 18 weeks, 1 day ago) unarchive 30434 reopen 30434 directly followed by Maxim’s question: Why did you reopen that issue? Does the original problem still affect you (a hard-coded magit-git-executable causing problems when executed on remote machines via TRAMP). And this bug was still open just as a reminder waiting for your patch. The initial issue had been closed and what you are reporting is not an issue anymore, from my understanding. I am proposing to open a fresh issue with accurate information from current Guix revisions about what you consider is this bug – referencing to this one if needed. BTW, for what it is worth, I feel your tone arrogant and that is generating an atmosphere that does not make the collaboration friendly. Cheers, simon 1: [bug#59253] [PATCH] gnu: emacs-magit: Substitute git executable path. Kyle Meyer Mon, 14 Nov 2022 19:52:36 -0500 id:87cz9pvy23@kyleam.com https://issues.guix.gnu.org//59253 https://issues.guix.gnu.org/msgid/87cz9pvy23@kyleam.com https://yhetil.org/guix/87cz9pvy23@kyleam.com
bug#66169: guix reconfigure error no match for id 4f35ff1275e05be31f5d41464ccf147e9dbfd016
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. Roman $ sudo guix system reconfigure /etc/config.scm Password: Backtrace: In guix/ui.scm: 2286:10 19 (run-guix-command _ . _) In ice-9/boot-9.scm: 1752:10 18 (with-exception-handler _ _ #:unwind? _ # _) In guix/status.scm: 859:3 17 (_) 839:4 16 (call-with-status-report _ _) In guix/scripts/system.scm: 1278:4 15 (_) In ice-9/boot-9.scm: 1752:10 14 (with-exception-handler _ _ #:unwind? _ # _) In guix/store.scm: 659:37 13 (thunk) 1298:8 12 (call-with-build-handler # …) 2168:25 11 (run-with-store # …) In guix/scripts/system.scm: 1302:15 10 (_ _) 831:5 9 (perform-action reconfigure #< name: #f format:…> …) In guix/scripts/system/reconfigure.scm: 346:3 8 (check-forward-update _ #:current-channels _) In srfi/srfi-1.scm: 691:23 7 (filter-map # . #) In guix/scripts/system/reconfigure.scm: 353:39 6 (_ #< name: guix url: "https://git.savannah.gn…>) In guix/git.scm: 481:21 5 (update-cached-checkout _ #:ref _ #:recursive? _ # _ # _ …) 367:15 4 (reference-available? _ _) In git/commit.scm: 172:8 3 (_ # #) In git/bindings.scm: 77:2 2 (raise-git-error _) In ice-9/boot-9.scm: 1685:16 1 (raise-exception _ #:continuable? _) 1685:16 0 (raise-exception _ #:continuable? _) ice-9/boot-9.scm:1685:16: In procedure raise-exception: Git error: object not found - no match for id (4f35ff1275e05be31f5d41464ccf147e9dbfd016) signature.asc Description: This is a digitally signed message part
bug#66174: [BUG] poetry buil
Hey Guix! I've encountered the following error while trying to install poetry: phase `patch-generated-file-shebangs' succeeded after 0.0 seconds starting phase `build' error: in phase 'build': uncaught exception: misc-error #f "no setup.py found" () #f phase `build' failed after 0.0 seconds Backtrace: 9 (primitive-load "/gnu/store/3353b4wb8kf4kz6m70ph2p3w0iw…") In guix/build/gnu-build-system.scm: 908:2 8 (gnu-build #:source _ #:outputs _ #:inputs _ #:phases . #) In ice-9/boot-9.scm: 1752:10 7 (with-exception-handler _ _ #:unwind? _ # _) In srfi/srfi-1.scm: 634:9 6 (for-each # …) In ice-9/boot-9.scm: 1752:10 5 (with-exception-handler _ _ #:unwind? _ # _) In guix/build/gnu-build-system.scm: 929:23 4 (_) In guix/build/python-build-system.scm: 148:2 3 (build #:use-setuptools? _) 135:6 2 (call-setuppy "build" () #t) In ice-9/boot-9.scm: 1685:16 1 (raise-exception _ #:continuable? _) 1685:16 0 (raise-exception _ #:continuable? _) ice-9/boot-9.scm:1685:16: In procedure raise-exception: no setup.py found builder for `/gnu/store/rh4nyw96hfli8lnn45rp18nnaz290lil-poetry-1.4.2.drv' failed with exit code 1 build of /gnu/store/rh4nyw96hfli8lnn45rp18nnaz290lil-poetry-1.4.2.drv failed View build log at '/var/log/guix/drvs/rh/4nyw96hfli8lnn45rp18nnaz290lil-poetry-1.4.2.drv.gz'. guix package: error: build of `/gnu/store/rh4nyw96hfli8lnn45rp18nnaz290lil-poetry-1.4.2.drv' failed
