Unannounced soname bump: ldns
by Adam Williamson
A new build of ldns was done for Rawhide yesterday by law/pemensik:
https://koji.fedoraproject.org/koji/buildinfo?buildID=1660180
This build changes the soname of libreport from libldns.so.2 to
libldns.so.3.
This bump was not announced AFAICS, and none of its several
dependencies appear to have been rebuilt:
dnsperf-0:2.4.0-2.fc34.x86_64
dnssec-trigger-0:0.17-1.fc34.x86_64
flamethrower-0:0.11.0-1.fc34.x86_64
ldns-devel-0:1.7.0-32.fc33.x86_64
ldns-utils-0:1.7.0-32.fc33.x86_64
libreswan-0:4.1-3.fc34.x86_64
netresolve-backends-aresdns-0:0.0.1-0.28.20160317git.fc33.x86_64
netresolve-backends-avahi-0:0.0.1-0.28.20160317git.fc33.x86_64
netresolve-backends-compat-0:0.0.1-0.28.20160317git.fc33.x86_64
netresolve-backends-ubdns-0:0.0.1-0.28.20160317git.fc33.x86_64
netresolve-compat-0:0.0.1-0.28.20160317git.fc33.x86_64
netresolve-core-0:0.0.1-0.28.20160317git.fc33.x86_64
netresolve-tools-0:0.0.1-0.28.20160317git.fc33.x86_64
nordugrid-arc-plugins-needed-0:6.9.0-1.fc34.x86_64
opendnssec-0:2.1.7-1.fc34.x86_64
python3-ldns-0:1.7.0-32.fc33.x86_64
This broke today's Rawhide compose due to a KDE dependency chain that
involves libreswan:
https://koji.fedoraproject.org/koji/taskinfo?taskID=57780927
Please remember to announce soname bumps ahead of time and arrange
rebuilds of dependencies so this kind of problem can be avoided.
Thanks. I will try and rebuild things, at least compose-critical
things, now, but if straight rebuilds don't work might need people to
help out.
--
Adam Williamson
Fedora QA
IRC: adamw | Twitter: adamw_ha
https://www.happyassassin.net
3 years, 3 months
Stale proven packagers
by Adam Williamson
A propos of some discussion of the Solarwinds news, it occurred to me
to check how many proven packager accounts there are in FAS. There are
251, which seems like a lot. Then it occurred to me to check how many
of them are inactive, so I wrote a little script:
===
#!/usr/bin/python3
import getpass
from fedora.client.fas2 import AccountSystem
from koji import ClientSession
username = input("FAS user name: ")
password = getpass.getpass("FAS password: ")
acc = AccountSystem(username=username, password=password)
pps = acc.group_members("provenpackager")
ks = ClientSession("https://koji.fedoraproject.org/kojihub")
for pp in pps:
user = ks.getUser(pp["username"])
if not user:
print(f"{pp['username']} NON-EXISTENT IN KOJI")
continue
uid = user["id"]
if ks.listBuilds(userID=uid, createdAfter="2019-01-01 00:00:00"):
continue
print(pp["username"])
===
Here is the list it produced:
alexl
alexlan
arg
athimm
atkac
bernie
bkabrda
bpepple
caillon
cebbert
chitlesh
cweyl
cwickert
davej
dbhole
dcbw
denis
dgregor
dsd
ecik
ensc
epienbro
fitzsim
gdk NON-EXISTENT IN KOJI
gemi
ianweller
iarnell
ilianaw
ishcherb
ivazquez
ixs
jcapik
jkeating
johnp
jpo
jreznik
jspaleta
jstanley
jsteffan
jwilson
kasal
katzj
kay
ke4qqq
kengert
kyle
kylev
laxathom
lennart
lmacken
lutter
markmc
mbarnes
mef
mjakubicek
mjg59
mmahut
mmaslano
mmcgrath
msrb
mstuchli
npmccallum
overholt
paragn
patches
pertusus
pjp
praveenp
pravins
rakesh
rkuska
rvokal
s4504kr
scop
sdake
sdz
skvidal
stahnma
steve
sundaram
thomasvs
toshio
tradej
tremble
tstclair
tuxbrewr
vakwetu
vicodan
willb
wolfy
that's 90 of the 251 who still have provenpackager privileges, but
haven't run any kind of Koji build since at least 2019-01-01 (if you
check, it turns out many of them haven't run a build since long before
then). Many of them, to my knowledge, don't work on Fedora at all any
more and haven't for years. At least one of them, to my and everyone
else's knowledge, is sadly dead and has been for some time. One account
- it's Greg Dekoenigsberg - somehow is in the FAS pp group but doesn't
exist in koji (any more?)
Perhaps we need a process for cleaning up membership of this extremely
powerful group? If the FAS password of *any one* of those user accounts
were somehow compromised (or if just one of them decided they had a
grudge against Fedora now and were going to have some fun), the results
could be...unfortunate.
--
Adam Williamson
Fedora QA
IRC: adamw | Twitter: adamw_ha
https://www.happyassassin.net
3 years, 3 months
Syngrafias - AsciiDocs Collaboration Tool for Fedora Documentation
Maintainers, Available for testing
by Nasir Hussain
Hi,
We'd like to announce the public testing of Syngrafias, an Asciidoctor
collaboration tool - a service for Fedora documentation maintainers aiming
to
provide an environment where they can collaborate by sharing their workspace
among multiple contributors with active synchronization of edits at every
end
and live preview of the Asciidoctor files.
The preview version for public testing is now available here:
http://35.231.107.163/
Please note that as it has been deployed on a low-tier Google Cloud
instance,
the first load might take a while.
Syngrafias leverages WebSockets backend to significantly improve upon the
collaboration experience among multiple documentation writers and ensures an
ultralight implementation of the workspace server. (~2MB above Python
runtime)
It also includes the following features -
- Live Asciidoc editing and preview
- Workspace identity can be shared among multiple people to collaborate in
real time
- Documents can be exported locally and imported in different workspaces
- Unintrusive and focussed editing with cells inside a document
We would love to hear your feedback. Please keep in mind that this is a
testing
deployment and is currently running on an underpowered cloud instance. We
are
proposing it as a candidate GSoC project for it to be deployed, maintained
and
integrated in the Fedora Infrastructure this summer. Also the deployment
goes
offline on 8th January so be sure to check it out soon.
Feel free to provide ideas or bug reports at
https://github.com/t0xic0der/syngrafias or simply send an email reply to
this
thread with all kinds of feedback and suggestions.
---
Nasir Hussain
3 years, 3 months
Reducing noise on devel list
by Dennis Gilmore
Hi all,
I filed https://pagure.io/fesco/issue/2512 asking FESCo to move all
automated emails to a separate list where people who want to follow
can, while I was part of the proliferation of compose reports coming
here, there is now a great deal of them, and they no longer seem to
trigger any conversation. I think that devel list would benefit from
having all automated reports sent to a reports-list and letting people
bring reports over when there is something to discuss. I was asked to
bring the request to the list for people to weigh in.
Thanks
Dennis
3 years, 3 months
HEADS UP: OpenEXR + ilmbase = (new) openexr
by Richard Shaw
OpenEXR and ilmbase are several releases behind in Fedora and the main
reason is that they combined OpenEXR & ilmbase and changed build systems to
CMake.
In digging into this, it makes sense. OpenEXR doesn't even provide a
library named OpenEXR, instead:
$ dnf repoquery --provides OpenEXR-libs
...
libIlmImf-2_3.so.24
libIlmImf-2_3.so.24()(64bit)
libIlmImfUtil-2_3.so.24
libIlmImfUtil-2_3.so.24()(64bit)
And strangely ilmbase provides mostly libraries that don't contain ilm!
$ dnf repoquery --provides ilmbase
...
libHalf.so.24
libHalf.so.24()(64bit)
libIex-2_3.so.24
libIex-2_3.so.24()(64bit)
libIexMath-2_3.so.24
libIexMath-2_3.so.24()(64bit)
libIlmThread-2_3.so.24
libIlmThread-2_3.so.24()(64bit)
libImath-2_3.so.24
libImath-2_3.so.24()(64bit)
And ALL of the headers for both packages get installed into
/usr/include/OpenEXR!
So here's my plan:
1. Repackage openexr from scratch including review request (Rex?)
1a. Include appropriate Provides/Obsoletes for current OpenEXR and ilmbase
packages
2. Perform all testing and dependent rebuilds in a COPR first.
3. Build openexr and dependencies in a side-tag
4. Merge the side tag and retire OpenEXR and ilmbase
So what am I forgetting? Thoughts?
Thanks,
Richard
3 years, 3 months
Fedora 34 Change: Enable systemd-oomd by default for all variants
(System-Wide Change)
by Ben Cotton
https://fedoraproject.org/wiki/Changes/EnableSystemdOomd
== Summary ==
Provide a better experience for Fedora users in out-of-memory (OOM)
situations by enabling
[https://www.freedesktop.org/software/systemd/man/systemd-oomd.html
systemd-oomd] by default. Actions taken by systemd-oomd operate on a
per-cgroup level, aligning well with the life cycle of systemd units.
systemd-oomd primarily uses [https://facebookmicrosites.github.io/psi/
Linux pressure stall information (PSI)] to make decisions based on
wasted productivity due to resource shortages; in addition to that, it
also supports swap based actions.
== Owners ==
* Name: [[User:anitazha|Anita Zhang]], [[User:Dcavalca|Davide
Cavalca]], [[User:Salimma|Michel Salim]], [[User:Htejun|Tejun Heo]],
[[User:3ki|Rik van Riel]]
* Email: the.anitazha(a)gmail.com, dcavalca(a)fb.com,
michel(a)michel-slm.name, htejun(a)fb.com, riel(a)fb.com
== Detailed description ==
The primary mechanism used by systemd-oomd for detecting when the
system is out of memory is memory pressure. Memory pressure measures
the percentage of time a cgroup has “wasted” due to lack of memory.
This includes time spent reclaiming free memory, faulting in recently
resident pages, and loading in anonymous pages from swap. When a
monitored cgroup’s memory pressure exceeds the specified thresholds,
systemd-oomd will perform action(s) on the targeted cgroup’s
descendants, starting from the cgroups with the most reclaim scans.
Reclaim activity is used here, rather than the largest consumer, as it
reflects values set in the cgroup memory controller for memory
protection (such as memory.low).
For memory pressure configuration, this will be
ManagedOOMMemoryPressure=kill and ManagedOOMMemoryPressureLimit=4% on
user@.service to have systemd-oomd send SIGKILLs to all processes
under a selected cgroup when total memory pressure on all tasks
exceeds 4% for 10 seconds.
For swap based actions, systemd-oomd will monitor the system-wide swap
space and act when available swap falls below the configured
threshold, starting with the cgroups with the highest swap usage to
the least. Keeping some amount of swap (if enabled) available will
prevent the kernel OOM killer from killing processes unpredictably and
spending an unbounded amount of time afterwards.
For swap configuration, this will be SwapUsedLimitPercent=90% in
oomd.conf and ManagedOOMSwap=kill on -.slice (root cgroup slice) to
have systemd-oomd send SIGKILLs to all processes under a cgroup when
swap used exceeds 90%.
== Benefit to Fedora ==
* Addressing the issue of improving user feedback in
https://pagure.io/fedora-workstation/issue/202, systemd-oomd currently
logs to the journal if pressure or swap action is about to occur.
There are also debug logs, for each process that is sent a SIGKILL,
that can be bumped up in priority. Further notification mechanisms
(i.e. over dbus) can also be implemented depending on feedback.
* While systemd-oomd is simpler in configuration to the oomd used at
Facebook, the algorithm is largely the same. As such, the following
case study can be used as an example of how PSI and cgroup killing can
release memory not normally resolved with process killing and lead to
better utilization:
https://facebookincubator.github.io/oomd/docs/oomd-casestudy.html
* OOM killing in userspace, before the kernel OOM killer kicks in, has
been shown to be effective at keeping a system functional. An OOM kill
in the kernel is slow, possibly leading to an unbounded amount of time
swapping in and out pages and evicting the page cache.
* PSI based actions, versus looking at raw memory consumption numbers,
better reflect memory protection policies set for cgroup resource
control limits (e.g. memory.low).
== Scope ==
* Proposal owners:
** Implement and land additional refinements to systemd-oomd
*** Remove swap as a hard requirement to running systemd-oomd
*** Expand ManagedOOM*= properties to user units (currently only
usable on system units)
*** Configurable memory pressure time window knob
** Enable oomd by default with sensible configuration
** Test days
** Aid with documentation
* Other developers:
** systemd: review PRs as needed
* Release engineering: https://pagure.io/releng/issue/9913
* Policies and guidelines: N/A
* Trademark approval: N/A
== Upgrade/compatibility impact ==
Existing systems running earlyoom will not be modified. One can
transition to systemd-oomd via:
<pre>sudo systemctl disable --now earlyoom
sudo systemctl enable --now systemd-oomd</pre>
Systems that were previously not running earlyoom will have
systemd-oomd enabled by default.
== How to test ==
systemd 247 build for Fedora includes all the artifacts for
systemd-oomd. It is disabled by default but can be started with:
<pre>sudo systemctl enable --now systemd-oomd</pre>
At this point you can decide which units to set properties on. For
example, to enable swap-based killing on all units below the root
slice:
<pre>sudo systemctl edit --force -- -.slice
[Slice]
ManagedOOMSwap=kill
# save and exit</pre>
Note that the following memory pressure example requires the changes
listed in “Scope” to work as expected, as systemd-oomd shipped with
systemd v247 does not support changing the time window for memory
pressure. This example was run on a system with swap:
<pre>systemctl edit user@.service
[Service]
ManagedOOMMemoryPressure=kill
ManagedOOMMemoryPressureLimit=4%
# save and exit
systemd-run --user tail /dev/zero # will lead to a lot of reclaim and
then OOM if not killed</pre>
== User experience ==
This should be a fully transparent change for users.
== Dependencies ==
None. If changes to oomd are required to address feedback to this
proposal, they will need to be merged in systemd.
== Contingency plan ==
* Contingency mechanism: For workstation, owner will revert all
changes and we’ll go back to using earlyoom instead
* Contingency deadline: Final freeze
* Blocks release? No
* Blocks product? No
== Documentation ==
https://www.freedesktop.org/software/systemd/man/systemd-oomd.html<br />
https://www.freedesktop.org/software/systemd/man/oomctl.html<br />
https://www.freedesktop.org/software/systemd/man/oomd.conf.html
== Release Notes ==
systemd-oomd is enabled by default. Depending on which systemd units
have ManagedOOMSwap=kill or ManagedOOMMemoryPressure=kill,
systemd-oomd will SIGKILL all the processes under the appropriate
descendant cgroups when the configured limits are exceeded.
To revert back to earlyoom, run:
<pre>sudo systemctl disable --now systemd-oomd
sudo systemctl enable --now earlyoom</pre>
See man oomd.conf for configuration options.
--
Ben Cotton
He / Him / His
Senior Program Manager, Fedora & CentOS Stream
Red Hat
TZ=America/Indiana/Indianapolis
3 years, 3 months
HEADS UP: libgit 1.1.0 update with SONAME bump (in Rawhide)
by Igor Raits
All packages were rebuilt successfully except julia. It is FTBFS due to the
GCC 11.0 upgrade (so it is FTBFS for quite some time already).
The update is on the way to Rawhide and I don't plan to push this update to
stable releases (unless somebody asks for it).
Have fun during these holidays!
3 years, 3 months
Fedora 34 Change: Deprecate xemacs, xemacs-packages-base,
xemacs-packages-extra, and neXtaw (Self-Contained Change proposal)
by Ben Cotton
https://fedoraproject.org/wiki/Changes/Deprecate_xemacs
== Summary ==
Deprecate the xemacs, xemacs-packages-base, xemacs-packages-extra, and
neXtaw packages, all of which have dead upstreams.
== Owner ==
* Name: [[User:jjames|Jerry James]]
* Email: loganjerry(a)gmail.com
== Detailed Description ==
I have been part of XEmacs upstream for over 20 years, and have
maintained the Fedora package for over 11 years. Upstream development
had already slowed significantly when I became Fedora maintainer. The
last release was over 7 years ago. Since that time, development has
essentially come to a halt. Somebody will push a commit every now and
then, but significant bugs are not being fixed. I see no future for
the project. We should start moving towards dropping it from the
distribution. The upstream sources have been spread across 3 packages
in Fedora: xemacs, xemacs-packages-base, and xemacs-packages-extra.
In addition, the xemacs package uses an ancient, unmaintained 3D X
library: neXtaw. It's last release was in 2003. Since xemacs is the
only package in Fedora that uses neXtaw, I propose that it also be
deprecated so we can eventually drop it.
Deprecation is warranted because there are about a dozen XEmacs add-on
packages in Fedora. This will prevent us from adding any more as we
work to retire the existing add-ons.
== Feedback ==
On December 7, 2020, I
[https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.o...
communicated my intent to file this Change] on fedora-devel-list.
There has been no community feedback.
== Benefit to Fedora ==
This Change will open a path for us to eventually remove unmaintained
software from the distribution.
== Scope ==
* Proposal owners:
The only required work is the addition of `Provides: deprecated()` to
the 4 affected packages.
* Other developers:
No immediate work is required. Eventually, maintainers of XEmacs
add-on packages will need to retire those packages so that XEmacs
itself can be retired.
* Release engineering:
This change does not require coordination with or impact release
engineering and does not require a mass rebuild.
* Policies and guidelines: N/A (not a System Wide Change)
* Trademark approval: N/A (not needed for this Change)
* Alignment with Objectives:
While this proposal does not match any of the
[https://docs.fedoraproject.org/en-US/project/objectives current
objectives], it is not opposed to any.
== Upgrade/compatibility impact ==
Since the Change only deprecates packages, it has no immediate effect
on upgrades or compatibility. Eventually, when the affected packages
are retired, fedora-obsolete-packages will be updated to properly
manage upgrades.
== How To Test ==
N/A (not a System Wide Change)
== User Experience ==
This change will not lead to any immediate changes in user experience.
Eventually, we will retire the affected packages, which will impact
users of those packages. We will seek to communicate the upcoming
retirement as we work towards it.
== Dependencies ==
N/A (not a System Wide Change)
== Contingency Plan ==
* Contingency mechanism: (What to do? Who will do it?) N/A (not a
System Wide Change)
* Contingency deadline: N/A (not a System Wide Change)
* Blocks release? N/A (not a System Wide Change)
* Blocks product? None
== Documentation ==
N/A (not a System Wide Change)
== Release Notes ==
The xemacs, xemacs-packages-base, xemacs-packages-extra, and neXtaw
packages have been deprecated. XEmacs users should prepare for the
eventual removal of these packages from the Fedora distribution.
--
Ben Cotton
He / Him / His
Senior Program Manager, Fedora & CentOS Stream
Red Hat
TZ=America/Indiana/Indianapolis
3 years, 3 months