Re: [yocto] [Yocto] RPI WiFi not loading module
Hi, Thanks for the reply. I have looked in to some of the issues on meta-raspberrypi and found some good information but nothing to fix my issue, i will post an issue there as well for the rpi specific problem. The question i have regarding Yocto is about KERNEL_MODULE_AUTOLOAD, i get the module added to /etc/modules-load.d/ but cant understand what service/script that is responsible for loading it. / Jonas Den fre 24 maj 2019 kl 02:03 skrev Khem Raj : > > > On 5/23/19 2:14 AM, Jonas Andersson wrote: > > Hi > > > > I have problem to get my WiFi working on boot on Raspberry Pi 3. > > > > The problem is that wlan0 interface not showing up, if I manually > > run modprobe brcmfmac it works. > > > > To try to "force" the load of brcmfmac i added it to > > KERNEL_MODULE_AUTOLOAD and that generated an file > > in /etc/modules-load.d/ -> brcmfmac.conf but it is still not loaded. > > > > I use systemd an to my understanding systemd-modules-load.service is > > handling module auto load, but that file is missing and I cant see how > > to include it in my build. > > > > Building thud version and I have added the following to my image recipe: > > > > DISTRO_FEATURES_append = " wifi" > > > > IMAGE_INSTALL_append = " iw wpa-supplicant packagegroup-base > > module-init-tools" > > > > IMAGE_INSTALL_append = "\ > > linux-firmware-rpidistro-bcm43430 \ > > linux-firmware-rpidistro-bcm43455 \ > > bluez-firmware-rpidistro-bcm43430a1-hcd \ > > bluez-firmware-rpidistro-bcm4345c0-hcd \ > > " > > Then i have symlinked wpa-supplicant service to load wpa-supplicant.conf > > file and that work when I manually loads the module. > > > > I wonder if something like this will help you > https://github.com/YoeDistro/meta-yoe/tree/master/recipes-core/systemd > > > Best regards > > Jonas > > > -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [meta-mono][PATCH] mono-5.xx: fix an issue with too long paths in doltlibtool
Ping?
Alex
On Mon, 13 May 2019 at 18:25, Alexander Kanavin wrote:
>
> When build directory is deeply nested, the shebang limit of 127
> characters is hit, which leads to doltlibtool failing to execute.
>
> Signed-off-by: Alexander Kanavin
> ---
> recipes-mono/mono/mono-5.xx.inc | 4
> 1 file changed, 4 insertions(+)
>
> diff --git a/recipes-mono/mono/mono-5.xx.inc b/recipes-mono/mono/mono-5.xx.inc
> index c36374c..dec2475 100644
> --- a/recipes-mono/mono/mono-5.xx.inc
> +++ b/recipes-mono/mono/mono-5.xx.inc
> @@ -102,3 +102,7 @@ RDEPENDS_${PN} =+ "bash"
>
> # Workaround for observed race in `make install`
> PARALLEL_MAKEINST=""
> +
> +# Otherwise the full path to bash is written to the first line of
> doltlibtool script
> +# which causes build failures with deeply nested build directories
> +CACHED_CONFIGUREVARS += "ac_cv_path_DOLT_BASH='/usr/bin/env bash'"
> --
> 2.17.1
>
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[yocto] final image size got increased when migrated from krogoth to Sumo
Hi All, I have migrated Yocto poky version from Krogoth to Sumo, after building the final image, i observed that the size of image got increased by more than 70Mb. I have not added any new packages. Any suggestions, how can I reduce the image size now. Thanks in Advance. Thanks, Praveen -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] final image size got increased when migrated from krogoth to Sumo
On Mon, May 27, 2019 at 1:29 PM praveen vattipalli wrote: > > Hi All, > > I have migrated Yocto poky version from Krogoth to Sumo, after building the > final image, i observed that the size of image got increased by more than > 70Mb. I have not added any new packages. > Any suggestions, how can I reduce the image size now. you should most likely start looking at buildhistory data which will give you the list of installed packages and their size. that should give you hints about what has changed. > > Thanks in Advance. > > Thanks, > Praveen > -- > ___ > 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] final image size got increased when migrated from krogoth to Sumo
Thanks Nicolas, i will try this. On Mon, May 27, 2019 at 5:10 PM Nicolas Dechesne < nicolas.deche...@linaro.org> wrote: > On Mon, May 27, 2019 at 1:29 PM praveen vattipalli > wrote: > > > > Hi All, > > > > I have migrated Yocto poky version from Krogoth to Sumo, after building > the final image, i observed that the size of image got increased by more > than 70Mb. I have not added any new packages. > > Any suggestions, how can I reduce the image size now. > > you should most likely start looking at buildhistory data which will > give you the list of installed packages and their size. that should > give you hints about what has changed. > > > > > Thanks in Advance. > > > > Thanks, > > Praveen > > -- > > ___ > > yocto mailing list > > yocto@yoctoproject.org > > https://lists.yoctoproject.org/listinfo/yocto > -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] [meta-swupdate] build fails under thud
Hello I want to create an update mechanism for our embedded system. I chose swupdate because it is very well documented and seems flexible. When trying to build swupdate-image it fails with several undefined references, just a few as example: """ /opt/thudPoky/build/tmp/work/corei7-64-poky-linux/swupdate/2018.11-r0/recipe-sysroot-native/usr/bin/x86_64-poky-linux/../../libexec/x86_64-poky-linux/gcc/x86_64-poky-linux/8.2.0/ld: bootloader/lib.a(uboot.o): in function `bootloader_env_set': | uboot.c:(.text.bootloader_env_set+0x40): undefined reference to `fw_env_open' | /opt/thudPoky/build/tmp/work/corei7-64-poky-linux/swupdate/2018.11-r0/recipe-sysroot-native/usr/bin/x86_64-poky-linux/../../libexec/x86_64-poky-linux/gcc/x86_64-poky-linux/8.2.0/ld: uboot.c:(.text.bootloader_env_set+0xf8): undefined reference to `fw_env_write' """ I see lots of "uboot" in the trace, but to my understanding swupdate should also work with grub which I enabled using: EFI_PROVIDER = "grub-efi" (First tried to use PREFERRED_PROVIDER_virtual/bootloader, but this doesn't work with EFI booting) When I want to enable "uboot" this way, bitbake tells me there is no uboot. I know there is also the option of writing my own init scripts but this would be just reinventing the wheel (given there is an swupdate available) and probably more error-prone than a grown update tool. Thus I would like to get swupdate to work. Any ideas ? Best regards Moritz -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [meta-swupdate] build fails under thud
Hi Moritz! You need to configure swupdate kind of like the linux kernel with menuconfig: bitbake -c menuconfig swupdate do not forget to copy your config then into an bbappend to swupdate (defconfig). Hope that helps, Regards, Matthias On 5/27/19 3:26 PM, Moritz Porst wrote: Hello I want to create an update mechanism for our embedded system. I chose swupdate because it is very well documented and seems flexible. When trying to build swupdate-image it fails with several undefined references, just a few as example: """ /opt/thudPoky/build/tmp/work/corei7-64-poky-linux/swupdate/2018.11-r0/recipe-sysroot-native/usr/bin/x86_64-poky-linux/../../libexec/x86_64-poky-linux/gcc/x86_64-poky-linux/8.2.0/ld: bootloader/lib.a(uboot.o): in function `bootloader_env_set': | uboot.c:(.text.bootloader_env_set+0x40): undefined reference to `fw_env_open' | /opt/thudPoky/build/tmp/work/corei7-64-poky-linux/swupdate/2018.11-r0/recipe-sysroot-native/usr/bin/x86_64-poky-linux/../../libexec/x86_64-poky-linux/gcc/x86_64-poky-linux/8.2.0/ld: uboot.c:(.text.bootloader_env_set+0xf8): undefined reference to `fw_env_write' """ I see lots of "uboot" in the trace, but to my understanding swupdate should also work with grub which I enabled using: EFI_PROVIDER = "grub-efi" (First tried to use PREFERRED_PROVIDER_virtual/bootloader, but this doesn't work with EFI booting) When I want to enable "uboot" this way, bitbake tells me there is no uboot. I know there is also the option of writing my own init scripts but this would be just reinventing the wheel (given there is an swupdate available) and probably more error-prone than a grown update tool. Thus I would like to get swupdate to work. Any ideas ? Best regards Moritz -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] meta-sunxi maintained?
Hello, I'm just curious if meta-sunxi is still maintained? I was contributed to layer back while and when look now thud branch is un-compilable (dri2proto not replaced) and warrior branch not created yet. There is 14 issues + 6 pending pull requests. Added maintainers also in CC. I think it would be good to have sunxi properly maintained as boards with sunxi processors are popular. I can give a hand as co-maintainer if necessary. Thanks a lot. BR, marek -- as simple and primitive as possible - Marek Belisko - OPEN-NANDRA Freelance Developer Ruska Nova Ves 219 | Presov, 08005 Slovak Republic Tel: +421 915 052 184 skype: marekwhite twitter: #opennandra web: http://open-nandra.com -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [meta-swupdate] build fails under thud
Hi Matthias Thank you very much for your help, this is not mentioned in the official repository. I tried what you said. It enables me (even without .bbappend) to build the swupdate-image. Now for the defconfig. I did it with a .bbappend the way the yocto documentation suggests (FILESEXTRAPATHS and SRC_URI) but which recipe do I need to append to? I thought just choose swupdate_git.bb, then swupdate_2018.11.bb. I always receive the following rootfs file: swupdate-image-ccns5.ext4.gz.u-boot (Clearly still uboot, I don't know why it managed to build though) Also I get the following warning on invoking bitbake for swupdate-image: WARNING: /opt/thudPoky/meta-swupdate/recipes-support/swupdate/swupdate_2018.11.bb.do_compile is tainted from a forced run Finally I always end up with microcode.cpio in my /boot directory which comes from meta-intel. I guess swupdate would replace the initrd/initramfs ? I put the following lines in my image description: INITRAMFS_IMAGE = "swupdate-image-ccns5" INITRAMFS_IMAGE_BUNDLE = "1" Shouldn't they cause the swupdate-image to be bundled into the kernel, thus that if I build my image that I end up with the swupdate initramfs in my /boot directory ? Sorry for all the questions and thanks in advance ! Best regards Moritz Gesendet: Montag, 27. Mai 2019 um 15:31 Uhr Von: "Matthias Schoepfer" An: yocto@yoctoproject.org Betreff: Re: [yocto] [meta-swupdate] build fails under thud Hi Moritz! You need to configure swupdate kind of like the linux kernel with menuconfig: bitbake -c menuconfig swupdate do not forget to copy your config then into an bbappend to swupdate (defconfig). Hope that helps, Regards, Matthias On 5/27/19 3:26 PM, Moritz Porst wrote: Hello I want to create an update mechanism for our embedded system. I chose swupdate because it is very well documented and seems flexible. When trying to build swupdate-image it fails with several undefined references, just a few as example: """ /opt/thudPoky/build/tmp/work/corei7-64-poky-linux/swupdate/2018.11-r0/recipe-sysroot-native/usr/bin/x86_64-poky-linux/../../libexec/x86_64-poky-linux/gcc/x86_64-poky-linux/8.2.0/ld: bootloader/lib.a(uboot.o): in function `bootloader_env_set': | uboot.c:(.text.bootloader_env_set+0x40): undefined reference to `fw_env_open' | /opt/thudPoky/build/tmp/work/corei7-64-poky-linux/swupdate/2018.11-r0/recipe-sysroot-native/usr/bin/x86_64-poky-linux/../../libexec/x86_64-poky-linux/gcc/x86_64-poky-linux/8.2.0/ld: uboot.c:(.text.bootloader_env_set+0xf8): undefined reference to `fw_env_write' """ I see lots of "uboot" in the trace, but to my understanding swupdate should also work with grub which I enabled using: EFI_PROVIDER = "grub-efi" (First tried to use PREFERRED_PROVIDER_virtual/bootloader, but this doesn't work with EFI booting) When I want to enable "uboot" this way, bitbake tells me there is no uboot. I know there is also the option of writing my own init scripts but this would be just reinventing the wheel (given there is an swupdate available) and probably more error-prone than a grown update tool. Thus I would like to get swupdate to work. Any ideas ? Best regards Moritz -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] Customize syslinux root=???
Hi all. I'm working with Thud and Ibase ib550f board (AMD Geode arch). I make the BSP for ib550f an I build the core-image-minimal image. Than with wic I try to write the final directdisk file. The ib550f run from a CompactFlash. The CF is mapped into the device /dev/hdb (the boot partition is /dev/hb1, the root partition /dev/hdb2). I read many docs of Yocto but I don't find what I need. The syslinux is always the bootloader choosen by wic: I'd like to use other booloader like grub. And syslonux get /dev/sda2 has root parameter appended to syslinux. I try to set SYSLINUX_ROOT := "root=/dev/hdb2" (in local.conf and in core-image-minimal.bbappend), but my setup is ignored How can I customize syslinux to change SYSLINUX_ROOT=/dev/hdb2 Thanks all. Mauro -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [meta-swupdate] build fails under thud
Hi Moritz, I will try to answer what I can inline: On 5/27/19 5:05 PM, Moritz Porst wrote: Hi Matthias Thank you very much for your help, this is not mentioned in the official repository. I tried what you said. It enables me (even without .bbappend) to build the swupdate-image. Now for the defconfig. I did it with a .bbappend the way the yocto documentation suggests (FILESEXTRAPATHS and SRC_URI) but which recipe do I need to append to? I thought just choose swupdate_git.bb, then swupdate_2018.11.bb. I always receive the following rootfs file: you can either bbappend the _2018.11 or make a swupdate_%.bbappend, that is then valid for both _git and _2018.11 if you happen to use the _git version. swupdate-image-ccns5.ext4.gz.u-boot (Clearly still uboot, I don't know why it managed to build though) Also I get the following warning on invoking bitbake for swupdate-image: WARNING: /opt/thudPoky/meta-swupdate/recipes-support/swupdate/swupdate_2018.11.bb.do_compile is tainted from a forced run This is because you bitbake -c menuconfig swupdate. If you clean the build (bitbake -c cleansstate swupdate), this should disappear. Then you can check, if your bbappend gets picked up correctly. Finally I always end up with microcode.cpio in my /boot directory which comes from meta-intel. I guess swupdate would replace the initrd/initramfs ? I put the following lines in my image description: INITRAMFS_IMAGE = "swupdate-image-ccns5" INITRAMFS_IMAGE_BUNDLE = "1" Shouldn't they cause the swupdate-image to be bundled into the kernel, thus that if I build my image that I end up with the swupdate initramfs in my /boot directory ? Errr you want to *add* swupdate to an image recipe. It is not an image by itself. Well, I guess, there is a rescue image within swupdate, but that is a different story and I have no experience with it. There are ways to add packages to an image, for example through IMAGE_INSTALL_append = " swupdate " in local.conf https://www.yoctoproject.org/docs/2.7/mega-manual/mega-manual.html#usingpoky-extend-customimage-localconf Sorry for all the questions and thanks in advance ! Best regards Moritz *Gesendet:* Montag, 27. Mai 2019 um 15:31 Uhr *Von:* "Matthias Schoepfer" *An:* yocto@yoctoproject.org *Betreff:* Re: [yocto] [meta-swupdate] build fails under thud Hi Moritz! You need to configure swupdate kind of like the linux kernel with menuconfig: bitbake -c menuconfig swupdate do not forget to copy your config then into an bbappend to swupdate (defconfig). Hope that helps, Regards, Matthias On 5/27/19 3:26 PM, Moritz Porst wrote: Hello I want to create an update mechanism for our embedded system. I chose swupdate because it is very well documented and seems flexible. When trying to build swupdate-image it fails with several undefined references, just a few as example: """ /opt/thudPoky/build/tmp/work/corei7-64-poky-linux/swupdate/2018.11-r0/recipe-sysroot-native/usr/bin/x86_64-poky-linux/../../libexec/x86_64-poky-linux/gcc/x86_64-poky-linux/8.2.0/ld: bootloader/lib.a(uboot.o): in function `bootloader_env_set': | uboot.c:(.text.bootloader_env_set+0x40): undefined reference to `fw_env_open' | /opt/thudPoky/build/tmp/work/corei7-64-poky-linux/swupdate/2018.11-r0/recipe-sysroot-native/usr/bin/x86_64-poky-linux/../../libexec/x86_64-poky-linux/gcc/x86_64-poky-linux/8.2.0/ld: uboot.c:(.text.bootloader_env_set+0xf8): undefined reference to `fw_env_write' """ I see lots of "uboot" in the trace, but to my understanding swupdate should also work with grub which I enabled using: EFI_PROVIDER = "grub-efi" (First tried to use PREFERRED_PROVIDER_virtual/bootloader, but this doesn't work with EFI booting) When I want to enable "uboot" this way, bitbake tells me there is no uboot. I know there is also the option of writing my own init scripts but this would be just reinventing the wheel (given there is an swupdate available) and probably more error-prone than a grown update tool. Thus I would like to get swupdate to work. Any ideas ? Best regards Moritz -- ___ 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] meta-sunxi maintained?
Hi Enrico, On Mon, May 27, 2019 at 5:44 PM Enrico wrote: > > Hi, > > i try to keep it maintained, but now i just have a lime2 for testing > on real hardware, and i don't have the resources to do test builds for > all the supported boards. > Your help would be welcome, i can't check right now if i have the > rights to add you as co-maintainer, anyway i will add you. Thanks I have few sunxi based boards so can do tests also on my setup. Pls ping me when you will add me. Thanks. > > Thanks for the help! > > Enrico Marek > > On Mon, May 27, 2019 at 4:50 PM Belisko Marek wrote: > > > > Hello, > > > > I'm just curious if meta-sunxi is still maintained? I was contributed > > to layer back while and when look now thud branch is un-compilable > > (dri2proto not replaced) and warrior branch not created yet. There is > > 14 issues + 6 pending pull requests. Added maintainers also in CC. I > > think it would be good to have sunxi properly maintained as boards > > with sunxi processors are popular. I can give a hand as co-maintainer > > if necessary. Thanks a lot. > > > > BR, > > > > marek > > > > -- > > as simple and primitive as possible > > - > > Marek Belisko - OPEN-NANDRA > > Freelance Developer > > > > Ruska Nova Ves 219 | Presov, 08005 Slovak Republic > > Tel: +421 915 052 184 > > skype: marekwhite > > twitter: #opennandra > > web: http://open-nandra.com -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] gstreamer1.0-plugins-base meta-sunxi issue with custom virtual/egl or virtual/libgles2 on thud
Hi,
I'm trying to compile image using libnice which have dependency on
gstreamer. Everything went fine but I get QA issues for plugins-base
like:
ERROR: gstreamer1.0-plugins-base-1.14.4-r0 do_package_qa: QA Issue:
/usr/lib/libgstgl-1.0.so.0.1404.0 contained in package libgstgl-1.0
requires libGLESv2.so, but no providers found in
RDEPENDS_libgstgl-1.0? [file-rdeps]
ERROR: gstreamer1.0-plugins-base-1.14.4-r0 do_package_qa: QA Issue:
/usr/lib/libgstgl-1.0.so.0.1404.0 contained in package libgstgl-1.0
requires libEGL.so, but no providers found in RDEPENDS_libgstgl-1.0?
[file-rdeps]
ERROR: gstreamer1.0-plugins-base-1.14.4-r0 do_package_qa: QA Issue:
/usr/lib/gstreamer-1.0/libgstopengl.so contained in package
gstreamer1.0-plugins-base-opengl requires libGLESv2.so, but no
providers found in RDEPENDS_gstreamer1.0-plugins-base-opengl?
[file-rdeps]
ERROR: gstreamer1.0-plugins-base-1.14.4-r0 do_package_qa: QA Issue:
/usr/lib/gstreamer-1.0/libgstopengl.so contained in package
gstreamer1.0-plugins-base-opengl requires libEGL.so, but no providers
found in RDEPENDS_gstreamer1.0-plugins-base-opengl? [file-rdeps]
ERROR: gstreamer1.0-plugins-base-1.14.4-r0 do_package_qa: QA run found
fatal errors. Please consider fixing them.
ERROR: gstreamer1.0-plugins-base-1.14.4-r0 do_package_qa: Function
failed: do_package_qa
meta-sunxi is using custom recipe which provide virtual/egl
virtual/libgles2 see:
https://github.com/linux-sunxi/meta-sunxi/blob/master/recipes-graphics/libgles/sunxi-mali_git.bb
also in configuration there is:
PREFERRED_PROVIDER_virtual/mesa ?= "mesa-gl"
PREFERRED_PROVIDER_virtual/libgl ?= "mesa-gl"
PREFERRED_PROVIDER_virtual/libgles1 ?= "sunxi-mali"
PREFERRED_PROVIDER_virtual/libgles2 ?= "sunxi-mali"
PREFERRED_PROVIDER_virtual/egl ?= "sunxi-mali"
XSERVER += "sunxi-mali \
sunxi-mali-dev"
MACHINE_ESSENTIAL_EXTRA_RRECOMMENDS += "\
kernel-module-mali \
kernel-module-mali-drm \
"
which is fine. I was able to workaround this issue by adding bbappend
for plugins base with content:
RDEPENDS_libgstgl-1.0 += "sunxi-mali"
RDEPENDS_${PN}-opengl += "sunxi-mali"
and add RPROVIDES_${PN} = "libGLESv1_CM.so libGLESv2.so libEGL.so" to
sunxi-mali.bb recipe.
Above workaround is not nice because if someone update
PREFERRED_PROVIDER then gstreamer will be broken. Any ideas how to fix
properly this QA issue? Thanks.
BR,
marek
--
as simple and primitive as possible
-
Marek Belisko - OPEN-NANDRA
Freelance Developer
Ruska Nova Ves 219 | Presov, 08005 Slovak Republic
Tel: +421 915 052 184
skype: marekwhite
twitter: #opennandra
web: http://open-nandra.com
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [patchtest-oe][PATCH] test_metadata_src_uri: new unittest detecting added patch files without modifying SRC_URI
ping
On 4/29/19 2:10 PM, Changqing Li wrote:
ping
On 3/5/19 5:59 PM, changqing...@windriver.com wrote:
From: Changqing Li
Adds new unittest detecting when a patch file is added but no
corresponding
change to the SRC_URI is done.
This patch is from , get from commit
49201c19cfe4cadd127b112d2858d5b28db49c20, this commit is reverted by
commit
6108d97f83b211f9eb245f339a412debd0ec5db4.
The added test case is ok, reason of series 9949 patchtest failed is:
recipe weston have REQUIRED_DISTRO_FEATURES, so parse recipe skipped,
cause self.modified is none, actually .bb is mofified, so make the
testcase failed.
during patchtest, we don't really need DISTRO_FEATURES, so fix the
problem
by set REQUIRED_DISTRO_FEATURES to "" in repo patchtest, meantime,
add this
testcase back.
[Yocto #13005]
Signed-off-by: Changqing Li
---
tests/test_metadata_src_uri.py | 25 +
1 file changed, 25 insertions(+)
diff --git a/tests/test_metadata_src_uri.py
b/tests/test_metadata_src_uri.py
index a4c5caa..f684ced 100644
--- a/tests/test_metadata_src_uri.py
+++ b/tests/test_metadata_src_uri.py
@@ -85,3 +85,28 @@ class SrcUri(base.Metadata):
'Amend the patch containing the
software patch file removal',
data=[('Patch', f) for f in
not_removed])
+ def test_src_uri_path_not_updated(self):
+ new_patches = set()
+ for patch in self.patchset:
+ if patch.is_added_file and patch.path.endswith('.patch'):
+ new_patches.add(os.path.basename(patch.path))
+
+ if not new_patches:
+ self.skip('No new patches added, skipping test')
+
+ if not self.modified:
+ self.fail('New patch path missing in SRC_URI',
+ "Add the patch path to the recipe's SRC_URI",
+ data=[('New patch(es)',
'\n'.join(new_patches))])
+
+ for pn in self.modified:
+ rd = self.tinfoil.parse_recipe(pn)
+
+ patchtestdata.PatchTestDataStore['%s-%s-%s' %
(self.shortid(), self.metadata, pn)] = rd.getVar(self.metadata)
+ test_src_uri =
patchtestdata.PatchTestDataStore['%s-%s-%s' % (self.shortid(),
self.metadata, pn)].split()
+ test_files = set([os.path.basename(patch) for patch
in test_src_uri if patch.startswith('file://')])
+
+ if not test_files.issuperset(new_patches):
+ self.fail('New patch path missing in SRC_URI',
+ "Add the patch path in the recipe's SRC_URI",
+ data=[('New patch(es)', p) for p in
new_patches.difference(test_files)])
--
BRs
Sandy(Li Changqing)
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [update-rc.d][PATCH V3] update-rc.d: support enable/disable options
ping
On 4/30/19 2:56 PM, changqing...@windriver.com wrote:
From: Changqing Li
Add support of enable/disable options, refer
https://manpages.debian.org/wheezy/sysv-rc/update-rc.d.8.en.html
With support of these options, the usr can never change an existing
configuration even after upgrading a package. The program will only
install links if none are present, otherwise, it will keep
the previous configuration.
preinst in update-rc.d.bbclass will delete all the links under
rcrunlevel.d, this behavior now conflicts with enable/disable
options. so remove preinst from the update-rc.d.bbclass
[Yocto 12955]
Signed-off-by: Changqing Li
---
update-rc.d | 81 +
1 file changed, 81 insertions(+)
diff --git a/update-rc.d b/update-rc.d
index e07cf85..a7fb7bc 100644
--- a/update-rc.d
+++ b/update-rc.d
@@ -27,6 +27,7 @@ usage()
usage: update-rc.d [-n] [-f] [-r ] remove
update-rc.d [-n] [-r ] [-s] defaults [NN | sNN kNN]
update-rc.d [-n] [-r ] [-s] start|stop NN runlvl
[runlvl] [...] .
+ update-rc.d [-n] [-r ] [-s] enable|disable [S|2|3|4|5]
-n: not really
-f: force
-v: verbose
@@ -101,6 +102,53 @@ makelinks()
done
}
+# function to disable/enable init script link of one run level
+# $1 should be K/S, means to disable/enable
+# $2 means which run level to disable/enable
+renamelink()
+{
+ local oldstartstop newstartstop lev oldnn newnn
+ if [ "x$1" = "xS" ]; then
+ oldstartstop="K"
+ newstartstop="S"
+ else
+ oldstartstop="S"
+ newstartstop="K"
+ fi
+
+ lev=$2
+ # modifies existing runlevel links for the script /etc/init.d/name by
renaming start links to stop link
+# or stop link to start link with a sequence number equal to the
difference of 100 minus the original sequence number.
+ if ls ${etcd}${lev}.d/${oldstartstop}*${bn} >/dev/null 2>&1; then
+ oldnn=`basename ${etcd}${lev}.d/${oldstartstop}*${bn}|cut -c2-3`
+ newnn=$[100-$oldnn]
+ [ $verbose -eq 1 ] && echo "rename
${etcd}${lev}.d/${oldstartstop}${oldnn}${bn} -> ${etcd}${lev}.d/${newstartstop}${newnn}${bn}"
+ if [ $notreally -eq 0 ];then
+ mv ${etcd}${lev}.d/${oldstartstop}${oldnn}${bn}
${etcd}${lev}.d/${newstartstop}${newnn}${bn}
+ fi
+ if [ $dostart -eq 1 ] && [ $newstartstop = "S" ] && [ $lev =
$RUNLEVEL ]; then
+ $fn start || true
+ fi
+ fi
+
+}
+
+# function to disable/enable init script link
+# $1 should be K/S, means to disable/enable
+# $2 run level [S|2|3|4|5], optional, If no start runlevel is
+# specified after the disable or enable keywords
+# the script will attempt to modify links in all start runlevels
+renamelinks()
+{
+ if [ $# -eq 2 ]; then
+ renamelink $1 $2
+ else
+ for i in 2 3 4 5 S; do
+ renamelink $1 $i
+ done
+ fi
+}
+
while [ $# -gt 0 ]; do
case $1 in
-n) notreally=1
@@ -221,6 +269,13 @@ case $1 in
;;
start | stop)
+ if [ $# -lt 4 ]
+ then
+ echo "Not enough arguments"
+ usage
+ exit 1
+ fi
+
while [ $# -gt 0 ]; do
if [ $1 = "start" ]; then
letter=S
@@ -251,6 +306,32 @@ case $1 in
makelinks
;;
+ enable | disable)
+ if [ $1 = "enable" ]; then
+ letter=S
+ elif [ $1 = "disable" ]; then
+ letter=K
+ else
+ usage
+ exit 1
+ fi
+ shift
+ #
+ if [ $# -gt 0 ]
+ then
+ case $1 in
+ S|2|3|4|5)
+ renamelinks $letter $1
+ ;;
+ *)
+ usage
+ exit 1
+ ;;
+ esac
+ else
+ renamelinks $letter
+ fi
+ ;;
*)
usage
exit 1
--
BRs
Sandy(Li Changqing)
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[yocto] [PATCH] samhain: add rconflict for client and server mode
From: Changqing Li
Signed-off-by: Changqing Li
---
recipes-ids/samhain/samhain-client_4.3.2.bb | 1 +
recipes-ids/samhain/samhain-server_4.3.2.bb | 1 +
2 files changed, 2 insertions(+)
diff --git a/recipes-ids/samhain/samhain-client_4.3.2.bb
b/recipes-ids/samhain/samhain-client_4.3.2.bb
index 812408e..0f53a8c 100644
--- a/recipes-ids/samhain/samhain-client_4.3.2.bb
+++ b/recipes-ids/samhain/samhain-client_4.3.2.bb
@@ -9,3 +9,4 @@ EXTRA_OECONF += " \
"
RDEPENDS_${PN} = "acl zlib attr bash"
+RCONFLICTS_${PN} = "samhain-standalone"
diff --git a/recipes-ids/samhain/samhain-server_4.3.2.bb
b/recipes-ids/samhain/samhain-server_4.3.2.bb
index 9341d44..d304912 100644
--- a/recipes-ids/samhain/samhain-server_4.3.2.bb
+++ b/recipes-ids/samhain/samhain-server_4.3.2.bb
@@ -18,3 +18,4 @@ do_install_append() {
}
RDEPENDS_${PN} += "gmp bash perl"
+RCONFLICTS_${PN} = "samhain-standalone"
--
2.7.4
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[yocto] [meta-cgl] monit lcrypt issue
monit lcrypt issue: Expose lcrypt while building monit with Yocto Thud
When building monit using Yocto Thud the following error pops while building
monit 5.25.2 :
/usr/src/debug/monit/5.25.2-r0/monit-5.25.2/src/util.c:1675: undefined
reference to `crypt’
Older versions of glibc supplied a libcrypt library for this purpose, and
declared the function in .
Newer versions of glibc don't supply libcrypt. In order to prevent the
undefined lcrypt error we need to add virtual/crypt to the recipe’s DEPENDS
Signed-off-by: Ronan Gaillard
mailto:ronan.gaill...@live.fr>>
—
diff --git a/meta-cgl-common/recipes-cgl/monit/monit_5.25.2.bb
b/meta-cgl-common/recipes-cgl/monit/monit_5.25.2.bb
index ab9e922..7a96722 100644
--- a/meta-cgl-common/recipes-cgl/monit/monit_5.25.2.bb
+++ b/meta-cgl-common/recipes-cgl/monit/monit_5.25.2.bb
@@ -9,7 +9,7 @@ HOMEPAGE = "http://mmonit.com/monit/";
LICENSE = "AGPLv3"
LIC_FILES_CHKSUM = "file://COPYING;md5=ea116a7defaf0e93b3bb73b2a34a3f51"
-DEPENDS = "openssl zlib"
+DEPENDS = "openssl zlib virtual/crypt"
SRC_URI = "\
http://mmonit.com/monit/dist/${BP}.tar.gz \
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
