Updating unmaintained ports: alphamail

Bradley Giesbrecht brad at pixilla.com
Sun Apr 18 09:08:14 PDT 2010


On Apr 18, 2010, at 2:51 AM, Ryan Schmidt wrote:

> 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.

My experience is that "port livecheck" without -d will report nothing  
if livecheck is invalid for various reason, example distname has  
changed or source repository has moved. I usually do port -d livecheck.

I would like port -v livecheck to report the current mp version and  
the highest source version found although I wouldn't put a much of  
priority on it. But is one were to implement the master_sites patch  
from Rainer maybe consider this enhancement as well while your at it.

// Brad


More information about the macports-dev mailing list