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
