On Sun, 28 Jul 2019 at 03:50, wrote:
> The changes include:
> - Drop all autotools related patches.
> - Move weston-launch setuid-install to do_install task since it's not
> supported yet by meson build.
> - Drop cairo-glesv2 package config, it's not supported by meson build,
> the
Considering:
1) bitbake is written in Python 3
2) HOSTTOOLS contains python3
There *really* is a host python 3 binary, and the canonical path to it
is ${HOSTTOOLS_DIR}/python3.
Ross
On Fri, 26 Jul 2019 at 16:40, Piotr Tworek wrote:
>
> Although /usr/bin/python3 works fine for class-target
I wonder how that happened, it must be finding a libdb somewhere...
On Fri, 26 Jul 2019 at 04:32, Mittal, Anuj wrote:
>
> Hi Ross
>
> This is causing errors:
>
> https://autobuilder.yoctoproject.org/typhoon/#/builders/72/builds/869/steps/8/logs/errors
>
> step7b: ERROR: libical-3.0.5-r0
On Thu, 25 Jul 2019 at 12:42, wrote:
> - Introduce remoting package config, without it meson would run into a
> build error.
Did you tell upstream about this?
Ross
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
I'm not hugely happy about adding new API that isn't in discussion
with upstream.
Ross
On Thu, 25 Jul 2019 at 08:02, wrote:
>
> From: Jason Wessel
>
> Add the ability to use a password encoded URI for use with ostree.
>
> Signed-off-by: Jason Wessel
> Signed-off-by: Mingli Yu
> ---
>
Are you aware of container-test-image.bb? Curious what the point of this is.
Ross
On Wed, 24 Jul 2019 at 03:39, Chen Qi wrote:
>
> Add a small busybox based container image.
>
> Signed-off-by: Chen Qi
> ---
> meta/recipes-core/images/container-image-busybox.bb | 8
> 1 file changed,
The last release of Orage was four years ago: I suggest removing that
from meta-xfce instead of keeping everyone else using an old version
of libical.
Ross
On Tue, 23 Jul 2019 at 22:04, Khem Raj wrote:
>
> this is causing a failure in meta-xfce
>
>
On Tue, 23 Jul 2019 at 20:33, Randy MacLeod wrote:
> Can you remind tell me why we need to keep libsdl_1.2.15?
> It was deprecated 7 years ago:
> https://en.wikipedia.org/wiki/Simple_DirectMedia_Layer
>
>
> $ cd .../oe-core.git
> $ rgrep sdl * | grep -v sdl2 | \
> grep -v
On Tue, 23 Jul 2019 at 09:35, Adrian Bunk wrote:
> In meta-openembedded the only other recipe using scons is
> PNBLACKLIST[mongodb] = "Since bbclass scons convert to python3, build mongodb
> failed"
>
> So 2/2 of the scons-using recipes in meta-openembedded so not work with
> the Python 3
On Tue, 23 Jul 2019 at 06:43, Adrian Bunk wrote:
> On Mon, Jul 22, 2019 at 10:51:35AM +0100, Burton, Ross wrote:
> > Do we need the Python 2 variation of scons in oe-core, or even at all?
>
> Regarding the latter, do you see what is needed for making gpsd in
> meta-oe working
Just send this patch as a v2 (git send-email -v2 ... if you didn't
know the handy shortcut).
On Mon, 22 Jul 2019 at 16:53, Oleksandr Kravchuk
wrote:
>
> Would it work if I resend this patch only or should I resend the entire
> sequence of patches?
>
> On 22/07/2019 12:16, Bur
(The recipe is doing DEPENDS= and overriding the DEPENDS+= in
setuptools3.bbclass)
On Mon, 22 Jul 2019 at 11:15, Burton, Ross wrote:
>
> The upgrade is failing for me:
>
> ERROR: python3-git-2.1.12-r0 do_configure: Function failed:
> do_configure (log file is located at
> /da
The upgrade is failing for me:
ERROR: python3-git-2.1.12-r0 do_configure: Function failed:
do_configure (log file is located at
/data/poky-tmp/master/work/corei7-64-poky-linux/python3-git/2.1.12-r0/temp/log.do_configure.32072)
ERROR: Logfile of failure stored in:
Do we need the Python 2 variation of scons in oe-core, or even at all?
Ross
On Mon, 22 Jul 2019 at 01:18, Oleksandr Kravchuk
wrote:
>
> Signed-off-by: Oleksandr Kravchuk
> ---
> ...hon-scons-native_3.0.5.bb => python-scons-native_3.1.0.bb} | 0
> .../python/{python-scons_3.0.5.bb =>
On Thu, 4 Jul 2019 at 15:40, wrote:
> +++ b/meta/conf/distro/include/init-manager-systemd.inc
> @@ -0,0 +1,6 @@
> +# Use systemd for system initialization
> +DISTRO_FEATURES_append = " systemd"
> +DISTRO_FEATURES_BACKFILL_CONSIDERED_append = " sysvinit"
> +VIRTUAL-RUNTIME_init_manager = "systemd"
On Thu, 18 Jul 2019 at 23:31, akuster808 wrote:
> Any reason this can't be configurable?
The raw data isn't updated a lot more frequently than that as far as
I'm aware. Also I may retract this and replace it with simply using
DATE as the hash because otherwise the class causes constant rebuilds
n to use os.path.join() please.
>
> I can't find the patches your are referring to. My patches are rebased
> on the last master, and I don't see a patch from you in master-next.
>
> Pierre
>
> Le jeu. 18 juil. 2019 à 15:10, Burton, Ross a écrit :
> >
>
> >
Can you rebase this on top of the patches I sent yesterday to change
the path construction to use os.path.join() please.
Ross
On Thu, 18 Jul 2019 at 13:41, Pierre Le Magourou wrote:
>
> From: Pierre Le Magourou
>
> djb2 hash algorithm was found to do collisions, so the database was
> sometime
> Should I submit individual patches for backport to "thud" and "warrior"
> branches ?
Yes, please.
Ross
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
On Thu, 18 Jul 2019 at 07:04, Adrian Bunk wrote:
> > Now that both Debian 8 and OpenSuse 42.3 are end-of-life and no longer
> > formally supported, we think it's time to drop them from the supported
> > distribution list.
>
> Debian 8 is still LTS-supported for a year, unless there is urgency to
Hi,
Now that both Debian 8 and OpenSuse 42.3 are end-of-life and no longer
formally supported, we think it's time to drop them from the supported
distribution list. Initially this involves removing them from the
SANITY_TESTED_DISTROS list in Poky, at some point during this cycle we
may remove
On Wed, 17 Jul 2019 at 13:25, wrote:
> buildhistory shows that busybox-dbg PKGSIZE increases from 4523596 to 4546396,
> busybox-ptest PKGSIZE decreases from 458949 to 458908 even when
> /usr/lib/busybox/ptest/testsuite/tar.utf8.tar.bz2 is added, busybox-src
> PKGSIZE increases from 4130952 to
Yes, I clearly meant to do that but forgot to check before posting.
Ross
On Tue, 16 Jul 2019 at 17:30, Khem Raj wrote:
>
> May be add a line about why it is being removed
>
> On Tue, Jul 16, 2019 at 5:46 AM Ross Burton wrote:
>>
>> Signed-off-by: Ross Burton
>> ---
>>
(discussed on IRC)
NACK, this is in python3-misc and I don't see a good reason to split
it out explicitly.
Ross
On Fri, 12 Jul 2019 at 15:09, Joshua Lock wrote:
>
> Signed-off-by: Joshua Lock
> ---
> .../python/python3/python3-manifest.json | 12
> 1 file changed, 12
On Fri, 12 Jul 2019 at 12:21, Peter Kjellerstedt
wrote:
> ERROR: sysstat-12.1.3-r0 do_package: SYSTEMD_SERVICE_sysstat value
> sysstat.service does not exist
> ERROR: sysstat-12.1.3-r0 do_package:
> ERROR: sysstat-12.1.3-r0 do_package: Function failed:
> systemd_populate_packages
>
>
On Fri, 12 Jul 2019 at 11:33, Robert Yang wrote:
> > HOSTTOOLS is more complicated and there's still plenty of pieces that
> > use host python. I've an old poky-contrib:ross/nopy2 branch that
> > fixes a few more users of host python2 that needs rebasing and
> > retesting.
>
> I meant remove
On Fri, 12 Jul 2019 at 07:30, Adrian Bunk wrote:
> Debian has already done a lot of work regarding reproducible,
> so checking there for existing patches first is always a good idea.
To expand on this for people who don't know how to mine Debian: first,
identify the source package. In this case
Bug closed as 'python' doesn't have to mean Python 2. We'll use use
python3 to start the bootstrap ourself.
On Fri, 12 Jul 2019 at 08:49, Burton, Ross wrote:
>
> On Fri, 12 Jul 2019 at 01:54, Khem Raj wrote:
> > Maybe we should encode it in interpreter section inside configure.p
On Fri, 12 Jul 2019 at 01:54, Khem Raj wrote:
> Maybe we should encode it in interpreter section inside configure.py
> itself and upstream it.
I've filed a bug (https://github.com/ninja-build/ninja/issues/1601) to
see if they have any strong reasons to stick with python instead of
python3.
Ross
On Thu, 11 Jul 2019 at 21:45, Adrian Bunk wrote:
> The Debian patch for the same purpose simply removes the problematic
> line - a comment with the build host was anyways not important information.
Agreed, it's just a comment, and replacing it with logic just means
more effort when we need to
On Thu, 11 Jul 2019 at 11:26, Burton, Ross wrote:
>
> On Thu, 11 Jul 2019 at 03:59, Robert Yang wrote:
> > On 6/28/19 8:15 PM, Burton, Ross wrote:
> > > Did you just do the minimum required, or take a new copy of waf from
> > > upstream?
> > >
> >
On Thu, 11 Jul 2019 at 03:59, Robert Yang wrote:
> On 6/28/19 8:15 PM, Burton, Ross wrote:
> > Did you just do the minimum required, or take a new copy of waf from
> > upstream?
> >
> > (https://gitlab.com/ita1024/waf/)
>
> I checked the one from upstr
Helpful when I commit all of the changes isn't it...
On Wed, 10 Jul 2019 at 22:22, Richard Purdie
wrote:
>
> On Wed, 2019-07-10 at 13:34 +0100, Ross Burton wrote:
> > The current test builds Navit, which uses GTK+ 2. As GTK+ 2 is being
> > removed
> > from oe-core, change the test to build
On Tue, 9 Jul 2019 at 12:47, Nathan Rossi wrote:
> Just to clarify, by real hardware are you interested in the tests
> running against a system running with a oe distro + kernel. Or just
> running on e.g. the build host?
>
> As for the failing tests, do not put to much emphasis on the values
>
This is awesome!
On Sat, 6 Jul 2019 at 12:39, Nathan Rossi wrote:
> | gcc | g++ | libstdc++ | binutils| gas
> | ld | glibc
> x86-64 | 589/135169 | 457/131913 | 1/13008 | 0/ 236 | 0/
> 1256 | 166/ 1975 | 1423/ 5991
> arm
On Tue, 9 Jul 2019 at 02:11, akuster808 wrote:
> On 7/8/19 4:46 PM, Ross Burton wrote:
> > As the sysroot isn't ran inside pseudo the ownership is whoever is running
> > the
> > builds. In a setup where multiple builders all contribute to a shared
> > buildhistory writing the ownership data
Agreed, making it a non-fatal dependency just means that some eSDKs
break, not all. There needs to be a better fix.
Ross
On Mon, 8 Jul 2019 at 17:53, Richard Purdie
wrote:
>
> On Mon, 2019-07-08 at 15:37 +0800, Chen Qi wrote:
> > For build-sysroots.bb, the xmlcatalog would not be in its
> >
On Mon, 8 Jul 2019 at 08:36, Anuj Mittal wrote:
> +PACKAGECONFIG ??= "\
> + ${@bb.utils.contains('DISTRO_FEATURES', 'x11', 'x11', ''
> ,d)} \
> + ${@bb.utils.contains('DISTRO_FEATURES', 'wayland',
> 'wayland', '' ,d)} \
bb.utils.filter() is a neater way of
We could just always install libxml2 into the SDK...
On Fri, 5 Jul 2019 at 02:18, Chen Qi wrote:
>
> For build-sysroots.bb, the xmlcatalog would not be in its
> staging directory. Causing the following error for eSDK.
>
> ERROR: build-sysroots-1.0-r0 do_build_native_sysroot: Command
>
Check the log for the a particular setscene task and it will show what
requests it made, and if they failed.
Ross
On Wed, 3 Jul 2019 at 11:09, Ankur Tyagi wrote:
>
> Hi,
>
> I am trying to setup sstate-cache in Artifactory so that multiple
> Linux host systems can share it.
>
> Once build
Yeah discovered that late last night here too. V2 finalising now.
Ross
On Wed, 3 Jul 2019 at 09:08, Richard Purdie
wrote:
>
> On Tue, 2019-07-02 at 16:22 +0100, Ross Burton wrote:
> > Instead of using part of ${base_libdir} to rename scripts, use
> > MLPREFIX. This
> > is more obvious as
On Mon, 1 Jul 2019 at 13:00, Matt Madison wrote:
> As for Richard's initial question, go.bbclass inherits ptest to enable
> the mapping of go's built-in test builds automatically. In hindsight,
> maybe this wasn't the best choice, and it was overly optimistic to
> think that because go supports
I just noticed that Oleksandr sent the 1.0.7 upgrade, so the backport
patch is good for all other stable branches.
Ross
On Mon, 1 Jul 2019 at 10:48, Burton, Ross wrote:
>
> *All* security issues are fixed in master first and then bubble down
> the stable branches. Otherwise, if you
at 22:50, wrote:
>
> Hi,
>
>
> > -Original Message-
> > From: Burton, Ross
> > Sent: Saturday, June 29, 2019 9:30 PM
> > To: anatol...@belski.net
> > Cc: OE-core
> > Subject: Re: [OE-core] [thud][PATCH v2] bzip2: Fix CVE-2019-12900
&
For master, lets upgrade to 1.0.7 instead.
Ross
On Sat, 29 Jun 2019 at 20:28, wrote:
>
> From: Anatol Belski
>
> Affects bzip2 <= 1.0.6
>
> Signed-off-by: Anatol Belski
> ---
> .../bzip2/bzip2-1.0.6/CVE-2019-12900.patch| 37 +++
>
Did you just do the minimum required, or take a new copy of waf from upstream?
(https://gitlab.com/ita1024/waf/)
Ross
On Fri, 28 Jun 2019 at 13:01, Robert Yang wrote:
>
> Signed-off-by: Robert Yang
> ---
> meta/recipes-graphics/eglinfo/files/waf | 4 ++--
> 1 file changed, 2 insertions(+), 2
The maintainer said:
> The patch below fixes this
> (it is committed for whenever the next bc/dc release gets made).
So:
> +Upstream-Status: Pending [Got the solution from maintainer]
This should be Backport.
Ross
--
___
Openembedded-core mailing
Actually looked at this. The makefile is using pod2man, which is in
HOSTTOOLS, so how is this a problem?
Ross
On Thu, 27 Jun 2019 at 14:54, Joshua Watt wrote:
>
> opkg-utils requires perl to generate documentation in do_compile. If not
> present, the documentation will be skipped, which is not
To avoid needing perl-native, can it be told to use the host perl?
Ross
On Thu, 27 Jun 2019 at 14:56, Joshua Watt wrote:
>
> perl is required to generate the OpenSSL documentation, and therefore
> should be present at do_compile. If not, OpenSSL will skip the
> documentation generation, which
On Thu, 27 Jun 2019 at 14:55, Joshua Watt wrote:
> gettext is required to generate the glibc locales in do_compile. If not
> present, glibc will skip the generation which isn't reproducible.
>
> Signed-off-by: Joshua Watt
> ---
> meta/recipes-core/glibc/glibc_2.29.bb | 2 +-
> 1 file changed, 1
Well spotted, thanks.
Changed in my branch.
Ross
On Thu, 27 Jun 2019 at 14:47, Martin Jansa wrote:
>
> > Changes to the sysroot as just as
>
> small typo in commit message if you need to update this commit again for
> whatever other reason.
>
> On Thu, Jun 27, 2019 at 2:29 PM Ross Burton
The patch doesn't have an Upstream-Status tag, and at no point do you
explain in the log that this is for musl, and results in resolved
being enabled in musl builds.
Ross
On Wed, 26 Jun 2019 at 09:36, Jörg Hofrichter wrote:
>
> From: Joerg Hofrichter
> Date: Wed, 26 Jun 2019 10:30:34 +0200
>
On Tue, 25 Jun 2019 at 09:49, Pierre Le Magourou wrote:
> > Also, the CVE db is updated using this custom task without link to
> > do_fetch, which means a fetchall task would not update the database for
> > off line NO_NETWORK builds.
> >
> > Could the task be added as dependency to do_fetch() or
On Mon, 24 Jun 2019 at 21:20, Alejandro Enedino Hernandez Samaniego
wrote:
> > # manual dependency additions
> > -RPROVIDES_${PN}-core = "${PN}"
> > +RPROVIDES_${PN}-modules = "${PN}"
>
> Is it just me or we already had this?, maybe we had this only for python3
It was only for Py3! Swore I
On Mon, 24 Jun 2019 at 17:25, wrote:
> That maybe but I'd still like to test that it builds given it was added
> due to problems where it stopped building and people got upset...
v2 sent.
Ross
--
___
Openembedded-core mailing list
On Mon, 24 Jun 2019 at 17:09, Richard Purdie
wrote:
> > -features += 'RUNTIMETARGET_append_pn-gcc-runtime = "
> > libquadmath"\n'
>
> Please don't remove that. We need to check libquadmath builds.
>From gcc-runtime.inc:
RUNTIMETARGET = "${RUNTIMELIBSSP} libstdc++-v3 libgomp libatomic
Will you be backporting this to Warrior and Thud?
Ross
On Thu, 20 Jun 2019 at 18:45, Joe Slater wrote:
>
> Unchanged patch from glib.git which was added after current release.
>
> Signed-off-by: Joe Slater
> ---
> .../glib-2.0/glib-2.0/CVE-2019-12450.patch | 62
>
Thanks! :)
Ross
On Mon, 24 Jun 2019 at 09:33, Pierre Le Magourou wrote:
>
> Hi,
>
> > > This adds python3 urllib3 (python3-urllib3 in Debian) to build environment
> > > dependencies. It's the first user of urllib3 in poky, AFAIK. Maybe
> > > documentation could be updated too, e.g.
> > >
Is this actually needed? Can we just delete python-scons?
Ross
On Mon, 24 Jun 2019 at 10:33, wrote:
>
> From: Changqing Li
>
> fix below error:
> file /usr/bin/scons conflicts between attempted installs of
> python-scons-3.0.5-r0.core2_32 and python3-scons-3.0.5-r0.core2_32
> file
So why does this build for me?
Ross
On Mon, 24 Jun 2019 at 09:30, Khem Raj wrote:
>
> efivar.h is in usr/include/efirvar directory so it should be
> added to include search path via -I to compiler cmdline to fix
>
> make[1]: *** No rule to make target 'efivar.h', needed by 'efibootmgr.o'.
>
On Fri, 21 Jun 2019 at 12:11, wrote:
> This adds python3 urllib3 (python3-urllib3 in Debian) to build environment
> dependencies. It's the first user of urllib3 in poky, AFAIK. Maybe
> documentation could be updated too, e.g.
>
Is it easier to just always delete those files? Do they serve any
useful purpose?
Ross
On Thu, 20 Jun 2019 at 16:47, Joshua Watt wrote:
>
> Bash has an internal "build number" that it tracks and automatically
> increments ever time a given builds is made from the same sandbox.
> However, this
Why DEPENDS on gtk? The recipes will typically already do this, but
all this class needs is the rdepends. Also, there's no explanation
for the hicolor addition.
Ross
On Thu, 20 Jun 2019 at 14:54, Richard Purdie
wrote:
>
> On Thu, 2019-06-20 at 17:58 +0800, Robert Yang wrote:
> >
> > On
Does this mean we can delete the cve-check-tool recipe itself too?
Ross
On Wed, 19 Jun 2019 at 15:03, Pierre Le Magourou wrote:
>
> From: Pierre Le Magourou
>
> Use the new update-cve-db recipe to update database.
>
> Signed-off-by: Pierre Le Magourou
> ---
> meta/classes/cve-check.bbclass |
I'd say we can assume that less exists.
On Wed, 19 Jun 2019 at 12:05, Adrian Bunk wrote:
>
> On Wed, Jun 19, 2019 at 12:32:51PM +0200, Ricardo Ribalda Delgado wrote:
> >...
> > --- a/meta/recipes-devtools/dpkg/dpkg.inc
> > +++ b/meta/recipes-devtools/dpkg/dpkg.inc
> > @@ -4,7 +4,7 @@ SECTION =
dpkg may, but that's because dpkg is the Debian package manager and it
follows Debian traditions. /usr/bin/pager is a Debianism: I suggest
we just patch it to use 'less'.
Ross
On Wed, 19 Jun 2019 at 10:47, Ricardo Ribalda Delgado
wrote:
>
> Some system tools (like dpkg) expects a binary called
No S-o-b in the patch, but more importantly no Upstream-Status. Have
you reported this upstream? Or compared what we're doing to what
other distros that package serf do?
Ross
On Tue, 18 Jun 2019 at 20:09, Martin Jansa wrote:
>
> * since 1522f09a4d serf: cleanup recipe
> serf.do_install
On Tue, 18 Jun 2019 at 16:51, Khem Raj wrote:
> while I agree, are there assumptions in the recipes using binconfig on this ?
> especially packages outside oe-core ?
I suspect that everyone is using remove-libtool, because that's one of
the default inherits.
Ross
--
On Fri, 14 Jun 2019 at 14:34, Alexander Kanavin wrote:
>
> On Fri, 14 Jun 2019 at 15:26, wrote:
>>
>> I guess if we can track down where the swrast dependency is coming and
>> and change things to avoid it, that would probably be ok.
>
>
> As Ross said, qemu bsp has this:
>
> XSERVER ?=
On Fri, 14 Jun 2019 at 13:46, Alexander Kanavin wrote:
> I would rather replace swrast with virgl in the qemu machine configs.
> Currently it's pulled in implicitly via the megadriver package which has
> virgl included because it is enabled by default in the mesa recipe. From what
> I can see
Are you going to fix all of the other recipes? Very few recipes let
you run the tests from an arbitrary directory, and assume that you're
in the test directory already.
Ross
On Thu, 13 Jun 2019 at 09:08, Hongxu Jia wrote:
>
> 1. Run run-ptest at arbitrary path
>
> 2. Fix large-subopt.in1 not
On Thu, 13 Jun 2019 at 09:48, Lei Maohui wrote:
>
> From: Hong Liu
>
> Fix bug as following on aarch64BE:
>
> Error: operand 1 must be an integer register -- `rev v31.16b,v31.16b'
>
> Upstream-Status: Pending [https://github.com/openssl/openssl/pull/9151]
This line ^^^
> Signed-off-by: Lei
ed "acount" to "account". I didn't
> do redundant change.
>
> > > -+acount includecommon-account
> > > ++account includecommon-account
>
>
> Best regards
> Lei
>
>
> > -Original Message-
> > Fro
I didn't make myself clear. To reduce the amount of moving parts and
changes I propose:
1) libx11 and libx11-diet are untouched
2) New recipe libx11-compose-data which just ships the compose data,
assuming that is all that is needed by xkeyboard-config's Compose
handling. Refuses to build if
On Wed, 12 Jun 2019 at 09:15, Alex Kiernan wrote:
> Upstream-Status: Backport [Not yet released]
> Signed-off-by: Alex Kiernan
As per patchtest, these belong in the patch you add, not the commit message.
Ross
--
___
Openembedded-core mailing list
You do more than fix a spelling mistake in that commit. Please
explain the other changes.
Ross
On Wed, 12 Jun 2019 at 04:09, Lei Maohui wrote:
>
> Signed-off-by: Lei Maohui
> ---
> meta/recipes-extended/at/at/pam.conf.patch | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff
On Tue, 11 Jun 2019 at 15:55, Burton, Ross wrote:
> Either is fine. Note that in the broken case - where the recipe isn't
> skipped - the test goes ahead and compiles stuff. Can you also try
> using --dry-run to see if that results in the same test behaviour, but
> withou
On Tue, 11 Jun 2019 at 15:56, Quentin Schulz
wrote:
> Also, I factored out everything into a function that shouldn't be run as
> a test but when doing:
> oe-selftest --run-tests incompatible_lic.IncompatibleLicenseTests
> it tries to run the function and thus fails the test. Is that okay? if
>
On Tue, 11 Jun 2019 at 15:52, Quentin Schulz
wrote:
> Sorry for the noise, apparently forgot to pull master and didn't even
> see my patch was already there *sigh*.
>
> I'll remove the import and test on master with and without the patch you
> already merged.
>
> Do you want me to send a v5 or a
On Tue, 11 Jun 2019 at 15:27, Quentin Schulz
wrote:
> +from oeqa.core.decorator.oeid import OETestID
This was removed a while ago, can you rebase the patches on top of
master please?
In this case you can just remove the import, but please verify the
behaviour with master.
Ross
--
What would be really useful is a small selftest
(meta/lib/oeqa/selftest/cases) to exercise this codepath. Have a test
that should work but doesn't before the fix, so the bug is
demonstrated and verified.
Ross
On Tue, 11 Jun 2019 at 09:13, Quentin Schulz
wrote:
>
> A non-SPDX license (which is
FWIW, this just landed in json-c master:
https://github.com/json-c/json-c/commit/07ea04e65193c3e5c902c5b79421d5fa48ff67c7
"build: add option --disable-werror to configure"
Ross
On Fri, 7 Jun 2019 at 12:20, Burton, Ross wrote:
>
> FWIW I still believe that just patc
Hurrah, last time I looked at this the Py3 support wasn't quite ready yet.
Ross
On Sat, 8 Jun 2019 at 00:49, Tim Orling
wrote:
>
> python-scons and python-scons-native are perhaps the last python2 only
> recipes in oe-core. With Python 2 going EOL in or before 2020, it's time
> to switch
FWIW I still believe that just patching out -Werror is the correct fix
here. To be honest I'm really close to writing a QA check that
-Werror and friends isn't being used at all...
Filed https://github.com/json-c/json-c/issues/489 in the hope that
upstream will handle it.
Ross
On Fri, 7 Jun
On Fri, 7 Jun 2019 at 09:46, Maciej Pijanowski
wrote:
> > Would you be able to write a small test for this, along the lines of
> > test_recipetool_create_*() in
> > meta/lib/oeqa/selftest/cases/recipetool.py?
> Sure, I will try that. I haven't been contributing to the QA parts yet.
> Is there
My first thought was "won't this break the test" but then I discovered
that there's no test.
Would you be able to write a small test for this, along the lines of
test_recipetool_create_*() in
meta/lib/oeqa/selftest/cases/recipetool.py?
Ross
On Fri, 7 Jun 2019 at 08:56, Maciej Pijanowski
wrote:
On Thu, 6 Jun 2019 at 22:03, Douglas Royds wrote:
> The problem is somewhat specific to json-c, as -Werror is hard-coded
> into configure.ac in this package.
Which is downright evil, and to be honest we should patch that out.
Ross
--
___
Do you mean "harmonise?"
Ross
On Thu, 6 Jun 2019 at 16:18, Nicola Lunghi wrote:
>
> this commit will permit to have a default file
> both in the systemd and in the sysvinit file
>
> Also reorganize the install_append function
>
> Signed-off-by: Nicola Lunghi
> ---
>
The patches you're adding all need your Signed-off-by alongside the
Upstream-Status, specifically
0008-configure-If-the-libc-is-lacking-argp-use-libargp.patch doesn't
have a Sob or U-S.
For the patches that are submitted, please add the pull request:
Upstream-Status: Submitted
You also need a S-o-b by the Upstream-Status in the patch itself, but
I've added that when applying locally so don't bother with a v4.
Thanks!
Ross
On Thu, 6 Jun 2019 at 17:07, Matthias Schoepfer via Openembedded-core
wrote:
>
> This patch originally only meant to correct the python3 build for
Sorry, but:
On Thu, 6 Jun 2019 at 17:00, Matthias Schoepfer via Openembedded-core
wrote:
> This patch originally only meant to correct the python3 build for mips
> with softfloat, as the original test only checked for mips hardfloat.
>
> Replaced custom C Program for triplet detection with
> > The shortlog should be "python3: fix build on softfloat mips".
> Do you want me to send an v2 for it?
Please do, with the shortlog fixed, removal of the word 'backport'
from the message, and your Signed-off-by/Upstream-Status: Submitted
[https://github.com/python/cpython/pull/13196] in the
On Thu, 6 Jun 2019 at 16:15, Matthias Schoepfer via Openembedded-core
wrote:
The shortlog should be "python3: fix build on softfloat mips".
> Applied / backported patch from upstream (pending review)
Is this patch backported, or is it still in review?
> +From
On Wed, 5 Jun 2019 at 17:33, Philippe Normand wrote:
> Yeah you're right, hardcoding /etc might not be a good idea. I kind of
> abandoned this patch series though, since it was decided to not make
> gnutls depend on p11-kit for the time being. This patch was merged
> instead:
>
>
Considering the pain that the gcc upgrade introducing that warning
caused I'll be *very* surprised if this problem is limited to json-c.
Could the icecc class forcibly disable that warning instead?
Ross
On Thu, 6 Jun 2019 at 03:06, Douglas Royds via Openembedded-core
wrote:
>
> icecc
On Thu, 30 May 2019 at 14:48, Philippe Normand wrote:
> +PACKAGECONFIG ??= "trust-paths"
> PACKAGECONFIG[trust-paths] =
> "--with-trust-paths=/etc/ssl/certs/ca-certificates.crt,--without-trust-paths,,ca-certificates"
Should that be /etc? Or $(sysconfdir)? Especially in native and
nativesdk
On Fri, 31 May 2019 at 17:25, Richard Purdie
wrote:
> On Fri, 2019-05-31 at 17:56 +0200, Alexander Kanavin wrote:
> > The tarballs for all versions prior to 18.x have been moved to
> > https://mesa.freedesktop.org/archive/older-versions/
> >
> > To avoid this practice causing fetching failures in
On Fri, 24 May 2019 at 19:59, Tanu Kaskinen wrote:
> 18575b082a4042376fd1575465e69562dea04ddc added bash as a dependency of
> alsa-utils-alsaconf so that the script interpreter will be available at
> run time. However, this has the undesirable side effect of making bash
> be a
The commit message and the patch disagree: you're not removing the
udev dependency but allowing the user to remove it.
A better message would be 'bluez5: allow udev dependency to be
disabled with PACKAGECONFIG'
Ross
On Thu, 23 May 2019 at 17:42, David Frey wrote:
>
> udev is an optional
On Fri, 24 May 2019 at 07:38, wrote:
> -SUMMARY_alsa-utils-alsabat = "Command-line sound tester for ALSA sound
> card driver"
> +SUMMARY_${MLPREFIX}alsa-utils-alsabat = "Command-line sound tester for
> ALSA sound card driver"
Why not replace alsa-utils-alsabat with ${PN}-alsabat?
1 - 100 of 5394 matches
Mail list logo
