Server Side Public License (SSPL) v1
by Tom Callaway
After review, Fedora has determined that the Server Side Public License
v1 (SSPL) is not a Free Software License.
It is the belief of Fedora that the SSPL is intentionally crafted to be
aggressively discriminatory towards a specific class of users.
Additionally, it seems clear that the intent of the license author is to
cause Fear, Uncertainty, and Doubt towards commercial users of software
under that license. To consider the SSPL to be "Free" or "Open Source"
causes that shadow to be cast across all other licenses in the FOSS
ecosystem, even though none of them carry that risk.
It is also worth nothing that while there is a draft for a "v2" of the SSPL:
A) It is not final.
B) It is not in use anywhere at this time (as far as we know).
C) The intent of the v2 draft text is not changed from the v1 license
currently in use.
We have updated our "Bad License" list to include SSPLv1. No software
under that license may be included in Fedora (including EPEL and COPRs).
Thanks,
Tom Callaway
Fedora Legal
3 years, 2 months
Re: NeuroFedora review swaps
by Ankur Sinha
On Mon, Jan 28, 2019 15:47:00 +0100, J. Scheurich wrote:
>
> > I'd like to get this package reviewed please:
> >
> > - python-pyscaffold: https://bugzilla.redhat.com/show_bug.cgi?id=1669913#
> >
> > Would anyone like to swap reviews?
>
> I would review it for wdune sponsoring.
Sorry---I'm not current with the wdune scenario. I assumed you meant
that you'd review it unofficially as part of the work to get sponsored
to the packagers group:
https://fedoraproject.org/wiki/How_to_get_sponsored_into_the_packager_gro...
I'm not a sponsor yet so I cannot sponsor you to the group myself, but
once you've done a few reviews, a sponsor will be happy to take a look
at them and guide you through the sponsorship process.
If you've submitted a review ticket for wdune already, I will be happy
to review it and provide comments.
--
Thanks,
Regards,
Ankur Sinha
https://ankursinha.in
Time zone: Europe/London
3 years, 2 months
F34 Change proposal: Wayland by Default for KDE Plasma Desktop
(System-Wide Change)
by Ben Cotton
https://fedoraproject.org/wiki/Changes/WaylandByDefaultForPlasma
== Summary ==
Change the default session selection in SDDM to prefer the
Wayland-based KDE Plasma Desktop session over the X11-based one.
== Owner ==
* Name: [[User:Ngompa|Neal Gompa]], [[User:Rdieter|Rex Dieter]],
[[User:Jgrulich|Jan Grulich]]
* Email: ngompa13(a)gmail.com, rdieter(a)gmail.com, jgrulich(a)redhat.com
* Product: KDE Spin
* Responsible WG: KDE SIG
== Detailed Description ==
With KDE Plasma 5.20, the KDE Plasma desktop environment has reached a
point where nearly all commonly used features in the desktop and all
major applications function in the Plasma Wayland environment on all
major GPUs (including NVIDIA with the proprietary driver). Starting
with Plasma 5.20 in Fedora 34, we will change the default
configuration for Wayland and X11 Plasma sessions so that Wayland is
preferred and used by default, while permitting the X11 session to be
selected as the alternative desktop environment option.
== Feedback ==
==== Is Wayland ready? ====
Wayland has been used by default for Fedora Workstation (which uses
GNOME) since Fedora 25. And while it was somewhat immature initially,
today it is a very rock-solid experience on virtually everything
Fedora Workstation runs on. The change in Fedora 25 kickstarted the
drive to get everything working on Wayland, and the Workstation team
succeeded beyond their wildest dreams. Firefox has been Wayland-native
by default since Fedora 31 as well.
On the KDE side, serious work into supporting Wayland started shortly
after GNOME switched to Wayland by default. Unlike GNOME, KDE has a
much broader stack in its toolkit, and it has taken longer to get to a
usable state. With the Plasma 5.20 release, the Wayland protocol for
screencasting as well as middle-click paste finally are supported,
completing the required feature set for switching to Wayland by
default.
==== What about NVIDIA? ====
Plasma, in fact, ''does'' support NVIDIA GPUs with the proprietary
driver on Wayland. It needs to be manually activated, which will be
taken care of by the <code>kwin-wayland-nvidia</code> package. So the
expectation is that all major GPUs will work just fine.
==== Why not keep using X11? ====
The fact of the matter is, Xorg is in
[https://blogs.gnome.org/uraeus/2019/06/24/on-the-road-to-fedora-workstati...
"hard maintenance mode"] per [[User:Uraeus|Christian Schaller]] and
development on it has basically stopped beyond the most critical of
fixes. Combined with the rapid maturation of the Wayland session in
KDE Plasma, this is the best time to make the switch and push things
over the edge for the KDE ecosystem in the same way that Fedora
Workstation did for the GNOME ecosystem.
== Benefit to Fedora ==
Fedora has long been a leader in advancing the adoption of the Wayland
protocol as part of the overall strategy to improve the Linux
graphical software stack. Much of the quality of Wayland for GNOME can
be attributed to the work done by the Fedora Workstation WG as part of
advancing the GNOME platform. It is now the KDE SIG's turn to do the
same for the KDE platform. By making this change, we are helping push
the adoption forward for newer, more streamlined, and overall more
actively developed graphics technology for the KDE ecosystem.
== Scope ==
* Proposal owners:
** Modify {{package|kwin}} to switch to Wayland
*** Split out <code>/usr/bin/kwin_x11</code> to the
<code>kwin-x11</code> subpackage.
*** Make {{package|kwin}} require <code>kwin-wayland</code> and
recommend <code>kwin-x11</code>
*** Add <code>kwin-wayland-nvidia</code> subpackage which contains
<code>/usr/lib/environment.d/10-kwin-wayland-nvidia.conf</code> to set
<code>$KWIN_DRM_USE_EGL_STREAMS</code> to <code>1</code>. This package
will have have a Supplements dependency <code>(kwin-wayland and
kmod-nvidia)</code>.
** Modify {{package|plasma-workspace}} to switch to Wayland
*** Rename <code>/usr/share/xsessions/plasma.desktop</code> to
<code>/usr/share/xsessions/plasma-xorg.desktop</code>, subpackage it
out as <code>plasma-workspace-xorg</code>, and have it require
<code>kwin-x11</code>
*** Rename <code>/usr/share/wayland-sessions/plasmawayland.desktop</code>
to <code>/usr/share/wayland-sessions/plasma.desktop</code>
*** Make {{package|plasma-workspace}} require
<code>plasma-workspace-wayland</code> and recommend
<code>plasma-workspace-xorg</code>
** Modify <code>@kde-desktop</code> comps group for Fedora 34 to
include <code>plasma-workspace-xorg</code> for the media.
* Other developers: N/A (not applicable for this Change)
* Release engineering: [https://pagure.io/releng/issue/9741 #9741]
* Policies and guidelines: N/A (not needed for this Change)
* Trademark approval: N/A (not needed for this Change)
* Alignment with Objectives: N/A (not applicable for this Change)
== Upgrade/compatibility impact ==
Systems using certain (very old) graphics hardware or graphics drivers
(matrox, etc.) may have problems running the Wayland session. In these
(rare) cases, users may have to configure SDDM to use X11.
== How To Test ==
Log into a KDE Plasma desktop. Do any activity you would normally do
in your daily desktop use: launching applications, configuring
displays, etc. Things should work the same way under Wayland as they
used to under X.
== User Experience ==
The user experience should not change noticeably.
== Dependencies ==
This mainly affects the {{package|plasma-workspace}} and
{{package|kwin}} packages, and details for the changes for those
packages are described in the Scope section.
== Contingency Plan ==
* Contingency mechanism: Revert the file renames and switch
<code>plasma-workspace-xorg</code> to be the required package instead
of <code>plasma-workspace-wayland</code>
* Contingency deadline: beta freeze
* Blocks release? Yes
* Blocks product? KDE Spin
== Documentation ==
Some upstream documents about Wayland
* https://community.kde.org/Plasma/Wayland
* https://community.kde.org/KWin/Wayland
There is currently no coherent up to date documentation about Plasma Wayland.
== Release Notes ==
The KDE Plasma Desktop is using the Wayland display system now. X
applications will continue to run transparently through XWayland.
--
Ben Cotton
He / Him / His
Senior Program Manager, Fedora & CentOS Stream
Red Hat
TZ=America/Indiana/Indianapolis
3 years, 2 months
%lua_requires behaves differently in F33+
by Michel Alexandre Salim
Hi,
Björn added some useful Lua packaging macros in
https://bugzilla.redhat.com/show_bug.cgi?id=1447324
One of them, %lua_requires, adds a dependency on either `lua(abi) =
%{lua_version}` or, on EL6 and below, on lua >= current version and lua
< next version.
Somehow this seems to be automatically applied on Fedora 33 and above
-- without adding any manual require on lua(abi)
e.g. lua-lunitx on Fedora 33
https://bodhi.fedoraproject.org/updates/FEDORA-2020-7c23dc64c0
on Fedora 32, though, the macro is not automatically invoked (so the
update below is bad and I need to redo it)
https://bodhi.fedoraproject.org/updates/FEDORA-2020-9074133de4
In fact, trying to use %lua_requires does not seem to work, with and
without curly braces:
error: line 15: Unknown tag: %lua_requires
error: line 15: Unknown tag: %{lua_requires}
Could someone help explain these two behaviors? I'm working on resuming
the Lua packaging draft so I want to have a canonical example on how
the macros are supposed to be used.
PS Björn -- we should consider moving the macros out of lua-devel and
into lua-rpm-macros, that lua-devel then depends on. That will fix the
inability to get these macros out to EPEL6 and EPEL7 - on those, lua
packages can just BR the macro package directly.
--
Michel Alexandre Salim
profile: https://keyoxide.org/michel@michel-slm.name
chat via email: https://delta.chat/
GPG key: 5DCE 2E7E 9C3B 1CFF D335 C1D7 8B22 9D2F 7CCC 04F2
3 years, 3 months
Disabling Fedora 30 chroots in Copr
by Jakub Kadlcik
Hello,
we have just disabled Fedora 30 chroots in Copr.
According to the Fedora wiki [1], Fedora 30 reached the end of its life
on 2020-05-26 and therefore we are disabling it in Copr.
That effectively means that from this moment, it is no longer possible
to submit builds for the following chroots:
- fedora-30-x86_64
- fedora-30-i386
- fedora-30-ppc64le
- fedora-30-aarch64
- fedora-30-armhfp
[1] https://fedoraproject.org/wiki/End_of_life
Jakub
3 years, 4 months
F34 Change proposal: MariaDB 10.5 (Self-Contained Change)
by Ben Cotton
https://fedoraproject.org/wiki/Changes/MariaDB_10.5
== Summary ==
Update of MariaDB ('mariadb' package) in Fedora from 10.4 to 10.5 version.
[[Category:Package MariaDB]]
== Owner ==
* Name: [[User:mschorm| Michal Schorm]]
* Email: mschorm(a)redhat.com
== Detailed Description ==
Update of MariaDB package in Fedora from 10.4 version to 10.5 version.
== Benefit to Fedora ==
I'm cooperating with the upstream to bring the latest stable software to
Fedora users.
10.5 series introduces number of enhancements, which cannot be found in
previous series.
Overview of the new features can be found here:
https://mariadb.com/kb/en/changes-improvements-in-mariadb-105/
== Scope ==
* Proposal owners:
**Prepare MariaDB 10.4 as a module for Rawhide and atleast one stable
Fedora release (done)<br />so users which want to stay on the current
release have the possibility.<br />This also serve as a failover mechanism
in case of issues with the 10.5.
**Prepare MariaDB 10.5 as a module for Rawhide and atleast one stable
Fedora release (done in Rawhide; the rest in BODHI)<br />so users can test
the 10.5 in advance. (installing 10.5 module on already stable release)<br
/>This also serve as a upgrade path - users can install 10.5 module on
Fedora release which have 10.4 in base; and then upgrade to 10.5 module on
a Fedora release which will have 10.5 in base.
**Release MariaDB 10.5 to Rawhide (blocked; 10.5 modules needs testing
first)
**Check software that requires or depends on 'mariadb' or 'galera' package
for incompatibilities<br />This shouldn't be an issue in general, as vast
majority of the software requires client library, provided by
"mariadb-connector-c" package, which won't change.
**Gather user input on the changes between MariaDB 10.4 and 10.5
* Other developers: N/A (not a System Wide Change)
* Release engineering:
* Policies and guidelines: N/A (not a System Wide Change)
* Trademark approval: N/A (not needed for this Change)
== Upgrade/compatibility impact ==
The MariaDB client library is compatible, so the shouldn't be any issues
and / or need for rebuild of dependent packages.
==='''UPDATE (10/2020)'''===
MariaDB 10.5 modules are now available for Fedora Rawhide and in BODHI for
the stable releases
== How To Test ==
Usual testing as when upgrading between major MariaDB versions.
Test that all other software runs well with MariaDB 10.5.
Report any issues, so I can reach the different upstreams and check if they
plan update their software to support MariaDB 10.5 and when.
== User Experience ==
The users will have to upgrade their databases the same way as between
major MariaDB versions.
If the users want to stick with MariaDB 10.4 for a little longer, the
MariaDB 10.4 module is available for them in all stable Fedora releases as
well as in Rawhide.
If the users want to test the 10.5 series beforehand, the MariaDB 10.5
module is available.
== Dependencies ==
Since the client library ('mariadb-connector-c') is not changing, dependent
software should work fine.
Only a rare cases builds against the server part of MariaDB. (e.g. building
a server plugin)
== Contingency Plan ==
Modules will provide the functional version of MariaDB 10.4, available to
all users.
* Contingency mechanism: Fedora Modules for 10.4 available
* Contingency deadline: already in place
* Blocks release? N/A (not a System Wide Change)
* Blocks product? N/A (not a System Wide Change)
== Documentation ==
Upgrade startegy:
https://mariadb.com/kb/en/library/upgrading-from-mariadb-104-to-mariadb-105/
Upgrading and incompatibilities:
https://mariadb.com/kb/en/library/upgrading-from-mariadb-104-to-mariadb-1...
== Release Notes ==
Release notes for each release:
https://mariadb.com/kb/en/library/release-notes-mariadb-105-series/
Overall overview of the changes and improvements:
https://mariadb.com/kb/en/library/changes-improvements-in-mariadb-105/
--
Ben Cotton
He / Him / His
Senior Program Manager, Fedora & CentOS Stream
Red Hat
TZ=America/Indiana/Indianapolis
3 years, 4 months
Btrfs question for Fedora 33 beta. How can I add nocow to /var
by Leslie Satenstein
I am looking to some performance considerations for the /etc/fstab btrs default config generated by anaconda.
It appears to have created a subvol for root (root00) and for home (home00).
I would like to put in /opt with it's subvol, and to migrate the /var to a subvol where I can specify nodatacow.
Leaving /var as a directory under /, without specifying nodatacow concerns me as it is a very "busy" directory, and can fill up the root00 subvol quite quickly.
I tried to create the two subvars, without success. I even went so far as to examine the grub menu entries.
Is this not possible with Fed33 beta?
3 years, 4 months
[ELN] gcc is going to be updated to gcc11 in the ELN buildroot ahead
of Rawhide
by Aleksandra Fedorova
Hi, all,
this is the informational message, no action required.
Upon agreement between gcc maintainers and ELN SIG we would like to
switch ELN buildroot to use GCC11 ahead of Fedora Rawhide.
Though ELN is defined as the buildroot where Fedora Rawhide code is
rebuilt into EL-like environment, in the ELN proposal we also
mentioned that ELN can be used to test certain buildroot-related
features on the side so it doesn't block Fedora Rawhide development.
We think that GCC11 is one such feature, where we can benefit from
testing it first on a small subset of the Fedora content in a separate
environment.
We would like to invite everyone to join this effort.
The work is currently tracked on Github:
https://github.com/fedora-eln/eln/issues/8
Once GCC11 is merged to the eln tag in koji, one would be able to use
it via, for example, mock or container environment:
quay.io/fedoraci/fedora:eln-x86_64
For more info on ELN please refer to ELN Docs (as soon as I update
them, which hopefully happens later today):
https://docs.fedoraproject.org/en-US/eln/
--
Aleksandra Fedorova
bookwar at #fedora-devel and #fedora-ci
3 years, 4 months