Re: bug#78332: [PATCH 1/1] 005-regular-releases: Initial draft of GCD005 'Regular and efficient releases'.

Hi Olivier, On Wed, Jun 18, 2025 at 04:52:42AM +, Olivier Rojon wrote: > Hi Steve, hi everyone, > > first things first, thank you so much for your efforts for the Guix project. > Your awesome > newbie-friendly blog posts, the Guix User and Contributor Survey, this GCD - > thanks! (...) Yo

Re: bug#78332: [PATCH 1/1] 005-regular-releases: Initial draft of GCD005 'Regular and efficient releases'.

eprecation of packages that don't build on the primary architecture" and "risk of removal" clearer. @text: Toolchain and transition freeze == Maybe a criterion such as with package updates could be used here, like "if a change in package X

Re: [PATCH] Add bolt

Hi, On Tue, 06 May 2025 at 18:01, Sergio Pastor Pérez wrote: > It's been two years since this patch series was updated. Is there any > reason why it didn't get merged? [...] > How can we help to push this patch series through the finish line? Maybe close this ticket and r

Re: [PATCH] build-system: Adding conan-build-system.

em.scm | 232 ++ > 3 files changed, 362 insertions(+) Could you resend this patch to the guix-patch tracker or maybe open a PR. :-) Cheers, simon

Re: [PATCH] import: Add conan import.

+++ > guix/scripts/import.scm | 1 + > guix/scripts/import/conan.scm | 112 > 4 files changed, 301 insertions(+) > create mode 100644 guix/import/conan.scm > create mode 100644 guix/scripts/import/conan.scm Well, maybe this could be tracked by a issue numb

Re: bug#76296: [PATCH maintenance] hydra: bayfront: Set up ‘git.guix.gnu.org’ as a redirect to Savannah.

Hello, Ludovic Courtès writes: > If we choose to install this patch, we should IMO do it as before > guix.git is migrated to Codeberg (presumably on May 25th). That way, we > can use git.guix.gnu.org in (guix channels) instead of > codeberg.org/guix/guix.git. We had a bunch of i

Re: [bug#76296] [PATCH maintenance] hydra: bayfront: Set up ‘git.guix.gnu.org’ as a redirect to Savannah.

Hello, On 5/18/25 22:55, Ludovic Courtès wrote: Hello, Ahmad Draidi writes: I did some testing on a test domain. I configured both DNS redirect (git-dns.guix.redscript.org) and HTTP 302 redirect (git.guix.redscript.org) to codeberg.org. As Ludo mentioned before, DNS redirect doesn't work. H

Re: [bug#76296] [PATCH maintenance] hydra: bayfront: Set up ‘git.guix.gnu.org’ as a redirect to Savannah.

I wanted to deploy this patch now so we can start testing it and since the goal was to migrate guix.git next Sunday (May 25th). Unfortunately, we seem to be unable to connect to the machine hosting our DNS service (bayfront) so I’m not sure when we’ll be able to deploy it. Bad timing. :-/ Ludo’.

Re: [bug#76296] [PATCH maintenance] hydra: bayfront: Set up ‘git.guix.gnu.org’ as a redirect to Savannah.

Hello, Ahmad Draidi writes: > I guess this would make switching, in case of disasters, seamless for > the user, which is probably something we want. The URL doesn't > change. On Guix project's side, it's a relatively quick change. The > extra load is probably negligible also. No need to proxy th

Re: [bug#76296] [PATCH maintenance] hydra: bayfront: Set up ‘git.guix.gnu.org’ as a redirect to Savannah.

Greetings, On 5/14/25 13:52, Ludovic Courtès wrote: Hi, Ricardo Wurmus writes: Noé Lopez writes: I guess its for style points, which I’m all for. I do think it would be better to set the URL to git.guix.gnu.org/guix/guix.git and just a DNS redirect to codeberg to avoid the extra connecti

FIXED Re: error: eudev-removable-devices-polling.patch: patch not found

FYI, fixed https://codeberg.org/guix/guix-mirror/commit/05a004fbfe1d8096f6b707d4c9d2a7bca3f2a689

error: eudev-removable-devices-polling.patch: patch not found

Current HEAD (f882e365e1b2e9383ee03c81b4ab87951ad3b7f7) is missing a file. $ guix shell -m manifest.scm hint: Consider passing the `--check' option once to make sure your shell does not clobber environment variables. guix shell: error: eudev-removable-devices-polling.patch: patc

[bug#78419] [PATCH] daemon: Add const qualifier to comparison call operator.

Hello Dariqq You encounteren the same problem with me when I tried to build guix-daemon with -std=c++11 [1]. With your patch guix-daemon can be built with -std=c++17 successflly, but with a warning. nix/libutil/util.cc: In function 'void nix::writeToStderr(const string&)': nix/l

Re: bug#76296: [PATCH maintenance] hydra: bayfront: Set up ‘git.guix.gnu.org’ as a redirect to Savannah.

Ludovic Courtès writes: Ricardo Wurmus writes: Noé Lopez writes: I guess its for style points, which I’m all for. I do think it would be better to set the URL to git.guix.gnu.org/guix/guix.git and just a DNS redirect to codeberg to avoid the extra connection. I second this. I think

Re: bug#76296: [PATCH maintenance] hydra: bayfront: Set up ‘git.guix.gnu.org’ as a redirect to Savannah.

Hi, Ricardo Wurmus writes: > Noé Lopez writes: > >> I guess its for style points, which I’m all for. I do think it would >> be >> better to set the URL to git.guix.gnu.org/guix/guix.git and just a >> DNS >> redirect to codeberg to avoid the extra connection. > > I second this. > > I think a DNS

Re: bug#76296: [PATCH maintenance] hydra: bayfront: Set up ‘git.guix.gnu.org’ as a redirect to Savannah.

Noé Lopez writes: I guess its for style points, which I’m all for. I do think it would be better to set the URL to git.guix.gnu.org/guix/guix.git and just a DNS redirect to codeberg to avoid the extra connection. I second this. I think a DNS level redirect would be sufficient. I'd prefer

Re: [PATCH 00/48] Extend bag-build to gexps.

Hello Nicolas, Nicolas Graves writes: > The first/independent part of 68315 has already been merged, now it's > time for discussion on how/when/with which process to get that one > merged. > > I've pinged the other issue this morning, hopefully we can get a > discussion going there! That's great

Re: [PATCH 00/48] Extend bag-build to gexps.

Sorry Sergio I read you late! Nice, indeed debugging symbols would be great in this context. The first/independent part of 68315 has already been merged, now it's time for discussion on how/when/with which process to get that one merged. I've pinged the other issue this morning, hopefully we c

Re: bug#76296: [PATCH maintenance] hydra: bayfront: Set up ‘git.guix.gnu.org’ as a redirect to Savannah.

Hi Noé, Noé Lopez writes: > As you said, this adds an extra point of failure. It seems that there is > no real issue with changing URL right now as shown by GCD 002. So what > is the benefit of this patch? This was originally proposed as a way to facilitate Git migration—should we de

Re: bug#76296: [PATCH maintenance] hydra: bayfront: Set up ‘git.guix.gnu.org’ as a redirect to Savannah.

Ludovic Courtès writes: > Hello, > > Now that GCD 002 has been accepted, I’d like to restart discussions > around this patch, which adds the git.guix.gnu.org DNS entry and HTTP(S) > redirects to codeberg.org/guix: > > https://issues.guix.gnu.org/76296 > >&

Re: bug#76296: [PATCH maintenance] hydra: bayfront: Set up ‘git.guix.gnu.org’ as a redirect to Savannah.

Ludovic Courtès writes: > Christopher Baines writes: > >> I wonder how this compares to storing and serving a mirror of the Git >> repository. Maybe that's a bit more complicated in terms of the setup, >> but it may perform better than a redirect and actually provide >> redundancy? > > Good poin

Re: bug#76296: [PATCH maintenance] hydra: bayfront: Set up ‘git.guix.gnu.org’ as a redirect to Savannah.

Hi, Christopher Baines writes: > I wonder how this compares to storing and serving a mirror of the Git > repository. Maybe that's a bit more complicated in terms of the setup, > but it may perform better than a redirect and actually provide > redundancy? Good point. I think mirroring would be

Re: bug#76296: [PATCH maintenance] hydra: bayfront: Set up ‘git.guix.gnu.org’ as a redirect to Savannah.

Ludovic Courtès writes: > Now that GCD 002 has been accepted, I’d like to restart discussions > around this patch, which adds the git.guix.gnu.org DNS entry and HTTP(S) > redirects to codeberg.org/guix: > > https://issues.guix.gnu.org/76296 > >> This patch implements t

Re: bug#76296: [PATCH maintenance] hydra: bayfront: Set up ‘git.guix.gnu.org’ as a redirect to Savannah.

Hi, Ludovic Courtès writes: > Hello, > > Now that GCD 002 has been accepted, I’d like to restart discussions > around this patch, which adds the git.guix.gnu.org DNS entry and HTTP(S) > redirects to codeberg.org/guix: > > https://issues.guix.gnu.org/76296 > >&

Re: bug#76296: [PATCH maintenance] hydra: bayfront: Set up ‘git.guix.gnu.org’ as a redirect to Savannah.

Hello, Now that GCD 002 has been accepted, I’d like to restart discussions around this patch, which adds the git.guix.gnu.org DNS entry and HTTP(S) redirects to codeberg.org/guix: https://issues.guix.gnu.org/76296 > This patch implements that; technically we have to have an HTTP redir

Re: [PATCH] Add bolt

Hello! It's been two years since this patch series was updated. Is there any reason why it didn't get merged? > Hi Ludo’, > > > removed the deprecated contruct make-forkexec-constructor/container and > changed bolt into boltd. > > Also added plasma-thunderbol

Re: [bug#78052] [PATCH] gnu: ungoogled-chromium: Fix WebRTC.

Hi Andreas, Andreas Enge writes: > Hello, > > Am Tue, Apr 29, 2025 at 10:45:44AM +0200 schrieb Noé Lopez: >> IMO its important that we have one of webkit, chromium and gecko in our >> repos for when those pesky websites refuse to work with X browser. > > I concur. In particular, many ecommerce w

Re: [bug#78052] [PATCH] gnu: ungoogled-chromium: Fix WebRTC.

existing users would probably not see it for example. I think going through the deprecation route would be a more visible option. Our (info "(guix) Deprecation Policy") suggests a one month period after the removal PATCH is submitted, plus a news to etc/news.scm broadcasting the removal

Re: [bug#78052] [PATCH] gnu: ungoogled-chromium: Fix WebRTC.

Andreas Enge writes: > Hello, > > Am Tue, Apr 29, 2025 at 10:45:44AM +0200 schrieb Noé Lopez: >> IMO its important that we have one of webkit, chromium and gecko in our >> repos for when those pesky websites refuse to work with X browser. > > I concur. In particular, many ecommerce websites do no

Re: [bug#78052] [PATCH] gnu: ungoogled-chromium: Fix WebRTC.

Hello, Am Tue, Apr 29, 2025 at 10:45:44AM +0200 schrieb Noé Lopez: > IMO its important that we have one of webkit, chromium and gecko in our > repos for when those pesky websites refuse to work with X browser. I concur. In particular, many ecommerce websites do not work with icecat, even after di

Re: [bug#78052] [PATCH] gnu: ungoogled-chromium: Fix WebRTC.

Maxim Cournoyer writes: > Nicolas Goaziou writes: > > I agree that it has value; wouldn't it only be for testing website > problems (it's still a thing in 2025 to find a website feature that only > works with Chromium, in a nudge to the good old Internet Explorer > days). My hypothetical use-ca

Re: [bug#78052] [PATCH] gnu: ungoogled-chromium: Fix WebRTC.

Maxim Cournoyer writes: > Hello, > > Danny Milosavljevic writes: > >> * gnu/packages/patches/ungoogled-chromium-fcntl-fix.patch: New file. >> * gnu/packages/chromium.scm (%guix-patches): Add reference to it. >> * gnu/local.mk (dist_patch_DATA): Add reference to it. > > Ouch, the last time ungoog

Re: [bug#78052] [PATCH] gnu: ungoogled-chromium: Fix WebRTC.

Hi Nicolas, Nicolas Goaziou writes: > Hello, > > Maxim Cournoyer writes: > >> Danny Milosavljevic writes: >> >>> * gnu/packages/patches/ungoogled-chromium-fcntl-fix.patch: New file. >>> * gnu/packages/chromium.scm (%guix-patches): Add reference to it. >>> * gnu/local.mk (dist_patch_DATA): Add

Re: [bug#78052] [PATCH] gnu: ungoogled-chromium: Fix WebRTC.

Hello, Maxim Cournoyer writes: > Danny Milosavljevic writes: > >> * gnu/packages/patches/ungoogled-chromium-fcntl-fix.patch: New file. >> * gnu/packages/chromium.scm (%guix-patches): Add reference to it. >> * gnu/local.mk (dist_patch_DATA): Add reference to it. > > Ouch, the last time ungoogled

Re: [bug#78052] [PATCH] gnu: ungoogled-chromium: Fix WebRTC.

Hello, Danny Milosavljevic writes: > * gnu/packages/patches/ungoogled-chromium-fcntl-fix.patch: New file. > * gnu/packages/chromium.scm (%guix-patches): Add reference to it. > * gnu/local.mk (dist_patch_DATA): Add reference to it. Ouch, the last time ungoogled-chromium was updated was in 2023.

Re: [PATCH 00/48] Extend bag-build to gexps.

Nicolas Graves writes: > Made some progress and I'll rework on the patches tonight. I'm looking forward to it! > Current workflow is the following : > > In a guix with v2 patches and current guix-local: > cd /tmp > mkdir -p hello > cd hello > guix local instantiate hello --> downloads and unpack

Re: [PATCH 00/48] Extend bag-build to gexps.

allow partial builds. >> >> Today I've decided to try it out. I got some issues when running the >> 'guix.scm' example you provided with your patch series applied over >> `412f411d4f8780e6b60b448caae17f01c09be0eb`. >> --8<---cut here

[PATCH] import: Add conan import.

Here's also my conan import implementation, if you want to take a look. Nicolas --- Makefile.am | 2 + guix/import/conan.scm | 186 ++ guix/scripts/import.scm | 1 + guix/scripts/import/conan.scm | 112 4 fil

Hacking and patch review session (Tuesday 22nd)

Hi all, After a few different talks at Guix Social, our next one is going to be a hacking and patch review session. This will next week - Tuesday 22nd - details of times on the Wiki: https://libreplanet.org/wiki/Group:Guix/GuixSocial For experienced developers/reviewers there will be a

[PATCH] build-system: Adding conan-build-system.

self.cpp_info.bindirs = ['bin'] if os.path.exists(os.path.join(self.package_folder, 'bin')) else [] +self.cpp_info.includedirs = ['include'] if os.path.exists(os.path.join(self.package_folder, 'include')) else [] +self.cpp_info.libdirs =

Re: [bug#76428] [GCD PATCH] 003-set-search-paths-without-program-wrappers: Submit.

. Also it allow user to customize > them as usually, or 'guix home' or 'guix system' to custom them at > profile level. I understand this, but I’m not sure how it releases to GUIX_-prefixing more variables. > In the specified search-paths.d implementation, for simplif

Re: bug#68453: closed (Re: bug#68453: [PATCH] doc: Improve VNC Services section.)

it is easier to understand where/what is "local" and where/what is "remote" The patch is attached. Cheers, Bost From 9bf0d51aa1351d12bf5115b7adc3aee8ec7fde75 Mon Sep 17 00:00:00 2001 Message-ID: <9bf0d51aa1351d12bf5115b7adc3aee8ec7fde75.1744212208.git.rostislav.svob...@g

Re: [PATCH 00/48] Extend bag-build to gexps.

On 2025-03-21 11:20, Sergio Pastor Pérez wrote: > > The version 2 has less patches. Do I need to apply only v2? Yes, I merged some patches because my mail are capped to 200/hour and I reached that in v1. -- Best regards, Nicolas Graves

Re: bug#76428: [GCD PATCH] 003-set-search-paths-without-program-wrappers: Submit.

onment variable. > > For example, the XDG_ variables are honored by a lot of software, not > just GLib- or Qt-based software, and it’s unrealistic to patch them all. > It’s also undesirable: generally speaking, we want to stay as close to > upstream as possible so that documentatio

Re: bug#76428: [GCD PATCH] 003-set-search-paths-without-program-wrappers: Submit.

e’s a precedent, ‘GUIX_PYTHONPATH’, but I think it does not follow that this can be generalized to every search path environment variable. For example, the XDG_ variables are honored by a lot of software, not just GLib- or Qt-based software, and it’s unrealistic to patch them all. It’s also undesir

Re: [PATCH 0/2] ffmpeg-7: Update to 7.1.1.

Hi Guix, So around 3 weeks ago, I sent a patch to bump ffmpeg-7 to the latest version, 7.1.1 [1]: 45mg <45mg.wri...@gmail.com> writes: > ffmpeg-7 is currently FFmpeg 7.0.2, which was released on 2024-08-03 - > 7 months ago. It's probably time for an update. > > Version 7.

Re: [PATCH 00/48] Extend bag-build to gexps.

Hello Nicolas! I've been looking forward to this early 2024 effort to allow partial builds. Today I've decided to try it out. I got some issues when running the 'guix.scm' example you provided with your patch series applied over `412f411d4f8780e6b60b448caae17f01c09be0eb`. --

Re: [PATCH 00/48] Extend bag-build to gexps.

e that there is 2 revisions of a similar patch series: - https://lists.sr.ht/~ngraves/devel/%3c20250319125056.27116-1-ngra...@ngraves.fr%3E - https://lists.sr.ht/~ngraves/devel/%3c20250319173238.7969-1-ngra...@ngraves.fr%3E The version 2 has less patches. Do I need to apply only v2?

Re: [PATCH 00/48] Extend bag-build to gexps.

been looking forward to this early 2024 effort to > allow partial builds. > > Today I've decided to try it out. I got some issues when running the > 'guix.scm' example you provided with your patch series applied over > `412f411d4f8780e6b60b448caae17f01c09be0

[PATCH v1] channels: add transformer field

Hey everyone, I've recently tried to declaratively apply my own patches to the upstream guix channel or channels in general but I found it very hard (aka impossible) to do that cleanly so I made this simple patch. This patch adds a new "transformer" field to the chann

Patch application workflows

Hi folks, I’ve had issues getting a reliable patch review/push workflow going, and would like to hear what others are doing for this. Specific issues I’d like to solve: * `mumi am' sometimes claims not to find patches. This just happened to me: guix!env!ieure:~/projects/guix/st

Re: [PATCH] gnu: qemu-7.2.4: Unregister patch.

Hi Nicolas, Nicolas Graves writes: > * gnu/packages/patches/qemu-7.2.4-build-info-manual.patch: Remove > patch. > * gnu/local.mk: Unregister patch. Applied, thanks. I'm not sure if I had already closed the guix-patches issue, I oddly can't find it anywhere. -- Thanks, Maxim

[PATCH] Blind update of Hanwen's go-fuse broke Gocryptfs

Hi, It's might be me for few months (14+) updating the Golang stack in Guix to some workable fresh state to bring new projects in. Few steps are taken in place: - make sure ALL tests are enabled by providing ./... to "go test" - make sure as much tests passed as possible - make sure the final ex

Re: bug#65974: [PATCH 00/33] thirty something go packages

Hi Sharlatan, JSYK, you're sending encrypted messages to lists. See . I think this is the second one I've seen, so something's misconfigured on your end. Kind regards, T G-R Sent on the go. Excuse or enjoy my brevity.

Re: bug#55231: [PATCH v6] initrd: Allow extra search paths with ‘initrd-extra-module-paths’

Hi Maxim, Your help is much appreciated! The changes all look good, but there is one thing which is alarming me somewhat. Perhaps I am misunderstanding how the `substitutable-derivation?` function actually operates, but if I apply these patches and then run, say: ``` (use-modules (guix) (gnu)

Re: bug#55231: [PATCH v6] initrd: Allow extra search paths with ‘initrd-extra-module-paths’

Hi Morgan, I needed to do some changes and adjust one test, but in v6 the derivations tests now pass, and the regular operation of Guix appears otherwise unaffected, which is good (I don't need to rebuild say, Libreoffice). Could you test? -- Thanks, Maxim

Re: bug#55231: [PATCH v1] initrd: Allow extra search paths with ‘initrd-extra-module-paths’

ng to apply `derivation-input-derivation`. I'll send over the patch in a moment. Best, Morgan

Re: bug#55231: [PATCH v1] initrd: Allow extra search paths with ‘initrd-extra-module-paths’

but didn't bother submitting an updated patch set because even with that typo fixed, the change still didn't seem to work. You may have noticed and fixed this yourself. I had trouble running the test suite while working on the changes, as I was away from home and my laptop seemed to be

Re: bug#55231: [PATCH v1] initrd: Allow extra search paths with ‘initrd-extra-module-paths’

Hi Morgan, Morgan Arnold writes: > Hi all, > >> I'm not sure if what I'm proposing would actually work. > > How prophetic. > > I did some more testing with the proposed change to `derivation`, and > it seems to be causing a weird issue. I didn't think that propagating > non-substitutability woul

Re: bug#55231: [PATCH v1] initrd: Allow extra search paths with ‘initrd-extra-module-paths’

Hi all, > I'm not sure if what I'm proposing would actually work. How prophetic. I did some more testing with the proposed change to `derivation`, and it seems to be causing a weird issue. I didn't think that propagating non-substitutability would be much of a problem, since there are very few

Re: bug#55231: [PATCH v1] initrd: Allow extra search paths with ‘initrd-extra-module-paths’

mally conservative (in terms of > > avoiding possible copyviols) approach to incorporating ZFS into > > Guix. If this makes sense, I would be happy to include that change to > > `derivation` in this patch set. > > > The idea is logical to me, but the implementation, if it

Re: bug#55231: [PATCH v1] initrd: Allow extra search paths with ‘initrd-extra-module-paths’

ou have a pseudo-code draft of where it'd be done? Few of us are knowledgeable about the daemon code base. > This seems to me to implement a maximally conservative (in terms of > avoiding possible copyviols) approach to incorporating ZFS into > Guix. If this makes sense, I would be ha

Re: bug#68453: closed (Re: bug#68453: [PATCH] doc: Improve VNC Services section.)

Hello Maxim, Thank you for reopening the issue. > > I meant that at one place we have (display-number 10), and then about > > 15 lines below, we have (display-number 5). That’s inconsistent! > > The same applies to the port numbers: 5910 vs. 5905. > > Is it a problem to show the use of different

Re: bug#68453: closed (Re: bug#68453: [PATCH] doc: Improve VNC Services section.)

read/trivial examples. > > You may not find my examples useful, but that doesn't convince me that > the existing ones are easy to read or trivial. > > The reason I took the time to modify this part of documentation and > submit a patch is precisely because I found the current

Re: bug#74736: [PATCH v2 0/1] Add Request-For-Comment process.

Hello Divya, Divya Ranjan skribis: > Glad that we've finalized the GCD! Really happy to see it. But is it that > you've missed my "I support" or that my name is not there in /etc/teams.scm? > I just did a search in https://issues.guix.gnu.org/74736 and found that I had > sent a "I support" on

Re: bug#64798: [PATCH 000/209] update kde package and add plasme desktop

Propagate gpgme. > b9e192ad9a gnu: Add qcoro-qt5. > ab3eba1447 gnu: Add kpipewire. > > Review is welcome, Thanks! Plasma build and works fine. Also fixed 3 mahjongg games with: >From 1e4085670a149df7e9858ef6c52995415cf27037 Mon Sep 17 00:00:00 2001 Message-ID: <1e4085670a149df7e9858ef6c52995415cf27037.169

Re: [PATCH v2 0/1] services: network-manager: Add extra-configuration-files field.

> I would advise against running a multitude of personal channels in favor > of collaborating with others on a much smaller number of channels -- and i agree. i meant to use the expression 'let a thousand flowers bloom' to be more about freedom and (friendly) competition, not the actual number.

Re: [bug#75145] [PATCH v2 0/1] services: network-manager: Add extra-configuration-files field.

Hi 45mg, 45mg <45mg.wri...@gmail.com> writes: [...] > Thanks, good to know. Will try to keep that in mind. I do wish there was > something I could do to get things moving faster, but I guess this is a > limitation of projects that run on (primarily) unpaid volunteer work :/ As mentioned by Rica

Re: [PATCH v2 0/1] services: network-manager: Add extra-configuration-files field.

Attila Lendvai writes: >> instead of calling for >> the proliferation of private channels, a different kind of unmanageable >> structurelessness. > > not private channels, simply channels that are not owned/controlled by > the exact same set of committers as guix proper, and not demanding the >

Re: [PATCH v2 0/1] services: network-manager: Add extra-configuration-files field.

> instead of calling for > the proliferation of private channels, a different kind of unmanageable > structurelessness. not private channels, simply channels that are not owned/controlled by the exact same set of committers as guix proper, and not demanding the exact same requirements from the

Re: bug#74736: [PATCH v2 0/1] Add Request-For-Comment process.

Simon Tournier skribis: >> Perhaps the “Decision Making” section could stress that, with a >> paragraph above “To learn …” along these lines: >> >> Consensus building requires that participants share a common goal, >> trust each other to act in good faith, listen to one another’s >> concern

Re: bug#74736: [PATCH v2 0/1] Add Request-For-Comment process.

Hi, On Thu, 16 Jan 2025 at 17:10, Ludovic Courtès wrote: >> Concerning consensus, I am mildly worried about deadlocks (including >> when trying to modify this RFC/GCD). What happens if some person insists >> on disapproving? > > This is a general question about consensus building. I agree. >

Re: bug#74736: [PATCH v2 0/1] Add Request-For-Comment process.

Hello! Andreas Enge skribis: > Concerning consensus, I am mildly worried about deadlocks (including > when trying to modify this RFC/GCD). What happens if some person insists > on disapproving? This is a general question about consensus building. For the situation you describe not to happen,

Re: [PATCH v2 0/1] services: network-manager: Add extra-configuration-files field.

Attila Lendvai writes: >> > this patch failed to get any attention in two weeks >> >> >> Two weeks isn't a long time in free software projects. A more common >> time frame would be between one year and eighteen months. > > > ...and with such a del

Re: [PATCH v2 0/1] services: network-manager: Add extra-configuration-files field.

> > this patch failed to get any attention in two weeks > > > Two weeks isn't a long time in free software projects. A more common > time frame would be between one year and eighteen months. ...and with such a delay most patches bitrot beyond recognition, then after o

Re: [PATCH v2 0/1] services: network-manager: Add extra-configuration-files field.

Hi Guix, I'd just like to apologise for CC'ing Guix-Devel at this point; this patch isn't nearly critical enough to warrant the noise after two weeks' wait - which, as Felix points out, really isn't that long in the grand scheme of things. I got impatient; I'm

Re: [PATCH v2 0/1] services: network-manager: Add extra-configuration-files field.

Hi 45mg, On Thu, Jan 09 2025, 45mg wrote: > this patch failed to get any attention in two weeks Two weeks isn't a long time in free software projects. A more common time frame would be between one year and eighteen months. > I'm CC'ing guix-devel on this one Pings are g

Re: [bug#75145] [PATCH v2 0/1] services: network-manager: Add extra-configuration-files field.

, which is read-only. So we can't create "/etc/NetworkManager/system-connections/". And this won't do, since NetworkManager itself needs to be able to write to that directory to manage saved connections. So it looks like that won't work. > Would it make sense to allow t

Re: [bug#75145] [PATCH v2 0/1] services: network-manager: Add extra-configuration-files field.

Hi, Thank you for your patch. 45mg <45mg.wri...@gmail.com> writes: > As the first revision of this patch failed to get any attention in two weeks, > I'm CC'ing guix-devel on this one, hoping it'll get reviewed this time. Let me > know if I should have done a

[PATCH v2 1/1] services: network-manager: Add extra-configuration-files field.

Allow users to specify additional configuration files for NetworkManager. These files will be added to `/etc/NetworkManager/conf.d` (NetworkManager's default configuration directory location). * gnu/services/networking.scm () [extra-configuration-files]: New field. (network-manager-configuration-d

[PATCH v2 0/1] services: network-manager: Add extra-configuration-files field.

Hi Guix, As the first revision of this patch failed to get any attention in two weeks, I'm CC'ing guix-devel on this one, hoping it'll get reviewed this time. Let me know if I should have done anything differently; I'm still relatively new to contributing. This patch all

Re: [PATCH 1/2] teams: Add hurd team.

Ludovic Courtès writes: > Janneke Nieuwenhuizen skribis: > >>> Am Tue, Dec 03, 2024 at 02:34:10PM +0100 schrieb Janneke Nieuwenhuizen: * etc/teams.scm (hurd): New team. >>> >>> I think you should simply push these two patches :) >> >> Pushed as 38bbed33a28524c26ca794117f6dfed1529e2807, thank

Re: [bug#62917] [bug#73799] [PATCH] Fix 'guix shell: error: symlink: File exists: "/bin/cc"'

Hi Marco, Marco Fortina writes: > This patch closes issue when running "guix shell --container --emulate-fhs > clang-toolchain gcc-toolchain" or "guix shell --container --emulate-fhs > clang-toolchain gcc-toolchain": > > > diff --git a/guix/

Re: [PATCH 1/2] teams: Add hurd team.

Hi, Janneke Nieuwenhuizen skribis: >> Am Tue, Dec 03, 2024 at 02:34:10PM +0100 schrieb Janneke Nieuwenhuizen: >>> * etc/teams.scm (hurd): New team. >> >> I think you should simply push these two patches :) > > Pushed as 38bbed33a28524c26ca794117f6dfed1529e2807, thanks. Thanks! I support this n

Re: [PATCH 0/1] qt-build-system: Wrap with build variables to allow %outputs in arguments

Hi John, thanks. > You should be able to use gexps, e.g. #$output (see > > for more details). That is actually the preferred way now, though > there are still instances of assoc-ref. > I believe the commit in question is >

Re: [PATCH 0/1] qt-build-system: Wrap with build variables to allow %outputs in arguments

83e34fe1>. > I think the issue is in qt using different system than build systems such > as cmake or gnu. Since I am unsure about the reason for qt not having > the same structure, I am submitting this to guix devel for discussion, > as well as opening a patch in case this is fi

[PATCH 0/1] qt-build-system: Wrap with build variables to allow %outputs in arguments

g the same structure, I am submitting this to guix devel for discussion, as well as opening a patch in case this is fine to be merged. If not, could someone please explain what the reason behind not adding inputs and outputs is, and what is the alternative? Regards, Rutherther Rutherther (1): gui

Re: [PATCH 1/2] teams: Add hurd team.

Andreas Enge writes: Hello Andreas, > Am Tue, Dec 03, 2024 at 02:34:10PM +0100 schrieb Janneke Nieuwenhuizen: >> * etc/teams.scm (hurd): New team. > > I think you should simply push these two patches :) Pushed as 38bbed33a28524c26ca794117f6dfed1529e2807, thanks. Janneke -- Janneke Nieuwenhuiz

Re: [PATCH 1/2] teams: Add hurd team.

Hello, Am Tue, Dec 03, 2024 at 02:34:10PM +0100 schrieb Janneke Nieuwenhuizen: > * etc/teams.scm (hurd): New team. I think you should simply push these two patches :) Thanks, Andreas

[PATCH 1/2] teams: Add hurd team.

* etc/teams.scm (hurd): New team. Change-Id: Id3b4d8ac3eed8c7773a45d0fe8a17154c6427aa1 --- etc/teams.scm | 9 + 1 file changed, 9 insertions(+) diff --git a/etc/teams.scm b/etc/teams.scm index 4f86dfb954..ab9b9e9160 100755 --- a/etc/teams.scm +++ b/etc/teams.scm @@ -610,6 +610,15 @@ (def

[PATCH 2/2] etc: teams: Add entry for Janneke Nieuwenhuizen.

* etc/teams.scm.in ("Janneke Nieuwenhuizen"): New member. Change-Id: Ia666772ae681cd869ffce84da65078c9174fa110 --- etc/teams.scm | 4 1 file changed, 4 insertions(+) diff --git a/etc/teams.scm b/etc/teams.scm index ab9b9e9160..6b492f1d4b 100755 --- a/etc/teams.scm +++ b/etc/teams.scm @@ -78

[bug#73462][PATCH] emacs-guix: shell commands broken

>From 282aea01d0212e3a9a2acac52d76a6a7325cf7e7 Mon Sep 17 00:00:00 2001 From: Christopher Howard Date: Wed, 6 Nov 2024 05:53:45 -0900 Subject: [PATCH] Provides work-around for https://issues.guix.gnu.org/issue/73462 --- elisp/guix-repl.el | 5 + 1 file changed, 5 insertions(+) diff --

Re: [PATCH v1] shepherd: add support for kexec

Hi Jakob, Jakob Kirsch skribis: > This patch adds preliminary support for rebooting into kexec using `reboot > -k` or `reboot --do-kexec`. Nice! That sounds useful. Some comments inline below. In the future, could you send patches to guix-patc...@gnu.org, with “Shepherd” in the s

Re: Fwd: [GNU bug Tracking System] bug#73864: Acknowledgement ([PATCH] gnu: rust: update to 1.82)

wrote: > >> >> On 21 October 2024 18:08:44 GMT, Brennan Vincent > >> >> wrote: > >> >> >Note that we already have Rust 1.81 in rust-team, and I have already > >> >> >sent a patch to update to 1.82 (the latest stable). Usual

Re: Fwd: [GNU bug Tracking System] bug#73864: Acknowledgement ([PATCH] gnu: rust: update to 1.82)

rote: >> >> >Note that we already have Rust 1.81 in rust-team, and I have already >> >> >sent a patch to update to 1.82 (the latest stable). Usually Efraim >> >> >reviews these updates. >> >> > >> >> > Sta

Re: Fwd: [GNU bug Tracking System] bug#73864: Acknowledgement ([PATCH] gnu: rust: update to 1.82)

Rust 1.81 in rust-team, and I have already > >> >sent a patch to update to 1.82 (the latest stable). Usually Efraim > >> >reviews these updates. > >> > > >> > Start of forwarded message > >> >Fr

Re: R: Fwd: [GNU bug Tracking System] bug#73864: Acknowledgement ([PATCH] gnu: rust: update to 1.82)

r.co.il > > Oggetto: Re: Fwd: [GNU bug Tracking System] bug#73864: Acknowledgement > ([PATCH] gnu: rust: update to 1.82) > > By the way, if you want to use Rust 1.82.0 before it gets accepted for > the default guix channel, you can use my channel (and install > `rust-next`,

Re: Fwd: [GNU bug Tracking System] bug#73864: Acknowledgement ([PATCH] gnu: rust: update to 1.82)

Efraim Flashner writes: > On Tue, Oct 22, 2024 at 07:31:05AM +, Divya wrote: >> On 21 October 2024 18:08:44 GMT, Brennan Vincent >> wrote: >> >Note that we already have Rust 1.81 in rust-team, and I have already >> >sent a patch to update to 1.82 (t

[bug#62917] [bug#73799] [PATCH] Fix 'guix shell: error: symlink: File exists: "/bin/cc"'

This patch closes issue when running "guix shell --container --emulate-fhs clang-toolchain gcc-toolchain" or "guix shell --container --emulate-fhs clang-toolchain gcc-toolchain": diff --git a/guix/scripts/environment.scm b/guix/scripts/environment.scm index a219b2ac89..37f

Re: Fwd: [GNU bug Tracking System] bug#73864: Acknowledgement ([PATCH] gnu: rust: update to 1.82)

On Tue, Oct 22, 2024 at 07:31:05AM +, Divya wrote: > On 21 October 2024 18:08:44 GMT, Brennan Vincent > wrote: > >Note that we already have Rust 1.81 in rust-team, and I have already > >sent a patch to update to 1.82 (the latest stable). Usually Efraim > &

  1   2   3   4   5   6   7   8   9   10   >