Packages such as gdk-pixbuf can result in the following error during
the rootfs construction:
CRITICAL **: 16:51:57.223: Failed to get connection to xfconfd: Cannot autolaunch D-Bus without X11 $DISPLAY
This is hit during the postinst-intercepts/update_pixbuf_cache.
Based on discussions upstream:
https://bugzilla.xfce.org/show_bug.cgi?id=14789
this appears to be an issue for xfconf and has an upstream update:
https://git.xfce.org/xfce/xfconf/commit?id=6f11cc65a2213f424728b5a0d25b1b63c19e773e
Drawing from this change we can go ahead and use PACKAGECONFIG to
emulate the upstream fix, defaulting to having the gsettings-backend
disabled.
Signed-off-by: Mark Asselstine <mark.asselstine@windriver.com>
Signed-off-by: Khem Raj <raj.khem@gmail.com>
This fixes:
ERROR: networkmanager-1.14.4-r0 do_package: QA Issue: networkmanager: Files/directories were installed but not shipped in any package:
/usr/lib64/NetworkManager/1.14.4/libnm-settings-plugin-ifupdown.la
/usr/lib64/NetworkManager/1.14.4/libnm-device-plugin-adsl.la
/usr/lib64/NetworkManager/1.14.4/libnm-device-plugin-wifi.la
/usr/lib64/NetworkManager/1.14.4/libnm-device-plugin-ovs.la
Please set FILES such that these items are packaged. Alternatively if they are unneeded, avoid installing them or delete them within do_install.
networkmanager: 4 installed and not shipped files. [installed-vs-shipped]
As with similar changes in the past, if the distro makes use of
'remove-libtool' this issue is not seen but we should add .la files to
the -dev package when they do exist.
Signed-off-by: Mark Asselstine <mark.asselstine@windriver.com>
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Since the xfconf uprev, commit 4222cac976 [xfconf: 4.13.5 ->
4.13.6], we are getting a QA issue:
ERROR: xfconf-4.13.6-r0 do_package: QA Issue: xfconf: Files/directories were installed but not shipped in any package:
/usr/lib64/gio/modules/libxfconfgsettingsbackend.la
Please set FILES such that these items are packaged. Alternatively if they are unneeded, avoid installing them or delete them within do_install.
xfconf: 1 installed and not shipped files. [installed-vs-shipped]
ERROR: xfconf-4.13.6-r0 do_package: Fatal QA errors found, failing task.
ERROR: xfconf-4.13.6-r0 do_package: Function failed: do_package
We need to include the .la file in the -dev package to avoid this.
Signed-off-by: Mark Asselstine <mark.asselstine@windriver.com>
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Whereas the python-twisted-core package is used to install the minimum
components of python-twisted, the python-twisted package is
essentially a 'meta' package which installs all of the
python-twisted-* packages (used by folks that don't want to determine
which components they are interested in). Add additional packages to
the python-twisted 'meta' package.
NOTE: that there are still modules of python-twisted which have not
been ported to python3 (see src/twisted/python/_setup.py
"notPortedModules") so the installed packages for py2 vs. py3 will not
be the same (ie. python-twisted-news is only part of the py2 package).
Signed-off-by: Mark Asselstine <mark.asselstine@windriver.com>
Signed-off-by: Khem Raj <raj.khem@gmail.com>
This is a partial revert of commit 2ad5ceafa5 [various classes
recipes: Remove FILES entries for dbg/dev packages] to restore the
packaging of libtool (.la) files. It is generally recommended to
include 'remove-libtool' in your distro features to purge libtool
files as a do_install postfunc for all recipes, as is the documented
recommendation for handling of libtool files (unless the .la have been
determined to be absolutely necessary, in which case a recipe can use
the REMOVE_LIBTOOL_LA to prevent the cleanup). However, if the
'remove-libtool' distro feature is not specified we need to ensure
that if after a recipe completes do_install() and there are libtool
files present in the image, we must package them or we will hit
'installed-vs-shipped' QA issues.
NOTE: that even with respect to libtool files this is not a 1:1
partial revert of commit 2ad5ceafa5, adjustments are made according
to the current state of the build today.
Signed-off-by: Mark Asselstine <mark.asselstine@windriver.com>
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Since commit eb0fe21c15 [thunar: upgrade 1.6.15 -> 1.8.0] we see a
QA Error/Warning regarding files 'installed-vs-shipped':
ERROR: QA Issue: thunar: Files/directories were installed but not
shipped in any package:
/usr/lib
/usr/lib/systemd
/usr/lib/systemd/user
/usr/lib/systemd/user/thunar.service
Correct the path to the systemd service file to match what we see in
other recipes which include "user" service files.
Signed-off-by: Mark Asselstine <mark.asselstine@windriver.com>
Acked-by: Andreas Müller <schnitzeltony@gmail.com>
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Since commit 5f31db6014 [xfce4-panel: upgrade 4.12.2 -> 4.13.3] we
are getting a QA Warnings/Erros for 'installed-vs-shipped':
ERROR: xfce4-panel-4.13.3-r0 do_package: QA Issue: xfce4-panel:
Files/directories were installed but not shipped in any package:
/usr/lib64/xfce4/panel/plugins/liblauncher.la
/usr/lib64/xfce4/panel/plugins/libdirectorymenu.la
...
>From various OE documents the .la files should not be packaged in
either the main recipe package or the -dev package unless required. So
inherit 'remove-libtool' to have all the .la files cleaned up as they
don't appear to be necessary.
Signed-off-by: Mark Asselstine <mark.asselstine@windriver.com>
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Building the 'gnome-keyring' recipe with "installed-vs-shipped"
included in ERROR_QA will result in:
ERROR: gnome-keyring-3.20.0-r0 do_package: QA Issue: gnome-keyring: \
Files/directories were installed but not shipped in any package:
/usr/lib64/pkcs11/gnome-keyring-pkcs11.la
/lib64/security/pam_gnome_keyring.la
>From various documents the .la files should not be packaged in either
the main recipe package or the -dev package unless required. So
inherit 'remove-libtool' to have all the .la files cleaned up as they
don't appear to be necessary.
Signed-off-by: Mark Asselstine <mark.asselstine@windriver.com>
Signed-off-by: Armin Kuster <akuster808@gmail.com>
The following error is being hit:
| install: cannot stat
| '.../tmp/work/core2-64-poky-linux/zeromq/4.2.3-r0/build/.libs/test_*':
| No such file or directory
This is being hit in the 'state of the world' builds (see [oe] State
of the world, 2018-03-19). The uprev to v4.2.3 (commit 50eb3504c83c)
did not take into account that the location of the tests changed in
the 'build' directory as part of the new release. Updating to use the
proper directory.
Signed-off-by: Mark Asselstine <mark.asselstine@windriver.com>
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Signed-off-by: Armin Kuster <akuster808@gmail.com>
The following error is seen when do_install is run
| UnicodeEncodeError: 'ascii' codec can't encode character u'\xf6' in
| position 16: ordinal not in range(128) ERROR: python setup.py
| install execution failed.
This is reported in the upstream project as part of pull request #81https://github.com/stefankoegl/python-json-patch/pull/81
Since a release is not yet available with the required fix we must
apply the fix as a patch.
Signed-off-by: Mark Asselstine <mark.asselstine@windriver.com>
Signed-off-by: Armin Kuster <akuster808@gmail.com>
When building an image which included 'netcf' I saw the following
warning which is followed by a python backtrace:
WARNING: cube-dom0-0.6-r0 do_rootfs: \
Manifest .../manifest-x86_64_x86_64-nativesdk-gnulib.package_write_rpm \
not found in genericx86_64 core2-64 x86_64 allarch x86_64_x86_64-nativesdk \
(variant '')?
>From this we find that the 'gnulib' package would fail the manifest
crosscheck for the 'package_write_rpm' task. By switching from
'noexec' to 'deltask' for this task (and its "siblings") we completely
remove the task and thus there is not crosscheck to fail.
NOTE that there is a pending merge which will change the backtrace for
a proper ERROR: [package_manager.py: Print offending package instead
of non-sense trace]
Signed-off-by: Mark Asselstine <mark.asselstine@windriver.com>
Signed-off-by: Armin Kuster <akuster808@gmail.com>
With oe-core commit cdcebd81c872cb7386c658998e27cf24e1d0447c
[initscripts: don't use update-alternatives] we start seeing a a
rootfs generation failure when both sysklogd and inetutils are present
in the image:
ERROR: do_rootfs: [log_check] : found 1 error message in the logfile:
[log_check] update-alternatives: Error: not linking
.../0.2-r0/rootfs/usr/share/man/man8/syslogd.8 to
/usr/share/man/man8/syslogd.8.inetutils since
.../0.2-r0/rootfs/usr/share/man/man8/syslogd.8 exists and is not a link
As has been done with the other packages which provide system logging
we add an rconflicts to only allow one to exist in a rootfs image at a
time.
Signed-off-by: Mark Asselstine <mark.asselstine@windriver.com>
Signed-off-by: Armin Kuster <akuster808@gmail.com>
Signed-off-by: Joe MacDonald <joe_macdonald@mentor.com>
setup.py will attempt to download python-incremental, as it is not
present in the sysroot. This is at the least wrong since some random
version of python-incremental will be used to build against (akin to
host contamination) and at most a build failure (when network access
is unavailable). So make python-incrementa-native available and a
DEPENDS.
Unfortunately python-incremental has a dependency on python-twisted
and vice versa. So we need to forcefully break this circular
dependency. Fortunately this doesn't affect the build of
python-twisted. Unfortunately if anyone else attempts to use
python-incremental-native there might be issues should it ever run the
code that does the import of twisted. This is not an issue now and a
comment has been added to hopefully make this issue known to anyone
else coming along at a later time.
Signed-off-by: Mark Asselstine <mark.asselstine@windriver.com>
Signed-off-by: Armin Kuster <akuster808@gmail.com>
Drop the json<-->simplejson patch instead opting to depend on
python-json (part of core python libs). Beyond this the uprev is
straightforward.
Signed-off-by: Mark Asselstine <mark.asselstine@windriver.com>
Signed-off-by: Armin Kuster <akuster808@gmail.com>
Matching what has been done with other python packages, move the
existing recipe into a .inc file and then create python and python3
specific bb files to allow the generation of python2 or python3
versions.
Signed-off-by: Mark Asselstine <mark.asselstine@windriver.com>
Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
The recipe seems to have the intent of creating a 'tests' package but
doesn't follow through on this intent. Rename 'tests' to 'test' to
match other python test packages and follow through on the intent to
actually produce a 'test' package.
Signed-off-by: Mark Asselstine <mark.asselstine@windriver.com>
Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
Because do_compile() makes calls to dbus-binding-tool we have to make
this tool available via the dbus-glib-native package. Failing this we
get errors:
| dbus-binding-tool --prefix=port --mode=glib-server --output=port-glue.h ...
| /bin/bash: dbus-binding-tool: command not found
| Makefile:1150: recipe for target 'daemon-glue.h' failed
This becomes a hard build failure when per recipe sysroots are used.
Signed-off-by: Mark Asselstine <mark.asselstine@windriver.com>
Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
By defining 'listen-address' in the global dnsmasq.conf file we
prevent other instances of dnsmasq from using the global config as we
will get an error that the address is already in use. Instead we pass
'local-service' when we start the main dnsmasq instance which will
listen on the loopback address as well as any other local
subnets. This will allow the main dnsmasq instance to play nice with
other instances we might start for network-manager, libvirt, lxc...
Signed-off-by: Mark Asselstine <mark.asselstine@windriver.com>
Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
Signed-off-by: Joe MacDonald <joe_macdonald@mentor.com>
The dnsmasq package installs a ${sysconfigdir}/dnsmasq.d directory but
doesn't currently use any configuration files that might be placed
there. This goes against what the user would expect and doesn't match
what you see in other distros.
We could ensure this config directory is read when dnsmasq is started,
as we are doing here, or by including it in the main dnsmasq.conf
file. By doing it here we can have better reuseability of the main
dnsmasq.conf file by other instances of dnsmasq.
There are currently no files added to the dnsmasq.d directory for core
oe images, so this should not result in any runtime behavior changes.
Signed-off-by: Mark Asselstine <mark.asselstine@windriver.com>
Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
Signed-off-by: Joe MacDonald <joe_macdonald@mentor.com>
During rootfs creation the following error is being hit
Preparing... ######################################## [ 0%]
warning: Removing ctdb-2.5.1-r0@core2_64 due to file /usr/bin/ctdb
conflicting with samba-4.4.2-r0@core2_64
error: ctdb-dev-2.5.1-r0 conflicts with ctdb = 2.5.1-r0
Looking at the relationship between samba and ctdb it appears that the
landscape has changed some starting in version 4.2. Samba now includes
and installs ctdb instead of relying on stand-alone ctdb. Referencing
https://wiki.samba.org/index.php/CTDB_Setup we see this activated by
'--with-cluster-support' which we do pass to configure based on the
bb.
Dropping the DEPENDS on ctdb resolves this issue.
Signed-off-by: Mark Asselstine <mark.asselstine@windriver.com>
Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
Signed-off-by: Joe MacDonald <joe_macdonald@mentor.com>
When building mozjs the following error was observed
| Traceback (most recent call last):
| File "./config.status", line 9, in <module>
| from ConfigStatus import config_status
| File "/build/bitbake_build/tmp/work/corei7-64-wrs-linux/mozjs/17.0.0-r0/mozjs17.0.0/js/src/build/ConfigStatus.py", line 11, in <module>
| import sys, re, os, posixpath, ntpath
| File "/usr/lib/python2.7/ntpath.py", line 15, in <module>
| from genericpath import _unicode
| ImportError: cannot import name _unicode
| WARNING: exit code 1 from a shell command.
| ERROR: Function failed: do_configure (log file is located at /build//bitbake_build/tmp/work/corei7-64-wrs-linux/mozjs/17.0.0-r0/temp/do_configure/log.do_configure.1056
Note the host paths found in the error msg. Further this issue can be
explored using the host python, which will not error when attempting
the above import, and the python in the sysroot, which will fail when
we attempt the import.
By inheriting pythonnative we ensure the proper paths are set to avoid
this host contamination.
Signed-off-by: Mark Asselstine <mark.asselstine@windriver.com>
Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
The changes made in commit 2497cf2960
[dnsmasq: steal resolvconf support from Ubuntu] broke systemd only
dnsmasq runtime. No sysvinit scripts are included in systemd only
builds (and should not be) and the dnsmasq executable has not moved to
/usr/sbin.
Reverting to the previous version of the systemd service file. If
folks want the local dnsmasq instance to be queried before going to
an external DNS they should add 'nameserver 127.0.0.1' to
/etc/resolv.conf. Or submit a change which will work with systemd.
Signed-off-by: Mark Asselstine <mark.asselstine@windriver.com>
Acked-by: Anders Darander <anders@chargestorm.se>
Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
Signed-off-by: Joe MacDonald <joe_macdonald@mentor.com>
Depending on the configuration used to build ntp it is possible to
have an empty libexecdir. This can cause QA issues. Add a test at the
end of install() to remove libexecdir if it is empty, thus avoiding
the possibility of QA issues, regardless of configuration.
Signed-off-by: Mark Asselstine <mark.asselstine@windriver.com>
Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
Signed-off-by: Joe MacDonald <joe_macdonald@mentor.com>
While building an image I was getting an error during rootfs creation
that ctdb was conflicting with base-files as both were creating
'/var/run':
warning: Removing ctdb-2.5.1-r0@core2_64 due to file /var/run \
conflicting with base-files-3.0.14-r89@genericx86_64
This is normally a volatile directory so we have no need
to include this in the ctdb package, so revert the actions of the
Makefile by deleting the directory.
Although /run and $localstatedir/run are linked to be consistent we
update the .service file to use the latter. To ensure the 'ctdb'
subdir exists we patch the use of RuntimeDirectory= in to the .service
file. This will compensate for our removal of this directory creation
from the Makefile.
Signed-off-by: Mark Asselstine <mark.asselstine@windriver.com>
Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
Signed-off-by: Joe MacDonald <joe_macdonald@mentor.com>
This effectively reverts commit
4e8853ca05 [bundler: Fix QA new Error]
The original QA error is now handled by changes to the ruby.bbclass to
properly handle build_info and extensions directories that Ruby 2.0.0
now creates while installing gems.
This revert isn't specifically required but by removing this broad
definition of FILES the hope is that other ruby recipes won't copy
this behavior which can actually lead to other QA errors/warnings,
depending on what gets installed in the build_info and extensions
directories.
Signed-off-by: Mark Asselstine <mark.asselstine@windriver.com>
Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
It appears that newer versions of ruby produce additional directories
which were not previously handled by the ruby bbclass, specifically
'build_info' and 'extensions'. This is currently resulting in QA
errors/warnings such as:
ERROR: QA Issue: puppet: Files/directories were installed but not shipped in any package:
/usr/lib64/ruby/gems/2.2.0/build_info
/usr/lib64/ruby/gems/2.2.0/extensions
Please set FILES such that these items are packaged. Alternatively if they are unneeded,
avoid installing them or delete them within do_install. [installed-vs-shipped]
Add these to our FILES in the bbclass such that they will packaged.
NOTE: several files may exist in the extensions directory such as
gem.build_complete and mkmf.log that we can most likely remove during
do_install. Since ruby installs these by default they have been left
in case their existence is used as some type of stampfile or similar.
Signed-off-by: Mark Asselstine <mark.asselstine@windriver.com>
Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
Without this dependency we will see warnings when ever we use the
ruby-native from the sysroot
...tmp/sysroots/x86_64-linux/usr/lib/ruby/yaml.rb:84:in `<top (required)>':
It seems your ruby installation is missing psych (for YAML output).
To eliminate this warning, please install libyaml and reinstall your ruby.
Signed-off-by: Mark Asselstine <mark.asselstine@windriver.com>
Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
In order to allow the building of gems we have created a
ruby.bbclass. The building of gems is much like the building of python
packages in that we rely on building up -native gems in order to
facilitate the cross compiling of the gems that will be built for the
target. When dependencies exist between gems they must be satisfied by
the -native gems installed in the host sysroot. This approach is
feasible since the build process is able to query installed gems
without being affected by the ARCH they were built for. At this point
I have yet to come across a situation where the assumption associated
with this approach have failed but so far focus has only been on x86
and x86-64 builds.
The recipes which inherit the ruby.bbclass can optionally define a BPV
in the case where the gemspec version doesn't always map 1:1 to the
PV. This situation has only been encountered on a few occasions so
the class has been made to default BPV to PV.
To demonstrate the ruby.bbclass in use we have included a recipe to
build the bundler gem. Bundler can be used on a running target to
install gems from rubygems.org, which can be useful in itself when you
don't have recipes available for gems but want to try installing and
running pre-built gems.
Signed-off-by: Mark Asselstine <mark.asselstine@windriver.com>
Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
While making use of the cyrus-sasl library an external application
will most likely include sasl.h which will cause compilation failures
if steps haven't been taken to define size_t. This should not be the
responsibility of the application building against the sasl library
but rather handled already in sasl.h. Here we ensure sasl.h has the
proper includes to have size_t defined before it is used.
Signed-off-by: Mark Asselstine <mark.asselstine@windriver.com>
Signed-off-by: Joe MacDonald <joe@deserted.net>
Mark Asselstine