Re: [OE-core] [PATCH] avahi: add ptest

On Thu, 8 Nov 2018 at 09:44, Stefan Strogin via Openembedded-core wrote: > +do_install_ptest () { > +install -d ${D}${PTEST_PATH}/test/.libs > +for t in dns-spin-test dns-test hashmap-test > +do > +install -m 0755 ${B}/avahi-core/$t ${D}${PTEST_PATH}/test/ > +sed -e

Re: [OE-core] [PATCH 2/7] python3: add tk support

On Fri, 9 Nov 2018 at 01:39, Yu, Mingli wrote: > > Why is this here and not in the manifest? > > It's because we can optionally enable or disable tk via PACKAGECONFIG, > if add it to manifest then we need to always enable tk which is also the > implement in v1. Are you sure? As I understand it

Re: [OE-core] [PATCH] util-linux: make alternatives for rev and ionice work with busybox

On Thu, 8 Nov 2018 at 10:58, Pascal Bach wrote: > Busybox can provide ionice and rev. They are both installed to /bin > The corresponding util-linux variant is installed to /usr/bin > > This causes the following error during the do_rootfs task: > > > update-alternatives: renaming ionice link from

Re: [OE-core] [PATCH] pseudo: fix link with new sqlite3

On Thu, 8 Nov 2018 at 14:53, Jens Rehsack wrote: > I digged a bit deeper (since I'd like to get a reasonable solution even for > other dependent components) and would say, pseudo will also fail, when > sqlite3 is build using readline or libz. > The better option will be to let pseudo use the

Re: [OE-core] [PATCH] valgrind: drop mips n32 support

On Wed, 7 Nov 2018 at 18:00, Randy MacLeod wrote: > valgrind for qemumips64 multilib builds fails to configure > for libn32 with the error: >configure:6190: checking for 32 bit build support >... >fatal error: bits/long-double-32.h: No such file or directory > It seems that the

Re: [OE-core] [PATCH 2/7] python3: add tk support

On Thu, 8 Nov 2018 at 06:09, wrote: > +if "tkinter" in pypackage and "tk" in pkgconfig: > +d.appendVar('FILES_' + pypackage, ' ' + > "${libdir}/python${PYTHON_MAJMIN}/lib-dynload/_tkinter*.so") > +if "tkinter" in pypackage and "tk" in pkgconfig: > +

Re: [OE-core] [PATCH v2] ghostscript: Define COMPATIBLE_HOST with supported platforms

On Thu, 8 Nov 2018 at 13:30, Khem Raj wrote: > > --- a/meta/recipes-extended/ghostscript/ghostscript_9.25.bb > > +++ b/meta/recipes-extended/ghostscript/ghostscript_9.25.bb > > @@ -121,5 +121,4 @@ do_install_class-native () { > > > > BBCLASSEXTEND = "native" > > > > -# ghostscript does not

Re: [OE-core] [PATCH] Fix header files to compile libgpg-error-native on ppc64le Power8 build machine

The identical patch by Serhey Popovych is queued for master right now. Ross On Wed, 7 Nov 2018 at 15:57, Guillermo Amat wrote: > > Using a ppc64le build machine the following error occurs when compiling > libjpg-error-native > > cp: cannot stat >

Re: [OE-core] [PATCH] glib-2.0: add missing locale dependencies to PN-ptest

Sounds about right. Not sure what would count as a solution here? Ross On Wed, 7 Nov 2018 at 12:40, Mauno Niko wrote: > > On 10/09/2018 02:00 PM, Ross Burton wrote: > > The test suite skips several tests if the required locales are not found, > > so add > > them as dependencies of

Re: [OE-core] [PATCHv2] glibc: make ld-2.28.so reproducible on arm

On Wed, 7 Nov 2018 at 07:41, Martin Hundebøll wrote: > > Please add Upsteam-Status: and Signed-off-by: in the patch itself. > > It was Richard's patch, so I chose the less intrusive approach. I can do > a refresh of the entire patch? There's nothing to do, as you're extending an existing patch.

Re: [OE-core] [PATCH] sqlite3_3: Update to 3.25.2

On Mon, 5 Nov 2018 at 16:11, Burton, Ross wrote: > On Mon, 5 Nov 2018 at 11:43, Burton, Ross wrote: > > Mining the list archive shows that we keep on getting sqlite upgrades > > which fail like this. Maxin reported that it was due to the > > full-text-search code enabli

Re: [OE-core] [PATCH] sqlite3_3: Update to 3.25.2

On Mon, 5 Nov 2018 at 11:43, Burton, Ross wrote: > Mining the list archive shows that we keep on getting sqlite upgrades > which fail like this. Maxin reported that it was due to the > full-text-search code enabling itself and failing to build, so one > solution is to explicitly

Re: [OE-core] [PATCH] sqlite3_3: Update to 3.25.2

Mining the list archive shows that we keep on getting sqlite upgrades which fail like this. Maxin reported that it was due to the full-text-search code enabling itself and failing to build, so one solution is to explicitly turn it off. Ross On Mon, 5 Nov 2018 at 11:39, Richard Purdie wrote: > >

Re: [OE-core] [PATCH v8] python3{,-native}: update to 3.7.0

On Fri, 2 Nov 2018 at 16:29, Burton, Ross wrote: > > Turns out enabling reproducible builds breaks the test suite: > > > > test test_py_compile failed -- Traceback (most recent call last): > > File "/usr/lib/python3.7/test/test_py_compile.py", line

Re: [OE-core] [PATCH v8] python3{,-native}: update to 3.7.0

Oh, and we should either backport https://github.com/python/cpython/commit/7bd6f0e5500f778e940374237b94651f60ae1990 or move to 3.7.1. Ross On Fri, 2 Nov 2018 at 16:29, Burton, Ross wrote: > > On Fri, 2 Nov 2018 at 16:17, Burton, Ross wrote: > > Turns out enabling reproducible b

Re: [OE-core] [PATCH v8] python3{,-native}: update to 3.7.0

On Fri, 2 Nov 2018 at 16:17, Burton, Ross wrote: > Turns out enabling reproducible builds breaks the test suite: > > test test_py_compile failed -- Traceback (most recent call last): > File "/usr/lib/python3.7/test/test_py_compile.py", line 125, in &g

Re: [OE-core] [PATCH v8] python3{,-native}: update to 3.7.0

On Fri, 2 Nov 2018 at 16:09, Burton, Ross wrote: > I'm currently running the regression tests so will report back if > anything fails. Turns out enabling reproducible builds breaks the test suite: test test_py_compile failed -- Traceback (most recent call last): File "/usr/lib/pyt

Re: [OE-core] [PATCH v8] python3{,-native}: update to 3.7.0

On Fri, 2 Nov 2018 at 16:05, Jens Rehsack wrote: > > > > Am 02.11.2018 um 16:57 schrieb Burton, Ross : > > It appears that Python 3.6 or 3.7 removed os.errno as an alias for > errno, as this is failing in wic: > > | File "/home/ross/Yocto/poky/scrip

Re: [OE-core] [PATCH] xserver-xorg: fix for CVE-2018-14665

On Fri, 2 Nov 2018 at 16:02, akuster808 wrote: > This should be in the update sitting in master-next. its good for Thud > or we update thud to the later version Thud is literally in QA for release, so it's way too late for an update. The CVE patch should be backported for thud, sumo, rocko.

Re: [OE-core] [PATCH v8] python3{,-native}: update to 3.7.0

It appears that Python 3.6 or 3.7 removed os.errno as an alias for errno, as this is failing in wic: | File "/home/ross/Yocto/poky/scripts/lib/wic/filemap.py", line 397, in _invoke_fiemap | if err.errno == os.errno.EOPNOTSUPP: | AttributeError: module 'os' has no attribute 'errno' Easily

Re: [OE-core] [[PATCH] libgpg-error: Support build for native on ppc64/ppc64le hosts

On Thu, 1 Nov 2018 at 16:35, Serhey Popovych wrote: > + ppc64*) TUPLE=powerpc${TARGET_ARCH#ppc}-unknown-linux-gnu ;; I agree with Khem: clever, but explicit wins here. Ross -- ___ Openembedded-core mailing list

Re: [OE-core] [PATCH] apt: update SRC_URI

Why are we using ubuntu's archive instead of the canonical Debian repository? The idiom for Debian packages is to use snapshot.debian.org. Ross On Thu, 1 Nov 2018 at 03:16, wrote: > > From: Changqing Li > > update SRC_URI since previous link is not valid now > > Signed-off-by: Changqing Li >

Re: [OE-core] [PATCH v2] python3: Fix python3-pyvenv run-time dependency

On Tue, 30 Oct 2018 at 17:23, Hugues Kamba wrote: > I am still new to Yocto but my understanding of adding pyvenv to venv's > RPROVIDES is that python3-pyvenv is available (albeit as an alias of > python3-venv). > I therefore have not removed the possibility for one to choose to include the >

Re: [OE-core] [PATCH] mtd-utils: Update SRC_URI

It's back now. Ross On Tue, 30 Oct 2018 at 12:13, Burton, Ross wrote: > > The machine is only down temporarily and should be back soon. I don't > think we should merge this as we'll be reverting shortly. > > Ross > On Tue, 30 Oct 2018 at 07:53, wrote: >

Re: [OE-core] [PATCH v2] python3: Fix python3-pyvenv run-time dependency

On Tue, 30 Oct 2018 at 16:13, Hugues Kamba wrote: > I am not sure where you saw the commit message say that pyvenv has been > removed. The python3-pyvenv package is literally being removed: packages/corei7-64-poky-linux/python3: PACKAGES: removed "python3-pyvenv", added "python3-venv" Ross --

Re: [OE-core] [PATCH v2] python3: Fix python3-pyvenv run-time dependency

Patch looks good, but the commit message contradicts itself a few times. python3-pyvenv is removed, but: " This patch adds the python3-venv module as a self-contained package which python3-pyvenv must depend on at run-time." This patch specifies the newly created python3-venv as a

Re: [OE-core] [PATCH] mtd-utils: Update SRC_URI

The machine is only down temporarily and should be back soon. I don't think we should merge this as we'll be reverting shortly. Ross On Tue, 30 Oct 2018 at 07:53, wrote: > > From: Mingli Yu > > The official repo for mtd-utils is git://git.infradead.org/mtd-utils.git, > however there comes

Re: [OE-core] [oe-core][PATCH 0/2] python: add tk support

On Tue, 30 Oct 2018 at 04:53, Randy MacLeod wrote: > I think what started us down this path is a FACE [1] compliance test. > If there's resistance to moving the package to oe-core, can we > enable python-tk even if tk stayed in meta-oe, Grace? > Also, this should be done using using

Re: [OE-core] [PATCH] libxcrypt: tweak branch from master to develop

Note that release branches also need updating. CC Armin. Ross On Mon, 29 Oct 2018 at 06:22, Hongxu Jia wrote: > > The master branch does not exist any more, use develop to replace. > > Signed-off-by: Hongxu Jia > --- > meta/recipes-core/libxcrypt/libxcrypt_4.1.1.bb | 2 +- > 1 file changed, 1

Re: [OE-core] [PATCH] python3: Fix python3-pyvenv run-time dependency

If pyvenv is going to disappear, would it be neater to just put all the files into PN-venv and have that RPROVIDE python-pyven for now? Ross On Wed, 24 Oct 2018 at 02:19, Hugues Kamba wrote: > > Pyvenv is just a small script that uses venv to create virtual > environments. >

Re: [OE-core] [oe-core][PATCH 0/2] python: add tk support

Terrified to ask, but why? On Thu, 25 Oct 2018 at 09:39, wrote: > > 1, move tk recipe from meta-oe > 2, enable tk to add tk support > -- > ___ > Openembedded-core mailing list > Openembedded-core@lists.openembedded.org >

Re: [OE-core] [PATCH 1/2] go: Upgrade to 1.11.1

Are you proposing this as a freeze-breaking change to Thud, or sending early for master? Ross On Fri, 19 Oct 2018 at 02:32, Khem Raj wrote: > > Drop 1.10 recipes in favor of 1.11 > we have had reports of 1.10 not being quite > functional wth OE > > Signed-off-by: Khem Raj > --- >

Re: [OE-core] [PATCH 3/4] weston: Remove machine specific append

On Thu, 18 Oct 2018 at 16:39, Mark Hatle wrote: > > Two questions: > > 1) does qemu still need fbdev or does virtio/drm work now? (iirc, we > > still have a crippled qemu here) > > 2) Can this be overridden in a config file instead > > I did not understand how to do this. The alternative I see

Re: [OE-core] [PATCH v4 2/4] cmake.bbclass: search both sysroot-native and host for native packages

On Thu, 18 Oct 2018 at 16:05, Pascal Bach wrote: > > My suspicion is that for systems where the host has python3-devel > > installed, libcomp-native's cmake is using the host python instead of > > the native python in the sysroot. I'm not sure yet if BOTH means it > > searches the host before

Re: [OE-core] Missing venv module in Python 3

On Thu, 18 Oct 2018 at 16:19, Jonathan Haigh wrote: > The venv package (https://docs.python.org/3/library/venv.html) itself is > missing although its source is available within Python 3.5 > (https://www.python.org/ftp/python/3.5.6/Python-3.5.6.tgz). As mentioned > earlier, it seems the issue

Re: [OE-core] Missing venv module in Python 3

venv is packaged in python3-pyvenv. Patches welcome to get that installed out of the box. Ross On Thu, 18 Oct 2018 at 14:35, Jonathan Haigh wrote: > > Hello, > > I have noticed that the venv module is not available with Python 3 in Yocto. > This is possibly because there is no entry for it in

Re: [OE-core] [PATCH 3/4] weston: Remove machine specific append

On Wed, 17 Oct 2018 at 17:44, Mark Hatle wrote: > -EXTRA_OECONF_append_qemux86 = "\ > +EXTRA_OECONF_append_x86 = "\ > WESTON_NATIVE_BACKEND=fbdev-backend.so \ > " This forces all x86 Westons that are not running inside X11 to use fbdev instead of drm. Two

Re: [OE-core] [PATCH 1/4] util-linux: alternatify cal, rev, and ionice

Can you rebase this on master? There's been a lot of changes here recently. Ross On Wed, 17 Oct 2018 at 22:22, Dan McGregor wrote: > > From: Dan McGregor > > These are also provided by toybox in its default configuration, > and can be turned on in busybox. > > Signed-off-by: Dan McGregor >

Re: [OE-core] [PATCH] boost.inc: make libboost_python3.so available

On Thu, 18 Oct 2018 at 03:29, Yu, Mingli wrote: > Many thanks for Ross's clarification! > If we need to fix the packages one by one, but not add the hack at boost > side, then https://bugzilla.yoctoproject.org/show_bug.cgi?id=12833 > should be invalid. Agreed, done! Ross --

Re: [OE-core] [PATCH v4 2/4] cmake.bbclass: search both sysroot-native and host for native packages

I think I figured out why we're seeing odd failures on the autobuilder, such as https://autobuilder.yoctoproject.org/typhoon/#/builders/15/builds/125. The important bit of the log is: File

Re: [OE-core] [PATCH] boost.inc: make libboost_python3.so available

On Wed, 17 Oct 2018 at 06:48, Yu, Mingli wrote: > I'm fine not add the the hack fix from boost side, but as I know there > is another package camera-calibration-parsers which has the same problem > as below apart from cv-bridge. BTW, there may some other package also > has this kind of problem.

Re: [OE-core] [PATCH] boost.inc: make libboost_python3.so available

On Tue, 16 Oct 2018 at 12:18, Burton, Ross wrote: > OpenCV has a patch to "fix" (bodge) the Py2 build: > > https://github.com/ros-perception/vision_opencv/pull/239 > > But this doesn't work for Py3. This was just pushed: https://github.com/ros-perception/vision_op

Re: [OE-core] [PATCH] freetype: remove compile of windows resource files

On Tue, 16 Oct 2018 at 04:36, Changqing Li wrote: > do_compile failed with below error: > x86_64-wrs-linux-libtool: compile: x86_64-wrs-linux-windres > --include-dir=work/corei7-64-wrs-linux/freetype/2.9.1-r0/recipe-sysroot/usr/include >

Re: [OE-core] [PATCH] boost.inc: make libboost_python3.so available

instead of "python3", although this will break when we upgrade to Python 3. A better solution would be to upstream a patch that uses the Python version to generate the correct name. Ross On Tue, 16 Oct 2018 at 11:38, Burton, Ross wrote: > > On Tue, 16 Oct 2018 at 11:01, wrote: >

Re: [OE-core] [PATCH] boost.inc: make libboost_python3.so available

On Tue, 16 Oct 2018 at 11:01, wrote: > I'm a little worried about why we're having to create these links when > other software seems able to expect these things by default. Is this > some standard packaging most distros do? I'm a little worried we're > creating an ABI here which doesn't exist...

Re: [OE-core] [PATCH] systemtap: 3.3 -> 4.0

On Mon, 15 Oct 2018 at 19:22, Victor Kamensky wrote: > Upgrade systemtap from 3.3 to 4.0: Removed backported patch. WARNING: systemtap-4.0-r0 do_package_qa: QA Issue: systemtap: /systemtap/etc/stap-exporter/EXAMPLE is owned by uid 1000, which is the same as the user running bitbake. This may be

Re: [OE-core] [PATCH] freetype: remove compile of windows resource files

Is this breaking the build of Freetype for mingw32? Seems like it would be easier change meta-mingw to just export RC in the SDK environment using overrides. Ross On Mon, 15 Oct 2018 at 06:32, wrote: > > From: Changqing Li > > remove compile of windows resource file to fix compile > fail

Re: [OE-core] Why openembedded-core mailing list is now author of some patches?

On Fri, 12 Oct 2018 at 15:03, Ruslan Bilovol wrote: > > This is basically due to SPF, and people sending email from > > non-authoritive hosts. Concrete example: Richard Purdie's mail comes > > from a machine which the linuxfoundation.org SPF records doesn't > > recognise as an authorised sender.

Re: [OE-core] Why openembedded-core mailing list is now author of some patches?

Ironically, this mail is From: Ruslan Bilovol via Openembedded-core. This is basically due to SPF, and people sending email from non-authoritive hosts. Concrete example: Richard Purdie's mail comes from a machine which the linuxfoundation.org SPF records doesn't recognise as an authorised

Re: [OE-core] [PATCH] attr: fix utime for symlink

Please change the shortlog to say that the patch is to unfs3 and not attr. Ross On Fri, 12 Oct 2018 at 04:10, Rui Wang wrote: > > Signed-off-by: Rui Wang > > cherry-pick of fa191666b with context for SRC_URI addition > modified to apply to current recipe. > > Signed-off-by: Joe Slater > --- >

Re: [OE-core] [PATCH 1/3] gobject-introspection: add required python modules to rdepends

On Wed, 10 Oct 2018 at 16:48, wrote: > +RDEPENDS_${PN}_class-target = "python3-pickle python3-xml" I'm pretty sure this idiom isn't right anymore: 1) python3-native has the right PROVIDES so e.g. python3-pickle-native exists 2) the RDEPENDS are needed if you build nativesdk-gobject-introspection

Re: [OE-core] [oe-commits] [openembedded-core] 02/09: glib-2.0: add missing locale dependencies to PN-ptest

On Thu, 11 Oct 2018 at 07:38, Martin Jansa wrote: > This is causing a lot of QA errors like: > > lib32-glib-2.0-2.58.0: lib32-glib-2.0-ptest rdepends on > lib32-locale-base-ru-ru, but it isn't a build dependency? [build-deps] > lib32-glib-2.0-2.58.0: lib32-glib-2.0-ptest rdepends on >

Re: [OE-core] [PATCHv3 1/4] cmake.bbclass: use CMAKE_SYSTEM_LIBRARY_PATH instead of CMAKE_LIBRARY_PATH

On Wed, 10 Oct 2018 at 15:12, Pascal Bach wrote: > The problem is "cmake.bbclass: allow cmake to find hosttools" it has the > side effect of making all hosttools available to all recipes. > In the case of libproxy this leads to it finding python, which is included > in hosttools, and thus

Re: [OE-core] [PATCH] cmake.bbclass: search both sysroot-native and host for native packages

All but this one apply now... weird. If you can rebase on top of poky-contrib:ross/thud then that would be great. Ross On Tue, 9 Oct 2018 at 15:07, Pascal Bach wrote: > Certain headers and libraries like `math.h` an `-m` are only available on > the > host as they are provided by the host

Re: [OE-core] [PATCH] cmake.bbclass: allow cmake to find hosttools

The hashes don't match anything public and git isn't happy: Applying: cmake.bbclass: allow cmake to find hosttools error: sha1 information is lacking or useless (meta/classes/cmake.bbclass). error: could not build fake ancestor Patch failed at 0001 cmake.bbclass: allow cmake to find hosttools

Re: [OE-core] [PATCH v2 1/3] busybox: fix conflict with runlevel applet

Don't you want to delete runlevel here too? Ross On Tue, 9 Oct 2018 at 08:45, Andrej Valek wrote: > - remove OE runlevel script which conflicts with busybox's applet > - don't install empty directories > > Signed-off-by: Andrej Valek > --- > meta/recipes-core/busybox/busybox.inc | 4

Re: [OE-core] [PATCH] Support for changing the imager used in wic.

That's one messed up patch: can you resend using git-send-email please? Ross On Mon, 8 Oct 2018 at 14:59, Davis, Michael wrote: > >*From 136d6214b6fc2c1118dac5b7f3e029ed006fab8a Mon Sep 17 00:00:00 2001* > > From: Paul Knopf > > > Date: Mon, 21

Re: [OE-core] [PATCH] busybox: fix conflict with runlevel applet

On Thu, 4 Oct 2018 at 12:28, Martin Jansa wrote: > On Thu, Oct 04, 2018 at 12:59:37PM +0200, Andrej Valek wrote: > > This init feature was introduced via > > > http://lists.openembedded.org/pipermail/openembedded-core/2016-January/116109.html > > which is from 2016. Busybox has this runlevel

Re: [OE-core] Python3 and HTTPS issue

Had a change of heart and just sent a patch to add ca-certificates to the recommends for python3-crypt. Ross On Mon, 8 Oct 2018 at 12:52, Burton, Ross wrote: > Python3 would be overkill, but the SSL libraries probably should yes. > > Ross > > On Sat, 6 Oct 2018 at 02:54, Marc

Re: [OE-core] Python3 and HTTPS issue

Python3 would be overkill, but the SSL libraries probably should yes. Ross On Sat, 6 Oct 2018 at 02:54, Marc Ferland wrote: > On Fri, Oct 5, 2018 at 5:22 PM Burton, Ross wrote: > > > > Did you install ca-certificates? > > > > Looks like it did the trick, thanks. &g

Re: [OE-core] Python3 and HTTPS issue

Did you install ca-certificates? Ross On Fri, 5 Oct 2018 at 15:49, Marc Ferland wrote: > > Hi everyone, > > I'm currently having a strange issue with python3 and https (using > sumo branch, commit 161eaa28ed16f93d57f3d1c4be84f894e99ab72e). Whenever > I try to connect to an https server I get: >

Re: [OE-core] (no subject)

I'm curious: the data sheet for the processor you mention in 4/4 says that it ha 64K of RAM. Are there other processors in the range, or have you done incredible things? Ross On Thu, 4 Oct 2018 at 14:30, Angelo Dureghello wrote: > > > This patch serie adds initial support for m68k architecture.

Re: [OE-core] [PATCH] pango: fix ptest failed problem

An even simpler fix is to just remove --disable-debug. We don't need a build with ptest enabled to have *all* the debuggig enabled, and it's always nice to have cast checks enabled (which --disable-debug turns off). Ross On Mon, 1 Oct 2018 at 11:34, Peter Kjellerstedt wrote: > > > -Original

Re: [OE-core] [PATCH V3] mesa: Disable asm on musl

Perfect. :) Did you file a bug upstream, or shall I copy/paste that into a bug now? Ross On Wed, 3 Oct 2018 at 01:49, Khem Raj wrote: > > Musl started blocking dlopen of libs with initial-exec references into > dynamic TLS area, via > >

Re: [OE-core] [PATCH] mesa: Disable asm on musl

I think musl is > exposing a bug in Mesa > Which we covered by disabling tls in Glx once we disable that then this > problem pops up so we disable ASM > > So this is a workaround until then > > On Tue, Oct 2, 2018 at 12:28 PM Burton, Ross wrote: >> >> Isn't this a bi

Re: [OE-core] [PATCH] mesa: Disable asm on musl

Isn't this a bit overkill? Is the assembler actually broken? Ross On Tue, 2 Oct 2018 at 20:21, Khem Raj wrote: > > some unknown part of mesa's x86 assembly > code is broken by readonly text segments > > [ YOCTO #12918 ] > > Signed-off-by: Khem Raj > --- > meta/recipes-graphics/mesa/mesa.inc |

Re: [OE-core] [PATCH V2] openssl: fix ptest case `test_symbol_presence' failed

If the test case needs debug symbols then I'd suggest we just disable that test. Especially as the test starts with this comment: "NOTE: developer test! It's possible that it won't run on your\n", "platform, and that's perfectly fine. This is mainly for developers\n", Ross On Mon, 1 Oct 2018 at

Re: [OE-core] [PATCH 1/2] libepoxy: fix PACKAGECONFIG to get rid of required opengl distro feature

On Sat, 29 Sep 2018 at 10:35, Chen Qi wrote: > -REQUIRED_DISTRO_FEATURES = "opengl" But libepoxy is a GL wrapper, so what is this *actually* achieving? The opengl DISTRO_FEATURE is deliberately vague and just means that some form of OpenGL is available. Ross --

Re: [OE-core] [PATCH 2/2] webkitgtk: fix to build without opengl

>From the libepoxy web site: "Epoxy is a library for handling OpenGL function pointer management for you" libepoxy is essentially a glorified wrapper around dlopen()/dlsym(). Are you simply moving the failure from build time to run time? libepoxy should be pulling in a GL implementation because

Re: [OE-core] [PATCH 1/1] sigwaitinfo01: recent glibc calls syscall directly

Please put the recipe name at the beginning of the commit log, and rebase on top of master. Ross On Fri, 21 Sep 2018 at 07:10, Hongzhi.Song wrote: > > The case of sigwaitinfo related to sigwaitinfo API failed. > > glibc commit > 8b0e795aaa44 ("Simplify Linux sig{timed}wait{info}

Re: [OE-core] [PATCH] [PATCH] adwaita-icon-theme:upgrade to 3.30.0

Please verify the patches apply cleanly: WARNING: adwaita-icon-theme-3.30.0-r0 do_patch: Some of the context lines in patches were ignored. This can lead to incorrectly applied patches. The context lines in the patches can be updated with devtool: devtool modify devtool finish

Re: [OE-core] python-sqlite3 packaging

Patch on the list now Ross On Wed, 26 Sep 2018 at 10:23, Jeroen Hofstee wrote: > > Hello Alejandro, > > > On 09/25/2018 05:08 PM, Alejandro Hernandez wrote: > > Hey Jeroen, > > > > On 9/24/2018 12:22 PM, Jeroen Hofstee wrote: > >> Hello, > >> > >> Not sure where to report this, so trying here.

Re: [OE-core] [oe-commits] [openembedded-core] 02/45: fribidi: use Meson instead of autotools

s.yoctoproject.org/Errors/Build/68805/ > > see the first three > On Mon, Sep 24, 2018 at 12:28 PM Burton, Ross wrote: > > > > Turns out that fix promptly breaks something else... > > > > Digging into Meson today and trying to fix some target/host confusion. > > &

Re: [OE-core] [oe-commits] [openembedded-core] 02/45: fribidi: use Meson instead of autotools

Turns out that fix promptly breaks something else... Digging into Meson today and trying to fix some target/host confusion. Ross On Mon, 24 Sep 2018 at 19:58, Khem Raj wrote: > > On Mon, Sep 24, 2018 at 4:10 AM Burton, Ross wrote: > > > > I can't seem to replicate this

Re: [OE-core] [oe-commits] [openembedded-core] 02/45: fribidi: use Meson instead of autotools

=1e32317ad77457d2a026eaa67ea7c6eebe58b127 for me please? Cheers, Ross On Mon, 24 Sep 2018 at 11:08, Burton, Ross wrote: > > Looks like Meson is using the target link flags for linking even when > it knows its doing a native build. Talking to Meson upstream now and > have a workarou

Re: [OE-core] [oe-commits] [openembedded-core] 02/45: fribidi: use Meson instead of autotools

Looks like Meson is using the target link flags for linking even when it knows its doing a native build. Talking to Meson upstream now and have a workaround. Ross On Sun, 23 Sep 2018 at 15:51, Khem Raj wrote: > > On Sun, Sep 23, 2018 at 2:20 AM Martin Jansa wrote: > > > > Was this one ever

Re: [OE-core] [PATCH 0/3 v5] udev-extraconf/mount.sh: add systemd-mount command for systemd

I just looked at this. Didn't we merge the old patch from April and not this series? Ross On Wed, 19 Sep 2018 at 10:44, Hongzhi, Song wrote: > > Sorry for ping. > > The patch has been merged. > > --Hongzhi > > > On 09/19/2018 05:37 PM, Hongzhi, Song wrote: > > ping.. > > > > --Hongzhi > > > > >

Re: [OE-core] [PATCH 1/1] runqemu: fix handling of SIGTERM and the problem of line wrapping

Is there a good reason why shell=True is used in the first place? Just change the cmd to a list, stop passing shell=True, and you don't need to dance around process groups. Ross On Fri, 21 Sep 2018 at 03:30, Chen Qi wrote: > > The current handling of SIGTERM is incorrect as the process pid

Re: [OE-core] [PATCH v2 5/9] libgpg-error: Add ARC support

Yes, that fixes it. Ross On Fri, 21 Sep 2018 at 14:08, Alexey Brodkin wrote: > > Hi Ross, > > On Fri, 2018-09-21 at 13:53 +0100, Burton, Ross wrote: > > Can you check that v3 works with x86-64 targets? > > > > ERROR: libgpg-error-1.32-r0 do_compile: Function fa

Re: [OE-core] [PATCH v2 5/9] libgpg-error: Add ARC support

/log.do_compile.13345) Ross On Fri, 21 Sep 2018 at 13:51, Alexey Brodkin wrote: > > Hi Ross, > > On Fri, 2018-09-21 at 14:31 +0300, Alexey Brodkin wrote: > > Hi Ross, > > > > On Fri, 2018-09-21 at 11:43 +0100, Burton, Ross wrote: > > > On Thu, 20 Sep 201

Re: [OE-core] Kernel warnings with master/poky-lsb

On Fri, 21 Sep 2018 at 13:33, Bruce Ashfield wrote: > > FYI, the poky-lsb builds for meta-yocto-bsp BSPs are all emitting this > > warning: > > > > WARNING: linux-yocto-4.14.48+gitAUTOINC+9beb3a2873_04043b48eb-r0 > > do_kernel_configcheck: [kernel config]: This BSP sets config options > > that

Re: [OE-core] [PATCH v2 8/9] binutils: Fix Glibc building for ARC

That's good to know, thanks. Ross On Fri, 21 Sep 2018 at 12:41, Alexey Brodkin wrote: > > Hi Ross, > > On Fri, 2018-09-21 at 11:55 +0100, Burton, Ross wrote: > > I don't like accumulating pending patches for something as key as > > binutils, are these actually workin

[OE-core] Kernel warnings with master/poky-lsb

FYI, the poky-lsb builds for meta-yocto-bsp BSPs are all emitting this warning: WARNING: linux-yocto-4.14.48+gitAUTOINC+9beb3a2873_04043b48eb-r0 do_kernel_configcheck: [kernel config]: This BSP sets config options that are not offered anywhere within this kernel: CONFIG_USB_OCTEON2_COMMON Is

Re: [OE-core] [PATCH v2 8/9] binutils: Fix Glibc building for ARC

I don't like accumulating pending patches for something as key as binutils, are these actually working their way upstream now? Ross On Thu, 20 Sep 2018 at 21:44, Alexey Brodkin wrote: > > Signed-off-by: Alexey Brodkin > --- > > Changes v1 -> v2: > > * Added upstream status > >

Re: [OE-core] [PATCH v2 5/9] libgpg-error: Add ARC support

On Thu, 20 Sep 2018 at 21:44, Alexey Brodkin wrote: > case ${TARGET_ARCH} in > aarch64_be) TUPLE=aarch64-unknown-linux-gnu ;; > + arc)TUPLE=i686-unknown-linux-gnu ;; > arm)TUPLE=arm-unknown-linux-gnueabi ;; > armeb)

Re: [OE-core] [PATCH] mesa: enable virgl driver for qemux86/qemux86-64

I'm assuming you have a local config to turn on gallium, as that isn't enabled by default. Ross On Wed, 19 Sep 2018 at 04:28, wrote: > > From: Ming Liu > > virgl driver should be enabled for qemux86/qemux86-64 machines, or else > it will cause runtime issue due to virtio_gpu driver missing. > >

Re: [OE-core] [PATCH] glibc-package.inc: correct intention for deleting /usr/lib as needed

achment? > > BR, > Awais > > ________ > From: Burton, Ross [ross.bur...@intel.com] > Sent: Thursday, September 20, 2018 4:10 PM > To: Belal, Awais > Cc: OE-core > Subject: Re: [OE-core] [PATCH] glibc-package.inc: correct intention for > deleting /

Re: [OE-core] [PATCH 1/3] xserver-xorg: upgrade 1.19.6 -> 1.20.1

Patch to remove that sent. I also sent upstream the arm/musl/inb patch. Ross On Wed, 19 Sep 2018 at 05:15, Khem Raj wrote: > > On Mon, Sep 17, 2018 at 7:51 PM Mittal, Anuj wrote: > > > > > > > > > -Original Message- > > > From: openembedded-core-boun...@lists.openembedded.org > > >

Re: [OE-core] [PATCH] glibc-package.inc: correct intention for deleting /usr/lib as needed

Can you resend using git-send-email, as this patch is encoded in HTML. Ross On Tue, 18 Sep 2018 at 11:53, Belal, Awais wrote: > > In case the baselib is lib64 we would want to delete /usr/lib > after removing the /usr/lib/locale dir and the implementation > wanted to do that earlier as well but

Re: [OE-core] [PATCH 2/3] python: respect package order in manifest

Close, but: ERROR: python-2.7.15-r1 do_package_qa: QA Issue: non -staticdev package contains static .a library: python-distutils path '/work/corei7-64-poky-linux/python/2.7.15-r1/packages-split/python-distutils/usr/lib/python2.7/config/libpython2.7.a' [staticdev] Ross On Fri, 14 Sep 2018 at

Re: [OE-core] [PATCH] dbus-test: fix ptest failed problem when multilib is enabled

Surely a better/safer replacement would be to change run-ptest to: -export LD_LIBRARY_PATH=/usr/lib/dbus-test/ptest/test/.libs +export LD_LIBRARY_PATH=@PTEST_PATH%/test/.libs And then substitute that. Replacing in baselib doesn't help if the distro changes PTEST_PATH. Ross On Wed, 19 Sep 2018

Re: [OE-core] ✗ patchtest: failure for python3{,-native}: update to 3.7.0 (rev3)

In this case set the status to Pending. Ross On Tue, 18 Sep 2018 at 15:26, Jens Rehsack wrote: > > > > Am 17.09.2018 um 21:03 schrieb Patchwork > : > > == Series Details == > > Series: python3{,-native}: update to 3.7.0 (rev3) > Revision: 3 > URL :

Re: [OE-core] [PATCH] gdb: gdbserver: update ctrl-c handling

On Tue, 18 Sep 2018 at 10:01, Zhixiong Chi wrote: > ++Upstream-Status: Pending > ++cherry-picked patch from > https://sourceware.org/bugzilla/show_bug.cgi?id=18945 Sounds like the status should be: Upstream-Status: Submitted [https://sourceware.org/bugzilla/show_bug.cgi?id=18945] Ross Ross

Re: [OE-core] [PATCH] unzip: add nativesdk support

No need to bump PR. Ross On Mon, 17 Sep 2018 at 14:42, Andrej Valek wrote: > > Signed-off-by: Andrej Valek > --- > meta/recipes-extended/unzip/unzip_6.0.bb | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/meta/recipes-extended/unzip/unzip_6.0.bb >

Re: [OE-core] [PATCH] oeqa/selftest/runtime_test: Ensure we build/use gnupg-native

Doesn't quite work: 2018-09-14 23:53:16,527 - oe-selftest - INFO - 7: 13/14 281/332 (10.67s) (runtime_test.TestImage.test_testimage_dnf) 2018-09-14 23:53:16,527 - oe-selftest - INFO - testtools.testresult.real._StringException: Traceback (most recent call last): File

Re: [OE-core] [PATCH v2] python/python3: Move test files to test package

On 14 September 2018 at 16:13, Andrew Geissler wrote: > Nice, thanks Ross! Looks good to me. Will you be back-porting to > python2 as well? Struggling to be motivated for Py2 to be honest. Do you fancy duplicating the changes for Py2? Alternatively I'll get around to doing it next week. Ross

Re: [OE-core] [PATCH v2] python/python3: Move test files to test package

On 14 September 2018 at 00:49, Burton, Ross wrote: > On 14 September 2018 at 00:30, Burton, Ross wrote: >> I suspect simply adding python3.5/*/test/ will catch the bulk of this >> now and in the future. > > Gave this a go and annoyingly the manifest generation must so

Re: [OE-core] [PATCH] tune-core2: use n270 instead of core2duo

On 13 September 2018 at 23:50, Andre McCurdy wrote: > From the Yocto bug these warnings are coming from the nightly builds: > > https://bugzilla.yoctoproject.org/show_bug.cgi?id=12916 > > Has something changed recently? Have the nightly builds moved onto an > AMD machine? No, the new AB code

Re: [OE-core] [PATCH v2] python/python3: Move test files to test package

On 14 September 2018 at 00:30, Burton, Ross wrote: > I suspect simply adding python3.5/*/test/ will catch the bulk of this > now and in the future. Gave this a go and annoyingly the manifest generation must sort the list because the glob works for everything apart from packages after

Re: [OE-core] [PATCH v2] python/python3: Move test files to test package

A little oe-pkgdata-util[1] managed to give me a good review of some missing entries here. python3-asyncio: /usr/lib/python3.5/asyncio/test_utils.py python3-2to3: /usr/lib/python3.5/lib2to3/tests/test_*.py python3-tkinter: /usr/lib/python3.5/tkinter/test/ python3-unittest:

<    1   2   3   4   5   6   7   8   9   10   >