API for rewriting package fields ?
Is there an interface to rewrite / update a field from a series of packages easily? What I get from the change in python-team last change for the pyproject-build-system is that we need to add python-setuptools or python-wheel to all packages that will complain about it, when trying to build. The errors are very easy to diagnose (a string match in stderr: ModuleNotFoundError: No module named 'setuptools' or error: invalid command 'bdist_wheel' is enough to know what's wrong). The logical thing to do here IMO would be to have a script running, reading stderr when it fails and programmatically replacing where it's needed, since it's done for 2-3k packages basically. I know some work has been done with the guix refresh command to rewrite based on package field location, but I'm not sure it provides a convenient-enough API to simply say in guile "add this package to native-inputs of this package in place". Would love some counselling here, thanks! -- Best regards, Nicolas Graves
Re: Should we include nss-certs out of the box?
Hello! On Thu, Apr 25 2024, Maxim Cournoyer wrote: > Clément Lassieur writes: > >> On Wed, Apr 03 2024, Maxim Cournoyer wrote: >> >>> It's been Guix policy to let people choose whether to install or not TLS >>> root certificates and which one to their machine. While I applaud the >>> idea to have the users make a conscious decision about it, in practice I >>> suppose very few of us choose to *not* install any as that basically >>> breaks using web browsers, especially ones like IceCat which (by >>> default) ensures HTTPS is used on every page. >> >> I'd be surprised Icecat breaks from this as it uses its own cert >> database and allows HTTP when HTTPS doesn't work. > > I didn't know Icecat had its own cert database. > > About allowing HTTP, it can access pages using it, but not without going > through a "Continue despite security risks" dialog, and perhaps turning > off the HTTPS everywhere add-on for the page, which is installed by > default. Indeed! (Well it's not an add-on anymore, but a Firefox native mode called HTTPS-only.) https://support.mozilla.org/en-US/kb/https-only-prefs Cheers, Clément
Re: Core updates status
Hi, On Tuesday, April 23rd, 2024 at 11:08 PM, Steve George wrote: > > > Hi, > > We're trying to stabilise and merge core-updates, help definitely wanted! > > https://debbugs.gnu.org/cgi/bugreport.cgi?bug=70456 > > So far the main blockers are: > > - guile-rsvg failing > - https://debbugs.gnu.org/cgi/bugreport.cgi?bug=70537 > - I'm able to build librsvg@2.56.4 but not guile-rsvg > - guile-rsvg@2.18.1 / guile2.2-rsvg > - guile-rsvg builds on master - connected? I've started looking at this build failure this morning, and my initial impressions are that a propagated-input is missing. I tried building guile-rsvg from core-updates and the build failed with three missing pango libraries (ld could not find -lpangocairo-1.0, -lpangoft2-1.0, and -lpango-1.0). I tried moving pango from the inputs to the propagated-inputs for librsvg, and that fixed the build of guile-rsvg. I'm just not sure if that is the right place to propagate it; I haven't yet traced where the pango libraries are being added to the linking command, as I've checked the pkgconfig files for librsvg, cairo, and a couple of other packages and not seen references to pango (which is what makes me think the pango propagated-input is needed elsewhere, and not actually in librsvg--but I also don't know Rust or what dependencies the rust code in librsvg has). Cheers, Kaelyn > This blocks further progress > > What builds so far: > > - gcc-toolchain and all the dependents from commencement.scm > ./pre-inst-env guix build --no-substitutes gcc-toolchain > > - bunch of the basic - but blocked on guile-rsvg > ./pre-inst-env guix system --no-substitutes vm > gnu/system/examples/bare-bones.tmpl > > Other potential issues: > > - 45885 libpng non-deterministic build > https://debbugs.gnu.org/cgi/bugreport.cgi?bug=45885 > won't build due to block on pango - > > - 58719 [core-updates]: build failure for file on i686 > https://ci.guix.gnu.org/build/4057809/details > > - 40316 [core-updates] Nss not reproducible > https://debbugs.gnu.org/cgi/bugreport.cgi?bug=40316 > confirmed > > - 68270 libstdc++-boot0.x86_64 is broken > - https://debbugs.gnu.org/cgi/bugreport.cgi?bug=68270 > > - 39415 [core-updates] Removing SSL patches in CMake and Kodi - help wanted > - check if they are there and remove? > - https://debbugs.gnu.org/cgi/bugreport.cgi?bug=39415 > > > This is building from 4a0e6e3895cefe7c2999c22e56fe9b3dbca97f55 which includes > the last merge from master. > > Thanks, > > Steve
Re: Managing patches and branches, retrospective and futher changes?
Steve George writes: > I think we should strongly recommend against long-running unmerged branches. > > Perhaps there could be a recommendation to merge every 3 months. My hope is that with these process changes, we won't end up with long-running branches. Maybe we could add a recommendation, but I'm not really sure if that would help. We still want to merge these changes when they and related things are ready, so it's not really something that can be willed or commanded to happen. > Could we add any automation to remind people if: > > 1. a branch has been unmerged for more than 3 months We can have QA highlight how long the issues have been open for, that's quite easy to do. > 2. an odd merge takes places (e.g. the core-updates merges) I'm not quite sure what you mean here? Thanks, Chris signature.asc Description: PGP signature
Re: nss not reproducible
Hi,
I believe I have a fix for this, I'm just waiting on my machine to hurry
up and confirm it, might end up running over night, then I'll send my
patch up.
I'm doing two native builds and two cross-builds.
I've also updated to 3.99.
Kind regards,
Christina
On 25/04/2024 15:06, Christina O'Donnell wrote:
Hi Steve,
It would be good to confirm this one:
https://debbugs.gnu.org/cgi/bugreport.cgi?bug=40316
Still fails to reproduce with those changes applied.
The culprit is in nss/cmd/shlibsign/shlibsign.c:
shlibSignHMAC generates a new key-pair each time it's run:
/* Generate a DSA key pair */
logIt("Generate an HMAC key ... \n");
crv = pFunctionList->C_GenerateKey(hRwSession, ,
hmacKeyTemplate,
PR_ARRAY_SIZE(hmacKeyTemplate),
);
Three options:
1. Disable library signing entirely.
2. Seed the generation to be deterministic.
3. Drop in a HMAC key-pair and patch the code to use that instead of
generating.
2 and 3 defeat the point of the cryptographically secure supply chain
as the private key can be obtained deterministically, so my vote would
be simply to not sign the libraries (1), which would be easier to
maintain. We're not the primary distributor and users can verify our
distribution of nss by running `guix challenge` anyway.
It looks like Zhen Junjie applied two patches to fix NSS
cross-compilation on Master [0]
Building everything cross-compiled to ARM now.
Kind regards,
Christina
Re: Python's native-inputs
Hi Guix, Just to let you know, I just added a working patch series that does this job on (guix build, guix import pypi, guix lint). This is not the full patch series, which I have rebased on python-team, but it should be good enough 1) to test it 2) to review it for a v2 that would be more guixy It's in 70570. Cheers, Nicolas On 2024-04-22 16:40, Ricardo Wurmus wrote: >> TL;DR : >> - patch series in big progress, not done yet because I don't really >> know where to stop and massive rebuilds. > > Please take a look at the python-team branch, which contains changes to > the build system. -- Best regards, Nicolas Graves
Re: Should we include nss-certs out of the box?
Hello! Clément Lassieur writes: > On Wed, Apr 03 2024, Maxim Cournoyer wrote: > >> It's been Guix policy to let people choose whether to install or not TLS >> root certificates and which one to their machine. While I applaud the >> idea to have the users make a conscious decision about it, in practice I >> suppose very few of us choose to *not* install any as that basically >> breaks using web browsers, especially ones like IceCat which (by >> default) ensures HTTPS is used on every page. > > I'd be surprised Icecat breaks from this as it uses its own cert > database and allows HTTP when HTTPS doesn't work. I didn't know Icecat had its own cert database. About allowing HTTP, it can access pages using it, but not without going through a "Continue despite security risks" dialog, and perhaps turning off the HTTPS everywhere add-on for the page, which is installed by default. -- Thanks, Maxim
Re: Core updates status
Hi Steve,
It would be good to confirm this one:
https://debbugs.gnu.org/cgi/bugreport.cgi?bug=40316
Still fails to reproduce with those changes applied.
The culprit is in nss/cmd/shlibsign/shlibsign.c:
shlibSignHMAC generates a new key-pair each time it's run:
/* Generate a DSA key pair */
logIt("Generate an HMAC key ... \n");
crv = pFunctionList->C_GenerateKey(hRwSession, ,
hmacKeyTemplate,
PR_ARRAY_SIZE(hmacKeyTemplate),
);
Three options:
1. Disable library signing entirely.
2. Seed the generation to be deterministic.
3. Drop in a HMAC key-pair and patch the code to use that instead of
generating.
2 and 3 defeat the point of the cryptographically secure supply chain as
the private key can be obtained deterministically, so my vote would be
simply to not sign the libraries (1), which would be easier to
maintain. We're not the primary distributor and users can verify our
distribution of nss by running `guix challenge` anyway.
It looks like Zhen Junjie applied two patches to fix NSS cross-compilation on
Master [0]
Building everything cross-compiled to ARM now.
Kind regards,
Christina
Re: Managing patches and branches, retrospective and futher changes?
Hi, I think we should strongly recommend against long-running unmerged branches. Perhaps there could be a recommendation to merge every 3 months. Could we add any automation to remind people if: 1. a branch has been unmerged for more than 3 months 2. an odd merge takes places (e.g. the core-updates merges) Thanks, Steve On 24 Apr, Christopher Baines wrote: > Hey! > > Almost a year ago, the branching strategy was changed [1][2]. > > 1: https://issues.guix.gnu.org/63459 > 2: https://lists.gnu.org/archive/html/guix-devel/2023-06/msg00024.html > > I think these changes have gone OK, we've had ~27 [3] branches merged in > this manor and I think looking back these changes have been > helpful. Coordination and visibility has improved, and we've been able > to build and test more prior to merging. > > 3: https://issues.guix.gnu.org/search?query=%22Request+for+merging%22 > > There's still room for more improvement though. The current guidance is > here [4], and I've sent a patch for improvements here [5]. > > 4: > https://guix.gnu.org/en/manual/devel/en/html_node/Managing-Patches-and-Branches.html > 5: https://issues.guix.gnu.org/70549 > > Let me know if you have any thoughts or questions! > > Thanks, > > Chris
