Re: [145141] trunk/dports/python

[Ryan Schmidt]

> On Jan 27, 2016, at 3:57 PM, Andrew Fernandes  
> wrote:
> 
> I think that's to be expected, for a port that hasn't been added to the 
> portindex yet.
> 
> Oh - so lint gives different (and incomprehenible) output that changes 
> whether or not the port is in the index. Yeesh.
> 
> No prob, committing a fix now. I’m also fixing the license issue. r145179

Well, lint was accurately telling you that your port py-pyinstaller has a 
dependency on py27-pyinstaller (which was added by the python 1.0 portgroup), 
and that no port named py27-pyinstaller exists in the portindex. lint didn't 
know that your new unindexed port included the definition for the 
py27-pyinstaller port.

___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: [145141] trunk/dports/python

[Ryan Schmidt]

> On Jan 27, 2016, at 4:24 AM, Andrew Fernandes  
> wrote:
> 
> MacPorts interprets the license field as a space-separated list of valid 
> license names.
> 
> Ah, I vaguely remember that. I had simply copied the license field from the 
> original Portfile in #42693.
> 
> But that didn’t cause the issue - I checked.
>> +python.versions 27 33 34 35
>> 
> 
> Doesn't the python.versions line have to be outside this block?
> 
> Yes, that’s what I’ve done before and that’s what all the other python ports 
> do.

Setting python.versions is what causes the python 1.0 portgroup to create the 
subports. If it's inside an "if {${name} ne ${subport}}" block, it can never 
get executed, and the subports can never get created, because at the time the 
if statement is evaluated no subports exist yet, so at that point ${name} will 
always eq ${subport}.


> However, if the line is outside the block - like every other port - I get a 
> “port lint” error that “py27-pypyinstaller is an unmet dependency” which I 
> simply don’t understand.

I think that's to be expected, for a port that hasn't been added to the 
portindex yet. You can either add it to the portindex (by running the portindex 
command in the dports directory as the correct user), or just ignore it and 
check it again later after it's been committed.


> Linting with a subport specified gives me no error.
> 
> The only way I could get rid of it - and I spent a lot of time trying and a 
> lot of time googling, and a lot of time looking at other ports - was to move 
> the python.versions block inside the subport-check block.



___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: [145185] trunk/dports/python/py-pyinstaller/Portfile

[Ryan Schmidt]

> On Jan 27, 2016, at 6:58 PM, adfernan...@macports.org wrote:
> 
> Revision
> 145185
> Author
> adfernan...@macports.org
> Date
> 2016-01-27 18:58:54 -0800 (Wed, 27 Jan 2016)
> Log Message
> 
> py-pyinstaller: actually fetch the correct tarball, not git HEAD
> Modified Paths
> 
>   • trunk/dports/python/py-pyinstaller/Portfile
> Diff
> 
> Modified: trunk/dports/python/py-pyinstaller/Portfile (145184 => 145185)
> 
> --- trunk/dports/python/py-pyinstaller/Portfile   2016-01-28 01:40:18 UTC 
> (rev 145184)
> +++ trunk/dports/python/py-pyinstaller/Portfile   2016-01-28 02:58:54 UTC 
> (rev 145185)
> @@ -7,9 +7,12 @@
>  namepy-pyinstaller
>  version 3.1
>  
> -fetch.type  git
>  github.setuppyinstaller PyInstaller ${version} v
> +github.tarball_from releases
>  
> +checksums   rmd160  8d0659ac74a81b634f0712a64ff28db71a3450e4 \
> +sha256  
> 5a28c3bb9d23ea644f9dc9e561e66471b83258d44063bcb108dfbbfe4af3c02b

It looks like HEAD was some commits ahead of 3.1. So this revision changes the 
files that would be installed on the user's disk. So the port's revision should 
be increased.

___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: VLC cannot play MKV files?

[Clemens Lang]

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 X 10.9. Can anybody
> please check whether it is actually supported on OS X 10.11 El Capitan?
> 
> $ echo "666f6f00...00" | /usr/bin/bsdtar --hfsCompression -xqOf -
> foo>/dev/null
> bsdtar: Option --hfsCompression is not supported
> Usage:
> ...

10.11's bsdtar doesn't support --hfsCompression.

-- 
Clemens
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: VLC cannot play MKV files?

[René J . V . Bertin]

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 not just include it in base, as
> it is BSD licensed.

Wasn't suggesting you should. But what can be done is to check for existence of 
the executable. That's what I do in the places where I added build.dir 
compression. That's a (crude) form of giving the user the choice whether or not 
the feature is to be used (someone not at all interested in using hfs 
compression would probably not install afsctool).

> We could include our own libarchive/bsdtar with this feature enabled or

It is already enabled.

> develop equivalent functionality for Pextlib based on the source of
> libarchive. However, it really does not look like writing compressed
> files is trivial [1].

No, it isn't, probably for a large part because it involves writing the 
compressed data to the resource fork. I'm using 
https://github.com/RJVB/afsctool/blob/master/afsctool.c as a reference, which 
is probably even more complicated because of additional features like choice of 
the compression level.
Things would have been different if the compressor were a part of the HFS+ 
implementation (and all you needed to do to activate it was setting the 
attribute on the file). As it is I think it'd be much preferable to leverage 
existing utilities or libraries that provide hfsCompression than to reimplement 
support for it.

R.
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: VLC cannot play MKV files?

[Rainer Müller]

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 see if the bsdtar command found "does the
> trick"?

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.

>> command pipeline before every extract either
> 
> 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 X 10.9. Can anybody
please check whether it is actually supported on OS X 10.11 El Capitan?

$ echo "666f6f00...00" | /usr/bin/bsdtar --hfsCompression -xqOf -
foo>/dev/null
bsdtar: Option --hfsCompression is not supported
Usage:
...

Probably the test could even be simpler:

$ /usr/bin/bsdtar --hfsCompression --help
bsdtar: Option --hfsCompression is not supported
Usage:
...

$ /opt/local/bin/bsdtar --hfsCompression --help
bsdtar: manipulate archive files
First option must be a mode specifier:
-c Create -r Add/Replace -t List -u Update -x Extract
...

> I've never looked in detail at how activation works without this
> patch; does it always use a temporary folder in
> ${prefix}/var/macports/software/${subport} from which items are then
> moved into place? If so, the easiest approach to making this optional
> would be to run a version of afsctool on the extraction folder.
> Afsctool being apparent abandonware I've developed it further,
> letting it process files in parallel. Combined with an accelerated
> zlib that makes fast enough that even a post-build compression of
> Qt's build.dir is insignificant w.r.t. to build time (for very
> appreciable savings).

afsctool is GPL-3 software, so we should not just include it in base, as
it is BSD licensed.

We could include our own libarchive/bsdtar with this feature enabled or
develop equivalent functionality for Pextlib based on the source of
libarchive. However, it really does not look like writing compressed
files is trivial [1].

Rainer

[1]
https://github.com/libarchive/libarchive/blob/b9d0b46eb05b0f1e6c832512c2c6b5d782db58d1/libarchive/archive_write_disk_posix.c
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev