Re: [yocto] unpacking deb packages
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
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
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
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
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 > > Whereas, my libcrypt.so.1.0.0 says: > > >Version definitions: > >1 0x01 0x0746be50 libcrypto.so.1.0.0 > >2 0x00 0x06a2b2e4 OPENSSL_1.0.2d > >3 0x00 0x06a2b2e7 OPENSSL_1.0.2g > > OPENSSL
[yocto] [PATCH] package.bbclass: Changed PACKAGESPLITFUNCS execution order
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
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
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
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?
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