Re: [yocto] Per image customizations
Don't forget to add your fstab/inittab files into CONFFILES_${PN} cause if
the package that includes them will be changed and You'll update it via
package system, your POSTPROCESS hacks will be overwritten.
Anyway, its better to avoid POSTPROCESS if possible.
1) Create *.bbappend recipe base-files_%s.bbappend in your layer. It
appends to poky "base-files" recipe.
2) Create your own "python do_package_prepend" function where you should
make your recipe produce two different packages
3) Add them to DEPENDS in your image recipe
On Wed, Jun 1, 2016 at 2:57 AM, Paul Eggleton wrote:
> Hi Diego,
>
> On Tue, 31 May 2016 18:05:19 Diego wrote:
> > I've asked this question on IRC, but haven't received complete enough
> > replies, so posting here.
> >
> > I have my own layer with my recipes and customizations. In my layer I
> have
> > two images, one which is the "regular OS" that runs the product
> > application, and one which is the "flash OS", a minimal ramdisk OS that
> > flashes the disks. I want the two images to have different fstab and
> > inittab files: what is the correct way to do that? I know how to handle
> > machine / arch specific differences, but I don't think there's a way to
> > "dress a package depending on the image it gets included in", right?
> >
> > Should I create my own IMAGE_FEATURE and hack my fstab and inittab when
> > rootfs is created, sort of how the "read-only-rootfs" feature was done?
> >
> http://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/meta/classes/core-image
> .
> > bbclass?h=fido#n77
>
> You can do that, yes. The only other possibility is outright replacing the
> package providing the file (since you are free to specify whatever packages
> you want in the image, though you may have to break up
> packagegroup-core-boot
> to do it). This only works of course if either there are no dependencies on
> the package or you can satisfy any dependencies that might exist. It could
> be
> that for your "flash OS" image there aren't any, but it depends what it
> has in
> it.
>
> It may be simpler just to hack it after the fact though. Note that you
> don't
> have to add an IMAGE_FEATURES item to do that - you could simply create a
> shell/python function and add a call to it in ROOTFS_POSTPROCESS_COMMAND.
> If
> the changes to the files are substantial you could even supply the
> alternative
> files in a separate package and then move them over the top of the original
> ones in the postprocessing function to save jumping through hoops adding
> files
> to the image recipe.
>
> 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
[yocto] Fwd: Changelog creation for a list of recipes
Hi,
I believe that it would be great to have a special variable that triggers
changelog creation for the specific recipe.
For example:
PN = "my_recipe"
SRC_URI = "git://${SOME_GIT_REPO};protocol=ssh"
SRCREV = "${AUTOREV}"
PV = "1+git${SRCPV}"
CHANGELOG = "1"
This should produce ${DEPLOY_DIR}/changelog file and add there changes in
repos of specific recipes in a simple form:
For example:
my_recipe:
#5410 Add some features to my_recipe
Signed-off-by: Oleksandr Poznyak
Oleksandr Poznyak
This will make inergration of Yocto into any CI tool (Jenkins for ex.) much
easier.
Thanks,
Oleksandr Poznyak!
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Recipe Debug - QA Issue
Hi,
1) It's more common to use FILES_${PN} += ...
2) Please, remove ${D} from FILES_${PN}
Try this:
FILES_${PN} += " \
${kmoddir}/onebox_common_gpl.ko \
${kmoddir}/onebox_gpl.ko \
${kmoddir}/onebox_nongpl.ko \
${kmoddir}/onebox_wlan_gpl.ko \
${kmoddir}/onebox_wlan_nongpl.ko \
${kmoddir}/wlan.ko \
${kmoddir}/wlan_wep.ko \
${kmoddir}/wlan_ccmp.ko \
${kmoddir}/wlan_tkip.ko \
${kmoddir}/wlan_acl.ko \
${kmoddir}/wlan_scan_sta.ko \
${kmoddir}/wlan_xauth.ko \
/etc/redpine/wlan_enable.sh \
/etc/redpine/wlan_disable.sh \
"
Moreover, You may simplify it:
FILES_${PN} += "${kmoddir} /etc/redpine"
On Wed, Jun 1, 2016 at 3:55 PM, Paul DeMetrotion <
pdemetrot...@winsystems.com> wrote:
> I have created a simple (?) recipe to copy some existing drivers and
> scripts into my kernel image. I am getting the following error when I
> attempt to bitbake the recipe. Is this a license issue?
>
>
>
> ERROR: QA Issue: rs9113: Files/directories were installed but not shipped
>
> /lib
>
> /lib/modules
>
> /lib/modules/kernel
>
> /lib/modules/kernel/drivers
>
> /lib/modules/kernel/drivers/net
>
> /lib/modules/kernel/drivers/net/wireless
>
> /lib/modules/kernel/drivers/net/wireless/redpine
>
> /lib/modules/kernel/drivers/net/wireless/redpine/wlan.ko
>
> /lib/modules/kernel/drivers/net/wireless/redpine/wlan_ccmp.ko
>
> /lib/modules/kernel/drivers/net/wireless/redpine/onebox_common_gpl.ko
>
> /lib/modules/kernel/drivers/net/wireless/redpine/wlan_tkip.ko
>
> /lib/modules/kernel/drivers/net/wireless/redpine/wlan_wep.ko
>
> /lib/modules/kernel/drivers/net/wireless/redpine/wlan_scan_sta.ko
>
> /lib/modules/kernel/drivers/net/wireless/redpine/wlan_acl.ko
>
> /lib/modules/kernel/drivers/net/wireless/redpine/onebox_wlan_nongpl.ko
>
> /lib/modules/kernel/drivers/net/wireless/redpine/onebox_wlan_gpl.ko
>
> /lib/modules/kernel/drivers/net/wireless/redpine/wlan_xauth.ko
>
> /lib/modules/kernel/drivers/net/wireless/redpine/onebox_gpl.ko
>
> /lib/modules/kernel/drivers/net/wireless/redpine/onebox_nongpl.ko
> [installed-vs-shipped]
>
>
>
> Here is the recipe. I have all of the files to be copied in the same
> directory as the recipe.
>
>
>
> DESCRIPTION = "Install of redpine drivers and scripts"
>
>
>
> LICENSE = "MIT"
>
> LIC_FILES_CHKSUM =
> "file://${COREBASE}/LICENSE;md5=4d92cd373abda3937c2bc47fbc49d690 \
>
>
> file://${COREBASE}/meta/COPYING.MIT;md5=3da9cfbcb788c80a0384361b4de20420"
>
>
>
> kmoddir =
> "/lib/modules/${KERNEL_VERSION}/kernel/drivers/net/wireless/redpine"
>
>
>
> FILESEXTRAPATHS_prepend := "${THISDIR}:"
>
>
>
> SRC_URI_append = " \
>
> file://onebox_common_gpl.ko \
>
> file://onebox_gpl.ko \
>
> file://onebox_nongpl.ko \
>
> file://onebox_wlan_gpl.ko \
>
> file://onebox_wlan_nongpl.ko \
>
> file://wlan.ko \
>
> file://wlan_wep.ko \
>
> file://wlan_ccmp.ko \
>
> file://wlan_tkip.ko \
>
> file://wlan_acl.ko \
>
> file://wlan_scan_sta.ko \
>
> file://wlan_xauth.ko \
>
> file://wlan_enable.sh \
>
> file://wlan_disable.sh \
>
> "
>
>
>
> do_install_append() {
>
> mkdir -p ${D}${kmoddir}
>
> install -m 0755 ${WORKDIR}/onebox_common_gpl.ko ${D}${kmoddir}
>
> install -m 0755 ${WORKDIR}/onebox_gpl.ko ${D}${kmoddir}
>
> install -m 0755 ${WORKDIR}/onebox_nongpl.ko ${D}${kmoddir}
>
> install -m 0755 ${WORKDIR}/onebox_wlan_gpl.ko ${D}${kmoddir}
>
> install -m 0755 ${WORKDIR}/onebox_wlan_nongpl.ko ${D}${kmoddir}
>
> install -m 0755 ${WORKDIR}/wlan.ko ${D}${kmoddir}
>
> install -m 0755 ${WORKDIR}/wlan_wep.ko ${D}${kmoddir}
>
> install -m 0755 ${WORKDIR}/wlan_ccmp.ko ${D}${kmoddir}
>
> install -m 0755 ${WORKDIR}/wlan_tkip.ko ${D}${kmoddir}
>
> install -m 0755 ${WORKDIR}/wlan_acl.ko ${D}${kmoddir}
>
> install -m 0755 ${WORKDIR}/wlan_scan_sta.ko ${D}${kmoddir}
>
> install -m 0755 ${WORKDIR}/wlan_xauth.ko ${D}${kmoddir}
>
> mkdir -p ${D}/etc/redpine
>
> install -m 0755 ${WORKDIR}/wlan_enable.sh ${D}/etc/redpine
>
> install -m 0755 ${WORKDIR}/wlan_disable.sh ${D}/etc/redpine
>
> }
>
>
>
> FILES_${PN}_append = " \
>
> ${D}${kmoddir}/onebox_common_gpl.ko \
>
> ${D}${kmoddir}/onebox_gpl.ko \
>
> ${D}${kmoddir}/onebox_nongpl.ko \
>
> ${D}${kmoddir}/onebox_wlan_gpl.ko \
>
> ${D}${kmoddir}/onebox_wlan_nongpl.ko \
>
> ${D}${kmoddir}/wlan.ko \
>
> ${D}${kmoddir}/wlan_wep.ko \
>
> ${D}${kmoddir}/wlan_ccmp.ko \
>
> ${D}${kmoddir}/wlan_tkip.ko \
>
> ${D}${kmoddir}/wlan_acl.ko \
>
> ${D}${kmoddir}/wlan_scan_sta.ko \
>
> ${D}${kmoddir}/wlan_xauth.ko \
>
> ${D}/etc/redpine/wlan_enable.sh \
>
> ${D}/etc/redpine/wlan_disable.sh \
>
> "
>
>
>
> Paul DeMetrotion
>
> Software Guru
>
> WinSystems, Inc.
>
> (972) 571-8657
>
> www.winsystems.com
>
>
>
> --
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
>
>
-
Re: [yocto] Recipe Debug - QA Issue
oops!
FILES_${PN} += "${base_libdir}"
That's it
On Wed, Jun 1, 2016 at 6:42 PM, Paul DeMetrotion <
pdemetrot...@winsystems.com> wrote:
> Thanks for your suggestions. I changed it to the simple one-line
> modification but still have the same issue. I even commented the
> FILES_${PN} line and have the same issue. It appears that the problem is
> with the do_install_append() section.
>
>
>
> Paul DeMetrotion
>
> Software Guru
>
> WinSystems, Inc.
>
> (972) 571-8657
>
> www.winsystems.com
>
>
>
> *From:* Oleksandr Poznyak [mailto:oleksandr.pozn...@gmail.com]
> *Sent:* Wednesday, June 01, 2016 8:40 AM
> *To:* Paul DeMetrotion
> *Cc:* yocto@yoctoproject.org
> *Subject:* Re: [yocto] Recipe Debug - QA Issue
>
>
>
> Hi,
> 1) It's more common to use FILES_${PN} += ...
> 2) Please, remove ${D} from FILES_${PN}
>
> Try this:
>
> FILES_${PN} += " \
> ${kmoddir}/onebox_common_gpl.ko \
> ${kmoddir}/onebox_gpl.ko \
> ${kmoddir}/onebox_nongpl.ko \
> ${kmoddir}/onebox_wlan_gpl.ko \
> ${kmoddir}/onebox_wlan_nongpl.ko \
> ${kmoddir}/wlan.ko \
> ${kmoddir}/wlan_wep.ko \
> ${kmoddir}/wlan_ccmp.ko \
> ${kmoddir}/wlan_tkip.ko \
> ${kmoddir}/wlan_acl.ko \
> ${kmoddir}/wlan_scan_sta.ko \
> ${kmoddir}/wlan_xauth.ko \
> /etc/redpine/wlan_enable.sh \
> /etc/redpine/wlan_disable.sh \
> "
>
> Moreover, You may simplify it:
>
> FILES_${PN} += "${kmoddir} /etc/redpine"
>
>
>
> On Wed, Jun 1, 2016 at 3:55 PM, Paul DeMetrotion <
> pdemetrot...@winsystems.com> wrote:
>
> I have created a simple (?) recipe to copy some existing drivers and
> scripts into my kernel image. I am getting the following error when I
> attempt to bitbake the recipe. Is this a license issue?
>
>
>
> ERROR: QA Issue: rs9113: Files/directories were installed but not shipped
>
> /lib
>
> /lib/modules
>
> /lib/modules/kernel
>
> /lib/modules/kernel/drivers
>
> /lib/modules/kernel/drivers/net
>
> /lib/modules/kernel/drivers/net/wireless
>
> /lib/modules/kernel/drivers/net/wireless/redpine
>
> /lib/modules/kernel/drivers/net/wireless/redpine/wlan.ko
>
> /lib/modules/kernel/drivers/net/wireless/redpine/wlan_ccmp.ko
>
> /lib/modules/kernel/drivers/net/wireless/redpine/onebox_common_gpl.ko
>
> /lib/modules/kernel/drivers/net/wireless/redpine/wlan_tkip.ko
>
> /lib/modules/kernel/drivers/net/wireless/redpine/wlan_wep.ko
>
> /lib/modules/kernel/drivers/net/wireless/redpine/wlan_scan_sta.ko
>
> /lib/modules/kernel/drivers/net/wireless/redpine/wlan_acl.ko
>
> /lib/modules/kernel/drivers/net/wireless/redpine/onebox_wlan_nongpl.ko
>
> /lib/modules/kernel/drivers/net/wireless/redpine/onebox_wlan_gpl.ko
>
> /lib/modules/kernel/drivers/net/wireless/redpine/wlan_xauth.ko
>
> /lib/modules/kernel/drivers/net/wireless/redpine/onebox_gpl.ko
>
> /lib/modules/kernel/drivers/net/wireless/redpine/onebox_nongpl.ko
> [installed-vs-shipped]
>
>
>
> Here is the recipe. I have all of the files to be copied in the same
> directory as the recipe.
>
>
>
> DESCRIPTION = "Install of redpine drivers and scripts"
>
>
>
> LICENSE = "MIT"
>
> LIC_FILES_CHKSUM =
> "file://${COREBASE}/LICENSE;md5=4d92cd373abda3937c2bc47fbc49d690 \
>
>
> file://${COREBASE}/meta/COPYING.MIT;md5=3da9cfbcb788c80a0384361b4de20420"
>
>
>
> kmoddir =
> "/lib/modules/${KERNEL_VERSION}/kernel/drivers/net/wireless/redpine"
>
>
>
> FILESEXTRAPATHS_prepend := "${THISDIR}:"
>
>
>
> SRC_URI_append = " \
>
> file://onebox_common_gpl.ko \
>
> file://onebox_gpl.ko \
>
> file://onebox_nongpl.ko \
>
> file://onebox_wlan_gpl.ko \
>
> file://onebox_wlan_nongpl.ko \
>
> file://wlan.ko \
>
> file://wlan_wep.ko \
>
> file://wlan_ccmp.ko \
>
> file://wlan_tkip.ko \
>
> file://wlan_acl.ko \
>
> file://wlan_scan_sta.ko \
>
> file://wlan_xauth.ko \
>
> file://wlan_enable.sh \
>
> file://wlan_disable.sh \
>
> "
>
>
>
> do_install_append() {
>
> mkdir -p ${D}${kmoddir}
>
> install -m 0755 ${WORKDIR}/onebox_common_gpl.ko ${D}${kmoddir}
>
> install -m 0755 ${WORKDIR}/onebox_gpl.ko ${D}${kmoddir}
>
> install -m 0755 ${WORKDIR}/onebox_nongpl.ko ${D}${kmoddir}
>
> install -m 0755 ${WORKDIR}/onebox_wlan_gpl.ko ${D}${kmoddir}
>
> install -m 0755 ${WORKDIR}/onebox_wlan_nongpl.ko ${D}${kmoddir}
>
> install -m 0755 ${WORKDIR}/wl
Re: [yocto] Per image customizations
Here is the content of bbappend recipe for base-files recipe:
FILESEXTRAPATHS_append := "${THISDIR}/${PN}"
SRC_URI += "file://fstab-flash \
file://fstab-regular \
"
PACKAGES += " ${PN}-flash ${PN}-regular"
CONFFILES_${PN}-flash = "${CONFFILES_${PN}}"
CONFFILES_${PN}-regular = "${CONFFILES_${PN}}"
pkg_preinst_${PN}-flash = "${pkg_preinst_${PN}}"
pkg_preinst_${PN}-regular = "${pkg_preinst_${PN}}"
RREPLACES_${PN}-flash = "${PN}"
RPROVIDES_${PN}-flash = "${PN}"
RCONFLICTS_${PN}-flash = "${PN}"
RREPLACES_${PN}-regular = "${PN}"
RPROVIDES_${PN}-regular = "${PN}"
RCONFLICTS_${PN}-regular = "${PN}"
python populate_packages_prepend() {
import shutil
packages = ("${PN}-flash", "${PN}-regular")
for package in packages:
# copy ${PN} content to packages
shutil.copytree("${PKGD}", "${PKGDEST}/%s" % package, symlinks=True)
# replace fstab
if package == "${PN}-flash":
shutil.copy("${WORKDIR}/fstab-flash",
"${PKGDEST}/${PN}-flash/etc/fstab")
else:
shutil.copy("${WORKDIR}/fstab-regular",
"${PKGDEST}/${PN}-regular/etc/fstab")
}
This will produce two separate packages that will replace base-files
package.
Moreover, this trick allows You to modify base-files package separately for
flash-OS and regular-OS
in other recipes add packages like this:
base-files-flash or base-files-regular
Thanks,
Oleksandr Poznyak!
On Wed, Jun 1, 2016 at 7:15 PM, Diego wrote:
> In data mercoledì 1 giugno 2016 15:25:09, Oleksandr Poznyak ha scritto:
> > Don't forget to add your fstab/inittab files into CONFFILES_${PN} cause
> if
> > the package that includes them will be changed and You'll update it via
> > package system, your POSTPROCESS hacks will be overwritten.
> >
> > Anyway, its better to avoid POSTPROCESS if possible.
> > 1) Create *.bbappend recipe base-files_%s.bbappend in your layer. It
> > appends to poky "base-files" recipe.
> > 2) Create your own "python do_package_prepend" function where you should
> > make your recipe produce two different packages
> > 3) Add them to DEPENDS in your image recipe
> >
>
> Hi Oleksandr,
>
> your approach is really interesting, but I'm unsure how to proceed with
> step
> 2) of your list.
>
> I've added the following in the bbappend:
>
> python do_package_prepend() {
> d.setVar('PACKAGES', "${PACKAGES} ${PN}-fstab-regular
> ${PN}-fstab-flash")
> }
>
> which creates the two additional packages, but then I'm confused on how to
> manage the two 'variant' fstab files. The FILES variable doesn't support
> "source -> destination", so how do I manage the fact that two different
> files
> need to go to the same destination path?
>
> An easier option would be to remove fstab in the base-files_%s.bbappend,
> and
> create 2 different .bb recipes for the 2 fstab files.
>
> Thanks anyhow for your help,
> Diego
>
>
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Recipe Debug - QA Issue
Also, try this to get KERNEL_VERSION:
KERNEL_VERSION="${@base_read_file('${STAGING_KERNEL_BUILDDIR}/kernel-abiversion')
kmoddir =
"/lib/modules/${KERNEL_VERSION}/kernel/drivers/net/wireless/redpine"
On Wed, Jun 1, 2016 at 8:44 PM, Paul DeMetrotion <
pdemetrot...@winsystems.com> wrote:
> That removed the QA error. Thanks you.
>
>
>
> Problems remain because none of the 12 driver files are being copied to
> the image while the two shell script files are copied.
>
>
>
> Paul DeMetrotion
>
> Software Guru
>
> WinSystems, Inc.
>
> (972) 571-8657
>
> www.winsystems.com
>
>
>
> *From:* Oleksandr Poznyak [mailto:oleksandr.pozn...@gmail.com]
> *Sent:* Wednesday, June 01, 2016 11:20 AM
>
> *To:* Paul DeMetrotion
> *Cc:* yocto@yoctoproject.org
> *Subject:* Re: [yocto] Recipe Debug - QA Issue
>
>
>
> oops!
>
> FILES_${PN} += "${base_libdir}"
>
> That's it
>
>
>
> On Wed, Jun 1, 2016 at 6:42 PM, Paul DeMetrotion <
> pdemetrot...@winsystems.com> wrote:
>
> Thanks for your suggestions. I changed it to the simple one-line
> modification but still have the same issue. I even commented the
> FILES_${PN} line and have the same issue. It appears that the problem is
> with the do_install_append() section.
>
>
>
> Paul DeMetrotion
>
> Software Guru
>
> WinSystems, Inc.
>
> (972) 571-8657
>
> www.winsystems.com
>
>
>
> *From:* Oleksandr Poznyak [mailto:oleksandr.pozn...@gmail.com]
> *Sent:* Wednesday, June 01, 2016 8:40 AM
> *To:* Paul DeMetrotion
> *Cc:* yocto@yoctoproject.org
> *Subject:* Re: [yocto] Recipe Debug - QA Issue
>
>
>
> Hi,
> 1) It's more common to use FILES_${PN} += ...
> 2) Please, remove ${D} from FILES_${PN}
>
> Try this:
>
> FILES_${PN} += " \
> ${kmoddir}/onebox_common_gpl.ko \
> ${kmoddir}/onebox_gpl.ko \
> ${kmoddir}/onebox_nongpl.ko \
> ${kmoddir}/onebox_wlan_gpl.ko \
> ${kmoddir}/onebox_wlan_nongpl.ko \
> ${kmoddir}/wlan.ko \
> ${kmoddir}/wlan_wep.ko \
> ${kmoddir}/wlan_ccmp.ko \
> ${kmoddir}/wlan_tkip.ko \
> ${kmoddir}/wlan_acl.ko \
> ${kmoddir}/wlan_scan_sta.ko \
> ${kmoddir}/wlan_xauth.ko \
> /etc/redpine/wlan_enable.sh \
> /etc/redpine/wlan_disable.sh \
> "
>
> Moreover, You may simplify it:
>
> FILES_${PN} += "${kmoddir} /etc/redpine"
>
>
>
> On Wed, Jun 1, 2016 at 3:55 PM, Paul DeMetrotion <
> pdemetrot...@winsystems.com> wrote:
>
> I have created a simple (?) recipe to copy some existing drivers and
> scripts into my kernel image. I am getting the following error when I
> attempt to bitbake the recipe. Is this a license issue?
>
>
>
> ERROR: QA Issue: rs9113: Files/directories were installed but not shipped
>
> /lib
>
> /lib/modules
>
> /lib/modules/kernel
>
> /lib/modules/kernel/drivers
>
> /lib/modules/kernel/drivers/net
>
> /lib/modules/kernel/drivers/net/wireless
>
> /lib/modules/kernel/drivers/net/wireless/redpine
>
> /lib/modules/kernel/drivers/net/wireless/redpine/wlan.ko
>
> /lib/modules/kernel/drivers/net/wireless/redpine/wlan_ccmp.ko
>
> /lib/modules/kernel/drivers/net/wireless/redpine/onebox_common_gpl.ko
>
> /lib/modules/kernel/drivers/net/wireless/redpine/wlan_tkip.ko
>
> /lib/modules/kernel/drivers/net/wireless/redpine/wlan_wep.ko
>
> /lib/modules/kernel/drivers/net/wireless/redpine/wlan_scan_sta.ko
>
> /lib/modules/kernel/drivers/net/wireless/redpine/wlan_acl.ko
>
> /lib/modules/kernel/drivers/net/wireless/redpine/onebox_wlan_nongpl.ko
>
> /lib/modules/kernel/drivers/net/wireless/redpine/onebox_wlan_gpl.ko
>
> /lib/modules/kernel/drivers/net/wireless/redpine/wlan_xauth.ko
>
> /lib/modules/kernel/drivers/net/wireless/redpine/onebox_gpl.ko
>
> /lib/modules/kernel/drivers/net/wireless/redpine/onebox_nongpl.ko
> [installed-vs-shipped]
>
>
>
> Here is the recipe. I have all of the files to be copied in the same
> directory as the recipe.
>
>
>
> DESCRIPTION = "Install of redpine drivers and scripts"
>
>
>
> LICENSE = "MIT"
>
> LIC_FILES_CHKSUM =
> "file://${COREBASE}/LICENSE;md5=4d92cd373abda3937c2bc47fbc49d690 \
>
>
> file://${COREBASE}/meta/COPYING.MIT;md5=3da9cfbcb788c80a0384361b4de20420"
>
>
>
> kmoddir =
> "/lib/modules/${KERNEL_VERSION}/kernel/drivers/net/wireless/redpine"
>
>
>
> FILESEXTRAPATHS_prepend := "${THISDIR}:"
>
>
>
> SRC_URI_append = " \
>
> file://onebox_common_gpl.ko \
>
> file://onebox_
Re: [yocto] How to set a cmake cache variable to a spezific value?
Hi, Just add to recipe: inherit cmake EXTRA_OECMAKE += " -DVARIABLE_NAME=value" On Thu, Jun 2, 2016 at 4:24 PM, Burton, Ross wrote: > > 2016-05-30 12:59 GMT+01:00 : > >> I want to build a recipe for a cmake based application. To make it run I >> need to set a cached cmake variable. >> > > EXTRA_OECMAKE += "-DVARIABLE_NAME=value" > > Ross > > -- > ___ > 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] Enable chroot for nativesdk
Hi, Currently, nativesdk doesn't support "chroot". It would be great to enable it for packages support at least. This will allow us to install packages directly into our sdk, try them and eventually add to Yocto if needed. Here might be valid steps to achive this: 1) Add coreutils to nativesdk: TOOLCHAIN_HOST_TASK += nativesdk-coreutils 2) Fix packagemanager support for chrooted nativesdk 1) Create unique symlink to dynamic loader located in nativesdk: Add something like this to POPULATE_SDK_POST_HOST_COMMAND ln -s ld-linux-x86-64.so.2 ld-yocto-nativesdk-x86-64.so.2 and ln -s /opt/poky/1.8/sysroots/x86_64-pokysdk-linux/lib/ld-linux-x86-64.so.2 /lib/ld-yocto-nativesdk-x86-64.so.2 2) patch binaries in nativesdk to set new dynamic loader patchelf --set-interpreter /lib/ld-yocto-nativesdk-x86-64.so.2 3) patch binaries in nativesdk to add RPATH: patchelf --set-rpath /opt/poky/1.8/sysroots/x86_64-pokysdk-linux/usr/lib:/opt/poky/1.8/sysroots/x86_64-pokysdk-linux/lib:/lib:/usr/lib Thanks, Oleksandr Poznyak! -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] rootfs mounted read-only on Live USB (x86-64)
Hi, Check if "read-only-rootfs" feature is added to any of these variables either in your local.conf or your image bitbake recipe: Something like that: IMAGE_FEATURES = "read-only-rootfs" EXTRA_IMAGE_FEATURES += "read-only-rootfs" Thanks, Oleksandr Poznyak! On Fri, Jun 3, 2016 at 12:06 PM, Dan O'Donovan wrote: > Hi all > > Has anyone else noticed that the root file-system appears to be mounted > read-only when booting a Live USB image from Yocto 2.1. > > This is on a sato build from the krogoth branch of poky and meta-intel, > for a generic x86-64 machine (4.4 kernel). > > I'm transferring the resulting .iso image to a usb stick using 'dd', and > then picking the 'boot' option at startup. > > As well as a bunch of errors about the read-only filesystem (e.g. failing > to create files in /var and other locations), the desktop UI fails to load. > > This worked fine with Yocto 2.0. > > I have a hunch that it might be caused by a lack of aufs support. Is it > possible that aufs patches were omitted from the x86 kernels in Yocto 2.1? > > Thanks, > -Dan > > P.S. It works fine if I just install it directly, or if I use the .hddimg, > instead of trying to boot the live image from the .iso. > -- > ___ > 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] Per image customizations
I found that that’s an issue with rpm packages. I didn't expect there might
be some issue with rpm. If you really don't care which package management
system to use, switch to deb:
PACKAGE_CLASSES = "package_deb"
On Fri, Jun 3, 2016 at 4:52 PM, Diego wrote:
> Hi Oleksandr,
>
> In data mercoledì 1 giugno 2016 21:57:32, Oleksandr Poznyak ha scritto:
> > Here is the content of bbappend recipe for base-files recipe:
> >
> > FILESEXTRAPATHS_append := "${THISDIR}/${PN}"
> >
> > SRC_URI += "file://fstab-flash \
> > file://fstab-regular \
> > "
> >
> > PACKAGES += " ${PN}-flash ${PN}-regular"
> > CONFFILES_${PN}-flash = "${CONFFILES_${PN}}"
> > CONFFILES_${PN}-regular = "${CONFFILES_${PN}}"
> >
> > pkg_preinst_${PN}-flash = "${pkg_preinst_${PN}}"
> > pkg_preinst_${PN}-regular = "${pkg_preinst_${PN}}"
> >
> > RREPLACES_${PN}-flash = "${PN}"
> > RPROVIDES_${PN}-flash = "${PN}"
> > RCONFLICTS_${PN}-flash = "${PN}"
> >
> > RREPLACES_${PN}-regular = "${PN}"
> > RPROVIDES_${PN}-regular = "${PN}"
> > RCONFLICTS_${PN}-regular = "${PN}"
> >
> > python populate_packages_prepend() {
> > import shutil
> >
> > packages = ("${PN}-flash", "${PN}-regular")
> > for package in packages:
> > # copy ${PN} content to packages
> > shutil.copytree("${PKGD}", "${PKGDEST}/%s" % package,
> symlinks=True)
> > # replace fstab
> > if package == "${PN}-flash":
> > shutil.copy("${WORKDIR}/fstab-flash",
> > "${PKGDEST}/${PN}-flash/etc/fstab")
> > else:
> > shutil.copy("${WORKDIR}/fstab-regular",
> > "${PKGDEST}/${PN}-regular/etc/fstab")
> > }
> >
> >
> > This will produce two separate packages that will replace base-files
> > package.
> > Moreover, this trick allows You to modify base-files package separately
> for
> > flash-OS and regular-OS
> >
>
> This is very useful, thank you. With this code I'm able to have two
> different
> fstab files under packages-split:
> ./packages-split/base-files-regular/etc/fstab
> ./packages-split/base-files-flash/etc/fstab
>
> Regardless of that though, the resulting rpm packages for
> "base-files-regular"
> and "base-files-flash" have the original fstab as in "base-files", which is
> different to both the fstabs in packages-split mentioned above.
>
> I'm looking at what might be causing this, but any idea is welcome.
>
> Thanks,
> Diego
>
>
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Per image customizations
Hi,
Unfortunately You can't have two *.bbappend files per one package (recipe).
You can create two new recipes where You'll install what You need and plus
add sysvinit-inittab to DEPENDS variable in those recipes. This will help
to retain the order of packages installation. Original sysvinit -> your
sysvinit.
In this situation You will have several recipes.
Thanks,
Oleksandr Poznyak!
On Mon, Jun 6, 2016 at 11:55 PM, Edward Wingate
wrote:
> On Wed, Jun 1, 2016 at 7:15 PM, Diego wrote:
> >
> > Hi Oleksandr,
> >
> > your approach is really interesting, but I'm unsure how to proceed with
> > step 2) of your list.
> >
> > I've added the following in the bbappend:
> >
> > python do_package_prepend() {
> > d.setVar('PACKAGES', "${PACKAGES} ${PN}-fstab-regular
> ${PN}-fstab-flash")
> > }
> >
> > which creates the two additional packages, but then I'm confused on how
> to
> > manage the two 'variant' fstab files. The FILES variable doesn't support
> > "source -> destination", so how do I manage the fact that two different
> > files need to go to the same destination path?
> >
> > An easier option would be to remove fstab in the base-files_%s.bbappend,
> > and create 2 different .bb recipes for the 2 fstab files.
>
> I hope you don't mind if I tag onto this thread, but I have a similar
> question.
>
> I've been modifying inittab with a sysvinit-inittab_2.88dsf.bbappend
> file that contains simply this:
>
> do_install_append() {
> echo "scra:2345:respawn:/opt/script1.sh" >> ${D}${sysconfdir}/inittab
> echo "scrb:2345:respawn:/opt/script2.sh" >> ${D}${sysconfdir}/inittab
> }
>
> Now, I want to do this if a different image is being created:
>
> do_install_append() {
> echo "scra:2345:respawn:/opt/script3.sh" >> ${D}${sysconfdir}/inittab
> echo "scrb:2345:respawn:/opt/script4.sh" >> ${D}${sysconfdir}/inittab
> }
>
> Can I duplicate and rename the bbappend file to have a different
> bbappend execute based on the image being created? Or perhaps
> duplicate the do_install_append() function in the same file and rename
> the functions to something like do_install_append_[something with
> image name]()?
>
> Or alternatively, can I set something in the image bb files that I can
> then use in the sysvinit-inittab_2.88dsf.bbappend to determine which
> to do?
>
> Thanks for your help.
>
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Per image customizations
Thanks, Paul. You are absolutely correct. On Tue, Jun 7, 2016 at 1:20 PM, Paul Eggleton wrote: > On Tue, 07 Jun 2016 00:10:58 Oleksandr Poznyak wrote: > > Unfortunately You can't have two *.bbappend files per one package > (recipe). > > Let's clarify that for the benefit of others reading along - you absolutely > *can* have multiple bbappends per recipe. To answer the original question > though, no you cannot have bbappends conditionally applied based on what > image > is being built - you cannot have other recipes built differently based on > the > image being built *period*. Other than what gets shared via the sysroot, > recipes are largely independent of eachother, and that's by design. > > Cheers, > Paul > > -- > > Paul Eggleton > Intel Open Source Technology Centre > -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Per image customizations
Hi, Edward.
Your approach is valid. But RREPLACES is not enough.
You should define that your package and original ones are conflicting and
that it provides the same as original one for other packages.
So in your recipe:
RPROVIDES_${PN} = "sysvinit-inittab"
RREPLACES_${PN} = "sysvinit-inittab"
RCONFLICTS_${PN} = "sysvinit-inittab"
Thanks,
Oleksandr Poznyak!
On Wed, Jun 8, 2016 at 2:23 AM, Paul Eggleton wrote:
> On Tue, 07 Jun 2016 16:07:26 Edward Wingate wrote:
> > On Tue, Jun 7, 2016 at 1:47 PM, Paul Eggleton
> > wrote:
> > > So what this will give you is alternative packages to be installed
> instead
> > > of sysvinit-inittab in your image.
> >
> > I was under the (mistaken) impression that my recipe will run in
> > addition to, not instead of, sysvinit-inittab (occurring after it and
> > overwriting its inittab with my custom version).
>
> The recipe will build in addition to sysvinit-inittab yes, but do_install
> for
> that recipe is just assembling the files ready for packaging - it doesn't
> directly install files into the image. When it comes time to assemble the
> image, all that is being done when you distil it down is that we install a
> bunch of packages.
>
> > > Have you verified (by way of the image manifest written next to the
> image
> > > file) that this package is actually being installed?
> >
> > The manifest shows both sysvinit-inittab and my package being
> > installed in the image, but sysvinit-inittab's inittab apparently
> > takes precedence over mine.
>
> Hmm, that is strange, because as they install the same file they ought to
> conflict. Perhaps as suggested elsewhere in this thread this is a bug (or
> at
> least undesirable behaviour) in rpm.
>
> > > What steps have you taken to ensure that it does get installed in
> > > preference to sysvinit-inittab?
> >
> > None, due to my mistaken impression. After investigating your kind
> > inference with help of Yocto manual, I replaced in my recipe:
> > DEPENDS += " sysvinit-inittab"
> > with:
> > RREPLACES_${PN} = "sysvinit-inittab"
> >
> > and it appears to be working now. I've been using Yocto for a year
> > now, but still feel like I'm barely scratching the surface of it. I
> > tend to get things to work by floundering about, so even though it
> > does works, I would appreciate knowing if this was the most proper
> > course of action. Thanks!
>
> I guess here you are getting into functionality that is not very
> well-defined,
> and you're also dealing with behaviour of the package manager rather than
> the
> build system itself (though I appreciate the lines are blurred from usage
> perspective). I guess it would help though if we would document a working
> procedure to do this kind of thing as it does come up from time to time.
>
> Cheers,
> Paul
>
> --
>
> Paul Eggleton
> Intel Open Source Technology Centre
>
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Problems with do_rootfs when changing the user password
Hi,
Its better to change root passwd within ROOTFS_POSTPROCESS_COMMAND
Something like that:
set_root_passwd() {
.change passwd here
}
ROOTFS_POSTPROCESS_COMMAND += " set_root_passwd;"
Thanks,
Oleksandr Poznyak!
On Thu, Jun 9, 2016 at 12:00 PM, wrote:
> Hej
>
> I want to change the root password. For that I create the recipe
> "myNewPassword.bb" with:
>
> SUMMARY = "my new password"
> SECTION = "new"
> LICENSE = "CLOSED"
>
> inherit extrausers
>
> EXTRA_USERS_PARAMS = "\
> usermod -P xyz root; \
> "
>
>
> compiling and packaging works fine.
>
> In my layer I add at the layer.conf:
>
> IMAGE_INSTALL_append=" myNewPassword"
>
>
> When do_rootfs (core-image-minimal) the package could not be found. A
> deb(ug) Package was created.
>
> Regards!
>
> Stefan Jaritz
>
>
> ESA Elektroschaltanlagen Grimma GmbH
> Broner Ring 30
> 04668 Grimma
> Telefon: +49 3437 9211 176
> Telefax: +49 3437 9211 26
> E-Mail: s.jar...@esa-grimma.de
> Internet: www.esa-grimma.de
>
>
> Geschäftsführer:
> Dipl.-Ing. Jörg Gaitzsch
> Jörg Reinker
>
> Sitz der Gesellschaft: Grimma
> Ust.-ID: DE 141784437
> Amtsgericht: Leipzig, HRB 5159
> Steuernummer: 238/108/00755
>
>
> Diese E-Mail enthält vertrauliche und/oder rechtlich geschützte
> Informationen.
> Wenn Sie nicht der richtige Adressat sind oder diese E-Mail irrtümlich
> erhalten
> haben, informieren Sie bitte sofort den Absender und löschen Sie diese
> Nachricht. Das unerlaubte Kopieren sowie die unbefugte Weitergabe dieser
> Mail
> ist nicht gestattet.
>
> This e-mail may contain confidential and/or privileged information. If you
> are
> not the intended recipient (or have received this e-mail in error) please
> notify the sender immediately and destroy this e-mail. Any unauthorized
> copying, disclosure or distribution of the material in this e-mail is
> strictly
> forbidden.
> --
> ___
> 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] [PATCH] package.bbclass: Changed PACKAGESPLITFUNCS execution order
Fixes [YOCTO #11343]
I've added runtime PACKAGESPLITFUNCS value modification in
the context of do_package() function so that
populate_packages_updatealternatives function is allways
executed before populate_packages_updatercd
Signed-off-by: Oleksandr Poznyak
---
meta/classes/package.bbclass | 5 +
1 file changed, 5 insertions(+)
diff --git a/meta/classes/package.bbclass b/meta/classes/package.bbclass
index cc466bd..149a185 100644
--- a/meta/classes/package.bbclass
+++ b/meta/classes/package.bbclass
@@ -2110,6 +2110,11 @@ python do_package () {
cpath = oe.cachedpath.CachedPath()
+# modify PACKAGESPLITFUNCS order
+if "populate_packages_updatealternatives" in d.getVar("PACKAGESPLITFUNCS",
True):
+d.setVar("PACKAGESPLITFUNCS", "populate_packages_updatealternatives
%s" \
+% d.getVar("PACKAGESPLITFUNCS",
True).replace("populate_packages_updatealternatives", ""))
+
for f in (d.getVar('PACKAGESPLITFUNCS') or '').split():
bb.build.exec_func(f, d)
--
2.1.4
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[yocto] [PATCH] package.bbclass: Changed PACKAGESPLITFUNCS execution order
Fixes [YOCTO #11343]
I've added runtime PACKAGESPLITFUNCS value modification in
the context of do_package() function so that
populate_packages_updatealternatives function is allways
executed before populate_packages_updatercd
Signed-off-by: Oleksandr Poznyak
---
meta/classes/package.bbclass | 5 +
1 file changed, 5 insertions(+)
diff --git a/meta/classes/package.bbclass b/meta/classes/package.bbclass
index cc466bd..149a185 100644
--- a/meta/classes/package.bbclass
+++ b/meta/classes/package.bbclass
@@ -2110,6 +2110,11 @@ python do_package () {
cpath = oe.cachedpath.CachedPath()
+# modify PACKAGESPLITFUNCS order
+if "populate_packages_updatealternatives" in d.getVar("PACKAGESPLITFUNCS",
True):
+d.setVar("PACKAGESPLITFUNCS", "populate_packages_updatealternatives
%s" \
+% d.getVar("PACKAGESPLITFUNCS",
True).replace("populate_packages_updatealternatives", ""))
+
for f in (d.getVar('PACKAGESPLITFUNCS') or '').split():
bb.build.exec_func(f, d)
--
2.1.4
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
