Re: Guix / Nix Benchmarks

[Csepp]

kiasoc5  writes:

> On 6/19/23 08:54, Nicolas Graves via Development of GNU Guix and the
> GNU System distribution. wrote:
>> One of the criticism that can be read online about Guix (compared to
>> Nix) is its speed. I have never tried Nix and probably won't in a near
>> future, but I was wondering if some work has been made to compare them
>> on basic tasks (package installation, removal...) (the reason why I ask
>> is to be able to give an honest answer to someone hesitating between
>> both).
>> 
>
> At least package installation is faster with Nix. One reason is that
> Hydra (their "substitute server") has faster download speeds compared
> to CI/Bordeaux, likely due to multiple geographical locations/mirrors.

Conversely, Nix itself is likely to be slower than Guile.  I remember
search being so memory intensive with Nix that it got OOM killed even
with 4 GB of RAM, although they may have fixed that since.

Re: FSDG issues of SCUMMVM-based games

[Liliana Marie Prikler]

Am Sonntag, dem 18.06.2023 um 21:07 +0200 schrieb Denis 'GNUtoo'
Carikli:
> [...]
> > Didn't you say that a hello world for scummvm exists?
> I don't know. There is a template for AGI games but the license is
> strange too, and it also requires some software to build it, and I've
> no idea if it's compatible with QT AGI, and I've also no idea if QT
> AGI works, doesn't have nonfree dependencies, etc. 
> 
> So that makes things way more complicated because here it probably
> requires a lot of work to confirm that it's possible or not possible
> to develop programs that run inside ScummVM with free software.
I see we're hitting a recurring pattern of not knowing things.  This is
not aided by my personal disinterest for ScummVM, but I have to weigh
that disinterest against the potential interest of thousands of users
who are likely to only discover this argument to have taken place after
we've reached a conclusion.

Note, that this discussion started IIRC a year ago and we have
practically known about actually existing FSDG violations since then. 
My approach here is quite simple and pragmatic: Remove the games which
obviously violate the FSDG (that is all the games currently depending
on ScummVM as far as I know), but keep ScummVM for now to allow folks
to experiment.  If in some one to five years we still find no practical
way of using ScummVM with only free software, that might be a reason to
remove it then.

WDYT?

Re: Changes to the branching/commit policy

[Christopher Baines]

John Kehayias  writes:

>>> Or does the section about branch building for once patches are pushed
>>> to a branch on Savannah?
>>
>> I'm not sure what you're asking here.
>
> I'm confused myself over my wording, but I remember what I was trying
> to get at:
>
> Currently QA doesn't build patches if they cause a large number of
> rebuilds correct? So for building a branch that requires this, will
> that only happen on Cuirass with a new jobspec for the branch? Or will
> this be addressed through changes to how QA builds? (Maybe this
> answered below actually.)

Yep, for issues there's a cap of 300 builds per system.

QA does build the branch at the front of the queue to be merged though,
currently that's ruby-team [1].

1: https://qa.guix.gnu.org/

>>> Does that mean pushing to a branch should follow the same 1-2 week
>>> review allowing QA builds? I guess patch series are always built
>>> together on QA but wondering if there is anything else to be aware of
>>> or needs mentioning to keep things tidy and clear.
>>
>> Those durations mentioned in the commit policy [1] are intended to allow
>> for human review. For QA, it doesn't need to be time based as it can
>> report it's progress. Obviously it does need a bit of time to check
>> things, but I prefer to leave it up to people to assess the changes and
>> any information provided by QA and decide when it's appropriate to push.
>>
>> 1: 
>> 
>>
>
> A separate issue which I wanted to get at was about pushing changes to
> any branch on Savannah. Do we expect those to be at the same state as
> anything that would go directly to master, just pending the testing of
> builds basically? So, after the usual review period? Or can those be
> more WIP and not polished yet? I suppose this is for a team/people
> working on a branch to discuss and how it will then be merged to
> master.

The latter. Non-master branches can be in whatever state is useful.

>> On keeping things clear, I think with branches I'm hoping the issue
>> tracker can help with this, which is why there's now a strong
>> requirement to create a guix-patches issue when you want to merge a
>> branch, and use those issues to manage the timing.
>>
>> For those issues, there's currently a convention of using the following
>> title: `Request for merging "" branch` e.g. [2]. That helps QA find
>> these issues and act accordingly, but of course if someone comes up with
>> a better way of naming these issues, we can just adjust the code in the
>> qa-frontpage.
>>
>
> I see, that's a nice way to then group up discussion if a branch has a
> bunch of separate patch threads. Looks like a good idea!
>
> So, to be concrete, with the mesa patch I just sent,
>  I can open a merge request issue for
> QA to process the branch, once the branch is actually created on
> Savannah? I assume with the pretty trivial version change here I could
> do that to see how the builds go, but I'll hold off pending the thread
> I just started about this branch/team.

Currently QA just builds the branch at the front of the queue, but yes.


signature.asc
Description: PGP signature

Re: Guix / Nix Benchmarks

[kiasoc5]

On 6/19/23 08:54, Nicolas Graves via Development of GNU Guix and the GNU 
System distribution. wrote:


One of the criticism that can be read online about Guix (compared to
Nix) is its speed. I have never tried Nix and probably won't in a near
future, but I was wondering if some work has been made to compare them
on basic tasks (package installation, removal...) (the reason why I ask
is to be able to give an honest answer to someone hesitating between
both).



At least package installation is faster with Nix. One reason is that 
Hydra (their "substitute server") has faster download speeds compared to 
CI/Bordeaux, likely due to multiple geographical locations/mirrors.

Re: Changes to the branching/commit policy

[John Kehayias]

Hi Chris,


On Sat, Jun 17, 2023 at 10:57 AM, Christopher Baines wrote:
>
> John Kehayias  writes:
>
>> Thanks for these changes! Question on branches (sorry if this was
>> covered in a previous thread, but now that we have new language in the
>> manual I figure this is a good place): do we have a convention on
>> branch names and subject headers for emailing patches for the branch?
>> e.g. does [PATCH  1/3] do anything on the QA end?
>
> On the names of branches, there's some typical names like -team, or
> wip- but really it's up to you.
>
> QA doesn't currently support applying patches to anything other than the
> master branch, but that's something that should probably be addressed at
> some point. I'd encourage you to do whatever you think is useful here,
> then hopefully QA can use that to act appropriately.
>

Sounds good, a simple identifier in the "[PATCH]" subject, like for
core-updates, seems simple enough to get started.

>> Or does the section about branch building for once patches are pushed
>> to a branch on Savannah?
>
> I'm not sure what you're asking here.

I'm confused myself over my wording, but I remember what I was trying
to get at:

Currently QA doesn't build patches if they cause a large number of
rebuilds correct? So for building a branch that requires this, will
that only happen on Cuirass with a new jobspec for the branch? Or will
this be addressed through changes to how QA builds? (Maybe this
answered below actually.)

>
>> Does that mean pushing to a branch should follow the same 1-2 week
>> review allowing QA builds? I guess patch series are always built
>> together on QA but wondering if there is anything else to be aware of
>> or needs mentioning to keep things tidy and clear.
>
> Those durations mentioned in the commit policy [1] are intended to allow
> for human review. For QA, it doesn't need to be time based as it can
> report it's progress. Obviously it does need a bit of time to check
> things, but I prefer to leave it up to people to assess the changes and
> any information provided by QA and decide when it's appropriate to push.
>
> 1: 
> 
>

A separate issue which I wanted to get at was about pushing changes to
any branch on Savannah. Do we expect those to be at the same state as
anything that would go directly to master, just pending the testing of
builds basically? So, after the usual review period? Or can those be
more WIP and not polished yet? I suppose this is for a team/people
working on a branch to discuss and how it will then be merged to
master.

> On keeping things clear, I think with branches I'm hoping the issue
> tracker can help with this, which is why there's now a strong
> requirement to create a guix-patches issue when you want to merge a
> branch, and use those issues to manage the timing.
>
> For those issues, there's currently a convention of using the following
> title: `Request for merging "" branch` e.g. [2]. That helps QA find
> these issues and act accordingly, but of course if someone comes up with
> a better way of naming these issues, we can just adjust the code in the
> qa-frontpage.
>

I see, that's a nice way to then group up discussion if a branch has a
bunch of separate patch threads. Looks like a good idea!

So, to be concrete, with the mesa patch I just sent,
 I can open a merge request issue for
QA to process the branch, once the branch is actually created on
Savannah? I assume with the pretty trivial version change here I could
do that to see how the builds go, but I'll hold off pending the thread
I just started about this branch/team.

> 2: 
> 3:
> 
>
> Thanks for your questions :)
>
> Chris
>

And thanks again for all you do here, the Guix tooling has been making
great progress!

John

Branch (and team?) for mesa updates

[John Kehayias]

Hi everyone,

With our move to a branching strategy for patches that require many rebuilds, I 
would like to propose a branch for Mesa updates. Based on how Mesa has been 
developed the last few years, there should be frequent (roughly a couple of 
months or quicker) releases that shouldn't be breaking anything or requiring 
lots of packaging work.

Famous last words, I know, but at least in the last few years the only big 
change I know of was the one we hit on the last core-updates cycle with old 
hardware being dropped. The previous cycle had some build changes, perhaps due 
to missing many intermediate version changes. Both were rather self-contained 
and resolved quickly.

So, I have submitted a patch for the latest stable release at 
 I'm aware of one other patch that should 
also go here,  are there any others?

I've tentatively labeled with "mesa-updates" as a proposed branch name. With 
Mesa's release cycle I propose keeping this as a branch for Mesa updates, and I 
suppose related required changes (say libdrm). If everything goes smoothly, we 
can give the build farm some time to build everything, check for any breakages, 
and then push to master with substitutes available. Master can be merged into 
this branch just prior to a patches going to this branch with the expectation 
merging back to master will be soon after and changes are only affecting 
packages that won't be touched on master anyway. I think this should be 
relatively clean and straightforward, a good use of our new branching/building 
strategy.

Thoughts? Can someone set up a build job for this branch and/or let me know how 
to do that? (I would also require access to Cuirass.)

Do we want a "Mesa team" or something a bit larger? Not sure what exactly, 
since "graphics" is perhaps too broad. Happy to help spearhead the Mesa front 
for Guix (the very package that got me first involved in the patching process).

Thanks!
John

Re: About donation to GNU Guix project

[Simon Tournier]

Hi,

On Sun, 11 Jun 2023 at 21:43, Maxim Cournoyer  wrote:
> Mert Gör  writes:

>> donate with some money if they all
>> possible I'll be happy

[...]

> 2. Guix Europe
> http://foundation.guix.info/
>
> I'm actually not sure how donating to Guix Europe works (I know you can
> become a member for a small fee), but you could ask for the bank account
> number and wire the funds there.

In addition to what Maxim said, Guix Foundation (previously known as
Guix Europe) is a non-profit supporting the Guix project.  Indeed, the
bank information is lacking on the website.  Feel free to ping me if you
would like to wire there.

Cheers,
simon

Guix / Nix Benchmarks

[Development of GNU Guix and the GNU System distribution.]

One of the criticism that can be read online about Guix (compared to
Nix) is its speed. I have never tried Nix and probably won't in a near
future, but I was wondering if some work has been made to compare them
on basic tasks (package installation, removal...) (the reason why I ask
is to be able to give an honest answer to someone hesitating between
both).

-- 
Best regards,
Nicolas Graves