GNU bug report logs -
#76899
Request for merging "c++-team" branch
Previous Next
To reply to this bug, email your comments to 76899 AT debbugs.gnu.org.
Toggle the display of automated, internal messages from the tracker.
Report forwarded
to
guix-patches <at> gnu.org
:
bug#76899
; Package
guix-patches
.
(Sun, 09 Mar 2025 21:11:02 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
Greg Hogan <code <at> greghogan.com>
:
New bug report received and forwarded. Copy sent to
guix-patches <at> gnu.org
.
(Sun, 09 Mar 2025 21:11:02 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
The branch includes the following patches:
#70031 Use CMake in build-system/cmake.
#76151 gnu: jsoncpp: Update to 1.9.6.
More details are in the introduction to #70031, but in short
cmake is updated to 3.30.8 from 3.25.1
cmake-bootstrap is updated to 3.30.8 from 3.24.2
jsoncpp is updated to 1.9.6 from 1.9.5, dependents reduced to 180 from 24,642
Greg
Information forwarded
to
guix-patches <at> gnu.org
:
bug#76899
; Package
guix-patches
.
(Wed, 14 May 2025 10:25:02 GMT)
Full text and
rfc822 format available.
Message #8 received at 76899 <at> debbugs.gnu.org (full text, mbox):
Hello Greg,
I tried to rebase the branch on master, but got a merge conflict in
inkscape. Could you maybe have a look?
Andreas
Information forwarded
to
guix-patches <at> gnu.org
:
bug#76899
; Package
guix-patches
.
(Wed, 14 May 2025 20:35:02 GMT)
Full text and
rfc822 format available.
Message #11 received at 76899 <at> debbugs.gnu.org (full text, mbox):
On Wed, May 14, 2025 at 6:24 AM Andreas Enge <andreas <at> enge.fr> wrote:
>
> Hello Greg,
>
> I tried to rebase the branch on master, but got a merge conflict in
> inkscape. Could you maybe have a look?
>
> Andreas
I was able to push but had to delete the branch first. Not sure why
the following was failing (I had fetched upstream).
Are you able to create a c++-team specification on CI? I have waited
on this until getting this branch as clean as I can locally, which
happened just now, and why I had not pushed an updated branch, or a
new patchset on #70031. I am hoping that Codeberg is an improvement
over blasting the mailing list with many-part updates.
Greg
--8<---------------cut here---------------start------------->8---
$ git push -f upstream c++-team
guix git: successfully authenticated commit
315aeb0fc3edb7dcd071cf9737ec908666f0d995
Compiling Scheme modules...
Compiling Scheme modules...
Compiling Scheme modules...
Compiling Scheme modules...
Compiling Scheme modules...
Compiling Scheme modules...
Compiling Scheme modules...
Compiling Scheme modules...
All 132 channel news entries are valid.
Enumerating objects: 494, done.
Counting objects: 100% (494/494), done.
Delta compression using up to 4 threads
Compressing objects: 100% (376/376), done.
Writing objects: 100% (376/376), 126.26 KiB | 66.00 KiB/s, done.
Total 376 (delta 330), reused 0 (delta 0), pack-reused 0 (from 0)
remote: Resolving deltas: 100% (330/330), completed with 118 local objects.
remote: error: denying non-fast-forward refs/heads/c++-team (you
should pull first)
To git.savannah.gnu.org:/srv/git/guix.git
! [remote rejected] c++-team -> c++-team (non-fast-forward)
error: failed to push some refs to 'git.savannah.gnu.org:/srv/git/guix.git'
--8<---------------cut here---------------end--------------->8---
Information forwarded
to
guix-patches <at> gnu.org
:
bug#76899
; Package
guix-patches
.
(Thu, 15 May 2025 11:21:02 GMT)
Full text and
rfc822 format available.
Message #14 received at 76899 <at> debbugs.gnu.org (full text, mbox):
Hello,
Am Wed, May 14, 2025 at 04:34:17PM -0400 schrieb Greg Hogan:
> I was able to push but had to delete the branch first. Not sure why
> the following was failing (I had fetched upstream).
this is how the server is set up: One can only push fast forward merges,
and not force push.
> Are you able to create a c++-team specification on CI?
Done, see here:
https://ci.guix.gnu.org/jobset/c%2B%2B-team
Andreas
Information forwarded
to
guix-patches <at> gnu.org
:
bug#76899
; Package
guix-patches
.
(Tue, 27 May 2025 08:10:02 GMT)
Full text and
rfc822 format available.
Message #17 received at 76899 <at> debbugs.gnu.org (full text, mbox):
Hello,
I have rebased once again, on dd5cb574b53337620c31dcc6cd727eabc6a09a48,
and pushed.
Hopefully this will be picked up by the data service soon.
Andreas
Information forwarded
to
guix-patches <at> gnu.org
:
bug#76899
; Package
guix-patches
.
(Wed, 28 May 2025 10:40:04 GMT)
Full text and
rfc822 format available.
Message #20 received at 76899 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Andreas Enge <andreas <at> enge.fr> writes:
> I have rebased once again, on dd5cb574b53337620c31dcc6cd727eabc6a09a48,
> and pushed.
>
> Hopefully this will be picked up by the data service soon.
I was looking at why the data service was so slow at processing this
branch, and I think it was mostly due to [1] "build-system/gnu: Limit
load average.".
1: https://codeberg.org/guix/guix/commit/dd2ebc733add21f9b40d0df5b7a8337c5beb8e72
Turns out that this change is also on the core-packages-team branch,
which is amore appropriate place, so I've rebased removing this commit.
I'd recommend running guix weather on branches like this since by
computing all the derivations you might find some problems, and it'll
give a sense of how many packages are affected by the changes.
[signature.asc (application/pgp-signature, inline)]
Added indication that bug 76899 blocks75518
Request was from
Andreas Enge <andreas <at> enge.fr>
to
control <at> debbugs.gnu.org
.
(Sun, 01 Jun 2025 09:32:02 GMT)
Full text and
rfc822 format available.
Information forwarded
to
guix-patches <at> gnu.org
:
bug#76899
; Package
guix-patches
.
(Tue, 03 Jun 2025 10:37:01 GMT)
Full text and
rfc822 format available.
Message #25 received at 76899 <at> debbugs.gnu.org (full text, mbox):
Hello,
the branch has a few build failures, including important packages such
as llvm:
https://qa.guix.gnu.org/branch/c++-team/package-changes?x86_64-linux-change=broken&x86_64-linux-change=still-failing&x86_64-linux-change=unknown-to-failing&x86_64-linux-change=new-failing
Could you have a look, Greg?
Andreas
Added blocking bug(s) 77340
Request was from
Andreas Enge <andreas <at> enge.fr>
to
control <at> debbugs.gnu.org
.
(Thu, 05 Jun 2025 08:32:02 GMT)
Full text and
rfc822 format available.
Information forwarded
to
guix-patches <at> gnu.org
:
bug#76899
; Package
guix-patches
.
(Thu, 05 Jun 2025 08:45:02 GMT)
Full text and
rfc822 format available.
Message #30 received at 76899 <at> debbugs.gnu.org (full text, mbox):
Hello,
while waiting for the c++-team branch to be fixed, I have passed the
mesa-updates branch to the front after rebasing it on commit
027a47787f8dcf6651a1c20c5b475376defe6d6b .
Please keep observing it and merge it when it is ready.
I am not sure if QA is currently keeping up with the branches, but it
is also evaluated by CI at
https://ci.guix.gnu.org/jobset/mesa-updates
Thanks,
Andreas
Information forwarded
to
guix-patches <at> gnu.org
:
bug#76899
; Package
guix-patches
.
(Sun, 08 Jun 2025 19:55:01 GMT)
Full text and
rfc822 format available.
Message #33 received at 76899 <at> debbugs.gnu.org (full text, mbox):
Hi Andreas et al.
On Thu, Jun 05, 2025 at 10:43 AM, Andreas Enge wrote:
> Hello,
>
> while waiting for the c++-team branch to be fixed, I have passed the
> mesa-updates branch to the front after rebasing it on commit
> 027a47787f8dcf6651a1c20c5b475376defe6d6b .
>
Thanks! I just rebased on 199fd26ab268d4f26cebcb39e844fe4ff9bea9bc (had
a checkmark on data services) and pushed another mesa update as they had
an emergency bugfix release (issue with latest AMD cards).
Prior to that the coverage on QA was about the same as master.
> Please keep observing it and merge it when it is ready.
>
So I can go ahead and merge this after this update builds then?
> I am not sure if QA is currently keeping up with the branches, but it
> is also evaluated by CI at
> https://ci.guix.gnu.org/jobset/mesa-updates
>
Yup, I've been keeping an eye on there whenever I'm working on this
branch, at least to see x86/x86_64 builds (always need to wait for
Bordeaux for others).
> Thanks,
>
> Andreas
A thanks for helping manage the branches!
John
Information forwarded
to
guix-patches <at> gnu.org
:
bug#76899
; Package
guix-patches
.
(Mon, 09 Jun 2025 14:44:02 GMT)
Full text and
rfc822 format available.
Message #36 received at 76899 <at> debbugs.gnu.org (full text, mbox):
Hello,
Am Sun, Jun 08, 2025 at 07:53:41PM +0000 schrieb John Kehayias:
> So I can go ahead and merge this after this update builds then?
yes, please do, close the bug and delete the branch (and keep us in cc).
This is assuming all goes well :)
There seem to be problems with CI as you reported, and the previous
evaluation had lots of failing packages, but they looked rather spurious
than real failures.
On QA, it has taken a while until the mesa-updates branch went to the
front, although I had given "block" instructions to debbugs - maybe
Chris had to change some code to take multiple blocks into account?
No, apparently blocking is not transitive - I see he has added an
explicit block yesterday.
So QA is working full-speed on the branch.
There are a few failing packages:
https://qa.guix.gnu.org/branch/mesa-updates/package-changes?x86_64-linux-change=broken&x86_64-linux-change=still-failing&x86_64-linux-change=unknown-to-failing&x86_64-linux-change=new-failing
I will let you judge whether these are more than random failures,
and if they are related to mesa, whether they should be repaired on
the branch or whether this can wait until master.
Thanks,
Andreas
Information forwarded
to
guix-patches <at> gnu.org
:
bug#76899
; Package
guix-patches
.
(Wed, 11 Jun 2025 22:42:01 GMT)
Full text and
rfc822 format available.
Message #39 received at 76899 <at> debbugs.gnu.org (full text, mbox):
Hi Andreas et al,
On Mon, Jun 09, 2025 at 04:43 PM, Andreas Enge wrote:
> Hello,
>
> Am Sun, Jun 08, 2025 at 07:53:41PM +0000 schrieb John Kehayias:
>> So I can go ahead and merge this after this update builds then?
>
> yes, please do, close the bug and delete the branch (and keep us in cc).
> This is assuming all goes well :)
> There seem to be problems with CI as you reported, and the previous
> evaluation had lots of failing packages, but they looked rather spurious
> than real failures.
>
I've gone ahead and merged mesa-updates after Efraim (added to CC) made
some fixes for riscv64-linux (though this isn't set to build on
QA/mesa-updates so substitutes will only build now on Berlin/master).
I'll be keeping an eye for any failures or reports of trouble, hopefully
just some random leaf packages at most.
> On QA, it has taken a while until the mesa-updates branch went to the
> front, although I had given "block" instructions to debbugs - maybe
> Chris had to change some code to take multiple blocks into account?
> No, apparently blocking is not transitive - I see he has added an
> explicit block yesterday.
>
> So QA is working full-speed on the branch.
> There are a few failing packages:
> https://qa.guix.gnu.org/branch/mesa-updates/package-changes?x86_64-linux-change=broken&x86_64-linux-change=still-failing&x86_64-linux-change=unknown-to-failing&x86_64-linux-change=new-failing
> I will let you judge whether these are more than random failures,
> and if they are related to mesa, whether they should be repaired on
> the branch or whether this can wait until master.
>
It has been hard to investigate failures directly from the Berlin CI
jobset due to webfront end/build processing issues where. I had reports
of at least one user on IRC that has used the branch fine on their
machine, and I've checked my own manifests as well. Usually (hopefully
not famous last words!) there isn't much happening, but it would be good
to have people with different hardware in the future to test pre-merge,
especially older hardware.
I didn't spot anything that looked critical or necessarily related to
these changes, but I'll be sure to be available for any fixes. Overall
substitute coverage was about the same as master in the last few days so
I don't anticipate much action, hopefully.
> Thanks,
>
> Andreas
Thanks for helping coordinate!
I really better create a mesa/graphics team and get this on a regular
schedule. It is a pretty straightforward branch and packages when doing
it a regular pace to keep relatively up to date with upstream.
John
Information forwarded
to
guix-patches <at> gnu.org
:
bug#76899
; Package
guix-patches
.
(Thu, 12 Jun 2025 08:40:02 GMT)
Full text and
rfc822 format available.
Message #42 received at 76899 <at> debbugs.gnu.org (full text, mbox):
Hello John,
thanks for pushing this through (figuratively and literally ;-))!
Am Wed, Jun 11, 2025 at 10:41:44PM +0000 schrieb John Kehayias:
> I've gone ahead and merged mesa-updates after Efraim (added to CC) made
> some fixes for riscv64-linux (though this isn't set to build on
> QA/mesa-updates so substitutes will only build now on Berlin/master).
I have also deleted the mesa-updates branch. This follows our policy and
avoids us ending up with old branches of which we have forgotten whether
they are work in progress or already merged. Please feel free to branch off
from master again at any time.
Packages for riscv64 are also built on the bordeaux build farm, with a
decent coverage:
https://qa.guix.gnu.org/branch/master
Cheers,
Andreas
Added blocking bug(s) 78527
Request was from
Andreas Enge <andreas <at> enge.fr>
to
control <at> debbugs.gnu.org
.
(Thu, 12 Jun 2025 09:27:02 GMT)
Full text and
rfc822 format available.
Removed indication that bug 76899 blocks
Request was from
Andreas Enge <andreas <at> enge.fr>
to
control <at> debbugs.gnu.org
.
(Thu, 12 Jun 2025 09:27:02 GMT)
Full text and
rfc822 format available.
Information forwarded
to
guix-patches <at> gnu.org
:
bug#76899
; Package
guix-patches
.
(Thu, 12 Jun 2025 09:56:02 GMT)
Full text and
rfc822 format available.
Message #49 received at 76899 <at> debbugs.gnu.org (full text, mbox):
Hello Greg,
I hope you are doing well, it is a bit worrying not to have heard back
from you since this branch started to be evaluated about a month ago.
I tried to rebase it, but there were a few merge conflicts, and I did
not feel able to decide which of the two versions, or maybe a
combination of them, should be retained.
For the time being, I let the emacs-team branch go to the front.
Please come back to us to see how this branch should be handled.
Andreas
Removed blocking bug(s) 77340
Request was from
Andreas Enge <andreas <at> enge.fr>
to
control <at> debbugs.gnu.org
.
(Fri, 13 Jun 2025 09:12:02 GMT)
Full text and
rfc822 format available.
Removed blocking bug(s) 78527
Request was from
Andreas Enge <andreas <at> enge.fr>
to
control <at> debbugs.gnu.org
.
(Fri, 13 Jun 2025 09:12:02 GMT)
Full text and
rfc822 format available.
Added blocking bug(s) 78257
Request was from
Andreas Enge <andreas <at> enge.fr>
to
control <at> debbugs.gnu.org
.
(Fri, 13 Jun 2025 09:12:02 GMT)
Full text and
rfc822 format available.
Removed blocking bug(s) 78257
Request was from
Andreas Enge <andreas <at> enge.fr>
to
control <at> debbugs.gnu.org
.
(Sun, 15 Jun 2025 16:22:05 GMT)
Full text and
rfc822 format available.
Added blocking bug(s) 78676
Request was from
Andreas Enge <andreas <at> enge.fr>
to
control <at> debbugs.gnu.org
.
(Sun, 15 Jun 2025 16:22:05 GMT)
Full text and
rfc822 format available.
Information forwarded
to
guix-patches <at> gnu.org
:
bug#76899
; Package
guix-patches
.
(Fri, 20 Jun 2025 17:37:01 GMT)
Full text and
rfc822 format available.
Message #62 received at 76899 <at> debbugs.gnu.org (full text, mbox):
On Thu, Jun 12, 2025 at 5:54 AM Andreas Enge <andreas <at> enge.fr> wrote:
>
> Hello Greg,
>
> I hope you are doing well, it is a bit worrying not to have heard back
> from you since this branch started to be evaluated about a month ago.
>
> I tried to rebase it, but there were a few merge conflicts, and I did
> not feel able to decide which of the two versions, or maybe a
> combination of them, should be retained.
No worries, just travelling with less access to the Internet than I
had hoped for.
> For the time being, I let the emacs-team branch go to the front.
>
> Please come back to us to see how this branch should be handled.
>
> Andreas
I have it rebased and bootstrapping locally. Still working to sort out
my Codeberg access to push the rebase there.
Any idea on how to access the build stats from QA
[https://qa.guix.gnu.org/branch/c++-team]? I have not closely followed
the issue with the unknown merge base revision, other than I believe
that rebasing on a different commit has solved the problem.
Greg
Information forwarded
to
guix-patches <at> gnu.org
:
bug#76899
; Package
guix-patches
.
(Fri, 20 Jun 2025 18:14:04 GMT)
Full text and
rfc822 format available.
Message #65 received at 76899 <at> debbugs.gnu.org (full text, mbox):
Am Fri, Jun 20, 2025 at 01:36:28PM -0400 schrieb Greg Hogan:
> No worries, just travelling with less access to the Internet than I
> had hoped for.
Good to hear that!
> I have it rebased and bootstrapping locally. Still working to sort out
> my Codeberg access to push the rebase there.
Hopefully this will be easy to sort out; people reported problems in the
past, but they have apparently been solved.
> Any idea on how to access the build stats from QA
> [https://qa.guix.gnu.org/branch/c++-team]? I have not closely followed
> the issue with the unknown merge base revision, other than I believe
> that rebasing on a different commit has solved the problem.
To solve the "unknown base revision" problem, you need to have a look at
https://data.qa.guix.gnu.org/
or more precisely
https://data.qa.guix.gnu.org/repository/1/branch/master
and choose a (well, the latest) commit with a green badge.
For the "unknown target revision", there is nothing to do but wait
until the data service has picked it up (it will show on
https://data.qa.guix.gnu.org/ again with a green badge).
Currently QA only looks at the first two branches, which currently are
ruby-team and core-packages team. So once ruby-team is merged, c++-team
should get into focus (but I may pause it once more until you have
managed to push the latest branch to master).
Andreas
Added blocking bug(s) 78689
Request was from
Andreas Enge <andreas <at> enge.fr>
to
control <at> debbugs.gnu.org
.
(Fri, 20 Jun 2025 21:02:02 GMT)
Full text and
rfc822 format available.
Information forwarded
to
guix-patches <at> gnu.org
:
bug#76899
; Package
guix-patches
.
(Sat, 21 Jun 2025 16:37:02 GMT)
Full text and
rfc822 format available.
Message #70 received at 76899 <at> debbugs.gnu.org (full text, mbox):
On Fri, Jun 20, 2025 at 2:13 PM Andreas Enge <andreas <at> enge.fr> wrote:
>
> Am Fri, Jun 20, 2025 at 01:36:28PM -0400 schrieb Greg Hogan:
> > No worries, just travelling with less access to the Internet than I
> > had hoped for.
>
> Good to hear that!
>
> > I have it rebased and bootstrapping locally. Still working to sort out
> > my Codeberg access to push the rebase there.
>
> Hopefully this will be easy to sort out; people reported problems in the
> past, but they have apparently been solved.
>
> > Any idea on how to access the build stats from QA
> > [https://qa.guix.gnu.org/branch/c++-team]? I have not closely followed
> > the issue with the unknown merge base revision, other than I believe
> > that rebasing on a different commit has solved the problem.
>
> To solve the "unknown base revision" problem, you need to have a look at
> https://data.qa.guix.gnu.org/
> or more precisely
> https://data.qa.guix.gnu.org/repository/1/branch/master
> and choose a (well, the latest) commit with a green badge.
>
> For the "unknown target revision", there is nothing to do but wait
> until the data service has picked it up (it will show on
> https://data.qa.guix.gnu.org/ again with a green badge).
>
> Currently QA only looks at the first two branches, which currently are
> ruby-team and core-packages team. So once ruby-team is merged, c++-team
> should get into focus (but I may pause it once more until you have
> managed to push the latest branch to master).
>
> Andreas
Thanks for all of your help. I have rebased a few times to try and get
a good build on CI [https://ci.guix.gnu.org/jobset/c%2B%2B-team], the
last being revision de9e1421 [
https://data.qa.guix.gnu.org/revision/de9e1421ae254ec94adbb45421b4690b5a20fc79].
It's unclear why CI would fail to build the Guix checkout if it is
compiling locally for me.
Greg
Information forwarded
to
guix-patches <at> gnu.org
:
bug#76899
; Package
guix-patches
.
(Sat, 21 Jun 2025 16:53:04 GMT)
Full text and
rfc822 format available.
Message #73 received at 76899 <at> debbugs.gnu.org (full text, mbox):
Am Sat, Jun 21, 2025 at 12:36:12PM -0400 schrieb Greg Hogan:
> It's unclear why CI would fail to build the Guix checkout if it is
> compiling locally for me.
I do not know, I do not usually work with cuirass or CI.
Someone mentioned a full disk on some of the nodes, maybe this is
related?
I had to take out my machines from the bordeaux build farm for a little
while, so this one will be degraded as well. And over the next few weeks
I might not be very present to follow up with branches.
I will let you sort things out between the branch captains :)
The nss-updates branch is discussed at
https://codeberg.org/guix/guix/pulls/400 ;
once it is merged and the branch and issue 78689 closed,
c++-team should automatically move one step to the front in QA and end
up within the two top branches, which are the evaluated branches.
Andreas
Information forwarded
to
guix-patches <at> gnu.org
:
bug#76899
; Package
guix-patches
.
(Fri, 18 Jul 2025 19:14:02 GMT)
Full text and
rfc822 format available.
Message #76 received at 76899 <at> debbugs.gnu.org (full text, mbox):
Hello all,
after the core-packages-team merge, your three branches are next in
line; could you maybe rebase them on master (a commit after
4d8c55de60cf9a5cafc4b881035131921d07314d, preferably one known to the
QA data service as shown here:
https://data.qa.guix.gnu.org/repository/1/branch/master
The qt-team branch was closed for a while, since it required the
core-packages-team branch to be merged; to repair breakage in the
latter, we actually moved some of its commits already, so part of the
branch is already applied. If you are ready, you can reopen the bug,
and qt-team will go to the front.
The nss-updates and c++-team branches come in a certain order right now,
but this needs not be fixed. Depending on how well QA and CI work,
respectively, it might also be an option to have them built by CI
instead. In theory, they should just work and just need to be built for
getting substitutes, but who knows!
As for qt-team, you may also update your updates to latest releases and
force-push the branches.
Andreas
Removed blocking bug(s) 77340
Request was from
Andreas Enge <andreas <at> enge.fr>
to
control <at> debbugs.gnu.org
.
(Sat, 19 Jul 2025 07:16:02 GMT)
Full text and
rfc822 format available.
Removed blocking bug(s) 78689
Request was from
Andreas Enge <andreas <at> enge.fr>
to
control <at> debbugs.gnu.org
.
(Sat, 19 Jul 2025 07:31:01 GMT)
Full text and
rfc822 format available.
Removed blocking bug(s) 78676
Request was from
Andreas Enge <andreas <at> enge.fr>
to
control <at> debbugs.gnu.org
.
(Sat, 19 Jul 2025 07:31:01 GMT)
Full text and
rfc822 format available.
Information forwarded
to
guix-patches <at> gnu.org
:
bug#76899
; Package
guix-patches
.
(Sat, 19 Jul 2025 12:20:02 GMT)
Full text and
rfc822 format available.
Message #85 received at 76899 <at> debbugs.gnu.org (full text, mbox):
Hi Andreas,
+CC Zheng
Andreas Enge <andreas <at> enge.fr> writes:
> Hello all,
>
> after the core-packages-team merge, your three branches are next in
> line; could you maybe rebase them on master (a commit after
> 4d8c55de60cf9a5cafc4b881035131921d07314d, preferably one known to the
> QA data service as shown here:
> https://data.qa.guix.gnu.org/repository/1/branch/master
>
> The qt-team branch was closed for a while, since it required the
> core-packages-team branch to be merged; to repair breakage in the
> latter, we actually moved some of its commits already, so part of the
> branch is already applied. If you are ready, you can reopen the bug,
> and qt-team will go to the front.
Which bug must be reopened? The merge request?
[...]
> As for qt-team, you may also update your updates to latest releases and
> force-push the branches.
I tried to rebase it, but there are lots of tricky conflicts to resolve
in KDE applications; I'll defer to Zheng, as they authored the changes
and probably know which variants are the most up to date/correct.
--
Thanks,
Maxim
Information forwarded
to
guix-patches <at> gnu.org
:
bug#76899
; Package
guix-patches
.
(Sat, 19 Jul 2025 20:10:02 GMT)
Full text and
rfc822 format available.
Message #88 received at 76899 <at> debbugs.gnu.org (full text, mbox):
On Fri, Jul 18, 2025 at 3:13 PM Andreas Enge <andreas <at> enge.fr> wrote:
>
> Hello all,
>
> after the core-packages-team merge, your three branches are next in
> line; could you maybe rebase them on master (a commit after
> 4d8c55de60cf9a5cafc4b881035131921d07314d, preferably one known to the
> QA data service as shown here:
> https://data.qa.guix.gnu.org/repository/1/branch/master
>
> The qt-team branch was closed for a while, since it required the
> core-packages-team branch to be merged; to repair breakage in the
> latter, we actually moved some of its commits already, so part of the
> branch is already applied. If you are ready, you can reopen the bug,
> and qt-team will go to the front.
>
> The nss-updates and c++-team branches come in a certain order right now,
> but this needs not be fixed. Depending on how well QA and CI work,
> respectively, it might also be an option to have them built by CI
> instead. In theory, they should just work and just need to be built for
> getting substitutes, but who knows!
> As for qt-team, you may also update your updates to latest releases and
> force-push the branches.
>
> Andreas
Sharlatan has been quicker on the draw, but I have also been rebasing
the c++-team branch and fixing the conflicts on
b22edc407e34848745106ce29040bbfa29aeeec3, which showed "Failed to
import data" rather than the usual "No information yet" and did not
appear to work, and now 9bff5e0ecb40fe3988ea8b33d679dedca03a7bdc shows
green.
Greg
Information forwarded
to
guix-patches <at> gnu.org
:
bug#76899
; Package
guix-patches
.
(Sat, 19 Jul 2025 20:29:01 GMT)
Full text and
rfc822 format available.
Message #91 received at 76899 <at> debbugs.gnu.org (full text, mbox):
Hello,
Am Sat, Jul 19, 2025 at 04:08:58PM -0400 schrieb Greg Hogan:
> Sharlatan has been quicker on the draw, but I have also been rebasing
> the c++-team branch and fixing the conflicts on
> b22edc407e34848745106ce29040bbfa29aeeec3, which showed "Failed to
> import data" rather than the usual "No information yet" and did not
> appear to work, and now 9bff5e0ecb40fe3988ea8b33d679dedca03a7bdc shows
> green.
impossible to compete with Sharlatan :)
But there seems to be some branch confusion.
9bff5e0ecb40fe3988ea8b33d679dedca03a7bdc is the first master branch
treated after the big merge by QA.
The C++ branch here is being treated right now:
https://data.qa.guix.gnu.org/revision/4550325654b35f6144af8fb8af33d350815e28b9
Ah, I see there is a new one:
https://data.qa.guix.gnu.org/revision/482862e466d28bc66dfa92bd393b57fb63a69cb1
So this is one you have rebased on 9bff5e0ecb40fe3988ea8b33d679dedca03a7bdc ?
Excellent, then we just have to continue waiting...
The c++-team branch is first in line, and I think nss-updates has not
yet been rebased.
Andreas
Information forwarded
to
guix-patches <at> gnu.org
:
bug#76899
; Package
guix-patches
.
(Sat, 19 Jul 2025 22:50:03 GMT)
Full text and
rfc822 format available.
Message #94 received at 76899 <at> debbugs.gnu.org (full text, mbox):
On Sat, Jul 19, 2025 at 4:28 PM Andreas Enge <andreas <at> enge.fr> wrote:
>
> So this is one you have rebased on 9bff5e0ecb40fe3988ea8b33d679dedca03a7bdc ?
Yes. One quick check is the source commit from the "View Git Branch"
link on the branch page (https://qa.guix.gnu.org/branch/c++-team):
https://codeberg.org/guix/guix/compare/9bff5e0ecb40fe3988ea8b33d679dedca03a7bdc...482862e466d28bc66dfa92bd393b57fb63a69cb1
Information forwarded
to
guix-patches <at> gnu.org
:
bug#76899
; Package
guix-patches
.
(Sun, 20 Jul 2025 17:28:02 GMT)
Full text and
rfc822 format available.
Message #97 received at 76899 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Hi,
Sorry if it's impatient, I've got some free time at evenings now =).
I was expecting core-packages-team be merged closer to the end of the
month ^.^
--
Oleg
[signature.asc (application/pgp-signature, inline)]
Information forwarded
to
guix-patches <at> gnu.org
:
bug#76899
; Package
guix-patches
.
(Mon, 21 Jul 2025 14:06:02 GMT)
Full text and
rfc822 format available.
Message #100 received at 76899 <at> debbugs.gnu.org (full text, mbox):
The c++-team is currently at the head of the queue at qa.guix.gnu.org
and displays the following message:
"Submitting builds for this branch suspended as master branch
substitute availability is low for: armhf-linux i686-linux"
and no builds have been attempted on the team branch.
Substitute availability on master is shown as 33.1% for armhf-linux
and 78.1% for i686-linux. I'm not noticing much improvement in those
numbers, but I can track this better now that I have recorded a point
in time.
This seems like a less than optimal behavior for the system to shut
down building on primary architectures for team branches when the
secondary architectures have large numbers of blocked builds,
presumably due to the recent core-packages-team merge.
Greg
Information forwarded
to
guix-patches <at> gnu.org
:
bug#76899
; Package
guix-patches
.
(Mon, 21 Jul 2025 14:53:02 GMT)
Full text and
rfc822 format available.
Message #103 received at 76899 <at> debbugs.gnu.org (full text, mbox):
Hello Greg,
Am Mon, Jul 21, 2025 at 10:05:14AM -0400 schrieb Greg Hogan:
> Substitute availability on master is shown as 33.1% for armhf-linux
> and 78.1% for i686-linux. I'm not noticing much improvement in those
> numbers, but I can track this better now that I have recorded a point
> in time.
>
> This seems like a less than optimal behavior for the system to shut
> down building on primary architectures for team branches when the
> secondary architectures have large numbers of blocked builds,
> presumably due to the recent core-packages-team merge.
indeed this is a problem! In particular now since I think the number
of buildable packages has gone below the limit of 80% on these two
architectures, so we will never reach this barrier. (I deduce this from
the numbers not going up.) However, on i686 I think we are on our way to
above 80% with all the recent changes on master.
I have submitted a PR here:
https://codeberg.org/guix/qa-frontpage/pulls/8
and am working on integrating and deploying it.
The qt-team branch has also reopened and gone to the front of the queue,
since it had been waiting longer and just been suspended while waiting
for core-packages-team, on which it depends, to let other branches go to
the front.
The c++-team branch has started on CI as well:
https://ci.guix.gnu.org/jobset/c++-team
but I am rather puzzled by the outcome.
The page itself shows an enormous number of failed packages in the red
box (almost all of them, plus some that are still in progress); when
clicking on the red box, I find packages such as ocaml that failed their
test phase with 0 failed tests. On the other hand, when clicking on the
dashboard (the monitor symbol to the right), almost all packages are
either green or transparent, and when one clicks on a transparent dot,
it shows the build as scheduled. But I know very little about CI.
All of qt-team, c++-team and nss-updates are accessible from CI as well,
so as soon as one of them is seen to be ready there, it can be pushed
to master.
Andreas
Information forwarded
to
guix-patches <at> gnu.org
:
bug#76899
; Package
guix-patches
.
(Mon, 21 Jul 2025 16:56:02 GMT)
Full text and
rfc822 format available.
Message #106 received at 76899 <at> debbugs.gnu.org (full text, mbox):
On Mon, Jul 21, 2025 at 10:52 AM Andreas Enge <andreas <at> enge.fr> wrote:
>
> The qt-team branch has also reopened and gone to the front of the queue,
> since it had been waiting longer and just been suspended while waiting
> for core-packages-team, on which it depends, to let other branches go to
> the front.
Yes, and likely a good thing since the qt-build-system inherits from
the cmake-build-system which is the focus of the c++-team branch.
The qt-team branch is rebased off the latest commit on master rather
than the latest processed commit so is showing the dreaded "Merge base
has not been processed by the data service yet".
> The c++-team branch has started on CI as well:
> https://ci.guix.gnu.org/jobset/c++-team
> but I am rather puzzled by the outcome.
> The page itself shows an enormous number of failed packages in the red
> box (almost all of them, plus some that are still in progress); when
> clicking on the red box, I find packages such as ocaml that failed their
> test phase with 0 failed tests. On the other hand, when clicking on the
> dashboard (the monitor symbol to the right), almost all packages are
> either green or transparent, and when one clicks on a transparent dot,
> it shows the build as scheduled. But I know very little about CI.
It is helpful that the ci dashboard can select for a single
architecture, but is there a way to compare against the merge base as
with qa? On master we are concerned with the state of all packages,
but on team branches is there any other question than to find the
newly failing packages relative to the base commit?
Greg
Information forwarded
to
guix-patches <at> gnu.org
:
bug#76899
; Package
guix-patches
.
(Mon, 21 Jul 2025 17:03:02 GMT)
Full text and
rfc822 format available.
Message #109 received at 76899 <at> debbugs.gnu.org (full text, mbox):
Am Mon, Jul 21, 2025 at 12:54:59PM -0400 schrieb Greg Hogan:
> The qt-team branch is rebased off the latest commit on master rather
> than the latest processed commit so is showing the dreaded "Merge base
> has not been processed by the data service yet".
Yes, but the latest commits on master are also Qt related, so we need
to wait and maybe rebase on the first commit that will have been
processed after that.
> It is helpful that the ci dashboard can select for a single
> architecture, but is there a way to compare against the merge base as
> with qa? On master we are concerned with the state of all packages,
> but on team branches is there any other question than to find the
> newly failing packages relative to the base commit?
I do not think so, I have the impression that it is always with respect
to the previous commit on the same branch.
Andreas
Information forwarded
to
guix-patches <at> gnu.org
:
bug#76899
; Package
guix-patches
.
(Fri, 25 Jul 2025 14:16:02 GMT)
Full text and
rfc822 format available.
Message #112 received at 76899 <at> debbugs.gnu.org (full text, mbox):
Hello,
this branch is now first in line.
Could you rebase it on master, possible a commit known (in an hour or two)
to data.qa.guix.gnu.org, or for the time being just commit
eb7fb3c59d8de06ef942dce55ceb9565917e7ddb
which is the merge of qt-team?
And maybe add the commit of https://codeberg.org/guix/guix/pulls/1569 on top.
Right now QA shows a lot of blocked packages:
https://qa.guix.gnu.org/branch/c++-team
And CI failed with this message, inside
https://ci.guix.gnu.org/eval/2073835/log/raw
(exception unbound-variable (value #f) (value "Unbound variable: ~S") (value (cmake-next)) (value #f))
builder for `/gnu/store/sfff5zisrfw5r5s8dw5gsdwm413jdkr7-guix-package-cache.drv' failed to produce output path `/gnu/store/5b2bcrf30gh2q3rpzinq6ri1sxb1lnp1-guix-package-cache'
cannot build derivation `/gnu/store/dzz0dd83pz4gx76rbhzp7zdz9b0x1354-profile.drv': 1 dependencies couldn't be built
I wonder if this indicates a problem with the branch, cmake-next is
definitely a package related to changes in this branch:
grep cmake-next gnu/packages/*.scm
gnu/packages/video.scm: #:cmake cmake-next ;needs cmake >= 3.28
gnu/packages/xdisorg.scm: #:cmake cmake-next
So I think this is a place where cmake-next used to be used, but
it does not exist anymore.
See this commit:
commit 83144c271c19af3a686a52c176fbb495f2c6d8dc
Author: Murilo <murilo <at> disroot.org>
Date: Tue Jul 22 14:53:44 2025 -0300
gnu: hyprsunset: Update to 0.3.0.
* gnu/packages/xdisorg.scm (hyprsunset): Update to 0.3.0.
[native-inputs]: Change gcc-14 to gcc-15.
[inputs]: Add hyprlang.
[arguments]{cmake}: Use cmake-next.
Signed-off-by: John Kehayias <john.kehayias <at> protonmail.com>
And this one:
commit 686cc8728ebe6b0572bebb31fb671f5fa0880cf2
Author: 宋文武 <iyzsong <at> envs.net>
Date: Mon Feb 10 13:05:44 2025 +0800
gnu: obs: Upduate to 31.0.1.
* gnu/packages/patches/obs-modules-location.patch: Adjust for 31.0.1.
* gnu/packages/video.scm (obs): Update to 31.0.1.
[inputs]: Add rnnoise and uthash.
[arguments]: Use cmake-next. Add "-DENABLE_NVENC=OFF" to configure-flags.
Set OBS_EXECUTABLE_RPATH, OBS_LIBRARY_RPATH and OBS_MODULE_RPATH.
Change-Id: Iaa8e7fceb04b3bf7e69cb0a040938ca90dfa46d0
Signed-off-by: Andreas Enge <andreas <at> enge.fr>
I think this is a place where textual git rebases do work, but are not
semantically correct; we will need a fixup to the commit that removes
cmake-next to handle these two packages.
Thanks,
Andreas
Information forwarded
to
guix-patches <at> gnu.org
:
bug#76899
; Package
guix-patches
.
(Fri, 25 Jul 2025 16:17:01 GMT)
Full text and
rfc822 format available.
Message #115 received at 76899 <at> debbugs.gnu.org (full text, mbox):
On Fri, Jul 25, 2025 at 10:15 AM Andreas Enge <andreas <at> enge.fr> wrote:
>
> Hello,
>
> this branch is now first in line.
> Could you rebase it on master, possible a commit known (in an hour or two)
> to data.qa.guix.gnu.org, or for the time being just commit
> eb7fb3c59d8de06ef942dce55ceb9565917e7ddb
> which is the merge of qt-team?
>
> And maybe add the commit of https://codeberg.org/guix/guix/pulls/1569 on top.
>
> Right now QA shows a lot of blocked packages:
> https://qa.guix.gnu.org/branch/c++-team
>
> And CI failed with this message, inside
> https://ci.guix.gnu.org/eval/2073835/log/raw
>
> (exception unbound-variable (value #f) (value "Unbound variable: ~S") (value (cmake-next)) (value #f))
> builder for `/gnu/store/sfff5zisrfw5r5s8dw5gsdwm413jdkr7-guix-package-cache.drv' failed to produce output path `/gnu/store/5b2bcrf30gh2q3rpzinq6ri1sxb1lnp1-guix-package-cache'
> cannot build derivation `/gnu/store/dzz0dd83pz4gx76rbhzp7zdz9b0x1354-profile.drv': 1 dependencies couldn't be built
>
> I wonder if this indicates a problem with the branch, cmake-next is
> definitely a package related to changes in this branch:
> grep cmake-next gnu/packages/*.scm
> gnu/packages/video.scm: #:cmake cmake-next ;needs cmake >= 3.28
> gnu/packages/xdisorg.scm: #:cmake cmake-next
> So I think this is a place where cmake-next used to be used, but
> it does not exist anymore.
>
> See this commit:
> commit 83144c271c19af3a686a52c176fbb495f2c6d8dc
> Author: Murilo <murilo <at> disroot.org>
> Date: Tue Jul 22 14:53:44 2025 -0300
>
> gnu: hyprsunset: Update to 0.3.0.
>
> * gnu/packages/xdisorg.scm (hyprsunset): Update to 0.3.0.
> [native-inputs]: Change gcc-14 to gcc-15.
> [inputs]: Add hyprlang.
> [arguments]{cmake}: Use cmake-next.
>
> Signed-off-by: John Kehayias <john.kehayias <at> protonmail.com>
>
> And this one:
> commit 686cc8728ebe6b0572bebb31fb671f5fa0880cf2
> Author: 宋文武 <iyzsong <at> envs.net>
> Date: Mon Feb 10 13:05:44 2025 +0800
>
> gnu: obs: Upduate to 31.0.1.
>
> * gnu/packages/patches/obs-modules-location.patch: Adjust for 31.0.1.
> * gnu/packages/video.scm (obs): Update to 31.0.1.
> [inputs]: Add rnnoise and uthash.
> [arguments]: Use cmake-next. Add "-DENABLE_NVENC=OFF" to configure-flags.
> Set OBS_EXECUTABLE_RPATH, OBS_LIBRARY_RPATH and OBS_MODULE_RPATH.
>
> Change-Id: Iaa8e7fceb04b3bf7e69cb0a040938ca90dfa46d0
> Signed-off-by: Andreas Enge <andreas <at> enge.fr>
>
> I think this is a place where textual git rebases do work, but are not
> semantically correct; we will need a fixup to the commit that removes
> cmake-next to handle these two packages.
>
> Thanks,
>
> Andreas
I have the branch ready to go (and did find the recent use of
cmake-next earlier today) when the data service gives the next
greenlight.
QA found a build failure in llvm <at> 3.5.2, so I am also locally testing
the following patch for a subtle bug lurking since 2020 (llvm is
currently aliased to llvm-13).
diff --git i/gnu/packages/llvm.scm w/gnu/packages/llvm.scm
index 087aa15f885..12a91c7579f 100644
--- i/gnu/packages/llvm.scm
+++ w/gnu/packages/llvm.scm
@@ -1352,7 +1352,7 @@ (define-public llvm-3.9.1
"1vi9sf7rx1q04wj479rsvxayb6z740iaz3qniwp266fgp5a07n8z"))))
(outputs '("out"))
(arguments
- (substitute-keyword-arguments (package-arguments llvm)
+ (substitute-keyword-arguments (package-arguments llvm-6)
((#:phases phases)
#~(modify-phases #$phases
(add-before 'build 'shared-lib-workaround
This bug report was last modified today.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.