Re: [yocto] unpacking deb packages

[Burton, Ross]

On 10 April 2017 at 14:32, Markus Volk  wrote:

> i´m building  for x86_64 using the recent master branch and encounter
> problems when fetching deb packages.
> With any .deb file inside SRC_URI the task do_unpack stops with this
> output:
>
> ... data.tar.xz && tar --no-same-owner -xpf data.tar.xz && rm data.tar.xz
> failed with return value 2
> if i  retry building the same recipe for 1-5 times without any change the
> task sometime completes without errors
>

My immediate hunch would be that it can't find a xz binary inside the
native sysroot as it hasn't been written in there yet.  Can you provide a
minimal recipe to test?

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

Re: [yocto] [OE-core] [PATCH v3] logrotate: Add systemd support

[Burton, Ross]

On 13 April 2017 at 08:42, Romain Perier 
wrote:

> --- /dev/null
> +++ b/meta/recipes-extended/logrotate/logrotate/logrotate.service
> @@ -0,0 +1,10 @@
> +[Unit]
> +Description=Rotate log files
> +ConditionACPower=true
> +
> +[Service]
> +Type=oneshot
> +ExecStart=/usr/sbin/logrotate /etc/logrotate.conf
>

Hard-coding these paths breaks anyone who wants to change them, use symbols
and replace them at build time.


> +SYSTEMD_AUTO_ENABLE = "disable"
>

What's the rationale for disabling logrotate by default?  The cron script
in the sysv case isn't disabled out of the box from what I can tell, so
that's a behavioural change based on init.


> +LOGROTATE_SYSTEMD_TIMER_BASIS ?= "daily"
> +LOGROTATE_SYSTEMD_TIMER_ACCURACY ?= "12h"
>

Do these really need to be variables in the recipe?

+# Install systemd unit files
> +if [ "${@bb.utils.contains('DISTRO_FEATURES', 'systemd', 'systemd',
> '', d)}" = "systemd" ]; then
> +install -d ${D}${systemd_system_unitdir}
> +install -m 0644 ${WORKDIR}/logrotate.service
> ${D}${systemd_system_unitdir}/logrotate.service
> +install -m 0644 ${WORKDIR}/logrotate.timer
> ${D}${systemd_system_unitdir}/logrotate.timer
> +sed -i -e 
> 's,OnCalendar=.*$,OnCalendar=${LOGROTATE_SYSTEMD_TIMER_BASIS},g'
> ${D}${systemd_system_unitdir}/logrotate.timer
> +sed -i -e 
> 's,AccuracySec=.*$,AccuracySec=${LOGROTATE_SYSTEMD_TIMER_ACCURACY},g'
> ${D}${systemd_system_unitdir}/logrotate.timer
> +else
> +mkdir -p ${D}${sysconfdir}/cron.daily
> +install -p -m 0755 examples/logrotate.cron
> ${D}${sysconfdir}/cron.daily/logrotate
> +fi
>

This breaks if the DISTRO_FEATURES contains both sysvinit and systemd (so
packages should contain the systemd and sysv integration), and different
images are generated that use either sysvinit or systemd.  With this the
cron hooks won't be added but if the package is used under sysv they'll be
needed.

Not that I have a good idea for how to solve this.  Maybe the cron should
check the timer unit isn't running?

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

Re: [yocto] [meta-raspberrypi][PATCH v2 0/3] pitft: Add support for pitft35r

[Andrei Gherzan]

Hi Rob,

On Thu, Apr 13, 2017 at 3:09 PM, Rob Woolley  wrote:
> Hi Andrei,
>
> Does this patchset look okay?
>
> Are there any further changes you would like me to make?

Looks good. I'll test it and merge it soon.
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [meta-raspberrypi][PATCH v2 0/3] pitft: Add support for pitft35r

[Rob Woolley]

Hi Andrei,

Does this patchset look okay?

Are there any further changes you would like me to make?

Regards,
Rob

On Thu, Apr 6, 2017 at 2:44 PM, Rob Woolley 
wrote:

> As requested, I have split the patch into separate commits for:
>
>   1. dtbo inclusion
>   2. rpi-config changes
>   3. Documentation commit
>
> I ordered them this way in case a user ever walked through the
> commits in the git tree.  This way the prerequisites are present
> before the feature is advertised in the documentation.
>
> Hope this works for you.  Let me know if there are any additional
> changes that need to be made.
>
> Regards,
> Rob
> --
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
>
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] bare-metal RPi2B & RPI3B

[Edward Vidal]

Hello All,
As of now I have been able to get the library of openjpeg running in bare-metal 
RPi2B or RPi3B.With just 5 files on a RPi2B or RPi3B the compression of bitmap 
is done.bootcode.bin  fixup.dat  kernel7.img  MyBitmap.bmp  start.elf.In 
addition this provides a TFTP server and Telnet services.In 26 sec the RPi3B 
boots and does a compression of a 1024 x 1024 image.The compression takes 5 sec 
 These files are found at 
https://github.com/develone/jpeg-2000-test/tree/master/bare-metal/openjp/sd-card/see
 
https://github.com/develone/jpeg-2000-test/blob/master/bare-metal/LibC/LibC.pdfand
 the openjpeg library 
https://github.com/develone/openjpeg/blob/ultibo/openjpeg.odtI forked the 
openjpeg repo and created a ultibo branch.The compiler used is arm-none-eabi 
tools to compile the C code and Free Pascal Compiler to compile and link 
kernel7.img.
This is the documentation to date.
pi@raspberrypi3:~ $ export 
PATH=/home/pi/ultibo/core/fpc/bin:$PATHpi@raspberrypi3:~ $ cd 
jpeg-2000-test/bare-metal/openjp/pi@raspberrypi3:~/jpeg-2000-test/bare-metal/openjp
 $ ./compile.sh Thu 13 Apr 11:36:26 UTC 2017Word count arm-none-eabi-ar -t 
libopenjp2.acopied from /home/pi/t_ultibo/src/lib/openjp2     22      22     
180Target OS: UltiboCompiling DWT_LIFT_RPi2.lprCompiling uTFTP.pasAssembling 
utftpCompiling uliftbitmap.pasCompiling uBufferToC.pasAssembling 
uliftbitmapAssembling dwt_lift_rpi2Linking DWT_LIFT_RPi21086 lines compiled, 
4.7 sec, 2733156 bytes code, 89252 bytes data-rw-r--r-- 1 pi pi    7364 Apr 13 
11:36 dwtlift.o-rwxr-xr-x 1 pi pi 2808540 Apr 13 11:36 kernel7.img-rw-r--r-- 1 
pi pi  356242 Apr 13 11:36 libdwtlift.a-rw-r--r-- 1 pi pi  356242 Apr 13 11:36 
libopenjp2.awhen ./compile.sh is executed should be 23Word count 
libopenjp2_obj.txt in /home/pi/t_ultibo/src/lib/openjp2plus dwtlift.o 23  23 
190 libopenjp2_obj.txt
 Does Wine run in Yocto? This would make Ultibo the Bare-metal project work in 
Yocto.

Let me know if you have any questions. Edward Vidal Jr. e-mail 
devel...@sbcglobal.net 915-595-1613 

On Friday, February 3, 2017 12:37 AM, "yocto-requ...@yoctoproject.org" 
 wrote:
 

 Send yocto mailing list submissions to
    yocto@yoctoproject.org

To subscribe or unsubscribe via the World Wide Web, visit
    https://lists.yoctoproject.org/listinfo/yocto
or, via email, send a message with subject or body 'help' to
    yocto-requ...@yoctoproject.org

You can reach the person managing the list at
    yocto-ow...@yoctoproject.org

When replying, please edit your Subject line so it is more specific
than "Re: Contents of yocto digest..."


Today's Topics:

  1. Re: Ruby and OpenSSL version mismatch? (Khem Raj)
  2. bare-metal RPi2B & RPI3B (Edward Vidal)
  3. [meta-cgl][PATCH 3/3] initramfs: fix parsing issue with do    to
      uboot inclusion (Armin Kuster)
  4. [meta-cgl][PATCH 1/3] iscsi-initiator-utils: make it
      DISTRO_FEATURE dependent (Armin Kuster)


--

Message: 1
Date: Thu, 02 Feb 2017 22:47:40 +
From: Khem Raj 
To: Takashi Matsuzawa ,    "yocto@yoctoproject.org"
    
Subject: Re: [yocto] Ruby and OpenSSL version mismatch?
Message-ID:
    
Content-Type: text/plain; charset="utf-8"

Send a back port request


On Thu, Feb 2, 2017 at 5:32 AM Takashi Matsuzawa 
wrote:

> Hello, I just tried and the below seems to be the fix.
>
>
> https://patchwork.openembedded.org/patch/11/
>
> --
> *From:* Takashi Matsuzawa
> *Sent:* Thursday, February 2, 2017 3:25 PM
> *To:* yocto@yoctoproject.org
> *Subject:* Ruby and OpenSSL version mismatch?
>
>
> Hello, Yocto.
>
> I am trynig a build of fido based yocto image, with openssl 1.0.2j for
> security reason.
> The openssl recipe itself builds successfully, but later in the build I
> see error in jscore.
> In fact, ruby is complaining that 'OPENSSL_1.0.0' is not available.
>
> |
> /xxx/sysroots/x86_64-linux/usr/lib/ruby/2.2.0/rubygems/core_ext/kernel_require.rb:54:in
> `require':
> /xxx/sysroots/x86_64-linux/usr/lib/ruby/2.2.0/x86_64-linux-gnu/digest/../../../../libcrypto.so.1.0.0:
> version `OPENSSL_1.0.0' not found (required by
> /xxx/sysroots/x86_64-linux/usr/lib/ruby/2.2.0/x86_64-linux-gnu/digest/sha1.so)
> -
> /xxx/sysroots/x86_64-linux/usr/lib/ruby/2.2.0/x86_64-linux-gnu/digest/sha1.so
> (LoadError)
> |    from
> /xxx/sysroots/x86_64-linux/usr/lib/ruby/2.2.0/rubygems/core_ext/kernel_require.rb:54:in
> `require'
> |    from
> /xxx/work/core2-32-poky-linux/qtwebkit/5.5.0+gitAUTOINC+0d592678ba-r0/git/Source/JavaScriptCore/offlineasm/generate_offset_extractor.rb:30:in
> `'
> | make[2]: *** [LLIntDesiredOffsets.h] Error 1
>
> In fact, if I do objdump -p on sha1.so (in ruby tree):
>
> >  required from libcrypto.so.1.0.0:
> >    0x066a2b20 0x00 02 OPENSSL_1.0.0
>
> 

[yocto] [PATCH] package.bbclass: Changed PACKAGESPLITFUNCS execution order

[Oleksandr Poznyak]

Fixes [YOCTO #11343]

I've added runtime PACKAGESPLITFUNCS value modification in
the context of do_package() function so that
populate_packages_updatealternatives function is allways
executed before populate_packages_updatercd

Signed-off-by: Oleksandr Poznyak 
---
 meta/classes/package.bbclass | 5 +
 1 file changed, 5 insertions(+)

diff --git a/meta/classes/package.bbclass b/meta/classes/package.bbclass
index cc466bd..149a185 100644
--- a/meta/classes/package.bbclass
+++ b/meta/classes/package.bbclass
@@ -2110,6 +2110,11 @@ python do_package () {
 
 cpath = oe.cachedpath.CachedPath()
 
+# modify PACKAGESPLITFUNCS order
+if "populate_packages_updatealternatives" in d.getVar("PACKAGESPLITFUNCS", 
True):
+d.setVar("PACKAGESPLITFUNCS", "populate_packages_updatealternatives 
%s" \
+% d.getVar("PACKAGESPLITFUNCS", 
True).replace("populate_packages_updatealternatives", ""))
+
 for f in (d.getVar('PACKAGESPLITFUNCS') or '').split():
 bb.build.exec_func(f, d)
 
-- 
2.1.4

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

Re: [yocto] Task dependencies

[Gary Thomas]

On 2017-04-13 09:34, Gary Thomas wrote:

I'm trying to understand why 'perl' is being built for my target
even though I don't mention it in any of the package recipes used
to build that target.  When I used 'taskexp', I found that 'perl:do_build'
only has a single dependent task, namely 'my-image:do_build'
note: no perl packages end up in my image.

This is just one example where it seems bitbake is doing a lot of
unnecessary (certainly un-asked-for) work.

How can I unravel this mystery?

Thanks for any pointers



I think I've figured this out - my image includes a couple of
packages (i2c-tools, ntp) that each have some component that
needs perl although I don't install those components.  So it
now makes sense that perl has to be built for my target even
though I'm not actually using it.

For example, in i2c-tools I see
  RDEPENDS_${PN}-misc = "${PN} perl"
and since I don't actually install i2c-tools-misc, perl isn't
needed.

That said, I had to discover this by manually looking through the
task-depends.dot file as I did not see how to come up with this
answer using -u taskdep alone.

--

Gary Thomas |  Consulting for the
MLB Associates  |Embedded world

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

[yocto] [PATCH v3] logrotate: Add systemd support

[Romain Perier]

Currently, this recipe only supports daily scheduling via a cron job.
This commit adds support for systemd in the recipe, with the
corresponding services backported from upstream. When the distro feature
is enabled the systemd variant will be used. The timer granularity and
its accuracy are also configurable.

Signed-off-by: Romain Perier 
---

Changes in v3:
- After a discussion with RP, that's preferable to integrate systemd support
in the recipe of logrotate 3.9. QA testing will be passed on it, then we will
see if this patch can be merged or delayed to master-next.
- I have backported systemd service and timer from upstream directly
- The bump to 3.11 will wait

 .../logrotate/logrotate/logrotate.service  | 10 
 .../logrotate/logrotate/logrotate.timer| 10 
 meta/recipes-extended/logrotate/logrotate_3.9.1.bb | 27 --
 3 files changed, 45 insertions(+), 2 deletions(-)
 create mode 100644 meta/recipes-extended/logrotate/logrotate/logrotate.service
 create mode 100644 meta/recipes-extended/logrotate/logrotate/logrotate.timer

diff --git a/meta/recipes-extended/logrotate/logrotate/logrotate.service 
b/meta/recipes-extended/logrotate/logrotate/logrotate.service
new file mode 100644
index 000..cf8d3f4
--- /dev/null
+++ b/meta/recipes-extended/logrotate/logrotate/logrotate.service
@@ -0,0 +1,10 @@
+[Unit]
+Description=Rotate log files
+ConditionACPower=true
+
+[Service]
+Type=oneshot
+ExecStart=/usr/sbin/logrotate /etc/logrotate.conf
+Nice=19
+IOSchedulingClass=best-effort
+IOSchedulingPriority=7
diff --git a/meta/recipes-extended/logrotate/logrotate/logrotate.timer 
b/meta/recipes-extended/logrotate/logrotate/logrotate.timer
new file mode 100644
index 000..297c2e4
--- /dev/null
+++ b/meta/recipes-extended/logrotate/logrotate/logrotate.timer
@@ -0,0 +1,10 @@
+[Unit]
+Description=Periodic rotation of log files
+
+[Timer]
+OnCalendar=daily
+AccuracySec=12h
+Persistent=true
+
+[Install]
+WantedBy=timers.target
diff --git a/meta/recipes-extended/logrotate/logrotate_3.9.1.bb 
b/meta/recipes-extended/logrotate/logrotate_3.9.1.bb
index c938d9f..2c254e8 100644
--- a/meta/recipes-extended/logrotate/logrotate_3.9.1.bb
+++ b/meta/recipes-extended/logrotate/logrotate_3.9.1.bb
@@ -23,6 +23,8 @@ SRC_URI = 
"https://github.com/${BPN}/${BPN}/archive/r3-9-1.tar.gz \
file://act-as-mv-when-rotate.patch \
file://update-the-manual.patch \
file://disable-check-different-filesystems.patch \
+   ${@bb.utils.contains('DISTRO_FEATURES', 'systemd', 
'file://logrotate.service', '', d)} \
+   ${@bb.utils.contains('DISTRO_FEATURES', 'systemd', 
'file://logrotate.timer', '', d)} \
 "
 
 SRC_URI[md5sum] = "8572b7c2cf9ade09a8a8e10098500fb3"
@@ -58,12 +60,33 @@ do_compile_prepend() {
 rm -f ${B}/.depend
 }
 
+inherit systemd
+
+SYSTEMD_AUTO_ENABLE = "disable"
+SYSTEMD_SERVICE_${PN} = "\
+${PN}.service \
+${PN}.timer \
+"
+
+LOGROTATE_SYSTEMD_TIMER_BASIS ?= "daily"
+LOGROTATE_SYSTEMD_TIMER_ACCURACY ?= "12h"
+
 do_install(){
 oe_runmake install DESTDIR=${D} PREFIX=${D} MANDIR=${mandir}
 mkdir -p ${D}${sysconfdir}/logrotate.d
-mkdir -p ${D}${sysconfdir}/cron.daily
 mkdir -p ${D}${localstatedir}/lib
 install -p -m 644 examples/logrotate-default 
${D}${sysconfdir}/logrotate.conf
-install -p -m 755 examples/logrotate.cron 
${D}${sysconfdir}/cron.daily/logrotate
 touch ${D}${localstatedir}/lib/logrotate.status
+
+# Install systemd unit files
+if [ "${@bb.utils.contains('DISTRO_FEATURES', 'systemd', 'systemd', '', 
d)}" = "systemd" ]; then
+install -d ${D}${systemd_system_unitdir}
+install -m 0644 ${WORKDIR}/logrotate.service 
${D}${systemd_system_unitdir}/logrotate.service
+install -m 0644 ${WORKDIR}/logrotate.timer 
${D}${systemd_system_unitdir}/logrotate.timer
+sed -i -e 
's,OnCalendar=.*$,OnCalendar=${LOGROTATE_SYSTEMD_TIMER_BASIS},g' 
${D}${systemd_system_unitdir}/logrotate.timer
+sed -i -e 
's,AccuracySec=.*$,AccuracySec=${LOGROTATE_SYSTEMD_TIMER_ACCURACY},g' 
${D}${systemd_system_unitdir}/logrotate.timer
+else
+mkdir -p ${D}${sysconfdir}/cron.daily
+install -p -m 0755 examples/logrotate.cron 
${D}${sysconfdir}/cron.daily/logrotate
+fi
 }
-- 
2.9.3

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

[yocto] Task dependencies

[Gary Thomas]

I'm trying to understand why 'perl' is being built for my target
even though I don't mention it in any of the package recipes used
to build that target.  When I used 'taskexp', I found that 'perl:do_build'
only has a single dependent task, namely 'my-image:do_build'
note: no perl packages end up in my image.

This is just one example where it seems bitbake is doing a lot of
unnecessary (certainly un-asked-for) work.

How can I unravel this mystery?

Thanks for any pointers

--

Gary Thomas |  Consulting for the
MLB Associates  |Embedded world

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

Re: [yocto] 'and' combination for OVERRIDES values?

[Takashi Matsuzawa]

Hello.


>AAA_xxx_yyy = "true"

Thank you, I will try.  I could not figure out but I feel it should work.


From: Paul Eggleton 
Sent: Thursday, April 13, 2017 2:23 PM
To: Takashi Matsuzawa
Cc: yocto@yoctoproject.org
Subject: Re: [yocto] 'and' combination for OVERRIDES values?

On Thursday, 13 April 2017 12:16:08 PM NZST Takashi Matsuzawa wrote:
> I just wonder if there is convenient way of defining somthing in recipes
> based on combination of two OVERRIDES variables. Say, I have two variables
> xxx and yyy.
>
> AAA = "false"
> AAA_xxx = "true"
> AAA_yyy = "true"
>
> But what if I want to set AAA to be "true" only when xxx and yyy are in
> OVERRIDES? (And also for 'or' condition.)

This should work for "and":

AAA_xxx_yyy = "true"

(There was a time many releases ago where this didn't, but it should work in
any release in the last few years).

For "or" you already have the answer above, basically do it with the same
value for both overrides:

AAA = "false"
AAA_xxx = "true"
AAA_yyy = "true"

> The similar situation for do_install_append(), etc.
>
> do_install_append_xxx() {
> }
>
> do_install_append_yyy() {
> }

Same thing - for and:

do_install_append_xxx_yyy() {
}

for or:

do_install_append_xxx() {
}

do_install_append_yyy() {
}

Note, we're appending here rather than setting as above, but otherwise setting
a function is pretty much the same in terms of operations as a variable - the
syntax is slightly different and immediate operations (such as +=) aren't
allowed, but the same rules apply for overrides and deferred operations such
as _append.

Cheers,
Paul

--

Paul Eggleton
Intel Open Source Technology Centre
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto