Re: [yocto] Patch failure with bbappends

[Nicolas Dechesne]

On Thu, Nov 28, 2013 at 8:10 AM, Nathan Rossi wrote:

> Reverting this commit on the top of master results in a functional build.
> I've done some 'bitbake -e' scanning with and without the above commit, and
> I cannot see any differences between the variables that are changed in the
> meta-xilinx .bbappends files. So it does not appear to be a problem in
> non-inclusion of the bbappend files, and the ordering of the inclusion
> appears to be correct as well.
>
> Before I dive any deeper into the bitbake change itself I was hoping
> someone might have seen this issue previously or has some insight.
>

just a wild guess... but could it be because gcc-cross and
gcc-cross-initial both start with 'gcc-cross', hence the regexp in this new
commit is catching them twice? i am referring to this:

-if f in self.appendlist:
-return self.appendlist[f]
-return []
+for bbappend in self.appendlist:
+if bbappend in f or ('%' in bbappend and
bbappend.startswith(f[:bbappend.index('%')])):
+self.appliedappendlist.append(bbappend)
+for filename in self.appendlist[bbappend]:
+filelist.append(filename)
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] unbootable image produced with PACKAGE_CLASSES ?= "package_ipk", /etc missing

[Robert Yang]

Hi Todd,

I can't reproduce the problem, the rpm has more space than ipk is because
of the IMAGE_ROOTFS_EXTRA_SPACE, which is 50M * 1.3 by default.

Would you please try the following commands:

1) $ ls -stlh 
tmp/deploy/images/wandboard-dual/core-image-minimal-dev-wandboard-dual-*.ext3


2) $ fsck.ext4 -fn /path/to/image.ext3

And can you show the bb file if possible ?

// Robert

On 11/27/2013 09:27 AM, Todd Stellanova wrote:

Tried creating a fresh build folder and giving the vm more ram but the
results are basically the same:

Allocated inode: 15264
copy_file: Could not allocate block in ext2 filesystem
debugfs: sif "libgio-2.0.so.0.3800.1" mode 0x81ed

It appears that using package_rpm successfully allocates something like
15968 inodes. When calculating the ROOTFS_SIZE it looks like package_rpm
and package_ipk are using very different values:

package_rpm:

++ du -ks
/fsl-community-bsp/build/tmp/work/wandboard_dual-poky-linux-gnueabi/todd-new/1.0-r0/rootfs
++ awk '{base_size = $1 * 1.3; base_size = ((base_size > 8192 ? base_size :
8192) + 0 + *51200*); if (base_size != int(base_size)) base_size =
int(base_size + 1); base_size = base_size + 4096 - 1; base_size -=
base_size % 4096; print base_size }'

+ ROOTFS_SIZE=*458752*

package_ipk:

++ du -ks
/fsl-community-bsp/build/tmp/work/wandboard_dual-poky-linux-gnueabi/todd-new/1.0-r0/rootfs
++ awk '{base_size = $1 * 1.3; base_size = ((base_size > 8192 ? base_size :
8192) + 0); if (base_size != int(base_size)) base_size = int(base_size +
1); base_size = base_size + 4096 - 1; base_size -= base_size % 4096; print
base_size }'

+ ROOTFS_SIZE=*376832*

I'm just guessing here, but it seems like package_ipk is underestimating
ROOTFS_SIZE and subsequently populate-extfs.sh fails trying to add files to
the ext fs.  Any ideas what might cause this?

Thanks for any help!






On Mon, Nov 25, 2013 at 7:03 AM, Todd Stellanova wrote:


Thanks for the ideas. I'll try creating a new build folder. If that still
shows the problem, I'm thinking this has something to do with the fact that
I'm running the build inside a vm (inside an Ubuntu vm running on a Mac).
It looks like the build is using debugfs...maybe it's running out of ram at
some point and not obtaining more in the vm properly?


On Nov 25, 2013, at 5:21 AM, Paul Eggleton <

paul.eggle...@linux.intel.com> wrote:


Hi Nicolas / Todd,


On Monday 25 November 2013 11:31:42 Nicolas Dechesne wrote:
On Sun, Nov 24, 2013 at 3:51 AM, Todd Stellanova
wrote:

It appears that copying the files to the ext3 / sdcard image is

failing in

*populate-extfs.sh*
I see a series of these errors:

*copy_file: Could not allocate block in ext2 filesystem*

Any idea what might cause this?  I've verified that the initial .tar
archive and the bz2 contain the right files.


can you try to create a new  folder (do not remove the current

one

for now) and reuse the downloads and sstate folder? i am wondering if

there

is a bug when trying to change PACKAGE_CLASSES in an existing 
folder.


I do this not infrequently and never hit a problem like this, so I doubt

this

is the case.

Either there is a problem in how the filesystem is being set up (block

sizes,

etc.) or there is some kind of corruption occurring.

Cheers,
Paul

--

Paul Eggleton
Intel Open Source Technology Centre






___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto


___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] How to use pre-built external Yocto toolchain

[Paul Eggleton]

Hi Christopher,

On Wednesday 27 November 2013 23:02:43 Thornburg, Christopher A wrote:
> I must be missing something obvious. It's easy for me to build and install a
> toolchain package using bitbake meta-toolchain
> The resulting toolchain package shows up at...
> ./tmp/deploy/sdk/poky-eglibc-i686-meta-toolchain-core2-toolchain-1.5.sh
> ...which is easy to install.
> 
> It seems the proper way to use such an external toolchain would be to set
> TCMODE, but TCMODE only seems to support 'default' (i.e. build an internal
> toolchain) and 'external-sourcery' (i.e. use an external sourcery
> toolchain). :S
> 
> How do I use an external toolchain built as above?

We don't support this; if you're going to use our toolchain it's expected that 
you let the build system take care of building it. If what you want is to 
accelerate repeat builds or builds of the same source on different machines, 
the solution for that is to use shared state (using SSTATE_MIRRORS to share 
between different build machines, if needed).

Cheers,
Paul

-- 

Paul Eggleton
Intel Open Source Technology Centre
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Errors with update-rc.d: /etc/init.d/XXX exists during rc.d purge (use -f to force)

[Richard Leitner - SKIDATA]

Hi Paul,
thank you for that hint and description of your workaround!
Looks like you've invested a little bit more time into working around this 
issue than me :-)

I've added "-f" to the update-rc.d.bbclass and now it's working like a charm:

diff --git a/meta/classes/update-rc.d.bbclass b/meta/classes/update-rc.d.bbclass
index d8cc342..dbb5781 100644
--- a/meta/classes/update-rc.d.bbclass
+++ b/meta/classes/update-rc.d.bbclass
@@ -33,7 +33,7 @@ updatercd_postrm() {
 if test "$D" != ""; then
OPT="-f -r $D"
 else
-   OPT=""
+   OPT="-f"
 fi
 if type update-rc.d >/dev/null 2>/dev/null; then
update-rc.d $OPT ${INITSCRIPT_NAME} remove


Nonetheless, I think there have to be a "cleaner" way to solve this issue than 
forcing the update-rc.d.
Maybe someone else has an idea how to solve this problem?

regards,
Richard


> -Original Message-
> From: Stath, Paul [mailto:pst...@axxcelera.com]
> Sent: Wednesday, November 27, 2013 5:40 PM
> To: Richard Leitner - SKIDATA
> Cc: Yocto Project Discussion ML (yocto@yoctoproject.org)
> Subject: RE: Errors with update-rc.d: /etc/init.d/XXX exists during rc.d 
> purge (use -f to
> force)
> 
> Richard --
> 
> My "workaround" was a little less drastic than yours.  (grin)
> 
> Before upgrading to the new package via 'dpkg -i', I would edit the postrm 
> script in
> /var/lib/dpkg/info/,postrm, adding the "-f" argument to "force" the
> symlink removal, as suggested by the error message.
> 
> Then the upgrade install works correctly.  (With only a warning from the 
> postrm script
> of the previous package.)
> 
> I believe that the issue is that when installing a package over an earlier 
> release, dpkg
> performs the following steps:
> 
> 1) Extract control files of new package
> 2) Execute "prerm" script of previous package if applicable.
> 3) Execute "preinst" script of new package.
> 4) Unpack new files and backup old files.
> 5) Execute "postrm" script of previous package if applicable.
> 6) Configure the package
> 
> When installing a newer version of the package, the "postrm" in step 5 fails, 
> because
> the initscript from the new package is extracted in step 4, and update-rc.d 
> w/o the "-f"
> argument exits with a non-zero return code.
> 
> I would argue that the "updatercd_postrm()" stanza in the update-rc.d.bbclass 
> should
> include the "-f" flag.
> (Anyone on the list want to chime in on this?)
> 
> In the meantime, I have added my own "updatercd_postrm()" stanza in the 
> .bbappend
> file for the package I'm having issues with, which overrides the one provided 
> by
> update-rc.d.bbclass.
> 
> updatercd_postrm() {
>update-rc.d $D -f ${INITSCRIPT_NAME} remove }
> 
> --
> Paul Stath
> Axxcelera Broadband Wireless
> 
> >From: Richard Leitner - SKIDATA [richard.leit...@skidata.com]
> >Sent: Wednesday, November 27, 2013 11:02 AM
> >To: Stath, Paul
> >Cc: Yocto Project Discussion ML (yocto@yoctoproject.org)
> >Subject: RE: Errors with update-rc.d: /etc/init.d/XXX exists during
> >rc.d purge (use -f to force)
> >
> >Hi Paul,
> >good to hear I'm not the only one suffering from this issue...
> >No, I've received no response on the mailing list yet, but maybe someone has 
> >a hint
> for us now?
> >
> >The only "workaround" I found is to purge the package and afterwards install 
> >the
> new version.
> >I know this is a really dirty workaround, but it's the only "solution" I 
> >found.
> >
> >Have you discovered any other workarounds, Paul?
> >
> >regards
> >Richard
> >
> >>-Original Message-
> >>From: Stath, Paul [mailto:pst...@axxcelera.com]
> >>Sent: Wednesday, November 27, 2013 4:49 PM
> >>To: Richard Leitner - SKIDATA
> >>Subject: RE: Errors with update-rc.d: /etc/init.d/XXX exists during
> >>rc.d purge (use -f to force)
> >>
> >>Richard --
> >>
> >>I am also getting the "update-rc.d: /etc/init.d/XXX exists during rc.d 
> >>purge"  error
> when I attempt to install a newer version of one of my packages.
> >>
> >>It doesn't look like you received any response to your post to the yocto 
> >>mailing list.
> >>
> >>Did you get any response, or did you discover a workaround?
> >>
> >>--
> >>Paul Stath
> >>Axxcelera Broadband Wireless
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] Tracker failing to compile

[Stuart Weaver]

Hi all,
I'm trying to include a recipe that depends on tracker_0.14.2. When I build
the image it is failing to do_compile tracker with the following output:

*| make[3]: Leaving directory
`/home/stuart/yocto/fsl-community-bsp/build/tmp/work/cortexa9hf-vfp-neon-poky-linux-gnueabi/tracker/0.14.2-r7/tracker-0.14.2/src/tracker-utils'*
*| Making all in tracker-extract*
*| make[3]: Entering directory
`/home/stuart/yocto/fsl-community-bsp/build/tmp/work/cortexa9hf-vfp-neon-poky-linux-gnueabi/tracker/0.14.2-r7/tracker-0.14.2/src/tracker-extract'*
*| make  all-am*
*| make[4]: Entering directory
`/home/stuart/yocto/fsl-community-bsp/build/tmp/work/cortexa9hf-vfp-neon-poky-linux-gnueabi/tracker/0.14.2-r7/tracker-0.14.2/src/tracker-extract'*
*| ../../arm-poky-linux-gnueabi-libtool  --tag=CXX   --mode=link
arm-poky-linux-gnueabi-g++  -march=armv7-a -mthumb-interwork
-mfloat-abi=hard -mfpu=neon -mtune=cortex-a9
--sysroot=/home/stuart/yocto/fsl-community-bsp/build/tmp/sysroots/imx6qsabresd
 -O2 -pipe -g -feliminate-unused-debug-types -fpermissive
-fvisibility-inlines-hidden  -Wl,-O1 -Wl,--hash-style=gnu -Wl,--as-needed
-o tracker-extract tracker_extract-tracker-marshal.o
tracker_extract-tracker-config.o tracker_extract-tracker-controller.o
tracker_extract-tracker-extract.o tracker_extract-tracker-media-art.o
tracker_extract-tracker-read.o tracker_extract-tracker-main.o
tracker_extract-tracker-media-art-pixbuf.o
../../src/libtracker-extract/libtracker-extract-0.14.la

../../src/libtracker-sparql-backend/libtracker-sparql-0.14.la

../../src/libtracker-miner/libtracker-miner-0.14.la

../../src/libtracker-data/libtracker-data.la 
../../src/libtracker-common/libtracker-common.la
  -lgio-2.0 -lgobject-2.0 -Wl,--export-dynamic
-lgmodule-2.0 -pthread -lglib-2.0  -lQtGui -lQtCore  -lgdk_pixbuf-2.0
-lgobject-2.0 -lglib-2.0*
*| arm-poky-linux-gnueabi-libtool: link: cannot find the library `' or
unhandled argument `-DLINUX=1'*
*| make[4]: *** [tracker-extract] Error 1*

I'm guessing that the issue is with the '-DLINUX=1' since no library is
written? I've tried looking into it more for an answer but haven't found
one so far!

Any help is much appreciated!!

Best Regards,
Stuart
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] chkconfig

[Paul Eggleton]

Hi Edward,

On Friday 22 November 2013 11:00:44 Edward Vidal wrote:
> Is chkconfig part of any image?

It's part of the LSB images and the self-hosted image, but you probably don't 
want to build those unless you're looking for those things exactly. You can 
add chkconfig to any image just by adding the "chkconfig" package to 
IMAGE_INSTALL.

> Also to force what is the best procedure?

To force what?

> In my /etc/network/interfaces I have tried the following
> auto eth0
> iface eth0 inet static
> address 192.168.0.29
> hwaddress ether 00:0A:35:00:00:00
> netmask 255.255.255.0
> network 192.168.0.0
> gateway 192.168.0.1
> Since I have a router on my network I get an IP using dhcp,
> if I ifdown eth0 and ifup eth0 then the 192.168.0.29 get setup.

Do you have connman in the image? If so the above might be being ignored.

Cheers,
Paul

-- 

Paul Eggleton
Intel Open Source Technology Centre
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Custom defconfig is not used

[Diego Sueiro]

Bruce,

Any updates on this?

Regards,

--
*dS
Diego Sueiro

/*long live rock 'n roll*/


On Mon, Nov 4, 2013 at 1:14 AM, Bruce Ashfield  wrote:

> On 13-10-29 11:31 AM, Diego Sueiro wrote:
>
>> Bruce,
>>
>> I've created new build setup with this configuration:
>>
>> BB_VERSION= "1.18.0"
>> BUILD_SYS = "x86_64-linux"
>> NATIVELSBSTRING   = "Ubuntu-12.10"
>> TARGET_SYS= "arm-poky-linux-gnueabi"
>> MACHINE   = "beaglebone"
>> DISTRO= "poky"
>> DISTRO_VERSION= "1.4.2"
>> TUNE_FEATURES = "armv7a vfp neon"
>> TARGET_FPU= "vfp-neon"
>> meta
>> meta-yocto
>> meta-yocto-bsp= "dylan:4e399f08d596197859214fdb3b06403b87bf8789"
>> meta-oe   = "dylan:a108b2203a997634f87ac687e81712badaf3c546"
>> common-bsp= "dylan:7fdf9c670a10c5031a2dc15c45e453de8c21"
>> meta-mine = "dylan:4e399f08d596197859214fdb3b06403b87bf8789"
>>
>> common-bsp comes from meta-beagleboard.
>> meta-oe needed to be added because of machine_kernel_pr.bbclass.
>>
>> bblayers.conf:
>>
>> LCONF_VERSION = "6"
>> BBPATH = "${TOPDIR}"
>> BBFILES ?= ""
>> BBLAYERS ?= " \
>>${TOPDIR}/meta \
>>${TOPDIR}/meta-yocto \
>>${TOPDIR}/meta-yocto-bsp \
>>${TOPDIR}/meta-openembedded/meta-oe \
>>${TOPDIR}/meta-beagleboard/common-bsp \
>>${TOPDIR}/meta-mine \
>>"
>>
>> meta-mine:
>>
>> conf/layer.conf:
>>
>> BBPATH .= ":${LAYERDIR}"
>> BBFILES += "${LAYERDIR}/recipes*/*/*.bb
>> ${LAYERDIR}/recipes*/*/*.bbappend"
>> BBFILE_COLLECTIONS += "my-layer"
>> BBFILE_PATTERN_my-layer := "^${LAYERDIR}/"
>> BBFILE_PRIORITY_my-layer = "10"
>>
>> recipes-kernel/linux/linux-mainline_3.8.bbappend (scenario 1):
>>
>> FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}-3.8:"
>> COMPATIBLE_MACHINE_beaglebone = "(beaglebone)"
>> SRC_URI += " file://defconfig \
>>   "
>>
>> recipes-kernel/linux/linux-mainline-3.8/defconfig (scenario 1):
>>
>> http://pastebin.com/qd8B3C5K
>>
>>
>> recipes-kernel/linux/linux-mainline_3.8.bbappend (scenario 2):
>>
>> FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}-3.8:"
>> inherit kernel
>> require recipes-kernel/linux/linux-yocto.inc
>> COMPATIBLE_MACHINE_beaglebone = "(beaglebone)"
>> SRC_URI += " file://config-addons.cfg \
>>   "
>>
>> recipes-kernel/linux/linux-mainline-3.8/config-addons.cfg (scenario
>> 2):
>>
>> CONFIG_WATCHDOG_NOWAYOUT=y
>>
>> CONFIG_NTFS_FS=y
>> CONFIG_NTFS_RW=y
>>
>>
>>
>> Results:
>>
>>   * Scenario 1: Full defconfig replacement
>>
>>
>> ${WORKDIR}/defconfig comes from meta-beagleboard instead of meta-mine
>>
>> ${S}/.config comes from meta-beagleboard instead of meta-mine
>>
>
> FYI: I went silent on this, since I was running a few experiments in the
> background. Mainly on scenario 2, but I can say that I see the same
> behaviour
> with scenario #1 as you do. Whether or not I use the yocto kernel tooling,
> or the core kernel processing, I see exactly the same defconfig used.
>
> The issue you are seeing is distinct from the kernel processing, since
> the defconfig isn't treated any differently than anything else on the
> SRC_URI from the fetcher point of view ... and it is the fetcher which
> is matching file://defconfig from the meta-beagleboard layer before the
> one you have in meta-mine, since FILESEXTRAPATHS are searched after the
> FILESPATH for the elements in the SRC_URI. But I'm not a fetcher expert,
> that's my understanding and empirical evidence.
>
> As a debug, I called src_patches() in patches.bbclass explicitly, and
> it is obvious that the source of the defconfig is from meta-beagleboard.
> Renaming the file in meta-beagleboard, allows the one in meta-mine to
> be found, since the search continues.
>
> So for this question, your issue is with the ordering of the elements
> on the SRC_URI, and you can have your layer prioritized by making sure
> it is in the search paths first.
>
> This may or may not contradict the docs, and there are several threads
> ongoing about SRC_URI ordering in the various branches .. so I'm simply
> watching and waiting on this one.
>
>
>>   * Scenario 2: Config fragments
>>
>>
>> "bitbake linux-mainline" got stuck on do_patch
>>
>> log.do_patch:
>>
>> DEBUG: Executing shell function do_patch
>>
>> WARNING: no meta data branch found ...
>>
>> Switched to branch 'linux-3.8.y'
>>
>> [INFO] validating against known patches
>>  (beaglebone-standard-meta)
>>
>>
> As for this. I debugged it over the weekend, and you wouldn't see this on
> master, but the tools on the dylan branch aren't using the proper
> kern-tools
> SRCREVS. As such, I backported a change from master, and switched the
> kern-tools to use the dylan branch.
>
> What you were 

Re: [yocto] Custom defconfig is not used

[Bruce Ashfield]

On 11/28/2013, 10:37 AM, Diego Sueiro wrote:

Bruce,

Any updates on this?


Which part ? :) The defconfig "selection" (prioritization) was
explained by instrumenting the SRC_URI processing order, and it
was behaving as expected.

And the patch I attached for the kern-tools to use the dedicated
release branch for dylan fixed the other patching issue you were
seeing.

Cheers,

Bruce



Regards,

--
*dS
Diego Sueiro

/*long live rock 'n roll*/


On Mon, Nov 4, 2013 at 1:14 AM, Bruce Ashfield
mailto:bruce.ashfi...@windriver.com>> wrote:

On 13-10-29 11 :31 AM, Diego Sueiro wrote:

Bruce,

I've created new build setup with this configuration:

 BB_VERSION= "1.18.0"
 BUILD_SYS = "x86_64-linux"
 NATIVELSBSTRING   = "Ubuntu-12.10"
 TARGET_SYS= "arm-poky-linux-gnueabi"
 MACHINE   = "beaglebone"
 DISTRO= "poky"
 DISTRO_VERSION= "1.4.2"
 TUNE_FEATURES = "armv7a vfp neon"
 TARGET_FPU= "vfp-neon"
 meta
 meta-yocto
 meta-yocto-bsp=
"dylan:__4e399f08d596197859214fdb3b0640__3b87bf8789"
 meta-oe   =
"dylan:__a108b2203a997634f87ac687e81712__badaf3c546"
 common-bsp=
"dylan:__7fdf9c670a10c5031a2dc15c45__e453de8c21"
 meta-mine =
"dylan:__4e399f08d596197859214fdb3b0640__3b87bf8789"

common-bsp comes from meta-beagleboard.
meta-oe needed to be added because of machine_kernel_pr.bbclass.

bblayers.conf:

 LCONF_VERSION = "6"
 BBPATH = "${TOPDIR}"
 BBFILES ?= ""
 BBLAYERS ?= " \
${TOPDIR}/meta \
${TOPDIR}/meta-yocto \
${TOPDIR}/meta-yocto-bsp \
${TOPDIR}/meta-openembedded/__meta-oe \
${TOPDIR}/meta-beagleboard/__common-bsp \
${TOPDIR}/meta-mine \
"

meta-mine:

 conf/layer.conf:

 BBPATH .= ":${LAYERDIR}"
 BBFILES += "${LAYERDIR}/recipes*/*/*.bb
 ${LAYERDIR}/recipes*/*/*.__bbappend"
 BBFILE_COLLECTIONS += "my-layer"
 BBFILE_PATTERN_my-layer := "^${LAYERDIR}/"
 BBFILE_PRIORITY_my-layer = "10"

 recipes-kernel/linux/linux-__mainline_3.8.bbappend
(scenario 1):

 FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}-3.8:"
 COMPATIBLE_MACHINE_beaglebone = "(beaglebone)"
 SRC_URI += " file://defconfig \
   "

 recipes-kernel/linux/linux-__mainline-3.8/defconfig
(scenario 1):

http://pastebin.com/qd8B3C5K


 recipes-kernel/linux/linux-__mainline_3.8.bbappend
(scenario 2):

 FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}-3.8:"
 inherit kernel
 require recipes-kernel/linux/linux-__yocto.inc
 COMPATIBLE_MACHINE_beaglebone = "(beaglebone)"
 SRC_URI += " file://config-addons.cfg \
   "

 recipes-kernel/linux/linux-__mainline-3.8/config-addons.cfg
(scenario 2):

 CONFIG_WATCHDOG_NOWAYOUT=y

 CONFIG_NTFS_FS=y
 CONFIG_NTFS_RW=y



Results:

   * Scenario 1: Full defconfig replacement


 ${WORKDIR}/defconfig comes from meta-beagleboard instead of
meta-mine

 ${S}/.config comes from meta-beagleboard instead of meta-mine


FYI: I went silent on this, since I was running a few experiments in the
background. Mainly on scenario 2, but I can say that I see the same
behaviour
with scenario #1 as you do. Whether or not I use the yocto kernel
tooling,
or the core kernel processing, I see exactly the same defconfig used.

The issue you are seeing is distinct from the kernel processing, since
the defconfig isn't treated any differently than anything else on the
SRC_URI from the fetcher point of view ... and it is the fetcher which
is matching file://defconfig from the meta-beagleboard layer before the
one you have in meta-mine, since FILESEXTRAPATHS are searched after the
FILESPATH for the elements in the SRC_URI. But I'm not a fetcher expert,
that's my understanding and empirical evidence.

As a debug, I called src_patches() in patches.bbclass explicitly, and
it is obvious that the source of the defconfig is from meta-beagleboard.
Renaming the file in meta-beagleboard, allows the one in meta-mine to
be found, since the search continues.

So for this question, your issue is with the ordering of the elements
on the SRC_URI, and you can have your layer prioritized by making sure
it is in the search paths first.

Re: [yocto] Custom defconfig is not used

[Diego Sueiro]

On Thu, Nov 28, 2013 at 1:49 PM, Bruce Ashfield <
bruce.ashfi...@windriver.com> wrote:

> And the patch I attached for the kern-tools to use the dedicated
> release branch for dylan fixed the other patching issue you were
> seeing.
>

This patch was applied in some repo?

Regards,

--
*dS
Diego Sueiro

/*long live rock 'n roll*/
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Custom defconfig is not used

[Bruce Ashfield]

On 11/28/2013, 11:26 AM, Diego Sueiro wrote:


On Thu, Nov 28, 2013 at 1:49 PM, Bruce Ashfield
mailto:bruce.ashfi...@windriver.com>> wrote:

And the patch I attached for the kern-tools to use the dedicated
release branch for dylan fixed the other patching issue you were
seeing.


This patch was applied in some repo?


That's why I cc'd Paul on the submission, but I suspect it got lost, since
I never did get a comment .. and we are all pretty busily juggling multiple
things at once.

Paul: can you find the patch in the history of this thread ? If not I
can resend it directly.

Bruce



Regards,

--
*dS
Diego Sueiro

/*long live rock 'n roll*/


___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Custom defconfig is not used

[Paul Eggleton]

Hi Bruce / Diego,

On Thursday 28 November 2013 11:28:41 Bruce Ashfield wrote:
> On 11/28/2013, 11:26 AM, Diego Sueiro wrote:
> > On Thu, Nov 28, 2013 at 1:49 PM, Bruce Ashfield
> > 
> > mailto:bruce.ashfi...@windriver.com>> wrote:
> > And the patch I attached for the kern-tools to use the dedicated
> > release branch for dylan fixed the other patching issue you were
> > seeing.
> > 
> > This patch was applied in some repo?
> 
> That's why I cc'd Paul on the submission, but I suspect it got lost, since
> I never did get a comment .. and we are all pretty busily juggling multiple
> things at once.
> 
> Paul: can you find the patch in the history of this thread ? If not I
> can resend it directly.

I've still got it in my queue. I'll try to process and send that out tomorrow, 
sorry for the delay.

Cheers,
Paul

-- 

Paul Eggleton
Intel Open Source Technology Centre
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Custom defconfig is not used

[Bruce Ashfield]

On 11/28/2013, 11:41 AM, Paul Eggleton wrote:

Hi Bruce / Diego,

On Thursday 28 November 2013 11:28:41 Bruce Ashfield wrote:

On 11/28/2013, 11:26 AM, Diego Sueiro wrote:

On Thu, Nov 28, 2013 at 1:49 PM, Bruce Ashfield

mailto:bruce.ashfi...@windriver.com>> wrote:
 And the patch I attached for the kern-tools to use the dedicated
 release branch for dylan fixed the other patching issue you were
 seeing.

This patch was applied in some repo?


That's why I cc'd Paul on the submission, but I suspect it got lost, since
I never did get a comment .. and we are all pretty busily juggling multiple
things at once.

Paul: can you find the patch in the history of this thread ? If not I
can resend it directly.


I've still got it in my queue. I'll try to process and send that out tomorrow,
sorry for the delay.


No worries. I of all people understand a merge backlog (as I look at my 
pending

BSP merge list :)

Bruce



Cheers,
Paul



___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] unbootable image produced with PACKAGE_CLASSES ?= "package_ipk", /etc missing

[Robert Yang]

Hi Todd,

I can reproduce the similar problem now, I think that it should be a
bug of e2fsprogs, it seems the debugfs can't know the free space
correctly, and thus it appears no free blocks, I'm sorry to say that
I can't fix it in a short while, but I will fix it in one or two weeks,
maybe you can set this in the local.conf as a workaround:

IMAGE_ROOTFS_EXTRA_SPACE = "51200"

If 51200 is not enough, it can be higher, the unit is Kbytes.


And the todd-new-wandboard-dual.tar.bz2 works well is because it doesn't
generated by debugfs.

// Robert

On 11/29/2013 12:02 AM, Todd Stellanova wrote:

Thanks for taking a look at this Robert!
Below is the ls output: fsck output and bb are attached.

I should note that if I manually copy the bz2 output of bitbake to an
sdcard, like:
sudo tar xjvf
tmp/deploy/images/wandboard-dual/todd-new-wandboard-dual.tar.bz2 -C
/media/rootfs
the image boots fine and contains all the packages I expect.

todd@ubuntu:~/proj/wandboard/fsl-community-bsp/build$ ls -stlh
tmp/deploy/images/wandboard-dual/*.ext3
572M -rw-r--r-- 1 todd todd 572M Nov 27 17:05
tmp/deploy/images/wandboard-dual/todd-new-wandboard-dual-20131128005017.rootfs.ext3
0 lrwxrwxrwx 1 todd todd   50 Nov 27 17:05
tmp/deploy/images/wandboard-dual/todd-new-wandboard-dual.ext3 ->
todd-new-wandboard-dual-20131128005017.rootfs.ext3
435M -rw-r--r-- 1 todd todd 436M Nov 26 16:17
tmp/deploy/images/wandboard-dual/todd-new-wandboard-dual-20131127001137.rootfs.ext3
435M -rw-r--r-- 1 todd todd 436M Nov 26 15:55
tmp/deploy/images/wandboard-dual/todd-new-wandboard-dual-20131126234958.rootfs.ext3
435M -rw-r--r-- 1 todd todd 436M Nov 26 15:36
tmp/deploy/images/wandboard-dual/todd-new-wandboard-dual-20131126232014.rootfs.ext3
435M -rw-r--r-- 1 todd todd 436M Nov 26 14:03
tmp/deploy/images/wandboard-dual/todd-new-wandboard-dual-20131126161048.rootfs.ext3




On Thu, Nov 28, 2013 at 4:48 AM, Robert Yang wrote:



Hi Todd,

I can't reproduce the problem, the rpm has more space than ipk is because
of the IMAGE_ROOTFS_EXTRA_SPACE, which is 50M * 1.3 by default.

Would you please try the following commands:

1) $ ls -stlh tmp/deploy/images/wandboard-dual/core-image-minimal-dev-
wandboard-dual-*.ext3

2) $ fsck.ext4 -fn /path/to/image.ext3

And can you show the bb file if possible ?

// Robert


On 11/27/2013 09:27 AM, Todd Stellanova wrote:


Tried creating a fresh build folder and giving the vm more ram but the
results are basically the same:

Allocated inode: 15264
copy_file: Could not allocate block in ext2 filesystem
debugfs: sif "libgio-2.0.so.0.3800.1" mode 0x81ed

It appears that using package_rpm successfully allocates something like
15968 inodes. When calculating the ROOTFS_SIZE it looks like package_rpm
and package_ipk are using very different values:

package_rpm:

++ du -ks
/fsl-community-bsp/build/tmp/work/wandboard_dual-poky-
linux-gnueabi/todd-new/1.0-r0/rootfs
++ awk '{base_size = $1 * 1.3; base_size = ((base_size > 8192 ? base_size
:
8192) + 0 + *51200*); if (base_size != int(base_size)) base_size =

int(base_size + 1); base_size = base_size + 4096 - 1; base_size -=
base_size % 4096; print base_size }'

+ ROOTFS_SIZE=*458752*


package_ipk:

++ du -ks
/fsl-community-bsp/build/tmp/work/wandboard_dual-poky-
linux-gnueabi/todd-new/1.0-r0/rootfs
++ awk '{base_size = $1 * 1.3; base_size = ((base_size > 8192 ? base_size
:
8192) + 0); if (base_size != int(base_size)) base_size = int(base_size +
1); base_size = base_size + 4096 - 1; base_size -= base_size % 4096; print
base_size }'

+ ROOTFS_SIZE=*376832*


I'm just guessing here, but it seems like package_ipk is underestimating
ROOTFS_SIZE and subsequently populate-extfs.sh fails trying to add files
to
the ext fs.  Any ideas what might cause this?

Thanks for any help!






On Mon, Nov 25, 2013 at 7:03 AM, Todd Stellanova 
wrote:


  Thanks for the ideas. I'll try creating a new build folder. If that still

shows the problem, I'm thinking this has something to do with the fact
that
I'm running the build inside a vm (inside an Ubuntu vm running on a Mac).
It looks like the build is using debugfs...maybe it's running out of ram
at
some point and not obtaining more in the vm properly?

  On Nov 25, 2013, at 5:21 AM, Paul Eggleton <



paul.eggle...@linux.intel.com> wrote:



Hi Nicolas / Todd,

  On Monday 25 November 2013 11:31:42 Nicolas Dechesne wrote:

On Sun, Nov 24, 2013 at 3:51 AM, Todd Stellanova
wrote:


It appears that copying the files to the ext3 / sdcard image is


failing in



*populate-extfs.sh*

I see a series of these errors:

*copy_file: Could not allocate block in ext2 filesystem*

Any idea what might cause this?  I've verified that the initial .tar
archive and the bz2 contain the right files.



can you try to create a new  folder (do not remove the current


one



for now) and reuse the downloads and sstate folder? i am wondering if



there



is a bug when trying to change PACKAGE_CLASSES in an existing 

folder.



I do this not infrequently and never hit