devel November 2024

devel@lists.fedoraproject.org

153 participants
178 discussions

Applying code layout optimization to postgresql16 RPMs in Fedora 41 gave a 3%-6% improvement in IPC
by William Cohen 09 Dec '24

09 Dec '24

Hi All, There is always a desire to make code run faster and use less memory. Code layout optimization is one technique used accomplish those goals by locating strongly connected functions together to reduce the number of memory pages containing actively executing code and to reduce the amount of time that processors use to adjust mapping of logical to physical memory addresses. With the addition of binutils-2.43 in Fedora 41 it is possible to do profile guided optimization (PGO) code layout with the sediment (*) tool. As a testcase I collected profiling data on an Intel machine, created a callgraph from the profiling data, built postgresql16 RPMs with and without optimizations, and benchmarked the RPMs. I got between a 3% and 6% improvment in IPC (instructions per cycle) for pgbench running in various environments (bare metal x86_64, x86_64 guest VM, and aarch64), enough of an improvement that people might be interested. There is a newer version of sediment for Fedora 41 (**) currently in Bodhi testing that include more details on this postgresql pgbench experiment in the documentation and the upstream sediment (*) also has that same information in https://github.com/wcohen/sediment/blob/master/docs/pop.rst. Sediment has been designed to work with the RPM build process. Currently, one needs to use modified RPM macros. These can be created quickly by writing the output of the sediment make_sediment_rpmmacros command into ~/.rpmmacros. One will also need to define set the pgo macro to 1 for the rpmbuild process. The rpm spec file has minimal modifications. It has the callgraph files stored as a source file and a defines the global call_graph to the source file that holds the call graph. The approach that sediment uses differs significantly from other code layout optimization tools such as Intel Thin Layout optimizer (+), Google propeller (++), and Meta Bolt (+++). These tools make it difficult to apply the data collected from one architecture to other architectures. Also the data collected is mapped back to line numbers which will make the data become stale quite quickly as patches or rebases are done on the software. Sediment uses the function names which change less frequently in source code and allow the data from one run to be still be used for later versions of the software across multiple architectures. I would like to see people give sediment a try in Fedora and see what additional performance improvements on application code can be obtained. I would also like to get feedback on how to further improve sediment. -Will Cohen (*) https://github.com/wcohen/sediment (**) https://bodhi.fedoraproject.org/updates/FEDORA-2024-7f5ea0f053 (+) https://github.com/intel/thin-layout-optimizer/commits/main/ (++) https://github.com/google/llvm-propeller (+++) https://github.com/llvm/llvm-project/blob/main/bolt/docs/OptimizingLinux.md

3 6

soname bump: live555 2024.03.08 coming to rawhide
by Dominik 'Rathann' Mierzejewski 09 Dec '24

09 Dec '24

Hello! Latest live555-2024.03.08 comes with an SONAME bump from 107 to 112. The only consumer seems to be vlc, which I'll rebuild in a side-tag (f41-build-side-87311) and submit together as an update. This is rawhide only. Regards, Dominik -- Fedora https://fedoraproject.org Deep in the human unconscious is a pervasive need for a logical universe that makes sense. But the real universe is always one step beyond logic. -- from "The Sayings of Muad'Dib" by the Princess Irulan

1 1

Tcl/Tk 9.0.0 rebase
by Jaroslav Škarvada 08 Dec '24

08 Dec '24

Hi, I would like to rebase Tcl/Tk in rawhide (f42) to the latest stable 9.0.0 release. Unfortunately, there are several incompatibilities [1] and several applications will require porting. I will create side-tag and bugs for individual packages. For the preliminary testing there are Tcl/Tk SRPMs available [2]. List of packages that tailed to compile with Tcl/Tk 9.0.0 follows: blt brltty cgnslib classified-ads deal eggdrop emacspeak expect gcl gtkwave hamlib hfsutils hping3 iaxclient ibutils insight irsim itcl itk iwidgets Lmod magic memchan nbdkit netgen-mesher ngspice ocaml-lablgl ocaml-labltk ocaml-ocamlnet ogdi opencascade openmsx owfs pidgin postgresql postgresql16 python* [*1] sqlite sqlite2 svxlink tcl-tclxml uudeview znc thanks & regards Jaroslav [1] https://www.tcl-lang.org/software/tcltk/9.0.html [2] https://jskarvad.fedorapeople.org/tcltk9/ [*1] tried versions 2.7 - 3.13

8 30

DOTNET 8.xx on fedora who is using it? does it work for you?
by André Verwijs 05 Dec '24

05 Dec '24

DOTNET 8.xx on fedora who is using it? does it work for you? question: witch repo should i use for dotnet 8 (if no packages are missing, like <b>“dotnet-runtime-debs-8.0”</b> ) thanks

5 4

Unresponsive maintainer for Fedora-EPEL python-django3
by Marco Benatto 03 Dec '24

03 Dec '24

Hello all, We recently noticed there's a couple of PRs opened to fix vulnerabilities in EPEL8 python-django3 with no response from the maintainer (CC'ed). This is an important update as it fixes 4 different CVEs. https://src.fedoraproject.org/rpms/python-django3/pull-request/2 I have raised a bugzilla bug asking for contact according https://docs.fedoraproject.org/en-US/fesco/Policy_for_nonresponsive_package… https://bugzilla.redhat.com/show_bug.cgi?id=2328973 may i please have your help in contacting the maintainer? Thanks, Marco Benatto Red Hat Product Security secalert(a)redhat.com for urgent response

5 6

subscription-manager orphaned
by Maxwell G 03 Dec '24

03 Dec '24

7 9

Plans for OCaml 5.2/5.3
by Richard W.M. Jones 03 Dec '24

03 Dec '24

Just a heads up for OCaml. We currently have OCaml 5.2.0 in Fedora 41 & Rawhide. OCaml 5.3.0 is expected to be released at the "end of November or beginning of December"[1], so it would make sense to move straight to this version in Rawhide after that happens. [1] https://ocaml.org/changelog/2024-10-31-ocaml-5.3.0.beta1 Release notes for 5.3.0: https://github.com/ocaml/ocaml/blob/5.3/Changes OCaml 5.2.1 is "a collection of safe but import[ant] runtime time bug fixes backported from the 5.3 branch of OCaml"[2]. It was released a couple of days ago. If I have the energy I'll update Fedora 41 to this version, but only after 5.3.0 is released first (as otherwise I'll need to do Rawhide twice to avoid the version in Rawhide being lower). [2] https://ocaml.org/changelog/2024-11-18-ocaml-5.2.1 Note that updating an OCaml version involves recompiling all the related packages, about 200 of them. Also there's a new version of LWT, so it makes sense to update that at the same time: https://bugzilla.redhat.com/show_bug.cgi?id=2326159 Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com Fedora Windows cross-compiler. Compile Windows programs, test, and build Windows installers. Over 100 libraries supported. http://fedoraproject.org/wiki/MinGW

1 1

small problem with vendored deps in rust packages
by Zbigniew Jędrzejewski-Szmek 02 Dec '24

02 Dec '24

Hi Yaakov, I was looking to update rust-zram-generator and I noticed the following: commit 820c5ec20c000e2f0ef57d19970311901d598cf1 Author: Yaakov Selkowitz <yselkowi(a)redhat.com> Date: Mon May 15 20:13:52 2023 -0400 Use vendored dependency in RHEL builds This introduces and rpm macro logic bug which causes the vendored dependencies to be unpacked unconditionally. I guess that most likely the same pattern was used in other packages. IIUC, the unpacked vendor/ dir is actually not used for anything. But it seems wasteful and confusing to unpack the second sources. It'd be nice to fix this everywhere the same pattern was used. The problem is this: %autosetup -n %{crate}-%{version_no_tilde} -p1 %{?bundled_rust_deps:-a2} %{?bundled_rust_deps:…} effectively checks if %bundled_rust_deps is defined. It always is, to either 0 or 1. Zbyszek

4 10

Building mixxx for ppc64le (f40)
by Luis Correia 02 Dec '24

02 Dec '24

Hi, I was running the build processes for Mixxx 2.4.2 release on RPMFusion It ran fine, except in F40 for ppc64le, in where some dependency doesn't exist in Everything. I am not the original maintainer and as such, didn't create the spec file, or had this issue in the few releases I actually managed to do. Humbly asking for assistance, as I'm out of my depth here https://koji.rpmfusion.org/koji/taskinfo?taskID=661020 https://koji.rpmfusion.org/kojifiles/work/tasks/1023/661023/root.log Thanks, Luis

3 6

libarrow (Apache Arrow) SONAME bump in rawhide — third notice
by Kaleb Keithley 02 Dec '24

02 Dec '24

Arrow packages include libarrow*.rpm parquet*.rpm (libparquet*), and python-pyarrow*.rpm Updating to Arrow 18.0.0 side-tag f42-build-side-100844 has been created for rebuilding the dependent packages: * ceph (I am the maintainer) * gdal (maintainer notified previously) * groonga (etc.) * myst-nb (etc.) * pcp (etc.) * root (etc.) * python-{dask,dask-expr,distributed,formulaic,fsspec,geopandas,pandas,papermill,pyogrio} (maintainers not notified) Are there any others? Richard W.M. Jones built many (or all ?) of the dependent packages listed above. (Thanks Richard.) If I hear nothing I plan to merge the side tag to rawhide on Monday AM EST. -- Kaleb

2 1

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 November 2024