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, 7 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, 7 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, 7 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, 7 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, 7 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, 7 months
SLF4J 2.0.0 update in Fedora Rawhide
by Mikolaj Izdebski
Hello,
In September package slf4j in Fedora Rawhide will be updated to a new
major version 2.0.0. This update contains API and ABI breaks,
therefore I am announcing it in advance. More details follow.
SLF4J is a popular Java logging framework. A new major version 2.0.0
has been recently released. For summary of changes see upstream
changelog: https://www.slf4j.org/news.html
Notably some functionality has been removed without replacement and
some classes have been renamed. Code changes may be required to port
code to the new version of SLF4J.
Currently Fedora Rawhide ships version 1.7.32 of SLF4J, but I am
preparing to push the new version 2.0.0.
A proof of concept code is available as pull request:
https://src.fedoraproject.org/rpms/slf4j/pull-request/10
In the PR above you can also find a Koji scratch build of the new
version, that can be used for testing dependent packages.
ETA for submitting Bodhi update to stable is mid September 2022.
Please contact me on the list or on IRC on #fedora-java if you want to
cooperate on building and pushing related updates together.
A compat package slf4j1 may be created if it turns out that porting
multiple packages at the same time is infeasible. A rebuild of
dependent packages with trivial changes (such as updating
BuildRequires) may still be needed to start using the compat package.
Packages that are known to require or build-require slf4j and
therefore are possibly affected by the update:
antlr3
antlr4-project
apache-sshd
aqute-bnd
dogtag-pki
freemarker
hdf
hdf5
java-dirq
jboss-logging
jericho-html
jetty
jgit
jss
ldapjdk
log4j
mariadb-java-client
maven
maven-artifact-transfer
maven-plugin-bundle
maven-resolver
maven-script-interpreter
maven-shade-plugin
maven-wagon
mysql-connector-java
openas2
plexus-resources
pomchecker
resteasy
sisu
sisu-mojos
slf4j
tomcatjss
xbean
xmvn
xmvn-connector-ivy
Maintainers of affected packages are BCC-ed.
--
Mikolaj Izdebski
1 year, 7 months
