liblzma and ffmpeg

[René J.V. Bertin]

'evening!

I'm doing a selfupdate, which includes upgrading ffmpeg +gpl2+nonfree+universal+x11 from 2.3.3_0 to 2.4.1 . That went fine on 10.6, but on my 10.9 VM I'm running into an issue involving liblzma, which apparently is not universal, and thus gives me a failure when merging libavcodec.pc .

Curiously, I have neither port:lzma nor port:liblzma installed (on both set-ups). `port provides` doesn't work for me so I'm at a loss where the liblzma.dylib comes from ...

In any case there seems to be something fishy with ffmpeg's Portfile?

Any suggestions?

R.

[Ryan Schmidt]

Post by René J.V. Bertin
I'm doing a selfupdate, which includes upgrading ffmpeg +gpl2+nonfree+universal+x11 from 2.3.3_0 to 2.4.1 . That went fine on 10.6, but on my 10.9 VM I'm running into an issue involving liblzma, which apparently is not universal, and thus gives me a failure when merging libavcodec.pc .
Curiously, I have neither port:lzma nor port:liblzma installed (on both set-ups). `port provides` doesn't work for me so I'm at a loss where the liblzma.dylib comes from ...
In any case there seems to be something fishy with ffmpeg's Portfile?

What do you mean, "`port provides` doesn't work for me"? What does it do?

[Brandon Allbery]

Post by Ryan Schmidt
What do you mean, "`port provides` doesn't work for me"? What does it do?

Presumably, given "Curiously, I have neither port:lzma nor port:liblzma
installed (on both set-ups)", it's correctly indicating it didn't come from
a port. I note that 10.9 has liblzma.5.dylib and liblzma.dylib in /usr/lib
though; probably the port needs to be tweaked to avoid the system one.

[David Evans]

Post by Ryan Schmidt
What do you mean, "`port provides` doesn't work for me"? What does it do?
Presumably, given "Curiously, I have neither port:lzma nor
port:liblzma installed (on both set-ups)", it's correctly indicating
it didn't come from a port. I note that 10.9 has liblzma.5.dylib and
liblzma.dylib in /usr/lib though; probably the port needs to be
tweaked to avoid the system one.
--
brandon s allbery kf8nh sine nomine associates
unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net
_______________________________________________
macports-users mailing list
https://lists.macosforge.org/mailman/listinfo/macports-users

It appears ffmpeg does want to link with liblzma but is missing a
dependency on xz. I think adding this dependency will fix the problem.
Testing now.

[René J.V. Bertin]

Post by Ryan Schmidt
What do you mean, "`port provides` doesn't work for me"? What does it do?

It tells me that the file "isn't provided by a port", whatever file I throw at it.

I found the explanation. Nowadays, liblzma is provided by port:xz . Before launching the upgrade procedure I'd pruned a number of ports that had been installed (or promoted to) +universal. I wasn't expecting port:xz (nor port:curl) to provide libraries, so I replaced them with the normal variant.
My bad ...

R.

[Ryan Schmidt]

Post by René J.V. Bertin

Post by Ryan Schmidt
What do you mean, "`port provides` doesn't work for me"? What does it do?

It tells me that the file "isn't provided by a port", whatever file I throw at it.

Perhaps it's this: "port provides" only responds to the canonical path. So even on case-insensitive file systems you must use the correct case, and if your MacPorts prefix is symlinked elsewhere, you must still use the prefix that MacPorts was originally configured to use.

[René J.V. Bertin]

Post by Ryan Schmidt

Post by René J.V. Bertin
It tells me that the file "isn't provided by a port", whatever file I throw at it.

Perhaps it's this: "port provides" only responds to the canonical path. So even on case-insensitive file systems you must use the correct case, and if your MacPorts prefix is symlinked elsewhere, you must still use the prefix that MacPorts was originally configured to use.

I have my MacPorts tree on a case-sensitive partition, with /opt/local a symlink to it. And it doesn't matter whether I use the path with /opt/local or the "normalised" path.

However, the command *does* work for the files inside KDE appbundles installed in /Applications/MacPorts/KDE4 . Go figure why ...

R.

[Brandon Allbery]

Post by René J.V. Bertin
I have my MacPorts tree on a case-sensitive partition, with /opt/local a
symlink to it. And it doesn't matter whether I use the path with /opt/local
or the "normalised" path.

So what does "port contents xz" say, compared to the paths you've been
testing?

[Daniel J. Luke]

Post by René J.V. Bertin

Post by Ryan Schmidt

Post by René J.V. Bertin
It tells me that the file "isn't provided by a port", whatever file I throw at it.

Perhaps it's this: "port provides" only responds to the canonical path. So even on case-insensitive file systems you must use the correct case, and if your MacPorts prefix is symlinked elsewhere, you must still use the prefix that MacPorts was originally configured to use.

I have my MacPorts tree on a case-sensitive partition, with /opt/local a symlink to it. And it doesn't matter whether I use the path with /opt/local or the "normalised" path.
However, the command *does* work for the files inside KDE appbundles installed in /Applications/MacPorts/KDE4 . Go figure why ...

http://permalink.gmane.org/gmane.os.apple.macports.devel/26581

--
Daniel J. Luke
+========================================================+
| *---------------- ***@geeklair.net ----------------* |
| *-------------- http://www.geeklair.net -------------* |
+========================================================+
| Opinions expressed are mine and do not necessarily |
| reflect the opinions of my employer. |
+========================================================+

[Clemens Lang]

Hi,

Post by Daniel J. Luke
http://permalink.gmane.org/gmane.os.apple.macports.devel/26581

I think that's a good change. Want to go ahead and provide a
patch/commit it before we forget about it again?

We could also add a step that "de-normalizes" the MacPorts prefix if
it is a symlink, e.g. something along the lines of:


package require struct::list

set fileComponents [file split [file normalize $filename]]
set normalizedPrefix [file split [file normalize $prefix]]
set prefixLen [llength $normalizedPrefix]

if {::struct::list equal [lrange $fileComponents 0 $prefixLen] $normalizedPrefix} {
set prefixComponents [file split $prefix]
set fileComponents [lreplace 0 $prefixLen-1] $prefixComponents
}

set filename [file join {*}$fileComponents]

[René J.V. Bertin]

On Saturday October 04 2014 13:02:30 Clemens Lang wrote:

Hi,

Post by Clemens Lang
I think that's a good change. Want to go ahead and provide a
patch/commit it before we forget about it again?
We could also add a step that "de-normalizes" the MacPorts prefix if

I hope you're suggesting something that makes sure that no normalised paths are being stored, so as to make a /opt/local symlink as transparent as it could be expected to be? Which would also get rid of the unreadable pathnames in /opt/local/var/macports/build c.s. ... (And incidentally, make it easier to change the name/location of the actual tree to which /opt/local points) ?

R.

[Clemens Lang]

Hi,

Post by René J.V. Bertin
I hope you're suggesting something that makes sure that no normalised paths are
being stored, so as to make a /opt/local symlink as transparent as it could be
expected to be? Which would also get rid of the unreadable pathnames in
/opt/local/var/macports/build c.s. ... (And incidentally, make it easier to
change the name/location of the actual tree to which /opt/local points) ?

I'm suggesting something that normalizes everything besides the MacPorts prefix.
That's currently already implied for all other paths, because we don't normalize
(which is exactly why symlinking prefix even works at all), but port provides
breaks in this situation, because it does in fact normalize.

Not sure what you mean with `unreadable pathnames in /opt/local/var/macports/build`
though.

[René J.V. Bertin]

On Saturday October 04 2014 13:27:53 Clemens Lang wrote:

Hi,

Post by Clemens Lang
I'm suggesting something that normalizes everything besides the MacPorts prefix.

Why normalise at all?

Post by Clemens Lang
Not sure what you mean with `unreadable pathnames in /opt/local/var/macports/build`
though.

`/Volumes/Debian/MacPorts/var/macports/build/_Volumes_Debian_MP6_var_macports_sources_rsync.macports.org_release_ports_kde_kdepim4-runtime/kdepim4-runtime/work/kdepim-runtime-4.12.5/`

vs.

`/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_kde_kdepim4-runtime/kdepim4-runtime/work/kdepim-runtime-4.12.5/`

Not MUCH more readable, but at least it contains no capital letters ...

R.

[Clemens Lang]

Hi,

Post by René J.V. Bertin
Why normalise at all?

Relative paths on the command line, absolute paths in the database. Plus
you might be in a directory symlink that wouldn't be known to the registry
when using port provides.

Post by René J.V. Bertin
`/Volumes/Debian/MacPorts/var/macports/build/_Volumes_Debian_MP6_var_macports_sources_rsync.macports.org_release_ports_kde_kdepim4-runtime/kdepim4-runtime/work/kdepim-runtime-4.12.5/`
vs.
`/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_kde_kdepim4-runtime/kdepim4-runtime/work/kdepim-runtime-4.12.5/`

Not what this thread is about, not likely to change, and not an issue IMO.

[David Evans]

Post by René J.V. Bertin
'evening!
I'm doing a selfupdate, which includes upgrading ffmpeg +gpl2+nonfree+universal+x11 from 2.3.3_0 to 2.4.1 . That went fine on 10.6, but on my 10.9 VM I'm running into an issue involving liblzma, which apparently is not universal, and thus gives me a failure when merging libavcodec.pc .
Curiously, I have neither port:lzma nor port:liblzma installed (on both set-ups). `port provides` doesn't work for me so I'm at a loss where the liblzma.dylib comes from ...
In any case there seems to be something fishy with ffmpeg's Portfile?
Any suggestions?
R.
_______________________________________________
macports-users mailing list
https://lists.macosforge.org/mailman/listinfo/macports-users

Inspection shows that lzma support is optional for ffmpeg depending on
whether or not liblzma can be autodetected.

In r126103, I've modified the ffmpeg port to explicitly enable lzma
support and have added a dependency on port xz which provides liblzma in
Macports and it builds +universal.
port liblzma is obsolete, replaced by xz. port lzma does not provide
the library only the utility.

Please update your ports and upgrade ffmpeg. I believe this should
solve your problem. If not, please file a ticket against ffmpeg.