GNU bug report logs - #74395
'mumi send-email' fails to detect created issue number

Previous Next

Full log

Message #49 received at 74395 <at> debbugs.gnu.org (full text, mbox):

From: Maxim Cournoyer <maxim.cournoyer <at> gmail.com>
To: Arun Isaac <arunisaac <at> systemreboot.net>
Cc: 74395 <at> debbugs.gnu.org
Subject: Re: bug#74395: closed (Re: 'mumi send-email' fails to detect
 created issue number)
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=guix-patches <at> gnu.org 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

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.