devel December 2020

devel@lists.stg.fedoraproject.org

220 participants
342 discussions

Server Side Public License (SSPL) v1
by Tom Callaway 21 Jan '21

21 Jan '21

After review, Fedora has determined that the Server Side Public License v1 (SSPL) is not a Free Software License. It is the belief of Fedora that the SSPL is intentionally crafted to be aggressively discriminatory towards a specific class of users. Additionally, it seems clear that the intent of the license author is to cause Fear, Uncertainty, and Doubt towards commercial users of software under that license. To consider the SSPL to be "Free" or "Open Source" causes that shadow to be cast across all other licenses in the FOSS ecosystem, even though none of them carry that risk. It is also worth nothing that while there is a draft for a "v2" of the SSPL: A) It is not final. B) It is not in use anywhere at this time (as far as we know). C) The intent of the v2 draft text is not changed from the v1 license currently in use. We have updated our "Bad License" list to include SSPLv1. No software under that license may be included in Fedora (including EPEL and COPRs). Thanks, Tom Callaway Fedora Legal

4 6

Fedora 34 Change: Enable spec file preprocessing (System-Wide Change proposal)
by Ben Cotton 20 Jan '21

20 Jan '21

https://fedoraproject.org/wiki/Changes/Enable_Spec_File_Preprocessing == Summary == This change should enable an opt-in spec file preprocessor in Fedora infrastructure for the benefit of packagers. The preprocessor allows some very neat tricks that were impossible before, for example generate changelog and release automatically from git metadata or pack the entire dist-git repository into an rpm-source tarball (effectively allowing unpacked repos to live in DistGit). == Owner == * Name: [[User:clime| Michal Novotný]] * Email: clime(a)fedoraproject.org == Detailed Description == There is a recently added feature into mock: [https://github.com/rpm-software-management/mock/wiki/Plugin-rpkg-preprocess… the rpkg preprocessor] which, if enabled, introduces an intermediate step just before srpm building. This step consists of running the spec file through a text preprocessing engine that includes an already present library of macros designed specifically for rpm spec file generation from git metadata. This library is called [https://docs.pagure.org/rpkg-util/v3/macro_reference.html rpkg-macros]. The macros there allow packagers to have their `%changelog`, `Release`, `Version`, `VCS` tag, or even `Source` fields automatically generated from dist-git repository data and metadata. The library can be easily extended in future to support more packager use-cases or even a completely new library can be developed that doesn't look at git metadata at all and instead, for example, analyses already present tarball content to render spec file based on upstream information. This doesn't mean it will happen but the framework is generic enough to support that. There is also support for user-defined macros that are loaded on-demand from a file placed alongside the package sources, maintained by packager. This feature wouldn't be enabled by this change from start but it's an example of freedom that the preprocessing framework is able to provide. Enabling this change should be very easy, basically adding: <pre> config_opts['plugin_conf']['rpkg_preprocessor_enable'] = True </pre> into mock configuration of Koji builders and using at least mock 2.7. Some very minor change may be also needed in Koji regarding the spec file lookup. Even if the change is enabled on the infrastructure level like this, the packager will still need to opt-in to use the preprocessor. The opting-in is done by placing `rpkg.conf` file into the package top-level directory with the following content: <pre> [rpkg] preprocess_spec = True </pre> When this is done by a packager, the preprocessor will be finally enabled for the given package. Alongside, there is an ongoing work to add the preprocessor support into the `rpkg` python library so that a packager can easily work with the spec files containing the preprocessor (rpkg) macros: https://pagure.io/rpkg/pull-request/530 The macros are supported since epel6 until the most latest Fedora (preproc, rpkg-macros, and rpm-git-tag-sort packages are needed). The spec preprocessing step in mock happens in a target chroot just before the srpm build. == Benefit to Fedora == This change offers solution to some long-standing issues in Fedora around packaging (i.e. automatic release and changelog generation) while also offering some interesting future options (for example unpacked dist-git repos). The big advantage of this approach is that it is explicit. Spec file stays the source of truth and by looking inside one, you will be able to determine how the text will expand for a certain git repository state. == Scope == * Proposal owners: For the very basic support, probably a small patch in Koji is needed to be able to lookup not only `.spec` files but also `.spec.rpkg` files (the `.spec.rpkg` extension explicitly states that the spec file is a template). Also the `rpmdevtools/rpmdev-bumpspec` script should be tweaked to be compatible with spec files using the macros. * Other developers: Some optional help with `rpmdevtools/rpmdev-bumpspec` changes would be welcome. * Release engineering: [https://pagure.io/releng/issue/9910 #9910] (a check of an impact with Release Engineering is needed) Enabling the rpkg_preprocessor plugin in mock config for Koji builders. * Policies and guidelines: The new macro support should be mentioned or even described in the packaging guidelines. We should decide if the full power of the rpkg-macros library should be allowed from start (i.e. even unpacked repos). * Trademark approval: N/A (not needed for this Change) * Alignment with Objectives: N/A == Upgrade/compatibility impact == Because of the opt-in nature on packager side, there should be no compatibility issues. == How To Test == Once the feature is enabled, one can test it by providing the `rpkg.conf` file with the required content in a package repository and use some rpkg macro in the spec file: e.g. <pre> Name: {{{ git_dir_name }}} </pre> to generate the name of the package from the repository name (this should actually produce the original text as package names should be the same as the repository basenames). To try it out first without committing to dist-git, one can use `rpkg` command-line tool from https://copr.fedorainfracloud.org/coprs/clime/rpkg-util/ or even fedpkg's koji scratch build after [https://pagure.io/rpkg/pull-request/530 the work in the pyrpkg] library is finished. One can also currently use Copr's SCM "rpkg" build method where the macros are enabled but the rpkg-macros there are in version 2 whereas this change is about introducing the [https://docs.pagure.org/rpkg-util/v3/macro_reference.html version 3 rpkg-macros]. However, while there are some differences between v2 and v3, the idea and most of the working is the same. == User Experience == This change is intended for packagers. It should help to make a bit of their work easier and offer them some new interesting options. == Dependencies == N/A == Contingency Plan == Packagers can opt-out on individual basis by removing the `rpkg.conf` file or just setting the `preproces_spec` property to `False`. On infrastructure level, the rpkg_preprocessor plugin could be disabled again. == Documentation == - [https://github.com/rpm-software-management/mock/wiki/Plugin-rpkg-preprocess… Mock's rpkg_preprocessor plugin] - [https://docs.pagure.org/rpkg-util/v3/macro_reference.html rpkg-macros reference (the library of macros ready to be used in spec files)] == Release Notes == Currently N/A -- Ben Cotton He / Him / His Senior Program Manager, Fedora & CentOS Stream Red Hat TZ=America/Indiana/Indianapolis

20 55

Release 5.6.1 of Sundials
by Antonio T. sagitter 19 Jan '21

19 Jan '21

Hi all. Next release of Sundials will be the 5.6.1: https://github.com/LLNL/sundials/releases/tag/v5.6.1 (Included changes of the 5.6.0 [1]) I'll update Sundials in Rawhide after the New Years'Day [1] https://github.com/LLNL/sundials/releases/tag/v5.6.0 -- --- Antonio Trande Fedora Project mailto: sagitter(a)fedoraproject.org GPG key: 0x29FBC85D7A51CC2F GPG key server: https://keys.gnupg.net/

3 7

Fedora 34 Change: Unify the GRUB configuration files location across all supported architectures (System-Wide Change proposal)
by Ben Cotton 14 Jan '21

14 Jan '21

https://fedoraproject.org/wiki/Changes/UnifyGrubConfig == Summary == This change makes the GRUB configuration files layout to be consistent across all the supported architectures. Currently EFI is a special case since the GRUB configuration file and environment variables block are stored in the EFI System Partition (ESP) instead of the boot partition (or `/boot` directory if no boot partition is used). == Owner == * Name: [[User:Javierm|Javier Martinez Canillas]] * Email: javierm(a)redhat.com * Name: [[User:Gicmo|Christian Kellner]] * Email: ckellner(a)redhat.com == Detailed Description == The GRUB configuration files layout on EFI platforms is not consistent with the other non-EFI platforms (e.g: x86 with legacy BIOS, ppc64le with Open Firmware). On platforms using EFI the GRUB configuration file (`grub.cfg`) and environment variables block (`grubenv`) are stored in the EFI System Partition (ESP) while for non-EFI platforms these are stored in the boot partition (or `/boot` directory if not boot partition is used). The reason for this is that the path where the GRUB bootloader searches for its configuration file varies depending on the firmware interface used. In most cases, GRUB searches for it in the path set in the `$prefix` variable. The device is not specified in that case, GRUB just searches for a configuration in this path for every detected device. But on EFI, a special `$fw_path` variable is used instead. This variable specifies both the device and path from where the GRUB bootloader was loaded and these are used to search for the configuration file. This is done for security reasons, to make sure that the correct GRUB configuration file is used and not just the first one found in one of the detected devices. Since the GRUB binary is located in the ESP, it expects to find the configuration file in that location as well. But this creates the mentioned inconsistency, because the GRUB configuration file has to be stored in `/boot/efi/EFI/fedora/grub.cfg` while for non-EFI platforms it has to be stored in `/boot/grub2/grub.cfg`. This leads to a GRUB configuration layout that is confusing for users and error prone, since either the tools that are used to manage these files have to be aware of the differences or symbolic links used to hide the fact that the pats differ depending on the platform. Also, it creates artificial constraints on the OS installation due the differences in the configuration layout used. A system installed when using EFI won't be bootable if the firmware configuration is changed to boot using legacy BIOS instead, for example enabling the EFI Compatibility Support Module or moving the disk to a BIOS machine. The proposal is to always store the `grub.cfg` and `grubenv` files in the `/boot/grub2/` directory, making `/boot/efi/EFI/fedora/grub.cfg` to only be a small configuration file that sets a different `$prefix` variable and loads the configuration file stored in `/boot/grub2/grub.cfg`. The `$prefix` variable will be set to the device partition where `/boot/grub2/grub.cfg` is stored, using the partition filesystem's Universally Unique IDentifier (UUID). That way the correct GRUB configuration file will be loaded, making it as secure as the current approach where the configuration file in the ESP is used. A drawback of the new approach is that the GRUB configuration will now depend on the boot partition (or `/boot` directory if no boot partition is used). But since the kernel and initramfs images are stored there too, the bootloader configuration already has this dependency anyways. Note that the proposed configuration files layout is already used by the Fedora CoreOS Assembler (COSA) and OSBuild image builders. So this will make the systems installed with Anaconda to be consistent with the images generated by these. == Benefit to Fedora == This change will not only simplify and make less confusing the GRUB configuration but also allow the following improvements: * To have a consistent configuration across all the architectures using GRUB. * Allow the same installation to be booted with either EFI or legacy BIOS. * Use the same documentation and commands for all architectures instead of having EFI as a special case. * Make GRUB configuration tools more robust by not relying on symbolic links to be created and not having to handle platform specific cases. * Align with images generated by COSA and OSBuild on how the GRUB configuration files are used. * Align with other Linux distributions on how the GRUB configuration files are used. == Scope == * Proposal owners: ** Modify Anaconda to generate the `grub.cfg` and `grubenv` files in `/boot/grub2/` instead of `/boot/efi/EFI/fedora/` for EFI platforms. ** Make Anaconda to generate the minimal GRUB config file in the ESP that sets the `$prefix` variable and loads the configuration file located in `/boot/grub2/grub.cfg`. ** Modify the grub2 package scriptlets to not generate the `/boot/grub2/grubenv` and `/etc/grub2-efi.cfg` symbolic links since these will not be needed anymore. ** Make any changes needed in tools that use these configuration files (`grubby`, `kernel-install` scripts, etc). * Other developers: ** The Anaconda developers will need to review and merge the patches to change where the GRUB configuration files are created. ** Test and watch for regressions. * Release engineering: ** [[Fedora_Program_Management/ReleaseBlocking/Fedora{{FedoraVersionNumber|next}}|List of deliverables]]: N/A * Policies and guidelines: The policies and guidelines do not need to be updated. * Trademark approval: No changes needed. == Upgrade/compatibility impact == The changes will only be for new installations, existing systems will not be impacted and will continue using the grub.cfg and grubenv files that are located in the ESP. == How To Test == * Install Fedora 34 and verify that the GRUB configuration is correct. * Check that the `/boot/efi/EFI/fedora/grub{.cfg,env}` files are not present. * Check that the `/boot/grub2/grub{.cfg,env}` files are present. * Enter the GRUB prompt by pressing 'c' from the GRUB boot menu and execute the following command: <pre>echo $prefix</pre> and verify that the prefix is set to the partition that contains the `/boot/grub2` directory. * Re-generate the GRUB configuration file with: <pre>grub2-mkconfig -o /boot/grub2/grub.cfg</pre> and verify that the GRUB configuration is still correct. == User Experience == No visible changes are expected other than the configuration files being present in a different path. This should improve the overall user experience. == Dependencies == None == Contingency Plan == * Contingency mechanism: Revert the Anaconda and grub2 package scriptlets changes. * Contingency deadline: Beta Freeze * Blocks release? No * Blocks product? None == Documentation == * Fedora CoreOS assembler script that creates the GRUB config file for EFI: https://github.com/coreos/coreos-assembler/blob/master/src/create_disk.sh * OSBuild org.osbuild.grub2 stage that creates the GRUB config file for EFI: https://github.com/osbuild/osbuild/blob/main/stages/org.osbuild.grub2 -- Ben Cotton He / Him / His Senior Program Manager, Fedora & CentOS Stream Red Hat TZ=America/Indiana/Indianapolis

17 36

Upcoming Fedora 34 deadlines
by Ben Cotton 12 Jan '21

12 Jan '21

Here we are, already thinking about Change submission deadlines for Fedora 34! Some key dates you should know: * 2020-12-16 — Change proposal deadline: Changes requiring infrastructure changes * 2020-12-29 — Change proposal deadline: System-Wide Changes, Changes requiring mass rebuild * 2021-01-19 — Change proposal deadline: Self-Contained Changes The full Fedora 34 schedule is on Fedora People: https://fedorapeople.org/groups/schedule/f-34/f-34-key-tasks.html I will send additional reminders as we approach the deadlines. You can also read the weekly Fedora program updates on the Community Blog[2] or join the FPgM office hours at 9 AM Eastern (currently 1400 UTC) on Wednesdays[3]. [1] https://fedorapeople.org/groups/schedule/f-34/f-34-key-tasks.html [2] https://communityblog.fedoraproject.org/category/program-management/ [3] https://apps.fedoraproject.org/calendar/meeting/9527/ -- Ben Cotton He / Him / His Senior Program Manager, Fedora & CentOS Stream Red Hat TZ=America/Indiana/Indianapolis _______________________________________________ devel-announce mailing list -- devel-announce(a)lists.fedoraproject.org To unsubscribe send an email to devel-announce-leave(a)lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel-announce@lists.fedorapr…

1 2

Re: NeuroFedora review swaps
by Ankur Sinha 12 Jan '21

12 Jan '21

On Mon, Jan 28, 2019 15:47:00 +0100, J. Scheurich wrote: > > > I'd like to get this package reviewed please: > > > > - python-pyscaffold: https://bugzilla.redhat.com/show_bug.cgi?id=1669913# > > > > Would anyone like to swap reviews? > > I would review it for wdune sponsoring. Sorry---I'm not current with the wdune scenario. I assumed you meant that you'd review it unofficially as part of the work to get sponsored to the packagers group: https://fedoraproject.org/wiki/How_to_get_sponsored_into_the_packager_group… I'm not a sponsor yet so I cannot sponsor you to the group myself, but once you've done a few reviews, a sponsor will be happy to take a look at them and guide you through the sponsorship process. If you've submitted a review ticket for wdune already, I will be happy to review it and provide comments. -- Thanks, Regards, Ankur Sinha https://ankursinha.in Time zone: Europe/London

6 27

How to troubleshoot aarch64 and s390x?
by Richard Shaw 09 Jan '21

09 Jan '21

I'm working on building the new openexr package but the unit tests are failing but just on aarch64 and s390x. The aarch64 test instances are down due to the infra move and there are none for s390x. What's the best way to work around this? An emulated aarch64 install of Fedora? Thanks, Richard

9 14

Mass spec file change: Adding BuildRequires: make
by Tom Stellard 08 Jan '21

08 Jan '21

Hi, As part of the f34 change request[1] for removing make from the buildroot, I will be doing a mass update of packages[2] to add BuildRequires: make where it is needed. If you are a package maintainer and would prefer to update your packages on your own, please do so before Dec 14, which is when I will begin doing the mass update. I will be doing the updates in batches, so that if there is a mistake the impact will be limited. Here is the rough schedule of the changes: Dec 14: Update first 50 packages. Dec 16: Next 1000. Dec 18: Next 1000. Jan 4: Next 1000. Jan 5: Next 1000. Jan 6: Next 1000. Jan 7: Next 1000. Jan 8: Rest of packages. The deadline for completing these updates is the start of the f34 mass rebuild (Jan 20). Thanks, Tom [1] https://fedoraproject.org/wiki/Changes/Remove_make_from_BuildRoot [2] https://fedorapeople.org/~tstellar/needs_br_make_packages.txt

27 65

Fedora 34 Change: Ruby 3.0 (System-Wide Change)
by Ben Cotton 08 Jan '21

08 Jan '21

https://fedoraproject.org/wiki/Changes/Ruby_3.0 == Summary == Ruby 3.0 is the latest stable version of Ruby. Many new features and improvements are included for the increasingly diverse and expanding demands for Ruby. With this major update from Ruby 2.7 in Fedora 33 to Ruby 3.0 in Fedora 34, Fedora becomes the superior Ruby development platform. == Owner == * Name: [[User:vondruch| Vít Ondruch]], [[User:pvalena| Pavel Valena]] * Email: vondruch(a)redhat.com, pvalena(a)redhat.com == Detailed Description ==  Ruby 3.0 is upstream's new major release of Ruby. Many new features and improvements are included. === RBS === RBS is a language to describe the types of Ruby programs. Type checkers including type-profiler and other tools supporting RBS will understand Ruby programs much better with RBS definitions. You can write down the definition of classes and modules: methods defined in the class, instance variables and their types, and inheritance/mix-in relations. The goal of RBS is to support commonly seen patterns in Ruby programs and it allows writing advanced types including union types, method overloading, and generics. It also supports duck typing with interface types. Ruby 3.0 ships with `rbs` gem, which allows parsing and processing type definitions written in RBS. === Ractor (experimental) === Ractor is an Actor-model like concurrent abstraction designed to provide a parallel execution feature without thread-safety concerns. You can make multiple ractors and you can run them in parallel. Ractor enables to make thread-safe parallel programs because ractors can not share normal objects. Communication between ractors are supported by message passing. To limit sharing objects, Ractor introduces several restrictions to the Ruby’s syntax (without multiple Ractors, there is no changes). The specification and implementation are not matured and changed in future, so this feature is marked as experimental and show the experimental feature warning if Ractor is created. === Scheduler (Experimental) === `Thread#scheduler` is introduced for intercepting blocking operations. This allows for light-weight concurrency without changing existing code. CAUTION: This feature is strongly experimental. Both the name and feature will change in next preview release. === Other Notable New Features === * Rightward assignment statement is added. * Endless method definition is added. * Find pattern is added. * `Hash#except` is now built-in. * Memory view is added as an experimental feature === Performance improvements === Many improvements were implemented in MJIT. === Other notable changes since 2.7 === * Keyword arguments are separated from other arguments. * The feature of `$SAFE` was completely removed; now it is a normal global variable. * The order of backtrace had been reversed at Ruby 2.5, but it was cancelled. Now it behaves like Ruby 2.4; an error message and the line number where the exception occurs are printed first, and its callers are printed later. * Some standard libraries are updated. == Benefit to Fedora == With a latest release, Ruby language is supporting the newest language features, which enables even faster and easier development of Ruby applications. == Scope == * Proposal owners: ** Finish packaging of Ruby 3.0. Current changes available in PR https://src.fedoraproject.org/rpms/ruby/pull-request/70 ** Rebuilding of Ruby packages providing native extensions (i.e. packages which depends on libruby). * Other developers: ** Rebuild of packages with binary extensions (i.e. packages which depends on libruby) will be handled automatically, but some packages might need fixes/updates to support Ruby 3.0 properly. * Release engineering: [https://pagure.io/releng/issue/9882 #9882] (a check of an impact with Release Engineering is needed) ** The packages are going to be rebuild in side-tag, but that does not need releng involvement nowadays. * Policies and guidelines: N/A (not a System Wide Change) * Trademark approval: N/A (not needed for this Change) * Alignment with Objectives: == Upgrade/compatibility impact == * User specific Ruby binary extensions need to be rebuild. == How To Test == * No special hardware is needed. * To test, install Ruby 3.0. The test builds are pusblished in PR or on Ruby-SIG ML * Try to locally rebuild your packages using Ruby 3.0. * Use the packages with your applications previously written in Ruby. * If something doesn't work as it should, let us know. == User Experience == The Ruby programs/scripts should behave as they were used to. == Dependencies == <pre> $ dnf repoquery --disablerepo=* --enablerepo=rawhide --enablerepo=rawhide-source --arch=src --whatrequires 'ruby-devel' | sort | uniq | wc -l 138 </pre> == Contingency Plan == * Contingency mechanism: We would like to get a special buildroot tag to be able to rebuild necessary the packages with Ruby 3.0. If anything goes wrong, the tag could be easily dropped and previous version of Ruby 2.7 and its dependencies stays intact. The tag would be merged into F34 after everything is rebuild. * Contingency deadline: Mass Rebuild * Blocks release? No (not a System Wide Change), Yes/No * Blocks product? No == Documentation == * [http://www.ruby-doc.org/ Help and documentation for the Ruby programming language] * [https://github.com/ruby/ruby/blob/v3_0_0_preview1/NEWS.md Ruby 3.0.0.preview1 NEWS] == Release Notes == * The Ruby 3.0 bumps soname, therefore Ruby packages, which use binary extensions, should be rebuilt. Nevertheless, since upstream paid great attention to source compatibility, no changes to your code are needed. https://github.com/ruby/ruby/blob/master/NEWS -- Ben Cotton He / Him / His Senior Program Manager, Fedora & CentOS Stream Red Hat TZ=America/Indiana/Indianapolis

2 1

Fedora 34 Change: Golang 1.16 (System-Wide Change proposal)
by Ben Cotton 06 Jan '21

06 Jan '21

https://fedoraproject.org/wiki/Changes/golang1.16 == Summary == Rebase of Golang package to upcoming version 1.16 in Fedora 34, including the rebuild of all dependent packages(the pre-release version of Go will be used for the rebuild if released version will not be available at the time of the mass rebuild). == Owner == * Name: [[User:Jcajka| Jakub Čajka]], [[User:alexsaezm| Alejandro Sáez Morollón]] * Email: jcajka(a)redhat.com, alexsaezm(a)redhat.com == Detailed Description == Rebase of Golang package to upcoming version 1.16 in Fedora 34. Golang 1.16 is scheduled to be released in February 2021. Due to Go packages' current nature and state, the rebuild of dependent packages will be required. == Benefit to Fedora == Stay closely behind upstream by providing the latest release of Go, which includes improved support of the risc-v processor architecture and added support for aarch64 based darwin(macOS) machines, among other bug fixes, enhancements and new features. For a complete list of changes, see upstream change notes at https://tip.golang.org/doc/go1.16 . Therefore Fedora will be providing a reliable development platform for Go language and projects written in it. == Scope == * Proposal owners: Rebase Golang package in Fedora 34, help resolve possible issues found * Other developers: Fix possible issues, with help from Golang maintainers. * Release engineering: Rebuild of dependent packages as part of planned mass-rebuild. Tracking issue.[https://pagure.io/releng/issue/9904] * Policies and guidelines: N/A * Trademark approval: N/A == Upgrade/compatibility impact == ;0. :a) Install golang 1.16 from rawhide and use it to build your application(s)/package(s). :b) Scratch build against rawhide. ;1. :Your application/package built using golang 1.16 should work as expected. == User Experience == None == Dependencies == <pre> dnf repoquery -q --releasever=rawhide --disablerepo='*' --qf='%{name}' --enablerepo=fedora-source --enablerepo=updates-source --enablerepo=updates-testing-source --archlist=src --whatrequires 'golang' dnf repoquery -q --releasever=rawhide --disablerepo='*' --qf='%{name}' --enablerepo=fedora-source --enablerepo=updates-source --enablerepo=updates-testing-source --archlist=src --whatrequires 'compiler(go-compiler)' dnf repoquery -q --releasever=rawhide --disablerepo='*' --qf='%{name}' --enablerepo=fedora-source --enablerepo=updates-source --enablerepo=updates-testing-source --archlist=src --whatrequires 'compiler(golang)' dnf repoquery -q --releasever=rawhide --disablerepo='*' --qf='%{name}' --enablerepo=fedora-source --enablerepo=updates-source --enablerepo=updates-testing-source --archlist=src --whatrequires 'go-rpm-macros' </pre> <pre> Omitted due to the number of packages listed ~1600. </pre> Not all of listed require re-build as they might not ship binaries and/or do not use golang compiler during build, but only use Go rpm macros that pull it in to every build root. == Contingency Plan == * Contingency mechanism:Reverting to golang version 1.15.X if significant issues are discovered. * Contingency deadline: Beta Freeze(?) * Blocks release? No * Blocks product? No == Documentation == https://tip.golang.org/doc/go1.16 -- Ben Cotton He / Him / His Senior Program Manager, Fedora & CentOS Stream Red Hat TZ=America/Indiana/Indianapolis

8 10

← Newer
1
2
3
4
5
6
7
...
35
Older →

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 December 2020