devel-announce December 2020

devel-announce@lists.fedoraproject.org

6 participants
37 discussions

Fedora 34 Change: MinGW environment and toolchain update (System-Wide Change proposal)
by Ben Cotton 15 Dec '20

15 Dec '20

https://fedoraproject.org/wiki/Changes/F34MingwEnvToolchainUpdate == Summary == Update the MinGW base environment and toolchain to the latest upstream stable releases. == Owner == * Name: [[User:smani|Sandro Mani]] * Email: manisandro(a)gmail.com == Detailed Description == The following packages will be updated * mingw-gcc to version 11.x * mingw-w64-tools to version 8.x * mingw-winpthreads to version 8.x * mingw-crt to version 8.x * mingw-headers to version 8.x * mingw-binutils to version 2.36 * mingw-gdb to version 10.x == Benefit to Fedora == Ship the latest available MinGW environment and GNU toolchain. == Scope == * Proposal owners: The above mentioned packages will be updated. Build failures following the mass rebuild will be inspected. * Other developers: * Release engineering: Impact check [https://pagure.io/releng/issue/9903] * Release engineering: Mass rebuild requested * Policies and guidelines: No policies need to be changed == Upgrade/compatibility impact == No impact == How To Test == Update the system once the updated packages land, look out for new build failures etc. == User Experience == The features of the newest MinGW environment and GNU Toolchain will be available to the users. == Dependencies == None == Contingency Plan == * Contingency mechanism: Revert to older versions of environment / toolchain, mass rebuild mingw packages again * Contingency deadline: Before release * Blocks release? Yes * Blocks product? No == Release Notes == Fedora 34 comes with the mingw-w64-8 environment, mingw-gcc-11, mingw-gdb-10' and mingw-binutils 2.36. -- Ben Cotton He / Him / His Senior Program Manager, Fedora & CentOS Stream Red Hat TZ=America/Indiana/Indianapolis

1 0

Fedora 34 Change: LLVM 12 (System-Wide Change proposal)
by Ben Cotton 14 Dec '20

14 Dec '20

https://fedoraproject.org/wiki/Changes/LLVM-12 == Summary ==  Update all llvm sub-projects in Fedora to version 12. == Owner == * Name: [[User:tstellar| Tom Stellard]] * Email: <tstellar(a)redhat.com> == Detailed Description == All llvm sub-projects in Fedora will be updated to version 12, and there will be a soname version change for the llvm libraries. Compatibility packages clang11 and llvm11 will be added to ensure that packages that currently depend on clang and llvm version 11 libraries will continue to work. == Benefit to Fedora == New features and bug fixes provided by the latest version of LLVM. == Scope == * Proposal owners: ** Review existing llvm and clang compatibility packages and orphan any packages that are no longer used. ** Request a side-tag. ** Build llvm11 and clang11 into the side-tag. ** When the upstream LLVM project releases version 12.0.0-rc1 (Jan 2021), package this and build it into the side tag. ** Merge side-tag into rawhide prior to the f34 branch date. ** Continue packaging newer release candidates into rawhide and f34 until the final release is complete (~March 2021) * Other developers: ** Maintainers of packages that depend on clang-libs or llvm-libs will need to update their spec files to depend on the clang11 and llvm11 compatibility packages if they want to rebuild their package and it does not work with LLVM 12 yet. The key point here is that spec file changes are only needed if a package is going to be rebuilt after LLVM 12 is added to Fedora. The compatibility packages will ensure that already built packages continue to work. * Release engineering: [] (a check of an impact with Release Engineering is needed) * Policies and guidelines: No policies or guidelines will need to be updated as a result of this change. * Trademark approval: N/A (not needed for this Change) == Upgrade/compatibility impact == This change should not impact upgradeability. == How To Test == The CI tests for the llvm sub-packages in Fedora will be used to catch regressions that might be potentially introduced by the update to LLVM 12. == User Experience == Users will benefit from new features and bug-fixes in the latest version of LLVM. == Dependencies == This change can be made without updating any other packages. However, as mention before, packages that need to use LLVM 11 will need to update their spec file on their first rebuild after this change. == Contingency Plan == * Contingency mechanism: (What to do? Who will do it?) If there are major problems with LLVM 12, the compatibility package provide a way for other packages to continue using LLVM 11. In the worst case, we could always revert LLVM back to LLVM 11, but this would only happen if their were an unprecedented amount of problems. * Contingency deadline: Beta Freeze * Blocks release? No * Blocks product? None == Documentation == Release notes will be added for this change. == Release Notes == LLVM sub-projects in Fedora have been updated to version 12: * llvm * clang * lld * lldb * compiler-rt * libomp * llvm-test-suite * libcxx * libcxxabi * python-lit * flang * mlir -- Ben Cotton He / Him / His Senior Program Manager, Fedora & CentOS Stream Red Hat TZ=America/Indiana/Indianapolis

1 0

Fedora 34 Change: Use ibus-m17n as the default IME for Vietnamese (System-Wide Change proposal)
by Ben Cotton 14 Dec '20

14 Dec '20

https://fedoraproject.org/wiki/Changes/ibus-m17n_as_default_Vietnamese_IME == Summary == The current default input method for Vietnamese is ibus-bogo. This should change to the ibus-m17n input method “m17n:vi:telex - telex (m17n)” == Owner == * Name: [[User:Mfabian| Mike Fabian]] * Email: <mfabian(a)redhat.com> == Detailed Description == The current Fedora default input method ibus-bogo seems to be not actively maintained and it doesn't work on Gnome Wayland. The bug has been reported already in Fedora 30, see: https://bugzilla.redhat.com/show_bug.cgi?id=1690326 The ibus-m17n input method vi-telex.mim seems to do the same as ibus-bogo, see https://bugzilla.redhat.com/show_bug.cgi?id=1690326#c12 Using vi-telex.mim via ibus-m17n seems to behave exactly like ibus-bogo. If ibus-bogo offers no additional benefit, it is probably better to use ibus-m17n with vi-telex as the default input method for Vietnamese. ibus-m17n has to be maintained anyway. Therefore, this saves the effort of fixing the unmaintained ibus-bogo. == Benefit to Fedora == Vietnamese input works again on Gnome-Wayland. Currently with ibus-bogo it is broken. == Scope == * Proposal owners: ** update default IME in comps @input methods ** update langpacks-vi to use ibus-m17n and m17n-db ** the langtable package has data about default input methods. Change this data. ** Change default input method in `libgnome-desktop/default-input-sources.h` Here are the changes for ibus-anthy requested by Takao Fujiwara, I need to request similar changes for changing from ibus-bogo as the default to ibus-m17n: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/3430 https://gitlab.gnome.org/fujiwarat/gnome-desktop/-/commit/04ad3737d5d1b66ed… * Other developers: gnome-desktop3 for default vi_VN input method * Release engineering: (a check of an impact with Release Engineering is needed) * Policies and guidelines: N/A (not a System Wide Change) * Trademark approval: N/A (not needed for this Change) == Upgrade/compatibility impact == The package installed by default will change from ibus-bogo to the packages ibus-m17n and m17n-db for an installation in Vietnamese. == How To Test == Install Fedora in Vietnamese and check that the default input method is vi-telex with ibus-m17n. == User Experience == * There should be very little difference in typing Vietnamese as ibus-bogo and ibus-m17n with vi-telex.mim behave the same. * The setup tool looks a little different. * Package sizes and dependent packages are different. * Memory usage is different. == Dependencies == ibus-m17n and m17n-db * comps has to be updated * gnome-desktop3 has to be updated == Contingency Plan == Revert changes back to ibus-bogo * Contingency mechanism: Revert comps and gnome-desktop3 * Contingency deadline: Beta release * Blocks release? No * Blocks product? None == Documentation == https://github.com/ibus/ibus-m17n -- Ben Cotton He / Him / His Senior Program Manager, Fedora & CentOS Stream Red Hat TZ=America/Indiana/Indianapolis

1 0

koji buildsystem changes
by Kevin Fenzi 13 Dec '20

13 Dec '20

Greetings everyone. I thought I would share some recent changes to koji (The Fedora buildsystem): * All s390x, x86_64, and ppc64le builders have been upgraded to Fedora33 * aarch64 and armv7 builder should be upgraded soon. * I have enabled bootstrap mode for all builds. In this mode koji uses the builder tools to construct a 'bootstrap' repo from the target os tools, which it then uses to create the src.rpm and do the build. For now this is needed for epel7/8 builds after builders moved to f33 due to rpm changing to default to sqlite rpm db. It will likely be needed for many other things moving forward and allows easier landing of new features while keeping other branches working as expected. This has caused one common issue: rhel7 rpm does not understand the newer changelog format with timezone, so spec files merged from fedora will break. * We have been having some koji database issues nightly when the koji-gc (garbage collection) scripts run (8-10UTC). We are working hard to track this down and fix it. Appologies for slowdowns in the mean time. Progress on this can be followed in https://pagure.io/fedora-infrastructure/issue/9528 * Finally releng is looking at establishing a sidetag cleanup policy. A reminder that sidetags should be short lived and only created when needed. koji must generate buildroot repos for every single sidetag. ( You can list all your sidetags with 'fedpkg list-side-tags --mine' ) As a first cut we are going to delete sidetags that have been empty for more than 14 days. We are considering a upper limit for time for sidetags as well. Input welcome to devel list or https://pagure.io/releng/issue/9805 Thanks everyone, stay safe out there! kevin

1 0

Mobility SIG meeting - 2020-12-14 16:30UTC
by Kevin Fenzi 11 Dec '20

11 Dec '20

Greetings everyone. I'd like to announce the next Mobility SIG meeting for next monday (2020-12-14) at 16:30UTC in #fedora-meeting. A tenative agenda: * introductions * status / plans on current remix * status / plans for next step remix with fedora kernel + patches and images built on copr * status / plans for official kickstart/images * All other business Our current efforts are focused on the pine64 pinephone, but other devices welcome. Please add / suggest topics at: https://pagure.io/fedora-mobility/issue/1 We plan to meet monthly on the second monday of the month moving foward. Please join us! More information at: https://fedoraproject.org/wiki/Mobility https://fedoraproject.org/wiki/Architectures/ARM/PinePhone Lets ramp up our pinephone efforts! kevin

1 0

Re: AArch64 support for container and flatpak builds
by Mohan Boddu 10 Dec '20

10 Dec '20

This is great news, thanks to everyone who worked on this project. On Thu, Dec 10, 2020 at 5:44 AM Mark O'Brien <markobri(a)redhat.com> wrote: > > All, > We are very happy to announce that we now have AArch64 support for flatpak and container fedpkg builds in production! > > By default all flatpak and container builds will be built on both architectures from now on. > > Thanks, > Fedora OSBS initiative > _______________________________________________ > devel mailing list -- devel(a)lists.fedoraproject.org > To unsubscribe send an email to devel-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@lists.fedoraproject.org

1 0

Fedora 34 Change proposal: Boost 1.75 upgrade (System-Wide Change)
by Ben Cotton 09 Dec '20

09 Dec '20

https://fedoraproject.org/wiki/Changes/F34Boost175 == Summary == This change brings Boost 1.75 to Fedora. This will mean Fedora ships with a recent upstream Boost release. == Owner == * Name: [[User:trodgers| Thomas Rodgers]] * Email: trodgers(a)redhat.com == Detailed Description == The aim is to synchronize Fedora with the most recent Boost release. Because ABI stability is absent from Boost, this entails rebuilding of all dependent packages. This also entails the change owner assisting maintainers of client packages in decoding cryptic boost-ese seen in output from g++. The equivalent changes for previous releases were [[Changes/F33Boost173]], [[Changes/F30Boost169|Fedora 30 Change]], [[Changes/F29Boost167|Fedora 29 Change]], [[Changes/F28Boost166|Fedora 28 Change]], [[Changes/F27Boost164|Fedora 27 Change]], [[Changes/F26Boost163|Fedora 26 Change]], [[Changes/F25Boost161|Fedora 25 Change]], [[Changes/F24Boost160|Fedora 24 Change]], [[Changes/F23Boost159|Fedora 23 Change]] and [[Changes/F22Boost158|Fedora 22 Change]]. == Benefit to Fedora == Fedora 33 includes Boost 1.73 (released April 28th 2020). Fedora will stay relevant, as far as Boost clients are concerned. In addition to serveral bug fixes and enhancements to existing components (including many as part of Boost 1.74's release) Boost 1.75 brings three new components: * [https://www.boost.org/doc/libs/1_74_0/libs/stl_interfaces Boost.STL_Interfaces], A library to assist in writing STL conforming iterators, views, and containers, from T. Zachary Laine (introduced in Boost 1.74). * [https://www.boost.org/doc/libs/1_75_0_beta1/libs/json/ Boost.JSON], A portable C++ library which provides containers and algorithms that implement JavaScript Object Notation, from Vinnie Falco, Krystian Stasiowski. * [https://www.boost.org/doc/libs/1_75_0_beta1/libs/leaf Boost.LEAF], A lightweight error handling library for C++11, from Krystian Stasiowski. * [https://www.boost.org/doc/libs/1_75_0_beta1/libs/pfr Boost.PFR], A C++14 library for very basic reflection, from Antony Polukhin. == Scope == * Proposal owners: ** Build will be done with Boost.Build v2 (which is the upstream-sanctioned way of building Boost) ** Request a "f34-boost" [https://docs.pagure.org/releng/sop_adding_side_build_targets.html build system tag] ([http://lists.fedoraproject.org/pipermail/devel/2011-November/159908.html discussion]): ** Build boost into that tag (take a look at the [http://koji.fedoraproject.org/koji/buildinfo?buildID=606493 build #606493] for inspiration) ** Post a request for rebuilds to fedora-devel ** Work on rebuilding dependent packages in the tag. ** When most is done, re-tag all the packages to rawhide ** Watch fedora-devel and assist in rebuilding broken Boost clients (by fixing the client, or Boost). * Other developers: ** Those who depend on Boost DSOs will have to rebuild their packages. Feature owners will alleviate some of this work as indicated above, and will assist those whose packages fail to build in debugging them. * Policies and guidelines: ** Apart from scope, this is business as usual, so no new policies, no new guidelines. * Trademark approval: N/A (not needed for this Change) == Upgrade/compatibility impact == * No manual configuration or data migration needed. * Some impact on other packages needing code changes to rebuild. Historically this hasn't been too much of a problem and could always be resolved before deadline. == How To Test == * No special hardware is needed. * Integration testing simply consists of installing Boost packages (`dnf install boost`) on Fedora and checking that it does not break other packages (see below for a way to obtain a list of boost clients). == User Experience == * Expected to remain largely the same. * Developers building third-party software on Fedora may need to rebuild against the new Boost packages, and may need to adjust their code if the new Boost release is not source-compatible. * Developers using `bjam` to build their own software will need to switch to using the new name for the tool, `b2` == Dependencies == Packages that must be rebuilt: <code>$ dnf repoquery -s --releasever=rawhide --whatrequires libboost\* --disablerepo=* --enablerepo=fedora | sort -u</code> All clients: <code>$ dnf repoquery --releasever=rawhide --archlist=src --whatrequires boost-devel --disablerepo='*' --enablerepo=fedora-source</code> == Contingency Plan == * Contingency mechanism: Worst case scenario is to abandon the update and simply ship F34 with Boost 1.73, which is already in rawhide. It would also be possible to ship the 1.74.0 which would still be newer than in current Fedora releases and contains numerous fixes and improvements to existing Boost components. * Contingency deadline: We will know whether the change can be made once the rebuilds in the side tag are done * Blocks release? No * Blocks product? None == Documentation == * https://www.boost.org/users/history/version_1_75_0.html (expected release mid December 2020) * https://www.boost.org/users/history/version_1_74_0.html (released on 14 August 2020) * https://www.boost.org/users/history/version_1_73_0.html (released on 28 April 2020) * https://www.boost.org/users/history/version_1_72_0.html (released on 11 December 2019) * https://www.boost.org/users/history/version_1_71_0.html (released on 19 August 2019) * https://www.boost.org/users/history/version_1_70_0.html (released on 12 April 2019) * https://www.boost.org/development/index.html -- Ben Cotton He / Him / His Senior Program Manager, Fedora & CentOS Stream Red Hat TZ=America/Indiana/Indianapolis

1 0

Fedora 34 Change: Stop Shipping Individual Nodejs Library Packages (Self-Contained)
by Ben Cotton 09 Dec '20

09 Dec '20

https://fedoraproject.org/wiki/Changes/NodejsLibrariesBundleByDefault == Summary == For Nodejs, Fedora should only package: * The interpreter, development headers/libraries, and the assorted tools to manage project-level installations (NPM, yarn, etc.). * Packages that provide binaries that users would want to use in their shell. * compiled/binary nodejs modules (for now) == Owner == * Name: [[User:tdawson| Troy Dawson]] * Email: tdawson(a)redhat.com * Name: [[User:sgallagh| Stephen Gallagher]] * Email: sgallagh(a)redhat.com * Name: [[https://developer.fedoraproject.org/tech/languages/nodejs/SIG.html| Nodejs SIG]] * Email: nodejs(a)lists.fedoraproject.org == Detailed Description == The nodejs libraries have been approved to be bundled, and there is infrastructure in place for the bundling to work properly. Currently, it is recommended that packagers should create individual nodejs library packages instead of bundling all of the libraries into the package requiring them. This change is to make it default to bundle the nodejs libraries with the package that needs them, and retire the vast majority of nodejs library packages. In summary, for Nodejs Fedora should only package: * The interpreter, development headers/libraries, and the assorted tools to manage project-level installations (NPM, yarn, etc.). * Packages that provide binaries that users would want to use in their shell. * compiled/binary nodejs modules (for now) == Feedback == There has been a discussion on the fedora nodejs mailing list about what to do with the extreme dependency problem of the nodejs library packages. Because of the extreme inter-dependency, upgrading almost any package causes others to break. It has caused most packages to rot, remaining on unsupported versions for years. Many of the nodejs packagers are giving up and orphaning their packages, which has caused even more problems. An initial proposal was to find all of the important nodejs library packages and bundle those, making them easier to upgrade and maintain. But there was problems with figuring out what was important, and what versions should those have. During that discussion, this rather extreme solution of getting rid of all nodejs libraries was proposed. To our surprise, it has been the best received suggestion and fixes the most problems. == Benefit to Fedora == * In Fedora 33, there are many nodejs libraries that are uninstallable, thus causing other programs based off them to also be uninstallable. This gets rid of that problem. * Packages in Fedora that use nodejs libraries will be able to use the library versions that upstream has tested and approved. * If a package in Fedora uses a nodejs library, the packager will not have to also package extra individual nodejs library packages. There have been times this has led to over 100 extra packages, each with their own package reviews and maintenance problems. This change will lower the workload on that packager, and possibly get more packages into Fedora. * The nodejs maintainers can concentrate on nodejs itself, instead of the whole nodejs library infrastructure. * Nodejs developers using Fedora will no longer have to worry about Fedora's global nodejs libraries causing conflicts or inconsistencies. == Scope == * Proposal owners: We will go through the Fedora release and determine what nodejs packages Fedora should package. We will implement nodejs library bundling on those we already own. For those that we do not own, we will work with their owners to implement nodejs library bundling. As packages implement nodejs library bundling, we will monitor the nodejs libraries and note which ones are no longer required. When they are no longer required, we will retire them, if we own them. If we do not own them, we will work with the owners to retire them, if they wish. * Other developers: For Fedora packagers whose package rely on nodejs libraries, please contact the [[https://developer.fedoraproject.org/tech/languages/nodejs/SIG.html| Nodejs SIG]] and we will help you find the easiest way to bundle your nodejs libraries. For Fedora nodejs library packages, look to see what depends on your library. If it looks like you can do so, retire your nodejs library. If you would like, give the [[https://developer.fedoraproject.org/tech/languages/nodejs/SIG.html| Nodejs SIG]] admin to your nodejs libraries, and they will work through the process for you. * Release engineering: [https://pagure.io/releng/issues #Releng issue number] (a check of an impact with Release Engineering is needed) * 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 == N/A == How To Test == * Install all nodejs libraries in Fedora 33. Try to update to Fedora 34. * Try to install all packages that require nodejs in Fedora 34. * Install all packages that require nodejs in Fedora 33. Try to update to Fedora 34. == User Experience == non-developer end users should not see anything different. Their nodejs binaries should continue to work. Nodejs developers using Fedora will no longer have to worry about Fedora's global nodejs libraries causing conflicts or inconsistencies. == Dependencies == As nodejs library packages are removed, we will work with the various packages that depend on them. We will help them bundle their nodejs libraries. == Contingency Plan == Since we will be bundling the nodejs binaries, before we remove their current dependencies, we will simply stop where we are at the freeze. There will be nothing to back out. * Contingency mechanism: N/A * Contingency deadline: N/A * Blocks release? N/A * Blocks product? N/A == Documentation == N/A (not a System Wide Change) -- Ben Cotton He / Him / His Senior Program Manager, Fedora & CentOS Stream Red Hat TZ=America/Indiana/Indianapolis

1 0

Fedora 34 Change: Binutils 2.36 (System-Wide Change)
by Ben Cotton 09 Dec '20

09 Dec '20

https://fedoraproject.org/wiki/Changes/BINUTILS236 == Summary == Rebase the binutils package from version 2.35.1 to version 2.36. == Owner == * Name: Nick Clifton [https://fedoraproject.org/wiki/User:Nickc] * Email: nickc(a)redhat.com == Detailed Description == Switch the binutils package from being based on the 2.35.1 release of the GNU binutils to being based on the 2.36 release. This release will bring in numerous bug fixes, as well as support for new x86 and ARM architecture extensions. == Benefit to Fedora == The main benefit will be the bug fixes and the improvements to the linker and assembler. Whilst invisible to ordinary users these changes will benefit package maintainers and application developers. == Scope == * Proposal owners: Change the source parameter in the binutils.spec rpm and adjust the local patches to take account of the bugs that are now already fixed. This is a significant change to the underlying tools used to build Fedora and so there should be a mass rebuild in order for the changes to be noticed across the system. * Other developers: None * Release engineering: https://pagure.io/releng/issue/9898 A mass rebuilt will be required. * Policies and guidelines: No documents need to be updated. * Trademark approval: N/A (not needed for this Change) * Alignment with Objectives: The rebase of the binutils will bring with it improved support for smaller architectures (eg ARM, RISC-V, MIPS) which in turn will align with the Fedora Internet of Things objective. == Upgrade/compatibility impact == The binutils are backwards compatible with previous releases, so no changes should be necessary. == How To Test == The binutils package does include its own set of testsuites which check basic functionality. The real test however is by rebuilding other packages which depend upon the binutils, or more likely, upon gcc. If these packages continue to work then the binutils update has not broken anything. == User Experience == The change should not be noticeable to the user. == Dependencies == This update has no hard dependencies on any other package. There are other packages that do depend upon the binutils however. Most notably gcc and redhat-rpm-config. == Contingency Plan == * Contingency mechanism: Revert to the 2.35.1 binutils as currently used in rawhide. This work can be done by me, should it prove necessary. * Contingency deadline: Beta freeze. * Blocks release? No * Blocks product? None == Documentation == This rebase brings with it many bug fixes, plus the following notable new features: New features in the Assembler: General: * When setting the link order attribute of ELF sections, it is now possible to use a numeric section index instead of symbol name. * Added a .nop directive to generate a single no-op instruction in a target neutral manner. This instruction does have an effect on DWARF line number generation, if that is active. * Removed --reduce-memory-overheads and --hash-size as gas now uses hash tables that can be expand and shrink automatically. X86/x86_64: * Add support for AVX VNNI, HRESET, UINTR, TDX, AMX and Key Locker instructions. * Support non-absolute segment values for lcall and ljmp. * Add {disp16} pseudo prefix to x86 assembler. * Configure with --enable-x86-used-note by default for Linux/x86. ARM/AArch64: * Add support for Cortex-A78, Cortex-A78AE and Cortex-X1, Cortex-R82, Neoverse V1, and Neoverse N2 cores. * Add support for ETMv4 (Embedded Trace Macrocell), ETE (Embedded Trace Extension), TRBE (Trace Buffer Extension), CSRE (Call Stack Recorder Extension) and BRBE (Branch Record Buffer Extension) system registers. * Add support for Armv8-R and Armv8.7-A ISA extensions. * Add support for DSB memory nXS barrier, WFET and WFIT instruction for Armv8.7. * Add support for +csre feature for -march. Add CSR PDEC instruction for CSRE feature in AArch64. * Add support for +flagm feature for -march in Armv8.4 AArch64. * Add support for +ls64 feature for -march in Armv8.7 AArch64. Add atomic 64-byte load/store instructions for this feature. * Add support for +pauth (Pointer Authentication) feature for -march in AArch64. New features in the Linker: * Add --error-handling-script=<NAME> command line option to allow a helper script to be invoked when an undefined symbol or a missing library is encountered. This option can be suppressed via the configure time switch: --enable-error-handling-script=no. * Add -z x86-64-{baseline|v[234]} to the x86 ELF linker to mark x86-64-{baseline|v[234]} ISA level as needed. * Add -z unique-symbol to avoid duplicated local symbol names. * The creation of PE format DLLs now defaults to using a more secure set of DLL characteristics. * The linker now deduplicates the types in .ctf sections. The new command-line option --ctf-share-types describes how to do this: its default value, share-unconflicted, produces the most compact output. * The linker now omits the "variable section" from .ctf sections by default, saving space. This is almost certainly what you want unless you are working on a project that has its own analogue of symbol tables that are not reflected in the ELF symtabs. New features in other binary tools: * The ar tool's previously unused l modifier is now used for specifying dependencies of a static library. The arguments of this option (or --record-libdeps long form option) will be stored verbatim in the __.LIBDEP member of the archive, which the linker may read at link time. * Readelf can now display the contents of LTO symbol table sections when asked to do so via the --lto-syms command line option. * Readelf now accepts the -C command line option to enable the demangling of symbol names. In addition the --demangle=<style>, --no-demangle, --recurse-limit and --no-recurse-limit options are also now available. -- Ben Cotton He / Him / His Senior Program Manager, Fedora & CentOS Stream Red Hat TZ=America/Indiana/Indianapolis

1 0

Fedora 34 Change: Stratis 2.3.0 (Self-Contained Change)
by Ben Cotton 07 Dec '20

07 Dec '20

https://fedoraproject.org/wiki/Changes/Stratis_2.3.0 == Summary == Stratis 2.3.0 adds additional flexibility to its encryption support via Clevis. == Owner == * Name: [[User:dkeefe|Dennis Keefe]], [[User:mulhern|Anne Mulhern]], [[User:jbaublitz|John Baublitz]] * Email: dkeefe(a)redhat.com, amulhern(a)redhat.com, jbaublitz(a)redhat.com == Detailed Description == === Stratis 2.3.0 === This release extends the pool unlock command, and adds two new commands, pool bind and pool unbind. The pool bind command establishes an alternative mechanism for unlocking a pool. The user may select either the "tang" mechanism, which implements NBDE (Network-bound Disc Encryption) by means of a Tang server, or the "tpm2" mechanism, which uses TPM 2.0 (Trusted Platform Module) encryption. Binding the devices in a pool to a supplementary Clevis encryption policy does not remove the primary encryption mechanism, which uses a key in the kernel keyring. The pool unbind command simply unbinds a previously added encryption policy from all the devices in the specified pool. In the pool unlock command it is now necessary to specify the mechanism. Use clevis to make use of the Clevis unlocking policy previously specified for the devices in the pool. Use keyring, to make use of the mechanism that uses a key in the kernel keyring, which was introduced in Stratis 2.1.0. Note that the pool unlock command unlocks all currently locked pools. == Detailed Description == === stratisd 2.3.0 === This release introduces two D-Bus interface revisions, which differ in the following way from the previous revisions. org.storage.stratis2.Manager.r3 modifies the UnlockPool method to take an additional parameter, unlock_method, which may be keyring or clevis. org.storage.stratis2.pool.r3 adds two new method: Bind and Unbind. The Bind method takes two arguments, pin and json. The pin argument designates the Clevis pin as a string, and the json argument encodes a Clevis configuration appropriate to the designated pin. The configuration is a JSON object. Besides Clevis information, it may include Stratis-specific keys that encode configuration decisions that Stratis may implement. At present there is just one such key: stratis:tang:trust_url. The Unbind method reverses a Bind action. == Remarks == The Bind method may be called with any Clevis pin and configuration; we expect that any valid Clevis pin and configuration can be used to bind the devices in a pool. However the Stratis project officially supports only the "tang" and "tpm2" pins as those are the pins that may be designated via stratis. Support for additional Clevis policies may be introduced into stratis in later releases. When binding a supplementary encryption policy to the devices in a pool using Clevis, the primary key, which is the key in the kernel keyring which was originally used to encrypt each device, must be supplied. stratisd obtains the appropriate key from the kernel keyring in order to provide it to the Clevis binding mechanism. The correct key must be present in the keyring for the bind operation to succeed. It is not necessary for the user to specify the key, stratisd obtains the necessary information from the LUKS2 metadata on the devices in the pool. In general, it is unwise to write a key consisting of arbitrary binary data to a keyfile. An accidental newline character in the data may cause the contents of the file to be truncated at the newline when read in one context while all the data may be read from the file in some other context. We are not aware that such a mistake would result in any error in Stratis's operation when Stratis is used in the way that we recommend. We explicitly acknowledge that it might be possible, through some direct interaction with the stratisd D-Bus API, or by, e.g., setting a key in the kernel keyring without using stratis, to manufacture a situation where stratisd could not bind the devices in a pool, even when the correct key is set in the kernel keyring. We would not treat such a situation as evidence of a bug in Stratis. == Feedback == == Benefits to Fedora == Users of Fedora will now benefit from Stratis 2.3.0 by: * Multiple methods of unlocking Stratis pools using - Kernel keyring - Tang server - TPM2 Device == Scope == * Proposal owners: ** Update existing stratis-cli package to specify new release ** Update existing stratisd package to specify new release * Other developers: N/A * Release engineering: Self Contained * Policies guidelines: N/A * Trademark approval: N/A == Upgrade/compatibility impact == There is no know impact when upgrading from Stratis 2.2.0 to 2.3.0 == How To Test == * Bind using Tang server echo "secret" > /tmp/testkey stratis key set --keyfile-path /tmp/testkey testkey stratis pool create --key-desc testkey testpool /dev/vdb stratis pool bind tang --trust-url testpool testkey tang.yourdomain.org * Bind using TPM2 echo "secret" > /tmp/testkey stratis key set --keyfile-path /tmp/testkey testkey stratis pool create --key-desc testkey testpool /dev/vdb stratis pool bind tpm2 testpool testkey * Unlock encrypted pool using Clevis (after reboot) stratis pool unlock clevis stratis pool list == User Experience == This latest release add a feature enhancement that will provide users with multiple unlock methods for encrypted Stratis pools == Dependencies == Two new dependencies have been added for clevis and clevis-luks == Contingency Plan == * Contingency mechanism: * Contingency deadline: N/A * Blocks release? No * Blocks product? No == Documentation == Please see https://stratis-storage.github.io/ for design documents and API reference. Development and issue tracking is at https://github.com/stratis-storage/ == Release Notes == Includes recent version of Stratis -- Ben Cotton He / Him / His Senior Program Manager, Fedora & CentOS Stream Red Hat TZ=America/Indiana/Indianapolis

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

devel-announce December 2020