Re: [ITA] pocl
> On 03/01/2024 06:25, Takashi Yano via Cygwin-apps wrote: > > On Wed, 3 Jan 2024 14:14:12 +0900 > > Takashi Yano via Cygwin-apps wrote: > >> I'd like to adopt the pocl package. > >> > >> - Update to latest upstream release. > > $ git diff |grep "^+" > +++ b/cygwin-pkg-maint > +pocl Takashi Yano Gold star awarded! https://cygwin.com/goldstars/#TY
Automatic announcement generation by calm
This is an experimental facility, currently only available for packages
deployed from the build service [1] (that is, not for self-built
packages uploaded with 'cygport up' via sftp)
When the token "announce" is present for a build job (in addition to
"deploy"), after a successful deploy, calm will automatically generate
and send an announce email.
The mail follows a similar format to that generated by "cygport
announce", containing a list of packages and the description, with the
following addition:
* If the cygport defines the variable "ANNOUNCE", it's evaluated
contents will be appended to the generated mail.
* Otherwise, if the source package contains an ANNOUNCE file [2], it's
contents will be appended.
* Otherwise, if the source package contains a README or ${PN}.README
file, lines that look like part of a changelog, between one starting
with ' ${PVR}' and the next starting '', will be extracted and
appended
(None of these seem like a particularly great way of doing things, but
they match some historical patterns. As always, suggestions about
improvements are welcome.)
In accordance with our long-standing policy of treating maintainer email
addresses as private information, the mail is sent from cygwin-no-reply
and bcc'ed to the uploader.
For testing purposes, if the token "mock" (yes, I am running out of
synonyms for "test"...) is also present, the mail will be only sent to
the uploader, not the announce list.
[1] https://cygwin.com/packaging/build.html
[2] Note that this isn't currently part of the default value of
CYGWIN_FILES [3], so needs to be explicitly listed there to be included
in the source package
[3] https://cygwin.github.io/cygport/src_prep_cygpart.html#CYGWIN_FILES
Re: Unmaintained packages in base package set
Takashi Yano via Cygwin-apps writes: > I found the cause. DISTCLEANFILES in original cygport file removes them. > Now I can successfully build libatk1.0-doc. Thanks! No, that means the tarball includes files that should get re-built, but apparently you somehow failed to do that. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ Factory and User Sound Singles for Waldorf rackAttack: http://Synth.Stromeko.net/Downloads.html#WaldorfSounds
Re: Unmaintained packages in base package set
On Sun, 7 Jan 2024 22:35:02 +0900 Takashi Yano via wrote: > In the source file, docs/xml directory should have document contents, > however, it is empty. So, I thought document cannot be built in this > version. I'll check again. I found the cause. DISTCLEANFILES in original cygport file removes them. Now I can successfully build libatk1.0-doc. Thanks! -- Takashi Yano
Re: Unmaintained packages in base package set
On Sun, 7 Jan 2024 12:54:35 +
Jon Turney wrote:
> > ERROR: package 'atk1.0-src' version '2.38.0-1' build-depends:
> > 'girepository(GLib-2.0)', but nothing satisfies that
> > ERROR: package 'atk1.0-src' version '2.38.0-1' build-depends:
> > 'pkgconfig(glib-2.0)', but nothing satisfies that
> > ERROR: package 'libatk1.0-doc' version '2.38.0-1' has empty install tar
> > file, but it's not in ['_obsolete'] category
>
> I guess I should ask about these errors and how you fixed them:
>
> * This documented but unimplemented style of dependency atom was dropped
> [1], because we don't have a good way of supporting it.
>
> But rather than just removing them, they should probably have been
> replaced with the appropriate package names (those containing
> GLib-2.0.gir and glib-2.0.pc, i.e. girepository-GLib2.0 and
> libglib2.0-devel)
The previous cygport file uses DEPEND and cygport warned to use
BUILD_REQUIRES instead. Then the above error occured. So, I just
remove them because I was not sure how to fix that.
Thanks for letting me know that!
> * Are you sure that libatk1.0-doc should be empty now (and not that it
> requires some tool to build the documentation which isn't installed)?
In the source file, docs/xml directory should have document contents,
however, it is empty. So, I thought document cannot be built in this
version. I'll check again.
> If it is the case that the documentation doesn't exist any more, I think
> you should perhaps make some arrangement for obsoleting the package,
> rather than simply stopping generating it, allowing the previous version
> to linger indefinitely in places where it is already installed.
Now the cygport file has the line:
libatk1_0_0_OBSOLETES="lib${NAME}-doc"
> (e.g. obsoleting it by the devel package, or marking the package as
> self-destruct)
Is this as you suggested?
--
Takashi Yano
Re: [ITA] pocl
On Sun, 7 Jan 2024 12:51:42 + Jon Turney wrote: > On 03/01/2024 09:29, Takashi Yano via Cygwin-apps wrote: > >>> > - Enable CUDA support. > >> > >> Curiosity, how do we support CUDA on Cygwin ? > > > > nvidia cuda toolkit is used in build stage of user programs. > > Although this is not very desirable for cygwin package, I thought > > that the advantage of being able to use the GPU was greater than > > the disadvantage. > > > > However, on the second thought, cuda support should be a separeted > > package from the base package, and suggest installing cuda toolkit > > in the install stage of of that package. > > If a 3rd party driver etc. needs to be installed for a Cygwin package to > work, we have in the past used the 'message' line in a .hint so setup > says that when it is installed. > > (Unfortunately, generating that line is not currently supported by > cygport, I think) Thanks for the advice. In the latest release candidate, cuda suppourt module is not in separated package. Instead, if NVIDIA GPU is detected and user specify to use GPU, but CUDA Toolkit is not installed: On Thu, 4 Jan 2024 09:55:07 +0900 Takashi Yano wrote: > time to build the kernel objects. If no CUDA Toolkit is found at > this time, the message: > "[CUDA] failed to open libdevice library file. Most likely, you do > not have NVIDIA CUDA Toolkit. Please consider to install it. If you > have it installed, set CUDA_PATH properly." > will be shown. -- Takashi Yano
Re: Unmaintained packages in base package set
On 03/01/2024 07:49, Marco Atzeri via Cygwin-apps wrote: On 03/01/2024 05:59, Takashi Yano via Cygwin-apps wrote: On Sat, 23 Dec 2023 04:51:22 +0100 Marco Atzeri wrote: On 23/12/2023 04:42, Takashi Yano via Cygwin-apps wrote: I suggest to start with the smaller beasts one by one or small groups I suspect GTK3 needs a lot of effort Thanks for the advice. Now, GTK3 package of 3.24.39 has been successfully built and packaged in my environment with updating some other related packages. So, firstly, I would like to take over following packages that are related to GTK3. fribidi 0.19.7 -> 1.0.13 libdatrie 0.28 -> 0.2.13 libthai 0.1.26 -> 0.1.29 pango1.0 1.40.14 -> 1.51.0 atk1.0 2.26.1 -> 2.38.0 gtk3 3.22.28 -> 3.24.39 Firstly, thanks for taking over these. ERROR: package 'atk1.0-src' version '2.38.0-1' build-depends: 'girepository(GLib-2.0)', but nothing satisfies that ERROR: package 'atk1.0-src' version '2.38.0-1' build-depends: 'pkgconfig(glib-2.0)', but nothing satisfies that ERROR: package 'libatk1.0-doc' version '2.38.0-1' has empty install tar file, but it's not in ['_obsolete'] category I guess I should ask about these errors and how you fixed them: * This documented but unimplemented style of dependency atom was dropped [1], because we don't have a good way of supporting it. But rather than just removing them, they should probably have been replaced with the appropriate package names (those containing GLib-2.0.gir and glib-2.0.pc, i.e. girepository-GLib2.0 and libglib2.0-devel) * Are you sure that libatk1.0-doc should be empty now (and not that it requires some tool to build the documentation which isn't installed)? If it is the case that the documentation doesn't exist any more, I think you should perhaps make some arrangement for obsoleting the package, rather than simply stopping generating it, allowing the previous version to linger indefinitely in places where it is already installed. (e.g. obsoleting it by the devel package, or marking the package as self-destruct) [1] https://cygwin.com/cgit/cygwin-apps/cygport/commit/?id=c8cb44a50377fb87c579280a490fc127562ced40
Re: [ITA] pocl
On 03/01/2024 09:29, Takashi Yano via Cygwin-apps wrote: - Enable CUDA support. Curiosity, how do we support CUDA on Cygwin ? nvidia cuda toolkit is used in build stage of user programs. Although this is not very desirable for cygwin package, I thought that the advantage of being able to use the GPU was greater than the disadvantage. However, on the second thought, cuda support should be a separeted package from the base package, and suggest installing cuda toolkit in the install stage of of that package. If a 3rd party driver etc. needs to be installed for a Cygwin package to work, we have in the past used the 'message' line in a .hint so setup says that when it is installed. (Unfortunately, generating that line is not currently supported by cygport, I think)
[ITP] svt-av1
SVT-AV1 is video encoder/decoder for av1, which has
very fast encoder compared with aom. Fedora has this
package. https://src.fedoraproject.org/rpms/svt-av1
I would like to enable svt-av1 encoding in ffmpeg via
this package.
Thanks in advance.
--
Takashi Yano
NAME="svt-av1"
VERSION=1.8.0
RELEASE=1
LICENSE="BSD-3-Clause"
CATEGORY="Video"
SUMMARY="Scalable Video Technology for AV1 (Encoer and Decoder)"
DESCRIPTION="The Scalable Video Technology for AV1 (SVT-AV1 Encoder and
Decoder) is an AV1-compliant software encoder/decoder library. The work on the
SVT-AV1 encoder targets the development of a production-quality AV1-encoder
with performance levels applicable to a wide range of applications, from
premium VOD to real-time and live encoding/transcoding. The SVT-AV1 decoder
implementation targets future codec research activities."
HOMEPAGE="https://gitlab.com/AOMediaCodec/SVT-AV1;
inherit cmake
SRC_URI="https://gitlab.com/AOMediaCodec/SVT-AV1/-/archive/v${VERSION}/SVT-AV1-v${VERSION}.tar.bz2;
SRC_DIR="SVT-AV1-v${VERSION}"
PKG_NAMES="
svt-av1
libsvtav1
libsvtav1-devel
libsvtav1-doc
"
svt_av1_CONTENTS="usr/bin/*.exe"
libsvtav1_CONTENTS="usr/bin/*.dll"
libsvtav1_devel_CONTENTS="usr/include usr/lib"
libsvtav1_doc_CONTENTS="usr/share/doc"
DIFF_EXCLUDES="libSvtAv1Dec.dll.a libSvtAv1Enc.dll.a"
BUILD_REQUIRES="cmake ninja yasm"
--- origsrc/SVT-AV1-v1.8.0/CMakeLists.txt 2023-12-14 21:33:03.0
+0900
+++ src/SVT-AV1-v1.8.0/CMakeLists.txt 2023-12-29 18:52:22.597806200 +0900
@@ -220,7 +220,7 @@ if(UNIX)
set(CMAKE_CXX_ARCHIVE_FINISH "
-no_warning_for_no_symbols -c ")
endif()
else()
-set(CMAKE_EXE_LINKER_FLAGS "${CMAKE_EXE_LINKER_FLAGS} -z noexecstack
-z relro -z now")
+set(CMAKE_EXE_LINKER_FLAGS "${CMAKE_EXE_LINKER_FLAGS}
-Wa,--noexecstack")
endif()
endif()
--- origsrc/SVT-AV1-v1.8.0/Source/App/EncApp/EbAppConfig.c 2023-12-14
21:33:03.0 +0900
+++ src/SVT-AV1-v1.8.0/Source/App/EncApp/EbAppConfig.c 2023-12-29
18:52:22.602058200 +0900
@@ -275,7 +275,7 @@ static Bool fopen_and_lock(FILE **file,
return FALSE;
const char *mode = write ? "wb" : "rb";
-FOPEN(*file, name, mode);
+SVT_FOPEN(*file, name, mode);
if (!*file)
return FALSE;
@@ -304,7 +304,7 @@ static EbErrorType open_file(FILE **file
}
FILE *f;
-FOPEN(f, name, mode);
+SVT_FOPEN(f, name, mode);
if (!f)
return validate_error(EB_ErrorBadParameter, token, name);
@@ -330,7 +330,7 @@ static EbErrorType set_cfg_input_file(Eb
cfg->input_file = stdin;
cfg->input_file_is_fifo = TRUE;
} else
-FOPEN(cfg->input_file, value, "rb");
+SVT_FOPEN(cfg->input_file, value, "rb");
if (cfg->input_file == NULL) {
return validate_error(EB_ErrorBadParameter, token, value);
@@ -1548,7 +1548,7 @@ static EbErrorType read_config_file(EbCo
FILE *config_file;
// Open the config file
-FOPEN(config_file, config_path, "rb");
+SVT_FOPEN(config_file, config_path, "rb");
if (!config_file) {
fprintf(stderr, "Error channel %u: Couldn't open Config File: %s\n",
instance_idx + 1, config_path);
return EB_ErrorBadParameter;
--- origsrc/SVT-AV1-v1.8.0/Source/App/EncApp/EbAppConfig.h 2023-12-14
21:33:03.0 +0900
+++ src/SVT-AV1-v1.8.0/Source/App/EncApp/EbAppConfig.h 2023-12-29
18:52:22.639768700 +0900
@@ -52,9 +52,9 @@ typedef enum EncPass {
#define MAX_NUM_TOKENS 210
#ifdef _WIN32
-#define FOPEN(f, s, m) fopen_s(, s, m)
+#define SVT_FOPEN(f, s, m) fopen_s(, s, m)
#else
-#define FOPEN(f, s, m) f = fopen(s, m)
+#define SVT_FOPEN(f, s, m) f = fopen(s, m)
#endif
typedef struct EbPerformanceContext {
--- origsrc/SVT-AV1-v1.8.0/Source/Lib/Common/ASM_AVX2/dav1d_x86inc.asm
2023-12-14 21:33:03.0 +0900
+++ src/SVT-AV1-v1.8.0/Source/Lib/Common/ASM_AVX2/dav1d_x86inc.asm
2023-12-29 19:00:25.994706400 +0900
@@ -61,7 +61,7 @@
%elifidn __OUTPUT_FORMAT__,x64
%define WIN64 1
%else
-%define UNIX64 1
+%define WIN64 1
%endif
%endif
--- origsrc/SVT-AV1-v1.8.0/Source/Lib/Common/ASM_SSE2/x64inc.asm
2023-12-14 21:33:03.0 +0900
+++ src/SVT-AV1-v1.8.0/Source/Lib/Common/ASM_SSE2/x64inc.asm2023-12-29
18:52:22.642767800 +0900
@@ -18,7 +18,7 @@
%elifidn __OUTPUT_FORMAT__,x64
%define WIN64 1
%else
-%define UNIX64 1
+%define WIN64 1
%endif
%undef FORMAT_ELF
--- origsrc/SVT-AV1-v1.8.0/Source/Lib/Common/ASM_SSE2/x86inc.asm
2023-12-14 21:33:03.0 +0900
+++ src/SVT-AV1-v1.8.0/Source/Lib/Common/ASM_SSE2/x86inc.asm2023-12-29
18:52:22.645765800 +0900
@@ -133,7 +133,7 @@ HAVE_WXWIDGETS equ 0
%elifidn __OUTPUT_FORMAT__,x64
%define WIN64 1
%else
-%define UNIX64 1
+%define WIN64 1
%endif
%endif
