[yocto] File in append recipe not installed
Thanks Gary. I think is not called because I have echo lines in do_install_append() and they don't appear when bitbake -v is used after the recipe is cleaned and rebuilt. This is my layer: releases/meta-mylayer ├── conf │ └── layer.conf ├── README -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] bind: issue in trust anchor management can cause named to crash (CVE-2015-1349)
Hi Benjamin, > I think this list is not published in the yocto lists page: > https://www.yoctoproject.org/tools-resources/community/mailing-lists > And, who would be able to subscribe to it? invite-only? public? This mailing list is an open list to discuss security related activities (mainly for those who contributes the Yocto Project with security updates/patches etc). We have some info about this list at https://wiki.yoctoproject.org/wiki/Security page, we should add this mailing list to https://www.yoctoproject.org/tools-resources/community/mailing-lists as well. Thank you for addressing this. //Sona -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Difference b/w yocto kernels and normal linux.org kernels
Hi Paul Eggleton, Is it kernel is must be a git repository code for building in the yocto? When i gave my custom kernel which is not a git repository code and it is in my development PC, i got invalid SRCREV number error. But when give the same kernel from the git repository it is working. Can you please help me in resolving this error. Cheers, Raghavendra K. From: Raghavendra Kakarla Sent: Tuesday, March 10, 2015 9:51 AM To: Paul Eggleton Cc: yocto@yoctoproject.org Subject: Difference b/w yocto kernels and normal linux.org kernels Hi Paul Eggleton, I have some doubt that is ,there is any difference between the linux kernels downloaded from the yocto and that are download from the kernel.org with same version number? Can you please clarify the my doubt. Thanks and Regards, Raghavendra Kakarla__ __ From: Raghavendra Kakarla Sent: Tuesday, March 3, 2015 5:47 PM To: Paul Eggleton Cc: yocto@yoctoproject.org Subject: RE: SDK generation issue Hi Paul Eggleton, Shall i get any API information in the generated SDK documents. Regards, Raghavendra. From: Paul Eggleton Sent: Tuesday, March 3, 2015 5:40 PM To: Raghavendra Kakarla Cc: yocto@yoctoproject.org Subject: Re: SDK generation issue Assuming you built the SDK you had installed with "doc-pkgs" in SDKIMAGE_FEATURES, they would be in the target sysroot i.e. /sysroots//usr/share/doc/ On Tuesday 03 March 2015 11:55:22 Raghavendra Kakarla wrote: > Hi Paul Eggleton, > > Where can i get the documents generated by the yocto sdk. > > Regards, > Raghavendra. > > From: Raghavendra Kakarla > Sent: Tuesday, March 3, 2015 3:56 PM > To: Paul Eggleton > Cc: yocto@yoctoproject.org > Subject: RE: SDK generation issue > > Hi Paul Eggleton, > > Thank you for your response. > > Now my issue is resolved. > > I have some doubts on yocto-sdk. Can you please clarify them. > > When i Built SDK for YOCTO, I am getting a cross compilation tool chain. > With which i am able to build the applications for my platform. I wanted to > confirm, whether SDK means a toolchain to build the applications or is > there something more (such as documentation, libraries, etc generated for > our platform) > > Regards, > Raghavendra. > > From: Paul Eggleton > Sent: Tuesday, March 3, 2015 3:07 PM > To: Raghavendra Kakarla > Cc: yocto@yoctoproject.org > Subject: Re: SDK generation issue > > On Tuesday 03 March 2015 05:41:43 Raghavendra Kakarla wrote: > > I am generated the yocto SDK using the yocto sdk script "bitbake > > core-image-minimal -c populate_sdk" command. With this command I am able > > to > > generte the installation script file and .manifest file. > > > > I run the installation script file. After running installation script file > > it propts that following message: > > > > Extracting SDK...done > > Setting it up...done > > SDK has been successfully set up and is ready to be used. > > > > > > After this i run the ". > > /opt/poky/1.7/environment-setup-mips32rel-poky-linux" and echo $PATH i got > > the correct path. > > > > After this i built wrote a small example and try to build with the sdk > > generated toolchain by running following command: > > > > mipsel-poky-linux-gcc test.c > > Use $CC instead of running the compiler directly so that you get the correct > options. > > Cheers, > Paul > > > -- > > Paul Eggleton > Intel Open Source Technology Centre -- Paul Eggleton Intel Open Source Technology Centre -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] File in append recipe not installed
On Thursday 12 March 2015 18:01:16 Gary Thomas wrote: > On 2015-03-12 17:21, p_j_r_m wrote: > > I've tested it, but the problem is the same. > > My bbappend recipe is not even called ,so it does not matter what i put in > > it. Why is not called? > > Please don't top-post :-( > > How do you know that your bbappend isn't being used/called? If you name it > incorrectly, e.g. base-files_3.0.99.bbappend, you should get an error > telling you that there is no base-files_3.0.99.bb which matches. Hence if > it's named base-files_3.0.14.bbappend and you get no error, it *is* being > used. > > Please show exactly what is now in your layer (as below). It's really easy > to make a mistake with a '_' instead of '-'. Also, one way to tell for sure whether it is being parsed is to use: bitbake-layers show-appends If it's not listed there, check that the layer shows up in: bitbake-layers show-layers If the layer doesn't show there, check if it has been correctly added to bblayers.conf. If it is, check that your layer.conf is setting BBFILES such that bbappends in the directory you placed the bbappend in will be picked up. Cheers, Paul -- Paul Eggleton Intel Open Source Technology Centre -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Difference b/w yocto kernels and normal linux.org kernels
On Friday 13 March 2015 08:14:13 Raghavendra Kakarla wrote: > Is it kernel is must be a git repository code for building in the yocto? > > When i gave my custom kernel which is not a git repository code and it is in > my development PC, i got invalid SRCREV number error. But when give the > same kernel from the git repository it is working. Can you please help me > in resolving this error. If you want to use your own non-git sources you are moving further away from how the linux-yocto recipe works. If you have not already I would suggest using linux-yocto-custom as described in our kernel development manual: http://www.yoctoproject.org/docs/current/kernel-dev/kernel-dev.html#working-with-your-own-sources Note that you must not have SRCPV included in the recipe's value of PV, or you will get the error you mentioned. Cheers, Paul -- Paul Eggleton Intel Open Source Technology Centre -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] running task only for native but not target?
Hi Yannick,
On Thursday 12 March 2015 19:05:13 Koehler, Yannick wrote:
> I have a package that produce a binary that I need for native, and an C
> header file that I need for target.
>
> I put the following do_install function to install appropriately the bin or
> header according to the class:
>
> do_install_append_class-target () {
> install -d ${D}${includedir}
> install -m 0755 ${S}/ifrpc.h ${D}${includedir}
> }
>
> do_install_append_class-native() {
> install -d ${D}${bindir}
> install -m 0755 ${S}/ifrpcgen ${D}${bindir}
> }
>
> but is there a way for me to disable do_patch/do_configure/do_compile only
> when building for the target? I have tried the following without success:
>
> do_configure_class-target[noexec] = "1"
> do_patch_class-target[noexec] = "1"
> do_compile_class-target[noexec] = "1"
>
> It appears the OVERRIDES do not apply here, any hint on how I can achieve
> this?
Probably the easiest way would be to just null out the tasks just for the
target class i.e.
do_configure_class-target () {
:
}
Cheers,
Paul
--
Paul Eggleton
Intel Open Source Technology Centre
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] eclipse-poky: Can't build from Eclipse, but command line build works
*snip* > > This is a different error. There seems to be a mismatch between your > > toolchain and rootfs. Could you please share the full name of > > > > my_built_image.tar.gz from > > > > runqemu-extract-sdk > > " > > > > I have been able to get things to build, but not exactly in a suggested > manner. I copied the entire target sysroot directory > (~/poky/poky_build/tmp/sysroots/at91sam9x5ek) to the previously mentioned > sysroot destination directory. I re-ran "bitbake meta-ide-support" just to > ensure I had a clean copy. I then modified the SDKTARGETSYSROOT to point to > my copied sysroot location. With this setup, I was able to get the project > to build from Eclipse. It's working, but it's a little ugly getting there. > core-image-minimal builds a very small image, which doesn't have all headers and libraries required to link even a simple binary > So I'm assuming I'm starting at the wrong point for the sysroot to extract. > What do other people do? You have two options here: 1) Generate a standalone toolchain and sdk installer. bitbake -c populate_sdk your_image_name This will generate an installer script-tarball in ~/poky/poky_build/tmp/deploy/sdk/ Execute this script and follow the installation instructions. This will extract both the toolchain and sysroot to a directory of your choice (e.g. /opt/poky/1.6.2/). When you configure the Yocto ADT plugin in Eclipse, select "Standalone pre-built toolchain" before you point it to the sysroot and toolchain directories created by the installer above. 2) Base your image on one of the development images (e.g. core-image-minimal-dev) Cheers, Todor smime.p7s Description: S/MIME cryptographic signature -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Difference b/w yocto kernels and normal linux.org kernels
Hi Paul, I hope you don't mind me asking a question slightly out of topic. I would like to know if there is a recipe for linux kernel 3.19 for dizzy branch (intel x64). Thanks. Regards, Albert. On Fri, Mar 13, 2015 at 4:53 PM, Paul Eggleton wrote: > On Friday 13 March 2015 08:14:13 Raghavendra Kakarla wrote: >> Is it kernel is must be a git repository code for building in the yocto? >> >> When i gave my custom kernel which is not a git repository code and it is in >> my development PC, i got invalid SRCREV number error. But when give the >> same kernel from the git repository it is working. Can you please help me >> in resolving this error. > > If you want to use your own non-git sources you are moving further away from > how the linux-yocto recipe works. If you have not already I would suggest > using linux-yocto-custom as described in our kernel development manual: > > http://www.yoctoproject.org/docs/current/kernel-dev/kernel-dev.html#working-with-your-own-sources > > Note that you must not have SRCPV included in the recipe's value of PV, or > you will get the error you mentioned. > > Cheers, > Paul > > -- > > Paul Eggleton > Intel Open Source Technology Centre > -- > ___ > 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] Difference b/w yocto kernels and normal linux.org kernels
On Friday 13 March 2015 17:05:29 Albert K wrote: > I hope you don't mind me asking a question slightly out of topic. I > would like to know if there is a recipe for linux kernel 3.19 for > dizzy branch (intel x64). Thanks. No, not out of the box - 3.19 wasn't available at the time dizzy (1.7) was branched and we don't generally backport upgrades. That said it should be fairly easy to build your own newer kernel by adding your own recipe to do so (though there may possibly be user-space compatibility issues you need to resolve as a result - I'm no expert there). Cheers, Paul -- Paul Eggleton Intel Open Source Technology Centre -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] eclipse-poky: Can't build from Eclipse, but command line build works
Todor, > -Original Message- > From: Minchev, Todor [mailto:todor.minc...@intel.com] > Sent: Friday, March 13, 2015 4:59 AM > To: Bryan Evenson > Cc: yocto@yoctoproject.org > Subject: Re: [yocto] eclipse-poky: Can't build from Eclipse, but command line > build works > > *snip* > > > > This is a different error. There seems to be a mismatch between your > > > toolchain and rootfs. Could you please share the full name of > > > > > > my_built_image.tar.gz from > > > > > > runqemu-extract-sdk > > > " > > > > > > > I have been able to get things to build, but not exactly in a suggested > manner. I copied the entire target sysroot directory > (~/poky/poky_build/tmp/sysroots/at91sam9x5ek) to the previously > mentioned sysroot destination directory. I re-ran "bitbake meta-ide- > support" just to ensure I had a clean copy. I then modified the > SDKTARGETSYSROOT to point to my copied sysroot location. With this setup, > I was able to get the project to build from Eclipse. It's working, but it's > a little > ugly getting there. > > > > core-image-minimal builds a very small image, which doesn't have all > headers and libraries required to link even a simple binary > > > So I'm assuming I'm starting at the wrong point for the sysroot to extract. > What do other people do? > > You have two options here: > > 1) Generate a standalone toolchain and sdk installer. > > bitbake -c populate_sdk your_image_name > > This will generate an installer script-tarball in > ~/poky/poky_build/tmp/deploy/sdk/ > > Execute this script and follow the installation instructions. This will > extract both the toolchain and sysroot to a directory of your choice > (e.g. /opt/poky/1.6.2/). > > When you configure the Yocto ADT plugin in Eclipse, select "Standalone > pre-built toolchain" before you point it to the sysroot and toolchain > directories created by the installer above. > > > 2) Base your image on one of the development images (e.g. > core-image-minimal-dev) > So *that* explains why I've never been able to get the Eclipse plug-in to work. I'd suggest adding the above detail to the "Extracting a Root Filesystem" section of the manual. For a frame of reference, I do two separate actions. I'll use bitbake to build our full production image. We also have a few userspace applications in which I'll build through Eclipse and test on the actual hardware. We interface with enough external devices that testing with the QEMU doesn't work too well and we'll need to test on actual hardware. So I just need to build something that I can then run on the actual hardware. After re-reading the "Extracting the Root Filesystem" section, I think there is an assumption that someone would only be doing this for QEMU purposes. I think some details stating what is needed out of the extracted filesystem for development would be beneficial. Thanks, Bryan > Cheers, > Todor > > -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] Post install script in a recipe
Hi All,
I was trying to perform a post install activity as part of the recipe using
pkg_postinst_PACKAGENAME() but seems it's not working. Below is the sample
function we have written as part of the recipe
pkg_postinst_test (){
#!/bin/sh -xe
echo " we are calling post install for test"
mkdir -p /test/logs/1
touch /test/test1/test2/test3/sample.txt
}
testX directory exists as they are created as part of the install activity.
When we verify the post install we did find the file being created as below is
the output
ls /test/test1/test2/test3/*.txt
ls: cannot access /test/test1/test2/test3/*.txt: No such file or directory
So any thoughts how to fix this issue as we need to perform some post install
activity as part of the package installation.
Regards,
Abhinav
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[yocto] Qt mouse driver
i successfully built customized yocto project(Qte-demo) for beagleboard-xm, In project i use two input device i.e mouse and touchscreen. Default library used in qt is tslib. So how do i use mouse and touchscreen at the same time? -- thanks and regards, parthiban +919790329795 -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] Using Pre Built Toolchain in Yocto Tree
Is there a way to configure Yocto to use Pre Built toolchain (like downloaded from CodeSourcery, etc.). I want to avoid building toolchain because it takes too much time and using new toolchain is not of my concern. I was using this feature in buildroot. Thanks in Advance!!! -- Regards Darshan -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] running task only for native but not target?
Hi Paul,
Thanks, yes that is likely to work, I will try it. I was looking for a more
Yocto-like solution using the overriding stuff but it seems the overriding
doesn't apply in this particular situation.
Yannick Koehler
-Message d'origine-
De : Paul Eggleton [mailto:paul.eggle...@linux.intel.com]
Envoyé : March-13-15 5:02 AM
À : Koehler, Yannick (HP Networking)
Cc : yocto@yoctoproject.org
Objet : Re: [yocto] running task only for native but not target?
Hi Yannick,
On Thursday 12 March 2015 19:05:13 Koehler, Yannick wrote:
> I have a package that produce a binary that I need for native, and an
> C header file that I need for target.
>
> I put the following do_install function to install appropriately the
> bin or header according to the class:
>
> do_install_append_class-target () {
> install -d ${D}${includedir}
> install -m 0755 ${S}/ifrpc.h ${D}${includedir}
> }
>
> do_install_append_class-native() {
> install -d ${D}${bindir}
> install -m 0755 ${S}/ifrpcgen ${D}${bindir}
> }
>
> but is there a way for me to disable do_patch/do_configure/do_compile
> only when building for the target? I have tried the following without
> success:
>
> do_configure_class-target[noexec] = "1"
> do_patch_class-target[noexec] = "1"
> do_compile_class-target[noexec] = "1"
>
> It appears the OVERRIDES do not apply here, any hint on how I can
> achieve this?
Probably the easiest way would be to just null out the tasks just for the
target class i.e.
do_configure_class-target () {
:
}
Cheers,
Paul
--
Paul Eggleton
Intel Open Source Technology Centre
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] running task only for native but not target?
On 13 March 2015 at 11:46, Koehler, Yannick (HP Networking) < yannick.koeh...@hp.com> wrote: > Thanks, yes that is likely to work, I will try it. I was looking for a > more Yocto-like solution using the overriding stuff but it seems the > overriding doesn't apply in this particular situation. > An alternative solution would be to build everything all the time, and package correctly so that you don't install unrequired binaries on the target. Ross -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] running task only for native but not target?
I believe this is the actual solution I am using, the tasks are always executed but my install steps differ and only install the appropriate file, which in turn I believe generate appropriate packages. That works too, but I do not want to get into issues where the build on the target fails due to arch issue and having to pull unnecessary dependency packages on my target and lost cpu cycle. But it would still work, which is why I am using it but looking for an alternative. Yannick Koehler De : Burton, Ross [mailto:ross.bur...@intel.com] Envoyé : March-13-15 7:51 AM À : Koehler, Yannick (HP Networking) Cc : Paul Eggleton; yocto@yoctoproject.org Objet : Re: [yocto] running task only for native but not target? On 13 March 2015 at 11:46, Koehler, Yannick (HP Networking) wrote: Thanks, yes that is likely to work, I will try it. I was looking for a more Yocto-like solution using the overriding stuff but it seems the overriding doesn't apply in this particular situation. An alternative solution would be to build everything all the time, and package correctly so that you don't install unrequired binaries on the target. Ross -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Using Pre Built Toolchain in Yocto Tree
Hi Darshan, On Fri, Mar 13, 2015 at 12:43 PM, Darshan Patel wrote: > Is there a way to configure Yocto to use Pre Built toolchain (like > downloaded from CodeSourcery, etc.). I want to avoid building toolchain > because it takes too much time and using new toolchain is not of my concern. > > I was using this feature in buildroot. Download the pre-built toolchain from here: http://downloads.yoctoproject.org/releases/yocto/yocto-1.7/toolchain/ eg: armv7 toolchain for an x86_64 host machine - # wget http://downloads.yoctoproject.org/releases/yocto/yocto-1.7/toolchain/x86_64/poky-glibc-x86_64-core-image-sato-armv7a-vfp-neon-toolchain-1.7.sh # sudo sh poky-glibc-x86_64-core-image-sato-armv7a-vfp-neon-toolchain-1.7.sh # source /opt/poky/1.7/environment-setup-armv7a-vfp-neon-poky-linux-gnueabi # arm-poky-linux-gnueabi-gcc hello.c > Thanks in Advance!!! > > Regards > Darshan Best Regards, Maxin -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Using Pre Built Toolchain in Yocto Tree
Hi Darshan, On a second thought, feels like I misunderstood your question. Please refer these: a) http://www.yoctoproject.org/docs/latest/adt-manual/adt-manual.html#optionally-using-an-external-toolchain b) http://elinux.org/images/c/c8/ExternalToolchainsInYocto.pdf c) https://www.youtube.com/watch?v=FZpKbSHRJro On Fri, Mar 13, 2015 at 2:50 PM, Maxin John wrote: > Hi Darshan, > > On Fri, Mar 13, 2015 at 12:43 PM, Darshan Patel wrote: >> Is there a way to configure Yocto to use Pre Built toolchain (like >> downloaded from CodeSourcery, etc.). I want to avoid building toolchain >> because it takes too much time and using new toolchain is not of my concern. >> >> I was using this feature in buildroot. > > Download the pre-built toolchain from here: > http://downloads.yoctoproject.org/releases/yocto/yocto-1.7/toolchain/ > > eg: armv7 toolchain for an x86_64 host machine - > > # wget > http://downloads.yoctoproject.org/releases/yocto/yocto-1.7/toolchain/x86_64/poky-glibc-x86_64-core-image-sato-armv7a-vfp-neon-toolchain-1.7.sh > # sudo sh poky-glibc-x86_64-core-image-sato-armv7a-vfp-neon-toolchain-1.7.sh > # source /opt/poky/1.7/environment-setup-armv7a-vfp-neon-poky-linux-gnueabi > > # arm-poky-linux-gnueabi-gcc hello.c > >> Thanks in Advance!!! >> >> Regards >> Darshan Best Regards, Maxin -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Using Pre Built Toolchain in Yocto Tree
On 3/13/15 6:43 AM, Darshan Patel wrote: > Is there a way to configure Yocto to use Pre Built toolchain (like downloaded > from CodeSourcery, etc.). I want to avoid building toolchain because it takes > too much time and using new toolchain is not of my concern. If you wish to use the Mentor Sourcery toolchain, they have a layer available that allows you to incorporate it. https://github.com/MentorEmbedded/meta-sourcery I have not used this layer in a while (and I don't work for Mentor), so if you have questions you may need to find someone who is more familiar with the layer. There is another alternative though. Build the toolchain once, store the sstate-cache files that were generated and use those on subsequent builds. There is a mechanism called the locked sstate-cache where you can feed into your configuration the hashes for the sstate-cache item you are interested in. This will tell the system to simply re-use the components, and ignore any system changes that may have occurred. --Mark > I was using this feature in buildroot. > > Thanks in Advance!!! > > -- > Regards > Darshan > > -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Using Pre Built Toolchain in Yocto Tree
On 2015-03-13 08:47, Mark Hatle wrote: On 3/13/15 6:43 AM, Darshan Patel wrote: Is there a way to configure Yocto to use Pre Built toolchain (like downloaded from CodeSourcery, etc.). I want to avoid building toolchain because it takes too much time and using new toolchain is not of my concern. If you wish to use the Mentor Sourcery toolchain, they have a layer available that allows you to incorporate it. https://github.com/MentorEmbedded/meta-sourcery I have not used this layer in a while (and I don't work for Mentor), so if you have questions you may need to find someone who is more familiar with the layer. There is another alternative though. Build the toolchain once, store the sstate-cache files that were generated and use those on subsequent builds. There is a mechanism called the locked sstate-cache where you can feed into your configuration the hashes for the sstate-cache item you are interested in. This will tell the system to simply re-use the components, and ignore any system changes that may have occurred. Could you elaborate on this (locked sstate-cache)? I don't see any mention of it in the documentation. --Mark I was using this feature in buildroot. Thanks in Advance!!! -- Regards Darshan -- Gary Thomas | Consulting for the MLB Associates |Embedded world -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] [meta-security][PATCH] libseccomp update
PPC support is not yet in master. I will backport patches shortly. Ptest/tests for this package require busybox config changes to get the scripts to work, so they are exclude with this update. For more information on this release, please see: https://github.com/seccomp/libseccomp/blob/master/CHANGELOG Armin Kuster (1): libseccomp: update to version 2.2.0 recipes-security/libseccomp/libseccomp_2.1.1.bb | 37 - recipes-security/libseccomp/libseccomp_2.2.0.bb | 23 +++ 2 files changed, 23 insertions(+), 37 deletions(-) delete mode 100644 recipes-security/libseccomp/libseccomp_2.1.1.bb create mode 100644 recipes-security/libseccomp/libseccomp_2.2.0.bb -- 1.9.1 -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] [meta-security][PATCH] libseccomp: update to version 2.2.0
License is not LGPL
sources come from github now
dropped patches since alt solutions included now.
Changes in the 2.2.0 release include:
* Migrated the build system to autotools
* Added support for the aarch64 architecture
* Added support for the mips, mips64, and mips64n32 architectures
* Added support for the new seccomp() syscall and thread sync
* Added Python bindings
* Updated the internal syscall tables to Linux v3.19
Signed-off-by: Armin Kuster
---
recipes-security/libseccomp/libseccomp_2.1.1.bb | 37 -
recipes-security/libseccomp/libseccomp_2.2.0.bb | 23 +++
2 files changed, 23 insertions(+), 37 deletions(-)
delete mode 100644 recipes-security/libseccomp/libseccomp_2.1.1.bb
create mode 100644 recipes-security/libseccomp/libseccomp_2.2.0.bb
diff --git a/recipes-security/libseccomp/libseccomp_2.1.1.bb
b/recipes-security/libseccomp/libseccomp_2.1.1.bb
deleted file mode 100644
index 2d93479..000
--- a/recipes-security/libseccomp/libseccomp_2.1.1.bb
+++ /dev/null
@@ -1,37 +0,0 @@
-SUMMARY = "interface to seccomp filtering mechanism"
-DESCRIPTION = "The libseccomp library provides and easy to use, platform
independent,interface to the Linux Kernel's syscall filtering mechanism:
seccomp."
-SECTION = "security"
-LICENSE = "GPL-2.0"
-LIC_FILES_CHKSUM =
"file://${COMMON_LICENSE_DIR}/GPL-2.0;md5=801f80980d171dd6425610833a22dbe6"
-
-SRC_URI = "http://sourceforge.net/projects/libseccomp/files/${BP}.tar.gz \
- file://compiler.patch \
- file://0001-tests-create-install-tests-target.patch \
- file://0002-tests-install-python-tests-if-appropriate.patch \
- file://0003-tests-introduce-alternate-test-report-format.patch \
-"
-
-SRC_URI[md5sum] = "1f41207b29e66a7e5e375dd48a64de85"
-SRC_URI[sha256sum] =
"8812c11e407c383f5ad6afb84a88e5a0224477bcfe8ff03f0c548e5abaac841c"
-
-do_configure() {
- ${S}/configure --prefix=${prefix} --libdir=${libdir}
-}
-
-do_compile_append() {
-oe_runmake DESTDIR=${D} tests
-}
-
-do_install() {
-oe_runmake DESTDIR=${D} install
-oe_runmake DESTDIR=${D} install-tests
-}
-
-# MIPS, aarch64, and PowerPC are not supported in this version.
-COMPATIBLE_HOST = '(x86_64|i.86|arm).*-linux'
-
-PACKAGES += "${PN}-tests "
-FILES_${PN}-tests = "${libdir}/${BPN}/tests/*"
-FILES_${PN}-dbg += "${libdir}/${BPN}/tests/.debug/*"
-
-RDEPENDS_${PN} = "bash"
diff --git a/recipes-security/libseccomp/libseccomp_2.2.0.bb
b/recipes-security/libseccomp/libseccomp_2.2.0.bb
new file mode 100644
index 000..fb29e6c
--- /dev/null
+++ b/recipes-security/libseccomp/libseccomp_2.2.0.bb
@@ -0,0 +1,23 @@
+SUMMARY = "interface to seccomp filtering mechanism"
+DESCRIPTION = "The libseccomp library provides and easy to use, platform
independent,interface to the Linux Kernel's syscall filtering mechanism:
seccomp."
+SECTION = "security"
+LICENSE = "LGPL-2.1"
+LIC_FILES_CHKSUM =
"file://LICENSE;beginline=0;endline=1;md5=8eac08d22113880357ceb8e7c37f989f"
+
+SRCREV = "bd10aab13c7248cc0df57512617e33d6743d33a6"
+
+PV = "2.2.0+git${SRCPV}"
+
+SRC_URI = "git://github.com/seccomp/libseccomp.git;protocol=http"
+
+S = "${WORKDIR}/git"
+
+inherit autotools-brokensep pkgconfig
+
+PACKAGECONFIG ??= ""
+PACKAGECONFIG[python] = "--enable-python, --disable-python, python"
+
+# PowerPC is not supported in this version.
+COMPATIBLE_HOST = '(x86_64|i.86|arm|arm64|mips|mips64).*-linux'
+
+RDEPENDS_${PN} = "bash"
--
1.9.1
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] OpenEmbedded Developer America's Meeting
Hello Folks, OEDAM is nearing. If you have not signed up, please do so. It will help me with head count for badges. We also need more subject matter the Agenda. If you have any topics or ideas, please submit them. kind regards, Armin On 02/10/2015 12:27 PM, Philip Balister wrote: We've scheduled a meeting in San Jose at a Monte Vista facility for March 27-28. This is after ELC (also in San Jose). There is a Yocto Project developer Day the day after ELC. I've made a page on the wiki to start collecting information: http://openembedded.org/wiki/OEDAM_2015 To get an idea of what we cover, see the page from the prior year: http://openembedded.org/wiki/OEDAM_2014 I apologize for the late notice. There were issues that led to a delay with dates due to the YP Dev day. Philip -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] [ANNOUNCEMENT] 1.8_M3 released
The third milestone release for Yocto Project 1.8 is available for download now. http://downloads.yoctoproject.org/releases/yocto/milestones/yocto-1.8_M3/ Thank you everyone for your contributions. eclipse-poky/juno-master 26bfc407781aa185f244a47ba63120343cee4a37 eclipse-poky/kepler-master b4d75601847b4c5b060265a37b47c2a9642da62d meta-qt3 3016129d90b7ac8517a5227d819f10ad417b5b45 poky 5c1c8af083ca7b57cc339d16ce0513b27c5dac90 Test report at https://wiki.yoctoproject.org/wiki/WW10_-_2015-03-03_-_Full_Pass_1.8_M3.rc3 -- Elizabeth Flanagan Yocto Project Build and Release -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] OpenEmbedded Developer America's Meeting
You can add yourself here (or drop me an email if you have trouble logging in) http://www.openembedded.org/wiki/OEDAM_2015 We plan to have a Hangout on the Air so people can follow along remotely. Philip On 03/13/2015 11:56 AM, akuster wrote: > Hello Folks, > > OEDAM is nearing. If you have not signed up, please do so. It will help > me with head count for badges. > > We also need more subject matter the Agenda. If you have any topics or > ideas, please submit them. > > kind regards, > Armin > > On 02/10/2015 12:27 PM, Philip Balister wrote: >> We've scheduled a meeting in San Jose at a Monte Vista facility for >> March 27-28. This is after ELC (also in San Jose). There is a Yocto >> Project developer Day the day after ELC. >> >> I've made a page on the wiki to start collecting information: >> >> http://openembedded.org/wiki/OEDAM_2015 >> >> To get an idea of what we cover, see the page from the prior year: >> >> http://openembedded.org/wiki/OEDAM_2014 >> >> I apologize for the late notice. There were issues that led to a delay >> with dates due to the YP Dev day. >> >> Philip >> > > -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] [meta-security][PATCH] suricata: update to 2.0.7
this includes CVE-2015-0928
moved patches and files to more generic dir name
Signed-off-by: Armin Kuster
---
.../suricata/{suricata-2.0.6 => files}/no_libhtp_build.patch| 0
.../suricata/{suricata-2.0.6 => files}/no_pcap_pkgconf_check.patch | 0
recipes-security/suricata/{suricata-2.0.6 => files}/suricata.yaml | 0
.../suricata/{suricata-2.0.6 => files}/volatiles.03_suricata| 0
recipes-security/suricata/{libhtp_0.5.16.bb => libhtp_0.5.17.bb}| 4 +++-
recipes-security/suricata/suricata.inc | 6 +++---
recipes-security/suricata/{suricata_2.0.6.bb => suricata_2.0.7.bb} | 0
7 files changed, 6 insertions(+), 4 deletions(-)
rename recipes-security/suricata/{suricata-2.0.6 =>
files}/no_libhtp_build.patch (100%)
rename recipes-security/suricata/{suricata-2.0.6 =>
files}/no_pcap_pkgconf_check.patch (100%)
rename recipes-security/suricata/{suricata-2.0.6 => files}/suricata.yaml (100%)
rename recipes-security/suricata/{suricata-2.0.6 =>
files}/volatiles.03_suricata (100%)
rename recipes-security/suricata/{libhtp_0.5.16.bb => libhtp_0.5.17.bb} (84%)
rename recipes-security/suricata/{suricata_2.0.6.bb => suricata_2.0.7.bb}
(100%)
diff --git a/recipes-security/suricata/suricata-2.0.6/no_libhtp_build.patch
b/recipes-security/suricata/files/no_libhtp_build.patch
similarity index 100%
rename from recipes-security/suricata/suricata-2.0.6/no_libhtp_build.patch
rename to recipes-security/suricata/files/no_libhtp_build.patch
diff --git
a/recipes-security/suricata/suricata-2.0.6/no_pcap_pkgconf_check.patch
b/recipes-security/suricata/files/no_pcap_pkgconf_check.patch
similarity index 100%
rename from recipes-security/suricata/suricata-2.0.6/no_pcap_pkgconf_check.patch
rename to recipes-security/suricata/files/no_pcap_pkgconf_check.patch
diff --git a/recipes-security/suricata/suricata-2.0.6/suricata.yaml
b/recipes-security/suricata/files/suricata.yaml
similarity index 100%
rename from recipes-security/suricata/suricata-2.0.6/suricata.yaml
rename to recipes-security/suricata/files/suricata.yaml
diff --git a/recipes-security/suricata/suricata-2.0.6/volatiles.03_suricata
b/recipes-security/suricata/files/volatiles.03_suricata
similarity index 100%
rename from recipes-security/suricata/suricata-2.0.6/volatiles.03_suricata
rename to recipes-security/suricata/files/volatiles.03_suricata
diff --git a/recipes-security/suricata/libhtp_0.5.16.bb
b/recipes-security/suricata/libhtp_0.5.17.bb
similarity index 84%
rename from recipes-security/suricata/libhtp_0.5.16.bb
rename to recipes-security/suricata/libhtp_0.5.17.bb
index 9d07133..7390e20 100644
--- a/recipes-security/suricata/libhtp_0.5.16.bb
+++ b/recipes-security/suricata/libhtp_0.5.17.bb
@@ -4,10 +4,12 @@ require suricata.inc
LIC_FILES_CHKSUM =
"file://../LICENSE;beginline=1;endline=2;md5=1fbd81241fe252ec0f5658a521ab7dd8"
+DEPENDS = "zlib"
+
inherit autotools pkgconfig
CFLAGS += "-D_DEFAULT_SOURCE"
-S = "${WORKDIR}/suricata-2.0.6/${BPN}"
+S = "${WORKDIR}/suricata-2.0.7/${BPN}"
RDEPENDS_${PN} += "zlib"
diff --git a/recipes-security/suricata/suricata.inc
b/recipes-security/suricata/suricata.inc
index a7f95b1..79622dc 100644
--- a/recipes-security/suricata/suricata.inc
+++ b/recipes-security/suricata/suricata.inc
@@ -2,7 +2,7 @@ HOMEPAGE = "http://suricata-ids.org/";
SECTION = "security Monitor/Admin"
LICENSE = "GPLv2"
-SRC_URI = "http://www.openinfosecfoundation.org/download/suricata-2.0.6.tar.gz";
+SRC_URI = "http://www.openinfosecfoundation.org/download/suricata-2.0.7.tar.gz";
-SRC_URI[md5sum] = "14bfb3adc184d4da321c93ed9abae500"
-SRC_URI[sha256sum] =
"e833e35ea3b6029bbdef81660af22e8f563494eac85d97618d761ce1b69c78ec"
+SRC_URI[md5sum] = "43cd7dd958d434c580426020079914d7"
+SRC_URI[sha256sum] =
"c5c3ccebeecbace39df0ff2d50ec4515b541103ffaa5e33cd1dc79d4955c0dfd"
diff --git a/recipes-security/suricata/suricata_2.0.6.bb
b/recipes-security/suricata/suricata_2.0.7.bb
similarity index 100%
rename from recipes-security/suricata/suricata_2.0.6.bb
rename to recipes-security/suricata/suricata_2.0.7.bb
--
1.9.1
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] File in append recipe not installed
Thanks for your suggestionsThe problem was that my recipe files were taken from sstate directories, even when they were previously cleaned with bitbake -c clean. If I use -c cleansstate instead, all is ok . El Viernes 13 de marzo de 2015 9:17, Paul Eggleton escribió: On Thursday 12 March 2015 18:01:16 Gary Thomas wrote: > On 2015-03-12 17:21, p_j_r_m wrote: > > I've tested it, but the problem is the same. > > My bbappend recipe is not even called ,so it does not matter what i put in > > it. Why is not called? > > Please don't top-post :-( > > How do you know that your bbappend isn't being used/called? If you name it > incorrectly, e.g. base-files_3.0.99.bbappend, you should get an error > telling you that there is no base-files_3.0.99.bb which matches. Hence if > it's named base-files_3.0.14.bbappend and you get no error, it *is* being > used. > > Please show exactly what is now in your layer (as below). It's really easy > to make a mistake with a '_' instead of '-'. Also, one way to tell for sure whether it is being parsed is to use: bitbake-layers show-appends If it's not listed there, check that the layer shows up in: bitbake-layers show-layers If the layer doesn't show there, check if it has been correctly added to bblayers.conf. If it is, check that your layer.conf is setting BBFILES such that bbappends in the directory you placed the bbappend in will be picked up. Cheers, Paul -- Paul Eggleton Intel Open Source Technology Centre -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
