On 2013-01-16 12:02, Brian Smucker wrote:

Hello all,

I'm not sure if my prior question was unclear or if the question was something nobody knows the answer to.

I think there's probably a simple answer, but maybe not.

So the background is this: A poky/danny setup where I have previously-compiled core-image-minimal.

I force busybox to be recompiled: bitbake -c -f compile busybox
I clean core-image-minimal: bitbake -c -f cleansstate core-image-minimal
I rebuild the core image: bitbake core-image-minimal

Result: The busybox that is included in the core-image rootfs is a busybox that was compiled earlier. It has an earlier timestamp.

Question: How do I force the newly-compiled busybox to be included in the core-image rootfs, so that the rootfs generation process does not retrieve some stale version of busybox
from a cache somewhere? (Without deleting the tmp directory. I know that works.)

There's got to be a simple answer.

Thanks,

Brian

ps. This is merely an interim way to test a particular permutation of the busybox config. I know how to make a recipe using bbappend and a new defconfig for busybox. But I want
to do a series of quick-and-dirty tests with various busybox config options.

The problem is that your rebuild of busybox only ran the compile step,
not any of the install or packaging steps.

Thankfully there is a new bitbake option which makes this much easier.
See if this does what you want:
% bitbake busybox -C compile
% bitbake core-image-minimal

--
------------------------------------------------------------
Gary Thomas | Consulting for the
MLB Associates | Embedded world
------------------------------------------------------------

Hello all,

I'm not sure if my prior question was unclear or if the question was something nobody knows the answer to.

I think there's probably a simple answer, but maybe not.

So the background is this: A poky/danny setup where I have previously-compiled core-image-minimal.

I force busybox to be recompiled: bitbake -c -f compile busybox
I clean core-image-minimal: bitbake -c -f cleansstate core-image-minimal
I rebuild the core image: bitbake core-image-minimal

Result: The busybox that is included in the core-image rootfs is a busybox that was compiled earlier. It has an earlier timestamp.

Question: How do I force the newly-compiled busybox to be included in the core-image rootfs, so that the rootfs generation process does not retrieve some stale version of busybox from a cache somewhere? (Without deleting the tmp directory. I know that works.)

There's got to be a simple answer.

Thanks,

Brian

ps. This is merely an interim way to test a particular permutation of the busybox config. I know how to make a recipe using bbappend and a new defconfig for busybox. But I want to do a series of quick-and-dirty tests with various busybox config options.

On Wed, Jan 16, 2013 at 10:23 AM, Brian Smucker <bds@...> wrote:

Hi,

The version of busybox is the same. I've just temporarily done a bitbake -c
menuconfig to change one of the options, recompiled using the custom config
that's generated, and now I want to force its inclusion into
core-image-minimal.

I see. I think that is a bit unorthodox. (Mostly because I have never
tried it. Is it even supposed to work like you describe? I suppose
not. But that aside ...)

If I were doing this, I would create a busybox bbappend in my meta
layer and override the danny stock do_prepare_config() (in
meta/recipes-core/busybox/busybox.inc)

96 do_prepare_config () {
97 sed -e 's#@DATADIR@#${datadir}#g' \
98 < ${WORKDIR}/defconfig > ${S}/.config
99 sed -i -e '/CONFIG_STATIC/d' .config
100 echo "# CONFIG_STATIC is not set" >> .config
101 for i in 'CROSS' 'DISTRO FEATURES'; do echo "### $i"; done >> \
102 ${S}/.config
103 sed -i -e '${configmangle}' ${S}/.config
104 if test ${DO_IPv4} -eq 0 && test ${DO_IPv6} -eq 0; then
105 # disable networking applets
106 mv ${S}/.config ${S}/.config.oe-tmp
107 awk 'BEGIN{net=0}
108 /^# Networking Utilities/{net=1}
109 /^#$/{if(net){net=net+1}}
110 {if(net==2&&$0 !~ /^#/&&$1){print("# "$1" is not
set")}else{print}}' \
111 ${S}/.config.oe-tmp > ${S}/.config
112 fi
113 }

Thanks,

Brian


On 1/16/2013 6:13 AM, Autif Khan wrote:

On Tue, Jan 15, 2013 at 6:57 PM, Brian Smucker <bds@...>
wrote:

Hi Rudolf,


On 1/15/2013 3:28 PM, Rudolf Streif wrote:

Brian,

What are you exactly referring to as "new version"? The package version
that bitbake builds is defined by the recipe, through the version
designation in the recipe's file name or through explicitly setting PV.

I think what you are trying to do is to modify the busybox configuration
and then recompile and package. Bitbake will not automatically recompile
after menuconfig. Menuconfig does not invslidate the shared state cache.
Try
this:

bitbake -c menuconfig busybox
bitbake -c -f compile busybox
bitbake busybox

So I have done the above. That is not the question. Busybox compiles
fine
and the new unstripped busybox is in the

.../yocto/tmp/work/armv4t-poky-linux-gnueabi/busybox-1.20.2-r2/busybox-1.20.2/

What is the new version of busybox?

What is the full filename of the new recipe that you created to
compile a new version of busybox? For example the old one is
busybox_1.20.2.bb (in meta/recipes-core/busybox)

Also, can you please paste the .bb file in the email

My question is that after compiling busybox, I do

bitbake -c cleansstate core-image-minimal
bitbake core-image-minimal

expecting that the core image generated will contain the new busybox. It
does not, it contains a busybox copy that was compiled days ago, not the
custom one I just compiled.

Why is this? How can I force the bitbake to include the newly-compiled
busybox into my minimal image?


Thanks,

Brian

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

On Wed, Jan 16, 2013 at 1:14 PM, Paul Eggleton
<paul.eggleton@...> wrote:

On Wednesday 16 January 2013 23:26:20 Navani Srivastava wrote:

On Thu, Dec 27, 2012 at 11:08 PM, Jon Szymaniak

<jon.szymaniak@...>wrote:

I am compiling Qt-4.8.0 with poky-denzil-7.0 for arm1136
architecture.

At the time of integrating qt-embedded with rootfs, I am getting
qtopia
directory in usr/share path of rootfs.

I tried removing qtopia directory through qt recipe but ended in
compilation error. Please suggest any idea to remove qtopia from
share
directory.

I ran into this as well after using a bbappend to disable a number
of
Qt features, including the building of demos that get staged in the
aforementioned path. In my case, that qtopia directory (and any
subdirectories) wound up either being empty or containing files that
were unnecessary for my build.

My quick and dirty solution was to just to add a install_append()
containing a 'rm -rf ${D}${datadir}/qtopia' in my bbappend. (Be sure
you don't have anything important in there!) I'd be curious to hear
if
there's a better approach to this as well...

Oops...just wanted to note the typo in my above response -- I'm not at
a machine where I have access to my recipes.

That should be a do_install_append(), not install_append(). I'd also
double check the qtopia path, as I wrote that from memory, which may
not be reliable. ;)

I tried the same but again ended up with error. As of now i am removing
all
unwanted things from rootfs by making changes in image_types.bbclass. I
am
sure this is not the correct way, any ideas are appreciated..

Can I ask both of you exactly how you are getting Qt installed into the
image?

Cheers,
Paul

--

Paul Eggleton
Intel Open Source Technology Centre

I'm not doing anything too unusual for "installing" Qt. My recipes for
my Qt application simply inherit qt4e, and list qt4-embedded in
DEPENDS.

The only place where I deviated a bit from the norm is that I use a
qt4-embedded_4.8.3.bbappend to set up QT_CONFIG_FLAGS exactly as I
want them, and to rm ${D}/usr/bin/qtopia. Below's my bbappend. I'd be
interested to hear if there's a better way to clean out unneeded
directories from a rootfs (in my case ${D}/usr/bin/qtopia).

DEPENDS = "qt4-tools-native freetype jpeg libpng zlib"

# Override provided recipe and configure Qt4 to...
# - Disable irrelevant functionality and output
# - Disable SQL Plugins
# - Disable unused input/ouput
# - Have keyboard input and mouse input via /dev/input/mice
# - Have Linux framebuffer support
# - Use QML (so we need the declarative engine)
#
# Note, some of these might be extraneous, and this is a work in progress.
# (You've been warned!)
QT_CONFIG_FLAGS = "\
-embedded ${QT_ARCH} -qtlibinfix ${QT_LIBINFIX} \
-release -no-rpath -reduce-relocations -shared -no-exceptions \
-no-mmx -no-3dnow -no-sse -no-sse2 -no-sse3 -no-sse4.1 -no-sse4.2 -no-avx \
-no-glib -no-largefile -no-accessibility -no-openssl -no-gtkstyle \
-no-xcursor -no-xinerama -no-phonon -no-phonon-backend -no-svg -no-webkit \
-no-libmng -no-accessibility -no-qt3support -no-xmlpatterns \
-no-audio-backend -no-gif -nomake examples -nomake demos -no-javascript-jit \
-no-nis -no-cups -no-declarative-debug \
-no-sql-db2 -no-sql-ibase -no-sql-mysql -no-sql-oci -no-sql-odbc \
-no-sql-sqlite -no-sql-sqlite2 -no-sql-sqlite_symbian -no-sql-tds \
-no-xkb -no-kbd-tty -no-kbd-qnx -no-mouse-linuxinput \
-no-mouse-tslib -no-mouse-qnx -no-mouse-linuxtp \
-qt-mouse-pc -qt-kbd-linuxinput \
-qt-gfx-linuxfb -qt-gfx-multiscreen \
-depths 8,16,24,32 \
-declarative -script"

PRINC := "${@int(PRINC) + 1}"

# Despite not building them, qt4.inc creates /usr/bin/qtopia/ with
# only demo/ and example/ underneath. Let's get rid of these...
do_install_append() {
rm -rf ${D}/usr/bin/qtopia
}

On Wednesday 16 January 2013 23:26:20 Navani Srivastava wrote:

On Thu, Dec 27, 2012 at 11:08 PM, Jon Szymaniak

<jon.szymaniak@...>wrote:

I am compiling Qt-4.8.0 with poky-denzil-7.0 for arm1136 architecture.

At the time of integrating qt-embedded with rootfs, I am getting qtopia
directory in usr/share path of rootfs.

I tried removing qtopia directory through qt recipe but ended in
compilation error. Please suggest any idea to remove qtopia from share
directory.

I ran into this as well after using a bbappend to disable a number of
Qt features, including the building of demos that get staged in the
aforementioned path. In my case, that qtopia directory (and any
subdirectories) wound up either being empty or containing files that
were unnecessary for my build.

My quick and dirty solution was to just to add a install_append()
containing a 'rm -rf ${D}${datadir}/qtopia' in my bbappend. (Be sure
you don't have anything important in there!) I'd be curious to hear if
there's a better approach to this as well...

Oops...just wanted to note the typo in my above response -- I'm not at
a machine where I have access to my recipes.

That should be a do_install_append(), not install_append(). I'd also
double check the qtopia path, as I wrote that from memory, which may
not be reliable. ;)

I tried the same but again ended up with error. As of now i am removing all
unwanted things from rootfs by making changes in image_types.bbclass. I am
sure this is not the correct way, any ideas are appreciated..

Can I ask both of you exactly how you are getting Qt installed into the image?

Cheers,
Paul

--

Paul Eggleton
Intel Open Source Technology Centre

On 01/15/2013 10:38 AM, Bruce Ashfield wrote:

On 13-01-15 01:26 PM, Patrick Turley wrote:

On Jan 15, 2013, at 12:00 PM, Bruce Ashfield <bruce.ashfield@...>
wrote:

On 13-01-15 12:54 PM, Patrick Turley wrote:

Thank you for directing me toward that documentation. As it happens, I
have already read that, and it doesn't apply.

There are ways to do this, your requirement is the same as the on-target
module building requirement. Have enough of the kernel source packaged
to build modules on the target, after it has booted.

Well, I still want to cross-compile them, but I see your point.

The trick is packaging things properly to not get binary/target elements
in the SDK/native packages, and to package just enough for the build. But
the issues have been explored and there was a plan. I know that Darren
(cc'd) has looked into this more than I have recently.

I can't locate the bugzilla entries on this at the moment, but I recall
that some parts were still missing, but may be addressed in yocto 1.4,
when I find the bug numbers, I'll have a better idea.

As I expected, someone else has already thought about this. This isn't the most common approach so it makes sense that it's been a lower priority. The good news for me is that I know I'm not missing something, so I can stop looking for it.

I finally found the entries that I was recalling earlier. They are:

https://bugzilla.yoctoproject.org/show_bug.cgi?id=241
https://bugzilla.yoctoproject.org/show_bug.cgi?id=1614
https://bugzilla.yoctoproject.org/show_bug.cgi?id=2968

1614 and 2968 are the most interesting for what you are asking.

As you can see the net result of those bugs is that you can get the
right parts of the kernel tree in SDK packages, since they include
dev packages, and with what is currently in kernel-dev .. it should
be enough to build against in the SDK (perhaps with just the LDFLAGS
tweaks mentioned in the other thread). The sources should be part
of the sysroot, and hence available when that is packaged for use
outside of bitbake/yocto.

If you aren't seeing kernel-dev in the SDK image, it might be that
TOOLCHAIN_TARGET_TASK doesn't have kernel-dev by default, or something
else is different in the SDK that is being generated in your testing.

I'm only speculating about what might be missing, since I'm not 100%
familiar with the SDK, but perhaps Jessica or others can chime in if
I've led you astray :)

Thanks for keeping this going Bruce. Yes, kernel-dev is the package for
the target. The only trick here is that we currently purge the host
binaries which means that you need to build scripts on the target prior
to building the module.

I think this might be missing from the new kernel manual as it isn't a
particularly common use-case, and is rather orthogonal to the way the
tooling has been designed (not to say it can't be done).

Patrick, please keep us posted if this continues to not work for you. I
will open a bug to include a section about this in the kernel
development manual.

--
Darren Hart
Intel Open Source Technology Center
Yocto Project - Technical Lead - Linux Kernel

Hi,

The version of busybox is the same. I've just temporarily done a bitbake -c menuconfig to change one of the options, recompiled using the custom config that's generated, and now I want to force its inclusion into core-image-minimal.

Thanks,

Brian

On 16/01/2013 14:11, Gary Thomas wrote:

On 2013-01-16 07:02, Alex J Lennon wrote:

On 16/01/2013 13:59, Robert P. J. Day wrote:

On Wed, 16 Jan 2013, Alex J Lennon wrote:

On 16/01/2013 05:45, Ed Nelson wrote:

I finally got a response back from github ....

Hi Ed,

We tracked the issue down to an internal network timeout (it only happens
when `--quiet` is used, because git is silent on the network while preparing
the clone in that case). We've bumped up the limit, and you should be able
to clone now. Please let us know if you have any more trouble.

....

I have not tried it yet but hopefully they fixed the problem

I've just tried it and it is still failing -

WARNING: Failed to fetch URL
git://github.com/raspberrypi/linux.git;protocol=git;branch=rpi-3.2.27,
attempting MIRRORS if available
ERROR: Fetcher failure: Fetch command failed with exit code 128, output:
Cloning into bare repository
'/data_drive/RPiMonoSmoke/yoctoProject/raspberryPiBuild/downloads/git2/github.com.raspberrypi.linux.git'...

fatal: read error: Connection timed out
fatal: early EOF
fatal: index-pack failed

ERROR: Function failed: Fetcher failure for URL:
'git://github.com/raspberrypi/linux.git;protocol=git;branch=rpi-3.2.27'.
Unable to fetch URL from any source.

github has been particularly annoying with respect to this lately.
my workaround is to simply clone what you need manually, then tweak
the recipe thusly to point at your local repo:

SRCREV = "10182a3bc434b27740f81c2b836a1af943060241"
SRC_URI =
"git:///home/rpjday/oe/dist/t/linux;protocol=git;branch=rpi-3.2.27 \
"

yes, it's hacky, but it lets me get back to work. sure be nice when
this silliness is resolved.

rday

Thanks Robert. I've got an archive I can use but wanted to see if it was working yet.

I think the fetcher archives up the retrieved git repo into a .tar.gz doesn't it in the downloads
directory? Would it not help if those tarballs were mirrored so the fetcher could fall back on
the mirror?

Yes, that would work (it's how I use it). However, it's not tiny :-) Here's what the
tarball looked like last I touched this:

-rw-rw-r-- 1 996 996 555905690 Sep 5 10:29 /work/misc/Poky/sources/git2_github.com.raspberrypi.linux.git.tar.gz

Quite :) I took a look in classes/mirrors.bbclass and I see a Yocto mirror URI in there for git://

http://downloads.yoctoproject.org/mirror/sources/

I see that there are similar sized linux yocto tarballs mirrored at that location. Would it be appropriate to
mirror the RPi kernel tarball up there for the time being?

Cheers, Alex

On Tue, Jan 15, 2013 at 6:57 PM, Brian Smucker <bds@...> wrote:

Hi Rudolf,


On 1/15/2013 3:28 PM, Rudolf Streif wrote:

Brian,

What are you exactly referring to as "new version"? The package version
that bitbake builds is defined by the recipe, through the version
designation in the recipe's file name or through explicitly setting PV.

I think what you are trying to do is to modify the busybox configuration
and then recompile and package. Bitbake will not automatically recompile
after menuconfig. Menuconfig does not invslidate the shared state cache. Try
this:

bitbake -c menuconfig busybox
bitbake -c -f compile busybox
bitbake busybox

So I have done the above. That is not the question. Busybox compiles fine
and the new unstripped busybox is in the
.../yocto/tmp/work/armv4t-poky-linux-gnueabi/busybox-1.20.2-r2/busybox-1.20.2/

What is the new version of busybox?

What is the full filename of the new recipe that you created to
compile a new version of busybox? For example the old one is
busybox_1.20.2.bb (in meta/recipes-core/busybox)

Also, can you please paste the .bb file in the email

My question is that after compiling busybox, I do

bitbake -c cleansstate core-image-minimal
bitbake core-image-minimal

expecting that the core image generated will contain the new busybox. It
does not, it contains a busybox copy that was compiled days ago, not the
custom one I just compiled.

Why is this? How can I force the bitbake to include the newly-compiled
busybox into my minimal image?


Thanks,

Brian

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

On 2013-01-16 07:02, Alex J Lennon wrote:

On 16/01/2013 13:59, Robert P. J. Day wrote:

On Wed, 16 Jan 2013, Alex J Lennon wrote:

On 16/01/2013 05:45, Ed Nelson wrote:

I finally got a response back from github ....

Hi Ed,

We tracked the issue down to an internal network timeout (it only happens
when `--quiet` is used, because git is silent on the network while preparing
the clone in that case). We've bumped up the limit, and you should be able
to clone now. Please let us know if you have any more trouble.

....

I have not tried it yet but hopefully they fixed the problem

I've just tried it and it is still failing -

WARNING: Failed to fetch URL
git://github.com/raspberrypi/linux.git;protocol=git;branch=rpi-3.2.27,
attempting MIRRORS if available
ERROR: Fetcher failure: Fetch command failed with exit code 128, output:
Cloning into bare repository
'/data_drive/RPiMonoSmoke/yoctoProject/raspberryPiBuild/downloads/git2/github.com.raspberrypi.linux.git'...

fatal: read error: Connection timed out
fatal: early EOF
fatal: index-pack failed

ERROR: Function failed: Fetcher failure for URL:
'git://github.com/raspberrypi/linux.git;protocol=git;branch=rpi-3.2.27'.
Unable to fetch URL from any source.

github has been particularly annoying with respect to this lately.
my workaround is to simply clone what you need manually, then tweak
the recipe thusly to point at your local repo:

SRCREV = "10182a3bc434b27740f81c2b836a1af943060241"
SRC_URI =
"git:///home/rpjday/oe/dist/t/linux;protocol=git;branch=rpi-3.2.27 \
"

yes, it's hacky, but it lets me get back to work. sure be nice when
this silliness is resolved.

rday

Thanks Robert. I've got an archive I can use but wanted to see if it was working yet.

I think the fetcher archives up the retrieved git repo into a .tar.gz doesn't it in the downloads
directory? Would it not help if those tarballs were mirrored so the fetcher could fall back on
the mirror?

Yes, that would work (it's how I use it). However, it's not tiny :-) Here's what the
tarball looked like last I touched this:

-rw-rw-r-- 1 996 996 555905690 Sep 5 10:29 /work/misc/Poky/sources/git2_github.com.raspberrypi.linux.git.tar.gz

--
------------------------------------------------------------
Gary Thomas | Consulting for the
MLB Associates | Embedded world
------------------------------------------------------------

On Wed, 16 Jan 2013, Alex J Lennon wrote:

On 16/01/2013 13:59, Robert P. J. Day wrote:

On Wed, 16 Jan 2013, Alex J Lennon wrote:

On 16/01/2013 05:45, Ed Nelson wrote:

I finally got a response back from github ....

Hi Ed,

We tracked the issue down to an internal network timeout (it only
happens
when `--quiet` is used, because git is silent on the network while
preparing
the clone in that case). We've bumped up the limit, and you should be
able
to clone now. Please let us know if you have any more trouble.

....

I have not tried it yet but hopefully they fixed the problem

I've just tried it and it is still failing -

WARNING: Failed to fetch URL
git://github.com/raspberrypi/linux.git;protocol=git;branch=rpi-3.2.27,
attempting MIRRORS if available
ERROR: Fetcher failure: Fetch command failed with exit code 128, output:
Cloning into bare repository
'/data_drive/RPiMonoSmoke/yoctoProject/raspberryPiBuild/downloads/git2/github.com.raspberrypi.linux.git'...

fatal: read error: Connection timed out
fatal: early EOF
fatal: index-pack failed

ERROR: Function failed: Fetcher failure for URL:
'git://github.com/raspberrypi/linux.git;protocol=git;branch=rpi-3.2.27'.
Unable to fetch URL from any source.

github has been particularly annoying with respect to this lately.
my workaround is to simply clone what you need manually, then tweak
the recipe thusly to point at your local repo:

SRCREV = "10182a3bc434b27740f81c2b836a1af943060241"
SRC_URI =
"git:///home/rpjday/oe/dist/t/linux;protocol=git;branch=rpi-3.2.27 \
"

yes, it's hacky, but it lets me get back to work. sure be nice when
this silliness is resolved.

rday

Thanks Robert. I've got an archive I can use but wanted to see if it was
working yet.

wait a minute, what i wrote above can't be right, i have a wiki page
for this:

http://www.crashcourse.ca/wiki/index.php/Building_basic_RPi_image

which shows my recipe mods to look like:

-SRC_URI = "git://github.com/raspberrypi/linux.git;protocol=git;branch=rpi-3.2.27 \
+SRC_URI = "git:///home/rpjday/oe/dist/t/linux;protocol=file;branch=rpi-3.2.27 \

not sure where i got the earlier stuff i posted.

I think the fetcher archives up the retrieved git repo into a
.tar.gz doesn't it in the downloads directory? Would it not help if
those tarballs were mirrored so the fetcher could fall back on the
mirror?

my setup always creates tarballs from whatever is fetched so, once
that's done, i always end up using local tarballs. i have a wiki page
which explains how to create your own local mirror of tarballs:

http://www.crashcourse.ca/wiki/index.php/OE_Creating_your_%22own_mirror%22

rday

--

========================================================================
Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca

Twitter: http://twitter.com/rpjday
LinkedIn: http://ca.linkedin.com/in/rpjday
========================================================================

On 16/01/2013 13:59, Robert P. J. Day wrote:

On Wed, 16 Jan 2013, Alex J Lennon wrote:

On 16/01/2013 05:45, Ed Nelson wrote:

I finally got a response back from github ....

Hi Ed,

We tracked the issue down to an internal network timeout (it only happens
when `--quiet` is used, because git is silent on the network while preparing
the clone in that case). We've bumped up the limit, and you should be able
to clone now. Please let us know if you have any more trouble.

....

I have not tried it yet but hopefully they fixed the problem

I've just tried it and it is still failing -

WARNING: Failed to fetch URL
git://github.com/raspberrypi/linux.git;protocol=git;branch=rpi-3.2.27,
attempting MIRRORS if available
ERROR: Fetcher failure: Fetch command failed with exit code 128, output:
Cloning into bare repository
'/data_drive/RPiMonoSmoke/yoctoProject/raspberryPiBuild/downloads/git2/github.com.raspberrypi.linux.git'...

fatal: read error: Connection timed out
fatal: early EOF
fatal: index-pack failed

ERROR: Function failed: Fetcher failure for URL:
'git://github.com/raspberrypi/linux.git;protocol=git;branch=rpi-3.2.27'.
Unable to fetch URL from any source.

github has been particularly annoying with respect to this lately.
my workaround is to simply clone what you need manually, then tweak
the recipe thusly to point at your local repo:

SRCREV = "10182a3bc434b27740f81c2b836a1af943060241"
SRC_URI =
"git:///home/rpjday/oe/dist/t/linux;protocol=git;branch=rpi-3.2.27 \
"

yes, it's hacky, but it lets me get back to work. sure be nice when
this silliness is resolved.

rday

Thanks Robert. I've got an archive I can use but wanted to see if it was working yet.

I think the fetcher archives up the retrieved git repo into a .tar.gz doesn't it in the downloads
directory? Would it not help if those tarballs were mirrored so the fetcher could fall back on
the mirror?

Cheers, Alex

On Wed, 16 Jan 2013, Alex J Lennon wrote:

On 16/01/2013 05:45, Ed Nelson wrote:

I finally got a response back from github ....

Hi Ed,

We tracked the issue down to an internal network timeout (it only happens
when `--quiet` is used, because git is silent on the network while preparing
the clone in that case). We've bumped up the limit, and you should be able
to clone now. Please let us know if you have any more trouble.

....

I have not tried it yet but hopefully they fixed the problem

I've just tried it and it is still failing -

WARNING: Failed to fetch URL
git://github.com/raspberrypi/linux.git;protocol=git;branch=rpi-3.2.27,
attempting MIRRORS if available
ERROR: Fetcher failure: Fetch command failed with exit code 128, output:
Cloning into bare repository
'/data_drive/RPiMonoSmoke/yoctoProject/raspberryPiBuild/downloads/git2/github.com.raspberrypi.linux.git'...

fatal: read error: Connection timed out
fatal: early EOF
fatal: index-pack failed

ERROR: Function failed: Fetcher failure for URL:
'git://github.com/raspberrypi/linux.git;protocol=git;branch=rpi-3.2.27'.
Unable to fetch URL from any source.

github has been particularly annoying with respect to this lately.
my workaround is to simply clone what you need manually, then tweak
the recipe thusly to point at your local repo:

SRCREV = "10182a3bc434b27740f81c2b836a1af943060241"
SRC_URI =
"git:///home/rpjday/oe/dist/t/linux;protocol=git;branch=rpi-3.2.27 \
"

yes, it's hacky, but it lets me get back to work. sure be nice when
this silliness is resolved.

rday

--

========================================================================
Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca

Twitter: http://twitter.com/rpjday
LinkedIn: http://ca.linkedin.com/in/rpjday
========================================================================

On 16/01/2013 05:45, Ed Nelson wrote:

I finally got a response back from github ....

Hi Ed,

We tracked the issue down to an internal network timeout (it only happens when `--quiet` is used, because git is silent on the network while preparing the clone in that case). We've bumped up the limit, and you should be able to clone now. Please let us know if you have any more trouble.

....

I have not tried it yet but hopefully they fixed the problem

I've just tried it and it is still failing -

WARNING: Failed to fetch URL git://github.com/raspberrypi/linux.git;protocol=git;branch=rpi-3.2.27, attempting MIRRORS if available
ERROR: Fetcher failure: Fetch command failed with exit code 128, output:
Cloning into bare repository '/data_drive/RPiMonoSmoke/yoctoProject/raspberryPiBuild/downloads/git2/github.com.raspberrypi.linux.git'...

fatal: read error: Connection timed out
fatal: early EOF
fatal: index-pack failed

ERROR: Function failed: Fetcher failure for URL: 'git://github.com/raspberrypi/linux.git;protocol=git;branch=rpi-3.2.27'. Unable to fetch URL from any source.

Alex

Thanks
Ed

Hello All,

I'm a relative newbie to yocto/oe, but have got a ways down the road to
understanding, but the gaps in my understanding cause me great grief at
times.

I think this probably is a simple question, but somehow I'm doing
something wrong.

I am trying to build altiris_7.1.8280 for x86 platform. It is unable to create folder

pravin@Desktop-System:~/tools/yocto/poky-danny-8.0/build/tmp/work/core2-poky-linux/altiris-7.1.8280-1

 

Step to build

1. bitbake -b ../meta/recipes-tos/altiris/altiris_7.1.8280.bb

2. bitbake altiris

 

- altiris_7.1.8280.bb recipe migrated from oe-classic to yocto.

- I tried altiris recipe in oe-core as well as yocto. Sometimes it creates image folder in ${WORKDIR} after cleaning recipe with -c clean option & again build it then it will not created.

 

parmod@ubuntu:~/pravin/oe-core_2/oe-core/build$ bitbake -b ../meta/recipes-tos/altiris/altiris_7.1.8280.bb
WARNING: Buildfile specified, dependencies will not be handled. If this is not what you want, do not use -b / --buildfile.

Build Configuration:
BB_VERSION        = "1.17.0"
BUILD_SYS         = "i686-linux"
NATIVELSBSTRING   = "Ubuntu-10.04"
TARGET_SYS        = "i586-oe-linux"
MACHINE           = "qemux86"
DISTRO_VERSION    = "oe-core.0"
TUNE_FEATURES     = "m32 i586"
TARGET_FPU        = ""
meta              = "master:99f003356be43bb361634359a5d3c520f72f0a08"

NOTE: Preparing runqueue
NOTE: Executing SetScene Tasks
NOTE: Executing RunQueue Tasks
NOTE: Tasks Summary: Attempted 12 tasks of which 10 didn't need to be rerun and all succeeded.

Summary: There was 1 WARNING message shown.
parmod@ubuntu:~/pravin/oe-core_2/oe-core/build$

parmod@ubuntu:~/pravin/oe-core_2/oe-core/build$ ls tmp-eglibc/work/i586-oe-linux/altiris/7.1.8280-1        
altiris      license-destdir  packages-split  pseudo                     sstate-install-package       sstate-install-populate-sysroot  temp
deploy-ipks  package          pkgdata         sstate-install-deploy-ipk  sstate-install-populate-lic  sysroot-destdir
parmod@ubuntu:~/pravin/oe-core_2/oe-core/build$

 

Can some one help me on the same issue ?

 

 

Thanks & Regards,

        PraviN

 

 

 

 

 

 

 

Signed-off-by: Björn Stenberg <bjst@...>
---
diff --git a/scripts/runqemu b/scripts/runqemu
index fb7ac56..fc7d749 100755
--- a/scripts/runqemu
+++ b/scripts/runqemu
@@ -155,7 +155,7 @@ while true; do
;;
"kvm")
KVM_ENABLED="yes"
- KVM_CAPABLE=`grep -q 'vmx\|smx' /proc/cpuinfo && echo 1`
+ KVM_CAPABLE=`grep -q 'vmx\|svm' /proc/cpuinfo && echo 1`
;;
"") break ;;
*)

--
Björn

Dear Bruce,

In message <50F59A91.5080806@...> you wrote:

Yes, it's clear to me that, in this one respect, the SDK is unsuitable
for building kernels or kernel modules.

My point is that this is a problem, and it might be reasonable to fix it.

This is indeed a problem, and not only with the kernel, but also for
example with U-Boot - fortunately there are not that many software
packages that need to tweak with linker scripts etc. so they need to
call the linker directly.

You probably want Jessica or Richard to comment on the architecture /
design of the SDK with respect to kernel elements. The only packaging
for out of tree / non build system builds that I know I've ever looked
into are on target, or staging directory builds of modules.

...

Everyone/Everything has their reasons for the different workflow(s).
(I maintain the ability to build all the boards covered in linux-yocto
without the need for any build system at all, as an example). And all
workflows are definitely valid, but it is expected that the primary
workflow for anything oe/bitbake based would be centered around recipes.

I found it difficult to find any formal definition of what LDFLAGS is
supposed to be. The most authoritative appears to be the definition
as given by the make(1) documentation - as this is where LDFLAGS
actually gets used:

`LDFLAGS'
Extra flags to give to compilers when they are supposed
to invoke the linker, `ld'.

Note the phrase "flags to give to compilers", i. e. this clearly
states that the linking is supposed to be done by running the compiler
frontend, and not the linker directly.

So even though we feel the recent version breaks old habits, it seems
that simply our old habits were based on incorrect assumptions.

I see no reason to fix the current settings, but perhaps it would be
helpful to clearly document this behaviour and recommend a workaround.

At least this was what we did for our Yocto based ELDK [1].

[1] http://www.denx.de/wiki/view/ELDK-5/FrequentlyAskedQuestionsAndAnswers#Compiling_U_Boot_or_Linux_fails

Best regards,

Wolfgang Denk

--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@...
Steal five dollars and you were a petty thief. Steal thousands of
dollars and you are either a government or a hero.
- Terry Pratchett, _Going_Postal_

On Tue, Jan 15, 2013 at 10:44 PM, Saul Wold <sgw@...> wrote:

On 01/15/2013 08:37 PM, McClintock Matthew-B29882 wrote:

On Tue, Jan 15, 2013 at 7:09 PM, Flanagan, Elizabeth
<elizabeth.flanagan@...> wrote:

- p1022ds failed due to a libxml2_2.8.0 failure. it is also throwing
warnings about missing patches.

I've got a master-next branch I'm testing now and should be on master
soon. I'm also debugging the oprofile issues from nightly-ppc as well.

There is a patch from Bogdan for this one, see "oprofile: set correct kernel
path", there is clearly more work needed here, but that will get us past
this failure until we get the libpfm recipe in, which looks like it will be
required also.

I made a recipe for libpfm3 and libpfm4 so let me submit those before
anyone else spends time on it.

-M

On 01/15/2013 08:37 PM, McClintock Matthew-B29882 wrote:

On Tue, Jan 15, 2013 at 7:09 PM, Flanagan, Elizabeth
<elizabeth.flanagan@...> wrote:

- p1022ds failed due to a libxml2_2.8.0 failure. it is also throwing
warnings about missing patches.

I've got a master-next branch I'm testing now and should be on master
soon. I'm also debugging the oprofile issues from nightly-ppc as well.

There is a patch from Bogdan for this one, see "oprofile: set correct kernel path", there is clearly more work needed here, but that will get us past this failure until we get the libpfm recipe in, which looks like it will be required also.

Sau!

-M