devel June 2021

devel@lists.stg.fedoraproject.org

214 participants
345 discussions

Linux 5.13 To Allow Zstd Compressed Modules, Zstd Update Pending With Faster Performance
by Reon Beon 12 Sep '21

12 Sep '21

LINUX KERNEL -- Adding to the variety of places where the Linux kernel supports making use of Zstd compression, kernel modules moving forward can now enjoy size reductions with Zstd. Linux already supports optional Gzip and XZ compression of kernel modules while beginning with Linux 5.13 there is support added for Zstd. In user-space, KMOD 28 already supports dealing with Zstd-compressed modules. The compressed modules are suffixed .ko.zst. The support for Zstd compressed kernel modules was sent in as part of the Kbuild updates for the Linux 5.13 merge window. The Kbuild updates also include more LLVM Clang compiler handling work and other alterations, including an indicator whether the kernel was built with link-time optimizations (LTO). Separate from the Kbuild updates and likely for post-5.13, there is renewed work on getting the latest Zstd code within the kernel updated against the upstream state. These patches get the Zstd code in the kernel updated against the latest upstream code, which is much newer than the current Zstd 1.3.1 derived code in the kernel. The Zstd kernel code is now generated automatically from the upstream Zstd code. With this pending Zstd code update for the kernel, Btrfs with Zstd compression is 5~15% faster, SquashFS decompression is ~15% faster, F2FS Zstd is 3~20% faster, kernel Zstd decompression is 35% faster, Zram decompression and read is 30% faster, and initramfs Zstd compression is around 5% faster. Plus there are bug fixes and other improvements in re-basing the kernel's Zstd code-base. https://www.phoronix.com/scan.php?page=news_item&px=Linux-5.13-Zstd-Modules

6 12

Announcing fmt library soversion bump
by Vitaly Zaitsev 09 Sep '21

09 Sep '21

Hello. fmt 8.0.x update will include soversion bump from .7 to .8. All dependent packages must be rebuilt in Rawhide. -- Sincerely, Vitaly Zaitsev (vitaly(a)easycoding.org)

7 19

pdftk retired?
by Michael J Gruber 08 Sep '21

08 Sep '21

I just git a "broken dependencies" notice for a package that I maintain. The reason is that "pdftk" got retired just the other day. I may have missed a corresponding post on fedora-devel, but I think a heads up notice to maintainers of depending packages may be in order before you retire a package, as a general idea. You see, unretiring a package is so much more work than changing maintainership. As for pdftk: I see 2 failed builds for version 1.45 and none for the current version 2.02 (which probably breaks the api anyways). What are the plans? Retire pdftk completely? Start fresh with pdftk2? pdflabs, the maker of pdftk, provide binary as well as source rpms for pdftk 2.02, by the way. I might even look into packaging it but don't want to duplicate any existing efforts. Michael

17 26

Fedora 35 Change: Autoconf-2.71 (Self-Contained Change proposal)
by Ben Cotton 31 Aug '21

31 Aug '21

https://fedoraproject.org/wiki/Changes/Autoconf_271 == Summary == Autoconf upgrade from version 2.69 to the last upstream version 2.71 in Fedora. == Owner == * Name: [[User:odubaj| Ondrej Dubaj]] * Email: odubaj(a)redhat.com == Detailed Description == Upgrading autoconf from version 2.69 to version 2.71 according to new upstream release. Version 2.70 is skipped due to multiple ABI incompatibilities, where some of them were fixed in version 2.71. Years of development differ these two releases, so problems are expected. This change might easily cause fails during builds of multiple packages, as some of them still require autoconf-2.69. This step must be properly discussed with maintainers of dependent packages, which should forward this change proposal to their upstream projects. == Benefit to Fedora == Brings a stable and up-to-date version of autoconf according to upsteam release. It is expected, that in the future many upstream development teams will use autoconf-2.71 as their default builder, so Fedora will be prepared for such a step. == Scope == * Proposal owners: **Prepare autoconf-2.71 as RPM package for Fedora Rawhide **Check software that requires `autoconf` or `autoconf-2.69` and rebuild it with autoconf-2.71 **Build autoconf-2.71 to Rawhide in a side-tag (https://fedoraproject.org/wiki/Package_update_HOWTO#Creating_a_side-tag) **Rebuild depended packages with autoconf-2.71 in the side-tag **Merge the side-tag to Rawhide * Other developers: **Check if their packages can be build with autoconf-2.71 * Release engineering: [https://pagure.io/releng/issues #Releng issue number] * 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 == Problems during build can appear in multiple packages what can lead to build failure, as multiple packages require autoconf-2.69 as their upstream dependency. These problems have to be resolved before adding autoconf-2.71 into Fedora. It seems aprox. 20% of dependent packages are having problems during build, which could be caused by a problem with same pattern. == How To Test == Rebuilding your packages with autoconf-2.71 dependency in copr (https://copr.fedorainfracloud.org/coprs/odubaj/autoconf-2.70/) Mass rebuild of dependent packages in a side tag. == User Experience == Users will be able to use the newer version (2.71) of autoconf, and building packages with autoconf-2.69 won't be available, as it won't be present on the specific fedora version. This can affect 3rd partly packages, which are not part of Fedora. == Dependencies == Hundreds of packages have build dependency on autoconf, therefore it is a huge step forward for Fedora, what should be properly discussed and tested. List of dependent packages with their ability to be built with autoconf-2.71 can be found in the given copr project (https://copr.fedorainfracloud.org/coprs/odubaj/autoconf-2.70/packages/) We should also look at dependent packages of `libtool` and `automake` (other critical autotools packages), as there might be some incompatibilities with the new autoconf version. == Contingency Plan == * Contingency mechanism: moving this change to Fedora 36, if not successfully finished until Fedora 35 branching from Rawhide * Contingency deadline: Fedora 35 branching from Rawhide (2021-08-10) * Blocks release? No == Documentation == Latest autoconf documentation: https://www.gnu.org/savannah-checkouts/gnu/autoconf/manual/autoconf-2.70/in… == Release Notes == Release notes for autoconf-2.70: https://lists.gnu.org/archive/html/autotools-announce/2020-12/msg00001.html Release notes for autoconf-2.71: https://lists.gnu.org/archive/html/autotools-announce/2021-01/msg00000.html -- Ben Cotton He / Him / His Senior Program Manager, Fedora & CentOS Stream Red Hat TZ=America/Indiana/Indianapolis

24 82

rpkg-3.rc2 built into rawhide
by clime 30 Aug '21

30 Aug '21

Hello, I have built rpkg-3.rc2 (package sources: https://src.fedoraproject.org/rpms/rpkg-util) into rawhide yesterday. It should be now available for installation. It is a complete rewrite of version 2. It aims to be a tool with minimal deps that allows people to easily transform git repositories containing spec files into rpm packages. Historically, the goal of this tool was to provide a single client to all dist-git instances (i.e Fedora, CentOS, maybe something else too). This was the idea when I started to work on it still in RedHat under the lead of Miroslav Suchý. We wanted to tweak the rpkg script provided by python-rpkg lib (https://pagure.io/rpkg) for that purpose. However, that script was soon being discontinued. There I created a separate project (rpkg-util) which would be providing the script so that I can continue in my goal. Eventually, I realized that some steps rather need to be taken server-side (https://github.com/release-engineering/dist-git) for a generic client to exist so that I did and then it was about adoption of the dist-git package (which provides the unified interface) by various dist-git instances. Meanwhile, I was thinking what to do next with rpkg while being heavily influenced by Copr that I primarily worked on at that time and also by discussion on devel list about automatically generating changelog and release from git. I realized there is an opportunity to provide a solution for this in the generic dist-git client (rpkg executable) and that it was not a bad place for it. This problem was then and even today solved by basically sedding spec file with regexps which I thought is kind of hacky and that it could be useful to have a library for common substitutions anyway so that people can reuse it. So a simple spec templating language was born (https://docs.pagure.org/rpkg-util/v3/spec_templates_from_scratch.html) and also a simple library of macros (https://docs.pagure.org/rpkg-util/v3/macro_reference.html) that use git content and metadata to render spec file content or parts of it. It now allows not only to generate changelog or release but also e.g. to generate a source tarball from a git submodule placed next to the spec file. There is also the possibility for users to define their own macros and therefore customize git->rpm transform in any way. You can try this now in rawhide (`dnf install rpkg`) or also in Copr (SCM rpkg build method) but note that in Copr, there is still v2 so there might be some differences. You might also need to install python3-setuptools - that package seems to be required by python3-munch but is not being brought in automatically at the moment. You can use rpkg tool similarly to fedpkg to work with Fedora dist-git packages (except that `rpkg build` command builds in Copr and the command set is mostly trimmed-down) or you can use it to work with those git layouts that contain unpackaged sources together with spec file (or rather spec file template) or link to the upstream sources through a git submodule. Best regards clime P.S.: the project is hosted here: https://pagure.io/rpkg-util

1 1

OpenLDAP 2.5 - Fedora Release - Help Needed
by Simon Pichugin 27 Aug '21

27 Aug '21

Hi folks, my name is Simon Pichugin and I am a maintainer for OpenLDAP. Recently, OpenLDAP has released 2.5 version. It has quite a big amount of changes - https://www.openldap.org/software/release/announce.html And it includes a pretty important "Upgrading from 2.4.x" section - https://www.openldap.org/doc/admin25/guide.html#Upgrading%20from%202.4.x Also, OpenLDAP on Fedora currently has links to a versioned library: ❯ ldconfig -p | grep libldap libldap_r-2.4.so.2 (libc6,x86-64) => /lib64/libldap_r-2.4.so.2 libldap-2.4.so.2 (libc6,x86-64) => /lib64/libldap-2.4.so.2 This makes it harder to upgrade as a lot of packages depend on the versioned one (and the new package has only libldap-2.5.so.2 library. (I even filed an issue to sudo but I think it's not related to them much - https://github.com/sudo-project/sudo/issues/105 ) I came here for advice as the upgrade can be a sensitive subject for many users. What I think can be done: - Rework openldap-compat package for openldap 2.5, so it will include libldap-2.4 libs (both with and without '_r'). I am not exactly sure what's the proper way to do this (make a tarball with the compiled libldap-2.4 libs and place it to the repo - would be okay?) - Openldap 2.5 package will include only libldap-2.5.so.2 library and while testing we will tag it with some build tag so we can make sure that everything builds with it successfully. I am not sure how we can help openldap-servers package users. Should we create a change proposal that will include all of the information about the upgrade (from the OpenLDAP Upstream guide)? And hope that they will read it before the package upgrade? Is there any other way to notify them during 'dnf update'? Please, share any of your thoughts on this issue. I'll come to a decision sometime soon as we need to get OpenLDAP 2.5 at least in some state to the Fedora Rawhide so it can be properly tested. Thank you for all of your great work on our awesome Fedora! Sincerely, Simon P.S. the PR for 2.5 change was filed by a community member and we already have some discussion there - https://src.fedoraproject.org/rpms/openldap/pull-request/6

3 3

F35 Change: Memory Constraints macros for RPM (System-Wide Change proposal)
by Ben Cotton 24 Aug '21

24 Aug '21

https://fedoraproject.org/wiki/Changes/MemoryConstraintsMacros == Summary == Introduce macros, similar to openSUSE's [https://build.opensuse.org/package/show/openSUSE:Factory/memory-constraints memory-constraints]), for optionally limiting build parallelism for build-time memory-bound packages == Owner == * Name: [[User:salimma|Michel Alexandre Salim]] * Email: michel AT michel-slm DOT name == Detailed Description == Some source packages have a memory usage per build thread higher than the RAM:CPU ratio available in some of our builders. Further, this ratio can be different for different build server on different architectures. At the moment, such packages ([https://src.fedoraproject.org/rpms/ceph/blob/d7454e4e0a98208dc569553b901a49… ceph], [https://src.fedoraproject.org/rpms/chromium/blob/baaf27b384295d6288ef367dd1… chromium], [https://src.fedoraproject.org/rpms/mcrouter/blob/a0f7ecad2ccc51c4214646b082… mcrouter]) have to implement their own logic for determining the safe amount of parallelism, and redefine `_smp_build_ncpus`. When this proposal is implemented, they can instead declaratively specify the amount of RAM needed per build thread, e.g. %limit_build -m 8192 for declaring a build thread should be allocated 8GB of RAM. Since Koji supports [https://docs.pagure.org/koji/release_notes/release_notes_1.18/#system-chang… setting default values for macros], there will be a macro for the default memory limit (name TBD) that, if set, will be used to cap `_smp_build_ncpus` unless overridden by `%limit_build -m`. 0 I'm proposing to tentatively call the macro package `build-constraints-rpm-macros` to allow the possibility of adding macros for related needs e.g. [https://pagure.io/copr/copr/issue/1678 build timeouts] to the same package. == Benefit to Fedora == This change simplifies maintaining specs for software that are memory-bounded rather than CPU-bounded on our build servers It could potentially improve build reliability for these packages, by reducing the number of jobs failing because of OOM errors, and reduce the need for package maintainers to debug these failures. By keeping the user-facing API aligned with what openSUSE is using, we open up the possibility to collaborate with them and with the upstream RPM project to get such macros upstreamed into RPM itself (see [https://github.com/rpm-software-management/rpm/pull/821 previous attempt]). **note** that is not in scope for this Change. == Scope == * Proposal owners: ** Introduce new macros ** Update known packages to use the new macros, replacing their custom `_smp_build_ncpus` overrides * Other developers: ** The proposal owners might not catch all references of such logic. Individual package maintainers can try refactoring their packages using these new macros * Release engineering: [https://pagure.io/releng/issue/10188 #10188] No mass rebuild needed. Affected packages should be rebuilt using the new macro * Policies and guidelines: Packaging guideline can be updated to recommend using these macros for build-time memory-bound packages * Trademark approval: N/A (not needed for this Change) * Alignment with Objectives: N/A == Upgrade/compatibility impact == No impact, affects package building only. Also, the use of the new macros are optional. == How To Test == 1. Install `build-constraints-rpm-macros` 2. Modify spec to set `%limit_build -n AMOUNT_IN_MB` in `%build` 3. Rebuild in koji and make sure it passes on all supported architectures == User Experience == == Dependencies == This can optionally be added as dependencies of `redhat-rpm-config` and `epel-rpm-macros`, depending on how many packages need this == Contingency Plan == * Contingency mechanism: (What to do? Who will do it?) Revert changed packages to their previous way of capping the number of build jobs * Contingency deadline: beta * Blocks release? No == Documentation == Previous discussion: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org… openSUSE implementation: https://build.opensuse.org/package/show/openSUSE:Factory/memory-constraints -- Ben Cotton He / Him / His Fedora Program Manager Red Hat TZ=America/Indiana/Indianapolis

11 27

New RPM submission
by Joan Moreau 22 Aug '21

22 Aug '21

Hi I am trying to create an "offical" RPM for a package related to dovecot imap server See : https://github.com/grosjo/fts-xapian/issues/82 How one should proceed to hae a RPM referenced in Fedora repositories ? Thank you JM

23 79

The Death of Java (packages)
by Fabio Valentini 18 Aug '21

18 Aug '21

Hi everybody, Long story short, I can no longer in good conscience be the primary maintainer of (most) Java packages in Fedora. I am not using any of them, I don't like Java or any other languages targeting the JVM, and don't get me started on the horrid Java ecosystem. Recently I've been spending 40-60 hours per week at my desk, and I just don't have the capacity to feel guilty for not taking care of those packages any longer. New versions and even security issues have been piling up for months (just look at the SIG's taiga board). Other people tried to step up for the "new" Java SIG (@java-maint-sig), but other than myself, nobody has been triaging new bugs in Java packages. Java package maintainers from Red Hat have been exceptionally unhelpful, and have not substantially contributed to Java packages in Fedora in years. Even the Modules that were heralded as "the solution" have stagnated. On the other hand, Mat Booth and two members of the DogTag PKI team have been really helpful, but Mat is busy fighting the Eclipse dumpster fire most of the time, and the other two have since both left Red Hat for greener pastures. And since I see no way for the situation to improve, there's only one honest thing left that I can do: I will orphan all Java packages I am the main admin of, later today. Since this is the majority of remaining Java software in Fedora (~180 packages), I expect at a decent amount of dependent packages will be affected. However, given the utter lack of Java package maintainers and the pitiful state of the overall language ecosystem, I would strongly urge affected maintainers to drop dependencies on Java, if at all possible. Maybe other members of the java-maint-sig will pick up the orphaned packages, if they're still here. Or maybe it's finally time to let Java packages die. Nobody seems to care either way. Fabio

26 47

Dynamic preemption support in Linux 5.12 kernel
by Artem Tim 17 Aug '21

17 Aug '21

Hello. Upcoming 5.12 allow building with dynamic preemption support which allows changing mode at boot/run-time so finally no need to rebuild or make alternative kernel build anymore[1]. Responsive system is a must have for gaming and good desktop experience overall, not only for professional audio. For example difference in input mouse lag is like day and night with PREEMPT mode. Maybe on cheap mouse this is hard to notice but on 500-1000Hz mouse really easy. You can test this yourself with experimental kernel build on COPR[2]. Some Linux distros[3] already using PREEMPT mode by default for a decent period of time. Fedora kernel build with CONFIG_PREEMPT_VOLUNTARY but this is not enough for desktop use case. Please provide full PREEMPT mode by default in 5.12 kernel for desktop variants. With 5.12 it is possible for user to change it without efforts if they need this. RT kernel FAQ: https://rt.wiki.kernel.org/index.php/Frequently_Asked_Questions [1]: http://lkml.iu.edu/hypermail/linux/kernel/2102.2/01311.html [2]: https://copr.fedorainfracloud.org/coprs/atim/kernel-futex/ [3]: https://wiki.archlinux.org/index.php/Professional_audio#Realtime_kernel

7 11

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 2021