This changes the following items:
- package name is now `blender-3.0.0-git.09eb04c0a865-windows64`
rather than `blender-3.00.0-git.09eb04c0a865-windows64`
- Fix version resource for blender.exe not building
- Data directories are now `3.0\...` rather than `3.00\....`
- User prefs are now in:
`c:\Users\users\AppData\Roaming\Blender Foundation\Blender\3.0\`
rather than:
`c:\Users\users\AppData\Roaming\Blender Foundation\Blender\3.00\`
- Updating startup & preferences from previous release
has a special exception for 3.0 to check for 3.93 and older.
See T87532
Ref D10986
Building RC builds would parse `BLENDER_VERSION_CYCLE_NUMBER` that
doesn't exist anymore. It was removed by {D7748}.
This change removes it from `buildbot_utils.py`.
This means that NVIDIA driver version 450 or newer is now required for Cycles
OptiX rendering. This upgrade is required to take advantage of new features and
improvements.
Ref T81431
This reverts commit 9d172f007e.
Got a second thought and remembered why it was not done in the first place.
The issue here is that the server needs to communicate codesign result back
and that must happen within the new protocol. So if the client talks old
protocol it is possible to receieve data from it, but is not possible to
communicate result back to it.
Pass codesign errors (if any) from codesign buildbot server to the
buildbot worker, so that the latter one can abort build process if
the error happens. This solves issues when non-properly-notarized
DMG package gets uploaded to the buildbot website.
With this patch the build system checks whether the "CUDA10_NVCC_EXECUTABLE" CMake
variable is set and if so will use that to build sm_30 kernels. Similarily for sm_8x kernels it
checks "CUDA11_NVCC_EXECUTABLE". All other kernels are built using the default CUDA
toolkit. This makes it possible to use either the CUDA 10 or CUDA 11 toolkit by default and
only selectively use the other for the kernels where its a hard requirement.
Reviewed By: brecht
Differential Revision: https://developer.blender.org/D9179
Solves problem with different order of codesign server startup and
mount of network shares: avoids exception happening when server is
started prior to the mounts are ready.
Is achieved by replacing hard-coded signed/unsigned file names with
"<uuid>" which acts as a "request ID". This way multiple workers can
put their requests into a single directory without collisions. The
code sign server will handle the requests sequentially in an unknown
order.
The directory layout on worker goes as following:
<Worker>
<Builder Name>
blender.git/
build/
install/
lib/
Adding an extra <Builder Name> after build is redundant.
Differential Revision: https://developer.blender.org/D8045
The file subversion is no longer used in the Python API or user interface,
and is now internal to Blender.
User interface, Python API and file I/O metadata now use more consistent
formatting for version numbers. Official releases use "2.83.0", "2.83.1",
and releases under development use "2.90.0 Alpha", "2.90.0 Beta".
Some Python add-ons may need to lower the Blender version in bl_info to
(2, 83, 0) or (2, 90, 0) if they used a subversion number higher than 0.
https://wiki.blender.org/wiki/Reference/Release_Notes/2.83/Python_API#Compatibility
This change is in preparation of LTS releases, and also brings us more
in line with semantic versioning.
Fixes T76058.
Differential Revision: https://developer.blender.org/D7748
Seems like sometimes files are being only partially ready, which makes it so there
are unsigned files, failing to deliver fully signed bundle.
Now expected archive file size is stored into stamp file and is checked against
size of the archive file on another side.
There are some bare prints used for debugging, would need to switch it to a proper
logger (or to be removed).
From looking into builder's logs it seems that stamp file is picked
up prior to actual archive: sometimes worker reports missing archive
file, from a code path which is only possible if there is a stamp file.
Could be something with IO scheduling where bigger file is sent to
Samba server after smaller file.
Hopefully with this change this will not happen anymore.
It changes name to be blender-<version>-linux64.
Since CentOS is used as a base host for builds there is no real need
in specifying libc version. Is unlikely anything older could be used
anyway.
Also make bitness to be the same as windows. It is something what
users will read easier.
xz compresses 25% better than bz2, reducing download times and server load.
The numbers:
blender-2.80-linux-glibc217-x86_64.tar.bz2 (release): 134 886 174 bytes
with xz: 96 181 604 bytes (-28.7%)
with xz -9: 93 871 548 bytes (-30.4%)
blender-2.81-7c1fbe24ca33-linux-glibc217-x86_64.tar.bz2 (beta): 173 600 363 bytes
with xz: 133 100 664 bytes (-23.3%)
with xz -9: 129 534 124 bytes (-25.4%)
xz also decompresses more than twice as fast as bz2, however compression needs
four times as long (on my 7-year-old laptop 3-4 minutes instead of <1).
Also xz has become more common than bz2, e.g. Debian/Ubuntu deb packages have
been xz-compressed for years, so the dpkg package manager as well as systemd
and grub all depend on liblzma being present, whereas bz2 is becoming more and
more optional.
Current Linux archives also include the UID/GID of whatever user account
happens to be used for building by the blender.org infrastructure. If someone
then installs these archives as root e.g. to /usr/local/... and doesn't pay
full attention the files remain owned by a regular user, which is a serious
security issue. This patch fixes that by setting the UID/GID to 0.
Differential Revision: https://developer.blender.org/D6138
The script requires Python 3.7 as a very minimum, and CentOS is
only 3.6.
On macOC there was an access to a None object, due to missing
implementation of code signer on this platform.
This changes integrates code signing steps into a buildbot worker
process.
The configuration requires having a separate machine running with
a shared folder access between the signing machine and worker machine.
Actual signing is happening as a "POST-INSTALL" script run by CMake,
which allows to sign any binary which ends up in the final bundle.
Additionally, such way allows to avoid signing binaries in the build
folder (if we were signing as a built process, which iwas another
alternative).
Such complexity is needed on platforms which are using CPack to
generate final bundle: CPack runs INSTALL target into its own location,
so it is useless to run signing on a folder which is considered INSTALL
by the buildbot worker.
There is a signing script which can be used as a standalone tool,
making it possible to hook up signing for macOS's bundler.
There is a dummy Linux signer implementation, which can be activated
by returning True from mock_codesign in linux_code_signer.py.
Main purpose of this signer is to give an ability to develop the
scripts on Linux environment, without going to Windows VM.
The code is based on D6036 from Nathan Letwory.
Differential Revision: https://developer.blender.org/D6216
This wasn't an issue in the real buildbot environment since the
precompiled libraries are compiled with same ABI as the compiler
used for Blender build. But it was causing issues when building
Blender using buildbot scripts (for troubleshooting purposes)
on a machine with different default compiler ABI.
Usually ABI detection is happening in platform_unix.cmake when
detecting whether there are any precompiled libraries folder
available. This detection is not happening when library folder
is provided explicitly, expecting ABI to be setup explicitly
as well.
