November 2024 - openSUSE Packaging - openSUSE Mailing Lists

New source service in Factory: obs-service-elixir_mix_deps
by alessio.biancalana＠suse.com 29 Nov '24

29 Nov '24

Hi everybody, I'd like to introduce a new package to Factory, named obs-service- elixir_mix_deps. It's a new source service meant to simplify dependency vendorization for Elixir application. I hope this will make packaging Elixir (or at least mix-based) applications a little bit easier. https://github.com/openSUSE/obs-service-elixir_mix_deps Cheers, Alessio

1 0

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

27 Nov '24

On Tue, Nov 26, 2024 at 10:55 PM Aaron Puchert <aaronpuchert(a)alice-dsl.net> wrote: > > Am 26.11.24 um 00:22 schrieb Andrii Nakryiko: > > Yes, stripped out ELF symbols are pretty annoying. But. That's a > > separate issue. And also it's possible to avoid needing them by > > capturing build ID and doing symbolization offline using build ID to > > lookup DWARF information for profiled executable/library. > > > > The important part, again, is *capturing the stack trace*. You seem > > to be more worried about symbolization, which is an entirely different > > problem. > > Isn't this entire proposal about the usability of profiling? I'm not > just worried about symbolization, but about the bigger picture. > Especially if we're profiling the entire system, we're easily talking > about gigabytes of debug info to download. > > >> With my compiler hat on, frame pointers often don't make sense. If there > >> are no VLAs and allocas, the compiler knows how large a stack frame is > >> and can simply add (for stacks that grow down) that fixed size in the > >> epilogue. The frame pointer on the stack contains no information that > >> the compiler doesn't already have. > > > > Sure, from compiler point of view. But here the concern is profilers and > > other stack trace-based tools used for observability, profiling, and > > debugging. > > My concern is not just profilers, since we're talking about a > distribution default. The point that others have made and that I've just > repeated here is that we're spending a register on a relatively > register-sparse architecture for something that's not relevant for the > program itself, but instrumentation for outside observers. And shipping > with instrumentation by default just doesn't feel right. That is not a > "real" argument, I know. > I think this is a matter of perspective. My point of view is that not having out-of-the-box instrumentation makes it hard for observability to develop further in spaces outside of the Kuberentes/Go case (where this is already default). > > Profiling the workload is much more common than you might think, and > > as it becomes more accessible (because frame pointers are there and > > tools just work out of the box), it just will be even more frequently > > used. Even if user doesn't do its own performance investigation, > > original application author can send simple perf-based (or whatnot) > > commands to run and report back data for further optimization. > > That's a bit hypothetical. In my experience, profiling is not even > terribly common among C++ developers, which is to say that most teams > have dedicated performance experts and most others rarely touch a > profiler. Most developers are profiling their own applications, after > just building them. That seems natural, after all you'll want to improve > performance and for that you'll need to touch the source and recompile. > > Application authors or package maintainers asking their users for > profiling sounds reasonable, but I haven't seen it yet. Realistically, > if users complain about a performance problem, it's probably big enough > that the overhead of DWARF and a reduced sample frequency are not an > obstacle. And even truncated stacks could be enough for the developer to > figure out the root cause. > This is something that both the GNOME and KDE communities are actively exploring. I know that the GNOME folks who maintain Sysprof have been working on making the tool better for this *exact* use-case. I'm sure folks that work on KDE are working on something similar. > For what it's worth, I've just today profiled an awfully slow clang-tidy > job and I could have attached a debugger to see what was wrong. > > > There is zero doubt that whatever we (Meta) lost due to disabling frame > > pointers has been recovered many times over through high quality and > > widely available profiling data. > > Meta has a large paid workforce though, while this is at least in parts > a community project. If SUSE wants to add FPs because they need it to > improve the distro, I don't think anybody is going to stand in their > way. But at least right now I don't think they have dedicated people for > performance, and I'm not aware of anyone regularly doing this kind of > work in the community. > > If they exist, please step up. All we have is a proposal that was copied > from Fedora and no Tumbleweed user that said "I want this and this is > how I would use it." > Most of the people who want this stuff are generally unable to figure out how to advocate for this in distributions. That's why *I* did it. Also, as a Tumbleweed user, I would hope that *I* count. I would also like to see us doing this more in KDE (and KDE upstream does qualification for Linux using openSUSE), and whole-system tracing requires the whole distribution being built for it. > Meta is also a data center operator, while SUSE mostly ships software to > my knowledge. So they don't have a big server farm where they could or > would want to do whole system profiling. Individual maintainers might do > performance work on their packages, but for that they don't need FPs as > a distro default. > On the contrary, performance bottlenecks can show up in random places. Whole-system tracing is incredibly useful with modern application middleware that can go fairly deep. > SUSE customers might want this for their deployments, but this is again > speculation. If that is actually the case, I think someone from SUSE > should tell us. My employer (a large SUSE customer I believe) would > probably not be interested so much, because we mainly run our own > binaries and use just the OS base in deployment. > As long as some of the OS is linked in your application stack, it can be useful. -- 真実はいつも一つ！/ Always, there's only one truth!

1 0

Packaging Rust applications build using the nightly toolchain
by Rein Fernhout (Levitating) 24 Nov '24

24 Nov '24

Hello, Does anyone know if there's a proper way to package rust applications (via obs) using the nightly toolchain? A lot of newer Rust features are currently still only found in the nightly release channel, and projects can typically use rust-toolchain.toml[1] file to specify what version of nightly is used. However there's no way to draw in these toolchains as a dependency in the specfile (that I am aware of). I know that other distributions like Fedora simply do not support the nightly toolchain for its packages[2]. But I feel like this is kind of a shame as so much functionality is found in nightly. My personal projects typically rely on at least a couple of nightly features. [1]: https://rust-lang.github.io/rustup/overrides.html#the-toolchain-file [2]: https://docs.fedoraproject.org/en-US/packaging-guidelines/Rust/

3 2

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

22 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!

8 17

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

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 14

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