devel-announce September 2020

devel-announce@lists.fedoraproject.org

9 participants
24 discussions

Planned Outage - pagure.io - 2020-10-01 08:00 UTC
by Pierre-Yves Chibon 30 Sep '20

30 Sep '20

There will be an outage starting at 2020-10-01 08:00 UTC, which will last approximately 4 hours. To convert UTC to your local time, take a look at http://fedoraproject.org/wiki/Infrastructure/UTCHowto or run: date -d '2020-10-01 08:00 UTC' Reason for outage: We are moving the service to a new server running RHEL8 and python3. Affected Services: pagure.io pagure.org Ticket Link: https://pagure.io/fedora-infrastructure/issue/9355 Please join #fedora-admin or #fedora-noc on irc.freenode.net or add comments to the ticket for this outage above.

1 0

F34 Change proposal: Compress Kernel Firmware (Self-Contained Change)
by Ben Cotton 29 Sep '20

29 Sep '20

https://fedoraproject.org/wiki/Changes/CompressKernelFirmware == Summary == Compress Kernel Firmwares to reduce on disk size == Owner == * Name: [[User:pbrobinson| Peter Robinson]] * Email: [mailto:pbrobinson@fedoraproject.org| pbrobinson(a)fedoraproject.org] == Detailed Description == Since the linux 5.3 kernel there has been support for loading firmware from xz compressed firmware. The upstream linux-firmware respository is now over 900Mb, not including other kernel firmware that are in Fedora but come from other sources. By compessing the firmware with "xz -C crc32", the only option currently supported in the kernel, we can reduce the ondisk size of the firmware by almost half. == Benefit to Fedora == Reduced on disk size of the firmware used by the kernel. == Scope == * Proposal owners: ** Add support upstream to the linux-firmware copy-firmware script to compess the firmware and create the symlinks to the compressed firmware ** Enable the upstream support in the Fedora linux-firmware package to compress the firmware at build time ** Enable compressing firmware in packages that contain firmware used by the kernel: eg alsa-sof-firmware, atmel-firmware, zd1211-firmware ** Enable the CONFIG_FW_LOADER_COMPRESS kernel option (long complete) * Other developers: ** No impact * Policies and guidelines: N/A (not a System Wide Change) * Trademark approval: N/A (not needed for this Change) == Upgrade/compatibility impact == There should be no upgrade impact, the support was added to the generic firmware loader interface in the kernel. == How To Test == Check devices that need firmware still work. Some devices that need firmware include: * GPU drivers such as nvidia, AMD and i915 * Wireless drivers such as those from Intel, Broadcom/Cyprus, TI, Qualcomm and Marvel * Wired network interfaces * Storage drivers * USB controllers and drivers == User Experience == Generally users should notice little to no difference. == Dependencies == N/A (not a System Wide Change) == Contingency Plan == * Contingency mechanism: Don't compress kernel firmware * Contingency deadline: GA * Blocks release? No. * Blocks product? No. == Documentation == N/A (not a System Wide Change) == Release Notes == N/A -- Ben Cotton He / Him / His Senior Program Manager, Fedora & CentOS Stream Red Hat TZ=America/Indiana/Indianapolis

1 0

F34 Change proposal: DNS Over TLS (System-Wide Change)
by Ben Cotton 29 Sep '20

29 Sep '20

https://fedoraproject.org/wiki/Changes/DNS_Over_TLS == Summary == Fedora will attempt to use DNS over TLS (DoT) if supported by configured DNS servers. == Owner == * Name: [[User:catanzaro|Michael Catanzaro]] * Email: <mcatanzaro(a)redhat.com> * Name: [[User:Zbyszek|Zbigniew Jędrzejewski-Szmek]] * Email: <zbyszek(a)in.waw.pl> == Detailed Description == We will build systemd with `-Ddefault-dns-over-tls=opportunistic` to protect DNS queries against passive network attackers. An active network attacker can trivially subvert this protection, but we cannot make DoT mandatory because other operating systems do not do so and many (or most?) DNS servers do not support it. DoT will only be used if the configured DNS server supports it and if it is not blocked by an active network attacker. Note that DoT is different from DNS over HTTPS (DoH). In particular, DoT is not an anti-censorship tool like DoH. It does not look like regular HTTPS traffic, and it can be blocked by network administrators if desired, so it should not be a problem for corporate networks. == Benefit to Fedora == DNS queries are encrypted and private by default, if the user's ISP supports DoT. Most probably don't, but users who manually configure a custom DNS server (e.g. Cloudflare or Google) will automatically benefit from DNS over TLS. == Scope == * Proposal owners: change meson flags in systemd.spec * Other developers: N/A (nothing should be required) * Release engineering: [https://pagure.io/releng/issue/9772 #9772] (a check of an impact with Release Engineering is needed) * Policies and guidelines: N/A (nothing should be required) * Trademark approval: N/A (not needed for this Change) * Alignment with Objectives: Nope == Upgrade/compatibility impact == DoT will be enabled automatically on upgrade to F34. If DoT is unsupported, systemd-resolved will fall back to unencrypted DNS, so there should be no compatibility impact. == How To Test == Load any website in a web browser. If you succeed, then name resolution probably works. Try using `resolvectl query fedoraproject.org` to see that resolvectl still works. Bonus points: set your DNS server to 1.1.1.1 or 8.8.8.8, then use Wireshark to see if your DNS is really encrypted or not. == User Experience == Users should not notice any difference in behavior. == Dependencies == No dependencies. == Contingency Plan == * Contingency mechanism: revert the change * Contingency deadline: can be done at any time, before F34 beta freeze would be best * Blocks release? No * Blocks product? No == Documentation == See the section `DNSOverTLS=` in the manpage `resolved.conf(5)` == Release Notes == systemd-resolved now enables DNS over TLS (DoT) support by default, in opportunistic mode. DoT will be used only if supported by your DNS server, and provides only best-effort encryption to protect against passive network observers. For compatibility with existing DNS servers, systemd-resolved will fall back to unencrypted DNS if DoT does not appear to be supported, reducing the security benefit. If you wish to manually configure systemd-resolved to prevent fallback to unencrypted DNS, set `DNSOverTLS=yes` in `/etc/systemd/resolved.conf`. Note that DoT is different than DNS over HTTPS (DoH) in that it does not use HTTPS and is therefore easy to distinguish from HTTPS traffic. -- Ben Cotton He / Him / His Senior Program Manager, Fedora & CentOS Stream Red Hat TZ=America/Indiana/Indianapolis

1 0

F34 Change proposal: Debug Info LLDB Index (System-Wide change)
by Ben Cotton 29 Sep '20

29 Sep '20

https://fedoraproject.org/wiki/Changes/DebugInfoLldbIndex == Summary == Provide .debug_names debug info index for LLDB for clang-built binaries using: clang -gdwarf-5 -gpubnames Debuginfo index significantly accelerates loading of *.debug files by debugger. Fedora currently provides ELF section .gdb_index for [https://www.gnu.org/software/gdb/ GDB debugger]. [https://lldb.llvm.org/ LLDB debugger] cannot use .gdb_index (as it is missing DIE offsets for more effective processing by LLDB) but LLDB can use .debug_names index. == Owner == * Name: [[User:jankratochvil| Jan Kratochvil ]] * Email: jan.kratochvil(a)redhat.com == Detailed Description == There are currently 3 formats of debug info index: * .gdb_index: It is currently produced in Fedora by GDB (/usr/bin/gdb-add-index), it is a part of rpmbuild process. It is compatible with GDB but incompatible with LLDB as it is missing essential DIE offsets needed by LLDB due to more effective (faster) reading of DWARF by LLDB. * .debug_names from GDB (augmentation "GDB\x00"): It can be produced by GDB (/usr/bin/gdb-add-index -dwarf-5) but its format is non-conforming to [http://www.dwarfstd.org/doc/DWARF5.pdf DWARF-5 standard]. LLDB expects DWARF-5 standard compliant .debug_names and therefore it is incompatible with this format. It can be expected GDB will fix the conformance in the future. Currently GDB .debug_names format has no advantage over GDB .gdb_index format. * .debug_names from clang (augmentation "LLVM0700"): It can be produced by clang (clang -gdwarf-5 -gpubnames) for LLDB. It is conforming to [http://www.dwarfstd.org/doc/DWARF5.pdf DWARF-5 standard], one can expect GDB will be able to read it in the future. It would be good to produce index from GCC by GDB and to produce index from clang by clang as the compatibility inside the same toolchain is best tested and supported. Using index across toolchains (index from GDB by LLDB or index from clang by GDB) should theoretically work but in practice there exist subtle differences in interpretation of more complicated DWARF constructs. It would be best to fix those but that will be always an afterthought. == Benefit to Fedora == * Faster startup of LLDB debugger using Fedora system *.debug files. == Scope == * Proposal owners: It affects all clang-built packages generating *-debuginfo.rpm. * Other developers: none * Policies and guidelines: All the needed changes should be done in [https://src.fedoraproject.org/rpms/redhat-rpm-config redhat-rpm-config]. The [https://src.fedoraproject.org/rpms/dwz dwz package] can be then retired. * Trademark approval: N/A (not needed for this Change) * Alignment with Objectives: The size differences are only for *-debuginfo.rpm which is outside of scope of the listed objectives. Currently the change will affect only packages using: %global toolchain clang Those are currently only these packages being built by clang and using this %toolchain framework: dotnet3.1 libcxxabi mtxclient nheko simde wine FIXME: Which other Fedora packages are being built by clang? == Upgrade/compatibility impact == Existing tools not supporting .debug_names will just ignore the additional ELF section. The only issue is current GDB would get confused by the clang .debug_names as it expects .debug_names to be in its incompatible GDB format - FIXME: Provide a GDB bugfix patch. Also each *-debuginfo.rpm has to exactly match NVRA of its binary package the Fedora change compatibility is not applicable. == How To Test == GDB should not get affected by the new .debug_names index from clang. LLDB should load Fedora system *.debug files faster. LLDB functionality should not be affected by the index from clang (that is a part of LLVM development/testsuite). "llvm-dwarfdump -debug-names *.debug" should show: Augmentation: 'LLVM0700' == User Experience == No user visible change. This affects what tools can developers use. == Dependencies == This Change is dependent on how is decided [[Changes/DebugInfoStandardization]]. This Change is dependent on RHEL-5 F-34 feature expected to be filed by Mark Wielaard. Mass rebuild is not required. Packages inherited from F-33 will just miss the LLDB index and LLDB will load them more slower. * .debug_names would need to be updated by DWZ but DWZ does not plan to support .debug_names (according to Mark Wielaard). ** If DWZ is dropped ([[Changes/DebugInfoStandardization]] gets approved) then clang can normally produce .debug_names for LLDB. ** If DWZ stays in use ([[Changes/DebugInfoStandardization]] gets rejected) then there are multiple options. LLDB currently cannot produce .debug_names (only clang can). GDB currently produces incompatible .debug_names format. *** [[Changes/DebugInfoStandardization]] should be applied at least for clang-built packages, preferred by this proposal. *** There was an idea DWZ would remove .debug_names. That would effectively reject this Change and make LLVM Toolchain slower due to a deficiency of the DWZ tool. *** There isn't anyone willing to implement updating of .debug_names into DWZ, moreover DWARF-5 standard does not specify a needed format for combination of both DWZ and .debug_names. Also LLDB currently does not support the DWZ format anyway. *** When GDB produces .debug_names compatible with DWARF-5 in the future it could theoretically produce .debug_names for LLDB. But that would mean the index for LLDB (and therefore interpretation of DWARF by LLDB) would be affected by interpretation of DWARF by GDB, that is a toolchain compatibility nightmare. * clang produces more effective .debug_names (one per executable; not one per *.o compilation unit) when using -flto which is [[LTOByDefault|default since F-33]] now. == Contingency Plan == * Contingency mechanism: Revert the change in [https://src.fedoraproject.org/rpms/redhat-rpm-config redhat-rpm-config]. LLDB can continue loading Fedora system *.debug files slightly slower. * Contingency deadline: beta freeze * Blocks release? No * Blocks product? N/A == Documentation == * [http://www.dwarfstd.org/doc/DWARF5.pdf DWARF-5] 6.1.1 Lookup by Name -- Ben Cotton He / Him / His Senior Program Manager, Fedora & CentOS Stream Red Hat TZ=America/Indiana/Indianapolis

1 0

Fedora 33 Beta Release Announcement
by Mohan Boddu 29 Sep '20

29 Sep '20

Fedora 33 Beta Released ---------------------------------- The Fedora Project is pleased to announce the immediate availability of Fedora 33 Beta, the next step towards our planned Fedora 33 release at the end of October. Download the prerelease from our Get Fedora site: * Get Fedora 33 Beta Workstation: https://getfedora.org/workstation/download/ * Get Fedora 33 Beta Server: https://getfedora.org/server/download/ * Get Fedora 33 IoT: https://getfedora.org/iot/download/ Or, check out one of our popular variants, including KDE Plasma, Xfce, and other desktop environments, as well as images for ARM devices: * Get Fedora 33 Beta Spins: https://spins.fedoraproject.org/prerelease * Get Fedora 33 Beta Labs: https://labs.fedoraproject.org/prerelease * Get Fedora 33 Beta ARM: https://arm.fedoraproject.org/prerelease ## Beta Release Highlights * All of the desktop variants of Fedora 33 Beta will use BTRFS as the default filesystem. * Fedora 33 Workstation Beta includes GNOME 3.38 * With Fedora 33 Beta, Fedora IoT is now an official Fedora Edition. * And more ... For more details about the release, read the full announcement at * https://fedoramagazine.org/announcing-the-release-of-fedora-33-beta/ or look for the prerelease pages in the download sections at * https://getfedora.org/ Since this is a Beta release, we expect that you may encounter bugs or missing features. To report issues encountered during testing, contact the Fedora QA team via the test(a)lists.fedoraproject.org mailing list or in #fedora-qa on Freenode. Regards, Mohan Boddu Fedora Release Engineering.

1 0

[NO ACTION REQUIRED] ELN Module Enablement
by Stephen Gallagher 28 Sep '20

28 Sep '20

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 We wanted to send out a heads-up to let folks know that once Infrastructure Freeze is lifted this week, we will be enabling modular builds for Fedora ELN. Once this happens, `platform:eln` will become available as a target for module builds. For anyone building packages with a BuildRequires of `platform: []`, building for ELN will happen automatically. If you have an explicit set of releases you build for, this will be unaffected. If your modules begin building for ELN, please ignore any output from the build-system at this time. We are working on infrastructure to enable automatic rebuilding of the `platform:rawhide` content only when a module is part of the explicit ELN set, but that portion of the tooling is not yet available at this time. * YOU DO NOT NEED TO ADDRESS ISSUES IN ELN MODULES AT THIS TIME * Our first step here is to ensure that the pipeline is working properly. The module maintainers are not on the hook at this time for addressing ELN- specific issues. You also do not need to modify your build scripts to either explicitly include or exclude ELN builds. Once the tooling becomes more advanced, you will no longer see ELN builds unless the module in question is explicitly intended for inclusion. -----BEGIN PGP SIGNATURE----- iQGzBAEBCAAdFiEEhQqd0dvyrMxvxJSRRduFpWgobREFAl9x/LUACgkQRduFpWgo bRFcAwv/QeT4X3Q7ltUIx3RYP3LFoCTMOrMTgXn6eewrARBcgDDaBOIZVt7EIrKK xhIbols9iXiK9lL57fxl7GiMQMkYAvlJtpUy+w/dp6UJj29rPc+SYjo8QKvl5KFm ewHzb+KSwRhoHWCo2ItxCI0bAbuqc0+PVuxyzlC8bRpv80YrhMYju6b2zg8lY2EW HPQs2KMyESTn4SwwXuvjUinStVSiPweOGbJEKgsdtNVgaT96Rpgph05uk49gTiUa AIwJT/kCXmX1k3cHj2/O3CO00+U2dbWCaR3i2sGJjdJ7CIv7cjheBY3fE0SIyhqC kMlv29ax/fXkhIobDcdJksD94P1E+BhiNogxdJ/1s+V7DYbyCm4V8hGu5ofXhGk1 wSDRYVgWgKK3DlTcIOiqoWYiTFgEaGily7Z9RPX7LkdFyLg1nMWhelw0VpZcTz0a E+K2k/QEJ+wC+XAfI4Y8PSRbcQfELYEkmOXokFE/jl4PHjwpQG7gAygcjdQWM8Is HuD2AwPg =z4z1 -----END PGP SIGNATURE-----

1 0

f33 latest build issues
by Kevin Fenzi 26 Sep '20

26 Sep '20

Greetings. Since Fedora 33 Beta was GO on thursday, and after tagging all the beta rpms, releng pushed all the pending f33 stable updates. However, this resulted in some issues where an older build was pushed after a newer one and used. This can happen when an update already is pending stable, and another update is created and bodhi is unable to obsolete the old update. Then they both go stable and it's chance which one "wins". I've cleaned up these issues. Here is the full list: catatonit-0.1.5-1.fc33 < catatonit-0.1.5-3.fc33 retagged catatonit-0.1.5-3.fc33 to f33 fabtests-1.11.0-1.fc33 < fabtests-1.11.0rc2-1.fc33 retagged fabtests-1.11.0rc2-1.fc33 to f33 google-api-python-client-1.10.1-1.fc33 < google-api-python-client-1.6.7-13.fc33 retagged google-api-python-client-1.6.7-13.fc33 to f33 igt-gpu-tools-1.25-1.20200818git4e5f76b.fc33 < igt-gpu-tools-1.25-2.20200719git9b964d7.fc33 retagged igt-gpu-tools-1.25-2.20200719git9b964d7.fc33 to f33 libfabric-1.11.0-1.fc33 < libfabric-1.11.0rc2-1.fc33 retagged libfabric-1.11.0rc2-1.fc33 to f33 magic-8.3.50-1.fc33 < magic-8.3.54-1.fc33 retagged magic-8.3.54-1.fc33 to f33 ocaml-lacaml-9.3.2-24.fc33 < ocaml-lacaml-9.3.2-25.fc33.1 retagged ocaml-lacaml-9.3.2-25.fc33.1 to f33 ovn-20.06.2-3.fc33 < ovn-20.06.2-4.fc33 retagged ovn-20.06.2-4.fc33 to f33 php-horde-Horde-Core-2.31.15-1.fc33 < php-horde-Horde-Core-2.31.16-1.fc33 retagged php-horde-Horde-Core-2.31.16-1.fc33 to f33 php-nrk-Predis-1.1.4-1.fc33 < php-nrk-Predis-1.1.6-1.fc33 retagged php-nrk-Predis-1.1.6-1.fc33 to f33 plplot-5.15.0-19.fc33 < plplot-5.15.0-19.fc33.1 retagged plplot-5.15.0-19.fc33.1 to f33 pywbem-0.14.6-6.fc33 < pywbem-1.0.1-1.fc33 retagged pywbem-1.0.1-1.fc33 to f33 qt-creator-4.13.1-1.fc33 < qt-creator-4.13.1-2.fc33 retagged qt-creator-4.13.1-2.fc33 to f33 qt5-qtwebengine-5.15.0-4.fc33 < qt5-qtwebengine-5.15.1-1.fc33 retagged qt5-qtwebengine-5.15.1-1.fc33 to f33 qt5-qtwebkit-5.212.0-0.51.alpha4.fc33 < qt5-qtwebkit-5.212.0-0.52.alpha4.fc33 retagged qt5-qtwebkit-5.212.0-0.52.alpha4.fc33 to f33 slirp4netns-1.1.4-1.fc33 < slirp4netns-1.1.4-4.dev.giteecccdb.fc33 retagged slirp4netns-1.1.4-4.dev.giteecccdb.fc33 to f33 stdair-1.00.10-5.fc33 < stdair-1.00.10-6.fc33 retagged stdair-1.00.10-6.fc33 to f33 sympa-6.2.56-2.fc33 < sympa-6.2.56-2.fc33.1 retagged sympa-6.2.56-2.fc33.1 to f33 systemd-246.3-1.fc33 < systemd-246.4-2.fc33 retagged systemd-246.4-2.fc33 to f33 uboot-tools-2020.10-0.3.rc2.fc33 < uboot-tools-2020.10-0.4.rc4.fc33 retagged uboot-tools-2020.10-0.4.rc4.fc33 to f33 video-downloader-0.5.5-1.fc33 < video-downloader-0.5.6-1.fc33 retagged video-downloader-0.5.6-1.fc33 to f33 yacreader-9.7.0-1.fc33 < yacreader-9.7.1-1.fc33 retagged yacreader-9.7.1-1.fc33 to f33 Hopefully bodhi will grow the ability to stop this from happening in future milestones. kevin

1 0

Fedora 33 Beta is GO
by Ben Cotton 24 Sep '20

24 Sep '20

The Fedora 33 Beta RC1.3 compose[1] is GO and will be shipped live on Tuesday, 17 March 2020. For more information please check the Go/No-Go meeting minutes [2] or log [3]. Thank you to everyone who has and still is working on this release! Subsequent schedule milestones[4] are unchanged. The Final Freeze begins on 6 October. [1] https://dl.fedoraproject.org/pub/alt/stage/33_Beta-1.3/ [2] https://meetbot.fedoraproject.org/fedora-meeting-1/2020-09-24/f33-beta-go_n… [3] https://meetbot.fedoraproject.org/fedora-meeting-1/2020-09-24/f33-beta-go_n… [4] https://fedorapeople.org/groups/schedule/f-33/f-33-key-tasks.html -- Ben Cotton He / Him / His Senior Program Manager, Fedora & CentOS Stream Red Hat TZ=America/Indiana/Indianapolis

1 0

F34 Change proposal: Debug Info Standardization (from DWZ to -fdebug-types-section) (System-Wide Change proposal)
by Ben Cotton 24 Sep '20

24 Sep '20

https://fedoraproject.org/wiki/Changes/DebugInfoStandardization == Summary == Fedora 18 implemented [[Features/DwarfCompressor]]. As the format did not get widespread and the tool is not much maintained it became burden to make existing debugging tools compatible with Fedora debug info. == Owner == * Name: [[User:jankratochvil| Jan Kratochvil ]] * Email: jan.kratochvil(a)redhat.com == Detailed Description == Debug info files *.debug contained in *-debuginfo.rpm are very big in general (x86_64 Fedora 32 distribution has debug/ directory of 82GB while all its other files are only 75GB). There exist several methods how to make the *-debuginfo.rpms at least a bit smaller. Fedora 18 started using DWZ tool (from [[Features/DwarfCompressor]]) while [https://gcc.gnu.org/pipermail/gcc-patches/2008-August/246281.html Google implemented] the same goal in a different way called -fdebug-types-section. Almost nobody uses existing Fedora DWZ (only Fedora/CentOS/RHEL and SuSE OSes) and so its support is missing in tools like [https://lldb.llvm.org/ LLDB], [[llvm-dwarfdumphttps://llvm.org/docs/CommandGuide/llvm-dwarfdump.html|llvm-d…]] or binutils readelf. -fdebug-types-section is used internally by Google (produced by clang). Debian does not store any debug info archives. Ubuntu uses neither -fdebug-types-section nor DWZ. * DWZ advantage: On the whole Fedora distro it saves 3.3% (5GB of the 157GB distribution size) ** If the 3.3% size increase is a concern I can implement a different optimization ([https://whova.com/embedded/session/llvm_202010/1193947/ talk (2)]) as a GCC post-processing phase which would require no changes in any DWARF consumers. * DWZ disadvantage: DWZ has currently less support across consumers (LLDB, llvm-dwarfdump, binutils readelf) * DWZ disadvantage: DWZ requires 8x times more complicated (LoC count) support in consumers than -fdebug-types-section. * DWZ disadvantage: DWZ cannot update LLVM .debug_names index which can be generated only by clang (it cannot be regenerated later for DWZ-compressed file) * DWZ disadvantage: DWZ DWARF-5 support is a work-in-progress. DWZ has been blocking DWARF-5 for Fedora for 3.5 years and only after I have now proposed to drop DWZ Mark Wielaard has started porting DWZ to DWARF-5. It can be expected next DWARF extensions will remain unsupported again. Even currently there is no plan to support DWARF-5 features used by clang which may need -fdebug-types-section for clang-built binaries or no size optimization of clang-built debug info at all. * DWZ disadvantage: Compilation (linking) requires for C++ up to 2x as big disk space (as DWZ is processing files after linker and DWZ is incompatible with -fdebug-types-section) * DWZ disadvantage: Compilation (linking) is slower This proposed DWARF format was originally submitted already for Fedora 18 as [[Features/DebugTypesSections]]. == Benefit to Fedora == * Better compatibility with existing debugging and tracing tools, primarily [https://lldb.llvm.org/ LLDB]. * Less resource-intensive rebuilds of C++ packages (in disk space, memory requirements and compilation time). == Scope == * Proposal owners: It affects all packages generating *-debuginfo.rpm, that is compiled (not scripted) languages. * Other developers: Report any possible debuginfo incompatibility (unexpected). * Release engineering: [https://pagure.io/releng/issues #Releng issue number] (a check of an impact with Release Engineering is needed) * Policies and guidelines: All the needed changes should be done in [https://src.fedoraproject.org/rpms/redhat-rpm-config redhat-rpm-config]. The [https://src.fedoraproject.org/rpms/dwz dwz package] can be then retired. * Trademark approval: N/A (not needed for this Change) * Alignment with Objectives: The size differences are only for *-debuginfo.rpm which is outside of scope of the listed objectives. == Upgrade/compatibility impact == As *-debuginfo.rpm have to exactly match NVRA of its binary package the compatibility is not relevant. Existing tools supporting DWZ will still support the DWZ file format in packages which have not been rebuilt. == How To Test == The change will update [https://src.fedoraproject.org/rpms/redhat-rpm-config redhat-rpm-config] by [https://people.redhat.com/jkratoch/redhat-rpm-config-fdebug-types-section.p… an -fdebug-types-section patch]. Then one can use rpmbuild to rebuild a package. For mock use -a|--addrepo with modified redhat-rpm-config.rpm (with increased NVRA). For packages already rebuilt in Koji nothing is needed. Test programs like lldb and gdb if they still can print source code, function parameters, variables etc. One should also verify integrated testsuites of tools like clang, lldb, gcc, binutils, gdb, elfutils or rpm are not regressing with the -fdebug-types-section option. One can also compare *.debug files built with/without DWZ and/or -fdebug-types-section using [https://src.fedoraproject.org/rpms/libabigail libabigail] utility dwdiff but that will be rather done by the change owner. == User Experience == No user visible change. This affects what tools can developers use. == Dependencies == none == Contingency Plan == * Contingency mechanism: Revert the change in [https://src.fedoraproject.org/rpms/redhat-rpm-config redhat-rpm-config]. Fedora can continue using DWZ, just some debugging/tracing tools will stay incompatible. * Contingency deadline: beta freeze * Blocks release? No * Blocks product? N/A == Documentation == * [http://www.dwarfstd.org/doc/DWARF5.pdf DWARF-5] E.2 Using Type Units * [https://gcc.gnu.org/onlinedocs/gcc/Debugging-Options.html#index-fdebug-type… GCC -fdebug-types-section] -- Ben Cotton He / Him / His Senior Program Manager, Fedora & CentOS Stream Red Hat TZ=America/Indiana/Indianapolis

1 0

F34 Change proposal: Move deprecated bluetooth utilities to subpackage (Self-Contained Change)
by Ben Cotton 24 Sep '20

24 Sep '20

https://fedoraproject.org/wiki/Changes/BluetoothDeprecated == Summary == Move deprecated bluez bluetooth utilities to a sub package to indicate their status. == Owner == * Name: [[User:pbrobinson| Peter Robinson]] * Email: [mailto:pbrobinson@fedoraproject.org| pbrobinson(a)fedoraproject.org] == Detailed Description == There's a number of utilities in the upstream bluez bluetooth package that have long been deprecated with their functionality replaced by the core bluetoothctl utility. They're no longer receiving updates and at some point may be removed. Move these utilities to a dedicated sub package to indicate their upstream support status. == Benefit to Fedora == Users are aware of the status of the various bluez utilities and why they may not support newer bluetooth functionality. == Scope == * Proposal owners: ** Create a sub package for deprecated bluetooth utilities, that is installed on upgrade, but not installed by default on new installs. * Other developers: ** No impact * Policies and guidelines: N/A * Trademark approval: N/A == Upgrade/compatibility impact == The new sub package will be installed on upgrade if bluez is installed, the deprecated utilities sub package will not be installed by default on a new install but will be available in the package repository. == How To Test == Check the new package is installed on upgrade, check the new package isn't installed for new installs == User Experience == Users shouldn't notice any difference, these utilities aren't used by standard bluetooth integration into desktops such as mice/keyboards/audio. They are command line utilities and bluetoothctl has superseded them and generally supports more functionality and newer reversions of the bluetooth spec. == Dependencies == N/A (not a System Wide Change) == Contingency Plan == * Contingency mechanism: N/A it's a straight fowrard packaging change. * Contingency deadline: N/A (not a System Wide Change) * Blocks release? No. * Blocks product? No. == Documentation == N/A (not a System Wide Change) == Release Notes == N/A -- 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 September 2020