[OE-core] read-only-rootfs and EFI configuration

[Paul Eggleton]

Hi folks,

So I was looking at the following commit today:

  
http://cgit.openembedded.org/openembedded-core/commit/?id=cfc09de06ecc12bb42181004689e881c75072665

Given we've just moved the creation of the configuration to its own recipe 
(grub-bootconf or systemd-bootconf depending on the bootloader selected)
doesn't that now pose a problem for the effectiveness of this change given
that it's setting it at the image level? Let me know if I'm missing something.

Cheers,
Paul

-- 

Paul Eggleton
Intel Open Source Technology Centre


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

Re: [OE-core] [oe-commits] [openembedded-core] 117/124: libuser: remove

[Hongxu Jia]

On 2018年05月07日 17:19, Robert Yang wrote:


Hi Ross,

The recipe
meta-openembedded/meta-gnome/recipes-support/usermode/usermode_1.111.bb

depends on libuser, so may be we need add libuser to meta-gnome, please ?


I've sent the patch to oe-dev which add liubuser to meta-gnome.

//Hongxu



// Robert


On 05/04/2018 04:57 PM, g...@git.openembedded.org 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 11ee7989b2f0709119c450819cd66bad70082a93
Author: Ross Burton 
AuthorDate: Fri Apr 27 20:10:24 2018 +0100

 libuser: remove
  This isn't used by anything in oe-core (or in common use in 
general, only one

 package in Debian depends on it), so remove it from oe-core.
  Signed-off-by: Ross Burton 
---
  meta/conf/distro/include/maintainers.inc   |  1 -
  .../libuser/libuser/0001-Check-for-issetugid.patch | 62 
--

  ...es.c-parse_field-fix-string-formating-in-.patch | 34 
  .../libuser/0002-remove-unused-execinfo.h.patch    | 27 --
  meta/recipes-extended/libuser/libuser_0.62.bb  | 35 
  .../packagegroup-core-full-cmdline.bb  |  1 -
  6 files changed, 160 deletions(-)

diff --git a/meta/conf/distro/include/maintainers.inc 
b/meta/conf/distro/include/maintainers.inc

index c2ab132..4fb9fc2 100644
--- a/meta/conf/distro/include/maintainers.inc
+++ b/meta/conf/distro/include/maintainers.inc
@@ -387,7 +387,6 @@ RECIPE_MAINTAINER_pn-liburcu = "Alexander Kanavin 
"
  RECIPE_MAINTAINER_pn-liburi-perl = "Tim Orling 
"
  RECIPE_MAINTAINER_pn-libusb-compat = "Maxin B. John 
"

  RECIPE_MAINTAINER_pn-libusb1 = "Maxin B. John "
-RECIPE_MAINTAINER_pn-libuser = "Robert Yang 
"

  RECIPE_MAINTAINER_pn-libva = "Anuj Mittal "
  RECIPE_MAINTAINER_pn-libva-utils = "Anuj Mittal 
"

  RECIPE_MAINTAINER_pn-libvorbis = "Tanu Kaskinen "
diff --git 
a/meta/recipes-extended/libuser/libuser/0001-Check-for-issetugid.patch 
b/meta/recipes-extended/libuser/libuser/0001-Check-for-issetugid.patch

deleted file mode 100644
index 79756b9..000
--- 
a/meta/recipes-extended/libuser/libuser/0001-Check-for-issetugid.patch

+++ /dev/null
@@ -1,62 +0,0 @@
-From d0537cb7f2dc5877700ad78dfd191515379d4edc Mon Sep 17 00:00:00 2001
-From: Khem Raj 
-Date: Thu, 7 Jan 2016 02:22:51 +
-Subject: [PATCH 1/2] Check for issetugid()
-
-If secure version of getenv is not there then we can use
-issetugid() as aid to call getenv()
-
-Signed-off-by: Khem Raj 

-Upstream-Status: Pending
-
- configure.ac |  1 +
- lib/config.c | 12 +++-
- 2 files changed, 12 insertions(+), 1 deletion(-)
-
-diff --git a/configure.ac b/configure.ac
-index 1ded1a2..ee19e1f 100644
 a/configure.ac
-+++ b/configure.ac
-@@ -125,6 +125,7 @@ AC_TYPE_OFF_T
- AC_TYPE_SIZE_T
-
- AC_CHECK_FUNCS([__secure_getenv secure_getenv])
-+AC_CHECK_FUNCS([issetugid])
-
- # Modify CFLAGS after all tests are run (some of them could fail 
because

- # of the -Werror).
-diff --git a/lib/config.c b/lib/config.c
-index 29e7120..30f9daf 100644
 a/lib/config.c
-+++ b/lib/config.c
-@@ -44,8 +44,10 @@
- #  define safe_getenv(string) secure_getenv(string)
- #elif defined(HAVE___SECURE_GETENV)
- #  define safe_getenv(string) __secure_getenv(string)
-+#elif defined(HAVE_ISSETUGID)
-+#  define safe_getenv(string) safe_getenv_issetugid(string)
- #else
--#  error Neither secure_getenv not __secure_getenv are available
-+#  error None of secure_getenv, __secure_getenv, or issetugid is 
available

- #endif
-
- struct config_config {
-@@ -59,6 +61,14 @@ struct config_key {
- GList *values;
- };
-
-+static const char*
-+safe_getenv_issetugid(const char* name)
-+{
-+    if (issetugid ())
-+    return 0;
-+    return getenv (name);
-+}
-+
- /* Compare two section names */
- static int
- compare_section_names(gconstpointer a, gconstpointer b)
---
-2.7.0
-
diff --git 
a/meta/recipes-extended/libuser/libuser/0001-modules-files.c-parse_field-fix-string-formating-in-.patch 
b/meta/recipes-extended/libuser/libuser/0001-modules-files.c-parse_field-fix-string-formating-in-.patch 


deleted file mode 100644
index 7c47df2..000
--- 
a/meta/recipes-extended/libuser/libuser/0001-modules-files.c-parse_field-fix-string-formating-in-.patch

+++ /dev/null
@@ -1,34 +0,0 @@
-From a4857911ece5ebfcdef42aee4c070eb216f39597 Mon Sep 17 00:00:00 2001
-From: =?UTF-8?q?An=C3=ADbal=20Lim=C3=B3n?= 


-Date: Fri, 13 May 2016 11:40:13 -0500
-Subject: [PATCH] modules/files.c: parse_field fix string formating in
- g_warnings
-MIME-Version: 1.0
-Content-Type: text/plain; charset=UTF-8
-Content-Transfer-Encoding: 

Re: [OE-core] [PATCH 1/1] oe-depends-dot: print dependency chains for '--why' option

[Robert Yang]

On 05/08/2018 10:19 AM, Chen Qi wrote:

When using '--why' option, we currently only list elements.
It's better to print out dependency chains. This patch adds
such abitility.

e.g.
   $ oe-depends-dot -k util-linux -w recipe-depends.dot
   Because: packagegroup-core-boot systemd-compat-units systemd shadow 
core-image-minimal dbus e2fsprogs
   core-image-minimal -> packagegroup-core-boot -> systemd-compat-units -> systemd -> 
dbus -> shadow -> util-linux
   core-image-minimal -> packagegroup-core-boot -> systemd-compat-units -> systemd -> 
dbus -> e2fsprogs -> util-linux


Looks great to me.

// Robert



Signed-off-by: Chen Qi 
---
  scripts/oe-depends-dot | 46 ++
  1 file changed, 46 insertions(+)

diff --git a/scripts/oe-depends-dot b/scripts/oe-depends-dot
index 5cec23b..6c7e9d3 100755
--- a/scripts/oe-depends-dot
+++ b/scripts/oe-depends-dot
@@ -47,6 +47,51 @@ class Dot(object):
  if len(sys.argv) != 3 and len(sys.argv) < 5:
  print('ERROR: Not enough args, see --help for usage')
  
+@staticmethod

+def insert_dep_chain(chain, rdeps, alldeps):
+"""
+insert elements to chain from rdeps, according to alldeps
+"""
+# chain should at least contain one element
+if len(chain) == 0:
+raise
+
+inserted_elements = []
+for rdep in rdeps:
+if rdep in chain:
+continue
+else:
+for i in range(0, len(chain)-1):
+if chain[i] in alldeps[rdep] and rdep in 
alldeps[chain[i+1]]:
+chain.insert(i+1, rdep)
+inserted_elements.append(rdep)
+break
+if chain[-1] in alldeps[rdep] and rdep not in chain:
+chain.append(rdep)
+inserted_elements.append(rdep)
+return inserted_elements
+
+@staticmethod
+def print_dep_chains(key, rdeps, alldeps):
+rlist = rdeps.copy()
+chain = []
+removed_rdeps = [] # hold rdeps removed from rlist
+
+chain.append(key)
+while (len(rlist) != 0):
+# insert chain from rlist
+inserted_elements = Dot.insert_dep_chain(chain, rlist, alldeps)
+if not inserted_elements:
+if chain[-1] in rlist:
+rlist.remove(chain[-1])
+removed_rdeps.append(chain[-1])
+chain.pop()
+continue
+else:
+# insert chain from removed_rdeps
+Dot.insert_dep_chain(chain, removed_rdeps, alldeps)
+print(' -> '.join(list(reversed(chain
+
  def main(self):
  #print(self.args.dotfile[0])
  # The format is {key: depends}
@@ -109,6 +154,7 @@ class Dot(object):
  if self.args.key in v and not k in reverse_deps:
  reverse_deps.append(k)
  print('Because: %s' % ' '.join(reverse_deps))
+Dot.print_dep_chains(self.args.key, reverse_deps, depends)
  
  if __name__ == "__main__":

  try:


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

[OE-core] [PATCH 1/1] oe-depends-dot: print dependency chains for '--why' option

[Chen Qi]

When using '--why' option, we currently only list elements.
It's better to print out dependency chains. This patch adds
such abitility.

e.g.
  $ oe-depends-dot -k util-linux -w recipe-depends.dot
  Because: packagegroup-core-boot systemd-compat-units systemd shadow 
core-image-minimal dbus e2fsprogs
  core-image-minimal -> packagegroup-core-boot -> systemd-compat-units -> 
systemd -> dbus -> shadow -> util-linux
  core-image-minimal -> packagegroup-core-boot -> systemd-compat-units -> 
systemd -> dbus -> e2fsprogs -> util-linux

Signed-off-by: Chen Qi 
---
 scripts/oe-depends-dot | 46 ++
 1 file changed, 46 insertions(+)

diff --git a/scripts/oe-depends-dot b/scripts/oe-depends-dot
index 5cec23b..6c7e9d3 100755
--- a/scripts/oe-depends-dot
+++ b/scripts/oe-depends-dot
@@ -47,6 +47,51 @@ class Dot(object):
 if len(sys.argv) != 3 and len(sys.argv) < 5:
 print('ERROR: Not enough args, see --help for usage')
 
+@staticmethod
+def insert_dep_chain(chain, rdeps, alldeps):
+"""
+insert elements to chain from rdeps, according to alldeps
+"""
+# chain should at least contain one element
+if len(chain) == 0:
+raise
+
+inserted_elements = []
+for rdep in rdeps:
+if rdep in chain:
+continue
+else:
+for i in range(0, len(chain)-1):
+if chain[i] in alldeps[rdep] and rdep in 
alldeps[chain[i+1]]:
+chain.insert(i+1, rdep)
+inserted_elements.append(rdep)
+break
+if chain[-1] in alldeps[rdep] and rdep not in chain:
+chain.append(rdep)
+inserted_elements.append(rdep)
+return inserted_elements
+
+@staticmethod
+def print_dep_chains(key, rdeps, alldeps):
+rlist = rdeps.copy()
+chain = []
+removed_rdeps = [] # hold rdeps removed from rlist
+
+chain.append(key)
+while (len(rlist) != 0):
+# insert chain from rlist
+inserted_elements = Dot.insert_dep_chain(chain, rlist, alldeps)
+if not inserted_elements:
+if chain[-1] in rlist:
+rlist.remove(chain[-1])
+removed_rdeps.append(chain[-1])
+chain.pop()
+continue
+else:
+# insert chain from removed_rdeps
+Dot.insert_dep_chain(chain, removed_rdeps, alldeps)
+print(' -> '.join(list(reversed(chain
+
 def main(self):
 #print(self.args.dotfile[0])
 # The format is {key: depends}
@@ -109,6 +154,7 @@ class Dot(object):
 if self.args.key in v and not k in reverse_deps:
 reverse_deps.append(k)
 print('Because: %s' % ' '.join(reverse_deps))
+Dot.print_dep_chains(self.args.key, reverse_deps, depends)
 
 if __name__ == "__main__":
 try:
-- 
1.9.1

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

[OE-core] [PATCH 0/1] oe-depends-dot: print dependency chains for '--why' option

[Chen Qi]

The following changes since commit f301a3bc110608c3684c78dd62e276beea73bd94:

  settings-daemon: Drop pointless apply=yes in SRC_URI (2018-05-04 13:28:06 
+0100)

are available in the git repository at:

  git://git.pokylinux.org/poky-contrib ChenQi/improve-oe-depends-dot
  
http://git.pokylinux.org/cgit.cgi/poky-contrib/log/?h=ChenQi/improve-oe-depends-dot

Chen Qi (1):
  oe-depends-dot: print dependency chains for '--why' option

 scripts/oe-depends-dot | 46 ++
 1 file changed, 46 insertions(+)

-- 
1.9.1

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

Re: [OE-core] [daisy][PATCH 0/6] SRC_URI updates and minor build fixes

[Andre McCurdy]

On Tue, Mar 20, 2018 at 7:42 PM, Andre McCurdy  wrote:
> Daisy has now (long since) left upstream maintenance and entered into
> community support. As a member of a community which still actively
> develops against this version of OE, I would like to propose the
> following updates.

Ping.

Are these kind of updates OK? Or are there objections to the community
trying to support historical releases? There are many millions of
devices in the field that I know of which are still being actively
developed and maintained on top of OE 1.6.

> Andre McCurdy (4):
>   gmp_4.2.1: fix build for MIPS
>   ncurses: fix build with gcc 5
>   binutils: fix build with gcc 5
>   mesa: fix SRC_URI
>
> Khem Raj (1):
>   kernel.bbclass: Remove bashism
>
> Krzysztof Sywula (1):
>   dtc: old SRC_URI died, changing to new working one
>
>  meta/classes/kernel.bbclass|  2 +-
>  .../ncurses/ncurses-5.9/ncurses-5.9-gcc-5.patch| 53 +++
>  meta/recipes-core/ncurses/ncurses_5.9.bb   |  1 +
>  meta/recipes-devtools/binutils/binutils-2.24.inc   |  1 +
>  ...86.c-Werror-logical-not-parentheses-error.patch | 61 
> ++
>  meta/recipes-graphics/mesa/mesa_9.2.5.bb   |  2 +-
>  meta/recipes-kernel/dtc/dtc.inc|  2 +-
>  .../avoid-h-asm-constraint-for-MIPS.patch  | 57 
>  meta/recipes-support/gmp/gmp_4.2.1.bb  |  1 +
>  9 files changed, 177 insertions(+), 3 deletions(-)
>  create mode 100644 
> meta/recipes-core/ncurses/ncurses-5.9/ncurses-5.9-gcc-5.patch
>  create mode 100644 
> meta/recipes-devtools/binutils/binutils/0001-Fix-tc-i386.c-Werror-logical-not-parentheses-error.patch
>  create mode 100644 
> meta/recipes-support/gmp/gmp-4.2.1/avoid-h-asm-constraint-for-MIPS.patch
>
> --
> 1.9.1
>
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [yocto] Yocto Project Status WW19’18

[akuster808]

On 05/07/2018 08:01 AM, Jolley, Stephen K wrote:
>
> Current Dev Position: YP 2.5 is in QA.
>
> Next Deadline: YP 2.5 M4 release is 4/27/18
>
>  
>
> SWAT Team Rotation:
>
> · SWAT lead is currently: Stephano
>
I am covering this week for stephano.
- armin
>
> · SWAT team rotation: Stephano -> Maxin  on May 11, 2018
>


> · SWAT team rotation: Maxin-> Armin on May 18, 2018
>
> · https://wiki.yoctoproject.org/wiki/Yocto_Build_Failure_Swat_Team
>
>  
>
> Key Status/Updates:
>
> · 2.5 rc1 should be due from QA early this week. It is 96%
> complete. See: https://wiki.yoctoproject.org/wiki/2.5_QA_Status
>
> · The need for any rc2 is still to be determined when the
> report is complete.
>
> · The technical call on 1st May started discussions on 2.6
> planning. Some threads were started on the openembedded-architecture
> mailing list for some of the topics which need discussion. The email
> linked to below details the planning process we will be following
> along with some of the possible ideas for 2.6:
> http://lists.openembedded.org/pipermail/openembedded-core/2018-April/150040.html
>
> · A further 2.6 planning meeting will be scheduled at the same
> time as the original meeting on 15th May to continue the discussion
> (8am PST, 4pm GMT).
>
> · We have started merging patches into master again to clear
> some of the backlog, particularly the recipe upgrades. This improved
> the overall patch count in metrics below.
>
>  
>
> Planned upcoming dot releases:
>
> · YP 2.3.4 (Pyro) will be built after 2.5
>
> · YP 2.2.4 (Morty) will be built after 2.5
>
> · YP 2.4.3 (Rocko) is planned for post YP 2.5
>
>  
>
> Key YP 2.5 Dates are:
>
> · YP 2.5 M4 release of 4/27/18
>
>  
>
> Tracking Metrics:
>
> · WDD 2550 (last week
> 2508)(https://wiki.yoctoproject.org/charts/combo.html)
>
> · Patches  
>
> o    Total patches found: 1590 (last week 1635)
>
> o    Percentage of patches in the Pending State: 47% (last week 46%)
>
>  
>
> Key Status Links for YP:
>
> https://wiki.yoctoproject.org/wiki/Yocto_Project_v2.5_Status
>
> https://wiki.yoctoproject.org/wiki/Yocto_2.5_Schedule
>
> https://wiki.yoctoproject.org/wiki/Yocto_2.5_Features
>
>  
>
> The Status reports are now stored on the wiki at:
> https://wiki.yoctoproject.org/wiki/Weekly_Status
>
>  
>
> [If anyone has suggestions for other information you’d like to see on
> this weekly status update, let us know!]
>
>  
>
> Thanks,
>
>  
>
> */Stephen K. Jolley/**//*
>
> *Yocto Project Project Manager*
>
> *INTEL, MS JF1-255, 2111 N.E. 25th Avenue, Hillsboro, OR 97124 *
>
> (    *Cell*:    (208) 244-4460
>
> * *Email*: _stephen.k.jolley@intel.com_
>
>  
>
>
>

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

Re: [OE-core] sdk

[Joshua Watt]

On Mon, May 7, 2018, 17:26 C Michael Sundius  wrote:

> Hi All,
>
> I've been scratching my head all day about why I can build my recipe under
> bitbake, but whne I try to build w/ the SDK I create w/ bitbake -c
> populate_sdk  it cant find the headers for the libraries that I
> depend upon.
>
> somehow when I create the sdk, it does not include the header files for
> the dependent libs. I see the .so files in the sysroot, but I don't see any
> of the header files.
>
> I don't see any of the headers for libxml2,  or the other libs.. those are
> simply standard recipes from yocto.
>
> any thoughts what am i doing wrong?
>

Maybe  "dev-pkgs" was accidentally removed from SDKIMAGE_FEATURES?


> ---
> inherit abc-cmake
> inherit pkgconfig
> inherit systemd
>
> EXTRA_OECMAKE_append = "\
> -DENABLE_SYSTEMD=ON \
> -DENABLE_API=ON \
> -DENABLE_CONFIG=ON \
> -DENABLE_UNITTEST=ON \
> -DENABLE_TUNCTL=ON \
> -DENABLE_WATCHDOG=ON \
> -DENABLE_AESNI=ON \
> -DFORCE_ALIGNMENT=OFF \
> -DENABLE_TRACE=OFF \
> -DENABLE_TUNING=OFF \
> "
>
> EXTRA_OECMAKE_append_abc-dev = " -DENABLE_TRACE=ON"
> EXTRA_OECMAKE_append_abc-dbg = " -DENABLE_TUNING=ON"
>
> LIC_FILES_CHKSUM = "file://COPYING;md5=8b5f7a1e89273c8fd243ca57ad73e483"
>
> SRC_URI += "file://myprog.service"
> SRC_URI += "file://myprog.conf"
>
> SYSTEMD_SERVICE_${PN} = "myprog.service"
> SYSTEMD_AUTO_ENABLE_${PN} = "enable"
>
> do_install_append () {
> #install systemd service file
> install -d ${D}${systemd_system_unitdir}
> install -m 0644 ${WORKDIR}/udpf.service
> ${D}${systemd_system_unitdir}
>
> #install tmpfiles.d configuration file
> install -d ${D}${sysconfdir}/tmpfiles.d
> install -m 0644 ${WORKDIR}/udpf.conf ${D}${sysconfdir}/tmpfiles.d/
> }
>
>
> PACKAGES =+ "${PN}-utilities ${PN}-samples ${PN}-conf"
>
> FILES_${PN} += "${sbindir}/dpfd"
> FILES_${PN}-dev += "\
> ${sbindir}/segtest \
> ${sbindir}/ttest \
> ${sbindir}/workq \
> "
> FILES_${PN}-utilities += "${sbindir}/tunctl ${sbindir}/tapctl"
> FILES_${PN}-samples += "${datadir}/*"
> FILES_${PN}-conf += "${sysconfdir}/dpf/*"
>
> RDEPENDS_${PN}-samples += "python"
> DEPENDS = "libxml2 libevent nss systemd concurrencykit netmap"
> RDEPENDS_${PN} = "libxml2 libevent nss systemd python-core
> kernel-module-tun netmap"
> RDEPENDS_${PN} += "libxml2 libevent nss-dev systemd python-core
> kernel-module-tun netmap"
>
> --
> ___
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core
>
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH] tclibc-baremetal: Adds virtual/crypt to ASSUME_PROVIDED

[Andre McCurdy]

On Mon, May 7, 2018 at 2:50 PM, Alejandro Enedino Hernandez Samaniego
 wrote:
> When trying to build meta-toolchain using TCLIBC = "baremetal"
> bitbake throws an error due to a mising dependency:
>
> ERROR: Nothing PROVIDES 'virtual/crypt'
>
> glibc PROVIDES virtual/crypt but was skipped:
> PREFERRED_PROVIDER_virtual/libc set to musl, not glibc
> musl PROVIDES virtual/crypt but was skipped:
> PREFERRED_PROVIDER_virtual/i586-poky-elf-libc-for-gcc set to baremetal,
> not musl
> libxcrypt PROVIDES virtual/crypt but was skipped: Recipe only applies in
> nativesdk case for now
>
> This is caused by the changes on commit:
> 29f65bda6d2c9fea4adb125c4857ee64f9312b9f
> nativesdk-glibc: Split glibc and libcrypt to use libxcrypt instead
>
> This is where the concept of virtual/crypt was introduced.
>
> This patch adds virtual/crypt to ASSUME_PROVIDED on tclibc-baremetal,
> providing the missing wiring to build meta-toolchain on baremetal
> correctly.
>
> Signed-off-by: Alejandro Enedino Hernandez Samaniego 
> ---
>  meta/conf/distro/include/tclibc-baremetal.inc | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/meta/conf/distro/include/tclibc-baremetal.inc 
> b/meta/conf/distro/include/tclibc-baremetal.inc
> index a8ce6d3..8d570f0 100644
> --- a/meta/conf/distro/include/tclibc-baremetal.inc
> +++ b/meta/conf/distro/include/tclibc-baremetal.inc
> @@ -8,7 +8,7 @@ LIBCEXTENSION = ""
>  LIBCOVERRIDE = ":libc-baremetal"
>  OVERRIDES .= "${LIBCOVERRIDE}"
>
> -ASSUME_PROVIDED += "virtual/libc virtual/libiconv"
> +ASSUME_PROVIDED += "virtual/libc virtual/libiconv virtual/crypt"
>
>  PREFERRED_PROVIDER_virtual/libc ?= "musl"
>  PREFERRED_PROVIDER_virtual/libiconv ?= "musl"

Not directly related to this fix, but why does tclibc-baremetal.inc
set PREFERRED_PROVIDER_virtual/libc to musl?

> --
> 2.7.4
>
> This email and any attachments are intended for the sole use of the named 
> recipient(s) and contain(s) confidential information that may be proprietary, 
> privileged or copyrighted under applicable law. If you are not the intended 
> recipient, do not read, copy, or forward this email message or any 
> attachments. Delete this email message and any attachments immediately.
> --
> ___
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] sdk

[C Michael Sundius]

Hi All,

I've been scratching my head all day about why I can build my recipe under
bitbake, but whne I try to build w/ the SDK I create w/ bitbake -c
populate_sdk  it cant find the headers for the libraries that I
depend upon.

somehow when I create the sdk, it does not include the header files for the
dependent libs. I see the .so files in the sysroot, but I don't see any of
the header files.

I don't see any of the headers for libxml2,  or the other libs.. those are
simply standard recipes from yocto.

any thoughts what am i doing wrong?

---
inherit abc-cmake
inherit pkgconfig
inherit systemd

EXTRA_OECMAKE_append = "\
-DENABLE_SYSTEMD=ON \
-DENABLE_API=ON \
-DENABLE_CONFIG=ON \
-DENABLE_UNITTEST=ON \
-DENABLE_TUNCTL=ON \
-DENABLE_WATCHDOG=ON \
-DENABLE_AESNI=ON \
-DFORCE_ALIGNMENT=OFF \
-DENABLE_TRACE=OFF \
-DENABLE_TUNING=OFF \
"

EXTRA_OECMAKE_append_abc-dev = " -DENABLE_TRACE=ON"
EXTRA_OECMAKE_append_abc-dbg = " -DENABLE_TUNING=ON"

LIC_FILES_CHKSUM = "file://COPYING;md5=8b5f7a1e89273c8fd243ca57ad73e483"

SRC_URI += "file://myprog.service"
SRC_URI += "file://myprog.conf"

SYSTEMD_SERVICE_${PN} = "myprog.service"
SYSTEMD_AUTO_ENABLE_${PN} = "enable"

do_install_append () {
#install systemd service file
install -d ${D}${systemd_system_unitdir}
install -m 0644 ${WORKDIR}/udpf.service
${D}${systemd_system_unitdir}

#install tmpfiles.d configuration file
install -d ${D}${sysconfdir}/tmpfiles.d
install -m 0644 ${WORKDIR}/udpf.conf ${D}${sysconfdir}/tmpfiles.d/
}


PACKAGES =+ "${PN}-utilities ${PN}-samples ${PN}-conf"

FILES_${PN} += "${sbindir}/dpfd"
FILES_${PN}-dev += "\
${sbindir}/segtest \
${sbindir}/ttest \
${sbindir}/workq \
"
FILES_${PN}-utilities += "${sbindir}/tunctl ${sbindir}/tapctl"
FILES_${PN}-samples += "${datadir}/*"
FILES_${PN}-conf += "${sysconfdir}/dpf/*"

RDEPENDS_${PN}-samples += "python"
DEPENDS = "libxml2 libevent nss systemd concurrencykit netmap"
RDEPENDS_${PN} = "libxml2 libevent nss systemd python-core
kernel-module-tun netmap"
RDEPENDS_${PN} += "libxml2 libevent nss-dev systemd python-core
kernel-module-tun netmap"
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH] tclibc-baremetal: Adds virtual/crypt to ASSUME_PROVIDED

[Alejandro Enedino Hernandez Samaniego]

When trying to build meta-toolchain using TCLIBC = "baremetal"
bitbake throws an error due to a mising dependency:

ERROR: Nothing PROVIDES 'virtual/crypt'

glibc PROVIDES virtual/crypt but was skipped:
PREFERRED_PROVIDER_virtual/libc set to musl, not glibc
musl PROVIDES virtual/crypt but was skipped:
PREFERRED_PROVIDER_virtual/i586-poky-elf-libc-for-gcc set to baremetal,
not musl
libxcrypt PROVIDES virtual/crypt but was skipped: Recipe only applies in
nativesdk case for now

This is caused by the changes on commit:
29f65bda6d2c9fea4adb125c4857ee64f9312b9f
nativesdk-glibc: Split glibc and libcrypt to use libxcrypt instead

This is where the concept of virtual/crypt was introduced.

This patch adds virtual/crypt to ASSUME_PROVIDED on tclibc-baremetal,
providing the missing wiring to build meta-toolchain on baremetal
correctly.

Signed-off-by: Alejandro Enedino Hernandez Samaniego 
---
 meta/conf/distro/include/tclibc-baremetal.inc | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/conf/distro/include/tclibc-baremetal.inc 
b/meta/conf/distro/include/tclibc-baremetal.inc
index a8ce6d3..8d570f0 100644
--- a/meta/conf/distro/include/tclibc-baremetal.inc
+++ b/meta/conf/distro/include/tclibc-baremetal.inc
@@ -8,7 +8,7 @@ LIBCEXTENSION = ""
 LIBCOVERRIDE = ":libc-baremetal"
 OVERRIDES .= "${LIBCOVERRIDE}"

-ASSUME_PROVIDED += "virtual/libc virtual/libiconv"
+ASSUME_PROVIDED += "virtual/libc virtual/libiconv virtual/crypt"

 PREFERRED_PROVIDER_virtual/libc ?= "musl"
 PREFERRED_PROVIDER_virtual/libiconv ?= "musl"
--
2.7.4

This email and any attachments are intended for the sole use of the named 
recipient(s) and contain(s) confidential information that may be proprietary, 
privileged or copyrighted under applicable law. If you are not the intended 
recipient, do not read, copy, or forward this email message or any attachments. 
Delete this email message and any attachments immediately.
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] python recipes with extensions fail to find/link with proper libraries

[Francesco Giancane]

Hi Alejandro,

Thank you for your support. I will try to explain better the situation. I
can attach the recipes but it is useless, the problem is not at recipe
level.

python3-numpy has an optional dependency on BLAS interface, and openblas is
an implementation of that interface.
python3-scipy has a mandatory dependency on BLAS interface, and openblas is
an implementation of that interface.

So, as simple as it seems, I added a python3-numpy_%.bbappend with
DEPENDS += "openblas".

Given the fact that openblas has a lot of issues when cross compiling, I
compiled it separately on the target (Raspberry Pi 3) and then the built
package has been tar'ed and gzip'ed.

After this step, I wrote a simple recipe (openblas.bb) which install as
binary files the content of the aforementioned tar archive (obviously
setting the compatible machine with arm only). At the end of the day, this
is just a not-so-clever hack to have a working openblas on the target,
including -dev packages.

After all this effort, I expected the job to be done: given that, after my
append file, the python3-numpy recipe depends on openblas, it will be
scheduled only after openblas.
At that point, given that the recipe for python3-numpy has access to the
include files and the library development files, I expect that running
setup.py would suffice in order to find & link the python C extensions to
openblas.
Unfortunately, given that the setup.py script is executed by the
python3-native package, the path the interpreter is searching for the
native libraries are not the ones for the sys root... And thus when
setup.py searches for libopenblas.so(arm) it will fail as openblas is not
deployed on x86_64 (native) variant.

Sorry for the very long mail, but I hope that the scenario is now clearer.

Long story short, python setuptools is failing to find correct libraries
for the target, and is searching for them in the native path, where it
won't find them. (Look at my first email with log attached).

Thanks,
Francesco Giancane


Il giorno lun 7 mag 2018 alle ore 23:28 Alejandro Enedino Hernandez
Samaniego  ha scritto:

> Hello Francesco,
>
>
> Please hit the reply-all button, otherwise I wont be getting notified when
> you reply.
>
>
> I think you're doing something very specific since you're building on
> target and tweaking the build system so to help you more I would need to
> take a look at the recipes you are using.
>
>
> Alejandro
>
> On 05/04/2018 01:19 AM, Francesco Giancane wrote:
>
> Hi Alejandro,
>
> Thank you for your response.
> I know that openblas recipe is a pain, given that its Makefile is not
> correctly written with respect to cross-compilation. However, the library
> has been built locally on the target (sigh!) and then it is being deployed
> with a recipe which unpacks the built binary and copy them into the sys
> root.
>
> So, from the openblas side, everything is OK.
>
> What is actually wrong is the configuration step for python3-numpy and
> python3-scipy: in the setup.py they are instructed to search for some
> libraries (namely, openblas amongst them) but they fail to search for them
> given that the path they are searching for is the sysroot-native, rather
> than sysroot. (you can see it clearly from the logs attached in the first
> message).
>
> Installing the packages using pip3 install scipy numpy on the target
> results on a correct execution (and libraries are properly found and
> linked).
>
> Thank you,
> Francesco Giancane
>
>
>
>
> Il giorno ven 4 mag 2018 alle ore 03:01 Alejandro Enedino Hernandez
> Samaniego  ha scritto:
>
>> Hello Francesco,
>>
>>
>>
>> It would be helpful if you could provide more information about this,
>> e.g. access to your layer or your recipes, to make sure they are actually
>> being built correctly, also I would start by manually linking it against
>> the built library to see if the error is just not having them on the
>> correct path, but I seem to remember a lot of issues when trying to cross
>> compile openblas, specially for an arm MACHINE.
>>
>>
>>
>> Alejandro
>>
>>
>>
>> *From:* openembedded-core-boun...@lists.openembedded.org [mailto:
>> openembedded-core-boun...@lists.openembedded.org] *On Behalf Of *Francesco
>> Giancane
>> *Sent:* Wednesday, May 2, 2018 2:33 PM
>> *To:* OE-core 
>> *Subject:* [OE-core] python recipes with extensions fail to find/link
>> with proper libraries
>>
>>
>>
>> Hi Everyone,
>>
>> I found a problem working with python(3) and C extensions.
>>
>>
>>
>> The use-case is the recipe for python(3)-numpy, which can be linked
>> against a BLAS/LAPACK library to use accelerated matricial and vectorial
>> operations.
>>
>>
>>
>> As it is currently shipped, the recipe fails to find any proper library
>> and then does not use extensions.
>>
>>
>>
>> I wrote a custom recipe for openblas which is correctly built & deploy
>> using standard commands.
>>
>> openblas 

[OE-core] Yocto Project changes in progress

[Jeff Osier-Mixon]

 Hello everyone. I'd like to briefly address rumors around Richard Purdie's
transition from Intel to a more neutral position, and Intel's reduction in
resources for the project.

We set up the Yocto Project in 2010 through Linux Foundation, with over 20
member organizations, so it would function as a true open source project -
neutral, unbiased, and well distributed. Those things are what make open
source projects less vulnerable to any one person or company. This is
actually a very exciting transitional time for the project, and all
existing member organizations are fully behind the project. We will let
people know details as they are available.

Meanwhile, the 2.5 "Sumo" release is on the way and should be released
soon, the 2.6 planning process has started in earnest (please
participate!), and we are excited to see what the future has in store for
the project.

-- 
Jeffrey “Jefro” Osier-Mixon, Intel Corporation
Open Source Community Ecosystem Strategist
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] python recipes with extensions fail to find/link with proper libraries

[Alejandro Enedino Hernandez Samaniego]

Hello Francesco,


Please hit the reply-all button, otherwise I wont be getting notified 
when you reply.



I think you're doing something very specific since you're building on 
target and tweaking the build system so to help you more I would need to 
take a look at the recipes you are using.



Alejandro


On 05/04/2018 01:19 AM, Francesco Giancane wrote:

Hi Alejandro,

Thank you for your response.
I know that openblas recipe is a pain, given that its Makefile is not 
correctly written with respect to cross-compilation. However, the 
library has been built locally on the target (sigh!) and then it is 
being deployed with a recipe which unpacks the built binary and copy 
them into the sys root.


So, from the openblas side, everything is OK.

What is actually wrong is the configuration step for python3-numpy and 
python3-scipy: in the setup.py they are instructed to search for some 
libraries (namely, openblas amongst them) but they fail to search for 
them given that the path they are searching for is the sysroot-native, 
rather than sysroot. (you can see it clearly from the logs attached in 
the first message).


Installing the packages using pip3 install scipy numpy on the target 
results on a correct execution (and libraries are properly found and 
linked).


Thank you,
Francesco Giancane




Il giorno ven 4 mag 2018 alle ore 03:01 Alejandro Enedino Hernandez 
Samaniego > ha scritto:


Hello Francesco,

It would be helpful if you could provide more information about
this, e.g. access to your layer or your recipes, to make sure they
are actually being built correctly, also I would start by manually
linking it against the built library to see if the error is just
not having them on the correct path, but I seem to remember a lot
of issues when trying to cross compile openblas, specially for an
arm MACHINE.

Alejandro

*From:* openembedded-core-boun...@lists.openembedded.org

[mailto:openembedded-core-boun...@lists.openembedded.org
] *On
Behalf Of *Francesco Giancane
*Sent:* Wednesday, May 2, 2018 2:33 PM
*To:* OE-core >
*Subject:* [OE-core] python recipes with extensions fail to
find/link with proper libraries

Hi Everyone,

I found a problem working with python(3) and C extensions.

The use-case is the recipe for python(3)-numpy, which can be
linked against a BLAS/LAPACK library to use accelerated matricial
and vectorial operations.

As it is currently shipped, the recipe fails to find any proper
library and then does not use extensions.

I wrote a custom recipe for openblas which is correctly built &
deploy using standard commands.

openblas is also added as a DEPENDS in a bbappend file for numpy.

However, the do_compile phase cannot find the aforementioned library.

Log attached:

DEBUG: Executing shell function do_compile

blas_opt_info:

blas_mkl_info:

customize UnixCCompiler

  libraries mkl_rt not found in

['/home/fgp/poky/rpi3_64/tmp/work/cortexa7hf-neon-vfpv4-poky-linux-gnueabi/python3-numpy/1.14.2-r0/recipe-sysroot-native/usr/lib']

  NOT AVAILABLE

blis_info:

customize UnixCCompiler

  libraries blis not found in

['/home/fgp/poky/rpi3_64/tmp/work/cortexa7hf-neon-vfpv4-poky-linux-gnueabi/python3-numpy/1.14.2-r0/recipe-sysroot-native/usr/lib']

  NOT AVAILABLE

openblas_info:

customize UnixCCompiler

customize UnixCCompiler

  libraries openblas not found in

['/home/fgp/poky/rpi3_64/tmp/work/cortexa7hf-neon-vfpv4-poky-linux-gnueabi/python3-numpy/1.14.2-r0/recipe-sysroot-native/usr/lib']

  NOT AVAILABLE

atlas_3_10_blas_threads_info:

Setting PTATLAS=ATLAS

customize UnixCCompiler

  libraries tatlas not found in

['/home/fgp/poky/rpi3_64/tmp/work/cortexa7hf-neon-vfpv4-poky-linux-gnueabi/python3-numpy/1.14.2-r0/recipe-sysroot-native/usr/lib']

  NOT AVAILABLE

atlas_3_10_blas_info:

customize UnixCCompiler

  libraries satlas not found in

['/home/fgp/poky/rpi3_64/tmp/work/cortexa7hf-neon-vfpv4-poky-linux-gnueabi/python3-numpy/1.14.2-r0/recipe-sysroot-native/usr/lib']

  NOT AVAILABLE

atlas_blas_threads_info:

Setting PTATLAS=ATLAS

customize UnixCCompiler

  libraries ptf77blas,ptcblas,atlas not found in

['/home/fgp/poky/rpi3_64/tmp/work/cortexa7hf-neon-vfpv4-poky-linux-gnueabi/python3-numpy/1.14.2-r0/recipe-sysroot-native/usr/lib']

  NOT AVAILABLE

atlas_blas_info:

customize UnixCCompiler

  libraries f77blas,cblas,atlas not found in

Re: [OE-core] cURL recipe: SSL backend

[Andre McCurdy]

On Mon, May 7, 2018 at 7:17 AM, Mark Hatle  wrote:
> On 5/7/18 8:16 AM, Viacheslav Salnikov wrote:
>> Alright, good point.
>>
>> But what if I need to use openssl instead of gnutls on Target? Can it be 
>> changed
>> without side effects?

The behaviour of curl when built with gnutls -vs- openssl in OE is not
the same. There are things (maybe related to certificates?) which work
fine with openssl but don't work with gnutls. Unfortunately I don't
have many more details than that - all the OE distros I use have
switched to using openssl, so going back to figure out what's wrong
with gnutls has never been a high priority. If you switch you should
test carefully, but from my experience openssl works better.

> This is why the package config settins are present in the curl recipe.  You 
> can
> adjust the setting to use whatever TLS engine you want in your distribution or
> project configuration.
>
> PACKAGECONFIG_pn-curl = "ipv6 proxy ssl threaded-resolver zlib"

This will work, but a more robust approach may be to use _append and
_remove to change PACKAGECONFIG options (rather than over-riding with
an absolute set of options, which may become out of sync with the
defaults in the main recipe). e.g.

  PACKAGECONFIG_remove_pn-curl = "gnutls"
  PACKAGECONFIG_append_pn-curl = " ssl"

> or any other combination of available options..
>
> --Mark
>
>> Regards,
>>
>> 2018-05-07 15:59 GMT+03:00 Alexander Kanavin 
>> > >:
>>
>> On 05/07/2018 03:51 PM, Viacheslav Salnikov wrote:
>>
>> cULR is built with GNUTLS for Target but OpenSSL is used for native 
>> and SDK.
>>
>> So my question is: why GNUTLS is used only for target? Is it 
>> necessary
>> for some good reason? Documentation for cURL has no explicit answer 
>> for
>> that.
>>
>> Could somebody help me to find the answer?
>>
>>
>> I think enabling gnutls on the native side would add a ton of 
>> dependencies
>> to build, and so openssl (which is more self-contained) is selected 
>> there.
>>
>> Alex
>>
>>
>>
>>
>
> --
> ___
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH] gcc7: drop stray uClibc specific patch

[Andre McCurdy]

The patch seems to have been left behind when other uClibc specific
patches were purged from gcc in:

  
http://git.openembedded.org/openembedded-core/commit/?id=ec03023d2165b49a52b83bac1ea2f0bfded7b852

Signed-off-by: Andre McCurdy 
---
 meta/recipes-devtools/gcc/gcc-7.3.inc  |  1 -
 .../gcc/gcc-7.3/0008-c99-snprintf.patch| 28 --
 2 files changed, 29 deletions(-)
 delete mode 100644 meta/recipes-devtools/gcc/gcc-7.3/0008-c99-snprintf.patch

diff --git a/meta/recipes-devtools/gcc/gcc-7.3.inc 
b/meta/recipes-devtools/gcc/gcc-7.3.inc
index d968c32..faf0622 100644
--- a/meta/recipes-devtools/gcc/gcc-7.3.inc
+++ b/meta/recipes-devtools/gcc/gcc-7.3.inc
@@ -32,7 +32,6 @@ BASEURI ?= "${GNU_MIRROR}/gcc/gcc-${PV}/gcc-${PV}.tar.xz"
 SRC_URI = "\
${BASEURI} \
file://0001-gcc-4.3.1-ARCH_FLAGS_FOR_TARGET.patch \
-   file://0008-c99-snprintf.patch \
file://0009-gcc-poison-system-directories.patch \
file://0010-gcc-poison-dir-extend.patch \
file://0011-gcc-4.3.3-SYSROOT_CFLAGS_FOR_TARGET.patch \
diff --git a/meta/recipes-devtools/gcc/gcc-7.3/0008-c99-snprintf.patch 
b/meta/recipes-devtools/gcc/gcc-7.3/0008-c99-snprintf.patch
deleted file mode 100644
index ebd562b..000
--- a/meta/recipes-devtools/gcc/gcc-7.3/0008-c99-snprintf.patch
+++ /dev/null
@@ -1,28 +0,0 @@
-From 732f10eead61830a8aee1bf38cce892da25c35b1 Mon Sep 17 00:00:00 2001
-From: Khem Raj 
-Date: Fri, 29 Mar 2013 08:49:03 +0400
-Subject: [PATCH 08/47] c99-snprintf
-
-Signed-off-by: Khem Raj 
-
-Upstream-Status: Pending

- libstdc++-v3/include/c_std/cstdio | 2 +-
- 1 file changed, 1 insertion(+), 1 deletion(-)
-
-diff --git a/libstdc++-v3/include/c_std/cstdio 
b/libstdc++-v3/include/c_std/cstdio
-index 43969892aa2..12148457909 100644
 a/libstdc++-v3/include/c_std/cstdio
-+++ b/libstdc++-v3/include/c_std/cstdio
-@@ -144,7 +144,7 @@ namespace std
-   using ::vsprintf;
- } // namespace std
- 
--#if _GLIBCXX_USE_C99_STDIO
-+#if _GLIBCXX_USE_C99_STDIO || defined(__UCLIBC__)
- 
- #undef snprintf
- #undef vfscanf
--- 
-2.12.2
-
-- 
1.9.1

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

Re: [OE-core] [PATCH] babeltrace: switch source URI

[Martin Jansa]

Checksums don't need any special treatment with downloadfilename parameter.

On Mon, May 7, 2018 at 5:48 PM, Trevor Woerner  wrote:

> Hi Martin,
>
> On Mon 2018-05-07 @ 05:33:26 PM, Martin Jansa wrote:
> > There is already a fix for this, see:
> > http://lists.openembedded.org/pipermail/openembedded-core/
> 2018-May/150423.html
>
> Oops, I should have checked, sorry!
>
> > Using github archives is even worse as they are regenerated from time to
> > time.
>
> Crazy! But good to know.
>
> > Also when you really want to use v${PV}.tar.gz archive, then
> > use downloadfilename parameter to fetch it with some more meaningful
> > filename and to prevent possible conflicts with other badly named
> tarballs.
>
> Oh, I see, in one's own DL_DIR. So (not that this patch is relevant
> anymore)
> instead of:
>
> -SRC_URI = "http://www.efficios.com/files/babeltrace/babeltrace-${
> PV}.tar.bz2 \
> -"
> +SRC_URI = "https://github.com/efficios/
> babeltrace/archive/v${PV}.tar.gz"
>
> better:
>
> -SRC_URI = "http://www.efficios.com/files/babeltrace/babeltrace-${
> PV}.tar.bz2 \
> -"
> +SRC_URI = "https://github.com/efficios/
> babeltrace/archive/v${PV}.tar.gz;downloadfilename=babeltrace-v${PV}.tar.gz
> "
>
> In this case, would the checksums need a tweak too, or do they know to look
> for the downloadfilename file name?
>
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH 01/12] gstreamer1.0: upgrade 1.12.4 -> 1.14.0

[Khem Raj]

On Mon, May 7, 2018 at 5:40 AM, Carlos Rafael Giani
 wrote:
> True. But it should stay as close to oe-core as possible. I already
> committed updates to meta-gstreamer1.0, so I am not sure what to think of
> this.
>

I would suggest you review the changes and see it does not regress meta-gstremer
and does not cause extra work for you.

>
> On 2018-05-04 12:23, Burton, Ross wrote:
>
> meta-gstreamer ships its own inc files (as it should).
>
> Ross
>
> On 3 May 2018 at 23:49, Khem Raj  wrote:
>>
>>
>> On Thu, May 3, 2018 at 1:18 AM Anuj Mittal  wrote:
>>>
>>> * For changes, please see:
>>> https://gstreamer.freedesktop.org/releases/1.14/
>>> * Merge inc and bb file since we only have one version now.
>>
>>
>> Threre is meta gstreamer can you check if this is not going to affect that
>> layer
>>>
>>>
>>>
>>> Signed-off-by: Anuj Mittal 
>>> ---
>>>  meta/recipes-multimedia/gstreamer/gstreamer1.0_1.12.4.bb   | 14
>>> --
>>>  .../gstreamer/{gstreamer1.0.inc => gstreamer1.0_1.14.0.bb} | 12
>>> +++-
>>>  2 files changed, 11 insertions(+), 15 deletions(-)
>>>  delete mode 100644
>>> meta/recipes-multimedia/gstreamer/gstreamer1.0_1.12.4.bb
>>>  rename meta/recipes-multimedia/gstreamer/{gstreamer1.0.inc =>
>>> gstreamer1.0_1.14.0.bb} (84%)
>>>
>>> diff --git a/meta/recipes-multimedia/gstreamer/gstreamer1.0_1.12.4.bb
>>> b/meta/recipes-multimedia/gstreamer/gstreamer1.0_1.12.4.bb
>>> deleted file mode 100644
>>> index 01b2396513..00
>>> --- a/meta/recipes-multimedia/gstreamer/gstreamer1.0_1.12.4.bb
>>> +++ /dev/null
>>> @@ -1,14 +0,0 @@
>>> -require gstreamer1.0.inc
>>> -
>>> -LIC_FILES_CHKSUM = "file://COPYING;md5=6762ed442b3822387a51c92d928ead0d
>>> \
>>> -
>>> file://gst/gst.h;beginline=1;endline=21;md5=e059138481205ee2c6fc1c079c016d0d"
>>> -
>>> -SRC_URI = " \
>>> -
>>> http://gstreamer.freedesktop.org/src/gstreamer/gstreamer-${PV}.tar.xz \
>>> -"
>>> -SRC_URI[md5sum] = "9d268f2e891cce1ac0832f1cc467d4ea"
>>> -SRC_URI[sha256sum] =
>>> "5a8704aa4c2eeb04da192c4a9942f94f860ac1a585de90d9f914bac26a970674"
>>> -
>>> -S = "${WORKDIR}/gstreamer-${PV}"
>>> -
>>> -CVE_PRODUCT = "gstreamer"
>>> diff --git a/meta/recipes-multimedia/gstreamer/gstreamer1.0.inc
>>> b/meta/recipes-multimedia/gstreamer/gstreamer1.0_1.14.0.bb
>>> similarity index 84%
>>> rename from meta/recipes-multimedia/gstreamer/gstreamer1.0.inc
>>> rename to meta/recipes-multimedia/gstreamer/gstreamer1.0_1.14.0.bb
>>> index c2df1f3258..b4398c8111 100644
>>> --- a/meta/recipes-multimedia/gstreamer/gstreamer1.0.inc
>>> +++ b/meta/recipes-multimedia/gstreamer/gstreamer1.0_1.14.0.bb
>>> @@ -14,11 +14,19 @@ inherit autotools pkgconfig gettext
>>> upstream-version-is-even gobject-introspecti
>>>  # (it has a custom INTROSPECTION_INIT macro, and so must be used instead
>>> of our common introspection.m4 file)
>>>  acpaths = "-I ${S}/common/m4 -I ${S}/m4"
>>>
>>> -SRC_URI_append = " \
>>> +LIC_FILES_CHKSUM = "file://COPYING;md5=6762ed442b3822387a51c92d928ead0d
>>> \
>>> +
>>> file://gst/gst.h;beginline=1;endline=21;md5=e059138481205ee2c6fc1c079c016d0d"
>>> +
>>> +S = "${WORKDIR}/gstreamer-${PV}"
>>> +
>>> +SRC_URI = " \
>>> +
>>> http://gstreamer.freedesktop.org/src/gstreamer/gstreamer-${PV}.tar.xz \
>>>
>>> file://0001-introspection.m4-prefix-pkgconfig-paths-with-PKG_CON.patch \
>>>  file://gtk-doc-tweaks.patch \
>>>
>>> file://0001-gst-gstpluginloader.c-when-env-var-is-set-do-not-fal.patch \
>>>  "
>>> +SRC_URI[md5sum] = "63c7cbfb86aa28c4522e374dcb96"
>>> +SRC_URI[sha256sum] =
>>> "fc361367f0d4b780a868a8833f9f30b9c9f4ac9faea4e6b251db8b4b0398466e"
>>>
>>>  PACKAGECONFIG ??= ""
>>>
>>> @@ -59,3 +67,5 @@ do_configure[prefuncs] += "delete_pkg_m4_file"
>>>  do_compile_prepend() {
>>>  export
>>> GIR_EXTRA_LIBS_PATH="${B}/gst/.libs:${B}/libs/gst/base/.libs"
>>>  }
>>> +
>>> +CVE_PRODUCT = "gstreamer"
>>> --
>>> 2.14.1
>>>
>>> --
>>> ___
>>> Openembedded-core mailing list
>>> Openembedded-core@lists.openembedded.org
>>> http://lists.openembedded.org/mailman/listinfo/openembedded-core
>>
>>
>> --
>> ___
>> Openembedded-core mailing list
>> Openembedded-core@lists.openembedded.org
>> http://lists.openembedded.org/mailman/listinfo/openembedded-core
>>
>
>
>
>
>
> --
> ___
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core
>
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH] babeltrace: switch source URI

[Trevor Woerner]

Hi Martin,

On Mon 2018-05-07 @ 05:33:26 PM, Martin Jansa wrote:
> There is already a fix for this, see:
> http://lists.openembedded.org/pipermail/openembedded-core/2018-May/150423.html

Oops, I should have checked, sorry!

> Using github archives is even worse as they are regenerated from time to
> time.

Crazy! But good to know.

> Also when you really want to use v${PV}.tar.gz archive, then
> use downloadfilename parameter to fetch it with some more meaningful
> filename and to prevent possible conflicts with other badly named tarballs.

Oh, I see, in one's own DL_DIR. So (not that this patch is relevant anymore)
instead of:

-SRC_URI = 
"http://www.efficios.com/files/babeltrace/babeltrace-${PV}.tar.bz2 \
-"
+SRC_URI = 
"https://github.com/efficios/babeltrace/archive/v${PV}.tar.gz;

better:

-SRC_URI = 
"http://www.efficios.com/files/babeltrace/babeltrace-${PV}.tar.bz2 \
-"
+SRC_URI = 
"https://github.com/efficios/babeltrace/archive/v${PV}.tar.gz;downloadfilename=babeltrace-v${PV}.tar.gz;

In this case, would the checksums need a tweak too, or do they know to look
for the downloadfilename file name?
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH] babeltrace: switch source URI

[Martin Jansa]

There is already a fix for this, see:
http://lists.openembedded.org/pipermail/openembedded-core/2018-May/150423.html

Using github archives is even worse as they are regenerated from time to
time. Also when you really want to use v${PV}.tar.gz archive, then
use downloadfilename parameter to fetch it with some more meaningful
filename and to prevent possible conflicts with other badly named tarballs.

On Mon, May 7, 2018 at 5:27 PM, Trevor Woerner  wrote:

> It looks like http://www.efficios.com/files/babeltrace is down, therefore
> switch to https://github.com/efficios/babeltrace/archive.
>
> The md5sum/sha256sum updates are (I'm guessing) a result of switching from
> .tar.bz2 to .tar.gz.
>
> Signed-off-by: Trevor Woerner 
> ---
>  meta/recipes-kernel/lttng/babeltrace_1.5.5.bb | 7 +++
>  1 file changed, 3 insertions(+), 4 deletions(-)
>
> diff --git a/meta/recipes-kernel/lttng/babeltrace_1.5.5.bb
> b/meta/recipes-kernel/lttng/babeltrace_1.5.5.bb
> index 92d86b92e8..2098264c67 100644
> --- a/meta/recipes-kernel/lttng/babeltrace_1.5.5.bb
> +++ b/meta/recipes-kernel/lttng/babeltrace_1.5.5.bb
> @@ -10,10 +10,9 @@ DEPENDS = "glib-2.0 util-linux popt bison-native
> flex-native"
>
>  inherit autotools pkgconfig
>
> -SRC_URI = "http://www.efficios.com/files/babeltrace/babeltrace-${
> PV}.tar.bz2 \
> -"
> +SRC_URI = "https://github.com/efficios/babeltrace/archive/v${PV}.tar.gz;
>
>  EXTRA_OECONF = "--disable-debug-info"
>
> -SRC_URI[md5sum] = "7decafd46093e4e47c14e7307d498986"
> -SRC_URI[sha256sum] = "409146789b4a6b81f6a275fcad932a
> 030743d444f6de5bd4a34aaf17aa72e8ac"
> +SRC_URI[md5sum] = "aa70da8947b2104b976302d8f65ddee5"
> +SRC_URI[sha256sum] = "ce11a5725e7f4838b4a1cc20966eca
> 77bf77a80c43a072062708d7eac7ebf272"
> --
> 2.17.0.rc2.3.gc2a499e6c
>
> --
> ___
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core
>
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH] babeltrace: switch source URI

[Trevor Woerner]

It looks like http://www.efficios.com/files/babeltrace is down, therefore
switch to https://github.com/efficios/babeltrace/archive.

The md5sum/sha256sum updates are (I'm guessing) a result of switching from
.tar.bz2 to .tar.gz.

Signed-off-by: Trevor Woerner 
---
 meta/recipes-kernel/lttng/babeltrace_1.5.5.bb | 7 +++
 1 file changed, 3 insertions(+), 4 deletions(-)

diff --git a/meta/recipes-kernel/lttng/babeltrace_1.5.5.bb 
b/meta/recipes-kernel/lttng/babeltrace_1.5.5.bb
index 92d86b92e8..2098264c67 100644
--- a/meta/recipes-kernel/lttng/babeltrace_1.5.5.bb
+++ b/meta/recipes-kernel/lttng/babeltrace_1.5.5.bb
@@ -10,10 +10,9 @@ DEPENDS = "glib-2.0 util-linux popt bison-native flex-native"
 
 inherit autotools pkgconfig
 
-SRC_URI = "http://www.efficios.com/files/babeltrace/babeltrace-${PV}.tar.bz2 \
-"
+SRC_URI = "https://github.com/efficios/babeltrace/archive/v${PV}.tar.gz;
 
 EXTRA_OECONF = "--disable-debug-info"
 
-SRC_URI[md5sum] = "7decafd46093e4e47c14e7307d498986"
-SRC_URI[sha256sum] = 
"409146789b4a6b81f6a275fcad932a030743d444f6de5bd4a34aaf17aa72e8ac"
+SRC_URI[md5sum] = "aa70da8947b2104b976302d8f65ddee5"
+SRC_URI[sha256sum] = 
"ce11a5725e7f4838b4a1cc20966eca77bf77a80c43a072062708d7eac7ebf272"
-- 
2.17.0.rc2.3.gc2a499e6c

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

[OE-core] Yocto Project Status WW19’18

[Jolley, Stephen K]

Current Dev Position: YP 2.5 is in QA.

Next Deadline: YP 2.5 M4 release is 4/27/18


SWAT Team Rotation:

· SWAT lead is currently: Stephano

· SWAT team rotation: Stephano -> Maxin  on May 11, 2018

· SWAT team rotation: Maxin-> Armin on May 18, 2018

· https://wiki.yoctoproject.org/wiki/Yocto_Build_Failure_Swat_Team


Key Status/Updates:

· 2.5 rc1 should be due from QA early this week. It is 96% complete. 
See: https://wiki.yoctoproject.org/wiki/2.5_QA_Status

· The need for any rc2 is still to be determined when the report is 
complete.

· The technical call on 1st May started discussions on 2.6 planning. 
Some threads were started on the openembedded-architecture mailing list for 
some of the topics which need discussion. The email linked to below details the 
planning process we will be following along with some of the possible ideas for 
2.6: 
http://lists.openembedded.org/pipermail/openembedded-core/2018-April/150040.html

· A further 2.6 planning meeting will be scheduled at the same time as 
the original meeting on 15th May to continue the discussion (8am PST, 4pm GMT).

· We have started merging patches into master again to clear some of 
the backlog, particularly the recipe upgrades. This improved the overall patch 
count in metrics below.


Planned upcoming dot releases:

· YP 2.3.4 (Pyro) will be built after 2.5

· YP 2.2.4 (Morty) will be built after 2.5

· YP 2.4.3 (Rocko) is planned for post YP 2.5


Key YP 2.5 Dates are:

· YP 2.5 M4 release of 4/27/18


Tracking Metrics:

· WDD 2550 (last week 2508) 
(https://wiki.yoctoproject.org/charts/combo.html)

· Patches

oTotal patches found: 1590 (last week 1635)

oPercentage of patches in the Pending State: 47% (last week 46%)


Key Status Links for YP:

https://wiki.yoctoproject.org/wiki/Yocto_Project_v2.5_Status

https://wiki.yoctoproject.org/wiki/Yocto_2.5_Schedule

https://wiki.yoctoproject.org/wiki/Yocto_2.5_Features


The Status reports are now stored on the wiki at: 
https://wiki.yoctoproject.org/wiki/Weekly_Status


[If anyone has suggestions for other information you’d like to see on this 
weekly status update, let us know!]

Thanks,

Stephen K. Jolley
Yocto Project Project Manager
INTEL, MS JF1-255, 2111 N.E. 25th Avenue, Hillsboro, OR 97124
•Cell:(208) 244-4460
• Email: stephen.k.jol...@intel.com

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

Re: [OE-core] cURL recipe: SSL backend

[Mark Hatle]

On 5/7/18 8:16 AM, Viacheslav Salnikov wrote:
> Alright, good point.
> 
> But what if I need to use openssl instead of gnutls on Target? Can it be 
> changed
> without side effects?

This is why the package config settins are present in the curl recipe.  You can
adjust the setting to use whatever TLS engine you want in your distribution or
project configuration.

PACKAGECONFIG_pn-curl = "ipv6 proxy ssl threaded-resolver zlib"

or any other combination of available options..

--Mark

> Regards,
> 
> 2018-05-07 15:59 GMT+03:00 Alexander Kanavin 
>  >:
> 
> On 05/07/2018 03:51 PM, Viacheslav Salnikov wrote:
> 
> cULR is built with GNUTLS for Target but OpenSSL is used for native 
> and SDK.
> 
> So my question is: why GNUTLS is used only for target? Is it necessary
> for some good reason? Documentation for cURL has no explicit answer 
> for
> that.
> 
> Could somebody help me to find the answer?
> 
> 
> I think enabling gnutls on the native side would add a ton of dependencies
> to build, and so openssl (which is more self-contained) is selected there.
> 
> Alex
> 
> 
> 
> 

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

Re: [OE-core] Question about multi rootfs UIDs when using wic

[Ricardo Ribalda Delgado]

Hi Volker

I have tried your patch and does not work for me :(. My configuration
is a little bit more complex, I have two different machines.

The images are generated with:

host-kiosk.wks:

part /boot/bootloader --source qbootimg-efi --ondisk sda --active
--align 1024 --use-uuid --fsoptions defaults,ro
part /export --source rootfs --rootfs-dir=kiosk-image --ondisk sda
--fstype=ext4 --label export --align 1024 --use-uuid --fsoptions
defaults,ro
part / --source rootfs --ondisk sda --fstype=ext4 --label rootfs
--align 1024 --use-uuid --fsoptions defaults,ro

bootloader --ptable gpt --timeout=1 --append="ro rootfstype=ext4
qtec_mem.size=64


MACHINE=qt5022 bitbake host-image ; MACHINE=qt5122 bitbake kiosk-image
wic create host-kiosk -e host-image --rootfs-dir
kiosk-image=/workdir/build/tmp/work/qt5122-poky-linux/kiosk-image/1.0-r0/rootfs/
--rootfs-dir /workdir/build/tmp/work/qt5022-poky-linux/host-image/1.0-r0/rootfs/
-m


In my case this patch does the trick

commit 269334f2400c6ee0c7b4fec7d9bf0f701e50c329 (HEAD -> europa, origin/europa)
Author: Ricardo Ribalda Delgado 
Date:   Mon May 7 13:54:15 2018 +0200

wic: Fix partition files UIDs on multi rootfs images

diff --git a/scripts/lib/wic/partition.py b/scripts/lib/wic/partition.py
index 84fe85d62b..49921e7494 100644
--- a/scripts/lib/wic/partition.py
+++ b/scripts/lib/wic/partition.py
@@ -206,7 +206,7 @@ class Partition():
 """
 p_prefix = os.environ.get("PSEUDO_PREFIX", "%s/usr" % native_sysroot)
 p_localstatedir = os.environ.get("PSEUDO_LOCALSTATEDIR",
- "%s/../pseudo" %
get_bitbake_var("IMAGE_ROOTFS"))
+ "%s/../pseudo" %  rootfs_dir)
 p_passwd = os.environ.get("PSEUDO_PASSWD", rootfs_dir)
 p_nosymlinkexp = os.environ.get("PSEUDO_NOSYMLINKEXP", "1")
 pseudo = "export PSEUDO_PREFIX=%s;" % p_prefix
diff --git a/scripts/lib/wic/plugins/imager/direct.py
b/scripts/lib/wic/plugins/imager/direct.py
index da1c061063..a90a47c926 100644
--- a/scripts/lib/wic/plugins/imager/direct.py
+++ b/scripts/lib/wic/plugins/imager/direct.py
@@ -121,6 +121,10 @@ class DirectPlugin(ImagerPlugin):
 if self._update_fstab(fstab_lines, self.parts):
 # copy rootfs dir to workdir to update fstab
 # as rootfs can be used by other tasks and can't be modified
+new_pseudo = os.path.realpath(os.path.join(self.workdir, "pseudo"))
+from_dir = os.path.join(os.path.join(image_rootfs, ".."), "pseudo")
+from_dir = os.path.realpath(from_dir)
+copyhardlinktree(from_dir, new_pseudo)
 new_rootfs = os.path.realpath(os.path.join(self.workdir,
"rootfs_copy"))
 copyhardlinktree(image_rootfs, new_rootfs)
 fstab_path = os.path.join(new_rootfs, 'etc/fstab')



Can you try it on your setup? If it also works for you I will work on
getting it merged.


Cheers!

On Wed, May 2, 2018 at 8:25 PM, Ricardo Ribalda Delgado
 wrote:
> cc: ed
>
> Is it a very bad idea to revert your patch?
>
> Thanks!
>
> On Wed, May 2, 2018 at 8:17 PM, Ricardo Ribalda Delgado
>  wrote:
>> Hi
>>
>> I do not know how many people is actively using wic. We have started
>> using it from last week, it is hard to replace old scripts that work
>> :)
>>
>> Try sending it as a proper patch, I can help you if you need it.
>>
>> Regards
>>
>> On Wed, May 2, 2018 at 6:31 PM, Volker Vogelhuber
>>  wrote:
>>> Hi,
>>>
>>> I never got any response to my message (until now). So AFAIK I solved the
>>> problem with the following patch:
>>>
>>> diff --git a/scripts/lib/wic/partition.py b/scripts/lib/wic/partition.py
>>> index 84fe85d62b..66ab757aec 100644
>>> --- a/scripts/lib/wic/partition.py
>>> +++ b/scripts/lib/wic/partition.py
>>> @@ -204,15 +204,10 @@ class Partition():
>>>
>>>  Currently handles ext2/3/4, btrfs and vfat.
>>>  """
>>> -p_prefix = os.environ.get("PSEUDO_PREFIX", "%s/usr" %
>>> native_sysroot)
>>> -p_localstatedir = os.environ.get("PSEUDO_LOCALSTATEDIR",
>>> - "%s/../pseudo" %
>>> get_bitbake_var("IMAGE_ROOTFS"))
>>> -p_passwd = os.environ.get("PSEUDO_PASSWD", rootfs_dir)
>>> +pseudo = "export PSEUDO_PREFIX=%s/usr;" % native_sysroot
>>> +pseudo += "export PSEUDO_LOCALSTATEDIR=%s/../pseudo;" %
>>> self.rootfs_dir
>>> +pseudo += "export PSEUDO_PASSWD=%s;" % rootfs_dir
>>>  p_nosymlinkexp = os.environ.get("PSEUDO_NOSYMLINKEXP", "1")
>>> -pseudo = "export PSEUDO_PREFIX=%s;" % p_prefix
>>> -pseudo += "export PSEUDO_LOCALSTATEDIR=%s;" % p_localstatedir
>>> -pseudo += "export PSEUDO_PASSWD=%s;" % p_passwd
>>> -pseudo += "export PSEUDO_NOSYMLINKEXP=%s;" % p_nosymlinkexp
>>>  pseudo += "%s " % get_bitbake_var("FAKEROOTCMD")
>>>
>>> 

Re: [OE-core] cURL recipe: SSL backend

[Viacheslav Salnikov]

Alright, good point.

But what if I need to use openssl instead of gnutls on Target? Can it be
changed without side effects?

Regards,

2018-05-07 15:59 GMT+03:00 Alexander Kanavin <
alexander.kana...@linux.intel.com>:

> On 05/07/2018 03:51 PM, Viacheslav Salnikov wrote:
>
>> cULR is built with GNUTLS for Target but OpenSSL is used for native and
>> SDK.
>>
>> So my question is: why GNUTLS is used only for target? Is it necessary
>> for some good reason? Documentation for cURL has no explicit answer for
>> that.
>>
>> Could somebody help me to find the answer?
>>
>
> I think enabling gnutls on the native side would add a ton of dependencies
> to build, and so openssl (which is more self-contained) is selected there.
>
> Alex
>
>
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] cURL recipe: SSL backend

[Alexander Kanavin]

On 05/07/2018 03:51 PM, Viacheslav Salnikov wrote:
cULR is built with GNUTLS for Target but OpenSSL is used for native and 
SDK.


So my question is: why GNUTLS is used only for target? Is it necessary 
for some good reason? Documentation for cURL has no explicit answer for 
that.


Could somebody help me to find the answer?


I think enabling gnutls on the native side would add a ton of 
dependencies to build, and so openssl (which is more self-contained) is 
selected there.


Alex

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

[OE-core] cURL recipe: SSL backend

[Viacheslav Salnikov]

Hello all,

cULR is built with GNUTLS for Target but OpenSSL is used for native and
SDK.

So my question is: why GNUTLS is used only for target? Is it necessary for
some good reason? Documentation for cURL has no explicit answer for that.

Could somebody help me to find the answer?

Thanks.
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH 01/12] gstreamer1.0: upgrade 1.12.4 -> 1.14.0

[Carlos Rafael Giani]

True. But it should stay as close to oe-core as possible. I already 
committed updates to meta-gstreamer1.0, so I am not sure what to think 
of this.



On 2018-05-04 12:23, Burton, Ross wrote:

meta-gstreamer ships its own inc files (as it should).

Ross

On 3 May 2018 at 23:49, Khem Raj > wrote:



On Thu, May 3, 2018 at 1:18 AM Anuj Mittal > wrote:

* For changes, please see:
https://gstreamer.freedesktop.org/releases/1.14/

* Merge inc and bb file since we only have one version now.


Threre is meta gstreamer can you check if this is not going to
affect that layer



Signed-off-by: Anuj Mittal >
---
 meta/recipes-multimedia/gstreamer/gstreamer1.0_1.12.4.bb
  | 14 --
 .../gstreamer/{gstreamer1.0.inc => gstreamer1.0_1.14.0.bb
} | 12 +++-
 2 files changed, 11 insertions(+), 15 deletions(-)
 delete mode 100644
meta/recipes-multimedia/gstreamer/gstreamer1.0_1.12.4.bb

 rename meta/recipes-multimedia/gstreamer/{gstreamer1.0.inc =>
gstreamer1.0_1.14.0.bb } (84%)

diff --git
a/meta/recipes-multimedia/gstreamer/gstreamer1.0_1.12.4.bb

b/meta/recipes-multimedia/gstreamer/gstreamer1.0_1.12.4.bb

deleted file mode 100644
index 01b2396513..00
--- a/meta/recipes-multimedia/gstreamer/gstreamer1.0_1.12.4.bb

+++ /dev/null
@@ -1,14 +0,0 @@
-require gstreamer1.0.inc
-
-LIC_FILES_CHKSUM =
"file://COPYING;md5=6762ed442b3822387a51c92d928ead0d \
-                   

file://gst/gst.h;beginline=1;endline=21;md5=e059138481205ee2c6fc1c079c016d0d"
-
-SRC_URI = " \
-
http://gstreamer.freedesktop.org/src/gstreamer/gstreamer-${PV}.tar.xz


\
-"
-SRC_URI[md5sum] = "9d268f2e891cce1ac0832f1cc467d4ea"
-SRC_URI[sha256sum] =
"5a8704aa4c2eeb04da192c4a9942f94f860ac1a585de90d9f914bac26a970674"
-
-S = "${WORKDIR}/gstreamer-${PV}"
-
-CVE_PRODUCT = "gstreamer"
diff --git
a/meta/recipes-multimedia/gstreamer/gstreamer1.0.inc
b/meta/recipes-multimedia/gstreamer/gstreamer1.0_1.14.0.bb

similarity index 84%
rename from meta/recipes-multimedia/gstreamer/gstreamer1.0.inc
rename to
meta/recipes-multimedia/gstreamer/gstreamer1.0_1.14.0.bb

index c2df1f3258..b4398c8111 100644
--- a/meta/recipes-multimedia/gstreamer/gstreamer1.0.inc
+++ b/meta/recipes-multimedia/gstreamer/gstreamer1.0_1.14.0.bb

@@ -14,11 +14,19 @@ inherit autotools pkgconfig gettext
upstream-version-is-even gobject-introspecti
 # (it has a custom INTROSPECTION_INIT macro, and so must be
used instead of our common introspection.m4 file)
 acpaths = "-I ${S}/common/m4 -I ${S}/m4"

-SRC_URI_append = " \
+LIC_FILES_CHKSUM =
"file://COPYING;md5=6762ed442b3822387a51c92d928ead0d \
+                   

file://gst/gst.h;beginline=1;endline=21;md5=e059138481205ee2c6fc1c079c016d0d"
+
+S = "${WORKDIR}/gstreamer-${PV}"
+
+SRC_URI = " \
+
http://gstreamer.freedesktop.org/src/gstreamer/gstreamer-${PV}.tar.xz


\
   
 file://0001-introspection.m4-prefix-pkgconfig-paths-with-PKG_CON.patch
\
     file://gtk-doc-tweaks.patch \
   
 file://0001-gst-gstpluginloader.c-when-env-var-is-set-do-not-fal.patch
\
 "
+SRC_URI[md5sum] = "63c7cbfb86aa28c4522e374dcb96"
+SRC_URI[sha256sum] =
"fc361367f0d4b780a868a8833f9f30b9c9f4ac9faea4e6b251db8b4b0398466e"

 PACKAGECONFIG ??= ""

@@ -59,3 +67,5 @@ do_configure[prefuncs] += "delete_pkg_m4_file"
 do_compile_prepend() {
         export
GIR_EXTRA_LIBS_PATH="${B}/gst/.libs:${B}/libs/gst/base/.libs"
 }
+
+CVE_PRODUCT = "gstreamer"
-- 
2.14.1


-- 
___

Openembedded-core mailing list

Re: [OE-core] [PATCH 01/12] gstreamer1.0: upgrade 1.12.4 -> 1.14.0

[Carlos Rafael Giani]

Is this based on my updates in meta-gstreamer1.0 ?

I did not yet have the time to push them to the mailing list, but it 
would be good to try and not have duplicate work.



On 2018-05-03 10:17, Anuj Mittal wrote:

* For changes, please see: https://gstreamer.freedesktop.org/releases/1.14/
* Merge inc and bb file since we only have one version now.

Signed-off-by: Anuj Mittal 
---
  meta/recipes-multimedia/gstreamer/gstreamer1.0_1.12.4.bb   | 14 --
  .../gstreamer/{gstreamer1.0.inc => gstreamer1.0_1.14.0.bb} | 12 +++-
  2 files changed, 11 insertions(+), 15 deletions(-)
  delete mode 100644 meta/recipes-multimedia/gstreamer/gstreamer1.0_1.12.4.bb
  rename meta/recipes-multimedia/gstreamer/{gstreamer1.0.inc => 
gstreamer1.0_1.14.0.bb} (84%)

diff --git a/meta/recipes-multimedia/gstreamer/gstreamer1.0_1.12.4.bb 
b/meta/recipes-multimedia/gstreamer/gstreamer1.0_1.12.4.bb
deleted file mode 100644
index 01b2396513..00
--- a/meta/recipes-multimedia/gstreamer/gstreamer1.0_1.12.4.bb
+++ /dev/null
@@ -1,14 +0,0 @@
-require gstreamer1.0.inc
-
-LIC_FILES_CHKSUM = "file://COPYING;md5=6762ed442b3822387a51c92d928ead0d \
-
file://gst/gst.h;beginline=1;endline=21;md5=e059138481205ee2c6fc1c079c016d0d"
-
-SRC_URI = " \
-http://gstreamer.freedesktop.org/src/gstreamer/gstreamer-${PV}.tar.xz \
-"
-SRC_URI[md5sum] = "9d268f2e891cce1ac0832f1cc467d4ea"
-SRC_URI[sha256sum] = 
"5a8704aa4c2eeb04da192c4a9942f94f860ac1a585de90d9f914bac26a970674"
-
-S = "${WORKDIR}/gstreamer-${PV}"
-
-CVE_PRODUCT = "gstreamer"
diff --git a/meta/recipes-multimedia/gstreamer/gstreamer1.0.inc 
b/meta/recipes-multimedia/gstreamer/gstreamer1.0_1.14.0.bb
similarity index 84%
rename from meta/recipes-multimedia/gstreamer/gstreamer1.0.inc
rename to meta/recipes-multimedia/gstreamer/gstreamer1.0_1.14.0.bb
index c2df1f3258..b4398c8111 100644
--- a/meta/recipes-multimedia/gstreamer/gstreamer1.0.inc
+++ b/meta/recipes-multimedia/gstreamer/gstreamer1.0_1.14.0.bb
@@ -14,11 +14,19 @@ inherit autotools pkgconfig gettext 
upstream-version-is-even gobject-introspecti
  # (it has a custom INTROSPECTION_INIT macro, and so must be used instead of 
our common introspection.m4 file)
  acpaths = "-I ${S}/common/m4 -I ${S}/m4"
  
-SRC_URI_append = " \

+LIC_FILES_CHKSUM = "file://COPYING;md5=6762ed442b3822387a51c92d928ead0d \
+
file://gst/gst.h;beginline=1;endline=21;md5=e059138481205ee2c6fc1c079c016d0d"
+
+S = "${WORKDIR}/gstreamer-${PV}"
+
+SRC_URI = " \
+http://gstreamer.freedesktop.org/src/gstreamer/gstreamer-${PV}.tar.xz \
  file://0001-introspection.m4-prefix-pkgconfig-paths-with-PKG_CON.patch \
  file://gtk-doc-tweaks.patch \
  file://0001-gst-gstpluginloader.c-when-env-var-is-set-do-not-fal.patch \
  "
+SRC_URI[md5sum] = "63c7cbfb86aa28c4522e374dcb96"
+SRC_URI[sha256sum] = 
"fc361367f0d4b780a868a8833f9f30b9c9f4ac9faea4e6b251db8b4b0398466e"
  
  PACKAGECONFIG ??= ""
  
@@ -59,3 +67,5 @@ do_configure[prefuncs] += "delete_pkg_m4_file"

  do_compile_prepend() {
  export GIR_EXTRA_LIBS_PATH="${B}/gst/.libs:${B}/libs/gst/base/.libs"
  }
+
+CVE_PRODUCT = "gstreamer"


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

Re: [OE-core] [PATCH v2] gst-plugins-base: upgrade 1.12.4 -> 1.14.0

[Alexander Kanavin]

On 05/04/2018 04:28 PM, Anuj Mittal wrote:

diff --git 
a/meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-base/0002-Makefile.am-prefix-calls-to-pkg-config-with-PKG_CONF.patch
 
b/meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-base/0002-Makefile.am-prefix-calls-to-pkg-config-with-PKG_CONF.patch
index 6616e2cf0d..dc15d93eb0 100644
--- 
a/meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-base/0002-Makefile.am-prefix-calls-to-pkg-config-with-PKG_CONF.patch
+++ 
b/meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-base/0002-Makefile.am-prefix-calls-to-pkg-config-with-PKG_CONF.patch
@@ -1,16 +1,17 @@
-From 990b653c7b6de1937ec759019982d6c5f15770f7 Mon Sep 17 00:00:00 2001
+From f523721e453febfb3f62f3ba1e9fefb31dcec471 Mon Sep 17 00:00:00 2001
  From: Alexander Kanavin 
-Date: Mon, 26 Oct 2015 16:38:18 +0200
-Subject: [PATCH 2/4] Makefile.am: prefix calls to pkg-config with
+Date: Thu, 5 Apr 2018 10:26:25 +0800
+Subject: [PATCH] Makefile.am: prefix calls to pkg-config with
   PKG_CONFIG_SYSROOT_DIR
  
  Upstream-Status: Pending [review on oe-core maillist]

  Signed-off-by: Alexander Kanavin 
+Signed-off-by: Anuj Mittal 
+
  ---
   gst-libs/gst/allocators/Makefile.am |  4 ++--
   gst-libs/gst/app/Makefile.am|  4 ++--
   gst-libs/gst/audio/Makefile.am  | 12 ++--
- gst-libs/gst/fft/Makefile.am|  4 ++--
   gst-libs/gst/pbutils/Makefile.am| 12 ++--
   gst-libs/gst/riff/Makefile.am   |  8 
   gst-libs/gst/rtp/Makefile.am|  8 
@@ -18,13 +19,13 @@ Signed-off-by: Alexander Kanavin 
   gst-libs/gst/sdp/Makefile.am|  4 ++--
   gst-libs/gst/tag/Makefile.am|  8 
   gst-libs/gst/video/Makefile.am  |  8 


This patch needs to be updated to also include gst-libs/gst/gl and fix 
it in a similar way to other dirs. Can you do that please? This will 
avoid the host contamination issue that you've seen on your machine 
(build succeeding because the host has the needed files).


Alex
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [meta-oe][PATCH v2] package_manager.py: set dnf always debug verbosity

[Alexander Kanavin]

On 05/05/2018 01:05 PM, Paulo Neves wrote:

@@ -892,7 +892,7 @@ class RpmPM(PackageManager):
   "--setopt=logdir=%s" % (self.d.getVar('T'))
  ]
  cmd = [dnf_cmd] + standard_dnf_args + dnf_args
-bb.note('Running %s' % ' '.join(cmd))
+bb.debug(1, 'Running %s' % ' '.join(cmd))


This should stay as bb.note. It only prints the command with arguments 
that is about to be executed.



  try:
  output = 
subprocess.check_output(cmd,stderr=subprocess.STDOUT).decode("utf-8")
  if print_output:



The actual output is logged just after these lines, so tweak it there 
please. Also, this should be a separate patch.


Alex
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH 14/14] babeltrace: switch over to git

[Alexander Kanavin]

On 05/04/2018 10:51 PM, Martin Jansa wrote:
Can you please upload the tarball (I assume you still have it from the 
time you were testing the upgrade to 1.5.5) to:

http://downloads.yoctoproject.org/mirror/sources/babeltrace-1.5.5.tar.bz2
or
http://sources.openembedded.org/babeltrace-1.5.5.tar.bz2
so that it's covered with default mirrors.bbclass as well?


I don't have upload rights to that.

Alex
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH 02/12] gst-plugins-base: upgrade 1.12.4 -> 1.14.0

[Alexander Kanavin]

On 05/04/2018 04:09 PM, Burton, Ross wrote:
Aha great.  I suspect that you have GStreamer headers on your host 
already and it's picking those up?


Seems like there is a host contamination issue here, which should be 
fixed as well.


Alex
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [oe-commits] [openembedded-core] 117/124: libuser: remove

[Robert Yang]

Hi Ross,

The recipe
meta-openembedded/meta-gnome/recipes-support/usermode/usermode_1.111.bb

depends on libuser, so may be we need add libuser to meta-gnome, please ?

// Robert


On 05/04/2018 04:57 PM, g...@git.openembedded.org 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 11ee7989b2f0709119c450819cd66bad70082a93
Author: Ross Burton 
AuthorDate: Fri Apr 27 20:10:24 2018 +0100

 libuser: remove
 
 This isn't used by anything in oe-core (or in common use in general, only one

 package in Debian depends on it), so remove it from oe-core.
 
 Signed-off-by: Ross Burton 

---
  meta/conf/distro/include/maintainers.inc   |  1 -
  .../libuser/libuser/0001-Check-for-issetugid.patch | 62 --
  ...es.c-parse_field-fix-string-formating-in-.patch | 34 
  .../libuser/0002-remove-unused-execinfo.h.patch| 27 --
  meta/recipes-extended/libuser/libuser_0.62.bb  | 35 
  .../packagegroup-core-full-cmdline.bb  |  1 -
  6 files changed, 160 deletions(-)

diff --git a/meta/conf/distro/include/maintainers.inc 
b/meta/conf/distro/include/maintainers.inc
index c2ab132..4fb9fc2 100644
--- a/meta/conf/distro/include/maintainers.inc
+++ b/meta/conf/distro/include/maintainers.inc
@@ -387,7 +387,6 @@ RECIPE_MAINTAINER_pn-liburcu = "Alexander Kanavin 
"
  RECIPE_MAINTAINER_pn-liburi-perl = "Tim Orling 
"
  RECIPE_MAINTAINER_pn-libusb-compat = "Maxin B. John "
  RECIPE_MAINTAINER_pn-libusb1 = "Maxin B. John "
-RECIPE_MAINTAINER_pn-libuser = "Robert Yang "
  RECIPE_MAINTAINER_pn-libva = "Anuj Mittal "
  RECIPE_MAINTAINER_pn-libva-utils = "Anuj Mittal "
  RECIPE_MAINTAINER_pn-libvorbis = "Tanu Kaskinen "
diff --git 
a/meta/recipes-extended/libuser/libuser/0001-Check-for-issetugid.patch 
b/meta/recipes-extended/libuser/libuser/0001-Check-for-issetugid.patch
deleted file mode 100644
index 79756b9..000
--- a/meta/recipes-extended/libuser/libuser/0001-Check-for-issetugid.patch
+++ /dev/null
@@ -1,62 +0,0 @@
-From d0537cb7f2dc5877700ad78dfd191515379d4edc Mon Sep 17 00:00:00 2001
-From: Khem Raj 
-Date: Thu, 7 Jan 2016 02:22:51 +
-Subject: [PATCH 1/2] Check for issetugid()
-
-If secure version of getenv is not there then we can use
-issetugid() as aid to call getenv()
-
-Signed-off-by: Khem Raj 

-Upstream-Status: Pending
-
- configure.ac |  1 +
- lib/config.c | 12 +++-
- 2 files changed, 12 insertions(+), 1 deletion(-)
-
-diff --git a/configure.ac b/configure.ac
-index 1ded1a2..ee19e1f 100644
 a/configure.ac
-+++ b/configure.ac
-@@ -125,6 +125,7 @@ AC_TYPE_OFF_T
- AC_TYPE_SIZE_T
-
- AC_CHECK_FUNCS([__secure_getenv secure_getenv])
-+AC_CHECK_FUNCS([issetugid])
-
- # Modify CFLAGS after all tests are run (some of them could fail because
- # of the -Werror).
-diff --git a/lib/config.c b/lib/config.c
-index 29e7120..30f9daf 100644
 a/lib/config.c
-+++ b/lib/config.c
-@@ -44,8 +44,10 @@
- #  define safe_getenv(string) secure_getenv(string)
- #elif defined(HAVE___SECURE_GETENV)
- #  define safe_getenv(string) __secure_getenv(string)
-+#elif defined(HAVE_ISSETUGID)
-+#  define safe_getenv(string) safe_getenv_issetugid(string)
- #else
--#  error Neither secure_getenv not __secure_getenv are available
-+#  error None of secure_getenv, __secure_getenv, or issetugid is available
- #endif
-
- struct config_config {
-@@ -59,6 +61,14 @@ struct config_key {
-   GList *values;
- };
-
-+static const char*
-+safe_getenv_issetugid(const char* name)
-+{
-+  if (issetugid ())
-+  return 0;
-+  return getenv (name);
-+}
-+
- /* Compare two section names */
- static int
- compare_section_names(gconstpointer a, gconstpointer b)
---
-2.7.0
-
diff --git 
a/meta/recipes-extended/libuser/libuser/0001-modules-files.c-parse_field-fix-string-formating-in-.patch
 
b/meta/recipes-extended/libuser/libuser/0001-modules-files.c-parse_field-fix-string-formating-in-.patch
deleted file mode 100644
index 7c47df2..000
--- 
a/meta/recipes-extended/libuser/libuser/0001-modules-files.c-parse_field-fix-string-formating-in-.patch
+++ /dev/null
@@ -1,34 +0,0 @@
-From a4857911ece5ebfcdef42aee4c070eb216f39597 Mon Sep 17 00:00:00 2001
-From: =?UTF-8?q?An=C3=ADbal=20Lim=C3=B3n?= 
-Date: Fri, 13 May 2016 11:40:13 -0500
-Subject: [PATCH] modules/files.c: parse_field fix string formating in
- g_warnings
-MIME-Version: 1.0
-Content-Type: text/plain; charset=UTF-8
-Content-Transfer-Encoding: 8bit
-
-[YOCTO #9547]
-
-Signed-off-by: Aníbal Limón 
-
-Upstream-Status: Pending

- 

[OE-core] [meta-oe][PATCH] package.bbclass: provide debug sources in externalsrc -dbg packages

[Vignesh Rajendran]

The recipes which are using externalsrc method doesn't contain the
debug sources in their -dbg packages.

Add a handling in copydebugsources function to copy the debugsources for
externalsrc -dbg packages.

Signed-off-by: Vignesh Rajendran 
---
 meta/classes/externalsrc.bbclass |  3 +++
 meta/classes/package.bbclass | 14 +++---
 2 files changed, 14 insertions(+), 3 deletions(-)

diff --git a/meta/classes/externalsrc.bbclass b/meta/classes/externalsrc.bbclass
index c9f5cf7..135670d 100644
--- a/meta/classes/externalsrc.bbclass
+++ b/meta/classes/externalsrc.bbclass
@@ -129,6 +129,9 @@ python () {
 d.setVar('CONFIGURESTAMPFILE', configstamp)
 d.setVar('STAMP', 
'${STAMPS_DIR}/work-shared/${PN}/${EXTENDPE}${PV}-${PR}')
 d.setVar('STAMPCLEAN', '${STAMPS_DIR}/work-shared/${PN}/*-*')
+
+   # set DEBUG_PREFIX_MAP to external source path
+   d.appendVar("DEBUG_PREFIX_MAP", 
"-fdebug-prefix-map=${EXTERNALSRC}=/usr/src/debug/${PN}/${EXTENDPE}${PV}-${PR}")
 }
 
 python externalsrc_configure_prefunc() {
diff --git a/meta/classes/package.bbclass b/meta/classes/package.bbclass
index edeffa9..2c4472d 100644
--- a/meta/classes/package.bbclass
+++ b/meta/classes/package.bbclass
@@ -420,6 +420,7 @@ def copydebugsources(debugsrcdir, d):
 workdir = d.getVar("WORKDIR")
 workparentdir = os.path.dirname(os.path.dirname(workdir))
 workbasedir = os.path.basename(os.path.dirname(workdir)) + "/" + 
os.path.basename(workdir)
+   externalsrc = d.getVar('EXTERNALSRC', True)
 
 # If build path exists in sourcefile, it means toolchain did not use
 # -fdebug-prefix-map to compile
@@ -444,10 +445,17 @@ def copydebugsources(debugsrcdir, d):
 processdebugsrc += "fgrep -zw '%s' | "
 # Remove prefix in the source paths
 processdebugsrc += "sed 's#%s##g' | "
-processdebugsrc += "(cd '%s' ; cpio -pd0mlL --no-preserve-owner '%s%s' 
2>/dev/null)"
+# handle external sources to provide sources in -dbg packages
+if externalsrc:
+localsrc_prefix = "/usr/src/debug/"
+processdebugsrc += "sed 's#%s/##g' | "
+processdebugsrc += "(cd '%s' ; cpio -pd0mlL --no-preserve-owner 
'%s%s/%s' 2>/dev/null)"
+cmd = processdebugsrc % (sourcefile, workbasedir, localsrc_prefix, 
workbasedir, externalsrc, dvar, debugsrcdir, workbasedir)
+else:
+processdebugsrc += "(cd '%s' ; cpio -pd0mlL --no-preserve-owner 
'%s%s' 2>/dev/null)"
+cmd = processdebugsrc % (sourcefile, workbasedir, localsrc_prefix, 
workparentdir, dvar, debugsrcdir)
 
-cmd = processdebugsrc % (sourcefile, workbasedir, localsrc_prefix, 
workparentdir, dvar, debugsrcdir)
-(retval, output) = oe.utils.getstatusoutput(cmd)
+   (retval, output) = oe.utils.getstatusoutput(cmd)
 # Can "fail" if internal headers/transient sources are attempted
 #if retval:
 #bb.fatal("debug source copy failed with exit code %s (cmd was 
%s)" % (retval, cmd))
-- 
2.7.4

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