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 that, without the testsuite passing I >> didn't feel confident that I would be proposing a good enough package >> because virtually the only part of public-inbox that I use is lei >> itself. What if there was a regression in other parts of it and I didn't >> notice because I use so little? >> >> But I wouldn't mind disabling the part that checks that lei-daemon is >> truly gone, or even the whole testsuite if that is too complicated. >> >> On the other hand, the preferred solution would be the workaround >> pointed out by Maxim, where tini is used to run the testsuite and reap >> its sub-processes. I can probably take a stab at it over the weekend if >> no one beats me to it. > > For sure. For it is worth, I try to keep in mind, :-) > > Now is better than never. > Although never is often better than *right* now. > > – The Zen of Python, by Tim Peters – I liked the plot twist in this one. :-) > and > > Perfect is the enemy of good > > – commonly attributed to Voltaire – Yeah, I can easily fall into the trap of trying to get things just right and taking too long to finish my projects… Though in this case not feeling confident enough about the updated package due to not being able to run the tests was a real concern for me. Since then I have been able to run the testsuite locally and it passes, so I have just posted a patch series updating public-inbox: https://issues.guix.gnu.org/55436 Though that one is still with tests disabled (in the spirit of the quotes above!). I have a bit more polishing to do before I can send the follow-up patches to enable tests. For now, you can find them here if you're curious: https://gitlab.com/bauermann/guix/-/commits/public-inbox-update -- Thanks Thiago
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.1 for use on non-x86_64 platforms? Would that even work? Besides, since mrustc was updated on ‘staging’, does that new version better support platforms other than x86_64? Thanks for the heads-up, Ludo’.
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 (guix build utils) has an optional > 'len' >;; parameter. > > The variant in (guix build utils) already supports that optional > argument. Can we remove the variant in (guix store deduplication)? Yes, looks like it. Go for it! Thanks, Ludo’.
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 (skribilo comes to mind), can >> benefit from it as well. Something like >> >> $ guix shell mumi -- mumi review 54874 > > I also think it would be a good fit for mumi. Yes, there are good arguments for having it in mumi. One of them is that we can make the server and client-side work hand-in-hand. An argument in favor of having such a tool in Guix is that we could have Guix-specific tooling layered on top, such as listing the set of new/upgraded packages, automatically building them, things like that. But look: we could have a generic ‘mumi review’ that a hypothetical ‘guix review’ could use as a library and extend. At any rate, anything will be better than the status quo, so I’m all for starting with a simple ‘mumi review’! Perhaps we should organize a hacking session or something eventually? Thanks, Ludo’.
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 package definition (it's a bit convoluted,
>>> having to fork a process in which we set the child reaping property and
>>> invoke the test suite via tini, acting as a fake PID 1).
>>
>> The Guile process running the build script (with the build phases) runs
>> as PID 1. So how about doing one of these:
>>
>> 1. Add a final phase that does (waitpid WAIT_ANY).
>>
>> 2. Add a SIGCHLD handler that calls ‘waitpid’.
>>
>> I suspect the former is enough.
>
> I don't think it is, unless I'm misunderstanding something. The
> testsuite expects the daemon to die within a few seconds of sending it
> the quit command (which it does several times over the course of a
> number of the tests), so having it reaped at the end of the build
> process won't help.
I see, makes sense.
> I tried the latter a couple of weeks ago and it didn't work either,
> though it's highly likely that I did something wrong in my Scheme code.
> I also didn't use the 1-second timer hack so perhaps that was it.
>
> I just tested this (adapted from the mutter package) and it worked:
>
> @@ -4137,6 +4142,26 @@ (define-public public-inbox
> ;; the builder.
> (substitute* "t/httpd-unix.t"
> (("^SKIP: \\{") "SKIP: { skip('Guix');"
> + (replace 'check
> + (lambda* (#:key target
> + (tests? (not target)) (test-flags '())
> + #:allow-other-keys)
> + (if tests?
> + (match (primitive-fork)
> + (0 ;child process
> +(set-child-subreaper!)
> +;; Use tini so that signals are properly handled and
> +;; doubly-forked processes get reaped; otherwise,
> +;; lei-daemon is kept as a zombie and the testsuite
> +;; fails thinking that it didn't quit as it should.
> +(apply execlp "tini" "--"
> + "make" "check" test-flags))
How does a basic SIGCHLD handler fare?
(sigaction SIGCHLD
(lambda _ (false-if-exception (waitpid WAIT_ANY WNOHANG
>> Eventually, we should do one of these in gnu-build-system.scm, as in:
>>
>> https://issues.guix.gnu.org/30948#2
>>
>> WDYT?
>
> I agree, possibly with the 1-second timer hack as well.
Heh, I hate that one, we need to find a better solution.
Thanks,
Ludo’.
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, something > like this offset by one (or two?) week would be awesome. I propose freezing tomorrow evening, Monday 16th ca. 8PM CEST. How does that sound? >From there we can start testing and fixing things. The branch has updates for a few important packages and partial ungrafting (util-linux and openssl grafts remain). Thanks, Ludo’.
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 crash (IIRC) because stdout still references the terminal. Ideally, exec-command (from the same file) could be used to also close the open file descriptors (including the terminal's) but that's done too late and would also close the control socket (and probably other important stuff). I wasn't quite sure how to work around that while keeping the existing behavior. On Fri, 6 May 2022 at 10:07, Andrew Tropin wrote: > > Actually, XDG_RUNTIME_DIR can be provided not only by elogind, but also > by pam_rundir or something similar, however in general it's true, > runtime dir will be removed when session ends. That was my thought at first (for example https://github.com/ifreund/dumb_runtime_dir can create the directory but not remove it, solving a part of the issue). Sadly, we lose elogind's built-in power management and some other packages depend on it anyway.
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
> (https://git.savannah.gnu.org/cgit/shepherd.git/tree/modules/shepherd/service.scm#n1421),
> see the attached 'shepherd-setsid.patch'. This fixes the Shepherd
> dying when exiting the SSH session or the Shepherd catching the ^C.
> I guess it should also close std{in,out,err} like it's done for the
> regular services
> (https://git.savannah.gnu.org/cgit/shepherd.git/tree/modules/shepherd/service.scm#n806)
> but this answers a part of my initial post.
[...]
> Detach from the controlling terminal when daemonizing
>
> https://lists.gnu.org/archive/html/guix-devel/2022-03/msg00040.html
>
> diff --git c/modules/shepherd/service.scm w/modules/shepherd/service.scm
> index ad8608b..62f97bc 100644
> --- c/modules/shepherd/service.scm
> +++ w/modules/shepherd/service.scm
> @@ -1420,8 +1420,12 @@ we want to receive these signals."
>(else
> (if (zero? (primitive-fork))
> (begin
> - (catch-system-error (prctl PR_SET_CHILD_SUBREAPER 1))
> - #t)
> + (setsid)
> + (if (zero? (primitive-fork))
> + (begin
> + (catch-system-error (prctl PR_SET_CHILD_SUBREAPER 1))
> + #t)
> + (primitive-exit 0)))
The extra ‘setsid’ call LGTM, but why add an extra ‘primitive-fork’
call?
Thanks in advance,
Ludo’.
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’.
