Go only supports shared libraries for some architectures, so
add a variable for use elsewhere that gets a non-null value
only for those architectures.
(From OE-Core rev: 2275712df152b73ce49b36bdf9f8d744c68c9c50)
Signed-off-by: Matt Madison <matt@madison.systems>
Signed-off-by: Otavio Salvador <otavio@ossystems.com.br>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
meta-oe was doing this before, but it was triggering a yocto-compat-script
failure during the signature checking.
The ca-certificates changing is ABISAFE, as the certificates themselves do
not modify the compiles behavior of the applications. This should permit
easier upgrades without as much rebuilding.
The original value was set in meta-oe by commit
ff7a4b13c4efeffc5853a93c6ff7265fa3d6c143.
(From OE-Core rev: 583dca290c230fbc981c41fe91e8abeff616e633)
Signed-off-by: Mark Hatle <mark.hatle@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
When these functions are being called INSANE_SKIP has already been taken into
account, so don't confuse the code by passing the skip list.
(From OE-Core rev: 0001ceead406b1e8ba4fd16d0ecb5fbf5b55ba66)
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
A recipe added with "devtool add" requires to be able to take precedence on recipes
previously defined with PREFERRED_PROVIDER.
By adding the parameter "--provides" to "devtool add" it is possible to specify
an element to be provided by the recipe. A devtool recipe can override a previous
PREFERRED_PROVIDER using the layer configuration file in the workspace.
E.g.
devtool add my-libgl git@git://my-libgl-repository --provides virtual/libgl
[YOCTO #10415]
(From OE-Core rev: adeea2fe6895898a5e6006e798898f0f5dabd890)
Signed-off-by: Juan M Cruz Alcaraz <juan.m.cruz.alcaraz@linux.intel.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
epitest.fi is down and hostap-utils source is now available in
w1.fi. So, move SRC_URI to https://w1.fi
Since hostap-utils is only meant for old Intersil Prism2/2.5/3 wifi cards,
this recipe will be removed from oe-core in future (most likely to
meta-handheld)
[YOCTO #12051]
(From OE-Core rev: 541b14c58132e8460a762617889bd5e3d736c1a4)
Signed-off-by: Maxin B. John <maxin.john@intel.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
After commit e8b1c65394, we started seeing
errors like the following during boot on genericx86 machines:
uvesafb: failed to execute /sbin/v86d
uvesafb: probe of uvesafb.0 failed with error -22
uvesafb: vbe_init() failed with -22
uvesafb: Getting VBE info block failed (eax=0x4f00, err=-2)
These were caused because the uvesa module was being loaded during boot,
when it is only meant to be loaded on qemu according to:
6af89812e8
Since genericx86-common.inc includes qemuboot-x86, the module also tries
to be loaded on genericx86 machines, this patch removes the instruction from
qemuboot-x86 and adds it in specific to both qemux86 machines confs so
it is correctly loaded only on those.
[YOCTO #11879]
(From OE-Core rev: 261f9c382121c73b72556a151fdd4c7938b32a92)
(From OE-Core rev: 554903483acb4af402feaba013366388db89e36b)
Signed-off-by: Alejandro Hernandez <alejandro.hernandez@linux.intel.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
There is an issue for requesting dynamic IP with ifup/ifdown command
when using dhclient.
Steps to reproduce:
1. Build a full-cmdline image and install dhcp-client as the default DHCP client.
2. Configure a static IP for eth0 in /etc/networking/interfaces and reboot.
$ ifconfig eth0
eth0 inet addr:192.168.1.2 Bcast:192.168.1.255 Mask:255.255.255.0
$ ifdown eth0
3. Modify /etc/networking/interfaces to configure a dynamic IP for eth0
$ ifup eth0
$ ifconfig eth0
eth0 inet addr:192.168.1.2 Bcast:192.168.1.255 Mask:255.255.255.0
You could see the eth0 still has a static IP. But actually it also has a
dynamic IP:
$ ip addr show eth0
eth0:
inet 192.168.1.2/24 brd 192.168.1.255 scope global eth0
inet 128.224.162.173/23 brd 128.224.163.255 scope global eth0
The root cause is the ifdown invokes "ifconfig" to down the eth0 but
doesn't remove its IP. The dhclient would invoke "ip" to configure the
interface. It can not remove an IP from down interface with "ip addr
flush" and "ip addr add" command can set multiple IPs on one interface.
To fix this issue, we should use the "ip" command to implement
ifup/ifdown, rather than using the older "ifconfig". It will flush the
IP before down the interface.
(From OE-Core rev: 4304ed013a015bfb6f054017cb273578b874b4c2)
Signed-off-by: Yi Zhao <yi.zhao@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The Device Tree is commonly used but it is still kept as a .inc file
instead of a proper class. Instead now we move the Device Tree code to
a kernel-devicetree class and automatically enable it when the
KERNEL_DEVICETREE variable is set.
To avoid breakage in existing layers, we kept a linux-dtb.inc file
which raises a warning telling the user about the change so in next
release this can be removed.
(From OE-Core rev: 03a00be7f2062aefef0e51ef20a4c9737f6685e7)
Signed-off-by: Otavio Salvador <otavio@ossystems.com.br>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
We need QEMU PID in order to access "/proc/<qemupid>/cmdline"
Having a valid QEMU PID does not mean we can access the proc entry
immediately, we need to wait for the /proc/<qemupid> to appear
before we can access it.
(From OE-Core rev: d2d069fa9910d1c7a94c898355a63fca03ec5ad8)
Signed-off-by: Juro Bystricky <juro.bystricky@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The code in scriptutils which implements the logic for running the
editor used by devtool edit-recipe looks at the VISUAL environment
variable before EDITOR, and thus if VISUAL is set in the environment it
will override the EDITOR value we are setting here, the editor (usually
vim) launches and there's nothing to stop it running forever short of
manually killing it. Set VISUAL instead to fix this.
Apparently VISUAL is in fact the variable we should really be preferring
here - I don't think I knew that but somehow I got it right in the code,
just not in the test. Here are the details for the curious:
https://unix.stackexchange.com/questions/4859/visual-vs-editor-whats-the-difference
Fixes [YOCTO #12074].
(From OE-Core rev: 6a7c50def569b5e86aa17bd9b287e8c63781dcb0)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Updated the kernel development flow diagram to have an arrow from
the repositories to the box that says you need to clone the
kernel repository. Also, provided some wording changes in the
end of the chapter.
(From yocto-docs rev: c77cff4f7b0795d5429dc47c2ad63aec6d19d513)
Signed-off-by: Scott Rifenbark <srifenbark@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
I added the linux-yocto-4.12 kernel repository and the linux-yocto-cache
repository to the list of Yocto Linux Kernel repositories in the
Source Repositories.
(From yocto-docs rev: 88fedda0fa4a4dfc468f0dc404fa9f04390cbed7)
Signed-off-by: Scott Rifenbark <srifenbark@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Switching to kernel version 4.12. Pulled some old commented
stuff out.
(From yocto-docs rev: c0a5c886256d3477ddaf670df4939bec1c73152e)
Signed-off-by: Scott Rifenbark <srifenbark@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Added in a sentence to point to the kernel-dev manual should
the user be interested in kernel development.
(From yocto-docs rev: cc47606af5b7eb2fdc669aa2c0c4dfbd930b8247)
Signed-off-by: Scott Rifenbark <srifenbark@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
I moved the flow diagram up higher and completely removed
the procedures to get the build host ready for kernel
development. Those are now in the common tasks chapter.
Lots of rewriting
Signen-off-by: Scott Rifenbark <srifenbark@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Had to account for devtool and traditional kernel methods
now.
(From yocto-docs rev: 74580d9a61fa012406059ba2a3348d38fdc24d4c)
Signed-off-by: Scott Rifenbark <srifenbark@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Fixes [YOCTO #11762]
Added a link from variable to new virtual providers
section.
(From yocto-docs rev: d87726cf4962ca093c63d23d9e04f41d448c9594)
Signed-off-by: Kristi Rifenbark <kristi.rifenbark@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Fixes [YOCTO #12031]
Applied minor wording changes based on review feedback.
(Bitbake rev: f0930f3216a8358759d561d244fa280932e8bf05)
Signed-off-by: Scott Rifenbark <srifenbark@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Fixes [YOCTO #12029]
There were four links to an old blog post that was leveraged
for the hello world example. The post has evidently been
removed and the links no longer resolved. I have taken them out.
(Bitbake rev: db298262189c94be700abfdb8c2ad7827b53afca)
Signed-off-by: Scott Rifenbark <srifenbark@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Fixes [YOCTO #12031]
Moved an inappropriate example from the bottom of the INHERIT
Configuration Directive section up into the inherit directive
section.
Updated the example at the end of the INHERIT Configuration
Directive section to apply to INHERIT.
(Bitbake rev: f169ac5da18d55a40d0554668e1a0ace70f94768)
Signed-off-by: Scott Rifenbark <srifenbark@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Fixes [YOCTO #12032]
I applied some re-writing to help clarify the relationships between
the inherit, include, and require directives.
(Bitbake rev: fded970a0709d928f70224d8b61534e9353ee6dd)
Signed-off-by: Scott Rifenbark <srifenbark@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Printing the last 10 lines of bitbake-cookerdaemon.log when the server
fails to start can sometimes result in printing the output from a
previous run, which could lead the user completely down the wrong path
in terms of the cause of the failure. Use a known start text containing
the time which we can then look for when scanning through the log, and
then grab the last 10 lines of that part instead.
Fixes [YOCTO #11903].
(Bitbake rev: 567f2cf1bc455b4f3cfb1cbd7f25145360b05a62)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The whitelist shouldn't have to be populated in order for the
enforcement to work properly - check if the list is not None in order to
determine whether the functionality is enabled or not since that is how
the function that sets up the list behaves.
(Bitbake rev: 7b1e79c352ca6eef1693d8abfacf7505544f1caa)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Issues in start are not being correctly detected by the current readypipe
code. Change it to use specific "ready" or "fail" messages to correctly
determine the correct failure mode and avoid bitbake seeming to hang
(it does currently timeout eventually).
[YOCTO #12062]
(Bitbake rev: 60d4791e3dd05729d2a2adf6f3b203c80d466a73)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Enable cross-canadian builds of the Go toolchain. This
requires an additional patch to the Go source to allow us
to use the native GOTOOLDIR during the bootstrap phase.
(From OE-Core rev: 9daa02f63a0d53ab90a515f2bd3e783187c9415b)
Signed-off-by: Matt Madison <matt@madison.systems>
Signed-off-by: Otavio Salvador <otavio@ossystems.com.br>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
