bug#70954: No 'guix pull' substitutes for foreign distros?

[Nigko Yerden]

Hi Florian Pelz,


https://guix.gnu.org/manual/en/html_node/Channels-with-Substitutes.html

Yes, I'm aware about this feature. It doesn't help.


it might be bad timing.

I think this possibility can be excluded because of:

1) I have performed 'guix pull' on the system B for the last few
months (maybe half a year) a few dozens of times and every time I
observed it build all the derivations by itself.

2) I had performed the experiment. I queried [1] for the latest
commit with substitutes and performed 'guix pull --commit="obtained commit"'
on systems A and B (they are both x86_64). The results of this experiment
are  presented in my first message.

3) Today I have preformed the similar experiment. According to [1] the
latest commit with substitutes was "5a624adfd". Again, the system B
have built all the derivations by itself while the system A have
downloaded substitutes.

[1] https://ci.guix.gnu.org/api/latestbuilds?nr=1=guix.x86_64-linux

Regards,
Nigko

pelzflorian (Florian Pelz) wrote:

Hello Nigko Yerden.  You could definitely test if substitutes are never
available if you used

https://guix.gnu.org/manual/en/html_node/Channels-with-Substitutes.html

which should guarantee that it will use a version of Guix where guix
pull has substitutes.  When not using
channel-with-substitutes-available, it might be bad timing.

Regards,
Florian

bug#70663: nss@3.99 is really hard to build

[Ian Eure]

Maxim Cournoyer  writes:


Hi Mark,

Mark H Weaver  writes:


Hi Maxim,

Maxim Cournoyer  writes:


Christopher Baines  writes:

[...]
At least from what I can see on the issues, the problem was 
introduced
with the update to 3.98.0 [3] and then continued with the 
update to 3.99
[4]. Given the changes in 70662 were sent to guix-patches and 
then
merged less than 24 hours later, I'd imagine that wasn't 
sufficient time

for data.qa.guix.gnu.org to fail attempting to build nss.


I think in [3] you meant https://issues.guix.gnu.org/70569, 
not #70662.


Since this was security sensitive, I built it on x86_64, 
tested it there
to ensure that IceCat worked as expected, had others confirmed 
it worked

for them on #guix then pushed.

[...]

3: https://issues.guix.gnu.org/70662
4: https://issues.guix.gnu.org/70618


Note that the IceCat package in Guix currently uses the copy of 
NSS that
comes bundled with the IceCat source code, so testing IceCat 
probably
won't tell you much about whether the standalone NSS package in 
Guix

works properly.


Thanks for the heads-up.  It looks like there are now some low 
hanging

fruits in terms of unbundling opportunities for icecat/Icedove!



Definitely.  The LibreWolf package is probably a good reference, 
as I was able to unbundle all its library dependencies and use the 
Guix-packaged versions instead.


 — Ian

bug#70926: Having default nss-certs plus nss-certs in operating-system packages causes problems

[Maxim Cournoyer]

Hello,

Liliana Marie Prikler  writes:

> Am Montag, dem 13.05.2024 um 22:38 +0100 schrieb Christopher Baines:
>> I've seen this when updating systems, but it seems like something is
>> wrong with the handling of nss-certs.
>> 
>> I'm on a guix revision with nss-certs by default, and when I add
>> nss-certs to my system packages (to simulate not removing it when
>> upgrading), it breaks certificates (e.g. wget https://guix.gnu.org/
>> doesn't work).
> I can confirm this on three machines (two of my own, one from a
> relative): Having nss-certs in the packages field unexpectedly breaks
> all known certificates.
>
>> My reading of the operating-system-packages code suggests that adding
>> nss-certs shouldn't have any effect, but this doesn't seem to be
>> working.
> It would be really nice to detect the mismatching versions if it's
> based on that.  IIUC we graft nss-certs now, so that we can hot-swap
> stuff like pythons certifi package.  Is this use case broken by any
> chance?

Apparently having multiple nss-certs of the same version is no problem
(they get deduped later).  The original problem would thus only exist
when there are multiple versions of nss-certs listed in packages, as
could happen for installer-generated configs that use
'(specification->package "nss-certs"), which would pick the latest
version and clash with the one in %base-packages.

My code could call delete even in the first case, which would clear
*all* nss-certs because they were the same object.  That's now guarded
against in 35ae95061e1b843e1df069693177519f22f9a16d ("system: Do not
delete all nss-certs packages when they are the same object."), which
I've just pushed.

Closing.

-- 
Thanks,
Maxim

bug#70850: question on nss-certs

[Maxim Cournoyer]

Hello,

jbra...@dismail.de writes:

> May 10, 2024 at 1:51 AM, "Antonio Carlos Padoan Junior" 
>  wrote:
>
>
>
>> 
>> jbra...@dismail.de writes:
>> 
>> > 
>> > May 9, 2024 at 1:53 PM, "Olivier Dion"  wrote:
>> > 
>> >  The best place for bugs, is to discuss them on bug-guix@gnu.org. That way 
>> > 
>> >  it ends up in our bug tracker. guix-de...@gnu.org is really meant for
>> > 
>> >  massive cool changes that you want guix to include. :)
>> > 
>> 
>> Thank you, I was not certain it was a bug. And yes, next time I will try
>> 
>> to be more precise in which list to post.
>
> No worries.  I hope the bug gets fixed.  :)

Should be fixed with: 35ae95061e ("system: Do not delete all nss-certs
packages when they are the same object.").

Sorry for the breakage, and thanks for the report!

-- 
Thanks,
Maxim

bug#70663: nss@3.99 is really hard to build

[Maxim Cournoyer]

Hi Mark,

Mark H Weaver  writes:

> Hi Maxim,
>
> Maxim Cournoyer  writes:
>
>> Christopher Baines  writes:
> [...]
>>> At least from what I can see on the issues, the problem was introduced
>>> with the update to 3.98.0 [3] and then continued with the update to 3.99
>>> [4]. Given the changes in 70662 were sent to guix-patches and then
>>> merged less than 24 hours later, I'd imagine that wasn't sufficient time
>>> for data.qa.guix.gnu.org to fail attempting to build nss.
>>
>> I think in [3] you meant https://issues.guix.gnu.org/70569, not #70662.
>>
>> Since this was security sensitive, I built it on x86_64, tested it there
>> to ensure that IceCat worked as expected, had others confirmed it worked
>> for them on #guix then pushed.
> [...]
>>> 3: https://issues.guix.gnu.org/70662
>>> 4: https://issues.guix.gnu.org/70618
>
> Note that the IceCat package in Guix currently uses the copy of NSS that
> comes bundled with the IceCat source code, so testing IceCat probably
> won't tell you much about whether the standalone NSS package in Guix
> works properly.

Thanks for the heads-up.  It looks like there are now some low hanging
fruits in terms of unbundling opportunities for icecat/Icedove!

-- 
Thanks,
Maxim

bug#70960: [PATCH] gnu: Remove mozjs-91.

[Andreas Enge]

Hallo, Jonathan!

Am Wed, May 15, 2024 at 10:12:10PM +0200 schrieb Jonathan Brielmaier:
> I'm not sure we should remove it yet.
> 0ad (the only reverse-dependency of mozjs@78) at master branch uses
> mozjs@91. So the next release of it would require mozjs@91.

thanks for the info! It agrees with the feeling that it is strange to
remove @91 while keeping @78.

So I will just close this bug report, which will store the info for
future use.

Andreas

bug#70960: [PATCH] gnu: Remove mozjs-91.

[Jonathan Brielmaier via Bug reports for GNU Guix]

Hallo Andreas,

Am 15.05.24 um 21:13 schrieb Andreas Enge:

* gnu/packages/gnuzilla.scm (mozjs-91): Delete variable.


I'm not sure we should remove it yet.

0ad (the only reverse-dependency of mozjs@78) at master branch uses
mozjs@91. So the next release of it would require mozjs@91.

See:
https://trac.wildfiregames.com/wiki/SpiderMonkey
https://code.wildfiregames.com/D4428

~Jonathan

bug#70960: [PATCH] gnu: Remove mozjs-91.

[Andreas Enge]

* gnu/packages/gnuzilla.scm (mozjs-91): Delete variable.

Change-Id: I121a480eb15d670461a70b7703a3a658d9db6732
---
 gnu/packages/gnuzilla.scm | 31 ---
 1 file changed, 31 deletions(-)

diff --git a/gnu/packages/gnuzilla.scm b/gnu/packages/gnuzilla.scm
index 814b610bba..6ec5ba272b 100644
--- a/gnu/packages/gnuzilla.scm
+++ b/gnu/packages/gnuzilla.scm
@@ -223,37 +223,6 @@ (define-public mozjs
 in C/C++.")
 (license license:mpl2.0))) ; and others for some files
 
-(define-public mozjs-91
-  (package
-(inherit mozjs)
-(version "91.13.0")
-(source (origin
-  (method url-fetch)
-  (uri (string-append "https://ftp.mozilla.org/pub/firefox;
-  "/releases/" version "esr/source/firefox-"
-  version "esr.source.tar.xz"))
-  (sha256
-   (base32
-"0qh7j960wdp5zcfqhkj8ki47spp9i9ms12xx0v0kxvmmw36jpgjk"
-(arguments
- (substitute-keyword-arguments (package-arguments mozjs)
-   ((#:phases phases)
-#~(modify-phases #$phases
-(add-before 'check 'disable-timezone-tests
-  (lambda _
-(with-directory-excursion "../js/src/tests"
-  ;; FIXME: Assertion failed: got "2021a", expected "2021a3"?
-  (delete-file 
"non262/Intl/DateTimeFormat/timeZone_version.js")
-  ;; XXX: Delete all tests that test time zone functionality,
-  ;; because the test suite uses /etc/localtime to figure out
-  ;; the offset from the hardware clock, which does not work
-  ;; in the build container.  See .
-  (delete-file-recursively "non262/Date")
-  (delete-file
-   
"non262/Intl/DateTimeFormat/tz-environment-variable.js"
-(inputs (modify-inputs (package-inputs mozjs)
-  (replace "icu4c" icu4c-69)
-
 (define-public mozjs-78
   (package
 (inherit mozjs)

base-commit: bc6742e168f4af9d6479e00f482998b03653787a
prerequisite-patch-id: c4d3caa64171c21ee75b8ba30c80cab10c3674ef
-- 
2.41.0

bug#70960: Remove mozjs and icu4c versions

[Andreas Enge]

Well, icu4c-69 is needed by mozjs-78, so we cannot remove it.
But mozjs-91 should be good to remove. Let QA give us its opinion.

Andreas

bug#70960: Remove mozjs and icu4c versions

[Andreas Enge]

To partially answer my questions:

Am Wed, May 15, 2024 at 05:46:47PM +0200 schrieb Andreas Enge:
> The only package depending on mozjs@78 is 0ad. Maybe the dependency
> can be upgraded?

0ad is on the latest release, and cannot be built with any other of the
mozjs versions we currently have. So I would suggest to remove mozjs-91
and icu4c-69.

Thoughts?

Andreas

bug#70841: Upgrade-Shepherd-Services Error when adding wayland support to gdm

[Josselin Poiret via Bug reports for GNU Guix]

Hi,

not emma via Bug reports for GNU Guix  writes:

> guix system: error: error parsing derivation
> `/gnu/store/4xz1998qw8niax3pi0lsbwxfl7dfrpil-
>
> upgrade-shepherd-services
>
> .drv':
> expected string `Derive(['

This looks like a store integrity issue, you might want to repair it
using `guix gc --verify=contents,repair`.

Best,
-- 
Josselin Poiret


signature.asc
Description: PGP signature

bug#70960: Remove mozjs and icu4c versions

[Andreas Enge]

After a recent patch updating the icu4c@68 dependency of 0ad to icu4c,
I have gone through icu4c and mozjs dependents.

It turns out that nothing depends on mozjs@91. Can it be removed?
Then I think that icu4c@69 can also be removed.

The only package depending on mozjs@78 is 0ad. Maybe the dependency
can be upgraded? (Well, we should check this first, upgrading to
mozjs@91 will prevent us from removing this...)

Andreas

bug#70258: FreeCAD dependency probably outdated

[Guillaume Le Vaillant]

Fixed by .


signature.asc
Description: PGP signature

bug#70698: python-pivy build fails (freecad dependency)

[Guillaume Le Vaillant]

Fixed by .


signature.asc
Description: PGP signature

bug#70954: No 'guix pull' substitutes for foreign distros?

[pelzflorian (Florian Pelz)]

Hello Nigko Yerden.  You could definitely test if substitutes are never
available if you used

https://guix.gnu.org/manual/en/html_node/Channels-with-Substitutes.html

which should guarantee that it will use a version of Guix where guix
pull has substitutes.  When not using
channel-with-substitutes-available, it might be bad timing.

Regards,
Florian