Re: Better support remote deployment

Hi, Efraim Flashner writes: [...] >> 'guix package' is already the command we use to create profiles; maybe >> it could accept a '--remote' argument to operate on a remote machine? >> Or is this not what 'GUIX_DAEMON_SOCKET=ssh://your-target guix package >> -m manifest.scm' can already

Re: Turning off tests leads to a different store item

Hi, Simon Tournier writes: > Hi, > > On Wed, 8 Nov 2023 at 20:20, Saku Laesvuori wrote: > >> There is another way: simply preventing the tests from changing the >> resulting store item. For example, the package could first be built >> without tests and then that build tree could be copied to

Re: Better support remote deployment

Hello, Felix Lechner writes: > Hi, > > On Tue, Nov 07 2023, Maxim Cournoyer wrote: > >> Then your suggestion to extend 'guix package' to be able to >> install a profile from a store profile sounds useful, or perhaps a new >> 'guix deploy-profile' (or a better n

Re: Patch Review Flow

Hi jgart, "jgart" writes: > Hi Guixers, > > Does anyone follow this workflow for reviewing patches? > > git clone https://git.guix-patches.cbaines.net/guix-patches/ > git checkout issue-x > git format-patch ... > # then in the development checkout of Guix: > git am ...; make; ./pre-inst-env

Re: Divvying up service definitions

Hi Bruno, Bruno Victal writes: > Hi, > > As the gnu/services and gnu/home/services grow, I think we should > consider divvying the services into stand-alone modules or > subdirectories. > > Consider the ⌜dovecot-service-type⌝ in gnu/services/mail.scm: as of > commit

Re: RFI response: Strengthening the Free Software Supply Chain via Guix and GNUnet

Hi Sergio, Sergio Pastor Pérez writes: > Hi, Maxim. > > This has been an interesting read. I would like to encourage you to keep > us updated. > > Thanks for sharing! My pleasure! I will keep you updated, if anything happens from it. -- Thanks, Maxim

RFI response: Strengthening the Free Software Supply Chain via Guix and GNUnet

Hello, Just for your info, I'm relaying the response I've sent for consideration to the US government [0] in reply to their RFI (Request For Information) [1]. It's about adding support for GNUnet for sharing Guix substitutes. I had no prior experience authoring these so it is probably written

Re: Expressing system test dependencies

Hi Bruno, Bruno Victal writes: > Hi, > > There are system tests that would benefit from being able to express > that their results are dependent on the result of other tests, when > these constitute independent units, especially when there are > configuration variants present. (e.g.

Re: mesa-updates: call for patches

Hi John, John Kehayias writes: > Hi Guix-ers, > > Time for another round of Mesa and friends updates! I've been waiting > for another Mesa release but seems the 23.2 series has stalled out and > now is a good time before 23.3 or 24. I've been using 23.2.1 for some > packages locally without

Re: [RFC]: Skipping rust crate tests by default

Hi Efraim! Efraim Flashner writes: [...] >> > error: unnecessary parentheses around index expression >> > --> >> > /tmp/guix-build-rust-nalgebra-0.21.1.drv-0/nalgebra-0.21.1/src/linalg/convolution.rs:49:53 >> >| >> > 49 | conv[i] += self[u] * kernel[(i - u)]; >>

Re: Re-evaluating the practice of automating user configuration

Hello, Tomas Volf writes: [...] > I have to admit I was surprised, and not in a pleasant way. When I started > playing with Guix, I went over the etc/git/gitconfig and copied the parts I > liked into the .git/config. For some reason I do not like tools automatically > touching the .git

Re: Re-evaluating the practice of automating user configuration

Hi Liliana, Liliana Marie Prikler writes: > Hi Guix, > > as we all are more or less aware of, Guix automates quite much of the > user's configuration for comfortably hacking on our codebase. As has > been argued elsewhere, both by myself and fellow Guix, this is not > always a good thing. > >

Re: [RFC]: Skipping rust crate tests by default

Hi Efraim, Efraim Flashner writes: [...] >> This sounds good except I don't understand how disabling the tests by >> default help to "make sure that the packages have the correct inputs" ? > > When the tests are disabled, if a package shows red on the CI it means > that either: > A) there was

Re: [PATCH cuirass] doc: Fix remaining evaluation hook example.

Hello, vicvbcun writes: > This is a follow-up to commit 0b63c3b6989af77d4e1c9a98dd25c8f26b37d930. > > * doc/cuirass.texi (Triggering an Evaluation): Fix URL in example. Also applied! -- Thanks, Maxim

Re: [PATCH cuirass] doc: Fix evaluation hook URL example.

Hi, vicvbcun writes: > * doc/cuirass.texi (Invocation): Fix URL in the example of the push hook. > --- > doc/cuirass.texi | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/doc/cuirass.texi b/doc/cuirass.texi > index 69c58f7..00f00c1 100644 > --- a/doc/cuirass.texi > +++

Re: How to send revision patches to old issues in DEBBUGS so Guix QA can look at them?

Hi, Andy Tai writes: > Maxim, I know about this. Problem is Guix QA does not look at old issues OK; sorry for the noise. It's an improvement that is desired in in QA, I see. -- Thanks, Maxim

Re: performance issue with TeX Live

Hi Emmanuel, Emmanuel Beffara writes: > De Maxim Cournoyer le 16/10/2023 à 15:46: >> My next question would be; how is this ls-R file produced in Guix? > > That I do not know, but I would assume mktexlsr is called at some point when > building the profile. > >> Does

Re: [RFC]: Skipping rust crate tests by default

Hi Efraim, Efraim Flashner writes: > Currently for for rust crates we build the crates, run the tests, and > then in %output we only have the license files and a repackaged version > of the source. > > The build system goes: > unpack source > unpack crates > patch shebangs > patch checksums of

Re: How to send revision patches to old issues in DEBBUGS so Guix QA can look at them?

Hi Andy, Andy Tai writes: > Hi, per Chris's recent comments, Guix QA only looks at (a window of) > recently created issues due to storage space limitations, which is > understandable. > > However, if I have update (package definition) patches to not very > recent issues, such as some stale

Re: performance issue with TeX Live

Hi, Emmanuel Beffara writes: > Hello, > > De Maxim Cournoyer le 14/10/2023 à 18:06: >> > I tried to explore this but I see no reason why the ls-R files would be >> > ignored and I don't know how to explore this further. I do want to >> > contribute >>

Re: performance issue with TeX Live

Hi, Emmanuel Beffara writes: > Hello, > > De Nicolas Goaziou le 13/09/2023 à 14:39: >> Emmanuel Beffara writes: >> >> > 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

Re: Fw: Question regarding qmk firmware

Hi Ekaitz, Ekaitz Zarraga writes: > Hi > > I want to forward this message to guix-devel because it is a clear > case of some (actually good) technical decision affecting users in > unexpected ways. > > Now, after the change, a user might run `guix search avr-toolchain` and find > nothing.

Re: Need people to help with kernel updates

Hi, Luis Felipe writes: > El 9/10/23 a las 1:22, John Kehayias escribió: >> Hi Leo, >> >> >> On Sat, Oct 07, 2023 at 02:04 PM, Leo Famulari wrote: >> >>> Hello, >>> >>> For a few years, I've been handling updates of the linux-libre kernel by >>> myself. Now I want some more people to help with

doc: Mention the responsibilities that blocking comes with.

Hello, I thought I'd advertise this proposed change here: that touches to our common rules, so that everyone gets to see it/comment on it. -- Thanks, Maxim

Proposal to introduce a Change-Id in our commit messages

Hi, As was discussed in [1], a proposal that emerged is adding a new commit-msg hook to our auto-configuration, so that a 'Change-Id' git trailer would always get added to new commits. This part has been implemented already bug#66027; if you have comments/concerns, now is a good time to share

Re: core-updates invites to an ungrafting party

Hi, Simon Tournier writes: > Hi, > > On Sun, 08 Oct 2023 at 11:12, Maxim Cournoyer > wrote: > > >> such as fixes to >> git-minimal (bug#65924) > > Why not also update git-minimal/pinned? > > Well,

Re: Restart of v4l-utils build

Hello, Reza Housseini writes: > Hi List > > I wanted to install python-sphinx-gallery but deep down in the > dependency list v4l-utils is failing [1]. Locally it builds fine > therefore I assume the build only needs to be restarted. > > Thanks, > Reza > > [1]

Re: Guix Data Service can now poll for new revisions/branches

Hi Christopher, Christopher Baines writes: > Hey, > > As has happened before in the past, at the moment we're not getting > emails to guix-commits for the main guix.git repository. This impacts > the data service instances as they use these emails to know when there > are new revisions to

Re: Golang mudules to follow common grouping

Hi, Sharlatan Hellseher writes: > Hi Guix! > > I've noticed the number of Golang packages start growing. I expect more > packages > to be reviewed and merged by quick check of Issues. > > I think it's time to split (gnu packages golang) into some logical groups, see > Python, Lisp for example.

[PATCH] doc: Mention the responsibilities that blocking comes with.

Hello! This is a heads-up regarding a modification to or contributing guidelines I am considering to make: Maxim Cournoyer writes: > * doc/contributing.texi (Commit Access): Mention that blocking comes with > extra responsibilities. > > Change-Id: I27cafcb351f68057b7882198e72e

Re: Opportunity For Guix: RFI Areas of long-term focus and Prioritization

Hi jgart, "jgart" writes: > Hi Guixers, > > Just reposting this chat message from Ryan Prior over #guix for anyone > interested: > >> The US Federal government has an RFI open on "Areas of long-term > focus and Prioritization". They're looking for 10 page briefing memos > on supporting

Re: core-updates invites to an ungrafting party

Hi John, John Kehayias writes: > Hi Maxim et al, > > On Sun, Oct 08, 2023 at 11:12 AM, Maxim Cournoyer wrote: > >> Hello Guix! >> >> The core-updates branch is still alive, and has accumulated (or plans >> to) a few changes that cause world-rebuilds, such a

Re: IDEA: missing-tests-pypi-error? condition

Hi, "jgart" writes: >> You want `info -f doc/guix.info`. > > Ah yes, I actually used that flag once before and had forgotten it... FWIW, it works for me even without '-f'. -- Thanks, Maxim

Re: IDEA: missing-tests-pypi-error? condition

Hi, "jgart" writes: >> 'make'), and you can review the new work with 'info doc/guix.info'. > > Hi, > > Is there a way to open the guix manual directly? Did you try it? It works for me. Or just 'info guix' to open the Guix manual from found from INFOPATH. -- Thanks, Maxim

core-updates invites to an ungrafting party

Hello Guix! The core-updates branch is still alive, and has accumulated (or plans to) a few changes that cause world-rebuilds, such as fixes to git-minimal (bug#65924) as well as docbook improvements (bug#65479) and fixes to the build systems so that deep input rewriting works as intended

Re: IDEA: missing-tests-pypi-error? condition

Hi, Munyoki Kilyungi writes: > Hi Maxim! > > Maxim Cournoyer > aliandika: > >> Hi, >> >> Munyoki Kilyungi writes: >> >>> "jgart" aliandika: >>> >>>> Hi Guixers, >>>> >>>> I was recently rev

Re: IDEA: missing-tests-pypi-error? condition

Hi, Munyoki Kilyungi writes: > "jgart" aliandika: > >>> Sometimes, PyPI versions lag behind upstream versions. >> >> Hi Bonz, >> >> Yes, in my experience that has sometimes been the case because maintainers >> don't make timely releases to PyPI. >> >>> What's the policy on this. Shouldn't we

#$(this-package-input "subversion") in git introduces a cycle

-ID: <703534c8b1b8355293d3014ef5e59a0f8dd263de.1696644353.git.maxim.courno...@gmail.com> From: Maxim Cournoyer Date: Fri, 6 Oct 2023 11:02:51 -0400 Subject: [PATCH] gnu: git: Remove labels and use gexps. * gnu/packages/version-control.scm (git) [native-inputs, inputs]: Remove labels. [arguments]: Use gexps. Use gexp

Re: IDEA: missing-tests-pypi-error? condition

Hi, Munyoki Kilyungi writes: > "jgart" aliandika: > >> Hi Guixers, >> >> I was recently reviewing a patch by a contributor and was discussing the >> notion of preferring upstream to PyPI when tests are missing on PyPI. >> > What's the policy on this. Shouldn't we prefer > upstream over PyPI?

Re: New section to easily reference Debbugs URLs within Emacs Debbugs

Hi, Mekeor Melire writes: > Thanks, Maxim, for implementing some of my suggestions in commit > 06dc36ffb7cde821a4762b299d1c95b3788ba110, as I coincidentally found > out when reading the commit log. > > By the way, I still believe it's less off-putting for average people > to see two lines of

Re: more than 1,800 dependent packages: website out of date

Hi, Simon Tournier writes: > Hi, > > On Tue, 26 Sept 2023 at 11:55, Attila Lendvai wrote: >> > > When will the above website be updated to use the latest manual >> > > information about branches? >> > >> > What do you mean? >> > >> > 1. The manual you are pointing is the released v1.4.0

Re: is core-updates still a thing?

Hi Katherine, Katherine Cox-Buday writes: > On 9/24/23 1:27 AM, Andy Tai wrote: >> Hi, curious if core-updates still a thing?There seems a branch by >> that name and the manual still says patches causing large number of >> rebuilds should go to core-updates, at least for these not aiming at

Re: is core-updates still a thing?

Hi Andy, Andy Tai writes: > Hi, curious if core-updates still a thing?There seems a branch by > that name and the manual still says patches causing large number of > rebuilds should go to core-updates, at least for these not aiming at a > specific feature branch. It is. We can't have

Re: Notmuch, Debbugs: my helpers (was Re: New section to easily reference Debbugs URLs within Emacs Debbugs)

Hi Simon, Simon Tournier writes: > Hi, > > On Sun, 17 Sep 2023 at 16:51, Maxim Cournoyer > wrote: > >> If you use Emacs and Emacs-Debbugs, you may be interested in applying >> the settings newly documented in the 'Viewing Bugs within Emacs' section >> of

New section to easily reference Debbugs URLs within Emacs Debbugs

Hello, If you use Emacs and Emacs-Debbugs, you may be interested in applying the settings newly documented in the 'Viewing Bugs within Emacs' section of the manual; see it at the bottom of info "(guix) The Perfect Setup"). I hope that's useful, -- Thanks, Maxim

Re: Can we provide another UI for patches than just email ?

Hi Saku, Saku Laesvuori writes: >> I'd like to be part of the solution, so Saku, I'd like to help >> write the putative scripts you talk about. The main difficulty I see is >> that they need to be configured to be able to send and receive email on >> the user's behalf. > > That could probably

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

Hi Ludovic, Ludovic Courtès writes: > Hi! > > Maxim Cournoyer skribis: > >> So given there's no technical reasons not to use libgit2, I'd use that >> and keep the closure size down. > > For the record, that’s a 6% increase: > > $ guix size guix | tail -1 &

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

Hello, Le 14 septembre 2023 12:30:41 GMT-04:00, Vagrant Cascadian a écrit : […] >> I doubt the Change-Id idea would help much closing *bugs* on the >> bug-guix tracker, but I'd expect it to be useful to close already merged >> (but forgotten on the guix-patches tracker) *patches*. > >Well,

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

Hi, Simon Tournier writes: > Hi, > > On Wed, 13 Sep 2023 at 21:14, Liliana Marie Prikler > wrote: > >> I do wonder how the ChangeId would work in practice. Since it's not >> really assigned by the committer, it would have to be generated "on the >> fly" and attached to the mail in between,

Re: Implementing the guix-dameon in Guile

Hi! Felix Lechner via "Development of GNU Guix and the GNU System distribution." writes: > Hi Chris, > > On Wed, Sep 13, 2023 at 9:29 AM Christopher Baines wrote: >> >> Rewrites are risky because you only get the value right at the end, >> therefore the priority is to get a minimal but viable

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

Hi, Vagrant Cascadian writes: > 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: >>>> >>

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

Hi Fannys, Fannys writes: > Ekaitz Zarraga writes: > >>> > This is what I mean when I say many times emacs is kind of mandatory, >>> > and >>> > this thread is kind of a demonstration of what I meant because the main >>> > discussion evolved to: you can use this or that in emacs to ease the

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

Hi Liliana, Liliana Marie Prikler writes: > 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 t

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

Hi Giovanni, Giovanni Biscuolo writes: [...] Liliana Marie Prikler writes: > > WDYT about the following >   Applies: [patch] >   Closes: [patch] >   Resolves: [patch] >   Done: [patch] [...] > Anyway, I agree with Liliana that having more keyworks will help

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?

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: 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/releas

Re: Closing submission incomplete since years?

Hi Simon, Simon Tournier writes: > Hi Maxim, > > On Mon, 11 Sep 2023 at 13:54, Maxim Cournoyer > wrote: > >> If you want to package elasticsearch, know it's not in the Guix as we >> speak, and see it as the first item when browsing >> https://issues.guix.gnu.

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

Hi Liliana, Liliana Marie Prikler writes: > Am Montag, dem 11.09.2023 um 14:36 -0400 schrieb Maxim Cournoyer: >> Hi, >> >> Liliana Marie Prikler writes: >> >> [...] >> >> > Maybe make that bug-guix so that it matches with the mailing list >&g

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

Hi, Liliana Marie Prikler writes: [...] > Maybe make that bug-guix so that it matches with the mailing list name, > though we also need a wording for when a patch is not a bug, e.g. a > simple package upgrade. > > WDYT about the following > Applies: [patch] > Closes: [patch] >

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

Hi wolf, wolf writes: [...] >> Personally, I do not have a strong opinion about the Big Plan™. I note >> that the introduction of Git as a hard dependency is a slippery slope >> considering the current state of libgit2. Here, it starts with “git >> clone”, then “git gc” (unsupported by

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

Hi, Simon Tournier writes: > Hi, > > On Mon, 11 Sep 2023 at 16:23, Ludovic Courtès wrote: > >> Note that the patch series adds a hard dependency on Git. >> This is because the existing ‘git-fetch’ code depends on Git, >> which is itself motivated by the fact that Git supports >> shallow clones

Re: Closing submission incomplete since years?

Hi Simon, Simon Tournier writes: > Hi Maxim, > > For reference [1]. > > On Sat, 09 Sep 2023 at 18:14, Maxim Cournoyer > wrote: > >> On a related note sometimes we have WIP kind of work that stays on our >> tracker with deeper questions / problems to solv

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

Hi, Simon Tournier writes: > Hi Maxim, > > Thanks for the explanations. > > On Mon, 11 Sept 2023 at 15:47, Maxim Cournoyer > wrote: > >> > 2. How is Change-Id linked to #65280? >> >> Each patch submission ("issue") can have one or multiple c

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

Hi Giovanni, Giovanni Biscuolo writes: > Hi Maxim, > > Maxim Cournoyer writes: > > [...] > >>> c. how do we get the issue number of a patch containing "Change-Id"? [1] >> >> We'd have to search through the currently opened patches issues; I

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

Hi Giovanni, Giovanni Biscuolo writes: > Hi! > > Liliana Marie Prikler writes: > >> Am Donnerstag, dem 07.09.2023 um 09:12 -0700 schrieb Vagrant Cascadian: >>> I am much more comfortable with the "Fixes" convention of: >>> >>>   Fixes: https://issues.guix.gnu.org/NNN > > OK, I understand

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

Hi Simon, Simon Tournier writes: > Hi Maxim, > > On Sat, 09 Sep 2023 at 19:50, Maxim Cournoyer > wrote: > >>>> --8<---cut here---start->8--- >>>> random=$({ git var GIT_COMMITTER_IDENT ; echo "$refha

Re: Cross compilation status

Hi Mathieu! Mathieu Othacehe writes: > Hello, > > 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

Re: [PATCH 0/4] Add module depth information to %load-verbosely output

Hi, Maxim Cournoyer writes: > This change was made to support investigating cyclic module dependencies > that sometimes happen in GNU Guix and are difficult to > comprehend/debug. For more context, see: > <https://issues.guix.gnu.org/65716>. Oops, wrong address, sorry! I'

[PATCH 2/4] .dir-locals: Set c-basic-offset to 2 for c-mode.

* .dir-locals.el (c-mode): Set c-basic-offset to 2. --- .dir-locals.el | 1 + 1 file changed, 1 insertion(+) diff --git a/.dir-locals.el b/.dir-locals.el index 908670479..f63bdc8a3 100644 --- a/.dir-locals.el +++ b/.dir-locals.el @@ -3,6 +3,7 @@ ((nil . ((fill-column . 72)

[PATCH 4/4] load: Display modules depth in output when using %load-verbosely.

a/THANKS b/THANKS index aa4877e95..546f79b45 100644 --- a/THANKS +++ b/THANKS @@ -5,6 +5,7 @@ Contributors since the last release: Rob Browning Tristan Colgate-McFarlane Aleix Conchillo Flaqué + Maxim Cournoyer Ludovic Courtès Jason Earl

[PATCH 1/4] (ice-9 boot-9): Fix typo.

* module/ice-9/boot-9.scm (module-use-interfaces!): Fix typo in doc string. --- module/ice-9/boot-9.scm | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/module/ice-9/boot-9.scm b/module/ice-9/boot-9.scm index a5f2eea9b..897d8d01c 100644 --- a/module/ice-9/boot-9.scm +++

[PATCH 0/4] Add module depth information to %load-verbosely output

This change was made to support investigating cyclic module dependencies that sometimes happen in GNU Guix and are difficult to comprehend/debug. For more context, see: <https://issues.guix.gnu.org/65716>. Maxim Cournoyer (4): (ice-9 boot-9): Fix typo. .dir-locals: Set c-basic-offse

[PATCH 3/4] guix.scm: Update guile package native inputs.

* guix.scm (guile) [native-inputs]: Replace texlive-base with texlive-scheme-basic. Add git:send-email. --- .guix/modules/guile-package.scm | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/.guix/modules/guile-package.scm b/.guix/modules/guile-package.scm index

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

Hi Vagrant, 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

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

Hi Simon, Simon Tournier writes: > Hi, > > On Wed, 06 Sep 2023 at 22:01, Maxim Cournoyer > wrote: > >> We could use Gerrit's commit hook that adds a unique ID as a git >> trailer. Then it should become possible to > > Do we still already have Gerrit runni

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

Hi Giovanni, Giovanni Biscuolo writes: [...] >> We could use Gerrit's commit hook that adds a unique ID as a git >> trailer. > > Do you mean "commit-msg" hook as documented here: > https://gerrit-review.googlesource.com/Documentation/cmd-hook-commit-msg.html > ? > > > The Gerrit Code Review

Re: Python Team: Keeping Branch Up To Date Question

Hi jgart, "jgart" writes: > Thanks, I ended up doing what you suggested. > > Should we document this git branch policy for contributors with commit access > in the manual? > > I think we should state it explicitly so there is no confusion for new > contributors with commit access. If

Re: Python Team: Keeping Branch Up To Date Question

Hi, Lars-Dominik Braun writes: > Hi, > >> What is the git approach for keeping the Python branch up to date? 閭 >> Should I be rebasing off of master or something else? > > yeah, that’s generally what I would do before working on it. Note that > you cannot force-push into Savannah. You have to

Displaying modules load depth to hunt cycles (or just for fun)

Hi Guix! I've recently hacked a bit on Guile to try to make the output when using (set! %load-verbosely #t) in e.g. (guix config) more helpful; giving it a second dimension (the depth at which modules are loaded). It works, but the default %load-hook needs to be refined as it uses too much

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

Hi, Felix Lechner writes: > Hi Gio', > > On Thu, Sep 7, 2023 at 4:08 AM Giovanni Biscuolo wrote: >> >> close the bugs that are listed in >> the commit message > > Perhaps you'd like to see Debian's hook [1] for the Salsa web forge > (which is controversially based on Gitlab). > > The regex

Re: Process for reviewing patches as someone without commit access

Hi Simon, Chris, Simon Tournier writes: > Hi Chris, all, > > On Wed, 06 Sep 2023 at 16:55, Christopher Baines wrote: > >> Once we know what tags to use, I can have the QA frontpage do something >> similar to the "Mark as moreinfo" links, so it's easy to just click a >> button then send the

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

Hi, Simon Tournier writes: > Hi, > > On Wed, 06 Sep 2023 at 12:14, Maxim Cournoyer > wrote: > >>> Let's avoid manual gardening as much as possible! :-) >> >> I like the idea! > > I think that automatizing is not trivial. Sadly. > > There are

Re: questionable advice about Geiser load path setting

Hi, I've made the change proposed and tested; then installed as 65dcfb3f (".dir-locals: Streamline Geiser configuration."). Let me know if you encounter any problem. -- Thanks, Maxim

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

Hi Vagrant, Vagrant Cascadian writes: > On 2023-09-06, Liliana Marie Prikler wrote: >> Am Dienstag, dem 05.09.2023 um 19:41 -0400 schrieb brian >>> ‘* foo/bar.scm new-package (inputs): add input’ >>> >>> stuff. I literally can never remember this format, no matter how many >>> times I do it.

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

Hi Giovanni, Giovanni Biscuolo writes: > Hello, > > often bug reports related to patches are left open even after the > patch/patchset have been applied, the last example is a batch of Debbugs > manual gardening from Vagrant last Fri and Sat when he closed more than > 20 bugs with messages

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

Hi, Attila Lendvai writes: >> also not as obvious (you search for lines added or removed or changed, >> not easy language such as 'gnu: package-name: Add'). > > > i'm pretty sure that the source of the annoyance is not the strict > format in the summary line, but the formal details in the

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

Hi Katherine, Katherine Cox-Buday writes: > On 9/5/23 10:01 AM, Simon Tournier wrote: > >> Well, somehow, I consider the commit message format similarly as coding >> style. We can discuss which one is better than the other when at the >> end it only reflects some artificial preferences and for

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

Hi, Csepp writes: [...] >>> Regarding the GNU changelog commits, I really dislike them. They're >>> redundant busy-work as far as I'm concerned. And while I'd like to say >>> they're no longer necessary, because we have better tooling >> >> As said before, I use them all the time through >>

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

Hi, brian via "Development of GNU Guix and the GNU System distribution." writes: > pinoaffe writes: > >> Andreas Enge writes: >>> So as far as I am concerned, they are tremendously useful. Well, that may >>> be due to a lack of git knowledge, of course! But while in other projects >>> I often

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

Hi, Ricardo Wurmus writes: > "Danny Milosavljevic" writes: > >> I agree that automating the technical steps of contributing to Guix >> would be nice. > > We could provide a VM. Guix can create systems well enough to make this > feasible, I think. I'm not convinced. I typically uses VM for

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

Hi Ricardo, Ricardo Wurmus writes: > Vagrant Cascadian writes: > >> The only thing clunky about this particular aspect of the workflow >> described is the fact that the guix community (maintainers?) have >> decided on a one patch per mail policy with a cover letter, rather than >> submitting

Re: CI job for lisp-team branch

Hi Guillaume, Guillaume Le Vaillant writes: > Hi. > I created a lisp-team branch to work one some updates for clisp and > sbcl. Could someone with admin access to the CI things add a job for it? > Thanks. I've also created a TLS client certificate and emailed it to you (encrypted) so that you

Re: questionable advice about Geiser load path setting

Hello, wolf writes: [...] > Geiser seems to add the project root (I assume based on the git) into the load > path automatically. geiser-repl-current-project-function seems to be set by > default, and rest is described in the docs: (geiser)Customization and tips, > Init > files and load

Re: native-search-path and guix profile

Hi Hartmut, Hartmut Goebel writes: > Good afternoon. > > I'm curious about how exactly native-search-path work. > > I packaged vagrant, which needs to find plugins, therefore I defined a > native-search-path, see > . > > This works fine when using

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

Hi, Katherine Cox-Buday writes: [...] > Here's my understanding of the process to contribute a patch: > >   1. Check out main, and run `./bootstrap`, then `./configure > --localstatedir=/var --sysconfdir=/etc` >   2. Run `make` >   3. You need to determine whether the change can be targeted

Re: The package/inherit trap

Hi Mark, Mark H Weaver writes: [...] > I don't have time to write the doc, but I can offer a few words here. > > The fundamental question that needs to be asked, to decide whether to > write (define DERIVED-PACKAGE (package/inherit BASE OVERRIDES ...)) or > (define DERIVED-PACKAGE (package

Re: 03/08: build: Add dependency on guix script for help2man targets.

Hi Josselin, Josselin Poiret writes: > Hi Maxim, > > Maxim Cournoyer writes: > >> This changes appears to break building my tree, like this: >> >> --8<---cut here---start->8--- >> help2man: can't get `--help' info

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

Hi Csepp, Csepp writes: > Maxim Cournoyer writes: > >> Hi, >> >> Csepp writes: >> >> [...] >> >>> but as soon as something breaks, you are thrown into the deep end, >>> having to dissect logs, bisect commit ranges, learn strace, gdb

Re: 03/08: build: Add dependency on guix script for help2man targets.

Hello, guix-comm...@gnu.org writes: > jpoiret pushed a commit to branch master > in repository guix. > > commit ca8acad38264dd29a808904d3ce8e7249194d95f > Author: Josselin Poiret > AuthorDate: Fri May 12 10:00:00 2023 +0200 > > build: Add dependency on guix script for help2man targets. >

<    1   2   3   4   5   6   7   8   9   >