https://fedoraproject.org/wiki/Changes/fedora-change-wrangler
= Track Changes in Taiga =
The Motivation for this proposal is to propose using the Taiga
instance at teams.fedoraproject.org for Change processing.
[[User:Bcotton/UsePagureForChanges|Using Pagure]] was previously
proposed for this. The new Change Processing workflow aims to simplify
the process to improve visibility and ease of management.
== Summary ==
The current process allows contributors to propose changes in upcoming
Fedora releases. However, the management of those feature proposals is
cumbersome and requires several manual steps. This introduces more
opportunity for error and reduces the time available to the Change
Wrangler for more valuable contributions to Fedora. In particular, the
current process includes artifacts and discussion in the Fedora Wiki,
on mailing lists, FESCo tickets, Bugzilla tickets, and Docs tickets.
The current process is cumbersome with several manual steps,this
introduces more opportunity for error and reduces the time available
for the Change Wrangler.
A Cli Tool Written in Python that interacts with Taiga,Pagure and
Bugzilla.Functionality includes
Promoting,announcing,submitting,accepting and updating the changes
across the three platforms and over mailing list.
The new process will consolidate much of the information in
Taiga.Proposed Changes will be submitted as an issue in Taiga. The
description of the Issue will include the content with few exceptions:
* System-Wide or Self-Contained change will be indicated by a binary
in the issue metadata
* Fedora release will be indicated by a milestone in the issue metadata
* Change status will be indicated by a list selection in the issue metadata
== Owner ==
* Name: [[User:Pac23| Manas Mangaonkar]]
* Email: manasmangaonkar(a)gmail.com || pac23(a)fedoraproject.org
* Name: [[User:Bcotton | Ben Cotton]]
* Email: bcotton(a)redhat.com
== Detailed Description ==
As Part of GSoC 2019 the fedora-change-wrangler tool will be developed
to smooth out the workflow,reduce Manual Work involved for both the
Contributors and the Change-Wrangler(FPgm). The tool makes it easy by
covering all the functionality required for the process of moving
forward proposals.
The tool will be developed using Python 3.6+ and will interact with
Taiga/Pagure/Bugzilla via their API and the Mailing List via SMTP.
The General Workflow would be :
1. Change Owner opens an issue and fills in the fields. When they are
ready to submit the Change proposal, they set the status to "Ready
for Wrangler".
2. The Change Wrangler (FPgM) reviews the proposal. If it is
incomplete, they set the status back to "New" and inform the Change
Owner of what's needed. If it is ready to process, then...
Functionality covered
1. Promote
* The issue will be promoted to a user story in taiga,copies the
contents of the custom fields from the issue to the user story. Closes
the issue.
2. Announce
* The tool would have the functionality to enable announcing the
change proposal to devel and devel-announce lists using smtp. It will
also automatically change the story status to announced.
3. fesco-submit
* Allowing creation of a new issue in the FESco Pagure repo directly
from the command line.
4. Accept
* Once the changes are accepted the change-wrangler can create a
tracking bug in Bugzilla along with release notes on Pagure.THe status
of the user story is updated to accepted aswell.
5. Update
* Status can be changed to testable if BZ is "Modified" and to
Complete is BZ is "ON_QA"
6. Creation of Report
* The user can create a report to provide quick view of changes and
their status. It can be in wiki or Html form.
Techstack:
* Python3.6+
* SMTP
* Taiga/Pagure/Bugzilla API's
* Nano/Gedit/Vi ( Inbuilt support to edit text)
* Kerberos(For authentication)
The current sample arg created looks like this [ change-tool convert
--taiga <issue no> <issue no> ] . The advantage of this the Manager
would be able to specify unlimited no of issues to change at once in a
single command using the issue no in taiga to convert to user story.
== Benefit to Fedora ==
The proposed change will make the change-process easier for
everyone.Everyone would be able to see them in one place with
status,id filters. The current wiki process can be bit difficult for
formatting,having defined fields would mean easy access without the
cumbersome wiki edits.
Since changes would be submitted in Issue format on
Taiga,pre-submission discussions would be available thus getting
suggestions/feedback at the first stage itself would be easy for
everyone involved.
== Scope ==
* Proposal owners:
I will be working with the Change-Wrangler(Ben Cotton) throughout the
summer to create this tool from scratch.
* Other developers: N/A (not a System Wide Change)
* Release engineering:(no release engineering impact is expected)
* Trademark approval: N/A (not needed for this Change)
== Upgrade/compatibility impact ==
N/A (not a System Wide Change)
== How To Test ==
N/A (not a System Wide Change)
== User Experience ==
No visible Impact is expected.
== Dependencies ==
No other packages depend on this.
== Contingency Plan ==
* Contingency mechanism: (What to do? Who will do it?) N/A (not a
System Wide Change)
Enough buffer time has been allocated to complete this during the GSoC period.
--
Ben Cotton
He / Him / His
Fedora Program Manager
Red Hat
TZ=America/Indiana/Indianapolis
Hi everyone!
I'm starting a Minimization Objective [1] focusing on minimising the
installation size of some of the popular apps, runtimes, and other pieces
of software in Fedora.
And there is a new Minimization Team [2] forming. Members of the team will
consult and work with Fedora maintainers, develop tooling and services,
generate reports showing the status of the Fedora ecosystem and a
comparison with other ecosystems, etc. The goal is to build an environment
where it's easy for our maintainers to keep things small over time, it's
not just a one-off effort. Please see the Action Plan [3] for more details.
Want to become a member? Let me know!
Cheers!
Adam
[1] https://docs.fedoraproject.org/en-US/minimization/
[2] https://docs.fedoraproject.org/en-US/minimization/team/
[3] https://docs.fedoraproject.org/en-US/minimization/action-plan/
--
Adam Šamalík
---------------------------
Senior Software Engineer
Red Hat
https://fedoraproject.org/wiki/Changes/EnableSysctlPingGroupRange
(Note this change proposal was originally submitted before the
deadline, but was delayed due to some discussion between the change
owner and change wrangler)
== Summary ==
Enable the Linux kernel's <code>net.ipv4.ping_group_range</code>
parameter to cover all groups.
== Owner ==
* Name: [[User:rishi|Debarshi Ray]]
* Email: debarshir(a)redhat.com
== Detailed Description ==
Enable the Linux kernel's <code>net.ipv4.ping_group_range</code>
parameter to cover all groups. This will let all users on the
operating system create ICMP Echo sockets without using setuid
binaries, or having the <code>CAP_NET_ADMIN</code> and
<code>CAP_NET_RAW</code> file capabilities.
== Benefit to Fedora ==
This makes <code>ping</code> work inside rootless [https://podman.io/
Podman] containers. Currently it doesn't.
When the Linux kernel's <code>net.ipv4.ping_group_range</code>
parameter is enabled for a group, users in that group can send ICMP
Echo packets without using setuid binaries, or having the
<code>CAP_NET_ADMIN</code> and <code>CAP_NET_RAW</code> file
capabilities. This works by using
[http://man7.org/linux/man-pages/man7/icmp.7.html ICMP Echo] sockets
instead of the more generic, and easier to abuse,
[http://man7.org/linux/man-pages/man7/raw.7.html raw] sockets. For
Fedora, this means that the file capabilities can be removed from the
<code>ping</code> binary.
This is good for OSTree based Fedora variants like Silverblue, where
development environments are often set up using rootless Podman
containers with helpers like [https://github.com/debarshiray/toolbox
Toolbox]. At present, <code>ping</code> doesn't work in those
environments, and it's inconvenient to not be able to use such a basic
network utility inside a development set-up.
== Scope ==
* Proposal owners: Enable <code>net.ipv4.ping_group_range</code> by
adding it to one of the files shipped by the sytemd RPM in
<code>/usr/lib/sysctl.d</code> or by creating a new file shipped by
the podman or toolbox RPMs.
[https://github.com/systemd/systemd/pull/13141 Here] is an upstream
pull request against systemd.
* Other developers: Once this change is in place, the file
capabilities should be removed from the <code>ping</code> binary
because they would no longer be necessary. However, it's not a
requirement for implementing this change.
* Release engineering: N/A (not needed for this Change)
* Policies and guidelines: N/A (not needed for this Change)
* Trademark approval: N/A (not needed for this Change)
== Upgrade/compatibility impact ==
Systems with a previous version of Fedora won't need manual
intervention. They will inherit this change when updated.
== How To Test ==
On a Fedora system containing this change, the following commands should work:
<pre>
$ podman run -it --rm registry.fedoraproject.org/fedora:latest
...
# dnf -y install iputils
...
# ping fedoraproject.org
...
</pre>
== User Experience ==
Users of rootless Podman, including those developing on Silverblue
inside Toolbox containers, would now be able to use <code>ping</code>.
Earlier, they weren't able to.
== Dependencies ==
N/A (not needed for this Change)
== Contingency Plan ==
* Contingency mechanism: If <code>net.ipv4.ping_group_range</code>
isn't enabled then status quo will be maintained. No explicit action
needs to be taken. Note that the <code>ping</code> binary should not
be touched until this change is complete. Only then should be the file
capabilities removed.
* Contingency deadline: N/A (not needed for this Change)
* Blocks release? No
* Blocks product? No
== Documentation ==
There's no upstream documentation. There's some discussion on
[https://github.com/systemd/systemd/pull/13141 this] systemd pull
request.
--
Ben Cotton
He / Him / His
Fedora Program Manager
Red Hat
TZ=America/Indiana/Indianapolis
Good Morning Everyone,
TL;DR: On July 24th we will turn on the first phase of Rawhide package gating,
for single build updates.
In a later phase, Rawhide updates that contain multiple builds will also be
enabled for gating. Our goal is to improve our ability to continuously turn out
a useful Fedora OS. So we hope and expect to get opt-in from as many Fedora
package maintainers as possible, including maintainers of the base OS. But this
phase of gating remains opt-in, and should not affect packagers who choose for
now not to opt in.
Last April FESCo approved a change proposal[1] allowing to gate Rawhide packages
based on test results. The proposal included gating updates with only a single
build as well as updates with multiple builds. It was designed to cause minimal
to no interference with the current workflow of packagers who do not opt-in.
The team has been working hard on this proposal, and decided to do a phased
roll-out of this change, so that we can gather feedback as early as possible
from the packagers interested in testing this workflow without impacting
everyone.
On July 24th, we plan to turn on the first phase of this change.
What does it mean for us as packagers?
--------------------------------------
When you run `fedpkg build` on Rawhide, your package will be built in a new koji
tag (which will be the default target for Rawhide). The package will be picked
up from this koji tag, signed and moved onto a second tag. Bodhi will be
notified by koji once this new build is signed and will automatically create an
update for it (you will be notified about this by email by bodhi directly) with
a “Testing” status. If the package maintainer has not opted in into the CI
workflow, the update will be pushed to “Stable” and the build will be pushed
into the regular Rawhide tag, making it available in the Rawhide buildroot, just
as it is today.
If the package maintainer has opted in into the CI workflow, the creation of the
update will trigger the CI pipeline which will send its results to resultsdb,
triggering greenwave to evaluate if all the required tests have passed or not,
thus allowing the update to go through the gate or not.
This is the first roll-out of this gating change, and so there may be additional
tuning and fixes until things are as smooth as we want them to be. With this
release we are looking for feedback on what can be improved. We have a dedicated
team working on this project and we will be taking your feedback into account to
improve the experience.
Small FAQ:
--------------
But I do not want to use gating!
While we believe CI and gating will ultimately help making a better Fedora,
there is nothing enforced at this point. Keep packaging as you do now!
How do I enroll?
Great! We’re glad to see such enthusiasm! You can find the instruction in the
docs on how to enable gating: https://docs.fedoraproject.org/en-US/ci/gating/
It does not work!
Bugs will be bugs. This is the first roll-out of this change, and more will
come. This rollout lets us gather feedback and iterate on the approach in an
open source fashion.
If you did not opt-in and you can’t do your packaging work as you used to,
please file a infrastructure ticket, since it’s likely a bug:
https://pagure.io/fedora-infrastructure/new_issue?title=[CI]
If you did opt-in and something in the gating of your update doesn’t work (for
example, CI ran but its results aren’t being considered, waiving didn’t work…),
file an infrastructure ticket:
https://pagure.io/fedora-infrastructure/new_issue?title=[CI]
If you opted-in and the tests don’t run the way you expect, file a fedora-ci
ticket: https://pagure.io/fedora-ci/general/new_issue
I enrolled but now I want to step out for some reasons
:sad trombone:
We hope you reported all the issues you’ve found/faced and are helping us
resolving them.
In the meanwhile, you can simply remove the gating.yaml file you’ve added in
your git repo and that should be enough to make greenwave ignore your package.
Want to know more? Your question isn’t here? Check our documentation on
rawhide gating: https://docs.fedoraproject.org/en-US/rawhide-gating/ [2]
We’ll keep it up to date as we face or solve questions.
Pierre
For the Rawhide package gating team
[1] https://pagure.io/fesco/issue/2102
[2] At the time of writing this, it looks like the website is having some
difficulties build the new version of the docs. This should get resolved in the
coming hours, sorry for the inconvenience.
(If only it had CI... :-))
https://fedoraproject.org/wiki/Changes/F31Boost170
== Summary ==
This change brings Boost 1.70 to Fedora. This will mean Fedora ships
with a recent upstream Boost release.
== Owner ==
* Name: [[User:jwakely| Jonathan Wakely]]
* Email: jwakely(a)redhat.com
== Detailed Description ==
The aim is to synchronize Fedora with the most recent Boost release.
Because ABI stability is one of explicit Boost non-goals, this entails
rebuilding of all dependent packages. This has also always entailed
yours truly assisting maintainers of client packages in decoding
cryptic boost-ese seen in output from g++. Such care is to be expected
this time around as well.
The equivalent changes for previous releases were
[[Changes/F30Boost169|Fedora 30 Change]], [[Changes/F29Boost167|Fedora
29 Change]], [[Changes/F28Boost166|Fedora 28 Change]],
[[Changes/F27Boost164|Fedora 27 Change]], [[Changes/F26Boost163|Fedora
26 Change]], [[Changes/F25Boost161|Fedora 25 Change]],
[[Changes/F24Boost160|Fedora 24 Change]],
[[Changes/F23Boost159|Fedora 23 Change]] and
[[Changes/F22Boost158|Fedora 22 Change]].
== Benefit to Fedora ==
Fedora 30 includes Boost 1.69, but the latest upstream release, Boost
1.70, was released on April 12th, 2019.
Fedora will stay relevant, as far as Boost clients are concerned.
Boost 1.70 brings two new components:
* [https://www.boost.org/libs/outcome/ Boost.Outcome], A set of tools
for reporting and handling function failures in contexts where
<i>directly</i> using C++ exception handling is unsuitable, from Niall
Douglas.
* [https://www.boost.org/libs/histogram/ Boost.Histogram], Fast and
extensible multi-dimensional histograms with convenient interface for
C++14, from Hans Dembinski.
== Scope ==
* Proposal owners:
** Build will be done with Boost.Build v2 (which is the
upstream-sanctioned way of building Boost)
** Request a "f31-boost"
[https://docs.pagure.org/releng/sop_adding_side_build_targets.html
build system tag]
([http://lists.fedoraproject.org/pipermail/devel/2011-November/159908.html
discussion]): https://pagure.io/releng/issue/8061
** Build boost into that tag (take a look at the
[http://koji.fedoraproject.org/koji/buildinfo?buildID=606493 build
#606493] for inspiration)
** Post a request for rebuilds to fedora-devel
** Work on rebuilding dependent packages in the tag.
** When most is done, re-tag all the packages to rawhide
** Watch fedora-devel and assist in rebuilding broken Boost clients
(by fixing the client, or Boost).
* Other developers:
** Those who depend on Boost DSOs will have to rebuild their packages.
Feature owners will alleviate some of this work as indicated above,
and will assist those whose packages fail to build in debugging them.
* Release engineering: [https://pagure.io/releng/issue/8500] (a check
of an impact with Release Engineering is needed)
* Policies and guidelines:
** Apart from scope, this is business as usual, so no new policies, no
new guidelines.
* Trademark approval: N/A (not needed for this Change)
== Upgrade/compatibility impact ==
* No impact on system upgrade (no removed subpackages this time).
* No manual configuration or data migration needed.
* Some impact on other packages needing code changes to rebuild.
Historically this hasn't been too big of a problem and could always be
resolved before deadline.
== How To Test ==
* No special hardware is needed.
* Integration testing simply consists of installing Boost packages
(<code>dnf install boost</code>) on Fedora and checking that it does
not break other packages (see below for a way to obtain a list of
boost clients).
== User Experience ==
* Expected to remain largely the same.
* Developers building third-party software on Fedora may need to
rebuild against the new Boost packages, and may need to adjust their
code if the new Boost release is not source-compatible.
== Dependencies ==
Packages that must be rebuilt:
<code>$ dnf repoquery -s --releasever=rawhide --whatrequires
libboost\* --disablerepo=* --enablerepo=fedora | sort -u</code>
All clients:
<code>$ dnf repoquery --releasever=rawhide --archlist=src
--whatrequires boost-devel --disablerepo='*'
--enablerepo=fedora-source</code>
== Contingency Plan ==
* Contingency mechanism: Worst case scenario is to abandon the update
and simply ship F31 with Boost 1.69, which is already in rawhide.
* Contingency deadline: We will know whether the change can be made
once the rebuilds in the side tag are done, which will be July 2019,
ideally before the mass rebuild.
* Blocks release? No
* Blocks product? None
== Documentation ==
* https://www.boost.org/users/history/version_1_70_0.html (released on
12 April 2019)
* https://www.boost.org/development/index.html
== Release Notes ==
Boost has been upgraded to version 1.70. Apart from a number of bug
fixes and improvements to existing libraries, compared to Fedora 30,
this brings:
* New header-only components: [https://www.boost.org/libs/outcome/
Boost.Outcome] and [https://www.boost.org/libs/histogram/
Boost.Histogram]
--
Ben Cotton
He / Him / His
Fedora Program Manager
Red Hat
TZ=America/Indiana/Indianapolis
https://fedoraproject.org/wiki/Changes/AArch64_Xfce_Desktop_image
== Summary ==
Add an AArch64 Xfce Desktop image to deliverables in Fedora 31.
== Owner ==
* Name: [[User:pwhalen| Paul Whalen]]
* Email: pwhalen(a)fedoraproject.org
* Responsible WG: ARM SIG
== Detailed Description ==
We currently offer Workstation, Minimal and Server images for use with
AArch64 Single Board Computer's (SBC's). We would like to add a
lighter weight desktop image for hardware that lacks the ability to
run accelerated desktops.
An initial set of supported devices:
* Pine64
* Raspberry Pi 3/4
* 96boards HiKey
* 96boards Dragonboard 410c
== Benefit to Fedora ==
Better user experience and an additional desktop choice for AArch64 SBC's.
== Scope ==
* Proposal owners: The ARM SIG will make the kickstart changes needed
to add the desktop images to the compose.
* Other developers: N/A
* Release engineering: Enable building of the AArch64 XFCE desktop
image. Small tweaks may be required to the pungi configs or fedora
kickstarts but those will be completed by the SIG and sent as pull
requests. Issue[https://pagure.io/releng/issue/8556 #8556]
* Policies and guidelines: N/A (not needed for this Change)
* Trademark approval: N/A (not needed for this Change)
== Upgrade/compatibility impact ==
No upgrade compatibility required, this is a new image variant.
== How To Test ==
Testing can be completed on any supported AArch64 SBC using the
existing arm-image-installer. Any additional instructions will be
added to the ARM installation documentation.
== User Experience ==
Users will have increased choice in desktop offerings for AArch64
SBC's. Those looking to install a desktop on hardware that lacks an
accelerated graphics driver or lower system specifications will have a
useable option.
== Dependencies ==
N/A (not a System Wide Change)
== Contingency Plan ==
* Contingency mechanism: N/A
* Contingency deadline: N/A
* Blocks release? No
* Blocks product? No
== Documentation ==
All documentation will be added or updated via the ARM Landing Page.
--
Ben Cotton
He / Him / His
Fedora Program Manager
Red Hat
TZ=America/Indiana/Indianapolis
https://fedoraproject.org/wiki/Changes/Anaconda_Reclaim_Disk_Space
== Summary ==
The installer shows the Resize Disk Space dialog to reclaim disk space
for the automatic partitioning in the graphical user interface. The
Anaconda team would like to replace this dialog with a simple list of
predefined choices.
== Owner ==
* Name: [[User:Vponcova| Vendula Poncova]]
* Email: vponcova(a)redhat.com
== Detailed Description ==
The installer shows the Resize Disk Space dialog to reclaim disk space
for the automatic partitioning in the graphical user interface. The
Anaconda team would like to replace this dialog with the following
list of choices:
* Use all disk space
* Use free space available for use
* Replace existing Linux system(s)
* Shrink or remove existing partitions
The first three options will redirect users to the Installation
Summary screen. The automatic partitioning will be configured based on
the selected action.
The last option will redirect users to the Manual Partitioning screen.
Users can shrink or remove existing partitions, automatically create
new partitions and leave the screen.
The Manual Partitioning screen supports all actions of the Resize Disk
Space dialog, so it doesn't make sense to have two user interfaces
with the same functionality.
== Benefit to Fedora ==
Simple predefined choices should improve the user experience for
users, who are not interested in shrinking or removing specific
partitions. Beginners can use all or free disk space without other
interaction. Advanced users can quickly reinstall their systems and
virtual machines.
== Scope ==
* Proposal owners: Implement the new dialog window for the graphical
user interface. The support for the dialog actions is already
implemented for the text user interface and kickstart installations.
It is a very small and isolated change.
* Other developers: 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)
== Upgrade/compatibility impact ==
N/A (not a System Wide Change)
== How To Test ==
N/A (not a System Wide Change)
== User Experience ==
During the Fedora installation, it will be easier to set up the
automatic partitioning in the graphical user interface. Users can
choose with one click to use all disk space, all free space or to
replace existing Linux systems.
These options are supported also in the text user interface and
kickstart files, so users might be already familiar with them.
Advanced users can choose to shrink or remove existing partitions.
They will be redirected to the Manual Partitioning screen, where they
can delete and shrink partitions and automatically generate partitions
for the new installation. However, users have much more flexibility at
this point. They can create a fully customized configuration without
having to revisit the Installation Destination screen.
== Dependencies ==
N/A (not a System Wide Change)
== Contingency Plan ==
* Contingency mechanism: Revert the changes in Anaconda.
* Contingency deadline: Beta Freeze
* Blocks release? No
* Blocks product? No
== Documentation ==
N/A (not a System Wide Change)
--
Ben Cotton
He / Him / His
Fedora Program Manager
Red Hat
TZ=America/Indiana/Indianapolis
https://fedoraproject.org/wiki/Changes/Add_LLD_As_Update_Alternatives_Optio…
== Summary ==
Allow users to optionally use update-alternatives to make /usr/bin/ld
point to /usr/bin/lld.
== Owner ==
* Name: [[User:tstellar| Tom Stellard]]
* Email: <tstellar(a)redhat.com>
== Detailed Description ==
Update the lld package %post and %postun steps to configure the system
so that a user can use the update-alternatives tool to create a
symlink from /usr/bin/ld to /usr/bin/lld. This will effectively allow
lld to act as the system linker and make it easier for users to
integrate lld into their projects. This same functionality is
currently available with one other non-system linker: gold.
I want to be clear that this proposal is not about making lld the
system linker or using lld during brew builds. This is simply about
making it easier for end-users to use lld with their own projects.
== Benefit to Fedora ==
This change will make it much easier for users to try out lld in their
projects. Many build systems and compilers assume that the linker is
/usr/bin/ld, and it is very difficult to seamlessly integrate lld into
existing build systems. With this proposal a user will be able to
easily switch between ld.bfd and lld without having to make any
modifications to their build systems.
== Scope ==
* Proposal owners: tstellar
* Other developers: N/A (not a System Wide Change)
* Release engineering:
* Policies and guidelines: N/A
* Trademark approval: N/A (not needed for this Change)
== Upgrade/compatibility impact ==
N/A (not a System Wide Change)
== How To Test ==
Tests for this change will be added to the lld package's CI tests.
One test will install lld and verify that /usr/bin/ld.bfd is still the
system linker. Another test will use update-alternatives to update
/usr/bin/ld to point to /usr/bin/lld and then it will run /usr/bin/ld
--version to verify that this correctly points to lld and then link a
simple program with it.
== User Experience ==
This will greatly enhance the experience for users who want to use
lld. They will be able to try lld with their projects by simply
running `update-alternatives --set ld /usr/bin/lld` instead of having
to make modifications to existing build systems.
== 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)
* Blocks release? N/A (not a System Wide Change)
* Blocks product? N/A
--
Ben Cotton
He / Him / His
Fedora Program Manager
Red Hat
TZ=America/Indiana/Indianapolis
https://fedoraproject.org/wiki/Changes/DeepinDE_15.11
== Summary ==
Update the Deepin Desktop Environment to 15.11 in Fedora.
== Owner ==
* Name: [[User:Zsun|Zamir SUN]] - main coordinator, packager
* Email: zsun#AT#fedoraproject.org
* [[User:cheeselee|Robin 'cheese' Lee]] - main packager
* Email: cheeselee#AT#fedoraproject.org
== Detailed Description ==
Update Deepin Desktop in Fedora to the newest upstream, which is 15.11.
Deepin Desktop in Fedora 30 is based on 15.9 and the changelog for
15.10 and 15.11 are
* https://www.deepin.org/en/2019/04/28/deepin15-10/
* https://www.deepin.org/en/2019/07/19/deepin15-11/
== Benefit to Fedora ==
Fedora stays in sync with upstream and gets the latest features and bug fixes.
== Scope ==
* Proposal owners: Deepin Desktop 15.11 packages packaged and built in
Fedora 31.
* Other developers: 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)
== Upgrade/compatibility impact ==
No impact should happen to current users except the bugfixes.
== How To Test ==
Install or update your Deepin Desktop on Fedora, make sure that the
desktop and all apps are usable.
== User Experience ==
There are some improvements.
* The default window manager will be changed to deepin-kwin (known as
dde-kwin in Deepin), which consumes less memory and has better
performance
* The deepin-file-manager will support burn ISO to disks.
* The dock - will show the capacity and the remaining time of battery.
== Dependencies ==
N/A (not a System Wide Change)
== Contingency Plan ==
* Contingency mechanism: Not announce the availability of Deepin
Desktop 15.11 in Fedora.
* Contingency deadline: Beta Freeze
* Blocks release? No.
* Blocks product? None.
== Documentation ==
* [https://github.com/FZUG/deepin-desktop The staging git repo of all
spec files].
* [https://www.deepin.org/en/dde/ Deepin Desktop Environment] website.
* [[SIGs/DeepinDE|DeepinDE SIG page]]
--
Ben Cotton
He / Him / His
Fedora Program Manager
Red Hat
TZ=America/Indiana/Indianapolis
https://fedoraproject.org/wiki/Changes/OpenLDAPwithBerkleyDBasModule
== Summary ==
Change the ''openldap-servers'' package so that BDB and HDB backends
are required to be dynamically loaded.
== Owner ==
* Name: [[User:mhonek| Matus Honek]]
* Email: mhonek (at) redhat (dot) com
== Detailed Description ==
So far the BDB and HDB were statically built with the ''slapd'' binary
and merely declaring `database bdb` or `database hdb` would just work.
Change introduces an additional requirement of explicitly declaring to
load the backend's SO file according to the documentation of dynamic
modules. The respective new modules will be shipped similarly to the
rest of the already shipped modules.
This change is directed to conduct a smoother experience before the
backends are removed in a next Fedora release.
== Benefit to Fedora ==
A step on a way to remove unsupported (both by OpenLDAP and BerkleyDB
upstream) piece of software.
== Scope ==
* Proposal owners:
Change the SPEC file accordingly.
* Other developers: N/A
* Policies and guidelines: N/A
* Trademark approval: N/A (not needed for this Change)
== Upgrade/compatibility impact ==
Server using BDB or HDB backends without modified configuration would
fail to start. See ''User Experience'' section for more information.
== How To Test ==
N/A (not a System Wide Change)
== User Experience ==
If a user is using either BDB or HDB they have two options:
* migrate to the fully supported MDB backend (preferred)
* add a `moduleload` configuration declaration (discouraged)
=== Migrating to MDB ===
The steps required to migrate a database are following:
* Stop the slapd server.
* Export data to an LDIF file using ''slapcat''.
* Change the server's configuration replacing the BDB/HDB sections
with its MDB counterparts.
* Import data to a new database from the LDIF file using ''slapadd''.
* Start the slapd server.
=== ModuleLoad the BDB/HDB backend ===
Depending on the configuration style and backend type, user should add
a declaration in order to load the backend library: add option
`moduleload` (slapd.conf(5), section ''GLOBAL CONFIGURATION OPTIONS'')
or attribute `olcModuleLoad` (slapd-config(5), section ''DYNAMIC
MODULE OPTIONS'') with value `back_bdb` and/or `back_hdb`.
== Dependencies ==
None.
== Contingency Plan ==
* Contingency mechanism: Revert the change.
* Contingency deadline: Anytime.
* Blocks release? No.
* Blocks product? None.
== Documentation ==
N/A (not a System Wide Change)
--
Ben Cotton
He / Him / His
Fedora Program Manager
Red Hat
TZ=America/Indiana/Indianapolis
https://fedoraproject.org/wiki/Changes/x86-64_micro-architecture_update
== Summary ==
Fedora currently uses the original K8 micro-architecture (without
3DNow! and other AMD-specific parts) as the baseline for its
<code>x86_64</code> architecture. This baseline dates back to 2003
and has not been updated since. As a result, performance of Fedora is
not as good as it could be on current CPUs.
This change to update the micro-architecture level for the
architecture to something more recent.
== Owner ==
* Name: [[User:fweimer| Florian Weimer]]
* Email: [mailto:fweimer@redhat.com fweimer(a)redhat.com]
== Detailed Description ==
After preliminary discussions with CPU vendors, we propose AVX2 as the
new baseline. AVX2 support was introduced into CPUs from 2013 to
2015. See [https://en.wikipedia.org/wiki/Advanced_Vector_Extensions#CPUs_with_AVX2
CPUs with AVX2].
Along with AVX2, it makes sense to enable certain other CPU features
which are not strictly implied by AVX2, such as CMPXCHG16B, FMA, and
earlier vector extensions such as SSE 4.2. Details are still being
worked out.
A test rebuild of a distribution largely based on Fedora 28 showed
that there is only a small number of build failures due to the
baseline switch. Very few packages are confused about the availability
of the CMPXCHG16B instruction, leading to linking failures related to
<code>-latomic</code>, and there are some hard-coded floating point
results that could change due to vectorization. (The latter is within
bounds of the usual cross-architecture variation for such tests.)
== Benefit to Fedora ==
Fedora will use current CPUs more efficiently, increasing performance
and reducing power consumption.
Moreover, when Fedora is advertised as a distribution by a compute
service provider, users can be certain that their AVX2-optimized
software will run in this environment.
== Scope ==
* Proposal owners: Update the <code>gcc</code> and
<code>redhat-rpm-config</code> package to implement the new compiler
flags. It is expected that the new baseline will be implemented in a
new GCC <code>-march=</code> option for convenience.
* Other developers: Other developers may have to adjust test suites
which expect exact floating point results, and correct linking with
<code>libatomic</code>. They will also have to upgrade their x86-64
machines to something that can execute AVX2 instructions.
* Release engineering: [https://pagure.io/releng/issue/8513 #8513]
** All Fedora builders need to be AVX2-capable.
** Infrastructure ticket:
[https://pagure.io/fedora-infrastructure/issue/7968 #7968]
* Policies and guidelines: No guidelines need to be changed.
* Trademark approval: N/A (not needed for this Change)
== Upgrade/compatibility impact ==
Fedora installations on systems with CPUs which are not able to
execute AVX2 instructions will not be able to upgrade.
== How To Test ==
General system testing will provide test coverage for this change.
== User Experience ==
User should observe improved performance and, likely, battery life.
Developers will benefit from the knowledge that code with AVX2
optimizations will run wherever Fedora runs.
== Dependencies ==
There are no direct dependencies on this change at this time.
== Contingency Plan ==
It is possible to not implement this change, or implement a smaller
subset of it (adopting the CMPXCHG16B instruction only, for example).
* Contingency mechanism: Mass rebuild with different/previous compiler glags.
* Contingency deadline: Final mass rebuild.
* Blocks release? No.
* Blocks product? No.
== Documentation ==
The new micro-architecture baseline and the resulting requirements
need to be documented.
== Release Notes ==
Release notes must mention how users can determine whether their
system supports AVX2 prior to upgrading, for example by running
<code>grep avx2 /proc/cpuinfo</code>.
--
Ben Cotton
He / Him / His
Fedora Program Manager
Red Hat
TZ=America/Indiana/Indianapolis
https://fedoraproject.org/wiki/Changes/Erlang_22
== Summary ==
Update Erlang/OTP to version 22.
== Owner ==
* Name: [[User:Peter|Peter Lemenkov]], [[SIGs/Erlang|Fedora Erlang
SIG]], [[User:bowlofeggs|Randy Barlow]], [[User:jcline|Jeremy Cline]]
* Email: lemenkov(a)gmail.com, erlang(a)lists.fedoraproject.org,
bowlofeggs(a)fedoraproject.org, jcline(a)fedoraproject.org
== Detailed Description ==
Upgrade Erlang to version 22 which brings a lot of changes. Just a few
highlights:
* Better and faster compiler. Faster string operations which Elixir
users will benefit.
* A new experimental low-level socket API.
* Even faster SSL/TLS operations.
* Improved [http://erlang.org/doc/apps/erts/erl_dist_protocol.html
Erlang Distribution Protocol] handling when it comes to a huge
messages (splitting into smaller ones, no longer blocking).
Aside from this, we plan to improve quality of Erlang and related
packages. These are shortcomings we want to address:
* Every daemon written in Erlang has its own logging solution which
doesn't use neither syslog nor Journald. We should start switching
them to Journald.
* We should add ability to use D-Bus via
[https://github.com/lizenn/erlang-dbus erlang-dbus] library.
* Further improve [[User:Peter/Erlang_Packaging_Guidelines|Erlang
Packaging Guidelines]] and promote it as the official guideline.
* Switch to rebar3 as a main build tool.
== Benefit to Fedora ==
Fedora users, both developers and end-users, will have visible
benefits from using Fedora-provided packages. Namely:
* Improved logging, better unified with the rest of system.
== Scope ==
* Proposal owners:
** [https://bugzilla.redhat.com/1683660 Upgrade Erlang to the latest
version (22.0)].
** We must rebuild every package which requires NIF version (listed
below in the [[#Dependencies|Dependencies]] section) against Erlang
22.x.y.
** Every Erlang daemon's systemd unit must require epmd.socket.
** We need to fill new review request for
[https://github.com/travelping/ejournald erlang-ejournald]
*** We have to fill new review request for
[https://github.com/travelping/lager_journald_backend
erlang-lager_journald_backend]
** We need to fill new review request for
[https://github.com/lizenn/erlang-dbus erlang-dbus]
** Upgrade outdated packages:
*** {{package|riak|Riak}}
**** {{package|riak|Riak}} has has been retired. We have to re-add it back.
*** {{package|ejabberd|Ejabberd}}
*** {{package|rabbitmq-server|RabbitMQ}}.
*** {{package|couchdb|CouchDB}}
** {{package|erlang-rebar3|rebar3}}
*** Provide/adjust RPM macros for rebar3.
** Package GDB macros for easier coredump debugging (see also
[https://bugzilla.redhat.com/show_bug.cgi?id=663253 this ticket]).
** Enable Kerberos authentication in {{package|ejabberd|Ejabberd}} (finally).
* Other developers: N/A
* Release engineering: TBA
* Policies and guidelines:
** We should promote officially
[[User:Peter/Erlang_Packaging_Guidelines|Erlang Packaging
Guidelines]].
* Trademark approval: N/A (not needed for this Change)
== Upgrade/compatibility impact ==
* Every Erlang upgrade requires the rebuilding of modules which
contains [http://www.erlang.org/doc/reference_manual/ports.html ports]
or [http://www.erlang.org/doc/tutorial/nif.html NIFs], and we will
rebuild all such modules in Fedora. However if a user has some
additional modules not available in a Fedora repository, then these
modules must be rebuilt manually.
* So-called [http://erlang.org/doc/man/HiPE_app.html HiPE] continues
to deteriorate. In this version it's barely functional and likely is
going to be removed in the next one.
== How To Test ==
* Ensure that high-grade Erlang applications are still working:
{| border="1"
|-
| '''Name''' || '''Tested'''
|-
| {{package|couchdb}} || {{no}}
|-
| {{package|ejabberd}} || {{no}}
|-
| {{package|elixir}} || {{no}}
|-
| {{package|mochiweb}} || {{no}}
|-
| {{package|rabbitmq-server}} || {{no}}
|-
| {{package|riak}} || {{no}} (package was retired :( )
|-
| {{package|wings}} || {{no}}
|}
* Collect feedback from volunteers regarding their experience with
this Erlang/OTP version
== User Experience ==
Users will get more robust, scalable, and fast Erlang applications.
== Dependencies ==
The following packages must be rebuilt:
{| border="1"
|-
| '''Name''' || '''Rebuilt'''
|-
| {{package|couchdb}} || {{no}}
|-
| {{package|erlang-basho_metrics}} || {{no}}
|-
| {{package|erlang-bitcask}} || {{no}}
|-
| {{package|erlang-cache_tab}} || {{no}}
|-
| {{package|erlang-cl}} || {{no}}
|-
| {{package|erlang-ebloom}} || {{no}}
|-
| {{package|erlang-eleveldb}} || {{no}}
|-
| {{package|erlang-emmap}} || {{no}}
|-
| {{package|erlang-erlsyslog}} || {{no}}
|-
| {{package|erlang-esasl}} || {{no}}
|-
| {{package|erlang-esdl}} || {{no}}
|-
| {{package|erlang-esip}} || {{no}}
|-
| {{package|erlang-fast_tls}} || {{no}}
|-
| {{package|erlang-fast_xml}} || {{no}}
|-
| {{package|erlang-fast_yaml}} || {{no}}
|-
| {{package|erlang-hyper}} || {{no}}
|-
| {{package|erlang-iconv}} || {{no}}
|-
| {{package|erlang-jiffy}} || {{no}}
|-
| {{package|erlang-js}} || {{no}}
|-
| {{package|erlang-lfe}} || {{no}}
|-
| {{package|erlang-riak_ensemble}} || {{no}}
|-
| {{package|erlang-sd_notify}} || {{no}}
|-
| {{package|erlang-skerl}} || {{no}}
|-
| {{package|erlang-snappy}} || {{no}}
|-
| {{package|erlang-stringprep}} || {{no}}
|-
| {{package|erlang-xmpp}} || {{no}}
|}
== Contingency Plan ==
* Contingency mechanism: None necessary. Instead of falling back to
the previous version we should fix existing packages in order to help
the Community. We should also monitor upstream development process for
potentially discovered issues and proactively apply patches (as we
already did with [[Features/Erlang_R14|Erlang R14]],
[[Features/Erlang_R15|Erlang R15]], [[Features/Erlang_R16|Erlang
R16]], [[Changes/BetterErlangSupport|Erlang 17]],
[[Changes/Erlang_18|Erlang 18]], [[Changes/Erlang_19|Erlang 19]],
[[Changes/Erlang_20|Erlang 20]], and [[Changes/Erlang_21|Erlang 21]]).
It should be noted that this change consists from an independent or
loosely coupled smaller changes. If we fail to deliver some changes in
time, we should reschedule these exact changes to the future Fedora
release while keeping already implemented ones.
* Contingency deadline: N/A
* Blocks release? N/A
* Blocks product? N/A
== Documentation ==
* [http://www.erlang.org/news/132 Erlang/OTP 22.0 release notes]
== Release Notes ==
Erlang/OTP 22.0 is available in Fedora 31.
--
Ben Cotton
He / Him / His
Fedora Program Manager
Red Hat
TZ=America/Indiana/Indianapolis
https://fedoraproject.org/wiki/Changes/GHC_8.6
== Summary ==
Update Haskell packages from GHC 8.4 to 8.6 and from Stackage LTS 12
to 13 package versions.
== Owner ==
* Name: [[User:Petersen|Jens Petersen]]
* Email: <petersen(a)redhat.com>
* Name: [[Haskell_SIG|Haskell SIG]]
* Email: <haskell(a)lists.fedoraproject.org>
== Detailed Description ==
The Haskell ghc compiler will be updated to 8.6.5 (rebase from the
ghc:8.6 module stream) and package version will be updated to current
Stackage LTS 13 versions. There will also be some packaging
improvements (doc and profiling subpackages).
== Benefit to Fedora ==
Fedora 31 will have the current stable GHC version (8.6.1 was
originally released last Sept),
and packages will be updated to more recent version from the Stackage
LTS 13 set.
The new subpackaging will allow smaller footprint Haskell development
installations without being forced to install docs and profiling
library that take up a lot of space and downloading.
== Scope ==
* Proposal owners:
** rebase ghc to 8.6.5
** update ghc-rpm-macros and cabal-rpm to allows doc and prof subpackaging
** refresh packaging to latest cabal-rpm
** update packages to latest Stackage LTS 13 versions
** build everything in a Koji f31-ghc sidetag repo
** When finished all builds will be pushed by releng to Rawhide before branching
* Other developers: N/A
* Release engineering: [https://pagure.io/releng/issue/8549 #8549]
* Policies and guidelines:
** There may be a minor revision later to update the Haskell Packaging
Guidelines
* Trademark approval: N/A (not needed for this Change)
== Upgrade/compatibility impact ==
Upgrades of Haskell packages should work fine.
Users will then recompile their code with the latest compiler and libraries.
== How To Test ==
* dnf install ghc
* dnf install ghc ghc-doc
* dnf install ghc ghc-prof
* install ghc and cabal-install
* install pandoc, ShellCheck, git-annex
* install ghc-*-devel or ghc-*-prof or ghc-*-doc
* cabal-rpm builddep <favouritepackage>; cabal install <favouritepackage>
== User Experience ==
Users will be happy to have the latest stable major version of GHC and
Haskell packages available to them, and benefit from the improvements
and new compiler features it provides.
== Dependencies ==
Non really: hedgewars rebuild will be tested.
== Contingency Plan ==
* Contingency mechanism: revert and ship the same package versions as F30
* Contingency deadline: Beta freeze
* Blocks release? N/A
* Blocks product? no
== Documentation ==
* https://downloads.haskell.org/~ghc/8.6.5/docs/html/users_guide/8.6.1-notes.…
--
Ben Cotton
He / Him / His
Fedora Program Manager
Red Hat
TZ=America/Indiana/Indianapolis
https://fedoraproject.org/wiki/Changes/VariableNotoFonts
== Summary ==
This Change aims to change the priority in Google Noto to make
Variable Fonts higher than non-Variable Fonts.
== Owner ==
* Name: [[User:Tagoh| Akira TAGOH]]
* Email: tagoh(a)redhat.com
== Detailed Description ==
The font selection to match better fonts mostly depends on the order
of the configuration files for fontconfig which is available at
/etc/fonts/conf.d as long as it is written along the templates in our
guidelines. so if we want to change that behavior for certain
languages, we usually change the priority of it.
This proposal is to give the variable fonts version of Google Noto
families higher priority than non-variable fonts in Google Noto
families, to enable the variable fonts in Google Noto.
== Benefit to Fedora ==
The variable fonts of Google Noto families supports some axes for
variations into one OpenType font file. no need to have multiple files
per variations. this saves disk spaces and give us more better
experience.
We have already enabled Google Noto as default fonts for Sinhala which
affects by this change. it may be good to have the comparison table
how it saves.
{| class="wikitable"
|-
! Language !! non-VF !! VF
|-
| Sinhala || 10.94MiB || 1.02MiB
|}
There are also the variable fonts available for other languages too
but not default fonts for them. this will gives similar benefits for
them as well if one install them instead of non-VF version of Noto:
* sans-serif
** Latin
** Arabic
** Armenian
** Bengali
** Canadian Aboriginal
** Cham
** Cherokee
** Devanagari
** Ethiopic
** Georgian
** Hebrew
** Kannada
** khmer
** Lao
** Malayalam
** Myanmar
** Tamil
** Thaana
** Thai
* serif
** Latin
** Armenian
** Ethiopic
** Georgian
** Gujarati
** Gurmukhi
** Hebrew
** Kannada
** Khmer
** Lao
** Myanmar
** Tamil
** Thai
** Tibetan
* monospace
** Latin
== Scope ==
* Proposal owners:
** Update google-noto-fonts package to change the priority of
fontconfig configuration files
** Update langpacks to replace non-VF to VF version of packages
** Update comps.xml to replace non-VF to VF version of packages
* Other developers: N/A
* Policies and guidelines: N/A
* Trademark approval: N/A (not needed for this Change)
== How To Test ==
To check if you use the variable fonts:
<pre>
$ fc-match -f '%{file}' sans-serif:lang=si
/usr/share/fonts/google-noto-vf/NotoSansSinhala-VF.ttf
</pre>
The filename should be obvious for the variable fonts.
== User Experience ==
Users can see more variations of fonts if applications supports.
== Dependencies ==
N/A (not a System Wide Change)
== Contingency Plan ==
* Contingency mechanism: (What to do? Who will do it?) We can simply
revert the relevant changes to what we had before this change
* Contingency deadline: N/A (not a System Wide Change)
* Blocks release? No
== Documentation ==
N/A (not a System Wide Change)
--
Ben Cotton
He / Him / His
Fedora Program Manager
Red Hat
TZ=America/Indiana/Indianapolis
Self-Contained Change proposals for Fedora 31 must be submitted (i.e.
placed into the ChangeReadyForWrangler category) by the end of
tomorrow (23 July).
I was on PTO last week, so if you were anticipating action on a Change
proposal and it hasn't happened yet, I'll work through that backlog
today.
For more development milestones in the F31 schedule, see:
https://fedorapeople.org/groups/schedule/f-31/f-31-devel-tasks.html
--
Ben Cotton
He / Him / His
Fedora Program Manager
Red Hat
TZ=America/Indiana/Indianapolis
Good Morning,
We posted this [1] blog today and want to open a mailing thread to garner
feedback, field questions and get some thoughts from the Community on
the approach that we in Community Platform Engineering (CPE) are taking.
[1] https://communityblog.fedoraproject.org/application-service-categories-and-…
pingou
- For the CPE team
Just a reminder that builds are currently running for python2 and python3 that
change the meaning of /usr/bin/python from Python 2 to Python 3 in rawhide.
For details, see https://fedoraproject.org/wiki/Changes/Python_means_Python3
I'll be sending e-mails later to package owners who still depend on
/usr/bin/python or who have other tools in /usr/bin/ that should be switched over.
In case of trouble, block the tracker bug:
https://bugzilla.redhat.com/show_bug.cgi?id=1729593
Thanks,
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
https://fedoraproject.org/wiki/Changes/Noi686Repositories
(Ben is on vacation, so I announcing this on his behalf.)
== Summary ==
Stop producing and distributing the Modular and Everything i686 repositories.
== Owner ==
* Name: Kevin Fenzi
* Email: kevin(a)scrye.com
== Current status ==
* Targeted release: [[Releases/31| Fedora 31 ]]
* Last updated: <!-- this is an automatic macro — you don't need to change this
line --> {{REVISIONYEAR}}-{{REVISIONMONTH}}-{{REVISIONDAY2}}
* Tracker bug: <will be assigned by the Wrangler>
* Release notes tracker: <will be assigned by the Wrangler>
== Detailed Description ==
With the dropping of the i686 kernel package it's no longer possible to directly
install Fedora 31 or later on i686 hardware, however, it is still possibly to
upgrade older releases as long as we continue to provide a repository. This will
leave those users with an old possibly vulnerable kernel installed.
The only other use/need for the repostories is to allow maintainers to debug and
test fixes for multilib shipped packages, but the koji buildroot repo can be
used for this use case.
== Benefit to Fedora ==
* users won't try and upgrade old i686 installs with insecure kernels.
* compose times will be decreased (no more gathering i686 packages up and
running createrepo on them).
* Updates push times will be reduced.
* disk size on mirrors will be reduced.
== Scope ==
* Proposal owners:
** modify pungi-fedora to no longer produce i386 repo for Everything and
Modular, modify bodhi config for f31+ to not make i386 repos for
updates/updates-testing.
** modify mock to use the koji buildroot for i686 for f31+ for those few users
that need to build i686 packages locally.
* Other developers: n/a
* Release engineering: [https://pagure.io/releng/issues 8529]
== Upgrade/compatibility impact ==
i686 users will not be able to upgrade, and will have to move to another
supported arch.
== How To Test ==
* Confirm that there are no trees under
https://dl.fedoraproject.org/pub/fedora-secondary/development/rawhide/Every…
or
https://dl.fedoraproject.org/pub/fedora-secondary/development/rawhide/Modul…
* Confirm that there are no trees under
https://dl.fedoraproject.org/pub/fedora-secondary/updates/31/{Everything|Mo…
or
https://dl.fedoraproject.org/pub/fedora-secondary/updates/testing/31/{Every…
* Confirm that mock can init a chroot for fedora-i386-31 using the koji
buildroot repository.
== User Experience ==
* Users will get updates and rawhide and rc composes faster.
* Users will not be able to upgrade to a insecure Fedora configuration.
== Contingency Plan ==
i686 trees will just continue to be composed and published. Users can upgrade to
them (with an old kernel from f30).
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
Planned Outage -pagure.io - 2019-07-12 21:00 UTC
There will be an outage starting at 2019-07-12 21:00 UTC ,
which will last approximately 4 hours.
To convert UTC to your local time, take a look at
http://fedoraproject.org/wiki/Infrastructure/UTCHowto
or run:
date -d '2019-07-12 21:00UTC'
Reason for outage:
We will be moving pagure.io from one datacenter to another. The time to
sync the data is expected to be around an hour, but we are leaving time
for configuration issues or network problems. We will try and minimize
the downtime as much as possible. Sorry for the short notice on this
outage window.
Affected Services:
https://pagure.iohttps://docs.pagure.org
Ticket Link:
None. :) Since pagure.io will be down.
Please join #fedora-admin or #fedora-noc on irc.freenode.net
or add comments to the ticket for this outage above.
https://fedoraproject.org/wiki/Changes/Mono_5_20
== Summary ==
Update the Mono stack in Fedora from 5.18 to 5.20. It seems we need to
do again a bootstrap build.
== Owner ==
* Name: [[User:tpokorra|Timotheus Pokorra]]
* Email: tpokorra(a)fedoraproject.org
== Detailed Description ==
I had hoped, that between minor releases, we could build Mono without
doing a bootstrap. I can build Mono 5.20 fine with a bootstrap, but
not without. I did some experimenting, with the idea of a fake
bootstrap, by using the existing Mono in Fedora, and avoiding the
checks for the mscorlib version. But that ended in compiler errors. I
asked upstream, but have not yet received a reply:
https://github.com/mono/mono/issues/15643
I have successfully built Mono 5.20 without bootstrap, once I have
Mono 5.20 installed.
I would like to request permission to make a one time exception of the
rule for building mono 5.20.1-1 using monolite and the reference
assemblies, later make mono depend again on itself and rebuild mono
5.18.1-2 using mono-5.18.1-1.
Steps for bootstrapping:
* The Monolite binaries are included in the Mono tarball which is
provided by upstream. See also
http://www.mono-project.com/docs/advanced/monolite/
** Monolite is a minimal binary distribution of mcs. This is the
compiler that is able to build the rest of Mono.
* The binary reference assemblies are included in the Mono tarball
which is provided by upstream. The tarball also includes the sources
of the reference assemblies, which are maintained here:
https://github.com/dotnet/source-build
* In the spec file, we usually delete all dlls and executables before
the build section.
* For the bootstrap, we would once keep the monolite binaries and some
binary reference assemblies.
* In the bootstrap, we rebuild the reference assemblies and include
them in the mono-devel package, as well as the mono compiler.
* After Mono has been built for all primary and secondary
architectures, we enable the deletion of the binaries again in the
spec file.
== Benefit to Fedora ==
Fedora aims to showcase the latest in free and open source software -
we should have the most recent release of Mono 5.x
== Scope ==
* Proposal owners:
Update mono spec and build in koji until is ready.
Members of the Mono SIG can rebuild their packages with Mono 5.20, but
tests with keepass for example show that it works fine without
rebuilding even with Mono 5.20. Rebuild of all packages depending on
Mono can happen during the regular mass rebuild.
* Other developers: N/A
* Policies and guidelines: N/A
* Trademark approval: N/A (not needed for this Change)
== Upgrade/compatibility impact ==
Tests with keepass without rebuilding keepass worked fine on Mono 5.20.
== How To Test ==
N/A (not a System Wide Change)
== User Experience ==
== Dependencies ==
This is not a system wide change, but only affects packages depending
on Mono, and should be managed by the members of the [[SIGs/Mono|Mono
SIG]].
== Contingency Plan ==
* Contingency mechanism: (What to do? Who will do it?) N/A
* Contingency deadline: N/A
* Blocks release? N/A
== Documentation ==
* https://fedoraproject.org/wiki/Packaging:Mono
* https://github.com/mono/mono
* https://copr.fedorainfracloud.org/coprs/tpokorra/mono-5.20/
* https://github.com/tpokorra/mono-5.x-fedora/tree/master/mono-5.20
--
Ben Cotton
He / Him / His
Fedora Program Manager
Red Hat
TZ=America/Indiana/Indianapolis
https://fedoraproject.org/wiki/Changes/Bundler_2.0
== Summary ==
Upgrade to Bundler 2.0, the latest stable gem version.
== Owner ==
* Name: [[User:pvalena | Pavel Valena]], [[User:vondruch | Vit Ondruch]]
* Email: pvalena(a)redhat.com, vondruch(a)redhat.com
== Detailed Description ==
Bundler 2 is new major upstream release, that includes many
improvements and bug fixes.
== Benefit to Fedora ==
Keeping with a latest release, Bundler is enabling simple Ruby
application dependency managemenent.
== Scope ==
* Proposal owners:
** Move Bundler 1.16 to rubygem-bundler1 (sub)package.
** Build Bundler 2.0. Current changes:
https://src.fedoraproject.org/rpms/rubygem-bundler/pull-request/5
** Work has been done in a Copr repository:
https://copr.fedorainfracloud.org/coprs/pvalena/rubygem-bundler/
* Other developers: N/A
* Release engineering: N/A
* Policies and guidelines: N/A
* Trademark approval: N/A
== Upgrade/compatibility impact ==
All applications and Gemfiles that currently work with Bundler 1 will
continue to work with Bundler 2.
Notable changes:
* Dropped support for end of lifed Ruby versions 1.8.7 through 2.2
* Dropped support for end of lifed RubyGems versions 1.3.6 through 2.5
* Moved error messages from STDOUT to STDERR
== How To Test ==
* No special hardware is needed.
* Install Bundler 2
* Run `bundle --version`
* Create new applications as before
* If something doesn't work as it should, let us know.
== User Experience ==
New features that come with Bundler 2.0 will be available. Current
version will be available as rubygem-bundler1.
== Documentation ==
https://bundler.io/docs.html
== Release Notes ==
* https://bundler.io/blog/2019/01/03/announcing-bundler-2.html
* https://bundler.io/blog/2018/11/04/an-update-on-bundler-2.html
--
Ben Cotton
He / Him / His
Fedora Program Manager
Red Hat
TZ=America/Indiana/Indianapolis