|
0efc4858
|
2020-11-09T18:55:21
|
|
Merge branch 'master' into dev
|
|
02227e48
|
2020-11-09T16:31:49
|
|
Travis: Combine PPC/Arm tests with jpeg-7/8 tests
There is no reason not to, since the jpeg-7 and jpeg-8 API/ABI tests do
not exercise the SIMD extensions any differently than the other tests.
|
|
c7dd1912
|
2020-11-08T15:15:02
|
|
Merge branch 'master' into dev
|
|
a524b9b0
|
2020-11-06T17:24:16
|
|
Travis: Regression-test Armv8 and PPC SIMD exts
Currently this only tests the 64-bit code paths, but it's better than
nothing.
|
|
4c5a15c3
|
2020-06-25T19:08:19
|
|
Eliminate 32-bit Mac build/packaging support
The scales have now tilted overwhelmingly in favor of eliminating
support for 32-bit Macs:
- 32-bit applications are only necessary in order to support OS X 10.5
"Leopard" and OS X 10.6 "Snow Leopard". OS X 10.7 "Lion" requires a
64-bit Mac and supports all 64-bit Macs.
- 32-bit applications are no longer allowed in the macOS App Store.
- 32-bit applications no longer run in macOS 10.15 "Catalina".
- 32-bit applications do not support thread-local storage, so the
TurboJPEG API library's global error handler is not thread-safe with
such applications.
- libjpeg-turbo 2.1.x no longer supports 32-bit iOS apps, so it makes
sense to also eliminate support for 32-bit macOS applications.
It's time.
|
|
b8a7680e
|
2019-12-05T22:38:05
|
|
Merge branch 'master' into dev
|
|
52291467
|
2019-12-05T21:25:20
|
|
Travis: Use MacPorts instead of Homebrew
Homebrew tends to drop support for a macOS release the second that Apple
stops releasing security updates for it, and that makes HB difficult to
use with some of the Travis macOS images. Furthermore, even on
supported macOS releases, HB sometimes tries to build GCC from source
even if a binary (bottle) is available. Long story short, MacPorts just
generally has better backward compatibility. MacPorts is also what I
personally use on the official libjpeg-turbo build machine.
|
|
713c451f
|
2019-11-08T14:53:55
|
|
Enable SSE2 progressive Huffman encoder for x32
Referring to #289, I'm not sure where I arrived at the conclusion that
the SSE2 progressive Huffman encoder doesn't provide any speedup for
x32. Upon re-testing, I discovered it to be about 50% faster than the
C encoder.
This commit also re-purposes one of the CI tests (specifically, the
jpeg-7 API/ABI test) so that it tests x32 as well.
|
|
f2d4b473
|
2019-11-07T02:13:09
|
|
Travis: Use Docker tag that matches Git branch
dcommander/buildljt:dev is a CentOS 6 container with YASM 1.2.0 rather
than NASM 2.10, so it can build the new optimized SSE2 Huffman encoder.
|
|
8ef53b10
|
2019-08-14T22:08:59
|
|
Merge branch 'master' into dev
|
|
02f7bcdb
|
2019-08-13T16:03:48
|
|
Travis: Enable additional sanitizer tests
- Re-purpose the non-SIMD test to test with MSan as well.
- Re-purpose the ASan test to test with UBSan as well.
- Use the default Travis build environment rather than specifying Ubuntu
14.04. I think I added 'dist: trusty' back when 14.04 was newer than
the default, but now it's older than the default.
- Enable verbose output for any unit tests that fail (so we can see the
sanitizer output.)
|
|
7fbfe29c
|
2019-07-18T15:18:27
|
|
Merge branch 'master' into dev
|
|
5ced1f59
|
2019-07-18T14:25:25
|
|
Travis: Cache Homebrew downloads
... to speed up the Mac CI builds.
|
|
b98ee192
|
2019-07-18T14:14:47
|
|
Travis: Update Homebrew/fix Mac CI build
Updating Homebrew wasn't necessary when the CI build first started using
the xcode8.3 image (see c8e52741fdb623698a27a4c55cf63db93c95aa14), but
apparently it now is.
|
|
051f4862
|
2019-05-09T20:46:18
|
|
Travis: Fix iOS build
The new libjpeg-turbo 2.1.x official build scripts expect Xcode to be
under /Applications/Xcode83.app.
|
|
c8e52741
|
2019-05-09T09:11:09
|
|
Travis: Use xcode8.3 image
xcode7.3 is based on El Capitan, which is EOL, and Homebrew no longer
provides El Cap bottles (pre-compiled binaries.) Thus, Homebrew was
trying to build GCC 5, YASM, and the other packages we need from source,
which caused the Mac CI builds to time out. I tried goading Homebrew
into installing GCC 5.5.0_2 and YASM 1.3.0_1, which still have El Cap
bottles available, by using the URLs of those specific versions of the
formulae (from the Homebrew GitHub repository) as package names. This
failed, however, because 'brew bundle' converted the URLs to all
lowercase. I then tried explicitly installing the old formulae by using
'brew install' with the aforementioned URLs (bypassing the Travis
Homebrew addon), but Homebrew still tried to build all of the
dependencies from source.
Upgrading to Xcode 8.3.x necessitated regression testing the performance
on iOS, but that proved less of a pain than figuring out how to install
all of the old Homebrew bottles we needed. Also, this future-proofs the
CI builds against the inevitable discontinuation of the xcode7.3 image.
Note that Xcode 8.3.x improves iOS 64-bit decompression performance
significantly relative to Xcode 7.2.x or 7.3.x. iOS 32-bit performance
unfortunately regresses by as much as 5%, but it can't be helped (32-bit
iOS apps are no longer supported on iOS 11+ anyhow, and the next major
release of libjpeg-turbo will remove support for them as well.)
|
|
9bc8eb64
|
2019-01-01T19:36:03
|
|
Travis: Use Homebrew addon to improve performance
|
|
aa829dcf
|
2018-11-20T22:52:36
|
|
Travis: Fetch GPG key from libjpeg-turbo.org
I give up on the public keyserver. It inexplicably just fails
sometimes. I was trying to use it out of an abundance of caution
(<cough> paranoia <cough>), but it seems like most open source projects
just serve up their public keys from their project web sites. The
private and public pre-release keys are still stored on separate sites,
the private key is still strongly encrypted by Travis, and we use a
separate key for pre-releases anyhow, so even if it's compromised, we
can quickly and easily deploy a new one.
|
|
bb3d3256
|
2018-11-12T13:20:28
|
|
Travis: Try high-availability SKS keyserver pool
The saga continues ...
|
|
2b1c9c68
|
2018-11-02T11:55:29
|
|
Travis: Don't check key server SSL certificate
... when downloading the RPM signing key. Apparently the key server
URL sometimes redirects to an https URL, which may explain why fetching
the RPM signing keys failed frequently when we used to run wget inside
of the CentOS 5 Docker container.
|
|
07e304c3
|
2018-10-26T09:29:09
|
|
Travis: Work around frequent build failures
The build will consistently fail for days at a time with:
error: http://pool.sks-keyservers.net/pks/lookup?op=get&search=0x0575F26BD5B3FDB1: import read failed(-1).
I have a hunch that this is related to the CentOS 5 Docker container, so
this commit causes Travis to download the RPM signing key outside of
the container and share it with the container.
|
|
3041cf67
|
2018-05-21T22:52:39
|
|
Travis: Use SKS keyserver pool
pgp.mit.edu seems to be frequently down, which was causing the PR builds
to fail.
|
|
9a12cf7a
|
2018-03-30T00:33:00
|
|
Travis: Deploy only when using official repo
This prevents build failures on forks that contain a master or dev
branch.
|
|
d3a1f899
|
2018-03-23T16:11:06
|
|
Travis: Don't build tags
|
|
d64e8e29
|
2018-03-23T13:57:59
|
|
Fix continuous integration of pull requests
- Travis doesn't set the $encrypted_* variables for PRs, so disable GPG
signing when building a PR (artifacts aren't deployed for PRs anyhow,
and even if they were, I wouldn't want them to be signed, as they may
contain unvetted code.)
- Take advantage of the new -d option in buildljt, which allows for
building from an existing Git clone directory. This eliminates the need
to rename and restore .git/shallow, allows the official build scripts to
work properly when building PRs, and prevents 'git clone' being invoked
twice in CI builds.
Refer to #217
|
|
289014d4
|
2018-01-05T12:05:43
|
|
Merge branch 'master' into dev
|
|
3847f911
|
2018-01-03T07:56:12
|
|
Travis/OS X: Use 'brew bundle' + Brewfile
This ensures that the build script will not fail if the Homebrew
dependencies are already installed.
|
|
c05d1249
|
2017-11-29T14:36:39
|
|
Merge branch 'master' into dev
|
|
a831b5a9
|
2017-11-29T14:23:31
|
|
Travis: Work around xcode7.3 image bug
Refer to travis-ci/travis-ci#8552. This was supposed to be fixed on
November 15, then on November 28. Travis blew through both deadlines,
so I have no confidence that the issue will be fixed as promised in a
timely manner. Adding 'brew update' to .travis.yml slows the OS X
build, but there is no choice at the moment.
|
|
f0dd80f2
|
2017-09-20T17:13:46
|
|
Merge branch 'master' into dev
|
|
db0dec3c
|
2017-09-11T09:48:33
|
|
Travis: Limit parallel make jobs to # of CPU cores
This tends to be faster than 'make -j', since it is making more wise
use of the available resources.
|
|
2ac4e9d9
|
2017-06-26T21:58:32
|
|
Merge branch 'master' into dev
|
|
70f236dd
|
2017-05-08T08:15:11
|
|
Travis: Fix OS X build
The Travis xcode7.3 image now apparently includes GnuPG 1.4.x by
default, so use it instead of installing GnuPG 2. Using GnuPG 2.1.x,
the default version in Homebrew as of this writing, is problematic for
this reason:
https://wiki.archlinux.org/index.php/GnuPG#Unattended_passphrase
|
|
d34d2559
|
2017-01-19T19:05:21
|
|
Merge branch 'master' into dev
|
|
22527955
|
2017-01-19T17:50:59
|
|
Fix error w/ lossless crop & libjpeg v7 emulation
The JPEG_LIB_VERSION #ifdef in jtransform_adjust_parameters() was
incorrect, which caused a "Bogus virtual array access" error when
attempting to use the lossless crop feature.
Introduced in c04bd3cc97f44fd9030de1e141754c8775d4e5a5.
This also adds libjpeg v7 API/ABI emulation to the Travis CI tests.
|
|
3582ce90
|
2016-12-01T01:58:34
|
|
Travis: Use xcode7.3 image
The xcode7.2 image is verfallen, verlumpt, verblunget, verkackt
This also ensures that the build scripts are checked out from a
branch matching the libjpeg-turbo repository branch (not strictly
necessary when building from master, but it keeps the code in sync with
dev.)
|
|
97205269
|
2016-11-23T18:44:33
|
|
Travis: Fix OS X build
+ migrate to new xcode7.3 image, since xcode7.2 is going away soon.
|
|
6abd3916
|
2016-11-15T08:47:43
|
|
Unified CMake-based build system
See #56 for discussion.
Fixes #21, Fixes #29, Fixes #37, Closes #56, Fixes #58, Closes #73
Obviates #82
See also:
https://sourceforge.net/p/libjpeg-turbo/feature-requests/5/
https://sourceforge.net/p/libjpeg-turbo/patches/5/
|
|
a949da48
|
2016-10-20T19:17:30
|
|
Merge branch 'master' into dev
|
|
2d4b2f14
|
2016-10-20T17:55:55
|
|
Travis: Deploy to S3 rather than SourceForge
This has the following advantages:
-- It doesn't require checking a private SSH key into the repository.
(With SourceForge, an SSH key is the "keys to the kingdom".)
-- If the S3 key is compromised, it is very easy to revoke it and
generate a new one.
-- The S3 bucket is isolated, so even if it becomes compromised, then
the damage that one could do is limited.
-- It's much easier to manage files through S3's web interface than
through SourceForge.
-- The files are served via HTTPS.
-- Travis fully supports S3 as a deployment target, so this simplifies
.travis.yml somewhat.
|
|
108b1cd9
|
2016-10-20T01:37:40
|
|
Merge branch 'master' into dev
|
|
9366cf0b
|
2016-10-20T01:01:27
|
|
Travis: GPG sign Linux binaries/source tarballs
Since we're still deploying our Linux/macOS CI artifacts to a web server
(specifically SourceForge Project Web Services) that doesn't support
HTTPS, it's a good idea to sign them. But since the private key has to
be checked into the repository, we use a different key for signing the
pre-releases (per project policy, the private signing keys for our
release binaries are never made available on any public server.)
|
|
1a8c68ac
|
2016-10-07T12:55:18
|
|
Merge branch 'master' into dev
|
|
1ee329d6
|
2016-10-07T12:54:55
|
|
Travis: Fix deployment issue (2nd attempt)
|
|
fa3bdfb7
|
2016-10-07T05:47:35
|
|
Merge branch 'master' into dev
|
|
b47c5e73
|
2016-10-07T05:34:11
|
|
Travis: Fix deployment issue
"Skipping a deployment with the script provider because this branch is
not permitted"
|
|
27f817cd
|
2016-10-07T05:07:11
|
|
Travis: Use existing sandbox for official builds
This eliminates the need to specify the remote repository and branch,
and it prevents the code from being checked out twice.
|
|
be908ac0
|
2016-10-05T14:42:35
|
|
Travis CI: Fixes to support AVX2 code
-- Use trusty for SIMD builds. Ubuntu 12.04 is still using NASM 2.09.x,
which isn't new enough to support AVX2.
-- Add a special test for the SSE2 code path, since it is no longer the
default.
|
|
6d22430a
|
2016-10-05T14:36:46
|
|
Travis: use correct repo/branch for off. builds
Pass the actual repository and branch that Travis is using into the
builtljt script, so the official builds it generates will come from
the same code base as the other tested builds.
|
|
e9e3a2ed
|
2016-10-05T12:38:59
|
|
Travis CI: Use correct key for this repository
|
|
211c69f3
|
2016-10-02T09:13:23
|
|
Add Travis CI config for Un*x pre-release builds
|