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

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]

Re: Cross compilation status

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

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

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

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

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

Re: CI job for lisp-team branch

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?

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

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

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

September London Guix/Guile meetup

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

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

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

Re: performance issue with TeX Live

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

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

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

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

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

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

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

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

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

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

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

performance issue with TeX Live

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

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

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

Re: btrfs recommended layout for snapshots?

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

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

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

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

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:

Re: Ideas for ocaml-team

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

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

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

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

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

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

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

[emacs]: snapshots against latest versions

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

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

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:

Re: Ideas for ocaml-team

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

Re: Guidelines for pre-trained ML model weight binaries

That was fascinating, thanks for sharing.