Ludovic Courtès writes:
>> Specifically, the bulk of patch submissions in Guix deal with packages.
>> Barring some core packages, perhaps Guix would be better served by
>> splitting other packages into a separate channel. The organization and
>> management of said channel could be optimized for
Hi Juliana,
I like some of the points you do here: we should encourage committers to
review patches, and give commit access to those that are focused on that.
On the other hand, I disagree with your message about GNU and the FSF.
First, I don't think the sentiment you describe about GNU and t
So,
On 2024-10-26 22:22, Ludovic Courtès wrote:
We have enough money, about 50k€ currently at the FSF plus a couple
thousand € at Guix Foundation⁰.
So we rely on the FSF for the funding, mostly.
I don't want to discuss if we want to separate ourselves from the FSF or
not, but in the end, if
With due respect, I disagree with that.
Guix recent years has seen growing interests and contributions, so
many patches that the they are not reviewed or processed in a timely
manner. This is with affiliation with GNU. I contributed to Guix
because it is GNU.
In fact I just contact the FSF abo
On 2024-10-26 18:40, Suhail Singh wrote:
Christine Lemmer-Webber writes:
...
Specifically, the bulk of patch submissions in Guix deal with packages.
Barring some core packages, perhaps Guix would be better served by
splitting other packages into a separate channel. The organization and
manage
Suhail Singh skribis:
> Ludovic Courtès writes:
[...]
>> Besides, I agree with you Greg that we need more automation, in
>> particular for package updates. Nixpkgs has an auto-update bot; we
>> could just as well have a bot that roughly runs ‘guix refresh’ and
>> submits patches/merge request
Hi Denis,
Adding to Andreas's thesis - it's hard to be the first =) and extending
your concern - start with small; small series, small contribution,
small steps, but be persistent in your efforts and keep the attitude
(refering to Chris Hadfield's "An Astronaut's Guide to Life on Earth").
To eas
Hi,
Suhail Singh skribis:
> Specifically, the bulk of patch submissions in Guix deal with packages.
> Barring some core packages, perhaps Guix would be better served by
> splitting other packages into a separate channel. The organization and
> management of said channel could be optimized for t
Hey y'all,
Ekaitz, thank you for opening this thread. RIP your inbox.
I think this thread demonstrates in itself one of our biggest issues. A
few folks have mentioned it indirectly. I'll be direct. We can't stay
on topic.
So once again, Ekaitz, thank you for clarifying what this discussion i
Hello Christine!
Thanks for your thoughtful message and for the good vibes! It’s great
to be able to count on the support and advice of an experienced leader.
There are many things in your message, let me reply selectively. :-)
Dave and you mention that you perceive Guix as “on the decline” or
Hi!
Before I reply to Christine’s insightful message, here’s my
Chief Visionary *cough* view on the questions you ask:
Ekaitz Zarraga skribis:
> - Do we need independent funding so we can pay for our machines and
> maintenance?
We have enough money, about 50k€ currently at the FSF plus a cou
Hi Felix,
On 25 October 2024 20:50:46 UTC, "Felix Lechner via Development of GNU Guix and
the GNU System distribution." wrote:
>Would it be more efficient to check whether a particular substitute is
>available in an individual query (like DNS) and stop querying for that
>substitute after a serve
On 26 October 2024 17:23:37 UTC, Suhail Singh wrote:
>To be fair it didn't say "the list"
Very fair, sorry. I wasn't even aware than my brain added the ‘the’ there.
>would "updating list of available substitutes" be better?
Well, I prefer my suggestion, but then I would, wouldn't I? ;-) You
Tobias Geerinckx-Rice writes:
>>"Fetching list of available substitutes" would be clearer, IMHO.
>
> Less accurate though. We never care about or download a complete list
> of available substitutes.
To be fair it didn't say "the list" nor "complete list". Regardless,
would "updating list of av
On 26 October 2024 16:54:04 UTC, Suhail Singh wrote:
>"Fetching list of available substitutes" would be clearer, IMHO.
Less accurate though. We never care about or download a complete list of
available substitutes.
Kind regards,
T G-R
Sent on the go. Excuse or enjoy my brevity.
Hi Attila,
On 25 October 2024 23:42:32 UTC, Attila Lendvai wrote:
>i still don't really know what's happening there, but maybe something like
>"fetching the registry" or "fetching metadata" would be more descriptive of it?
Howsabout… ‘looking for suitable substitutes on ’ if we must change
th
Ludovic Courtès writes:
> The “updating substitutes” bit corresponds to making pipelined GET
> requests for narinfos¹ to figure out upfront what’s going to be
> available as substitutes and what will have to be built.
"Fetching list of available substitutes" would be clearer, IMHO.
--
Suhail
Ludovic Courtès writes:
>> WIth 29,000+ packages the nature of the project has changed from
>> adding new software to managing updates (what fraction of new packages
>> are rust or python dependencies?).
>
> … that’s the crux of the problem. What works for our little channels
> mentioned above i
Christine Lemmer-Webber writes:
> That patches aren't being reviewed and aren't making it in. Alas.
We have ~45 authorized contributors. Based on the manner in which these
contributors were added, I believe they have reasonable trustworthiness
to uphold the goals of Guix. However, I do not be
On Fri, Oct 25, 2024 at 7:25 PM Attila Lendvai wrote:
[...]
> this is also a chicken-egg issue: until some authority is delegated, the
> center will remain a bottleneck.
[...]
> ... then i considered the effort it would take to send a patch, and the fact
> that i already have a lot of my eff
Hi Juliana,
Juliana Sims skribis:
> After a turbulent few months, I have an exciting announcement about
> the Goblins Shepherd port -- the design document has reached (initial)
> completion! [1]
Congrats on this first milestone! This is an exciting project and I
look forward to further develop
Hi,
Felix Lechner via "Development of GNU Guix and the GNU System
distribution." skribis:
> When updating, my equipment spends nearly as much time "updating
> substitutes" as it does downloading substitutes.
>
> The activity is probably exacerbated because I cross-publish substitutes
> in my loc
Hi,
Nicolas Graves skribis:
> I was wondering about handling a cpe-vendor property to handle such
> cases, since cpe-name won't help here.
Yes, we need that. (guix cve) currently blissfully ignores the “vendor”
part of CPE names; we can do better.
Thanks,
Ludo’.
Hello,
Ekaitz Zarraga skribis:
> Second, grants work kind of well for specific tasks, but what happens
> with the structural work? Is anybody actually getting paid for it?
Should the project have the ability to pay people, I think it should
first and foremost reward thankless tasks—from system
Hello!
(“As an online Guix discussion grows longer, the probability of ending
up talking about the email workflow approaches 1.”)
Greg Hogan skribis:
> On Fri, Oct 25, 2024 at 10:21 AM Noé Lopez via Development of GNU Guix
> and the GNU System distribution. wrote:
>>
>> Furthermore, on the top
Hi Christine,
I think you very well said here.
My original discussion wanted to tackle several points, some of them you
very well mention here:
- There's already people getting paid for working on Guix, and that is
not a problem at the moment but we could do it better.
- If there's any com
Hi Marco,
Marco Fortina skribis:
> Yes, only changes in the environment.scm files are required for fixing the
> issue.
>
> Why did you make the patch so complex?
[...]
>> +(when (file-exists? gcc-path)
>> + (catch 'system-error
>> +(lambda ()
>> + (symlink gcc-path "
Greg Hogan skribis:
> On Wed, Oct 23, 2024 at 12:14 PM Ludovic Courtès wrote:
>>
>> Hello Guix,
>
> [...]
>
>> 2. When rebasing on top of ‘master’, please cancel pending builds from
>> previous evaluations that have become irrelevant.
>
> How is this issue limited to rebasing to 'master'?
Hello, hello! Thanks for starting this thread, Ekaitz, and it's nice to
see the comments which have rolled in so far. We were talking about
this thread on the daily Spritely engineering call and Dave went over
what he had already said and I went on a long ramble of opinions, and
juli and Dave sai
Hello,
Felix Lechner writes:
> Should updates to TexLive or its prerequisites fall under the
> core-updates policy (or whatever its successor is)?
>
> My Guix is heavily modified and building TexLive takes an hour and a
> half. Grafting it takes nearly as long. Thanks!
What TexLive are you tal
30 matches
Mail list logo