1. 16

  2. 13

    As many of you know, I maintain the #lobsters IRC channel bot, Mock Turtle. That bot notifies IRC of story submissions to lobste.rs. It works by using the mailing list mode, and so runs an email server and converts incoming messages to IRC notifications.

    I’m pleased to announce that, on the release of notqmail-1.07, the bot is using notqmail to receive these messages.

    1. 8

      Some examples of feedback we’d welcome:

      • That you can’t try updating to notqmail yet, and what would make it possible for you
      • That you tried updating, and it didn’t work
      • That you tried updating, and it did work

      Hope to hear from some folks playing with this.

      1. 3

        We see new software popping out (on Github) and fading (on SourceForge) all of the time, but former software updated by different maintainers, not so often.

        I bet it gives a different feeling this way, a sense of continuity.

        1. 3

          Congratulations on the release.

          This begs a question I haven’t seen answered elsewhere though. What would be the reasons for a sysadmin to invest time and effort into (not)qmail? Other implementations (such as Postfix) seem to meet an equal standard of stability, while already providing the features you want to implement in notqmail.

          1. 3

            For the moment, we’re targeting sysadmins who already run (net)qmail. Much later, when we begin to approach feature parity with Postfix, notqmail might start being an interesting alternative. We hope that time will come. If you can’t figure out why you’d run it right now, you’re probably right :-)

            1. 2

              That makes sense, thanks :-)

          2. 2

            This was the script I was packaging netqmail with.

            #!/bin/sh -ex
            mkdir -p /var/qmail
            mkdir -p /etc/qmail
            mkdir -p "$PREFIX/bin"
            rm -rf /var/qmail/control
            ln -sf /etc/qmail /var/qmail/control
            ln -sf "$PREFIX/bin" /var/qmail
            user() {
                    if [ "$(readlink -f "$(which adduser)" | sed 's;.*/;;')" = "busybox" ]; then
                            adduser -D -s "$1" -G "$2" -h "3" "$4"
                            useradd -s "$1" -g "$2" -d "$3" "$4"
            group() {
                    if [ "$(readlink -f "$(which addgroup)" | sed 's;.*/;;')" = "busybox" ]; then
                            addgroup "$1"
                            groupadd "$1"
            ! group nofiles
            ! user "$(which true)" nofiles /var/qmail/alias alias
            ! user "$(which true)" nofiles /var/qmail qmaild
            ! user "$(which true)" nofiles /var/qmail qmaill
            ! user "$(which true)" nofiles /var/qmail qmailp
            ! group qmail
            ! user "$(which true)" qmail /var/qmail qmailq
            ! user "$(which true)" qmail /var/qmail qmailr
            ! user "$(which true)" qmail /var/qmail qmails
            ! user "$(which true)" qmail /var/qmail alias
            touch nroff
            chmod +x nroff
            export PATH="$PATH:$PWD"
            make setup
            rm -rf "$PREFIX/share/man"
            mkdir -p "$PREFIX/share"
            mv /var/qmail/man "$PREFIX/share/man"

            You might notice the extra difficulty caused by configuring users at packaging time, although more due to busybox choices and current systems heterogeneity.

            I’d gladly live fine with /etc/qmail and /bin instead of /var/qmail/control and /var/qmail/bin, but two symlinks does the trick just fine.

            Is formatting the man pages at compile time really necessary? The man command (and an nroff/groff/mandoc backend) is quite ubiquitous.

            1. 3

              The way I’ve packaged mail/qmail in pkgsrc (which is now notqmail-based), you get symlinks too:

              alias -> /etc/qmail/alias
              bin -> /opt/pkg/bin
              boot -> /opt/pkg/share/examples/qmail/boot
              control -> /etc/qmail/control
              doc -> /opt/pkg/share/doc/qmail
              man -> /opt/pkg/man
              queue -> /var/spool/qmail
              users -> /etc/qmail/users

              We intend to address FHS/hier(7) more directly in 1.08.

              In pkgsrc, I’ve patched out preformatted man pages. But for notqmail, we haven’t convinced ourselves that’s the best move. I think we’re not done noodling on how to handle docs.

              1. 2

                Neat, thank you for sharing your packaging script.

                Is formatting the man pages at compile time really necessary? The man command (and an nroff/groff/mandoc backend) is quite ubiquitous.

                It has always been true that not all platforms use or make available preformatted manpages (“catpages” with a .0 extension). qmail does absolutely install them, as you observe. One significant change that has occurred in the intervening years is platforms (e.g., OpenBSD) only supporting the mandoc macro package, and not the man macro package that the qmail documentation is written in. We can no longer assume or rely on the man macro package being available even when a platform otherwise has a working man command.

                I would like to make building the documentation optional, which would make our build-time dependency on groff optional–without rewriting the man pages we’d still have a runtime dependency on an nroff that has the man macros (groff in most cases), so the question of whether to use the mandoc/mdoc macros (now more widely supported) immediately comes up.

                Some of those questions won’t be decidable until we’re further along with FHS support, but this is an area where both practice and tooling have changed out from under qmail, and we’ll attend to that as it makes sense to do so.

                1. 2

                  I was about to suggest to provide the preformatted man pages in the release, but it might be better to be able to reproduce the entire thing everywhere.

                  Thank you for the description.