Re: mumi web server bugs [was "`mumi send-email' means no more debbugs dance to send multiple patches"]

[Arun Isaac]

Hi Andreas,

> When I start it, it runs on 0.0.0.0, port 1.2.3.4; should it not choose
> a sensible default, such as localhost and 8080?

I agree. A patch setting the defaults to localhost and 8080 is
welcome. Would you like to give it a shot? If not, could you register
these in our bug tracker so that someone else can address these later?

> Running
>mumi web --address=localhost --port=8080
> complains that it does not know localhost.
> When I use 127.0.0.1 instead, it starts.

Yes, mumi does not know to resolve the name localhost to
127.0.0.1. Again, patches fixing this are welcome.

This problem does pop up anywhere we have guile web server programs. In
tissue[1], one of my guile web server projects, I had to write a lot of
code to teach it to run correctly on IPv4 addresses, IPv6 addresses and
on Unix sockets. It would be practical if Guile (or a Guile library)
provided some help in this regard. Or, am I expecting Scheme to be more
unminimal? ;-)

[1]: https://tissue.systemreboot.net/

> But it complains about
>  1. : "DatabaseOpeningError: Couldn't stat 
> '/var/mumi/db/mumi.xapian' (No such file or directory)"
>
> I wondered if I needed to "mumi fetch" first (in that case, there could
> be a more friendly error message).
>
> But "mumi fetch" fails; it complains about a missing file
> /var/mumi/data/spool/index.db.realtime
> (which may be missing because as non-root I cannot create it).
> Could this be moved to .mumi or .cache/mumi?

When hacking on mumi, I put the data directory in the checkout of my
local mumi git repo itself. To make mumi look for the data directory in
the current directory, you need to set the MUMI_UNINSTALLED environment
variable. See the code about db-dir in mumi/config.scm.in in the mumi
repo. This should of course be documented, perhaps in a HACKING file in
the mumi repo. Patches are welcome, as always!

But, the larger issue is that you actually need the Debbugs data to hack
on mumi. Currently, our mumi deployment is only able to get this data
via rsync from the Debbugs server and because the IP of our mumi server
is explicitly allowed to do so by the Debbugs admins. We should
distribute this data so that people can hack on mumi. But, is it ok to
do so considering that we are talking about raw email messages with
headers and everything? This may be considered private information. I
would think it is ok because Debbugs already exposes raw email messages
via its web interface. But, mumi data is different in that it is in bulk
and constitutes privileged access to the Debbugs server. We should
discuss this question as a community, and decide on the best way
forward. This question is very important to enable more people to hack
on mumi.

> Anyway, thanks for moving us forward with our tooling, which I think is
> currently our biggest problem.

A pleasure, as always! :-)

Cheers!
Arun

Re: `mumi send-email' means no more debbugs dance to send multiple patches

[Arun Isaac]

Hi John,

> I just tried it out and it worked smoothly for sending 2 patches to an
> existing bug. However, it was sent only directly to the bug address,
> not being aware I guess of anyone that had submitted or since been
> CC'ed to the thread.
>
> Is there anything we can do here? I learned about the useful "wide
> reply" when using debbugs in Emacs and presumably mumi can/does know
> about all addresses on the bug. So hopefully this wishlist item won't
> be too difficult.

This is definitely a nice feature to have. For now, I put in the other
addresses as Cc when creating the patch using `git format-patch'. Should
we build this feature into `mumi send-email' or should we create a
separate `mumi format-patch' command that will create a patch with the
correct Cc and with other necessary options passed to `git
format-patch'? The other necessary options (think options like `-1 -a
--base=auto' as recommended in the Guix manual at "(guix) Sending a
Patch Series") could be configured in .mumi/config allowing different
projects using mumi to recommend different options.

Either way, patches to mumi are always welcome! ;-)

Regards,
Arun

Re: `mumi send-email' means no more debbugs dance to send multiple patches

[Arun Isaac]

Hi Josselin,

> My mails usually take less that 30 seconds to get a reply from debbugs.
> I don't remember how long it took yesterday for the issue to appear on
> mumi though, but more than the 15 retries of mumi send-email (I manually
> checked).

Could you link to the specific email message that you tried sending with
`mumi send-email'? Debbugs provides the complete email message in mbox
format. The email headers should have timestamps we can look at to
ascertain how long it took. I am hoping that this was a one-off spurious
delay somewhere in the email system. I would certainly encourage you to
try using `mumi send-email' again to see if the problem persists. If it
does, we should certainly try and do something about it.

Regards,
Arun

Re: `mumi send-email' means no more debbugs dance to send multiple patches

[Arun Isaac]

> This could be changed.  We don’t need to wait for the email to arrive on
> the mumi server; could we ask debbugs directly for the email?  (If we
> can’t ask for the mail we could ask for newest bugs and check if that
> contains the email.)

`mumi send-email' polls mumi's /msg-id endpoint to find if an email has
reached the mumi server. I am not sure if the debbugs API allows us to
query for a particular email using its message ID. If debbugs does allow
it, we could modify mumi's /msd-id endpoint to call the debbugs API in
addition to checking its own local storage.

[PATCH] gnu: guitarix: Update to 0.44.1.

[John Kehayias]

Hi Felix,

On Wed, Apr 26, 2023 at 02:57 PM, Felix Lechner via \"Development of
GNU Guix and the GNU System distribution.\" wrote:

> Hi,
>
> With a recent checkout of Guix, guitarix fails to build from source.
> It may be a Python issue. A pertinent excerpt of the log is below.
>
> Without a patch ready, I wasn't sure where and how to file this report. 
> Thanks!
>

The usual bug-g...@gnu.org list will do just fine I would say.

In any event, I'm cc'ing the patch list with a quick patch that
updates the package which builds fine for me locally; I didn't test
running it though. I also updated to gexps and removed the
native-inputs label. Since this was an update and the package
currently doesn't build, I put it as one patch, but maybe it should be
split up? I'm not sure (I think usually as separate commit, but here a
fix/update for broken package seemed opportune), feel free to chime in
anyone. I also did this super quickly, apologies for any silly
mistakes.

Thanks for the report!
John

> Kind regards
> Felix
>
> * * *
>
> [ 477/1048] Compiling src/gx_head/engine/gx_resampler.cpp
> In file included from
> /gnu/store/nb40pwd37v6i1g4b1fq4l6q4h9px3asr-glib-2.72.3/include/glib-2.0/glib/gthread.h:32,
>  from
> /gnu/store/nb40pwd37v6i1g4b1fq4l6q4h9px3asr-glib-2.72.3/include/glib-2.0/glib/gasyncqueue.h:32,
>  from
> /gnu/store/nb40pwd37v6i1g4b1fq4l6q4h9px3asr-glib-2.72.3/include/glib-2.0/glib.h:32,
>  from
> /gnu/store/nb40pwd37v6i1g4b1fq4l6q4h9px3asr-glib-2.72.3/include/glib-2.0/glib/gi18n.h:21,
>  from
> /gnu/store/cbjgz6f8nrb7804nnmmlvpd4y78p8zf3-glibmm-2.64.5/include/glibmm-2.4/glibmm/i18n.h:23,
>  from ../src/headers/engine.h:43,
>  from ../src/gx_head/engine/gx_resampler.cpp:27:
> ../src/headers/gx_system.h: In function ‘bool
> gx_system::atomic_compare_and_exchange(volatile int*, int, int)’:
> /gnu/store/nb40pwd37v6i1g4b1fq4l6q4h9px3asr-glib-2.72.3/include/glib-2.0/glib/gatomic.h:163:44:
> error: invalid conversion from ‘volatile void*’ to ‘void*’
> [-fpermissive]
>   163 | __atomic_compare_exchange_n ((atomic), _oldval,
> (newval), FALSE, __ATOMIC_SEQ_CST, __ATOMIC_SEQ_CST) ? TRUE : FALSE; \
>   |^~
>   ||
>   |volatile void*
> ../src/headers/gx_system.h:115:12: note: in expansion of macro
> ‘g_atomic_int_compare_and_exchange’
>   115 | return g_atomic_int_compare_and_exchange(p, oldv, newv);
>   |^
>
> In file included from
> /gnu/store/nb40pwd37v6i1g4b1fq4l6q4h9px3asr-glib-2.72.3/include/glib-2.0/glib/gthread.h:32,
>  from
> /gnu/store/nb40pwd37v6i1g4b1fq4l6q4h9px3asr-glib-2.72.3/include/glib-2.0/glib/gasyncqueue.h:32,
>  from
> /gnu/store/nb40pwd37v6i1g4b1fq4l6q4h9px3asr-glib-2.72.3/include/glib-2.0/glib.h:32,
>  from
> /gnu/store/3cl87br64f94fr6w45cpwzyn1kv9ma2p-gtk+-3.24.37/include/gtk-3.0/gdk/gdkconfig.h:8,
>  from
> /gnu/store/3cl87br64f94fr6w45cpwzyn1kv9ma2p-gtk+-3.24.37/include/gtk-3.0/gdk/gdk.h:30,
>  from
> /gnu/store/3cl87br64f94fr6w45cpwzyn1kv9ma2p-gtk+-3.24.37/include/gtk-3.0/gtk/gtk.h:30,
>  from ../src/headers/guitarix.h:35,
>  from ../src/gx_head/gui/gx_main_boxes.cpp:25:
> ../src/headers/gx_system.h: In function ‘bool
> gx_system::atomic_compare_and_exchange(volatile int*, int, int)’:
> /gnu/store/nb40pwd37v6i1g4b1fq4l6q4h9px3asr-glib-2.72.3/include/glib-2.0/glib/gatomic.h:163:44:
> error: invalid conversion from ‘volatile void*’ to ‘void*’
> [-fpermissive]
>   163 | __atomic_compare_exchange_n ((atomic), _oldval,
> (newval), FALSE, __ATOMIC_SEQ_CST, __ATOMIC_SEQ_CST) ? TRUE : FALSE; \
>   |^~
>   ||
>   |volatile void*
> ../src/headers/gx_system.h:115:12: note: in expansion of macro
> ‘g_atomic_int_compare_and_exchange’
>   115 | return g_atomic_int_compare_and_exchange(p, oldv, newv);
>   |^
>
> In file included from
> /gnu/store/nb40pwd37v6i1g4b1fq4l6q4h9px3asr-glib-2.72.3/include/glib-2.0/glib/gthread.h:32,
>  from
> /gnu/store/nb40pwd37v6i1g4b1fq4l6q4h9px3asr-glib-2.72.3/include/glib-2.0/glib/gasyncqueue.h:32,
>  from
> /gnu/store/nb40pwd37v6i1g4b1fq4l6q4h9px3asr-glib-2.72.3/include/glib-2.0/glib.h:32,
>  from
> /gnu/store/3cl87br64f94fr6w45cpwzyn1kv9ma2p-gtk+-3.24.37/include/gtk-3.0/gdk/gdkconfig.h:8,
>  from
> /gnu/store/3cl87br64f94fr6w45cpwzyn1kv9ma2p-gtk+-3.24.37/include/gtk-3.0/gdk/gdk.h:30,
>  from
> 

Guitarix FTBFS

[Development of GNU Guix and the GNU System distribution.]

Hi,

With a recent checkout of Guix, guitarix fails to build from source.
It may be a Python issue. A pertinent excerpt of the log is below.

Without a patch ready, I wasn't sure where and how to file this report. Thanks!

Kind regards
Felix

* * *

[ 477/1048] Compiling src/gx_head/engine/gx_resampler.cpp
In file included from
/gnu/store/nb40pwd37v6i1g4b1fq4l6q4h9px3asr-glib-2.72.3/include/glib-2.0/glib/gthread.h:32,
 from
/gnu/store/nb40pwd37v6i1g4b1fq4l6q4h9px3asr-glib-2.72.3/include/glib-2.0/glib/gasyncqueue.h:32,
 from
/gnu/store/nb40pwd37v6i1g4b1fq4l6q4h9px3asr-glib-2.72.3/include/glib-2.0/glib.h:32,
 from
/gnu/store/nb40pwd37v6i1g4b1fq4l6q4h9px3asr-glib-2.72.3/include/glib-2.0/glib/gi18n.h:21,
 from
/gnu/store/cbjgz6f8nrb7804nnmmlvpd4y78p8zf3-glibmm-2.64.5/include/glibmm-2.4/glibmm/i18n.h:23,
 from ../src/headers/engine.h:43,
 from ../src/gx_head/engine/gx_resampler.cpp:27:
../src/headers/gx_system.h: In function ‘bool
gx_system::atomic_compare_and_exchange(volatile int*, int, int)’:
/gnu/store/nb40pwd37v6i1g4b1fq4l6q4h9px3asr-glib-2.72.3/include/glib-2.0/glib/gatomic.h:163:44:
error: invalid conversion from ‘volatile void*’ to ‘void*’
[-fpermissive]
  163 | __atomic_compare_exchange_n ((atomic), _oldval,
(newval), FALSE, __ATOMIC_SEQ_CST, __ATOMIC_SEQ_CST) ? TRUE : FALSE; \
  |^~
  ||
  |volatile void*
../src/headers/gx_system.h:115:12: note: in expansion of macro
‘g_atomic_int_compare_and_exchange’
  115 | return g_atomic_int_compare_and_exchange(p, oldv, newv);
  |^

In file included from
/gnu/store/nb40pwd37v6i1g4b1fq4l6q4h9px3asr-glib-2.72.3/include/glib-2.0/glib/gthread.h:32,
 from
/gnu/store/nb40pwd37v6i1g4b1fq4l6q4h9px3asr-glib-2.72.3/include/glib-2.0/glib/gasyncqueue.h:32,
 from
/gnu/store/nb40pwd37v6i1g4b1fq4l6q4h9px3asr-glib-2.72.3/include/glib-2.0/glib.h:32,
 from
/gnu/store/3cl87br64f94fr6w45cpwzyn1kv9ma2p-gtk+-3.24.37/include/gtk-3.0/gdk/gdkconfig.h:8,
 from
/gnu/store/3cl87br64f94fr6w45cpwzyn1kv9ma2p-gtk+-3.24.37/include/gtk-3.0/gdk/gdk.h:30,
 from
/gnu/store/3cl87br64f94fr6w45cpwzyn1kv9ma2p-gtk+-3.24.37/include/gtk-3.0/gtk/gtk.h:30,
 from ../src/headers/guitarix.h:35,
 from ../src/gx_head/gui/gx_main_boxes.cpp:25:
../src/headers/gx_system.h: In function ‘bool
gx_system::atomic_compare_and_exchange(volatile int*, int, int)’:
/gnu/store/nb40pwd37v6i1g4b1fq4l6q4h9px3asr-glib-2.72.3/include/glib-2.0/glib/gatomic.h:163:44:
error: invalid conversion from ‘volatile void*’ to ‘void*’
[-fpermissive]
  163 | __atomic_compare_exchange_n ((atomic), _oldval,
(newval), FALSE, __ATOMIC_SEQ_CST, __ATOMIC_SEQ_CST) ? TRUE : FALSE; \
  |^~
  ||
  |volatile void*
../src/headers/gx_system.h:115:12: note: in expansion of macro
‘g_atomic_int_compare_and_exchange’
  115 | return g_atomic_int_compare_and_exchange(p, oldv, newv);
  |^

In file included from
/gnu/store/nb40pwd37v6i1g4b1fq4l6q4h9px3asr-glib-2.72.3/include/glib-2.0/glib/gthread.h:32,
 from
/gnu/store/nb40pwd37v6i1g4b1fq4l6q4h9px3asr-glib-2.72.3/include/glib-2.0/glib/gasyncqueue.h:32,
 from
/gnu/store/nb40pwd37v6i1g4b1fq4l6q4h9px3asr-glib-2.72.3/include/glib-2.0/glib.h:32,
 from
/gnu/store/3cl87br64f94fr6w45cpwzyn1kv9ma2p-gtk+-3.24.37/include/gtk-3.0/gdk/gdkconfig.h:8,
 from
/gnu/store/3cl87br64f94fr6w45cpwzyn1kv9ma2p-gtk+-3.24.37/include/gtk-3.0/gdk/gdk.h:30,
 from
/gnu/store/3cl87br64f94fr6w45cpwzyn1kv9ma2p-gtk+-3.24.37/include/gtk-3.0/gtk/gtk.h:30,
 from ../src/headers/guitarix.h:35,
 from ../src/gx_head/gui/gx_main_midi.cpp:25:
../src/headers/gx_system.h: In function ‘bool
gx_system::atomic_compare_and_exchange(volatile int*, int, int)’:
/gnu/store/nb40pwd37v6i1g4b1fq4l6q4h9px3asr-glib-2.72.3/include/glib-2.0/glib/gatomic.h:163:44:
error: invalid conversion from ‘volatile void*’ to ‘void*’
[-fpermissive]
  163 | __atomic_compare_exchange_n ((atomic), _oldval,
(newval), FALSE, __ATOMIC_SEQ_CST, __ATOMIC_SEQ_CST) ? TRUE : FALSE; \
  |^~
  ||
  |volatile void*
../src/headers/gx_system.h:115:12: note: in expansion of macro
‘g_atomic_int_compare_and_exchange’
  115 | return g_atomic_int_compare_and_exchange(p, oldv, newv);
  |

Re: `mumi send-email' means no more debbugs dance to send multiple patches

[John Kehayias]

Hi Arun,

On Mon, Apr 24, 2023 at 04:12 PM, Arun Isaac wrote:

> Hi all,
>
> mumi, the software powering our debbugs frontend at
> , now also comes with a command-line
> interface. At the moment, the new command-line interface allows
> searching for issues, and sending patches. Most notably, it frees us
> from the debbugs dance required for sending multiple patches!
>

Thanks for this and the detailed instructions!

I just tried it out and it worked smoothly for sending 2 patches to an
existing bug. However, it was sent only directly to the bug address,
not being aware I guess of anyone that had submitted or since been
CC'ed to the thread.

Is there anything we can do here? I learned about the useful "wide
reply" when using debbugs in Emacs and presumably mumi can/does know
about all addresses on the bug. So hopefully this wishlist item won't
be too difficult.

Thanks again, will be happy to use this on the 20 patch series I'm
about to send...

John

Greater bug specifics for automatic team assignment

[Development of GNU Guix and the GNU System distribution.]

Hi,

As a corollary to the upcoming teams approach, should we tag bugs in
Debbugs so that their respective teams can find them?

Kind regards
Felix

Re: Emacs next variants

[Mekeor Melire]

2023-03-10 16:39 zimon.touto...@gmail.com:

As far I know, this branch does not contain the feature 
Tree-sitter. Instead, the feature Tree-sitter is in the branch 
"master", which will be branched later as Emacs 30 and somehow 
will be the next next release of Emacs.


2023-03-12 12:47 and...@trop.in:

Sure, I think [...] after emacs-30 release we will include 
tree-sitter in emacs package itself and also we will be able to 
move emacs-next-pgtk to emacs-pgtk.


Emacs 29.1 will support tree-sitter. This mail-thread seems to 
have been mislead by the wrong assumption that Emacs 30 will be 
the first version to support tree-sitter.


Feel free to check "etc/NEWS" within branch "emacs-29" of Emacs' 
repository and correct me if I'm wrong: 
https://git.savannah.gnu.org/cgit/emacs.git/tree/etc/NEWS?h=emacs-29#n36

Re: Blog post on the Full-Source Bootstrap

[Tobias Platen]

This looks good, I am interested in doing a port to the POWER ISA.
Currently on my OrangeCrab I only have one small C program running,
coldboot. Everything from the HDL to the BIOS should be Full-Source.

https://git.libre-soc.org/?p=ls2.git;a=blob;f=coldboot/coldboot.c 

Tobias

On Wed, 2023-04-26 at 16:12 +0200, Janneke Nieuwenhuizen wrote:
> Hello Guix!
> 
> Now that core-updates has been merged, the Full-Source Bootstrap has
> come to Guix!  This means we're building packages from source all the
> way down.  Read all about it in this new post:
> 
>  
> https://gnu.org/software/guix/blog/2023/the-full-source-bootstrap-building-from-source-all-the-way-down/
> 
> Janneke & Ludo
> 

Blog post on the Full-Source Bootstrap

[Janneke Nieuwenhuizen]

Hello Guix!

Now that core-updates has been merged, the Full-Source Bootstrap has
come to Guix!  This means we're building packages from source all the
way down.  Read all about it in this new post:

  
https://gnu.org/software/guix/blog/2023/the-full-source-bootstrap-building-from-source-all-the-way-down/

Janneke & Ludo

-- 
Janneke Nieuwenhuizen   | GNU LilyPond https://LilyPond.org
Freelance IT https://www.JoyOfSource.com | Avatar® https://AvatarAcademy.com

Re: `mumi send-email' means no more debbugs dance to send multiple patches

[Andreas Enge]

Hello Arun,

this looks all very nice, thanks a lot!

I have a few "bug reports" about "mumi web".

When I start it, it runs on 0.0.0.0, port 1.2.3.4; should it not choose
a sensible default, such as localhost and 8080? Running
   mumi web --address=localhost --port=8080
complains that it does not know localhost.
When I use 127.0.0.1 instead, it starts.
But it complains about
 1. : "DatabaseOpeningError: Couldn't stat 
'/var/mumi/db/mumi.xapian' (No such file or directory)"

I wondered if I needed to "mumi fetch" first (in that case, there could
be a more friendly error message).

But "mumi fetch" fails; it complains about a missing file
/var/mumi/data/spool/index.db.realtime
(which may be missing because as non-root I cannot create it).
Could this be moved to .mumi or .cache/mumi?

Anyway, thanks for moving us forward with our tooling, which I think is
currently our biggest problem.

Andreas