| Age | Commit message (Collapse) | Author |
|---|
|
Previously, when building core-image-minimal, the rootfs size would
default to 64M because we use '?=' in bitbake.conf and also '?=' in
core-image-minimal.bb.
The thing is, we'd like to have a default value for all images set
in bitbake.conf but still allow each image recipe to set its own default
value which could be overridden by users in local.conf.
Signed-off-by: Chen Qi <Qi.Chen@windriver.com>
|
|
glibc 2.20+ wont support any older than that
Signed-off-by: Khem Raj <raj.khem@gmail.com>
|
|
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
Might as well move this default to the class which uses it allowing
for easier reading/understanding of the class.
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
Currently its near impossible for other classes to sanely override
this value with their own default. By setting a weak default we can
allow other classes to change the default and allow end recipes to
again override this.
As far as I can tell, there shouldn't be any regressions from this
change.
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
A few native scipts requires bash-native, and we don't build
bash-native, so add it to ASSUME_PROVIDED.
Signed-off-by: Robert Yang <liezhi.yang@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
When adding patches or config files from bbappend files, it requires
the use of FILESEXTRAPATHS, which has been an issue and failure point
for people starting to work with bitbake and oe-core.
We add checking to standardize how to use FILESEXTRAPATHS. Only the
format of:
FILESEXTRAPATHS_append := ":${THISDIR}/Your_Files_Path" or
FILESEXTRAPATHS_prepend := "${THISDIR}/Your_Files_Path:"
is acceptable.
[YOCTO #5412]
Signed-off-by: Hongxu Jia <hongxu.jia@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
Currently, BB_NUMBER_THREADS and PARALLEL_MAKE default to unset and
are set in local.conf. Now that we have the automatic probing,
the default values can be set in bitbake.conf and an example of
explicitly defining how many tasks to run can be moved to
local.conf.sample.extended.
[YOCTO #6217]
Signed-off-by: Roxana Ciobanu <roxana.ciobanu@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
* Check the rootfs size against IMAGE_ROOTFS_MAXSIZE (if set)
* Add comments for IMAGE_ROOTFS_SIZE to not confuse with IMAGE_ROOTFS_MAXSIZE
[YOCTO #2610]
Signed-off-by: Robert Yang <liezhi.yang@windriver.com>
Signed-off-by: Saul Wold <sgw@linux.intel.com>
|
|
pkglibexecdir is a fairly common location for package-specific binaries (in
automake this is $libexecdir/$PACKAGE), and binaries in there are already
installed to FILES_PN, so add the corresponding .debug directory to
FILES_PN-dbg.
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
For most users this commit will have no effect. But if you come across the idea of giving
different names for paths, you'll get some troubles.
When a recipe inherit native, properly define bindir, sbindir, includedir, sysconfdir, datadir
(using xxxdir_native definitions from meta/conf/bitbake.conf).
For example, edit "${BASE_WORKDIR}/${MULTIMACH_TARGET_SYS}/quilt-native/temp/log.do_configure"
and see what are the arguments given by oe_runconf.
Notice that ${docdir}, ${mandir}, ${infodir}, ${localstatedir} have no associated _native definition.
Signed-off-by: Matthieu Crapet <Matthieu.Crapet@ingenico.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
The QEMU_OPTIONS variables belong in qemu.bbclass so move them there. The
only users of them inherit qemu.bbclass. There is no point in pushing
these into every recipe.
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
Currently, qemuppc prints warnings about gdk-pixbuf postinstalls
not working due to illegal instructions. This is due to qemu
running with the wrong cpu type. Add an option for ppc7400 so
that qemuppc works correctly.
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
To unpack that to more than a single line: -native and -cross recipes are made
to use the dummy Texinfo utilities provided by texinfo-dummy-native if they
invoke those utilities at build time. The target-architecture (cross-compiled)
recipes still use the genuine Texinfo utilites. Right now, they still use
the host system's Texinfo utilities, but could be made to use the
texinfo-native recipe we already ship with some config file changes.
Signed-off-by: Max Eliaser <max.eliaser@intel.com>
Signed-off-by: Saul Wold <sgw@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
If we don't do this, we see an exception:
ERROR: Failure expanding variable MACHINE_ARCH, expression was ${@[d.getVar('TUNE_PKGARCH', True),
d.getVar('MACHINE', True)][bool(d.getVar('MACHINE', True))].replace('-', '_')} which triggered
exception AttributeError: 'NoneType' object has no attribute 'replace'
Setting a default value avoids this error and allows the sanity checker
to trigger instead.
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
* Set default to http://search.cpan.org/CPAN/, as it should be
Signed-off-by: Tim Orling <TicoTimo@gmail.com>
Signed-off-by: Saul Wold <sgw@linux.intel.com>
|
|
* The SRC_URI is not accessible.
So need to add mirror site referred by the original site.
* The problem is that
http://download.savannah.gnu.org/releases redirects to closest mirror
and few mirrors (e.g. .jp) weren't working correctly while
http://download-mirror.savannah.gnu.org/releases/ seems to be reliable.
* Add SAVANNAH_GNU_MIRROR and SAVANNAH_NONGNU_MIRROR variable in bitbake.conf.
* Change the SRC_URI using the new variable.
Signed-off-by: Changhyeok Bae <changhyeok.bae@lge.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
This allows them to co-exist together in the native sysroot, with one
set of cross tools per target architecture.
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
This patch adds the bitbake qemu option for the ppc e6500 &
ppc e6500-64b architectures.
Signed-off-by: Valentin Cobelea <valentin.cobelea@enea.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
The problem is that do_configure.sigdata depends on STAMPS_DIR because:
do_configure -> STAMPCLEAN -> STAMPS_DIR
this will make the sigdata generated by "STAMPS_DIR=/tmp/stps bitbake -S
recipe" doesn't match the ones in our build dir, but it should. We can
add STAMPS_DIR or STAMPCLEAN to BB_HASHBASE_WHITELIST to fix the
problem, but we can't add STAMPS_DIR since once it is in
BB_HASHBASE_WHITELIST, the "STAMPS_DIR=/tmp/stps bitbake -S recipe"
would not run again.
[YOCTO $6031]
Signed-off-by: Robert Yang <liezhi.yang@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
We don't want the value of this varflag itself entering any signatures,
ever.
Part of the fix for [YOCTO #5897].
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Saul Wold <sgw@linux.intel.com>
|
|
Drop the -fpermissive C++ compiler flag. We've had this around for years, most
code should have been fixed long ago. Its possible some recipes may fail
however we can (and should) just use the flag where needed.
An OE-Core world build seems to work just fine with this change.
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
These variables should not influence the config hash, i.e. changing them
shouldn't trigger a reparse of the metadata, so whitelist them.
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
The default value for HOMEPAGE of "unknown" has been in place since the
early OE-Classic days, but it doesn't really make sense - "unknown" is
not a valid URL and it just means we have to explicitly check for this
hardcoded string if we're displaying the value in some form of UI, such
as Toaster.
This has required some changes to the packaging classes as they
previously did not expect the value to be blank.
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
SUMMARY should not end with a full stop; however if DESCRIPTION is not
set in a recipe and thus defaulted from SUMMARY, the additional
DESCRIPTION values for other standard packages e.g. ${PN}-dev look a bit
odd without a full stop separating the SUMMARY value and the rest of the
text. Add a full stop to avoid this.
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
|
|
Ensure that if MACHINE_FEATURES is not set by the machine config that we
don't end up with expansion errors during parsing. Technically since the
introduction of MACHINE_FEATURES_BACKFILL = "rtc" this is unlikely to be
a problem unless "rtc" is also added to
MACHINE_FEATURES_BACKFILL_CONSIDERED, however we should be consistent
with DISTRO_FEATURES which is defaulted in bitbake.conf.
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
|
|
The layout of stamp files ensures that changes to WORKDIR mean recipes get rebuilt correctly.
Since WORKDIR usually contains MULTIMACH_TARGET_SYS and that depends on tune variables,
including WORKDIR in sstate checksums adds a lot of noise to the system for what amounts to
no gain.
On the other hand, removing it reduces noise, reduces the size of the siginfo files and
reduces the amount of processing bitbake has to do. It therefore seems like dropping it
from the checksums is an all around win.
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
gcc tooling appears to be standardising around the FC variable naming.
This patch changes the F77 namespace to FC instead and use the default
gfortran compiler. If anyone needs the F77 variables or tools, those
can still be made on a case by case basis.
Also updates local.conf.sample.extended accordingly.
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
ADOBE_MIRROR, HANDHELDS_CVS and E_SVN were broken links and not used by
any recipe in oe-core.
FREEDESKTOP_CVS is no longer useful because all the source code that
matters is in git; no recipe in oe-core still uses the CVS repository.
E_MIRROR, FREEBSD_MIRROR, FREESMARTPHONE_GIT still point to valid-seeming
locations but there are no recipes in oe-core that use them. Any layers
which need these variables can define them for themselves.
GPE_SVN, GPE_EXTRA_SVN, GPEPHONE_MIRROR and GPEPHONE_SVN are not used by
any recipe in oe-core and the corresponding projects seem to be mostly
dead upstream. Again, any layers which still wish to use these variables
can define them locally.
All the above are just wasting space in bitbake's datastore and would be
better deleted.
Signed-off-by: Phil Blundell <philb@gnu.org>
Signed-off-by: Saul Wold <sgw@linux.intel.com>
|
|
This variable has been unused since the tune file overhaul two years
ago.
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
These were for task-bootstrap in OE-Classic and have never been used in
OE-Core.
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
An empty distro value leads to OVERRIDES and FILESOVERRIDES containing
"::" entries which causes odd issues such as files being included when
they shouldn't be. We could put in anonymous python to guard against
empty entries but its messy and setting a default value for DISTRO to
something harmless is much easier.
This patch adds a weak default and ensures the sanity test doesn't
complain about it.
DISTRO_VERSION and SDK_VERSION are also updated to match.
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
I discovered bitbake rebuilding packages because WARN_QA had changed. These
variables don't influence the output, so add them to the whitelist.
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
* we correctly have
${STAGING_DIR_NATIVE}${base_sbindir_native}
and then double slash in
${STAGING_DIR_NATIVE}/${base_bindir_native}
* similar in PKG_CONFIG_DIR where libdir also starts with slash
${STAGING_DIR_HOST}/${libdir}/pkgconfig
* also fix double slash in insane.bbclass and staging.bbclass
* I was a bit nervous about staging change (in case the / was important
in some weird use-case, but the extra slash is there since following
commit where other extra slashes were removed only the one before
libdir was kept:
commit 6ea78d648951e5bbe9669412c0863daaf7f49ca5
Author: Richard Purdie <rpurdie@linux.intel.com>
Date: Mon Nov 2 17:10:51 2009 +0000
autotools.bbclass: Separate out useful staging functions into
base.bbclass and call from autotools classes
* this isn't fixing any real-world issue AFAIK, I was just trying to
debug one weird case where debugedit fails with
canonicalization unexpectedly shrank by one character
and it's easier to grep for '//' without many harmless instances
already in run* scripts etc
Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
To make it easier to move WORKDIR, define it using the new variable
BASE_WORKDIR, which is the root of the work directory.
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
directory
Currently we have a hierarchy of pkgdata directories and the code has to put together
a search path and look through each in turn until it finds the data it needs.
This has lead to a number of hardcoded paths and file globing which
is unpredictable and undesirable. Worse, certain tricks that should be
easy like a GL specific package architecture become problematic with the
curretn search paths.
With the modern sstate code, we can do better and construct a single pkgdata
directory for each machine in just the same way as we do for the sysroot. This
is already tried and well tested. With such a single directory, all the code that
iterated through multiple pkgdata directories and simply be removed and give
a significant simplification of the code. Even existing build directories adapt
to the change well since the package contents doesn't change, just the location
they're installed to and the stamp for them.
The only complication is the we need a different shlibs directory for each
multilib. These are only used by package.bbclass and the simple fix is to
add MLPREFIX to the shlib directory name. This means the multilib packages will
repackage and the sstate checksum will change but an existing build directory
will adapt to the changes safely.
It is close to release however I believe the benefits this patch give us
are worth consideration for inclusion and give us more options for dealing
with problems like the GL one. It also sets the ground work well for
shlibs improvements in 1.6.
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
This allows a clean seperation between image outputs from different
machines, and makes it possible to have convenience symlinks to make
the output ready to deploy.
This did require some surgery in runqemu; if explicit paths to the image
and kernel are not supplied then DEPLOY_DIR_IMAGE needs to be determined
from bitbake or set in the environment. However the script does try to
avoid requiring it unless it really is needed. Corresponding changes
were made in the automated testing code as well.
Based on an RFC patch by Koen Kooi <koen@dominion.thruhere.net>
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
For a long time we've provided PN-PV and PN-PV-PR by tweaking PROVIDES. This looks
nice at first glance however it turns out to be a bit problematic. Taking make as an
example where there are two versions, 3.81 and 3.82, what should "bitbake make-3.81" do?
Currently it builds make-3.81 and make-3.82 and breaks in interesting ways. Is that
a bitbake bug? Well, it certainly shouldn't try and run the build. Why is it building
3.82 though? Its due to finding a dependency on "make-dev" and then trying to figure
out what provides it? The answer is "make" and the default version of "make" is 3.82.
So arguably, finding "make-3.81" should infer PREFERRED_VERSION_make = "3.81". Doing
so resolved the above problem since now "make" resolves to "make-3.81".
So what about if we have Recipe A:
DEPENDS = "make-3.81"
and Recipe B:
DEPENDS = "make-3.82"
That is clearly an error, easy. So finally what about if we have Recipe A:
DEPENDS = "make-3.81"
and Recipe B:
DEPENDS = "make"
The first recipe infers the PREFERRED_VERSION_make = "3.81" and then forces that
version on everything else. Is that desired? Probably not in most cases, at least not
silently.
As mitigation, we could print a WARNING about this happening. The final part of the problem
is that we can ony figure this out within bitbake itself. That means we'd have to teach bitbake
about the PN-PV format of PROVIDES which is breaking the separation between bitbake and the
metadata. We can't win :(.
Nobody that I know of is using or relying on this functionality so perhaps we should
just remove it instead which is what this patch does. Opinions?
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
The gcc recipes reference this however we account for it in the work
directory paths and we don't want recipes depending on the value changing.
This avoids unecessary rebuilds when switching SDKs.
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
There were darwin8/darwin9 overrides spinkled in the code from times gone
by. Lets settle on the darwin override and remove the others since its pointless
duplication. We always inject darwin into OVERRIDES if needed in the darwin8/9
cases.
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
On darwin, we have:
libxxx.dylib -> libxxx.Y.dylib
compared to Linux which has:
libxxx.so -> libxxx.so.Y
Our ordering of PACKAGES with -dev first and then ${PN} makes it impossible to
match the files correctly using simple globbing. This makes darwin targets
completely broken since both the libs and the dev symlinks end up in ${PN}-dev.
Whilst this commit is a hack, it at least puts the files into ${PN} and allows the
builds to be used. Symlinks don't take up much space so this isn't the end of
the world. I'm open to better solutions to this.
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
Hardcoding -nativesdk as the sdk package architecture is inflexible. We may have
multiple different target OS and we need a way to be able to separate them. Turning
this into a configurable value allows the flexibility we need to build different
SDKMACHINEs with different OS targets.
The commit should have no behaviour change, just makes things more configurable.
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
The gettext handling of USE_NLS has become a bit tricky to understand, or
alter from the SDK context. This patch introduces a SDKUSE_NLS which can
be set to configure a given SDK/ADT to use NLS or not. This is independent
of the target system NLS usage.
The code in gettext.bbclass is therefore simplified and the classes
themselves now set USE_NLS to appropriate values. No NLS is used
for native, cross and crosssdk since it is never used there and
would just increase build time.
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
Add NO_RECOMMENDATIONS support. A way to disable all recommended
packages from being installed. This will help shrink the size of
the resulting filesystem.
Add documentation on NO_RECOMMENDATIONS and BAD_RECOMMENDATIONS.
Note, using NO_RECOMMENDATIONS has side effects such that kernel-modules may
not have been installed. A user will need to manually add to their image
any kernel-modules required to be on the image for functionality.
Signed-off-by: Mark Hatle <mark.hatle@windriver.com>
Signed-off-by: Saul Wold <sgw@linux.intel.com>
|
|
Add support for the BAD_RECOMMENDATIONS variable that can be used to
prevent specific packages from being installed via an RRECOMMENDS
relationship when using the RPM backend. (Previously this
functionality was only available when using ipk packaging.)
In the process this moves the defaulting of BAD_RECOMMENDATIONS (as
empty) to bitbake.conf since it is no longer specific to the ipk
backend, as well as unifying some of the code that creates the
configuration for smart for use on the host and target.
Fixes [YOCTO #3916].
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Saul Wold <sgw@linux.intel.com>
|
|
In order to correctly handle fakeroot at the bitbake level we need some extra
information which we provide with these new variables.
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
* fixes build without EXTRA_IMAGE_FEATURES defined:
ERROR: '${EXTRA_IMAGE_FEATURES}' in IMAGE_FEATURES is not a valid
image feature. Valid features: dbg-pkgs ....
Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
* remove STRINGS export from systemd
Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
Use "??=" to set default ROOT_HOME. It can be overwrote by developer
with "?=" in any layer and at same time it also can be overwrote in
local.conf.
Signed-off-by: Kang Kai <kai.kang@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
python3 is stricter about type comparisions so add an explicit cast to int()
to ensure this code is portable.
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
Chen Qi
Khem Raj
Richard Purdie
Robert Yang
Hongxu Jia
Roxana Ciobanu
Ross Burton
Matthieu Crapet
Max Eliaser
Tim Orling
Changhyeok Bae
Valentin Cobelea
Paul Eggleton
Richard Purdie
Phil Blundell
Martin Jansa
Mark Hatle
Kang Kai