devel December 2024

devel@lists.fedoraproject.org

145 participants
189 discussions

Orphaned magic-wormhole + its python deps
by Fabio Valentini 21 Jan '25

21 Jan '25

Hi everyone, I have just orphaned magic-wormhole (the original one written in Python) and its dependencies. I no longer use it, I have no time to fix the packages for new Python versions, and upstream is pretty much dead since they started porting the project to Rust. - python-magic-wormhole - python-magic-wormhole-mailbox-server - python-magic-wormhole-transit-relay - python-txtorcon - python-spake2 - python-hkdf There is an alternative Go implementation of the "Wormhole Protocol" (wormhole-william), for which eclipseo already submitted a review request. It seems to be better maintained than the Python original, if we want to have a Wormhole client in Fedora: https://bugzilla.redhat.com/show_bug.cgi?id=1922806 The official port of magic-wormhole to Rust also seems to be progressing, we might want to package that one instead once it's released: https://github.com/magic-wormhole/magic-wormhole.rs Fabio

4 6

F42 Change Proposal: GNOME Shell extension Dependency Generator (system-wide)
by Aoife Moloney via devel-announce 21 Jan '25

21 Jan '25

Wiki - https://fedoraproject.org/wiki/Changes/GnomeShellExtensionDependencyGenerat… Discussion thread - https://discussion.fedoraproject.org/t/f42-change-proposal-gnome-shell-exte… This is a proposed Change for Fedora Linux. This document represents a proposed Change. As part of the Changes process, proposals are publicly announced in order to receive community feedback. This proposal will only be implemented if approved by the Fedora Engineering Steering Committee. == Summary == Implement a dependency generator for GNOME Shell extensions that would make the binary RPM depend on the correct versions of GNOME Shell == Owner == * Name: [[User:salimma|Michel Lind]], [[User:ngompa|Neal Gompa]] * Email: michel(a)michel-slm.name, ngompa13(a)gmail.com == Detailed Description == GNOME Shell extensions ship with a `metadata.json` that lists the supported versions of GNOME Shell. This data is currently unused when packaging an extension, unless the package maintainer explicitly transfer this information to the spec -- and then keeps it up to date. With this Change Proposal implemented, the binary RPM would automatically declare its dependency on the right versions of GNOME Shell, ensuring that we will discover after mass rebuild if some extensions need to be updated because they will FTI. == Feedback == == Benefit to Fedora == This will result in an improved user experience for our users, because extensions that install are now more likely to work. It will also help extension packagers, as they get early signal that an extension needs to be updated, by getting a FTI bug not long after the mass rebuild is complete. == Scope == * Proposal owners: ** Implement a dependency generator and package it as `gnome-shell-extension-rpm-macros` ** make `gnome-shell` `Provides: gnome-shell(api) == MAJOR_VER` to make the implementation of the generator easier ** Get this package pulled in by `redhat-rpm-config` ** Optionally get this into `epel-rpm-macros` for EPEL 10 ** Provide a COPR for other developers to test * Other developers: ** Test your package by explicitly adding the new dependency generator package as a `BuildRequires` and dropping the `Requires` on `gnome-shell` ** If that works, once the new package is in Fedora and pulled in by `redhat-rpm-config`, you may (but do not have to) drop the `Requires` on `gnome-shell` as it will be redundant * Release engineering: [https://pagure.io/releng/issues #Releng issue number] * Policies and guidelines: [https://pagure.io/packaging-committee/pull-request/1425 FPC #1425] This should only land after implementation is done * Trademark approval: N/A (not needed for this Change) * Alignment with the Fedora Strategy: == Upgrade/compatibility impact == N/A. This change would be transparent to packagers and end-users - it will allow packagers to clean up their spec by removing the explicit `Requires` on `gnome-shell` but that is optional == Early Testing (Optional) == == How To Test == == User Experience == == Dependencies == This requires changes to `gnome-shell` and optionally `redhat-rpm-config`. The former significantly eases implementation, as it allows a 1:1 mapping between the version listed in `metadata.json` and what we express in the binary RPM. The latter is required to make this transparent to other packagers; if that change does not go through this becomes a self-contained change and extension maintainers can opt in by BR-ing the package == Contingency Plan == * Contingency mechanism: (What to do? Who will do it?) If the dependency generator turns out to be very buggy, we can stop pulling it in `redhat-rpm-config` * Contingency deadline: Beta freeze * Blocks release? No == Documentation == N/A == Release Notes == -- Aoife Moloney Fedora Operations Architect Fedora Project Matrix: @amoloney:fedora.im IRC: amoloney -- _______________________________________________ devel-announce mailing list -- devel-announce(a)lists.fedoraproject.org To unsubscribe send an email to devel-announce-leave(a)lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel-announce@lists.fedorapr… Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue

3 2

F42 Change Proposal: Replace SDL 2 with sdl2-compat using SDL 3 (self-contained)
by Aoife Moloney via devel-announce 19 Jan '25

19 Jan '25

Wiki - https://fedoraproject.org/wiki/Changes/SDL2onSDL3 Discussion Thread - https://discussion.fedoraproject.org/t/f42-change-proposal-replace-sdl-2-wi… This is a proposed Change for Fedora Linux. This document represents a proposed Change. As part of the Changes process, proposals are publicly announced in order to receive community feedback. This proposal will only be implemented if approved by the Fedora Engineering Steering Committee. == Summary == This Change proposes to replace SDL 2 with sdl2-compat, which uses SDL 3. == Owner == * Name: [[User:Ngompa| Neal Gompa]] * Email: ngompa13(a)gmail.com == Detailed Description == SDL 2 feature development ended some time ago with efforts being focused on SDL 3. However, many older games still use SDL 2 and cannot change to SDL 3. In order to continue to support SDL 2 games in the modern world, let's replace SDL 2 with sdl2-compat, which uses SDL 3. This also has the effect of moving SDL 1.2 games to SDL3 through sdl12-compat running on sdl2-compat. == Feedback == == Benefit to Fedora == Switching SDL 2 powered games to use <code>sdl2-compat</code> ensures that SDL-based applications continue to use the actively developed codebase. This also has the effect of SDL 1.2 powered games that use <code>sdl12-compat</code> to run on SDL3 as well through the fully supported path of <code>sdl12-compat</code> running on <code>sdl2-compat</code> running on SDL3. == Scope == * Proposal owners: ** Package [https://github.com/libsdl-org/sdl2-compat libsdl2-compat] (native: [https://bugzilla.redhat.com/2316576 RH#2316576], mingw: [https://bugzilla.redhat.com/2330101 RH#2330101]) ** Retire {{package|SDL2}} and {{package|mingw-SDL2}} completely * Other developers: * Release engineering: [https://pagure.io/releng/issue/12485 #12485] * Policies and guidelines: N/A (not needed for this Change) * Trademark approval: N/A (not needed for this Change) * Alignment with the Fedora Strategy: N/A == Upgrade/compatibility impact == The <code>SDL2</code> package would be transparently upgraded to <code>libsdl2-compat</code> package and games using it should just transparently start using SDL 3.0. == How To Test == The testing steps are simple: 0. Enable the [https://copr.fedorainfracloud.org/coprs/ngompa/SDL2onSDL3/ <code>SDL2onSDL3</code> COPR]: <code>dnf copr enable ngompa/SDL2onSDL3</code> 1. Swap <code>SDL2</code> for <code>sdl2-compat</code>: <code>dnf swap SDL2 sdl2-compat</code> 2. Run something that uses SDL 2 like {{package|supertuxkart}} and see that it works. 3. Run something that uses SDL 1.2 like {{package|icebreaker}} and see that it works. Issues should be reported upstream for the fastest response: https://github.com/libsdl-org/sdl2-compat/issues  == User Experience == There shouldn't be a noticeable user impact, other than possibly a smoother experience because applications are using SDL 3.0. == Dependencies == == Contingency Plan == * Contingency mechanism: Revert back to shipping SDL2 / mingw-SDL2 packages * Contingency deadline: Final Freeze * Blocks release? N/A (not a System Wide Change) == Documentation == N/A (not a System Wide Change) == Release Notes == Applications that use SDL 2 will now transparently use SDL 3 through the <code>sdl2-compat</code> package. This makes it so applications that historically used SDL 2 now use SDL 3. -- Aoife Moloney Fedora Operations Architect Fedora Project Matrix: @amoloney:fedora.im IRC: amoloney -- _______________________________________________ devel-announce mailing list -- devel-announce(a)lists.fedoraproject.org To unsubscribe send an email to devel-announce-leave(a)lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel-announce@lists.fedorapr… Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue

3 3

F42 Change Proposal: RPM Support For Systemd Sysusers.d (system-wide)
by Aoife Moloney via devel-announce 14 Jan '25

14 Jan '25

Wiki - https://fedoraproject.org/wiki/Changes/RPMSuportForSystemdSysusers Discussion thread - https://discussion.fedoraproject.org/t/f42-change-proposal-rpm-support-for-… This is a proposed Change for Fedora Linux. This document represents a proposed Change. As part of the Changes process, proposals are publicly announced in order to receive community feedback. This proposal will only be implemented if approved by the Fedora Engineering Steering Committee. == Summary == RPM supports creating users and groups according to configuration provided in sysusers.d snippets shipped in package payload. The goal of the proposal is to fully integrate this RPM functionality in Fedora. == Owner == * Name: Michal Sekletar, Zbigniew Jędrzejewski-Szmek, Panu Matilainen * Email: msekleta(a)redhat.com, zbyszek(a)in.waw.pl, pmatilai(a)redhat.com == Detailed Description == This proposal consists of two parts. The first is to make sure that rpm functionality is fully enabled in Fedora. The second is to update packaging guidelines and raise awareness about the new simpler user creation method for rpm packages. The goal is a fully declarative system user and group management in all RPMs. Over time we should be able to drop all manual `useradd`/`groupadd` invocations or use of `%sysusers_create_compat` macro in rpm scriptlets. Support for sysusers was added in rpm 4.19.0. Support for group membership (`m` lines) was added in rpm 4.20.0. Support for locked-down users (`u!` lines) was added for rpm 4.21.0. The rpm package has patches to disable user/group creation ([https://src.fedoraproject.org/rpms/rpm/blob/rawhide/f/rpm-4.18.92-disable-s… rpm-4.18.92-disable-sysusers.patch]) and make user/group dependencies weak ([https://src.fedoraproject.org/rpms/rpm/blob/rawhide/f/rpm-4.19.91-weak-user… rpm-4.19.91-weak-user-group.patch]). == Feedback == [https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org… Discussion] about idea to submit the proposal on fedora-devel list. == Benefit to Fedora == * Declarative system user and group management by packages * Potential for spec file simplification, concretely, removal of relevant part of %pre scripts in some packages. * Ability to query what user and groups are provided by given package as well as ability to have dependencies on users/groups from different packages. * Make use of native rpm functionality in favor of current %sysusers_compat_create. == Scope == * Proposal owners: ** Change rpm so that it generates hard dependency between packages A and B in case B depends on user or group provided by package A. Rpm currently has downstream patch so that only weak dependencies are generated. ** Make sure that previous change in rpm doesn't cause package dependency loops during system installation. ** Work on fix for shadow-utils so that useradd and groupadd work correctly in chroot on SELinux enabled systems (shadow-utils [https://github.com/shadow-maint/shadow/issues/940| issue].) * Other developers: ** We would welcome any help with shadow-utils [https://github.com/shadow-maint/shadow/issues/940| issue]. * Release engineering: N/A (not needed for this Change) * Policies and guidelines: N/A (not needed for this Change) * Trademark approval: N/A (not needed for this Change) * Alignment with the Fedora Strategy: == Upgrade/compatibility impact == There is no upgrade/compatibility impact. == How To Test == * Select rpm package that creates system user/group account in %pre * Remove part of %pre scriptlet that handles user/group creation * Create equivalent [https://www.freedesktop.org/software/systemd/man/latest/sysusers.d.html| sysusers.d] configuration file and ship it as part of rpm payload under /usr/lib/sysusers.d/. * Rebuild the package * Verify that package has been built correctly and it has rpm provides for installed user account and group (e.g. `user(foo) = ABUNCHOFHEXHERE`, `group(bar) = ADIFFERNTBUNCHOFHEXHERE`). Use `rpm -qP $package | awk '/(user|group)\(/ {print $3}' | base64 -d` and check that the output looks reasonable. * Verify that you can install the package and installed files have correct ownership. == User Experience == There shouldn't be any user observable change to previous state. Potential packaging related benefits are mostly of interest to package maintainers. == Dependencies == None == Contingency Plan == * Contingency mechanism: If we are not confident by mass-rebuild that we can deliver the feature we will postpone its delivery to later Fedora release. There are no explicit rollback/cleanup actions that need to taken. * Contingency deadline: Mass Rebuild of RPMs on Wed 2025-01-15. * Blocks release? No == Documentation == [https://github.com/rpm-software-management/rpm/blob/master/docs/manual/user… sysusers.d support in RPM]. == Release Notes == N/A -- Aoife Moloney Fedora Operations Architect Fedora Project Matrix: @amoloney:fedora.im IRC: amoloney -- _______________________________________________ devel-announce mailing list -- devel-announce(a)lists.fedoraproject.org To unsubscribe send an email to devel-announce-leave(a)lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel-announce@lists.fedorapr… Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue

6 11

Forming a lightweight SIG around MkDocs
by Davide Cavalca 13 Jan '25

13 Jan '25

MkDocs (https://www.mkdocs.org/) is a Markdown-based website maker, geared towards technical documentation. The CentOS Project has historically used MkDocs for SIG documentation, and the CentOS Docs SIG has recently standardized on MkDocs for the overall project, leading to the creation of a collated documentation site at https://docs.centos.org (sources: https://gitlab.com/CentOS/docs/docs.centos.org) To ease this work, I've been working on getting the MkDocs stack back in shape in Fedora, with the goal of eventually branching it for EPEL 10. Because MkDocs is quite sprawling, I'd like to setup a lightweight SIG around it to ease package maintenance of the stack. By "lightweight" I mean that I expect this will mostly be used for package ACLs and bug triage. While I mostly expect folks from the CentOS Docs SIG to join in, this is by all means open to anybody interested in collaborating. Cheers Davide

6 8

Heads-up: rubberband ABI bump for Rawhide (2 -> 3)
by Michel Lind 09 Jan '25

09 Jan '25

Hi all, This PR updates rubberband from v3 to v4; in the process the soversion is bumped from 2 to 3: https://src.fedoraproject.org/rpms/rubberband/pull-request/11#request_diff Per the upstream announcement the API should be backward compatible https://www.breakfastquay.com/news/20241025.html This is the one-week heads up notice per the update policy: https://docs.fedoraproject.org/en-US/fesco/Updates_Policy/#_rawhide I'll follow up later today or tomorrow with a COPR with dependent packages rebuilt to verify this; if you maintain one of the packages in the list, let me know if you prefer building the update yourself between now and next week. I'll do another update in a week announcing the side tag I'm using for this, and will rebuild all the packages where the maintainers have not opted out. Affected packages: $ fedrq whatrequires -P rubberband-devel ardour6-6.9.0-23.fc41.src ardour7-7.5.0-11.fc41.src ardour8-8.10.0-1.fc42.src denemo-2.6.0-15.fc42.src easyeffects-7.1.9-2.fc42.src ffmpeg-7.0.2-8.fc42.src mlt-7.28.0-4.fc42.src mpv-0.39.0-1.fc42.src mpv-devel-0.39.0-1.fc42.aarch64 muse-1:4.2.1-5.fc42.src qmplay2-24.06.16-3.fc42.src qtractor-1.2.0-1.fc42.src samplv1-0.9.91-2.fc41.src sonic-visualiser-5.0-2.fc42.src sooperlooper-1.7.3-24.fc40.src Best regards, -- _o) Michel Lind _( ) identities: https://keyoxide.org/5dce2e7e9c3b1cffd335c1d78b229d2f7ccc04f2

2 4

Time to retire GlusterFS in Fedora?
by Kaleb Keithley 09 Jan '25

09 Jan '25

HI, Development has effectively ended. For years Red Hat drove development for its RHGS product, but with the EOL of RHGS at the end of 2024 [1], and the disbanding of RHGS engineering at Red Hat, no development is being done. The last update (11.1) was on 6 Nov., 2023. Little or no, development is taking place in the greater Gluster community (such as it is), and no new updates appear to be forthcoming from any direction. Over in the CentOS world, the CentOS Storage SIG members have decided not to build GlusterFS RPMs for Stream 10. Therefore I intend to retire the GlusterFS package in Fedora 42, unless someone else would like to step in and take over as package owner. [1] https://access.redhat.com/support/policy/updates/rhs/ -- Kaleb

9 16

Plans for OCaml 5.2/5.3
by Richard W.M. Jones 09 Jan '25

09 Jan '25

Just a heads up for OCaml. We currently have OCaml 5.2.0 in Fedora 41 & Rawhide. OCaml 5.3.0 is expected to be released at the "end of November or beginning of December"[1], so it would make sense to move straight to this version in Rawhide after that happens. [1] https://ocaml.org/changelog/2024-10-31-ocaml-5.3.0.beta1 Release notes for 5.3.0: https://github.com/ocaml/ocaml/blob/5.3/Changes OCaml 5.2.1 is "a collection of safe but import[ant] runtime time bug fixes backported from the 5.3 branch of OCaml"[2]. It was released a couple of days ago. If I have the energy I'll update Fedora 41 to this version, but only after 5.3.0 is released first (as otherwise I'll need to do Rawhide twice to avoid the version in Rawhide being lower). [2] https://ocaml.org/changelog/2024-11-18-ocaml-5.2.1 Note that updating an OCaml version involves recompiling all the related packages, about 200 of them. Also there's a new version of LWT, so it makes sense to update that at the same time: https://bugzilla.redhat.com/show_bug.cgi?id=2326159 Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com Fedora Windows cross-compiler. Compile Windows programs, test, and build Windows installers. Over 100 libraries supported. http://fedoraproject.org/wiki/MinGW

2 3

F42 Change Proposal: Tcl/Tk 9.0 (system-wide)
by Aoife Moloney via devel-announce 07 Jan '25

07 Jan '25

Wiki - https://fedoraproject.org/wiki/Changes/TclTk9.0 Discussion Thread - https://discussion.fedoraproject.org/t/f42-change-proposal-tcl-tk-9-0-syste… This is a proposed Change for Fedora Linux. This document represents a proposed Change. As part of the Changes process, proposals are publicly announced in order to receive community feedback. This proposal will only be implemented if approved by the Fedora Engineering Steering Committee. == Summary == Tcl/Tk rebase to version 9. There are some major incompatibilities and it's unrealistic to port all depending packages, thus the compat Tcl/Tk 8 packages will be provided. == Owner == * Name: [[User:jskarvad| Jaroslav Škarvada]] * Email: jskarvad(a)redhat.com == Detailed Description == Some packages were already ported to Tcl/Tk 9, but some ports are complicated or there is nobody working/interested in the port at the moment thus it's unrealistic to port everything into f42. That's why the compat Tcl/Tk 8 packages will be provided and maintained till there will be packages requiring Tcl/Tk 8. This effort has been announced on the fedora-devel mailing list: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org… Example of the change in the packages SPEC: Original package, or package building with the Tcl/Tk 9: <pre> ... BuildRequires: tcl-devel BuildRequires: tk-devel ... </pre> Package switched to the compat Tcl/Tk: <pre> ... BuildRequires: tcl8-devel BuildRequires: tk8-devel ... </pre> The switch to the rebased Tcl/Tk and the packages built with the compat should happen atomically through the side-tag. == Feedback == There hasn't been any proposed alternative and no negative feedback yet. == Benefit to Fedora == There are several new features in the Tcl/Tk 9 (details in the [[#User_Experience]]). Fedora packages should follow the upstream latest releases. == Scope == * Proposal owners: ** rebase Tcl/Tk packages to version 9 (done in copr) ** get compat Tcl/Tk 8 packages into Fedora" *** tcl8: https://bugzilla.redhat.com/show_bug.cgi?id=2330615 *** tk8: https://bugzilla.redhat.com/show_bug.cgi?id=2330617 ** fill bugzillas for components not ported to Tcl/Tk 9 to switch to compat Tcl/Tk 8 * Other developers: ** Developers that will not port their packages to Tcl/Tk 9 will have to switch the BuildRequires: to compat Tcl/Tk 8 devel packages. This can be also done by proven packagers or the feature owner (proven packager) in case there will be no reaction to the created bugzillas. * Release engineering: [https://pagure.io/releng/issues #Releng issue number] ** There is probably no need to coordinate this with the Release engineering. * Trademark approval: N/A (not needed for this Change) * Alignment with the Fedora Strategy: == Upgrade/compatibility impact == It should seamlessly update. Packages ported to Tcl/Tk 9 will require Tcl/Tk 9 and unported packages will require compat Tcl/Tk 8. == Early Testing (Optional) == == How To Test == # Install Tcl/Tk depending packages, e.g. expect, gitk, ..., check the list of packages in the [[#Dependencies]] # Check functionality of the package. == User Experience == User experience should improve due to the new features supported by Tcl/Tk 9, e.g.: * 64-bit Capacity: Data values larger than 2Gb. * Unicode and Encodings: full codepoint range, added encodings, encoding profiles to govern I/O, and more. * Access to OS facilities: notifications, print, and tray systems. * Scalable Vector Graphics: partial support in images, extensive use to enable scalable widget and theme appearances. * Platform Features and Conventions: many improvements, including two-finger gesture support where available. Full list in: https://www.tcl-lang.org/software/tcltk/9.0.html == Dependencies == Some of the packages listed bellow only explictly require the Tcl interpreter and could work with the new Tcl package even without rebuild or compat version. Packages implicitly requiring the Tcl/Tk libraries (i.e. these that will 100 % require port/rebuild or compat version) are included in the Copr: https://copr.fedorainfracloud.org/coprs/jskarvad/TclTK9.0.0/ <pre> blt brazil brltty bwidget catdoc cgnslib classified-ads deal eggdrop emacspeak environment-modules eth-tools expect fmtools gcl gensio git git-cola gpsman graphviz gtkwave hamlib hfsutils hping3 html2ps iaxclient ifm insight irsim itcl itk iwidgets linsmith llvm-test-suite Lmod magic maxima med memchan mercurial mmtests mpqc nagelfar nbdkit ncid netgen-mesher ngspice ocaml-lablgl ocaml-labltk ocaml-ocamlnet ogdi opencascade openmsx owfs packmol pcb pgplot pidgin planets plplot postgresql15 postgresql16 pypy pypy3.10 pypy3.9 PySolFC python3.10 python3.11 python3.12 python3.13 python3.14 python3.6 python3.8 python3.9 R remind rrdtool R-tkrplot rubygem-tk snobol4 sqlite sqlite2 stk svxlink systemtap tcl-ezsmtp tcllib tcl-mysqltcl tcl-pgtcl tcl-signal tcl-snack tcl-tclreadline tcl-tcludp tcl-tclvfs tcl-tclxml tcl-thread tcl-tileqt tcl-tkpng tcl-tktreectrl tcltls tcl-togl tcl-trf tclx tcl-zlib tdom texlive-base tix tkabber tkdnd tkimg tklib tktray torque usb_modeswitch uudeview vim-syntastic vkeybd weechat wordnet xapian-bindings xbindkeys xcircuit xpa xschem x11vnc yaz yosys znc </pre> == Contingency Plan == * Contingency mechanism: Contingency mechanism shouldn't be needed. In the worst case, use of the compat packages should provide the same user experience as with the previous Fedora release. The hard and dirty way to rollback everything is to drop the compat packages, bump the epoch of the Tcl/Tk, revert it to the version 8 and bump and rebuilt depending packages. This can be done by the feature owner. * Contingency deadline: beta freeze * Blocks release? No == Documentation == https://www.tcl-lang.org/software/tcltk/9.0.html == Release Notes == -- Aoife Moloney Fedora Operations Architect Fedora Project Matrix: @amoloney:fedora.im IRC: amoloney -- _______________________________________________ devel-announce mailing list -- devel-announce(a)lists.fedoraproject.org To unsubscribe send an email to devel-announce-leave(a)lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel-announce@lists.fedorapr… Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue

3 2

Discussion on what to do with SvtAv1DecApp
by yoong jin 07 Jan '25

07 Jan '25

with the retirement of `SvtAv1DecApp` , and its libraries in the version bump of `svt-av1` from `2.1.0` to `2.3.0` , we should migrate applications from it. impact checks from running [copr builds](https://copr.fedorainfracloud.org/coprs/solomoncyj/svt/build/843658… from `fedrq wrsrc svt-av1 -F source show that no applications rely on the outdated libary. anyone wnating to to decode videos using the `av1` codec should use [da1vd](https://code.videolan.org/videolan/dav1d/) which has been used as the de facto standard for some time as a av1 software decoder

2 1

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

devel December 2024