Jason Wessel [Thu, 8 Aug 2019 20:24:00 +0000 (13:24 -0700)]
dpkg: Provide update-alternative for start-stop-daemon
When using DISTRO_FEATURE usrmerge, busybox and something that
requires dpkg-start-stop there is a conflict which prints the
following error.
===
ERROR: core-image-minimal-1.0-r1 do_rootfs: Postinstall scriptlets of ['busybox'] have failed. If the intention is to defer them to first boot,
then please place them into pkg_postinst_ontarget_${PN} ().
Deferring to first boot via 'exit 1' is no longer supported.
Details of the failure are in /build/tmp-glibc/work/intel_x86_64-linux/core-image-minimal/1.0-r1/temp/log.do_rootfs.
ERROR: core-image-minimal-1.0-r1 do_rootfs: Function failed: do_rootfs
===
Looking at the log file, it shows the problem:
update-alternatives: Error: not linking /build/tmp-glibc/work/intel_x86_64-linux/core-image-minimal/1.0-r1/rootfs/usr/sbin/start-stop-daemon to /usr/bin/busybox.nosuid since /build/tmp-glibc/work/intel_x86_64-linux/core-image-minimal/1.0-r1/rootfs/usr/sbin/start-stop-daemon exists and is not a link
===
The solution is to add an update-alternative to start-stop-daemon for dpkg.
As for the removal of the bb.warn, if the size is not specified, it is
not something to warn the end user about. Some of my default images
make use of the head room + a computed directory size or while generating
images.
Jason Wessel [Thu, 8 Aug 2019 20:23:58 +0000 (13:23 -0700)]
wic: Add partition type for msdos partition tables
In order to create a msdos partition table disk image that can auto
expand after the image is copied to an SD card, wic needs the ability
to have a primary partition as the last entry. The desired use case
is to be able to create an A/B update partition image scheme with a
/var volume that can be auto expanded to the remainder of the SD card
at run time.
The typical .wks file will look similar to the following:
With the patch applied a primary partition can be created at the end
of the image which can be expanded to fill the free space on the media
where the image has been copied, which looks like:
Disk boot.img: 890940s
Sector size (logical/physical): 512B/512B
Partition Table: msdos
Disk Flags:
Jason Wessel [Thu, 8 Aug 2019 20:23:57 +0000 (13:23 -0700)]
image_types_wic.bbclass: Copy the .wks and .env files to deploy image dir
When using a .wks.in file, the only place that the generated .wks file
exists in the tmp/work area. A copy should be left behind in the
deploy directory so that you can easily run the wic tool to
re-generate or modify a new image without running bitbake. Custom
.wks.in files can reference any number of bitbake variables, so it is
important to save the result.
below is an example of using the generated .wks file in the deploy
area. The full name of my generated .wks file was
core-image-minimal-ostree-uboot-ab.wks, but since you usually only
have a single .wks file per image you can use a wild card like:
Ricardo Neri [Mon, 5 Aug 2019 22:18:23 +0000 (18:18 -0400)]
runqemu: Add support to handle EnrollDefaultKeys PK/KEK1 certificate
The EnrollDefaultKeys.efi application (distributed in ovmf-shell-image)
expects the hypervisor to provide a Platform Key and first Key Exchange
Key certificate.
For QEMU, this is done by adding an OEM string in the Type 11 SMBIOS
table. The string contains the EnrollDefaultKeys application GUID followed
by the certificate string. For now, the string is passed in the command
line until QEMU understands OEM strings from regular files (please see
https://bugs.launchpad.net/qemu/+bug/1826200).
If runqemu detects it is given an OVMF binary with support for Secure Boot
(i.e., ovmf.secboot* binaries), extract the certificate string from the
OvmfPkKek1.pem certificate and modify the command-line parameters to
provide the key. Such certificate is created when building OVMF with
support for Secure Boot.
ovmf: Generate test Platform key and first Key Exchange Key
Commit from EDK2 be9470b3c91f ("OvmfPkg/EnrollDefaultKeys: enroll
PK/KEK1 from the Type 11 SMBIOS table") mandates that a Platform Key
and first Key Exchange Key certificate is provided to the
EnrollDefaultKeys application.
Previously, the application was using a hard-coded certificate
from Red Hat embedded in the application.
Create a certificate that can QEMU can subsequently pass to
EnrollDefaultKeys when running qemu-shell-image.
Cc: Ross Burton <ross.burton@intel.com> Cc: Patrick Ohly <patrick.ohly@intel.com> Cc: Alexander Kanavin <alex.kanavin@gmail.com>
(From OE-Core rev: daaf9d7bd8c3586609ab0eccf49af38dbdb0b02e)
Signed-off-by: Ricardo Neri <ricardo.neri-calderon@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Update OVMF to edk2-stable201905. Since the last update, several things
have changed. Many of the patches we were carrying have now been taken
upstream in EDK2 or become obsolete. See below for details.
Also, as of commit 0c1ffb9504c3("CryptoPkg: Adding OpenSSL as one
submodule of EDKII repo"), openssl is not embedded into EDK2 using a
patching script but a git submodule. Then, use the gitsm bitbabke fetcher
and drop the extra SRC_URI from openssl when building with secureboot
enabled. Also remove all related variables.
OVMF switched to BSD+Patent license as detailed in
https://bugzilla.tianocore.org/show_bug.cgi?id=1373. Hence, update
LIC_FILES_CHKSUM accordingly to reflect this change.
Patches are updated as follows:
Drop 0001-ia32-Dont-use-pie.patch as it is implemented in upstream EDK2
in commits are 11d0cd23dd1b ("BaseTools/tools_def IA32: drop -no-pie linker
option for GCC49" and c25d3905523a ("BaseTools/tools_def IA32: disable PIE
code generation explicitly") for the applicable GCC versions.
Rebase 0003-BaseTools-makefile-adjust-to-build-in-under-bitbake.patch
to edk2-stable201905.
Drop VfrCompile-increase-path-length-limit.patch as it has been taken
upstream in EDK2 in commit ba78032bc8c9f("BaseTools/VfrCompile: Remove the
MAX_PATH limitation").
Rebase no-stack-protector-all-archs.patch to keep behavior on not using
stack protector on all archs.
Drop 0001-BaseTools-header.makefile-add-Wno-stringop-truncatio.patch,
0002-BaseTools-header.makefile-add-Wno-restrict.patch, and
0003-BaseTools-header.makefile-revert-gcc-8-Wno-xxx-optio.patch. These
patches have been taken in upstream EDK2 in commits 9222154ae7b3("BaseTools
/header.makefile: add "-Wno-restrict"), 1d212a83df0e("BaseTools/
header.makefile: add "-Wno-stringop-truncation"), and 777f4aa083e9
("BaseTools/header.makefile: revert gcc-8 '-Wno-xxx' options on OSX"),
respectively.
Also, drop 0004-BaseTools-GenVtf-silence-false-stringop-overflow-war.patch.
GenVtf has been removed from EDK2 in commit 64ab2c82e8f6("BaseTools:
Remove GenVtf"). Also, this patch had been taken in EDK2 upstream in
commit 9de306701312("BaseTools/GenVtf: silence false 'stringop-overflow'
warning with memcpy()").
Drop patch 0007-OvmfPkg-EnrollDefaultKeys-application-for-enrolling-.patch
as it also has been taken by EDK2.
Patches 0002-ovmf-update-path-to-native-BaseTools.patch and
0004-ovmf-enable-long-path-file.patch did not need any update.
do_rootfs failed with error:
file /usr/lib64/grub/arm64-efi/acpi.module conflicts between attempted installs of grub-2.02-r0.aarch64 and grub-efi-2.02-r0.aarch64
file /usr/lib64/grub/arm64-efi/adler32.module conflicts between attempted installs of grub-2.02-r0.aarch64 and grub-efi-2.02-r0.aarch64
...
file /usr/lib64/grub/arm64-efi/zfsinfo.module conflicts between attempted installs of grub-2.02-r0.aarch64 and grub-efi-2.02-r0.aarch64
For arm64, grub and grub-efi both compiled GRUBD2 with platform
arm64-efi, arm64 only support platform efi. So both packages have
almost same folder and content /usr/lib64/grub/arm64-efi/*
if Machine set to qemux86_64, do_rootfs will not have this problem,
since for grub, it compiled with platform i386-pc, for grub-efi,
compiled with platform x86-64-efi.
While installing grub and grub-efi, there are conflict files
in ${sysconfdir} ${datadir} ${bindir} ${sbindir}.
- Since all of the conflicted files are tools which is
common for grub and grub-efi, we split them (except
grub-editenv) to grub-common in grub.
common tools for grub and grub-efi are installed into grub-common,
for aarch64, also shipped libdir into this common packages.
in this way, for qemuarm64, package grub is empty, and package grub-efi
use lib in package grub-common
Tim Blechmann [Thu, 8 Aug 2019 04:58:33 +0000 (12:58 +0800)]
deb: allow custom dpkg command
trying to reduce the turnaround times for local builds, i'm trying to
find a way to inject `-Zgzip -z1` into the dkpg-deb command line.
attached patch introduces a `DPKG_BUILDCMD` variable for this purpose.
(i'm not very familiar with the whole bitbake infrastructure, so i'm
wondering: do i have to add it to the `vardeps` of do_package_deb?)
tia,
tim
>From 62d4930d307d5d07844889001e8a1c3111b72b98 Mon Sep 17 00:00:00 2001
From: Tim Blechmann <tim@klingt.org>
Date: Thu, 8 Aug 2019 06:48:54 +0200
Subject: [PATCH] package_deb: allow dpkg-deb to be customized via
DPKG_BUILDCMD
the command line to invoke `dpkg-deb` is hardcoded. there are certain use
cases where we want to tweak how debian packages are compiled: e.g. the
default uses xz compression, which is rather CPU intensive. for local
builds one might want to pass `-Zgzip -z1` to favor speed over compression
ratio.
we therefore introduce a `DPKG_BUILDCMD` variable which allows downstream
code to customize how dpkg-deb is executed
Robert Yang [Wed, 7 Aug 2019 09:50:49 +0000 (17:50 +0800)]
bitbake: knotty: Fix for the Second Keyboard Interrupt
Fixed:
$ rm -fr tmp-glibc/cache/default-glibc/qemux86/x86_64/bb_cache.dat* ; bitbake -p
Press the first Ctrl-C when the parsing process is at about 50%:
Keyboard Interrupt, closing down...
Then presss the second Ctrl-C:
File "/path/to/bitbake/bitbake/lib/bb/ui/knotty.py", line 619, in main
event = eventHandler.waitEvent(0.25)
File "/path/to/bitbake/lib/bb/server/process.py", line 591, in waitEvent
self.eventQueueNotify.wait(delay)
File "/usr/lib/python3.5/threading.py", line 549, in wait
signaled = self._cond.wait(timeout)
File "/usr/lib/python3.5/threading.py", line 297, in wait
gotit = waiter.acquire(True, timeout)
KeyboardInterrupt
Capture the second KeyboardInterrupt during stateShutdown is running can fix
the problem. There may be still tracebacks for the third KeyboardInterrupt, but
I'm leaning to not fix it since we aimed for supporting 2 KeyboardInterrupts
only.
Robert Yang [Wed, 7 Aug 2019 09:50:48 +0000 (17:50 +0800)]
bitbake: cooker: Cleanup the queue before call process.join()
Fixed:
$ rm -fr tmp-glibc/cache/default-glibc/qemux86/x86_64/bb_cache.dat* ; bitbake -p
Press *one* Ctrl-C when the parsing process is at about 50%, then the processes
are not exited:
Keyboard Interrupt, closing down...
Timeout while waiting for a reply from the bitbake server
local.conf.sample: do not add sdl to nativesdk qemu config
This is unnecessary as the recipe itself already does it:
http://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/meta/recipes-devtools/qemu/qemu_4.0.0.bb?id=1a4e4fb6b0a9d54641bd4193e95311d1f822a9ca#n21
EXCLUDE_PACKAGES_FROM_SHLIBS is too broad: it suppresses both generation
of required and provided shlibs. We need to suppress only the provided shlibs
(to avoid clashes with the main package providing the same shlibs),
and run the required shlib dependencies generator as usual.
When the code is compiled with "-fstack-protector-strong
-D_FORTIFY_SOURCE=2", everytime ftpfd is asked for a non existent file,
it crashes with the following error:
*** buffer overflow detected ***:
Aborted
This seems to be a bug/feature of gcc. A bug has been open on their
bugzilla, and also inetutils have been posted with the proposed patch.
Without this patch, pxelinux fails to boot because it keeps asking the
server for the pxelinux.cfg/00-01-02-03-04 and never jumps to /default.
mesa,llvm,meson: Update llvm to 8.0.1 plus define and use LLVM version globally
- Add missing dependency on libedit
- Define LLVMVERSION on the same lines as GCCVERSION and other tools
- Use LLVMVERSION in mesa and meson.bbclass to get llvm version instead of
hardcoding it
- Use llvm patches unmodified from meta-clang, helps in keeping them in
sync
- Define PREFERRED_VERSION for llvm, llvm-native, nativesdk-llvm
Trevor Gamblin [Tue, 6 Aug 2019 19:16:59 +0000 (15:16 -0400)]
gzip: update ptest package dependencies
gzip-ptest skips the following tests on core-image-sato builds:
- zgrep-context
- zdiff
- zgrep-signal
The same tests pass on core-image-sato-sdk builds. This is due to
the use of busybox tool variants on core-image-sato (zgrep-context,
zdiff) and the absence of the perl and perl-ptest packages
(zgrep-signal). This patch adds the dependencies needed for all
three tests.
Jason Wessel [Mon, 5 Aug 2019 16:32:37 +0000 (09:32 -0700)]
pseudo: Fix openat() with a symlink pointing to a directory
While working with ostree disk generation in conjunction with wic, I
found a problem with pseudo where it tried to resolve a symlink when
it shouldn't, based on openat() flags. A C program has been
constructed to test pseudo to show that it is working properly with
the correct behavior around openat().
int target_dfd = openat (dfd, "tlink", O_RDONLY | O_NONBLOCK |
O_DIRECTORY | O_CLOEXEC | O_NOFOLLOW);
if (target_dfd == -1) {
printf("Test 1 good\n");
} else {
printf("Test 1 failed\n");
close(target_dfd);
}
target_dfd = openat (dfd, "tlink", O_RDONLY | O_NONBLOCK |
O_DIRECTORY | O_CLOEXEC);
if (target_dfd == -1) {
printf("Test 2 failed\n");
} else {
printf("Test 2 good\n");
close(target_dfd);
}
/* Test 3 make sure the owner of the link is root */
struct stat sbuf;
if (!lstat("tlink", &sbuf) && sbuf.st_uid == 0) {
printf("Test 3 good\n");
} else {
printf("Test 3 failed\n");
}
/* Test 4 tests open with the "rb" flag, owner should not change */
int ofd = openat(dfd,"./tlink", O_RDONLY|O_CLOEXEC);
if (ofd >= 0) {
if (fstat(ofd, &sbuf) != 0)
printf("ERROR in fstat test 4\n");
else if (sbuf.st_uid == 0)
printf("Test 4 good\n");
close(ofd);
} else {
printf("Test 4 failed with openat()\n");
}
/* Test pseudo db to see the fstat() above did not delete the DB entry */
if (!lstat("tlink", &sbuf) && sbuf.st_uid == 0)
printf("Test 5 good\n");
else
printf("Test 5 failed... tlink is owned by %i and not 0\n", sbuf.st_uid);
return 0;
}
Jason Wessel [Tue, 6 Aug 2019 21:16:08 +0000 (14:16 -0700)]
sqlite3: Fix zlib determinism problem
sqlite3-native in particular was finding zlib from the host if zlib-devel
was installed. This could lead to races where pseudo-native may or may not
fail to build.
We don't need/use compressed page support with sqlite so disable the dependency
(it doesn't have a configure option so use a autoconf cache variable).
The target binaries were not previously building with zlib, so we will
leave the default being zlib turned off, while the host binaries were
building with it "occasionally", but not for anything at runtime.
Errors:
qemu cannot bootup since:
Booting from ROM...
This kernel requires an x86-64 CPU, but only detected an i686 CPU.
Unable to boot - please use a kernel appropriate for your CPU.
QEMU: Terminated
For lib32 image, override has x86, so the qemubin set to qemu-system-i386,
fix by move QB_SYSTEM_NAME to corresponding conf, don't use the override
Khem Raj [Sun, 4 Aug 2019 15:14:46 +0000 (08:14 -0700)]
glibc: Update to glibc 2.30
- Drop backported patches
- Move common pieces between cross-localedef and glibc into a common file
- Move latest checksums to glibc-common.inc and remove duplicates from glibc recipe
- Detailed release notes [1]
Khem Raj [Mon, 5 Aug 2019 19:34:29 +0000 (12:34 -0700)]
groff: Fix math.h inclusion from system headers issue
groff has system headers overrides in its sourcecode which it
generates as fallbacks but in some cases when a system header includes
math.h via include <> directive it lands in the override header and
causes compile issues, seen with clang+libc++, this patch makes sure
that right defines are available before including it
Richard Purdie [Mon, 29 Jul 2019 16:28:04 +0000 (17:28 +0100)]
sstatesig: Updates to match bitbake siggen changes
Update the metadata to correspond to the bitbake siggen task specification
format change. This standardises on "<fn>:<task>" everywhere rather than
the "." delimiter that was being used in some places.
This is an API breaking change but means we now have a consistent format
being used throughout the codebase without compatibility APIs.
Richard Purdie [Tue, 23 Jul 2019 20:58:24 +0000 (21:58 +0100)]
sstatesig: Adpat to recent bitbake hash equiv runqueue changes
Upstream bitbake now hanes preserving the unihash data itself, drop
this usage of persist_data which was extremely problematic due to
concurrent task access issues, particulary on loaded systems.
Richard Purdie [Mon, 29 Jul 2019 13:22:03 +0000 (14:22 +0100)]
sstatesig: Move unihash siggen code to bitbake
This code is closely tied with the hash server in bitbake and also means
we can't relibably test the hashserv runqueue functionality without OE
metadata. Moving this to bitbake as a MixIn class makes most sense
and encourages code collaboration and reuse as well as enabling easier
and more accurate testing of the APIs.
Richard Purdie [Wed, 31 Jul 2019 14:59:59 +0000 (15:59 +0100)]
classes/lib: Remove bb.build.FuncFailed
Whilst seemingly a good idea, this exception doesn't really serve any purpose
that bb.fatal() doesn't cover. Wrapping exceptions within exceptions isn't
pythonic.
Its not used in many places, lets clean up those and remove usage of it
entirely. It may ultimately be dropped form bitbake entirely.
Richard Purdie [Wed, 31 Jul 2019 14:55:51 +0000 (15:55 +0100)]
bitbake: build/utils: Drop bb.build.FuncFailed
Its hard to see what this exception adds in the current codebase. The logfile
attribute is effectively ignored, the exception doesn't serve a defined
purpose and mostly seems to be worked around.
Remove it entirely. If this does cause output problems, we'll figure
out better ways to address those.
Richard Purdie [Mon, 29 Jul 2019 16:28:20 +0000 (17:28 +0100)]
bitbake: siggen: Clean up task reference formats
Currently siggen uses the format "<filename>.<taskname>" for referencing tasks
whilst runqueue uses "<filename>:<taskname>". This converts to use ":" as the
separator everywhere.
This is an API breaking change since the cache is affected, as are siginfo files
and any custom signature handlers such as those in OE-Core.
Ultimately this will let us clean up and the accessor functions from runqueue,
removing all the ".rsplit(".", 1)[0]" type code currently all over the place.
Once a standard is used everwhere we can update the code over time to be more
optimal.
Richard Purdie [Mon, 29 Jul 2019 14:46:03 +0000 (15:46 +0100)]
bitbake: runqueue: Clean up BB_HASHCHECK_FUNCTION API
This function uses an old API which uses offsets into lists as a communication
mechanism. Update the API to use "tid" which is used universally in runqueue now.
We can also add kwargs support to the funciton definition to drop some of the
backwards compaiblility hoops we had to jump though with different function
argument combinations.
Richard Purdie [Wed, 31 Jul 2019 09:49:39 +0000 (10:49 +0100)]
bitbake: hashserv: Switch from threads to multiprocessing
There were hard to debug lockups when trying to use threading to start
hashserv as a thread. Switch to multiprocessing which doesn't show the
same locking problems.
Richard Purdie [Wed, 24 Jul 2019 13:14:50 +0000 (14:14 +0100)]
bitbake: hashserv: Use separate threads for answering requests and handling them
Experience with the prserv shows that having two threads, one accepting
and queueing connections and one handling the requests leads to much
more reliable behaviour than having everything in a single thread.
Richard Purdie [Wed, 24 Jul 2019 13:08:30 +0000 (14:08 +0100)]
bitbake: hashserv: Turn off sqlite synchronous mode
We're seeing performance problems with hashserv running on a normal build
system. The cause seems to be the large amounts of file IO that builds involve
blocking writes to the database. Since sqlite blocks on the sync calls, this
causes a significant problem.
Since if we lose power we have bigger problems, run with synchronous=off
to avoid locking and put the jounral into memory to avoid any write issues
there too.
This took writes from 120s down to negligible in my tests, which means
hashserv then responds promptly to requests.
Richard Purdie [Wed, 24 Jul 2019 08:13:55 +0000 (09:13 +0100)]
bitbake: cooker/hashserv: Allow autostarting of a local hash server using BB_HASHSERVE
Its useful, particularly in the local developer model of usage, for
bitbake to start and stop a hash equivalence server on local port,
rather than relying on one being started by the user before the build.
The new BB_HASHSERVE variable supports this.
The database handling is moved internally into the hashserv code so that
different threads/processes can be used for the server without errors.
Richard Purdie [Mon, 5 Aug 2019 22:31:25 +0000 (23:31 +0100)]
bitbake: runqueue: Improve determinism
Whilst this isn't strictly necessary, its helpful if the log output is
consistent and its also helpful if bugs either appear or don't appear
for a specific configuration. Ensuring the various iterations we make
are deterministic (sorted) helps with this.
Richard Purdie [Tue, 23 Jul 2019 21:51:15 +0000 (22:51 +0100)]
bitbake: runqueue: Enable dynamic task adjustment to hash equivalency
There is a compelling usecase for tasks being able to notify runqueue
that their "unihash" has changed. When this is recieved, the hashes of
all subsequent tasks should be recomputed and their new hashes checked
against existing setscene validity. Any newly available setscene tasks
should then be executed.
Making this work effectively needs several pieces. An event is added
which the cooker listen for. If a new hash becomes available it can
send an event to notify of this.
When such an event is seen, hash recomputations are made. A setscene
task can't be run until all the tasks it "covers" are stopped. The
notion of "holdoff" tasks is therefore added, these are removed from
the buildable list with the assumption that some setscene task will
run and cover them.
The workers need to be notified when taskhashes change to update their
own internal siggen data stores. A new worker command is added to do this
which will affect all newly spawned worker processes from that worker.
Richard Purdie [Tue, 23 Jul 2019 21:44:29 +0000 (22:44 +0100)]
bitbake: siggen: Add new unitaskhashes data variable which is cached
We need to preserve unihash task hashes between runs. Use the new SimpleCache
class to create such a class within the signature generator which is loaded
at init time and saved when builds complete. The default is unpopulated but
metadata sig handlers can populate this cache.
Rather than a special copy of the data structure which we change, compute
the logic using set operations from other data we have. This means
we can add tasks back into the scenequeue without having to worry about
reversing operations on this variable with all the potential bugs that
might involve.
Richard Purdie [Tue, 23 Jul 2019 20:50:20 +0000 (21:50 +0100)]
bitbake: cache: Add SimpleCache class
This adds a simple version of the MultiProcessCache which can be used to
save and load cache data, useful for a new usecase we have in
sigdata/runqueue.
Richard Purdie [Mon, 29 Jul 2019 13:22:23 +0000 (14:22 +0100)]
bitbake: siggen: Import unihash code from OE-Core
This code is closely tied with the hash server in bitbake and also means
we can't relibably test the hashserv runqueue functionality without OE
metadata. Moving this to bitbake as a MixIn class makes most sense
and encourages code collaboration and reuse as well as enabling easier
and more accurate testing of the APIs.
Implements a number of optimizations to the SQL used in the hash
equivalence server:
1) Two indexes are created for the two methods (method, taskhash and
method outhash) by which rows are found in order to speed up the
lookup
2) An extra SELECT to lookup the just inserted row was removed. This
SELECT is unnecessary since all of the information about the newly
inserted row is already available.
3) A uniqueness constraint was added to the table. This should allow
the server to be multithreaded in the future since duplicate inserts
can be detected (and ignored). This change requires bumping the
database version to '2', since a uniqueness constraint can't be
added to an existing table.
4) Some comments are added to clarify the trick SELECT statement used
when inserting new equivalent hashes
Richard Purdie [Sat, 3 Aug 2019 10:49:23 +0000 (11:49 +0100)]
sstate: Reduce race windows
When we write to the sstate directory we try to do so atomically so
consumers either see one version or another but never an imcomplete file.
Unfortunately this is reliant on filesystem support and with some NFS
configurations a replaced file would be lost from memory even if users held
open descriptors.
It makes sense to try and avoid replacing existing files where we can.
Ross Burton [Fri, 2 Aug 2019 20:37:16 +0000 (21:37 +0100)]
xserver-xorg: remove embedded build path in the source
The generated source file sdksyms.c has a comment with the absolute build path,
which means xserver-xorg-src contains this build path. This is both potential
build information leakage and a source of unreproducibility, so remove the
comment.
Ross Burton [Fri, 2 Aug 2019 20:37:14 +0000 (21:37 +0100)]
xdpyinfo: don't depend on DGA
DGA (Direct Graphics Access) is an obsolete extension that neither modern X
drivers nor applications support. We'll remove the client library, so remove
the optional dependency on DGA in xdpyinfo.
projects / thirdparty / openembedded / openembedded-core-contrib.git / log
