Alex Chernyakhovsky <achernya(a)mit.edu> writes:
> Yeah, I have no idea how I missed that bug. But I've uploaded 1.3.2
> for all active branches and requested an epel8 branch, so that's all I
> can do for now :)
I'll just cut to the chase.
About 2-3 months ago I filed a bug report that overclocking on Nvidia
hardware wasn't working on Fedora. I observed this bug while trying out
Fedora Silverblue 30's release but not in beta. I then later sent an
email about this issue wherein Nvidia was immediately blamed for the bug
despite this not being an issue on any other Linux distro. I was then
asked to file a bug report and had provider information, which I did by
doing multiple reinstalls of Silverblue/Workstation.
2-3 months ago by and the bug report has been closed because I didn't
and couldn't do a deep level analysis. I don't use Fedora, I use Arch
Linux. This isn't my distro and I'm not the one that broke it to begin
with. The only reason I was even trying it out is because I really like
the whole immutable filesystem concept and was hoping that the bug and
issues with it would be ironed out and that I could switch to it if Arch
decided to take a dump.
Sadly the issues weren't last time I checked about a month ago.
Silverblue repos are often out of sync with the rest of Fedora resulting
in upgrades failing. You have to manually cleanup upgrade meta cache to
get upgrades to work correctly(rpm-ostree cleanup -m). Fedora update
servers in general are unstable and unreliable as hell, sometimes
returning HTTP error codes or just being offline. Gnome Software doesn't
display software correctly on the front page. There still is no way to
add Flatpak external disks via Gnome-Settings as of 3.34. You can't use
Rawhide with Nvidia drivers because of debug kernel. There is a lack of
software compared to other Linux distros like Ubuntu or Arch(no
Vivaldi!?!?). Fedora developers tend to be hostile towards proprietary
No, Red Hat. Fedora Silverblue isn't easy to use.
...but I digress...
I got the email and decided to check the nvidia-settings repo on
Github. Apparently, Someone has filed a bug report about overclocking
on rootless X. org servers doesn't work. I then downloaded Fedora
Workstation and installed the Nvidia driver and checked which user the
X. org server was running under.
Mini rant: By the way, update your damn installer images. Users
shouldn't have to install 400MB of updates after they just install the
distro. The installer image has Firefox 66 on it still! That's really
freaking stupid. On my 5400RPM drive it takes a half hour to install all
of that crap, which is longer than installing the distro itself or
updating under Silverblue!
Yep, X. Org **ISN"T** running under root. Overclocking doesn't work
either, same as before.
So I then tried making X. Org run as root using the Arch Wiki's guide
and verified that I was now running as root.
I was... and overclocking is now working.
...seriously? You make a abrupt change to Fedora 30 literally right
before it was released, breaking overclocking applications such as my
own AND Nvidia's own software, and then blame Nvidia for your own
So problem found. It was a problem in Fedora all along, like I said from
nearly the beginning. Fix problems that **YOU** make instead of blaming
Nvidia next time.
== Summary ==
Better thermal management and peak performance on Intel CPUs by
including thermald in the default install.
== Owner ==
* Name: [[User:benzea| Benjamin Berg]]
* Email: bberg(a)redhat.com
* Name: [[User:ckellner| Christian J. Kellner]]
* Email: ckellner(a)redhat.com
* Product: Workstation
* Responsible WG: Workstation
== Detailed Description ==
Modern Intel-based systems provide sensors and methods to monitor and
control temperature of its CPUs. The Thermal daemon will use those
sensors to monitor the temperature and use the best available method
to keep the CPU in the right temperature envelop. On certain systems
this is needed to reach the maximal performance. For optimal
performance a per-model thermald configuration should be created, this
can either be done by using dptfxtract (available from rpmfusion) or
we could ship static configuration files for a set of known models.
For a more details explanation please consult Intel's
introduction] to thermald.
== Benefit to Fedora ==
Better out-of-the-box experience due to improved cooling methods and
performance on Intel systems.
== Scope ==
* Proposal owners:
- Include the thermald package in the default Workstation install
- Optionally provide patches for thermald to be able to read hardware
specific configuration data
- Optionally collect hardware specific configuration data and ship it
* Other developers: N/A (not a System Wide Change)
* Release engineering:
* Policies and guidelines: N/A (not a System Wide Change)
* Trademark approval: N/A (not needed for this Change)
== Upgrade/compatibility impact ==
N/A (not a System Wide Change)
== How To Test ==
Install the packages and use e.g. turbostat to monitor the
performance. Improvements may only be visible if the non-free
dptfxtract package is also installed.
== User Experience ==
- Better performance on certain hardware
- Better cooling of CPUs on certain hardware
He / Him / His
Fedora Program Manager
As eclipse module is the supported way to get eclipse now and there are a
number of FTBFS for me as a package I've just orphaned the following:
Most of them are leaf packages so can go freely - only critical parts if
one wants to keep eclipse srpm in is eclipse-ecf and cbi-plugins.
Red Hat Eclipse Team
Are the aarch64 test systems running on real or emulated hardware? (Is
there a way to tell?)
I ask because I'm seeing bad numerical results from a test and would
like to know if I can eliminate qemu as a possible cause -- not that I
think that's likely.
tagsoup was maintained byt he Stewardship SIG and is no longer required by any
of our packages. I have orphaned it.
I don't know much about the package, but several other Java stuff requires it:
It was updated to the current 1.2.1 version in 2012 and upstream has either
moved or died.
The Stewardship SIG is currently providing only bare-minimum
maintenance for some Java packages, and none of our packages depend on
So, we're looking for someone to take better care of them, preferably
someone who actively uses these packages or maintains a package that
depends on them.
The packages are:
Directly dependent packages of java-base64:
Directly dependent packages of jboss-jstl-1.2-api:
Directly dependent packages of jetty-version-maven-plugin:
Directly dependent packages of stringtemplate4:
Directly dependent packages of tagsoup:
If you received this email directly, you're a (co-)maintainer of one
of these packages, and would probably be best qualified to take care
of the package in question.
If you want to take one, some, or all of them off our hands, just fill
out the "package_adoption_request" template here, and we will transfer
the package to you. https://www.pagure.io/stewardship-sig/new_issue
If nobody claims the packages within the next two weeks, we will
orphan them again, setting them on their course towards retirement in
about two months.
Fabio (decathorpe), for the Stewardship SIG
Good Morning Everyone,
The Fedora Infrastructure team has been working on making changes to the way
orphaned packages are being adopted as well as the way to set the monitoring
status for the integration with anitya (ie: https://release-monitoring.org).
## Orphan packages
Currently if a package is orphaned there is no way to adopt it easily on
dist-git (https://src.fedoraproject.org). You need to open a ticket on the
releng issue tracker and wait for someone to process that ticket.
This is going to change, new versions of pagure-dist-git and pagure will offer a
button on the left hand side menu offering to adopt orphaned packages.
This is already live in staging, so you can see how it looks there, for example:
https://src.stg.fedoraproject.org/rpms/aasaver (you'll need to be logged in)
Note: if the package is retired, you will still have to go through a releng
ticket as it will need to be unblocked in koji.
## Anitya integration
Currently if you want to tweak the setting for the anitya integration, you need
to open a pull-request on the fedora-scm-requests project at
That git repo is pretty big and once your pull-request is finally open, you
still have to wait for someone to merge it.
This is also going to change, new versions of pagure and pagure-dist-git offer a
drop-down menu on the left hand side menu to see and adjust the monitoring
status of the project.
This is also live in staging and you can see an example of a project who has set
its monitoring status to "monitoring":
(The status in staging have been imported from the fedora-scm-requests repo)
Feel free to play with this in staging and let us know if there is anything that
isn't working as expected or that you would like to change before we push this
to production (post F31-beta freeze).
Once the new versions of pagure, pagure-dist-git, anitya and the-new-hotness
have been deployed to production we will send another announcement for the
change and work on getting the different documentations updated.
Looking forward to hear from you,
Michal and Pierre
- On behalf of the Fedora Infrastructure team
devel-announce mailing list -- devel-announce(a)lists.fedoraproject.org
To unsubscribe send an email to devel-announce-leave(a)lists.fedoraproject.org
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://firstname.lastname@example.org...