F36 Change: Drop NIS(+) support from PAM (System-Wide Change proposal)
by Ben Cotton
https://fedoraproject.org/wiki/Changes/drop_NIS_support_from_PAM
== Summary ==
This change is about dropping user-authentication using NIS(+) from PAM.
== Owner ==
* Name: [[User:besser82 | Björn Esser]]
* Email: besser82(a)fedoraproject.org
* Name: [[User:ipedrosa | Iker Pedrosa]]
* Email: ipedrosa(a)redhat.com
== Detailed Description ==
NIS(+) was introduced by Sun/Oracle to easily share files and system
users between UNIX-alike systems within the same network, and has been
around for some decades. Its simplicity though opens a variety of
possible security issues, like not being able the verify whether the
shared information is actually correct and/or trustworthy. That said,
and with several more secure options (LDAP, Kerberos, Samba, etc.) to
achieve the same goal, we should at least remove support for NIS for
user authentication.
== Feedback ==
There was some discussion on
[https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.o...
the fedora-devel mailing-list]. Some people are reluctant about the
removal of NIS(+) support from PAM, while most are okay with it as
there are more secure alternatives (LDAP, FreeIPA, etc.) available.
== Benefit to Fedora ==
With this change we start directing our users and developers to move
away from NIS(+) to secure alternatives like LDAP and/or FreeIPA.
== Scope ==
* Proposal owners:
** Adapt the pam spec file to build without support for NIS(+).
** Communicate the removal of the PAM configuration for
user-authentication using NIS with the authselect maintainers; also
offer assistance to implement the needed changes.
* Other developers:
** Apply the pull-request to the authselect package.
** Test this change.
* Release engineering: [https://pagure.io/releng/issue/10351 #10351]
* Policies and guidelines: N/A (not needed for this Change)
* Trademark approval: N/A (not needed for this Change)
* Alignment with Objectives: N/A
== Upgrade/compatibility impact ==
Users that were relying on support for NIS(+) will need to move to
secure alternatives like LDAP and/or FreeIPA.
== How To Test ==
There is no need to test, as when configure switch is removed, support
is dropped.
== User Experience ==
For some users this change may be a bit disruptive and it may require
some learning curve for switching to alternative solutions.
== Dependencies ==
* The authselect package needs to be updated to drop its PAM
configuration for user-authentication using NIS.
* Apart from that there are actually no rpms, that directly depend on
the change of the functionality of the affected PAM module.
== Contingency Plan ==
* Contingency mechanism: Revert the changes made to the affected
packages and rebuild them.
* Contingency deadline: At beta freeze.
* Blocks release? Yes.
== Documentation ==
The documentation about sharing system users and files over NIS should
be dropped, if there even is any.
== Release Notes ==
Support for NIS(+) has been dropped from PAM. Users, who are
currently using NIS(+) to share UNIX users / groups within a network,
should migrate their setups to use LDAP or some other secure service
providing comparable functionalities before updating to Fedora 36.
--
Ben Cotton
He / Him / His
Fedora Program Manager
Red Hat
TZ=America/Indiana/Indianapolis
3 months
mv is massively slower on the host rather than in a nspawn chroot,
regression somewhere?
by Robert-André Mauchin
Hi,
So I have an annoying bug that started near the beginnings of F35.
My papirus-icon-theme became very slow to install:
https://bugzilla.redhat.com/show_bug.cgi?id=2029709#c18
During the installation, all the files are copied, then renamed by rpm
(no idea why it works like this).
It works fast in a Mock chroot but incredibly slow on bare metal.
I've done a small test of moving files:
[root@cassini icons]# mkdir test
[root@cassini icons]# for (( i = 0; i < 10000; i++ )) do > test/file_$i;
done
[root@cassini icons]# cd test
On host:
time $(for f in *; do mv "$f" "${f%}.txt"; done)
real 2m3,500s
user 0m3,966s
sys 2m0,431s
In nspawn container:
<mock-chroot> sh-5.1# time $(for f in *; do mv "$f" "${f%}.txt"; done)
real 0m6.702s
user 0m4.237s
sys 0m3.344s
Since papirus-icon-theme contains more than 100,000 (small) files, it is
a problem. One minute of waiting is ok, 20 mn is not.
What can cause this? I read that nspawn virtualizes the file system,
could it be file system related on the host? (I use btrfs btw)
Any input welcome!
Best regards,
Robert-André
3 months
Bodhi and "update ejected from the push" errors
by Mattia Verga
Recently we're having some (a lot) of errors about updates stuck in
Bodhi with errors like "update ejected from the push because Cannot find
relevant tag...".
I tried to fix some of them myself, and relengs folks are also on this.
But since there are so many, I'll post here how to fix yourself.
If your Bodhi update is stuck in the "Pending" state, please make sure
that all the builds inside the update are tagged in the release
candidate tag (which is typically something like
'f35-updates-candidate'). You can check that by clicking on the build(s)
name(s) in the right column on the update page.
If any build in the update is not properly tagged, you must manually tag
it with something like:
koji tag-build f35-updates-candidate build-0.1.2-1.fc35
(obviously you need koji cli to be installed on your system and you need
to be authenticated with kerberos)
After all the builds in the update are tagged you can push the update to
testing. If you just push the update without all the builds properly
tagged, you'll get another "update ejected from the push" the next Bodhi
composer run.
For updates stuck in the "Testing" state, the quickest solution is to
unpush the update with the button in Bodhi web interface and then
re-submit it to testing.
Mattia
3 months
libcurl-minimal
by Zbigniew Jędrzejewski-Szmek
Hi Kamil and everyone,
what is the plan with introduction of libcurl-minimal in Fedora?
IIUC, libcurl and libcurl-minimal both have the same Provides, so libcurl-minimal
can be used to satisfy automatically generated dependencies:
$ dnf repoquery --provides libcurl-minimal
libcurl = 7.78.0-3.fc35
libcurl(x86-32) = 7.78.0-3.fc35
libcurl(x86-64) = 7.78.0-3.fc35
libcurl-minimal = 7.78.0-3.fc35
libcurl-minimal(x86-32) = 7.78.0-3.fc35
libcurl-minimal(x86-64) = 7.78.0-3.fc35
libcurl.so.4
libcurl.so.4()(64bit)
$ dnf repoquery --provides libcurl
libcurl = 7.78.0-3.fc35
libcurl(x86-32) = 7.78.0-3.fc35
libcurl(x86-64) = 7.78.0-3.fc35
libcurl-full = 7.78.0-3.fc35
libcurl-full(x86-32) = 7.78.0-3.fc35
libcurl-full(x86-64) = 7.78.0-3.fc35
libcurl.so.4
libcurl.so.4()(64bit)
AFAICS, no other package makes use of libcurl-{full,minimal}.
In systemd we only care about a narrow subset of protocols, so libcurl-minimal is
perfect. I considered adding Suggests:libcurl-minimal%{_isa} in systemd. IIUC,
that'd bias dnf towards the installation of libcurl-minimal. But the problem
is that if some other package expects libcurl in the full version, it'll be
disappointed.
Hence my question: how to proceed with pulling in libcurl-minimal where
it'd be useful? Should I just add Suggests:libcurl-minimal%{_isa} in systemd
and let the maintainers of other packages add Recommends:libcurl-minimal%{_isa}
or Requires:libcurl-minimal%{_isa} if they need it? What packages would that be?
Another option would be do not do any of this at package level, but instead
pull in libcurl-minimal through comps or kickstart or equivalent when doing
installations.
(Sorry if this is all documented somewhere… I looked around, but didn't see
anything relevant.)
Zbyszek
3 months, 1 week
F37 Change: MinGW UCRT target (Self-Contained Change proposal)
by Ben Cotton
https://fedoraproject.org/wiki/Changes/F37MingwUCRT
== Summary ==
This proposal is to add the UCRT target & support from Fedora to the
MinGW cross-toolchains.
== Owner ==
* Name: [[User:elmarco| Marc-André Lureau]]
* Email: marcandre.lureau(a)redhat.com
== Detailed Description ==
The current mingw32 and mingw64 cross-toolchains provided by Fedora
target the MSVCRT (Microsoft Visual C++ Runtime). Since Visual Studio
15 & Windows 10, the default and recommended runtime is UCRT. See also
[https://www.msys2.org/docs/environments/#msvcrt-vs-ucrt MSVCRT vs
UCRT].
A new toolchain target triple `x86_64-w64-mingw32ucrt` and associated
binaries will be added.
Fedora MinGW macros will be provided to target UCRT, with ucrt64-*
prefix (ex: `ucrt64-meson`)
mingw-* libraries will be progressively adjusted to add the produced
ucrt64-* binaries.
Since mingw-*.spec are very repetitive and cumbersome to modify (each
mingw32, mingw64, ucrt package has to be defined manually, and this is
tedious and error-prone), a custom MinGW/Fedora tool or solution will
be proposed. In the meantime, packages can be modified to add manually
the new target.
[https://lists.fedoraproject.org/archives/list/mingw@lists.fedoraproject.o...
UCRT plans on mingw(a)lists.fedoraproject.org ]
== Benefit to Fedora ==
This change will allow to cross-compile projects to Windows with the
up to date C runtime & headers, and better c99 support. This should
allow to more easily mix binaries produced from different versions or
compilers as well.
== Scope ==
* Proposal owners:
** update the mingw filesystem, binutils, headers, gcc & winpthreads packages
** bootstrap the new toolchain
** propose a solution to simplify library packaging with the different targets
** update some common library packages, such as mingw-zlib
* Other developers:
** Progressively adjust the mingw-* packages to produce ucrt64-
packages, following the updated guidelines.
* Release engineering:
* Policies and guidelines:
https://fedoraproject.org/wiki/Packaging:MinGW packaging guideline
will be adjusted.
* Trademark approval: N/A (not needed for this Change)
* Alignment with Objectives:
== Upgrade/compatibility impact ==
None
== How To Test ==
<pre>
$ x86_64-w64-mingw32ucrt-gcc test.c
$ /usr/bin/mingw-objdump -p a.exe | grep DLL
vma: Hint Time Forward DLL First
DLL Name: KERNEL32.dll
DLL Name: api-ms-win-crt-time-l1-1-0.dll
DLL Name: api-ms-win-crt-math-l1-1-0.dll
DLL Name: api-ms-win-crt-runtime-l1-1-0.dll
DLL Name: api-ms-win-crt-environment-l1-1-0.dll
DLL Name: api-ms-win-crt-private-l1-1-0.dll
DLL Name: api-ms-win-crt-heap-l1-1-0.dll
DLL Name: api-ms-win-crt-locale-l1-1-0.dll
DLL Name: api-ms-win-crt-stdio-l1-1-0.dll
DLL Name: api-ms-win-crt-string-l1-1-0.dll
</pre>
== User Experience ==
Windows binaries produced by Fedora cross-toolchain will target a more
modern and compatible C runtime, bringing hopefully better
compatibility & safety.
== Dependencies ==
None
== Contingency Plan ==
* Contingency mechanism: N/A (not a System Wide Change)
* Contingency deadline: N/A (not a System Wide Change)
* Blocks release? No (not a System Wide Change)
== Documentation ==
N/A (not a System Wide Change)
== Release Notes ==
The new MinGW toolchain and tools are available to compile binaries
targeting the Windows UCRT.
--
Ben Cotton
He / Him / His
Fedora Program Manager
Red Hat
TZ=America/Indiana/Indianapolis
3 months, 1 week
F36 Change: Wayland by Default for SDDM (Self-Contained Change proposal)
by Ben Cotton
https://fedoraproject.org/wiki/Changes/WaylandByDefaultForSDDM
= Wayland by Default for SDDM =
== Summary ==
Change the default display server mode for SDDM to use a Wayland-based
greeter rather than an 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, Kinoite
* Responsible WG: KDE SIG
== Detailed Description ==
With [https://github.com/sddm/sddm/pull/1393 the work done upstream in
SDDM to support using a Wayland based greeter] and
[[Changes/ReplaceFbdevDrivers|the introduction of SimpleDRM to fix the
broken fallback when platform drivers are unavailable]], it is now
possible for the Fedora KDE variants (the regular spin and Kinoite) to
move to Wayland for the login manager, which effectively completes the
switch to Wayland for these variants.
== Benefit to Fedora ==
As originally detailed in [[Changes/WaylandByDefaultForPlasma|the
Change to switch Plasma to Wayland by default]], Fedora is a leader in
advancing the adoption of the Wayland protocol as part of the overall
strategy to improve the Linux graphical software stack. We have been
successful in helping drive Wayland forward in the Plasma Desktop, and
we intend to do the same for SDDM.
== Scope ==
* Proposal owners:
** Upgrade {{package|sddm}} to the latest snapshot and introduce
mutually exclusive <code>sddm-wayland-generic</code> and
<code>sddm-x11</code> greeter configuration packages.
** Modify {{package|plasma-workspace}} to switch SDDM to Wayland
*** Enable installation of the SDDM Wayland configuration snippet and
ship as <code>sddm-wayland-plasma</code> that is mutually exclusive
with the other sddm greeter configuration packages. This package will
supplement {{package|sddm}} and <code>plasma-workspace-wayland</code>
to be automatically installed together.
** Modify <code>@kde-desktop</code> comps group for Fedora Linux 36 to
include <code>sddm-wayland-plasma</code> for the media.
* Other developers: N/A (not needed for this Change)
* Release engineering: [https://pagure.io/releng/issue/10536 #10536]
* Policies and guidelines: N/A (not needed for this Change)
* Trademark approval: N/A (not needed for this Change)
* Alignment with Objectives: N/A
== Upgrade/compatibility impact ==
On upgrade to Fedora Linux 36, SDDM will be transparently switched
from the X11 greeter to the Wayland one leveraging kwin. In order to
override this, the user can do one of the following:
* Drop in a configuration file in <code>/etc/sddm.conf.d</code> to set
the display server back to X11
* Swap back to X11 with the configuration package: <code>dnf swap
sddm-wayland-plasma sddm-x11</code>
== How To Test ==
Once the SDDM and Plasma Wayland changes are made, Rawhide users can
try this by using nightly KDE ISOs and using them normally to install
and run a Rawhide KDE Plasma environment.
== User Experience ==
Ideally, there should be no noticeable impact on the user experience,
though users may notice that things operate more smoothly and with
slightly lower resources.
== Dependencies ==
This change is dependent on [[Changes/ReplaceFbdevDrivers|the Change
to replace fbdev with SimpleDRM]]. Without that Change, we will need
to keep SDDM using X11 because otherwise the fallbacks are broken when
drivers do not work.
== Contingency Plan ==
* Contingency mechanism: Update comps and {{package|plasma-workspace}}
so that <code>sddm-x11</code> is shipped instead.
* Contingency deadline: beta freeze
* Blocks release? Yes
== Documentation ==
N/A (not a System Wide Change)
== Release Notes ==
SDDM, the login manager for the Fedora variants using the KDE Plasma
Desktop, now uses the Wayland display system.
--
Ben Cotton
He / Him / His
Fedora Program Manager
Red Hat
TZ=America/Indiana/Indianapolis
3 months, 1 week
F37 Change: RetireARMv7 (System-Wide Change proposal)
by Ben Cotton
https://fedoraproject.org/wiki/Changes/RetireARMv7
== Owner ==
* Name: [[User:pbrobinson| Peter Robinson]]
* Email: <pbrobinson(a)fedoraproject.org>
== Detailed Description ==
The ARMv7 arm architecture was the second variant of the arm
architecture that Fedora has supported, the first was ARMv5, the third
is aarch64. The proposal is to retire ARMv7 as part of the Fedora 37
release. This will allow ARMv7/armhfp to be supported until the Fedora
36 end of life in around June 2023.
Overall arm32 is generally waning with generally few new ARMv7 devices
added to Fedora in recent releases. To add to that a number of newer
Fedora features designed to improve speed and security of the Fedora
release are causing 32 bit architectures in general primarily due to
the process memory limit when linking large applications. The
ARMv7/armhfp is the last fully supported 32 bit architecture, we still
currently build i686 packages, but it's not shipped as artefacts.
== Benefit to Fedora ==
The primary benefit is to maintainers of the ARM architecture, the
various toolchain teams and package maintainers in general.
== Scope ==
* Proposal owners: Work with rel-eng to disable the architecture in
koji, remove all the various pungi pieces and clean up any other
release detritus.
* Other developers: No action required.
* Release engineering: [https://pagure.io/releng/issue/10387 Releng
issue #10387] Disable a bunch of stuff, it's really just one koji
admin command and a PR for pungi config changes
* Policies and guidelines: No initial updates to policies and
guidelines as ARMv7 won't completely disappear until F-36 EOL.
* Trademark approval: N/A (not needed for this Change)
== Upgrade/compatibility impact ==
Any current users of Fedora on ARMv7 devices won't be able to upgrade
to Fedora 37, they will have to stay on Fedora 36 until it's EOL.
== How To Test ==
There's not really anything to test as it's removing the support for
an architecture.
== User Experience ==
Any current users of Fedora on ARMv7 devices won't be able to upgrade
to Fedora 37, they will have to stay on Fedora 36 until it's EOL.
== Dependencies ==
N/A.
== Contingency Plan ==
Continue on as before with the added advantage of the people that
protested the removal of the architecture will be actively
contributing to the maintenance of the architecture
* Contingency mechanism: Leave enabled. We basically won't get to this
if FESCo doesn't approve the change.
* Contingency deadline: Mass rebuild.
* Blocks release? Yes
* Blocks product? Yes
== Documentation ==
N/A
== Release Notes ==
Fedora Linux 37 with the ARMv7 architecture is retired into the
sunset. There will definitely be celebrations, there will likely be
some that shed some tears! Overall for the maintainers it will likely
be seen as a net win, for the few, generally shrinking, users it's
probably a net loss but they can probably just go and buy a Raspberry
Pi Zero 2W for US$15. ¯\_(ツ)_/¯
--
Ben Cotton
He / Him / His
Fedora Program Manager
Red Hat
TZ=America/Indiana/Indianapolis
3 months, 1 week
F36 Change: Enable exclude_from_weak_autodetect by default in LIBDNF
(System-Wide Change proposal)
by Ben Cotton
https://fedoraproject.org/wiki/Changes/ExcludeFromWeakAutodetect
== Summary ==
exclude_from_weak_autodetect enables autodetection of unmet weak
dependencies (Recommends or Supplements) of installed packages and
blocks installation of packages satisfying already unmet dependencies.
In other words: When you don't have the recommended package installed,
it won't be automatically installed with future upgrades of the
recommending package.
== Owner ==
* Name: [[User:jmracek| Jaroslav Mracek]]
* Email: jmracek(a)redhat.com
== Detailed Description ==
The feature is designed to prevent an install of removed weak
dependencies from the system by users and to not install weak
dependencies missing after system deployment. It will change the
behavior of DNF, microdnf, and PackageKit. The feature will be
backported to all Fedoras, but in default, the feature will be off.
Additional information: https://bugzilla.redhat.com/show_bug.cgi?id=1699672
The default value for exclude_from_weak_autodetect configuration can
be overridden in `/etc/dnf/dnf.conf`
== Feedback ==
The feature was requested by [[User:Churchyard|Miro Hrončok]] and
supported by many others: See
[https://bugzilla.redhat.com/show_bug.cgi?id=1699672 rhbz#1699672] for
more feedback.
== Benefit to Fedora ==
After the installation of a fresh system, the first upgrade will not
install a lot of weak dependencies. Some of them were excluded from
the kick-start installation set for good reasons (security, image
size, minimal functional set, ...), but after the first update, all
weak dependencies are installed, therefore some features of deployment
simply disappear.
== Scope ==
* Proposal owners:
** The feature is ready in Pull Request -
https://github.com/rpm-software-management/libdnf/pull/1279
** PRs only wait for a release of libsolv
** The Feature will be enabled in upstream as default, therefore from
Fedora 36, we start to release libdnf without a revert patch of
default in comparison to upstream.
* Other developers: The change requires a new release of libsolv.
* Release engineering:
* Policies and guidelines: A packaging guideline should be added that
discourages or forbids weak dependencies on fully versioned
(sub)packages (see
[https://bugzilla.redhat.com/show_bug.cgi?id=1699672#c44 the
details]).
* Trademark approval: N/A (not needed for this Change)
* Alignment with Objectives:
== Upgrade/compatibility impact ==
No manual changes will be required. After the libdnf update, this
feature will be on by default.
== How To Test ==
1. Install package without satisfied weak dependencies
2. Upgrade the upgrade. With exclude_from_weak_autodetect=true, it
will not install weak dependencies of already installed packages. With
exclude_from_weak_autodetect=false, weak dependencies will be
installed during upgrades.
== User Experience ==
The change in default will help to keep some values for particular
deployments (a minimal system will be still minimal without disabling
weak dependencies).
Users will be able to remove particular weak dependencies and they
will be not installed on the first upgrade.
In case when the feature will not work according to the user
expectation it can be switched off in the dnf configuration file.
== Dependencies ==
libsolv - Required code changes are already in the libsolv upstream.
We only wait for the next libsolv release.
== Contingency Plan ==
There are no external dependencies, therefore we can easily postpone
the feature and the change of default behavior.
* Contingency mechanism: (What to do? Who will do it?)
* Contingency deadline: beta freeze
* Blocks release? No
== Documentation ==
The feature will be documented in dnf man pages.
--
Ben Cotton
He / Him / His
Fedora Program Manager
Red Hat
TZ=America/Indiana/Indianapolis
3 months, 1 week
Weirdness with clang and stdatomic.h on Rawhide
by Ron Olson
Hey all,
I’m troubleshooting an issue and came up with this sample program: https://pastebin.com/g9S8Z64q to demonstrate the problem. Basically, clang 13, on Rawhide, won’t compile that program, while on Fedora 35 it does.
The reason why is that on Rawhide, stdatomic.h exists under /usr/include/c++/12 while it does not exist on 35, so clang uses its built-in stdatomic per https://clang.llvm.org/docs/LanguageExtensions.html#c11-atomic-operations. If it uses its internal version, the sample program compiles fine.
Looking at stdatomic.h on Rawhide, I see it’s gated by “#if __cplusplus > 202002L”, so that means C++2b or later, not C++20. This seems to create a problem for clang which, since the file is present, wants to use it, but since it’s effectively empty due to the #ifdef, compiling of the sample program fails.
Is it possible to disable clang’s use of the header file as a flag? I’ve been unable to find anything like that, and obviously renaming the header is out of the question. Also, is it correct to the setting stdatomic.h to only be used by c++2b?
Thanks for any info,
Ron
3 months, 1 week
