Opened 7 years ago

Closed 4 years ago

Last modified 4 years ago

#54633 closed defect (fixed)

ffmpeg, ffmpeg-devel: not distributable on Snow Leopard

Reported by: ryandesign (Ryan Carsten Schmidt) Owned by: mascguy (Christopher Nielsen)
Priority: Normal Milestone:
Component: ports Version:
Keywords: Cc: jeremyhu (Jeremy Huddleston Sequoia), mojca (Mojca Miklavec), danchr (Dan Villiom Podlaski Christiansen), dbevans (David B. Evans)
Port: ffmpeg, ffmpeg-devel

Description (last modified by mascguy (Christopher Nielsen))

ffmpeg and ffmpeg-devel are not distributable on 10.6, but they are on all later MacOS releases.

Any idea how we could fix them to be distributable on 10.6 too?

Change History (20)

comment:1 Changed 7 years ago by mojca (Mojca Miklavec)

Cc: mojca added

comment:2 Changed 4 years ago by mascguy (Christopher Nielsen)

Cc: mascguy added

comment:3 Changed 4 years ago by mascguy (Christopher Nielsen)

Also see comments in duplicate ticket issue:62851.

comment:4 Changed 4 years ago by mascguy (Christopher Nielsen)

Cc: danchr added

FYI, I built MacPorts with @Danchr's excellent work related to issue:60315, and here's our answer:

$ port licensecheck ffmpeg
--->  Checking license for ffmpeg
Warning: "ffmpeg" is not distributable because its license "GPL" conflicts with license "OpenSSL": librsvg -> glib2 -> python27 -> openssl
Warning: "ffmpeg" is not distributable because its license "GPL" conflicts with license "SSLeay": librsvg -> glib2 -> python27 -> openssl

After the addition of license_noconflict openssl:

$ port licensecheck ffmpeg
--->  Checking license for ffmpeg
"ffmpeg" is distributable

So my first thought is, we REALLY need to add Dan's licensecheck functionality to base. IMHO, I think we should strongly consider adding it to the pending release (albeit with the change to move license data under _resources), as the risk is minimal.

As for ffmpeg, given the dependency chain, is the openssl license a problem in this case?

Last edited 4 years ago by mascguy (Christopher Nielsen) (previous) (diff)

comment:5 Changed 4 years ago by mascguy (Christopher Nielsen)

Cc: dbevans added; mascguy removed
Owner: changed from dbevans to mascguy
Status: newassigned

comment:6 Changed 4 years ago by kencu (Ken)

the ffmpeg license is supposed to be LGPL-2+, which is distributable, unless you specifically enable the gpl2 variant, and then it is non-distributable due to the openssl mess (which disappears this year with openssl 3.0, we all hope).

Did that get messed up?

comment:7 Changed 4 years ago by mascguy (Christopher Nielsen)

Summary: ffmpeg, ffmpeg-devel: not distributable on Snow Leopard or Lionffmpeg, ffmpeg-devel: not distributable on Snow Leopard

comment:8 Changed 4 years ago by mascguy (Christopher Nielsen)

Ken, this is only happening for the MacOS 10.6 case, which is curious. And +gpl2 has been the default for a long time, without an issue for later MacOS releases.

Last edited 4 years ago by mascguy (Christopher Nielsen) (previous) (diff)

comment:9 Changed 4 years ago by mascguy (Christopher Nielsen)

Description: modified (diff)

comment:10 Changed 4 years ago by mascguy (Christopher Nielsen)

Description: modified (diff)

comment:11 Changed 4 years ago by kencu (Ken)

it looks like the gpl2 variant is enabled by default somehow. for any software that has a chain that leads to openssl, that makes it non-distributable. Disabling gpl2 on 10.6 (etc) should do it.

IMHO, YMMV, etc

comment:12 Changed 4 years ago by kencu (Ken)

maybe some dep of a dep of a dep added a dep on openssl and brought the whole house of cards down...

comment:13 Changed 4 years ago by kencu (Ken)

gpl2+ was enabled 10 years ago, I see. Looks like not a good idea to disable gpl2+. probably shouldn't even be a variant, just enable it always, but leave that for Ryan and Josh.

So, 10.6ers are still building it then, I guess until openssl 3.0 comes along.

comment:14 Changed 4 years ago by mascguy (Christopher Nielsen)

Well, the output of port licensecheck shows us the dependency chain, so there's no longer a mystery:

license "GPL" conflicts with license "OpenSSL": librsvg -> glib2 -> python27 -> openssl
license "GPL" conflicts with license "SSLeay": librsvg -> glib2 -> python27 -> openssl

Taking this a step further, and reviewing the dependencies of glib2:

$ port deps glib2 os.major=10
Full Name: glib2 @2.58.3_1+x11
Extract Dependencies: xz
Build Dependencies:   autoconf, automake, libtool, libxml2, pkgconfig, clang-3.7
Library Dependencies: gettext, libffi, libiconv, pcre, zlib, python27, libcxx

$ port deps glib2 os.major=11
Full Name: glib2 @2.58.3_1+x11
Extract Dependencies: xz
Build Dependencies:   autoconf, automake, libtool, libxml2, pkgconfig, clang-3.7
Library Dependencies: gettext, libffi, libiconv, pcre, zlib

We can see that glib2 has a lib dependency on python27, that only exists for 10.6. And per the glib2 portfile:

if {${os.platform} eq "darwin" && ${os.major} <= 10} {
    # Requires python 2.7 as of 2.53.4
    # See https://bugzilla.gnome.org/show_bug.cgi?id=785193
    depends_lib-append      port:python27
    configure.python        ${prefix}/bin/python2.7
}

So I think that's our answer. Ryan, does glib2 truly have a lib dependency on python27? Or is it build-time only?

comment:15 in reply to:  14 ; Changed 4 years ago by ryandesign (Ryan Carsten Schmidt)

Replying to mascguy:

Ryan, does glib2 truly have a lib dependency on python27?

Yes, according to #17530.

comment:16 in reply to:  4 ; Changed 4 years ago by ryandesign (Ryan Carsten Schmidt)

Replying to mascguy:

So my first thought is, we REALLY need to add Dan's licensecheck functionality to base. IMHO, I think we should strongly consider adding it to the pending release

Josh tagged 2.7.0-rc1 tonight, so that would mean that only commits that fix showstopping bugs should be cherry-picked to the 2.7 branch at this point. Let's get the fix in master and it can go into 2.7.1.

comment:17 in reply to:  15 Changed 4 years ago by mascguy (Christopher Nielsen)

Replying to ryandesign:

Replying to mascguy:

Ryan, does glib2 truly have a lib dependency on python27?

Yes, according to #17530.

Okay, so is it fair to say that binaries aren't publishable for ffmpeg [on 10.6], until the upstream openssl license changes?

comment:18 in reply to:  16 Changed 4 years ago by mascguy (Christopher Nielsen)

Replying to ryandesign:

Replying to mascguy:

So my first thought is, we REALLY need to add Dan's licensecheck functionality to base. IMHO, I think we should strongly consider adding it to the pending release

Josh tagged 2.7.0-rc1 tonight, so that would mean that only commits that fix showstopping bugs should be cherry-picked to the 2.7 branch at this point. Let's get the fix in master and it can go into 2.7.1.

Sounds good. I reached out to the Dan almost a week ago, and haven't heard back. So I'll close his PR, and open a new one, with the updated work.

comment:19 Changed 4 years ago by mascguy (Christopher Nielsen)

Resolution: fixed
Status: assignedclosed

This issue will be resolved once the upstream openssl license changes. Closing.

comment:20 Changed 4 years ago by ryandesign (Ryan Carsten Schmidt)

I don't know whether it is legal to specify an openssl exception for this case; I have not attempted to figure it out.

It would be better to update the existing PR than to close it and open a new one.

Note: See TracTickets for help on using tickets.