Tried to build the Vulkan spec today and got

Traceback (most recent call last):
  File "/vulkan/scripts/genvk.py", line 19, in <module>
    from docgenerator import DocGeneratorOptions, DocOutputGenerator
  File "/vulkan/scripts/docgenerator.py", line 10, in <module>
    from parse_dependency import dependencyLanguage
  File "/vulkan/scripts/parse_dependency.py", line 15, in <module>
    from pyparsing import (
ModuleNotFoundError: No module named 'pyparsing'

@rpavlik per #33 (comment) it looks like the openxr-android container build is failing - could you check on that?

I'm not sure what repo CI is doing - the Azure files are beyond my pay grade at present - but it is taking approximately forever (35 minutes, at this point). If it's building all the images from scratch, let's not do that!

@rpavlik I think changing the default branch name triggered a re-run of CI. Looks like something about 'reuse' didn't work, which is odd because it's installed in other images that were built.

https://github.com/KhronosGroup/DockerContainers/actions/runs/3889699138

I just started using the Khronos Docker image to successfully build the Vulkan spec HTML, and happy to see that the HTML loads much faster in my default browser (Firefox).

One thing I want to be able to do is directly trigger a build inside the Docker container without using an interactive shell. I want to do that so I can update my already-existing "build anything" script to trigger a build directly from a shell on my Windows development system. When I use the generic Ubuntu Docker image, I can do this successfully. But this doesn't work in the Khronos vulkan-docs image:

C:\Windows\system32>docker run --rm --name test ubuntu /bin/ls -C /
bin   dev  home  lib64  mnt  proc  run   srv  tmp  var
boot  etc  lib   media  opt  root  sbin  sys  usr

C:\Windows\system32>docker run --rm --name test khronosgroup/docker-images:vulkan-docs /bin/ls -C /
** Creating user vulkan id 1000
HOME=/home/vulkan USER=vulkan CONTAINER_CWD=
** ignoring entrypoint.vulkan.sh args - length was 13
** About to gosu vulkan /bin/bash

It looks like the problem might be related to this override in /root/entrypoint.vulkan.sh that seems to trigger an interactive Bash shell no matter what you pass on the command line:

# Default to 'bash' if no arguments are provided
args="$@"
if [ -z "$args" ]; then
    args=/bin/bash
else
    # Actually, always use it, because CI appears to be passing in some horrid bash script as the arguments
    echo -n "** ignoring entrypoint.vulkan.sh args - length was "
    echo $args | wc -c
    args=/bin/bash
fi

Thanks,
Pat

It's possible to use image: sources with are remote URLs, but requires a couple of packages not in the Vulkan images. Need to add these:

• Debian package graphicsmagick-libmagick-dev-compat
• gem prawn-gmagick

Unfortunate there's an issue in the asciidoctor stack itself which means it can't deal properly with remote URLs that don't have file format suffixes (.svg, .jpg, etc.) but otherwise it works. The asciidoctor attribute '-a allow-uri-read' must be set for this to work.

According to https://gitlab.khronos.org/sycl/Specification/-/merge_requests/565#note_285846 and https://gitlab.khronos.org/sycl/Specification/-/issues/454#note_285542 I think some packages could be added.

To repository owners: please rename the default branch of this repository from 'master' to 'main', using the Github renaming tool. This request is per policy set by the Khronos Promoters in May 2021, to follow Github community practice for respectful naming.

The Github renaming tool sets up URL redirections and retargets outstanding pull requests, so the impact on repository users is minimal. The most visible issue is that people with local repo clones will probably want to rename their clone's 'master' branch, following the popup instructions that will be seen when browsing the github repository after the change; or just delete 'master' and pull the new 'main', if it's purely a tracker with no local content.

You may wish to coordinate with @outofcontrol if you are doing auto-updates from this repository to another location, whether via push/pull mirroring or other mechanisms. The redirects setup by Github should accommodate most such uses transparently, but it's still good practice.

Based on experience with other KhronosGroup repositories which have undergone this renaming already, this is a reasonable approach:

• Agree on a date for the renaming within the Working Group or other owners of the repository, and document that date here.
  • Date can be adjusted to avoid interaction with major releases in flight.
• Provide notice to repository users outside Khronos, insofar as possible (adding a comment in the repo README with the switchover date is one way).
• Once the renaming is done, edit the new 'main' branch to replace hardwired references to 'master' with (preferably) 'default branch' or 'main'.
• Update the repo README to note the change.

If you have questions or issues about this, please raise them on Khronos internal gitlab 'khronos-general' issue 106 if possible. If not possible, you can @-tag me here.

While we will not force any WG into acting precipitously, this is our agreed policy. Please try to accommodate renaming relatively soon.

Note that this issue is automatically generated, due to the large number of KhronosGroup repositories it's being raised in.