Skip to content

Conversation

@Rutpiv
Copy link
Contributor

@Rutpiv Rutpiv commented Jan 3, 2026

Testing the changes

  • I tested the changes in this PR: briefly

Local build testing

  • I built this PR locally for my native architecture (x86_64)
  • I built this PR locally for these architectures using specific masterdirs:
    • x86_64-musl
    • i686
  • I built this PR locally for these architectures (crossbuilds):
    • aarch64
    • aarch64-musl
    • armv7l
    • armv7l-musl
    • armv6l
    • armv6l-musl

@Rutpiv Rutpiv changed the title Gstreamer gstreamer: update to 1.26.10 Jan 3, 2026
@Rutpiv
Copy link
Contributor Author

Rutpiv commented Jan 3, 2026

While looking into the CI failure, I noticed that xlint flags qmake_default_version as a custom variable, even though this variable is already part of the qmake build-helper workflow.

qmake_default_version is referenced in:

  • the qmake5.sh and qmake6.sh build-helpers
  • the sourcepkg.sh environment setup script

However, it does not seem to be recognized by xlint’s variable whitelist, which results in a warning when it is set in the template.

What would be the preferred way forward here?

  • Add qmake_default_version to xlint’s recognized variables
  • Keep the template as-is, since this variable has historically been used this way
  • Or adopt another approach that maintainers consider more appropriate

I’m happy to adjust the template or make a follow-up modification based on the preferred approach.

@classabbyamp
Copy link
Member

if it's used by a build style, it should be in xlint

@Rutpiv
Copy link
Contributor Author

Rutpiv commented Jan 4, 2026

Thanks for confirming. I’ll follow up with a PR to update xlint to recognize qmake_default_version.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants