Age | Commit message (Collapse) | Author |
|
Build was failing with
Running transaction check
Transaction check succeeded.
Running transaction test
Error: Transaction check error:
file /usr/lib/mono conflicts between attempted installs of gtk-sharp-2.12.21-r0.i586 and mono-libs-4.5-5.0.1.1-r0.i586
file /usr/lib/mono/gac conflicts between attempted installs of gtk-sharp-2.12.21-r0.i586 and mono-gac-5.0.1.1-r0.i586
It appears this is related to an issue with the way the RPM
package manager deals with ownership of directories under pyro
From Zoltan Boszormenyi:
haven't Pyro replaced the RPM 5.x version with the more Fedora /
Red Hat / SuSE compatible 4.1x?
I vaguely remember that ownership of identical directories are not
allowed in two different RPM packages, it would be a problem on
Fedora, too.
RPM specfiles in Fedora can list empty directories with the %{dir}
directive (this is what different *filesystem* packages are for in
Fedora and RHEL/CentOS) but as far as I can see the Bitbake FILES_*
directives don't make a difference between file patterns and directories.
In Yocto, I only have experience with packaging IPKs. They list all
the parent directories of a file, too. E.g. for something like this:
FILES_${PN} += "${libdir}/package/somefile.bin"
the resulting IPK will contains these:
./usr
./usr/lib
./usr/lib/package
./usr/lib/package/somefile.bin
When you specify file patterns in an RPM specfile, the resulting RPM will
only contain the last one, i.e. the file with the full path. Only this
file will be owned by the RPM. Installing relies on the fact that the
whole path will be created anyway.
The installation conflict may come from RPM being stricter about directory
ownership and two packages can only list the same directories if both
the permissions and the creation date are the same. The latter would be
identical for two sub-packages of the same recipe but different for
different packages.
The problem seems to be inherent to how Bitbake creates the list of
packaged files.
...
The question is: how can we convince Bitbake to avoid adding
parent directories explicitly into the packages?
I think this is what you need to be aware of [...]
https://github.com/openembedded/openembedded-core/commit/0e33d232916125ba5305ced7200cc00f8b5f7b22
...
I suspect there is a deeper underlying issue as other recipes don't appear
to need to make use of DIRFILES=1. But this works as an interim solution
Signed-off-by: Alex J Lennon <ajlennon@dynamicdevices.co.uk>
|
|
Build fails with the following error (caused by a typo s/files/file/):
"Failure expanding variable do_fetch[file-checksums], expression was
${@bb.fetch.get_checksum_file_list(d)} ${@get_lic_checksum_file_list(d)}
which triggered exception IndexError: string index out of range"
Signed-off-by: Ioan-Adrian Ratiu <adrian.ratiu@ni.com>
|
|
Signed-off-by: Alex J Lennon <ajlennon@dynamicdevices.co.uk>
|
|
Signed-off-by: Alex J Lennon <ajlennon@dynamicdevices.co.uk>
|
|
The following were in -dev and need to be in the core package
/usr/lib/libatksharpglue-2.so
/usr/lib/libgdksharpglue-2.so
/usr/lib/libgladesharpglue-2.so
/usr/lib/libglibsharpglue-2.so
/usr/lib/libgtksharpglue-2.so
/usr/lib/libpangosharpglue-2.so
Signed-off-by: Alex J Lennon <ajlennon@dynamicdevices.co.uk>
|
|
mono.bbclass already adds it so it's unnecessary here.
Signed-off-by: Richard Tollerton <rich.tollerton@ni.com>
Signed-off-by: Alex J Lennon <ajlennon@dynamicdevices.co.uk>
|
|
mono.bbclass already adds it so it's unnecessary here.
Signed-off-by: Richard Tollerton <rich.tollerton@ni.com>
Signed-off-by: Alex J Lennon <ajlennon@dynamicdevices.co.uk>
|
|
/usr/lib/gtk-sharp-2.0 and /usr/share/gapi-2.0 are (AFAIK) only used for
building, and so belong in gtk-sharp-dev.
All other relevant FILES entries have been rolled into mono.bbclass.
Signed-off-by: Richard Tollerton <rich.tollerton@ni.com>
Signed-off-by: Alex J Lennon <ajlennon@dynamicdevices.co.uk>
|
|
This package has perl scripts; make sure they're runnable.
Signed-off-by: Richard Tollerton <rich.tollerton@ni.com>
Signed-off-by: Alex J Lennon <ajlennon@dynamicdevices.co.uk>
|
|
recipes rather than target recipes
Testing: Complete build of target image including Mono
Signed-off-by: Alex J Lennon <ajlennon@dynamicdevices.co.uk>
|
|
xbuild native build of source files
Signed-off-by: Alex J Lennon <ajlennon@dynamicdevices.co.uk>
|
|
from upgraded recipes
These are no longer required as per email thread @see https://lists.yoctoproject.org/pipermail/yocto/2014-February/018306.html
Signed-off-by: Alex J Lennon <ajlennon@dynamicdevices.co.uk>
|
|
Synopsis:
- Previous recipe 2.10.2 was failing to build
- Updated to current GTK# release 2.12.21
- Cleaned up recipe
Testing:
- This change has been tested on a qemux86 image with the Mono GTK# 'hello world' example
@see: http://www.mono-project.com/GtkSharp:_Hello_World
Signed-off-by: Alex J Lennon <ajlennon@dynamicdevices.co.uk>
|
|
failure to properly sign assemblies (e.g. policy-2.4-foo.dll). We then fail installing those to the GAC as they are delay signed rather than strong named as they should be. Until the race condition is identified and patched a workaround is to disable parallel make tasks for this recipe
|
|
Added recipes for gtk-sharp, mono-xsp, monotools-server
(gtk-sharp and mono-xsp need testing but they build well enough for the command line monotools-server to run. There may be an issue with monotools-gui-server)
Updated libgdiplus to support OE build with libpng15
|