Re: Renaming pythonXY packages to pythonX.Y (e.g. python39 to
python3.9)
by Miro Hrončok
On 29. 04. 20 21:42, Lloyd Kvam wrote:
>> What you say is true. I still don't agree that "python3.9" as a package name
>> annoys humans.
> I am not a package pro, but simply reading along as an interested human user. To me, adding
> periods in package names can be confusing.
My sentence was about "python3.9" not being more annoying than "python-3.9".
I wonder, why do you consider periods in names confusing?
We have around ~100 source package names with dot. Most of them have versions, e.g.:
clang9.0
dotnet3.1
freerdp1.2
llvm5.0
llvm6.0
llvm9.0
jboss-jsf-2.1-api
jboss-jsf-2.2-api
jboss-jsp-2.2-api
jboss-jsp-2.3-api
Some use dot as a separator, e.g.:
R-R.utils
R-data.table
R-futile.logger
R-futile.options
R-gamlss.dist
R-lambda.r
R-statnet.common
openoffice.org-diafilter
python-boolean.py
> I will adjust to whatever you decide to do, and I am not informed enough to want a vote in how
> this decision comes down, but I do not see an advantage to this sort of change.
The biggest advantage I see is getting closer to upstream.
The command that the user executes is "python3.9", not "python39".
I know no other place in the Python ecosystem where Python 3.9 is called
"python39" than the names of RPM packages (or other Linux distro packages).
I've googled "python36", "python37" etc. and all I could find was
Fedora/RHEL/CentOS related (or AUR). We have invented that naming ourselves and
we don't like being different :)
(There is the "py39" short identifier used e.g. in tox, but not "python39".)
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
2 years
Block discard on more things
by Chris Adams
Now that Fedora 32 has fstrim.timer enabled by default... how about
discards for the things that fstrim doesn't get? Two main things I know
of:
- swap: Do discard at swapon time by setting "discard=once" in
/etc/fstab would be somewhat similar to the periodic fstrim call. I
don't know how much impact the "discard=pages" option might have (the
man page says it is asynchronous, but it might make low-memory
situations worse).
- logical volumes: Set "issue_discards = 1" in /etc/lvm/lvm.conf so that
removed LVs get discarded.
--
Chris Adams <linux(a)cmadams.net>
2 years
Renaming pythonXY packages to pythonX.Y (e.g. python39 to python3.9)
by Tomas Orsava
Hello everyone.
I’m working on a change to rename pythonXY packages to pythonX.Y, e.g.
python39 to python3.9.
*Motivation:*
When you install an additional Python interpreter, the command that runs
it contains a dot (e.g. /usr/bin/python3.9) but the package name does
not (e.g. dnf install python39).
The name without a dot is a technical debt that we carry since (at
least) the python26 package in RHEL 5 for consistency. The name with the
dot makes much more sense to Red Hat Python maintainers.
It’s a minor inconsistency, but we'd like to get it right in RHEL, and
since RHEL splits off from Fedora, it will be bugging us still in 2030+
unless we fix it now. Especially with the likely coming version 3.10 the
package name python310 is confusing. This will also get us in sync with
e.g. Debian package names.
*Backwards compatibility:*
We plan to create new components in rawhide containing the dot (e.g.
python3.9) for all Python interpreters (except soon-to-be-retired
python34 and python26) and push the git commits from pythnoXY to them to
preserve the history.
The packages will Provide and Obsolete the old name without a dot (e.g.
python39). The current packages already provide the name with the dot,
so this will be just a switch between real name and virtual provide.
Therefore any package that depends on these components will continue to
work just fine. And in time we’d like to fix all of those to use the new
name, which is backwards compatible, because it is already provided now
(as a side note, the packages are generally just recommended, not required).
*Technical details:*
There has been a recent rawhide-only change to the %python_provide macro
that acts on packages named `python3-foo` and adds for them a new
Provide `python38-foo`.
We’d like to change this to Provide `python3.8-foo` instead.
Since this has been rawhide-only so far, and because there’s no real
reason to depend on these provides yet, we don’t expect any breakage.
What do you think? Do you foresee any problems?
All the best,
Tomas
2 years
Fedora+Lenovo
by Mark Pearson
Hi all,
Adam Williamson suggested I stick a note in the mailing list saying “hi” - so I’ve achieved that and officially upgraded myself from lurker! He also suggested I take questions from the community - and I’m very happy to do that.
So - if there are any questions from Fedora developers on the Lenovo announcement let me know and I will answer them as best I can….if I don’t know the answer I’ll do the try to find out.
I will lurk around the mailing list but generally if there is anything that might be important for Lenovo to look at/respond to/etc and I don’t respond do feel free to send me a note directly saying “Look at the mailing list” 😊
Mark
2 years
CPE Weekly: 2020-04-26
by Aoife Moloney
# CPE Weekly: 2020-04-26
---
title: CPE Weekly status email
tags: CPE Weekly, email
---
Background:
The Community Platform Engineering group is the Red Hat team combining
IT and release engineering from Fedora and CentOS.Check out our teams
info here https://docs.fedoraproject.org/en-US/cpe/
## GitForge Updates
* We will be tracking our progress here
https://fedoraproject.org/wiki/Git_forge_update
* Please be aware this does not contain any new information, as we
don't have any to share yet.
* However once we have more information for you, we will be posting it
to the above link, and with the URL in the weekly emails for quick
access.
* We are currently doing a technical deep-dive with our own team on
what we need from GitLab
* We are also still engaging with Fedora Council who are tracking the
Fedora Communities needs here
https://pagure.io/Fedora-Council/tickets/issue/292
* And we are looking at ways to engage closer with the CentOS
community too to share information as and when we have it
* Public Q&A sessions are still being discussed to allow for open
conversations in public forums too as we move through this journey, so
thank you for your patience with us.
## Fedora Updates
* F32 release is a Go!
* Estimated release date is April 28th - well done to everyone involved!
### Data Centre Move
* Due to Covid-19 restrictions at each datacentre, we have
unfortunately experienced a delay during the initial move.
* The need to push out our dates by 2-3 weeks was made necessary on
Thursday 23rd April, following meetings with Red Hat IT on network
connectivity status and estimate connection times for our team to
access the new datacentre.
* We will need to adjust our outage schedule and move schedule to
properly reflect the new dates of services being turned off and
reduced, and the full amended schedule will be published to hackmd,
with emails sent to the devel-announce & infra lists next week (week
ending 1st May)
* We will also include links to the updated move schedule and service
impact schedule in next weeks CPE Weekly
* Please be aware that CommuniShift is now down indefinitely until
earliest May 8th.
### AAA Replacement
* The team have begun phase two of the project and you can view their
board for more technical information on their work here
https://github.com/orgs/fedora-infra/projects/6
* They are doing amazing work :)
### CI/CD
* Monitor-gating is now running in production and has already caught a
couple of issues with bodhi (both in stg and in prod)!
* Rpmautospec
* In review as a Fedora package:
https://bugzilla.redhat.com/show_bug.cgi?id=1816124
* Work progressing on Koji tagging plugin (post-build), full use
case support for bumping releases
* Plan is still to get it deployed in staging
### Sustaining Team
* Mbbox Upgrade
* Some progress on CRD for koji-builder and koji-hub components
* Bodhi 5.2.2 released
* Some issues with celery tasks, however rawhide monitoring super useful.
* Compose tracker enhancement
* Focusing on tagging issues, and having the ability to ping maintainers
Odcs-backend-releng01 provision to enable testing in Fedora Minimal Compose
* Infra
* The daily standup the team has has helped a lot with managing
infra tickets - they are down to 99 tickets!
* Mass update of stg and prod
* Please note you may experience some Kojira slowness
* New review-stats application deployed -
(https://fedoraproject.org/PackageReviewStatus/)
## CentOS Updates
### CentOS
* ppc64le and aarch64, 8 and 8-stream nodes now available in cico for
tenants to checkout. -- Email sent to ci-user list
* New signing for SIGs (through https://cbs.centos.org) live on 25th April 2020
### CentOS Stream
* Summit Videos took our attention this week
* We have a booth, so don't forget to register your attendance!
https://www.redhat.com/en/summit
* Qt5.12 pushed in response to an internal request
* NetworkManager re-imported
As always, feedback is welcome, and we will continue to look at ways
to improve the delivery and readability of this weekly report.
Have a great week ahead!
Aoife
Source: https://hackmd.io/8iV7PilARSG68Tqv8CzKOQ
--
Aoife Moloney
Product Owner
Community Platform Engineering Team
Red Hat EMEA
Communications House
Cork Road
Waterford
2 years
<sys/sysctl.h> will disappear from rawhide glibc soon
by Florian Weimer
This follows the removal of the system call from Linux 5.5. Having the
header and function just confuses configure checks that assume that if
the function is present, it will do something useful (it never did on
aarch64, and it's been many years since it worked on Fedora kernels on
other architectures).
Replacements are uname, getentropy, and reading from /proc, but I really
do not expect much fallout from this (famous last words).
The kernel headers still provide <linux/sysctl.h>, but that will
eventually disappear as well.
Thanks,
Florian
2 years
Fedora pagure confusion wrt EPEL
by Michael Schwendt
I don't do EPEL packaging. I never signed up as an "owner" of EPEL packages.
I don't want to be the new default owner of EPEL bugzilla tickets.
Where may I be able to stop this mess?
2 years
Fedora 33 Self-Contained Change proposal: Network Time Security
by Ben Cotton
https://fedoraproject.org/wiki/Changes/NetworkTimeSecurity
== Summary ==
Support for the Network Time Security (NTS) authentication mechanism
in the NTP client/server (chrony) and installer (anaconda).
== Owner ==
* Name: [[User:mlichvar| Miroslav Lichvar]], [[User:mkolman| Martin Kolman]]
* Email: mlichvar(a)redhat.com, mkolman(a)redhat.com
== Detailed Description ==
NTP is a widely used protocol for synchronization of clocks over
network. Authentication of NTP packets is important to prevent a
Man-in-the-middle (MITM) attacker from taking full control over the
client's clock (e.g. force it to jump to a distant future or past).
Several different authentication mechanisms have been specified for
NTP. The oldest and simplest one uses secret keys, where each client
has its own key which needs to be securely distributed to the server
and client. This means it is mostly limited to local networks. Autokey
is a newer mechanism based on public-key cryptography, but it was
shown to be insecure and it is rarely supported on public servers.
NTS is a new authentication mechanism
[https://datatracker.ietf.org/doc/draft-ietf-ntp-using-nts-for-ntp
specified by the IETF] for NTP. NTS has an NTS-KE protocol using
Transport Layer Security (TLS) to establish the keys and provide the
client with cookies which allow the NTP server to not keep any
client-specific state. NTP packets are authenticated using
Authenticated Encryption with Associated Data (AEAD). NTS is expected
to scale well to a large numbers of clients. There are already some
public NTP servers with NTS support.
The default NTP client and server on Fedora is `chrony`. Support for
NTS is added in version 4.0. It uses the GnuTLS library for TLS and
the Nettle library for AEAD.
NTS authentication can be enabled on the client by adding the `nts`
option to the `server` or `pool` directive in ''/etc/chrony.conf''.
Until a standard port is assigned for NTS by IANA, the port may need
to be specified with the `ntsport` option. For example
`
server time.example.com iburst nts ntsport 12123
`
When using NTS-enabled NTP sources, any NTP source that is not trusted
and reachable over a trusted network should be disabled. This includes
servers provided by DHCP. They should be disabled by adding
`PEERNTP=no` to ''/etc/sysconfig/network''.
We can consider changing the default ''/etc/chrony.conf'' to use some
trusted public NTP servers with NTS support. There are public servers
provided by [https://www.cloudflare.com/time/ Cloudflare] and
[https://www.netnod.se/time-and-frequency/how-to-use-nts Netnod]. Both
would be ok with Fedora using their servers by default (after some
testing and coordination). There is also a possibility that
pool.ntp.org will support NTS, although it is not very clear how
useful would NTS be in this case as the servers are owned by
individual contributors instead of a single trusted entity and
attackers can easily join the pool (some mitigations have been
proposed on the pool mailing list).
Potential issues with enabling NTS by default:
* Firewalls may block the NTS-KE port.
* ISPs may block or rate limit longer NTP packets as a mitigation for
amplification attacks using NTP mode 6 and 7. NTS-KE supports port
negotiation and an alternative port could be used to avoid this issue.
* Computers with no RTC (e.g. some ARM boards), or RTC that is too far
from the real time, will fail to verify TLS certificates. An option
could be added to disable the time checks before the first update of
the clock. This would have an impact on security.
== Benefit to Fedora ==
This change enables Fedora users to securely synchronize the system
clock to local or public NTP servers.
TBD: This change also makes the default configuration of the NTP client secure.
== Scope ==
* Proposal owners:
# Update `chrony` to 4.0 and enable the NTS support (adding dependency
on GnuTLS)
# TBD: Modify the default ''/etc/chrony.conf'' to use public servers
with NTS support
# Add an NTS option to the NTP settings in anaconda
* Other developers: N/A (not a System Wide Change)
* Release engineering: N/A (not needed for this Change)
* Policies and guidelines: N/A (not a System Wide Change)
* Trademark approval: N/A (not needed for this Change)
== Upgrade/compatibility impact ==
Fedora systems updated from a previous version will use the new
''/etc/chrony.conf'' automatically if the installed file was not
modified. If it was modified, the users will need to update the file
manually or rename ''/etc/chrony.conf.rpmnew'' to
''/etc/chrony.conf'' in order to enable NTS.
== How To Test ==
If the default configuration is modified for this Change, it needs to
be tested that it works correctly on most systems where the previous
default configuration using pool.ntp.org servers worked.
The installer needs to be tested that it enables NTS in
''/etc/chrony.conf'' as expected and that it adds `PEERNTP=no` to
''/etc/sysconfig/network''.
The `chronyc -N sources` command can be used to verify that NTP
sources are responding. The `chronyc ntpdata` command can be used to
verify that the NTP sources are authenticated. For example:
# chronyc -N sources
MS Name/IP address Stratum Poll Reach LastRx Last sample
===============================================================================
^* time.cloudflare.com 3 6 377 28 -115us[
-111us] +/- 13ms
^+ nts.ntp.se 2 6 377 27 +212us[
+212us] +/- 22ms
# chronyc ntpdata | grep Auth
Authenticated : Yes
Authenticated : Yes
== User Experience ==
Client NTS can be enabled in the NTP settings in the installer.
Client and server NTS can be enabled by editing ''/etc/chrony.conf''
as documented in the `chrony.conf` man page.
== Dependencies ==
N/A (not a System Wide Change)
== Contingency Plan ==
* Contingency mechanism: 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?
== Documentation ==
N/A (not a System Wide Change)
== Release Notes ==
TBD
--
Ben Cotton
He / Him / His
Senior Program Manager, Fedora & CentOS Stream
Red Hat
TZ=America/Indiana/Indianapolis
2 years
