November 2024

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 *… [View More]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! [View Less]

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 … [View More]

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 … [View More]

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 > … [View More]

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 … [View More]

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/… [View More]

3 5

Main

Development

Information

Community

Social Media

Other

openSUSE Packaging