Bug#954078: marked as done (vulkan-loader: consider using multiple .orig tarball to simplify packaging)

This is a multi-part message in MIME format...

------------=_1785158942-1586201-0
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="utf-8"

Your message dated Mon, 27 Jul 2026 14:22:31 +0100
with message-id <amdbl3ibge3Djlu9@descent>
and subject line Re: Bug#954078: vulkan-loader: consider using multiple .or=
ig tarball to simplify packaging
has caused the Debian Bug report #954078,
regarding vulkan-loader: consider using multiple .orig tarball to simplify =
packaging
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact [email protected]
immediately.)


--=20
954078: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=3D954078
Debian Bug Tracking System
Contact [email protected] with problems

------------=_1785158942-1586201-0
Content-Type: message/rfc822
Content-Disposition: inline
Content-Transfer-Encoding: 7bit

Received: (at submit) by bugs.debian.org; 16 Mar 2020 12:41:48 +0000
X-Spam-Checker-Version: SpamAssassin 3.4.2-bugs.debian.org_2005_01_02
	(2018-09-13) on buxtehude.debian.org
X-Spam-Level: 
X-Spam-Status: No, score=-11.3 required=4.0 tests=BAYES_00,SPF_HELO_PASS,
	SPF_PASS,TXREP,UNPARSEABLE_RELAY autolearn=ham autolearn_force=no
	version=3.4.2-bugs.debian.org_2005_01_02
X-Spam-Bayes: score:0.0000 Tokens: new, 35; hammy, 149; neutral, 84; spammy,
	1. spammytokens:0.987-1--H*r:46044 hammytokens:0.000-+--H*F:U*smcv,
	0.000-+--UD:2.orig.tar.gz, 0.000-+--H*rp:U*smcv, 0.000-+--tarballs,
	0.000-+--gbpconf
Return-path: <[email protected]>
Received: from bhuna.collabora.co.uk ([2a00:1098:0:82:1000:25:2eeb:e3e3]:46044)
	by buxtehude.debian.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
	(Exim 4.92)
	(envelope-from <[email protected]>)
	id 1jDp40-0003fY-5E
	for [email protected]; Mon, 16 Mar 2020 12:41:48 +0000
Received: from [127.0.0.1] (localhost [127.0.0.1])
	(Authenticated sender: smcv)
	with ESMTPSA id 146E8294234
Date: Mon, 16 Mar 2020 12:41:38 +0000
From: Simon McVittie <[email protected]>
To: Debian Bug Tracking System <[email protected]>
Subject: vulkan-loader: consider using multiple .orig tarball to simplify
 packaging
Message-ID: <20200316124138.GA1250095@horizon>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
X-Reportbug-Version: 7.6.0
Delivered-To: [email protected]

Source: vulkan-loader
Version: 1.2.131.2-1
Severity: wishlist

I notice that vulkan-loader contains a vendored copy of vulkan-headers,
in order to keep the library and headers in sync, with the "upstream"
tarball actually being composed by repacking the combination of
vulkan-loader and vulkan-headers.

Since it's a 3.0 (quilt) package already, and the vendored vulkan-headers
is in the top-level directory, this seems like a perfect fit for multiple
.orig tarballs:

- download https://github.com/KhronosGroup/Vulkan-Loader/archive/sdk-1.2.131.2.tar.gz
  and rename it to vulkan-loader_1.2.131.2.orig.tar.gz
- download https://github.com/KhronosGroup/Vulkan-Headers/archive/sdk-1.2.131.1.tar.gz
  and rename it to vulkan-loader_1.2.131.2.orig-vulkan-headers.tar.gz
  (note the version number mismatch - sorry, I think this is unavoidable
  with current tools, if your upstream doesn't always keep the version
  numbers in sync)
- put both in ../ or wherever else you keep your upstream tarballs, or
  commit them to pristine-tar with gbp import-orig if you use that
- import them both into your upstream-unstable git branch, perhaps with
  gbp import-orig --upstream-vcs-tag=... --component=vulkan-headers
  to keep it as a descendant of the upstream git history

This would avoid needing to repack the upstream tarball, which seems likely
to be problematic if more than one developer imports it independently.

The yquake2 source package in contrib is an example of this technique.
I use DEP-14 branch names rather than the xorg-team's conventions, but
I think the difference is mostly just labelling? In particular,
"component=ctf" in debian/gbp.conf and debian/watch (in your case it
would be "component=vulkan-headers") activates the support for multiple
.orig tarballs in gbp and uscan.

I'm involved in the maintenance of a derivative (the Steam Runtime) that
has an interest in having the latest Vulkan library, and it's looking like
I might need to package the latest release (a development version "v...",
rather than the stable "sdk-..." versions that you package). Would you
be interested in receiving a merge request with that version, targeting
experimental?

Thanks,
    smcv

------------=_1785158942-1586201-0
Content-Type: message/rfc822
Content-Disposition: inline
Content-Transfer-Encoding: 7bit

Received: (at 954078-done) by bugs.debian.org; 27 Jul 2026 13:28:00 +0000
X-Spam-Checker-Version: SpamAssassin 4.0.1-bugs.debian.org_2005_01_02
	(2024-03-25) on buxtehude.debian.org
X-Spam-Level: 
X-Spam-Status: No, score=-7.2 required=4.0 tests=BAYES_00,DKIM_SIGNED,
	DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,HAS_BUG_NUMBER,SPF_HELO_NONE,
	SPF_PASS autolearn=ham autolearn_force=no
	version=4.0.1-bugs.debian.org_2005_01_02
X-Spam-Bayes: score:0.0000 Tokens: new, 20; hammy, 115; neutral, 24; spammy,
	0. spammytokens: hammytokens:0.000-+--H*F:U*smcv, 0.000-+--H*rp:U*smcv,
	 0.000-+--McVittie, 0.000-+--mcvittie, 0.000-+--smcv
Return-path: <[email protected]>
Received: from bali.collaboradmins.com ([148.251.105.195]:41484)
	by buxtehude.debian.org with utf8esmtps (TLS1.3:ECDHE_X25519__RSA_PSS_RSAE_SHA256__AES_256_GCM:256)
	(Exim 4.96)
	(envelope-from <[email protected]>)
	id 1woLN9-006eJp-2e
	for [email protected];
	Mon, 27 Jul 2026 13:28:00 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=collabora.com;
	s=mail; t=1785158551;
	bh=/n8mwjKNVttVRK36EQJXka1+oFRJRerL1LlhIAdkwY4=;
	h=Date:From:To:Subject:References:In-Reply-To:From;
	b=MRugpGI2x6cz53BOCa7sCF+MTxN3XlJKfBt0G0iuvQEReAezNG01JoJN3Azae7INE
	 HvjqN7xPzFMur7IFgyhAYsgW2DtGnsdubE2rF/rGzmPqlQ5xTSFvdALved4ykh3W2i
	 5Imtsr+IahYFFqhT6GDFwyKRsrrOKobGZX4m7fJGsJ7kor6wPQ7HDdtWyOeoQjGHgo
	 QgbMwkHW0t9PvRf/DcirtSEpQyCoqyYJXqIvIgbhTtPFfKumQwIrnQQLmoGxmauz0l
	 rY8H3LU75TzM/a+gNRL0B1seyADDNyNnB/wS55ddoXYatr2onzOk1tkFNGMssSTmD9
	 BfV26RXQZY4Wg==
Received: from localhost (unknown [100.64.0.242])
	(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
	 key-exchange secp256r1 server-signature RSA-PSS (4096 bits) server-digest SHA256)
	(No client certificate requested)
	(Authenticated sender: smcv)
	by bali.collaboradmins.com (Postfix) with UTF8SMTPSA id C065817E0213
	for <[email protected]>; Mon, 27 Jul 2026 15:22:31 +0200 (CEST)
Date: Mon, 27 Jul 2026 14:22:31 +0100
From: Simon McVittie <[email protected]>
To: [email protected]
Subject: Re: Bug#954078: vulkan-loader: consider using multiple .orig tarball
 to simplify packaging
Message-ID: <amdbl3ibge3Djlu9@descent>
References: <20200316124138.GA1250095@horizon>
 <20200316124138.GA1250095@horizon>
 <[email protected]>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <[email protected]>
X-Greylist: delayed 326 seconds by postgrey-1.37 at buxtehude; Mon, 27 Jul 2026 13:28:00 UTC

On Fri, 03 Apr 2020 at 13:22:42 +0300, Timo Aaltonen wrote:
> On 16.3.2020 14.41, Simon McVittie wrote:
> > [multiple .orig tarballs]
> > would avoid needing to repack the upstream tarball, which seems likely
> > to be problematic if more than one developer imports it independently.
> 
> Hmm, well it seems that using multiple tarballs involves more steps than
> the current one, if the tags can get out-of-sync as they are now.. so
> right now I'd rather keep the current method.

I asked you to consider it, you considered it, and the answer was no,
so: closing this.

    smcv
------------=_1785158942-1586201-0--