Re: [workflow] Automatically close bug report when a patch is committed

[Vagrant Cascadian]

On 2023-09-09, Maxim Cournoyer wrote:
> Vagrant Cascadian  writes:
>>> Did you see my message about integrating a commit-hook similar to what
>>> Gerrit uses?  It produces unique ID such as:
>>>
>>> --8<---cut here---start->8---
>>> Change-Id: I9b86781869d80eda347659f0c009b8dfe09bdfd0
>>> --8<---cut here---end--->8---
...
>> That seems like it would only work if the patch was identical, as
>> opposed to a slightly rebased patch on top of newer patches on master?
>>
>> How can you correlate Change-Id to a patch in the tracker?
>
> The Change-Id stays the same unless you manually edit it out of your
> commit message when amending / rebasing, so the commit hash may change
> while the Change-Id stays the same.  So you can rebase your feature
> branch on master and share a v2, whose existing commits will have the
> same Change-Ids (newly added commits would get their own Change-Id
> trailer).

Ok, that makes some sense.

Although the majority of bugs in the cleanup work I did were actually
filed by someone else entirely... so the Change-Id will not help with
those. Not a reason not to implement it, but not consistent with some of
the triggers of this thread. :)

live well,
  vagrant


signature.asc
Description: PGP signature

[emacs]: snapshots against latest versions

[Cayetano Santos]

Hi Guix,

  Following a recent patch to an snapshot of an emacs package
  (emacs-mastodon), where latest stable (tagged) release dates back from
  a long time, the question of whether to send patches for non stable
  (tagged) versions is pertinent or not.

  Of course, the answer is clear: we only package stable. Guix manual
  (22.4.3 Version Numbers) clearly states that "We usually package only
  the latest version of a given free software project ... Occasionally,
  we package snapshots of upstream’s version control system (VCS)
  instead of formal releases.  This should remain exceptional.". Fine
  with that.

  Now, regarding emacs-xyz packages, the situation is a bit ambiguous.
  We have (old?) (tagged) releases, as well as snapshots. What is the
  rule to follow when we contribute ? At what point in time do we
  consider we may submit patches for snapshots ? With which frequency ?
  Do we consider number or relevance of commits since latest version ?
  Do we base our decision on time elapsed ? Simply put, as for now, we
  have a mix of melpa-stable and melpa: when one may decide to forget
  stable and move forward to latest ? Of course, this is author’s role,
  but I’m wondering how subjective all of this is, and how this might
  impact quality of provided packages.

Best,

Cayetano

Re: performance issue with TeX Live

[Olivier Dion]

On Tue, 12 Sep 2023, Emmanuel Beffara  wrote:
> Hello Guix devel,
>
> I am facing a severe performance issue with TeX Live: compilation of any
> document is an order of magnitude slower with a Guix installed system as
> compared to a manual installation. Is anyone confronted to this phenomenon, or
> is there a way to fix this ?

I had a similar issue not long ago.  I think recent patches fix this and
now it is smooth as before.

-- 
Olivier Dion
oldiob.dev

Re: [workflow] Automatically close bug report when a patch is committed

[Liliana Marie Prikler]

Hi Maxim,

Am Montag, dem 11.09.2023 um 16:41 -0400 schrieb Maxim Cournoyer:
> [...]
> Perhaps both approach[es] could be combined.  I still see value in a
> general scheme to automate closing applied series that linger on in
> Debbugs.
> 
> [0] 
> https://lists.gnu.org/archive/html/guix-devel/2023-09/msg00138.html
> 
> Change-Ids would also add the benefit that any commit found in Git
> could easily be traced back to their submission on the guix-patches
> or guix trackers or vice-versa (git log --grep='Change-Id='), as
> noted by Giovanni.
The thing is, we're discussing the same basic workflow (which you lay
out below), just different kinds of metadata that we'd have to attach
to our commits.  IIUC ChangeIds need to actually be carried around by
the committers as they e.g. rewrite patches (rebasing, squashing, what
have you), and they're basically opaque hashes so I don't see the
benefit to the reader.  (I think you might be arguing that the benefit
is uniqueness, but I'm not sure if I ought to buy that.)

Meanwhile "Fixes: [whatever notation]" also needs to carried around,
sure, but at the same time provides semantics by pointing to a (known)
bug report.  Now again, I personally prefer cool URLs here, but that's
a bike we can shed however we want.

> The process could go like this:
> 
> 1. commits of a series pushed to master
> 2. Savannah sends datagram to a remote machine to trigger the
> post-commit job, with the newly pushed commits 'Change-Id' values (a
> list of them).
> 3. The remote machine runs something like 'mumi close-issues [change-
> id-1 change-id-2 ...]'
Yeah, I think we basically agree on the 1 and 2 here, but I don't think
we have to really implement 3.  IMHO we could do something simpler for
all parties by just carrying the bug number around (in whichever form),
which we do for some of our pre-ChangeLog explanations already.
 
> In case it couldn't close an issue, it could send a notification to
> the submitter: "hey, I've seen some commits of series  landing to
> master, but not all of the commits appears to have been pushed,
> please check"
I'm not sure how common this case is, but if it's needed we could add
"Part-of: [same stuff as for fixes]" which once parsed by Debbugs/Mumi
would send that notification.


Cheers

Re: How can we decrease the cognitive overhead for contributors?

[Simon Tournier]

Hi Maxim,

On Tue, 12 Sep 2023 at 10:42, Maxim Cournoyer  wrote:

>> Even before looking at it, I have to spend some time to find a way to
>> manually apply the patches.  Then, rebasing on the top of master could
>> lead to conflict but that another story and the same appears whatever
>> the workflow.
>
> I think this kind of problem has improved though, since we deploy by
> default our etc/git/config snippet, which sets 'useAutoBase = true'.
>
> At least I don't have a problem when applying patches with 'git am -3s'.

We are drifting. :-)

This branch of the long thread starts with:

Re: How can we decrease the cognitive overhead for contributors?
Attila Lendvai 
Fri, 25 Aug 2023 08:07:53 +

id:JRUs8LVm3AtAh0MnHjE5rnhB4sNET0vWTOO2N3w2KfvKoM3CALRNwHTmwJ0Y9Bg3ZDWCs8j-1bMCo9aRiaoac8TAkuXAvrWgSwt_8RcwhQA=@lendvai.name

https://yhetil.org/guix/JRUs8LVm3AtAh0MnHjE5rnhB4sNET0vWTOO2N3w2KfvKoM3CALRNwHTmwJ0Y9Bg3ZDWCs8j-1bMCo9aRiaoac8TAkuXAvrWgSwt_8RcwhQA=@lendvai.name
https://lists.gnu.org/archive/html/guix-devel/2023-08

Attila speaks about the PR model.  Then many comments later about the
pros and cons, the discussion is split intro the contributor side and
the reviewer side of the PR model.  Ricardo reports then their
experience reviewing Pull Request:

Re: How can we decrease the cognitive overhead for contributors?
Ricardo Wurmus 
Fri, 08 Sep 2023 16:44:41 +0200
id:87sf7o67ia@elephly.net
https://yhetil.org/guix/87sf7o67ia@elephly.net
https://lists.gnu.org/archive/html/guix-devel/2023-09

And I provide one typical example where “our“ model leads to some
friction for the reviewer: the first step, apply the patches.

And this exact same friction does not exist in the PR model by design of
this very PR model.  I am not saying the PR model is perfect and I am
not saying “our” workflow is crappy.  I just agree with Ricardo
messages.

Now, yes this kind of problem is improving.  Please note that the
problem is not new and I am aware of it. :-) I submitted on October 2020
the first mention of ‘git format-patch --base’ in the “Submitting
Patches” section and d18b787d8a5cada8d239f1335257d0c1bca7f825 had been
pushed only on September 2021.

For whatever reason, sometimes patches fall into some cracks or are
badly formatted or something else.  Then, applying them becomes boring.
I am not saying that’s impossible, I am just saying that sometimes we
have a friction (something that has no value for the project) because of
our workflow.

I am not speaking on the vacuum of an hypothetical problem but I am
using a concrete example patch#62202 from my own pile.

Using the usual “git am -3s” from Emacs Debbugs, then I get:

--8<---cut here---start->8---
Applying: import: juliahub: first script draft.
error: sha1 information is lacking or useless (guix/import/go.scm).
error: could not build fake ancestor
hint: Use 'git am --show-current-patch=diff' to see the failed patch
Patch failed at 0001 import: juliahub: first script draft.
When you have resolved this problem, run "git am --continue".
If you prefer to skip this patch, run "git am --skip" instead.
To restore the original branch and stop patching, run "git am --abort".
--8<---cut here---end--->8---

Ok, maybe that’s because some empty commit message (I did not know that
and I had to search using search engine, well I do not know), let’s try
with “git apply”, then I get:

--8<---cut here---start->8---
error: patch failed: guix/import/go.scm:503
error: guix/import/go.scm: patch does not apply
--8<---cut here---end--->8---

Ok, that’s maybe this file had been modified.  So I do,

--8<---cut here---start->8---
$ git log --format="%h %cd %s" -- guix/import/go.scm
ae587c2ef041 Mon Mar 13 15:08:33 2023 +0100 guix: Strip #:use-module lists.
3c24da4260f2 Sat Dec 31 14:48:46 2022 +0100 import/utils: Pass all arguments 
through to package builder.
c1db66fa0a17 Sun Jan 9 23:17:17 2022 +0100 import: go: Correctly report 
diagnostics upon version mismatch.
--8<---cut here---end--->8---

And I checkout ae587c2ef041.  Same error.  The parent of ae587c2ef041.
Same error.  And I checkout 3c24da4260f2.  Same error.  Ok, do I try
with b4?

Well, at this point, do we agree there is useless friction? :-)

Maybe I am missing the obvious.  Maybe that’s a rare case.  That’s just
one from my pile.  And I see that time to time.

After 15 minutes today (and 10-15 minutes on April, 7th = 24 days after
the submission), I just give up.  And it ends on some eternal postponing
on my side; until I will just copy manually the 21 patches and manually
recreate the 21 commits.

Ricardo used the term “superior” and Liliana asked a definition.  That’s
the origin of my email.  Instead of a 

Re: How can we decrease the cognitive overhead for contributors?

[Katherine Cox-Buday]

On 9/8/23 2:37 PM, Ricardo Wurmus wrote:


Liliana Marie Prikler  writes:


Am Freitag, dem 08.09.2023 um 17:27 +0200 schrieb Ricardo Wurmus:

I have the same positive view on our faux ChangeLogs commit messages,
though I also would like to have them generated.  The benefit is
still there: I still get to *review* an effective summary of the
changes before pushing or sending them off for review.  But at least
I don’t have to write them myself.

Now, this is no longer a problem for me because I’ve been writing so
many commit messages over the years (and because I no longer try to
adhere to some poorly specified format), but it *is* a problem for
people that I’ve mentored.

etc/committer.scm and the yasnippets are supposed to alleviate some
of the pain, but I don’t need to think for a long time to come up
with a number of improvements in this area.

Can I assume this to mean it'd take you some short time to think of
snippets that we're currently lacking?  If so, please do contribute
them.  If not, what do you mean then?


I mean that they have plenty of defects.

When I wrote the first few iterations of etc/committer.scm it was only
really meant and good for bulk package updates (= lots of changes across
files, all upgrades).  It couldn’t (and maybe still can’t) reliably
detect added or removed package definitions.  It doesn’t handle changes
to the arguments field.  It’s also terribly slow because it naively
recomputes information for every hunk in the diff, reading package
definitions from the old vs the changed file after every commit.

The update yasnippet repeatedly gets the order of lines wrong when
adding a patch to dist_patch_DATA in gnu/local.mk; it also doesn’t do
what etc/committer.scm is already able to do: detecting changes to
inputs.  Configuring yasnippet is also not trivial for people who don’t
regularly use Emacs (the snippets are tied to modes set by magit).

I think in light of these defects “Uhm, we have snippets?” isn’t a
satisfying response.


Also, from my original message:

   I use the templates provided, but those don't cover all cases, 
and I've

   even gotten feedback in a review to change a message it created.

Re: How can we decrease the cognitive overhead for contributors?

[Katherine Cox-Buday]

On 9/8/23 5:28 AM, Ricardo Wurmus wrote:


Katherine, I’m very happy you brought this up and continue to respond in
this thread to clarify and steer the discussion into a fruitful
direction.  I know I couldn’t do it.  I thank you for this work, and I
hope that the project can come up with ways to lower the barriers to
entry.


Thanks for saying so, Ricardo, and thank you for all of your 
contributions to Guix. When I think fondly of the project, yours is one 
of the names that springs to mind.

Re: How can we decrease the cognitive overhead for contributors?

[Katherine Cox-Buday]

On 9/8/23 6:40 AM, Giovanni Biscuolo wrote:

Ricardo,

Ricardo Wurmus  writes:


Giovanni,


You are obviously free not to contribute your patches upstream but the
fact that you decided not to because it's "too hard" (my executive
summary about your complaints about Change Log content rules) to write
commit messages suitable for contribution it _not_ a Guix maintainers
fault, not at all.


As a former Guix co-maintainer I disagree with this take.  (Nobody even
brought up the word “fault”, which is a particularly unhelpful lens for
understanding social issues, in my opinion.)


sorry for using "fault", I can't find a better term


“too hard” sounds (perhaps unintentionally) derisive.


the complete sentence is: «"too hard" (my executive summary about your
complaints about Change Log content rules)»

what can I add about my intentions?

[...]


It’s not that writing commit messages is hard.  It’s one of many
obstacles,


IMO one of the very little ones


Taking a single step is trivial. Walking a thousand miles is difficult. 
The aggregate is the thing that matters most!


And these are subjective statements, which are bad to rest decisions on. 
I have the opinion that this style of commit message is difficult and 
doesn't have a lot of value; others think it's easy and find a lot of 
value in it.


I don't place much emphasis on my opinion or others' on this, but I 
place an enormous emphasis on the existence of the two groups. We should 
be curious why the two groups hold their opinions, and curious about a 
mutual path forward.


Instead of setting up camp and throwing rocks, let's share a meal and 
create a better way for everyone.



We can’t blame anyone for seeing these two piles and come to the
conclusion that it’s not worth the hassle — especially when operating
your own channel is so easy in comparison.


I'm not blaming Katherine, I respect her decision; I just wanted to say:
please don't blame the guidelines about ChangeLog for the two (or more)
piles.


No hard feeling, Gio. I want to echo what Ricardo is saying: viewing 
these conversations through the lens of blame and fault is not the 
intent, and is not helpful. In my original message I intentionally said 
that this was not a list of grievances, but an attempt to describe the 
"shape" of the problem.


While I do search for root-causes to issues, it's not done with the 
intent to cast blame on something. It's done with curiosity, and the 
desire to make the situation better for everyone.

performance issue with TeX Live

[Emmanuel Beffara]

Hello Guix devel,

I am facing a severe performance issue with TeX Live: compilation of any
document is an order of magnitude slower with a Guix installed system as
compared to a manual installation. Is anyone confronted to this phenomenon, or
is there a way to fix this ?

I suspect the problem comes from kpathsea, but I may be misinterpeting my
observations. The fact is that there is an enormous amount of file accesses
for any compilation.

As an experiment, I compared two installations.

- One is a pure Guix installation, managed with `guix home`, that contains a
  rather large collection of packages that I include through a custom package:

(define-public texlive-scheme-eb
  (package
(name "texlive-scheme-eb")
(version (number->string %texlive-revision))
(source #f)
(build-system trivial-build-system)
(arguments (list #:builder #~(mkdir #$output)))
(propagated-inputs
  (list texlive-scheme-medium
texlive-collection-fontsextra
texlive-collection-latexextra
texlive-collection-pictures))
(home-page "https://www.tug.org/texlive/;)
(synopsis "EB's custom installation scheme")
(description "This my a TeX Live scheme with what I use.")
(license (license:fsf-free 
"https://www.tug.org/texlive/copying.html;

- The other is manual, I set up a container with

 $ guix shell --container -F --network --share=$HOME/opt=/opt bash 
coreutils curl grep gzip ncurses perl sed tar wget

  in which I installed TeX Live using `install-tl` as found on
  , in the folder `/opt` exposed in the container.
  I installed the same package set by selecting the medium scheme in
  `install-tl` and installing the collections above with the provided `tlmgr`.

On my machine (a rather recent and powerful Dell Latitude 7410 with 16GiB RAM
and 12 cores), I observe the following timings:

- For a minimal LaTeX document (title, author and one word of body text)
  running `time pdflatex doc.tex` I get the following timings in the Guix
  version:

real0m4,288s
user0m3,140s
sys 0m1,148s

  and in the manual version:

real0m0.773s
user0m0.729s
sys 0m0.044s

- For a small beamer slideshow with nothing exotic (474 source lines, 17
  slides, no tikz graphics or anything), I get the following timings in the
  Guix version:

real1m0,122s
user0m14,337s
sys 0m44,279s

  and in the manual version:

real0m4.554s
user0m4.446s
sys 0m0.108s

I tried doing `strace` on the pdflatex calls to investigate further and it
appears that the behaviours of the two versions are largely different.
Counting the number of system calls of each kind gives the following, for the
most frequent calls:

- minimal document, Guix version:

   112860 newfstatat
10491 getdents64
 5247 openat
 5246 close
 4397 access
 3141 read

- minimal document, manual version:

 2772 read
   90 openat
   72 access
   64 close
   64 newfstatat
   60 getdents64

- slideshow, Guix version:

  2831722 getdents64
  1538560 newfstatat
  1498287 access
  1415296 openat
  1415295 close
 4283 read

- slideshow, Guix version:

 3913 read
 1288 getdents64
 1136 access
  960 openat
  925 close
  920 newfstatat

So apparently no file hash is used in the Guix version and a large part of the
`texmf-dist` folder is browsed, probably several times.

-- 
Emmanuel

Re: CI job for lisp-team branch

[Guillaume Le Vaillant]

Guillaume Le Vaillant  skribis:

> I reported the issue upstream at
>  with your log file.
> Let's see what they say...

I downgraded sbcl to 2.3.7 on the lisp-team branch for now.


signature.asc
Description: PGP signature

Re: How can we decrease the cognitive overhead for contributors?

[Katherine Cox-Buday]

On 9/11/23 6:19 AM, Giovanni Biscuolo wrote:


If you want I can add a little bit of Italian attitide at discussing in
detail tiny variations of the same thing :-O... just joking, eh! ;-)


One of the reasons I love working with people from around the world is 
the delight in discovering that despite real cultural differences, we 
are all human.


I think discussing minute details in a search to be perfectly understood 
is a very human thing that transcends cultures :)

Re: Cross compilation status

[Guillaume Le Vaillant]

Mathieu Othacehe  skribis:

> In order for Guix to become an alternative to tools such as Yocto and
> Buildroot, having most or all our packages cross-compiling is a
> prerequisite.
>
> Here is a status of cross-compilation in Guix. For cross-compilation to
> work, the build-system needs to support cross-compilation.
>
> The following build-systems explicitly refuse cross-compiling packages:
>
> haskell, agda, waf, chicken, rakudo, julia, python, emacs, rebar, cargo, 
> ruby, renpy, dub, android-ndk, scons, dune, ant, pyproject, maven, asdf, r, 
> ocaml, node
>
> while the rest of the build-systems do accept cross-compiling packages:
>
> clojure, qt, copy, minetest-mod, tree-sitter, raw, linux-module, glib-or-gtk,
> asdf/source, go, cmake, minify, perl, trivial, guile, elm, font, gnu, 
> asdf/ecl,
> asdf/sbcl, meson, mozilla, texlive

Hi.
I'm surprised to see asdf/* in the list of build systems accepting
to cross-compile packages. How did you test them?

Because I get (on a x86-64 machine):
--8<---cut here---start->8---
$ guix build --target=aarch64-linux-gnu sbcl-alexandria
guix build: error: gnu/packages/lisp-xyz.scm:168:2: sbcl-alexandria@1.4: build 
system `asdf/sbcl' does not support cross builds

$ guix build --target=aarch64-linux-gnu ecl-alexandria
guix build: error: gnu/packages/lisp-xyz.scm:168:2: ecl-alexandria@1.4: build 
system `asdf/ecl' does not support cross builds
--8<---cut here---end--->8---

I'm not even sure if sbcl and ecl have the ability to compile Common
Lisp code for an architecture different from the one they are running
on.


signature.asc
Description: PGP signature

September London Guix/Guile meetup

[Arun Isaac]

Hi all,

Guixers of the world (or more simply, from the London area) unite!
烙

Unbelievable, we've reached our fourth event already, which will be held
at the very heart of the City of London. Join us to talk about Guix,
Guile, Scheme & Lisp, and all things Free Software. Bring your laptop
for some in-person hacking if you like - and your best collection of
parentheses! :)

Participants will need to be registered at the reception, so please RSVP
asap with your details (your full name or, if you wish, a nickname—no
further details are required).

Location:

c/o HubHub
20 Farringdon Street, EC4A 4AB, London

Date/Time: Monday, September 25, 2023 from 6:00 PM to 8:30 PM
Mobilizon page: https://mobilizon.fr/events/552977a1-3398-47bf-a7c1-ee5afee211d9

For any questions, please get in touch via any of the following
channels:

- Arun: arunis...@systemreboot.net
- Fabio: m...@fabionatali.com and https://octodon.social/@fabionatali
- Guix Devel mailing list: https://lists.gnu.org/mailman/listinfo/guix-devel/

We look forward to seeing you!

Regards,
Arun

Re: Mumi CLI client (was: How can we decrease the cognitive overhead for contributors?)

[Giovanni Biscuolo]

Hello Ricardo,

Ricardo Wurmus  writes:

> Giovanni Biscuolo  writes:
>
>> […] actually Debbugs or Mumi web interfaces are read-only: you cannot
>> open a bug report or comment it, you have to send an email; this is a
>> _feature_, not a bug since we don't need a _complex_ web based
>> authentication+authorization system for bug reporters/commenters. […]
>
> Mumi actually does support commenting on the web:
>
>
> https://git.savannah.gnu.org/cgit/guix/mumi.git/tree/mumi/web/controller.scm#n145
>
> It’s just been disabled because messages ended up being stuck in the
> queue and nobody could make enough time to debug this.

Uh, I didn't know mumi have that feature

AFAIU mumi does not (still?) have ad authentication/authorization,
right?

If so how do you plan to deal with users posting SPAM or similar
unappropriate content?

Thanks! Gio'

-- 
Giovanni Biscuolo

Xelera IT Infrastructures


signature.asc
Description: PGP signature

Re: How can we decrease the cognitive overhead for contributors?

[Maxim Cournoyer]

Hi,

Csepp  writes:

> Giovanni Biscuolo  writes:
>
>> [[PGP Signed Part:Undecided]]
>> Hello Csepp, 
>>
>> Csepp  writes:
>>
>> [...]
>>
>>> I don't think repeating that no forge sucks less advances the
>>> conversation towards any solution other than keeping the status quo,
>>> which can't really be called a solution.
>>
>> Are we really talking about changing the official Guix forge:
>> https://savannah.gnu.org/projects/guix?
>
> I definitely am.

The real place to put efforts toward that goal should be in the GNU
project; this way we can continue to maintain shared resource, knowledge
and tooling as a project.  I think packaging either sourcehut or gitea
and writing a Guix System service for it would provide opportunities to
experiment and perhaps one day move in that direction, so that's
something concrete that you can direct your efforts too.

-- 
Thanks,
Maxim

Re: How can we decrease the cognitive overhead for contributors?

[Maxim Cournoyer]

Hi Simon,

Simon Tournier  writes:

> Hi Liliana,
>
> On Mon, 11 Sep 2023 at 19:53, Liliana Marie Prikler 
>  wrote:
>
>> For "patch does not apply", the forge solution is typically to send a
>> notification to the issuer.
>
> No, that does not match my small experience.  Because often the issuer
> is gone or not responding.  As a reviewer using the forge solution, I am
> still able to pull the issuer branch and then resolve the conflicts if
> any.
>
> Using “our” workflow, I fail earlier in the process.  I am not able to
> apply the patches against any branches (pull the PR somehow).  An
> example:
>
> [bug#62202] [PATCH 0/21] Juliahub import script.
> https://issues.guix.gnu.org/msgid/871qlq89kz@ngraves.fr
>
> Even before looking at it, I have to spend some time to find a way to
> manually apply the patches.  Then, rebasing on the top of master could
> lead to conflict but that another story and the same appears whatever
> the workflow.

I think this kind of problem has improved though, since we deploy by
default our etc/git/config snippet, which sets 'useAutoBase = true'.

At least I don't have a problem when applying patches with 'git am -3s'.
I don't see what is specially difficult here (perhaps there are too many
options available to do the task?), but we could document some ways,
perhaps adding a new 'Reviewing others work' section to the Contributing
node?  It could show how to do it from either an Gnus perspective
(Emacs) or via 'wget -O- $mumi_url | git am -3s' etc.  and provide some
guidance, perhaps with a link to

until this is automated in a 'guix review' command or similar.

-- 
Thanks,
Maxim

Re: hard dependency on Git? (was bug#65866: [PATCH 0/8] Add built-in builder for Git checkouts)

[wolf]

On 2023-09-12 08:56:15 -0400, Maxim Cournoyer wrote:
> Hi,
> 
> Josselin Poiret  writes:
> 
> > Hi,
> >
> > Maxim Cournoyer  writes:
> >
> >> That's no longer true, as of libgit2 v1.7.0 [0].  I already have it
> >> packaged in a branch, but I need to iron out dependent breakages.
> >>
> >> [0]  https://github.com/libgit2/libgit2/releases/tag/v1.7.0
> >>
> >> So given there's no technical reasons not to use libgit2, I'd use that
> >> and keep the closure size down.
> >
> > There's still the `git gc` problem though.
> 
> It's klunky, but a workaround is to locally clone the checkout anew using
> libgit2, as suggested here [0].

While the comment does suggest a workaround, I would recommend to read the
comment right below it before using it.  I am not sure if Guix would be affected
by those mentioned concurrency issues, but sounds like something that needs to
be understood in detail.

> We could also try to contribute to libgit2 toward adding proper support for a
> 'gc' action.
> 
> [0]  https://github.com/libgit2/libgit2/issues/3247#issuecomment-486585944
> 
> -- 
> Thanks,
> Maxim
> 

-- 
There are only two hard things in Computer Science:
cache invalidation, naming things and off-by-one errors.


signature.asc
Description: PGP signature

Re: [workflow] Automatically close bug report when a patch is committed

[Giovanni Biscuolo]

Hi Maxim and Liliana,

Maxim Cournoyer  writes:

>>> Liliana Marie Prikler  writes:

>>> > WDYT about the following
>>> >   Applies: [patch] 
>>> >   Closes: [patch] 
>>> >   Resolves: [patch] 
>>> >   Done: [patch] 

[...]

>> I'm just asking which wording you prefer.  For the tracker, they'd mean
>> the same as "Fixes", but fixes imho sounds like a bug,

But we actually have to close/fix/resolve/mark-as-done a bug
(report), no?  :-D

>> which "Update Emacs to 29.2" isn't.  Thus, something with a more
>> neutral meaning like "Resolves" might apply better here.

IMO this is just an implementation "detail", although an important one.

Keywords are _just_ labels, the semantics is defined elsewhere (even
when it's "implicit") and the semantics establish the behaviour we
intend to implement via our algorithm we use to (re)program the git hook
in order to automatically close a bug report when the committer pushes
all needed patches in a bug of class "PATCH" or find it's appropriate to
mark it as done when committing another class of bug (sorry for being so
convoluted :-O )

Anyway, I agree with Liliana that having more keyworks will help humans
better capture (and remember) the implied semantics (that we should
definitely document, anyway); for this reason my proposal is to accept
all this _lowercased_ keywords (all followed by a ":" with NO spaces in
between): fix, fixes, close, closes, resolve, resolves, do, done.

This means that a committer can write for example "RESOLVES:" and the
meaning is the same as "do:" or "Fixes:".

IMO the "superficial" semantic of the keyword apply/applies is ambiguos:
does this mean:

1. the commit is part of a series of patches tracked in #bug-num thus
the rest of the series is still to be worked upon (please don't close
the bug report)

or

2. the commit is the last one of all the patches tracked in #bug-num
thus no other patch is left to be committed (please close the bug
report)

WDYT?

> If we choose this simple scheme where the top commit of a series can be
> annotated with Debbugs control commands, I'd opt for:
>
> --8<---cut here---start->8---
> Applies: #bug-number
> --8<---cut here---end--->8---

Uh I think I get it: you mean we could use a keyword in the commit
message to allow the committer to effectively link a commit to a
#bug-number, right?

This is something we sould consider, but it's another topic: how to
effectively link commits to #bug-num (I guess we already talked about
this in some other thread)

> I'm not sure what [patch] or namespace add (is it for a fancy URL?), so
> I'd drop them.

I'll try to recap, sorry for the repetitions!

Namespace has been assumed as part of the proposed URI to try address
Vagrant's concerns [1]:

--8<---cut here---start->8---

   So... I maintain the guix package in Debian, and want to make sure
   that whatever bug-closing indicator guix upstream uses, does not end up
   triggering when I push new upstream versions to salsa.debian.org ... and
   start incorrectly marking incorrect bug numbers on bugs.debian.org that
   were meant for debbugs.gnu.org.

--8<---cut here---end--->8---

Here we have a use case in which a Guix committer is also committer of
other projects using a similar git hook, with (a subset of) the _very
same_ keywords we choose for our hook.

That's why I proposed [2] a namespaced URI, possibly not including the
URL:

--8<---cut here---start->8---

Fixes: [optional bug description] 

--8<---cut here---end--->8---
(here, URI is :#)

...but then you, Maxim, suggested [3] this form:

--8<---cut here---start->8---
Fixes: bug#65738 (java-ts-mode tests)
--8<---cut here---end--->8---
(here, URI is bug#8---

: bug#@ ()

--8<---cut here---end--->8---

I'm an Emacs user also and when I enable bug-reference-mode in this
message buffer I still see the "bug#" part of the string:

bug#65738@guix

is shown as an URL (pointing nowhere since I still did not configure my
Emacs properly)

Maxim: do you think my proposal could work also for Emacs
bug-reference-mode "machinery"?

And everyone: do you think that the above proposal for an "Emacs
compatible" namestaced URI could be fine for all considered usercases?

>>> If so, that's adding rather than reducing friction, and I'm not sure
>>> it'd gain much traction.  The way I see it, it needs to happen
>>> automatically.
>> I mean, the way I imagine is that you type this as part of your message
>> and then debbugs would do the work of closing the bug.  In short, "git
>> push" saves you the work of writing a mail because there's a hook for
>> it.

I guess all of us are looking for this very same thing: a server side
web hook that automatically closes bugs (via 

Re: hard dependency on Git? (was bug#65866: [PATCH 0/8] Add built-in builder for Git checkouts)

[Maxim Cournoyer]

Hi,

Josselin Poiret  writes:

> Hi,
>
> Maxim Cournoyer  writes:
>
>> That's no longer true, as of libgit2 v1.7.0 [0].  I already have it
>> packaged in a branch, but I need to iron out dependent breakages.
>>
>> [0]  https://github.com/libgit2/libgit2/releases/tag/v1.7.0
>>
>> So given there's no technical reasons not to use libgit2, I'd use that
>> and keep the closure size down.
>
> There's still the `git gc` problem though.

It's klunky, but a workaround is to locally clone the checkout anew
using libgit2, as suggested here [0].  We could also try to contribute
to libgit2 toward adding proper support for a 'gc' action.

[0]  https://github.com/libgit2/libgit2/issues/3247#issuecomment-486585944

-- 
Thanks,
Maxim

Re: btrfs recommended layout for snapshots?

[Andrew Tropin]

On 2023-08-18 01:58, Nicolas Graves wrote:

> On 2023-08-16 10:10, Nicolas Graves wrote:
>
>> I guess it's possible to do the same with my home as well (thus only
>> saving actual data and not consecutive linking metadata), but that might
>> require some more time and fine-grained applications considerations.
>>
>> One weakness from this impermanence feature is that it's actually
>> application-dependent. For guix-system it's not very damaging (except if
>> we want very low-level optimizations, like setting nodatacow on
>> subvolumes with databases etc), but for guix-home, it makes things much
>> more difficult. @Andrew Tropin : maybe that's something we could in RDE in
>> a state-btrfs in (gnu home-services state) if we find a way to migrate
>> directories to subvolumes safely and reproducibly.
>
> Some notes about more progress I've done.
>
> My attempt to also load the /home subvolume on tmfps has quite
> progressed. I've created the following subvolumes :
>
> ;; App related (apps who doesn't entirely follow the XDG base directory
> ;; specification and save data or cache outside of XDG_DATA_HOME,
> ;; XDG_STATE_HOME and XDG_CACHE_HOME. Other users may need other app dirs.
>
> /home/graves/.config/chromium
> /home/graves/.config/emacs
> /home/graves/.config/libreoffice
> /home/graves/.config/guix
> /home/graves/.ssh
>
> ;; XDG_CACHE_HOME, XDG_STATE_HOME, XDG_DATA_HOME (I'm using RDE)
>
> /home/graves/.cache
> /home/graves/.local
>
> ;; And some personal want-to-save directories.
>
> /home/graves/archives
> /home/graves/resources
> /home/graves/projects
> /home/graves/spheres
>
> The only thing that seems to get in my way to achieve this properly
> is... .guix-home! Which I don't want to backup since it's only a link
> and that would require at least /home/graves/ to be snapshotted.
>
> I thus have a proposition for discussion :
> Make .guix-home XDG base dir compliant by storing a symlink
> in $XDG_CONFIG_DIR/guix/home to /var/guix/per-user/$user/guix-home
> instead of the current default of the symlink
> in /home/$user/.guix-home to the actual object in the store.
>
> This was discussed in a previous mail thread :
> "RFC: Configurable placing of the ~/.guix-home symlink"
> With Andrew concluding that
>
>>  Back in the day, the implementation of Guix Home required a symlink in
>>  home directory, right now due to improvements in symlink-manager and
>>  reconfigure code it's probably not necessary and with a few patches
>>  /var/guix/profiles/per-user/bob/guix-home/ can be used instead.
>
> With a first glance, I think it's possible to do in the code, since the
> home-run-on-first-login-service-type already gets the UID of the user,
> and with the following guile function :
>
> Scheme Procedure: passwd:name pw
> The name of the userid.
>
> we should be able to get the name of the user and replace
> ~/.guix-home with /var/guix/per-user/$user/guix-home everywhere.
> So the code where a hardlink is needed will be, and the "pleasing UX of
> searching within guix home" would also be possible.
>
> I also don't really see the reason why .guix-home shouldn't be
> $XDG_CONFIG_DIR/guix/home since it's really user-specific and unique
> (and XDG user dirs are too), unlike .guix-profile.

I don't have all the context loaded in my head right now, but it's
probably possible now, and we can try to implement it.  Feel free to
send a patch and Cc me or continue the discussion on "RFC: Configurable
placing of the ~/.guix-home symlink".

>
> This may be the one of the only missing step to make the (manual and
> only with directories (btrfs subvolumes), at least for now)
> implementation of impermanence (a quick reminder of the idea implemented
> by nix here : https://nixos.wiki/wiki/Impermanence) on with guix home, I
> would appreciate some feedback comments on the idea ;) (another step
> would be to actually activate the home environment on login in
> home-shell-profile-service-type, but migrating .guix-home would be a
> requirement).

-- 
Best regards,
Andrew Tropin


signature.asc
Description: PGP signature

Re: How can we decrease the cognitive overhead for contributors?

[Csepp]

Giovanni Biscuolo  writes:

> [[PGP Signed Part:Undecided]]
> Hello Csepp, 
>
> Csepp  writes:
>
> [...]
>
>> I don't think repeating that no forge sucks less advances the
>> conversation towards any solution other than keeping the status quo,
>> which can't really be called a solution.
>
> Are we really talking about changing the official Guix forge:
> https://savannah.gnu.org/projects/guix?

I definitely am.

Re: comparing commit-relation using Scheme+libgit2 vs shellout plumbing Git

[Attila Lendvai]

is the decision between libgit2 and invoking git really such a big commitment?

let's make sure the entire guix codebase uses a single git related API, and 
then we can easily switch back and forth between the two.

on another note, i'm surprised that the reference implementation of git itself 
doesn't have a lib, and libgit2 even had to be written. even this may change in 
the future.

-- 
• attila lendvai
• PGP: 963F 5D5F 45C7 DFCD 0A39
--
“I learned long ago, never to wrestle with a pig. You get dirty, and besides, 
the pig likes it.”
— George Bernard Shaw (1856–1950)

Re: Ideas for ocaml-team

[Julien Lepiller]

I don't think it makes sense to have a separate brarch when we have so few 
contributions, and so few impacted packages

Le 12 septembre 2023 08:57:56 GMT+02:00, pukkamustard  
a écrit :
>
>Salut!
>
>Simon Tournier  writes:
>
>>> I think it's time to start an `ocaml-team` (or `ocaml-updates`) branch
>>> to collect some bigger updates and changes to the OCaml packages in
>>> Guix.
>>
>> I think that’s a great idea. :-)  Any progress on this?
>>
>
>There is #64249 (https://issues.guix.gnu.org/64249) to which I just
>submitted a v6.
>
>>> * Remove most ocaml4.07-* and ocaml4.09 packages
>>>   - We only want to keep the compiler around for bootstrapping purposes.
>>
>> Currently camlboot is used by ocaml-4.07-boot used by ocaml-4.07.  But
>> then version 4.09 and later and not bootstrapped; well they use the
>> upstream bootstrap (which is boot/ocamlc and friends IIRC).
>>
>> Well, independently of this upgrade plan, the OCaml bootstrap could be
>> the chain 4.07 -> 4.09 -> … and I do not know if 4.09 would be enough
>> for 4.14.  And if 4.14 would also be enough for 5.
>
>I don't know either and I don't think I will have time to look into this
>soonish.
>
>I think placing the 4.07 and 4.09 compiler in (gnu packages ocaml-boot),
>even if unused, seems reasonable. We should add some nice
>comments/breadcrumbs for whoever looks into completing the chain in the
>future.
>
>> That’s said, aside this bootstrapping consideration, I am in favor to
>> remove 4.07 and 4.09 OCaml packages.
>
>Ack
>
>> Do we create the branch ocaml-team for doing this plan?
>
>Just asked a similar question in the cover for the v6 to
>#64249. Basically I don't know how fast I/we will be able to look into
>the other items in this list. Maybe it makes sense to just merge in to
>master instead of having a too long-lived ocaml-team branch? Or set a
>pre-defined time-to-live for the branch? What's the current modus
>operandi for other teams?
>
>Cheers,
>pukkamustard

Re: How can we decrease the cognitive overhead for contributors?

[Giovanni Biscuolo]

Hello Csepp, 

Csepp  writes:

[...]

> I don't think repeating that no forge sucks less advances the
> conversation towards any solution other than keeping the status quo,
> which can't really be called a solution.

Are we really talking about changing the official Guix forge:
https://savannah.gnu.org/projects/guix?

When talking about "what forge to use" I feel that keeping the status
quo is a very good solution, overall.

Thanks, Gio'

-- 
Giovanni Biscuolo

Xelera IT Infrastructures


signature.asc
Description: PGP signature

Re: hard dependency on Git? (was bug#65866: [PATCH 0/8] Add built-in builder for Git checkouts)

[Josselin Poiret]

Hi,

Maxim Cournoyer  writes:

> That's no longer true, as of libgit2 v1.7.0 [0].  I already have it
> packaged in a branch, but I need to iron out dependent breakages.
>
> [0]  https://github.com/libgit2/libgit2/releases/tag/v1.7.0
>
> So given there's no technical reasons not to use libgit2, I'd use that
> and keep the closure size down.

There's still the `git gc` problem though.

My opinion is that the preferred API for Git is still the UNIX one via
plumbing commands.  Anything else is trying to catch up to it, and then
we get into this conundrum that we want to do everything in Scheme, but
we're unable to do it as well as Git itself.  If I had to choose, a
Guile library wrapping the Git commands would be the best, especially
since we're managing long-living checkouts, something libgit2 doen't
seem too interested in.

Best,
-- 
Josselin Poiret


signature.asc
Description: PGP signature

Re: hard dependency on Git? (was bug#65866: [PATCH 0/8] Add built-in builder for Git checkouts)

[Simon Tournier]

Hi Vagrant,

On Mon, 11 Sep 2023 at 12:35, Vagrant Cascadian  wrote:

> What about making git an optional dependency, and only calling out to
> "git gc" if git is available in PATH?

Somehow, that’s more or less the case, IIUC,

--8<---cut here---start->8---
15 candidates:
./build/android-repo.scm:57:  (invoke git-repo-command "init" "-u" 
manifest-url "-b" manifest-revision
./build/android-repo.scm:59:  (invoke git-repo-command "sync" "-c" 
"--fail-fast" "-v" "-j"
./build/git.scm:55:  (invoke git-command "init" "--initial-branch=main")
./build/git.scm:56:  (invoke git-command "remote" "add" "origin" url)
./build/git.scm:58:  (invoke git-command "checkout" "FETCH_HEAD")
./build/git.scm:62:(invoke git-command "fetch" "origin")
./build/git.scm:63:(invoke git-command "checkout" commit)))
./build/git.scm:66:(invoke git-command "submodule" "update" "--init" 
"--recursive")
./git-download.scm:175: (invoke "git" "-C" #$output 
"init")
./git-download.scm:176: (invoke "git" "-C" #$output 
"config" "--local"
./git-download.scm:178: (invoke "git" "-C" #$output 
"config" "--local"
./git-download.scm:180: (invoke "git" "-C" #$output 
"add" ".")
./git-download.scm:181: (invoke "git" "-C" #$output 
"commit" "-am" "init")
./git-download.scm:182: (invoke "git" "-C" #$output 
"read-tree" "--empty")
./git-download.scm:183: (invoke "git" "-C" #$output 
"reset" "--hard")
--8<---cut here---end--->8---

An “optional dependency”, is it not already the case?

I read hard-dependency as the idea behind a change like [1].  For
instance, something like:

--8<---cut here---start->8---
diff --git a/guix/self.scm b/guix/self.scm
index 81a36e007f..41c5f40786 100644
--- a/guix/self.scm
+++ b/guix/self.scm
@@ -68,6 +68,7 @@ (define %packages
   ("gzip"   . ,(ref 'compression 'gzip))
   ("bzip2"  . ,(ref 'compression 'bzip2))
   ("xz" . ,(ref 'compression 'xz))
+  ("git-minimal". ,(ref 'version-control 'git-minimal))
   ("po4a"   . ,(ref 'gettext 'po4a))
   ("gettext-minimal". ,(ref 'gettext 'gettext-minimal))
   ("gcc-toolchain"  . ,(ref 'commencement 'gcc-toolchain))
@@ -825,6 +826,9 @@ (define* (compiled-guix source #:key
   (define guile-lzma
 (specification->package "guile-lzma"))

+  (define git
+(specification->package "git-minimal"))
+
--8<---cut here---end--->8---

In the context of the proposal patch#65866 [1], this hard-dependency
makes sense.  From my point of view, once we have git-minimal as a
hard-dependency, I do not see the point to keep slower Git operations
using libgit2; as ’commit-relation’ for one example.

But maybe I am missing something.

Cheers,
simon


1: [bug#65866] [PATCH 5/8] build: Add dependency on Git.
Ludovic Courtès 
Mon, 11 Sep 2023 16:25:23 +0200
id:4eca94501c2c1e9986e1f718eeccb3eb9276dcd4.1694441831.git.l...@gnu.org
https://issues.guix.gnu.org//65866
https://issues.guix.gnu.org/msgid/4eca94501c2c1e9986e1f718eeccb3eb9276dcd4.1694441831.git.l...@gnu.org
https://yhetil.org/guix/4eca94501c2c1e9986e1f718eeccb3eb9276dcd4.1694441831.git.l...@gnu.org

Re: Guidelines for pre-trained ML model weight binaries

[Nathan Dehnel]

That was fascinating, thanks for sharing.

Re: Ideas for ocaml-team

[pukkamustard]

Salut!

Simon Tournier  writes:

>> I think it's time to start an `ocaml-team` (or `ocaml-updates`) branch
>> to collect some bigger updates and changes to the OCaml packages in
>> Guix.
>
> I think that’s a great idea. :-)  Any progress on this?
>

There is #64249 (https://issues.guix.gnu.org/64249) to which I just
submitted a v6.

>> * Remove most ocaml4.07-* and ocaml4.09 packages
>>   - We only want to keep the compiler around for bootstrapping purposes.
>
> Currently camlboot is used by ocaml-4.07-boot used by ocaml-4.07.  But
> then version 4.09 and later and not bootstrapped; well they use the
> upstream bootstrap (which is boot/ocamlc and friends IIRC).
>
> Well, independently of this upgrade plan, the OCaml bootstrap could be
> the chain 4.07 -> 4.09 -> … and I do not know if 4.09 would be enough
> for 4.14.  And if 4.14 would also be enough for 5.

I don't know either and I don't think I will have time to look into this
soonish.

I think placing the 4.07 and 4.09 compiler in (gnu packages ocaml-boot),
even if unused, seems reasonable. We should add some nice
comments/breadcrumbs for whoever looks into completing the chain in the
future.

> That’s said, aside this bootstrapping consideration, I am in favor to
> remove 4.07 and 4.09 OCaml packages.

Ack

> Do we create the branch ocaml-team for doing this plan?

Just asked a similar question in the cover for the v6 to
#64249. Basically I don't know how fast I/we will be able to look into
the other items in this list. Maybe it makes sense to just merge in to
master instead of having a too long-lived ocaml-team branch? Or set a
pre-defined time-to-live for the branch? What's the current modus
operandi for other teams?

Cheers,
pukkamustard