On Fri, Feb 07, 2025 at 01:59:46AM +0100, dan...@friendly-machines.com wrote: > Hi Ludo, > > > Could you please either revert this commit or merge the two 'dlib' > > definitions, assuming the upgrade does not break any dependent? (You > > can use 'guix build -P1 dlib' for example to check that.) > > I've merged them now and checked the only 3 dependents, starting with > python-openturns and the rest being in guix-hpc: they still do the > same not-that-great stuff that they did before (since the python > bindings are not enabled in dlib and were not enabled before in > dlib either it's not optimizing by using dlib even though it could). > > I'll investigate some more. > > In the meantime the dlib duplicate is straightened out on guix master > with my commit 438e13306162d8a969ae299d247e0d8d36507387. > > Well, at least we got a dlib update out :) > > P.S. if I enable dlib parallel builds and checks, it will use all > the CPU and RAM of my machine (which is not easy) and then fail the > build. So, right now, the "check" phase is done on one core instead. > > But the dlib package could use further tuning like > > cmake --build --parallel (/ number-of-cores 7) > > or whatever.
Another option would be something like (untested):
(replace 'check
(lambda args
(or (assoc-ref %standard-phases 'check)
(apply ((assoc-ref %standard-phases 'check)
#:parallel-tests? #f) args)))
> > PS: I think it's also a case showing how we could benefit from a
> > streamlined process where changes are merged only once they've had a
> > green light from CI.
>
> I agree.
>
> I think https://qa.guix.gnu.org/patches would be going in the right
> direction already--but I feel it does 500 internal server error
> pretty often.
>
> Just checked, it's not doing 500 internal server error right now.
> Nice :)
>
--
Efraim Flashner <efr...@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
signature.asc
Description: PGP signature
