Subject: bug#74395: closed (Re: 'mumi send-email' fails to detect created issue number)

From: Maxim Cournoyer <[email-masked]>
Date: Wed, 19 Mar 2025 21:43:10 +0900

Hi Arun,

I tried to use 'mumi send-email' today, and unfortunately it didn't
work:

--8<---------------cut here---------------start------------->8---
$ mumi send-email libvirt-uefi/*.patch
git send-email --to=[email-masked] libvirt-uefi/0000-cover-letter.patch
libvirt-uefi/0000-cover-letter.patch

[...]

Result: 250 
Server has not yet received our email. Will retry in 60 seconds. 14 retries remaining.
Server has not yet received our email. Will retry in 60 seconds. 13 retries remaining.
Server has not yet received our email. Will retry in 60 seconds. 12 retries remaining.
Server has not yet received our email. Will retry in 60 seconds. 11 retries remaining.
Server has not yet received our email. Will retry in 60 seconds. 10 retries remaining.
Server has not yet received our email. Will retry in 60 seconds. 9 retries remaining.
Server has not yet received our email. Will retry in 60 seconds. 8 retries remaining.
Server has not yet received our email. Will retry in 60 seconds. 7 retries remaining.
Server has not yet received our email. Will retry in 60 seconds. 6 retries remaining.
Server has not yet received our email. Will retry in 60 seconds. 5 retries remaining.
Server has not yet received our email. Will retry in 60 seconds. 4 retries remaining.
Server has not yet received our email. Will retry in 60 seconds. 3 retries remaining.
Server has not yet received our email. Will retry in 60 seconds. 2 retries remaining.
Server has not yet received our email. Will retry in 60 seconds. 1 retries remaining.
Server has not yet received our email. Will retry in 60 seconds. 0 retries remaining.
Mail not acknowledged by issue tracker. Giving up.
--8<---------------cut here---------------end--------------->8---

[...]

>> Should we also raise the frequency of the rsync job? Currently it's
>> every 5 minutes; we could make try perhaps every minute, but it should
>> block when it's already running. I think the new Shepherd timer API
>> would allow defining it as such.
>
> Ah, good point! I didn't think of that. That would be worth doing to
> further improve responsiveness.
>
> Is there a way to prevent multiple rsync instances from running at the
> same time? I understand it can be dangerous.
> https://serverfault.com/questions/332577/is-it-safe-to-running-multiple-instances-of-rsync-together
>
> Did you mean that the new Shepherd timer API has a way to achieve this
> blocking?

Yes; the make-timer-constructor has a #:wait-for-termination? argument
(defaults to #f), which would need to be set to #t.  It's documented in
(info "(shepherd) Timers").

I'll try converting the mcron in a bit, I'll let you know how it went.

-- 
Thanks,
Maxim