Re: Building, packaging and updating Guix with confidence

Hi zimoun, zimoun writes: > Now #53210 [1] is closed, it improves the situation, right? Is it > enough for the C extension you are working on? > > 1: Well, wrt. the C extension, it doesn't really improve much, there's still the issue of having both build

Re: Building, packaging and updating Guix with confidence

Hi Bengt, On mar., 26 juil. 2022 at 03:09, Bengt Richter wrote: > I naively don't buy the rationale against a non-root guix daemon :) For sure, we can imagine many other designs than the current implemented one. However, at one point or the other, “something with privileges” is required, no?

Re: Building, packaging and updating Guix with confidence

Hi Josselin, Thank you for the clear explanations. On mer., 06 juil. 2022 at 22:01, Josselin Poiret wrote: [...] > What I personally think, is that we should rationalize the way we > interact with Guix source: a running Guix should always be able to hold > a reference to its source. The guix

Re: Building, packaging and updating Guix with confidence

Hi Josselin, tl;dr: I naively don't buy the rationale against a non-root guix daemon :) Skip to [2] if tl ;) On +2022-07-21 18:10:53 +0200, Josselin Poiret wrote: > Hello, > > b...@bokr.com writes: > > Naively: > > > > Why does "the" guix daemon per se need root access at all? > > The main thin

Re: Building, packaging and updating Guix with confidence

On 21-07-2022 18:10, Josselin Poiret wrote: b...@bokr.com writes: Naively: Why does "the" guix daemon per se need root access at all? The main thing is that all files in the store end up being written by the guix daemon user. So if we want the files to be easily substitutable, they'd need t

Re: Building, packaging and updating Guix with confidence

Hello, b...@bokr.com writes: > Naively: > > Why does "the" guix daemon per se need root access at all? The main thing is that all files in the store end up being written by the guix daemon user. So if we want the files to be easily substitutable, they'd need to have a fixed uid/gid, and the only

Re: Building, packaging and updating Guix with confidence

Hi! I’m late to the party, but I like your thoughtful message. Josselin Poiret skribis: > What I personally think, is that we should rationalize the way we > interact with Guix source: a running Guix should always be able to hold > a reference to its source. The guix package or future equivale

Re: Building, packaging and updating Guix with confidence

Hi Josselin, I have some naive questions below :) On +2022-07-07 16:34:17 +0200, Josselin Poiret wrote: > Hello, > > Zhu Zihao writes: > > > If your foreign function use case is very trivial? Why not give Guile > > dynamic FFI a try? > > That could be another option, but I'd like to have autoc

Re: Building, packaging and updating Guix with confidence

Hello, Zhu Zihao writes: > If your foreign function use case is very trivial? Why not give Guile > dynamic FFI a try? That could be another option, but I'd like to have autoconf be able to detect whether the target supports things like posix_spawn and getrlimit, which I use in the code. > It's

Re: Building, packaging and updating Guix with confidence

Josselin Poiret writes: > In the second case, I am in the process of adding a very simple Guile C > extension to Guix that only requires to wrap a simple libc function. > The C code itself took approx. 5% of my time on it, while adding the > magical invocations for the Autotools took 35%, and no