- openSUSE Packaging

How to reload D-Bus by RPM macros?
by Alexey Svistunov 21 Nov '24

21 Nov '24

I packaging timekps-next for openSUSE in OBS, that install a D-Bus rules for group access to service. How I can reload D-Bus daemon to refresh access policies for Timekpr-nExT daemon by RPM scriptlets? DEB postinst script contain: echo "Reloading dbus daemon to refresh access policies for Timekpr-nExT daemon" systemctl reload dbus Is the anyway for done this with RPM? Now, access works only after reboot.

6 11

Re: Proposal: Update default build flags to enable frame pointers
by Neal Gompa 21 Nov '24

21 Nov '24

On Thu, Nov 21, 2024 at 12:32 AM Jiri Slaby <jslaby(a)suse.cz> wrote: > > On 18. 11. 24, 16:22, Neal Gompa wrote: > > But the storage increase is several orders of magnitude smaller than > > using DWARF data. > > Then we could use ORC. Which is a reason of NOT having framepointers in > the kernel, while being able to unwind. > Sure, do we already build our kernels with ORC? -- 真実はいつも一つ！/ Always, there's only one truth!

1 0

Proposal: Update default build flags to enable frame pointers
by Neal Gompa 21 Nov '24

21 Nov '24

Hello, I would like to change openSUSE's default build flags in rpm and rpm-config-SUSE to incorporate frame pointers (and equivalents on other architectures) to support real-time profiling and observability on SUSE distributions. In practice, this would mean essentially adopting the same tunables that exist in Fedora[1] for openSUSE to turn them on by default and to allow packages or OBS projects to selectively opt out as needed. The reasons to do so are threefold: * It is a major competitive disadvantage for us to lack the ability to do cheap real-time profiling and observability. Fedora[2], Ubuntu[3], Arch Linux[4], and AlmaLinux[5] all now do this, and thus support this capability. * The performance hit for having it vs not is insignitifcant[6]. * There are new tools in both the cloud-native and regular systems development worlds that leverage this, and openSUSE should be an enabler of those technologies. I want openSUSE to be a great place for people to develop and optimize workloads on, especially desktop ones, where most of the tooling we have for tracing and profiling is broken without frame pointers (see Sysprof and Hotspot from GNOME and KDE respectively, which both rely on frame pointers to have cheap real-time tracing for performance analysis). And given that we advertise as the "makers' choice", I think it would definitely be on-brand for us to have the capability to better support makers and shakers. For those interested in more detail about frame pointers, Brendan Gregg has a decent post about it[7]. I have also submitted a parallel request for openSUSE Leap 16 to have this feature enabled too[8]. I truly believe this would give us an even better footing with the broader community of developers and operators and make SUSE distributions very attractive for FOSS and proprietary software alike. Best regards, Neal [1]: https://src.fedoraproject.org/rpms/redhat-rpm-config/blob/93063bb396395b9a2… [2]: https://fedoraproject.org/wiki/Changes/fno-omit-frame-pointer [3]: https://ubuntu.com/blog/ubuntu-performance-engineering-with-frame-pointers-… [4]: https://gitlab.archlinux.org/archlinux/rfcs/-/blob/master/rfcs/0026-fno-omi… [5]: https://almalinux.org/blog/2024-10-22-introducing-almalinux-os-kitten/ [6]: https://www.phoronix.com/review/fedora-38-beta-benchmarks [7]: https://www.brendangregg.com/blog/2024-03-17/the-return-of-the-frame-pointe… [8]: https://code.opensuse.org/leap/features/issue/175 -- 真実はいつも一つ！/ Always, there's only one truth!

7 16

Re: Proposal: Update default build flags to enable frame pointers
by Aaron Puchert 19 Nov '24

19 Nov '24

Am 16.11.24 um 22:55 schrieb Alessio Biancalana via openSUSE Factory: > For what it's worth I think the same. Also, these days I've been using > bpftrace quite extensively and I noticed it segfaults on tumbleweed, > that's really sad. Maybe https://bugzilla.opensuse.org/show_bug.cgi?id=1233220? Should be fixed with the next snapshot, sorry for that.

1 0

Re: Proposal: Update default build flags to enable frame pointers
by Neal Gompa 18 Nov '24

18 Nov '24

On Mon, Nov 18, 2024 at 8:40 AM Richard Biener <rguenther(a)suse.de> wrote: > > On Mon, 18 Nov 2024, Bernhard M. Wiedemann via openSUSE Factory wrote: > > > On 18/11/2024 09.30, Richard Biener wrote: > > > > > I also object to enforce this for x86 32bit which is a very register > > > starved architecture (x86-64 is only slightly better in this regard). > > > > I think, we can leave i586 as is and just improve x86_64. It should have 8 > > additional general-purpose registers, so losing 1 of 15 is not as bad as > > losing 1 of 7 on i586. > > > > But I guess, most of the performance impact comes from the 3 extra > > instructions needed for save+restore of RBP. Is there an option to not use > > frame-pointers in small functions (where the performance-impact would be the > > largest) ? > > That's -momit-leaf-frame-pointer - small functions are usually leaf > (do not call other functions). > > > The "Shadow Stacks" alternative mentioned in [4] also sounds interesting. CPUs > > with this seem to be around for 6 years already... But it still needs code to > > use it. > > > > > > Not sure about other 64-bit architectures. aarch64, riscv, ppc64 - maybe > > later? > > All those RISCy architectures have enough registers to spare, or like > power and s390 have other ways to unwind for backtraces (link register). > > > > In any case - I propose shipping all packages with debug info included > > > since that greatly improves the profiling experience - even more so > > > than by enabling frame-pointers. Bandwidth and disk is cheap these > > > days. > > > > We have debuginfod these days that should allow to pull in required info on > > demand. > > I don't see that doing a whole system profile will pull that in. > > > And while desktop machines are very powerful these days, running VMs and > > containers greatly profits from small footprints. > > Code without framepointer is smaller as well. Legacy hardware with > not "tons of storage" also benefits from a few % more performance more > than your up-do-date european HW. > But the storage increase is several orders of magnitude smaller than using DWARF data. -- 真実はいつも一つ！/ Always, there's only one truth!

1 0

Packaging a npm/nodejs CLI application?
by Johannes Kastl 14 Nov '24

14 Nov '24

Dear packagers, is there a good example on how to package a nodejs / npm CLI application? Something that could be installed using "npm install -g XXX"? I know I can "prepare"/vendor the required node_modules using the service of the same name. I can provide them inside the build with the local-npm-registry call as given by the node_modules documentation. But what then? If there is no "build" step involved, do I only issue %{nodejs_install}? So, lots of questions, hence a pointer to an example package would be highly appreciated... Kind Regards, Johannes

5 9

How to properly add a Requires for "I want a desktop" (or maybe "I want a KDE Plasma desktop")?
by Johannes Kastl 03 Nov '24

03 Nov '24

Hi all, I found tail-tray, a KDE Plasma tray application for tailscale. I have a first rough package (that I need to test), but was asking myself how to properly add a dependency on "a desktop environment. If I understood this properly, this tray app should be running fine on a KDE plasma desktop. Maybe also on other desktops, if everything follows the same "tray specification". No idea. But how to add that Requires? What should I depend on? > https://build.opensuse.org/package/show/home:ojkastl_buildservice:Branch_ne… Kind Regards Johannes

3 5

Properly require one of podman or docker **with** specifying a preference for podman?
by Johannes Kastl 31 Oct '24

31 Oct '24

Hi all, while packaging apx (https://github.com/Vanilla-OS/apx) I noticed something funny with distrobox. distrobox has the following line in the spec: Requires: (%{_bindir}/podman or %{_bindir}/docker) However, on a new Tumbleweed VM or container, installing distrobox does not pull in podman, it pulls in docker. I would have assumed that the first in the list, i.e. podman, is being installed if neither is already installed. Is there a way to tell RPM to "favor" podman over docker, if neither is already installed? Kind Regards, Johannes

3 3

How to fix the "#include <filesystem>" error on 15.x / SLES15 SPX?
by Johannes Kastl 30 Oct '24

30 Oct '24

Hi all, next thing regarding tail-tray: It fails to build on 15.x (Leap and SLES15). > [ 53s] [ 18%] Building CXX object CMakeFiles/tail-tray.dir/tail-tray_autogen/mocs_compilation.cpp.o > [ 56s] [ 25%] Building CXX object CMakeFiles/tail-tray.dir/src/main.cpp.o > [ 58s] [ 31%] Building CXX object CMakeFiles/tail-tray.dir/src/MainWindow.cpp.o > [ 58s] In file included from /usr/include/qt6/QtCore/qdir.h:8:0, > [ 58s] from /usr/include/qt6/QtCore/QDir:1, > [ 58s] from /home/abuild/rpmbuild/BUILD/tail-tray-0.2.2/src/MainWindow.cpp:1: > [ 58s] /usr/include/qt6/QtCore/qfile.h:13:10: fatal error: filesystem: No such file or directory > [ 58s] #include <filesystem> > [ 58s] ^~~~~~~~~~~~ > [ 58s] compilation terminated. The few things I found on the net hinted at the gcc compiler. Richard and Alexandre also mentioned it in the SR (https://build.opensuse.org/request/show/1219105) But adding a BuildRequire for gcc14 and gcc14-c++ makes it unresolvable for Leap and still fails to build for SLES15 SPX. As this (also?) uses clang, do I need to specify a newer version of clang to get this going? > https://build.opensuse.org/package/show/home:ojkastl_buildservice:Branch_ne… Kind Regards, Johannes

1 1

New global macro default_firewall_backend
by Marcus Rückert 22 Oct '24

22 Oct '24

hi, since a while ago firewalld, the default firewall tool on TW, switched to nftables. Sadly not all tools followed that switch so now you can run into the situation that you have a perfectly configured firewalld firewall but you traffic still doesnt work, because there is a parallel iptables firewall. ARGH! to make it easier to switch over all tools without having to have a new chain of `%if 0%{?suse_version}` cascades for this, we set up the macro default_firewall_backend in TW, ALP/SLFO and SLE 15.x that should make it easy to have one spec file that can adapt to prefer one of the other depending on the distro. to take an example from the libvirt package: ``` %if 0%{?suse_version} > 1500 %define prefer_nftables 1 %define firewall_backend_priority nftables,iptables %else %define prefer_nftables 0 %define firewall_backend_priority iptables,nftables %endif ``` we can now rewrite this to: ``` %if "%{?default_firewall_backend}" == "nftables" %define prefer_nftables 1 %define firewall_backend_priority nftables,iptables %else %define prefer_nftables 0 %define firewall_backend_priority iptables,nftables %endif ``` if you only care about BuildRequires or some configure option you can of course directly use: ``` BuildRequires: %{default_firewall_backend} [snip] %build %configure --with-firewall-backend=%{default_firewall_backend} ``` hth darix -- Always remember: Never accept the world as it appears to be. Dare to see it for what it could be. The world can always use more heroes.

1 1