Date   

Re: [meta-rockchip] The various rockchip layers

Khem Raj
 

On Sat, Oct 7, 2017 at 4:03 PM, Mirza Krak <mirza.krak@gmail.com> wrote:
Hi all.

I recently started working with Rockchip SoC`s and I currently have a
Tinkerboard and a FireFly-RK3288 board. And as I recently enter the
Yocto Rockchip world I have some comments and questions on the current
setup/workflow which I found a bit confusing when starting out.

As I started digging to check the current state of the different
layers it was quite clear to me that there where two different sets.
One is maintained by Rockchip [1] and the other one by the community
[2].

And it made sense to me initially. I do not know the full background
story with the Rockchip layers (would be nice if someone could tell it
:)) on what the intent was with "community" Rockchip layers.

But as I looked in to it further it was quite clear to me that the
Rockchip maintained layers are more "up to date" then the community
ones. And then I started thinking on why are not these merged and we
could focus effort on maintaining one layer.

There are a couple things that are interesting:

- The Rockchip maintained layers state that they do accept
contributions trough pull-requests on github. So nothing stopping us
there?

- The Rockchip maintained layers supports more "community" boards then
the community layers does. Bit odd? :)

- The community layers are a bit outdated on older Yocto branches,
master branch seems active though.

- Trevor and Romain (maintainers of the community layers) are listed
as maintainers of the Rockchip layers? [4]
Its not a good situation, While it is good that both layers are maintained, it
should be clear in its purpose. It could be that github layer supports products
and might have binary stuff and may not work with latest upstreams and the
community layer while supporting lesser number of boards is kept uptodate
with respective upstreams. Ideally, it would be good if both layers were
in sync.


What I am really after is better understanding the workflow working
with Rockchip SOC`s and Yocto and that is why I am raising questions
to do so :).

My plan was getting involved in one of the Rockchip layers as I have
some improvements and I have some ideas for further improvements. And
the goal with this email was to figure out where.

[1]. https://github.com/rockchip-linux
[2]. http://git.yoctoproject.org/cgit/cgit.cgi/meta-rockchip/
[3]. http://freescale.github.io/doc/release-notes/2.2/#the-differences-between-project-name-and-freescale-release-name
[4]. https://github.com/rockchip-linux/meta-rockchip/blob/master/README#L65-L66
--
Best Regards
Mirza
--
_______________________________________________
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto


[meta-security][PATCH 2/2] README: update with basic info

Armin Kuster
 

needed to pass yocto-check-layer

Signed-off-by: Armin Kuster <akuster808@gmail.com>
---
meta-tpm/README | 4 ++++
1 file changed, 4 insertions(+)

diff --git a/meta-tpm/README b/meta-tpm/README
index e69de29..bbc70bb 100644
--- a/meta-tpm/README
+++ b/meta-tpm/README
@@ -0,0 +1,4 @@
+meta-tpm layer
+==============
+
+This layer contains base TPM recipes.
--
2.7.4


[meta-security][PATCH 1/2] swtpm: fix cuse depends

Armin Kuster
 

if cuse is enabled, depend on fuse which is in meta-filesystems
throw error is layer is missing.

Signed-off-by: Armin Kuster <akuster808@gmail.com>
---
meta-tpm/recipes-tpm/swtpm/swtpm_1.0.bb | 10 ++++++++--
1 file changed, 8 insertions(+), 2 deletions(-)

diff --git a/meta-tpm/recipes-tpm/swtpm/swtpm_1.0.bb b/meta-tpm/recipes-tpm/swtpm/swtpm_1.0.bb
index 14f668b..952de1a 100644
--- a/meta-tpm/recipes-tpm/swtpm/swtpm_1.0.bb
+++ b/meta-tpm/recipes-tpm/swtpm/swtpm_1.0.bb
@@ -3,7 +3,7 @@ LICENSE = "BSD-3-Clause"
LIC_FILES_CHKSUM = "file://LICENSE;md5=fe8092c832b71ef20dfe4c6d3decb3a8"
SECTION = "apps"

-DEPENDS = "libtasn1 fuse expect socat glib-2.0 libtpm libtpm-native"
+DEPENDS = "libtasn1 expect socat glib-2.0 libtpm libtpm-native"

# configure checks for the tools already during compilation and
# then swtpm_setup needs them at runtime
@@ -32,7 +32,7 @@ PACKAGECONFIG += "${@bb.utils.contains('DISTRO_FEATURES', 'selinux', 'selinux',
PACKAGECONFIG[openssl] = "--with-openssl, --without-openssl, openssl"
PACKAGECONFIG[gnutls] = "--with-gnutls, --without-gnutls, gnutls"
PACKAGECONFIG[selinux] = "--with-selinux, --without-selinux, libselinux"
-PACKAGECONFIG[cuse] = "--with-cuse, --without-cuse"
+PACKAGECONFIG[cuse] = "--with-cuse, --without-cuse, fuse"

EXTRA_OECONF += "--with-tss-user=${TSS_USER} --with-tss-group=${TSS_GROUP}"

@@ -55,3 +55,9 @@ USERADD_PARAM_${PN} = "--system -g ${TSS_GROUP} --home-dir \
RDEPENDS_${PN} = "libtpm expect socat bash"

BBCLASSEXTEND = "native nativesdk"
+
+python() {
+ if 'cuse' in d.getVar('PACKAGECONFIG') and \
+ 'filesystems-layer' not in d.getVar('BBFILE_COLLECTIONS').split():
+ raise bb.parse.SkipRecipe('Cuse enabled which requires meta-filesystems to be present.')
+}
--
2.7.4


[meta-rockchip] The various rockchip layers

Mirza Krak <mirza.krak@...>
 

Hi all.

I recently started working with Rockchip SoC`s and I currently have a
Tinkerboard and a FireFly-RK3288 board. And as I recently enter the
Yocto Rockchip world I have some comments and questions on the current
setup/workflow which I found a bit confusing when starting out.

As I started digging to check the current state of the different
layers it was quite clear to me that there where two different sets.
One is maintained by Rockchip [1] and the other one by the community
[2].

And it made sense to me initially. I do not know the full background
story with the Rockchip layers (would be nice if someone could tell it
:)) on what the intent was with "community" Rockchip layers.

But as I looked in to it further it was quite clear to me that the
Rockchip maintained layers are more "up to date" then the community
ones. And then I started thinking on why are not these merged and we
could focus effort on maintaining one layer.

There are a couple things that are interesting:

- The Rockchip maintained layers state that they do accept
contributions trough pull-requests on github. So nothing stopping us
there?

- The Rockchip maintained layers supports more "community" boards then
the community layers does. Bit odd? :)

- The community layers are a bit outdated on older Yocto branches,
master branch seems active though.

- Trevor and Romain (maintainers of the community layers) are listed
as maintainers of the Rockchip layers? [4]

What I am really after is better understanding the workflow working
with Rockchip SOC`s and Yocto and that is why I am raising questions
to do so :).

My plan was getting involved in one of the Rockchip layers as I have
some improvements and I have some ideas for further improvements. And
the goal with this email was to figure out where.

[1]. https://github.com/rockchip-linux
[2]. http://git.yoctoproject.org/cgit/cgit.cgi/meta-rockchip/
[3]. http://freescale.github.io/doc/release-notes/2.2/#the-differences-between-project-name-and-freescale-release-name
[4]. https://github.com/rockchip-linux/meta-rockchip/blob/master/README#L65-L66
--
Best Regards
Mirza


Re: [meta-raspberry-pi] needing newer or patched version of g++

Khem Raj
 

On Sat, Oct 7, 2017 at 9:38 AM, Bill Jenkins <bill@korgrd.com> wrote:

On Sep 15, 2017, at 8:02 AM, Bill Jenkins <bill@korgrd.com> wrote:


On Sep 15, 2017, at 7:43 AM, Khem Raj <raj.khem@gmail.com> wrote:

On Fri, Sep 15, 2017 at 7:35 AM, Bill Jenkins <bill@korgrd.com> wrote:

On Sep 15, 2017, at 6:54 AM, Khem Raj <raj.khem@gmail.com> wrote:

On Thu, Sep 14, 2017 at 10:14 PM, Bill Jenkins <bill@korgrd.com> wrote:
After creating an SDK for a 32-bit Raspberry Pi3 target, I ran into the following compiler error when
compiling an application using the SDK:

internal compiler error: Max. number of generated reload insns per insn is achieved (90)

It turns out that a patch was submitted for g++ early last year for the above problem,
We need to backport the patch to 6.3.0 and regenerate SDK. If you can
point to patch that will be helpful.
Thanks Khem, here's a link to the commit:

https://github.com/gcc-mirror/gcc/commit/4fe01ba94e99e792ebe9da2ccb3b071aa1bac388#diff-af18d9175d034b2b3726f1ddc05fae55
OK and which release are you on ?
I've been building in the pyro branch. DISTRO_VERSION reports 2.3.2.
I hadn't heard any news on this. Is there any more information required?
Will it be possible to backport that patch to gcc 6.3.0?
Posted now here
https://patchwork.openembedded.org/patch/144754/


Re: [meta-raspberry-pi] needing newer or patched version of g++

Bill J
 

On Sep 15, 2017, at 8:02 AM, Bill Jenkins <bill@korgrd.com> wrote:


On Sep 15, 2017, at 7:43 AM, Khem Raj <raj.khem@gmail.com> wrote:

On Fri, Sep 15, 2017 at 7:35 AM, Bill Jenkins <bill@korgrd.com> wrote:

On Sep 15, 2017, at 6:54 AM, Khem Raj <raj.khem@gmail.com> wrote:

On Thu, Sep 14, 2017 at 10:14 PM, Bill Jenkins <bill@korgrd.com> wrote:
After creating an SDK for a 32-bit Raspberry Pi3 target, I ran into the following compiler error when
compiling an application using the SDK:

internal compiler error: Max. number of generated reload insns per insn is achieved (90)

It turns out that a patch was submitted for g++ early last year for the above problem,
We need to backport the patch to 6.3.0 and regenerate SDK. If you can
point to patch that will be helpful.
Thanks Khem, here's a link to the commit:

https://github.com/gcc-mirror/gcc/commit/4fe01ba94e99e792ebe9da2ccb3b071aa1bac388#diff-af18d9175d034b2b3726f1ddc05fae55
OK and which release are you on ?
I've been building in the pyro branch. DISTRO_VERSION reports 2.3.2.
I hadn't heard any news on this. Is there any more information required?
Will it be possible to backport that patch to gcc 6.3.0?

Cheers,
Bill



but apparently that
patch is not in the 6.3.0 version within the SDK. When I try to specify a newer version,
(by using PREFERRED_VERSION_gcc-cross-${TARGET_ARCH}) bitbake reports that only 5.4.0 or 6.3.0
are available. Any suggestions on how to resolve this? (i.e. is there some way to use a newer g++ or to
apply the patch?)

Thanks,
Bill
--
_______________________________________________
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto


Missing /etc/resolv.conf

Paul D. DeRocco
 

(Yocto Pyro, using systemd configured with resolved, networkd, timedated,
timesyncd)

/etc/resolv.conf is supposed to be symlinked to
/run/systemd/resolve/resolv.conf, which gets updated with the DNS address
received from DHCP, but it's not. Looking through systemd_232.bb, I see
that do_install() uses sed to edit /usr/lib/tmpfiles.d/etc.conf to set up
this link. When I run the system, I see that etc.conf does indeed have
this edited line, but there is no /etc/resolv.conf.
systemd-tmpfiles-setup.service runs successfully. Isn't that what's
supposed to execute all the junk in /usr/lib/tmpfiles.d? All the
abovementioned servers are running.

Am I missing something?

--

Ciao, Paul D. DeRocco
Paul mailto:pderocco@ix.netcom.com


FW: QA cycle report for 2.4 RC1

libertad
 

Hello All,

Enjoy viewing the full Report for 2.4 RC1:  https://wiki.yoctoproject.org/wiki/WW40_-_2017-10-06_-_Full_Test_Cycle_2.4_RC1

 

======= Summary ========

 

The QA cycle for release 2.4 RC1 is complete.  There are 18 new bugs from which 5 are high priority and are targeted to be fixed in 2.4 M4.  Four of the High Priority bugs (12143[1], 12144[2], 12145[3], 12146[4]) are ptest related and one (12194[5]) is Toaster related.  An additional medium+ priority (12131[6]  Kernel traceback when reboot beaglebone) is targeted to be fixed by 2.4 M4. As an extra note on this report QA wants to highlight that, there are a total of 46 Bugs targeted to be fixed in 2.4 M4 (link [20]).

 

ptest

Results show that python and e2fsprogs are not executing, hence bugs 12143[1] and 12146[4], respectively, were opened and given a high priority.

Bash (bug 12145[3]) had a decrement in the pass rate of  1.27% and  busybox (bug 12144[2]) had a decrement in the pass rate of 0.19%. Although they are high priority, QA sees that the decrement is not very significant, hence this bugs can be lowered in priority.

 

Eclipse

Some good news: testing for Eclipse-Oxygen was  added for the first time to the QA test cycle.

 

Posix

2.4 RC1 Posix results are very similar to last QA cycle 2.4 M3 rc1. They only show that Edgerouter had one more failure if compared with the previous run.

 

                  Failures               2.4 RC1           2.4 M3 RC1

                  Generic86-64           46                      46

                  Beaglebone              45                      45

                  Edgerouter               47                      46

                  Mpc8315e-rdb         45                      45

 

For more details visit:  https://wiki.yoctoproject.org/wiki/Posix_result and https://wiki.yoctoproject.org/wiki/POSIX-results

 

LTP

2.4 RC1 LTP results show that, for Genericx86-64 and Beaglebone, the failures incremented by 1 test. On Edgerouter we have an increment of 2 failures if compared with QA cycle 2.4 M3 rc1.

 

                                                     2.4 RC1               |        2.4 M3 RC1

                                                Total  |  Failures      |      Total   |  Failures

               Genericx86-64         1391 |   27              |      1391   |     26

               Beaglebone              1353 |   18              |      1353   |     17

               Edgerouter               1353 |   34              |      1353   |     32

               Mpc8315e-rdb        1353  |   31              |      1353   |     31

 

For more details: https://wiki.yoctoproject.org/wiki/LTP_result

 

 

Performance

 

In general, the measurements were on the same levels showed up on 2.4_M3. The only noticeable variation was on “rootfs” that is showing an increase of 5% on Ubuntu and 7% on Fedora, although this does not represent an important regression.

 

Ubuntu                 Test       2.4 M3 rc1           2.4_rc1         %

                              sato       1:15:58              1:15:24           -0.75

                              rootfs    2:34                    2:45                 7.14

                              rmwork 1:08:15              1:08:19           0.10

                              kernel    5:36                    5:41                 1.49

                              eSDK      2:39                    2:40                 0.63

                                                                          

                                                                          

Fedora                 Test       2.4 M3 rc1           2.4_rc1         %

                              sato       1:14:13              1:17:02           3.80

                              rootfs    2:35                    2:44                 5.81

                              rmwork 1:09:06              1:10:25           1.91

                              kernel    5:58                    6:04                 1.68

                              eSDK      2:37                    2:42                 3.18

 

 

======= QA-Hints========

 

Due to the fact that, there are 5 high priority bugs and 46 bugs targeted to be fixed and solved by 2.4 M4, QA requests an RC2 so that all the commits/fixes relevant to 2.4 release are integrated.

 

======= Bugs ========

 

       New Bugs

            -12143[1] Ptest-runner does not run python, in 2.4rc1

            -12144[2] ptest-busybox cases failed in 2.4rc1

            -12145[3] ptest-bash cases failed in 2.4rc1

            -12146[4] ptest-e2fsprog cases failed in 2.4rc1

            -12194[5] Toaster server lost "toaster.conf" environment, user settings lost

            -12131[6] Kernel traceback when reboot beaglebone black Medium+

            -12170[7] Add mkfs.ext support to busybox on poky-tiny

            -12138[8] [master] the icon on the connection manager appears without connection in Eclipse Plugin 

            -12168[9] media player - must be warned that it is not possible to play MPEG-1 and MP3 formats

            -12150[10] bug for QA to create Testcases for this new test on testopia AUTO_eSDK_sdkext

            -12133[11] The search results for numbers are incorrect.

            -12140[12] The link and the x button from the search's result did not work as expected

            -12142[13] The color from the table from the project build changed when you use an special character.

            -12164[14] The field from time's task is empty

            -12171[15] After building an image, checking the packages there's nothing.

            -12175[16] [Test Case 946] View detailed configuration information for a build

            -12200[17] The button from New custom image is not working as expected

            -12201[18] The button from New custom image is letting you press it and it’s supposed to be disabled.

 

 

       Not new M+ bugs

            -11994[19]  Graphical qemu doesn’t work over remote X on Fedora 26

 

 

 

Full Bug Report: https://wiki.yoctoproject.org/wiki/WW40_-_2017-10-06_-_Full_Test_Cycle_2.4_RC1#Bugs_Found_during_QA_Test

 

 

======== Links =========

    1.    https://bugzilla.yoctoproject.org/show_bug.cgi?id=12143[1]

 

    2.    https://bugzilla.yoctoproject.org/show_bug.cgi?id=12144[2]

 

    3.    https://bugzilla.yoctoproject.org/show_bug.cgi?id=12145[3]

 

    4.    https://bugzilla.yoctoproject.org/show_bug.cgi?id=12146[4]

 

    5.    https://bugzilla.yoctoproject.org/show_bug.cgi?id=12194[5]

 

    6.    https://bugzilla.yoctoproject.org/show_bug.cgi?id=12131[6]

 

    7.    https://bugzilla.yoctoproject.org/show_bug.cgi?id=12170[7]

 

    8.    https://bugzilla.yoctoproject.org/show_bug.cgi?id=12138[8]

 

    9.    https://bugzilla.yoctoproject.org/show_bug.cgi?id=12168[9]

 

    10.    https://bugzilla.yoctoproject.org/show_bug.cgi?id=12150[10]

 

    11.    https://bugzilla.yoctoproject.org/show_bug.cgi?id=12133[11]

 

    12.    https://bugzilla.yoctoproject.org/show_bug.cgi?id=12140[12]

 

    13.    https://bugzilla.yoctoproject.org/show_bug.cgi?id=12142[13]

 

    14.    https://bugzilla.yoctoproject.org/show_bug.cgi?id=12164[14]

 

    15.    https://bugzilla.yoctoproject.org/show_bug.cgi?id=12171[15]

 

    16.    https://bugzilla.yoctoproject.org/show_bug.cgi?id=12175[16]

 

    17.    https://bugzilla.yoctoproject.org/show_bug.cgi?id=12200[17]

 

    18.    https://bugzilla.yoctoproject.org/show_bug.cgi?id=12201[18]

 

    19.    https://bugzilla.yoctoproject.org/show_bug.cgi?id=11994[19]

 

    20.    https://wiki.yoctoproject.org/wiki/WW40_-_2017-10-06_-_Full_Test_Cycle_2.4_RC1#Current_community_Open_Bugs_-_Medium.2B.2FHigh[20]

 

Regards

Libertad G.

 

 


Re: Framework to implement mirroring in Yocto

Andre McCurdy <armccurdy@...>
 

On Fri, Oct 6, 2017 at 3:08 PM, Gutierrez, Hernan Ildefonso (Boise
R&D, FW) <hernan_gutierrez@hp.com> wrote:
Hi,

We are planning to implement a mirror for both source code downloaded and
sscache in our work environment.

We are planning to use Nexus and Nuget to allow storage and versioning
control. We don’t know if these are the right tools.
There are two main aspects of a mirror, fetching from the mirror
(happens during the build process) and populating the mirror
(generally happens outside the main build process).

For fetching from the mirror during the build process, the bitbake
fetchers are used, so your server needs to be accessible via a
protocol which the fetchers support, e.g http or https would be
recommended. Support for sstate mirrors via https with a password (ie
if you want private mirrors which can be accessed over the internet
without needing a VPN) was first added in pyro, so you'll need to
backport a couple of patches to make that work with morty. If the
standard bitbake fetchers don't meet your needs then it's not a huge
task to write a custom fetcher - see the Amazon S3 fetcher recently
added to bitbake. It's less than 100 lines of code.

For populating the mirror, you will likely need to implement something
custom, ie outside bitbake and the build process, since bitbake only
really supports writing sstate and downloads to local directories. It
could be something as simple as running rsync after every build to
upload from the build server's local sstate and downloads directories
to the mirror server(s). It could be something more complex - it's up
to you.

Note that for both sstate and downloads the files on the mirror would
be expected to be unique (e.g. there would never be two different
versions of "gcc-6.3.0.tar.bz2", etc), so there's no obvious reason to
be able to snapshot or version the state of the mirrors. Just let the
files accumulate over time - the old versions won't be lost or
over-written.

Since we are about to embark in this project, before starting I wanted to
know if you have some pointers on how can be implemented a mirroring
framework for yocto.

Not sure if there are some common tools (other tools) with which yocto
integrates nicely.

Any pointers will be appreciated,


Framework to implement mirroring in Yocto

Gutierrez, Hernan Ildefonso (Boise R&D, FW) <hernan_gutierrez@...>
 

Hi,

 

We are planning to implement a mirror for both source code downloaded and sscache in our work environment.

 

We are planning to use Nexus and Nuget to allow storage and versioning control. We don’t know if these are the right tools.

 

Since we are about to embark in this project, before starting I wanted to know if you have some pointers on how can be implemented a mirroring framework for yocto.

 

Not sure if there are some common tools (other tools) with which yocto integrates nicely.

 

Any pointers will be appreciated,

 

--Hernan

 

PS> We are in morty branch currently.


Re: [opkg-devel] [opkg-utils PATCH] opkg.py/opkg-make-index: Add option to include all fields

Alejandro del Castillo <alejandro.delcastillo@...>
 

yep, that makes sense, thanks for the contribution

merged

On 10/05/2017 12:03 PM, Jeffrey Pautler wrote:
If the -f option is enabled, opkg-make-index will include user-defined
fields in the package index rather than discarding them. This change is
motivated by the fact that opkg now has support for user-defined fields
in the package index.
Signed-off-by: Jeffrey Pautler <jeffrey.pautler@ni.com>
---
opkg-make-index | 11 +++++++----
opkg.py         | 28 ++++++++++++++++++----------
2 files changed, 25 insertions(+), 14 deletions(-)
diff --git a/opkg-make-index b/opkg-make-index
index 3f757f6..3227fc0 100755
--- a/opkg-make-index
+++ b/opkg-make-index
@@ -11,7 +11,7 @@ import re
verbose = 0
 def usage():
-     sys.stderr.write("%s [-h] [-s] [-m] [-a] [-l Packages.filelist] [-p Packages] [-r Packages.old] [-L localesdir] [-v] packagesdir\n" % (sys.argv[0],))
+     sys.stderr.write("%s [-h] [-s] [-m] [-a] [-f] [-l Packages.filelist] [-p Packages] [-r Packages.old] [-L localesdir] [-v] packagesdir\n" % (sys.argv[0],))
      sys.exit(-1)
 def to_morgue(filename):
@@ -43,7 +43,8 @@ stamplist_filename = "Packages.stamps"
opt_s = 0
opt_m = 0
opt_a = 0
-(opts, remaining_args) = getopt.getopt(sys.argv[1:], "hl:p:vsmr:L:a")
+opt_f = 0
+(opts, remaining_args) = getopt.getopt(sys.argv[1:], "hl:p:vsmr:L:af")
for (optkey, optval) in opts:
      if optkey == '-h':
           usage()
@@ -64,6 +65,8 @@ for (optkey, optval) in opts:
           locales_dir = optval
      if optkey == '-a':
           opt_a = 1
+     if optkey == '-f':
+          opt_f = 1
 if ( not remaining_args ):
      usage()
@@ -81,7 +84,7 @@ if old_filename:
      if (verbose):
           sys.stderr.write("Reading package list from " + old_filename + "\n")
      old_packages = opkg.Packages()
-     old_packages.read_packages_file(old_filename)
+     old_packages.read_packages_file(old_filename, opt_f)
      for k in list(old_packages.packages.keys()):
           p = old_packages.packages[k]
           old_pkg_hash[p.filename] = p
@@ -122,7 +125,7 @@ for abspath in files:
      if not pkg:
           if (verbose):
                sys.stderr.write("Reading info for package %s\n" % (filename,))
-          pkg = opkg.Package(abspath, relpath=pkg_dir)
+          pkg = opkg.Package(abspath, relpath=pkg_dir, all_fields=opt_f)
      if opt_a:
           pkg_key = ("%s:%s:%s" % (pkg.package, pkg.architecture, pkg.version))
diff --git a/opkg.py b/opkg.py
index 9131755..cdadcab 100644
--- a/opkg.py
+++ b/opkg.py
@@ -45,6 +45,7 @@ from stat import ST_SIZE
import arfile
import tarfile
import textwrap
+import collections
 class Version(object):
     """A class for holding parsed package version information."""
@@ -123,7 +124,7 @@ class Package(object):
     # relpath: If this argument is set, the file path is given relative to this
     #   path when a string representation of the Package object is created. If
     #   this argument is not set, the basename of the file path is given.
-    def __init__(self, fn=None, relpath=None):
+    def __init__(self, fn=None, relpath=None, all_fields=None):
         self.package = None
         self.version = 'none'
         self.parsed_version = None
@@ -153,6 +154,7 @@ class Package(object):
         self.fn = fn
         self.license = None
+        self.user_defined_fields = collections.OrderedDict()
         if fn:
             # see if it is deb format
             f = open(fn, "rb")
@@ -176,7 +178,7 @@ class Package(object):
             except KeyError:
                 control = tarf.extractfile("./control")
             try:
-                self.read_control(control)
+                self.read_control(control, all_fields)
             except TypeError as e:
                 sys.stderr.write("Cannot read control file '%s' - %s\n" % (fn, e))
             control.close()
@@ -215,7 +217,7 @@ class Package(object):
             self.size = stat[ST_SIZE]
         return int(self.size)
-    def read_control(self, control):
+    def read_control(self, control, all_fields=None):
         import os
         line = control.readline()
@@ -227,19 +229,22 @@ class Package(object):
             line = line.rstrip()
             lineparts = re.match(r'([\w-]*?):\s*(.*)', line)
             if lineparts:
-                name = lineparts.group(1).lower()
+                name = lineparts.group(1)
+                name_lowercase = name.lower()
                 value = lineparts.group(2)
                 while 1:
                     line = control.readline()
                     if not line: break
                     if line[0] != ' ': break
                     value = value + '\n' + line
-                if name == 'size':
+                if name_lowercase == 'size':
                     self.size = int(value)
-                elif name == 'md5sum':
+                elif name_lowercase == 'md5sum':
                     self.md5 = value
-                elif name in self.__dict__:
-                    self.__dict__[name] = value
+                elif name_lowercase in self.__dict__:
+                    self.__dict__[name_lowercase] = value
+                elif all_fields:
+                    self.user_defined_fields[name] = value
                 else:
                     print("Lost field %s, %s" % (name,value))
                     pass
@@ -490,6 +495,9 @@ class Package(object):
         if self.license: out = out + "License: %s\n" % (self.license)
         if self.priority: out = out + "Priority: %s\n" % (self.priority)
         if self.tags: out = out + "Tags: %s\n" % (self.tags)
+        if self.user_defined_fields:
+            for k, v in self.user_defined_fields.items():
+                out = out + "%s: %s\n" % (k, v)
         out = out + "\n"
         return out
@@ -523,12 +531,12 @@ class Packages(object):
         else:
             return 1
-    def read_packages_file(self, fn):
+    def read_packages_file(self, fn, all_fields=None):
         f = open(fn, "r")
         while True:
             pkg = Package()
             try:
-                pkg.read_control(f)
+                pkg.read_control(f, all_fields)
             except TypeError as e:
                 sys.stderr.write("Cannot read control file '%s' - %s\n" % (fn, e))
                 continue
--
2.7.4
--
You received this message because you are subscribed to the Google Groups "opkg-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email to opkg-devel+unsubscribe@googlegroups.com <mailto:opkg-devel+unsubscribe@googlegroups.com>.
For more options, visit https://groups.google.com/d/optout <https://urldefense.proofpoint.com/v2/url?u=https-3A__groups.google.com_d_optout&d=DwMFaQ&c=I_0YwoKy7z5LMTVdyO6YCiE2uzI1jjZZuIPelcSjixA&r=wNcrL2akRn6jfxhHaKavUrJB_C9JAMXtynjLd8ZzgXQ&m=ovQLEvQ9Lx-7vCjplOAzesO39gF_IJUaWHnH7MYJRKk&s=Cjo25iHoDUxMx8anWywj0hPZTramOkXjGn9UCLksWcU&e=>.
--
Cheers,

Alejandro


Re: Boost + Yocto

Khem Raj
 

On Fri, Oct 6, 2017 at 7:56 AM, Patrick Vacek
<patrick@advancedtelematic.com> wrote:
On 06.10.2017 15:36, Khem Raj wrote:
On Fri, Oct 6, 2017 at 5:05 AM, Patrick Vacek
<patrick@advancedtelematic.com> wrote:
Hello,

I'm trying to understand how Yocto figures out which Boost libraries to
install in an image. I've been studying the Boost recipes and it looks
like RRECOMMENDS is used to specify all of the libraries, but yet my
image only gets a subset of them. It's the subset that I typically need,
so it's fine, but I want to understand how the process works.

There's an additional tricky detail that got me looking into this. When
I bitbake a recipe I've written which just lists "boost" in DEPENDS,
running ldd the compiled executable does not appear to depend on a
couple of the boost libraries that I'd specified in CMake (although it
does depend on several others). Only the libraries that are specifically
mentioned with ldd are installed in the image. However, if I manually
cross-compile the same code via the native-sdk, ldd indicates that all
the expected libraries are dependencies. As such, that executable will
not be able to run on my device until I install the missing libraries.
Oddly, those libraries are built with bitbake, but not installed! How
does bitbake manage to remove some of these dependencies?
it could be thst applications dependency detection mechanism is behaving
differently and presenting different set to linker.

Secondly its possible that linker options in play are different e.g.
--as-needed and --copy-dt-needed-entries might be in play
It turns out that the troublesome boost libraries are not actually used
after all! I haven't yet deduced if the sort of linker flags you
mentioned are being used, but that may be at the root of the issue.

What's now confusing me is why, after removing all references to the
extraneous libraries, CMake still finds them and the cross-compiled
binary still links against them. The only thought I've had so far is
that they are a transitive dependency, although that seems unlikely.
However, that's probably a matter to look into with CMake, not Yocto...
its possible that the faulty build is using a linker which defaults to
pulling libraries from DT_NEEDED segments


Basic question: "core-image-minimal" v.s "core-image-base" ?

Jerry Lian <jerry.lian@...>
 

Hi, all:

I have a basic question: how to tell the difference between "core-image-minimal" and "core-image-base"?
* If we look at file \poky\meta\recipes-core\images\core-image-base.bb
===================================================================================
SUMMARY = "A console-only image that fully supports the target device hardware."

IMAGE_FEATURES += "splash"

LICENSE = "MIT"

inherit core-image
===================================================================================
* how can we tell that "core-image-base" will include "support for a variety of hardware such as WIFI, bluetooth...", as compare to "core-image-minimal"?
* Do I miss any other document that I need to read?

Thanks!
Jerry


Re: [opkg-devel] [opkg-utils PATCH] opkg.py: Remove reformatting of description field

Alejandro del Castillo <alejandro.delcastillo@...>
 

Agreed, opkg-make-index spould not be formatting control files. Description should be treated as any other field.

merged

On 10/05/2017 09:05 AM, Jeffrey Pautler wrote:
The Debian Policy Manual describes the format of the description field.
This includes information about how lines might be wrapped by programs
displaying this information, how to mark lines to not be wrapped, how
to mark a line as blank, and how leading spaces on a multi-line
description might be deleted.
By reformatting the description field in opkg.py, we are breaking many
of these behaviors and taking control of formatting away from the
author of the control file. Instead, we should simply copy the
description field with no reformatting.
Signed-off-by: Jeffrey Pautler <jeffrey.pautler@ni.com>
---
opkg.py | 8 ++------
1 file changed, 2 insertions(+), 6 deletions(-)
diff --git a/opkg.py b/opkg.py
index 9131755..c0cdcd5 100644
--- a/opkg.py
+++ b/opkg.py
@@ -230,7 +230,7 @@ class Package(object):
                 name = lineparts.group(1).lower()
                 value = lineparts.group(2)
                 while 1:
-                    line = control.readline()
+                    line = control.readline().rstrip()
                     if not line: break
                     if line[0] != ' ': break
                     value = value + '\n' + line
@@ -480,11 +480,7 @@ class Package(object):
         if self.installed_size: out = out + "InstalledSize: %d\n" % int(self.installed_size)
         if self.filename: out = out + "Filename: %s\n" % (self.filename)
         if self.source: out = out + "Source: %s\n" % (self.source)
-        if self.description:
-            printable_description = textwrap.dedent(self.description).strip()
-            summary = printable_description.split('\n', 1)[0]
-            printable_description = printable_description.split('\n', 1)[-1].strip()
-            out = out + "Description: %s\n%s\n" % (summary, textwrap.fill(printable_description, width=74, initial_indent=' ', subsequent_indent=' '))
+        if self.description: out = out + "Description: %s\n" % (self.description)
         if self.oe: out = out + "OE: %s\n" % (self.oe)
         if self.homepage: out = out + "HomePage: %s\n" % (self.homepage)
         if self.license: out = out + "License: %s\n" % (self.license)
--
2.7.4
--
You received this message because you are subscribed to the Google Groups "opkg-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email to opkg-devel+unsubscribe@googlegroups.com <mailto:opkg-devel+unsubscribe@googlegroups.com>.
For more options, visit https://groups.google.com/d/optout <https://urldefense.proofpoint.com/v2/url?u=https-3A__groups.google.com_d_optout&d=DwMFaQ&c=I_0YwoKy7z5LMTVdyO6YCiE2uzI1jjZZuIPelcSjixA&r=wNcrL2akRn6jfxhHaKavUrJB_C9JAMXtynjLd8ZzgXQ&m=SjrJd3411AwLD4Dn6cj5fJxIrZ4Fet4b54t4bmitpWM&s=boq46c76IPvFqTwi4dlGOI7VtCn4aV7kqsCa_BXdMI0&e=>.
--
Cheers,

Alejandro


Re: read-only-rootfs causes systemd-tmpfiles-setup.service failure ( symlink(../run/lock, /var/lock) failed: Read-only file system)

Ayoub Zaki <ayoub.zaki@...>
 

Hi,

On 06.10.2017 15:40, richard_allen@keysight.com wrote:
I am build an image with read-only-rootfs
When enabled, during startup I get a

[FAILED] Failed to start Create Volatile Files and Directories.
See 'systemctl status systemd-tmpfiles-setup.service' for details.



● systemd-tmpfiles-setup.service - Create Volatile Files and Directories
Loaded: loaded (/lib/systemd/system/systemd-tmpfiles-setup.service; static; vendor pre
set: enabled)
Active: failed (Result: exit-code) since Fri 2017-09-01 19:16:27 UTC; 3min 52s ago
Docs: man:tmpfiles.d(5)
man:systemd-tmpfiles(8)
Process: 945 ExecStart=/bin/systemd-tmpfiles --create --remove --boot --exclude-prefix=
/dev (code=exited, status=1/FAILURE)
Main PID: 945 (code=exited, status=1/FAILURE)

Sep 01 19:16:27 dso systemd[1]: Starting Create Volatile Files and Directories...
Sep 01 19:16:27 dso systemd-tmpfiles[945]: symlink(../run/lock, /var/lock) failed: Read-only file system
Sep 01 19:16:27 dso systemd-tmpfiles[945]: "/var/tmp" already exists and is not a directory.
Sep 01 19:16:27 dso systemd-tmpfiles[945]: "/var/log" already exists and is not a directory.
Sep 01 19:16:27 dso systemd[1]: systemd-tmpfiles-setup.service: Main process exited, code=exited, status=1/FAILURE
Sep 01 19:16:27 dso systemd[1]: Failed to start Create Volatile Files and Directories.
Sep 01 19:16:27 dso systemd[1]: systemd-tmpfiles-setup.service: Unit entered failed state.
Sep 01 19:16:27 dso systemd[1]: systemd-tmpfiles-setup.service: Failed with result 'exit-code'.


Not clear if I should be worried about this.
If so, what should be done?
Thanks


Richard C. Allen
Keysight Technologies
richard_allen@Keysight.com
can you show your /etc/fstab ?

--
Ayoub Zaki
Embedded Systems Consultant

Vaihinger Straße 2/1
D-71634 Ludwigsburg

Tel. : +4971415074546
Mobile : +4917662901545
Email : ayoub.zaki@embexus.com
Homepage : https://embexus.com


Re: Boost + Yocto

Patrick Vacek <patrick@...>
 

On 06.10.2017 15:36, Khem Raj wrote:
On Fri, Oct 6, 2017 at 5:05 AM, Patrick Vacek
<patrick@advancedtelematic.com> wrote:
Hello,

I'm trying to understand how Yocto figures out which Boost libraries to
install in an image. I've been studying the Boost recipes and it looks
like RRECOMMENDS is used to specify all of the libraries, but yet my
image only gets a subset of them. It's the subset that I typically need,
so it's fine, but I want to understand how the process works.

There's an additional tricky detail that got me looking into this. When
I bitbake a recipe I've written which just lists "boost" in DEPENDS,
running ldd the compiled executable does not appear to depend on a
couple of the boost libraries that I'd specified in CMake (although it
does depend on several others). Only the libraries that are specifically
mentioned with ldd are installed in the image. However, if I manually
cross-compile the same code via the native-sdk, ldd indicates that all
the expected libraries are dependencies. As such, that executable will
not be able to run on my device until I install the missing libraries.
Oddly, those libraries are built with bitbake, but not installed! How
does bitbake manage to remove some of these dependencies?
it could be thst applications dependency detection mechanism is behaving
differently and presenting different set to linker.

Secondly its possible that linker options in play are different e.g.
--as-needed and --copy-dt-needed-entries might be in play
It turns out that the troublesome boost libraries are not actually used
after all! I haven't yet deduced if the sort of linker flags you
mentioned are being used, but that may be at the root of the issue.

What's now confusing me is why, after removing all references to the
extraneous libraries, CMake still finds them and the cross-compiled
binary still links against them. The only thought I've had so far is
that they are a transitive dependency, although that seems unlikely.
However, that's probably a matter to look into with CMake, not Yocto...

Thanks!

--
Patrick Vacek
ATS Advanced Telematic Systems GmbH
Kantstraße 162, 10623 Berlin
HRB 151501 B, Amtsgericht Charlottenburg
Vertreten durch die Geschäftsführer
Dirk Pöschl, Armin G. Schmidt


Re: Bitbaking a recipe often triggers a do_package_write_rpm of a dependant recipe... why?

Khem Raj
 

On Thu, Oct 5, 2017 at 3:09 AM, Torsten Sievers
<torstensievers@googlemail.com> wrote:
Hi guys,

Here is the situation:

I have two custom made recipes, one is a SDK , the other one is a set of
examples that use the sdk.

The examples recipe has DEPENDS and RDEPENDS set that point to artifacts
that are produced by the SDK recipe.

So far, so normal

Now the strange thing happens:

when I do

bitbake sdk

everything is fine, it configures,compiles,installs and eventually create a
rpm (by do_package_write_rpm)

when I run

bitbake examples

immediately after the finish of the bitbake sdk

it is compiling,installing etc the example rpm. However it is also very
often (but not always) re-triggering the do_package_write_rpm from the SDK.
but why?

I double checked, the SDK code/recipe was not touched, and the SDK rpm was
sitting right there before I bitbaked the examples.


i am digging deep inside bitbake / yocto recipes for days but i cannot find
the rootcause...

Any hint what could cause this? I would not bother too much, but the
building of the SDK rpms takes roughly 10 minutes, thus significantly
slowing down my development iterations.

Any hints are highly appreciated...
hard to know without seeing the code but you can try to dump the task
signatures for do_package_write_rpm task from sdk recipe or use
bitbake-diffsigs tool to compute the differencs between two runs of
this task which
can give some insights into the task variable dependencies which might be
in play

BR
Torsten


--
_______________________________________________
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto


read-only-rootfs causes systemd-tmpfiles-setup.service failure ( symlink(../run/lock, /var/lock) failed: Read-only file system)

richard allen
 

I am build an image with read-only-rootfs
When enabled, during startup I get a

[FAILED] Failed to start Create Volatile Files and Directories.
See 'systemctl status systemd-tmpfiles-setup.service' for details.



● systemd-tmpfiles-setup.service - Create Volatile Files and Directories
Loaded: loaded (/lib/systemd/system/systemd-tmpfiles-setup.service; static; vendor pre
set: enabled)
Active: failed (Result: exit-code) since Fri 2017-09-01 19:16:27 UTC; 3min 52s ago
Docs: man:tmpfiles.d(5)
man:systemd-tmpfiles(8)
Process: 945 ExecStart=/bin/systemd-tmpfiles --create --remove --boot --exclude-prefix=
/dev (code=exited, status=1/FAILURE)
Main PID: 945 (code=exited, status=1/FAILURE)

Sep 01 19:16:27 dso systemd[1]: Starting Create Volatile Files and Directories...
Sep 01 19:16:27 dso systemd-tmpfiles[945]: symlink(../run/lock, /var/lock) failed: Read-only file system
Sep 01 19:16:27 dso systemd-tmpfiles[945]: "/var/tmp" already exists and is not a directory.
Sep 01 19:16:27 dso systemd-tmpfiles[945]: "/var/log" already exists and is not a directory.
Sep 01 19:16:27 dso systemd[1]: systemd-tmpfiles-setup.service: Main process exited, code=exited, status=1/FAILURE
Sep 01 19:16:27 dso systemd[1]: Failed to start Create Volatile Files and Directories.
Sep 01 19:16:27 dso systemd[1]: systemd-tmpfiles-setup.service: Unit entered failed state.
Sep 01 19:16:27 dso systemd[1]: systemd-tmpfiles-setup.service: Failed with result 'exit-code'.


Not clear if I should be worried about this.
If so, what should be done?
Thanks


Richard C. Allen
Keysight Technologies
richard_allen@Keysight.com


Re: Boost + Yocto

Khem Raj
 

On Fri, Oct 6, 2017 at 5:05 AM, Patrick Vacek
<patrick@advancedtelematic.com> wrote:
Hello,

I'm trying to understand how Yocto figures out which Boost libraries to
install in an image. I've been studying the Boost recipes and it looks
like RRECOMMENDS is used to specify all of the libraries, but yet my
image only gets a subset of them. It's the subset that I typically need,
so it's fine, but I want to understand how the process works.

There's an additional tricky detail that got me looking into this. When
I bitbake a recipe I've written which just lists "boost" in DEPENDS,
running ldd the compiled executable does not appear to depend on a
couple of the boost libraries that I'd specified in CMake (although it
does depend on several others). Only the libraries that are specifically
mentioned with ldd are installed in the image. However, if I manually
cross-compile the same code via the native-sdk, ldd indicates that all
the expected libraries are dependencies. As such, that executable will
not be able to run on my device until I install the missing libraries.
Oddly, those libraries are built with bitbake, but not installed! How
does bitbake manage to remove some of these dependencies?
it could be thst applications dependency detection mechanism is behaving
differently and presenting different set to linker.

Secondly its possible that linker options in play are different e.g.
--as-needed and --copy-dt-needed-entries might be in play


Re: Adding support for yum in a yocto image

Alexander Kanavin <alexander.kanavin@...>
 

On 10/05/2017 10:08 PM, Josef Holzmayr wrote:

Uhm. Be aware that your custom built distribution is *not* some kind of Fedora-Light. Its an entirely different distribution, and mixing in repositories from somewhere is most certainly disastrous - or do you think using that OpenSuse repo plays along nicely with your CentOS install? :-)
Also epel-release provides packages only for server architectures: x86_64, ppc64, and aarch64, so if the 'network device' is built on anything else, the whole thing is a non-starter.

I generally agree that attempting to ride on the coattails of desktop/server Linux vendors is asking for frustration. People are still trying though:
https://bugzilla.yoctoproject.org/show_bug.cgi?id=10422

Much better to just write the recipes from the start, and share them with the community :)

Alex

16541 - 16560 of 54800