Re: Recommended way of packaging web themes
Hi Felix, Tomas, El 9/11/23 a las 7:56, Tomas Volf escribió: On 2023-11-08 15:44:46 -0800, Felix Lechner via Development of GNU Guix and the GNU System distribution. wrote: Hi Felipe, On Wed, Nov 08 2023, Luis Felipe wrote: I'm looking into packaging the current Guix's website theme [...] I think it would be easier for other Guix websites and services (e.g. CI, QA, DATA) to use them and hopefully achieve a more uniform look and feel for the network of Guix web fronts. Could you simply publish the resources online (except Javascript, of course) so any site can use them? If that will be done, please try to provide a versioned, well, version as well, so that subresource integrity can be used. Thanks, I'll explore that path instead: simply serving them and using Cross-Origin Resource Sharing (CORS) and Subresource Integrity (SRI). OpenPGP_0x0AB0D067012F08C3.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature
Re: Turning off tests leads to a different store item
Hi Simon, Simon Tournier writes: [...] >> I think the lower fruits are in looking at making the test suite of the >> few common offenders more robust (using libfaketime or the likes) to >> prevent (re)occurrences of time bombs in the future. > > I agree. On a side note, one of the issue is the time of some tests. > Sometimes, packaging is frustrating: build takes ages, then you fix some > tests, think it will be good, re-launch “guix build”, another test > failing, repeat. It could nice to be able to cache the result of the > build phase. I usually end up working in the /tmp/guix-build-* failed build of a package for these situations; then I don't need to rebuild the whole thing for each test suite run, and can test changes directly without proper patches while working toward a fix. -- Thanks, Maxim
Re: Better support remote deployment
Hi, Efraim Flashner writes: [...] >> 'guix package' is already the command we use to create profiles; maybe >> it could accept a '--remote' argument to operate on a remote machine? >> Or is this not what 'GUIX_DAEMON_SOCKET=ssh://your-target guix package >> -m manifest.scm' can already accomplish? :-) > > Currently there's no ssh connection caching, so using GUIX_DAEMON_SOCKET > can be quite slow, I normally allow 5-10 minutes for a profile. That > works best when you can't use guix copy to send derivations over. > > The profile effectively already exists, it doesn't need to be computed > on each machine. It does seem more like deploy: take this profile, send > it to that machine, and activate it there. `guix deploy` already takes > a file, the file could have a profile (or home config?) and a location > for the profile. And a user. That's some idea I suggested earlier (add integration form 'guix home' configs to an operating system definition). That has merit on its own, but wouldn't solve Ricardo's use case, which is to deploy a profile on a *foreign* distribution (not Guix System). -- Thanks, Maxim
Re: Divvying up service definitions
Hi Bruno, On Thu, Oct 26 2023, Bruno Victal wrote: > Agreed, the crux of the discussion is splitting service-definitions into > their own modules. In the current naming scheme, the module (gnu services configuration) is an outlier: It does not ship "configuration services" but provides facilities that help build services. Perhaps the module should move elsewhere. Kind regards Felix
