Re: [oe] [meta-oe][PATCH v2] zstd: New recipe

[Burton, Ross]

On Fri, 19 Jul 2019 at 14:43, Alex Kiernan  wrote:
> +PACKAGE_BEFORE_PN += " \
> +${PN}-compress \
> +${PN}-decompress \
> +${PN}-frugal \

Is there a good reason to do this?

Ross
-- 
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel

Re: [oe] [PATCH] package.bbclass: fix directories setuid and setgid bits

[Burton, Ross]

This should go to openembedded-c...@lists.openembedded.org, not -devel.

Ross

On Thu, 27 Jun 2019 at 09:59, Jean-Tiare Le Bigot
 wrote:
>
> From: Joël Esponde 
>
> populate_packages relies on ``mkdir`` to both create a directory and set
> its permissions. However, ``mkdir`` honors the ``umask`` value.
> Therefore, some bits may be lost in the operation. In our case, the
> setgid bit on the directories were lost.
>
> This commit fixes this by having a distinct call to create the directory
> and to set the permissions.
>
> Signed-off-by: Jean-Tiare Le Bigot 
> ---
>  meta/classes/package.bbclass | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/meta/classes/package.bbclass b/meta/classes/package.bbclass
> index 20d72bba79..cd223a121e 100644
> --- a/meta/classes/package.bbclass
> +++ b/meta/classes/package.bbclass
> @@ -1216,7 +1216,8 @@ python populate_packages () {
>  src = os.path.join(src, p)
>  dest = os.path.join(dest, p)
>  fstat = cpath.stat(src)
> -os.mkdir(dest, fstat.st_mode)
> +os.mkdir(dest)
> +os.chmod(dest, fstat.st_mode)
>  os.chown(dest, fstat.st_uid, fstat.st_gid)
>  if p not in seen:
>  seen.append(p)
> --
> 2.19.1
>
> --
> ___
> Openembedded-devel mailing list
> Openembedded-devel@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-devel
-- 
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel

Re: [oe] github archives in the recipes

[Burton, Ross]

On Fri, 17 May 2019 at 02:44, Martin Jansa  wrote:
> Don't use github archives, because they are regenerated from time to time 
> with different
> checksums.

I *really* need to get around to merging
https://github.com/rossburton/meta-ross/blob/master/classes/insanitier.bbclass#L93
into oe-core.  I'l try and do that today.

Ross
-- 
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel

Re: [oe] [PATCH] cannelloni: new package, CAN to ethernet proxy

[Burton, Ross]

On Mon, 29 Apr 2019 at 16:04, Sean Nyekjaer via Openembedded-devel
 wrote:
> > Version by hash is not optimal. Can you add PV or change the recipe name
> > to include the version?
> >
> > - armin
> Hi Armin
>
> Upstream have not released in 3 years. But new commits are quite useful...
> So do you have an idea to what I can add as a PV?

https://github.com/mguentner/cannelloni/releases says the last release
was either 20160414 or 0.5.  The idiom is "+git.

Ross
-- 
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel

Re: [oe] [PATCH v2 2/6] libfann: Initial commit

[Burton, Ross]

On Fri, 5 Apr 2019 at 15:49, Alistair Francis  wrote:
> +SRCREV = "${AUTOREV}"

Pick a SHA, don't use autorev.

Ross
-- 
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel

[oe] Do you use ISO images generated by bitbake?

[Burton, Ross]

Hi,

I'm looking for some users that use the ISO images generated by
Bitbake (IMAGE_FSTYPE live or iso).  Anyone out there?

Ross
-- 
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel

Re: [oe] [OE-core] Git commit process question.

[Burton, Ross]

On Tue, 2 Apr 2019 at 20:46, Tom Rini  wrote:
> > The kernel does not have "upgrade foo to the latest upstream version" 
> > commits.
> >
> > With the Automatic Upgrade Helper this is a semi-automatic task, and
> > most of the time there is no specific motivation other than upgrading
> > to the latest upstream version.
>
> But since that's just filling in a template the body can also be a
> template perhaps with useful AUH data (run at ... by ... ?) ?

Apart from making the commit message longer what does this achieve?
The commit already has a timestamp and author.

Ross
-- 
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel

Re: [oe] [meta-oe][PATCH] cpulimit: introduce support for this package

[Burton, Ross]

On Sat, 9 Mar 2019 at 10:55, BOUBAKER Bassem via Openembedded-devel
 wrote:
> +inherit autotools

Upstream isn't autotools, so don't inherit autotools.

Ross
-- 
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel

Re: [oe] [meta-gnome][PATCH 5/5] libgtop: 2.38.0 -> 2.39.91

[Burton, Ross]

Development release, instead add an inherit of upstream-version-is-even.

Ross

On Fri, 8 Mar 2019 at 01:34,  wrote:
>
> From: Kai Kang 
>
> Update libgtop from 2.38.0 to 2.39.91.
>
> * reset LIBGTOP_LIBS to avoid compile-host-path qa issue
>
> Signed-off-by: Kai Kang 
> ---
>  .../libgtop/{libgtop_2.38.0.bb => libgtop_2.39.91.bb}   | 6 --
>  1 file changed, 4 insertions(+), 2 deletions(-)
>  rename meta-gnome/recipes-gnome/libgtop/{libgtop_2.38.0.bb => 
> libgtop_2.39.91.bb} (60%)
>
> diff --git a/meta-gnome/recipes-gnome/libgtop/libgtop_2.38.0.bb 
> b/meta-gnome/recipes-gnome/libgtop/libgtop_2.39.91.bb
> similarity index 60%
> rename from meta-gnome/recipes-gnome/libgtop/libgtop_2.38.0.bb
> rename to meta-gnome/recipes-gnome/libgtop/libgtop_2.39.91.bb
> index 494934fe7..fa5a1d394 100644
> --- a/meta-gnome/recipes-gnome/libgtop/libgtop_2.38.0.bb
> +++ b/meta-gnome/recipes-gnome/libgtop/libgtop_2.39.91.bb
> @@ -7,7 +7,9 @@ inherit gnomebase lib_package gtk-doc distro_features_check 
> gobject-introspectio
>  # depends on libxau
>  REQUIRED_DISTRO_FEATURES = "x11"
>
> -SRC_URI[archive.md5sum] = "bb0ce7de6b28694b40405eedac8a31b5"
> -SRC_URI[archive.sha256sum] = 
> "4f6c0e62bb438abfd16b4559cd2eca0251de19e291c888cdc4dc88e5ffebb612"
> +SRC_URI[archive.md5sum] = "b50a24e8c70af532c5616f42f4ec71b7"
> +SRC_URI[archive.sha256sum] = 
> "3428e3901c80a572d7f7bdf29cc0ecb733cc314038ba3d45093a84f314271f0f"
>
>  DEPENDS = "glib-2.0 libxau"
> +
> +EXTRA_OEMAKE += "LIBGTOP_LIBS="
> --
> 2.20.0
>
> --
> ___
> Openembedded-devel mailing list
> Openembedded-devel@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-devel
-- 
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel

Re: [oe] [meta-gnome][PATCH 3/5] gvfs: 1.39.1 -> 1.39.92

[Burton, Ross]

That recipe should inherit upstream-version-is-even to remind everyone
of this, and stop any automatic tooling that use the upgrade checking
code in oe-core from suggesting upgrades to development releases.

Ross

On Fri, 8 Mar 2019 at 08:10, Kang Kai  wrote:
>
> On 2019/3/8 下午3:57, Andreas Müller wrote:
> > On Fri, Mar 8, 2019 at 2:33 AM  wrote:
> >> From: Kai Kang 
> >>
> >> Signed-off-by: Kai Kang 
> > I have overlooked your last update: Please don't update to unstable
> > gnome releases (odd version numbers) in the future. As far as I can
> > remember there were similar comments in oe-core already.
> >
> > Andreas
> >
> Hi Andreas,
>
> I searched for gnome version policy and got
>
> https://developer.gnome.org/programming-guidelines/stable/versioning.html.en
>
> Most GNOME modules follow a convention for stable and unstable releases.
> The minor version is even for stable releases and is odd for unstable
> releases. For example, the 3.20.* versions are stable, but the 3.19.*
> versions are unstable. The 3.19.* versions can be seen as alpha and beta
> releases of the 3.20 version.
>
> Thanks for reminder.
>
> --
> Kai Kang
>
> --
> ___
> Openembedded-devel mailing list
> Openembedded-devel@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-devel
-- 
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel

Re: [oe] [meta-oe PATCH 1/2] python-idna: Avoid removing '+x' from `.egg-info/` directory

[Burton, Ross]

The original patch doesn't explain what it's doing and is clearly
going to remove executable bits from directories, which clearly isn't
right.

I'd say remove it, and *then* if it breaks again fix properly.

Ross

On Mon, 25 Feb 2019 at 15:07, Khem Raj  wrote:
>
> On Mon, Feb 25, 2019 at 6:00 AM Otavio Salvador  
> wrote:
> >
> > The chmod was removing the executing bit from the directory and then
> > the native version was failing to build.
> >
> > Signed-off-by: Otavio Salvador 
> > ---
> >
> >  meta-python/recipes-devtools/python/python-idna.inc | 4 
> >  1 file changed, 4 deletions(-)
> >
> > diff --git a/meta-python/recipes-devtools/python/python-idna.inc 
> > b/meta-python/recipes-devtools/python/python-idna.inc
> > index 436b58606..519812ddc 100644
> > --- a/meta-python/recipes-devtools/python/python-idna.inc
> > +++ b/meta-python/recipes-devtools/python/python-idna.inc
> > @@ -16,7 +16,3 @@ do_compile_prepend() {
> >  }
> >
> >  BBCLASSEXTEND = "native nativesdk"
> > -
> > -do_install_append() {
> > -chmod 664 -R ${D}${PYTHON_SITEPACKAGES_DIR}/*.egg-info/
> > -}
>
> this overturns a prior fix
> https://git.openembedded.org/meta-openembedded/commit/?id=79bb01985260800f80b393e73b387543f86f9e62
>
> I think it would be better to resolve the original issue before reverting
> it or maybe just appy this for target recipe alone
>
> > \ No newline at end of file
> > --
> > 2.20.1
> >
> > --
> > ___
> > Openembedded-devel mailing list
> > Openembedded-devel@lists.openembedded.org
> > http://lists.openembedded.org/mailman/listinfo/openembedded-devel
> --
> ___
> Openembedded-devel mailing list
> Openembedded-devel@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-devel
-- 
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel

Re: [oe] DATETIME seems to be getting updated

[Burton, Ross]

On Thu, 24 Jan 2019 at 04:32, Muhlenkamp, Lewis
 wrote:
> It appears that the DATETIME variable is being updated.  From what I read 
> this should not be happening, correct?

DATETIME is defined as follows:

DATE := "${@time.strftime('%Y%m%d',time.gmtime())}"
TIME := "${@time.strftime('%H%M%S',time.gmtime())}"
DATETIME = "${DATE}${TIME}"

So every time bitbake.conf is parsed, the datetime is updated.  This
happens once for the main process, and then again for every worker
that bitbake spawns.

You can silence the 'metadata changed' errors by using vardepsexclude
to mark it as a variable that can change (grep oe-core for examples of
using DATETIME and vardepsexclude).

Ross
-- 
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel

Re: [oe] Build suddenly stops and desktop logouts !

[Burton, Ross]

The usual causes are not enough RAM (so the OOM killer steps in and
kills something inappropriate), bad RAM (you're actually using all of
it for a change), or CPU overheating.  The latter two often cause
actual reboots instead of logouts, a logout suggests the OOM killer
was involved.  Setting up a little bit of swap might be useful, or
turn down the parallelism in local.conf.

Ross
On Wed, 19 Dec 2018 at 15:27, Ranran  wrote:
>
> Hello,
>
> I have strange behavior with ubuntu16.04 LTS, in which after building
> for couple of hours, suddenly the ubuntu OS logouts.
> I see that others also have the same issue but seems that there is no 
> solution:
> http://lists.openembedded.org/pipermail/openembedded-core/2016-December/130617.html
> and
> https://stackoverflow.com/questions/48148169/whenever-running-bitbake-stops-all-application-and-locks-the-system
>
> I have increased my virtualbox memory to 11G, (no swap in my ubuntu)
> but it still happens (might be less than before not sure), also
> strangely even after increase with "free" command I see that it get
> sometimes below ~150M free.
>
> Is there any idea what's wrong?
>
> Thank you,
> ran
> --
> ___
> Openembedded-devel mailing list
> Openembedded-devel@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-devel
-- 
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel

Re: [oe] [meta-oe][PATCHv2] iwd: add version 0.12

[Burton, Ross]

On Thu, 22 Nov 2018 at 12:48, Martin Hundebøll  wrote:
> +DEPENDS += "${@bb.utils.contains('PTEST_ENABLED', '1', 'readline', '', d)}"

Better to fix the makefile so it doesn't build the client test if the
client is disabled?

> +SRC_URI = " \
> +git://git.kernel.org/pub/scm/network/wireless/iwd.git \
> +file://0001-configure.ac-enable-serial-tests-in-automake-to-supp.patch \

Oh, I've a patch to automake to make this redundant.  I'll dig it out
and post to oe-core.

> +HAVE_SYSTEMD = "${@bb.utils.contains('PACKAGECONFIG', 'systemd', True, 
> False, d)}"
> +
> +# iwd service
> +SYSTEMD_SERVICE_${PN} = "${@'iwd.service' if 
> bb.utils.to_boolean(d.getVar('HAVE_SYSTEMD')) else ''}"
> +FILES_${PN} += " \
> +${datadir}/dbus-1/system.d/iwd-dbus.conf \
> +${datadir}/dbus-1/system-services/net.connman.iwd.service \
> +"

No need, if systemd is disabled then the class won't do anything.

> +# iwctl tool
> +PN_CLIENT = "${@bb.utils.contains('PACKAGECONFIG', 'client', '${PN}-client', 
> '', d)}"
> +RRECOMMENDS_${PN} += "${PN_CLIENT}"
> +PACKAGE_BEFORE_PN += "${PN_CLIENT}"
> +FILES_${PN}-client += "${bindir}/iwctl"

I'm generally against massively splitting up recipes in the name of
modularity as it just complicates recipes.  Unless there's a good
reason I'd say just put the daemon, the client, and the extra parts
(such as EAD) in the same package.  It's not like anyone would want to
install the client but not the daemon, or installing the client
alongside the daemon would be a huge waste of space.

Ross
-- 
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel

Re: [oe] [meta-oe][PATCH 3/3] iwd: add version 0.12

[Burton, Ross]

On Wed, 21 Nov 2018 at 08:19, Martin Hundebøll  wrote:
> The iwd wireless daemon is an alternative to wpa_supplicant. It is
> controlled using the iwctl command line client (or the dbus interface).
>
> Signed-off-by: Martin Hundebøll 
> ---
>  meta-oe/recipes-connectivity/iwd/iwd_0.12.bb | 24 
>  1 file changed, 24 insertions(+)
>  create mode 100644 meta-oe/recipes-connectivity/iwd/iwd_0.12.bb
>
> diff --git a/meta-oe/recipes-connectivity/iwd/iwd_0.12.bb 
> b/meta-oe/recipes-connectivity/iwd/iwd_0.12.bb
> new file mode 100644
> index 0..a4261547e
> --- /dev/null
> +++ b/meta-oe/recipes-connectivity/iwd/iwd_0.12.bb
> @@ -0,0 +1,24 @@
> +DESCRIPTION = "Wireless daemon for Linux"
> +LICENSE = "LGPL-2.1"
> +LIC_FILES_CHKSUM = "file://COPYING;md5=fb504b67c50331fc78734fed90fb0e09"
> +
> +inherit autotools pkgconfig systemd
> +
> +DEPENDS = "ell readline dbus"
> +
> +SRC_URI = "git://git.kernel.org/pub/scm/network/wireless/iwd.git"
> +SRCREV = "d7609915db4b57229f7dd4c04b4eabcce637872a"
> +S = "${WORKDIR}/git"
> +
> +SYSTEMD_SERVICE_${PN} = "iwd.service"
> +
> +PACKAGECONFIG ??= "${@bb.utils.filter('DISTRO_FEATURES', 'systemd', d)}"
> +PACKAGECONFIG[systemd] = 
> "--with-systemd-unitdir=${systemd_system_unitdir},--disable-systemd-service,systemd"
> +
> +EXTRA_OECONF += "--enable-external-ell"
> +
> +do_configure_prepend () {
> +mkdir -p ${S}/build-aux
> +}
> +
> +FILES_${PN} += "${datadir}/dbus-1"

I started a recipe for this but never got around to submitting it.
You'll find it here:

http://git.yoctoproject.org/cgit.cgi/poky-contrib/commit/?h=ross/mutwipargh=0e7d8a005540bdc36c7af68c0fdb8670ef74a0e0

I definitely think the PACKAGECONFIGs and ead.service need to be added
before merging.  The ptest stuff wasn't tested so I don't know how
useful it was.

Ross
-- 
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel

Re: [oe] [RFC meta-gnome][PATCH 02/16] ibus: add recipe for ibus to support gnome-settings-daemon and gnome-shell

[Burton, Ross]

On Thu, 8 Nov 2018 at 17:28, Brendan Kerrigan  wrote:
> Yeah it does have a build time dependency on gtk+2.

There's a --disable-gtk2, I'd recommend either just passing that or
for bonus points having a disabled packageconfig to enable/disable
gtk2.  GTK+2 is well dead now, so we shouldn't be building it out of
the box.

Ross
-- 
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel

Re: [oe] [RFC meta-gnome][PATCH 02/16] ibus: add recipe for ibus to support gnome-settings-daemon and gnome-shell

[Burton, Ross]

On Thu, 8 Nov 2018 at 17:28, Brendan Kerrigan  wrote:
> Yeah it does have a build time dependency on gtk+2. I've made the other 
> changes, though I still have two libraries that are in subdirectories of 
> libdir that are giving me an installed vs. shipped QA warning. Is it 
> appropriate to do a more specific packaging within libdir (e.g. FILES_${PN} 
> += "${libdir}/subdir/subdir.so") or should I take a different approach?

If they're plugins/modules then for clarity do FILES_${PN} +=
${libdir}/subdir/, because if a proper library is ever added the
packaging will totally break.

Ross
-- 
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel

Re: [oe] [PATCH][meta-oe] pcsc-lite: fix SRC_URI

[Burton, Ross]

Just in case anyone didn't knot, it's not temporarily down, it's dead for good.

Ross
On Fri, 2 Nov 2018 at 19:39, Martin Jansa  wrote:
>
> * alioth.debian.org is down
>   Connecting to alioth.debian.org (alioth.debian.org)|5.153.231.21|:443... 
> failed: No route to host.
>
> Signed-off-by: Martin Jansa 
> ---
>  meta-oe/recipes-support/pcsc-lite/pcsc-lite_1.8.22.bb | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/meta-oe/recipes-support/pcsc-lite/pcsc-lite_1.8.22.bb 
> b/meta-oe/recipes-support/pcsc-lite/pcsc-lite_1.8.22.bb
> index 90d58b00d9..10f724e6c8 100644
> --- a/meta-oe/recipes-support/pcsc-lite/pcsc-lite_1.8.22.bb
> +++ b/meta-oe/recipes-support/pcsc-lite/pcsc-lite_1.8.22.bb
> @@ -11,7 +11,7 @@ LICENSE_${PN}-spy-dev = "GPLv3+"
>  LIC_FILES_CHKSUM = "file://COPYING;md5=f38b3d1c7ef7fc2c8b6d20cd38efdc29"
>  DEPENDS = "udev"
>
> -SRC_URI = 
> "https://alioth.debian.org/frs/download.php/file/4225/pcsc-lite-${PV}.tar.bz2;
> +SRC_URI = "https://pcsclite.apdu.fr/files/${BP}.tar.bz2;
>  SRC_URI[md5sum] = "0ec103b1ef298d0c58d6ef6b00b9cf17"
>  SRC_URI[sha256sum] = 
> "6a358f61ed3b66a7f6e1f4e794a94c7be4c81b7a58ec360c33791e8d7d9bd405"
>
> --
> 2.17.1
>
> --
> ___
> Openembedded-devel mailing list
> Openembedded-devel@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-devel
-- 
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel

Re: [oe] [RFC meta-gnome][PATCH 01/16] sassc: add recipes for libsass-native and sassc-native.

[Burton, Ross]

On Mon, 29 Oct 2018 at 16:42, brendank310  wrote:
> +SRC_URI = "https://github.com/sass/${BPN}/archive/${PV}.tar.gz \
> +   "
> +SRC_URI[md5sum] = "4af3f4ffd3e8cac1cb1c90ebc2dd41b2"
> +SRC_URI[sha256sum] = 
> "5f61cbcddaf8e6ef7a725fcfa5d05297becd7843960f245197ebb655ff868770"

These tarballs are dynamically generated using git-archive so can
change over time.  As the maintainers are not uploading their own
static tarballs, you'll have to use git to fetch these.

> +S = "${WORKDIR}/${BPN}-${PV}"

This is the default.

> +inherit autotools pkgconfig native

Instead of having sassc-native and inheriting native, it's better to
have a sassc.bb and BBCLASSEXTEND=native to get native and target
recipes.  Bonus points for test-building the nativesdk variant too.

Ross
-- 
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel

Re: [oe] [RFC meta-gnome][PATCH 14/16] packagegroup-gnome3-base: add packagegroup for installing gnome3/gnome-shell

[Burton, Ross]

On Mon, 29 Oct 2018 at 16:43, brendank310  wrote:
> +LICENSE = "MIT"

Implied by packagegroup.bbclass.

> +LIC_FILES_CHKSUM = 
> "file://${COMMON_LICENSE_DIR}/MIT;md5=0835ade698e0bcf8506ecda2f7b4f302"

Not required.

> +RDEPENDS_${PN} = " \
> +packagegroup-core-x11 \
> +xinit \
> +atk \
> +at-spi2-core \
> +at-spi2-atk \
> +cairo \
> +gnome-shell \
> +gnome-bluetooth \
> +upower \
> +pulseaudio \
> +librsvg \
> +ibus \
> +gnome-desktop3 \
> +accountsservice \
> +gnome-settings-daemon \
> +"

A large proportion of those are libraries that will be pulled in
automatically (atk, cairo, librsvg, etc).  These can be removed.

Ross
-- 
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel

Re: [oe] [RFC meta-gnome][PATCH 16/16] gnome-tweak-tool: add recipe for the GNOME Tweak tool

[Burton, Ross]

On Tue, 30 Oct 2018 at 03:43, Khem Raj  wrote:
> > +LICENSE = "GPLv2"
> This seems should be GPL-3.0 as that’s what
> Being checksummed few lines below

> > +LIC_FILES_CHKSUM =
> > "file://LICENSES/GPL-3.0;md5=9eef91148a9b14ec7f9df333daebc746"

There's also a CCO license file in there which should be referred to
in LICENSE and checksummed.

Ross
-- 
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel

Re: [oe] [RFC meta-gnome][PATCH 09/16] gdm: add recipe for gdm (Gnome Desktop Manager)

[Burton, Ross]

On Mon, 29 Oct 2018 at 16:42, brendank310  wrote:
> +SRC_URI = 
> "git://gitlab.gnome.org/GNOME/gdm.git;protocol=http;branch=master;tag=3.30.1 \

Tarball.

> +FILES_${PN} += "${systemd_system_unitdir}"

Use systemd class.

> +FILES_${PN} += "${libdir}"

Breaks library packaging.

> +do_configure_prepend() {
> +   install -d ${S}/build-aux
> +   sed -i '/AC_CHECK_FILE/d' ${S}/configure.ac

Why?  If this is needed then do it as a patch.

Ross
-- 
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel

Re: [oe] [RFC meta-gnome][PATCH 14/16] packagegroup-gnome3-base: add packagegroup for installing gnome3/gnome-shell

[Burton, Ross]

On Mon, 29 Oct 2018 at 16:43, brendank310  wrote:
> +inherit packagegroup distro_features_check
> +
> +REQUIRED_DISTRO_FEATURES = "x11"

Everyone running GNOME 3 on Wayland will be surprised by this.  This
packagegroup should be *just* GNOME and then the image using it can
decide whether to pull in X11 or Weston.

Ross
-- 
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel

Re: [oe] [RFC meta-gnome][PATCH 15/16] gnome-shell-extensions: add recipe for gnome-shell-extensions

[Burton, Ross]

On Mon, 29 Oct 2018 at 16:43, brendank310  wrote:
> +SRC_URI = " \
> +   
> git://gitlab.gnome.org/GNOME/gnome-shell-extensions.git;protocol=http;branch=master;tag=3.30.1
>  \
> +  "

Use tarball.

> +RDEPENDS_gnome-shell = " \
> + gnome-shell \
> +"

This is why you use ${PN} ;)

Ross
-- 
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel

Re: [oe] [RFC meta-gnome][PATCH 04/16] accountsservice: add recipe for Accounts Service

[Burton, Ross]

On Mon, 29 Oct 2018 at 16:42, brendank310  wrote:
> +accountsservice: Remove internationalization
> +
> +  The i18n internationalization fails within the OE
> +  environment.

Probably because you don't depend on gettext-native.

> + context = g_option_context_new ("");
> +-g_option_context_set_translation_domain (context, GETTEXT_PACKAGE);
> + g_option_context_set_summary (context, _("Provides D-Bus interfaces 
> for querying and manipulating\nuser account information."));
> + g_option_context_add_main_entries (context, entries, NULL);
> + if (!g_option_context_parse (context, , , )) {
> diff --git a/meta-gnome/recipes-gnome/gnome3/accountsservice_git.bb 
> b/meta-gnome/recipes-gnome/gnome3/accountsservice_git.bb
> new file mode 100644
> index 0..a019a8c6d
> --- /dev/null
> +++ b/meta-gnome/recipes-gnome/gnome3/accountsservice_git.bb
> @@ -0,0 +1,24 @@
> +DESCRIPTION = "Accounts Service"
> +LICENSE = "GPLv3"
> +DEPENDS = " \
> +glib-2.0 \
> +gsettings-desktop-schemas \
> +polkit \
> +dbus \
> +  "
> +
> +LIC_FILES_CHKSUM = "file://COPYING;md5=d32239bcb673463ab874e80d47fae504"
> +
> +SRC_URI = 
> "git://anongit.freedesktop.org/accountsservice.git;protocol=git;branch=master 
> \

That's a mirror of
https://gitlab.freedesktop.org/accountsservice/accountsservice.

Also tarballs are at https://www.freedesktop.org/software/accountsservice/.

> +   file://0001-strip-out-intl.patch \
> +   "
> +
> +FILES_${PN} += "${systemd_system_unitdir}"

Use the systemd class instead.

> +FILES_${PN} += "${libdir}"

As discussed.

> +SRCREV="${AUTOREV}"

As discussed.

Ross
-- 
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel

Re: [oe] [RFC meta-gnome][PATCH 02/16] ibus: add recipe for ibus to support gnome-settings-daemon and gnome-shell

[Burton, Ross]

On Mon, 29 Oct 2018 at 16:41, brendank310  wrote:
> +DESCRIPTION = "Intelligent Input Bus for Linux/Unix"
> +LICENSE = "LGPLv2.1"
> +DEPENDS = "prelink \
> +   gtk+ \
> +  "

It depends on gtk+2?

> +S = "${WORKDIR}/${PN}-${PV}"

This is the default.

> +inherit autotools pkgconfig gtk-doc distro_features_check vala 
> gobject-introspection

distro_features_check isn't being used.

> +FILES_${PN} += "${libdir}"

Definitely wrong.

Ross
-- 
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel

Re: [oe] [RFC meta-gnome][PATCH 05/16] lcms2: add recipe for Little Color Management System

[Burton, Ross]

On Mon, 29 Oct 2018 at 16:42, brendank310  wrote:
> +inherit autotools pkgconfig distro_features_check

distro_features_check isn't being used.

But mainly, just update the existing recipe.

Ross
-- 
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel

Re: [oe] [RFC meta-gnome][PATCH 12/16] mutter: add recipe for mutter window manager

[Burton, Ross]

On Mon, 29 Oct 2018 at 16:43, brendank310  wrote:

> +do_install_append() {
> +   install -d ${D}/${datadir}/gir-1.0
> +   install ${B}/src/Meta-3.gir ${D}/${datadir}/gir-1.0
> +   install ${B}/cogl/cogl/Cogl-3.gir ${D}/${datadir}/gir-1.0
> +   install ${B}/cogl/cogl-pango/CoglPango-3.gir ${D}/${datadir}/gir-1.0
> +   install ${B}/clutter/clutter/Cally-3.gir ${D}/${datadir}/gir-1.0
> +   install ${B}/clutter/clutter/ClutterX11-3.gir ${D}/${datadir}/gir-1.0
> +   install ${B}/clutter/clutter/Clutter-3.gir ${D}/${datadir}/gir-1.0
> +}

Why is this needed?

Ross
-- 
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel

Re: [oe] [RFC meta-gnome][PATCH 13/16] gnome-shell: add recipe for gnome-shell.

[Burton, Ross]

On Mon, 29 Oct 2018 at 16:43, brendank310  wrote:
> +SRC_URI = 
> "git://gitlab.gnome.org/GNOME/gnome-shell.git;protocol=http;branch=master;tag=3.30.1
>  \
> +   file://0001-dont-detect-python.patch \
> +   "

Tarball is preferred.

> +RDEPENDS_gnome-shell += " python3-core python3-pygobject 
> gnome-settings-daemon gnome-bluetooth gdm "

Use ${PN} instead of gnome-shell so this works for multilib.

> +EXTRA_OEMESON += " -Dman=false -Dnetworkmanager=false "

Respecting the api-documentation DISTRO_FEATURE would be good here.
See manpages.bbclass.

> +FILES_${PN} += "${libdir}"

Almost definitely wrong.

> +FILES_${PN} += "${bindir}"

This is in FILES by default.

> +do_configure_prepend() {
> +   # Fixup the gsettings version
> +   sed -i 's^3.27.90^3.24.1^g' ${S}/meson.build

Do this as a patch so we can see *why*.

Ross
-- 
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel

Re: [oe] [RFC meta-gnome][PATCH 08/16] libgweather: add recipe for libgweather

[Burton, Ross]

On Mon, 29 Oct 2018 at 16:42, brendank310  wrote:
> +SRC_URI = 
> "git://gitlab.gnome.org/GNOME/libgweather.git;protocol=http;branch=gnome-3-28 
> \

Why not tarball (small, checksumed, easier to mirror)

> +FILES_${PN} += "${libdir}"

This breaks library packaging.

> +SRCREV="${AUTOREV}"

Never use this in mainline recipes.

Ross
-- 
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel

Re: [oe] [RFC meta-gnome][PATCH 07/16] geocode-glib: add recipe for geocode-glib library

[Burton, Ross]

On Tue, 30 Oct 2018 at 03:43, Khem Raj  wrote:
> > +SRC_URI = "git://
> > gitlab.gnome.org/GNOME/geocode-glib.git;protocol=http;branch=master;tag=3.26.0
>
> hmm tags are floating kind of commits so they would result in checking
> remote repo on every fetch task it would be better to use a hard coded SHA

Or the tarball, https://download.gnome.org/sources/geocode-glib/3.26/

Note that gnome.bbclass pretty much sets up SRC_URI for you.

Ross
-- 
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel

Re: [oe] [RFC meta-gnome][PATCH 10/16] dconf-native: add dconf-native recipe

[Burton, Ross]

On Mon, 29 Oct 2018 at 19:30, Khem Raj  wrote:
>> I had initially tried to get the native recipe integrated into it, by
>> inheriting the native class but was unable to get that to work. Using the
>> above, I get the following:
>>
>> ERROR: Required build target 'gdm' has no buildable providers.
>> Missing or unbuildable dependency chain was: ['gdm', 'dconf-native',
>> 'glib-2.0-utils-native']
>>
>> Any thoughts on how to resolve this? Should I also be providing a
>> glib-2.0-utils-native package?

I'm assuming you meant BBCLASSEXTEND and not an explicit inherit native.

> Just add that dependency to target only recipe via class-target override 
> perhaps

To clarify, the dependency comes from the gsettings.bbclass.  This
dependency should be target-only, so use a class-target override.

Ross
-- 
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel

Re: [oe] [RFC meta-gnome][PATCH 03/16] gjs: add a recipe for gjs (Gnome JavaScript engine)

[Burton, Ross]

On Mon, 29 Oct 2018 at 16:42, brendank310  wrote:

> +do_configure_prepend() {
> +   export 
> GI_DATADIR="${RECIPE_SYSROOT_NATIVE}${datadir}/gobject-introspection-1.0"
> +   sed -i 's#mozjs-17#mozjs-52#g' ${S}/configure.ac
> +}

Personally I prefer patches to sed in do_configure, as nobody will
notice when the sed isn't required anymore and the point of the change
isn't always obvious.

Ross
-- 
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel

Re: [oe] [RFC meta-gnome][PATCH 10/16] dconf-native: add dconf-native recipe

[Burton, Ross]

There's already a dconf in meta-gnome, so just add
BBCLASSEXTEND="native nativesdk".

Ross
On Mon, 29 Oct 2018 at 16:43, brendank310  wrote:
>
> From: Brendan Kerrigan 
>
> gdm recipe requires a native dconf tool.
>
> Signed-off-by: Brendan Kerrigan 
> ---
>  .../dconf/dconf-native_0.28.0.bb  | 19 +++
>  1 file changed, 19 insertions(+)
>  create mode 100644 meta-gnome/recipes-gnome/dconf/dconf-native_0.28.0.bb
>
> diff --git a/meta-gnome/recipes-gnome/dconf/dconf-native_0.28.0.bb 
> b/meta-gnome/recipes-gnome/dconf/dconf-native_0.28.0.bb
> new file mode 100644
> index 0..ee78fbb66
> --- /dev/null
> +++ b/meta-gnome/recipes-gnome/dconf/dconf-native_0.28.0.bb
> @@ -0,0 +1,19 @@
> +SUMMARY = "configuation database system"
> +LICENSE = "LGPLv2.1"
> +LIC_FILES_CHKSUM = "file://COPYING;md5=2d5025d4aa3495befef8f17206a5b0a1"
> +SECTION = "x11/gnome"
> +
> +SRC_URI[archive.md5sum] = "81faa8e68e5ea71ff0ee75050fc0759c"
> +SRC_URI[archive.sha256sum] = 
> "61d3b3865ef58b729c3b39aa0979f886c014aa8362f93dcfc74bf5648ed9c742"
> +
> +DEPENDS = "dbus glib-2.0 intltool-native"
> +
> +GNOMEBASEBUILDCLASS = "meson"
> +
> +inherit gnomebase gsettings bash-completion vala native
> +
> +FILES_${PN} += " \
> +${datadir}/dbus-1 \
> +${libdir}/gio/modules/*.so \
> +${bindir}/dconf \
> +"
> --
> 2.17.1
>
> --
> ___
> Openembedded-devel mailing list
> Openembedded-devel@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-devel
-- 
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel

Re: [oe] [PATCH v3] opencl-headers: Initial recipe for OpenCL headers

[Burton, Ross]

On Tue, 16 Oct 2018 at 05:43, Ankit Navik  wrote:

> +do_install () {
> +   install -d ${D}${includedir}/CL/
> +   install -m 0644 -D -t ${D}${includedir}/CL ${S}/CL/*.h
> +}

-D to install is 'create directories' which you've already done in the
previous line, so that can be removed.

If you're removing -D then a more idiomatic form would be:

+   install -d ${D}${includedir}/CL/
+   install -m 0644 ${S}/CL/*.h ${D}${includedir}/CL

Ross
-- 
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel

Re: [oe] [PATCH] opencl-headers: Initial recipe for OpenCL headers

[Burton, Ross]

On Mon, 15 Oct 2018 at 20:01, Denys Dmytriyenko  wrote:
> > > > > > > > > +do_install () {
> > > > > > > > > + install -d ${D}${includedir}/CL/
> > > > > > > > > + for f in ${S}/CL/*.h; do
> > > > > > > > > + install -m 0644 $f ${D}${includedir}/CL/
> > > > >
> > > > > Single file install? Not very optimized...
> > >
> > > > Its not a single file, Installing all the header files.
> > >
> > > It's a single file install in a for loop, hence my comment about being
> > > unoptimal. Why not use "cp *.h"?
> >
> >  I agree its suboptimal use here. May be
> >
> > install [OPTION]... -t DIRECTORY SOURCE
> >
> > could be tamed to make it better.
> > however cp messes the file permissions up if not used with right opts.
> > So I would not prefer it unless used with right
> > options to respect the file perms. Install does it correctly,
>
> Agree, cp would require passing correct options, but there are plenty of
> examples alreay.

If we're bikeshedding a micro-optimisation then surely this is optimal:

  install -m 0644 -D -t ${D}${includedir}/CL ${S}/CL/*.h

That combines the mkdir and cp in one command.

Ross
-- 
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel

Re: [oe] [meta-oe][PATCH 1/5] directfb: add x11 to REQUIRED_DISTRO_FEATURES

[Burton, Ross]

DirectFB depending on X11 would be *very wrong*.

Ross
On Fri, 12 Oct 2018 at 18:52, Vesa Jääskeläinen  wrote:
>
> On 12/10/2018 18.26, Armin Kuster wrote:
>
> > package has depends on vlc and gtk
> >
> > Signed-off-by: Armin Kuster 
> > ---
> >   meta-oe/recipes-graphics/directfb/directfb.inc | 3 ++-
> >   1 file changed, 2 insertions(+), 1 deletion(-)
> >
> > diff --git a/meta-oe/recipes-graphics/directfb/directfb.inc 
> > b/meta-oe/recipes-graphics/directfb/directfb.inc
> > index 96aa311..cf8f19a 100644
> > --- a/meta-oe/recipes-graphics/directfb/directfb.inc
> > +++ b/meta-oe/recipes-graphics/directfb/directfb.inc
> > @@ -32,7 +32,8 @@ LDFLAGS_append_arm = 
> > "${@bb.utils.contains('DISTRO_FEATURES', 'ld-is-gold', ' -f
> >
> >   BINCONFIG = "${bindir}/directfb-config"
> >
> > -inherit autotools binconfig-disabled pkgconfig
> > +inherit autotools binconfig-disabled pkgconfig distro_features_check
> > +REQUIRED_DISTRO_FEATURES = "x11"
> >
> Wrong method?
>
> Quote from:
> https://github.com/DirectFB/directfb
>
> "Optionally, depending on the configuration you want:
>
> FBDev
>   - Linux kernel 2.2.x or newer with working frame buffer device
> (check /proc/fb) for the fbdev system.
>
> SDL
>   - libSDL (Simple Direct Media Layer) for the sdl system.
>
> X11
>   - libX11 (X11 client library) for the X11 system (libx11-dev and 
> libxext-dev packages)."
>
> --
> ___
> Openembedded-devel mailing list
> Openembedded-devel@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-devel
-- 
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel

Re: [oe] [PATCH] postgresql: use util-linux's uuid

[Burton, Ross]

Sorry!

On 31 August 2018 at 17:35, Khem Raj  wrote:
> its already in see
> http://git.openembedded.org/meta-openembedded/commit/?id=140bf68e37
>
> On Fri, Aug 31, 2018 at 7:42 AM Ross Burton  wrote:
>>
>> Postgreqsql was configured to use ossp-uuid but ossp-uuid is dead and 
>> everyone
>> will be building util-linux anyway, so use the libuuid.so from there.
>>
>> Confusing the option is called e2fs because the library originated in 
>> e2fsprogs.
>>
>> Signed-off-by: Ross Burton 
>> ---
>>  meta-oe/recipes-dbs/postgresql/postgresql.inc | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/meta-oe/recipes-dbs/postgresql/postgresql.inc 
>> b/meta-oe/recipes-dbs/postgresql/postgresql.inc
>> index 1301060ee5..44a1b30fe0 100644
>> --- a/meta-oe/recipes-dbs/postgresql/postgresql.inc
>> +++ b/meta-oe/recipes-dbs/postgresql/postgresql.inc
>> @@ -59,7 +59,7 @@ PACKAGECONFIG ??= "${enable_pam} openssl python uuid 
>> libxml tcl nls libxml perl"
>>  PACKAGECONFIG[pam] = "--with-pam,--without-pam,libpam,"
>>  PACKAGECONFIG[openssl] = "--with-openssl,--without-openssl,openssl,"
>>  PACKAGECONFIG[python] = "--with-python,--without-python,python,python"
>> -PACKAGECONFIG[uuid] = "--with-ossp-uuid,--without-ossp-uuid,ossp-uuid,"
>> +PACKAGECONFIG[uuid] = "--with-uuid=e2fs,--without-uuid,util-linux,"
>>  PACKAGECONFIG[tcl] = "--with-tcl 
>> --with-tclconfig=${STAGING_BINDIR_CROSS},--without-tcl,tcl tcl-native,"
>>  PACKAGECONFIG[nls] = "--enable-nls,--disable-nls,,"
>>  PACKAGECONFIG[libxml] = "--with-libxml,--without-libxml,libxml2,libxml2"
>> --
>> 2.11.0
>>
>> --
>> ___
>> Openembedded-devel mailing list
>> Openembedded-devel@lists.openembedded.org
>> http://lists.openembedded.org/mailman/listinfo/openembedded-devel
-- 
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel

Re: [oe] [PATCH] python-protobuf: disable clean

[Burton, Ross]

Erm, yeah, that would be a rebase gone bad.

Thanks for spotting ;)
Ross

On 31 August 2018 at 15:45, Martin Jansa  wrote:
> Isn't this already covered by:
> http://git.openembedded.org/meta-openembedded/commit/?id=19aeaf028f6819e5fa705593d4bcdbf0b98143e0
> http://git.openembedded.org/meta-openembedded/commit/?id=e65b1c4ebbbf2174125e7c659b908dd0f46c4509
> https://patchwork.openembedded.org/patch/154300/
> ?
>
> On Fri, Aug 31, 2018 at 4:42 PM Ross Burton  wrote:
>>
>> The distutils class does a 'setup.py clean' but this breaks the protobuf
>> build:
>>
>> | Can't find required file: ../src/google/protobuf/descriptor.proto
>> | Generating google/protobuf/descriptor_pb2.py...
>> | ERROR: python3 setup.py build_ext execution failed.
>>
>> Disable the clean to work around this.
>>
>> Signed-off-by: Ross Burton 
>> ---
>>  meta-python/recipes-devtools/python/python-protobuf.inc | 2 ++
>>  1 file changed, 2 insertions(+)
>>
>> diff --git a/meta-python/recipes-devtools/python/python-protobuf.inc
>> b/meta-python/recipes-devtools/python/python-protobuf.inc
>> index 6a0568ae62..421775d394 100644
>> --- a/meta-python/recipes-devtools/python/python-protobuf.inc
>> +++ b/meta-python/recipes-devtools/python/python-protobuf.inc
>> @@ -25,3 +25,5 @@ RDEPENDS_${PN} += " \
>>
>>  # For usage in other recipies when compiling protobuf files (e.g. by
>> grpcio-tools)
>>  BBCLASSEXTEND = "native"
>> +
>> +CLEANBROKEN = "1"
>> --
>> 2.11.0
>>
>> --
>> ___
>> Openembedded-devel mailing list
>> Openembedded-devel@lists.openembedded.org
>> http://lists.openembedded.org/mailman/listinfo/openembedded-devel
-- 
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel

Re: [oe] [OE-core] devtool add recipe with no srctree / fetchuri?

[Burton, Ross]

devtool add's primary convenience is how it can examine the source and
write the LICENSE correctly, the correct inherits, etc.  If you're
just going to install a few files then just write a recipe from
scratch.

Ross

On 30 July 2018 at 15:10, Adam Lee  wrote:
> Is it possible to run 'devtool add [recipe-name]' without 'srctree' or
> 'fetchuri'?
> I just want to add a simple recipe with a few files to be installed on the
> target file system.
> I can directly add a file in my meta-layer, but devtool is probably the more
> correct approach.
>
> Adam
>
> --
> ___
> Openembedded-core mailing list
> openembedded-c...@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core
>
-- 
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel

Re: [oe] [meta-oe][PATCH 1/1] kernel-selftest: Add a recipe on kernel selftest

[Burton, Ross]

On 13 July 2018 at 15:06, Hongzhi.Song  wrote:
>+LIC_FILES_CHKSUM = "file://COPYING;md5=d7810fab7487fb0aad327b76f1be7cd7 \

Why are you shipping your own copy of the kernel's COPYING file even
though you copy another in that prefunc?

Isn't it possible to just depend on kernel-source and build directly
from the kernel source tree?

> +# for bpf and vm
> +DEPENDS = " \
> +elfutils \
> +libcap \
> +libcap-ng \
> +fuse \
> +util-linux \
> +rsync-native \
> +"

Really not convinced these dependencies are accurate.

> +TEST_LIST = "bpf \
> + vm \
> +"

You're not listing memfd in here, but that is the only place which
uses fuse as far as I can tell.

My suggestion is to trim the DEPENDS back to the core minimum and use
PACKAGECONIG to select what directories get built. This means you can
have optional test suites where the dependencies are not in oe-core
(fuse for memfd, for example), and get the right RDEPENDS too.

> +oe_runmake -C ${S}/tools/testing/selftests/${i} 
> INSTALL_PATH=${D}/opt/kselftest/${i} install

FHS says /opt is for sysadmin-installed tools that are not package
managed.  You're building a package.  You're also building a package
which is essentially ptest.  I'd say inherit ptest, write a runner,
and put all the binaries in $PTESTDIR.

Ross
-- 
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel

Re: [oe] [meta-python][PATCH 2/2] python3-lxml, python3-pandas, python3-protobuf: Set CLEANBROKEN

[Burton, Ross]

I've just sent a patch for oe-core to improve how it calls clean,
which fixes lxml.

Pandas can be fixed by depending on cython, patch sent.

protobuf is broken, we still need the cleanbroken but I plan to do the
same for python2 so I've just sent a patch to add it to the inc file.

Ross

On 9 July 2018 at 10:52, Burton, Ross  wrote:
> The lxml failure can be fixed with a tweak to the class, so I'll run
> the tweak through all of meta-python to see if it regresses anything
> else.  Please hold this off until I report back.
>
> Ross
>
> On 8 July 2018 at 09:06, Khem Raj  wrote:
>> The distutils class got a clean via "setup.py clean", but these
>> recipes doesn't support this yet so disable clean target during
>> configure
>>
>> Signed-off-by: Khem Raj 
>> ---
>>  meta-python/recipes-devtools/python/python3-lxml_4.2.3.bb | 1 +
>>  meta-python/recipes-devtools/python/python3-pandas_0.23.1.bb  | 1 +
>>  meta-python/recipes-devtools/python/python3-protobuf_3.6.0.bb | 1 +
>>  3 files changed, 3 insertions(+)
>>
>> diff --git a/meta-python/recipes-devtools/python/python3-lxml_4.2.3.bb 
>> b/meta-python/recipes-devtools/python/python3-lxml_4.2.3.bb
>> index ff4bc7faad..b95d7bae71 100644
>> --- a/meta-python/recipes-devtools/python/python3-lxml_4.2.3.bb
>> +++ b/meta-python/recipes-devtools/python/python3-lxml_4.2.3.bb
>> @@ -1,2 +1,3 @@
>>  inherit setuptools3
>>  require python-lxml.inc
>> +CLEANBROKEN = "1"
>> diff --git a/meta-python/recipes-devtools/python/python3-pandas_0.23.1.bb 
>> b/meta-python/recipes-devtools/python/python3-pandas_0.23.1.bb
>> index b5dd5e0924..c1e57189cf 100644
>> --- a/meta-python/recipes-devtools/python/python3-pandas_0.23.1.bb
>> +++ b/meta-python/recipes-devtools/python/python3-pandas_0.23.1.bb
>> @@ -1,2 +1,3 @@
>>  inherit setuptools3
>>  require python-pandas.inc
>> +CLEANBROKEN = "1"
>> diff --git a/meta-python/recipes-devtools/python/python3-protobuf_3.6.0.bb 
>> b/meta-python/recipes-devtools/python/python3-protobuf_3.6.0.bb
>> index 781d1dc4da..53d5528c4b 100644
>> --- a/meta-python/recipes-devtools/python/python3-protobuf_3.6.0.bb
>> +++ b/meta-python/recipes-devtools/python/python3-protobuf_3.6.0.bb
>> @@ -1,2 +1,3 @@
>>  inherit setuptools3
>>  require python-protobuf.inc
>> +CLEANBROKEN = "1"
>> --
>> 2.18.0
>>
>> --
>> ___
>> Openembedded-devel mailing list
>> Openembedded-devel@lists.openembedded.org
>> http://lists.openembedded.org/mailman/listinfo/openembedded-devel
-- 
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel

Re: [oe] [meta-python][PATCH 2/2] python3-lxml, python3-pandas, python3-protobuf: Set CLEANBROKEN

[Burton, Ross]

The lxml failure can be fixed with a tweak to the class, so I'll run
the tweak through all of meta-python to see if it regresses anything
else.  Please hold this off until I report back.

Ross

On 8 July 2018 at 09:06, Khem Raj  wrote:
> The distutils class got a clean via "setup.py clean", but these
> recipes doesn't support this yet so disable clean target during
> configure
>
> Signed-off-by: Khem Raj 
> ---
>  meta-python/recipes-devtools/python/python3-lxml_4.2.3.bb | 1 +
>  meta-python/recipes-devtools/python/python3-pandas_0.23.1.bb  | 1 +
>  meta-python/recipes-devtools/python/python3-protobuf_3.6.0.bb | 1 +
>  3 files changed, 3 insertions(+)
>
> diff --git a/meta-python/recipes-devtools/python/python3-lxml_4.2.3.bb 
> b/meta-python/recipes-devtools/python/python3-lxml_4.2.3.bb
> index ff4bc7faad..b95d7bae71 100644
> --- a/meta-python/recipes-devtools/python/python3-lxml_4.2.3.bb
> +++ b/meta-python/recipes-devtools/python/python3-lxml_4.2.3.bb
> @@ -1,2 +1,3 @@
>  inherit setuptools3
>  require python-lxml.inc
> +CLEANBROKEN = "1"
> diff --git a/meta-python/recipes-devtools/python/python3-pandas_0.23.1.bb 
> b/meta-python/recipes-devtools/python/python3-pandas_0.23.1.bb
> index b5dd5e0924..c1e57189cf 100644
> --- a/meta-python/recipes-devtools/python/python3-pandas_0.23.1.bb
> +++ b/meta-python/recipes-devtools/python/python3-pandas_0.23.1.bb
> @@ -1,2 +1,3 @@
>  inherit setuptools3
>  require python-pandas.inc
> +CLEANBROKEN = "1"
> diff --git a/meta-python/recipes-devtools/python/python3-protobuf_3.6.0.bb 
> b/meta-python/recipes-devtools/python/python3-protobuf_3.6.0.bb
> index 781d1dc4da..53d5528c4b 100644
> --- a/meta-python/recipes-devtools/python/python3-protobuf_3.6.0.bb
> +++ b/meta-python/recipes-devtools/python/python3-protobuf_3.6.0.bb
> @@ -1,2 +1,3 @@
>  inherit setuptools3
>  require python-protobuf.inc
> +CLEANBROKEN = "1"
> --
> 2.18.0
>
> --
> ___
> Openembedded-devel mailing list
> Openembedded-devel@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-devel
-- 
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel

Re: [oe] [meta-oe][PATCH 18/20] check: add recipe

[Burton, Ross]

Already in oe-core: meta/recipes-support/libcheck/libcheck_0.12.0.bb

Ross

On 24 June 2018 at 20:18, Khem Raj  wrote:
> It is a C unittest framework
>
> Signed-off-by: Khem Raj 
> ---
>  meta-oe/recipes-test/check/check_git.bb | 21 +
>  1 file changed, 21 insertions(+)
>  create mode 100644 meta-oe/recipes-test/check/check_git.bb
>
> diff --git a/meta-oe/recipes-test/check/check_git.bb 
> b/meta-oe/recipes-test/check/check_git.bb
> new file mode 100644
> index 00..e7bfece3cf
> --- /dev/null
> +++ b/meta-oe/recipes-test/check/check_git.bb
> @@ -0,0 +1,21 @@
> +# Copyright (C) 2018 Khem Raj 
> +# Released under the MIT license (see COPYING.MIT for the terms)
> +
> +DESCRIPTION = "A unit testing framework for C"
> +HOMEPAGE = "https://libcheck.github.io/check/;
> +LICENSE = "LGPL-2.1"
> +LIC_FILES_CHKSUM = 
> "file://COPYING.LESSER;md5=2d5025d4aa3495befef8f17206a5b0a1"
> +
> +PV = "0.12.0+git${SRCPV}"
> +
> +SRCREV = "285d04b3d461ba68dc39e0f9e847784fb6064bb3"
> +
> +SRC_URI = "git://github.com/libcheck/check"
> +
> +S = "${WORKDIR}/git"
> +
> +inherit cmake
> +
> +do_install_append() {
> +rm -rf ${D}${exec_prefix}/cmake
> +}
> --
> 2.18.0
>
> --
> ___
> Openembedded-devel mailing list
> Openembedded-devel@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-devel
-- 
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel

Re: [oe] Can't see my patches on lists.openembedded.org

[Burton, Ross]

Yes, you have to subscribe, or your posts will be moderated and will
be delayed until the queue is reviewed.

Ross

On 21 June 2018 at 23:45, Henry Chang  wrote:
> Hi guys,
>
> Does the mailing list server lists.openembedded.org have any delays?
> I've sent several patches to it but couldn't see any results in the
> archive. Or do I have to subscribe to the list?
>
> Regards,
>
> Henry
> --
> ___
> Openembedded-devel mailing list
> Openembedded-devel@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-devel
-- 
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel

Re: [oe] [meta-java] maintainer status

[Burton, Ross]

On 13 June 2018 at 06:42,
 wrote:
> Another question just came to my mind:
> How should I deal with my own patches?
> Am I "allowed" to apply them myself or should another maintainer do
> this? If I should do it on my own: How long should they "stay" on the
> mailinglist before?

If they're trivial I can't see a problem with post-and-push.  For
anything that isn't pretty obvious, they should have a bit of time on
the list.

Ross
-- 
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel

Re: [oe] [meta-java][PATCH 0/4] README: update to reflect current status

[Burton, Ross]

The same happens for Richard Purdie for me, I suspect the problem is
that you're sending mail from your own machine (or some other relay)
but skidata.com has SPF configured and that machine isn't listed.

Ross

On 12 June 2018 at 15:51,
 wrote:
> Hi Maxin,
>
> On 06/12/2018 04:38 PM, Maxin B. John wrote:
>> Hi Richard,
>>
>> On Tue, Jun 12, 2018 at 04:33:27PM +0200, 
>> openembedded-devel-boun...@lists.openembedded.org wrote:
>>> Update the README file to reflect current maintainers, dependencies and 
>>> patch
>>> formatting/sending guidlines.
>>>
>>> Mario Domenech Goulart (1):
>>>   README: Remove Mario Goulart from the list of maintainers
>>>
>>> Richard Leitner (3):
>>>   README: fix dependent branch names
>>>   README: add note on how to send a patch series with cover-letter
>>>   README: add maintainer: Richard Leitner
>>>
>>>  README | 20 ++--
>>>  1 file changed, 14 insertions(+), 6 deletions(-)
>>
>> For some reasons, the "Author" of patches are not clearly set. It shows up 
>> like - "openembedded-devel-boun...@lists.openembedded.org",
>> instead of your mail-id.
>
> Just wrote you an email because of that. It's strange because the
> answer from Otavio to my [PATCH 3/4] parses the "From:" correctly.
> Also my "raw patches" which I passed to "git send-email" seem to be fine...
>
> Do you have any ideas what causes this problem?
>
> regards;Richard.L
> --
> ___
> Openembedded-devel mailing list
> Openembedded-devel@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-devel
-- 
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel

Re: [oe] Avoid version going backwards for beta versions

[Burton, Ross]

On 31 May 2018 at 11:28, André Draszik  wrote:
> In debian based distros, the tilde will always cause sorting to be lower
> than the version specified before the tilde, so e.g.
>
> fluidsynth-2.0.0~beta.1
>
> works as expected, and I *think* this latter approach works in OE, too.

Yes, RPM4/dpkg/opkg all support this syntax, so this does work in OE.

Ross
-- 
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel

Re: [oe] [OE-core] meta-openembedded maintainer ship change.

[Burton, Ross]

Thanks Armin for all your hard work!

Ross

On 22 May 2018 at 16:40, akuster808  wrote:
> Hello all,
>
> After much thought, I have decided to step away from being the
> meta-openembedded maintainer, patch wrangler and builder.  Khem Raj has
> kindly stepped up to continue these activities. Maintaining this was
> consuming too much of my free time and I need to focus on other things
> in the community.
>
> Thanks for the opportunity to have served you.
>
> Kind regards,
>
> Armin
>
>
> --
> ___
> Openembedded-core mailing list
> openembedded-c...@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core
-- 
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel

Re: [oe] [meta-java][PATCHv2] jdepend: Retrieve source from Git rather than tarball

[Burton, Ross]

On 16 May 2018 at 11:52, Burton, Ross <ross.bur...@intel.com> wrote:
> On 16 May 2018 at 10:53, André Draszik <g...@andred.net> wrote:
>> Would it be useful to add a check to patchreview.py (or elsewhere?) to
>> reject patches that contain references to github archive URLs in the recipe?
>
> patchtest.  Yes, it would!

Bug files: https://bugzilla.yoctoproject.org/show_bug.cgi?id=12752

If anyone wants to explore patchtest, this is a good starting point.

Ross
-- 
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel

Re: [oe] [meta-java][PATCHv2] jdepend: Retrieve source from Git rather than tarball

[Burton, Ross]

On 16 May 2018 at 10:53, André Draszik  wrote:
> Would it be useful to add a check to patchreview.py (or elsewhere?) to
> reject patches that contain references to github archive URLs in the recipe?

patchtest.  Yes, it would!

Ross
-- 
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel

Re: [oe] [OE-core] [RFT] GCC 8.1

[Burton, Ross]

I threw the branch at the Yocto Project autobuilder today, produced a
number of failures:

http://errors.yoctoproject.org/Errors/Latest//?filter=b23dba19607412c8cc7d267d95354d65f5631088=commit

Ross

On 5 May 2018 at 01:26, Khem Raj  wrote:
> Hi All
>
> As you might have noticed that gcc 8.1 was released this week, I am
> calling out for some testing help on testing branch so we can weed out
> issues you might see in your setups. so if you have your
> builders idling over weekend, then you know what they can do this weekend :)
>
> Highlighted changes are
>
> https://gcc.gnu.org/gcc-8/changes.html
>
> and porting doc is
>
> https://gcc.gnu.org/gcc-8/porting_to.html
>
> The branch is here
>
> http://git.openembedded.org/openembedded-core-contrib/log/?h=kraj/gcc-8
>
> Its uptodate on top of current master oe-core
>
> May fourth be with you !!
>
> Cheers!
>
> -Khem
> --
> ___
> Openembedded-core mailing list
> openembedded-c...@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core
-- 
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel

Re: [oe] [meta-java][PATCHv2] jdepend: Retrieve source from Git rather than tarball

[Burton, Ross]

http://lists.openembedded.org/pipermail/openembedded-devel/2017-September/114916.html,
fwiw

Ross

On 4 May 2018 at 19:37, Mike Crowe  wrote:

> When Bitbake downloads jdepend-2.9.1.zip itself and I download
> https://github.com/clarkware/jdepend/blob/master/dist/jdepend-2.9.1.zip ,
> the calculated hashes don't match the ones included in the recipe.
>
> The hashes were last changed in commit
> dd5c43fca8289b8795a9214aee616775e1493109 on 1st March, but GitHub claims
> that the file being downloaded was published on 20th January, so I can't
> explain why they are wrong.
>
> It seems that we can't really rely on these tarballs to remain unchanged,
> so let's download the Git hash that corresponds to v2.9.1 instead. This
> should always remain valid.
>
> Cc: André Draszik 
> Cc: Khem Raj 
> Signed-off-by: Mike Crowe 
> ---
>  recipes-core/jdepend/jdepend_2.9.1.bb | 7 +++
>  1 file changed, 3 insertions(+), 4 deletions(-)
>
> I'll let whoever wants to merge this decide whether to take v1 with
> the updated hashes or v2 using the Git repository.
>
> diff --git a/recipes-core/jdepend/jdepend_2.9.1.bb b/recipes-core/jdepend/
> jdepend_2.9.1.bb
> index 5f09a8b..dfbf493 100644
> --- a/recipes-core/jdepend/jdepend_2.9.1.bb
> +++ b/recipes-core/jdepend/jdepend_2.9.1.bb
> @@ -6,7 +6,9 @@ LIC_FILES_CHKSUM = "file://LICENSE;md5=
> f5777d32a7709d558c2877d4a6616230"
>
>  HOMEPAGE = "https://github.com/clarkware/jdepend;
>
> -SRC_URI = "https://github.com/clarkware/jdepend/archive/${PV}.zip;
> downloadfilename=${BP}.zip"
> +SRC_URI = "git://github.com/clarkware/jdepend"
> +SRCREV = "57980590313a5dbde236a3eb2c8958e9e53e6a10"
> +S = "${WORKDIR}/git"
>
>  inherit java-library
>
> @@ -18,7 +20,4 @@ do_compile() {
>fastjar cf ${JARFILENAME} -C build .
>  }
>
> -SRC_URI[md5sum] = "9b91efe1d770e023893f89f4dde8434e"
> -SRC_URI[sha256sum] = "536b5082d64e4f4514ce30178f
> 36c7a31b34d969275f278f72e522e7f7c9"
> -
>  BBCLASSEXTEND = "native"
> --
> 2.11.0
>
>
> --
> ___
> Openembedded-devel mailing list
> Openembedded-devel@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-devel
>
-- 
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel

Re: [oe] [oe-commits] [openembedded-core] 05/06: package.bbclass: Include dbgsrc for static libs

[Burton, Ross]

FWIW, libsdl2 builds fine for me with current sumo branch.

Ross

On 20 April 2018 at 13:03, Martin Jansa  wrote:
> I haven't dig around this much, but some of my builds are now failing with:
>
> ERROR: libsdl2-webos-2.0.4-86-r22 do_package: dwarfsrcfiles failed with
> exit code 1 (cmd was 'dwarfsrcfiles' 'libsdl2-webos/2.0.4-86-r22/
> package/usr/lib/libSDL2main.a'):
> dwarfsrcfiles: libsdl2-webos/2.0.4-86-r22/package/usr/lib/libSDL2main.a:
> not a valid ELF file
> ERROR: libsdl2-webos-2.0.4-86-r22 do_package: Function failed:
> split_and_strip_files
>
> It's different version of libsdl2 than what's in oe-core now and the recipe
> for it might be a bit broken.
>
> $ file package/usr/lib/libSDL2main.a
> package/usr/lib/libSDL2main.a: current ar archive
>
> $ recipe-sysroot-native/usr/bin/dwarfsrcfiles package/usr/lib/libSDL2main.a
> dwarfsrcfiles: package/usr/lib/libSDL2main.a: not a valid ELF file
>
> $ ar x ../package/usr/lib/libSDL2main.a
>
> contains only:
> SDL_dummy_main.lo
>
> Should we try a bit harder to check if the .a contains static library? In
> the meantime I'll check what's going on in libsdl2-webos build and if the
> same happens in oe-core libsdl2.
>
> Regards,
>
> On Thu, Apr 19, 2018 at 3:45 PM,  wrote:
>
>> This is an automated email from the git hooks/post-receive script.
>>
>> rpurdie pushed a commit to branch master
>> in repository openembedded-core.
>>
>> commit eefa5ba35663fabe1f3f8cf7f1ff126d51240613
>> Author: Ola x Nilsson 
>> AuthorDate: Thu Apr 19 13:17:30 2018 +0200
>>
>> package.bbclass: Include dbgsrc for static libs
>>
>> The debugsource must be added from the package providing the static
>> lib, because any package using that lib does not have access to the
>> source code.
>>
>> Fixes [YOCTO #12558]
>>
>> Signed-off-by: Ola x Nilsson 
>> Signed-off-by: Ross Burton 
>> ---
>>  meta/classes/package.bbclass | 44 ++
>> ++
>>  1 file changed, 32 insertions(+), 12 deletions(-)
>>
>> diff --git a/meta/classes/package.bbclass b/meta/classes/package.bbclass
>> index 7978307..fff7ceb 100644
>> --- a/meta/classes/package.bbclass
>> +++ b/meta/classes/package.bbclass
>> @@ -344,6 +344,20 @@ def parse_debugsources_from_dwarfs
>> rcfiles_output(dwarfsrcfiles_output):
>>
>>  return debugfiles.keys()
>>
>> +def append_source_info(file, sourcefile, d):
>> +cmd = "'dwarfsrcfiles' '%s'" % (file)
>> +(retval, output) = oe.utils.getstatusoutput(cmd)
>> +# 255 means a specific file wasn't fully parsed to get the debug file
>> list, which is not a fatal failure
>> +if retval != 0 and retval != 255:
>> +bb.fatal("dwarfsrcfiles failed with exit code %s (cmd was %s)%s"
>> % (retval, cmd, ":\n%s" % output if output else ""))
>> +
>> +debugsources = parse_debugsources_from_dwarfsrcfiles_output(output)
>> +# filenames are null-separated - this is an artefact of the previous
>> use
>> +# of rpm's debugedit, which was writing them out that way, and the
>> code elsewhere
>> +# is still assuming that.
>> +debuglistoutput = '\0'.join(debugsources) + '\0'
>> +open(sourcefile, 'a').write(debuglistoutput)
>> +
>>
>>  def splitdebuginfo(file, debugfile, debugsrcdir, sourcefile, d):
>>  # Function to split a single file into two components, one is the
>> stripped
>> @@ -369,18 +383,7 @@ def splitdebuginfo(file, debugfile, debugsrcdir,
>> sourcefile, d):
>>
>>  # We need to extract the debug src information here...
>>  if debugsrcdir:
>> -cmd = "'dwarfsrcfiles' '%s'" % (file)
>> -(retval, output) = oe.utils.getstatusoutput(cmd)
>> -# 255 means a specific file wasn't fully parsed to get the debug
>> file list, which is not a fatal failure
>> -if retval != 0 and retval != 255:
>> -bb.fatal("dwarfsrcfiles failed with exit code %s (cmd was
>> %s)%s" % (retval, cmd, ":\n%s" % output if output else ""))
>> -
>> -debugsources = parse_debugsources_from_dwarfs
>> rcfiles_output(output)
>> -# filenames are null-separated - this is an artefact of the
>> previous use
>> -# of rpm's debugedit, which was writing them out that way, and
>> the code elsewhere
>> -# is still assuming that.
>> -debuglistoutput = '\0'.join(debugsources) + '\0'
>> -open(sourcefile, 'a').write(debuglistoutput)
>> +append_source_info(file, sourcefile, d)
>>
>>  bb.utils.mkdirhier(os.path.dirname(debugfile))
>>
>> @@ -936,6 +939,15 @@ python split_and_strip_files () {
>>  type |= 8
>>  return type
>>
>> +def isStaticLib(path):
>> +if path.endswith('.a') and not os.path.islink(path):
>> +with open(path, 'rb') as fh:
>> +# The magic must include the first slash to avoid
>> +# matching golang static libraries
>> +

Re: [oe] [meta-oe][PATCH 1/2] websocketpp: add new recipe based on Debian packaging

[Burton, Ross]

On 19 April 2018 at 15:17, Gianfranco Costamagna
 wrote:
> +FILES_${PN}-dev += "${libdir}/cmake"

cmake.bbclass does this:

FILES_${PN}-dev += "${libdir}/cmake ${datadir}/cmake"

So this is not required.

Ross
-- 
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel

Re: [oe] [OE-core] X11 proto changes

[Burton, Ross]

On 24 March 2018 at 19:07, akuster808  wrote:
> It appears Xorg is deprecating most of it's proto header repos for a new
> all-in-1 repo xorgproto. This will most likely affect down stream
> layers. The question I have, is do we want this big churn to happen for
> Sumo or wait for 2.6 ?

Pretty late for Sumo and if the worst case thing happens and they
delete the repos (which would be unusual) then we can just point the
SRC_URI at the yoctoproject mirror site.

Moving forward in master I guess a xorgprotos recipe which PROVIDES
that bundle should be seamless.

Ross
-- 
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel

Re: [oe] Splitting meta-oe?

[Burton, Ross]

On 21 February 2018 at 14:02, Joe MacDonald 
wrote:

> Honestly, now that I'm back from my vacation, I think the right thing is
> to add the dependency and then start thinking about a way to specify
> layer dependencies with greater granularity than on a meta-layer basis.
> Like, there's no question meta-networking depends on core.  It's
> nonsense to think of it without that dependency.  But it'd be nice to be
> able to specify a layer dependency that only exists if your project
> includes specific recipes out of that layer.
>
> But that kind of mechanism seems highly prone to breakage and likely to
> be highly contentious even if it was shown to be reliable, so it may not
> get beyond a "that'd be nice" thing for me.
>
> Unless someone else has already implemented it and I'm just not aware of
> how to use it?  :-)
>

meta-freescale (iirc) does this, conditionally adds sub-layers to BBLAYERS
based on what other layers are already enabled.

Ross
-- 
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel

[oe] Splitting meta-oe?

[Burton, Ross]

Hi,

Is now a good time to talk about splitting up meta-oe?  Some layers are
actively developed and maintained (one example: meta-python), others are
basically bitrotting and only get touched when something else causes them
to break world builds (one example: meta-gnome).  I've long felt that
meta-oe should be split up and the high quality layers managed in their own
repositories so patches to them don't get held up by breakage in other
sub-layers.

Another advantage of splitting out the high quality layers is that we'd
like to look at running more community layers through the Yocto
autobuilder, and granular layers make that easier to manage.

Comments?

Ross
-- 
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel

Re: [oe] [OE-core] [RFT] Glibc 2.27

[Burton, Ross]

The yocto autobuilder was idle so I fired it, fingers crossed :)

On 27 January 2018 at 21:44, Khem Raj  wrote:

> Hi All
>
> glibc 2.27 is releasing soon in few weeks. I have put together the recipes
> for upgrade, along with fixes for some of packages that I ran into here
>
> http://git.openembedded.org/openembedded-core-contrib/log/?
> h=kraj/glibc-2.27
>
> This has gotten limited testing. I plan to put the package fixes as we
> plough through. Please test this out in your setups and report problems or
> fixes ( preferred ) to get various packages working on 2.27 release
>
> Thanks
> -Khem
> --
> ___
> Openembedded-core mailing list
> openembedded-c...@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core
>
-- 
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel

Re: [oe] [yocto] [RFT] Glibc 2.27

[Burton, Ross]

On 29 January 2018 at 07:45, Zoran Stojsavljevic <
zoran.stojsavlje...@gmail.com> wrote:

> This one will be tough to integrate. Most of the packages depend on
> this one, which is critical one. On the very bottom. I would say, this
> is a big step, since here somewhere you should draw clear line. And
> this line will be the following: which releases you/YOCTO crew will
> support (back-port to) with Glibc 2.27, and which not?!
>

This one will be easy to integrate: it goes into master and none of the
stable releases.  Stable releases only get upgrades after release is very
limited situations.

Ross
-- 
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel

Re: [oe] [meta-networking][PATCH] ndisc6: need to set USE_NLS="yes" to use gettext.h

[Burton, Ross]

Oh right, presumably your distro is turning off NLS.  Yeah if the upstream
doesn't understand how to turn it off, then yes this would be the
workaround.

Ross

On 26 January 2018 at 22:10, Denys Dmytriyenko <de...@denix.org> wrote:

> Not really:
>
> ERROR: ndisc6-1.0.4+gitAUTOINC+4c794b5512-r0 do_configure: Function
> failed: do_configure (log file is located at .../work/armv7ahf-neon-linux-
> gnueabi/ndisc6/1.0.4+gitAUTOINC+4c794b5512-r0/temp/log.do_configure.23315)
> ERROR: Logfile of failure stored in: .../work/armv7ahf-neon-linux-
> gnueabi/ndisc6/1.0.4+gitAUTOINC+4c794b5512-r0/temp/log.do_configure.23315
> Log data follows:
> | DEBUG: Executing shell function do_configure
> | cp: cannot stat '.../work/armv7ahf-neon-linux-gnueabi/ndisc6/1.0.4+
> gitAUTOINC+4c794b5512-r0/recipe-sysroot-native/usr/share/gettext/gettext.h':
> No such file or directory
> | WARNING: .../work/armv7ahf-neon-linux-gnueabi/ndisc6/1.0.4+
> gitAUTOINC+4c794b5512-r0/temp/run.do_configure.23315:1 exit 1 from 'cp
> .../work/armv7ahf-neon-linux-gnueabi/ndisc6/1.0.4+
> gitAUTOINC+4c794b5512-r0/recipe-sysroot-native/usr/share/gettext/gettext.h
> .../work/armv7ahf-neon-linux-gnueabi/ndisc6/1.0.4+
> gitAUTOINC+4c794b5512-r0/git/include'
> | ERROR: Function failed: do_configure (log file is located at
> .../work/armv7ahf-neon-linux-gnueabi/ndisc6/1.0.4+
> gitAUTOINC+4c794b5512-r0/temp/log.do_configure.23315)
> ERROR: Task (/OE/arago-rocko/sources/meta-openembedded/meta-networking/
> recipes-support/ndisc6/ndisc6_git.bb:do_configure) failed with exit code
> '1'
>
>
>
> On Wed, Jan 24, 2018 at 10:53:08AM +, Burton, Ross wrote:
> > That should only be true for native recipes?
> >
> > On 23 January 2018 at 22:39, Denys Dmytriyenko <de...@denix.org> wrote:
> >
> > > Ping.
> > >
> > >
> > > On Tue, Jan 16, 2018 at 01:43:35AM -0500, Denys Dmytriyenko wrote:
> > > > From: Denys Dmytriyenko <de...@ti.com>
> > > >
> > > > Otherwise we can get gettext-minimal-native dependency instead, which
> > > does not
> > > > provide gettext.h header.
> > > >
> > > > Signed-off-by: Denys Dmytriyenko <de...@ti.com>
> > > > ---
> > > >  meta-networking/recipes-support/ndisc6/ndisc6_git.bb | 2 ++
> > > >  1 file changed, 2 insertions(+)
> > > >
> > > > diff --git a/meta-networking/recipes-support/ndisc6/ndisc6_git.bb
> > > b/meta-networking/recipes-support/ndisc6/ndisc6_git.bb
> > > > index 48a83b8..58f1230 100644
> > > > --- a/meta-networking/recipes-support/ndisc6/ndisc6_git.bb
> > > > +++ b/meta-networking/recipes-support/ndisc6/ndisc6_git.bb
> > > > @@ -22,6 +22,8 @@ EXTRA_OECONF += "PERL=${USRBINPATH}/perl"
> > > >  LDFLAGS += "-fuse-ld=gold"
> > > >  TOOLCHAIN = "gcc"
> > > >
> > > > +USE_NLS = "yes"
> > > > +
> > > >  do_configure_prepend() {
> > > >  cp ${STAGING_DATADIR_NATIVE}/gettext/gettext.h ${S}/include
> > > >  ${S}/autogen.sh
> > > > --
> > > > 2.7.4
> > > >
> > > > --
> > > > ___
> > > > Openembedded-devel mailing list
> > > > Openembedded-devel@lists.openembedded.org
> > > > http://lists.openembedded.org/mailman/listinfo/openembedded-devel
> > > --
> > > ___
> > > Openembedded-devel mailing list
> > > Openembedded-devel@lists.openembedded.org
> > > http://lists.openembedded.org/mailman/listinfo/openembedded-devel
> > >
>
-- 
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel

Re: [oe] [meta-networking][PATCH] ndisc6: need to set USE_NLS="yes" to use gettext.h

[Burton, Ross]

That should only be true for native recipes?

On 23 January 2018 at 22:39, Denys Dmytriyenko  wrote:

> Ping.
>
>
> On Tue, Jan 16, 2018 at 01:43:35AM -0500, Denys Dmytriyenko wrote:
> > From: Denys Dmytriyenko 
> >
> > Otherwise we can get gettext-minimal-native dependency instead, which
> does not
> > provide gettext.h header.
> >
> > Signed-off-by: Denys Dmytriyenko 
> > ---
> >  meta-networking/recipes-support/ndisc6/ndisc6_git.bb | 2 ++
> >  1 file changed, 2 insertions(+)
> >
> > diff --git a/meta-networking/recipes-support/ndisc6/ndisc6_git.bb
> b/meta-networking/recipes-support/ndisc6/ndisc6_git.bb
> > index 48a83b8..58f1230 100644
> > --- a/meta-networking/recipes-support/ndisc6/ndisc6_git.bb
> > +++ b/meta-networking/recipes-support/ndisc6/ndisc6_git.bb
> > @@ -22,6 +22,8 @@ EXTRA_OECONF += "PERL=${USRBINPATH}/perl"
> >  LDFLAGS += "-fuse-ld=gold"
> >  TOOLCHAIN = "gcc"
> >
> > +USE_NLS = "yes"
> > +
> >  do_configure_prepend() {
> >  cp ${STAGING_DATADIR_NATIVE}/gettext/gettext.h ${S}/include
> >  ${S}/autogen.sh
> > --
> > 2.7.4
> >
> > --
> > ___
> > Openembedded-devel mailing list
> > Openembedded-devel@lists.openembedded.org
> > http://lists.openembedded.org/mailman/listinfo/openembedded-devel
> --
> ___
> Openembedded-devel mailing list
> Openembedded-devel@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-devel
>
-- 
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel

Re: [oe] [meta-oe][PATCH]nautilus: new add

[Burton, Ross]

On 5 January 2018 at 04:20, zhengrq  wrote:

> +EXTRA_OECONF = " --disable-gtk-doc


There's a class to handle this.


> --disable-nls


Why are you disabling i18n?


> --enable-introspection=no"
>

There's a class to handle this.

Ross
-- 
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel

Re: [oe] [OE-core] MS Windows machine?

[Burton, Ross]

On 21 December 2017 at 09:54, Steffen Sledz <sl...@dresearch-fe.de> wrote:

> On 21.12.2017 10:08, Burton, Ross wrote:
> > On 21 December 2017 at 06:40, Steffen Sledz <sl...@dresearch-fe.de>
> wrote:
> >> Anyone tried to cross-compile for MS Windows target with Yocto/OE?
> >
> > Yes, see meta-mingw.
>
> A misunderstanding?
>
> I like to build *for* MS Windows, not *at* MS Windows.
>

"OpenEmbedded meta layer for mingw based SDKs"

Running bitbake on Windows isn't possible.  It's getting closer with the
new Subsystem for Linux thing but that's not ready yet.

meta-mingw lets you build SDKs *for* Windows.  We've used it to build cross
compilers that run on Windows that generate Linux binaries.

If you want to build for a Windows target then that should be possible but
nobody as far as I'm aware has made the work public.  meta-mingw will
contain most of the changes needed as that does build Windows binaries.

Ross
-- 
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel

Re: [oe] [OE-core] MS Windows machine?

[Burton, Ross]

On 21 December 2017 at 06:40, Steffen Sledz  wrote:

> Anyone tried to cross-compile for MS Windows target with Yocto/OE?
>

Yes, see meta-mingw.

Ross
-- 
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel

Re: [oe] splitting python's standard library

[Burton, Ross]

On 19 December 2017 at 13:23, Derek Straka  wrote:

> Cool.  Works for me.  Thanks.
>

There's an epic patch on the list which I'm reviewing right now that
drastically changes how the core Python library is packaged.  If you'd like
to have a look, the almost-final (my bandaid fixes need to be squashed) is
at poky-contrib:ross/py.

Ross
-- 
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel

Re: [oe] [meta-oe][PATCH] Fix PACKAGES assignment for fftw

[Burton, Ross]

You should explain why its the wrong operator, as =+ is as valid as += is.

Ross

On 23 November 2017 at 13:25, Vladan Jovanovic 
wrote:

> fftw recipe using wrong operator for modifying PACKAGES variable.
> ---
>  meta-oe/recipes-support/fftw/fftw_3.3.6.bb | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/meta-oe/recipes-support/fftw/fftw_3.3.6.bb
> b/meta-oe/recipes-support/fftw/fftw_3.3.6.bb
> index ed14e16..e13684c 100644
> --- a/meta-oe/recipes-support/fftw/fftw_3.3.6.bb
> +++ b/meta-oe/recipes-support/fftw/fftw_3.3.6.bb
> @@ -65,12 +65,12 @@ do_install() {
>  }
>
>
> -PACKAGES =+ "libfftw libfftwl libfftwf"
> +PACKAGES += "libfftw libfftwl libfftwf"
>  FILES_libfftw = "${libdir}/libfftw3.so.* ${libdir}/libfftw3_*.so.*"
>  FILES_libfftwl = "${libdir}/libfftw3l.so.* ${libdir}/libfftw3l_*.so.*"
>  FILES_libfftwf = "${libdir}/libfftw3f.so.* ${libdir}/libfftw3f_*.so.*"
>
> -PACKAGES =+ "fftw-wisdom fftwl-wisdom fftwf-wisdom fftw-wisdom-to-conf"
> +PACKAGES += "fftw-wisdom fftwl-wisdom fftwf-wisdom fftw-wisdom-to-conf"
>  FILES_fftw-wisdom = "${bindir}/fftw-wisdom"
>  FILES_fftwl-wisdom = "${bindir}/fftwl-wisdom"
>  FILES_fftwf-wisdom = "${bindir}/fftwf-wisdom"
> --
> 1.9.1
>
> --
> ___
> Openembedded-devel mailing list
> Openembedded-devel@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-devel
>
-- 
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel

Re: [oe] [PATCH 00/15] create meta-installer layer

[Burton, Ross]

I honestly don't see why this has to belong in meta-openembedded and can't
live in a standalone repository.

Ross

On 23 November 2017 at 12:09, Hongxu Jia  wrote:

> The meta-installer layer provides a collection of installation
> programs based on OE platform.
>
> One implementation is the target installer 'anaconda', the version
> is 26.21.11 which is based on Fedora 26.
>
> The anacoda requires:
> - systemd as init manager
> - python3
> - dnf2/rpm4
> - gobject-introspection which requires qemu-usermode
>   in MACHINE_FEATURES
>
> The anaconda provides:
> - graphic install and text install.
>
> - package based (dnf/rpm) install and image (copy)
>   based install.
>
> - package based (dnf/rpm) install from local and
>   remote rpm sources such as CDs and DVDs, images
>   stored on a hard drive, NFS, HTTP, and FTP.
>
> - kickstart install which provides a fully unattended
>   installation that can be duplicated on scores of machines.
>
> - install over VNC on headless machines.
>
> - timezone setting.
>
> - root password setting.
>
> - user account creation.
>
> - a variety of advanced storage devices including
>   LVM, Btrfs, Ext4, and filesystem encryption.
>
> TODO (currently not support):
> - keyboard setting
>
> - language support setting
>
> - network & host name setting
>
> //Hongxu
>
> The following changes since commit 34aa4c3202b427f59f843dc43a4e1a
> fda4f81d13:
>
>   usb-modeswitch: add usb-modeswitch@.service (2017-11-19 13:45:38 -0800)
>
> are available in the git repository at:
>
>   git://git.openembedded.org/openembedded-core-contrib
> hongxu/meta-installer
>   http://cgit.openembedded.org/openembedded-core-contrib/log/
> ?h=hongxu/meta-installer
>
> Hongxu Jia (15):
>   meta-installer: create layer
>   meta-installer: add kernel config
>   meta-installer: add anaconda support for target build
>   meta-installer: add distro anaconda for host build
>   meta-installer: add systemd/systemd-serialgetty bbappend
>   meta-installer: add gtk+3 bbappend
>   meta-installer: add initramfs-live-boot bbappend
>   meta-installer: add xserver-xf86-config bbappend
>   meta-installer: add multipath-tools bbappend
>   meta-installer: add recipe packagegroup-installer-x11-anaconda
>   meta-installer: add recipe yocto-compat-logos
>   meta-installer: add recipe anaconda-init
>   meta-installer: add recipe anaconda 26.21.11
>   meta-installer: add recipe core-image-anaconda
>   meta-installer: add recipe core-image-anaconda-initramfs
>
>  meta-installer/COPYING.MIT |  17 +
>  meta-installer/README  |  47 ++
>  meta-installer/README.anaconda | 341 
>  meta-installer/classes/anaconda_image.bbclass  | 321 +++
>  meta-installer/classes/anaconda_kernel.bbclass |  14 +
>  .../classes/anaconda_support_image.bbclass |  40 ++
>  .../classes/anaconda_support_kernel.bbclass|   8 +
>  meta-installer/conf/distro/anaconda.conf   |  33 ++
>  meta-installer/conf/layer.conf |  31 ++
>  meta-installer/licenses/FLTK   | 530
> ++
>  .../systemd/files/serial-getty@.service|  40 ++
>  .../systemd/files/serial-screen-anaconda.sh|   5 +
>  .../systemd/systemd-serialgetty.bbappend   |  12 +
>  .../recipes-core/systemd/systemd_%.bbappend|   6 +
>  ...for-anaconda-installer-while-loading-libA.patch |  84 +++
>  .../recipes-gnome/gtk+/gtk+3_%.%.%.bbappend|   3 +
>  .../xorg-xserver/xserver-xf86-config_0.1.bbappend  |  12 +
>  .../anaconda-init/anaconda-init.bb |  77 +++
>  .../anaconda-init/anaconda-init/COPYING| 339 
>  .../anaconda-init/anaconda-init/Xusername  |   1 +
>  .../anaconda-init/anaconda-init/anaconda-init  | 362 +
>  .../anaconda-init/anaconda-init-screen@.service|  22 +
>  .../anaconda-init/anaconda-init.service|  13 +
>  .../anaconda-init/anaconda-init.target |   6 +
>  .../anaconda/files/0001-do-not-support-po.patch|  41 ++
>  ...02-widgets-Makefile.am-do-not-compile-doc.patch |  28 +
>  ...t-Use-system-Python-when-running-Anaconda.patch |  42 ++
>  ...4-pyanaconda-flags.py-drop-selinux-module.patch |  48 ++
>  ...ckage-site-dir-for-installclass-searching.patch |  38 ++
>  ...06-do-not-load-the-system-wide-Xresources.patch |  53 ++
>  .../0007-tweak-iso-mount-dir-and-kernel-name.patch |  95 
>  .../0008-dnfpayload.py-customize-for-WRLinux.patch | 597
> +
>  ...cessary-noverifyssl-for-http-ftp-protocol.patch |  32 ++
>  .../0010-dynamic-detect-workable-locale.patch  |  77 +++
>  .../files/0011-improve-thread-monitor.patch|  55 ++
>  .../anaconda/files/0012-disable-audit.patch|  64 +++
>  ...py-Change-grub2-settings-to-match-oe-core.patch | 137 +
>  .../files/0014-tweak-detect-kernel-version.patch   |  96 
>  

Re: [oe] [meta][PATCH] connman: bump to version 1.35

[Burton, Ross]

oe-core patches go to openembedded-core@ not -devel@.

Ross

On 13 November 2017 at 20:53, Daniel Mack  wrote:

> Two patches are no longer needed, remove them.
>
> Signed-off-by: Daniel Mack 
> ---
>  ...ll-nftables-fix-build-with-libnftnl-1.0.7.patch | 72
> --
>  .../connman/connman/CVE-2017-12865.patch   | 87
> --
>  .../connman/{connman_1.34.bb => connman_1.35.bb}   |  6 +-
>  3 files changed, 2 insertions(+), 163 deletions(-)
>  delete mode 100644 meta/recipes-connectivity/
> connman/connman/0001-firewall-nftables-fix-build-with-libnftnl-1.0.7.patch
>  delete mode 100644 meta/recipes-connectivity/connman/connman/CVE-2017-
> 12865.patch
>  rename meta/recipes-connectivity/connman/{connman_1.34.bb =>
> connman_1.35.bb} (67%)
>
> diff --git a/meta/recipes-connectivity/connman/connman/0001-firewall-
> nftables-fix-build-with-libnftnl-1.0.7.patch b/meta/recipes-connectivity/
> connman/connman/0001-firewall-nftables-fix-build-with-libnftnl-1.0.7.patch
> deleted file mode 100644
> index cfafbd1271..00
> --- a/meta/recipes-connectivity/connman/connman/0001-firewall-
> nftables-fix-build-with-libnftnl-1.0.7.patch
> +++ /dev/null
> @@ -1,72 +0,0 @@
> -From 4058ce3186a99fd5f03350fc11a7fc8d38b6a381 Mon Sep 17 00:00:00 2001
> -From: "Maxin B. John" 
> -Date: Mon, 8 May 2017 10:53:18 +0300
> -Subject: [PATCH] firewall-nftables: fix build with libnftnl-1.0.7
> -
> -We need these updates to accommodate the changes caused by the following
> -commit in libnftnl-1.0.7
> -
> -commit 907a9f8e5a93f5bcd449643eb3916a656d634758
> -Author: Pablo Neira Ayuso 
> -Date:   Tue Dec 20 13:47:11 2016 +0100
> -
> -src: get rid of aliases and compat
> -
> -This machinery was introduced to avoid sudden compilation breakage of
> -old nftables releases. With the upcoming release of 0.7 (and 0.6 which
> -is now 6 months old) this is not required anymore.
> -
> -Moreover, users gain nothing from older releases since they are
> -half-boiled and buggy.
> -
> -So let's get rid of aliases now. Bump LIBVERSION and update map file.
> -
> -Upstream-Status: Submitted
> -
> -Signed-off-by: Maxin B. John 
> 
> - src/firewall-nftables.c | 14 +++---
> - 1 file changed, 7 insertions(+), 7 deletions(-)
> -
> -diff --git a/src/firewall-nftables.c b/src/firewall-nftables.c
> -index 583d1c4..83b137b 100644
>  a/src/firewall-nftables.c
> -+++ b/src/firewall-nftables.c
> -@@ -387,9 +387,9 @@ static int add_cmp(struct nftnl_rule *rule, uint32_t
> sreg, uint32_t op,
> - if (!expr)
> - return -ENOMEM;
> -
> --nftnl_expr_set_u32(expr, NFT_EXPR_CMP_SREG, sreg);
> --nftnl_expr_set_u32(expr, NFT_EXPR_CMP_OP, op);
> --nftnl_expr_set(expr, NFT_EXPR_CMP_DATA, data, data_len);
> -+nftnl_expr_set_u32(expr, NFTNL_EXPR_CMP_SREG, sreg);
> -+nftnl_expr_set_u32(expr, NFTNL_EXPR_CMP_OP, op);
> -+nftnl_expr_set(expr, NFTNL_EXPR_CMP_DATA, data, data_len);
> -
> - nftnl_rule_add_expr(rule, expr);
> -
> -@@ -575,8 +575,8 @@ static int build_rule_nat(const char *address,
> unsigned char prefixlen,
> -   expr = nftnl_expr_alloc("meta");
> -   if (!expr)
> -   goto err;
> --  nftnl_expr_set_u32(expr, NFT_EXPR_META_KEY, NFT_META_OIFNAME);
> --  nftnl_expr_set_u32(expr, NFT_EXPR_META_DREG, NFT_REG_1);
> -+  nftnl_expr_set_u32(expr, NFTNL_EXPR_META_KEY, NFT_META_OIFNAME);
> -+  nftnl_expr_set_u32(expr, NFTNL_EXPR_META_DREG, NFT_REG_1);
> -   nftnl_rule_add_expr(rule, expr);
> -   err = add_cmp(rule, NFT_REG_1, NFT_CMP_EQ, interface,
> -   strlen(interface) + 1);
> -@@ -677,8 +677,8 @@ static int build_rule_snat(int index, const char
> *address,
> -   expr = nftnl_expr_alloc("meta");
> -   if (!expr)
> -   goto err;
> --  nftnl_expr_set_u32(expr, NFT_EXPR_META_KEY, NFT_META_OIF);
> --  nftnl_expr_set_u32(expr, NFT_EXPR_META_DREG, NFT_REG_1);
> -+  nftnl_expr_set_u32(expr, NFTNL_EXPR_META_KEY, NFT_META_OIF);
> -+  nftnl_expr_set_u32(expr, NFTNL_EXPR_META_DREG, NFT_REG_1);
> -   nftnl_rule_add_expr(rule, expr);
> -   err = add_cmp(rule, NFT_REG_1, NFT_CMP_EQ, , sizeof(index));
> -   if (err < 0)
> ---
> -2.4.0
> -
> diff --git a/meta/recipes-connectivity/connman/connman/CVE-2017-12865.patch
> b/meta/recipes-connectivity/connman/connman/CVE-2017-12865.patch
> deleted file mode 100644
> index 45f78f10ea..00
> --- a/meta/recipes-connectivity/connman/connman/CVE-2017-12865.patch
> +++ /dev/null
> @@ -1,87 +0,0 @@
> -From 5c281d182ecdd0a424b64f7698f32467f8f67b71 Mon Sep 17 00:00:00 2001
> -From: Jukka Rissanen 
> -Date: Wed, 9 Aug 2017 10:16:46 +0300
> -Subject: dnsproxy: Fix crash on malformed DNS response
> -
> -If the response query string is malformed, we might access memory
> -pass the end of 

Re: [oe] [oe-commits] [openembedded-core] 04/44: db: don't provide virtual/db

[Burton, Ross]

Apologies, I must have failed to submit that series after it passed an
autobuilder run.  Patches for meta-oe sent.

Ross

On 12 November 2017 at 17:22, Khem Raj  wrote:

> On Sun, Nov 12, 2017 at 3:48 AM, Martin Jansa 
> wrote:
> > Also, was this ever sent to ML for review? I haven't found it in my
> maildir
> > and google haven't found it in ML archive as well.
> >
>
> Its not on patchwork it seems to have slipped in probably by an overisight
> but I think fix is right. Probably a simple fix for meta-oe recipes to
> depend on
> db will be what we need
>
> > On Sat, Nov 11, 2017 at 11:45 PM, Martin Jansa 
> > wrote:
> >
> >> Hi,
> >>
> >> will you please send fix for:
> >> ERROR: Nothing PROVIDES 'virtual/db' (but meta-oe/meta-networking/
> >> recipes-daemons/postfix/postfix_3.2.2.bb meta-oe/meta-networking/
> >> recipes-daemons/cyrus-sasl/cyrus-sasl_2.1.26.bb DEPENDS on or otherwise
> >> requires it).
> >>
> >> Thanks
> >>
> >> On Fri, Nov 10, 2017 at 3:45 PM,  wrote:
> >>
> >>> This is an automated email from the git hooks/post-receive script.
> >>>
> >>> rpurdie pushed a commit to branch master-next
> >>> in repository openembedded-core.
> >>>
> >>> commit dcbc45aa3fe72c528fe4d47a783da4b4ed5ff38e
> >>> Author: Ross Burton 
> >>> AuthorDate: Tue Oct 31 21:10:13 2017 +
> >>>
> >>> db: don't provide virtual/db
> >>>
> >>> As there are no alternative providers for virtual/db remove the
> >>> PROVIDES and
> >>> recipes can just depend on db.
> >>>
> >>> Signed-off-by: Ross Burton 
> >>> ---
> >>>  meta/recipes-support/db/db_5.3.28.bb | 10 --
> >>>  1 file changed, 10 deletions(-)
> >>>
> >>> diff --git a/meta/recipes-support/db/db_5.3.28.bb
> >>> b/meta/recipes-support/db/db_5.3.28.bb
> >>> index fb4befb..fe71967 100644
> >>> --- a/meta/recipes-support/db/db_5.3.28.bb
> >>> +++ b/meta/recipes-support/db/db_5.3.28.bb
> >>> @@ -12,7 +12,6 @@ SECTION = "libs"
> >>>  SUMMARY = "Berkeley Database v5"
> >>>  HOMEPAGE = "http://www.oracle.com/technetwork/database/database-
> technol
> >>> ogies/berkeleydb/overview/index.html"
> >>>  LICENSE = "Sleepycat"
> >>> -VIRTUAL_NAME ?= "virtual/db"
> >>>  RCONFLICTS_${PN} = "db3"
> >>>
> >>>  PR = "r1"
> >>> @@ -37,15 +36,6 @@ LIC_FILES_CHKSUM = "file://LICENSE;md5=ed1158e314
> >>> 37f4f87cdd4ab2b8613955"
> >>>
> >>>  inherit autotools
> >>>
> >>> -# Put virtual/db in any appropriate provider of a
> >>> -# relational database, use it as a dependency in
> >>> -# place of a specific db and use:
> >>> -#
> >>> -# PREFERRED_PROVIDER_virtual/db
> >>> -#
> >>> -# to select the correct db in the build (distro) .conf
> >>> -PROVIDES += "${VIRTUAL_NAME}"
> >>> -
> >>>  # The executables go in a separate package - typically there
> >>>  # is no need to install these unless doing real database
> >>>  # management on the system.
> >>>
> >>> --
> >>> To stop receiving notification emails like this one, please contact
> >>> the administrator of this repository.
> >>> --
> >>> ___
> >>> Openembedded-commits mailing list
> >>> openembedded-comm...@lists.openembedded.org
> >>> http://lists.openembedded.org/mailman/listinfo/openembedded-commits
> >>>
> >>
> >>
> > --
> > ___
> > Openembedded-devel mailing list
> > Openembedded-devel@lists.openembedded.org
> > http://lists.openembedded.org/mailman/listinfo/openembedded-devel
>
-- 
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel

Re: [oe] [PATCH] bitbake.conf: Add sdl-config to HOSTTOOLS

[Burton, Ross]

On 4 October 2017 at 10:32, Patrick Ohly  wrote:

> On Tue, 2017-10-03 at 11:40 +0200, Ricardo Ribalda Delgado wrote:
> > Without this patch bitbake cannot find sdl-config
> >
> > ERROR:  OE-core's config sanity checker detected a potential
> > misconfiguration.
> > Either fix the cause of this error or at your own risk disable the
> > checker (see sanity.conf).
> > Following is the list of potential problems / advisories:
> >
> > libsdl-native is set to be ASSUME_PROVIDED but sdl-config can't be
> > found in PATH. Please either install it, or configure qemu not to
> > require sdl.
>
> Making sdl-config available is the wrong solution. See https://bugzilla
> .yoctoproject.org/show_bug.cgi?id=11725


I've just closed that bug because I removed the sdl-config check from
sanity.bbclass back in June.

Ross
-- 
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel

Re: [oe] [PATCH] bitbake.conf: Add sdl-config to HOSTTOOLS

[Burton, Ross]

On 3 October 2017 at 10:40, Ricardo Ribalda Delgado <
ricardo.riba...@gmail.com> wrote:

> Without this patch bitbake cannot find sdl-config
>
> ERROR:  OE-core's config sanity checker detected a potential
> misconfiguration.
> Either fix the cause of this error or at your own risk disable the checker
> (see sanity.conf).
> Following is the list of potential problems / advisories:
>
> libsdl-native is set to be ASSUME_PROVIDED but sdl-config can't be found
> in PATH. Please either install it, or configure qemu not to require sdl.
>

First, wrong list, this should go to openembedded-core@ instead of -devel@.

qemu's configure prefers pkg-config instead of sdl-config, so why doesn't
that work for you?

Also note that we don't recommend using host libsdl via ASSUME_PROVIDED
because it's a nightmare to link when we've a sysroot full of
ABI-incompatible libraries.  For example if I try to build on Debian 9
qemu-native with the host SDL it fails at configure time:

| ERROR: User requested feature sdl
|configure was not able to find it.
|Install SDL devel

That's a lie, it found it but it wouldn't link:

//usr/lib/x86_64-linux-gnu/libcaca.so.0: undefined reference to
`resize_term@NCURSESW_5.3.20021019'
//usr/lib/x86_64-linux-gnu/libcaca.so.0: undefined reference to
`COLORS@NCURSESW_5.1.2708'
//usr/lib/x86_64-linux-gnu/libcaca.so.0: undefined reference to
`raw@NCURSES_TINFO_5.0.19991023'
//usr/lib/x86_64-linux-gnu/libcaca.so.0: undefined reference to
`ESCDELAY@NCURSESW_5.1.2708'
//usr/lib/x86_64-linux-gnu/libcaca.so.0: undefined reference to
`nodelay@NCURSES_TINFO_5.0.19991023'
//usr/lib/x86_64-linux-gnu/libcaca.so.0: undefined reference to
`initscr@NCURSESW_5.1.2708'
//usr/lib/x86_64-linux-gnu/libcaca.so.0: undefined reference to
`nonl@NCURSESW_5.1.2708'
//usr/lib/x86_64-linux-gnu/libcaca.so.0: undefined reference to
`wrefresh@NCURSESW_5.1.2708'
//usr/lib/x86_64-linux-gnu/libcaca.so.0: undefined reference to
`wmove@NCURSESW_5.1.2708'
//usr/lib/x86_64-linux-gnu/libcaca.so.0: undefined reference to
`getmouse@NCURSESW_5.1.2708'
//usr/lib/x86_64-linux-gnu/libcaca.so.0: undefined reference to
`curs_set@NCURSES_TINFO_5.0.19991023'
//usr/lib/x86_64-linux-gnu/libcaca.so.0: undefined reference to
`newterm@NCURSESW_5.1.2708'
//usr/lib/x86_64-linux-gnu/libcaca.so.0: undefined reference to
`waddnstr@NCURSESW_5.1.2708'
//usr/lib/x86_64-linux-gnu/libcaca.so.0: undefined reference to
`mouseinterval@NCURSESW_5.1.2708'
//usr/lib/x86_64-linux-gnu/libcaca.so.0: undefined reference to
`wgetch@NCURSESW_5.1.2708'
//usr/lib/x86_64-linux-gnu/libcaca.so.0: undefined reference to
`LINES@NCURSES_TINFO_5.0.19991023'
//usr/lib/x86_64-linux-gnu/libcaca.so.0: undefined reference to
`curscr@NCURSES_TINFO_5.0.19991023'
//usr/lib/x86_64-linux-gnu/libcaca.so.0: undefined reference to
`init_pair@NCURSESW_5.1.2708'
//usr/lib/x86_64-linux-gnu/libcaca.so.0: undefined reference to
`start_color@NCURSESW_5.1.2708'
//usr/lib/x86_64-linux-gnu/libcaca.so.0: undefined reference to
`stdscr@NCURSES_TINFO_5.0.19991023'
//usr/lib/x86_64-linux-gnu/libcaca.so.0: undefined reference to
`noraw@NCURSES_TINFO_5.0.19991023'
//usr/lib/x86_64-linux-gnu/libcaca.so.0: undefined reference to
`wattr_on@NCURSESW_5.1.2708'
//usr/lib/x86_64-linux-gnu/libcaca.so.0: undefined reference to
`COLS@NCURSES_TINFO_5.0.19991023'
//usr/lib/x86_64-linux-gnu/libcaca.so.0: undefined reference to
`noecho@NCURSESW_5.1.2708'
//usr/lib/x86_64-linux-gnu/libcaca.so.0: undefined reference to
`keypad@NCURSES_TINFO_5.0.19991023'
//usr/lib/x86_64-linux-gnu/libcaca.so.0: undefined reference to
`ungetch@NCURSESW_5.1.2708'
//usr/lib/x86_64-linux-gnu/libcaca.so.0: undefined reference to
`mousemask@NCURSESW_5.1.2708'
//usr/lib/x86_64-linux-gnu/libcaca.so.0: undefined reference to
`endwin@NCURSESW_5.1.2708'

The host libcaca is linking to the sysroot libncurses, and they're not
compatible.  This is why we moved away from using
ASSUME_PROVIDED=libsdl-native in December 2015.

Ross
-- 
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel

Re: [oe] [meta-mono][PATCHv2] libgdiplus: use tarball from mono project instead of github

[Burton, Ross]

The checksums didn't change?  Are you sure that bitbake wasn't finding the
tarballs you'd downloaded with v1 of this patch and using those (as the
checksums are only validated at fetch, not unpack).

(I guess its possible that the release tarballs were github /archive/
tarballs uploaded, but I'd be surprised)

Ross

On 29 September 2017 at 16:12, Pascal Bach  wrote:

> Signed-off-by: Pascal Bach 
> ---
>  recipes-mono/libgdiplus/libgdiplus-native_4.2.bb | 3 +--
>  recipes-mono/libgdiplus/libgdiplus_4.2.bb| 6 +++---
>  2 files changed, 4 insertions(+), 5 deletions(-)
>
> diff --git a/recipes-mono/libgdiplus/libgdiplus-native_4.2.bb
> b/recipes-mono/libgdiplus/libgdiplus-native_4.2.bb
> index 4dee6a0..e169105 100644
> --- a/recipes-mono/libgdiplus/libgdiplus-native_4.2.bb
> +++ b/recipes-mono/libgdiplus/libgdiplus-native_4.2.bb
> @@ -6,8 +6,7 @@ SECTION = "libs"
>  LICENSE = "MIT"
>  LIC_FILES_CHKSUM = "file://COPYING;md5=fe7364dfce9f3689eb6995e7cdd56879"
>
> -SRC_URI = "https://github.com/mono/libgdiplus/archive/${PV}.tar.gz \
> -   "
> +SRC_URI = "https://download.mono-project.com/sources/
> libgdiplus/libgdiplus-${PV}.tar.gz"
>
>  inherit autotools pkgconfig native
>
> diff --git a/recipes-mono/libgdiplus/libgdiplus_4.2.bb
> b/recipes-mono/libgdiplus/libgdiplus_4.2.bb
> index 00eb406..6fb4988 100644
> --- a/recipes-mono/libgdiplus/libgdiplus_4.2.bb
> +++ b/recipes-mono/libgdiplus/libgdiplus_4.2.bb
> @@ -12,9 +12,9 @@ PACKAGECONFIG[tiff] = "--with-libtiff,--without-
> libtiff,tiff"
>  PACKAGECONFIG[gif] = "--with-libgif,--without-libgif,giflib"
>  PACKAGECONFIG[exif] = "--with-libexif,--without-libexif,libexif"
>
> -SRC_URI = "https://github.com/mono/libgdiplus/archive/${PV}.tar.gz \
> -  file://01-remove-libjpeg-path.patch \
> -   "
> +SRC_URI = "https://download.mono-project.com/sources/
> libgdiplus/libgdiplus-${PV}.tar.gz \
> +   file://01-remove-libjpeg-path.patch \
> +  "
>
>  inherit autotools pkgconfig
>
> --
> 2.1.4
>
> --
> ___
> Openembedded-devel mailing list
> Openembedded-devel@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-devel
>
-- 
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel

Re: [oe] [meta-mono][PATCH] libgdiplus: include name in downloaded file

[Burton, Ross]

FYI, github.com /archive/ URLs result in tarballs that can and do change
over time, so it's recommended to use either explicitly uploaded tarballs
generated by the maintainer, or a git clone.

The github repo doesn't host any maintainer-generated tarballs but luckily
the Mono project itself does:
https://download.mono-project.com/sources/libgdiplus/.  I'd heavily
recommend changing to use those tarballs instead of the /archive/ tarballs.

Ross

On 29 September 2017 at 15:54, Pascal Bach  wrote:

> Without this change the file is named ${PV}.tar.gz
>
> Signed-off-by: Pascal Bach 
> ---
>  recipes-mono/libgdiplus/libgdiplus-native_4.2.bb | 3 +--
>  recipes-mono/libgdiplus/libgdiplus_4.2.bb| 6 +++---
>  2 files changed, 4 insertions(+), 5 deletions(-)
>
> diff --git a/recipes-mono/libgdiplus/libgdiplus-native_4.2.bb
> b/recipes-mono/libgdiplus/libgdiplus-native_4.2.bb
> index 4dee6a0..d3a988e 100644
> --- a/recipes-mono/libgdiplus/libgdiplus-native_4.2.bb
> +++ b/recipes-mono/libgdiplus/libgdiplus-native_4.2.bb
> @@ -6,8 +6,7 @@ SECTION = "libs"
>  LICENSE = "MIT"
>  LIC_FILES_CHKSUM = "file://COPYING;md5=fe7364dfce9f3689eb6995e7cdd56879"
>
> -SRC_URI = "https://github.com/mono/libgdiplus/archive/${PV}.tar.gz \
> -   "
> +SRC_URI = "https://github.com/mono/libgdiplus/archive/${PV}.tar.
> gz;downloadfilename=libgdiplus-${PV}.tar.gz"
>
>  inherit autotools pkgconfig native
>
> diff --git a/recipes-mono/libgdiplus/libgdiplus_4.2.bb
> b/recipes-mono/libgdiplus/libgdiplus_4.2.bb
> index 00eb406..03d87f7 100644
> --- a/recipes-mono/libgdiplus/libgdiplus_4.2.bb
> +++ b/recipes-mono/libgdiplus/libgdiplus_4.2.bb
> @@ -12,9 +12,9 @@ PACKAGECONFIG[tiff] = "--with-libtiff,--without-
> libtiff,tiff"
>  PACKAGECONFIG[gif] = "--with-libgif,--without-libgif,giflib"
>  PACKAGECONFIG[exif] = "--with-libexif,--without-libexif,libexif"
>
> -SRC_URI = "https://github.com/mono/libgdiplus/archive/${PV}.tar.gz \
> -  file://01-remove-libjpeg-path.patch \
> -   "
> +SRC_URI = "https://github.com/mono/libgdiplus/archive/${PV}.tar.
> gz;downloadfilename=libgdiplus-${PV}.tar.gz \
> +   file://01-remove-libjpeg-path.patch \
> +  "
>
>  inherit autotools pkgconfig
>
> --
> 2.1.4
>
> --
> ___
> Openembedded-devel mailing list
> Openembedded-devel@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-devel
>
-- 
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel

Re: [oe] [PATCH] curl: option to enable http2 protocol support.

[Burton, Ross]

On 25 September 2017 at 19:38, baali  wrote:

> From: baali 
>
> With default --without-nghttp2 flag set there was no way to get
> http2 protocol support using nghttp2 library. Instead moved it to
> PACKAGECONFIG options


Wrong list: oe-core patches go to openembedded-core@ instead of -devel@.


> +PACKAGECONFIG[nghttp2] = "--with-nghttp2,--without-nghttp2"


The configure.ac then checks for the libnghttp2 library which isn't listed
as a build dependency, so you'll need to add this here.

Ross
-- 
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel

Re: [oe] [meta-oe][PATCH] jsoncpp: update to version 1.8.3

[Burton, Ross]

On 20 September 2017 at 15:09, Derek Straka  wrote:

> -LIC_FILES_CHKSUM = "file://LICENSE;md5=c56ee55c03a55f8105b969d8270632ce"
> +LIC_FILES_CHKSUM = "file://LICENSE;md5=fa2a23dd1dc6c139f35105379d76df2b"
>

Always explain why the checksum needs to change in the commit message (so a
v2, not just a reply to this message).

Ross
-- 
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel

Re: [oe] [OE-core] Use of github /archive/ tarballs in SRC_URI

[Burton, Ross]

On 19 September 2017 at 15:34, Carlos Alberto Lopez Perez <clo...@igalia.com
> wrote:

> On 19/09/17 10:09, Burton, Ross wrote:
> > Then the tarball for one of Erlang's repositories changed, and was
> noticed
> > by the checksum in the recipe (thanks Gunnar Andersson for reporting
> > this).  The extracted contents are identical, but the tarball itself has
> > changed.  I'm presuming this is due to the old tarball expiring in their
> > cache, and a newly generated tarball using a later version of tar.
>
> I don't think tar is the one to blame, but gzip.
> I have just tested GNU tar (versions 1.29 and 1.26) and BSD tar (from
> OpenBSD 5.8) and the 3 have produced identical archives (same md5sum)
> when invoked like git archive does.
>
> However, the .tar.gz file generated was different in the case of BSD.
> It even had a different file size.
>
> I bet that if you uncompress both files, the .tar will have the same
> checksum in both cases.
>

In the situation that I was talking to Gunnar with, the source is the tar
itself.

https://paste.fedoraproject.org/paste/rP67aSPn1IuYbQcz2UNY3g

They have identical length
> $ wc -c new-OTP-18.2.3.tar
> 159068160 new-OTP-18.2.3.tar
> 159068160 orig-OTP-18.2.3.tar
> ...but different content
> $ cmp new-OTP-18.2.3.tar orig-OTP-18.2.3.tar
> $ new-OTP-18.2.3.tar orig-OTP-18.2.3.tar differ: byte 79122433, line
> 2004431
>

Basically, both tar and gzip can cause problems.

Ross
-- 
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel

Re: [oe] Use of github /archive/ tarballs in SRC_URI

[Burton, Ross]

On 19 September 2017 at 09:32,  wrote:

> Yes, we have been affected by this several times too.
>
> In addition to fixing recipes, a sanity test to warn about the situation
> would be nice to have so that the issue could be detected in other
> meta layers too.
>

So I have a class adding a few tests to package_qa, including this one:

https://github.com/rossburton/meta-ross/blob/0f788385dbe13914e9e07d382793c494c4927ef9/classes/insanitier.bbclass#L93

If I get a moment I'll move it to insane.bbclass.

Ross
-- 
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel

[oe] Use of github /archive/ tarballs in SRC_URI

[Burton, Ross]

Hi,

Some people have insisted for a long time that the dynamically generated
/archive/ tarballs at github cannot be trusted for long-term stability, as
they are generated using git-archive.  Others said that git-archive takes
measures to ensure the files are identical, and basic testing does indeed
show that.  Personally I was on the fence: a dynamically generated tarball
that is cached *could* change, but the git-archive generates the same file
list and the tools are stable.

Then the tarball for one of Erlang's repositories changed, and was noticed
by the checksum in the recipe (thanks Gunnar Andersson for reporting
this).  The extracted contents are identical, but the tarball itself has
changed.  I'm presuming this is due to the old tarball expiring in their
cache, and a newly generated tarball using a later version of tar.

So we now have documented evidence that this can and does happen, and it's
quite frustrating when this happens.  So, I suggest that use of github.com
/archive/ URLs be considered a bad practise for the primary SRC_URI tarball.

I'm working my way through the recipes in oe-core that use /archive/ and
replacing them with either maintainer-generated tarballs or git clones, but
there are a number of recipes in meta-oe which could do with fixing:

$ git grep -l -E github\\.com/.*/archive/
meta-initramfs/recipes-devtools/grubby/grubby_8.40.bb
meta-multimedia/recipes-support/gst-instruments/gst-instruments_0.2.3.bb
meta-multimedia/recipes-support/libsrtp/libsrtp_1.5.2.bb
meta-networking/recipes-support/geoip/geoip-perl_1.50.bb
meta-oe/recipes-connectivity/libuv/libuv_1.11.0.bb
meta-oe/recipes-connectivity/libwebsockets/libwebsockets_2.1.0.bb
meta-oe/recipes-devtools/protobuf/protobuf-c_1.2.1.bb
meta-oe/recipes-devtools/python/python-cpuset_1.5.7.bb
meta-oe/recipes-extended/boinc/boinc-client_7.6.33.bb
meta-oe/recipes-graphics/libvncserver/libvncserver_0.9.11.bb
meta-oe/recipes-graphics/openjpeg/openjpeg_2.1.1.bb
meta-oe/recipes-kernel/crash/crash_7.1.9.bb
meta-oe/recipes-multimedia/mplayer/mpv_0.24.0.bb
meta-oe/recipes-support/hunspell/hunspell_1.6.1.bb
meta-oe/recipes-support/lm_sensors/lmsensors_3.4.0.bb
meta-oe/recipes-test/gtest/gtest_1.8.0.bb
meta-perl/recipes-perl/libmodule/libmodule-pluggable-perl_5.2.bb
meta-perl/recipes-perl/libmodule/libmodule-runtime-perl_0.015.bb

Ross
-- 
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel

Re: [oe] [meta-oe][PATCH] libpng12: add it back from oe-core

[Burton, Ross]

On 15 September 2017 at 11:03, Martin Jansa  wrote:

> Hi,
>
> most of our prebuilt binaries (built outside OE, sometimes by other
> companies) are built against libpng12.
>
> Not because they must be, just because libpng12 was there when they started
> building them and nobody revisited that since then. Now I'm trying to get
> all those prebuilt binaries to be rebuilt against libpng 1.6 before we
> upgrade to Yocto 2.4. If I don't get them soon enough I'll need to keep
> libpng12 in one of our internal layer for a bit longer.
>
> So I agree it's outdated waste of time, but unfortunately still mis-used by
> some people.
>

That sounds like a great rationale to keep libpng12 in meta-oe.

Ross
-- 
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel

Re: [oe] [meta-oe][PATCH] libpng12: add it back from oe-core

[Burton, Ross]

On 14 September 2017 at 14:49, Alexander Kanavin <
alexander.kana...@linux.intel.com> wrote:

> On 09/14/2017 04:42 PM, Burton, Ross wrote:
>
>> On 14 September 2017 at 11:33, Martin Jansa <martin.ja...@gmail.com>
>> wrote:
>>
>> LSB compliance isn't a goal of meta-oe as well, otherwise we'd need to
>>> add Qt4 to meta-oe too.
>>>
>>>
>> Touche.
>>
>> It still needs to go somewhere though...
>>
>
> How about modifying the LSB tests to make the absence of libpng12 a
> warning rather than an error?
>

Then it won't be doing a LSB test...   The LSB is the LSB, we don't claim
to support it, but there's a need for a libpng12 recipe for people who want
to be close.  Currently it's just this one recipe that I'm aware of that
isn't already in a layer somewhere.

Ross
-- 
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel

Re: [oe] [meta-oe][PATCH] libpng12: add it back from oe-core

[Burton, Ross]

On 14 September 2017 at 11:33, Martin Jansa  wrote:

> LSB compliance isn't a goal of meta-oe as well, otherwise we'd need to
> add Qt4 to meta-oe too.
>

Touche.

It still needs to go somewhere though...

Ross
-- 
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel

Re: [oe] [meta-oe][PATCH] libpng12: add it back from oe-core

[Burton, Ross]

On 13 September 2017 at 10:54, Martin Jansa  wrote:

> All other LSB related recipes are in oe-core, why should libpng12 be
> different and live in meta-oe?


Mainly because LSB compliance isn't a goal of oe-core, otherwise we'd need
to add Qt4 to oe-core too.

meta-oe seems like a perfectly acceptable place for this.

Ross
-- 
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel

Re: [oe] [PATCH] goarch.bbclass: Replace logic for setting GOARM

[Burton, Ross]

This class is in oe-core, so should go do openembedded-core@ not -devel@.

Ross

On 7 September 2017 at 10:20, Will Newton  wrote:

> On Thu, Sep 7, 2017 at 10:18 AM, Martin Jansa 
> wrote:
> > Wrong ML
>
> I appreciate you taking the time to craft this response, but it isn't
> very helpful to me.
>
> > On Thu, Sep 7, 2017 at 11:17 AM, Will Newton 
> wrote:
> >>
> >> The previous logic applied a regex to TUNE_FEATURES which could
> >> set the GOARM value to 7 incorrectly, for example when dealing
> >> with an arm1176 core. Simplify to check for the presence of
> >> "armv7a" instead. At the same time add a check for "armv6" and
> >> set GOARM to 6 in that case.
> >>
> >> Signed-off-by: Will Newton 
> >> ---
> >>  meta/classes/goarch.bbclass | 7 +--
> >>  1 file changed, 5 insertions(+), 2 deletions(-)
> >>
> >> diff --git a/meta/classes/goarch.bbclass b/meta/classes/goarch.bbclass
> >> index 4a5b2ec..35f2987 100644
> >> --- a/meta/classes/goarch.bbclass
> >> +++ b/meta/classes/goarch.bbclass
> >> @@ -38,8 +38,11 @@ def go_map_arch(a, d):
> >>
> >>  def go_map_arm(a, f, d):
> >>  import re
> >> -if re.match('arm.*', a) and re.match('arm.*7.*', f):
> >> -return '7'
> >> +if re.match('arm.*', a):
> >> +if 'armv7a' in f:
> >> +return '7'
> >> +elif 'armv6' in f:
> >> +return '6'
> >>  return ''
> >>
> >>  def go_map_os(o, d):
> >> --
> >> 2.7.4
> >>
> >> --
> >> ___
> >> Openembedded-devel mailing list
> >> Openembedded-devel@lists.openembedded.org
> >> http://lists.openembedded.org/mailman/listinfo/openembedded-devel
> >
> >
> --
> ___
> Openembedded-devel mailing list
> Openembedded-devel@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-devel
>
-- 
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel

Re: [oe] [PATCH][meta-gnome 1/9] cheese: remove (previously blacklisted)

[Burton, Ross]

I'd prefer you not to remove all blacklisted packages, for example there
are two gweather recipes and the blacklisted one is the one you want to
keep.  Would you prefer that I fiddle the blacklistings and leave them to
expire when the message says?

Ross


On 21 July 2017 at 09:56, Martin Jansa  wrote:

> The PNBLACKLIST message says it will be removed on 2017-09-01. I already
> have a patch which will remove all blacklisted recipes with such
> PNBLACKLIST but I'll apply it only at the end of next month.
>
> On Thu, Jul 20, 2017 at 5:35 PM, Ross Burton 
> wrote:
>
>> Cheese 2.30.1 is very old (2010) and has been blacklisted for some time,
>> so
>> remove it.
>>
>> Signed-off-by: Ross Burton 
>> ---
>>  meta-gnome/recipes-apps/cheese/cheese_2.30.1.bb | 26
>> -
>>  1 file changed, 26 deletions(-)
>>  delete mode 100644 meta-gnome/recipes-apps/cheese/cheese_2.30.1.bb
>>
>> diff --git a/meta-gnome/recipes-apps/cheese/cheese_2.30.1.bb
>> b/meta-gnome/recipes-apps/cheese/cheese_2.30.1.bb
>> deleted file mode 100644
>> index 3f5a5b124..0
>> --- a/meta-gnome/recipes-apps/cheese/cheese_2.30.1.bb
>> +++ /dev/null
>> @@ -1,26 +0,0 @@
>> -SUMMARY = "Take photos and videos with your webcam, with fun graphical
>> effects"
>> -LICENSE = "GPLv2"
>> -LIC_FILES_CHKSUM = "file://COPYING;md5=a17cb0a873d252440acfdf9b3d0e7fbf"
>> -
>> -DEPENDS = "gtk+ gstreamer gst-plugins-base libcanberra udev librsvg
>> gnome-desktop evolution-data-server intltool-native"
>> -
>> -PR = "r2"
>> -
>> -inherit gnome
>> -
>> -SRC_URI[archive.md5sum] = "1599fded8a1797ea51fb010af4e6c45b"
>> -SRC_URI[archive.sha256sum] = "48f03470c6f527caa0e3b269d3afc
>> ff86ae0939a74f66ce030d4eed3bc3cbd9a"
>> -GNOME_COMPRESS_TYPE="bz2"
>> -
>> -FILES_${PN} += "${datadir}/dbus-1"
>> -RRECOMMENDS_${PN} = "gst-plugins-good-meta gst-plugins-base-meta"
>> -
>> -EXTRA_OECONF += "--disable-scrollkeeper"
>> -
>> -do_configure_prepend() {
>> -sed -i -e "s: help : :g" ${S}/Makefile.am
>> -}
>> -
>> -PNBLACKLIST[cheese] ?= "Depends on blacklisted gstreamer - the recipe
>> will be removed on 2017-09-01 unless the issue is fixed"
>> -
>> -PNBLACKLIST[cheese] ?= "Depends on blacklisted gnome-desktop - the
>> recipe will be removed on 2017-09-01 unless the issue is fixed"
>> --
>> 2.11.0
>>
>> --
>> ___
>> Openembedded-devel mailing list
>> Openembedded-devel@lists.openembedded.org
>> http://lists.openembedded.org/mailman/listinfo/openembedded-devel
>>
>
>
-- 
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel

Re: [oe] [PATCH] openssl : By default, disable cryptodev.

[Burton, Ross]

On 17 July 2017 at 02:54, Huang Qiyu  wrote:

> Because according to the other Distros(e.g. Ubuntu, Fedora), cryptodev is
> not enabled.
> If users want enable cryptodev, just have to add "cryptodev-linux" into
> PACKAGECONFIG.
>

Wrong list, you meant oe-core@.

There was a discussion about this back in March ("openssl: disable
cryptodev by default") where Wind River reports that they see a number of
customers using hardware crypto.  I'm all for making this an option but
whether to enable/disable it by default isn't clear.


-DEPENDS += "cryptodev-linux"
+PACKAGECONFIG[cryptodev-linux] = ",,cryptodev-linux"

Just call this cryptodev, imho.

+DEPENDS += "${@bb.utils.contains('PACKAGECONFIG', 'cryptodev-linux',
'cryptodev-linux', '', d)}"

No need to do this, as that is what the third option to the PACKAGECONFIG
flag is for.

+CFLAG += "${@bb.utils.contains('PACKAGECONFIG', 'cryptodev-linux',
'-DHAVE_CRYPTODEV -DUSE_CRYPTODEV_DIGESTS', '', d)}"

If you add those to the first value in the PACKAGECONFIG flag list then you
could just add PACKAGECONFIG_CONFARGS to CFLAG, and using PACKAGECONFIG for
other options in the future is then trivial.

Ross
-- 
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel

[oe] Moving GNOME 2 recipes to an external meta-gnome2 layer?

[Burton, Ross]

Hi,

The meta-gnome layer in the meta-openembedded repository currently contains
a mix of GNOME 2 and GNOME 3 recipes.  Considering GNOME 3 was released in
2011, so GNOME 2 has been unmaintained for six years now, I think it is
time to consider splitting out the GNOME 2 recipes into a meta-gnome2 layer
that can be hosted somewhere else: meta-oe isn't the place for recipes to
go and die, it should be useful and relevant.  I mean, one of the most
recent commits was a fix to Dates to fix it under clang.  We (OpenedHand)
abandoned that in 2009!

So, does anyone actually use the GNOME 2 platform still?  Does anyone
volunteer to maintain this layer?  Should I instead just delete the recipes
instead, reducing meta-gnome down to the few recipes that are part of the
GNOME 3 stack?

Ross
-- 
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel

Re: [oe] [PATCH 00/10] Fix compile errors if distro feature openssl-no-weak-ciphers exists

[Burton, Ross]

On 5 July 2017 at 09:11,  wrote:

> Patches to add distro feature openssl-no-weak-ciphers have been sent to
> oe-core.
>

FWIW I'm still not very keen on a distro feature for this.

Ross
-- 
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel

Re: [oe] [meta-oe][PATCH 7/8] meson: use tarball instead of git checkout

[Burton, Ross]

That's not a generated archive but an uploaded tarball.

Ross

On 26 June 2017 at 16:26, Martin Jansa  wrote:

> I still don't trust github archives/releases, can we skip this one?
>
> On Mon, Jun 26, 2017 at 5:11 PM, Ross Burton 
> wrote:
>
>> Signed-off-by: Ross Burton 
>> ---
>>  meta-oe/recipes-devtools/meson/meson_0.40.1.bb | 10 +++---
>>  1 file changed, 3 insertions(+), 7 deletions(-)
>>
>> diff --git a/meta-oe/recipes-devtools/meson/meson_0.40.1.bb
>> b/meta-oe/recipes-devtools/meson/meson_0.40.1.bb
>> index ab54b8c79..f33256a10 100644
>> --- a/meta-oe/recipes-devtools/meson/meson_0.40.1.bb
>> +++ b/meta-oe/recipes-devtools/meson/meson_0.40.1.bb
>> @@ -4,13 +4,9 @@ SUMMARY = "A high performance build system"
>>  LICENSE = "Apache-2.0"
>>  LIC_FILES_CHKSUM = "file://COPYING;md5=3b83ef96387f14655fc854ddc3c6bd57"
>>
>> -SRC_URI = " \
>> -git://github.com/mesonbuild/meson.git \
>> -"
>> -
>> -SRCREV = "b25d3e4d3f2b4d37029a507cc089bdde643c6240"
>> -
>> -S = "${WORKDIR}/git"
>> +SRC_URI = "https://github.com/mesonbuild/meson/releases/download/${PV}
>> /${BP}.tar.gz"
>> +SRC_URI[md5sum] = "8475b19d5f5f3bd5c40f4bb1f31b93f3"
>> +SRC_URI[sha256sum] = "890ce46e713ea0d061f8203c99fa7
>> d38645354a62e4c207c38ade18db852cbf5"
>>
>>  inherit setuptools3
>>
>> --
>> 2.11.0
>>
>> --
>> ___
>> Openembedded-devel mailing list
>> Openembedded-devel@lists.openembedded.org
>> http://lists.openembedded.org/mailman/listinfo/openembedded-devel
>>
>
>
-- 
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel

Re: [oe] [meta-oe][PATCH 2/3] meson: fix build/host confusion for bbclass

[Burton, Ross]

On 16 June 2017 at 12:19, Linus Svensson  wrote:

> What is the difference?
>
> As far as I understand, bitbake and meson use the same terminology. meson
> is supposed to get the build machine info from the environment, not the
> cross file.
>

Linus is right.  Quoting the documentation:

autotools:
--build: In which system the program will be built.
--host: In which system the generated program will run.

Meson:
build machine is the computer that is doing the actual compiling
host machine is the machine on which the compiled binary will run

So changing host_machine to use BUILD_* variables is wrong.

Ross
-- 
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel

Re: [oe] [meta-oe][PATCH v2] meson: add LDFLAGS to bbclass C/C++ link arguments

[Burton, Ross]

On 8 June 2017 at 18:34, Adam C. Foltzer  wrote:

> -cpu = '${TARGET_ARCH}'
> +cpu = '${TUNE_PKGARCH}'
>

This line was retracted in a later mail but the patch was merged.


>  SRC_URI = " \
>  git://github.com/mesonbuild/meson.git \
> -file://native_bindir.patch \
>  "
>

Was this patch meant to be removed?  If so the file needs to be removed too.

Ross
-- 
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel

Re: [oe] [meta-oe][PATCH 1/1 v2] microcode-ctl: add new recipe

[Burton, Ross]

On 15 June 2017 at 02:36,  wrote:

> The microcode_ctl utility is a companion to the
> IA32 microcode driver.
>

Wouldn't it make sense for this to be in meta-intel, alongside the
microcode? Also what's the difference between this and iucode-tool, which
is already in meta-intel?

Ross
-- 
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel

Re: [oe] [PATCH] meson: don't pass localedir

[Burton, Ross]

On 5 June 2017 at 20:41, Christopher Larson  wrote:

> Maybe we should think about renaming that variable for clarity.
>

Yes.  Not sure what to though.

Ross
-- 
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel

Re: [oe] [PATCH 1/2] meson: enable process reporting for do_compile

[Burton, Ross]

Just realised that my local master was out of date and these don't apply
anymore, I'll rebase and resend.

Ross

On 2 June 2017 at 16:55, Ross Burton  wrote:

> Ninja outputs progress information during a build (for example [12/34]) so
> we
> can tell bitbake how to parse this.
>
> Signed-off-by: Ross Burton 
> ---
>  meta-oe/classes/meson.bbclass | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/meta-oe/classes/meson.bbclass b/meta-oe/classes/meson.bbclass
> index 5a04134..42f4005 100644
> --- a/meta-oe/classes/meson.bbclass
> +++ b/meta-oe/classes/meson.bbclass
> @@ -75,6 +75,7 @@ meson_do_configure() {
>  fi
>  }
>
> +do_compile[progress] = "outof:^\[(\d+)/(\d+)\]"
>  meson_do_compile() {
>  ninja ${PARALLEL_MAKE}
>  }
> --
> 2.8.1
>
>
-- 
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel

Re: [oe] [meta-oe][PATCH] Meson update and fix

[Burton, Ross]

On 2 June 2017 at 21:34, Adam Foltzer  wrote:

> These patches respectively fix some issues with the Meson bitbake class,
> and update the devtool recipe to the latest version. These issues arose
> when creating a new recipe for a C++ project that uses Meson, but the
> additional linker flags should help with C recipes as well.
>
> The diffs are available here:
> https://github.com/openembedded/meta-openembedded/compare/master...
> acfoltzer:meson-updates
>
> Regards,
> Adam
>

The patches need to be submitted to the list, using git-send-email ideally.

Please split them up more, for example fixing the HOST/BUILD confusion is
one commit, and the C++ flags another.

Ross
-- 
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel

Re: [oe] Cairo egl / glesv2 PACKAGECONFIG dependency hell

[Burton, Ross]

On 11 May 2017 at 09:08, Boszormenyi Zoltan  wrote:

> Please fix it either way: remove PACKAGECONFIG[egl] from cairo
> or add native build to mesa.
>

Or only enable egl in target builds (using a class override), which is the
easier, simpler, and correct fix.

Ross
-- 
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel

Re: [oe] [yocto] [OE-core] [RFT] gcc7 and glibc-2.26 recipes

[Burton, Ross]

On 25 April 2017 at 23:35, Nathan Lynch  wrote:

> Done:
> http://lists.openembedded.org/pipermail/openembedded-core/
> 2017-April/136086.html
>

Thanks!

Ross
-- 
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel

Re: [oe] [yocto] [OE-core] [RFT] gcc7 and glibc-2.26 recipes

[Burton, Ross]

On 24 April 2017 at 23:00, Nathan Lynch  wrote:

> Does adding this patch to lttng-modules work around it?
>

Yes, it fixes the build here.  I'll throw it at the autobuilder now, can
you send a patch with a commit message that isn't "someone told me to try
this"? :)

Ross
-- 
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel

Re: [oe] [OE-core] [RFT] gcc7 and glibc-2.26 recipes

[Burton, Ross]

On 24 April 2017 at 01:31, Bruce Ashfield  wrote:

> I see that it was the 4.1 kernel, which is expected to fail. I haven't
> looked into backporting gcc7 fixes
> that far, but if there's demand, it is something we can consider/look into.
>

There's demand in that the gcc7 merge is blocking on either kernel 4.1
being fixed or removed.  Your choice. :)

Ross
-- 
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel

Re: [oe] [OE-core] [RFT] gcc7 and glibc-2.26 recipes

[Burton, Ross]

On 24 April 2017 at 17:10, Khem Raj  wrote:

> thanks, yes I haven't been testing SDK yet, whats the gcc version on
> your build host ?
>

It's failing across the autobuilder so I'd suggest it's not specific to a
gcc version.

It also breaks on my personal machine, which is Debian Jessie(ish) with gcc
4.9.2

Ross
-- 
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel