Skip irrelevant submodules when building on Arch by Tea23 · Pull Request #817 · LizardByte/Sunshine

Tea23 · 2023-01-23T03:57:18Z

Description

The ffmpeg submodules are quite large, so pulling them in when building on Arch adds some unnecessary extra time to the build. When building on Arch, we're only interested in ffpmeg-linux-x86_64 and the others are not used at all.

Arguably we could conditionally pull ffpmeg-linux-aarch64 instead of its x86_64 counterpart when building for / on aarch64, but because arch doesn't specify aarch64 as a valid architecture for this package, there's no real need.

Screenshot

N/A

Issues Fixed or Closed

N/A

Type of Change

Bug fix (non-breaking change which fixes an issue)
New feature (non-breaking change which adds functionality)
Breaking change (fix or feature that would cause existing functionality to not work as expected)
Dependency update (updates to dependencies)
Documentation update (changes to documentation)
Repository update (changes to repository files, e.g. .github/...)

Checklist

My code follows the style guidelines of this project
I have performed a self-review of my own code
I have commented my code, particularly in hard-to-understand areas
I have added or updated the in code docstring/documentation-blocks for new or existing methods/components

Branch Updates

LizardByte requires that branches be up-to-date before merging. This means that after any PR is merged, this branch
must be updated before it can be merged. You must also
Allow edits from maintainers.

I want maintainers to keep my branch updated

v0.15.0

v0.15.0 resubmit

v0.16.0

v0.17.0

The ffmpeg submodules are quite large, so pulling them in when building on Arch adds some unnecessary extra time to the build. When building on Arch, we're only interested in `ffpmeg-linux-x86_64` and the others are not used at all. Arguably we could conditionally pull `ffpmeg-linux-aarch64` instead of its x86_64 counterpart when building for / on aarch64, but because `arch` doesn't specify aarch64 as a valid architecture for this package, there's no real need.

CLAassistant · 2023-01-23T03:57:27Z

All committers have signed the CLA.

github-actions · 2023-01-23T03:57:32Z

Your PR was set to master, PRs should be sent to nightly.
The base branch of this PR has been automatically changed to nightly.
Please check that there are no merge conflicts

ReenigneArcher · 2023-01-23T13:39:23Z

Thank you for your submission.

Arguably we could conditionally pull ffpmeg-linux-aarch64 instead of its x86_64 counterpart when building for / on aarch64, but because arch doesn't specify aarch64 as a valid architecture for this package, there's no real need.

I was planning to enable this for aarch64, but as far as I could find all the dependencies are not available for arm64. Perhaps I am searching wrong, but when I search for avahi for example, it just shows x86_64... https://archlinux.org/packages/?sort=&q=avahi&maintainer=&flagged=

In fact, arm64/aarch64 is not even listed as a possible architecture.

Tea23 · 2023-01-23T15:02:37Z

Strictly speaking, Arch only supports x86_64 and so they don't list alternative architectures on the official AUR. The arch parameter in a PKGBUILD specifies which architectures the package maintainer deems it to be compatible with, but the upstream distro itself will only support/endorse/etc x86_64. aarch64 and i686 are supplied by separate projects (https://archlinuxarm.org/ and https://archlinux32.org/).

Nothing stops you from defining i686 and/or aarch64 in arch, you just forfeit any distro level support and have to take it on yourself. If we do want this package to build on aarch64, we'd need to adjust the prepare section to conditionally pull the appropriate submodule.

ReenigneArcher · 2023-01-23T16:13:53Z

Strictly speaking, Arch only supports x86_64 and so they don't list alternative architectures on the official AUR. The arch parameter in a PKGBUILD specifies which architectures the package maintainer deems it to be compatible with, but the upstream distro itself will only support/endorse/etc x86_64. aarch64 and i686 are supplied by separate projects (https://archlinuxarm.org/ and https://archlinux32.org/).
Nothing stops you from defining i686 and/or aarch64 in arch, you just forfeit any distro level support and have to take it on yourself. If we do want this package to build on aarch64, we'd need to adjust the prepare section to conditionally pull the appropriate submodule.

Okay, would you mind making the adjustment, as well as adding aarch64 to the arch parameter?

Tea23 · 2023-01-24T01:07:50Z

@ReenigneArcher Sure, although you may want to remove i686 altogether, there only seems to be x86_64 and aarch64 ffpmeg submodules so sunshine may not build in i686 at all.

The default behaviour will pull all submodules, because honestly it'd be impressive if someone got that far at all!

ReenigneArcher · 2023-01-24T02:43:29Z

you may want to remove i686 altogether

That's fine with me as well.

KuleRucket · 2023-03-10T07:21:29Z

You have most commands in the if/else block repeating for every branch.

All of this could simply be outside the if block:

 git -c submodule."ffmpeg-macos-x86_64".update=none \
-c submodule."ffmpeg-windows-x86_64".update=none \
-c submodule."ffmpeg-macos-aarch64".update=none \
submodule update --recursive --init

ReenigneArcher · 2023-03-10T12:05:29Z

@KuleRucket then it would grab non architecture specific submodules in all cases.

KuleRucket · 2023-03-10T15:10:43Z

The final commit is OK. I was looking at the one before that had the same in the else block.

Tea23 · 2023-01-23T03:57:18Z

Description

The ffmpeg submodules are quite large, so pulling them in when building on Arch adds some unnecessary extra time to the build. When building on Arch, we're only interested in ffpmeg-linux-x86_64 and the others are not used at all.

Arguably we could conditionally pull ffpmeg-linux-aarch64 instead of its x86_64 counterpart when building for / on aarch64, but because arch doesn't specify aarch64 as a valid architecture for this package, there's no real need.

Screenshot

N/A

Issues Fixed or Closed

N/A

Type of Change

Bug fix (non-breaking change which fixes an issue)
New feature (non-breaking change which adds functionality)
Breaking change (fix or feature that would cause existing functionality to not work as expected)
Dependency update (updates to dependencies)
Documentation update (changes to documentation)
Repository update (changes to repository files, e.g. .github/...)

Checklist

My code follows the style guidelines of this project
I have performed a self-review of my own code
I have commented my code, particularly in hard-to-understand areas
I have added or updated the in code docstring/documentation-blocks for new or existing methods/components

Branch Updates

LizardByte requires that branches be up-to-date before merging. This means that after any PR is merged, this branch
must be updated before it can be merged. You must also
Allow edits from maintainers.

I want maintainers to keep my branch updated

v0.15.0

v0.15.0 resubmit

v0.16.0

v0.17.0

The ffmpeg submodules are quite large, so pulling them in when building on Arch adds some unnecessary extra time to the build. When building on Arch, we're only interested in `ffpmeg-linux-x86_64` and the others are not used at all. Arguably we could conditionally pull `ffpmeg-linux-aarch64` instead of its x86_64 counterpart when building for / on aarch64, but because `arch` doesn't specify aarch64 as a valid architecture for this package, there's no real need.

CLAassistant · 2023-01-23T03:57:27Z

All committers have signed the CLA.

github-actions · 2023-01-23T03:57:32Z

Your PR was set to master, PRs should be sent to nightly.
The base branch of this PR has been automatically changed to nightly.
Please check that there are no merge conflicts

ReenigneArcher · 2023-01-23T13:39:23Z

Thank you for your submission.

Arguably we could conditionally pull ffpmeg-linux-aarch64 instead of its x86_64 counterpart when building for / on aarch64, but because arch doesn't specify aarch64 as a valid architecture for this package, there's no real need.

I was planning to enable this for aarch64, but as far as I could find all the dependencies are not available for arm64. Perhaps I am searching wrong, but when I search for avahi for example, it just shows x86_64... https://archlinux.org/packages/?sort=&q=avahi&maintainer=&flagged=

In fact, arm64/aarch64 is not even listed as a possible architecture.

Tea23 · 2023-01-23T15:02:37Z

Strictly speaking, Arch only supports x86_64 and so they don't list alternative architectures on the official AUR. The arch parameter in a PKGBUILD specifies which architectures the package maintainer deems it to be compatible with, but the upstream distro itself will only support/endorse/etc x86_64. aarch64 and i686 are supplied by separate projects (https://archlinuxarm.org/ and https://archlinux32.org/).

Nothing stops you from defining i686 and/or aarch64 in arch, you just forfeit any distro level support and have to take it on yourself. If we do want this package to build on aarch64, we'd need to adjust the prepare section to conditionally pull the appropriate submodule.

ReenigneArcher · 2023-01-23T16:13:53Z

Strictly speaking, Arch only supports x86_64 and so they don't list alternative architectures on the official AUR. The arch parameter in a PKGBUILD specifies which architectures the package maintainer deems it to be compatible with, but the upstream distro itself will only support/endorse/etc x86_64. aarch64 and i686 are supplied by separate projects (https://archlinuxarm.org/ and https://archlinux32.org/).
Nothing stops you from defining i686 and/or aarch64 in arch, you just forfeit any distro level support and have to take it on yourself. If we do want this package to build on aarch64, we'd need to adjust the prepare section to conditionally pull the appropriate submodule.

Okay, would you mind making the adjustment, as well as adding aarch64 to the arch parameter?

Tea23 · 2023-01-24T01:07:50Z

@ReenigneArcher Sure, although you may want to remove i686 altogether, there only seems to be x86_64 and aarch64 ffpmeg submodules so sunshine may not build in i686 at all.

The default behaviour will pull all submodules, because honestly it'd be impressive if someone got that far at all!

ReenigneArcher · 2023-01-24T02:43:29Z

you may want to remove i686 altogether

That's fine with me as well.

KuleRucket · 2023-03-10T07:21:29Z

You have most commands in the if/else block repeating for every branch.

All of this could simply be outside the if block:

 git -c submodule."ffmpeg-macos-x86_64".update=none \
-c submodule."ffmpeg-windows-x86_64".update=none \
-c submodule."ffmpeg-macos-aarch64".update=none \
submodule update --recursive --init

ReenigneArcher · 2023-03-10T12:05:29Z

@KuleRucket then it would grab non architecture specific submodules in all cases.

KuleRucket · 2023-03-10T15:10:43Z

The final commit is OK. I was looking at the one before that had the same in the else block.

Tea23 · 2023-01-23T03:57:18Z

Description

The ffmpeg submodules are quite large, so pulling them in when building on Arch adds some unnecessary extra time to the build. When building on Arch, we're only interested in ffpmeg-linux-x86_64 and the others are not used at all.

Arguably we could conditionally pull ffpmeg-linux-aarch64 instead of its x86_64 counterpart when building for / on aarch64, but because arch doesn't specify aarch64 as a valid architecture for this package, there's no real need.

Screenshot

N/A

Issues Fixed or Closed

N/A

Type of Change

Bug fix (non-breaking change which fixes an issue)
New feature (non-breaking change which adds functionality)
Breaking change (fix or feature that would cause existing functionality to not work as expected)
Dependency update (updates to dependencies)
Documentation update (changes to documentation)
Repository update (changes to repository files, e.g. .github/...)

Checklist

My code follows the style guidelines of this project
I have performed a self-review of my own code
I have commented my code, particularly in hard-to-understand areas
I have added or updated the in code docstring/documentation-blocks for new or existing methods/components

Branch Updates

LizardByte requires that branches be up-to-date before merging. This means that after any PR is merged, this branch
must be updated before it can be merged. You must also
Allow edits from maintainers.

I want maintainers to keep my branch updated

v0.15.0

v0.15.0 resubmit

v0.16.0

v0.17.0

The ffmpeg submodules are quite large, so pulling them in when building on Arch adds some unnecessary extra time to the build. When building on Arch, we're only interested in `ffpmeg-linux-x86_64` and the others are not used at all. Arguably we could conditionally pull `ffpmeg-linux-aarch64` instead of its x86_64 counterpart when building for / on aarch64, but because `arch` doesn't specify aarch64 as a valid architecture for this package, there's no real need.

CLAassistant · 2023-01-23T03:57:27Z

All committers have signed the CLA.

github-actions · 2023-01-23T03:57:32Z

Your PR was set to master, PRs should be sent to nightly.
The base branch of this PR has been automatically changed to nightly.
Please check that there are no merge conflicts

ReenigneArcher · 2023-01-23T13:39:23Z

Thank you for your submission.

Arguably we could conditionally pull ffpmeg-linux-aarch64 instead of its x86_64 counterpart when building for / on aarch64, but because arch doesn't specify aarch64 as a valid architecture for this package, there's no real need.

I was planning to enable this for aarch64, but as far as I could find all the dependencies are not available for arm64. Perhaps I am searching wrong, but when I search for avahi for example, it just shows x86_64... https://archlinux.org/packages/?sort=&q=avahi&maintainer=&flagged=

In fact, arm64/aarch64 is not even listed as a possible architecture.

Tea23 · 2023-01-23T15:02:37Z

Strictly speaking, Arch only supports x86_64 and so they don't list alternative architectures on the official AUR. The arch parameter in a PKGBUILD specifies which architectures the package maintainer deems it to be compatible with, but the upstream distro itself will only support/endorse/etc x86_64. aarch64 and i686 are supplied by separate projects (https://archlinuxarm.org/ and https://archlinux32.org/).

Nothing stops you from defining i686 and/or aarch64 in arch, you just forfeit any distro level support and have to take it on yourself. If we do want this package to build on aarch64, we'd need to adjust the prepare section to conditionally pull the appropriate submodule.

ReenigneArcher · 2023-01-23T16:13:53Z

Strictly speaking, Arch only supports x86_64 and so they don't list alternative architectures on the official AUR. The arch parameter in a PKGBUILD specifies which architectures the package maintainer deems it to be compatible with, but the upstream distro itself will only support/endorse/etc x86_64. aarch64 and i686 are supplied by separate projects (https://archlinuxarm.org/ and https://archlinux32.org/).
Nothing stops you from defining i686 and/or aarch64 in arch, you just forfeit any distro level support and have to take it on yourself. If we do want this package to build on aarch64, we'd need to adjust the prepare section to conditionally pull the appropriate submodule.

Okay, would you mind making the adjustment, as well as adding aarch64 to the arch parameter?

Tea23 · 2023-01-24T01:07:50Z

@ReenigneArcher Sure, although you may want to remove i686 altogether, there only seems to be x86_64 and aarch64 ffpmeg submodules so sunshine may not build in i686 at all.

The default behaviour will pull all submodules, because honestly it'd be impressive if someone got that far at all!

ReenigneArcher · 2023-01-24T02:43:29Z

you may want to remove i686 altogether

That's fine with me as well.

KuleRucket · 2023-03-10T07:21:29Z

You have most commands in the if/else block repeating for every branch.

All of this could simply be outside the if block:

 git -c submodule."ffmpeg-macos-x86_64".update=none \
-c submodule."ffmpeg-windows-x86_64".update=none \
-c submodule."ffmpeg-macos-aarch64".update=none \
submodule update --recursive --init

ReenigneArcher · 2023-03-10T12:05:29Z

@KuleRucket then it would grab non architecture specific submodules in all cases.

KuleRucket · 2023-03-10T15:10:43Z

The final commit is OK. I was looking at the one before that had the same in the else block.

Tea23 · 2023-01-23T03:57:18Z

Description

The ffmpeg submodules are quite large, so pulling them in when building on Arch adds some unnecessary extra time to the build. When building on Arch, we're only interested in ffpmeg-linux-x86_64 and the others are not used at all.

Arguably we could conditionally pull ffpmeg-linux-aarch64 instead of its x86_64 counterpart when building for / on aarch64, but because arch doesn't specify aarch64 as a valid architecture for this package, there's no real need.

Screenshot

N/A

Issues Fixed or Closed

N/A

Type of Change

Bug fix (non-breaking change which fixes an issue)
New feature (non-breaking change which adds functionality)
Breaking change (fix or feature that would cause existing functionality to not work as expected)
Dependency update (updates to dependencies)
Documentation update (changes to documentation)
Repository update (changes to repository files, e.g. .github/...)

Checklist

My code follows the style guidelines of this project
I have performed a self-review of my own code
I have commented my code, particularly in hard-to-understand areas
I have added or updated the in code docstring/documentation-blocks for new or existing methods/components

Branch Updates

LizardByte requires that branches be up-to-date before merging. This means that after any PR is merged, this branch
must be updated before it can be merged. You must also
Allow edits from maintainers.

I want maintainers to keep my branch updated

v0.15.0

v0.15.0 resubmit

v0.16.0

v0.17.0

The ffmpeg submodules are quite large, so pulling them in when building on Arch adds some unnecessary extra time to the build. When building on Arch, we're only interested in `ffpmeg-linux-x86_64` and the others are not used at all. Arguably we could conditionally pull `ffpmeg-linux-aarch64` instead of its x86_64 counterpart when building for / on aarch64, but because `arch` doesn't specify aarch64 as a valid architecture for this package, there's no real need.

CLAassistant · 2023-01-23T03:57:27Z

All committers have signed the CLA.

github-actions · 2023-01-23T03:57:32Z

Your PR was set to master, PRs should be sent to nightly.
The base branch of this PR has been automatically changed to nightly.
Please check that there are no merge conflicts

ReenigneArcher · 2023-01-23T13:39:23Z

Thank you for your submission.

Arguably we could conditionally pull ffpmeg-linux-aarch64 instead of its x86_64 counterpart when building for / on aarch64, but because arch doesn't specify aarch64 as a valid architecture for this package, there's no real need.

I was planning to enable this for aarch64, but as far as I could find all the dependencies are not available for arm64. Perhaps I am searching wrong, but when I search for avahi for example, it just shows x86_64... https://archlinux.org/packages/?sort=&q=avahi&maintainer=&flagged=

In fact, arm64/aarch64 is not even listed as a possible architecture.

Tea23 · 2023-01-23T15:02:37Z

Strictly speaking, Arch only supports x86_64 and so they don't list alternative architectures on the official AUR. The arch parameter in a PKGBUILD specifies which architectures the package maintainer deems it to be compatible with, but the upstream distro itself will only support/endorse/etc x86_64. aarch64 and i686 are supplied by separate projects (https://archlinuxarm.org/ and https://archlinux32.org/).

Nothing stops you from defining i686 and/or aarch64 in arch, you just forfeit any distro level support and have to take it on yourself. If we do want this package to build on aarch64, we'd need to adjust the prepare section to conditionally pull the appropriate submodule.

ReenigneArcher · 2023-01-23T16:13:53Z

Strictly speaking, Arch only supports x86_64 and so they don't list alternative architectures on the official AUR. The arch parameter in a PKGBUILD specifies which architectures the package maintainer deems it to be compatible with, but the upstream distro itself will only support/endorse/etc x86_64. aarch64 and i686 are supplied by separate projects (https://archlinuxarm.org/ and https://archlinux32.org/).
Nothing stops you from defining i686 and/or aarch64 in arch, you just forfeit any distro level support and have to take it on yourself. If we do want this package to build on aarch64, we'd need to adjust the prepare section to conditionally pull the appropriate submodule.

Okay, would you mind making the adjustment, as well as adding aarch64 to the arch parameter?

Tea23 · 2023-01-24T01:07:50Z

@ReenigneArcher Sure, although you may want to remove i686 altogether, there only seems to be x86_64 and aarch64 ffpmeg submodules so sunshine may not build in i686 at all.

The default behaviour will pull all submodules, because honestly it'd be impressive if someone got that far at all!

ReenigneArcher · 2023-01-24T02:43:29Z

you may want to remove i686 altogether

That's fine with me as well.

KuleRucket · 2023-03-10T07:21:29Z

You have most commands in the if/else block repeating for every branch.

All of this could simply be outside the if block:

 git -c submodule."ffmpeg-macos-x86_64".update=none \
-c submodule."ffmpeg-windows-x86_64".update=none \
-c submodule."ffmpeg-macos-aarch64".update=none \
submodule update --recursive --init

ReenigneArcher · 2023-03-10T12:05:29Z

@KuleRucket then it would grab non architecture specific submodules in all cases.

KuleRucket · 2023-03-10T15:10:43Z

The final commit is OK. I was looking at the one before that had the same in the else block.

Tea23 · 2023-01-23T03:57:18Z

Description

The ffmpeg submodules are quite large, so pulling them in when building on Arch adds some unnecessary extra time to the build. When building on Arch, we're only interested in ffpmeg-linux-x86_64 and the others are not used at all.

Arguably we could conditionally pull ffpmeg-linux-aarch64 instead of its x86_64 counterpart when building for / on aarch64, but because arch doesn't specify aarch64 as a valid architecture for this package, there's no real need.

Screenshot

N/A

Issues Fixed or Closed

N/A

Type of Change

Bug fix (non-breaking change which fixes an issue)
New feature (non-breaking change which adds functionality)
Breaking change (fix or feature that would cause existing functionality to not work as expected)
Dependency update (updates to dependencies)
Documentation update (changes to documentation)
Repository update (changes to repository files, e.g. .github/...)

Checklist

My code follows the style guidelines of this project
I have performed a self-review of my own code
I have commented my code, particularly in hard-to-understand areas
I have added or updated the in code docstring/documentation-blocks for new or existing methods/components

Branch Updates

LizardByte requires that branches be up-to-date before merging. This means that after any PR is merged, this branch
must be updated before it can be merged. You must also
Allow edits from maintainers.

I want maintainers to keep my branch updated

v0.15.0

v0.15.0 resubmit

v0.16.0

v0.17.0

The ffmpeg submodules are quite large, so pulling them in when building on Arch adds some unnecessary extra time to the build. When building on Arch, we're only interested in `ffpmeg-linux-x86_64` and the others are not used at all. Arguably we could conditionally pull `ffpmeg-linux-aarch64` instead of its x86_64 counterpart when building for / on aarch64, but because `arch` doesn't specify aarch64 as a valid architecture for this package, there's no real need.

CLAassistant · 2023-01-23T03:57:27Z

All committers have signed the CLA.

github-actions · 2023-01-23T03:57:32Z

Your PR was set to master, PRs should be sent to nightly.
The base branch of this PR has been automatically changed to nightly.
Please check that there are no merge conflicts

ReenigneArcher · 2023-01-23T13:39:23Z

Thank you for your submission.

Arguably we could conditionally pull ffpmeg-linux-aarch64 instead of its x86_64 counterpart when building for / on aarch64, but because arch doesn't specify aarch64 as a valid architecture for this package, there's no real need.

I was planning to enable this for aarch64, but as far as I could find all the dependencies are not available for arm64. Perhaps I am searching wrong, but when I search for avahi for example, it just shows x86_64... https://archlinux.org/packages/?sort=&q=avahi&maintainer=&flagged=

In fact, arm64/aarch64 is not even listed as a possible architecture.

Tea23 · 2023-01-23T15:02:37Z

Strictly speaking, Arch only supports x86_64 and so they don't list alternative architectures on the official AUR. The arch parameter in a PKGBUILD specifies which architectures the package maintainer deems it to be compatible with, but the upstream distro itself will only support/endorse/etc x86_64. aarch64 and i686 are supplied by separate projects (https://archlinuxarm.org/ and https://archlinux32.org/).

Nothing stops you from defining i686 and/or aarch64 in arch, you just forfeit any distro level support and have to take it on yourself. If we do want this package to build on aarch64, we'd need to adjust the prepare section to conditionally pull the appropriate submodule.

ReenigneArcher · 2023-01-23T16:13:53Z

Strictly speaking, Arch only supports x86_64 and so they don't list alternative architectures on the official AUR. The arch parameter in a PKGBUILD specifies which architectures the package maintainer deems it to be compatible with, but the upstream distro itself will only support/endorse/etc x86_64. aarch64 and i686 are supplied by separate projects (https://archlinuxarm.org/ and https://archlinux32.org/).
Nothing stops you from defining i686 and/or aarch64 in arch, you just forfeit any distro level support and have to take it on yourself. If we do want this package to build on aarch64, we'd need to adjust the prepare section to conditionally pull the appropriate submodule.

Okay, would you mind making the adjustment, as well as adding aarch64 to the arch parameter?

Tea23 · 2023-01-24T01:07:50Z

@ReenigneArcher Sure, although you may want to remove i686 altogether, there only seems to be x86_64 and aarch64 ffpmeg submodules so sunshine may not build in i686 at all.

The default behaviour will pull all submodules, because honestly it'd be impressive if someone got that far at all!

ReenigneArcher · 2023-01-24T02:43:29Z

you may want to remove i686 altogether

That's fine with me as well.

KuleRucket · 2023-03-10T07:21:29Z

You have most commands in the if/else block repeating for every branch.

All of this could simply be outside the if block:

 git -c submodule."ffmpeg-macos-x86_64".update=none \
-c submodule."ffmpeg-windows-x86_64".update=none \
-c submodule."ffmpeg-macos-aarch64".update=none \
submodule update --recursive --init

ReenigneArcher · 2023-03-10T12:05:29Z

@KuleRucket then it would grab non architecture specific submodules in all cases.

KuleRucket · 2023-03-10T15:10:43Z

The final commit is OK. I was looking at the one before that had the same in the else block.

Tea23 · 2023-01-23T03:57:18Z

Description

The ffmpeg submodules are quite large, so pulling them in when building on Arch adds some unnecessary extra time to the build. When building on Arch, we're only interested in ffpmeg-linux-x86_64 and the others are not used at all.

Arguably we could conditionally pull ffpmeg-linux-aarch64 instead of its x86_64 counterpart when building for / on aarch64, but because arch doesn't specify aarch64 as a valid architecture for this package, there's no real need.

Screenshot

N/A

Issues Fixed or Closed

N/A

Type of Change

Bug fix (non-breaking change which fixes an issue)
New feature (non-breaking change which adds functionality)
Breaking change (fix or feature that would cause existing functionality to not work as expected)
Dependency update (updates to dependencies)
Documentation update (changes to documentation)
Repository update (changes to repository files, e.g. .github/...)

Checklist

My code follows the style guidelines of this project
I have performed a self-review of my own code
I have commented my code, particularly in hard-to-understand areas
I have added or updated the in code docstring/documentation-blocks for new or existing methods/components

Branch Updates

LizardByte requires that branches be up-to-date before merging. This means that after any PR is merged, this branch
must be updated before it can be merged. You must also
Allow edits from maintainers.

I want maintainers to keep my branch updated

v0.15.0

v0.15.0 resubmit

v0.16.0

v0.17.0

The ffmpeg submodules are quite large, so pulling them in when building on Arch adds some unnecessary extra time to the build. When building on Arch, we're only interested in `ffpmeg-linux-x86_64` and the others are not used at all. Arguably we could conditionally pull `ffpmeg-linux-aarch64` instead of its x86_64 counterpart when building for / on aarch64, but because `arch` doesn't specify aarch64 as a valid architecture for this package, there's no real need.

CLAassistant · 2023-01-23T03:57:27Z

All committers have signed the CLA.

github-actions · 2023-01-23T03:57:32Z

Your PR was set to master, PRs should be sent to nightly.
The base branch of this PR has been automatically changed to nightly.
Please check that there are no merge conflicts

ReenigneArcher · 2023-01-23T13:39:23Z

Thank you for your submission.

Arguably we could conditionally pull ffpmeg-linux-aarch64 instead of its x86_64 counterpart when building for / on aarch64, but because arch doesn't specify aarch64 as a valid architecture for this package, there's no real need.

I was planning to enable this for aarch64, but as far as I could find all the dependencies are not available for arm64. Perhaps I am searching wrong, but when I search for avahi for example, it just shows x86_64... https://archlinux.org/packages/?sort=&q=avahi&maintainer=&flagged=

In fact, arm64/aarch64 is not even listed as a possible architecture.

Tea23 · 2023-01-23T15:02:37Z

Strictly speaking, Arch only supports x86_64 and so they don't list alternative architectures on the official AUR. The arch parameter in a PKGBUILD specifies which architectures the package maintainer deems it to be compatible with, but the upstream distro itself will only support/endorse/etc x86_64. aarch64 and i686 are supplied by separate projects (https://archlinuxarm.org/ and https://archlinux32.org/).

Nothing stops you from defining i686 and/or aarch64 in arch, you just forfeit any distro level support and have to take it on yourself. If we do want this package to build on aarch64, we'd need to adjust the prepare section to conditionally pull the appropriate submodule.

ReenigneArcher · 2023-01-23T16:13:53Z

Strictly speaking, Arch only supports x86_64 and so they don't list alternative architectures on the official AUR. The arch parameter in a PKGBUILD specifies which architectures the package maintainer deems it to be compatible with, but the upstream distro itself will only support/endorse/etc x86_64. aarch64 and i686 are supplied by separate projects (https://archlinuxarm.org/ and https://archlinux32.org/).
Nothing stops you from defining i686 and/or aarch64 in arch, you just forfeit any distro level support and have to take it on yourself. If we do want this package to build on aarch64, we'd need to adjust the prepare section to conditionally pull the appropriate submodule.

Okay, would you mind making the adjustment, as well as adding aarch64 to the arch parameter?

Tea23 · 2023-01-24T01:07:50Z

@ReenigneArcher Sure, although you may want to remove i686 altogether, there only seems to be x86_64 and aarch64 ffpmeg submodules so sunshine may not build in i686 at all.

The default behaviour will pull all submodules, because honestly it'd be impressive if someone got that far at all!

ReenigneArcher · 2023-01-24T02:43:29Z

you may want to remove i686 altogether

That's fine with me as well.

KuleRucket · 2023-03-10T07:21:29Z

You have most commands in the if/else block repeating for every branch.

All of this could simply be outside the if block:

 git -c submodule."ffmpeg-macos-x86_64".update=none \
-c submodule."ffmpeg-windows-x86_64".update=none \
-c submodule."ffmpeg-macos-aarch64".update=none \
submodule update --recursive --init

ReenigneArcher · 2023-03-10T12:05:29Z

@KuleRucket then it would grab non architecture specific submodules in all cases.

KuleRucket · 2023-03-10T15:10:43Z

The final commit is OK. I was looking at the one before that had the same in the else block.

Tea23 · 2023-01-23T03:57:18Z

Description

The ffmpeg submodules are quite large, so pulling them in when building on Arch adds some unnecessary extra time to the build. When building on Arch, we're only interested in ffpmeg-linux-x86_64 and the others are not used at all.

Arguably we could conditionally pull ffpmeg-linux-aarch64 instead of its x86_64 counterpart when building for / on aarch64, but because arch doesn't specify aarch64 as a valid architecture for this package, there's no real need.

Screenshot

N/A

Issues Fixed or Closed

N/A

Type of Change

Bug fix (non-breaking change which fixes an issue)
New feature (non-breaking change which adds functionality)
Breaking change (fix or feature that would cause existing functionality to not work as expected)
Dependency update (updates to dependencies)
Documentation update (changes to documentation)
Repository update (changes to repository files, e.g. .github/...)

Checklist

My code follows the style guidelines of this project
I have performed a self-review of my own code
I have commented my code, particularly in hard-to-understand areas
I have added or updated the in code docstring/documentation-blocks for new or existing methods/components

Branch Updates

LizardByte requires that branches be up-to-date before merging. This means that after any PR is merged, this branch
must be updated before it can be merged. You must also
Allow edits from maintainers.

I want maintainers to keep my branch updated

v0.15.0

v0.15.0 resubmit

v0.16.0

v0.17.0

The ffmpeg submodules are quite large, so pulling them in when building on Arch adds some unnecessary extra time to the build. When building on Arch, we're only interested in `ffpmeg-linux-x86_64` and the others are not used at all. Arguably we could conditionally pull `ffpmeg-linux-aarch64` instead of its x86_64 counterpart when building for / on aarch64, but because `arch` doesn't specify aarch64 as a valid architecture for this package, there's no real need.

CLAassistant · 2023-01-23T03:57:27Z

All committers have signed the CLA.

github-actions · 2023-01-23T03:57:32Z

Your PR was set to master, PRs should be sent to nightly.
The base branch of this PR has been automatically changed to nightly.
Please check that there are no merge conflicts

ReenigneArcher · 2023-01-23T13:39:23Z

Thank you for your submission.

Arguably we could conditionally pull ffpmeg-linux-aarch64 instead of its x86_64 counterpart when building for / on aarch64, but because arch doesn't specify aarch64 as a valid architecture for this package, there's no real need.

I was planning to enable this for aarch64, but as far as I could find all the dependencies are not available for arm64. Perhaps I am searching wrong, but when I search for avahi for example, it just shows x86_64... https://archlinux.org/packages/?sort=&q=avahi&maintainer=&flagged=

In fact, arm64/aarch64 is not even listed as a possible architecture.

Tea23 · 2023-01-23T15:02:37Z

Strictly speaking, Arch only supports x86_64 and so they don't list alternative architectures on the official AUR. The arch parameter in a PKGBUILD specifies which architectures the package maintainer deems it to be compatible with, but the upstream distro itself will only support/endorse/etc x86_64. aarch64 and i686 are supplied by separate projects (https://archlinuxarm.org/ and https://archlinux32.org/).

Nothing stops you from defining i686 and/or aarch64 in arch, you just forfeit any distro level support and have to take it on yourself. If we do want this package to build on aarch64, we'd need to adjust the prepare section to conditionally pull the appropriate submodule.

ReenigneArcher · 2023-01-23T16:13:53Z

Strictly speaking, Arch only supports x86_64 and so they don't list alternative architectures on the official AUR. The arch parameter in a PKGBUILD specifies which architectures the package maintainer deems it to be compatible with, but the upstream distro itself will only support/endorse/etc x86_64. aarch64 and i686 are supplied by separate projects (https://archlinuxarm.org/ and https://archlinux32.org/).
Nothing stops you from defining i686 and/or aarch64 in arch, you just forfeit any distro level support and have to take it on yourself. If we do want this package to build on aarch64, we'd need to adjust the prepare section to conditionally pull the appropriate submodule.

Okay, would you mind making the adjustment, as well as adding aarch64 to the arch parameter?

Tea23 · 2023-01-24T01:07:50Z

@ReenigneArcher Sure, although you may want to remove i686 altogether, there only seems to be x86_64 and aarch64 ffpmeg submodules so sunshine may not build in i686 at all.

The default behaviour will pull all submodules, because honestly it'd be impressive if someone got that far at all!

ReenigneArcher · 2023-01-24T02:43:29Z

you may want to remove i686 altogether

That's fine with me as well.

KuleRucket · 2023-03-10T07:21:29Z

You have most commands in the if/else block repeating for every branch.

All of this could simply be outside the if block:

 git -c submodule."ffmpeg-macos-x86_64".update=none \
-c submodule."ffmpeg-windows-x86_64".update=none \
-c submodule."ffmpeg-macos-aarch64".update=none \
submodule update --recursive --init

ReenigneArcher · 2023-03-10T12:05:29Z

@KuleRucket then it would grab non architecture specific submodules in all cases.

KuleRucket · 2023-03-10T15:10:43Z

The final commit is OK. I was looking at the one before that had the same in the else block.

Tea23 · 2023-01-23T03:57:18Z

Description

The ffmpeg submodules are quite large, so pulling them in when building on Arch adds some unnecessary extra time to the build. When building on Arch, we're only interested in ffpmeg-linux-x86_64 and the others are not used at all.

Arguably we could conditionally pull ffpmeg-linux-aarch64 instead of its x86_64 counterpart when building for / on aarch64, but because arch doesn't specify aarch64 as a valid architecture for this package, there's no real need.

Screenshot

N/A

Issues Fixed or Closed

N/A

Type of Change

Bug fix (non-breaking change which fixes an issue)
New feature (non-breaking change which adds functionality)
Breaking change (fix or feature that would cause existing functionality to not work as expected)
Dependency update (updates to dependencies)
Documentation update (changes to documentation)
Repository update (changes to repository files, e.g. .github/...)

Checklist

My code follows the style guidelines of this project
I have performed a self-review of my own code
I have commented my code, particularly in hard-to-understand areas
I have added or updated the in code docstring/documentation-blocks for new or existing methods/components

Branch Updates

LizardByte requires that branches be up-to-date before merging. This means that after any PR is merged, this branch
must be updated before it can be merged. You must also
Allow edits from maintainers.

I want maintainers to keep my branch updated

v0.15.0

v0.15.0 resubmit

v0.16.0

v0.17.0

The ffmpeg submodules are quite large, so pulling them in when building on Arch adds some unnecessary extra time to the build. When building on Arch, we're only interested in `ffpmeg-linux-x86_64` and the others are not used at all. Arguably we could conditionally pull `ffpmeg-linux-aarch64` instead of its x86_64 counterpart when building for / on aarch64, but because `arch` doesn't specify aarch64 as a valid architecture for this package, there's no real need.

CLAassistant · 2023-01-23T03:57:27Z

All committers have signed the CLA.

github-actions · 2023-01-23T03:57:32Z

Your PR was set to master, PRs should be sent to nightly.
The base branch of this PR has been automatically changed to nightly.
Please check that there are no merge conflicts

ReenigneArcher · 2023-01-23T13:39:23Z

Thank you for your submission.

Arguably we could conditionally pull ffpmeg-linux-aarch64 instead of its x86_64 counterpart when building for / on aarch64, but because arch doesn't specify aarch64 as a valid architecture for this package, there's no real need.

I was planning to enable this for aarch64, but as far as I could find all the dependencies are not available for arm64. Perhaps I am searching wrong, but when I search for avahi for example, it just shows x86_64... https://archlinux.org/packages/?sort=&q=avahi&maintainer=&flagged=

In fact, arm64/aarch64 is not even listed as a possible architecture.

Tea23 · 2023-01-23T15:02:37Z

Strictly speaking, Arch only supports x86_64 and so they don't list alternative architectures on the official AUR. The arch parameter in a PKGBUILD specifies which architectures the package maintainer deems it to be compatible with, but the upstream distro itself will only support/endorse/etc x86_64. aarch64 and i686 are supplied by separate projects (https://archlinuxarm.org/ and https://archlinux32.org/).

Nothing stops you from defining i686 and/or aarch64 in arch, you just forfeit any distro level support and have to take it on yourself. If we do want this package to build on aarch64, we'd need to adjust the prepare section to conditionally pull the appropriate submodule.

ReenigneArcher · 2023-01-23T16:13:53Z

Strictly speaking, Arch only supports x86_64 and so they don't list alternative architectures on the official AUR. The arch parameter in a PKGBUILD specifies which architectures the package maintainer deems it to be compatible with, but the upstream distro itself will only support/endorse/etc x86_64. aarch64 and i686 are supplied by separate projects (https://archlinuxarm.org/ and https://archlinux32.org/).
Nothing stops you from defining i686 and/or aarch64 in arch, you just forfeit any distro level support and have to take it on yourself. If we do want this package to build on aarch64, we'd need to adjust the prepare section to conditionally pull the appropriate submodule.

Okay, would you mind making the adjustment, as well as adding aarch64 to the arch parameter?

Tea23 · 2023-01-24T01:07:50Z

@ReenigneArcher Sure, although you may want to remove i686 altogether, there only seems to be x86_64 and aarch64 ffpmeg submodules so sunshine may not build in i686 at all.

The default behaviour will pull all submodules, because honestly it'd be impressive if someone got that far at all!

ReenigneArcher · 2023-01-24T02:43:29Z

you may want to remove i686 altogether

That's fine with me as well.

KuleRucket · 2023-03-10T07:21:29Z

You have most commands in the if/else block repeating for every branch.

All of this could simply be outside the if block:

 git -c submodule."ffmpeg-macos-x86_64".update=none \
-c submodule."ffmpeg-windows-x86_64".update=none \
-c submodule."ffmpeg-macos-aarch64".update=none \
submodule update --recursive --init

ReenigneArcher · 2023-03-10T12:05:29Z

@KuleRucket then it would grab non architecture specific submodules in all cases.

KuleRucket · 2023-03-10T15:10:43Z

The final commit is OK. I was looking at the one before that had the same in the else block.

ReenigneArcherand others added 7 commits October 30, 2022 15:05

Merge pull requestLizardByte#332from LizardByte/nightly
660d8e1
v0.15.0

Merge pull requestLizardByte#456from LizardByte/nightly
1e6d9da
v0.15.0 resubmit

Merge pull requestLizardByte#458from LizardByte/nightly
8509ee7
v0.15.0 resubmit

Merge pull requestLizardByte#460from LizardByte/nightly
e1b112c
v0.15.0 resubmit

Merge pull requestLizardByte#467from LizardByte/nightly
08d623c
v0.16.0

Merge pull requestLizardByte#567from LizardByte/nightly
b2fe042
v0.17.0

github-actionsBot changed the base branch from master to nightlyJanuary 23, 2023 03:57

Tea23 added 2 commits January 23, 2023 18:34

Add aarch64 to arch and skip unneeded submodules
3949496
The default behaviour will pull all submodules, because honestly it'd be impressive if someone got that far at all!

Correct variable
85ba065

ReenigneArcher requested changes Jan 26, 2023
View reviewed changes

Comment threadpackaging/linux/aur/PKGBUILD Outdated
Comment threadpackaging/linux/aur/PKGBUILD Outdated

Merge branch 'nightly' into pr/817
bf00a06

LizardByte-bot added the autoupdate label Mar 10, 2023

disable non linux submodules
3022250

ReenigneArcher force-pushed the patch-1 branch from 0cab6a5 to 3022250Compare March 10, 2023 02:49

ReenigneArcher approved these changes Mar 10, 2023
View reviewed changes

ReenigneArcher merged commit bf4ed89 into LizardByte:nightlyMar 10, 2023