Re: [yocto] [meta-security][rocko][PATCH] clamav: Add missing clamav.service file to SRC_URI
Please ignore this patch, it gives an error as it is unable to
inherit multilib-alternatives.This class is part of our internal layer.
Regards,
Jagadeesh
On Tue, Mar 20, 2018 at 12:20 PM, Jagadeesh Krishnanjanappa <
jkrishnanjana...@mvista.com> wrote:
> This solves the below error when systemd is used as init manager,
> -- snip --
> ERROR: clamav-0.99.2-r0 do_package: SYSTEMD_SERVICE_clamav value
> clamav.service does not exist
> ERROR: clamav-0.99.2-r0 do_package: Function failed:
> systemd_populate_packages
> -- snip --
>
> Other issues:
> 1. Ship /lib/systemd/system/clamav-freshclam.service into ${PN}-freshclam
>package, to solve below warning:
> -- snip --
> [10240] WARNING: QA Issue: clamav: Files/directories were installed but
> not shipped in any package:
> /lib/systemd/system/clamav-freshclam.service
> -- snip --
>
> 2. Solve rpm conflict error in do_populate_sdk, when clamav and mlib-clamav
>are specified using IMAGE_INSTALL.
> -- snip --
> do_populate_sdk fails with below error:
> file /usr/bin/clamav-config conflicts between attempted installs of
> lib32-clamav-dev-0.99.2-r0.i586 and clamav-dev-0.99.2-r0.corei7_64
> -- snip --
>
> Signed-off-by: Jagadeesh Krishnanjanappa
> ---
> recipes-security/clamav/clamav_0.99.2.bb | 11 +--
> 1 file changed, 9 insertions(+), 2 deletions(-)
>
> diff --git a/recipes-security/clamav/clamav_0.99.2.bb
> b/recipes-security/clamav/clamav_0.99.2.bb
> index 5dfda8f..d7aa6d0 100644
> --- a/recipes-security/clamav/clamav_0.99.2.bb
> +++ b/recipes-security/clamav/clamav_0.99.2.bb
> @@ -14,6 +14,7 @@ SRC_URI = "git://github.com/vrtadmin/
> clamav-devel;branch=${PV} \
> file://clamd.conf \
> file://freshclam.conf \
> file://volatiles.03_clamav \
> +file://${BPN}.service \
> "
>
> SRC_URI[md5sum] = "61b51a04619aeafd965892a53f86d192"
> @@ -26,7 +27,7 @@ SO_VER = "7.1.1"
>
> EXTRANATIVEPATH += "chrpath-native"
>
> -inherit autotools-brokensep pkgconfig useradd systemd
> +inherit autotools-brokensep pkgconfig useradd systemd
> multilib-alternatives
>
> UID = "clamav"
> GID = "clamav"
> @@ -90,8 +91,13 @@ do_install_append() {
> install -m 0644 ${WORKDIR}/volatiles.03_clamav
> ${D}${sysconfdir}/default/volatiles/volatiles.03_clamav
> sed -i -e 's#${STAGING_DIR_HOST}##g' ${D}${libdir}/pkgconfig/
> libclamav.pc
> rm ${D}/${libdir}/libclamav.so
> +if ${@bb.utils.contains('DISTRO_FEATURES','systemd','true','
> false',d)};then
> + install -D -m 0644 ${WORKDIR}/clamav.service
> ${D}${systemd_unitdir}/system/clamav.service
> +fi
> }
>
> +MULTILIB_ALTERNATIVES_${PN}-dev = "${bindir}/clamav-config"
> +
> pkg_postinst_${PN} () {
> if [ -z "$D" ] && [ -e /etc/init.d/populate-volatile.sh ] ; then
> ${sysconfdir}/init.d/populate-volatile.sh update
> @@ -126,7 +132,8 @@ FILES_${PN}-freshclam = "${bindir}/freshclam \
> ${sysconfdir}/clamav ${sysconfdir}/default/volatiles
> \
> ${localstatedir}/lib/clamav \
> ${docdir}/${PN}-freshclam
> ${mandir}/man1/freshclam.* \
> -${mandir}/man5/freshclam.conf.*"
> +${mandir}/man5/freshclam.conf.* \
> +${systemd_unitdir}/system/
> clamav-freshclam.service"
>
> FILES_${PN}-dev = " ${bindir}/clamav-config ${libdir}/*.la \
> ${libdir}/pkgconfig/*.pc \
> --
> 2.7.4
>
>
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [OE-core] Yocto Project Status WW12’18
> On Mar 20, 2018, at 11:00 AM, Alexander Kanavin > wrote: > > On 03/20/2018 05:59 PM, Richard Purdie wrote: How long does a single run take, and why not run it every month? >>> Just a bit longer than a day, maybe 30 hours, if it needs to update >>> the >>> typical amount of 100-150 packages. I'll shift it to monthly then. >> Personally I'm leaning to every couple of weeks... > > My worry is that shorter AUH periods will lead to reminder fatigue. Also the > period between submitting the updates, and having them show up in master is > sometimes less than ideal, even when the freeze is not in effect. > I agree with both of you. I guess that makes me a transistor that can’t decide which path to choose :) For meta-perl and meta-python, I am striving to run once a week, but that isn’t intended to send email out to any maintainers, it is just for my own accounting. It gets very messy with in-flight patches, which I hope to fix by using git-pw to not include packages that already have an upgrade in review. It is also optimistic for me to personally fix the 20+ packages that need updates at any given moment. This is why I need run time testing to give me better confidence in auto-upgraded recipes. Working on it :) > Alex > -- > ___ > Openembedded-core mailing list > openembedded-c...@lists.openembedded.org > http://lists.openembedded.org/mailman/listinfo/openembedded-core -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [OE-core] Yocto Project Status WW12’18
On 03/20/2018 05:59 PM, Richard Purdie wrote: How long does a single run take, and why not run it every month? Just a bit longer than a day, maybe 30 hours, if it needs to update the typical amount of 100-150 packages. I'll shift it to monthly then. Personally I'm leaning to every couple of weeks... My worry is that shorter AUH periods will lead to reminder fatigue. Also the period between submitting the updates, and having them show up in master is sometimes less than ideal, even when the freeze is not in effect. Alex -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [OE-core] Yocto Project Status WW12’18
On Tue, 2018-03-20 at 13:26 +0200, Alexander Kanavin wrote: > On 03/20/2018 12:52 PM, Burton, Ross wrote: > > > > Which brings me to a question: what is a good schedule and > > cadence > > for AUH runs? Currently it's run on the 15th of every odd- > > numbered > > month (so January, March, and so on), but I thought of shifting > > it > > one month forward, so it doesn't land right in the middle of a > > feature freeze. Thoughts? > > > > > > How long does a single run take, and why not run it every month? > Just a bit longer than a day, maybe 30 hours, if it needs to update > the > typical amount of 100-150 packages. I'll shift it to monthly then. Personally I'm leaning to every couple of weeks... Cheers, Richard -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] meta-raspberrypi systemd rpi0-w bluetooth startup
FWIW: Dengke's email caused me to wonder why the RDEPENDS in bluez hadn't
triggered the inclusion of udev-rules-rpi in the first place. I now
suspect that when I tried to switch from 'rocko' to 'master', the steps I
took to force a rebuild were insufficient, and bluez5 was not recompiled
with the new patches, including the patch to increase the timeout. I'm not
able to check it at the moment, but will try to retrace my steps when I get
a chance.
John
On Tue, Mar 20, 2018 at 10:13 AM r10kindsofpeople <
r10kindsofpeo...@gmail.com> wrote:
> Thanks Dengke, I thought I tried using the line "After=dev-ttyAMA0.device"
> and referring to /dev/ttyAMA0 in the hciattach command and the
> brcm43438.service was still being triggered before the /dev/ttyAMA0 device
> was actually available on some boots, but I may have had something else
> wrong at that point, or I may be recalling incorrectly. If it works for
> you, great.
>
> It doesn't make sense to me that we'd need the udev-rules-rpi for bluez,
> but then refer to /dev/ttyAMA0 in the service. I thought the point of the
> 99-com.rules file created by udev-rules-rpi was to create a symbolic link
> equating /dev/ttyAMA0 and /dev/serial1 on the rpi0w.
>
> It's my impression that the move to use /dev/serial1 (as an alias for
> /dev/ttyAMA0) is an attempt to make software written for the Raspberry Pi
> more portable across all variants of the Pi, since some variants swap the
> role of /dev/ttyS0 and /dev/ttyAMA0 for the console or swap which one is
> available on the GPIO expansion. Or perhaps the goal was portablilty from
> Raspbian to Yocto and back. The steps I outlined retain that, and still
> seem to work reliably. I'm not entirely comfortable with relying on the
> udev script to trigger the service that runs hciattach, (and all of bluez
> dependent on that), but acknowledge that I don't know enough about systemd
> and udev to know "proper" from "improper".
>
> John
>
> On Mon, Mar 19, 2018 at 11:01 PM Dengke Du
> wrote:
>
>> Raspberry pi have two built-in UARTs, PL011 and mini UART
>>
>> by default: /dev/ttyS0 refers to the mini UART, /dev/ttyAMA0 refers to
>> the PL011
>>
>> https://www.raspberrypi.org/documentation/configuration/uart.md
>>
>> So I think the brcm43438 service should use the /dev/ttyAMA0.
>>
>> On 2018年03月20日 10:41, Dengke Du wrote:
>>
>> For rpi0-w bluetooth, before the commit:
>>
>>
>> https://github.com/agherzan/meta-raspberrypi/commit/6235b0a8543bcf6704d0fe0156ab2b847a4ea0bc#diff-70e4910388c3702c52118d7acf7556e7
>>
>> the brcm43438.service always failed, because it depends on
>> /dev/ttyAMA0,after that commit, the 'udev-rules-rpi' added to the RDEPENDS
>> for rpi0-w,we
>>
>> can check it here:
>>
>>
>> https://github.com/agherzan/meta-raspberrypi/commit/6235b0a8543bcf6704d0fe0156ab2b847a4ea0bc#diff-3b2568c620828b0ba653c1070041318aR52
>>
>> for service brcm43438, but I still use the /dev/ttyAMA0 in it, not
>> /dev/serial1(when I use /dev/serial1, the service failed), the service can
>> start everytime correctly.
>>
>> On 2018年03月19日 02:10, r10kindsofpeople wrote:
>>
>> Update: I suspect this is not the proper way to do this, but in case it
>> provides useful information toward a better solution...
>> 1) systemctl disable brcm43438.service
>> 2) modified 99-com.rules to include TAG+="systemd" and
>> ENV{SYSTEMD_WANTS}="device-brcm43438.service"
>> 3) cp /lib/systemd/system/brcm43438.service
>> /etc/systemd/system/device-brcm43438.service
>> 4) modified device-brcm43438.service to be as follows:
>> [Unit]
>> Description=Broadcom BCM43438 bluetooth HCI
>>
>> [Service]
>> Type=simple
>> ExecStart=/usr/bin/hciattach -n /dev/serial1 bcm43xx 921600 noflow -
>> Restart=on-failure
>>
>> note removal of Before, After, ConditionPath, Install sections and
>> addition of Restart=on-failure. This last was to cope with an intermittent
>> timeout in hciattach. Suppose I should have tried increasing the timeout
>> first.
>>
>> This seems to have gotten me to the point of it starting up at least 10
>> times successfully. Bottom line, in my opinion, is that brcm43438.service
>> is somehow running before the udev script can create the symbolic link for
>> /dev/serial1 -> /dev/ttyAMA0 despite the "After=dev-serial1.device"
>> clause.
>>
>> John
>>
>>
>> On Sat, Mar 17, 2018 at 12:32 PM r10kindsofpeople <
>> r10kindsofpeo...@gmail.com> wrote:
>>
>>> Background: I'm trying to bring up the pi zero w's bluetooth using
>>> systemd. Started with rocko and then moved to 'master' of meta-raspberry
>>> pi, sync'd about a week ago after noticing that there were some recent
>>> updates in this area.
>>>
>>> There was an initial problem with /dev/serial1 not showing up...I found
>>> udev-rules-rpi.bb, added it to my layer, and when it still didn't show
>>> up in my rootfs, I punted and installed it in /etc/udev/rules.d by hand and
>>> now /dev/serial1 shows up. Given time, I can probably fix the recipe on my
>>> own, so moving on.
>>>
>>> But brcm43438.se
Re: [yocto] meta-raspberrypi systemd rpi0-w bluetooth startup
Thanks Dengke, I thought I tried using the line "After=dev-ttyAMA0.device"
and referring to /dev/ttyAMA0 in the hciattach command and the
brcm43438.service was still being triggered before the /dev/ttyAMA0 device
was actually available on some boots, but I may have had something else
wrong at that point, or I may be recalling incorrectly. If it works for
you, great.
It doesn't make sense to me that we'd need the udev-rules-rpi for bluez,
but then refer to /dev/ttyAMA0 in the service. I thought the point of the
99-com.rules file created by udev-rules-rpi was to create a symbolic link
equating /dev/ttyAMA0 and /dev/serial1 on the rpi0w.
It's my impression that the move to use /dev/serial1 (as an alias for
/dev/ttyAMA0) is an attempt to make software written for the Raspberry Pi
more portable across all variants of the Pi, since some variants swap the
role of /dev/ttyS0 and /dev/ttyAMA0 for the console or swap which one is
available on the GPIO expansion. Or perhaps the goal was portablilty from
Raspbian to Yocto and back. The steps I outlined retain that, and still
seem to work reliably. I'm not entirely comfortable with relying on the
udev script to trigger the service that runs hciattach, (and all of bluez
dependent on that), but acknowledge that I don't know enough about systemd
and udev to know "proper" from "improper".
John
On Mon, Mar 19, 2018 at 11:01 PM Dengke Du wrote:
> Raspberry pi have two built-in UARTs, PL011 and mini UART
>
> by default: /dev/ttyS0 refers to the mini UART, /dev/ttyAMA0 refers to the
> PL011
>
> https://www.raspberrypi.org/documentation/configuration/uart.md
>
> So I think the brcm43438 service should use the /dev/ttyAMA0.
>
> On 2018年03月20日 10:41, Dengke Du wrote:
>
> For rpi0-w bluetooth, before the commit:
>
>
> https://github.com/agherzan/meta-raspberrypi/commit/6235b0a8543bcf6704d0fe0156ab2b847a4ea0bc#diff-70e4910388c3702c52118d7acf7556e7
>
> the brcm43438.service always failed, because it depends on
> /dev/ttyAMA0,after that commit, the 'udev-rules-rpi' added to the RDEPENDS
> for rpi0-w,we
>
> can check it here:
>
>
> https://github.com/agherzan/meta-raspberrypi/commit/6235b0a8543bcf6704d0fe0156ab2b847a4ea0bc#diff-3b2568c620828b0ba653c1070041318aR52
>
> for service brcm43438, but I still use the /dev/ttyAMA0 in it, not
> /dev/serial1(when I use /dev/serial1, the service failed), the service can
> start everytime correctly.
>
> On 2018年03月19日 02:10, r10kindsofpeople wrote:
>
> Update: I suspect this is not the proper way to do this, but in case it
> provides useful information toward a better solution...
> 1) systemctl disable brcm43438.service
> 2) modified 99-com.rules to include TAG+="systemd" and
> ENV{SYSTEMD_WANTS}="device-brcm43438.service"
> 3) cp /lib/systemd/system/brcm43438.service
> /etc/systemd/system/device-brcm43438.service
> 4) modified device-brcm43438.service to be as follows:
> [Unit]
> Description=Broadcom BCM43438 bluetooth HCI
>
> [Service]
> Type=simple
> ExecStart=/usr/bin/hciattach -n /dev/serial1 bcm43xx 921600 noflow -
> Restart=on-failure
>
> note removal of Before, After, ConditionPath, Install sections and
> addition of Restart=on-failure. This last was to cope with an intermittent
> timeout in hciattach. Suppose I should have tried increasing the timeout
> first.
>
> This seems to have gotten me to the point of it starting up at least 10
> times successfully. Bottom line, in my opinion, is that brcm43438.service
> is somehow running before the udev script can create the symbolic link for
> /dev/serial1 -> /dev/ttyAMA0 despite the "After=dev-serial1.device"
> clause.
>
> John
>
>
> On Sat, Mar 17, 2018 at 12:32 PM r10kindsofpeople <
> r10kindsofpeo...@gmail.com> wrote:
>
>> Background: I'm trying to bring up the pi zero w's bluetooth using
>> systemd. Started with rocko and then moved to 'master' of meta-raspberry
>> pi, sync'd about a week ago after noticing that there were some recent
>> updates in this area.
>>
>> There was an initial problem with /dev/serial1 not showing up...I found
>> udev-rules-rpi.bb, added it to my layer, and when it still didn't show
>> up in my rootfs, I punted and installed it in /etc/udev/rules.d by hand and
>> now /dev/serial1 shows up. Given time, I can probably fix the recipe on my
>> own, so moving on.
>>
>> But brcm43438.service still fails on boot. Despite having
>> "After=dev-serial1.device" in the service Unit section, it fails with:
>>
>> Mar 17 16:21:13 raspberrypi0-wifi systemd[1]: Started Broadcom BCM43438
>> bluetooth HCI.
>> Mar 17 16:21:14 raspberrypi0-wifi hciattach[105]: Can't open serial port:
>> No such file or directory
>> Mar 17 16:21:14 raspberrypi0-wifi hciattach[105]: Can't initialize
>> device: No such file or directory
>> Mar 17 16:21:14 raspberrypi0-wifi systemd[1]: [[0;1;39mbrcm43438.service:
>> Main process exited, code=exited, status=1/FAILURE[[0m
>> Mar 17 16:21:14 raspberrypi0-wifi systemd[1]: [[0;1;39mbrcm43438.service:
>> Unit entered failed state.[[0m
>>
Re: [yocto] use of variables in wic files
On Tue, Mar 20, 2018 at 1:24 PM, Andrea Galbusera wrote: > Hi, > > Is there any way to reference bitbake variable within the wic file > syntax? Got to this question after a wic file of mine recently broke > due to a u-boot artifact changing its name after an upstream update of > the u-boot recipe. The wic had the artifact's name hardcoded as a > parameter to the rawcopy plugin. Could I have been referencing the > u-boot artifact via UBOOT_BINARY variable instead? Use a wic.in file? http://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/meta/classes/image_types_wic.bbclass#n83 There's an example in the Intel RefKit: https://github.com/intel/intel-iot-refkit/blob/master/meta-refkit-core/wic/refkit-directdisk.wks.in -- Alex Kiernan -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] use of variables in wic files
Hi, Is there any way to reference bitbake variable within the wic file syntax? Got to this question after a wic file of mine recently broke due to a u-boot artifact changing its name after an upstream update of the u-boot recipe. The wic had the artifact's name hardcoded as a parameter to the rawcopy plugin. Could I have been referencing the u-boot artifact via UBOOT_BINARY variable instead? -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [OE-core] Yocto Project Status WW12’18
On 03/20/2018 12:52 PM, Burton, Ross wrote: Which brings me to a question: what is a good schedule and cadence for AUH runs? Currently it's run on the 15th of every odd-numbered month (so January, March, and so on), but I thought of shifting it one month forward, so it doesn't land right in the middle of a feature freeze. Thoughts? How long does a single run take, and why not run it every month? Just a bit longer than a day, maybe 30 hours, if it needs to update the typical amount of 100-150 packages. I'll shift it to monthly then. Alex -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [OE-core] [oe-core] system lock down in middle of build
Please remember to reply to the list, not the person to who sent the mail. On 20 March 2018 at 04:10, Rajath C S wrote: > You are right, it's not actually logging out but a fast reboot occurs. > > Thanks for the info, I'll upgrade my hardware. > This isn't an "upgrade my hardware" issue but a "fix the problem" issue. Run memtest86 to see if you have bad RAM. Watch the system temperature to see if its a thermal shutdown. Ross -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [OE-core] Yocto Project Status WW12’18
On 20 March 2018 at 10:07, Alexander Kanavin < alexander.kana...@linux.intel.com> wrote: > On 03/19/2018 10:07 PM, Burton, Ross wrote: > >> Do we have a place identified for new changes (2.6) while 2.5 >> stabilizes. >> >> >> A formal place, no. I tend to queue stuff in a branch if master isn't >> taking all of my energy, otherwise the patches will sit on the list until >> 2.5 releases. Typically master and sumo branches won't diverge until >> post-release. >> > > Which brings me to a question: what is a good schedule and cadence for AUH > runs? Currently it's run on the 15th of every odd-numbered month (so > January, March, and so on), but I thought of shifting it one month forward, > so it doesn't land right in the middle of a feature freeze. Thoughts? > How long does a single run take, and why not run it every month? Ross -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [OE-core] Yocto Project Status WW12’18
On 03/19/2018 10:07 PM, Burton, Ross wrote: Do we have a place identified for new changes (2.6) while 2.5 stabilizes. A formal place, no. I tend to queue stuff in a branch if master isn't taking all of my energy, otherwise the patches will sit on the list until 2.5 releases. Typically master and sumo branches won't diverge until post-release. Which brings me to a question: what is a good schedule and cadence for AUH runs? Currently it's run on the 15th of every odd-numbered month (so January, March, and so on), but I thought of shifting it one month forward, so it doesn't land right in the middle of a feature freeze. Thoughts? Alex -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
