F38 proposal: Minizip renaming (Self-Contained Change proposal)
by Ben Cotton
https://fedoraproject.org/wiki/Changes/MinizipRenaming
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 ==
Renaming the "minizip" package to "minizip-ng" and renaming the
"minizip-compat" zlib subpackage to "minizip" to align with the
upstream naming.
== Owner ==
* Name: [[User:ljavorsk| Lukas Javorsky]]
* Email: ljavorsk(a)redhat.com
== Detailed Description ==
Upstream has changed the naming of the "minizip" package to
"minizip-ng" and we should follow their naming so there is no
confusion about which package is the right one. Upstream has also
requested to rename the "minizip-compat" zlib subpackage to "minizip"
which is the right naming for the package.
The "minizip" and "minizip-compat" provides different shared libraries
which prevent us from conflicting sonames.
The plan behind this change can be put into x steps which will be
completed separately and in the given order:
''NOTE: All of the Provides and Obsoletes will be added to the *-devel
subpackages as well.''
1) Create a new package "minizip-ng" which will `Provides: minizip =
%{sameevr}` and `Obsoletes: (minizip < 3.0.2-7 and minizip > 3.0.0-1)`
''NOTE: The versions I choose here are the safe versions that create a
space for possible "minizip-compat" rebases''
2) Rebuild all of the packages that BuildRequire/Require "minizip"
package to BuildRequire/Require new "minizip-ng" package
3) Retire the "minizip" package following the
[https://docs.fedoraproject.org/en-US/package-maintainers/Package_Retireme...
Package Retirement Process]
4) Wait for the Fedora 40 when it's ensured that every user has
updated at least to the Fedora 38. Remove the `Provides` and
`Obsoletes` from the "minizip-ng" package
5) Rename the "minizip-compat" to the "minizip" package and add
`Provides: minizip-compat = %{sameevr}` and `Obsoletes: minizip-compat
< 1.2.12`
== Feedback ==
Early feedback from the community is possite, the feedback is located
in this [https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.o...
Email thread]
== Benefit to Fedora ==
Fedora should always respect upstream package naming, so the users are
not confused about which package are they installing. This naming
change will align the naming with the upstream.
== Scope ==
* Proposal owners: New package "minizip-ng" will be created, and
several changes in "minizip-compat" package which are described in the
Detailed Description.
* Other developers: Change the names of their BuildRequires/Requires
accordingly.
* Release engineering: No action required
* 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 following the plan in Detailed Description there will be no need
for manual action. Everything will be handled by the automated dnf
upgrade.
== How To Test ==
== User Experience ==
== Dependencies ==
List of the packages from Fedora 37
=== minizip ===
repoquery --whatrequires "*libminizip.so.3*" | pkgname | uniq
R-libSBML
collada-dom
dolphin-emu
dolphin-emu-tool
java-libsbml
keepassxc
libnuml
librasterlite2
libsbml
libspatialite
libxlsxwriter
minizip-devel
perl-LibSBML
python3-libsbml
ruby-SBML
sigil
vxl
xiphos
zfstream
=== minizip-compat ===
repoquery --whatrequires "*libminizip.so.1*" | pkgname | uniq
chromedriver
chromium
chromium-headless
domoticz
hashcat
libdigidocpp
minizip-compat-devel
springlobby
== Contingency Plan ==
* Contingency mechanism: Remove the builds created and revert shipped
changes. Done by any Fedora packager (preferred by the one who knows
about this change)
* Contingency deadline: Beta freeze
* Blocks release? No
''NOTE: If we don't finish this change to the deadline, it is possible
to just complete this change with the next release.''
== Documentation ==
[https://github.com/zlib-ng/minizip-ng/issues/358 Upstream issue]
[https://bugzilla.redhat.com/show_bug.cgi?id=2037245 Bugzilla tracker]
--
Ben Cotton
He / Him / His
Fedora Program Manager
Red Hat
TZ=America/Indiana/Indianapolis
1 year, 8 months
Bump f38 .so for libid3tag
by Leigh Scott
Switching upstream has increased the .so version from libid3tag.so.0 to libid3tag.so.0.16.2
I plan to do the rebuilds myself after checking everything builds ok in copr.
Affected packages
Fedora:
audacity-0:3.1.3-5.fc37.x86_64
easytag-0:2.4.3-16.fc37.x86_64
gtkpod-0:2.1.5-21.fc37.x86_64
imlib2-id3tag-loader-0:1.7.4-3.fc37.x86_64
mp3fs-0:1.1.1-4.fc37.x86_64
sonic-visualiser-0:4.5-2.fc37.x86_64
sox-0:14.4.2.0-33.fc37.x86_64
Rpmfusion:
audacity-freeworld-0:3.1.3-4.fc37.x86_64
libmp3splt-0:0.9.2-13.fc37.x86_64
minidlna-0:1.3.0-8.fc37.x86_64
mixxx-0:2.3.3-2.fc37.x86_64
moc-0:2.6-0.46.svn3005.fc37.x86_64
mpd-1:0.23.9-1.fc37.x86_64
vdr-mp3-0:0.10.4-6.fc37.x86_64
1 year, 8 months
Users with commit rights in src.fp.o but no more in packager group
by Mattia Verga
Following my comment in
https://pagure.io/fesco/issue/2856#comment-812870 I wrote a simple
script to check how many users have commit rights onto some project in
src.fp.o, but aren't (anymore) members of the `packager` group:
```
Found 31 users with commit privileges but not in packager group:
packaging-team
stefanok
mmcgrath
kernel-maint
oddshocks
systemd-maint
lvm-team
abrt-team
i18n-team
amahdal
jvlomax
coremodule
libvirt-maint
sonkun
fonts-sig
narasim
perl-sig
dcr226
gecko-maint
ozamosi
sheltren
anaconda-maint
java-sig
duriantang
dracut-maint
ipa-maint
kmod-maint
mariobl
mck182
design-sw
cdeccio
```
With the exclusion of *-team, *-sig and *-maint, I think packaging
rights should be removed from those users.
Also, as per my comment linked above, I think there should be some check
to prevent users removed from packager group to maintain commit rights.
No idea where/how to implement that.
Mattia
1 year, 8 months
F37 side tag after branching point
by Iñaki Ucar
Hi all,
We have a new R version sitting on a side tag (f37-build-side-55653)
for a few weeks now, where packages are being rebuilt as time permits.
Unfortunately, F37 is not rawhide anymore, so the question is whether
this side tag could be safely merged both in F37 and rawhide when it
is ready.
Thanks,
--
Iñaki Úcar
1 year, 9 months
Heads-up / for discussion: dnf not working with 1G of RAM or less
by Adam Williamson
Hey folks! I apologize for the wide distribution, but this seemed like
a bug it'd be appropriate to get a wide range of input on.
There's a bug that was proposed as an F37 Beta blocker:
https://bugzilla.redhat.com/show_bug.cgi?id=1907030
it's quite an old bug, but up until recently, the summary was
apparently accurate - dnf would run out of memory with 512M of RAM, but
was OK with 1G. However, as of quite recently, on F36 at least (not
sure if anyone's explicitly tested F37), dnf operations are commonly
failing on VMs/containers with 1G of RAM due to running out of RAM and
getting OOM-killed.
There's some discussion in the bug about what might be causing this and
potential ways to resolve it, and please do dig into/contribute to that
if you can, but the other question here I guess is: how much do we care
about this? How bad is it that you can't reliably run dnf operations on
top of a minimal Fedora environment with 1G of RAM?
This obviously has some overlap with our stated hardware requirements,
so here they are for the record:
https://docs.fedoraproject.org/en-US/fedora/latest/release-notes/welcome/...
that specifies 2GB as the minimum memory for "the default
installation", by which I think it's referring to a default Workstation
install, though this should be clarified. But then there's a "Low
memory installations" boxout, which suggests that "users with less than
768MB of system memory may have better results performing a minimal
install and adding to it afterward", which kinda is recommending that
people do exactly the thing that doesn't work (do a minimal install
then use dnf on it), and implying it'll work.
After some consideration I don't think it makes sense to take this bug
as an F37 blocker, since it already affects F36, and that's what I'll
be suggesting at the next blocker review meeting. However, it does seem
a perfect candidate for prioritized bug status, and I've nominated it
for that.
I guess if folks can chime in with thoughts here and/or in the bug
report, maybe a consensus will emerge on just how big of an issue this
is (and how likely it is to get fixed). There will presumably be a
FESCo ticket related to prioritized bug status too.
Thanks folks!
--
Adam Williamson
Fedora QA
IRC: adamw | Twitter: adamw_ha
https://www.happyassassin.net
1 year, 9 months
F37 Beta blocker status email
by Ben Cotton
With F37 now branched from Rawhide, it's time to pick up our weekly
blocker status emails!
Action summary
====================
Accepted blockers
-----------------
1. kde-settings — KDE needs to pick up F37 backgrounds — NEW
ACTION: Maintainers to make new kde-settings build
Proposed blockers
-----------------
1. anaconda — Anaconda crashed on signal 11 - keyboard layout
encryption password prompt — ON_QA
ACTION: QA, reporter to verify anaconda-37.12-1
NEEDINFO: doug.hs
2. anaconda — Anaconda will not start F37 Raw — NEW
ACTION: Reporter to provide requested log files
NEEDINFO: aalmeleh.whatever.0101
3. dnf — "dnf update" runs out of memory on swapless 0.5 GiB RAM machine — NEW
ACTION: Manitainers to investigate short-term dnf improvements
NEEDINFO: jmracek
4. dracut — Media check fails with checkisomd5 "service failed because
the control process exited with error code" — POST
ACTION: Maintainers to build with upstream PR
5. polkit — Switching users in Gnome results in polkitd errors that
prevent powering off the computer. — ASSIGNED
ACTION: Maintainers to diagnose issue
6. sddm — Logout from KDE session on Rawhide goes to console, not SDDM — NEW
ACTION: Maintainers to diagnose issue
Bug-by-bug detail
=============
Accepted blockers
-----------------
1. kde-settings — https://bugzilla.redhat.com/show_bug.cgi?id=2117706 — NEW
KDE needs to pick up F37 backgrounds
New desktop backgrounds require a new KDE settings update.
Proposed blockers
-----------------
1. anaconda — https://bugzilla.redhat.com/show_bug.cgi?id=2070823 — ON_QA
Anaconda crashed on signal 11 - keyboard layout encryption password prompt
Clicking the keyboard layout button in the LUKS decryption popup
crashes anaconda. anaconda-37.12-1 contains a candidate fix.
2. anaconda — https://bugzilla.redhat.com/show_bug.cgi?id=2101229 — NEW
Anaconda will not start F37 Raw
Neither clicking the desktop icon nor the taskbar icon will launch
anaconda. openQA is not experiencing this. Using basic graphics mode
results in the expected behavior.
3. dnf — https://bugzilla.redhat.com/show_bug.cgi?id=1907030 — NEW
"dnf update" runs out of memory on swapless 0.5 GiB RAM machine
dnf is killed by oom-kill on machines with 512 MB of RAM. Adding a
swap disk or disabling the updates repo works around this issue.
Recently, FCOS has seen this behavior with 1 GB VMs. The issue appears
to be the size of the metadata for the repository. The short term
fixes look like they may need to be made on the repo side, not in dnf.
4. dracut — https://bugzilla.redhat.com/show_bug.cgi?id=2107858 — POST
Media check fails with checkisomd5 "service failed because the control
process exited with error code"
Media check fails on certain hardware. Skipping the media check
results in a successful boot. Upstream PR #1882 contains a candidate
fix: https://github.com/dracutdevs/dracut/pull/1882
5. polkit — https://bugzilla.redhat.com/show_bug.cgi?id=2109145 — ASSIGNED
Switching users in Gnome results in polkitd errors that prevent
powering off the computer.
Under certain conditions (including but not limited to several user
switches), the power off button disappears from the GNOME menu due to
a polkitd error. `systemctl poweroff -i` as an unprivileged user does
not work. It may be an issue with using the duktape JS engine instead
of mozjs91. polkit-121-3 reverts to mozjs91, but is not a sufficient
fix.
6. sddm — https://bugzilla.redhat.com/show_bug.cgi?id=2110801 — NEW
Logout from KDE session on Rawhide goes to console, not SDDM
After logging out of KDE Plasma, you end up at a console on tty2. SDDM
had been running on tty1 but just shows a flashing cursor.
--
Ben Cotton
He / Him / His
Fedora Program Manager
Red Hat
TZ=America/Indiana/Indianapolis
1 year, 9 months
Let's enable Koschei for all packages automatically
by Miro Hrončok
Hello folks,
during our Nest FESCo session, we've talked about enabling Koschei [1] for all
packages automatically.
There seem to be a consensus by FESCo members, that it would be a good thing.
What would it take?
1) Koji resources
I think we can try to enable this and see if it burns. I think ti won't.
2) One-time enablement of all existing packages
That should be doable. Right?
3) Automatic enablement of all new packages
That should be just a matter of changing the defaults. Correct?
Can we do this? How can I help?
[1] https://fedoraproject.org/wiki/Koschei
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
1 year, 9 months
Request for testing: Fedora 37 pre-Beta validation tests
by Adam Williamson
Hey folks!
So we're in freeze for Fedora 37 Beta now, and the first go/no-go
meeting should be on September 8.
It would be really great if we can get the validation tests run now so
we can find any remaining blocker bugs in good time to get them fixed.
Right now the blocker list looks short, but there are definitely some
tests that have not been run.
You can use the testcase_stats view to find tests that need running:
https://openqa.fedoraproject.org/testcase_stats/37/
For each validation test set (Base, Desktop etc.) it shows when each
test was last performed. So you can easily look for Basic and Beta
tests that have not yet been run. We need to run all of these.
You can enter results using `relval report-results`, or edit the
summary results page at
https://fedoraproject.org/wiki/Test_Results:Current_Summary . That's a
redirect link which will always point to the validation results page
for the currently-nominated compose, which right now is 20220826.n.0.
Sumantro will be running a validation 'test week' starting on
Wednesday, so you can drop by the Fedora Test Day room on
chat.fedoraproject.org to hang out with other testers and get any help
you need in testing. See
https://lists.fedoraproject.org/archives/list/test-announce@lists.fedorap...
for that announcement.
Thanks folks!
--
Adam Williamson
Fedora QA
IRC: adamw | Twitter: adamw_ha
https://www.happyassassin.net
1 year, 9 months
