Re: On the naming of System and Home services modules.

On 2021-09-23 22:10, Ludovic Courtès wrote: > Hi, > > Andrew Tropin skribis: > >> However, ~(gnu home services ...)~ also looks cool, but it would be a >> little inconsistent with system services, which will have one level of >> nestiness less: ~(gnu services)~. >> >> IMO, ~(gnu home services ...

Re: Code sharing between system and home services (was Re: On the naming of System and Home services modules.)

On 2021-09-24 16:03, Maxime Devos wrote: > Xinglu Chen schreef op vr 24-09-2021 om 15:35 [+0200]: >> On Thu, Sep 23 2021, Ludovic Courtès wrote: >> >> > Hi, >> > >> > Xinglu Chen skribis: >> > >> > > Some services might be useful to have in both Guix System and Guix Home; >> > > for instance,

Re: Go importer and packages with version flags

Hi Katherine, Jack, Katherine Cox-Buday writes: > Jack Hill writes: > >> Hi Guix, > > Hey, Jack, a few thoughts. > >> While I was was working with the go importer today, it suggested I package >> go-github-com-russross-blackfriday-v2. Fair enough, except we already have a >> package for go-gith

Re: Linux-libre source code will be taken offline

On Mon, 27 Sep 2021 19:30:29 -0400 Leo Famulari wrote: > I didn't check that the files are bit-identical, but my understanding > is that the "old" revisions of the deblobbing scripts are available > here: > > https://linux-libre.fsfla.org/pub/linux-libre/releases/old/ Yes. In gen6. They have be

Re: Go importer and packages with version flags

Jack Hill writes: > Hi Guix, Hey, Jack, a few thoughts. > While I was was working with the go importer today, it suggested I package > go-github-com-russross-blackfriday-v2. Fair enough, except we already have a > package for go-github-com-russross-blackfriday. I was poking around a rust code-

Re: Code sharing between system and home services (was Re: On the naming of System and Home services modules.)

Hi, Xinglu Chen writes: > On Thu, Sep 23 2021, Ludovic Courtès wrote: > >> Hi, >> >> Xinglu Chen skribis: >> >>> Some services might be useful to have in both Guix System and Guix Home; >>> for instance, Guix System currently has a service for configuring >>> Syncthing, and I think it makes sen

Re: Linux-libre source code will be taken offline

(Sorry, for the typos.) On Tue, 28 Sept 2021 at 02:13, zimoun wrote: > even if it happens, SWH does rebuild the exact same tarball (because SWH does *NOT* rebuild the exact same tarball.

Re: Linux-libre source code will be taken offline

Hi, On Tue, 28 Sept 2021 at 01:34, Leo Famulari wrote: > Of course, adding this to the list of URIs in linux-libre-deblob-scripts > won't help users of old Guix revisions... Software Heritage and other > archives that support content-addressed lookups are the only solution > for that. I do not

Re: Linux-libre source code will be taken offline

On Mon, Sep 27, 2021 at 06:30:21PM -0400, Mark H Weaver wrote: > If we wish to preserve Guix users' ability to reproduce older systems, > we will need an 'origin' to fetch the Linux-libre deblob scripts from > that has a policy of retaining older releases, unchanged and at a fixed > location. Appa

Re: Linux-libre source code will be taken offline

On 2021-09-27, Mark H Weaver wrote: > Leo Famulari writes: > >> On Sat, Sep 04, 2021 at 01:32:16PM -0700, Jason Self wrote: >>> The scripts are not being removed and my understanding is that Guix >>> only uses the scripts anyway. >> >> Okay, that's great. We do use the scripts. > > Unfortunately,

Re: Linux-libre source code will be taken offline

Leo Famulari writes: > On Sat, Sep 04, 2021 at 01:32:16PM -0700, Jason Self wrote: >> The scripts are not being removed and my understanding is that Guix >> only uses the scripts anyway. > > Okay, that's great. We do use the scripts. Unfortunately, the older deblobbing scripts have now been remo

Go importer and packages with version flags

Hi Guix, While I was was working with the go importer today, it suggested I package go-github-com-russross-blackfriday-v2. Fair enough, except we already have a package for go-github-com-russross-blackfriday. The packages differ in their version (2.1.0 verses 2.0.1), their imputs (the imported

Re: branch core-updates-frozen updated: services: database: Change postgresql default socket.

On Mon, Sep 27 2021, Mathieu Othacehe wrote: > Hello, > >> The manual should also be updated to reflect this change. > > Fixed, thanks for the reminder. You are welcome! :-) >> Also, is there any reason for making this change on >> ‘core-updates-frozen’ rather than ‘master’? > > Yes, that's a f

Re: branch core-updates-frozen updated: services: database: Change postgresql default socket.

Hello, > The manual should also be updated to reflect this change. Fixed, thanks for the reminder. > Also, is there any reason for making this change on > ‘core-updates-frozen’ rather than ‘master’? Yes, that's a follow-up of 86cf4c039631cdf15c4c428bf4ffe52d6cbd7d4c that was pushed on core-up

Re: branch core-updates-frozen updated: services: database: Change postgresql default socket.

On 27 September 2021 15:26, guix-comm...@gnu.org wrote: > commit 502925655d1a51aad544804c8ef492a5d24e1776 > Author: Mathieu Othacehe > AuthorDate: Mon Sep 27 19:22:56 2021 + > > services: database: Change postgresql default socket. > > Adapt to the postgresql default socket directory

Building guix system

Hello very cool project, please, can you describe how to build live image of guix? With best wishes, Gh0sty

Re: minification R: build-system

I think what would be ideal is packaging the Javascript dependencies separately, then including them as inputs. I wouldn't be suprised if someone has tried this, but I don't know the history. ‐‐‐ Original Message ‐‐‐ On Monday, September 27th, 2021 at 12:28 PM, zimoun wrote: > Hi, >

minification R: build-system

Hi, Recently, the switch from uglify-js to uglifyjs raises a question if this minification should be part of the r-build-system; as suggested by Ricardo: What people think to this move? Because, currently the replacement of the minifier