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

2025-02-18 Thread Leo Famulari
On Wed, Feb 19, 2025 at 02:12:40AM +0100, Denis 'GNUtoo' Carikli wrote:
> This doesn't take care of existing repositories, and it is possible to
> handle that as well but the way I know does require practical control
> over the infrastructure (there may be better ways though that works
> without ssh access):
> 
> $ git checkout origin/master -b temporary
> $ git push origin HEAD:main
> $ ssh root@server
> $ cd /path/to/repository.git
> $ git symbolic-ref HEAD refs/heads/main # Change the main branch
> $ git symbolic-ref refs/heads/master refs/heads/main # Make master point to 
> main
> 
> I did it on many Replicant repositories for instance, and it's 100%
> transparent to the users. With that, new clone of the repositories use
> main by default.

Nice, thanks for sharing these tips!



Re: bug#65974: [PATCH 00/33] thirty something go packages

2025-02-18 Thread Tobias Geerinckx-Rice
Hi Sharlatan,

JSYK, you're sending encrypted messages to lists.  See 
.  I think this is the second one I've 
seen, so something's misconfigured on your end.

Kind regards,

T G-R

Sent on the go.  Excuse or enjoy my brevity.



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

2025-02-18 Thread Denis 'GNUtoo' Carikli
On Wed, 12 Feb 2025 11:44:42 +0100
Ekaitz Zarraga  wrote:
> [...] in Git there's no slave.

Personally I find 'main' more accurate precisely because of that.

Git enables to more easily maintain branches (not necessarily in the
same repository) with modifications on top, and/or to diverge, and so
for me using 'main' also convey the idea that people can legitimately
use other branches as well, especially because more than one meaning of
master don't really encourage that ('master copy' and/or power
relationship, though the later is more for the noun than the adjective).

There is also this wording in the manual for the main channel, and here
too the Guix utilities and daemon can also be reused with alternative
repositories (even replacing the main one as I understand, though I'm
unsure if anybody tried that).

In both cases using a more accurate word can empower the users and
promote practical freedoms.

Denis.


pgpdq1PrhUExL.pgp
Description: OpenPGP digital signature


Re: Re: [GCD] Rename “main” branch

2025-02-18 Thread Sharlatan Hellseher

This thread reminds me RFC1925 https://www.rfc-editor.org/rfc/rfc1925
"The Twelve Networking Truths" <1996-04-01>.

^.^

Oleg


signature.asc
Description: PGP signature


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

2025-02-18 Thread Denis 'GNUtoo' Carikli
On Thu, 13 Feb 2025 13:15:01 +0100
Liliana Marie Prikler  wrote:

> Am Donnerstag, dem 13.02.2025 um 10:30 + schrieb Attila Lendvai:
> > > Here's my perspective: it will cost us basically nothing to rename
> > > the master branch,
> > 
> > i suspect you'd be surprised how many places will need to be touched
> > until the whole infra is back on track after such a rename...
> > 
> > e.g. consider just the "bootstrapping" of this rename:
> > 
> > if you simply rename the branch, then people won't be able to guix
> > pull after the rename.
> > 
> > if you keep two branches, then for how long until no users are left
> > who will attempt to guix pull using an unprepared guix binary?
> > 
> > or should we add code to guix preemptively that can deal with both
> > the pre and post rename environment? then have a grace period before
> > the rename? for how long?
> Consider these steps:
> 
> 1. Create 'main', following 'master'.
> 2. Push a commit that makes 'main' the branch of
> %default-guix-channel. 
> 3. Push that commit to both 'master' and 'main'. 
> 4. Lock master on said commit.

This doesn't take care of existing repositories, and it is possible to
handle that as well but the way I know does require practical control
over the infrastructure (there may be better ways though that works
without ssh access):

$ git checkout origin/master -b temporary
$ git push origin HEAD:main
$ ssh root@server
$ cd /path/to/repository.git
$ git symbolic-ref HEAD refs/heads/main # Change the main branch
$ git symbolic-ref refs/heads/master refs/heads/main # Make master point to main

I did it on many Replicant repositories for instance, and it's 100%
transparent to the users. With that, new clone of the repositories use
main by default.

Denis.


pgpjLYUq4tLOZ.pgp
Description: OpenPGP digital signature


Re: [GCD] Set search paths without program wrappers

2025-02-18 Thread Simon Tournier
Hi 宋文武,

On Sun, 02 Feb 2025 at 12:57, 宋文武 via "Development of GNU Guix and the GNU 
System distribution."  wrote:

> title: Set search paths without program wrappers
> id: 003
> status: draft
> discussion: https://issues.guix.gnu.org/
> authors: 宋文武 
> sponsors: Maxim Cournoyer 
> date-submitted: 
> date: 
> SPDX-License-Identifier: CC-BY-SA-4.0 OR GFDL-1.3-no-invariants-only
> ---

Well, since you have sponsors and the Git repository hosting GCDs is now
up and configured, feel free to start the process.

This GCD can be now considered as *submitted*.  The date for the
submission date will be the one when you will send the announce; see
“Communication Channels” section.

Cheers,
simon



Guix Consensus Document: Git repo and workflow

2025-02-18 Thread Simon Tournier
Hi all,

Please consider the Git repository hosting the GCDs:

https://git.savannah.gnu.org/cgit/guix/guix-consensus-documents.git/

And the README file proposes a workflow.  It’s up to changes. :-)

Feel free to drop new GCDs.  However, please consider that it takes time
to read and forge an opinion on some heavy topics, so refrain from
shooting more than 3 GCDs in the same time frame, for what my opinion is
worth.

Cheers,
simon



Re: Trying out Codeberg

2025-02-18 Thread Simon Tournier
Hi Ludo,

On Sun, 16 Feb 2025 at 17:41, Ludovic Courtès  wrote:


>perhaps even before GCD #001 is committed
> (not sure what’s going on here :-))

Probably because I’m lagging…

Well, now it’s ready from my side. :-)  Feel free to tweak, if it’s not
clear enough.

Cheers,
simon



Re: [GCD] Rename “main” branch

2025-02-18 Thread Simon Tournier
Hi Liliana,

On Sat, 15 Feb 2025 at 09:42, Liliana Marie Prikler  
wrote:

> title: Rename "main" branch
> id: 003
> status: draft
> discussion: https://issues.guix.gnu.org/
> authors: Liliana Marie Prikler
> sponsors:
> date: 
> SPDX-License-Identifier: CC-BY-SA-4.0 OR GFDL-1.3-no-invariants-only
> ---

Well, since you have sponsors and the Git repository hosting GCDs is now
up and configured, feel free to start the process:

This GCD can be now considered as *submitted*.  The date for the
submission date will be the one when you will send the announce; see
“Communication Channels” section.

Cheers,
simon




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

2025-02-18 Thread Simon Tournier
Hi Ludo,

On Tue, 28 Jan 2025 at 15:33, Ludovic Courtès  wrote:

> title: Migrating repositories, issues, and patches to Codeberg
> id: 002
> status: draft
> discussion: https://issues.guix.gnu.org/
> authors: Ludovic Courtès
> sponsors: Tobias Geerinckx-Rice, Ricardo Wurmus
> date-submitted:  
> date: 
> SPDX-License-Identifier: CC-BY-SA-4.0 OR GFDL-1.3-no-invariants-only
> ---

Well, since you have sponsors and the Git repository hosting GCDs is now
up and configured, feel free to start the process.

This GCD can be now considered as *submitted*.  The date for the
submission date will be the one when you will send the announce; see
“Communication Channels” section.

Cheers,
simon



Re: Trying out Codeberg

2025-02-18 Thread Simon Tournier
Hi Olivier,

On Sun, 16 Feb 2025 at 13:51, Olivier Dion  wrote:

> I have not follow the entire thread about this migration.
>
> Will the mail-patch workflow still available?

The mail-patch workflow is still available.  It will be available until
a GCD changing is accepted.  And such GCD will explain the migration
plan.

Ludo is probably too eager to switch. ;-)  But Ludo’s initiative appears
to me helpful because it might help to draw a better migration plan.

Cheers,
simon



Re: renaming of fpga.scm module

2025-02-18 Thread Cayetano Santos

>lun. 17 févr. 2025 at 21:03, Maxim Cournoyer  wrote:

> Hi Cayetano,
>
> Andreas Enge  writes:
>
>> Am Sun, Feb 09, 2025 at 10:11:17AM +0100 schrieb Cayetano Santos:
>>> Two options at this point: we keep on happily dropping loosely related
>>> packages somewhere (is that a problem, after all ?); or we create a new
>>> team (if there is interest on participating) to organise and maintain
>>> these packages (I volunteer).
>>
>> Teams are always a good idea!
>
> I'd be happy to be on an electronic team.

I guess two makes a team 😀

> I don't see it as a bad thing to keep our current '(gnu packages
> electronics)' as the fourre-tout for eletronics packages that do not
> have a better home yet, while having more specific ones like the FPGA
> packages in (gnu packages fpga), and perhaps one day (gnu packages asic)
> or (gnu packages eda) for electronics design automation.

As stated before, the border line between domains is rather thin, with
frequent overflows (vhdl/verilog are asic of fpga ?), but still

> In other words, I'd keep what we have but introduce an electronics-team
> with a scope that covers them.

How do we proceed with this ? Do we send a patch for the new (binary)
team ?  Anyone else interested ?

--
Cayetano Santos
.
gpg: CCB8 1842 F9D7 058E CD67 377A BF5C DF4D F6BF 6682
key: meta.sr.ht/~csantosb.pgp


signature.asc
Description: PGP signature


Re: Guix Consensus Document: Git repo and workflow

2025-02-18 Thread Development of GNU Guix and the GNU System distribution.
Simon Tournier  writes:

> Hi all,
>
> Please consider the Git repository hosting the GCDs:
>
> https://git.savannah.gnu.org/cgit/guix/guix-consensus-documents.git/
>
> And the README file proposes a workflow.  It’s up to changes. :-)
>
> Feel free to drop new GCDs.  However, please consider that it takes time
> to read and forge an opinion on some heavy topics, so refrain from
> shooting more than 3 GCDs in the same time frame, for what my opinion is
> worth.
>
> Cheers,
> simon

Thanks for setting this up!

Noé



Re: Trying out Codeberg

2025-02-18 Thread Rostislav Svoboda
People, I find codeberg to be slow :-/

Cheers, Bost