Re: [yocto] SELinux with Busybox on morty
Hi Marco,
On similar lines, as Joe suggested please try with refpolicy 2.20151208
from morty,
also I would like to recommend start with refpolicy-minimum policy variant,
then you can explore other variants like refpolicy-targeted.
On Mon, Jul 24, 2017 at 1:15 PM, Marco Ostini wrote:
>
> Hi Joe & Shrikant,
>
> Many thanks for your response. It was good to know that busybox can
function with SELinux enforcing enabled.
>
I also confirm busybox works fine with enforcing mode on minimum variant,
used it in multiple ways.
> Sorry not to mention the policy we're currently using. It's:
>refpolicy-targeted
>
> ||/ NameVersion Architecture
Description
>
+++-===---
> ii refpolicy-targeted git-r0 amd64
SELinux targeted policy
>
> We'll build policy based on 2.20151208 and give it a try to see how it
behaves.
>
> It appears to me that policy itself is responsible for semanage not
functioning. When I try:
>
>semanage -v port -l
>
> I see errors like this:
>
> 1088. 07/24/17 07:29:46 semanage
unconfined_u:unconfined_r:semanage_t:s0-s0:c0.c1023 2 dir write
system_u:object_r:lib_t:s0 denied 1095
> 1089. 07/24/17 07:29:46 semanage
unconfined_u:unconfined_r:semanage_t:s0-s0:c0.c1023 2 dir write
system_u:object_r:lib_t:s0 denied 1096
>
> or
>
> time->Mon Jul 24 07:29:46 2017
> type=PROCTITLE msg=audit(1500881386.907:1101):
proctitle=2F7573722F62696E2F707974686F6E002D4573002F7573722F7362696E2F73656D616E616765002D7600706F7274002D6C
> type=SYSCALL msg=audit(1500881386.907:1101): arch=c03e syscall=2
success=no exit=-13 a0=7ddf20 a1=2c1 a2=81a4 a3=5640003640100 items=0
ppid=496 pid=1201 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0
fsgid=0 tty=pts0 ses=1 comm="semanage" exe="/usr/bin/python2.7"
subj=unconfined_u:unconfined_r:semanage_t:s0-s0:c0.c1023 key=(null)
> type=AVC msg=audit(1500881386.907:1101): avc: denied { write } for
pid=1201 comm="semanage" name="sepolgen" dev="vda" ino=6091
scontext=unconfined_u:unconfined_r:semanage_t:s0-s0:c0.c1023
tcontext=system_u:object_r:lib_t:s0 tclass=dir permissive=0
>
> The majority of the errors however are related to start_getty:
>
> 142. 07/24/17 06:14:04 start_getty system_u:system_r:getty_t:s0 4 dir
search system_u:object_r:default_t:s0 denied 149
>
> time->Mon Jul 24 07:34:21 2017
> type=PROCTITLE msg=audit(1500881661.906:1160):
proctitle=2F62696E2F7368002F62696E2F73746172745F676574747900313135323030007474795330
> type=SYSCALL msg=audit(1500881661.906:1160): arch=c03e syscall=59
success=no exit=-13 a0=6fca60 a1=6fcc40 a2=6faf90 a3=59a items=0 ppid=1244
pid=1246 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0
fsgid=0 tty=(none) ses=4294967295 comm="start_getty" exe="/bin/bash"
subj=system_u:system_r:getty_t:s0 key=(null)
> type=AVC msg=audit(1500881661.906:1160): avc: denied { search } for
pid=1246 comm="start_getty" name="sbin" dev="vda" ino=7236
scontext=system_u:system_r:getty_t:s0
tcontext=system_u:object_r:default_t:s0 tclass=dir permissive=0
>
> I've applied an appropriate context to start_getty, but that didn't
prevent the errors:
>
> ls -alZ /bin/start_getty
> -rwxr-xr-x. 1 root root system_u:object_r:getty_exec_t:s0 99 Jul 21 02:55
/bin/start_getty
>
> start_getty is a shell script that points back to /sbin/getty which is a
symlink to /usr/lib/busybox/sbin/getty
>
> So I applied a context to /usr/lib/busybox/sbin/getty without it
preventing the above mentioned errors:
>
> ls -alZ /usr/lib/busybox/sbin/getty
> -rwxr-xr-x. 1 root root system_u:object_r:getty_exec_t:s0 21 Jun 9 03:39
/usr/lib/busybox/sbin/getty
>
I think you are trying to patch the policy Or fixing the avc denials w.r.to
context,
To do it, we have audit tools available from meta-selinux which will help
to understand the avc denials in detail,
please try using audit2why on avc denials to get why we hit with denials.
& further using audit2allow to generate the allow rules based on current
policy & then try with generated allow rules.
Hope it helps :)
> I'm keen to see how policy based on 2.20151208 will look.
>
> Additional to trying 2.20151208 if you have any suggestions or advice I'd
be grateful to hear it.
Please start exploring with refpolicy-minimum..
>
> Cheers,
> Marco
>
>
Thanks
Shrikant
>
> On 22 July 2017 at 05:46, Joe MacDonald wrote:
>>
>> Hi Justin / Marco,
>>
>> [Re: SELinux with Busybox on morty] On 17.07.19 (Wed 16:05) Justin
Clacherty wrote:
>>
>> > Hi Joe,
>> >
>> > Is this something you or one of the other meta-selinux devs are able
>> > to help out with or is it more of an upstream question?
>>
>> I'll see if I can give this a shot. :-)
>>
>> >
>> > Cheers,
>> > Justin.
>> >
>> >
>> > > On 17 Jul 2017, at 4:57 pm, Marco Ostini wrote:
>> > >
>> > >
>> > > Hi All,
>> > >
>> > > At the moment I'm attempting to prepare a VM of
[yocto] [Error] Conflict between meta and meta-freescale layer
Dear all, I am trying to compile a core-image-minimal, using the 4.1-2.0 Kernel version. I am using the meta-freescale layer upon meta and meta-bsp layers. I keep getting the ERROR: Multiple .bb files are due to be built which each provide cryptodev-linux. I already tried to wipe out the output / sstatechache dir, and call clean -c , and also cleansstate. The conflict is between: /home/vroriz/poky/meta-freescale/recipes-kernel/cryptodev/cryptodev-qoriq- linux_1.8.bb /home/vroriz/poky/meta/recipes-kernel/cryptodev/cryptodev-linux_1.8.bb The output for tracing is: A list of tasks depending on these providers is shown and may help explain where the dependency comes from. /home/vroriz/poky/meta-freescale/recipes-kernel/cryptodev/cryptodev-qoriq- linux_1.8.bb has unique dependees: /home/vroriz/poky/meta/recipes-kernel/cryptodev/cryptodev-linux_1.8.bb:do_ build /home/vroriz/poky/meta/recipes-kernel/cryptodev/cryptodev-linux_1.8.bb:do_ package_qa /home/vroriz/poky/meta/recipes-kernel/cryptodev/cryptodev-linux_1.8.bb:do_ package_write_rpm /home/vroriz/poky/meta/recipes-kernel/cryptodev/cryptodev-linux_1.8.bb has unique dependees: /home/vroriz/poky/meta/recipes-connectivity/openssl/openssl_1.0.2j.bb: do_package /home/vroriz/poky/meta/recipes-connectivity/openssl/openssl_1.0.2j.bb: do_configure /home/vroriz/poky/meta/recipes-core/images/core-image-minimal.bb:do_image It could be that one recipe provides something the other doesn't and should. The following provider and runtime provider differences may be helpful. /home/vroriz/poky/meta-freescale/recipes-kernel/cryptodev/cryptodev-qoriq- linux_1.8.bb has unique provides: cryptodev-qoriq-linux /home/vroriz/poky/meta-freescale/recipes-kernel/cryptodev/cryptodev-qoriq- linux_1.8.bb has unique rprovides: cryptodev-qoriq-linux-doc cryptodev-qoriq-linux cryptodev-qoriq-linux-staticdev cryptodev-qoriq-linux-locale cryptodev-qoriq-linux-dbg cryptodev-qoriq-linux-dev ^cryptodev-qoriq-linux-locale-.* /home/vroriz/poky/meta/recipes-kernel/cryptodev/cryptodev-linux_1.8.bb has unique provides: /home/vroriz/poky/meta/recipes-kernel/cryptodev/cryptodev-linux_1.8.bb has unique rprovides: ^cryptodev-linux-locale-.* BR, Vitor Roriz -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] Perforce fetcher ignores module and label
Hi,
I'm upgrading a recipe that fetches the source code from Perforce.
The old recipe was:
SRC_URI = " \
p4://${P4USER}:${P4PASSWD}:${P4HOST}:${P4PORT}@Depot/path/
perforce/...;module=local/path/relativeto/p4;label=${P4CHANGELIST} \
"
With the new version of /lib/bb/fetch2/perforce.py, I had to set P4PORT
outside SRC_URI, leaving the recipe with:
SRC_URI = " \
p4://${P4USER}:${P4PASSWD}@Depot/path/perforce/...;
module=local/path/relativeto/p4;label=${P4CHANGELIST} \
"
The Perforce fetcher kind of works, but it seems to be ignoring the
"module" and the "label" attributes. After reading the Python script I can
see that after the "@", only the substring before the first ";" is used.
Is there a way to set module and label/changelist? I have several folders
per recipe that I need to map to different subfolders and with the current
script some of the folders don't get fetched.
Thanks for your time.
Regards,
Katu
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[yocto] Eclipse Yocto Plugin: Breaks Customize Prespective
Hi, I have noticed that when installing the Yocto Eclipse Plugin in Eclipse Neon (Ubuntu 16.04), I don't have access to the "Customize Prespective" in Eclipse any more. I'm installing from http://downloads.yoctoproject.org/releases/eclipse-plugin/2.3.1/ My plugin setup points to /opt/poky/2.3 and /opt/poky/2.3/sysroots and I'm debugging with real hw. If I uninstall the plugin, it comes back. Is there a workaround this? Regards, Katu -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] Migrating from krogoth to morty (can't boot fitImage)
I'm trying to migrate my krogoth environment to morty. I have custom recipes for u-boot and kernel; the only change necessary to build under morty was to patch u-boot for gcc6 - other than that the source versions and configs used are the same. On krogoth I can boot a fitImage kernel, but not on morty. (uImage works on both). Looking at the image info on the morty image, it looks like the load/entry addresses are completely wrong. On krogoth: U-Boot > iminfo ## Checking Image at 1800 ... FIT image found FIT description: U-Boot fitImage for Image 0 (kernel@1) Description: Linux kernel Type: Kernel Image Compression: uncompressed Data Start: 0x18e8 Data Size:3304552 Bytes = 3.2 MiB Architecture: ARM OS: Linux Load Address: 0x10008000 Entry Point: 0x10008000 Hash algo:sha1 Hash value: 10a220564569205b11febba4b7e2809395bfee9c Image 1 (fdt@1) Description: Flattened Device Tree blob Type: Flat Device Tree Compression: uncompressed Data Start: 0x18326e44 Data Size:38269 Bytes = 37.4 KiB Architecture: ARM Hash algo:sha1 Hash value: 79d5eeb892ef059566c04d98cdc6b30e92a665a2 Default Configuration: 'conf@1' Configuration 0 (conf@1) Description: Boot Linux kernel with FDT blob Kernel: kernel@1 FDT: fdt@1 ## Checking hash(es) for FIT Image at 1800 ... Hash(es) for Image 0 (kernel@1): sha1+ Hash(es) for Image 1 (fdt@1): sha1+ On morty: U-Boot > iminfo ## Checking Image at 1800 ... FIT image found FIT description: U-Boot fitImage for Image 0 (kernel@1) Description: Linux kernel Type: Kernel Image Compression: uncompressed Data Start: 0x18e8 Data Size:3304016 Bytes = 3.2 MiB Architecture: ARM OS: Linux Load Address: 0x01314c40 <- doesn't seem like these could be correct? Entry Point: 0x01314c40 Hash algo:sha1 Hash value: e2de67793e93d854614a42994180b77e053c7302 Image 1 (fdt@1) Description: Flattened Device Tree blob Type: Flat Device Tree Compression: uncompressed Data Start: 0x18326c2c Data Size:38269 Bytes = 37.4 KiB Architecture: ARM Hash algo:sha1 Hash value: 79d5eeb892ef059566c04d98cdc6b30e92a665a2 Default Configuration: 'conf@1' Configuration 0 (conf@1) Description: Linux kernel, FDT blob Kernel: kernel@1 FDT: fdt@1 ## Checking hash(es) for FIT Image at 1800 ... Hash(es) for Image 0 (kernel@1): sha1+ Hash(es) for Image 1 (fdt@1): sha1+ Attempting to boot causes it to hang after "Loading Kernel Image ... " Anyone got any ideas what might be wrong, or where to look to track it down? (Any change to mkimage-type steps in morty?) -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Migrating from krogoth to morty (can't boot fitImage)
Hi Colin, On Tue, Jul 25, 2017 at 12:21 PM, wrote: > I'm trying to migrate my krogoth environment to morty. I have custom recipes > for u-boot and kernel; the only change necessary to build under morty was to > patch u-boot for gcc6 - other than that the source versions and configs > used are the same. > On krogoth I can boot a fitImage kernel, but not on morty. (uImage works on > both). > Looking at the image info on the morty image, it looks like the load/entry > addresses are completely wrong. Do you have those variables in your conf: UBOOT_ENTRYPOINT and UBOOT_LOADADDRESS. For details please check: meta/classes/kernel-fitimage.bbclass > > On krogoth: > U-Boot > iminfo > > ## Checking Image at 1800 ... >FIT image found >FIT description: U-Boot fitImage for > Image 0 (kernel@1) > Description: Linux kernel > Type: Kernel Image > Compression: uncompressed > Data Start: 0x18e8 > Data Size:3304552 Bytes = 3.2 MiB > Architecture: ARM > OS: Linux > Load Address: 0x10008000 > Entry Point: 0x10008000 > Hash algo:sha1 > Hash value: 10a220564569205b11febba4b7e2809395bfee9c > Image 1 (fdt@1) > Description: Flattened Device Tree blob > Type: Flat Device Tree > Compression: uncompressed > Data Start: 0x18326e44 > Data Size:38269 Bytes = 37.4 KiB > Architecture: ARM > Hash algo:sha1 > Hash value: 79d5eeb892ef059566c04d98cdc6b30e92a665a2 > Default Configuration: 'conf@1' > Configuration 0 (conf@1) > Description: Boot Linux kernel with FDT blob > Kernel: kernel@1 > FDT: fdt@1 > ## Checking hash(es) for FIT Image at 1800 ... >Hash(es) for Image 0 (kernel@1): sha1+ >Hash(es) for Image 1 (fdt@1): sha1+ > > On morty: > U-Boot > iminfo > > ## Checking Image at 1800 ... >FIT image found >FIT description: U-Boot fitImage for > Image 0 (kernel@1) > Description: Linux kernel > Type: Kernel Image > Compression: uncompressed > Data Start: 0x18e8 > Data Size:3304016 Bytes = 3.2 MiB > Architecture: ARM > OS: Linux > Load Address: 0x01314c40 <- doesn't seem like these could be > correct? > Entry Point: 0x01314c40 > Hash algo:sha1 > Hash value: e2de67793e93d854614a42994180b77e053c7302 > Image 1 (fdt@1) > Description: Flattened Device Tree blob > Type: Flat Device Tree > Compression: uncompressed > Data Start: 0x18326c2c > Data Size:38269 Bytes = 37.4 KiB > Architecture: ARM > Hash algo:sha1 > Hash value: 79d5eeb892ef059566c04d98cdc6b30e92a665a2 > Default Configuration: 'conf@1' > Configuration 0 (conf@1) > Description: Linux kernel, FDT blob > Kernel: kernel@1 > FDT: fdt@1 > ## Checking hash(es) for FIT Image at 1800 ... >Hash(es) for Image 0 (kernel@1): sha1+ >Hash(es) for Image 1 (fdt@1): sha1+ > > Attempting to boot causes it to hang after "Loading Kernel Image ... " > > Anyone got any ideas what might be wrong, or where to look to track it down? > (Any change to mkimage-type steps in morty?) > > > -- > ___ > yocto mailing list > yocto@yoctoproject.org > https://lists.yoctoproject.org/listinfo/yocto Thanks and 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] Migrating from krogoth to morty (can't boot fitImage)
> On 25 July 2017 at 12:16 Belisko Marek wrote: > > Hi Colin, > > On Tue, Jul 25, 2017 at 12:21 PM, wrote: > > > I'm trying to migrate my krogoth environment to morty. I have custom recipes > > for u-boot and kernel; the only change necessary to build under morty was to > > patch u-boot for gcc6 - other than that the source versions and configs > > used are the same. > > On krogoth I can boot a fitImage kernel, but not on morty. (uImage works on > > both). > > Looking at the image info on the morty image, it looks like the load/entry > > addresses are completely wrong. > Do you have those variables in your conf: UBOOT_ENTRYPOINT and > UBOOT_LOADADDRESS. > For details please check: meta/classes/kernel-fitimage.bbclass > Ah yes, thanks that was the problem - added UBOOT_ENTRYPOINT and it now boots. (I have my own machine defined, which borrows from meta-freescale-3rdparty/conf/machine/include/tx6-karo-common.inc - there must be some subtle difference between that and the meta-fsl-arm-extra/conf/machine/include/tx6-karo-common.inc that I was using on krogoth) -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] [meta-virtualization] [recipes-containers] criu version 2.12.1
Hi All, in attach my recipes for Criu 2.12.1. Best regards, Federico Briata --- recipes-containers/criu/criu-2.12.1+gitAUTOINC+14e0bf7baf/0002-criu-Skip-documentation-install.patch | 28 +++ recipes-containers/criu/criu-2.12.1+gitAUTOINC+14e0bf7baf/0001-criu-Fix-toolchain-hardcode.patch | 94 +++ recipes-containers/criu/criu_2.12.1.bb | 79 +++ recipes-containers/criu/criu-2.12.1+gitAUTOINC+14e0bf7baf/0001-criu-Change-libraries-install-directory.patch | 24 ++ 4 files changed, 225 insertions(+), 0 deletions(-) diff --git a/recipes-containers/criu/criu-2.12.1+gitAUTOINC+14e0bf7baf/0001-criu-Change-libraries-install-directory.patch b/recipes-containers/criu/criu-2.12.1+gitAUTOINC+14e0bf7baf/0001-criu-Change-libraries-install-directory.patch new file mode 100644 index 000..88efba3 --- /dev/null +++ b/recipes-containers/criu/criu-2.12.1+gitAUTOINC+14e0bf7baf/0001-criu-Change-libraries-install-directory.patch @@ -0,0 +1,24 @@ +diff --git a/Makefile.install b/Makefile.install +index 7f867cf..15b6065 100644 +--- a/Makefile.install b/Makefile.install +@@ -8,19 +8,6 @@ LIBDIR:= $(PREFIX)/lib + INCLUDEDIR:= $(PREFIX)/include + LIBEXECDIR:= $(PREFIX)/libexec + +-# +-# For recent Debian/Ubuntu with multiarch support. +-DEB_HOST_MULTIARCH := $(shell dpkg-architecture -qDEB_HOST_MULTIARCH 2>/dev/null) +-ifneq "$(DEB_HOST_MULTIARCH)" "" +-LIBDIR:= $(PREFIX)/lib/$(DEB_HOST_MULTIARCH) +-else +-# +-# For most other systems +-ifeq "$(shell uname -m)" "x86_64" +-LIBDIR:= $(PREFIX)/lib64 +-endif +-endif +- + export PREFIX BINDIR SBINDIR MANDIR + export LIBDIR INCLUDEDIR LIBEXECDIR + diff --git a/recipes-containers/criu/criu-2.12.1+gitAUTOINC+14e0bf7baf/0001-criu-Fix-toolchain-hardcode.patch b/recipes-containers/criu/criu-2.12.1+gitAUTOINC+14e0bf7baf/0001-criu-Fix-toolchain-hardcode.patch new file mode 100644 index 000..1e1437d --- /dev/null +++ b/recipes-containers/criu/criu-2.12.1+gitAUTOINC+14e0bf7baf/0001-criu-Fix-toolchain-hardcode.patch @@ -0,0 +1,94 @@ +diff --git a/Makefile b/Makefile +index 79490d0..1e421b1 100644 +--- a/Makefile b/Makefile +@@ -54,7 +54,7 @@ LDARCH ?= $(SRCARCH) + + export SRCARCH LDARCH VDSO + +-UNAME-M := $(shell uname -m) ++UNAME-M ?= $(shell uname -m) + export UNAME-M + + ifeq ($(ARCH),arm) +diff --git a/criu/pie/Makefile b/criu/pie/Makefile +index 141c018..09dbdc6 100644 +--- a/criu/pie/Makefile b/criu/pie/Makefile +@@ -17,7 +17,7 @@ restorer-obj-e += ./$(ARCH_DIR)/syscalls.built-in.o + # + CFLAGS:= $(filter-out -pg $(CFLAGS-GCOV),$(CFLAGS)) + CFLAGS+= -iquote $(SRC_DIR)/criu/pie/piegen +-CFLAGS+= -iquote $(SRC_DIR)/criu/arch/$(ARCH)/include ++CFLAGS+= -iquote $(SRC_DIR)/criu/arch/$(SRCARCH)/include + CFLAGS+= -iquote $(SRC_DIR)/criu/include + CFLAGS+= -iquote $(SRC_DIR)/include + CFLAGS+= -iquote $(SRC_DIR) +diff --git a/scripts/nmk/scripts/include.mk b/scripts/nmk/scripts/include.mk +index 711b9da..3d44624 100644 +--- a/scripts/nmk/scripts/include.mk b/scripts/nmk/scripts/include.mk +@@ -20,7 +20,7 @@ SUBARCH := $(shell uname -m | sed \ + -e s/aarch64.*/arm64/) + + ARCH ?= $(SUBARCH) +-SRCARCH := $(ARCH) ++SRCARCH ?= $(ARCH) + + export SUBARCH ARCH SRCARCH + +diff --git a/scripts/nmk/scripts/tools.mk b/scripts/nmk/scripts/tools.mk +index 56dba84..1698821 100644 +--- a/scripts/nmk/scripts/tools.mk b/scripts/nmk/scripts/tools.mk +@@ -2,30 +2,30 @@ ifndef nmk_defined__tools + + # + # System tools shorthands +-RM:= rm -f ++RM?= rm -f + HOSTLD?= ld +-LD:= $(CROSS_COMPILE)$(HOSTLD) ++LD?= $(CROSS_COMPILE)$(HOSTLD) + HOSTCC?= gcc +-CC:= $(CROSS_COMPILE)$(HOSTCC) +-CPP := $(CC) -E +-AS:= $(CROSS_COMPILE)as +-AR:= $(CROSS_COMPILE)ar +-STRIP := $(CROSS_COMPILE)strip +-OBJCOPY := $(CROSS_COMPILE)objcopy +-OBJDUMP := $(CROSS_COMPILE)objdump +-NM:= $(CROSS_COMPILE)nm +-MAKE := make +-MKDIR := mkdir -p +-AWK := awk +-PERL := perl +-PYTHON:= python +-FIND := find +-SH:= $(shell if [ -x "$$BASH" ]; then echo $$BASH;\ ++CC?= $(CROSS_COMPILE)$(HOSTCC) ++CPP ?= $(CC) -E ++AS?= $(CROSS_COMPILE)as ++AR?= $(CROSS_COMPILE)ar ++STRIP ?= $(CROSS_COMPILE)strip ++OBJCOPY ?= $(CROSS_COMPILE)objcopy ++OBJDUMP ?= $(CROSS_COMPILE)objdump ++NM?= $(CROSS_COMPILE)n
Re: [yocto] How do I write a yocto/bitbake recipe to replace the default vsftpd.conf file with my own file?
FYI, "recipetool appendfile" can help you create this. See the
"recipetool appendfile --help" output for details.
Cheers,
Paul
On Monday, 24 July 2017 11:27:17 AM CEST Burton, Ross wrote:
> The package that generates will conflict with the real one.
>
> Write a bbappend for the recipe you want to replace the files in, add the
> files to SRC_URI, and use do_install_append() to overwrite the files in
> ${D}.
>
> Ross
>
> On 24 July 2017 at 06:26, Bacheh Karaji wrote:
>
> > Hi,
> > I want to replace the default vsftpd.conf file with my own file!
> > My bitbake file looks following:
> >
> > bbexample_1.0.bb
> > DESCRIPTION = "Configuration and extra files for TX28"
> > LICENSE = "CLOSED"
> > LIC_FILES_CHKSUM = ""
> >
> > S = "${WORKDIR}"
> >
> > SRC_URI += " \
> > file://ld.so.conf \
> > file://vsftpd.conf \
> > file://nginx/nginx.conf \
> > file://init.d/myscript.sh"
> >
> > inherit allarch
> >
> > do_install () {
> > install -d ${D}${sysconfdir}
> > install -d ${D}${sysconfdir}/nginx
> > install -d ${D}${sysconfdir}/init.d
> > rm -f ${D}${sysconfdir}/ld.so.conf
> > rm -f ${D}${sysconfdir}/vsftpd.conf
> > install -m 0755 ${WORKDIR}/ld.so.conf ${D}${sysconfdir}
> > install -m 0755 ${WORKDIR}/vsftpd.conf ${D}${sysconfdir}
> > install -m 0755 ${WORKDIR}/nginx/nginx.conf
> > ${D}${sysconfdir}/nginx/
> > install -m 0755 ${WORKDIR}/init.d/myscript.sh
> > ${D}${sysconfdir}/init.d/
> > }
> >
> > But, the file could not be replaced!
> > What is wrong?
> >
> > --
> > ___
> > yocto mailing list
> > yocto@yoctoproject.org
> > https://lists.yoctoproject.org/listinfo/yocto
> >
> >
>
--
Paul Eggleton
Intel Open Source Technology Centre
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [meta-virtualization] [recipes-containers] criu version 2.12.1
Hi Frederico, Thanks for the patch, but this needs to go to the meta-virtualization list. Also, we carry a _git recipe in meta-virt to track the various releases (and sometimes points in between). So this patch should be done against that recipe versus creating a new versioned variant. Finally, make sure to check the patch submission guidelines, since this patch doesn't have a proper commit log or a Signed-off-by. Cheers, Bruce On Tue, Jul 25, 2017 at 8:26 AM, Federico Pietro Briata wrote: > Hi All, > > in attach my recipes for Criu 2.12.1. > > Best regards, > > Federico Briata > > > --- > > recipes-containers/criu/criu-2.12.1+gitAUTOINC+14e0bf7baf/0002-criu-Skip-documentation-install.patch > | 28 +++ > > recipes-containers/criu/criu-2.12.1+gitAUTOINC+14e0bf7baf/0001-criu-Fix-toolchain-hardcode.patch > | 94 +++ > recipes-containers/criu/criu_2.12.1.bb > | 79 +++ > > recipes-containers/criu/criu-2.12.1+gitAUTOINC+14e0bf7baf/0001-criu-Change-libraries-install-directory.patch > | 24 ++ > 4 files changed, 225 insertions(+), 0 deletions(-) > > diff --git > a/recipes-containers/criu/criu-2.12.1+gitAUTOINC+14e0bf7baf/0001-criu-Change-libraries-install-directory.patch > > b/recipes-containers/criu/criu-2.12.1+gitAUTOINC+14e0bf7baf/0001-criu-Change-libraries-install-directory.patch > new file mode 100644 > index 000..88efba3 > --- /dev/null > +++ > b/recipes-containers/criu/criu-2.12.1+gitAUTOINC+14e0bf7baf/0001-criu-Change-libraries-install-directory.patch > @@ -0,0 +1,24 @@ > +diff --git a/Makefile.install b/Makefile.install > +index 7f867cf..15b6065 100644 > +--- a/Makefile.install > b/Makefile.install > +@@ -8,19 +8,6 @@ LIBDIR := $(PREFIX)/lib > + INCLUDEDIR := $(PREFIX)/include > + LIBEXECDIR := $(PREFIX)/libexec > + > +-# > +-# For recent Debian/Ubuntu with multiarch support. > +-DEB_HOST_MULTIARCH := $(shell dpkg-architecture -qDEB_HOST_MULTIARCH > 2>/dev/null) > +-ifneq "$(DEB_HOST_MULTIARCH)" "" > +-LIBDIR := $(PREFIX)/lib/$(DEB_HOST_MULTIARCH) > +-else > +-# > +-# For most other systems > +-ifeq "$(shell uname -m)" "x86_64" > +-LIBDIR := $(PREFIX)/lib64 > +-endif > +-endif > +- > + export PREFIX BINDIR SBINDIR MANDIR > + export LIBDIR INCLUDEDIR LIBEXECDIR > + > diff --git > a/recipes-containers/criu/criu-2.12.1+gitAUTOINC+14e0bf7baf/0001-criu-Fix-toolchain-hardcode.patch > > b/recipes-containers/criu/criu-2.12.1+gitAUTOINC+14e0bf7baf/0001-criu-Fix-toolchain-hardcode.patch > new file mode 100644 > index 000..1e1437d > --- /dev/null > +++ > b/recipes-containers/criu/criu-2.12.1+gitAUTOINC+14e0bf7baf/0001-criu-Fix-toolchain-hardcode.patch > @@ -0,0 +1,94 @@ > +diff --git a/Makefile b/Makefile > +index 79490d0..1e421b1 100644 > +--- a/Makefile > b/Makefile > +@@ -54,7 +54,7 @@ LDARCH ?= $(SRCARCH) > + > + export SRCARCH LDARCH VDSO > + > +-UNAME-M := $(shell uname -m) > ++UNAME-M ?= $(shell uname -m) > + export UNAME-M > + > + ifeq ($(ARCH),arm) > +diff --git a/criu/pie/Makefile b/criu/pie/Makefile > +index 141c018..09dbdc6 100644 > +--- a/criu/pie/Makefile > b/criu/pie/Makefile > +@@ -17,7 +17,7 @@ restorer-obj-e += > ./$(ARCH_DIR)/syscalls.built-in.o > + # > + CFLAGS := $(filter-out -pg $(CFLAGS-GCOV),$(CFLAGS)) > + CFLAGS += -iquote $(SRC_DIR)/criu/pie/piegen > +-CFLAGS += -iquote $(SRC_DIR)/criu/arch/$(ARCH)/include > ++CFLAGS += -iquote > $(SRC_DIR)/criu/arch/$(SRCARCH)/include > + CFLAGS += -iquote $(SRC_DIR)/criu/include > + CFLAGS += -iquote $(SRC_DIR)/include > + CFLAGS += -iquote $(SRC_DIR) > +diff --git a/scripts/nmk/scripts/include.mk b/scripts/nmk/scripts/include.mk > +index 711b9da..3d44624 100644 > +--- a/scripts/nmk/scripts/include.mk > b/scripts/nmk/scripts/include.mk > +@@ -20,7 +20,7 @@ SUBARCH := $(shell uname -m | sed \ > + -e s/aarch64.*/arm64/) > + > + ARCH?= $(SUBARCH) > +-SRCARCH := $(ARCH) > ++SRCARCH ?= $(ARCH) > + > + export SUBARCH ARCH SRCARCH > + > +diff --git a/scripts/nmk/scripts/tools.mk b/scripts/nmk/scripts/tools.mk > +index 56dba84..1698821 100644 > +--- a/scripts/nmk/scripts/tools.mk > b/scripts/nmk/scripts/tools.mk > +@@ -2,30 +2,30 @@ ifndef nmk_defined__tools > + > + # > + # System tools shorthands > +-RM := rm -f > ++RM ?= rm -f > + HOSTLD ?= ld > +-LD := $(CROSS_COMPILE)$(HOSTLD) > ++LD ?= $(CROSS_COMPILE)$(HOSTLD) > + HOSTCC ?= gcc > +-CC := $(CROSS_COMPILE)$(HOSTCC) > +-CPP := $(CC) -E > +-AS := $(CROSS_COMPILE)as > +-AR := $(CROSS_COMP
Re: [yocto] [Error] Conflict between meta and meta-freescale layer
On Tue, Jul 25, 2017 at 1:29 AM, vr roriz wrote: > Dear all, > > I am trying to compile a core-image-minimal, using the 4.1-2.0 Kernel > version. I am using the meta-freescale layer upon meta and meta-bsp layers. > I keep getting the ERROR: Multiple .bb files are due to be built which each > provide cryptodev-linux. I already tried to wipe out the output / > sstatechache dir, and call clean -c , and also cleansstate. > > The conflict is between: > > /home/vroriz/poky/meta-freescale/recipes-kernel/cryptodev/cryptodev-qoriq-linux_1.8.bb > /home/vroriz/poky/meta/recipes-kernel/cryptodev/cryptodev-linux_1.8.bb > I guess you need to select one of these two via preferred provider or make sure that explicit dependencies on each one of them are addressed to point to say cryptodev-linux only, then make sure cryptodev-qoriq-linux PROVIDES cryptodev-linux in local.conf you can set PREFERRED_PROVIDER_cryptodev-linux = "cryptodev-qoriq-linu" > The output for tracing is: > A list of tasks depending on these providers is shown and may help explain > where the dependency comes from. > /home/vroriz/poky/meta-freescale/recipes-kernel/cryptodev/cryptodev-qoriq-linux_1.8.bb > has unique dependees: > > /home/vroriz/poky/meta/recipes-kernel/cryptodev/cryptodev-linux_1.8.bb:do_build > > /home/vroriz/poky/meta/recipes-kernel/cryptodev/cryptodev-linux_1.8.bb:do_package_qa > > /home/vroriz/poky/meta/recipes-kernel/cryptodev/cryptodev-linux_1.8.bb:do_package_write_rpm > /home/vroriz/poky/meta/recipes-kernel/cryptodev/cryptodev-linux_1.8.bb has > unique dependees: > > /home/vroriz/poky/meta/recipes-connectivity/openssl/openssl_1.0.2j.bb:do_package > > /home/vroriz/poky/meta/recipes-connectivity/openssl/openssl_1.0.2j.bb:do_configure > /home/vroriz/poky/meta/recipes-core/images/core-image-minimal.bb:do_image > It could be that one recipe provides something the other doesn't and should. > The following provider and runtime provider differences may be helpful. > /home/vroriz/poky/meta-freescale/recipes-kernel/cryptodev/cryptodev-qoriq-linux_1.8.bb > has unique provides: > cryptodev-qoriq-linux > /home/vroriz/poky/meta-freescale/recipes-kernel/cryptodev/cryptodev-qoriq-linux_1.8.bb > has unique rprovides: > cryptodev-qoriq-linux-doc > cryptodev-qoriq-linux > cryptodev-qoriq-linux-staticdev > cryptodev-qoriq-linux-locale > cryptodev-qoriq-linux-dbg > cryptodev-qoriq-linux-dev > ^cryptodev-qoriq-linux-locale-.* > /home/vroriz/poky/meta/recipes-kernel/cryptodev/cryptodev-linux_1.8.bb has > unique provides: > /home/vroriz/poky/meta/recipes-kernel/cryptodev/cryptodev-linux_1.8.bb has > unique rprovides: > ^cryptodev-linux-locale-.* > > BR, > Vitor Roriz > > -- > ___ > 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] Problems with 'configure' on own recipe [after moving to morty]
This is gonna be a bit of a hard one to describe concisely, but hoping
someone can advise me on solving it
I have a recipe of my own for an app (NetworkManager) which fetches the
source from its git repo. This recipe works on krogoth, but is throwing up
configure errors on morty.
The recipe has a
do_configure_prepend() {
( cd ${S} ; NOCONFIGURE=yes ./autogen.sh )
}
- I seemed to need this because the git source has no ABOUT-NLS; not sure
if that's the correct fix, but 'it seemed to work' before.
The final error is
| DEBUG: Executing shell function do_configure
| ln: failed to create symbolic link '/usr/share/doc/gtk-doc.make':
Permission denied
| cp: cannot create regular file '/usr/share/doc/gtk-doc.make': Permission
denied
I'm not sure why it's trying to make the symlink in the build machine's root
(as I say, it doesn't do this on krogoth)
I'm also getting a lot of:
| NOTE: Skipping setscene dependency
virtual:native:/home/colin/100051-trunk/fsl-community-bsp/sources/poky/meta/
recipes-devtools/pseudo/pseudo_1.8.1.bb:do_populate_sysroot for m4 macro
copying
- not sure if this is relevant/important
Freely admit I'm no autotools expert, so any suggestions welcome! Thanks
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Problems with 'configure' on own recipe [after moving to morty]
On 25 July 2017 at 15:08, wrote:
> This is gonna be a bit of a hard one to describe concisely, but hoping
> someone can advise me on solving it
> I have a recipe of my own for an app (NetworkManager) which fetches the
> source from its git repo. This recipe works on krogoth, but is throwing up
> configure errors on morty.
>
For a start, why not use the recipe from meta-oe?
> The recipe has a
> do_configure_prepend() {
> ( cd ${S} ; NOCONFIGURE=yes ./autogen.sh )
> }
> - I seemed to need this because the git source has no ABOUT-NLS; not sure
> if that's the correct fix, but 'it seemed to work' before.
>
If the only thing that is missing is an ABOUT-NLS file (sounds like
something gettext should have installed?) then I'd just have a prepend that
touches that file, and let autotools.bbclass invoke autoreconf for you.
> I'm also getting a lot of:
> | NOTE: Skipping setscene dependency
> virtual:native:/home/colin/100051-trunk/fsl-community-
> bsp/sources/poky/meta/
> recipes-devtools/pseudo/pseudo_1.8.1.bb:do_populate_sysroot for m4 macro
> copying
>
> - not sure if this is relevant/important
>
> Freely admit I'm no autotools expert, so any suggestions welcome! Thanks
>
That's just verbose logging from the recipe-specific-sysroot code, you can
ignore it.
Ross
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Problems with 'configure' on own recipe [after moving to morty]
> On 25 July 2017 at 15:20 "Burton, Ross" wrote:
>
> On 25 July 2017 at 15:08, wrote:
>
> > This is gonna be a bit of a hard one to describe concisely, but hoping
> > someone can advise me on solving it
> > I have a recipe of my own for an app (NetworkManager) which fetches the
> > source from its git repo. This recipe works on krogoth, but is throwing up
> > configure errors on morty.
>
> For a start, why not use the recipe from meta-oe?
>
That is in fact what I blagged as the starting point for 'my' recipe, but then
evolved it so as to use the github head. For my particular [embedded] platform
I also need to switch off some of the configure options.
> > The recipe has a
> > do_configure_prepend() {
> > ( cd ${S} ; NOCONFIGURE=yes ./autogen.sh )
> > }
> > - I seemed to need this because the git source has no ABOUT-NLS; not sure
> > if that's the correct fix, but 'it seemed to work' before.
>
> If the only thing that is missing is an ABOUT-NLS file (sounds like something
> gettext should have installed?) then I'd just have a prepend that touches
> that file, and let autotools.bbclass invoke autoreconf for you.
I'll try that
>
> > I'm also getting a lot of:
> > | NOTE: Skipping setscene dependency
> >
> > virtual:native:/home/colin/100051-trunk/fsl-community-bsp/sources/poky/meta/
> > recipes-devtools/pseudo/pseudo_1.8.1.bb:do_populate_sysroot for m4 macro
> > copying
> >
> > - not sure if this is relevant/important
> >
> > Freely admit I'm no autotools expert, so any suggestions welcome! Thanks
>
> That's just verbose logging from the recipe-specific-sysroot code, you can
> ignore it.
>
Ok, ta
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Problems with 'configure' on own recipe [after moving to morty]
On 25 July 2017 at 15:39, Colin Helliwell wrote: > That is in fact what I blagged as the starting point for 'my' recipe, but > then evolved it so as to use the github head. For my particular [embedded] > platform I also need to switch off some of the configure options. Sounds like a bbappend should be able to fiddle SRC_URI and some PACKAGECONFIGs right? Ross -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Problems with 'configure' on own recipe [after moving to morty]
Ah yes, that's true Ross - I should be able to try that approach instead. > On 25 July 2017 at 15:57 "Burton, Ross" wrote: > > On 25 July 2017 at 15:39, Colin Helliwell > wrote: > > > That is in fact what I blagged as the starting point for 'my' recipe, but > > then evolved it so as to use the github head. For my particular [embedded] > > platform I also need to switch off some of the configure options. > > Sounds like a bbappend should be able to fiddle SRC_URI and some > PACKAGECONFIGs right? > > Ross -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Problems with 'configure' on own recipe [after moving to morty]
> On 25 July 2017 at 16:00 Colin Helliwell > wrote: > > Ah yes, that's true Ross - I should be able to try that approach instead. > However there's obviously been a lot of changes from 1.4 to 1.8 and hence something to be said for a fresh recipe rather than mega-appending an older one..? (Well, there certainly would be if it worked!) And, as I say, the recipe works on krogoth [cleanly rebuilt today and definitely the same git version] - something subtly changed in some or other class perhaps, but not obvious to me. > > On 25 July 2017 at 15:57 "Burton, Ross" wrote: > > > > On 25 July 2017 at 15:39, Colin Helliwell > > wrote: > > > > > That is in fact what I blagged as the starting point for 'my' recipe, but > > > then evolved it so as to use the github head. For my particular > > > [embedded] platform I also need to switch off some of the configure > > > options. > > > > Sounds like a bbappend should be able to fiddle SRC_URI and some > > PACKAGECONFIGs right? > > -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] information on cedarview support for Yocto Poky
Hello, I am about to work in a cedarview Machine. From what I seeing online it seems that the only available support is for yocto danny. It is the cedarview supported and I’m missing the reference or the system is no longer supported? Can I consider some possible patch on poky? My target is to work on an implementation where the sw will be updated in the future and to receive further kernel update. did you have any feedback on this topic? thank you very much for your support -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] Yocto Poky meta browser issue on intel 32 image
Hello, i'm trying to integrate meta browser recipe for have a chromium instance on a intel x86 32 bit machine. i'm configuring x86 machine and i've integrated the meta-browser proposed by open-embedded 1. https://codeload.github.com/OSSystems/meta-browser/zip/master 2. https://github.com/OSSystems/meta-browser.git to test the behavior we have downloaded the chromium sample 32 bits and even that one has created issue to launch on my machine ( the same sample has been launched easily on a ubuntu 32 bits) (http://opensource.spotify.com/cefbuilds/index.html) what we are seeing is that the same recipe created with real machine 32 bits is not working on the intel device. we have a segmentation fault. is it correct to integrate this recipe? to be precise my target was to have Chromium CEF but i would accept for now to make Chromium work on the machine. i'll really appreciate you support, regards, Mauriizo Galasso -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] How do I write a yocto/bitbake recipe to replace the default vsftpd.conf file with my own filE?
Hi,
I want to replace the default vsftpd.conf file with my own file!
My bitbake file looks following:
bbexample_1.0.bb
DESCRIPTION = "Configuration and extra files for TX28"
LICENSE = "CLOSED"
LIC_FILES_CHKSUM = ""
S = "${WORKDIR}"
SRC_URI += " \
file://ld.so.conf \
file://vsftpd.conf \
file://nginx/nginx.conf \
file://init.d/myscript.sh"
inherit allarch
do_install () {
install -d ${D}${sysconfdir}
install -d ${D}${sysconfdir}/nginx
install -d ${D}${sysconfdir}/init.d
rm -f ${D}${sysconfdir}/ld.so.conf
rm -f ${D}${sysconfdir}/vsftpd.conf
install -m 0755 ${WORKDIR}/ld.so.conf ${D}${sysconfdir}
install -m 0755 ${WORKDIR}/vsftpd.conf ${D}${sysconfdir}
install -m 0755 ${WORKDIR}/nginx/nginx.conf ${D}${sysconfdir}/nginx/
install -m 0755 ${WORKDIR}/init.d/myscript.sh ${D}${sysconfdir}/init.d/
}
But, the file could not be replaced!
What is wrong?
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[yocto] Extra rebuilds when using rm_work
With both pyro and master, I have noticed that when I use 'INHERIT += “rm_work”’ I get extra rebuilds of the image rootfs. My current build uses poky rev 5686f4e1fe5229705b8c7d35895aa03827796d13 Specifically, without “rm_work”: $ . src/poky/oe-init-build-env build-rm-work $ cat >> conf/local.conf DL_DIR = "/work/dmoseley/yocto-downloads" SSTATE_DIR = "/work/dmoseley/yocto-sstate-cache" MACHINE="beaglebone" $ bitbake core-image-minimal NOTE: Tasks Summary: Attempted 2611 tasks of which 2379 didn't need to be rerun and all succeeded. $ bitbake core-image-minimal NOTE: Tasks Summary: Attempted 2611 tasks of which 2611 didn't need to be rerun and all succeeded. and again with “rm_work” $ echo 'INHERIT += "rm_work"' >> conf/local.conf $ bitbake core-image-minimal Tasks Summary: Attempted 3052 tasks of which 2390 didn't need to be rerun and all succeeded. $ bitbake core-image-minimal Tasks Summary: Attempted 3052 tasks of which 3039 didn't need to be rerun and all succeeded. $ grep NOTE:\ Running tmp/log/cooker/beaglebone/console-latest.log NOTE: Running noexec task 2577 of 3052 (/work/dmoseley/community/yocto/pyro/src/poky/meta/recipes-core/images/core-image-minimal.bb:do_fetch) NOTE: Running task 2578 of 3052 (/work/dmoseley/community/yocto/pyro/src/poky/meta/recipes-core/images/core-image-minimal.bb:do_prepare_recipe_sysroot) NOTE: Running task 3042 of 3052 (/work/dmoseley/community/yocto/pyro/src/poky/meta/recipes-core/images/core-image-minimal.bb:do_rootfs) NOTE: Running task 3043 of 3052 (/work/dmoseley/community/yocto/pyro/src/poky/meta/recipes-core/images/core-image-minimal.bb:do_image) NOTE: Running task 3044 of 3052 (/work/dmoseley/community/yocto/pyro/src/poky/meta/recipes-core/images/core-image-minimal.bb:do_image_jffs2) NOTE: Running task 3045 of 3052 (/work/dmoseley/community/yocto/pyro/src/poky/meta/recipes-core/images/core-image-minimal.bb:do_image_tar) NOTE: Running task 3046 of 3052 (/work/dmoseley/community/yocto/pyro/src/poky/meta/recipes-core/images/core-image-minimal.bb:do_rootfs_wicenv) NOTE: Running task 3047 of 3052 (/work/dmoseley/community/yocto/pyro/src/poky/meta/recipes-core/images/core-image-minimal.bb:do_image_wic) NOTE: Running task 3048 of 3052 (/work/dmoseley/community/yocto/pyro/src/poky/meta/recipes-core/images/core-image-minimal.bb:do_image_complete) NOTE: Running task 3049 of 3052 (/work/dmoseley/community/yocto/pyro/src/poky/meta/recipes-core/images/core-image-minimal.bb:do_image_qa) NOTE: Running task 3050 of 3052 (/work/dmoseley/community/yocto/pyro/src/poky/meta/recipes-core/images/core-image-minimal.bb:do_rm_work) NOTE: Running noexec task 3051 of 3052 (/work/dmoseley/community/yocto/pyro/src/poky/meta/recipes-core/images/core-image-minimal.bb:do_rm_work_all) NOTE: Running noexec task 3052 of 3052 (/work/dmoseley/community/yocto/pyro/src/poky/meta/recipes-core/images/core-image-minimal.bb:do_build) Has anyone else seen similar behavior? Drew-- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] How do I write a yocto/bitbake recipe to replace the default vsftpd.conf file with my own filE?
On 24.07.2017 07:18, Mohammad Nouri wrote:
Hi,
I want to replace the default vsftpd.conf file with my own file!
My bitbake file looks following:
bbexample_1.0.bb
DESCRIPTION = "Configuration and extra files for TX28"
LICENSE = "CLOSED"
LIC_FILES_CHKSUM = ""
S = "${WORKDIR}"
SRC_URI += " \
file://ld.so.conf \
file://vsftpd.conf \
file://nginx/nginx.conf \
file://init.d/myscript.sh"
inherit allarch
do_install () {
install -d ${D}${sysconfdir}
install -d ${D}${sysconfdir}/nginx
install -d ${D}${sysconfdir}/init.d
rm -f ${D}${sysconfdir}/ld.so.conf
rm -f ${D}${sysconfdir}/vsftpd.conf
install -m 0755 ${WORKDIR}/ld.so.conf ${D}${sysconfdir}
install -m 0755 ${WORKDIR}/vsftpd.conf ${D}${sysconfdir}
install -m 0755 ${WORKDIR}/nginx/nginx.conf ${D}${sysconfdir}/nginx/
install -m 0755 ${WORKDIR}/init.d/myscript.sh ${D}${sysconfdir}/init.d/
}
But, the file could not be replaced!
What is wrong?
you should add to your recipe :
FILES_${PN} += " list of files you installed"
--
Ayoub Zaki
ayoub.z...@embexus.com
Mobile: +49(0)176-62901545
Skype: ayoub.zaki_2
https://embexus.com
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Yocto Poky meta browser issue on intel 32 image
On Fri, Jul 21, 2017 at 7:11 AM, Maurizio Galasso wrote: > > Hello, > > > > i'm trying to integrate meta browser recipe for have a chromium instance on > a intel x86 32 bit machine. > > i'm configuring x86 machine and i've integrated the meta-browser proposed by > open-embedded > > https://codeload.github.com/OSSystems/meta-browser/zip/master > https://github.com/OSSystems/meta-browser.git > > to test the behavior we have downloaded the chromium sample 32 bits and even > that one has created issue to launch on my machine ( the same sample has > been launched easily on a ubuntu 32 bits) > (http://opensource.spotify.com/cefbuilds/index.html) > > what we are seeing is that the same recipe created with real machine 32 bits > is not working on the intel device. > we have a segmentation fault. > is it correct to integrate this recipe? > > to be precise my target was to have Chromium CEF but i would accept for now > to make Chromium work on the machine. some backtraces might help. We just punted CEF recipes, but you can resurrect them and make them work > > i'll really appreciate you support, > > regards, > > Mauriizo Galasso > > -- > ___ > 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] How to build a same package twice with different configurations for same MACHINE?
Hi,
Am 18.07.2017 um 15:24 schrieb Ngọc Thi Huỳnh:
> [...]
>
> Both images use busybox package but in different ways. The main-image
> can use several busybox' tools but the initial-flasher-image only uses
> one or two of them just to complete the flashing goal.
>
> My question is, is there a way to build busybox for main-image with one
> defconfig, then build the busybox for initial-flasher-image with a
> different defconfig when I issue "bitbake initial-flasher-image" command?
>
> [...]
I'm not aware of such a feature in BitBake. As for your situation I'd
suggest creating a secondary recipe (e.g. "busybox-flasher") in your own
layer which includes the original busybox recipe and adapts its feature
set with a configuration fragment.
Example: busybox-flasher_1.24.1.bb
require recipes-core/busybox/busybox_${PV}.bb
SRC_URI += "file://flasher-options.cfg"
That way you can easily distinguish busybox and busybox-flasher in your
images and you can minimize the redundancies between the recipes.
Hope it helps!
Best regards,
Dennis Menschel
signature.asc
Description: OpenPGP digital signature
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[yocto] Mpich and yocto ?
Dear Yocto Member, Does anyone know on how to run poky on mpich cluster ? Thanks, -- * /***/ Sent by Ubuntu LTS 16.04, Kind regards, Riko Ho /***/ * -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Mpich and yocto ?
Hi On 26.07.2017 05:12, Riko Ho wrote: Does anyone know on how to run poky on mpich cluster ? As far as I can see, MPICH is a userland library, basically. So it would be the other way round, you could probably run a mpich application on a number of nodes that run some OE/Poky thing. Greetz -- Josef Holzmayr Software Developer Embedded Systems Tel: +49 8444 9204-48 Fax: +49 8444 9204-50 R-S-I Elektrotechnik GmbH & Co. KG Woelkestrasse 11 D-85301 Schweitenkirchen www.rsi-elektrotechnik.de ——— Amtsgericht Ingolstadt – GmbH: HRB 191328 – KG: HRA 170393 Geschäftsführer: Dr.-Ing. Michael Sorg, Dipl.-Ing. Franz Sorg Ust-IdNr: DE 128592548 _ Amtsgericht Ingolstadt - GmbH: HRB 191328 - KG: HRA 170363 Geschäftsführer: Dr.-Ing. Michael Sorg, Dipl.-Ing. Franz Sorg USt-IdNr.: DE 128592548 -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [PATCH] Added missing CPPFLAGS/CFLAGS/LDFLAGS in sample recipe for morty branch
On Mon, Jul 17, 2017 at 4:48 PM, Leonardo Sandoval <
leonardo.sandoval.gonza...@linux.intel.com> wrote:
> On Mon, 2017-07-17 at 15:30 +0100, Burton, Ross wrote:
> >
> > On 17 July 2017 at 15:04, Leonardo Sandoval
> > wrote:
> > master has the second line (LDFLAGS) but not the first one
> > (CPPFLAGS and
> > CFLAGS) so the problem may also be present on master. Would
> > you mind
> > checking this and sent patches to the poky mailing list?
> >
> >
> > The GNU_HASH warning is triggered by ignoring LDFLAGS.
>
> Got it, so definitely LDFLAGS var is missing, not sure if the rest are
> necessary for this simple hello world recipe.
> Leo
>
I had this problem to and IIRC i fixed it by moving the LDFLAGS variable to
the end of the line
> + ${CC} helloworld.o -o helloworld ${LDFLAGS}
>
> >
> > Ross
>
>
Einar
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Mpich and yocto ?
How can we do that ? bitbake in which node ? I don't understand ? On 26/07/17 13:57, Josef Holzmayr wrote: Hi On 26.07.2017 05:12, Riko Ho wrote: Does anyone know on how to run poky on mpich cluster ? As far as I can see, MPICH is a userland library, basically. So it would be the other way round, you could probably run a mpich application on a number of nodes that run some OE/Poky thing. Greetz -- * /***/ Sent by Ubuntu LTS 16.04, Kind regards, Riko Ho /***/ * -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
