Bug#884865: Response?

[Brett Johnson]

On Wed, Mar 7, 2018 at 8:05 AM, Timo Aaltonen  wrote:
>
> > 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:
> >
> > https://github.com/KhronosGroup/glslang/issues/1255
>
> Looks like there's now 5.0 released yesterday, which is nice. If only
> spirv-headers got tagged..


Although spirv-headers isn't tagged, it's not too hard to version.
The headers API is versioned, and is currently at 1.2, so I simply
counted the number of commits in master, and added it to the end of
"1.2.".  This is the script I put in my package to generate a version
number:

 #!/bin/sh

 UPSTREAM_REMOTE=khronos
 UPSTREAM_BRANCH=master

 COMMON_ANCESTOR=`git merge-base master $UPSTREAM_REMOTE/$UPSTREAM_BRANCH`

 NB_OF_COMMITS=`git log --oneline $COMMON_ANCESTOR | wc -l`
 echo "1.2.$NB_OF_COMMITS"

Bug#884865: Response?

[Timo Aaltonen]

On 02.03.2018 18:54, Brett Johnson wrote:
> 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 repositories:
> 
> https://github.com/linuxturtle/glslang
> https://github.com/linuxturtle/SPIRV-Tools
> https://github.com/linuxturtle/SPIRV-Headers

Ah, I should've known better.. anyway, these can be co-maintained in
salsa.d.o/xorg-team/vulkan/, just that for uploads someone with
sufficient credentials is needed to sponsor them..

> 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:  
> 
> https://github.com/KhronosGroup/glslang/issues/1255

Looks like there's now 5.0 released yesterday, which is nice. If only
spirv-headers got tagged..

Bug#884865: Response?

[Brett Johnson]

Oh, also, my thoughts on splitting spirv-tools were that it didn't need
splitting, as the whole package is a "-dev" package in itself.  I.e. even
though it produces libraries, executables, and headers, they're all part of
the same package, they're all only used for development, and don't really
need to be separated.  YMMV though, and the /bin executables could easily
be split into their own package if you think that's cleaner.  Builddep for
glslang and libvulkan would depend on both packages though.

On Fri, Mar 2, 2018 at 9:07 AM, Timo Aaltonen  wrote:

> On 26.02.2018 21:50, Brett Johnson wrote:
> > On Mon, Feb 26, 2018 at 12:25 PM, Timo Aaltonen 
> wrote:
> >> 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:
>
> https://salsa.debian.org/xorg-team/vulkan
>
> spirv-headers was uploaded already, but -tools needs some bikeshedding
> on how to split it, and glslang obviously needs this information for
> build-depends.
>
>
> --
> t
>

Bug#884865: Response?

[Brett Johnson]

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
repositories:

https://github.com/linuxturtle/glslang
https://github.com/linuxturtle/SPIRV-Tools
https://github.com/linuxturtle/SPIRV-Headers

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:

https://github.com/KhronosGroup/glslang/issues/1255

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.

Thanks!

On Fri, Mar 2, 2018 at 9:07 AM, Timo Aaltonen  wrote:

> On 26.02.2018 21:50, Brett Johnson wrote:
> > On Mon, Feb 26, 2018 at 12:25 PM, Timo Aaltonen 
> wrote:
> >> 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:
>
> https://salsa.debian.org/xorg-team/vulkan
>
> spirv-headers was uploaded already, but -tools needs some bikeshedding
> on how to split it, and glslang obviously needs this information for
> build-depends.
>
>
> --
> t
>

Bug#884865: Response?

[Timo Aaltonen]

On 26.02.2018 21:50, Brett Johnson wrote:
> On Mon, Feb 26, 2018 at 12:25 PM, Timo Aaltonen  wrote:
>> 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:

https://salsa.debian.org/xorg-team/vulkan

spirv-headers was uploaded already, but -tools needs some bikeshedding
on how to split it, and glslang obviously needs this information for
build-depends.


-- 
t

Bug#884865: Response?

[Brett Johnson]

On Mon, Feb 26, 2018 at 12:25 PM, Timo Aaltonen  wrote:
> 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.

Bug#884865: Response?

[Timo Aaltonen]

Brett Johnson kirjoitti 26.02.2018 klo 20:52:
> On Thu, Feb 15, 2018 at 4:35 AM, Timo Aaltonen  wrote:
>> Looks like latest vulkan changed how it depends on SPIRV, so we'll just
>> bite the bullet and package glslang and spirv-tools separately instead..
> 
> I've got a first draft of these packages done.
> 
> Also, I think I should maybe clarify the changes in how the
> loader/validation sources pull in glslang and spirv-*.
> 
> Nothing has really changed WRT dependencies on the source code.
> libVkLayer still requires glslang, which requires spirv-tools.  The
> only difference is that spirv-tools and spirv-headers is now pulled in
> by the glslang sources, instead of by the LVL sources directly.  I.e.
> the "update_external_sources.sh" script clones glslang, then runs the
> "update_glslang_sources.py" script, which pulls in the correct version
> of spirv-tools and spirv-headers (inside the glslang source tree).
> So, just simply changing the debian/get-external.sh script to no
> longer pull in spirv-tools is not sufficient.
> 
> Could I suggest an alternative implementation of the
> debian/get-external.sh script?  Maybe simply call the existing
> "update_external_sources.sh" script, then find/rm the resulting .git
> directories inside of "external"?  That would ensure you always had
> the correct dependencies, even if Khronos/LunarG changes the way
> they're fetched again.

I've done that locally, just wondering (again) if glslang should be
packaged separately or not. Because now would be the time to do it..


-- 
t

Bug#884865: Response?

[Brett Johnson]

On Thu, Feb 15, 2018 at 4:35 AM, Timo Aaltonen  wrote:
> Looks like latest vulkan changed how it depends on SPIRV, so we'll just
> bite the bullet and package glslang and spirv-tools separately instead..

I've got a first draft of these packages done.

Also, I think I should maybe clarify the changes in how the
loader/validation sources pull in glslang and spirv-*.

Nothing has really changed WRT dependencies on the source code.
libVkLayer still requires glslang, which requires spirv-tools.  The
only difference is that spirv-tools and spirv-headers is now pulled in
by the glslang sources, instead of by the LVL sources directly.  I.e.
the "update_external_sources.sh" script clones glslang, then runs the
"update_glslang_sources.py" script, which pulls in the correct version
of spirv-tools and spirv-headers (inside the glslang source tree).
So, just simply changing the debian/get-external.sh script to no
longer pull in spirv-tools is not sufficient.

Could I suggest an alternative implementation of the
debian/get-external.sh script?  Maybe simply call the existing
"update_external_sources.sh" script, then find/rm the resulting .git
directories inside of "external"?  That would ensure you always had
the correct dependencies, even if Khronos/LunarG changes the way
they're fetched again.

Bug#884865: Response?

[Timo Aaltonen]

Brett Johnson kirjoitti 15.02.2018 klo 23:32:
> On Thu, Feb 15, 2018 at 10:23 AM, Brett Johnson  wrote:
>> Would you like me to file ITPs for them?  Or are you planning on doing
>> so right away?
> 
> Since we're on opposite sides of the pond, and I'm very impatient :D,
> I went ahead and filed ITPs for glslang (#890552) and spirv-tools
> (#890553), and I'll try to figure out how to version them in a sane
> way.  If you want to do the packaging, go ahead and reassign/change
> ownership for them.

ITP's are fine, thanks :)


-- 
t

Bug#884865: Response?

[Brett Johnson]

On Thu, Feb 15, 2018 at 10:23 AM, Brett Johnson  wrote:
> Would you like me to file ITPs for them?  Or are you planning on doing
> so right away?

Since we're on opposite sides of the pond, and I'm very impatient :D,
I went ahead and filed ITPs for glslang (#890552) and spirv-tools
(#890553), and I'll try to figure out how to version them in a sane
way.  If you want to do the packaging, go ahead and reassign/change
ownership for them.

Bug#884865: Response?

[Brett Johnson]

On Thu, Feb 15, 2018 at 4:35 AM, Timo Aaltonen  wrote:
> Looks like latest vulkan changed how it depends on SPIRV, so we'll just
> bite the bullet and package glslang and spirv-tools separately instead..

Yes, past the 1.0.65 tag/branch, the loader/layers repository (as well
as VulkanSamples) quit keeping track of the embedded explicit git
commit for spirv-tools, and now relies on glslang to pull in the
correct commit.  Still ugly, but slightly less ugly than it used to be
(at least now, there's only one place keeping track of that git commit
ID, rather than two places). That shouldn't change the packaging very
much though, and it has to change anyway to package 1.0.68 regardless.
But maybe you're right, and the two should be packaged separately
anyway, even though that's going to make keeping versioning straight
between all of them messy and manual.

Would you like me to file ITPs for them?  Or are you planning on doing
so right away?

Bug#884865: Response?

[Timo Aaltonen]

On 12.02.2018 20:43, Brett Johnson wrote:
> Excellent, thank you for the update!
> 
> On Sat, Feb 10, 2018 at 7:55 AM, Timo Aaltonen  > wrote:
> 
> Brett Johnson kirjoitti 09.02.2018 klo 18:50:
> > Any chance of a response to this request?  If y'all think it's a bad
> > idea, or don't want to do it, that's OK, I'll go back to the drawing
> > board and try to figure out some sane way to package/version
> glslang and
> > spirv-tools independently (although that's going to be difficult, as
> > they don't have any kind of internal versioning).  But I'd sure
> > appreciate some kind of response.  Thanks!
> 
> Sorry about the delay, current git has packaging for these but I wanted
> to let folks have a look at it first before uploading (which will happen
> soon now).

Looks like latest vulkan changed how it depends on SPIRV, so we'll just
bite the bullet and package glslang and spirv-tools separately instead..


-- 
t

Bug#884865: Response?

[Brett Johnson]

Excellent, thank you for the update!

On Sat, Feb 10, 2018 at 7:55 AM, Timo Aaltonen  wrote:

> Brett Johnson kirjoitti 09.02.2018 klo 18:50:
> > Any chance of a response to this request?  If y'all think it's a bad
> > idea, or don't want to do it, that's OK, I'll go back to the drawing
> > board and try to figure out some sane way to package/version glslang and
> > spirv-tools independently (although that's going to be difficult, as
> > they don't have any kind of internal versioning).  But I'd sure
> > appreciate some kind of response.  Thanks!
>
> Sorry about the delay, current git has packaging for these but I wanted
> to let folks have a look at it first before uploading (which will happen
> soon now).
>

Bug#884865: Response?

[Timo Aaltonen]

Brett Johnson kirjoitti 09.02.2018 klo 18:50:
> Any chance of a response to this request?  If y'all think it's a bad
> idea, or don't want to do it, that's OK, I'll go back to the drawing
> board and try to figure out some sane way to package/version glslang and
> spirv-tools independently (although that's going to be difficult, as
> they don't have any kind of internal versioning).  But I'd sure
> appreciate some kind of response.  Thanks!

Sorry about the delay, current git has packaging for these but I wanted
to let folks have a look at it first before uploading (which will happen
soon now).

Bug#884865: Response?

[Brett Johnson]

Any chance of a response to this request?  If y'all think it's a bad idea,
or don't want to do it, that's OK, I'll go back to the drawing board and
try to figure out some sane way to package/version glslang and spirv-tools
independently (although that's going to be difficult, as they don't have
any kind of internal versioning).  But I'd sure appreciate some kind of
response.  Thanks!