[ITP] openh264 (2.3.1)

[ITP] openh264 (2.3.1)

[Takashi Yano]

I would like to propose new package openh264, which is
a H264 video codec library. This is needed by ffmpeg
package I had proposed, and also provided for ffmpeg-free
package in fedora.

I already prepared the package at the following location.

https://tyan0.yr32.net/cygwin/x86_64/release/openh264/

-- 
Takashi Yano <takashi.yano@nifty.ne.jp>

Re: [ITP] openh264 (2.3.1)

[Jon Turney]

On 05/02/2023 08:37, Takashi Yano via Cygwin-apps wrote:
> I would like to propose new package openh264, which is
> a H264 video codec library. This is needed by ffmpeg
> package I had proposed, and also provided for ffmpeg-free
> package in fedora.
> 
> I already prepared the package at the following location.
> 
> https://tyan0.yr32.net/cygwin/x86_64/release/openh264/

libopenh264 contains a libopenh264.dll file.  This doesn't match the 
naming convention for cygwin DLLs.  This might need patching in the make 
machinery somewhere.

Re: [ITP] openh264 (2.3.1)

[Yaakov Selkowitz]

On Sun, 2023-02-05 at 17:37 +0900, Takashi Yano via Cygwin-apps wrote:
> I would like to propose new package openh264, which is
> a H264 video codec library. This is needed by ffmpeg
> package I had proposed, and also provided for ffmpeg-free
> package in fedora.
> 
> I already prepared the package at the following location.
> 
> https://tyan0.yr32.net/cygwin/x86_64/release/openh264/

Unfortunately, this cannot be included in the Cygwin distribution.  Cisco's
patent license only covers binaries they distribute.  Fedora has a special
arrangement with Cisco where they build their RPMs on Fedora infrastructure,
but the packages are hosted by Cisco in a separate repository.

-- 
Yaakov

Re: [ITP] openh264 (2.3.1)

[Brian Inglis]

On 2023-02-05 19:44, Yaakov Selkowitz via Cygwin-apps wrote:
> On Sun, 2023-02-05 at 17:37 +0900, Takashi Yano via Cygwin-apps wrote:
>> I would like to propose new package openh264, which is
>> a H264 video codec library. This is needed by ffmpeg
>> package I had proposed, and also provided for ffmpeg-free
>> package in fedora.
>>
>> I already prepared the package at the following location.
>>
>> https://tyan0.yr32.net/cygwin/x86_64/release/openh264/

> Unfortunately, this cannot be included in the Cygwin distribution.  Cisco's
> patent license only covers binaries they distribute.  Fedora has a special
> arrangement with Cisco where they build their RPMs on Fedora infrastructure,
> but the packages are hosted by Cisco in a separate repository.

http://www.openh264.org/
"Cisco has taken their H.264 implementation, and open sourced it under BSD 
license terms. Development and maintenance will be overseen by a board from 
industry and the open source community. Furthermore, we have provided a binary 
form suitable for inclusion in applications across a number of different 
operating systems, and make this binary module available for download from the 
Internet. We will not pass on our MPEG-LA licensing costs for this module, and 
based on the current licensing environment, this will effectively make H.264 
free for use on supported platforms."

http://blogs.cisco.com/collaboration/open-source-h-264-removes-barriers-webrtc

http://blogs.cisco.com/collaboration/open-source-h-264-removes-barriers-webrtc

https://github.com/cisco/openh264
"For Windows Builds
"make" must be installed. It is recommended to install the Cygwin and "make" 
must be selected to be included in the installation. After the installation, 
please add the Cygwin bin path to your PATH.
License
BSD, see LICENSE file for details."

-- 
Take care. Thanks, Brian Inglis			Calgary, Alberta, Canada

La perfection est atteinte			Perfection is achieved
non pas lorsqu'il n'y a plus rien à ajouter	not when there is no more to add
mais lorsqu'il n'y a plus rien à retirer	but when there is no more to cut
			-- Antoine de Saint-Exupéry

Re: [ITP] openh264 (2.3.1)

[Yaakov Selkowitz]

On Sun, 2023-02-05 at 22:11 -0700, Brian Inglis wrote:
> On 2023-02-05 19:44, Yaakov Selkowitz via Cygwin-apps wrote:
> > On Sun, 2023-02-05 at 17:37 +0900, Takashi Yano via Cygwin-apps wrote:
> > > I would like to propose new package openh264, which is
> > > a H264 video codec library. This is needed by ffmpeg
> > > package I had proposed, and also provided for ffmpeg-free
> > > package in fedora.
> > > 
> > > I already prepared the package at the following location.
> > > 
> > > https://tyan0.yr32.net/cygwin/x86_64/release/openh264/
> 
> > Unfortunately, this cannot be included in the Cygwin distribution. 
> > Cisco's
> > patent license only covers binaries they distribute.  Fedora has a special
> > arrangement with Cisco where they build their RPMs on Fedora
> > infrastructure,
> > but the packages are hosted by Cisco in a separate repository.
> 
> http://www.openh264.org/
> "Cisco has taken their H.264 implementation, and open sourced it under BSD 
> license terms. Development and maintenance will be overseen by a board from 
> industry and the open source community. Furthermore, we have provided a
> binary 
> form suitable for inclusion in applications across a number of different 
> operating systems, and make this binary module available for download from
> the 
> Internet. We will not pass on our MPEG-LA licensing costs for this module,
> and 
> based on the current licensing environment, this will effectively make H.264
> free for use on supported platforms."

This is exactly the point.  Cisco paid for a license, but that license is
limited to binaries they distribute.  Unfortunately, I doubt that Cisco will
do the same for Cygwin.

-- 
Yaakov

Re: [ITP] openh264 (2.3.1)

[Takashi Yano]

On Mon, 06 Feb 2023 00:16:45 -0500
Yaakov Selkowitz via Cygwin-apps <cygwin-apps@cygwin.com> wrote:

> On Sun, 2023-02-05 at 22:11 -0700, Brian Inglis wrote:
> > On 2023-02-05 19:44, Yaakov Selkowitz via Cygwin-apps wrote:
> > > On Sun, 2023-02-05 at 17:37 +0900, Takashi Yano via Cygwin-apps wrote:
> > > > I would like to propose new package openh264, which is
> > > > a H264 video codec library. This is needed by ffmpeg
> > > > package I had proposed, and also provided for ffmpeg-free
> > > > package in fedora.
> > > > 
> > > > I already prepared the package at the following location.
> > > > 
> > > > https://tyan0.yr32.net/cygwin/x86_64/release/openh264/
> > 
> > > Unfortunately, this cannot be included in the Cygwin distribution. 
> > > Cisco's
> > > patent license only covers binaries they distribute.  Fedora has a special
> > > arrangement with Cisco where they build their RPMs on Fedora
> > > infrastructure,
> > > but the packages are hosted by Cisco in a separate repository.
> > 
> > http://www.openh264.org/
> > "Cisco has taken their H.264 implementation, and open sourced it under BSD 
> > license terms. Development and maintenance will be overseen by a board from 
> > industry and the open source community. Furthermore, we have provided a
> > binary 
> > form suitable for inclusion in applications across a number of different 
> > operating systems, and make this binary module available for download from
> > the 
> > Internet. We will not pass on our MPEG-LA licensing costs for this module,
> > and 
> > based on the current licensing environment, this will effectively make H.264
> > free for use on supported platforms."
> 
> This is exactly the point.  Cisco paid for a license, but that license is
> limited to binaries they distribute.  Unfortunately, I doubt that Cisco will
> do the same for Cygwin.

OK. How about distributing only headers as cygwin package
for building ffmpeg?

-- 
Takashi Yano <takashi.yano@nifty.ne.jp>

Re: [ITP] openh264 (2.3.1)

[Takashi Yano]

[-- Attachment #1: Type: text/plain, Size: 867 bytes --]

On Sun, 5 Feb 2023 16:36:21 +0000
Jon Turney wrote:
> On 05/02/2023 08:37, Takashi Yano via Cygwin-apps wrote:
> > I would like to propose new package openh264, which is
> > a H264 video codec library. This is needed by ffmpeg
> > package I had proposed, and also provided for ffmpeg-free
> > package in fedora.
> > 
> > I already prepared the package at the following location.
> > 
> > https://tyan0.yr32.net/cygwin/x86_64/release/openh264/
> 
> libopenh264 contains a libopenh264.dll file.  This doesn't match the 
> naming convention for cygwin DLLs.  This might need patching in the make 
> machinery somewhere.

As Yaakov mentioned, it seems that binary libopenh264 package
cannot be distributed as a cygwin package, so I re-package
it so that it includes only the header files.

Please check attached cygport file.

-- 
Takashi Yano <takashi.yano@nifty.ne.jp>

[-- Attachment #2: openh264.cygport --]
[-- Type: text/plain, Size: 1624 bytes --]

NAME="openh264"
VERSION=2.3.1
RELEASE=1
CATEGORY="Video"
SUMMARY="H.264 codec library (headers only)"
DESCRIPTION="OpenH264 is a codec library which supports H.264 encoding and decoding. It is suitable for use in real time applications such as WebRTC. This package has only headers. If you need library binary itself, you can download it from https://github.com/cisco/openh264/."
HOMEPAGE="https://www.openh264.org/"
LICENSE="BSD-2-Clause"
ARCH="noarch" # This is noarch because it's just header files.

SRC_URI="${NAME}-headers-${VERSION}.tar.xz"

# Make dummy source file for prep if the cleaned one is not exist.
if [ ! -f ${SRC_URI} ]
then
	mkdir ${NAME}-${VERSION}
	touch ${NAME}-${VERSION}/dummy
	tar acf ${SRC_URI} ${NAME}-${VERSION}
	rm -rf ${NAME}-${VERSION}
fi

CYGPORT_USE_UNSTABLE_API=1
src_unpack_hook() {
	if [ $(tar tvf ../../../${SRC_URI} | wc -l)  -eq 2 ] # Source file is dummy
	then
		NV=${NAME}-${VERSION}
		pushd ..
		rm -rf ${NV} # Remove dummy source file.
		# Download original source file.
		wget https://github.com/cisco/openh264/archive/refs/tags/v${VERSION}.tar.gz
		tar xf v${VERSION}.tar.gz
		rm -f v${VERSION}.tar.gz
		# Make source file which has only necessary header files.
		tar acf ../../${NAME}-headers-${VERSION}.tar.xz ${NV}/codec/api/wels/*.h
		# Update source directory.
		rm -rf ${NV}
		tar xf ../../${NAME}-headers-${VERSION}.tar.xz
		popd
	fi
}
	
PKG_NAMES="libopenh264-headers"
libopenh264_headers_CATEGORY="Video Devel"
libopenh264_headers_CONTENTS="usr/include"

src_compile() {
	:
}

src_install() {
	mkdir -p ${D}/usr/include
	ln -fs ${S}/codec/api/wels ${D}/usr/include/.
}

Re: [ITP] openh264 (2.3.1)

[Lee]

On 2/6/23, Yaakov Selkowitz via Cygwin-apps <cygwin-apps@cygwin.com> wrote:
> On Sun, 2023-02-05 at 22:11 -0700, Brian Inglis wrote:
>> On 2023-02-05 19:44, Yaakov Selkowitz via Cygwin-apps wrote:
>> > On Sun, 2023-02-05 at 17:37 +0900, Takashi Yano via Cygwin-apps wrote:
>> > > I would like to propose new package openh264, which is
>> > > a H264 video codec library. This is needed by ffmpeg
>> > > package I had proposed, and also provided for ffmpeg-free
>> > > package in fedora.
>> > >
>> > > I already prepared the package at the following location.
>> > >
>> > > https://tyan0.yr32.net/cygwin/x86_64/release/openh264/
>>
>> > Unfortunately, this cannot be included in the Cygwin distribution.
>> > Cisco's
>> > patent license only covers binaries they distribute.  Fedora has a
>> > special
>> > arrangement with Cisco where they build their RPMs on Fedora
>> > infrastructure,
>> > but the packages are hosted by Cisco in a separate repository.
>>
>> http://www.openh264.org/
>> "Cisco has taken their H.264 implementation, and open sourced it under BSD
>>
>> license terms. Development and maintenance will be overseen by a board
>> from
>> industry and the open source community. Furthermore, we have provided a
>> binary
>> form suitable for inclusion in applications across a number of different
>> operating systems, and make this binary module available for download
>> from
>> the
>> Internet. We will not pass on our MPEG-LA licensing costs for this
>> module,
>> and
>> based on the current licensing environment, this will effectively make
>> H.264
>> free for use on supported platforms."
>
> This is exactly the point.  Cisco paid for a license, but that license is
> limited to binaries they distribute.

IANAL but it sure looks like redistribution is allowed:

cisco/openh264 is licensed under the
BSD 2-Clause "Simplified" License

  https://github.com/cisco/openh264/blob/master/LICENSE
    <.. snip ..>
  Redistribution and use in source and binary forms, with or without
modification,
are permitted provided that the following conditions are met:

Lee

Re: [ITP] openh264 (2.3.1)

[Brian Inglis]

On 2023-02-05 22:16, Yaakov Selkowitz via Cygwin-apps wrote:
> On Sun, 2023-02-05 at 22:11 -0700, Brian Inglis wrote:
>> On 2023-02-05 19:44, Yaakov Selkowitz via Cygwin-apps wrote:
>>> On Sun, 2023-02-05 at 17:37 +0900, Takashi Yano via Cygwin-apps wrote:
>>>> I would like to propose new package openh264, which is
>>>> a H264 video codec library. This is needed by ffmpeg
>>>> package I had proposed, and also provided for ffmpeg-free
>>>> package in fedora.
>>>>
>>>> I already prepared the package at the following location.
>>>>
>>>> https://tyan0.yr32.net/cygwin/x86_64/release/openh264/
>>
>>> Unfortunately, this cannot be included in the Cygwin distribution.
>>> Cisco's
>>> patent license only covers binaries they distribute.  Fedora has a special
>>> arrangement with Cisco where they build their RPMs on Fedora
>>> infrastructure,
>>> but the packages are hosted by Cisco in a separate repository.
>>
>> http://www.openh264.org/
>> "Cisco has taken their H.264 implementation, and open sourced it under BSD
>> license terms. Development and maintenance will be overseen by a board from
>> industry and the open source community. Furthermore, we have provided a
>> binary form suitable for inclusion in applications across a number of different
>> operating systems, and make this binary module available for download from
>> the Internet. We will not pass on our MPEG-LA licensing costs for this module,
>> and based on the current licensing environment, this will effectively make H.264
>> free for use on supported platforms."

> This is exactly the point.  Cisco paid for a license, but that license is
> limited to binaries they distribute. Unfortunately, I doubt that Cisco will
> do the same for Cygwin.

Other distros and 3rd party repos provide the libraries and utilities in their 
free-est repos e.g. DSC and DFSG conforming: what makes Fedora different, and 
why has that any impact on what Cygwin may provide?

Would it make a difference if we moved from RH servers to SFC infrastructure, or 
servers outside the US?

-- 
Take care. Thanks, Brian Inglis			Calgary, Alberta, Canada

La perfection est atteinte			Perfection is achieved
non pas lorsqu'il n'y a plus rien à ajouter	not when there is no more to add
mais lorsqu'il n'y a plus rien à retirer	but when there is no more to cut
			-- Antoine de Saint-Exupéry

Re: [ITP] openh264 (2.3.1)

[Takashi Yano]

Hi Yaakov,

On Mon, 6 Feb 2023 14:25:23 +0900
Takashi Yano wrote:
> On Mon, 06 Feb 2023 00:16:45 -0500
> Yaakov Selkowitz via Cygwin-apps <cygwin-apps@cygwin.com> wrote:
> > On Sun, 2023-02-05 at 22:11 -0700, Brian Inglis wrote:
> > > On 2023-02-05 19:44, Yaakov Selkowitz via Cygwin-apps wrote:
> > > > Unfortunately, this cannot be included in the Cygwin distribution. 
> > > > Cisco's
> > > > patent license only covers binaries they distribute.  Fedora has a special
> > > > arrangement with Cisco where they build their RPMs on Fedora
> > > > infrastructure,
> > > > but the packages are hosted by Cisco in a separate repository.
> > > 
> > > http://www.openh264.org/
> > > "Cisco has taken their H.264 implementation, and open sourced it under BSD 
> > > license terms. Development and maintenance will be overseen by a board from 
> > > industry and the open source community. Furthermore, we have provided a
> > > binary 
> > > form suitable for inclusion in applications across a number of different 
> > > operating systems, and make this binary module available for download from
> > > the 
> > > Internet. We will not pass on our MPEG-LA licensing costs for this module,
> > > and 
> > > based on the current licensing environment, this will effectively make H.264
> > > free for use on supported platforms."
> > 
> > This is exactly the point.  Cisco paid for a license, but that license is
> > limited to binaries they distribute.  Unfortunately, I doubt that Cisco will
> > do the same for Cygwin.
> 
> OK. How about distributing only headers as cygwin package
> for building ffmpeg?

Ping?

-- 
Takashi Yano <takashi.yano@nifty.ne.jp>

Re: [ITP] openh264 (2.3.1)

[Yaakov Selkowitz]

On Mon, 2023-02-06 at 14:25 +0900, Takashi Yano via Cygwin-apps wrote:
> On Mon, 06 Feb 2023 00:16:45 -0500
> Yaakov Selkowitz via Cygwin-apps <cygwin-apps@cygwin.com> wrote:
> 
> > On Sun, 2023-02-05 at 22:11 -0700, Brian Inglis wrote:
> > > On 2023-02-05 19:44, Yaakov Selkowitz via Cygwin-apps wrote:
> > > > On Sun, 2023-02-05 at 17:37 +0900, Takashi Yano via Cygwin-apps wrote:
> > > > > I would like to propose new package openh264, which is
> > > > > a H264 video codec library. This is needed by ffmpeg
> > > > > package I had proposed, and also provided for ffmpeg-free
> > > > > package in fedora.
> > > > > 
> > > > > I already prepared the package at the following location.
> > > > > 
> > > > > https://tyan0.yr32.net/cygwin/x86_64/release/openh264/
> > > 
> > > > Unfortunately, this cannot be included in the Cygwin distribution. 
> > > > Cisco's
> > > > patent license only covers binaries they distribute.  Fedora has a
> > > > special
> > > > arrangement with Cisco where they build their RPMs on Fedora
> > > > infrastructure,
> > > > but the packages are hosted by Cisco in a separate repository.
> > > 
> > > http://www.openh264.org/
> > > "Cisco has taken their H.264 implementation, and open sourced it under
> > > BSD 
> > > license terms. Development and maintenance will be overseen by a board
> > > from 
> > > industry and the open source community. Furthermore, we have provided a
> > > binary 
> > > form suitable for inclusion in applications across a number of different
> > > operating systems, and make this binary module available for download
> > > from
> > > the 
> > > Internet. We will not pass on our MPEG-LA licensing costs for this
> > > module,
> > > and 
> > > based on the current licensing environment, this will effectively make
> > > H.264
> > > free for use on supported platforms."
> > 
> > This is exactly the point.  Cisco paid for a license, but that license is
> > limited to binaries they distribute.  Unfortunately, I doubt that Cisco
> > will
> > do the same for Cygwin.
> 
> OK. How about distributing only headers as cygwin package
> for building ffmpeg?

The Fedora package includes openh264 headers and a patch which will dlopen()
libopenh264 if present.  These could be used (with the modification
libopenh264.so.N -> cygopenh264-N.dll of course) in the Cygwin package.

-- 
Yaakov

Re: [ITP] openh264 (2.3.1)

[Takashi Yano]

On Thu, 09 Feb 2023 23:35:53 -0500
Yaakov Selkowitz wrote:
> The Fedora package includes openh264 headers and a patch which will dlopen()
> libopenh264 if present.  These could be used (with the modification
> libopenh264.so.N -> cygopenh264-N.dll of course) in the Cygwin package.

Thanks for the reply.

libopenh264_dlopen.h in Fedra's ffmpeg-free package includes
#include <wels/codec_api.h>
#include <wels/codec_ver.h>
and wels/codec_api.h includes
#include "codec_app_def.h"
#include "codec_def.h"
.

These are from cisco's openh264 source files. Can we distribute
these headers as a cygwin package, (That is:
  https://tyan0.yr32.net/cygwin/noarch/release/openh264/
) ?

-- 
Takashi Yano <takashi.yano@nifty.ne.jp>

Re: [ITP] openh264 (2.3.1)

[Takashi Yano]

On Fri, 10 Feb 2023 14:05:31 +0900
Takashi Yano via Cygwin-apps <cygwin-apps@cygwin.com> wrote:

> On Thu, 09 Feb 2023 23:35:53 -0500
> Yaakov Selkowitz wrote:
> > The Fedora package includes openh264 headers and a patch which will dlopen()
> > libopenh264 if present.  These could be used (with the modification
> > libopenh264.so.N -> cygopenh264-N.dll of course) in the Cygwin package.
> 
> Thanks for the reply.
> 
> libopenh264_dlopen.h in Fedra's ffmpeg-free package includes
> #include <wels/codec_api.h>
> #include <wels/codec_ver.h>
> and wels/codec_api.h includes
> #include "codec_app_def.h"
> #include "codec_def.h"
> .
> 
> These are from cisco's openh264 source files. Can we distribute
> these headers as a cygwin package, (That is:
>   https://tyan0.yr32.net/cygwin/noarch/release/openh264/
> ) ?

Ah, I see. Fedora's ffmpeg source package includes
https://src.fedoraproject.org/repo/pkgs/ffmpeg/ffmpeg-dlopen-headers.tar.xz
wihch has wels/*.h. You meant this can be used.

Thanks!

-- 
Takashi Yano <takashi.yano@nifty.ne.jp>

Re: [ITP] openh264 (2.3.1)

[Takashi Yano]

On Fri, 10 Feb 2023 14:18:50 +0900
Takashi Yano wrote:
> On Fri, 10 Feb 2023 14:05:31 +0900
> Takashi Yano via Cygwin-apps <cygwin-apps@cygwin.com> wrote:
> 
> > On Thu, 09 Feb 2023 23:35:53 -0500
> > Yaakov Selkowitz wrote:
> > > The Fedora package includes openh264 headers and a patch which will dlopen()
> > > libopenh264 if present.  These could be used (with the modification
> > > libopenh264.so.N -> cygopenh264-N.dll of course) in the Cygwin package.
> > 
> > Thanks for the reply.
> > 
> > libopenh264_dlopen.h in Fedra's ffmpeg-free package includes
> > #include <wels/codec_api.h>
> > #include <wels/codec_ver.h>
> > and wels/codec_api.h includes
> > #include "codec_app_def.h"
> > #include "codec_def.h"
> > .
> > 
> > These are from cisco's openh264 source files. Can we distribute
> > these headers as a cygwin package, (That is:
> >   https://tyan0.yr32.net/cygwin/noarch/release/openh264/
> > ) ?
> 
> Ah, I see. Fedora's ffmpeg source package includes
> https://src.fedoraproject.org/repo/pkgs/ffmpeg/ffmpeg-dlopen-headers.tar.xz
> wihch has wels/*.h. You meant this can be used.

Jon, should we include these headers as a part of ffmpeg
source package? Or distribute as another package like
https://tyan0.yr32.net/cygwin/noarch/release/openh264/ ?

-- 
Takashi Yano <takashi.yano@nifty.ne.jp>

Re: [ITP] openh264 (2.3.1)

[Jon Turney]

On 10/02/2023 05:25, Takashi Yano via Cygwin-apps wrote:
>>
>> Ah, I see. Fedora's ffmpeg source package includes
>> https://src.fedoraproject.org/repo/pkgs/ffmpeg/ffmpeg-dlopen-headers.tar.xz
>> wihch has wels/*.h. You meant this can be used.
> 
> Jon, should we include these headers as a part of ffmpeg
> source package? Or distribute as another package like
> https://tyan0.yr32.net/cygwin/noarch/release/openh264/ ?
> 

I don't know.

How do other distros approach this problem?
What's least effort for you?

Re: [ITP] openh264 (2.3.1)

[Brian Inglis]

On 2023-02-13 11:30, Jon Turney via Cygwin-apps wrote:
> On 10/02/2023 05:25, Takashi Yano via Cygwin-apps wrote:
>>>
>>> Ah, I see. Fedora's ffmpeg source package includes
>>> https://src.fedoraproject.org/repo/pkgs/ffmpeg/ffmpeg-dlopen-headers.tar.xz
>>> wihch has wels/*.h. You meant this can be used.
>>
>> Jon, should we include these headers as a part of ffmpeg
>> source package? Or distribute as another package like
>> https://tyan0.yr32.net/cygwin/noarch/release/openh264/ ?

> I don't know.
> 
> How do other distros approach this problem?
> What's least effort for you?

Debian downloads binaries directly from Cisco during pkg install.

-- 
Take care. Thanks, Brian Inglis			Calgary, Alberta, Canada

La perfection est atteinte			Perfection is achieved
non pas lorsqu'il n'y a plus rien à ajouter	not when there is no more to add
mais lorsqu'il n'y a plus rien à retirer	but when there is no more to cut
			-- Antoine de Saint-Exupéry

Re: [ITP] openh264 (2.3.1)

[Takashi Yano]

[-- Attachment #1: Type: text/plain, Size: 1207 bytes --]

On Mon, 13 Feb 2023 12:03:02 -0700
Brian Inglis wrote:
> On 2023-02-13 11:30, Jon Turney via Cygwin-apps wrote:
> > On 10/02/2023 05:25, Takashi Yano via Cygwin-apps wrote:
> >>>
> >>> Ah, I see. Fedora's ffmpeg source package includes
> >>> https://src.fedoraproject.org/repo/pkgs/ffmpeg/ffmpeg-dlopen-headers.tar.xz
> >>> wihch has wels/*.h. You meant this can be used.
> >>
> >> Jon, should we include these headers as a part of ffmpeg
> >> source package? Or distribute as another package like
> >> https://tyan0.yr32.net/cygwin/noarch/release/openh264/ ?
> 
> > I don't know.
> > 
> > How do other distros approach this problem?
> > What's least effort for you?
> 
> Debian downloads binaries directly from Cisco during pkg install.

This seems great if acceptable. I have tried that in
cygport file.

The new cygport file does:
- The header files are placed in libopenh264-headers.
  I think this makes the license of the header files
  clearer than fedora's approach.
- The libopenh264 package includes only /etc/postinstall
  and /etc/preremove, which downloads/removes Cisco's dll
  (binary) as well as license file.

Jon, could you please have a look?

-- 
Takashi Yano <takashi.yano@nifty.ne.jp>

[-- Attachment #2: openh264.cygport --]
[-- Type: text/plain, Size: 2543 bytes --]

NAME="openh264"
VERSION=2.3.1
RELEASE=1
CATEGORY="Video"
SUMMARY="H.264 codec library by Cisco"
DESCRIPTION="OpenH264 is a codec library which supports H.264 encoding and decoding. It is suitable for use in real time applications such as WebRTC. The binary library (runtime) itself will be downloaded from http://ciscobinary.openh264.org/"
HOMEPAGE="https://www.openh264.org/"
LICENSE="BSD-2-Clause"
ARCH="noarch" # This is noarch because it's just header files and shell scrpits.

SRC_URI="${NAME}-headers-${VERSION}.tar.xz"

# Make dummy source file for prep if the cleaned one is not exist.
if [ ! -f ${SRC_URI} ]
then
	mkdir ${NAME}-${VERSION}
	touch ${NAME}-${VERSION}/dummy
	tar acf ${SRC_URI} ${NAME}-${VERSION}
	rm -rf ${NAME}-${VERSION}
fi

CYGPORT_USE_UNSTABLE_API=1
src_unpack_hook() {
	if [ $(tar tvf ../../../${SRC_URI} | wc -l)  -eq 2 ] # Source file is dummy
	then
		NV=${NAME}-${VERSION}
		pushd ..
		rm -rf ${NV} # Remove dummy source file.
		# Download original source file.
		wget https://github.com/cisco/openh264/archive/refs/tags/v${VERSION}.tar.gz
		tar xf v${VERSION}.tar.gz
		rm -f v${VERSION}.tar.gz
		# Make source file which has only necessary header files.
		tar acf ../../${NAME}-headers-${VERSION}.tar.xz ${NV}/codec/api/wels/*.h
		# Update source directory.
		rm -rf ${NV}
		tar xf ../../${NAME}-headers-${VERSION}.tar.xz
		popd
	fi
}
	
PKG_NAMES="libopenh264 libopenh264-headers"
libopenh264_CATEGORY="Video Libs"
libopenh264_CONTENTS="etc/"
libopenh264_REQUIRES="wget bzip2"
libopenh264_SUMMARY="H.264 codec library runtime by Cisco"
libopenh264_headers_CATEGORY="Video Devel"
libopenh264_headers_CONTENTS="usr/include"
libopenh264_headers_SUMMARY="H.264 codec library headers"

src_compile() {
	:
}

src_install() {
	mkdir -p ${D}/usr/include
	ln -fs ${S}/codec/api/wels ${D}/usr/include/.
	mkdir -p ${D}/etc/postinstall
	if [ $(uname -m) = "x86_64" ]
	then
		POSTFIX="win64"
	else
		POSTFIX="win32"
	fi
	cat << _EOF_ > ${D}/etc/postinstall/lib${NAME}.sh
#!/bin/sh
wget -q http://ciscobinary.openh264.org/${NAME}-${VERSION}-${POSTFIX}.dll.bz2 -O - | bunzip2 > /usr/bin/libopenh264.dll
chmod a+x /usr/bin/libopenh264.dll
mkdir -p /usr/share/doc/lib${NAME}
wget -q http://www.openh264.org/BINARY_LICENSE.txt -O - > /usr/share/doc/lib${NAME}/BINARY_LICENSE.txt
_EOF_
	chmod a+x ${D}/etc/postinstall/lib${NAME}.sh
	mkdir -p ${D}/etc/preremove
	cat << _EOF_ > ${D}/etc/preremove/lib${NAME}.sh
#!/bin/sh
rm -rf /usr/bin/libopenh264.dll /usr/share/doc/lib${NAME}
_EOF_
	chmod a+x ${D}/etc/preremove/lib${NAME}.sh
}

Re: [ITP] openh264 (2.3.1)

[ASSI]

Takashi Yano via Cygwin-apps writes:
> - The libopenh264 package includes only /etc/postinstall
>   and /etc/preremove, which downloads/removes Cisco's dll
>   (binary) as well as license file.

This is a Windows / MingW64 DLL, not a Cygwin one?

Also, since Cisco seems to be unable to correctly provide a cert chain
over the Akamai infrastructure to allow downloading via HTTPS, you
should have an SHA256 or SH512 check on the resulting file to assure
that the file matches what is expected.  It should probably be renamed
to .dll only after that step.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

SD adaptation for Waldorf microQ V2.22R2:
http://Synth.Stromeko.net/Downloads.html#WaldorfSDada

Re: [ITP] openh264 (2.3.1)

[Takashi Yano]

[-- Attachment #1: Type: text/plain, Size: 734 bytes --]

On Tue, 14 Feb 2023 12:02:37 +0100
ASSI wrote:
> Takashi Yano via Cygwin-apps writes:
> > - The libopenh264 package includes only /etc/postinstall
> >   and /etc/preremove, which downloads/removes Cisco's dll
> >   (binary) as well as license file.
> 
> This is a Windows / MingW64 DLL, not a Cygwin one?

Right.

> Also, since Cisco seems to be unable to correctly provide a cert chain
> over the Akamai infrastructure to allow downloading via HTTPS, you
> should have an SHA256 or SH512 check on the resulting file to assure
> that the file matches what is expected.  It should probably be renamed
> to .dll only after that step.

Thanks for the advice. I have revised the cygport file.

-- 
Takashi Yano <takashi.yano@nifty.ne.jp>

[-- Attachment #2: openh264.cygport --]
[-- Type: text/plain, Size: 2807 bytes --]

NAME="openh264"
VERSION=2.3.1
RELEASE=1
CATEGORY="Video"
SUMMARY="H.264 codec library by Cisco"
DESCRIPTION="OpenH264 is a codec library which supports H.264 encoding and decoding. It is suitable for use in real time applications such as WebRTC. The binary library (runtime) itself will be downloaded from http://ciscobinary.openh264.org/"
HOMEPAGE="https://www.openh264.org/"
LICENSE="BSD-2-Clause"
ARCH="noarch" # This is noarch because it's just header files and shell scrpits.

SRC_URI="${NAME}-headers-${VERSION}.tar.xz"

# Make dummy source file for prep if the cleaned one is not exist.
if [ ! -f ${SRC_URI} ]
then
	mkdir ${NAME}-${VERSION}
	touch ${NAME}-${VERSION}/dummy
	tar acf ${SRC_URI} ${NAME}-${VERSION}
	rm -rf ${NAME}-${VERSION}
fi

CYGPORT_USE_UNSTABLE_API=1
src_unpack_hook() {
	if [ $(tar tvf ../../../${SRC_URI} | wc -l)  -eq 2 ] # Source file is dummy
	then
		NV=${NAME}-${VERSION}
		pushd ..
		rm -rf ${NV} # Remove dummy source file.
		# Download original source file.
		wget https://github.com/cisco/openh264/archive/refs/tags/v${VERSION}.tar.gz
		tar xf v${VERSION}.tar.gz
		rm -f v${VERSION}.tar.gz
		# Make source file which has only necessary header files.
		tar acf ../../${NAME}-headers-${VERSION}.tar.xz ${NV}/codec/api/wels/*.h
		# Update source directory.
		rm -rf ${NV}
		tar xf ../../${NAME}-headers-${VERSION}.tar.xz
		popd
	fi
}
	
PKG_NAMES="libopenh264 libopenh264-headers"
libopenh264_CATEGORY="Video Libs"
libopenh264_CONTENTS="etc/"
libopenh264_REQUIRES="wget bzip2"
libopenh264_SUMMARY="H.264 codec library runtime by Cisco"
libopenh264_headers_CATEGORY="Video Devel"
libopenh264_headers_CONTENTS="usr/include"
libopenh264_headers_SUMMARY="H.264 codec library headers"

src_compile() {
	:
}

src_install() {
	mkdir -p ${D}/usr/include
	ln -fs ${S}/codec/api/wels ${D}/usr/include/.
	mkdir -p ${D}/etc/postinstall
	if [ $(uname -m) = "x86_64" ]
	then
		POSTFIX="win64"
	else
		POSTFIX="win32"
	fi
	cat << _EOF_ > ${D}/etc/postinstall/lib${NAME}.sh
#!/bin/sh
pushd /tmp
wget -q http://ciscobinary.openh264.org/${NAME}-${VERSION}-${POSTFIX}.dll.bz2 -O - | bunzip2 > ${NAME}-${VERSION}-${POSTFIX}.dll
if wget -q http://ciscobinary.openh264.org/${NAME}-${VERSION}-${POSTFIX}.dll.signed.md5.txt -O - | md5sum --quiet -c
then
	mv ${NAME}-${VERSION}-${POSTFIX}.dll /usr/bin/libopenh264.dll
else
	rm ${NAME}-${VERSION}-${POSTFIX}.dll
	exit 1
fi
popd
chmod a+x /usr/bin/libopenh264.dll
mkdir -p /usr/share/doc/lib${NAME}
wget -q http://www.openh264.org/BINARY_LICENSE.txt -O - > /usr/share/doc/lib${NAME}/BINARY_LICENSE.txt
_EOF_
	chmod a+x ${D}/etc/postinstall/lib${NAME}.sh
	mkdir -p ${D}/etc/preremove
	cat << _EOF_ > ${D}/etc/preremove/lib${NAME}.sh
#!/bin/sh
rm -rf /usr/bin/libopenh264.dll /usr/share/doc/lib${NAME}
_EOF_
	chmod a+x ${D}/etc/preremove/lib${NAME}.sh
}

Re: [ITP] openh264 (2.3.1)

[ASSI]

Takashi Yano via Cygwin-apps writes:
> Thanks for the advice. I have revised the cygport file.

You are getting the file and the hash from the same unprotected source.
I was thinking you should put the hash into the cygport file and hence
the postinstall script.

Also note that the system doing the postinstall will not necessarily
have internet access, so you'll need to cope with errors that will
produce.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

SD adaptations for KORG EX-800 and Poly-800MkII V0.9:
http://Synth.Stromeko.net/Downloads.html#KorgSDada

Re: [ITP] openh264 (2.3.1)

[Takashi Yano]

[-- Attachment #1: Type: text/plain, Size: 669 bytes --]

On Tue, 14 Feb 2023 17:41:16 +0100
ASSI wrote:
> Takashi Yano via Cygwin-apps writes:
> > Thanks for the advice. I have revised the cygport file.
> 
> You are getting the file and the hash from the same unprotected source.
> I was thinking you should put the hash into the cygport file and hence
> the postinstall script.
> 
> Also note that the system doing the postinstall will not necessarily
> have internet access, so you'll need to cope with errors that will
> produce.

Thanks.

The new cygport file attached downloads md5hash during
the packaging process and embeds it into postinstall
script. Does this make sense?

-- 
Takashi Yano <takashi.yano@nifty.ne.jp>

[-- Attachment #2: openh264.cygport --]
[-- Type: text/plain, Size: 3164 bytes --]

NAME="openh264"
VERSION=2.3.1
RELEASE=1
CATEGORY="Video"
SUMMARY="H.264 codec library by Cisco"
DESCRIPTION="OpenH264 is a codec library which supports H.264 encoding and decoding. It is suitable for use in real time applications such as WebRTC. The binary library (runtime) itself will be downloaded from http://ciscobinary.openh264.org/"
HOMEPAGE="https://www.openh264.org/"
LICENSE="BSD-2-Clause"
ARCH="noarch" # This is noarch because it's just header files and shell scrpits.

SRC_URI="${NAME}-headers-${VERSION}.tar.xz"

# Make dummy source file for prep if the cleaned one is not exist.
if [ ! -f ${SRC_URI} ]
then
	mkdir ${NAME}-${VERSION}
	touch ${NAME}-${VERSION}/dummy
	tar acf ${SRC_URI} ${NAME}-${VERSION}
	rm -rf ${NAME}-${VERSION}
fi

CYGPORT_USE_UNSTABLE_API=1
src_unpack_hook() {
	if [ $(tar tvf ../../../${SRC_URI} | wc -l)  -eq 2 ] # Source file is dummy
	then
		NV=${NAME}-${VERSION}
		pushd ..
		rm -rf ${NV} # Remove dummy source file.
		# Download original source file.
		wget https://github.com/cisco/openh264/archive/refs/tags/v${VERSION}.tar.gz
		tar xf v${VERSION}.tar.gz
		rm -f v${VERSION}.tar.gz
		# Make source file which has only necessary header files.
		tar acf ../../${NAME}-headers-${VERSION}.tar.xz ${NV}/codec/api/wels/*.h
		# Update source directory.
		rm -rf ${NV}
		tar xf ../../${NAME}-headers-${VERSION}.tar.xz
		popd
	fi
}
	
PKG_NAMES="libopenh264 libopenh264-headers"
libopenh264_CATEGORY="Video Libs"
libopenh264_CONTENTS="etc/"
libopenh264_REQUIRES="wget bzip2"
libopenh264_SUMMARY="H.264 codec library runtime by Cisco"
libopenh264_headers_CATEGORY="Video Devel"
libopenh264_headers_CONTENTS="usr/include"
libopenh264_headers_SUMMARY="H.264 codec library headers"

src_compile() {
	:
}

src_install() {
	mkdir -p ${D}/usr/include
	ln -fs ${S}/codec/api/wels ${D}/usr/include/.
	mkdir -p ${D}/etc/postinstall
	MD5HASH64=$(wget -q http://ciscobinary.openh264.org/${NAME}-${VERSION}-win64.dll.signed.md5.txt -O - | sed "s/dll$/tmp/")
	MD5HASH32=$(wget -q http://ciscobinary.openh264.org/${NAME}-${VERSION}-win32.dll.signed.md5.txt -O - | sed "s/dll$/tmp/")
	if [ ! "${MD5HASH64}" -o ! "${MD5HASH32}" ]
	then
		echo "Need internet access!!!"
		exit 1
	fi
	cat << _EOF_ > ${D}/etc/postinstall/lib${NAME}.sh
#!/bin/sh
pushd /tmp
if [ \$(uname -m) = "x86_64" ]
then
	POSTFIX="win64"
	MD5HASH="${MD5HASH64}"
else
	POSTFIX="win32"
	MD5HASH="${MD5HASH32}"
fi
wget -q http://ciscobinary.openh264.org/${NAME}-${VERSION}-\${POSTFIX}.dll.bz2 -O - | bunzip2 > ${NAME}-${VERSION}-\${POSTFIX}.tmp
if echo "\${MD5HASH}" | md5sum --status -c
then
	mv ${NAME}-${VERSION}-\${POSTFIX}.tmp /usr/bin/libopenh264.dll
else
	# Hash mismatch (or failed to download)
	rm ${NAME}-${VERSION}-\${POSTFIX}.tmp
	exit 1
fi
popd
chmod a+x /usr/bin/libopenh264.dll
mkdir -p /usr/share/doc/lib${NAME}
wget -q http://www.openh264.org/BINARY_LICENSE.txt -O - > /usr/share/doc/lib${NAME}/BINARY_LICENSE.txt
_EOF_
	chmod a+x ${D}/etc/postinstall/lib${NAME}.sh
	mkdir -p ${D}/etc/preremove
	cat << _EOF_ > ${D}/etc/preremove/lib${NAME}.sh
#!/bin/sh
rm -rf /usr/bin/libopenh264.dll /usr/share/doc/lib${NAME}
_EOF_
	chmod a+x ${D}/etc/preremove/lib${NAME}.sh
}

Re: [ITP] openh264 (2.3.1)

[Jon Turney]

On 14/02/2023 21:21, Takashi Yano via Cygwin-apps wrote:
> On Tue, 14 Feb 2023 17:41:16 +0100
> ASSI wrote:
>> Takashi Yano via Cygwin-apps writes:
>>> Thanks for the advice. I have revised the cygport file.
>>
>> You are getting the file and the hash from the same unprotected source.
>> I was thinking you should put the hash into the cygport file and hence
>> the postinstall script.
>>
>> Also note that the system doing the postinstall will not necessarily
>> have internet access, so you'll need to cope with errors that will
>> produce.
> 
> Thanks.
> 
> The new cygport file attached downloads md5hash during
> the packaging process and embeds it into postinstall
> script. Does this make sense?

Thanks.

So, this looks like it works, and meets the requirements.

Is md5 the only hash available?  This is not really considered "good 
enough" any more.

As a thought-experiment, consider doing it slightly differently:

package contains:
- the headers
- a data file with the version (or maybe URL) and hash
- a script which can fetch (using above data) or remove the DLL
- postinstall and preremove scripts which invoke that script appropriately

(I think this means the post/pre scripts can be static, and packaged via 
$C, rather than written by the cygport itself)

What do you think of that?

Re: [ITP] openh264 (2.3.1)

[Takashi Yano]

[-- Attachment #1: Type: text/plain, Size: 1693 bytes --]

On Thu, 16 Feb 2023 19:24:24 +0000
Jon Turney wrote:
> On 14/02/2023 21:21, Takashi Yano via Cygwin-apps wrote:
> > On Tue, 14 Feb 2023 17:41:16 +0100
> > ASSI wrote:
> >> Takashi Yano via Cygwin-apps writes:
> >>> Thanks for the advice. I have revised the cygport file.
> >>
> >> You are getting the file and the hash from the same unprotected source.
> >> I was thinking you should put the hash into the cygport file and hence
> >> the postinstall script.
> >>
> >> Also note that the system doing the postinstall will not necessarily
> >> have internet access, so you'll need to cope with errors that will
> >> produce.
> > 
> > Thanks.
> > 
> > The new cygport file attached downloads md5hash during
> > the packaging process and embeds it into postinstall
> > script. Does this make sense?
> 
> Thanks.
> 
> So, this looks like it works, and meets the requirements.
> 
> Is md5 the only hash available?  This is not really considered "good 
> enough" any more.
> 
> As a thought-experiment, consider doing it slightly differently:
> 
> package contains:
> - the headers
> - a data file with the version (or maybe URL) and hash
> - a script which can fetch (using above data) or remove the DLL
> - postinstall and preremove scripts which invoke that script appropriately
> 
> (I think this means the post/pre scripts can be static, and packaged via 
> $C, rather than written by the cygport itself)
> 
> What do you think of that?

Thanks for the advice!

So, how about this one?

package contains:
- the headers
- the data files with the version and hash
- postinstall and preremove scripts which fetch (using above data)
  and remove the DLL

-- 
Takashi Yano <takashi.yano@nifty.ne.jp>

[-- Attachment #2: openh264.cygport --]
[-- Type: text/plain, Size: 2819 bytes --]

NAME="openh264"
VERSION=2.3.1
RELEASE=1
CATEGORY="Video"
SUMMARY="H.264 codec library by Cisco"
DESCRIPTION="OpenH264 is a codec library which supports H.264 encoding and decoding. It is suitable for use in real time applications such as WebRTC. The binary library (runtime) itself will be downloaded from http://ciscobinary.openh264.org/"
HOMEPAGE="https://www.openh264.org/"
LICENSE="BSD-2-Clause"
ARCH="noarch" # This is noarch because it's just header files and shell scrpits.

SRC_URI="${NAME}-headers-${VERSION}.tar.xz"

# Make dummy source file for prep if the cleaned one is not exist.
if [ ! -f ${SRC_URI} ]
then
	mkdir ${NAME}-${VERSION}
	touch ${NAME}-${VERSION}/dummy
	tar acf ${SRC_URI} ${NAME}-${VERSION}
	rm -rf ${NAME}-${VERSION}
fi

CYGPORT_USE_UNSTABLE_API=1
src_unpack_hook() {
	if [ $(tar tvf ../../../${SRC_URI} | wc -l)  -eq 2 ] # Source file is dummy
	then
		NV=${NAME}-${VERSION}
		pushd ..
		rm -rf ${NV} # Remove dummy source file.
		# Download original source file.
		wget https://github.com/cisco/openh264/archive/refs/tags/v${VERSION}.tar.gz
		tar xf v${VERSION}.tar.gz
		rm -f v${VERSION}.tar.gz
		# Make source tarball file which has only necessary header files.
		tar acf ../../${NAME}-headers-${VERSION}.tar.xz ${NV}/codec/api/wels/*.h
		# Update source directory.
		rm -rf ${NV}
		tar xf ../../${NAME}-headers-${VERSION}.tar.xz
		popd
	fi
}
	
PKG_NAMES="libopenh264 libopenh264-headers"
libopenh264_CATEGORY="Video Libs"
libopenh264_CONTENTS="etc/ usr/share/"
libopenh264_REQUIRES="wget bzip2"
libopenh264_SUMMARY="H.264 codec library runtime by Cisco"
libopenh264_headers_CATEGORY="Video Devel"
libopenh264_headers_CONTENTS="usr/include"
libopenh264_headers_SUMMARY="H.264 codec library headers"

src_compile() {
	:
}

src_install() {
	mkdir -p ${D}/usr/include
	ln -fs ${S}/codec/api/wels ${D}/usr/include/.
	# Get license file
	mkdir -p ${D}/usr/share/doc/lib${NAME}
	if ! wget -q http://www.openh264.org/BINARY_LICENSE.txt -O - > ${D}/usr/share/doc/lib${NAME}/BINARY_LICENSE.txt
	then
		echo "Need internet access!!!"
		exit 1
	fi
	mkdir -p ${D}/etc/lib${NAME}
	# Make sha256 hash
	wget -q http://ciscobinary.openh264.org/${NAME}-${VERSION}-win64.dll.bz2 -O - | bunzip2 | sha256sum | sed "s/-$/${NAME}-${VERSION}-win64.tmp/" > ${D}/etc/lib${NAME}/${NAME}-${VERSION}-win64.dll.sha256
	wget -q http://ciscobinary.openh264.org/${NAME}-${VERSION}-win32.dll.bz2 -O - | bunzip2 | sha256sum | sed "s/-$/${NAME}-${VERSION}-win32.tmp/" > ${D}/etc/lib${NAME}/${NAME}-${VERSION}-win32.dll.sha256
	# Make version text
	echo ${VERSION} > ${D}/etc/lib${NAME}/version.txt
	# Install postinstall/preremove scripts
	mkdir -p ${D}/etc/postinstall  ${D}/etc/preremove
	cp ${C}/lib${NAME}.postinstall ${D}/etc/postinstall/lib${NAME}.sh
	cp ${C}/lib${NAME}.preremove ${D}/etc/preremove/lib${NAME}.sh
}

[-- Attachment #3: openh264-2.3.1-1.cygwin.patch --]
[-- Type: text/plain, Size: 1018 bytes --]

--- origsrc/openh264-2.3.1/CYGWIN-PATCHES/libopenh264.postinstall	1970-01-01 09:00:00.000000000 +0900
+++ src/openh264-2.3.1/CYGWIN-PATCHES/libopenh264.postinstall	2023-02-17 12:36:27.633701700 +0900
@@ -0,0 +1,18 @@
+if [ $(uname -m) = "x86_64" ]
+then
+	POSTFIX="win64"
+else
+	POSTFIX="win32"
+fi
+VERSION=$(cat /etc/libopenh264/version.txt)
+cd /tmp
+wget -q http://ciscobinary.openh264.org/openh264-${VERSION}-${POSTFIX}.dll.bz2 -O - | bunzip2 > openh264-${VERSION}-${POSTFIX}.tmp
+if sha256sum --status -c /etc/libopenh264/openh264-${VERSION}-${POSTFIX}.dll.sha256
+then
+	mv openh264-${VERSION}-${POSTFIX}.tmp /usr/bin/libopenh264.dll
+else
+	# Hash mismatch (or failed to download)
+	rm openh264-${VERSION}-${POSTFIX}.tmp
+	exit 1
+fi
+chmod a+x /usr/bin/libopenh264.dll
--- origsrc/openh264-2.3.1/CYGWIN-PATCHES/libopenh264.preremove	1970-01-01 09:00:00.000000000 +0900
+++ src/openh264-2.3.1/CYGWIN-PATCHES/libopenh264.preremove	2023-02-17 12:14:05.806697700 +0900
@@ -0,0 +1 @@
+rm /usr/bin/libopenh264.dll

Re: [ITP] openh264 (2.3.1)

[Jon Turney]

On 17/02/2023 08:49, Takashi Yano via Cygwin-apps wrote:
> On Thu, 16 Feb 2023 19:24:24 +0000
> Jon Turney wrote:
>> On 14/02/2023 21:21, Takashi Yano via Cygwin-apps wrote:
>>> On Tue, 14 Feb 2023 17:41:16 +0100
>>> ASSI wrote:
>>>> Takashi Yano via Cygwin-apps writes:
>>>>> Thanks for the advice. I have revised the cygport file.
>>>>
>>>> You are getting the file and the hash from the same unprotected source.
>>>> I was thinking you should put the hash into the cygport file and hence
>>>> the postinstall script.
>>>>
>>>> Also note that the system doing the postinstall will not necessarily
>>>> have internet access, so you'll need to cope with errors that will
>>>> produce.
>>>
>>> Thanks.
>>>
>>> The new cygport file attached downloads md5hash during
>>> the packaging process and embeds it into postinstall
>>> script. Does this make sense?
>>
>> Thanks.
>>
>> So, this looks like it works, and meets the requirements.
>>
>> Is md5 the only hash available?  This is not really considered "good
>> enough" any more.
>>
>> As a thought-experiment, consider doing it slightly differently:
>>
>> package contains:
>> - the headers
>> - a data file with the version (or maybe URL) and hash
>> - a script which can fetch (using above data) or remove the DLL
>> - postinstall and preremove scripts which invoke that script appropriately
>>
>> (I think this means the post/pre scripts can be static, and packaged via
>> $C, rather than written by the cygport itself)
>>
>> What do you think of that?
> 
> Thanks for the advice!
> 
> So, how about this one?
> 
> package contains:
> - the headers
> - the data files with the version and hash
> - postinstall and preremove scripts which fetch (using above data)
>    and remove the DLL

Great, thanks.  I hope this means you think this is a better approach, 
rather than just humouring me :)

A few minor points:

* It seems like the empty dummy archive could be made with something 
like just:

   tar -Jcf ${SRC_URI} --files-from /dev/null

* If the postinstall failed somehow, the preremove script will fail 
trying to remove a file which doesn't exist.  It might be a good idea to 
use 'rm -f' to ensure that doesn't happen.

* I don't think you should need:

> 	# Install postinstall/preremove scripts
> 	mkdir -p ${D}/etc/postinstall  ${D}/etc/preremove
> 	cp ${C}/lib${NAME}.postinstall ${D}/etc/postinstall/lib${NAME}.sh
> 	cp ${C}/lib${NAME}.preremove ${D}/etc/preremove/lib${NAME}.sh
> 

This should happen automatically if the files are in $C (and you can 
list them in CYGWIN_FILES or make them with cygwin.patch file to put 
them there)

Re: [ITP] openh264 (2.3.1)

[Takashi Yano]

On Sun, 19 Feb 2023 15:37:47 +0000
Jon Turney wrote:
> On 17/02/2023 08:49, Takashi Yano via Cygwin-apps wrote:
> > So, how about this one?
> > 
> > package contains:
> > - the headers
> > - the data files with the version and hash
> > - postinstall and preremove scripts which fetch (using above data)
> >    and remove the DLL
> 
> Great, thanks.  I hope this means you think this is a better approach, 
> rather than just humouring me :)

Absolutely yes :)

> A few minor points:
> 
> * It seems like the empty dummy archive could be made with something 
> like just:
> 
>    tar -Jcf ${SRC_URI} --files-from /dev/null

Just doing this causes mismatch of SRC_DIR with actual source
package. However, making ${NAME}-{$VERSION}/dummy file does not
seem necessary.

So, I modified the cygport file as follows.
    mkdir -p ${NAME}-${VERSION}
    tar acf ${SRC_URI} ${NAME}-${VERSION}
    rm -rf ${NAME}-${VERSION}

> * If the postinstall failed somehow, the preremove script will fail 
> trying to remove a file which doesn't exist.  It might be a good idea to 
> use 'rm -f' to ensure that doesn't happen.

Indeed. Fixed. Thanks!

> * I don't think you should need:
> 
> > 	# Install postinstall/preremove scripts
> > 	mkdir -p ${D}/etc/postinstall  ${D}/etc/preremove
> > 	cp ${C}/lib${NAME}.postinstall ${D}/etc/postinstall/lib${NAME}.sh
> > 	cp ${C}/lib${NAME}.preremove ${D}/etc/preremove/lib${NAME}.sh
> > 
> 
> This should happen automatically if the files are in $C (and you can 
> list them in CYGWIN_FILES or make them with cygwin.patch file to put 
> them there)

That's what I understood from
https://cygwin.github.io/cygport/masterindex.html,
however, actually libopenh264.{postinstall,preremove} are
not installed during install process by cygport 0.36.0
even though openh264-2.3.1-1.cygwin.patch exists.

Could you please give me a hint how I can make it work?

-- 
Takashi Yano <takashi.yano@nifty.ne.jp>

Re: [ITP] openh264 (2.3.1)

[Jon Turney]

On 20/02/2023 08:55, Takashi Yano via Cygwin-apps wrote:
> On Sun, 19 Feb 2023 15:37:47 +0000
> Jon Turney wrote:
[...]>> * I don't think you should need:
>>
>>> 	# Install postinstall/preremove scripts
>>> 	mkdir -p ${D}/etc/postinstall  ${D}/etc/preremove
>>> 	cp ${C}/lib${NAME}.postinstall ${D}/etc/postinstall/lib${NAME}.sh
>>> 	cp ${C}/lib${NAME}.preremove ${D}/etc/preremove/lib${NAME}.sh
>>>
>>
>> This should happen automatically if the files are in $C (and you can
>> list them in CYGWIN_FILES or make them with cygwin.patch file to put
>> them there)
> 
> That's what I understood from
> https://cygwin.github.io/cygport/masterindex.html,
> however, actually libopenh264.{postinstall,preremove} are
> not installed during install process by cygport 0.36.0
> even though openh264-2.3.1-1.cygwin.patch exists.
> 
> Could you please give me a hint how I can make it work?

Aha! This is a bug in cygport.

(There's some code which skips over doing this for the first item in 
PKG_NAMES, assuming that is always the same as PN, which has already 
been done)

Thanks for drawing that to my attention. I'll look into fixing it, but 
for the moment it seems you can workaround the bug by ensuring that the 
package with premove/postinstall scripts isn't first in that list, i.e.:

- PKG_NAMES="libopenh264 libopenh264-headers"
+ PKG_NAMES="libopenh264-headers libopenh264"

Re: [ITP] openh264 (2.3.1)

[Takashi Yano]

[-- Attachment #1: Type: text/plain, Size: 1609 bytes --]

On Tue, 21 Feb 2023 14:11:46 +0000
Jon Turney wrote:
> On 20/02/2023 08:55, Takashi Yano via Cygwin-apps wrote:
> > On Sun, 19 Feb 2023 15:37:47 +0000
> > Jon Turney wrote:
> [...]>> * I don't think you should need:
> >>
> >>> 	# Install postinstall/preremove scripts
> >>> 	mkdir -p ${D}/etc/postinstall  ${D}/etc/preremove
> >>> 	cp ${C}/lib${NAME}.postinstall ${D}/etc/postinstall/lib${NAME}.sh
> >>> 	cp ${C}/lib${NAME}.preremove ${D}/etc/preremove/lib${NAME}.sh
> >>>
> >>
> >> This should happen automatically if the files are in $C (and you can
> >> list them in CYGWIN_FILES or make them with cygwin.patch file to put
> >> them there)
> > 
> > That's what I understood from
> > https://cygwin.github.io/cygport/masterindex.html,
> > however, actually libopenh264.{postinstall,preremove} are
> > not installed during install process by cygport 0.36.0
> > even though openh264-2.3.1-1.cygwin.patch exists.
> > 
> > Could you please give me a hint how I can make it work?
> 
> Aha! This is a bug in cygport.
> 
> (There's some code which skips over doing this for the first item in 
> PKG_NAMES, assuming that is always the same as PN, which has already 
> been done)
> 
> Thanks for drawing that to my attention. I'll look into fixing it, but 
> for the moment it seems you can workaround the bug by ensuring that the 
> package with premove/postinstall scripts isn't first in that list, i.e.:
> 
> - PKG_NAMES="libopenh264 libopenh264-headers"
> + PKG_NAMES="libopenh264-headers libopenh264"

Thanks! It works.

I updated the cygport file and cygwin.patch.

-- 
Takashi Yano <takashi.yano@nifty.ne.jp>

[-- Attachment #2: openh264.cygport --]
[-- Type: text/plain, Size: 2490 bytes --]

NAME="openh264"
VERSION=2.3.1
RELEASE=1
CATEGORY="Video"
SUMMARY="H.264 codec library by Cisco"
DESCRIPTION="OpenH264 is a codec library which supports H.264 encoding and decoding. It is suitable for use in real time applications such as WebRTC. The binary library (runtime) itself will be downloaded from http://ciscobinary.openh264.org/"
HOMEPAGE="https://www.openh264.org/"
LICENSE="BSD-2-Clause"
ARCH="noarch" # This is noarch because it's just header files and shell scrpits.

SRC_URI="${NAME}-headers-${VERSION}.tar.xz"

# Make dummy source file for prep if the cleaned one is not exist.
if [ ! -f ${SRC_URI} ]
then
	mkdir -p ${NAME}-${VERSION}
	tar acf ${SRC_URI} ${NAME}-${VERSION}
	rm -rf ${NAME}-${VERSION}
fi

CYGPORT_USE_UNSTABLE_API=1
src_unpack_hook() {
	if [ $(tar tvf ../../../${SRC_URI} | wc -l)  -eq 1 ] # Source file is dummy
	then
		NV=${NAME}-${VERSION}
		pushd ..
		# Download original source file.
		wget -q https://github.com/cisco/openh264/archive/refs/tags/v${VERSION}.tar.gz -O - | tar xzf -
		# Make source tarball file which has only necessary header files.
		tar acf ../../${NAME}-headers-${VERSION}.tar.xz ${NV}/codec/api/wels/*.h
		# Update source directory.
		rm -rf ${NV}
		tar xf ../../${NAME}-headers-${VERSION}.tar.xz
		popd
	fi
}
	
PKG_NAMES="libopenh264-headers libopenh264"
libopenh264_CATEGORY="Video Libs"
libopenh264_CONTENTS="etc/ usr/share/"
libopenh264_REQUIRES="wget bzip2"
libopenh264_SUMMARY="H.264 codec library runtime by Cisco"
libopenh264_headers_CATEGORY="Video Devel"
libopenh264_headers_CONTENTS="usr/include"
libopenh264_headers_SUMMARY="H.264 codec library headers"

src_compile() {
	:
}

src_install() {
	mkdir -p ${D}/usr/include
	ln -fs ${S}/codec/api/wels ${D}/usr/include/.
	# Get license file
	mkdir -p ${D}/usr/share/doc/lib${NAME}
	if ! wget -q http://www.openh264.org/BINARY_LICENSE.txt -O - > ${D}/usr/share/doc/lib${NAME}/BINARY_LICENSE.txt
	then
		echo "Need internet access!!!"
		exit 1
	fi
	mkdir -p ${D}/etc/lib${NAME}
	# Make sha256 hash
	wget -q http://ciscobinary.openh264.org/${NAME}-${VERSION}-win64.dll.bz2 -O - | bunzip2 | sha256sum | sed "s/-$/${NAME}-${VERSION}-win64.tmp/" > ${D}/etc/lib${NAME}/${NAME}-${VERSION}-win64.dll.sha256
	wget -q http://ciscobinary.openh264.org/${NAME}-${VERSION}-win32.dll.bz2 -O - | bunzip2 | sha256sum | sed "s/-$/${NAME}-${VERSION}-win32.tmp/" > ${D}/etc/lib${NAME}/${NAME}-${VERSION}-win32.dll.sha256
	# Make version text
	echo ${VERSION} > ${D}/etc/lib${NAME}/version.txt
}

[-- Attachment #3: openh264-2.3.1-1.cygwin.patch --]
[-- Type: text/plain, Size: 1021 bytes --]

--- origsrc/openh264-2.3.1/CYGWIN-PATCHES/libopenh264.postinstall	1970-01-01 09:00:00.000000000 +0900
+++ src/openh264-2.3.1/CYGWIN-PATCHES/libopenh264.postinstall	2023-02-17 12:36:27.633701700 +0900
@@ -0,0 +1,18 @@
+if [ $(uname -m) = "x86_64" ]
+then
+	POSTFIX="win64"
+else
+	POSTFIX="win32"
+fi
+VERSION=$(cat /etc/libopenh264/version.txt)
+cd /tmp
+wget -q http://ciscobinary.openh264.org/openh264-${VERSION}-${POSTFIX}.dll.bz2 -O - | bunzip2 > openh264-${VERSION}-${POSTFIX}.tmp
+if sha256sum --status -c /etc/libopenh264/openh264-${VERSION}-${POSTFIX}.dll.sha256
+then
+	mv openh264-${VERSION}-${POSTFIX}.tmp /usr/bin/libopenh264.dll
+else
+	# Hash mismatch (or failed to download)
+	rm openh264-${VERSION}-${POSTFIX}.tmp
+	exit 1
+fi
+chmod a+x /usr/bin/libopenh264.dll
--- origsrc/openh264-2.3.1/CYGWIN-PATCHES/libopenh264.preremove	1970-01-01 09:00:00.000000000 +0900
+++ src/openh264-2.3.1/CYGWIN-PATCHES/libopenh264.preremove	2023-02-17 12:14:05.806697700 +0900
@@ -0,0 +1 @@
+rm -f /usr/bin/libopenh264.dll

Re: [ITP] openh264 (2.3.1)

[Jon Turney]

On 22/02/2023 03:33, Takashi Yano via Cygwin-apps wrote:
> On Tue, 21 Feb 2023 14:11:46 +0000
> Jon Turney wrote:
>> On 20/02/2023 08:55, Takashi Yano via Cygwin-apps wrote:
>>> On Sun, 19 Feb 2023 15:37:47 +0000
>>> Jon Turney wrote:
>> [...]>> * I don't think you should need:
>>>>
>>>>> 	# Install postinstall/preremove scripts
>>>>> 	mkdir -p ${D}/etc/postinstall  ${D}/etc/preremove
>>>>> 	cp ${C}/lib${NAME}.postinstall ${D}/etc/postinstall/lib${NAME}.sh
>>>>> 	cp ${C}/lib${NAME}.preremove ${D}/etc/preremove/lib${NAME}.sh
>>>>>
>>>>
>>>> This should happen automatically if the files are in $C (and you can
>>>> list them in CYGWIN_FILES or make them with cygwin.patch file to put
>>>> them there)
>>>
>>> That's what I understood from
>>> https://cygwin.github.io/cygport/masterindex.html,
>>> however, actually libopenh264.{postinstall,preremove} are
>>> not installed during install process by cygport 0.36.0
>>> even though openh264-2.3.1-1.cygwin.patch exists.
>>>
>>> Could you please give me a hint how I can make it work?
>>
>> Aha! This is a bug in cygport.
>>
>> (There's some code which skips over doing this for the first item in
>> PKG_NAMES, assuming that is always the same as PN, which has already
>> been done)
>>
>> Thanks for drawing that to my attention. I'll look into fixing it, but
>> for the moment it seems you can workaround the bug by ensuring that the
>> package with premove/postinstall scripts isn't first in that list, i.e.:
>>
>> - PKG_NAMES="libopenh264 libopenh264-headers"
>> + PKG_NAMES="libopenh264-headers libopenh264"
> 
> Thanks! It works.
> 
> I updated the cygport file and cygwin.patch.

GTG.

Re: [ITP] openh264 (2.3.1)

[Takashi Yano]

On Thu, 23 Feb 2023 12:54:04 +0000
Jon Turney wrote:
> On 22/02/2023 03:33, Takashi Yano via Cygwin-apps wrote:
> > On Tue, 21 Feb 2023 14:11:46 +0000
> > Jon Turney wrote:
> >> On 20/02/2023 08:55, Takashi Yano via Cygwin-apps wrote:
> >>> On Sun, 19 Feb 2023 15:37:47 +0000
> >>> Jon Turney wrote:
> >> [...]>> * I don't think you should need:
> >>>>
> >>>>> 	# Install postinstall/preremove scripts
> >>>>> 	mkdir -p ${D}/etc/postinstall  ${D}/etc/preremove
> >>>>> 	cp ${C}/lib${NAME}.postinstall ${D}/etc/postinstall/lib${NAME}.sh
> >>>>> 	cp ${C}/lib${NAME}.preremove ${D}/etc/preremove/lib${NAME}.sh
> >>>>>
> >>>>
> >>>> This should happen automatically if the files are in $C (and you can
> >>>> list them in CYGWIN_FILES or make them with cygwin.patch file to put
> >>>> them there)
> >>>
> >>> That's what I understood from
> >>> https://cygwin.github.io/cygport/masterindex.html,
> >>> however, actually libopenh264.{postinstall,preremove} are
> >>> not installed during install process by cygport 0.36.0
> >>> even though openh264-2.3.1-1.cygwin.patch exists.
> >>>
> >>> Could you please give me a hint how I can make it work?
> >>
> >> Aha! This is a bug in cygport.
> >>
> >> (There's some code which skips over doing this for the first item in
> >> PKG_NAMES, assuming that is always the same as PN, which has already
> >> been done)
> >>
> >> Thanks for drawing that to my attention. I'll look into fixing it, but
> >> for the moment it seems you can workaround the bug by ensuring that the
> >> package with premove/postinstall scripts isn't first in that list, i.e.:
> >>
> >> - PKG_NAMES="libopenh264 libopenh264-headers"
> >> + PKG_NAMES="libopenh264-headers libopenh264"
> > 
> > Thanks! It works.
> > 
> > I updated the cygport file and cygwin.patch.
> 
> GTG.

Thank you for reviewing all my proposed packages!

-- 
Takashi Yano <takashi.yano@nifty.ne.jp>