Test upgrades from F37 to F38 - it will take you just a minute
by Miroslav Suchý
Do you want to make Fedora 38 better? Please spend 1 minute of your time and try to run:
# Run this only if you use default Fedora modules
# next time you run any DNF command default modules will be enabled again
sudo dnf module reset '*'
dnf --releasever=38 --setopt=module_platform_id=platform:f38 \
--enablerepo=updates-testing \
$(rpm -q fedora-repos-modular >/dev/null && echo --enablerepo=updates-testing-modular) \
--assumeno distro-sync
This command does not replace `dnf system-upgrade`, but it will reveals potential problems.
You may also run `dnf upgrade` before running this command.
The `--assumeno` will just test the transaction, but does not make the actual upgrade.
In case you hit dependency issues, please report it against the appropriate package.
Or against fedora-obsolete-packages if that package should be removed in Fedora 38. Please check existing reports against
fedora-obsolete-packages first:
https://red.ht/2kuBDPu
and also there is already bunch of "Fails to install" (F38FailsToInstall) reports:
https://bugzilla.redhat.com/show_bug.cgi?id=F38FailsToInstall
Thank you
Miroslav
1 year
[HEADS UP] util-linux based on new mount API coming to rawhide/f39
by Karel Zak
Hey all,
util-linux v2.39-rc1 coming to rawhide, Release Notes:
https://kernel.org/pub/linux/utils/util-linux/v2.39/v2.39-ReleaseNotes
I usually don't report util-linux Fedora updates, but this one is
special. This new version provides libmount with support for new
kernel mount API (syscalls fsconfig, fsmount, open_tree, etc.).
Some kernel parts may not be fully ported to the new API. Unfortunately,
the reliable way to detect possible issues is to test all less usual use
cases and mount options combinations in the real distribution.
For example, a well-known issue is btrfs when mixed with selinux mount
options. In this case, libmount falls back to the classic mount(2)
syscall. We need to gather all such cases.
If you see any unexpected behavior, please report it to
https://github.com/util-linux/util-linux/issues, the ideal report is
with libmount debug output (LIBMOUNT_DEBUG=all mount /foo ...).
Thanks!
Karel Zak
--
Karel Zak <kzak(a)redhat.com>
http://karelzak.blogspot.com
1 year
TeXLive 2023
by Tom Callaway
Hi Fedora,
TeXLive 2023 (composed of texlive-base and texlive SRPMs) is in rawhide
now. I've done local testing to try to make sure it doesn't break anything
obvious... but the size and scope of TL means that there are probably still
some bugs introduced by this update.
Change wiki page here: https://fedoraproject.org/wiki/Changes/TeXLive2023
Please let me know if something stops building as a result of the new
texlive packages, either via email, bugzilla, twitter, mastodon, or carrier
pigeon, with as much detail as you can provide.
There is at least one clear bug: texlive-texaccents (from texlive-base)
will not install at the moment, because it depends on snobol4. Snobol4 is
not in Fedora yet, I have made a new package which is pending review (and
it shouldn't be a hard review), so help with reviewing would be appreciated:
https://bugzilla.redhat.com/show_bug.cgi?id=2182080
Note that texlive-texaccents used to be Python, but upstream decided to
rewrite it in SNOBOL. The only thing (I think) that depends on texaccents
is texlive-collection-binextra.
I do not plan to push TeXLive 2023 to any stable Fedora, just let it get
inherited for Fedora 39+.
Also, this is the fastest I've ever turned around a TeXLive build (mostly
because I had just updated most things for 2022 in January).
~spot
1 year
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
1 year
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
1 year
HEADS UP: tesseract-5.3.0 landing in rawhide with soname bump
by Sandro Mani
Hi
I'll be landing tesseract 5.3.0 in rawhide, building it in the
f38-build-side-61405 side tag, along with the following dependent packages:
ffmpeg
gimagereader
mupdf
opencv
python-PyMuPDF
qpdfview
R-tesseract
zathura-pdf-mupdf
Thanks
Sandro
1 year
Fedpkg: Could not execute pre_push_check: Fail to upload files. Server
returns status 403
by Ondřej Mejzlík
Hi,
For the past week I have been having issues pushing changes into my own fork of a package.
Here is what I have done:
(All of this used to work fine about a week ago, my steps are always the same.)
Click the Fork button for example here: https://src.fedoraproject.org/rpms/ppp/tree/
fedpkg clone -a forks/omejzlik/rpms/ppp
cd ppp
git checkout -b fedora_testing
Make a change.
git add .
git commit -a -m 'Some comment'
git push --set-upstream origin fedora_testing
Could not execute pre_push_check: Fail to upload files. Server returns status 403
error: failed to push some refs to 'https://src.fedoraproject.org/forks/omejzlik/rpms/ppp.git'
The same error happens if I try to make a change in the main/rawhide branch and even when using fedpkg push.
The error used to be "Unauthorized access..." about 3 days ago, then changed to 403.
I have created and set new tokens for both:
[fedpkg.distgit]
apibaseurl = https://src.fedoraproject.org
token = XH...
[fedpkg.pagure]
url = https://pagure.io/
token = AK...
I have updated my SSH key in my FAS profile just in case it has anything to do with this.
And I tried logging into my fedora kerberos account.
Nothing helps.
I have several older packages forked from a week or earlier, pushing there throws a different error:
error: RPC failed; HTTP 502 curl 22 The requested URL returned error: 502
send-pack: unexpected disconnect while reading sideband packet
fatal: the remote end hung up unexpectedly
Any idea what the problem is?
Thanks.
1 year
%patchN deprecated?
by Michael J Gruber
Has `%patchN` been deprecated in favour of `%patch N`?
I got a push by a proven packager to one of the packages which I maintain, commit subject and changelog entry "Fix deprecated patch rpm macro". It contains no explanation and no reference whatsoever. I didn't find any heads up notice, nor info in the packaging guidelines, but I didn't try too hard - because it's not my job.
I mean: One person is doing that push. Is it too much to ask to get at least the slightest bit of reference or communication before or into a push which probably affects hundreds of people? If not out of courtesy then out of mere common sense of efficiency?
On the technical side, I'd be interested why this is better (fewer macros?) and which releases can take it, and what are the recommendations for `PatchN:`-lines (with or without N), and why (or whether) the recommendation isn't to go for `%autosetup` or `%autopatch` - maybe all answered in the missing reference.
P.S.: There is nothing to "fix" here either, only to "adapt" to the deprecation notice, but I'll take that one easy between non-native speakers, presumably.
1 year
