Fedora 35 Change: PHP 8.0 (Self-Contained Change proposal)
by Ben Cotton
https://fedoraproject.org/wiki/Changes/php80
== Summary ==
Update the PHP stack in Fedora to latest version 8.0.x
== Owner ==
* Name: [[User:Remi| Remi Collet]] and [[SIGs/PHP|PHP SIG]]
* Email: remi at fedoraproject dot org
== Detailed Description ==
Update the PHP stack in Fedora to latest version 8.0.x.
* Despiste PHP 8.0 schedule was compatible with Fedora 34 one, we choose to
skip 1 cycle to give more time for projects to adapt to this new major
version
* At Fedora 35 time, PHP 7.3 will be EOL, 7.4 on security mode so 8.0 the
only version with active support, see [
https://www.php.net/supported-versions.php PHP supported version]
* 8.1 is planed for end of year and will be a Fedora 36 feature
Dropped unmaintained extensions (available on PECL if needed):
* xmlrpc
== Benefit to Fedora ==
Provides the latest PHP version to developers and system administrators.
== Scope ==
* Proposal owners: Check Koschei status. Test with latest version to ensure
compatibility. Work with upstream on bug fixing. Needed mass rebuild (C
extensions) done by change owner.
* Other developers: N/A (not a System Wide Change)
*
[[Fedora_Program_Management/ReleaseBlocking/Fedora{{FedoraVersionNumber|next}}|List
of deliverables]]: N/A (not a System Wide Change)
* Policies and guidelines: N/A (not a System Wide Change)
* Trademark approval: N/A (not needed for this Change)
== How To Test ==
* The PHP stack (extensions and libraries) are monitored by Koschei, see
the [
https://apps.fedoraproject.org/koschei/groups/php?order_by=state%2C-started
Koschei PHP group]
* install and play with your web applications
== User Experience ==
Developers and system administrators will have the great benefit or running
the latest PHP version.
== Dependencies ==
All php-* packages (and some *-php)
== Contingency Plan ==
* Contingency mechanism: Drop not compatible packages.
* Contingency deadline: N/A (not a System Wide Change)
* Blocks release? N/A (not a System Wide Change)
* Blocks product? product
== Documentation ==
* [https://www.php.net/ChangeLog-8.php#PHP_8_0 CHANGELOG]
* [https://www.php.net/manual/en/migration80.php Migrating from PHP 7.4.x
to PHP 8.0.x]
* [https://www.php.net/releases/8.0/en.php PHP 8 released] (new features
announcement)
* [https://raw.githubusercontent.com/php/php-src/PHP-8.0/UPGRADING
UPGRADING]
* [https://raw.githubusercontent.com/php/php-src/PHP-8.0/UPGRADING.INTERNALS
UPGRADING.INTERNALS]
== Release Notes ==
--
Ben Cotton
He / Him / His
Senior Program Manager, Fedora & CentOS Stream
Red Hat
TZ=America/Indiana/Indianapolis
2 years, 10 months
Mass spec file change: Adding BuildRequires: make
by Tom Stellard
Hi,
As part of the f34 change request[1] for removing make from the
buildroot, I will be doing a mass update of packages[2] to add
BuildRequires: make where it is needed.
If you are a package maintainer and would prefer to update your packages
on your own, please do so before Dec 14, which is when I will begin
doing the mass update.
I will be doing the updates in batches, so that if there is a mistake
the impact will be limited. Here is the rough schedule of the changes:
Dec 14: Update first 50 packages.
Dec 16: Next 1000.
Dec 18: Next 1000.
Jan 4: Next 1000.
Jan 5: Next 1000.
Jan 6: Next 1000.
Jan 7: Next 1000.
Jan 8: Rest of packages.
The deadline for completing these updates is the start of the f34 mass
rebuild (Jan 20).
Thanks,
Tom
[1] https://fedoraproject.org/wiki/Changes/Remove_make_from_BuildRoot
[2] https://fedorapeople.org/~tstellar/needs_br_make_packages.txt
2 years, 10 months
HOWTO: Change default branch on pagure.io projects
by Kevin Fenzi
Per https://fedoraproject.org/wiki/Changes/GitRepos-master-to-main#Phase0_-_2...
here's a short guide for any interested folks on how to change the
default branch in pagure.io projects:
Switching default branch from ‘master’ to ‘main’ on pagure.io
If you have an existing project using ‘master’ as it’s default branch:
git clone ssh://git@pagure.io/YOURPROJECT.git
(This checks out your repo with it’s current ‘master’ branch)
git checkout -b main
(This creates a local ‘main’ branch)
git push
(This pushes the new ‘main’ branch to pagure.io)
Go to your project, Settings, “Default Branch”, set to ‘main’, click “Make Default”
(This switches the ‘default’ branch you get if you do not specify one)
git push origin :master
(This deletes the old ‘master’ branch)
If you have are just creating a new project:
When creating the project specify ‘main’ as the default branch.
(This will be changed soon to default that way)
Q&A:
Q: What happens to pull-requests that are against the old ‘main’ branch?
A: They will show an error, you will need to get the submitter to open a new pull-request
against the new branch name (we will be fixing pagure so it allows updating the
target branch of a PR in the (near) future)
Q: I want to call the default branch something else, do I have to use ‘main’?
A: main is becoming a industry wide name, so people are going to expect it.
That said, it's your project and you can name it anything you like.
Q: What happens to Documentation/Issues/Pull Requests repos associated to the projects?
A: We are not changing anything on theses repos for now, we will update you when we change
the default branch on these repos.
Q: What happens to users who have a checkout of the old default branch?
A: If they do a 'git pull' they will get:
* [new branch] main -> origin/main
Your configuration specifies to merge with the ref 'refs/heads/master'
from the remote, but no such ref was fetched.
They need to do 'git checkout main' and pull will work fine again.
As a reminder, on 2021-01-06 (tomorrow), we will be changing the following pagure.io
repos to use 'main' as default branch:
pagure.io:
releng
releng/*
fedora-comps
fedora-kickstarts
fedora-infrastructure
fedora-lorax-templates
fedora-mediawikitheme
fedora-packager
fedora-infra/*
infra-docs
koji-fedmsg-plugin
workstation-ostree-config
pungi-fedora
fedora-docs/*
fedora-docs-i18n/*
See https://fedoraproject.org/wiki/Changes/GitRepos-master-to-main
for more information.
kevin
2 years, 11 months
Fedora 34 Change: Signed RPM Contents (late System-Wide Change)
by Ben Cotton
https://fedoraproject.org/wiki/Changes/Signed_RPM_Contents
Note that this change was submitted after the deadline, but since it can be
shipped in an complete state, I am still processing it for Fedora 34.
== Summary ==
We want to add signatures to individual files that are part of shipped RPMs.
These signatures will use the Linux IMA (Integrity Measurement
Architecture) scheme, which means they can be used to enforce runtime
policies to ensure execution of only trusted files.
== Owner ==
* Name: [[User:Puiterwijk| Patrick Uiterwijk]]
* Email: puiterwijk(a)redhat.com
* Name: [[User:Pbrobinson| Peter Robinson]]
* Email: pbrobinson(a)gmail.com
== Detailed Description ==
During signing builds, the files in it will be signed with IMA signatures..
These signatures will be made with a key that’s kept by the Fedora
Infrastructure team, and installed on the sign vaults.
== Benefit to Fedora ==
Having all files signed with a verifiable key means that system owners can
use the kernel Integrity and Measurement Architecture (IMA) to enforce only
verified files can be executed, or define other policies.
== Scope ==
* Proposal owners:
The proposal owners will write the code for sigul to pass the required
arguments, generate the keys in Infrastructure and get them deployed to the
sign vaults.
* Other developers:
Nothing needed from other developers
* Release engineering:
A mass rebuild would be nice (as it ensures all packages are signed), but
is not required to implement the change itself.
* Policies and guidelines:
No impact
* Trademark approval:
No impact
* Alignment with Objectives:
This aligns with the Internet of Things objective.
== Upgrade/compatibility impact ==
For standard Fedora users there will be no impact. If an advanced user was
already signing their own files (for the Fedora shipped RPMs) for IMA
functionality, they will just overwrite the existing signature.
== How To Test ==
The signatures can be tested “in vitro” by running `evmctl ima_verify
--sigfile --key publiccert.der -v myfile.txt`.
This should result in the system reporting “<filename>: verification is OK”.
The full system could be tested by enrolling the Fedora IMA key to the
kernel `_ima` keyring, and adding a policy that verifies (some) files to be
verified against the key. (instructions to follow).
== User Experience ==
If the user deploys an IMA policy to verify all or some files, they should
be able to trust the signatures made by the Fedora build system.
== Dependencies ==
No external package dependencies.
== Contingency Plan ==
* Contingency mechanism: If the change is not finished in time, we have
probably not yet started signing new files. Signing can easily be disabled
by updating the config file should issues arise.
If we did start signing, but haven’t signed everything, that is okay, since
then packages will get signed as they’re bumped by developers, and they’ll
be all signed in the next major release.
* Contingency deadline: We could ship with this feature in an unfinished
state.
* Blocks release? No
* Blocks product? N/A
== Documentation ==
Documentation to follow.
--
Ben Cotton
He / Him / His
Senior Program Manager, Fedora & CentOS Stream
Red Hat
TZ=America/Indiana/Indianapolis
2 years, 11 months
List of long term FTBFS packages to be retired in February
by Miro Hrončok
Dear maintainers.
Based on the current fail to build from source policy, the following packages
will be retired from Fedora 34 approximately one week before branching (February
2021).
Policy:
https://docs.fedoraproject.org/en-US/fesco/Fails_to_build_from_source_Fai...
Note that some listed packages are orphaned and hence may be retired even sooner.
The packages in rawhide were not successfully built at least since Fedora 32.
This report is based on dist tags.
Packages collected via:
https://github.com/hroncok/fedora-report-ftbfs-retirements/blob/master/ft...
If you see a package that was built, please let me know.
If you see a package that should be exempted from the process, please let me
know and we can work together to get a FESCo approval for that.
If you see a package that can be rebuilt, please do so.
Package (co)maintainers Latest build
============================================================================
VirtualGL gsgatlin Fedora 31
boo elsupergomez, orphan, tpokorra Fedora 31
sugar-flipsticks callkalpa, chimosky, pbrobinson, tuxbrewr Fedora 31
sugar-getiabooks callkalpa, chimosky, pbrobinson, tuxbrewr Fedora 31
sugar-infoslicer callkalpa, chimosky, pbrobinson, tuxbrewr Fedora 31
sugar-labyrinth callkalpa, chimosky, pbrobinson Fedora 31
sugar-ruler callkalpa, chimosky Fedora 31
sugar-starchart callkalpa, chimosky, orphan Fedora 31
sugar-view-slides callkalpa, chimosky, pbrobinson, tuxbrewr Fedora 31
No packages require above mentioned packages.
Affected (co)maintainers
callkalpa: sugar-labyrinth, sugar-starchart, sugar-ruler, sugar-getiabooks,
sugar-infoslicer, sugar-view-slides, sugar-flipsticks
chimosky: sugar-labyrinth, sugar-starchart, sugar-ruler, sugar-getiabooks,
sugar-infoslicer, sugar-view-slides, sugar-flipsticks
elsupergomez: boo
gsgatlin: VirtualGL
pbrobinson: sugar-labyrinth, sugar-getiabooks, sugar-infoslicer,
sugar-view-slides, sugar-flipsticks
tpokorra: boo
tuxbrewr: sugar-getiabooks, sugar-infoslicer, sugar-view-slides, sugar-flipsticks
2 years, 11 months
Fedora 34 Change: Localization measurement and tooling
(Self-Contained Change proposal)
by Ben Cotton
https://fedoraproject.org/wiki/Changes/LocalizationMeasurementAndTooling
== Summary ==
Provide a public website for end users and contributors, containing
Fedora Workstation translation progress and useful files for
translators (as an example: translation memories).
== Owner ==
* Name: [[User:jibecfed|Jean-Baptiste Holcroft]],
[[User:darknao|Francois Andrieu]]
* Email: <jean-baptiste(a)holcroft.fr>
== Detailed Description ==
Language support is a transversal activity, there is no way to know
the actual language support provided by Fedora as an Operating System.
Because language support and translations are part of each upstream
software, the Linux language community is as spread as the Free Libre
and Open Source community is.
The ability to share efforts is limited (with data, tools, etc.):
* because of the complexity to get an overview of the current
localization status of the Linux community,
* because translators often have a low level of technical knowledge,
* because development experts are more keen to use English by default,
and don't know much about languages support requirements.
Debian did something similar (20 years ago)
https://www.debian.org/international/l10n/ . But this work:
* is limited in terms of features (no translation memories there)
* is too deeply integrated with Debian infrastructure (data
extraction, computation and website generation are 100% debian
specific)
* is using a programming language that doesn't allow to share easily
with existing i18n/l10n libraries (it did not exist 20 years ago)
== Benefit to Fedora ==
It is a progress for the project: provide a new tool to translator community.
It helps the Linux community to better understand the language support
challenges.
It increases contributors effectiveness by providing translation
memories and other tools.
These translation memories open new possibilities:
* to train machines to suggest new translations?
* to detect quality issues (spellcheck, linters, etc)?
* the change the way we ship translations to users? (Ubuntu does it,
but never bring back translation to main project)
* to advertise user that Linux is available in many languages?
== Scope ==
All of the work is isolated, as long as dnf works, the automation
works. The closer to mirror the cheaper it is for network cost (all
Fedora is downloaded at each execution).
* Proposal owners:
** [[User:Darknao|Francois Andrieu]] integrate the existing scripts
into containers to allow execution into openshift
** Infra team:
*** provide some space for script execution (50 GB per release)
*** provide the languages.fedoraproject.org domain name
*** provide a location for static website (about 2 GB per release, may
increase over time)
* 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)
* Alignment with mission: ''In our community, contributors of all
kinds come together to advance the ecosystem for the benefit of
everyone.''
== Upgrade/compatibility impact ==
N/A (not a System Wide Change)
== How To Test ==
N/A (not a System Wide Change)
== User Experience ==
== 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)
== Documentation ==
A draft with simplistic template is there:
https://jibecfed.fedorapeople.org/partage/fedora-localization-statistics/...
Code and "documentation" are there:
https://pagure.io/fedora-localization-statistics
About other project:
* Debian's code to build website with language progress:
https://salsa.debian.org/webmaster-team/webwml/-/commits/master/english/i...
* Ubuntu's code to build langpacks:
https://bazaar.launchpad.net/~ubuntu-langpack/langpack-o-matic/main/files
** Note: ubuntu does provide language progress in launchpad:
https://translations.launchpad.net/ubuntu and some useful
documentation is there: https://dev.launchpad.net/Translations
--
Ben Cotton
He / Him / His
Senior Program Manager, Fedora & CentOS Stream
Red Hat
TZ=America/Indiana/Indianapolis
2 years, 11 months
Fedora 34 Change: LXQt 0.16.0 (Self-Contained Change proposal)
by Ben Cotton
https://fedoraproject.org/wiki/Changes/LXQt_0.16.0
== Summary ==
Update LXQt to 0.16.0 in Fedora.
== Owner ==
* Name: [[User:Zsun|Zamir SUN]]
* Email: zsun#AT#fedoraproject.org <!--- bugzilla account : sztsian #
gmail.com -->
== Detailed Description ==
LXQt just released with a bunch of bugfixes. It's always good to keep
Fedora users running on most recent software.
Detailed LXQt release note is available
[https://lxqt-project.org/release/2020/11/05/lxqt-0-16-0/ here].
== Benefit to Fedora ==
This change brings bug fixes and enhancements to LXQt in Fedora.
== Scope ==
* Proposal owners:
1. Update all the LXQt related packages in Fedora.
2. Replace ark with lxqt-archiver in the package group.
* Other developers: N/A (not a System Wide Change)
* Release engineering: [https://pagure.io/releng/issue/9926 #9926]
* 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 using the spin, netinstall or DVD. Or upgrade from older
release. Then users should be able to test by doing any daily work.
== User Experience ==
Users of live media will now see lxqt-archiver instead of ark as the
default compress/decompress tool. For all users there will be a better
user experience and some more alternative themes available to choose
from.
== Dependencies ==
This update is pretty self contained and has been mostly finished in Rawhide.
== Contingency Plan ==
* Contingency mechanism: N/A. This is almost done in rawhide so the
remaining things are more about bug fixing.
* Contingency deadline: Fedora 34 Beta Freezee? N/A (not a System Wide Change)
* Blocks product? N/A
== Documentation ==
N/A (not a System Wide Change)
--
Ben Cotton
He / Him / His
Senior Program Manager, Fedora & CentOS Stream
Red Hat
TZ=America/Indiana/Indianapolis
2 years, 11 months
