Report forwarded
to guix-patches@gnu.org: bug#78689; Package guix-patches.
(Wed, 04 Jun 2025 02:22:03 GMT) (full text, mbox, link).
Acknowledgement sent
to Maxim Cournoyer <maxim.cournoyer@gmail.com>:
New bug report received and forwarded. Copy sent to guix-patches@gnu.org.
(Wed, 04 Jun 2025 02:22:03 GMT) (full text, mbox, link).
Added indication that bug 78689 blocks76899
Request was from Andreas Enge <andreas@enge.fr>
to control@debbugs.gnu.org.
(Fri, 20 Jun 2025 21:02:02 GMT) (full text, mbox, link).
Information forwarded
to guix-patches@gnu.org: bug#78689; Package guix-patches.
(Fri, 18 Jul 2025 19:14:02 GMT) (full text, mbox, link).
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 indication that bug 78689 blocks
Request was from Andreas Enge <andreas@enge.fr>
to control@debbugs.gnu.org.
(Sat, 19 Jul 2025 07:31:01 GMT) (full text, mbox, link).
Information forwarded
to guix-patches@gnu.org: bug#78689; Package guix-patches.
(Sat, 19 Jul 2025 12:20:02 GMT) (full text, mbox, link).
Hi Andreas,
+CC Zheng
Andreas Enge <andreas@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@gnu.org: bug#78689; Package guix-patches.
(Sat, 19 Jul 2025 20:10:03 GMT) (full text, mbox, link).
On Fri, Jul 18, 2025 at 3:13 PM Andreas Enge <andreas@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@gnu.org: bug#78689; Package guix-patches.
(Mon, 21 Jul 2025 14:06:03 GMT) (full text, mbox, link).
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@gnu.org: bug#78689; Package guix-patches.
(Mon, 21 Jul 2025 14:53:03 GMT) (full text, mbox, link).
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@gnu.org: bug#78689; Package guix-patches.
(Mon, 21 Jul 2025 16:56:03 GMT) (full text, mbox, link).
On Mon, Jul 21, 2025 at 10:52 AM Andreas Enge <andreas@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@gnu.org: bug#78689; Package guix-patches.
(Mon, 21 Jul 2025 17:03:03 GMT) (full text, mbox, link).
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@gnu.org: bug#78689; Package guix-patches.
(Fri, 25 Jul 2025 14:21:02 GMT) (full text, mbox, link).
Cc: Maxim Cournoyer <maxim@guixotic.coop>, Ian Eure <ian@retrospec.tv>
Subject: Re: Rebase required
Date: Mon, 4 Aug 2025 09:34:48 +0200
Hello,
the c++-team branch has been merged, so it will soon be your turn after
go-team. Could you please rebase? There has not been a rebase after the
core-packages-team and qt-team merges, so if I do not hear back, I will
close this issue.
Adding Ian in cc, since I see librewolf related commits in this branch
and they have authored the commit updating nss. This may have to be
updated again given the time that has passed since the branch was
created.
See also https://codeberg.org/guix/guix/pulls/400 .
Thanks,
Andreas
Information forwarded
to guix-patches@gnu.org: bug#78689; Package guix-patches.
(Wed, 06 Aug 2025 02:20:01 GMT) (full text, mbox, link).
Cc: Ian Eure <ian@retrospec.tv>, 78689@debbugs.gnu.org
Subject: Re: Rebase required
Date: Wed, 06 Aug 2025 11:19:22 +0900
Hi,
Andreas Enge <andreas@enge.fr> writes:
> Hello,
>
> the c++-team branch has been merged, so it will soon be your turn after
> go-team. Could you please rebase? There has not been a rebase after the
> core-packages-team and qt-team merges, so if I do not hear back, I will
> close this issue.
I rebased that nss-updates branch yesterday.
--
Thanks,
Maxim
Information forwarded
to guix-patches@gnu.org: bug#78689; Package guix-patches.
(Wed, 06 Aug 2025 07:39:02 GMT) (full text, mbox, link).
Cc: Ian Eure <ian@retrospec.tv>, 78689@debbugs.gnu.org
Subject: Re: Rebase required
Date: Wed, 6 Aug 2025 09:38:20 +0200
Am Wed, Aug 06, 2025 at 11:19:22AM +0900 schrieb Maxim Cournoyer:
> I rebased that nss-updates branch yesterday.
Great, thanks!
The go-team branch advances incredibly slowly; I think QA does not
submit jobs as it should, but only Chris can debug this. We will have
to discuss tooling after the summer, this is really holding us back,
even more so than lack of human power (which is also an issue).
Andreas
Information forwarded
to guix-patches@gnu.org: bug#78689; Package guix-patches.
(Wed, 06 Aug 2025 07:41:01 GMT) (full text, mbox, link).
Cc: Ian Eure <ian@retrospec.tv>, 78689@debbugs.gnu.org
Subject: Re: Rebase required
Date: Wed, 6 Aug 2025 09:39:56 +0200
Am Wed, Aug 06, 2025 at 09:38:20AM +0200 schrieb Andreas Enge:
> The go-team branch advances incredibly slowly; I think QA does not
> submit jobs as it should
Or we are stuck in the initial phase where the first go packages close
to the root of the changes are built one after the other, before
building fans out. Difficult to say!
Andreas
Information forwarded
to guix-patches@gnu.org: bug#78689; Package guix-patches.
(Thu, 07 Aug 2025 17:16:02 GMT) (full text, mbox, link).
Cc: Ian Eure <ian@retrospec.tv>, mail@cbaines.net, 78689@debbugs.gnu.org
Subject: Re: Rebase required
Date: Thu, 7 Aug 2025 19:15:27 +0200
Hello,
I thought I would try something new, and rebase the nss-updates branch
directly on the go-team branch. We are at least a few days from merging
the former, but in the end this should make the second branch in line
start faster, since it will already be evaluated on a commit known to
the data service, and which will be essentially the new state of master.
So the second branch should directly start with meaningful package builds.
I have rebased on 7ca1cb9db6c3e6c6ca8158a02275ef204957180d , the current
head of go-team. In case I made a thinko and we need the previous branch,
it is still available under the name of nss-updates-on master.
Andreas
Information forwarded
to guix-patches@gnu.org: bug#78689; Package guix-patches.
(Fri, 08 Aug 2025 02:25:02 GMT) (full text, mbox, link).
Cc: Ian Eure <ian@retrospec.tv>, mail@cbaines.net, 78689@debbugs.gnu.org
Subject: Re: Rebase required
Date: Fri, 08 Aug 2025 11:24:22 +0900
Hi,
Andreas Enge <andreas@enge.fr> writes:
> Hello,
>
> I thought I would try something new, and rebase the nss-updates branch
> directly on the go-team branch. We are at least a few days from merging
> the former, but in the end this should make the second branch in line
> start faster, since it will already be evaluated on a commit known to
> the data service, and which will be essentially the new state of master.
>
> So the second branch should directly start with meaningful package builds.
>
> I have rebased on 7ca1cb9db6c3e6c6ca8158a02275ef204957180d , the current
> head of go-team. In case I made a thinko and we need the previous branch,
> it is still available under the name of nss-updates-on master.
OK, sounds reasonable given the current difficulties with getting
branches built.
--
Thanks,
Maxim
Information forwarded
to guix-patches@gnu.org: bug#78689; Package guix-patches.
(Fri, 08 Aug 2025 07:51:02 GMT) (full text, mbox, link).
Cc: Ian Eure <ian@retrospec.tv>, mail@cbaines.net, 78689@debbugs.gnu.org
Subject: Re: Rebase required
Date: Fri, 8 Aug 2025 09:50:01 +0200
Hello,
actually it occurred to me that rebasing branch 2 directly on branch 1
could speed things up even more. Assuming that branch 2 has no problems,
but just needs to be built for substitutes, then while branch 1 is built
on QA, branch 2 will already be built on CI in parallel. So essentially,
we can merge the two at the same time. So we could piggy-back a branch
which should not break anything on a branch that may be a bit more risky.
CI has found a problem with nss-updates:
https://ci.guix.gnu.org/eval/2077455/log/raw\
(exception unbound-variable (value #f) (value "Unbound variable: ~S") (value (nss-certs-for-test)) (value #f))
I could reproduce it locally like this:
$ ./pre-inst-env guix package -A nss
Backtrace:
In ice-9/boot-9.scm:
1752:10 19 (with-exception-handler _ _ #:unwind? _ # _)
In unknown file:
18 (apply-smob/0 #<thunk 7f75647112a0>)
In ice-9/boot-9.scm:
724:2 17 (call-with-prompt _ _ #<procedure default-prompt-handle…>)
In ice-9/eval.scm:
619:8 16 (_ #(#(#<directory (guile-user) 7f7564716c80>)))
In guix/ui.scm:
2399:7 15 (run-guix . _)
2362:10 14 (run-guix-command _ . _)
In ice-9/boot-9.scm:
1752:10 13 (with-exception-handler _ _ #:unwind? _ # _)
In guix/scripts/package.scm:
850:26 12 (_)
In guix/discovery.scm:
188:3 11 (fold-module-public-variables _ _ _)
In guix/combinators.scm:
48:26 10 (fold2 #<procedure 7f7561a0c5a0 at guix/discovery.scm:…> …)
48:26 9 (fold2 #<procedure 7f753bf424a0 at guix/discovery.scm:…> …)
In guix/discovery.scm:
191:33 8 (_ #<package cobib@5.3.0 gnu/packages/textutils.scm:12…> …)
In gnu/packages.scm:
236:37 7 (_ #<package cobib@5.3.0 gnu/packages/textutils.scm:12…> …)
In guix/packages.scm:
1444:17 6 (supported-package? #<package cobib@5.3.0 gnu/packages…> …)
In guix/memoization.scm:
101:0 5 (_ #<hash-table 7f7561a2efa0 38833/56197> #<package co…> …)
In guix/packages.scm:
1422:39 4 (_)
1692:16 3 (package->bag _ _ _ #:graft? _)
1796:47 2 (thunk)
In gnu/packages/textutils.scm:
1325:11 1 (native-inputs #<package cobib@5.3.0 gnu/packages/textu…>)
In ice-9/boot-9.scm:
1685:16 0 (raise-exception _ #:continuable? _)
ice-9/boot-9.scm:1685:16: In procedure raise-exception:
error: nss-certs-for-test: unbound variable
Andreas
Information forwarded
to guix-patches@gnu.org: bug#78689; Package guix-patches.
(Sun, 10 Aug 2025 17:47:02 GMT) (full text, mbox, link).
Cc: Ian Eure <ian@retrospec.tv>, mail@cbaines.net, 78689@debbugs.gnu.org
Subject: Re: Rebase required
Date: Sun, 10 Aug 2025 19:46:13 +0200
Hello,
I am right now rebasing on go-team, commit
c92ca86e298fec4b4b025235f62254eec69f0bc4
We expect to merge go-team tomorrow.
Am Fri, Aug 08, 2025 at 09:50:01AM +0200 schrieb Andreas Enge:
> I could reproduce it locally like this:
> $ ./pre-inst-env guix package -A nss
> Backtrace:
> In ice-9/boot-9.scm:
> 1752:10 19 (with-exception-handler _ _ #:unwind? _ # _)
> ...
> ice-9/boot-9.scm:1685:16: In procedure raise-exception:
> error: nss-certs-for-test: unbound variable
So now it would be urgent to fix this, since otherwise I will let
another team go to the front.
Andreas
Information forwarded
to guix-patches@gnu.org: bug#78689; Package guix-patches.
(Sun, 10 Aug 2025 17:58:02 GMT) (full text, mbox, link).
Cc: Ian Eure <ian@retrospec.tv>, mail@cbaines.net, 78689@debbugs.gnu.org
Subject: Re: Rebase required
Date: Sun, 10 Aug 2025 19:57:33 +0200
Am Sun, Aug 10, 2025 at 07:46:13PM +0200 schrieb Andreas Enge:
> Am Fri, Aug 08, 2025 at 09:50:01AM +0200 schrieb Andreas Enge:
> > I could reproduce it locally like this:
> > $ ./pre-inst-env guix package -A nss
> > Backtrace:
> > In ice-9/boot-9.scm:
> > 1752:10 19 (with-exception-handler _ _ #:unwind? _ # _)
> > ...
> > ice-9/boot-9.scm:1685:16: In procedure raise-exception:
> > error: nss-certs-for-test: unbound variable
>
> So now it would be urgent to fix this, since otherwise I will let
> another team go to the front.
See my comment in IRC:
Actually this should be easy to fix. The problematic commit is c5227bbc8c60e4746151ffce5fd42a2a396811d2 , which does not adjust all the module imports. For instance, bioinformatics.scm imports certs, but does not now import nss.
Andreas
Information forwarded
to guix-patches@gnu.org: bug#78689; Package guix-patches.
(Sun, 10 Aug 2025 19:04:02 GMT) (full text, mbox, link).
Cc: Ian Eure <ian@retrospec.tv>, mail@cbaines.net, 78689@debbugs.gnu.org
Subject: Re: Rebase required
Date: Sun, 10 Aug 2025 21:03:26 +0200
Am Sun, Aug 10, 2025 at 07:57:33PM +0200 schrieb Andreas Enge:
> Actually this should be easy to fix. The problematic commit is c5227bbc8c60e4746151ffce5fd42a2a396811d2 , which does not adjust all the module imports. For instance, bioinformatics.scm imports certs, but does not now import nss.
With this it was easy. Commit amended and pushed.
Andreas
Information forwarded
to guix-patches@gnu.org: bug#78689; Package guix-patches.
(Mon, 11 Aug 2025 18:24:02 GMT) (full text, mbox, link).
Cc: Ian Eure <ian@retrospec.tv>, mail@cbaines.net, 78689@debbugs.gnu.org
Subject: Re: Rebase required
Date: Mon, 11 Aug 2025 20:23:39 +0200
Am Thu, Aug 07, 2025 at 07:15:27PM +0200 schrieb Andreas Enge:
> I thought I would try something new, and rebase the nss-updates branch
> directly on the go-team branch. We are at least a few days from merging
> the former, but in the end this should make the second branch in line
> start faster, since it will already be evaluated on a commit known to
> the data service, and which will be essentially the new state of master.
This part is working! I see the first nss-updates packages starting to
be built on QA (nss-3.101-4, nss-certs-for tests) while the last go-team
packages close to the leaves are being finished. Now normally the last
rebasing of go-team on master should not change the nss derivations, so
what is built now should be the packages that we eventually need.
> actually it occurred to me that rebasing branch 2 directly on branch 1
> could speed things up even more. Assuming that branch 2 has no problems,
> but just needs to be built for substitutes, then while branch 1 is built
> on QA, branch 2 will already be built on CI in parallel.
That part, however, does not seem to work out.
https://ci.guix.gnu.org/jobset/nss-updates
shows 43000 scheduled packages, and on the dashboard
https://ci.guix.gnu.org/eval/2078147/dashboard
one sees enormous empty spots. Maybe someone who knows cuirass would be
able to fix this, but the holiday season does not help coping with a bus
factor of 1 or 2...
So we will have to wait for QA.
Andreas
Information forwarded
to guix-patches@gnu.org: bug#78689; Package guix-patches.
(Tue, 12 Aug 2025 07:22:02 GMT) (full text, mbox, link).
Cc: Ian Eure <ian@retrospec.tv>, mail@cbaines.net, 78689@debbugs.gnu.org
Subject: Merging of "nss-updates"
Date: Tue, 12 Aug 2025 09:21:02 +0200
Go-team has been merged last night. I have just rebased on commit
5e4ef038eb3eac660c2d4680446d3dbc09dac9ad from master, and now we
(hopefully) just have to wait until everything builds out.
Andreas
Information forwarded
to guix-patches@gnu.org: bug#78689; Package guix-patches.
(Tue, 12 Aug 2025 11:47:02 GMT) (full text, mbox, link).
On Tue, Aug 12, 2025 at 09:21:02AM +0200, Andreas Enge wrote:
> Go-team has been merged last night. I have just rebased on commit
> 5e4ef038eb3eac660c2d4680446d3dbc09dac9ad from master, and now we
> (hopefully) just have to wait until everything builds out.
>
> Andreas
I found nss@3.101.4 failed in the 'check phase for i686-linux. It looks
like there's an extra round of parenthesis around the substitute* for
the (unless #$(target-64bit?)
((substitute* ...
I wasn't able to quickly find a way to remove the extra parenthesis
without also causing a rebuild on x86_64.
I'm not sold on changing from (if ...) to (when ...) and (unless ...),
part of what we gain from using `if` is only the `true` branch is
evaluated, rather than everything, allowing us to make changes that can
affect fewer targets.
```
phase `build' succeeded after 61.2 seconds
starting phase `check'
error: in phase 'check': uncaught exception:
wrong-type-arg #f "Wrong type to apply: ~S" (#t) (#t)
phase `check' failed after 0.0 seconds
Backtrace:
9 (primitive-load "/gnu/store/qlhwga99vbgl8rbci2k764hvc9f…")
In guix/build/gnu-build-system.scm:
972:2 8 (gnu-build #:source _ #:outputs _ #:inputs _ #:phases . #)
In ice-9/boot-9.scm:
1752:10 7 (with-exception-handler _ _ #:unwind? _ # _)
In srfi/srfi-1.scm:
634:9 6 (for-each #<procedure 1f2070 at guix/build/gnu-build-s…> …)
In ice-9/boot-9.scm:
1752:10 5 (with-exception-handler _ _ #:unwind? _ # _)
In guix/build/gnu-build-system.scm:
993:23 4 (_)
In ice-9/eval.scm:
619:8 3 (_ #(#(#<directory (guile-user) e6690>) #t))
619:8 2 (_ _)
In ice-9/boot-9.scm:
1685:16 1 (raise-exception _ #:continuable? _)
1685:16 0 (raise-exception _ #:continuable? _)
ice-9/boot-9.scm:1685:16: In procedure raise-exception:
Wrong type to apply: #t
build process 18 exited with status 256
builder for `/gnu/store/46rjxw865z0g2h25h8rdy78qg29dxn24-nss-3.101.4.drv' failed with exit code 1
@ build-failed /gnu/store/46rjxw865z0g2h25h8rdy78qg29dxn24-nss-3.101.4.drv - 1 builder for `/gnu/store/46rjxw865z0g2h25h8rdy78qg29dxn24-nss-3.101.4.drv' failed with exit code 1
derivation '/gnu/store/46rjxw865z0g2h25h8rdy78qg29dxn24-nss-3.101.4.drv' offloaded to '141.80.167.178' failed: build of `/gnu/store/46rjxw865z0g2h25h8rdy78qg29dxn24-nss-3.101.4.drv' failed
build of /gnu/store/46rjxw865z0g2h25h8rdy78qg29dxn24-nss-3.101.4.drv failed
```
--
Efraim Flashner <efraim@flashner.co.il> אפרים פלשנר
GPG key = A28B F40C 3E55 1372 662D 14F7 41AA E7DC CA3D 8351
Confidentiality cannot be guaranteed on emails sent or received unencrypted
Am Tue, Aug 12, 2025 at 02:46:30PM +0300 schrieb Efraim Flashner:
> I found nss@3.101.4 failed in the 'check phase for i686-linux. It looks
> like there's an extra round of parenthesis around the substitute* for
> the (unless #$(target-64bit?)
> ((substitute* ...
> I wasn't able to quickly find a way to remove the extra parenthesis
> without also causing a rebuild on x86_64.
Oh dear, that will teach us a lesson!
The attached commit solves the problem by adding a layer of wrapping.
But it is quite ugly. Since we are still early in the rebuild phase,
we could also correct the package and rebuild everything.
What do you think?
Andreas
To: Efraim Flashner <efraim@flashner.co.il>,
Maxim Cournoyer <maxim@guixotic.coop>, Ian Eure <ian@retrospec.tv>,
mail@cbaines.net, 78689@debbugs.gnu.org
Subject: Re: [bug#78689] Merging of "nss-updates"
Date: Tue, 12 Aug 2025 15:57:03 +0200
Am Tue, Aug 12, 2025 at 03:37:44PM +0200 schrieb Andreas Enge:
> we could also correct the package and rebuild everything.
I have opted for this solution and fully reverted the last commit;
you could have a look at the IRC logs for more details.
In short: The late ungexping makes expressions such as
(unless #t ...)
in 64 bits or
(unless #f ...)
in 32 bits appear verbatim in the builder script.
On the other hand, ungexp-splicing the whole expression (here the
(if ...)) forces an evaluation when creating the derivation, so that only
the result appears in the builder script - in 64 bits there is nothing,
since the "then" branch evaluates to the empty list; in 32 bits there
are the expressions from the "else" branch that above I have hidden behind
the ... .
So the #$@(if, or otherwise said the early ungexping, is a feature and
had better be kept.
Andreas
Information forwarded
to guix-patches@gnu.org: bug#78689; Package guix-patches.
(Wed, 13 Aug 2025 16:07:02 GMT) (full text, mbox, link).
To: Efraim Flashner <efraim@flashner.co.il>,
Maxim Cournoyer <maxim@guixotic.coop>, Ian Eure <ian@retrospec.tv>,
mail@cbaines.net, 78689@debbugs.gnu.org
Subject: Re: [bug#78689] Merging of "nss-updates"
Date: Wed, 13 Aug 2025 18:05:47 +0200
Now the revision has been handled by the data service, but not a single
package of the new branch has been built at least since this morning.
All services seem to work, but qa-frontpage does not submit build jobs.
Something happens on CI, but I see only a few i686 packages appearing.
I am at a loss as at what to do now and can only wait and hope that
things magically start working again...
Andreas
Information forwarded
to guix-patches@gnu.org: bug#78689; Package guix-patches.
(Wed, 13 Aug 2025 18:34:02 GMT) (full text, mbox, link).
Reply sent
to Andreas Enge <andreas@enge.fr>:
You have taken responsibility.
(Sun, 17 Aug 2025 20:48:01 GMT) (full text, mbox, link).
Notification sent
to Maxim Cournoyer <maxim.cournoyer@gmail.com>:
bug acknowledged by developer.
(Sun, 17 Aug 2025 20:48:02 GMT) (full text, mbox, link).
Cc: 78689-done@debbugs.gnu.org, mail@cbaines.net,
Efraim Flashner <efraim@flashner.co.il>, Ian Eure <ian@retrospec.tv>
Subject: Re: [bug#78689] Merging of "nss-updates"
Date: Mon, 18 Aug 2025 10:30:25 +0900
Hi,
Andreas Enge <andreas@enge.fr> writes:
> Hello all,
>
> I have merged just now. Time for a mini-celebration!
Yay! Thank you for Shepherding it through the finishing line.
--
Maxim
Debbugs is free software and licensed under the terms of the
GNU Public License version 2. The current version can be
obtained from https://bugs.debian.org/debbugs-source/.