devel June 2022

devel@lists.fedoraproject.org

201 participants
282 discussions

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: 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

Plan / proposal: enable openQA update testing and potentially gating on Rawhide updates
by Adam Williamson 28 Jul '22

28 Jul '22

Hi folks! We've had openQA testing of updates for stable and branched releases, and gating based on those tests, enabled for a while now. I believe this is going quite well, and I think we addressed the issues reported when we first enabled gating - Bodhi's gating status updates work more smoothly now, and openQA respects Bodhi's "re-run tests" button so failed tests can be re-triggered. A few weeks ago, I enabled testing of Rawhide updates in the openQA lab/stg instance. This was to see how smoothly the tests run, how often we run into unexpected failures or problems, and whether the hardware resources we have are sufficient for the extra load. So far this has been going more smoothly than I anticipated, if anything. The workers seem to keep up with the test load, even though one out of three worker systems for the stg instance is currently out of commission (we're using it to investigate a bug). We do get occasional failures which seem to be related to Rawhide kernel slowness (e.g. operations timing out that usually don't otherwise time out), but on the whole, the level of false failures is (I would say) acceptably low, enough that my current regime of checking the test results daily and restarting failed ones that don't seem to indicate a real bug should be sufficient. So, I'd like to propose that we enable Rawhide update testing on the production openQA instance also. This would cause results to appear on the Automated Tests tab in Bodhi, but they would be only informational (and unless the update was gated by a CI test, or somehow otherwise configured not to be pushed automatically, updates would continue to be pushed 'stable' almost immediately on creation, regardless of the openQA results). More significantly, I'd also propose that we turn on gating on openQA results for Rawhide updates. This would mean Rawhide updates would be held from going 'stable' (and included in the next compose) until the gating openQA tests had run and passed. We may want to do this a bit after turning on the tests; perhaps Fedora 37 branch point would be a natural time to do it. Currently this would usually mean a wait from update submission to 'stable push' (which really means that the build goes into the buildroot, and will go into the next Rawhide compose when it happens) of somewhere between 45 minutes and a couple of hours. It would also mean that if Rawhide updates for inter-dependent packages are not correctly grouped, the dependent update(s) will fail testing and be gated until the update they depend on has passed testing and been pushed. The tests for the dependent update(s) would then need to be re- run, either by someone hitting the button in Bodhi or an openQA admin noticing and restarting them, before the dependent update(s) could be pushed. In the worst case, if updated packages A and B both need the other to work correctly but the updates are submitted separately, both updates may fail tests and be blocked. This could only be resolved by waiving the failures, or replacing the separate updates with an update containing both packages. All of those considerations are already true for stable and branched releases, but people are probably more used to grouping updates for stable and branched than doing it for Rawhide, and the typical flow of going from a build to an update provides more opportunity to create grouped updates for branched/stable. For Rawhide the easiest way to do it if you need to do it is to do the builds in a side tag and use Bodhi's ability to create updates from a side tag. As with branched/stable, only critical path updates would have the tests run and be gated on the results. Non-critpath updates would be unaffected. (There's a small allowlist of non-critpath packages for which the tests are also run, but they are not currently gated on the results). I think doing this could really help us keep Rawhide solid and avoid introducing major compose-breaking bugs, at minimal cost. But it's a significant change and I wanted to see what folks think. In particular, if you find the existing gating of updates for stable/branched releases to cause problems in any way, I'd love to hear about it. Thanks folks! -- Adam Williamson Fedora QA IRC: adamw | Twitter: adamw_ha https://www.happyassassin.net

5 9

Suggestion: Use a unified kernel image by default in the future.
by Sharpened Blade 22 Jul '22

22 Jul '22

Use unified kernel images by default for new releases. This can allow for the local installation to sign the kernel and the initrd, so the boot chain can be verified until after the uefi. Currently, the initrd can be modified by attackers, so even if the / partition is encrypted, the systems data can be read on the next boot. If the kernel image, which includes the command line, and the initrd, is signed then it is harder to comprimise the system. The system can still be comprimised if the uefi is modified. If this was used, then the kernel could no longer be signed in the package by the fedora infrastructure. To still support secure boot, the kernel image would have to be signed be key stored on disk on every update. If the disk is encrypted, the private key can still be protected from attackers. On installation, or update for existing installs, a public/private keypair would be generated, and trusted by the shim. This has a few problems, if the root user is hacked, then the kernel can be tampered with. But this is not a very big problem because if the root user is hacked, then for example systemd can be changed, secure boot will not protect you. It will also mean that if the user want to modify the kernel command line or initrd, they have to regenerate the entire kernel image. This can also break some users install, if they use a non-default boot process, or have a buggy uefi implementation. For non-uefi architectures, this change could be ignored.

22 103

F37 proposal: RPM Macros for Build Flags (System-Wide Change proposal)
by Ben Cotton 20 Jul '22

20 Jul '22

https://fedoraproject.org/wiki/Changes/RPMMacrosForBuildFlags 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 == Create a corresponding macro for each compiler flag in the redhat-rpm-config macro file and create "extra flag" macros to make it easier for packages to add and remove compiler flags. == Owner == * Name: [[User:tstellar| Tom Stellard]] * Email: <tstellar(a)redhat.com> == Detailed Description == The macros file in the redhat-rpm-config package contains a list of default compiler flags for packages to use when compiling C, C++, and Fortran packages. There is currently no standard way to remove or add to the set of default flags. Most packages use a combination of echo and sed to remove unwanted flags or add new ones. Some examples: compiler-rt: [https://src.fedoraproject.org/rpms/compiler-rt/blob/rawhide/f/compiler-rt.s… global optflags %(echo %{optflags} -D_DEFAULT_SOURCE)] julia: [https://src.fedoraproject.org/rpms/julia/blob/rawhide/f/julia.spec#_267 %global optflags %(echo %{optflags} | sed 's/-Wp,-D_GLIBCXX_ASSERTIONS //')] This change will add new macros which will make it easier for packages to add and remove their own compiler flags. This strategy is already used to some extent with feature macros like %{_lto_cflags}, %{_hardening_cflags}, etc, but these new macros will give packagers even more fine-grained control over the options. The proposed macros for adding new flags are: %_pkg_extra_cflags %_pkg_extra_cxxflags %_pkg_extra_fflags %_pkg_extra_ldflags These will be added to %{build_cflags}, %{build_cxxflags}, %{build_fflags}, and %{build_ldflags} respectively to allow packges to add their own flags to the default list: e.g. %build_cflags %{optflags} %{_pkg_extra_cflags} The proposed new macros to represent existing flags are: %_flag_fstack_protector_strong -fstack-protector-strong %_flag_z_now -Wl,-z,now %_flag_z_defs -Wl,-z,defs %_flag_flto_auto -flto=auto %_flag_ffat_lto_objects -ffat-lto-objects %_flag_o -O2 %_flag_f_exceptions -fexceptions %_flag_g -g %_flag_grecord_gcc_switches -grecord-gcc-switches %_flag_pipe -pipe %_flag_wall -Wall %_flag_werror_format_security -Werror=format-security %_flag_fortify_source -Wp,-D_FORTIFY_SOURCE=2 %_flag_glibcxx_assertions -Wp,-D_GLIBCXX_ASSERTIONS %_flag_asynchronous_unwind_tables -fasynchronous-unwind-tables %_flag_fstack_clash_protection -fstack-clash-protection %_flag_fcf_protection -fcf-protection %_flag_mbranch_protection_standard -mbranch-protection=standard With these new macros, the examples from above could be re-written as: compiler-rt: %global _pkg_extra_cflags -D_DEFAULT_SOURCE julia: %global _flag_glibcxx_assertions %{nil} For more details see the [https://src.fedoraproject.org/fork/tstellar/rpms/redhat-rpm-config/c/0ee9a8… Prototype Implementation]. In addition to adding these new macros, the packaging guidelines will be updated to require that all new flags added to redhat-rpm-config have their own RPM macro. == Benefit to Fedora == * It will provide a standard way to disable existing compiler flags or enable new ones that is more simple and robust than the existing echo + sed solution. * It will make it easier to determine which packages disable or add compiler flags by doing a simple grep of the spec files. * It will make it easier for toolchain developers to experiment with adding new flags to the distribution as this can be done with a simple macro definition instead of patching redhat-rpm-config. == Scope == * Proposal owners: ** Proposal owners will update the redhat-rpm-config package and add the new macros. ** Proposal owners will test the changes to ensure that the correct flags are still being used. * Other developers: ** Other developers may, but are not required to, update their packages to use the new macros. * Release engineering: [https://pagure.io/releng/issues/10819 #10819] * Policies and guidelines: ** The Fedora packaging policy will be updated to require that new flags added to redhat-rpm-config come with their own RPM macro. * Trademark approval: N/A (not needed for this Change) * Alignment with Objectives: == Upgrade/compatibility impact == None. == How To Test == * This can be tested by inspecting the value of the %{build_cflags}, %{build_cxxflags}, %{build_fflags}, and %{build_ldflags} and ensuring they are the same before and after the change. * This can be tested by modifying some of the new macros in a spec file and ensuring that the changes appear in the appropriate macro mentioned above. == User Experience == This is a change for developers and will have no impact to the user experience. == Dependencies == None. == Contingency Plan == * Contingency mechanism: (What to do? Who will do it?) Change owner will revert the update to redhat-rpm-config. * Contingency deadline: Mass Rebuild * Blocks release? N/A (not a System Wide Change), No == Documentation == None. == Release Notes == None. -- Ben Cotton He / Him / His Fedora Program Manager Red Hat TZ=America/Indiana/Indianapolis

8 16

F37 proposal: Python: Add -P to default shebangs (System-Wide Change proposal)
by Ben Cotton 19 Jul '22

19 Jul '22

https://fedoraproject.org/wiki/Changes/PythonSafePath == Summary == The [https://docs.python.org/3.11/using/cmdline.html#cmdoption-P `-P` flag] will be added to the Python shebang macros (`%{py3_shbang_opts}`, `%{py3_shebang_flags}`, ...). Packages that adhere to those macros will change their Python shebangs from `#! /usr/bin/python3 -s` to `#! /usr/bin/python3 -sP` and as a result, will no longer have the directory of the script (such as `/usr/bin`) in `sys.path`. An opt-out mechanism exists. == Owner == * Name: [[User:Churchyard|Miro Hrončok]], [[User:Vstinner|Victor Stinner]] * Email: python-maint(a)redhat.com == Detailed Description == All Python 3 shebang RPM macros will be changed to contain one more flag: `-P`. Previously, they contained `-s`, now they will contain `-sP`. From the [https://docs.python.org/3.11/using/cmdline.html#cmdoption-P documentation for the `-P` option]: :Don’t prepend a potentially unsafe path to `sys.path`: : :* `python -m module` command line: Don’t prepend the current working directory. :* `python script.py` command line: Don’t prepend the script’s directory. If it’s a symbolic link, resolve symbolic links. :* `python -c code` and `python` (REPL) command lines: Don’t prepend an empty string, which means the current working directory. In shebangs, only the middle option (''don’t prepend the script’s directory'') is relevant. Consider the following executbale script installed as `/usr/bin/let-there-be-fun`: #! /usr/bin/python3 -s import abc ... When the script is directly executed (e.g. by running `let-there-be-fun` from the console), the script's directory (`/usr/bin`) is prepended to `sys.path`. Python tries to locate an importable `abc` module in `/usr/bin` first. This can cause real issues: [https://bugzilla.redhat.com/2057340 python3-notebook: ImportError: bad magic number in six] and [https://github.com/benjaminp/six/issues/359 bad magic number in six]. When the shebang includes `-P`: #! /usr/bin/python3 -sP import abc ... ...the script's directory (`/usr/bin`) is '''not''' prepended to `sys.path`. The change owners consider this approach safer for the majority of Fedora's RPM packages. By default, '''all standardly RPM-packaged Python packages with scripts in `/usr/bin` will gain the `-P` flag in their shebang''', assuming the software is packaged in a way that respects the Python shebang RPM macros (see below for opt-out and explicit opt-in mechanisms). Due to the variety of ways such scripts can be created/packaged, there will likely be packages that will not be affected by the change automatically. (In other words, the change is applied on RPM macro level, no added mechanics to force the flag, such as BRP scripts, are planned as part of this change.) === List of RPM macros that will gain `-P` === * `%{py3_shbang_opts}` * `%{py3_shbang_opts_nodash}` * `%{py3_shebang_flags}` * `%{py_shbang_opts}` * `%{py_shbang_opts_nodash}` * `%{py_shebang_flags}` === Opting out === If the new behavior is not desirable to your package amend the macros (e.g. with `sed`) to remove the `P` flag. If you use the [https://docs.fedoraproject.org/en-US/packaging-guidelines/Python/ current Python packaging guidelines], e.g. `%pyproject_wheel` and `%pyproject_install`, use: # Don't add -P to Python shebang # This package only works when /usr/bin is in sys.path (use your own rationale here) %global py3_shebang_flags %(echo %py3_shebang_flags | sed s/P//) If you use the [https://docs.fedoraproject.org/en-US/packaging-guidelines/Python_201x/ 201x-era Python packaging guidelines], e.g. `%py3_build` and `%py3_install`, use: # Don't add -P to Python shebang # This package only works when /usr/bin is in sys.path (use your own rationale here) %global py3_shbang_opts %(echo %py3_shbang_opts | sed s/P//) (The only difference is the name of the macro.) === Opting in === If you use the [https://docs.fedoraproject.org/en-US/packaging-guidelines/Python/ current Python packaging guidelines], e.g. `%pyproject_wheel` and `%pyproject_install`, the standard set of Python shebang flags is applied to all files with Python shebangs installed in `/usr/bin/`. If you use the [https://docs.fedoraproject.org/en-US/packaging-guidelines/Python_201x/ 201x-era Python packaging guidelines], e.g. `%py3_build` and `%py3_install`, the standard set of Python shebang flags might be applied to some files and not applied to others depending on the exact structure of the packaged software. If you wish to explicitly apply the standard set of Python shebang flags on a certain file that is not handled automatically, use [https://docs.fedoraproject.org/en-US/packaging-guidelines/Python/#py3_sheba… the `%py3_shebang_fix` macro]. === What if the packager changes `%__python3` to an older version of Python === The `-P` flag was introduced in Python 3.11. When `%__python3` is redefined to an older Python version, e.g. `/usr/bin/python3.10`, including the `-P` flag in shebangs would break the scripts. Hence, the flag will be included conditionally, presumably somehow like this: <nowiki>%py3_shbang_opts -s%(%{__python3} -Ic "import sys; print('P' if hasattr(sys.flags, 'safe_path') else '')")</nowiki> === What if the admin/user changes `/usr/bin/python3` to an older version of Python === The `-P` flag was introduced in Python 3.11. When an admin/user changes `/usr/bin/python3` to point to an older version of Python, e.g. `/usr/bin/python3.10`, including the `-P` flag in shebangs would break the scripts. However, changing `/usr/bin/python3` to a different Python would ''brick'' a Fedora system even now. So we don't consider that an issue. See an example that changes `/usr/bin/python3` to Python 3.9 (don't try this at home): [root@086a2804411a /]# head -n1 /usr/bin/dnf #!/usr/bin/python3 [root@086a2804411a /]# dnf --version 4.12.0 ... [root@086a2804411a /]# sudo ln -sf /usr/bin/python3.9 /usr/bin/python3 [root@086a2804411a /]# dnf --version Traceback (most recent call last): File "/usr/bin/dnf", line 61, in <module> from dnf.cli import main ModuleNotFoundError: No module named 'dnf' === Risks === As with any other change, there is a risk that this will break things. The change owners plan to test the change extensively via Copr before they deploy the change in Rawhide. If things go badly, they are prepared to delay or cancel the change. The [https://docs.fedoraproject.org/en-US/packaging-guidelines/Python_201x/ 201x-era Python RPM macros] set the shebang flags by a weird hack. As a result, it is not well-defined what scripts will be affected by this change. The change owners are aware that: # not all Python scripts in `/usr/bin` will have the `-P` flag automatically # some scripts '''not''' in `/usr/bin` might gain the `-P` flag as well The first point is an acceptable gradual deployment of the default flag. The second point is not very dangerous because we don't except users to directly execute Python scripts via shebangs when such scripts are not in `$PATH`. If a problematic package is found, it can opt-out easily. If this causes too much friction, we will only change the flag used in the `%pyproject_install` macro, leaving packages with the "legacy" macros intact. == Feedback == * Relevant upstream discussion: [https://discuss.python.org/t/13896 Should console_scripts entry points exclude the scripts directory from sys.path?] * Adding `-P` to Python: [https://github.com/python/cpython/issues/57684 GitHub issue], [https://mail.python.org/archives/list/python-dev@python.org/thread/IU5Q2AXA… email thread] * [https://github.com/rpm-software-management/dnf/pull/1815#pullrequestreview-… dnf maintainers response for doing this explicitly in dnf first] Generally, people seem to think that this is a good thing. They are afraid to change the default behavior of Python but welcome using this flag for system-installed scripts. == Benefit to Fedora == Python programs in `/usr/bin` will be less fragile to other random files being present in `/usr/bin`. Real hard-to-debug issues like [https://bugzilla.redhat.com/2057340 python3-notebook: ImportError: bad magic number in six] and [https://github.com/benjaminp/six/issues/359 bad magic number in six] will not happen. == Scope == * Proposal owners: ** Test everything in Copr ** If everything works, change the flags either before the Python 3.11 rebuild or before the Fedora 37 Mass Rebuild ** Provide guidance to packagers, fix bugs if needed * Other developers: ** Observe their packages, find and report bugs, opt-out if needed ** Volunteerily opt-in by calling the `%py3_shebang_fix` macro and/or by converting their packages to `%pyproject_install` * Release engineering: [https://pagure.io/releng/issue/10784 #10784] * Policies and guidelines: The new flag needs to be documented in the Python packaging guidelines (old and new) * Trademark approval: not needed for this Change * Alignment with Objectives: no == Upgrade/compatibility impact == No impact is anticipated. == How To Test == * Low level: Examine the value of the changed RPM macros, it should contain the `-P` flag * Middle level: Examine the shebang lines of RPM-installed Python scripts in `/usr/bin`, it should contain the `-P` flag * High level: Tests that RPM-installed Python scripts still behave as expected but don't try to import stuff from `/usr/bin` == User Experience == Users of RPM-installed scripts should get a safer experience by default. Users of Python should not observe a difference, the behavior is not a new default: the `-P` flag needs to be explicitly used. == Dependencies == We need [[Changes/Python3.11]] first. == Contingency Plan == * Contingency mechanism: defer to F38; only add `-P` to shebangs in `%pyproject_install` to keep backward compatibility of the old macros; revert and rebuild * Contingency deadline: 1 week before the beta freeze * Blocks release? No == Documentation == * This page * TBD Updated Python guidelines * https://docs.python.org/3.11/using/cmdline.html#cmdoption-P * https://docs.python.org/3.11/whatsnew/3.11.html#summary-release-highlights (Security improvements) == Release Notes == TBD -- Ben Cotton He / Him / His Fedora Program Manager Red Hat TZ=America/Indiana/Indianapolis

9 10

Spring Cleaning go-sig/June 2022
by Fabio Alessandro Locati 19 Jul '22

19 Jul '22

Hello Golang packagers, As it happened last month, we are trying to clean the situation with golang packages. In the last month we have seen big improvements (265 ->131 packages in the list), and I really hope next month we will be able to claim such a great result again! At the moment I've gathered all packages that depend on golang and the privilege that @go-sig has on them. I would ask of all of you to make sure all your packages have been added to the @go-sig group on src.fedoraproject.org (at least with "commit" access), unless there is a very good reason not to do so (and if that is the case for a particular package on this list, I'd be interested in knowing the reason). Without that, it makes it very hard for us to keep the Go stack up-to-date and in working order, because the "go-sig" list / bugzilla account does not get CC'd on new bugs that way, and your bugs do not show up in our BugZilla queries. If you want a scripted way of adding "@go-sig" group to many packages, you can generate an API token on src.fedoraproject.org (with "Modify an existing project") access level, and use the simple Python script from this link: https://fale.fedorapeople.org/add-go-sig.py Below is the list of "incompletely set-up" packages, in alphabetic order, and at the bottom, is a list per package maintainer. Thanks, Fale ================================================================================ Maintainers per package: - android-tools: van - apptainer: dwd - asciigraph: mhayden - buildah: lsm5 - butane: bgilbert - ceph: kkeithle - cheat: tkorbar - clipman: wef - containernetworking-plugins: mheon - cri-o: haircommander - deepin-api: mosquito - deepin-daemon: mosquito - deepin-desktop-schemas: mosquito - deepin-gir-generator: mosquito - deepin-pw-check: cheeselee - docker-distribution: cverna - git-octopus: baitaand - go-bindata: lsm5 - godep: jchaloup - golang: jcajka - golang-deepin-go-lib: mosquito - golang-entgo-ent: salimma - golang-github-acobaugh-osrelease: harrymichal - golang-github-anaskhan96-soup: atim - golang-github-apparentlymart-cidr: pwouters - golang-github-apparentlymart-textseg-13: limb - golang-github-bits-and-blooms-bitset: dcavalca - golang-github-client9-gospell: mayorga - golang-github-cli-gh: mikelo2 - golang-github-cli-shurcool-graphql: jdoss - golang-github-coreos-semver: limb - golang-github-elves-elvish: appadeia - golang-github-enescakir-emoji: jdoss - golang-github-facebook-time: abulimov - golang-github-gizak-termui: atim - golang-github-gocomply-scap: isimluk - golang-github-googlecloudplatform-guest-logging: ericedens - golang-github-google-dap: alexsaezm - golang-github-google-gousb: jjelen - golang-github-gosexy-gettext: zyga - golang-github-hajimehoshi-mp3: atim - golang-github-hajimehoshi-oto: atim - golang-github-harrymichal-version: harrymichal - golang-github-heistp-irtt: tohojo - golang-github-hinshun-vt10x: jdoss - golang-github-hub: jaymzh - golang-github-hugelgupf-socketpair: dcavalca - golang-github-ianbruene-difflib: dfateyev - golang-github-jroimartin-gocui: atim - golang-github-kalafut-imohash: dcavalca - golang-github-kelvins-sunrisesunset: cheeselee - golang-github-letsencrypt-challtestsrv: pwouters - golang-github-letsencrypt-pebble: pwouters - golang-github-linuxdeepin-dbus-factory: mosquito - golang-github-linuxdeepin-go-x11-client: mosquito - golang-github-lithammer-fuzzysearch: atim - golang-github-lofanmi-pinyin: cheeselee - golang-github-lpabon-godbc: lpabon - golang-github-lunixbochs-vtclean: atim - golang-github-mbland-hmacauth: pwouters - golang-github-mbndr-figlet4go: atim - golang-github-mingrammer-commonregex: athoscr - golang-github-mitchellh-ps: szeth - golang-github-mozillazg-pinyin: cheeselee - golang-github-msprev-fzf-bibtex: dmoerner - golang-github-muesli-reflow: jdoss - golang-github-muesli-termenv: jdoss - golang-github-mvo5-goconfigparser: zyga - golang-github-netflix-expect: jdoss - golang-github-openprinting-goipp: zdohnal - golang-github-openprinting-ipp-usb: zdohnal - golang-github-pkg-browser: thomasfedb - golang-github-projectdiscovery-cdncheck: fab - golang-github-projectdiscovery-sliceutil: mikelo2 - golang-github-remeh-sizedwaitgroup: mayorga - golang-github-rickb777-date: cheeselee - golang-github-rickb777-plural: cheeselee - golang-github-rivo-uniseg: jdoss - golang-github-rubyist-tracerx: clime - golang-github-schollz-cli-2: dcavalca - golang-github-schollz-croc: dcavalca - golang-github-schollz-logger: dcavalca - golang-github-schollz-mnemonicode: dcavalca - golang-github-schollz-pake-3: dcavalca - golang-github-schollz-peerdiscovery: dcavalca - golang-github-segmentio-ksuid: gundersanne - golang-github-sqshq-sampler: atim - golang-github-teambition-rrule: cheeselee - golang-github-termie-shutil: dfateyev - golang-github-tomnomnom-xtermcolor: atim - golang-github-tscholl2-siec: dcavalca - golang-github-xiaq-persistent: appadeia - golang-github-xrash-smetrics: mayorga - golang-github-zyedidia-highlight: atim - golang-gitlab-esr-fqme: dfateyev - golang-gitlab-ianbruene-kommandant: dfateyev - golang-nanomsg-mangos-3: fab - golang-rsc-pdf: deparker - golang-starlark: alexsaezm - golie: isimluk - gomtree: vbatts - google-guest-agent: ericedens - gotun: kushal - grafana: agerstmayr - grafana-pcp: agerstmayr - graphviz: jskarvad - gron: lkiesow - ignition: dustymabe - kata-containers: etrunko - kompose: dustymabe - manifest-tool: jwboyer - oci-seccomp-bpf-hook: jnovy - origin: jcajka - osbuild-composer: obudai - pack: lsm5 - podman: mheon - podman-tui: navidys - popub: zsun - reg: mattia - reposurgeon: dfateyev - restic: copart - runc: kir - singularity: dwd - skopeo: lsm5 - stargz-snapshotter: ktock - startdde: mosquito - swig: jplesnik - tmux-top: ttomecek - toolbox: rishi - vultr-cli: mhayden - xe-guest-utilities-latest: cheeselee Packages per maintainer: abulimov (1): golang-github-facebook-time agerstmayr (2): grafana, grafana-pcp alexsaezm (2): golang-github-google-dap, golang-starlark appadeia (2): golang-github-elves-elvish, golang-github-xiaq-persistent athoscr (1): golang-github-mingrammer-commonregex atim (11): golang-github-anaskhan96-soup, golang-github-gizak-termui, golang-github-hajimehoshi-mp3, golang-github-hajimehoshi-oto, golang-github-jroimartin-gocui, golang-github-lithammer-fuzzysearch, golang-github-lunixbochs-vtclean, golang-github-mbndr-figlet4go, golang-github-sqshq-sampler, golang-github-tomnomnom-xtermcolor, golang-github-zyedidia-highlight baitaand (1): git-octopus bgilbert (1): butane cheeselee (8): deepin-pw-check, golang-github-kelvins-sunrisesunset, golang-github-lofanmi-pinyin, golang-github-mozillazg-pinyin, golang-github-rickb777-date, golang-github-rickb777-plural, golang-github-teambition-rrule, xe-guest-utilities-latest clime (1): golang-github-rubyist-tracerx copart (1): restic cverna (1): docker-distribution dcavalca (10): golang-github-bits-and-blooms-bitset, golang-github-hugelgupf-socketpair, golang-github-kalafut-imohash, golang-github-schollz-cli-2, golang-github-schollz-croc, golang-github-schollz-logger, golang-github-schollz-mnemonicode, golang-github-schollz-pake-3, golang-github-schollz-peerdiscovery, golang-github-tscholl2-siec deparker (1): golang-rsc-pdf dfateyev (5): golang-github-ianbruene-difflib, golang-github-termie-shutil, golang-gitlab-esr-fqme, golang-gitlab-ianbruene-kommandant, reposurgeon dmoerner (1): golang-github-msprev-fzf-bibtex dustymabe (2): ignition, kompose dwd (2): apptainer, singularity ericedens (2): golang-github-googlecloudplatform-guest-logging, google-guest-agent etrunko (1): kata-containers fab (2): golang-github-projectdiscovery-cdncheck, golang-nanomsg-mangos-3 gundersanne (1): golang-github-segmentio-ksuid haircommander (1): cri-o harrymichal (2): golang-github-acobaugh-osrelease, golang-github-harrymichal-version isimluk (2): golang-github-gocomply-scap, golie jaymzh (1): golang-github-hub jcajka (2): golang, origin jchaloup (1): godep jdoss (7): golang-github-cli-shurcool-graphql, golang-github-enescakir-emoji, golang-github-hinshun-vt10x, golang-github-muesli-reflow, golang-github-muesli-termenv, golang-github-netflix-expect, golang-github-rivo-uniseg jjelen (1): golang-github-google-gousb jnovy (1): oci-seccomp-bpf-hook jplesnik (1): swig jskarvad (1): graphviz jwboyer (1): manifest-tool kir (1): runc kkeithle (1): ceph ktock (1): stargz-snapshotter kushal (1): gotun limb (2): golang-github-apparentlymart-textseg-13, golang-github-coreos-semver lkiesow (1): gron lpabon (1): golang-github-lpabon-godbc lsm5 (4): buildah, go-bindata, pack, skopeo mattia (1): reg mayorga (3): golang-github-client9-gospell, golang-github-remeh-sizedwaitgroup, golang-github-xrash-smetrics mhayden (2): asciigraph, vultr-cli mheon (2): containernetworking-plugins, podman mikelo2 (2): golang-github-cli-gh, golang-github-projectdiscovery-sliceutil mosquito (8): deepin-api, deepin-daemon, deepin-desktop-schemas, deepin-gir-generator, golang-deepin-go-lib, golang-github-linuxdeepin-dbus-factory, golang-github-linuxdeepin-go-x11-client, startdde navidys (1): podman-tui obudai (1): osbuild-composer pwouters (4): golang-github-apparentlymart-cidr, golang-github-letsencrypt-challtestsrv, golang-github-letsencrypt-pebble, golang-github-mbland-hmacauth rishi (1): toolbox salimma (1): golang-entgo-ent szeth (1): golang-github-mitchellh-ps thomasfedb (1): golang-github-pkg-browser tkorbar (1): cheat tohojo (1): golang-github-heistp-irtt ttomecek (1): tmux-top van (1): android-tools vbatts (1): gomtree wef (1): clipman zdohnal (2): golang-github-openprinting-goipp, golang-github-openprinting-ipp-usb zsun (1): popub zyga (2): golang-github-gosexy-gettext, golang-github-mvo5-goconfigparser -- Fabio Alessandro Locati fale.io

3 2

Updated criteria proposal: networking requirements
by Adam Williamson 18 Jul '22

18 Jul '22

Hi folks! Some time ago I proposed some specific networking release criteria. I revived the thread back in February, and meeting discussion suggested we should be more intentional and specific about wifi requirements. So, looking at it again, I suggest adding an additional footnote: Footnote titled "Wireless networks": Common wireless network configurations using supported hardware as defined above are covered by this criterion. This includes access to home and enterprise wireless networks using 802.11 series connection protocols and WPA2 and WPA3 personal and enterprise security protocols. Bugs that are specific to particular hardware or configurations will be assessed according to [[Blocker_Bug_FAQ|hardware-dependent-issues|the normal considerations for such issues]]. Here is the full proposal again, with the new footnote included: ##### === 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 both typical router-provided addressing systems (e.g. DHCP on IPv4 or SLAAC or IPv6) and static addressing. The default network configuration tools for the console, for release-blocking desktops and for installer environments 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. Footnote titled "Wireless networks": Common wireless network configurations using supported hardware as defined above are covered by this criterion. This includes access to home and enterprise wireless networks using 802.11 series connection protocols and WPA2 and WPA3 personal and enterprise security protocols. Bugs that are specific to particular hardware or configurations will be assessed according to [[Blocker_Bug_FAQ|hardware-dependent-issues|the normal considerations for such issues]]. ==== 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 VPN servers with typical configurations. Footnote titled "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. ##### Any more thoughts, comments, adjustments etc? Thanks! -- Adam Williamson Fedora QA IRC: adamw | Twitter: adamw_ha https://www.happyassassin.net

9 14

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