Hi, On 11/03/10 02:02, Jonas Smedegaard wrote: > -dbg packages are not handled specially , but might "just work"(tm).
I guess for debugging symbols, but not for Python debug builds. For them, you need to normally build the package with pythonX.Y-dbg as the interpreter, and then rename the .so extensions to _d.so (so that python-dbg can find them). Also those builds need to be done with -O0. > The othe points certainly are handled. That's the reason this class > have been outside of mainline cdbs for so long: I extended makefile.mk > and autotools.mk to support multiflavored builds, That's very cool on its own :) I'll see if we can use it from those normal packages that we build several times with different flags (e.g. gtk+2.0). [snip] > Your implementation is quite exciting to look at. Parts of it I don't > like - e.g. setting per-rule variables I feel should be avoided. But > some parts are interesting - like bug#500118 which I did not know > about. Obvious when you think about it, I just didn't until now :-P You don't until you hit a bug ;) I was going to report a separate bug about it. >> What about -dbg builds? > > I have actually never tested -dbg packages with CDBS yet. I believe I > understand the general principle of such packages but have not yet had > any use for them myself (I do not understand strace or debugging running > C code). > > so you can no doubt educate me on that part. The idea is that debugging symbols are stripped from the main binaries to make them smaller (since end users don't need them), and we ship them in separate packages. Then if you need to debug something (say get a backtrace of a crash, or step through the program while it's running), if you don't have the debugging symbols, backtraces will contain almost zero information and you won't be able to step through the code (as gdb won't know where things are). But gdb is able to load detached debugging symbols, and that's what dbg packages contain. However that's only a part of Python -dbg packages. There's also the python-dbg interpreters, which cover different purposes (I'm not very confident with python-dbg but the way to build them is pointed above). > So how do we move from here? > > > First off: Would you like to join the CDBS team? Not for now, thanks. I can prepare a patch here and there and maybe at some point join the team, but I dunno if I have the time right now. > I feel that my implementation is the best one to work from - but > obviously I am biased, so do tell me if you disagree! Well, I dunno. Yours has the benefit that it reuses the existing (new) flavor support. If it can do everything mine does (read: if I can get pygtk and pygobject to work with it) then I'm okay with using yours. > I will certainly cherry-pick (the idea from) your handling bug#500118 Cool. > and will (later, I have my hands full at the moment) read it closer to > try reveal other neat details too. Would be very helpful if you could > point out to me what you think are candidates for cherry-picking. Mainly the python -dbg packages support. Also see https://wiki.ubuntu.com/PyDbgBuilds > I would appreciate help understanding and fixing any bugs in handling > -dbg packages. I believe some support is in cdbs already but have no > idea what works and what don't. CDBS supports normal -dbg packages (we have quite a lot in pkg-gnome), but Python -dbg packages require special handling. > Another thing I haven't gotten around to play with is parallelised > builds. In case you want a challenge ;-) Doesn't CDBS support it already? Cheers, Emilio -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
