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

[Arun Isaac <arunisaac@systemreboot.net>]

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. &xapian-error: "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