Re: Regarding the vertical alignment in the record definitions

[indieterminacy]

Hello,

On 2024-12-05 07:13, Maxim Cournoyer wrote:

Hi Tomas,

...

I agree it's a bit tedious, both manually and also in diffs.  My
personal preference is to leave just one space between the field name
and the value, that also holds for variable bounds in lets, etc., to
avoid the problem (at the cost of some visual clarity, I guess).

One day maybe we'll have a general tool like 'scheme-fmt' to run on a
file save hook that'd fix the format question for good, like Python has
with 'black' or 'ruff', etc.  I have on mind to work on such a tool, 
but

it's low in the list.


FWIW, Im slowly cobbling together some parsing-expression-grammars for 
Guix package definitions.
Im doing it in the Lisp TXR atm but Im going to create a hybrid approach 
with Prolog to make it more general.


In addition to outputting a unified formatting, Im planning on altering 
descriptions so that that that content is outputted in the format 
Texinfo.


Please dont expect anything soon but should anybody start any other 
initiative then I may possibly some useful assets or details by then.


Kind regards,


Jonathan

Re: Automatically testing package updates

[Hilton Chain]

Hi,

On Thu, 05 Dec 2024 15:20:53 +0800,
Efraim Flashner wrote:
>
> I'm now thinking about the easy-package -> hard-package learning curve
> for new contributors, and I'm not sure how we'd address that.

I'm thinking about something like a wiki of packaging examples, where it starts
from a 'hello' package to explain basic concepts and (most importantly from my
observation) rules for synopses and descriptions etc., expanding to specific
cases for various build systems.  Since we already have plenty of good examples,
the content can be quickly filled.

Thanks

Re: Automatically testing package updates

[Ricardo Wurmus]

Suhail Singh  writes:

> Efraim Flashner  writes:
>
>> Also I don't think we should spam the bug tracker with package upgrades,
>> so we'd have to think about something for that.
>
> Could you clarify what you're objecting to?  Is it bug issues being
> created that are then not (as is currently the case) automatically
> closed?  Or is simply the creation of bug issues problematic, even if
> they were to be closed automatically by a bot (yet to be implemented)?

It would be preferable to automate trivial updates *completely*, even
bypassing the need for manual patch generation and submission to the bug
tracker.  I'd rather reserve the issue tracker for humans and keep bots
in a realm that is separate from the user interfaces designed for
humans.

-- 
Ricardo

Re: ‘cargo-build-system’ makes everything slow

[Liliana Marie Prikler]

Hi Guix,

Am Donnerstag, dem 05.12.2024 um 09:06 +0200 schrieb Efraim Flashner:
> On Mon, Dec 02, 2024 at 08:24:29PM +0100, Ricardo Wurmus wrote:
> > Perhaps this would be a good time to revive the antioxidant-build-
> > system
> […]
> I still have a copy of the code on my machine but unfortunately it no
> longer builds due to the constant churn of rust packages.
> 
> […]
> 
> Another idea which I'm not in love with is what Debian does. […]
I would like to throw a third option into the Mix: Meson.  It not only
supports Rust[1], but also has a wrapper for the cargo build system[2],
which while experimental should help us translating all the cargo bits
to Meson ones.  At least the former is actively being used in Mesa[3],
so it works as a proof of concept – for the latter, it appears that
Mesa uses hand-written meson build files.

Cheers

[1] https://mesonbuild.com/Rust.html
[2] https://mesonbuild.com/Wrap-dependency-system-manual.html#cargo-wraps
[3] 
https://gitlab.freedesktop.org/mesa/mesa/-/blob/24.3/src/compiler/rust/meson.build

Re: Automatically testing package updates

[Ricardo Wurmus]

Suhail Singh  writes:

> If we do decide to keep bots in a separate realm as it were, it would be
> desirable (and in my opinion, important) if that still allowed for at
> least as much transparency that the issue tracker provides for human
> activities.

Examples are the guix-cran and guix-bioc channels:

https://github.com/guix-science/guix-cran
https://github.com/guix-science/guix-bioc

They are generated with these scripts:

https://github.com/guix-science/guix-cran-scripts/

For my purposes this is sufficient transparency.  Automated updates for
closed package collections (by team scope or otherwise) would look
similar, I assume.

-- 
Ricardo

Re: Automatically testing package updates

[Attila Lendvai]

> If we do decide to keep bots in a separate realm as it were, it would be
> desirable (and in my opinion, important) if that still allowed for at
> least as much transparency that the issue tracker provides for human
> activities.


what other data would you miss that is not available in the git log?

sidenote: as a newcomer i found it rather off-putting that the bug tracker is 
full of random two-liner package updates, many long forgotten and even obsolete.

for at least two reasons:

 - it's a lot of wasted effort; the admin overhead of a simple package
   update is several times of the effort that goes into creating the
   patch. it gives the impression that the project organization
   doesn't value the time of its participants.

 - when i search for something, it's lost in the noise of boring and
   obsolete stuff in the issue tracker (package updates being one
   source). if a bot joins the "effort", i'm afraid it'll become that
   much worse.

-- 
• attila lendvai
• PGP: 963F 5D5F 45C7 DFCD 0A39
--
“The more artificial taboos and restrictions there are in the world, the more 
the people are impoverished…. The more that laws and regulations are given 
prominence, the more thieves and robbers there will be.”
— Lao Tzu (sixth century BC)

Re: Automatically testing package updates

[Ricardo Wurmus]

Hilton Chain  writes:

> On Thu, 05 Dec 2024 15:20:53 +0800,
> Efraim Flashner wrote:
>>
>> I'm now thinking about the easy-package -> hard-package learning curve
>> for new contributors, and I'm not sure how we'd address that.
>
> I'm thinking about something like a wiki of packaging examples, where it 
> starts
> from a 'hello' package to explain basic concepts and (most importantly from my
> observation) rules for synopses and descriptions etc., expanding to specific
> cases for various build systems.  Since we already have plenty of good 
> examples,
> the content can be quickly filled.

The Cookbook has a packaging tutorial.  It could get more tutorials of
the kind you're describing.

-- 
Ricardo

How to build Rust packages

[Ludovic Courtès]

Hello,

Efraim Flashner  skribis:

> I still have a copy of the code on my machine but unfortunately it no
> longer builds due to the constant churn of rust packages.
>
> One thing I remember explicitly about it was that building end packages
> was faster than the current method, and that was before taking into
> account reusing build artifacts.
>
> https://notabug.org/maximed/cargoless-rust-experiments

Neat.

> Another idea which I'm not in love with is what Debian does. They grab
> all of the sources into one build environment and then build everything.
> It simplifies the dependency management of the sources but for us it
> would make it so that we can't touch anything in rust without causing a
> full rebuild of everything.

I believe this is also what Nixpkgs does, as discussed in this thread:

  https://toot.aquilenet.fr/@civodul/113532478383900515

I’m not a fan either.  But I think one of the main criteria here should
be long-term maintainability, which is influenced by internal design
issues and by how we design our relation with the external packaging
tool.

By internal issues I mean things like #:cargo-inputs instead of regular
inputs, which makes the whole thing hard to maintain and causes
friction.  (See .)

As for the relation with Cargo and crates.io, the question is should we
map packages one-to-one?  Is it worth it?  If the answer is yes, do we
have the tools to maintain it in the long run.

Ludo’.

Re: [Deprecation RFC] node@10 (a.k.a. node-bootstrap)

[Liliana Marie Prikler]

Am Mittwoch, dem 04.12.2024 um 09:03 +0100 schrieb Jelle Licht:
> Hi guix,
> 
> I've just sent out the v2 series to bump Node.js and friends:
> https://issues.guix.gnu.org/74187
> 
> In this proposed series of patches, the version of Node.js
> (node@10.24.1) we use to bootstrap node-llhttp-bootstrap becomes a
> hidden package. As per my reading of the policy w.r.t. 'removing'
> public packages, consider this message the start of the 1 month
> notice period to speak up and mitigate potential breakage [0].
> 
> AFAICS I took care of fixing everything within guix proper, but
> things can break in branches other than master, and in external
>  channels. Please reply with any concerns, and cc
> 74...@debbugs.gnu.org for good measure.
> 
> Some soft landing options:
> 1. Define a deprecated-package that aliases the 'node' variable to
> 'node-lts'. I'd prefer not doing this, as in the medium term it would
> be nice to have a proper 'node' package that actually tracks the
> latest releases.
> 
> 2. Add an entry in news.scm.
I think defining a non-deprecated alias with node → node-lts is in the
spirit of Guix and what we do for other things like GCC, LLVM, etc. 
That being said, do we have a node that is fresher than node-lts?  If
not, we might in future just rename node-lts to node :)

Cheers

Re: Automatically testing package updates

[Suhail Singh]

Efraim Flashner  writes:

> Also I don't think we should spam the bug tracker with package upgrades,
> so we'd have to think about something for that.

Could you clarify what you're objecting to?  Is it bug issues being
created that are then not (as is currently the case) automatically
closed?  Or is simply the creation of bug issues problematic, even if
they were to be closed automatically by a bot (yet to be implemented)?

-- 
Suhail

Re: Automatically testing package updates

[Ricardo Wurmus]

Attila Lendvai  writes:

> sidenote: as a newcomer i found it rather off-putting that the bug
> tracker is full of random two-liner package updates, many long
> forgotten and even obsolete.

This is exactly my point and why I think the bug tracker must contain
only *actionable* work that humans are meant to work on.  As we're
trying to undo the damage of years of being overwhelmed by patches I'd
really like to keep the issue tracker for humans only.

-- 
Ricardo

Re: Creating a C/C++ team?

[Greg Hogan]

On Fri, Nov 29, 2024 at 4:35 AM Liliana Marie Prikler
 wrote:
>
> Hi Greg,
>
> Am Montag, dem 25.11.2024 um 13:27 -0500 schrieb Greg Hogan:
> > Guix,
> >
> > Should we have a C++ team? I think project contributions regarding C
> > and C++ compilers, libraries, tools, and programs would benefit from
> > a tag to flag, discuss, and triage issues and a team branch to
> > manage, test, and pre-build patches.
> >
> > This team would of course be distinct from the core-packages team,
> > which manages the most fundamental packages and challenging updates.
> I think there is a risk that this still overlaps with core-packages on
> the account of GCC being our main C/C++ toolchain.

The core-packages team scope includes commencement.scm, gcc.scm, and
gnu-build-system so contributors using etc/teams.scm will be properly
directed. I do share this concern, but I also think there is enough
delay in collecting and building patches on a team branch that someone
would flag a patchset needing core-packages handling and review.

> Note: while I'm already swamped with work on gnome and emacs, I would
> be interested in joining a hypothetical c++ team.

Excellent!

> > diff --git a/etc/teams.scm b/etc/teams.scm
> > index fe3291f914..e257650a04 100755
> > --- a/etc/teams.scm
> > +++ b/etc/teams.scm
> > @@ -611,0 +612,14 @@ (define-team zig
> > +(define-team c++
> > +  (team 'c++
> > +#:name "C/C++ team"
> > +#:description
> > +"C and C++ compilers, libraries, tools, and programs"
> I would limit the scope to "libraries and tools".  That programs happen
> to be written in C/C++ is almost always incidental :)
>
> > +#:scope (list "gnu/packages/c.scm"
> > +  "gnu/packages/cpp.scm"
> Of course.
>
> > +  "gnu/packages/llvm.scm"
> > +  "gnu/packages/llvm-meta.scm"
> Not sure about these two.  Since our main use for LLVM is in
> Rust/Zig/Mesa, all of which have their own teams, maybe we should leave
> a broader LLVM team with members from all of that open for folks who
> are not necessarily interested in the rest of C/C++.
>
> > +  "gnu/packages/ninja.scm"
> > +  "gnu/packages/valgrind.scm"
> If we add these, I would also suggest adding build-tools.scm,
> check.scm, debug.scm etc.
>
> > +  "gnu/build/cmake-build-system.scm"
> > +  "gnu/build-system/cmake.scm")))
> These are under guix/ and belong to the core team IIRC.
>
> Cheers

v2 below. Removed compiler (llvm[-meta].scm) scope and removed
"compilers" from description.

+1 to an LLVM team or llvm[-meta].scm in the core-packages scope.

I think cmake-build-system belongs in the C++ team scope. Our use of
cmake is rather simple, even with the enhancements collected in #70031
(which began with a desire to parallelize tests). We should keep cmake
up-to-date without bothering core-packages.

ninja.scm and valgrind.scm are essentially single package modules. The
suggested build-tools.scm, check.scm, and debug.scm are a mix. For
example, check.scm includes python-pytest among other python packages.
Not sure why these are not in python-check.scm unless there would be
circular dependencies. Given the success of the teams workflow, should
we look to divide these mixed modules by team rather than grouping by
theme?

$ ./etc/teams.scm show c++
id: c++
name: C/C++ team
description: C and C++ libraries and tools and the CMake build system.
+ Note that updates to fundamental packages are the competency of the
+ core-packages team.
scope:
+ gnu/build-system/cmake.scm
+ gnu/build/cmake-build-system.scm
+ gnu/packages/c.scm
+ gnu/packages/cmake.scm
+ gnu/packages/cpp.scm
+ gnu/packages/ninja.scm
+ gnu/packages/valgrind.scm

Re: Automatically testing package updates

[Suhail Singh]

Attila Lendvai  writes:

> what other data would you miss that is not available in the git log?

No data that is currently being automatically generated.  Then again,
none of the patches at present are.  One can argue (and perhaps that's
what you are) that, even in the future, whatever automated-comments may
be left (e.g. guix lint/style stats, integration test-suite status) on
issues created for automated-patches could instead also be noted in the
automated-commits.  That's certainly possible.

Another thing to note is that when there's an integration-test-suite,
patch-generation may not automatically lead to patch-merge, and even in
the case that they do there may be a delay between patch-generation and
patch-merge.  Those situations are elegantly handled by having a
patch-generation and patch-merge bot interacting on a debbugs
issue-tracker.

>  - it's a lot of wasted effort; the admin overhead of a simple package
>update is several times of the effort that goes into creating the
>patch. it gives the impression that the project organization
>doesn't value the time of its participants.

Sure, however, this doesn't apply in the case when patches are
automatically handled.

>  - when i search for something, it's lost in the noise of boring and
>obsolete stuff in the issue tracker (package updates being one
>source). if a bot joins the "effort", i'm afraid it'll become that
>much worse.

Being "lost in the noise" can be addressed by ensuring there's a
straightforward way to exclude all bot-generated-patches from search
results.

Guix already makes good use of debbugs usertags.  It would be
straightforward for all automatically generated patches to have a
pre-defined usertag denoting the fact that they've been automatically
generated.  The mumi interface at issues.gnu.guix.org could also have
the default configuration which ignores all issues with said usertag.

Conclusion: The reasons presented so far seem to fundamentally be about
retaining the ability to discern automatically-generated-patches from
human-generated-patches.  This is possible while still tracking such
patches via the issue tracker.

-- 
Suhail