To fix:
file /usr/share/man/man1/dnsdomainname.1 conflicts between attempted installs
of inetutils-doc-1.9.4-r0.core2_64 and net-tools-doc-1.60+26-r0.core2_64
file /usr/share/man/man8/syslogd.8 conflicts between attempted installs
of inetutils-doc-1.9.4-r0.core2_64 and sysklogd-doc-1.5.1-r0.core2_64
file /usr/share/man/man1/logger.1 conflicts between attempted installs
of util-linux-doc-2.29.1-r0.core2_64 and inetutils-doc-1.9.4-r0.core2_64
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
Signed-off-by: Joe MacDonald <joe_macdonald@mentor.com>
To fix:
[log_check] Warn: update-alternatives: logger.1 has multiple providers
with the same priority, please check
tmp/work/genericx86_64-overc-linux/cube-graphical-builder/0.2-r0/rootfs/usr/lib/opkg/alternatives/logger.1
for details
In that file we see:
/usr/share/man/man1/logger.1
/usr/share/man/man1/logger.1.util-linux 80
/usr/share/man/man1/logger.1.inetutils 80
Since most people would probably expect the util-linux version, we
drop inetutils by one.
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
Signed-off-by: Joe MacDonald <joe_macdonald@mentor.com>
In the report at http://errors.yoctoproject.org/Errors/Details/130673/
we see the following:
i586-oe-linux-gcc -m32 -march=i586 <snip> netcat.o atomicio.o socks.o `pkg-config --libs libbsd` -lresolv -o nc
/bin/sh: 1: pkg-config: not found
What follows is a bunch of link errors for BSD library functions, as
the backtick didn't return anything but an empty string and hence no
BSD library was involved in the link.
I was able to reproduce this by temporarily removing my host version
of pkg-config, and then validated that this fix solves it while still
having the host binary removed. So it should fix the reported issue.
I also confirmed pkg-config was in the sysroot after the change.
Cc: Khem Raj <raj.khem@gmail.com>
Cc: Martin Jansa <Martin.Jansa@gmail.com>
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
Signed-off-by: Joe MacDonald <joe_macdonald@mentor.com>
To fix:
file /usr/share/man/man1/eject.1 conflicts between attempted installs
of util-linux-doc-2.29.1-r0.core2_64 and eject-doc-2.1.5-r1.core2_64
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
The coreutils has a hostname command; this package already dealt
with that existing as an alternate, but for some reason it did not
do the same with the manpage of the same name. The conflict varied
from intermittent to "why does this keep happening to me?!?".
Mark gets credit for the fix; he didn't want to bear witness to yet
another premature death of a USB keyboard and suggested the change
here; which I then largely just confirmed as functional, since I
happened to "be so lucky" as to have the reproducer.
The failure showed up in do_rootfs as follows:
ERROR: cube-graphical-builder-0.2-r0 do_rootfs: [log_check] cube-graphical-builder:
found 1 error message in the logfile: [log_check] update-alternatives:
Error: not linking tmp/work/qemuarm64-overc-linux/cube-graphical-builder/0.2-r0/rootfs/usr/share/man/man1/hostname.1
to /usr/share/man/man1/hostname.1.coreutils since
tmp/work/qemuarm64-overc-linux/cube-graphical-builder/0.2-r0/rootfs/usr/share/man/man1/hostname.1
exists and is not a link
Cc: Mark Hatle <mark.hatle@windriver.com>
Cc: Joe MacDonald <joe_macdonald@mentor.com>
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
Signed-off-by: Joe MacDonald <joe_macdonald@mentor.com>
Currently we see:
| checking for gconftool-2... no
| configure: error: gconftool-2 executable not found in your path - should be installed with GConf
| ERROR: Function failed: do_configure (log file is located at gthumb/2.12.4-r4/temp/log.do_configure.5243)
ERROR: Task (meta-gnome/recipes-gnome/gthumb/gthumb_2.12.4.bb:do_configure) failed with exit code '1'
Presumably this now happens more regularly with demise of the shared
sysroot. Adding gconf-native to the dependency list fixes it.
Cc: Martin Jansa <Martin.Jansa@gmail.com>
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
We currently see:
| /bin/bash: gconftool-2: command not found
| Makefile:841: recipe for target 'install-data-local' failed
| make[3]: *** [install-data-local] Error 127
Presumably this now happens more regularly with demise of the shared
sysroot. Adding gconf-native to the dependency list fixes it.
Cc: Martin Jansa <Martin.Jansa@gmail.com>
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
In the config log we see:
configure:12277: checking whether to build static libraries
configure:12281: result: yes
configure:12419: checking for x86_64-overc-linux-pkg-config
configure:12452: result: no
configure:12462: checking for pkg-config
configure:12495: result: no
configure:12801: Using Farsight2 source release as package name
configure:12825: Using Unknown package origin as package origin
configure:12879: Using /usr/libexec/gst-install-plugins-helper as plugin install helper
configure:12953: checking for NICE
configure:13022: error: Need libnice >= 0.0.9
While it libnice that fails configure, it is the absence of pkg-config
several lines above that causes the failure, as libnice is in the sysroot.
For most build hosts, you'll have to remove the default binary that
lives in /usr/bin/pkg-config in order to see this failure.
Cc: Martin Jansa <Martin.Jansa@gmail.com>
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
In http://errors.yoctoproject.org/Errors/Details/130583/ we see the
following:
/bin/bash: line 1: glib-mkenums: command not found
/bin/bash: glib-genmarshal: command not found
Makefile:1808: recipe for target 'gstenumtypes.h' failed
make[2]: *** [gstenumtypes.h] Error 127
Most people don't see this because most hosts have these binaries
in /usr/bin -- e.g. libglib2.0-dev in Ubuntu provides them.
However, after making this change, we see the following in the
build for gstreamer:
./recipe-sysroot-native/usr/bin/glib-mkenums
./recipe-sysroot-native/usr/bin/glib-genmarshal
..and hence this change should resolve the above Yocto issue.
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
This started showing up recently on machines w/o xsltproc in
their path:
| checking for xsltproc... no
| configure: error: xsltproc is needed
| WARNING: udisks2/2.1.7-r0/temp/run.do_configure.29255:1 exit 1
| ERROR: Function failed: do_configure (log file is located at
| build/tmp/work/core2-64-overc-linux/udisks2/2.1.7-r0/temp/log.do_configure.29255)
Presumably the splitting of the sysroot made this happen more
frequently on such machines that didn't have a host install of the
xsltproc binary.
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
Now with the shared sysroot gone, an implicit dependency shows up as:
| checking for dbus-binding-tool... no
| configure: error: could not find dbus-binding-tool in $PATH. You can run
| ./configure DBUS_BINDING_TOOL=/path/to/dbus-binding-tool to define
| a custom location for it.
| ERROR: Function failed: do_configure (log file is located at /home/paul/poky/build/tmp/work/core2-64-overc-linux/xfdesktop/4.12.3-r0/temp/log.do_configure.9339)
ERROR: Task (/home/paul/poky/meta-openembedded/meta-xfce/recipes-xfce/xfdesktop/xfdesktop_4.12.3.bb:do_configure) failed with exit code '1'
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
The rmdir in configure prepend seemed like a nice sanity check to
ensure the upstream source didn't change their handling of the
gnulib submodule, but it will be a problem when changed sigs (in
gnulib for example) trigger a reconfigure in an existing build.
In such an instance, the .gnulib dir will have the old copy from
the sysroot, and not be empty and the rmdir will fail.
Given that we don't know what changed in the context of the prepend,
we just assume it could have been the gnulib sysroot content, and
hence blow away the old dir and re-copy in the possibly updated
gnulib sysroot content.
This works for both clean builds, and rebuilds that have triggered
a reconfigure of an existing netcf build.
Fixes: 0939421972 ("netcf: fix mishandling of gnulib submodule
causing build fail")
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
Signed-off-by: Joe MacDonald <joe_macdonald@mentor.com>
netcf fails to build on certain hosts with newer versions
of git installed as follows:
| ./bootstrap: Bootstrapping from checked-out netcf sources...
| ./bootstrap: consider installing git-merge-changelog from gnulib
| ./bootstrap: getting gnulib files...
| error: pathspec 'gnulib' did not match any file(s) known to git.
If we do a devshell we will see that our configure prepend that
intended to _create_ the .gitmodules has instead _modified_ it
and left us with this change present:
sh-4.3# git diff
diff --git a/.gitmodules b/.gitmodules
index 7acb1ea19ca7..2d10b0e0e0fe 100644
--- a/.gitmodules
+++ b/.gitmodules
@@ -1,3 +1,3 @@
[submodule "gnulib"]
- path = .gnulib
- url = git://git.sv.gnu.org/gnulib.git
+ path = gnulib
+ url = git://git.sv.gnu.org/gnulib
sh-4.3#
What happens is that the newer git does not respect uncommitted
changes to the .gitmodules file, and hence the path ".gnulib" is
still considered valid vs. the in tree updated path "gnulib". It
doesn't help any that the package has its own tracked files in
gnulib/ that we stomp over, but the real fail is just uncommitted
changes to the .gitmodule as this insertion of a random path shows:
sh-4.3# git diff
diff --git a/.gitmodules b/.gitmodules
index 7acb1ea19ca7..91bd45f8e4d4 100644
--- a/.gitmodules
+++ b/.gitmodules
@@ -1,3 +1,3 @@
[submodule "gnulib"]
- path = .gnulib
+ path = gnulibaaa
url = git://git.sv.gnu.org/gnulib.git
sh-4.3# git --version
git version 2.7.4
sh-4.3# git submodule init
fatal: no submodule mapping found in .gitmodules for path '.gnulib'
sh-4.3#
Since the original bbclass simply assumed there was no .gitmodules
file to begin with, we can easily solve this by not clobbering it
and respect the path choice used by the package itself.
As the version of ./bootstrap shipped with netcf supports this:
--no-git do not use git to update gnulib. Requires that
--gnulib-srcdir point to a correct gnulib snapshot
we can use it in conjunction with the pathspec since we know the
gnulib was just copied in from the sysroot, and does not need
to try and pull any further updates.
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
Signed-off-by: Joe MacDonald <joe_macdonald@mentor.com>
The theory behind this bbclass was reasonable, with the primary
goal being to avoid multiple downloads of gnulib, but it neglected
the fact that packages would be shipping a specific version of the
./bootstrap which will support some flags but maybe not all the
latest ones from the latest gnulib/build-aux/bootstrap file.
I attempted to simply update the two pkgs to use the latest copy
of bootstrap from gnulib but this of course triggers the descent
into autoconf hell that we all know and love. Rather than futzing
with the packages configure.ac and deviating from what the pkg
maintainers intended and tested, we can just let the packages have
independent calls to ./bootstrap with whatever flags are needed.
The goal of this commit is to move the prepend out to the packages
and then delete the class without any real functional change ; i.e.
a purely mechanical change. Then we can adjust each package to
ensure it will still build with a modern host, in an independent
fashion, while keeping the main advantage of not fetching gnulib
two extra times for netcf and fontforge.
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
Signed-off-by: Joe MacDonald <joe_macdonald@mentor.com>