mbox series

[bug#73152,0/6] NSS updates

Message ID 20240909175249.8003-1-ian@retrospec.tv
Headers
Series NSS updates |

Message

Ian Eure Sept. 9, 2024, 5:52 p.m. UTC 
Hello,

This is a first pass at getting the nss packages into shape, as I proposed
earlier this year[1].  Many packages depend on nss, so these patches need to
be applied to a new branch -- my suggestion is `nss-updates', but I have no
strong preference.

This patch series:

- Ungrafts nss
- Factors out package creation into the `make-nss' procedure.
- Updates nss and nss-rapid to use that procedure.
- Updates nss and nss-certs to 3.102.1, the current ESR.
- Updates nss-rapid to 3.104, the latest release.
- Removes nspr-4.32, as it doesn’t appear to be used by anything.

[1]: https://lists.gnu.org/archive/html/guix-devel/2024-06/msg00318.html

Ian Eure (6):
  gnu: Remove nss/fixed.
  gnu: Remove nspr-4.32.
  gnu: Add make-nss.
  gnu: nss: Update to 3.102.1.
  gnu: nss-rapid: Update to 3.104.
  gnu: nss-certs: Update to 3.102.1.

 gnu/packages/certs.scm |   4 +-
 gnu/packages/nss.scm   | 208 +++++++++++------------------------------
 2 files changed, 59 insertions(+), 153 deletions(-)

Comments

Ian Eure May 17, 2025, 6:19 p.m. UTC | #1 
Hi Liliana, Christopher,

Liliana Marie Prikler <liliana.prikler@gmail.com> writes:

> Note: the explanation should come before the ChangeLog.

Fixed, thanks.


Christopher Baines <mail@cbaines.net> writes:

> Maybe there's a more elegant way to share a value between phases 
> in the
> builder, but I think even doing it via an environment variable 
> is still
> preferable than using a procedure to create the package. I've 
> spent many
> hours debugging complex functional and performance related 
> issues caused
> by procedures returning packages, and while it's a powerful 
> tool, it's
> something to be avoided unless necessary.

I adopted this suggestion, and it made for a much cleaner setup. 
Thank you!

The current patch series is working and ready for review.  I 
haven’t rebuilt all the dependent packages (and QA is down, so I’m 
not sure whether it has, but it’s had a week to do so), but the 
direct nss/nspr changes build and seem to work for me.

> In terms of how to make this kind of change, I'd split it in to 
> two
> parts. Introducing the environment variable can definately go to 
> the
> core-packages-team branch in my opinion, and the package updates 
> could
> maybe as well, but I'd think of it as two separate patch series.

This patch series updates nss, but leaves nss-rapid for a later 
series.  I’d prefer not to block this on core-package-team, but if 
you feel strongly that some or all of these changes should go 
there, I will direct them.  Given that it’s been 8 months since I 
opened the series and that will extend the timeline greatly, I’m 
disinclined to complicate things more -- and would likely end up 
needing to move all the changes to Codeberg with the added delay. 
WDYT?

 -- Ian