devel June 2022

devel@lists.stg.fedoraproject.org

201 participants
282 discussions

[HEADS UP] Sphinx 5 and docutils 0.18.1 coming to Rawhide on July 11th
by Karolina Surma 18 Jul '22

18 Jul '22

Hello packagers, The new major version of the popular documentation framework Sphinx has been recently released[0]. It brings many changes, among which there is support of docutils 0.18.1. We aim to update both packages together in Fedora Rawhide on **July 11th**. As usual, an ongoing attempt to smoothly integrate the updates takes place using Copr[1]. There are some packages impacted with the new changes. Please take time to review an fix the package, or coordinate with the upstream. If your package hasn't succeeded to build with Python 3.11 yet, we can't test whether it will work with this update. Common issues and mitigation - `None` is no longer accepted as value of `language` in conf.py Solution: Use `language = 'en'` instead. - Build/ tests fail with: `AttributeError: 'path' object has no attribute 'text'` Solution: use `path.read_text()` instead Test your package locally in mock using the provided test Copr $ mock -r fedora-rawhide-x86_64 --addrepo=https://download.copr.fedorainfracloud.org/results/ksurma/sphinx-5/fedora-rawhide-x86_64/ --no-clean <your.src.rpm> $ mock -r fedora-rawhide-x86_64 --addrepo=https://download.copr.fedorainfracloud.org/results/ksurma/sphinx-5/fedora-rawhide-x86_64/ shell Packages that pin Sphinx and docutils to lower versions than are about to be introduced, and will effectively stop working after the update has reached Rawhide: Sphinx < 5: python-h2-0:4.1.0-7.fc37.src python-priority-0:2.0.0-7.fc37.src python-sphinx-panels-0:0.6.0-3.fc37.src python-sphinx-tabs-0:3.1.0-7.fc37.src python3-sphinxcontrib-zopeext-0:0.3.2-3.fc37.noarch docutils < 0.18: python-sphinx-tabs-0:3.1.0-7.fc37.src python3-sphinx_rtd_theme-0:1.0.0-6.fc37.noarch Full list of known affected packages Maintainers by package: copr-keygen clime dturecek frostyx msuchy praiskup coq amdunn jjames diceware kushal kea fjanus mosvald zdohnal libcamera javierm liblognorm alakatos rsroka zfridric python-django bkabrda churchyard jdornak mrunge rdopiera salimma sgallagh python-graphviz eclipseo python-h2 eclipseo python-pikepdf qulogic zdohnal python-priority eclipseo python-sphinx-panels qulogic python-sphinx-tabs hobbes1069 python-sphinx_rtd_theme jjames ksurma piotrp python-sphinxcontrib-bibtex jjames python-sphinxcontrib-htmlhelp churchyard cstratak python-sphinxcontrib-jsmath churchyard cstratak python-sphinxcontrib-qthelp churchyard cstratak python-sphinxcontrib-zopeext jjames Packages by maintainer: alakatos liblognorm amdunn coq bkabrda python-django churchyard python-django python-sphinxcontrib-htmlhelp python-sphinxcontrib-jsmath python-sphinxcontrib-qthelp clime copr-keygen cstratak python-sphinxcontrib-htmlhelp python-sphinxcontrib-jsmath python-sphinxcontrib-qthelp dturecek copr-keygen eclipseo python-graphviz python-h2 python-priority fjanus kea frostyx copr-keygen hobbes1069 python-sphinx-tabs javierm libcamera jdornak python-django jjames coq python-sphinx_rtd_theme python-sphinxcontrib-bibtex python-sphinxcontrib-zopeext ksurma python-sphinx_rtd_theme kushal diceware mosvald kea mrunge python-django msuchy copr-keygen piotrp python-sphinx_rtd_theme praiskup copr-keygen qulogic python-pikepdf python-sphinx-panels rdopiera python-django rsroka liblognorm salimma python-django sgallagh python-django zdohnal kea python-pikepdf zfridric liblognorm Cheers, Karolina Surma [0] https://www.sphinx-doc.org/en/master/changes.html [1] https://copr.fedorainfracloud.org/coprs/ksurma/sphinx-5/

3 4

F37 proposal: Deprecate openssl1.1 package (System-Wide Change)
by Vipul Siddharth 18 Jul '22

18 Jul '22

https://fedoraproject.org/wiki/Changes/DeprecateOpensslCompat This document represents a proposed Change. As part of the Changes process, proposals are publicly announced in order to receive community feedback. This proposal will only be implemented if approved by the Fedora Engineering Steering Committee. == Summary == We are going to deprecate openssl1.1 package, stop shipping the corresponding devel package, and stop respecting crypto policies in openssl1.1 package itself. == Owner == * Name: [[User:DmitryBelyavskiy| Dmitry Belyavskiy]] * Email: dbelyavs(a)redhat.com == Detailed Description == In Fedora 36 we switched to OpenSSL 3.0 branch. This is a brand new version with new architecture. We left the openssl1.1 package for the applications that were unable to switch to the new API/architecture, 3rd-party applications, etc. As openssl 1.1 has a predictable EOL, we want to ensure that no new products relying on it will appear in Fedora. == Benefit to Fedora == This proposal ensures than no new packages in Fedora will rely on the deprecated OpenSSL version that will cause an overall increase of security/stability, and will reduce the amount of old packages relying on OpenSSL 1.1 series. It will also reduce the maintenance burden for the OpenSSL maintainers, especially when new CVEs are published. == Scope == * Proposal owners: ** Remove devel package ** eliminate crypto policy support from the main package ** provide assistance in migration to other developers * Other developers: ** Patch their packages to work with OpenSSL 3.0 ** Fedora/RHEL distributions provide some syntax sugar related to https://fedoraproject.org/wiki/Packaging:CryptoPolicies. For the packages still relying to openssl1.1 the syntax provided by crypto policies will no longer be supported. The changes implemented according to https://fedoraproject.org/wiki/Packaging:CryptoPolicies (e.g. using "PROFILE=SYSTEM" as default TLS ciphersuites configuration) should be removed. * Release engineering: This feature doesn't require coordination with release engineering. * Policies and guidelines: N/A (not needed for this Change) * Trademark approval: N/A (not needed for this Change) == Upgrade/compatibility impact == As Crypto Policy support is removed from openssl1.1, applications will need to adjust the configuration files if they contain the line "PROFILE=SYSTEM" according to https://fedoraproject.org/wiki/Packaging:CryptoPolicies == How To Test == Regular application tests should catch the regressions caught by these changes. == Dependencies == No packages should depend on openssl1.1-devel packages that is eliminated. == Contingency Plan == Revert the shipped configuration Contingency deadline: TBD == Documentation == TBW == Release Notes == TBW -- Vipul Siddharth He/His/Him FPgM team member

26 64

F37 Change Proposal: MAC Address Policy none (System-Wide Change)
by Vipul Siddharth 15 Jul '22

15 Jul '22

This document represents a proposed Change. As part of the Changes process, proposals are publicly announced in order to receive community feedback. This proposal will only be implemented if approved by the Fedora Engineering Steering Committee. == Summary == The `systemd-udev` package installs `"/usr/lib/systemd/network/99-default.link"`, which sets `Link.MACAddressPolicy=persistent`. This proposal is to change it to set `Link.MACAddressPolicy=none` to stop changing the MAC address. This is particularly important for bridge and bond devices. This change can either only apply to bridge/bond devices, or to various software devices. That is to be discussed. == Owner == * Name: [[User:thaller|Thomas Haller]] (NetworkManager) * Email: <thaller(a)redhat.com> * Name: [[User:dustymabe| Dusty Mabe]] (Fedora CoreOS) * Email: <dmabe(a)redhat.com> == Detailed Description == On Fedora, udev by default changes the MAC address of a wide range of software devices. This was introduced by systemd 242 in early 2019 (Fedora 31), when `MACAddressPolicy=` was extended to affect more types of devices. With `MACAddressPolicy=persistent` udev's aim is to provide a stable MAC address, otherwise the kernel will assign a random one. However, that can cause problems: Firstly, software devices are always created by some tool that has plans for the device. The tool may not expect that udev is going to change the MAC address and races against that. The best solution for the tool is to set the MAC address when creating an interface. This will prevent udev from changing the MAC address according to the MACAddressPolicy. Otherwise, the tool should wait for udev to initialize the device to avoid the race. In theory, a tool is always advised to wait for udev to initialize the device. However, if it were not for MACAddressPolicy, in common scenarios udev doesn't do anything relevant for software devices to make that necessary. Secondly, for interface types bridge and bond, an unset MAC address has a special meaning to the kernel and the MAC address of the first port is used. If udev changes the MAC address, that no longer works. Now the generated MAC address is not directly discoverable as it is based on `/etc/machine-id` ([https://www.man7.org/linux/man-pages/man5/machine-id.5.html machine-id(5)]), among other data. Even if there were a tool to easily calculate the MAC address, it could be cumbersome to use it without logging into the machine first. The MAC address can directly affect the assigned IP address, for example when using DHCP. When booting a new virtual machine, the user might know the MAC address of the (virtual) "physical" interfaces. When bonding/bridging those interfaces, the bond/bridge would get one of the well known MAC addresses. `MACAddressPolicy=persistent` interferes with that. The goal of persistent policy is to provide a stable MAC address. Note that if the tool or user who created the interface would want a certain MAC address, they have all the means to set it already. That applies regardless whether the tool is iproute2, NetworkManager, systemd-networkd. Neither NetworkManager nor systemd-networkd rely on udev's MACAddressPolicy for setting the MAC address. This behavior is mostly useful for plain `ip link add`, but it's unclear which real world user wants this behavior. Of course, the user is welcome to configure the MAC address in any way they want. Including, dropping a link file that sets `MACAddressPolicy=persistent`. The problem is once udev sets a MAC address, it cannot be unset. Which makes this problematic to do by default. While Fedora inherited this behavior from upstream systemd, RHEL-9 does not follow this behavior ([https://gitlab.com/redhat/centos-stream/rpms/systemd/-/blob/c8953519504bf2e… centos9], [https://bugzilla.redhat.com/show_bug.cgi?id=1921094 rh#1921094]). For RHEL-8, this doesn't apply because the systemd there is too old to change the MAC address of most software devices. This could be either implemented by patching `/usr/lib/systemd/network/99-default.link` to have a different policy, or by dropping a link file with higher priority. In the latter case, that override could be shipped either by udev or even by NetworkManager. Another option is to change the scope of this proposal to only change to `MACAddressPolicy=none` for the device types where this causes the most issues (bridge/bond/team). == Feedback == This was also discussed on upstream systemd mailing list [https://lists.freedesktop.org/archives/systemd-devel/2022-May/047893.html here]. The upstream systemd maintainers' opinion is that the current udev behavior is desirable, but accepts that distributions (or network stacks such as NetworkManager) may choose to change the default depending on their needs ([https://lists.freedesktop.org/archives/systemd-devel/2022-May/047943.html reference]). The goal here is to find out what the Fedora community thinks is the most appropriate default. The RHEL-9 bug is [https://bugzilla.redhat.com/show_bug.cgi?id=1921094 [rh#1921094]]. == Benefit to Fedora == Pros: - Consistent behavior with RHEL8 and RHEL9. - Avoid race of udev and the tool that creates the interface. - Bridge and bond interfaces can get the MAC addresses from their first port. In the case of `MACAddressPolicy=none` for a bond (or bridge) the bond will get a MAC related to one of its physical NIC devices. In the case of provisioning new systems (especially in a large datacenter) information about the server can be used to configure the network environment (DHCP, Firewall, etc) before the server is ever even powered on. This does mean that you may have to update your network environment configuration if you replace a NIC (con), but that you won't have to update your network environment configuration if you re-install your server (pro), which is what you'd have to do now with `MACAddressPolicy=persistent`. Cons: - Deviate from upstream systemd. It is desirable that RHEL and Fedora behaves similar. A possible outcome could be the current behavior stays and RHEL 10 would change behavior. On the other hand, different distributions (or even Fedora spins) have different uses and needs. Deviating might be fine. In the same vein, there is also a desire to stay close to upstream systemd behavior. But the uses of systemd project go beyond Fedora/RHEL, so deviating here may also be fine. == Scope == * Proposal owners: The main goal of this request is to generate productive discussion and find the desired behavior. The implementation/changes are either way very simple. * Other developers: Other projects that wish a certain MAC address are welcome to set it for their devices. Including using udev's MACAddressPolicy. * Release engineering: Not needed for this change. * Policies and guidelines: N/A (not needed for this Change) * Trademark approval: N/A (not needed for this Change) * Alignment with Objectives: == Upgrade/compatibility impact == After the change, the MAC address for the affected device types changes. == How To Test == 1) Create a software device two times, for example `ip link add type bridge`. Note that the MAC address is either stable or random, depending on the `MACAddressPolicy=`. 2) Note that if the software device has the MAC address set initially, udev does not change it (`ip link add address aa:aa:aa:aa:aa:aa type bridge`). That depends on `/sys/class/net/$dev/addr_assign_type`. 3) Create a bridge/bond interface without setting the MAC address. Note that if `MACAddressPolicy=none`, the MAC address is random at first. Note that attaching the first port will update the controller's MAC address. On the other hand, with `MACAddressPolicy=persistent`, the MAC address of the controller is fixed and not inherited from the port. 4) Run ip monitor link & while : ; do ip link del xxx ip link add name xxx type dummy \ && ip link set xxx addr aa:00:00:00:00:00 \ && ip link show xxx | grep -q aa:00:00:00:00:00 \ || break done to reproduce the race between a simple tool and udev changing the MAC address. == User Experience == Bond/bridge devices would again get assigned the MAC address of the first NIC added to the device. If we chose to not limit the scope of this change to just bonds/bridges then all software devices would get randomly assigned MAC addresses. == Dependencies == None. == Contingency Plan == If the change is rejected, nothing needs to be done. The change itself will be simple to implement. Contingency deadline: beta freeze Blocks release? No == Documentation == TODO. == Release Notes == -- Vipul Siddharth He/His/Him FPgM team member

13 27

F37 proposal: Add -fno-omit-frame-pointer to default compilation flags (System-Wide Change proposal)
by Ben Cotton 13 Jul '22

13 Jul '22

https://fedoraproject.org/wiki/Changes/fno-omit-frame-pointer This document represents a proposed Change. As part of the Changes process, proposals are publicly announced in order to receive community feedback. This proposal will only be implemented if approved by the Fedora Engineering Steering Committee. == Summary == Fedora will add -fno-omit-frame-pointer to the default C/C++ compilation flags, which will improve the effectiveness of profiling and debugging tools. == Owner == * Name: [[User:daandemeyer| Daan De Meyer]], [[User:Dcavalca| Davide Cavalca]], [[ Andrii Nakryiko]] * Email: daandemeyer(a)fb.com, dcavalca(a)fb.com, andriin(a)fb.com == Detailed Description == Credits to Mirek Klimos, whose internal note on stacktrace unwinding formed the basis for this change proposal (myreggg(a)gmail.com) Any performance or efficiency work relies on accurate profiling data. Sampling profilers probe the target program's call stack at regular intervals and store the stack traces. If we collect enough of them, we can closely approximate the real cost of a library or function with minimal runtime overhead. Stack trace capture what’s running on a thread. It should start with clone - if the thread was created via clone syscall - or with _start - if it’s the main thread of the process. The last function in the stack trace is code that CPU is currently executing. If a stack starts with [unknown] or any other symbol, it means it's not complete. === Unwinding === How does the profiler get the list of function names? There are two parts of it: # Unwinding the stack - getting a list of virtual addresses pointing to the executable code # Symbolization - translating virtual addresses into human-readable information, like function name, inlined functions at the address, or file name and line number. Unwinding is what we're interested in for the purpose of this proposal. The important things are: * Data on stack is split into frames, each frame belonging to one function. * Right before each function call, the return address is put on the stack. This is the instruction address in the caller to which we will eventually return — and that's what we care about. * One register, called the "frame pointer" or "base pointer" register (RBP), is traditionally used to point to the beginning of the current frame. Every function should back up RBP onto the stack and set it properly at the very beginning. The “frame pointer” part is achieved by adding push %rbp, mov %rsp,%rbp to the beginning of every function and by adding pop %rbp before returning. Using this knowledge, stack unwinding boils down to traversing a linked list: https://i.imgur.com/P6pFdPD.png === Where’s the catch? === The frame pointer register is not necessary to run a compiled binary. It makes it easy to unwind the stack, and some debugging tools rely on frame pointers, but the compiler knows how much data it put on the stack, so it can generate code that doesn't need the RBP. Not using the frame pointer register can make a program more efficient: * We don’t need to back up the value of the register onto the stack, which saves 3 instructions per function. * We can treat the RBP as a general-purpose register and use it for something else. Whether the compiler sets frame pointer or not is controlled by the -fomit-frame-pointer flag and the default is "omit", meaning we can’t use this method of stack unwinding by default. To make it possible to rely on the frame pointer being available, we'll add -fno-omit-frame-pointer to the default C/C++ compilation flags. This will instruct the compiler to make sure the frame pointer is always available. This will in turn allow profiling tools to provide accurate performance data which can drive performance improvements in core libraries and executables. == Feedback == === Potential performance impact === * Meta builds all its libraries and executables with -fno-omit-frame-pointer by default. Internal benchmarks did not show significant impact on performance when omitting the frame pointer for two of our most performance intensive applications. * Firefox recently landed a change to preserve the frame pointer in all jitted code (https://bugzilla.mozilla.org/show_bug.cgi?id=1426134) No significant decrease in performance was observed. * Kernel 4.8 frame pointer benchmarks by Suse showed 5%-10% regressions in some benchmarks (https://lore.kernel.org/all/20170602104048.jkkzssljsompjdwy@suse.de/T/#u) Should individual libraries or executables notice a significant performance degradation caused by including the frame pointer everywhere, these packages can opt-out on an individual basis as described in https://docs.fedoraproject.org/en-US/packaging-guidelines/#_compiler_flags. === Alternatives to frame pointers === There are a few alternative ways to unwind stacks instead of using the frame pointer: * [https://dwarfstd.org DWARF] data - The compiler can emit extra information that allows us to find the beginning of the frame without the frame pointer, which means we can walk the stack exactly as before. The problem is that we need to unwind the stack in kernel space which isn't implemented in the kernel. Given that the kernel implemented it's own format (ORC) instead of using DWARF, it's unlikely that we'll see a DWARF unwinder in the kernel any time soon. The perf tool allows you to use the DWARF data with --call-graph=dwarf, but this means that it copies the full stack on every event and unwinds in user space. This has very high overhead. * [https://www.kernel.org/doc/html/v5.3/x86/orc-unwinder.html ORC] (undwarf) - problems with unwinding in kernel led to creation of another format with the same purpose as DWARF, just much simpler. This can only be used to unwind kernel stack traces; it doesn't help us with userspace stacks. More information on ORC can be found [https://lwn.net/Articles/728339 here]. * [https://lwn.net/Articles/680985 LBR] - New Intel CPUs have a feature that gives you source and target addresses for the last 16 (or 32, in newer CPUs) branches with no overhead. It can be configured to record only function calls and to be used as a stack, which means it can be used to get the stack trace. Sadly, you only get the last X calls, and not the full stack trace, so the data can be very incomplete. On top of that, many Fedora users might still be using CPUs without LBR support which means we wouldn't be able to assume working profilers on a Fedora system by default. To summarize, if we want complete stacks with reasonably low overhead (which we do, there's no other way to get accurate profiling data from running services), frame pointers are currently the best option. == Benefit to Fedora == Implementing this change will provide profiling tools with easy access to stacktraces of installed libraries and executables which will lead to more accurate profiling data in general. This in turn can be used to implement optimizations to core libraries and executables which will improve the overall performance of Fedora itself and the wider Linux ecosystem. Various debugging tools can also make use of the frame pointer to access the current stacktrace, although tools like gdb can already do this to some degree via embedded dwarf debugging info. == Scope == * Proposal owners: Put up a PR to change the rpm macros to build packages by default with -fno-omit-frame-pointer by default. * Other developers: Review and merge the PR implementing the Change. * Release engineering: [https://pagure.io/releng/issues #Releng issue number]. A mass rebuild is required. * Policies and guidelines: N/A (not needed for this Change) * Trademark approval: N/A (not needed for this Change) * Alignment with Objectives: N/A == Upgrade/compatibility impact == This should not impact upgrades in any way. == How To Test == # Build the package with the updated rpm macros # Profile the binary with `perf record -g <binary>` # Inspect the perf data with `perf report -g 'graph,0.5,caller'` # When expanding hot functions in the perf report, perf should show the full call graph of the hot function (at least for all functions that are part of the binary compiled with -fno-omit-frame-pointer) == User Experience == Fedora users will be more likely to have a streamlined experience when trying to debug/profile system executables/libraries. Tools such as perf will work out of the box instead of requiring to users to provide extra options (e.g. --call-graph=dwarf/LBR) or requiring users to recompile all relevant packages with -fno-omit-frame-pointer. == Dependencies == The rpm macros for Fedora need to be adjusted to include -fno-omit-frame-pointer in the default C/C++ compilation flags. == Contingency Plan == * Contingency mechanism: The new version can be released without every package being rebuilt with fno-omit-frame-pointer. Profiling will only work perfectly once all packages have been rebuilt but there will be no regression in behavior if not all packages have been rebuilt by the time of the release. If the Change is found to introduce unacceptable regressions, the PR implementing it can be reverted and affected packages can be rebuilt. * Contingency deadline: Final freeze * Blocks release? No == Documentation == * Original proposal for in-kernel DWARF unwinder (rejected): https://lkml.org/lkml/2017/5/5/571 == Release Notes == Packages are now compiled with frame pointers included by default. This will enable a variety of profiling and debugging tools to show more information out of the box. -- Ben Cotton He / Him / His Fedora Program Manager Red Hat TZ=America/Indiana/Indianapolis

32 112

F37 Change Proposal: Unfiltered Flathub (System-Wide Change)
by Vipul Siddharth 13 Jul '22

13 Jul '22

26 55

F37 Change: Drop i686 builds of jdk8,11,17 and latest (18) rpms from f37 onwards (System-Wide Change)
by Ben Cotton 13 Jul '22

13 Jul '22

https://fedoraproject.org/wiki/Changes/Drop_i686_JDKs == Summary == java-1.8.0-openjdk, java-11-openjdk, java-17-openjdk and java-latest-openjdk packages will no longer build i686 subpackages == Owner == * Name: [[User:jvanek| Jiri Vanek]] * Email: <jvanek(a)redhat.com> * Product: java and java stack * Responsible WG: java-sig (java and java-maint)(which no longer exists) === Expected schedule === * during march, drop i686 builds from all jdks in fedora rawhide == Detailed Description == Fedora currently ships: * java-1.8.0-openjdk (LTS) * java-11-openjdk (LTS) * java-17-openjdk (LTS) * java-latest-openjdk (STS, jdk18). All those builds on all architectures except jdk8, where arm32 with jit is built by different package. Unluckily, the i686 bit builds of jdk are rotten in upstream. The recent breakage of i686 JIT just before branching nearly killed jdk17 as system jdk feature. The rotting have main visibility with newer GCCs. If GCC bump, and it does, it always triggers new issues in i686 JIT, and there is less and less people to somehow workaround them. Unluckily, there is probably no longer anyone willing to really fix them == Benefit to Fedora == The i686 builds are rotten in usptream, and to patch them localy had become pain. We may be introducing very bugy i686 jdk. Better then to do so, we would rather not ship that at all. This will untie hands of both JDK and GCC developers, who will no longer need to dive into nasty legacy code. == Scope == ==== Change owners ==== * we will simiply stop building i686 pkg in rawhide ==== Other developers ==== * may notice the multilib i686 java missing. * it is up to them to drop i686 builds or to povide workaround (if possible) ==== Other ==== * Release engineering: https://pagure.io/releng/issue/10686 * Trademark approval: N/A (not needed for this Change) == Upgrade/compatibility impact == * The upgrade on multilib systems will lead to autoremoval of i686 javastack * which should be minimum - 99% of javastack is noarch == How To Test == install i686 java will result to not packages found == User Experience == User experience on multilib systems will be bad. Bad reasonable. == Dependencies == There are is unknown number of multilib java consumers. I expect some of them may rise voice, but that will have to handled one by one. == Contingency Plan == * Contingency mechanism: return i686 packages * Contingency date: (not provided) == Documentation == Will be neded... == Release Notes == None yet... -- Ben Cotton He / Him / His Fedora Program Manager Red Hat TZ=America/Indiana/Indianapolis

8 13

Upcoming F37 deadlines
by Ben Cotton 12 Jul '22

12 Jul '22

As a reminder, several Fedora Linux 37 deadlines are approaching: * 2022-06-22 — Change proposals requiring infrastructure changes due * 2022-06-28 — System-Wide Change proposals and proposals requiring a mass rebuild due * 2022-07-19 — Self-Contained Change proposals due For the full schedule, see https://fedorapeople.org/groups/schedule/f-37/f-37-key-tasks.html -- Ben Cotton He / Him / His Fedora Program Manager 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… Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure

1 2

F37 proposal: Stratis 3.1.0 (Self-Contained change)
by Vipul Siddharth 11 Jul '22

11 Jul '22

https://fedoraproject.org/wiki/Changes/Stratis_3.1.0 This document represents a proposed Change. As part of the Changes process, proposals are publicly announced in order to receive community feedback. This proposal will only be implemented if approved by the Fedora Engineering Steering Committee. == Summary == Stratis 3.1.0 includes significant improvements to the management of the thin-provisioning layers, as well as a number of other user-visible enhancements and bug fixes. == 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 3.1.0 includes significant improvements to the management of the thin-provisioning layers, as well as a number of other user-visible enhancements and bug fixes. Please see this [https://stratis-storage.github.io/thin-provisioning-redesign/ post] for a detailed discussion of the thin-provisioning changes. To support these changes the Stratis CLI has been enhanced to: * allow specifying whether or not a pool may be overprovisioned on creation * allow changing whether or not a pool may be overprovisioned while it is running * allow increasing the filesystem limit for a given pool * display whether or not a pool is overprovisioned in the pool list view Users of the Stratis CLI may also observe the following changes: * A `debug` subcommand has been added to the `pool`, `filesystem`, and `blockdev` subcommands. Debug commands are not fully supported and may change or be removed at any time. * The `--redundancy` option is no longer available when creating a pool. This option had only one permitted value so specifying it never had any effect. stratisd 3.1.0 includes one additional user-visible change: * The minimum size of a Stratis filesystem is increased to 512 MiB. stratisd 3.1.0 also includes a number of internal improvements: * The size of any newly created MDV is increased to 512 MiB. * A pool's MDV is mounted in a private mount namespace and remains mounted while the pool is in operation. * Improved handling of udev events on device removal. * The usual and customary improvements to log messages. Please consult the [https://github.com/stratis-storage/stratisd/blob/master/CHANGES.txt/ stratisd] and [https://github.com/stratis-storage/stratis-cli/blob/master/CHANGES.txt/ stratis-cli] changelogs for additional information about the 3.1.0 release. == Benefit to Fedora == Users of Fedora will now benefit from Stratis 3.1.0 by: * Change the overprovisioning mode at create time or while running * User can increase the limit of filesystems per pool. The default is 100. * Stratis pool list will display whether or not a pool is overprovisioned * The MDV size is now 512MB, which allows for more filesystems to be created per pool * MDV is now in a private mount namespace, which decreases logging events and user may see faster completion times for commands that required the MDV to be mounted. == 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 == How To Test == * To see the `overprovisioning` field, list the pools `stratis pool list` overprovisioned will equal `OP`, no overprovisioning will equal `~OP` * To set the filesystem limit of a pool: `stratis pool set-fs-limit p1 200` * To see what the filesystem limit is `stratis report engine_state_report` Look for field `fs_limit` in output == User Experience == Other than the changes mentioned above the user experience will be the same. == Dependencies == No new dependencies == Contingency Plan == * Contingency mechanism: * Contingency deadline: N/A * Blocks release? No * Blocks product? No == Documentation == * This content can be viewed on Developer’s [https://stratis-storage.github.io/thin-provisioning-redesign/ blog] for Stratis 3.1 * Thin-provisioning [https://stratis-storage.github.io/thin-provisioning-redesign/ blog] * [https://github.com/stratis-storage/stratisd/blob/master/CHANGES.txt/ stratisd] changelog * [https://github.com/stratis-storage/stratis-cli/blob/master/CHANGES.txt/ stratis-cli] changelog == Release Notes == [https://stratis-storage.github.io/stratis-release-notes-3-1-0/ Stratis Release Notes] -- Vipul Siddharth He/His/Him Fedora | CentOS CI Infrastructure Team

2 1

About Fedora containers
by Alejandro Saez Morollon 11 Jul '22

11 Jul '22

Hi all! TL;DR: Is there any documentation about how to properly take care of our containers? :) --- The Go container has been outdated for a while, and I would love to update it[0], but I'm not familiar with the container process in Fedora. I checked Python3's container[1] looking for information, and I saw that the rawhide branch is not used in the same way we use it with the RPMs. Also, I saw that the s2i-base image is only available until F35. No F36 or Rawhide. And, it looks like they are only available for x86_64 platforms. So I guess the main big question is: is there any documentation or proposals I should be aware of? Is the Go container relevant? cc'ed Container SIG's mailing list; I didn't see movement in the mailing list, just in case. [0] https://src.fedoraproject.org/container/golang [1] https://src.fedoraproject.org/container/python3 Thank you very much!

10 12

Rename Airspy
by Buford T. Justice 11 Jul '22

11 Jul '22

For the regular Airspy (not HF+), why is the package called "airspyone_host"? All other distros just call it "airspy": https://pkgs.org/search/?q=airspy So it would be nice to simply do: sudo dnf install airspy airspyhf To have support in Fedora for both Airspy and Airspy HF+.

3 4

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

devel June 2022