New set of questions for FESCo candidates?
by Zbigniew Jędrzejewski-Szmek
Dear all,
the semiannual exercise is upon us. FESCo candidates must submit an
"interview" in which they answer a set of questions (but can also add whatever they want).
The question whether we should have a new set of questions needs to be answered.
Currently we have the following:
Mandatory Question #1: Describe some of the important technical issues
you foresee affecting the Fedora community. What insight do you bring
to these issues?
Mandatory Question #2: What objectives or goals should FESCo focus on
to help keep Fedora on the cutting edge of open source development?
Mandatory Question #3: What are the areas of the distribution and our
processes that, in your opinion, need improvement the most? Do you
have any ideas how FESCo would be able to help in those "trouble
spots"?
Please answer with any proposals. If there is sufficient support for
change, I'll gather a list and submit this for some kind of poll
(details to be figured out...).
Zbyszek
3 years, 11 months
Call for testers for rpmautospec in staging
by Pierre-Yves Chibon
Good Morning Everyone,
You may remember that Nils, Adam and pingou have been investigating what
it would take to get rid of maintaining the changelog and release fields
manually in our spec files (but still have them in the produced RPMs).
We have already discussed the idea in a few threads:
- https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.o...
announced the original idea
- https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.o...
presented some of the possible approaches to do this
The result of these discussions and our investigations is `rpmautospec`
As its documentation says:
`rpmautospec` is a program and library used to automatically generate the
release and changelog fields in RPM spec files opting to use it.
`rpmautospec` is currently a proof of concept, we have deployed it in staging
and with this email we would like to invite you to test it there.
We have written some documentation on how `rpmautospec` works and how you
can opt in at: https://docs.pagure.org/Fedora-Infra.rpmautospec/
To interact with staging you will need:
- to use `stg-koji` instead of `koji`
- to use `fedpkg-stage` instead of `fedpkg` (``dnf install fedpkg-stage``)
- to kinit against `STG.FEDORAPROJECT.ORG`
- to test with rawhide as rpmautospec is only available there in staging at this
point
To remove some of the warnings thrown by `fedpkg` or to simply keep `rpmbuild`
working locally, you will have to install the `rpmautospec-rpm-macros` package
available in your nearest bodhi (it's still hot from the oven at the time of
writing this email so it hasn't made it yet to updates-testing).
Note, this task was very much time-bound for us and we reached this limit, so
this is not something that we will be heavily working on in the coming 3 months.
However, if there are sufficient people testing this in staging, providing
feedback or contributing to it, we may (depending on that feedback) look at
pushing this project forward later in the year.
Finally, while we've tried to be careful, we're sure that we've missed some
use cases and that this software isn't bug free, so please bear with us if
some of its edges are rough and report your issues/RFEs at:
https://pagure.io/Fedora-Infra/rpmautospec/
Thanks in advance for your help and feedback,
Adam, Nils and Pierre
PS:
- F32 update: https://bodhi.fedoraproject.org/updates/FEDORA-2020-7f41380eb9
- F31 update: https://bodhi.fedoraproject.org/updates/FEDORA-2020-3ee46bf2cd
- F30 update: https://bodhi.fedoraproject.org/updates/FEDORA-2020-081a876918
_______________________________________________
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, 12 months
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
3 years, 12 months
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>
3 years, 12 months
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
4 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
4 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
4 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
4 years
