Debian Bug report logs - #730572
reprepro: support for ddebs (debug symbols)

Reply or subscribe to this bug.

Toggle useless messages

Message #5 received at submit@bugs.debian.org (full text, mbox, reply):

From: Simon McVittie <simon.mcvittie@collabora.co.uk>

To: Debian Bug Tracking System <submit@bugs.debian.org>

Subject: reprepro: support for ddebs (debug symbols)

Date: Tue, 26 Nov 2013 16:49:58 +0000

[Message part 1 (text/plain, inline)]

Package: reprepro
Version: 4.13.1-1+b1
Severity: wishlist

(Deliberately not tagging this +patch right now, since Debian doesn't
officially support ddebs yet, and the archive layout looks likely to change.)

Ubuntu has a semi-separate archive for separate debug symbols, and
<https://wiki.debian.org/AutomaticDebugPackages> is the proposal to
add the same thing to Debian. It would be great if reprepro could
support them, too.

The attached patch is a proof-of-concept implementation: it treats them
as a mixture of .deb and .ddeb. It seems to work OK in conjunction with
Ubuntu's pkg-create-dbgsym.

Known omissions:

* The wiki page says "ddeb will have no override entries, so no priority
  or section". In my implementation, they can have override entries
  (sharing an override file with normal debs), although those are not
  mandatory, and they have whatever package and section they are given
  by pkg-create-dbgsym, currently Priority: extra and whatever Section
  was used by the ordinary deb.

* The wiki page says "ddeb will go into the component "debug", so will
  show up in ./pool/debug/" but in my implementation they go in
  pool/{main,contrib,non-free}. The wiki page lists "Do we need to
  split ddeb per main/contrib/non-free?" as an open issue, which is partly
  why I chose to sidestep that question for now.

* The wiki page says "Standalone Release/Packages in ./debug/dists/"
  but in my implementation they behave more like udebs: they go somewhere
  like dists/main/debug/binary-i386/main and are covered by the main
  Release file.

* ddebs seem to end up with a long Description, despite the wiki
  page saying they shouldn't. I think tha might be a pkg-create-dbgsym
  bug, though?

I hope this is a useful starting point anyway.

Regards,
    S

[0002-Add-basic-support-for-ddebs-Ubuntu-style-dbgsym-pack.patch (text/x-diff, attachment)]

Message #10 received at 730572@bugs.debian.org (full text, mbox, reply):

From: "Bernhard R. Link" <brlink@debian.org>

To: Simon McVittie <simon.mcvittie@collabora.co.uk>

Cc: 730572@bugs.debian.org

Subject: Re: Bug#730572: reprepro: support for ddebs (debug symbols)

Date: Sun, 1 Dec 2013 03:34:42 +0100

* Simon McVittie <simon.mcvittie@collabora.co.uk> [131126 18:03]:
> (Deliberately not tagging this +patch right now, since Debian doesn't
> officially support ddebs yet, and the archive layout looks likely to change.)
> 
> Ubuntu has a semi-separate archive for separate debug symbols, and
> <https://wiki.debian.org/AutomaticDebugPackages> is the proposal to
> add the same thing to Debian. It would be great if reprepro could
> support them, too.
> 
> The attached patch is a proof-of-concept implementation: it treats them
> as a mixture of .deb and .ddeb. It seems to work OK in conjunction with
> Ubuntu's pkg-create-dbgsym.

Thanks. That fits the coding style of reprepro quite well. If you'd
have claimed I had written it and just forgotten about about, I'd
have had a hard time arguing against that.

> diff --git a/checkin.c b/checkin.c
> index 02ba279..ba5331f 100644
> --- a/checkin.c
> +++ b/checkin.c
> @@ -130,7 +130,7 @@ static void freeentries(/*@only@*/struct fileentry *entry) {
>  		free(entry->section);
>  		free(entry->priority);
>  		free(entry->name);
> -		if (entry->type == fe_DEB || entry->type == fe_UDEB)
> +		if (FE_BINARY(entry->type))
>  			deb_free(entry->pkg.deb);
>  		 else if (entry->type == fe_DSC) {
>  			 strlist_done(&entry->needed_filekeys);

I've already applied this one. As it makes sense anyway.


> @@ -1164,8 +1169,7 @@ static retvalue changes_checkpkgs(struct distribution *distribution, struct chan
>  	e = changes->files;
>  	while (e != NULL) {
>  		char *fullfilename;
> -		if (e->type != fe_DEB && e->type != fe_DSC
> -				&& e->type != fe_UDEB) {
> +		if (!FE_PACKAGE (e->type)) {
>  			e = e->next;
>  			continue;
>  		}

This, too. But without the space between E and (.

> +		/* we use the deb overrides for ddebs too - ddebs aren't
> +		 * meant to have overrides so this is probably fine */
>  		binoverride = distribution->overrides.deb;
>  		components = &distribution->components;

I think if those packages will finally come without a Priority or
Section in the package, there will be a more complex solution needed,
as without no Section at all, reprepro will not accept the package
yet (unless there is one in the override file).


> @@ -173,20 +176,36 @@ static retvalue gentargetcontents(struct target *target, struct release *release
>  	struct filetorelease *file;
>  	struct filelist_list *contents;
>  	struct target_cursor iterator;
> +	const char *suffix;
> +	const char *symlink_prefix;
>  
>  	if (onlyneeded && target->saved_wasmodified)
>  		onlyneeded = false;
>  
> +	switch (target->packagetype) {
> +		case pt_ddeb:
> +			symlink_prefix = "d";
> +			suffix = "-ddeb";
> +			break;
> +		case pt_udeb:
> +			symlink_prefix = "s";
> +			suffix = "-udeb";
> +			break;
> +		default:
> +			symlink_prefix = "";
> +			suffix = "";
> +	}
> +
>  	contentsfilename = mprintf("%s/Contents%s-%s",
>  			atoms_components[target->component],
> -			(target->packagetype == pt_udeb)?"-udeb":"",
> +			suffix,
>  			atoms_architectures[target->architecture]);

Will there even be Contents files for ddebs?


> +/* This is pretty close to duplicating the enum typedef'd to filetype
> + * in changes.h, but its order corresponds to typesuffix[]. Do not
> + * confuse them. */
>  enum filetype { ft_UNKNOWN,


uh, oh. Indeed, I should probably rename one of those two.

	Bernhard R. Link
-- 
F8AC 04D5 0B9B 064B 3383  C3DA AFFC 96D1 151D FFDC

Message #15 received at 730572@bugs.debian.org (full text, mbox, reply):

From: Simon McVittie <simon.mcvittie@collabora.co.uk>

To: 730572@bugs.debian.org

Subject: Re: Bug#730572: reprepro: support for ddebs (debug symbols)

Date: Thu, 19 Dec 2013 14:45:37 +0000

[Message part 1 (text/plain, inline)]

On 01/12/13 02:34, Bernhard R. Link wrote:
> * Simon McVittie <simon.mcvittie@collabora.co.uk> [131126 18:03]:
>> The attached patch is a proof-of-concept implementation

>> -		if (entry->type == fe_DEB || entry->type == fe_UDEB)
>> +		if (FE_BINARY(entry->type))
> 
> I've already applied this one. As it makes sense anyway.

Thanks! I've rebased onto that, and added a regression test (once I
found where testtool lives - please consider including that in reprepro
tarballs, if it isn't likely to be packaged separately).

> I think if those packages will finally come without a Priority or
> Section in the package, there will be a more complex solution needed,
> as without no Section at all, reprepro will not accept the package
> yet (unless there is one in the override file).

Fixed, I think: I've forced them to Section: debug, Priority: extra.

> Will there even be Contents files for ddebs?

*shrug* it was easier to implement them than to consider whether to do so...

    S

[0002-Add-basic-support-for-ddebs-Ubuntu-style-dbgsym-pack.patch (text/x-patch, attachment)]

[0003-Add-a-regression-test-for-udebs-and-ddebs.patch (text/x-patch, attachment)]

Message #20 received at 730572@bugs.debian.org (full text, mbox, reply):

From: kindjal@gmail.com

To: 730572@bugs.debian.org

Subject: status ddeb support in reprepro

Date: Thu, 7 Aug 2014 10:38:34 -0500

I don't see any evidence of these patches in the current (4.15.0)
code. Is there a current status report?

Message #25 received at 730572@bugs.debian.org (full text, mbox, reply):

From: Niels Thykier <niels@thykier.net>

To: 730572@bugs.debian.org

Cc: Simon McVittie <simon.mcvittie@collabora.co.uk>, "Bernhard R. Link" <brlink@debian.org>

Subject: Re: Bug#730572: reprepro: support for ddebs (debug symbols)

Date: Sun, 20 Dec 2015 08:53:16 +0000

[Message part 1 (text/plain, inline)]

On Thu, 19 Dec 2013 14:45:37 +0000 Simon McVittie
<simon.mcvittie@collabora.co.uk> wrote:
> On 01/12/13 02:34, Bernhard R. Link wrote:
> > * Simon McVittie <simon.mcvittie@collabora.co.uk> [131126 18:03]:
> >> The attached patch is a proof-of-concept implementation
> 
> [...]
> 
> Thanks! I've rebased onto that, and added a regression test (once I
> found where testtool lives - please consider including that in reprepro
> tarballs, if it isn't likely to be packaged separately).
> 
> > I think if those packages will finally come without a Priority or
> > Section in the package, there will be a more complex solution needed,
> > as without no Section at all, reprepro will not accept the package
> > yet (unless there is one in the override file).
> 
> Fixed, I think: I've forced them to Section: debug, Priority: extra.
> 
> [...]

Hi,

Thanks for working on dbgsym support for reprepro.

In the actual implementation we got live now, there are a couple of
changes though.

 * The dbgsym packages use the .deb extension
 * The primary indicator of a dbgsym file is the header
   "Auto-Built-Package", which is set to (exactly) "debug-symbols"
 * Further validation that can/should be done:
   - The package name should end with "-dbgsym"
   - The package should be in section "debug" (possibly in a *non*
     main component)
 * If it sees a package "foo-dbgsym" with the header, then it should
   also assert that a package called "foo" is uploaded.  The latter
   should be listed in the control file.

In DAK / the Debian infrastructure, the dbgsym packages are placed in a
separate component called "<suite>-debug".  The current mirror is
available at [1].

Thanks,
~Niels

[1] http://debug.mirrors.debian.org/

[signature.asc (application/pgp-signature, attachment)]

Message #30 received at 730572@bugs.debian.org (full text, mbox, reply):

From: Simon McVittie <smcv@collabora.com>

To: Niels Thykier <niels@thykier.net>, 730572@bugs.debian.org

Cc: "Bernhard R. Link" <brlink@debian.org>, Lucas Kanashiro <lucas.kanashiro@collabora.com>

Subject: Re: Bug#730572: reprepro: support for ddebs (debug symbols)

Date: Tue, 11 Jun 2019 13:10:18 +0100

On Sun, 20 Dec 2015 at 08:53:16 +0000, Niels Thykier wrote:
> In the actual implementation we got live now, there are a couple of
> changes though.
> 
>  * The dbgsym packages use the .deb extension

For the non-Debian projects for which I developed this patch, we still
need at least basic support for .ddeb files, because Ubuntu's toolchain
still produces those (and as far as I can tell it will continue to do
so indefinitely - they no longer use pkg-create-dbgsym, but they have a
patch in their dh_strip to make it produce .ddeb instead of .deb files).

I wouldn't object to simplifying it by treating .ddeb files as exactly
equivalent to .deb, so they go alongside ordinary debs, instead of
creating a <component>/debug pseudo-component? That's what happens right
now when you import a Debian-built -dbgsym package into an unpatched
reprepro. (You can't currently import an Ubuntu-built -dbgsym package
at all.)

(Cc'ing my colleague Lucas Kanashiro who will be looking into rebasing
this patch for our own use - we need a fork of reprepro that supports
this, even if it can't go upstream, so we might as well provide an
updated patch on this bug too.)

> In DAK / the Debian infrastructure, the dbgsym packages are placed in a
> separate component called "<suite>-debug".

Isn't that a suite or a "dist" or something, rather than a component?
The production Debian dbgsym infrastructure seems to have the same
three components (aka archive areas) as the main Debian archive, namely
main, contrib and non-free.

I don't think reprepro can or should mimic dak's output accurately,
because dak creates a separate lookaside apt repository for detached
debug symbols, but the scope of reprepro is that it deals with a single
apt repository.

Because reprepro can already accept *-dbgsym_*.deb and will currently
list them alongside any other .deb, moving Debian-built (.deb) -dbgsym
packages into a separate suite, component or repository would arguably
be an incompatible behaviour change.

    smcv

Message #35 received at 730572-close@bugs.debian.org (full text, mbox, reply):

From: Debian FTP Masters <ftpmaster@ftp-master.debian.org>

To: 730572-close@bugs.debian.org

Subject: Bug#730572: fixed in reprepro 5.4.0-1

Date: Wed, 27 Jul 2022 11:20:58 +0000

Source: reprepro
Source-Version: 5.4.0-1
Done: Bastian Germann <bage@debian.org>

We believe that the bug you reported is fixed in the latest version of
reprepro, which is due to be installed in the Debian FTP archive.

A summary of the changes between this version and the previous one is
attached.

Thank you for reporting the bug, which will now be closed.  If you
have further comments please address them to 730572@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Bastian Germann <bage@debian.org> (supplier of updated reprepro package)

(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmaster@ftp-master.debian.org)


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Format: 1.8
Date: Wed, 27 Jul 2022 12:43:10 +0200
Source: reprepro
Architecture: source
Version: 5.4.0-1
Distribution: experimental
Urgency: medium
Maintainer: Bastian Germann <bage@debian.org>
Changed-By: Bastian Germann <bage@debian.org>
Closes: 570623 730572 857302
Changes:
 reprepro (5.4.0-1) experimental; urgency=medium
 .
   * Import new upstream version 5.4.0
     (Closes: #570623, #857302, #730572, LP: #799889)
   * Add ISC license for new test files
   * Run shunit2 tests on build time
Checksums-Sha1:
 825523930c3bde6fe32f43aa6e3321bfb1a41181 1757 reprepro_5.4.0-1.dsc
 982a0b97e1f2d88667e17d2991b1873dc01ade55 458700 reprepro_5.4.0.orig.tar.xz
 bf4e09c5d5897a7ae33bf5a922a52a7a2b1810bf 14608 reprepro_5.4.0-1.debian.tar.xz
 4ed2d1144f04a4a6c697e32fa158e6e139148f92 10211 reprepro_5.4.0-1_source.buildinfo
Checksums-Sha256:
 a9c3ea5c7244063ccf4d243a7fefb166a4d4980960c78cb5f24564556f27b939 1757 reprepro_5.4.0-1.dsc
 4e32f728b0053d28f832d1b51d07577f85b364a2bca44bdd573fb9024081da28 458700 reprepro_5.4.0.orig.tar.xz
 101d1ed858c717a9632b9cd41d1a1990cd5c736426f64f2e9bc4543d853cfba4 14608 reprepro_5.4.0-1.debian.tar.xz
 a71aa2fbc102d6aa7d8184b92c46d2fbe56ec998108fd53bd31d9eca34d1325c 10211 reprepro_5.4.0-1_source.buildinfo
Files:
 25eba5c2a04c2cfac5401400f1ed76ba 1757 utils optional reprepro_5.4.0-1.dsc
 eba99a3ed4c37477f47c4724608c2f9b 458700 utils optional reprepro_5.4.0.orig.tar.xz
 2e1e377dd10cd4342d052d6527cbec4f 14608 utils optional reprepro_5.4.0-1.debian.tar.xz
 71676cf7c8cbd6d2382e9c5d864248c3 10211 utils optional reprepro_5.4.0-1_source.buildinfo

-----BEGIN PGP SIGNATURE-----

iQHEBAEBCgAuFiEEQGIgyLhVKAI3jM5BH1x6i0VWQxQFAmLhGRgQHGJhZ2VAZGVi
aWFuLm9yZwAKCRAfXHqLRVZDFCx8DACFvm3YEwNELSZb4Y7ndDEScuNUbKKf/hYQ
RrxYZz+3oWpF/NFmRp/Y9jclYZVzn3LzXvaL6Hp3gb5wIwLKfuoapM6g+m3zeqvE
PwkMHEyB5R4megkqcIdGD3q+HgAEC5HO92xfkukgdf3UYG3WZ9DZ7t98RtkcvN1z
x+uNPiBda3A1akxku/3YhrUJ1YK4buYwa11XkruuYcjJHh6NspLojiDKGpCmJQjL
O3Xoonfo8Uyfwtg3IQvRTFpwDF9c2GNReyf4JS1MxAEoC30P4axMcammNRI7k9Of
hj3V55RgptDbowLYWUXxuX2UfddjzodmoZiYF1pxq+2Hz1anl8Ta5+a51uMxr3Vh
kLLLCZA4uQCQ3msSIUeVAhNr5J6+3BDJ52XRAg4/SpZK6rX9P5OwA4lIEwSwhImW
2jToHuu6EMhdkLwa7E6EXvMQwdRHmZolEalL3bakxBlBohNv560Ff4Feo8Pj1beA
7C/jhcjwXU3tltiTU/w2a6MCYYp/ZFY=
=80ap
-----END PGP SIGNATURE-----

Send a report that this bug log contains spam.