[yocto] [meta-selinux] [PATCH v1] libpcre: do no create links when compiling for windows
lipcre-native is trying to create symbolic links to so files
when used with meta-mingw. Remove this condition for mingw builds.
Signed-off-by: Sinan Kaya
---
recipes-support/libpcre/libpcre_selinux.inc | 20 +---
1 file changed, 13 insertions(+), 7 deletions(-)
diff --git a/recipes-support/libpcre/libpcre_selinux.inc
b/recipes-support/libpcre/libpcre_selinux.inc
index 59c0184..dc287d7 100644
--- a/recipes-support/libpcre/libpcre_selinux.inc
+++ b/recipes-support/libpcre/libpcre_selinux.inc
@@ -1,11 +1,17 @@
do_install_append () {
- if [ ! ${D}${libdir} -ef ${D}${base_libdir} ]; then
- realsofile=`readlink ${D}${libdir}/libpcre.so`
- mkdir -p ${D}/${base_libdir}/
- mv -f ${D}${libdir}/libpcre.so.* ${D}${base_libdir}/
- relpath=${@os.path.relpath("${base_libdir}", "${libdir}")}
- ln -sf ${relpath}/${realsofile} ${D}${libdir}/libpcre.so
- ln -sf ${relpath}/${realsofile} ${D}${libdir}/libpcre.so.1
+ # This code creates libpcre for both the dev machine (SDK native)
+ # and for cross-compiling (machine arch). For Linux (SDK Linux native
+ # + all machine arch), symlinks to the .so files have to be created,
+ # but not for the Windows SDK native.
+ if [ ${TARGET_OS} != "mingw32" ]; then
+ if [ ! ${D}${libdir} -ef ${D}${base_libdir} ]; then
+ realsofile=`readlink ${D}${libdir}/libpcre.so`
+ mkdir -p ${D}/${base_libdir}/
+ mv -f ${D}${libdir}/libpcre.so.* ${D}${base_libdir}/
+ relpath=${@os.path.relpath("${base_libdir}",
"${libdir}")}
+ ln -sf ${relpath}/${realsofile} ${D}${libdir}/libpcre.so
+ ln -sf ${relpath}/${realsofile}
${D}${libdir}/libpcre.so.1
+ fi
fi
}
--
2.19.0
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] pcre-config replacement
On Thu, Jan 31, 2019 at 2:14 AM Burton, Ross wrote: > pkg-config. Inherit the pkgconfig class in the recipe if it doesn't > already, and see for example > > meta/recipes-devtools/swig/swig/0001-configure-use-pkg-config-for-pcre-detection.patch > in oe-core for an example. > > This is an upstreamable change so ideally submit it upstream so you > don't have to carry a patch around too. > Indeed, that is exactly what I have done: https://github.com/SpiderLabs/ModSecurity/pull/2014 It looks like a few of their automated regression tests are failing, so I probably have more work to do on the patch. I did end up finding the patch you referenced, and that got me most of the way there. I do not use autotools much, so it is hard for me to tell if I missed something obvious. ..Ch:W.. -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [oe] OE Summit @ SCaLE 17x - Sunday March 10th 2019 - Pasadena CA
On Thu, Jan 31, 2019 at 5:40 AM Andrea Galbusera wrote: > On Thu, Jan 31, 2019 at 8:26 AM Trevor Woerner wrote: > > The schedule for the OE Summit has been posted: > > https://www.socallinuxexpo.org/scale/17x/schedule/sunday > > https://www.socallinuxexpo.org/scale/17x/open-embedded-summit-0 > > To whoever can double check and fix the schedule... it looks like > there's a typo at the second link, where Alistair's talk is listed > twice. From the first link "Lokesh Kumar Goel > OpenEmbedded in LG Products" should be at 11.30am instead. > Thanks. There are a bunch of other snafus with the webpages (i.e. the title of Alistair's talk is actually "RISC-V and OpenEmbedded", and some of the links to the speakers' bios doesn't seem to work properly). I had notified the organizers even before I sent out this email, but didn't want to wait even longer to let everyone know about this event. Hopefully the organizers can get around to fixing them soon-ish. -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] RDEPENDS and do_rootfs
Ah in that case there's been a lot of work since daisy to useradd etc. Ross On Thu, 31 Jan 2019 at 15:51, Darcy Watkins wrote: > > Hi, > > In my case, package A creates groups a1, a2 and a3. > > B is actually a family of packages B1, B2 and B3 that each create user > b1, b2, or b3 respectively, but also adds the new user to groups a1, a2 > and/or a3. > > So in this case, it is necessary that package A first be installed AND > that its post-inst scripts have run to generate groups a1, a2 and a3. > > If, as you suggest, RDEPENDS will NOT guarantee this, then I will need > to solve this another way, perhaps by... > > agroups.bbclass - creates groups a1, a2 and a3 for any package recipe > that inherits it. > > Package recipes, A, B1, B2 and B3 would thus all have to inherit from > agroups.bbclass. > > The first package installed creates the groups in rootfs. The remaining > packages just find the groups already present. > > So I think that there may be a solution for my case. > > - > > I think that this limitation possibly may be related to some useradd > failures reported a few years back such as "ERROR: Tried running > useradd command 10 times without scucess, giving up". There had been > changes made by patching the shadow package and by refining the bbclass > to use file locks. I went for about three years with just the luck of > the draw that packages were installed in a good order until this showed > up. I had backported some of these changes to 'daisy' before realizing > that the groups simply hadn't been created yet. > > > > On Thu, 2019-01-31 at 10:52 +, Burton, Ross wrote: > > Forgot to say, Bitbake's dependency model is loosely based on > > Debian's > > so the Debian Policy is a good read for semantics: > > > > > https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.debian.org%2Fdoc%2Fdebian-policy%2Fch-relationships.html%23binary-dependencies-depends-recommends-suggests-enhances-pre-dependsdata=02%7C01%7Cdwatkins%40sierrawireless.com%7Ccb4829af452948bfa95208d6876a34ed%7C08059a4c248643dd89e33a747e0dcbe8%7C1%7C0%7C636845287569900461sdata=WsJ0EjOAI7C%2BurDmAfVMCGb9SEaAWMxy%2F8Xpfks%2FjPA%3Dreserved=0 > > > > Debian's "Depends" is our "RDEPENDS", what you want is "Pre-Depends" > > that we don't (yet) support. As I said, this is just a matter of > > picking a name and then mapping it into the control file. > > > > Ross > > > > On Thu, 31 Jan 2019 at 10:49, Burton, Ross > > wrote: > > > > Presumably the problem here is that you've a maintainer script > > (preinst or postinst) in B that needs a binary/library from A, and is > > failing because B's postinst is running before A is unpacked? If > > not, > > please clarify, otherwise the problem is that DEPENDS just talks > > about > > the final solution. If you want to express that A needs to be > > installed and configured before B is configured then you'll need to > > use Pre-Depends, which I don't believe are actually supported in the > > packaging classes yet. I know that dpkg and opkg support this, and > > presumably rpm too, so extending the packaging classes is a few > > minutes work. > > > > Ross > > > > On Thu, 31 Jan 2019 at 06:51, Darcy Watkins < > > dwatk...@sierrawireless.com> wrote: > > > > Hi, > > > > Can someone knowledgeable with the inner workings of the build system > > please confirm... > > > > IF package B has RDEPENDS on package A > > > > THEN during do_rootfs task, package A will always be installed into > > rootfs first AND the post-inst scripts of package A will always be > > run > > prior to those for package B. > > > > Also, if that can be confirmed for 'daisy' branch, that would really > > be > > helpful. If not, then please mention as far back the branch that you > > know for sure. Thanks! > > > > > > > > -- > > > > > > Regards, > > > > Darcy > > > > Darcy Watkins :: Senior Staff Engineer, Firmware > > > > SIERRA > > WIRELESS > > Direct +1 604 233 7989 :: Fax +1 604 231 1109 :: Main + > > 1 604 231 1100 > > 13811 Wireless Way :: Richmond, BC Canada V6V 3A4 > > [P1] > > > > dwatk...@sierrawireless.com :: > > https://na01.safelinks.protection.outlook.com/?url=www.sierrawireless.comdata=02%7C01%7Cdwatkins%40sierrawireless.com%7Ccb4829af452948bfa95208d6876a34ed%7C08059a4c248643dd89e33a747e0dcbe8%7C1%7C0%7C636845287569900461sdata=d946J0HFRXZgDiC1QjtumL%2BX4mzpHkhlvuC1J1xEbeE%3Dreserved=0 > > > > > > > > -- > > ___ > > yocto mailing list > > yocto@yoctoproject.org > > > https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.yoctoproject.org%2Flistinfo%2Fyoctodata=02%7C01%7Cdwatkins%40sierrawireless.com%7Ccb4829af452948bfa95208d6876a34ed%7C08059a4c248643dd89e33a747e0dcbe8%7C1%7C0%7C636845287569900461sdata=DiZmJr86q5r0i1iVk4Yraj0CB6fXY0Eczkh8HpigJlA%3Dreserved=0 > -- > > > Regards, > > Darcy > > Darcy Watkins :: Senior Staff Engineer, Firmware > > SIERRA > WIRELESS > Direct +1 604 233 7989 :: Fax +1 604 231 1109 :: Main + > 1
Re: [yocto] How to create a signed bootloader and Linux kernel on a UEFI BIOS
On Thu, Jan 31, 2019 at 12:53:36PM +0100, Dominig ar Foll (Intel Open Source) wrote: > Hello, > > Securing the full boot chain on a UEFI BIOS such as those provided on > Intel platforms is possible but not that simple. > Working, detailed documentation is not easy to find anywhere. > > Some of my students from Lorient (University of South Brittany) have > done a good documentation job on > a HowTo create and boot a signed kernel and Grub2 on a UEFI BIOS. > > As it could be useful to some of you, I share the link. > https://ubs_csse.gitlab.io/secu_os/tutorials/linux_secure_boot.html > > Thanks to Romain Brenaget, Jerôme Blanchard and Pierre Fontaine from the > Master1 in Embedded Cyber Security. > > fontaine.e1800...@etud.univ-ubs.fr > brenaget.e1803...@etud.univ-ubs.fr > blanchard.e1804...@etud.univ-ubs.fr I did pick up something new reading through those docs, so thanks for the link. Please note that in the context of OpenEmbedded https://github.com/jiazhang0/meta-secure-core/tree/master/meta-efi-secure-boot provides all of this and is fairly well documented. There may be some interesting parts in there for you and your team as it does handle the kernel/initramfs question differently. -- Tom signature.asc Description: PGP signature -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] How to archive only packages contained in a certain image
Please remember to keep the list on CC. The reason is that those recipes are built for the target so they'll be archived, the archiver doesn't distinguish what recipes go into what image. It's relatively simple to filter the list after the build if you want to produce just what is in a specific image, take the image manifest and use oe-pkgdata-util to turn the package names into recipes. Ross On Thu, 31 Jan 2019 at 14:01, David Zimmermann wrote: > > Hi Ross, > > and thanks for your reply. > I do bake an image based on core-image-minimal with additional packages like > openssh and qt (-base, -declarative, -quickcontrols). > My folder ’tmp/deploy/sources/arm-poky-linux-gnueabi’ e.g. contains: > perl, pulseaudio and python > > Even though those might be dependencies I inherited by other recipes - python > e.g. is not contained / will be installed to my image. > As a countercheck I see what licenses will be placed in the image > (COPY_LIC_DIRS = 1 && COPY_LIC_MANIFEST = 1) which reflects the limited > number of packages I do expect. > > Regards, > David > > > Am 31.01.2019 um 11:11 schrieb Burton, Ross : > > > > Does it not just contain the packages used to build the entire image, > > so build-time dependents. Can you give an example of a recipe that is > > archived but shouldn't be? > > > > Ross > > > > On Thu, 31 Jan 2019 at 08:46, David Zimmermann > > wrote: > >> > >> Hi List, > >> > >> I use Yocto Krogoth and the following configuration for the archiver: > >> > >> INHERIT += „archiver“ > >> COPYLEFT_RECIPE_TYPES = ’target’ > >> > >> But the ‚tmp/deploy/sources/…/‚ folder for my target architecture contains > >> much more packages then those ‚used‘ to build my image. > >> Is there a way to extract / archive / isolate only those package sources > >> used for a certain image (kernel + rootfs) ? > >> > >> Thanks for your help, > >> David > >> -- > >> ___ > >> 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] How to create a signed bootloader and Linux kernel on a UEFI BIOS
Hello, Securing the full boot chain on a UEFI BIOS such as those provided on Intel platforms is possible but not that simple. Working, detailed documentation is not easy to find anywhere. Some of my students from Lorient (University of South Brittany) have done a good documentation job on a HowTo create and boot a signed kernel and Grub2 on a UEFI BIOS. As it could be useful to some of you, I share the link. https://ubs_csse.gitlab.io/secu_os/tutorials/linux_secure_boot.html Thanks to Romain Brenaget, Jerôme Blanchard and Pierre Fontaine from the Master1 in Embedded Cyber Security. fontaine.e1800...@etud.univ-ubs.fr brenaget.e1803...@etud.univ-ubs.fr blanchard.e1804...@etud.univ-ubs.fr -- Dominig ar Foll Senior Software Architect Intel Open Source Technology Centre -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] RDEPENDS and do_rootfs
Forgot to say, Bitbake's dependency model is loosely based on Debian's so the Debian Policy is a good read for semantics: https://www.debian.org/doc/debian-policy/ch-relationships.html#binary-dependencies-depends-recommends-suggests-enhances-pre-depends Debian's "Depends" is our "RDEPENDS", what you want is "Pre-Depends" that we don't (yet) support. As I said, this is just a matter of picking a name and then mapping it into the control file. Ross On Thu, 31 Jan 2019 at 10:49, Burton, Ross wrote: > > Presumably the problem here is that you've a maintainer script > (preinst or postinst) in B that needs a binary/library from A, and is > failing because B's postinst is running before A is unpacked? If not, > please clarify, otherwise the problem is that DEPENDS just talks about > the final solution. If you want to express that A needs to be > installed and configured before B is configured then you'll need to > use Pre-Depends, which I don't believe are actually supported in the > packaging classes yet. I know that dpkg and opkg support this, and > presumably rpm too, so extending the packaging classes is a few > minutes work. > > Ross > > On Thu, 31 Jan 2019 at 06:51, Darcy Watkins > wrote: > > > > Hi, > > > > Can someone knowledgeable with the inner workings of the build system > > please confirm... > > > > IF package B has RDEPENDS on package A > > > > THEN during do_rootfs task, package A will always be installed into > > rootfs first AND the post-inst scripts of package A will always be run > > prior to those for package B. > > > > Also, if that can be confirmed for 'daisy' branch, that would really be > > helpful. If not, then please mention as far back the branch that you > > know for sure. Thanks! > > > > > > > > -- > > > > > > Regards, > > > > Darcy > > > > Darcy Watkins :: Senior Staff Engineer, Firmware > > > > SIERRA > > WIRELESS > > Direct +1 604 233 7989 :: Fax +1 604 231 1109 :: Main + > > 1 604 231 1100 > > 13811 Wireless Way :: Richmond, BC Canada V6V 3A4 > > [P1] > > > > dwatk...@sierrawireless.com :: www.sierrawireless.com > > > > > > > > -- > > ___ > > 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] RDEPENDS and do_rootfs
On Thu, 31 Jan 2019 at 07:01, Hopp, Denis wrote: > I cannot assure you of that specific case but to my understanding you could > find out with the taskexp: > > bitbake -g -u taskexp > There you will have a graphical interface to explore your package > dependencies and which task will be executed before another. Hope that helps. Those are bitbake's build-time dependencies and don't have any impact on the install order by the package manager. Ross -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] RDEPENDS and do_rootfs
Presumably the problem here is that you've a maintainer script (preinst or postinst) in B that needs a binary/library from A, and is failing because B's postinst is running before A is unpacked? If not, please clarify, otherwise the problem is that DEPENDS just talks about the final solution. If you want to express that A needs to be installed and configured before B is configured then you'll need to use Pre-Depends, which I don't believe are actually supported in the packaging classes yet. I know that dpkg and opkg support this, and presumably rpm too, so extending the packaging classes is a few minutes work. Ross On Thu, 31 Jan 2019 at 06:51, Darcy Watkins wrote: > > Hi, > > Can someone knowledgeable with the inner workings of the build system > please confirm... > > IF package B has RDEPENDS on package A > > THEN during do_rootfs task, package A will always be installed into > rootfs first AND the post-inst scripts of package A will always be run > prior to those for package B. > > Also, if that can be confirmed for 'daisy' branch, that would really be > helpful. If not, then please mention as far back the branch that you > know for sure. Thanks! > > > > -- > > > Regards, > > Darcy > > Darcy Watkins :: Senior Staff Engineer, Firmware > > SIERRA > WIRELESS > Direct +1 604 233 7989 :: Fax +1 604 231 1109 :: Main + > 1 604 231 1100 > 13811 Wireless Way :: Richmond, BC Canada V6V 3A4 > [P1] > > dwatk...@sierrawireless.com :: www.sierrawireless.com > > > > -- > ___ > 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] [oe] OE Summit @ SCaLE 17x - Sunday March 10th 2019 - Pasadena CA
On Thu, Jan 31, 2019 at 8:26 AM Trevor Woerner wrote: > > We're excited to announce the inaugural "OpenEmbedded Summit" taking place > Sunday March 10th 2019 as part of the Southern California Linux Expo > (SCaLE) 17x at the Pasadena Convention Center. > > For the past few years there's been an ever-growing OpenEmbedded event as > part of SCaLE. This year, with the missing Spring ELC, we felt it was time > to do something more "formally" so OE enthusiasts could get together > without having to wait until August. > > The initial suggestion for this summit came at last year's OEDEM in > Edinburgh. At that time an idea was also floated to hold this year's OEDAM > at the same time. Just to be absolutely clear: this suggestion was > rejected; there will be no OEDAM at the OE Summit at SCaLE 17x. However, > this summit is taking place with the full approval of the OpenEmbedded > Board of Directors, many of whom have also been helping out with its > organization. > > The schedule for the OE Summit has been posted: > https://www.socallinuxexpo.org/scale/17x/schedule/sunday > https://www.socallinuxexpo.org/scale/17x/open-embedded-summit-0 To whoever can double check and fix the schedule... it looks like there's a typo at the second link, where Alistair's talk is listed twice. From the first link "Lokesh Kumar Goel OpenEmbedded in LG Products" should be at 11.30am instead. > > So if you're in the Southern California area, or are generally interested > in hanging out with some OpenEmbedded people, please join us in Pasadena on > March 10th! > > Your OE Summit organizing committee: > Tom King > Behan Webster > Trevor Woerner > -- > ___ > Openembedded-devel mailing list > openembedded-de...@lists.openembedded.org > http://lists.openembedded.org/mailman/listinfo/openembedded-devel -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] pcre-config replacement
On Thu, 31 Jan 2019 at 00:14, Chuck Wolber wrote: > What is the recommended packaging approach for an upstream configure script > that seems to think that it must have pcre-config (which is disabled by the > binconfig-disabled class)? > > Looking at the source of the upstream package seems to indicate that they > actually do need pcre, so this is not as simple as patching the configure > script. pkg-config. Inherit the pkgconfig class in the recipe if it doesn't already, and see for example meta/recipes-devtools/swig/swig/0001-configure-use-pkg-config-for-pcre-detection.patch in oe-core for an example. This is an upstreamable change so ideally submit it upstream so you don't have to carry a patch around too. Ross -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] How to archive only packages contained in a certain image
Does it not just contain the packages used to build the entire image, so build-time dependents. Can you give an example of a recipe that is archived but shouldn't be? Ross On Thu, 31 Jan 2019 at 08:46, David Zimmermann wrote: > > Hi List, > > I use Yocto Krogoth and the following configuration for the archiver: > > INHERIT += „archiver“ > COPYLEFT_RECIPE_TYPES = ’target’ > > But the ‚tmp/deploy/sources/…/‚ folder for my target architecture contains > much more packages then those ‚used‘ to build my image. > Is there a way to extract / archive / isolate only those package sources used > for a certain image (kernel + rootfs) ? > > Thanks for your help, > David > -- > ___ > 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] How to archive only packages contained in a certain image
Hi List, I use Yocto Krogoth and the following configuration for the archiver: INHERIT += „archiver“ COPYLEFT_RECIPE_TYPES = ’target’ But the ‚tmp/deploy/sources/…/‚ folder for my target architecture contains much more packages then those ‚used‘ to build my image. Is there a way to extract / archive / isolate only those package sources used for a certain image (kernel + rootfs) ? Thanks for your help, David -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
