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 .orig 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.) -- 954078: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=954078 Debian Bug Tracking System Contact [email protected] with problems
--- Begin Message ---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
--- End Message ---
--- Begin Message ---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
--- End Message ---
