Re: dbgsym packages and backports
* Niels Thykier <email@example.com> [2016-01-14 08:36:52 CET]:
> Jens Reyer:
> > how should we (backports) handle packages that build the new dbgsym
> > packages? (CCing Niels who sent the announce mail.)
> Speaking with my debhelper/dbgsym implementor hat on. I will leave
> *all* decisions about backports to the backports FTP masters.
Well, that's an easy call. ;) Given that I'm uncertain how the
dbgsym should be handled here I'll pass that ball on to the regular FTP
> > Generally:
> > Debhelper in jessie-backports (9.20150101) doesn't support this. Is
> > anybody planning to backport debhelper for jessie-backports?
> Recent versions of debhelper has removed support for compat 1+2 (and
> quite soon, compat 3). I doubt this is something you want to/in
> On the other hand, backporting the particular changes needed to build
> dbgsyms should be less problematic.
I rather would not see that feature added to backports specificly if
the rest of the rest of the archive doesn't know how to handle it.
Though: We have -dbg packages in stable and AIUI those automaticly
created -dbgsym package isn't too much different from those, so it
shouldn't be a big trouble.
> > Even with a newer debhelper I guess there are infrastructure changes
> > needed. Are there any plans for whatever is needed to support them? I
> > saw only posts about testing and stable(=stretch) requiring changes in
> > britney.
> Both stable and stable-backports could trivially enable the required
> features. Basically, they need what is called a "debug-suite" in dak.
Which the backports FTP masters can't do. That's for the regular FTP
masters to decide/do.
> Once they had that, dbgsyms would be accepted automatically and go to
> the correct mirror.
Currently we have six -dbgsym packages in backports which seem to have
slipped in by accident, because they are only built for amd64 but no
With that I like to emphasize: *Do* build your backported packages in a
stable environment with *no* stuff appart from backports in. There is
no debhelper package in backports that would create -dbgsym package, so
the chroot that did produce those binaries is tainted. Fix that. Now.
> The problem with testing is that we need to patch Britney to /migrate/
> the dbgsyms to testing. Without that, the testing debug suite will
> simply just be empty (or out of date).
> This affects stable because the empty/out-dated "testing-debug" would
> eventually be copied into/replace "stable-debug".
So before that happens any further discussion about dbgsym in backports
doesn't make any sense to me.
> > What would happen without infrastructure adapted, but debhelper
> > backported? Would dbgsym packages just be ignored, or would this cause
> > errors? AFAIK debugsyms are currently only available for unstable and
> > experimental, so for jessie-backports with a backported debhelper the
> > same might happen as for stretch currently (whatever this is).
> * Without a debug suite, the dbgsym packages will end up in
> backports-NEW on the upload AFAICT.
> - Should make them trivial to spot and REJECT.
Mistakes can happen and will. I'm not sure if a dak rm would do the
right thing here, I'll investigate. So far I don't know if the
debhelper is/was the only thing tainting the chroot for those two
backports that produced the -dbgsym packages, so it might affect more
> A little known "secret": The relation given to "--ddeb-migration" is
> /not/ required to be versioned (if you do not mind a "I"-tag from lintian).
> Secondly, the Breaks/Replaces are only "required" as long as one of
> the ELF build-ids of your current matches the one from the "-dbg"
> package. If all your ELF binaries contain "__DATE__" and "__TIME__" in
> them (or is otherwise built completely non-deterministic) you are
> probably safe.
But we are aiming at reproducible builds in general - might that cause
more troubles in that area?
> > So I think I'll just remove the override_dh_strip completly. Thus the
> > binaries will be stripped, but the debug symbols will be discarded.
> > The -dbg package has a versioned depends, so it will be uninstalled on
> > update. I guess there is no need to add a Replaces/Breaks in libwine.
I guess that sounds like a sane approach - at least for now until we
find out more. It at least provides less pain to deal with in case
things are more clear in the longer run I'd say.
Rhonda [mostly without backports team hat on, but still influenced by it]
Fühlst du dich mutlos, fass endlich Mut, los |
Fühlst du dich hilflos, geh raus und hilf, los | Wir sind Helden
Fühlst du dich machtlos, geh raus und mach, los | 23.55: Alles auf Anfang
Fühlst du dich haltlos, such Halt und lass los |