Updating unmaintained ports: alphamail

Ryan Schmidt ryandesign at macports.org
Sun Apr 18 02:51:51 PDT 2010


On Apr 18, 2010, at 03:26, Ryan Schmidt wrote:

> On Apr 17, 2010, at 03:49, Scott Haneda wrote:
> 
>> Would you mind walking me through your process of one port, so I know how to do this in a fast way.
> 
> Ok, let me pick one from my to-do list and see what happens.

Let's do another.


alphamail seems to have been updated (port version: 1.0.16, new version: 1.05)

That doesn't look right. Tickets? Yes, one:

http://trac.macports.org/ticket/15383

That ticket updates the port to 1.0.44, so now we know the livecheck is bogus. According to the patch in the ticket, the project has moved to SourceForge, so applying that patch might also fix the livecheck. Let's see what happens.

cd $(port dir alphamail)
patch -p0 < ~/Downloads/alphamail.patch 
patching file Portfile
Hunk #1 FAILED at 1.
1 out of 2 hunks FAILED -- saving rejects to file Portfile.rej

Oops... Why didn't the patch apply? Oh I see, the patchfile includes some changes right around the "# $Id$" line, but in the patchfile that line reads "# $Id$" (the patch was probably created with "svn di") whereas in my working copy it reads "# $Id: Portfile 64023 2010-02-20 10:34:53Z ryandesign at macports.org $". Once Subversion 1.7 is released which will contain an "svn patch" command this won't be a problem, but for now I edited the Portfile's "# $Id$" line to match what's in the patchfile. (Subversion will fix it up again anyway when I commit.)

edit Portfile
patch -p0 < ~/Downloads/alphamail.patch 

I don't like some of the whitespace changes made by this patch (they don't conform to the port's existing whitespace) so I'm going to fix that. I'll make some other formatting changes that suit me. Normally I wouldn't make whitespace changes in the same commit as functional changes, but when those whitespace changes occur in lines that are already being changed anyway for functional reasons, I think it's ok.

The default_variants line in the patch is syntactically incorrect (needs a "+" before the name of the desired default variant); fixing that.

Let's see if the livecheck is now ok.

port livecheck

It now says nothing, meaning it thinks the port is up to date. Checking the homepage... yup, 1.0.44 is current. So livecheck works now.

The ticket mentions some trouble with this update, hence apparently why it wasn't committed yet. Let's see if it builds.

sudo port -d install

It installed antiword as a dependency, which I notice isn't UsingTheRightCompiler, and also installed with the +universal variant (which is in my variants.conf) but did not actually install universal software.

cd $(port dir antiword)
edit Portfile

Ah, this software doesn't have a configure script. The port should have used "use_configure no" but didn't. I'll add that line (which will disable the universal variant), change the existing configure phase override to a post-patch phase, and add CC=${configure.cc} to build.args. Fixed.

http://trac.macports.org/changeset/66621

A nice next step for antiword would be to support ${configure.build_arch} and universal building. Maybe another day.

Back to alphamail. dovecot got installed as a dependency, then mod_perl2. mod_perl2 couldn't activate because the /opt/local/lib/perl5/5.8.9/darwin-2level/perllocal.pod it wanted to install conflicts with the one installed by rrdtool. Neither of these ports should be installing this file. We already have a ticket for this problem which I updated:

http://trac.macports.org/ticket/19854

Deactivated rrdtool to work around this for now.

sudo port deactivate rrdtool
cd $(port dir alphamail)
sudo port -d install

Had trouble installing some of the p5- modules with the universal variant, so skipping universal for now; someone else can file a ticket for that later.

sudo port clean p5-params-validate
sudo port clean
sudo port -d install -- -universal

Fails:

checking boost include files... yes
checking boost version greater than 1.33... yes
checking boost compilation... yes
checking thread compilation... configure: error: Unable to compile threaded programs. You may need -pthread (Linux), -pthreads (Solaris), or -mthreads (Mingw32) in CXXFLAGS

Maybe this is what Jeremy meant when he said in the ticket comments that he "can't get boost included correctly".

Searching the alphamail issue tracker... don't see anything relevant. Their forum and mailing lists seem unused. Googling parts of the error message... not finding anything. Guess I have to file a bug report and hope they respond to it:

https://sourceforge.net/tracker/?func=detail&aid=2988933&group_id=183361&atid=904932

I'll attach my revised patch back to the MacPorts ticket.

svn di > /tmp/alphamail-1.0.44-ryandesign.diff

That's all I can do for this one for now.


Not sure if any of this is being helpful to you. Each port has its own story and its own needs so I'm not sure if you're getting any generally-applicable advice out of this. But if you want to see how I handle things, this is it.




More information about the macports-dev mailing list