Status of AVIF support in Fedora
by Sandro
Greetings everyone,
TL;DR
Will there be AVIF (AV1) support for applications using libheif in Fedora?
A while ago I stumbled upon AVIF files not being supported by
applications (gThumb, ImageMagick, GIMP) in Fedora [1].
It appears that the applications mentioned have switched to libheif for
AVIF support in favor of libavif. Since libheif also provides/requires
patent encumbered libraries/codecs (libde265) related to HEIF it is
provided by RPMFusion.
AVIF, however, is not encumbered by patents as I understand it [2]. So
it seems we need a compatibility libheif-av1 or the like to allow
applications provided by fedora repos to enable AVIF (AV1) support using
libheif [3].
I found two threads ([4],[5]) in the archives regarding HEIF and AVIF.
But none of them are conclusive with regards to enabling AVIF support.
Are there any plans to enable AVIF support in applications that use
libheif as their provider? If so, where can I find information regarding
the status?
I apologize in advance if any of the above is not entirely correct (or
entirely incorrect). Aim of my message is to better understand why
support for AVIF is lacking in some applications and if that can be fixed.
[1] https://bugzilla.redhat.com/show_bug.cgi?id=2165606
[2] https://bugzilla.redhat.com/show_bug.cgi?id=2164329#c3
[3] This part is not entirely clear to me. Please correct me.
[4]
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.o...
[5]
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.o...
Cheers,
Sandro
--
Sandro
FAS: gui1ty
IRC: Penguinpee
Elsewhere: [Pp]enguinpee
2 days, 15 hours
Heads up - squashfs-tools prelease in rawhide
by Bruno Wolff III
Phillip is really close to releasing 4.6 and I want to get some testing
in rawhide before that happens. If we do find a problem, it will be easier
on him if we find it before the release. I ran a test script that tests
the features we mostly use, so I'm not expecting any problems.
5 days, 11 hours
Fedora Linux 38 blocker status summary
by Ben Cotton
We've branched F38 from Rawhide, so it's time to start everyone's
favorite Friday email from Ben! The F38 Beta freeze begins on 21
February. The current target release date is the early target date
(2023-03-14).
Action summary
====================
Accepted blockers
-----------------
1–3. distribution — {Workstation,Everything,Server} boot x86_64 image
exceeds maximum size — ASSIGNED
ACTION: Relevant Teams to reduce image size or increase the limit
Proposed blockers
-----------------
1. anaconda — installer fails to boot in text mode or rescue mode with
systemd 253 — MODIFIED
ACTION: Maintainers to build an update that includes upstream PR
2. grub2 — ext4 filessystem support missing — NEW
ACTION: Maintainer to diagnose issue
NEEDINFO: ausil
3. kwin — kwin_wayland often crashed when used as the sddm Wayland
compositor and logging out of Plasma resulting in a black screen — NEW
ACTION: Maintainer to diagnose issue
4. mesa — KDE crashes on start with mesa-23.0.0~rc3-3.fc38 — ASSIGNED
ACTION: Maintainer to diagnose issue
Bug-by-bug detail
=============
Accepted blockers
-----------------
1–3. distribution — {Workstation,Everything,Server} boot x86_64 image
exceeds maximum size — ASSIGNED
https://bugzilla.redhat.com/show_bug.cgi?id=2149246
https://bugzilla.redhat.com/show_bug.cgi?id=2151495
https://bugzilla.redhat.com/show_bug.cgi?id=2151497
Image sizes exceed the specified limits. The choices are to either
shrink the image by removing packages or to riase the limits.
Proposed blockers
-----------------
1. anaconda — https://bugzilla.redhat.com/show_bug.cgi?id=2165433 — MODIFIED
installer fails to boot in text mode or rescue mode with systemd 253
anaconda is writing systemd units to an unexpected area. Upstream PR
4534 contains a candidate fix:
https://github.com/rhinstaller/anaconda/pull/4534
2. grub2 — https://bugzilla.redhat.com/show_bug.cgi?id=2166412 — NEW
ext4 filessystem support missing
Between grub2-2.06-76 and grub2-2.06-78, grub2 apparently lost the
ability to detect ext4 filesystems.
3. kwin — https://bugzilla.redhat.com/show_bug.cgi?id=2168034 — NEW
kwin_wayland often crashed when used as the sddm Wayland compositor
and logging out of Plasma resulting in a black screen
Logging out of Plasma sometimes triggers a kwin crash. This may be
limited to running in a virtual machine.
4. mesa — https://bugzilla.redhat.com/show_bug.cgi?id=2164667 — ASSIGNED
KDE crashes on start with mesa-23.0.0~rc3-3.fc38
A recent mesa update caused both GNOME and KDE to crash on start.
Update FEDORA-2023-40b973fa06 fixed GNOME, but KDE is still seeing
this issue. The root cause is still uncertain.
--
Ben Cotton
He / Him / His
Fedora Program Manager
Red Hat
TZ=America/Indiana/Indianapolis
5 days, 16 hours
F38 proposal: Noto CJK Variable Fonts (Self-Contained Change proposal)
by Ben Cotton
https://fedoraproject.org/wiki/Changes/Noto_CJK_Variable_Fonts
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 ==
Switch the default Noto CJK fonts for Chinese, Japanese and Korean
from static to variable fonts.
== Owner ==
* Name: [[User:pwu| Peng Wu]]
* Email: pwu(a)redhat.com
== Detailed Description ==
In order to reduce the font size in Noto CJK fonts, we plan to switch
to use the variable fonts by default.
# Split the google-noto-cjk-fonts package into
google-noto-sans-cjk-fonts and google-noto-serif-cjk-fonts, and
provide the variable fonts in google-noto-sans-cjk-vf-fonts and
google-noto-serif-cjk-vf-fonts.
# Drop several sub packages which are not installed by default from
the google-noto-cjk-fonts package.
## Like google-noto-sans-cjk-*-fonts, google-noto-sans-*-fonts,
google-noto-sans-mono-cjk-*-fonts, google-noto-serif-cjk-*-fonts and
google-noto-serif-*-fonts
# Install the Noto CJK Variable Fonts by default.
Fedora Copr for testing: https://copr.fedorainfracloud.org/coprs/pwu/noto-cjk/
== Feedback ==
== Benefit to Fedora ==
The variable fonts will reduce the disk space usage and live image
size compared to the static fonts.
{| class="wikitable"
|+ RPM Size
|-
! Size (bytes) !! Noto Sans CJK !! Noto Serif CJK
|-
| Static Fonts || 130674365 || 181621033
|-
| Variable Fonts || 64613100 || 56924710
|}
== Scope ==
* Proposal owners:
** Package four font packages for Noto CJK fonts
** Retire google-noto-cjk-fonts in Fedora rawhide
** Switch to install variable fonts by default in fedora-comps and langpacks
** Submit pull request to lorax templates to use
google-noto-sans-cjk-fonts in the boot.iso
* Other developers:
* Release engineering:
* Policies and guidelines: N/A (not needed for this Change)
* Trademark approval: N/A (not needed for this Change)
* Alignment with Objectives:
== Upgrade/compatibility impact ==
When upgrade, the variable fonts will be installed by default.
== How To Test ==
* Please upgrade to Fedora 38 or rawhide to get the latest fonts
* Install the variable fonts: google-noto-sans-cjk-vf-fonts and
google-noto-serif-cjk-vf-fonts
** Check the google-noto-sans-cjk-ttc-fonts and
google-noto-serif-cjk-ttc-fonts packages are replaced
* Then use CJK locales to check if the new fonts have any problem
== User Experience ==
This new variable fonts will reduce the disk space usage and live image size.
== Dependencies ==
== Contingency Plan ==
* Contingency mechanism: Use the static fonts by default -
google-noto-sans-cjk-fonts and google-noto-serif-cjk-fonts
* Contingency deadline: N/A
* Blocks release? N/A
== Documentation ==
N/A (not a System Wide Change)
== Release Notes ==
This new variable fonts will reduce the disk space usage and live image size.
--
Ben Cotton
He / Him / His
Fedora Program Manager
Red Hat
TZ=America/Indiana/Indianapolis
1 week, 1 day
Retiring Bottles in favor of Flatpak provided by upstream
by Sandro
Hi,
Development of Bottles is moving fast and we have been struggling to
keep up with upstream releases, especially since the introduction of
Rust components.
Upstream has approached the maintainers [1,2] and asked us to retire the
package in favor of the Flatpak packages provided by upstream.
I'm planning to move forward with retiring Bottles in the coming days. I
will add a comment in all open bug reports, letting users know they
should switch to the Flatpak release.
Bottles in F36 and F37 will not receive any further updates unless there
are security related issues surfacing.
[1] https://github.com/bottlesdevs/Bottles/issues/2345
[2] https://bugzilla.redhat.com/show_bug.cgi?id=2160007
Cheers,
Sandro
--
Sandro
FAS: gui1ty
IRC: Penguinpee
Elsewhere: [Pp]enguinpee
1 week, 1 day
can't install package pipewire-jack-audio-connection-kit
by Martin Gansser
Hi,
when trying to install pipewire-jack-audio-connection-kit i get this error message:
# dnf -y install pipewire-jack-audio-connection-kit
Last metadata expiration check: 1:39:52 ago on Thu Dec 31 14:10:39 2020.
Error:
Problem: problem with installed package jack-audio-connection-kit-1.9.14-5.fc33.x86_64
- package pipewire-jack-audio-connection-kit-0.3.13-4.fc33.i686 conflicts with jack-audio-connection-kit provided by jack-audio-connection-kit-1.9.14-5.fc33.x86_64
- conflicting requests
- package pipewire-jack-audio-connection-kit-0.3.15-2.fc33.i686 conflicts with jack-audio-connection-kit provided by jack-audio-connection-kit-1.9.14-5.fc33.x86_64
- package pipewire-jack-audio-connection-kit-0.3.13-4.fc33.x86_64 conflicts with jack-audio-connection-kit provided by jack-audio-connection-kit-1.9.14-5.fc33.x86_64
- package pipewire-jack-audio-connection-kit-0.3.15-2.fc33.x86_64 conflicts with jack-audio-connection-kit provided by jack-audio-connection-kit-1.9.14-5.fc33.x86_64
(try to add '--allowerasing' to command line to replace conflicting packages or '--skip-broken' to skip uninstallable packages)
How can i fix this ?
Regards
Martin
1 week, 3 days
Go leaves will be mass retired in one month
by Maxwell G
(Resending as it seems this didn't reach the ML the first time...)
Hi Fedorians,
Changes/Mass_Retire_Golang_Leaves [1] has been approved by FESCo. As
part of this Change, all Go library packages that are leaves will be be
mass retired and removed from the Fedora 39 repositories in
approximately one month.
The following maintainers/groups own co-maintain or watch at least one
package that we have identified as a leaf:
@deepinde-sig
@go-sig
@osbuild-sig
agerstmayr
anthr76
athoscr
atim
carlwgeorge
dcavalca
dctrud
eclipseo
fab
fale
fuller
gundersanne
jchaloup
jdoss
jjelen
laiot
logic
mayorga
mgoodwin
nathans
obudai
pwouters
qulogic
rga
rominf
yanqiyu
I will forward this message to those users separately instead of BCCing.
Apparently, some people have broken filters that hide any email sent to
the ML even if it's addressed to them directly.
See [2] for a full list of leaves and [3] for a maintainer by maintainer
breakdown. Maintainers may opt out by cloning
https://pagure.io/GoSIG/go-leaves/ and pushing an `opt-out/{PKGNAME}`
file with a short justification.
Something like:
```
git clone ssh://git@pagure.io/GoSIG/go-leaves.git
cd go-leaves
echo "Dependency for foo (review bug #XXXXX)" > ./opt-out/bar
git add ./opt-out/bar
git commit -m "opt out bar"
git push origin
```
All Go SIG members have write access to this repository. Other users can
submit a pull request. You're also welcome to file an issue and I'll
push the file for you.
After a month has passed, we'll remove Go SIG write access from the
repository and stop accepting additional opt-outs. Then, we'll preform
test builds in Copr to make sure there's no false positives in the list.
Finally, I'll verify the results, opt out any additional false
positives, and preform the mass retirement. As usual, anybody can
unretire packages without a re-review within eight weeks by filing a
releng ticket.
[1] https://fedoraproject.org/wiki/Changes/Mass_Retire_Golang_Leaves
[2] https://pagure.io/GoSIG/go-leaves/blob/main/f/leaves
[3] https://pagure.io/GoSIG/go-leaves/blob/main/f/leaves-by-maintainer
Thank you for your cooperation,
--
Maxwell G (@gotmax23)
Pronouns: He/They
1 week, 4 days
Planning to start unifying native and mingw packages
by Sandro Mani
Hi
Following recent discussions and to reduce the maintenance burden, I'm
planning to start merging native and mingw packages. Initially, I'll be
looking at these packages where I maintain both variants:
eigen3 mingw-eigen3
enchant2 mingw-enchant2
freeimage mingw-freeimage
gdal mingw-gdal
GeographicLib mingw-GeographicLib
geos mingw-geos
giflib mingw-giflib
gtkspell3 mingw-gtkspell3
gtkspellmm30 mingw-gtkspellmm30
jxrlib mingw-jxrlib
leptonica mingw-leptonica
libgeotiff mingw-libgeotiff
libimagequant mingw-libimagequant
libkml mingw-libkml
librttopo mingw-librttopo
libspatialite mingw-libspatialite
libwebp mingw-libwebp
openjpeg2 mingw-openjpeg2
OpenSceneGraph mingw-OpenSceneGraph
osgearth mingw-osgearth
podofo mingw-podofo
proj mingw-proj
python-pillow mingw-python-pillow
qtspell mingw-qtspell
shapelib mingw-shapelib
svg2svgt mingw-svg2svgt
tesseract mingw-tesseract
uriparser mingw-uriparser
I'm performing test builds here [1]. Once I've got them all building
there, if there are no objections, I plan to push to F37 and retire all
the corresponding mingw repos.
Sandro
[1] https://copr.fedorainfracloud.org/coprs/smani/mingw-unified-spec/builds/
1 week, 6 days
