Why we can’t install debug symbols (e.g debug symbols for Plasma/KDE apps) on Manjaro ? while it’s possible on Ubuntu based distributions ?
Debian based Distributions enable debug symbols at compile time of applications.
Arch based Distributions don’t do that. The reason is, that enabling debugging symbols slows down applications. It can debated if this is still a reason, because CPU are usually quite fast and the impact of debugging symbols is not that big. But it also makes packages bigger or there would be the need of spilt packages, which is not liked by Arch maintainer.
You can recompile a package with debug symbols enabled. Keep in mind that you might need to recompile some libraries too.
5 Likes
This is nonsense. Technology has been in existence for decades to build separate symbol packages that don’t weigh down the regular runtime packages. Arch’s decision not to employ this technology is THE most stupid and lazy decision they ever made. I am here right now specifically because I am looking for an Arch-based distro that fixes this madness.
The process of building debug packages in Arch is absurdly, ridiculously heavy. Each PKGBUILDs of every KDE program separately downloads THE WHOLE COMPLETE TOTAL ENTIRETY OF THE KDE SOURCE CODE ARCHIVE, even if you only want to build one application. The whole ordeal takes hours if everyhing goes smoothly, or days if there are hiccups. Literally no one does that just to be able to send useful traces, ever. The reality is that people simply live with the inability to upload traces, and this whole “getting traces” Wiki page exists solely as a monument to Arch Way zealotry. One long term consequence is that crashes triggered by conditions specific to Arch simply never get fixed, and this rot accumulates over the years, making the whole KDE experience increasingly crashy.
2 Likes
Is it able for Manjaro team to do
Alternatively you can put the debug information in a separate package by enabling both
debugandstrip, debug symbols will then be stripped from the main package and placed, together with source files to aid in stepping through the debugger, in a separatefoo-debugpackage.
to provide debug symbols in separate package to be able to report bugs, for example of current issues of
Ark 7zip and zip compression not working properly and crashing Dolphin
and
Got a black screen with mouse cursor only after switching (on SDDM screen) a user session type between X11 and Wayland
to make user be able to report bugs?
Cause as the Guidelines and HOWTOs/Debugging/How to create useful crash reports - KDE Community Wiki tells:
Backtraces
Backtraces are essential. They may look meaningless to you, but they might actually contain a wealth of useful information. A backtrace describes which functions were called prior to the crash, so that developers may track down in which function the mess started. Having good backtraces has a downside: libraries and executables occupy much more disk space than their optimized counter parts. That’s the reason why many distros choose to install stripped files which result in useless backtraces.
Otherwise to leave each user an hours to compile target package, then their dependencies stuff, than core application which crashes (like Ark app triggers plasmashell crash) and then to fix possible errors during making packages.
May be separate debug symbols can be as solution or should we have nothing to do with upstream bug reports cause w/o debugging symbols
result in useless backtraces
and cause of
Backtraces are essential
we can’t submit useful bug reports.
Does the separate debug package symbols decision will lead Manjaro OS powered PCs to run as fast as always, but in the same being able to restart an app with applied debug symbols to reproduce the issue and to make good useful bug report to upstream developers?
May be a current technologies, tools, methods already made that possibility easier?
Thanks!
Arch decided not to ship debug symbols, period! We can only follow upstream as otherwise we would need to compile all packages.
As soon as we would do that:
- we would be independent from Arch
- we might have a different release cycle
- AUR support will be dropped
- we might ditch desktop environments our developers might not use
- less apps might be found in our repository and we might suggest flatpaks and Snaps to reduce our efforts
However, since we work closely with KDE we enabled debug symbols for kde-unstable packages on a separate server for KDE developers to debug the software we work together with them on mobile devices.
So if you want to report bugs properly to kde most likely don’t use an Arch based distro.
10 Likes
I guess arch just changed their minds about shipping debug information for their software. Now Manjaro can follow arch in shipping debug packages 
3 Likes
We have to see on how we can get that done on our end.
3 Likes
Many KDE reported bugs from Manjaro users are blocked due to lack of debug symbols, but for now there is hope with https://debuginfod.archlinux.org, the problem is that repo has only latest unstable packages (5.24), is there any alternative for stable branch ?
The repo contains the debug symbols for the active packages released by Archlinux.
Since Archlinux is ahead of Manjaro with at least 1 week the if a new version of glibc is released by Archlinux valgrind will not work on Manjaro until glibc is updated as well.
What would be the correct solution for Manjaro since this causes a major issue in debugging at least once a month?
2 Likes
Well, we might come up with some solution but that won’t be soon. Our unstable branch is mostly on pair with Arch but people will use more our stable branch, on which we even have 5.24 plasma series in our overlay. So if we ship debug symbols we have to have a similar approach as we have with our current binary repos to have debug packages per branch matching our packages.
On a site-note: for ARM we have blacklisted all debug packages as ARM is shipping them on the regular mirrors, which will kick out most of our own mirrors if we would add those large packages.