Reproducible Research Hackathon: Friday, July 3rd

Hello, We are pleased to announce a Hackathon about Reproducible Science. We propose to collectively tackle some issues on *Friday, July 3rd*: - identify stumbling blocks in using Guix to write end-to-end pipelines, - document how to achieve this, - feed the Guix-Past channel by other old

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

Hi, On Tue, 29 Aug 2023 at 13:05, Giovanni Biscuolo wrote: > In other words: you can contribute to a SourceHut hosted project with > patches (or just with comments to patches) because everyone can send an > email to an email address provided by the project maintainer(s). Just to point that

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

Hi, On Mon, 28 Aug 2023 at 23:00, Maxim Cournoyer wrote: >> If someone has use cases for the ChangeLog commits, I'd like to hear >> them. Maybe there is something that can't be achieved with git history >> without ChangeLogs, but I can't think of anything. Someone mentioned >> grepping the git

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

Hi, On Mon, 04 Sep 2023 at 23:06, Arun Isaac wrote: > But, meanwhile, I wish to remind everyone that we already have a mumi > CLI client that takes away some of the pain of dealing with Debbugs. It > operates fully on the command-line and does not require Emacs at > all. This CLI client has so

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

Hi, On Tue, 29 Aug 2023 at 12:53, MSavoritias wrote: > Do you know if there are any plans to write a scheme bug/patching > system? Because looking a bit into it, it doesn't seem like its that > actively developed so maybe we would be better served by one in scheme. > Or Sourcehut of course as

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

Hi Katherine, Thank you for your extensive analysis. I concur. On Wed, 30 Aug 2023 at 10:11, Katherine Cox-Buday wrote: > 3. We should reify a way for Guix, the project, to measure, and track > progress, >    against long-term goals. Particularly when they're social and not > strictly >  

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

Hi Ricardo, all, On Sun, 03 Sep 2023 at 12:31, Ricardo Wurmus wrote: > As the original author of Mumi I want it to become obsolete as it > clearly has outlived its usefulness and better alternatives exist. The > way to get there is to add the replacement to Guix so we can host it. I am seeing

Re: Guix pull speed

without any of the dependencies and then add them in later, > similar to what is done with build-aux/build-self.scm to be able to load > (guix self) in the first place. That seems quite complex though. Thanks for looking at this. Well, as reported in [1], I am missing what is the aim of the pro

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

Hi, Thanks for these pointers. Therefore I am asking more naive questions. :-) On Tue, 5 Sept 2023 at 21:19, Csepp wrote: > There are mbox downloads on lists.sr.ht. > Random example from my browser history: > https://lists.sr.ht/~lioploum/forevercomputer If I understand correctly, this

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

Hi, On Wed, 06 Sep 2023 at 00:11, wolf wrote: > But I guess this was supposed to be taken as "run make check' and make sure > nothing new is broken". Is there a command for that? Yes taken like that. :-) And nothing I am aware. I agree that the situation with “make check” is imperfect.

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

Hi Katherine, I am fully aligned with the Survey proposal; at some past Guix Days I remember discussing a kind of survey á la Haskell or Emacs surveys. Well, such appears to me very informative to better know how to improve, from user to contributor. On Tue, 05 Sep 2023 at 12:00, Katherine

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

ng particular rules or standards – and 2. confidence – the willing to send the perfect message on the first try. And there is no tool for fixing these both issues. Example of a imperfect message: a957171bc41e98e29674f99cf3dd2940ff45a0d3. Typo! :-) --8<---cut here---s

Next action, survey?

Hi Katherine, On Tue, 05 Sep 2023 at 20:58, Katherine Cox-Buday wrote: > OK, great! What are next steps, and how can I help? Well, from my point of view, the next steps are: + Propose a survey (questions), open a new thread (or a bug report) for iterating. + Review how to distribute the

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

3b274703acaf446ec678e96c9d875c5d6b1a3e17.ca...@gmail.com https://lists.gnu.org/archive/html/guix-devel/2023-09 https://yhetil.org/guix/3b274703acaf446ec678e96c9d875c5d6b1a3e17.ca...@gmail.com 2: Re: How can we decrease the cognitive overhead for contributors? Simon Tournier Thu, 24 Aug 2023 20:53:14 +0200 id:871qfsuvad@gmail.com https://lists.gnu.org/archive/html/guix-devel/2023-08 https://yhetil.org/guix/871qfsuvad@gmail.com

Re: Process for reviewing patches as someone without commit access

Hi Felix, On Wed, 06 Sep 2023 at 12:01, Felix Lechner via "Development of GNU Guix and the GNU System distribution." wrote: > Usually, helpful reviews come from people with more experience. In > your system they come from folks with less. That seems upside down to > me. Well, I think we are

Re: Process for reviewing patches as someone without commit access

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 email to change the state of a issue. That’s cool!

Re: Guix pull speed

Hi Josselin, On Wed, 06 Sep 2023 at 11:45, Josselin Poiret wrote: >> Well, on my machine, the bigger bottleneck seems the procedure name >> ’proxy’ which copies stuff around, IIUC. See [1]. > > Proxy is on the helper script side, it's just waiting for the actual > build script to do its thing.

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

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 many corner cases: 1. series as attachement 2. not all the series is applied 3. commit message

Re: Guix pull speed

Hi Josselin, On Thu, 7 Sept 2023 at 10:37, Josselin Poiret wrote: [...] Thanks for explaining. Cheers, simon

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

xisting commits will have the > same Change-Ids (newly added commits would get their own Change-Id > trailer). I am sorry if I am slow but I do not understand. --8<---cut here---start->8--- $ git var GIT_COMMITTER_IDENT Simon Tournier

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

Hi Liliana, On Sun, 10 Sep 2023 at 00:20, Liliana Marie Prikler wrote: >> > > 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

Closing submission incomplete since years?

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 solve, and I don't think > it's fair for our reviewers to have these linger on for years on

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

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 commits. We'd > know for sure the series was merged (and thus can be closed) when the > set of

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

Re, On Mon, 11 Sep 2023 at 17:17, Simon Tournier wrote: > 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 motiva

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

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 and libgit2/Guile-Git doesn’t. Going

Re: [workflow] Triaging issues (was Automatically close bug report when a patch is committed)

LI client (was: How can we decrease the cognitive overhead for contributors?))) Simon Tournier Tue, 05 Sep 2023 10:58:50 +0200 id:86msy1uhbp@gmail.com https://yhetil.org/guix/86msy1uhbp@gmail.com https://lists.gnu.org/archive/html/guix-devel/2023-09 Cheers, simon

Re: Cross compilation status

Hi Mathieu, On Sun, 10 Sep 2023 at 11:14, Mathieu Othacehe wrote: > 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,

Re: Closing submission incomplete since years?

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.org/search?query=elasticsearch, I have some hope > that someone could find it.

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

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

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

Hi, On Mon, 11 Sep 2023 at 14:26, Maxim Cournoyer wrote: > In the grand scheme of things (pun intended), we'd like every > programming to be feasible via nice Scheme APIs, which is what Guile-Git > provides to work with git repositories. The appeal is to have a single > language to rule them

Re: to PR or not to PR, is /that/ the question?

Hi, On Thu, 14 Sept 2023 at 08:53, Giovanni Biscuolo wrote: > To remain /in topic/: I think that adopting a «web based PR model» will > definitely _not_ decrease the cognitive overhead for contributors. What could potentially decrease the cognitive overhead for contributors when using a "web

Re: Cuirass actors

Hi, It is really cool! :-) On Wed, 13 Sep 2023 at 23:08, Ludovic Courtès wrote: > - The "builder" spawns derivation builds. There are currently two > implementations: the local builder sends build requests to the local > 'guix-daemon' process, while the remote build delegates builds

Re: Implementing the guix-dameon in Guile

Hi, Really cool! Congrats Chris! :-) On Wed, 13 Sep 2023 at 13:13, Maxim Cournoyer wrote: > I had some musing about the daemon recently; I was thinking libguile > could be added to our old C++ daemon, which could then replace its > functions piece-wise with Scheme implemented ones? Maxim,

Re: The already complicated (complex?) process for contributing.

Hi Giovanni, On Fri, 15 Sep 2023 at 16:37, Giovanni Biscuolo wrote: > maybe we are drifting... again? ;-) Yes we are. :-) > Is it /complex/ or /complicated/? Change-Id is not really complex – especially if the complexity is hidden behind some pre-commit hook – and it is not complex compared

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

Hi Edouard, It is very important to speak up, although that makes me sad to read such poor feedback experience. Well, the friction is about Debbugs. Maybe I repeat myself: Debbugs is initially thought to be a bug tracker system and not a patch track system. Do not take me wrong, I am not

Re: The already complicated (complex?) process for contributing.

Hi Giovanni, On Sat, 16 Sep 2023 at 09:33, Giovanni Biscuolo wrote: > since I already replied you offline please forgive me for any > repetitions, but later I realized a better comment to your metaphore > (see below) could be useful to other people. Since your offlist comment is more or less

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

Hi Liliana, On Sun, 17 Sep 2023 at 00:19, Liliana Marie Prikler wrote: > Am Donnerstag, dem 14.09.2023 um 19:48 +0200 schrieb Simon Tournier: >> a.  … send an Email to guix-patc...@gnu.org #only once >> b.  $ git config sendemail.to 12...@debbugs.gnu.org

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

Hi, On Thu, 24 Aug 2023 at 02:18, Csepp wrote: > By the way, that's another issue. Using a TeX based document format for > the docs is, uuuh, maybe not the best idea. Info is a pretty okayish > documentation reader, but it's a relatively big barrier to entry > compared to what you need to

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

Hi Katherine, On Fri, 25 Aug 2023 at 19:02, Katherine Cox-Buday wrote: > I think there's utility in distinguishing between familiarity and > eliminating toil. I think it was incorrect of me to suggest forming > habits in my original message. I think it's better to focus on > eliminating

Re: (computed-origin-method) and (origin)'s file-name field

Hi, On Sun, 27 Aug 2023 at 20:25, Adam Faiz wrote: > Must the 'computed-origin-method' workaround be solved by adding the > renaming capability to snippets? > > Why couldn't the file-name field of the source origin be used to > rename it? > > If it's because the upstream source might be

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

Hi, On Fri, 25 Aug 2023 at 09:31, Attila Lendvai wrote: > another thing worth pointing out here is that the harder it is to test > a submitted patchset locally, the fewer non-committer reviews will > happen. First, please note that thanks to tireless Chris work about QA, testing is not hard!

Re: collection of “guix pull“ bug reports

Hi Maxim, On Sat, 26 Aug 2023 at 22:34, Maxim Cournoyer wrote: >> https://issues.guix.gnu.org/issue/62830 >> https://issues.guix.gnu.org/issue/63451 >> https://issues.guix.gnu.org/issue/63830 >> https://issues.guix.gnu.org/issue/64489 >> https://issues.guix.gnu.org/issue/64659 >>

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

Hi, On Sat, 26 Aug 2023 at 19:42, kias...@disroot.org wrote: > I would like to hear from committers if non-committer reviews are > helpful, because I don't really know how or what I can comment on for > incoming patches on packages I'm not really familiar with. Well, I do not have enough

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

Hi, On Fri, 25 Aug 2023 at 18:39, Katherine Cox-Buday wrote: > 2. Remember the email address (it might seem silly unless you have forms > of dyslexia. is it guix-patches? or patches-guix? Wait, what was I doing?) > 3. And then the whole deal with what to do with follow ups. For what it is

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

Hi Katherine, On Tue, 12 Sep 2023 at 10:05, Katherine Cox-Buday wrote: > 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 >

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

Re, On Wed, 13 Sep 2023 at 09:57, Simon Tournier wrote: > Somehow, the line is drawn using a two-axis plot of “easy vs boring” > when instead we should draw a two-axis plot of “complexity vs capture > the values”. I meant, the thread is considering a one-axis plot using a subjective

Re: Swineherd: Guix System container manager

Hi Ricardo, On Wed, 13 Sep 2023 at 11:06, Ricardo Wurmus wrote: [...] > > The Swineherd was designed to be used with Shepherd on foreign distros, > so it does not assume to be running on top of Guix System (for better or > worse). Oh! It is very promising. Really cool! > Of course the

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

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, which could result in all > kinds of nasty

Re: to PR or not to PR, is /that/ the question?

Hi Giovanni, Thank you for your detailed message. Sorry, I have not read all the details because I have been lost. What do you want to explain? Well, let me explain my understanding using my own words. :-) When one reduces to the core of the workflows, the main difference between “email

Re: Process for reviewing patches as someone without commit access

Hi, On Wed, 06 Sep 2023 at 22:47, Maxim Cournoyer wrote: >> Well, using emacs-debbugs and then >> >> C-u M-x debbugs-gnu-usertags guix-patches RET >> >> the list of usertags is: >> >> guix-patches for-core-updates >> guix-patches reviewed-looks-good >> >> And if instead of

Re: Pinned versions should be a requirement.

-f2) … build all packages impacted by a change in the package gmsh … --8<---cut here---end--->8--- Cheers, simon 1: [bug#61078] [PATCH 0/4] Rename '/fixed' by '/pinned' Simon Tournier Thu, 26 Jan 2023 17:42:38 +0100 id:20230126164238.2462377

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

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? Cheers, simon

Re: Building from git

Hi, On Sat, 02 Sep 2023 at 11:03, Nicolas Débonnaire wrote: > guix shell -D guix --pure > ./bootstrap > ./configure --localstatedir=/var --syscondir=/etc > make [...] > Error: fontconfig:Didn't find expected font family. Perhaps URW Type 1 > fonts need installing? Hum, weird. That’s because

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: 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: 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: hard dependency on Git? (was bug#65866: [PATCH 0/8] Add built-in builder for Git checkouts)

Hi, On Thu, 14 Sept 2023 at 18:51, Ludovic Courtès wrote: > For the record, that’s a 6% increase: > > --8<---cut here---start->8--- > $ guix size guix | tail -1 > total: 633.0 MiB > $ guix size guix git-minimal | tail -1 > total: 675.7 MiB >

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

Hi Ludo, On Thu, 14 Sep 2023 at 12:30, Ludovic Courtès wrote: >but I don’t think > we can get a decent throughput if we shell out for all these things > (assuming ‘git’ can even give us raw data). Do you consider that Magit does not have

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

Hi, On Thu, 14 Sep 2023 at 12:27, Giovanni Biscuolo wrote: > Please can you expand what troubles do you see in automatically adding > 'Change-Id:' using a hook-commit-msg like > https://gerrit-review.googlesource.com/Documentation/cmd-hook-commit-msg.html > ? 1. The hook must be installed. 2.

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

Hi Giovanni, Before commenting, let me repeat. ;-) That’s said, I am not against the proposal. I just have mixed feelings and before deploying I strongly suggest to review if the proposal covers the intent. On Fri, 15 Sep 2023 at 09:16, Giovanni Biscuolo wrote: >

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

Hi, On Thu, 14 Sep 2023 at 23:19, Sarthak Shah wrote: > I believe that it should not be very hard to create a user interface (web, > ncurses or GUI) that searches for a package's location (the package record > has a field that accommodates this) and then displays it, which the user > can then

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

Hi Edouard, On Thu, 14 Sep 2023 at 20:57, Edouard Klein wrote: > Second, I don't know what the general feeling is here towards debbugs, but > if moving away from it is something that may happen, my suggestion is not > to use anything with Pull Requests, as Simon you seem to have > understood.

Re: Moment de convivialité Guix@Paris en octobre

salut Tanguy, On Fri, 27 Oct 2023 at 09:04, Tanguy LE CARROUR wrote: > Merci à ceux qui ont bravé la pluie pour venir hier soir ! > Et merci à ceux qui ont supporté de nous voir manger et boire *via* > la vidéo-conférence.  Chouette soirée ! Merci Tanguy pour la logistique. > Vu que l'on

$EDITOR and “guix edit”

Hi, The command “guix edit” returns “+N path/to/file” that is then passed to $EDITOR. Therefore $EDITOR needs the command line: $ $EDITOR +N /path/to/file Well, that is accepted by many $EDITOR, to my knowledge. At least, Emacs, Vi or less are fine with it. However, some other $EDITOR

G-expressions and chroot environment? (was Re: branch master updated: gnu: Add passff.)

Hi, On Sat, 28 Oct 2023 at 17:05, Clément Lassieur wrote: >> ./pre-inst-env guix show passff-host >> name: passff-host >> version: 1.2.3 >> outputs: >> + out: everything >> systems: x86_64-linux mips64el-linux aarch64-linux powerpc64le-linux >> riscv64-linux >> + i686-linux

Re: doc: Mention the responsibilities that blocking comes with.

Hi, On sam., 14 oct. 2023 at 11:44, Maxim Cournoyer wrote: > 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. Here is the change: --8<---cut

Request-For-Comment process: concrete implementation

-For-Comment process #+DATE: 2023-10-31 + Issue: 66844 + Status: pending + Supporter: Simon Tournier + Co-supporters: * Summary The "RFC" (request for comments) process is intended to provide a consistent and controlled path for new features to enter the Guix project, so that all stakeh

Re: Order of manifest and overlapping binaries

Hi, On Tue, 16 May 2023 at 16:41, Greg Hogan wrote: > I could not find documentation on this circumstance or how to resolve. > Both 'parallel' and 'moreutils' produce a 'bin/parallel' and only one > can go in the $GUIX_PROFILE. > > Creating a container, the latter package overshadows the former

Meet Guix at Capitole du Libre in Toulouse, nov. 18-19

Hi, Some of us will be in Toulouse, INP-N7, 26 rue Riquet on 18 & 19 november for Capitole du Libre: https://capitoledulibre.org/ We will stand in Village Associatif. Let us know if you can help us at the event. Well, I do not know exactly what means "a stand" since it will be the first

Re: G-expressions and chroot environment? (was Re: branch master updated: gnu: Add passff.)

Hi, On Fri, 03 Nov 2023 at 19:46, Simon Tournier wrote: > However, there is still something that I am missing. The derivations > tracks all and that’s expected; thanks G-expression machinery. :-) > However, I miss how the builder works with the chrooted environment if > nothi

Re: guix shell init

Hi, On Wed, 25 Oct 2023 at 04:29, "jgart" wrote: > nix flakes also allows you to create your own custom template for use with > `nix flakes init`: > > https://nixos.org/manual/nix/stable/command-ref/new-cli/nix3-flake-init#template-definitions > > We could do the same with `guix shell init`

Re: guix shell init

Hi, On Wed, 25 Oct 2023 at 04:24, "jgart" wrote: > It would generate this boilerplate somehow: > > https://guix.gnu.org/en/blog/tags/cookbook/sk/html_node/Getting-Started.html Could you be precise about the boilerplate? You would like that “guix shell --init” would generate a template for

Re: guix shell init

Hi, On Wed, 25 Oct 2023 at 02:24, "jgart" wrote: > What if we had a command like `guix shell init`. > > It would create a basic manifest.scm or guix.scm file for the user. Is guix shell --export-manifest not already doing that? And “guix package --export-channels” is similar for the

Helpers? (was Re: New section to easily reference Debbugs URLs within Emacs Debbugs)

Hi Maxim, On Wed, 20 Sep 2023 at 14:13, Maxim Cournoyer wrote: >> (define-key gnus-article-mode-map "R" >> #'(lambda () >> "Start composing a reply mail to the current message. >> The original article will be yanked, see >> `gnus-summary-wide-reply-with-original'." > > This comes

Re: July update on qa.guix.gnu.org

Hi Chris, Thanks for the update, always nice! On Wed, 26 Jul 2023 at 09:44, Christopher Baines wrote: > The queue is very large at [3]. Some patches trigger a lot of rebuilds. And the threshold is about 300 or something, I guess. Would it be possible to mark these items? For instance,

Re: The elephant in the room and the Guix Bang.

we decrease the cognitive overhead for contributors? Simon Tournier Mon, 18 Sep 2023 12:09:45 +0200 id:87bkdzssgm@gmail.com https://lists.gnu.org/archive/html/guix-devel/2023-09 https://yhetil.org/guix/87bkdzssgm@gmail.com

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

Hi Ludo, On Mon, 18 Sept 2023 at 15:56, Ludovic Courtès wrote: > Anyhow, how about this plan: > > 1. Merge with the hard Git > dependency. Is #65866 fixing bug#63331 (Guile-GnuTLS/Git circular dependency) [1]? Does the merge of #65866 lead to close

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

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 the manual; see it at the bottom of info "(guix) The Perfect Setup"). Oh, cool! On

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

4]. In summary, “email vs. web-forge” is a fake-problem, IMHO. Last, the talk [5] by Enrico Zini appears to me much more fruitful. The question is about sustain the community. And this sustainability does not clearly depend on any tool. Cheers, simon 1: Re: How can we decrease the cogni

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

Hi, On Sun, 17 Sep 2023 at 14:29, MSavoritias wrote: > The reason I have come to guix is because it strives to actually make it > easier for people to change things. with guix shell and such. So making > it easier for people to contribute is absolutely a part of it. Im not > saying we should

Re: Guix Days and Fosdem 2024

Hi Manolis, On Sun, 17 Sep 2023 at 17:42, Manolis Ragkousis wrote: > It's that time of the year again. We should start preparing for the Guix > Days 2024 and a Declarative and Minimalistic Computing devroom proposal. Cool! > I have created the pages at [1] devroom proposal and [2] Guix days.

Re: [fr] Moment de convivialité Guix@Paris en septembre

salut Tanguy, On Thu, 14 Sep 2023 at 18:06, Tanguy LE CARROUR wrote: > Ce jeudi 28 septembre à 19h, se tiendra la première édition de Guix@Paris > ouverte au public. Chouette ! Je serai là. à tantôt, simon

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

On Mon, 18 Sept 2023 at 18:35, MSavoritias wrote: > I was talking from my experience. If you don't share it that is fine. Share what? Your experience? How can I? Instead, I share facts backed by numbers. It is fine to share how you perceive, encouraged even! It is not fine to make bold

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

Hi, On Mon, 18 Sept 2023 at 19:40, MSavoritias wrote: > As i said its okay if you don't understand it, or share it. What you can > not do is dismiss my experience. I do not dismiss your experience. To the contrary. It is because I do not share other experiences that I am interested by

Re: Guix Survey (follow up on "How can we decrease the cognitive overhead for contributors?")

Hi, Really cool! Thank you. On Sat, 16 Sep 2023 at 14:59, Wilko Meyer wrote: > I identified a few key themes that could be useful for a guix user > survey as well. I plan on doing a more extensive summary on this later > this weekend if my time allows it, for now a loose collection of >

Re: RFC: add more setups to Guix docs (was: The e(macs)lephant in the room and the Guix Bang)

Hi Ekaitz, On Mon, 25 Sep 2023 at 14:25, Ekaitz Zarraga wrote: > I decided to go for the action instead of discussion. Nice initiative! > Are maintainers open to add some section like this to the manual? I am not maintainer and I have nothing against. :-) Well, I do not know if you plan to

Re: The e(macs)lephant in the room and the Guix Bang

Hi, On Mon, 25 Sep 2023 at 20:54, Liliana Marie Prikler wrote: >> The default of Emacs absolutely do matter. [...] > I share neither the experience nor the argument. [...] Please, we are not on the emacs-devel mailing list. :-) Or maybe, we need to create some guix-tagents mailing list.

Emacs and Guix (was Re: The e(macs)lephant in the room and the Guix Bang)

Hi, On Mon, 25 Sep 2023 at 14:09, MSavoritias wrote: > when its the same people that push Emacs as the "blessed" way to > contribute (as in the guix manual) Just to point 1. Guix is part of GNU – for the good, the bad and the ugly – so 2. editors developed under the GNU umbrella are

Re: The Giraffe; the Pelican et al (was Re: The e(macs)lephant in the room and the Guix Bang)

Hi, On Mon, 25 Sep 2023 at 14:13, MSavoritias wrote: > So saying that the people who don't know guile or guix need to first > contribute docs is pretty ridiculous. Why? Could you explain more why it appears to you “ridiculous”? Cheers, simon

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

Hi Ricardo, On Thu, 28 Sep 2023 at 08:35, Ricardo Wurmus wrote: > Across the wider GNU system the command for accessing manuals is “info” > followed by the name of the manual, e.g. “info guix” or “info > guix-cookbook”. Yeah but for instance I barely use Info because I never remember how to

Re: is core-updates still a thing?

Hi, On Tue, 26 Sep 2023 at 12:28, Maxim Cournoyer wrote: >> My understanding is that feature-branches are now the canonical way to >> work on things, and core-updates has become just another kind of >> feature-branch for landing groups of large changes that don't really >> fit anywhere; the

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

Hi, On Tue, 26 Sep 2023 at 03:18, "jgart" wrote: > https://guix.gnu.org/manual/en/html_node/Submitting-Patches.html > 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: more than 1,800 dependent packages: website out of date

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 manual, not the > > latest one. This v1.4.0

Re: guix refresh -u weird behaviour

Hi jgart, On Wed, 04 Oct 2023 at 10:10, Ricardo Wurmus wrote: > Because Faker doesn’t list them in a way that the importer can add them. > The quality of the importer determines the quality of the updater. The > updater only does what the importer tells it to do. …and the Guix importer tells

content-address hint? (was Re: intrinsic vs extrinsic identifier: toward more robustness?)

ease note Guix is already storing multiple hashes for some origins. It is the case for ’git-fetch’ methods, for example. All these packages using a plain Git commit hash are somehow storing two content-addressed hashes (Git and Nar). If one needs examples about how upstream can manage the ugly way the

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

Hi, On Wed, 04 Oct 2023 at 17:33, Ludovic Courtès wrote: >> Yeah but for instance I barely use Info because I never remember how to >> navigate and often I have an approximate idea about what I am looking >> for and in this case, I am faster with the HTML documentation. > > That’s fine, we all

  1   2   3   4   5   >