```
$ git shortlog d4ff0020b40b524a490cf62eccbd3a318f4c0e58..HEAD
Anton Khirnov (1):
lavc/dvdsubenc: only check canvas size when it is actually set
Benjamin Cheng (1):
hwcontext_vulkan: guard unistd.h include
Dmitry Rogozhkin (1):
avcodec/decode: validate hw_frames_ctx when AVHWAccel.free_frame_priv is used
Lynne (1):
lavc/Makefile: build vulkan decode code if vulkan_av1 has been enabled
Sebastian Ramacher (2):
avcodec/fft: Use av_mallocz to avoid invalid free/uninit
avcoded/fft: Fix memory leak if ctx2 is used
```
Closes: https://bugs.gentoo.org/920185
Signed-off-by: Sam James <sam@gentoo.org>
Checking the test phase output, it is not implemented and does nothing.
Or to be more accurate, it compiles one executable but never runs
anything.
The former testsuite in the 1.x series has been divided up, just like
the constituent installable components, and it turns out that all
testable parts are in the split-out packages and none are left here.
Signed-off-by: Eli Schwartz <eschwartz93@gmail.com>
Signed-off-by: Sam James <sam@gentoo.org>
The tests are newly created during the 2.x upgrade. They will hang
forever if they cannot run properly. And running them properly has hit a
wall. I'm not sure where to go on from here.
Even getting this far means stepping outside of what portage can
reasonably require. Avahi only runs as root, and doesn't seem to have a
mocking mode, and even if it is running, the sandbox prevents src_test
from seeing it.
Signed-off-by: Eli Schwartz <eschwartz93@gmail.com>
Signed-off-by: Sam James <sam@gentoo.org>
If USE=test, an option was passed to configure that makes unittest
binaries be built, and as a side effect also runs them. But we really do
not want to run tests in src_compile, as FEATURES=test might not be set.
Crudely hack around this by overriding the autoconf variable that would
normally be set by `$(use_enable test unit-tests)`, when running the
test invocation itself. As a side effect, this also moves the
test-program compilation to src_test.
Signed-off-by: Eli Schwartz <eschwartz93@gmail.com>
Signed-off-by: Sam James <sam@gentoo.org>
They appear to work at the moment. There's a fun oddity, in that if
libcupsfilters is installed you need image support of some variety.
Signed-off-by: Eli Schwartz <eschwartz93@gmail.com>
Signed-off-by: Sam James <sam@gentoo.org>
It is a PDEPEND which forces installing both, and makes building a
modular cups-filters more challenging.
Additionally, many "users" of cups may not actually want cups-filters at
all.
- A primary reason is because cups provides libcups, which other
packages need as an RDEPEND in order to support USE=cups while not
having any expectation of using a printing stack (at least, yet).
- Even more fun, sometimes users have -bin packages where upstream has
built the binaries against libcups on the assumption that users who
want cups support will automatically get it and users who don't want
cups support "just" need the debian libcups2 split binary package.
This isn't really solvable without providing a minimal libcups-only
experience.
Rely instead on a metapackage for the full cups experience.
Bug: https://bugs.gentoo.org/222601
Bug: https://bugs.gentoo.org/914586
Closes: https://bugs.gentoo.org/813507
Closes: https://github.com/gentoo/gentoo/pull/31784
Signed-off-by: Eli Schwartz <eschwartz93@gmail.com>
Signed-off-by: Sam James <sam@gentoo.org>
New metapackage to pull in all the parts for a functional cups printing
stack. This will allow to avoid relying on net-print/cups for that
purpose -- because, with the advent of cups-filters 2.0.0 and the
ongoing work to refactor CUPS 3, things are broken out into various
interconnected components and configuring each one is not perfectly
straightforward. Eventually, there will not be a "cups" package at all
anyway.
Additionally, this helps solve a longstanding cycle with cups <-->
cups-filters that has only gotten worse since the latter was broken up
into various packages which require libcups from cups, which in turn
depends on -filters. There are a number of use cases for having cups
installed in "minimal" mode so that other packages can build against it.
Signed-off-by: Eli Schwartz <eschwartz93@gmail.com>
Signed-off-by: Sam James <sam@gentoo.org>
Part of the CUPS v3 evolution. Now, cups-filters has been split out into
multiple sub-packages. This contains the standalone browsed component.
Bug: https://bugs.gentoo.org/914586
Signed-off-by: Eli Schwartz <eschwartz93@gmail.com>
Signed-off-by: Sam James <sam@gentoo.org>
Part of the CUPS v3 evolution. Now, cups-filters has been split out into
multiple sub-packages. The new version of cups-filters depends on a
couple of extracted libraries, and builds on these to distribute the
actual filters. It no longer handles browsed at all -- this is a
completely separate, optional component.
Most options are no longer relevant, as they are encapsulated in the
subpackages.
Closes: https://bugs.gentoo.org/914586
Signed-off-by: Eli Schwartz <eschwartz93@gmail.com>
Signed-off-by: Sam James <sam@gentoo.org>
Part of the CUPS v3 evolution. Now, cups-filters has been split out into
multiple sub-packages. This is the legacy PPD filters core library.
Bug: https://bugs.gentoo.org/914586
Signed-off-by: Eli Schwartz <eschwartz93@gmail.com>
Signed-off-by: Sam James <sam@gentoo.org>
Just to clarify that this was an issue when not building tests too.
Primary reason this been made default was because some other dev-qt
packages (qtdeclarative I recall?) failed even with USE=-test and
did not felt worth working around nor have a IUSE=+testlib (saves
the need to declare it for tests on a whole lot of packages too).
Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
Michał Górny
Sam James
Zac Medico
Eli Schwartz
Ionen Wolkens
Mike Pagano