November 2021 - devel - Fedora Mailing-Lists

by Vitaly Zaitsev

Hello. I have a lot of unremoved directories and files in /usr/lib/jvm/: $ ls -l /usr/lib/jvm/ total 140 drwxr-xr-x. 5 root root 4096 Sep 10 14:32 java-11-openjdk-11.0.12.0.7-4.fc34.x86_64 drwxr-xr-x. 3 root root 4096 Mar 14 2017 java-1.8.0-openjdk-1.8.0.121-10.b14.fc25.x86_64 drwxr-xr-x. 3 root root 4096 Apr 21 2017 java-1.8.0-openjdk-1.8.0.131-1.b12.fc25.x86_64 drwxr-xr-x. 3 root root 4096 Oct 25 2017 java-1.8.0-openjdk-1.8.0.151-1.b12.fc26.x86_64 drwxr-xr-x. 3 root root 4096 Oct 25 2017 java-1.8.0-openjdk-1.8.0.151-1.b12.fc27.x86_64 drwxr-xr-x. 3 root root 4096 Jan 24 2018 java-1.8.0-openjdk-1.8.0.161-0.b14.fc27.x86_64 drwxr-xr-x. 3 root root 4096 Feb 6 2018 java-1.8.0-openjdk-1.8.0.161-5.b14.fc27.x86_64 drwxr-xr-x. 3 root root 4096 Mar 29 2018 java-1.8.0-openjdk-1.8.0.162-3.b12.fc27.x86_64 drwxr-xr-x. 3 root root 4096 Apr 18 2018 java-1.8.0-openjdk-1.8.0.171-1.b10.fc27.x86_64 drwxr-xr-x. 3 root root 4096 Apr 25 2018 java-1.8.0-openjdk-1.8.0.171-4.b10.fc27.x86_64 drwxr-xr-x. 3 root root 4096 Apr 25 2018 java-1.8.0-openjdk-1.8.0.171-4.b10.fc28.x86_64 drwxr-xr-x. 3 root root 4096 Jul 3 2018 java-1.8.0-openjdk-1.8.0.172-12.b11.fc28.x86_64 drwxr-xr-x. 3 root root 4096 Jun 18 2018 java-1.8.0-openjdk-1.8.0.172-9.b11.fc28.x86_64 drwxr-xr-x. 3 root root 4096 Jul 23 2018 java-1.8.0-openjdk-1.8.0.181-7.b13.fc28.x86_64 drwxr-xr-x. 3 root root 4096 Sep 5 2018 java-1.8.0-openjdk-1.8.0.181.b15-0.fc28.x86_64 drwxr-xr-x. 3 root root 4096 Oct 4 2018 java-1.8.0-openjdk-1.8.0.181.b15-5.fc28.x86_64 drwxr-xr-x. 3 root root 4096 Oct 11 2018 java-1.8.0-openjdk-1.8.0.181.b15-6.fc28.x86_64 drwxr-xr-x. 3 root root 4096 Oct 11 2018 java-1.8.0-openjdk-1.8.0.181.b15-6.fc29.x86_64 drwxr-xr-x. 3 root root 4096 Nov 29 2018 java-1.8.0-openjdk-1.8.0.191.b12-11.fc29.x86_64 drwxr-xr-x. 3 root root 4096 Nov 1 2018 java-1.8.0-openjdk-1.8.0.191.b12-8.fc29.x86_64 drwxr-xr-x. 3 root root 4096 Jan 14 2019 java-1.8.0-openjdk-1.8.0.191.b13-0.fc29.x86_64 drwxr-xr-x. 3 root root 4096 Feb 6 2019 java-1.8.0-openjdk-1.8.0.201.b09-2.fc29.x86_64 drwxr-xr-x. 3 root root 4096 Mar 26 2019 java-1.8.0-openjdk-1.8.0.201.b09-6.fc29.x86_64 drwxr-xr-x. 3 root root 4096 Apr 23 2019 java-1.8.0-openjdk-1.8.0.212.b04-0.fc29.x86_64 drwxr-xr-x. 3 root root 4096 Apr 23 2019 java-1.8.0-openjdk-1.8.0.212.b04-0.fc30.x86_64 drwxr-xr-x. 3 root root 4096 Jul 31 2019 java-1.8.0-openjdk-1.8.0.222.b10-0.fc30.x86_64 drwxr-xr-x. 3 root root 4096 Oct 16 2019 java-1.8.0-openjdk-1.8.0.232.b09-0.fc30.x86_64 drwxr-xr-x. 3 root root 4096 Oct 16 2019 java-1.8.0-openjdk-1.8.0.232.b09-0.fc31.x86_64 drwxr-xr-x. 3 root root 4096 Jan 28 2020 java-1.8.0-openjdk-1.8.0.242.b08-0.fc31.x86_64 drwxr-xr-x. 3 root root 4096 Mar 23 2020 java-1.8.0-openjdk-1.8.0.242.b08-1.fc32.x86_64 drwxr-xr-x. 3 root root 4096 May 4 2020 java-1.8.0-openjdk-1.8.0.252.b09-0.fc32.x86_64 drwxr-xr-x. 3 root root 4096 May 22 2020 java-1.8.0-openjdk-1.8.0.252.b09-1.fc32.x86_64 drwxr-xr-x. 3 root root 4096 Jul 17 2020 java-1.8.0-openjdk-1.8.0.262.b10-1.fc32.x86_64 drwxr-xr-x. 3 root root 4096 Jul 28 2020 java-1.8.0-openjdk-1.8.0.265.b01-1.fc32.x86_64 drwxr-xr-x. 3 root root 4096 Oct 21 2020 java-1.8.0-openjdk-1.8.0.272.b10-0.fc32.x86_64 lrwxrwxrwx. 1 root root 21 Sep 10 14:32 jre -> /etc/alternatives/jre lrwxrwxrwx. 1 root root 24 Sep 10 14:32 jre-11 -> /etc/alternatives/jre_11 lrwxrwxrwx. 1 root root 32 Sep 10 14:32 jre-11-openjdk -> /etc/alternatives/jre_11_openjdk lrwxrwxrwx. 1 root root 41 Aug 31 18:50 jre-11-openjdk-11.0.12.0.7-4.fc34.x86_64 -> java-11-openjdk-11.0.12.0.7-4.fc34.x86_64 lrwxrwxrwx. 1 root root 29 Sep 10 14:32 jre-openjdk -> /etc/alternatives/jre_openjdk I think the OpenJDK's scriplets need to be adjusted to remove everything. -- Sincerely, Vitaly Zaitsev (vitaly(a)easycoding.org)

1 year

2
1
0 / 0

Heads-up: grpc 1.41.0 coming to Rawhide with C (core) and C++ soname bumps

by Ben Beasley

In one week (October 6), or slightly later, I will build grpc 1.41.0 for Rawhide (F36). Fedora 35 will remain on 1.39.1. As is traditional for minor releases of grpc, the C++ ABI was broken (soversion bumped from 1.40 to 1.41). This time, the C (core) ABI was also broken (soversion bumped from 18 to 19). I will coordinate builds in a side tag of packages that use the C (core) and/or C++ libraries. Maintainers of the following packages should have received this email directly: • bear • frr • perl-grpc-xs Packages that use the Python bindings should be unaffected, as there should be no incompatible API changes: • buildstream • python-chirpstack-api • python-etcd3 • python-google-api-core • python-google-cloud-core • python-grpc-google-iam • python-opencensus (orphaned) • python-opencensus-proto • python-opentelemetry • python-pytest-grpc • python-xds-protos

1 year

1
1
0 / 0

GNOME only: KeepassXC quirks

by Germano Massullo

KeepassXC comaintainer here. There are many Fedora GNOME Wayland users experiencing quirks in using KeepassXC. Textboxes not showing text that is being written, other quirks with GNOME, etc. Upstream developers said many times that this only happen with Fedora users. Myself I do use KDE Spin and I do not experience these issues (tested on Wayland too) I don't paste bugs titles since they are misleading https://bugzilla.redhat.com/show_bug.cgi?id=1925130 https://bugzilla.redhat.com/show_bug.cgi?id=1941731 (CentOS 8) https://bugzilla.redhat.com/show_bug.cgi?id=1954742 https://github.com/keepassxreboot/keepassxc/issues/5608 plus others that I cannot find again at the moment I would like to ask if you have any idea about why this happens on GNOME only (and not on other distros too) Thank you

1 year, 3 months

10
30
1 / 0

Release criteria proposal: networking requirements

by Adam Williamson

Hi folks! So at this week's blocker review meeting, the fact that we don't have explicit networking requirements in the release criteria really started to bite us. In the past we have squeezed networking-related issues in under other criteria, but for some issues that's really difficult, notably VPN issues. So, we agreed we should draft some explicit networking criteria. This turns out to be a big area and quite hard to cover (who'd've thought!), but here is at least a first draft for us to start from. My proposal would be to add this to the Basic criteria. I have left out some wikitext stuff from the proposal for clarity; I'd add it back in on actually applying the proposed changes. It's just formatting stuff, nothing that'd change the meaning. Anyone have thoughts, complaints, alternative approaches, supplements? Thanks! === Network requirements === Each of these requirements apply to both installer and installed system environments. For any given installer environment, the 'default network configuration tools' are considered to be those the installer documents as supported ways to configure networking (e.g. for anaconda-based environments, configuration via kernel command line options, a kickstart, or interactively in anaconda itself are included). ==== Basic networking ==== It must be possible to establish both IPv4 and IPv6 network connections using DHCP and static addressing. The default network configuration tools for the console and for release-blocking desktops must work well enough to allow typical network connection configuration operations without major workarounds. Standard network functions such as address resolution and connections with common protocols such as ping, HTTP and ssh must work as expected. Footnote titled "Supported hardware": Supported network hardware is hardware for which the Fedora kernel includes drivers and, where necessary, for which a firmware package is available. If support for a commonly-used piece or type of network hardware that would usually be present is omitted, that may constitute a violation of this criterion, after consideration of the [[Blocker_Bug_FAQ|hardware-dependent- issues|normal factors for hardware-dependent issues]]. Similarly, violations of this criteria that are hardware or configuration dependent are, as usual, subject to consideration of those factors when determining whether they are release-blocking ==== VPN connections ==== Using the default network configuration tools for the console and for release-blocking desktops, it must be possible to establish a working connection to common OpenVPN, openconnect-supported and vpnc-supported VNC servers with typical configurations. Footnote title "Supported servers and configurations": As there are many different VPN server applications and configurations, blocker reviewers must use their best judgment in determining whether violations of this criterion are likely to be encountered commonly enough to block a release, and if so, at which milestone. As a general principle, the more people are likely to use affected servers and the less complicated the configuration required to hit the bug, the more likely it is to be a blocker. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net

1 year, 3 months

9
22
0 / 0

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

1 year, 3 months

7
11
0 / 0

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

1 year, 3 months

11
23
0 / 0

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

1 year, 3 months

23
30
0 / 0

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

1 year, 3 months

13
35
0 / 0

what is wrong with this conditional scriplet on rpm.spec

by Sérgio Basto

Hi, I just notice build in mock or koji this scriptlet [1] on a build for Fedora gives me "is rhel 8 or 9" , what I'm missing ? Thank you [1] %if ! 0%{?rhel} >= 8 echo "is not rhel >= 8" %else echo "is rhel 8 or 9" %endif -- Sérgio M. B.

1 year, 4 months

2
3
0 / 0

Announcing LLVM Snapshot Packages for Fedora Linux

by Konrad Kleine

Dear Fedora packagers, developers and users, we have some good news for you: We are beginning to build nightly snapshot packages of LLVM for the latest versions of Fedora Linux (currently 34, 35 and rawhide) for a growing list of architectures. You can grab them here: https://copr.fedorainfracloud.org/coprs/g/fedora-llvm-team/llvm-snapshots/ Feel free to enable the copr repository with $ dnf copr enable @fedora-llvm-team/llvm-snapshots and then install the i.e. latest clang with $ dnf install clang Beware, that a snapshot release of LLVM is probably more unstable than a regular release! If you run into a problem, I would kindly ask you to wait and try it again with the next snapshot. We hope you enjoy this peek into the next version of LLVM that you can now try without too much hassle and without compiling it every day on your own. Regards, Konrad Kleine Senior Software Engineer, Platform Tools Red Hat <https://www.redhat.com> kkleine(a)redhat.com M: +49(0)151/21000244 D87A 77F4 2A58 C72D 12A7 203B C0A0 2C32 BCB7 3099 <https://www.redhat.com>

1 year, 4 months

7
17
0 / 0

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

devel November 2021