* Loss of a wayland socket by a systemd user session
From: Tomas Novotny @ 2016-11-18 18:12 UTC (permalink / raw)
To: openembedded-core
Hi all,
I'm using weston and its 'weston-start' script shipped with oe-core (morty).
It works perfectly until root is logged in. The problematic path is:
1) 'weston-start' is started during boot. XDG_RUNTIME_DIR for root doesn't
exist so it is created and 'wayland-0' socket is created in that directory.
So far so good.
2) When root is logged in, systemd user session is started via 'systemd
--user'. This replaces original XDG_RUNTIME_DIR (new tmpfs is mounted over
it) and the 'wayland-0' socket is lost. Logout doesn't help, the original
XDG_RUNTIME_DIR is deleted. You can imagine that weston doesn't work properly
without that socket.
Is there any proper way to fix it?
Thanks,
Tomas
^ permalink raw reply
* Re: [Openembedded-architecture] Enabling uninative by default in oe-core?
From: Richard Purdie @ 2016-11-18 18:06 UTC (permalink / raw)
To: akuster808, Burton, Ross, OE-core, openembedded-architecture
In-Reply-To: <70e3fff2-d9a5-37c3-5e14-5dbcc4e4d37b@gmail.com>
On Fri, 2016-11-18 at 08:28 -0800, akuster808 wrote:
> On 11/17/2016 09:31 AM, Burton, Ross wrote:
> > Background: uninative is a class that downloads a precompiled host
> > glibc for use in the sysroot, thus isolating the native sysroot
> > from the host environment. This means greater sstate reuse, as
> > instead of native builds being dependent on the host system they're
> > able to be shared between all hosts. There is a reference tarball
> > hosted on www.yoctoproject.org, and the URL can be overridden by
> > distros if you would prefer to build your own.
> >
> > We enable this in Poky so that we get greater reuse on the
> > autobuilders, and due to some issues with the C++ ABI the eSDK
> > generation in master now requires uninative to be enabled. The
> > question is: do we now enable uninative by default in oe-core's
> > nodistro (pointing at the yoctoproject tarball), or do we keep it
> > disabled by default and require the user to enable uninative if
> > they wish to build an eSDK?
>
> If Poky wants the default to use a prebuilt uninative that is fine,
> but it should be not be the default in OE. In the spirit of Bitbake,
> uninative should be a build dependency for eSDK with the option of
> using a prebuilt one.
Its not that simple. Using uninative requires certain options passed in
when compiling native recipes for example, e.g. to pick particular C++
abis. If you start the build without those set (since uninative is
disabled), you can't get native sstate built in the right way for it to
work with eSDK. We could of course add a new BBCLASSEXTEND, "native2"
which is native specially for use in the eSDK but that seems silly.
I guess we could move the configuration uninative requires into global
bitbake.conf but not require the actual binary shim to be enabled. That
would let eSDK work in OE-Core just not make OE-Core require uninative.
It would mean the compiler options for native would be a little
different. That might be an acceptable compromise?
> > Though enabling uninative globally does mean everything works out
> > of the box, so following the principle of Least Surprise that's
> > what we should do.
>
> I see there are multiple versions, which one works with which
> release?
The one configured in meta/conf/distro/include/yocto-uninative.inc.
By putting a standard include there its easy for anyone to opt into
this should they wish to.
Cheers,
Richard
^ permalink raw reply
* Re: [PATCH 1/5] systemd: Upgrade to 232
From: Khem Raj @ 2016-11-18 17:35 UTC (permalink / raw)
To: Burton, Ross; +Cc: OE-core
In-Reply-To: <CAJTo0LYgH6_T5Y-YO1Px5eyYFLiud9SQvG1vHGRoebwkhVhdKg@mail.gmail.com>
[-- Attachment #1.1: Type: text/plain, Size: 1086 bytes --]
On 11/18/16 4:38 AM, Burton, Ross wrote:
>
> On 16 November 2016 at 17:47, Khem Raj <raj.khem@gmail.com
> <mailto:raj.khem@gmail.com>> wrote:
>
> * Drop support for rcS.d SysV init scripts.
> These are prone to cause dependency loops, and almost all packages with
> rcS scripts now ship a native systemd service.
>
> * Drop mount propagation patch, it only happens with libseccomp, OE doesnt
> enable it
>
> * kdbus option has disappeared from configure
>
> * Ignore dev-so for PN now since systemd introduced private .so see
> https://github.com/systemd/systemd/issues/3810
> <https://github.com/systemd/systemd/issues/3810>
>
> Signed-off-by: Khem Raj <raj.khem@gmail.com <mailto:raj.khem@gmail.com>>
>
>
> Because systemd-boot basically include the systemd recipe, this breaks
> systemd-boot.
>
> Can we think up a way to handle systemd/systemd-boot without breaking every
> upgrade?
I have been booting systemd 232 on multiple devices how did it got missed to
compile this ?
>
> Ross
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 211 bytes --]
^ permalink raw reply
* State of bitbake world 2016-11-17
From: Martin Jansa @ 2016-11-18 16:49 UTC (permalink / raw)
To: openembedded-core, openembedded-devel
[-- Attachment #1: Type: text/plain, Size: 35875 bytes --]
== Number of issues - stats ==
{| class='wikitable'
!|Date !!colspan='3'|Failed tasks !!colspan='6'|Failed depencencies !!|Signatures !!colspan='12'|QA !!Comment
|-
|| ||qemuarm ||qemux86 ||qemux86_64 ||qemuarm||max||min ||qemux86||max||min ||all ||already-stripped ||libdir ||textrel ||build-deps ||file-rdeps ||version-going-backwards ||host-user-contaminated ||installed-vs-shipped ||unknown-configure-option ||symlink-to-sysroot ||invalid-pkgconfig ||pkgname ||
|-
||2016-11-17 ||9 ||7 ||6 ||17 ||9 ||7 ||12 ||6 ||5 ||0 ||0 ||0 ||2 ||1 ||3 ||24 ||2 ||0 ||0 ||0 ||0 ||0 ||
|}
http://www.openembedded.org/wiki/Bitbake_World_Status
== Failed tasks 2016-11-17 ==
INFO: jenkins-job.sh-1.8.12 Complete log available at http://logs.nslu2-linux.org/buildlogs/oe/world/pyro/log.report.20161118_063609.log
=== common (6) ===
* meta-openembedded/meta-networking/recipes-support/wireshark/wireshark_2.2.1.bb:do_compile
* meta-openembedded/meta-oe/recipes-connectivity/obexftp/obexftp_0.23.bb:do_compile
* meta-openembedded/meta-oe/recipes-connectivity/obex/obex-data-server_0.4.6.bb:do_compile
* meta-openembedded/meta-python/recipes-devtools/python/python3-scales_1.0.9.bb:do_populate_lic
* meta-openembedded/meta-xfce/recipes-bindings/vala/xfce4-vala_4.10.3.bb:do_configure
* openembedded-core/meta/recipes-graphics/libsdl2/libsdl2_2.0.5.bb:do_compile
=== common-x86 (0) ===
=== qemuarm (3) ===
* meta-openembedded/meta-multimedia/recipes-mediacenter/kodi/kodi_16.bb:do_configure
* meta-openembedded/meta-multimedia/recipes-multimedia/vlc/vlc_2.2.2.bb:do_package_qa
* openembedded-core/meta/recipes-sato/webkit/webkitgtk_2.14.1.bb:do_compile
=== qemux86 (1) ===
* meta-browser/recipes-browser/chromium/chromium_52.0.2743.76.bb:do_compile
=== qemux86_64 (0) ===
=== Number of failed tasks (22) ===
{| class=wikitable
|-
|| qemuarm || 9 || http://logs.nslu2-linux.org/buildlogs/oe/world/pyro/log.world.qemuarm.20161116_034630.log/ || http://errors.yoctoproject.org/Errors/Build/24510/
|-
|| qemux86 || 7 || http://logs.nslu2-linux.org/buildlogs/oe/world/pyro/log.world.qemux86.20161116_034634.log/ || http://errors.yoctoproject.org/Errors/Build/24517/
|-
|| qemux86_64 || 6 || http://logs.nslu2-linux.org/buildlogs/oe/world/pyro/log.world.qemux86-64.20161117_042142.log/ || http://errors.yoctoproject.org/Errors/Build/24596/
|}
=== PNBLACKLISTs (116) ===
=== QA issues (32) ===
{| class=wikitable
!| Count ||Issue
|-
||0 ||already-stripped
|-
||0 ||installed-vs-shipped
|-
||0 ||invalid-pkgconfig
|-
||0 ||libdir
|-
||0 ||pkgname
|-
||0 ||symlink-to-sysroot
|-
||0 ||unknown-configure-option
|-
||1 ||build-deps
|-
||24 ||version-going-backwards
|-
||2 ||host-user-contaminated
|-
||2 ||textrel
|-
||3 ||file-rdeps
|}
=== Failed dependencies for qemuarm (17) ===
Complete log: http://logs.nslu2-linux.org/buildlogs/oe/world/pyro/log.dependencies.qemuarm.20161117_032146.log/
Found differences:
Found errors:
* ERROR: 17 issues were found in these recipes: kodi libsdl2 obex-data-server obexftp python3-scales vlc webkitgtk wireshark xfce4-vala
=== Recipes failing with maximal dependencies for qemuarm (9) ===
* kodi -- http://logs.nslu2-linux.org/buildlogs/oe/world/pyro/log.dependencies.qemuarm.20161117_032146.log//2_max/failed/kodi.log
* libsdl2 -- http://logs.nslu2-linux.org/buildlogs/oe/world/pyro/log.dependencies.qemuarm.20161117_032146.log//2_max/failed/libsdl2.log
* obex-data-server -- http://logs.nslu2-linux.org/buildlogs/oe/world/pyro/log.dependencies.qemuarm.20161117_032146.log//2_max/failed/obex-data-server.log
* obexftp -- http://logs.nslu2-linux.org/buildlogs/oe/world/pyro/log.dependencies.qemuarm.20161117_032146.log//2_max/failed/obexftp.log
* python3-scales -- http://logs.nslu2-linux.org/buildlogs/oe/world/pyro/log.dependencies.qemuarm.20161117_032146.log//2_max/failed/python3-scales.log
* vlc -- http://logs.nslu2-linux.org/buildlogs/oe/world/pyro/log.dependencies.qemuarm.20161117_032146.log//2_max/failed/vlc.log
* webkitgtk -- http://logs.nslu2-linux.org/buildlogs/oe/world/pyro/log.dependencies.qemuarm.20161117_032146.log//2_max/failed/webkitgtk.log
* wireshark -- http://logs.nslu2-linux.org/buildlogs/oe/world/pyro/log.dependencies.qemuarm.20161117_032146.log//2_max/failed/wireshark.log
* xfce4-vala -- http://logs.nslu2-linux.org/buildlogs/oe/world/pyro/log.dependencies.qemuarm.20161117_032146.log//2_max/failed/xfce4-vala.log
=== Recipes failing with minimal dependencies for qemuarm (7) ===
* kodi -- http://logs.nslu2-linux.org/buildlogs/oe/world/pyro/log.dependencies.qemuarm.20161117_032146.log//3_min/failed/kodi.log
* obex-data-server -- http://logs.nslu2-linux.org/buildlogs/oe/world/pyro/log.dependencies.qemuarm.20161117_032146.log//3_min/failed/obex-data-server.log
* obexftp -- http://logs.nslu2-linux.org/buildlogs/oe/world/pyro/log.dependencies.qemuarm.20161117_032146.log//3_min/failed/obexftp.log
* python3-scales -- http://logs.nslu2-linux.org/buildlogs/oe/world/pyro/log.dependencies.qemuarm.20161117_032146.log//3_min/failed/python3-scales.log
* webkitgtk -- http://logs.nslu2-linux.org/buildlogs/oe/world/pyro/log.dependencies.qemuarm.20161117_032146.log//3_min/failed/webkitgtk.log
* wireshark -- http://logs.nslu2-linux.org/buildlogs/oe/world/pyro/log.dependencies.qemuarm.20161117_032146.log//3_min/failed/wireshark.log
* xfce4-vala -- http://logs.nslu2-linux.org/buildlogs/oe/world/pyro/log.dependencies.qemuarm.20161117_032146.log//3_min/failed/xfce4-vala.log
=== Failed dependencies for qemux86 (12) ===
Complete log: http://logs.nslu2-linux.org/buildlogs/oe/world/pyro/log.dependencies.qemux86.20161118_031152.log/
Found differences:
Found errors:
* ERROR: 12 issues were found in these recipes: chromium libsdl2 obex-data-server obexftp wireshark xfce4-vala
=== Recipes failing with maximal dependencies for qemux86 (6) ===
* chromium -- http://logs.nslu2-linux.org/buildlogs/oe/world/pyro/log.dependencies.qemux86.20161118_031152.log//2_max/failed/chromium.log
* libsdl2 -- http://logs.nslu2-linux.org/buildlogs/oe/world/pyro/log.dependencies.qemux86.20161118_031152.log//2_max/failed/libsdl2.log
* obex-data-server -- http://logs.nslu2-linux.org/buildlogs/oe/world/pyro/log.dependencies.qemux86.20161118_031152.log//2_max/failed/obex-data-server.log
* obexftp -- http://logs.nslu2-linux.org/buildlogs/oe/world/pyro/log.dependencies.qemux86.20161118_031152.log//2_max/failed/obexftp.log
* wireshark -- http://logs.nslu2-linux.org/buildlogs/oe/world/pyro/log.dependencies.qemux86.20161118_031152.log//2_max/failed/wireshark.log
* xfce4-vala -- http://logs.nslu2-linux.org/buildlogs/oe/world/pyro/log.dependencies.qemux86.20161118_031152.log//2_max/failed/xfce4-vala.log
=== Recipes failing with minimal dependencies for qemux86 (5) ===
* chromium -- http://logs.nslu2-linux.org/buildlogs/oe/world/pyro/log.dependencies.qemux86.20161118_031152.log//3_min/failed/chromium.log
* obex-data-server -- http://logs.nslu2-linux.org/buildlogs/oe/world/pyro/log.dependencies.qemux86.20161118_031152.log//3_min/failed/obex-data-server.log
* obexftp -- http://logs.nslu2-linux.org/buildlogs/oe/world/pyro/log.dependencies.qemux86.20161118_031152.log//3_min/failed/obexftp.log
* wireshark -- http://logs.nslu2-linux.org/buildlogs/oe/world/pyro/log.dependencies.qemux86.20161118_031152.log//3_min/failed/wireshark.log
* xfce4-vala -- http://logs.nslu2-linux.org/buildlogs/oe/world/pyro/log.dependencies.qemux86.20161118_031152.log//3_min/failed/xfce4-vala.log
=== Incorrect PACKAGE_ARCH or sstate signatures (0) ===
Complete log: http://logs.nslu2-linux.org/buildlogs/oe/world/pyro/log.signatures.20161117_101022.log/
* ERROR: Nothing PROVIDES 'libva' (but /home/jenkins/oe/world/shr-core/meta-openembedded/meta-multimedia/recipes-mediacenter/kodi/kodi_16.bb DEPENDS on or otherwise requires it). Close matches:
* ERROR: Required build target 'meta-world-pkgdata' has no buildable providers.
* ERROR: no sigdata files were generated for MACHINE qemux86copy in /home/jenkins/oe/world/shr-core/tmp-glibc/stamps
* ERROR: Nothing PROVIDES 'libva' (but /home/jenkins/oe/world/shr-core/meta-openembedded/meta-multimedia/recipes-mediacenter/kodi/kodi_16.bb DEPENDS on or otherwise requires it). Close matches:
* ERROR: Required build target 'meta-world-pkgdata' has no buildable providers.
* ERROR: no sigdata files were generated for MACHINE qemux86 in /home/jenkins/oe/world/shr-core/tmp-glibc/stamps
PNBLACKLISTs:
openembedded-core/:
meta-browser:
recipes-browser/chromium/cef3_280796.bb:PNBLACKLIST[cef3] ?= "BROKEN: fails to build with gcc-6"
meta-openembedded:
meta-efl/recipes-efl/e17/diskio_svn.bb:PNBLACKLIST[diskio] ?= "broken: switch to https://git.enlightenment.org/enlightenment/modules/diskio.git/ and fix 0.0.1+svnr82070-r0.0/E-MODULES-EXTRA/diskio/e-module-diskio.edc:58. invalid state name: 'off'. "default" state must always be first."
meta-efl/recipes-efl/e17/elbow_git.bb:PNBLACKLIST[elbow] ?= "Depends on blacklisted webkit-efl"
meta-efl/recipes-efl/e17/elmdentica_svn.bb:PNBLACKLIST[elmdentica] ?= "OLD and depends on broken azy"
meta-efl/recipes-efl/e17/emprint_svn.bb:PNBLACKLIST[emprint] ?= "if you want to use these modules with E18, then you need to update it to git recipe fetching newer sources from http://git.enlightenment.org/apps/emprint.git/"
meta-efl/recipes-efl/e17/news_svn.bb:PNBLACKLIST[news] ?= "if you want to use these modules with E18, then you need to update it to git recipe fetching newer sources from http://git.enlightenment.org/enlightenment/modules/news.git/"
meta-efl/recipes-efl/e17/rage_svn.bb:PNBLACKLIST[rage] ?= "if you want to use these modules with E18, then you need to update it to git recipe fetching newer sources from http://git.enlightenment.org/apps/rage.git/"
meta-efl/recipes-efl/e17/screenshot_svn.bb:PNBLACKLIST[screenshot] ?= "depends on blacklisted emprint"
meta-efl/recipes-efl/efl/azy_svn.bb:PNBLACKLIST[azy] ?= "OLD and doesn't build with gcc-5"
meta-efl/recipes-efl/efl/engrave_svn.bb:PNBLACKLIST[engrave] ?= "BROKEN: fails to build with latest oe-core"
meta-efl/recipes-efl/efl/entrance_svn.bb:PNBLACKLIST[entrance] ?= "broken: switch to https://git.enlightenment.org/misc/entrance.git and fix 0.0.4+svnr82070-r7/entrance/data/themes/old/default.edc:678. invalid state name: 'defaault'. "default" state must always be first."
meta-efl/recipes-efl/webkit/webkit-efl.inc:PNBLACKLIST[webkit-efl] ?= "Old and unmaintaned fork with many security issues"
meta-efl/recipes-navigation/mcnavi/mcnavi_0.3.4.bb:PNBLACKLIST[mcnavi] ?= "BROKEN: latest version 0.3.4 is 3 years old and now broken with more strict ejde_cc from efl-1.13"
meta-filesystems/recipes-utils/dmapi/dmapi_2.2.12.bb:PNBLACKLIST[dmapi] ?= "Depends on broken xfsprogs"
meta-filesystems/recipes-utils/xfsdump/xfsdump_3.1.4.bb:PNBLACKLIST[xfsdump] ?= "Depends on broken xfsprogs"
meta-filesystems/recipes-utils/xfsprogs/xfsprogs_3.2.3.bb:PNBLACKLIST[xfsprogs] ?= "BROKEN: Needs upgrade to 4.5.0 version to be compatible with Kernel uapi changes from 4.5"
meta-gnome/recipes-apps/epdfview/epdfview_0.1.8.bb:PNBLACKLIST[epdfview] ?= "BROKEN: images are not displayed anymore"
meta-gnome/recipes-apps/gnome-mplayer/gnome-mplayer_1.0.5.bb:PNBLACKLIST[gnome-mplayer] ?= "rdepends on blacklisted mplayer"
meta-gnome/recipes-extended/gtk-theme-torturer/gtk-theme-torturer_git.bb:PNBLACKLIST[gtk-theme-torturer] ?= "BROKEN: gmacros.h:182:53: error: size of array '_GStaticAssertCompileTimeAssertion_2' is negative"
meta-gnome/recipes-gnome/gcalctool/gcalctool_5.32.0.bb:PNBLACKLIST[gcalctool] ?= "broken at least since April 2013 http://permalink.gmane.org/gmane.comp.handhelds.openembedded/57920 and nobody complained, it's also replaced by gnome calculator"
meta-gnome/recipes-gnome/gdm/gdm_2.32.2.bb:PNBLACKLIST[gdm] ?= "Depends on broken gnome-panel"
meta-gnome/recipes-gnome/gnome-control-center/gnome-control-center_2.32.1.bb:PNBLACKLIST[gnome-control-center] ?= "Depends on broken gnome-menus"
meta-gnome/recipes-gnome/gnome-keyring/gnome-keyring_2.32.1.bb:PNBLACKLIST[gnome-keyring] ?= "This version conflicts with gcr from oe-core"
meta-gnome/recipes-gnome/gnome-menus/gnome-menus_2.30.5.bb:PNBLACKLIST[gnome-menus] ?= "BROKEN: fails to build because of python + conflicts with gnome-menu3"
meta-gnome/recipes-gnome/gnome-panel/gnome-panel3_3.0.2.bb:PNBLACKLIST[gnome-panel3] ?= "CONFLICT: depends on libgweather3 which conflicts with libgweather"
meta-gnome/recipes-gnome/gnome-panel/gnome-panel3_3.0.2.bb:PNBLACKLIST[gnome-panel3] ?= "Depends on broken gnome-menus"
meta-gnome/recipes-gnome/gnome-panel/gnome-panel_2.32.1.bb:PNBLACKLIST[gnome-panel] ?= "Depends on broken libgweather"
meta-gnome/recipes-gnome/gnome-power-manager/gnome-power-manager_2.32.0.bb:PNBLACKLIST[gnome-power-manager] ?= "BROKEN: not compatible with current libnotify"
meta-gnome/recipes-gnome/gnome-session/gnome-session_2.32.1.bb:PNBLACKLIST[gnome-session] ?= "BROKEN: fails to build with gcc-6"
meta-gnome/recipes-gnome/gnome/gnome-terminal_2.30.2.bb:PNBLACKLIST[gnome-terminal] ?= "BROKEN: fails to build with gcc-6"
meta-gnome/recipes-gnome/gnome/libgnomecups_0.2.3.bb:PNBLACKLIST[libgnomecups] ?= "Depends on broken libgnomeui"
meta-gnome/recipes-gnome/gnome/libgnomeprint_2.18.8.bb:PNBLACKLIST[libgnomeprint] ?= "Depends on broken libgnomecups"
meta-gnome/recipes-gnome/gnumeric/gnumeric_1.12.0.bb:PNBLACKLIST[gnumeric] ?= "Depends on broken libgnomeprint"
meta-gnome/recipes-gnome/gweather/libgweather3_3.0.2.bb:PNBLACKLIST[libgweather3] ?= "CONFLICT: 876 files are conflicting with libgweather"
meta-gnome/recipes-gnome/gweather/libgweather_2.30.3.bb:PNBLACKLIST[libgweather] ?= "BROKEN: fails to build with gcc-6"
meta-gnome/recipes-gnome/nautilus/nautilus3_3.2.1.bb:PNBLACKLIST[nautilus3] ?= "BROKEN: fails to build, maybe missing dependency on gnome-desktop-utils.h provider"
meta-gnome/recipes-gnome/pimlico/tasks_0.19.bb:PNBLACKLIST[tasks] ?= "Fails to build with gcc-6"
meta-gnome/recipes-gnome/pimlico/tasks_git.bb:PNBLACKLIST[tasks] ?= "Fails to build with gcc-6"
meta-gnome/recipes-gnome/system-tools/system-tools-backends_2.10.2.bb:PNBLACKLIST[system-tools-backends] ?= "does not build with distroless qemuarm as reported in 'State of bitbake world' thread, nobody volunteered to fix them"
meta-gnome/recipes-gnome/zenity/zenity_2.32.1.bb:PNBLACKLIST[zenity] ?= "BROKEN: doesn't build with B!=S"
meta-gnome/recipes-support/goffice/goffice_0.10.1.bb:PNBLACKLIST[goffice] ?= "BROKEN: fails to build with gcc-6"
meta-gnome/recipes-support/tracker/tracker_0.14.2.bb:PNBLACKLIST[tracker] ?= "BROKEN: fails to build with new binutils-2.27"
meta-gpe/recipes-support/fbreader/fbreader_git.bb:PNBLACKLIST[fbreader] ?= "BROKEN: fails to build with gcc-6"
meta-multimedia/recipes-mkv/mkvtoolnix/mkvtoolnix_git.bb:PNBLACKLIST[mkvtoolnix] ?= "BROKEN: Failx to build with gcc-5"
meta-multimedia/recipes-multimedia/coriander/coriander_2.0.2.bb:PNBLACKLIST[coriander] ?= "BROKEN: fails to use SDL probably because libsdl-config was removed, error: unknown type name 'SDL_Overlay'"
meta-multimedia/recipes-multimedia/dleyna/renderer-service-upnp_0.3.0.bb:PNBLACKLIST[renderer-service-upnp] ?= "BROKEN: doesn't build with B!=S (trying to install rendererconsole.py from ${B} instead of ${S})"
meta-multimedia/recipes-multimedia/gstreamer-0.10/gst-ffmpeg_0.10.13.bb:PNBLACKLIST[gst-ffmpeg] ?= "Not compatible with currently used ffmpeg 3"
meta-multimedia/recipes-multimedia/gstreamer/gst123_0.3.1.bb:PNBLACKLIST[gst123] ?= "gst123 is still "sometimes" using wrong sysroot"
meta-networking/recipes-daemons/dnrd/dnrd_2.20.3.bb:PNBLACKLIST[dnrd] ?= "BROKEN: dnrd-2.20.3-r0 do_package: QA Issue: dnrd: Files/directories were installed but not shipped in any package:"
meta-networking/recipes-kernel/netmap/netmap-modules_git.bb:PNBLACKLIST[netmap-modules] ?= "BROKEN: not compatible with default kernel version 4.8"
meta-networking/recipes-kernel/netmap/netmap_git.bb:PNBLACKLIST[netmap] ?= "BROKEN: Tries to build kernel module and fails, either it should be disabled or there should be dependency on kernel like in netmap-modules"
meta-networking/recipes-protocols/accel-ppp/accel-ppp_git.bb:PNBLACKLIST[accel-ppp] ?= "BROKEN: fails to build with new binutils-2.27"
meta-networking/recipes-support/lksctp-tools/lksctp-tools_1.0.17.bb:PNBLACKLIST[lksctp-tools] ?= "${@bb.utils.contains('DISTRO_FEATURES', 'ld-is-gold', "BROKEN: fails to link against sctp_connectx symbol", '', d)}"
meta-networking/recipes-support/nis/ypbind-mt_2.2.bb:PNBLACKLIST[ypbind-mt] ?= "BROKEN: Depends on broken yp-tools"
meta-oe/recipes-connectivity/bluez/bluez-hcidump_2.5.bb:PNBLACKLIST[bluez-hcidump] ?= "${@bb.utils.contains('DISTRO_FEATURES', 'bluez5', 'bluez5 conflicts with bluez4 and bluez5 is selected in DISTRO_FEATURES', '', d)}"
meta-oe/recipes-connectivity/bluez/bluez4_4.101.bb:PNBLACKLIST[bluez4] ?= "${@bb.utils.contains('DISTRO_FEATURES', 'bluez5', 'bluez5 conflicts with bluez4 and bluez5 is selected in DISTRO_FEATURES', '', d)}"
meta-oe/recipes-connectivity/bluez/gst-plugin-bluetooth_4.101.bb:PNBLACKLIST[gst-plugin-bluetooth] ?= "${@bb.utils.contains('DISTRO_FEATURES', 'bluez5', 'bluez5 conflicts with bluez4 and bluez5 is selected in DISTRO_FEATURES', '', d)}"
meta-oe/recipes-connectivity/soft66/soft66_git.bb:PNBLACKLIST[soft66] ?= "BROKEN: depends on broken libftdi"
meta-oe/recipes-connectivity/wvdial/wvdial_1.61.bb:PNBLACKLIST[wvdial] ?= "Depends on broken wvstreams"
meta-oe/recipes-connectivity/wvdial/wvstreams_4.6.1.bb:PNBLACKLIST[wvstreams] ?= "BROKEN: fails to build with gcc-6"
meta-oe/recipes-connectivity/zeroc-ice/zeroc-ice_3.5.1.bb:PNBLACKLIST[zeroc-ice] ?= "BROKEN: not compatible with default db version"
meta-oe/recipes-core/fakeroot/fakeroot_1.18.4.bb:PNBLACKLIST[fakeroot] ?= "BROKEN: QA Issue: -dev package contains non-symlink .so"
meta-oe/recipes-devtools/cloud9/cloud9_0.6.bb:PNBLACKLIST[cloud9] ?= "Not comatible with current nodejs 0.12, but upstream is working on it for v3"
meta-oe/recipes-devtools/ltp-ddt/ltp-ddt_1.0.0.bb:PNBLACKLIST[ltp-ddt] ?= "BROKEN: fails since last autotools.bbclass changes"
meta-oe/recipes-devtools/packagekit/packagekit_0.5.6.bb:PNBLACKLIST[packagekit] ?= "BROKEN: depends on old deprecated libopkg which is currently disabled and will be removed soon"
meta-oe/recipes-extended/subsurface/subsurface_git.bb:PNBLACKLIST[subsurface] ?= "Needs to be upgraded for compatibility with new libdivecomputer"
meta-oe/recipes-gnome/gtkextra/gtkextra_3.0.5.bb:PNBLACKLIST[gtkextra] ?= "BROKEN: Fails to build with gcc-5"
meta-oe/recipes-graphics/clutter/clutter-box2d_git.bb:PNBLACKLIST[clutter-box2d] ?= "BROKEN: doesn't build with B!=S"
meta-oe/recipes-graphics/fim/fim_0.4-rc1.bb:PNBLACKLIST[fim] ?= "BROKEN: doesn't build with B!=S (flex: can't open lex.lex)"
meta-oe/recipes-graphics/slim/slim_1.3.2.bb:PNBLACKLIST[slim] ?= "does not build with distroless qemuarm as reported in 'State of bitbake world' thread, nobody volunteered to fix them"
meta-oe/recipes-graphics/xorg-driver/xf86-input-mtev_git.bb:PNBLACKLIST[xf86-input-mtev] ?= "BROKEN: doesn't build with B!=S (Makefile without ${S} in sed call)"
meta-oe/recipes-graphics/xorg-driver/xf86-video-geode_2.11.16.bb:PNBLACKLIST[xf86-video-geode] ?= "BROKEN, fails to build"
meta-oe/recipes-kernel/ktap/ktap-module_git.bb:PNBLACKLIST[ktap-module] ?= "Not compatible with 3.19 kernel"
meta-oe/recipes-kernel/ktap/ktap_git.bb:PNBLACKLIST[ktap] ?= "Depends on blacklisted kernel-module-ktapvm"
meta-oe/recipes-multimedia/mplayer/mplayer2_git.bb:PNBLACKLIST[mplayer2] ?= "Not compatible with currently used ffmpeg 3"
meta-oe/recipes-navigation/foxtrotgps/foxtrotgps_1.1.1.bb:PNBLACKLIST[foxtrotgps] ?= "${@bb.utils.contains('DISTRO_FEATURES', 'bluez5', 'bluez5 conflicts with bluez4 and bluez5 is selected in DISTRO_FEATURES', '', d)}"
meta-oe/recipes-navigation/gdal/gdal_1.11.1.bb:PNBLACKLIST[gdal] ?= "BROKEN: fails to build with gcc-5"
meta-oe/recipes-navigation/gypsy/gypsy.inc:PNBLACKLIST[gypsy] ?= "${@bb.utils.contains('DISTRO_FEATURES', 'bluez5', 'bluez5 conflicts with bluez4 and bluez5 is selected in DISTRO_FEATURES', '', d)}"
meta-oe/recipes-navigation/navit/navit.inc:PNBLACKLIST[navit] ?= "${@bb.utils.contains('DISTRO_FEATURES', 'bluez5', 'bluez5 conflicts with bluez4 and bluez5 is selected in DISTRO_FEATURES', '', d)}"
meta-oe/recipes-sato/claws-mail/claws-mail_3.9.0.bb:PNBLACKLIST[claws-mail] ?= "depends on blacklisted libetpan"
meta-oe/recipes-sato/claws-mail/claws-plugin-gtkhtml2-viewer_0.31.bb:PNBLACKLIST[claws-plugin-gtkhtml2-viewer] ?= "depends on blacklisted claws-mail"
meta-oe/recipes-sato/claws-mail/claws-plugin-mailmbox_1.15.bb:PNBLACKLIST[claws-plugin-mailmbox] ?= "depends on blacklisted claws-mail"
meta-oe/recipes-sato/claws-mail/claws-plugin-rssyl_0.34.bb:PNBLACKLIST[claws-plugin-rssyl] ?= "depends on blacklisted claws-mail"
meta-oe/recipes-support/apcupsd/apcupsd_3.14.10.bb:PNBLACKLIST[apcupsd] ?= "BROKEN: doesn't build with B!=S"
meta-oe/recipes-support/emacs/emacs_23.4.bb:PNBLACKLIST[emacs] ?= "qemu: uncaught target signal 11 (Segmentation fault) - core dumped"
meta-oe/recipes-support/fftw/benchfft_3.1.bb:PNBLACKLIST[benchfft] ?= "does not build with distroless qemuarm as reported in 'State of bitbake world' thread, nobody volunteered to fix them"
meta-oe/recipes-support/iksemel/iksemel_1.4.bb:PNBLACKLIST[iksemel] ?= "Not compatible with gnutls version 3.4 currently in oe-core"
meta-oe/recipes-support/libdbi/libdbi-drivers_0.8.3-1.bb:PNBLACKLIST[libdbi-drivers] ?= "BROKEN: fails to build with gcc-5"
meta-oe/recipes-support/libetpan/libetpan_0.57.bb:PNBLACKLIST[libetpan] ?= "Not compatible with gnutls version 3.4 currently in oe-core"
meta-oe/recipes-support/open-vcdiff/open-vcdiff_0.8.4.bb:PNBLACKLIST[open-vcdiff] ?= "BROKEN: fails to build with gcc-6"
meta-oe/recipes-support/opencv/opencv-samples_2.4.bb:PNBLACKLIST[opencv-samples] ?= "Depends on blacklisted opencv"
meta-oe/recipes-support/opencv/opencv_2.4.bb:PNBLACKLIST[opencv] ?= "Not compatible with currently used ffmpeg 3"
meta-oe/recipes-support/openmotif/openmotif_2.3.3.bb:PNBLACKLIST[openmotif] ?= "BROKEN: doesn't build with B!=S"
meta-oe/recipes-support/opensync/libsyncml_0.5.4.bb:PNBLACKLIST[libsyncml] ?= "${@bb.utils.contains('DISTRO_FEATURES', 'bluez5', 'bluez5 conflicts with bluez4 and bluez5 is selected in DISTRO_FEATURES', '', d)}"
meta-oe/recipes-support/openwbem/openwbem_3.2.3.bb:PNBLACKLIST[openwbem] ?= "BROKEN: fails to build with gcc-6"
meta-oe/recipes-support/pidgin/pidgin-otr_4.0.0.bb:PNBLACKLIST[pidgin-otr] ?= "depends on blacklisted pidgin"
meta-oe/recipes-support/vala-terminal/vala-terminal_git.bb:PNBLACKLIST[vala-terminal] ?= "BROKEN: Doesn't work with B!=S, touch: cannot touch `src/.stamp': No such file or directory"
meta-oe/recipes-support/vboxguestdrivers/vboxguestdrivers_4.3.36.bb:PNBLACKLIST[vboxguestdrivers] ?= "BROKEN: not compatible with default kernel version 4.8"
meta-qt5:
meta-smartphone:
meta-fso/recipes-freesmartphone/freesmartphone/libframeworkd-glib_git.bb:PNBLACKLIST[libframeworkd-glib] ?= "BROKEN: many errors when building with gcc-6"
meta-fso/recipes-freesmartphone/freesmartphone/zhone_git.bb:PNBLACKLIST[zhone] ?= "rdepends on python-pycairo which was removed"
meta-shr/recipes-shr/3rdparty/advancedcaching_git.bb:PNBLACKLIST[advancedcaching] ?= "RDEPENDS on python-pygtk was removed from oe-core"
meta-shr/recipes-shr/3rdparty/emtooth2_svn.bb:PNBLACKLIST[emtooth2] ?= "${@bb.utils.contains('DISTRO_FEATURES', 'bluez5', 'bluez5 conflicts with bluez4 and bluez5 is selected in DISTRO_FEATURES', '', d)}"
meta-shr/recipes-shr/3rdparty/ffalarms_git.bb:PNBLACKLIST[ffalarms] = "Doesn't build after vala upgrade from 0.24.0 to 0.26.1"
meta-shr/recipes-shr/3rdparty/gwaterpas_0.3.bb:PNBLACKLIST[gwaterpas] ?= "broken: depends on blacklisted fltk"
meta-shr/recipes-shr/3rdparty/iliwi_git.bb:PNBLACKLIST[iliwi] = "Doesn't build after vala upgrade from 0.24.0 to 0.26.1"
meta-shr/recipes-BROKEN: needs to be adapted to new qtwayland-5.7"
PNBLACKLIST[android-system] = "depends on lxc from meta-virtualiazation which isn't included in my world builds"
PNBLACKLIST[bigbuckbunny-1080p] = "big and doesn't really need to be tested so much"
PNBLACKLIST[bigbuckbunny-480p] = "big and doesn't really need to be tested so much"
PNBLACKLIST[bigbuckbunny-720p] = "big and doesn't really need to be tested so much"
PNBLACKLIST[bigbuckbunny-720p] = "big and doesn't really need to be tested so much"
PNBLACKLIST[tearsofsteel-1080p] = "big and doesn't really need to be tested so much"
PNBLACKLIST[build-appliance-image] = "tries to include whole downloads directory in /home/builder/poky :/"
PNBLACKLIST[linux-yocto-tiny-kexecboot] = "does weird sh!t breaking other kernels and modules - broken for years"
PNBLACKLIST[linux-yocto-tiny] = "does weird sh!t breaking other kernels and modules - broken for years"
QA issues by type:
count: 0 issue: already-stripped
count: 0 issue: libdir
count: 2 issue: textrel
corosync-2.4.0: ELF binary '/tmp/work/core2-64-oe-linux/corosync/2.4.0-r0/packages-split/corosync/usr/sbin/corosync' has relocations in .text [textrel]
x264-r2491+gitAUTOINC+86b71982e1: ELF binary '/tmp/work/i586-oe-linux/x264/r2491+gitAUTOINC+86b71982e1-r0/packages-split/x264/usr/lib/libx264.so.148' has relocations in .text [textrel]
count: 1 issue: build-deps
mpv-0.15.0: mpv rdepends on libvdpau, but it isn't a build dependency, missing libvdpau in DEPENDS or PACKAGECONFIG? [build-deps]
count: 3 issue: file-rdeps
libmodule-build-perl-0.31: /usr/bin/config_data contained in package libmodule-build-perl requires /tmp/sysroots/x86_64-linux/usr/bin/perl-native/perl.real, but no providers found in RDEPENDS_libmodule-build-perl? [file-rdeps]
numptyphysics-0.2+svnr109: /usr/share/numptyphysics/convert_all.sh contained in package numptyphysics requires /bin/bash, but no providers found in RDEPENDS_numptyphysics? [file-rdeps]
ubx-utils-0.0.0+gitrAUTOINC+b63c0932dd: /usr/bin/memory-map.sh contained in package ubx-utils requires /bin/bash, but no providers found in RDEPENDS_ubx-utils? [file-rdeps]
count: 24 issue: version-going-backwards
breakpad-git: Package version for package breakpad-dbg went backwards which would break package feeds from (0:svn-r0.36 to 0:git-r0.0) [version-going-backwards]
breakpad-git: Package version for package breakpad-dbg went backwards which would break package feeds from (0:svn-r0.39 to 0:git-r0.0) [version-going-backwards]
breakpad-git: Package version for package breakpad-dbg went backwards which would break package feeds from (0:svn-r0.42 to 0:git-r0.0) [version-going-backwards]
breakpad-git: Package version for package breakpad-dev went backwards which would break package feeds from (0:svn-r0.36 to 0:git-r0.0) [version-going-backwards]
breakpad-git: Package version for package breakpad-dev went backwards which would break package feeds from (0:svn-r0.39 to 0:git-r0.0) [version-going-backwards]
breakpad-git: Package version for package breakpad-dev went backwards which would break package feeds from (0:svn-r0.42 to 0:git-r0.0) [version-going-backwards]
breakpad-git: Package version for package breakpad-doc went backwards which would break package feeds from (0:svn-r0.36 to 0:git-r0.0) [version-going-backwards]
breakpad-git: Package version for package breakpad-doc went backwards which would break package feeds from (0:svn-r0.39 to 0:git-r0.0) [version-going-backwards]
breakpad-git: Package version for package breakpad-doc went backwards which would break package feeds from (0:svn-r0.42 to 0:gitdump-upload went backwards which would break package feeds from (0:svn-r0.42 to 0:git-r0.0) [version-going-backwards]
breakpad-git: Package version for package breakpad-staticdev went backwards which would break package feeds from (0:svn-r0.36 to 0:git-r0.0) [version-going-backwards]
breakpad-git: Package version for package breakpad-staticdev went backwards which would break package feeds from (0:svn-r0.39 to 0:git-r0.0) [version-going-backwards]
breakpad-git: Package version for package breakpad-staticdev went backwards which would break package feeds from (0:svn-r0.42 to 0:git-r0.0) [version-going-backwards]
breakpad-git: Package version for package breakpad-sym-upload went backwards which would break package feeds from (0:svn-r0.36 to 0:git-r0.0) [version-going-backwards]
breakpad-git: Package version for package breakpad-sym-upload went backwards which would break package feeds from (0:svn-r0.39 to 0:git-r0.0) [version-going-backwards]
breakpad-git: Package version for package breakpad-sym-upload went backwards which would break package feeds from (0:svn-r0.42 to 0:git-r0.0) [version-going-backwards]
breakpad-git: Package version for package breakpad went backwards which would break package feeds from (0:svn-r0.36 to 0:git-r0.0) [version-going-backwards]
breakpad-git: Package version for package breakpad went backwards which would break package feeds from (0:svn-r0.39 to 0:git-r0.0) [version-going-backwards]
breakpad-git: Package version for package breakpad went backwards which would break package feeds from (0:svn-r0.42 to 0:git-r0.0) [version-going-backwards]
count: 2 issue: host-user-contaminated
glibc-locale-2.24: glibc-locale: /glibc-binary-localedata-doi-in/usr/lib/locale/doi_IN/LC_MEASUREMENT is owned by uid 3004, which is the same as the user running bitbake. This may be due to host contamination [host-user-contaminated]
glibc-locale-2.24: glibc-locale: /glibc-binary-localedata-pt-br/usr/lib/locale/pt_BR/LC_MEASUREMENT is owned by uid 3004, which is the same as the user running bitbake. This may be due to host contamination [host-user-contaminated]
count: 0 issue: installed-vs-shipped
count: 0 issue: unknown-configure-option
count: 0 issue: symlink-to-sysroot
count: 0 issue: invalid-pkgconfig
count: 0 issue: pkgname
== Tested changes (not included in master yet) - bitbake ==
latest upstream commit:
91c3b34 lib/bb/cooker.py: fix for BBFILE_PATTERN = ""
not included in master yet:
4f95c8d world-image: add extra target
== Tested changes (not included in master yet) - openembedded-core ==
latest upstream commit:
a675b2c sanity.bbclass: fix logging of an error
not included in master yet:
42633bc qemux86: Add identical qemux86copy variant for tests
6bb13b6 sstate-sysroot-cruft.sh: Extend the whitelist
51d1286 recipes: Replace "cp -a" with "cp -R --no-dereference --preserve=mode,links"
f1c2480 buildhistory.bbclass: metadata-revs show repo parent
b060f95 metadata-revs: provide more information
a956d2c report-error: Allow to upload reports automatically
== Tested changes (not included in master yet) - meta-openembedded ==
latest upstream commit:
7f8915a wireshark: install missing header files
not included in master yet:
52829ae lksctp-tools: 1.0.16 -> 1.0.17
1ef70fd drbd-utils: 8.9.3 -> 8.9.6
03cf724 fftw: Remove the fftw-dev package dependency on non-existent fftw package.
5313d04 libxklavier: upgrade 5.4
2af1cea nginx: update to version 1.10.2
3d9e6de sdparm: 1.09 -> 1.10
3e695ae apache2: cve-2016-5387
ac41e03 libtinyxml2: Upgrade 3.0.0 -> 4.0.1
ac5e765 libmicrohttpd: update to version 0.9 menulibre: initial add 2.1.3
2a39d56 xfce4-whiskermenu-plugin: update to 2.0.2
8f95aa8 xfce4-whiskermenu-plugin: add menulibre to RRECOMMENDS
a864648 ristretto: update to 0.8.1
983b9d7 xfconf: update to 4.12.1
c6991d3 xfce4-notifyd: update to 0.3.3
3c6da1a poppler: update to 0.48.0
63516c9 xfce4-terminal: update to 0.8.1
7e31544 xfce4-panel: do not display desktop icon when no window is opened
1b414ce xfce4-panel: update to 4.12.1
a7c4608 libwnck3: add a recipe
dfaeb3e gstreamer: fix rare but annoying build errors
bf81a51 ttf-abyssinica: update SRC_URI
e2325f4 libiio: add recipe
7061283 squid: disable gnu atomic operations for mipsel
23a7f8d python-m2crypto: inherit siteinfo
a56dddd chrony: remove unrecognized option ipv6
6b0be77 meta_oe_security_flags: Disable PIE for s3c64xx-gpio/s3c24xx-gpio/cpufrequtils
170de5a boinc: Add recipe for boinc-client
c292e99 meta_oe_security_flags.inc: Add libcec, libmodplug, libcdio
7d9dd8c dcadec, libsquish: Add new recipes
b032a63 fix QA Issue for opensaf
9d2b852 libiio: add recipe
5914eab fwts: Update to 16.09 release
70e09c1 libvdpau: Add recipe
0533796 krb5: Add -fPIC to compile flags
84d6a1f libvdpau: Disable PIE
7fdf37f libcec: Update to 3.1.0+
04dc34b kodi: Add krypton/17.x Jarvis/16.x recipes
4a7d3d6 streamripper: add v1.64.6
bcf35d9 tsock: Make use of LDFLAGS
0adff8f kodi: Fix build with pic on x86_64
a7d71db mariadb: use faster download URL
264b8db edac-utils: fix systemd service
65705ee python-scales: add recipe for version 1.0.9
f4cd45e python-cassandra-driver: add recipe for version 3.7.1
a88416a python-spidev: add recipe for version 3.2
661d598 augeas: fix QA warning
6d95ecc fwknop: Initial add 2.6.9
9012b24 libplist: Remove rpaths surgically
993b0f2 kodi-17: Add packageconfig for lcms support
d3ab4e4 Revert "physfs: move to sources found at github/supertux"
1d2d076 xfce4-battery-plugin: update to 1.1.0
070bd73 xfce4-datetime-plugin: update to 0.7.0
bd77ca4 xfce4-diskperf-plugin: update to 2.6.0
60e78ec xfce4-fsguard-plugin: update to 1.1.0
7372707 xfce4-mpc-plugin: update to 0.5.0
6155b86 xfce4-netload-plugin: update to 1.3.0
0e9129f xfce4-smartbookmark-plugin: update to 0.5.0
fc4a397 xfce4-systemload-plugin: update to 1.2.0
c3fdac8 xfce4-wavelan-plugin: update to 0.6.0
6cd6847 xfmpc: update to 0.2.3
90f7486 gparted: update to 0.27.0
36860f8 networkmanager: update to 1.4.2
b918893 network-manager-applet: update to 1.4.2
36c59fc portaudio-v19: update to v190600 released on 20161030
f6c3339 python-pyserial: remove serialjava.py
cfda0ae samba: Fix build with musl
fc5abe2 lockdev: Pretend GNU libc on musl
ada6bc5 kodi-17: Fix build with musl
a290a4e gnuplot: upgrade to 5.0.5
8079ede glmark: update to latest sources
3ccde0f pyyaml: Enable nativesdk bake
6b7fe33 breakpad: Upgrade to latest
9975789 iozone3: 434 -> 465
86fbc95 libhugetlbfs: 1.19 -> 1.20
6faacd0 phoronix-test-suite: 6.0.1 -> 6.6.1
b8b4b2c asio: DEPENDS on openssl
bda3baf asio: fix a musl compilation warning
60e0c96 apache2: include .load files in modules.d
5589fea openjpeg: rename the download file
d1a0a87 openobex: upgrade to 1.7.2
94a0bd0 python-humanize, python3-humanize: Add recipe for version 0.5.1
e3dbe72 ifenslave: make option '-h' work
c00fd46 opencv: fix QA issue
ace909b libeigen: set tarball name as ${BP}.tar.bz2
68bda63 libowfat: add v0.31
19cc43c lvm2: 2.02.138 -> 2.02.166
666342d opencv: checking existence of /usr/lib
5928fab libdbus-c++: added recipe for it
357ab85 ncp: add v1.2.4
== Tested changes (not included in master yet) - meta-qt5 ==
latest upstream commit:
81fb771 Update Qt5's git repositories to match new locations
not included in master yet:
== Tested changes (not included in master yet) - meta-browser ==
latest upstream commit:
1edcce7 chromium-wayland: skip when CHROMIUM_ENABLE_WAYLAND isn't enabled
not included in master yet:
== Tested changes (not included in master yet) - meta-webos-ports ==
latest upstream commit:
6d82a3f libqofono: use the recipe from meta-qt5
not included in master yet:
== Tested changes (not included in master yet) - meta-smartphone ==
latest upstream commit:
eb87e6d linux-lg-mako: bump SRCREV to fix build with gcc6
not included in master yet:
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 169 bytes --]
^ permalink raw reply
* Yocto Project Status WW47
From: Jolley, Stephen K @ 2016-11-18 16:35 UTC (permalink / raw)
To: yocto@yoctoproject.org, openembedded-core@lists.openembedded.org
[-- Attachment #1: Type: text/plain, Size: 2419 bytes --]
Current Dev Position: YP 2.3 M1
Next Deadline: YP 2.3 M1 by Dec. 12, 2016
SWAT team rotation: Leo -> Juro
https://wiki.yoctoproject.org/wiki/Yocto_Build_Failure_Swat_Team
Key Status/Updates:
* 2.1.2 QA report is out and likely to be released imminently.
* The QA report for 2.1.2 is at: https://wiki.yoctoproject.org/wiki/WW46_-_2016-11-10_-_Test_Cycle_2.1.2_rc1
* At this point most 2.3 targeted features should have been identified in bugzilla. M1 is comparatively loaded compared to M2/M3 and some individuals have particularly heavy workloads so loading balancing is being done.
* We'll run a 2.0.3 test build over the weekend to find out our status there.
* Backports of fixes to the morty release branch are now occurring, thanks Armin. Armin is looking like the principle morty maintainer for that stable release series.
* There are some changes planned to the getVar/getVarFlag expansion defaults and the old data store APIs are likely to be removed imminently. There is an email on the openembedded-architecture list about this.
* WDD is now climbing again unfortunately, we've wiped out half of the improvements we made in the 2.2 cycle.
Proposed upcoming dot releases:
YP 2.0.3 Release by Dec. 9, 2016
YP 2.2.1 Release by Jan. 20, 2017
YP 2.1.3 Release by May. 19, 2017
Key YP 2.3 Dates:
YP 2.3 M1 Cutoff is Dec. 12, 2016
YP 2.3 M1 Release is Dec. 23, 2016
YP 2.3 M2 Cutoff is Jan. 23, 2017
YP 2.3 M2 Release is Feb. 3, 2017
YP 2.3 M3 Cutoff is Feb 27, 2017
YP 2.3 M3 Release is Mar. 10, 2017
YP 2.3 M4 Cutoff is April 3, 2017
YP 2.3 M4 Release is April 28, 2017
Tracking Metrics:
WDD 2516 (last week 2497)
(https://wiki.yoctoproject.org/charts/combo.html)
Key Status Links for YP:
https://wiki.yoctoproject.org/wiki/Yocto_Project_v2.3_Status
https://wiki.yoctoproject.org/wiki/Yocto_2.3_Schedule
https://wiki.yoctoproject.org/wiki/Yocto_2.3_Features
[If anyone has suggestions for other information you'd like to see on this weekly status update, let us know!]
Thanks,
Stephen K. Jolley
Yocto Project Program Manager
INTEL, MS JF1-255, 2111 N.E. 25th Avenue, Hillsboro, OR 97124
* Work Telephone: (503) 712-0534
* Cell: (208) 244-4460
* Email: stephen.k.jolley@intel.com
[-- Attachment #2: Type: text/html, Size: 20182 bytes --]
^ permalink raw reply
* Re: Enabling uninative by default in oe-core?
From: akuster808 @ 2016-11-18 16:28 UTC (permalink / raw)
To: Burton, Ross, OE-core, openembedded-architecture
In-Reply-To: <CAJTo0LbvGwRpzxfOL0505w+Vz=Jhf6O3QOr5Z8SX9XaFqaZ7eg@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1877 bytes --]
On 11/17/2016 09:31 AM, Burton, Ross wrote:
> Hi,
>
> Background: uninative is a class that downloads a precompiled host
> glibc for use in the sysroot, thus isolating the native sysroot from
> the host environment. This means greater sstate reuse, as instead of
> native builds being dependent on the host system they're able to be
> shared between all hosts. There is a reference tarball hosted on
> www.yoctoproject.org <http://www.yoctoproject.org>, and the URL can be
> overridden by distros if you would prefer to build your own.
>
> We enable this in Poky so that we get greater reuse on the
> autobuilders, and due to some issues with the C++ ABI the eSDK
> generation in master now requires uninative to be enabled. The
> question is: do we now enable uninative by default in oe-core's
> nodistro (pointing at the yoctoproject tarball), or do we keep it
> disabled by default and require the user to enable uninative if they
> wish to build an eSDK?
If Poky wants the default to use a prebuilt uninative that is fine, but
it should be not be the default in OE. In the spirit of Bitbake,
uninative should be a build dependency for eSDK with the option of using
a prebuilt one.
>
> Personally I'm torn: I don't like eSDK not working out of the box, but
> I don't really like oe-core nodistro depending on uninative.
Well Bitbake does not work out of the box on every host either. There
are packages needing to exist on the host as a prerequisite. I see this
in the same light.
Do we make "Buildtools" a requirement to use Bitbake?
||||||
> Though enabling uninative globally does mean everything works out of
> the box, so following the principle of Least Surprise that's what we
> should do.
I see there are multiple versions, which one works with which release?
- Armin
>
> Ross
>
>
[-- Attachment #2: Type: text/html, Size: 3479 bytes --]
^ permalink raw reply
* [PATCH] ofono: update 1.18 -> 1.19
From: André Draszik @ 2016-11-18 16:06 UTC (permalink / raw)
To: openembedded-core
From: André Draszik <adraszik@tycoint.com>
In particular, this fixes a crash on shutdown.
From upstream's ChangeLog:
ver 1.19:
Fix issue with DHCP parsing and Huawei modems.
Fix issue with detecting Huawei E3372 modem.
Fix issue with handling serving cell info.
Fix issue with handling SIM SC facility lock.
Fix issue with Android RIL PIN retry logic.
Fix issue with Android RIL and RAT handling.
Add support for Android RIL cell broadcast.
Add support for SoFIA 3GR thermal management.
Signed-off-by: André Draszik <adraszik@tycoint.com>
---
meta/recipes-connectivity/ofono/{ofono_1.18.bb => ofono_1.19.bb} | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
rename meta/recipes-connectivity/ofono/{ofono_1.18.bb => ofono_1.19.bb} (52%)
diff --git a/meta/recipes-connectivity/ofono/ofono_1.18.bb b/meta/recipes-connectivity/ofono/ofono_1.19.bb
similarity index 52%
rename from meta/recipes-connectivity/ofono/ofono_1.18.bb
rename to meta/recipes-connectivity/ofono/ofono_1.19.bb
index b070731..adebd71 100644
--- a/meta/recipes-connectivity/ofono/ofono_1.18.bb
+++ b/meta/recipes-connectivity/ofono/ofono_1.19.bb
@@ -4,7 +4,7 @@ SRC_URI = "\
${KERNELORG_MIRROR}/linux/network/${BPN}/${BP}.tar.xz \
file://ofono \
"
-SRC_URI[md5sum] = "0a6b37c8ace891cb2a7ca5d121043a0a"
-SRC_URI[sha256sum] = "53cdbf342913f46bce4827241c60e24255a3d43a94945edf77482ae5b312d51f"
+SRC_URI[md5sum] = "a5f8803ace110511b6ff5a2b39782e8b"
+SRC_URI[sha256sum] = "a0e09bdd8b53b8d2e4b54f1863ecd9aebe4786477a6cbf8f655496e8edb31c81"
CFLAGS_append_libc-uclibc = " -D_GNU_SOURCE"
--
2.10.2
^ permalink raw reply related
* Re: small number of perl modules that can't be cross-compiled
From: Robert P. J. Day @ 2016-11-18 14:55 UTC (permalink / raw)
To: André Draszik; +Cc: OE Core mailing list
In-Reply-To: <1479480655.27546.16.camel@andred.net>
[-- Attachment #1: Type: text/plain, Size: 2854 bytes --]
On Fri, 18 Nov 2016, André Draszik wrote:
> On Fri, 2016-11-18 at 09:09 -0500, Robert P. J. Day wrote:
> > On Fri, 18 Nov 2016, André Draszik wrote:
> >
> > > On Fri, 2016-11-18 at 07:46 -0500, Robert P. J. Day wrote:
> > > > On Fri, 18 Nov 2016, André Draszik wrote:
> > > >
> > > > > On Fri, 2016-11-18 at 06:41 -0500, Robert P. J. Day wrote:
> > > > > > after OE recipfying over 100 perl modules from CPAN, i'm down to
> > > > > > less than a dozen that are going to take more work, and a small
> > > > > > number
> > > > > > of those seem to be simply badly written in that they don't
> > > > > > support
> > > > > > cross-compilation for my target choice of "qemuppc". example
> > > > > > boilerplate recipe i put together produces this:
> > > > > >
> > > > > > $ make libauthen-pam-perl
> > > > > > ... snip ...
> > > > > > Checking if your kit is complete...
> > > > > > Looks good
> > > > > > checking for gcc... powerpc-wrs-linux-gcc -m32 -mhard-float
> > > > > > -mcpu=7400
> > > > > > --
> > > > > > sysroot=/home/rpjday/WRL/builds/msm/nov17/bitbake_build/tmp/sysroo
> > > > > > ts/q
> > > > > > emup
> > > > > > pc
> > > > > > checking for C compiler default output file name... a.out
> > > > > > checking whether the C compiler works... configure: error: cannot
> > > > > > run
> > > > > > C compiled programs.
> > > > > > If you meant to cross compile, use `--host'.
> > > > > > See `config.log' for more details.
> > > > >
> > > > > It'd be useful to see config.log, ...
> > > >
> > > > see bottom.
> > >
> > > That message is referring to config.log from autotools, not the
> > > bitbake do_configure.log. Should be somewhere below ${B}
> >
> > sorry, my mistake ... see below:
> >
> > This file contains any messages produced by compilers while
> > running configure, to aid debugging if configure makes a mistake.
> >
> > It was created by Authen::PAM configure 0.16, which was
> > generated by GNU Autoconf 2.59. Invocation command line was
> >
> > $ ./configure
>
> I think the issues are in your recipe. You should see *many* arguments to
> configure. In particular --build= --host= --target=, but many more.
>
> Also, this explains that message:
>
> configure:1697: error: cannot run C compiled programs.
> If you meant to cross compile, use `--host'.
i realize that now, so that will be today's project. thanks.
rday
--
========================================================================
Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca
Twitter: http://twitter.com/rpjday
LinkedIn: http://ca.linkedin.com/in/rpjday
========================================================================
^ permalink raw reply
* Re: small number of perl modules that can't be cross-compiled
From: André Draszik @ 2016-11-18 14:50 UTC (permalink / raw)
To: Robert P. J. Day; +Cc: OE Core mailing list
In-Reply-To: <alpine.LFD.2.20.1611180908440.18681@localhost.localdomain>
On Fri, 2016-11-18 at 09:09 -0500, Robert P. J. Day wrote:
> On Fri, 18 Nov 2016, André Draszik wrote:
>
> > On Fri, 2016-11-18 at 07:46 -0500, Robert P. J. Day wrote:
> > > On Fri, 18 Nov 2016, André Draszik wrote:
> > >
> > > > On Fri, 2016-11-18 at 06:41 -0500, Robert P. J. Day wrote:
> > > > > after OE recipfying over 100 perl modules from CPAN, i'm down to
> > > > > less than a dozen that are going to take more work, and a small
> > > > > number
> > > > > of those seem to be simply badly written in that they don't
> > > > > support
> > > > > cross-compilation for my target choice of "qemuppc". example
> > > > > boilerplate recipe i put together produces this:
> > > > >
> > > > > $ make libauthen-pam-perl
> > > > > ... snip ...
> > > > > Checking if your kit is complete...
> > > > > Looks good
> > > > > checking for gcc... powerpc-wrs-linux-gcc -m32 -mhard-float
> > > > > -mcpu=7400
> > > > > --
> > > > > sysroot=/home/rpjday/WRL/builds/msm/nov17/bitbake_build/tmp/sysroo
> > > > > ts/q
> > > > > emup
> > > > > pc
> > > > > checking for C compiler default output file name... a.out
> > > > > checking whether the C compiler works... configure: error: cannot
> > > > > run
> > > > > C compiled programs.
> > > > > If you meant to cross compile, use `--host'.
> > > > > See `config.log' for more details.
> > > >
> > > > It'd be useful to see config.log, ...
> > >
> > > see bottom.
> >
> > That message is referring to config.log from autotools, not the
> > bitbake do_configure.log. Should be somewhere below ${B}
>
> sorry, my mistake ... see below:
>
> This file contains any messages produced by compilers while
> running configure, to aid debugging if configure makes a mistake.
>
> It was created by Authen::PAM configure 0.16, which was
> generated by GNU Autoconf 2.59. Invocation command line was
>
> $ ./configure
I think the issues are in your recipe. You should see *many* arguments to
configure. In particular --build= --host= --target=, but many more.
Also, this explains that message:
configure:1697: error: cannot run C compiled programs.
If you meant to cross compile, use `--host'.
Cheers,
Andre'
^ permalink raw reply
* Re: small number of perl modules that can't be cross-compiled
From: Robert P. J. Day @ 2016-11-18 14:09 UTC (permalink / raw)
To: André Draszik; +Cc: OE Core mailing list
In-Reply-To: <1479474900.27546.14.camel@andred.net>
[-- Attachment #1: Type: text/plain, Size: 11326 bytes --]
On Fri, 18 Nov 2016, André Draszik wrote:
> On Fri, 2016-11-18 at 07:46 -0500, Robert P. J. Day wrote:
> > On Fri, 18 Nov 2016, André Draszik wrote:
> >
> > > On Fri, 2016-11-18 at 06:41 -0500, Robert P. J. Day wrote:
> > > > after OE recipfying over 100 perl modules from CPAN, i'm down to
> > > > less than a dozen that are going to take more work, and a small number
> > > > of those seem to be simply badly written in that they don't support
> > > > cross-compilation for my target choice of "qemuppc". example
> > > > boilerplate recipe i put together produces this:
> > > >
> > > > $ make libauthen-pam-perl
> > > > ... snip ...
> > > > Checking if your kit is complete...
> > > > Looks good
> > > > checking for gcc... powerpc-wrs-linux-gcc -m32 -mhard-float -mcpu=7400
> > > > --
> > > > sysroot=/home/rpjday/WRL/builds/msm/nov17/bitbake_build/tmp/sysroots/q
> > > > emup
> > > > pc
> > > > checking for C compiler default output file name... a.out
> > > > checking whether the C compiler works... configure: error: cannot run
> > > > C compiled programs.
> > > > If you meant to cross compile, use `--host'.
> > > > See `config.log' for more details.
> > >
> > > It'd be useful to see config.log, ...
> >
> > see bottom.
>
> That message is referring to config.log from autotools, not the
> bitbake do_configure.log. Should be somewhere below ${B}
sorry, my mistake ... see below:
This file contains any messages produced by compilers while
running configure, to aid debugging if configure makes a mistake.
It was created by Authen::PAM configure 0.16, which was
generated by GNU Autoconf 2.59. Invocation command line was
$ ./configure
## --------- ##
## Platform. ##
## --------- ##
hostname = localhost.localdomain
uname -m = x86_64
uname -r = 4.7.7-100.fc23.x86_64
uname -s = Linux
uname -v = #1 SMP Fri Oct 7 22:16:13 UTC 2016
/usr/bin/uname -p = x86_64
/bin/uname -X = unknown
/bin/arch = x86_64
/usr/bin/arch -k = unknown
/usr/convex/getsysinfo = unknown
hostinfo = unknown
/bin/machine = unknown
/usr/bin/oslevel = unknown
/bin/universe = unknown
PATH: /home/rpjday/WRL/builds/msm/nov17/bitbake_build/tmp/sysroots/x86_64-linux/usr/bin/perl-native
PATH: /home/rpjday/WRL/builds/msm/nov17/layers/oe-core/scripts
PATH: /home/rpjday/WRL/builds/msm/nov17/bitbake_build/tmp/sysroots/x86_64-linux/usr/bin/powerpc-wrs-linux
PATH: /home/rpjday/WRL/builds/msm/nov17/bitbake_build/tmp/sysroots/qemuppc/usr/bin/crossscripts
PATH: /home/rpjday/WRL/builds/msm/nov17/bitbake_build/tmp/sysroots/x86_64-linux/usr/sbin
PATH: /home/rpjday/WRL/builds/msm/nov17/bitbake_build/tmp/sysroots/x86_64-linux/usr/bin
PATH: /home/rpjday/WRL/builds/msm/nov17/bitbake_build/tmp/sysroots/x86_64-linux/sbin
PATH: /home/rpjday/WRL/builds/msm/nov17/bitbake_build/tmp/sysroots/x86_64-linux/bin
PATH: /home/rpjday/WRL/builds/msm/nov17/layers/oe-core/scripts
PATH: /home/rpjday/WRL/builds/msm/nov17/bitbake/bin
PATH: /home/rpjday/WRL/builds/msm/nov17/bitbake_build/buildtools/sysroots/x86_64-wrlinuxsdk-linux/usr/bin
PATH: /home/rpjday/WRL/builds/msm/nov17/layers/wrlinux/scripts
PATH: /home/rpjday/WRL/builds/msm/nov17/scripts
PATH: /scripts
PATH: /home/rpjday/oe/dist/bin/bb/bin
PATH: /home/rpjday/oe/dist/bin/bb/bin
PATH: /usr/local/bin
PATH: /usr/local/sbin
PATH: /usr/bin
PATH: /usr/sbin
PATH: /home/rpjday/.local/bin
PATH: /home/rpjday/bin
PATH: /home/rpjday/WRL/builds/msm/nov17/layers/wrlinux/scripts
PATH: /home/rpjday/WRL/builds/msm/nov17/layers/wrlcompat/scripts
PATH: /home/rpjday/WRL/builds/msm/nov17/layers/local/scripts
## ----------- ##
## Core tests. ##
## ----------- ##
configure:1313: checking for gcc
configure:1339: result: powerpc-wrs-linux-gcc -m32 -mhard-float -mcpu=7400 --sysroot=/home/rpjday/WRL/builds/msm/nov17/bitbake_build/tmp/sysroots/qemuppc
configure:1583: checking for C compiler version
configure:1586: powerpc-wrs-linux-gcc -m32 -mhard-float -mcpu=7400 --sysroot=/home/rpjday/WRL/builds/msm/nov17/bitbake_build/tmp/sysroots/qemuppc --version </dev/null >&5
powerpc-wrs-linux-gcc (Wind River Linux 5.2.0-8.0-qemuppc) 5.2.0
Copyright (C) 2015 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
configure:1589: $? = 0
configure:1591: powerpc-wrs-linux-gcc -m32 -mhard-float -mcpu=7400 --sysroot=/home/rpjday/WRL/builds/msm/nov17/bitbake_build/tmp/sysroots/qemuppc -v </dev/null >&5
Using built-in specs.
COLLECT_GCC=powerpc-wrs-linux-gcc
COLLECT_LTO_WRAPPER=/home/rpjday/WRL/builds/msm/nov17/bitbake_build/tmp/sysroots/x86_64-linux/usr/libexec/powerpc-wrs-linux/gcc/powerpc-wrs-linux/5.2.0/lto-wrapper
Target: powerpc-wrs-linux
Configured with: /home/rpjday/WRL/builds/msm/nov17/bitbake_build/tmp/work-shared/gcc-5.2.0-r0/gcc-5.2.0/configure --build=x86_64-linux --host=x86_64-linux --target=powerpc-wrs-linux --prefix=/home/rpjday/WRL/builds/msm/nov17/bitbake_build/tmp/sysroots/x86_64-linux/usr --exec_prefix=/home/rpjday/WRL/builds/msm/nov17/bitbake_build/tmp/sysroots/x86_64-linux/usr --bindir=/home/rpjday/WRL/builds/msm/nov17/bitbake_build/tmp/sysroots/x86_64-linux/usr/bin/powerpc-wrs-linux --sbindir=/home/rpjday/WRL/builds/msm/nov17/bitbake_build/tmp/sysroots/x86_64-linux/usr/bin/powerpc-wrs-linux --libexecdir=/home/rpjday/WRL/builds/msm/nov17/bitbake_build/tmp/sysroots/x86_64-linux/usr/libexec/powerpc-wrs-linux --datadir=/home/rpjday/WRL/builds/msm/nov17/bitbake_build/tmp/sysroots/x86_64-linux/usr/share --sysconfdir=/home/rpjday/WRL/builds/msm/nov17/bitbake_build/tmp/sysroots/x86_64-linux/etc --sharedstatedir=/home/rpjday/WRL/builds/msm/nov17/bitbake_build/tmp/sysroots/x86_64-linux/com --localstatedir=/home/rpjday/WRL/builds/msm/nov17/bitbake_build/tmp/sysroots/x86_64-linux/var --libdir=/home/rpjday/WRL/builds/msm/nov17/bitbake_build/tmp/sysroots/x86_64-linux/usr/lib/powerpc-wrs-linux --includedir=/home/rpjday/WRL/builds/msm/nov17/bitbake_build/tmp/sysroots/x86_64-linux/usr/include --oldincludedir=/home/rpjday/WRL/builds/msm/nov17/bitbake_build/tmp/sysroots/x86_64-linux/usr/include --infodir=/home/rpjday/WRL/builds/msm/nov17/bitbake_build/tmp/sysroots/x86_64-linux/usr/share/info --mandir=/home/rpjday/WRL/builds/msm/nov17/bitbake_build/tmp/sysroots/x86_64-linux/usr/share/man --disable-silent-rules --disable-dependency-tracking --with-libtool-sysroot=/home/rpjday/WRL/builds/msm/nov17/bitbake_build/tmp/sysroots/x86_64-linux --enable-clocale=generic --with-gnu-ld --enable-shared --enable-languages=c,c++ --enable-threads=posix --disable-multilib --enable-c99 --enable-long-long --enable-symvers=gnu --enable-libstdcxx-pch --program-prefix=powerpc-wrs-linux- --without-local-prefix --enable-lto --enable-libssp --disable-bootstrap --disable-libmudflap --with-system-zlib --with-linker-hash-style=gnu --enable-linker-build-id --with-ppl=no --with-cloog=no --enable-checking=release --enable-cheaders=c_global --without-isl --with-gxx-include-dir=/not/exist/usr/include/c++/5.2.0 --with-sysroot=/not/exist --with-build-sysroot=/home/rpjday/WRL/builds/msm/nov17/bitbake_build/tmp/sysroots/qemuppc --enable-secureplt --with-long-double-128 --enable-targets=powerpc64 --enable-poison-system-directories --with-mpfr=/home/rpjday/WRL/builds/msm/nov17/bitbake_build/tmp/sysroots/x86_64-linux/usr --with-system-zlib --disable-nls --enable-__cxa_atexit --with-pkgversion='Wind River Linux 5.2.0-8.0-qemuppc' --with-bugurl=support@windriver.com
Thread model: posix
gcc version 5.2.0 (Wind River Linux 5.2.0-8.0-qemuppc)
configure:1594: $? = 0
configure:1596: powerpc-wrs-linux-gcc -m32 -mhard-float -mcpu=7400 --sysroot=/home/rpjday/WRL/builds/msm/nov17/bitbake_build/tmp/sysroots/qemuppc -V </dev/null >&5
powerpc-wrs-linux-gcc: error: unrecognized command line option '-V'
powerpc-wrs-linux-gcc: fatal error: no input files
compilation terminated.
configure:1599: $? = 1
configure:1622: checking for C compiler default output file name
configure:1625: powerpc-wrs-linux-gcc -m32 -mhard-float -mcpu=7400 --sysroot=/home/rpjday/WRL/builds/msm/nov17/bitbake_build/tmp/sysroots/qemuppc -O2 -pipe -g -Wl,-O1 -Wl,--hash-style=gnu -Wl,--as-needed conftest.c >&5
configure:1628: $? = 0
configure:1674: result: a.out
configure:1679: checking whether the C compiler works
configure:1685: ./a.out
./configure: line 1686: ./a.out: cannot execute binary file: Exec format error
configure:1688: $? = 126
configure:1697: error: cannot run C compiled programs.
If you meant to cross compile, use `--host'.
See `config.log' for more details.
## ---------------- ##
## Cache variables. ##
## ---------------- ##
ac_cv_env_CC_set=set
ac_cv_env_CC_value='powerpc-wrs-linux-gcc -m32 -mhard-float -mcpu=7400 --sysroot=/home/rpjday/WRL/builds/msm/nov17/bitbake_build/tmp/sysroots/qemuppc'
ac_cv_env_CFLAGS_set=set
ac_cv_env_CFLAGS_value=' -O2 -pipe -g '
ac_cv_env_CPPFLAGS_set=set
ac_cv_env_CPPFLAGS_value=
ac_cv_env_CPP_set=set
ac_cv_env_CPP_value='powerpc-wrs-linux-gcc -E --sysroot=/home/rpjday/WRL/builds/msm/nov17/bitbake_build/tmp/sysroots/qemuppc -m32 -mhard-float -mcpu=7400'
ac_cv_env_LDFLAGS_set=set
ac_cv_env_LDFLAGS_value='-Wl,-O1 -Wl,--hash-style=gnu -Wl,--as-needed'
ac_cv_env_build_alias_set=
ac_cv_env_build_alias_value=
ac_cv_env_host_alias_set=
ac_cv_env_host_alias_value=
ac_cv_env_target_alias_set=
ac_cv_env_target_alias_value=
ac_cv_exeext=
ac_cv_prog_ac_ct_CC='powerpc-wrs-linux-gcc -m32 -mhard-float -mcpu=7400 --sysroot=/home/rpjday/WRL/builds/msm/nov17/bitbake_build/tmp/sysroots/qemuppc'
## ----------------- ##
## Output variables. ##
## ----------------- ##
CC='powerpc-wrs-linux-gcc -m32 -mhard-float -mcpu=7400 --sysroot=/home/rpjday/WRL/builds/msm/nov17/bitbake_build/tmp/sysroots/qemuppc'
CFLAGS=' -O2 -pipe -g '
CPP='powerpc-wrs-linux-gcc -E --sysroot=/home/rpjday/WRL/builds/msm/nov17/bitbake_build/tmp/sysroots/qemuppc -m32 -mhard-float -mcpu=7400'
CPPFLAGS=''
DEFS=''
DL_LOAD_FLAGS=''
ECHO_C=''
ECHO_N='-n'
ECHO_T=''
EXEEXT=''
LDFLAGS='-Wl,-O1 -Wl,--hash-style=gnu -Wl,--as-needed'
LIBOBJS=''
LIBS=''
LTLIBOBJS=''
OBJEXT=''
PACKAGE_BUGREPORT=''
PACKAGE_NAME='Authen::PAM'
PACKAGE_STRING='Authen::PAM 0.16'
PACKAGE_TARNAME='Authen-PAM'
PACKAGE_VERSION='0.16'
PATH_SEPARATOR=':'
SHELL='/bin/sh'
ac_ct_CC='powerpc-wrs-linux-gcc -m32 -mhard-float -mcpu=7400 --sysroot=/home/rpjday/WRL/builds/msm/nov17/bitbake_build/tmp/sysroots/qemuppc'
bindir='${exec_prefix}/bin'
build_alias=''
datadir='${prefix}/share'
exec_prefix='NONE'
host_alias=''
includedir='${prefix}/include'
infodir='${prefix}/info'
libdir='${exec_prefix}/lib'
libexecdir='${exec_prefix}/libexec'
localstatedir='${prefix}/var'
mandir='${prefix}/man'
oldincludedir='/usr/include'
prefix='NONE'
program_transform_name='s,x,x,'
sbindir='${exec_prefix}/sbin'
sharedstatedir='${prefix}/com'
sysconfdir='${prefix}/etc'
target_alias=''
## ----------- ##
## confdefs.h. ##
## ----------- ##
#define PACKAGE_BUGREPORT ""
#define PACKAGE_NAME "Authen::PAM"
#define PACKAGE_STRING "Authen::PAM 0.16"
#define PACKAGE_TARNAME "Authen-PAM"
#define PACKAGE_VERSION "0.16"
configure: exit 1
^ permalink raw reply
* Re: small number of perl modules that can't be cross-compiled
From: André Draszik @ 2016-11-18 13:15 UTC (permalink / raw)
To: Robert P. J. Day; +Cc: OE Core mailing list
In-Reply-To: <alpine.LFD.2.20.1611180742360.16475@localhost.localdomain>
On Fri, 2016-11-18 at 07:46 -0500, Robert P. J. Day wrote:
> On Fri, 18 Nov 2016, André Draszik wrote:
>
> > On Fri, 2016-11-18 at 06:41 -0500, Robert P. J. Day wrote:
> > > after OE recipfying over 100 perl modules from CPAN, i'm down to
> > > less than a dozen that are going to take more work, and a small number
> > > of those seem to be simply badly written in that they don't support
> > > cross-compilation for my target choice of "qemuppc". example
> > > boilerplate recipe i put together produces this:
> > >
> > > $ make libauthen-pam-perl
> > > ... snip ...
> > > Checking if your kit is complete...
> > > Looks good
> > > checking for gcc... powerpc-wrs-linux-gcc -m32 -mhard-float -mcpu=7400
> > > --
> > > sysroot=/home/rpjday/WRL/builds/msm/nov17/bitbake_build/tmp/sysroots/q
> > > emup
> > > pc
> > > checking for C compiler default output file name... a.out
> > > checking whether the C compiler works... configure: error: cannot run
> > > C compiled programs.
> > > If you meant to cross compile, use `--host'.
> > > See `config.log' for more details.
> >
> > It'd be useful to see config.log, ...
>
> see bottom.
That message is referring to config.log from autotools, not the bitbake
do_configure.log. Should be somewhere below ${B}
Cheers,
a.
^ permalink raw reply
* Re: small number of perl modules that can't be cross-compiled
From: Jens Rehsack @ 2016-11-18 13:03 UTC (permalink / raw)
To: André Draszik; +Cc: OE Core mailing list
In-Reply-To: <1479472068.27546.12.camel@andred.net>
[-- Attachment #1: Type: text/plain, Size: 1831 bytes --]
> Am 18.11.2016 um 13:27 schrieb André Draszik <git@andred.net>:
>
> On Fri, 2016-11-18 at 06:41 -0500, Robert P. J. Day wrote:
>> after OE recipfying over 100 perl modules from CPAN, i'm down to
>> less than a dozen that are going to take more work, and a small number
>> of those seem to be simply badly written in that they don't support
>> cross-compilation for my target choice of "qemuppc". example
>> boilerplate recipe i put together produces this:
>>
>> $ make libauthen-pam-perl
>> ... snip ...
>> Checking if your kit is complete...
>> Looks good
>> checking for gcc... powerpc-wrs-linux-gcc -m32 -mhard-float -mcpu=7400
>> --
>> sysroot=/home/rpjday/WRL/builds/msm/nov17/bitbake_build/tmp/sysroots/qemup
>> pc
>> checking for C compiler default output file name... a.out
>> checking whether the C compiler works... configure: error: cannot run
>> C compiled programs.
>> If you meant to cross compile, use `--host'.
>> See `config.log' for more details.
>
> It'd be useful to see config.log, ...
>
>> Error in configuring the Authen::PAM module.
>> ... snip ...
>>
>> so i'm assuming the source itself for Authen::PAM:
>>
>> https://metacpan.org/pod/Authen::PAM
>>
>> is somehow flawed in that it doesn't properly recognize
>> cross-compilation, would that be it?
>
> ... there is at least one issue in Authen-PAM-0.16/configure.ac, I would
> say, in that it tries to detect RTLD_GLOBAL support based on the host's
> perl. So it's likely there are more flaws.
Looks as if Makefile.PL doesn't pass all reasonable flags to ./configure call.
Maybe you should send the Author to http://act.yapc.eu/lpw2016/talk/6966 or
at least send him http://www.netbsd.org/~sno/talks/nrpm/Cross-Compiling-For-Perl-Hackers.pdf :)
Cheers
--
Jens Rehsack - rehsack@gmail.com
[-- Attachment #2: Message signed with OpenPGP using GPGMail --]
[-- Type: application/pgp-signature, Size: 859 bytes --]
^ permalink raw reply
* Re: [PATCH] Test needed to verify postinst script order.
From: Burton, Ross @ 2016-11-18 12:59 UTC (permalink / raw)
To: Pedraza Gonzalez, Francisco J; +Cc: OE-core
In-Reply-To: <475C95148A21B945A7A18605A8298B991028E82D@fmsmsx107.amr.corp.intel.com>
[-- Attachment #1: Type: text/plain, Size: 788 bytes --]
On 17 November 2016 at 18:20, Pedraza Gonzalez, Francisco J <
francisco.j.pedraza.gonzalez@intel.com> wrote:
> Ross: Could you please give more details about PACKAGE_CLASSES?, I am not
> very familiar with.
>
See
http://www.yoctoproject.org/docs/2.2/ref-manual/ref-manual.html#var-PACKAGE_CLASSES
By setting it to "package_rpm package_ipk package_deb" you'll be build
packages for all formats, and then rotating the value so each format is
first when you build an image it will be built with each type of package.
For example:
for classes in ("package_rpm package_deb package_ipk",
"package_deb package_rpm package_ipk",
"package_ipk package_deb package_rpm"):
PACKAGE_CLASSES=classes
bitbake()
qemu()
Ross
[-- Attachment #2: Type: text/html, Size: 1788 bytes --]
^ permalink raw reply
* Re: perl packaging, Makefile.PL versus Build.PL?
From: Jens Rehsack @ 2016-11-18 12:58 UTC (permalink / raw)
To: Robert P. J. Day; +Cc: OE Core mailing list
In-Reply-To: <alpine.LFD.2.20.1611180513530.24565@localhost.localdomain>
[-- Attachment #1: Type: text/plain, Size: 1773 bytes --]
> Am 18.11.2016 um 11:24 schrieb Robert P. J. Day <rpjday@crashcourse.ca>:
>
>
> still going to have a few more questions on the standards for
> packaging perl source into OE recipes, here's the first one.
>
> as i read it, there are two build standards for perl source in OE:
>
> cpan.bbclass: Makefile.PL build-based
> cpan_build.bbclass: (newer) Build.PL build-based
Err: Wrong - Module::Build has been written after ExtUtil::MakeMaker exists,
but it has been removed from Perl core, because ExtUtils::MakeMaker is
much better maintained and has better compatibilities (even if it still
can improved ^^)
> so if one peruses the source at CPAN, it should be obvious which build
> system is relevant, no? so what about source that has *both* those
> files?
>
> https://metacpan.org/pod/Parse::DMIDecode
Look into it: https://metacpan.org/source/NICOLAW/Parse-DMIDecode-0.03/Makefile.PL
shows clearly, that the Makefile.PL is a wrapper for cpan shells which don't
support Build.PL (very old, but when Nicola uploaded it in 2007, 5.8 was bleeding
edge and 5.004 or 5.005 were widely spread.
You can also refer to https://github.com/rehsack/Packager-Utils/blob/master/lib/Packager/Utils/Role/Packages/Bitbake.pm#L507-L517 for some inspiration.
> which has both of those install scripts in the top-level directory,
> although the INSTALL file clearly refers to the newer build system:
>
> perl Build.PL
> perl Build
> perl Build test
> perl Build install
>
> does it make any logical sense for both of those files to be there?
> backward compatibility? any other reason? or am i just wildly
> misunderstanding something?
For some people: yes. For others: No.
Cheers
--
Jens Rehsack - rehsack@gmail.com
[-- Attachment #2: Message signed with OpenPGP using GPGMail --]
[-- Type: application/pgp-signature, Size: 859 bytes --]
^ permalink raw reply
* Re: small number of perl modules that can't be cross-compiled
From: Robert P. J. Day @ 2016-11-18 12:46 UTC (permalink / raw)
To: André Draszik; +Cc: OE Core mailing list
In-Reply-To: <1479472068.27546.12.camel@andred.net>
[-- Attachment #1: Type: text/plain, Size: 4670 bytes --]
On Fri, 18 Nov 2016, André Draszik wrote:
> On Fri, 2016-11-18 at 06:41 -0500, Robert P. J. Day wrote:
> > after OE recipfying over 100 perl modules from CPAN, i'm down to
> > less than a dozen that are going to take more work, and a small number
> > of those seem to be simply badly written in that they don't support
> > cross-compilation for my target choice of "qemuppc". example
> > boilerplate recipe i put together produces this:
> >
> > $ make libauthen-pam-perl
> > ... snip ...
> > Checking if your kit is complete...
> > Looks good
> > checking for gcc... powerpc-wrs-linux-gcc -m32 -mhard-float -mcpu=7400
> > --
> > sysroot=/home/rpjday/WRL/builds/msm/nov17/bitbake_build/tmp/sysroots/qemup
> > pc
> > checking for C compiler default output file name... a.out
> > checking whether the C compiler works... configure: error: cannot run
> > C compiled programs.
> > If you meant to cross compile, use `--host'.
> > See `config.log' for more details.
>
> It'd be useful to see config.log, ...
see bottom.
> > Error in configuring the Authen::PAM module.
> > ... snip ...
> >
> > so i'm assuming the source itself for Authen::PAM:
> >
> > https://metacpan.org/pod/Authen::PAM
> >
> > is somehow flawed in that it doesn't properly recognize
> > cross-compilation, would that be it?
>
> ... there is at least one issue in Authen-PAM-0.16/configure.ac, I would
> say, in that it tries to detect RTLD_GLOBAL support based on the host's
> perl. So it's likely there are more flaws.
that's pretty much all i wanted to confirm at this point -- that it
wasn't something stupid i was doing; rather, the source itself is
flawed, and that's not the only example.
rday
DEBUG: Executing python function sysroot_cleansstate
DEBUG: Python function sysroot_cleansstate finished
DEBUG: Executing shell function do_configure
*** Module name IN: /home/rpjday/WRL/builds/msm/nov17/bitbake_build/tmp/sysroots/qemuppc/usr/lib/perl/5.22.0/Cwd.pm
*** p1: /home/rpjday/WRL/builds/msm/nov17/bitbake_build/tmp/sysroots/qemuppc/usr/lib/ p3: perl/5.22.0/ p5: Cwd.pm
*** Module name OUT: /home/rpjday/WRL/builds/msm/nov17/bitbake_build/tmp/sysroots/x86_64-linux/usr/lib/perl-native/perl/5.22.0/Cwd.pm
*** Module name IN: /home/rpjday/WRL/builds/msm/nov17/bitbake_build/tmp/sysroots/qemuppc/usr/lib/perl/5.22.0/Encode.pm
*** p1: /home/rpjday/WRL/builds/msm/nov17/bitbake_build/tmp/sysroots/qemuppc/usr/lib/ p3: perl/5.22.0/ p5: Encode.pm
*** Module name OUT: /home/rpjday/WRL/builds/msm/nov17/bitbake_build/tmp/sysroots/x86_64-linux/usr/lib/perl-native/perl/5.22.0/Encode.pm
*** Module name IN: /home/rpjday/WRL/builds/msm/nov17/bitbake_build/tmp/sysroots/qemuppc/usr/lib/perl/5.22.0/I18N/Langinfo.pm
*** p1: /home/rpjday/WRL/builds/msm/nov17/bitbake_build/tmp/sysroots/qemuppc/usr/lib/ p3: perl/5.22.0/ p5: I18N/Langinfo.pm
*** Module name OUT: /home/rpjday/WRL/builds/msm/nov17/bitbake_build/tmp/sysroots/x86_64-linux/usr/lib/perl-native/perl/5.22.0/I18N/Langinfo.pm
*** Module name IN: /home/rpjday/WRL/builds/msm/nov17/bitbake_build/tmp/sysroots/qemuppc/usr/lib/perl/5.22.0/B.pm
*** p1: /home/rpjday/WRL/builds/msm/nov17/bitbake_build/tmp/sysroots/qemuppc/usr/lib/ p3: perl/5.22.0/ p5: B.pm
*** Module name OUT: /home/rpjday/WRL/builds/msm/nov17/bitbake_build/tmp/sysroots/x86_64-linux/usr/lib/perl-native/perl/5.22.0/B.pm
*** Module name IN: /home/rpjday/WRL/builds/msm/nov17/bitbake_build/tmp/sysroots/qemuppc/usr/lib/perl/5.22.0/List/Util.pm
*** p1: /home/rpjday/WRL/builds/msm/nov17/bitbake_build/tmp/sysroots/qemuppc/usr/lib/ p3: perl/5.22.0/ p5: List/Util.pm
*** Module name OUT: /home/rpjday/WRL/builds/msm/nov17/bitbake_build/tmp/sysroots/x86_64-linux/usr/lib/perl-native/perl/5.22.0/List/Util.pm
Checking if your kit is complete...
Looks good
checking for gcc... powerpc-wrs-linux-gcc -m32 -mhard-float -mcpu=7400 --sysroot=/home/rpjday/WRL/builds/msm/nov17/bitbake_build/tmp/sysroots/qemuppc
checking for C compiler default output file name... a.out
checking whether the C compiler works... configure: error: cannot run C compiled programs.
If you meant to cross compile, use `--host'.
See `config.log' for more details.
Error in configuring the Authen::PAM module.
WARNING: /home/rpjday/WRL/builds/msm/nov17/bitbake_build/tmp/work/ppc7400-wrs-linux/libauthen-pam-perl/0.16-r0/temp/do_configure/run.do_configure.16119:1 exit 25 from
perl Makefile.PL INSTALLDIRS=vendor
ERROR: Function failed: do_configure (log file is located at /home/rpjday/WRL/builds/msm/nov17/bitbake_build/tmp/work/ppc7400-wrs-linux/libauthen-pam-perl/0.16-r0/temp/do_configure/log.do_configure.16119)
^ permalink raw reply
* Re: [PATCH 1/5] systemd: Upgrade to 232
From: Burton, Ross @ 2016-11-18 12:38 UTC (permalink / raw)
To: Khem Raj; +Cc: OE-core
In-Reply-To: <20161116174748.26994-1-raj.khem@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 760 bytes --]
On 16 November 2016 at 17:47, Khem Raj <raj.khem@gmail.com> wrote:
> * Drop support for rcS.d SysV init scripts.
> These are prone to cause dependency loops, and almost all packages with
> rcS scripts now ship a native systemd service.
>
> * Drop mount propagation patch, it only happens with libseccomp, OE doesnt
> enable it
>
> * kdbus option has disappeared from configure
>
> * Ignore dev-so for PN now since systemd introduced private .so see
> https://github.com/systemd/systemd/issues/3810
>
> Signed-off-by: Khem Raj <raj.khem@gmail.com>
>
Because systemd-boot basically include the systemd recipe, this breaks
systemd-boot.
Can we think up a way to handle systemd/systemd-boot without breaking every
upgrade?
Ross
[-- Attachment #2: Type: text/html, Size: 1494 bytes --]
^ permalink raw reply
* Re: [PATCH] libpcap: Fix build when PACKAGECONFIG ipv6 is not enable
From: Patrick Ohly @ 2016-11-18 12:34 UTC (permalink / raw)
To: Christopher Larson; +Cc: Patches and discussions about the oe-core layer
In-Reply-To: <CABcZANnL5MxwQmiZZ0i8CGHaYxsD9zapNfcyB_a37OoigHq2oA@mail.gmail.com>
On Thu, 2016-11-17 at 09:24 -0700, Christopher Larson wrote:
>
> On Thu, Nov 17, 2016 at 9:21 AM, Fabio Berton
> <fabio.berton@ossystems.com.br> wrote:
> No, I created a patch, git format-patch and then edit
> generated files with Upstream-Status tag and added to recipe.
> Is this wrong?
>
> As I indicated in my first reply, it’s best to put the tag outside the
> generated patch (above it, or below the —-), as it isn’t part of the
> commit, only part of the patch file.
Now I'm confused. My understanding was that
http://www.openembedded.org/wiki/Commit_Patch_Message_Guidelines#Patch_Header_Recommendations explicitly asks for Upstream-Status in the patch header.
Taking an existing example, is
http://cgit.openembedded.org/openembedded-core/tree/meta/recipes-core/systemd/systemd/0001-core-device.c-Change-the-default-device-timeout-to-2.patch doing it wrong?
> It’s minor, and you don’t need to re-submit, but in general the tag
> is not part of the commit message. For example, if your patch was
> applied to a git repository with git-am, it’d be in the commit
> message, which should not be the case.
Yes, that's indeed the effect. That has pros (the Upstream-Status tag is
preserved when working with devtool) and cons (patch as attached to a
recipe is not the same as the patch upstream).
--
Best Regards, Patrick Ohly
The content of this message is my personal opinion only and although
I am an employee of Intel, the statements I make here in no way
represent Intel's position on the issue, nor am I authorized to speak
on behalf of Intel on this matter.
^ permalink raw reply
* Re: small number of perl modules that can't be cross-compiled
From: André Draszik @ 2016-11-18 12:27 UTC (permalink / raw)
To: Robert P. J. Day, OE Core mailing list
In-Reply-To: <alpine.LFD.2.20.1611180634400.3556@localhost.localdomain>
On Fri, 2016-11-18 at 06:41 -0500, Robert P. J. Day wrote:
> after OE recipfying over 100 perl modules from CPAN, i'm down to
> less than a dozen that are going to take more work, and a small number
> of those seem to be simply badly written in that they don't support
> cross-compilation for my target choice of "qemuppc". example
> boilerplate recipe i put together produces this:
>
> $ make libauthen-pam-perl
> ... snip ...
> Checking if your kit is complete...
> Looks good
> checking for gcc... powerpc-wrs-linux-gcc -m32 -mhard-float -mcpu=7400
> --
> sysroot=/home/rpjday/WRL/builds/msm/nov17/bitbake_build/tmp/sysroots/qemup
> pc
> checking for C compiler default output file name... a.out
> checking whether the C compiler works... configure: error: cannot run
> C compiled programs.
> If you meant to cross compile, use `--host'.
> See `config.log' for more details.
It'd be useful to see config.log, ...
> Error in configuring the Authen::PAM module.
> ... snip ...
>
> so i'm assuming the source itself for Authen::PAM:
>
> https://metacpan.org/pod/Authen::PAM
>
> is somehow flawed in that it doesn't properly recognize
> cross-compilation, would that be it?
... there is at least one issue in Authen-PAM-0.16/configure.ac, I would
say, in that it tries to detect RTLD_GLOBAL support based on the host's
perl. So it's likely there are more flaws.
A.
^ permalink raw reply
* small number of perl modules that can't be cross-compiled
From: Robert P. J. Day @ 2016-11-18 11:41 UTC (permalink / raw)
To: OE Core mailing list
after OE recipfying over 100 perl modules from CPAN, i'm down to
less than a dozen that are going to take more work, and a small number
of those seem to be simply badly written in that they don't support
cross-compilation for my target choice of "qemuppc". example
boilerplate recipe i put together produces this:
$ make libauthen-pam-perl
... snip ...
Checking if your kit is complete...
Looks good
checking for gcc... powerpc-wrs-linux-gcc -m32 -mhard-float -mcpu=7400
--sysroot=/home/rpjday/WRL/builds/msm/nov17/bitbake_build/tmp/sysroots/qemuppc
checking for C compiler default output file name... a.out
checking whether the C compiler works... configure: error: cannot run
C compiled programs.
If you meant to cross compile, use `--host'.
See `config.log' for more details.
Error in configuring the Authen::PAM module.
... snip ...
so i'm assuming the source itself for Authen::PAM:
https://metacpan.org/pod/Authen::PAM
is somehow flawed in that it doesn't properly recognize
cross-compilation, would that be it?
i'm about to peruse the build process, but if someone has a quick
answer as to what the issue is here, there are 2 or 3 other modules
that have exactly the same issue. much thanks.
rday
--
========================================================================
Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca
Twitter: http://twitter.com/rpjday
LinkedIn: http://ca.linkedin.com/in/rpjday
========================================================================
^ permalink raw reply
* perl packaging, Makefile.PL versus Build.PL?
From: Robert P. J. Day @ 2016-11-18 10:24 UTC (permalink / raw)
To: OE Core mailing list
still going to have a few more questions on the standards for
packaging perl source into OE recipes, here's the first one.
as i read it, there are two build standards for perl source in OE:
cpan.bbclass: Makefile.PL build-based
cpan_build.bbclass: (newer) Build.PL build-based
so if one peruses the source at CPAN, it should be obvious which build
system is relevant, no? so what about source that has *both* those
files?
https://metacpan.org/pod/Parse::DMIDecode
which has both of those install scripts in the top-level directory,
although the INSTALL file clearly refers to the newer build system:
perl Build.PL
perl Build
perl Build test
perl Build install
does it make any logical sense for both of those files to be there?
backward compatibility? any other reason? or am i just wildly
misunderstanding something?
rday
--
========================================================================
Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca
Twitter: http://twitter.com/rpjday
LinkedIn: http://ca.linkedin.com/in/rpjday
========================================================================
^ permalink raw reply
* Re: [Openembedded-architecture] Enabling uninative by default in oe-core?
From: Richard Purdie @ 2016-11-18 8:03 UTC (permalink / raw)
To: Koen Kooi, Burton, Ross; +Cc: openembedded-architecture, OE-core
In-Reply-To: <AA4AB54F-B782-4CFC-9E77-512EAFE73399@dominion.thruhere.net>
On Fri, 2016-11-18 at 08:15 +0100, Koen Kooi wrote:
> >
> > Op 17 nov. 2016, om 18:31 heeft Burton, Ross <ross.burton@intel.com
> > > het volgende geschreven:
> >
> > Hi,
> >
> > Background: uninative is a class that downloads a precompiled host
> > glibc
> Why can’t OE build it on-demand? What’s next, requiring prebuilt
> toolchains?
Its a chicken and egg problem.
We could add a special "uninativesdk" BBCLASSEXTEND range of targets,
then require that it built before we build anything native (or anything
that needs a native tool). This would push build times up 'a little'
and I suspect might not be popular. So the reason we "can't" is that
its impractical, not an absolute technical constraint.
Cheers,
Richard
^ permalink raw reply
* [PATCH][krogoth] Qemu: net: CVE-2016-4001
From: Sona Sarmadi @ 2016-11-18 7:51 UTC (permalink / raw)
To: openembedded-core
buffer overflow in stellaris_enet emulator
Reference to upstream patch:
http://git.qemu.org/?p=qemu.git;a=patch;h=3a15cc0e1ee7168db0782133d2607a6bfa422d66
Reference:
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2016-4001
Signed-off-by: Sona Sarmadi <sona.sarmadi@enea.com>
---
.../recipes-devtools/qemu/qemu/CVE-2016-4001.patch | 51 ++++++++++++++++++++++
meta/recipes-devtools/qemu/qemu_2.5.0.bb | 1 +
2 files changed, 52 insertions(+)
create mode 100644 meta/recipes-devtools/qemu/qemu/CVE-2016-4001.patch
diff --git a/meta/recipes-devtools/qemu/qemu/CVE-2016-4001.patch b/meta/recipes-devtools/qemu/qemu/CVE-2016-4001.patch
new file mode 100644
index 0000000..cfec8b8
--- /dev/null
+++ b/meta/recipes-devtools/qemu/qemu/CVE-2016-4001.patch
@@ -0,0 +1,51 @@
+From 3a15cc0e1ee7168db0782133d2607a6bfa422d66 Mon Sep 17 00:00:00 2001
+From: Prasad J Pandit <pjp@fedoraproject.org>
+Date: Fri, 8 Apr 2016 11:33:48 +0530
+Subject: [PATCH] net: stellaris_enet: check packet length against receive
+ buffer
+
+When receiving packets over Stellaris ethernet controller, it
+uses receive buffer of size 2048 bytes. In case the controller
+accepts large(MTU) packets, it could lead to memory corruption.
+Add check to avoid it.
+
+CVE: CVE-2016-4001
+Upstream-Status: Backport
+
+Reported-by: Oleksandr Bazhaniuk <oleksandr.bazhaniuk@intel.com>
+Signed-off-by: Prasad J Pandit <pjp@fedoraproject.org>
+Message-id: 1460095428-22698-1-git-send-email-ppandit@redhat.com
+Reviewed-by: Peter Maydell <peter.maydell@linaro.org>
+Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
+Signed-off-by: Sona Sarmadi <sona.sarmadi@enea.com>
+---
+ hw/net/stellaris_enet.c | 12 +++++++++++-
+ 1 file changed, 11 insertions(+), 1 deletion(-)
+
+diff --git a/hw/net/stellaris_enet.c b/hw/net/stellaris_enet.c
+index 84cf60b..6880894 100644
+--- a/hw/net/stellaris_enet.c
++++ b/hw/net/stellaris_enet.c
+@@ -236,8 +236,18 @@ static ssize_t stellaris_enet_receive(NetClientState *nc, const uint8_t *buf, si
+ n = s->next_packet + s->np;
+ if (n >= 31)
+ n -= 31;
+- s->np++;
+
++ if (size >= sizeof(s->rx[n].data) - 6) {
++ /* If the packet won't fit into the
++ * emulated 2K RAM, this is reported
++ * as a FIFO overrun error.
++ */
++ s->ris |= SE_INT_FOV;
++ stellaris_enet_update(s);
++ return -1;
++ }
++
++ s->np++;
+ s->rx[n].len = size + 6;
+ p = s->rx[n].data;
+ *(p++) = (size + 6);
+--
+1.9.1
+
diff --git a/meta/recipes-devtools/qemu/qemu_2.5.0.bb b/meta/recipes-devtools/qemu/qemu_2.5.0.bb
index b965f69..6823b62 100644
--- a/meta/recipes-devtools/qemu/qemu_2.5.0.bb
+++ b/meta/recipes-devtools/qemu/qemu_2.5.0.bb
@@ -28,6 +28,7 @@ SRC_URI += "file://configure-fix-Darwin-target-detection.patch \
file://CVE-2016-5403.patch \
file://CVE-2016-4441.patch \
file://CVE-2016-4952.patch \
+ file://CVE-2016-4001.patch \
"
SRC_URI_prepend = "http://wiki.qemu-project.org/download/${BP}.tar.bz2"
SRC_URI[md5sum] = "f469f2330bbe76e3e39db10e9ac4f8db"
--
1.9.1
^ permalink raw reply related
* Re: Modifying SRC_URI from anonymous python
From: Patrick Ohly @ 2016-11-18 7:44 UTC (permalink / raw)
To: Andre McCurdy; +Cc: OE Core mailing list
In-Reply-To: <CAJ86T=U8RB13J_we2bte22bFQKwnahCe3v5L6na9SDPKm6O8bA@mail.gmail.com>
On Thu, 2016-11-17 at 13:28 -0800, Andre McCurdy wrote:
> I have a supplier who provides recipes which set SRC_URI to their
> private git servers. To make those same recipes usable by others (ie
> me), some anonymous python is used to transform the default SRC_URI
> (elements which contain private git URLs are replaced, patches and
> other files are left as-is).
>
> This apparently worked in OE 2.0 but from 2.1 onwards the anonymous
> python which modifies SRC_URI races with the anonymous python in
> base.bbclass which parses SRC_URI to determine additional
> do_fetch/do_unpack dependencies and whether or not to call
> fetch2.get_srcrev().
I have a patch which I intend to submit to bitbake which adds priorities
for anonymous python methods:
https://github.com/pohly/poky/commit/9d959e50e5f27d149654f5db0aff2fe51365ad68
With that in place, the anonymous python method which transforms the
SRC_URI could request to run sooner than the base.bbclass anonymous
python.
However, I am not sure whether that should be backported to 2.1 and 2.2.
> Specifically I get failures because
> fetch2.get_srcrev() sees the original SRC_URI and tries to resolve
> AUTOREV from a repo to which I don't have access.
>
> The proposed solution from the supplier is this patch to base.bbclass:
>
> @@ -598,7 +598,7 @@ python () {
> d.appendVarFlag('do_unpack', 'depends', '
> file-native:do_populate_sysroot')
>
> if needsrcrev:
> - d.setVar("SRCPV", "${@bb.fetch2.get_srcrev(d)}")
> + d.setVar("SRCPV", "${@bb.fetch2.get_srcrev(d)}", parsing=True)
>
> set_packagetriplet(d)
>
> After reading the setVar source I'm not very clear how or why this
> works, but it looks dubious. What is parsing=True intended to do?
>
> Is it documented somewhere that modifying SRC_URI from anonymous
> python isn't allowed? I've now seen two suppliers both independently
> run into the same problem when updating to OE 2.1.
Sorry, I don't know about that.
--
Best Regards, Patrick Ohly
The content of this message is my personal opinion only and although
I am an employee of Intel, the statements I make here in no way
represent Intel's position on the issue, nor am I authorized to speak
on behalf of Intel on this matter.
^ permalink raw reply
* Re: Enabling uninative by default in oe-core?
From: Koen Kooi @ 2016-11-18 7:15 UTC (permalink / raw)
To: Burton, Ross; +Cc: openembedded-architecture, OE-core
In-Reply-To: <CAJTo0LbvGwRpzxfOL0505w+Vz=Jhf6O3QOr5Z8SX9XaFqaZ7eg@mail.gmail.com>
> Op 17 nov. 2016, om 18:31 heeft Burton, Ross <ross.burton@intel.com> het volgende geschreven:
>
> Hi,
>
> Background: uninative is a class that downloads a precompiled host glibc
Why can’t OE build it on-demand? What’s next, requiring prebuilt toolchains?
regards,
Koen
^ permalink raw reply
* Re: Modifying SRC_URI from anonymous python
From: Andre McCurdy @ 2016-11-18 3:31 UTC (permalink / raw)
To: Christopher Larson; +Cc: OE Core mailing list
In-Reply-To: <CABcZANmfZSGZsFFcXvSAhTgPBPvoQm=wx=p9Q7sPgSSn3D4mAg@mail.gmail.com>
On Thu, Nov 17, 2016 at 2:00 PM, Christopher Larson <clarson@kergoth.com> wrote:
>
> On Thu, Nov 17, 2016 at 2:28 PM, Andre McCurdy <armccurdy@gmail.com> wrote:
>>
>> I have a supplier who provides recipes which set SRC_URI to their
>> private git servers. To make those same recipes usable by others (ie
>> me), some anonymous python is used to transform the default SRC_URI
>> (elements which contain private git URLs are replaced, patches and
>> other files are left as-is).
>>
>> This apparently worked in OE 2.0 but from 2.1 onwards the anonymous
>> python which modifies SRC_URI races with the anonymous python in
>> base.bbclass which parses SRC_URI to determine additional
>> do_fetch/do_unpack dependencies and whether or not to call
>> fetch2.get_srcrev(). Specifically I get failures because
>> fetch2.get_srcrev() sees the original SRC_URI and tries to resolve
>> AUTOREV from a repo to which I don't have access.
>
> You might want to try using a RecipePreFinalise event handler instead, they
> run before anonymous python functions do.
Thanks, that works.
(For the benefit of anyone else who may try copying and pasting the
example from the bitbake user manual, the correct eventmask is
"bb.event.RecipePreFinalise" rather than
"bb.build.RecipePreFinalise").
> --
> Christopher Larson
> clarson at kergoth dot com
> Founder - BitBake, OpenEmbedded, OpenZaurus
> Maintainer - Tslib
> Senior Software Engineer, Mentor Graphics
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox