Request for merging "c++-team" branch

>

> 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 rebased once again, on dd5cb574b53337620c31dcc6cd727eabc6a09a48,

> and pushed.

>

> Hopefully this will be picked up by the data service soon.

> 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

> So I can go ahead and merge this after this update builds then?

> 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

> 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).

>

> 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

> No worries, just travelling with less access to the Internet than I

> had hoped for.

> 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.

>

> 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

> It's unclear why CI would fail to build the Guix checkout if it is

> compiling locally for me.

> 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.

> As for qt-team, you may also update your updates to latest releases and

> force-push the branches.

>

> 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.

>

> So this is one you have rebased on 9bff5e0ecb40fe3988ea8b33d679dedca03a7bdc ?

> 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.

>

> 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.

> 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".

> 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?

>

> 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@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@protonmail.com>

>

> And this one:

> commit 686cc8728ebe6b0572bebb31fb671f5fa0880cf2

> Author: 宋文武 <iyzsong@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@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 restarted guix-data-service, then qa-frontpage, but this is

> already the result.

>

> To me, this looks like a bug in the data service, which only Chris

> should be able to debug...

>

> So CI remains as our only source of build results.

>

> Andreas

> 1) Can failed QA builds be restarted as with CI?

> I have a patch for libomemo which will be in the next rebase and push.

> 2) Can CI show the list of broken builds as with QA?

> $ ./pre-inst-env guix build icedtea@2.6 jsoncpp julia python-diskcache

> python-duckdb python-pybedtools

> /gnu/store/byqdnch9v28djx3gkd0ba3b6lqigiimw-icedtea-2.6.13-doc

> /gnu/store/qd4g7h2552nk5avnsa5b610x7f3ycdar-icedtea-2.6.13-jdk

> /gnu/store/ssb80nhgkbb1vaqddlcpm96a8jpvkkgp-icedtea-2.6.13

> /gnu/store/7haysh5icvla8rkbjjq1z58s6771fw3f-jsoncpp-1.9.6

> I have resubmitted it:

> https://bordeaux.guix.gnu.org/build/6bd00b9f-8ce5-4387-b005-32d2dc99fd0c

> Now julia is the main blocker.

>

> > 2) Can CI show the list of broken builds as with QA?

>

> Here

> https://qa.guix.gnu.org/branch/c++-team

> you can click on the failed builds (which you may have to repeat

> a few times in case of timeout).

>

> Am Mon, Jul 28, 2025 at 12:31:39PM +0200 schrieb Andreas Enge:

> > Now julia is the main blocker.

>

> On x86_64; on i686 it is llvm:

> /gnu/store/2awzss9mx0ndzyg69nz915wkj2xsjyr2-llvm-13.0.1.drv 2586

> /gnu/store/412slh6ynaa1q3104w54fwzbn7891c6k-llvm-18.1.8.drv 2572

> /gnu/store/rr0nnr99iic9kq8f10fjnsmrvk6zmfw4-llvm-for-mesa-18.1.8.drv 2562

>

> llvm-13 also fails on x86_64, I have not searched why it is less blocking.

>

> I am slowly building llvm-13+ on i686 and will then patch. On x86_64

> llvm-13 is not shown as broken.

> I have been using the following script to build locally any package

> which has failed on QA (on any of the three architectures). I have

> patches for all current failures (on x86-64, and I have tested llvm

> for i686) but I will wait to push as QA is returning 502 Bad Gateway

> (and the data service continues to build, and we can view failures,

> but not the overall status).

>

> sounds good, thanks for the progress report!

> QA Substitute availability shows 80% for bordeaux with 8,000

> failed/blocked/unknown packages, which would be 25% of ~32,000 total

> packages [0].

> CI is listed at 23% on x86-64 at priority 9 and is only building for

> x86_64-linux and i686-linux. What is the strategy here for team

> branches? I see other teams with only x86_64-linux and at the same

> lowest priority. Do we defer aarch64-linux to the post-rebase master

> specification? Should the priority be lowered for branches nearing

> completion?

>

> 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

>

> On Sun, Mar 9, 2025 at 5:10 PM Greg Hogan <code@greghogan.com> wrote:

> >

> > 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

>

> The c++-team branch has been applied to master.

>

> The following three leaf packages have broken builds but were only

> discovered by QA over the weekend and can be fixed on master.

> conan

> python-git-hammer

> optizelle

>

> On to the go team!

>

> Greg

>

> Hello,

>

> conforming to policy, I have deleted the c++-team branch. I suppose that

> the c++-libraries branch can be renamed to c++-team and a new request

> for merging can be filed?

>

> Andreas