On Wed, Jan 27, 2016 at 03:00:52PM +0100, Rainer Müller wrote:
> > I think the system bsdtar doesn't support this on all OS X versions
> > that do support hfs compression.
>
> Right, on my OS X 10.10.5 Yosemite it does not seem to be supported. In
> the ticket you said it was not supported on OS
On Wednesday January 27 2016 15:00:52 Rainer Müller wrote:
> Yes, it is a test, but I would not call that simple. Also, we would only
> need to test this once and it could even be done during configure.
Configure when MacPorts itself is being built?
> afsctool is GPL-3 software, so we should
On 2016-01-26 18:31, René J.V. Bertin wrote:
> On Tuesday January 26 2016 08:55:20 Ryan Schmidt wrote:
>
>> https://trac.macports.org/ticket/36560
> On 2016-01-26 18:12, Joshua Root wrote:
>> Not really thrilled by the inline hex file and shelling out to run
>> a
>
> Isn't that simply a test to
>> I was under the impression that Apple already compressed the files and
>> programs installed with the operating system, using HFS compression, ever
>> since taking up less disk space was listed as a feature of Snow Leopard.
> Yeah, I thought so too, but I also have the impression that may not
Hi,
On 26/01/16 09:47, Vincent Habchi wrote:
I was under the impression that Apple already compressed the files and programs
installed with the operating system, using HFS compression, ever since taking
up less disk space was listed as a feature of Snow Leopard.
Yeah, I thought so too, but
> On Jan 26, 2016, at 1:47 AM, Vincent Habchi wrote:
>
>>> I was under the impression that Apple already compressed the files and
>>> programs installed with the operating system, using HFS compression, ever
>>> since taking up less disk space was listed as a feature of
> On Jan 26, 2016, at 2:26 AM, René J.V. Bertin wrote:
>
> Given the disk savings it can give I really don't understand why the patch
> that adds HFS compression to port activation was never accepted.
For reference, that was this ticket:
On Jan 26, 2016, at 11:55 AM, Ryan Schmidt wrote:
> There were performance concerns earlier in the discussion but I'm not sure if
> the latest version of the patch attached there resolves them.
the latest comment that mentions it says it's a 2x slowdown (better than the
On 2016-1-27 04:04 , Daniel J. Luke wrote:
> On Jan 26, 2016, at 11:55 AM, Ryan Schmidt wrote:
>> There were performance concerns earlier in the discussion but I'm not sure
>> if the latest version of the patch attached there resolves them.
>
> the latest comment that
On Jan 26, 2016, at 12:12 PM, Joshua Root wrote:
> Not really thrilled by the inline hex file and shelling out to run a
> command pipeline before every extract either. Seems like this could be a
> configure check for the system bsdtar supporting the feature instead.
+1
I
On Tuesday January 26 2016 08:55:20 Ryan Schmidt wrote:
>https://trac.macports.org/ticket/36560
Yeah, that was the one.
>There were performance concerns earlier in the discussion but I'm not sure if
>the latest version of the patch attached there resolves them.
Activating hfsCompression is
On Tuesday January 26 2016 10:47:10 Vincent Habchi wrote:
>I’ve applied René method, disabling SIP while compressing /Applications. It
>gave me some significant savings, thus I surmise all the applications are not
>compressed. Xcode is, though, but things like iWorks (Pages, etc.) are not.
> On Jan 24, 2016, at 1:42 AM, Vincent Habchi wrote:
>
>> Sure. And it is probably also very easy to introduce regressions that way if
>> the #ifdefs aren't already in place.
>
> Yeah, that’s right. Every cloud has its silver lining. Or the contrary for
> that matter.
>
On Monday January 25 2016 19:39:26 Ryan Schmidt wrote:
>I was under the impression that Apple already compressed the files and
>programs installed with the operating system, using HFS compression, ever
>since taking up less disk space was listed as a feature of Snow Leopard.
Yeah, I thought so
> This typically doesn't take a lot of space, and no compiler option will
> remove the unused code in software that was meant to support different CPUs
> at runtime…
Except that you can use configure to detect what model of processor you’re
running on, and then with a -D flag eliminate all the
> Sure. And it is probably also very easy to introduce regressions that way if
> the #ifdefs aren't already in place.
Yeah, that’s right. Every cloud has its silver lining. Or the contrary for that
matter.
> It'll do the same with your /Applications directory or the entire /opt/local
> tree.
On Sunday January 24 2016 09:46:03 Vincent Habchi wrote:
>Except that you can use configure to detect what model of processor you’re
>running on, and then with a -D flag eliminate all the code that is not
>targeted for your CPU (via #ifdef/#ifndef).
Sure. And it is probably also very easy to
On Sunday January 24 2016 10:42:56 Vincent Habchi wrote:
> Except that it’s no longer possible to compress the build-in Applications
> with OS X 10.11 since Apple introduced SIP
> (http://arstechnica.com/apple/2015/09/os-x-10-11-el-capitan-the-ars-technica-review/8/#h1).
> Even root cannot
On Sun, Jan 24, 2016 at 6:20 AM, René J.V. wrote:
> A trip to single-user mode or into recovery mode to toggle an EFI setting,
> right?
csrutil {enable|disable} and reboot.
--
brandon s allbery kf8nh sine nomine associates
On Saturday January 23 2016 14:19:26 Vincent Habchi wrote:
> Latest one:
>
> port installed | grep VLC
> VLC @2.1.5_7+mod+mpc+osd+qtkit+quartz (active)
That's indeed that latest one provided through MacPorts, but not the latest VLC
version. I've submitted a port for 2.2.1 on Trac months ago,
Hi René,
> Any MKV file? What VLC version?
Latest one:
port installed | grep VLC
VLC @2.1.5_7+mod+mpc+osd+qtkit+quartz (active)
> What does the VLC log tell you (either in-app or by launching the app bundle
> executable directly from a terminal, with the -vvv argument)?
You will find the
> On Jan 23, 2016, at 8:48 AM, Vincent Habchi wrote:
>> Might I suggest that you download the latest VLC player from videolan.org
>> directly, and see if that one gives the same error? If it doesn't, you can
>> then probably simply uninstall the one from MacPorts.
>
> Yep,
On Saturday January 23 2016 12:10:54 Vincent Habchi wrote:
Hi,
>I’ve a strange problem with VLC. Clicking on a MKV file will not crash the
>app, but it will go into a sort of infinite loop, as if it was not finding
>anything to play inside the file and kept on trying again.
>
>ffplay with the
>
> That's indeed that latest one provided through MacPorts, but not the latest
> VLC version. I've submitted a port for 2.2.1 on Trac months ago, but it has
> never been committed.
There’s a “beta” 2.2.2-20150427_3 available on MacPorts, I’ll try it and let
you know.
> Might I suggest that
> On Jan 23, 2016, at 9:36 AM, Vincent Habchi wrote:
> I compiled VLC 2.2.1 using Macports and still have the same error :(
> Seems something is wrong in the MacPorts librairies, but where? ...
>
> VLC media player 2.2.2 Weatherwax (revision 2.2.1-21-g2502874)
> …
>
> On Jan 23, 2016, at 12:33 PM, Vincent Habchi wrote:
>
>> … If you only installed those libraries for VLC then you shouldn't lose
>> much. You would however have more definite proof whether your issue is due
>> to something with the MacPorts build or in VLC itself. If the
On Saturday January 23 2016 14:48:56 Vincent Habchi wrote:
>There’s a “beta” 2.2.2-20150427_3 available on MacPorts, I’ll try it and let
>you know.
Ah, not mine AFAIK. The portfile I submitted on Trac *probably* contains a
VLC-devel port for 3.0.0-150503-g7385062d (my local copy does), but I
> Ah, not mine AFAIK. The portfile I submitted on Trac *probably* contains a
> VLC-devel port for 3.0.0-150503-g7385062d (my local copy does), but I don't
> think I tried building or using that one since May last year (1505).
I could have a stab at compiling it, if you want.
> If you only
On Saturday January 23 2016 18:33:07 Vincent Habchi wrote:
>> Ah, not mine AFAIK. The portfile I submitted on Trac *probably* contains a
>> VLC-devel port for 3.0.0-150503-g7385062d (my local copy does), but I don't
>> think I tried building or using that one since May last year (1505).
>
>I
René,
I compiled VLC 2.2.1 using Macports and still have the same error :(
Seems something is wrong in the MacPorts librairies, but where?
Cheers!
—
VLC media player 2.2.2 Weatherwax (revision 2.2.1-21-g2502874)
[7f9f92f00378] core libvlc debug: VLC media player - 2.2.2 Weatherwax
> You might want to look at the following to clean up those libraries:
>
> $ port info port_cutleaves
[…]
Thanks Craig!
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev
Craig:
> Do other mkv files play OK?
I haven’t many MKV files, all from the same source, and none plays correctly on
VLC.
FFPLAY has no difficulty reading them.
Strange.
Output of mediainfo:
> mediainfo /Volumes/Archives/Vidéos/Series/MLP\ FIM\ S4/YP-7Z-04x02.mkv
General
Unique ID
On Sat, 23 Jan 2016, Vincent Habchi wrote:
> I’ve a fairly new Mac (three-year old or so), so performance is no concern
> during normal operation; however, watching a flick or a show while compiling
> Qt5 can sometimes be jerky. Besides, more CPU efficiency also means less
> battery drain.
33 matches
Mail list logo