Hi David,
David Pirotte writes:
In Guix program languages specified libraries are named with
the
language as prefix, eg: python-six, perl-dbix-simple, and
guile-g-golf.
Guix should not do this. ...
Changing this convention would require a very large amount of work
and disrupt things ever
Hi 45mg,
On Mon, Feb 10 2025, 45mg wrote:
> That could work, but would probably open up a larger attack surface;
Larger than the --disable-authentication I have used for two years?
Upon reflection, I am actually more likely to install a local public
key, or perhaps a set, into ~/.config/guix.
Hello Florian,
> > g-golf
> > g-golf-gtk-4-examples
> > g-golf-adw-1-examples
> ... sadly sadly since Guix commit ... any package that uses g-golf
> and possibly more can again only run using --no-grafts.
I still would split packages, as whether a guix user would just use
g-golf (
Hello iyzsong,
> Well, g-golf is deprecated by guile-g-golf here, so guile-g-golf is
> the correct name..
Sorry, guile-g-golf can't be a correct name. it actually is an
incorrect name 'by definition' - there is only one correct name, GNU
G-Golf, abreviated in all distro (but guix) as g-golf x.y.z
Am 11.02.25 um 11:36 schrieb Tomas Volf:
What are the benefits of changing the name of the master branch?
"master" is considered offensive for black people, because of centuries
of slavery - where the "master" was the suppressor.
--
Regards
Hartmut Goebel
| Hartmut Goebel | h.goe..
David Pirotte writes:
> Wrt packaging g-golf in guix, please allow me to suggest to adopt this
> approach, which is what debian does, and I recently convinced the nix
> pkg maintainer to also 'do the same'.
>
> I highly recommend that you split and propose (for now) 3 pkgs:
>
> g-golf
>
On Sat, 28 Dec 2024, Ludovic Courtès wrote:
> Hello,
>
> Olivier Dion skribis:
>
>> For what it is worth, I have been using my own build system purely in
>> Guile for a few years now. I use it in my main project libpatch
>> (https://git.sr.ht/~old/libpatch/tree). It is compatible with the
>> gn
On Sat, 28 Dec 2024, Divya Ranjan wrote:
> Hello Oliver,
>
> Thanks for the elaborate response and apologies for a delayed one from
> me, the holidays have been occupied.
Sorry for my very late reply. Last months were very busy for me. I
appology in advance for this very long answer.
> The bui
On Tue, 31 Dec 2024, Pjotr Prins wrote:
> On Sat, Dec 28, 2024 at 01:48:02AM +, Divya Ranjan wrote:
[...]
> Sure, it may be worth creating a clean system. But I do note that both
> meson and cmake chose to handle the build through make or ninja. There
> must be a reason for that :)
Sorry fo
On Tue, 31 Dec 2024, Pjotr Prins wrote:
> On Sat, Dec 28, 2024 at 01:48:02AM +, Divya Ranjan wrote:
[...]
> Sure, it may be worth creating a clean system. But I do note that both
> meson and cmake chose to handle the build through make or ninja. There
> must be a reason for that :)
Sorry fo
Simon Tournier writes:
> Especially when it becomes so “easy” (familiar) to click on a button for
> forking. Without counting on the “wish-to” effect: I would like to
> contribute and even if I will never do it, I start to fork in case.
While on GitHub and GitLab forks can effectively live fore
Simon Tournier writes:
> Hi,
>
> On Sun, 09 Feb 2025 at 12:43, Tomas Volf <~@wolfsden.cz> wrote:
>
>>> Maybe this is semantic nitpicking, but people who are able to merge are
>>> effectively committers, if only potentially limited to some parts of
>>> the code.
>>
>> Given that Guix is (effective
Hi Maxim,
Thanks for the input. I think that I communicated the idea that I'm proposing
poorly, although I'm not sure if what I'm proposing would actually work. I sent
a new version of the patchset with the change that I'm proposing implemented,
which should hopefully clarify what I mean. Of co
Hi,
Morgan Arnold writes:
> Hi Andreas,
>
> Thanks for the clarification. If this is the case, and texlive is
> unlikely to be used as a native input, it seems reasonable to me that
> setting `allowSubstitutes = 0` if `(not (and substitutable? (every
> substitutable-derivation? inputs)))` would
Hi,
Interesting discussion but not easy to follow !
> 2. Does it the fit the workflow of people who concretely review and
> push code from other? And if I read correctly your messages,
> yes. :-)
On Nixpkgs, the bot suggests PR to the maintainer when upstream is updated (for
example h
We discussed the next release during Guix Days and I volunteered to lead
the effort.
The short version:
* We need a tagged release so we can update the version in Debian and
other distros, in CI systems, etc.
* We need a newer point-in-time for the installer.
* A new release increases interest
Hi,
On Sat, 08 Feb 2025 at 17:57, Ludovic Courtès wrote:
>> Now you mention it, shouldn't we have some people there to vote if we
>> are doing some heavy use of their infrastructure?
>
> The GCD draft I sent mentions creating ties with Codeberg e.V., possibly
> through financial support, definit
Hi Leo,
On Thu, 06 Feb 2025 at 14:39, Leo Famulari wrote:
> On Thu, Feb 06, 2025 at 04:40:03PM +0100, Simon Tournier wrote:
>> Sorry if my understanding is incorrect, but if we do not increase the
>> number of people with specific/dedicated/controlled write access, the
>> move to Codeberg is use
Hi,
On Thu, 06 Feb 2025 at 12:08, Vagrant Cascadian wrote:
>> All these commits before v0.16 could be archived. And the “new”
>> repository would start at this 4a0b87f0ec5b6c2dcf82b372dd20ca7ea6acdd9c.
[...]
> Maybe I misunderstand, but can that be done without rewriting history,
> which woul
Hi Ludo,
On Sat, 08 Feb 2025 at 17:43, Ludovic Courtès wrote:
>> Sorry if my understanding is incorrect, but if we do not increase the
>> number of people with specific/dedicated/controlled write access, the
>> move to Codeberg is useless. Provocative on purpose. ;-)
>
> As I mentioned in the G
Hi,
On Sun, 09 Feb 2025 at 12:43, Tomas Volf <~@wolfsden.cz> wrote:
>> Maybe this is semantic nitpicking, but people who are able to merge are
>> effectively committers, if only potentially limited to some parts of
>> the code.
>
> Given that Guix is (effectively) just a large Scheme program, doe
Hi,
On Sat, 08 Feb 2025 at 18:13, Ludovic Courtès wrote:
> To be more concrete, do you have something like this in mind:
>
> git.guix.gnu.org/guix.git
> git.guix.gnu.org/maintenance.git
> git.guix.gnu.org/build-coordinator.git
> …
>
> ?
I’m not Tobias but I had that in mind when reading
Hi,
On Fri, 07 Feb 2025 at 16:22, Ludovic Courtès wrote:
> • Scalability (storage): If the Guix repository were to have “tens of
> thousands” of forks (I think these were their words), then the
> storage requirements for Codeberg could be very high and
> problematic, due to lack (o
Ludovic Courtès writes:
> The Savannah `guix.git` repository would become a mirror of the one at
> Codeberg, with a script periodically updating it, as a way to ease
> migration to the new repository for users.
Will the mirroring ensure that the guix-commits mailing list still
works? I find it
Hartmut Goebel writes:
> Am 10.02.25 um 21:38 schrieb Ludovic Courtès:
>> I support it as well¹ but I think we’d rather address it separately.
>
> I'm in favor of changing the name of the main branch in one go when switching
> to
> Codeberg.
>
> Rational: People need to touch their setup anyway
25 matches
Mail list logo
