Date   

Re: [PATCH yocto-autobuilder-helper 2/2] scripts/send-qa-email: fix bug in git push logic for yocto-testresults

Richard Purdie
 

On Wed, 2020-04-22 at 14:43 -1000, Steve Sakoman wrote:
We were mistakenly doing a force push if the branch was in either
BUILD_HISTORY_FORKPUSH or BUILD_HISTORY_DIRECTPUSH.

Now we force push for branches in BUILD_HISTORY_FORKPUSH, regular push
for branches in BUILD_HISTORY_DIRECTPUSH, and no push if the branch is
in neither list.

Signed-off-by: Steve Sakoman <steve@...>
---
scripts/send-qa-email | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/scripts/send-qa-email b/scripts/send-qa-email
index 205f6d1..b4d4cec 100755
--- a/scripts/send-qa-email
+++ b/scripts/send-qa-email
@@ -80,10 +80,10 @@ if 'poky' in repos and os.path.exists(resulttool) and args.results_dir:
extraopts = None

subprocess.check_call([resulttool, "store", args.results_dir, tempdir])
- if basebranch:
+ if comparebranch:
subprocess.check_call(["git", "push", "--all", "--force"], cwd=tempdir)
subprocess.check_call(["git", "push", "--tags", "--force"], cwd=tempdir)
- else:
+ elif basebranch:
subprocess.check_call(["git", "push", "--all"], cwd=tempdir)
subprocess.check_call(["git", "push", "--tags"], cwd=tempdir)
Thanks, well found!

I tweaked the first patch to use comparerepo instead of baserepo. The
confusion came from cut and paste from the buildhistory code.

Cheers,

Richard


Re: inconsistencies with selecting systemd as init manager?

Robert P. J. Day
 

On Thu, 23 Apr 2020, Nicolas Dechesne wrote:



On Thu, Apr 23, 2020 at 1:18 PM Robert P. J. Day <rpjday@...> wrote:

  just noticed that, given that since YP 3.0 one could select systemd
as the init manager via the single variable INIT_MANAGER, which pulled
in init-manager-systemd.inc:

# Use systemd for system initialization
DISTRO_FEATURES_append = " systemd"
DISTRO_FEATURES_BACKFILL_CONSIDERED_append = " sysvinit"
VIRTUAL-RUNTIME_init_manager ??= "systemd"
VIRTUAL-RUNTIME_initscripts ??= "systemd-compat-units"
VIRTUAL-RUNTIME_login_manager ??= "shadow-base"


INIT_MANAGER was added in 3.0, see:
https://git.openembedded.org/openembedded-core/commit/?id=8d0b4704a526a48cd5e67df6
1b613424bbbdccde
i know, that's what i mentioned above.

  this doesn't quite seem to match this snippet from
meta/lib/oeqa/selftest/cases/imagefeatures.py:

# Switch to systemd
DISTRO_FEATURES += "systemd"
VIRTUAL-RUNTIME_init_manager = "systemd"
VIRTUAL-RUNTIME_initscripts = ""
VIRTUAL-RUNTIME_syslog = ""
VIRTUAL-RUNTIME_login_manager = "shadow-base"
DISTRO_FEATURES_BACKFILL_CONSIDERED = "sysvinit"


this is the 'old' (pre 3.0) method, and it can (and should) be
replaced with INIT_MANAGER, i believe.
i suspected as much, i just wanted to point out that those two
snippets are not *exactly* equivalent so someone should make sure that
INIT_MANAGER usage is precisely defined.

rday


Re: inconsistencies with selecting systemd as init manager?

Nicolas Dechesne
 



On Thu, Apr 23, 2020 at 1:18 PM Robert P. J. Day <rpjday@...> wrote:

  just noticed that, given that since YP 3.0 one could select systemd
as the init manager via the single variable INIT_MANAGER, which pulled
in init-manager-systemd.inc:

# Use systemd for system initialization
DISTRO_FEATURES_append = " systemd"
DISTRO_FEATURES_BACKFILL_CONSIDERED_append = " sysvinit"
VIRTUAL-RUNTIME_init_manager ??= "systemd"
VIRTUAL-RUNTIME_initscripts ??= "systemd-compat-units"
VIRTUAL-RUNTIME_login_manager ??= "shadow-base"

INIT_MANAGER was added in 3.0, see:


  this doesn't quite seem to match this snippet from
meta/lib/oeqa/selftest/cases/imagefeatures.py:

# Switch to systemd
DISTRO_FEATURES += "systemd"
VIRTUAL-RUNTIME_init_manager = "systemd"
VIRTUAL-RUNTIME_initscripts = ""
VIRTUAL-RUNTIME_syslog = ""
VIRTUAL-RUNTIME_login_manager = "shadow-base"
DISTRO_FEATURES_BACKFILL_CONSIDERED = "sysvinit"

this is the 'old' (pre 3.0) method, and it can (and should) be replaced with INIT_MANAGER, i believe.


  not sure if that second snippet could be replaced with a simple
assignment to INIT_MANAGER or whether those two snippets are
effectively equivalent ... i'll let someone else make that call.

rday

--

========================================================================
Robert P. J. Day                                 Ottawa, Ontario, CANADA
                         http://crashcourse.ca

Twitter:                                       http://twitter.com/rpjday
LinkedIn:                               http://ca.linkedin.com/in/rpjday
========================================================================


inconsistencies with selecting systemd as init manager?

Robert P. J. Day
 

just noticed that, given that since YP 3.0 one could select systemd
as the init manager via the single variable INIT_MANAGER, which pulled
in init-manager-systemd.inc:

# Use systemd for system initialization
DISTRO_FEATURES_append = " systemd"
DISTRO_FEATURES_BACKFILL_CONSIDERED_append = " sysvinit"
VIRTUAL-RUNTIME_init_manager ??= "systemd"
VIRTUAL-RUNTIME_initscripts ??= "systemd-compat-units"
VIRTUAL-RUNTIME_login_manager ??= "shadow-base"

this doesn't quite seem to match this snippet from
meta/lib/oeqa/selftest/cases/imagefeatures.py:

# Switch to systemd
DISTRO_FEATURES += "systemd"
VIRTUAL-RUNTIME_init_manager = "systemd"
VIRTUAL-RUNTIME_initscripts = ""
VIRTUAL-RUNTIME_syslog = ""
VIRTUAL-RUNTIME_login_manager = "shadow-base"
DISTRO_FEATURES_BACKFILL_CONSIDERED = "sysvinit"

not sure if that second snippet could be replaced with a simple
assignment to INIT_MANAGER or whether those two snippets are
effectively equivalent ... i'll let someone else make that call.

rday

--

========================================================================
Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca

Twitter: http://twitter.com/rpjday
LinkedIn: http://ca.linkedin.com/in/rpjday
========================================================================


Distro testing #yocto

sateesh m
 

Hi Guys,

             I want to test Distro testing in my yocto build image. for that I need setup configurations and how can i check results and where i can get results. can anybody knows please suggest me .


perf-1.0 do complie issue

sateesh m
 

Hi Sir,

           I am trying to build yocto image target qemuriscv64 using core-image-sato. But i am facing issue with this package how can i resolve this issue . can you please suggest me solution.



Thanks & Regards,
Sateesh


Re: meta-javascripts

Per Hallsmark
 

Hi Nicholas,

Thanks, I was thinking as providing it to Yocto but not maintaining it myself. Too much other stuff going on
so it would be a slowly updated layer then.

BR,
Per

On Thu, 23 Apr 2020 at 07:59, Nicholas Krause <xerofoify@...> wrote:


On 4/23/20 1:28 AM, per@... wrote:
Hello fellow Yocto developers,

To be able todo efficient HTML5 programming we of course needs some javascript libraries.
I've not seen Yocto have them packaged so I made up this idea of putting them into their own /usr/lib/js path
with a subdir for each javascript library. It is published here :

https://gitlab.com/saxofon/meta-javascripts

With an example usage here :

https://github.com/Wind-River/device-remote-gui

Would this be something yoctoproject is interested of perhaps?

BR,
Per

Hi,

I'm not a maintainer but you may want to see if you or other  people are able to maintain
then as a open embedded layer as part of the index. Not sure if someone else can
chip in if this is a useful recipe set to add to the open embedded index.

That would ideally be where you would want this to go if this is useful and maintained,

Nick

    


[meta-selinux][PATCH] libselinux-python: Fix one invalid link

Changqing Li
 

From: Changqing Li <changqing.li@...>

when host arch and target arch are different, the extension
suffix of host is different with target one, so there will
be a invalid link. Fix by update the way to create the link.

Signed-off-by: Changqing Li <changqing.li@...>
---
recipes-security/selinux/libselinux-python_3.0.bb | 1 +
...PYCEXT-and-rely-on-the-installed-file-nam.patch | 52 ++++++++++++++++++++++
2 files changed, 53 insertions(+)
create mode 100644 recipes-security/selinux/libselinux/0001-Do-not-use-PYCEXT-and-rely-on-the-installed-file-nam.patch

diff --git a/recipes-security/selinux/libselinux-python_3.0.bb b/recipes-security/selinux/libselinux-python_3.0.bb
index e024a22..2b5438d 100644
--- a/recipes-security/selinux/libselinux-python_3.0.bb
+++ b/recipes-security/selinux/libselinux-python_3.0.bb
@@ -16,5 +16,6 @@ SRC_URI += "\
file://libselinux-define-FD_CLOEXEC-as-necessary.patch \
file://0001-Fix-building-against-musl-and-uClibc-libc-libraries.patch \
file://0001-Makefile-fix-python-modules-install-path-for-multili.patch \
+ file://0001-Do-not-use-PYCEXT-and-rely-on-the-installed-file-nam.patch \
"
S = "${WORKDIR}/libselinux-${PV}"
diff --git a/recipes-security/selinux/libselinux/0001-Do-not-use-PYCEXT-and-rely-on-the-installed-file-nam.patch b/recipes-security/selinux/libselinux/0001-Do-not-use-PYCEXT-and-rely-on-the-installed-file-nam.patch
new file mode 100644
index 0000000..b7cd59d
--- /dev/null
+++ b/recipes-security/selinux/libselinux/0001-Do-not-use-PYCEXT-and-rely-on-the-installed-file-nam.patch
@@ -0,0 +1,52 @@
+From 0d4da8093bc2ef92b7c6f7fd1f4804f6ebc6cb56 Mon Sep 17 00:00:00 2001
+From: Thomas Petazzoni <thomas.petazzoni@...>
+Date: Fri, 25 Oct 2019 13:37:14 +0200
+Subject: [PATCH] Do not use PYCEXT, and rely on the installed file name
+
+PYCEXT is computed by asking the Python intrepreter what is the
+file extension used for native Python modules.
+
+Unfortunately, when cross-compiling, the host Python doesn't give the
+proper result: it gives the result matching the build machine, and not
+the target machine. Due to this, the symlink has an incorrect name,
+and doesn't point to the .so file that was actually built/installed.
+
+To address this and keep things simple, this patch just changes the ln
+invocation to rely on the name of the _selinux*.so Python module that
+was installed.
+
+[Upstream: https://github.com/SELinuxProject/selinux/pull/184]
+Signed-off-by: Thomas Petazzoni <thomas.petazzoni@...>
+
+Upstream-Status: Denied [https://patchwork.kernel.org/patch/11212405/]
+
+[Refreshed for 3.0]
+Signed-off-by: Changqing Li <changqing.li@...>
+---
+ src/Makefile | 3 +--
+ 1 file changed, 1 insertion(+), 2 deletions(-)
+
+diff --git a/src/Makefile b/src/Makefile
+index a384a10..82adf82 100644
+--- a/src/Makefile
++++ b/src/Makefile
+@@ -15,7 +15,6 @@ INCLUDEDIR ?= $(PREFIX)/include
+ PYINC ?= $(shell $(PKG_CONFIG) --cflags $(PYPREFIX))
+ PYLIBS ?= $(shell $(PKG_CONFIG) --libs $(PYPREFIX))
+ PYTHONLIBDIR ?= $(shell $(PYTHON) -c "from distutils.sysconfig import *; print(get_python_lib(plat_specific=1, prefix='$(PREFIX)'))")
+-PYCEXT ?= $(shell $(PYTHON) -c 'import imp;print([s for s,m,t in imp.get_suffixes() if t == imp.C_EXTENSION][0])')
+ RUBYINC ?= $(shell $(RUBY) -e 'puts "-I" + RbConfig::CONFIG["rubyarchhdrdir"] + " -I" + RbConfig::CONFIG["rubyhdrdir"]')
+ RUBYLIBS ?= $(shell $(RUBY) -e 'puts "-L" + RbConfig::CONFIG["libdir"] + " -L" + RbConfig::CONFIG["archlibdir"] + " " + RbConfig::CONFIG["LIBRUBYARG_SHARED"]')
+ RUBYINSTALL ?= $(shell $(RUBY) -e 'puts RbConfig::CONFIG["vendorarchdir"]')
+@@ -175,7 +174,7 @@ install: all
+ install-pywrap: pywrap
+ $(PYTHON) setup.py install --prefix=$(PREFIX) --root=$(DESTDIR) --install-lib=$(PYTHONLIBDIR)
+ install -m 644 $(SWIGPYOUT) $(DESTDIR)$(PYTHONLIBDIR)/selinux/__init__.py
+- ln -sf --relative $(DESTDIR)$(PYTHONLIBDIR)/selinux/_selinux$(PYCEXT) $(DESTDIR)$(PYTHONLIBDIR)/_selinux$(PYCEXT)
++ ln -sf --relative $(DESTDIR)$(PYTHONLIBDIR)/selinux/_selinux*.so $(DESTDIR)$(PYTHONLIBDIR)/
+
+ install-rubywrap: rubywrap
+ test -d $(DESTDIR)$(RUBYINSTALL) || install -m 755 -d $(DESTDIR)$(RUBYINSTALL)
+--
+2.24.1
+
--
2.7.4


Re: meta-javascripts

Nicholas Krause
 



On 4/23/20 1:28 AM, per@... wrote:
Hello fellow Yocto developers,

To be able todo efficient HTML5 programming we of course needs some javascript libraries.
I've not seen Yocto have them packaged so I made up this idea of putting them into their own /usr/lib/js path
with a subdir for each javascript library. It is published here :

https://gitlab.com/saxofon/meta-javascripts

With an example usage here :

https://github.com/Wind-River/device-remote-gui

Would this be something yoctoproject is interested of perhaps?

BR,
Per

Hi,

I'm not a maintainer but you may want to see if you or other  people are able to maintain
then as a open embedded layer as part of the index. Not sure if someone else can
chip in if this is a useful recipe set to add to the open embedded index.

That would ideally be where you would want this to go if this is useful and maintained,

Nick

    


meta-javascripts

Per Hallsmark
 

Hello fellow Yocto developers,

To be able todo efficient HTML5 programming we of course needs some javascript libraries.
I've not seen Yocto have them packaged so I made up this idea of putting them into their own /usr/lib/js path
with a subdir for each javascript library. It is published here :

https://gitlab.com/saxofon/meta-javascripts

With an example usage here :

https://github.com/Wind-River/device-remote-gui

Would this be something yoctoproject is interested of perhaps?

BR,
Per


[PATCH yocto-autobuilder-helper 2/2] scripts/send-qa-email: fix bug in git push logic for yocto-testresults

Steve Sakoman
 

We were mistakenly doing a force push if the branch was in either
BUILD_HISTORY_FORKPUSH or BUILD_HISTORY_DIRECTPUSH.

Now we force push for branches in BUILD_HISTORY_FORKPUSH, regular push
for branches in BUILD_HISTORY_DIRECTPUSH, and no push if the branch is
in neither list.

Signed-off-by: Steve Sakoman <steve@...>
---
scripts/send-qa-email | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/scripts/send-qa-email b/scripts/send-qa-email
index 205f6d1..b4d4cec 100755
--- a/scripts/send-qa-email
+++ b/scripts/send-qa-email
@@ -80,10 +80,10 @@ if 'poky' in repos and os.path.exists(resulttool) and args.results_dir:
extraopts = None

subprocess.check_call([resulttool, "store", args.results_dir, tempdir])
- if basebranch:
+ if comparebranch:
subprocess.check_call(["git", "push", "--all", "--force"], cwd=tempdir)
subprocess.check_call(["git", "push", "--tags", "--force"], cwd=tempdir)
- else:
+ elif basebranch:
subprocess.check_call(["git", "push", "--all"], cwd=tempdir)
subprocess.check_call(["git", "push", "--tags"], cwd=tempdir)

--
2.17.1


[PATCH yocto-autobuilder-helper 1/2] scripts/utils.py: Fix confusing naming of getcomparisonbranch() return value

Steve Sakoman
 

Signed-off-by: Steve Sakoman <steve@...>
---
scripts/utils.py | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/scripts/utils.py b/scripts/utils.py
index 68652d9..25eba31 100644
--- a/scripts/utils.py
+++ b/scripts/utils.py
@@ -358,9 +358,9 @@ def getcomparisonbranch(ourconfig, reponame, branchname):
if (reponame + ":" + branchname) in getconfig("BUILD_HISTORY_FORKPUSH", ourconfig):
base = getconfig("BUILD_HISTORY_FORKPUSH", ourconfig)[reponame + ":" + branchname]
if base:
- baserepo, basebranch = base.split(":")
- print("Comparing to %s\n" % (basebranch))
- return branchname, basebranch
+ baserepo, comparebranch = base.split(":")
+ print("Comparing to %s\n" % (comparebranch))
+ return branchname, comparebranch
if (reponame + ":" + branchname) in getconfig("BUILD_HISTORY_DIRECTPUSH", ourconfig):
return branchname, None
return None, None
--
2.17.1


Re: Adding python3 remotely

Sean McKay
 

Assuming you’re using the default rpm packaging, you can extract the contents of the rpm (from tmp/deploy/rpm/<target>) file to a staging directory using rpm2cpio and piping to cpio (easiest way I know of to extract an rpm) and then scp/rsync/etc the files into the right places.

 

That being said, you’ll now have a “package” that wasn’t installed by the package manager on the system, so it could cause weirdness when you do finally get it up and running. I’d strongly recommend trying to get the packaging to work correctly… is rpm (or whatever packagemanager you’re using) installed on your target? Does it work if you try to copy the whole package on manually and install it with the package manager, rather than going through the whole sources process for updating?

 

-Sean McKay

 

From: yocto@... <yocto@...> On Behalf Of Emily
Sent: Wednesday, April 22, 2020 8:25 AM
To: Yocto List <yocto@...>
Subject: [yocto] Adding python3 remotely

 

Hi all - 

 

I'd like to add python3 to my OS - I can add and build it just fine, but at the moment I can't physically access my board. I've never been able to get the OS to update properly remotely, though I think there should be a way since I'm booting from SD. That aside, can I just copy the built python3 files to the proper places in my OS (/usr/lib, /usr/bin, etc) and have a working python3 on the board? If so, which files do I need? I've been unable to get it to work thus far by just poking around the workdir files. 

 

Thanks,

Emily Smith


Re: HELP NEEDED TO ENABLE CUPS IN YOCTO #cups #yocto #linux

Ross Burton <ross@...>
 

On Wed, 22 Apr 2020 at 16:58, Dan O'Donovan <dan.odonovan@...> wrote:
This meta-printing layer has worked well for me in the past:
https://github.com/rossburton/meta-printing.git
Those recipes exist in other layers, meta-printing is dead so please
don't use it.

Ross


Re: HELP NEEDED TO ENABLE CUPS IN YOCTO #cups #yocto #linux

Dan O'Donovan
 

This meta-printing layer has worked well for me in the past:

I was using the 'morty' branch with a meta-ti BSP, so I can't testify to how well it works with other Yocto versions or BSP layers.

In case it helps, these are the recipes that included in the image:
	cups \
	cups-filters \
	ghostscript \
	qpdf \

 


Re: Building Qt5 toolchain for windows

David Fz <d.fourdrigniez@...>
 

Hello Joshua,

 

Thank you for your reply,

 

Just for information, I put the following parameters in local.conf

 

MACHINE ?= “qemuarm”

 

SDKMACHINE = “i686-mingw32”

 

IMAGE_INSTALL_append = “ gcc g++ binutils libgcc-dev libstdc++ libstdc++-dev libstdc++-staticdev qtbase qtcharts qtconnectivity qtdeclarative qtenginio qtgraphicaleffects qtlocation qtmultimedia qtscript qtsensors qtserialport qtsystems qttools qttranslations qtvirtualkeyboard qtwebsockets qtxmlpatterns openssh-sftp-server gdb gdbserver”

 

And here is the error I get when I run the command: bitbake meta-toolchain-qt5

 

| In file included from /home/david/yocto/poky/build/tmp/work/i686-nativesdk-mingw32-pokysdk-mingw32/nativesdk-qtbase/5.13.2+gitAUTOINC+a7a24784ee-r0/recipe-sysroot/opt/poky/3.0.2/sysroots/i686-pokysdk-mingw32/usr/include/winbase.h:18,

|                  from /home/david/yocto/poky/build/tmp/work/i686-nativesdk-mingw32-pokysdk-mingw32/nativesdk-qtbase/5.13.2+gitAUTOINC+a7a24784ee-r0/recipe-sysroot/opt/poky/3.0.2/sysroots/i686-pokysdk-mingw32/usr/include/windows.h:70,

|                  from /home/david/yocto/poky/build/tmp/work/i686-nativesdk-mingw32-pokysdk-mingw32/nativesdk-qtbase/5.13.2+gitAUTOINC+a7a24784ee-r0/git/qmake/library/ioutils.cpp:35:

| /home/david/yocto/poky/build/tmp/work/i686-nativesdk-mingw32-pokysdk-mingw32/nativesdk-qtbase/5.13.2+gitAUTOINC+a7a24784ee-r0/recipe-sysroot/opt/poky/3.0.2/sysroots/i686-pokysdk-mingw32/usr/include/fileapi.h:53:48: note:   initializing argument 1 of 'void* CreateFileA(LPCSTR, DWORD, DWORD, LPSECURITY_ATTRIBUTES, DWORD, DWORD, HANDLE)'

|    53 |   WINBASEAPI HANDLE WINAPI CreateFileA (LPCSTR lpFileName, DWORD dwDesiredAccess, DWORD dwShareMode, LPSECURITY_ATTRIBUTES lpSecurityAttributes, DWORD dwCreationDisposition, DWORD dwFlagsAndAttributes, HANDLE hTemplateFile);

|       |                                         ~~~~~~~^~~~~~~~~~

| Makefile:212: recipe for target 'ioutils.o' failed

| make: *** [ioutils.o] Error 1

| WARNING: exit code 2 from a shell command.

|

ERROR: Task (/home/david/yocto/poky/meta-qt5/recipes-qt/qt5/nativesdk-qtbase_git.bb:do_configure) failed with exit code '1'

NOTE: Tasks Summary: Attempted 3299 tasks of which 3161 didn't need to be rerun and 1 failed.

 

Summary: 1 task failed:

  /home/david/yocto/poky/meta-qt5/recipes-qt/qt5/nativesdk-qtbase_git.bb:do_configure

Summary: There was 1 ERROR message shown, returning a non-zero exit code.

 

Best regards,

 

David FOURDRIGNIEZ
Mobile +33 6 27 94 03 25

Email d.fourdrigniez@...

 

From: Joshua Watt <jpewhacker@...>
Sent: mardi 21 avril 2020 13:20
To: d.fourdrigniez@...
Cc: Samuli Piippo <samuli.piippo@...>; yocto@...
Subject: Re: [Yocto] Building Qt5 toolchain for windows

 

 

On 4/21/20 1:00 PM, d.fourdrigniez@... wrote:

Hello,

 

I’m working on a project and I need to build a Qt5 toolchain for Windows,

I’m using meta-qt5 and meta-mingw and my build machine is an ubuntu 18.04

However I keep having errors when i execute « bitbake meta-toolchain-qt5 », very much like the one in below forum thread 

https://www.yoctoproject.org/pipermail/yocto/2019-March/044512.html

 

Am I doing something wrong ? Could you help sending me some ideas on how I could accomplish what I want ?

 

I don't actually know a whole lot about cmake/qt5, so I'm not sure what would need to be done (other than what I've already stated in the message above). Samuli Piippo (cc'd) recently did some work to get cmake to build for MinGW, so he might have some insight.

 

Thanks,

 

Best regards,

David Fourdrigniez.


Adding python3 remotely

Emily
 

Hi all - 

I'd like to add python3 to my OS - I can add and build it just fine, but at the moment I can't physically access my board. I've never been able to get the OS to update properly remotely, though I think there should be a way since I'm booting from SD. That aside, can I just copy the built python3 files to the proper places in my OS (/usr/lib, /usr/bin, etc) and have a working python3 on the board? If so, which files do I need? I've been unable to get it to work thus far by just poking around the workdir files. 

Thanks,
Emily Smith


Re: FYI: "which" program is broken by default on centos-8

Armin Kuster
 



On 4/21/20 5:42 PM, Joel A Cohen wrote:
Centos 8 'which' installs an alias by default: alias which='(alias; typeset -f) | /usr/bin/which --tty-only --read-alias --read-functions --show-tilde --show-dot'

This comes from the which rpm, in /etc/profile.d/which.sh

This breaks in OE, I'm guessing because the shell used doesn't support whatever is going on there. You get a mystifying message about unexpected parentheses.

Can you provide some way to reproduce this as Centos8 is one of the OS's used to build on for Dunfell and Master. Maybe we are missing a corner case. Would you mind opening a defect in the Yocto Bugzilla with all the information?
https://bugzilla.yoctoproject.org/

- Armin

To fix for the moment, I just got rid of the alias, but is it worth adding a check or something?

Thanks,
Aaron




    


Issue with mongodb 4.0.6 and openssl 1. 1.1 recipes

amaya jindal
 

Hi All, 

I have yocto Rocko, I need to port mongodb 4.0.6 with openssl 1.1.1 recipe. But there are errors in compilation of mongodb with this version of openssl 1.1.1. Please guide. 

Sent from my Huawei phone


Re: [yocto-announce] [ANNOUNCEMENT] Yocto Project 3.1 LTS (Dunfell 23.0.0) is Released

 

On Tue, 21 Apr 2020 21:15:08 +0000
"Vineela" <vineela.tummalapalli@...> wrote:

Hello,

We are pleased to announce the Yocto Project 3.1 (dunfell-23.0.0) LTS Release and is now available for download.
Congratulations to everyone involved in this release! Despite some resourcing
changes and challenging times in the wider world, Yocto Project is still
moving forward and improving.

- -------------
Dedication
- -------------

This release is dedicated to Scott Rifenbark, technical writer for the Yocto Project from the project's inception in 2010 until his passing in January 2020. Our documentation stands in his memory, and it is fitting that some of his character will always be in those words.
This is very fitting, I know Scott was a friend as well as a colleague to
many involved in the project and he will be missed.

Thanks,

--
Paul Barker
Konsulko Group

8181 - 8200 of 57397