How do people use ManageSieve on macOS

[Gerben Wierda via macports-users]

I have a dovecot & dovecot-sieve running under MacPorts on my macOS ’server’. I 
do a very low tech maintenance on sieve, by using the cli on the server and 
edit sieve by hand for myself. I’d like to open this up to other users.

How do people use this from their macOS clients? For this, the ManageSieve 
protocol exists and this is implemented by dovecot-sieve, but other than 
installing roundcube and offering a web-based mail client that also supports 
ManageSieve, is there another way? A ManageSieve client that directly runs on 
the macOS client and interfaces with dovecot-sieve on the server?

After all, routing mail to different mailboxes better happens server-side so 
that all clients profit.

Gerben Wierda (LinkedIn )
R IT Strategy  (main site)
Book: Chess and the Art of Enterprise Architecture 
Book: Mastering ArchiMate 

Re: Understaning rleaves, rdepof

[Gerben Wierda via macports-users]

Interesting.

So, how would you go about finding the ports on which what is actually 
installed depends?

E.g.: if I have dovecot+solr8 installed, how would I find out which ports 
dovecot truly depends on on my system?

Gerben Wierda (LinkedIn )
R IT Strategy  (main site)
Book: Chess and the Art of Enterprise Architecture 
Book: Mastering ArchiMate 

> On 30 Jan 2022, at 10:20, Ryan Schmidt  wrote:
> 
> On Jan 29, 2022, at 10:56, Richard L. Hamilton wrote:
>> 
>> But looking at the dovecot Portfile, it seems the dependency on apache-solr8 
>> is specific to the +solr variant (which you have, to be sure). So assuming 
>> your installation isn't a bit confused somehow, maybe port isn't always 
>> smart about showing variant-specific dependencies.
>> 
>> That's just a guess, though; 
> 
> That's correct.
> 
>> On Jan 29, 2022, at 10:52, Gerben Wierda wrote:
>> 
>>> Thank you. That solves a lot of the mystery. I did encounter a small 
>>> mystery:
>>> 
>>> gerben@hermione ~ % port installed rdepof:dovecot 
> 
> "rdepof" determines the port's recursive dependencies based on the port's 
> default variants (which doesn't include +solr), not based on the variants 
> with which you have it installed.
> 
> I'm not sure if there's a form of this command that allows you to specify an 
> alternate set of variants.
> 
>>> The following ports are currently installed:
>>>  autoconf @2.71_1 (active)
>>>  automake @1.16.5_0 (active)
>>>  bison @3.8.2_2 (active)
>>>  bison-runtime @3.8.2_0 (active)
>>>  bzip2 @1.0.8_0 (active)
>>>  flex @2.6.4_0 (active)
>>>  gettext @0.21_0 (active)
>>>  gettext-runtime @0.21_0 (active)
>>>  gettext-tools-libs @0.21_0 (active)
>>>  libiconv @1.16_1 (active)
>>>  libtextstyle @0.21_0 (active)
>>>  libtool @2.4.6_13 (active)
>>>  lz4 @1.9.3_1 (active)
>>>  m4 @1.4.19_1 (active)
>>>  ncurses @6.3_0 (active)
>>>  openssl @3_2 (active)
>>>  openssl3 @3.0.1_0+legacy (active)
>>>  pkgconfig @0.29.2_0 (active)
>>>  xz @5.2.5_0 (active)
>>>  zlib @1.2.11_0 (active)
>>> gerben@hermione ~ % port installed rdependentof:apache-solr8
> 
> "rdependentof" consults your MacPorts registry to determine this information, 
> so it's based on what was recorded there when you installed the ports with 
> whatever variants you installed them with.
> 
>>> The following ports are currently installed:
>>>  dovecot @2.3.17_0+apns+solr (active)
>>> 
>>> Or, it seems port knows apache-solr8 is requested by dovecot but not the 
>>> other way around.
> 

Is this git handling of a problem on my macports-ports fork OK?

[Gerben Wierda via macports-users]

I have my own fork of macports-ports in case I want to do maintenance. 
Getting a clean local clone for me means:

# First, do an update of macports base only (does not update the ports tree):

sudo port selfupdate --no-sync

# Updating the master of my fork from the master of the original:

git checkout master # Go to branch master in my local clone
git pull upstream master# Update my local clone master from the 
master of the remote upstream
# (overwrites my local master with 
remote github/macports/master)
git reset --hard upstream/master# Resets index and working tree of 
local clone/master from remote upstream
git push origin master --force  # Push local clone 
(~/MacPortsDev/macports-ports) master back
# to my own remote fork 
(github/gctwnl/macports-ports)
# NOTE: this closes all open 
pull-requests!
portindex   # Tell macports to use this tree and 
update the macports index

Apparently, in the past UI have accidentally done some of this as root, so this 
failed because parts of the macports-ports clone were owned by root.

So, I did a chown -R on that tree and tried again, but now I get

albus:macports-ports sysbh$ git pull upstream master
From https://github.com/macports/macports-ports
 * branchmaster -> FETCH_HEAD
Updating e0a3df02c73..eca5c1226ee
error: Your local changes to the following files would be overwritten by merge:

_resources/port1.0/checks/implicit_function_declaration/macosx10.10.sdk.list

_resources/port1.0/checks/implicit_function_declaration/macosx10.11.sdk.list
…
error: The following untracked working tree files would be overwritten by merge:
aqua/qt5/files/patch-qtwebengine_gn_binary_path.diff
comms/s710/files/dynamic_lookup-11.patch

So I tried to do 

git reset --hard upstream/master

and apparently this did work as another pull did nothing. But before I push 
that back to my own clone: have I done anything wrong? Is my local tree in 
order now?

Gerben Wierda (LinkedIn )
R IT Strategy  (main site)
Book: Chess and the Art of Enterprise Architecture 
Book: Mastering ArchiMate