Re: Rebasing or merging? [was: Re: 01/03: gnu: wxwidgets: Add libxtst to inputs.]

[Josselin Poiret]

Hi everyone,

Maxim Cournoyer  writes:

> I'm not a 'git log' expert myself, but intuitively like you, I'd expect
> the --no-merges one to be useful to hide merge commits!  The doc seems
> to confirm that:
>
>  --no-merges
>  Do not print commits with more than one parent. This is
>  exactly the same as --max-parents=1.
>
> Thanks for finding that option.

I used these kinds of options for the last core-updates merge, and this
one only hides the merge commits themselves, not the merged commits.
For that, you need to use --first-parent.

Best,
-- 
Josselin Poiret


signature.asc
Description: PGP signature

Re: FSDG issues of SCUMMVM-based games

[Giovanni Biscuolo]

Liliana Marie Prikler  writes:

[...]

> 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)

I totally agree with this simple and pragmatic solution, but the FSDG
violation is not that games are distributed with a non-free license
(IMHO the license of some or all games have the same legal effect of the
SIL Open Font License v.1.1, that is considered free [1])

AFAIU the violation comes from the absence of the source code (or just
the build tools?) to compile the game to ScummVM bytecode (other issues
with the way games are compiled and distributed can be patched, AFAIU)

IMO when removing teh games is very inportant to mention the motivation,
since it will be useful for potential similar use cases.

> 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.

Yes, keeping ScummVM is not a clear FSDG violation AFAIU

Thanks all for the heads on!

[1] albeit very poorly worded: 
https://www.gnu.org/licenses/license-list.html#SILOFL

-- 
Giovanni Biscuolo

Xelera IT Infrastructures


signature.asc
Description: PGP signature

Re: distributed substitutes: file slicing

[Attila Lendvai]

> I have a question / suggestion about the distributed substitutes
> project: would downloads be split into uniformly sized chunks or could
> the sizes vary?
> Specifically, in an extreme case where an update introduced a single
> extra byte at the beginning of a file, would that result in completely
> new chunks?


most (all?) distributed storage solutions have a chunker (including ERIS with 
its 32k chunks, or Swarm with 4k chunks), and the chunks are content addressed, 
i.e. it also serves as deduplication at the chunk granularity.

if the file doesn't just grow, but shifts away a couple of bytes somewhere in 
the middle, then this chunk-level deduplication stops happening from that point 
on.

IIRC rar was the first archiver that introduced a very fast deduplication 
algorithm that detected even the non-aligned duplicated blocks of varying 
sizes. i don't think any distributed storage system has anything like that.


> An alternative I've been thinking about is this:
> find the store references in a file and split it along these references,
> optionally apply further chunking to the non-reference blobs.


chunking storage systems store only whole chunks, so too much splitting of 
files can increase the wasted storage. more so with large chunks, less so with 
smaller ones.


> It's probably best to do this at the NAR level??
> 
> Storing reference offsets is already something that we should be doing to
> speed other operations up, so this could tie in nicely with that.


if optimization of grafting is worth this amount of trouble, then maybe the 
best is to extend the NAR format to store mutable references in a separate 
table at the end of the file. that would speed up guix operations like 
grafting, and help any storage systems that have deduplication, which includes 
some copy-on-write filesystems.

-- 
• attila lendvai
• PGP: 963F 5D5F 45C7 DFCD 0A39
--
“If you shut up truth and bury it under the ground, it will but grow, and 
gather to itself such explosive power that the day it bursts through it will 
knock down everything that stands in its way.”
— Émile Zola (1840–1902)

Zig build system and river Wayland compositor

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

Hi,

I declared Bug#60889, [1] which provides a Zig build system, as a
prerequisite for Bug#64208. [2] The latter packages two Zig
applications that use the build system in the former.

One of the Zig applications is a new Wayland compositor called River. [3][4]

The Debbugs change is not visible in Mumi, so a brief note here seemed
appropriate. The bug control system [5] has in fact many advanced
features that can help manage large numbers of bugs. Like most large
software projects, GNU Guix has a lot of open patches and bug reports.

While I have everyone's attention, I'd also like to take the
opportunity to ask any available committers to please review the new
Zig build system.

Zig is an exciting language. [6] Using strong but inferred types, it
brings many of Rust's ideas to a language that looks and compiles like
C yet feels like a script. I like GNU Guile much better but to this
author, Zig appears as a more natural evolution of the C ecosystem for
system-level programming than Golang. (I hope neither Rob Pike or Ken
Thompson take offense.)

Most notably, the Zig tooling is super easy to use, especially for
wasm32-wasi. Please try it one day & thanks!

Kind regards
Felix

cc: Ekaitz

[1] https://debbugs.gnu.org/60889
[2] https://debbugs.gnu.org/64208
[3] https://isaacfreund.com/blog/river-intro/
[4] https://archive.fosdem.org/2021/schedule/event/zig_wayland/
[5] https://debbugs.gnu.org/server-control.html
[6] 
https://www.infoworld.com/article/3689648/meet-the-zig-programming-language.html

Adding Django 4.2 LTS

[Luis Felipe]

Hi,

I've been using Django 4.2.2 from my personal Guix channel for a couple 
of days and it seems to work alright, so I'd like to send a patch to 
include it in Guix, although I have some questions first.


1. python-asgiref >= 3.6.0 and < 4 is a requirement for Django 4.2 LTS 
series, there is a patch for it already 
(https://issues.guix.gnu.org/61543), it builds, doesn't appear to have 
known vulnerabilities and Django 4.2.2 works with it. Would it be okay 
to add it to Guix until someone else packages the latest version (3.7.2, 
but it currently fails to build for me: sanity-check 
DistributionNotFound or something)?


2. "guix lint python-django@4.2.2" says this version of DJango might be 
vulnerable to CVE-2023-31047 but reading the CVE description version 
4.2.2 doesn't seem to be affected. Is there anything I should do 
regarding this warning?


3. Guix currently distributes versions of Django that no longer receive 
security updates or bug fixes. For example, python-django@4.0.7, 
python-django@3.1.14, python-django@2.2.28 (see 
https://www.djangoproject.com/download/). Should they be removed?


Thanks in advance,

--
Luis Felipe López Acevedo
https://luis-felipe.gitlab.io/



OpenPGP_0x0AB0D067012F08C3.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

FreeType Brotli (WOFF font) support; Godot 4

[John Kehayias]

Hi Guix-devel-ers,

I have a local patch that updates Godot to (the big and exciting) version 4. 
Despite the big changes in Godot, besides some larger changes to its package 
definition, the only external change I came across was in FreeType. Guix's 
FreeType is built without Brotli support, needed for WOFF fonts. Is there any 
reason we don't build with Brotli?

The change needed is simply adding 'brotli' to the 'propagated-inputs' of the 
freetype package. The closure increases from 79.9 MiB to 82.3 MiB.

If this is a reasonable change, I can go ahead and make it, I would say on the 
mesa-updates branch I proposed. A change to freetype means over 8000 packages 
need to be rebuilt (17,800 dependents), according to guix refresh. There is 
significant overlap with what gets rebuilt for a Mesa update, and we could see 
about bumping up harfbuzz too, per the discussion in 
.

It is a lot of rebuilds but very minor changes in package definitions in just a 
few places, hopefully making it easier to address any issues (or backing out 
some changes for another time).

I can go ahead an make a branch with these few changes next week if there are 
no objections to at least see how this will go, pending a build job. Sorry for 
splitting this related discussion to a new thread, but I figure this would be 
good for separate input.

Thanks!
John

PS: In my quick tests Godot 4 works great; probably we want to keep the 
previous version 3 series as it is LTS now.

Re: Zig build system and river Wayland compositor

[Ekaitz Zarraga]

--- Original Message ---
On Wednesday, June 21st, 2023 at 3:43 PM, Felix Lechner 
 wrote:


> Hi,
> 
> I declared Bug#60889, [1] which provides a Zig build system, as a
> prerequisite for Bug#64208. [2] The latter packages two Zig
> applications that use the build system in the former.
> 
> One of the Zig applications is a new Wayland compositor called River. [3][4]
> 
> The Debbugs change is not visible in Mumi, so a brief note here seemed
> appropriate. The bug control system [5] has in fact many advanced
> features that can help manage large numbers of bugs. Like most large
> software projects, GNU Guix has a lot of open patches and bug reports.
> 
> While I have everyone's attention, I'd also like to take the
> opportunity to ask any available committers to please review the new
> Zig build system.
> 
> Zig is an exciting language. [6] Using strong but inferred types, it
> brings many of Rust's ideas to a language that looks and compiles like
> C yet feels like a script. I like GNU Guile much better but to this
> author, Zig appears as a more natural evolution of the C ecosystem for
> system-level programming than Golang. (I hope neither Rob Pike or Ken
> Thompson take offense.)
> 
> Most notably, the Zig tooling is super easy to use, especially for
> wasm32-wasi. Please try it one day & thanks!
> 
> Kind regards
> Felix
> 
> cc: Ekaitz
> 
> [1] https://debbugs.gnu.org/60889
> [2] https://debbugs.gnu.org/64208
> [3] https://isaacfreund.com/blog/river-intro/
> [4] https://archive.fosdem.org/2021/schedule/event/zig_wayland/
> [5] https://debbugs.gnu.org/server-control.html
> [6] 
> https://www.infoworld.com/article/3689648/meet-the-zig-programming-language.html


Thanks for the work on this, Felix.

Looks like the build system was ready for production after all.

Maybe a maintainer / commiter can take a look into this and guide us to the 
final inclusion in guix?
Efraim, can you please take a look, this have been sitting for a while (half a 
year :( ) and it looks like it starts to have some interests.
I'm not sure about the cross-compilation yet, even though I tried it and worked 
properly, but the native one seems to be ready.

Also this might be a great opportunity. We can attract some people from the Zig 
community as they don't really have a Zig package manager yet (they are 
building one!) and Felix and I will push Guix a little bit in their community 
(right Felix? :))

Thanks all for your work.

Ekaitz

Re: Ideas for ocaml-team

[pukkamustard]

DABY-SEESARAM Arnaud  writes:

> [[PGP Signed Part:Undecided]]
> Hi,
>
> Do you plan on including coq.scm in the upgrade plan, as it also depends 
> on dune?

I hadn't thought of the Coq packages, but probably makes sense to update
them together as they will be rebuilt with updates to the OCaml compiler
and Dune.

Do you have an overview of what Coq packages need an update?

> Anyway, I am new to Guix, but will try to help if I can (time- and 
> competence-wise) ! :)

Yeah, very nice! :) 

-pukkamustard

Re: Zig build system and river Wayland compositor

[Pjotr Prins]

Thanks for the package updates - we are using them.

Pj.

Re: distributed substitutes: file slicing

[Csepp]

Csepp  writes:

> I have a question / suggestion about the distributed substitutes
> project: would downloads be split into uniformly sized chunks or could
> the sizes vary?
> Specifically, in an extreme case where an update introduced a single
> extra byte at the beginning of a file, would that result in completely
> new chunks?
>
> An alternative I've been thinking about is this:
> find the store references in a file and split it along these references,
> optionally apply further chunking to the non-reference blobs.
>
> It's probably best to do this at the NAR level??
>
> Storing reference offsets is already something that we should be doing to
> speed other operations up, so this could tie in nicely with that.

I was sent this link that others might find interesting:
https://alternativebit.fr/posts/nixos/future-of-nix-substitution/