Re: Pinned/fixed versions should be a requirement.

Am Samstag, dem 09.09.2023 um 20:37 -0500 schrieb Distopico: > > On 2023-09-10, Liliana Marie Prikler > wrote: > > > > [bunch of stuff regarding Rust] > > > Beyond Rust, an example of a language/packages ecosystem that does > not follow semantic versioning at all is JavaScript/Npm. Most >

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: > . Oops, wrong address, sorry! I'll resend to

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

* NEWS: Update news. * THANKS: Add myself. * doc/guile-api.alist (%load-announce, %load-hook): Add DEPTH argument. * doc/ref/api-evaluation.texi (Loading): Document new DEPTH argument for the primitive-load, primitive-load-path and %load-hook procedures. Update %load-hook example. Document

[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: . Maxim Cournoyer (4): (ice-9 boot-9): Fix typo. .dir-locals: Set c-basic-offset to 2

[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: Pinned/fixed versions should be a requirement.

On 2023-09-10, Liliana Marie Prikler wrote: Hi Liliana, >> This is problematic because: >> >>     - Over time, it becomes more vulnerable to libraries/packages >>   breaking. >> >>     - It makes reproducible software more challenging, as "1.x" can >>   encompass many versions. >>

Re: Python Team: Keeping Branch Up To Date Question

So, I should add a Python teams specific section to the texinfo docs?

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

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 I like the idea, but we should also consider the bugs.gnu.org address here as well as the convention of putting it into

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 running? I was not suggesting to host

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: Pinned/fixed versions should be a requirement.

In this thread: Rust has a broken packaging model, so let's apply that. Am Montag, dem 04.09.2023 um 21:59 -0500 schrieb Distopico: > Many libraries in different languages don't follow semver, which can > lead to cases like `rust-serde-json`, which, between versions > "1.0.97" and "1.0.98,"

Re: Pinned/fixed versions should be a requirement.

> For these reasons, I believe that pinned versions should be a > requirement in libraries, always specifying the exact dependency, for > example, `rust-serde-json-1.0.98`. aiming a little higher, we could stop using module-global variables for pointing to packages (aka define-public), and with

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

Am Samstag, dem 09.09.2023 um 21:40 +0200 schrieb Ricardo Wurmus: > > Liliana Marie Prikler writes: > > > > Must we force a single workflow on everyone, even if our track > > > record in reviewing and merging doesn’t clearly show that our way > > > is superior? > > Again, define superior. > >

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: How can we decrease the cognitive overhead for contributors?

Simon Tournier writes: > On Fri, 08 Sep 2023 at 17:27, Ricardo Wurmus wrote: > >> 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

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

Liliana Marie Prikler writes: >> Must we force a single workflow on everyone, even if our track record >> in reviewing and merging doesn’t clearly show that our way is >> superior? > Again, define superior. No, I won’t. I think it’s obvious that our review process isn’t working *well*. So

Re: Python Team: Keeping Branch Up To Date Question

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. all best, jgart

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

Am Donnerstag, dem 07.09.2023 um 14:39 -0600 schrieb Katherine Cox- Buday: > > Somehow, that’s the remark by Liliana [1], > > > > Maybe it's time to take a step back and instead of asking > > “How can we decrease the cognitive overhead for > > contributors?”, we should

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

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

Hi Ricardo, all, On Fri, 08 Sep 2023 at 17:27, Ricardo Wurmus wrote: > 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

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

Hi Katherine, On Thu, 07 Sep 2023 at 14:39, Katherine Cox-Buday wrote: >> Maybe it's time to take a step back and instead of asking “How can >> we >> decrease the cognitive overhead for contributors?”, we should >> perhaps >> ask “For which contributors do we

Re: Pinned versions should be a requirement.

Hi, On Thu, 07 Sep 2023 at 10:35, Distopico wrote: > In terms of haskell I notice an incompetence of versions so even GHC are > semver the required version was other and several packages are taking > "text" internal GHC type and no the required package, you can see that > in this patch

Re: Building from git

Hi, On Thu, 07 Sep 2023 at 19:45, wolf wrote: >> The Makefile does not run ‘guix git authenticate’ using ./pre-inst-env. >> And that’s probably to ensure the source of trust. If one corrupt the >> commit that is built, then ’make authenticate’ would authenticate the >> corruption because it

Re: Process for reviewing patches as someone without commit access

Hi, There are only two hard things in Computer Science… On Thu, 07 Sep 2023 at 09:19, Vagrant Cascadian wrote: >>> Discussing about idea, would it be possible that the QA infrastructure >>> automatically send a message to Debbugs for tagging? For example, the >>> usertag ’qa-ok’ or whatever

Re: Building from git

Hi both of you (I'm replying to both at the same time), wolf writes: On 2023-09-08 11:47:56 +0200, Wojtek Kosior wrote: > Hello Josselin > > > wolf writes: > > > > > Hmm, but the recipe for the authenticate rule comes from the (possibly) > > > compromised source, no? So the attacker can

Re: Cadence For Merging python-team into master

Hi, > […] or is it just a matter of successfully building all dependents that you > are introducing against master? basically this and running the system tests. Lars

Re: Guix related things in Germany at the end of October/start of November

On Tue, 05 Sep 2023 19:28:09 +0200 Christopher Baines wrote --- > Is anyone else planning to attend these events, or otherwise interested > in meeting up in Germany around these dates? I recently moved to Hamburg. Thank you for informing the list (and particularly me) of these