FS#10975 - Add support for separated packages with debug symbols to makepkg (patch included)

Attached to Project: Pacman
Opened by Jan M. (funkyou) - Monday, 21 July 2008, 22:39 GMT
Last edited by Allan McRae (Allan) - Tuesday, 27 November 2012, 06:09 GMT
Task Type Feature Request
Category makepkg
Status Closed
Assigned To Allan McRae (Allan)
Architecture All
Severity Low
Priority Normal
Reported Version 3.1.4
Due in Version 4.1.0
Due Date Undecided
Percent Complete 100%
Votes 107
Private No

Details

Hi there,

today i sat down and wrote another patch for makepkg, this time to create separate packages with debug symbols automatically... As Arch is a distro that "keeps it upstream" it should be an easy thing to create backtraces and report bugs, at least theoretically :) But then all the nice debug symbols are stripped by default which makes it a bit of a hassle to get some proper debug info, especially if you must rebuild a whole set of packages, as its sometimes not just done with rebuilding one package with debug info... For example, if you want to have some kde-related stuff with debug info, you need also to rebuild at least kdelibs and kdebase (and maybe even Qt) ...

As this is just too much hassle and not optimal(tm), i just thought "this must be stopped" and created this patch :)



HOW ITS DONE (the theory):
--------------------------

"GDB allows you to put a program's debugging information in a file separate from the executable itself, in a way that allows GDB to find and load the debugging information automatically. Since debugging information can be very large--sometimes larger than the executable code itself, some systems distribute debugging information for their executables in separate files, which users can install only when they need to debug a problem."

Ok, that sounds nice, but how do we do it?

Its easy... Lets take an executable file like "ls" and compile it with debug info... Then we use objcopy to move only the debug symbols into a new file. This happens with "objcopy --only-keep-debug $file $file.debug" ... This creates "$file.debug" which holds all debugging symbols...

The second step is to strip the file as we already do in arch, by using "strip" for executables and "strip --strip-debug" for shared libraries, because we have now the symbols in another file and dont need them anymore...

As the last step, gdb must know if a file has its debug symbols in a separated file... For this we use objcopy again on the file and add the "debug link flag" to it which points to the file(name): "objcopy --add-gnu-debuglink=$file.debug $file"

(As a sidenote: You cant use a full path with the "--add-gnu-debuglink" parameter, but just the name of the file _and_ the debug file must be available for objcopy. This means that you must create the .debug file in the same path as the executable/library and move the .debug file elsewhere afterwards, because otherwise it will not work later...)

Finally, when using gdb on such files, it looks into the following directories for .debug files (example for "ls"):

`/bin/ls.debug'
`/bin/.debug/ls.debug'
`/usr/lib/debug/bin/ls.debug'



MAKEPKG IMPLEMENTATION:
-----------------------

The implementation in makepkg is pretty easy and lightweight... At first there is another option called "splitdebug" in makepkg.conf which can be used only together with the "strip" option, so both need to be enabled to create debug packages...

Then we just need another directory in $startdir, where the .debug files will be placed. In the patched version this directory is called $startdir/dbg.

To create the .debug files, i have modified the strip stuff in tidy_install() and added another function for creating the debug package called create_debug_package()...

create_debug_package() is a stripped-down copy of create_package(), with lesser stuff added to the .PKGINFO (like groups or the install file, we dont need that for debug symbols) and it also adds the -debug suffix to the package name automatically...

Before calling create_package(), there are two new checks for the "strip" and "splitdebug" options. If both are enabled, create_debug_package() will be called after create_package() to package the generated debug symbol files...

The .debug files are placed into the same directory as their executables. In my opionion, this is the easiest and KISSest way to deal with it... Other distros use "/usr/lib/debug/THE/FULL/PREFIX/$FILE" for that, but i think thats just overkill...



HOW TO TEST IT:
---------------

Just use the attached makepkg, enable the "strip" option in makepkg.conf and also add "splitdebug" to the options array... Then run makepkg on any package you like... This should create 2 packages: $package and $package-debug...

To test it with gdb: Install both packages, run gdb, open a executable file from the package inside gdb ("file /path/file") and it should load and find the debug symbols automatically...



DISADVANTAGES:
--------------

So far none, at least for me :) The implementation in tidy_install() could be a bit cleaner, but i dont know how to do it and would like to see some feedback about this - especially on the way how i handle the "objcopy --add-gnu-debuglink" stuff, as it needs to be done in the same directory as the file + file.debug...

The size of the -debug packages could be an issue. It varies from package to package, from about 5% (for kdesvn) to over 70% (for amarok-base) of the original package...

Also notice that will not decrease performance in any way, as the binaries are still stripped like before...



Please test this stuff and give me some feedback, thanks!

Greetings

Jan


This task depends upon

Closed by  Allan McRae (Allan)
Tuesday, 27 November 2012, 06:09 GMT
Reason for closing:  Implemented
Additional comments about closing:  In git - many patches culminating in 254329f6
Comment by Allan McRae (Allan) - Tuesday, 22 July 2008, 14:35 GMT
Wow, that is a long bug report! I quite like this idea for inclusion into makepkg, although I think that having debug packages in the Arch repos seems unlikely...

A few comments:

1) I think that a flag for makepkg be better than specifying an option in the PKGBUILD.

2) If we stick with using an option, we could have splitdbg/dbgpkg or whatever the option gets called imply strip. In fact, either way, a single check early on the these options/flag don't conflict would save a lot of multiple testing afterward.

3) I like using /usr/lib/debug much more than having debug files along side their counterparts in the filesystem. It just seems cleaner. Also, that allows configuring the path (as you can changing it in gdb). e.g think about what setting the path to "/" would achieve. :)
Comment by Aaron Griffin (phrakture) - Tuesday, 22 July 2008, 21:10 GMT
Oh man, you weren't kidding! Long bug report is long

My only qualm is... this seems like something that can be more generalized with all the different "split packages" ideas floating around. Perhaps integration with some of that would make this a much cooler idea.
Comment by Jan M. (funkyou) - Tuesday, 22 July 2008, 21:30 GMT
Hehe, yes its a long report :-) I just wanted to provide all details about this stuff, as you cannot find that much about it on the interwebs...

Allan, thanks for your suggestions, they are quite legit for me and definitely an improvement. I will rework the patch when i have time (could take a bit) and post an updated version here...

Aaron, this patch has nothing to do with splitting packages. It does not even split anything but just creates a second package containing all the symbols. Just take a look at the diff, its pretty self-explaining...

When i am on it, i will also combine it with our splitpkg patch from KDEmod, that should be an easy job... But again, this patch has nothing to do with splitting packages :-)
Comment by Aaron Griffin (phrakture) - Tuesday, 22 July 2008, 21:32 GMT
Yeah, I'm just saying that if you have code to make a second package at the same time, perhaps that can be generalized a bit so that we can re-purpose some of the code for split packages.
Comment by Jan M. (funkyou) - Tuesday, 22 July 2008, 21:36 GMT
Ok, now i got it :-) I'll take a look at that too ...
Comment by Allan McRae (Allan) - Tuesday, 22 July 2008, 22:46 GMT
I'm running with the whole split packages idea once 3.2 is out the door. So you may want to hold up on reimplementing the patch to combine with the KDEmod splitting because that isn't necessarily how it is going to happen...
Comment by Dan McGee (toofishes) - Thursday, 24 July 2008, 02:26 GMT
I'll chime in and say I kind of like this, especially since it isn't all that invasive as opposed to most other splitting packages patches I've seen. It would also be helpful for things like solving  FS#10976 .

With that said, I think Allan is going to round up the challengers post-3.2 and try to get something we can mostly all agree on.
Comment by Jan M. (funkyou) - Thursday, 24 July 2008, 11:42 GMT
Ok, here is version 2 ...

- debug symbols are now placed in /usr/lib/debug
- there is a new flag (-t|--splitdbg) to enable -debug packages
- the makepkg.conf option got renamed to "splitdbg". Using "dbgpkg" for that was just too prone for typos ;)
- you can now freely combine/use the flag and the "strip" and "splitdbg" options in makepkg.conf, it will always work as intended
- there is now a check if any .debug files have been created. This is important for stuff like wallpaper packages or so which contain no binaries. The former version just created an empty -debug package in that case

Its still hackish, as i am not a bash pro at all, but it works fine for me so far. If you have any suggestions, i would be happy to read them...

About splitting packages: I have also combined the patch with our splitpkg stuff. I know that this is just one of many ways to split pkgs, but i wanted to have a working solution _now_, as i intend to use that on the KDEmod packages... If there is any interest in these patches, they are currently located here: http://www.kdemod.ath.cx/svn/work/kde41-move-it-to-usr/_buildsystem/patches/
Comment by Nagy Gabor (combo) - Sunday, 27 July 2008, 17:27 GMT
Thx a lot for the long report: I learned much from there;-)

Basically I like the idea (but I didn't check your implementation).
Comment by Jan M. (funkyou) - Friday, 23 January 2009, 17:49 GMT
Updated patch for makepkg with split support.
So far i have tested split & "normal" pkgs and repackaging. It works fine.

Again: this is more a quick hack that basically works and does the job for me, and not a real proper implementation ;)
Comment by Michael Witten (mfwitten) - Saturday, 15 August 2009, 10:01 GMT
This looks like it would be extremely useful. What's holding this back?

One of the biggest pains in the ass is not having easy access to debug symbols.
Comment by Allan McRae (Allan) - Saturday, 15 August 2009, 12:44 GMT
Now split package support has been added, I would like to make this use a similar package strategy to the packaging of the split debug packages.
Comment by mutlu inek (mutlu_inek) - Saturday, 15 August 2009, 20:54 GMT
That would be wonderful. The biggest lack on Arch was always debug information. I am sure many users would be very thankful.
Comment by Martin Sandsmark (sandsmark) - Tuesday, 12 January 2010, 02:01 GMT
Any progress? Debugging symbols is extremely nice to have, especially for pre-releases of KDE and whatnot.

What is holding this up? (I would like to help, if there is anything I can do.)
Comment by Jan M. (funkyou) - Tuesday, 12 January 2010, 07:44 GMT
I can do another patch against the latest makepkg, if that helps :) But there werent many changes, just some very small improvements.
Comment by Gaurish Sharma (gary4gar) - Tuesday, 16 March 2010, 12:42 GMT
Due to Arch's rolling release model, we are the first ones who encounter bugs in latest releases.its responsible thing that we should able users to generate back traces with proper debug info without having them recompile the whole. so it would help upstream to fix bugs and increase the overall stability of packages.

I would strongly request, devs to rethink the current policy of not carring -debug packages in repos. Because its "Anti-upstream".
Comment by Allan McRae (Allan) - Tuesday, 16 March 2010, 12:46 GMT
Requesting gets you nowhere. Refactoring the above patch so that it does not duplicate so much code might.
Comment by Gaurish Sharma (gary4gar) - Tuesday, 16 March 2010, 13:16 GMT
I wouldn't had requested, I was capable of implementing it myself. I am not a coder
Comment by Karol Błażewicz (karol) - Tuesday, 27 April 2010, 00:56 GMT
Status? Apart from the loss of OP that is.
Comment by aze489 (aze489) - Thursday, 13 May 2010, 13:07 GMT
Such a feature would really be usefull.
Comment by Pete (tam1138) - Friday, 02 July 2010, 19:21 GMT
I poked around in makepkg, and my impression of split packages is that they don't provide a convenient way to do this. In my opinion, the option to create a debug package should be as easy to enable as possible (eg, "makepkg -d" or something like that), but it looks like a split package would have to be added to every PKGBUILD to enable the production of debugging information. Please correct me if I'm wrong, or point me in the right direction, or argue my conclusion. =) I'm happy to do the work for this, but I want to make sure I do it so that it's as easy as possible to integrate.
Comment by Rémy Oudompheng (remyoudompheng) - Friday, 23 July 2010, 16:34 GMT
What about the following patch? I refactored Jan's patch following Allan's suggestion, and tried it on a regular package, as well as a split package.
Comment by Rémy Oudompheng (remyoudompheng) - Friday, 23 July 2010, 17:03 GMT
Small update because I forget to clean $dbgdir when building the package, and debug files went in the wrong place.
Comment by Allan McRae (Allan) - Friday, 23 July 2010, 23:24 GMT
Does this work with split packages? With split packages we "backup_package_variables" and then when spitting debug symbols you "backup_package_variables" over the top of the old stores.
Comment by Rémy Oudompheng (remyoudompheng) - Saturday, 24 July 2010, 07:52 GMT
Actually I don't think I do: I use backup_package_variables in the non-split case, and in the split package case, I mess up with the variables (without backup) just before the line where they are usually restored.
Comment by Allan McRae (Allan) - Saturday, 24 July 2010, 10:05 GMT
Ah ... so it does. Other minor comments:

+ depends=($pkgname)
should be depends=($pkgname-$pkgver-$pkgrel)

+ provides=${provides/%/-dbg}
+ conflicts=${conflicts/%/-dbg}
These are not needed in my opinion.
Comment by Rémy Oudompheng (remyoudompheng) - Tuesday, 27 July 2010, 10:29 GMT
I agree. There should also be
replaces=()

There is an obvious problem with this when dealing with packages with hard linked binaries (git for example). A solution would be to not generate debug packages for these, or to add a check in order to not strip an already stripped binary.

Suppose a package has /usr/bin/prog1 and /usr/bin/prog2 which are the same inode. Then prog1 will be stripped, giving
/usr/lib/debug/usr/bin/prog1.debug
and the .gnu_debuglink section of prog1 (hence prog2) will contain "prog1.debug".

Then prog2 will not be stripped, as it already contains a .gnu_debuglink section. But if gdb is used on prog2, since it is .gnu_debuglink-ed to prog1.debug, it will indeed find the debug symbols in /usr/lib/debug/usr/bin/prog1.debug

I suspect it will not work if hardlinked files are not in the same directory. Gentoo has a much more robust way to deal with this, but given that it will be seldom needed, it may be best to "Keep It Simple".

Here is a new patch for makepkg, which I tested with the git package. Note that git-fetch and git-merge-ours are the same file.

% SPLIT_DBG=1 makepkg.new -f
% sudo pacman -U git-1.7.1.1-1-i686.pkg.tar.gz git-dbg-1.7.1.1-1-i686.pkg.tar.gz
% gdb /usr/lib/git-core/git-fetch
GNU gdb (GDB) 7.1
Copyright (C) 2010 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "i686-pc-linux-gnu".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
Reading symbols from /usr/lib/git-core/git-fetch...Reading symbols from /usr/lib/debug/usr/lib/git-core/git-merge-ours.debug...done.
done.
(gdb) quit
Comment by Allan McRae (Allan) - Wednesday, 28 July 2010, 03:01 GMT
The patch is looking good. I am busy at the moment but will do a full review later.

For the hard link issue, check how we handle compressing man pages in makepkg. That might give you a hint on how to handle them.
Comment by Rémy Oudompheng (remyoudompheng) - Wednesday, 28 July 2010, 12:36 GMT
Issues arising here seem different from the case of man pages: for man pages we need a file with the right name to be accessible. But if I am not mistaken, the file containing the debug symbols has no reason to bear the right name: it should bear the name that is written in the .gnu_debuglink info.

For example, if /bin/prog and /usr/bin/prog2 are hard linked, and we create /usr/lib/debug/bin/prog.debug, then this should be hardlinked to /usr/lib/debug/usr/bin/prog.debug (and not prog2.debug). Of course, another name prog2.debug could be created for user-friendliness, but it would not be used. The only package I have here using off-directory hardlinks is glibc, which has /usr/bin/getconf and /usr/lib/getconf/*, and its PKGBUILD manually strips files, I don't have a suitable PKGBUILD for testing this case (of course I could forge one...).
Comment by Rémy Oudompheng (remyoudompheng) - Wednesday, 28 July 2010, 13:37 GMT
I forgot
backup=()
in the create_dbgpackage() function.
Comment by Rémy Oudompheng (remyoudompheng) - Thursday, 29 July 2010, 11:28 GMT
Here is a testcase for cross-directory hardlinks. I noticed that if a package creates two names for a file, say /bin/a and /usr/bin/b, and you try to install it with pacman, on a system with separate / and /usr partitions, then only one of the files is installed. Is it a bug/feature of pacman, or should there be some symlink installed instead ?
   PKGBUILD (0.5 KiB)
Comment by Allan McRae (Allan) - Thursday, 29 July 2010, 11:40 GMT
Please file a separate bug about the hardlink across partitions issue. That is a bug.
Comment by Vitaliy Gorbunov (vit.gorbunov) - Sunday, 30 January 2011, 18:33 GMT
I added forgotten backup=(), applied this patch to scripts/makepkg.sh.in and rebuild pacman package using abs. I build some packages with -t key and all seems to work fine. Could anyone tell me why there is no activity here so long?
Comment by Divan Santana (divansantana) - Monday, 04 April 2011, 20:32 GMT
I was wondering if one couldn't look at what Chakra have done to their makepkg to assist with this bug.
They seem to provide KDE debug packages as an option.
http://chakra-project.org/news/index.php?/archives/112-KDE-Debug-Packages.-Its-time-to-contribute-to-KDE-!.html
Comment by Allan McRae (Allan) - Tuesday, 05 April 2011, 01:54 GMT
The patch already provided in this bug is from the Chakra guys.

I really need to sit down and do some makepkg patch reviewing...
Comment by Vitaliy Gorbunov (vit.gorbunov) - Saturday, 06 August 2011, 07:18 GMT
Rebased against pacman master.
Comment by Vitaliy Gorbunov (vit.gorbunov) - Wednesday, 10 August 2011, 17:06 GMT
I rewrite patch from Remy Oudompheng in order to use generic split packaging mechanism.
The main idea is that debug packages will be added to pkgname array and for each of it package_<name>-dbg function will be created. So it treated like usual split packages.
Tested on split and non-split packages. All seems to work fine.
Comment by Divan Santana (divansantana) - Tuesday, 11 October 2011, 20:13 GMT
Hi Allan/Others,

Is the latest patch submitted by Vitaliy good enough to be implemented?
It would be nice to have this so we could have split debuging packages.
Comment by Vitaliy Gorbunov (vit.gorbunov) - Tuesday, 11 October 2011, 20:43 GMT
Hi Divan.

You can follow discussion about this patch here http://mailman.archlinux.org/pipermail/pacman-dev/2011-August/014023.html.
It was never reviewed by Allan but according to last reviwing from Dave Reisner it still has some issues with portability.
Due to lack of attention here I kind of give up it and now I unlikely find time to continue work on it.

The last version of patch in the mail list contains error.
eval "package ..." should be replaced by eval "function package ...".
Unfortunately I did this last change in hurry and didn't test it.

I just hope my work can be useful in future here.
Comment by Martin Stolpe (BertiBoeller) - Sunday, 23 October 2011, 14:10 GMT
Hi,

did I understand Dave Reisner's comment correctly that makepkg is supported for other platforms too? I understood Dave Reisner correctly makepkg also supported on OSX and cygwin?

Wouldn't it be possible to make the code for building debug packages platform specific: If the compiler is gcc and objectdump and readelf exist allow building of debug packages, in all other cases ignore the flag.
Comment by Jason William Walton (jasonww) - Sunday, 18 December 2011, 06:01 GMT
Debug symbols are incredibly easy to make available using build-ids:

When a Build ID is 717dddecd8a7c928c72d4c0afe14bdf58ad0783d
gdb will look here:
/usr/lib/debug/.build-id/71/7dddecd8a7c928c72d4c0afe14bdf58ad0783d.debug
regardless of path etc.

So with a little bit of parsing you can do this quick and dirty in 5 lines of bash or so, assuming you reuse the strip loop in makepkg and don't bother with seperate packages.
Comment by Raghavendra D Prabhu (rprabhu) - Sunday, 18 December 2011, 08:19 GMT
The one Jason is referring to is http://sourceware.org/gdb/onlinedocs/gdb/Separate-Debug-Files.html and is way more convenient than other approaches and will require only a modification to makepkg, also binutils in Arch is fairly new to support build ids.

Adding something similar to following to makepkg should do: (requires eu-strip from elfutils, if using strip will require a slightly longer step)

file="<filename>"
bldid=$(file -n -b $file | grep -o -E '0x[a-f0-9]+')
dir="${bldid:2:2}"
mkdir -p $pkgdir/usr/lib/debug/$dir/
eu-strip -f $pkgdir/usr/lib/debug/$dir/${bldid:4:-1}.debug $file
Comment by Allan McRae (Allan) - Sunday, 18 December 2011, 08:30 GMT
I guess you never read the rest of the bug report given the method is basically exactly the same was already proposed. The only difference is instead of using build-ids, the debug hierarchy is created under /usr/lib/debug (e.g. /usr/lib/debug/usr/bin/ls.debug).
Comment by Jason William Walton (jasonww) - Sunday, 18 December 2011, 08:35 GMT
Something like that.

Heres how it looks in valgrind for anyone who cares:

--3123-- Reading syms from /lib/ld-2.14.1.so (0x4000000)
--3123-- Considering /usr/lib/debug/.build-id/68/e0fd99cfe47a0d6c2d0e3c272dfb33558dfef6.debug ..
--3123-- .. build-id is valid
....
--3123-- Reading syms from /lib/libc-2.14.1.so (0x4e2f000)
--3123-- Considering /usr/lib/debug/.build-id/d7/ea87cfa3d875b8a290aa2fb7d2146f73494ef5.debug ..
--3123-- .. build-id is valid
etc.

I used /usr/bin/objcopy --compress-debug-sections --only-keep-debug
instead of eu-strip.



Comment by Raghavendra D Prabhu (rprabhu) - Tuesday, 24 January 2012, 23:40 GMT
@Jason, the build id returned by file is different from that returned by readelf command. I think there may be bug with former. GDB doesn't recognise if build id from file is used but works with one readelf returns. For some reason, Valgrind throws this if the build-id from readelf is used, may be a bug with valgrind too.

"--12370-- Reading syms from /usr/bin/rtorrent (0x400000)
--12370-- Considering /usr/lib/debug/.build-id/a1/ec3cc04fa376fca521981919430eb4776ad1c6.debug ..
--12370-- .. build-id mismatch (found (null) wanted a1ec3cc04fa376fca521981919430eb4776ad1c6)
--12370-- object doesn't have a symbol table
"
Comment by Jason William Walton (jasonww) - Sunday, 12 February 2012, 13:24 GMT
Indeed, file seems broken compared to readelf.

Heres a really shitty function I made that seems to work just fine.
I incorporated this into the strip loop since I don't really care about disk space.
Note that I have no clue about how bash works, so I'm pretty sure it could be a lot nicer.

seperate_debuginfo() {
local elf="$1"
local bldidx=$(/usr/bin/readelf -n $elf | /bin/grep "Build ID")
local bldid=${bldidx:14:40}

if [[ $bldid ]]; then
local short=${bldid:0:2}
#echo "Splitting up debug symbols: ELF: $elf -> Build ID: $bldid"
if [[ ! -d usr/lib/debug/.build-id/$short ]]; then
/bin/mkdir -m 0755 -p "usr/lib/debug/.build-id/$short"
fi
local new_build_id=${bldid:2:40}
/usr/bin/objcopy --compress-debug-sections --only-keep-debug $elf "usr/lib/debug/.build-id/$short/$new_build_id.debug"
fi
}

You probably want to fix the hardcoded paths before trying it.
Comment by Vampir achtneunacht (Vamp898) - Monday, 09 July 2012, 17:01 GMT
I really think this bug should have an much higher Priority.

I mean its not a "nice to have feature" it something like essential to fix bugs. Right now i have to start a virtual machine (or my gentoo on the second partition) if i find a bug while running archlinux only because other distros have debug symbols.

I doubt that everyone is willing to have a second system with the same software just to report bugs, also this is _not_ KISS, KISS would be if pacman would have the ability to deliver debug packages.

To build them your own (especially with KDE) is some kind of unuseable and the opposite of KISS

This Bug is opened since 2008 and really should finally be fixed
Comment by Miguel Angel Rasero (skuda) - Monday, 09 July 2012, 17:15 GMT
Yeah i think this is truly important for a distro and it seems Arch Linux it is behind many others in this, it seems an abanadoned problem too.
Comment by Martin Sandsmark (sandsmark) - Wednesday, 03 October 2012, 17:19 GMT
I applied the latest patch I found here: https://github.com/sandsmark/pacman
Comment by Allan McRae (Allan) - Wednesday, 03 October 2012, 20:40 GMT
Or... you could use the set of 10 patches to get this working properly available here:
https://projects.archlinux.org/users/allan/pacman.git/log/?h=working-split/debug
Comment by Martin Stolpe (BertiBoeller) - Wednesday, 03 October 2012, 20:46 GMT
Does this mean that makepkg will officially support building of split packages in a future version or is it just your private repository? If this will be supported officially this would be really great news!
Comment by Allan McRae (Allan) - Wednesday, 03 October 2012, 20:50 GMT
That will be merged into pacman soon. This does not mean Arch Linux will provide debug packages....
Comment by Martin Stolpe (BertiBoeller) - Wednesday, 03 October 2012, 20:55 GMT
I really appreciate it that the building of debug packages will be supported. May I ask why you don't have any plans to offer debug packages? For me it would make sense as Arch users are usually amongst the first to use a new software release. I've had some KDE crashes in past (luckily not anymore) which I wasn't able to report because the crash log was unusable because of missing debug symbols.
Comment by Martin Sandsmark (sandsmark) - Wednesday, 03 October 2012, 23:10 GMT
Allan, you are a magnificent person.

And as a KDE developer I really hope Arch starts shipping debug symbols, but still; thanks a bunch for this. :)
Comment by André Fettouhi (A.Fettouhi) - Thursday, 04 October 2012, 13:08 GMT
This should really be a top priority getting debug symbols into KDE in Arch. I have a bug report also in Amarok that I can't anything with.
Comment by Peter Wu (Lekensteyn) - Thursday, 04 October 2012, 20:57 GMT
Allan, there is a small typo in the help text in configure.ac:
+# Help line for debug package suffix
+AC_ARG_WITH(debug-suffix,
+ AS_HELP_STRING([--with-debux-suffix=name], [set the suffix for split debugging symbol packages used by makepkg]),
+ [DEBUGSUFFIX=$withval], [DEBUGSUFFIX=debug])

+1 for inclusion of debugging packages in arch, hitting a specific bug and not being able to get a meaningful backtrace (even with recompiling) is not cool.
Comment by Allan McRae (Allan) - Friday, 05 October 2012, 01:02 GMT
@Peter: thanks - typo fixed.


Please leave the discussion about debugging packages in Arch Linux out of this report. This bug is for tracking the implementation in pacman only.
Comment by Felipe Lessa (meteficha) - Tuesday, 28 October 2014, 14:08 GMT
Sorry for the silly "ping" comment, but it seems like this issue has been forgotten. It has been full 2 years since the last comment on this bug report. It's stated as 100% complete, and that it "will be merged into pacman soon". Finally, it's set as due to 4.1.0, but we're already at 4.1.2. Thanks! :)

Edit: sorry for the noise, I clearly can't read the issue status :/.
Comment by Allan McRae (Allan) - Tuesday, 28 October 2014, 23:21 GMT
This has been implemented since 4.1.0. So you are more than a year late in your ping...

Loading...