(name . guix-patches)(address . guix-patches@gnu.org)
87msao9rhu.fsf@gmail.com
on 3 Jun 19:21 -0700
on 20 Jun 14:01 -0700
on 19 Jul 13:08 -0700
on 5 Aug 19:19 -0700
on 12 Aug 04:46 -0700
Request for merging "nss-updates" branch
- Done
Details
- 5 participants
- Andreas Enge
- Greg Hogan
- Efraim Flashner
- Maxim Cournoyer
- Maxim Cournoyer
- Owner
- unassigned
- Submitted by
- Maxim Cournoyer
- Severity
- normal
- Blocked by
Block c++ by nss
(address . control@debbugs.gnu.org)
aFXMFEmZH7WEGkfA@jurong
block 76899 by 78689
thanks
After the merge is before the merge
aHqc5o9rYnO8gLFL@jurong
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:
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
Unblock
(address . control@debbugs.gnu.org)
aHtJeL6MUvmX85KN@jurong
unblock 76899 by 78689
unblock 76899 by 78676
thanks
Re: After the merge is before the merge
(name . Andreas Enge)(address . andreas@enge.fr)
87seisqsoc.fsf@guixotic.coop
Hi Andreas,
+CC Zheng
Andreas Enge <andreas@enge.fr> writes:
Toggle quote (14 lines)
> 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?
[...]
Toggle quote (3 lines)
> 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
(name . Andreas Enge)(address . andreas@enge.fr)
CA+3U0Z=c0mj6wPTAv=YQ2XzHZ_1ae6NWaqPtLOyquacoHijfaQ@mail.gmail.com
On Fri, Jul 18, 2025 at 3:13 PM Andreas Enge <andreas@enge.fr> wrote:
Toggle quote (25 lines)
>
> 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
(name . Andreas Enge)(address . andreas@enge.fr)
CA+3U0Z=sh6OaMQ3UOnj9jQQn-90ZjyDn=gxfG12B-9XrTP0vPw@mail.gmail.com
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
(name . Greg Hogan)(address . code@greghogan.com)
aH5UFaS3eGGGO20P@jurong
Hello Greg,
Am Mon, Jul 21, 2025 at 10:05:14AM -0400 schrieb Greg Hogan:
Toggle quote (10 lines)
> 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:
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:
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
(name . Andreas Enge)(address . andreas@enge.fr)
CA+3U0ZkZ6dp-a6k-5YJf1cNAP71Ua70aE2tzxb_QTkGuRu4HbA@mail.gmail.com
On Mon, Jul 21, 2025 at 10:52 AM Andreas Enge <andreas@enge.fr> wrote:
Toggle quote (6 lines)
>
> 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".
Toggle quote (11 lines)
> 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
(name . Greg Hogan)(address . code@greghogan.com)
aH5ynsdQh8RDcMnC@jurong
Am Mon, Jul 21, 2025 at 12:54:59PM -0400 schrieb Greg Hogan:
Toggle quote (4 lines)
> 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.
Toggle quote (6 lines)
> 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
Rebase required
(address . 78689@debbugs.gnu.org)(name . Maxim Cournoyer)(address . maxim@guixotic.coop)
aIOSqczB4cRLnjS6@jurong
Hello,
I have just pushed qt-teams to master, and your branch is second in
line. Could you maybe rebase it?
Thanks,
Andreas
Blocking
(address . control@debbugs.gnu.org)
aISntTRXr-a4bc2j@jurong
block 78689 by 78781
thanks
Re: Rebase required
(address . 78689@debbugs.gnu.org)
aJBimCGCqPn5Lg2c@jurong
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
(name . Andreas Enge)(address . andreas@enge.fr)
87zfcdxkd1.fsf@guixotic.coop
Hi,
Andreas Enge <andreas@enge.fr> writes:
Toggle quote (7 lines)
> 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
(name . Maxim Cournoyer)(address . maxim@guixotic.coop)
aJMGbCe2hyMGD69B@jurong
Am Wed, Aug 06, 2025 at 11:19:22AM +0900 schrieb Maxim Cournoyer:
Toggle quote (2 lines)
> 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
(name . Maxim Cournoyer)(address . maxim@guixotic.coop)
aJMGzFeYCzgcmNU0@jurong
Am Wed, Aug 06, 2025 at 09:38:20AM +0200 schrieb Andreas Enge:
Toggle quote (3 lines)
> 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
(name . Maxim Cournoyer)(address . maxim@guixotic.coop)
aJTfL9pOyK6F5UUM@jurong
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
(name . Andreas Enge)(address . andreas@enge.fr)
87ldnutusp.fsf@guixotic.coop
Hi,
Andreas Enge <andreas@enge.fr> writes:
Toggle quote (14 lines)
> 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
(name . Maxim Cournoyer)(address . maxim@guixotic.coop)
aJWsKRj5dmaQ2vzl@jurong
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:
(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
(name . Maxim Cournoyer)(address . maxim@guixotic.coop)
aJja5S5cGjjsVTK8@jurong
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:
Toggle quote (9 lines)
> 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
(name . Maxim Cournoyer)(address . maxim@guixotic.coop)
aJjdjdczCKdsVX7i@jurong
Am Sun, Aug 10, 2025 at 07:46:13PM +0200 schrieb Andreas Enge:
Toggle quote (13 lines)
> 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
(name . Maxim Cournoyer)(address . maxim@guixotic.coop)
aJjs_rxGVluDh0hw@jurong
Am Sun, Aug 10, 2025 at 07:57:33PM +0200 schrieb Andreas Enge:
Toggle quote (2 lines)
> 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
(name . Maxim Cournoyer)(address . maxim@guixotic.coop)
aJo1K65Sc8DctCew@jurong
Am Thu, Aug 07, 2025 at 07:15:27PM +0200 schrieb Andreas Enge:
Toggle quote (6 lines)
> 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.
Toggle quote (5 lines)
> 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.
shows 43000 scheduled packages, and on the 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
Merging of "nss-updates"
(name . Maxim Cournoyer)(address . maxim@guixotic.coop)
aJrrXgwdbaL1Dn7E@jurong
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
(name . Andreas Enge)(address . andreas@enge.fr)
aJsplnbZQNE1dYc4@3900XT
On Tue, Aug 12, 2025 at 09:21:02AM +0200, Andreas Enge wrote:
Toggle quote (6 lines)
> 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
-----BEGIN PGP SIGNATURE-----
iQIzBAABCAAdFiEEoov0DD5VE3JmLRT3Qarn3Mo9g1EFAmibKZYACgkQQarn3Mo9
g1HwLQ//Skd7kA7fJq6nP3Eojhv5Ltf8Rcf3Bor98TQtJ8Q+ZSaR4m2HC4U1bChL
89halx7n+8UXjSlNrSJC2P4Zg7kaUJGskytOYbowuVafpCne/Gnig50dQ2V4TyeA
YuQVU8bZRdx9YAJp5q4fgFW5N0RTGU7+o9Nsy/Gux96LhB9HcBX90vnWNDkw79+o
4bZGGrs4mdAkrTj3SOZ7X7pVY46Eg/GcnhnF362C4vfPGWfFHzpjSZEVub/ureoq
eHrACpqe+xKhUI9l6U9PkoeRZ5gI8rNqzrn+6oN262zc2h6wdCMFA4BwXb9lCRaa
HtVJYSRLTXA+CaZ+kSCUCZPXSpBj6ND3CbYEPjjYQRgSNz+T9mjW6Ogy7o5E570G
6pZ8Qqc1jwpbAvD+xq6fPQX+HYrDPRc6NfzMbGkE9q3PLEWsXJqxL8JgWCorlPkO
69eLzdJZ5h9rsSVPImJ3ALQ+gcnsYvwhe5gO0mNBzwv5Hkcm+ITncCrpvHchBhjk
ZxAnEpuMh8cMCTE6JG5KTPP6yJsFspLpvi/TR+8L4DqYCxkeQhAq3FdCOaBY2K12
gEpQ8dBo0YHAGssOxUodOk1LiF2qOLo5JLbOf/D2BOca7JK6ppqpwn//cTJka7bz
9GT3UoP3eXa5UIr9I4EGHQXWt+xUeJrUptDCk3eI4BtlAtjbZ7c=
=cgGN
-----END PGP SIGNATURE-----
aJtDqPt9hcHHQkhJ@jurong
Am Tue, Aug 12, 2025 at 02:46:30PM +0300 schrieb Efraim Flashner:
Toggle quote (7 lines)
> 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
From 10002034a66abf2a67c72f8157c052937140230a Mon Sep 17 00:00:00 2001
Message-ID: <10002034a66abf2a67c72f8157c052937140230a.1755005604.git.andreas@enge.fr>
From: Andreas Enge <andreas@enge.fr>
Date: Tue, 12 Aug 2025 15:32:12 +0200
Subject: [PATCH] gnu: nss: Fix build on 32 bit.
Change-Id: I81279a601b9d16140fd58af4613bc8aa9573d099
---
gnu/packages/nss.scm | 17 ++++++++++++++++-
1 file changed, 16 insertions(+), 1 deletion(-)
Toggle diff (38 lines)
diff --git a/gnu/packages/nss.scm b/gnu/packages/nss.scm
index 40adef194b..120becd1cb 100644
--- a/gnu/packages/nss.scm
+++ b/gnu/packages/nss.scm
@@ -219,13 +219,28 @@ (define-public nss
(substitute* "nss/tests/dbtests/dbtests.sh"
((" -lt 5") " -lt 50"))
- (unless #$(target-64bit?)
+ ;; Workaround for an error in a previous commit that we
+ ;; prefer to not revert.
+ #$@(if (target-64bit?)
+ ;; The previous faulty code, needs to be copied so as
+ ;; not to change the derivation in 64 bit.
+ `((unless ,(target-64bit?)
;; The script fails to determine the source
;; directory when running under 'datefudge' (see
;; <https://issues.guix.gnu.org/72239>). Help it.
((substitute* "nss/tests/gtests/gtests.sh"
+ (("SOURCE_DIR=.*")
+ (string-append "SOURCE_DIR=" (getcwd) "/nss\n"))))))
+ ;; The correct code for 32 bit. On the next run,
+ ;; keep only this "else" branch.
+ `((unless ,(target-64bit?)
+ ;; The script fails to determine the source
+ ;; directory when running under 'datefudge' (see
+ ;; <https://issues.guix.gnu.org/72239>). Help it.
+ (substitute* "nss/tests/gtests/gtests.sh"
(("SOURCE_DIR=.*")
(string-append "SOURCE_DIR=" (getcwd) "/nss\n")))))
+ )
(let ((release-date (getenv "GUIX_NSS_RELEASE_DATE")))
(when (string=? "" release-date)
base-commit: c20d32dc5d3f69e7bcb49951043cf7786700b72f
--
2.50.1
From 10002034a66abf2a67c72f8157c052937140230a Mon Sep 17 00:00:00 2001
Message-ID: <10002034a66abf2a67c72f8157c052937140230a.1755005604.git.andreas@enge.fr>
From: Andreas Enge <andreas@enge.fr>
Date: Tue, 12 Aug 2025 15:32:12 +0200
Subject: [PATCH] gnu: nss: Fix build on 32 bit.
Change-Id: I81279a601b9d16140fd58af4613bc8aa9573d099
---
gnu/packages/nss.scm | 17 ++++++++++++++++-
1 file changed, 16 insertions(+), 1 deletion(-)
Toggle diff (38 lines)
diff --git a/gnu/packages/nss.scm b/gnu/packages/nss.scm
index 40adef194b..120becd1cb 100644
--- a/gnu/packages/nss.scm
+++ b/gnu/packages/nss.scm
@@ -219,13 +219,28 @@ (define-public nss
(substitute* "nss/tests/dbtests/dbtests.sh"
((" -lt 5") " -lt 50"))
- (unless #$(target-64bit?)
+ ;; Workaround for an error in a previous commit that we
+ ;; prefer to not revert.
+ #$@(if (target-64bit?)
+ ;; The previous faulty code, needs to be copied so as
+ ;; not to change the derivation in 64 bit.
+ `((unless ,(target-64bit?)
;; The script fails to determine the source
;; directory when running under 'datefudge' (see
;; <https://issues.guix.gnu.org/72239>). Help it.
((substitute* "nss/tests/gtests/gtests.sh"
+ (("SOURCE_DIR=.*")
+ (string-append "SOURCE_DIR=" (getcwd) "/nss\n"))))))
+ ;; The correct code for 32 bit. On the next run,
+ ;; keep only this "else" branch.
+ `((unless ,(target-64bit?)
+ ;; The script fails to determine the source
+ ;; directory when running under 'datefudge' (see
+ ;; <https://issues.guix.gnu.org/72239>). Help it.
+ (substitute* "nss/tests/gtests/gtests.sh"
(("SOURCE_DIR=.*")
(string-append "SOURCE_DIR=" (getcwd) "/nss\n")))))
+ )
(let ((release-date (getenv "GUIX_NSS_RELEASE_DATE")))
(when (string=? "" release-date)
base-commit: c20d32dc5d3f69e7bcb49951043cf7786700b72f
--
2.50.1
aJtIL2UEBCjw54bz@jurong
Am Tue, Aug 12, 2025 at 03:37:44PM +0200 schrieb Andreas Enge:
Toggle quote (2 lines)
> 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
aJy32zStr_0lETSz@jurong
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
aJzaUQIAYDftdbXl@jurong
Am Wed, Aug 13, 2025 at 06:05:47PM +0200 schrieb Andreas Enge:
Toggle quote (3 lines)
> I am at a loss as at what to do now and can only wait and hope that
> things magically start working again...
aKI_1Sa1KZOYCzZM@jurong
Hello all,
I have merged just now. Time for a mini-celebration!
Andreas
Closed
(name . Andreas Enge)(address . andreas@enge.fr)
87ldnhto0e.fsf@guixotic.coop
Hi,
Andreas Enge <andreas@enge.fr> writes:
Toggle quote (4 lines)
> Hello all,
>
> I have merged just now. Time for a mini-celebration!
Yay! Thank you for Shepherding it through the finishing line.
--
Maxim
Closed
?