* bug#70456: Request for merging core-updates branch @ 2024-04-18 14:56 Steve George 2024-04-19 14:42 ` bug#70456: Request for merging "core-updates" branch Christopher Baines ` (4 more replies) 0 siblings, 5 replies; 15+ messages in thread From: Steve George @ 2024-04-18 14:56 UTC (permalink / raw) To: 70456 Let's see where we are with the branch currently. Thanks, Steve / Futurile ^ permalink raw reply [flat|nested] 15+ messages in thread
* bug#70456: Request for merging "core-updates" branch 2024-04-18 14:56 bug#70456: Request for merging core-updates branch Steve George @ 2024-04-19 14:42 ` Christopher Baines 2024-04-19 17:00 ` Christopher Baines 2024-04-26 14:44 ` tumashu ` (3 subsequent siblings) 4 siblings, 1 reply; 15+ messages in thread From: Christopher Baines @ 2024-04-19 14:42 UTC (permalink / raw) To: 70456, steve [-- Attachment #1: Type: text/plain, Size: 1121 bytes --] Hey, Thanks for raising this issue Steve, given the branch has been going for around 9 months (since [1]) now, I think it's well overdue to start looking at building and merging it. 1: https://lists.gnu.org/archive/html/guix-commits/2023-07/msg00332.html I pushed a single commit plus a merge from master today, and that was pretty difficult. There was plenty of conflicts, and I probably have resolved some wrongly, and there's potentially some things that Git didn't raise as conflicts but might have broken with merging in master. I'm also really confused by what commits appear to be on the branch, take 12b15585a75062f3fba09d82861c6fae9a7743b2 which appears to be one core-updates, but it's a duplicate of e2a7c227dea5b361e2ebdbba24b923d1922a79d0 which was pushed to master. Same with this commit 28d14130953d868d4848540d9de8e1ae4a01a467, which is different to f29f80c194d0c534a92354b2bc19022a9b70ecf8 on master. Putting aside the functional changes on core-updates, it's doesn't seem good to merge these seemingly duplicate commits on to master. I'm not sure how this happened though, or how to fix it. Chris [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 987 bytes --] ^ permalink raw reply [flat|nested] 15+ messages in thread
* bug#70456: Request for merging "core-updates" branch 2024-04-19 14:42 ` bug#70456: Request for merging "core-updates" branch Christopher Baines @ 2024-04-19 17:00 ` Christopher Baines 2024-04-20 16:16 ` Maxim Cournoyer 0 siblings, 1 reply; 15+ messages in thread From: Christopher Baines @ 2024-04-19 17:00 UTC (permalink / raw) To: 70456; +Cc: Maxim Cournoyer, steve [-- Attachment #1: Type: text/plain, Size: 1491 bytes --] Christopher Baines <mail@cbaines.net> writes: > I'm also really confused by what commits appear to be on the branch, > take 12b15585a75062f3fba09d82861c6fae9a7743b2 which appears to be one > core-updates, but it's a duplicate of > e2a7c227dea5b361e2ebdbba24b923d1922a79d0 which was pushed to > master. Same with this commit 28d14130953d868d4848540d9de8e1ae4a01a467, > which is different to f29f80c194d0c534a92354b2bc19022a9b70ecf8 on > master. I've worked out at least when these two werid commits turned up on core-updates. 12b15585a7 is mentioned here: https://lists.gnu.org/archive/html/guix-commits/2023-09/msg00955.html and 28d1413095 is mentioned here: https://lists.gnu.org/archive/html/guix-commits/2024-03/msg00381.html With the changes last month in March, I was going to suggest deleting the branch and then re-creating from f205179ed2 and trying to re-apply the changes that should be on core-updates, while avoiding any "duplicate" commits. However, I'm not even sure where to being with the ~5000 commits pushed in September, at least one of them is a duplicate of a commit on master, but I'm not sure how many of the other ~5000 are. For comparison, I did a merge of master in to core-updates today, and this is what it shows up like on guix-commits: https://lists.gnu.org/archive/html/guix-commits/2024-04/msg01209.html There are only two new revisions, the ed update I pushed, and the merge commit, which is what a merge should look like as far as I'm aware. [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 987 bytes --] ^ permalink raw reply [flat|nested] 15+ messages in thread
* bug#70456: Request for merging "core-updates" branch 2024-04-19 17:00 ` Christopher Baines @ 2024-04-20 16:16 ` Maxim Cournoyer 2024-04-20 18:08 ` Christopher Baines 0 siblings, 1 reply; 15+ messages in thread From: Maxim Cournoyer @ 2024-04-20 16:16 UTC (permalink / raw) To: Christopher Baines; +Cc: 70456, steve Hi, Christopher Baines <mail@cbaines.net> writes: > Christopher Baines <mail@cbaines.net> writes: > >> I'm also really confused by what commits appear to be on the branch, >> take 12b15585a75062f3fba09d82861c6fae9a7743b2 which appears to be one >> core-updates, but it's a duplicate of >> e2a7c227dea5b361e2ebdbba24b923d1922a79d0 which was pushed to >> master. Same with this commit 28d14130953d868d4848540d9de8e1ae4a01a467, >> which is different to f29f80c194d0c534a92354b2bc19022a9b70ecf8 on >> master. > > I've worked out at least when these two werid commits turned up on > core-updates. > > 12b15585a7 is mentioned here: > https://lists.gnu.org/archive/html/guix-commits/2023-09/msg00955.html > > and 28d1413095 is mentioned here: > https://lists.gnu.org/archive/html/guix-commits/2024-03/msg00381.html > > > With the changes last month in March, I was going to suggest deleting > the branch and then re-creating from f205179ed2 and trying to re-apply > the changes that should be on core-updates, while avoiding any > "duplicate" commits. However, I'm not even sure where to being with the > ~5000 commits pushed in September, at least one of them is a duplicate > of a commit on master, but I'm not sure how many of the other ~5000 are. > > For comparison, I did a merge of master in to core-updates today, and > this is what it shows up like on guix-commits: > > https://lists.gnu.org/archive/html/guix-commits/2024-04/msg01209.html > > There are only two new revisions, the ed update I pushed, and the merge > commit, which is what a merge should look like as far as I'm aware. I think probably what happened is that in the middle of a merge of master -> core-updates (which entails sometimes painful conflicts resolution), a new commit pushed to core-updates, and to be able to push the resulting local branch (including the thousands of commits from the merge commit) got rebased on the remote core-updates. Perhaps another merge commit appeared on the remote around the same time, which would explain the duplicates. While I agree it's messy to have 5000 of duplicated commits, I'm not sure attempting to rewrite the branch, which has seen a lot of original commits, is a good idea (it'd be easy to have some good commits fall into cracks, leading to lost of work). I'd rather we take this experience as a strong reminding that rebasing merge commits should be avoided at all costs (git already issues a warning, IIRC). As you suggested, the next time a situation like this happens (locally prepared merge commit with new commits made to the remote branch), merging the remote into the local branch is probably a nicer solution. -- Thanks, Maxim ^ permalink raw reply [flat|nested] 15+ messages in thread
* bug#70456: Request for merging "core-updates" branch 2024-04-20 16:16 ` Maxim Cournoyer @ 2024-04-20 18:08 ` Christopher Baines 2024-04-22 17:31 ` Maxim Cournoyer 0 siblings, 1 reply; 15+ messages in thread From: Christopher Baines @ 2024-04-20 18:08 UTC (permalink / raw) To: Maxim Cournoyer; +Cc: 70456, steve [-- Attachment #1: Type: text/plain, Size: 4238 bytes --] Maxim Cournoyer <maxim.cournoyer@gmail.com> writes: > Hi, > > Christopher Baines <mail@cbaines.net> writes: > >> Christopher Baines <mail@cbaines.net> writes: >> >>> I'm also really confused by what commits appear to be on the branch, >>> take 12b15585a75062f3fba09d82861c6fae9a7743b2 which appears to be one >>> core-updates, but it's a duplicate of >>> e2a7c227dea5b361e2ebdbba24b923d1922a79d0 which was pushed to >>> master. Same with this commit 28d14130953d868d4848540d9de8e1ae4a01a467, >>> which is different to f29f80c194d0c534a92354b2bc19022a9b70ecf8 on >>> master. >> >> I've worked out at least when these two werid commits turned up on >> core-updates. >> >> 12b15585a7 is mentioned here: >> https://lists.gnu.org/archive/html/guix-commits/2023-09/msg00955.html >> >> and 28d1413095 is mentioned here: >> https://lists.gnu.org/archive/html/guix-commits/2024-03/msg00381.html >> >> >> With the changes last month in March, I was going to suggest deleting >> the branch and then re-creating from f205179ed2 and trying to re-apply >> the changes that should be on core-updates, while avoiding any >> "duplicate" commits. However, I'm not even sure where to being with the >> ~5000 commits pushed in September, at least one of them is a duplicate >> of a commit on master, but I'm not sure how many of the other ~5000 are. >> >> For comparison, I did a merge of master in to core-updates today, and >> this is what it shows up like on guix-commits: >> >> https://lists.gnu.org/archive/html/guix-commits/2024-04/msg01209.html >> >> There are only two new revisions, the ed update I pushed, and the merge >> commit, which is what a merge should look like as far as I'm aware. > > I think probably what happened is that in the middle of a merge of > master -> core-updates (which entails sometimes painful conflicts > resolution), a new commit pushed to core-updates, and to be able to push > the resulting local branch (including the thousands of commits from the > merge commit) got rebased on the remote core-updates. > > Perhaps another merge commit appeared on the remote around the same > time, which would explain the duplicates. > > While I agree it's messy to have 5000 of duplicated commits, I'm not > sure attempting to rewrite the branch, which has seen a lot of original > commits, is a good idea (it'd be easy to have some good commits fall > into cracks, leading to lost of work). I think it's important to weigh up the cost and risks associated with either merging these commits, or somehow avoiding doing so. I think the potential impact is more than just a bit of messy Git history. Assuming we merge core-updates without doing anything about these duplicate commits, and taking the cwltool package as a semi-random example, if you do: git log -p gnu/packages/bioinformatics.scm You're going to see two commits for the update to 3.1.20240112164112, that's maybe confusing, but not a big issue I guess since they look the same, just different hashes. But say you're looking at the Git history because you want that specific version of cwltool and you're going to use guix time-machine or an inferior looking at that revision. Well, it's a lucky dip. If you pick the original master commit, you're in luck, you'll probably get substitutes for cwltool. But if you pick the other seemingly identical commit, you're effectively checking out core-updates as it was last month and the chance of substitutes is much less likely. I also can't really think how you'd work out which commit is best to use once core-updates is merged? The easiest way would probably be to check the signature, but that will only work most of the time. This isn't a new issue, it's already problematic for substitute availability to use intermediate commits (commits that weren't directly pointed to by master). But there are over 1000 packages who's versions are being changed on core-updates currently, or at least it looks like this because of the duplicate commits, and if I'm correct about how people are using the git history to find commits for specific versions of packages, then having these duplicates in the Git history for master forever more is going to catch people out for as long as those versions remain relevant. [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 987 bytes --] ^ permalink raw reply [flat|nested] 15+ messages in thread
* bug#70456: Request for merging "core-updates" branch 2024-04-20 18:08 ` Christopher Baines @ 2024-04-22 17:31 ` Maxim Cournoyer 0 siblings, 0 replies; 15+ messages in thread From: Maxim Cournoyer @ 2024-04-22 17:31 UTC (permalink / raw) To: Christopher Baines; +Cc: 70456, steve Hi Christopher, Christopher Baines <mail@cbaines.net> writes: [...] > Assuming we merge core-updates without doing anything about these > duplicate commits, and taking the cwltool package as a semi-random > example, if you do: > > git log -p gnu/packages/bioinformatics.scm I trust the 'newest' (appearing first in 'git log --grep='cwltool: Update') would yield the commit having substitutes? If so, the inconvenience is somewhat mitigated, as long as you know to use the newest of duplicated commits. -- Thanks, Maxim ^ permalink raw reply [flat|nested] 15+ messages in thread
* bug#70456: Request for merging "core-updates" branch 2024-04-18 14:56 bug#70456: Request for merging core-updates branch Steve George 2024-04-19 14:42 ` bug#70456: Request for merging "core-updates" branch Christopher Baines @ 2024-04-26 14:44 ` tumashu 2024-05-08 12:03 ` bug#70456: Process gnome-team before core-updates Christopher Baines ` (2 subsequent siblings) 4 siblings, 0 replies; 15+ messages in thread From: tumashu @ 2024-04-26 14:44 UTC (permalink / raw) To: 70456 [-- Attachment #1: Type: text/plain, Size: 315 bytes --] emacs has a script gitmerge.el, it can skip some commit when merge with different merge rule (ours), maybe can make life easier: https://git.savannah.gnu.org/cgit/emacs.git/tree/admin/gitmerge.el https://git.savannah.gnu.org/cgit/emacs.git/tree/admin/notes/git-workflow -- 发自我的网易邮箱手机智能版 [-- Attachment #2: Type: text/html, Size: 436 bytes --] ^ permalink raw reply [flat|nested] 15+ messages in thread
* bug#70456: Process gnome-team before core-updates 2024-04-18 14:56 bug#70456: Request for merging core-updates branch Steve George 2024-04-19 14:42 ` bug#70456: Request for merging "core-updates" branch Christopher Baines 2024-04-26 14:44 ` tumashu @ 2024-05-08 12:03 ` Christopher Baines 2024-06-14 6:30 ` bug#70456: Request for merging core-updates branch Lars-Dominik Braun 2024-06-18 2:14 ` bug#70456: core-updates failed package: time 宋文武 via Bug reports for GNU Guix 4 siblings, 0 replies; 15+ messages in thread From: Christopher Baines @ 2024-05-08 12:03 UTC (permalink / raw) To: control; +Cc: 70766, 70456 [-- Attachment #1: Type: text/plain, Size: 309 bytes --] block 70456 by 70766 thanks I think being able to merge core-updates is still a few weeks away, so I think there's time to build and merge gnome-team without delaying core-updates. If it does become a problem, we can always switch approach and wait until after core-updates is merged to look at gnome-team. [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 987 bytes --] ^ permalink raw reply [flat|nested] 15+ messages in thread
* bug#70456: Request for merging core-updates branch 2024-04-18 14:56 bug#70456: Request for merging core-updates branch Steve George ` (2 preceding siblings ...) 2024-05-08 12:03 ` bug#70456: Process gnome-team before core-updates Christopher Baines @ 2024-06-14 6:30 ` Lars-Dominik Braun 2024-06-14 7:55 ` Guillaume Le Vaillant 2024-06-18 2:14 ` bug#70456: core-updates failed package: time 宋文武 via Bug reports for GNU Guix 4 siblings, 1 reply; 15+ messages in thread From: Lars-Dominik Braun @ 2024-06-14 6:30 UTC (permalink / raw) To: Steve George; +Cc: ludo, mail, 70456, maxim.cournoyer, efraim Hi, it seems the core-updates branch is first in the merge-queue. haskell-team was successfully built by the CI and is ready to be merged. Since there does not seem to be an ETA for core-updates, can I skip the queue and go ahead with merging haskell-team? Lars ^ permalink raw reply [flat|nested] 15+ messages in thread
* bug#70456: Request for merging core-updates branch 2024-06-14 6:30 ` bug#70456: Request for merging core-updates branch Lars-Dominik Braun @ 2024-06-14 7:55 ` Guillaume Le Vaillant 2024-06-17 19:53 ` Maxim Cournoyer 0 siblings, 1 reply; 15+ messages in thread From: Guillaume Le Vaillant @ 2024-06-14 7:55 UTC (permalink / raw) To: Lars-Dominik Braun Cc: Steve George, maxim.cournoyer, ludo, mail, efraim, 70456 [-- Attachment #1: Type: text/plain, Size: 396 bytes --] Lars-Dominik Braun <lars@6xq.net> skribis: > Hi, > > it seems the core-updates branch is first in the merge-queue. haskell-team > was successfully built by the CI and is ready to be merged. Since there > does not seem to be an ETA for core-updates, can I skip the queue and > go ahead with merging haskell-team? > > Lars Hi. The lisp-team branch is also in a good shape and ready to be merged. [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 247 bytes --] ^ permalink raw reply [flat|nested] 15+ messages in thread
* bug#70456: Request for merging core-updates branch 2024-06-14 7:55 ` Guillaume Le Vaillant @ 2024-06-17 19:53 ` Maxim Cournoyer 2024-06-17 20:19 ` Guillaume Le Vaillant 0 siblings, 1 reply; 15+ messages in thread From: Maxim Cournoyer @ 2024-06-17 19:53 UTC (permalink / raw) To: Guillaume Le Vaillant Cc: Steve George, ludo, mail, Lars-Dominik Braun, efraim, 70456 Hi, Guillaume Le Vaillant <glv@posteo.net> writes: > Lars-Dominik Braun <lars@6xq.net> skribis: > >> Hi, >> >> it seems the core-updates branch is first in the merge-queue. haskell-team >> was successfully built by the CI and is ready to be merged. Since there >> does not seem to be an ETA for core-updates, can I skip the queue and >> go ahead with merging haskell-team? >> >> Lars > > Hi. > The lisp-team branch is also in a good shape and ready to be merged. I think it's fine to merge these first; perhaps the core-updates merge request should be removed if it was preposterous (usually we issue the merge request when we are confident the branch is ready to me merged). -- Thanks, Maxim ^ permalink raw reply [flat|nested] 15+ messages in thread
* bug#70456: Request for merging core-updates branch 2024-06-17 19:53 ` Maxim Cournoyer @ 2024-06-17 20:19 ` Guillaume Le Vaillant 2024-06-18 12:15 ` Maxim Cournoyer 0 siblings, 1 reply; 15+ messages in thread From: Guillaume Le Vaillant @ 2024-06-17 20:19 UTC (permalink / raw) To: Maxim Cournoyer Cc: Steve George, ludo, mail, Lars-Dominik Braun, efraim, 70456 [-- Attachment #1: Type: text/plain, Size: 1080 bytes --] Maxim Cournoyer <maxim.cournoyer@gmail.com> skribis: > Hi, > > Guillaume Le Vaillant <glv@posteo.net> writes: > >> Lars-Dominik Braun <lars@6xq.net> skribis: >> >>> Hi, >>> >>> it seems the core-updates branch is first in the merge-queue. haskell-team >>> was successfully built by the CI and is ready to be merged. Since there >>> does not seem to be an ETA for core-updates, can I skip the queue and >>> go ahead with merging haskell-team? >>> >>> Lars >> >> Hi. >> The lisp-team branch is also in a good shape and ready to be merged. > > I think it's fine to merge these first; perhaps the core-updates merge > request should be removed if it was preposterous (usually we issue the > merge request when we are confident the branch is ready to me merged). Hi. It might be more logical to have two steps. First a "work started on xyz-team branch" message to indicate to the QA to make the stats for this branch, and then the "request for merging xyz-team branch" message to put the branch in the merge queue. I'll try to merge the lisp-team branch tomorrow (UTC+2 timezone). [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 247 bytes --] ^ permalink raw reply [flat|nested] 15+ messages in thread
* bug#70456: Request for merging core-updates branch 2024-06-17 20:19 ` Guillaume Le Vaillant @ 2024-06-18 12:15 ` Maxim Cournoyer 0 siblings, 0 replies; 15+ messages in thread From: Maxim Cournoyer @ 2024-06-18 12:15 UTC (permalink / raw) To: Guillaume Le Vaillant Cc: Steve George, ludo, mail, Lars-Dominik Braun, efraim, 70456 Hi, Guillaume Le Vaillant <glv@posteo.net> writes: > Maxim Cournoyer <maxim.cournoyer@gmail.com> skribis: > >> Hi, >> >> Guillaume Le Vaillant <glv@posteo.net> writes: >> >>> Lars-Dominik Braun <lars@6xq.net> skribis: >>> >>>> Hi, >>>> >>>> it seems the core-updates branch is first in the merge-queue. haskell-team >>>> was successfully built by the CI and is ready to be merged. Since there >>>> does not seem to be an ETA for core-updates, can I skip the queue and >>>> go ahead with merging haskell-team? >>>> >>>> Lars >>> >>> Hi. >>> The lisp-team branch is also in a good shape and ready to be merged. >> >> I think it's fine to merge these first; perhaps the core-updates merge >> request should be removed if it was preposterous (usually we issue the >> merge request when we are confident the branch is ready to me merged). > > Hi. > > It might be more logical to have two steps. First a "work started on > xyz-team branch" message to indicate to the QA to make the stats for > this branch, and then the "request for merging xyz-team branch" message > to put the branch in the merge queue. That'd be neat. Some other flow/UI idea: From the QA interface, have a "Request to build" button action attached to a branch. If the branch could be built successfully (with all checks OK), enable a "Request to merge" button, that could send an email with the patches to review to guix-patches. -- Thanks, Maxim ^ permalink raw reply [flat|nested] 15+ messages in thread
* bug#70456: core-updates failed package: time 2024-04-18 14:56 bug#70456: Request for merging core-updates branch Steve George ` (3 preceding siblings ...) 2024-06-14 6:30 ` bug#70456: Request for merging core-updates branch Lars-Dominik Braun @ 2024-06-18 2:14 ` 宋文武 via Bug reports for GNU Guix 2024-06-18 7:49 ` bug#70456: core-updates failed package: libfaketime for i686-linux 宋文武 via Bug reports for GNU Guix 4 siblings, 1 reply; 15+ messages in thread From: 宋文武 via Bug reports for GNU Guix @ 2024-06-18 2:14 UTC (permalink / raw) To: 70456 time-1.9 fail its test on core-updates: https://ci.guix.gnu.org/build/4587082/log/raw time(1) failed to detect 5MB allcoation. mem-baseline(kb): 768 mem-5MB(kb): 5720 delta(kb): 4952 FAIL tests/time-max-rss.sh (exit status: 1) delta is 4952, but it expect 5000-6000. No idea what's the reason, maybe skip it? ^ permalink raw reply [flat|nested] 15+ messages in thread
* bug#70456: core-updates failed package: libfaketime for i686-linux 2024-06-18 2:14 ` bug#70456: core-updates failed package: time 宋文武 via Bug reports for GNU Guix @ 2024-06-18 7:49 ` 宋文武 via Bug reports for GNU Guix 0 siblings, 0 replies; 15+ messages in thread From: 宋文武 via Bug reports for GNU Guix @ 2024-06-18 7:49 UTC (permalink / raw) To: 70456 宋文武 <iyzsong@envs.net> writes: libfaketime (dependency of nss, poppler, cairo) failed for i686-linux https://ci.guix.gnu.org/build/4555668/log/raw out=1717606732 (secs since Epoch) expected=1 - bad out=1717606732 (secs since Epoch) expected=2 - bad out=1717606732 (secs since Epoch) expected=4 - bad that mean FAKETIME=1 date doesn't report 1, but 1717606732. I think that due to libfaketime doesn't work with _TIME_BITS=64 on 32bit systems. Maybe this issue https://github.com/wolfcw/libfaketime/issues/418. I have no idea how to fix this, help need! ^ permalink raw reply [flat|nested] 15+ messages in thread
end of thread, other threads:[~2024-06-18 12:17 UTC | newest] Thread overview: 15+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2024-04-18 14:56 bug#70456: Request for merging core-updates branch Steve George 2024-04-19 14:42 ` bug#70456: Request for merging "core-updates" branch Christopher Baines 2024-04-19 17:00 ` Christopher Baines 2024-04-20 16:16 ` Maxim Cournoyer 2024-04-20 18:08 ` Christopher Baines 2024-04-22 17:31 ` Maxim Cournoyer 2024-04-26 14:44 ` tumashu 2024-05-08 12:03 ` bug#70456: Process gnome-team before core-updates Christopher Baines 2024-06-14 6:30 ` bug#70456: Request for merging core-updates branch Lars-Dominik Braun 2024-06-14 7:55 ` Guillaume Le Vaillant 2024-06-17 19:53 ` Maxim Cournoyer 2024-06-17 20:19 ` Guillaume Le Vaillant 2024-06-18 12:15 ` Maxim Cournoyer 2024-06-18 2:14 ` bug#70456: core-updates failed package: time 宋文武 via Bug reports for GNU Guix 2024-06-18 7:49 ` bug#70456: core-updates failed package: libfaketime for i686-linux 宋文武 via Bug reports for GNU Guix
Code repositories for project(s) associated with this external index https://git.savannah.gnu.org/cgit/guix.git This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.