Help with a Portfile

[iEFdev]

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-7.3.2.154-source-patches/binutils-2_26.patch
> 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.

// https://github.com/ByteInternet/libapache-mod-fastcgi/

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: https://github.com/ByteInternet/libapache-mod-fastcgi/

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:
https://github.com/ByteInternet/libapache-mod-fastcgi/releases/tag/upstream/2.4.7_0910052141
- The tarball link (on the page) is:
https://github.com/ByteInternet/libapache-mod-fastcgi/archive/upstream/2.4.7_0910052141.tar.gz
- The downloaded file name is:
libapache-mod-fastcgi-upstream-2.4.7_0910052141.tar.gz


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
          https://github.com/ByteInternet/libapache-mod-fastcgi/releases/download/upstream/2.4.7_0910052141

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: <http://lists.macports.org/pipermail/macports-dev/attachments/20190114/61a39b6f/attachment.html>