neomutt @20160916_2: chgrp fails during non-root destroot

[jhi]

Log snippet (whole log will be attached):

...
:info:destroot          { echo "Can't fix mutt_dotlock's permissions!  This is required to lock mailboxes in the mail spool directory." >&2 ; exit 1 ; } \
:info:destroot  fi
:info:destroot chgrp: you are not a member of group mail
:info:destroot Can't fix mutt_dotlock's permissions!  This is required to lock mailboxes in the mail spool directory.
:info:destroot make[4]: *** [install-exec-hook] Error 1

I am not planning to have a local mail spool, FWIW, just IMAP from gmail.

[jhi]

/opt/local/var/macports/logs/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_mail_neomutt/neomutt/main.log

[larryv (Lawrence Velázquez)]

It looks like you aren’t running MacPorts as root. Is this accurate?

[jhi]

Replying to larryv@…:

It looks like you aren’t running MacPorts as root. Is this accurate?

This is correct. I prefer to minimize root activity.

[lbschenkel (Leonardo Brondani Schenkel)]

I have attached a fix. When not building as root the port will assume you don't want to read mail from the system spool at /var/mail and it will build with --with-homespool, which turns off the dotlock functionality and allows the port to finish building.

[jhi]

Replying to leonardo.schenkel@…:

I have attached a fix. When not building as root the port will assume you don't want to read mail from the system spool at /var/mail and it will build with --with-homespool, which turns off the dotlock functionality and allows the port to finish building.

Can I test this patch somehow locally? (without an updated port from macports.org, that is)

[lbschenkel (Leonardo Brondani Schenkel)]

Yes, you can manually run port edit neomutt and add manually enter my changes as described the diff. Then just run a port install neomutt. On next port update or selfupdate your changes to the Portfile will be lost (but the package will remain installed).

[lbschenkel (Leonardo Brondani Schenkel)]

One more thing: I suggest that you do *not* change the revision even though it is in my patch, so when the Portfile is updated on MacPorts it will automatically upgrade to the "official" build. If you do bump the revision then MacPorts will consider the package already up-to-date when that happens.

[jhi]

Replying to leonardo.schenkel@…:

Yes, you can manually run port edit neomutt and add manually enter my changes as described the diff. Then just run a port install neomutt. On next port update or selfupdate your changes to the Portfile will be lost (but the package will remain installed).

Tried that (without the revision bump as suggested). Failed. Looked at the patch. Didn't you mean

if {${install.user} eq "root"}

That is, try the homespool option only if we are root?

[lbschenkel (Leonardo Brondani Schenkel)]

No, it's the opposite. If you are root the package is built normally because that is how it is supposed to be built (this is a behaviour from upstream, not this port). If you are *not* root then neomutt is configured with --with-homespool and mutt_dotlock is not built, which bypasses the "can't fix permissions" error.

It's strange that it didn't work out for you. Did you get the exact same problem as before? Can you post the new complete debug log with my patch applied?

[jhi]

/opt/local/var/macports/logs/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_mail_neomutt/neomutt/main.log

[jhi]

Replying to leonardo.schenkel@…:

No, it's the opposite. If you are root the package is built normally because that is how it is supposed to be built (this is a behaviour from upstream, not this port). If you are *not* root then neomutt is configured with --with-homespool and mutt_dotlock is not built, which bypasses the "can't fix permissions" error.

It's strange that it didn't work out for you. Did you get the exact same problem as before? Can you post the new complete debug log with my patch applied?

Note: with the "eq root" neomutt built and installed for me.

But, anyway: did now "port uninstall neomutt" (to get rid of the modified revision three), and then re-did "port edit neomutt" to put back the "ne root", and re-tried "port install neomutt". Failed, the new patch attached.

[lbschenkel (Leonardo Brondani Schenkel)]

OK, I checked your log and I think I have a wrong understanding of what ${install.user} actually means. I have done an alternative approach: I have introduced a new variant +homespool, which you should manually activate when running port install without root. This flag will be preserved on upgrades, so you only need to remember to activate it manually when you install the package for the first time.

If I figure out later how to do it properly (I'll need to ask around), I may be able to enable this variant automatically for cases like yours when you aren't running MacPorts with sudo. But you will always be able to enable this yourself, so hopefully that should suffice.

Could you please try again once more?

[mf2k (Frank Schima)]

Adding a variant does not need a revision change. The user must specifically install the port with the variant to get it. An update will not add it even if it is a default variant.

[neverpanic (Clemens Lang)]

In any case, this wouldn't need a revbump. Users that succeeded in installing mutt already have the correct version and don't have to rebuild. Users that have failed builds will automatically use the new Portfile after a fix is committed.

Let me check for a way to find out whether a Portfile is run in a non-root installation…

[neverpanic (Clemens Lang)]

jhi: Can you attach your copy of /opt/local/libexec/macports/lib/port1.0/port_autoconf.tcl? It should contain install_user $yourusername which is the default for install.user. I'd like to figure out why the proposed solution did not work for you.

[jhi]

Replying to leonardo.schenkel@…:

OK, I checked your log and I think I have a wrong understanding of what ${install.user} actually means. I have done an alternative approach: I have introduced a new variant +homespool, which you should manually activate when running port install without root. This flag will be preserved on upgrades, so you only need to remember to activate it manually when you install the package for the first time.

If I figure out later how to do it properly (I'll need to ask around), I may be able to enable this variant automatically for cases like yours when you aren't running MacPorts with sudo. But you will always be able to enable this yourself, so hopefully that should suffice.

Could you please try again once more?

With the +homespool variant, install works.

[jhi]

/opt/local/libexec/macports/lib/port1.0/port_autoconf.tcl

[jhi]

Replying to cal@…:

jhi: Can you attach your copy of /opt/local/libexec/macports/lib/port1.0/port_autoconf.tcl? It should contain install_user $yourusername which is the default for install.user. I'd like to figure out why the proposed solution did not work for you.

Done. The install_users seems to be "root".

Note: I used to run macports as root (with sudo) for a while, but got nervous of doing that. So I chown -R:ed /opt/local to myself, and have been running updates fine (no sudo) with that setup.

[neverpanic (Clemens Lang)]

Oh, OK, that explains it. Non-root copies of MacPorts should be installed by following ​https://guide.macports.org/#installing.macports.source and passing --with-no-root-privileges switch to ./configure, which will automatically set install.user to your user name.

Note that running MacPorts without root privileges gives build systems unrestricted access to your home directory and your files. Running with sudo as root makes MacPorts drop privileges for builds to an unprivileged macports user.

I think we can keep the variant, but add a code block that makes it the default if install.user is not root:

if {${install.user} ne "root"} {
  default_variants +homespool
}

[lbschenkel (Leonardo Brondani Schenkel)]

Great. I have updated the patch with the suggestions and I have added openmaintainer as well.

[lbschenkel (Leonardo Brondani Schenkel)]

add +homespool, enable when not root, add openmaintainer

[neverpanic (Clemens Lang)]

Thanks, committed in r153193 and closing.