Skip to content
This repository has been archived by the owner on Nov 2, 2021. It is now read-only.

Adapt to Yocto "Thud" 2.6 #79

Merged
merged 15 commits into from Oct 31, 2018
Merged

Adapt to Yocto "Thud" 2.6 #79

merged 15 commits into from Oct 31, 2018

Conversation

sashko
Copy link
Contributor

@sashko sashko commented Aug 26, 2018

Signed-off-by: Oleksandr Kravchuk oleksandr.kravchuk@pelagicore.com

@frznlogic
Copy link
Collaborator

@sashko the build fails because there is no qemu 3.x in our builds. See

https://go.genivi.org/go/tab/build/detail/yocto-baseline-GITHUB-PR-qemuarm64/59/Build/1/init_and_bitbake

@sashko
Copy link
Contributor Author

sashko commented Aug 27, 2018

@frznlogic same story as with #80: since it's master, it must be built against poky master.

@sashko sashko changed the title qemu: rebase to 3.x WIP: adaptation to poky/oe master/thud Aug 30, 2018
@gunnarx
Copy link
Member

gunnarx commented Aug 31, 2018

Build checks:
Looks like two errors (might depend on the order the components get built?)

@gunnarx
Copy link
Member

gunnarx commented Sep 4, 2018 •
edited

One build check seems to have failed on some technicality, so I triggered a rerun. It will again fail on the #81 issue of course, unless something else is noticed instead. But please force-push an update to this to trigger the other build checks that have not run at all yet.

@gunnarx
Copy link
Member

gunnarx commented Sep 6, 2018 •
edited

#81 is now merged so we should rebase this and get a new build check.

Warning @sashko, maintainers (and I) can force-push the source branch of any PR. This is a GitHub feature and it enables us to perform rebases and fixes, and we often do force push the PRs!
Note that since you sent the PR from your master, that would update sashko:master (!)

Let me know if this is OK, or you can yourself rebase on the latest master, and push it again.
(Next time, we just do it without asking ;-)

@sashko
Copy link
Contributor Author

sashko commented Sep 6, 2018

@gunnarx you guys know your project better and I have no objections to you modifying my PRs.

@sashko sashko force-pushed the master branch 2 times, most recently from e3f38af to 431412c Compare September 6, 2018 21:02
@gunnarx
Copy link
Member

gunnarx commented Sep 7, 2018 •
edited

@gunnarx you guys know your project better and I have no objections to you modifying my PRs.

Cool, looks like you did the rebase

@gunnarx
Copy link
Member

gunnarx commented Sep 7, 2018 •
edited

Fails on ecryptfs-utils I looked into it a bit.

Not totally sure why ecryptfs-utils is included in meta-ivi.

  • I don't agree it being in the "P1" packagegroup of the default image. I'm not saying it is unimportant, I just can't find that exact component specified as a mandatory component in the underlying GENIVI compliance specifications.

  • It has been there for a long time, I would say "since the beginning".

  • Since we have received patches to it in the past from Fujitsu, I first assume there's a need and interest, so I was at first less inclined to drop it.

  • But on the other hand there's a seemingly well maintained and more featureful recipe in meta-security so based on that it still seems the right thing to drop the recipe from meta-ivi, in my opinion.

  • The current version of the ecryptfs user space, version 111, seems to be the latest upstream.

  • Upstream status> Looks like the bug that is reported, and some patches created here: https://bugs.launchpad.net/ecryptfs/+bug/1670476.

  • Apparently ecryptfs in combination with openssl 1.1.1 does not work.

  • I didn't see that meta-security has incorporated that fix yet, but since it does not need to be in the meta-ivi base image, it will still be better to drop it and for adopters to switch over the recipe to meta-security layer, and then deal with any issues there.

  • Note that openssl_1.1.1 became the default in poky:df15a4c914, only about a week ago (August 28 2018) so it's likely a very recent problem.

^^ @sashko

@gunnarx
Copy link
Member

gunnarx commented Sep 7, 2018 •
edited

--> If you want, you can add a patch to drop ecryptfs-utils recipe and remove it from the package group. (Make sure the commit clearly advises the reader to add the meta-security layer to find the recipe there.)

@sashko
Copy link
Contributor Author

sashko commented Sep 7, 2018

@gunnarx yeah, my findings were similar: it is simply not adapted to the latest OpenSSL; I'll delete the recipe then, thanks.

@sashko sashko force-pushed the master branch 2 times, most recently from 9ba1da4 to c251bc9 Compare September 8, 2018 10:04
@sashko
Copy link
Contributor Author

sashko commented Sep 10, 2018

@gunnarx I'm getting the following error. Do you know how I could fix it?

ERROR: audiomanagerplugins-7.6-r0 do_configure: Function failed: do_configure (log file is located at /home/oleksandr/projects/genivi/build/tmp/work/i586-poky-linux/audiomanagerplugins/7.6-r0/temp/log.do_configure.51917)
ERROR: Logfile of failure stored in: /home/oleksandr/projects/genivi/build/tmp/work/i586-poky-linux/audiomanagerplugins/7.6-r0/temp/log.do_configure.51917
Log data follows:
| DEBUG: Executing shell function do_configure
| -- The C compiler identification is GNU 8.2.0
| -- The CXX compiler identification is GNU 8.2.0
| -- Check for working C compiler: /home/oleksandr/projects/genivi/build/tmp/work/i586-poky-linux/audiomanagerplugins/7.6-r0/recipe-sysroot-native/usr/bin/i586-poky-linux/i586-poky-linux-gcc
| -- Check for working C compiler: /home/oleksandr/projects/genivi/build/tmp/work/i586-poky-linux/audiomanagerplugins/7.6-r0/recipe-sysroot-native/usr/bin/i586-poky-linux/i586-poky-linux-gcc -- works
| -- Detecting C compiler ABI info
| -- Detecting C compiler ABI info - done
| -- Detecting C compile features
| -- Detecting C compile features - done
| -- Check for working CXX compiler: /home/oleksandr/projects/genivi/build/tmp/work/i586-poky-linux/audiomanagerplugins/7.6-r0/recipe-sysroot-native/usr/bin/i586-poky-linux/i586-poky-linux-g++
| -- Check for working CXX compiler: /home/oleksandr/projects/genivi/build/tmp/work/i586-poky-linux/audiomanagerplugins/7.6-r0/recipe-sysroot-native/usr/bin/i586-poky-linux/i586-poky-linux-g++ -- works
| -- Detecting CXX compiler ABI info
| -- Detecting CXX compiler ABI info - done
| -- Detecting CXX compile features
| -- Detecting CXX compile features - done
| -- Found PkgConfig: /home/oleksandr/projects/genivi/build/tmp/work/i586-poky-linux/audiomanagerplugins/7.6-r0/recipe-sysroot-native/usr/bin/pkg-config (found version "0.29.2")
| -- Checking for module 'libsystemd >= 44'
| --   Found libsystemd , version 239
| -- Checking for module 'dbus-1 >= 1.4'
| --   Found dbus-1 , version 1.12.10
| -- Checking for module 'CommonAPI >= 3.1.5'
| --   Found CommonAPI , version 3.1.12
| -- Checking for module 'automotive-dlt >= 2.2.0'
| --   Found automotive-dlt , version 2.17.0
| -- Found LibXml2: /home/oleksandr/projects/genivi/build/tmp/work/i586-poky-linux/audiomanagerplugins/7.6-r0/recipe-sysroot/usr/lib/libxml2.so (found version "2.9.8")
| -- Audiomanager version: 7.6.4
| -- CommonAPI Version: 3.1.12
| -- Checking for module 'org.genivi.am.commandinterfaceStub'
| --   No package 'org.genivi.am.commandinterfaceStub' found
| -- No fidls for the binding generator. The generation of binding code will be skipped !
| -- Searching for common-api generator executable commonapi-generator-linux-x86_64 ...
| -- Will execute common-api generator at path /home/oleksandr/projects/genivi/build/tmp/work/i586-poky-linux/audiomanagerplugins/7.6-r0/recipe-sysroot/../recipe-sysroot-native/usr/share/capicxx-core-native-3.1.12/commonapi-generator-linux-x86_64 with fidls:
| -- /home/oleksandr/projects/genivi/build/tmp/work/i586-poky-linux/audiomanagerplugins/7.6-r0/git/PluginCommandInterfaceCAPI/fidl/CommandInterface.fidl
| CMake Error at PluginCommandInterfaceCAPI/cmake/CommonAPI.cmake:348 (message):
|   Failed to generate files from FIDL:Commonapi-generator-linux-x86_64:
| 
|   A Java Runtime Environment (JRE) or Java Development Kit (JDK)
| 
|   must be available in order to run Commonapi-generator-linux-x86_64.  No
|   Java virtual machine
| 
|   was found after searching the following locations:
| 
| 
|   /home/oleksandr/projects/genivi/build/tmp/work/i586-poky-linux/audiomanagerplugins/7.6-r0/recipe-sysroot-native/usr/share/capicxx-core-native-3.1.12/jre/bin/java
| 
| 
|   java in your current PATH
| Call Stack (most recent call first):
|   PluginCommandInterfaceCAPI/cmake/CommonAPI.cmake:381 (FIND_AND_EXEC_GENERATOR)
|   PluginCommandInterfaceCAPI/cmake/CommonAPI.cmake:462 (EXECUTE_GENERATOR)
|   PluginCommandInterfaceCAPI/CMakeLists.txt:87 (COMMON_API_GENERATE_SOURCES)
| 
| 
| -- Configuring incomplete, errors occurred!
| See also "/home/oleksandr/projects/genivi/build/tmp/work/i586-poky-linux/audiomanagerplugins/7.6-r0/build/CMakeFiles/CMakeOutput.log".
| WARNING: exit code 1 from a shell command.
| ERROR: Function failed: do_configure (log file is located at /home/oleksandr/projects/genivi/build/tmp/work/i586-poky-linux/audiomanagerplugins/7.6-r0/temp/log.do_configure.51917)
ERROR: Task (/home/oleksandr/projects/genivi/sources/poky/../meta-ivi/meta-ivi/recipes-multimedia/audiomanager/audiomanagerplugins_7.6.bb:do_configure) failed with exit code '1'
NOTE: Tasks Summary: Attempted 3922 tasks of which 2552 didn't need to be rerun and 1 failed.

Summary: 1 task failed:
  /home/oleksandr/projects/genivi/sources/poky/../meta-ivi/meta-ivi/recipes-multimedia/audiomanager/audiomanagerplugins_7.6.bb:do_configure
Summary: There was 1 WARNING message shown.
Summary: There was 1 ERROR message shown, returning a non-zero exit code.

@slawr
Copy link
Member

slawr commented Sep 10, 2018

Warning @sashko, maintainers (and I) can force-push the source branch of any PR. This is a GitHub feature and it enables us to perform rebases and fixes, and we often do force push the PRs!
Note that since you sent the PR from your master, that would update sashko:master (!)

Hmm makes me wonder if we should warn about that in the readme. Suggest that PRs are created on unique branch for example. On one level master is just another branch but I can see how someone might think WTH if they suddenly have changes to their master.

@gunnarx
Copy link
Member

gunnarx commented Sep 12, 2018

Hmm makes me wonder if we should warn about that in the readme. Suggest that PRs are created on unique branch for example. On one level master is just another branch but I can see how someone might think WTH if they suddenly have changes to their master.

Yes sure - feel free if you wish. Actually this should be part of a "contribution guidelines" review, perhaps.

I would add however:

  1. As I wrote above, I normally warn people before force-pushing if I think it is their first pull request sent from master. After that, they know it. In addition, it will be noted in the comment flow if the PR is modified, so that's a second chance to pick up on how/why a rebase happened.
  2. It's a standard Github feature so one could argue why that needs to go into our specific README* Also, to be clear, this is actually something the sender of the PR already has control over - it is just good that this is enabled by default. For completeness I dug up the GitHub documentation on this feature.
  3. *Despite argument 2 - since we make aggressive use of rebasing in GDP we actually placed prominent warning on the GDP Contribution Page which is linked from the contribution section of the GDP README.
    This is meta-ivi, but those are still the contribution guidelines that I recommend most projects to apply.

@gunnarx
Copy link
Member

gunnarx commented Sep 12, 2018 •
edited

@sashko I suppose it is as written, that a Java runtime needs to be installed on the build machine, for the code generators to run. (I think Java is not built as a -native dependency inside Yocto but it must be on the build machine)

@sashko
Copy link
Contributor Author

sashko commented Sep 12, 2018

@gunnarx

$ java --version
openjdk 10.0.2 2018-07-17
OpenJDK Runtime Environment (build 10.0.2+13-Ubuntu-1ubuntu0.18.04.1)
OpenJDK 64-Bit Server VM (build 10.0.2+13-Ubuntu-1ubuntu0.18.04.1, mixed mode)

or does it want Oracle JDK?

@gunnarx
Copy link
Member

gunnarx commented Sep 12, 2018 •
edited

OpenJDK should be fine. Possibly it's a version issue since version 10 is very new.

But the error actually states that it is looking in the sysroot-native area:

| /home/oleksandr/projects/genivi/build/tmp/work/i586-poky-linux/audiomanagerplugins/7.6-r0/recipe-sysroot-native/usr/share/capicxx-core-native-3.1.12/jre/bin/java

I'm not sure what the issue is - might be best to ask audiomanager or capicxx-core project for this...

EDIT: For what it's worth, our build agents have a native installation (i.e. /usr/bin/java) of Java 8:

openjdk version "1.8.0_171"
OpenJDK Runtime Environment (build 1.8.0_171-8u171-b11-0ubuntu0.16.04.1-b11)
OpenJDK 64-Bit Server VM (build 25.171-b11, mixed mode)

Again I don't know if that's the one that is used.

@slawr
Copy link
Member

slawr commented Sep 12, 2018 •
edited

Yes sure - feel free if you wish. Actually this should be part of a "contribution guidelines" review, perhaps.

Yes I think that would be a good idea. I was just thinking somewhat aloud and its a small point that certainly could wait to a wider review.

@gunnarx
Copy link
Member

gunnarx commented Sep 12, 2018 •
edited

Hmm, some small conflict because of the most recent merges I made...
I just tried the GitHub built-in "conflict resolution" editor which created some weird commit. Well if it looks OK I guess we keep it :-)

Ugh, rebase conflict now. Let me fix and redo this.

@gunnarx
Copy link
Member

gunnarx commented Sep 12, 2018

OK I nuked the ugly merge commit that GitHub created and rebased on latest master again instead. So you're all up to date on top of origin/master. As noted earlier in the thread, be aware that sashko/master is now rewritten (compared to your local copy master branch)

@slawr
Copy link
Member

slawr commented Sep 12, 2018

But the error actually states that it is looking in the sysroot-native area:

| /home/oleksandr/projects/genivi/build/tmp/work/i586-poky-linux/audiomanagerplugins/7.6-r0/recipe-sysroot-native/usr/share/capicxx-core-native-3.1.12/jre/bin/java

I was wondering if it was further changes to the per recipe sysroot introduced in YP 2.3, but unfortunately the upgrade guide for YP 2.6 in the reference manual is not published yet. If not then we would expect it to be failing before 2.6/Thud.

There is no explicit host runtime build dep in the AM Plugin recipe in meta-ivi for that I could see. Maybe the capicxx deps are supposed to cover it. I note that the recipe is doing some java path work in a do_configure_prepend().

@gunnarx
Copy link
Member

gunnarx commented Sep 18, 2018

@sashko I think you forgot to remove ecryptfs-utils also from the packagegroup file in bbe08ac, hence the build failure. Will you update with a fix or shall I?

@sashko
Copy link
Contributor Author

sashko commented Sep 18, 2018 •
edited

@gunnarx it wouldn't be enough to make it build: there're few more issues with other GENIVI packages; I have made few pull request with fixes; it would be more helpful if you've made them reviewed instead. Thanks.

@gunnarx
Copy link
Member

gunnarx commented Sep 18, 2018

@sashko If you let me know what other PRs you mean then I'll try to get contact with the maintainers if they are not reviewing. I saw the DLT proposal and will follow up on that, but I guess that's at the moment not holding up meta-ivi, thanks to the patch you added above. I see nothing more open on meta-ivi except the text-file change?

As for it not being enough, we still have to deal with each issue, one at a time until it works...
(That's also why I offered to do it)

@sashko
Copy link
Contributor Author

sashko commented Oct 30, 2018

I sent them a fix: http://lists.openembedded.org/pipermail/openembedded-core/2018-October/157163.html

@sashko sashko changed the title Adapt to to Yocto "Thud" 2.6 Adapt to Yocto "Thud" 2.6 Oct 30, 2018
@sashko sashko force-pushed the master branch 3 times, most recently from e67dac2 to 5f5add3 Compare October 30, 2018 23:20
@gunnarx
Copy link
Member

gunnarx commented Oct 31, 2018 •
edited

weston build failure that popped up now:

file /etc/xdg/weston/weston.ini conflicts between attempted installs of weston-5.0.0-r3.core2_64 and weston-conf-1.0-r0.qemux86_64

So as far as I can tell the tip of poky (oe-core) is failing for qemux86* targets (unless there's some conf setting that we're supposed to have but have missed?)

To avoid it I think it might work to roll back poky to before
this commit until it is sorted upstream. What do you think @sashko? I'm eager to get this PR merged in some working fashion. Then later pull requests can suggest more updates.

EDIT: Just testing it now on a temporary PR

sashko and others added 15 commits October 31, 2018 14:42
@sashko
README.md: bump dependencies for thud
61e4e29 
Build layer against Yocto "Thud" 2.6.

Signed-off-by: Oleksandr Kravchuk <oleksandr.kravchuk@pelagicore.com>
@sashko
qemu: rebase to 3.x
6cb1d6a 
Signed-off-by: Oleksandr Kravchuk <oleksandr.kravchuk@pelagicore.com>
@sashko
bluez5: rebase patches for 5.50
a2f3363 
Signed-off-by: Oleksandr Kravchuk <oleksandr.kravchuk@pelagicore.com>
@sashko
poky-ivi-systemd: remove duplicate inclusion
ed22556 
security_flags.inc is already included in poky.conf.

Signed-off-by: Oleksandr Kravchuk <oleksandr.kravchuk@pelagicore.com>
@sashko
dlt-daemon: fix compilation with GLIBC 2.28
5635a2e 
Signed-off-by: Oleksandr Kravchuk <oleksandr.kravchuk@pelagicore.com>
@sashko
dbus: rebase patch for 1.12.10
c15075e 
Signed-off-by: Oleksandr Kravchuk <oleksandr.kravchuk@pelagicore.com>
@sashko
ecryptfs-utils: remove recipe and drop the package
82da702 
Removed recipe from the layer as it is already maintained by the
meta-security.

Signed-off-by: Oleksandr Kravchuk <oleksandr.kravchuk@pelagicore.com>
@sashko
poky-ivi-systemd: adjust hardening flags for dbus
d85c9a1 
Signed-off-by: Oleksandr Kravchuk <oleksandr.kravchuk@pelagicore.com>
@sashko
wayland-ivi-extension: bump to latest git revision
668b62f 
Signed-off-by: Oleksandr Kravchuk <oleksandr.kravchuk@pelagicore.com>
@sashko
meta-ivi: set LAYERSERIES_COMPAT to thud
d4182b9 
Signed-off-by: Oleksandr Kravchuk <oleksandr.kravchuk@pelagicore.com>
@sashko
ci-build: remove ftp from PREMIRROR
6cbf42f 
FTP mirrors are not supported by Yocto anymore.

Signed-off-by: Oleksandr Kravchuk <oleksandr.kravchuk@pelagicore.com>
@sashko
persistence_client_library: version 1.2.0
bc5abc1 
Comparing persistence_client_library tag 1.1.0 to this one (1.2.0),
there have been *lots* of changes introduced.  The recipe has however
updated its SRCREV to track master during this time, so the shortlog of
the PCL changes corresponding to the SRCREV change *in this commit* is
only:

797e314 Merge pull request GENIVI#15 from sashko/master
bc4b12f20 Fix compilation with GCC 8

In any case the component has a new tag, and the recipe name therefore
now also changed to PV=1.2.0

Signed-off-by: Gunnar Andersson <gandersson@genivi.org>
@sashko
persistence_common_object: version 1.1.0
cb6b9a3 
Comparing persistence_common_object tag 1.0.3 to this one (1.1.0), there
have been a few more changes introduced. The recipe has however updated
its SRCREV to track master during this time, so the shortlog of the PCO
changes corresponding to the SRCREV change *in this commit* is:

6e827a9 Fix gdbus-codegen invocation
2ee245d Merge pull request GENIVI#5 from mdanilov/master
4b6b1ce Reverted: added dbus config file (there was commit to remove it due to conflict with pcl repo)
857df7a Change README to symlink
f5b3b67 Fixed build, added missed dbus config file
29ec697 Merge pull request GENIVI#2 from GordanM/topic/deprecated
d9235fa Merge pull request GENIVI#1 from GordanM/topic/fix-README
98a32c6 README.md: Update README
daa21fe Merge pull request GENIVI#3 from GordanM/topic/remove-dbus-conf
103be9f dbus_config: Remove dbus configuration file
fe82962 pers_ipc_dbus: remove deprecated glib init
eeac12c Added sqlite backend; use --with-database=sqlite in configure step

In any case the component has a new tag, and the recipe name therefore
now also changed to PV=1.1.0

Signed-off-by: Gunnar Andersson <gandersson@genivi.org>
@sashko
persistence-administrator: version 1.0.10
cda1e46 
(A.k.a. Persistence Administration Service (PAS), but the bb component
 name is persistence-administrator for some historical reason)

It was updated from version 1.0.9, but for some reason the repository is
not tagged with that version, although the commmit message itself
specifies the version.  There is now a tag created for 1.0.10

Short log of changes - the gdbus-codegen update is the important one

ebfb5dd README: fix headline and minor cleanups
49b7936 Makefile: fix gdbus-codegen invocation

Signed-off-by: Gunnar Andersson <gandersson@genivi.org>
@sashko
node-health-monitor: version 1.3.7
aa65df4 
Specifically this includes:

5adefcdd fix gdbus-codegen invocation

Note that 1.3.6 was skipped due to a bug

Signed-off-by: Gunnar Andersson <gandersson@genivi.org>
@sashko
Copy link
Contributor Author

sashko commented Oct 31, 2018

To avoid it I think it might work to roll back poky to before
this commit until it is sorted upstream. What do you think @sashko? I'm eager to get this PR merged in some working fashion. Then later pull requests can suggest more updates.

Yes, let's do it.

@gunnarx gunnarx mentioned this pull request Oct 31, 2018
Closed
@gunnarx
Copy link
Member

gunnarx commented Oct 31, 2018

Woot! It's finally mergable :)

@gunnarx
Copy link
Member

gunnarx commented Oct 31, 2018

I pushed a 1.0.10 tag for persistence-administrator, so recipe is now also correctly named.

@gunnarx gunnarx merged commit ba83418 into GENIVI:master Oct 31, 2018
@gunnarx
Copy link
Member

gunnarx commented Oct 31, 2018

A total of 48 comments preparing this PR :-) Thanks for your work Oleksandr!

This was referenced Nov 16, 2018
Merged
Merged
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Reviewers

@gunnarx gunnarx gunnarx left review comments

Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
4 participants
@sashko @frznlogic @gunnarx @slawr