Oh! I didn't know you were actively working on packaging these. I've also
packaged them, with results in the debian-unstable branches of these github
I think it's obviously better (since you're a dd, and I'm not) for you to
own it, so feel free to take any bits you find useful from those
repositories. The glslang packaging mostly came from some work that had
already been done by Daan Wendelen, and he asked that his name/copyright
remain attached to it, so if you use some of that, please honor his
request. He also gave me permission to change the license for debian/* to
Apache-2.0, so I did.
Some other bits you may not be aware of:
John Kessenich (main maintainer of glslang) is working on coming up with a
reasonable versioning scheme for it. So until he does that, you may want
to use a scheme similar to what I did, that will be overridden with
whatever he comes up with. The bug to track what he's doing is here:
I'm also working on packaging VulkanTools, and am running into a problem I
think you will also run into packaging the LVL repository. I have to run
right now, but I'll send you more details later, when I figure out how to
get around it.
On Fri, Mar 2, 2018 at 9:07 AM, Timo Aaltonen <tjaal...@debian.org> wrote:
> On 26.02.2018 21:50, Brett Johnson wrote:
> > On Mon, Feb 26, 2018 at 12:25 PM, Timo Aaltonen <tjaal...@debian.org>
> >> just wondering (again) if glslang should be
> >> packaged separately or not. Because now would be the time to do it.
> > FWIW, after digging further down this rabbit hole, I think you made
> > the right call by not wanting to package them in the same source
> > package as libvulkan. The upstream maintainer has agreed to start
> > versioning/tagging the glslang repository, so that makes it much more
> > sensible to package it separately. And there are people who want/use
> > glslang for OpenGL/OpenCL who have nothing to do with vulkan, so it
> > really should be independent anyway.
> I've pushed spirv-headers, -tools and glslang here:
> spirv-headers was uploaded already, but -tools needs some bikeshedding
> on how to split it, and glslang obviously needs this information for