<html>
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#333333">
<p>Hi Mojca and Josh,<br>
</p>
<br>
<div class="moz-cite-prefix">On 1/13/19 15:11 , Mojca Miklavec
wrote:<br>
</div>
<blockquote
cite="mid:CALBOmsYo2C8Xh7Ncqcs-dNwg3KdRxeo_SYZMHaswrRL76+j0GA@mail.gmail.com"
type="cite">
<blockquote type="cite">
<pre wrap="">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. :)
</pre>
</blockquote>
<pre wrap="">This is of course also possible, it depends on the individual situation.</pre>
</blockquote>
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.<br>
<br>
<br>
<blockquote
cite="mid:CALBOmsYo2C8Xh7Ncqcs-dNwg3KdRxeo_SYZMHaswrRL76+j0GA@mail.gmail.com"
type="cite">
<blockquote type="cite">
<pre wrap="">I did play a little with this one:
post-fetch {
system -W ${worksrcpath} "patch --input=path/to/patch_file.diff"
}
</pre>
</blockquote>
<pre wrap="">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}"
}
</pre>
</blockquote>
Well, “pre-patch“ must be better. Still part of the patch compared
to post-fetch. :) <br>
<br>
<br>
<br>
<div class="moz-cite-prefix">On 1/14/19 0:50 , Joshua Root wrote:</div>
<blockquote
cite="mid:65cea619-616e-bd96-ec3a-adb2b276fb6c@macports.org"
type="cite">
<pre wrap="">GitHub will generate a tarball for any commit you name, so there's no
need to use fetch.type git in this case.
</pre>
</blockquote>
<br>
// <a class="moz-txt-link-freetext" href="https://github.com/ByteInternet/libapache-mod-fastcgi/">https://github.com/ByteInternet/libapache-mod-fastcgi/</a><br>
<pre><pre>github.setup ByteInternet libapache-mod-fastcgi 9b2f7df
fetch.type git</pre></pre>
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.<br>
<br>
<br>
<blockquote
cite="mid:65cea619-616e-bd96-ec3a-adb2b276fb6c@macports.org"
type="cite">
<blockquote type="cite">
<pre wrap="">I would suggest you to post your code somewhere and then it will be
easier to understand what goes wrong.
</pre>
</blockquote>
<pre wrap="">Agreed.
- Josh
</pre>
</blockquote>
<br>
<div class="moz-cite-prefix">On 1/13/19 15:11 , Mojca Miklavec
wrote:</div>
<blockquote
cite="mid:CALBOmsYo2C8Xh7Ncqcs-dNwg3KdRxeo_SYZMHaswrRL76+j0GA@mail.gmail.com"
type="cite">
<pre wrap="">(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.
</pre>
</blockquote>
Yes, of course… It's not much to show since it doesn't download. The
Portfile I have with <i>fetch.type git</i> - that one works.<br>
<br>
<br>
This is the repo:
<a class="moz-txt-link-freetext" href="https://github.com/ByteInternet/libapache-mod-fastcgi/">https://github.com/ByteInternet/libapache-mod-fastcgi/</a><br>
<br>
I think part of the problem is they have a slash in the release/tag
name.<br>
The closest I've come now (restarted with a fresh file), is also
using: “distname”.<br>
<br>
So, if I restart, and decides to go with this tag/release:
<a class="moz-txt-link-freetext" href="https://github.com/ByteInternet/libapache-mod-fastcgi/releases/tag/upstream/2.4.7_0910052141">https://github.com/ByteInternet/libapache-mod-fastcgi/releases/tag/upstream/2.4.7_0910052141</a><br>
- The tarball link (on the page) is:
<a class="moz-txt-link-freetext" href="https://github.com/ByteInternet/libapache-mod-fastcgi/archive/upstream/2.4.7_0910052141.tar.gz">https://github.com/ByteInternet/libapache-mod-fastcgi/archive/upstream/2.4.7_0910052141.tar.gz</a><br>
- The downloaded file name is:
libapache-mod-fastcgi-upstream-2.4.7_0910052141.tar.gz<br>
<br>
<br>
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:<br>
<pre><pre>github.setup ByteInternet libapache-mod-fastcgi 2.4.7_0910052141 upstream/
github.tarball_from releases
distname libapache-mod-fastcgi-upstream-2.4.7_0910052141</pre></pre>
That one gives this, when using: sudo port fetch …:
<pre>---> Attempting to fetch libapache-mod-fastcgi-upstream-2.4.7_0910052141.tar.gz from
https:<font class="pastecode">//github.com/ByteInternet/libapache-mod-fastcgi/releases/download/upstream/2.4.7_0910052141</font></pre>
I've tried all combos, tags, releases, with/without distname,
with/without tag prefix, etc<br>
<br>
- - -<br>
<br>
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.<br>
<br>
I see now there's an SSL error in the logs, on the line below the
github line? <i>That</i> can't be good. <_<<br>
:debug:fetch Fetching distfile failed: error:1407742E:SSL
routines:SSL23_GET_SERVER_HELLO:tlsv1 alert protocol version<br>
<br>
<font size="-1"><i>// I'm using: OSX 10.7.5, MacPorts 2.5.4 ,Xcode
4.3.3</i></font><br>
<br>
Any ideas?<br>
<br>
<br>
· Eric<br>
</body>
</html>