Armin Kuster [Sun, 25 Mar 2018 05:40:32 +0000 (22:40 -0700)]
tzdata: update to 2018d
Briefly:
Palestine starts DST a week earlier in 2018.
Add support for vanguard and rearguard data consumers.
Add subsecond precision to source data format, though not to data.
Changes to future time stamps
In 2018, Palestine starts DST on March 24, not March 31.
Adjust future predictions accordingly. (Thanks to Sharef Mustafa.)
Changes to past and future time stamps
Casey Station in Antarctica changed from +11 to +08 on 2018-03-11
at 04:00. (Thanks to Steffen Thorsen.)
Changes to past time stamps
Historical transitions for Uruguay, represented by
America/Montevideo, have been updated per official legal documents,
replacing previous data mainly originating from the inventions of
Shanks & Pottenger. This has resulted in adjustments ranging from
30 to 90 minutes in either direction over at least two dozen
distinct periods ranging from one day to several years in length.
A mere handful of pre-1991 transitions are unaffected; data since
then has come from more reliable contemporaneous reporting. These
changes affect various timestamps in 1920-1923, 1936, 1939,
1942-1943, 1959, 1966-1970, 1972, 1974-1980, and 1988-1990.
Additionally, Uruguay's pre-standard-time UT offset has been
adjusted westward by 7 seconds, from UT-03:44:44 to UT-03:44:51, to
match the location of the Observatory of the National Meteorological
Institute in Montevideo.
(Thanks to Jeremie Bonjour, Tim Parenti, and Michael Deckers.)
Enderbury and Kiritimati skipped New Year's Eve 1994, not
New Year's Day 1995. (Thanks to Kerry Shetline.)
Fix the 1912-01-01 transition for Portugual and its colonies.
This transition was at 00:00 according to the new UT offset, not
according to the old one. Also assume that Cape Verde switched on
the same date as the rest, not in 1907. This affects
Africa/Bissau, Africa/Sao_Tome, Asia/Macau, Atlantic/Azores,
Atlantic/Cape_Verde, Atlantic/Madeira, and Europe/Lisbon.
(Thanks to Michael Deckers.)
Fix an off-by-1 error for pre-1913 timestamps in Jamaica and in
Turks & Caicos.
Changes to past time zone abbreviations
MMT took effect in Uruguay from 1908-06-10, not 1898-06-28. There
is no clock change associated with the transition.
Changes to build procedure
The new DATAFORM macro in the Makefile lets the installer choose
among three source data formats. The idea is to lessen downstream
disruption when data formats are improved.
* DATAFORM=vanguard installs from the latest, bleeding-edge
format. DATAFORM=main (the default) installs from the format
used in the 'africa' etc. files. DATAFORM=rearguard installs
from a trailing-edge format. Eventually, elements of today's
vanguard format should move to the main format, and similarly
the main format's features should eventually move to the
rearguard format.
* In the current version, the main and rearguard formats are
identical and match that of 2018c, so this change does not
affect default behavior. The vanguard format currently contains
one feature not in the main format: negative SAVE values. This
improves support for Ireland, which uses Irish Standard Time
(IST, UTC+01) in summer and GMT (UTC) in winter. tzcode has
supported negative SAVE values for decades, and this feature
should move to the main format soon. However, it will not move
to the rearguard format for quite some time because some
downstream parsers do not support it.
* The build procedure constructs three files vanguard.zi, main.zi,
and rearguard.zi, one for each format. The files represent the
same data as closely as the formats allow. These three files
are intended for downstream data consumers and are not
installed. Zoneinfo parsers that do not support negative SAVE values
should start using rearguard.zi, so that they will be unaffected
when the negative-DST feature moves from vanguard to main.
Bleeding-edge Zoneinfo parsers that support the new features
already can use vanguard.zi; in this respect, current tzcode is
bleeding-edge.
The Makefile should now be safe for parallelized builds, and 'make
-j to2050new.tzs' is now much faster on a multiprocessor host
with GNU Make.
When built with -DSUPPRESS_TZDIR, the tzcode library no longer
prepends TZDIR/ to file names that do not begin with '/'. This is
not recommended for general use, due to its security implications.
(From a suggestion by Manuela Friedrich.)
Armin Kuster [Sun, 25 Mar 2018 05:38:34 +0000 (22:38 -0700)]
tzcode-native: update to 2018d
Changes to code
zic now accepts subsecond precision in expressions like
00:19:32.13, which is approximately the legal time of the
Netherlands from 1835 to 1937. However, because it is
questionable whether the few recorded uses of non-integer offsets
had subsecond precision in practice, there are no plans for tzdata
to use this feature. (Thanks to Steve Allen for pointing out
the limitations of historical data in this area.)
The code is a bit more portable to MS-Windows. Installers can
compile with -DRESERVE_STD_EXT_IDS on MS-Windows platforms that
reserve identifiers like 'localtime'. (Thanks to Manuela
Friedrich).
Changes to documentation and commentary
theory.html now outlines tzdb's extensions to POSIX's model for
civil time, and has a section "POSIX features no longer needed"
that lists POSIX API components that are now vestigial.
(From suggestions by Steve Summit.) It also better distinguishes
time zones from tz regions. (From a suggestion by Guy Harris.)
Commentary is now more consistent about using the phrase "daylight
saving time", to match the C name tm_isdst. Daylight saving time
need not occur in summer, and need not have a positive offset from
standard time.
Commentary about historical transitions in Uruguay has been expanded
with links to many relevant legal documents.
(Thanks to Tim Parenti.)
Commentary now uses some non-ASCII characters with Unicode value
less than U+0100, as they can be useful and should work even with
older editors such as XEmacs.
Bruce Ashfield [Wed, 14 Mar 2018 15:10:29 +0000 (11:10 -0400)]
linux-yocto/4.12: backport bugfixes for x86
Integrating the following commits:
60b649971940 x86/hibernate/64: Mask off CR3's PCID bits in the saved CR3 cec3c008ec8f drm/i915/cfl: Coffee Lake works on Kaby Lake PCH. 073873cb152c brd: remove unused brd_mutex 912c53b1b346 audit: fix memleak in auditd_send_unicast_skb.
Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com> Signed-off-by: Ross Burton <ross.burton@intel.com>
Author: California Sullivan <california.l.sullivan@intel.com>
Date: Wed Feb 17 16:47:10 2016 -0800
ktypes: add developer ktype
The developer ktype enables EMBEDDED, EXPERT, and DEBUG_KERNEL,
opening up more kernel options and setting some defaults.
Signed-off-by: California Sullivan <california.l.sullivan@intel.com> Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
Was created to address the kernel footprint related issues that are related
to many of the kernel debug options.
When this commit was merged, it re-enabled CONFIG_DEBUG_KERNEL for the
standard kernel, since it includes the systemtap fragment. The correct thing
to do is to move systemtap properly into the developer kernel type.
For now, you can build the developer kernel type, or add the developer kernel
configuration fragment via a bbappend, and you'll have a functional systemtap.
[YOCTO #12603]
Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com> Signed-off-by: Ross Burton <ross.burton@intel.com>
Jason Wessel [Tue, 13 Mar 2018 03:08:26 +0000 (22:08 -0500)]
python3: Fix purelib install and runtime paths
oe-core commit: 45afadf0b6 fixed the pip problem with purelib for
python2, even though the the patch stated it was for python3. This
patch addresses the purelib problem for python3.
If you install the package python3-pip you will have a pip3 binary
where you can see the problem on the device easily where the modules
install into the incorrect area and are not able to be referenced by
python3 at all.
Example error:
pip3 install imutils
pip3 list |grep imutils || echo ERROR no imutils
ERROR no imutils
python3 -c 'import imutils'
Traceback (most recent call last):
File "<string>", line 1, in <module>
ImportError: No module named 'imutils'
Signed-off-by: Jason Wessel <jason.wessel@windriver.com> Signed-off-by: Ross Burton <ross.burton@intel.com>
Koen Kooi [Fri, 9 Mar 2018 10:55:14 +0000 (11:55 +0100)]
openssl: fix libdir logic to allow multiarch style paths
The recipes were using 'basename' to turn '/usr/lib' into 'lib', which breaks when libdir is '/usr/lib/tuple', leading to libraries ending up in '/usr/tuple', which isn't in FILES_*. Change the logic to use sed to strip the prefix instead.
Signed-off-by: Koen Kooi <koen.kooi@linaro.org> Signed-off-by: Ross Burton <ross.burton@intel.com>
Richard Purdie [Wed, 14 Mar 2018 16:52:18 +0000 (09:52 -0700)]
uninative: Add compatiblity version check
If glibc is newer on the host than in uninative, the failure mode is
pretty nasty for clusters where the sstate is shared, including the Yocto
Project autobuilder.
This check aborts the use of uninative in such scenarios where a newer
glibc version appears and avoids corruption of sstate caches.
We use ldd to check the glibc version since that is included in libc-bin
(or equivalent) which locales use so it should always be present.
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Ross Burton [Mon, 12 Mar 2018 16:38:58 +0000 (16:38 +0000)]
build-recipe-list: build universe instead of world
Building world means recipes that are excluded from world build for whatever
reason get skipped from the manifests, which isn't useful. Instead building
universe and pass -k so that the expected dependency failures are not fatal.
Signed-off-by: Ross Burton <ross.burton@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Ross Burton [Mon, 12 Mar 2018 16:38:57 +0000 (16:38 +0000)]
meta: remove some EXCLUDE_FROM_WORLD assignments
Now that we have recipe-specific-sysroots we don't need to exclude recipes from
world builds because they conflict with other recipes, as they'll all be built
with their own sysroots.
Signed-off-by: Ross Burton <ross.burton@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Trevor Woerner [Mon, 12 Mar 2018 15:22:33 +0000 (11:22 -0400)]
iproute2: fix rebuild failures
When rebuilding iproute2, many such instances of the following build failure
occur:
| make[1]: Entering directory '.../iproute2/4.14.1-r0/iproute2-4.14.1/lib'
| Makefile:1: ../config.mk: No such file or directory
| make[1]: *** No rule to make target '../config.mk'. Stop.
Signed-off-by: Trevor Woerner <twoerner@gmail.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
lib/oe/patch.py: add a warning if patch context was ignored
Ignoring patch context increases the chances of patches being
applied incorrectly. Depending on what code is being patched, this can go
completely unnoticed and create subtle bugs, sometimes with security implications.
Please see here for a specific example:
https://bugzilla.yoctoproject.org/show_bug.cgi?id=10450
On the other hand, we cannot simply force all patch context to match exactly:
doing this would break a lot of recipes suddenly, across all layers.
So let's try a softer approach: issue a warning, and gently update
patches over a longer span of time. When most of the warnings are eliminated,
we can start enforcing a strict patch application policy.
I do understand that this patch creates a lot of warnings all of a sudden, however
I believe the problem does need to be addressed. All of oe-core recipes have their
context already fixed.
Sample warning:
WARNING: vulkan-1.0.61.1-r0 do_patch:
Some of the context lines in patches were ignored. This can lead to incorrectly applied patches.
The context lines in the patches can be updated with devtool:
Then the updated patches and the source tree (in devtool's workspace)
should be reviewed to make sure the patches apply in the correct place
and don't introduce duplicate lines (which can, and does happen
when some of the context is ignored).
Details:
Applying patch demos-Don-t-build-tri-or-cube.patch
patching file demos/CMakeLists.txt
Hunk #1 succeeded at 63 (offset 2 lines).
Hunk #2 succeeded at 76 with fuzz 1 (offset 2 lines).
[YOCTO #10450]
Signed-off-by: Alexander Kanavin <alexander.kanavin@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
oe-selftest: add a test for failing package post-installation scriptlets
The test runs a scriptlet that has an intentionally failing command in the middle
and checks for two things:
1) that bitbake does warn the user about the failure
2) that scriptlet execution stops at that point.
The test is run for all three package types: rpm, deb, ipk.
Signed-off-by: Alexander Kanavin <alexander.kanavin@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
meta/lib/oe/package_manager.py: warn about failing scriptlets for all package types
Previously this was done only for rpm packages; now also ipk/deb scriptlet
failures are reported.
In the future this will become a hard error, but it can't yet happen
due to the legacy 'exit 1' way of deferring scriptlet execution to first boot which
needs a deprecation period.
Signed-off-by: Alexander Kanavin <alexander.kanavin@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
package.bbclass: run pre/post installation/removal scriptlets using sh -e
This allows catching errors in the scriptlets which would otherwise
go unnoticed, e.g. this sequence:
====
bogus_command
proper_command
====
would work just fine without any visible warnings or errors.
This was previously done only for rpm packages; this patch replaces
the rpm-specific tweak with one that works for all package types.
Signed-off-by: Alexander Kanavin <alexander.kanavin@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Juro Bystricky [Sat, 10 Mar 2018 19:27:29 +0000 (11:27 -0800)]
openssl_1.0.2n: improve reproducibility
Improve reproducible build of:
openssl-staticdev
openssl-dbg
libcrypto
There are two main causes that prevent reproducible build, both related to
the generated file "buildinf.h":
1. "buildinf.h" contains build host CFLAGS, containing various build
host references. We need to pass sanitized CFLAGS to the script
generating this file ("mkbuildinf.pl". )
2. We also need to modify the script "mkbuildinf.pl" itsel in order to
generate a build timestamp based on SOURCE_DATE_EPOCH, if present in
the environment.
Signed-off-by: Juro Bystricky <juro.bystricky@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Juro Bystricky [Sat, 10 Mar 2018 18:56:25 +0000 (10:56 -0800)]
classes/recipes: Use expanded BUILD_REPRODUCIBLE_BINARIES value
Replace the occurences of BUILD_REPRODUCIBLE_BINARIES with expanded
values ${BUILD_REPRODUCIBLE_BINARIES} so the variable does not need to be
exported.
Signed-off-by: Juro Bystricky <juro.bystricky@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The patch tool will apply patches by default with "fuzz", which is where if the
hunk context isn't present but what is there is close enough, it will force the
patch in.
Whilst this is useful when there's just whitespace changes, when applied to
source it is possible for a patch applied with fuzz to produce broken code which
still compiles (see #10450). This is obviously bad.
We'd like to eventually have do_patch() rejecting any fuzz on these grounds. For
that to be realistic the existing patches with fuzz need to be rebased and
reviewed.
Signed-off-by: Alexander Kanavin <alexander.kanavin@linux.intel.com> Signed-off-by: Ross Burton <ross.burton@intel.com>
Ross Burton [Fri, 9 Mar 2018 18:56:13 +0000 (20:56 +0200)]
attr: refresh patches
The patch tool will apply patches by default with "fuzz", which is where if the
hunk context isn't present but what is there is close enough, it will force the
patch in.
Whilst this is useful when there's just whitespace changes, when applied to
source it is possible for a patch applied with fuzz to produce broken code which
still compiles (see #10450). This is obviously bad.
We'd like to eventually have do_patch() rejecting any fuzz on these grounds. For
that to be realistic the existing patches with fuzz need to be rebased and
reviewed.
Signed-off-by: Ross Burton <ross.burton@intel.com> Signed-off-by: Alexander Kanavin <alexander.kanavin@linux.intel.com> Signed-off-by: Ross Burton <ross.burton@intel.com>
Ross Burton [Fri, 9 Mar 2018 18:56:12 +0000 (20:56 +0200)]
libunwind: refresh patches
The patch tool will apply patches by default with "fuzz", which is where if the
hunk context isn't present but what is there is close enough, it will force the
patch in.
Whilst this is useful when there's just whitespace changes, when applied to
source it is possible for a patch applied with fuzz to produce broken code which
still compiles (see #10450). This is obviously bad.
We'd like to eventually have do_patch() rejecting any fuzz on these grounds. For
that to be realistic the existing patches with fuzz need to be rebased and
reviewed.
Signed-off-by: Ross Burton <ross.burton@intel.com> Signed-off-by: Alexander Kanavin <alexander.kanavin@linux.intel.com> Signed-off-by: Ross Burton <ross.burton@intel.com>
Ross Burton [Fri, 9 Mar 2018 18:56:11 +0000 (20:56 +0200)]
libtiff: refresh patches
The patch tool will apply patches by default with "fuzz", which is where if the
hunk context isn't present but what is there is close enough, it will force the
patch in.
Whilst this is useful when there's just whitespace changes, when applied to
source it is possible for a patch applied with fuzz to produce broken code which
still compiles (see #10450). This is obviously bad.
We'd like to eventually have do_patch() rejecting any fuzz on these grounds. For
that to be realistic the existing patches with fuzz need to be rebased and
reviewed.
Signed-off-by: Ross Burton <ross.burton@intel.com> Signed-off-by: Alexander Kanavin <alexander.kanavin@linux.intel.com> Signed-off-by: Ross Burton <ross.burton@intel.com>
Ross Burton [Fri, 9 Mar 2018 18:56:10 +0000 (20:56 +0200)]
cryptodev: refresh patches
The patch tool will apply patches by default with "fuzz", which is where if the
hunk context isn't present but what is there is close enough, it will force the
patch in.
Whilst this is useful when there's just whitespace changes, when applied to
source it is possible for a patch applied with fuzz to produce broken code which
still compiles (see #10450). This is obviously bad.
We'd like to eventually have do_patch() rejecting any fuzz on these grounds. For
that to be realistic the existing patches with fuzz need to be rebased and
reviewed.
Signed-off-by: Ross Burton <ross.burton@intel.com> Signed-off-by: Alexander Kanavin <alexander.kanavin@linux.intel.com> Signed-off-by: Ross Burton <ross.burton@intel.com>
Ross Burton [Fri, 9 Mar 2018 18:56:09 +0000 (20:56 +0200)]
blktrace: refresh patches
The patch tool will apply patches by default with "fuzz", which is where if the
hunk context isn't present but what is there is close enough, it will force the
patch in.
Whilst this is useful when there's just whitespace changes, when applied to
source it is possible for a patch applied with fuzz to produce broken code which
still compiles (see #10450). This is obviously bad.
We'd like to eventually have do_patch() rejecting any fuzz on these grounds. For
that to be realistic the existing patches with fuzz need to be rebased and
reviewed.
Signed-off-by: Ross Burton <ross.burton@intel.com> Signed-off-by: Alexander Kanavin <alexander.kanavin@linux.intel.com> Signed-off-by: Ross Burton <ross.burton@intel.com>
Ross Burton [Fri, 9 Mar 2018 18:56:08 +0000 (20:56 +0200)]
xorg-xserver: refresh patches
The patch tool will apply patches by default with "fuzz", which is where if the
hunk context isn't present but what is there is close enough, it will force the
patch in.
Whilst this is useful when there's just whitespace changes, when applied to
source it is possible for a patch applied with fuzz to produce broken code which
still compiles (see #10450). This is obviously bad.
We'd like to eventually have do_patch() rejecting any fuzz on these grounds. For
that to be realistic the existing patches with fuzz need to be rebased and
reviewed.
Signed-off-by: Ross Burton <ross.burton@intel.com> Signed-off-by: Alexander Kanavin <alexander.kanavin@linux.intel.com> Signed-off-by: Ross Burton <ross.burton@intel.com>
Ross Burton [Fri, 9 Mar 2018 18:56:06 +0000 (20:56 +0200)]
mesa: refresh patches
The patch tool will apply patches by default with "fuzz", which is where if the
hunk context isn't present but what is there is close enough, it will force the
patch in.
Whilst this is useful when there's just whitespace changes, when applied to
source it is possible for a patch applied with fuzz to produce broken code which
still compiles (see #10450). This is obviously bad.
We'd like to eventually have do_patch() rejecting any fuzz on these grounds. For
that to be realistic the existing patches with fuzz need to be rebased and
reviewed.
Signed-off-by: Ross Burton <ross.burton@intel.com> Signed-off-by: Alexander Kanavin <alexander.kanavin@linux.intel.com> Signed-off-by: Ross Burton <ross.burton@intel.com>
Ross Burton [Fri, 9 Mar 2018 18:56:05 +0000 (20:56 +0200)]
drm: refresh patches
The patch tool will apply patches by default with "fuzz", which is where if the
hunk context isn't present but what is there is close enough, it will force the
patch in.
Whilst this is useful when there's just whitespace changes, when applied to
source it is possible for a patch applied with fuzz to produce broken code which
still compiles (see #10450). This is obviously bad.
We'd like to eventually have do_patch() rejecting any fuzz on these grounds. For
that to be realistic the existing patches with fuzz need to be rebased and
reviewed.
Signed-off-by: Ross Burton <ross.burton@intel.com> Signed-off-by: Alexander Kanavin <alexander.kanavin@linux.intel.com> Signed-off-by: Ross Burton <ross.burton@intel.com>
Ross Burton [Fri, 9 Mar 2018 18:56:04 +0000 (20:56 +0200)]
gtk-doc: refresh patches
The patch tool will apply patches by default with "fuzz", which is where if the
hunk context isn't present but what is there is close enough, it will force the
patch in.
Whilst this is useful when there's just whitespace changes, when applied to
source it is possible for a patch applied with fuzz to produce broken code which
still compiles (see #10450). This is obviously bad.
We'd like to eventually have do_patch() rejecting any fuzz on these grounds. For
that to be realistic the existing patches with fuzz need to be rebased and
reviewed.
Signed-off-by: Ross Burton <ross.burton@intel.com> Signed-off-by: Alexander Kanavin <alexander.kanavin@linux.intel.com> Signed-off-by: Ross Burton <ross.burton@intel.com>
Ross Burton [Fri, 9 Mar 2018 18:56:03 +0000 (20:56 +0200)]
gnome: refresh patches
The patch tool will apply patches by default with "fuzz", which is where if the
hunk context isn't present but what is there is close enough, it will force the
patch in.
Whilst this is useful when there's just whitespace changes, when applied to
source it is possible for a patch applied with fuzz to produce broken code which
still compiles (see #10450). This is obviously bad.
We'd like to eventually have do_patch() rejecting any fuzz on these grounds. For
that to be realistic the existing patches with fuzz need to be rebased and
reviewed.
Signed-off-by: Ross Burton <ross.burton@intel.com> Signed-off-by: Alexander Kanavin <alexander.kanavin@linux.intel.com> Signed-off-by: Ross Burton <ross.burton@intel.com>
Ross Burton [Fri, 9 Mar 2018 18:56:02 +0000 (20:56 +0200)]
sysstat: refresh patches
The patch tool will apply patches by default with "fuzz", which is where if the
hunk context isn't present but what is there is close enough, it will force the
patch in.
Whilst this is useful when there's just whitespace changes, when applied to
source it is possible for a patch applied with fuzz to produce broken code which
still compiles (see #10450). This is obviously bad.
We'd like to eventually have do_patch() rejecting any fuzz on these grounds. For
that to be realistic the existing patches with fuzz need to be rebased and
reviewed.
Signed-off-by: Ross Burton <ross.burton@intel.com> Signed-off-by: Alexander Kanavin <alexander.kanavin@linux.intel.com> Signed-off-by: Ross Burton <ross.burton@intel.com>
Ross Burton [Fri, 9 Mar 2018 18:56:01 +0000 (20:56 +0200)]
rpcbind: refresh patches
The patch tool will apply patches by default with "fuzz", which is where if the
hunk context isn't present but what is there is close enough, it will force the
patch in.
Whilst this is useful when there's just whitespace changes, when applied to
source it is possible for a patch applied with fuzz to produce broken code which
still compiles (see #10450). This is obviously bad.
We'd like to eventually have do_patch() rejecting any fuzz on these grounds. For
that to be realistic the existing patches with fuzz need to be rebased and
reviewed.
Signed-off-by: Ross Burton <ross.burton@intel.com> Signed-off-by: Alexander Kanavin <alexander.kanavin@linux.intel.com> Signed-off-by: Ross Burton <ross.burton@intel.com>
Ross Burton [Fri, 9 Mar 2018 18:56:00 +0000 (20:56 +0200)]
newt: refresh patches
The patch tool will apply patches by default with "fuzz", which is where if the
hunk context isn't present but what is there is close enough, it will force the
patch in.
Whilst this is useful when there's just whitespace changes, when applied to
source it is possible for a patch applied with fuzz to produce broken code which
still compiles (see #10450). This is obviously bad.
We'd like to eventually have do_patch() rejecting any fuzz on these grounds. For
that to be realistic the existing patches with fuzz need to be rebased and
reviewed.
Signed-off-by: Ross Burton <ross.burton@intel.com> Signed-off-by: Alexander Kanavin <alexander.kanavin@linux.intel.com> Signed-off-by: Ross Burton <ross.burton@intel.com>
Ross Burton [Fri, 9 Mar 2018 18:55:59 +0000 (20:55 +0200)]
net-tools: refresh patches
The patch tool will apply patches by default with "fuzz", which is where if the
hunk context isn't present but what is there is close enough, it will force the
patch in.
Whilst this is useful when there's just whitespace changes, when applied to
source it is possible for a patch applied with fuzz to produce broken code which
still compiles (see #10450). This is obviously bad.
We'd like to eventually have do_patch() rejecting any fuzz on these grounds. For
that to be realistic the existing patches with fuzz need to be rebased and
reviewed.
Signed-off-by: Ross Burton <ross.burton@intel.com> Signed-off-by: Alexander Kanavin <alexander.kanavin@linux.intel.com> Signed-off-by: Ross Burton <ross.burton@intel.com>
Ross Burton [Fri, 9 Mar 2018 18:55:58 +0000 (20:55 +0200)]
ltp: refresh patches
The patch tool will apply patches by default with "fuzz", which is where if the
hunk context isn't present but what is there is close enough, it will force the
patch in.
Whilst this is useful when there's just whitespace changes, when applied to
source it is possible for a patch applied with fuzz to produce broken code which
still compiles (see #10450). This is obviously bad.
We'd like to eventually have do_patch() rejecting any fuzz on these grounds. For
that to be realistic the existing patches with fuzz need to be rebased and
reviewed.
Signed-off-by: Ross Burton <ross.burton@intel.com> Signed-off-by: Alexander Kanavin <alexander.kanavin@linux.intel.com> Signed-off-by: Ross Burton <ross.burton@intel.com>
Ross Burton [Fri, 9 Mar 2018 18:55:57 +0000 (20:55 +0200)]
ethtool: refresh patches
The patch tool will apply patches by default with "fuzz", which is where if the
hunk context isn't present but what is there is close enough, it will force the
patch in.
Whilst this is useful when there's just whitespace changes, when applied to
source it is possible for a patch applied with fuzz to produce broken code which
still compiles (see #10450). This is obviously bad.
We'd like to eventually have do_patch() rejecting any fuzz on these grounds. For
that to be realistic the existing patches with fuzz need to be rebased and
reviewed.
Signed-off-by: Ross Burton <ross.burton@intel.com> Signed-off-by: Alexander Kanavin <alexander.kanavin@linux.intel.com> Signed-off-by: Ross Burton <ross.burton@intel.com>
Ross Burton [Fri, 9 Mar 2018 18:55:56 +0000 (20:55 +0200)]
cups: refresh patches
The patch tool will apply patches by default with "fuzz", which is where if the
hunk context isn't present but what is there is close enough, it will force the
patch in.
Whilst this is useful when there's just whitespace changes, when applied to
source it is possible for a patch applied with fuzz to produce broken code which
still compiles (see #10450). This is obviously bad.
We'd like to eventually have do_patch() rejecting any fuzz on these grounds. For
that to be realistic the existing patches with fuzz need to be rebased and
reviewed.
Signed-off-by: Ross Burton <ross.burton@intel.com> Signed-off-by: Alexander Kanavin <alexander.kanavin@linux.intel.com> Signed-off-by: Ross Burton <ross.burton@intel.com>
Ross Burton [Fri, 9 Mar 2018 18:55:55 +0000 (20:55 +0200)]
tcf-agent: refresh patches
The patch tool will apply patches by default with "fuzz", which is where if the
hunk context isn't present but what is there is close enough, it will force the
patch in.
Whilst this is useful when there's just whitespace changes, when applied to
source it is possible for a patch applied with fuzz to produce broken code which
still compiles (see #10450). This is obviously bad.
We'd like to eventually have do_patch() rejecting any fuzz on these grounds. For
that to be realistic the existing patches with fuzz need to be rebased and
reviewed.
Signed-off-by: Ross Burton <ross.burton@intel.com> Signed-off-by: Alexander Kanavin <alexander.kanavin@linux.intel.com> Signed-off-by: Ross Burton <ross.burton@intel.com>
Ross Burton [Fri, 9 Mar 2018 18:55:54 +0000 (20:55 +0200)]
ruby: refresh patches
The patch tool will apply patches by default with "fuzz", which is where if the
hunk context isn't present but what is there is close enough, it will force the
patch in.
Whilst this is useful when there's just whitespace changes, when applied to
source it is possible for a patch applied with fuzz to produce broken code which
still compiles (see #10450). This is obviously bad.
We'd like to eventually have do_patch() rejecting any fuzz on these grounds. For
that to be realistic the existing patches with fuzz need to be rebased and
reviewed.
Signed-off-by: Ross Burton <ross.burton@intel.com> Signed-off-by: Alexander Kanavin <alexander.kanavin@linux.intel.com> Signed-off-by: Ross Burton <ross.burton@intel.com>
Ross Burton [Fri, 9 Mar 2018 18:55:52 +0000 (20:55 +0200)]
qemu: refresh patches
The patch tool will apply patches by default with "fuzz", which is where if the
hunk context isn't present but what is there is close enough, it will force the
patch in.
Whilst this is useful when there's just whitespace changes, when applied to
source it is possible for a patch applied with fuzz to produce broken code which
still compiles (see #10450). This is obviously bad.
We'd like to eventually have do_patch() rejecting any fuzz on these grounds. For
that to be realistic the existing patches with fuzz need to be rebased and
reviewed.
Signed-off-by: Ross Burton <ross.burton@intel.com> Signed-off-by: Alexander Kanavin <alexander.kanavin@linux.intel.com> Signed-off-by: Ross Burton <ross.burton@intel.com>
Ross Burton [Fri, 9 Mar 2018 18:55:51 +0000 (20:55 +0200)]
python: refresh patches
The patch tool will apply patches by default with "fuzz", which is where if the
hunk context isn't present but what is there is close enough, it will force the
patch in.
Whilst this is useful when there's just whitespace changes, when applied to
source it is possible for a patch applied with fuzz to produce broken code which
still compiles (see #10450). This is obviously bad.
We'd like to eventually have do_patch() rejecting any fuzz on these grounds. For
that to be realistic the existing patches with fuzz need to be rebased and
reviewed.
Signed-off-by: Ross Burton <ross.burton@intel.com> Signed-off-by: Alexander Kanavin <alexander.kanavin@linux.intel.com> Signed-off-by: Ross Burton <ross.burton@intel.com>
Ross Burton [Fri, 9 Mar 2018 18:55:50 +0000 (20:55 +0200)]
opkg-utils: refresh patches
The patch tool will apply patches by default with "fuzz", which is where if the
hunk context isn't present but what is there is close enough, it will force the
patch in.
Whilst this is useful when there's just whitespace changes, when applied to
source it is possible for a patch applied with fuzz to produce broken code which
still compiles (see #10450). This is obviously bad.
We'd like to eventually have do_patch() rejecting any fuzz on these grounds. For
that to be realistic the existing patches with fuzz need to be rebased and
reviewed.
Signed-off-by: Ross Burton <ross.burton@intel.com> Signed-off-by: Alexander Kanavin <alexander.kanavin@linux.intel.com> Signed-off-by: Ross Burton <ross.burton@intel.com>
Ross Burton [Fri, 9 Mar 2018 18:55:49 +0000 (20:55 +0200)]
m4: refresh patches
The patch tool will apply patches by default with "fuzz", which is where if the
hunk context isn't present but what is there is close enough, it will force the
patch in.
Whilst this is useful when there's just whitespace changes, when applied to
source it is possible for a patch applied with fuzz to produce broken code which
still compiles (see #10450). This is obviously bad.
We'd like to eventually have do_patch() rejecting any fuzz on these grounds. For
that to be realistic the existing patches with fuzz need to be rebased and
reviewed.
Signed-off-by: Ross Burton <ross.burton@intel.com> Signed-off-by: Alexander Kanavin <alexander.kanavin@linux.intel.com> Signed-off-by: Ross Burton <ross.burton@intel.com>
Ross Burton [Fri, 9 Mar 2018 18:55:48 +0000 (20:55 +0200)]
i2c-tools: refresh patches
The patch tool will apply patches by default with "fuzz", which is where if the
hunk context isn't present but what is there is close enough, it will force the
patch in.
Whilst this is useful when there's just whitespace changes, when applied to
source it is possible for a patch applied with fuzz to produce broken code which
still compiles (see #10450). This is obviously bad.
We'd like to eventually have do_patch() rejecting any fuzz on these grounds. For
that to be realistic the existing patches with fuzz need to be rebased and
reviewed.
Signed-off-by: Ross Burton <ross.burton@intel.com> Signed-off-by: Alexander Kanavin <alexander.kanavin@linux.intel.com> Signed-off-by: Ross Burton <ross.burton@intel.com>
Due to patch fuzz, it was applied again, so the same code sequence was
repeated twice. Not sure if that caused any bugs, but certainly wasn't
the right thing to do.
Signed-off-by: Alexander Kanavin <alexander.kanavin@linux.intel.com> Signed-off-by: Ross Burton <ross.burton@intel.com>
Ross Burton [Fri, 9 Mar 2018 18:55:46 +0000 (20:55 +0200)]
e2fsprogs: refresh patches
The patch tool will apply patches by default with "fuzz", which is where if the
hunk context isn't present but what is there is close enough, it will force the
patch in.
Whilst this is useful when there's just whitespace changes, when applied to
source it is possible for a patch applied with fuzz to produce broken code which
still compiles (see #10450). This is obviously bad.
We'd like to eventually have do_patch() rejecting any fuzz on these grounds. For
that to be realistic the existing patches with fuzz need to be rebased and
reviewed.
Signed-off-by: Ross Burton <ross.burton@intel.com> Signed-off-by: Alexander Kanavin <alexander.kanavin@linux.intel.com> Signed-off-by: Ross Burton <ross.burton@intel.com>
The patch was applied in a completely incorrect spot (due to fuzz),
no one noticed or complained. Meanwhile upstream says the issue
has been resolved differently:
https://rt.openssl.org/Ticket/Display.html?id=3759&user=guest&pass=guest
Signed-off-by: Alexander Kanavin <alexander.kanavin@linux.intel.com> Signed-off-by: Ross Burton <ross.burton@intel.com>
projects / thirdparty / openembedded / openembedded-core-contrib.git / log
