* List [ITP],[ITA] by me @ 2023-02-05 8:40 Takashi Yano 2023-02-05 16:33 ` Jon Turney 0 siblings, 1 reply; 10+ messages in thread From: Takashi Yano @ 2023-02-05 8:40 UTC (permalink / raw) To: cygwin-apps The list of ITPs and ITAs I recently proposed, is as follows. Sorry, there are so many, but thank you in advance. [ITP] AMF: for ffmpeg (new) aom: for ffmpeg (new) faad2 : for moc fdk-aac-free : for ffmpeg (new) ffmpeg : for moc (under discussion) libopusenc : for opus-tools mfx_dispatch : for ffmpeg (new) moc nv-codec-headers : for ffmpeg (new) openh264 : for ffmpeg (new) xvidcore : for ffmpeg [ITA] libsndfile : maintainer changed, no GTG yet opus : maintainer changed, no GTG yet opusfile : maintainer changed, no GTG yet opus-tools : maintainer changed, no GTG yet pulseaudio : (new) SDL2 : already has GTG mpg123 : already has GTG [WITHDRAW] x264 x265 -- Takashi Yano <takashi.yano@nifty.ne.jp> ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: List [ITP],[ITA] by me 2023-02-05 8:40 List [ITP],[ITA] by me Takashi Yano @ 2023-02-05 16:33 ` Jon Turney 2023-02-06 12:21 ` Takashi Yano 2023-02-13 10:47 ` Status update (Re: List [ITP],[ITA] by me) Takashi Yano 0 siblings, 2 replies; 10+ messages in thread From: Jon Turney @ 2023-02-05 16:33 UTC (permalink / raw) To: Takashi Yano, cygwin-apps On 05/02/2023 08:40, Takashi Yano via Cygwin-apps wrote: > The list of ITPs and ITAs I recently proposed, is as follows. > Sorry, there are so many, but thank you in advance. No problem. I'll try to give them all the attention they deserve. > [ITP] > AMF: for ffmpeg (new) > aom: for ffmpeg (new) > faad2 : for moc > fdk-aac-free : for ffmpeg (new) > ffmpeg : for moc (under discussion) > libopusenc : for opus-tools > mfx_dispatch : for ffmpeg (new) > moc > nv-codec-headers : for ffmpeg (new) I have a question about how this (and AMF I guess) works. Are these headers which implement the whole codec? or do they expect the codec to be accessible via the driver somehow? > openh264 : for ffmpeg (new) > xvidcore : for ffmpeg > > [ITA] > libsndfile : maintainer changed, no GTG yet > opus : maintainer changed, no GTG yet > opusfile : maintainer changed, no GTG yet > opus-tools : maintainer changed, no GTG yet > pulseaudio : (new) > > SDL2 : already has GTG > mpg123 : already has GTG > > [WITHDRAW] > x264 > x265 > I've posted some specific comments on some of these. Please double-check that packages which contain a soversioned library include that in the package name (for reasons touched on in [1]). If you'd like me to review any of these again, please post the just new .cygport file in a follow-up (since that will save me a little time in having to extract it) I've updated the package list. [1] https://cygwin.com/pipermail/cygwin-apps/2023-January/042480.html ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: List [ITP],[ITA] by me 2023-02-05 16:33 ` Jon Turney @ 2023-02-06 12:21 ` Takashi Yano 2023-02-13 18:02 ` Jon Turney 2023-02-13 10:47 ` Status update (Re: List [ITP],[ITA] by me) Takashi Yano 1 sibling, 1 reply; 10+ messages in thread From: Takashi Yano @ 2023-02-06 12:21 UTC (permalink / raw) To: cygwin-apps On Sun, 5 Feb 2023 16:33:45 +0000 Jon Turney wrote: > On 05/02/2023 08:40, Takashi Yano via Cygwin-apps wrote: > > The list of ITPs and ITAs I recently proposed, is as follows. > > Sorry, there are so many, but thank you in advance. > > No problem. I'll try to give them all the attention they deserve. Thank you very much! > > [ITP] > > AMF: for ffmpeg (new) > > aom: for ffmpeg (new) > > faad2 : for moc > > fdk-aac-free : for ffmpeg (new) > > ffmpeg : for moc (under discussion) > > libopusenc : for opus-tools > > mfx_dispatch : for ffmpeg (new) > > moc > > nv-codec-headers : for ffmpeg (new) > > I have a question about how this (and AMF I guess) works. > > Are these headers which implement the whole codec? or do they expect the > codec to be accessible via the driver somehow? nv-codec-headers provides header files which dynamically loads nvcuda.dll, nvcuvid.dll and nvEncodeAPI{,64}.dll. Similary, AMF loads amfrt{64,32}.dll dinamically. The codec itself is implemented in the dlls which is provided by nVidia/AMD. mfx_dispatch also does the similar. It loads some dlls dynamically privided by Intel. > > openh264 : for ffmpeg (new) > > xvidcore : for ffmpeg > > > > [ITA] > > libsndfile : maintainer changed, no GTG yet > > opus : maintainer changed, no GTG yet > > opusfile : maintainer changed, no GTG yet > > opus-tools : maintainer changed, no GTG yet > > pulseaudio : (new) > > > > SDL2 : already has GTG > > mpg123 : already has GTG > > > > [WITHDRAW] > > x264 > > x265 > > > > I've posted some specific comments on some of these. > > Please double-check that packages which contain a soversioned library > include that in the package name (for reasons touched on in [1]). > > If you'd like me to review any of these again, please post the just new > .cygport file in a follow-up (since that will save me a little time in > having to extract it) > > I've updated the package list. > > [1] https://cygwin.com/pipermail/cygwin-apps/2023-January/042480.html Thanks. I'll check and fix that. -- Takashi Yano <takashi.yano@nifty.ne.jp> ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: List [ITP],[ITA] by me 2023-02-06 12:21 ` Takashi Yano @ 2023-02-13 18:02 ` Jon Turney 2023-02-14 9:11 ` Takashi Yano 0 siblings, 1 reply; 10+ messages in thread From: Jon Turney @ 2023-02-13 18:02 UTC (permalink / raw) To: Takashi Yano, cygwin-apps On 06/02/2023 12:21, Takashi Yano via Cygwin-apps wrote: > On Sun, 5 Feb 2023 16:33:45 +0000 > Jon Turney wrote: >> On 05/02/2023 08:40, Takashi Yano via Cygwin-apps wrote: >>> The list of ITPs and ITAs I recently proposed, is as follows. >>> Sorry, there are so many, but thank you in advance. >> >> No problem. I'll try to give them all the attention they deserve. > > Thank you very much! > >>> [ITP] >>> AMF: for ffmpeg (new) >>> aom: for ffmpeg (new) >>> faad2 : for moc >>> fdk-aac-free : for ffmpeg (new) >>> ffmpeg : for moc (under discussion) >>> libopusenc : for opus-tools >>> mfx_dispatch : for ffmpeg (new) >>> moc >>> nv-codec-headers : for ffmpeg (new) >> >> I have a question about how this (and AMF I guess) works. >> >> Are these headers which implement the whole codec? or do they expect the >> codec to be accessible via the driver somehow? > > nv-codec-headers provides header files which dynamically > loads nvcuda.dll, nvcuvid.dll and nvEncodeAPI{,64}.dll. > > Similary, AMF loads amfrt{64,32}.dll dinamically. > > The codec itself is implemented in the dlls which is provided > by nVidia/AMD. mfx_dispatch also does the similar. It loads > some dlls dynamically privided by Intel. > I see. It might be helpful to mention that (in general terms) in the description for those packages. Generally, there are some ABI concerns with using interfaces like this, e.g.: i) You need to be sure that Windows API sized types are used (e.g. DWORD) rather than C ABI sized types (e.g. long) See https://cygwin.com/faq.html#faq.programming.64bitporting ii) Since these dynamically loaded DLLs are linked with a different C runtime, one must tread carefully, as caution is required: e.g. if an exported function returns a pointer to some memory dynamically allocated using malloc(), which you are expected to release with free() VERY BAD THINGS will happen when you pass it to Cygwin's free() rather than the MSVCRT free() matchin the alloc() it came from. I'm going to assume that these concerns don't apply, because you would have noticed the dismal failure to work at all. ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: List [ITP],[ITA] by me 2023-02-13 18:02 ` Jon Turney @ 2023-02-14 9:11 ` Takashi Yano 2023-02-14 13:33 ` Takashi Yano 0 siblings, 1 reply; 10+ messages in thread From: Takashi Yano @ 2023-02-14 9:11 UTC (permalink / raw) To: cygwin-apps On Mon, 13 Feb 2023 18:02:27 +0000 Jon Turney wrote: > On 06/02/2023 12:21, Takashi Yano via Cygwin-apps wrote: > > On Sun, 5 Feb 2023 16:33:45 +0000 > > Jon Turney wrote: > >> On 05/02/2023 08:40, Takashi Yano via Cygwin-apps wrote: > >>> The list of ITPs and ITAs I recently proposed, is as follows. > >>> Sorry, there are so many, but thank you in advance. > >> > >> No problem. I'll try to give them all the attention they deserve. > > > > Thank you very much! > > > >>> [ITP] > >>> AMF: for ffmpeg (new) > >>> aom: for ffmpeg (new) > >>> faad2 : for moc > >>> fdk-aac-free : for ffmpeg (new) > >>> ffmpeg : for moc (under discussion) > >>> libopusenc : for opus-tools > >>> mfx_dispatch : for ffmpeg (new) > >>> moc > >>> nv-codec-headers : for ffmpeg (new) > >> > >> I have a question about how this (and AMF I guess) works. > >> > >> Are these headers which implement the whole codec? or do they expect the > >> codec to be accessible via the driver somehow? > > > > nv-codec-headers provides header files which dynamically > > loads nvcuda.dll, nvcuvid.dll and nvEncodeAPI{,64}.dll. > > > > Similary, AMF loads amfrt{64,32}.dll dinamically. > > > > The codec itself is implemented in the dlls which is provided > > by nVidia/AMD. mfx_dispatch also does the similar. It loads > > some dlls dynamically privided by Intel. > > > > I see. > > It might be helpful to mention that (in general terms) in the > description for those packages. > > > Generally, there are some ABI concerns with using interfaces like this, > e.g.: > > i) You need to be sure that Windows API sized types are used (e.g. > DWORD) rather than C ABI sized types (e.g. long) > > See https://cygwin.com/faq.html#faq.programming.64bitporting > > ii) Since these dynamically loaded DLLs are linked with a different C > runtime, one must tread carefully, as caution is required: > > e.g. if an exported function returns a pointer to some memory > dynamically allocated using malloc(), which you are expected to release > with free() VERY BAD THINGS will happen when you pass it to Cygwin's > free() rather than the MSVCRT free() matchin the alloc() it came from. > > > I'm going to assume that these concerns don't apply, because you would > have noticed the dismal failure to work at all. Thanks for the advice. I will check just to be sure. -- Takashi Yano <takashi.yano@nifty.ne.jp> ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: List [ITP],[ITA] by me 2023-02-14 9:11 ` Takashi Yano @ 2023-02-14 13:33 ` Takashi Yano 2023-02-16 18:52 ` Jon Turney 0 siblings, 1 reply; 10+ messages in thread From: Takashi Yano @ 2023-02-14 13:33 UTC (permalink / raw) To: cygwin-apps [-- Attachment #1: Type: text/plain, Size: 4045 bytes --] On Mon, 13 Feb 2023 18:02:27 +0000 Jon Turney wrote: > On 06/02/2023 12:21, Takashi Yano via Cygwin-apps wrote: > > On Sun, 5 Feb 2023 16:33:45 +0000 > > Jon Turney wrote: > >> On 05/02/2023 08:40, Takashi Yano via Cygwin-apps wrote: > >>> [ITP] [...] > >>> AMF: for ffmpeg (new) [...] > >>> nv-codec-headers : for ffmpeg (new) > >> > >> I have a question about how this (and AMF I guess) works. > >> > >> Are these headers which implement the whole codec? or do they expect the > >> codec to be accessible via the driver somehow? > > > > nv-codec-headers provides header files which dynamically > > loads nvcuda.dll, nvcuvid.dll and nvEncodeAPI{,64}.dll. > > > > Similary, AMF loads amfrt{64,32}.dll dinamically. > > > > The codec itself is implemented in the dlls which is provided > > by nVidia/AMD. mfx_dispatch also does the similar. It loads > > some dlls dynamically privided by Intel. > > I see. > > It might be helpful to mention that (in general terms) in the > description for those packages. I have added descriptions to cygport files each of AMF, nv-codec-headers and mfx_dispatcher. > Generally, there are some ABI concerns with using interfaces like this, > e.g.: > > i) You need to be sure that Windows API sized types are used (e.g. > DWORD) rather than C ABI sized types (e.g. long) > > See https://cygwin.com/faq.html#faq.programming.64bitporting AMF: Seems to specify the argument bit-width explicitly. typedef uint64_t amf_uint64; typedef AMF_RESULT (AMF_CDECL_CALL *AMFInit_Fn)(amf_uint64 version, AMFFactory **ppFactory); nv-codec-headers: Also specifies bit-width explicitly. NVENCSTATUS NVENCAPI NvEncOpenEncodeSession (void* device, uint32_t deviceType, void** encoder); mfx_dispatch: This also specifies the bit-width explicitly. typedef mfxI32 mfxIMPL; typedef void (MFX_CDECL * mfxFunctionPointer)(void); typedef struct _mfxSession *mfxSession; typedef struct { mfxU32 AllocId; mfxU32 reserved[2]; mfxU16 reserved3; mfxU16 AsyncDepth; union { mfxInfoMFX mfx; mfxInfoVPP vpp; }; mfxU16 Protected; mfxU16 IOPattern; mfxExtBuffer** ExtParam; mfxU16 NumExtParam; mfxU16 reserved2; } mfxVideoParam; struct _mfxSession { // A real handle from MFX engine passed to a called function mfxSession session; mfxFunctionPointer callTable[eVideoFuncTotal]; mfxFunctionPointer callPlugInsTable[ePluginFuncTotal]; mfxFunctionPointer callAudioTable[eAudioFuncTotal]; // Current library's implementation (exact implementation) mfxIMPL impl; }; FUNCTION(mfxStatus, MFXVideoENC_GetVideoParam, (mfxSession session, mfxVideoParam *par), (session, par)) > ii) Since these dynamically loaded DLLs are linked with a different C > runtime, one must tread carefully, as caution is required: > > e.g. if an exported function returns a pointer to some memory > dynamically allocated using malloc(), which you are expected to release > with free() VERY BAD THINGS will happen when you pass it to Cygwin's > free() rather than the MSVCRT free() matchin the alloc() it came from. AMF: Seems to use the pair of malloc()/free(). static AMF_INLINE void* AMF_CDECL_CALL amf_variant_alloc(amf_size count) { return malloc(count); } static AMF_INLINE void AMF_CDECL_CALL amf_variant_free(void* ptr) { free(ptr); } nv-codec-headers: Uses the pair of alloc/free function in the dll. tcuMemAlloc_v2 *cuMemAlloc; tcuMemFree_v2 *cuMemFree; mfx_dispatch: Use the pair of Alloc/Free function defined by itself. typedef struct { mfxU32 reserved[4]; mfxHDL pthis; mfxStatus (MFX_CDECL *Alloc) (mfxHDL pthis, mfxU32 nbytes, mfxU16 type, mfxMemId *mid); mfxStatus (MFX_CDECL *Lock) (mfxHDL pthis, mfxMemId mid, mfxU8 **ptr); mfxStatus (MFX_CDECL *Unlock) (mfxHDL pthis, mfxMemId mid); mfxStatus (MFX_CDECL *Free) (mfxHDL pthis, mfxMemId mid); } mfxBufferAllocator; Therefore, I do not think the problems i) and ii) apply. -- Takashi Yano <takashi.yano@nifty.ne.jp> [-- Attachment #2: nv-codec-headers.cygport --] [-- Type: text/plain, Size: 712 bytes --] NAME="nv-codec-headers" VERSION=11.1.5.2 RELEASE=1 LICENSE="MIT" CATEGORY="Devel" SUMMARY="FFmpeg version of Nvidia Codec SDK headers" DESCRIPTION="FFmpeg version of headers required to interface with Nvidias codec APIs. This package provides headers which loads corresponding dlls dynamically. The codec itself is implemented in the dlls and the Nvidia GPU." HOMEPAGE="https://github.com/FFmpeg/nv-codec-headers" ARCH="noarch" # This is noarch because it's just header files. SRC_URI="https://github.com/FFmpeg/nv-codec-headers/archive/refs/tags/n${VERSION}.tar.gz" SRC_DIR="${NAME}-n${VERSION}" src_compile() { cd ${B} ln -sf ${S}/Makefile . ln -sf ${S}/ffnvcodec.pc.in . ln -sf ${S}/include . cygmake } [-- Attachment #3: AMF.cygport --] [-- Type: text/plain, Size: 1753 bytes --] NAME="AMF" VERSION=1.4.29 RELEASE=1 LICENSE="MIT" CATEGORY="Devel" SUMMARY="Advanced Media Framework (AMF) SDK" DESCRIPTION="A light-weight, portable multimedia framework that abstracts away most of the platform and API-specific details. AMF is supported on the closed source AMD Pro driver and OpenMax on the open source AMD Mesa driver, whose dlls are dynamically loaded by the SDK header. The codec itself is impelemted in the dlls and the AMD GPU." HOMEPAGE="https://gpuopen.com/advanced-media-framework/" ARCH="noarch" # This is noarch because it's just header files. SRC_URI="${NAME}-cleaned-${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/GPUOpen-LibrariesAndSDKs/AMF/archive/refs/tags/v${VERSION}.tar.gz tar xf v${VERSION}.tar.gz rm -f v${VERSION}.tar.gz # Remove unnecessary files. rm -rf ${NV}/Thirdparty ${NV}/amf/public/common ${NV}/amf/public/make ${NV}/amf/public/proj ${NV}/amf/public/props ${NV}/amf/public/samples ${NV}/amf/public/src ${NV}/amf/doc ${NV}/.github # Make cleaned source file which has only necessary header files. tar acf ../../${NAME}-cleaned-${VERSION}.tar.xz ${NV} popd fi } src_compile() { : } src_install() { mkdir -p ${D}/usr/include # Just make symlink for header files. ln -fs ${S}/amf/public/include ${D}/usr/include/${NAME} } [-- Attachment #4: mfx_dispatch.cygport --] [-- Type: text/plain, Size: 575 bytes --] NAME="mfx_dispatch" VERSION=1.35.1 RELEASE=1 LICENSE="BSD-3-Clause" CATEGORY="Libs" SUMMARY="Intel MediaSDK dispatcher (Alternative to libmfx)" DESCRIPTION="This package provides the headers and the library which loads Intel MediaSDK dlls dynamically. The codec itself is implemented in the dlls and the Intel GPU." HOMEPAGE="https://github.com/lu-zero/mfx_dispatch" SRC_URI="https://github.com/lu-zero/mfx_dispatch/archive/refs/tags/${VERSION}.tar.gz" PKG_NAMES="libmfx1 libmfx-devel" libmfx1_CONTENTS="usr/bin usr/share/doc/" libmfx_devel_CONTENTS="usr/include/ usr/lib/" ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: List [ITP],[ITA] by me 2023-02-14 13:33 ` Takashi Yano @ 2023-02-16 18:52 ` Jon Turney 0 siblings, 0 replies; 10+ messages in thread From: Jon Turney @ 2023-02-16 18:52 UTC (permalink / raw) To: Takashi Yano, cygwin-apps On 14/02/2023 13:33, Takashi Yano via Cygwin-apps wrote: > On Mon, 13 Feb 2023 18:02:27 +0000 > Jon Turney wrote: >> On 06/02/2023 12:21, Takashi Yano via Cygwin-apps wrote: >>> On Sun, 5 Feb 2023 16:33:45 +0000 >>> Jon Turney wrote: >>>> On 05/02/2023 08:40, Takashi Yano via Cygwin-apps wrote: >>>>> [ITP] > [...] >>>>> AMF: for ffmpeg (new) > [...] >>>>> nv-codec-headers : for ffmpeg (new) >>>> >>>> I have a question about how this (and AMF I guess) works. >>>> >>>> Are these headers which implement the whole codec? or do they expect the >>>> codec to be accessible via the driver somehow? >>> >>> nv-codec-headers provides header files which dynamically >>> loads nvcuda.dll, nvcuvid.dll and nvEncodeAPI{,64}.dll. >>> >>> Similary, AMF loads amfrt{64,32}.dll dinamically. >>> >>> The codec itself is implemented in the dlls which is provided >>> by nVidia/AMD. mfx_dispatch also does the similar. It loads >>> some dlls dynamically privided by Intel. >> >> I see. >> >> It might be helpful to mention that (in general terms) in the >> description for those packages. > > I have added descriptions to cygport files each of AMF, > nv-codec-headers and mfx_dispatcher. > >> Generally, there are some ABI concerns with using interfaces like this, >> e.g.: [...] > Therefore, I do not think the problems i) and ii) apply. Thanks very much for investigating and checking these details. These are approved. ^ permalink raw reply [flat|nested] 10+ messages in thread
* Status update (Re: List [ITP],[ITA] by me) 2023-02-05 16:33 ` Jon Turney 2023-02-06 12:21 ` Takashi Yano @ 2023-02-13 10:47 ` Takashi Yano 2023-02-13 18:29 ` Jon Turney 1 sibling, 1 reply; 10+ messages in thread From: Takashi Yano @ 2023-02-13 10:47 UTC (permalink / raw) To: cygwin-apps; +Cc: Jon Turney On Sun, 5 Feb 2023 16:33:45 +0000 Jon Turney wrote: > On 05/02/2023 08:40, Takashi Yano via Cygwin-apps wrote: > > The list of ITPs and ITAs I recently proposed, is as follows. > > Sorry, there are so many, but thank you in advance. > > No problem. I'll try to give them all the attention they deserve. > > > [ITP] > > AMF: for ffmpeg (new) > > aom: for ffmpeg (new) > > faad2 : for moc > > fdk-aac-free : for ffmpeg (new) > > ffmpeg : for moc (under discussion) > > libopusenc : for opus-tools > > mfx_dispatch : for ffmpeg (new) > > moc > > nv-codec-headers : for ffmpeg (new) > > I have a question about how this (and AMF I guess) works. > > Are these headers which implement the whole codec? or do they expect the > codec to be accessible via the driver somehow? > > > openh264 : for ffmpeg (new) > > xvidcore : for ffmpeg > > > > [ITA] > > libsndfile : maintainer changed, no GTG yet > > opus : maintainer changed, no GTG yet > > opusfile : maintainer changed, no GTG yet > > opus-tools : maintainer changed, no GTG yet > > pulseaudio : (new) > > > > SDL2 : already has GTG > > mpg123 : already has GTG > > > > [WITHDRAW] > > x264 > > x265 > > > > I've posted some specific comments on some of these. > > Please double-check that packages which contain a soversioned library > include that in the package name (for reasons touched on in [1]). > > If you'd like me to review any of these again, please post the just new > .cygport file in a follow-up (since that will save me a little time in > having to extract it) > > I've updated the package list. > > [1] https://cygwin.com/pipermail/cygwin-apps/2023-January/042480.html +----+------------------------+------------+---------+----------------------+ | No.| Package | Maintainer | GTG | Comment | +----+------------------------+------------+---------+----------------------+ | 1 | [ITP] AMF | | | | | 2 | [ITP] nv-codec-headers | | | | | 3 | [ITP] mfx_dispatch | | | | | 4 | [ITP] aom | Assigned | Almost | | | 5 | [ITP] xvidcore | Assigned | | | | 6 | [ITP] openh264 | Assigned | | | | 7 | [ITP] ffmpeg | Assigned | | Needs 1,2,3,4,5,6,10 | | 8 | [ITP] moc | Assigned | Almost | Needs 7 | | 9 | [ITP] libopusenc | | Almost | | +----+------------------------+------------+---------+----------------------+ | 10 | [ITA] fdk-aac | | Almost | [ITP] -> [ITA] | | 11 | [ITA] libsndfile | Assigned | Almost | Needs 13 | | 12 | [ITA] pulseaudio | Assigned | Almost | | | 13 | [ITA] opus | Assigned | | | | 14 | [ITA] opusfile | Assigned | | | | 15 | [ITA] opus-tools | Assigned | | Needs 9 | | 16 | [ITA] mpg123 | Assigned | Almost | | | 17 | [ITA] SDL2 | Assigned | Yes | | +----+------------------------+------------+---------+----------------------+ | 18 | [ITP] x264 | | | Withdrawn | | 19 | [ITP] x265 | | | Withdrawn | | 20 | [ITP] faad2 | Assigned * | | Withdrawn | +----+------------------------+------------+---------+----------------------+ * Please remove faad2 from package list (ref. Yaakov's reply). -- Takashi Yano <takashi.yano@nifty.ne.jp> ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Status update (Re: List [ITP],[ITA] by me) 2023-02-13 10:47 ` Status update (Re: List [ITP],[ITA] by me) Takashi Yano @ 2023-02-13 18:29 ` Jon Turney 2023-02-14 9:11 ` Takashi Yano 0 siblings, 1 reply; 10+ messages in thread From: Jon Turney @ 2023-02-13 18:29 UTC (permalink / raw) To: Takashi Yano, cygwin-apps On 13/02/2023 10:47, Takashi Yano via Cygwin-apps wrote: >> >> I've posted some specific comments on some of these. >> >> Please double-check that packages which contain a soversioned library >> include that in the package name (for reasons touched on in [1]). >> >> If you'd like me to review any of these again, please post the just new >> .cygport file in a follow-up (since that will save me a little time in >> having to extract it) >> >> I've updated the package list. >> >> [1] https://cygwin.com/pipermail/cygwin-apps/2023-January/042480.html > > +----+------------------------+------------+---------+----------------------+ > | No.| Package | Maintainer | GTG | Comment | > +----+------------------------+------------+---------+----------------------+ > | 1 | [ITP] AMF | | | | > | 2 | [ITP] nv-codec-headers | | | | > | 3 | [ITP] mfx_dispatch | | | | > | 4 | [ITP] aom | Assigned | Almost | | > | 5 | [ITP] xvidcore | Assigned | | | > | 6 | [ITP] openh264 | Assigned | | | > | 7 | [ITP] ffmpeg | Assigned | | Needs 1,2,3,4,5,6,10 | > | 8 | [ITP] moc | Assigned | Almost | Needs 7 | > | 9 | [ITP] libopusenc | | Almost | | > +----+------------------------+------------+---------+----------------------+ > | 10 | [ITA] fdk-aac | | Almost | [ITP] -> [ITA] | > | 11 | [ITA] libsndfile | Assigned | Almost | Needs 13 | > | 12 | [ITA] pulseaudio | Assigned | Almost | | > | 13 | [ITA] opus | Assigned | | | > | 14 | [ITA] opusfile | Assigned | | | > | 15 | [ITA] opus-tools | Assigned | | Needs 9 | > | 16 | [ITA] mpg123 | Assigned | Almost | | > | 17 | [ITA] SDL2 | Assigned | Yes | | > +----+------------------------+------------+---------+----------------------+ > | 18 | [ITP] x264 | | | Withdrawn | > | 19 | [ITP] x265 | | | Withdrawn | > | 20 | [ITP] faad2 | Assigned * | | Withdrawn | > +----+------------------------+------------+---------+----------------------+ > > * Please remove faad2 from package list (ref. Yaakov's reply). > I have applied these updates. All the the ITPs and ITAs I haven't specifically replied to are also approved. Thanks again! ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Status update (Re: List [ITP],[ITA] by me) 2023-02-13 18:29 ` Jon Turney @ 2023-02-14 9:11 ` Takashi Yano 0 siblings, 0 replies; 10+ messages in thread From: Takashi Yano @ 2023-02-14 9:11 UTC (permalink / raw) To: cygwin-apps On Mon, 13 Feb 2023 18:29:57 +0000 Jon Turney wrote: > On 13/02/2023 10:47, Takashi Yano via Cygwin-apps wrote: > > >> > >> I've posted some specific comments on some of these. > >> > >> Please double-check that packages which contain a soversioned library > >> include that in the package name (for reasons touched on in [1]). > >> > >> If you'd like me to review any of these again, please post the just new > >> .cygport file in a follow-up (since that will save me a little time in > >> having to extract it) > >> > >> I've updated the package list. > >> > >> [1] https://cygwin.com/pipermail/cygwin-apps/2023-January/042480.html > > > > +----+------------------------+------------+---------+----------------------+ > > | No.| Package | Maintainer | GTG | Comment | > > +----+------------------------+------------+---------+----------------------+ > > | 1 | [ITP] AMF | | | | > > | 2 | [ITP] nv-codec-headers | | | | > > | 3 | [ITP] mfx_dispatch | | | | > > | 4 | [ITP] aom | Assigned | Almost | | > > | 5 | [ITP] xvidcore | Assigned | | | > > | 6 | [ITP] openh264 | Assigned | | | > > | 7 | [ITP] ffmpeg | Assigned | | Needs 1,2,3,4,5,6,10 | > > | 8 | [ITP] moc | Assigned | Almost | Needs 7 | > > | 9 | [ITP] libopusenc | | Almost | | > > +----+------------------------+------------+---------+----------------------+ > > | 10 | [ITA] fdk-aac | | Almost | [ITP] -> [ITA] | > > | 11 | [ITA] libsndfile | Assigned | Almost | Needs 13 | > > | 12 | [ITA] pulseaudio | Assigned | Almost | | > > | 13 | [ITA] opus | Assigned | | | > > | 14 | [ITA] opusfile | Assigned | | | > > | 15 | [ITA] opus-tools | Assigned | | Needs 9 | > > | 16 | [ITA] mpg123 | Assigned | Almost | | > > | 17 | [ITA] SDL2 | Assigned | Yes | | > > +----+------------------------+------------+---------+----------------------+ > > | 18 | [ITP] x264 | | | Withdrawn | > > | 19 | [ITP] x265 | | | Withdrawn | > > | 20 | [ITP] faad2 | Assigned * | | Withdrawn | > > +----+------------------------+------------+---------+----------------------+ > > > > * Please remove faad2 from package list (ref. Yaakov's reply). > > > > I have applied these updates. > > All the the ITPs and ITAs I haven't specifically replied to are also > approved. > > Thanks again! Thank you too! -- Takashi Yano <takashi.yano@nifty.ne.jp> ^ permalink raw reply [flat|nested] 10+ messages in thread
end of thread, other threads:[~2023-02-16 18:52 UTC | newest] Thread overview: 10+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2023-02-05 8:40 List [ITP],[ITA] by me Takashi Yano 2023-02-05 16:33 ` Jon Turney 2023-02-06 12:21 ` Takashi Yano 2023-02-13 18:02 ` Jon Turney 2023-02-14 9:11 ` Takashi Yano 2023-02-14 13:33 ` Takashi Yano 2023-02-16 18:52 ` Jon Turney 2023-02-13 10:47 ` Status update (Re: List [ITP],[ITA] by me) Takashi Yano 2023-02-13 18:29 ` Jon Turney 2023-02-14 9:11 ` Takashi Yano
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).