bug#70373: Bug in the download of the development İSOs

2024-04-14 Thread Felipe Lohan
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

2024-04-14 Thread Frederickson, Jonathan
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

2024-04-14 Thread Frederickson, Jonathan
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

2024-04-14 Thread hiecaq

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

2024-04-14 Thread wakyct--- via Bug reports for GNU Guix
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

2024-04-14 Thread hiecaq



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

2024-04-14 Thread Christina O'Donnell

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

2024-04-14 Thread Nathan Dehnel
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