[Sending from the correct address this time]
I'd still like to see the opportunistic (via libarchive / bsdtar)
compression (pull request #45) integrated at some point; with modern
machines and their soldered-down storage, it's all the more useful.
Shall I open a ticket in trac as a feature reques
https://github.com/macports/macports-base/pull/76
During the extract-from-package step, if bsdtar exists **and** supports
--hfsCompression, use the flag during the extraction.
To test:
* make sure libarchive is installed
* check disk usage
* deactivate & re-activate a large port (llvm / gcc /
See my comments on the thread. Yes, it is slower, but for users with fixed
space, the time during activation isn't the biggest concern.
On Wed, Apr 18, 2018 at 4:09 AM, Jan Stary wrote:
> On Apr 12 22:58:54, ebori...@macports.org wrote:
> > https://github.com/macports/macports-base/pull/76
> >
Anyone know of any (license) issues with someone using our logo (
https://www.macports.org/img/macports-logo-top.png) when linking to
MacPorts as an installation option for their software?
Thanks,
- Eric
A note if others have github-hosted packages that use Doxygen to create
documentation: check to see if these changes broke your documentation
generation. Doxygen doesn't seem to like it when the INPUT directory itself
is a symlink. No errors are reported, but no useful documentation is
generated, e
As discussed here [1] on GitHub, 'curl-config --libs' is returning results
like this:
-L/opt/local/lib -lcurl -lidn2 -lpsl -lssl -lcrypto -lssl -lcrypto -lz
while 'pkg-config --libs libcurl' gives this:
-L/opt/local/lib -lcurl
The curl-config version results in lots of unnecessary libraries bei
Try updating and going again; 7.0 needed to be added to the
blacklist-if-not-installed loop in libomp. Not sure if this is your issue,
but can't hurt.
On Fri, Feb 8, 2019 at 12:52 PM Chris Jones
wrote:
> Hi,
>
> I was more referring to your macports configuration than the ports tree
> itself. A
It's been a decade since I set it up previously, and we've moved over to
GitHub Authentication in the interim. Any special directions for how to set
up a committer's @macports.org account now?
Thanks,
- Eric
We're getting activations errors when metadata is being attached to
read-only files on the buildbots. This causes errors on activation (with
MP's libarchive and HFS compression) due to is likely bug in libarchive
wrt. chmod() and setting metadata order-of-operations.
That said, do we know why this
I've created a pull request [1] to incorporate this patch. As noted on the
PR, I have no way to test the end result; perhaps someone else would like
to try it?
Thanks,
- Eric
[1] https://github.com/macports/macports-ports/pull/8859
On Mon, Oct 19, 2020 at 11:19 AM Christopher Chavez
wrote:
>
If I see something like this -- https://github.com/macports/
macports-ports/pull/37 -- come through, and it LGTM, do I just push the big
'Rebase and merge' button on the GitHub GUI? (This particular one is an
update to a nomaintainer port (fish) to the latest upstream version,
removes no-longer-nee
d ends)
as possible on both sides.
- Eric
On Mon, Nov 14, 2016 at 10:58 AM, Ryan Schmidt
wrote:
>
> > On Nov 14, 2016, at 10:51 AM, Eric A. Borisch
> wrote:
> >
> > If I see something like this -- https://github.com/macports/
> macports-ports/pull/37 -- come thr
On Mon, Nov 14, 2016 at 10:51 AM, Eric A. Borisch
wrote:
> If I see something like this -- https://github.com/
> macports/macports-ports/pull/37 -- come through, and it LGTM, do I just
> push the big 'Rebase and merge' button on the GitHub GUI? (This particular
>
On Mon, Nov 14, 2016 at 11:36 AM, Rainer Müller wrote:
> On 2016-11-14 18:11, Eric A. Borisch wrote:
> > If squash-and-merge is what we're going to want for pull requests, can
> > we re-enable the button? (Also known as, if we're using GitHub, can we
> > use GitH
On Mon, Nov 14, 2016 at 1:17 PM, Rainer Müller wrote:
> I agree this is not the easiest workflow we could have. However, even
> with "Squash and merge" button, you could only replace 4) and 5) of your
> steps with the web interface. You still need to the other steps to test
> the changes anyway.
Specifically, I'm looking at DCMTK where it has a penchant for grabbing
headers from the installed version of DCMTK.
The current approach is to force dcmtk to be deactivated first; but if I
can just enable the masking of non-dep files from trace mode, that would
work, too. (As the old versions wou
I'm going to throw in my 2c again asking for the 'squash and commit' button
to be activated. I'm much more likely to wander through and commit some
cut-and-dried PRs if it is something I can do drive-by, or even from my
phone.
And by cut-and-dried, I mean PRs from a prior contributor updating chec
On Mon, Dec 5, 2016 at 6:56 PM, Joshua Root wrote:
> On 2016-12-6 11:49 , Eric A. Borisch wrote:
>
>> I'm going to throw in my 2c again asking for the 'squash and commit'
>> button to be activated. I'm much more likely to wander through and
>> commit
Removing those two should be fine.
On older systems, libomp relies on macports-clang <= 3.7 to build (as >=
3.8 all depend themselves on libomp.) Just something to keep in mind in
"the future."
[Resend with MP e-mail; sorry for duplicates.]
On Sun, Jan 29, 2017 at 1:51 PM, Ken Cunningham <
ken.c
Just wondering what everyone would think of applying this patch? It enables
a runtime test during activation to see if (1) bsdtar is in path and (2) if
it supports the --hfsCompression option. (The version from libarchive does.)
The --hfsCompression does what you would expect: applies compression
On Mon, Nov 6, 2017 at 9:24 PM, Ryan Schmidt
wrote:
>
> On Nov 6, 2017, at 21:10, Eric A. Borisch wrote:
>
> > Just wondering what everyone would think of applying this patch?
>
> Are you aware of prior discussion in this ticket?
>
> https://trac.macports.org/ticket
21 matches
Mail list logo
