[Soc-coordination] Fwd: Re: Debian debug packages project

[Philipp Kern]

One quick reply.

On Wed, Apr 08, 2009 at 09:24:46PM +0200, Emilio Pozuelo Monfort wrote:
> Marc Brockschmidt wrote:
> > I'm not sure how much work porting apport would be. The actual software
> > is already available and I don't think it needs a lot of changes - but
> > setting the service up might require quite a bit of time.
> We would need to integrate it with ddebs.debian.org (should be easy), and with

"should be easy"?

> debbugs if we want to use it to submit bugs and/or crashes. There is the
> retracing service too, but for that we would need servers for each arch running
> the retracers, which take the coredumps from somewhere (possibly from debbugs),
> which doesn't sound right since we don't want to make coredumps publicly
> available. So for now we can leave the retracing services out. There is the
> possibility to add an option to apport to download the ddebs packages to retrace
> a core dump locally, that would solve the privacy issue.

Another thing to investigate: shouldn't it be possible to have one machine which
can retrace all arches?  Shouldn't it be possible to get a multiarch gdb?

> Another good idea would be to grow a 'debug' option to apt-get (like the
> 'source' option) that installs the ddebs for the given packages (possibly for
> dependencies too).

I would go for one debug package per source package, btw, with (at max) recommends
on the binary packages.

> There's an issue I didn't think about before. If we make the ddebs creation as a
> special thing in the buildds (as Ubuntu does, dpkg-diverting dh_strip), we have
> the problem that for DDs uploads we would be missing ddeb packages, e.g. I
> upload foobar_1.0-1_i386.changes, when it's autobuilt on amd64 ddebs will be
> created, but not for i386.

Well, you basically have those two options and I guess they should be discussed
on debian-devel.  If we just adjust debhelper itself to create the ddeb everything
uploaded will gain ddebs (and thus larger uploads, but if there's consensus...).

> One possible solution would be to stop allowing binary uploads ;) ISTR there are
> plans to allow/require sourceful uploads, not sure if that's the case. If it
> was, the problem would be moot. If this is the plan for the future, but won't
> happen anytime soon, we can ignore binary uploads, and only create ddebs for
> packages built in the buildds, until that time comes when everybody does
> sourceful uploads. This is not ideal though, in case that takes a long time.

s/sourceful/source-only/.  No, it looks like ftpmasters still want the binary but
to throw it away, which would essentially be the same.  But we need to fix
arch:all autobuilding first (i.e. tackle it at all).

> Another possibility would be to add multiarchive support to dak, and make the
> ddebs creation part of the normal packages build. That way when you build foobar
> and upload it to Debian, you have built the ddebs and upload them to incoming
> together with everything else. But that doesn't sound like a great solution to me...

I find this confusing.  I think they should flow through ftp-master either way?
At least I don't like the collector think Canonical does (and they don't like
it neither).

Kind regards,
Philipp Kern
-- 
 .''`.  Philipp Kern                        Debian Developer
: :' :  http://philkern.de                         Stable Release Manager
`. `'   xmpp:phil at 0x539.de                         Wanna-Build Admin
  `-    finger pkern/key at db.debian.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: Digital signature
URL: <http://lists.alioth.debian.org/pipermail/soc-coordination/attachments/20090409/f893bde6/attachment.pgp>