Re: Updating mumi on berlin

Hello zimoun, zimoun writes: > Hi Thiago, > > On Fri, 06 May 2022 at 00:22, Thiago Jung Bauermann > wrote: > >> I didn't go that route because I don't like disabling tests without >> understanding why they fail and it took me a while to understand the >> zombie root cause. In addition to tha

Re: RFC: Configurable placing of the ~/.guix-home symlink

> It would be up to users to make sure then that whatever “home > environment profile” they use has its startup files actually loaded. What do you mean by that? The user in this case must ensure that $HOME_ENVIRONMENT/{setup-environment,on-first-login} are loaded?

Re: python-cryptography and rust [was: Re: ‘staging’ branch is open!]

Hi Efraim, (+Cc: Marius.) Efraim Flashner skribis: > python-cryptography now depends on rust. We're going to need 3.4.8 from > the 3.4 series for the other architectures. Currently > python-cryptography@36.0.1 is gating about 3000 packages. Yes, so what do you mean? Should we keep the old 3.3

Re: cleaning up some minor things

Hello, Ricardo Wurmus skribis: > “guix/scripts/pull.scm” imports WITH-FILE-LOCK/NO-WAIT from (guix build > syscalls) but doesn’t use it. Can we remove that? Yes. > “guix/store/deduplication.scm” defines a variant of DUMP-PORT with this > comment: > >;; TODO: Remove once 'dump-port' in (gu

Re: Mumi, public-inbox and tools

Hi! Ricardo Wurmus skribis: > Arun Isaac writes: > >> Hi Ludo, >> >>> The attached super-early-draft ‘guix review’ script fetches mboxes from >>> mumi—that part is OK. >> >> I like the idea! But, could we put this in mumi instead of guix? That >> way, other packages that use debbugs/mumi (skrib

Re: Updating mumi on berlin

Hi, Thiago Jung Bauermann skribis: > Ludovic Courtès writes: > >> Hi, >> >> Maxim Cournoyer skribis: >> >>> Yes, that would be the correct and general solution (I hope you get to >>> fix it, else I may look into it in some time). Workarounds currently in >>> use can be seen in our mutter pack

Re: ‘staging’ branch is open!

Hi Guix! Ludovic Courtès skribis: > zimoun skribis: > >> The schedule could be: >> >> + freeze the ’staging’ branch on the Sun May, 8th >> + fix until it is ready, targeting the Sun, May 22th >> + prepare a release for June > > So now I look ridiculous for being derailed myself… But yes, so

Re: Should Guix Home daemonize Shepherd?

On Sun, 15 May 2022 at 15:20, Ludovic Courtès wrote: > > The extra ‘setsid’ call LGTM, but why add an extra ‘primitive-fork’ > call? Sorry, but don't use this patch. The setsid call makes things slightly better but if Shepherd prints anything (for example, a service's status update), it will cras

Re: Should Guix Home daemonize Shepherd?

Hi, Kevin Boulain skribis: > First, Guix Home correctly tells the user Shepherd to daemonize itself > via an 'action' > (https://git.savannah.gnu.org/cgit/guix.git/tree/gnu/home/services/shepherd.scm#n64) > but, from my understanding, the daemonization process is missing at > least a setsid call

Re: RFC: Configurable placing of the ~/.guix-home symlink

Hi, I wonder if a ‘-p’ switch similar to that of ‘guix package’ would make sense for ‘guix home’? It would be up to users to make sure then that whatever “home environment profile” they use has its startup files actually loaded. Ludo’.