devel November 2021

devel@lists.fedoraproject.org

199 participants
342 discussions

Claim delve
by Alejandro Saez Morollon 29 Jun '22

29 Jun '22

Hi there, folks. Delve[0] (a Golang debugger) was retired due to the impossibility of building a new version of delve for dependencies issues. I would like to claim the package and fix the situation. I already have one of the dependencies[1] in the works. I already talked with the original maintainer (he's in cc) and he is OK with it. Thanks. [0] https://src.fedoraproject.org/rpms/delve [1] https://src.fedoraproject.org/rpms/golang-starlark

2 2

[HEADS UP] -Wl,--as-needed is added in rawhide
by Igor Gnatenko 26 Jun '22

26 Jun '22

It's in redhat-rpm-config-118-1.fc30. If it causes any problems for you - let me know. In the meantime, you can use `%undefine _ld_as_needed` to disable it. Thanks for attention! -- -Igor Gnatenko

4 4

Wine MinGW system libraries
by Zebediah Figura 11 Jun '22

11 Jun '22

Hello all, I'm a contributor to the Wine project. To summarize the following mail, Wine needs special versions of some of its normal dependencies, such as libfreetype and libgnutls, built using the MinGW cross-compiler, and I'm sending out a mail to major distributions in order to get some feedback from our packagers on how these should be built and packaged. For a long time Wine has built all of its Win32 libraries (DLLs and EXEs) as ELF binaries. For various reasons related to application compatibility, we have started building our binaries as PE instead, using the MinGW cross-compiler. It is our intent to expand this to some of our dependencies as well. The list of dependencies that we intend to build using MinGW is not quite fixed yet, but we expect it to include and be mostly limited to the following: * libvkd3d * libFAudio * libgnutls * zlib (currently included via manual source import) * libmpg123 * libgsm * libpng * libjpeg-turbo * libtiff * libfreetype * liblcms2 * jxrlib and dependencies of the above packages (not including CRT dependencies, which Wine provides). There is currently some internal discussion about how these dependencies should be built and linked. There are essentially three questions I see that need to be resolved, and while these resolutions have a significant impact on the Wine building and development process, they also have an impact on distributions, and accordingly I'd like to get input from our packagers to ensure that their considerations are accurately taken into account. (1) Should we build via source import, or link statically, or dynamically? Static linking and source imports are dispreferred by Fedora [1] [2], as by many distributions, on the grounds that they cause duplication of libraries on disk and in memory, and make it harder to update the libraries in question (see also question 2). They also make building and bisecting harder. Note however that if they are linked dynamically, we need to make sure that we load our packages instead of MinGW builds of open-source libraries with applications ship with. Accordingly we need each library to be renamed, and to link to renamed dependencies. For example, if application X ships with its own copy of libfreetype-6.dll, we need to make sure that our gdi32.dll links to libwinefreetype-6.dll instead, and that libwinefreetype-6.dll links to libwineharfbuzz-0.dll and winezlib.dll. I think, although I haven't completely verified yet, that this can be done just with build scripts (i.e. no source patches), by using e.g. --with-zlib=/path/to/winezlib.dll. Accordingly, although static linking and source imports are generally disprefered, it may quite likely be preferable in our case. We don't get the benefits of on-disk deduplication, since Wine is essentially the only piece of software which needs these libraries. (2) If we use dynamic libraries, should dependencies be included in the main wine package, or packaged separately? This is mostly a question for packagers, although it also relates to (3). I expect that Fedora (and most distributions) want to answer "packaged separately" here, on the grounds that this lets them update (say) Wine's libgnutls separately, and in sync with ELF libgnutls, if some security fix is needed. There is a snag, though: we need libraries to be copied into the prefix (there's some internal effort to allow using something like symlinks instead, but this hard and not done yet). Normally we perform this copy every time Wine is updated, but if Wine and its dependencies aren't updated on the same schedule, we may end up loading an old version of a dependency in the prefix, thus missing the point of the update. (3) If dependencies are packaged separately, should Wine build them as part of its build tree (e.g. using submodules), or find and link (statically or dynamically) to existing binaries? Linking to existing binaries is generally preferable: it avoids duplication on disk; it reduces compile times when compiling a single package from source (especially the first time). However, we aren't going to benefit from on-disk duplication. And, most importantly, unlike with ELF dependencies, there is no standardized way to locate MinGW libraries—especially if it comes to Wine-specific libraries. We would need a way for Wine's configure script to find these packages—and ideally find them automatically, or else fall back to a submodule-based approach. If we rely on distributions to provide our dependencies, the best idea I have here would be something like a x86_64-w64-mingw32-pkg-config. And if we use shared libraries rather than static, things get worse: we need to know the exact path of each library and its dependencies so that we can copy (or symlink) them into a user's WINEPREFIX. For what it's worth, the current proposed solution (which has the support of the Wine maintainer) involves source imports and submodules. There's probably room for changing our approach even after things are committed, but I'd still like to get early feedback from distributions, and make sure that their interests are accurately represented, before we commit. In short, it's not clear whether distributions want their no-static-library policies to apply to us as well, or whether we're enough of a special case and would be enough of a pain to package that they'd rather we deal with the hard parts, and I don't want us to make any assumptions. ἔρρωσθε, Zebediah [1] https://docs.fedoraproject.org/en-US/packaging-guidelines/#packaging-static… [2] https://fedoraproject.org/wiki/Bundled_Libraries

9 28

OpenJDK and unremoved directories
by Vitaly Zaitsev 25 May '22

25 May '22

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)

2 1

Heads-up: grpc 1.41.0 coming to Rawhide with C (core) and C++ soname bumps
by Ben Beasley 09 May '22

09 May '22

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 1

GNOME only: KeepassXC quirks
by Germano Massullo 01 Mar '22

01 Mar '22

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

10 30

Release criteria proposal: networking requirements
by Adam Williamson 01 Mar '22

01 Mar '22

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

9 22

F36 Change: Drop NIS(+) support from PAM (System-Wide Change proposal)
by Ben Cotton 16 Feb '22

16 Feb '22

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.org… 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

7 11

libcurl-minimal
by Zbigniew Jędrzejewski-Szmek 10 Feb '22

10 Feb '22

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

11 23

F37 Change: RetireARMv7 (System-Wide Change proposal)
by Ben Cotton 07 Feb '22

07 Feb '22

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

23 30

Jump to page:

2024

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