Re: Changes to the branching/commit policy

[John Kehayias]

Hi Chris,

On Mon, Jun 12, 2023 at 09:23 PM, Christopher Baines wrote:
>
> Christopher Baines  writes:
>
>> The changes in #63459 have strayed now in to touching the commit policy
>> [1]. My intent was to simplify the guidance by grouping it better, but I
>> think the significant change here is that the commit policy now
>> references the entire branching strategy, rather than just talking about
>> sending patches for review.
>>
>> 1: 
>> 
>>
>> That new branching strategy makes some "should" requirements on sending
>> patches for review and pushing to topic branches for larger changes. It
>> also makes a "must" requirement on opening guix-patches issues to track
>> and manage merging branches.
>>
>> I'd like to merge these changes next week since they've been up for a
>> few weeks, so do comment if you have any thoughts or if you'd like more
>> time to review them.
>
> I've now merged these changes as
> 0ea096ae23fa81f05ce97e5e61c15647c0a475ec.
>
> You can now see the updated Commit Policy on the website [1] (you might
> need to force a refresh), as well as the new section on managing patches
> and branches [2].
>
> 1: 
> 
> 2: 
> 
>

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? Or does the
section about branch building for once patches are pushed to a branch
on Savannah? 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.

Thanks!
John

service 'term-tty2' provided more than once

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

Hi,

I drop agetty and mingetty from %base-services [1] and then add greed
and mingetty in the way I prefer. [2] My last successful configure was
about a month ago (and after Bruno rewrote many of those services.) As
of recently, my deployments fail with

service 'term-tty2' provided more than once

Did someone change the way the virtual terminals are provisioned in
%base-services? Thanks!

Kind regards,
Felix

[1] 
https://codeberg.org/lechner/system-config/src/commit/81f867ca39ba6149e1efb49f3c1437614085e970/host/wallace-server/operating-system.scm#L1129-L1130
[2] 
https://codeberg.org/lechner/system-config/src/commit/81f867ca39ba6149e1efb49f3c1437614085e970/services/greeter.scm

Re: rust-build-system from antioxidant

[Maxim Cournoyer]

Hi Nicolas,

Nicolas Graves  writes:

> Hi all,
>
> Thanks for this discussion that I didn't expected to happen ;)
>
> I'll try and finish a version of the rust-build-system but I'd like to
> know if there are reasons to not want a direct and complete rewrite of
> all Rust packages before putting more time into this. My rationale is
> that since we have channels, users won't really be affected in any
> meaningful way because adding a "snapshot of cargo packages" in a
> channel and then adding the channel is straightforward.

Thank you!

My impression is that the Rust packaging in Guix is so problematic that
if a way would mean less work for you and motivate you to push this work
to the finish line it, that may well be the better way :-).

> I've merged the rust-build-system and rust-workspace-build-system into a
> single one, and made some UX improvements (a dozen patches on top of
> Maxime's work).
>
> If atomicity / readability of changes is the issue, I can try to cut the
> packages rewrites into patches (although that would make more than 1k
> patches total I think).

That would match our convention better, if it's not too difficult to
accomplish (is this going to be automated?  I've written some imperfect
but useful automatic rewriting tool in the past to remove the Python 2
packages [0].  Perhaps it could provide some ideas)

[0]  
https://notabug.org/apteryx/guix-api-examples/src/master/purge-python2-packages.scm

-- 
Thanks,
Maxim

Re: FSDG issues of SCUMMVM-based games

[Denis 'GNUtoo' Carikli]

On Thu, 15 Jun 2023 19:34:32 +0200
Liliana Marie Prikler  wrote:
> I don't think we need to be that harsh on ScummVM itself, it being a
> virtual machine.  
>
> Compare it to Wine: the tools to create Windows binaries with free
> software only are limited (albeit existing if we discount the
> necessity for system headers), but it still serves a purpose by
> enabling you to run said programs without resorting to a Windows
> machine.
About wine, the first time GUix's wine starts it asks you to download
and install mono for you (and in my case I didn't manage to skip that),
but if that's 100% free (it's most likely the case), everything should
be OK because:
- We have an FSDG compliant toolchain for Wine in Guix
- Wine in Guix should also be 100% free software
- The guix build --target=x86_64-w64-mingw32 hello works fine in
  Guix's Wine
- The package description also don't steer users toward nonfree
  software.

So just with that have at least 1 valid use case that don't steer users
toward getting and installing nonfree software at all, and that use
case is not incompatible with the package description, so for me It's
hard to find something wrong with that here, especially when the use
case is of strategic importance for free software (shipping software to
people used by nonfree OS can help spread free file formats and
protocols).

> The only limiting factor here is your point (2), i.e. it being able to
> run arbitrary games compiled for the VM.  I don't think that weird
> checksums ought to be enforced if they're not baked into the program
> itself.
The draci-historie build tutorial said that the checksums were backed
in ScummVM and that you needed to add your own checksum inside ScummVM
source code and recompile it to run a modified version of the game.

Maybe that changed since then, but that is probably not very likely to
have happened, and this checksum mechanism also likely applies to all
programs or games meant to run inside ScummVM.

And if we had at least one 100% free program that run inside ScummVM
(something without nonfree dependencies, that we can rebuild or modify)
then we'd be able to easily find out about the checksums.

If someone knows good tools to work with ARJ archives, we could also
try it by modifying existing games very slightly (like by adding
something new inside the ARJ archive).

> Even if no such toolchain exists for ScummVM, you need ScummVM as a
> testbed to write one :)
Assuming that some way around the checksums is found, the issue here is
that no such toolchain exist yet, so testing it won't work right now.

And assuming that draci-historie turn out to be a dead end, getting a
free toolchain probably requires significant work in research, or in
packaging.

In contrast, many other VMs (qemu, java, gjs, etc), they already
have valid use cases and/or it's trivial to make a free software hello
world.

So there is no such burden on the potential user to have to provide
development tools that don't exist yet for that VM.

And here the rationale doesn't try to weight uses cases (like wine has
many nonfree games and very few known 100% free software, so wine
should be removed[2]), only to make sure that there is at least a single
use case that works with 100% free software.

> > I've looked a bit at another game (draci-historie[2]) that has some
> > source code published. This game is not packaged nor redistributed
> > by Guix but it looks way better than the other freedom wise and it
> > can teach us how ScummVM games are made.
> > 
> > Its probably not good enough as-is as its source code also also
> > relies on a tarball that contains executable to build the game and I
> > also didn't manage to build it with Guix yet (I've attached a file
> > with my attempt) but maybe it's possible to get it to build and
> > maybe we can build a 100% free software version of it.
> You might be able to bootstrap parts of it with fpc, i.e. the Free
> Pascal Compiler.  I'm not sure whether you'll encounter the necessity
> for Borland Pascal, as we package version 3.2.2, which is somewhat
> newer than the mentioned 2.4.
I'm unsure of why it fails exactly. I've an error message[1] that comes
from the Pascal code, but I don't know Pascal and the comments aren't
in English. 

Though I could indeed try a different compiler version and see if it
works, or try to build it in some FHS container.

References:
---
[1]cannot save palettes used in programs
   /tmp/guix-build-draci-historie-1+2.drv-0/source/build/gfx/outro/outpal1.pcx
[2]In my opinion weighting use cases is a can of worms because the
   importance of use cases is subjective, and if all FSDG distros go
   this route, it could prevent valid use cases that are or turn out to
   be strategic for free software. And since the use cases are
   prevented, people might even not be able to see the problem that was
   created by going this route.

Denis.


pgpAh_A6KkrN5.pgp
Description: OpenPGP digital signature

Re: rust-build-system from antioxidant

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

Hi all,

Thanks for this discussion that I didn't expected to happen ;)

I'll try and finish a version of the rust-build-system but I'd like to
know if there are reasons to not want a direct and complete rewrite of
all Rust packages before putting more time into this. My rationale is
that since we have channels, users won't really be affected in any
meaningful way because adding a "snapshot of cargo packages" in a
channel and then adding the channel is straightforward.

I've merged the rust-build-system and rust-workspace-build-system into a
single one, and made some UX improvements (a dozen patches on top of
Maxime's work).

If atomicity / readability of changes is the issue, I can try to cut the
packages rewrites into patches (although that would make more than 1k
patches total I think).

-- 
Best regards,
Nicolas Graves