Help with a Portfile

iEFdev eric at
Mon Jan 14 03:04:40 UTC 2019

Hi Mojca and Josh,

On 1/13/19 15:11 , Mojca Miklavec wrote:
>> But maybe one could take one of the releases, and create an additional patch from the last commit - just to get up to date? I dont' think it's that many commits behind. :)
> This is of course also possible, it depends on the individual situation.
Yes, I think I'll go that way… as soon as I can get a release to download. I
compared it to a fresh clone. It'll just need a small patch.

>> I did play a little with this one:
>> post-fetch {
>>     system -W ${worksrcpath} "patch --input=path/to/patch_file.diff"
>> }
> This is approxmately what I ended up doing (but I don't like it):
> set file_patch msp430-gcc-
> pre-patch {
>     system -W ${worksrcpath} "/usr/bin/patch -p0 < ${workpath}/${file_patch}"
> }
Well, “pre-patch“ must be better. Still part of the patch compared to
post-fetch. :)

On 1/14/19 0:50 , Joshua Root wrote:
> GitHub will generate a tarball for any commit you name, so there's no
> need to use fetch.type git in this case.


github.setup        ByteInternet libapache-mod-fastcgi 9b2f7df
fetch.type          git

That one will clone… but, it won't create a tarball if I skip the fetch part..
And there's some really odd naming thing going on.

>> I would suggest you to post your code somewhere and then it will be
>> easier to understand what goes wrong.
> Agreed.
> - Josh

On 1/13/19 15:11 , Mojca Miklavec wrote:
> (Intermediate comment: since you are probably not packaging some
> proprietary software, it could be easier to explain the issues by
> pointing to the concrete sources than trying to explain the situation
> :)
> This is often a perfectly valid usecase for fetching the source from
> git. You just need to make sure that you don't specify master, but
> provide the shasum instead. (And you need to live with the fact that
> until we merge the code from base, those sources would be re-fetched
> each time when you compile your port.)
> I would suggest you to post your code somewhere and then it will be
> easier to understand what goes wrong.
Yes, of course… It's not much to show since it doesn't download. The Portfile I
have with /fetch.type git/ - that one works.

This is the repo:

I think part of the problem is they have a slash in the release/tag name.
The closest I've come now (restarted with a fresh file), is also using: “distname”.

So, if I restart, and decides to go with this tag/release:
- The tarball link (on the page) is:
- The downloaded file name is:

In my Portfile… Don't know if to treat the “upstream/”-part as a part of the
tag, or as a prefix. I have tried both:

github.setup        ByteInternet libapache-mod-fastcgi 2.4.7_0910052141 upstream/
github.tarball_from releases
distname            libapache-mod-fastcgi-upstream-2.4.7_0910052141

That one gives this, when using: sudo port fetch …:

--->  Attempting to fetch libapache-mod-fastcgi-upstream-2.4.7_0910052141.tar.gz from

I've tried all combos, tags, releases, with/without distname, with/without tag
prefix, etc

- - -

Perhaps there's something else to it? I just tried with another port. Tested
with “fish”, just to try to “port fetch”. It worked, but when I copied it to
another dir, and called it fishy, samme thing.

I see now there's an SSL error in the logs, on the line below the github line?
/That/ can't be good. <_<
    :debug:fetch Fetching distfile failed: error:1407742E:SSL
routines:SSL23_GET_SERVER_HELLO:tlsv1 alert protocol version

/// I'm using: OSX 10.7.5, MacPorts 2.5.4 ,Xcode 4.3.3/

Any ideas?

· Eric
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the macports-dev mailing list