Re: Automatic tagging of unanswered issues in mumi

[Cayetano Santos]

> mumi now automatically tags unanswered issues.

Thanks for the latest improvements ! Mumi really helps a lot.

I’m just wondering if the help page up to date with most recent hints.

https://issues.guix.gnu.org/help

C.


signature.asc
Description: PGP signature

Re: bug#76503: [GCD] Migrating repositories, issues, and patches to Codeberg

[Vagrant Cascadian]

On 2025-03-14, Ludovic Courtès wrote:
> Vagrant Cascadian  skribis:
>> Is there duplication of issues? Yup. Sometimes one needs to get
>> forwarded to the other manually. Whee.
>>
>>
>> Do issues get automatically closed on both systems? Usually, if you
>> remember to include the right incantations in your commit messages!
>> Occasionally even if you forget, what magic is that?!
>
> Wait, are users told they can report bugs not just to Debbugs but also
> to salsa.debian.org?  (Back when I used Debian, email, possibly via
> ‘reportbug’, was the only way to report bugs.)

I suspect your days with Debian predate salsa.debian.org by wide
margins. :)

Not sure what users are told these days!  I definitely get issues, bugs,
patches, etc. on both systems for most of my packages. Sometimes I get
issues which point to a prior submission on the other system.


> In practice, would you say that there’s a group only paying attention to
> salsa and another one only paying attention to Debbugs?  Or is it less
> clear-cut than that?

I think there are both maintainers, contributors and other users paying
more attention to one or the other system... and to be honest, there are
maintainers that seem to pay attention to neither! It seems largely up
to individual preferences (and the intersection of multiple parties
preferences). I cannot say I get a sense of a "type" of user using one
or the other system.


>> I do feel, given what I have heard from several people in this
>> discussion, that proposing a flag day with a short time of overlap is
>> going to be very hard for this community, and possibly more divisive
>> than whatever fracturing we might encounter by maintaining two
>> concurrent technical systems over an extended time period...
>
> Note that, as currently worded, the flag day is only for new bug reports
> and patches; if we were to adopt it as-is, we’d continue using Debbugs
> for months or years to process the backlog.
>
> It wouldn’t be as sharp a transition as it may seem.

That seems like a reasonable plan to a large extent, though I still get
the sense that there are some people who would like it to last
considerably longer.

Might be worth spelling out the various tradeoffs of what it would
require for a short, medium and long transition; I am not really sure
what they are off the top of my head...

From my personal experiences with Debian, it looks to me possible to do
both systems for a long time, but the extent of the downsides are
unclear to me.


live well,
  vagrant


signature.asc
Description: PGP signature

Re: Automatic tagging of unanswered issues in mumi

[Arun Isaac]

Hi Cayetano,

> I’m just wondering if the help page up to date with most recent hints.
>
> https://issues.guix.gnu.org/help

The help page is technically up-to-date since I haven't changed that
interface. However, the help page could be improved significantly by
adding examples of real-world everyday queries people might use. I'll do
that soon. You can help it happen sooner if you reply to this thread
with some concrete examples. :-) I don't need a patch, just text I can
work with. It's always helpful to have these examples written by users
so they are representative of what users actually want to do.

Regards,
Arun

Re: Contribute to Guix

[Gabriel Santos]

Em 13 de março de 2025 20:49:01 BRT, "João Mauricio"  
escreveu:
>Hello!
>My name is Joao Mauricio, I am a developer from Brazil
>I want to contribute to the gnu project in some way and I found out about 
>guix, which is a project that attracted me a lot as I loved its goals. As a 
>developer my main goal is to contribute in this project through actual code, 
>it can be maintenance, developing or solving small issues, I see it as a great 
>experience and I would love to be part of this project.
>Please answer this email about what I can do to start and what is needed.
>
>best regards.

Olá,

Leia este trecho do manual:



Pode parecer muito, mas basicamente você terá que clonar o repistório no 
Savannah
(), fazer suas
alterações e depois enviar o patch por e-mail. Você pode enviar e-mail
usando o próprio git:



Recomendo também que você leia sobre etiqueta de e-mail:



É recomendado que você quebre linhas a cada ~70 caracteres, sem
separar palavras.

Problemas podem ser encontrados em:



Espero ter ajudado!

Atenciosamente,

--
Gabriel Santos

--

English translation:

Hello,

Read this part of the manual:



It may seem like a lot, but basically you'll have to clone the
repository in Savannah, make your changes and then submit the
patch by e-mail. You can send the patch using git itself:



I also recommend you read on e-mail etiquette:



It's recommended for one to break lines every ~70 characters,
without separating words.

Issues can be found in:



Hope I could be of help!

Regards,

--
Gabriel Santos

guix pull from private ssh server

[Christoph Buck]

Hi Guix!

I hope you have a good day!

The other day i ran into a problem as i was pulling a guix channel from
my private ssh server secured by pubkey authentication.

The channel file looks like this:

 > (channel
 >   (name 'grimbard)
 >   (url "ssh://t...@xx..xx:/srv/ssh/guix/grimbard.git")))

Pulling this channel via `guix pull -C channel-file.scm` results in the
following error on client side:

> $ guix pull -C ~/channels.scm
> Updating channel 'grimbard' from Git repository at 
> 'ssh://t...@xx..xx:/srv/ssh/guix/grimbard.git'...
> guix pull: error: Git error: failed to start SSH session: Unable to exchange 
> encryption keys

And the following error on server side:

> Unable to negotiate with x.x.x.x port 34589: no matching host key type found. 
> Their offer: ssh-rsa [preauth]

Googling around i found the excellent post from Matthew on the help-guix
mailing list [1] which lead me to a possible solution for the problem.

As Matthew already described in his post this error is most likely due
to the fact that libssh2 is compiled with crypto backend libgcrypt which
causes it to disable certain hostkeys and leaves only the
deprecated "ssh-rsa" option available for libgit2. Unfortunately
enabling "ssh-rsa" keys explicitly on server side via
`PubkeyAcceptedKeyTypes` as a workaround does not work.

To fix this problem i bumped the libssh2 version number from 1.10.0 to
1.11.1 and changed the crypto backend (as suggested by Matthew) to
openssl (see the attached patch).

Building in a fresh container environment:

> ./pre-inst-env guix describe
> Git checkout:
>   repository: /home/icepic/guix/src/guix/
>   branch: master
>   commit: 98f29906912d03d499c48b0bd0a1aa384ea23fb2
> ./bootstrap && ./configure --localstatedir=/var
> make clean-go
> make
> ./pre-inst-env guix build guix
> [...]
> successfully built 
> /gnu/store/x2m0q1f17vg63z93khv8icncshg7s7hq-guix-1.4.0-34.5058b40.drv
> /gnu/store/pn67qhlg0qqs945p5m1ssqacx35g5hj5-guix-1.4.0-34.5058b40

and then installing the guix command in a temporary profile does indeed
fix the problem:

> guix package --profile=/tmp/libssh2 --install 
> /gnu/store/pn67qhlg0qqs945p5m1ssqacx35g5hj5-guix-1.4.0-34.5058b40
> /tmp/libssh2/bin/guix pull -C ~/channels.scm
> Updating channel 'grimbard' from Git repository at 

Server side:
>Accepted publickey for test from x.x.x.x port 50052 ssh2: RSA 
>SHA256:xx

Is this a viable patch? Obviously this causes a additional dependency
for guix but as far as i can tell from stracing, guix was dependend on
openssl anyway.

A small problem which Matthew already mentioned is, that the tests for
libssh2-1.11.1 are currently failing (therefor the append patch disable
the tests for now). From what i saw this is due to the fact the tests
pull in docker in order to simulate an ssh connection. If we want to go
forward with this solution i would look into it and create a merge
request on debuggs.

Looking forward for feedback!

Best regards

Christoph 

[1] 
https://yhetil.org/guix-user/0b9479a3-abd7-4ccf-a8e7-214b34d83...@app.fastmail.com/
-- 
Best regards

Christoph Buck 

GnuPG key: https://web.icepic.de/public_key.txt
FingerPrint: B43F 4D2B 2017 E715 36C0  03C6 B8BB BCDE CD00 3305

>From 6e0ae2fb5c184b02c054ea0822abeb87f85b0864 Mon Sep 17 00:00:00 2001
Message-ID: <6e0ae2fb5c184b02c054ea0822abeb87f85b0864.1741969386.git@icepic.de>
From: Christoph Buck 
Date: Fri, 14 Mar 2025 17:21:20 +0100
Subject: [PATCH] Update libssh2 to version 1.11.1 and change crypto backend

Change-Id: I1571c4d4a9a78af8009d4e5c2ed26d22aa7be77f
---
 gnu/packages/ssh.scm | 11 ++-
 1 file changed, 6 insertions(+), 5 deletions(-)

diff --git a/gnu/packages/ssh.scm b/gnu/packages/ssh.scm
index fecb3a2559..ec3bec561c 100644
--- a/gnu/packages/ssh.scm
+++ b/gnu/packages/ssh.scm
@@ -181,7 +181,7 @@ (define-public libssh
 (define-public libssh2
   (package
(name "libssh2")
-   (version "1.10.0")
+   (version "1.11.1")
(source (origin
 (method url-fetch)
 (uri (string-append
@@ -189,14 +189,15 @@ (define-public libssh2
version ".tar.gz"))
 (sha256
  (base32
-  "0l8xwhhscvss7q007vpbkbv7jh9s43579rx2sf8lnfgd7l7yjr1d"
+  "1xsqysmrq40gdfjndd1yrcvwic16kn4jrzir6pn8xfadwg5pdv6r"
(build-system gnu-build-system)
;; The installed libssh2.pc file does not include paths to libgcrypt and
;; zlib libraries, so we need to propagate the inputs.
-   (propagated-inputs (list libgcrypt zlib))
+   (propagated-inputs (list openssl zlib))
(arguments
-(list #:configure-flags #~'("--with-libgcrypt"
-"--disable-static")))
+(list #:configure-flags #~'("--with-crypto=openssl"
+"--disable-static")
+  #:tests? #f))
(synopsis "Client-side C library implementing the SSH2 protocol")
(description
 "libssh2 is a library intended to allow software 

Re: bug#76503: [GCD] Migrating repositories, issues, and patches to Codeberg

[Ludovic Courtès]

Hello Guix!

It’s been one month since this GCD was submitted, which means there’s
only (only?) one month left! Thanks to everyone who contributed to the
discussion so far, it’s good to have this diversity of viewpoints and
experiences.

For the remaining time, I think we should focus on finding what it would
take to reach consensus on a variant of this proposal sharing goals
along the lines of those stated in the intro:

  The contribution workflow in Guix has been facing several challenges:
  difficult onboarding, lack of legibility, complex, unreliable, and
  labor-intensive infrastructure, and lack of automation.  All these lead
  to an experience that contributors often find frustrating and hinders
  quality assurance efforts.  We propose to address these limitations by
  migrating repositories, issue tracking, and patch tracking to Codeberg,
  a “modern” forge hosted by a non-profit.

If you brought up ideas or concerns, consider submitting a patch against
the existing proposal; what would you change to the text?

Please make sure to take a step back, taking into consideration the
experience we have collectively (with Codeberg and other forges, with
migrations, with free software project workflows, etc.) and what sounds
desirable for the project’s future, putting aside personal preferences
and short-term issues for a moment.

I’m confident we can find common ground!

Ludo’.

Re: Guix on the MNT/Reform

[Vagrant Cascadian]

On 2025-03-13, Vagrant Cascadian wrote:
> Just pushed a "wip-linux-libre-arm64-mnt-reform" branch that contains a
> kernel for the MNT/Reform family of systems.
>
> I have successfully built and booted a linux-libre-arm64-mnt-reform@6.12
> kernel on a "MNT Reform2 with RCORE RK3588 Module" ... running Debian, I
> know... but Guix System cannot be too far off!

Not far off at all, turns out! Pushed an example config to the
wip-linux-libre-arm64-mnt-reform branch!

Ethernet, USB, keyboard, trackball, and built-in display all seem to
work. Have not tested HDMI or sound output yet.

Running sway desktop with librewolf just fine.

Downside is I have not yet figured out how to get u-boot to boot
directly off of NVMe, so I have to manually copy all the relevent files
for /boot over to an SD or eMMC every time I generate a new system
generation...

  https://issues.guix.gnu.org/48172

Fixing that properly would allow for encrypted rootfs or other similar
fun!


> In theory it also supports the other MNT Reform platforms, but I have
> not tested!

If anyone has one of the other MNT Reform variants, testing those would
be nice.  I technically also have an imx8mq module, but not really eagre
fuss with switching back and forth.


> The whole patch is 1.2MiB, so on the ugly large side, but I think there
> are some ways we could get that down to a quite reasonable size patch by
> getting the patches from an upstream git repository as an input or
> whatever(rather than dumping them all into gnu/packages/patches/), if
> someone could help with that? :)

Still could use help with getting the patches handled better before
submitting to be reviewed and eventually merged into master.


live well,
  vagrant


signature.asc
Description: PGP signature

Contribute to Guix

[João Mauricio]

Hello!
My name is Joao Mauricio, I am a developer from Brazil
I want to contribute to the gnu project in some way and I found out about guix, 
which is a project that attracted me a lot as I loved its goals. As a developer 
my main goal is to contribute in this project through actual code, it can be 
maintenance, developing or solving small issues, I see it as a great experience 
and I would love to be part of this project.
Please answer this email about what I can do to start and what is needed.

best regards.

Re: bug#76503: [GCD] Migrating repositories, issues, and patches to Codeberg

[Ludovic Courtès]

Hi Vagrant,

Thanks for sharing your experience, it’s definitely relevant!

Vagrant Cascadian  skribis:

> Is there duplication of issues? Yup. Sometimes one needs to get
> forwarded to the other manually. Whee.
>
>
> Do issues get automatically closed on both systems? Usually, if you
> remember to include the right incantations in your commit messages!
> Occasionally even if you forget, what magic is that?!

Wait, are users told they can report bugs not just to Debbugs but also
to salsa.debian.org?  (Back when I used Debian, email, possibly via
‘reportbug’, was the only way to report bugs.)

In practice, would you say that there’s a group only paying attention to
salsa and another one only paying attention to Debbugs?  Or is it less
clear-cut than that?

> I do feel, given what I have heard from several people in this
> discussion, that proposing a flag day with a short time of overlap is
> going to be very hard for this community, and possibly more divisive
> than whatever fracturing we might encounter by maintaining two
> concurrent technical systems over an extended time period...

Note that, as currently worded, the flag day is only for new bug reports
and patches; if we were to adopt it as-is, we’d continue using Debbugs
for months or years to process the backlog.

It wouldn’t be as sharp a transition as it may seem.

Ludo’.