Full GPU builds should take 30-40 on windows minutes now
https://wiki.blender.org/wiki/Infrastructure/BuildBot#Notable_Changes

I don't know how be my main reasoning here, I'd rather not spend an hour fighting white space and line endings on windows in a bash script a Linux platform guy would do a better job at in 10 minutes.

Any reasons not to have included needed changes to install_deps here too? they should be trivial (biggest work being to figure out name of libzstd dev package on the supported distros...)?

Alembic 1.8.2 was just released. Shall we target that one instead of 1.8.1? The changes really are minor, and I don't expect they'll even influence Blender, but that way at least we're at the latest version.

Is clang-format an issue big enough to trigger a lib update ? arm mac has LLVM 11.0.1 and other three platforms have 9.x.

Is clang-format an issue big enough to trigger a lib update ?
arm mac has LLVM 11.0.1 and other three platforms have 9.x. That creates some mismatch in formatting:

1. https://stackoverflow.com/questions/65964384/how-to-make-clang-format-11-put-a-space-after-variadic-template-decleration/67724531#67724531 [1]
2. Ternary operator formatting [2]
3. Space before const qualifier [3]

Although I have version 13, at least one of these is present with version 11 too.

rebase

Wiki updated with summary of changes.

The approach has been reworked as discussed with @Brecht Van Lommel (brecht)
Will update Wiki with details during deployment today.

Thanks for the info!!

I did a survey of all libraries, these are correct to the best of my knowledge but mistakes could have slipped in, some of these we can't update because of VFX platform (ie boost), some of these we can't update because of dep requirements on a specific version (ie blosc).

In T88419#1165112, @Óscar (Oxer) wrote:

In T88419#1163720, @Ankit Meel (ankitm) wrote:

@Óscar (Oxer) 2.93, 3.0 arm and intel versions have been updated as of now.
2.83 will be updated in a day. Ping us if it doesn't.

The 2.83.15 LTS is not updated yet.

In T88419#1163720, @Ankit Meel (ankitm) wrote:

@Óscar (Oxer) 2.93, 3.0 arm and intel versions have been updated as of now.
2.83 will be updated in a day. Ping us if it doesn't.

I looked on the old Linux worker machine, OpenMP with pthread was not setup there either.

v283

INFO:root:scl enable devtoolset-9 -- cmake /home/blender/git/blender-v283/blender.git -C/home/blender/git/blender-v283/blender.git/build_files/buildbot/config/blender_linux.cmake -DCMAKE_BUILD_TYPE:STRING=release -DCMAKE_INSTALL_PREFIX=/home/blender/git/blender-v283/install_release -DWITH_GTESTS=ON -DCUDA_BUILD_CUBIN=ON -DWITH_CYCLES_CUDA_BINARIES=ON -DWITH_CYCLES_CUDA_BUILD_SERIAL=OFF -DWITH_CYCLES_NATIVE_ONLY=OFF -DOPTIX_ROOT_DIR:PATH=/home/blender/git/NVIDIA-Optix-SDK-7.0 -DCUDA10_TOOLKIT_ROOT_DIR:PATH=/usr/local/cuda-10.1 -DCUDA10_NVCC_EXECUTABLE:STRING=/usr/local/cuda-10.1/bin/nvcc;-ccbin;/opt/rh/devtoolset-8/root/usr/bin/gcc -DCUDA_TOOLKIT_ROOT_DIR:PATH=/usr/local/cuda-11.3 -DCUDA_NVCC_EXECUTABLE:FILEPATH=/usr/local/cuda-11.3/bin/nvcc.exe
loading initial cache file /home/blender/git/blender-v283/blender.git/build_files/buildbot/config/blender_linux.cmake

The config fie path was updated after the option was added to command line.

Pulse package on the machine, not sure why not linked in.
https://builder.blender.org/admin/#/builders/10/builds/268/steps/6/logs/stdio

I added a filter for to turn into warnings in the logs

Issues ?
OpenMP

-- Could NOT find OpenMP_C (missing: OpenMP_pthread_LIBRARY) (found version "4.5")
-- Could NOT find OpenMP_CXX (missing: OpenMP_pthread_LIBRARY) (found version "4.5")
-- Could NOT find OpenMP (missing: OpenMP_C_FOUND OpenMP_CXX_FOUND)

Jack

-- Could NOT find Jack (missing: JACK_LIBRARY JACK_INCLUDE_DIR)

Anyone know the package names for those on Centos 7 ?

Starting linux builds on all branches.
See if that helps a bit.

Installed pulseaudio on all Centos machines

[blender@pvet-lvm-centos-7-x64-07 ~]$ ldconfig -p | grep -i "gomp"
        libgomp.so.1 (libc6,x86-64) => /lib64/libgomp.so.1

In T88431#1163528, @Brecht Van Lommel (brecht) wrote:

From the logs, I think it's already there.
https://builder.blender.org/admin/#/builders/10/builds/257/steps/6/logs/stdio

However it seems to not find OpenMP and Jack, which is an issue.

@Óscar (Oxer) 2.93, 3.0 arm and intel versions have been updated as of now.
2.83 will be updated in a day. Ping us if it doesn't.

When will 2.83.15, 2.93 Beta & 3.00 Alpha versions available to download with support for macOS 10.13+?

I do need to explain a bit more though.
But that's lengthy discussion.

Can't do that.
That script did not work in certain circumstances.

It was a little easier to track all dep changes in a single verison wide ticket, we can keep this ticket for any additional integration that we want/need to do, but i'd prefer if we did the update process of the lib in T88438

The policy is for library upgrades. Does bumping a version in versions.cmake need to go along with putting a new source package in svn?

Yes, and removal of the old package

Do we need to install missing packages on the machines ?

Ah easy fix this, will check

From the logs, I think it's already there.
https://builder.blender.org/admin/#/builders/10/builds/257/steps/6/logs/stdio

Can we document this? The appropriate wiki page is here:
https://wiki.blender.org/wiki/Building_Blender/Dependencies

I could install PulseAudio if we need it ?

As far as I can tell this is just an error in the work_compile.py in the bdr-devops-core repo.

Can't we just use the make_update.py from the Blender repo, that auto-detects branches?

For branch this output is expected.
Can be reviewed in the update-code step

I guess these could be updated nightly, yes.
This way the artists at the studio don't have to manually trigger builds (that can take a long time to finish for windows)

Thanks @James Monteath (jmonteath)! I can't spend time on this right now unfortunately, but will keep an eye on things.

In T88431#1163473, @James Monteath (jmonteath) wrote:

Ok, I can change the pipeline to always use the correct cmake file.

👍

Do you want this branch to be nightly also ?

I actually fixed an issue regarding how it this was done as it was not working correctly.
I will add a config to override the default being master.
I will run test on your this specific branch.

Yes, I am proposing a change to override cmake option to set the MIN onto the supported version release branch and would only apply when running with buildbot.
We could also ensure the cmake file is correct on all branches instead.

I would prefer to override CMAKE_OSX_DEPLOYMENT_TARGET via new build pipeline that will apply the value across all branches in case this changes again.

As a developer, it might make sense to use that value as current OS. @Sebastián Barschkis (sebbas) would need to confirm this.

std::filesystem (at least partially) std::optional::value(see rB9734a78bc81b0565d605577ea9a9ff9752b50d13) etc are not available for macOS 10.13, they were added in 10.15 and 10.14 respectively. If this suggestion of leaving CMAKE_OSX_DEPLOYMENT_TARGET to current macOS is implemented, someone on a newer OS version will commit code using std::filesystem and break builds for older OSes. Correct CMAKE_OSX_DEPLOYMENT_TARGET and thus correct -mmacosx-version-min=${CMAKE_OSX_DEPLOYMENT_TARGET}") ensures that such errors are caught at build time on that developer's system.

Here is the generated Info.plist file.
Not sure if that value is used.

The legacy and new workers are on Catalina 15.13.7.

Looks like a bug in platform_apple_xcode.cmake so confirming instead of redirecting to devtalk. CMAKE_OSX_DEPLOYMENT_TARGET is set to builder's OS version and is not corrected to be OSX_MIN_DEPLOYMENT_TARGET.

This was fixed few days after this issue was posted

curl https://download.blender.org/release/Blender2.91/blender-2.91.2.sha256
8f1e1e8852750e1038579336c7461c1a5492da973ce188e1e5cae99b2f796a23  blender-2.91.2-linux64.tar.xz
269ae25c10b55d33d311bd6d6519e5b2d5670a607dee0cdefe59afcc16fbc9b6  blender-2.91.2-macOS.dmg
60dbc4fde64e0844f2fd37ac3a16faff62cc55d0807fb3424435a91298ec6e76  blender-2.91.2-windows64.msi
52582e09379c36bd7a26d99ec72cbbe2d1d200773e63e73f57ebfc1c1a5918c4  blender-2.91.2-windows64.zip

In T78710#1161835, @Timothy Cook (CookItOff) wrote:

I see the other versions of Blender have had the fix for the viewport or timeline jumping large distances when "trucking" (cinematography term) the mouse off the screen, for quite a while now; so I'm not going to file a bug report knowing it's been addressed.

There's a newer build here:
https://builder-prod.blender.org/download/daily/

I see the other versions of Blender have had the fix for the viewport or timeline jumping large distances when "trucking" (cinematography term) the mouse off the screen, for quite a while now; so I'm not going to file a bug report knowing it's been addressed.
I would just like to add to the voices to update the master build when possible so this fix can be part of the ARM64 build. This is a super annoying glitch.

I can confirm the patch is not applying cleanly. Clang cleanup by Campbell, see rBc1c0b661c01 (some unwanted accidental changes by my last commit)

Requesting changes since some tests are not passing on latest master on macOS

Testing from a fresh build from today's master (with WITH_BULLET enabled) I'm getting a few problems:

1. I can't apply the patch cleanly. Rebasing on latest master and submitting with arc should solve the problem. To test the patch I added the new tests manually.
2. Tests CubeConvexHull and MonkeyConvexHull are failing with error: 'Loop Vert Mismatch In Poly Test'

In T78710#1149187, @Leon Zandman (lzandman) wrote:

I see this is all committed to master branch. However, I'm unable to build it myself on my M1 system. I'm simply following the "Building Blender for macOS" instructions. Am I missing something?

Today I decided to completely delete the Blender repository and related stuff (the Blender-git folder) and do a fresh checkout and build of the source code. To my surprise I again stumbled upon the fact that the build failed, because the darwin_arm64 libraries weren't downloaded. I decided to look into the matter and it turned out that my system somehow has both an Intel and an ARM version of Python3 installed. And the Blender make update target used the Intel version. So the call to platform.machine() returned x86_64, which caused the wrong libs to get downloaded.

Thanks devs for working on this!

Can we please get a new alpha build? Blender keeps crashing, not sure if a new M1 build would fix this.

Thanks, Brecht. The issue is now in reported in T88241.

Please report any bugs to their own reports, it's easier to keep track that way and ensure it gets looked at by the right developer.

Note for the person who commits it:
I think it would be good to mention a comment above convex_hull like "WITH_BULLET flag should be enabled while testing."

is there an exactness to what the mesh coordinates are supposed to be?

Afaik, no there isn't a fixed distance between objects. Purely from observation, from a zoomed out level, one blender cell contains approximately 2 sets of tests.

Fixed missing formatting change in some operators