Re: [bug#78332] GCD005: Regular and efficient releases (submitted)

On Mon, Jun 30, 2025 at 9:33 AM Ludovic Courtès wrote: > > Hi Greg, > > Greg Hogan writes: > > > My opinions on the project release cadence are of no greater > > consequence than the update frequency or inclusion of any individual > > package by a contributor or

Re: GCD005: Regular and efficient releases (consideration/decision)

On Mon, Jun 23, 2025 at 10:44 AM Steve George wrote: > > Hi all, > > After a good long discussion I'm moving GCD005 to Deliberation. > > The final version is below and can be found on Codeberg: > > > https://codeberg.org/guix/guix-consensus-documents/src/branch/main/005-regular-releases.md I

Re: Forgejo: branch master is protected from unverified commit

On Wed, Jun 25, 2025 at 8:59 AM Z572 wrote: > > Greg Hogan writes: > > > My local guix and git repo validate the signature, but when pushing > > the validated commit upstream to codeberg the commit is rejected as > > unverified. The key is present in .guix-authorizati

Re: Forgejo: branch master is protected from unverified commit

> On Wed, Jun 25, 2025 at 8:59 AM Z572 wrote: > > > > It still needs to be configured in codeberg > > see https://codeberg.org/user/settings/keys This was it. I had overlooked that both the ssh and gpg keys need to be configured. Thank you!

Forgejo: branch master is protected from unverified commit

(HEAD -> master) gpg: Signature made Wed 25 Jun 2025 11:29:36 AM UTC gpg:using RSA key 00234208F3F2BBD7CE14EF6EB27413CFEEF3 gpg:issuer "c...@greghogan.com" gpg: Good signature from "Greg Hogan " [ultimate] Author: Ashish SHUKLA Date: T

Re: [bug#78332] GCD005: Regular and efficient releases (submitted)

On Fri, Jun 20, 2025 at 1:53 PM Andreas Enge wrote: > > Hello, > > Am Fri, Jun 20, 2025 at 11:28:19AM -0400 schrieb Greg Hogan: > > > I think you put it very mildly; the real problem of our current process > > > is that it apparently has turned into "no release

Re: [bug#78332] GCD005: Regular and efficient releases (submitted)

On Fri, Jun 13, 2025 at 2:31 PM Andreas Enge wrote: > > Am Sat, Jun 07, 2025 at 01:03:10PM +0100 schrieb Steve George: > > One way to consider that risk is to think about whether a GCD is > > irreversible (a one-day door). Trying 'regular releases' is not a one-way > > door. We can try it out, a

Re: [bug#76503] [GCD] Migrating repositories, issues, and patches to Codeberg

On Tue, May 13, 2025 at 11:50 AM Vagrant Cascadian wrote: > > On 2025-05-13, Greg Hogan wrote: > > On Tue, May 13, 2025 at 9:32 AM pinoaffe wrote: > >> > >> If someone prefers that a GCD be withdrawn but would find its acceptance > >> acceptable, they shoul

Re: GCD005: Regular and efficient releases

ssons learned rather than speculate beforehand. > Am Mon, May 12, 2025 at 01:11:15PM -0400 schrieb Greg Hogan: > > I think we should release more often (multiple times per year) > > So I am definitely not getting your point! With the goal of moving forward, > could you try to ref

Re: [bug#76503] [GCD] Migrating repositories, issues, and patches to Codeberg

On Tue, May 13, 2025 at 9:32 AM pinoaffe wrote: > > If someone prefers that a GCD be withdrawn but would find its acceptance > acceptable, they should probably "vote" accept, even if their preference > is quite strong This preference is indicated by not voting. If 75% of team members "vote" this

Re: GCD005: Regular and efficient releases

On Mon, May 12, 2025 at 12:23 PM Rutherther wrote: > > Hi Greg, > > Greg Hogan writes: > > > On Fri, May 9, 2025 at 5:55 PM Steve George wrote: > >> > >> I hope the initial user experience wouldn't be to "break on the user's > >> f

Re: Preparing ungrafts

On Mon, May 12, 2025 at 11:34 AM Ludovic Courtès wrote: > > Hello, > > Greg Hogan writes: > > > I would like to second Leo's idea from the kernel-team branch discussion: > > > > Changing the subject, it would be nice if grafts were committed > > al

Re: GCD005: Regular and efficient releases

On Fri, May 9, 2025 at 5:55 PM Steve George wrote: > > I hope the initial user experience wouldn't be to "break on the user's first > pull", since with annual releases we wouldn't have release artefacts that are > 2.5 years out of date. And, we'd also degraft regularly which would be > benefici

Preparing ungrafts

How many grafts are currently on the master branch? My (potentially naive and) simple regex returns less than a dozen, but when building packages I see counts like "applying 100 grafts for ...". Is the latter a recursive count? The current GCD proposal on release planning contains the following:

Re: Committers: create and share your Codeberg account

On Fri, May 9, 2025 at 5:46 AM Ludovic Courtès wrote: > > Hello Guix! > > If you’re a committer, please consider creating an account on Codeberg. > > To avoid problems, I suggest you send your account name as a public > reply to this message, in a signed message. > > You will be given rights on Co

Re: GCD005: Regular and efficient releases

On Fri, May 9, 2025 at 8:54 AM Steve George wrote: > [...] > Adding a slower-moving branch akin to Nix's stable could be an eventual goal > as > it would increase Guix's suitability for some users and use-cases [^2]. > However, > this GCD only sets out to implement regular releases which is a s

Re: [GCD] Deliberation on: Migrating repositories, issues, and patches to Codeberg

On Wed, Apr 23, 2025 at 5:11 AM Ludovic Courtès wrote: > > Hello Guix, > > It’s been two months since we started discussing GCD 002, entitled > “Migrating repositories, issues, and patches to Codeberg”. Its final > version is attached below. > > In accordance with the GCD process, team members ha

Re: our git linked with openssl, license is incompatible

On Tue, Apr 15, 2025 at 4:38 AM Z572 wrote: > > see https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1094969 Should we follow Debian's lead and close this bug?

Questions on Managing Patches and Branches

How "ready" do branches need to be in the "request to merge" queue? Our documentation [0] includes both of the following statements: "Once a branch is at the front of the queue, wait until sufficient time has passed for the build farms to have processed the changes, and for the necessary testing t

New committer

particular use has been creating shared build environments with a focus on C++ development. My hope is to use the teams/branches workflow to provide more and more timely updates to these packages. Greg Hogan keyname: oom -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEACqqo0II8

Re: Trying out Codeberg

On Fri, Feb 21, 2025 at 3:45 AM Alexis Simon wrote: > > Hello, > > For those interested I tried the AGit workflow [1] on guix-science and > it worked nicely to start a PR from the command line without forking > [2]. Not sure it was mentioned before. I ran the following for a single commit pull re

Re: On the quest for a new release model

On Wed, Dec 18, 2024 at 11:49 AM Ludovic Courtès wrote: > As has been discussed multiple times at the Guix Days and on this list > (I think?), I believe what we need is a release team with rotating > duties. That is, a bunch of 3–5 people commit to doing the work leading > to 1.5.0; then a new te

Re: On the quest for a new release model

On Wed, Dec 18, 2024 at 12:43 PM Suhail Singh wrote: > > Suhail Singh writes: > > > The issue, as I see it, is the time commitment required from the > > release-team. > > Correction, the issues (IMO) are (in no particular order): > 1. the timespan (several weeks) > 2. uncertainty around total eff

Re: On the quest for a new release model

On Fri, Dec 13, 2024 at 8:02 AM Suhail Singh wrote: > > Ricardo Wurmus writes: > > > Releases are made a short time after the core team branch is merged. > > This would give us a new release whenever e.g. the default GCC and > > glibc is bumped up. We could aim for a release two months after the

Re: Creating a C/C++ team?

On Fri, Nov 29, 2024 at 4:35 AM Liliana Marie Prikler wrote: > > Hi Greg, > > Am Montag, dem 25.11.2024 um 13:27 -0500 schrieb Greg Hogan: > > Guix, > > > > Should we have a C++ team? I think project contributions regarding C > > and C++ compilers, librarie

Creating a C/C++ team?

Guix, Should we have a C++ team? I think project contributions regarding C and C++ compilers, libraries, tools, and programs would benefit from a tag to flag, discuss, and triage issues and a team branch to manage, test, and pre-build patches. This team would of course be distinct from the core-p

Re: Discussion on Guix funding // future

On Fri, Oct 25, 2024 at 7:25 PM Attila Lendvai wrote: [...] > this is also a chicken-egg issue: until some authority is delegated, the > center will remain a bottleneck. [...] > ... then i considered the effort it would take to send a patch, and the fact > that i already have a lot of my eff

Re: Discussion on Guix funding // future

On Fri, Oct 25, 2024 at 10:21 AM Noé Lopez via Development of GNU Guix and the GNU System distribution. wrote: > > Furthermore, on the topic of mail, I totally agree with David > Thompson. Mail is cool, I get it, but another way to contribute like > pull requests on a forgejo/gitlab mirror would b

Re: guix shell: error: symlink: File exists: "/bin/cc"

On Thu, Oct 24, 2024 at 4:03 AM Marco Fortina wrote: > > Hello! > > Yes, only changes in the environment.scm files are required for fixing the > issue. > > Why did you make the patch so complex? There are many potential errors in addition to EEXIST: https://man7.org/linux/man-pages/man2/symlin

Re: Limiting resource usage on ci.guix.gnu.org

On Wed, Oct 23, 2024 at 12:14 PM Ludovic Courtès wrote: > > Hello Guix, [...] > 2. When rebasing on top of ‘master’, please cancel pending builds from > previous evaluations that have become irrelevant. How is this issue limited to rebasing to 'master'? For example, if the rust team push

Re: 1.5.0 release?

On Fri, Sep 6, 2024 at 5:32 AM Ludovic Courtès wrote: > > Hi Greg, > > Greg Hogan skribis: > > > With the recent core-updates merge, and as the master branch > > stabilizes, is there a plan or desire for a 1.5.0 release? > > Desire, definitely; plan? we have

Re: upgrade to new version of packages with lots of dependencies--installing new versions along first?

On Fri, Sep 6, 2024 at 4:56 PM Andy Tai wrote: > > Maybe this can be generalized for packages with lots of dependencies, > say for any package A with 300 (or 1000) dependencies, when upgrading > to a new version, add that as A-next so existing A is not touched. > Then A-next can be added without a

1.5.0 release?

Hi Guix, With the recent core-updates merge, and as the master branch stabilizes, is there a plan or desire for a 1.5.0 release? It has been 20 months since the 1.4.0 release, which is already more than the previously longest interval (18 months for v1.4.0). 2023 was the first year without a rele

Re: Next Steps For the Software Heritage Problem

On Tue, Jun 18, 2024 at 12:33 PM MSavoritias wrote: > > Ah it seems I wasn't clear enough. > I meant write something like: > > By packaging a software project for Guix you are exposing said software > to a code harvesting project (also known as LLMs or "AI") run by > Software Heritage and/or their

Re: Next Steps For the Software Heritage Problem

On Tue, Jun 18, 2024 at 4:37 AM MSavoritias wrote: > > 1. Add a clear disclaimer/requirment that any new package that is added > in Guix, the person has to give consent or get consent from the person > that the package is written in. This needs to be added in the docs and > in the email procedures

Re: cmake-build-system: build tests only if #:tests? is true?

On Mon, Mar 4, 2024 at 6:01 PM Hartmut Goebel wrote: > > Hi Greg, > > I will submit a patchset shortly for review and if accepted we can > > look to combine all the cmake patches for the large rebuild. > > Yes, of course we should combine them. May I ask you to take care of it > and include mine,

Re: Mandb does not include guix package man pages

On Wed, Mar 13, 2024 at 1:49 AM Pan Xie wrote: > > Hello > > I find this issue on both GuixSD and guix package manager on ArchLinux. > The problem is `man -k' can not find manpages installed by guix. I > believe the issue is caused by `mandb' does not include guix packages' > man pages when genera

Re: cmake-build-system: build tests only if #:tests? is true?

On Sat, Mar 2, 2024 at 4:17 PM Hartmut Goebel wrote: > > Hi, > > I found an old and unfinished patch in my pile. It optimizes building > with cmake by not building the test if "#:tests?" is false. (Basically > it passes -DBUILD_TESTING=OFF/ON" depending on "#:tests?".) > > Is this of interest? The

Helping with abandoned patches

What is the preferred process for when a patch review is provided (often by a committer) but no response is received from the submitter (for many weeks or months)? Is it appropriate to make the recommended changes and submit an updated patch? Examples include #62262 and #67294, but there surely a

Re: Order of manifest and overlapping binaries

On Mon, Oct 23, 2023 at 10:39 AM Kaelyn wrote: > > Hi, > > --- Original Message --- > On Monday, October 23rd, 2023 at 6:18 AM, Greg Hogan > wrote: > > > > > On Tue, May 16, 2023 at 4:55 PM Csepp raingl...@riseup.net wrote: > > > > > Greg

Re: Order of manifest and overlapping binaries

On Tue, May 16, 2023 at 4:55 PM Csepp wrote: > > > Greg Hogan writes: > > > 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

Re: [bug#62047] [PATCH 0/2] '--with-input' & co. no longer replace hidden packages

On Wed, Mar 8, 2023 at 7:03 AM Ludovic Courtès wrote: > > Hello, > > This change makes things like: > > guix build --with-input=guile=guile-next guix -n --no-grafts > > more useful and tractable. > > Low-level rewrites are still possible for packages not marked > as hidden in 'commencement.scm',

Order of manifest and overlapping binaries

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 package, as below. Unclear if this is consistent. In my manifest

Re: Guix CI "No space left on device"

On Tue, May 16, 2023 at 11:06 AM Simon Tournier wrote: > > Hi, > > On Tue, 09 May 2023 at 10:47, Greg Hogan wrote: > > icedtea-3.19.0 fails to build with ... > > http://ci.guix.gnu.org/build/1331007/details > > [...] > > > note: build failure may have

Re: Substitute not downloading

On Wed, May 10, 2023 at 5:35 AM Andreas Enge wrote: > > I think the substitute not being available may have to do with the > difference between the package being available in the store, and as a > nar file for substitution. As I understand it, the first request for a nar > can fail, then it is bui

Substitute not downloading

I have an up-to-date Guix but am unable to fetch the substitute from http://ci.guix.gnu.org/build/1332269/details Are substitutes only available after the evaluation has completed? --8<---cut here---start->8--- $ guix describe Generation 9May 09 2023 15:1

Guix CI "No space left on device"

icedtea-3.19.0 fails to build with ... http://ci.guix.gnu.org/build/1331007/details --8<---cut here---start->8--- repacking /gnu/store/cyxfl45c31dg84spwkazadnmn2c94rak-icedtea-3.19.0-jdk/lib/jconsole.jar java.io.IOException: No space left on device at

Ungrafted dependency

mariadb is grafted on master. Why does libreoffice depend on the ungrafted mariadb rather than the grafted version? And, perhaps related, since libreoffice depends on mariadb's "dev" output, why does libreoffice pull in "out"? mariadb:dev was created specifically as a libreoffice dependency in the

proot-static build failures (master and core-updates)

We now have a build attempt on Cuirass: https://ci.guix.gnu.org/build/982993/details proot-static is required for building relocatable packages. That is on core-updates, but I see the same issue building from source on master, as well as running manually outside of the proot. The check fails on t

Re: i686 core-updates failure.

On Thu, Apr 13, 2023 at 11:53 AM Ricardo Wurmus wrote: > > Yes, this is only i686 and it’s worth thinking about whether to continue > supporting this architecture when developers seemingly don’t care about > it any more. But just removing foundational packages is akin to just > giving up. We hav

Re: Guix release broken without substitutes on ungrafted openssl

On Wed, Feb 15, 2023 at 1:33 PM Leo Famulari wrote: > > It only really affects distros like Guix or Nix, so it's our problem to > fix. I forgot to mention that I also needed to switch the pull url from https to http, otherwise git would fail on certificate verification. I believe this is secure w

Guix release broken without substitutes on ungrafted openssl

Guix, Installing guix from source fails on the build of openssl@1.1.1l. I see the same error on my working system (log attached) when executing the command below. The issue looks to be caused by OpenSSL's expired test certs fixed in 1.1.1p [0]. Guix currently grafts openssl 1.1.1s but it seems gra

Re: Dealing with non-ASCII file names in BOOTSTRAP-ORIGIN

Marius, Thank you for your work upgrading the core packages! On the off chance that the following is helpful, in order to switch the build to GCC 11 or 12 I had to apply the patch (with the missing endif) from https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100017#c12 You may have avoided or work

Re: aarch64 workers appear to have stalled on ci.guix.gnu.org

On Wed, Jun 8, 2022 at 4:59 PM Ludovic Courtès wrote: > It looks like ‘cuirass-remote-worker’ needed a kick on these boxes, > which Mathieu and I did earlier today (‘herd restart …’). Most of them > are busy right now. I only count 7 successful builds for aarch64, and several more under spec:gui

Re: Building clang with gcc-toolchain@11

On Mon, Mar 7, 2022 at 5:18 AM Ludovic Courtès wrote: > The ‘clang’ definition reads: > > ;; Use a sane default include directory. > (string-append "-DC_INCLUDE_DIRS=" > (assoc-ref %build-inputs "libc") > "/include"

Building clang with gcc-toolchain@11

When creating a profile containing both clang-toolchain and gcc-toolchain I see the same issue as in #43023; however, if I specify the default gcc-toolchain (currently gcc-toolchain@10) then clang and gcc work just fine together. --8<---cut here---start->8--- $

Re: Unable to bootstrap Guix without substitutes

On Wed, Feb 16, 2022 at 4:28 PM Greg Hogan wrote: > I then saw the error building binutils-mesboot0 as in bug #41264, for > which Mathieu proposed an idea for fixing Mes, still awaiting > implementation. > > As a temporary fix the same tmpfs trick works when bind mounting /gnu

Re: Unable to bootstrap Guix without substitutes

On Thu, Feb 10, 2022 at 8:39 PM Timothy Sample wrote: > I can perform the build successfully using > > $ guix build --check \ > -e '(@@ (gnu packages commencement) bash-masboot0)' > > That scary backtrace happens even for the successful build, so I’m > pretty sure it is not the issue.

Unable to bootstrap Guix without substitutes

When installing the Guix binary distribution (both the 1.3.0 release and most recent guix-binary on ci.guix.gnu.org) on a new system without enabling substitutes the guix pull or install commands fail when building bash-mesboot0. https://guix.gnu.org/manual/en/html_node/Binary-Installation.html

Re: Test parallelism with CMake

On Fri, Oct 29, 2021 at 8:09 AM Ludovic Courtès wrote: > Hi Greg, > > Greg Hogan skribis: > > It seems that we should at a minimum document the issue in > > cmake-build-system:check. We could patch cmake-build-system to enable > test > > parallelism and expli

Re: Test parallelism with CMake

On Sat, Oct 9, 2021 at 3:56 AM Liliana Marie Prikler < liliana.prik...@gmail.com> wrote: > for the purposes of GNU Guix, #:parallel-build? and #:parallel-tests? > are distinct flags and the latter (if implemented) would apply to the > check phase. Our cmake-build-system in this case defers to gnu

Re: Test parallelism with CMake

Hi Liliana, The packages I am building do not disable parallel tests. Greg On Sat, Oct 9, 2021 at 3:56 AM Liliana Marie Prikler < liliana.prik...@gmail.com> wrote: > Hi Greg, > > for the purposes of GNU Guix, #:parallel-build? and #:parallel-tests? > are distinct flags and the latter (if implem

Test parallelism with CMake

Guix, As I read the source, cmake-build-system should by default both build and check with parallelism enabled. When I locally build a package only the build phase runs with parallelism and tests are being run in serial. When I run a manual build (stopping an in-process build run with '-K', then

Re: Offline build failure

5.9.tar.xz 0rkn451qfz3gbni57la00a5fbgish9jmm5bmhmgmf223vxwya447 Since the tarball is not restored to the original location the guix build command still attempts the download and fails the offline build. Greg Hogan On Fri, Dec 11, 2020 at 9:42 PM Tobias Geerinckx-R

Offline build failure

I am attempting an offline build without success. I have a Guix 1.2.0 node with internet access on which I download sources with transitive dependencies: $ guix build --sources=transitive tzdata > ~/transfer I then copy the files as root to a Guix 1.2.0 node without internet access (only local n

Mailing Lists List

When I google for “guix mailing lists” I am directed to https://savannah.gnu.org/mail/?group=guix which does not include guix-devel. It is returned as my second google link and also of course listed on the Guix website but would be helpful to include

Building a library as both static and dynamic

Is there a best practice or example for building a library twice, both static and dynamic? I submitted patch #43620, and in working on another library have the same issue. These are cmake builds with a parameter declaration for either a static or dynamic build, not both. I would like to create a