[gentoo-dev] Last-rites: kde-apps/akonadi-notes
# Andreas Sturmlechner (2025-03-07) # No more revdeps after kde-apps/knotes last-rites and Gear 24.08.3 cleanup. # Removal on 2025-03-31. kde-apps/akonadi-notes signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] [PATCH] ffmpeg-compat.eclass: new eclass
On Sun, Mar 09, 2025 at 12:45:37PM -0400, Eli Schwartz wrote:
> On 3/8/25 10:34 PM, Ionen Wolkens wrote:
> > Sending this to dev ML in advance given it's simple and "probably"
> > won't need to change the code further.
> >
> > If interested in the whole deal, see the PR instead:
> > https://github.com/gentoo/gentoo/pull/40942
> >
> > --- (actual commit message below)
> >
> > Both the slotting method and eclass are meant to be as simple
> > as possible, and isolated so that it does not really need to
> > work with everything given non-slotted ffmpeg stays.
> >
> > Did not want turn ffmpeg into a permanent slotting model with
> > a FFMPEG_SLOT use_expand, eselect, or such potentially turning
> > it into a special Gentoo-only thing that often need hacks.
> >
> > Essentially just a way for broken packages to gain time without
> > blocking everyone's ffmpeg updates.
>
>
> What's the advantage of this over, say, just having ffmpeg itself with
> slotting, but only supporting the tools with the latest slot and having
> all old versions be library-only?
> If you anyways have to modify packages relying on older versions as soon
> as a newer version goes stable, then it seems like there shouldn't be a
> major difference here. And keeping it all in one PN would mean you don't
> have issues with ffmpeg and ffmpeg-compat wanting to install each
> others' libraries and maybe ending up with both installed. You also
> wouldn't need to e.g. maintain the same patchset for multiple packages.
Having packages that behave differently within the same namespace
sound confusing to me (and likely to users too). Not only will they have
no tools, but have headers and pkg-config files in non-standard
locations (if not renamed, but that's not better). It's essentially a
slot that's only for other ebuilds, not users.
Don't like the idea of juggling which version provides what too.
Like stable ffmpeg-6.1.2 w/ tools, ~arch ffmpeg-6.1.2-r1 w/o tools
plus ~arch ffmpeg-7.1.1 w/ tools. Kind of confusing and not clear-cut.
Plus we may want to keep several branches and versions, maybe a user
actually wants ffmpeg-6's tools due to some niche regression until
it's fixed. Having all this under media-video/ffmpeg feels messy.
wrt same time, if we *really* don't want that, could always have them
either block each others until versions get cleaned up, it ends up
being the same save for the patches bit.
...but it feels like an unnecessary restriction to me, even if we sync
up all stabilizations perfectly, users will do still accept_keywords
and such (esp. ~arch-only packages) and then run into blockers without
necessarily wanting the latest ffmpeg too.
Also, I'm hoping for usage of ffmpeg-compat to be really low. It's
meant to be a isolated last resort, new ffmpeg major versions will
still be added masked, then we'll try to fix most packages esp.
popular ones, and then give ffmpeg-compat to the rest and hopefully
not get it on many users' system. Problem is that (right now) it's
staying masked for way too long.
wrt patches, current ffmpeg-compat is sharing patches through a tarball
right now, good excuse to kill the 128kB files/ -- not that we couldn't
duplicate a few patches on short notice (but I agree it's not ideal).
The ebuilds are also identical, ffmpeg-compat is not meant to be
maintained on its own until the non-compat equivalent is removed,
just copy incl. keywords. The ${PN} change currently acts as the
trigger to become slotted (not that changing a variable instead would
be a big deal).
--
ionen
signature.asc
Description: PGP signature
Re: [gentoo-dev] [PATCH] ffmpeg-compat.eclass: new eclass
On 3/8/25 10:34 PM, Ionen Wolkens wrote: > Sending this to dev ML in advance given it's simple and "probably" > won't need to change the code further. > > If interested in the whole deal, see the PR instead: > https://github.com/gentoo/gentoo/pull/40942 > > --- (actual commit message below) > > Both the slotting method and eclass are meant to be as simple > as possible, and isolated so that it does not really need to > work with everything given non-slotted ffmpeg stays. > > Did not want turn ffmpeg into a permanent slotting model with > a FFMPEG_SLOT use_expand, eselect, or such potentially turning > it into a special Gentoo-only thing that often need hacks. > > Essentially just a way for broken packages to gain time without > blocking everyone's ffmpeg updates. What's the advantage of this over, say, just having ffmpeg itself with slotting, but only supporting the tools with the latest slot and having all old versions be library-only? If you anyways have to modify packages relying on older versions as soon as a newer version goes stable, then it seems like there shouldn't be a major difference here. And keeping it all in one PN would mean you don't have issues with ffmpeg and ffmpeg-compat wanting to install each others' libraries and maybe ending up with both installed. You also wouldn't need to e.g. maintain the same patchset for multiple packages. -- Eli Schwartz OpenPGP_signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] [PATCH] ffmpeg-compat.eclass: new eclass
On Sat, 2025-03-08 at 22:34 -0500, Ionen Wolkens wrote:
> Sending this to dev ML in advance given it's simple and "probably"
> won't need to change the code further.
>
> If interested in the whole deal, see the PR instead:
> https://github.com/gentoo/gentoo/pull/40942
>
> --- (actual commit message below)
>
> Both the slotting method and eclass are meant to be as simple
> as possible, and isolated so that it does not really need to
> work with everything given non-slotted ffmpeg stays.
>
> Did not want turn ffmpeg into a permanent slotting model with
> a FFMPEG_SLOT use_expand, eselect, or such potentially turning
> it into a special Gentoo-only thing that often need hacks.
>
> Essentially just a way for broken packages to gain time without
> blocking everyone's ffmpeg updates.
>
> Signed-off-by: Ionen Wolkens
> ---
> eclass/ffmpeg-compat.eclass | 69 +
> 1 file changed, 69 insertions(+)
> create mode 100644 eclass/ffmpeg-compat.eclass
>
> diff --git a/eclass/ffmpeg-compat.eclass b/eclass/ffmpeg-compat.eclass
> new file mode 100644
> index ..2d675ab4cc66
> --- /dev/null
> +++ b/eclass/ffmpeg-compat.eclass
> @@ -0,0 +1,69 @@
> +# Copyright 2025 Gentoo Authors
> +# Distributed under the terms of the GNU General Public License v2
> +
> +# @ECLASS: ffmpeg-compat.eclass
> +# @MAINTAINER:
> +# Ionen Wolkens
> +# @AUTHOR:
> +# Ionen Wolkens
> +# @SUPPORTED_EAPIS: 8
> +# @BLURB: Helper functions to link with slotted ffmpeg-compat libraries
> +# @DESCRIPTION:
> +# To use this, run ``ffmpeg_compat_setup `` before packages use
> +# pkg-config, depend on media-video/ffmpeg-compat:=, and ensure
> +# usage of both pkg-config --cflags and --libs (which adds -Wl,-rpath
> +# to find libraries at runtime).
> +#
> +# This eclass is intended as a quick-to-setup alternative to setting
> +# an upper bound on ffmpeg for packages broken with the latest version,
> +# and thus allow users to upgrade their normal ffmpeg.
> +#
> +# This should still be a temporary measure, and it is recommended to
> +# keep migration bugs open rather than consider this eclass as being
> +# the "fix".
> +#
> +# Unlike LLVM_SLOT-style, this does not have USE to select the slot
> +# and should instead pick only the highest one usable until package
> +# is fixed and can use non-slotted ffmpeg again.
> +#
> +# Do *not* use both like ``|| ( ffmpeg-compat: )``,
> +# the package manager cannot know which version it linked against
> +# without USE flags. Unfortunately means a period where users may
> +# have two identical versions in stable before the newest major version
> +# is stabilized, but idea is to not mangle normal ffmpeg with slotting
> +# logic and make this an isolated temporary deal.
> +
> +case ${EAPI} in
> + 8) ;;
> + *) die "${ECLASS}: EAPI ${EAPI:-0} not supported" ;;
> +esac
> +
> +if [[ -z ${_FFMPEG_COMPAT_ECLASS} ]]; then
> +_FFMPEG_COMPAT_ECLASS=1
> +
> +# @FUNCTION: ffmpeg_compat_get_prefix
> +# @USAGE:
> +# @DESCRIPTION:
> +# Return prefix of the installed ffmpeg-compat:. Binaries like
> +# ffmpeg will be found under /bin if needed.
> +ffmpeg_compat_get_prefix() {
> + (( ${#} == 1 )) || die "Usage: ${FUNCNAME} "
> +
> + echo "${EPREFIX}/usr/lib/ffmpeg${1}"
> +}
> +
> +# @FUNCTION: ffmpeg_compat_setup
> +# @USAGE:
> +# @DESCRIPTION:
> +# Add ESYSROOT's ffmpeg-compat: to PKG_CONFIG_PATH for the
> +# current ABI. Can be called multiple times for multilib.
> +ffmpeg_compat_setup() {
> + (( ${#} == 1 )) || die "Usage: ${FUNCNAME} "
> +
> + local path=${SYSROOT}$(ffmpeg_compat_get_prefix "${1}")
> + [[ ${PKG_CONFIG_PATH} =~ (.*)"${path}"/[^/]+/pkgconfig:(.*) ]] &&
> + PKG_CONFIG_PATH=${BASH_REMATCH[1]}${BASH_REMATCH[2]}
> + export
> PKG_CONFIG_PATH=${path}/$(get_libdir)/pkgconfig:${PKG_CONFIG_PATH}
> +}
> +
> +fi
I like this approach. We've generally been quite good at dragging upstreams to
the latest, so it would be a shame to go fully slotted.
The regex check seems like overkill to me, but perhaps I've missed something.
This currently won't work when cross-compiling as cross-pkg-config currently
unsets PKG_CONFIG_PATH, but I have been thinking about changing that. That was
done to tame non-Gentoo environments, but no one else uses crossdev in
reality.
signature.asc
Description: This is a digitally signed message part
Re: [gentoo-dev] [PATCH] ffmpeg-compat.eclass: new eclass
On Sun, Mar 09, 2025 at 10:17:42AM +, James Le Cuirot wrote:
> > +ffmpeg_compat_setup() {
> > + (( ${#} == 1 )) || die "Usage: ${FUNCNAME} "
> > +
> > + local path=${SYSROOT}$(ffmpeg_compat_get_prefix "${1}")
> > + [[ ${PKG_CONFIG_PATH} =~ (.*)"${path}"/[^/]+/pkgconfig:(.*) ]] &&
> > + PKG_CONFIG_PATH=${BASH_REMATCH[1]}${BASH_REMATCH[2]}
> > + export
> > PKG_CONFIG_PATH=${path}/$(get_libdir)/pkgconfig:${PKG_CONFIG_PATH}
> > +}
> > +
> > +fi
>
> I like this approach. We've generally been quite good at dragging upstreams to
> the latest, so it would be a shame to go fully slotted.
>
> The regex check seems like overkill to me, but perhaps I've missed something.
Well, guess could let the multilib paths accumulate given it'll try
the first one anyway. It was just cleaning up the previous one that it
shouldn't use.
>
> This currently won't work when cross-compiling as cross-pkg-config currently
> unsets PKG_CONFIG_PATH, but I have been thinking about changing that. That was
> done to tame non-Gentoo environments, but no one else uses crossdev in
> reality.
Really? There's a few others eclasses that set PKG_CONFIG_PATH.. does
nothing work?
--
ionen
signature.asc
Description: PGP signature
Re: [gentoo-dev] [PATCH] ffmpeg-compat.eclass: new eclass
On Sun, 2025-03-09 at 06:27 -0400, Ionen Wolkens wrote:
> On Sun, Mar 09, 2025 at 10:17:42AM +, James Le Cuirot wrote:
> > > +ffmpeg_compat_setup() {
> > > + (( ${#} == 1 )) || die "Usage: ${FUNCNAME} "
> > > +
> > > + local path=${SYSROOT}$(ffmpeg_compat_get_prefix "${1}")
> > > + [[ ${PKG_CONFIG_PATH} =~ (.*)"${path}"/[^/]+/pkgconfig:(.*) ]] &&
> > > + PKG_CONFIG_PATH=${BASH_REMATCH[1]}${BASH_REMATCH[2]}
> > > + export
> > > PKG_CONFIG_PATH=${path}/$(get_libdir)/pkgconfig:${PKG_CONFIG_PATH}
> > > +}
> > > +
> > > +fi
> >
> > I like this approach. We've generally been quite good at dragging upstreams
> > to
> > the latest, so it would be a shame to go fully slotted.
> >
> > The regex check seems like overkill to me, but perhaps I've missed
> > something.
>
> Well, guess could let the multilib paths accumulate given it'll try
> the first one anyway. It was just cleaning up the previous one that it
> shouldn't use.
>
That's what I thought. I don't mind too much.
> > This currently won't work when cross-compiling as cross-pkg-config currently
> > unsets PKG_CONFIG_PATH, but I have been thinking about changing that. That
> > was
> > done to tame non-Gentoo environments, but no one else uses crossdev in
> > reality.
>
> Really? There's a few others eclasses that set PKG_CONFIG_PATH.. does
> nothing work?
Seems like things I haven't generally tried to cross-compile.
signature.asc
Description: This is a digitally signed message part
[gentoo-dev] Last-rites: kde-apps/kdesdk-thumbnailers-common, media-libs/ksanecore-common, net-misc/kio-zeroconf-common
# Andreas Sturmlechner (2025-03-07) # Downstream-split fallback package for KF5-based revdeps without any # revdeps left. Removal on 2025-03-31. kde-apps/kdesdk-thumbnailers-common media-libs/ksanecore-common net-misc/kio-zeroconf-common signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] [PATCH] ffmpeg-compat.eclass: new eclass
On Sun, Mar 09, 2025 at 10:33:13AM +, James Le Cuirot wrote:
> On Sun, 2025-03-09 at 06:27 -0400, Ionen Wolkens wrote:
> > On Sun, Mar 09, 2025 at 10:17:42AM +, James Le Cuirot wrote:
> > > > +ffmpeg_compat_setup() {
> > > > + (( ${#} == 1 )) || die "Usage: ${FUNCNAME} "
> > > > +
> > > > + local path=${SYSROOT}$(ffmpeg_compat_get_prefix "${1}")
> > > > + [[ ${PKG_CONFIG_PATH} =~ (.*)"${path}"/[^/]+/pkgconfig:(.*) ]]
> > > > &&
> > > > + PKG_CONFIG_PATH=${BASH_REMATCH[1]}${BASH_REMATCH[2]}
> > > > + export
> > > > PKG_CONFIG_PATH=${path}/$(get_libdir)/pkgconfig:${PKG_CONFIG_PATH}
> > > > +}
> > > > +
> > > > +fi
> > >
> > > I like this approach. We've generally been quite good at dragging
> > > upstreams to
> > > the latest, so it would be a shame to go fully slotted.
> > >
> > > The regex check seems like overkill to me, but perhaps I've missed
> > > something.
> >
> > Well, guess could let the multilib paths accumulate given it'll try
> > the first one anyway. It was just cleaning up the previous one that it
> > shouldn't use.
> >
>
> That's what I thought. I don't mind too much.
I went ahead and removed it, on 2nd thought I didn't like it either.
Thanks.
> > > This currently won't work when cross-compiling as cross-pkg-config
> > > currently
> > > unsets PKG_CONFIG_PATH, but I have been thinking about changing that.
> > > That was
> > > done to tame non-Gentoo environments, but no one else uses crossdev in
> > > reality.
> >
> > Really? There's a few others eclasses that set PKG_CONFIG_PATH.. does
> > nothing work?
>
> Seems like things I haven't generally tried to cross-compile.
It's used for the same purpose in e.g. lua eclasses which put their
lua.pc in ${T}. Not looked too closely but python, vala, postgres
eclasses to do this too. It's likely that cross still "works" given
it uses the system's .pc file which could be the wrong version.
Much like how it'll still "work" here by linking to the unslotted
ffmpeg.. albeit these packages will likely be broken with latest
version and fail to build :) Been seeing it as the failsafe.
I do think this should be changed as well anyhow, maybe it could
only filter paths not in ROOT.. or so I'd like to say, but that
doesn't handle the T or WORKDIR cases.
--
ionen
signature.asc
Description: PGP signature
Re: [gentoo-dev] [PATCH] ffmpeg-compat.eclass: new eclass
On Sat, Mar 08, 2025 at 10:34:31PM -0500, Ionen Wolkens wrote: > Sending this to dev ML in advance given it's simple and "probably" > won't need to change the code further. > > If interested in the whole deal, see the PR instead: > https://github.com/gentoo/gentoo/pull/40942 On a side-note, the ffmpeg ebuild was also rewritten in that PR which may be of more interest than the slotting to some. See the `rewrite live ebuild` commit message if want details, some changes are debatable and may anger some users, albeit I'm mostly aiming for stabler ffmpeg. -- ionen signature.asc Description: PGP signature
[gentoo-dev] Last rites: dev-lang/gnat-gpl
# Sam James (2025-03-09) # Obsolete in favour of dev-lang/ada-bootstrap. Using sys-devel/gcc[ada] # should now Just Work. Removal on 2025-04-10. dev-lang/gnat-gpl
