devel July 2022

devel@lists.fedoraproject.org

213 participants
271 discussions

Minizip renaming Fedora Change
by Lukas Javorsky 16 Sep '22

16 Sep '22

Hi fellow contributors, Upstream has reported a request for minizip naming change from "minizip" to "minizip-ng" (minizip-ng is the official name of the upstream package right now). As Fedora should match the upstream naming, I believe this change is necessary. Another naming change is required for the "minizip-compat" package which is the subpackage of the "zlib" package. Upstream requests that we should rename "minizip-compat" to "minizip". I agree with renaming this package as well, however, this could lead to multiple confusions maybe even conflicts for the users. The problem with renaming this package right after renaming the "minizip-ng" could be that the users may be confused about which package is the right "minizip" for them. I believe we could rename the "minizip-compat" to the "minizip" after some larger time period so every package that requires "minizip" changes the requirements to "minizip-ng" and there is no confusion anymore. The first step I want to do is to create a Fedora Change, which contains this whole process and is well communicated within the community. This email serves as a heads-up and also opens a possibility for any tips that you can give me with this change. This is my first time doing a change like this so it may have some bumps along the way, but I'm willing to learn and improve, so feel free to give me any advice you think could benefit me with this process. Thank you for understanding and sorry for quite a long email. Lukas -- S pozdravom/ Best regards Lukáš Javorský Software Engineer, Core service - Databases Red Hat <https://www.redhat.com> Purkyňova 115 (TPB-C) 612 00 Brno - Královo Pole ljavorsk(a)redhat.com <https://www.redhat.com>

7 13

nodejs-electron
by Andreas Schneider 15 Sep '22

15 Sep '22

Hello! Over the past 8 month, I've been working on getting Electron [1] built on Fedora. Yesterday I was finally able to do the first working build for Fedora Rawhide [2]. This was possible because we finally have ffmpeg [3] in Fedora. My use for Electron is that I want to run signal-desktop [4] on Fedora. You can get electron and signal-packages packages for it at [5]. Is there interest to bring nodejs-electron into Fedora and if yes, would someone be interested to maintain it? I don't have the time to maintain it but I'm happy to help as a co-maintainer. Best regards Andreas [1] https://www.electronjs.org/ [2] https://build.opensuse.org/package/show/network:im:signal/nodejs-electron [3] https://src.fedoraproject.org/rpms/ffmpeg/ [4] https://build.opensuse.org/package/show/network:im:signal/signal-desktop [5] https://download.opensuse.org/repositories/network:/im:/signal/ Fedora_Rawhide/x86_64/

8 25

F38 Proposal: SPDX License Phase 1 (Self-Contained Change proposal)
by Ben Cotton 08 Sep '22

08 Sep '22

https://fedoraproject.org/wiki/Changes/SPDX_Licenses_Phase_1 This document represents a proposed Change. As part of the Changes process, proposals are publicly announced in order to receive community feedback. This proposal will only be implemented if approved by the Fedora Engineering Steering Committee. == Summary == Transition from Fedora's short name of licenses to standardized [https://spdx.org/licenses/ SPDX license] [https://spdx.dev/specifications/ formula]. == Owner == * Name: [[User:msuchy| Miroslav Suchý]] * Name: [[User:jlovejoy| Jilayne Lovejoy]] * Name: [[User:ngompa| Neal Gompa]] * Name: [[User:dcantrell| David Cantrell]] * Name: [[User:rfontanaref| Richard Fontana]] * Name: [[User:mattdm| Matthew Miller]]  * Email: msuchy(a)redhat.com, dcantrell(a)redhat.com, jlovejoy(a)redhat.com, ngompa13(a)gmail.com, rfontana(a)redhat.com == Detailed Description == In the past, Fedora decided to use short names for licenses. Although we documented the short names very well. The identifiers were never standard. In the meantime, SPDX identifiers become standard, and [https://wiki.spdx.org/view/Business_Team/Adoption other SW vendors start using it]. In this phase, we want to provide documentation and tooling to allow maintainers to begin using SPDX license ids instead of the old Fedora short names. This move is opt-in. There will be [[Changes/SPDX_Licenses_Phase_2|Phase 2]], where we identify the remaining packages and help them to migrate to the SPDX formula. == Feedback == Ancient [https://lists.fedoraproject.org/archives/list/legal@lists.fedoraproject.org… feedback from SPDX organization]. Summary from [https://lists.fedoraproject.org/archives/search?q=spdx&page=1&mlist=legal%4… fedora-legal mailing list]: we want this to happen, but this is big scope and likely will happen over more than one release. Summary from packaging-committee: * [https://pagure.io/packaging-committee/pull-request/971#]: older PR to change packaging guidelines * [https://pagure.io/packaging-committee/pull-request/1142]: present PR that needs more updating Summary from devel-list: TBD == Benefit to Fedora == The use of a standardized identifier for license will align Fedora with other distributions. And allows efficient and reliable identification of licenses. == Scope == * Proposal owners (things sorted by done/todo and by priorities): ** Miroslav Suchý: license-fedora2spdx - done ** Jilayne Lovejoy: map rest of Fedora licenses to SPDX ids - done ** David Cantrell: create machine-readable format and new repo - done ** David Cantrell: merge mapping of Fedora licenses to SPDX ids to new data format/repo - done ** Richard Fontana & Jilayne Lovejoy: review update all licensing info and legal pages in wiki - in process ** Jilayne Lovejoy & Richard Fontana: create and populate new Docs pages for legal and licensing info - in process ** Miroslav Suchy - create [https://gitlab.com/fedora/legal/fedora-license-data fedora-license-data package] (with data from rpminspect-data-fedora) - TODO ** David Cantrell: separate licenses from rpminspect-data-fedora [https://bugzilla.redhat.com/show_bug.cgi?id=2077914 BZ 2077914] - TODO ** Miroslav Suchý: allow `license-validate` to use spdx - TODO ** David Cantrell: generate from license data to new Docs page similar to [https://fedoraproject.org/wiki/Licensing:Main#Software_License_List Licensing:Main] ** SOMEBODY: create a webhook that updates Docs page after the merge to fedora-license-data - TODO ** Jilayne Lovejoy: prepare PR for updates to packaging guidelines - in the process [https://pagure.io/packaging-committee/pull-request/1142] ** SOMEBODY: help maintainers who want to change license string to SPDX identifiers proactively. * Out of Scope: In this phase, we do not target to move **all** packages to SPDX identifiers. That will be done in [[Changes/SPDX_Licenses_Phase_2|Phase 2]]. In [[Changes/SPDX_Licenses_Phase_2|Phase 2]] we will identify the remaining packages and open BZ or PR. * Other developers: Early adopters can migrate their License tag to the SPDX identifiers. Proposal owners will gather feedback and will work on potential problems. We want to have all bits ready so that maintainers can start changing the spec files just after Fedora 37 branching (summer 2022). * Release engineering: * Policies and guidelines: Licensing page, packaging guidelines has to be altered. * Trademark approval: N/A (not needed for this Change) * Alignment with Objectives: == Upgrade/compatibility impact == License strings are not used anything in run time. This change will not affect the upgrade or runtime of Fedora. During the transition period, developer tools like rpminspect, licensecheck, etc. may produce false negatives. And we have to define a date where we flip these tools from old Fedora's short names to the SPDX formula. == How To Test == Users should not need any testing. These steps are for package maintainers: * Fetch your license string from `License` tag in SPEC file. * Test that your current Fedora's short name is correct. E.g. $ license-validate -v 'MIT or GPLv1' Approved license * Convert license string to SPDX formula: $ license-fedora2spdx 'MIT or GPLv1' Warning: more options how to interpret MIT. Possible options: ['Adobe-Glyph', 'MIT-CMU', 'MIT-CMU', 'HPND', 'HPND', 'no-spdx-yet (MIT license (also X11))', 'SGI-B-2.0', 'SGI-B-2.0', 'SMLNJ', 'MIT-enna', 'MIT-feh', 'mpich2'] mpich2 or GPL-1.0-only In this example, the short name `GPLv1` can be converted straight to `GPL-1.0-only`. But short name `MIT` stands for several licenses with different [https://spdx.org/licenses/ SPDX identifiers]. You have to examine what license is package actually using. `license-fedora2spdx` will try to convert the formula and use one of the options but without any heuristics. You need to manually review the license. You can check if SPDX formula is correct using: $ license-validate -v --file FIXME "MIT-CMU or GPL-1.0-only" == User Experience == Users should be able to use standard software tools that audit licenses. E.g. for Software Bills of Materials. == Dependencies == No other dependencies. == Contingency Plan == * Contingency mechanism: In this first phase, if something goes wrong, we can 'git revert' each change in dist-git. It is expected that in the first phase, there will be only a few packages altered. It may be a few hundred, but it is still doable to revert. * Contingency deadline: Beta freeze. But it is expected that not all packages will be converted by that time and the change will continue in the next release. * Blocks release? No. This change has no impact on runtime of any package. == Documentation == N/A (not a System Wide Change) == Release Notes == -- Ben Cotton He / Him / His Fedora Program Manager Red Hat TZ=America/Indiana/Indianapolis

15 39

Planning to start unifying native and mingw packages
by Sandro Mani 03 Sep '22

03 Sep '22

Hi Following recent discussions and to reduce the maintenance burden, I'm planning to start merging native and mingw packages. Initially, I'll be looking at these packages where I maintain both variants: eigen3 mingw-eigen3 enchant2 mingw-enchant2 freeimage mingw-freeimage gdal mingw-gdal GeographicLib mingw-GeographicLib geos mingw-geos giflib mingw-giflib gtkspell3 mingw-gtkspell3 gtkspellmm30 mingw-gtkspellmm30 jxrlib mingw-jxrlib leptonica mingw-leptonica libgeotiff mingw-libgeotiff libimagequant mingw-libimagequant libkml mingw-libkml librttopo mingw-librttopo libspatialite mingw-libspatialite libwebp mingw-libwebp openjpeg2 mingw-openjpeg2 OpenSceneGraph mingw-OpenSceneGraph osgearth mingw-osgearth podofo mingw-podofo proj mingw-proj python-pillow mingw-python-pillow qtspell mingw-qtspell shapelib mingw-shapelib svg2svgt mingw-svg2svgt tesseract mingw-tesseract uriparser mingw-uriparser I'm performing test builds here [1]. Once I've got them all building there, if there are no objections, I plan to push to F37 and retire all the corresponding mingw repos. Sandro [1] https://copr.fedorainfracloud.org/coprs/smani/mingw-unified-spec/builds/

7 27

F37 proposal: Emacs 28 (Self-Contained Change proposal)
by Ben Cotton 28 Aug '22

28 Aug '22

https://fedoraproject.org/wiki/Changes/Emacs_28 This document represents a proposed Change. As part of the Changes process, proposals are publicly announced in order to receive community feedback. This proposal will only be implemented if approved by the Fedora Engineering Steering Committee. == Summary == Update GNU Emacs to 28.1 release. This release includes a wide variety of new features, including native compilation of Lisp files. == Owner == * Name: [[User:Bhavin192| Bhavin Gandhi]] * Email: bhavin192(a)fedoraproject.org == Detailed Description == The Emacs package will be updated to 28.1 release of GNU Emacs. This will have native compilation feature enabled, and will package additional natively compiled Lisp files. == Benefit to Fedora == This major version of Emacs has bugfixes and new features which also improve the overall speed of Emacs. == Scope == * Proposal owners: Upgrade the Emacs package to 28.1 * Other developers: N/A * 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) * Alignment with Objectives: N/A == Upgrade/compatibility impact == Users might see some warnings while their installed Emacs packages get natively compiled after first launch post the upgrade. These warnings won't break any functionality, though the users are encouraged to update their Emacs packages. == How To Test == # Run dnf update emacs # Open Emacs and check if inbuilt functionalities and packages work as indented. == User Experience == https://www.gnu.org/software/emacs/#Releases * Lisp files are natively compiled, this results in speed improvements for most of the functionalities * Much improved display of Emoji and Emoji sequences * New system for documenting groups of functions == Dependencies == N/A == 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), No == Documentation == * https://www.gnu.org/software/emacs/news/NEWS.28.1 * https://src.fedoraproject.org/rpms/emacs/pull-request/12 == Release Notes == The upstream release notes are available at https://www.gnu.org/software/emacs/news/NEWS.28.1 These can also be accessed from within Emacs by doing `C-h n`. -- Ben Cotton He / Him / His Fedora Program Manager Red Hat TZ=America/Indiana/Indianapolis

10 25

F37 proposal: Supplement of Server distributables by a KVM VM disk image (Self-Contained Change proposal)
by Ben Cotton 26 Aug '22

26 Aug '22

https://fedoraproject.org/wiki/Changes/Supplement-server-by-kvm-vm-image This document represents a proposed Change. As part of the Changes process, proposals are publicly announced in order to receive community feedback. This proposal will only be implemented if approved by the Fedora Engineering Steering Committee. == Summary == Virtualization has long been a steadily growing use case of Fedora Server Edition, but it is still time consuming and tedious for the system administrator to create a Fedora Server VM. Supplementing the downloads by a KVM VM image remedies the deficiency. == Owner == * Name: [[User:pboy| Peter Boy on behalf of Server WG]] * Email: pboy(a)uni-bremen.de == Detailed Description == The creation of the VM disk image, uses the same kickstart files and installation groups as the standard full installation, except of course for the hardware-specific items. The image is optimized for KVM. That way, the VM resembles a default server installation as closely as possible. All administrative tools are available reliably from the beginning, all administrative routines and helps (scripts) can be used in the same way. All application services work in the identical way. A default VM installation takes 1-2 minutes instead of about 30 mins. == Feedback == The change proposal is based on an extensive discussion of the server WG and has become part of its work program. For example, the server documentation on virtualization has already been significantly expanded in parallel and will continue to be supplemented and updated on an ongoing basis. This is a response to the importance of the topic. == Benefit to Fedora == Significantly improves usability for Fedora Server Edition administrators when deploying a Fedora Server Edtion VM. It thus makes Fedora Server Edition more attractive, especially for new users without extensive experience with Fedora. It thus helps to expand our user base. Fedora finally provides an installation path for a Fedora Server VM that is built entirely on Fedora Resources, subject to Fedora quality control, and compliant with Fedora principles. Until now, if a system administrator has to install a VM preferable without the hassles of a full default installation, we could only recommend third party binary blob (e.g. virt-builder), which is a violation of our own core principles. In addition, the third party products do not provide a 'Fedora Server Edition', but their own different concept and vision of a server, under the name Fedora Server. == Scope == * Proposal owners: A kickstart file for ImageFactory is completed and locally tested. * Other developers: n/a * Release engineering: [https://pagure.io/releng/issues #10768] * 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 == none == How To Test == Basically, the same test procedures as for the full install apply. 1. Install a Fedora Server Edition including virtualization, follow the Server documentation 2. Import the Fedora Server disk image following the Server documentation (staging), either using Cockpit or cli virt-install 3. Use the VM with your intendend server applications. == User Experience == Users (system administrators) will have a VM install method available, which saves them a lot of time and efforts. == Dependencies == none == 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), No == Documentation == N/A (not a System Wide Change) Fedora Server documentation is available. == Release Notes == TBD -- Ben Cotton He / Him / His Fedora Program Manager Red Hat TZ=America/Indiana/Indianapolis

6 7

Retiring the pcre package from Fedora
by Lukas Javorsky 23 Aug '22

23 Aug '22

Hi, As from the pcre-8.45, the upstream stopped supporting this library. The recommended procedure is to switch onto the new pcre2 library that has full upstream support. [1] As a result of this announcement, the older PCRE library in Fedora will be retired. Without upstream support, we don't have enough capacity to keep up with the security and bugs-related issues, and thus we will support only the new PCRE2 library. [2] The retirement procedure will happen in the upcoming weeks, so if you would like to take over the package let us know. The list of affected packages: 389-ds-base 389-ds-base-libs EMBOSS-libs Falcon GMT Io-language Thunar adanaxisgpl aide aircrack-ng anope-pcre bti ccze cegui cegui06 clisp clover2 clover2-devel clover2-libs coccinelle compton condor condor-classads cppcheck cppcheck-gui cyrus-imapd-libs eterm ettercap freeradius freeradius-utils ganglia ganglia-gmond ghc-highlighting-kate ghc-pcre-light ghc-regex-pcre gnome-builder gnome-text-editor grep groonga-httpd haxe hydra i3 i3-gaps imapfilter kdelibs kdelibs3 kf5-kjs kismet libast libeplplot liblognorm libmodsecurity libprelude lnav mle mod_auth_openid mod_auth_openidc mod_qos mod_security mod_security-mlogc monotone ncid nekovm ngrep nmap ocaml-pcre octave openCOLLADA openscap openscap-engine-sce opensips opensips-regex pads pcre-cpp pdfgrep perl perl-HTML-Template-Pro perl-re-engine-PCRE picom pl poco-debug poco-foundation postfix-pcre powwow prboom-plus prelude-lml privoxy python3-qutepart python3-scss rasqal regexxer remctl root-core rudiments slang-slsh sord sslh suricata sway swig syncevolution-libs syncevolution-libs-akonadi syslog-ng syslog-ng-mqtt syslog-ng-slog the_foundation the_silver_searcher tin tintin tinyfugue trafficserver uwsgi vdr-epgfixer watchman wmweather+ xastir xfce4-verve-plugin xgrep xmlcopyeditor zabbix zabbix-agent zabbix-proxy-mysql zabbix-proxy-pgsql zabbix-proxy-sqlite3 zabbix-server-mysql zabbix-server-pgsql zsh --- Thank you for understanding. Lukas [1] https://www.pcre.org/ [2] https://github.com/PCRE2Project/pcre2 -- S pozdravom/ Best regards Lukáš Javorský Software Engineer, Core service - Databases Red Hat <https://www.redhat.com> Purkyňova 115 (TPB-C) 612 00 Brno - Královo Pole ljavorsk(a)redhat.com <https://www.redhat.com>

22 69

Need to rename package? libphidget -> libphidget22
by Richard Shaw 21 Aug '22

21 Aug '22

I am trying to update the libphidget package which has not been updated in Fedora since 2014. Apparently in 2017 the name was changed to "libphidget22" I'm guessing the soversion being embedded in the library name, seems awfully Debian centric. The bigger problem is the version was reset from something 2.x back to 1.0.0, the current version being 1.10. I can bump the epoch easy enough but it still feels wrong. Should I rename the package to libphidget22 and obsoletes/provide the original package? The supplementary libraries also have "22" on the end: https://www.phidgets.com/docs/OS_-_Linux#Source_Install-0 Click "Source Install" tab. Thoughts? Thanks, Richard

3 4

Missing LLVM stack bugfix updates in stable Fedora branches
by Fabio Valentini 19 Aug '22

19 Aug '22

Hi all, Today I encountered another LLVM-specific bug that affects at least one Rust package and causes non-working code to be produced, which prompted this question: Why are stable releases not getting bugfix releases of LLVM? Fedora 35 is stuck at LLVM 13.0.0, while 13.0.1 has been released. Fedora 36 is stuck at LLVM 14.0.0, while 14.0.1 through 14.0.6 have been released. Even Rawhide is at LLVM 14.0.5, but has not been updated to 14.0.6 yet (released over 3 weeks ago). However, the llvm13 compat package that exists on Fedora 36+ *has* been updated to version 13.0.1, so I'm not sure why this update wasn't also pushed to Fedora 35, where LLVM 13 is the default, and would benefit much more from bugfixes provided by 13.0.1. Given that llvm and the whole llvm ecosystem (clang, lld, rustc, ghc on some architectures, mesa/llvmpipe) are an important part of our stack, it seems bad that stable releases are missing out on several bugfix updates for those critical packages. I appreciate that updating ~a dozen packages for new LLVM point releases is work, but I don't think having outdated LLVM components on stable releases of Fedora is a good idea, either. What can we do to improve this situation? Fabio

3 8

Help needed: build failure trying to upgrade healpix
by Mattia Verga 17 Aug '22

17 Aug '22

Hello folks, I've been trying to update healpix package to latest version, so that I can submit a PR to the package maintainer. Current version is a couple of years old. Unfortunately, the automated build process available in the package itself isn't suitable for our needs, so each component (currently the package provides Fortran, C, C++ and Java) must be compiled on its own. Moreover, a library is bundled (libsharp), which is needed by the C++ component... there are some reasons why not unbundle it, I will not list them here as they're not related to my request. I did an heavy rewrite of the spec file to adapt to the new version and I can build everything fine locally, but when I try a koji scratch build it fails because the configure script of the C++ component cannot find a cfitsio header. That's weird, because the C component is able to find cfitsio and the header, while the C++ component finds cfitsio but not the header... I'm at a dead end, can someone have a look at the scratch build [1] and explain me where's the fault? Thanks Mattia [1] https://koji.fedoraproject.org/koji/taskinfo?taskID=90263817

6 13

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 July 2022