<html>
  <head>
    <meta content="text/html; charset=utf-8" http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#333333">
    <p><font face="Arial">Hi Mojca,</font></p>
    <p><font face="Arial">Thank you so much for your reply and help…</font><br>
    </p>
    On 1/13/19 12:27 , Mojca Miklavec wrote:<br>
    <blockquote
cite="mid:CALBOmsYU-L30AndygYE=+2A70NyD66n0fa=861A_ABmGxOc2BA@mail.gmail.com"
      type="cite">
      <pre wrap="">When you use github.setup, a tarball is fetched directly from the
GitHub server, without resorting to git in any way, and works as if
you fetched the sources from elsewhere.

When you use git directly, the checksums are (sadly) not yet verified.
If you fetch from a particular commit in git, the shasum should
usually give you sufficient reliability (to some extent), while if you
use master (or any other branch for that matter), you would not get
reliable contents anyway, and it's highly discouraged to fetch from a
branch as you never know what could break and when.

This is admittedly suboptimal. Rainer did some 80% of the work, see
    <a class="moz-txt-link-freetext" href="https://trac.macports.org/ticket/16373">https://trac.macports.org/ticket/16373</a>
or the corresponding branch (vcs-fetch) in macports-base, but he might
need a push to complete the work, test and merge the code :) :) :)
</pre>
    </blockquote>
    I never got that to (start) download, and then there is that other
    thing - that the commit I used is the last one made, and it's ≈ 2
    years newer than last release. 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. :)<br>
    <br>
    <blockquote
cite="mid:CALBOmsYU-L30AndygYE=+2A70NyD66n0fa=861A_ABmGxOc2BA@mail.gmail.com"
      type="cite">
      <pre wrap="">I recently stumbled into a wall myself when trying to do something
less conventional with patch files [1]. I ended up running patch
manually which is heavily suboptimal and it could help to modify the
base a bit to better support a scenario of having an extracted patch
file somewhere or the disk that's not exactly files/, but I don't know
what exactly you scenario is. MacPorts would happily support applying
a patch from a .bz2 file located somewhere online, for example. <b>Where
did you get the patch file from / how?</b></pre>
    </blockquote>
    The patch files are inside the downloaded directory as a part of the
    download, sort of. Thought it would be nice to bee able to use them
    at their current location, instead of taking the patch and put in a
    Files directory.<br>
    <br>
    <br>
    I did play a little with this one:<br>
    <br>
    post-fetch {<br>
        system -W ${worksrcpath} "patch --input=path/to/patch_file.diff"<br>
    }<br>
    <br>
    But, then it's outside the system, sort of. Hard to patch it manual
    with: port patch foobar <br>
    <br>
    <br>
    <blockquote
cite="mid:CALBOmsYU-L30AndygYE=+2A70NyD66n0fa=861A_ABmGxOc2BA@mail.gmail.com"
      type="cite">
      <pre wrap="">Mojca


[1] <a class="moz-txt-link-freetext" href="https://github.com/macports/macports-ports/pull/3336">https://github.com/macports/macports-ports/pull/3336</a>
</pre>
    </blockquote>
    Yes, it was something simular I had in mind.<br>
    <br>
    I thought, with:<br>
    <i>patch.dir ${worksrcpath}/path/to</i><i><br>
    </i><i>patchfiles patch_file.diff</i><br>
    <br>
    it would (hopefully) do the same thing as above (w system -W …). :)<br>
    That specifying a patch.dir would make the Files dir unnecessary. <br>
    <br>
    <br>
    But, if I'm going to patch up the last release, then I guess I have
    to use the Files dir anyway.<br>
    <br>
    Eric<br>
  </body>
</html>