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.
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 :)
