Heads up: changing the subject format of change proposal announcements
by Ben Cotton
Just in case anyone is parsing the subject line of change proposal
announcements (I really hope not, but if you are, please let me know
off-list what your use case is. I'm curious), I'm going to make a
change to how these are formatted.
I will replace
"Fedora <N> <Type> Change proposal: <Title>"
with
"<Title> - Fedora <N> <Type> Change proposal"
As noted by Milan Crha, the existing format can result in threads that
are hard to distinguish when the subject is truncated by the width of
the mail client window. Screens are often pretty wide these days, but
~40 characters is still a lot to use.
--
Ben Cotton
He / Him / His
Senior Program Manager, Fedora & CentOS Stream
Red Hat
TZ=America/Indiana/Indianapolis
3 years, 8 months
Upcoming Fedora 33 Change proposal deadlines
by Ben Cotton
This is your reminder that several Change proposal deadlines for
Fedora 33 are approaching.
* 2020-06-24: Proposal deadline for Changes requiring infrastructure changes
* 2020-06-30: Proposal deadline for Changes requiring mass rebuild
* 2020-06-30: Proposal deadline for System-Wide Changes
* 2020-07-21: Proposal deadline for Self-Contained Changes
For the full schedule, see
https://fedorapeople.org/groups/schedule/f-33/f-33-key-tasks.html
--
Ben Cotton
He / Him / His
Senior Program Manager, Fedora & CentOS Stream
Red Hat
TZ=America/Indiana/Indianapolis
3 years, 8 months
Orphaning repsnapper, gtkglextmm
by Miro Hrončok
I've just orphaned repsnapper and gtkglextmm. repsnapper depends on gtkglextmm
which depends on pangox-compat, which is already orphaned for 4 weeks.
I haven't touched the packages in years and I don't use repsnapper.
In case a new maintainer emerges, I can stay around if needed.
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
3 years, 8 months
Announcement: Aim to remove libdb-java from Fedora-rawhide
by Ondrej Dubaj
Hello everyone,
we are aiming to remove libdb-java package from Fedora-rawhide, as we are
currently preparing for jdk update from jdk-1.8 to jdk-11 in Fedora
rawhide. The problem is that we are unable to rebuild this package with
jdk-11. It is still possible to "hack" it and rebuild it with jdk-1.8, but
that can cause unexpected runtime behaviour according to JVM-11, which will
soon be default in Fedora-rawhide.
There seems to be no packages, which depend directly to libdb-java and
upstream does not support version 5.3.28 anymore.
If anyone has any reasons why this should not be made, or someone is
currently active user of this JDBC connector, please leave a comment with
your opinion in the tracker [1] mentioned below.
There is also an existing tracker for deprecating libdb in Fedora [2], so
this can be understand as a first step.
Additional info about jdk-11 here [3].
Best regards,
Ondrej Dubaj
Associate Software Engineer
Red Hat
[1] https://bugzilla.redhat.com/show_bug.cgi?id=1846398
[2] https://bugzilla.redhat.com/show_bug.cgi?id=1834842
[3]
https://fedoraproject.org/wiki/Changes/Java11#Intermediate_step_build_wit...
3 years, 8 months
Fedora 33 Self-Contained Change proposal: Drop mod_php
by Ben Cotton
https://fedoraproject.org/wiki/Changes/drop_mod_php
== Summary ==
mod_php (apache2handler) is an optional httpd module to execute PHP
scripts, not used.
== Owner ==
* Name: [[User:Remi| Remi Collet]]
* Email: remi at fedoraproject dot org
== Detailed Description ==
By default php-fpm is used for a few versions. mod_php is not
supported for threaded modules. mod_php usage also increases security
risk, sharing the same process than httpd.
Drop mod_php from php build. This will only affect user of httpd in
"prefork" mode, which will also use php-fpm.
php-fpm is already used but most users of httpd and nginx without any issue.
The "php" package will be kept as a metapackage, installing (weak
dependencies) most commonly used extension, thus reducing the
difference between "yum install php" (flat repository) and "yum module
install php" (modular repository).
== Benefit to Fedora ==
Only provide the modern way to execute PHP in a web server.
== Scope ==
PHP rebuild (mod_php build is already conditional)
* Other developers: N/A (not a System Wide Change)
* Release engineering: N/A
* 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 and play with your web applications
== User Experience ==
No change.
== Dependencies ==
None (dependency on "php" is already forbidden by Guidelines)
== Contingency Plan ==
* revert
* Contingency deadline: N/A (not a System Wide Change)
* Blocks release? N/A (not a System Wide Change), Yes/No
* Blocks product? product
== Documentation ==
--
Ben Cotton
He / Him / His
Senior Program Manager, Fedora & CentOS Stream
Red Hat
TZ=America/Indiana/Indianapolis
3 years, 8 months
Fedora 33 Self-Contained Change proposal: NSS dbm support removal
by Ben Cotton
https://fedoraproject.org/wiki/Changes/NSSDBMRemoval
== Summary ==
Network Security Services (NSS) historically supports 2 different
database backends, based on SQLite and dbm. Since Fedora 28, the
SQLite backend has been used by default and the dbm backend has been
deprecated ([[Changes/NSSDefaultFileFormatSql|NSS Default File Format
SQL]]). This Change is about removing the support for the dbm backend
entirely.
== Owner ==
* Name: [[User:ueno| Daiki Ueno]]
* Email: dueno(a)redhat.com
== Detailed Description ==
Applications that use the NSS library often use a database for storage
of keys, certificates and trust. NSS supports two different storage
formats, one is based on SQLite and another one is based on dbm files.
Today's default file format used by NSS, used when applications omit
the type parameter, is the SQLite file format, and the older dbm
format has been considered as deprecated since Fedora 28, because it
has several drawbacks such as lack of support for parallel access to
the storage.
As the default change was made 2 years ago, and NSS provides a
transparent migration mechanism from the dbm format to the SQLite
format, the suggestion is to completely disable the dbm backend.
== Benefit to Fedora ==
There are a few benefits:
* By disabling the dbm database, the size of the library binary will
be slightly smaller
* The NSS developers will be able to focus on the new file format
== Scope ==
* Proposal owners:
A build time environment variable (NSS_DISABLE_DBM) needs to be set.
* Other developers: N/A
* Policies and guidelines: N/A (not a System Wide Change)
* Trademark approval: N/A (not needed for this Change)
== Upgrade/compatibility impact ==
The impact should be limited, as long as the users always update from
the previous version. That would ensure the existing databases on the
system are properly migrated. Therefore, we propose this as a Self
Contained Change, rather than a System Wide Change.
In the discussion on the fedora-devel list, it was pointed that pesign
package embedded the dbm format database. It has now been resolved in
[https://bugzilla.redhat.com/show_bug.cgi?id=1827902 bug 1827902].
== How To Test ==
N/A (not a System Wide Change)
== User Experience ==
No user visible changes.
== Dependencies ==
N/A (not a System Wide Change)
== Contingency Plan ==
* Contingency mechanism: Revert the shipped configuration
* Contingency deadline: N/A (not a System Wide Change)
* Blocks release? No
--
Ben Cotton
He / Him / His
Senior Program Manager, Fedora & CentOS Stream
Red Hat
TZ=America/Indiana/Indianapolis
3 years, 8 months
Packagers with no corresponding valid bugzilla accounts
by Pierre-Yves Chibon
Good Morning Everyone,
If you are a packagers or are watching tickets on dist-git (ie: asked to be
cc'ed on tickets on bugzilla for a given package), you must have a valid
bugzilla account associated with the email address you have set in FAS.
There are currently 66 users and groups who do not satisfy this requirement.
This has a direct impact as the script syncing from dist-git to bugzilla the
information about the default assignee and the CC list updates components in
bugzilla in a single request to reduce the load on the server.
So if someone in the CC list does not have a valid bugzilla account, the
entire request will fail to update both the CC list and the default assignee.
Accounts in this state may at some point be removed from packages/cc, so it's
important to correct your account soon!
So, if your name is listed here, please take a minute and create a bugzilla
for the email you have associated with your FAS account:
aarondmarasco
adsllc
affix
ajeetdsouza
alen
amitshah
andreyma
avesh
bpereto
@certbot-sig
csomh
darkdragon001
dcantrel
digimer
dmsimard
doug1
edwintorok
etingof
fepitre
gnikandrov
@graphics-sig
ignotusp
itsbill
jefferson2z
jkratoch
jkreuzer
karsten
kir
klausdevwalker
labbott
lamm
luismartingil
marcdeop
mathstuf
mbartos
mhabrnal
mildew
mmahut
moisesguimaraes
mzidek
nguzman
njohnston
omejzlik
pgibson
portante
proski
rbtr
robled
romal
rpitonak
rspanton
sakalosj
squallbayu
sspreitz
sturivnyi
svahl
tnorth
trasher
tstclair
usercont
vbatts
vicodan
vpolasek
@weldr-sig
yuwata
zmc
If you really to have two distinct email addresses, we keep a mapping of FAS
emails to bugzilla account in [1], which you can update via a pull-request if
you wish to use this.
Thanks for your help,
Pierre
[1]
https://pagure.io/fedora-infra/ansible/blob/master/f/roles/openshift-apps...
_______________________________________________
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://lists.fedoraproject.org/archives/list/devel-announce@lists.fedora...
3 years, 8 months
Questions on an update to javamail in ursine
by Jie Kang
Hi all,
javamail ursine is using version 1.5.2 while there are some module
streams at 1.6.x
The upstream project also moved to the eclipse foundation and these
1.6.x releases have different exports for OSGi, making an update to
them potentially breaking for users.
I'd like to update ursine to 1.6.x, but I understand packages
depending on them should be notified or some such. However I realized
I don't know what commands to run to get a list of such and then where
to send it. Could anyone advise?
Also, upstream repo was renamed: https://github.com/eclipse-ee4j/mail
so maybe a new package 'mail' can be introduced to use it? Any
thoughts there?
Thanks,
Jie Kang
3 years, 8 months
Better Thermal Management for the Workstation - Fedora 33
Self-Contained Change proposal
by Ben Cotton
https://fedoraproject.org/wiki/Changes/ThermalManagementWS
== 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. thermald will for example use the PPCC power
table to set power limits (when available, see for example
https://www.mail-archive.com/kernel-packages@lists.launchpad.net/msg41161...).
This is for example the case on Ice Lake, where thermald can increase the
performance of the out-of-the-box behaviour of Fedora.
Not strictly necessary, but *further* improvements can be achieved by using
per-model thermald configurations. The most straight forward way of using
those is for the user to install dptfxtract (available from rpmfusion). At
least parts of what dptfxtract can already do may be integrated into
thermald in the future thanks to the reverse engineering work done by
Matthew Garret (see
https://github.com/intel/thermal_daemon/tree/mg_patches_test,
https://github.com/intel/thermal_daemon/pull/224). Should the reverse
engineering effort be merged, or if the user installs dptfxtract, then they
can expect a performance boost on some machines.
Theoretically one could ship appropriate per-machine configurations as a
separate package (or inside thermald). However, this is not part of the
proposal for a number of reasons:
1. It is not clear how the configuration data can be collected
2. We do not currently have an implementation to load such configuration
data
3. This may become obsolete with if the reverse-engineering effort
continues and is merged (or picked up by Fedora)
For a more details explanation please consult Intel's [
https://01.org/linux-thermal-daemon/documentation/introduction-thermal-da...
introduction] to thermald.
== Benefit to Fedora ==
Better out-of-the-box experience due to improved cooling methods and
performance on Intel systems. This affects many modern laptops (e.g. the
Ice Lake platform). On affected machines, Fedora would continue to have
poorer performance compared to other distributions.
== Scope ==
* Proposal owners:
- Include the thermald package in the default Workstation install
* 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
== Dependencies ==
N/A (not a System Wide Change)
== Contingency Plan ==
* Contingency mechanism: Don't ship package by default
* Contingency deadline: N/A (not a System Wide Change)
* Blocks release? N/A
--
Ben Cotton
He / Him / His
Senior Program Manager, Fedora & CentOS Stream
Red Hat
TZ=America/Indiana/Indianapolis
3 years, 8 months
Re: Fedora 33 System-Wide Change proposal: Make nano the default editor
by alexandrebfarias@gmail.com
Hello,
I decided to register just so I could offer my humble take on this. First
of all, I have many years of Linux experience (mostly on Debian and
Gentoo), but after years without having Linux on my desktop environments
(though I did use it on all servers I have managed, mostly on the Debian
side of things). Seeing the currently offered options, even though I almost
nil experience with RHEL/CentOS/Fedora systems, I decided to go with Fedora
earlier this year (just before F32 was released). BTRFS drove me an inch
away from completely removing Fedora from my system and never looking back
again. I mean, it couldn't be just a file system, it seemed impossible that
deeper issues within the distro weren't involved.
Android emulator went literally unusable. Images that podman would build
10x times faster in lower specced servers. Turned off datacow on the
folders containing the vm images/container fs's and copied them in order to
get rid of the fragmentation. Things were a little better, but performance
was still degrading every single day. I just threw the towel and turned off
datacow entirely as a palliative, which made the system somewhat usable but
also made btrfs a toothless tiger, took away all of its compelling
features.
All of this was on a Predator Helios 300 - 572 notebook, i7 7700, 32gb ram,
dedicated Nvidia 1060, with the BTRFS system installed on a 500GB WD Blue
SSD. At this point I was starting to wonder whether Fedora, Gnome or even
Linux were a viable choice of this machine, it seemed my computer wasn't
getting along with the system at all.
Only reason I still have Fedora is that I managed to backup the data on my
NVME WD Black 256GB drive, wiped it and created a new XFS partition as a
last ditch effort (also mirroring the previous Swap / boot layout, but this
time I had swap encryption) I mean, of course the PCI-E interface is fast
than the SATA one, but the difference is barely noticeable during daily
usage. And while I had BTRFS as a raw partition, XFS was on top of LVM and
LUKS. My WD Blue SSD is also, fine tested it over and over again to make
sure and my previous Windows installation ran there and performed just
fine.
Wasn't very hopeful, but after a simple rsync and simply pointing grub to
the new XFS partition gave a whole new life to my system. The sizes were
very similar (the BTRFS partition had about 230GB), so it can't come down
to that. The difference was so absurd I couldn't believe I was actually
enjoying the exact same system just because of a FS change. I really wish I
could provide benchmarks to back my claim but at this point I was quite fed
up and had lost a lot of productive time because of the countless hang-ups
and even crashes I experienced with btrfs.
Don't expect much love on this, since my opinion has been downvoted on
reddit by many of those who don't want to hear bad news about btrfs. And
no, I don't have any benchmarks and did not collect any logs, I'm not
talking about a bug, BTRFS is defective beyond anything Fedora could do to
fix it. After spending so much time fighting against my system
So, deciding to come back to Linux after getting fed up with Windows, meant
that I'd have to make some choices. Foremost of all for me, after choosing
Fedora, was choosing a suitable filesystem. I installed it on a partition
taking about half of a pretty decent WD Blue SSD. I actually expected btrfs
to be one of the best aspects of my experience, was quite excited to make
use of its capabilities (and I didn't even get to using RAID features,
which are knowingly riddled with defects).
I've never thought much of ext4 and in the past I just went with JFS for my
desktop machines. I mean, my machine is pretty decent, the performance
impact couldn't be that bad, even seeing the benchmarks. Turns out I was
wrong. My system was pretty much unusable after some weeks. Even
defragmenting and doing every kind of mount flag option optimization known
to man didn't make the situation any better. Turning off CoW was the only
thing that made me able to even perform simple tasks on my otherwise
performant computer.
With all due respect, this proposal is borderline wreckless. There is not a
single benchmark out there showing BTRFS is suitable for any common
workload of an average Fedora user. Anedoctal experience is even worse. I'm
boarding an airplane right now and this e-mail should be quite
disorganized, but I had to leave my 2cents
I'm not surprised RHEL completely got rid of BTRFS and not even oracle is
using it as a default for their Enterprise Linux.
3 years, 8 months