Re: [DDEB] Status on automatic debug packages (2015-08-24)
Dnia 2015-09-20, nie o godzinie 19:38 +0200, Niels Thykier pisze:
[ cut ]
> > I added DH_BUILD_DDEBS = 1 to d/rules, changed dh_strip to use
> > --ddeb-migration and not -dbg-package, and removed *-dbg from
> > d/control.
> > After building I got python-pyopencl{3}-dbgsym*.dbg.
> > Those packages contained only /usr/lib/debug/.build-id/*.debug
> > files,
> > without /usr/lib/python*/dist-packages/*.so.
> >
>
> Indeed, as I concluded above in reply to Jean-Michel, this is the
> intentional behaviour - at least for now.
>
> > Is there something missing?
> > Files *.so with debugging symbols are built (there are lines
> > PYBUILD_DESTDIR_python2-dbg=debian/python-pyopencl-dbg/ in d/rules)
> > so IMO it's (just?) case of adding those to *-dggsym.deb files.
> >
> > Best regards.
> >
>
> I am open to adding those at a later stage. Though at this point, I
> would really like to get ddebs into unstable, before we scope creep
> it
> any further.
Thanks for explanation.
For now I'll leave manual debug packages for Python.
At the same time - current DH with pybuilder build all necessary files
so as soon as DDEBs take Python-specific files into consideration
I'm ready to switch.
Best regards.
--
Tomasz Rybak GPG/PGP key ID: 2AD5 9860
Fingerprint A481 824E 7DD3 9C0E C40A 488E C654 FB33 2AD5 9860
http://member.acm.org/~tomaszrybak
signature.asc
Description: This is a digitally signed message part
Re: [DDEB] Status on automatic debug packages (2015-08-24)
On 2015-09-20 19:04, Tomasz Rybak wrote:
> Dnia 2015-08-25, wto o godzinie 13:41 +, Jean-Michel Vourgère
> pisze:
>> Hi
>>[...]
>>
>> The question is also valid for python2:
>>
>> When using dh --with python2 *and* build-depending on python-all-dbg,
>> I'm getting [1]:
>> * Some files like /usr/lib/debug/.build-id/*.debug
>> * Some files like
>> /usr/lib/python2.7/dist-packages/rrdtool.x86_64-linux-gnu_d.so
>>
>> Am I correct in assuming that this need to be split?
>> * Each arch:any binary package will get its own -dbgsym package, like
>> python-rrdtool-dbgsym_1.5.4-6_amd64.deb,
>> lua-rrd-dbgsym_1.5.4-6_amd64.deb, ...
>> * The python debug $(arch)_d.so generated by dh_auto_build will need
>> its
>> own package. (See questions of Nikolaus and Sebastian).
>>
>> The main question is whether or not these -dbgsym package is only of
>> debug symbols.
>>
The current plan is for debhelper to only deal with the first type of
debug symbols (i.e. /usr/lib/debug/.build-id/*/*.debug). I have not
looked at language specific debug files; we might do that later once the
original proposal is available in unstable.
>
>>
>> Assuming this is split, should one make a recommends: towards these
>> non-main packages?
>>
FTR: It is not a given that you should split them. If you have to
create a manual dbg package, you might as well include the normal debug
symbols.
>>
>> Finally, if the current -dbg packages are moved out of main, either
>> the
>> buildd's will need to have them in their source list, or the section
>> of
>> the python tools to generate the debug _d.so thingies need to be
>> changed.
>>
>> [1] https://packages.debian.org/sid/amd64/rrdtool-dbg/filelist
For reference, given the issues with moving regular -dbg packages out of
main (some of them are used as Build-Depends), manual -dbg packages will
stay in unstable.
This was concluded in a separate branch of this thread.
>
> Test on current sid, trying to PyOpenCL with pybuild and debug symbols.
> Current version of package has *-dbg entries for both Python 2 and Python 3,
> and thanks for pybuild there is no need for code dealing with those in
> d/control.
>
> I added DH_BUILD_DDEBS = 1 to d/rules, changed dh_strip to use
> --ddeb-migration and not -dbg-package, and removed *-dbg from d/control.
> After building I got python-pyopencl{3}-dbgsym*.dbg.
> Those packages contained only /usr/lib/debug/.build-id/*.debug files,
> without /usr/lib/python*/dist-packages/*.so.
>
Indeed, as I concluded above in reply to Jean-Michel, this is the
intentional behaviour - at least for now.
> Is there something missing?
> Files *.so with debugging symbols are built (there are lines
> PYBUILD_DESTDIR_python2-dbg=debian/python-pyopencl-dbg/ in d/rules)
> so IMO it's (just?) case of adding those to *-dggsym.deb files.
>
> Best regards.
>
I am open to adding those at a later stage. Though at this point, I
would really like to get ddebs into unstable, before we scope creep it
any further.
Thanks,
~Niels
signature.asc
Description: OpenPGP digital signature
Re: [DDEB] Status on automatic debug packages (2015-08-24)
Dnia 2015-08-25, wto o godzinie 13:41 +, Jean-Michel Vourgère
pisze:
> Hi
>
> Nikolaus Rath wrote:
> > On Aug 24 2015, Sebastian Ramacher wrote:
> > > What's the plan for python(3)-*-dbg packages that include both
> > > Python extensions
> > > built for the python-dbg interpreter and debug symbols? Should
> > > they also change
> > > their Section to something else?
> >
> >
> > .. and will they also be build automatically? Or rather, when
> > relying on
> > the automatic building, will they include the extension for the
> > debug
> > interpreter or just the debugging symbols for all extensions (built
> > for
> > debugging and regular interpreter)?
>
> The question is also valid for python2:
>
> When using dh --with python2 *and* build-depending on python-all-dbg,
> I'm getting [1]:
> * Some files like /usr/lib/debug/.build-id/*.debug
> * Some files like
> /usr/lib/python2.7/dist-packages/rrdtool.x86_64-linux-gnu_d.so
>
> Am I correct in assuming that this need to be split?
> * Each arch:any binary package will get its own -dbgsym package, like
> python-rrdtool-dbgsym_1.5.4-6_amd64.deb,
> lua-rrd-dbgsym_1.5.4-6_amd64.deb, ...
> * The python debug $(arch)_d.so generated by dh_auto_build will need
> its
> own package. (See questions of Nikolaus and Sebastian).
>
> The main question is whether or not these -dbgsym package is only of
> debug symbols.
>
>
> Assuming this is split, should one make a recommends: towards these
> non-main packages?
>
>
> Finally, if the current -dbg packages are moved out of main, either
> the
> buildd's will need to have them in their source list, or the section
> of
> the python tools to generate the debug _d.so thingies need to be
> changed.
>
> [1] https://packages.debian.org/sid/amd64/rrdtool-dbg/filelist
Test on current sid, trying to PyOpenCL with pybuild and debug symbols.
Current version of package has *-dbg entries for both Python 2 and Python 3,
and thanks for pybuild there is no need for code dealing with those in
d/control.
I added DH_BUILD_DDEBS = 1 to d/rules, changed dh_strip to use
--ddeb-migration and not -dbg-package, and removed *-dbg from d/control.
After building I got python-pyopencl{3}-dbgsym*.dbg.
Those packages contained only /usr/lib/debug/.build-id/*.debug files,
without /usr/lib/python*/dist-packages/*.so.
Is there something missing?
Files *.so with debugging symbols are built (there are lines
PYBUILD_DESTDIR_python2-dbg=debian/python-pyopencl-dbg/ in d/rules)
so IMO it's (just?) case of adding those to *-dggsym.deb files.
Best regards.
--
Tomasz Rybak GPG/PGP key ID: 2AD5 9860
Fingerprint A481 824E 7DD3 9C0E C40A 488E C654 FB33 2AD5 9860
http://member.acm.org/~tomaszrybak
signature.asc
Description: This is a digitally signed message part
Re: [DDEB] Status on automatic debug packages (2015-08-24)
On 2015-08-27 14:57, Bastian Blank wrote: > On Mon, Aug 24, 2015 at 11:12:41PM +0200, Niels Thykier wrote: >> * ddebs are Debian packages with the extension .deb that >> contain debugging symbols and are built implicitly. >> - A package foo_1.23.deb will receive a corresponding >> foo_1.23-dbgsym.deb package. > > Are they named .deb or .ddeb? > That would be ".deb" with a single "D" - sorry for the copy-waste mistake. I should probably start calling them dbgsym or adbg (for "automatic debug" packages) instead to avoid confusion. :) > One question remains: Can we move non-automatic build dbgsum packages[1] > to the special debug suite as well? Even after the recent change to not > automatically move them? > > Thanks, > Bastian > > [1]: linux for example needs to handle them specially, as they need to > contain unstripped binaries instead of detached debugging infos and > there is no support for build-ids. > Technically, yes. I also /suspect/ that the FTP masters would agree with it (but I cannot speak on their behalf). On the technical side, it is will be a simple matter of adding a field with a given value in your -dbg package. Thanks, ~Niels signature.asc Description: OpenPGP digital signature
Re: [DDEB] Status on automatic debug packages (2015-08-24)
On Mon, Aug 24, 2015 at 11:12:41PM +0200, Niels Thykier wrote: > * ddebs are Debian packages with the extension .deb that > contain debugging symbols and are built implicitly. > - A package foo_1.23.deb will receive a corresponding > foo_1.23-dbgsym.ddeb package. Are they named .deb or .ddeb? One question remains: Can we move non-automatic build dbgsum packages[1] to the special debug suite as well? Even after the recent change to not automatically move them? Thanks, Bastian [1]: linux for example needs to handle them specially, as they need to contain unstripped binaries instead of detached debugging infos and there is no support for build-ids. -- Most legends have their basis in facts. -- Kirk, "And The Children Shall Lead", stardate 5029.5 signature.asc Description: Digital signature
Re: [DDEB] Status on automatic debug packages (2015-08-24)
On Mon, Aug 24, 2015 at 02:28:05PM -0700, Steve Langasek wrote: > I wonder how this list was arrived at. Offhand, I see the libc6-dbg and > python3.5-dbg packages are both in section 'debug', both of which are part > of the build-dependency closure of main; I'm pretty sure we don't want them > shunted to a separate archive. Really good point; no one thought of this while we were sprinting on it. Right, so, two things are now in. nthykier has checked in a changeset to add a binary control header to signal it's an autocreated debug package, and dak now uses that to check to see if it should be diverted. This means we *wont* see a great pickup in space by moving those super ultra huge debs (like webkit's debug package) into the other mirror, but I'm sure we can work something out with the maintainers. Anyway, thanks for that. Patches made against dak and just getting some testing locally now. Paul -- .''`. Paul Tagliamonte | Proud Debian Developer : :' : https://people.debian.org/~paultag | https://pault.ag/ `. `'` Debian - the Universal Operating System `-4096R / 8F04 9AD8 2C92 066C 7352 D28A 7B58 5B30 807C 2A87 signature.asc Description: Digital signature
Re: [DDEB] Status on automatic debug packages (2015-08-24)
Hi Nikolaus Rath wrote: > On Aug 24 2015, Sebastian Ramacher wrote: >> What's the plan for python(3)-*-dbg packages that include both Python >> extensions >> built for the python-dbg interpreter and debug symbols? Should they also >> change >> their Section to something else? > > > .. and will they also be build automatically? Or rather, when relying on > the automatic building, will they include the extension for the debug > interpreter or just the debugging symbols for all extensions (built for > debugging and regular interpreter)? The question is also valid for python2: When using dh --with python2 *and* build-depending on python-all-dbg, I'm getting [1]: * Some files like /usr/lib/debug/.build-id/*.debug * Some files like /usr/lib/python2.7/dist-packages/rrdtool.x86_64-linux-gnu_d.so Am I correct in assuming that this need to be split? * Each arch:any binary package will get its own -dbgsym package, like python-rrdtool-dbgsym_1.5.4-6_amd64.deb, lua-rrd-dbgsym_1.5.4-6_amd64.deb, ... * The python debug $(arch)_d.so generated by dh_auto_build will need its own package. (See questions of Nikolaus and Sebastian). The main question is whether or not these -dbgsym package is only of debug symbols. Assuming this is split, should one make a recommends: towards these non-main packages? Finally, if the current -dbg packages are moved out of main, either the buildd's will need to have them in their source list, or the section of the python tools to generate the debug _d.so thingies need to be changed. [1] https://packages.debian.org/sid/amd64/rrdtool-dbg/filelist -- Nirgal
Re: [DDEB] Status on automatic debug packages (2015-08-24)
On 2015-08-25 11:29, Matthias Klose wrote: > On 08/24/2015 11:12 PM, Niels Thykier wrote: >> * debhelper will be including debug-ids in the control file to make it >>easier to find the necessary debug symbols for a given file. >>- Thanks to paultag for this idea. >>- This is merged into git and will be included in the next upload. > > are these debug-ids the same as the build-id emitted by GCC? If yes, please > could you consider enabling these build-id's independent of the debhelper > compat > level? I see no reason why these should be only enabled by compat 9. > > Matthias > Hi, Indeed, they are the same as emitted by GCC and they will be added regardless of compat level (like ddebs itself). ~Niels signature.asc Description: OpenPGP digital signature
Re: [DDEB] Status on automatic debug packages (2015-08-24)
On 08/24/2015 11:12 PM, Niels Thykier wrote: > * debhelper will be including debug-ids in the control file to make it >easier to find the necessary debug symbols for a given file. >- Thanks to paultag for this idea. >- This is merged into git and will be included in the next upload. are these debug-ids the same as the build-id emitted by GCC? If yes, please could you consider enabling these build-id's independent of the debhelper compat level? I see no reason why these should be only enabled by compat 9. Matthias
Re: [DDEB] Status on automatic debug packages (2015-08-24)
On Aug 24 2015, Sebastian Ramacher wrote: > Hi > > On 2015-08-24 23:12:41, Niels Thykier wrote: >> * Up to 5 packages need to change section (see "Implementation- >>details" below) >>- See #796834, #796836, #796839, #796840, and #796842. > > What's the plan for python(3)-*-dbg packages that include both Python > extensions > built for the python-dbg interpreter and debug symbols? Should they also > change > their Section to something else? .. and will they also be build automatically? Or rather, when relying on the automatic building, will they include the extension for the debug interpreter or just the debugging symbols for all extensions (built for debugging and regular interpreter)? Best, -Nikolaus -- GPG encrypted emails preferred. Key id: 0xD113FCAC3C4E599F Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F »Time flies like an arrow, fruit flies like a Banana.« signature.asc Description: PGP signature
Re: [DDEB] Status on automatic debug packages (2015-08-24)
Hi On 2015-08-24 23:12:41, Niels Thykier wrote: > * Up to 5 packages need to change section (see "Implementation- >details" below) >- See #796834, #796836, #796839, #796840, and #796842. What's the plan for python(3)-*-dbg packages that include both Python extensions built for the python-dbg interpreter and debug symbols? Should they also change their Section to something else? Cheers -- Sebastian Ramacher signature.asc Description: Digital signature
Re: [DDEB] Status on automatic debug packages (2015-08-24)
On 2015-08-24 23:28, Steve Langasek wrote: > Hi Niels, > > On Mon, Aug 24, 2015 at 11:12:41PM +0200, Niels Thykier wrote: >> [...] > > I wonder how this list was arrived at. Offhand, I see the libc6-dbg and > python3.5-dbg packages are both in section 'debug', both of which are part > of the build-dependency closure of main; I'm pretty sure we don't want them > shunted to a separate archive. > > Analysis of Build-Dependencies[1] also shows libpetsc3.4.2-dbg is affected, > which wasn't in your list. > > Thanks, > I looked for packages in the debug section, which did not end in -dbg. It did not occur to me that we were using -dbg packages as a part of the build-dependency chains. I suspect it did not occur to the FTP masters when they wrote the DAK patch. Thanks, ~Niels signature.asc Description: OpenPGP digital signature
Re: [DDEB] Status on automatic debug packages (2015-08-24)
Hi Niels, On Mon, Aug 24, 2015 at 11:12:41PM +0200, Niels Thykier wrote: > * Up to 5 packages need to change section (see "Implementation- >details" below) >- See #796834, #796836, #796839, #796840, and #796842. > Implementation-details > == > > There are some details behind the implementation that might be of > general interest. > > * All packages in the "debug" section will be moved from unstable to >the new "unstable-debug" (separate mirror list) >- Including "manual" debug packages I wonder how this list was arrived at. Offhand, I see the libc6-dbg and python3.5-dbg packages are both in section 'debug', both of which are part of the build-dependency closure of main; I'm pretty sure we don't want them shunted to a separate archive. Analysis of Build-Dependencies[1] also shows libpetsc3.4.2-dbg is affected, which wasn't in your list. Thanks, -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org [1] grep-dctrl -sBuild-Depends -FBuild-Depends -r '.*-dbg' \ /chroots/sid/var/lib/apt/lists/*Sources \ | grep -vE 'python3?(-all)?-dbg|libc[0-9.]+-dbg' | less signature.asc Description: Digital signature
