Date   

Re: Busybox still old version: Still looking for a clear understanding of an old mystery.

Autif Khan <autif.mlist@...>
 

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


Re: Raspberry Pi do_fetch failure

Gary Thomas
 

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
------------------------------------------------------------


Re: Raspberry Pi do_fetch failure

Robert P. J. Day
 

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
========================================================================


Re: Raspberry Pi do_fetch failure

Alex J Lennon <ajlennon@...>
 

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


Re: Raspberry Pi do_fetch failure

Robert P. J. Day
 

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
========================================================================


Re: Raspberry Pi do_fetch failure

Alex J Lennon <ajlennon@...>
 

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


migrating oe-classic to yocto Facing problem unable to create image folder in ${WORKDIR}/image

Pravin Mahadev Shedage <pravin.sh@...>
 

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

 

 

 

 

 

 

 


[PATCH] For danny: Fix typo in kvm capability detection in runqemu

Björn Stenberg <bjorn@...>
 

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


Re: SDK environment LDFLAGS problem?

Wolfgang Denk <wd@...>
 

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_


Re: Weekly build availability.

McClintock Matthew-B29882 <B29882@...>
 

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


Re: Weekly build availability.

Saul Wold <sgw@...>
 

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


Re: Weekly build availability.

McClintock Matthew-B29882 <B29882@...>
 

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.

-M


Re: Weekly build availability.

Saul Wold <sgw@...>
 

QA Teams:

Please do FULL Pass testing on this as a PRE-M3 Full Pass so we have some idea of what's going on.

Git Rev: 9eb88ceb39b7d0b8ddc6487e61ce8edadef10ec4

On 01/15/2013 05:09 PM, Flanagan, Elizabeth wrote:
The weekly build is available at:

http://autobuilder.yoctoproject.org/pub/nightly/20130115-2

Known issues:

- The eclipse plugin needs to be built alone and moved manually. I'm
doing this right now. This is due to moving the eclipse builder to a
slightly overloaded machine. I'll be moving it back once I have idle
time on the infrastructure.
- p1022ds failed due to a libxml2_2.8.0 failure. it is also throwing
warnings about missing patches.
- nightly-fsl-arm core-image-x11 failed. Multiple providers for
virtual/libgl and compile issues for beecrypt and avahi
- nightly-ppc failed on oprofile
This is a known issue and there is a patch on stage/master_under_test for this


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


Weekly build availability.

Flanagan, Elizabeth <elizabeth.flanagan@...>
 

The weekly build is available at:

http://autobuilder.yoctoproject.org/pub/nightly/20130115-2

Known issues:

- The eclipse plugin needs to be built alone and moved manually. I'm
doing this right now. This is due to moving the eclipse builder to a
slightly overloaded machine. I'll be moving it back once I have idle
time on the infrastructure.
- p1022ds failed due to a libxml2_2.8.0 failure. it is also throwing
warnings about missing patches.
- nightly-fsl-arm core-image-x11 failed. Multiple providers for
virtual/libgl and compile issues for beecrypt and avahi
- nightly-ppc failed on oprofile


-b


Re: Busybox still old version: Still looking for a clear understanding of an old mystery.

Brian Smucker
 

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/

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


Re: [PATCH] [Bug #3963][eclipse-poky][branch:denzil]

Zhang, Jessica
 

Merged to eclipse-poky denzil.

Thanks,
Jessica

-----Original Message-----
From: yocto-bounces@... [mailto:yocto-bounces@...] On Behalf Of Ioana Grigoropol
Sent: Tuesday, January 15, 2013 8:40 AM
To: yocto@...
Subject: [yocto] [PATCH] [Bug #3963][eclipse-poky][branch:denzil]

- source oe-init-build-env each time a command is ran using yocto-bsp tool

Signed-off-by: Ioana Grigoropol <ioanax.grigoropol@...>
---
.../sdk/remotetools/wizards/bsp/MainPage.java | 86 ++++++++++++++++++--
.../remotetools/wizards/bsp/PropertiesPage.java | 16 ++--
2 files changed, 89 insertions(+), 13 deletions(-)

diff --git a/plugins/org.yocto.sdk.remotetools/src/org/yocto/sdk/remotetools/wizards/bsp/MainPage.java b/plugins/org.yocto.sdk.remotetools/src/org/yocto/sdk/remotetools/wizards/bsp/MainPage.java
index aa1c124..f7dea27 100644
--- a/plugins/org.yocto.sdk.remotetools/src/org/yocto/sdk/remotetools/wizards/bsp/MainPage.java
+++ b/plugins/org.yocto.sdk.remotetools/src/org/yocto/sdk/remotetools/wi
+++ zards/bsp/MainPage.java
@@ -56,6 +56,7 @@ public class MainPage extends WizardPage {
private static final String PROPERTIES_CMD_PREFIX = "yocto-bsp list ";
private static final String PROPERTIES_CMD_SURFIX = " properties -o ";
private static final String PROPERTIES_FILE = "/tmp/properties.json";
+ static final String INIT_FILE = "/oe-init-build-env";

private Button btnMetadataLoc;
private Button btnBspOutLoc;
@@ -287,8 +288,18 @@ public class MainPage extends WizardPage {
}

bspElem.setBspName(bspname);
+// if (!textBspOutLoc.getText().isEmpty())
+// bspElem.setBspOutLoc(textBspOutLoc.getText());
if (!textBspOutLoc.getText().isEmpty())
bspElem.setBspOutLoc(textBspOutLoc.getText());
+ else
+ bspElem.setBspOutLoc("");
+ if (!textBspOutLoc.getText().isEmpty())
+ bspElem.setBuildLoc(textBspOutLoc.getText());
+ else {
+ bspElem.setBuildLoc(metadata_loc + "/build");
+ checkBuildDir();
+ }
bspElem.setMetadataLoc(metadata_loc);
bspElem.setKarch(karch);
bspElem.setQarch(qarch);
@@ -296,6 +307,53 @@ public class MainPage extends WizardPage {

return true;
}
+ private Status createBuildDir(String buildLoc) {
+ String metadataDir = textMetadataLoc.getText();
+
+ // if we do not change the directory to metadata location the script will be looked into the directory indicated by user.dir system property
+ // system.property usually points to the location from where eclipse was started
+ String createBuildDirCmd = "cd " + metadataDir + ";source " +
+metadataDir + INIT_FILE + " " + buildLoc;
+
+ try {
+ ProcessBuilder builder = new ProcessBuilder(new String[] {"sh", "-c", createBuildDirCmd});
+ Process proc = builder.start();
+ InputStream errorStream = proc.getErrorStream();
+ InputStreamReader isr = new InputStreamReader(errorStream);
+ BufferedReader br = new BufferedReader(isr);
+ String line = null;
+ String status = "";
+ while ( (line = br.readLine()) != null) {
+ status += line;
+ }
+
+ if (proc.waitFor() != 0)
+ return new Status(IStatus.ERROR, "not_used", 0, status, null);;
+ return new Status(IStatus.OK, "not_used", 0, "", null);
+ } catch (Exception e) {
+ return new Status(IStatus.ERROR, "not_used", 0, e.getMessage(), null);
+ }
+ }
+ private Status checkBuildDir() {
+
+ String metadataLoc = textMetadataLoc.getText();
+
+ String buildLoc = metadataLoc + "/build";
+ return createBuildDir(buildLoc);
+ }
+ private String getBuildDir() {
+
+ String metadataLoc = textMetadataLoc.getText();
+ String buildLoc = textBspOutLoc.getText();
+
+ if (buildLoc.isEmpty()) {
+ buildLoc = metadataLoc + "/build";
+ }
+ File buildLocDir = new File(buildLoc);
+ if (!buildLocDir.exists()) {
+ createBuildDir(buildLoc);
+ }
+ return buildLoc;
+ }

private boolean createPropertiesFile() {
String create_properties_cmd = bspElem.getMetadataLoc() + "/scripts/" + @@ -319,14 +377,22 @@ public class MainPage extends WizardPage {
}
return true;
}
-
+ private String getSourceCmd(){
+ String metadataLoc = textMetadataLoc.getText();
+ return "source " + metadataLoc + INIT_FILE + " " + getBuildDir() +" > temps; rm -rf temps;";
+ }
private ArrayList<String> getKArches() {
ArrayList<String> karches = new ArrayList<String>();
-
- String get_karch_cmd = textMetadataLoc.getText() + "/scripts/" + KARCH_CMD;
+ String metadataLoc = textMetadataLoc.getText();
+
+ String get_karch_cmd = getSourceCmd() + metadataLoc + "/scripts/" +
+KARCH_CMD;
try {
- Runtime rt = Runtime.getRuntime();
- Process proc = rt.exec(get_karch_cmd);
+// Runtime rt = Runtime.getRuntime();
+// Process proc = rt.exec(get_karch_cmd);
+
+ ProcessBuilder builder = new ProcessBuilder(new String[] {"sh", "-c", get_karch_cmd});
+ Process proc = builder.start();
+
InputStream stdin = proc.getInputStream();
InputStreamReader isr = new InputStreamReader(stdin);
BufferedReader br = new BufferedReader(isr); @@ -351,11 +417,15 @@ public class MainPage extends WizardPage {

private ArrayList<String> getQArches() {
ArrayList<String> qarches = new ArrayList<String>();
+ String metadataLoc = textMetadataLoc.getText();

- String get_qarch_cmd = textMetadataLoc.getText() + "/scripts/" + QARCH_CMD;
+ String get_qarch_cmd = getSourceCmd() + metadataLoc + "/scripts/" +
+QARCH_CMD;
try {
- Runtime rt = Runtime.getRuntime();
- Process proc = rt.exec(get_qarch_cmd);
+// Runtime rt = Runtime.getRuntime();
+// Process proc = rt.exec(get_qarch_cmd);
+ ProcessBuilder builder = new ProcessBuilder(new String[] {"sh", "-c", get_qarch_cmd});
+ Process proc = builder.start();
+
InputStream stdin = proc.getInputStream();
InputStreamReader isr = new InputStreamReader(stdin);
BufferedReader br = new BufferedReader(isr); diff --git a/plugins/org.yocto.sdk.remotetools/src/org/yocto/sdk/remotetools/wizards/bsp/PropertiesPage.java b/plugins/org.yocto.sdk.remotetools/src/org/yocto/sdk/remotetools/wizards/bsp/PropertiesPage.java

index a5e220e..61bd2e5 100644
--- a/plugins/org.yocto.sdk.remotetools/src/org/yocto/sdk/remotetools/wizards/bsp/PropertiesPage.java
+++ b/plugins/org.yocto.sdk.remotetools/src/org/yocto/sdk/remotetools/wi
+++ zards/bsp/PropertiesPage.java
@@ -398,7 +398,7 @@ public class PropertiesPage extends WizardPage {
existingButton.setSelection(false);
kbCombo.removeAll();

- kb_property = "\"" + kernel_choice + "\"."+NEW_KBRANCH_NAME;
+ kb_property = "\\\"" + kernel_choice + "\\\"."+NEW_KBRANCH_NAME;
String[] values = getValues(kb_property);
if (values != null)
kbCombo.setItems(values);
@@ -435,14 +435,20 @@ public class PropertiesPage extends WizardPage {
canFlipToNextPage();
getWizard().getContainer().updateButtons();
}
-
+ private String getSourceCmd(){
+ String metadataLoc = bspElem.getMetadataLoc();
+ return "source " + metadataLoc + MainPage.INIT_FILE +" > temps; rm -rf temps;";
+ }
private String[] getValues(String property) {
ArrayList<String> values = new ArrayList<String>();

- String values_cmd = bspElem.getMetadataLoc() + "/scripts/" + VALUES_CMD_PREFIX + bspElem.getKarch() + VALUES_CMD_SURFIX + property;
+ String values_cmd = getSourceCmd() + bspElem.getMetadataLoc() +
+"/scripts/" + VALUES_CMD_PREFIX + bspElem.getKarch() +
+VALUES_CMD_SURFIX + property;
try {
- Runtime rt = Runtime.getRuntime();
- Process proc = rt.exec(values_cmd);
+// Runtime rt = Runtime.getRuntime();
+// Process proc = rt.exec(values_cmd);
+ ProcessBuilder builder = new ProcessBuilder(new String[] {"sh", "-c", values_cmd});
+ Process proc = builder.start();
+
InputStream stdin = proc.getInputStream();
InputStreamReader isr = new InputStreamReader(stdin);
BufferedReader br = new BufferedReader(isr);
--
1.7.9.5

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


Re: Busybox still old version: Still looking for a clear understanding of an old mystery.

Rudolf Streif <rstreif@...>
 

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

BR,
Rudi

On Jan 15, 2013 1:27 PM, "Brian Smucker" <bds@...> wrote:
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 recompile busybox with a new config: bitbake -c menuconfig busybox
I make busybox: bitbake busybox
bitbake gets compiled.

Then I do a bitbake core-image-minimal.  It does the do_rootfs action and makes a new image.
But the busybox is not the newly-compiled one, it is old.
I expect the new version.
Maybe my expectations are wrong.  But I've struggled with this and similar scenarios time and time again, sometimes hitting on a combination of things that work or by selectively deleting a directory or so or by bitbake -c cleansstate -f on one target or another.

But it's always been kind of a mystery to me how to recompile a particular target, which then succeeds, and subsequently make sure that target is included in the image target (core-image-minimal). I've succeeded in a hit-or-miss way at times, but I would love to know a clear series of steps that will work definitively.

I know I can delete the entire tmp directory, but that seems far too extreme, not to mention slow to recover from.

Can someone help me?

I'm using Danny.

Thanks,
Brian






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


Re: gcov on target

Robert Berger <gmane@...>
 

Hi,

After compiling with:

GCOV_PROFILE := y

I get:

insmod debugfs.ko
Error: could not insert module debugfs.ko: Invalid module format
unknown relocation: 38

Is this a known issue, or am I doing something stupid?

Regards,

Robert



..."In the beginning, there was software. And it wasn't good."

My public pgp key is available,at:
http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x90320BF1


Re: gcov on target

Robert Berger <gmane@...>
 

Hi,

After compiling with:

GCOV_PROFILE := y

I get:

insmod debugfs.ko
Error: could not insert module debugfs.ko: Invalid module format
unknown relocation: 38

Is this a known issue, or am I doing something stupid?

Regards,

Robert



..."In the beginning, there was software. And it wasn't good."

My public pgp key is available,at:
http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x90320BF1


Details on automated Yocto validation?

Sandino Flores Moreno <tigrux@...>
 

Hello.
I'm familiar to bitbake and poky, but I'm new to Yocto.

Where may I find details about Yocto Validation?
Especially in what regards to automated tests.

I came up with this topic because we are using it to build a custom linux distribution, rpm based, and now it is required to implement a proper validation to ensure there are no regressions, that packages are sane, etc.

As it normally happens, there may be an effort that someone else started already.

So far I have only found:

But it's, as the name states, it is very general.
Something more specific would be useful.

Thanks in advance for any info.