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

[Emilio Pozuelo Monfort]

[ Adding ftpmaster@ to the loop ]

Philipp Kern wrote:
> 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"?

Yes, we would just need to pass ddebs.debian.org instead of ddebs.ubuntu.com to
apport-chroot, but this is to have a retracing system. There's a bug report
about integrating apport-retrace with the GUI, https://launchpad.net/bugs/75901

>> 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?

Looks like:

"It is possible to build GDB for several different target architectures. When
GDB is built like that, you can choose one of the available architectures with
the set architecture command."

From http://sourceware.org/gdb/current/onlinedocs/gdb_18.html#SEC168

Not sure what "several" exactly means here...

>> 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.

+1 for one ddeb per source package

And then it doesn't make sense to depend on all the binaries, so recommends at
most, yes (perhaps not even that...)

>> 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...).

I'm unsure about this (whether to create the ddebs in normal builds and make
them part of the normal uploads, vs only build them in the buildds so that
developers don't need to upload them and worry about them), so asking for
comments in -devel sounds good. I'll send an RFC to it.

>> 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).

Maybe we can throw away only the arch:any packages, and keep the arch:all ones,
so that we don't have this problem (at least until it's tackled down).

>> 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).

The collector thing was the alternative yes, but it's indeed weird. So we would
need to add multiarchive support to dak, right?

Cheers,
Emilio

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: OpenPGP digital signature
URL: <http://lists.alioth.debian.org/pipermail/soc-coordination/attachments/20090409/1f83715e/attachment.pgp>