Debian anonscm service in Alioth is shutdown and thus
fetching sources fails.
https://wiki.debian.org/Alioth
"Alioth is broken, and there is nobody around to fix it. Don't ask the remaining people who give it life support to implement fixes and changes. It is being replaced by a cocktail of ?GitLab (see Salsa), read-only repos and keep-alive mechanisms. See below for more information."
https://wiki.debian.org/Salsa
"What is Salsa?
Salsa is the name of a collaborative development server for Debian based on the gitlab software. Salsa is supposed to provide the necessary tools for package maintainers, packaging teams and other Debian related individuals and groups for collaborative development.
What is the status of Salsa?
After various discussions about the future of Alioth, the Alioth Sprint in August 2017 gave birth to the initial setup of the the upcoming Salsa service. The productive weekend resulted in a working prototype and was launched as a beta in December 2017. It left its beta status in January 2018."
(From OE-Core rev: 08ff7b42d8b7d06ef61255185c95e900ada8769b)
Signed-off-by: Mikko Rapeli <mikko.rapeli@bmw.de>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Debian anonscm service in Alioth is shutdown and thus
fetching ca-certificates sources fails.
https://wiki.debian.org/Alioth
"Alioth is broken, and there is nobody around to fix it. Don't ask the remaining people who give it life support to implement fixes and changes. It is being replaced by a cocktail of ?GitLab (see Salsa), read-only repos and keep-alive mechanisms. See below for more information."
(From OE-Core rev: fc20ff2003cee7ee3b78ba3bc236a60a8caabc35)
Signed-off-by: Mikko Rapeli <mikko.rapeli@bmw.de>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Debian anonscm service in Alioth is shutdown and thus
fetching ncurses sources fails.
https://wiki.debian.org/Alioth
"Alioth is broken, and there is nobody around to fix it. Don't ask the remaining people who give it life support to implement fixes and changes. It is being replaced by a cocktail of ?GitLab (see Salsa), read-only repos and keep-alive mechanisms. See below for more information."
(From OE-Core rev: 8fab5794218445ddb3e8f73a74fa3f130e7c42f6)
Signed-off-by: Mikko Rapeli <mikko.rapeli@bmw.de>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Backport fix from qemu mainline for intermediate qemuarm64 hang
issue. Root caused in OE environment, issue with aarch64 qemu
logic of executing instructions that reenabe interrupts. See patch
commit message for more details.
Upstream-Status: Backport
(From OE-Core rev: aa33945fc7cf7bfa859c4091bcfa2695c422849b)
Signed-off-by: Victor Kamensky <kamensky@cisco.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Apparently there are recipes in the wild which generate files with
filenames containing '$' characters - which cause errors during
packaging.
Instead of adding another special case to escape '$' characters when
constructing the command passed to oe.utils.getstatusoutput(), switch
to using single quotes to quote the path - and therefore make isELF()
consistent with the way filenames and paths are quoted by every other
caller of oe.utils.getstatusoutput() in oe-core.
(From OE-Core rev: 7877761534b0c2492da6289e9f2269d41b6ed464)
Signed-off-by: Andre McCurdy <armccurdy@gmail.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Although get_filesystem_id() is a private API and never gets passed
a path containing spaces or other special characters, etc, quote the
path anyway for consistency.
(From OE-Core rev: 1a9878cdb1cdb807c47e852b780c8ef9b93a214e)
Signed-off-by: Andre McCurdy <armccurdy@gmail.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Fix non-void function 'fix_options' should return a value.
Add function prototype to tcpd.c and miscd.c.
(From OE-Core rev: 01590c04e875968a7137a67d1683c503a6bad396)
Signed-off-by: Oleksiy Obitotskyy <oobitots@cisco.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
With 4.15 kernel systemtap needs update to address systemtap module
compilation issues. It is fixed in later version of systemtap by
PR22551.
Upstream-Status: Backport
(From OE-Core rev: 7425d03729507ac5aff3c75ba20e749beaf3a3d5)
Signed-off-by: Victor Kamensky <kamensky@cisco.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Use ext4 filesystem instead of ext3 when using the live image to install
on target. wic defaults to ext4 as well.
(From OE-Core rev: db6c3d681807cfef098ead1db098f5268e1eb055)
Signed-off-by: Anuj Mittal <anuj.mittal@intel.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* Fix RDEPENDS
* Upstream v1.12_9 is a development version, not a stable release
* Add UPSTREAM_CHECK_REGEX skip development releases
* Drop anonymous python function to "fix" version, which breaks
auto-upgrade-helper (AUH)
* Use LICENSE file for checksum rather than ephemeral META.yml
* License remains the same
Fixes: [YOCTO #12581]
License-Update: use LICENSE file for checksum
(From OE-Core rev: 613fa79adff798e29ec7f72bff6f060a1832bc89)
Signed-off-by: Tim Orling <timothy.t.orling@linux.intel.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Pseudo is using a custom configure script that detects if it shall build with
extended file attribute support or not. The check is done by simply calling
'getfattr' provided by attr-native which is not part of the dependency list.
Due to the recent changes (recipe specific sysroot & cleanup of $PATH) this
call fails now when the recipe is being build for the first time (at least
when being build for nativesdk case). Explicitly setting up a dependency to
attr-native just to satisfy configure would be wrong also since the real
dependency is to attr/nativesdk-attr which are already part of the dependency
list (see DEPENDS). Therefore bypass the test in the configure by explicitly
enabling xattr using a configure option available in any case.
(From OE-Core rev: a7381eb16ba2183ed990a009bb8e82b4702f3d98)
Signed-off-by: Andreas Kaufmann <andreas.kaufmann.79@gmail.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The 'glamor' PACKAGECONFIG in xserver-xorg creates a dependency on libgbm
which can be satisfied in some cases by mesa, in others by blobs such as mali.
(From OE-Core rev: 5f8050722169a931b8e9078b8757216ba7a84506)
Signed-off-by: Trevor Woerner <twoerner@gmail.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Mesa only PROVIDES these features if they are enabled via PACKAGECONFIG.
Therefore make the PROVIDES conditional depending on whether or not these
features have been enabled.
(From OE-Core rev: 8b1e57eb8c959c0f0a5d9a7e0c2e0811c515ea08)
Signed-off-by: Trevor Woerner <twoerner@gmail.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
replace_glibc_check_with_linux.patch was accepted upstream with
modifications.
(From OE-Core rev: 94cf27ebc5d3e3fafa85f3bb1ca54f606bb411ad)
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>
This version has been published at March 21, 2018, and it is a bugfix
only release. It includes several important fixes that were made as
part of 18.0.0 development cycle.
Full list of bug fixes can be see online at:
https://www.mesa3d.org/relnotes/17.3.7.html
(From OE-Core rev: 3601c079e15f3570b9b90cd8775e4e90175d1bb5)
Signed-off-by: Otavio Salvador <otavio@ossystems.com.br>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This string is now being presented as "bsp_root_name" in the YP
manual set. A BSP name is essentially "meta-bsp_root_name".
It was being presented in the manual set as "meta-bsp_name",
which is not technically correct.
(From yocto-docs rev: 9ad25836b2b3ca79aa3430be014871f50205cf9e)
Signed-off-by: Scott Rifenbark <srifenbark@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Fixed the way we refer to a BSP name. It is really
"meta-<bsp_root_name>" rather than "meta-<bsp_name>". The
name is the whole string and not just the root name.
Also added a tip on ordering the layers in the BBLAYERS
variable in the bblayers.conf file. Order is important.
(From yocto-docs rev: 9c56238295f5631c496377616ea98b860253e6f7)
Signed-off-by: Scott Rifenbark <srifenbark@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This is a layer that contains other layers
(From yocto-docs rev: 0cd1881c18e8a63d5f2f078b03fe4e89fd9c75b5)
Signed-off-by: Scott Rifenbark <srifenbark@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Reality dictates that the YP does not treat layer naming consistently.
Layers are talked about as the "meta-whatever" layer and never the
"whatever" layer. However, the tooling sometimes appends or uses
just the "whatever" part of the layer name. A good example is the
meta-yocto-bsp configuration file. All the variables in there use
just the root name of a layer's name. In the manuals, I had been
distinguishing the layer name as just the "whatever" part sans
"meta-". I talked about the convention of using "meta-" in front
of layer names, etc. Well, this is confusing in light of how everyone
says a layer's name is "meta-whatever". So, I fixed all this up.
(From yocto-docs rev: 79e52f6ccf4246fc69a460ce9d3a4a18720a9442)
Signed-off-by: Scott Rifenbark <srifenbark@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Split this section into two sections: one for creating the layer
using bitbake-layers create-layer and one for adding the layer
to bblayers.conf using bitbake-layers add-layer.
Needed to update some references in the yocto-project-qs and
kernel-dev manuals.
(From yocto-docs rev: 741a29b0cbeaaeaa0ac9155036ace2623938aee3)
Signed-off-by: Scott Rifenbark <srifenbark@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Fixes [YOCTO #12419]
In the section on runtime package management, I created a "Tip"
box to tell the user about using a location for the package
index information outside of the "deploy" area of the hosts
build directory.
(From yocto-docs rev: 2aee814d3d3ed4052fca332693d5416907ae640e)
Signed-off-by: Scott Rifenbark <srifenbark@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Provided some key links to help clarify content.
(From yocto-docs rev: 8d27b9946dad89729d30497bcc4de26b9a5c87d9)
Signed-off-by: Scott Rifenbark <srifenbark@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Fixes [YOCTO #12419]
This section was unclear and needed some work. I added text to
help clear things up.
(From yocto-docs rev: 54358a39a5710dbd0cbcfe8dafd2f641ec3863ef)
Signed-off-by: Scott Rifenbark <srifenbark@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Added the fact that this variable is really optional. If you
don't use it then you are setting up a package feed URI that
will include all supported arcchitectures for the package.
Using it means you are setting up specific URIs for specific
architectures.
Added a "Tip" note box to show how you can use the variable
to whitelist architectures.
(From yocto-docs rev: 009f3551aa61aaf6459fd24105a2e06511b59da3)
Signed-off-by: Scott Rifenbark <srifenbark@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
I created a two-bullet "Caution" note to highlight the stuff a
user needs to be aware of that can cause problems.
(From yocto-docs rev: 553bc13e5fd350adb15400afe170e587965929db)
Signed-off-by: Scott Rifenbark <srifenbark@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
I took out the sections at the end of the manual that talked
about the yocto-kernel tool. This tool is no longer maintained
and there is no equivalent tool. I also fixed the yocto-bsp
tool to be the bitbake-layers tool. This involved some
consolidation of sections.
I fixed some links in the kernel-dev and toaster-manual.
(From yocto-docs rev: 20cda99b301b6327d816c4a4cfb3511ad25c987c)
Signed-off-by: Scott Rifenbark <srifenbark@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Updated this section with minor edits.
(From yocto-docs rev: 1bc1dcda5fbab4a66737653164222f4fc5a7289c)
Signed-off-by: Scott Rifenbark <srifenbark@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This section had several out-of-date items. They are all up
to date now.
(From yocto-docs rev: 247f3eceeccc645a1b556aea433d4cf66399e962)
Signed-off-by: Scott Rifenbark <srifenbark@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Made changes to sync the raspberrypi BSP example to what is
really in the source directories. It was pretty out of date.
Made some minor edits to the sections describing the framework
of the BSP.
(From yocto-docs rev: b222d0988cb365cb1943ee1857e5cfd6b9fe173a)
Signed-off-by: Scott Rifenbark <srifenbark@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Applied some edits to make the section more up-to-date. Dumped
minnow as a BSP example for raspberrypi.
(From yocto-docs rev: a40515bad28d07d736e1ddd1832c19b074749d53)
Signed-off-by: Scott Rifenbark <srifenbark@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Added more relevant information around the discussion of BSP
layers.
(From yocto-docs rev: 8ca439b0bbfdcf390edb723fd12e8a00d90024e3)
Signed-off-by: Scott Rifenbark <srifenbark@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The example that creates a layer using bitbake-layers had old
output. Updated it.
(From yocto-docs rev: c58d738a59f113f8fffe0fc40b22e06b9d96cb6f)
Signed-off-by: Scott Rifenbark <srifenbark@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This reference to tools to help upgrade now exists with the
creation of the section in the dev-manual that talks about how to
upgrade recipes. I converted the bullet item here in the QS to
point to the actual section.
(From yocto-docs rev: b3d8895fefb99799a7c06abff5cc1604530ee36a)
Signed-off-by: Scott Rifenbark <srifenbark@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Ross Burton
Sascha Silbe
akuster@mvista.com
Armin Kuster
Mikko Rapeli
Victor Kamensky
Andre McCurdy
Khem Raj
Oleksiy Obitotskyy
Anuj Mittal
Tim Orling
Andreas Kaufmann
Trevor Woerner
Maxin B. John
Otavio Salvador
Scott Rifenbark