bug#70373: Bug in the download of the development İSOs
Hi, My name is Felipe Lohan. Lately, accessing the Guix’s website, when trying to download the latest successful build of the development İSOs (in https://guix.gnu.org/download/latest/), İ’m receiving an error regarding the JSON: «Could not find the requested build product». İ’m sending the screenshot as an attachment. Regards, Felipe Lohan ***😎[Standard Signature / Assinatura Padrão]😎*** Cheers. At your disposal, →Fortes abraços. À sua disposição, Felipe Lohan Pinheiro da Silva ([İnhabitant of the Xanderkistan / Habitante do Xandaquistão]) *** Dear NSA spies that must be eavesdropping on this e-mail, consider stopping spying on people and joining the Free Software Movement. →Caros espiões da NSA que devem estar espionando este e-mail, considerem parar de espionar as pessoas e se juntarem ao Movimento do Software Livre. *** 🦅Vincit Omnia Veritas🦅 ([The truth defeats everyone / A verdade vence a todos]) -BEGIN PGP PUBLIC KEY BLOCK- mQINBGVCFK8BEAC+kAtOwf68LumrQpVXBwDO4mvmXO7yM2FJCSu+sLsN6ouYfOoV ptMzIMXunPClZzszYqsJMHa03jrfVJP3H0Ih6kVmqtPbrpqJ3QAn7aq4ZnWOUSsC xVPTvNGZYU9V55Amw/r+Vo+WgOVlSR/5tANMYkjJcJG5Ka0Jnu9u4MMPuhNGwhfU EbQJRlAKBR+cD+ZH6fPj7MUs+FQC5lgmFdT8JwOty4RkAJuTd+xS0hP7PgyF1dbm +tYfiC0L0Pg+bmv+lOeU3Pk2QSb2eD7+ZVKqqlgcZs0z4i0ZgTU8D0MBq6dxnZvX IcVTaLW3qLYKkHisyQfEecv0rAhCmS04k7C7oHN/hSzgSjUkBHz/91JOOahIfBtS 23V7qqD75v+UNJFVdHEHP/m0vO/t1P63RP1r+grcbc0FjHkn68e4J+4N0I6F+GQA GA8VK7VA8nKHrmIIKcBNPz1xu9NNWOfR4wWIFKHy3aWR9yT4+fvXzH8uxKaICYQU K7hKg+Lmoj/cRSVs2WFlCscmYTLgOjpdAHqh9RzhtVWm93M33sNaJBbYCIHI0L9y 14G3NuXrxS9wbuoaH/k1JgV3qlO2/mSDnb4qT0X87DujflRNytYwnk/SH9i8sGAe bTXoV++K95tSIgGrF3gFnOxkVGQM1V9qr5WX2dSdim4z0c9S6dyd5Eh1nQARAQAB sAwAAGdwZwEAAAC0NkZlbGlwZSBMb2hhbiBQaW5oZWlybyBkYSBTaWx2YSAo VmluY2l0IG9tbmlhIHZlcml0YXMuKbAMAABncGcCiQJOBBMBCgA4FiEE L+7sUSMMWj0z+gNXX7yiNivgn+QFAmVCFK8CGwMFCwkIBwIGFQoJCAsCBBYCAwEC HgECF4AACgkQX7yiNivgn+R+hQ//ZQpPsDC3O1jjQcq9GHuhZxmmMcwjz1nuMIop 8obdgjBnBgs1WnUi8YPo3LG3bGPNJsELNL6aV7bqbYHG/v1GkyhUwhVRieYlfjcd ui4EPIuoWa0/ErPmfDCvslAEATjHNf+YlU2Kiwq3sCdlH82RcAAO6zRW9wuCFc0l Ed+TQ5+ebOJdsIV0TDS3hnR6oRbU0rOfyRERxCPSiq7p9b/VPMw0JwoSmR1HUN1U 9uGID9ARA6U7dKOi40uGHHBgbqwnBlGkuGfFP1POtSJVo+t74wQYd3hZCoM1XTk0 Tj87pTYeaJXtdM6JbfyZSF3KZssB2FYu1ymJJwTIAuUvL4otFRicV7n3/eD+XT+0 808e+sVEliF54b+F6td9BdbuI5xXZ6vJKSImnNrVI3tZs38LxAtAqpsUbwodAfVB XrvxvH5+53wDPRQb1yz68s97x1kkpUnSPq3gU2bhye3yf0HDq4UI7jf349ZSIXyl ON6HMOrJ47PF/LkASwCX+3PB8yYKibrhyIo8Y5wLbLLHZX9EzfQxqkVXN9O9rRS/ 0N/KComXjvadQxwk4YMUgFUAScaoZb2wR60erPIwWRz4lKcXm2eJ36pzXd6iquUZ Lft++0ZMHAXjnTCnugr0Rm1CQdUH865qbSI971D5gfC3N5GQE4w7E/61bVpXN6OF Sz35hKywBgAAZ3BnALkCDQRlQhSvARAA3d0IgCQ6Jj+frg05ivGKucDWRliyDZzp bnaNVr3Oaf1t4u0bNDT59CczTpguYOetd5FSwvNeGMfzBd3FJRnngVY8wslECXMp tfFTXRcvE0CL0LUob21IhvbzPFIF5yEw6k95uhLvE7vdDxpCb2/ZhNIE1opx38wu hkn4IvTwTAGdqw5VYLs5m41RLy3Y5wzcMZjZ3z/a6gr/Hfk8hDdpyuAl/hoxrUCm b6ha3pxu5nc6Lw2BRPezWd9CPITrd11ne55YtAydxZVqZ1Ae/iX7jIi1qINb2X6P CUU4J9OEdOMNezIjSgXvLvjxkB862kLrxOPbBYMmO+BzFS9NBM7W53dCsKi04Nti 8oxOe0F7Vem0SmmlG3uoePB0xI2mWWcMI6crTREG6L9Ds3wA6Sg4qZsj23vcdgJc phiQU32GhkQVG5N1dgndtoBjcMw/eluipbJ+94dI7p2OQK5cUlGWcGyQ0HPoainp o3R4cBbWIrMsZnxDPL7730t1w/WEuYNuptTfpfovOg4XkHhbv5VGOyBxIzC08lGg 6+u6drduaP0vKzM+OW52t3/CBqsI1fSaOuAsWSedGQOa62bFP7HTTjWwiDTGBBLo 2NLERbf9nl9f3uEqWi4QCPjPyM6JWNMMyg7bwpAFQYZQMm0S1g4PNe2MTMUPQOBv Ds96vXlBSPEAEQEAAYkCNgQYAQoAIBYhBC/u7FEjDFo9M/oDV1+8ojYr4J/kBQJl QhSvAhsMAAoJEF+8ojYr4J/kzGMP/ioMlBJnE8nwq96Uu8UpWMpzvyNIu9IHo9Ry jMCbVfDiz7/js4njLn8ujOq6R66YnU5BAkV2kSyi3ZMlDlwnc1fiS/aZbHIhpKdU JJd3MTmvlz7aztVGmDpgexBah4GDqW+GDXrp4kknQYrBZRkjk18LL8MT73PyNkmt E2kp68bZO/MKEgG8NlfLJ/n/9acgv1sJLYxpfAZYvZDdaOkCfvRWuwPTXkuqW4nc 2iMqDczKo+BU/zHmSZGDTmhhNBHRRPR8wuzh34r0xilnBLGrxYGVqe/b6CAyDnu6 4oghp+r8rXTmoIfqaMyPgTPN5fhmYwdRDiMoYzcNyic9abFdYnkzR9ApZxdOaswo k+KUpl5SHQwdChNorGWueiD6DaNThk7jBtmYyu0ekeBtWbw7t9QGlESytYw3LrlF EVN35VKADsdd0928f7mGOT05LMgc2npyTf7+Ix5UBBmbqqcz6NQUgSYKfZL/tK3/ rmrMrzMVDm0MIcDEi28znVsFerjry28D9nO+CoiHIgPwqJRd5k3nL9Ojoh1TkpMx biUl75TiAvv9cK9uLGRi5EmBCXD2SsbFPjeLAUqwBwQqzd2EELUW2QJSN+DqvjdC ExgIQaBok9dRa6K3JoDyAYmPOeYMnO9nu4gxhbL1yHS99D0zGXohOLNOca0dBVc3 amkXLUEQsAYAAGdwZwA= =nUiy -END PGP PUBLIC KEY BLOCK-
bug#70034: Hostkey error when pulling or building from private git repository
I just ran into this issue as well. I spent some time bisecting last night and tracked it down to a change in guile-git's dependency on libgit2: 9f00975f55e569fc3ba204fc34261a942a19b4e5 is the first bad commit commit 9f00975f55e569fc3ba204fc34261a942a19b4e5 Author: Ludovic Courtès Date: Mon Feb 26 22:15:57 2024 +0100 gnu: guile-git: Depend on libgit2 1.7. * gnu/packages/guile.scm (guile-git)[inputs]: Replace LIBGIT2-1.3 with LIBGIT2-1.7. Change-Id: Ia386f977b0888b7bd9b26443ac6150428fda2155 gnu/packages/guile.scm | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) smime.p7s Description: S/MIME cryptographic signature
bug#70034: Hostkey error when pulling or building from private git repository
It looks like this is https://github.com/libgit2/libgit2/issues/6612 And one of the comments on that issue from the libgit2 maintainer made me realize there's a workaround. Using github.com as an example since the initial report was having trouble with a channel on github, if you run this: $ ssh-keyscan github.com >> ~/.ssh/known_hosts ...it seems to fix the issue, because ssh-keyscan fetches host keys of all types from the remote host, rather than just one (as seems to happen when you connect to a remote host via SSH normally). Obviously would prefer a proper fix, but this is a relatively low- impact workaround for now. smime.p7s Description: S/MIME cryptographic signature
bug#70211: emacs-eglot fails after upgrade to emacs-29.3
Lilly via Bug reports for GNU Guix writes: Hi, after upgrading to emacs 29.3 eglot fails to start with an error message like Invalid slot name: "#eglot-lsp-server-cacbec>", :events-buffer-config This also happens if I start emacs with 'emacs -q' and activate just eglot manually. I'm using not the build-in eglot package, but emacs-eglot@1.17. This package has a dependency to emacs-jsonrpc@1.0.23 Upgrading jsonrpc to version 1.0.25 solved the issue for me. Yours, Lilly I also encountered this on my Guix configuration (on a foreign distro). I tried to investigate into it, but I got confused. The error message I got is: slot-missing: Invalid slot name: "#eglot-lsp-server-170231c>", :events-buffer-config However, events-buffer-config (it is defined in jsonrpc-connection, and eglot-lsp-server inherits that if I read correctly) is introduced in jsonrpc.el at e0b9944b69ff72923c29756fcfcea9528a3f5069, which is included in 1.0.23.
bug#70258: FreeCAD dependency probably outdated
I've also tried building pivy 0.6.8 against an updated soqt (1.6.2) but get similar errors. Any idea what needs to be upgraded here to make pivy build?
bug#70211: emacs-eglot fails after upgrade to emacs-29.3
Lilly via Bug reports for GNU Guix writes: Upgrading jsonrpc to version 1.0.25 solved the issue for me. Hi, the above solution does not work for me so I tried to dig into the problem further, and I think I've moved closer to the real cause of this problem. TLDR: This issue is more close related to jsonrpc instead of eglot, and putting (setq load-no-native t) In early-init.el fixes the problem for me. The first thing I noticed is that if we look up "jsonrpc-connection", Help page tells us that it is a native-compiled function, which is the hint to my following attempts because in my configurations packages are only byte-complied and not native-compiled, while built-ins are native-compiled. This can be quickly checked if you open the jsonrpc.elc file. (and I believe that it is the same case for the upstream Guix) Also, if you visit the "jsonrpc-connection"'s class Help page, it shows that it does not have a slot named "events-buffer-config". Instead it has "events-buffer-scrollback-size", which reflects the corresponding file in 29.3 built-in. So my guess is that Emacs somehow prefers the native-compiled version (from the built-in) over the byte-compiled version (from the package), even if the latter is newer. I do have "(setq load-prefer-newer t)" in my early-init.el, but it still works that way. I'm not sure why the package loading works as expected before recent updates in Guix though.
bug#68359: Can't pull my channel because of, getaddrinfo -8 error
Hi Simon, Paul, I've also run into this bug and I believe it is due to the error being cached. This is clearly undesirable so this issue should stay open until that is resolved. My reasoning for thinking it is a cache issues is: - An issue with package transformations should never cause an getaddrinfo error as Guix generally only goes up to servers for channels and build packages. - I ran into this after my gitlab instance had some outage, and persisted since my server came back up. - Pulling from a duplicate ref with the same hash succeeds, indicating that the bug occurs before the checkout is fetched. I'm happy to have a stab at working on this. Currently working on reproducing this, it's not as simple as making the channel url point at a closed port (eg. https://localhost:1212). I even tried binding a SCTP server to the port, but I just get connection refused. Anyone have any ideas about this? Should the title be changed to something like "Guix can cache getaddrinfo failures on `guix pull`"? (.. on the assumption that I'm proven right ;-) I'll assign this to myself, if there are no objections. Kind regards, Christina
bug#70376: killing guix hangs shell
If I ^C a running guix command, this weird thing happens where it causes bash to become unresponsive, and I have to kill the terminal. Does not happen with commands besides guix. guix 5a95cf7